"But it all becomes Class C?!?"

"But it all becomes Class C?!?" - IEC 62304, software architecture and Software safety classification

During a seminar some time ago, I elaborated on the possibility of using existing risk assessments to deduce the software safety classification (SSC) of the software architecture parts according to IEC 62304 (see the slides here).

My discussion was based on the Matrix Model, initially published by the company "Certified Compliance Solutions". The essence of the deduction goes like this:

• IEC 62304 does not stipulate an explicit traceability relationship between the SW requirements and the architecture.
• The Software Safety Classification of each software item/unit is based on the potential harm that (hypothetical errors in) the item/unit might produce.
• Risk originates not from the software item itself, but from the functional context in which it is used. If a GUI component displays printer settings, then the risk is low. If the GUI component displays the real-time EEG, then the risk is high.

So how can the risks emanating from the functional context often documented in SW requirements, be transposed to the SCC of the Software Architecture.

The company “Certified Compliance Solutions” ties these concepts together by applying the so-called "Matrix model" to functional workflows and the software architecture. The approach is best explained in the picture below.

The idea is to establish/document use-cases for all SW Requirements and perform a risk assessment on these Use Cases to establish the worst possible harm they might cause.

This gives each Use-case a "functional" Safety Classification.

On the X-axis, we enumerate all Software Items/Units in our architecture.

It should now be possible to single out the set of Software Items/Units a particular Use-case needs/uses for its implementation.

The functional safety class for the Use-case can then be transferred to all the Software Items/Units needed for its implementation. Repeat this process for all Use-cases.

The highest occurring Software Safety Classification in each column represents the Software Safety Classification for the Software Item/Unit of that column.

(Be aware: A Use-case usually does not cause the same risk for each step of the workflow. Some steps generate higher risks than others. The Matrix Model does not account for this.) 

"But then all becomes of Class C?!?" - exclaims a young man in the audience.

Now, this is a valid observation and a phenomenon we see from time to time.

Risk-driven development is one of the underlying reasons for IEC 62304. The manufacturer should focus development efforts on the software parts that pose the highest risks.

The Software Safety Classification-concept is used to detect these software parts. More risk => more effort required to ensure safety.

However, manufacturers sometimes seem overburdened with the ins-and-outs of the regulation and therefore capitulates to the approach of "just smack class C (or class B) on everything and get it over with".

I think there are several reasons for ending up in this situation and these reasons should not be confused with each other. They each have different causes and different remedies.

Defunct Architecture

The first potential reason lies in the selected software architecture.

If, after having applied the Matrix Model, it turns out that all Software Items/unit indeed receive the highest possible software safety class, then this is might indicate a particularly entangled design with insufficient separation of concerns.

The Matrix Model should give an indication of high-risk Use Cases that span across wide parts of the architecture.

The scope of these use cases might be too large. Reconsidering the scope and aiming for a more risk-driven division of the workflows could lead to some important decomposition gains. 

Or maybe the decomposition of the architecture is insufficient. Further decomposition and/or segregation of software items can potentially confine high-risk aspects of the software to dedicated areas.

Bad Processes

A second and completely different reason for "everything turning into class C" lies in the administrative overhead of separating the work needed for each Software Item according to its Software Safety Classification. This point-of-view advocates that it is simply less work to treat every software item uniformly from an administrative perspective regardless of the actual risk of the software items is lower than nominally designated risk.

This indicates that something is foul in the development process and/or documentation system. IEC 62304 gives the manufacturer the possibility to perform efficient development, allowing redistribution of resources from low-risk areas to high-risk areas of the software. That opportunity is foregone in this scenario.

A well-adapted development process and supporting tool-set shall make sure that the following things are in place:

• An easy-to-understand, formalized technique to correctly deduce the Software Safety Classification from Risk assessments.
• Automatic checks to verify that the software architecture is valid from a Software Safety Classification perspective.
• Clear designation of necessary and sufficient tasks to comply with IEC 62304 given the SSC for the particular item.

The Matrix Model is right

The third reason for this phenomenon is, of course, that the result is entirely warranted. The Matrix Model might actually correctly show that the entire software DOES carry a risk for death or serious injury to the patient and/or user. If this is the case, the model has served its purpose.

Safety and Quality first

Last but not least, your development process might be more ambitious than what IEC 62304 requires. This is entirely OK. IEC 62304 establishes the most basic requirements to ensure that the software is developed with safety in mind. Raising the bar further by applying even more rigorous development requirements with regards to safety might very well be warranted for companies that put safety and quality first. 

Learn more about how Aligned Elements can help you support IEC 62304

Request a live demo and let us show you how Aligned Elements can help you to comply to IEC 62304