MAY 27/Integration & Testing/4 MIN READ

Stop Authoring ICDs. Generate Them From Code

Dan Zaidenband

Share on

Every satellite program has at least one ICD that nobody on the team can swear matches the firmware. The question worth asking is not which one. It is why, when this happens on every program, the industry's answer is still to write more ICDs, more carefully, in better templates.

A typical smallsat program carries somewhere between 80 and 300 interface control documents. Some live in Word, some in Excel, some in PDFs that started as Word, some in Confluence pages whose author left two companies ago. The format doesn't matter. What matters is that the document is a description of an interface that exists somewhere else: in firmware, in pinouts on a connector, in voltages on a wire. The document is downstream of those things. When the upstream changes, the document does not change with it, unless someone remembers to open the file and re-export.

Two vendors agree on a CAN message in a Tuesday kickoff. They both leave with a copy of the spreadsheet. The avionics team updates the firmware to send the temperature field as little-endian. The thermal team writes their parser for big-endian. Both teams checked the document. Both teams shipped. Integration finds the swap nine months later.

The document was never the source of truth

Treating the description as the agreement is the original sin of ICD management. Every ICD problem we've seen on programs we've worked on traces back to it. The signed PDF holds a snapshot of an agreement reached at one point in time. The agreement itself lives in the running system, and the running system moves on. When somebody catches the gap at integration, somebody else is already rewriting a parser at 2am.

Documents drift; code does not

There are two reasons documents drift away from the systems they describe.

The first is that documents are copied. The version in Confluence, the version in the supplier portal, the version attached to the RFP, the version pasted into the kickoff slide deck, all of these are forks the moment they exist. Each one ages independently. Nobody notices until two of them are compared.

The second is that documents are not run. Code that defines an interface gets executed every test cycle, every CI run, every flight rehearsal. If the message definition changes and the parser does not, the test breaks. The drift is loud. With a document, the drift is silent until a human opens the file, and humans open the file infrequently and selectively, usually after something has already gone wrong.

This is not a critique of the engineers maintaining the documents. It is a critique of the workflow that asks them to keep the actual interface in code and a separate description of it in a Word file, and trusts them to keep both in sync across years and turnover. That bet loses on long enough timelines, which is all timelines.

Generate the document, do not author it

The fix is structural. The interface lives in code: a message schema, a struct definition, a protocol buffer, an XTCE telemetry definition, an AUTOSAR ARXML module, an ASN.1 spec, whatever serves the domain. The schema sits in the same repository as the firmware that implements it. It is reviewed in the same pull requests, versioned with the same tags, and signed off by the same people who sign off on the code change. The ICD as a document, the test harness, the simulator stub, and the procurement appendix are all generated from that one schema.

This is how the rest of software has worked for fifteen years. OpenAPI specs drive REST. Protocol buffers drive Google's RPC layer. GraphQL schemas drive frontends across the consumer internet. The web industry stopped writing API documents and started generating them somewhere around 2014. Automotive uses DBC and FIBEX as authoritative for ECU networks. The aerospace standards exist already; CCSDS XTCE was designed for exactly this on telemetry and command. Most programs treat XTCE as a delivery format rather than a source format, which is half the answer at twice the work.

The pattern is not new, and it is not even ours. What's new is aerospace adopting it on programs that are flying now.

The ICD is what falls out of the code, not what shapes it.

What changes in practice

Three things shift once the schema is the source of truth.

Procurement gets cleaner. The contract appendix becomes a generated artifact with a known checksum. When the schema updates, the procurement document updates with it, and both parties can audit the diff. The signed PDF becomes a snapshot of a version, not an authoritative document the code is expected to chase.

Vendor exchange changes shape. Instead of mailing a spreadsheet and hoping the other team interprets the byte order correctly, vendors exchange schema files. The schemas drive both sides' parsers. Disagreement about endianness, scale factor, or units shows up as a build error on day one, not as a thermal anomaly on day two hundred.

Integration testing collapses inward. The simulator reads the same schema the flight software does. The test harness reads it too. When a developer edits the schema, the simulator stub regenerates, the test fails, the build flags it. The discovery loop drops from months to minutes. Software-in-the-loop simulation becomes daily practice instead of a milestone gate, because it shares the same source of truth as the flight code.

The document still has a place

We are not arguing against the document. Auditors need it. Lawyers need it. Customers need a thing to sign, and heritage programs that have been audited a thousand times need a paper trail that looks like what they have always reviewed.

What we're arguing against is the document being authored. The document should be generated, signed, archived, and treated as a snapshot. If the underlying schema changes, a new document is generated, the diff is reviewed for what changed, and the new version is signed. The flow of authority runs from the schema to the document, not the other way around.

The PDF will outlive us all. It belongs in the audit folder, in the legal binder, on the SharePoint that nobody opens. It does not belong at the head of an integration pipeline, where every minute it spends being wrong costs another minute in the high bay.

Share on

More from the blog