European Cooperation for Space Standardization

On 31 July 1973, the foundations of the Ariane project were laid, that contributed to the merging of the European Launch Development Organization (ELDO) and the European Space Research Organization (ESRO), resulting in the creation of the European Space Agency (ESA) on 31 May 1975.[7] Engineers quickly realized the need for standards and for formal requirements definition, both essential to manage project execution, to respect project deadlines, and to provide quality assurance. Concerning software engineering, the ESA's Board for Software Standardization and Control (BSSC) was established in May 1977 through the administrative note ESA/ADMIN(77)18.[8] The BSSC had three responsibilities: defining software engineering standards, the compilation of these standards, and safeguarding the intellectual property rights of developed software.[9] Standardization was initially received negatively by some engineers, as developing complex space systems required special and unique methods. However, appreciation quickly grew after the first work accomplished by the BSSC that defined the software life cycle and its phases. This work established a common terminology that facilitated communication and experience exchange between work groups. The next accomplishment of the BSSC were the documents known as “pink documents” (due to the color of the papers used for printing), that consisted of a set of documents each covering a specific phase of the software life cycle. Through the five years following the creation of the BSCC, and with the growing adoption of the pink documents, opposition to standardization gradually decreased.[10] By the end of 1982, a full set of pink documents defining the complete software life cycle was available, and released as a single volume in 1984, known as the ESA Software Engineering Standards ESA BSSC (84)1, Issue 1. Following further review and update, the ESA BSSC (84)1 was published as part of the ESA “Procedures, Specifications and Standards” (PSS) documents, as a fully mature standard. First released in January 1987 as “PSS-05-0, Issue 1”, then updated and released in February 1991 as “PSS-05-0, Issue 2”.[11] In total, the ESA worked on the standardization of ten branches:[4]

1. PSS-01-0 Product Assurance and Safety
2. PSS-02-0 Electrical Power and EMC
3. PSS-03-0 Mechanical Engineering and Human Factors
4. PSS-04-0 Space Data Communications
5. PSS-05-0 Software Engineering
6. PSS-06-0 Management and Project Control
7. PSS-07-0 Operations and EGSE
8. PSS-08-0 Natural and Induced Environment
9. PSS-09-0 Control Systems
10. PSS-10-0 Ground Communications and Computer Networking

While the ESA developed the PSS system for its projects, the different space agencies in Europe relied on a multiplicity of standards. In 1988, the first call to unify standardization on a European level originated from Eurospace, an association of European companies involved in space activities. Several efforts were subsequently initiated to achieve this objective. In the autumn of 1993, a number of national space agencies (mentioned below), alongside several European industrial organizations represented by Eurospace, signed the European Cooperation for Space Standardization (ECSS) terms of reference.[2] A work group was established to define the Standardization Policy, approved by the Steering Board under the title ECSS-P-00 by late 1993. This document was publicly released on 4 April 2000, as ECSS-P-00A.[12] On 23 June 1994, the ESA council adopted the resolution ESA/C/CXIII/Res.1, formally initiating the transfer of the PSS system to the new ECSS system.[3] The ECSS secretariat initially aimed to complete the transfer by the end of June 1995. By February 1995, the active entities participating to drafting the ECSS system were:[2] European Space Agency (ESA), Eurospace on behalf of the European space industry, Agenzia Spaziale Italiana (ASI), Belgian Office for Scientific, Technical and Cultural Affairs (OSTC), British National Space Centre (BNSC), Centre National d’Études Spatiales (CNES), Deutsche Agentur für Raumfahrtangelegenheiten (DARA), Norwegian Space Centre (NSC), and Canadian Space Agency (CSA).

The first results of the ECSS efforts were released on 19 April 1996, with the publication of 17 standard documents. In parallel to defining and compiling standardization documents, the ECSS actively worked on developing regional and international liaisons in the objective of achieving a formal status of a selected part of the developed standards, either as European Standards (EN), or as International Organization for Standardization (ISO) standards.[12] The first agreement between the ECSS and the European Committee for Electrotechnical Standardization (CENELEC)[13] was signed on 6 June 1997, in view to incorporate the ECSS engineering standards (E-branch) in the body of CENELEC European standards (EN). Shortly after on 19 June 1997, the cooperation protocol with the European Committee for Standardization (CEN)[14] was defined and signed, in view to implement the management (M-branch) and product assurance (Q-branch) standards in the body of CEN standards. On 15 May 1998, a co-operation agreement between the ECSS and the space systems and operations ISO committee ISO/TC20/SC14[15] was established, with the objective being to avoid duplication, improve harmonization, and to achieve the benefit of reciprocal expertise in the field of space standardization. As of May 2021, the table below shows the total number of standards published per year by the ECSS (316 total releases, with 139 currently active[5]). The surge observed in 2008 is the result of adopting a new ECSS standards template, aiming for the harmonization and improved organization of the ECSS system.

Since its creation, the ECSS promotes the application of its standards for all European space activities.[1] Currently, the ECSS standards are essential in ESA projects (e.g. the ESTRACK stations[16]), but are also widely adopted by the European space industry. These standards have been applied to the qualification of software engineering (e.g. AdaCore's Ravenscar SFP run-time[17]), mechanical parts (e.g. AMRC nanosatellite fuel tank burst pressure[18]), radiation hardening (e.g. Reflex Photonics transceivers radiation dose tolerance[19]), material processes (e.g. Surrey Nanosystems super black coating[20]), among others.

The ECSS organization structure, called the ECSS Developer Structure, is defined by the ECSS-P-00C “ECSS Standardization objectives, policies and organization” document.[22] The developer structure consists of five entities. The Steering Board[23] is responsible for elaborating the ECSS objectives, policy, strategies. The Technical Authority[24] is responsible for implementing the Steering Board decisions. The Executive Secretariat[25] is responsible for administrative support, promoting the ECSS, and managing communication. The Network of Expert[26] is responsible for technical support to the technical authority and executive secretariat. Finally, the Working Groups are initiated as needed, and are responsible for defining or updating standards.

The ECSS encourages all users and suppliers of space products conforming to the ECSS standards to contribute to the ECSS system development through experience and expertise feedback. However, formally participating to the pursuit of the ECSS objectives must be done under one of the three defined types of membership: full members, associates, or observers.[22][27]

Full members are the entities actively supporting the ECSS in the development of standard documents, and ensuring the adoption of the ECSS system in their respective projects. Currently, the ECSS full members are :

• Agenzia Spaziale Italiana (ASI)
• UK Space Agency (UKSA)
• Centre National d’Etudes Spatiales (CNES)
• Deutsches Zentrum für Luft- und Raumfahrt (DLR)
• European Space Agency (ESA)
• Netherlands Space Office (NSO)
• Norwegian Space Centre (NOSA)
• Eurospace on behalf of the European space industry

The four European space companies contributing to ECSS development through Eurospace with voting rights are: Airbus Defence and Space, ArianeGroup, OHB System, and Thales Alenia Space.

Associate members are the entities that contribute with limited efforts, or on specific subjects, while committing to the adoption of the standards to which they contributed. Currently, the only associate member is the Canadian Space Agency (CSA).

Observers are the entities that wish to contribute by providing recommendations and expertise feedback resulting from the observation of the ECSS system development. Currently, the ECSS observers are:

• European Committee for Standardization (CEN)
• European Committee for Electrotechnical Standardization (CENELEC)
• European Organisation for the Exploitation of Meteorological Satellites (EUMETSAT)
• European Commission (EC)
• European Defence Agency (EDA)

The ECSS-P-00C “ECSS Standardization objectives, policies and organization” document[22] defines the objectives of the ECSS efforts. The main interests are the improvement of project cost efficiency, the assurance of product quality and safety, the expansion of interoperability, and the harmonization of the European space sector. All of these interests serve to improve the competitiveness of the European space sector. The ECSS maintains its liaisons with various standardization organizations, contributing to standardization, as well as adopting pertinent existing standards into the ECSS system.

The ECSS actively works to promote the adoption of its standards by the European space community, by making its documents freely available worldwide,[28] and by providing the adequate training[29] for potential users. However, the actors of the European space community are not systematically obligated to adhere to the ECSS system. The ECSS documents are made applicable through a legal document, such a business agreement contract.[30] The ECSS does not provide nor recognize any certification process for compliance with the ECSS system. The party imposing the use of ECSS documents is responsible for supervising and verifying the correct application. However, the ECSS system defines a tailoring process to help in elaborating the ECSS Applicability Requirements Matrix (EARM), which serves to identify the applicability of ECSS standards and requirements to a given project. This tailoring process is defined in the ECSS-S-ST-00-02 “ECSS System Tailoring” document.[31]

The ECSS uses the following format in naming its documents in the S, M, E, Q, and U branches:

ECSS-Branch-<Document Type>-<Number><Version> <Revision>

• The Branch field identifies the standardization branch to which the document belongs, and may take the value of S, M, E, Q, or U.
• The <Documents Type> field identifies the type of the document, and may take the value of ST, HB, TM, AS, or AH.
• The <Number> field is one or two groups of two digits that identify the discipline and the hierarchy of the document.
• The <Version> field is a letter from “A” onwards identifying the release version.
• The <Revision> field is used to indicate an updated release of the same version.

The documents belonging to the P and D branches are not identified by a document type, and are named as ECSS-P-00 and ECSS-D-00-<Number> respectively.

The documents released by the ECSS are classified under five document types:

• Standards (ST) are normative documents defining verifiable requirements, and providing the minimum necessary description.
• Handbooks (HB) are non-normative documents used as reference that may contain guidelines, good practices, and/or collections of data. They may serve as normative documents by the user.
• Technical memoranda (TM) are information documents that cannot be used as normative documents.
• Adoption notices for standards (AS) are normative documents formalizing the adoption of non-ECSS standards, and identifying the related added or modified clauses and requirements specific to the ECSS system.
• Adoption notices for handbooks (AH) formalize the adoption of non-ECSS handbooks.

The ECSS system uses seven branches[6] to classify its documents,[5] of which four are user oriented standardization disciplines (M, E, Q, and U branches), and the other three are related to the definition and development of the ECSS system (P, S, and D branches).

The ECSS policy branch (P-branch), as its name implies, defines the policy, objectives, and organization of the ECSS. This branch consists of a single document, which is the first document developed by the ECSS:[2]

• ECSS-P-00: ECSS - Standardization Objectives, Policies and Organization.

The ECSS system description branch (S-branch) documents are the top-level documents describing the ECSS system, and defining its applicability. This branch contains three documents:

• ECSS-S-ST-00: ECSS System - Description, Implementation, and General Requirements
• ECSS-S-ST-00-01: ECSS System - Glossary of terms
• ECSS-S-ST-00-02: ECSS System - Tailoring

The ECSS configuration and information management branch (D-branch) defines the lifecycle of ECSS documents, the templates for different document types, and the criteria for review and release. This branch contains four documents:

• ECSS-D-00: ECSS - ECSS Organization and Processes
• ECSS-D-00-01: ECSS - Drafting Rules and Template for ECSS Standards
• ECSS-D-00-02: ECSS - Drafting Rules and Template for ECSS Handbooks
• ECSS-D-00-11: ECSS - Criteria for Acceptance for Public Review and Criteria for Handbook Release for Publication

The ECSS management branch (M-branch) develops the project management process. This branch contains six documents distributed over five management disciplines:

• M-10 Project Planning and Implementation: ECSS-M-ST-10 and ECSS-M-ST-10-01
• M-40 Configuration and Information Management: ECSS-M-ST-40
• M-60 Cost and Schedule Management: ECSS-M-ST-60
• M-70 Integrated logistic support: ECSS-M-70 (released prior to the current naming convention, ECSS-M-ST-70 is in development)
• M-80 Risk Management: ECSS-M-ST-80

The ECSS engineering branch (E-branch) defines the standard engineering processes and technical requirements of space systems. This branch contains 65 documents distributed over seven disciplines (except ECSS-E-AS-11C):

• E-10 System Engineering: 9 ECSS-E-ST-10-... documents
• E-20 Electrical and Optical Engineering: 7 ECSS-E-ST-20-... documents
• E-30 Mechanical Engineering, divided into five sub-disciplines:
  • E-31 Thermal: 3 ECSS-E-ST-31-... documents
  • E-32 Structural: 7 ECSS-E-ST-32-... documents
  • E-33 Mechanisms: ECSS-E-ST-33-01 and ECSS-E-ST-33-11
  • E-34 Environment Control and Life Support : ECSS-E-ST-34
  • E-35 Propulsion: 6 ECSS-E-ST-35-... documents
• E-40 Software Engineering: ECSS-E-ST-40 and ECSS-E-ST-40-07
• E-50 Communications: 6 ECSS-E-AS-50-... and 11 ECSS-E-ST-50-... documents
• E-60 Control Engineering: 4 ECSS-E-ST-60-... documents
• E-70 Ground Systems and Operations: 6 ECSS-E-ST-70-... documents

The ECSS product assurance branch (Q-branch) defines the methods and requirements relevant to assure the safety and reliability of space products. This branch contains 62 documents distributed over seven disciplines:

• Q-10 Product Assurance Management: 3 ECSS-Q-ST-10-... documents
• Q-20 Quality Assurance: 4 ECSS-Q-ST-20-... documents
• Q-30 Dependability: 4 ECSS-Q-ST-30-... documents
• Q-40 Safety: 3 ECSS-Q-ST-40-... documents
• Q-60 Electrical, Electronic, and Electromechanical Components: 7 ECSS-Q-ST-60-... documents
• Q-70 Materials, Mechanical Parts, and Processes: 40 ECSS-Q-ST-70-... documents
• Q-80 Software Product Assurance: ECSS-Q-ST-80

The ECSS space sustainability branch (U-branch), initiated in 2012, defines two disciplines: space debris mitigation and planetary protection. This branch currently consists of one document for each discipline:

• U-10 Space Debris: ECSS-U-AS-10
• U-20 Planetary Protection: ECSS-U-ST-20