Freedom from Interference - How to beat the MPU

Mixed criticality in embedded software development is the concept of allowing software at different levels of criticality to interact and coexist in the same Electronic Control Unit (ECU). Certification of such systems is rather complex, because you have to prove that software elements with a lower safety level cannot interfere with elements with a higher safety level. You have to ensure what ISO 26262 calls ‘Freedom from Interference’. Read how to address this topic.

Freedom from Interference between software elements with incompatible ASILs

Some people like cats. They go to the animal shelter to get themselves one or more pussy cats, which is perfectly fine. Others love birds. They go to the pet shop to buy themselves a Tweety bird, which is nice too. And then there are also people who like both. They've worked themselves in a bit of a pickle by getting both. A cat and a bird in one room require some extra precautions. You don't want the bird to be eaten by the cat. You have to assure "freedom from interference".   

So, perhaps you get yourself a dog to keep an eye on both troublemakers or alternatively just put one of them in a cage.

In "safety language" we would call this problem a form of mixed criticality. Mixed criticality is the concept of allowing software at different levels of criticality to interact and coexist in the same Electronic Control Unit (ECU). Certification of such systems is rather complex, because you have to prove that software elements with a lower safety level cannot interfere with elements with a higher safety level. You have to ensure what ISO 26262 calls ‘Freedom from Interference’. An important aspect to this is to preclude illegal memory access.

A common solution to handle interferences, instead of avoiding them, is to use a hardware Memory Protection Unit (MPU). If the application is partitioned into different Safety integrity levels (SIL), the MPU checks for illegal memory accesses at run-time. If an illegal access occurs, the system can try to restore itself into a safe state.

But that is quite a rigorous solution and not very helpful if your application is already operational in the field. It would be valuable if you knew about such interferences at an earlier stage. But when and how are you supposed to find out?

The TASKING Safety Checker has the ability to verify the integrity of memory accesses between software elements with incompatible ASILs during development. The tool understands the concept of safety levels, even without the need to adapt your source code.

Whoever would've thought that cats and birds can live in perfect harmony without burning the house!

In my next blogs I will tell you more about how this is accomplished.

For more information about the TASKING Safety Checker, see our on-demand Webinar.

 

LOONEY TUNES CHARACTERS, NAMES, AND ALL RELATED INDICIA ARE ™ & © WARNER BROS. ENTERTAINMENT, INC. 2012