Fulfilling Requirements for Advanced Automotive 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.

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, which presents a whole new set of challenges.

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]. Unfortunately, these ASIL requirements can be costly. So what can you do to escape these high costs and challenges while still developing high-quality products that meet today’s requirements?

Implementing Software Partitioning and MPUs

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 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. Here are some of the most common pitfalls encountered when using the MPU:

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

• 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].

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

In order to ensure you don’t further complicate development with more issues, it’s important to understand how to effectively diminish the risks described above. But how can you do that?

Mitigating the Risks Associated with MPU Usage

The TASKING Safety Checker tool was developed specifically to mitigate the risks and problems associated with improper MPU usage. It was designed to help reduce the risk of releasing code which triggers MPU traps by up to 95% while also saving 69% of your MPU related testing and bug fixing costs.

Interested in learning more about how the TASKING Safety Checker will help you avoid the commonly encountered risks associated with MPU usage? Download our TASKING Safety Checker Overview Guide today for a step-by-step walkthrough of the tool and a general overview of its key features.