Follow the Data

September 23, 2016 Harrold Spier

To achieve freedom from interference as defined by ISO 26262 would be rather simple if all C modules were completely self-contained, i.e. only calling functions and referring variables within in the same module. But reality is different. Addresses of objects, passed as parameters, flow through the whole application. How to keep track of access violation in such a labyrinth of code?

In order to assure freedom from interference

The functional safety standard for road vehicles, ISO 26262, does not prohibit software with different Safety Integration Level (SIL) to interact and coexist in the same Electronic Control Unit (ECU), for as long as software elements of a lower safety level cannot interfere with elements at a higher safety level. This can be accomplished using software partitioning. The software is split up into parts of different Safety Integration Levels. Next you need to ensure freedom from interference as defined by ISO 26262.

follow-the-data.jpg

This would be rather simple if all C modules are completely self-contained, i.e. only calling functions and referring variables within in the same module. Unfortunately, life isn’t that easy. C modules will call external functions and will access data declared in other modules. C is about pointers; pointers to data and even pointers to functions. Addresses of objects, passed as parameters, flow through the whole application. How does one keep track of access violations in a labyrinth of code?

The TASKING Safety Checker is a Safety Integration Level (SIL) aware static analyzer which has the ability to verify those accesses. But how? Let’s take a look at the following example:

follow-snippet-1.png

We can see that the address of the global variable my_global is passed as parameter from function main() via function foo() to function bar() where it is accessed. Let’s assume the two objects in the left column have ASIL-A, the object in the second column have ASIL-B and the object in the right column has ASIL-C. Given this scenario, is it allowed for function foo() to access variable my_global directly?

How is this checked by the Safety Checker? First it determines all relevant actions per function:

follow-snippet-2.png

With this information, it is possible to construct the call graph, fill in the function arguments and add the required checks:

follow-snippet-4.png

For this example, creating the call graph it is rather simple. But constructing this can become really complicated when also function pointers are passed as parameters. See the blog “Who is calling whom?’ for more information.

So we end with three checks:

follow-snippet-5.png

Whether each access is allowed depends on the configuration of the Safety Class Access Rights Table. For each SIL-combination, this table specifies which type of access (read, write, call) is allowed.

If an ASIL-C object is not allowed to write to an ASIL-A object, the Safety Checker will emit the following messages:

follow-snippet-6.png

The message reports the access violation, but it also tells you how the address of my_global is passed from main() via function foo() to function bar().

Note that even though the address of my_global is also passed by function foo(), it doesn't count as a violation. The only thing that counts is the actual write access in function bar(). This behaviour is identical to an MPU.
For more background on TASKING Safety Checker, refer to the white paper Freedom From Memory Interference - How Safe and Secure Are Current Defences?’ or Freedom From Memory Interference - An ASIL Aware Static Analysis and Associated Tools’.

Product

Previous Article
Announcing TASKING VX-toolset for TriCore™ release v6.1r1
Announcing TASKING VX-toolset for TriCore™ release v6.1r1

The new TASKING TriCore™ VX-toolset is built specifically to help...

Next Article
Call Graph Created by Safety Checker
Call Graph Created by Safety Checker