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

Transcription

1 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: X Price: 10 (up to 50 pages) 20 ( pages) 30 ( pages) Printed in: The Netherlands Copyright: 2007 by the European Space Agency for the members of ECSS 2

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

4 Contents Foreword Scope Normative references Terms, definitions and abbreviated terms...11 Terms and definitions Abbreviated terms Overview of systems engineering The system engineering discipline The system engineering process General requirements System engineering plan Systems engineering integration and control Requirement engineering Analysis Design and configuration Verification Project phase specific requirements...29 General Phase 0:Mission analysis-need identification Phase A: Feasibility Phase B: Preliminary definition Phase C: Detailed definition: Phase D: Production, ground qualification and acceptance Phase E: Utilization Phase F: Disposal Annex A (normative) System engineering documents delivery per review...33 Annex B (normative) Mission description document (MDD) DRD...37 Annex C (normative) System concept report DRD...41 Annex D (normative) System engineering plan (SEP) DRD

5 Annex E (normative) Technology plan (TP) DRD...51 Annex F (normative) Technology matrix - DRD...55 Annex G (normative) Design definition file (DDF)- DRD...57 Annex H (normative) Function tree - DRD...61 Annex I (normative) Technical budget - DRD...63 Annex J (normative) Specification tree - DRD...65 Annex K (normative) Design justification file - DRD...67 Annex L (normative) Trade-off report - DRD...73 Annex M (normative) Interface requirement document - DRD...75 Annex N (normative) Requirements traceability matrix - DRD...77 Annex O (normative) Requirements justification file - DRD...79 Annex P (normative) Product user manual (PUM or UM) - DRD...81 Annex Q (normative) Analysis report DRD...89 Bibliography...91 Figures Figure 1 System engineering functions and boundaries Figure 2 System engineering function and relationships Figure B-1 Relationship between documents Tables Table A-1 System engineering deliverable documents

6 (This page is intentionally left blank) 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-theloop, 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. 7

8 (This page is intentionally left blank) 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 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 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 (to be published) Space systems -- Orbital debris -- Routes to compliance and management for debris mitigation 9

10 (This page is intentionally left blank) 10

11 Terms, definitions and abbreviated terms 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 critical characteristic of a process, process condition, parameter, requirement or item that deserves control and special attention in order to meet the objectives (e.g. of a mission) within given constraints 11

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 integration process of physically and functionally combining lower level products (hardware or software) to obtain a particular functional configuration mission statement set of collected needs NOTE Document commonly used within the space community, see also 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 NOTE 4 Adapted from EN 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 recurring product a product which conforms to a qualified design and produced according to the corresponding production master file system engineering the interdisciplinary approach governing the total technical effort required to transform a requirement into a system solution NOTE From IEEE P system engineering process set of inter-related or interacting activities, each transforming inputs into outputs, to implement system engineering technical requirement requirement stated in the technical terms 12

13 NOTE These are requirements related to a product and not those related to the process or management of the project or contract technology readiness level achieved status of development of a technology NOTE TRL levels 1 to 9 are defined as follows: TRL1 TRL2 TRL3 TRL4 TRL5 TRL6 TRL7 TRL8 TRL9 Basic principles observed and reported Technology concept and/or application formulated Analytical and experimental critical function and/or characteristic proof-of-concept performed Component and/or breadboard validated in the laboratory environment Component and/or breadboard validated in the relevant environment System/subsystem model or prototype demonstrated in the relevant environment (ground or space) System prototype demonstrated in a space environment Actual system completed and flight-qualified through test and demonstrated (ground or flight) 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 FQR flight qualification review 13

14 FRR FTA GSE ICD ILS IOOR IRD LRR MCR MDD MDR MOP MS ORR PDR PRR PUM QR RF RJF ROD RTM R&D SE SEP SRR STD TP TS UM VCD VP w.r.t. flight readiness review fault tree analysis ground support equipment interface control document integrated logistic support in-orbit operations review interface requirement document launch readiness review mission closed-out review mission description document mission definition review mission operations plan mission statement operational readiness review preliminary design review preliminary requirement review product user manual qualification review radio frequency requirement justification file review of design requirement traceability matrix research and development system engineering system engineering plan system requirement review standard technology plan technical specification user manual verification control document verification plan with respect to 14

15 Overview of systems engineering 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. 15

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

17 NOTE: MAIT = manufacturing, assembly, integration and test PMP = parts, materials and Figure 1 System engineering functions and boundaries 17

18 Integration and Control System Analysis Analysis Requirement Engineering Requirement Engineering Requirements Verification Verification System Engineering Data Base Technical Plans System Engineering Tools and Models System Analysis Functional Analysis and allocation Functional Verification System Analysis Design and configuration Design and configuration Product Verification Plan and Data Figure 2 System engineering function and relationships 18

19 4.2 The system engineering process ECSS-E-10 C Draft 1 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-theshelf). 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. NOTE 2 The project phases are defined in ECSS-M-30B. 19

20 (This page is intentionally left blank) 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 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 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) Engineering data a. The organization in charge of the system shall: b. Define the engineering data to be stored in a data repository. 21

22 c. Ensure that engineering data can be exchanged in electronic form between the different product decomposition levels via agreed and validated interfaces 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) 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) 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 ), 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 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 Changes and nonconformances control The systems engineering organisation shall: 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). 22

23 5.3 Requirement engineering 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 A 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 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 Requirement engineering process 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 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. 23

24 Requirement analysis The systems engineering organisation shall perform the requirements analysis to the level of depth necessary to identify elements impacting on system risks; 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); Requirement allocation The system requirements (and their verification methods) shall be allocated to lower levels and included in the specifications of the related products Requirements consistency The systems engineering organisation shall verify that the system and lower level requirements are individually and globally consistent and non redundant 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 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 Requirements baseline The systems engineering organisation shall establish the list of documents constituting the system requirements baseline. 5.4 Analysis System analysis a. The systems engineering organisation shall perform an analysis of the Mission Statement document, produce Mission Description document(s) (see ECSS-E-10C Annex B), and maintain this latter document for the final selected concept. b. The systems engineering organisation shall perform a functional analysis as defined in ECSS-E-HB-10-05, produce the functional architecture documented as per ECSS-E-10C Annex G, and the function tree (see ECSS- E-10C Annex H). c. The systems engineering organisation shall perform a physical analysis documented as per ECSS-E-10C Annex G as input to the physical architecture documented as per ECSS-E-10C Annex G and to the product tree (as defined in ECSS-M-40B Annex B). d. The systems engineering organisation shall analyse the performances of the system, including end-to-end evaluation, documenting the results of the analysis as per the Design Justification File, see ECSS-E-10C Annex K. e. The systems engineering organisation shall analyse influence of mission, design, development, operations and constraints on cost and schedule as input to the project cost and schedule consolidation. 24

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

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 multidisciplinary analysis (as defined in ECSS-E-TM-10-20A and ECSS-E-TM A). 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 Design 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) Budgets The systems engineering organisation shall: a. define and maintain all technical budgets reflecting the as-designed status of the system; b. apportion budget requirements to all levels of system decomposition; c. apply the margin policy 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. e. Design models produced by design tools shall be validated. 26

27 5.6 Verification ECSS-E-10 C Draft 1 f. All design models shall refer to a reference coordinate system agreed with the customer (as defined in ECSS-E-10-09A Coordinate systems) 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 Configuration 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) 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) Configuration assembly constraints The systems engineering organisation shall control and document the hierarchical and assembly relationship of the system elements with the physical architecture General a. The system engineering organisation shall implement the verification according to ECSS-E-10-02B. b. The system engineering organisation shall establish a verification strategy documented in the Verification Plan, as defined in ECSS-E-10-02B Annex B. c. The system engineering organisation shall assign the product to a verification product category, as defined in ECSS-E-10-02B Table-1. d. The system engineering organisation shall confirm that all verification objectives are achieved by analysing the results of the verification activities (Verification Control Document and its closeout documents, as defined in ECSS-E-10-02B Annex C). e. The system engineering organisation shall ensure that validation of systems with man-in-the-loop take into account the man related limitations. 27

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 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 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, inorbit 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). 28

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 6.3 Phase A: Feasibility 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. The systems engineering organization shall 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, d. ensure implementation of PRR actions. 29

30 6.4 Phase B: Preliminary definition The systems engineering organization shall 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 6.7 Phase E: Utilization 6.8 Phase F: Disposal. The systems engineering organization shall 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. 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. The systems engineering organization shall a. support the entity in charge of the disposal following the terms of a business agreement, 30

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

32 (This page is intentionally left blank) 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

34 Table A-1 System engineering deliverable documents Document title Phase 0 Phase A Phase B Phase C Phase D Phase E Phase F MDR PRR SRR PDR CDR QR AR FRR ORR LRR FQR EOFR MCR Mission description document ECSS-E-10C Annex B Specifications Functional specification ECSS-E-10-06B Annex A Technical specification ECSS-E-10-06B Annex B Interface requirements document ECSS-E-10C Annex M System engineering plan ECSS-E-10C Annex D Technology plan ECSS-E-10C Annex E Technology matrix ECSS-E-10C Annex F Verification plan ECSS-E-10-02B Annex B AIT QM/FM plan ECSS-E-10-03B Annex Orbital debris mitigation plan ISO Other related plans (as called in ECSS-E-10C Annex D) Design definition file ECSS-E-10C Annex G Function tree ECSS-E-10C Annex H Product tree ECSS-M-40B Annex B Specification tree ECSS-E-10C Annex J Technical budget ECSS-E-10C Annex I

35 ECSS-E-10 C Draft 1 Table A-1 System engineering deliverable documents Document title Phase 0 Phase A Phase B Phase C Phase D Phase E Phase F MDR PRR SRR PDR CDR QR AR FRR ORR LRR FQR EOFR MCR Functional specifications for next lower level (2) Technical specifications for next lower level (2) Design definition file for next lower level (2) Interface control document ECSS-E-10-04B Annex A Product User manual / User Manual ECSS-E-10C Annex P Design justification file ECSS-E-10C Annex K Requirements traceability matrix ECSS-E-10C Annex N Requirement justification file ECSS-E-10C Annex O Concept report ECSS-E-10C Annex C Trade off report ECSS-E-10C Annex L Verification matrix ECSS-E-10-02B Annex C Verification control document ECSS-E-10-02B Annex C Test specification ECSS-E-10-03B Annex D Analysis report ECSS-E-10C Annex Q Mathematical model ECSS-E-HB-10- description (1) 22A Annex A + + Correlation report (1) ECSS-E-HB-10-22A Annex B + + Test procedure ECSS-E-10-03B Annex C Test report ECSS-E-10-02B Annex D

36 Table A-1 System engineering deliverable documents Document title Phase 0 Phase A Phase B Phase C Phase D Phase E Phase F MDR PRR SRR PDR CDR QR AR FRR ORR LRR FQR EOFR MCR Verification report ECSS-E-10-02B Annex H Design justification file for next lower level (2) Review of design report ECSS-E-10-02B Annex F + + Inspection report ECSS-E-10-02B Annex G + + GSE specifications GSE Data packages Other documents Integration procedure Production master file (1) ECSS-E- 10 Part 15 Annex A ECSS-E-10 Part 15 Annex C + + Note (1) : To be published; Note (2) : See c., d., and Note. 36

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

38 Mission Statement Functional Specification System Engineering Plan #1 Mission Description Document Concept #1... Mission Description Document Concept #n System Engineering Plan #n project phasing and planning requirement document #1 System concept report project phasing and planning requirement document #n Trade-off report B.2 Expected response 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.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. 38

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 39

40 B.3 Special remark <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. None. 40

41 Annex C (normative) System concept report DRD C.1 DRD identification C.2 Expected response C.1.1 Requirement identification and source document ECSS-E-10C, requirement 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.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: <1> Introduction The system concept report shall contain a description of the purpose, objective, content and the reason prompting its preparation (e.g. logic, organization, process or procedure). <2> Applicable and reference documents 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. 41

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

43 Annex D (normative) System engineering plan (SEP) DRD D.1 DRD identification D.2 Expected response 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.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: <1> Introduction The SEP shall contain a description of the purpose, objective, content and the reason prompting its preparation (e.g. programme or project reference and phase). 43

44 <2> Applicable and reference documents 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 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 to project management plan. 44