Advancing automotive application development: Page 5 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.

3. Mapping Functions, Variables and Addresses into Safety Classes

Variables and functions that are either global or static can be mapped to different safety classes using an array of structs, where each entry has the format {“filename.c”, “Regular Expression to match functions or global variables”, Safety Class}, as shown in the example below.

Please note:

Local variables inherit the safety class of the function they are declared in. Furthermore, note that all variables and functions that are not explicitly mapped into a safety class are automatically mapped into safety class (0U) which corresponds to QM in our example.



/* FileMask, NameMask, SafetyClass */

{ “file1.c”, “*”, ASIL_A }, //”*” is a regular expression

{ “file2.c”, “*”, ASIL_B }, //everything in “file2.c” is assigned to safety class ASIL_B

{ “file3.c”, “f3”, ASIL_C }, //”f3” in file3.c is assigned to safety class ASIL_C

{ “file3.c”, “y”, ASIL_C } //global variable “y” in module “file3.c” is assigned to safety class ASIL_C


//safety areas allow to assign memory areas to safety class, e.g. to protect SFRs from unintended access



// StartAddress, Size, Class

{ 0x8004000, 0x200, ASIL_D }, //some SFRs

{ 0x8008000, 0x100, ASIL_D }


This step concludes the configuration of the TASKING Safety Checker. We can now move onto applying safety checker analysis on our sources.

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.