How are Safety Goals Developed for Functional Safety Management?

How are Safety Goals Developed for Functional Safety Management?

Vehicles have transformed our world, but their use carries risk. This risk can extend beyond the vehicle to the surrounding environment. As modern vehicles have become more and more complex, standards have been developed to guide manufacturers towards the creation of functionally safe products and systems.

Functional safety encompasses how we plan for, design, develop and manage the development of safe products, that can also lead to a hazardous condition if they malfunction. But that’s just a general description. The achievement of functional safety requires the application of standards, processes, and other key elements. Safety goals are one such element, a top-level safety requirement that is assigned to a system with the purpose of reducing the risk of one or more hazardous events.

What is a functional safety goal in relationship to functional safety?

Functional safety in general includes not only the development of the product, but also the organization, their process, and their safety culture. Safety goals are foundation elements in the pursuit and achievement of a functionally safe product or system. They are derived from a thorough understanding of all the potential hazards that may factor into the failure of a component or system. These potential hazards include not only those hazards that could affect the persons inside the vehicle, but also persons in the surrounding environment.

As part of the risk classification scheme defined by international standard ISO 26262 “Road vehicles – Functional safety”, each safety goal is assigned an Automotive Safety Integrity Level (ASIL) attribute, as well as all the requirements for returning the vehicle to a safe state. Safety goals, high-level requirements, technical requirements on a product… these are all things that need to be mitigated on a particular system to make sure that faults don't propagate and create a hazardous condition. All of that is included when you see the term “functional safety”, and those considerations factor into the safety goal of a project.

How do you manage safety goal testing and assessment? Who creates the functional safety goals and defines the ASIL levels?

Going through the process for developing a hazard analysis and risk assessment, is team-style committee work. When you are analyzing risk, a lot of subjectivity comes into play. Even if you think about it from the perspective of analyzing the reaction of vehicle drivers, everybody has their own personal biases and opinions.

Each member of the team should be asked the same questions. For example, “If I lose my vehicle powertrain and propulsion, do you think that's critical?” Or, “How critical do you think a loss of propulsion is in relation to ASIL A to D, with ASIL A being the least stringent or the least critical, and ASIL D being the most critical?” Two different people might rate that situation differently. And so, it is the work of the committee to reach a true consensus on what the company needs to do.

These are real issues, and there are real differences in ratings from company to company on different types of faults. It is not a situation where one person has all the answers. Typically, one or two brave souls might create the initial draft, but then it will certainly be reviewed by different experts, different team members, and that's usually who sets the goals in real life. And when experts are brought in, it is vitally important for them to have objectivity; that really plays a critical role in this process.

The management of functional safety is overseen by the safety manager. They coordinate all of these activities and more, making sure that they raise a flag to the right people, when necessary, to make sure that functional safety is not compromised. To learn more about the role of the Safety manager, see our blog: What is Functional Safety Management in Automotive

How do you identify a bad safety goal? How far does the project usually get before it is realized that a safety goal is inadequate?

The functional safety process is a risk-based functional safety concept that is designed to catch issues up front. This follows what is known as the V-Model development lifecycle. The left side of the V is much like a waterfall, and cascades downward from one step to the next. Any decisions made up top, are propagated downward. To catch inadequate safety goals, there are steps set in place to make sure they are caught upfront.

Once a hazard analysis and risk assessment are either drafted or even blessed by a team, no matter what system, they're looking for level independence. Three-level independence means that a complete separate team should be evaluating that same hazard analysis and risk assessment and the safety goals for that product. The separate team needs to be independent, not your immediate peers, and hopefully not from your same team. You need someone completely different to do an evaluation to see if they reach concurrence independently. That is done initially, to try to catch any issues early on.

As the project progresses, towards the end there is a validation phase. During the validation phase, you go back to the beginning and ask yourself, “Okay, now that we have created this design and we possess all this test data, were our original assumptions correct?” For example, when safety goals were developed for a product that could lose propulsion, we assumed that losing propulsion in the parking lot was really of no concern. Therefore, a test would have to be run to verify whether that was indeed the case.

The driver reports that in the parking lot at low speed, he felt comfortable when he lost power, and nothing really happened. He was able to control the vehicle by just applying the brakes. However, do the assumptions around that same fault hold true when it happens at speed on the freeway? Obviously, this would not be tested on an actual public freeway, but rather, on a test track.

Part of the validation phase is asking whether the safety goals that the team initially developed still hold true. Do they still make sense? Can I ensure that they're still adequate? You test a lot of the assumptions that you made early on, to see if they're still holding true. And if they're not adequate, they need to be updated. In essence, that is the purpose of validation. There are a lot of other checks in between as well. But those are the major ones that we try to do up front and towards the end, to see how to catch bad safety goals.

When tests on safety goals are run, do they use teams with drivers that depict a variety of skill levels and age groups, to try to get a broader and more representative spectrum?

The reality is, a lot of testing is qualitative, especially during the development lifecycle. An OEM is not going to utilize unvetted personnel from the general public and say, “Here, go drive this.” But in comparison, how real is a test when you use professional test track drivers? They are specially trained to handle situations like this. Likewise, if you were to use the public for a team, you might tell them, “You are now going to test new vehicles. Some failures may occur that we need to look out for. The objective is to monitor how you react.” The reality is, you have just given them advanced warning on what to expect. They now know that something is coming, and they are actively looking for it. So, that is not a realistic test, either.

There is guidance in ISO 26262 that tries to provide some alignments. Certainly, if there is serious injury or death, it is a highly critical situation. But if it is just bruises and bumps, it is not as serious. If the public were used, it is also questionable how that would be validated. So, there is a lot of subjectivity and unfortunately, a lot of this part of the process is qualitative. You must start somewhere.

How are real-world conditions accounted for in the V-Model systems development diagram?

Real-world weather, geography, and other environmental conditions are accounted for early on. When determining the rating of a safety goal, the ASIL level, there are three main factors that are taken into consideration:

• The different driving environments and operational scenarios
• Probability
• Controllability

Driving environments and scenarios

Am I on a freeway in the mountains, or am I on a parking lot or in my garage? Those are known as Environmental Factors, or the E Factor. It is the probability of exposure to a given environmental condition. What is the probability that I am going to be in this scenario when that component or system fails? For example, what is the probability that I will be in a freeway scenario when I experience a loss of propulsion? How often am I going to be on a mountainous country road? It might be a little less frequent for one person compared to another. But it's not just for that one person, we are testing for the public. They all must be factored in. And so, there is guidance as to these types of operational scenarios and the kind of rating we would see from those scenarios.

Probability

Probability is also one of the factors that is considered in determining the rating; the more probable the scenario, then it should be considered a high probability scenario. Our job is to evaluate faults in those scenarios. Not only the faults, but their impact as well. And by impact, there are other factors taken into consideration.

Let's assume that a particular fault does happen. What is the severity of that fault if it comes to fruition? Let's say that because of this fault, the vehicle gets rear-ended. How bad is it going to be in that scenario? Did the vehicle get rear-ended because it lost propulsion on the freeway? Is the driver going to be bruised, suffer broken bones, or are they going to die? And, at what speed? We analyze these scenarios, and that is when severity gets considered. If an injury happens, how severe is it likely to be to the human beings? Is it likely to be life threatening? And that analysis is not restricted to just the humans inside the vehicle. Are nearby cyclists or pedestrians likely to be hurt?

Controllability

The third factor is controllability. How much is the driver going to be able to compensate for the loss of propulsion? Is it just a matter of them applying the brakes and that's it, they bring the vehicle to a nice, controlled stop? Are they able to just drive onto the shoulder? If propulsion is lost on the freeway, the vehicle still has momentum, so it is unlikely to come to an immediate dead stop. But if the driver turns on the hazard flashers and can drive onto the shoulder, is that the end of the hazard? That's where controllability factors in because we need to assess for those considerations.

And so collectively, those three factors yield a rating. There is a table in the standard that, depending on your three ratings, indicates an ASIL rating for the given safety goal. The safety goals define requirements, and they in turn are the subject of tests. Safety goals are overarching and foundational, all at the same time.

Conclusion

Modern vehicle designs have become highly complex. There is a need to ensure functional safety at every stage of the product’s development and use. Strict adherence to automotive safety standards is paramount, and vetted and well-defined safety goals are key to meeting those standards. Safety goals are high-level, but they touch and shape every aspect of functional safety. Their importance cannot be overstated.