“This should never have happened! Why the hell didn’t you let me know that you are experiencing problems and that you are not reaching the goals!?“
A red artery pulsates threateningly on the lead developer’s forehead. He looks upon his team’s shell-shocked faces as they avoid his gaze. He just can’t understand it. It’s always the same problem. The development was going so well, everything looked like it was working, even the audits came out well – under the circumstances – and now, at the end of the project, everything seems to be unravelling again. Errors popped up during the implementation phase, the feature could not be maintained and lots of requirements went unfulfilled. Different components bucked under the pressure during tests – they were not prepared for this “special, unpredictable circumstance”. He was upset, mistakes still cropped up by the end of the project even though he’d sent his team to training courses, the same old mistakes that always invoke the same response: “Damnit, we should have thought of that/how could we have missed that? At least it happened now, another expensive recall would have cost him his job. He actually loved his job, he had a good team, but had to deal with development cycles that got ever shorter and the increasing pressure made sustainable development more and more difficult.
Different views and standards
There are many companies that experience comparable situations in terms of their development or in their production. Some development is global and it is done according to different views and standards. Terms like “secure”, “trustworthy” or just “good” could be interpreted differently. Misunderstandings and a sense of resignation could set in. Of course the solution is communication – who would have thought? – but that is just half the story, you also need to be able to talk about the right things in the brief time available. Perhaps one of these moments was the birthplace of functional safety in the projects; the desire to improve processes and make them more secure.
There is a persistent belief in business that though safety is (probably) quite important, it can be pursued halfheartedly. Functional safety on the other hand, if used properly, aims to reduce a lot of pressure and offers many advantages.
What is functional safety and how could it be useful?
If you’ve ever read a norm you’ll know that even app user manuals are easier to read. So let’s take a little look at functional safety. As the name suggests, functional safety ensures that a previously defined safety function is maintained and that a particular secure state can be guaranteed for a system. This is limited however to the electric, electronic and programmable parts of development.
In order to achieve this goal the following approach is taken (this example looks as machine and building construction):
- Analyze possible dangers. What are the possible dangers with particular products? With the help of hazard and operability index these changes can be estimated. These procedures lay the foundation for functional safety and minimize the probability of recalls or legal action due to production delays, or in the worst cases, injuries by customers.
- Defining safety functions. Every exposed danger is assigned a safety function. This describes how the danger can be countered. Depending on the probabilities and extent of damage, every safety function gets a SIL (Safety Integrity Level; 4=highest; 1=lowest). This SIL represents the extent of risk minimization necessary to bring about a safe state and to reduce the remaining risk.
This approach is applicable across industries and identical in each – aside from the wording and specific risk categories. Sounds good, but it also sounds like more work and not very much value for regular developers. Let’s take a look at the practice in lot of companies in order to measure the cost and benefit: often the default internal processes are not capable of doing justice to the ever growing pile of requirements. This leads to errors and bad decisions that give rise to the following process.
A safety concept could lead to the following situation:
The analysis of possible dangers and definitions of safety functions only build the foundation of functional safety. As the image clearly shows, the FuSi makes the development process easier instead of – as is often assumed – harder. The apparent high upfront costs in the beginning of the project lead to reduction in stress in the middle of the project. That helps to eliminate systematic mistakes in the development process. The elementary advantages that make this possible are as follows:
- The management of functional safety (the exact course of action is described in IEC 61508 for example) makes clear recommendations and prescriptions. It gives staff members special roles connected to set tasks. Similarly, there are set prescriptions pertaining to workflows and work structures, which lead to the following advantages:
* Clarity on who will be doing what and when. That reduces the number of misunderstandings about who is actually responsible for particular activities. And there is less friction and frustration among colleagues.
* Because the prescribed process can be seen as complete and comprehensive, there is less fear about forgetting intermediary steps or deficient execution of tasks. The supervisor can receive clear communication about the project’s status and what is coming next.
- Recommendations for defined workflows and processes
Specifications about the kind of development are made in order to achieve particular goals in functional safety. An example of this would the familiar “V model”. This leads to the following advantages:
* So-called systematic errors are minimized through the use of pre-defined intermediary steps and set workflows.
* Internal hierarchical problems are dealt with in the best possible way.
* The quality improves.
The advantages of a safety structure in companies are clear.
Advantages for businesses:
- Minimizing the probability of recalls
- Creating SIL-ready products
- Improved quality
Advantages to staff members:
- Stress reduction through collective prescriptions
- Clear role assignments
- Better task allocation
- Many practical checklists from norms
A lot of processes need to be changed in a company for real change to be possible. That is a good thing, after all, happy staff members and teams have been proven to do better work. Sure, the upfront costs are high – but would it cost much more than recalls, settlement costs, liability disputes and demotivated staff members? I doubt it. The true challenge lies in the implementation and not the acceptance. The change cannot and may not happen immediately or all at once, partly because procedural and structural changes are made by decision-makers and leaders. It can start small by including the V model in your processes, performing a risk analysis or by changing the internal process step by step. Work smarter not harder.
Patrick Richter offers seminars on the “Functional safety of machines – basic seminar for norm-based development and proof of functional safety according to DIN EN ISO 13849” (German only).