Determination of software safety class (62304) prior to software risk analysis

[jddad19]

Hi,
I'm confused by what seems to be a chicken vs. egg situation in IEC 62304. Per 62304, risk analysis is required to determine whether your software is safety class A, B or C. However, if your safety class is A, according to Section 7 of 62304 you do not need to perform risk analysis for the software. So, how are you supposed to determine your safety classification without performing software risk analysis?

Should I just be considering system-level risks that could be caused general by the software to make this determination, without getting into the details of risks from each software unit?
Thanks

 

[yodon]

The decision tree in 4.3 does not consider software risk controls (at least that's the way I've always understood it). Based on the decision tree, software can only be class A if there are no hazardous situations that can arise from failure of the software. In practice, I think you want to do risk analysis considering the software to provide the rationale for such a claim.

 

[jddad19]

Thank you for your reply and input. That's correct the decision tree does not consider software risk controls. On the second point, it is possible for the software system to be Class A even if it can contribute to hazardous situations, so long as it does not result in unacceptable risk after consideration of risk controls external to the software. It's this point where I feel the catch-22 exists, to make a determination that hazardous situations resulting from the software system cannot result in unacceptable risk seems to require risk analysis, though 62304 Section 7 (where analysis of software contributing to hazardous situations is performed) is not applicable to Class A software.

In reading and thinking about this a little further, perhaps the key is the difference between "software system" (referenced in the 4.3 decision tree) and "software items" referenced in Section 7 for risk management process. I suppose general risks arising from the software at the system level should be used to make the determination of safety class and, subsequently, how deep the risk analysis needs to go (based on determination of safety class)?

 

[Tidge]

I suggest trying to think of the engineering of the complete device as allocating

• functions
• risk controls

Some functions will be allocated to software (and/or hardware), some risk controls will be allocated to software (and/or hardware). Typically the allocation of functions (between software and hardware) is known at the concept phase. There can be an allocation of risk controls at the concept phase, but as a practical matter the full suite of necessary risk controls won't be identified until there are device outputs ready for verification... some design choices are (more) prone to certain failure modes than different design choices.

In case where the software failure would result in unacceptable risk, if the control for that risk is allocated to something outside the software (and the external control is effective), then it is possible that even if the software fails that the risks are acceptable.