Professional Documents
Culture Documents
6 August 2007
Space engineering
System engineering
This ECSS document is a draft standard distributed for Public Review. It is therefore
subject to change without any notice and may not be referred to as an ECSS Standard
until published as such.
End of Public Review: 5 December 2007
ECSS Secretariat
ESA-ESTEC
Requirements & Standards Division
Noordwijk, The Netherlands
ECSS-E-10 C Draft 1
6 August 2007
2
ECSS-E-10 C Draft 1
6 August 2007
Foreword
3
ECSS-E-10 C Draft 1
6 August 2007
Contents
Foreword...............................................................................................................................................3
1 Scope .......................................................................................................................................7
4
ECSS-E-10 C Draft 1
6 August 2007
Bibliography........................................................................................................................................91
Figures
Figure 1 System engineering functions and boundaries ............................................................... 17
Figure 2 System engineering function and relationships ............................................................... 18
Figure B-1 Relationship between documents .................................................................................. 38
Tables
Table A-1 System engineering deliverable documents............................................................................. 34
5
ECSS-E-10 C Draft 1
6 August 2007
6
ECSS-E-10 C Draft 1
6 August 2007
1
Scope
This Standard is intended to apply to all space systems and product, at any
level of the system decomposition, including hardware, software, man-in-the-
loop, facilities and services.
7
ECSS-E-10 C Draft 1
6 August 2007
8
ECSS-E-10 C Draft 1
6 August 2007
2
Normative references
9
ECSS-E-10 C Draft 1
6 August 2007
10
ECSS-E-10 C Draft 1
6 August 2007
3
Terms, definitions and abbreviated terms
3.1.1
critical
characteristic of a process, process condition, parameter, requirement or item
that deserves control and special attention in order to meet the objectives (e.g.
of a mission) within given constraints
11
ECSS-E-10 C Draft 1
6 August 2007
3.1.2
design to cost
method of managing a project, which enables the project to be controlled from
its inception in order to meet defined performances within pre-established
objectives of cost and time
3.1.3
integration
process of physically and functionally combining lower level products
(hardware or software) to obtain a particular functional configuration
3.1.4
mission statement
set of collected needs
NOTE Document commonly used within the space community,
see also 3.1.5.
3.1.5
need
what is necessary for, or desired by, the user
NOTE 1 A need can be declared or undeclared; it can be an existing
or a potential one.
NOTE 2 The user is a person or an organization for which the
product is designed and which exploits at least one of its
functions at any time during its life cycle.
NOTE 3 For the space community, the needs are often called
mission statement, see 3.1.4.
NOTE 4 Adapted from EN 1325-1.
3.1.6
requirement traceability
requirement attribute that links each single requirement to its higher level
requirements inside the requirement set
NOTE This enables the derivation of a requirement tree, which
demonstrates the coherent flow-down of the requirements.
3.1.7
recurring product
a product which conforms to a qualified design and produced according to the
corresponding production master file
3.1.8
system engineering
the interdisciplinary approach governing the total technical effort required to
transform a requirement into a system solution
NOTE From IEEE P1220.
3.1.9
system engineering process
set of inter-related or interacting activities, each transforming inputs into
outputs, to implement system engineering
3.1.10
technical requirement
requirement stated in the technical terms
12
ECSS-E-10 C Draft 1
6 August 2007
3.1.11
technology readiness level
achieved status of development of a technology
NOTE TRL levels 1 to 9 are defined as follows:
13
ECSS-E-10 C Draft 1
6 August 2007
14
ECSS-E-10 C Draft 1
6 August 2007
4
Overview of systems engineering
15
ECSS-E-10 C Draft 1
6 August 2007
16
ECSS-E-10 C Draft 1
6 August 2007
17
18
System Engineering Data Base
6 August 2007
Technical Plans
System Engineering Tools and Models
ECSS-E-10 C Draft 1
System Analysis
Analysis
Verification
The systems engineering process is applied for each element of the product
decomposition.
19
ECSS-E-10 C Draft 1
6 August 2007
20
ECSS-E-10 C Draft 1
6 August 2007
5
General requirements
21
ECSS-E-10 C Draft 1
6 August 2007
22
ECSS-E-10 C Draft 1
6 August 2007
23
ECSS-E-10 C Draft 1
6 August 2007
5.4 Analysis
5.4.1 System analysis
a. The systems engineering organisation shall perform an analysis of the
Mission Statement document, produce Mission Description document(s)
(see ECSS-E-10C Annex B), and maintain this latter document for the final
selected concept.
b. The systems engineering organisation shall perform a functional analysis
as defined in ECSS-E-HB-10-05, produce the functional architecture
documented as per ECSS-E-10C Annex G, and the function tree (see ECSS-
E-10C Annex H).
c. The systems engineering organisation shall perform a physical analysis
documented as per ECSS-E-10C Annex G as input to the physical
architecture documented as per ECSS-E-10C Annex G and to the product
tree (as defined in ECSS-M-40B Annex B).
d. The systems engineering organisation shall analyse the performances of the
system, including end-to-end evaluation, documenting the results of the
analysis as per the Design Justification File, see ECSS-E-10C Annex K.
e. The systems engineering organisation shall analyse influence of mission,
design, development, operations and constraints on cost and schedule as
input to the project cost and schedule consolidation.
24
ECSS-E-10 C Draft 1
6 August 2007
25
ECSS-E-10 C Draft 1
6 August 2007
5.5.1.2 Budgets
The systems engineering organisation shall:
a. define and maintain all technical budgets reflecting the as-designed status
of the system;
b. apportion budget requirements to all levels of system decomposition;
c. apply the margin policy.
26
ECSS-E-10 C Draft 1
6 August 2007
f. All design models shall refer to a reference coordinate system agreed with
the customer (as defined in ECSS-E-10-09A Coordinate systems).
5.5.2 Configuration
5.5.2.1 Configuration content
a. The configuration shall include the complete system functional, physical
and software characteristics, budgets, interfaces and relationships between
external and internal items.
b. The configuration shall include all lower decomposition levels.
c. The configuration shall be documented in the DDF (see ECSS-E-10C Annex
G) and in configuration definition documents (as defined in ECSS-M-40B).
5.6 Verification
5.6.1 General
a. The system engineering organisation shall implement the verification
according to ECSS-E-10-02B.
b. The system engineering organisation shall establish a verification strategy
documented in the Verification Plan, as defined in ECSS-E-10-02B Annex
B.
c. The system engineering organisation shall assign the product to a
verification product category, as defined in ECSS-E-10-02B Table-1.
d. The system engineering organisation shall confirm that all verification
objectives are achieved by analysing the results of the verification activities
(Verification Control Document and its closeout documents, as defined in
ECSS-E-10-02B Annex C).
e. The system engineering organisation shall ensure that validation of
systems with man-in-the-loop take into account the man related
limitations.
27
ECSS-E-10 C Draft 1
6 August 2007
28
ECSS-E-10 C Draft 1
6 August 2007
6.1 General
a. System engineering organisation shall implement the project phases in
accordance with ECSS-M-30B.
b. System engineering organisation shall produce in each project phase
documents as per Table A-1 of ECSS-E-10C Annex A.
c. System engineering organisation shall ensure that for critical elements
which are not at the next lower level, the functional specification, the
technical specification, the design definition file and the design justification
file are available in early project phases.
d. System engineering organisation shall identify the critical elements.
NOTE The documents to be approved by the Customer as well as
the time of their approval are listed in the business
agreement.
29
ECSS-E-10 C Draft 1
6 August 2007
30
ECSS-E-10 C Draft 1
6 August 2007
31
ECSS-E-10 C Draft 1
6 August 2007
32
ECSS-E-10 C Draft 1
6 August 2007
Annex A (normative)
System engineering documents delivery
per review
Table A-1 lists the documents that are defined as output of the systems
engineering organization activities during the phases of a project.
Documents are either ECSS-E-10C DRDs or DRDs to other ECSS-E-XX
standards, or defined within the referenced DRDs.
NOTE For the definition and contents of ECSS DRDs see ECSS-
D-00 Annex C.2.1.6.
33
ECSS-E-10 C Draft 1
6 August 2007
Specifications
34
ECSS-E-10 C Draft 1
6 August 2007
Functional specifications
for next lower level (2) + + + + + +
Technical specifications
for next lower level (2) + + + + +
Design definition file for
next lower level (2) + + + + +
Interface control
document ECSS-E-10-04B Annex A + + + + + + +
Product User manual /
User Manual ECSS-E-10C Annex P + + + + + + + + + +
35
ECSS-E-10 C Draft 1
6 August 2007
GSE specifications + + +
Other documents
ECSS-E- 10
Integration procedure Part 15 Annex A + + +
ECSS-E-10 Part
Production master file (1) 15 Annex C + +
Note (1) : To be published; Note (2) : See 5.7.1 c., 5.7.1 d., and 5.7.1 Note.
36
ECSS-E-10 C Draft 1
6 August 2007
Annex B (normative)
Mission description document (MDD) – DRD
37
ECSS-E-10 C Draft 1
6 August 2007
Mission Statement
Functional Specification
Mission Mission
Description
Document
... Description
Document
Concept #1 Concept #n
System System
Engineering Engineering
Plan #1 Plan #n
Trade-off report
<1> Introduction
The MDD shall contain a description of the purpose, objective, content and the
reason prompting its preparation (e.g. logic, organization, process or
procedure).
38
ECSS-E-10 C Draft 1
6 August 2007
39
ECSS-E-10 C Draft 1
6 August 2007
<7> Conclusion
The MDD shall summarize the strengths and weaknesses of the concept.
40
ECSS-E-10 C Draft 1
6 August 2007
Annex C (normative)
System concept report – DRD
<1> Introduction
The system concept report shall contain a description of the purpose, objective,
content and the reason prompting its preparation (e.g. logic, organization,
process or procedure).
41
ECSS-E-10 C Draft 1
6 August 2007
<7> Conclusion
The system concept report shall present the identified technical and
programmatic risks induced by possible concept(s), and any additional activity
necessary to be performed for risk mitigation.
C.2.3 Special remark
None.
42
ECSS-E-10 C Draft 1
6 August 2007
Annex D (normative)
System engineering plan (SEP) – DRD
<1> Introduction
The SEP shall contain a description of the purpose, objective, content and the
reason prompting its preparation (e.g. programme or project reference and
phase).
43
ECSS-E-10 C Draft 1
6 August 2007
44
ECSS-E-10 C Draft 1
6 August 2007
b. The SEP shall provide dates of milestones or the duration of phases and the
critical path according to the project master schedule.
<3.4> Procurement approach
The SEP shall describe the strategy for acquisition of the items of the system or
products defined in the product tree (e.g. make or buy, product line,
incremental development).
<3.5> Initial critical issues
The SEP shall list the critical issues identified at the beginning of the project
phase(s) covered in the SEP (e.g. any specific issues, problems, critical subjects,
which require dedicated attention, investigation, action and planning).
45
ECSS-E-10 C Draft 1
6 August 2007
46
ECSS-E-10 C Draft 1
6 August 2007
47
ECSS-E-10 C Draft 1
6 August 2007
The SEP shall define process and control to be put in place to meet
requirements for software engineering. It shall cover, amongst others, flight
and ground software, checkout software and simulation software.
j. Communications engineering (as defined in ECSS-E-50)
The SEP shall define process and control to be put in place to meet
requirements for communication engineering. It shall cover, amongst
others, spacecraft-to-ground, spacecraft-to-spacecraft, ground-to-ground
and on-board communications links.
NOTE It includes aspects such link budgets, data management,
RF, audio and video communications and protocols.
k. Control engineering (as defined in ECSS-E-60)
The SEP shall define process and control to be put in place to meet
requirements for control engineering. It shall cover, amongst others, AOCS,
robotics, rendez-vous and docking.
<5.1.3> Work package
The SEP shall define and describe the work package(s) for the relevant
engineering tasks, which are maintained in the work breakdown structure.
<5.2> Related plans
<5.2.1> General
a. When the SEP includes sub-plans covering parts of system engineering
activities, these sub-plans shall be annexed to the SEP.
b. The SEP shall integrate or refer to the following plans:
1. the SEP plans of sub-products constituting the system or product
2. the system or product verification plan (VP), AIT plan, AIV plan and
technology plan
NOTE VP and AIT plans can be integral parts of the SEP, or
rolled out separately (without overlap), or combined as the
AIV Plan. However, the existence of the AIV Plan excludes
independent VP and AIT plans.
3. other specific engineering plans, e.g. Fracture Control Plan, Micro-
gravity Control Plan, Electro-Magnetic Compatibility Plan, Audible
Noise Control Plan, and Radio Frequency Plan
<5.2.2> Verification Plan (VP)
The SEP shall integrate or refer to the document that conforms to the
Verification plan DRD defined in ECSS-E-10-02B Annex B.
<5.2.3> AIT Plan
The SEP shall integrate or refer to the document that conforms to the AIT plan
DRD as defined in ECSS-E-10-03B Annex A.
<5.2.4> AIV Plan
The SEP shall integrate the document that conforms to the VP plan defined in
ECSS-E-10-02B Annex B and ECSS-E-10C Annex D.2.2 <5.2.1> and the
document that conforms to the AIT plan as defined in ECSS-E-10-03B Annex
A.
<5.2.5> Technology Plan
The SEP shall integrate or refer to the document that conforms to the
technology plan DRD defined in ECSS-E-10C Annex E.
48
ECSS-E-10 C Draft 1
6 August 2007
49
ECSS-E-10 C Draft 1
6 August 2007
50
ECSS-E-10 C Draft 1
6 August 2007
Annex E (normative)
Technology plan (TP)– DRD
<1> Introduction
The TP shall contain a description of the purpose, objective, content and the
reason prompting its preparation (e.g. programme or project reference and
phase).
51
ECSS-E-10 C Draft 1
6 August 2007
a. SEP,
b. Technology matrix (as defined in ECSS-E-10C, Annex F),
c. Function tree, and
d. Specification tree (functional and technical).
52
ECSS-E-10 C Draft 1
6 August 2007
<4.5> TP interfaces
The TP shall describe the external and internal interfaces in conformance to
the SEP.
53
ECSS-E-10 C Draft 1
6 August 2007
54
ECSS-E-10 C Draft 1
6 August 2007
Annex F (normative)
Technology matrix - DRD
<1> Introduction
The technology matrix shall contain a description of the purpose, objective,
content and the reason prompting its preparation.
55
ECSS-E-10 C Draft 1
6 August 2007
<6> Conclusion
a. The technology matrix shall provide, for each system function, the selected
technology or technological element, a list of the identified project risks and
critical aspects, and an identified back-up technological solution.
F.2.3 Special remark
None.
56
ECSS-E-10 C Draft 1
6 August 2007
Annex G (normative)
Design definition file (DDF)- DRD
57
ECSS-E-10 C Draft 1
6 August 2007
<1> Introduction
The DDF shall contain a description of the purpose, objective and the reason
prompting its preparation (e.g. programme or project reference and phase).
58
ECSS-E-10 C Draft 1
6 August 2007
59
ECSS-E-10 C Draft 1
6 August 2007
<9> Conclusion
The DDF shall list and summarize all deviations of the design with respect to
the technical specifications and constraints induced by the system or product
design definition.
G.2.3 Special remark
None.
60
ECSS-E-10 C Draft 1
6 August 2007
Annex H (normative)
Function tree - DRD
<1> Introduction
The function tree document shall contain a description of the purpose, objective
and the reason prompting its preparation.
61
ECSS-E-10 C Draft 1
6 August 2007
62
ECSS-E-10 C Draft 1
6 August 2007
Annex I (normative)
Technical budget - DRD
<1> Introduction
The technical budget shall contain a description of the purpose, objective,
content and the reason prompting its preparation.
63
ECSS-E-10 C Draft 1
6 August 2007
<5> Conclusion
The technical budget shall contain a conclusion that identifies the key
engineering parameters having a negative margin, and identify for each of
those:
a. the impact on the technical requirements and the associated risk for the
project, and
b. the specific program to conform to the specified value and for project risk
mitigation.
I.2.3 Special remark
None.
64
ECSS-E-10 C Draft 1
6 August 2007
Annex J (normative)
Specification tree - DRD
<1> Introduction
The specification tree document shall contain a description of the purpose,
objective and the reason prompting its preparation.
65
ECSS-E-10 C Draft 1
6 August 2007
66
ECSS-E-10 C Draft 1
6 August 2007
Annex K (normative)
Design justification file - DRD
67
ECSS-E-10 C Draft 1
6 August 2007
<1> Introduction
The DJF shall contain a description of the purpose, objective, content and the
reason prompting its preparation.
68
ECSS-E-10 C Draft 1
6 August 2007
69
ECSS-E-10 C Draft 1
6 August 2007
70
ECSS-E-10 C Draft 1
6 August 2007
71
ECSS-E-10 C Draft 1
6 August 2007
72
ECSS-E-10 C Draft 1
6 August 2007
Annex L (normative)
Trade-off report - DRD
<1> Introduction
The trade-off report shall contain a description of the purpose, objective,
content and the reason prompting its preparation.
73
ECSS-E-10 C Draft 1
6 August 2007
<9> Conclusion
a. The trade-off report shall recommend one solution and explain the reason
for this choice (e.g. evaluation criteria where the selected solution take
advantage), and precise the condition for the application of the
recommended solution.
b. The trade-off report shall present the identified technical and
programmatic risks induced by the choice of the recommended solution, and
any additional activity necessary to be performed for risk mitigation.
L.2.3 Special remark
None.
74
ECSS-E-10 C Draft 1
6 August 2007
Annex M (normative)
Interface requirement document - DRD
<1> Introduction
The IRD shall contain a description of the purpose, objective, content and the
reason prompting its preparation.
75
ECSS-E-10 C Draft 1
6 August 2007
76
ECSS-E-10 C Draft 1
6 August 2007
Annex N (normative)
Requirements traceability matrix - DRD
<1> Introduction
The RTM shall contain a description of the purpose, objective, content and the
reason prompting its preparation.
77
ECSS-E-10 C Draft 1
6 August 2007
78
ECSS-E-10 C Draft 1
6 August 2007
Annex O (normative)
Requirements justification file - DRD
<4> Introduction
The RJF shall contain a description of the purpose, objective, content and the
reason prompting its preparation.
79
ECSS-E-10 C Draft 1
6 August 2007
80
ECSS-E-10 C Draft 1
6 August 2007
Annex P (normative)
Product user manual (PUM or UM) - DRD
<1> Introduction
The introduction shall describe the purpose and objective of the PUM.
81
ECSS-E-10 C Draft 1
6 August 2007
1. Handling,
2. Storage,
3. Installation,
4. Operations (nominal and contingency),
5. Maintenance,
6. Disposal.
b. The PUM shall consider potential consequences of the environment on
those sequences (e.g. sensor blinding, eclipses);
82
ECSS-E-10 C Draft 1
6 August 2007
b. The PUM shall describe the specific design features, transport and
environmental conditions, required GSE, and limitations for the handling
of the product.
<4.7> Storage
a. The PUM shall describe the conditions and procedures for the storage of the
product, be it integrated or stand-alone.
b. The PUM shall describe the specific design features, environmental
conditions, required GSE, monitoring requirements, life-limited items,
health maintenance procedures (activation, monitoring) and limitations for
the storage of the product.
<4.8> Installation
a. The PUM shall describe the conditions and procedures for the installation
of the product, be it integrated or stand-alone.
b. The PUM shall describe the specific design features, required GSE, modes,
environmental conditions, and limitations for the installation of the
product.
<4.9> Product operations
This shall include timelines, modes and procedures, constraints to operate the
product during its life cycle in nominal and contingency conditions, and
highlight critical operations.
NOTE 1 When the product is a space segment, the product
operations aspects are included in a specific part of the
UM called Flight Operations Manual (FOM).
NOTE 2 The implementation of the FOM by the ground segment
responsible organisation is contained in the Mission
Operation Plan (MOP, as defined in ECSS-E-70B Annex
G).
<4.9.1> Timelines
The PUM shall include:
a. Baseline event timelines for all nominal and contingency modes and
phases.
b. Related constraints.
c. Each timeline shall contain a detailed description (i.e. down to the level of
each single operational action) of the complete sequence of operations to be
carried out, including a description of the rationale behind the chosen
sequence of events, a definition of any constraints (e.g. absolute timing,
relative timing) and the interrelationships between operations in the
sequence.
<4.9.2> Product modes
a. The PUM shall describe all nominal and contingency modes, including:
1. their purpose (i.e. circumstances under which they are used),
2. the related procedures,
3. operational constraints,
4. resource utilization,
5. the definition of the associated modes, and
6. monitoring requirements.
b. The PUM shall describe the allowable mode transitions and the operations
procedure corresponding to each such transition.
83
ECSS-E-10 C Draft 1
6 August 2007
84
ECSS-E-10 C Draft 1
6 August 2007
85
ECSS-E-10 C Draft 1
6 August 2007
b. product constituent modes shall be defined for all distinct nominal and
back-up modes of the subsystem including:
1. purpose (i.e. conditions under which each shall be used);
2. operational constraints;
3. resource utilization;
4. the definition of the associated modes for each product constituent and
its software functions;
5. higher level monitoring requirements.
6. identification of the allowable mode transitions and any product
constituent operational constraints.
c. Nominal operational procedures shall be defined for each nominal mode
transition identified under <5.7> b.6.
d. For each procedure described in <5.7> c, the following shall be provided:
1. an introduction describing the purpose of the procedure and the
phase(s) or conditions when applicable;
2. the body of the procedure, structured according to operational steps,
including:
(a) pre-conditions for the start of the step defining, where applicable:
∗ product or product constituent level pre-requisites (e.g.
configuration and resource requirements, such as power, fuel);
∗ external interfacing products pre-requisites;
(b) telecommands to be sent;
(c) telemetry data to be monitored to verify correct execution of the
step;
(d) interrelationships between steps (e.g. conditional branching
within the procedure, timing requirements or constraints, hold
and check points);
(e) conditions for completion of the step.
e. Contingency procedures shall be defined for each failure case identified in
the product constituent failure analysis (FMECA/FTA).
NOTE This can utilize a nominal operational procedure already
identified in <5.7> c. above.
f. For contingency procedures, the same details shall be provided as for
nominal operational procedures in d. above.
g. Where the recovery method for a failure or group of failures is mode,
mission, or phase dependent, separate procedures shall be described for
each mode/mission phase.
<5.8> Product component data definition
h. For each operational mode of the product constituent, sensor output data,
conditions under which they are generated, their contents, and data rate
shall be described.
i. Required on-board processing performed on sensor data and algorithms
used for this shall be described.
P.2.3 Special remarks
Where the objective is to allow for the accommodation of equipment designed a
posteriori w.r.t an existing platform or vehicle, the following documents shall be
part of the UM:
a. Accommodation handbook
86
ECSS-E-10 C Draft 1
6 August 2007
87
ECSS-E-10 C Draft 1
6 August 2007
88
ECSS-E-10 C Draft 1
6 August 2007
Annex Q (normative)
Analysis report – DRD
<1> Introduction
a. The analysis report shall contain a description of the purpose, objective,
content and the reason prompting its preparation.
b. Any open issue, assumption and constraint relevant to this document shall
be stated and described.
89
ECSS-E-10 C Draft 1
6 August 2007
<8> Conclusions
The analysis report shall:
a. summarize the analysis results,
b. summarise the conditions of validity of this analysis, and
c. clearly state and describe any open issue.
NOTE Where the analysis report is used for the verification of a
requirement (in correlation with a VCD) it shall clearly
indicate the requirement verification closeout status.
Q.2.3 Special remarks
None.
90
ECSS-E-10 C Draft 1
6 August 2007
Bibliography
91