Software in Medical Devices, by MD101 Consulting - Tag - software failure - CommentsBlog about software medical devices and their regulatory compliance. Main subjects are software validation, IEC 62304, ISO 13485, ISO 14971, CE mark 93/42 directive and 21 CFR part 820.2024-03-27T15:32:28+01:00Cyrille Michaudurn:md5:9c06172e7cd5ed0f5b192883b657eabbDotclearProbability of occurence of a software failure - Aliurn:md5:7e8227ed3f3475cabe2387a313d05a9f2022-02-16T14:50:24+01:002022-02-16T14:50:24+01:00Ali<p>Thank you for this informative post. But I think, in some places you calculated the total probability by multiplication (if the events be dependent, you have to calculate the total probability by conditional probability formulas).</p>What is a Software Unit? - Mitchurn:md5:6ad0b1ad5dd9aab648fe6205597bf3132021-06-12T21:21:52+02:002021-06-12T20:21:52+02:00MitchHi Onni,
Many thanks for your feedback.
Testing SW units without instanciating some other components can be a bit artificial. It's possible sometimes by using mock objects or similar artifacts. But it is very likely that you need some other components to test units the appropriate way. Especially when they depend on general-purpose libraries.What is a Software Unit? - Onniurn:md5:60db907eb4d84245914825b57def471e2021-06-11T13:53:52+02:002021-06-11T12:53:52+02:00Onni<p>Hi Mitch,</p>
<p>I really appreciate the work you have put down to decipher the IEC 62304!</p>
<p>The definition of UNIT seems to imply that a UNIT cannot depend on another UNIT. Also in B.5.4 the standard says "UNITS can be tested separately".</p>
<p>Surely it is good to minimize tight dependencies between UNITS. But how am I supposed to e.g. work with general purpose libraries/modules (which are UNITS on their own)? These libraries are usually used extensively everywhere. The standard seems to categorically mandate that UNITS should be implemented in such way that they can be tested in separation even from general purpose libraries/modules.</p>
<p>Please tell me that there's a less restrictive way to interpret the standard.</p>
<p>Any comments appreciated!</p>What is a Software Unit? - Mitchurn:md5:3e5f172dcb52553751987592893f54c72021-04-20T15:25:46+02:002021-04-20T14:25:46+02:00MitchHi Dan,
Thanks for your feedback and comment.
"It looks here that you are describing something similar to "Component based programming". Is that right?"
IEC 62304 doesn't talk about component-based programming. But it's true that the approach of SW items and SW units is similar to component-based programming.
"Is this article saying that the same approach would be useful for class C embedded medical devices?"
Yes, the same approach would be useful for class C embedded MD, since they are similar.
"Is 62304 saying that we must use Component Based Programming and design for class C medical devices?"
No, this is not written neither in the normative part, nor in the annexes.
"What if the amount of software was closer to being more easily represented using plain classes and OO? Would we still be required to "componentise" the software and add interfaces?"
That's possible to consider that the components are equal to the plain old classes and POO if the embedded SW is tiny enough to make the component level redundant or not useful. To make it short, if your software is tiny enough, you can have software units equal to classes. Then no "composentization" is required.
Hope it helpsWhat is a Software Unit? - Danurn:md5:468b4593119dca4dc21560bbbe3094b92021-04-19T12:17:19+02:002021-04-19T11:17:19+02:00Dan<p>Hi,</p>
<p>Thanks for the articles and the information you share, its great! I think this article is very interesting.</p>
<p>What is not clear to me is, 62304 talks about software units and specifying interfaces. It looks here that you are describing something similar to "Component based programming". Is that right? My understanding of component based programming was that it is useful for large scale enterprise systems and implementing micro-services architectures and such. I have read about it in the Ian Somerville books and in the "UML Component" book by Cheeseman and Daniels. Is this article saying that the same approach would be useful for class C embedded medical devices? Is 62304 saying that we must use Component Based Programming and design for class C medical devices? What if the amount of software was closer to being more easily represented using plain classes and OO? Would we still be required to "componentise" the software and add interfaces?</p>
<p>Thanks again!</p>
<p>Dan</p>Probability of occurence of a software failure - Mitchurn:md5:a8cd1f727b7ae1df5ba1cbe98ce59d932018-02-17T17:02:42+01:002018-02-17T17:03:32+01:00Mitch<p>Hi Hans,</p>
<p>You're right :-) That's the purpose of IEC 62034. But ISO 14971 is there to force you to find mitigation actions specific to your software with top priority for "safety by design".</p>Class A, B and C. Is it possible to reduce the documentation of detailed design of software medical devices? - Mitchurn:md5:731139c74309320a3eb0df0e780646422018-02-17T16:56:02+01:002018-02-17T16:56:02+01:00Mitch<p>Hi Murielle,</p>
<p>The hardware risk control is required to downgrade form C to B or B to A without isolation/segregation. But according to 4.3.d, the segregation can be software/logical or hardware/physical. But you shall bring strong rationale for a logical segregation. Usually, it is better admitted to have logical separation between classes A and B, and physical between C and B.</p>
<p>Bye.</p>Probability of occurence of a software failure - Hansurn:md5:8afac24eedf6e1eb87b65ff13adc1d272018-02-16T22:26:22+01:002018-02-16T22:26:22+01:00Hans<p>Thanks for the article.</p>
<p>Where you wrote "The main mitigation action of risks linked to software failures generated by defects is applying the IEC 62304 standard," I was wondering if "Software developed using IEC 62304" would be documented as the risk control on the hazard analysis.</p>
<p>It seems like this would end up being a risk control for all software-related hazards because all the software would be written to IEC 62304.</p>Class A, B and C. Is it possible to reduce the documentation of detailed design of software medical devices? - Murielleurn:md5:540bfc56fcd2f03177a8bde98a5469162018-01-26T15:06:19+01:002018-02-17T16:49:05+01:00Murielle<p>Thank you for this post<br />
I have a question<br />
You write that the "The isolation may also be physical". So I assume that the interface may be done by software (for exemple with mutex, queue if using an OS).<br />
But when I read EN62304:2006 4.3.a, there is only hardware risk control measure which can reduce the software safety classification.<br />
So the interface can be only physical with consequence to run software items on separate hardware or I'm wrong in comprehension?<br />
Thanks for your response</p>How to differenciate Bugs, Software Risks and Software Failures - Part 1 - Ike Siposurn:md5:fd527310bd5a50f0e7b5af3bee2f3b5a2017-12-19T17:13:24+01:002017-12-28T21:19:01+01:00Ike Sipos<p>Amen for this immensely informative blog. Software bugs can be one of the most infuriating aspects of development. Not to mention the negative backlash that ensues when clients are unhappy. I cherished the level of detail you go into. Thanks again.</p>Class A, B and C. Is it possible to reduce the documentation of detailed design of software medical devices? - Mitchurn:md5:ebe4d8e4190f037be2f7e08ff14a4cf62017-12-08T16:00:41+01:002017-12-08T16:00:41+01:00Mitch<p>Thanks for your feedback.</p>
<p>Yes, it's possible to downgrade from class C to class A with two mitigation actions.</p>Class A, B and C. Is it possible to reduce the documentation of detailed design of software medical devices? - Mathieu Febvayurn:md5:09a67e0aebfc23cfe2a5d1cded2130112017-12-05T17:16:57+01:002017-12-05T17:16:57+01:00Mathieu Febvay<p>Thank you for this trick !</p>
<p>However, when you isolate your software like you did, is the interface manager mandatory class B ?</p>
<p>Is it possible to switch from class C item to class A with risk mitigation measures (CRC and another hardware/software checks the class C item) ? (EN62304:2006 4.3.a explains that is possible to switch from class C to class B AND from class B to class A)</p>
<p>Again, thank you for all your valuable informations.</p>
<p>Mathieu.</p>Probability of occurence of a software failure - Martinurn:md5:e210fd6ce3faf4e3e0314c966020aa802012-12-05T16:06:07+01:002012-12-05T16:06:07+01:00Martin<p>We had the exact same discussion in one of our projects the other day. I usually read new posts on your blog, but I must have missed this one...</p>
<p>btw. I always recommend your blog to people I work with. It's often easier to get them to read this instead of looking into IEC/ISO documents =)</p>