The right design framework and RTOS can help simplify and cost-reduce creation and certification of safety-critical software.
As industrial automation becomes more widespread, there is an unprecedented need for safety-certified code. To compound the issue, industrial device software complexity is increasing at an alarming rate along with the costs associated with device certification. A real-time operating system (RTOS) with a light-weight process model and power management framework – along with the utilization of a Trusted Execution Environment (an embedded hardware technology) can assist software developers in reducing code complexity and limiting costs when developing industrial embedded systems.
The demand for increasing amounts of software presents significant challenges for software developers as they strive to develop devices that meet the IEC 61508 safety certified standard. The software design selected, which comprises both safety critical and non-safety critical applications, can have a direct impact on the reduction of system complexity and overall certification costs. Knowing which parts of the code are which is an important design consideration.
Obtaining safety integrity level certification for a device requires software documentation and testing for every line of critical code in the system. Because this comes at a significant cost, only the safety-critical code should be certified. Designing the software so the certified applications are separated from the non-critical applications is a necessity to keep software certification costs down.
Certified and Non-certified Code
One option for software developers is to partition certified software from non-certified software. This is done by developing two different hardware subsystems: one subsystem to execute the certified applications, and a second subsystem for non-certified applications. While effective, this approach has several drawbacks including added hardware costs; additional testing; and increased space, weight, heat, and power consumption.
An alternative to the dual subsystem approach is consolidating both the safety critical and non-safety critical applications onto a single system-on-chip (SoC). Clearly, there are advantages to developing a mixed-criticality system on a single module. For such a design, issues to be considered include:
- Partitioning for safety assurance
- Sharing for efficient resource usage
- Certified applications/tasks must be guaranteed system resources
- Non-certified applications/tasks given best possible service
- Assurance that the behavior of non-certified applications will not adversely impact the behavior of certified software
New processors now on the market allow for the consolidation of a rack or multi-CPU system into a single small card. These new processors offer enough power to run both the safety certified and non-safety certified applications. They also offer provisioning for space and resource partitioning and can contain failures in the non-certified application to prevent any impact on a safety critical application.
Mixed Criticality Systems
A software framework designed for “mixed criticality” provides software developers with the option to use a single hardware module to execute both certified and non-certified applications. More sophisticated software frameworks include a certified hypervisor or an ARINC653 certified operating system (OS), of which, both are very good for heterogeneous operating system designs. However, for many devices, these options add unnecessary complexity to the software development and come with a cost of increased testing and documentation.
Depending on the application and system requirements, application partitioning can be accomplished without impacting performance with a light-weight and low overhead RTOS with a process model, or by utilizing a type of Trusted Execution Environment (TEE), a built-in hardware capability available from most major silicon providers.
The Process Model Approach
The employment of an OS that offers a light-weight framework that utilizes the Memory Management Unit (MMU) or Memory Protection Unit (MPU) to create space partitioning, without the overhead of virtualizing the memory, facilitates a cost-effective approach to the design of mixed-criticality systems on a single module. Non-safety applications, such as the user interface (UI) and networking software, run in protected memory regions, which guarantees containment of faults to ensure a non-critical subsystem cannot take down the entire system. Certified applications run in a different memory protected region, at a higher privilege level and at a higher priority to ensure deterministic and guaranteed access to system resources. Mixed-criticality systems reduce overall software design complexity, testing, and cost for regulatory certification.
Figure 1: A process model like that available on Mentor’s Nucleus offers increased device reliability due to faster isolation of software faults and the ability of a deployed system to self-diagnose.
With an operating system such as the Mentor Graphics certified Nucleus real-time operating system (RTOS) with a process model (Figure 1) a system designer can partition the system software into two domains:
1) Foreground: which has the highest priority and can ensure resource allocation for safety critical applications, and
2) Background: which operates with a lower priority to support non-safety critical applications.
For safety applications in the Foreground domain, applications can be statically or dynamically linked and loaded. The statically linked applications run at the same privilege as the root-kernel, while the dynamically loaded modules run at a high priority level in kernel space to guarantee access to system resources.