Start with a 340-page PDF attachment, version 2.3 of the OBSW Interface Control Document, dated three months earlier. The subsystem engineer has one week to deliver a working parser and unit-test suite before the first software integration review. This is the manual baseline Spacebackend was built to replace, and the engineer's actual sequence follows.
Step One: APID Orientation and Inventory
Use the first hour to navigate the new ICD. Read its contents, locate sections covering the subsystem interface, and sketch the document structure. Most ICDs group material by subsystem or packet type, but neither scheme is universal. Relevant content must be found before extraction starts.
Find the APID allocation table, generally in an appendix. Extract subsystem APIDs and record packet types. A medium-complexity interface may contain 8 to 20 TC types and 5 to 15 TM types; a complex payload may contain 50 or more. First confirm that every assigned interface appears in the ICD and check for APID changes since the prior version.
Allow 30 minutes to 2 hours for orientation, depending on document quality and mission familiarity. The result is an APID processing list. Nothing executable yet.
Step Two: Field and Type Mapping
For every relevant APID, locate its packet structure table and copy out the field definitions. Read each row and convert it into the project's working representation: a Python dataclass, C struct, or intermediate schema, according to the available tooling.
Translation requires judgment, not simple copying. The same information may use different ICD conventions. Bit widths may appear as "Length (bits)", "Size [b]", "N bits", or an unlabeled number whose position implies length. Types may be written as "uint16", "UINT16", "unsigned 16-bit integer", "U16", or "integer" beside a size column. Enumerations may be inline, in an appendix, or referenced in another document.
Every translation choice is an interpretation. If the ICD states "temperature parameter, 0.01 K resolution, range 0 to 400 K" and the engineer assigns a 0.01 scale factor, the reading is correct. If it only says "mode word" without encoding details, the engineer must locate the enumeration table, compare the description section, and choose an interpretation. That choice can be wrong.
For a 15-APID interface, an experienced engineer spends a full working day on extraction. The result is a collection of struct or dataclass definitions reflecting the engineer's reading of the ICD, not a verified transcription.
Step Three: Building the Parser
Using the field definitions, the engineer writes packet parsers. A TC parser reads a byte buffer and extracts values; a serializer builds the correctly encoded buffer from those values. For TM, parsing is the primary direction.
With correct field definitions, parser coding follows a predictable series of bit shifts and masks. Experienced engineers move quickly, while less experienced ones make more mistakes, especially in offsets for fields crossing byte boundaries. Such non-aligned fields are common in CCSDS packets: the 11-bit APID begins 5 bits into the second header byte.
Implementation yields code that compiles and runs, but not necessarily correct code. Correctness requires accurate field definitions, hardware-matching encoding assumptions, and sound parser arithmetic. Any of these three may be wrong without a compile failure or runtime exception during tests.
Step Four: Building Test Cases
Unit tests use a known byte buffer, call the parser, and check field values against expected results. Serializer tests build a field object and compare its output with a known-good byte sequence.
Known-good byte sequences come from ICD examples when available, or from manual construction based on the field definitions. That construction has the same hazard as manual parsing: arithmetic at non-byte-aligned offsets is easy to miscalculate. Engineers often derive expected values with the parser's own logic, allowing one systematic bit error to enter both. Tests then pass even though the parser is wrong.
A sound parser test uses a known-good byte sequence from an independent source: an ICD example, hardware-test capture, or another engineer's construction. Without that source, correctness depends on one engineer getting the arithmetic right twice independently, a weaker safeguard than it seems.
Hidden Cost: Ambiguity Loops
Budgeting often omits the ambiguity cycle. During extraction and coding, the engineer may find conflicting or unclear ICD statements. A sequence counter is said to "increments per packet" in one section and "increments per telecommand" in another. An overview range differs from the detailed field table, or a field cites "Appendix D," absent from this ICD version.
Clarification requires contacting the ICD author, who may work for another organization, be the sole source of the answer, and have competing duties. A response can take one day to two weeks, depending on mission context. The engineer must either proceed on a potentially wrong assumption or wait and put the schedule at risk.
A medium-complexity ICD produces 3 to 8 ambiguity queries during careful extraction. Their combined delay consumes a significant share of the extraction schedule and is rarely included in estimates.
Spacebackend Automation
This workflow takes roughly one to two weeks of engineering time to produce a parser, serializer, and unit-test suite for a medium-complexity subsystem interface. Spacebackend reduces extraction and implementation to under an hour. Upload the ICD, extract a provisional field schema, review ambiguities beside source text, then generate the parser, serializer, and structural tests from the confirmed schema.
Ambiguity queries remain, but appear during schema review instead of mid-implementation. The reviewer sees the flagged field, source ICD text, and extracted value together, makes a decision, and proceeds. Each ambiguity is tied to its field rather than emerging as a test failure three days into coding.
Tests generated from the confirmed schema use the ICD's declared field values, not parser logic. This separates parser faults from test faults, removing the correlation that undermines manual tests. A check of a 12-bit field at bit offset 20 fails when the parser reads offset 19, even if one person wrote both.
Source ICD ambiguity remains unchanged. Poorly written ICDs require more review in Spacebackend and more manual implementation time. The tool speeds the structured work; ICD quality determines how much interpretation remains.
