Reducing the complexity of managing safety critical code.
Electronic systems are becoming more complex across multiple markets including automotive, industrial control and healthcare. Vehicles are beginning to drive themselves, industrial robots are becoming increasingly collaborative, and medical systems are automated to assist with surgery or deliver medication. This trend is not a new phenomenon. What was a high-end capability in the last generation frequently becomes standard in future generations, while new previously unanticipated capabilities are added and systems expand. This growth and increase in complexity is of course enabled by both the capabilities of the hardware and the software. This rising complexity introduces added challenges in the management of the software within the system.
ARM’s new Cortex-R52 adds support which enables better control of software within a single processor providing isolation of code and enabling virtualization, but without impacting the deterministic execution important for many real-time applications.
The software controlling early embedded systems could be implemented with a simple single super-loop to manage the complete application. As systems grew in complexity it was increasingly difficult to add or modify the code, with a small change in one section having a knock on impact in another. In a real-time system this is particularly unwanted, resulting in significant resources being required to make relatively simple changes. Most systems now use an operating system which much more readily enables the integration of new features, functionality and enhancements.
Within a single system, there can be multiple suppliers of the software. In the past this could be limited to just a handful of players for a single system, but as complexity rises and the need to standardize builds, so do the benefits of using multiple sources of software to improve reuse and leverage specialist expertise. Together this increased complexity has added to the challenge of integrating software within a single processor.
In systems where functional safety is required, any unexpected interaction with code of different criticality could have unforeseen but dramatic effects on the system’s operation. To counter this risk, the complete software stack would typically be validated and certified. This also can be a complex and costly step and the challenge is only increasing as the software grows in size. One approach to reduce this effort in multiprocessor systems is to split software tasks between processors. Tasks related to the systems safety can be deployed on separate processors with dedicated hardware resources allocated to each. This approach may be helpful in some cases, but does not offer a complete solution, with limited flexibility and a reliance on a full knowledge if the interactions between the tasks. In some systems’ legacy software, the split between safety critical and non-safety critical code may not be well defined, or be very difficult to separate, making this approach infeasible.
A better solution would be to guarantee the independence of safety critical or sensitive code by simplifying the development of functional safety software with clear separation between different levels of software criticality. This independence would mean changes or enhancements may not require wholesale re-certification while software for critical tasks could exist on the same processor as non-critical software, easing both the implementation and flexibility of the solution.
As part of the ARMv8-R architecture, Cortex-R52 allows hardware to monitor software or a hypervisor to provide separation of the software. This simplifies how software interacts together and accesses shared resources. This can be used to maintain separation between tasks on a single processor running on the same operating system, or across multiple operating systems, enabling freedom from interference. Some elements of this code may not have any requirements to explicitly support critical functionality. This could be combined into a processor where safety checking functions such as the execution of software self-test routines and the initiation logic BIST checks are performed, or alternatively it could be used to initiate a safety action or to manage security events.
Access to shared resources between tasks can be managed with a monitor or hypervisor running at a new, higher exception level. Tasks request access to shared required resources through the hypervisor where a separate Memory Protection Unit (MPU) is used to provide hardware protection against unintended accesses. This approach is not limited to two different criticality levels, but can support a mix of many different criticalities together on a single processor and ensures that the critical software will operate as expected. Sandboxes can be created where the code can exist in a protected environment against other tasks unexpectedly taking control or accessing resources which it uses. This enables critical tasks such as those for functional safety to have precedence over other tasks and be able to run without interference from other software in the system.
By providing clear hardware supported isolation between tasks, the effort to validate and certify software can be reduced by limiting this activity to the areas of software with greatest sensitivity, or those which have changed.
To help reduce cost and simplify the overall system there is a trend to integrate functions together.
This integration can take a significant amount of effort when functions are combined into a single device or processor. This integration requires evaluation of all interactions between the systems to insure correct operation.
One approach to simplifying this integration is to virtualize the function and integrate it along with its operating system using a hypervisor to manage the separation. The operating systems do not need to have any awareness of the each other simplifying their incorporation. This can be enabled through the Cortex-R52’s processors hardware. This can be used to help systems which have been developed specifically to be implemented together, as in the case of application consolidation, or when incrementally adding new functionality into an existing system.
In the real-time systems where Cortex-R52 is anticipated to be deployed, the tasks to be performed are known at build time and there is not a need to support the creation of additional virtual machines at run-time. The memory system is therefore composed with a fixed address map and, unlike a fully virtualized system using Memory Management Units (MMU), the memory map is not virtualized. To learn more about virtualization on Cortex-R processors, there is a free webinar on November 9th.
With many virtualization approaches, deterministic execution can be impacted through the use of an MMU. While a page table hit incurs no penalty, a miss in the page table could result in a long page table walk, fetching from slow backing memory with a significant delay on a context change or an exception. This difference, or indeterminism, can be a problem for real-time systems. Cortex-R52 enables virtualization without impacting deterministic execution. The protection is enforced by the two-level MPU which always performs a check of permissions in a single cycle. Compared to previous Cortex-R processors, a new programming model in Cortex-R52 means region sizes are more flexible and faster to program even when implementing a hypervisor.
In many embedded applications the interrupt loading can be significant. Without efficient interrupt handling and deterministic response times, these frequent interrupts can be problematic for real-time systems and could potentially cause a significant performance penalty. The Cortex-R52 has an interrupt controller integrated within the processor cluster helping with low latency interrupt entry and efficient virtual interrupt management. Together with the rapid context switch support for virtualized tasks, the processor provides a fast responding and bounded reaction to the multitude of operations these embedded systems control.
Cortex-R52 context switching example
The Cortex-R52’s ability to support virtualization of tasks on a single processor can help with reduction of effort when integrating tasks together. This is particularly important when combining functional safety tasks of mixed criticality. It reduces effort and increases confidence in the freedom from interference for critical software such as those for functional safety tasks. It also offers a simplified route to combining functions and applications together to assist in application consolidation. The virtualization support through a software hypervisor can often mean the introduction of lower levels of determination. In the case of Cortex-R52, determinism is maintained, making it ideally suited for many real-time applications. To learn more about the Cortex-R52, check out this blog on the ARM Connected Community.
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
Leave a Reply