Note: This article discusses general principles of IEC 62304 compliance. Actual certification requirements depend on specific device classifications, regulatory jurisdictions, and notified body interpretations. This is not legal or regulatory advice.
IEC 62304 defines the lifecycle requirements for medical device software. Among its classifications, Class C represents the highest level of rigour—software where failure could result in death or serious injury. Pacemaker firmware. Insulin pump controllers. Ventilator software.
For manufacturers developing Class C software, the standard imposes requirements that many conventional architectures struggle to meet. Deterministic execution isn’t mandated by the standard, but it can provide architectural properties that directly support compliance evidence.
Understanding the Classification System
IEC 62304 classifies software based on the severity of harm that could result from failure:
- No injury or damage to health possible
- Basic documentation requirements
- Unit testing optional
- Example: Patient record display
- Non-serious injury possible
- Unit-level verification required
- Architecture documentation required
- Example: Diagnostic imaging display
- Death or serious injury possible
- Full lifecycle documentation required
- Detailed design verification required
- Example: Implantable cardiac devices
The jump from Class B to Class C is significant. It’s not merely more documentation—it’s a fundamentally different evidence burden. You must demonstrate not just that the software works, but that you understand why it works, and that this understanding is traceable through every development artefact.
The Class C Evidence Requirements
IEC 62304 Section 5 specifies software development process requirements. For Class C, key requirements include:
Software Architecture (5.3): The architecture must be documented with sufficient detail to support verification. This includes identifying software items, their interfaces, and the data flows between them.
Detailed Design (5.4): Each software unit must be specified in detail sufficient to enable correct implementation and verification. The design must address how the unit contributes to the overall safety requirements.
Software Unit Verification (5.5): Each unit must be verified against its detailed design. The verification must demonstrate correct implementation of the design and absence of unintended functionality.
Integration Testing (5.6): Software items must be tested in combination to verify that they function correctly together and that interfaces operate as specified.
System Testing (5.7): The complete software system must be tested to verify that it meets all specified requirements.
The standard requires traceability throughout: from requirements to architecture, from architecture to detailed design, from design to implementation, from implementation to verification. Any gap in this chain becomes a compliance finding.
Where Conventional Architectures Struggle
Traditional embedded software architectures face several challenges in Class C compliance:
Non-Deterministic Behaviour
When software exhibits different timing or sequencing depending on runtime conditions, verification becomes probabilistic rather than exhaustive. A test that passes 10,000 times might fail on execution 10,001 due to a timing window that only opens under specific load conditions.
For Class C devices, this creates an uncomfortable question: how many test executions are enough? The honest answer is that no number is sufficient if the underlying behaviour is non-deterministic. You’re sampling from a space you cannot fully characterise.
Implicit State
Operating systems and middleware often maintain internal state that affects application behaviour but isn’t visible to the application developer. Thread scheduling decisions, interrupt priorities, memory allocation patterns—all can influence execution in ways that are difficult to document and verify.
IEC 62304 requires documenting software architecture with sufficient detail to support verification. When significant behaviour is determined by implicit state in platform components, this documentation requirement becomes challenging to satisfy.
Interface Complexity
Complex inter-component interfaces create verification challenges. If component A can call component B in 47 different ways, and component B can be in 23 different states, the interface has over 1,000 potential interaction scenarios. Testing all of them may be impractical; documenting all of them is certainly tedious.
This complexity tends to compound. Systems built from complex components with complex interfaces exhibit combinatorial explosion in their verification requirements.
How Deterministic Architecture Supports Compliance
Deterministic execution provides architectural properties that can directly address these challenges:
Reproducible Behaviour
Given identical inputs and initial state, a deterministic system produces identical outputs and final state—enabling exhaustive verification of observed behaviour.
When behaviour is reproducible, testing becomes definitive rather than statistical. A test that passes demonstrates correct behaviour for that input scenario. The verification record shows what the system does, not what it probably does.
This property directly supports IEC 62304’s verification requirements. Evidence of correct behaviour is concrete and repeatable.
Explicit State
Deterministic architectures typically make all state explicit and inspectable. There is no hidden scheduler state, no implicit priority inheritance, no background garbage collection. The system state at any moment can be captured, examined, and restored.
For documentation purposes, this means the architecture description can be complete. Every state variable, every state transition, every possible configuration is enumerable. There are no “it depends on runtime conditions” qualifications.
Minimal Interfaces
Deterministic designs tend toward minimal, well-defined interfaces. Components communicate through explicit channels with specified protocols. The tick-based execution model, for example, provides a single synchronisation primitive: the tick boundary.
Fewer interface scenarios mean fewer test cases, fewer documentation pages, and fewer opportunities for unexpected interactions. The verification burden scales linearly with functionality rather than combinatorially with interface complexity.
Mapping to IEC 62304 Requirements
Specific standard requirements that deterministic architecture can support:
| Requirement | How Determinism Helps |
|---|---|
| 5.3.2 - Develop architecture to support hazard control | Reproducible behaviour enables verification of hazard controls |
| 5.3.6 - Verify architecture supports requirements | Complete state documentation enables traceability |
| 5.4.2 - Develop detailed design from architecture | Explicit interfaces simplify unit-level design |
| 5.5.3 - Verify software units | Deterministic units have definitive test results |
| 5.6.3 - Verify integration | Reproducible timing eliminates integration test flakiness |
| 5.7.2 - Verify software system | System-level tests are repeatable and conclusive |
The pattern is consistent: where the standard requires evidence of correct behaviour, deterministic execution provides evidence that is concrete rather than statistical, complete rather than sampled.
The Software Problem Report Challenge
IEC 62304 Section 9 addresses software problem resolution. When anomalies are discovered, they must be evaluated, documented, and resolved. For Class C software, this includes evaluating whether the problem affects safety.
Non-deterministic bugs present a particular challenge: they may be difficult to reproduce, difficult to diagnose, and difficult to verify as resolved. A problem report stating “intermittent crash under high load” can consume weeks of engineering time with no definitive resolution.
Deterministic architectures can reduce this burden. When bugs are reproducible, they can be captured as failing test cases. When fixes are applied, the test case demonstrates resolution. The problem report lifecycle becomes tractable.
This matters for more than engineering efficiency. Regulatory reviewers examine problem reports. A history of intermittent issues with uncertain resolutions suggests an architecture that resists verification. A history of reproducible issues with demonstrated fixes suggests an architecture under control.
Post-Market Surveillance Implications
Class C devices require post-market surveillance under the Medical Device Regulation (MDR) in Europe and similar requirements elsewhere. When field issues occur, manufacturers must investigate, assess safety impact, and potentially issue field safety corrective actions.
The investigation phase benefits significantly from reproducibility. If device logs capture sufficient state, and device behaviour is deterministic, then field issues can potentially be reproduced in the laboratory. The root cause analysis has concrete evidence to work with.
For non-deterministic systems, field issue investigation often relies on statistical analysis of failure patterns across the installed base. This can identify correlations but rarely provides mechanistic understanding. Regulatory authorities increasingly expect more than correlation.
The Certification Timeline Factor
While not a compliance requirement per se, certification timeline affects commercial viability. Devices that spend years in regulatory review face market timing risks and extended capital requirements.
Deterministic architectures can support faster certification through:
Reduced verification iterations: Tests that pass consistently don’t require re-runs to build confidence.
Cleaner audit findings: Clear traceability and complete documentation reduce audit queries.
Faster problem resolution: Reproducible issues reach root cause faster.
Reusable evidence: Platform components verified once can support multiple device applications.
These factors are difficult to quantify precisely, but the pattern observed in practice suggests that verifiable architectures reach market faster than their conventional counterparts—sometimes significantly faster.
Practical Considerations
Adopting deterministic architecture for Class C development involves trade-offs:
Development approach: Deterministic designs require discipline. The freedom to spawn threads or allocate memory dynamically is constrained. Some developers find this restrictive.
Performance characteristics: Deterministic scheduling can impose overhead compared to fully dynamic approaches. For compute-intensive applications, this overhead must be evaluated.
Platform availability: Deterministic execution platforms are less common than conventional RTOS options. Toolchain and ecosystem maturity varies.
Team expertise: Designing for determinism requires specific skills that may not be present in teams experienced with conventional embedded development.
These constraints are real and should be evaluated against the compliance benefits for any specific project.
Conclusion
IEC 62304 Class C represents the highest bar for medical device software development. The standard’s requirements for traceability, verification, and documented understanding of system behaviour create challenges that conventional architectures struggle to address efficiently.
Deterministic execution provides architectural properties—reproducibility, explicit state, minimal interfaces—that can directly support compliance evidence. The result is potentially faster certification, more tractable problem resolution, and stronger audit performance.
For manufacturers developing the next generation of safety-critical medical devices, the architecture decision deserves careful consideration. The standard doesn’t mandate determinism, but determinism can make the standard’s requirements substantially easier to meet.
As with any architectural approach, suitability depends on system requirements, risk classification, and regulatory context. Medical device development involves numerous factors beyond software architecture, and regulatory strategy should be developed in consultation with qualified regulatory affairs professionals.
Further Reading
- CardioCore™ Medical Kernel — Deterministic platform designed for IEC 62304 alignment
- Reproducibility and Post-Incident Analysis in Implantable Cardiac Devices — Legal and regulatory implications
- DO-178C Level A Certification — Parallel requirements in aerospace