Functional safety is an important feature in many embedded systems today. Designers need to know the specific safety integrity levels that must be met in various application environments and software development standards and guidelines. The use of an integrated development environment can efficiently bring these various requirements together to maximize the productivity of the development process and the quality of the resulting embedded system software.
Some of the most common functional safety standards include:
- IEC 61508 is the international umbrella standard for functional safety. The standard, and standards derived from it, are used within all kinds of industries with requirements on reliability and safety, for example, process industries, the oil and gas industry, nuclear power plants, machinery, and railway control systems.
- ISO 26262 is used for automotive safety-related systems.
- EN 50128 and EN 50657 are European standards for safety-related software in railway applications. The standards are derived from IEC 61508.
- IEC 62304 is an international standard which specifies life cycle requirements for developing medical software and software within medical devices.
High-integrity functional safety standards frequently require designers to provide extensive justification for selecting a particular development tool unless the tool is already certified. The proof of compliance for the tools increases cost and time of development. Pre-certified tools can provide an answer to this need.
For example, IAR Systems provides certified editions of IAR Embedded Workbench for Arm, for Renesas RX, RL78, and RH850, and for STM8. The tools’ functional safety editions are certified by TÜV SÜD according to the requirements of IEC 61508, ISO 26262 (ISO 26262-6:2018), EN 50128, and EN 50657. For Arm, RX, RL78, and STM8, the certification also covers IEC 62304.
Safety integrity levels
The concepts and requirements for various safety integrity levels (SILs) are not consistent among all functional safety standards. Based on the IEC 61508 standard, four SILs are defined in the functional safety standards, with SIL 4 the most dependable and SIL 1 the least. IEC 61508 defines SIL using requirements grouped into two broad categories: hardware safety integrity and systematic safety integrity. A device or system must meet the requirements for both categories to achieve a given SIL. In addition, there are different SIL requirements for systems that operate continuously compared with systems that are used intermittently. The “probability of dangerous failure on demand” (PDF) and the “risk reduction factor” (RRF) can be 10,000-times more stringent for systems that operate continuously compared with systems that are used intermittently.
For embedded industrial applications, Renesas Electronics recently announced the extension of their RX Functional Safety solution, with the release of its Functional Safety over EtherCAT (FSoE) Application Software Kit, the first software offering that supports functional safety on EtherCAT from a semiconductor manufacturer. Renesas’ RX Functional Safety solution is a solution for industrial automation applications that reduces the complexity of IEC 61508 SIL3 certification.
Renesas’ new FSoE software is based on the FSoE standard published by the EtherCAT Technology Group, the world’s largest industrial Ethernet organization. Developers can obtain an FSoE protocol stack in addition to an RX microcontroller (MCU) with functional safety support and the software – all in a single package, speeding up the development of industrial equipment incorporating FSoE. This allows the quick implementation of communication functions needed to support functional safety, such as essential alarms indicating danger or emergency stop signals using an RX MCU.
Automotive safety integrity levels
While IEC 61508 defines four safety integrity levels from 1 to 4, ISO 26262 defines four automotive safety integrity levels (ASILs) from A to D. ASIL A is the least stringent level of safety reduction, while ASIL D is the most severe. ISO 26262 applies to vehicles with a maximum gross vehicle mass of up to 3,500 kg (about 7,700 pounds).
Car manufacturers and system suppliers have traditionally addressed compliance with these requirements. However, with the increasing complexity of automobiles, all supply chain participants are now called to support and enable functional safety and reliability standards. These metrics are becoming an integral part of the semiconductor design flow.
According to ISO 26262:1-2011, a safety mechanism is a technical solution implemented by electrical or electronic functions or elements, or by other technologies, to detect faults or control failures to achieve or maintain a safe state. Examples of safety mechanisms include:
- Error correction code (ECC)
- Cyclic redundancy check (CRC)
- Hardware redundancy
- Built-in-self-test (BIST)
The effectiveness of the solution to detect these random failures is measured by three metrics to detect fault and failure in time (FIT), as well as the overall likelihood of risk:
- Single-point fault metric (SPFM)
- Latent fault metric (LFM)
- Probabilistic metrics for hardware failures (PMHF)
MISRA C
MISRA C is a set of software development guidelines for the C programming language developed by MISRA (Motor Industry Software Reliability Association). It aims to facilitate code safety, security, portability, and reliability in the context of embedded systems, specifically those systems programmed in ISO C / C90 / C99. There is also a set of guidelines for MISRA C++. Although originally specifically targeted at the automotive industry, MISRA C has evolved as a widely accepted model for best practices by leading developers in sectors including automotive, aerospace, telecom, medical devices, defense, railway, and others.
MISRA is a collaboration between manufacturers, component suppliers, and engineering consultancies, which seeks to promote best practice in developing safety- and security-related electronic systems and other software-intensive applications. For a claim of MISRA compliance to have meaning, it is necessary to establish:
- Use of a disciplined software development process;
- Exactly which guidelines are being applied;
- The effectiveness of the enforcement methods;
- The extent of any deviations from the guidelines;
- The status of any software components developed outside of the project.
Integrated development environment
Regardless of the programming language, standards, or applications environment, embedded software designers need an integrated development environment (IDE). IDEs are designed to maximize programmer productivity by providing a set of development tools with similar user interfaces. IDEs present a single program in which all development is done. This program typically provides many features for authoring, modifying, compiling, deploying, and debugging software.
Examples of the tools included in IDEs are debuggers and emulators. The debugger goes through the code and eliminates bugs and errors, notifying the programmer where they occur. Debuggers pinpoint the lines where issues are found so that programmers can address them quickly.
An emulator is a hardware or software replication of the target system with identical functionality and components. Emulators are used to simulate software performance and see how the code will work in a real-time environment. With an emulator, programmers can change values to reach optimal performance of the code.
This was the final article in a three-part FAQ series on various aspects of embedded system design. The first article looked at managing power consumption and dissipation in embedded systems for a greener world. The second article considered securing embedded systems in a hostile world.
References
Functional Safety Methodologies for Automotive Applications, Cadence
Functional Safety Solution for Industrial Automation, Renesas Electronics
MISRA Compliance:2020, MISRA
Integrated code analysis in functional safety tools, IAR Systems
Safety integrity level, Wikipedia
What is ASIL?, Synopsys
Leave a Reply