ICDs typically contain 95% of required specifications. The missing 5% causes extensive project delays. Documentation frequently omits error-handling procedures, timing restrictions, command sequences and behavioural logic.
This can lead to late-stage failures. Here we take a detailed look at the ambiguities inside an ICD, why engineers’ differing interpretations can lead to disaster, and how AI document analysis can help.
Ambiguities that produce conflicting interpretations
Broadly speaking, an ICD can be ambiguous in two ways:
It may be missing important information, or
the information it provides can be interpreted in more than one way.
We’ve spoken to a lot of flight software leads and AIT engineers in our network about the types of ambiguities they often see in ICDs. Here are six of the most common examples:
Undefined states
A component may enter a state that the ICD doesn’t describe, leaving engineers unsure how it should behave. For example, the interval during a reboot or after receiving only part of a command. Software built to handle only the states listed in the ICD has no defined behaviour for these situations.
Conflicting requirements
Two sections of an ICD, or an ICD and its datasheet, may specify different values for the same parameter. The engineer must either pick one or go back to the supplier for clarification.
Picking one means taking a gamble, as nothing flags a wrong choice until the driver runs against the hardware. The fix would only come late in the project schedule. Going back to the supplier avoids that risk but stalls the work while waiting for an answer. Either way, significant time is lost.
Multiple interpretations of command timing
A requirement such as “send within 10 ms” leaves the starting point open. It could be measured from the end of the previous response, from the start of the previous command, or from a bus event. As a result, each reading ends up producing a result that behaves differently.
Undefined behaviour during failures
ICDs tend not to give enough information around failure behaviour, like power loss in the middle of a command or a fault on the bus. These are the cases where flight software really needs a specified response.
Unclear ownership between subsystems
When the text doesn’t say which subsystem commands a reset or handles a recovery, both teams may conclude that the other one does it. The recovery then never gets implemented.
Missing assumptions about operational context
A document written for bench testing may assume conditions that do not represent conditions in orbit or space. If the intended context is not stated, an engineer can’t say with certainty which parts of the ICD apply correctly to the mission.
ICD problems are semantic
Many ICD problems are semantic issues (system behaviour, operational state transitions, etc.) rather than syntax problems (data formatting, bit lengths, etc.).
Standard software tools are built to check syntax. They can confirm that a field exists and has a valid type. They can’t tell you what a subsystem does when that field arrives during a fault or who is responsible for the recovery. This is one reason ambiguous ICDs can lead to failures late in the integration process.
If an edge case isn’t defined in the ICD, two separate engineering teams will fill in the blank in two completely different ways. Each version looks reasonable on its own, and the conflict only appears when the systems are connected.
But by that point, the cost is high. Engineers spend days or even weeks debugging during hardware-in-the-loop testing. The cause is ambiguity in the documentation that should have been caught right away.
How Lynapse Studio handles ambiguous ICDs
Lynapse Studio is built to catch these semantic ambiguities during the design phase. It runs an AI analysis on imported ICDs before any code or configuration is written, flagging any missing parameters, timing gaps, conflicting data, or undefined behaviours. As a result, engineers don’t need to waste time cross-referencing documents manually to look for ambiguities.
When an engineer resolves an ambiguity inside Lynapse, the choice updates the underlying digital model. Lynapse then automatically recompiles both the flight software driver and the Software-in-the-Loop (SiL) from that single, verified source of truth.
Fix the ICD before you write the code. Book a technical demo with our team to see how Lynapse analyses an ICD before implementation begins.
