For those of us in the automotive segment of embedded software, the success – or failure – of our companies depends heavily on meeting safety requirements. If we do not develop code using proven development methods to insure safety, at best we will go out of business; at worst, we could cause destruction of property, injury, or even death. As automobiles evolve toward autonomously driven vehicles, functional safety of hardware and software is the paramount concern of software developers, engineers, managers, and executives. Without uncompromised safety, there will be no autonomous vehicles.

Functional safety is the correct operation of a system or equipment in response to its inputs. When functional safety has been met, that system has eliminated all unacceptable risks and poses no threat of injury to occupants. Unfortunately, because embedded software is generally extremely complex, it is difficult to mitigate all risks.

The safety standard for the automotive industry, ISO 26262, defines the way to develop software to mitigate risks and produce safer software. Functional safety, as defined in ISO 26262, is a method of setting safety goals for each electrical or electronic system in the vehicle. Those goals are classified by severity using automotive safety integrity level (ASIL) classification. These levels are established by the risk level with ASIL A being the lowest severity and ASIL D being the greatest. For example, an ASIL A risk might be the DVD player fails (no chance for injury) while an unintentional airbag deployment is an ASIL D risk. Imagine deployment happening at 55 mph on the highway: serious injury and uncontrollability are very likely.

The ASIL is determined at the beginning of the development process. ASILs are used to define the safety goals to which the system must meet. Each ASIL is determined by examining the possible severity of an accident, the amount of exposure time, and the controllability of the vehicle in that situation. ASIL forces designers to ask the question, “If a functional failure emerges, what will happen to the operator, associated road users, and the surrounding environment?”

The standard defines methods to develop software so that it meets functional safety requirements. These requirements include management of the software development process, traceability, risk management, and quality assurance. Companies are required to implement stringent process control.

So, how can a product be developed with these stringent requirements?

Tools to ensure functional safety

Most software errors and problems result from inadequate requirements and a process that isn’t well managed. Poor requirements lead to incorrect or unreliable implementation of functions, and that leads to failed functional safety. When a function is incorrectly implemented, it may cause interference with other software functions, violating the “prime directive” of ISO 26262, which is freedom from interference.

Static analysis can be used to find errors when the software is causing interference. One of the main advantages of using static analysis is that you can begin analysis as soon as completed modules are ready. The analysis can continue until the entire product code set is complete.

It is possible to perform static analysis on either source code or object code. Analyzing the binary file has some advantages. For example, it doesn’t depend on the compiler or assembler used. It can also reveal errors that were introduced by the compiler or assembler without having the source code.

However, lacking information about the compiler and how it may have optimized the code makes some analyses impossible. Further, you can’t trace faults back to the offending point in the source code, making it of little use to correcting the error.

So, analysis quality improves drastically when the source code is used. With source code, you can indeed trace a fault right back to the point it occurred. Of course, you must have the source code available to run the static analysis.

Static analysis reveals interference from illegal attempts to access protected memory by ASIL functions without permission to do so. You can imagine the consequences of corrupting protected memory in an autonomously driven vehicle – or even in your current vehicle. Bad things could result if you hit the DVD Play button instead changing the cruise control setting!

Static analysis ensures freedom from interference

Static analysis does not replace hardware and software verification, but is very valuable for preventing interferences in applications. It can find errors in your source code which violate ISO 26262 requirements. By finding problems as the code is being developed, verification can generally proceed much more quickly. Static analysis with SIL awareness covers the full code base. You can start analysis as soon as the first software elements have been written then continue until all software has been integrated in the system.

Franz Maidl currently serves as the Director of Global TASKING Business at Altium. He studied Technical Physics at Munich University of Applied Sciences, and brings over twenty years of technical knowledge and business experience in the EDA and embedded computing industries to the team. He has a passion for the development of embedded tools for the automotive, industrial and aerospace industries, and is excited about TASKING’s role in moving these industries forward to a smarter, more connected world.