ISO 26262 - Best ideas come in the Shower

September 7, 2016 Harrold Spier

TASKING wants employees to be creative, you get your best ideas when you’re under the shower, so build a couple of showers at the TASKING office. This wonderful idea arose under the shower, so I quickly wiped myself dry and went to the office to tell my boss about it. Unfortunately he was not excited at all. Read how this relates to my experience when developing our Safety Checker, initially targeted for ISO 26262 related applications.

Still TASKING refuses to build showers in the office

iso-26262-best-ideas

How simple can it be? TASKING® wants employees to be creative, you get your best ideas when you’re under the shower, so build a couple of showers at the TASKING office.

This wonderful idea arose under the shower, so I quickly wiped myself dry and went to the office to tell my boss about it. Unfortunately he was not excited at all. He told me the plan is ridiculous, which at the same time proves that also very worse ideas arise under the shower. In his opinion.

So that’s funny. By saying the idea is bad makes the idea bad by itself. This sounds exactly like an Epimenides paradox, which is a problem with self-reference in logic. It is typically a situation computers have difficulty with and it reminded me of a situation I once encountered during the development of the Safety Checker.

Safety Checker by TAKING is a tool to verify the software partitioning design against its implementation and can be used to help proving freedom from interference in the memory space domain and the special function register domain as described in the ISO 26262 functional safety standard.

To be able to do a good static analysis, Safety Checker starts with constructing a full call tree. A well-known trap for creating the call tree is, of course, the recursive loop. Basically, a function is calling itself or a function calls one of its parent functions.

void foo(void)
{
       foo();
}

So, checking for recursive calls is rather obvious and therefore was implemented and thoroughly tested. Nevertheless, there proved to be another, more obscure, form of recursion.

int my_global;
int * foo(int *p)
{
       return p;
}
void bar(void)
{
       *foo(foo(&my_global)) = 1;
}

This is definitely not a recursive call. Function foo() is simply called twice. The first time foo() is called with the address of my_global as argument. The second time foo() is called with the return value of the previous call. This is where it went wrong. Safety Checker tried to find out what the set of arguments is for which the function foo() is called. But to find out, it needs all possible return values of function foo() which cannot be determined if you don’t know the set of possible arguments. The result was a never-ending loop.

Luckily human beings are still required to help computers if they are stuck again in self-referenced misery.

For more information about the Safety Checker by TASKING, Refer to the ASIL CODE INTEGRITY CHECK TOOL.

Product

Previous Article
Who is calling whom?
Who is calling whom?

Critical to static analysis is whether a tool is capable of build...

Next Article
Freedom from Interference - How to beat the MPU
Freedom from Interference - How to beat the MPU

Mixed criticality in embedded software development is the concept...