BY CLEMENS MÜLLER, Director, Business Development Robotics
Infineon Technologies
www.infineon.com
At the turn of the 20th century, Henry Ford, inspired by conveyor belt usage in grain warehouses, revolutionized automobile manufacturing. This, coupled with other efficiencies gained from assembly line production, allowed them to reduce the manufacturing time of a vehicle from over 12 hours down to almost 90 minutes. Today, most products are the result of cooperation between man and machine, with man protected from potential harm through doors, light barriers, and interlock mechanisms.
However, to benefit from further potential efficiencies, we need to move from simple cooperation to collaboration. Initiatives around Industry 4.0 are making robots more intelligent and, through their sensors, better equipped to interact with their surroundings. But one big question remains open: Can this revolution occur safely?
Safety in focus
The conveyor belt concept allows us to benefit from the speed and power of machines. At the same time, it restricts how products can be manufactured. As long as the products being manufactured are all the same, all is well. But today’s consumers are looking for options, customization, and uniqueness. This doesn’t fit into a linear manufacturing flow.
Rather than limit ourselves to this linear step-by-step process, innovations offered by Industry 4.0 allow us to consider alternative ways of implementing the manufacturing process. One method is to move to a collection of manufacturing islands, with each island completing an element of the manufacturing process. In this case, the product is ferried from one station to another, with each station completing its task.
This also provides the opportunity to deliver differentiated products. A basic model is required only to visit the key manufacturing stations, whereas a premium model is moved through additional stations for extra manufacturing steps.
In some cases, these manufacturing steps may require human interaction. For human-machine interaction to occur safely, a safety concept is required, which is defined at the very start of system development. This is common in the development of systems in other industries, such as automotive.
In the automotive industry, passengers are reliant upon electronics for maintaining control of many key systems. If they go wrong or fail to work completely, it can impact both bystanders and the vehicle’s passengers. Anti-lock braking systems, electric parking brakes, and power steering systems all fall into this category. As such products are defined and the control systems are selected, the implementation of functional safety must be considered at every stage.
Detecting failure
Devices such as the AURIX family of 32-bit microcontrollers are architected specifically for applications demanding high levels of safety integrity. They fulfill the strictest ISO 26262 safety requirements in the automotive industry and can, therefore, be used together with safety manual and dedicated safety software routines in systems that can fulfill IEC 61508, of which IEC 61513 is an adaption for machinery while IEC 61511 targets process industries.
To ensure that a failure in the processing element of a system can be detected, many functionally safe systems opt to use two different microcontrollers. One executes the application while the second monitors the first (Fig. 1 ). This approach ensures diversity across the control system: A software bug or failure in one device will not be replicated in the second device.
Fig. 1: To achieve sufficient diversity for safety-critical applications, two different microcontrollers are often used in a loosely synchronized dual-processor architecture.
The AURIX architecture achieves the same safety functionality inside the device through its diverse lockstep CPU, which uses the same 32-bit TriCore architecture as the main CPU. But this is where the similarity ends.
The lockstep CPU is physically isolated from its companion, and the layout of its circuitry is completely different (Fig. 2 ). Furthermore, the instructions are executed in the lockstep core with a delay of two clock cycles, providing protection so that events that may disturb the execution of an instruction in the main core cannot be replicated in the lockstep core. At the end of the delay, the outcome of instruction execution from the main and lockstep cores are compared with one another. In the event that they do not match, the processor can handle the error.
Fig. 2: The AURIX family of 32-bit microcontrollers achieves the necessary diversity for safety-critical systems with their diverse lockstep CPU.
Built-in self-test (BIST), executed at power-on, for the internal device logic also checks that the AURIX device is functional prior to executing application code. Further tests, such as a memory BIST, can be added to the application software. Infineon also offers software libraries, such as the PRO-SIL SafeTlib and SBST, to support embedded developers with their designs.
To ensure that the multiple processor cores cannot take control of each other’s peripherals or overwrite memory that is assigned to them, a memory protection system is in place. Furthermore, each peripheral and shared SRAM also has its own local access protection mechanism. When coupled with a hypervisor, it is also possible to execute mixed-criticality software while still maintaining real-time performance.
With a gigabit Ethernet, EtherCAT capable peripheral, and multiple CAN communication interfaces (Fig. 3 ), the second-generation AURIX family is an ideal platform for industrial robotics applications including autonomous guided vehicles (AGVs).
Fig. 3: Safety-critical applications, such as industrial robotics controllers, are an ideal application for the second generation of AURIX microcontrollers.
Providing safety now and in the future
Up until now, industrial robot arms have been developed independently from the tools that they carry. The power and control system for a welding tool is typically affixed via a bundle of heavy cables to the side of the robot arm. In part, this separation is linked to safety, allowing the robotic arm supplier to retain complete control of their safety-certified device regardless of whose tool is in use. If they were to share their communication busses and power systems with third-party tools, it would be challenging to provide the safety of the system.
With Industry 4.0 comes the need to network all systems and sensors, enabling the machines to communicate and collaborate with each other and their human operators. At the same time, this provides a potential security risk, a crack in the armor, that could be the entrance point for attacks.
Worse still is the potential for the addition of future add-ons and tools that have not had their security implementation suitably tested. Such elements could become a back door for network attacks or even reconfiguring industrial networked equipment and the robots themselves. With man and machine in such close proximity, there is a significant risk that life could be harmed if robots are reprogrammed or they rely on compromised sensor data.
Trusted tooling, sensors, accessories, and spare parts will be essential to provide safety and to ensure that network security is maintained in the factory of the future. However, in the fast-paced world of manufacturing, it is equally important that the implementation of the trusted system does not impede maintenance or spare part exchange, which would ultimately lead to extended downtime.
Like safety, security is not a bolt-on afterthought. Security must be built into the development process from the beginning to enable the protection needed while simultaneously being intuitive to use. In addition, safety and security are no longer independent subjects.
For collaborative automation systems, functional safety can only be realized if appropriate security measures have been taken. Any redundancy setup, as mentioned previously in the context of a safe microcontroller, will be exposed to unsafe behavior if, for example, critical calibration can be manipulated in an unauthorized fashion. For the AURIX microcontrollers, this has been addressed with an embedded security module.
Very often, however, there is no one-size-fits-all solution. For a consumable, a simple low-cost solution may be all that is necessary to determine whether supplier-approved parts are being used. A fully networked control subsystem, on the other hand, requires self-authentication with a trust anchor before being allowed to participate in a mission-critical production system.
Beyond mutually authenticating robotic machinery with control systems, it is essential that these systems are protected against data theft and manipulation. Robotic device integrity is upheld best by IP protection of calibration files, authentication of components, and secured logging to help identify attacks.
To safeguard the security of data, interfaces, and communication channels in smart robots and industrial networks, Infineon provides OPTIGA embedded security solutions designed for an easy integration.
Table 1: Infineon offers a comprehensive OPTIGA family of hardware security controllers to match various purposes.
As man and machine come into closer contact, a large part of the success of their collaboration will depend on trust. That trust can only be built up if we feel safe in the company of machines. Safety has to be built in from initial conception and continuously reviewed through to the completion of the robot, cobot, or AGV design.
But safe software can only be relied upon if it is unmodified and is communicating with a trusted network of systems, modules, and sensors. Thus, security is fundamental from the first instance, allowing highly complex robotic systems and their human operators to be authenticated for trust by upholding industrial device integrity.
Advertisement
Learn more about Infineon Technologies
