Global Sources
EE Times-Asia
Stay in touch with EE Times Asia
EE Times-Asia > EDA/IP

Create safety certified code for industrial systems

Posted: 14 Jul 2015 ?? ?Print Version ?Bookmark and Share

Keywords:industrial automation? real-time operating system? RTOS? IEC 61508? system-on-chip?

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 utilising 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 utilises 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 sub-system 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.

The Trusted Execution Environment approach
For SoCs based on today's most commonly used cores with a type of Trusted Execution Environment (TEE) capability, isolating safety critical tasks from non-safety tasks can be achieved by using the physical hardware separation built into the processor. With TEE, the system resources can be partitioned into two separate domains: one domain designated specifically for non-safety critical applications and the other domain for safety critical applications. A subset of system resources (memory, I/O devices, etc.) is assigned as accessible to the non-safety domain while the safety critical domain has access to all system resources including those accessible to the non-safety domain.

Unless explicitly authorised by the safety critical domain, though, the opposite is not true. The primary purpose of creating a secure safety critical domain is to protect the assets from the non-safety domain through a hardware mechanism that the non-safety domain cannot access or modify.

Multicore SoCs with TEE capability can allocate a processor core to the non-safety domain and another core to the safety critical domain thereby allowing each domain to run continuously. A subset of system resources (memory, I/O devices, etc.) is still assigned as accessible to the non-safety domain while the secure safety critical domain has access to all system resources including those accessible to the non-safety domain. Shared memory can be used for data exchange with an interrupt that is used as an inter-processor signalling between the two domains.

If data needs to be shared from the safety critical domain to the non-safety domain, the safety critical domain can use an inter-processor interrupt to notify the non-safety domain that there is data in shared memory. However, the safety application in the safety critical domain cannot be interrupted by the non-safety domain. Data flowing from the non-safety domain to the secure safety critical domain can be retrieved by a polling mechanism in the safety critical domain using the same shared memory transport.

Working within a power management framework
Just as modern software architectures abstract hardware functions through device drivers, a power management framework provides a structured mechanism for all system devices to be controlled using intuitive application programming interface (API) calls. Any alteration of one device that impacts other devices results in a coordinated transition across all involved sub-systems. The Nucleus power management framework approaches the conservation of power usage from four directions:
1) System states are used to control peripheral power;
2) Dynamic voltage frequency scaling (DVFS) focuses on the entire system;
3) Idle power management prevents expending energy without a ascertainable goal; and
4) Hibernate/Sleep modes allow the system to go off-line during long periods of inactivity.

?First Page?Previous Page 1???2???3?Next Page?Last Page

Article Comments - Create safety certified code for ind...
*? You can enter [0] more charecters.
*Verify code:


Visit Asia Webinars to learn about the latest in technology and get practical design tips.

Back to Top