Selecting embedded Linux for a new medical device project (LONG)

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Hi,

I've just begun working on a new project for a medical device, and I'm in
the early stages of deciding which RTOS we'll use.

To summarize the device, it's a medical device that will have a graphical
user interface (and possibly a touchscreen), a control knob to set the power
level, a footswitch, an RF power generator, and an 'applicator' that's
connected to the system by a long cable.

The doctor will use the device by setting the desired power level using the
knob (the knob position is read by the software), and when the footswitch is
pressed, the device will deliver the appropriate level of RF energy to the
patient via an applicator.  During the 'treatment', the device will display
the setpoint power level, the measured power level, the time in seconds
since the treatment was started, and the temperature of the patient's tissue
that's being 'treated'.  The device will emit a beep tone every three
seconds during 'treatment' to indicate that RF energy is being applied.
When the doctor deems the 'treatment' is complete, he will release the
footswitch, and the RF power will be turned off.  Data aquisition
(temperature and measured power level) will be performed every 10ms or so.

Of course the final device, including its software, will be run through
rigorous testing and clinical trials as required by the US FDA.  But it
would be nice to select an operating system that has been used successfully
in safety-critical (such as medical) applications, so that I won't be the
first one going down that road with the OS we select.

At this stage, we have not decided which CPU will be used, but I suspect it
will be a single-board computer (such as a PC/104 form factor) with an Intel
x86 or compatible processor.

I am considering using embedded / RT Linux for this project, to help keep
costs down by avoiding operating system per-copy royalty charges.  How
should I go about selecting a particular distro or Linux?  I was reading
about uCLinux, but it doesn't seem to have been ported to Intel x86 CPUs
yet.

Any links or tips in selecting a particular version of Linux is appreciated!

David K


Re: Selecting embedded Linux for a new medical device project (LONG)
David,

Quoted text here. Click to load it

Consider that this target does not use any SMM (System Management Mode)
services in the background. If it does so, your RT OS (whatever you will
select) *will* fail. The SMM always has the highest priority in your
system, and cannot controlled by your OS! So the OS cannot ensure any
latency.
 
Quoted text here. Click to load it

If you will use an x86 based system, there is no need for uCLinux. You *can*
use any regular distribution. But you better should select one for embedded
purposes. Its easier to handle in your case.

BTW: Linux + Realtime:
http://rt.wiki.kernel.org/index.php/Main_Page

Patches you will find here:
http://www.kernel.org/pub/linux/kernel/projects/rt /

There is also a RT-Preempt specific maillist
( snipped-for-privacy@vger.kernel.org). Maybe you could ask your question there
again. Especially about your use in a medical environment.

Juergen

Re: Selecting embedded Linux for a new medical device project (LONG)


Quoted text here. Click to load it

Ya. RTLinux supports wel for this type of applications. FYI, In
RTLinux, we have 2 major versions, one is Open source RTLinux and
commercial version RTLinuxPro. If you will prepare Open source
RTLinux, then you need to learn more in this RTLinux, before you enter
into Open source RTLInux. If you like to get some supports and extra
components in RTLInux, then you can preapre RTLinuxPro from Windriver
[Early FSM Labs]. Its affordable for your application.
And you just consider this eCos also, http://ecos.sourceware.org/ and
http://ecos.sourceware.org/hardware.html
I dont thing, uclinux will suitable for this application.

-Prakash.


Re: Selecting embedded Linux for a new medical device project (LONG)
Quoted text here. Click to load it

IMHO a x86 CPU is much too high performance level and not enough "long
living chip-design" for this "deeply embedded" application.

I would first look at what hardware is useful for the application. If
there is a need for an FPGA, you can look at stuff like NIOS or
Microblaze, that can be programmed in the FPGA without the need for
additional hardware.

-Michael

Re: Selecting embedded Linux for a new medical device project (LONG)
Thanks Michael for the excellent info and for opening my eyes to soft-core
CPU technology using FPGAs.

It looks like a flexible and lower-cost alternative to using a single-board
computer, though my unfamiliarity with it makes me a little shy about
recommending it for our new product.  I'll do more online research, and will
add it to our list of hardware possibilities for this project.

DK

Quoted text here. Click to load it
it
Intel


Re: Selecting embedded Linux for a new medical device project (LONG)

Quoted text here. Click to load it
Don't know if you need hard real time system, if not try your own
distriution - I've been using snap gear to building one
http://www.snapgear.org/snapgear/faq.html

Re: Selecting embedded Linux for a new medical device project (LONG)
Quoted text here. Click to load it

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/thread/aa080701ded96de3/e33dfb197f4e8cbe?hl=en&lnk=st&q=&rnum20%#e33dfb197f4e8cbe

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.


Re: Selecting embedded Linux for a new medical device project (LONG)

would not use embedded Linux as the critical
Quoted text here. Click to load it
http://groups.google.com.au/group/comp.os.linux.embedded/browse_frm/thread/aa080701ded96de3/e33dfb197f4e8cbe?hl=en&lnk=st&q=&rnum20%#e33dfb197f4e8cbe
Quoted text here. Click to load it

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


Re: Selecting embedded Linux for a new medical device project (LONG)
Quoted text here. Click to load it
critical system.  Following thread gives
Quoted text here. Click to load it

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.


Re: Selecting embedded Linux for a new medical device project (LONG)
Thus IMHO using an FPGA would be the most intelligent choice. Here you
can create any "Hardware" you want (including as sophisticated watch
dogs as necessary) and you can include a 32 bit processor (e.g. NIOS
with an Altera FPGA) with nearly no additional cost. You can use µCLinux
(or one of about 10 other) OS and do the critical stuff in hardware.

You even can put two processors in the FPGA (one running Linux and one
for critical stuff) if appropriate. Of course you should use some
external watchdog device.

The "hardware" and the "firmware" can mutually watch each other for
safety. Of course you should add some simple external watchdog device do
do a reset and shut down any harmful hardware. I use a small PIC
processor for this purpose.

-Michael

Re: Selecting embedded Linux for a new medical device project (LONG)

Quoted text here. Click to load it
Hi David,

Interesting project. Your company costs will be dominated by the
approvals and testing time. Everything else will disappear, in relation
to those.

You don't give much information. The only timing info you gave was 3
seconds for a beep and 10 ms for a input check. If those are your only
constraints I would consider a 8051 or a PIC with no operating system.

Why do we use an operating system at all and a RTOS in particular? To
allocate resources; sometimes control response time, cpu availability
etc. The big plus with an OS is I/O. Display drivers, control input
drivers, higher level things like tcp/ip or usb really need a decent OS.

If all you are doing is reading a pot for the foot control and doing
other similar, slow timing a much smaller no-os cpu is indicated. It
will make your testing much easier.

Regards, Steve



Re: Selecting embedded Linux for a new medical device project (LONG)
Thanks for your input, Steve.  You're right-on regarding the cost of FDA
approvals and clinical trials.

I did over-simplify the description of our project, in order to keep this
post from becoming a software specification in itself.

We'll use an RTOS because we'll have several tasks/threads running, in order
to keep the design modular, so that some modules can be reused in a future
scaled-up or scaled-down product.  Our system will have a cooling system
that's  controlled by a PID algorithm, as well as other heating elements
that we're switching on and off based on thermistor reading inputs.  Along
with the previously-mentioned touchscreen and footswitch inputs, and the GUI
screen output (where we'll be displaying time, temperature and power
output), it's easiest to break these up into separate tasks that have just
one thing to handle each.

We'll also be logging treatment data to a hard disk or disk-on-chip (or
memory card), which is indispensable during clinical trials.  Finally, the
device will have a Setup and Calibration Mode whereby we can tweak treatment
parameters while we're running tests in our lab environment.

Dave


Quoted text here. Click to load it


Re: Selecting embedded Linux for a new medical device project (LONG)
Quoted text here. Click to load it

IMHO, long-time product management and flexibility is another argument
for using an FPGA with a built-in processor running Linux.

OTOH Development will be more demanding, as you need to do both firmware
development (in C) and "hardware"-development in VHDL.

If you decide not to use Linux, there are similar options using "virtual
peripherals with a modern "multi-threading" CPU. Here you only need to do C.

-Michael

Re: Selecting embedded Linux for a new medical device project (LONG)
Quoted text here. Click to load it

It looks to me that  you can solve your control problem in a small
Microcontroller
connected to a display unit which does not need to have any real time.

1 ADC channel to measure "knob".
1 ADC channel to measure temperature over NTC
1 Digital input to measure footswitch
1 Timer for beeper.
1 black box to generate RF power. (SPI?)
1 black box for applicator (What's an applicator?)
1 Communication channel to display unit.
   1 measurement cycle per 10 ms.
   115,200 BAUD UART => 115 characters per cycle
   You need to transmit
    * setpoint power level (2 bytes)
    * the measured power level (2 bytes)
    * the time in seconds since the treatment was started    (2 bytes)
(Assume shorter than 16 hours)
    * Temperature  (2 bytes)
SPI to communicate with SD-Card.
EEPROM to handle Setup & Calibration.

Sounds like it easily could be done in an AVR
communicating with a display controller.

You did not mention the resolution/colourdepth of your screen.
This is quite important.
Also, what type of volume are you planning.
Just a few, and an off the shelf PC communicating with a USB device
doing the real measurement should do.
With some volume behind it, then there are several cheap ARMs with LCD
display.
(AT91SAM9261 is but one)



The displayunit can run Linux, but writing to a double buffered
screen without a large RTOS is probably not a big deal.

--
Best Regards,
Ulf Samuelsson
We've slightly trimmed the long signature. Click to see the full one.
Re: Selecting embedded Linux for a new medical device project (LONG)
Quoted text here. Click to load it

I would use pure digital signals whenever possible. there are
incremental coders (with LED positions notifiers when appropriate) that
do the "knob"

Quoted text here. Click to load it

There are temperature sensor chips with I²C, "one-wire"and other serial
digital interfaces

-Michael

Site Timeline