Skip to content

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

Closed
Closed
Domain schema packages: IEC 62304, DO-178C, IEC 61508, EN 50128/50716#102
Labels
enhancementNew feature or request
@avrabe

Description

@avrabe
avrabe
opened on Apr 2, 2026

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:

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:

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:

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:

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

Dependencies

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions