ECSS-Q-ST-80C Rev.2: ECSS-Q-ST-80C Rev.2 – Tutorial (about 60 minutes)

ECSS-Q-ST-80C Rev.2 is the European space standard that sets out what a supplier must do to give its customer justified confidence that space software – on board a satellite or launcher, or on the ground – is fit for its mission. It is used by software product assurance engineers, software developers and testers, project managers, prime contractors and agencies such as ESA. After this tutorial you will be able to explain how the standard is organised, how software criticality drives the effort it demands, which plans and reports it expects, how compliance is judged, and how it works together with its engineering twin, ECSS-E-ST-40C.

Free tutorial · about 60 minutes · 7 lessons · 4 diagrams · then a 25-question knowledge check and a certificate.

Course overview

Edition and status: the current version is ECSS-Q-ST-80C Rev.2, Space product assurance – Software product assurance, published by the European Cooperation for Space Standardization (ECSS) on 30 April 2025. It cancels and replaces ECSS-Q-ST-80C Rev.1 of 15 February 2017, which itself revised the original C issue of 6 March 2009. A draft of Rev.2 went through public review from 20 March to 17 May 2024 before publication, and Rev.2 was released on the same date as its companion engineering standard ECSS-E-ST-40C Rev.1. Rev.2 is the active version. Verified 2026-10-29 against the ECSS publication listing and public-review notice and the published Rev.2 text itself (read from the Internet Archive copy of the ECSS PDF, because ecss.nl redirected to an ESA outage page on that date); check ecss.nl for any corrigendum issued after April 2025. Projects contracted before 2025 may still work to Rev.1; this course teaches Rev.2 and points out what changed.

Who it is for: engineers, testers, quality and product assurance staff, project and procurement managers, and auditors who meet space software for the first time, such as a quality engineer moving from automotive or aviation into space.

Prerequisites: none. A general idea of how software is specified, coded and tested helps. Every space-specific term is explained when it first appears.

By the end of this tutorial:

You will be able to explain why space software needs a product assurance standard and where ECSS-Q-ST-80C sits in the ECSS system.
You will be able to define the core vocabulary: product assurance, software criticality category, tailoring, nonconformance, ISVV, metrication and the main documents.
You will be able to describe the three main requirement clauses and the key annexes of the standard.
You will be able to walk through how software product assurance runs alongside the software lifecycle and its review milestones.
You will be able to explain how compliance is demonstrated to a customer, and why there is no certificate on the wall for this standard.
You will be able to apply the standard to a realistic small-satellite software project, including tailoring by criticality.
You will be able to compare ECSS-Q-ST-80C with ECSS-E-ST-40C, ECSS-Q-ST-40C, DO-178C and other neighbours.

Lesson 1 – Origins, purpose and scope

Why space software needs assurance

Software controls almost everything a spacecraft does – attitude and orbit control, power, payload operation, data handling, fault detection and recovery – and launchers depend on flight software to steer and sequence stages. On the ground, mission control and data processing software decide what commands are sent and how data becomes products. A spacecraft cannot be brought back to the workshop for repair, so a software failure can cost the mission.

Software also fails differently from hardware. A resistor wears out; software does not. Software faults are systematic: they are put in during specification, design or coding and lie dormant until a particular combination of inputs, timing and state triggers them. Well-known space failures came from such causes, for example reused code operating outside the conditions it was designed for. You cannot test your way out of systematic faults alone, because the number of possible situations is far too large. What you can do is control the process that produces the software and measure the product that comes out of it, so that faults are prevented, found early and handled in a disciplined way. That combination is what the space community calls software product assurance.

Who writes the standard

The European Cooperation for Space Standardization was set up in the early 1990s by the European Space Agency, national space agencies and European industry, represented through Eurospace, to replace a patchwork of agency-specific rules with one coherent set of standards. ECSS standards are written by working groups of agency and industry experts, go through public review, and are made applicable to a project through contracts. Many are also published by CEN-CENELEC as European Norms in the EN 16600 family.

The ECSS system is organised in branches. The M branch covers project management (planning, configuration management, risk), the E branch covers engineering disciplines, the Q branch covers product assurance (quality, dependability, safety, parts, materials, software), the U branch covers space sustainability, and the S branch contains the system-level description of how the standards work together, including tailoring. Within each branch, disciplines are numbered. In the Q branch, number 80 is software product assurance.

Reading the name

The identifier tells you a lot. ECSS is the organisation. Q is the product assurance branch. ST means this is a normative standard containing requirements; the same discipline also has handbooks marked HB, which give guidance but no requirements. 80 is the software product assurance discipline. C is the issue letter of the current generation of ECSS documents, introduced in 2008–2009. Rev.2 means this is the second revision of that C issue. So "ECSS-Q-ST-80C Rev.2" reads as "the second revision of issue C of the ECSS product assurance standard for software".

What it covers

The standard defines product assurance requirements for the development and maintenance of software for space systems. That includes the space segment (spacecraft, payloads, experiments), the launch service segment and the ground segment, including equipment and facilities. It applies to deliverable software and also to non-deliverable software that can affect the quality of the delivered product, such as development and test tools, simulators and data generators. A dedicated clause also covers software loaded into programmable devices, such as programmed memories. The depth of what is required varies enormously, as Lesson 3 shows.

Two things are deliberately outside the standard. First, it does not tell you how to engineer software – how to write requirements, design architecture or run tests. Those engineering processes are defined in ECSS-E-ST-40C. ECSS-Q-ST-80C instead defines how to assure that those processes are planned, followed, monitored and verified, and that the resulting product meets quality objectives. Second, it does not decide how dangerous a function is. That judgement comes from system-level dependability and safety analyses under ECSS-Q-ST-30C and ECSS-Q-ST-40C, and the software standard takes the result as an input.

What changed in Rev.2

Rev.2 implements change requests from agencies and industry and pursues three aims. The first is alignment with ECSS-E-ST-40C Rev.1, published the same day: shared definitions, product assurance participation in the software delivery review board that the engineering standard introduced, and supplier review of the software validation control information – a per-requirement record of whether validation was executed and with what result. The second, and the most visible, is software security assurance. Rev.1 barely mentioned security; Rev.2 adds a short clause on security aspects of the standard, requirements on passing security sensitivity information down to lower-tier suppliers, security criteria for tools and the development environment, protection of the integrity and authenticity of delivered software, a security representative on nonconformance boards when security may be affected, and two new subclauses, 6.2.9 "Software security" and 6.2.10 "Handling of security sensitive software". The third is lessons learnt: a mandatory test readiness review before validation against the requirements baseline, independent verification and validation stated to come on top of – never instead of – the supplier's own verification, and process assessment references moved from ISO/IEC 15504 to ISO/IEC 33002, with a lighter option for very small entities based on ISO/IEC 29110. The old delivery and acceptance subclause was also split into two, and the firmware subclause was renamed "Programmable devices".

Figure 1 – Where ECSS-Q-ST-80C sits: it is fed by system-level dependability and safety analyses and works hand in hand with the software engineering standard.

Lesson 2 – Key concepts and vocabulary

ECSS uses a precise vocabulary. The explanations below are in plain language, not the formal definitions, which are in the standard's terms clause and the ECSS glossary.

Product assurance (PA) – the discipline that gives the customer, and the supplier's own management, confidence that a product will meet its requirements. In ECSS it groups quality assurance, dependability, safety, parts, materials and processes, and software product assurance.
Software product assurance (SPA) – the part of product assurance that deals with software: assuring the processes used to develop and maintain it and the quality of the resulting product.
Customer and supplier – ECSS describes every relationship as a chain of customers and suppliers, for example ESA, a prime contractor, an equipment supplier and a software subcontractor. Requirements flow down the chain and evidence flows back up.
Software criticality category – a letter from A (most critical) to D (least critical) assigned to a software product according to the worst consequence its failure could contribute to at system level. The category decides which requirements apply and how rigorously.
Tailoring – the process of adapting a standard to a particular project by stating which requirements apply, which do not, and which are modified. Tailoring is normal and expected in ECSS.
Software product assurance plan (SPAP) – the supplier's plan describing how it will meet the software PA requirements on a project: organisation, responsibilities, activities, methods, tools, metrics and schedule.
Software product assurance milestone report (SPAMR) – a report delivered at project review milestones summarising the PA status: what was done, what was found, metric results, open problems and compliance.
Nonconformance – a departure from a requirement that is formally recorded and dispositioned, typically through a nonconformance review board (NRB) involving supplier and, where needed, customer.
Software problem report – the record of a suspected defect or anomaly in software, tracked through analysis, correction, verification and closure. Not every problem becomes a nonconformance.
Critical software – in this standard, software of category A, B or C (everything except D). The subclause on handling critical software adds measures for these categories, such as stricter verification and control of changes; independent verification and validation is added for categories A and B.
ISVV (independent software verification and validation) – verification and validation performed by an organisation that is technically, managerially and financially independent of the developer. It is required for the most critical software where the risk justifies the cost; the customer may accept a lower level of independence, such as a separate team inside the supplier, and ISVV always comes in addition to the supplier's own verification, never in place of it.
Metrication – the systematic definition, collection and analysis of process measurements (such as problems found per phase) and product measurements (such as complexity or test coverage), so that quality is judged with evidence.
Software reuse – using existing software (heritage, open-source or commercial off-the-shelf code) in a new context. ECSS treats reuse as a risk to be analysed, because the new context may differ from the one the software was proven in.
HSIA (hardware-software interaction analysis) – an analysis that checks how the software reacts to hardware failures and how hardware and software together handle faults. The software supplier contributes by stating, for each hardware failure considered, the required software behaviour, and then verifies it.
Software security assurance – the activities that give confidence that software protects confidentiality, integrity and availability as required, and that its development and supply chain are not compromised. This is the main addition in Rev.2.

Process assurance and product assurance

The most important idea to hold on to is that the standard looks at software from two angles. Process assurance asks: were the right activities planned, were they actually carried out, by competent people, with suitable tools, and is there evidence? Product quality assurance asks: does the software itself meet measurable quality objectives – for example on complexity, test coverage, numerical accuracy and portability – and are reused or generated parts trustworthy? The standard demands both.

Independence of the PA function

A recurring principle is that people who assure the software should not report only to the people under pressure to deliver it. The standard expects the supplier to name a software PA manager or engineer who reports to the project manager (through the project's product assurance manager, if there is one), has the organisational authority and independence to run the PA programme, and has unimpeded access to higher management when needed. Reviews and audits must be done by people not directly involved in the work being checked. Independence here is about authority and reporting, not about using a separate company; ISVV is the stronger, contractual form of independence used for the most critical software.

Lesson 3 – Structure of the standard

ECSS-Q-ST-80C follows the standard ECSS layout: a short scope, the normative references, terms and abbreviations, a principles clause, then three requirement clauses and a set of annexes. Each requirement also carries a unique identifier, which makes compliance matrices and traceability easier. Most clause numbers carried over from Rev.1, but not all: splitting the delivery and acceptance subclause shifted the numbers of the later subclauses in clause 6, so a Rev.1 compliance matrix cannot simply be reused for Rev.2.

Clause 4 – Principles

Clause 4 explains the purpose of software product assurance, the customer–supplier principle, how the standard is organised, how it is to be tailored and – new in Rev.2 – how security assurance affects it. It contains no numbered requirements but is essential reading, because it explains that ECSS-Q-ST-80C and ECSS-E-ST-40C together specify all the processes for space software.

Clause 5 – Software product assurance programme implementation

This clause is about setting up and running the PA programme at the organisational and project level. Its main topics are:

Organisation and responsibility – who does software PA, their authority, the resources and the training of personnel, which in Rev.2 also covers security awareness.
Programme management – planning (the SPAP), reporting (including the SPAMR), audits, alerts, the handling of software problems and of nonconformances, and the quality model used to specify software quality requirements.
Risk management and critical item control – identifying software-related risks and critical items and following them up.
Supplier selection and control – making sure that lower-tier suppliers can meet the requirements and are monitored, and giving them the criticality and, since Rev.2, the security sensitivity of what they develop.
Procurement – controlling software bought in or obtained from third parties, including export-control constraints, which Rev.2 notes can include security export regulations.
Tools and supporting environment – choosing, justifying and controlling methods, tools and the development and test environment.
Assessment and improvement – assessing the supplier's software processes and improving them, based on recognised process assessment models.

Clause 6 – Software process assurance

Clause 6 follows the software lifecycle. It starts with requirements on the software development life cycle itself (it must be defined, with milestones and entry and exit criteria). It then sets requirements that apply to all software engineering processes: documentation, dependability and safety, the handling of critical software, configuration management, process metrics, verification, reuse of existing software, automatic code generation and – new in Rev.2 – software security and the handling of security-sensitive software. Finally, it sets requirements on individual processes and activities: requirements engineering, design, coding, testing and validation, delivery and installation, acceptance (a separate subclause since Rev.2), operations and maintenance. Each of these mirrors a process in ECSS-E-ST-40C, but the angle is assurance: are coding standards defined and checked, are test reports complete and valid, is the test coverage achieved, are deviations recorded?

Clause 7 – Software product quality assurance

Clause 7 deals with the product. It requires quality objectives and metrication: the supplier derives quality objectives, selects metrics to show whether they are met, and collects and reports them. Typical product metrics include size, design and code complexity, fault density, test coverage and failure counts. It covers numerical accuracy and software maturity, and sets quality requirements on the requirements baseline, the design documentation (for example complexity and modularity) and the test documentation. It has requirements for software intended for reuse, for standard ground hardware and services used by operational systems, and for programmable devices (called firmware in Rev.1): procedures for programming them, marking them and calibrating the programming equipment.

Annexes

The annexes are where much of the practical work happens. Annex B is the document requirements definition (DRD) for the software product assurance plan, and Annex C is the DRD for the software product assurance milestone report. A DRD is an ECSS template that defines the purpose, expected content and structure of a document without prescribing its format. Annex D, which is normative, explains how to tailor the standard according to software criticality: it defines the categories and contains an applicability matrix that marks, requirement by requirement, whether it applies (Y), does not apply (N) or applies under stated conditions to category A, B, C or D software. The security requirements are an exception: the matrix says they are applied according to security assurance and sensitivity levels, independently of the criticality category. Other annexes are informative, for example listing requirements that have built-in tailoring options and showing which documents are expected at each milestone.

Software criticality categories

The criticality categories are the single most important structural concept, because they decide how much of the standard bites. The process starts at system level. Dependability and safety analyses under ECSS-Q-ST-30C and ECSS-Q-ST-40C rate the severity of what could happen if a function fails, on a scale running from catastrophic (for example loss of life, loss of the launch site or loss of the mission) down to minor or negligible. A software product then receives the category of the most critical function it implements or contributes to. The system standards group functions into categories I to IV, from catastrophic down to minor or negligible. Broadly, software involved in category I functions is category A, category II leads to B, category III to C and category IV to D. A compensating provision – hardware, independent software or an operational procedure meeting the system standards' rules – lowers the software by one category (for example from A to B), but such a claim must be justified at system level, not asserted by the software team. Software that itself implements a compensating provision takes the higher category, so the safety net is never weaker than what it protects. And if a lower-category component can make a higher-category one fail, for example through shared memory, both are classified at the higher category unless the propagation is prevented.

Once the category is known, the applicability matrix in Annex D tells the project which requirements apply. Category A software carries the full weight of the standard; category D software carries a much lighter set. Some requirements, listed in an informative annex, have built-in tailoring: they apply only under conditions stated in their text or leave a level to be agreed between customer and supplier, so the level of rigour is negotiated and recorded rather than left undefined. Test coverage is a good illustration. ECSS-Q-ST-80C requires coverage goals for each testing level to be agreed between customer and supplier, based on the dependability and safety criticality and – new in Rev.2 – the security sensitivity of the software, and their achievement to be monitored with metrics. The numbers themselves sit in ECSS-E-ST-40C Rev.1: 100 % statement and decision coverage for categories A and B, 100 % modified condition/decision coverage (MC/DC) for category A, and values to be agreed with the customer for the remaining cases.

Figure 3 – How software criticality is determined from system analyses and then used to tailor which requirements apply to a software product.

Lesson 4 – How it works in practice

Two standards, one lifecycle

On a real project, ECSS-Q-ST-80C never works alone. The customer's statement of work makes a tailored version of ECSS-E-ST-40C and ECSS-Q-ST-80C applicable, usually through a product assurance requirements document that also calls up other Q-branch standards. The supplier then answers with a compliance matrix and with plans. Engineering follows ECSS-E-ST-40C and assurance follows ECSS-Q-ST-80C, with the same lifecycle, reviews and criticality categories.

The lifecycle and its reviews

ECSS projects are paced by formal reviews defined in the project management branch. For software, the main milestones are the system requirements review (SRR), where the requirements baseline is agreed; the preliminary design review (PDR), which for software includes agreement on the technical specification and architecture; the critical design review (CDR), where detailed design, code and unit and integration testing are examined; the qualification review (QR), where the software is shown to meet its technical specification and requirements baseline; the acceptance review (AR), where the customer accepts the product; and, for operational systems, the operational readiness review (ORR). Software-specific reviews such as a detailed design review can be held between them. Test readiness reviews (TRR) are held before test activities start, and Rev.2 makes one mandatory, as a formal project review, before validation against the requirements baseline: the team must show that the software status allows validation to start and that plans, test documentation, simulators and other means are ready.

Rev.2 also brings in the software delivery review board introduced by ECSS-E-ST-40C Rev.1: a board convened before any software version is delivered to decide whether it is fit for its intended use, which must include product assurance and software engineering representatives. And it asks the supplier to review the software validation control information – for each requirement, whether validation was executed, its result, the test cases, the configuration and any problem reports raised – and to make it available to the customer at milestone reviews.

At each milestone, PA delivers its view. The SPAMR summarises activities performed, audits held, metrics collected and their interpretation, the status of problem reports and nonconformances, and the status of compliance with the applicable requirements.

Figure 4 – Software product assurance follows the project's review milestones: the plan is set early and a milestone report gives the PA status at each review.

Roles

Most projects end up with a recognisable cast. The software product assurance manager or engineer on the supplier side writes the SPAP, runs audits, checks metrics and reports at milestones. The software project manager and development team carry out the engineering. On the customer side, a PA representative follows up, reviews documents, takes part in reviews and nonconformance boards, and may audit the supplier. For critical software an ISVV team from an independent company analyses requirements, design and code and may run additional tests. System-level dependability and safety engineers provide criticality inputs and receive software analyses back.

Artefacts

The ECSS software documents are organised into files. ECSS-E-ST-40C defines groupings such as the requirements baseline, the technical specification, the design definition file, the design justification file, the management file, the maintenance file, the operational documentation and the product assurance file; Rev.1 of the engineering standard adds a security file, which holds documents such as the software security management plan and the software security analysis report. The product assurance file collects the PA evidence: the SPAP, the milestone reports, audit reports, metric reports, records of tool justification, reuse analyses and similar items. At each review the question is whether the file contains the evidence the milestone needs.

Implementation steps for a supplier

Understand the applicable requirements. Read the customer's product assurance requirements and the tailoring of ECSS-Q-ST-80C, including the criticality categories assigned or to be assigned to each software product.
Answer with a compliance matrix. For each requirement state whether you comply, partially comply or do not comply, with justification and proposed alternatives.
Write the SPAP. Describe organisation, responsibilities, activities per lifecycle phase, review participation, audits, problem and nonconformance handling, metrics, tools, supplier control, reuse and security measures.
Set up the infrastructure. Configuration management, problem tracking, a coding standard with automated checking, static analysis, coverage measurement, and a metrics dashboard. Justify the tools you rely on for verification.
Run PA throughout the lifecycle. Review documents, verify that verification really happened, sample code against the coding standard, check that problem reports are analysed and closed, and track metrics against quality objectives.
Report at each milestone. Produce the SPAMR, highlight risks, and agree corrective actions.

Handling problems and nonconformances

A strong problem management process is at the heart of software PA. Every anomaly found in review, test or operation is recorded, analysed for cause and impact, corrected or deliberately deferred, and verified after correction. Problems that mean the product does not meet an agreed requirement become nonconformances and go to an NRB, which follows the nonconformance control standard of the Q branch and must include at least a software PA and a software engineering representative. For software the board chooses between using the product as it is, fixing it (by correction, patch or redesign) or, for procured products such as COTS, returning it to the supplier. Rev.2 adds that a representative of software security engineering joins the board when a nonconformance may have a security impact. The PA function checks that no problem quietly disappears.

Reuse, generated code and tools

Three topics deserve special attention because they are where modern projects most often get into trouble. Reuse: heritage software from an earlier mission or a commercial library must be analysed for its suitability in the new context – requirements, environment, criticality, available documentation and verification evidence – and gaps closed with additional work. Automatic code generation: when code is generated from models, the standard expects the generator and modelling standards to be selected and controlled, and the generated code to be verified, so that model-based development does not create an unverified blind spot. Tools: compilers, static analysers, test frameworks and coverage tools can introduce or hide errors. The supplier must justify their selection and their suitability for the criticality of the software, and Rev.2 requires tools and methods to be appropriate to the security sensitivity of the product as well.

Security assurance in Rev.2

Before Rev.2, security was largely left to project-specific requirements. Rev.2 weaves it through the standard. The SPAP must include security assurance. The supplier performs a software security analysis, using the system-level security analyses, to decide how security sensitive each software component is, updates it at each milestone and feeds new vulnerabilities back to system level. Measures follow in proportion: fewer and better isolated security-sensitive components, security criteria for tools, integrity and authenticity checks on delivered software, attention to known vulnerabilities in reused software, and extra measures such as secure coding and security testing, recorded in a software security management plan. The engineering side of space security is covered by the ECSS standard on security in space system lifecycles, ECSS-E-ST-80C, which Rev.2 references.

Lesson 5 – Assessment, certification and compliance

There is no ECSS-Q-ST-80C certificate

Unlike ISO 9001 or ISO/IEC 27001, ECSS-Q-ST-80C has no third-party certification scheme. No accredited body issues a certificate saying that a company "is ECSS-Q-ST-80C certified", and any marketing claim of that kind should be read with care. Compliance is a contractual matter between customer and supplier on a specific project, under a specific tailoring. A supplier that complied fully on one mission may be non-compliant on the next if the tailoring or criticality differs.

How compliance is demonstrated

Compliance is shown through a body of evidence that the customer reviews over the life of the project:

The compliance matrix at proposal and contract stage, agreed by both parties, listing each requirement and the supplier's position.
The SPAP, reviewed and accepted by the customer, showing how each applicable requirement will be met.
Milestone reviews, where the customer checks the documentation files and the SPAMR against the review's objectives and raises review item discrepancies when something is missing or wrong.
Audits by the customer or its PA representative, checking that the supplier does what its plans say.
Process assessments of the supplier's software capability. Rev.2 requires assessments and assessment models to conform to ISO/IEC 33002 (Rev.1 referred to ISO/IEC 15504), performed by a competent assessor, with the model, method, scope and assessors established by the customer. The ECSS handbook for software process assessment and improvement, historically known as SPICE for space, can still be used with the customer's agreement, and CMMI can be used with the SCAMPI A appraisal method. Very small entities – enterprises, departments or projects of up to 25 people – may use a model and method conforming to ISO/IEC 29110-6-1. These requirements do not apply to category D software. Assessments may be required before contract award or as part of supplier control.
ISVV for critical software, carried out by an independent organisation under customer control, which provides an independent view of requirements, design, code and validation and often finds issues that the development team's own verification missed.
Qualification and acceptance evidence: verification and validation reports, coverage results, the software validation control information, metric reports and the closure status of all problems and nonconformances.

Ratings and outcomes

Because there is no certification, there are no "levels" of compliance in the standard itself. Outcomes are concrete project decisions: a review is passed, passed with actions or not passed; a nonconformance is closed with a fix or accepted for use as is; a requirement is declared compliant, partially compliant or non-compliant; a process assessment produces capability ratings for assessed processes according to the assessment model used. When a supplier cannot comply with a requirement, the correct route is a request for deviation or waiver, approved by the customer, not silent omission.

What assessors look for

Experienced customer PA engineers look past the volume of documents. Is the criticality justified by system analyses? Does the SPAP describe what the team actually does? Are metrics used to make decisions? Can each requirement be traced to its validation result? Is heritage code backed by evidence?

Lesson 6 – Worked example

The organisation and the contract

NordOrbit is a fictional company of about sixty people that builds small Earth-observation satellites. It has signed a contract with a national space agency, acting with ESA support, for a demonstrator satellite. The contract makes ECSS-E-ST-40C Rev.1 and ECSS-Q-ST-80C Rev.2 applicable, tailored by a product assurance requirements document. NordOrbit has written flight software before, but never under ECSS. Its new software PA engineer, Lina, has two weeks before kick-off.

Step 1 – Identify the software products and their criticality

Lina starts by listing the software products: the on-board software of the platform computer (attitude control, mode management, fault management, telecommand and telemetry), the payload control software in the camera electronics, the ground mission control software, and the test tools used to validate the flight software. She does not assign categories herself. Instead she asks the system safety and dependability engineer for the function severity analysis. The analysis shows that loss of attitude control during a critical phase could lead to loss of the mission, which is rated critical for this uncrewed demonstrator, and there is no independent hardware means of recovery. The platform on-board software therefore becomes category B. The payload software can at worst lose images, which the system rates as major: category C. The mission control software is category C because the satellite has an autonomous safe mode that protects it against wrong commands, a compensating provision justified at system level. The test tools are not flight software but they help produce verification evidence for category B software, so their selection and suitability must be justified under the tool requirements. (The FPGA design in the power unit is handled by the electronics team under ECSS's own ASIC and FPGA engineering standard, ECSS-E-ST-20-40C.)

Step 2 – Tailor and answer

Using the Annex D applicability matrix, Lina builds a requirement list per product. For the category B on-board software, nearly all requirements apply, including dependability and safety analyses of the software, the HSIA contribution, ISVV and – through the engineering standard – 100 % statement and decision coverage. For the category C products the matrix drops some requirements, such as ISVV, and the coverage goals must be agreed, so she proposes concrete targets and records them in the compliance matrix. A full ISO/IEC 33002 process assessment is a heavy step for NordOrbit, but its software department has only fifteen people, and Rev.2 lets departments or projects of up to 25 people use an ISO/IEC 29110-6-1 model instead, so she proposes that route and asks the customer, who decides the assessment model, to accept it. The compliance matrix goes out with clear positions instead of a blanket "compliant".

Step 3 – Plan

Lina writes the SPAP following the Annex B template. It names her as software PA manager, reporting to the project manager through the project's product assurance manager, with direct access to the company's quality director when an issue needs escalating. It describes PA participation in every review, a quarterly internal audit of the software team, the problem reporting workflow, the NRB composition (including a security representative, because the satellite's command link uses authentication), the metrics to be collected (code complexity, coding-standard violations, test coverage, problem density per phase, open versus closed problems), the tool justification approach, the reuse analysis of an attitude control library from a previous commercial mission, and the security measures: restricted repository access, signed release artefacts, and a security review of the telecommand authentication code. The SPAP is consistent with the software development plan that the engineering lead writes under ECSS-E-ST-40C.

Step 4 – Run

Development proceeds through SRR, PDR and CDR. Early on, Lina's metrics show that the fault management module has much higher complexity than the rest of the code. She raises it at an internal review, and the team refactors it before unit testing, which is far cheaper than discovering untestable logic at qualification. The reuse analysis of the heritage attitude library finds that the library was verified only for a different sensor sampling rate. Instead of trusting heritage, the team adds requirements-based tests for the new rate and documents the gap and its closure in the reuse file. Static analysis runs on every commit with a justified, version-controlled tool. Before formal qualification testing, a test readiness review checks that procedures, test benches and configuration are under control; one test bench is found to run a different simulator version from the baseline, and the review waits until it is fixed.

Step 5 – Independent view

Because the on-board software is category B, the customer contracts an ISVV company. ISVV analysts review the software requirements and find two mode-transition cases with no defined behaviour. Problem reports are raised, and the NRB, with the customer's PA representative attending, decides to change the requirements and add tests. Lina tracks the closure and reports it in the SPAMR for the qualification review.

Step 6 – Qualify and deliver

At the qualification review, the product assurance file contains the SPAP, three milestone reports, audit reports, the metric report showing coverage achieved for the category B software, the software validation control information showing every requirement's validation status and result, the tool justifications, the reuse analysis and the list of problem reports and nonconformances with their status. One minor nonconformance on a telemetry formatting rule remains; the NRB, with the customer's agreement, dispositions it as "use as is" and records the decision. A delivery review board then confirms that the delivered version, its documentation and its checksums match the qualified configuration. The software is accepted.

What the example shows

None of NordOrbit's actions were exotic: system analyses set criticality, tailoring was explicit, the plan matched reality, metrics triggered early action, heritage was re-verified and problems were reported honestly.

Lesson 7 – Relationship to other standards and frameworks

ECSS-Q-ST-80C sits in a dense network of standards.

Inside ECSS

ECSS-E-ST-40C is the essential companion. It defines the software engineering processes and documents; ECSS-Q-ST-80C defines the assurance of those processes and the quality of the product. The two are revised together, share definitions and use the same criticality categories. ECSS-Q-ST-30C (dependability) and ECSS-Q-ST-40C (safety) provide the system-level severity analysis from which software criticality is derived. ECSS-Q-ST-10C covers product assurance management in general, and the Q branch also has a dedicated standard for nonconformance control. The M branch defines project phases, reviews, configuration and information management, and risk management, all of which the software PA programme uses. ECSS handbooks give guidance on reuse of existing software, on software process assessment and improvement, on software dependability and safety, and on setting up a software metrication programme, and Rev.2 points to the ESA ISVV handbook for independent verification and validation. ECSS-E-ST-80C covers security in space system lifecycles and is a normative reference of Rev.2.

Outside ECSS

The general idea – rigour scaled to the consequence of failure – is shared, but the scales, documents and assessment models differ.

Standard	Domain and owner	How it scales rigour	Assessment	Relationship to ECSS-Q-ST-80C
ECSS-E-ST-40C Rev.1	Space software engineering, ECSS	Same categories A to D	Customer reviews and acceptance	Companion: engineering processes that Q-80 assures
ECSS-Q-ST-40C	Space system safety, ECSS	Severity of hazards	Customer safety reviews	Provides severity inputs that set software categories
DO-178C	Airborne software, RTCA and EUROCAE	Design assurance levels A to E	Certification authority approval	Similar coverage ideas; aviation has a certification authority, space has a contracting customer
IEC 61508	Generic functional safety, IEC	Safety integrity levels 1 to 4	Independent functional safety assessment, optional certification	Shared principle of rigour by consequence; different scale and lifecycle model
ISO/IEC 33000 series and ISO/IEC 29110	Process assessment, ISO/IEC	Process capability levels	Formal process assessments	Referenced by Rev.2 for supplier process assessment
ISO/IEC 25000 series (SQuaRE)	Software product quality, ISO/IEC	Quality characteristics, not levels	Used inside evaluations	Cited by Rev.2 as further guidance on the quality models used to specify quality requirements
NASA-STD-8739.8	Software assurance and software safety, NASA	Software classification and safety-criticality	NASA assurance oversight	The closest US counterpart for agency space software

Reusing evidence across domains

A supplier with a mature DO-178C or IEC 61508 process will find that traceability, structural coverage, independence, configuration control and problem reporting transfer. ECSS document groupings, review milestones and tailoring by category do not, so map the existing process to the applicable ECSS requirements and close the gaps rather than claiming equivalence without evidence.

Common pitfalls and best practices

Common pitfalls

Treating the standard as an afterthought. Writing the SPAP after development has started, or assembling evidence just before qualification, produces documents that describe an imagined process and evidence that cannot be trusted.
Software teams choosing their own criticality. Picking a low category to save effort, without system-level analysis, collapses at the first customer review and causes expensive rework.
Blanket compliance claims. Answering "compliant" to every requirement in the compliance matrix, then failing to deliver, damages trust far more than an honest partial compliance with a reasoned alternative.
Trusting heritage software. Reusing flight-proven code without analysing differences in environment, interfaces and criticality has caused real mission failures.
Collecting metrics nobody reads. A metrics programme that produces charts but never triggers a decision costs effort and gives false comfort.
Bolting security on late. With Rev.2, security assurance is part of the baseline; leaving it to the last review means redesign of configuration management, supply and access controls.

Best practices

Start with criticality. Obtain the function severity analysis early and record the rationale for every category, including any compensating provisions.
Tailor explicitly and early. Use the Annex D matrix, propose concrete levels for requirements subject to agreement, and settle disagreements before the contract is signed.
Keep the SPAP alive. Treat it as a working document that is updated when the project changes, and check at each milestone that it still describes reality.
Automate evidence. Generate coding-standard reports, static analysis results, coverage figures and traceability matrices from the build pipeline so that evidence is always current.
Use metrics to steer. Define thresholds that trigger action, such as a complexity limit that forces review, and report trends rather than snapshots.
Protect PA independence. Make sure the PA function can escalate concerns to management without going through the delivery chain.
Close the loop. Feed lessons learnt from problem reports and reviews into process improvement, as the assessment and improvement requirements intend.

Summary and key takeaways

ECSS-Q-ST-80C Rev.2, published by ECSS on 30 April 2025, is the current European standard for software product assurance in space projects and replaces Rev.1 of 2017.
It covers deliverable software and supporting software in the space, launch and ground segments, including software in programmable devices, and it is made applicable by contract and tailoring.
It assures both the software process and the software product, and works hand in hand with the engineering standard ECSS-E-ST-40C.
Its requirements are grouped in three clauses: PA programme implementation, software process assurance and software product quality assurance, supported by templates for the SPAP and SPAMR.
Software criticality categories A to D, derived from system-level dependability and safety analyses, decide through Annex D how much of the standard applies.
There is no certification scheme; compliance is demonstrated to the customer through compliance matrices, plans, reviews, audits, process assessments, ISVV and verification evidence.
Rev.2 adds software security assurance throughout, aligns with ECSS-E-ST-40C Rev.1 (delivery review board, validation control information), makes a test readiness review before validation mandatory and moves process assessment to ISO/IEC 33002, with an ISO/IEC 29110 route for very small entities.
Good practice: early criticality analysis, explicit tailoring, a living plan, automated evidence, metrics that drive decisions and an independent PA voice.

Reflection questions

Think of a software product you know well. If it flew on a satellite, which system-level failure could it contribute to, and which criticality category would you expect it to receive? What compensating provisions might change that?
Your organisation's existing quality process is based on another domain standard. Which parts of it would satisfy ECSS-Q-ST-80C requirements, and which gaps would you have to close?
Choose three metrics you would include in a SPAP for a category B product. For each, what threshold would trigger action, and what action?
A colleague proposes to reuse an open-source library in flight software because "everyone uses it". What would you need to know and show before agreeing?
How would you explain to a project manager under schedule pressure why the software PA function must be able to report issues independently of the development team?