When an RTOS is Just What the Doctor Ordered
As migration to 32-bit microprocessors in medical IoT devices picks up steam, the case for using a commercial RTOS only gets stronger.
Medical devices that monitor and manage illness and improve wellness are helping drive explosive growth in the Internet of Things (IoT), which is expected to have an installed base of 45 to 55 billion devices by the year 2025 according to Business Insider. Growth is coming from two key types of applications: existing devices or ‘things’ monitoring data and sharing it with other devices, and new devices designed to monitor, measure, predict and share data across a networked infrastructure.
Medical IoT devices require network connectivity, such as Wi-Fi, Bluetooth, ZigBee or Ethernet, and many will also include a graphical user interface (GUI). That means these new devices generally will require 32-bit microprocessors in order to provide the necessary address space and processing power to support such connectivity and a responsive GUI. There already is strong migration from 8-bit and 16-bit microprocessors due to requirements for enhanced device functionality as well as the attractive cost/performance attributes of new 32-bit microprocessors. The forecasted IoT growth promises to sharply accelerate this migration.
On the hardware front, the migration to 32-bit processors is clear, but what about the software side? The increased connectivity requirements alone necessitate the execution of communication protocol stacks on the 32-bit embedded microprocessor, which in turn necessitates the use of a real time operating system (RTOS). GUI design and runtime software from third parties typically rely on RTOS services as well.
RTOS for Medical Applications: Four Considerations
According to the UBM Embedded Developer survey released in May 2015, medical applications were one of the top ten embedded development projects. The survey also reported that more than 60 percent of current projects include real-time capabilities, more than a third include a GUI, and more than 70 percent use an RTOS or scheduler of some kind. Of respondents who selected a commercial RTOS, 53 percent cited the number one reason as “real-time capability.” Four key considerations come into play when deciding whether your application could use an RTOS.
(1) Real-Time Responsiveness
Medical devices attached or inside the human body that are used to monitor and maintain a person’s health or help manage diseases require reliable real-time responsiveness. An RTOS invisibly handles allocation of the processor to the threads that perform the duties of the embedded device. With the proper assignment of thread priorities, application software does not have to concern itself with how much processing time each individual thread takes. Even better, changes in the processing responsibilities of a given thread do not impact the processor allocation (responsiveness) of higher-priority threads.
Many legacy 8/16-bit devices employ a polling-loop software architecture to distribute processing time among various threads. Although easy to understand and appropriate in very simple devices, this approach suffers when used in more complex devices. The fundamental problem of the polling loop is that responsiveness of any thread in the loop is determined by the processing in the rest of the polling loop. The worst-case responsiveness is effectively the worst-case processing. If processing in the polling loop changes dynamically, so does the responsiveness of each thread. As greater complexity is added to the polling loop, it becomes more difficult to predict and meet real-time requirements.
|When Is an RTOS Overkill?
As a rough guideline, when the total memory (ROM and RAM combined) of a device is less than 16KB, an RTOS may be overkill or impossible. Such devices typically have a dedicated purpose and most often use an 8-bit or 16-bit microprocessor. Once device firmware exceeds 32KB of total memory and/or utilizes a GUI or communication protocol (like all IoT devices will), it will almost certainly need an RTOS. Even a small 32KB, dedicated-purpose, non-IoT device could benefit by using an RTOS by simply isolating foreground and background processing into two separate threads. This configuration would only cost an additional 3KB in total memory for the RTOS, while making the device firmware much simpler and much easier to enhance in the future.
Take, for example, an existing device that must sample an external sensor in real-time. Figure 1 shows a simple polling loop that examines a real-time sensor and then performs three additional functions. The developer has complete access to this closed, simple system so that the real-time interrogation of the external sensor can be guaranteed. However, if this device needs to be connected to the cloud for access by a caregiver or to update an electronic medical record (EMR), the polling loop must also invoke a software protocol stack for the cloud communication.
Figure 2 shows the polling loop with an additional call “perform_cloud_communication.” Adding this extra processing to the polling loop might reduce the responsiveness to a level where the external sensor is no longer sampled properly. In addition, communication protocols often range from 50KB to 100KB in size, which indicates a level of complexity that might make it difficult to calculate its worst-case processing requirement.
In sharp contrast, the response time using an RTOS is constant. In the same example, the protocol stack processing could be placed (or called from) a lower-priority thread, while the real-time sensor sampling processing could be placed in a higher-priority thread. The RTOS would ensure that the real-time sensor sampling thread always takes precedence over the communication protocol stack. This results in completely deterministic (on the order of 120 cycles on an ARM Cortex-M) and faster response times for the external sensor sampling thread, all of which is invisible to the application software.
(2) How an RTOS Can Ease Development
In legacy small device development, each firmware developer has intimate knowledge of the run-time behavior and requirement of the device because processor allocation logic is dispersed throughout the application code. For small device firmware projects (typically less than 32KB of total memory), one or two developers have a fighting chance to understand the processing requirements of all the firmware. However, as functionality of the device increases (e.g., cloud communication protocols, etc.), the development team expands and firmware processing requirements become more complex. Communication among the code modules developed by each team member must be designed and implemented to allow for inter-thread synchronization and information exchange.
An RTOS eases development as the device functionality increases by eliminating the need to fully understand the processing requirements of every firmware component. With an RTOS, developers can concentrate on their specific piece of the firmware and not have to worry about the processing requirements of the other firmware in the device. Moreover, they have inter-thread communication services (e.g., messaging, semaphores, etc.) that are efficient, consistent and well defined.
(3) Adding New Features Simply
Medical IoT devices produce relevant data that can be viewed continuously from remote locations, but that often also require an intuitive user interface and additional connectivity. An RTOS invisibly handles the processor allocation logic so that real-time performance of a high-priority thread can be guaranteed, whether the firmware is 32KB or 1MB in size and regardless of the number of threads in the application. This makes it easier to maintain the application and easier to add new features to a device. In addition, most commercial RTOS offerings also have an extensive set of middleware that is pre-integrated and ready to be deployed. Having the ability to easily add networking, file systems, USB and graphical user interfaces makes adding new features to a device that much easier. Figure 3 shows the association of middleware and the RTOS.
(4) Faster Safety Certification
Many medical devices require certifications to ensure patient safety. The interoperability of IoT devices will certainly challenge some existing safety standards and may even give rise to new ones. RTOSes such as ThreadX from Express Logic have received certification that confirms it can be used in the development of safety-related software for the highest safety integrity levels of the IEC 61508 and IEC 62304, for the functional safety of electrical, electronic and programmable electronic safety-related systems. This pre-certification offers huge benefits to developers. It means no artifacts need to be provided for the RTOS, which speeds the process of system certification. Without a pre-certified RTOS, developers must either qualify their own scheduling code, or provide artifacts for the RTOS software they are using—often at additional cost and time.
With the continued migration to 32-bit microprocessors and billions of new IoT devices coming to market in the next several years, there is a strong case for using a commercial RTOS. Coupled with the relatively small cost, it is practically a foregone conclusion that an RTOS is in your near future—if you aren’t using one already.
William E. Lamie, co-founder and CEO of Express Logic, Inc., is the architect of the ThreadX® RTOS. Prior to founding Express Logic, Lamie authored the Nucleus™ RTOS and co-founded Accelerated Technology. Twenty-five of Lamie’s 30 years’ experience in developing embedded systems has focused on the development of real-time operating systems. As the architect of three RTOSs that have enjoyed widespread commercial adoption, Lamie can be credited as the source behind more than five billion RTOS-driven devices.