ECSS Qualification and Acceptance Testing
Accredited
Scope Available
Programmes
Plus Certified
Expertise
Test Evidence
Qualification testing and acceptance testing are two of the most important verification activities performed on space hardware before launch. They are closely connected, but they answer different engineering questions.
Qualification testing provides evidence that a design performs according to its specification in the intended environments with defined qualification margins. It is concerned primarily with design confidence.
Acceptance testing applies to each flight product, except the article used under an agreed protoflight approach. It provides evidence that the manufactured article performs according to specification with acceptance margins and is free from workmanship defects or flawed materials.
ECSS-E-ST-10-03C Rev.1 defines requirements for qualification, acceptance and protoflight testing. It also addresses test programmes, environmental testing, functional testing, margins, durations, tolerances, measurement uncertainty, reviews and documentation.
Confusing qualification with acceptance is a serious programme-planning error. The wrong test philosophy can produce insufficient verification evidence, expose flight hardware unnecessarily or consume cost and schedule without answering the project’s decision question.
This guide explains the differences, similarities and practical controls engineers should consider.
Qualification testing provides evidence that a space-segment element or item of equipment performs according to its specification in the intended environments with the required qualification margins.
Its primary purpose is to demonstrate confidence in the design.
Qualification testing is normally conducted on a dedicated Qualification Model. A Protoflight Model may be used where the project has selected an approved protoflight approach.
A Qualification Model should represent the flight design sufficiently for the resulting evidence to remain relevant. Differences in materials, interfaces, manufacture, software, thermal paths, load paths or operating modes can weaken the qualification conclusion.
Qualification testing is not simply harsher acceptance testing. It forms part of a planned verification strategy and should be supported by analysis, inspection or review of design where those methods are needed.
Qualification is normally positioned after the design has matured and relevant development testing has been completed.
It supports:
design verification;
completion of development activity;
confirmation of design margins;
environmental verification;
model correlation;
qualification reviews;
acceptance planning; and
progression towards flight-hardware production and release.
ECSS-E-ST-10-03C Rev.1 requires development testing to be completed before formal qualification begins. Development testing should not be conducted on qualification or flight models.
Design-risk reduction
Qualification testing exposes design weaknesses before they become recurring flight-hardware problems.
A failure during qualification may indicate a weakness in:
structural design;
thermal design;
materials;
interfaces;
electrical design;
software or operating modes;
manufacturing process; or
the original environmental assumptions.
The result must be investigated rather than treated only as a laboratory failure.
Qualification margins increase the severity beyond the maximum conditions expected during the product lifetime.
Depending on the applicable requirement, the margin may involve:
increased level;
extended range;
increased duration;
additional cycles; or
another justified increase in severity.
Margins should come from the controlled project baseline. They should not be improvised from facility capability or applied without understanding the hardware.
Qualification evidence supports the verification process when it is linked to:
an applicable requirement;
the approved model;
a controlled configuration;
defined conditions;
suitable instrumentation;
measurement uncertainty;
agreed success criteria; and
a clear conclusion.
A completed test is not automatically usable qualification evidence.
Qualification reduces the risk of committing an inadequately demonstrated design to flight manufacture or integration.
It cannot guarantee mission success. Confidence also depends on design analysis, product assurance, configuration control, manufacturing controls, acceptance testing and effective anomaly management.
Qualification planning commonly interacts with:
ECSS-E-ST-10, System Engineering General Requirements;
ECSS-E-ST-10-02, Verification;
ECSS-E-ST-10-03C Rev.1, Testing;
ECSS-S-ST-00, ECSS system application;
ECSS-S-ST-00-02, Tailoring;
ECSS-Q-ST-20, Quality Assurance; and
applicable specialist engineering and product assurance standards.
The complete requirement set depends on the product, project and contractual baseline.
The model philosophy determines which article will provide qualification evidence.
Possible models include:
Qualification Model;
Engineering Qualification Model;
Structural Model;
Thermal Model;
Protoflight Model;
representative assembly; or
dedicated destructive-test model.
The chosen article must represent the function being verified.
Qualification requirements may be tailored according to:
mission consequence;
product level;
design maturity;
heritage;
intended environment;
model philosophy;
available analysis;
customer requirements; and
accepted risk.
Heritage should not be treated as automatic qualification. Changes to the design, materials, manufacturing route, interfaces, mission or environment may require delta qualification.
Customers may define additional requirements covering:
environmental levels;
durations;
operating modes;
test sequence;
allowable notching;
functional monitoring;
inspection;
success criteria;
witnessing; and
evidence format.
Conflicts between ECSS, launcher and customer requirements should be resolved before procedure approval.
The project establishes the qualification strategy, applicable requirements, model philosophy and verification method.
The expected evidence and authority for approval should be clear.
Preparation normally includes:
approved Test Specification;
controlled Test Procedure;
confirmed model configuration;
fixture and facility readiness;
instrumentation planning;
calibration confirmation;
functional baseline;
safety review; and
Test Readiness Review.
The approved environmental, functional and performance activity is conducted.
The as-run record should capture actual conditions, changes, deviations, holds and anomalies.
The project assesses:
achieved conditions;
data quality;
functional performance;
anomalies;
nonconformances;
measurement uncertainty;
compliance with success criteria; and
implications for the design.
The Test Report records the activity and results.
Verification reporting then uses the evidence to support requirement closure. The customer or appointed verification authority determines whether the qualification objective has been met.
Depending on the product and project, qualification may include:
vibration testing;
mechanical shock or SRS testing;
acoustic testing;
thermal vacuum testing;
thermal testing;
EMC verification;
pressure or leak testing;
mechanism testing;
functional testing;
performance testing; and
mission-specific environmental activity.
Not every test applies to every product.
Resonate can support vibration, shock, SRS and thermal vacuum testing where the requirement, facility fit and scope are confirmed. Acoustic and EMC activity should be coordinated with suitable specialist providers.
An unsuitable model, fixture, configuration or operating mode can make the result unrepresentative.
Late qualification can delay flight manufacture, integration and customer reviews.
Dedicated qualification hardware can be expensive. However, removing it without understanding the alternative risk can be more expensive.
A test can be technically successful but fail to close the requirement because traceability, configuration or acceptance criteria are incomplete.
Poor Test Specifications, procedures or as-run records can weaken otherwise valid data.
Acceptance testing provides evidence that a flight product performs according to its specification in the intended environments with the specified acceptance margins.
It is performed on each flight product, except the first flight model used under an agreed protoflight approach.
Acceptance testing also helps assure freedom from workmanship defects and flawed materials.
The programme follows successful qualification or forms part of the combined evidence generated under a protoflight strategy.
Acceptance testing is normally completed after manufacture and before delivery, higher-level integration or launch preparation.
It supports:
manufacturing completion;
equipment acceptance;
spacecraft integration;
delivery reviews;
flight-hardware release;
launch preparation; and
verification close-out.
Acceptance evidence applies to the article and configuration that were tested. It should not be transferred automatically to a different item or modified configuration.
A qualified design can still be manufactured incorrectly.
Acceptance testing can reveal problems involving:
assembly;
fasteners;
soldering;
connectors;
wiring;
materials;
contamination;
workmanship;
manufacturing variation;
handling damage; or
integration errors.
The actual flight article is exposed to agreed conditions.
This gives the project evidence about its configuration and performance before delivery or launch.
Acceptance testing confirms that the flight product performs according to its specification with acceptance margins.
It is not simply an inspection. Functional and environmental evidence may both be required.
Acceptance testing reduces the risk that an individual manufacturing or integration problem remains undiscovered until launch or operation.
It does not demonstrate qualification margin unless the project is using an approved protoflight approach.
ECSS-E-ST-10-03C Rev.1 requires acceptance testing on each flight product except the product used as Protoflight.
The acceptance programme follows completion of the applicable qualification programme.
The standard defines acceptance test levels and durations through its equipment-level and element-level tables. Those durations are minimum values.
The project must still confirm:
product level;
applicable test baseline;
flight configuration;
customer requirements;
operating modes;
acceptance margins;
functional checks;
tailoring;
evidence requirements; and
review authority.
Acceptance profiles should not be changed informally because a facility has spare capacity or because a qualification profile is already available.
The project defines the flight-item acceptance campaign and confirms the applicable baseline.
Preparation should confirm:
as-built configuration;
software version;
calibration status;
fixture and instrumentation;
procedure approval;
pre-test functional performance;
cleanliness and safety requirements;
acceptance criteria; and
readiness-review actions.
The flight product undergoes the approved environmental, functional and performance activity.
Actual conditions, deviations and anomalies are recorded in the as-run procedure.
The project reviews:
achieved conditions;
post-test performance;
inspections;
anomalies;
nonconformances;
data quality;
acceptance criteria; and
any effect on residual life.
The Test Report records the evidence.
The customer or appointed authority decides whether the product can be accepted, integrated, delivered or progressed towards flight.
Depending on the applicable baseline, acceptance may include:
acceptance vibration testing;
thermal vacuum testing;
thermal testing;
functional testing;
performance testing;
leak testing;
mechanism checks;
electrical checks;
visual inspection;
configuration verification; and
pre-test and post-test inspection.
The campaign should be proportionate to the product, environment and customer requirements.
Insufficient testing can allow workmanship or manufacturing defects to remain undetected.
Unnecessary repetition or increased severity can consume flight-hardware life.
Flight-hardware availability, anomaly investigation and retesting can affect delivery or launch milestones.
Incomplete evidence can delay acceptance even when the hardware appears to have performed correctly.
The acceptance conclusion applies only to the tested configuration. Uncontrolled changes can invalidate the evidence.
Confirm the as-built configuration before testing.
Record hardware and software versions.
Use approved acceptance profiles.
Establish pre-test functional baselines.
Maintain strict procedure control.
Record all deviations and anomalies.
Conduct post-test inspection and functional checks.
Assess cumulative environmental exposure.
Retest only with appropriate technical authority.
Preserve the complete evidence chain.
Acceptance testing does not normally demonstrate design qualification margins.
Additional severity can damage flight hardware or consume unnecessary life.
A qualified design does not prove that every manufactured product is free from defects.
Evidence is only valid for the tested article and controlled configuration.
The project must still review data, anomalies, configuration, inspections and open actions.
| Area | Qualitfication Testing | Acceptance Testing |
|---|---|---|
| Primary objective | Demonstrate design performance with qualification margins | Demonstrate flight-product performance with acceptance margins and identify workmanship or material defects |
| Primary question | Is the design adequately demonstrated? | Is this flight product acceptable? |
| Typical hardware | Dedicated Qualification Model or agreed representative model | Each flight product |
| Protoflight exception | Qualification and acceptance objectives combined on the first flight model | Separate acceptance testing does not apply to the Protoflight Model in the same way |
| Margins | Qualification margins | Acceptance margins |
| Programme position | Before the acceptance programme | After successful qualification |
| Failure implication | May indicate a design, requirement or qualification-strategy issue | May indicate workmanship, manufacturing, handling, integration or article-specific issues |
| Evidence use | Supports qualification and VCD close-out | Supports flight-product acceptance and VCD close-out |
| Hardware life | Usually conducted on non-flight qualification hardware | Conducted on flight hardware and must protect residual life |
| Decision authority | Customer or appointed verification authority | Customer or appointed acceptance authority |
Both activities require:
applicable requirements;
controlled configurations;
approved test documentation;
suitable facilities and instrumentation;
defined conditions and tolerances;
measurement uncertainty;
success criteria;
functional checks;
anomaly control;
traceable results; and
formal review.
Both generate objective evidence. Neither should be reduced to a facility booking.
Engineering teams should consider:
Verification objective.
Product level.
Model philosophy.
Applicable ECSS requirements.
Customer and launcher requirements.
Mission environment.
Qualification and acceptance margins.
Design heritage.
Manufacturing maturity.
Hardware availability.
Residual-life constraints.
Required evidence.
Schedule-recovery options.
Consequence of failure.
Approved tailoring.
The decision should be made before hardware manufacture and facility booking wherever possible.
| Document | Role |
|---|---|
| Verification Plan | Defines verification methods, levels, stages and model philosophy. |
| Verification Control Document | Tracks applicable requirements and close-out evidence. |
| AIT Plan | Defines assembly, integration and test activities, facilities, responsibilities and schedule. |
| Test Specification | Defines what the test must achieve, including configuration, conditions, uncertainty and criteria. |
| Test Procedure | Provides controlled step-by-step execution and becomes the as-run record. |
| Test Report | Records activity, achieved conditions, results, anomalies and conclusions. |
| Verification Report | Uses evidence to support verification close-out. |
| Nonconformance records | Control unexpected results and departures from requirements. |
| Requests for Deviation or Waiver | Record authorised departures from the original requirement baseline. |
The Test Specification and Test Procedure are different documents. For simple activities, the project may agree to combine them, but their required content and control still remain relevant.
Success is indicated when:
the required conditions were achieved;
the representative design performed as specified;
qualification margins were demonstrated;
anomalies were resolved or controlled;
evidence remained traceable;
the applicable qualification requirements can be closed; and
the authorised project body agrees the design may progress.
Success is indicated when:
the flight article completed the applicable campaign;
acceptance conditions were achieved;
functional and performance criteria were satisfied;
no unresolved critical workmanship or material issue remains;
configuration and evidence are traceable; and
the authorised project body accepts progression.
The test laboratory provides evidence. It does not make the complete product qualification, acceptance or flight-readiness decision.
Resonate can review customer-supplied requirements, environmental profiles, hardware information and expected outputs.
This helps identify missing inputs before quotation or facility booking.
Subject to technical review, Resonate can support the practical development of:
vibration testing;
mechanical shock and SRS testing;
thermal vacuum testing;
selected environmental testing; and
functional monitoring during exposure.
The fixture, load path, control locations, response channels, thermal interfaces and monitoring approach can affect the validity of the evidence.
These interfaces should be reviewed early.
Resonate can contribute test-specific information to:
AIT Plans;
Test Specifications;
Test Procedures;
readiness reviews;
as-run records;
Test Reports; and
evidence packages.
The customer retains control of the Verification Plan, model philosophy, Verification Control Document and requirement closure.
The objective is not to maximise test severity or facility time.
It is to help define controlled activity that answers the project’s engineering question and produces evidence the customer can use.
Vibration, shock, SRS and thermal vacuum activity can be coordinated through one engineering team where technically suitable.
EMC and acoustic testing are not claimed as direct Resonate capabilities on this page. Those activities should be coordinated with appropriate specialist providers.
Your Test Facilitator. Not simply a test facility.
Whether you’re looking to contact us for the first time or have another testing requirement, we’d love to hear from you.
