The idea of breaking down a complex problem into smaller, more manageable challenges is a well-established concept. In software design, this concept is called segregation.
Segregation involves ensuring that certain software items are protected from the unintended influence of other software items. Consequently, software segregation in the context of medical devices is essentially the partitioning of software to control and reduce risk.
In our topical article below, our eHealth and Regulatory teams discuss how to effectively implement software segregation to limit risk, enhance reusability and testability, and ultimately allow manufacturers to focus efforts on the critical components of their medical devices.
What do the regulations say about software segregation?
From a regulatory perspective, it is permitted and possible for software systems to consist of software items with different software safety classes. Detailed documentation providing a clear description of architectural design and interfaces, and a comprehensible rationale for the segregation is required. In every case, rigorous and thorough risk analysis, and control coherent with architectural segregation is required to be certain that the rationale is valid.
IEC 62304 and IEC 60601-1 both promote the idea of segregating or partitioning software to control and reduce risk:
- Annex B.4.3 of IEC 62304 outlines that each software item can have its own software safety classification.
- IEC 62034 4.3 defines how software safety classifications shall be assigned.
- IEC 62034 4.3.d calls for a rationale to be provided for each of the different classifications that explains how the software items are effectively segregated – such that they may qualify for separate software safety classification.
Software Safety Class C classified software
IEC 62304 5.3.5 mandates that during software architectural design for Software Safety Class C classified software, the manufacturer must identify the segregation necessary for risk control.
An example of segregation provided in the note attached to this section is where software items execute on different processors. The effectiveness of the segregation can be ensured by having no shared resources between the processors. Other means of segregation can be applied when effectiveness can be ensured by the software architecture design.
At what stage should software segregation be implemented?
The end of the software architecture activity is the earliest point in the development when the full set of software items is defined, and the risk management activity has identified how the software items relate to safety. This is therefore the earliest point at which software items can be classified definitively according to their safety role, and segregated accordingly. This timing corresponds to when risk control should begin as instructed in ISO 14971.
Before this point, the risk management process identifies architectural risk control measures, for example by adding protective subsystems, or reducing the opportunities for software failures to cause harm. After this point, the risk management process uses methods aimed at reducing a software item’s probability of failing. In other words, the classification of a software item specifies the process-based risk control measures to be applied to said item.
Which software items should be segregated?
Your 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.
Segregation is not restricted to physical (e.g. processor or memory partition) separation but includes any mechanism that prevents one software item from negatively affecting another. The suitability of a segregation is determined by the risks involved and the rationale required to be documented.
The diagram below illustrates a possible partitioning of software items within a software system and how the software safety classes could be applied to the group of software items:
In this example, the manufacturer knows, due to risk analysis, that the preliminary software safety classification for the software system is Software Safety Class C. During software architecture design the manufacturer has decided to partition the system, as shown, with three software items – X, W and Z.
The manufacturer is able to segregate all software system contributions to hazardous situations which could result in death or serious injury to software item Z and all remaining software system contributions to hazardous situations which could result in a non-serious injury to software item W.
Software item W is classified as Software Safety Class B and software item Z as Software Safety Class C. Software item Y therefore must be classified as Class C, as per IEC 62304 4.3.d. The software system is also classified at Software Safety Class C in line with this requirement. Software item X has been classified as Software Safety Class A.
In this example, the manufacturer must document a rationale for the segregation between software items X and Y, as well as software items W and Z, to assure the integrity of the segregation. If segregation is not possible between software items X and Y, then software item X must be classified as Software Safety Class C.
How do you implement effective segregation?
If we review the definition of segregation from IEC 62304, then segregation is effective if the individual software items combined in the system maintain their functionality and provide adequate risk control even under adverse conditions.
Step 1 | Overcome adverse conditions
Adverse conditions could include faults, limited resources, or limited performance.
We cannot prevent faults from occurring, therefore we must provide error handling which responds to faults and ensures that the software avoids failure.
The available resources in each design can be pre-determined. For effective segregation, the design of the system must guarantee that all resources required to support risk controls are always available and cannot be compromised.
Effective risk control requires guaranteed performance and response times for critical tasks. Effective segregation requires that the risk control measures are always able to run at the correct rate with the correct response timing.
Step 2 | Ascertain whether physical or logical segregation is required
Segregation can be physical or logical:
- Physical segregation means executing the individual software items on different hardware (e.g., separate processors or cores) with segmented memory managed by memory management hardware.
- Logical segregation means we logically separate the software items and their data within the same hardware. Logical segregation can use layers within the architecture.
Step 3 | Reduce coupling and enhance cohesion
The principles of reducing coupling and enhancing cohesion should be applied for segregation of software items.
- Coupling is the measure of the degree of interdependence between the modules. Good software will have low coupling.
- Cohesion is a measure of the degree to which the elements inside of the module are functionally related. A good software design will have high cohesion.
How to reduce coupling
- Ensure your software interfaces are well defined.
- Avoid global data structures.
- Prevent external access to internal data and functions.
- Detect software items and correct errors locally.
- Ensure that your software items prevent faults from blocking processing, data, or resources, ensuring other software items are not blocked or corrupted.
How to enhance cohesion
- Decompose your software architecture to group related functionality together.
- Group together software functions that may be different but are risk assessed to share the same safety class.
What are the pros and cons of software segregation?
While risk reduction is one of the most important reasons for segregation, for small systems the efforts of planning, segregating, and documenting may not outweigh the benefits. However, applying some consideration supports a good architectural result.
On the other hand, for large and complex systems, potential gains could be substantial. Segregation can improve system reliability, whilst reducing risk and risk management. It can also improve an organisation’s understanding of their system via documentation and development activities, and help with change management, reusability, and testability throughout the software lifecycle.
So ultimately, when considering the application of software segregation to your system, you must first weigh up what level of segregation is truly necessary to benefit your overall project goals.