Among the myriad challenges they face in bringing their products to market, medical device manufacturers must obtain FDA and other regulatory approvals before releasing their devices for sale. The preapproval requirement has left many medical device makers wary of designing with multicore systems, fearing multicore’s complexity will jeopardize a product’s ability to obtain regulatory clearance.
It’s true that multicore processing introduces further complexities into software systems. But whether they run on one, two or 16 processors, today’s systems are too complex to be validated through testing alone. Thus, device manufacturers should already be familiar with the validation techniques they will need for multicore system development.
This article discusses the validation of safety claims for systems running on multicore processors, as well as some OS characteristics that can facilitate the migration to multicore.
The growing need for medical devices with more-sophisticated capabilities, including complex user interfaces and high-definition imaging (both of which have voracious appetites for computational power), is feeding an increasing demand for multicore processing. Even as they support a growing range of advanced features, medical systems often must also satisfy requirements for low weight, low power consumption and low heat dissipation.
Those requirements are difficult to meet with only one core, as increasing the computational power by increasing the processor clock rate runs up against three insurmountable limitations. First, power consumption and heat generation increase more rapidly than clock rates. Further, memory speed doesn’t keep up with processor speeds. Finally, resource, control and data dependencies limit the parallelism possible with a single instruction stream.
Figure 1. With growing demands for computing power, even a relatively small medical device may benefit from multicore processing.
Click on image to enlarge.
Key OS requirements
Any medical device for which reliability and availability are requirements will probably need a real-time OS, and that RTOS will likely need to support symmetric multiprocessing. It’s easier to work with a single OS that can distribute processes across multiple cores than it is to accommodate asymmetric multiprocessing, which uses distinct OS instances—and sometimes even different OSes—on each processor.
The selected RTOS must prevent faults from percolating through the system and must be able to restart components when faults do occur. The optimal choice in most cases is a microkernel architecture, in which applications, device drivers, file systems and networking stacks all reside outside the kernel in separate address spaces, and are thus isolated both from the kernel and from each other.
Also of importance, because of the high number of processes and threads in multicore systems, is a software watchdog. The watchdog is a user-space fault-recovery process that can detect failures and immediately move the system to a safe state, or restart failed processes when it’s possible to do so without compromising safety.
To ensure system dependability, the RTOS should also support:
• time partitioning (preferably adaptive), so that critical processes cannot be starved of CPU cycles;
• priority inheritance, to prevent priority inversions; and
• processor affinity, which lets designers restrict specific parent and child processes to designated cores.
Designers can decide exactly how they want to use the multiple cores available to the system. For example, they may assign noncritical but computationally intensive processes to run on any available core or, alternatively, to run on only a limited subset of cores, while restricting critical components to one core to simplify design, debugging and validation.
Figure 2. Screen shot of a system profiler display showing CPU usage across four cores.