Why build a custom processor-based control system for a medical device when you can buy one off the shelf? E&T looks at the issues.
Developing a new medical device can be a minefield. You've completed the fundamental science and research, and enjoyed the first round of press attention. Now there are patients who need your new therapy or treatment and the competition is breathing down your neck so you need to get something to market fast.
At the same time, quality is a key requirement because a failure could have catastrophic consequences. Your company also has to make a profit, so cost of goods sold (COGS) and other economics need to be considered. To manage the quality concerns, regulatory agencies such as the Medicines and Healthcare products Regulatory Agency in the UK and the US Food and Drug Administration (FDA) have been established to help guide and enforce best practices for the development of safe and reliable devices. The rest is up to you, the engineer, to work within those constraints and meet all of the requirements in the most timely and cost-effective manner.
One of the first key engineering milestones is deciding how to implement the system's primary controller. This decision can make or break the product because it serves as the foundation on which many other decisions are made. Not only do you need to consider processor architectures, operating system capabilities and other components, but you also must decide whether to produce a custom design or to buy off the shelf.
Custom-built or off the shelf?
A custom design can be tailored to your specific needs and costs can be optimised, but the design cycle will take longer and specification changes or oversights can cause expensive delays. In addition, FDA validation and verification for custom hardware and software can be a gruelling process, especially for smaller companies without prior experience. By contrast, an off-the-shelf platform can increase the COGS, and you may end up paying for features not used in your design, but they typically allow for faster design and validation cycles and therefore a faster time-to-market.
So how do you decide whether to build or buy? And what are the technical and financial risks associated with each approach?
Start by examining the device under development. As an example, we'll consider a cardio-pulmonary bypass (CPB) pump, commonly known as a heart and lung machine. These devices are used during open-heart surgery to oxygenate and circulate blood through the body, taking over from the heart and lungs.
Of course, this article is not intended to serve as a blueprint for developing such a device; please do not attempt to build a CPB pump in your garden shed based on the information here. Rather, this article uses it as an example to highlight some of the issues that arise when selecting primary controller technology for any embedded system.
As shown in Fig 1, you can break down the functionality of a CPB pump into two main phases - oxygenation and circulation. Oxygenation is typically performed by a membrane oxygenator, which imitates the natural lung by interposing a thin membrane of either microporous polypropylene or silicone rubber between the gas and blood phases. The controller needs to acquire data from flowmeters and an oxygen analyser to assess the current state of blood and algorithmically manage flow regulators, a gas blender, a gas filter and a moisture trap to control the ventilating gases. As a result, this system requires multiple analogue input and output channels.
The circulation pump is a simpler system, but involves much of the same input/output capabilities as the oxygenator. Most modern CPB pumps employ centrifugal pumps, which consist of a series of nested, smooth plastic cones, which, when rotated rapidly, propel blood by centrifugal force. An arterial flowmeter is required to determine forward blood flow since it can vary based on the resistance to the flow downstream.
There are other components of a typical system that require additional analogue, digital and other I/O capabilities. For example, to create a stand-alone user interface that does not interfere with the core control of the system, you would need a communications mechanism such as Ethernet or RS232.
There are other key electromechanical elements of the system, such as a heat exchanger to manage the temperature of the blood, but for simplicity I won't examine all of these requirements here.
The DIY approach
If you're going to take the custom embedded design or 'build' approach, then you must start by choosing a processor technology. There are at least five potential technologies that could be used as the primary controller of the system.
Microcontrollers are extremely cost-effective and generally offer an integrated solution on a single chip, including I/O peripherals; but they offer low levels of on-chip memory, so there is little room for complexity and expansion. With a microprocessor, clock rates are higher and there is almost always an external memory interface, so performance and expandability are usually not a concern. However, there are usually no on-chip analogue peripherals, so these processors need to interface to external peripherals, making complex driver development a necessity for most applications.
A digital signal processor is a specialised microprocessor with additional instructions added to optimise certain mathematical functions, such as multiply and accumulate. They are extremely useful for computationally intensive applications, but specialised knowledge is usually required to take advantage of this capability in software.
An application-specific integrated circuit (ASIC) is a chip designed for a specific application rather than general-purpose programmability. ASICs are the most optimised solution, but the extremely expensive development and fabrication process typically deters all except those with the highest-volume products.
A field-programmable gate array (FPGA) provides an interesting middle ground between custom ASIC design and off-the-shelf technology by providing a high-level of specialisation without high fabrication cost. Although you can use them for a variety of processing applications, developing using VHSIC hardware description language is a specialised skill which many embedded software developers, who are used to programming in C, may not be familiar with.
In the case of the CPB, it may be best to use a combination of processor technologies to take advantage of the relative strengths of each. The CPB pump system has to carry out multiple independent functions in parallel. For example, a surgeon should be able to adjust the level of oxygen in the blood without affecting the flow rate. While this can be achieved with a single processor architecture, the added determinism and inherent parallelism of an FPGA-based control scheme is the most appropriate solution. However, for things like user interface and network connectivity, a microprocessor with an embedded operating system is the most common choice. In this situation, you should develop a hybrid system combining both technologies. Fig 2 shows the proposed block diagram for the embedded controller.
Now it is time to develop the I/O circuitry. Because many of the signals in the CPB pump are analogue in nature (flowmeters and motors), analogue-to-digital converters and digital-to-analogue converters are necessary, and corresponding software drivers need to be developed.
So, while the custom design approach will result in a highly specialised design with the lowest COGS, development time and risk is much higher.
The 'buy' approach
An alternative option is to purchase an off-the-shelf platform for developing the controller. Although you can expect to pay significantly more than the cost of the components on a custom board, you can expect to reach the market much more quickly. In addition, these systems typically have clear options for expansion, so allowing for the inevitable feature creep and specification changes that occur after the first prototype is far less painful. There are two basic options for off-the-shelf embedded systems, packaged or unpackaged.
Unpackaged or board-level embedded systems are available in a range of form factors, both industry standard, such as Mini-ITX and PC/104, and proprietary. They are typically the lowest priced solution for off-the-shelf deployment. Board-level embedded systems are available in a variety of processor architectures and each has a small range of supported operating systems and I/O. However, software development tools are almost never integrated and these systems will often require you to undertake all regulatory certifications yourself.
A packaged embedded system can have the same components as an unpackaged embedded system, but it will also deliver specifications for shock, vibration, operating temperature and environmental certifications. These systems are generally more expensive, but they often come with integrated software development tools and a more extensive set of integrated I/O options. One example is the industrial PC, which makes use of standard PC technology and offers the most comprehensive options for development tools and I/O capabilities. This, however, comes at a cost and these systems are significantly more expensive than others.
A further option is to choose an off-the-shelf embedded architecture that is available in both packaged and unpackaged form factors - the National Instruments RIO architecture is one example of this approach. The system architecture includes a real-time processor, FPGA and modular I/O. It comes packaged (CompactRIO) or unpackaged (Single-Board RIO), and it uses the same NI LabVIEW integrated development environment for real-time code development and FPGA development across all deployment targets.
For the CPB machine, since EMC/EMI regulations will become a factor in the hospital environment, you should choose a packaged embedded system that has at least FCC Part 15 - Class A certification or your local market equivalent. In Fig 3, you can see that using this type of system can drastically reduce the complexity of your controller architecture.
Return on investment
So how do you decide whether to build or buy? More often than not, technical capabilities are not the determining factor; rather, it usually comes down to a simple financial analysis of the return on investment of engineering cost incurred in the development of the product versus eventual profits.
In order to make an educated decision, you must first accurately estimate the cost of building your own custom solution. This is never as simple as it seems; if you just add up the cost of the components on the board, plus the hardware and software development time, you are grossly underestimating the total investment. Other 'hidden' costs need to be considered before you have accurately assessed the true cost of the job.
For example, manufacturing and inventory cost can typically account for an additional 20-30 per cent of the COGS of the system. Also, it has been estimated that on average about 30 per cent of total software development time is spent on operating system, driver, and middleware development, although by choosing a packaged platform with integrated hardware and software, you can eliminate the need for this 'board bring-up'.
You must also account for other hidden costs including environmental regulations, end-of-life components, and last minute specification changes forcing design alterations and complete redesigns. The least tangible, but potentially the largest hidden cost, is the opportunity cost of spending engineering time on designing this aspect of the system rather than other revenue-generating projects.
Finally, for medical devices, the FDA validation effort for off-the-shelf components can be far less demanding than a custom design, provided you show due diligence in choosing a vendor with a well defined product lifecycle development process. If you choose vendors with documented certifications like ISO-9001, you can make great strides in easing the validation effort of your product.
So what is the lesson? Never develop a custom controller? Certainly not. Rather, when you are assessing technologies that are crucial to your product's success, save your hard work for the systems that will reach very high volumes, require an extremely specialised form factor, or have very stringent technical requirements. In areas like lower-volume, high-value medical machines, where you can use off-the-shelf technology, consider letting your suppliers take on the logistics and 'hidden' costs so you can focus on differentiating technology to make your product safer and more effective.