GLIWA embedded systems :: T1.accessPredictor

T1.accessPredictor makes it possible to detect access violations before the software runs on the target hardware

Upset by MPU exceptions in the field? Tracking them down while the software executes can be very time consuming and costly. T1.accessPredictor allows you to check for any memory access violations before even flashing the software. Think of it as an “off-line MPU”.
binaryOnly

Analyzing the binary rather than the source code has significant advantages.

It is a long way from the source code to the binary and assuming that no additional accesses were injected by the compiler and linker is a critical assumption in a safety-relevant context.
C source analysis also omits any assembler code.
What’s more today’s ECUs incorporate software components from various parties. None of them has a full view on 100% of the sources so a complete analysis is impossible when performing source code analysis.

Using T1.accessPredictor is very simple; there are only a few steps to take

Step 1: Specify the different access classes using the intuitive GUI and define in which way (Read, Write and eXecute) every class may access the other classes. “Execute” refers to code accesses such as function-calls. In the example on the right, four access-classes were defined: ASIL_A, ASIL_D, QM and Flash.

Click on image to enlarge

Step 2: Read in the binary, the ELF file. T1.accessPredictor will disassemble the binary and perform a static analysis based on abstract interpretation. Afterwards T1.accessPredictor presents a “bi-directional” call-tree indicating a) which function calls which other functions and b) by which other functions a function gets called.
Step 3: If necessary, add annotations (manually, generated or measurement-based) to complete the call-tree.
Step 4: Analyze the results! The call-tree indicates access violations with red exclamation marks: for invalid data accesses and for invalid code accesses.

Click on image to enlarge