Advancing automotive application development: Page 6 of 8

February 08, 2017 //By Alexander Herz, Tasking
Advancing automotive application development
Safety-critical software functions required in a car are traditionally placed in separate, single-core Electronic Control Unit (ECU). With this practice, it’s easy to ensure that different functions with potentially different functional safety requirements and Automotive Safety Integrity Level (ASIL) are physically insulated and protected against interference from each other.

4. Applying Safety Checker Analysis on Sources

After specifying our memory access rights, the sources files can then be analyzed for MPU access right violations. As an example, we examine the source files in the figure below:


Figure 1 - Examining Source Files for MPU Access Violations

Within these sources, the address of variable my_global is passed to function f2(). Within function f2(), the address of my_global is stored in p and passed to function f3(). Within function f3() the address of my_global is stored in q and dereferenced followed by a read action.

According to __SAFETY_CLASS_SELECTIONS__ (from 3.), f3() is in ASIL_C and my_global is in ASIL-A. __SAFETY_CLASS_ACCESS_RIGHTS__ does not allow access from ASIL_C to ASIL-A, so the read from my_global via q in f3() is illegal and would trigger an MPU trap, given a correctly configured MPU.

Instead of specifying a test case and tracing the MPU traps generated by the test through several potentially large and complex source files, the TASKING Safety Checker outputs a root cause analysis for each identified memory access violation, as shown in the next section.

5. Fixing MPU Memory Access Violations

Running the TASKING Safety Checker on the input data from the previous sections produces the results shown below. The source of each safety violation can be easily identified using the root cause analysis output from the tool.

$ csaf file1.c file2.c file3.c partitioning.saf

csaf E498: [“file3.c” 5] safety violation reading “my_global” (class ASIL_A)

from “f3” (class 3)

csaf I899: [“file1.c” 6] the address of “my_global” is passed from

function “f1” as parameter #1 to function “f2”

csaf I898: [“file2.c” 5] parameter #1 containing the address of “my_global”

is passed from function “f2” as parameter #1 to function “f3”

csaf E499: [“file2.c” 5] safety violation calling “f3” (class ASIL_C)

from “f2” (class 2)

csaf E499: [“file1.c” 6] safety violation calling “f2” (class ASIL_B)

from “f1” (class 1)

3 errors, 0 warnings

With the access violation descriptions provided by the TASKING Safety Checker, the problems can be understood quickly and a fix can be planned and implemented within minutes. Once fixed, a quick, second run of the tool can be used to verify the solution. When running the TASKING Safety Checker from within the IDE, the developer can simply click on each output message to directly jump to the offending source location.

Design category: 

Vous êtes certain ?

Si vous désactivez les cookies, vous ne pouvez plus naviguer sur le site.

Vous allez être rediriger vers Google.