ECSS-E-ST-40C Rev.1: ECSS-E-ST-40C Rev.1 – Tutorial (about 60 minutes)

ECSS-E-ST-40C Rev.1 is the European space standard that says what a supplier must do, and what evidence it must deliver, when it engineers software for a space project – from the first system-level requirements to operation and maintenance after launch. It is used by space agencies, prime contractors, software subcontractors, product assurance staff and independent verifiers, mostly in Europe but also by anyone who supplies software into a European mission. After this tutorial you will be able to explain why the standard exists, read its structure, follow its processes, reviews and document files, understand how criticality categories and tailoring change the work, and see how it fits with its product assurance twin, ECSS-Q-ST-80C.

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

Course overview

Edition and status: the current edition is ECSS-E-ST-40C Rev.1, Space engineering – Software, dated 30 April 2025, published by the European Cooperation for Space Standardization (ECSS) Secretariat, hosted by the European Space Agency (ESA). It is the third issue (letter C), first revision, and it cancels and replaces ECSS-E-ST-40C of 6 March 2009; the ECSS catalogue page for the 2009 issue is marked as cancelled and replaced by Rev.1. It was published at the same time (April 2025) as its companion ECSS-Q-ST-80C Rev.2, Software product assurance. ECSS standards can be downloaded free of charge from the ECSS website after registration. Status verified on 2026-10-29 from the ECSS catalogue entries as indexed by search engines, the ESA software-standards update presentation, and the AdaCore space-software booklet that cites the 30 April 2025 editions; the ECSS website itself was temporarily unreachable on that date, so check the catalogue for any newer revision before relying on this course for a contract.

Who it is for: software engineers, testers, software product assurance engineers, project and technical managers, buyers and subcontract managers, and engineers from aviation, automotive, rail or medical software who are new to space projects and meet "E-40" in a statement of work.

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

By the end of this tutorial:

You will be able to explain why space software needs its own engineering standard and what ECSS-E-ST-40C Rev.1 covers and leaves to other ECSS standards.
You will be able to use the core vocabulary: customer and supplier, requirements baseline, technical specification, files, expected outputs, criticality categories and tailoring.
You will be able to describe the structure of the standard: its software processes, its document requirements definitions and its annexes.
You will be able to follow a software development through the joint reviews, from the system requirements review to the operational readiness review.
You will be able to explain how compliance is demonstrated and judged in a contract, and why there is no certificate for organisations or products.
You will be able to name what Rev.1 changed, in particular the software security process and the strengthened code verification.
You will be able to relate the standard to ECSS-Q-ST-80C, the system engineering standard, DO-178C and ISO/IEC/IEEE 12207.

Lesson 1 – Origins, purpose and scope

Why space software is different

Software runs almost every part of a modern space mission. On board a satellite it points the spacecraft, controls power and heat, protects the platform when something fails, compresses and stores payload data and executes commands from the ground. On the ground it plans operations, sends telecommands, receives telemetry, processes science data and simulates the spacecraft for training. A launcher depends on flight software to steer through the atmosphere in a few minutes with no second chance.

Several things make this software unusual. Once a spacecraft is launched, nobody can walk up to it and fix it; software can sometimes be patched from the ground, but only through narrow, slow communication links and with great care. The hardware is specialised, often radiation-tolerant and less powerful than an office laptop, so timing and memory margins matter. Missions last ten or fifteen years, longer than many careers, so the documentation must still make sense to people who were not there when the code was written. And the work is spread across a supply chain: an agency buys a mission from a prime contractor, who buys subsystems from other companies, who buy software from specialist suppliers. Every link in that chain needs to know exactly what is expected and how it will be checked.

Without a common rulebook, each agency and each prime contractor would write its own software requirements into every contract, and every supplier would have to learn a new set each time. ECSS-E-ST-40C exists to give the whole European space sector one shared set of software engineering requirements, written so that they can be placed in a contract, tailored to the risk of the project, and checked at agreed review points.

Who writes the standard

The European Cooperation for Space Standardization was set up in the 1990s by ESA, national space agencies and European space industry to replace the many agency-specific standards with one coherent system. Its documents are organised in branches. The M branch covers project management (planning, configuration management, reviews and similar). The Q branch covers product assurance (quality, dependability, safety, software product assurance, parts and materials). The E branch covers engineering disciplines (system engineering, electrical, mechanical, communications, control, ground systems, software and others). A later sustainability branch, U, deals with topics such as space debris. Above them sit system-level documents that explain how the whole set is used and tailored.

The document codes are systematic. In "ECSS-E-ST-40C Rev.1", E is the engineering branch, ST marks a standard (as opposed to HB for a handbook or TM for a technical memorandum), 40 is the software discipline number, C is the issue letter and Rev.1 is the first revision of that issue. People in the industry usually just say "E-40" for this standard and "Q-80" for ECSS-Q-ST-80C.

A short history

Software engineering standards for European space projects existed before ECSS (ESA's PSS-05 software engineering standards were widely used in the 1990s). The first ECSS software engineering standard was issue A, followed by issue B in the early 2000s, then the major restructuring into the "ST" format as ECSS-E-ST-40C in March 2009. That 2009 issue served for sixteen years. A working group of agencies and industry processed 68 change requests from users and published Rev.1 on 30 April 2025, at the same time as Q-80 Rev.2. A deliberate rule of the revision was that existing requirement numbers must not change, so a compliance matrix written for the 2009 issue still lines up with Rev.1, with new requirements added rather than renumbered.

Scope

The standard applies to product software: software that is part of a space system product tree and is developed as part of a space project. That includes flight software in the space segment, software in the launch service segment, and software in the ground segment, as well as software that is not delivered but affects the delivered product (for example a tool that generates configuration tables). It covers the whole life of the software: system-level requirements that concern software, management, requirements and architecture, design and implementation, validation, delivery and acceptance, verification, operation, maintenance and – new in Rev.1 – security.

Just as important is what the standard does not cover. It does not define the product assurance programme for software (independent quality checks, metrics, criticality classification rules, reuse assurance); that is the job of ECSS-Q-ST-80C. It does not define how the project as a whole is managed or how formal project reviews run; those are M-branch topics. It does not define system engineering, which sits in ECSS-E-ST-10C, or the engineering of FPGAs and ASICs, which sits in ECSS-E-ST-20-40C. E-40 defines its interfaces to all of these so that the pieces fit together.

The customer–supplier idea

The single most important idea for reading E-40 is that every requirement describes an expectation between a customer and a supplier. The customer is whoever orders the software – an agency, a prime contractor, or a subsystem supplier buying from a smaller company. The supplier is whoever develops it. The relationship is recursive: a prime contractor is a supplier to the agency and a customer to its own subcontractors. Some requirements are addressed to the customer (for example, to define the system requirements and the criticality of the software); most are addressed to the supplier. The standard is designed to be made applicable through a contract, after tailoring.

Figure 1 – Where ECSS-E-ST-40C Rev.1 sits in the ECSS system and the standards it works with.

Figure 1 shows the family. E-40 and Q-80 are read together: E-40 says what engineering must be done and produced, Q-80 says how the supplier assures the quality and safety of that work. Supporting handbooks (ECSS-E-HB-40A for general guidance, ECSS-E-HB-40-01A on agile development and ECSS-E-HB-40-02A on machine learning) explain how to apply the requirements, but handbooks are guidance, not requirements.

Lesson 2 – Key concepts and vocabulary

ECSS uses a precise vocabulary. Rev.1 revisited its definitions, including a new definition of "software" and a new term "threat", and agreed them with the FPGA/ASIC standard. The terms below are explained in plain language; the official definitions are in clause 3 of the standard and in the ECSS glossary.

Customer and supplier – the two parties to every E-40 requirement: the one who orders and accepts the software, and the one who develops and delivers it. A company can be both at once in a supply chain.
Product software – software that forms part of the space system's product tree and is developed within the project, whether it flies, runs on the ground or supports the launch.
Requirements baseline (RB) – the customer's statement of what the software must do, captured in the software system specification and the interface requirements document, together with constraints such as criticality and security needs. It is the customer's view.
Technical specification (TS) – the supplier's response to the requirements baseline: the software requirements specification and the interface control document, written in engineering terms that designers and testers can work from. It is the supplier's view.
File – a logical grouping of documents that mature together and are presented at reviews. E-40 uses eight files plus, since Rev.1, a security file. A file is not necessarily one physical document.
Document requirements definition (DRD) – an annex that describes the expected content of one document, such as the software development plan. DRDs specify content, not layout or format.
Expected output – the part of each requirement that names what must be produced, which file it belongs to, and at which review it is presented. This is how E-40 ties activities to evidence.
Software criticality category – a letter from A (most critical) to D (least critical) that expresses how severe the consequences of a software failure could be. It drives how many requirements apply and how much verification is needed.
Tailoring – the process of selecting, modifying or adding requirements so that the standard fits a particular project's risk, size and constraints. ECSS standards are always tailored before being made applicable.
Verification – confirming that each output of an activity correctly reflects its inputs and the applicable rules ("did we build it right?"). In E-40 it is a process that runs alongside every other process.
Validation – confirming that the software meets its specified requirements, first against the technical specification and then against the requirements baseline ("did we build the right thing?").
Joint review – a review in which customer and supplier assess progress and evidence together. E-40 distinguishes formal project reviews, run with the formality of the M-branch review standard, from technical reviews with an agreed, lighter formality; Rev.1 added two new technical reviews.
Qualification and acceptance – qualification shows that the software meets its requirements in its intended environment; acceptance is the customer's decision to take delivery of it.
Independent software verification and validation (ISVV) – verification and validation performed by an organisation that is technically, managerially and financially independent of the developer, used for the most critical software.
Threat and vulnerability – a threat is a potential cause of harm through unauthorised action; a vulnerability is a weakness that a threat could exploit. Both terms matter for the new security process.
Software validation control – a Rev.1 concept that maps the system's verification control approach down to software level, using evidence such as test result matrices rather than an extra document.

Two views of requirements

The pair "requirements baseline" and "technical specification" confuses many newcomers, so it deserves a moment. Imagine a prime contractor ordering on-board software for a satellite. The prime writes down what it needs from the satellite's point of view: the modes the software must support, the telecommands it must accept, the response times, the interfaces to the platform computer, the criticality. That is the requirements baseline, and it is agreed at the system requirements review. The software supplier then analyses it and writes its own, more detailed and testable software requirements, plus the interface control document. That is the technical specification, and it is agreed at the software requirements review that prepares the preliminary design review. Validation later happens twice for this reason: once against the supplier's technical specification, and once against the customer's requirements baseline.

Criticality in one paragraph

The criticality category is not chosen by the software team. It comes from the system-level dependability and safety analyses, which classify how severe the effect of a function's failure would be – from catastrophic (for example, loss of life or loss of the launch site) down to minor or negligible. Q-80 maps those severities to software categories A, B, C and D, and a software product normally takes the category of the most critical function it implements. System design features such as independent hardware protections may justify a lower category, but only with analysis and the customer's agreement. Lessons 4 and 5 show how the category changes the work.

Lesson 3 – Structure of the standard

Like every ECSS standard, E-40 starts with scope (clause 1), normative references (clause 2) and terms, definitions and abbreviated terms (clause 3). Clause 4 explains the principles: the processes, the reviews and how the standard relates to the M and Q branches. Clause 5 contains the requirements, grouped into processes. The annexes describe documentation and give tailoring support. The summary below paraphrases the structure; consult the standard for the exact wording.

The software processes in clause 5

Subclause	Process	What it is about, in short
5.2	Software-related system requirements	The customer's work: system requirements allocated to software, interfaces, verification and validation needs, operations and maintenance needs, criticality and – in Rev.1 – security constraints, leading to the requirements baseline.
5.3	Software management	Lifecycle definition, the software development plan, joint and technical reviews, interface management with other teams, budget and margin management.
5.4	Software requirements and architecture engineering	Analysing the requirements baseline into the technical specification, and designing the software architecture, including real-time behaviour and reuse.
5.5	Software design and implementation engineering	Detailed design of components and interfaces, coding, unit testing and integration.
5.6	Software validation	Validation against the technical specification and then against the requirements baseline, with validation plans, specifications and reports.
5.7	Software delivery and acceptance	Preparing the release, installing it, and the customer's acceptance testing and decision.
5.8	Software verification	Verification of every output: requirements, architecture, design, code, tests, schedulability and budgets, including code coverage targets.
5.9	Software operation	Operating the software after delivery: operational testing, problem handling, user support and, in Rev.1, monitoring of vulnerabilities.
5.10	Software maintenance	Modifying the software after acceptance, including long-term maintenance of flight software, migration and retirement.
5.11	Software security (new in Rev.1)	Security management, security analysis maintained through the lifecycle, and security activities in each engineering phase.

Notice that the numbering does not follow a strict time order: verification (5.8) is listed after delivery (5.7) because it is a supporting process that runs in parallel with all the others, not a phase at the end. Management (5.3) and security (5.11) are also continuous. Figure 2 shows how they relate.

Figure 2 – The E-40 processes: engineering processes in sequence, with management, verification and security running continuously.

How a requirement is built

Each requirement in clause 5 has a number (for example 5.8.3.5), a short title, one or more lettered "shall" statements, and an expected output line. The expected output names the item to produce, the file it goes into, the document requirements definition that describes its content, and the review at which it must be available. Annex A collects all of this in a single document requirements list, a table that is effectively the map of the whole standard: if you want to know what must be ready for the critical design review, Annex A tells you. Rev.1 added the new security file to this list.

The files

E-40 groups its outputs into files so that customers and reviewers can find evidence quickly. The table below paraphrases their purpose.

File	Owner	Typical content
Requirements baseline (RB)	Customer	Software system specification, interface requirements document, system-level constraints including criticality and security needs.
Technical specification (TS)	Supplier	Software requirements specification, interface control document.
Design definition file (DDF)	Supplier	Software design document, source and executable code, software release document, software user manual.
Design justification file (DJF)	Supplier	Verification and validation plans, test specifications and reports, analyses (for example schedulability and budgets), reuse justification.
Management file (MGT)	Supplier	Software development plan, review plan, schedules and progress reports.
Maintenance file (MF)	Supplier	Maintenance plan, migration and retirement plans, maintenance records.
Operational file (OP)	Supplier, with operator input	Operational plan, operational testing and user support arrangements.
Product assurance file (PAF)	Supplier	Software product assurance plan, requirements and reports defined by Q-80.
Security file (new in Rev.1)	Supplier	Software security management plan, software security analysis report, security risk treatment plan.

The annexes

After Annex A, a long series of normative annexes are document requirements definitions. They describe documents such as the software system specification (SSS), interface requirements document (IRD), software requirements specification (SRS), interface control document (ICD), software design document (SDD), software release document, software user manual, software verification plan, software validation plan, unit and integration test plan, software validation specification, software verification report, software reuse file, software development plan (SDP) and software review plan. Rev.1 adds the security documents listed above. Other annexes support tailoring by criticality category and summarise the relationship with other standards.

Rev.1 also introduced Annex U, an informative annex on software code verification. In the 2009 issue, the list of things to check in the code sat inside the code verification requirement; Rev.1 moved those checks into Annex U and extended them to fourteen. They address arithmetic safety (numerical protection against overflow, underflow or division by zero, correct use of operators, risky implicit conversions), memory safety (array and buffer bounds, invalid or null accesses, uninitialised variables, leaks, pointer arithmetic), control flow (unintended infinite loops), data handling (variable lifetime and visibility, correct use of volatile data, unused assignments) and concurrency (race conditions). Most of these checks can be supported by static analysis tools, which is why the annex matters so much in practice.

Lesson 4 – How it works in practice

Choosing a lifecycle

E-40 does not impose a waterfall. It requires the supplier to define the software lifecycle it will follow and to describe it in the software development plan, consistent with the project's review milestones. In practice many projects still look like a V-model, because the system-level reviews happen in that order. But incremental, iterative and agile approaches are allowed, and Rev.1 deliberately removed wording that read as a waterfall bias. ECSS-E-HB-40-01A explains how sprints, backlogs and increments can be mapped onto the joint reviews and the expected outputs, for example by delivering documents incrementally and treating the review as a checkpoint on the latest increment.

The joint reviews

The heart of an E-40 project is its sequence of reviews. Each one checks that certain files have reached the agreed maturity before the project moves on.

SRR – system requirements review: customer-led; agrees the requirements baseline for the software and the supplier's first management plans.
SWRR – software requirements review: agrees the technical specification; when held separately it anticipates part of the PDR.
PDR – preliminary design review: agrees the technical specification and the software architecture, and the verification and validation approach.
DDR – detailed design review: checks the detailed design, anticipating part of the CDR.
CDR – critical design review: confirms the detailed design, code, unit and integration testing and validation against the technical specification.
QR – qualification review: confirms that the software is qualified, including validation against the requirements baseline.
AR – acceptance review: the customer accepts the delivered software after acceptance testing.
ORR – operational readiness review: confirms that the software and its operations arrangements are ready for operational use.

Alongside these project reviews there are technical reviews. A test readiness review (TRR) checks that a test campaign can start; a test review board (TRB) looks at its results. There is a TRR before each validation campaign; Figure 3 shows only the one before validation against the requirements baseline. Rev.1 added two more based on lessons learnt: a software validation specification review, which agrees the validation specification before the TRR so that disagreements about test content do not block the start of testing, and a software delivery review board, which formalises a good practice of large projects for checking each software delivery. Technical reviews are not mandatory milestones: they are lighter than project reviews; their formality is agreed between customer and supplier.

Figure 3 – The main joint and technical reviews of an E-40 software development and what each one confirms.

Verification and validation in daily work

Verification is not a phase but a habit. Requirements are checked for consistency, testability and traceability to the requirements baseline; the architecture is checked against the requirements; the design is checked against the architecture; code is checked against the design and against coding rules; tests are checked for coverage of the requirements. Traceability in both directions – from customer requirement to software requirement, design, code and test, and back – is a recurring theme.

Code verification is where Rev.1 tightened the rules. The code must be verified against a set of criteria (consistency with requirements and design, traceability, correct data and control flow, safety and security properties, absence of run-time errors, error handling), with the detailed checks now in Annex U. Structural code coverage measured during testing must reach targets that depend on the criticality category. For categories A and B, every statement and every decision must be exercised; for category A, modified condition/decision coverage (MC/DC), which shows that each condition in a decision independently affects its outcome, is also required. For lower categories the targets are "to be agreed" with the customer, and Rev.1 made sure a coverage measure is always reported, whatever the category. If testing cannot reach the target, the uncovered code must be justified by analysis, inspection or review. For category A, object code coverage is also needed when the supplier cannot show that the compiled object code corresponds to the source code. Real-time software also needs a schedulability analysis showing that tasks meet their deadlines with margin.

Validation is performed in two steps. Validation against the technical specification shows that the software meets the supplier's software requirements, usually on a representative test bench. Validation against the requirements baseline shows that it meets the customer's needs, often on a more complete system test environment. When a requirement truly cannot be tested, analysis, inspection or design review may be used, with justification.

Security throughout the lifecycle

Rev.1's largest change is the new software security process in 5.11, linked to around two hundred edits across the standard. Security starts at system level: the customer states security constraints, including constraints on the development and integration environments based on how sensitive the software is. The supplier writes a software security management plan that names the methods, tools and procedures it will use, performs a software security analysis that is kept up to date through the lifecycle, and plans how identified security risks will be treated. Security assurance requirements determine how much verification and validation is needed, which may include techniques such as fuzz testing. Residual vulnerabilities and risks are reassessed during verification and validation. In operation, vulnerabilities must be monitored continuously, and those judged not relevant are still recorded for audit.

Hardware–software co-engineering

Many space functions are split between software on a processor and logic in an FPGA or ASIC. Rev.1 recognises this co-engineering: requirements that concern software are still captured in the software system specification and interface requirements document, and the software development plan must identify the information exchanged between hardware and software teams, such as shared models and simulators. Definitions were aligned with the FPGA/ASIC standard so that both teams use the same words.

Roles

Typical roles on an E-40 project are the customer's software responsible (who owns the requirements baseline and leads the customer side of reviews), the supplier's software project manager, the software architect and developers, the verification and validation team, the software product assurance engineer (applying Q-80, reporting on quality and compliance), a security responsible (since Rev.1), configuration management, and, for critical software, an independent ISVV team. Operations engineers join for the operational readiness review and the operation and maintenance processes.

Lesson 5 – Assessment, certification and compliance

No certificate, but contractual compliance

There is no certification scheme for ECSS-E-ST-40C. An organisation cannot be "E-40 certified" the way it can be certified to ISO 9001, and no accredited body issues a product certificate against it. ECSS also has no personal certification for engineers; training certificates (like the one for this course) show learning, not compliance. Compliance is demonstrated inside a contract: the customer makes a tailored version of the standard applicable, the supplier commits to it, and the evidence is judged at the joint reviews and, finally, at acceptance.

Tailoring and the compliance matrix

The process usually runs like this. In the invitation to tender, the customer attaches the standard with an applicability matrix, stating for each requirement whether it applies, applies with modification, or does not apply. The tailoring is driven by the criticality category, the type of software (flight, ground, tool), the project's size and the use of existing software. The bidder answers with a compliance matrix, stating for each applicable requirement whether it is compliant, partially compliant or non-compliant, and justifying every deviation. After negotiation, the agreed matrix becomes part of the contract. Throughout the project, the expected outputs in each file are the evidence; reviewers check them at each milestone, and nonconformances are raised and closed through the project's normal processes.

How criticality drives the evidence

Figure 4 – How system failure analysis sets the software criticality category, which then scales the requirements and verification effort.

Figure 4 summarises the logic. The category comes from the system safety and dependability analyses defined in the Q branch, including a hardware–software interaction analysis that looks at how software reacts to hardware failures. Q-80 then gives an applicability matrix per category for its own requirements, and E-40 does the same for its requirements, so a category D tool needs far less evidence than a category A attitude controller. Independent software verification and validation is normally reserved for the highest categories; ESA's ISVV handbook, published in 2023, replaced fixed ISVV levels with a tailoring approach that sets the ISVV scope from task priorities, influencing factors and budget.

Who judges what

The customer judges conformity at each joint review and makes the final acceptance decision at the AR.
The supplier's software product assurance function, independent of the development team within the supplier, monitors compliance with E-40 and Q-80, audits processes and reports to the customer.
ISVV providers, where required, give an independent opinion on requirements, design, code and validation for critical software.
Process assessments under Q-80, based on the ISO/IEC 33000 family of process assessment standards, may be used to evaluate a supplier's capability before or during a contract.
Agency or prime contractor audits may be carried out at any time under the contract's terms.

Moving from the 2009 issue to Rev.1

Because requirement numbers were kept, migration is mostly additive. A supplier with an E-40 process from the 2009 issue should add the security process and security file, adopt the Annex U code checks (typically by configuring static analysis tools), make sure coverage is always measured, introduce the new technical reviews where the customer wants them, and update its templates for the revised definitions. Which issue applies to a given project is decided by the contract: projects started under the 2009 issue usually continue with it unless the customer and supplier agree otherwise.

Lesson 6 – Worked example

This fictional example shows how the pieces fit together. Nordlicht Avionics, a 120-person software company, is asked by a satellite prime contractor to deliver the on-board application software for the attitude and orbit control subsystem (AOCS) of an Earth observation satellite. The AOCS keeps the satellite pointing correctly; a failure could lead to loss of the mission.

Step 1 – Understanding the request

The prime's invitation to tender contains a software system specification and interface requirements document (the requirements baseline in draft), a statement that the software is category B based on the system failure analysis, and a tailored applicability matrix for ECSS-E-ST-40C Rev.1 and ECSS-Q-ST-80C Rev.2. The tailoring removes some requirements that only apply to ground software, and adds a project-specific requirement to use a given coding standard. Nordlicht's bid team reads Annex A of E-40 to list every document it will have to produce and every review it must support, and estimates the effort accordingly.

Step 2 – Committing in a compliance matrix

Nordlicht answers with a compliance matrix. It is compliant with most requirements, partially compliant with one (it proposes to deliver the software user manual as an online document set rather than a single document, with the same content), and asks for clarification on the security constraints for its development environment. After negotiation, the prime accepts the partial compliance and clarifies that development must take place on a segregated network. The agreed matrix becomes part of the contract.

Step 3 – Planning

The software development plan describes an incremental lifecycle: three increments, each adding AOCS modes, with a full validation campaign at the end. It maps increments to the project's reviews: the first increment's requirements and architecture for the PDR, the complete detailed design for the CDR. The plan also names the tools (a requirements management tool, a static analyser configured for the Annex U checks, a coverage tool able to measure statement and decision coverage on the target), the configuration management approach and the information exchanged with the hardware team that is designing an FPGA for sensor pre-processing. The security management plan, new for Nordlicht, describes how the team will perform security analysis and how it will protect its build environment.

Step 4 – From requirements baseline to technical specification

After the SRR has agreed the requirements baseline, Nordlicht's engineers write the software requirements specification and interface control document. Each software requirement traces to a customer requirement, and each customer requirement is covered. They hold a software requirements review with the prime, which finds that two requirements on mode transitions are not testable; they are rewritten before the PDR. At the PDR, the architecture is presented with a first schedulability analysis showing CPU load and deadlines with margin, and the verification and validation plans.

Step 5 – Design, code and verification

The team produces the detailed design and code in increments. Every merge triggers the static analyser, which checks the coding standard and the Annex U checks such as array bounds, uninitialised variables and race conditions; findings must be fixed or justified. Unit tests run on a host and on a target processor emulator, and coverage is measured. By the DDR, the design is complete; by the CDR, coverage for the critical modules reaches 100 % of statements and decisions, except for a defensive branch that handles a hardware fault the tests cannot provoke. The team justifies it by analysis and review, and records the justification in the design justification file. Validation against the technical specification on the software validation facility is reported at the CDR.

Step 6 – Security analysis

The security analysis looks at threats such as a corrupted software image uploaded from the ground or tampering with the build chain. The team adds requirements for checking the integrity of uploaded patches, documents residual risks in the security risk treatment plan, and runs fuzz tests on the telecommand parser as agreed in the security assurance requirements. The results go into the security file and are reviewed at the CDR and QR.

Step 7 – Validation, qualification and acceptance

Before the formal validation campaign against the requirements baseline, a validation specification review agrees which tests will demonstrate each customer requirement, so the TRR only has to confirm that the test bench and software version are ready. The campaign runs on a test bench with a real flight computer and simulated sensors. A validation result matrix links each requirement to its test result, providing the software validation control evidence. At the QR, the prime agrees that the software is qualified. Acceptance tests on the prime's system test bench follow, and at the AR the prime accepts the release, documented by the software release document.

Step 8 – Operation and maintenance

After launch, the satellite operator raises a problem report: a rare sensor combination causes an unnecessary safe mode entry. Under the maintenance process, Nordlicht analyses the problem, proposes a modification, applies the same engineering processes at the necessary depth (requirements update, design, code, verification, regression validation), and delivers a patch that the operator uploads after a delivery review board. Meanwhile, the supplier monitors vulnerability reports for the third-party library used in its ground tools, recording even those that do not apply.

What the example teaches

Every activity in the example produced an expected output, in a known file, for a known review. The criticality category drove the coverage target and the depth of verification. Tailoring was explicit and negotiated, not improvised. Security was planned from the beginning rather than added at the end. That is the practical shape of E-40.

Lesson 7 – Relationship to other standards and frameworks

E-40 rarely stands alone. The table compares it with the documents a space software engineer meets most often.

Standard	Focus	Relationship to ECSS-E-ST-40C Rev.1
ECSS-Q-ST-80C Rev.2 – Software product assurance	Assurance of software quality, safety and dependability: PA programme, criticality classification, tools, reuse, metrics, process assessment.	Twin standard, published at the same time (April 2025) and aligned with it; normally made applicable together. E-40 says what engineering to do, Q-80 how to assure it.
ECSS-E-ST-10C – System engineering	System requirements, design, verification and integration of the whole space system.	Provides the system context; E-40's software-related system requirements process is the bridge from system engineering to software.
ECSS M-branch standards (project planning, reviews, configuration management)	How the project is organised, reviewed and controlled.	E-40's project reviews follow the M-branch formality; configuration management of software items follows M-branch rules.
ECSS-E-ST-20-40C – ASIC, FPGA and IP core engineering	Engineering of programmable and custom digital hardware.	Definitions aligned; Rev.1 adds hardware–software co-engineering so both teams exchange models and requirements consistently.
DO-178C / ED-12C – Airborne software	Objectives for software in civil aircraft systems, with design assurance levels A to E, assessed by certification authorities.	Similar ideas (severity-driven levels, MC/DC at the top level, independence), but the levels do not map one to one: DO-178C level C, for example, requires statement coverage, while E-40 leaves category C targets to be agreed. DO-178C is objective-based and tied to aircraft certification, E-40 is requirement-based and tied to contracts.
ISO/IEC/IEEE 12207 – Software life cycle processes	Generic, industry-neutral software lifecycle processes.	Conceptual neighbour: E-40 can be seen as a space-specific, contract-ready set of process requirements with defined documents and reviews.
NASA NPR 7150.2 – NASA software engineering requirements	Software engineering requirements for NASA projects, scaled by software classification.	The US counterpart for agency missions; joint missions sometimes need mappings between the two.

Figure 5 places the main relationships around a single software development.

Figure 5 – How system engineering, safety analysis, product assurance, hardware engineering and project reviews feed a single E-40 software development.

A practical point for engineers coming from aviation: if you know DO-178C, much of E-40 will feel familiar, but the mindset differs. DO-178C asks you to satisfy objectives and show it to a certification authority; E-40 lists requirements that a customer has tailored into your contract and judges at reviews. Many space suppliers use tools and methods qualified for aviation, but they must still produce the E-40 files and pass the E-40 reviews.

Common pitfalls and best practices

Pitfalls

Applying the standard untailored. Treating every requirement as applicable to every project creates paperwork without value, especially for small ground tools. Tailoring is expected; it must be explicit and agreed.
Confusing the two specifications. Merging the customer's requirements baseline and the supplier's technical specification hides who owns which requirement and makes the two validation steps meaningless.
Treating verification as a final phase. Leaving code checks, traceability and coverage until just before qualification produces late surprises; E-40 expects verification throughout.
Writing documents for the review, not the project. Documents produced in a rush to pass a milestone often contradict the code. Reviewers notice, and maintainers suffer for years.
Bolting security on at the end. Under Rev.1, security constraints, analysis and risk treatment start with the requirements; adding them after the design costs far more.
Assuming the 2009 issue still applies. New contracts may call up Rev.1 with its security file and code verification annex; always check which issue the contract names.
Letting the team set its own criticality. The category comes from system analyses and is agreed with the customer; lowering it to save effort without justification is a serious nonconformance.

Best practices

Start from Annex A. Build your project's document and review map from the document requirements list, then align it with your lifecycle.
Automate traceability and code checks. Requirements management tools, static analysis configured for the Annex U checks and continuous coverage measurement make the evidence a by-product of daily work.
Negotiate the compliance matrix early and honestly. State partial compliance clearly with a reasoned alternative; hidden non-compliance becomes a review finding later.
Use technical reviews to de-risk joint reviews. A validation specification review or an early informal design walk-through can resolve disagreements before a formal milestone.
Plan agile delivery around the review evidence. If you work iteratively, use the agile handbook to map increments and documents to reviews, and agree that mapping with the customer.
Keep the security analysis alive. Update it at each review and after each change, and keep monitoring vulnerabilities in operation.
Involve product assurance from day one. The Q-80 function catches process gaps early and speaks the same language as the customer's assurance staff.

Summary and key takeaways

ECSS-E-ST-40C Rev.1 (30 April 2025) is the current ECSS software engineering standard; it replaces the 2009 issue and is published with its product assurance twin, ECSS-Q-ST-80C Rev.2.
It applies to product software in space, launch and ground segments and is made applicable through contracts between customers and suppliers, after tailoring.
Clause 5 defines the processes: system requirements for software, management, requirements and architecture, design and implementation, validation, delivery and acceptance, verification, operation, maintenance and the new security process.
Every requirement names an expected output, the file it belongs to and the review where it is checked; Annex A is the map of all of them.
The requirements baseline is the customer's view of the software, the technical specification is the supplier's; validation is done against both.
Criticality categories A to D, derived from system failure analyses, scale the requirements, the coverage targets and the need for independent verification.
Rev.1 added a software security process and security file, moved and extended code checks into Annex U, reduced waterfall bias and introduced new technical reviews.
There is no certification against E-40; compliance is judged by the customer at reviews and acceptance, supported by product assurance and, for critical software, ISVV.

Reflection questions

Think of a software system you know well. If it were delivered under E-40, what would belong in the requirements baseline and what in the technical specification, and who would own each?
A ground tool that generates configuration tables for flight software is not itself delivered. What arguments would you use to decide whether, and to what depth, E-40 should apply to it?
Your team works in two-week sprints. How would you present evidence to a preliminary design review and a critical design review without abandoning your iterative way of working?
Which of the Annex U code checks would be hardest to perform in the programming language your team uses, and what tools or language features would help?
If you had to move an existing product line from the 2009 issue to Rev.1, which three changes would you plan first, and why?