Hardware that survives a test still needs to work afterward. Subsystem-level functional verification under controlled conditions — checking behaviour, not just structural integrity.
Functional verification runs during environmental testing — your hardware is exercised at hot, cold, and ambient dwells, not just powered on after the test.
What we run
Survival isn't enough.
Behaviour is.
A unit can pass a vibration test mechanically and still fail to boot. Functional testing during environmental exposure is how you catch this — before launch, not after.
Principle 01
Test during dwell
Functional checks executed at hot and cold dwells — not just at ambient before and after. Catches temperature-dependent failures that would otherwise be invisible.
Principle 02
Real interfaces
Hardware exercised through its actual flight interfaces — power profile, command sequence, telemetry. Not a synthetic test mode that bypasses real-world behaviour.
Principle 03
Anomaly tracking
Every off-nominal observation is logged with timestamp and conditions. The test report includes anomaly history — not just pass / fail.
What this looks like
Customer-defined scope.
Engineer-led execution.
Functional testing has no fixed standard — by design. Scope is defined per your subsystem and your acceptance criteria. We bring the lab discipline; you bring the test sequence.
Frequency range (RE)
10 kHz – 18 GHz
(planned)
Frequency range (CE)
30 Hz – 100 MHz
Susceptibility levels
per mission profile
Hardware footprint
CubeSat 1U → 16U
Reference standards
ECSS-E-ST-20-07 · MIL-STD-461
Status
2026 — early alignment
Related services
Functional sits inside.
Functional testing is paired with environmental testing — never standalone. These are the campaigns it most often runs inside.