Download this article in PDF format.
A modern factory is a far cry from Henry Ford’s 1913 assembly line. That plant revolutionized manufacturing, but the introduction of industrial computing in the 1950s marked the beginning of electronics on the shop floor. Those initial innovations led straight to the factory of today, with advanced robotics, high-speed networks, real-time control, and thousands of intelligent nodes to monitor and report on every aspect of manufacturing operations.
Sponsored Resources:
1. A broad selection of functions is needed to cover the needs of an automated factory.
A typical factory automation system contains three main levels (Fig. 1), also known as tiers or nodes, that drive real-time communications and control. Each of these levels requires its own set of optimized hardware and software solutions. The three levels are:
Field level: I/O modules, actuators, and drives operate the motors, valves, and other machines, plus gather data about machine status and process variables.
Control level: Programmable logic controllers (PLCs) or computer-numerical-control (CNC) machines collect information from, and issue commands to, field-level devices. PLCs have varying levels of capability based on their processing ability, number of connected nodes, cycle times, number of supported protocols, and more. Fanless operation is a must, so low power consumption is a key requirement.
Operator level: Human-machine interface (HMI) devices provide a visual interface to human operators and relay commands from them to the control level. Like PLCs, industrial HMIs come in varying levels of complexity, and must function within a factory environment that requires fieldbus connectivity and low-power fanless operation. As shown in Fig. 1, the HMI is increasingly built around a graphical user interface (GUI) with touchscreen capability.
Connectivity, Reusability, and Scalability are Keys to Success
Reliable communication between all systems in the factory is key to coordinating complex industrial processes.
The factory automation architecture must support multiple industrial fieldbus protocols to accommodate the current and legacy standards already used in a factory. The most common fieldbus standard is an industrial version of the ubiquitous Ethernet protocol, such as EtherCAT, PROFINET, or Ethernet/IP, but other standards like CAN are also popular. A deterministic network—one in which no random variations in propagation times occur between messages—is also important for automated applications, spurring the development of industrial Ethernet protocols with deterministic data delivery.
In terms of hardware, a factory automation PLC requires a rich set of peripherals and interfaces since it communicates on multiple levels. Not only does it need the physical-layer ports for fieldbus networks, but also digital input/output (I/O) ports; analog interfaces for sensor outputs; power drivers for valves and actuators; interfaces to brushless dc (BLDC) motor controllers; and more.
Supporting multiple protocols poses a complex challenge for the designer. A hardware-based approach—changing protocols by swapping out an application-specific integrated circuit (ASIC), for example—poses a logistical problem because each protocol may require its own specific device. It’s much simpler if the fieldbus protocol can be modified with only a software or firmware change.
Software development represents a major investment in a factory automation application; therefore, maximizing software reuse is critical for reducing both time-to-market and overall development cost. The hardware platform should be scalable so that the same software can be applied across multiple applications.
Virtualization and Its Use in Embedded Systems
The standard software architecture in an automated factory is designed to provide real-time control of the field-level devices, using a real-time operating system (RTOS).
The move toward Industry 4.0, also known as the Industrial Internet of Things (IIoT), is placing new emphasis on uploading massive amounts of data to the cloud for offline activities such as predictive maintenance. To implement this feature, IIoT designers must add cloud connectivity and non-real-time functions to the existing software architecture without compromising or interfering with critical real-time tasks.
The technique of virtualization offers a powerful solution. Virtualization refers to the act of creating a virtual version of an underlying hardware resource. A desktop or laptop, for example, can contain several virtual hard-disk drives. Each one is a software component that emulates an actual disk drive. To the rest of the system, the virtual drive looks and behaves like an actual physical device.
Virtualization can be divided into two categories: full virtualization or static partitioning, also called core virtualization.
A full virtualization scheme simulates the hardware environment so that the virtual environments aren’t tied directly to the underlying hardware partitions. For example, one physical core can be divided into two virtual cores, each one running a different operating system (OS).
A static partitioning scheme isolates programs or tasks to certain portions of the existing hardware to simulate separate systems. Unlike full virtualization, the software partitions are bound to the hardware partitions.
2.The two main virtualization schemes look very similar on the surface, but are optimized for different applications. (Source: TI: “Virtualization for embedded industrial systems” PDF)
Figure 2 compares the two approaches. Each system contains two hardware CPUs (CPU0 and CPU1), and runs more than one OS, but the full-virtualization scheme includes a layer with three virtual CPUs on top of the hardware CPUs. In this implementation, CPU0 runs Linux, and CPU1 runs two Oss—another Linux kernel and the RTOS. The two CPUs share memory and I/O resources.
The static partition, in contrast, runs one OS per physical core—Linux on CPU0 and an RTOS on CPU1. Each CPU has its own dedicated memory and I/O. If one CPU resource is fully committed, it can’t draw upon the other partition for help.
Both schemes enable the separation of isolated tasks (e.g., sharing a system among multiple users) or the separation of critical tasks from less-critical tasks (e.g., separating a secure domain from a general-purpose domain). Full virtualization further enables you to suspend entire OSs to persistent storage or even live migration from one physical processor to another over a network connection. Static partitioning trades off this flexibility for some guarantees of determinism.
Both approaches have their advantages and disadvantages. An enterprise or data-center environment has immense CPU and storage resources. In such a setting, full virtualization can enable a single server to act like hundreds of servers. On the other hand, multiple software instances can try to access the same hardware resources simultaneously, slowing down the latency of a given process to meet a system metric such as average throughput or transactions per second.
An embedded system has limited hardware resources and runs a limited number of virtual environments. It also prioritizes real-time operation with determinism and guaranteed latency; these requirements must be paramount.
Both fully virtualized and statically partitioned systems can separate tasks by priority level, whether related to security, safety, or real-time operation. However, the timing of tasks is less affected in the partitioned system, since its physical resources couple more directly to the virtualized environment. This makes the partitioned system more suited for resource-limited embedded designs.
Virtualization in HMI Applications
Virtualization has uses in a factory automation application beyond combining a critical real-time application and less-time-critical networking functions.
Consider the HMI. A well-designed HMI provides the operator with critical information that helps the decision-making process while reducing workload. This involves a lot more than simply grafting a fancy screen onto an existing design. The HMI designers must be intimately familiar with the relevant details of the industrial process and its operating procedures so that they can develop an effective GUI.
An HMI system’s effectiveness is determined by its processing power, its ability to render complex images, its fast response time to user inputs, and its flexibility in handling various levels of operator interactions.
Several graphics frameworks are available to help the HMI designer. Qt, for example, is a well-known application framework and widget toolkit for creating GUIs. Qt and its competitors run on most common OSs, so it’s simpler to implement an HMI design on a Linux platform than it would be to fit it into an RTOS.
However, a Linux-only solution would not be a good choice for critical real-time functions such as PLC logic control, protection algorithms, or motion control. One option might be to separate the HMI and the control into two separate processors on the board. However, this increases the size, cost, and overall power consumption. A better solution is to run both tasks on a single CPU and use a virtualization scheme to maintain separation between the two OSs and their respective tasks.
Sitara and Factory Automation
TI has developed the Sitara family microcontrollers to solve some of these tricky factory automation problems and accommodate a diverse set of industrial applications. Sitara comprises a scalable portfolio of single-chip solutions that combines Arm Cortex-A cores and coprocessors with flexible peripherals for real-time communications, as well as optional graphics and display functions for user interfaces. Sitara also includes full software support for popular fieldbuses.
3. With a choice of cores and a rich peripheral set, the Sitara family can meet the full range of factory automation requirements. (Source: TI Products: Sitara Processors)
Figure 3 shows the Sitara products for factory automation. The AM335x series is optimized for low cost, but still integrates an Arm Cortex-A8 core running at up to 1000 MHz. Four models include a dual-core programmable real-time unit (PRU) coprocessor, discussed below, and three add a 3D graphics accelerator.
The AM4x series upgrades the core to an Arm Cortex-A9 running at up to 1000 MHz. Included are a 3D graphics accelerator and security features such as a cryptographic accelerator, a secure boot option, and a quad-core PRU.
The AM5x upgrades the CPU yet again, to a Cortex-A15 processor that delivers twice the performance of the Cortex-A9 (Fig. 4). Devices in this series include single or dual 3D accelerators, a C66 digital signal processor (DSP), and multiple Ethernet ports.
4. The Sitara AM5728 includes a quad-core PRU, advanced security features, and a large variety of I/O options. (Source: TI Products: Sitara AM57x Processors)
How does Sitara simplify some of the factory automation challenges discussed earlier? Let’s look at a couple of examples.
Sitara Virtualization: Jailhouse Hypervisor Support
A virtualization scheme, whether full virtualization or static partitioning, requires underlying software to create the virtualization framework. This underlying software is called a hypervisor. It manages guest machines, guest OSs, and the sharing of actual physical resources by virtualized systems.
The Sitara microcontroller can run several virtualization solutions, but the Linux edition of TI’s Processor SDK (software development kit) supports Jailhouse, an open-source hypervisor, as part of the standard configuration.
The Processor SDK is a unified software platform for Sitara and other TI embedded processors. It provides easy setup and fast out-of-the-box access to benchmarks and demos. All releases of the Processor SDK are consistent across TI’s portfolio, allowing developers to seamlessly reuse and migrate software across devices. The Processor SDK includes support for Linux, TI-RTOS, and Android operating systems.
Why standardize around Jailhouse?
- It supports partitioning, which is better suited to embedded resources than full virtualization.
- It’s more lightweight than other open-source hypervisors.
- It’s optimized for simplicity rather than a large feature set.
Once Jailhouse is activated, it takes full control over the hardware and needs no external support; i.e., it runs “bare metal.” Unlike other bare-metal hypervisors, however, it’s loaded and configured by a normal Linux system. This simplifies its use and quickens adoption.
Because it’s lightweight, constrained to hard-partitioned resources, and doesn’t require high computing power or large amounts of memory, a Jailhouse-virtualized system can achieve comparable real-time performance to a nonvirtualized system. This makes Jailhouse a good fit for embedded applications, especially where two tasks or systems run side by side with mixed levels of real-time goals.
TI has developed a reference design showing the use of Jailhouse in the Sitara AM572x. The reference design runs Linux on one ARM Cortex-A15 core and bare metal on the other core.
Sitara’s PRU-ICSS Simplifies Real-Time Connectivity Challenges
As we’ve discussed, real-time control is a critical component in factory automation success.
But high performance in a general-purpose processor (GPP) running a standard high-level operating system (HLOS) doesn’t necessarily equate to success in real-time operations. That’s because the two tasks require different feature sets.
A GPP typically includes instruction pipelines and memory and interconnect architectures with several layers. Depending on the precise path taken to access data, its response time will vary. This makes it difficult to provide the predictable and guaranteed low-latency response times needed in a real-time application.
Such variation also causes problems when interfacing to a deterministic fieldbus. An Ethernet time-sensitive network (TSN), for example, adds guaranteed latency to standard Ethernet operation, specifically to handle industrial real-time control applications.
How do designers achieve both capabilities in their designs?
Adding an external ASIC or FPGA to handle real-time operations is one option, but Sitara MCUs include a specialized coprocessor subsystem, the PRU, that eliminates the need for an external device and simplifies interfacing to industrial communication networks.
Each PRU subsystem (Fig. 5) consists of two 200-MHz real-time cores, each with a 5-ns cycle time per instruction. Since the real-time cores aren’t equipped with an instruction pipeline, single-cycle instruction execution is ensured. The PRU’s small, deterministic instruction set with multiple bit-manipulation instructions is easy to learn and use.
5. A general-purpose core supplemented with real-time coprocessors simplifies the job of real-time control. (Source: TI: “Ensuring real-time predictability—Leveraging TI’s Sitara processors real-time programmable unit” PDF)
The PRU architecture gives the SoC direct and fast access to the outside world—each PRU has its own single-cycle I/O, plus its own set of up to 30 inputs and 32 outputs that directly access external pins.
Local memory and peripherals dedicated to each real-time engine means that each unit can guarantee low-latency responsiveness. An incoming interrupt can access a real-time processing engine directly without encountering the delays caused by crossing the several layers of interconnects and memory in the GPP.
The PRU is integrated into the Sitara AM335x, AM437x, and AM5x processors, plus the AMIC110 multiprotocol, programmable, industrial communications processor that supports more than 10 Ethernet protocols.
Using the PRU for Fieldbus Communication
The PRU hardware block can be applied to any real-time application, such as driving a stepper motor, but it’s particularly well-suited to a low-latency fieldbus design.
TI offers the PRU-ICSS protocols to assist in communication development. These run on top of Processor-SDK-RTOS and include optimized firmware, a driver for the selected ARM processor, and example applications.
Multiple Ethernet, fieldbus, interface, and redundancy protocols are offered at no charge, including certified solutions for EtherCAT, PROFIBUS, and PROFINET. The PRU-ICSS can support multiple protocols on the same hardware using firmware supplied by TI, through the Industrial Software Development Kit, or from industry partners.
Sponsored Resources: