EN 
DE Ensuring Freedom from Interference in Automotive Applications
Authors: Ulrich Kloidt, Altium Europe GmbH, Rudolf Grave, Elektrobit (EB)
Contribution – Embedded Software Engineering Congress 2017
Integrating safety-relevant applications into AUTOSAR environments presents a challenge, as it almost always requires integrating software with differing safety objectives, combined with the requirement of non-reciprocal impact. To support integrators, this article presents an automated verification process that significantly simplifies software development in safety environments. This approach leads to better utilization of hardware resources, reduced development time, and consequently, lower costs.
introduction
To increase the safety of electronic systems through standardization, various standards have been developed. In the automotive sector, for example, ISO 26262 is used. This standard ensures the functional safety of a system with electrical/electronic components. Safety standards for other areas are defined in standards such as IEC 61508, ISO 25119, or EN 50128..
Traditionally, safety-critical software functions are processed by a separate single-processor control unit (ECU). This practice ensures a separation of functions with different safety integrity levels (SILs), as physical separation prevents mutual interference.
Currently, several of these single-processor control units are being replaced by a few multi-core control units. Advantages of this solution include reduced wiring complexity and power consumption. However, this measure means that functions with differing safety requirements exist in parallel within a single ECU.
According to ISO 26262, this is only permissible if freedom from interference is guaranteed between software components that have different safety integrity levels or different safety requirements. For example, a function with ASIL A requirements would be separated from an ASIL C function, as would two ASIL D functions with differing safety requirements.
Furthermore, a safety-relevant function must not be affected by the base software. One way to achieve this is through software partitioning, which is implemented using a Memory Protection Unit (MPU). This approach is complex and requires existing hardware on which the application can be tested. It is more efficient to intervene earlier in the development process and verify compliance with the memory partitioning using software.
Freedom from Interference
In ISO 26262, Part 1, Definition 1.49, the absence of feedback is described as "the absence of cascading failures between two or more elements that could lead to a violation of a safety requirement." For example, element 1 and element 2 are free of feedback if no failure of element 2 can trigger a failure in element 1.
There are three types of interference:
Execution time
It must be ensured that a safety-relevant function is not interrupted by another function, as such an interruption could prevent the safety-relevant function from being executed within the specified timeframe or interval. This is typically achieved using hardware and software watchdogs that support control flow monitoring and deadline monitoring. These are usually components of a real-time operating system.
memory
Memory interference occurs when program code or program data of a safety-relevant function is modified by other functions or external errors. Memory access violations can be detected by a memory protection unit (MPU).
Information exchange
Disruptions in information exchange occur when messages are repeated, lost, or their content is corrupted.
The Safety Checker software presented here helps to detect memory interference. This reduces both the development effort and the need for a memory protection unit at low safety levels.
- MPUs are complex to configure. After activation, errors frequently occur, often due to careless mistakes during coding or configuration. Since each individual error must be analyzed, this is a time-consuming task.
- It is very costly to achieve complete code coverage in order to detect all possible memory access violations [3].
- Errors made during the configuration of the MPU may only become apparent in the field, i.e., after delivery of the software [1,2].
- The late use of an MPU and the costly MPU testing delays fault detection and increases development costs [1,4].
Static analysis of the source code as an alternative to the MPU (Medical-Psychological Assessment).
To detect memory interference, a static analysis of the source code can be performed using software. The code is not executed on target hardware. This allows for rapid interference testing after source code changes. The analysis includes checking all possible program flows, thus ensuring high code coverage. Dedicated test cases are therefore not required. C++ code and (inline) assembly code are not checked.
A disadvantage of this approach is that the source code of all files must be available to perform the analysis. This is not a viable way to protect intellectual property. One solution to this problem is to store the analysis data of each file in an encrypted format. This data is then used during software integration.
Differentiation within a security integrity level
The hardware approach via the MPU does not allow for differentiation within a SIL level. The software approach offers this possibility. Any number of levels can be defined, including multiple levels for a single SIL level.
__SAFETY_CLASS_ATTRIBUTES__
{
/* Class name */
{ 0, „QM“ },
{ 1, „ASIL A“ },
{ 2, „ASIL B_1“ },
{ 3, „ASIL B_2“ },
{ 4, „ASIL C“ }
{ 5, „ASIL D“ }
{ 6, „COM_Buf_B1toA“}
};
Application example: MCAL drivers. These are permitted to access configuration data for both reading and writing. Other ASIL B functions, however, are only permitted to read this configuration data.
__SAFETY_CLASS_ACCESS_RIGHTS__
{
/* Source Destination Access rights */
{ ASIL_B_1, COM_Buf_B1toA, W },/* ASIL B_1 function may write to the communication buffer for the ASIL A partition */
{ ASIL_B_1, ASIL_A, R }, /* ASIL B_1 function may have ASIL A data
read */
{ ASIL_A, ASIL_B_2, X }, /* ASIL A function may be ASIL B_2
Call function */
{ ASIL_B_1, ASIL_B_2, R }, /* ASIL B_1 function may be ASIL B_2
Read data */
{ ASIL_B_2, ASIL_B_1, R|W|X }/* ASIL B_2 function may call ASIL B_1 functions and has full access to ASIL B_1 data */
};
MCAL functions and configuration data are assigned to class ASIL_B_2, the remaining ASIL_B functions and data to class ASIL_B_1.
The assignment of functions and variables to the previously defined security integrity levels is done using a table:
__SAFETY_CLASS_SELECTIONS__
{
/* Filename Name SIL */
/* All functions and variables from file 'file_1.c' beginning with 'f' are assigned ASIL_B_1 */
{ „file_1.c“, „f*“, ASIL_B_1 },
/* The variable named 'x' is assigned ASIL_B_2 */
{ „file_1.c“, „x“, ASIL_B_2 },
/* All functions and variables from file 'file_2.c' are assigned ASIL_A, 'file_2.c' contains function 'test' */
{ „file_2.c“, „*“, ASIL_A }
};
If an address range is to be assigned to a SIL level instead of a variable or function, a starting address, size and the desired safety level of the range are specified.
After the static analysis is complete, violations of the specified access rules are displayed in a diagnostic file:
csaf E497: [„file_1.c“ 12] safety violation writing „x“ (ASIL B_2) from „f2“ (ASIL B_1)
csaf E499: [„file_2.c“ 13] safety violation calling „f1“ (ASIL B_1) from „test“ (ASIL A)
A report is available for documentation purposes, the level of detail of which can be scaled. This report consists of
- a table that lists the assignment of functions and variables to the SIL classes,
- a SIL class access matrix that shows the interaction possibilities of individual SIL levels,
- a call diagram that shows all interactions of the functions and the checks performed by the software, as well as
- an access table that shows what type of access is made to each individual function and variable.
Practical application
Two application scenarios will be presented in the following section:
- Non-reactive protection without hardware-supported memory protection for low security levels
- Efficient integration support for control units with memory protection
A typical scenario is integrating software elements with low safety requirements together with QM software, for example, to avoid performance losses during partition changes (e.g., by switching or reprogramming the MPU), to reuse legacy code, or to eliminate the need for a memory protection unit on the processor. As mentioned in the introduction, an argument for the lack of impact on the system must now be provided. This can be achieved through "virtual" partitioning in the Safety Checker by creating different partitions in the configuration for the software elements to be integrated. In this case, the Safety Checker receives a high Tool Confidence Level (TCL) because it is used directly for the safety argument.
Another use case is found in systems with memory protection. In the early project phases, memory protection is often disabled because working functions need to be demonstrated quickly, and there is no immediate danger to life or limb on the board. During this phase, the developer usually doesn't pay attention to proper partitioning, as it isn't being checked. If memory protection needs to be enabled later in the project, this can add up to four weeks to development time, as every incorrect memory protection access results in an exception that then has to be individually analyzed and corrected. Using the Safety Checker, especially in early project phases, can drastically reduce development time and prepare the application for the use of memory protection. Since the safety argument in this scenario relies on the available memory protection, the TCL is usually set to Level 1 and therefore requires no further action.
Integration of the safety checker
Integrating the Safety Checker into a Make environment is relatively simple and can be prepared by the AUTOSAR supplier. The Safety Checker is called in the same way as a compiler.
Creating the configuration file is similarly complex to creating a linker script; however, using a system description, such as the one provided by AUTOSAR, allows for the generation of large portions. For example, the partitions (OS Application) and the SW-C/Basic Software Mapping defined in the system model can be used in the AUTOSAR RTE to generate the SAFETY_CLASS_ATTRIBUTES and SAFETY_CLASS_SELECTIONS.
conclusion
Using static analysis software to locate memory interference reduces the development and hardware testing effort of an MPU, as many access violations can be detected and resolved early in the development phase. A high degree of integration with operating systems like AUTOSAR and their associated tooling significantly reduces the additional effort required by the safety checker, since the necessary information is already stored. An integrator's ideal scenario is a single button or make-target command: "make safetycheck".
Bibliography
[1] Boehm, BW Understanding and controlling software costs. Journal of Parametrics 8, 32–68 (1988).
[2] https://www.popsci.com/software-rising-cause-car-recalls
[3] Software debugging, testing and verification by Hailpern and Santhanam, 2002 (https://www.cs.uleth.ca/~benkoczi/3720/pres/debug-test-verify_hailpern02.pdf)
[4] Tassey, G. The economic impacts of inadequate infrastructure for software testing. National Institute of Standards and Technology, RTI Project 7007, (2002).
Automotive – 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 automotive/embedded and real-time software development.
Training & coaching on the other topics in our portfolio can be found here. here.
Automotive – Expertise
Valuable expertise in automotive/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.
