Originally Published MEM April 2001
Embedded Systems
Innovation in Medical Imaging Equipment Design: An Imperative, Not an OptionSystem architectural changes demanded by a competitive market can be incorporated time- and cost-effectively.
John Groezinger, Steve LeRouge, and Greg Novak
The
medical diagnostic imaging market has been evolving for a century and
has never been healthier than it is today. This vitality is due primarily
to continual technological improvements that lead to faster and better-resolution
imaging, greater patient safety, and the provision of these capabilities
to a growing population. The result has been a vigorous competition
to create the most cost-effective diagnostic imaging systems.
OEMs are being driven to deliver this continually improving equipment by four key factors: the need to contain costs, a decreasing time to market, the advantages of improved resolution, and a shortage of engineers. These interrelated market factors operate in the context of an increasingly global customer base.
OEMs are addressing these factors chiefly through rapid deployment of the latest technology and an increased dependence on outsourcing. They have always closely tracked technological advances and have traditionally used them to improve their products and, ultimately, reduce costs. A newer response to this challenge is their recourse to the extended engineering workforce and life-cycle management capabilities that are available through an experienced outsourcing partner.
Electronics designers for radiology equipment must investigate system architectural changes to keep pace with market trends. Related medical equipment, such as hard-copy output stations, data storage devices, and picture archiving and communication systems, is also subject to these pressures. Improving functionality is the natural starting point for architectural innovation, followed by the need for enhanced performance. Increasing global competition means OEMs must innovate under extremely short development schedules and intense containment restrictions, both in unit product costs and life-cycle development expenses. One answer is to move from proprietary solutions to standards-based designs. Although this approach initially presents new challenges, it can be effective in getting products to market quickly and keeping costs under control.
The Foundation of Architectural Decisions
When considering an architectural change, one priority remains constantthe product form, fit, and functional design requirements must be met. Often a new product is the result of the natural evolution from previous generations of a product family. What a patient may see as new and improved on a piece of equipment may in fact be the result of a reevaluation of the technologies being used and a major redesign. For example, the latest magnetic resonance (MR) system may appear to simply have a stronger magnetic field, but in fact it involves a complete redesign of its computing platformfrom a multichassis proprietary, multibus architecture to a single CompactPCI system combining acquisition, digitizing, and radio-frequency programmer all in one chassis.
Another example would be the process required to add a digital imaging and communications in medicine (DICOM) interface to a radiology modality. In the past several years, the medical market has come to expect a DICOM port on many radiology information system modalities, thereby providing a standards-based connectivity scheme. However, this imposes additional processing, storage, connectivity, and data flow requirementswithout sacrificing any performance in the baseline system. Rather than taking on this design problem internally, OEMs can work with a DICOM-focused partner company to provide this increasingly common interface. The OEM hires experts to handle the DICOM-related issues, allowing it to focus its resources on strategic innovation within the modality, resulting in better use of resources and a reduced time to market.
![]() |
Figure 1. A schematic representation of an imaging system with a DICOM interface. |
The medical imaging system in Figure 1 requires a DICOM interface. The modality acquires the data and displays it on a console for viewing by a technician. The DICOM interface box provides connectivity between the modality and the hospital information system network. Because processing power and connectivity are important attributes, working with a partner that also has expertise in central processing unit (cpu) design and networking technologies is a significant advantage. Outside expertise can help OEMs get the most out of the equipment design, for example, by configuring state-of-the-art cpus to meet software image-processing requirements while designing the latest network interface 10/100/ 1000BaseT (gigabit) Ethernet expansion capabilities right on the platform.
Bringing in Reinforcements
Every equipment manufacturer prides itself on its innovative (and often proprietary) designs, and the value its equipment brings to the market. Yet, in this competitive landscape, the need to get increasingly complex products out of development and to market quickly can overshadow the time required to address component-level issues. So, on a short deadline, equipment manufacturers must deliver faster systems that run the latest applications. This is the point at which many OEMs bring in reinforcements by partnering with computing-platform experts to take part of the workload.
To see this partnership at work, consider the development of an advanced MR system. As MR systems increase in speed, so do their potential applications. For example, while once capturing static images on film, today's functional MR applications highlight organs in operation. To make this leap in technology, a change in a fundamental design parameter, such as speed, often has systemwide implications. At the board level, even a simple change like the move to gigabit Ethernet places throughput demands on the local PCI bus that can ultimately affect image-capture performance.
A partner can bring to the table an understanding of end-product requirements, system performance, and the latest computer technologies to help the OEM manage these requirements during the conceptual phase, through performance evaluation, and ultimately through product deployment. Throughout the development process (often years for medical equipment), the OEM is freed to focus on applications and other design attributes that distinguish its product in the market. Meanwhile, its partner organization is managing all issues related to the product infrastructure over its life cycle, such as technology seminars, detailed design and modeling, prototypes, product integration, and test.
![]() |
Figure 2. Using a CompactPCI architecture can solve system-level design issues by providing 250-plus pins on three connectors. |
A good example of this kind of design process is the utilization of a CompactPCI system to solve a systems-level issue (see Figure 2). In this example, a dedicated chest computed-radiography system uses CompactPCI to provide the electronics platform. In addition to processing requirements, a typical medical modality has demanding I/O data requirements, particularly in the areas of data acquisition and transmission. Although VME is alive and well, CompactPCI has advantages. Because most high-speed bus traffic has gravitated to add-in buses, a significant advantage of CompactPCI in a market that does not yet require high availability (defined as 99.999% availability, the equivalent of five minutes or less of downtime per year, both planned and unplanned) is the 250-plus pins of user I/O available on three connectors. For example, this additional I/O can be used for rear connections for all I/O on two PMC (PCI mezzanine card) modules, allowing add-in I/O modules that tailor the system to exact interface requirements. There are even adequate pins to implement a user-defined imaging bus and handle module I/O, opening up architectural alternatives even further. The user, therefore, can develop an industry-standard PMC that provides the custom I/O interface, with confidence that the PMC card can be utilized on future (or other) systems.
Because medical equipment lifetimes are relatively long, an OEM may wish to provide a technology refresh of the electronics platform to add new features while retaining key architectural elements of the system. As functionality of medical devices advances, there will come a point at which reaching levels of high availability (99.999% or 5-nines availability) will be a crucial aspect of the equipment's performance, especially when complex and expensive combined-modality systems (for example, computed tomography) require constant use to provide payback. In all these cases, if the platform selection has been carefully done with an eye on standards and future product road maps, integration of a new technology to replace or supplant the existing system can be planned as a natural evolution.
Cutting Costs with Hardware and Software
The trend toward cost containment is directly opposed to increased functionality and performance. Just as the medical devices mature and computing technology advances, the purchasing department has retrained its focus on reduced costs due to pressure from the government, insurance companies, and stockholders. One option is to implement a software solution on a platform with enough (even upgradeable) processing power to enable it to replace proprietary hardware (see Figure 3). A Processor PMC (PrPMC) card could be used to provide significant computing power while interfacing across a 64-bit, 66-MHz PCI bus for the specific I/O required by the application. An embedded motherboard could also be used, but PrPMCs are typically preferred because of power-dissipation and space constraints. They also support add-in performance, with slave PrPMC cards creating a loosely coupled multiprocessing environment (see sidebar).
![]() |
Figure 3. An off-the-shelf custom solution. A Processor PMC can provide significant power and other features to replace proprietary hardware. |
![]() |
Figure 4. Side view of the Processor PMC, standard and tall configurations. The diagram is not to scale. All units of distance are millimeters. The recommended stacking height is 10 mm. |
Software is paramount in properly deploying any of these architectural innovations. Classically, a real-time operating system has been used for system control. It may be the only option. Medical imaging often has latency requirements that require a fine degree of task control; data paths typically need to be constructed carefully, and exception handling needs priority scheduling. However, some medical applications can use an alternative OS, such as Windows NT/2000 or Linux, very successfully. The final OS requirements, along with critical benchmarks, usually need to be analyzed for concept validation. Many OEMs find that the open-source nature of Linux, and the licensing fee structure associated with it, make that OS worth investigating. If CompactPCI is being used, PCI-based device drivers (such as those for Windows NT and Linux) can be employed, often with minimal modification. And the large number of software engineers familiar with these operating systems makes obtaining engineering resources easier.
Understanding Regulatory Requirements
The medical industry has unique requirements. For example, many times a medical device network interface must go beyond typical commercial IEC 60950/UL 1950 requirements with regard to electrical isolation and meet IEC 60601/UL 2601 requirements. Although copper-based interfaces must be evaluated for this requirement, optical-based interfaces often meet this requirement automatically. Another issue to be considered is the internal interface between the DICOM port and the modality itself. Medical equipment often has a requirement to move data between systems or subsystems at rates exceeding 10 Mbyte/sec. Rather than a proprietary solution, the open-standards-based gigabit Ethernet technology offers a ready-made solution to expanding connectivity requirements and, therefore, may address both speed and isolation issues.
Regulatory agencies play a part in the relationship between OEM and vendor. For example, manufacturers of medical equipment are subject to new quality system standards adopted by FDA in 1997 and enforced since 1998. The requirements applicable depend on the end product. They can include design controls on hardware and software developed in-house. An outsourced product is likely to be subject to a different portion of the quality system regulation and have a purchase specification as well as other requirements. An end-device manufacturer must carefully evaluate the trade-offs involved and work with vendors to ensure that requirements in the regulations are met.
No matter what choices are made during the design cycle, medical equipment manufacturers are required to control product changes after the design has been transferred to production. All changes may be subject to verification and validation. Depending on the extent of the changes involved, this cycle can become time-consuming and expensive. Given the very high level of product turnover in the electronics industry, an electronics vendor may be better suited to managing this part of the process. Judiciously selecting platforms and technologies through partnerships, and then using in-house designs when appropriate, can minimize the impact of design changes.
Conclusion
Dynamic medical imaging market trends are pushing equipment manufacturers to experiment with new architectural options and new outsourcing business models to meet demanding performance, cost, and time-to-market goals. While at one time reluctant to source design expertise and architectural technologies outside their own organizations, many OEMs now realize that partnering with outside experts can actually minimize risk and get products to market faster. Outside experts not only support a variety of applicable technologies, they specialize in the related open standards that will be the basis of the medical equipment of the future.
John Groezinger is senior systems engineer for the Motorola Computer Group (Tempe, AZ). Steve LeRouge is product manager and Greg Novak is marketing manager for the Cross Industries Business Unit of Motorola.
|
Processor PMC Standard
Minimizes
Product Development Time
|
|
PCI mezzanine cards (PMCs) have traditionally been favored as a method for expanding I/O on computer baseboards such as VME boards, CompactPCI boards, motherboards, and custom designs. Rugged mechanical mounting and reliable electrical connectors, coupled with the standard PCI interface, make PMCs a natural choice for expanding the I/O functionality of intelligent controllers and single-board computers. However, as the size of processing cores continues to shrink with the integration of a cpu, memory controllers, and bridges on a single chip, the PMC form factor offers a ready-made starting point for the development of a modular cpu, or Processor PMC (PrPMC), standard. Processor PMCs have utility in two types of system configuration. Traditionally, PMCs have been slave I/O controllers. The simplest approach therefore places the PrPMC as an additional target cpu, creating a loosely coupled multiprocessing system. However, a few extra signals added to the standard makes another architecture possible, one in which the PrPMC acts as the host cpu and is connected to a carrier board full of PCI-based I/O controllers. Placing the processor core on a mezzanine is certainly not new. Defining such a standard with multivendor support creates the novelty. How would a PrPMC standard differ from the original PMC standard? Changes to the PMC Standard The guiding premise of the PrPMC standardization effort is that changes to the original draft IEEE1386 and 1386.1 PMC standards should be minimized. The draft PrPMC standard is just a 12-page document that complements the draft PMC standards. Changes were required in just two basic areas: (1) redefining 15 of the 256 available signals (for the popular single-size PMC) to support the PMC as a cpu rather than as simply a slave PCI device, and (2) defining a taller version of the module to allow for the increased power dissipation of cpus. The VMEbus International Trade Association (VITA) Web site (http://www.vita.com) contains the complete specification (under "VITA 32," the designation of the responsible task group). Click on the "VITA Standards Organization Downloadable Draft Standards" shortcut in the left margin of the home page to obtain the complete standard. Monarch or Nonmonarch at Peak Speeds Two types of PrPMCs are defined, originally described as master (or host) and slave (or target). Owing to the location of the PCI clock and arbiter on the carrier board, the PrPMC specification introduces the terms monarch and nonmonarch. The monarch is defined as the main PCI-bus PrPMC, or cputhe one that performs PCI bus enumeration at power-up and services PCI interrupts. A nonmonarch thus is not the main cpu and does not perform PCI bus enumeration. Naturally, there must be only one monarch per system, while there can be as many nonmonarchs as the electrical interface on the carrier card will support. The new "PRESENT" signal positively identifies installed modules. Changes to the interrupt signals were required. The typical nonmonarch (slave) PMC generates interrupt outputs, whereas a monarch acts as an interrupt handler, requiring interrupts as inputs. The PrPMC draft standard therefore redefines interrupts to be bi-directional. The PCI specification supports 66-MHz operation, so M66EN is now included in both the IEEE1386.1 PMC and the PrPMC standard. The PMC specification also defines only one PCI load per PMC. The latest release of the PrPMC draft standard, Revision 0.4, allows two loads on a PrPMC, similar to the two-load option now only available to the CompactPCI system slot. The Tall PMC Option The PrPMC standard defines a new "tall" option. This taller alternative may be necessary to accommodate heat sinks for cpus that exhibit considerable power dissipation. An increase of 20 mm in height is a natural choice, since that size allows the tall PrPMCs to fit easily into two VME or CompactPCI slots (see Figure 4). The original PMC standard defined a power limit of 7.5 W for a single wide standard PMC. However, the current draft standard provides more-realistic guidelines that allow PrPMC and carrier/enclosure vendors to specify maximums based upon connector and airflow requirements. Conclusion Reflecting the philosophy that simpler is better when speeding new technologies and products to market, the overall complexity of the PrPMC draft standard has steadily decreased since the original revision 0.1; yet the proposed standard now includes selected features that provide all the capabilities required by real-world designs. The standard, which recently has been updated in accordance with results of the VITA 32 Task Group ballot, will stabilize PrPMC designs so that vendors can create truly interchangeable modules based on an important new architectural building block. |







