IEC 62304 requires manufacturers to determine the necessary segregation of software components. How this is to be done is not specified in the standard, which leads to much discussion. Find answers to frequently asked questions here.
1. The five objectives of segregation
Segregation has several objectives.
Objective 1: Minimize risks
Segregating a component helps to minimize the risk of that software item in the event of a fault. The dependencies between a segregated component and the other components of the software system are weaker than would be the case for a non-segregated or weakly segregated component.
A component is segregated because it cannot access variables of other components or even global variables. It can, therefore, neither read nor modify this variable.
This means that a faulty (global) variable cannot directly cause a segregated component without this access to malfunction. Also, a segregated component cannot modify global variables incorrectly, which causes the entire software system to malfunction.
IEC 62304 discusses segregation with a focus on risk minimization.
Objective 2: Simplify and accelerate development
Development teams benefit from weakly coupled components. It is then easier to
- split the development between several teams and thus to work in parallel,
- use the most suitable technologies for different components (e.g., micro-services),
- test the components independently of each other and
- integrate them into an overall system.
Objective 3: Minimize documentation effort
IEC 62304 allows sufficiently segregated components to be assigned different safety classes. The documentation requirements for components with a low safety class (A or B) are lower than for higher safety classes.
The safety classes are an IEC 62304 concept that the FDA does not recognize. However, the FDA also allows a scope of ” risk-based ” documentation.
Do not overestimate the time you save by assigning software (items) to safety class B instead of the default class C.
Creating a resilient software architecture and a detailed design is much more worthwhile. This saves a great deal of effort that would otherwise be spent on
- inefficient, uncoordinated development,
- rectifying faulty software and
- maintaining the software system.
We can complete this documentation within a few days. Please contact us if you require support, for example, using our contact form.
Objective 4: Increase maintainability
Thanks to their weak coupling, segregated components are easier or better
- replaceable/replaceable by other components,
- reusable, e.g., in other products, and
- analyzable; it is easy to understand what a component does and what the effects are if it does not.
Objective 5: Compliance with legal requirements
Manufacturers must at least consider and document whether and at what point the segregation of their software items is necessary. This obligation arises from
- ISO 14971, which requires that risks be minimized; for example, by using a design that is inherently safe to the greatest extent possible,
- IEC 62304, which explicitly requires this in Chapter 5.3.5
The MANUFACTURER shall identify any segregation between SOFTWARE ITEMS that is necessary for RISK CONTROL, and state how to ensure that such segregation is effective. [Class C]
In other words, manufacturers must determine whether and how various components must be segregated to effectively control risks posed by an element or design measures for risk control.
The standard also explains this in the annex.:
The software ARCHITECTURE should promote segregation of software items that are required for safe operation and should describe the methods used to ensure effective segregation of those SOFTWARE ITEMS.
According to Chapter 4.3 of IEC 62304, the effectiveness of segregation must also be demonstrated when manufacturers assign different safety classes to a software system.
2. Segregation options
If you want to downclassify an entire software system, IEC 62304 requires independent hardware. Suppose you only assign a lower safety class to specific components of a software system and not to the software system as a whole. In that case, answering whether segregation is sufficiently justified becomes more challenging.
a) Segregation through different hardware
A software item that runs on its own/independent processor and memory area is usually sufficiently segregated.
You can avoid this discussion if you define each part of your software that runs on its hardware as a separate software system to which you can independently assign a safety class.
b) Segregation through specialized processors and operating systems
A dedicated processor or a unique operating system on which different processes run independently of each other and in which their memory areas cannot influence each other will also be sufficiently segregated.
c) Segregation within a software on a processor
It is more difficult to justify that various software components that run on a processor are sufficiently segregated. Here, it is essential to examine which risks segregation should minimize.
If the medical device is not available because the software crashes altogether (e.g., due to a memory overflow caused by the operating system), the patient is at risk. In this case, logical separation of the components (e.g., using packages, private modifiers, OSGi bundles, and namespaces) is difficult to argue for.
If a race condition leads to a deadlock, patients are at risk. Separating the processes is likely sufficient if an independent process on the same processor can identify this deadlock and react appropriately.
A component’s method calculates a radiation dose. A second component’s method reviews this value before accepting it. The two components are sufficiently segregated regarding this logical error. However, if the first component can transfer values to the second component that cause the second component to crash (e.g., buffer overflow), the segregation would not be sufficient.
So remember that segregation boundaries that only exist logically can consistently be undermined via the operating system/memory. If these “detours” do not lead to unacceptable risks, segregation within software on a processor is conceivable.
Manufacturers should always strive for segregation to minimize risks – not the documentation effort.
3. Typical segregation errors
Errors regularly occur when segregating software items.
Mistake 1: Lack of segregation
The manufacturer failed to segregate its components – or even to identify components.
Mistake 2: Missing documentation
For auditors and reviewers, the rule is that if it’s not documented, it doesn’t exist. Therefore, developing software with a perfect architecture of weakly coupled, i.e., well-segregated, components is not enough. The architecture and design decisions must also be documented.
Mistake 3: Insufficient evidence
Boxes drawn in PowerPoint count as documentation but are not a line of argument. The manufacturers must document the interfaces and explain why they lead to such a weak coupling of the components that they are considered sufficiently segregated.
There is no discussion of why two components are sufficiently segregated, especially if running on the same processor.
These considerations must also be reflected in the risk management file, primarily if the segregation is intended to achieve risk control measures.
Error 4: Defective implementation
Paper is patient. This also applies to architectural documents and risk management files. It is crucial that these specifications are implemented and that the assumptions are accurate.
All too often, an unplanned method is implemented on a facade class during development, increasing the dependencies of components and thus sabotaging segregation.
Error 5: Insufficient verification (e.g. testing)
Every risk-minimizing measure must be reviewed for effectiveness. As a consequence, manufacturers must review whether the segregation is adequate. Tests usually provide this evidence. Laws and standards require that these tests be planned and carried out, the results evaluated, and all of this be documented.
Some tests are complex. For example, a buffer overflow, a runtime environment crash, or faulty data from a neighboring system are not always easy to simulate. These proofs of effectiveness are regularly missing.
4. Conclusion and summary
Software for medical devices must be safe. The segregation of software items is a lever for achieving this safety and minimizing risks. This is why regulations demand segregation.
The weak coupling of components is a prerequisite for their segregation. Whether a logical or physical separation is necessary for segregation depends on the individual case. However, segregation is almost always needed for medical devices.
The documentation of segregation and the proof of its effectiveness are required by law.
Change history
- 2024-11-26: Article almost completely rewritten
- 2015-11-27: The first version of the article was published
