This Standard has been cancelled and replaced by ECSS-E-10 Part 1B (18 November 2004).

Introduction

This standard is intended to guide the development of Systems (including hard-ware, software, man-in-the-loop, facilities and services) for space applications.

It specifies implementation requirements for the responsible System Engineering organisation consistent with the assumption that the System Engineering process defined in Standard ECSS-E-10-01 is to be applied.

Specific objectives of this standard are to :

1. Assist in defining, performing, managing, and evaluating System Engineering efforts to ensure that the programme has a firm organisational basis, able in principle to minimise technical risk due to uncertain understanding of scope.
2. Facilitate minimisation of cost through avoidance of repeated organisational work, conversion between different practices and dispersions due to conflicts of interpretation of approaches to System Engineering tasks.
3. Capture the key aspects of the Space Standardization initiatives to : better integrate requirements; implement multidisciplinary teamwork including suppliers; establish the requirements early; establish clear measurements of system responsiveness; focus on process control rather than inspection; en-courage risk management rather than risk avoidance; increase teamwork and cooperation.

This Standard covers specifically each conventional phase of development of a Space System, from analysis and assembly of the user’s requirements to operations and disposal.

The requirements of this Standard may be tailored for each specific space application, in line with the overall ECSS tailoring guidelines (Ref. …..).

For the definition of “System Engineering” see Clause 3 below. System Engineering has an integration role for the Engineering disciplines defined in Standard ECSS-E-00.

For the definition of System lower levels of decomposition, this Standard, in line with other ECSS standards, does not assume a unique terminology in the assumption that each programme may optimise its breakdown choosing from the terms defined in ECSS-E-00.

In this respect it is important to note that the guidelines herein formulated for a space “System” indeed apply, with appropriate tailoring, to a lower level of decomposition, on the grounds that products of practically any level are:

1. the final result of an interdisciplinary process starting with the operational requirements analysis and concluding with the delivery of the verified and certified product;
2. the result of the design integration of different parts and functions.

Figure 1 shows the boundaries of the System Engineering discipline, its relation-ship with Production, Operations, Product Assurance and Management disciplines and its internal partition into “Functions”:

• System Engineering Integration & Control
• Requirements Engineering
• Analysis
• Design and Configuration
• Verification

Functions do not represent a compulsory organisation requirement, but rather a useful conceptual partition of the System Engineering discipline, whereby each element (“function”) embraces tasks which are homogeneous in objective and nature, and all elements together encompass the totality of the discipline’s scope.

The organisation of requirements per functions, as in this Standard, permits the definition of clear-cut, homogeneous sets that can be easily mapped on the functional diagram of the Systems Engineering process defined in standard ECSS-E-10-01 (Figure 2), and external to which only requirements for System Engineering Interface tasks at the boundary with other disciplines remain to be defined.

The dynamic properties of this process, namely its applicability in an iterative and nested pattern across the complete span of a system life cycle, are described in de-tail in Standard ECSS-E-10-01 “Systems Engineering Process”.

For each function, General (i.e. principle, structural) and Specific (i.e. in the form of a discrete, verifiable task or product for a given life cycle phase) requirements are given, covering all the System Engineering activities as a means of obtaining a beneficial, nonoverburdening, programme-independent recommendation or guideline.

Relationship with other standards

For the overall definition of “System Engineering” as a discipline of Engineering in Space projects this Standard refers to Standard ECSS-E-00 (Engineering of Space Programmes), while for the theory of System Engineering this Standard refers to Standard ECSS-E-10-01 (Systems Engineering Process).

It is in ECSS-E-10-01 that “System Engineering” is explained as a mechanism for proceeding from interpretation of the customer’s requirements to an optimised product by steadily applying a wide-ranging attention to product requirements, extending to all details of the user’s needs, produceability constraints and life cycle aspects, essentially through an organised concurrent engineering practice. This takes place through iteration and nesting of a proper routine of analysis/synthesis, typical of a comprehensive system approach, within and across all levels of integration and all phases of a system life cycle.

Standard ECSS-E-10-01 defines and describes this routine in a high-level, productindependent, phase-independent and essentially intellectual way.

This standard instead aims at providing a practical, space-focused implementation of the above, developing it into a set of discrete definitions and requirements.

These constitute a common reference or “checklist” of maximum utility for organising and conducting, with respect of the above principles, the engineering activities of a space system project or for participating as customer or supplier at any level of decomposition.

The System Engineering activities addressed in ECSS-E-10

• integrate specifically the activities of other Engineering disciplines covered by ECSS-E-xx standards (ECSS-E-20 Electrical and Electronic, ECSS-E-30 Mechanical, ECSS-E-40 Software, ECSS-E-50 Communications, ECSS-E-60 Control Systems, ECSS-E-70 Ground Systems and Operations);
• ensure a functional interfacing with Management and Quality activities covered by ECSS-M-xx and ECSS-Q-xx standards, in particular:

• System Engineering is submitted to ECSS-M-10 Project Breakdown Structure, ECSS-M-20 Project organisation (it is part of it), ECSS-M-30 Project Phasing;
• System Engineering is fully interfaced with and complies with the requirements of ECSS ECSS-M-40 Configuration Management, ECSS-M-50 In-formation/Documentation, ECSS-M-60 Cost and Schedule Management, and ECSS-M-70 Integrated Logistics Support;
• System Engineering integrates in the product design and implementation process the inputs of the Product Assurance organisation, namely Depend-ability, Safety, Component Control, Materials, Mechanical Parts and Processes provisions.
• System Engineering contributes to the implementation of the Product Assurance organisation by integrating the ECSS-Q-xx requirements and facilities within the system engineering activities.

Attachments:

• ECSS-E-10A(19April1996).pdf