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.
|Express Logic's ThreadX RTOS manages activity in a multicore system and shows the state of all application threads, context switches, and interrupt activity.|
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:
- Eases development by providing callable functions that perform necessary system services for applications.
- Facilitates multithreading, so that one part of an application can run when another part must wait for something to occuracilitates team development.
- Facilitates application portability to other processors as the product matures and needs more resources or to cover a range of capabilities in a family of medical devices.
- Optimizes application functionality by context switching, interrupt processing, and task scheduling.
Benefits unique to commercial RTOSes include the following:
- Point of contact for support.
- Regular upgrades of the tools.
- Higher performance.
- IP rights indemnification.
- Safety-critical certification (IEC 62304 compliance for medical devices).
- Protection of proprietary application IP.
Risks and disadvantages of commercial RTOSes include the following:
- • License cost. Teams may question whether the tools are good enough to be worth the price.
- • Supplier viability. Has the supplier been in business for a while?
- • Field-proven. Has the RTOS been used in successful products?
What are the benefits and risks of using an in-house RTOS?
Benefits of in-house RTOSes include the following:
- Design appropriate for the application.
- Intimate knowledge of RTOS.
- Safety-critical certification.
Risks of in-house RTOSes include the following:
- Development expertise. Is the staff capable of designing, developing, and maintaining an RTOS?
- Performance. Is the RTOS optimized, based on years of widespread use?
- Support. Do you want to be in the RTOS business?
- Portability. When requirements dictate a change in processor, porting an in-house RTOS can involve changes that were not foreseen.
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.