TECH REPRINT

w w w . m e n t o r . c o m

T apps while the core IVI system might be based on the Linux platform. A similar multi-OS industrial scenario may involve a real-time operating system (RTOS) for key real-time control functionality while Linux®, the general purpose operating system (GPOS), delivers a user interface and supervises data communication.

Code module isolation using an MMU/MPU under an RTOS A real-time operating system with an isolated process model, such as the Nucleus® RTOS from Mentor Graphics, provides the ability to make use of the Memory Management Unit (MMU) available on many System-on-Chip (SoC) devices to isolate and protect code mod-ules. Figure 1 illustrates how real-time control tasks can share the protected memory region of the kernel, while the other software tasks are separated into their own protected memory regions. The functions of connectivity and remote

he Internet of Things (IoT) is a trend that spans many industries such as smart home appliances, automotive, wearables, and medical devices to name a few. As we increase our reliance on these connected devices and the information they provide, factors such as up time and reliability play an essential role in their success and in the IoT ecosystem at large. A smart appliance in the home and an automotive infotainment head unit are representative of a large class of IoT systems that require both connect-ivity and highly reliable execution.

A smart appliance such as a washing machine has a rich user interface (UI) capable of handling any number of instructions. Such a device can be con-trolled remotely from a smartphone and communicate with the electrical grid to schedule the wash during an off-peak time when costs for electricity are lower.

The washing machine of course, must per- form one function very well and reliably – the function of washing clothes. Indus-trial systems have even more stringent real-time control requirements and it’s important to guarantee that real-time control and other critical operations are capable of functioning independently of the higher level features.

The automotive industry is also investing in the connected car for use cases such as gathering telematics data as well as addressing consumer expectations by providing updateable and downloadable applications (apps) for in-vehicle info-tainment (IVI) systems. Automakers face a great deal of scrutiny to ensure IVI sys-tems are safe. App downloads cannot be allowed to interfere with more critical features of an IVI system such as the video feed of a rear facing camera. In this case, an operating system like Android may be a viable option for delivering

By Felix Baum

Strategies for Ensuring the Reliable Operation of ConnectedInternet of Things (IoT) Devices

2

w w w . m e n t o r . c o m

update share the same region, while the UI and other application tasks are assigned to another isolated region. This approach to isolating application subsystems pre-vents functions in the connectivity or user interface application subsystems from corrupting the kernel or real-time control operations.

One of the advantages for using an RTOS over a GPOS is the real-time nature of the underlying kernel. An RTOS provides hard, real-time scheduling with guaran-teed runtime for high priority tasks. A process model capable RTOS maintains deterministic, real-time scheduling while adding the memory protection. The memory protection does not alter the priority of tasks, nor system responsiveness. Figure 2 shows that the user application (Task 7) and the remote update task, while in separate isolated memory regions, can execute at the same priority level while the control and connectivity tasks exe-cute at a higher priority. This is a significant departure from the way processes are implemented on a general purpose OS. In the protected RTOS environment, the developer is free to adjust the priority of tasks individually without the need to combine them into a common memory region.

A process model based RTOS also allows the process modules (the collection of tasks and library function within a com-mon isolated memory region) to be loaded and unloaded dynamically during system operation. In addition to the obvious ability to update a system, this allows the developer to dynamically re- configure a device to different modes of operation and switch between different configurations of task isolation and priority.

Implementing multi-OS applica-tion with a type-1 hypervisorMulticore processors found in today’s embedded devices provide greater pro-cessing capability and connectivity options.

These devices make the consolidation of multiple operating systems a viable and safe approach to introducing connect-ivity while insuring the proper execution of more important functions. Even in industries where safety is extremely important, such as automotive, consum-ers now have expectations that the IVI systems provide access to applications found on the smartphones and tablets.

Before IoT and the connected vehicle, safety and reliability were achieved via physical separation, with multiple yet separate processors on the same or sep-arate boards to ensure robustness of the design. With consolidated embedded

systems today, a recommended approach to introducing connectivity is to use multiple operating systems separated by a type-1 hypervisor, which in effect, sep-arates and virtualizes the device resources and ensures that essential vehicle func-tionality is given priority over connected applications.

Figure 3 (next page) illustrates how a hypervisor, such as the Mentor® Embedded Hypervisor, can be used for a vehicle infotainment system where connected application functionality is implemented in Android and the rest of the in-vehicle infotainment system based on Linux.

Figure 2: Process model separates critical regions within an RTOS.

Figure 1: Separating control from connectivity and remote update through a process model.

3

w w w . m e n t o r . c o m

A hypervisor goes beyond the simple separation as depicted in figure 3. It also provides a mechanism to restrict access of peripherals to specific application domains. In the case of an IVI system, we may want to limit access to the vehicle CAN bus by only allowing the vehicle infotainment system to access CAN data and for the connected apps in Android to only access data through inter-processor communication (IPC) with the Linux-based vehicle infotainment application. At the same time we would like both Linux and Android to have access to the local SD card for access to media files. Figure 4 illustrates how a hypervisor allows us to directly map peripherals as well as to paravirtualize them. This allows the developer to restrict access to the CAN bus while sharing other resources such as the SD card.

Testing for reliability in real-world scenarios So far, we’ve illustrated two possible approaches to designing IoT systems, the use of an RTOS and a type-1 hypervisor.

There are of course, many different perm-utations and the ideal approach will depend on a specific device. All connect- ed systems however will benefit from some level of testing to ensure they operate correctly in the field. Automated security testing to flood and stress test connected devices is one example where failures in the protocol stack or process control functions can be examined. In

addition, the functional health of a device can be determined during the simulated attack. Other tests that should be per-formed include sending invalid or fragmented packets, and also executing test frameworks exploiting known vulner-abilities in software stacks. Performing these tests can increase the overall robustness of the connected device as it’s deployed into the field.

Designing for updatability Users of mobile devices are familiar with the need to upgrade their device frequently, to patch bugs, add security updates, or increase device performance – all of which is accomplished effortlessly “over the air.” Both a process model based RTOS and the use of a type-1 hypervisor facilitate the design of embedded systems which can be updated over the air in a secure manner. By isolating application subsystems that can be dynamically loaded and unloaded, both of these approaches make it possible to update specific subsystems over time, fixing bugs or addressing reliability issues found during deployment and operation in the field.

Figure 3: Separating connected apps in a guest operating system with a type-1 hypervisor.

Figure 4: Using a hypervisor to isolate and share peripherals.

©2016 Mentor Graphics Corporation, all rights reserved. This document contains information that is proprietary to Mentor Graphics Corporation and may be duplicated in whole or in part by the original recipient for internal business purposes only, provided that this entire notice appears in all copies. In accepting this document, the recipient agrees to make every reasonable effort to prevent unauthorized use of this information. All trademarks mentioned in this document are the trademarks of their respective owners.

For the latest product information, call us or visit:

MGC 10-16 MISC2590-w

w w w . m e n t o r . c o m

ConclusionThe breadth of IoT devices and related functionality often requires developers to integrate code from numerous sources including home-grown, commercial, and open source. All of these increase the risk of negatively impacting the responsiveness and reliability of a connected IoT device. Using an RTOS with a process model to isolate application subsystems and a type-1 hypervisor to consolidate multiple operating systems are valid approaches to introducing connectivity in applications and systems that require a high level or reliability in their execution.

Author’s Bio: Felix Baum is a senior poduct manager with Mentor Graphics Embedded Systems Division, overseeing embedded virtualization and multicore, multi-OS technologies. He currently leads product marketing and management efforts for real-time operating system capabilities. Prior to his current position, Felix worked in business development with strategic alliance partners around the globe Felix has also consulted customers on the development of highly optimized devices for a broad range of industries. Felix started his career at NASA’s JPL designing flight software for various spacecraft and satellites. Felix holds a master’s degree in Computer Science from the CSUN and a Master of Business Administration from the University of California at Los Angeles.

In addition to selecting the appropriate system architecture and technology approach, designers must also add in time for additional testing to ensure correct operation and consider the full operational lifetime of the device with the ability to update device software quickly, seamlessly, and as effortlessly as possible.

The registered trademark Linux® is used pursuant to a sublicense from LMI, the exclusive licensee of Linus Torvalds, owner of the mark on a worldwide basis. ARM, TrustZone, and Cortex are registered trademarks of ARM Ltd.

For more information on Mentor Embedded Hypervisor, please visit the Mentor Embedded Hypervisor Website.

Click here for more information on Nuclues RTOS or Mentor Embedded Linux.