Re: Selecting embedded Linux for a new medical device project (LONG)
- From: "DavidK" <PleaseReplyTo@xxxxxxxxxxxxxx>
- Date: Thu, 4 Oct 2007 21:23:06 -0700
"Janaka" <janakas@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 giveshttp://groups.google.com.au/group/comp.os.linux.embedded/browse_frm/thread/aa080701ded96de3/e33dfb197f4e8cbe?hl=en&lnk=st&q=&rnum=20#e33dfb197f4e8cbe
some more info if you are interested on how some others will use Linux
in medical devices or how I would use it.
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
.
- Follow-Ups:
- Re: Selecting embedded Linux for a new medical device project (LONG)
- From: Michael Schnell
- Re: Selecting embedded Linux for a new medical device project (LONG)
- From: Janaka
- Re: Selecting embedded Linux for a new medical device project (LONG)
- 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
|