Qualification Testing vs Acceptance Testing Under ECSS

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.

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.

• Complete development testing before formal qualification.

• Confirm the representative model and configuration.

• Maintain requirement-to-evidence traceability.

• Define levels, durations and margins before facility booking.

• Agree success criteria before execution.

• Review fixtures, control locations and response channels.

• Include functional checks at meaningful points.

• Record every deviation and anomaly.

• Protect configuration after successful qualification.

• Reassess qualification after relevant design or manufacturing changes.

Qualification primarily addresses design confidence. It does not replace acceptance of each manufactured flight product.

Heritage is useful only where the previous evidence remains relevant to the current design, environment, manufacture and use.

Qualification and acceptance levels serve different objectives. They should not be exchanged without authorised tailoring.

Evidence from a model with significant differences may not support qualification of the flight design.

More severe testing is not automatically better verification. Unjustified severity can produce unrealistic failures or damage an otherwise adequate design.

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.

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:

1. Verification objective.

2. Product level.

3. Model philosophy.

4. Applicable ECSS requirements.

5. Customer and launcher requirements.

6. Mission environment.

7. Qualification and acceptance margins.

8. Design heritage.

9. Manufacturing maturity.

10. Hardware availability.

11. Residual-life constraints.

12. Required evidence.

13. Schedule-recovery options.

14. Consequence of failure.

15. Approved tailoring.

The decision should be made before hardware manufacture and facility booking wherever possible.

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.

These FAQs explain the practical difference between qualification and acceptance testing.

Requirements vary by project and approved tailoring. If anything needs clarification, please contact us. We welcome feedback and are happy to discuss your programme.

Qualification testing provides evidence about the design with qualification margins. Acceptance testing provides evidence about each flight product with acceptance margins and helps identify workmanship or material defects.

Yes. ECSS-E-ST-10-03C Rev.1 includes requirements for qualification, acceptance and protoflight testing.

Yes. Under the ECSS baseline, the acceptance programme follows completion of the applicable qualification programme.

ECSS requires acceptance testing on each flight product except the article used as Protoflight, subject to the contractually applicable and tailored project baseline.

Yes, through an approved protoflight strategy. The general ECSS approach uses qualification levels with acceptance durations, subject to the applicable tables and project requirements.

Yes. Tailoring should reflect project characteristics and risk. It must be controlled, justified and agreed by the appropriate customer authority.

Not automatically. Heritage must remain relevant to the current design, manufacture, interfaces, environment and intended use.

Not without an approved reason. Applying qualification severity to flight hardware can consume life or create unnecessary risk.

Typical evidence includes the approved specification, as-run procedure, achieved-condition data, functional results, inspections, anomaly records, Test Report and references used for verification close-out.

No. Resonate performs agreed testing and provides objective evidence. The customer or appointed project authority makes the qualification, acceptance and flight-readiness decision.

• To Follow

Authoritative source material is available from the ECSS official website and ECSS Standards Library.