ECSS system
Description, implementation and general requirements
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.
This Standard has been prepared by the ECSS-S-ST-00 Working Group, reviewed by the ECSS Executive Secretariat and approved by the ECSS Technical Authority.
Disclaimer
ECSS does not provide any warranty whatsoever, whether expressed, implied, or statutory, including, but not limited to, any warranty of merchantability or fitness for a particular purpose or any warranty that the contents of the item are error-free. In no respect shall ECSS incur any liability for any damages, including, but not limited to, direct, indirect, special, or consequential damages arising out of, resulting from, or in any way connected to the use of this Standard, whether or not based upon warranty, business agreement, tort, or otherwise; whether or not injury was sustained by persons or property or otherwise; and whether or not loss was sustained from, or arose out of, the results of, the item, or any services that may be provided by ECSS.
Published by: ESA Requirements and Standards Division
ESTEC, ,
2200 AG Noordwijk
The
Copyright: 2008 © by the European Space Agency for the members of ECSS
Change log
|
ECSS-S-00A
|
First issue
|
|
ECSS-S-00B
|
Never issued
|
|
ECSS-S-ST-00C
|
Second issue
|
Scope
This document is the ECSS top–level document for ECSS users. It gives a general introduction into ECSS and the use of ECSS Documents in space programmes and projects.
Its purpose is to provide users with an overview of the ECSS System, together with an introduction to the three branches of applicability and to the disciplines covered by the set of ECSS Standards and the processes involved in generating and using these standards.
As an introduction into space programmes, space projects actors and their customer-supplier relationships are described.
The three branches (Management, Product Assurance and Engineering) of ECSS system and their disciplines are then presented as well as link amongst the branches.
Application of the ECSS System for space projects in the customer-supplier chain is explained and a practical tailoring method is described together with methods for collecting and processing user feedback.
Finally top-level requirements are defined for implementation of the ECSS system in space projects/programmes.
This standard is applicable to all the procurements of space products.
With effect from the date of approval, this Standard announces the adoption of the external document on a restricted basis for use in the European Cooperation for Space Standardization (ECSS) system.
This standard may be tailored for the specific characteristic and constraints of a space project in conformance with clause 7 of this standard.
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-S-ST-00-01
|
ECSS system – Glossary of terms
|
Terms, definitions and abbreviated terms
Terms from other standards
For the purpose of this Standard, the terms and definitions from ECSSSST0001 apply.
Abbreviated terms
For the purpose of this Standard, the abbreviated terms from ECSS-S-ST-00-01 and the following apply:
|
Abbreviation
|
Meaning
|
|
DRD
|
document requirements definition
|
|
EARM
|
ECSS applicable requirements matrix
|
|
ECM
|
ECSS compliance matrix
|
|
HB
|
handbook
|
|
ID
|
implementation document
|
|
PA
|
product assurance
|
|
PRD
|
project requirements document
|
|
SDO
|
standard development organization
|
|
TM
|
technical memorandum
|
ECSS system objectives and policy
The overall objectives of using the ECSS system of standards include:
achieving more cost effective space programmes and projects in ,
improving the competitiveness of European space industry,
improving the quality and safety of space projects and products,
facilitating clear and unambiguous communication between all parties involved, in a form suitable for reference or quotation in legally binding documents,
reducing risk and guarantee interoperability and interface compatibility by applying proved and recognized requirements and methods.
In order to meet the above stated objectives, the ECSS policy has been developed: see ECSSP00.
ECSS documents are produced to support the formal customer-supplier relation in developing space programs and projects.
In order to ensure European space programmes and projects’ efficiency in terms of technical performance, life cycle cost-effectiveness and on-time deliveries, the ECSS System can be adapted to specific domains of application by use of tailoring activities.
See attachment “Example of ECSS Applicable Requirements Matrix (EARM)”.
Systematic feedback of experience from programmes, projects and other appropriate sources into the ECSS System allows improvement of ECSS Standards.
ECSS System description
Overview
The ECSS System has been developed as a cooperative effort between the European space agencies and space industries. It comprises a comprehensive set of documents addressing all essential aspects of the three major branches for the successful implementation of space programmes and projects, namely
Project management,
Engineering, and
Product assurance.
ECSS user oriented documents other than the present one and ECSSST0001 fall in one of those branches.
ECSS includes three types of documents: standards, handbooks and technical memoranda.
Types of ECSS documents
Standards
Standards are documents for direct use in invitation to tender and business agreements for implementing space related activities.
They state verifiable requirements, supported by the minimum descriptive text necessary to understand their context.
Each requirement contained within a Standard has a unique identification, allowing full traceability and easy verification of compliance.
Standards are named as ECSS-<X>-ST-<Number> <Version>, where:
<X> represents the branch and can take the following values: P or S (ECSS system), M (management), E (engineering) or Q (product assurance).
<Number> is one or two groups of two digits.
<Version> is a letter from “A” onwards.
When a requirement asks for the delivery of a document, the scope and content is specified in a dedicated DRD (Document Requirements Definition), which forms an integral part of a standard.
The ECSS Standards focus primarily on what is required to comply with each standard, rather than how to achieve this. This approach provides the flexibility for different customers and suppliers to use established “in–house” procedures, or processes, to comply with these standards.
Handbooks
Handbooks are non-normative documents providing background information, orientation, advice or recommendations related to one specific discipline or to a specific technique, technology, process or activity.
ECSS handbooks provide guidelines and good practices, and collection of data.
They are named as ECSS-<X>-HB-<Number> <Version>, where <X>, <Number> and <Version> have the same meaning than for standards.
Handbooks do not contain requirements, but provide additional information on selected topics addressed by the ECSS standards. Handbooks can be used as reference document or transformed into normative documents by the customer.
Technical memoranda
Technical memoranda are non-normative documents providing useful information to the space community on a specific subject.
They are prepared to record and present data which are not the subjects for a standard or for a handbook or not yet mature to be published as standard or handbook.
They are named as ECSS-<X>-TM-<Number> <Version>, where <X>, <Number> and <Version> have the same meaning than for standards.
Technical memoranda do not contain requirements, but provide additional information on selected topics addressed by the ECSS standards. Technical memoranda can be used as reference document and are not intended to be transformed into normative documents.
Structure and architecture of ECSS Standards System
Overview
The present document is the top level user document of ECSS. Beneath this document there are three parallel branches, one each for project management, engineering, and product assurance (see Figure 51). Project management branch documents have an “M” prefix, engineering standards have an “E” prefix, and product assurance standards have a “Q” prefix.
Some documents adopted by ECSS are originated from other Standard Development Organizations (SDO) (see ECSS-P-00 and Figure 51).
Within each branch, disciplines and corresponding requirements are covered by dedicated standards. ECSS Disciplines can also be supported by Handbooks (HB) and Technical Memoranda (TM) as necessary.
The disciplines addressed by the ECSS Standards system are given in Figure 52.
Figure 51: ECSS User Standards structured as Branches
Figure 52: Disciplines of the ECSS Standards system
Management (M-branch)
The overall objective of project management is to implement a process to achieve successful completion of the project in terms of cost, schedule and technical performance. Project management is performed following a structured approach throughout all stages of its life cycle and at all levels of the customer-supplier chain.
It integrates all management, engineering and product assurance functions required to execute the project.
Table 51 presents an overview of the disciplines covered by ECSS management branch. It is not intended to be exhaustive.
Table 51: Disciplines in the management branch
|
Discipline
|
Title
|
Scope / Objective
|
|
M-10
|
Project Planning and Implementation
|
Project planning and implementation discipline provides a coherent set of processes for minimizing the technical, scheduling and economic risks of the project. In particular this is done by:
|
|
M-40
|
Configuration and Information Management
|
Configuration management and information discipline:
|
|
M-60
|
Cost and Schedule Management
|
Cost and schedule management discipline provides a coherent set of processes for verifying the compliance of project planning and organization to ensure the consistent use of human resources, facilities, materials and funds to achieve the successful completion of the space project within its established goals: costs, schedule and performance.
|
|
M-70
|
Integrated Logistic Support
|
Integrated logistic support discipline covers the requirements necessary for logistic support throughout the system life cycle.
|
|
M-80
|
Risk Management
|
Risk management discipline identifies all risks (incl. new opportunities) and keeps these risks within defined and accepted boundaries that are defined in the risk policy of the project.
|
Engineering (E-branch)
ECSS-E disciplines cover the engineering aspects of space systems and products, including:
the engineering process as applied to space systems and their elements or functions, and
technical aspects of products used to accomplish, or associated with, space missions.
Table 52 presents an overview of the disciplines covered by ECSS engineering branch. It is not intended to be exhaustive.
Table 52: Disciplines in the engineering branch
|
Discipline
|
Title
|
Scope / Objective
|
|
E-10
|
System Engineering
|
The system engineering discipline is a multidisciplinary activity to technically coordinate the different engineering activities to ensure the overall technical consistency and integrity within the project. In particular it includes: System technical requirements definition analysis, integration and interfaces control, verification, and System activities providing constraints to others disciplines such as space environment, human factors and celestial mechanics, reference coordinates. Note: Equipment electromagnetic compatibility design aspects are included in the discipline E-20 “Electrical and Optical”.
|
|
E-20
|
Electrical and Optical Engineering
|
The electrical and optical engineering discipline addresses all aspects of the electrical, electronic, electromagnetic, microwave and optical engineering processes design of space products. In particular it includes:
|
|
E-30
|
Mechanical Engineering
|
The mechanical engineering discipline addresses all aspects of the mechanical design of space products. In particular it includes:
|
|
E-40
|
Software Engineering
|
The software engineering discipline addresses the life cycle processes for software products (e.g. requirements definition, architectural design, development, operations and maintenance). In particular it addresses the different types of software: on-board (embedded), on-ground, and software for qualification, testing and verification.
|
|
E-50
|
Communications
|
The communications discipline addresses all communication aspects related to:
|
|
E-60
|
Control Engineering
|
The control engineering discipline addresses aspects of automatic control in space systems. In particular it includes:
|
|
E-70
|
Ground Systems and Operations
|
The ground systems and operations discipline addresses the engineering of the ground segment and mission operations, which form an integral part of the overall system implementing a space project. In particular it includes: Procedures and languages for operations,
|
Product Assurance (Q-branch)
The prime objective of Product Assurance is to assure that the Space Products accomplish their defined mission objectives and more specifically that they are Safe, Available and Reliable. In support of project Risk Management, PA assures an adequate identification, appraisal, prevention and control of technical risks within project constraints.
Table 53 presents an overview of the disciplines covered by ECSS product assurance branch. It is not intended to be exhaustive.
Table 53: Disciplines in the product assurance branch
|
Discipline
|
Title
|
Scope / Objective
|
|
Q-10
|
Product Assurance Management
|
Product Assurance management is a multidisciplinary activity to ensure that a Product Assurance programme is implemented and managed throughout all project phases and coordinated with all actors. It addresses the Product Assurance Plan defining all PA activities consistent with the Project objectives, requirements, criticalities and constraints. In particular it includes:
|
|
Q-20
|
Quality Assurance
|
The quality assurance discipline addresses all aspects to ensure that product quality is specified according to customer needs, designed-in, built, verified and maintained in the products with associated documentation throughout project life cycle. In particular it addresses:
|
|
Q-30
|
Dependability
|
The dependability discipline addresses all aspects to ensure that the dependability performance (availability performance and its influencing factors reliability performance, maintainability performance and maintenance support performance) is met for the space product including system functions implemented in software and the interaction between hardware and software. In particular it includes:
|
|
Q-40
|
Safety
|
The safety discipline addresses all aspects to ensure that all safety risks associated with the design, development, production and operations of Space Product are identified, assessed, minimised, controlled and finally accepted through the implementation of a safety assurance programme. In particular it addresses the assessment of the risks based on qualitative and quantitative analyses (e.g. hazard, fault-tree, sneak).
|
|
Q-60
|
Electrical, Electronic, Electromechanical (EEE) Components
|
The EEE components discipline defines requirements for selection, control and procurement of EEE components for space projects to ensure that they satisfy the mission performance requirements during the full life cycle of the products. In particular it addresses:
|
|
Q-70
|
Materials, Mechanical Parts and Processes
|
The Materials, Mechanical Parts and Processes discipline defines requirements for selection, control and procurement of materials, mechanical parts and processes for space projects to ensure that they satisfy the mission performance requirements during the full life cycle of the products. In particular it addresses:
|
|
Q-80
|
Software Product Assurance
|
The Software Product Assurance discipline defines requirements to ensure that developed or reused software and software services perform properly and safely in their operational environments. It also includes requirements for the development of non-deliverable software which affects the quality of the deliverable product or service provided by a space system (e.g. test and verification software).
|
Introduction into space programmes
The customer-supplier model
The production of space systems calls for the cooperation of several organizations that share the common objective of providing a product that satisfies the customer’s needs (performance within cost and schedule constraints).
All space project actors are either a customer or a supplier, or both.
In its simplest form, a project can comprise one customer with just one supplier; however, most space projects comprise a number of hierarchical levels, where:
the actor at the top level of the hierarchy is the top level customer,
the actors at intermediate levels of the hierarchy are both supplier and customer,
the actors at the lowest level of the hierarchy are suppliers only.
Business agreements
Within the project, exchanges of products and services are governed by business agreements, used as a generic term throughout the ECSS Standards when referring to a legally binding agreement between two or more actors in the customer–supplier chain. These agreements include the terms and conditions agreed between the parties, the rules by which business is conducted, the actors’ commitments and obligations for the provision of goods and services, the methods of acceptance and compensation, monetary, or otherwise. Business agreements serve as a framework prescribing the activities throughout the execution of work, and as a reference to verify compliance.
Business agreements are recorded in a variety of forms, such as
Contracts,
Memoranda of understanding,
Inter–governmental agreements,
Inter–agency agreements,
Partnerships,
Bartering agreements, and
Purchase orders.
Applicability of ECSS documents
The ECSS documents themselves do not have legal standing and they do not constitute business agreements: they are made applicable by invoking them in business agreements, most commonly in contracts. The applicability of standards and requirements is specified in the project requirements documents (PRDs), which are included in business agreements, which are agreed by the parties and binding them.
Description of PRD is provided in ECSS-M-ST-10, Clause 4.1.10.
The top–level customer’s PRD forms the basis for the generation of all lower level customer PRDs. An integral part of a PRD, at any level, is the set of ECSS Standards tailored as necessary and documented in an “ECSS Applicability Requirements Matrix" (EARM), as described in clause 7.3.5.
A supplier, at any level, is responsible for demonstrating compliance with the project requirements contained in his customer’s PRD, through, for example, the elaboration of a compliance matrix, and ultimately for supplying a conforming product. The compliance to the PRD is presented in an Implementation Documents (IDs), for example project plans (e.g. management, engineering and product assurance) and compliance matrix.
Description of Implementation Document is provided in ECSS-M-ST-10.
The hierarchical structure in Figure 61 constitutes the customer–supplier chain within a project with its contractual chain of documents.
Figure 61: Customer–supplier network concept
Application of ECSS Standards
Introduction
The project’s requirements within the PRD are composed by two sets:
requirements covered by ECSS disciplines, subject to tailoring, and
other requirements specific to the project (not considered in this Clause, e.g. mission specific requirements)
The ECSS Standards and requirements to be made applicable at each level of the customer–supplier chain are influenced by the type and phase of the project involved, and by the type of business agreement to be used for managing the project.
The ECSS System provides a comprehensive set of coherent standards covering the requirements for the procurement of a generic space product. This system can be adapted to a wide range of project types. The process of adapting the requirements to the project specificities is called tailoring.
It is important to complete the preparatory activities (see clause 7.2) before addressing the range, degree and phasing of applicability of the total set of ECSS Standards to a particular project.
Figure 71 and the clauses 7.2 and 7.3 describe a recommended 7-step process for the preparation and application of tailoring to establish the applicability of ECSS Standards and their requirements to a project and to apply tailoring as necessary.
Preparatory activities
Identification of project characteristics - Step 1
Overall project characteristics are derived taking into account experience gained and lessons learned from comparable projects, and are used for establishing the project context, scope, scale, orientation and other elements key to the successful achievement of the project objectives. They are specified in both programmatic and technical terms. Programmatic characteristics cover overall risk policy, including risk sharing, as well as political, financial, schedule, economic and contractual aspects. Technical characteristics cover mission objectives (including life cycle and environment), technical complexity, technology, engineering, quality, scientific and product–oriented aspects.
Analysis of project characteristics and identification of risks - Step 2
After identifying its characteristics, the project is analysed to identify significant cost, schedule, technical drivers, as well as critical issues and specific constraints. These are used to identify and evaluate inherent and induced risks.
Main strategic, organisational, economical or technical characteristics considered for a project are as follows:
Objective of the mission (e.g. scientific, commercial, institutional);
Product type (e.g. space segment, space transportation segment, ground segment and operations, equipment, instrument);
characteristics (e.g. type of orbit, expected life duration, availability);
Constraints with the environment (e.g. external interfaces, external regulations, procurement constraints) the project belongs to;
Expected cost to completion;
Schedule drivers;
Level of commitment (e.g. partnership, supplier) or type of business agreement (e.g. fixed price, cost-reimbursement);
Maturity of design or technology (e.g. recurrent development, readiness level);
Technical product complexity;
Organisational or contractual complexity;
Supplier maturity.
This list is not exhaustive and can be completed according to project needs. Some elements of this list are imposed to the project, whereas the others are subject to choice within the project itself.
The resulting project risk factors are documented and the causes and consequences of the identified risks are determined. This is the first step in the risk management process, which is continued to monitor and manage risk mitigation actions throughout the life of the project.
Tailoring activities
Selection of applicable ECSS Standards - Step 3
Using the results of the preparatory activities as the primary input, the complete set of ECSS Standards is evaluated for relevance to the overall project needs. Those standards found to be relevant are identified as applicable standards for the implementation of the project. In making this determination, it is important to recognise that at this level, due to the integrated structure of the ECSS System, identifying a standard as directly applicable also makes other standards called by it explicitly applicable.
The subset of applicable standards selected through the above process can vary, depending mainly on the type, size and complexity of the project being addressed. The project phase, or phases, for which the applicability of ECSS Standards and their requirements is being selected, is another important factor to be considered. The early phases in a project lifecycle most often do not need a high percentage of the requirements available in ECSS Standards to be made applicable to achieve their objective. However, in order to establish an overall view of the phasing in of requirements, it is good practice that this initial selection of applicable standards covers all project phases up to and including the development phase, which is typically the most demanding phase of a project. With this initial selection established, appropriate and coherent subsets of the standards to be made applicable during the course of project implementation can then be selected to match the specific needs of the earlier project phases.
Selection of requirements from applicable standards - Step 4
Having established the list of applicable ECSS Standards for a project, the extent to which the requirements contained within these standards are made applicable is assessed against cost, schedule, and technical drivers, as well as against the identified risks and their mitigation strategies.
Each requirement within the applicable standards is assessed and classified as:
(Y) Applicable without change,
(M) Applicable with modification, or
(N) Not applicable (deleted).
Where all requirements in a standard are classified as applicable without change, the whole standard is fully applicable.
Where an applicable standard contains requirements of different classifications, these are recorded as follows:
for each requirement classified as (Y), the applicability is recorded as such;
for each requirement classified as (M), the modification can be a change to, or deletion of, part of the existing text, or new text added to the existing text to enhance or clarify the requirement. In all cases, the complete modified text is recorded and justified;
for each requirement classified as (N), the non–applicability is recorded and justified.
Where any requirement in an applicable standard is classified as (M), or (N), the standard is partially applicable.
Completion of requirements - Step 5
When a lack, which is not project specific, is identified in the requirements of an ECSS standard, a new requirement is generated or adopted preferably from a standard of an SDO. Such requirements are classified as:
(A) Additional requirement.For each requirement classified as (A), the complete new text is recorded and justified.
Harmonization of requirements - Step 6
Having completed the selection of applicable ECSS Standards and requirements and the addition of any new requirements in accordance with the above process, the coherence and consistency of the overall set of requirements to be applied to the project is reviewed to eliminate the risk of conflict, duplication, or lack of necessary requirements.
Documenting of requirements applicability - Step 7
The method of recording the applicability of ECSS Standards and requirements for a project in an efficient and structured manner is to consolidate it into an “ECSS Applicability Requirements Matrix” (EARM) or equivalent document, which will be part of the PDR. Annex A provides an example of a template of the EARM for the requirements of this Standard.
Figure 71: 7–step tailoring process
User feedback
The ECSS users apply ECSS documents to projects, including any adaptation through tailoring necessary to meet specific projects’ needs. They are also expected to provide feedback to the ECSS developers. This feedback is the primary source for maintaining and enhancing the ECSS System.
In addition to user feedback provided during the development of ECSS documents, following feedback is expected:
The set of requirements tailored from ECSS documents to the project specificities and made applicable as part of the business agreement(s). For example, this can be documented into an ECSS Applicable Requirements Matrix (EARM).
Status of compliance with respect to the above set of ECSS requirements. This can be documented into an ECSS Compliance Matrix (ECM). This matrix provides, during the development phase, the actual indication of compliance.
Change proposals to ECSS documents or to the ECSS System as a whole, provided in the form of an ECSS Change Request at any time; see form and process in Annex B.
This information represents important customer feedback because they provide information on how ECSS documents were applied and on how requirements evolved during project life cycle.
Any user feedback should in the end be made available to the ECSS Secretariat, via his/her representative in ECSS organisation (e.g. uploading information in the ECSS website (www.ecss.nl)), for recording and passing it to the appropriate ECSS bodies for assessment and further processing.
Requirements
Applicability
This clause addresses the requirements to make applicable the ECSS standards for the development of space products. The following requirements apply to any element of customer-supplier chain, from top to lowest level, as illustrated in Figure 61.
Requirements on customers
The customer shall select which ECSS Standards to make applicable and to use to establish the project/product requirements, including use of ECSS-S-ST-00-01 for terms and definitions.
The customer shall define, as part of the project requirements documentation (PRD), the set of requirements tailored from ECSS documents to the project specificities which are made applicable.
The customer shall produce, as part of the PRD, a documentation identifying the ECSS requirements applicable to the project.
An “ECSS applicable requirements matrix” (EARM) is a recommended method for this component of the PRD.
The documentation identifying the requirements applicable to the project shall include following data (e.g. EARM):
- The complete list of ECSS standards either fully or partially applicable to the project/product, including any standard (ECSS or not) made applicable via the chain of normative references;
- For each partially applicable standard, the status of each requirement: applicable without modification
applicable with modification
not applicable
- The complete list of additional requirements
- For modified and additional requirements, their complete formulation
Requirements on suppliers
The supplier shall demonstrate compliance with the PRD requirements.
An “ECSS compliance matrix” (ECM) is a recommended method to document the demonstration of this compliance. The ECM is part of the project compliance matrix, addressing compliance to the applicable ECSS requirements (e.g. EARM).
The documentation identifying the compliance to ECSS requirements applicable to the project (e.g. the ECM) shall include following data:
- The complete list of ECSS requirements applicable to the project (e.g. in the EARM).
- For each requirement, the actual indication of compliance. When deviation is identified the justification is provided.
ANNEX(informative)Example of template for an EARM for the requirements of ECSSSST00C
|
Identifier
|
Requirement
|
Applicable (A/M/D/N)
|
Modified requirement
|
|
9.2a.
|
The customer shall select which ECSS Standards to make applicable and to use to establish the project/product requirements, including use of ECSS-S-ST-00-01 for terms and definitions.
|
|
|
|
9.2b.
|
The customer shall define, as part of the project requirements documentation (PRD), the set of requirements tailored from ECSS documents to the project specificities which are made applicable.
|
|
|
|
9.2c.
|
The customer shall produce, as part of the PRD, a documentation identifying the ECSS requirements applicable to the project.
|
|
|
|
9.2d.
|
The documentation identifying the requirements applicable to the project (e.g. the EARM) shall include following data:
|
|
|
|
9.3a.
|
The supplier shall demonstrate compliance with the PRD requirements.
|
|
|
|
9.3b.
|
The documentation identifying the compliance to ECSS requirements applicable to the project (e.g. the ECM) shall include following data:
|
|
|
ANNEX(informative)ECSS Change Request / Document Improvement Proposal
A Change Request / Document Improvement Proposal for an ECSS Standard may be submitted to the ECSS Secretariat at any time after the standard’s publication using the form presented below. This form can be downloaded in MS Word format from the ECSS Website (www.ecss.nl, in the menus: Standards - ECSS forms).
Filling instructions:
Originator’s name - Insert the originator’s name and address
ECSS document number - Insert the complete ECSS reference number
Date - Insert current date
Number - Insert originator’s numbering of CR/DIP (optional)
Location - Insert clause, table or figure number and page number where deficiency has been identified
Changes - Identify any improvement proposed, giving as much detail as possible
Justification - Describe the purpose, reasons and benefits of the proposed change
Disposition
Once completed, please send the CR/DIP by e-mail to: ecss-secretariat@esa.int
Bibliography
|
ECSS-P-00
|
ECSS – Standardization policy
|
|
ECSS-M-ST-10
|
Space project management - Project planning and implementation
|
|
ECSS-M-ST-40
|
Space project management – Configuration and information management
|
|
ECSS-M-ST-60
|
Space project management - Cost and schedule management
|
|
ECSS-M-ST-70
|
Space project management - Integrated logistic support
|
|
ECSS-M-ST-80
|
Space project management - Risk management
|
|
ECSS-E-ST-10
|
Space engineering - System engineering general requirements
|
|
ECSS-E-ST-20
|
Space engineering - Electrical and electronic
|
|
ECSS-E-ST-31
|
Space engineering – Thermal control general requirements
|
|
ECSS-E-ST-32
|
Space engineering – Structural general requirements
|
|
ECSS-E-ST-34
|
Space engineering – Environmental control and life support (ECLS)
|
|
ECSS-E-ST-35
|
Space engineering – Propulsion general requirements
|
|
ECSS-E-ST-40
|
Space engineering - Software general requirements
|
|
ECSS-E-ST-50
|
Space engineering - Communications
|
|
ECSS-E-ST-60
|
Space engineering - Control engineering
|
|
ECSS-E-ST-70
|
Space engineering - Ground systems and operations
|
|
ECSS-Q-ST-10
|
Space product assurance - Product assurance management
|
|
ECSS-Q-ST-20
|
Space product assurance - Quality assurance
|
|
ECSS-Q-ST-30
|
Space product assurance – Dependability
|
|
ECSS-Q-ST-40
|
Space product assurance – Safety
|
|
ECSS-Q-ST-60
|
Space product assurance - Electrical, electronic and electromechanical (EEE) components
|
|
ECSS-Q-ST-70
|
Space product assurance - Materials, mechanical parts and processes
|
|
ECSS-Q-ST-80
|
Space product assurance - Software product assurance
|