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

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

Reply to
DavidK
Loading thread data ...

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.

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:

formatting link

Patches you will find here:

formatting link

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

Reply to
Juergen Beisert

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,

formatting link
and
formatting link
I dont thing, uclinux will suitable for this application.

-Prakash.

Reply to
asprakash

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

Reply to
Michael Schnell

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

formatting link

Reply to
DJ

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.

formatting link

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.

Reply to
Janaka

formatting link

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

Reply to
DavidK

critical system. Following thread gives

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.

Reply to
Janaka

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

Reply to
Michael Schnell

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

it

Intel

Reply to
DavidK

"DavidK" wrote in news:rZXMi.122$ snipped-for-privacy@newssvr17.news.prodigy.net:

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

Reply to
Steve Calfee

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

Reply to
DavidK

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

Reply to
Michael Schnell

"DavidK" skrev i meddelandet news:rZXMi.122$ snipped-for-privacy@newssvr17.news.prodigy.net...

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
 Click to see the full signature
Reply to
Ulf Samuelsson

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

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

-Michael

Reply to
Michael Schnell

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.