Author:
Muhammad Shafique, solution architect, Mentor a Siemens company
Date
09/26/2017
PDF
Figure 1: Example of Arm’s TrustZone technology demonstrating compartmentalization.
Today’s Industrial Internet of Things (IIoT) is rapidly changing how connected devices are enabled in modern heterogeneous multicore system-on-chip (SoC) architectures. These multicore environments reduce operational and maintenance costs by converging what were previously multiple discrete functions on a separate processor into a single, multi-functional SoC.
But a major obstacle when enabling this type of convergence is often the competing requirements of various discrete functions such as safety certification, real-time response, UI/HMI, and network connectivity to name a few.
This article discusses various ways discrete functions can be isolated on a single piece of silicon using technologies that include hypervisors, Arm TrustZone, and a multicore framework.
The industrial robotic arm
In the past, embedded control systems were designed using a single processor with one function in mind. Today, in order to achieve complete system control multiple discrete processors must be connected together.
To understand this better, let’s use an industrial robotic arm as a system available commercially as a standalone unit. In addition to the mechanical arm, it includes an electronic control unit and HMI display. The HMI enables manual operation or by programing a sequence of moves (script), it can perform without human intervention. In a real-world scenario this type of operation might include stacking items as they exit an assembly line.
In addition to the HMI and process control, the robotic arm controller implements safety interlocks. These interlocks can be used to shut down robotic arm operation in case of emergency and are programmed to various types of sensors e.g., proximity switches, pressure sensors, safety beam, etc. And because this is an IIoT enabled unit, it must also connect with an external network infrastructure. So we can add a fourth processor to perform network communications and handle the firewall and various other associated activities.
It’s important to note that each single function has different processing needs, and consequently, each function requires a different type of processor.
Granted this is fairly simplistic view of an industrial robot unit with four processors, with each processor responsible for a discrete function. It is perfectly fine to realize this design in this discrete way. It will require building multi-processor PCBs or multiple PCBs, defining communication architecture between the processors, and integration testing at both the hardware and software levels.
Multicore development – not always about performance
Embedded software has seen a proliferation of multicore SoCs. There are obvious situations where embedded systems need more computational power (e.g., network throughput for richer UI graphics), but in most situations, it’s more about reliability, responsiveness, power consumption, cost effectiveness, and maintenance over an extended period of time.
So what is the primary factor for using multicore in embedded? The answer is – convergence of functionality. Convergence means combining different forms/components of technology into a single entity. From our robot example, if there is a way to utilize a single multicore processor to perform “Safety Controller”, “HMI/Operator Console”, “Process Controller”, and “Network Controller” significant cost savings would be achieved in BOM and in hardware. Embedded devices typically have a long life and reduced BOM means fewer hard components to track and inventory over the lifespan of a device.
The key challenge in multicore convergence is to maintain individuality of each discrete function. When looking at the robotic arm scenario, the processor used for the Safety Controller does not require much computational power. The most important requirement is to reliably read data from safety sensors and drive related actuators when needed. The code executing safety functions is typically subject to compliance requirements (IEC 61508 for industrial or ISO 26262 for automotive). On the other hand, the HMI/Operator Console requires a more computationally capable environment supporting rich graphics frameworks or multimedia capabilities with no safety requirements.
If we want to use one multicore processor to implement both Safety Controller and HMI/Operator Console functions we need strong compartmentalization, or a partitioning mechanism that can create different execution context; one high priority context for Safety Controller and another context for HMI (which is less critical). It’s important to make sure that non-critical code executing the HMI does not interfere or block any of the functions of the Safety Controller at any time.
Various technologies that enable isolation/compartmentalization include:
-Embedded Hypervisor
Often a hypervisor is the first thing that comes to mind as this type of technology has been the convergence enabler for the desktop and server domains. With virtualization extensions now available on multicore SoCs, this is certainly an option. A hypervisor is a software component that creates an abstraction on top of hardware, allowing multiple guests operating systems to run simultaneously side by side.
-Arm TrustZone
The Arm TrustZone (Figure 1) can run a secure operating system (secure world) and a normal operating system (normal world) at the same time from a single core or multiple cores, thus enabling a form of compartmentalization. TrustZone is hardware-based feature where software running in normal world is blocked from accessing secure world resources directly.
-Multicore Framework
Processing cores running in an asymmetric multiprocessing (AMP) configuration can help assign individual functions to various cores. A multicore framework (such as Mentor’s framework depicted in Figure 2) assists with life cycle management and helps facilitate communication between various participating cores, which can be very useful.
Click image to enlarge
Figure 2: Mentor’s multicore framework approach which helps to utilize and manage multiple available homogeneous or heterogeneous cores on a multicore processor.
Putting it all together
To illustrate embedded multicore enablement and convergence, let’s revisit the automated robotic arm. The robotic arm is a giant machine capable of performing heavy duty tasks. While the robotic arm is moving we do not want any human presence in the work area as this could create a hazardous situation. To avoid unsafe situations, we introduce safety beam safety interlocks where a laser beam cordons off the entrance to the robot work area. If anyone enters the area and obstructs the safety beam, the robotic arm quickly stops moving and latches into a safe position.
When the safety beam is broken, in addition to latching the robot into a safe position, the system generates an alarm on HMI/Operator Console so that a corrective action can be taken.
If we take the traditional approach to architecting this type of system, we use one discrete processor to drive the HMI/Operator Console, one processor to control the robotic arm, and another processor to implement the safety domain.
However let’s follow a multicore SoC approach to better demonstrate system convergence.
First, we select the NXP i.MX6 homogeneous quad-core processor to implement the system. Figure 3 depicts how this system is constructed at a higher level.
Click image to enlarge
Figure 3: This robot application leverages Arm TrustZone hardware extensions to realize a mixed-critical environment on single SoC where real-time safety functions are isolated from the HMI context.
Each of the TrustZone partitions is running an independent instance of Mentor’s Nucleus RTOS. Nucleus utilizes Arm TrustZone technology and the OpenAMP-based multicore framework to do life cycle management and enable communication between secure and normal worlds.
The secure world Nucleus application is responsible for the safety beam functionality and rendering safe graphics on the HMI/Operator Console. This is called the “Safety Domain” and is represented by the red dotted line in the shaded box in Figure 3. Whenever secure world Nucleus detects safety beam obstruction via laser detector it sends a command to the robot to stop moving and enters into an alarm state. Real-time status of safety beam and alarm state is animated on the HMI/Operator Console.
The normal world Nucleus application is used for the user interface to drive the robot and control its movement. This application also provides information on robot movement.
Notice that both secure and normal world Nucleus applications are rendering on a single display unit (HMI/Operator Console). This implementation uses layered graphics architecture with safe graphics overlaying on top of non-safe graphics.
As the secure world has higher priority over normal world, the safety functions are always available, even if the normal world is shut down or corrupted.
So in effect, we have a single i.MX6 SoC fulfilling rich graphics, real-time control, and safety functions at the same time without compromising any of the discrete functions i.e., acting as both a Safety Controller and HMI/Operator Console.
Conclusion
The converged software architecture brings significant benefits and cost savings. It is possible to combine safe and non-safe software on multicore SoCs by using technology components such as hypervisors, multicore frameworks, and Arm TrustZone. These components help maintain individuality of discrete functions and provide the much needed isolation.
