European Cooperation for Space Standardization

Last updated

European Cooperation for Space Standardization
ECSS Logo.svg
Aerial view of ESA s technical centre ESTEC.jpg
Headquarters in Noordwijk, Netherlands
AbbreviationECSS
Established1993
Headquarters Noordwijk, Netherlands
Coordinates 52°13′02″N4°25′17″E / 52.21722°N 4.42139°E / 52.21722; 4.42139 Coordinates: 52°13′02″N4°25′17″E / 52.21722°N 4.42139°E / 52.21722; 4.42139
Membership
9 members
Official language
English
Parent organization
 European Space Agency
Website ecss.nl

The European Cooperation for Space Standardization (ECSS) is a collaboration between the European Space Agency (ESA), the European space industry represented by Eurospace, and several space agencies, to develop and maintain a coherent, single set of user-friendly standards for use in all European space activities. [1] Established in 1993 following a call by Eurospace to unify space products assurance standardization on a European level, [2] it was officially adopted by the ESA on 23 June 1994 through the resolution ESA/C/CXIII/Res.1, [3] to replace its own Procedures, Specifications and Standards (PSS) system. [4] The ECSS currently has 139 active standards, [5] forming the ECSS system. These standards cover management, engineering, product assurance, and space sustainability disciplines. [6] The ECSS is managed by the ESA Requirement and Standard Division, based in the European Space Research and Technology Centre (ESTEC) in Noordwijk, the Netherlands. The ECSS maintains connections with multiple European and international standardization organizations, to contribute to standardization and to adopt relevant standards as part of the ECSS system. [1]

Contents

History

Background

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

Foundation

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

Development and adoption

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.

  • YearReleases
    199617
    19975
    19984
    199915
    200015
    20015
    20029
    200313
    200413
    200511
  • YearReleases
    20067
    200710
    200887
    200926
    20108
    20115
    20126
    20138
    20146
    20153
  • YearReleases
    20163
    20178
    20185
    201911
    20208
    20218

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.

Organization

The ECSS is a cooperation by its definition; therefore, it is formed by an arrangement between European space agencies and industries. The administrative and technical organization of the ECSS is conducted by the ESA Requirement and Standard Division, acting as the ECSS central secretariat, based in the European Space Research and Technology Centre (ESTEC) in Noordwijk, the Netherlands. [1] The ESA holds the copyright for all ECSS documents on behalf of the members of ECSS. [21]

Structure

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.

Membership

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 :

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:

Mission

The ECSS presents itself as following:

The European Cooperation for Space Standardization is an initiative established to develop
a coherent, single set of user-friendly standards for use in all European space activities.

—  ecss.nl

Objectives

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.

Applicability

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]

ECSS System

The ECSS-S-ST-00 “ECSS System Description, Implementation, and General Requirements” document [30] defines the architecture of the ECSS system. The complete ECSS system is publicly available in a ZIP archive file format on the European Space Components Information Exchange System (ESCIES) server, [28] as well as in the IBM Engineering Requirements Management DOORS format. [32]

Naming convention

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

Document type

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

Standardization branches

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

Policy branch (P-branch)

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.

System description branch (S-branch)

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

Configuration and information management branch (D-branch)

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

Management branch (M-branch)

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

Engineering branch (E-branch)

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

Product assurance branch (Q-branch)

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

Space sustainability branch (U-branch)

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

See also

Related Research Articles

In computer science, test coverage is a percentage measure of the degree to which the source code of a program is executed when a particular test suite is run. A program with high test coverage has more of its source code executed during testing, which suggests it has a lower chance of containing undetected software bugs compared to a program with low test coverage. Many different metrics can be used to calculate test coverage. Some of the most basic are the percentage of program subroutines and the percentage of program statements called during execution of the test suite.

Configuration management Process for maintaining consistency of a product attributes with its design

Configuration management (CM) is a systems engineering process for establishing and maintaining consistency of a product's performance, functional, and physical attributes with its requirements, design, and operational information throughout its life. The CM process is widely used by military engineering organizations to manage changes throughout the system lifecycle of complex systems, such as weapon systems, military vehicles, and information systems. Outside the military, the CM process is also used with IT service management as defined by ITIL, and with other domain models in the civil engineering and other industrial engineering segments such as roads, bridges, canals, dams, and buildings.

Quality assurance (QA) is the term used in both manufacturing and service industries to describe the systematic efforts taken to insure that the product(s) delivered to customer(s) meet with the contractual and other agreed upon performance, design, reliability, and maintainability expectations of that customer. The core purpose of Quality Assurance is to prevent mistakes and defects in the development and production of both manufactured products, such as automobiles and shoes, and delivered services, such as automotive repair and athletic shoe design. Assuring quality and therefore avoiding problems and delays when delivering products or services to customers is what ISO 9000 defines as that "part of quality management focused on providing confidence that quality requirements will be fulfilled". This defect prevention aspect of quality assurance differs from the defect detection aspect of quality control and has been referred to as a shift left since it focuses on quality efforts earlier in product development and production and on avoiding defects in the first place rather than correcting them after the fact.

A standards organization, standards body, standards developing organization (SDO), or standards setting organization (SSO) is an organization whose primary function is developing, coordinating, promulgating, revising, amending, reissuing, interpreting, or otherwise contributing to the usefulness of technical standards to those who employ them. Such an organization works to create uniformity across producers, consumers, government agencies, and other relevant parties regarding terminology, product specifications, protocols, and more. Its goals could include ensuring that Company A's external hard drive works on Company B's computer, an individual's blood pressure measures the same with Company C's sphygmomanometer as it does with Company D's, or that all shirts that should not be ironed have the same icon on the label.

In software project management, software testing, and software engineering, verification and validation (V&V) is the process of checking that a software system meets specifications and requirements so that it fulfills its intended purpose. It may also be referred to as software quality control. It is normally the responsibility of software testers as part of the software development lifecycle. In simple terms, software verification is: "Assuming we should build X, does our software achieve its goals without any bugs or gaps?" On the other hand, software validation is: "Was X what we should have built? Does X meet the high-level requirements?"

In the context of software engineering, software quality refers to two related but distinct notions:

SpaceWire is a spacecraft communication network based in part on the IEEE 1355 standard of communications. It is coordinated by the European Space Agency (ESA) in collaboration with international space agencies including NASA, JAXA, and RKA.

A specification often refers to a set of documented requirements to be satisfied by a material, design, product, or service. A specification is often a type of technical standard.

The Concurrent Design Facility (CDF) is the European Space Agency main assessment center for future space missions and industrial review. Located at ESTEC, ESA's technical center in Noordwijk in The Netherlands, it has been operational since early 2000.

System requirements in spacecraft systems are the specific system requirements needed to design and operate a spacecraft or a spacecraft subsystem.

Verification in the field of space systems engineering covers two verification processes: Qualification and Acceptance

Worst-case circuit analysis is a cost-effective means of screening a design to ensure with a high degree of confidence that potential defects and deficiencies are identified and eliminated prior to and during test, production, and delivery.

The Time-Triggered Ethernet standard defines a fault-tolerant synchronization strategy for building and maintaining synchronized time in Ethernet networks, and outlines mechanisms required for synchronous time-triggered packet switching for critical integrated applications, IMA and integrated modular architectures. SAE International has released SAE AS6802 in November 2011.

In a manufacturing environment, a request for waiver (RFW) is a request for authorization to accept an item which, during manufacture or after inspection, is found to depart from specified requirements, but nevertheless is considered suitable for use as is or after repair by an approved method.

The Open Concurrent Design Server (OCDS) is an initiative of the European Space Agency, ESA. The OCDS aimed to provide the building blocks of a Concurrent, Collaborative and Distributed Engineering for the European Space Industry, using Open Standards Information Models and Reference Libraries.

ISO 10007 "Quality management — Guidelines for configuration management" is the ISO standard that gives guidance on the use of configuration management within an organization. "It is applicable to the support of products from concept to disposal." The standard was originally published in 1995, and was updated in 2003 and 2017. Its guidance is specifically recommended for meeting "the product identification and traceability requirements" introduced in ISO 9001:2015 and AS9100 Rev D.

ISO/IEC 29110: Systems and Software Life Cycle Profiles and Guidelines for Very Small Entities (VSEs) International Standards (IS) and Technical Reports (TR) are targeted at Very Small Entities (VSEs). A Very Small Entity (VSE) is an enterprise, an organization, a department or a project having up to 25 people. The ISO/IEC 29110 is a series of international standards and guides entitled "Systems and Software Engineering — Lifecycle Profiles for Very Small Entities (VSEs)". The standards and technical reports were developed by working group 24 (WG24) of sub-committee 7 (SC7) of Joint Technical Committee 1 (JTC1) of the International Organization for Standardization and the International Electrotechnical Commission.

ECLIPSE is a suite of software applications, intended for use by aerospace project and mission teams in managing their CM/QA/PA/PM activities.

The Allied Quality Assurance Publications (AQAP) are standards for quality assurance systems developed by NATO

ECSS-E-TM-10-25 "System Engineering - Engineering Design Model Data Exchange (CDF)" is a Technical Memorandum under the E-10 "System engineering" branch in the ECSS series of standards, handbooks and technical memoranda.

References

  1. 1 2 3 4 "Requirements and standards". www.esa.int. European Space Agency. Retrieved 25 May 2021.
  2. 1 2 3 4 Kriedte, W.; El Gammal, Y. (February 1995), A New Approach to European Space Standards (ESA Bulletin), vol. 81, European Space Agency, pp. 38–43, retrieved 25 May 2021
  3. 1 2 "Transition to ECSS software standards". www.esa.int. European Space Agency. 22 August 2006. Retrieved 25 May 2021.
  4. 1 2 "PSS documents". www.esa.int. European Space Agency. Retrieved 25 May 2021.
  5. 1 2 3 "ECSS Active Standards". ecss.nl. European Cooperation for Space Standardization. Retrieved 25 May 2021.
  6. 1 2 "Document Tree". ecss.nl. European Cooperation for Space Standardization. Retrieved 25 May 2021.
  7. ↑ "ESA turns 30! A successful track record for Europe in space" (Press release). ESA Media Relations Division. 31 May 2005. Retrieved 25 May 2021.
  8. ↑ European Space Agency (May 1977), ESA-4487 ESA/ADMIN(77)18 (Administrative note) (in English and French)
  9. ↑ "Board for Software Standardisation and Control (BSSC)". www.esa.int. European Space Agency. 1 October 2012. Retrieved 25 May 2021.
  10. ↑ Jones, M.; Mazza, C.; Mortensen, U.K.; Scheffer, A. (May 1997), 1977-1997: Twenty Years of Software Engineering Standardisation in ESA (ESA Bulletin), vol. 90, European Space Agency, pp. 39–45, retrieved 25 May 2021
  11. ↑ ESA Board for Software Standardisation and Control (February 1991), ESA PSS-05-0 Software Engineering Standards (PDF) (Standard), retrieved 25 May 2021
  12. 1 2 European Cooperation for Space Standardization (4 April 2000), ECSS-P-00A Standardization policy (Standard), retrieved 25 May 2021
  13. ↑ "CENELEC European Partners". www.cenelec.eu. European Committee for Electrotechnical Standardization. Retrieved 25 May 2021.
  14. ↑ "CEN European Partners". standards.cen.eu. European Committee for Standardization. Retrieved 25 May 2021.
  15. ↑ "ISO/TC 20/SC 14 Space systems and operations (Liaisons)". www.iso.org. International Organization for Standardization. Retrieved 25 May 2021.
  16. ↑ "Estrack ground stations". www.esa.int. European Space Agency. Retrieved 25 May 2021.
  17. ↑ Nyirady, Annamarie (24 September 2019). "ESA Selects AdaCore for Spacecraft Software Development Solution". Via Satellite. Retrieved 25 May 2021.
  18. ↑ Tyrrell, Michael (1 May 2020). "AM nanosatellite fuel tank design could be 'game changer'". Aerospace Manufacturing. Retrieved 25 May 2021.
  19. ↑ "Reflex Photonics to Demo its New Radiation–Resistant SpaceABLE Optical Transceivers at Space Tech Expo USA 2018" (Press release). Reflex Photonics. PRWeb. 16 May 2018. Retrieved 25 May 2021.
  20. ↑ Ford, Jason (11 July 2014). "None more black: UK engineers create world's darkest material". The Engineer. Retrieved 25 May 2021.
  21. ↑ "License agreement – Disclaimer". ecss.nl. European Cooperation for Space Standardization. Retrieved 25 May 2021.
  22. 1 2 3 European Cooperation for Space Standardization (22 March 2013), ECSS-P-00C Standardization objectives, policies and organization (Standard), retrieved 25 May 2021
  23. ↑ "Steering Board". ecss.nl. European Cooperation for Space Standardization. Retrieved 25 May 2021.
  24. ↑ "Technical Authority". ecss.nl. European Cooperation for Space Standardization. Retrieved 25 May 2021.
  25. ↑ "Executive Secretariat". ecss.nl. European Cooperation for Space Standardization. Retrieved 25 May 2021.
  26. ↑ "TA Area Responsibles and Discipline Focal Points". ecss.nl. European Cooperation for Space Standardization. Retrieved 25 May 2021.
  27. ↑ "Members". ecss.nl. European Cooperation for Space Standardization. Retrieved 25 May 2021.
  28. 1 2 "ECSS System Standards and Handbooks (ESCIES FTP Server)". escies.org. European Space Components Information Exchange System. Retrieved 25 May 2021.
  29. ↑ "ECSS Training". ecss.nl. European Cooperation for Space Standardization. Retrieved 25 May 2021.
  30. 1 2 European Cooperation for Space Standardization (15 June 2020), ECSS-S-ST-00C Rev.1 Description, implementation and general requirement (Standard), retrieved 25 May 2021
  31. ↑ European Cooperation for Space Standardization (15 June 2020), ECSS-S-ST-00-02C Draft 1 Tailoring (Standard), retrieved 25 May 2021
  32. ↑ "DOORS database download". ecss.nl. European Cooperation for Space Standardization. Retrieved 25 May 2021.
This page is based on this Wikipedia article
Text is available under the CC BY-SA 4.0 license; additional terms may apply.
Images, videos and audio are available under their respective licenses.