Many people associate with the implementation of functional safety, a lot of formalism, and unnecessarily extensive documentation and many processes with a high proportion of theoretical framework. And yes, such projects are existing very often and in every industry. My experience shows that such projects are not very powerful when measured by the real implementation of effective safety measures. The following blog article examines the question why this is so? In addition, the contribution is a plea for a pragmatic software development process, especially in functional safety projects.

Where does formalism come from?

First of all, there are the functional standards such as ISO26262, IEC61508, DO178, EN50128 that tempt us to proceed quite formally. And behind these standards, at least in Germany, is the Product Liability Act. This means that in the event of damage, it is very likely that you as the manufacturer have to prove that you have done everything possible to avoid mistakes during product development and production. In such a situation, verbal agreements are of little help in proving evidence. It become obvious, that only documented, correct information is really helpful here. This point is to be taken very seriously and cannot be eliminated by the best pragmatic approach. A certain formalism and accompanying documentation is inherent in the nature of the matter and cannot be avoided. From this it can be deduced that a project of functional safety is basically more expensive (approximate value: 2-3 times more expensive) than a project in which the topic does not play a role.

Do we therefore have to accept formalism and surrender to it?

Plea for a pragmatic software development process!

Before answering this question, I want to loo at the concept of pragmatism. What does pragmatism mean and what are the prerequisites for its application?

A pragmatic approach in software development means that one always weighs individual aspects against each other and finds a compromise. However, an essential prerequisite for such a procedure is that you have experience in the topic. This is the only way to make responsible compromises in terms of safety in a weighing process.

As an example, I would like to use the planning documentation in a functional safety project. If I design these documents extensively, I can define the procedure with a high level of detail very precisely. This promotes the uniqueness of the procedure.

On the other hand, the projects show again and again that too many details in planning documents are counterproductive, as the overview is lost. The central message that should be given by such a project through the planning documents is lost. In sum, this is considerably more harmful than the missing details. With this experience, planning documents are created which describe the essential procedure in the project in a compact form. Additionally, the change effort for such documents is also significantly lower.

Similar effects can also be observed in the technical content of the Safety Project. More than 2 levels of requirements are needed in almost no project (exception: aerospace). Similarly, projects that do unit tests without formally documentation generally achieve more in the sense of safety than projects that make a great effort here.

These examples already answer the question of whether you have to accept formalism in functional safety projects: NO. Instead of extensive formalism, much more effort should be invested in a balanced strategy for the implementation of such projects. In terms of safety, this achieves much more!

Conclusion

In summary, it can be stated that a certain formalism is necessary in functional safety projects, since it is the only way to protect oneself in the sense of the product liability law, so that one can prove in case of damage that he has done everything to minimize the number of errors.

On the other hand, formalism must not become an objective for itself in the project. Much more in the sense of safety is achieved by developing optimally coordinated strategies for your project. The best way to achieve this is to have the necessary experience.

As a great side effect, the costs for safety projects can then be reasonably limited. An optimal cost/benefit ratio is achieved..

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.