During Q1 2026, we added three new ICD input formats. By June's end, we had rebuilt the parser's table-detection layer and released the first ECSS-E-ST-70-41C compliance hint pass. This post details the changes, our tradeoffs, and a lesson that led to two weeks of rework before the pass was ready for early-access users.
Added ICD Input Types
At private beta launch, we supported two inputs: PDFs with embedded tables and Excel workbooks. They covered most ICDs from small spacecraft teams, but early-access users soon sent XML exports from model-based systems engineering (MBSE) tools, a case we had not fully anticipated.
XML exports use varied schemas. Some follow conventions derived from ECSS-E-ST-10-25A System Modelling Language profiles, while others come through proprietary pipelines in commercial MBSE environments. In Q1, we added structured XML parsing, initially for two common export profiles. We route these formats into the same field-definition intermediate representation (IR) used for PDF and Excel. As a result, downstream code-generation modules and test-stub generators gained XML support without separate format-specific paths.
We also rebuilt Excel table detection. Previously, the parser needed a clean header in the first non-empty row of the target sheet. That broke on ICDs with a document-title row, project-code block, or change-history section ahead of the field table. The new scanner searches downward for the first row matching a recognized header pattern: field-name, data-type, and bit-width columns, plus at least one of byte-offset or bit-offset. Header qualification remains deliberately strict, preventing free-form notes from being ingested as field data.
Parser Speed: Before and After
Before the Q1 refactor, a 40-page PDF ICD took 18 to 35 seconds to parse, depending on table density. That worked during private beta, when users uploaded one ICD at a time. In Q2, batch uploads for complete subsystem interface sets pushed latency to several minutes per batch. We parallelized table extraction across pages, bringing median parsing for a 40-page ICD down to approximately 6 seconds on the same server configuration.
Here, "parse time" runs from file upload to a validated field-definition IR, excluding end-to-end code generation. Code generation is under one second for a typical ICD. Parsing and field extraction account for the heavy work.
ECSS-E-ST-70-41C Compliance Hints
ECSS-E-ST-70-41C, the ECSS Packet Utilisation Standard (PUS), specifies service types, packet structures, and field conventions for mission telemetry and telecommand within the ECSS standards family. Our hint pass examines extracted field definitions for possible deviations from PUS conventions, including wrong service-type widths, absent acknowledgement-flag fields in TC packets, packet data lengths that omit PUS header overhead, and application process identifier (APID) positions outside expected locations.
We learned the hard way that compliance hints are not validation results. Early versions looked authoritative, and one early-access user treated a hint as a confirmed ICD compliance failure. It was not. A hint means that a field pattern differs from the PUS convention we recognize and needs review. The ICD used a non-standard field-naming convention that was valid for its mission but triggered our checks. We spent two weeks adding confidence levels, explanatory context, and a prominent heading to every hint.
Hint Scope and Limitations
Hints compare structural patterns with PUS service definitions, including service-type and subservice-type positions in TC application data, source-APID and destination-APID fields, and packet error control (PEC) presence and placement. They do not assess mission-specific parameter ranges, operational constraints, or the data's semantic correctness.
More importantly, the pass is not a formal ECSS compliance assessment for any mission. That requires checking the ICD against all normative content in ECSS-E-ST-70-41C, the applicable mission ECSS tailoring document, and interface agreements with the launch service provider and mission operations center. Our pass is a quick screen for obvious structural deviations, not a replacement for that review. We built it to reduce the first review cycle, not eliminate it.
Plans for H2 2026
Two efforts are underway: C output for MIL-STD-1553 message descriptors and an initial CLI integration. The CLI will allow ICD parsing and code generation within a continuous integration pipeline instead of the web interface. Teams requested this to connect generation with repository ICD version tags, so document changes automatically rerun the generation pass and flag output diff lines.
We are also developing a requirements traceability matrix export linking generated code to specific ICD field-table rows through field identifiers. Some ICDs lack stable identifiers, identifying a field only by its row number and document header text rather than an explicit ID field. We must create stable synthetic identifiers and an auditable provenance chain, allowing engineers to verify each traceability link without blindly trusting tool output. That auditability is the difficult part, so we will not ship until it is correct.
Early-access teams can request an ECSS-E-ST-70-41C hint-pass run against their own ICD before general availability by writing to [email protected]. We perform manual review passes for early-access programs on request.
