Qualification and Flight Readiness
Accredited
Scope Available
Programmes
Plus Certified
Expertise
Test Evidence
A protoflight strategy combines qualification and acceptance objectives on the first flight model. Instead of building a dedicated Qualification Model followed by a separate Flight Model, the Protoflight Model is exposed to an agreed campaign designed to demonstrate design robustness and confirm readiness for delivery and flight.
The approach can reduce model count, manufacturing effort and programme duration. However, it does not remove verification work. It concentrates that work, and its associated risk, in the flight article.
Under ECSS-E-ST-10-03C Rev.1, protoflight testing is performed on the first flight model. The activity provides evidence that the product performs to specification in its intended environments with defined qualification margins. It also confirms readiness for subsequent use and helps identify workmanship defects or flawed materials.
A credible protoflight strategy must therefore connect the model philosophy, Verification Plan, AIT Plan, test specifications, environmental conditions, functional checks, anomaly process and verification close-out.
This guide explains the benefits, limitations and practical controls programme managers and engineering teams should understand before choosing protoflight.
A protoflight strategy is an ECSS-recognised verification approach that combines qualification and acceptance testing objectives on the first flight model.
In a traditional model philosophy, a dedicated Qualification Model is used to demonstrate that the design can withstand its specified environments with qualification margins. Separate Flight Models then undergo acceptance testing to confirm performance and identify manufacturing or workmanship defects.
Under a protoflight approach, the first flight model performs both roles. The Protoflight Model is subjected to the agreed environmental and functional campaign and is subsequently intended for flight.
This can be attractive where:
hardware is expensive or difficult to manufacture;
only one flight article is planned;
programme schedules do not support a separate qualification build;
the product has suitable heritage;
production quantities are low;
interfaces and environmental requirements are sufficiently mature; or
the programme accepts the additional risk concentration.
The ECSS approach can be applied at different levels of the space-system decomposition. It does not prevent a project from using dedicated development or structural models where those models reduce risk. For example, an early Structural Model may be used to support mechanical qualification or model correlation before the Protoflight Model enters its formal campaign.
Protoflight should not be selected merely because it appears cheaper. The decision should follow a documented assessment of design maturity, hardware availability, heritage, residual life, test severity, schedule recovery options and the consequences of an anomaly on the flight article.
Removing a dedicated Qualification Model can reduce manufacturing, procurement, assembly and integration costs.
The saving can be significant for one-off spacecraft, payloads or complex equipment. However, it should be assessed against the cost of additional analysis, development models, test preparation and contingency planning. A single flight model is less expensive only if the programme can manage the risk attached to that model.
Fewer hardware builds can shorten the route through manufacturing, assembly, integration and testing.
This does not mean that planning can be compressed without consequence. Protoflight places greater importance on early requirements maturity, fixture readiness, instrumentation design, software stability, procedure approval and review closure.
The programme still has to demonstrate compliance with its applicable requirements.
Protoflight is not reduced-form qualification. It is a combined verification strategy. Qualification and acceptance objectives remain visible, and the evidence must support the relevant verification close-out.
The article intended for flight experiences the agreed environmental campaign. This provides direct evidence about that specific hardware configuration.
The advantage has a corresponding disadvantage. An anomaly, overstress event or configuration error affects the flight article itself. Recovery options may be restricted, and any repair or modification can trigger additional analysis, retesting or re-verification.
The commercial case is therefore balanced:
| Potential advantage | Corresponding risk |
|---|---|
| Lower model count | Greater dependence on one article |
| Reduced manufacturing cost | Less spare hardware for investigation |
| Shorter build programme | Reduced schedule recovery options |
| Direct evidence from flight hardware | Qualification exposure consumes flight-hardware life |
| Simplified configuration chain | An anomaly can affect qualification and delivery simultaneously |
A protoflight strategy is strongest when these trade-offs are explicit rather than hidden behind an assumed cost saving.
The qualification objective is to demonstrate that the product performs according to its specification in the intended environments with the required qualification margins.
This provides confidence in the design, its interfaces and its ability to withstand the applicable environmental conditions.
The acceptance objective applies to the flight product. It confirms agreed performance and supports the identification of workmanship defects, flawed materials or manufacturing problems.
Qualification of a design does not automatically prove the acceptability of each manufactured item. Acceptance activity addresses that gap.
Protoflight testing combines these objectives on the first flight model.
The approach therefore requires more than applying an environmental profile. The project must establish which qualification and acceptance objectives are being addressed, how the conditions satisfy those objectives and how the resulting evidence will support the Verification Control Document.
Test evidence contributes to verification reporting and requirement close-out. It should identify:
the requirement being verified;
the tested configuration;
the applicable test level and duration;
facility and instrumentation details;
measurement uncertainty;
functional and performance checks;
deviations and anomalies;
achieved conditions;
results and conclusions; and
any remaining verification activity.
Protoflight verification remains part of a structured programme derived from the project requirements, Verification Plan, model philosophy and AIT Plan. It should never be treated as an isolated laboratory booking.
The general ECSS protoflight approach is:
Test severity is generally selected using qualification levels.
These levels provide the defined margin used to demonstrate confidence in the design. The applicable value depends on the test, product level, mission environment and tailored project baseline.
Exposure duration is generally selected using acceptance durations.
This helps limit unnecessary consumption of flight-hardware life while still meeting the combined verification objectives.
In simple terms:
Qualification-style severity, combined with acceptance-style duration.
ECSS-E-ST-10-03C Rev.1 states that protoflight test levels and durations are specified in its equipment-level and element-level tables. It notes that the general approach is to use qualification levels and acceptance durations. The durations identified in those tables are minimum values.
This distinction is important. It is not safe to turn the general approach into one universal test recipe.
The actual campaign must be confirmed against:
the applicable ECSS test table;
product type and decomposition level;
project Verification Plan;
environmental specification;
launcher or customer requirements;
hardware operating modes;
model philosophy;
contractual requirements; and
approved tailoring.
For example, a project may apply a qualification-level random-vibration environment for an acceptance-style exposure duration. Thermal testing may use qualification temperature margins while controlling cycle count, plateaux, dwell, transitions and functional checks according to the agreed protoflight baseline.
The exact profile should be taken from controlled project documentation. It should not be reconstructed from a general website explanation.
A protoflight campaign can include environmental, functional and performance testing. The applicable baseline depends on the product, mission and tailored requirements.
Vibration testing provides evidence about launch survivability, structural integrity and functional performance under defined mechanical environments.
A protoflight vibration test may use qualification-level severity with the applicable protoflight duration. The fixture, control accelerometers, response channels, notching strategy, abort criteria and pre-test and post-test functional checks must be agreed before execution.
A poor fixture or unsuitable control strategy can invalidate evidence or expose flight hardware to unintended loads. Fixture and instrumentation readiness should therefore be treated as verification-critical activities.
Learn more about /vibration-testing/.
Thermal vacuum testing demonstrates operation or survival under controlled vacuum and temperature conditions relevant to the mission.
The protoflight specification should define pressure, temperature references, hot and cold limits, transitions, plateaux, cycle count, dwell, operating modes, functional checks, contamination controls and success criteria.
Thermal vacuum activity also consumes schedule and hardware life. The project should avoid adding cycles or extending exposure without a clear verification purpose.
Learn more about /thermal-vacuum-testing/.
EMC verification examines whether electrical and radio-frequency systems can operate without unacceptable electromagnetic interaction.
The applicable limits, modes, interfaces and configurations are defined by the project and specialist discipline requirements. EMC should be included in the overall verification strategy even where it is delivered by a separate specialist provider.
Resonate does not claim direct EMC capability on this page. Where EMC is required, the interfaces and sequencing should be identified early and coordinated with an appropriate provider.
Read /emc-testing/.
Shock testing addresses short-duration mechanical events associated with separation, release, deployment and other mission events.
The applicable shock environment, response spectrum, instrumentation, tolerances and test method must be defined. The programme must also consider whether direct testing, analysis, similarity or another verification method provides the most appropriate evidence.
Learn more about /shock-testing/.
Environmental activities should not be selected independently. The sequence can affect the evidence and the condition of the article entering later tests. Functional checks between exposures help identify when a change in behaviour first occurred.
Visit /environmental-testing/ for campaign-level guidance.
ECSS-E-ST-10-03C Rev.1 identifies specific equipment-level qualification tests that are performed on dedicated hardware and not on the Protoflight Model.
Life testing consumes operating life and can take hardware beyond the condition acceptable for flight.
Where life testing is required, it should be conducted on appropriate dedicated hardware that represents the function and design being verified.
Burst testing is destructive by purpose. It cannot be conducted on hardware intended for flight.
ECSS requires a representative model other than the Protoflight Model where destructive testing, such as burst testing, is needed. The model may be simplified, but it must fully represent the function being tested.
The equipment-level protoflight baseline identifies ESD qualification as an activity performed on a dedicated model rather than on the Protoflight Model.
This distinction protects the flight article from qualification activity that could impair its integrity or usable life.
These restrictions expose a wider principle: protoflight does not mean every verification activity is performed on one article. The programme can still need dedicated models, samples, coupons, representative assemblies or supporting analysis.
The model philosophy should identify these needs before the Protoflight Model enters formal testing.
The project establishes the verification requirements, methods, levels, stages and model philosophy.
The protoflight decision should be justified against mission risk, heritage, design maturity, schedule, cost and hardware availability. Applicable ECSS requirements and project-specific tailoring should be recorded.
See /verification-planning/.
The AIT Plan connects the verification strategy to assembly, integration, testing, facilities, ground support equipment, responsibilities, reviews and schedule.
It should show how the Protoflight Model will move through the campaign and how configuration status will be maintained.
Development tests, analysis, structural models or representative hardware may be used before the formal protoflight campaign.
This activity should reduce uncertainty. It should not be used to conceal an immature design or replace required qualification evidence without customer approval.
A controlled baseline is established before environmental exposure.
The project confirms hardware configuration, software version, interfaces, modes, performance and instrumentation. This baseline provides a reference for later comparison.
The Test Readiness Review determines whether the article, facility, documentation, people and support equipment are ready.
Open actions should have owners and closure dates. The review should conclude with a clear decision to proceed or not proceed.
See /test-readiness-reviews/.
The agreed mechanical, thermal, electrical and other environmental activities are executed in their approved sequence.
Controlled functional checks are completed at the specified points. Deviations and anomalies enter the appropriate project process.
Final functional and performance checks confirm the condition of the article after environmental exposure.
The project evaluates results, deviations, anomalies and any effect on requirement closure or residual life.
Test reports and verification reports record the evidence and conclusions.
The customer or appointed project authority decides whether the relevant requirements can be closed and whether the article can progress towards delivery and flight.
Protoflight evidence depends on controlled documentation.
| Document | Role in the programme |
|---|---|
| Verification Plan | Defines the verification strategy, methods, levels, stages and model philosophy. |
| Verification Control Document | Records the status and close-out evidence for applicable requirements. |
| AIT Plan | Describes the assembly, integration and test programme, facilities, organisation, reviews and schedule. |
| Test Specification | Defines the test purpose, article, configuration, conditions, tolerances, instrumentation, uncertainty, sequence and acceptance criteria. |
| Test Procedure | Provides controlled step-by-step execution and becomes the as-run record. |
| Test Report | Records execution, achieved conditions, results, deviations, anomalies and conclusions. |
| Verification Report | Brings the evidence together to support verification close-out. |
The Test Specification should define what the activity must achieve. The Test Procedure should define how the approved activity will be executed.For simple activities, the project may agree to combine elements of these documents. The content and control still need to meet the applicable requirements.Procedure variations, anomalies and unexpected results must remain visible. They should not be edited out of the record after testing.
A protoflight approach can reduce build time but also removes some recovery options.
If the Protoflight Model is damaged, requires modification or produces ambiguous evidence, qualification and flight-delivery schedules may be affected simultaneously.
Qualification-level environments provide evidence of design robustness.
However, exposing the first flight model to these conditions means design maturity should be established before formal entry into the campaign. Development testing and analysis may be needed to reduce uncertainty first.
Reduced model count can lower hardware expenditure.
The saving can be offset by late redesign, retesting, repair, additional analysis or delayed launch access if the original programme was underprepared.
Environmental exposure, mechanism operation, pressure cycles, thermal cycles and functional testing can consume hardware life.
The programme should understand life limits and maintain a record of the exposure experienced by the article.
Ground testing helps reveal design, interface, material and workmanship problems before launch.
It cannot prove that no mission failure will occur. Confidence comes from combining testing with analysis, inspection, review of design, configuration control and disciplined anomaly management.
The protoflight decision should therefore be a verification strategy, not merely a cost-reduction exercise.
These FAQs explain the purpose, benefits and risks of an ECSS protoflight strategy.
Every programme is different. If you need clarification, or your project follows another verification route, please contact us. We welcome feedback and are happy to discuss the practical test implications.
What is a Protoflight Model?
A Protoflight Model is the first flight model used to address both qualification and acceptance testing objectives. The model is subjected to an agreed test programme intended to demonstrate that the design performs according to specification with the applicable qualification margins. The programme also confirms readiness for delivery and subsequent use and helps identify workmanship defects or flawed materials. The Protoflight Model is intended for flight after successful completion of the required activity and project reviews. This makes configuration control, residual-life management and anomaly handling particularly important.
Why would a programme choose a protoflight strategy?
A programme may choose protoflight to reduce model count, manufacturing cost, integration effort or overall schedule. It can be appropriate where only one flight article is planned, hardware is expensive, suitable heritage exists or building a separate Qualification Model would be disproportionate. However, protoflight is not automatically the cheaper or faster option. It concentrates qualification exposure and programme dependence in the first flight article. The decision should consider design maturity, heritage, residual life, development evidence, test severity, schedule recovery options and the consequences of an anomaly or repair.
Is a Test Readiness Review especially important for protoflight?
Yes.
A Test Readiness Review is critical because the test article is intended for flight. Errors in configuration, fixtures, instrumentation, software, procedures or test profiles can directly affect flight hardware.
The review should confirm:
The review should not approve testing while critical assumptions remain unresolved.
Is protoflight testing the same as qualification testing?
No. Qualification testing focuses on demonstrating design robustness with defined qualification margins. Acceptance testing focuses on the flight item and helps identify workmanship, material or manufacturing problems. Protoflight combines these objectives on the first flight model. The resulting campaign must address both design confidence and flight-item assurance. Calling a test “protoflight” does not itself achieve that. The levels, durations, sequence, functional checks, documentation and evidence must reflect the approved protoflight strategy.
Is protoflight always lower risk than using separate qualification and flight models?
No.
Protoflight can reduce cost and schedule, but it increases dependence on one article. If that article is damaged, modified or produces ambiguous evidence, the qualification and flight-delivery routes may both be affected.
A separate Qualification Model can provide more freedom to expose, investigate, modify or retest hardware without placing the flight article at the same level of risk.
The correct model philosophy depends on programme economics, design maturity, hardware availability, mission consequence, heritage and recovery options.
Protoflight is a risk trade-off, not a universally superior strategy.
What is the main ECSS rule for protoflight test levels and durations?
The general ECSS approach is:
This balances design confidence against the need to protect flight-hardware life. However, it is a general approach rather than a universal profile. ECSS-E-ST-10-03C Rev.1 directs projects to the applicable equipment-level and element-level tables. It also identifies the listed durations as minimum values. The controlled project specification, applicable test table, product level, mission environment and approved tailoring remain decisive.
Does qualification level mean every protoflight test uses maximum severity?
No. Qualification level means the agreed test severity includes the qualification margin required by the applicable baseline. It does not mean that the laboratory should select the highest available equipment setting or the harshest value found in any reference. The correct level should be derived from the project environment, product level, customer requirements, applicable ECSS provisions and approved tailoring. Excessive severity can damage flight hardware or consume unnecessary life. Insufficient severity may fail to demonstrate the required design confidence. Both outcomes represent poor verification planning.
Can a project still use other models when following a protoflight strategy?
Yes. Protoflight does not require every development, qualification or investigation activity to be performed on one flight article. A programme may use:
ECSS specifically recognises that dedicated models may be used to reduce risk. An early Structural Model, for example, may support mechanical qualification or correlation before the Protoflight Model enters formal testing.
Which tests should not be performed on the Protoflight Model?
For the ECSS equipment-level protoflight baseline, the following qualification activities are performed on dedicated models and not on the Protoflight Model:
Burst testing is destructive and therefore requires representative hardware other than the flight article. Life testing can consume an unacceptable proportion of operating life. ESD qualification can expose the article to risks unsuitable for flight hardware. The project should confirm all exclusions and dedicated-model requirements against its applicable product level, test baseline and specialist standards.
What environmental tests may form part of a protoflight campaign?
Depending on the product and project requirements, a protoflight campaign may include:
Not every test applies to every product. Applicability depends on the product type, decomposition level, intended environment, interfaces, launcher, operating modes and tailored requirement set. The test sequence should also be controlled because earlier exposures can affect the condition of the article entering later tests.
How does protoflight testing affect flight-hardware life?
Protoflight activity exposes the flight article to qualification-level environmental severity while using the applicable protoflight durations. Thermal cycles, pressure cycles, vibration exposure, mechanism operations and powered functional testing can all consume part of the hardware’s available life. The programme should identify life-limited items, record accumulated exposure and consider the effect of any additional testing or retesting. A decision to extend a dwell, repeat an axis or add a cycle should not be made casually. It should consider the verification need, residual-life effect and customer authority.
What happens if an anomaly occurs during protoflight testing?
The test should be paused or controlled in accordance with the approved procedure, abort criteria and project anomaly process. The project should protect the article, preserve data and record:
The anomaly should then be investigated through the appropriate project process.
What documentation controls a protoflight campaign?
A controlled protoflight campaign normally draws on:
The documentation should identify both qualification and acceptance objectives. It should also make the article configuration, applicable levels, durations, functional checks, acceptance criteria, achieved conditions and verification conclusions traceable.
Can a protoflight article be retested?
Potentially, but retesting should not be automatic. The need and extent of retesting depend on the reason, the exposure already experienced, the affected requirement, the product configuration and the customer’s decision. Retesting may follow:
The project must consider residual life and possible cumulative overstress. A repeated test may generate the missing evidence, but it may also increase risk to the flight article.
Does successful protoflight testing prove that the spacecraft is ready to launch?
Not by itself. Protoflight test evidence is one part of the project’s wider verification and readiness process. Launch readiness may also depend on analysis, inspections, design reviews, software verification, interface checks, safety evidence, product assurance, configuration status, launcher requirements and closure of anomalies or waivers. The laboratory provides evidence from the agreed test activity. The customer, design authority or appointed project body decides whether requirements can be closed and whether the product may progress towards delivery or launch.
How can Resonate Testing support a protoflight programme?
Subject to technical review, Resonate can support the practical planning and delivery of vibration, shock, SRS and thermal vacuum activity within a wider protoflight campaign. Support can include:
Resonate does not replace the customer’s verification authority, approve the model philosophy or declare flight readiness. Your Test Facilitator. Not simply a test facility.
What should I send Resonate before discussing a protoflight campaign?
Send the current controlled information, including:
Early review is particularly valuable for protoflight because unresolved interfaces can affect both qualification evidence and the flight article.
Each test activity should connect to an applicable requirement and an agreed verification objective.
Traceability allows reviewers to move from the requirement to the approved specification, as-run procedure, data, result and verification conclusion.
Documented configurations, software versions, set-ups, conditions, steps and deviations allow the project to understand what was actually tested.
Repeatability does not always mean repeating the test. It means maintaining enough information to reproduce or evaluate the activity if needed.
Suitable instrumentation, calibration, data acquisition, test tolerances and measurement uncertainty improve confidence in the results.
More data are not automatically better evidence. The data must be relevant to the verification decision.
Compliance is supported by objective evidence against the applicable project requirement.
The laboratory produces test evidence. The customer or appointed verification authority retains responsibility for requirement closure, qualification acceptance and flight-readiness decisions.
Resonate Testing helps customers translate applicable environmental test requirements into practical, controlled activity.
We can review customer-supplied requirements, environmental profiles, model information, hardware configuration, schedule and expected evidence before quotation.
This helps identify missing inputs, facility interfaces and potential constraints before they affect the test window.
Resonate can support the practical development of vibration, shock and thermal vacuum activities that form part of a wider protoflight campaign.
The scope is agreed against facility capability, safety, instrumentation, fixtures, hardware interfaces and customer-controlled requirements.
The purpose is not to maximise the number of tests. It is to help customers define activity that produces relevant evidence without unnecessary exposure of flight hardware.
This includes challenging unclear profiles, incomplete acceptance criteria, unrealistic sequences or evidence expectations that have not been agreed.
Resonate can review and contribute to the test-specific information needed for facility planning, Test Specifications, procedures and reports within the agreed scope.
The customer retains control of its Verification Plan, model philosophy, AIT Plan, Verification Control Document and final qualification decisions unless a different responsibility is formally agreed.
Agreed testing can generate controlled data, observations, achieved-condition records and test reports.
Outputs should be agreed before testing so that the evidence supports the intended customer review and verification activity.
Vibration, shock and thermal vacuum activity can be coordinated through one engineering team where the requirements and capability are suitable.
EMC and any other activity outside confirmed Resonate capability should be coordinated with an appropriate specialist provider.
Your Test Facilitator. Not simply a test facility.
The specimen is weighed and conditioned in accordance with the approved method. Balance accuracy, environmental conditions and handling controls are important because the measured mass changes can be small.
The sample is exposed to the prescribed vacuum and temperature conditions. Volatile species released by the sample can be collected on a temperature-controlled collector.
The sample and collector are reweighed under controlled conditions. TML, RML and CVCM values are calculated as required by the method.
Results should be checked against:
Applicable limits.
Material identity.
Sample preparation.
Test validity.
Repeatability.
Measurement uncertainty.
Customer requirements.
Intended use.
The report or certificate should provide enough information to link the result to the exact material, batch, preparation and test configuration.
A protoflight strategy can reduce model count and programme duration, but it transfers more verification responsibility and risk to the first flight article.
Before facility booking, establish the applicable requirements, model philosophy, qualification margins, test durations, sequence, functional checks, acceptance criteria, anomaly process and evidence needed for verification close-out.
Bring Resonate Testing your controlled specification, hardware information, environmental profiles, fixture assumptions, instrumentation needs and programme schedule. We can review the practical test route and identify facility or readiness issues before the campaign begins.
Whether you’re looking to contact us for the first time or have another testing requirement, we’d love to hear from you.
