EN 16603-10:2018
(Main)Space engineering - System engineering general requirements
Space engineering - System engineering general requirements
This standard specifies the system engineering implementation requirements for space systems and space products development.
Specific objectives of this standard are:
- to implement the system engineering requirements to establish a firm technical basis and to minimize technical risk and cost for space systems and space products development;
- to specify the essential system engineering tasks, their objectives and outputs;
- to implement integration and control of engineering disciplines and lower level system engineering work;
- to implement the "customer-system-supplier mode" through the development of systems and products for space applications.
Depending of the product category, the application of this standard needs to be checked and if needed tailored. The pre-tailoring table in clause 7 contains the applicability of the requirements of this document and its annexes according to product type. Specific requirements related to system engineering, like technical specification, verification, and testing are specified in dedicated documents and standards within the set of ECSS system engineering standards ECSS-E-ST-10-XX.
Discipline or element specific engineering implementation requirements are covered in dedicated ECSS standards. These standards are based on the same principles, process and documentation model. The applicability of each these standards can therefore not be considered in isolation from the others.
NOTE 1 The term "Discipline" is defined in ECSS-M-ST-10, as "a specific area of expertise within a general subject". The name of the discipline normally indicates the type of expertise, e.g. in the ECSS system mechanical engineering, software and communications are disciplines within the engineering domain.
NOTE 2 The requirements on the system engineering process are gathered in this standard; specific aspects of the SE process are further elaborated in dedicated standards.
For engineering process both for SW and for Ground Segment and Operations the following standards are considered fully sufficient for development of these items:
- ECSS-E-ST-70 Space engineering - Ground systems and operations
- ECSS-E-ST-40 Space engineering - Software
- ECSS-Q-ST-80 Space product assurance - Software product assurance
This standard may be tailored for the specific characteristic and constrains of a space project in conformance with ECSS-S-ST-00.
Raumfahrttechnik - Allgemeine Anforderungen an das Systemengineering
Ingénierie spatiale - Exigences générales d'ingénierie système
La présente Norme expose les exigences de mise en oeuvre de l’ingénierie système pour le développement des systèmes et des produits spatiaux.
Les objectifs précis de la présente Norme sont les suivants :
- appliquer les exigences d’ingénierie système pour créer une base technique solide et minimiser les coûts et les risques techniques pour le développement des systèmes et des produits spatiaux ;
- définir les principales tâches d’ingénierie système, leurs objectifs et leurs résultats ;
- mettre en oeuvre l’intégration et le contrôle des disciplines d’ingénierie, ainsi que les travaux d’ingénierie système de niveau inférieur ;
- mettre en oeuvre le « modèle client-système-fournisseur » à travers le développement de systèmes et de produits pour les applications spatiales.
En fonction de la catégorie de produit, il faut vérifier si la présente norme doit être appliquée et si besoin adaptée. Le tableau de préadaptation de l’article 7 présente l’applicabilité des exigences du présent document et de ses annexes selon le type de produit. Les exigences spécifiques relatives à l’ingénierie système, telles que les spécifications techniques, la vérification et les essais, sont spécifiées dans des documents et normes dédiés de la série ECSS-E-ST-10-XX, relative à l’ingénierie système de l’ECSS.
Les exigences de mise en oeuvre de l’ingénierie propres à chaque discipline ou à chaque élément sont décrites dans les normes ECSS associées. Ces normes se fondent sur les mêmes principes, les mêmes processus et le même modèle de documentation. L’applicabilité de chacune de ces normes ne peut donc être envisagée de manière indépendante.
NOTE 1 Le terme « Discipline » est défini dans l’ECSS-M-ST-10 comme étant une « spécialité entrant dans le cadre d’un sujet général ». Le nom de la discipline indique généralement le type d’expertise auquel elle est associée ; par exemple, dans le système ECSS, l’ingénierie mécanique, les logiciels et les communications sont des disciplines du domaine de l’ingénierie.
NOTE 2 Les exigences relatives au processus d’ingénierie système sont réunies dans cette norme ; les aspects spécifiques au processus d’ES sont décrits de façon plus détaillée dans des normes dédiées.
En matière de processus d’ingénierie relatif aux logiciels ainsi qu’au segment sol et aux opérations, les normes suivantes sont considérées comme étant amplement suffisantes pour le développement de ces articles :
- ECSS-E-ST-70 Ingénierie spatiale - Systèmes sol et opérations
- ECSS-E-ST-40 Ingénierie spatiale - Logiciels
- ECSS-Q-ST-80 Assurance produit des projets spatiaux - Assurance produit logiciel
La présente Norme peut être adaptée aux caractéristiques et contraintes spécifiques d’un projet spatial, conformément à l’ECSS-S-ST-00.
Vesoljska tehnika - Sistemskotehnične splošne zahteve
Ta standard določa zahteve za izvajanje sistemskega inženiringa za vesoljske sisteme in razvoj vesoljskih izdelkov. Namen tega standarda je zlasti: • izvajanje zahtev za sistemski inženiring z namenom zagotavljanja trdne tehnične podlage in zmanjševanja tehničnih tveganj in stroškov vesoljskih sistemov ter razvoja vesoljskih izdelkov; • določanje bistvenih nalog sistemskega inženiringa ter njihovih ciljev in rezultatov; • izvajanje povezovanja in nadzora nad različnimi inženirskimi disciplinami in dela v zvezi s sistemskim inženiringom na nižji ravni; • izvajanje »modela odjemalec-sistem-dobavitelj« s pomočjo razvoja sistemov in izdelkov za vesoljske aplikacije. Ta standard je namenjen za uporabo pri vseh vesoljskih sistemih in izdelkih, na kateri koli ravni razstavljanja sistema, vključno s strojno opremo, programsko opremo, postopki, modeli z vključitvijo človeka, objekti in storitvami. V celotnem dokumentu in njegovih dodatkih zahteve kot take veljajo samo za kompleksne sisteme; za elemente nižje ravni je potrebna prilagoditev. Posebne zahteve v zvezi s sistemskim inženiringom, kot so tehnične specifikacije, preverjanje in preskušanje, določajo namenski dokumenti in standardi v sklopu standardov ECSS za sistemski inženiring ECSS-E-ST-10-XX. Zahteve za izvajanje inženiringa, vezanega na discipline ali elemente, so zajete namenskih standardih ECSS. Navedeni standardi temeljijo na enakih načelih, procesu in modelu dokumentiranja. Zato uporabnosti posameznega standarda ni mogoče presojati ločeno od ostalih standardov. Dokument ECSS-E-HB-10 »Smernice za sistemski inženiring« vsebuje smernice, ki se navezujejo na ta standard, vključno z opisom postopka inženiringa za vesoljski sistem in njegove izdelke. OPOMBA 1: izraz »disciplina« je v standardu ECSS-M-ST-10 opredeljen kot »določeno strokovno področje v okviru splošne tematike«. Iz imena discipline je običajno razvidna vrsta strokovnega znanja, npr. v okviru mehanskega inženiringa sistema ECSS sta programska oprema in komunikacije disciplini s področja inženiringa. OPOMBA 2: v tem standardu so zajete zahteve za postopek sistemskega inženiringa; posebni vidiki postopka sistemskega inženiringa so natančneje določeni v namenskih standardih. Ta standard se lahko prilagodi posameznim lastnostim in omejitvam vesoljskega projekta v skladu s standardom ECSS-S-ST-00.
General Information
Relations
Standards Content (Sample)
SLOVENSKI STANDARD
01-julij-2018
1DGRPHãþD
SIST EN 13292:2000
SIST EN 14514:2005
SIST EN 14607-7:2005
9HVROMVNDWHKQLND6LVWHPVNRWHKQLþQHVSORãQH]DKWHYH
Space engineering - System engineering general requirements
Raumfahrttechnik - Grundsätze und Verfahrensweise
Ta slovenski standard je istoveten z: EN 16603-10:2018
ICS:
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.
EUROPEAN STANDARD
EN 16603-10
NORME EUROPÉENNE
EUROPÄISCHE NORM
April 2018
ICS 49.140
Supersedes EN 13292:1999, EN 14514:2004, EN
14607-7:2004
English version
Space engineering - System engineering general
requirements
Ingénierie spatiale - Exigences générales d'ingénierie Raumfahrttechnik - Grundsätze und Verfahrensweise
système
This European Standard was approved by CEN on 21 August 2017.
CEN and CENELEC members are bound to comply with the CEN/CENELEC Internal Regulations which stipulate the conditions for
giving this European Standard the status of a national standard without any alteration. Up-to-date lists and bibliographical
references concerning such national standards may be obtained on application to the CEN-CENELEC Management Centre or to
any CEN and CENELEC member.
This European Standard exists in three official versions (English, French, German). A version in any other language made by
translation under the responsibility of a CEN and CENELEC member into its own language and notified to the CEN-CENELEC
Management Centre has the same status as the official versions.
CEN and CENELEC members are the national standards bodies and national electrotechnical committees of Austria, Belgium,
Bulgaria, Croatia, Cyprus, Czech Republic, Denmark, Estonia, Finland, Former Yugoslav Republic of Macedonia, France, Germany,
Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Romania,
Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland, Turkey and United Kingdom.
CEN-CENELEC Management Centre:
Rue de la Science 23, B-1040 Brussels
© 2018 CEN/CENELEC All rights of exploitation in any form and by any means Ref. No. EN 16603-10:2018 E
reserved worldwide for CEN national Members and for
CENELEC Members.
Table of contents
European Foreword . 5
1 Scope . 7
2 Normative references . 9
3 Terms, definitions and abbreviated terms . 10
3.1 Terms from other standards . 10
3.2 Terms specific to the present standard . 10
3.3 Abbreviated terms. 11
4 Overview of system engineering . 14
4.1 The system engineering discipline . 14
4.2 The system engineering process . 18
4.3 Overview of system engineering tasks per project phase. 19
4.3.1 Overview . 19
4.3.2 General . 19
4.3.3 Phase 0 Overview: Mission analysis-need identification . 20
4.3.4 Phase A Overview: Feasibility . 20
4.3.5 Phase B Overview: Preliminary definition . 20
4.3.6 Phase C Overview: Detailed definition . 21
4.3.7 Phase D Overview : Qualification and production . 21
4.3.8 Phase E Overview: Operations / utilization . 21
4.3.9 Phase F Overview: Disposal . 21
5 General requirements. 23
5.1 System engineering plan . 23
5.2 Requirement engineering . 24
5.2.1 General . 24
5.2.2 Requirement traceability. 24
5.2.3 Requirement engineering process . 25
5.3 Analysis . 27
5.3.1 System analysis . 27
5.3.2 System environments and design and test factors . 28
5.3.3 Trade-off analyses . 28
5.3.4 Analysis methods, tools and models . 29
5.4 Design and configuration . 30
5.4.1 Design . 30
5.4.2 Configuration . 31
5.5 Verification . 32
5.5.1 General . 32
5.5.2 Product verification. 32
5.6 System engineering integration and control . 33
5.6.1 Management of system engineering activities . 33
5.6.2 Planning . 33
5.6.3 Engineering data . 33
5.6.4 Interface control . 34
5.6.5 Coordinate systems and units . 34
5.6.6 Technical budgets and margin policy . 34
5.6.7 Technology . 34
5.6.8 Risk management . 35
5.6.9 Changes and nonconformances control . 35
6 <> . 36
7 Pre-tailoring matrix per space product types . 37
Annex A (informative) System engineering documents delivery per review . 51
Annex B (normative) Mission description document (MDD) – DRD . 55
Annex C (normative) System concept report – DRD . 59
Annex D (normative) System engineering plan (SEP) – DRD . 60
Annex E (normative) Technology plan (TP) – DRD . 69
Annex F (normative) Technology matrix - DRD . 73
Annex G (normative) Design definition file (DDF) - DRD . 75
Annex H (normative) Function tree - DRD . 80
Annex I (normative) Technical budget - DRD . 82
Annex J (normative) Specification tree - DRD . 84
Annex K (normative) Design justification file (DJF) - DRD . 86
Annex L (normative) Trade-off report - DRD . 93
Annex M (normative) <> . 96
Annex N (normative) Requirements traceability matrix (RTM) - DRD . 97
Annex O (normative) Requirements justification file (RJF) - DRD . 99
Annex P (normative) Product user manual (PUM or UM) - DRD . 102
Annex Q <> . 110
Annex R (informative) Mapping of typical DDP to ECSS documents . 111
Annex S (informative) Guideline content of Analysis Report . 113
Bibliography . 115
Figures
Figure 4-1: System engineering, sub-functions and boundaries . 16
Figure 4-2: System engineering sub-functions inter-relationships . 17
Figure B-1 : Relationship between documents . 56
Figure E-1 : TRSL template . 72
Tables
Table A-1 : System engineering deliverable documents . 52
European Foreword
This document (EN 16603-10:2018) has been prepared by Technical Committee CEN-CENELEC/JTC 5
“Space”, the secretariat of which is held by DIN.
This standard (EN 16603-10:2018) originates from ECSS-E-ST-10C Rev.1.
This European Standard shall be given the status of a national standard, either by publication of an
identical text or by endorsement, at the latest by October 2018, and conflicting national standards shall
be withdrawn at the latest by October 2018.
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 supersedes EN 13292:1999, EN 14514:2004 and EN 14607-7:2004.
The main changes with respect to EN 13292:1999, EN 14514:2004 and EN 14607-7:2004 are:
• The main driver for the changes in this issue of the standard comes from the intention to include in
this document only requirements and remove all informative material related to the process for
inclusion in a future handbook.
• Inclusion of EN 16603-11 (ECSS-E-AS-11) "Adoption Notice of ISO 16290, Space systems -
Definition of the Technology Readiness Levels (TRLs) and their criteria of assessment" as
Normative Reference.
• Former clause 5 “System engineering process”, replaced by a brief overview of the project phases
and related system engineering tasks in the current clause 4.3 “Overview of system engineering
tasks per project phase”.
• Former Clause 4 split into an introductory clause 4 “Overview of Systems engineering” and clause
5 “General Requirements”.
• Clause 7 "Pre-tailoring matrix per space product types" added
• The remaining requ irements have been reworded for readability and consistency. Repetition of
requirements included in other related standards have been eliminated.
• Regarding the documentation model, the only significant modification originates in the
simplification of the concept of Functional Specification and Technical Specification. In EN 16603-
10-06 only one specification, the technical requirements specification (customer specification), is
considered. This is reflected in this standard, as explained in clause 5.2.3.1
• Annex A: System engineering documents delivery per review: This annex replaces and expands
old Annex B. It includes the listing of the main documents per phase of the project development
indicating when the document needs to be available.
• Document Requirements Descriptions (DRD) added in several Annexes that include all the project
documents pertinent to this standard. In the previous issue the DRDs were not included.
• Annex R: Mapping of typical DDP to ECSS documents: This is an addition with respect to the
previous issue. It presents where specific subjects contained in the previously used Design and
Development Plan are located in the new set of ECSS documents.
This document has been prepared under a standardization request 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 EN covering the same scope but with a wider domain of applicability (e.g. : aerospace).
According to the CEN-CENELEC Internal Regulations, the national standards organisations of the
following countries are bound to implement this European Standard: Austria, Belgium, Bulgaria,
Croatia, Cyprus, Czech Republic, Denmark, Estonia, Finland, Former Yugoslav Republic of
Macedonia, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania,
Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Romania, Serbia, Slovakia, Slovenia,
Spain, Sweden, Switzerland, Turkey and the United Kingdom.
Scope
This standard specifies the system engineering implementation requirements
for space systems and space products development.
Specific objectives of this standard are:
• to implement the system engineering requirements to establish a firm
technical basis and to minimize technical risk and cost for space systems
and space products development;
• to specify the essential system engineering tasks, their objectives and
outputs;
• to implement integration and control of engineering disciplines and
lower level system engineering work;
• to implement the “customer-system-supplier model” through the
development of systems and products for space applications.
Depending of the product category, the application of this standard needs to be
checked and if needed tailored. The pre-tailoring table in clause 7 contains the
applicability of the requirements of this document and its annexes according to
product type. Specific requirements related to system engineering, like technical
specification, verification, and testing are specified in dedicated documents and
standards within the set of ECSS system engineering standards ECSS-E-ST-10-XX.
Discipline or element specific engineering implementation requirements are
covered in dedicated ECSS standards. These standards are based on the same
principles, process and documentation model. The applicability of each these
standards can therefore not be considered in isolation from the others.
NOTE 1 The term “Discipline” is defined in ECSS-M-ST-10, as “a
specific area of expertise within a general subject”. The
name of the discipline normally indicates the type of
expertise, e.g. in the ECSS system mechanical
engineering, software and communications are
disciplines within the engineering domain.
NOTE 2 The requirements on the system engineering process are
gathered in this standard; specific aspects of the SE
process are further elaborated in dedicated standards.
For engineering process both for SW and for Ground Segment and Operations
the following standards are considered fully sufficient for development of these
items:
• ECSS-E-ST-70 Space engineering - Ground systems and operations
• ECSS-E-ST-40 Space engineering - Software
• ECSS-Q-ST-80 Space product assurance - Software product assurance
This standard may be tailored for the specific characteristic and constrains of a
space project in conformance with ECSS-S-ST-00.
Normative references
The following normative documents contain provisions which, through
reference in this text, constitute provisions of this ECSS Standard. For dated
references, subsequent amendments to, or revision of any of these publications
do not apply, However, parties to agreements based on this ECSS Standard are
encouraged to investigate the possibility of applying the more recent editions of
the normative documents indicated below. For undated references, the latest
edition of the publication referred to applies.
EN reference Reference in text Title
EN 16601-00-01 ECSS-S-ST-00-01 ECSS system - Glossary of terms
EN 16603-11 ECSS-E-AS-11 Adoption Notice of ISO 16290, Space systems - Definition
of the Technology Readiness Levels (TRLs) and their
criteria of assessment
EN 16603-10-02 ECSS-E-ST-10-02 Space engineering – Verification
EN 16603-10-06 ECSS-E-ST-10-06 Space engineering – Technical requirements specification
EN 16603-10-09 ECSS-E-ST-10-09 Space engineering – Reference coordinate system
EN 16603-10-24 ECSS-E-ST-10-24 Space engineering – Interface control
EN 16601-10 ECSS-M-ST-10 Space project management – Project planning and
implementation
EN 16601-40 ECSS-M-ST-40 Space project management – Configuration and
information management
EN 16602-10 ECSS-Q-ST-10 Space product assurance - Product assurance
management
EN 16602-10-09 ECSS-Q-ST-10-09 Space product assurance - Nonconformance control
system
EN 16602-20-10 ECSS-Q-ST-20-10 Off-the-shelf items utilization in space systems
Terms, definitions and abbreviated terms
3.1 Terms from other standards
a. For the purpose of this Standard, the terms and definitions from ECSS-S-
ST-00-01 apply, in particular for the following terms:
1. acceptance
2. approval
3. configuration baseline
4. critical
5. development
6. equipment
7. inspection
8. integration
9. mission statement
10. product tree
11. requirement
12. specification
13. subsystem
14. system
15. test
16. verification
b. For the purpose of this Standard, the terms and definitions from ECSS-E-
AS-11 apply, in particular for the following terms:
1. technology readiness level
3.2 Terms specific to the present standard
3.2.1 requirement traceability
requirement attribute that links each single requirement to its higher level
requirements inside the requirement set
1 to entry: This enables the derivation of a requirement
tree, which demonstrates the coherent flow-down of the
requirements.
3.2.2 recurring product
product which conforms to a qualified design and is produced according to the
corresponding production master file
3.2.3 system engineering
interdisciplinary approach governing the total technical effort required to
transform requirements into a system solution
1 to entry: From IEEE P1220.
3.2.4 verification matrix
initial issue of the VCD which contains for each requirement to be verified the
methods, levels and stages of product verification
1 to entry: See ECSS-E-ST-10-02 for a more detailed
definition of the VCD.
3.3 Abbreviated terms
For the purpose of this Standard, the abbreviated terms from ECSS-S-ST-00-01
and the following apply:
Abbreviation Meaning
assembly, integration and test
AIT
assembly, integration and verification plan
AIV plan
attitude and orbit control sub-system
AOCS
acceptance review
AR
critical design review
CDR
commercial off-the-shelf
COTS
commissioning results review
CRR
NOTE For space vehicles (e.g. launcher, transfer vehicle,
crew transport vehicle) the CRR can be replaced or
complemented by a flight qualification review
(FQR).
design definition file
DDF
design development plan
DDP
design justification file
DJF
document requirements definition
DRD
European Cooperation for Space Standardization
ECSS
end-of-life review
ELR
failure, detection, isolation, recovery
FDIR
Abbreviation Meaning
flight model
FM
failure modes, effects, and criticality analysis
FMECA
flight operations manual
FOM
flight readiness review
FRR
fault tree analysis
FTA
ground support equipment
GSE
human-in-the-loop
HITL
interface control document
ICD
integrated logistic support
ILS
interface requirement document
IRD
launch readiness review
LRR
mission closed-out review
MCR
mission description document
MDD
mission definition review
MDR
mission operations plan
MOP
mission statement
MS
operational readiness review
ORR
preliminary design review
PDR
project management plan
PMP
parts materials and processes
PM&P
preliminary requirement review
PRR
product user manual
PUM
qualification review
QR
reliability, availability, maintainability, safety
RAMS
risk assessment report
RAR
radio frequency
RF
requirement justification file
RJF
review of design
ROD
read only memory / random access memory
ROM/RAM
requirement traceability matrix
RTM
research and development
R&D
system engineering
SE
system engineering plan
SEP
system functional test
SFT
system requirement review
SRR
system validation test
SVT
Abbreviation Meaning
technology plan
TP
technology readiness assessment
TRA
technology readiness level
TRL
technology readiness status list
TRSL
technical requirements specification
TS
user manual
UM
verification control document
VCD
verification plan
VP
with respect to
w.r.t.
Overview of system engineering
4.1 The system engineering discipline
System engineering is an interdisciplinary approach governing the total
technical effort to transform requirements into a system solution.
A system is an integrated set of elements to accomplish a defined objective.
These elements include hardware, software, firmware, human resources,
information, techniques, facilities services, and other support elements.
In this standard the concept of “system” is used in a wide sense. The highest
level, often called “mission level” or “space system”, consists usually of one (or
more) space segment(s), of a ground segment, and of a user segment. Elements
of system decomposition are also considered a system. For the purpose of this
standard the system can be any element at any level of decomposition as
defined by the function tree (see Annex H) or the product tree (see ECSS-M-ST-
10 Annex B). The scope of an element can include hardware, software,
procedures, man-in-the-loop, facilities and services.
From the perspective of the considered system, requirements originate from the
next upper level (the customer) and elements are procured from the next lower
level (the suppliers).
NOTE 1 The customer-supplier model is described in
ECSS-S-ST-00.
NOTE 2 Through this standard the notion of customer
refers to several actors ,in relation to the project
phase. In fact a customer can be e.g. a scientific
community in phase 0, a commercial user in
phase A or an Agency in phase B. A supplier can
on the other hand be an Agency in both phase 0
and phase A.
Figure 4-1 shows the boundaries of system engineering (for which the indicated
interactions between the identified major disciplines is not exhaustive but
indicative), its relationship with production, operations, product assurance and
management disciplines (and their cross-interaction is indicated as “interface
areas” in the figure) and its internal partition into the following system
engineering sub-functions:
• requirement engineering, which consist on requirement analysis and
validation, requirement allocation, and requirement maintenance;
• analysis, which is performed for the purpose of resolving requirements
conflicts, decomposing and allocating requirements during functional
analysis, assessing system effectiveness (including analysing risk factors);
and complementing testing evaluation and providing trade studies for
assessing effectiveness, risk, cost and planning;
• design and configuration which results in a physical architecture, and its
complete system functional, physical and software characteristics;
• verification, which objective is to demonstrate that the deliverables
conform to the specified requirements, including qualification and
acceptance;
• system engineering integration and control, coordinating the various
engineering disciplines and participants throughout all the project
phases.
Figure 4-2 shows system engineering sub-functions, their inter-relationships
and their main activities during the system engineering process.
System engineering sub-functions are applied in an iterative mode during
implementation of the system engineering process described in clause 4.2.
Within the frame of a project, the system engineering function is generally
implemented by a system engineering organisation of the supplier which is in
charge of transforming the requirements of the customer into a system solution
delivered by the supplier. For the purpose of this standard, the ‘system
engineering function’ only is referred to in the normative statements,
independent of whether the supplier has a formal ‘system engineering
organisation’ or not.
NOTE With respect to the next lower level, the
supplier plays the role of the customer.
Figure 4-1: System engineering, sub-functions and boundaries
Management
- Cost
- Planning
- Configuration control
- Procurement
- Information
- Documentation
- Schedule
SYSTEM ENGINEERING INTEGRATION AND CONTROL
- Product
assurance
- Dependability
- Verification
ANALYSIS
- Procurement
- Development
- Criticality
- AIT
analysis
REQUIREMENTS
DESIGN AND
- PM&P
ENGINEERING
CONFIGURATION
- Safety
- EEE component
- SW PA
VERIFICATION & VALIDATION
SYSTEM
ENGINEERING
- Operations Engineering
- Operations Verification
- Logistic Analysis
Production
Product
Assurance
Operations and Logistics
= Interface Area
= System Engineering Scope = Other Programme Disciplines
AIT = assembly, integration and test SW PA = Software Product Assurance
PM&P = parts, materials and processes
Plans and Data
Plans and Data
Plans and Data
Figure 4-2: System engineering sub-functions inter-relationships
System Engineering Data Base
Technical Plans
System Engineering Tools and Models
Integration and Control
System Analysis
System Analysis
System Analysis
Analysis
Requirement Functional Analysis Design and
Engineering and allocation configuration
Customer input
Requirement Engineering
Design and configuration
Functional Product Qualified product design
Requirements
Verification Verification
Verification
Verification
4.2 The system engineering process
The system engineering activities of a project are conducted by an entity or
resources within the project team of a supplier. This entity or the resources that
perform this function is called in this document “system engineering function”.
The system engineering process is in turn applied by each system engineering
function of each supplier of the elements of the product decomposition.
The system engineering process consists of activities to be performed by the
system engineering function within each project phase according to the
designated lifecycle model. The objective is to obtain a product which satisfies
the customer technical requirements within pre-established objectives of cost,
time and quality. The requirements for these activities are described in clause 5.
The system engineering process is intrinsically iterative across the whole life of
a project, in particular in the initial phases (i.e. 0, A, and B) of the development
of a complex system (e.g. a spacecraft), procured through a multi-layered set of
suppliers.
During these phases, the system engineering function derives design oriented
technical solutions starting from the design-independent customer
requirements contained in a technical requirements specification (TS). This is
achieved through an iterative top-down process by trading off several design
solutions at an increasing level of detail.
NOTE For definition and requirements for a technical
requirements specification see ECSS-E-ST-10-06.
Through this process the system engineering function performs a
multidisciplinary functional decomposition to obtain logical lower level
products (both hardware and software). At the same time the system
engineering function decides on balanced allocations, throughout the system, of
resources allocated by the customer and respects agreed margin philosophies as
a function of the relevant technology readiness levels.
The functional decomposition defines, for each level of the system, the technical
requirements for the procurement of subassemblies or lower level products as
well as the requirements for the verification of the final characteristics of each
product.
The system engineering process uses the results of these lower level verification
activities to build a bottom-up multi-layered evidence that the customer
requirements have been met.
The system engineering process is applied with various degrees of depth
depending on the level of maturity of the product (e.g. new development or off-
the-shelf).
The system engineering process can be applied with different level of tailoring
as agreed between customer and supplier in their business agreement.
The system engineering function has interfaces with those other functions in
charge of management, product assurance, engineering disciplines, production,
and operations and logistics.
NOTE The project phases are defined in ECSS-M-ST-
10.
4.3 Overview of system engineering tasks per project
phase
4.3.1 Overview
The allocation of specific system engineering requirements per phase depends
strongly on the type of business agreement established between customer and
supplier and the nature and level of complexity of the system subject of the
agreement. The breakdown and the details of the tasks are defined in the
business agreement specific documents.
NOTE Some projects define them in a Statement of
work (SoW).
The actors in the customer-supplier relationship change between phases and
across levels. In the following clauses each system engineering function is
meant to be the supplier’s system engineering function during that phase.
4.3.2 General
a. The system engineering function plans its activities in conformance with
the project phases as defined in the Project Management Plan in
accordance with ECSS-M-ST-10 and document it in the SEP as per Annex
D.
NOTE The phases or combination thereof to be
implemented for a project are specified in the
business agreement.
b. The system engineering function monitors the execution of all system
engineering activities including lower levels.
c. The system engineering function identifies the critical items in
cooperation with the Product Assurance (PA) according to ECSS-Q-ST-10
(PA being tasked to manage the critical items throughout the project life).
d. The system engineering function ensures that for critical items the
technical requirements specification, the design definition file and the
design justification file are available at latest by end of Phase B .
NOTE Information regarding the expected delivery of
system engineering documents for each project
review is provided in 7.
The documents to be approved by the customer
as well as the time of their approval are listed in
the business agreement.
e. The system engineering function activities need to be aligned with
Product Assurance (PA) activities according to ECSS-Q-ST-10 throughout
the project life. This includes definition and execution of tasks in which
PA activities are involved (detailed in the Product Assurance Plan).
4.3.3 Phase 0 Overview: Mission analysis-need
identification
a. For Phase 0, the system engineering function
1. supports the identification of customer needs.
2. proposes possible system concepts.
3. supports the Mission Definition Review (MDR) and ensures
implementation of the MDR actions.
4. performs an analysis of the Mission Statement document, and
integrates this analysis and any relevant contribution from lower
level suppliers in to a Mission Description document(s) in
conformance with Annex B, and maintains this latter document for
the final selected concept.
5. proposes the requirements against the expressed user needs for
agreement with the customer.
NOTE Mission Statement captures the declared “user
needs”.
4.3.4 Phase A Overview: Feasibility
a. For Phase A, the system engineering function
1. finalises the expression of the needs identified in Phase 0.
2. proposes system solutions (including identification of critical items
and risks) to meet the customer needs.
3. supports the Preliminary Requirement Review (PRR) and ensure
implementation of PRR actions.
4. finalises the validation of the requirements against the expressed
needs together with the customer.
NOTE Mission Statement captures the declared “user
needs”.
4.3.5 Phase B Overview: Preliminary definition
a. For Phase B, the system engineering function
1. establishes the system preliminary definition for the system
solution selected at end of Phase A.
2. demonstrates that the solution meets the technical requirements
according to the schedule, the target cost and the customer
requirements.
3. supports the System Requirements Review (SRR) and Preliminary
Design Review (PDR), and ensuring implementation of the SRR
and PDR actions.
4. define development approach and plan of engineering activities.
4.3.6 Phase C Overview: Detailed definition
a. For Phase C, the system engineering function
1. establishes the system detailed definition.
2. demonstrates the capability to meet the technical requirements of
the system technical requirements specification.
3. supports the Critical Design Review (CDR) and ensures
implementation of the CDR actions.
4.3.7 Phase D Overview : Qualification and
production
a. For Phase D, the system engineering function
1. finalizes the development of the system by qualification and
acceptance.
2. finalizes the preparation for operations and utilization.
3. supports Qualification Review (QR) and Acceptance Review (AR)
and ensures implementation of the QR and AR actions.
4.3.8 Phase E Overview: Operations / utilization
a. For Phase E, the system engineering function
1. supports the launch campaign.
2. supports the entity in charge of the operations and utilization
following the terms of a business agreement.
3. supports the Flight Readiness Review (FRR), Operations Readiness
Review (ORR), Launch Readiness Review (LRR), Commissioning
Results Review (CRR), End-of-Life Review (ELR), and recurring
products AR, and ensure implementation of the actions of those
reviews.
4. supports the execution of all system engineering activities and
provision of documents in support to anomaly investigations and
resolutions.
NOTE Phase E and its reviews as presented in Table
A-1 refer only to mission level. In case of lower
level product, activities to be considered by the
system engineering function are only related to
maintenance and anomaly investigations.
4.3.9 Phase F Overview: Disposal
a. For Phase F, the system engineering function
1. supports the entity in charge of the disposal following the terms of
a business agreement.
2. supports the Mission Close-out Review (MCR) and ensure
implementation of the actions of the MCR.
NOTE Phase F and its review as presented in Table A-
1 refer only to mission level. In case of lower
level product, activities to be considered by the
system engineering function are only related to
disposal.
General requirements
5.1 System engineering plan
a. The system engineering function shall produce and maintain a system
engineering plan (SEP) in conformance with Annex D.
NOTE The system engineering function establishes the
SEP with the contributions and constraints of
management, product assurance, engineering
disciplines, production, and operations and
logistics.
b. <>
c. The SEP shall take consideration of the lower level plans, ensure
consistency between these plans, and, be consistent with these plans.
NOTE 1 The early version of the Project Management
Plan (PMP), which includes the early version of
the SEP, contains all the information which was
traditionally contained in the Design and
Development Plan (DDP). See Annex R which
illustrates the mapping between a typical DDP
and ECSS DRDs.
NOTE 2 The SEP content evolves with the phase of the
project, with more information on risk analysis
and new technologies in early phases 0, A and
B, and more information on verification and
validation aspects in phases C, D.
NOTE 3 The SEP can be considered a collection of
documents delivered over the life-cycle as
illustrated in Table A-1.
NOTE 4 No SEP lower than equipment/unit.
d. The system engineering function shall support the project manager in the
project reviews as defined in the Project Management Plan in accordance
with ECSS-M-ST-10.
5.2 Requirement engineering
5.2.1 General
a. The system engineering function shall analyse the requirements for the
system issued by the customer.
NOTE 1 This analysis enables the transformation of
customer requirements into the supplier’s
system solution.
NOTE 2 The level of the required analysis and form of
any deliverable is expressed in the business
agreement.
b. The system engineering function shall derive, generate, control and
maintain the set of requirements for the lower level elements, defining
their design and operational constraints and the parameters of
functionality, performance, and verification necessary to meet the system
requirements issued by the customer.
c. The system engineering function shall ensure consistency of the
requirements at system level, at lower levels, as well as amongst levels.
NOTE Consistency of requirements of different system
engineering sub-functions at the same level is
the responsibility of the higher level system
engineering function.
d. The system engineering function shall ensure requirements generated in
5.2.1b. are in conformance with characteristics specified in ECSS-E-ST-10-
06 clause 8.
e. The system engineering function shall ensure that each requirement for
the lower level elements has a justification reflected in the requirement
justification file in conformance with Annex O.
NOTE Tailoring of a standard in a list of applicable
standards, or of a requirement in an applicable
standard, is possible where each tailoring
measure is duly justified.
5.2.2 Requirement traceability
a. The system engineering function shall ensure forward and backward
traceability of all requirements:
1. to their sources;
2. to the lower level requirements, if existing;
3. to changes in the design inducing modifications of the
requirements;
4. to their verification close-out.
NOTE to item 1: Examples for sources: a higher level
requirement, an imposed management
constraint, an applicable standard or an
accepted lower level constraint.
b. The system engineering function shall establish and maintain the
requirements traceability matrix in conformance with Annex N.
c. The system engineering function shall ensure that the requirement close-
out traceability is documented in the VCD in conformance with ECSS-E-
ST-10-02 Annex B.
5.2.3 Requirement engineering process
5.2.3.1 Technical requirements specifications
a. The system engineering function shall establish technical requirements
specifications of the next lower level products consistent among them
and with the technical specification received from the customer.
b. The system engineering function shall ensure that the technical
requirements specifications it establishes conform to ECSS-E-ST-10-06
and its DRD in Annex A.
c. The system engineering function shall establish a specification tree in
conformance with Annex J.
NOTE 1 Requirements common to more than one lower
level product can be gathered in “common”
technical specifications called “support
specifications” (e.g. GDIR “General Design and
Interface Requirements”, environmental, test,
EMC requirements specifications).
NOTE 2 Requirements for equipment level products (or
lower level products) can be issued in self-
contained specifications.
d. <>
5.2.3.2 Requirement consolidation
a. The system engineering function shall involve the customer in the
consolidation of requirements by identifying and resolving incomplete,
duplicate, ambiguous, and contradictory requirements for customer-
issued requirements.
b. The system engineering function shall reflect the consolidated
requirements in the release of the technical specifications.
5.2.3.3 Requirement risk analysis
a. <>
b. The system engineering function shall perform the requirements analysis
to identify impacts on system risks.
c. As part of the risk management process implemented on the project, the
system engineering function shall report the requirement impacts on the
risk.
NOTE ECSS-M-ST-80 Annex E describes the risk
reporting process.
5.2.3.4 Requirements verification methods
a. The system engineering function shall ensure that for each requirement
contained in the technical requirements specification, one or a
combination of verification methods are identified.
NOT
...
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...