Search the Elsmar Cove!
**Search ALL of Elsmar.com** with DuckDuckGo including content not in the forum - Search results with No ads.

Reduction of software class based on multiple external risk controls

david316

Involved In Discussions
#1
Hello all,

In 62304 you are allowed to reduce a software class by the use of external risk controls (clause 4.3). For example the flow-chart allows you to reduce a class C software item to class A with the use of an external risk controls. If the risk control contains software, it inherits the software classification based on the risk it is preventing (clause 7.2.2). Therfore the original software item would be class A and the external risk control would be class C. Can anyone provide guidance on what the software classification should be if you have 2 independent external risk controls that contain software? Which is correct below?

1)
-Origianl software item that can cause serious harm (assigned class A based on external risk control)
-First external risk control (assigned class C based on risk of original software item)
-Second external risk control (assigned class A as it is not needed and isn't considered to provide any meaningful additional safety)

2)
-Origianl software item that can cause serious harm (assigned class A based on external risk control)
-First external risk control (assigned class A based on the fact that there is a second independent external risk control, so if this risk control failure there is redundacy)
-Second external risk control (assigned class A based on the fact that there is a second independent external risk control, so if this risk control failure there is redundacy)

Thank you for any guidance
 

yodon

Staff member
Super Moderator
#2
I've been struggling with how to reply to this. I don't think the path is completely clear.

I could use a bit of clarification: you have 3 software items? The "original" software + 2 software items providing risk controls (maybe among other things)?

From experience, auditors / reviewers are a bit challenged with this down-classification process. While the standard allows it, in practice, it seems that the class for at least one of the software items will need to line up with the product risk; i.e., if you have a product that can cause death, at least one software item will be expected to be Class C. Not saying that's right (by what the standard says), just providing a heads up on what I've experienced.

If it were me, I'd probably go with the original software as Class C and, if justifiable, down-classing the other items. That's no guarantee the lower classes for the other items will be accepted but you might be in a more defensible position. Your architecture will need to show that they are suitably isolated.
 

david316

Involved In Discussions
#3
Yes, 3 software items. An example might be system with 3 micro controllers. One controls the system. The other two implement risk controls. All are independent from each other. The controller without the two independent risk controllers is class C.
 

Tidge

Involved In Discussions
#4
Please heed the yodon advice about the architecture showing the isolation of the software elements. It has been my experience that the architecture is the absolute best way to describe the allocation of functions (including risk controls) if there are elements of a 62304-compliant process are going to be skipped (for some areas of the software) because of a lower safety classification. Keep in mind the notes about decomposition and segregation of software items in clause 4.3.

Generally: I'm not a fan of down-classification based on the evaluation of effectiveness of external (to software) control measures for two reasons.

The first reason is that the FDA guidance is explicit that their "level of concern" for software cannot consider risk control measures. The three-tier "Level of Concern" is not the same as the three-tier "Software Safety Classification", but the expected deliverables for each tier practically align.

The second reason is that (in my experience) the evaluation of effectiveness of non-software risk control measures could take quite some (development) time, and it would be a huge time waste to delay 62304 development activities while you wait for that evaluations of the non-software risk control measures. I can understand the appeal of saving time by avoiding unnecessary activities, but my experience has been that software and hardware develop in parallel and it would be peculiar to delay development of software until hardware was done (to the point of demonstrating the effectiveness of risk controls) and the hardware team would probably be anxious about having to implement hardware risk controls because (for example) the software development team wasn't going to (or could not) place configuration items under configuration management control.

The informative text of 62304 (Annex B) has a lot of text discussing segregation of software items vis-a-vis risks but does not do a good job (IMHO) of explaining the 'process box' and the subsequent decision point in the image of clause 4.3. I also don't think the informative text provides any illumination to the text of how a software system safety classification can be 'subsequently assigned a new software safety classification' or the text of Note 1. I know the 62304 standard is under review; it is my hope that this section (and the informative text) gets cleaned up. To be frank: suggesting that a 'health care procedure' could free a manufacturer from the need to categorize software defects (see 5.1.12 as not required for class A) is absurd.
 

david316

Involved In Discussions
#6
FYI. The draft of the new edition of 62304 is quite explicit that a risk control needs to inherit the risk of the original item being mitigated.... no matter the amount of risk controls.

"It has been asked how to assign software safety classifiction for SOFTWARE SYSTEMS that utilize redundancy or diversity to achieve the desired level of SAFETY. In both cases, one of the SOFTWARE SYSTEMS is obligated to take responsibility for the implementation of the RISK CONTROL measure (taking a higher software safety classification based on the RISK being controlled). In the case of redundancy, the arguement that each SOFTWARE SYSTEM has an external risk control measure (pointing to the other SOFTWARE SYSTEM) and therfore each are software safety class A is not logical because one of the SOFTWARE SYSTEMS is obligated to take responsibility for the RISK being controlled."
 
Top Bottom