EN 
DE Development of a safety architecture on the AURIX TC27x
Authors: Prof. Dr.-Ing. Peter Fromm, Thomas Barth, Darmstadt University of Applied Sciences, Mario Cupelli, HighTec EDV Systeme GmbH
Contribution – Embedded Software Engineering Congress 2015
Multi-core controllers offer not only performance gains but also the possibility of implementing redundant applications on a single chip. However, since the physical coupling between the individual cores is significantly tighter than in discrete multi-controller solutions, special demands are placed on the software architecture, memory layout, operating system, and driver layer.
This paper outlines the challenges and approach involved in developing a safety architecture for forklift controllers using the Infineon AURIX TC27x multi-core chip and the PxROS operating system from HighTec. Specifically, it describes the development of a safe and extensible base architecture, the design of a multi-core runtime environment, and the application of suitable design patterns for application development.
Motivation for the use of multi-core controllers
Developing multicore applications is anything but trivial. Migrating existing code to a multicore architecture typically requires a complete redesign of the software architecture. True concurrency across the cores can lead to data consistency issues, and resources like memory and peripherals must be shared conflict-free between the individual cores. Software qualification and debugging become significantly more complex compared to single-core applications. So why take the leap to multicore?
A key argument is the performance gain of a multi-core architecture compared to a single-core one. The CPU frequency cannot be increased indefinitely due to the parallel increase in power consumption and electromagnetic interference. Multi-core controllers offer a solution here, allowing the parallel execution of independent program components.
Another interesting use case for multicore architectures is the replacement of redundant multi-controller solutions with a single multicore chip. Such architectures are frequently found in applications with high safety requirements, such as machine controls, engine control units, or aircraft technology, to name just a few. In such architectures, the signal paths are typically implemented using multiple channels to detect potential malfunctions and bring the system to a safe state. A simplified multi-channel architecture with redundant monitoring is shown in Figure 1 (see...). PDFThe input signal is acquired via a dual-channel sensor and fed into a control loop that calculates and generates an output signal, e.g., the desired rotational speed for a machine. Simultaneously, the input signals, the correct calculation of the output signal, and the physical output signal are acquired and verified by two independent monitoring units. For safety reasons, different signal acquisition technologies (e.g., VADC and Sigma-Delta ADC) and different algorithms are often used. As soon as a check fails, the system can be brought to a safe state, e.g., standstill, independently of both channels via a suitable escalation strategy.
To save production costs and increase the system's tamper resistance (elimination of external connections between the controllers), such an architecture should alternatively be implemented with a multicore controller as shown in Figure 2 (see PDF) can be structured using an example sketch.
When designing such a solution, a number of questions arise, which will be discussed below:
- How does a multicore architecture compare to a discrete multi-controller solution from the perspective of the relevant safety standards?
- How can the central requirement of Freedom of Interference be ensured on a multicore controller?
- What does a suitable safety software architecture look like on a multicore controller?
As part of a feasibility study, a prototype control unit for future forklift controls was developed in cooperation with the companies HighTec, Infineon and a well-known machine manufacturer, using the 3-core controller Aurix TC275 from Infineon.
Requirements for security architectures from the world of standards
The development of safety-critical systems is heavily regulated by legal standards. Prominent examples of such standards are ISO 26262 [1] in the automotive industry and ISO 13849 [2] in the mechanical engineering industry, which will be referenced below.
When developing the control system, a development process is recommended according to [3] which includes the following steps:
- Risk analysis and assessment
- Identification of the necessary security functions to reduce risk and determination of the required performance level.
- Definition of the control architecture
- Assessment of the impact of errors and diagnostic options, error prevention
- Implementation of error-preventing measures in the software lifecycle
- Verification and validation of the overall system
Due to the potential hazards to forklift operators, the control system for driving and lifting operations must meet Performance Level d. As shown in Figure 3 below (see PDFIt can be seen that the desired performance level d can be achieved with a category 2 or 3 architecture. However, a category 2 architecture has higher requirements for diagnostic coverage.
Regarding hardware architecture, the standard differentiates into the following categories:
| category | Construction[1] | Description |
|
B / 1 |
|
|
|
2 |
|
|
|
3 / 4 |
|
|
Transfer of architecture categories to a multicore controller
Looking at the different categories in Table 1, the structure of a multicore controller cannot be directly translated into these categories. While a multicore controller has independent processing cores, the memory and peripheral components can be accessed by all cores. Additional technologies such as memory protection units (MPCUs) promise a certain degree of separation when correctly configured, but this is very likely insufficient to meet the standard's requirements regarding measures against common cause errors. In particular, the aspects of signal path separation/isolation, component diversity, and the impact of environmental disturbances appear problematic.
Regardless of this question, which will certainly have to be answered in the future, the software architecture must ensure the highest possible degree of freedom of interference between the individual applications, and in particular between the logic functions and the safety functions, which is justified as follows:
- Qualifying smaller software units with clear interfaces is simpler and more reliable than qualifying large software monoliths. Control engineering applications, in particular, often rely on global variables for data exchange, but their data flow is difficult or even impossible to verify in practice.
- The impact of potential (software) errors is limited locally.
- Safety functions and normal functions must be qualified differently. A clear and secure separation allows the safety functions and the application component to be qualified once according to their respective process requirements. This makes it easier to requalify the application component, especially when changes are made to it.
The Aurix microcontroller supports the "Freedom from Interference" requirement both between software components themselves and between software components and peripheral registers. A distinction is made between the data domain, the time domain, and the resource domain.
The Aurix Memory Protection Unit (MPU) is primarily used to protect the data domain (memory). Additionally, the Bus Memory Protection Unit (BUS-MPU) provides further protection. While the MPU is controlled by the accessing process (e.g., task xyz accesses memory area abc) and can be used more dynamically, the BUS-MPU is configured from the perspective of the accessed resource (e.g., only specific bus participants, such as tasks from a particular core, are allowed to access memory area abc) and implements more static restrictions.
The time domain is primarily achieved through concurrent code execution on individual cores. Once a core is started, it runs independently of the other cores, provided that no spinlocks or other blocking constructs are used. To safeguard runtime behavior, the usual watchdogs for local operations and a safety watchdog for global operations are also available.
Peripheral register protection is handled similarly to memory protection via the Memory Protection Unit (MPU) or Register Access Protection (RAP, functionally comparable to the BUS MPU). Since the MPU is 8-byte aligned, it can only protect complete modules; the granularity is often insufficient for individual pins. RAP always applies to complete peripheral modules and does not allow further subdivision. These limitations must be considered during hardware layout. In addition to Supervisor Mode, two User Modes are available that restrict access to the peripherals.
Basic software / operating system PxROS
After the Aurix boots, all security mechanisms are disabled. This means the application must explicitly restrict access to protect specific resources. Since this configuration should not be handled by the application itself, the PxROS operating system from HighTec was selected. PxROS is a certified multicore operating system that optimally supports the Aurix's hardware features.
- Individual tasks can be dynamically assigned to different cores.
- The task configuration contains all access rights to memory and peripherals, which therefore automatically apply to the application software that is executed in the context of this task.
- Data exchange between tasks occurs via non-blocking events and messages. This happens independently of the core on which the task physically runs. This means that the assignment of tasks to the hardware can be reconfigured without requiring any changes to the application code.
Architectural concept
Figure 4 (see PDFFigure 1 schematically shows the partitioning of the forklift control system. All safety functions and the peripheral drivers required by these functions are executed on Core 0, which is started via hardware reset. Once all safety functions are running, Core 0 starts the controller applications on Core 1 and the comfort functions on Core 2, along with their associated drivers.
The blue boxes each represent an application assigned to a task with defined resources. Communication between tasks typically occurs via operating system services. For a few particularly fast accesses, data exchange can alternatively be implemented via shared memory.
Furthermore, the applications are flashed as independent hex files, so that, for example, a future comfort function can be added without requiring a new qualification of the safety software or the driving/lifting functions.
Multi-core runtime environment
Another requirement was that the application developer should be able to create their code independently of the system's final partitioning. This means an application only needs to know which data it requires and which data it provides. The actual signal flow should be handled by a runtime environment that is centrally configured and qualified.
The AUTOSAR RTE was used as a starting point for the design of the runtime environment, and a custom runtime environment was developed based on it:
- Mapping runnables to tasks and tasks to cores
- Expansion of intelligence services across core boundaries
- Support for different memory areas (read only, read/write, write once, …)
- Direct coupling of the drivers to the signals of the runtime environment
- Scaling of raw data into application data in the signal layer
Figure 5 (see PDF) shows, by way of example, the implementation of a safety function as well as the driving application and a comfort function.
Experiences, conclusion, outlook
The project has demonstrated that multicore architectures offer an attractive solution for security applications. However, developing multicore applications is significantly more complex than developing traditional single-core programs. An operating system that is optimally tailored to the hardware and abstracts it effectively is a crucial prerequisite for project success.
The combination of Infineon Aurix and PxROS HR from HighTec has proven to be a well-matched pair. Based on this, a high-performance multicore runtime environment was developed with manageable effort and is already being used in initial projects.
Nevertheless, developing multicore applications remains a significant challenge, as system complexity quickly becomes very high and errors are difficult to locate. In the case of Aurix, numerous configurations of memory, hardware safety functions, and the operating system must be kept synchronized even after changes. Suitable tools still need to be developed to support this economically and securely.
Another exciting question for the future is the further development of the fail-safe architecture presented here into a fail-operational solution, in which tasks can be transferred from one core to another in case of an error.
List of abbreviations
I: Input – Input unit, e.g., sensor with ADC signal
L: Logic – Data processing unit, e.g., controller
O: Output – output unit, e.g., actuator controlled via PWM
TE: Test unit
Bibliography
| [1] | ISO26262; Functional Safety – Road Vehicles; ISO/FDIS; 2011 |
| [2] | German Institute for Standardization (DIN); DIN EN ISO 13849-1/2; Beuth Verlag; Berlin; 2008 |
| [3] | Barg, Eisenhut-Fuchsberger, Orth, Ost, Springhorn; 10 Steps to Performance Level; Bosch-Rexroth; oA. |
| [4] | Infineon; Aurix Safety Manual AP32224 V1.2; Infineon Munich; 2015 |
Multicore – our training & coaching
Do you want to bring yourself up to date with the latest technology?
Then find out more here MircoConsult offers training courses/seminars/workshops and individual coaching on the topic of multicore/microcontrollers.
Training & coaching on the other topics in our portfolio can be found here. here.
Multicore – Expertise
Valuable expertise in modeling/embedded and real-time software development is available. here Available for you to download free of charge.
You can find expertise on other topics in our portfolio here. here.
