An Embedded Recipe for Medical Imaging Systems

Find more content on:


Originally Published MEM Spring 2003



Many factors contribute to the selection of the platform architecture and the design of a medical imaging system.

John Groezinger

Medical equipment manufacturers have diverse requirements for electronic platforms of imaging devices. The detailed architecture usually varies widely between modalities because the end-product functionality differs from device to device. Even within a given modality, the system architecture can change significantly, typically to meet performance requirements and cost constraints.

In addition, a variety of other factors can play into the final decision, including compatibility with legacy equipment, software reuse, and in-house expertise. This article examines various ways to address the specialized requirements of medical imaging.

Most embedded imaging platforms have common elements that can be analyzed independently of the final system architecture. Some elements may not be used, and others may be enhanced for the particular device needs. Therefore, although it is impossible to create a detailed "recipe," it is possible to ensure that the major imaging elements are considered during the conceptual design phase. While reviewing each element, design requirements—such as performance, interfaces, protocols, compatibility, and field upgrades—are often identified.

Data Flow

Figure 1. Conceptual embedded image processing system.
(click to enlarge)

The acquisition (input) section is responsible for getting data into the platform (see Figure 1). This input can be raw data coming from a detector array, or may already have had preprocessing applied. Image processing is applied to the data to transform the information into a more useful form. This process is where the heavy lifting is performed. The algorithms employed are typically proprietary. OEMs develop algorithms that give the best image quality and simultaneously optimize computing time. An output section sends the data to the next device or presents the data for human use. Therefore, data come in and are transformed and output, usually at high data rates. This data flow concept is present in many embedded imaging platforms.

Data I/O

To start with, the input/output (I/O) function in many medical devices is often specialized. It may be customized to meet special needs or to satisfy legacy requirements. If an electronics platform is being upgraded but the acquisition section is not, then equipment compatibility will be a requirement. Sometimes, the I/O may have special electrical isolation, noise immunity, or distance requirements. In such cases, fiber-optic solutions are often used. Latency, bandwidth, cost, and technology maturity requirements are almost always present. And finally, environmental requirements such as plenum installations can complicate choosing the appropriate architecture.

Design engineers usually start by evaluating onboard interfaces to see whether one will satisfy their needs. Since Ethernet is available on most single board computers (SBCs) with 10/100/1000 Mb speeds and is widely supported, this interface can provide many advantages. In addition, Ethernet can be used in a simple point-to-point interface to solve box-to-box interconnection, and thus sidestepping contention issues. For medical devices that require patient contact, this interface may need to be optically isolated, but it can still result in a low-cost solution.

Specialty interface products are available that allow data to be moved over point-to-point interfaces at very high rates with low latencies. Sometimes, an in-house proprietary solution is the only option. Selecting or designing a card that uses a standard form factor (such as IEEE P1386 PMC) enables the board to be used on many different SBCs. Therefore, when the time comes to change the interface, only the card needs to be changed.

The medical market has several de facto standard interfaces such as 3M digital and video. Interfacing with video has many advantages including speed and wide availability. The image data are transmitted as an analog video signal, and a frame grabber is used for capture. This is a mature technology that has existed for several decades. In addition, a video interface may be one of the most cost-effective methods for interfacing to a predigital image communication for medicine (DICOM) modality. Using a frame grabber plugged into a peripheral component interconnect (PCI) slot can attain very high data-transfer rates.

Data Processing

Another important consideration is the processing block. Usually, one of the most stringent requirements is to keep up with the data load being presented. This requirement can be thought of as the compute platform bandwidth in response to the data stream. Many medical applications have data rates in the tens of Mbytes per second (although higher rates exist). Note that the output section may not have to keep up with the input data rate as long as there is time between patients to finish processing and temporary storage is present. However, some systems impose a maximum latency requirement on the data processing (e.g., for devices used during patient procedures). These requirements will drive the detailed processing architecture.

Without a doubt, computing horsepower gets the most attention when initially analyzing requirements. Although some of the more widely published benchmarks, such as Standard Performace Evaluation Corp. (SPEC), provide an indication of processor capability, they rarely are useful for making a deterministic evaluation of a processor for a given application.

Over the years, a number of specialized image processing benchmarks (such as the Abingdon Cross) have been attempted, but these have flaws as well. Most designers determine a set of characteristic benchmarks that will allow them to evaluate the new technology. The 80/20 rule is often used to define a benchmark for the 20% of the code that is executed 80% of the time.

Processing Options

Starting with the microarchitecture of the cpu, the selected processor should be able to implement the chosen algorithms very efficiently. Short-pipelined cpus typically have fewer pipeline stalls, resulting in more-efficient use of chip resources. Very efficient context switching is required during task switching (such as interrupt handling) for embedded systems. A long pipe increases the time to get things going again. A lockable instruction cache prevents swapping of the needed interrupt service routines for fast interrupt handling. Power PC instruction set architecture processors have been optimized to address these embedded issues. This optimization makes them ideally suited for data manipulation while they still perform general-purpose functions.

The AltiVec (Motorola) single-instruction multiple-data (SIMD) processing unit found on G4-series processors can be used to increase the speed of certain classes of algorithms. This processing unit handles data as input and output streams. The data are stored into a set of vector registers (rather than scalar) and processed in chunks. For example, eight half-word (16 bit) signed integers can be processed simultaneously. Although mileage may vary, real implementations have performance increases of 5–10x over conventionally coded algorithms. And the scalar processing resources are still available. Algorithms such as fast Fourier transforms (FFTs), convolution, and other spatial operators can benefit greatly from this on-chip resource.

Embedded systems typically have other specialized requirements that are not found in a typical desktop system. For example, large chunks of data need to be moved quickly in many applications. This is best implemented with direct memory access (DMA) functionality. For example, Motorola's Power Plus architecture includes specialized resources that provide a generalized DMA function across the PCI bus and VMEbus. Other examples include hardware timers and prioritized interrupt mechanisms for software support.

One-way to attain more processing performance is to take advantage of a system bus. Additional processors can be installed in the system as compute notes. Each processor can be dedicated to a given task, and the workload can be distributed. Communications and coordination can take place over the bus, Ethernet, or other system-management buses. If necessary, third-party or proprietary boards can be integrated into the final system.

This concept can be extended in a number of directions. For example, the Processor PMC (PrPMC) concept allows the use of monarch- and nonmonarch-mode processors. A PrPMC can be mounted to a PMC site on an SBC allowing two processors to work on the data stream on a given board. These concepts are supported by many real-time operating systems vendors.

Another way to increase processing horsepower is to use multiple processors in a symmetric multiprocessing (SMP) fashion under an operating system that supports this (such as Linux). Processors can be clustered to achieve even higher computing power.

A final comment regarding processor selection is in order. Processing requirements often change during development either to meet performance criteria or to meet cost-reduction requirements. Final selection of the processor is often made late in the development process but before clinical trials begin. Availability of different speed and memory configurations allow these decisions to be made later in the design cycle with minimal impact and risk.

Displaying Data

If this platform is the last computing platform in the chain, then the data are typically ready for final display. Although this step can be viewed as a special case of output, in the medical world, displaying data typically gets special treatment. The display section takes the data set and formats it so that it is conducive for operators to view it. The display can range from a set of monitors displaying real-time data during surgery to a small, single display used for a simple go/ no-go check. Some systems have no display requirement, particularly if the data are displayed downstream by another device.

Along with this, the system usually has a user interface that can be as simple as a touchpad or as complex as a workstation console. Interface selection depends on the complexity of the task being performed. Many devices have multiple user interfaces. Some interface boxes do not have a dedicated user interface at all, but rather accomplish connectivity through other means such as a Web browser.

For medical imaging, a specialized requirement is often for the system to be able to provide a hard copy of the image data. Even though soft-copy diagnoses are becoming acceptable, the vast majority of radiologists use film on a light box for diagnosis. A lower-quality output device could be used for referral purposes. In the past, this function was performed with a camera and photographic film, but now specialized laser imagers are used to directly output data to film media.

The Console

Starting with the display section, many modalities actually delegate this function to a separate compute platform. Partitioning this function is done for reasons such as software standardization or to provide a common look and feel to the user interface. Other systems make the display portion part of the same platform that does the processing. In either case, typically a full-featured operating system such as Linux or Windows is used. The display section can have one or more display adapters plugged into the PCI or accelerated graphics port (AGP) slots. The manufacturer then can choose the video performance level needed.

The user interface to these systems usually includes keyboard and mouse interfaces. Traditionally, this has been done with PS/2 or serial interfaces. Having a USB port available on the SBC allows the vendor to use additional devices. The increased speed of USB 2.0 will allow higher speed connections for certain peripherals. Despite the availability of new interfaces, manufacturers typically have devices that still need RS-232 to communicate. Having several onboard serial ports for communication is always useful.


The modality typically has some requirement for storage. This requirement can be short term for buffering of data until they can be processed, medium term such that the data are retained for 10 days or so, or long term for archive purposes with backup facilities. Each of these categories has particular characteristics.

A buffer built into the machine may or may not be visible to the user directly. Manufacturers may opt to use temporary buffers that simply hold data until they can be processed. In the past, memory was used for this function; however, today SCSI drives (sometimes in arrays) are fast enough for most needs. In these kinds of applications, the storage size is typically not a driving factor but access speed is.

A medium-term storage mechanism may be present in the machine to keep data local so that they can be accessed quickly. Such storage is useful for referrals or follow-up visits by patients. In such cases, the amount of storage is often an issue. In addition, data may need to be physically on media. This can be provided by a variety of peripherals such as writable DVD drives.

Long-term storage is used to keep patient data available, but typically it does not have the immediacy requirement like the previous two. However, with archival storage, designers must address security concerns and other catastrophes. Some systems have onboard adapters to allow vendors to connect high-speed peripherals. For cost-sensitive applications, integrated drive electronics (IDE) interfaces are available. Redundant array of inexpensive disk (RAID) support is present on storage-oriented products.


Onboard storage should be given special attention. Onboard storage includes nonvolatile RAM (NVRAM) used for storing configuration parameters but that can be accessed very quickly. NVRAM allows settings specific for the machine (such as Internet protocol address) to be kept safely. CompactFlash is also present on machines that allow the configuration data (even image data) to be moved between systems. Complete backup operating systems can be stored in CompactFlash. In the event that the primary fails, backup operating systems can be booted.


DICOM is an example of the transmission element. DICOM has become synonymous with medical imaging because it presents the avenue whereby equipment finally becomes interconnected. Using DICOM, radiologists no longer need to be present where the exam was conducted, and archives of data replace archives of records and film.

The de facto choice for DICOM physical layers at the end point is 10/100/1000BaseT. Much equipment runs quite well on 10BaseT interfaces. What is more important is that the interface be reliable and perform well under heavy load. The cpu must be able to handle the transaction-heavy requirements of TCP/IP. In addition, encryption and compression requirements may be placed on top of the DICOM protocols.


To make the embedded image processing system actually work in a real piece of equipment, it must be controlled. Machine control must often be synchronized with the image-processing portion of the machine. One approach often employed is to use small processors to perform specific tasks such as multiaxis motor control. By using a PrPMC oriented for control functions, a low-cost solution is provided with external interface and an off-the-shelf board support package (BSP) such as the RTOS. The PrPMC can be mounted on a board dedicated for the I/O control task at hand, and the processor can be upgraded in the future if needed. Most manufacturers want a complete development environment as well as run-time environment available with the product so they can start useful work immediately. Platform developers work closely with major RTOS and Linux vendors to provide platforms that have been qualified to work on a variety of operating systems. Extensions to software can allow a system to be recoverable in the event of failure.


This article has provided an overview of ways to address the various requirements of designing a medical imaging system. Requirements for acquisition and processing, display, storage, and transmission functions must also be considered. Detailed architecture varies widely, and many factors contribute to the final platform decision.

John Groezinger is senior systems engineer for the Motorola Computer Group (Tempe, AZ).

Copyright ©2003 Medical Electronics Manufacturing

No votes yet