This article is part of a blog series on the European Cooperation for Space Standardization (ECSS) standards. It gives an overview of the European software standards for space and details the process of developing, then verifying, safe compliant software.

You can find links to each part below:

• Part 1 (this blog): An introduction to ECSS-E-ST-40 Rev.1 and ECSS-Q-ST-80C Rev.2
• Part 2: Efficient Design and Implementation of Safe Space Software in compliance with ECSS-E-ST-40 Rev.1 and ECSS-Q-ST-80C Rev.2 using SCADE Suite
• Part 3: Efficient Verification and Validation of Safe Space Software in compliance with ECSS-E-ST-40 Rev.1 and ECSS-Q-ST-80C Rev.2 using SCADE Suite

This article introduces the two main software standards ECSS-E-ST-40 Rev.1 and ECSS-Q-ST-80C Rev.2 titled “Space engineering – Software” and “Space product assurance – Software product assurance” respectively.

ECSS Standards

In 1958, the Committee on the Peaceful Uses of Outer Space (COPUOS) was set up by the General Assembly of the United Nations (UN) in order to:

• review the scope of international cooperation in peaceful uses of outer space
• devise programs in this field to be undertaken under UN responsibility
• encourage continued research and the dissemination of information on outer space matters, and
• study legal problems arising from the exploration of outer space.

In 1967, the Outer Space Treaty was adopted by UN. Key principle: “No one can claim all or part of space as their own, but everyone can explore it and benefit from its resources for peaceful purposes”.

In 1994, European Cooperation for Space Standardization (ECSS) was established to develop and maintain a consistent, single set of standards. ECSS is composed of the European Space Agency (ESA), national space agencies (UK Space Agency, Deutsches Zentrum für Luft- und Raumfahrt (DLR), Centre National d’Etudes Spatiales (CNES), etc.), and European Industry represented by Eurospace.

ECSS defines standards that help space missions meet Outer Space Treaty (OST) obligations, e.g., avoiding contamination, preventing space debris, ensuring liability compliance. For example: the OST states that a country is liable for damage caused by its space objects. ECSS standards help reduce risk by ensuring spacecraft reliability and safety.

ECSS standards have the following properties:

• they are objective-oriented,
• they incorporate lessons learned from past projects and user feedback,
• they are not regulatory, their applicability is decided on a case-by-case basis, by commercial clause,
• they are highly tailorable. The tailoring process is explicitly planned, described and promoted in the standard documents,
• they are designed as a complete consistent package.

The following figure shows the ECSS disciplines in more detail.

ECSS Disciplines

ECSS-E-ST-40 Rev.1 and ECSS-Q-ST-80C Rev.2 (named ECSS-E-ST-40 and ECSS-Q-ST-80C in the remainder of this document) are two normative standards (i.e., normative documents for direct use in invitations to tender and business agreements) related to software product development. They are linked to other ECSS standards like: ECSS-Q-ST-30C – dependability, ECSS-Q-ST-40C – safety, ECCS-S-ST-00C – description, implementation and general requirements, etc. They are applicable to:

• all space elements including the space segment, the launch service segment and the ground segment
• non-deliverable software that affects the quality of the deliverable product (i.e. supporting tools, firmware, etc.).

ECSS-E-ST-40 and ECSS-Q-ST-80C description

Software Criticality categories

ECSS-Q-ST-40C Rev.1 (Space product assurance – Safety) and ECSS-Q-ST-30C Rev.1 (Space product assurance – Dependability) define four function severity categories from Catastrophic (the most severe) to Minor or Negligible (the least severe). These severity categories are common to dependability and safety.

A function implemented in a space system is assigned with a criticality category in accordance with the severity of identified hazardous events it can cause, following the categories depicted in the table below (ECSS-Q-ST-30C §5.3.2.a, ECSS-Q-ST-40C §6.4.1k).

System Severity Categories – ECSS-Q-ST-30C Table 5-1, ECSS-Q-ST-40C Table 6-1

At software level, a software product is assigned a criticality category based on the criticality assigned to the most critical function it implements, and meeting the criteria defined in ECSS-Q-ST-30C §5.4 and in ECSS-Q-ST-40C §6.5.6.3 (see ECSS-Q-ST-80C §6.2.2.1).

The table below describes the relationship between the criticality category of the software products, the highest criticality of the functions implemented by the software and the existing system compensating provisions (ECSS-Q-ST-80C §D-1).

Software Criticality Categories – ECSS-Q-ST-80C Table D-1

ECSS-E-ST-40C Space engineering – Software

ECSS-E-ST-40C provides requirements for the software development life cycle:

Software related system requirement process

The software-related system requirements process establishes the functional, performance, and interface requirements baseline for software development. It connects the space system engineering processes defined in ECSS-E-ST-10 (Space engineering – System engineering general requirements) and ECSS-E-ST-70 (Space engineering – Ground systems and operations) with software processes.

According to the ECSS recursive customer-supplier model, each customer is responsible for delivering a system that integrates the developed software and for defining lower-level system and software requirements.

According to ECSS-E-ST-10, system engineering produces:

• in phase A (called feasibility phase): “lower-level element functional specification” along with possible system solutions,
• in phase B (called preliminary definition phase): “technical specification (TS)” of lower-level elements in the preliminary definition for the system solution selected at end of Phase A and established in phase B.

For software, the Requirement Baseline (RB) is the full set of these two specifications.

Software management process

This process governs the entire software project life cycle and aligns with the management (M) branch of the ECSS standards (see the first figure of this blog), particularly ECSS-M-ST-10 (Space project management – Project planning and implementation), and is adapted for software-specific management.

The core activity is the creation of a Software Development Plan (SDP) detailing the software life cycle, activities, milestones, deliverables, applied techniques, and identified risks. The management process further covers the organization of joint reviews, system interface management, and technical budget and margin control.

Software requirements and architecture engineering process

This process defines how the supplier develops the Technical Specification (TS) which includes the Software Requirements Specification (SRS) and a preliminary Interface Control Document (ICD), as a response to the requirements baseline and interface requirements. It also produces a preliminary Software Design Document (SDD) describing the software architecture.

To support design rationale, a Design Justification File (DJF) is produced to record all major trade-offs, feasibility studies, make-or-buy decisions, and technical assessments.

Software design and implementation engineering process

This process produces the detailed design of software items based on the Technical Specification (TS), Interface Control Document (ICD), and preliminary Design Definition File (DDF). The DJF records the rationale for major design decisions, along with analysis and test data demonstrating compliance with requirements.

Additionally, this process encompasses coding, unit testing, and integration testing, with all test activities and evidence documented in the DJF.

Software requirements, architecture and detailed design activities will be further addressed in Part 2 of this blog seriesx.

Software validation process

This process confirms that “the technical specification and the requirements baseline functions and performances are correctly and completely implemented in the final product“. The results are included in the DJF.

Software delivery and acceptance process

This process ensures that the software product is ready for delivery and validation within its operational environment. It concludes with an Acceptance Review (AR), which uses the DJF as a primary input. The acceptance review is a formal event for the evaluation of the software in its intended environment. It takes place after the software has been delivered to the customer and installed in its operational environment.

Software verification process

This process is transversal to all other processes. It aims to confirm that for every activity, specifications and inputs are available and that the outputs are correct and consistent with these specifications and inputs.

All expected outputs of the development activities are subject to set of verification activities described in this process.

The result of this process is included in the DJF and reported at each review. In addition, this process can be executed with varying degrees of independence.

It is worth mentioning that ECSS-E-ST-40C § 5.8.3.5a provides detailed requirements for code verification. In Rev.1, the requirement is complemented by a new informative Annex (Annex U) providing an extensive list of code checks which “aim at ensuring the quality of the software code and at improving the security of the systems that use it“.

Part 3 of this blog series will explain how SCADE Suite environment supports the validation and verification activities, in particular native compliance with Annex U of ECSS-E-ST-40C.

Software operation process

The software operation process begins after the Acceptance Review and is governed by system-level requirements. Unlike spacecraft or payload operations, software operation in ECSS-E-ST-40C standard primarily involves helpdesk support and coordination between users, developers/maintainers, and the customer.

The Software Operation Support (SOS) entity is responsible for keeping the software operational.

Software maintenance process

This process begins after software qualification and before or during operational use. It addresses “software product modification to code or associated documentation for correcting an error, a problem or implementing an improvement or adaptation”. It instantiates the maintenance process for software.

Its main objective is to update existing software while maintaining functional integrity. The process also includes migration and retirement activities of the software product.

Software security process

Newly added in Rev.1, this process is performed all along the software life cycle. It is integrated with all other processes and with risk management. It aims at ensuring “that security risks are properly addressed over the lifecycle of the software”. It is mainly based on security analyses that are performed and maintained at each product’s hierarchical level.

ECSS-Q-ST-80C Space product assurance – Software product assurance

ECSS-Q-ST-80C provides requirements for software product assurance. The standard addresses:

Software product assurance program implementation

The aim of this clause is:

• To establish and organize the software product assurance program.
• To manage assurance activities throughout the project.
• To provide assurance evidence and control mechanisms.

This clause includes:

• Organization and responsibility
• Program management: planning and control, reporting, audit, alerts, problem management, non-conformance
• Risk management and control of critical items
• Supplier selection
• Procurement
• Tools and supporting environment, including guidance about tool selection criteria:
  • Suitability and appropriateness of the development environment w.r.t. the functional and operational characteristics of the product
  • availability
  • compatibility
  • performance
  • maintenance
  • the available support documentation
  • the acceptance and warranty conditions
  • the conditions of installation, preparation, training and use
  • the maintenance conditions, including the possibilities of evolutions
  • etc.
• Assessment and improvement processes.

Software process assurance

The aim of this clause is to ensure that:

• All software life-cycle processes are correctly planned, implemented, and verified in compliance with applicable ECSS standards.
• Process adherence, consistency, and effectiveness are monitored through reviews, audits, and assessments.
• Nonconformances and process deviations are identified, controlled, and resolved to maintain confidence in the overall software development and maintenance process.

This clause includes:

• Software development life cycle
• Requirements applicable to all software engineering processes, including software security and how to handle critical software:
  • failure isolation and handling
  • defensive programming
  • use of a “safe subset” of programming language
  • use of formal design language for formal proof
  • 100 % code branch coverage at unit testing
  • full inspection of source code
  • witnessed or independent testing
  • gathering and analysis of failure statistics
  • removing deactivated code or strong justification
  • removing unreachable code
  • etc.
• Requirements applicable to individual software engineering processes or activities

The clause also defines requirements applicable in case of automatic code generation, for instance:

• Appropriate selection of the code generator tool (tool interoperability, code portability, design and code metrics, verifiability of the generated code, compliance with open standards)
• Testing of the generated code
• V&V of the code generator in compliance with the standard’s objectives (like embedded software)
• Adherence to modeling standards
• Adherence to coding standards if the generated code is manually modified.

Software product quality assurance

The aim of this clause is to:

• Ensure the software product conforms to all technical and quality requirements defined in the project baseline.
• Verify that the delivered software is complete, consistent, and verified through systematic reviews, tests, and audits.
• Provide objective evidence of product quality and compliance, ensuring traceability from requirements to the final software product.

This clause includes:

• Product quality objectives and metrication including requirements about:
  • Basic metrics:
    • size (code)
    • complexity (design, code)
    • fault density and failure intensity
    • test coverage
    • number of failures
  • Numerical accuracy estimation and verification
  • Definition of quality requirements for design complexity and modularity
  • Code portability (independence from the operating system and the hardware)
• Product quality requirements
• Software intended for reuse
• Standard ground hardware and services for operational system
• Programmable devices

In addition to these clauses, Annex C depicts the structure of the software documents to be produced in accordance with the requirements defined in ECSS-Q-ST-80C and ECSS-E-ST-40.

Further details about handling critical software, automatic code generation and metric computation using the SCADE Suite environment are provided in Part 3 of this blog series.

Tailoring

As mentioned earlier in this blog, ECSS standards are highly tailorable, and the tailoring is described within the standards themselves:

• ECSS‐S‐ST‐00-02C-DRAFT1 provides the methodology and requirements for tailoring of the ECSS system using the pre-tailoring done by ECSS (process defining the list of standards and requirements applicable to a product type).
• ECSS-E-ST-40 Annex R and ECSS-Q-ST-80C Annex D (both normative) for tailoring based on software criticality categories.
• ECSS-E-ST-40 Annex S and ECSS-Q-ST-80C Annex E (both informative) for general tailoring.
• In ECSS-E-ST-40, factors for tailoring the software development lifecycle are:
  • Technical factors (complexity of the software and the system, size of the software, etc.)
  • Operational factors (expected lifetime of the software, operation, maintenance, migration and retirement constraints, etc.)
  • Management factors (budget requirements, accepted risk level for the project, experience of the supplier, etc.)
  • etc.
• List of conditional requirements to be customized (for example, requirements applicable only for flight software or for ground software).
• List of requirements with customer – supplier agreement (for example code coverage value).

The following figure shows a sample extract from ECSS-E-ST-40 Annex R for requirements tailoring based on software criticality categories where:

• Y: means that the requirement is applicable to that criticality category. The activity and the expected output are required;
• N: means that the requirement is not applicable to that criticality category. Neither the activity nor the expected output are required;
• Ytba (Yes, to be agreed): means that some DRD (document requirements definition) information may be missing if justified and agreed by the customer;
• Other value: specific conditions.

Requirement tailoring based on software criticality categories – extract from ECSS-E-ST-40 Table R-1

Stay tuned

In this blog, we have introduced the ECSS-E-ST-40 and ECSS-Q-ST-80C software standards, applicable to the development of space software.

Upcoming articles will explain how SCADE enables model-based development, allowing engineers to satisfy ECSS-E-ST-40 and ECSS-Q-ST-80C requirements for developing and verifying space software products.

If you’d like to learn more about Ansys SCADE Solutions, we’d love to hear from you! Get in touch on our product page.

About the author