Corruption of Memory Content
This blog is about “ASIL Aware Static Analysis of Memory Interferences”, a novel technique to detect and repair memory interferences which has been implemented in the TASKING Safety Checker tool.
My previous blog about “Weaknesses in defenses against memory interference” explained the state of the art to ensure freedom from memory interference and showed that the prevailing solutions have limitations such as:
Interferences between software components of the same ASIL remain undetected;
Inter-task interferences and interferences between trusted OS components remain undetected;
Error detection and error recovery occurs at run-time, possibly after a product has been shipped;
Error recovery is coarse-grained, a failure caused by a single software component affects all other correctly working software components located in the same partition as well.
This lead to the conclusion that there is a clear need for analysis tools that reveal memory interferences at software construction time, that solve the limitations of existing approaches, and are capable to analyze interferences between all software components that are located on a (multi-core) electronic control unit (ECU). TASKING Safety Checker is such tool.
Today most safety managers advise to focus on architecture and design aspects to ensure freedom from interference and avoid inspection of the source code. This advice is based on the argument that it is virtually impossible to detect all potential interferences in a large code base since there is no appropriate tool support available. This argument becomes invalid now that the TASKING Safety Checker tool has been publicly released.
The development of this tool was initiated on request of an automotive tier one supplier which experienced severe performance problems during software integration. Overall system performance was much lower as expected which was caused by an surprisingly high error recovery workload originating from interrupts issued by the memory protection unit (MPU) which resulted from memory interferences. So in this case, the root cause appeared to be in the software implementation and tool support was necessary to find and fix the interferences.
The TASKING Safety Checker tool is an addition to, not a replacement of, your toolbox to ensure freedom from memory interference. The main strengths of the solution is that it closes the gaps left by other approaches. Although the development was driven by requirements of the automotive industry, the results can also be used in other domains where safety related embedded software is developed in accordance to standards such as IEC 61508, ISO 25119, EN 50128 or DO-178.
You can download the free whitepaper “Freedom From Memory Interference - An ASIL Aware Static Analysis and Associated Tools” to obtain an in-depth understanding about the strengths and limitations of the analysis technique as it is implemented in the tool. This allows you to make your own assessment about how the tool affects the time-to-market, the verification costs, and the quality that determine the profitability of your products.
About the Author
Gerard Vink accompanied the evolution of TASKING from almost the very beginning of the company’s journey. Being the Head of R&D he is responsible for compiler and debugger technology. Before joining TASKING in 1988 he worked on MCAD and computer animation software. During his more than 25 years at TASKING he witnessed microcontrollers evolve from simple 8-bit cores into complex heterogeneous multicore systems, where the complexity of compiler and debugger technology advanced accordingly. Gerard studied mechanical engineering and computer science.More Content by Gerard Vink