Home > On-Demand Archives > Q&A Sessions >

Live Q&A - A Medical Device Primer for Embedded Software Engineers

Jeff Gable - Watch Now - EOC 2023 - Duration: 25:12

Live Q&A - A Medical Device Primer for Embedded Software Engineers
Jeff Gable
Live Q&A with Jeff Gable for the talk titled A Medical Device Primer for Embedded Software Engineers
italicssurround text with
boldsurround text with
**two asterisks**
or just a bare URL
surround text with
strikethroughsurround text with
~~two tilde characters~~
prefix with

Score: 0 | 10 months ago | 1 reply

Hi Jeff, thanks for a great presentation :) I recently joined a company working on medical devices and have been trying to rapidly familiarise myself these standards. It's quite interesting how some software techniques - such as unit testing and CI - have been pioneered in industries which are generally not seen as "safety critical". I think you explained clearly what the thoughts on this have been and why they are changing.
Cheers, Tim

Jeff GableSpeaker
Score: 0 | 10 months ago | no reply

Thanks Tim! Thankfully attitudes are changing -- I remember hearing people say "You can't use X because it's not validated for medical" when any reasonable, informed person would understand that the quality of the final product would be improved, sometimes greatly so, by using X. There's still a lot of inertia from those years.

Score: 0 | 1 year ago | 2 replies

Hi Jeff,
Thank you for such a well-researched and informative presentation. I will hang on to your slides for dear life! Also, I didn't realize that you have so many good resources on your website.
I have a question about certification for off-the-shelf software similar to an RTOS. That software is generic and medical device vendors integrate it with their application software for specific products. How shall I approach the Hazard & Risk Analysis in this case, for example? I understand that you cannot provide here any detailed answers, but perhaps you could outline a general strategy. (I mean, integrating something like an RTOS should be fairly common.) Also, what kind of documentation would be most useful and time-saving for the customers of such software? Perhaps you could point me to some resources that I could buy, borrow, or steal.
Thanks a lot!

Score: 0 | 1 year ago | 1 reply

I was thinking similarly while listening to Mohamed Billoo's talk on Zephyr. I would approach it as a SOUP component in the terminilogy of IEC 62304 -- a Third Party Software Component in the terminology used in "Medical Device Cybersecurity for Engineers and Manufacturers" (A better term in my book). I would still have to write tests for the functionality I include, right? So if I include a USB driver on my Zephyr config, how extensively must I verify that subsystem? That could end up being very expensive! Or do I need to simply test for the functionality (and associated failures identified in my Risk Analysis) that I will use for my device?

Yes, I'm interested in how you'd approach your RTOS and vendor libraries, for example.

Jeff GableSpeaker
Score: 0 | 1 year ago | 1 reply

As extensively as necessary to satisfy yourself that it doesn't pose risk of harm! What harm comes if that USB driver fails in some way? For instance, if I have a user interface implemented on a tablet, and it's communicating with a hard-real-time application running on a microcontroller over USB, then the microcontroller code needs to be able to go to safe state as appropriate if it loses communication with the user interface. Which is something you'd need anyway, regardless of the form of communication. This covers any failure of the USB SOUP code. That one mitigation (go to safe state on loss of communications with the user interface, checked with periodic messages at the "application" level of the comm stack) is sufficient to mitigate many different possible failures. Make sense?

Score: 0 | 1 year ago | no reply

Makes sense.
My mind was harkening back to a USB driver for a DO-178C Level B project with a USB driver on a μC/OS-II runtime. When we looked at the complexity of writing unit tests for coverage, it became a daunting task -- and ultimately killed the project. Thankfully, it's very unlikely that my USB driver will be in a class 3 safety level module -- and the FDA doesn't specify decision coverage or condition coverage requirements.

This is one way that Medical Device is actually less stringent than aerospace.

Jeff GableSpeaker
Score: 0 | 1 year ago | no reply

Hi Miro, thanks for the great question. I realize that I promised you such a conversation a long time ago when you came on the Agile Embedded podcast, and we never had it!

You can see an example of what a RTOS supplier promises in their "safety certification package" here: https://www.plm.automation.siemens.com/global/en/products/embedded/nucleus-safetycert.html

Basically, they provide all the documents that are specified by IEC 62304. Since they (and presumably you, with the QP frameworks) want to target all safety-critical industries, not just medical, they will have documentation packages that reflect the unique requirements of each industry's particular safety standard (ISO 26262 for automotive, DO-178C for aerospace, etc).
There is a great deal of overlap in the requirements of all these standards. They would just format those documents according to each industry so they are easy to consume.

For the Hazard and Risk Analysis, there are two parts. First is the process you follow to make sure that your library (QP and its siblings) meets its requirements, and the documentation of all the risks you can think of internal to your software and how you mitigate them. Second is a "Safety Manual" which tells your customers/users what THEY must do when incorporating your software into theirs.

  • Check return values and react appropriately (common sense, yes, but good to specify)
  • Monitor event queue usage and ensure no overflow (as you mention, this is just as bad for Actor Model software as stack or heap overflow is for an RTOS)

I'm happy to talk again offline and go into specifics that fit your particular case.

Score: 0 | 1 year ago | 1 reply

Jeff, Thank you for a well ordered and fairly comprehensive overview of Medical Device development. You hit the nail omn the head over and over again with your comments on less-then-good practices you see -- I see many of the same.

I think this presentation could benefit from a reformation of the classic IEC 62304 process diagram. Something with that line of chevrons wrapping around on themselves and repeated per feature... per cycle. I think of Agile Medical Device Development in terms of many iterations of mini-V models, sometimes with some larger cycles at a slower pace.

I appreciate your methodical and well-ordered presentation -- it almost makes medical deveice development seem easy. :-)

Hope to be there tomorrow for Q&A.

Jeff GableSpeaker
Score: 0 | 1 year ago | no reply

Thanks for the kind words!
We mirrored your thoughts exactly on a recent episode of the Agile Embedded Podcast -- "Agile vs V-Model". The V-Model captures all the steps necessary to develop quality software, but you should never use it to describe the timing or sequence of those activities at the project level. It's great when you use the V-model many many times in an iterative fashion, per feature, per change, per cycle.

Listen to that episode here:

Like I said in the Q&A, I wouldn't describe medical device development as "easy", but I do want to convey that it is "NOT MAGIC". It is a skill that can be learned and cultivated.

16:34:09	 From  Quantum Leaps : In your presentation you mentioned tools for requirements traceability. What are some of such tools popular among your customers in the medical business?
16:36:15	 From  Quantum Leaps : Also, speaking of tools, which static analysis tools are popular in medical?
16:36:27	 From  Quantum Leaps : Also, how important is MISRA-C compliance?
16:37:36	 From  Quantum Leaps : What do you think if HTML documentation? Would this be accepted?
16:38:31	 From  Dan Rittersdorf : Risk Analysis for Safety and Security are similar but not the same process.    How resks are scored for Safety and Security is different.   Verification for Cybersecurity requires a certain skillset also.   Either way, those that do it need to be able to prove they're competent.    What are some ways to get that training for each type of Risk Analysis, and what's re3ally needed to prove competence?

Can you recommend training resources?   Other ways to become and prove competence?
16:40:24	 From  Kate Stewart : Have you started seeing requests for SBOM generation?
16:42:04	 From  René Andrés Ayoroa : Hi Jeff, what do you think are required skills for junior embedded developers to get in the medical industry?
16:42:22	 From  Aaron Olowin : How detailed do your own processes need to be documented and is there a preferred format for that?
16:43:00	 From  BobF : Validation of any RTOS choice must be a headache - requires a significantly high level of due diligence?
16:43:25	 From  Dan Rittersdorf : Replying to "Risk Analysis for Sa..."

16:44:29	 From  Quantum Leaps : How to help customers in generation of SBOM? Would the provision of SPDX-License-Identifier in the source code be helpful? Would it be sufficient?
16:44:52	 From  Kate Stewart : Side note:   1 config option change will create auto generated SPDX SBOMs for the entire build (including toolchain) for Yocto.
16:46:33	 From  Dan Rittersdorf : Comment: The FDA is already requiring Cybersecurity plans now.   They're just handholding companies through the process between now and October.    No free pass even now, but in October, the handholding will turn into RTA letters.
16:49:44	 From  Kate Stewart : Also SBOMs for Zephyr:  see https://docs.zephyrproject.org/latest/develop/west/zephyr-cmds.html#software-bill-of-materials-west-spdx and video overview at https://www.zephyrproject.org/generating-sboms-for-iot-at-build-time/
16:49:56	 From  BobF : Rings a bell .... 100% deterministic
16:50:56	 From  Quantum Leaps : SafeRTOS comes from Wittenstein High Integrity Systems
16:53:51	 From  Aaron Olowin : The time-triggered OS is likely based on: https://www.safetty.net/publications
16:54:25	 From  BobF : Got it !
16:54:36	 From  Quantum Leaps : Do you see state machines used in medical?
16:55:16	 From  Keith J : agree - plan to use Miro's stuff in my next project
16:55:20	 From  Keith J : albeit non-medical :D
16:55:36	 From  Keith J : Thanks again Jeff!
16:56:06	 From  Quantum Leaps : Yes, thank you, Jeff!
16:56:07	 From  René Andrés Ayoroa : Thank you Jeff.
16:56:08	 From  Doinita Marcu : Thank you!
16:56:11	 From  Aaron Olowin : Thanks Jeff! Your podcast is good too.
16:56:21	 From  Dan Rittersdorf : Thank you, Jeff!
16:56:30	 From  Keith J : keep the podcast coming!
16:56:44	 From  Stephane   to   Jeff Gable(Direct Message) : Thank you Jeff!!!
16:56:48	 From  BobF : Very much about being on the ball, thanks!