Embedded technology plays a key role in today's medical diagnostic and therapeutic equipment. Products ranging from infusion pumps and glucose meters to blood gas analysers and ventilators leverage microprocessors, memory, operating systems and application software.
The evolution to microprocessor-controlled medical equipment has enabled the development of ever more capable devices but it also places more reliance on the quality of the software that controls these embedded systems.
If software in a medical device malfunctions, the consequences can be catastrophic. During the 1980s, software malfunctions in the Therac-25 radiotherapy machine from Atomic Energy of Canada Ltd caused massive overdoses of radiation to be delivered to several patients, killing at least six.
According to US FDA, drug-infusion pumps were involved in nearly 20,000 serious injuries and over 700 deaths between 2005 and 2009, alone. Software errors were the most frequently cited problem in these injuries and deaths.
Commonly, medical software consists of an application running on top of a real-time operating system (RTOS). Regulatory standards have been established to help assure that software used in medical devices is well-designed, thoroughly tested and proven to operate correctly in all cases. Commercial RTOSes help medical device manufacturers deliver a better product to market faster by ensuring performance while satisfying relevant regulatory requirements.
Various government-sponsored agencies and independent technical standards organisations have defined these regulations for safety-critical systems. The International Electrotechnical Commission (IEC), a worldwide organisation for standardisation, promotes international co-operation on all questions concerning standardisation in the electrical and electronic fields. IEC-61508, the international standard for electrical, electronic and programmable electronic safety-related systems, sets out the requirements for ensuring that systems are designed, implemented, operated and maintained to assure safety. A separate, derived standard, IEC-62304, focuses specifically on medical system software.
Common regulatory elements
All international safety-critical software standards incorporate common elements that apply to software systems, regardless of their end application. While the different standards have their own particular phraseology and individual features, they all generally require that software be developed according to a well-documented plan, and that its operation is consistent with that plan.
In particular, safety-critical software must demonstrate, through rigorous testing and documentation, that it is well designed and operates safely, in the following areas:
• Process: The process through which the software was designed, developed and tested must be fully described and shown to be consistent. This is broken down into several sub-categories:
6. Configuration management
7. Quality assurance
• Code: The source code produced by the developers or development tool, including all system and application source code, test code, scripts, and object code.
• Test: Test strategy and specific tests performed to verify the correct operation of the code, as well as its ability to achieve all design goals and system requirements.
• Results: Complete results of all tests compiled into a unit and integration test report.
Meeting regulatory requirements
Manufacturers of medical equipment have development teams that are fully capable of generating the documentation required to comply with these safety-critical standards and have done so for years. There are some aspects of this work that pose challenges for developers or that may squander time unnecessarily, however. This particularly holds for RTOSes.
An RTOS controls and manages application software to simplify and optimise the use of system resources. Generally, this software must manage multiple application tasks, or threads, which results in a priority-based, preemptive scheduling OS for real-time responsiveness. As safety-critical systems evolve in complexity and make use of more powerful microprocessors, they increasingly take advantage of commercial RTOS technology. A good commercial RTOS provides system services with an easy-to-use application programming interface (API) that can save developers substantial time in bringing a product to market. Such offerings also enable developers to more easily use other commercial middleware components such as network stacks, graphics, USB communication and more.
If a commercial RTOS is used in a safety-critical system, the developer is challenged to comply with the regulatory requirements that call for documentation and testing of software developed by an independent entity. Regulators refer to this type of software as software of unknown pedigree (SOUP). As difficult as it is to provide all the required documentation for regulatory compliance for the code created by the development teams themselves, it is more difficult to do the same for code developed by another organisation. In addition, the time required to generate and organise all of the RTOS-related documentation can consume a significant portion of the project schedule. The process becomes even more difficult if the commercial RTOS used is not delivered with full source code, or was not well designed and documented.
These concerns motivate some development teams to use an in-house OS instead of a commercial product. This certainly eliminates the problem of SOUP and makes the documentation task less demanding, but it burdens the medical device development team with creation and maintenance of a real-time operating system, which is likely outside their realm of expertise.
If a commercial RTOS is delivered with full source code and is manageably small, then it might be feasible for the development team to complete the regulatory documentation and testing tasks internally. However, to accomplish this, teams typically spend a fair amount of time to understand the code well enough that they can document and test it sufficiently to satisfy regulatory review. This time and effort—not to mention the risk of error and failure—still leave this approach as less than satisfactory since it lengthens the development cycle and increases cost.
Solving the problem
For many companies, the solution for certifying commercial RTOS and tool technology is a complete turnkey solution from the RTOS supplier that is geared to meet the demands of safety-critical systems regulations. Developers can then keep their attention focused on their own application software, which they know well, while all documentation to meet regulatory requirements for external software is provided by the RTOS vendor. This approach also eliminates the risk of error and failure through the RTOS supplier's guarantee of successful regulatory approval.
Faced with the need to satisfy the demands of regulatory agencies for software compliance, developers need to examine the trade-off between efficient use of in-house development resources versus the use of a commercial package prepared for the RTOS.
Commercial regulatory compliance solutions for the RTOS should be both 100% turnkey and include a guarantee of acceptance. Developers who wish to tackle part of the effort in-house are able to do so as well. For those developers, a partial set of material is provided and the in-house team typically might opt to perform target testing internally.
As we move forward as a technology-rich society, we can expect to see more safety-critical requirements intended to reduce the number of system failures that lead to injury and loss of life. Turnkey regulatory compliance solutions will likely become the norm, and will help greatly in the development of quality, well-proven embedded software.
J ohn A. Carbone, vice president of marketing for Express Logic , has 35 years experience in real-time computer systems and software, ranging from embedded system developer and FAE to vice president of sales and marketing. Prior to joining Express Logic, Mr. Carbone was vice president of marketing for Green Hills Software. Mr. Carbone has a BS degree in mathematics from Boston College.
This article was previously published in UBM’s European Medical Device Technology Magazine.