Meeting RTOS certification requirements for safety-critical medical designs

John Carbone, Express Logic Software

April 01, 2013

John Carbone, Express Logic SoftwareApril 01, 2013

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:

1. Planning
2. Design
3. Development
4. Requirements
5. Verification
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.

< Previous
Page 1 of 2
Next >

Loading comments...

Most Commented

  • Currently no items

Parts Search

Sponsored Blogs