Increased Automation Challenges Embedded Safety Functionality

An increase in automation, in factories, in vehicles and in the IoT is driving the need for functional safety to be embedded in the digital portion of designs for industrial and automotive products.

Increasing levels of automation in factories means that safety and security are more critical than ever. More equipment and systems are communicating and operating over a network to monitor and analyze processes in the manufacture of end products.

Embedded systems used in the automation process need to foresee problems. And devices used must comply with safety standards. In self-driving cars and the Internet of Things (IoT), devices are also operating without operator assistance. In all three instances, there has to be a high level of system awareness. Reliable devices must be certified to meet a level of risk analysis and an acceptable probability of failure.

Functional Safety Standards

Functional safety can be designed into embedded systems, whereby the system meets certification requirements and detects potentially dangerous conditions. Importantly, the definition of functional safety includes “the activation of a protective or corrective device or mechanism to prevent hazardous events arising or providing mitigation to reduce the fight consequence of the hazardous event.” (IEC-Functional Safety Explained)

“Embedded systems used in the automation process need to foresee problems and devices used must comply with safety standards.”

Although the initial part of IEC 61508 was introduced in 1998, sector-specific versions followed, for example, oil production and non-nuclear power plants in 2001, but it was not until 2010 that it addressed industrial communication networks. Roger May, system architect and functional safety lead at Altera, believes that the 2010 European machinery directive has changed the way designers integrate safety into products. “[It] required all machines to be safe,” he says, “This has led to customers looking to add safety into the core of the product instead of as an add-on. As these safety designs are becoming more prevalent, then there is a knock-on impact across other markets/geographies which see the need to improve the safety of their products.”

An extension of the IEC 61508 is ISO 26262, which defines Automotive System Integrity Levels (ASILs), or risk analysis. Both of these standards assess hardware safety integrity and systematic safety integrity.

Industrial and Automotive Design

At this year’s SPS IPC Drives exhibition in Nuremberg, Germany, many companies highlighted the need for device and system level to work in harmony to reduce risk and time to market for industrial and automotive systems.

Infineon was one. It announced that its XMC4000 32-bit microcontrollers will be available with a Safety Package to help designers develop TUV-certified automation tests that conform to Safety Integrity Level (SIL) 2 and SIL3. These SILs, as defined in the IEC 61508, are 0.000001 – 0.0000001 and 0.0000001 – 0.00000001 probability of failure per hour respectively for continuous operation. TUV Rheinland is the international, independent body for certification of safety and quality of products, services and management systems.

The XMC4000 family is based on an ARM Cortex-M4 processor and was designed for the industrial market, with an integrated EtherCAT, for real-time Ethernet communication and an ambient temperature operation of 125°C.

Figure 1: The XMC4800 32-bit microcontroller from Infineon has integrated EtherCAT for real-time communication.

Figure 1: The XMC4800 32-bit microcontroller from Infineon has integrated EtherCAT for real-time communication.

The Safety Package includes XMC4000 microcontroller hardware, documentation and the TUV-certified Fault Robust Software Test Library (fRSTL), jointly developed with YOGITECH, and consultancy and implementation support by embedded engineering tool company, Hitex. Documentation includes a failure mode report, failure mode effects and diagnostic analysis based on liable failure-in-time rates for the microcontrollers and the Safety Application Note to develop SIL2 and SIL3 systems.

The non-TUV-certified library (fRSTL) is available now, and the TUV-certified version will be available, under license from YOGITECH or Hitex, from Q1 2016. The documentation (failure mode report, failure mode effects and diagnostic analysis) documentation will be available in January 2016.

“There have been changes in the safety functionality that customers are embedding in their products,” observes May, requiring changes to the embedded system. “We are seeing a greater demand to add more complex drive safety features, such as SS1 (Safe Stop 1) and SLS (Safely-Limited Speed)—these require safety to be more deeply embedded in the digital system,” he adds.

FPGA Combines With IP

In 2010, Altera was the first FPGA company to deliver a certified toolflow and IP, says May. It has added toolflows such as Safety Design Partitioning and works with partners, such as YOGITECH, the independent IC design services provider. The Nios II embedded processor is now available with the Functional Safety Lockstep. Targeting industrial and automotive applications, the two companies have built the Lockstep solution using Altera FPGAs, SoCs and certified toolflows, with YOGITECH IP. Customers can use Lockstep to implement SIL3 safety designs in Altera FPGAs using fRSmartComp technology for diagnostic coverage, self-checking and safety-related diagnostics of ICs, in compliance with IEC 61508 and ISO 26262.

Figure 2: Altera launched the Nios II Lockstep processor solution with partner, YOGITECH, at this year’s SPS IPC Drives show in Nuremberg, Germany.

Figure 2: Altera launched the Nios II Lockstep processor solution with partner, YOGITECH, at this year’s SPS IPC Drives show in Nuremberg, Germany.

In a safety system, the more complete the tests for system faults, the better. May explains that a measure of this is the diagnostic coverage. When implementing safety on a processor, the processor itself must be tested. This can be done using Software Test Libraries (STLs) to test software functions that run on the processor. “A disadvantage of these STLs,” says May, is that they require significant processor performance (approximately >50%)—leaving less performance for the safety functionality. They are also only able to provide moderate diagnostic coverage (approximately 60% at best). This moderate-low diagnosis coverage limits the system designer when trying to implement the high safety levels that require diagnostics of at least 90%,” he points out. “Using Nios II Lockstep has benefits in that the diagnostic coverage is >99% and it is achieved without impacting the performance of the processor,” he says.

Figure 3: The YOGITECH safety methodology flow.

Figure 3: The YOGITECH safety methodology flow.

Nios II joins the ARM Cortex-R5 processor in the fRSmartComp, YOGITECH’s IP that implements lockstep operations by interfacing a master and slave microprocessor with all the logic and mechanisms required. It embeds the standard cycle-by-cycle comparator of dual-core lock-step architectures. When a discrepancy is detected at one of the interfaces, it detects which of the two cores may have failed. Fail-operation architecture allows the faulty core to be swapped for a good one. A fail-safe architecture has two channels, using one as either a redundancy channel, in case of one failing. Alternatively, it can be designed so that both channels perform the same operation, and in the event of failure, a single channel performs the task.

Tags: ,