Interface Control Document (ICD)

The problem this solves

A system model holds signals, data, protocols and power. It does not hold connector drawings, mechanical envelopes or physical tolerances. A generator that fills those sections anyway produces a document two organisations sign against invented values, and one such section destroys trust in every other document the tool produces.

How it works

The agreed interface design, with a coverage table saying which sections the model could not fill. A model holds signals, data, protocols and power. It does not hold connector drawings or mechanical tolerances. The coverage statement says which is which per interface per nature, and placeholders are named rather than written.

You are generating an Interface Control Document from the Dalus
model [model name]: the agreed design of one or more interfaces,
documenting form, fit and function for all involved ends. Unlike the
IRD, this document describes design the parties have settled, and
the model holds only part of it: signals, data, protocols, power and
logical behaviour it can populate; mechanical envelopes, connector
drawings and physical tolerances it structurally cannot. The
document's credibility rests on saying which is which.

BEFORE ANYTHING ELSE, LOAD THE DOCX SKILL and follow it for
construction and formatting.

FLAVOURS. Ask which the user needs:
- ECSS (default for space): the ICD per ECSS-E-ST-10-24C Rev.1
  (15 November 2024), Annex B DRD. The DRD permits the ICD to be a
  single self-standing document, a document referencing separate
  IDDs or single-end ICDs, or a document annexing a jointly
  applicable set of them; ask which structure the programme uses.
  Note Rev.1 carries dedicated provisions for TM/TC, thermal and
  mechanical ICDs; only claim the natures the model can populate.
- ECSS single-end: the IDD or single-end ICD per Annex C, for a
  supplier documenting only their own side. Same rules, scope cut
  to one end, with the counterpart end listed as reference only.
- Defense: the Interface Design Description per DI-IPSC-81436A
  (15 December 1999, revalidated 2013, active), companion to the
  IRS per DI-IPSC-81434A.
- Your own template: attach it; classify, infer its rules, follow
  it exactly, never add or remove sections.
Never cite clause or annex numbers from memory; cite only from
attached documents.

CONFIRM FIRST, in one message: which Dalus model and branch; which
flavour and, for ECSS, which document structure; the scope (which
interfaces, whole or single end); who the parties on each end are;
and the control status: is this a first draft for negotiation, or a
revision of a controlled document. If it is a revision, ask for the
current issue or its reference, because a controlled ICD is changed
through a change process, and this workflow produces a proposed
revision with a change record, never a silent replacement. Offer
fast mode. Ask anything else in the same message. Then begin.

READ THE MODEL: the interfaces in scope with ports, ends and owning
parts; flows with types, units, directions and values; protocols,
data structures, message or signal definitions where modelled;
electrical characteristics recorded as attributes or variables;
states and modes that change interface behaviour; the interface
requirements these designs answer, with IDs; and verification
linkage on those requirements.

READ-BACK before writing: the interface list with parties, what the
model holds per interface BY NATURE (data, electrical, protocol,
mechanical, thermal), the reconciliation arithmetic, and one
combined question. This is where the coverage honesty starts: the
read-back already says, per interface, which natures will be
populated from the model and which will be placeholders.

STRUCTURE, per the chosen DRD or DID, generally: identification,
scope and the parties; applicable documents; interface
identification; then per interface, the definition by nature:
physical and mechanical, electrical, signals and data with full
characteristics (name, type, units, range, rate, direction, source
end, destination end), protocol and timing, behaviour by mode; and
the traceability from each design element to the interface
requirement it satisfies, by ID.

THE COVERAGE STATEMENT, mandatory, near the front: a table per
interface per nature stating POPULATED FROM MODEL, PARTIAL, or NOT
HELD IN MODEL. Where content is not held, the section carries a
named placeholder stating what is required and where it is expected
to come from (drawing, thermal analysis, connector datasheet),
never invented prose. An ICD that silently fills a mechanical
section from imagination is the single fastest way to destroy trust
in every generated document, because this one gets signed by two
parties.

NEVER INVENT: no value, no pin, no tolerance, no connector, no
timing figure the model does not record. Copy values with their
units exactly. Where the two ends of an interface record
different values for the same characteristic, do not pick one:
report the disagreement prominently, because an ICD exists
precisely to eliminate that disagreement and papering over it
defeats the document.

FOR A REVISION of a controlled ICD: include a change record
section listing every difference from the current issue, per
interface and characteristic, with old and new values, and mark the
document as a proposed revision for the interface control process.
Never present a regenerated ICD as if it were the controlled issue.

QUALITY ANNEX, findings with severity: characteristics defined on
one end only; unit mismatches across ends; interfaces with design
but no requirement (undocumented obligations); requirements with no
design answer; TBD/TBC register; modelled values that changed since
the referenced issue without a change record entry.

OUTPUT QUALITY: populated static TOC, signal and data tables in
landscape where wide, consistent per-interface numbering. Render,
inspect, fix, render again before delivery.

DELIVER the .docx and summarise: interfaces covered, the coverage
statement, the cross-end disagreements found, and the top findings.
Offer, do not execute: generating the IRD if requirements coverage
was thin, the single-end extracts for each supplier, and the
two-sided comparison against a counterparty's ICD.

THIS WORKFLOW IS READ-ONLY on the model.

Replace the [bracketed] placeholders with your model and project names.

What you get

Common questions