This graphic shows a safety architecture with two ASIL partitions and one QM partition. Within the partitions, a more detailed architecture is indicated, but this is not relevant in the context of the analysis for Freedom from Interference. Here we are concerned with the interfaces between partitions of different criticality. These interfaces can be modelled in many ways. However, the execution of low-criticality code in the context of a higher-criticality partition presumably constitutes a violation of the safety case. Such dependencies violating the safety architecture are marked in the picture.
Without a check for compliance with the safety architecture such violations can only be detected late in the process with hardware and configured MPU/MMU. With the architecture analysis, these violations are immediately found as architecture violations. In contrast to dynamic testing on hardware, this check can also be integrated directly into the CI/DevOps pipeline.
Simplified Integration of a Safety System
If the software elements are additionally checked for compliance with a suitable coding guideline (e.g. AUTOSAR C++ 14 or MISRA) using static semantic analysis, programming errors that lead to undefined behaviour can also be largely excluded. This combination thus provides a strong argument for Freedom from Interference in Mixed ASIL systems.
These checks can be used early in the development process, during coding. In a partitioned system with memory protection, significantly fewer problems are thus to be expected in the late integration phases (e.g. MMU/MPU exceptions).
