Domain schema packages: IEC 62304, DO-178C, IEC 61508, EN 50128/50716

[avrabe]

Context

Rivet currently ships 9 schemas: common, dev, aadl, aspice, cybersecurity, stpa, stpa-sec, score, research. These cover automotive (ASPICE, ISO 26262 via STPA) and general development.

No open-source traceability tool provides schema-driven validation for medical, aerospace, railway, or general industrial safety standards. The competitive landscape outside automotive is a desert — teams use DOORS, Jira+plugins, or spreadsheets. Each schema Rivet ships is a domain it owns by default.

This issue adds four domain schemas for the major safety-critical verticals beyond automotive. Each follows Rivet's existing patterns: artifact types, link types, traceability rules, conditional rules, and extends: [common]. All compose with STPA/STPA-Sec via bridge schemas.

Relevant timing:

• IEC 62304 Edition 2 — draft targeting publication ~August 2026, expands scope from medical devices to all health software, adds AI lifecycle requirements, simplifies safety classes from A/B/C to two levels (I/II)
• EU AI Act — August 2, 2026 deadline for high-risk AI (covered separately in EU AI Act compliance schema (schemas/eu-ai-act.yaml) — high-risk AI system documentation #99)
• EN 50128 → EN 50716 — railway standard recently superseded, teams adopting new version

Schema 1: IEC 62304 — Medical Device Software Lifecycle

Standard: IEC 62304:2006+A1:2015 (current), Edition 2 draft (targeting 2026)

Safety classification: Three classes (Edition 1) → Two levels (Edition 2 draft)

• Edition 1: Class A (no injury), Class B (non-serious injury), Class C (death/serious injury)
• Edition 2 draft: Level I (≈ Class A), Level II (≈ Class B+C)

Lifecycle processes (Clause 5-8):

Artifact Type	IEC 62304 Clause	Description
med-sw-dev-plan	5.1	Software development plan
med-sw-req	5.2	Software requirement (functional, performance, interface, safety)
med-sw-arch	5.3	Software architecture element (items, interfaces, SOUP)
med-sw-detail-design	5.4	Detailed design (Class C / Level II only)
med-sw-unit	5.5	Software unit implementation
med-sw-integration-test	5.6	Software integration and integration testing
med-sw-system-test	5.7	Software system testing
med-sw-release	5.8	Software release artifact
med-sw-maintenance	6	Software maintenance record
med-risk-control	7	Risk control measure (links to ISO 14971 hazards)
med-config-item	8	Configuration management item
soup-item	5.3	Software of Unknown Provenance — third-party/OSS component
med-anomaly	9	Problem / anomaly report

Edition 2 additions:
| ai-dev-plan | New | AI/ML development lifecycle plan |
| ai-training-data | New | Training data record (provenance, quality, bias assessment) |
| ai-validation | New | AI model validation record |

Traceability rules:

• Every med-sw-req must derive from a system requirement or risk control (derives-from, error)
• Every med-sw-arch must be allocated from a software requirement (allocated-from, error)
• Every med-sw-req must be verified by a test (verified-by backlink, severity by class/level)
• Every soup-item must have a risk assessment (risk-assessed-by backlink, error for Class B+C / Level II)
• Every med-risk-control must link to at least one hazard (mitigates, error)

Conditional rules (class-dependent rigor):

• Class C / Level II: med-sw-detail-design required, full unit verification required
• Class A / Level I: detailed design and unit verification recommended but not required

Bridge schema: iec-62304-stpa-bridge.yaml

• Maps STPA hazards → med-risk-control measures
• Maps STPA loss scenarios → med-anomaly reports

References:

• IEC 62304 Wikipedia
• IEC 62304 Edition 2 draft changes
• IEC 62304 lifecycle overview
• Jama guide
• ISO 14971 (risk management for medical devices — risk controls link target)

---

Schema 2: DO-178C — Airborne Software

Standard: RTCA DO-178C (2011), with supplements DO-330 through DO-333

Design Assurance Levels (DAL):

• Level A: Catastrophic (most rigorous — e.g. flight control)
• Level B: Hazardous/Severe-Major
• Level C: Major
• Level D: Minor
• Level E: No safety effect (least rigorous)

Objectives-based structure:

DO-178C defines ~71 objectives across processes. The number of objectives and independence requirements increase with DAL. Rather than prescribing methods, it specifies what must be demonstrated.

Artifact Type	DO-178C Process	Description
air-system-req	—	System-level requirement (from ARP 4754A)
air-hlr	§5	High-Level Requirement (software requirement)
air-llr	§5	Low-Level Requirement (detailed design requirement)
air-sw-arch	§5	Software architecture
air-source-code	§5	Source code unit
air-hlr-test	§6	High-level requirement test case
air-llr-test	§6	Low-level requirement test case (DAL A/B/C)
air-structural-coverage	§6	Structural coverage analysis (MC/DC for DAL A)
air-integration-test	§6	Integration test
air-hw-sw-integration	§6	Hardware/software integration test
air-review	§7	Review / analysis record (independence required per DAL)
air-tool-qualification	DO-330	Tool qualification record
air-derived-req	§5	Derived requirement (no parent system req — requires justification)
air-problem-report	§8	Problem report / change request

Traceability rules (bidirectional, end-to-end):

• air-hlr → air-system-req (derives-from, error)
• air-llr → air-hlr (derives-from, error)
• air-source-code → air-llr (implements, error)
• air-hlr-test → air-hlr (verifies, error)
• air-llr-test → air-llr (verifies, error for DAL A/B/C)
• Every air-hlr must have test coverage (verified-by backlink, error)
• Every air-derived-req must have safety justification (error)
• air-structural-coverage → air-source-code (covers, error for DAL A/B)

Conditional rules (DAL-dependent):

• DAL A: MC/DC coverage required, all objectives with independence
• DAL B: Decision coverage, most objectives with independence
• DAL C: Statement coverage, some independence
• DAL D: Minimal objectives, no independence
• DAL E: No objectives required

Companion document artifacts:

• air-model-element (DO-331 — model-based development)
• air-formal-proof (DO-333 — formal methods supplement)
• air-oo-class (DO-332 — object-oriented supplement)

References:

• DO-178C Wikipedia
• DO-178C testing overview (Rapita)
• DO-178C traceability (Parasoft)
• DO-178C certification guide (ConsuNova)
• ARP 4754A (system-level development guidance — source of system requirements)

---

Schema 3: IEC 61508 — Functional Safety (General Industrial)

Standard: IEC 61508:2010 (7 parts), the "mother standard" for functional safety

Safety Integrity Levels (SIL):

• SIL 1: Lowest integrity
• SIL 2
• SIL 3
• SIL 4: Highest integrity (e.g. nuclear, chemical plant emergency shutdown)

Overall safety lifecycle (16 phases):

Artifact Type	IEC 61508 Phase	Description
fs-concept	Phase 1	Safety concept definition
fs-scope	Phase 2	Overall scope definition
fs-hazard-risk	Phase 3	Hazard and risk analysis
fs-safety-req	Phase 4	Overall safety requirements
fs-safety-req-alloc	Phase 5	Safety requirements allocation to E/E/PE systems
fs-sw-safety-req	Part 3	Software safety requirement
fs-sw-arch	Part 3	Software architecture
fs-sw-module	Part 3	Software module design
fs-sw-unit	Part 3	Software unit
fs-sw-integration-test	Part 3	Software integration test
fs-sw-validation	Part 3	Software safety validation record
fs-safety-plan	Phase 8	Overall safety plan
fs-safety-assessment	Phase 9	Safety assessment (by independent assessor for SIL 3/4)
fs-modification	Phase 13	Modification and retrofit record
fs-tool-qualification	Part 3 7.4.4	Tool classification (T1/T2/T3) and qualification

Traceability rules:

• fs-sw-safety-req → fs-safety-req-alloc (derives-from, error)
• fs-sw-arch → fs-sw-safety-req (allocated-from, error)
• fs-sw-module → fs-sw-arch (refines, error)
• Every fs-sw-safety-req must be verified (verified-by backlink, error)
• Every fs-hazard-risk must have a safety requirement addressing it (satisfies backlink, error)
• fs-safety-assessment required for SIL 3/4 (conditional rule)

Conditional rules (SIL-dependent rigor):

• SIL 3/4: Independent safety assessment required, formal methods recommended
• SIL 1/2: Assessment may be by developer, less rigorous verification acceptable

Bridge: iec-61508-stpa-bridge.yaml

• Maps STPA hazards → fs-hazard-risk analysis
• Maps STPA system constraints → fs-safety-req
• IEC 61508 is the parent standard for EN 50128 and (partially) IEC 62304

References:

• IEC 61508 Wikipedia
• IEC 61508 SIL guide (Perforce)
• IEC 61508 overview (TÜV SÜD)
• IEC 61508 explained (alekvs)

---

Schema 4: EN 50128 / EN 50716 — Railway Software Safety

Standard: EN 50128:2011 (superseded by EN 50716:2023)

EN 50128 is a sector-specific derivation of IEC 61508 for railway applications. EN 50716 is its successor with updated terminology and structure.

SIL levels: 0-4 (same as IEC 61508, applied to railway context)

Artifact Type	EN 50128 Clause	Description
rail-sw-req	7.2	Software requirement specification
rail-sw-arch	7.3	Software architecture
rail-sw-design	7.4	Software component design
rail-sw-unit	7.5	Software unit / module implementation
rail-sw-unit-test	7.5	Unit test
rail-sw-integration	7.6	Software integration
rail-sw-integration-test	7.6	Integration test
rail-sw-validation	7.7	Software/hardware integration validation
rail-sw-assessment	6.1	Software assessment (independent for SIL 3/4)
rail-verification-report	6.2	Verification report
rail-validation-report	6.3	Validation report
rail-tool-class	6.7	Tool classification (T1/T2/T3) and qualification
rail-config-mgmt	6.5	Configuration management record
rail-modification	6.6	Modification and change control

Traceability rules:

• rail-sw-req → system requirement (derives-from, error)
• rail-sw-arch → rail-sw-req (allocated-from, error)
• rail-sw-design → rail-sw-arch (refines, error)
• rail-sw-unit → rail-sw-design (implements, error)
• Every rail-sw-req must be verified (verified-by backlink, error)
• Every rail-sw-unit must have unit test (verified-by backlink from rail-sw-unit-test, error for SIL 2+)
• Bidirectional traceability: requirements ↔ design ↔ implementation ↔ tests

Conditional rules:

• SIL 3/4: Independent assessment required
• SIL 0: Minimal requirements (informative only)

EN 50716 changes:

• Updated terminology (aligns with current IEC 61508 concepts)
• Modernized lifecycle model
• Schema should support both EN 50128 and EN 50716 field names via aliases or mapping notes

Bridge: en-50128-iec-61508-bridge.yaml

• EN 50128 derives from IEC 61508 — bridge maps railway types to parent standard types
• Enables cross-standard coverage analysis

References:

• EN 50128 overview (Jama)
• EN 50128 → EN 50716 transition (QA Systems)
• EN 50128 compliance (Parasoft)
• EN 50128 overview (Perforce)
• Railway software safety (LDRA)

---

Implementation approach

Phase 1: IEC 61508 first (parent standard)

IEC 61508 is the "mother standard" — IEC 62304, EN 50128, and (indirectly) ISO 26262 all derive from it. Build this schema first as the foundation.

Phase 2: Sector schemas in parallel

• IEC 62304 (medical) — high demand due to Edition 2 draft + AI lifecycle
• EN 50128/50716 (railway) — closest to IEC 61508, natural extension
• DO-178C (aerospace) — most complex (71 objectives, DAL-dependent), independent structure

Phase 3: Bridge schemas

• iec-61508-stpa-bridge.yaml
• iec-62304-stpa-bridge.yaml
• en-50128-iec-61508-bridge.yaml
• do-178c-stpa-bridge.yaml

Phase 4: Cross-domain coverage

• rivet coverage --schema iec-62304 shows medical compliance status
• rivet export --format compliance-report --schema do-178c generates certification evidence
• rivet init --schema iec-62304 with starter artifacts and example project

Per-schema deliverables

• Schema YAML file in schemas/
• Bridge schema(s) for STPA composition
• Example project in examples/{domain}/
• Documentation in embedded schema description and common-mistakes fields (Spec-driven development: schema packages, bridges, guide API, CRUD CLI #93 Phase 1)

Dependencies

• Spec-driven development: schema packages, bridges, guide API, CRUD CLI #93 Phase 1 (schema package format with manifest.yaml, guidance fields) — enriches all schemas
• Spec-driven development: schema packages, bridges, guide API, CRUD CLI #93 Phase 2 (bridge schema mechanism) — enables cross-domain composition
• Existing schemas: common.yaml (extends), stpa.yaml / stpa-sec.yaml (bridge targets)

[avrabe]

Phase 1-2 shipped in PR #115: IEC 61508, IEC 62304, DO-178C, EN 50128. Bridge schemas remaining for future PR.