Skip to main content

ICD

The contract between subsystems — auto-seeded from your block diagram.

ICD

What it's for​

An ICD defines the interfaces between subsystems. Each interface row carries a class (electrical / power / data / mechanical / thermal / fluid / rf / human / software), source and target endpoints with owning parties, a verification status and a disposition, linked requirements, and nested signals/messages. Its stand-out feature is deriving interface stubs straight from a Block Diagram.

When to use it​

Once the architecture is drawn and subsystems need to agree on their boundaries.

How it works​

  1. Use “Derive from Block Diagram”, or Generate / start blank / import CSV. → Picking a block diagram converts its connections into interface stubs — one row per connection — so you refine instead of author from zero.
  2. Add or edit an interface row (one at a time). → Inline editors for name, source→target endpoints, class, owning-party per side, verification status (planned/in-work/verified/failed/waived) and disposition (open/proposed/agreed/disputed); Save persists, Cancel reverts.
  3. Refine via a follow-on and merge. → A main save re-resolves the verification links into the system VCRM; changes show in the diff panel.
  4. Search, then Export. → Export to PDF, stamped PDF, CSV (one row per signal) or JSON; the CSV round-trips back in via Import.

Mechanics​

  • Interfaces table with class · owning parties · verification · disposition
  • Nested signals / messages per interface
  • Derive interface stubs from a Block Diagram
  • Per-row inline edit (one at a time) · CSV import (row-per-signal)
  • Follow-on · merge · revisions · review · VCRM link resolution

Open ICD in the app