← Back to the learning library
Before you begin: TFA-101, TFA-109 and a working understanding of medical-device risk management. Use a controlled copy of IEC 62304 including applicable amendments for a real compliance assessment.
Reading time and practice time are estimates. Examples use fictional products and illustrative engineering values, not approved product limits.
Learning objectives
By the end of this module, you should be able to:
- Place embedded firmware within the IEC 62304 lifecycle.
- Explain safety classification and its effect on activities.
- Plan requirements, architecture, detailed design and verification evidence.
- Integrate firmware with system risk management, configuration and problem resolution.
Lesson 1
1. Firmware is software within a medical-device system
IEC 62304 applies lifecycle processes to medical-device software, including embedded firmware. Begin by defining the software system boundary and the software items that make it understandable and manageable. The standard does not replace system engineering, usability, electrical safety or ISO 14971 risk management; firmware evidence must connect to those activities.
A bootloader, operating system, communications stack or library may be a software item or SOUP depending on how it is developed and controlled.
Lesson 2
2. Classification is a documented risk decision
IEC 62304 software safety classes A, B and C determine the applicable lifecycle activities. They are not medical-device regulatory classes, automotive ASILs or IEC 61508 SILs. Do not convert directly between these schemes.
Apply the classification procedure in the authorised edition and amendment to the defined software system, considering its contribution to hazardous situations and permitted external risk controls. The 2015 amendment changed the classification provisions; a severity-only mnemonic is not the complete procedure. Do not justify a lower class using an unsupported low probability of a software defect.
Different item classifications require a justified architecture and segregation argument where applicable. Identify shared resources and failure propagation before relying on a lower-class item. Reassess classification when functions, dependencies or external controls change.
Lesson 3
3. Build a connected development record
The plan defines lifecycle, responsibilities, methods, standards, tools and deliverables. Software requirements should be testable and include risk controls. Architecture defines items, interfaces and segregation. Detailed design provides sufficient information to implement and verify higher-class items. Unit, integration and system verification demonstrate the allocated requirements.
Traceability should connect requirements, risk controls, design and tests without forcing every source line into a document.
Lesson 4
4. Continue after first release
IEC 62304 also addresses maintenance, configuration management and problem resolution. Define how field problems are recorded, evaluated for safety, investigated, corrected and communicated. Changes require impact analysis and appropriate regression evidence. SOUP anomalies and new vulnerabilities may trigger the same controlled evaluation.
Lesson 5
5. Plan deliverables around decisions
The development plan should connect responsibilities, lifecycle activities, applicable methods, tools, configuration controls and deliverables. A document list alone does not explain when a requirement is accepted, how a design is reviewed or who resolves a failed test.
Requirements should include functional behaviour, interfaces, ranges, timing, alarms where applicable, risk controls and abnormal conditions. The architecture allocates them to software items and explains interfaces and segregation. Detailed design adds the information needed to implement and verify units where required by the applicable class and process.
For an embedded controller, include the bootloader, third-party operating system, drivers, configuration and update mechanism in the boundary assessment. A supplier’s organisational boundary does not remove the firmware from the manufacturer’s lifecycle responsibilities.
Lesson 6
6. Assess supplied and existing software
SOUP is not a synonym for all third-party code. Determine whether the component meets the standard’s definition based on its origin and available development records. Identify its exact version, function, operating environment, requirements and known anomalies, then assess its role in hazardous situations.
For a supplied RTOS, consider scheduling, memory, interrupts, failure handling and supported compiler/processor combinations. A vendor test report may be useful but does not establish correct integration into your device. Record which anomalies affect the configured build and how missing evidence is addressed.
Legacy software needs an explicit assessment under the applicable provisions rather than being declared compliant because it has operated for years. Field history informs risk, but absence of reported failures is not evidence that every hazardous condition has been exercised.
Lesson 7
7. Connect software release to device release
Complete software verification, configuration, anomaly evaluation and release records for the exact software version. Maintain traceability from risk-control requirements through design and results. A change requires impact analysis that includes connected binaries, SOUP, tools, configuration, tests and risk management.
Medical-device validation and final device release remain wider activities; IEC 62304 does not replace them. Firmware can satisfy a software requirement while the complete device fails a clinical workflow or system performance need. Keep the software release decision and the final product release decision connected but distinct.
Post-release problem reports should preserve affected versions, reproducibility, safety impact, investigation and corrective action. Cybersecurity findings may need the same coordinated lifecycle response, alongside the product’s dedicated security process.
Decision guide
What must a classification rationale establish?
| Decision | Evidence needed | Avoid |
|---|---|---|
| Boundary | Software system, items, interfaces and external controls. | Classifying an unnamed collection of files. |
| Risk contribution | Hazardous situations and credible software involvement. | Equating class with code size or device regulatory class. |
| Applicable procedure | Exact standard edition/amendment and documented rationale. | A severity table used as a complete classification algorithm. |
| Segregation | Architecture and verification supporting different item treatment. | Assuming separate source folders establish independence. |
Worked example
Worked example — embedded analyser controller
Firmware controls temperature, stirring and signal acquisition; loss of host communication must not leave an unsafe operation running.
The software boundary includes controller application, bootloader and third-party RTOS. Requirements define control limits, communication supervision and safe-stop behaviour. Architecture allocates an independent monitor and separates drivers from assay control. Integration tests verify interfaces; HIL verifies temperature faults, lost communication and interrupted update. Classification assumptions are linked to the system risk analysis.
The firmware file is not an isolated “code package”; it forms a traceable lifecycle record connected to system safety and released binaries.
Engineering evidence
What should the work produce?
Software development plan
Defines lifecycle, responsibilities, methods and deliverables.
Classification rationale
Records possible harm and external controls.
Requirements and architecture
Allocate functions, risks, interfaces and segregation.
Verification and release records
Demonstrate tests, anomalies, configuration and approval.
Maintenance and problem records
Control post-release evaluation and change.
Common failure patterns
What goes wrong?
- Equating medical-device class with software safety class.
- Writing plans and architecture after testing is complete.
- Calling all third-party code SOUP without evaluating its role and anomalies.
- Keeping risk controls in a separate system with no software traceability.
Applied exercise · approximately 25 minutes
Build a firmware evidence gap assessment
A supplier provides a controller binary, source snapshot, generic RTOS tests and a spreadsheet of passing bench tests. The manufacturer holds the system risk analysis, but no approved firmware architecture or classification rationale has been found.
- Identify the first boundary and classification questions without inventing a class.
- List evidence that can be reused, evidence needing evaluation and evidence that is absent.
- Define a remediation sequence that distinguishes historical records from newly performed work.
Review a suggested approach
Resolve the software-system boundary, item breakdown, intended behaviour, hazardous situations and external controls with the manufacturer and supplier. Apply the controlled classification procedure; the supplied information is insufficient to assign a class. Identify exactly which binary the source and tests support.
Reuse genuine dated records when their scope and configuration are credible. Evaluate RTOS evidence against the integrated version and operating assumptions. Create and review the missing architecture, requirements gaps and verification plan, then perform justified additional verification. Label reconstructed descriptions and new reviews honestly: they cannot establish that an undocumented historical review occurred. Close the assessment with owners, residual gaps and release implications.
Completion criteria
- No unsupported class or compliance claim is made.
- Evidence reuse is tied to an identified configuration and objective.
- The remediation plan preserves provenance and manufacturer responsibility.
This is a self-directed engineering exercise, not an accredited examination. Compare the rationale as well as the final answer.
Practical check
Questions for your next design review
- Is the software boundary and item decomposition clear?
- Does classification cite system hazards and external controls?
- Are risk-control requirements identifiable and verified?
- Are architecture and detailed design proportionate to class?
- Do release and maintenance records identify the exact firmware configuration?
IEC 62304 compliance is a connected body of lifecycle evidence, not a folder of document titles.
References and further reading
- IEC 62304:2006 + Amendment 1:2015 — consolidated publication
- ISO 14971:2019 — Medical device risk management
- FDA — General Principles of Software Validation
- TFA-301 — Firmware Standards & Guidance
Educational guidance only. Apply the authorised standards editions, regulations and approved procedures relevant to your product and market. Linked publications support further study; the fictional exercises do not demonstrate compliance.