Advancing automotive application development

February 08, 2017 // By Alexander Herz, Tasking
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.

Today, it is common to combine many of these single core ECUs into a few multi-core ECUs to save costs on wiring and energy consumption. With this new process, functions with different safety requirements and ASIL levels must coexist on the same ECU where no physical insulation is provided. ISO 26262 [5] requires that all software components be developed to the highest ASIL level unless they are partitioned and freedom from interference between the software partitions is established [6].

To avoid the high costs of moving all software components to the highest ASIL level, many software suppliers have started to use software partitioning and Memory Protection Units (MPUs). The MPU is one of the methods supported by the ISO 26262 [6] to establish freedom from interference for memory access and is the most commonly used method today. However, incorrect usage of the MPU can lead to massive financial and legal risks due to critical safety failures in the field. Specifically, the following pitfalls are usually encountered when using the MPU:

•MPUs are notoriously hard to configure correctly. Turning on the MPU often triggers lots of unacceptable MPU access violations (traps) due to small coding and configuration mistakes.

•Debugging and correcting MPU configuration and coding mistakes “trap-by-trap” is time-consuming and costly.

•Achieving high/full test coverage, especially for exceptional corner cases, is prohibitively expensive [3].

•Incorrect MPU configurations and coding mistakes triggering MPU traps are hard to eliminate completely by testing and often create substantial costs when not detected until after delivery of your software “in the field” [1,2].

•Late consideration of MPUs and time-intensive MPU testing delay the discovery of bugs, thus driving the increase in development costs [1,4].

In the remainder of this overview guide, we will discuss the TASKING Safety Checker tool which was developed specifically to mitigate the risks and problems outlined above.

Design category: