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

This is a discussion on Selecting embedded Linux for a new medical device project (LONG) - Embedded ; 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 ...

+ Reply to Thread
Results 1 to 12 of 12

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

  1. 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


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

    David,

    DavidK wrote:
    > 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.


    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.

    > 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.


    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
    (linux-rt-users@vger.kernel.org). Maybe you could ask your question there
    again. Especially about your use in a medical environment.

    Juergen

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



    > 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.


    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.


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

    > 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.


    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

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


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

    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

  6. 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

  7. 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

    "Michael Schnell" wrote in message
    news:fe2b65$fru$1@murphy.mediascape.de...
    > > 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.

    >
    > 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



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

    "DavidK" wrote in
    news:rZXMi.122$LD2.46@newssvr17.news.prodigy.net:

    > 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
    >

    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



  9. 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


    "Steve Calfee" wrote in message
    news:Xns99C1AB3232113stevecalfeehotmailco@208.49.8 0.253...
    > 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
    >
    >



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

    > to keep the design modular, so that some modules can be reused in a future
    > scaled-up or scaled-down product.


    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

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

    "DavidK" skrev i meddelandet
    news:rZXMi.122$LD2.46@newssvr17.news.prodigy.net.. .
    > 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
    >


    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
    This is intended to be my personal opinion which may,
    or may not be shared by my employer Atmel Nordic AB




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

    > 1 ADC channel to measure "knob".

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

    > 1 ADC channel to measure temperature over NTC


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

    -Michael

+ Reply to Thread