IEC 61508, ISO26262, DO 178C, ISO 25119: Have you ever encountered these abbreviations in your professional life? If so, there is a high probability that you are already implementing functional safety projects in your company or that you are entering the market in the near future. Perhaps you have already made the experience, or at least, heard of the fact that especially software projects in the field of functional safety can only be carried out with very high documentation / test effort. The safety development process requires this effort. In addition, such projects are very rigid, inefficient, and inflexible. Is such an argument or experience known to you?
Especially for you, but also for all others, I would like to point out in this blog that this is not so. I would like to encourage you to remove meaningless things from your development process and to choose a coherent approach based on engineering principles.

Typical initial situation:

With two project situations are faced very often: In the first, a company has long been working in functional safety projects. However, the software development process in particular is considered to be very inefficient and overloaded. Almost no employees are interested in working on a new safety project. If at all then a developer “only” wants to create the code, the rest should be taken care by the safety manager. Safety development does not at all attract the employees within the company.
The second situation is that a company is new to the topic of functional safety and a software process that meets the relevant standard (depending on the industry, IEC 61508, ISO26262, etc.). Typically, all “requirements” of the standard are often copied to Excel tables, and then it is the goal to fulfill each line of the table. Plans and specifications are then prepared for this. The result is a complex software development process that can not be implemented in practice.
Both scenarios have in common that hardly anyone wants to carry out safety projects.

Solution – The efficient Safety development process:

The solution is the KISS principle: Keep it simple and stupid! This principle helps greatly in the definition of a lean, efficient software development process fulfilling all requirements of the standard. Here are some examples in which places this can be applied wonderfully:

• Requirements: Describe only technical or functional requirements in databases. Strategic, political, and deadline requirements are part of strategy papers and planning documents.
• Architecture and design: Create a software architecture or the software model in graphical form in a suitable tool. Do not describe the architecture in epic texts in requirements databases.
• Coding Guidelines: Consider how your development strategy for the code is, and then determine the coding rules to be followed. As a rule, it makes no sense to try to comply with the complete MISRA standard.
• Test: Do not create isolated unit tests whose exclusive goal is to achieve the structural source code coverage. Much better is a test strategy integrated across all levels. In many cases, a GAP testing strategy will be the means of choice.

If you implement these examples, the motivation of your employees will increase significantly, to carry out safety projects. At the same time, you will pass the functional safety audits.

Are you ready for a functional safety workshop, to analyse improvement potentials in your development process, then send a mail to: info[at]heicon-ulm.de or call +49 (0) 7353 981 781.