FROM THEORY TO PRACTICE

Safety Analyses of Software architectures

27. June 2016 | Software & Testing Solutions

The biggest challenge in software safety analysis is the high level of complexity in today’s software architectures.This complexity is due to the presence of various layers as well as the distributed nature of many development efforts where faults and their effects cannot be analyzed by one party alone. As a result, a common understanding of the method to be used and the necessary scope and depth of the analysis is essential. In addition, the interfaces that must be established for the analysis need to be defined. Thanks to experienced interdisciplinary project teams that also work intercontinentally, FEV is able to develop processes that meet all of these criteria. Furthermore, FEV has experience in collecting the corresponding data for any third party components, interfaces, and their specific demands. This knowledge is essential in order to achieve a holistic development and safety analysis.

ISO26262 requires various safety analyses on software architecture, posing a huge challenge to developers. On the one hand, evidence must be provided indicating that all software elements that are required to fulfill the system level safety mechanism are developed in accordance with the assigned ASIL (Automotive Safety Integrity Level) and are effective. The second safety analysis demonstrates the freedom of interference and sufficient independency by analyzing common causes and cascading failures originating in the design of the software architecture.

FEV has developed a practical approach to these analyses. Based on the example of a transmission control software, Bastian Wirges, Functional Safety expert at FEV explains the correlations and dependencies. In the context of this interdisciplinary development task, FEV’s transmission and software experts are working together.

Mr. Wirges, could you explain your approach with the help of a simplified part of the software architecture?

Let’s have a look at an operation where our aim is to determine and actuate the next target gear for a transmission. At the transmission system level, the functional chain must be analyzed using the HAZOP guide words such as: “too high,” “too low,” “too early,” “too late,” “too fast,” “too slow”… A “too low” gear could lead to the wheels locking up, which is a violation of a safety goal on the vehicle level. Therefore, a safety mechanism must be defined to monitor a potential actuation of a “too low” gear.

And then?

For the analyses of the software architecture, the entire architecture has to be analyzed along the control- and dataflow, with a focus on the interaction between different software components and common resources. At this level of analysis, software specific guidewords according to the Software Hazard Analysis and Resolution in Design Method – SHARD – are used.These aspects include guidewords such as “omission,” “commission,” “coarsely incorrect,” “subtly incorrect,” “wrong timing.”

What does this mean for the example of our transmission?

If the information about the lowest allowed gear is received “incorrectly,” the monitor will not be able to work effectively. This is, therefore, a cascaded failure. If the information is “omitted” or contains the “wrong timing,” the monitor will not be able to work at all. Therefore two additional safety mechanisms need to be added to the system: a protection of the information exchanged and a monitor that checks whether the generation and transmission of information is handled properly and in a timely manner.

How do these analysis results impact the whole development process?

In the example, the results ended up in a design decision, namely the implementation of parts of the information protection in one central software component. A fault in this component is, therefore, a common cause failure, which leads to another safety mechanism that monitors the protection handling itself. The analysis stops at this level, as the system has to be capable of handling double faults or latent faults only.

Grafik Safetz-01

Process of Safety Analyses

>>Bastian Wirges, Functional Safety expert at FEV explains the basics of safety analyses of software architectures
FacebookTwitterGoogle+XINGLinkedInWhatsAppBuffer

Leave a Reply

Your email address will not be published. Required fields are marked *