Software Safety Classification and Architectural Impact

Purpose

Define how safety classification (IEC 62304 Class A/B/C) influences architecture, segregation, documentation, and testing, ensuring controls scale with risk.

When to Apply

• •Early architecture/design decisions.
• •Changes that alter hazard exposure, control placement, or interfaces.
• •Integration of new SOUP/components affecting safety pathways.

Requirements (testable)

1. •Classification Derivation: Derive software item class from hazard analysis; document rationale and links to hazards/controls. Rationale: correct activity tailoring.
2. •Segregation: Separate higher-class items from lower-class items via process/memory/interface boundaries; document mechanisms. Rationale: containment of failures.
3. •Interface Contracts: Define strict, validated interfaces between classes; include timeouts, bounds, and error handling. Rationale: prevent propagation of faults.
4. •Evidence by Class: Class B/C require formal architecture description, design detail, and stronger verification (unit+integration+system); Class A can be lighter but traceable. Rationale: proportional rigor.
5. •Change Impact: Reassess classification and segregation when interfaces or functionality change. Rationale: keep controls current.
6. •Tool/SOUP Usage: Evaluate tools/SOUP by class impact; add mitigations or evidence where used in Class B/C items. Rationale: control dependencies.

Recommended Practices

• •Maintain a per-item class table with justification and segregation method.
• •Use MPU/MMU regions or process isolation for Class C vs non-safety code.
• •Apply defensive serialization and checksum on inter-partition messages.
• •Keep class-aware test coverage goals (e.g., MC/DC for Class C control logic).

Patterns

Segregation note (YAML):

item: pump_control_task
class: Class C
segregation: MPU region RO code, RW data; runs in high-priority partition
interfaces: msg queue from ui_task (Class B), validated length + CRC
tests: TEST-IC-12 (queue bounds), TEST-IC-13 (CRC failure path)

Interface validation snippet:

// CLASS C boundary; REQ-IF-01; TEST-IC-12
int handle_cmd(const cmd_t *cmd, size_t len) {
    if (len != sizeof(cmd_t)) return -1;
    if (!crc_ok(cmd, len)) return -2;
    return dispatch(cmd);
}

Anti-Patterns (risks)

• •Treating whole system as lowest class -> risk: under-verified safety functions.
• •Shared memory between Class C and utility code without protection -> risk: corruption.
• •Unbounded, unvalidated messaging across classes -> risk: fault propagation.
• •No re-evaluation of class after feature changes -> risk: stale controls.

Verification Checklist

• • Class per item documented with hazard linkage and rationale.
• • Segregation mechanisms implemented and reviewed (MPU/MMU/process/IPC).
• • Interfaces across classes validated (size, CRC, timeout, error handling).
• • Verification level aligns to class (coverage, test types).
• • SOUP/tool impacts on Class B/C items assessed and mitigated.
• • Change impact analysis performed on classification/segregation.

Traceability

• •Link item class entries to hazards (HZ-###), controls (RISK-CTRL-###), and tests.
• •Maintain a class table under configuration control; reference in architecture docs.

References

• •IEC 62304:2006+A1:2015 (classification and activity tailoring per Annex A Tables A.1-A.7).
• •ISO 14971:2019 (hazard/risk basis).
• •IEC TR 80002-1:2019 (software risk considerations; second edition).

Changelog

• •1.0.1 (2026-01-04): Audit correction - updated IEC TR 80002-1 to 2019 edition.
• •1.0.0 (2026-01-04): Initial skill covering class derivation, segregation, interfaces, and verification expectations.

Audit History

• •2026-01-04: Audit performed. IEC TR 80002-1:2009 updated to 2019 edition.