Separation of Safety-Critical Concerns

Purpose

Define architectural partitioning to contain failures, simplify verification, and align safety classes with appropriate isolation.

When to Apply

• •Designing or refactoring architecture for mixed-criticality systems.
• •Introducing new subsystems with different safety impacts (e.g., UI vs control).
• •Adding third-party/SOUP modules or connectivity stacks near safety logic.

Requirements (testable)

1. •Partitioning: Separate safety-critical from non-critical components using process/MPU/MMU or language-level isolation; document boundaries. Rationale: fault containment.
2. •Minimal Interfaces: Keep interfaces between partitions minimal and typed; avoid shared mutable state. Rationale: reduce coupling and fault vectors.
3. •Validation at Boundaries: Validate all data crossing partitions (lengths, ranges, CRC/MAC); enforce timeouts and error handling. Rationale: prevent propagation.
4. •Principle of Least Privilege: Assign minimal privileges to non-critical partitions; restrict syscalls/IO where possible. Rationale: limit impact of compromise.
5. •Monitoring: Add health monitoring/heartbeats for critical partitions; safe fallback on failure. Rationale: detect and react to partition failure.
6. •Testability: Provide mocks/stubs for non-critical partitions to test critical logic deterministically. Rationale: reliable verification.

Recommended Practices

• •Use message queues or well-defined RPC instead of shared globals.
• •Define data transfer objects (DTOs) with explicit versioning and size fields.
• •Apply static analysis to enforce layering (no upward dependencies).
• •Consider dual-core separation if hardware supports, with strict comms.

Patterns

DTO with size and CRC:

// REQ-SEP-IF-01; TEST-SEP-04
typedef struct {
    uint16_t len;
    uint16_t crc;
    uint8_t payload[48];
} msg_t;

bool validate_msg(const msg_t *m) {
    if (m->len > sizeof(m->payload)) return false;
    return crc16(m->payload, m->len) == m->crc;
}

Partition watchdog:

// REQ-SEP-MON-02; TEST-SEP-09
void monitor_control_partition(void) {
    if (!heartbeat_ok()) {
        enter_safe_state(); // stop outputs, alarm
    }
}

Anti-Patterns (risks)

• •Shared global buffers between UI and control logic -> risk: corruption.
• •Unbounded/unvalidated IPC -> risk: DoS or malformed data affecting safety.
• •Broad privileges for non-critical services -> risk: escalation into safety domain.
• •Hidden backdoors (debug UART) bridging partitions -> risk: bypassing controls.

Verification Checklist

• • Partitions defined; safety-critical isolated from non-critical.
• • Interfaces documented and minimal; no shared mutable state across classes.
• • Boundary validation implemented (size/range/CRC/MAC, timeouts).
• • Privileges for non-critical partitions minimized.
• • Monitoring/heartbeat for critical partition with safe fallback.
• • Mocks/stubs available for testing critical logic without non-critical code.

Traceability

• •Map partitions to safety classes and hazards; link interface validation tests (TEST-SEP-###).
• •Maintain an interface contract document; tie to architecture diagrams.

References

• •IEC 62304 segregation intent (5.3).
• •ISO 26262 Part 6 (informative for mixed-criticality partitioning concepts).
• •SEI CERT C and MISRA guidance on shared state avoidance (informative).

Changelog

• •1.0.0 (2026-01-04): Initial partitioning guidance with boundary validation and monitoring.

Audit History

• •2026-01-04: Audit performed. Verified:
  • •IEC 62304 segregation intent correctly referenced to clause 5.3
  • •ISO 26262 Part 6 reference appropriate as informative for mixed-criticality concepts
  • •SEI CERT C and MISRA guidance correctly marked as informative