Re: Selecting embedded Linux for a new medical device project (LONG)
- From: Janaka <janakas@xxxxxxxxxxxx>
- Date: Thu, 04 Oct 2007 21:51:00 -0700
On Oct 5, 2:23 pm, "DavidK" <PleaseRepl...@xxxxxxxxxxxxxx> wrote:
"Janaka" <jana...@xxxxxxxxxxxx> wrote in message > In my humble opinion; I
would not use embedded Linux as the critical> operating system for a safety critical system. Following thread gives
some more info if you are interested on how some others will use Linux
in medical devices or how I would use it.
http://groups.google.com.au/group/comp.os.linux.embedded/browse_frm/t...
Don't get me wrong, I am a big advocate of open source and Linux.
However we are talking about the safety of someone here. Personally I
would make the safetly critical parts of any system as simple as
possible. Possibly using HW circuit, FPGA/PLD or bonafied (and safety
critical tested) RTOS to control it. And use Linux to provide all the
bells and whistles, like GUI/UI, network access, data streaming,
remote operation and data storage.
Reasons are that I think Embedded Linux is too generic and too
highlevel for a safety critical system. And if something goes wrong
it will be harder to track because of the complexity and also as you
increase the complexity, the points of failure becomes greater. And
you will most likely spend more money verifying and getting linux up
to a safety critical standard. On the other hand if you use a
certified safety critical RTOS (there are a few of them around ) you
will get a big initial licensing cost and a smaller product
certification and verification costs.
If you decide to go with Linux you will probably have to branch off
from the Linux main source and that means you take away one of the
advantages of using Linux.
Please let me know if any opposing arguments.
Cheers
J
P.S. Another bit of advice; I wouldn't go for a x86 architecture for
the CPU because they dont have long production lifespans. Which means
you'll have to replace the CPU every few years, and hence get each new
HW revision re-tested for medical use. Given that medical devices
takes few years to go through product to market, you might get stuck
with a never ending cycle.
Thanks for the link and the thoughtful response. You have many excellent
points, especially about keeping the design as simple as possible to
minimize the places where things can go wrong.
For brevity, I didn't mention all of the system's functions. To mitigate
the possibility of runaway/crashed code from harming the patient, our
hardware will include watchdog circuits and output-power-limiting controls.
And a large portion of the software will be dedicated to sensor monitoring
and error detection/handling, to help ensure patient safety. Finally, the
doctor has the "last word" by using the footswitch, which is not only
monitored by the software but also directly enables/disables the
power-generation circuits, so if something doesn't seem right during
treatment, the doctor can simply lift his foot off the footswitch.
Thanks again for your input. I'm also considering other RTOSes; embedded
Linux is just one of the possibilities. I'm hoping to hear opinions and
pros/cons from people who have actually used embedded Linux in a device
control context.
DK
Having said all that, we are currently developing a embedded Linux
based medical imaging device. We are not using Linux for any of the
safety critical sections, but using it for a high reliability central
control unit. We have selected the Denx ELDK (and Uboot) as the
embedded Linux distribution and this has saved us a lot of time in
developing generic capabilities such as USB2, Ethernet, Serial comms,
Flash access and a few applications layer tools.
.
- References:
- Prev by Date: Re: Selecting embedded Linux for a new medical device project (LONG)
- Next by Date: Re: Selecting embedded Linux for a new medical device project (LONG)
- Previous by thread: Re: Selecting embedded Linux for a new medical device project (LONG)
- Next by thread: Re: Selecting embedded Linux for a new medical device project (LONG)
- Index(es):
Relevant Pages
|
