Defensive Programming for Medical Devices

Purpose

Apply defensive coding techniques to prevent, detect, and safely handle abnormal conditions in safety-relevant software.

When to Apply

• •All safety-related modules; heightened rigor for Class B/C items.
• •Input/output handling, hardware interactions, IPC, and configuration parsing.

Requirements (testable)

1. •Input Validation: Validate range, length, format of all external inputs; reject or sanitize invalid data. Rationale: prevent hazardous behavior and memory faults.
2. •Output Bounds Checking: Enforce limits on actuators/outputs; clamp with alarms when exceeded. Rationale: prevent unsafe outputs.
3. •Assertions and Guards: Use assertions for invariants in non-production or guarded builds; runtime checks for production where safety impact exists. Rationale: detect defects early.
4. •Error Propagation: Return explicit error codes; avoid silent failures; ensure callers handle errors. Rationale: predictable handling.
5. •Timeouts: Apply timeouts to blocking waits (I/O, IPC); on timeout, transition to safe/error handling. Rationale: avoid hangs.
6. •Defensive Defaults: Fail closed/safe on config or sensor anomalies; prefer explicit initialization for all fields. Rationale: safe startup and operation.

Recommended Practices

• •Prefer explicit enums over magic numbers; exhaustive switch with default-safe handling.
• •Zero-initialize structs; validate configuration at startup with a single validation function.
• •Log abnormal conditions with context but avoid leaking sensitive data.
• •Use compile-time checks (static_assert) for structure sizes, array lengths.

Patterns

Input validation:

// REQ-DEF-INPUT-01; TEST-DEF-03
bool validate_flow(float ml_hr) {
    return ml_hr >= 0.0f && ml_hr <= MAX_FLOW;
}

Output clamping with alarm:

// REQ-DEF-OUT-02; TEST-DEF-05
float clamp_output(float cmd) {
    if (cmd > MAX_OUTPUT) {
        alarm_over_output();
        return MAX_OUTPUT;
    }
    if (cmd < MIN_OUTPUT) return MIN_OUTPUT;
    return cmd;
}

Timeout wrapper:

// REQ-DEF-TIMEOUT-04; TEST-DEF-07
int read_with_timeout(int fd, uint8_t *buf, size_t len, uint32_t ms) {
    if (!poll_ready(fd, ms)) return -ETIMEDOUT;
    return read(fd, buf, len);
}

Anti-Patterns (risks)

• •Trusting external input without bounds checking -> risk: overflow, unsafe commands.
• •Silent error swallowing (return; with no log/propagation) -> risk: hidden failure.
• •Infinite waits with no timeout -> risk: deadlock/hang in critical path.
• •Using uninitialized data -> risk: nondeterministic behavior.

Verification Checklist

• • Inputs validated (range/length/format) at boundaries.
• • Outputs clamped with alarms for out-of-range commands.
• • Assertions/guards present for invariants; runtime checks on safety paths.
• • Errors propagated and handled; no silent failure paths.
• • Blocking operations have timeouts; safe fallback on timeout.
• • Defensive defaults applied; structures initialized explicitly.

Traceability

• •Tag defensive checks with requirement IDs (REQ-DEF-###) and link to tests.
• •Keep logs of validation failures tied to fault handling requirements where applicable.

References

• •MISRA C/C++ defensive guidelines.
• •IEC 62304 implementation discipline expectations.
• •SEI CERT C secure coding (informative).

Changelog

• •1.0.0 (2026-01-04): Initial defensive design guidance with validation, clamping, and timeout patterns.

Audit History

• •2026-01-04: Audit performed. Verified:
  • •MISRA C/C++ defensive guideline references accurate
  • •SEI CERT C reference appropriate as informative
  • •Code examples follow stated defensive patterns correctly