4 ms·

I would guess pacemakers don't run Linux. I would be surprised if they run an OS at all. I work on devices that have to survive 20 years on one non-rechargeable

I would guess pacemakers don't run Linux. I would be surprised if they run an OS at all. I work on devices that have to survive 20 years on one non-rechargeable and non-serviceable battery, and there's at most a simple scheduler in place to control tasks. We use 32 bits for epoch time, but our epoch starts Jan 1, 2000, so we have 30 years on Linux before this becomes a problem.

pinaceae 10y ago
you might be underestimating modern med devices which even have wireless access (beats a port or invasive surgery to read a log). example for the issues in this area: https://spqr.eecs.umich.edu/papers/49SS2-3_burleson.pdf https://spqr.eecs.umich.edu/papers/49SS2-3_burleson.pdf
- OnACoffeeBreak 10y ago
  I see "wireless", but not "WiFi" or "802.11*" in the PDF. For what it's worth, devices I work on have a few wireless interfaces while guaranteeing 20-year life time: one interface is long-range (on the order of 10km), two are short range (on the order of a few mm). There is no way we can get to 20-year life time with doing WiFi (maintaining current battery size/capacity) for long'ish range and maybe not even BT for shorter range.
  - pinaceae 10y ago
    yes - but this means there is more than a simple OS operating in those devices. and just like any other IoT, using generic chips and stacks is cheaper. run QNX or Linux on it and walk away. there are DYI insulin pump monitors out there already that use Linux on RaspberryPi - see here: https://openaps.org/ https://openaps.org/
    - OnACoffeeBreak 10y ago
      The microcontrollers on these devices don't have MMUs. There is typically not even a USB interface. The microcontroller is in deep sleep mode saving power 99.9% of the time. During that time only essential peripherals are powered on and no code is executing. A RasPi has no chance of running for 20 years off a single A-size non-rechargeable non-serviceable battery.
zeptomu 10y ago
This is really interesting! Obviously it is a topic in itself, but do you mind sketching how one develops software in an environment that requires this extreme amount of reliability? If you do not use an existing general-purpose OS, do you even use a MMU? Is it hard real-time? E.g. what language do you use? Is it SW or HW that you "ship"? You probably perform some kind of verification and or validation - how does the tool chain look like? Do you perform model-checking on all possible inputs? Lots of questions, and you do not have to go into detail, but I would appreciate your input, as it is an interesting topic.
- OnACoffeeBreak 10y ago
  No MMU. It is hard real-time in the sense that there are events that need to be processed withing a small time window (a few microseconds (with help from hardware typically) to milliseconds). The product is custom hardware built with off-the-shelf parts like microcontroller, power converters, sensors, memory. Texas Instruments MSP430 family of microcontrollers [1] is popular for this type of application. They are based around MIPS CPU cores with a bunch of peripherals like analog-to-digital converters, timers, counters, flash, RAM, etc. I don't work on medical devices, so validation is more inline with normal product validation. We certainly have several very well staffed test teams: one for product-level firmware, one for end-to-end solution verification, others for other pieces of the overall solution. We are also heavy on testing reliability over environmental conditions: temperature, pressure, moisture, soil composition, etc. The firmware is all done in-house written in C. Once in a while someone looks at what the assembler the compiler, but nobody writes assembler to gain efficiency. We rely on microcontroller vendor's libraries for low-level hardware abstraction (HAL), but other than that the code is ours. The tool chain is based on GCC I believe, but the microcontroller vendor configures everything so that it crosscompiles to the target platform on PC. Debugging is done by attaching to the target microcontroller through a JTAG interface and stepping through code, dumping memory, checking register settings. We also use serial interfaces, but the latency introduced by dumping data to the serial port can be too much for the problem we're trying to debug and we have to use things like togging IO pins on the micro. We don't model the hardware and firmware and don't do exhaustive all possible inputs test like one would do in FPGA or ASIC verification. I need to go, but if you have more questions, feel free to ask, and I'll reply in a few hours. 1: http://www.ti.com/lsds/ti/microcontrollers-16-bit-32-bit/msp/overview.page http://www.ti.com/lsds/ti/microcontrollers-16-bit-32-bit/msp...

pinaceae 10y ago

you might be underestimating modern med devices which even have wireless access (beats a port or invasive surgery to read a log). example for the issues in this area: https://spqr.eecs.umich.edu/papers/49SS2-3_burleson.pdf https://spqr.eecs.umich.edu/papers/49SS2-3_burleson.pdf

OnACoffeeBreak 10y ago
I see "wireless", but not "WiFi" or "802.11*" in the PDF. For what it's worth, devices I work on have a few wireless interfaces while guaranteeing 20-year life time: one interface is long-range (on the order of 10km), two are short range (on the order of a few mm). There is no way we can get to 20-year life time with doing WiFi (maintaining current battery size/capacity) for long'ish range and maybe not even BT for shorter range.
- pinaceae 10y ago
  yes - but this means there is more than a simple OS operating in those devices. and just like any other IoT, using generic chips and stacks is cheaper. run QNX or Linux on it and walk away. there are DYI insulin pump monitors out there already that use Linux on RaspberryPi - see here: https://openaps.org/ https://openaps.org/
  - OnACoffeeBreak 10y ago
    The microcontrollers on these devices don't have MMUs. There is typically not even a USB interface. The microcontroller is in deep sleep mode saving power 99.9% of the time. During that time only essential peripherals are powered on and no code is executing. A RasPi has no chance of running for 20 years off a single A-size non-rechargeable non-serviceable battery.

zeptomu 10y ago

This is really interesting! Obviously it is a topic in itself, but do you mind sketching how one develops software in an environment that requires this extreme amount of reliability? If you do not use an existing general-purpose OS, do you even use a MMU? Is it hard real-time? E.g. what language do you use? Is it SW or HW that you "ship"? You probably perform some kind of verification and or validation - how does the tool chain look like? Do you perform model-checking on all possible inputs? Lots of questions, and you do not have to go into detail, but I would appreciate your input, as it is an interesting topic.

OnACoffeeBreak 10y ago
No MMU. It is hard real-time in the sense that there are events that need to be processed withing a small time window (a few microseconds (with help from hardware typically) to milliseconds). The product is custom hardware built with off-the-shelf parts like microcontroller, power converters, sensors, memory. Texas Instruments MSP430 family of microcontrollers [1] is popular for this type of application. They are based around MIPS CPU cores with a bunch of peripherals like analog-to-digital converters, timers, counters, flash, RAM, etc. I don't work on medical devices, so validation is more inline with normal product validation. We certainly have several very well staffed test teams: one for product-level firmware, one for end-to-end solution verification, others for other pieces of the overall solution. We are also heavy on testing reliability over environmental conditions: temperature, pressure, moisture, soil composition, etc. The firmware is all done in-house written in C. Once in a while someone looks at what the assembler the compiler, but nobody writes assembler to gain efficiency. We rely on microcontroller vendor's libraries for low-level hardware abstraction (HAL), but other than that the code is ours. The tool chain is based on GCC I believe, but the microcontroller vendor configures everything so that it crosscompiles to the target platform on PC. Debugging is done by attaching to the target microcontroller through a JTAG interface and stepping through code, dumping memory, checking register settings. We also use serial interfaces, but the latency introduced by dumping data to the serial port can be too much for the problem we're trying to debug and we have to use things like togging IO pins on the micro. We don't model the hardware and firmware and don't do exhaustive all possible inputs test like one would do in FPGA or ASIC verification. I need to go, but if you have more questions, feel free to ask, and I'll reply in a few hours. 1: http://www.ti.com/lsds/ti/microcontrollers-16-bit-32-bit/msp/overview.page http://www.ti.com/lsds/ti/microcontrollers-16-bit-32-bit/msp...