For Cloud-Connected Medical Devices, Start with a Rich, Solid Platform
The advent of small, wearable medical devices is transforming health care and giving patients more liberty. While they are small, they are also complex and require certification. It pays to get a jump on development by starting with a platform that supplies a small but rich RTOS as well as communications and peripheral support from the start.
by Kim Rowe, CEO, RoweBots, Ltd.
Small, intelligent medical devices worn on the body and kept in the home are not only saving lives. They are shortening hospital stays and enabling elderly patients to live at home longer, thus driving down the costs of medical care. By directly sensing and interpreting vital bodily functions they can signal alerts when needed as well as connect via the Cloud to physicians and specialists for more regular monitoring.
Companies developing these devices face multiple challenges that include the familiar pressures of cost, time to market, size, weight and power (SWaP) optimization, safety, security and providing the proper mix of features. They also must confront hurdles for certification, often by multiple countries and different levels of certification. While the specific functional requirements for medical OEM devices may vary widely, they also share some common characteristics.
To address the needs of the medical OEM community, RoweBots has created MedicalOS, a special packaging of its flagship Unison RTOS targeted for medical applications. Its aim is to provide selected components that can offer a broad set of features for medical devices without making developers search through a complex set of unnecessary components but quickly find and evaluate those most suited to their development goals. One of the major areas is home health care, which involves a device worn on the body that communicates with a smartphone carried by the patient and/or a PC-based or specialized gateway server in the home. This system is then connected to the Internet and ultimately to Cloud services.
The goal is to allow the patient maximum freedom while constantly attending to specific medical signs with the ability to alert at different levels, for example when it is time to take a medication. At other levels an alert would go to a medical professional site for routine monitoring or in some cases for more immediate action. This requires the ability to analyze and handle (store and/or transfer) data appropriately. In some cases the analysis would result in an immediate alarm with an alert to the remote service. In others, it would simply involve storing data and transmitting it to other systems (gateway or Cloud) as appropriate. One other option could provide the ability to store and dispense medications of various types.
Another aspect of home health care involves monitoring motion and location. For example, an accelerometer can signal if an elderly patient has taken a fall and either has or has not gotten up. If a patient gets up at night to use the bathroom, has he or she returned to bed? Has he or she eaten or taken medications? If an alert is sent, where is the patient’s location to send help?
These possibilities make it clear that a given device may have a unique combination of features and functions that are defined by specialized peripherals such as sensors for pressure, temperature, video and other input. These peripherals supply input to vital specific software functions. Not only that, it is also vital that medical devices be secure from unauthorized access while also allowing authorized access for configuration and for data retrieval. They must support appropriate wireless communication standards. They must be able to accurately synchronize time, provide GPS location data and even sometimes incorporate motor drive capability.
Start with a Solid Platform
Developing systems of this variety and complexity from scratch would, of course, be a thankless task. The MedicalOS package of the Unison RTOS offers a stable and versatile platform consisting of a choice of supported MCUs and hardware devices along with an RTOS environment tailored for very small systems. Unison is based on a completely native POSIX implementation using nano-kernel technology that has a tiny memory footprint in the range of 20K of flash and 8K of RAM. A complete solution looking more like an ultra-tiny embedded Linux configuration might be in the order of 300K of flash using 70K of RAM depending on the configuration without security modules. With security modules, this might be more like 400K of flash and 100K of RAM depending on features selected—still a very small footprint.
Due to the wide variety of medical devices and their support systems such as in-home gateways, MedicalOS supports the entire spectrum of processors and MCUs supported by the full Unison RTOS. The Unison RTOS delivers complete POSIX RTOS implementations with file I/O, socket I/O and fully compatible error codes. The RoweBots POSIX RTOS implementation delivers ultra-tiny embedded Linux-compatible solutions that are a single process, multiple thread model with complete I/O and a tiny footprint and other significant improvements over embedded Linux variants.
To be even more helpful, this small, modular and efficient RTOS environment can be fitted with just the right software modules for peripherals and wireless connectivity to act as the foundation of a truly small and efficient wearable device. In the MedicalOS package there is a selection of software items that have been pre-tested and can be quickly integrated to meet the needs of the development project.
Software module and peripheral support consists of a selection of advanced and secure networking protocols that implement secure access for both data transfer and remote configuration and control. For example, the Secure Shell (SSH) SSH provides a secure channel over an unsecured network in a client-server architecture working with the Secure File Transfer Protocol (SFTP).
Security is Built in
It is hard to sufficiently emphasize the importance of security in the medical device arena. There are, of course, federal regulations such as HIPPA that mandate patient privacy. In addition, these devices my end up being used in a variety of network environments from home-based Internet connections communicating with Cloud servers and ultimately to doctors and specialists to connection inside various hospital wireless networks. Devices must be able to negotiate secure connections that not only protect data, but also guard against hacking and malicious access. As horrid as it may sound, there is even a definite need to protect pace makers against hacking.
Of central importance to device security is the way memory is managed in Unison. The POSIX compatibility with Linux in the RTOS world lies mostly with the API and the fact that many developers are already familiar with it and that a large amount of existing code—much of it available as open source—can be acquired and adapted for use in the embedded application. One major “behind the scenes” difference with Unison is memory management, which is designed to eliminate the dangers of dynamic loading. The reason is that while dynamic loading can be a convenience for system flexibility and configuration, it can be a definite liability when it comes to security.
In the Linux world, the code can be loaded into RAM and then run under control of the operating system. Linux relies on protection of the OS to make sure that user programs cannot gain control of which programs are to be run. However, this protection is sometimes breached. The same is true for many RTOS implementations, and they too can be breached in this way because they are large and complex and it only takes one small security hole to get privileged access or access to physical memory to change specific bits and the entire security mechanism can be bypassed. Since the malware code must execute from the target device, it must therefore be loaded into that device’s memory.
While Unison has retained the Linux API compatibility with all of its advantages for the developer, it has been modified in terms of its memory model to offer a much higher grade of security for embedded connected devices. In Unison, all code executes from Flash memory so in order for code to be loaded in so that it can execute, it must also be placed in Flash, which is much more difficult that putting it into RAM. With Unison there are two major barriers to loading unauthorized code. The first is that the Flash-based code is a single linked image so that when it executes, it just executes that image. RAM is of course used for temporary storage of variables and stacks such as used for context switching, but all instructions execute from Flash.
This means that no external program can be loaded into device memory to be executed even under control of the OS because the code must be executed from Flash and the only way to modify that Flash image is to upload an entirely new image, presumably one that includes the malware along with the regular application code.
The Unison field upgrade feature requires loading of the entire software image, not just additional operations such as supported by dynamic loading. Getting ahold of a copy of the Flash-based application is extremely difficult if not impossible. Another hurdle is the fact that the remote field upgrade feature is also a program on the device that uses encryption. If the image to be loaded is encrypted, it can only be decrypted if it is signed with the proper key, which is owned by the owner of the code and the device and kept separately from the device. In other words, you can’t get the decryption key by hacking the device. Code that isn’t properly signed is simply thrown away. The upshot is that even if a hacker could breach the password/user name barrier, he will not be able to modify the code in the device in any useful way.
In addition to this foundational, architecture-based security, Unison MedicalOS also provides a suite of additional security-critical components including secure mail or secure SMTP along with secure web pages or HTTPS for implementing layered security strategies. Secure management—SNMP v3— is provided to secure both authentication and transmission of data between the management station and the SNMP agent. A secure bootloader—mentioned above—requires the files that are downloaded for reflashing the system to be encrypted and checked before loading. And there is also a PowerSafe and encrypted file system. Secure and reliable wireless communication is indispensable for medical devices and MedicalOS supports Bluetooth Classic and Smart/Smartready along with Wi-Fi and 6loWPAN with 802.15.5 radios. Additional protocols for graphics options along with camera and video options set the developer up with a rich selection of options for the entire range of possible medical applications.
Reference Design Speeds Application Development
A home health care reference design based on MedicalOS is available to help develop a hardware-agnostic home healthcare system and connect it to the Cloud. In addition to the MedicalOS package, it consists of a wireless router, a windows server and an Android phone along with three ARM Cortex-M4-based evaluation boards along with their support packages from three different manufacturers. The three boards are the FRDM-K64F from Freescale (Figure 1a), the Tiva 129 from Texas Instruments (Figure 1b) and the STM3240G from STMicrosystems (Figure 1c).
1a
1b
1c
Figure 1: Medical device developers have access to a full development kit with a choice of three platform boards: the FRDM-K64F from Freescale (1a), the Tiva 129 from Texas Instruments (1b) and the STM3240G from STMicrosystems (1c). The boards along with a wide choice of sensors and peripherals, offer different capabilities to target different classes of medical devices.
The kit allows the developer to configure a system with MedicalOS-based devices connected to more stationary MedicalOS-based devices that are in turn connected to the Cloud and the Android phone via an MQ Telemetry Transport (MQTT) client that uses the full MedicalOS security features. All three boards connect to the wireless router via TCP/IPv4/v6 and then to the Cloud and the Android phone as shown in Figure Y.
For example, the FRDM-K64F incorporates an on-board accelerometer/magnetometer and an RGB LED onboard. The Tiva 129 and the STM3240G both additionally support on-board 320 x 240 touch screen displays. In addition, all three boards include the I2C bus, which can be used to attach sensors. Sensors supported in the reference design kit include:
- The InvenSense MPU9150, a 9-axis accelerometer/gyroscope
- The Intersil ISL29023 digital light sensor
- The Bosch BMP180 pressure/temperature sensor
- The Senserion SHT21 humidity/temperature sensor
- The Texas Instruments TMP006 infrared temperature sensor, which can read temperature without contact
All three can also sense battery data.
By connecting the components in the kit as shown, the developer can verify transfer of data and commands and use them as a platform to reliably begin development of unique and innovative medical and healthcare applications.
Connecting to the Cloud
“Things” are connected to the Internet for a reason and that is to make use of the data they supply to produce results that are either used for analysis and/or to make decisions and issue commands back to the devices. The connectivity built into IoT devices is precisely for this purpose, which can often mean thousands of even millions of connected devices feeding data into the Cloud. But that Cloud is a server or servers in a data center running analysis and management applications to communicate with and control those devices. Not every customer will have their own server/data center, so these are mostly operated as services using hub software to which the devices connect.
MedicalOS features support for the Microsoft Azure Cloud computing service. Azure lets developers build, deploy and manage applications and services through a global network of Microsoft-managed data centers. Often medical devices will connect via a local or private network to edge devices. These edge devices may have some critical analytic and decision making functions as well as doctor or hospital direct access as determined by the needs of the application. But the IoT devices will also connect via these edge computers to the Cloud as embodied in this case by Microsoft Azure.
Devices can connect to their peers or the edge server using some selected wireless protocol such as Wi-Fi, LoRa, 6LoRa or some other protocol. Then to connect to the Cloud services an edge device will connect using a protocol like MQTT or AMQP or HTTPS over the Internet IP. Devices that support IP can communicate directly. Applications in the Cloud servers, which can be accessed by authorized users, can then make use of the data in creative ways and monitor and control the devices. The ability to connect to a set of services via a ready-made hub that offers privacy and security along with services offered as subscription can go a long way toward getting the target application working and supported. Solutions such as this also offer a friendly environment for the development of further applications to expand the capabilities of the networked devices (Figure 2).
Figure 2: Microsoft Azure provides are ready-made Cloud environment and connectivity for IoT devices to communicate their data, be monitored and receive commands from authorized personnel.
Development Tools
The Unison approach to development tools is to provide an environment that is inexpensive yet versatile and expandable, giving the developer the opportunity to put together just the right environment for their projects. This means a strong emphasis on Eclipse-compatible integrated development environments (IDEs), which are available from multiple vendors for the range of processors supported by Unison. Since they are Eclipse-compatible, these tools suites from multiple vendors fit easily into the Eclipse-based Remedy IDE for Unison, giving the developer a minimum of an editor, a compiler tool chain and a debugger in addition to any other tools included in that vendor’s IDE.
RoweBots also offers the GNU C/C++ compiler (or a substitute compiler) for all supported processors. Embedded C/C++ developers have been migrating towards the GNU C/C++ compiler as their compiler of choice for some time. It is well known to offer reliable operation on a broad set of hardware targets with relatively low costs. The plug-in nature of the Eclipse IDE makes it easy for developers to switch out or add in Eclipse-compatible tools as needed.
In addition to the basics, there are two important tools supplied at no additional cost with the Unison RTOS. These are the Remedy RTOS Viewer and the Remedy RED Analyzer, which are specifically designed for developing with Unison. The Remedy RTOS Viewer is integrated along with the IDE to support the tool suites from Keil, Mentor Graphics, Texas Instruments, Microsemi and more. Since it is integrated with the IDE, it can view all registered objects and internal kernel structures in the Unison environment, including semaphores, and their count, message queues and mutexes as well as threads and their status including stack usage and current state and memory pool status. Updates are made automatically to the information each time a breakpoint is hit.
The Remedy RED Analyzer features three types of analysis: Remote control features to set target variables and control dynamic event tracing, Event time-based triggering and displays, and Data collection, transfer and display. Using these features and their graphic displays allows a developer to visualize the timing and resource usage inside the Unison operating system and tune it to exactly fit the application’s needs. Remedy RED consists of a host-based viewer and a remote-control server and data logger on the target system (Figure 3). The logged data is sent to the viewer where the user can examine it in different views for detailed analysis. The user can also set triggering and logging options, collect and view the data and zoom in on problems.
Figure 3: The Remedy RED Analyzer gives the developer full insight into the timing and resource utilization and behavior of the Unison RTOS.
One example of a Remedy RED Analyzer application is analyzing complex timing issues. For example, a system that has a broad set of I/O may rarely encounter a condition that leads to a system crash. The crash seems random and data collection is difficult. Using the Remedy RED Analyzer, the problem can be traced, and a diagnosis made by setting up a trace on the suspected I/O and a trigger event to capture the conditions leading up to the crash. Examination of the crash data can then turn up clues to the failure. The user can expand the scope of the data to achieve a complete analysis and solution to the problem. Many other cases involving multithreaded timing behavior can be quickly captured and analyzed.
One other important tool supplied with Unison is the Remedy Bootloader. The bootloader allows a new program to be installed on the target system, which is useful both during development and for field upgrades since it can be done remotely. The bootloader also had an encryption/decryption option, which is important for doing secure remote updates. The reboot phase will flash or copy the program into execution memory and transfer control to the new program. If the new program fails, then the program will generally revert to the backup program and program this image. This approach is used to ensure that field service or product return is avoided at all costs.
Building on a solid platform starts with the Unison RTOS, which is itself lean, built on standards like the POSIX API for interchangeable modules, protocols and drivers and adaptable, so applications can be easily enhanced, ported and customized for user demands. It includes a rich set of security features that can be put in place at the foundation to build a secure system and application set. The ability to build in safety is supported by determinism and zero boot time, which make it able to respond to an unsafe condition can be halted immediately and brought back to a safe condition or the device diverted to an emergency action for remedy.
Unison also provides completeness and connectivity through its rich set of available wireless and other communication modules, its support of memory, mechanical, display, camera, touch sensor and other sensor systems along with more universal connectivity via USB. And, importantly, Unison provides Cloud access with a broad set of protocols that can be used on the Cloud side to easily and securely connect and transfer data and process commands. Keeping up with developments in the Internet of Things requires the latest components and tools to deal with it and its newer applications. In the Unison RTOS world this means the ability to work with other leading-edge applications like Microsoft Azure. That includes the ability to make use of the latest tools and IDEs as discussed above.
Starting from the Unison platform, Unison MedicalOS takes that solid set of characteristics and focuses them to the needs of those developing wearable technology. The core components of the Unison RTOS, the wireless communication protocols, the ready to go support of a rich set of sensors and peripherals, tiny graphics packages and Android connectivity, power management, a selection of MCUs and more put a set of components and tools into the developer’s hand to get started adding value from day one.