IEC 61508: Development and deployment of industrial systems with safety certification codes

Written by Andrew Patterson, Mentor Graphics

As industrial automation becomes more widespread, the demand for safety certification code is also increasing at an unprecedented rate, and for this reason, the complexity of industrial device software is also increasing at an astonishing rate, along with the costs associated with device certification.

The increasing amount of software is a major challenge for software developers struggling to develop devices that meet the IEC 61508 safety certification standard. The software design chosen consists of safety-critical and non-safety-critical applications, which can directly affect the system complexity and overall certification cost.

In this article, we explore how a secure execution environment (TEE) leveraging ARM TrustZone, an embedded hardware technology, along with a real-time operating system (RTOS) with a lightweight processor model and power management framework, can help software developers reduce code complexity and limit costs when developing industrial embedded systems.

Authentication and Non-Authentication Codes

Obtaining a safety integrity level certification for a device requires software documentation and testing of every line of critical code within the system. This is expensive, so only safety-critical code should be certified, and to keep software certification costs low, software should be designed so that certified applications are separated from non-critical applications.

One option for software developers is to separate certified software from noncertified software. This is done by developing two separate hardware subsystems, one for running certified applications and the second for noncertified applications. While this approach is effective, it has several drawbacks: increased hardware cost, additional testing requirements, and increased space, weight, heat, and power consumption.

An alternative to the dual subsystem approach is to integrate safety-critical and non-safety-critical applications into a single system-on-chip (SoC). There are clear advantages to developing a mixed-criticality system on a single module. The issues to consider in such a design are:

• Split for safety assurance
• Sharing for efficient resource use
• Guarantee system resources to authorized applications/tasks
• Provide the best possible service to non-authenticated applications/tasks
• Prevents unauthorized applications from adversely affecting the operation of the authentication software.

The introduction of new processors allows for the consolidation of racks or multi-CPU systems into a single small card. These new processors provide enough power to run both safety-certified and non-safety-certified applications. They also provide provisioning for space and resource partitioning, and can contain failures of non-certified applications to prevent them from affecting safety-critical applications.

Mixed criticality system

Software frameworks developed for “mixed criticality” provide software developers with the option to run both certified and non-certified applications using a single hardware module. More sophisticated software frameworks include certified hypervisors or ARINC653 certified operating systems (OSs), both of which are well suited to heterogeneous OS designs. However, for many devices, these options not only add unnecessary complexity to software development, but also increase testing and documentation costs.

Depending on the application and system requirements, application partitioning can be achieved without compromising performance by leveraging a lightweight, low-overhead RTOS with a process model, or by leveraging some form of secure execution environment (TEE), a built-in hardware feature offered by most major silicon vendors.

Process Model Approach

Adopting an OS that provides a lightweight framework for performing spatial partitioning without the burden of memory virtualization using a memory management unit (MMU) or memory protection unit (MPU) facilitates a cost-effective approach to designing mixed-criticality systems on a single module. Non-safe applications, such as user interface (UI) and networking software, run in protected memory areas that contain faults to ensure that nonessential subsystems cannot bring down the entire system.

Certified applications run in different memory protection domains with higher privilege levels and priorities, ensuring deterministic and reliable access to system resources. Mixed criticality systems reduce the overall complexity of software design, testing, and regulatory certification costs.


Figure 1: Process models provided by Mentor’s Nucleus provide improved device reliability due to the ability to isolate software faults more quickly and enable self-diagnosis of deployed systems.


Using the Mentor Graphics® certified Nucleus® real-time operating system with process model (Figure 1), system designers can partition system software into two domains:

1) Foreground: Has the highest priority and can guarantee resource allocation to safety-critical applications.
2) Background: It operates at a lower priority and supports non-safety critical applications. Safety applications in the foreground domain can be linked and loaded statically or dynamically. Statically linked applications run at the same privilege level as the root kernel, while dynamically loaded modules run at a higher priority level in kernel space, ensuring access to system resources.

Secure Execution Environment (TEE) Approach

In SoCs based on cores with some form of Secure Execution Environment (TEE) capability, which is most commonly used today, separating safety-critical tasks from non-safety-critical tasks can be achieved by using physical hardware separation built into the processor. The TEE capability allows the system resources to be partitioned into two separate domains.

One domain is specifically designated for non-safety-critical applications, and another domain is designated for safety-critical applications. The non-safety domain is assigned access to a subset of system resources (memory, I/O devices, etc.), while the safety-critical domain has access to all system resources, including those accessible to non-safety domains. The reverse is not true unless explicitly authorized by the safety-critical domain. The primary goal of creating a safety-critical domain that is guaranteed to be safe is to protect assets from non-safety domains through hardware mechanisms that cannot be accessed or modified by non-safety domains.

Multicore SoCs with TEE functionality can allow each domain to run continuously by assigning one processor core to the non-safety domain and another core to the safety-critical domain. While non-safe domains are still assigned access to some of the system's resources (memory, I/O devices, etc.), safety-critical domains, which are guaranteed to be safe, have access to all system resources, including those accessible to non-safe domains.

Shared memory can be used to exchange data, and interrupts are used as inter-processor signaling between the two domains. When a safety-critical domain needs to share data with a non-safe domain, it can use inter-processor interrupts to notify the non-safe domain that there is data in the shared memory. However, a safety application in a safety-critical domain cannot be interrupted by a non-safe domain. Data flowing from a non-safe domain to a safety-critical domain can be retrieved using the same shared memory transfer function as the polling mechanism in the safety-critical domain.

Working within the power management framework

Just as modern software architectures abstract hardware functionality through device drivers, the power management framework provides a structured mechanism for all system devices to be controlled by using intuitive application programming interface (API) calls. A change in one device that affects other devices causes a coordinated change across all relevant subsystems. The Nucleus power management framework's power-saving approach is driven by four directions:

1) Control the power of surrounding autonomous regions using the system status.
2) Dynamic voltage frequency scaling (DVFS) techniques are concentrated throughout the system.
3) Idle power management prevents energy consumption without a verifiable goal.
4) Hibernate/Sleep mode allows the system to go offline when it has been inactive for a long time.

Embedded software developers can use the power management framework to effectively write code that meets power requirements without bloating code or increasing footprint. For both safety-critical and non-safety applications, the power management framework enables embedded software developers to consider power specifications early in the software design cycle. Code can be written to minimize both footprint and power consumption, and tested throughout the development process to ensure that power requirements are met.

Process model functionality, power management framework, and TEE support are just some of the important features provided by a fully featured, certified Nucleus RTOS. Although this paper focuses on the IEC 61508 standard, the new Mentor Graphics Nucleus® SafetyCert™ commercial solution (Figure 2) supports a variety of industry standards.


Figure 2: Mentor’s Nucleus SafetyCert solution and partner ecosystem support a range of industry standards.


The Importance of a Certified OS

Safety-critical software is typically written on the basis of a certified real-time operating system (RTOS). The RTOS runs in the safety-critical domain and is responsible for managing system resources according to specific rules. It is essential that the RTOS effectively manages and shares resources so as not to delay or affect certified applications. In short, a safety-certified RTOS must not interfere with certified applications. The RTOS must comply with the following:

• Ensure data is corrected
• Implement expected results on time
• Ensures that user code executes as expected
• Handle fault conditions correctly

conclusion

The choice of a certified operating system with a lightweight process model and power management framework is the basis for cost-effective implementation of mixed criticality in industrial equipment. The introduction of a powerful SoC allows software developers to integrate safety-critical and non-safety-critical applications on a single SoC using a TEE. These TEEs are also critical to keeping system complexity and authentication costs to a minimum.


###Author Bio:
Andrew Caples is a Product Marketing Manager for Mentor Graphics Embedded Systems Division (ESD). He has over 20 years of experience working for startups and Fortune 500 companies in a variety of positions from technical marketing to sales management. He holds a Bachelor of Science degree in Electrical and Computer Engineering from California Polytechnic University. He currently holds a Product Management position for the Nucleus Real-Time Operating System.