Space engineering. System engineering. ECSS-E-10 C Draft 1

(1)

ECSS-E-10 C Draft 1

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

(2)

Published by: ESA Standard and Requirements Division ESTEC, P.O. Box 299,

2200 AG Noordwijk,

The Netherlands

ISSN: 1028-396X

Price: € 10 (up to 50 pages) € 20 (50-100 pages) € 30 (101 - 200 pages) Printed in: The Netherlands

(3)

Foreword

This Standard is one of the series of ECSS Standards intended to be applied together for the management, engineering and product assurance in space projects and applications. ECSS is a cooperative effort of the European Space Agency, national space agencies and European industry associations for the purpose of developing and maintaining common standards.

Requirements in this Standard are defined in terms of what shall be accomplished, rather than in terms of how to organize and perform the necessary work. This allows existing organizational structures and methods to be applied where they are effective, and for the structures and methods to evolve as necessary without rewriting the standards.

The formulation of this Standard takes into account the existing ISO 9000 family of documents.

This Standard has been prepared by the ECSS-E-10C Working Group, reviewed by the ECSS Executive Secretariat and approved by the ECSS Technical Authority.

(4)

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

(6)

(7)

1 Scope

This standard specifies the systems engineering implementation requirements for Space systems and Space products development.

Specific objectives of this standard are:

• to implement the system engineering requirements to ensure that the programme has a firm technical basis to minimize technical risk .

• to specify the essential system engineering tasks, their objectives and outputs.

• to implement integration and control of discipline engineering and lower level systems engineering work

• to implementation of the “customer–system–supplier model” through the development of systems for space applications

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.

Specific requirements related to systems engineering, like functional analysis, functional and technical specifications, verification, testing are specified in dedicated documents and standards within the E10 standard branch.

Discipline or element specific engineering implementation requirement are covered in dedicated ECSS standards.

ECSS-E-HB-10A contains guidelines related to this standard, including a description of the reference system engineering process for a space system and products.

(8)

(9)

2 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 revisions 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 most recent editions of the normative documents indicated below. For undated references, the latest edition of the publication referred to applies.

ECSS-E-10-02B Space engineering – Verification ECSS-E-10-03B Space engineering – Testing

ECSS-E-10-04 Space engineering – Space environment

ECSS-E-10-06A Space engineering – Functional and technical specifications

ECSS-E-20 Space engineering – Electrical and electronic ECSS-E-32A Space engineering – Structural

ECSS-E-40C Space engineering – Software

ECSS-E-70-41A Space engineering – Telemetry and telecommand packet utilization

ECSS-E-TM-10-10 Space engineering – Logistic engineering ECSS-E-TM-10-23A Space engineering – Engineering database

ECSS-M-10B Space project management – Project breakdown structures

ECSS-M-30B Space project management – Project phasing and planning

ECSS-M-40B Space project management – Configuration management

ECSS-M-50B Space project management – Information/documentation management

ECSS-P-001B ECSS - Glossary of terms ISO/AWI 24113 (to be

(10)

(11)

3 Terms, definitions and abbreviated terms

3.1 Terms and definitions

For the purposes of this document, the definitions given in ECSS-P-001 apply. In particular, the following terms have a specific definition for use in this document. Acceptance Approval Analysis Configuration baseline Design Development Element Equipment Inspection Margin

Performance (see also ECSS-E-10-06) Product tree Qualification Requirement Specification Subsystem System Test Verification 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

(12)

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

(13)

NOTE These are requirements related to a product and not those related to the process or management of the project or contract.

3.1.11

technology readiness level

achieved status of development of a technology

NOTE TRL levels 1 to 9 are defined as follows:

TRL1 Basic principles observed and reported

TRL2 Technology concept and/or application formulated TRL3 Analytical and experimental critical function

and/or characteristic proof-of-concept performed TRL4 Component and/or breadboard validated in the

laboratory environment

TRL5 Component and/or breadboard validated in the relevant environment

TRL6 System/subsystem model or prototype demonstrated in the relevant environment (ground or space)

TRL7 System prototype demonstrated in a space environment

TRL8 Actual system completed and flight-qualified through test and demonstrated (ground or flight) TRL9 Actual system “flight-proven” through successful

mission operations

3.2 Abbreviated terms

The following abbreviated terms are defined and used within this standard:

Abbreviation Meaning

AIT assembly, integration and test

AIV plan assembly, integration and verification plan

AOCS attitude and orbit control sub-system

AR acceptance review

CDR critical design review

COTS commercial off-the-shelf

DDF design definition file

DJF design justification file

DRD document requirements definition

ECSS European Cooperation for Space Standardization

ELR end-of-life review

FS functional specification

EOL end-of-life

FM flight model

FMECA failure modes, effects, and criticality analysis

FOM flight operation manual

(14)

FRR flight readiness review

FTA fault tree analysis

GSE ground support equipment

ICD interface control document

ILS integrated logistic support

IOOR in-orbit operations review

IRD interface requirement document

LRR launch readiness review

MCR mission closed-out review

MDD mission description document

MDR mission definition review

MOP mission operations plan

MS mission statement

ORR operational readiness review

PDR preliminary design review

PRR preliminary requirement review

PUM product user manual

QR qualification review

RF radio frequency

RJF requirement justification file

ROD review of design

RTM requirement traceability matrix

R&D research and development

SE system engineering

SEP system engineering plan

SRR system requirement review

STD standard

TP technology plan

TS technical specification

UM user manual

VCD verification control document

VP verification plan

(15)

4 Overview of systems engineering

4.1 The system engineering discipline

Systems engineering is defined as an interdisciplinary approach governing the total technical effort to transform requirements into a system solution.

A system is defined as an integrated set of elements to accomplish a defined objective. These elements include hardware, software, firmware, people, 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”, consists usually of one (of more) space segment(s), of a ground segment, and of a user segment. Elements of a system decomposition are also considered a system. For the purpose of this standard the system can be any item at any level of decomposition.

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 The customer-supplier model is described in ECSS-M-00B. Figure 1 shows the boundaries of the systems engineering discipline, its relationship with production, operations, product assurance and management disciplines and its internal partition into functions:

• system engineering integration and control, which ensures the integration of the various engineering disciplines and participants throughout all the project phases.

• 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 (which is performed to result in a physical architecture) and configuration (which is performed to result in a complete system functional, physical and software).

• verification, which objective is to demonstrate that the deliverables conform to the specified requirements.

(16)

Figure 2 shows system engineering functions, their relationships and their main activities during the systems engineering process.

Systems engineering functions are applied in an iterative mode during implementation of the systems engineering process described in subclause 4.2.

(17)

Figure 1 System engineering functions and boundaries

NOTE: MAIT = manufacturin

g, assembl

y, inte

gration and test PMP =

(18)

De si gn a nd co nf ig ur at io n R equ irem en t En gi ne er in g Analy sis Sy st em E ngi ne er in g Da ta B as e Technic a l Pla n s Sys te m Eng in e erin g Too ls an d M odels In te g rat io n an d C on tr ol Sy stem A na lysis F unc tio n al An a ly si s an d a lloc at ion Sys te m Analy sis Sys te m Analy sis Re qu ir eme nt En gine e rin g De si gn a nd co nf ig ur at io n Ver ifi cati on Requ ireme n ts V er ifi ca tio n Fu nc tional Ve ri fica tion Pr odu ct V er ifi ca tio n

P lan and D ata

(19)

4.2 The system engineering process

The systems engineering process consists of activities to be performed by the system engineering organisation within each project phase. The objective is to obtain a product which satisfies the mission statement or customer intended need within pre-established objectives of cost and time. The requirements for these activities are described in chapter 5.

The systems engineering process is applied for each element of the product decomposition.

The systems engineering process is applied with various degrees of depth depending on the level of maturity of the product (new development or off-the-shelf).

The systems engineering process may be applied with different level of tailoring as agreed between customer and supplier.

The systems engineering organization has interfaces with organizations in charge of management, product assurance, engineering, production, and operations and logistics.

NOTE 1 The systems engineering process is defined in detail in ECSS-E-HB-10A Systems engineering guidelines.

(20)

(21)

5 General requirements

5.1 System engineering plan

a. The systems engineering organisation shall produce a system engineering plan (SEP, see ECSS-E-10C, Annex D).

b. The systems engineering organisation shall establish the SEP with the contributions and constraints of management, product assurance, engineering, production, and operations and logistics.

5.2 Systems engineering integration and control

5.2.1 Management of systems engineering activities

The system engineering organisation shall define, plan and manage the integrated technical effort in accordance with the SEP and the subsequent sections of this document. In particular:

a. Set up the system engineering organisation and interfaces (including those to customer and to lower levels) in accordance with the system engineering plan.

b. Make engineering decisions with the support and implementation of 1. studies, trade-offs and analyses,

2. models, simulators, breadboards, 3. development activities

4. technical optimisation efforts

c. Ensure the availability of product and process data which enables the complete system to be produced, tested, delivered, operated, maintained, and properly disposed of.

d. Ensure that the experience gained in past and in parallel activities is systematically considered.

5.2.2 Planning

The organization in charge of the system shall ensure that the SEP is in agreement with the project schedule (as defined in ECSS-M-60B Annex C).

5.2.3 Engineering data

a. The organization in charge of the system shall:

(22)

c. Ensure that engineering data can be exchanged in electronic form between the different product decomposition levels via agreed and validated interfaces.

5.2.4 Interface control

The system engineering organization shall control external interfaces as well as internal interfaces to the system by means of technical specification (as defined in ECSS-E-10-06A Annex B) and interface control documents (as defined ECSS-E-10-24A Annex A).

NOTE 1 The control of the external interfaces is performed in cooperation of the parties involved in the interface.

NOTE 2 Interface requirements can be rolled-out of the technical specification as interface requirements documents (see ECSS-E-10C, Annex M)

5.2.5 Technical budgets and margin policy

a. The organization in charge of system engineering shall control all technical budgets (see ECSS-E-10C, Annex I).

b. The organization in charge of system engineering shall define the margin policy as applicable to the maturity level of the product (see Design Justification File ECSS-E-10C, Annex I).

5.2.6 Technology

The organization in charge of system engineering shall

a. identify candidate technologies, and document them in the Technology Matrix (see ECSS-E-10C, Annex F).

b. ensure that the technologies proposed are assessed and confirmed in terms of availability and maturity (according to TRL levels defined in 3.1.11), and documented in the Technology Plan (see ECSS-E-10C, Annex E).

c. demonstrate supportability and feasibility within the defined industrial organization’s cost and schedule constraints.

5.2.7 Risk control

The systems engineering organisation shall:

a. ensure the availability of engineering data and approaches in support of risk management (as defined inECSS-M-00-03).

b. implement and control the elements of the risk management plan which are within systems engineering responsibility.

5.2.8 Changes and nonconformances control

a. provide a technical assessment on any change proposal to the baseline of the product.

b. provide a technical assessment on any nonconformance to the as-designed status of the product.

c. Implement and control agreed actions.

NOTE 1 Change is related to a request for deviation. NOTE 2 Nonconformance is related to a request for waiver.

NOTE 3 The change procedure/control is defined as part of the configuration management (as defined in ECSS-M-40B).

(23)

5.3 Requirement engineering

5.3.1 General

The system engineering organisation shall ensure:

a. generation, control and maintenance of a set of requirements for the system and its lower level elements;

b. consistency of the requirements at system level, at lower levels, as well as amongst levels

c. conformance of each requirement with characteristics specified in ECSS-E-10-06A clause 8.

d. that each requirement has a justification reflected in the requirement justification file (see ECSS-E-10C Annex O).

NOTE Main characteristics are: traceable, unique, single, verifiable, unambiguous.

5.3.2 Requirement traceability

a. The system engineering organisation shall ensure forward and backward traceability of all requirements:

1. to their sources (e.g. a higher level requirement, an imposed management constraint, an applicable standard, an accepted lower level constraint);

2. to the lower level requirements;

3. to changes in the design inducing modifications of the requirements; 4. to their verification close-out.

b. The systems engineering organisation shall establish the requirements traceability matrix, as defined in ECSS-E-10C Annex N.

c. The system engineering organisation shall ensure that the close-out traceability is documented in the VCD according to ECSS-E-10-02B Annex C.

5.3.3 Requirement engineering process

5.3.3.1 Functional and technical specifications

a. The systems engineering organisation shall establish functional specifications and technical specifications of the system and of the different lower level products

b. The systems engineering organisation shall establish a comprehensive specifications tree as defined in ECSS-E-10C Annex J.

c. The systems engineering organisation shall ensure that the functional and technical specifications conform to ECSS-E-10-06A and its respective DRDs Annex A and Annex B.

5.3.3.2 Requirement consolidation

a. At the beginning of each project phase, incomplete, ambiguous, contradictory requirements shall be identified and resolved with the customer.

b. New requirements shall be agreed with the customer.

c. Consolidated requirements shall be reflected in updates of the requirements specifications.

(24)

5.3.3.3 Requirement analysis

The systems engineering organisation shall perform the requirements analysis to the level of depth necessary to identify elements impacting on system risks;

5.3.3.4 Requirements verification methods

The systems engineering organisation shall ensure that one or more verification methods are identified for each requirement in the Technical Specification (as defined in ECSS-E-10-06A Annex A) and reflected in the verification matrix (as defined in ECSS-E-10-02B Annex C);

5.3.3.5 Requirement allocation

The system requirements (and their verification methods) shall be allocated to lower levels and included in the specifications of the related products.

5.3.3.6 Requirements consistency

The systems engineering organisation shall verify that the system and lower level requirements are individually and globally consistent and non redundant.

5.3.3.7 Requirements validation

The systems engineering organisation shall gain the acceptance of the customer of the final set of requirements in the system and the next lower level specifications.

5.3.3.8 Requirement maintenance

a. The systems engineering organisation shall ensure that agreed changes to requirements are implemented in system and lower levels specifications. b. The systems engineering organisation shall exercise the maintenance

during the system life cycle, down to final verification close-out.

5.3.3.9 Requirements baseline

The systems engineering organisation shall establish the list of documents constituting the system requirements baseline.

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 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.

(25)

f. The systems engineering organisation shall ensure that any analysis is documented in an analysis report, which conforms to ECSS-E-10C, Annex Q.

5.4.2 System environments and design factors

a. The systems engineering organisation shall establish the influence of all types of environments applied during each life profile event on system and its elements in terms of nominal and extreme environmental conditions (as defined in ECSS-E-10-06A Annex B).

b. The systems engineering organisation shall establish the criteria for qualification and acceptance (ECSS-E-10C Annex K) of system / system elements for all types of environment.

c. The systems engineering organisation shall ensure that analyses include design induced effects between system components or the system and its external environment (ECSS-E-10C Annex K).

d. The systems engineering organisation shall establish the factors and margins applicable for design (ECSS-E-10C Annex K).

e. The systems engineering organisation shall establish environment conditions for verification.

5.4.3 Trade-off analyses

a. The systems engineering organisation shall conduct or consolidate trade-off analyses to:

1. assist in selecting system concepts, designs and solutions (including people, parts and materials availability);

2. support material selection and process decisions; 3. support make-or-buy and supplier selection;

4. examine alternative technologies to satisfy functional and design requirements;

5. evaluate environmental and cost impacts of materials and processes; 6. evaluate alternative physical architectures to select preferred products

and processes;

7. establish the system and its configuration items;

8. analyze planning critical paths and propose alternatives;

9. select standard components, techniques, services and facilities that reduce system life-cycle cost;

10. establish model philosophy achieving verification and qualification objectives while considering testability;

11. assess design capacity to evolve.

b. Alternative concepts considered during trade-off studies shall each be documented in a System Concept Report (see ECSS-E-10C Annex C).

c. Alternative concepts shall be evaluated against each other in a Trade-off report, see ECSS-E-10C Annex L.

5.4.4 5Analysis tools and models

a. The system engineering organisation shall define the analysis tools and methods to be used during the product life cycle, as well as the model and data exchanges between the tools, and document these in the SEP (see ECSS-E-10C Annex D).

(26)

b. Analysis tools shall be validated, maintained.

c. Analysis tools shall be capable of exchanging and using engineering models and data (as defined in ECSS-E-TM-10-20A and ECSS-E-TM-10-21A). d. Analysis tools shall be capable of transferring engineering models for

multi-disciplinary analysis (as defined in 10-20A and ECSS-E-TM-10-21A).

e. Models produced by analysis tools shall be validated based on documented procedures and results.

f. Modelling and test accuracy as well as limitations shall be considered (ECSS-E-10C Annex K) when establishing the performances and specifying environmental conditions for verification.

g. Models shall be kept operational for the lifetime of the product.

5.5 Design and configuration

5.5.1 Design

5.5.1.1 General

a. The system engineering organisation shall establish a design of the system from its functional architecture, requirement allocation, and technology selection.

b. The design shall address system aspects, covering its whole lifecycle, producing the physical architecture documented as per ECSS-E-10C Annex G (Design Definition File) and the product tree (as defined in ECSS-M-40B, Annex B).

c. The design shall cover hardware, software, and man in the loop. d. The design shall be supported by analyses.

e. The system engineering organisation shall ensure that all interface points with the production organisation are duly supported by communication, cooperation and provision of inputs between the two organizations.

NOTE This relates to integration procedures (as defined in ECSS-E-10 Part 15, Annex A to be published), production master file (as defined in ECSS-E-10 Part 15, Annex C to be published).

5.5.1.2 Budgets

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.

5.5.1.3 Design tools and models

a. The system engineering organisation shall define the design tools and methods to be used during the product life cycle and document it in the SEP.

b. Design tools shall be validated and maintained.

c. Design tools shall be capable of exchanging and using design models and data (as defined in ECSS-E-TM-10-20A and ECSS-E-TM-10-21A).

d. Design models related to the product as documented in the final DDF and DJF shall be kept operational for the lifetime of the product.

(27)

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.1.4 Design files

The systems engineering organisation shall establish and maintain: a. a design definition file, see ECSS-E-10C Annex G.

b. a design justification file, see ECSS-E-10C Annex K.

c. a product user’s manual (PUM) or user’s manual (UM) see ECSS-E-10C Annex P.

NOTE In case the product considered is a space segment, the user manual contains the Flight Operations Manual (FOM) defined in ECSS-E-70B, Annex A.

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.5.2.2 Configuration baseline

The systems engineering organisation shall establish the system configuration baseline to be placed under control at defined programme points (as defined in ECSS-M-40B).

5.5.2.3 Configuration assembly constraints

The systems engineering organisation shall control and document the hierarchical and assembly relationship of the system elements with the physical architecture.

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.

(28)

5.6.2 Requirements verification

a. The systems engineering organisation shall ensure that requirements fulfil the mission statement needs.

b. The systems engineering organisation shall validate the requirements against the expressed needs together with the customer.

5.6.3 Functional verification

a. The systems engineering organisation shall ensure that the functional architecture as derived from the functional analysis is responding to all functional requirements or needs.

b. The systems engineering organisation shall ensure that the requirements as reflected in the functional architecture are verifiable.

5.6.4 Product verification

a. The systems engineering organisation shall ensure that the verification of the product is performed on the physical architecture as defined in the DDF.

b. The systems engineering organisation shall ensure that the verification of the product is performed in the environment conditions defined for verification and using the defined criteria for qualification and acceptance. c. The systems engineering organisation shall ensure that the verification

covers the complete product including hardware, software, man in the loop, operations and representative mission scenarios (including pre-launch, in-orbit and post-landing).

NOTE 1 The testing performed during and at the end of the integration of a system is defined as System Functional Test (SFT).

NOTE 2 For system composed of different segments (e.g. space segment, ground segment), the testing performed to ensure operability and functionality of the complete system is defined as System Validation Test (SVT).

(29)

6 Project phase specific requirements

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.

6.2 Phase 0:Mission analysis-need identification

The systems engineering organization shall

a. ensure that a mission is defined and mission needs identified, b. propose possible system concepts,

c. ensure execution of all systems engineering activities and provision of documents in support to MDR,

d. ensure implementation of the MDR actions.

6.3 Phase A: Feasibility

a. finalise the expression of the needs identified phase 0,

b. propose solutions (including identification of criticalities and risks) to meet the perceived needs,

c. ensure execution of all systems engineering activities and provision of documents in support to PRR,

(30)

6.4 Phase B: Preliminary definition

a. demonstrate that the solution selected at the end of Phase A meets the technical requirements according to the schedule, the budget, the target cost and the organization requirements,

b. ensure execution of all systems engineering activities and provision of documents in support to SRR and PDR,

c. ensure implementation of the SRR and PDR actions.

6.5 Phase C: Detailed definition:

The systems engineering organization shall a. establish the system detailed definition,

b. demonstrate its capability to meet the technical requirements of the system technical specification,

c. ensure execution of all systems engineering activities and provision of documents in support to CDR,

d. ensure implementation of the CDR actions.

6.6 Phase D: Production, ground qualification and acceptance

a. finalize the development of the system by qualification and acceptance, b. finalize the preparation for operations and utilization,

c. ensure execution of all systems engineering activities and provision of documents in support of QR and AR,

d. ensure implementation of the QR and AR actions.

6.7 Phase E: Utilization

The systems engineering organization shall a. support the launch campaign,

b. support the entity in charge of the operations and utilization following the terms of a business agreement,

c. ensure execution of all systems engineering activities and provision of documents in support to the FRR, ORR, LRR, FQR, EOLR, and recurring products AR,

d. ensure implementation of the actions of the above reviews,

e. ensure execution of all systems 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 organisation are only related to maintenance and anomaly investigations.

6.8 Phase F: Disposal.

a. support the entity in charge of the disposal following the terms of a business agreement,

(31)

b. ensure execution of all systems engineering activities and provision of documents in support to the MCR,

c. 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 organisation are only related to disposal.

(32)

(33)

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.

(34)

34

6 August 2007

ECSS-E-10

C Draft 1

Table A-1 System engineering deliver

a

ble documents

Docu men t ti tle Phase 0 Phase A Phase B Phase C Phase D Phase E MDR PRR SRR PDR CDR QR A R FRR ORR LRR FQR EOFR ion document ECSS-E-10C Annex B + + + + + + + + + + + + al specification ECSS-E-10-06B Annex A + + + + + + + + l specification ECSS-E-10-06B Annex B + + + + + + + + + + + ace requirements nt ECSS-E-10C Annex M + + + + + + + + + ing plan ECSS-E-10C Annex D + + + + + + + og y plan ECSS-E-10C Annex E + + + + + + og y mat rix ECSS-E-10C Annex F + + + + + + ECSS-E-10-02B Annex B + + + + + + QM/ F M plan ECSS-E-10-03B Annex ++ + + + + + + bris mitigation ISO 24113 + + + + + + + + + + + +

er related plans (as x D)

+ + + + + + ECSS-E-10C Annex G + + + + + + tree ECSS-E-10C Annex H + + + + + + ree ECSS-M-40B Annex B + + + + + + ECSS-E-10C Annex J + + + + l budget ECSS-E-10C Annex I + + + + + +

(35)

6 A ugust 2007 ECSS-E-10 C Draft 1

Table A-1 System engineering deliver

a

ble documents

Docu men t ti tle Phase 0 Phase A Phase B Phase C Phase D Phase E MDR PRR SRR PDR CDR QR A R FRR ORR LRR FQR EOFR al specifications xt l ower level (2) + + + + + + l specifications xt l ower level (2) + + + + +

efinition file for

xt lo wer level (2) + + + + + ace control nt ECSS-E-10-04B Annex A + + + + + + +

User manual / nual

ECSS-E-10C Annex P + + + + + + + + + ECSS-E-10C Annex K + + + + + ments aceability matr ix ECSS-E-10C Annex N + + + + + + + ment justification ECSS-E-10C Annex O + + + + + + + + report EC SS-E-10C Annex C + + + + + + + ade off report ECSS-E-10C Annex L + + + + + + + ECSS-E-10-02B Annex C + + + + + + + nt ECSS-E-10-02B Annex C + + + + + + + + + + + cificat ion ECSS-E-10-03B Annex D + + + + + + + + ys is report EC SS-E-10C Annex Q + + + + + + + + + + + atical model ECSS-E-HB-10- 22A Annex A + + rt (1 ) ECSS-E-HB-10- 22A Annex B + + o cedure ECSS-E-10-03B Annex C + + + + + po rt ECSS-E-10-02B Annex D + + + + + + + +

(36)

36

6 August 2007

ECSS-E-10

C Draft 1

Table A-1 System engineering deliver

a

ble documents

Docu men t ti tle Phase 0 Phase A Phase B Phase C Phase D Phase E MDR PRR SRR PDR CDR QR A R FRR ORR LRR FQR EOFR rt ECSS-E-10-02B Annex H + + + + + + + + ion file xt l ower level (2) + + + w of design report ECSS-E-10-02B Annex F + + ECSS-E-10-02B Annex G + + ifications + + + ata packages + + + ation procedur e ECSS-E- 10 Part 15 Annex A + + + n master file (1) ECSS-E-10 Pa rt 15 Annex C + + ) : To be published; No te (2) : Se e 5.7. 1 c., 5.7.1 d., a nd 5.7.1 Not e.

(37)

Annex B (normative)

Mission description document (MDD) – DRD

B.1 DRD identification

B.1.1 Requirement identification and source document

ECSS-E-10C, requirement 5.4.1.a.

B.1.2 Purpose and objective

The objective of the mission description document (MDD) is to provide input for the later selection of the best concept meeting the mission statement (MS) in iteration with the preparation of the functional specification (FS) (as defined in ECSS-E-10-06B Annex A). It is prepared in Phase 0 and Phase A (as defined in ECSS-M-30B) and for each possible concept, as indicated in ECSS-E-10C requirement 5.4.1 a. an MDD is established.

Links and chronology amongst the MS, FS, MDD, System Engineering Plan, Project Phasing and Planning Requirement document, System Concept Report and trade-off report are provided on the Figure B-1.

(38)

Mission Statement Functional Specification Mission Description Document Concept #1 Mission Description Document Concept #n

...

System Engineering Plan #1 project phasing and planning requirement document #1

System concept report

Trade-off report System Engineering Plan #n project phasing and planning requirement document #n

Figure B-1 Relationship between documents

The MDD is produced by systems engineering organization of the mission responsible and defines a concept that aims at satisfying the current functional specification, and presents how the objectives, operation profile, major system events and capabilities, contingencies and performance standards are expected to be achieved.

For each mission concept, the MDD is a complete description of that concept. And to each MDD a SEP evaluating the related systems engineering effort and a report evaluating the related programmatic aspect are associated.

The system concept report assesses the different concept for a technical and risk point of view and the trade off report presents the final trade off including weighting factors which bears some management aspects.

B.2 Expected response

B.2.1 Response identification

The requirements for document identification contained in ECSS-M-50B shall be applied to the MDD.

B.2.2 Scope and content

The MDD shall provide the information presented in the following sections:

<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).

<2> Applicable and reference documents

The MDD shall list the applicable and reference documents in support to the generation of the document, and include, as a minimum, the current functional specification.

(39)

<3> Functional specification summary

The MDD shall provide a summary of the functional specification objectives and list the design driving requirements, derived from the current functional specification.

<4> Concept description

The MDD shall provide: a. Overview of the concept b. Mission analysis c. System description:

— System element 1 — …

— System element N

Example For a spacecraft, its ground control segment, and a user segment, e.g.

• Space Segment — Payload — Platform — Launch Vehicle — Orbit related aspects — On-Board Data Handling

— Reference Operation Scenarios / Observation characteristics

— Operability / Autonomy Requirements • Ground Segment

— Functional Requirements and Major Elements — Monitoring and Control Segment

— Data Processing Segment • User segment

— Functional Requirements and Major Elements — Monitoring requirements

d. Description of how the system works in each mission phase 1. Performance drivers

2. Constraints 3. Main events

4. Operations scenarios

Example For a spacecraft, the following phase: • Launch preparation

• Launch and Early Orbit Phase • In Orbit Commissioning • Nominal Operations • Spacecraft Disposal

(40)

<5> Assessment of the performance

The MDD shall provide the

a. Assessment against the current functional specification requirements, and b. Identification of non-compliances, and their impact on the current

Functional Specification.

<6> Identification of risk areas

The MDD shall provide the list of identified risk related to the concept, including as a minimum technology, contingencies handling, and programmatic aspects.

<7> Conclusion

The MDD shall summarize the strengths and weaknesses of the concept.

B.3 Special remark

(41)

Annex C (normative)

System concept report – DRD

C.1 DRD identification

C.1.1 Requirement identification and source document

ECSS-E-10C, requirement 5.4.3 b.

C.1.2 Purpose and objective

The system concept report describes the principal technical characteristics of alternative concepts, relating to performance, architectures, driving technologies, interfaces, risk, and later addresses the selected concepts.

C.2 Expected response

C.2.1 Response identification

The requirements for document identification contained in ECSS-M-50B shall be applied to the system concept report.

C.2.2 Scope and contents

The system concept report shall provide the information presented in the following sections:

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).

The system concept report shall list the applicable and reference documents in support to the generation of the document, and include, as a minimum, the system functional specification and mission description document.

<3> Key technical requirements

a. The system concept report shall list the key technical requirements from the FS (as defined in ECSS-E-10-06B) to be satisfied by the possible concepts to conform to the needs or requirements of the user.

(42)

b. The research of possible concepts should not preclude the identification of concepts, which are not currently mature enough but which can be potential solution for future similar applications.

NOTE A possible concept is a technical answer that has the capability to meet a set of functional requirements.

<4> Sources of information used to search for possible concepts

The system concept report shall identify and present the sources of information used to identify the possible concepts, e.g. R&D results, lessons learned, or similar applications.

<5> Possible concepts description

The system concept report shall describe every identified possible concept, and characterizing each possible concept in terms of technology status or maturity, performances capability, and risks.

<6> Assessment of possible concepts vs the key technical requirements

a. The system concept report shall present the result of the assessment of every identified possible concept with regard to the key FS technical requirements.

b. For each possible concept all the key FS technical requirements shall be assessed, the pros and cons of the concept presented, and the technical and programmatic risks identified.

<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.

(43)

Annex D (normative)

System engineering plan (SEP) – DRD

D.1 DRD identification

D.1.1 Requirement identification and source document

ECSS-E-10C, requirement 5.1.

D.1.2 Purpose and objective

The objective of the system engineering plan (SEP) is to define the approach, methods, procedures, resources and organization to co-ordinate and manage all technical activities necessary to specify, design, verify, operate and maintain a system or product in conformance with the customer’s requirements. In particular the SEP is established to fulfil the major technical project objectives, taking into account the defined project phases and milestones (as defined in ECSS-M-30B).

The SEP covers the full project lifecycle according to the scope of the business agreement. It is established for each item of the product tree (as defined in ECSS-M-10B).

It highlights the risks, the critical elements, the specified technologies, as well as potential commonalities, possibilities of reuse and standardization, and provides means for handling these issues.

The SEP is part of the project management plan (as defined in ECSS-M-00B).

D.2 Expected response

D.2.1 Response identification

The requirements for document identification contained in ECSS-M-50B shall be applied to the SEP.

D.2.2 Scope and contents

The SEP shall provide the information presented in the following sections:

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).

(44)

a. The SEP shall list the applicable and reference documents in support to the generation of the document.

b. The SEP shall include the reference to the following applicable documents: 1. Business agreement,

2. Project management plan (as defined in ECSS-M-00B), 3. Product assurance plan,

4. Configuration management plan (as defined in ECSS-M-40B), 5. Production plan,

6. Operations plan, 7. ILS plan.

<3> Project overview

<3.1> Project objectives and constraints

The SEP shall contain the following description of:

a. The project objective and the main elements that characterize the user’s need.

b. The objective of the system or product as established by the FS (as defined in the ECSS-E-10-06 Annex A) or the TS (as defined in the ECSS-E-10-06, Annex B).

c. The principal elements of the system architecture (i.e. first level elements of the architecture adopted for the system and identification of their reuse constraints).

d. The principal characteristics of the project lifecycle and the incremental development of the system (e.g. successive versions, progressive implementation of system functions.)

e. The principal elements supporting the project lifecycle (e.g. ground support equipments, and facilities).

f. The organizational constraints impacting system engineering activities (e.g. the external and internal industrial organization (e.g. contractors, partners, suppliers, own company) constraints).

g. The list of the critical issues identified at the beginning of the project phase(s).

h. The list of national and international regulations,

i. The capacity for verification and validation, taking into account the means available, e.g. for tests, analysis, or simulation.

<3.2> Product evolution logic

The SEP shall detail the incremental development of the system: a. progressive implementation of system functionalities,

b. identification of possible successive versions,

c. objectives and strategy for the implementation of the successive versions.

<3.3> Project phase(s), reviews and planning

a. The SEP shall provide an implementation and schedule of the system engineering activities and identify for the considered phase(s), as a minimum:

1. the main project milestones driving the system engineering process, 2. the phase(s) of the project lifecycle and the main reviews in accordance

(45)

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).

<4> System design approach <4.1> System engineering inputs

a. The SEP shall list the driving inputs for the system engineering activities described and defined by the:

1. business agreement,

2. outputs from previous phase(s) or expected under the heading of activities which are not controlled within the context of this SEP (e.g. data provided by the customer, data coming from other projects, upstream or predevelopment studies, product lines),

3. project management plan, product assurance plan, risk management plan, and configuration and documentation management plans.

b. The SEP shall list the external means and facilities (e.g. equipment, software, and premises) made available by the customer or by any other entity external to the organization that is responsible of this SEP, and, for each identified mean or facility, identify the applicable interface requirements (e.g. interface control documentation) as well as the authority in charge of it.

c. The SEP shall list the internal means and facilities (e.g. equipment, software, and premises) made available by the organization in charge of the development of the system or product.

<4.2> System engineering outputs

a. The SEP shall list the specified system engineering outputs as defined in ECSS-E-10C for the specific project phase(s) covered in the SEP.

b. The SEP shall describe the following:

1. The strategy for the system engineering activities in line with the guidelines addressed by the management plan. In particular, identifying intermediate technical events for each phase in compliance with the master program schedule.

2. The system design activities, with their objectives and major outputs according to the phase.

3. The major engineering activities for each intermediate technical events, showing their mutual interactions and their relationships with the principal milestones (i.e. internal or contractual) of the project.

4. The model philosophy (as defined in ECSS-E-10-02B sub-clause 4.2.5) in terms of number and characterization of models, from system to the requested lower level, necessary to achieve a high confidence in the product verification.

5. The margin policy according to project phase, product category and maturity level.

(46)

c. The SEP shall also describe

1. the method(s) and process(es) considered for the engineering activities (e.g. concurrent engineering, value analysis, or iteration cycle),

2. the interrelation between the different engineering disciplines and other project activities (e.g. production, quality assurance, and operations and logistics),

3. the interaction with other actors (e.g. customer and suppliers),

4. the consistency and coherency of simultaneous activities (e.g. performed in parallel),

5. which and how, control activities are implemented:

6. in the case of a system incremental evolution, the SEP shall describe the design strategy for:

(a) the development of the initial release of the product;

(b) the development, the validation of subsequent releases and their deployment;

(c) the introduction of new technologies; (d) the tools and methods used for analysis (e) the control of the evolutions for each release.

<4.4> System engineering team responsibilities and organization

The SEP shall contain the following:

a. Definition of the entities participating in the system engineering activities and the corresponding functions according to the project management plan b. Identification of key engineering roles and responsibilities (e.g. system

engineers, disciplines engineers, and technical managers)

c. Description of the co-operative work amongst the different teams participating in the system design,

<4.5> System engineering interfaces

The SEP shall describe the external and internal interfaces in line with the project management plan.

<5> Implementation and related plans <5.1> System engineering tasks description <5.1.1> System engineering process description

a. The SEP shall describe the system engineering process (as defined in ECSS-E-HB-10A Systems engineering guidelines) tailored to the specifics of the considered project, and identify all the systems engineering tasks to be implemented from the starting conditions (e.g. kick-off) to the closing event (e.g. review), their relationship, and their interfaces with other actors of the project, and identify and describe any existing iteration within the process. b. For each task, the input information and their origin, the document(s)

delivered (i.e. expected output) and their destination, the systems engineering function(s) performed and the contribution of other actors shall be identified (as defined in ECSS-E-HB-10A Systems engineering guidelines).

<5.1.2> Engineering disciplines integration

The SEP shall address the following activities that concern the different engineering disciplines, recalling the relevant applicable standards and ancillary dedicated plans that are considered integral part of this SEP.

(47)

a. Operations engineering (as defined in ECSS-E-70B)

The SEP shall define the process and control to be put in place to meet requirements of operations of the space segment. It shall cover, amongst others:

— ground segment engineering, mission operation preparation and execution,

— mission and trajectory analysis, and

— operability analysis (e.g. autonomy, operational scenario, nominal and non-nominal modes, failure detection isolation and recovery).

b. Human factors engineering (as defined in ECSS-E-10-11A)

The SEP shall define the process and control to be put in place to meet requirements for human activities and environments associated with space systems.

c. Production interfaces (as defined in ECSS-E-10 Part 15 to be published) The SEP shall define the process and control to be put in place to meet requirements for the approach, methods, procedures, organization and resources to be implemented to ensure proper technical interfaces between system engineering and production.

d. Space environment (as defined in ECSS-E-10-04)

The SEP shall define the process and control to be put in place to meet requirements specifying natural environment for all space regimes (e.g. debris regulations, or planetary contamination protection) and general models and rules for determining the local induced environment

e. Human system integration (as defined in ECSS-E-10-13 to be published) The SEP shall define process and control to be put in place to meet requirements for implementation of design selections relating to humans for any item with associated human interface, including computer based system and equipment.

f. Logistics engineering (as defined in ECSS-E-TM-10-10)

The SEP shall define for ground and in-orbit logistics and maintenance support aspects, the logistics engineering technical activities and the logistics engineering standards.

It shall address, amongst others, the approaches, methods and analyses to be performed to ensure that the development of space systems (i.e. manned and unmanned) properly takes into account and integrates the supportability and support aspects for the whole life cycle.

g. Electrical and electronic engineering (as defined in ECSS-E-20)

The SEP shall define the process and control to be put in place to meet requirements for electrical and electronic engineering. It shall cover all electrical and electronic aspects of the relevant space product, including functions such as power generation, storage, conversion and distribution, and optical, avionics and microwave domains, electromagnetic compatibility, and electrical interfaces.

h. Mechanical engineering (as defined in ECSS-E-3x series of standards) The SEP shall define the process and control to be put in place to meet requirements for the thermal, structures, mechanisms, environmental control and life support, propulsion, pyrotechnics, mechanical parts, and materials functions and interfaces.

(48)

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.

Space engineering. System engineering. ECSS-E-10 C Draft 1

ECSS-E-10 C Draft 1