CEN/TR 17603-40:2022
(Main)Space engineering - Software engineering handbook
Space engineering - Software engineering handbook
This Handbook provides advice, interpretations, elaborations and software engineering best practices for the implementation of the requirements specified in EN 16603-40 (based on ECSS-E-ST-40C). The handbook is intended to be applicable to both flight and ground. It has been produced to complement the EN 16603-40 Standard, in the area where space project experience has reported issues related to the applicability, the interpretation or the feasibility of the Standard. It should be read to clarify the spirit of the Standard, the intention of the authors or the industrial best practices when applying the Standard to a space project.
The Handbook is not a software engineering book addressing the technical description and respective merits of software engineering methods and tools.
Raumfahrttechnik - Handbuch zur Softwareentwicklung
Ingénierie spatiale - Guide d’ingénierie logiciel
Vesoljska tehnika - Priročnik o programski opremi
Ta priročnik podaja nasvete, razlage, opise in dobre prakse s področja inženiringa programske opreme za izvajanje zahtev iz standarda EN 16603-40 (na podlagi standarda ECSS-E-ST-40C). Priročnik je namenjen uporabi pri letenju in na tleh. Pripravljen je bil kot dopolnilo k standardu EN 16603-40 na področju, na katerem so pri preteklih vesoljskih projektih poročali o težavah v zvezi uporabnostjo, razlaganjem ali izvedljivostjo standarda. Priporočljivo ga je prebrati za razjasnitev smisla standarda, namena avtorjev oziroma dobrih industrijskih praks, kadar se standard uporablja za vesoljski projekt.
Priročnik ni knjiga o inženiringu programske opreme, ki bi obravnavala tehnične opise in z njimi povezane prednosti metod oziroma orodij inženiringa programske opreme.
General Information
Standards Content (Sample)
SLOVENSKI STANDARD
01-september-2022
Vesoljska tehnika - Priročnik o programski opremi
Space engineering - Software engineering handbook
Raumfahrttechnik - Handbuch zur Softwareentwicklung
Ingénierie spatiale - Guide d’ingénierie logiciel
Ta slovenski standard je istoveten z: CEN/TR 17603-40:2022
ICS:
35.080 Programska oprema Software
49.140 Vesoljski sistemi in operacije Space systems and
operations
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.
TECHNICAL REPORT CEN/TR 17603-40
RAPPORT TECHNIQUE
TECHNISCHER BERICHT
June 2022
ICS 49.140; 35.080
English version
Space engineering - Software engineering handbook
Ingénierie spatiale - Guide d'ingénierie logiciel Raumfahrttechnik - Handbuch zur
Softwareentwicklung
This Technical Report was approved by CEN on 20 April 2022. It has been drawn up by the Technical Committee CEN/CLC/JTC 5.
CEN and CENELEC members are the national standards bodies and national electrotechnical committees of Austria, Belgium,
Bulgaria, Croatia, Cyprus, Czech Republic, Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Iceland, Ireland, Italy,
Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Republic of North Macedonia, Romania, Serbia,
Slovakia, Slovenia, Spain, Sweden, Switzerland, Turkey and United Kingdom.
CEN-CENELEC Management Centre:
Rue de la Science 23, B-1040 Brussels
© 2022 CEN/CENELEC All rights of exploitation in any form and by any means
Ref. No. CEN/TR 17603-40:2022 E
reserved worldwide for CEN national Members and for
CENELEC Members.
Table of contents
European Foreword . 6
Introduction . 7
1 Scope . 8
2 References . 10
3 Terms, definitions and abbreviated terms . 12
3.1 Terms from other documents .12
3.2 Terms specific to the present document .12
3.3 Abbreviated terms.12
4 Introduction to space software . 15
4.1 Getting started .15
4.1.1 Space projects . 15
4.1.2 Space standards: The ECSS System . 15
4.1.3 Key characteristics of the ECSS System . 16
4.1.4 Establishing ECSS Standards for a space project . 16
4.1.5 Software / ECSS Standards relevant for Software . 17
4.1.6 Why are standards a MUST for the software development process? . 19
4.1.7 Executing a space software project . 20
4.1.8 Disciplines in Space Software Projects . 21
4.2 Getting compliant .22
4.2.1 The ECSS-E-ST-40C roles . 22
4.2.2 Compliance with the ECSS-E-ST-40C . 26
4.2.3 Characterization of space software leading to various interpretations/applications of
the standard . 28
4.2.4 Software criticality categories . 31
4.2.5 Tailoring . 33
4.2.6 Contractual and Organizational Special Arrangements . 35
5 Guidelines . 41
5.1 Introduction .41
5.2 Software related system requirement process .41
5.2.1 Overview . 41
5.2.2 Software related system requirements analysis . 44
5.2.3 Software related system verification . 45
5.2.4 Software related system integration and control . 46
5.2.5 System requirement review . 53
5.3 Software management process .54
5.3.1 Overview . 54
5.3.2 Software life cycle management . 54
5.3.3 Software project and technical reviews . 55
5.3.4 Software project reviews description . 55
5.3.5 Software technical reviews description . 56
5.3.6 Review phasing . 63
5.3.7 Interface management . 64
5.3.8 Technical budget and margin management . 65
5.3.9 Compliance to this Standard . 65
5.4 Software requirements and architecture engineering process .65
5.4.1 Overview . 65
5.4.2 Software requirement analysis . 65
5.4.3 Software architectural design . 67
5.4.4 Conducting a preliminary design review . 76
5.5 Software design and implementation engineering process .76
5.5.1 Overview . 76
5.5.2 Design of software items . 76
5.5.3 Coding and testing . 78
5.5.4 Integration . 81
5.6 Software validation process .83
5.6.1 Overview . 83
5.6.2 Validation process implementation . 84
5.6.3 Validation activities with respect to the technical specification. 91
5.6.4 Validation activities with respect to the requirement baseline . 91
5.7 Software delivery and acceptance process .93
5.7.1 Overview . 93
5.7.2 Software delivery and installation . 93
5.7.3 Software acceptance . 94
5.8 Software verification process .97
5.8.1 Overview . 97
5.8.2 Verification process implementation . 97
5.8.3 Verification activities . 100
5.9 Software operation process .104
5.9.1 Overview . 104
5.9.2 Process implementation . 107
5.9.3 Operational testing . 107
5.9.4 Software operation support . 107
5.9.5 User support . 107
5.10 Software maintenance process .108
5.10.1 Overview . 108
5.10.2 Process implementation . 108
5.10.3 Problem and modification analysis . 115
5.10.4 Modification implementation . 115
5.10.5 Conducting maintenance review . 115
5.10.6 Software migration . 115
5.10.7 Software retirement . 115
6 Selected topics . 116
6.1 Use Cases and Scenarios .116
6.1.1 Relation to the Standard . 116
6.1.2 Introduction to use cases . 116
6.1.3 Identification of use cases . 117
6.1.4 Formalization of each use case . 117
6.1.5 Definition and guidelines. 119
6.2 Life cycle .120
6.2.1 Relation to the Standard . 120
6.2.2 Introduction . 120
6.2.3 Existing life-cycle models. 122
6.2.4 Choosing a Software life-cycle . 131
6.3 Model based Engineering .134
6.3.1 Relation to the Standard . 134
6.3.2 Definition and guidelines. 135
6.4 Testing Methods and Techniques .138
6.4.1 Relation to the Standard . 138
6.4.2 Introduction . 138
6.4.3 Definitions . 138
6.4.4 Test objectives . 138
6.4.5 Testing strategies and approaches . 141
6.4.6 Real Time Testing . 145
6.5 Autocode .146
6.5.1 Relation to the Standard . 146
6.5.2 Introduction . 146
6.5.3 Subsystem and software relationship around autocode . 147
6.5.4 From subsystem model to autocoded model. 150
7 Real-time software . 152
7.1 Relation to the Standard .152
7.2 Software technical budget and margin philosophy definition . 152
7.2.1 Introduction . 152
7.2.2 Load and real-time . 153
7.2.3 Memory capacity . 156
7.2.4 Numerical Accuracy . 156
7.2.5 Interface timing budget . 156
7.3 Technical budget and margins computation .157
7.3.1 Load and real-time . 157
7.3.2 Memory margins . 158
7.3.3 Numerical accuracy budget management . 158
7.3.4 Interface timing budget management . 159
7.4 Selection of a computational model for real-time software .159
7.4.1 Introduction . 159
7.4.2 Recommended Terminology . 160
7.4.3 Computational model . 164
7.5 Schedulability analysis for real-time software .169
7.5.1 Overview . 169
7.5.2 Schedulability Analysis . 169
Annex A Documentation Requirement List . 179
Annex B Generic Techniques . 183
B.1 Formal Methods .183
B.2 Functional Decomposition and Structured Analysis .184
B.2.1 Introduction . 184
B.2.2 Data flow . 185
B.2.3 Control Flow . 186
B.3 Object-Oriented Analysis (OOA) .187
B.4 Architecture and Design.187
B.5 Data Description Languages .188
B.6 State machine modelling languages .189
B.7 ITIL ® .190
Annex C (normative) "Software Maintenance Plan (SMP) – DRD" . 192
C.1 DRD identification . 192
C.1.1 Requirement identification and source document . 192
C.1.2 Purpose and objective . 192
C.2 Expected response .192
C.2.1 Scope and content . 192
Figures
Figure 4-1: ECSS relations for discipline software . 17
Figure 4-2: Role relationships . 26
Figure 4-3 : Delivery of warranty and support between companies . 36
Figure 4-4 : Closely Coupled Build and Service Support Contract . 36
Figure 5-1: System database. 48
Figure 5-2: Constraints between life cycles . 50
Figure 5-3: Software requirement reviews . 53
Figure 5-4: Phasing between system reviews and flight software reviews . 64
Figure 5-5: Phasing between ground segment reviews and ground software reviews . 64
Figure 5-6 : Reuse in case of reference architecture . 75
Figure 5-7 : Example ITIL processes . 106
Figure 6-1: The autocoding process . 149
Figure 7-1: Mitigation of theoretical worst case with operational scenarios. . 154
Figure 7-2: An example of a complete task table with all timing figures . 175
Figure 7-3 : Maintenance Cycle . 191
Tables
Table 5-1: Possible review setup . 59
Table 5-2: Example of review objectives and their applicability to each version . 60
Table 6-1: Choosing a Software life-cycle . 131
Table 6-2: Relation between the testing objectives and the testing strategies . 145
Table 7-1: Schedulability Analysis Checklists . 176
European Foreword
This document (CEN/TR 17603-40:2022) has been prepared by Technical Committee CEN/CLC/JTC 5
“Space”, the secretariat of which is held by DIN.
It is highlighted that this technical report does not contain any requirement but only collection of data
or descriptions and guidelines about how to organize and perform the work in support of EN 16603-
40.
This Technical report (CEN/TR 17603-40:2022) originates from ECSS-E-HB-40A.
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. CEN [and/or CENELEC] shall not be held responsible for identifying any or all such
patent rights.
This document has been prepared under a mandate given to CEN by the European Commission and
the European Free Trade Association.
This document has been developed to cover specifically space systems and has therefore precedence
over any TR covering the same scope but with a wider domain of applicability (e.g.: aerospace).
Introduction
The ECSS-E-ST-40C Standard defines the principles and requirements applicable to space software
engineering. This ECSS-E-HB-40A handbook provides guidance on the use of the ECSS-E-ST-40C.
History of the ECSS-E-40
At the beginning was ESA PSS-05. It was a prescriptive list of requirements ordered all along a
waterfall lifecycle. It was necessary to improve it because it was too prescriptive and not flexible
enough to apply new technologies such as UML.
ECSS was created in the 90’s, and ECSS-E-40A was published in 1999. It was derived from ISO 12207,
which is a process model. A process model proposes a set of abstract processes, and the software
developer defines its own lifecycle that enters and leaves and re-enters the various processes. The
process model was very abstract, with sort of meta-processes that were “invoking” other sub-
processes. The new ECSS-E-40A was not prescriptive and very flexible to any kind of lifecycle.
ECSS-E-40A was improved because it was too abstract and it was not clear what had to be done.
ECSS-E-40B was worked out in order to downsize the abstraction. The invocation was simplified,
some processes were grouped. ECSS-E-40B was sent for public review.
The public review recommended improving further the pragmatic aspects of the standard. Therefore
another ECSS-E-40B version was produced where the process model was streamlined.
At a workshop in 2004 on the use of ECSS-E-40B, it was recognised that some of the requirements left
room for interpretation, which in turn lead to many discussions in the project reviews (especially
when they were overlooked during the Software Development Plan review). Therefore the version C
of ECSS-E-ST-40 was produced to improve the usability of the standard, refining and streamlining the
open requirements, and somehow coming closer to the ESA PSS-05 spirit.
Scope
This Handbook provides advice, interpretations, elaborations and software engineering best practices
for the implementation of the requirements specified in ECSS-E-ST-40C. The handbook is intended to
be applicable to both flight and ground. It has been produced to complement the ECSS-E-ST-40C
Standard, in the area where space project experience has reported issues related to the applicability,
the interpretation or the feasibility of the Standard. It should be read to clarify the spirit of the
Standard, the intention of the authors or the industrial best practices when applying the Standard to a
space project.
The Handbook is not a software engineering book addressing the technical description and respective
merits of software engineering methods and tools.
ECSS-E-HB-40A covers, in particular, the following:
a. In section 4.1, the description of the context in which the software engineering standard
operates, together with the explanation of the importance of following standards to get proper
engineering.
b. In section 4.2, elaboration on key concepts that are essential to get compliance with the
Standard, such as the roles, the software characteristics, the criticality, the tailoring and the
contractual aspects.
c. In section 5, following the table of content of the ECSS-E-ST-40C Standard, discussion on the
topics addressed in the Standard, with the view of addressing the issues that have been
reported in projects about the interpretation, the application or the feasibility of the
requirements. This includes in particular:
1. Requirement engineering and the relationship between system and software
2. Implementation of the requirements of ECSS-E-ST-40 when different life-cycle paradigms
are applied (e.g., waterfall, incremental, evolutionary, agile) and at different levels of the
Customer-Supplier Network
3. Architecture, design and implementation, including real-time aspects
4. Unit and integration testing considerations, testing coverage
5. Validation and acceptance, including software validation facility and ISVV
implementation
6. Verification techniques, requirements and plan
7. Software operation and maintenance considerations.
d. In section 6 and 7, more information about selected topics addressed in section 5 such as (in
section 6) use cases, life cycle, model based engineering, testing, automatic code generation, and
(in section 7) technical budget and margin, computational model and schedule analysis.
NOTE In order to improve the readability of the Handbook, the
following logic has been selected for sections 5, 6, and 7:
• section 5 follows the table of content of ECSS-E-ST-40C at
least up to level 3 and generally up to level 4. For each sub
clause of ECSS-E-ST-40C:
+ either information is given fully in section 5,
+ or there is a pointer into section 6 or section 7
+ or the paragraph has been left intentionally empty for
consistency with the ECSS-E-ST-40C table of content, in this
case, only “ –“ is mentioned.
• section 6 expands selected parts of section 5 when:
+ either the volume of information was considered too large to
stay in section 5,
+ or the topic is addressed in several places of section 5
In any case, there is a pointer from section 5 to section 6, and
section 6 mentions the various places in ECSS-E-ST-40C
where the topic is addressed.
• section 7 follows the same principles as section 6, but
gathers the topics related to margins and to real-time.
e. In Annex A, as a complement to the ECSS-E-ST-40C Annex A called Document Requirement
List [DRL], the documents expected at the Technical Reviews such as SWRR, DDR, TRR and
TRB.
f. In Annex B, software engineering techniques appropriate for the implementation of specific
ECSS-E-ST-40C clauses and their selection criteria, covering most of the software lifecycle.
g. In Annex C, an example of the Document Requirement Definition of the Software Maintenance
Plan.
References
EN Reference Reference in text Title
EN 16601-00-01 ECSS-S-ST-00-01C ECSS system - Glossary of terms
EN 16603-10 ECSS-E-ST-10C Space engineering – System engineering general
requirements
EN 16603-40 ECSS-E-ST-40C Space engineering - Software
EN 16603-70-01 ECSS-E-ST-70-01C Space engineering - On board control procedures
ECSS-E-TM-40-07A Space engineering - Simulation modelling platform
EN 16601-40 ECSS-M-ST-40C Space project management - Configuration and
information management
EN 16602-80 ECSS-Q-ST-80C Space product assurance - Software product
assurance
Def Stan 00-54 (March Requirements for Safety Related Electronic Hardware
1999) in Defence Equipment" Part No: 1: Requirements:
Issue 1
ESA ISVV Guide ESA Guide for Independent Software Verification
and Validation, Version 2.0, December 29, 2008
IEEE 610.12-1990 (Jan IEEE Standard Glossary of Software Engineering
1990) Terminology
IEEE 754-1985 (Aug IEEE Standard for Binary Floating-Point Arithmetic
1985)
ISO/IEC 12207:2008 Systems and software engineering – Software life
cycle processes
NASA Study on Flight Final Report. NASA Study on Flight Software
Software Complexity Complexity. Commissioned by the NASA Office of
(May 2009) Chief Engineer. Technical Excellence Program Adam
West, Program Manager
RNC-CNES-E-HB-70- Space engineering monitoring and control
501 (September 2008) specification guide, Version 2, September 16, 2008
NASA Lessons http://llis.nasa.gov/llis/search/home.jsp
Learned
NASA System NASA/SP-2007-6105 Rev1 December 2007
Engineering
Handbook
EN Reference Reference in text Title
ESA PSS-05-0 Issue 2 ESA software engineering standards Issue 2
(February 1991)
Flight Computer Space Avionics Open Interface initiative document:
Initialisation Sequence SAVOIR/12-007/FT http://savoir.estec.esa.int
Terms, definitions and abbreviated terms
3.1 Terms from other documents
For the purpose of this document, the terms and definitions from ECSS-S-ST-00-01C and ECSS-E-ST-
40C apply.
3.2 Terms specific to the present document
3.2.1 software product:
set of computer programs, procedures, documentation and their associated data
3.2.2 acceptance test
test of a system or functional unit usually performed by the customer on his premises after
installation, with the participation of the supplier to ensure that the contractual requirements are met
[adapted from ISO/IEC 2382--20:1990]
NOTE ECSS-E-ST-40C relies on ECSS-E-ST-00-01 for the definition of
acceptance test and software product (and consequently of its
synonyms “software” and “software item”). However, these
two terms have disappeared in its last revision C. The
definitions of ECSS-E-ST-40B (and therefore ECSS-Q-ST-80B)
are restored here.
3.3 Abbreviated terms
For the purpose of this document, the abbreviated terms from ECSS-S-ST-00-01C and ECSS-E-ST-40C
apply.
Abbreviation Meaning
acceptance review
AR
NOTE The term SW-AR can be used for clarity to denote ARs
that solely involve software products.
critical design review
CDR
NOTE The term SW-CDR can be used for clarity to denote
CDRs that solely involve software products.
capability maturity model integration
CMMI
commercial-off-the-shelf
COTS
Abbreviation Meaning
central processing unit
CPU
design definition file
DDF
detailed design review
DDR
design justification file
DJF
document requirements definition
DRD
European Cooperation for Space Standardization
ECSS
expected output
eo
ground segment
GS
human machine interface
HMI
hardware-software interaction analysis
HSIA
hardware
HW
interface control document
ICD
international registration scheme for assessors
INTRSA
interface requirements document
IRD
International Organization for Standardization
ISO
independent software validation
ISV
independent software verification and validation
ISVV
management file
MGT
maintenance file
MF
modified off-the-shelf
MOTS
on-board control procedure
OBCP
operational plan
OP
operational readiness review
ORR
off-the-shelf
OTS
product assurance file
PAF
preliminary design review
PDR
NOTE The term SW-PDR can be used for clarity to denote
PDRs that solely involve software products.
preliminary requirement review
PRR
qualification review
QR
NOTE The term SW-QR can be used for clarity to denote QRs
that solely involve software products.
requirements baseline
RB
standard CMMI appraisal method for process improvement
SCAMPI
software development environment
SDE
software operation support
SOS
Abbreviation Meaning
software product assurance
SPA
software product assurance milestone report
SPAMR
software product assurance plan
SPAP
software problem report
SPR
software review board
SRB
system requirements review
SRR
NOTE The term SW-SRR can be used for clarity to denote SRRs
that solely involve software products.
software
SW
software engineering
SWE
test readiness review
TRR
technical specification
TS
Introduction to space software
4.1 Getting started
4.1.1 Space projects
Space projects vary widely in purpose, size, complexity and availability of resources. Depending on
the intended scenarios, the space projects will cover from small up to very complex developments
which may consist of a space segment (e.g. manned spacecraft’s like COLUMBUS, unmanned space
vehicles like ATV or ARIANE rockets, all kinds of satellites, and payloads within a spacecraft or
externally attached residing directly in space), of a launch service segment (e.g. ARIANE Launch
complex at Kourou) and of a ground segment (e.g. operations and control centres as well as data
evaluation sites).
The production of space systems calls for the cooperation of several organizations that share the
common objective of providing a product that satisfies the customer’s needs (performance within cost
and schedule constraints). This setup requires a strong project management for all involved parties. To
base business agreements (e.g. contracts) which define all kinds of applicable standards that are
binding for the space project.
4.1.2 Space standards: The ECSS System
In order to enable all experts to "speak the same language" in a space project, a comprehensive set of
coherent European Space Standards has been developed as a cooperative effort between the European
space agencies and space industries under the heading of European Cooperation for Space
Standardization (abbreviated: ECSS). This set of standards is addressing all essential aspects of the
three major domains for the successful implementation of space programmes and projects and is
covering all aspects of interest that might appear for the procurement of a generic space product.
Besides general objectives and standardization policies as in the top level documents entitled "ECSS
System - Description, implementation and general requirements" (ECSS-S-ST-00C) and terminology
"ECSS System - Glossary of terms" (ECSS-S-ST-00-01C) for a space project, the three major domains:
• Space project management,
• Space engineering, and
• Space product assurance
are addressed and their activities are described in a necessary level of detail for application / execution
in the form of processes.
4.1.3 Key characteristics of the ECSS System
The ECSS System has four prominent characteristics, which are to provide:
a. a comprehensive and coherent set of standards offering a complete and stable framework
within which customers and suppliers at all levels can implement a project in an efficient and
cost effective manner;
b. a system of standards constructed in such a way that it can be applied throughout the life cycle
of space projects and programmes;
c. a system that can be utilized in activities ranging from small, individual, less complex projects
to very large programmes comprising several projects involving many products and interfaces;
d. a controlled method for tailoring the standards such that they can be applied selectively
depending on the type, or phase of the project for which they are being used.
As a consequence, the ECSS System focuses primarily on what is required to comply with each
standard, rather than how to achieve this. This approach provides the flexibility for different
customers and suppliers to use established “in-house” procedures, or processes, to comply with these
standards. The ECSS System also includes supporting standards, which identify specific procedures or
processes, and Handbooks, which provide technical data and guidelines for procedures and
processes. Handbooks are documents providing orientation, advice or recommendations on non-
normative matters.
4.1.4 Establishing ECSS Standards for a space project
There is a 7-step process for the a) preparation and b) application of tailoring to establish the ECSS
Standards and their requirements for a space project.
a) Preparatory activities:
1) Identification of project characteristics;
means to identify strategic and technical aspects of the space project.
2) Analysis of project characteristics and identification of risks;
enforces a close analytical look to significant cost, risk and technical drivers as well as critical
issues and specific constraints. These are used to identify and evaluate inherent and induced
risks.
b) Tailoring activities:
3) Selection of applicable ECSS Standards;
comprises to evaluate the ECSS Standards for relevance to the overall space project's needs.
Those standards found to be relevant are identified as applicable standards for the
implementation of the project.
4) Selection of applicable ECSS requirements;
Having established the list of applicable ECSS Standards for a project, the extent to which the
requirements (contained within these standards) are made applicable is to be assessed against
cost, schedule, and technical drivers, as well as against the identified risks and their mitigation
strategies.
5) Addition of new requirements;
Where the applicable ECSS Standards do not include a specific requirement needed for the
space project, a new requirement needs to be generated or adopted from an international
standard.
6) Harmonization of applicable requirements;
Having completed the selection of applicable ECSS Standards and requirements and the
addition of any new requirements, the coherence and consistency of the overall set of
requirements to be applied to the space project is reviewed to eliminate the risk of conflict,
duplication, or lack of necessary requirements.
7) Documenting ECSS Standards and requirements applicability
The process steps 1 to 6 intentionally do not define a specific format for generating and
recording the results of the process. This approach is in line with the ECSS principle of
identifying what is required, but not how this is to be achieved, and provides a degree of
freedom for customers to select the most appropriate way to present the data within their
particular environment.
One method of recording the applicability data in an efficient and structured manner is to consolidate
it into an “Applicable Requirements Matrix”.
Further details on each of these activities are contained in document "ECSS System - Description and
implementation" (ECSS-S-ST-00C).
4.1.5 Software / ECSS Standards relevant for Software
Within a space project "software" plays a key-role with respect to system functionality and operations.
It is found at all levels, ranging from system functions down to firmware, including safety and
mission critical functions. The Figure 4-1 identifies the main relations of the ECSS-E-ST-40C with the
other ECSS Standards.
Figure 4-1: ECSS relations for discipline software
The ECSS-S-ST-00C document provides a general introduction to the ECSS System and to the use of
the ECSS documents in all the space projects and gives therefore background information also for
software projects. The M standards for project management define phases, processes, reviews and
rules for space project organization that apply also for software projects. In particular the ECSS-M-
ST-40C Rev1 defines the space configuration and information management requirements also for
software projects. In addition, the ECSS-M-ST-10C Rev1 requirements are tailored for software in the
ECSS-S-ST-40 Software Management Process.
The context of the space software engineering activities is the overall Space System Engineering
process. System engineering is defined as an interdisciplinary approach governing the total technical
effort to transform requirements into a system solution. It's framework is defined by the "Space
engineering - System Engineering General Requirements" (ECSS-E-ST-10C) Standard which is
intended to apply to all space systems and products, at any level of the system decomposition,
including hardware, software, procedures, man-in-the-loop, facilities and services.
The "Space Engineering Software" Standard (ECSS-E-ST-40C) covers the software development of
the “Space system product software”, i.e. all software that is part of a space system product tree and
that is developed as part of a space project needs to apply this standard (for software deliverables and
non-deliverables). It focuses on space software engineering processes requirements and their expected
outputs. A special emphasis is put in the standard on the system-to-software relationship and on the
verification and validation of software items.
This Standard is, to the extent made applicable by project business agreements, to be applied by all the
elements of a space system, including the space segment, the launch service segment and the ground
segment. It covers all aspects of space software engineering including requirements definition, design,
production, verification and validation, transfer, operations and maintenance.
The Standard defines the scope of the space software engineering processes and its interfaces with
management and product assurance, which are addressed in the Management (–M) and Product
assurance (–Q) branches of the ECSS System, and explains how they apply in the software engineering
processes. Together with the requirements found in the other branches of the ECSS Standards,
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.
Loading comments...