Software as risk control - Confused on one aspect of IEC 62304

david316

Involved In Discussions
Hello,

I am a little confused on one aspect of 62304. If I have a class C system and I use software as part of a risk control (e.g. an alarm due to loss of some critical function), I need to develop the software item in accordance with Clause 5. Assuming I develop the software item according to the requirements of 62304, when completing a post mitigation risk assessment, can I assume my software risk control works or do I need to assume it never works (i.e. probability of failure is 1).

For example, maybe consider an alarm with software involved that detects a loss of mains power to a device. When looking at whether the software has successfully helped make the risk acceptable can I assume it works 100% of the time or do I need to assume it never works (which seems silly) or is there some middle ground? The standard isn't very clear on this.

Thanks
 

sagai

Quite Involved in Discussions
Probability of software fails is 100% for me.
It's even worst ( :bonk:could it be? ) because the hardware that it is running on also could fail on a way that it looks that software failed.

For arguement, I am happy to listent of the resolution of the Halting problem first :D

Regards
Szabolcs
 

glork98

Involved In Discussions
..can I assume my software risk control works or do I need to assume it never works (i.e. probability of failure is 1).

(Alternate position!)

Yes. The 100% failure is raw code without any testing, inspection or other quality practices. Code developed under good practices will have a lower defect rate compared to what would be produced with no practices. This can appropriately be reflected in the risk analysis.

So... It is up to the SW staff to work with Quality Assurance to establish how the Risk Analysis is done. Impress on them that applying B & C practices decrease defect rates and is itself a mitigation.

What may help is to find studies that show defect discovery for each level of practice and then use that. In a dFMEA I drop the occurrence from a "Frequent" to a "Occasional" (5 of 5 to a 3) and see if more mitigation is needed.

Without this, it becomes impossible to actually make a product that has an intrinsic patient risk using software for control functions. The new layers of (mostly) hardware mitigations create their own risks and there simply can't be mitigations for all software problems without creating an analog computer.


You're welcome.
 

david316

Involved In Discussions
Is a conservative approach that to say, even if we assume the alarm fails with 100% probability due to software, its state of the art as we follow IEC 62304. We also follow the appropriate particular standard, we have other risk mitigators in place (e.g. a warning to have a backup device available), etc. The risk is as low as practically possible. In this case, even if the risk is deemed unacceptable, as we assume the alarm never works, and the other risk mitigators don't make the risk acceptable, then via a risk vs benefit analysis the risk is acceptable.
 

sagai

Quite Involved in Discussions
So, coming back to this power loss alarm.

My opinion ...
Software does not detect power loss.
It is the electronics that in a micro secund timescale can detect the unacceptable degradation of the current that probably will lead to power loss in future. Than it signals it to micro controller/processor or to logic unit. So a software that runs on it or the logic gate array sits on it kicks in and triggers an alarm/signal/whatever that indicates the current degradation on power board/logic unit.
Therefore I would do FMEDA (diagnostic FMEA) for the section of the electronics that is for indicating current degradation, FTA for this function.
So than you will see the reliability of this particular safety related function.

So it is not the software I think in this case.

Regards
Szabolcs
 

david316

Involved In Discussions
The software doesn't detect the loss of power but surely you need to consider the fact that the software will be responsible for displaying the alarm on the device and controlling the output to the speaker, etc. If the software in the alarm system fails there will be no alarm.
 

sagai

Quite Involved in Discussions
So, software is solely one of the many leaves on the fault tree of the funtion of indicating power loss. Probability of failure of this leaf that is for software piece 100%.
There are many other leaves of this fault tree for electronics function block where probability determined by FMEDA.

Reasoning of risk acceptance is incomplete without building and evaluating this fault tree first.

Regards
 

david316

Involved In Discussions
Sure, although the software is like the trunk. If you assume that the software in the alarm system fails 100% of the time, none of the other probabilities matter...the alarm will not function 100% of the time.
 

sagai

Quite Involved in Discussions
Slowly, we are getting there. :)

It should not be like that.
It should not be that software functions demolish the reliability of your safety function ( in this particular case to indicate if there is a potential of unacceptable power loss).

Fault tree brunches with leaves ( leaf = probabilities of the identified failure event ) having “AND” relations multiplies the probabilities (less than 100% if there are other event than software function), therefore if your system architecture built up or re-designed on such a way that either your software one of many parallel events those lead to failure or you are having diagnostic function next to the main function, then your safety function will have better than ‘always and any time’ may fail characteristics.

Hoping this helps ...

Regards
 

david316

Involved In Discussions
Maybe we are getting there .... but still not at the desired destination :). In terms of probability of harm to a patient if you did a fault tree you could end up with one of the nodes being something like:

Probability of serious harm to patient (one possible node) =
Probability of power plug accidentally pulled from socket (0.01) *
probability of not being noticed (0.5) *
probability of alarm failing to operate (1.0) *
probability alarm not acted on (1.0) *
probability that loss of therapy would result in serious harm to patient (0.1)

Admittedly this is based on my understanding of fault trees rather than having experience doing them :). The thing is, in this example if you assume software will fail with 100% of the time then the alarm is useless. The only solution is not having any software involved in the alarm system which seems unpractical. Even if you put the alarm system in its own dedicated processor if you have to assume 100% probability of failure I can't see how this would help.... Hopefully I will have a light bulb moment at some point.....I'm not sure what I am missing...

Actually, I have realised that the power out alarm is probably not the best example for my initial post because its had to think of a software fault that would cause a power out. A better example might be

Probability of serious harm to patient (one possible node) =
Probability of software bug cause device to shut-down (1.0) *
probability of device shutdown not being detected by user (0.5) *
probability of alarm system which detects device shut down failing to operate (1.0) *
probability that loss of therapy would result in serious harm to patient (0.1)

As before the alarm is useless if we need to assume 100% probability that the software as part of the alarm system fails which means the alarm is pointless which doesn't seem right.
 
Last edited:
Top Bottom