Functional
Testing.

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.

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.

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

Need behaviour verified during testing?

Tell us your test sequence and your acceptance criteria — we’ll integrate functional verification into the right environmental campaign.