RTOS for Medical Devices 101

Real-time operating systems (RTOSes) allow medical device manufacturers to improve the performance of their medical devices and ensure they meet regulatory requirements. But choosing whether to use an open-source, commercial, or in-house RTOS can be tough.

John Carbone, vice president of Express Logic, a maker of RTOSes and embedded operating system software for the medical device industry, explains the basics, including the benefits and risks of commercial and in-house RTOSes, as well as how to ensure an RTOS is safe from cyberattacks. 

What is an RTOS? Why is it needed?

An RTOS (real-time operating system) is software that helps a real-time application do its job. It’s analogous to Windows on a PC, which enables applications like Word, Internet Explorer, and Outlook to do their jobs. So, an RTOS is like Windows for the computer that’s within a medical device.

The computers inside a device—typically referred to as an embedded system, are very different from PCs, so an RTOS has a very different job to do compared with Windows. Most notably, embedded systems have to perform their functions in real time as opposed to PCs, which do not have to meet any particular real-time constraints. Also, embedded systems are not as general-purpose as PCs, nor as resource-rich in memory, processing power, and peripherals. As a result, the job of the RTOS is focused on providing the application the resources it needs to execute, just as Windows is focused on the needs of a PC.

An RTOS provides applications with real-time scheduling (enabling applications to react to real-time events in a deterministic manner), real-time communications (enabling applications to send messages among parts of the application and to react to those messages in real-time), memory allocation, timer management, interrupt processing, device access, and other functions that real-time systems might need.

An RTOS is needed if applications perform sufficiently complex real-time scheduling, message passing, interrupt management, memory allocation, and peripheral control. The most simple applications might not need an RTOS, while very complex applications almost certainly do. For applications that lie in between, the system designer must determine whether to use an RTOS given the need for future growth, portability, development strategy, and maintenance.
 

What standards apply to RTOSes?

Most commercial RTOSes are proprietary. They are designed, developed, and maintained by a single company according to the vision of that company and the applications that company wants to target. Noncommercial RTOSes, whether in-house or open source, also target certain classes of applications, either to suit the in-house project needs or to offer various types of solutions for many real-time applications.

Most of these RTOSes do not follow any standards with regard to their functionality, API, or various characteristics. Many do support standards that address certain industry needs, such as ARINC-653 scheduling, IEC 62304 for medical certification, DO-178B/C safety considerations, OSEK automotive requirements, and the like. Some offer industry standard APIs, such as POSIX, ITRON, or de-facto standard APIs like VxWorks.
 

What are the benefits and risks of using a commercial RTOS?

There are many benefits to using an RTOS, and most are common to commercial and open-source RTOSes alike. However, there are some benefits unique to commercial RTOSes.

Common benefits of both commercial and open-source RTOSes include the following: 

Benefits unique to commercial RTOSes include the following:

Risks and disadvantages of commercial RTOSes include the following:

What are the benefits and risks of using an in-house RTOS?

Benefits of in-house RTOSes include the following:

Risks of in-house RTOSes include the following:

What is more common in medical devices, an in-house RTOS or a commercial RTOS? Why?

Express Logic has many medical device customers, all of whom have elected to use our ThreadX RTOS rather than develop and support an in-house solution. This frees them to focus on their areas of core competency, rather than to reinvent the RTOS wheel and try to match the benefits of a commercial RTOS. Also, open-source RTOSes are difficult to certify, due to the software of unknown pedigree (SOUP) and the sheer complexity of many open-source RTOSes (especially Linux).

Cybersecurity is getting a lot of attention in medtech. How can designers know if their RTOS is safe from attacks?

It is extremely difficult to determine and prove security analytically, and very few—if any—RTOSes provide guaranteed security from external attack. More commonly, developers will rely on their own analysis of the RTOS code (through review of the source as part of their development process) and the track record of success in the medical device market by previous users of a particular RTOS.