Robots that can man-handle car bodies incorporate several safe guards to protect workers. New software architectures have evolved to make these systems reliable and easy to manage.
Muhammad Shafique | Mentor Graphics • Embedded Systems Div.
The industrial automation industry is rapidly making use of today’s heterogeneous multicore system-on-chip (SoC) architectures. These multicore environments help reduce operational and maintenance costs by combining functions once handled by separate processors and putting them on a single, multi-functional SoC (system on a chip).
However, a problem can arise when combining functions on an SoC this way: Each function can have requirements – in the form of safety certifications, real-time response, rich UI/HMI, and network connectivity functions to name a few – that compete for scarce resources. But there are various ways discrete functions can be isolated on a single piece of silicon using technologies such as hypervisors, ARM TrustZone, or a multicore framework. To understand these approaches, it can be helpful to study an example. So consider the case of a mixed safety-critical application comprised of an automated robotic arm used in an IIoT (industrial internet of things) factory setting.
Traditional embedded control systems were designed with a single processor and one function in mind. Today, it is more often the case that embedded systems incorporate multiple discrete processors. The industrial robotic arm serves as an example. In addition to the mechanical arm itself, it includes an electronic control unit and HMI (human machine interface) display. The HMI enables manual operation or movement by programming a sequence of moves (script) that can take place without human intervention.
The robotic arm controller handles the HMI and process control and also implements safety inputs/interlocks. These interlocks can be used to shut down the arm in an emergency and are programmed to take inputs from various types of sensors, for example, proximity switches, pressure sensors, and safety beam. The IIoT connection means the robot connects with an external network. So an additional processor might be incorporated to perform network communications and handle the firewall and various other associated activities.
It’s important to note that each robot arm function has different processing needs. Consequently, it requires a different type of processor. Let’s identify and/or explain those needs:
• HMI/Operator Console: The processor should be a high-end application processor with rich graphics support such as an ARM Cortex-A with GPUs.
• Process Controller: This is a relatively high-end processor with use-case specific features. For example, it could be a DSP if the primary function involves processing a large amount of data as in image processing. The controller can be an ARM Cortex-A, Cortex-R, or a DSP core.
• Safety Controller: Requires a relatively low-end processor as its sole purpose is to execute safety interlocks. This could be an ARM Cortex-R or Cortex-M. Software running on this processor typically needs to go through safety certifications such as IEC 61508.
• Network Controller: The processor may have some additional network communication capabilities, for example, radio or communication interfaces to talk with other IoT nodes. This can be an ARM Cortex-A or Cortex-M device.
This is a fairly simplistic view of an industrial robot. The design will require multi-processor PCBs or multiple PCBs, defining a communication architecture between the processors, and integration testing at both the hardware and software levels.
Multicore in embedded
In past few years, multicore SoCs have proliferated. However, multicore in the embedded space is not entirely about computational performance. There are some obvious cases where embedded systems can use more computational power e.g., network throughput or rich graphics. But in most situations, embedded systems are designed to excel at other factors such as reliability, responsiveness, real-time behavior, safety, security, power consumption, low cost, and low maintenance.
So one might say the chief driving factor for multicore in embedded is a convergence of functions. Here convergence means combining different forms/components of technology into a single entity. In the robot example, there would be significant cost savings available if a single multicore processor could handle the four functions outlined above.
Another benefit of convergence is that of a simple software architecture where various functions can talk to each other using inter-processor communication (IPC) mechanisms. This is far less complicated than implementing complex communication protocols between discrete processors. A single multicore processor also needs less power than multiple discrete processors and less supporting circuitry. Moreover, individual cores can be turned off when not needed.
The key challenge in multicore convergence is to maintain the individuality of each discrete function. For example, when looking at the robotic arm scenario, the processor serving as 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 a rich graphics framework or multimedia capabilities with no safety requirements.
If we want to use one multicore processor to implement both the safety controller and HMI/operator console functions, we need a strong compartmentalization, or a partitioning mechanism that can create different execution contexts; one high priority context for the safety controller and another context for HMI (which is less critical). It’s important to make sure that non-critical code running the HMI never interferes or blocks any of the functions of the safety controller.
Various technology options can enable this compartmentalization.

Embedded Hypervisor: A hypervisor is a software component that creates an abstraction on top of hardware and allows multiple guests operating systems to run simultaneously side-by-side. Virtualization technology or the use of hypervisors has been a convergence enabler for the desktop and server domains for quite some time. Virtualization extensions are available on multicore SoCs so this is certainly an option to consider.

Multicore Framework: Processing cores running in an asymmetric multiprocessing (AMP) configuration can be assigned individual functions. Multicore frameworks assist with life cycle management and help facilitate communication between various participating cores, which can be useful.
ARM TrustZone: TrustZone is a hardware-based feature where software running in a normal world is blocked from accessing secure world resources directly. ARM processors with TrustZone can run a secure operating system (secure world) and a normal operating system (normal world) simultaneously from a single core or from multiple cores, thus enabling a form of compartmentalization.

These components can make a design look a bit complex and overwhelming. But the good news is there are embedded software vendors who can help. Multicore SoCs from semiconductor vendors and embedded software platforms from companies such as Mentor Graphics provide convergence-enabling software technology components that are pre-tested, hardened, certified, and available with long term support and maintenance options. Typically, these platforms are also packaged with required tooling to get all of this working.
To illustrate embedded multicore enablement and convergence using an embedded software platform, let’s continue with an example of the automated robotic arm.
While the robotic arm moves, humans should be kept away to prevent hazardous situations. Consequently, industrial robots often use safety beam interlocks where a laser beam cordons off the entrance to the robot work area. Anyone entering the area obstructs the safety beam, stopping the robotic arm and latching it into a safe position. Additionally, the system generates an alarm on the HMI/operator console so the operator can take a corrective action.

In this scenario, the three main components are the mechanical robotic arm operation (process), the HMI/operator console, and the safety beam. The traditional approach to architecting this system would use one discrete processor to drive the HMI/operator console, one processor to control the robotic arm, and one processor to implement the safety domain. However, let’s follow a multicore approach.
To begin, we select the NXP i.MX6 homogeneous quad-core processor to implement this system. In this design, each of the TrustZone separated partitions run an independent instance of the Nucleus real-time operating system (RTOS). Nucleus uses ARM TrustZone technology and the OpenAMP-based multicore framework to do life cycle management and enable communication between secure and normal world.
The secure world Nucleus application is responsible for both running the safety beam and rendering safe graphics on HMI/operator console. This is called the safety domain and is represented by the red dotted line and shaded box in the nearby figure. So whenever the secure world Nucleus detects a safety beam obstruction it sends a command to the robot to stop moving and enters 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.
An interesting point to note is that both secure and normal world Nucleus applications write to 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 ARM TrustZone secure world has higher priority than the normal world, the safety functions are always available even if the non-safe or normal world is down or corrupted.
So in effect, we have a single i.MX6 SoC fulfilling rich graphics, real-time control, and safety functions simultaneously without compromising any of these discrete functions (such as acting as safety controller and HMI/operator console).
There are numerous multicore homogeneous and heterogeneous SoCs available today that can converge and combine embedded software functions. The converged software architecture brings significant benefits and cost savings. Technology components such as hypervisors, multicore frameworks, and ARM TrustZone help maintain individuality of discrete functions being combined and provide the required isolation. To reduce time-to-market and simplify maintenance, it is also worthwhile to look at pre-baked multicore embedded software platforms from trusted software venders to complement today’s more sophisticated SoCs.
References
Leave a Reply