Verification vs validation in aerospace, and how spacecraft are verified
In short
Verification asks whether a product meets its specified requirements: did we build it right? Validation asks whether it fulfils its intended use and stakeholder needs in its intended environment: did we build the right thing?
Spacecraft verification combines inspection, analysis, demonstration and test with qualification and acceptance campaigns, model-based methods, and software and cybersecurity assurance. Methods are chosen requirement by requirement.
01
Verification and validation are different questions
Systems-engineering standards and handbooks treat verification and validation as separate processes, even when one test produces evidence for both. NASA's systems engineering guidance frames verification as proof of compliance with specifications and validation as proof that the product accomplishes its intended purpose for its stakeholders.
| Verification | Validation | |
|---|---|---|
| Question | Did we build the product right? | Did we build the right product? |
| Measured against | Specified requirements | Stakeholder needs and intended use |
| Typical evidence | Test reports, analyses, inspection records, review records | Operational scenarios, end-to-end tests, user or operator evaluations, mission simulations |
| Environment | Controlled conditions defined by the procedure | The intended operational environment, real or realistically simulated |
| Failure means | The product does not meet its specification | The specification, or the product, does not meet the need |
A satellite example
A requirement says the X-band downlink shall deliver 40 GB per day. A link-budget analysis and an RF test verify it. Validation asks a different question: with real orbits, real ground-station passes and real operators, does the mission actually deliver the images its users need, in time to be useful? That is answered with end-to-end tests and mission simulations, not by re-reading the requirement.
02
What is requirements verification?
Requirements verification turns each requirement into a planned, evidenced and approved conclusion. In practice it runs through the same steps for every requirement:
- 01Verifiable requirement
- 02Method selected
- 03Verification event planned
- 04Event executed on a known configuration
- 05Evidence produced
- 06Result assessed against criteria
- 07Issues resolved
- 08Closure approved
Verification happens at several levels (component, subsystem, system) and stages (qualification, acceptance, pre-launch and in orbit). A verification matrix records the plan and the status. The weak point is rarely the plan. It is keeping the status true as designs, builds and procedures change; see configuration-aware evidence validity.
03
Verification method taxonomy
Classical verification
The four methods most aerospace verification matrices start from. Each requirement is assigned one or more of them.
- Inspection
- Visual or dimensional examination of the product, or of its drawings and records, to confirm a physical feature, marking or documented attribute.Example: Confirming connector keying and labelling on a harness.
- Analysis
- Calculation, modelling or simulation that shows a requirement is met, used when testing is impractical or as a complement to test.Example: Structural margin analysis of a bracket under launch loads.
- Demonstration
- Operating the product to show that it performs a function, with little or no quantitative data collected.Example: Showing that a deployment mechanism releases on command.
- Test
- Operating the product under controlled conditions and measuring its response against defined pass/fail criteria. The most resource-intensive method.Example: Measuring battery charge regulation across temperature.
Extended aerospace assurance
Methods and evidence classes that sit around the classical four in spacecraft and aircraft programmes.
- Qualification
- Proves that the design meets its requirements with margin, typically by testing a qualification unit at levels beyond the expected environment. Done once per design.Example: Random vibration at qualification levels on a qualification model.
- Acceptance
- Shows that each flight unit is built correctly and free of workmanship defects, typically at levels equal to the expected environment. Done on every unit.Example: Acceptance thermal cycling of each flight battery.
- Similarity / heritage
- Reuses evidence from an identical or closely similar item, with a documented comparison of design, configuration, environment and application.Example: Claiming qualification of a reaction wheel flown on a previous mission.
- Review of design
- Verification by reviewing approved design documentation, drawings or records against the requirement. ECSS treats this as a formal method.Example: Confirming an interface definition against the ICD.
- Certification / compliance evidence
- Evidence assembled to show compliance with a certification basis or regulatory requirement, for review by the responsible authority.Example: Compliance records submitted for an airworthiness approval.
- Independent review / assessment
- Assessment by people or organisations independent of the developer, such as independent verification and validation (IV&V) of software.Example: IV&V of fault-management flight software.
Model-based and digital verification
Verification that relies on models and simulation. Its evidence is only as good as the model's own validation and configuration.
- MBSE-supported verification
- Requirements, architecture and verification relationships held in a system model, so coverage and impact can be queried rather than compiled by hand.
- Physics-based simulation
- Thermal, structural, orbital, power or RF models that predict behaviour. Typically correlated against test results before being relied on.
- Monte Carlo / uncertainty analysis
- Running a model many times with varied inputs to estimate the probability of meeting a requirement, not only the nominal case.
- Model-in-the-loop (MIL)
- Control or software design models executed against simulated plant models before code exists.
- Software-in-the-loop (SIL)
- Compiled flight software executed on a host computer against simulated hardware and environment.
- Processor-in-the-loop (PIL)
- Flight software running on the target processor, or a representative one, with simulated surroundings.
- Hardware-in-the-loop (HIL)
- Real flight or engineering-model hardware connected to simulated sensors, actuators and dynamics, so closed-loop behaviour can be tested on the bench.
- Digital twins
- A model maintained alongside a specific physical system and updated with its data. In AEAIP a digital twin is an evidence source, not a separate platform.
- Scenario-based verification
- Verifying behaviour across defined operational scenarios, such as safe-mode entry or eclipse transitions, rather than single requirements in isolation.
- Automated regression
- Re-running a defined test set automatically after each change, so previously verified behaviour is re-confirmed.
Software assurance
Evidence that software meets its requirements and was built from a known, reproducible configuration.
- Requirements-based testing
- Test cases derived from, and traced to, software requirements.
- Unit verification
- Verification of individual software units in isolation.
- Integration verification
- Verification of interfaces and interactions between software components.
- System verification
- Verification of the integrated software on representative hardware.
- Static analysis
- Analysis of source code without executing it, for defects, rule violations and vulnerabilities.
- Dynamic analysis
- Analysis of software behaviour while it executes, such as timing, memory and resource use.
- Coverage evidence
- Measured statement, branch or condition coverage, at the level the applicable software standard requires.
- Formal methods (where justified)
- Mathematical proof of selected properties, typically reserved for the most critical logic.
- Configuration reproducibility
- Evidence that the verified binary can be rebuilt exactly from controlled source, tools and settings.
- CI/CD evidence (where controlled)
- Automated build and test records, usable as evidence only when the pipeline itself is under configuration control.
Cybersecurity assurance
Security verification treated like any other verification: requirements, methods, findings, remediation and retest.
- Threat modelling
- Systematic identification of threats, attack paths and the assets they target.
- Security requirement verification
- Verifying that each security requirement is implemented and effective.
- Secure-design review
- Review of architecture and design against security principles and the threat model.
- Static application security testing
- Source or binary analysis for security weaknesses, where applicable.
- Dynamic application security testing
- Testing running software or services for exploitable weaknesses, where applicable.
- Software composition analysis
- Identifying third-party components and their known vulnerabilities.
- SBOM / software provenance
- A software bill of materials and the origin of each component for a given build.
- Fuzzing
- Feeding malformed or unexpected inputs, for example to command parsers, to find failures.
- Penetration testing
- Authorised attempts to exploit the system as an attacker would.
- Configuration verification
- Checking that security-relevant settings match the approved configuration.
- Firmware integrity
- Evidence that the firmware loaded is the firmware that was approved.
- Secure boot evidence
- Evidence that only authenticated software can start on the processor.
- Communications-security evidence
- Evidence for authentication and encryption of command and telemetry links.
- Supply-chain security evidence
- Evidence about the origin and handling of hardware and software components.
- Retest after remediation
- Re-verification that a finding is fixed and nothing else was broken.
Operational evidence
Evidence produced after launch. It can confirm, refine or challenge what was predicted and tested.
- Telemetry
- Measured spacecraft data downlinked during operations.
- Health monitoring
- Trending of telemetry against limits to detect degradation.
- Anomaly evidence
- Records of in-flight anomalies, their investigation and resolution.
- Actual mission performance
- Measured performance against mission requirements and success criteria.
- Field / flight behaviour
- Observed behaviour across the fleet or mission life, fed back into future designs.
Frameworks group these differently. NASA guidance centres on test, analysis, inspection and demonstration; ECSS verification guidance treats test, analysis, review-of-design and inspection as its methods. A programme's verification plan defines which apply.
04
Qualification, acceptance and protoflight
Environmental testing answers two different questions. Is the design good enough, with margin? And was this particular unit built correctly? Qualification answers the first; acceptance answers the second. A protoflight approach answers both on the flight unit when no separate qualification unit is built.
| Qualification | Acceptance | Protoflight | |
|---|---|---|---|
| Purpose | Prove the design meets requirements with margin | Prove each unit is built correctly, free of workmanship defects | Prove design and workmanship on the flight unit itself |
| Article | Dedicated qualification unit | Every flight or production unit | The flight unit |
| Levels | Above expected environment, typically longer duration | At expected environment | Between acceptance and qualification, typically shorter duration |
| Frequency | Once per design (repeated if the design changes) | Every unit | Once, on the unit that will fly |
| Trade-off | Highest confidence, extra hardware cost | Does not prove design margin by itself | Saves a unit; accepts more risk to the flight hardware |
Exact levels, margins and durations come from the programme's environmental verification standard, for example NASA Goddard's General Environmental Verification Standard or the ECSS testing standard, and from the launch vehicle's requirements.
Similarity and heritage
Reusing evidence from a previously qualified item is legitimate and common, but only with a documented comparison of design, configuration, manufacturing, environment and application. A small change in any of these can be enough to invalidate the heritage claim, which is why AEAIP treats heritage evidence like any other evidence: linked to the configuration it actually proves.
05
Model-based and digital verification
Models let a team verify behaviour that is impractical to test: a full orbit of thermal cycling, thousands of Monte Carlo dispersions of a manoeuvre, or a fault that would damage hardware. They also introduce a new dependency. A model's output is evidence only if the model itself is credible for that use: validated against test data, run within its validated range, and identified by version.
That is why thermal models are correlated against thermal-vacuum results, and why a simulation result in AEAIP is linked to the model version and input set that produced it. Digital twins follow the same rule; see Predicted → Tested → Flown.
06
How does HIL testing verify avionics?
In hardware-in-the-loop testing, the real on-board computer runs real flight software, connected through its real interfaces to a real-time simulation of the spacecraft: sensors, actuators, power, dynamics and environment. The computer cannot tell it is not flying.
- It verifies closed-loop behaviour: attitude control, mode transitions, fault detection and recovery.
- It allows fault injection that would be unsafe on the integrated spacecraft.
- It measures timing on the real processor, which software-in-the-loop cannot.
Its limits matter as much. The simulator is part of the test configuration: a result is evidence for the hardware revision, software build and simulator version it ran on, and only as good as the simulator's own fidelity. When any of those change, the result may need to be repeated. The Interactive Assurance Demo follows one HIL failure, FSW-247, through anomaly, corrective action and retest.
07
Software verification and assurance
Flight software is verified through requirements-based tests at unit, integration and system level, supported by static and dynamic analysis and coverage measurement at the level the applicable standard requires. NASA programmes follow NPR 7150.2 and NASA-STD-8739.8; European space programmes use the ECSS software engineering and software product assurance standards; airborne software is commonly developed to RTCA DO-178C.
The evidence is only meaningful for a reproducible build. A test report for build 4.2.0 says nothing on its own about build 4.2.1, which is why software configuration identifiers sit on every software evidence record in AEAIP.
08
Cybersecurity verification
Security requirements are verified like any other requirement: by design review, analysis and test, including penetration testing and fuzzing of command interfaces. Findings are tracked to closure with retest after remediation. See cybersecurity as engineering assurance.
09
How verification relates to certification
Verification produces the evidence. Certification is a formal decision by an authorised body that a product or design meets a defined set of requirements, made by reviewing that evidence.
Aircraft and airborne equipment are certified by civil or military airworthiness authorities. Space systems are usually governed by programme and customer acceptance, launch-provider requirements and national authorisation regimes rather than a type certificate. In every case, software can help organise and check the evidence; it does not certify. Certification evidence is the focus of AirCert AI™.
10
Example: a verification matrix
| Requirement | Statement | Method | Level | Event | Status |
|---|---|---|---|---|---|
| SAT-EPS-014 | Battery charge termination 4.10 V ±0.015 V/cell, 0–40 °C | Test | Subsystem | TP-EPS-022 Rev B in TVAC | Reopened · reverification required |
| FSW-247 | Safe-mode transition within 2 s of watchdog timeout | Test (HIL) | Software / avionics | HIL campaign C3-R | Open · retest pending |
| STR-012 | First lateral natural frequency above 50 Hz | Analysis + test | System | Modal analysis; sine survey in vibration test | Closed · approved |
| THM-014 | Radiator emissivity ≥ 0.88 | Inspection | Component | Coating measurement | Waiver WVR-007 |
| COM-002 | TT&C link compatible with ground network | Test | System + ground | End-to-end RF compatibility test | Planned |
Questions
Verification and validation questions
What is the difference between verification and validation?
Verification confirms, with objective evidence, that a product meets its specified requirements: did we build the product right? Validation confirms that the product fulfils its intended use and stakeholder needs in its intended environment: did we build the right product? A product can pass verification and still fail validation if the requirements themselves were wrong.
What is spacecraft verification?
Spacecraft verification is the planned set of inspections, analyses, demonstrations and tests that show each spacecraft requirement is met, at component, subsystem and system level. It includes qualification and acceptance campaigns such as vibration, shock, thermal vacuum and EMC testing, and ends with closure of every requirement before the spacecraft is accepted and flown.
What is requirements verification?
Requirements verification is the process of assigning each requirement a verification method, planning the event that will produce evidence, executing it on a known configuration, assessing the result against defined criteria and having an authorised person close the requirement. It is usually managed through a verification matrix.
How does HIL testing verify avionics?
In hardware-in-the-loop (HIL) testing, real avionics hardware such as the on-board computer runs flight software while connected to real-time simulations of sensors, actuators, dynamics and environment. It verifies closed-loop behaviour, timing and fault responses that cannot be safely or affordably tested on the integrated spacecraft. Its evidence is valid only for the hardware revision, software build and simulator version it ran on.
References / Engineering Sources
Explanations on this page are original GAMYAA paraphrase. Standards are referenced, not reproduced; paid standards link to their publisher. Referencing a framework does not imply compliance with it.
- 01NASA Systems Engineering Handbook — 5.3 Product Verification (opens in a new tab)
NASA
Verification methods, qualification, acceptance and recording the product and requirement versions verified.
- 02NASA Systems Engineering Handbook — 5.4 Product Validation (opens in a new tab)
NASA
Validation against stakeholder expectations in the intended environment.
- 03ISO/IEC/IEEE 15288:2023, Systems and software engineering — System life cycle processes (opens in a new tab)
ISO / IEC / IEEE
Life-cycle process descriptions, including verification and validation processes.
- 04ECSS-E-ST-10-02C Rev.1, Space engineering — Verification (opens in a new tab)
European Cooperation for Space Standardization
Verification methods (test, analysis, review-of-design, inspection), levels and stages.
- 05ECSS-E-ST-10-03C, Space engineering — Testing (opens in a new tab)
European Cooperation for Space Standardization
Verification by testing of space segment elements and equipment before launch.
- 06GSFC-STD-7000B, General Environmental Verification Standard (GEVS) (opens in a new tab)
NASA Goddard Space Flight Center
Environmental verification programmes and test levels for GSFC payloads, subsystems and components.
- 07NPR 7150.2D, NASA Software Engineering Requirements (opens in a new tab)
NASA Office of the Chief Engineer
Software engineering requirements, including software verification and validation.
- 08NASA-STD-8739.8B, Software Assurance and Software Safety Standard (opens in a new tab)
NASA
Software assurance, software safety and IV&V.
- 09ECSS-E-ST-40C Rev.1, Space engineering — Software (opens in a new tab)
European Cooperation for Space Standardization
Space software engineering processes, including verification and validation.
- 10ECSS-Q-ST-80C Rev.2, Space product assurance — Software product assurance (opens in a new tab)
European Cooperation for Space Standardization
Software product assurance for space projects.
- 11SEBoK — System Verification (opens in a new tab)
Systems Engineering Body of Knowledge (INCOSE, IEEE SMC, SERC)
Open reference on verification concepts and methods.
- 12SEBoK — System Validation (opens in a new tab)
Systems Engineering Body of Knowledge (INCOSE, IEEE SMC, SERC)
Open reference on validation concepts.
- Published by
- Gamyaa AeroSystems — Engineering Assurance Research
- Last reviewed
- Status
- Status: Research