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

Alternatively, the TASKING Safety Checker can be obtained as an optional upgrade for supported TASKING Toolsets (e.g., TASKING 6.0r1 TriCore Toolset). When integrated with a TASKING toolset, the TASKING Safety Checker requires no additional configuration for non-standard C extensions. The description of the memory access rights is given as part of the TASKING linker layout language (lsl script), thus providing a single, integrated definition language to handle all memory and layout related issues.

The integrated version of the tool is the preferred option for customers that are already using TASKING toolsets and are familiar with the TASKING linker layout language. Customers that use TASKING Safety Checker with non-TASKING Toolsets and compilers are bound to the standalone version.

Software integrators

The TASKING Safety Checker can be optionally used to create partial analysis results at the site of software suppliers using a system integrator defined memory access rights configuration. This allows the supplier to verify that his code does not violate the safety constraints given by the system integrator. Furthermore, these partial results can be combined by the system integrator to obtain a full memory access violation result for the entire integrated system. This allows you to easily and quickly pinpoint memory access violations created by combining the different software components from the different suppliers.


We have demonstrated in this overview guide how the application of TASKING Safety Checker by your developers early on during the development of your application code will reduce your MPU related test and bug fixing costs by 69% (sum of all savings in Table 1 up to “Fix Code”). Also, reducing the risk of delivering embarrassing, safety critical errors to your customers by up to 95% (last row in Table 1).

The TASKING Safety Checker is easy to integrate into any existing development environment, and allows your developers to quickly analyze and resolve errors at the time of development. This tool is indispensable for any developer working on code that may trigger an MPU, and it provides an automated and cost-effective solution to identify memory access right violations for a variety of common safety standards including ISO 26262-6 6.4.14, IEC 61508-3 and SIRF 400 Chapter 5.

Get started with the TASKING Safety Checker today by registering for a free evaluation.


[1] Boehm, B. W. Understanding and controlling software costs. Journal of Parametrics 8, 32–68 (1988).


[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).

[5] ISO26262-6 Section 6.4.14,

[6] ISO26262-6 Appendix D,

About the author:

Alexander Herz is head of product development at Tasking.

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.