The six-week integration test preparation cycle is not an engineer-speed issue. It is a handoff issue: the ICD arrives, the subsystem engineer studies it, then spends several weeks manually converting packet field definitions into test code. Hardware availability often does not determine the duration. Translation work is the bottleneck, and it occurs before any test runs.
Where the Time Goes
Before writing the first unit test for a new ICD, a subsystem engineer usually completes four tasks. First, they study the packet field tables for types, bit widths, offsets, and valid ranges. Second, they write or update packet encoder and decoder classes based on those definitions. Third, they create stubs covering each field at nominal, minimum, and maximum values. Fourth, they confirm that encoder output round-trips through the decoder.
For one packet type containing 12 to 20 fields, steps two through four require two to four days for an experienced engineer familiar with the codebase. A subsystem ICD covering 30 to 50 packet types expands that effort to five to ten weeks. A two-engineer software team on a 12-month delivery schedule cannot absorb that work without making it the critical path.
ICD churn adds further delay. If field offsets move or fields are added in an update, manually written encoder and test classes must be reviewed and changed. Handwritten code provides no dependable automated diff between ICD version N and version N+1. Engineers must reread the document, mentally compare it with their code, and hope no change was missed.
What Generated Test Stubs Provide
Processing an ICD through Spacebackend produces packet class code plus a test stub for every packet type. Each stub includes assertions derived from the ICD field definitions: minimum-value encoding must round-trip, maximum-value encoding must round-trip, values above the maximum must either raise an exception or be clamped as the ICD specifies, and a nominal encoding must round-trip using the ICD-defined defaults.
Consider a housekeeping telemetry packet whose solar array current field is a 16-bit unsigned integer ranging from 0 to 65535, with a scale factor of 0.001 A per LSB. The generated stub asserts the encoded byte pattern for raw values of 0 and 65535, plus a mid-range nominal value. It also checks that decoding reproduces the original value within floating-point tolerance after applying the scale factor. Writing four assertions by hand is easy. Repeating that work for 40 fields across 35 packet types is the five-week task the generator replaces.
Before Hardware Is Ready
Early generated stubs let verification begin before flight hardware is assigned to the software team. Hardware-in-the-loop testing needs the flight unit, test bench, and communication interface simultaneously, a window that is often narrow and late in the schedule. Software-only fixtures can verify packet encoding, field boundary behavior, and decoder fidelity. Hardware is not needed for those checks.
During early access, a team working on an attitude and orbit control system (AOCS) ICD with 28 TM packet types ran our generator and reported executable stubs for all 28 within a day of uploading the ICD. Its previous process took three to four weeks to reach equivalent coverage from a new ICD revision. The cited figure was 23 working days reduced to approximately 1.5 days for stub generation. This is one data point from an early-access program, not a general benchmark.
What Generated Stubs Do Not Replace
Generated stubs confirm that generated code matches the ICD, not that the ICD itself is correct. If the document gives a wrong field offset, the encoder will implement it faithfully, and the stub will show that the incorrect encoder is self-consistent. That is not a defect in generation. It is a characteristic of tests whose assertions and code under test come from the same source.
Tests for interface defects between subsystems require real communication flow. An isolated generated stub on a laptop will not expose a timing dependency, a buffer alignment assumption that works on the development host but fails on the target processor, or differing ICD interpretations between subsystem teams. Such tests need hardware in the loop and must run there. Generated stubs make the route to that stage shorter, not the stage itself.
Generated stubs should be viewed as covering work once handled by manual encoding tests. They free engineers to use hardware-in-the-loop time on interface defects that require integration, rather than confirming that a field encoder correctly implements its own field definition.
ICD Version Tracking
Tying code generation to ICD document versions partly addresses churn. After a new revision is uploaded, the generator compares the field-definition IR from the old and new versions. Changed, added, and removed fields are annotated, while code and stubs for changed fields are regenerated. Engineers review that diff instead of rereading the entire document.
"Partially addressed" is deliberate. The diff captures structural changes visible in the field table, but not prose changes in footnotes or free-text remarks that alter field interpretation without changing table structure. Those changes still need human review. The generator cannot infer intent from prose.
