Introduction to Functional Safety for Self Driving Cars
Introduction to concepts like ISO 26262, Safety, Functional Safety, Evaluating Risks, Identify Hazards and Reducing Risk with System Engineering
Welcome to functional safety. In this medium article, we’ll learn how to analyze and design automotive systems to reduce risk. Functional safety is an important part of designing autonomous vehicles and it’s often a difficult skill set to acquire because it is so specific to the automotive industry.
Introduction
So what exactly is functional safety? Any product will have certain requirements or functions describing what the product is supposed to do. Our job as safety managers and engineers is to make sure that these functions do not lead to injury or harm. In the automotive industry, functional safety specifically refers to reducing risk in electronic systems. Automotive functional safety was developed out of the increasing use of complex hardware and software systems in passenger vehicles. In this medium article, I’ll introduce you to the main functional safety standards for the automotive industry, ISO 26262, the standard used in systems engineering to methodically reduce risk in passenger vehicle’s E/E-Systems. Because functional safety is just one part of the overall automotive safety, we will start off with a general introduction to automotive safety. We’ll also present the basic building blocks for carrying out a functional safety analysis according to the ISO standard.
What is Safety?
Let’s look at the morning commute of a person and discuss some hazards he might encounter along his way. He might slam his fingers when he shut the car door. When he turns on the engine, the battery could blow up leaving me burned. He leaves the driveway in reverse and it might hit a trash can or worse, run into a pedestrian. On the highway, his car might even flip over in a fiery accident and he breaks all his bones. His commute seems pretty scary.
Yet despite all of these dangers, he still get in his car and drive to work every weekday. But why? The benefits of getting to work in his car outweigh the potential costs. In other words, the risk seems reasonable to him and driving to work, in his opinion, is a safe activity. Maybe another person sees his morning commute as too risky and takes the train to work instead. Or another person will only drive on city streets at low speed reducing the chance of a high speed accident. To other people, his morning commute seems like an unreasonable risk and therefore unsafe. We all have different risk tolerances and we do these informal risk analysis all of the time in our everyday lives. We feel safe and we participate in activities that have reasonable risks.
What is Functional Safety?
Now we’ll start to think like a functional safety engineer and consider how we can be more methodical about our analysis. In functional safety, our goal is to identify high-risk situations that could cause harm and then we find ways to lower the risk to reasonable, acceptable levels. Safety then is the absence of unreasonable risks. Functional safety at its most basic level involves three main things.
Number one, identifying potential problems that could injure people or damage people’s health. We will call these potential problems hazards. Number two, evaluating the risks of these hazards. Number three, using systems engineering to lower risks to acceptable levels. We ensure that hazards do not lead to accidents. Systems engineering helps us figure out what our vehicle needs to do and what our vehicle design needs to look like in order to remain as safe as reasonably possible. In practice the third part takes the most work and will be the main focus of functional safety. Lowering risks involves designing safe systems, testing our systems and documenting all designs and tests.
Introduction to Identify Hazards
We have now discussed the main goal of functional safety, identifying hazards and lowering risks to acceptable level. So one of the first steps in functional safety analysis is to identify hazards that could cause injury or harm a person’s health. Vehicles have a lot of safety features that we take for granted today. But many safety features such as padded dashboards, headrests, and windshield glass came about because vehicles were actually causing injuries. In functional safety, we want to identify hazards before they ever cause injury. We do not want to wait for an injury to happen and then identify the hazards after. But how do we identify these potential hazards? It takes brainstorming. As a functional safety engineer, we will take a cross-section of personnel from our company to help out with the brainstorming process. We have to imagine a lot of different scenarios and situations that could lead to accidents. To help us identify hazards, we are going to discuss three general causes of accidents: errors caused by humans, errors from technology and errors caused by human technology interaction. This is just an introduction to hazard analysis.
Introduction to Evaluating Risks
Now that we have an idea about how to identify hazards, we need to evaluate the risk associated with each hazard. Evaluating risk will be an important part of our more formal functional safety analysis. Every hazard has a certain risk associated with it. And since we are thinking like functional safety engineers, we are going to define risk numerically.
Risk equals the severity of harm times the probability of occurrence. Severity of harm measures how badly a person could be injured when an accident occurs. Probability of occurrence has a specific definition for passenger car functional safety. It is the frequency with which typical drivers find themselves driving in a certain situation. For example, driving on a city street has a high probability of occurrence because people do it everyday. Driving on a snowy mountain side has a low probability because people hardly find themselves driving in those conditions. Probability of occurrence only takes into account how often we find yourself driving in a certain situation. It does not take into account how likely a malfunction will occur, like the probability of our brakes failing. Failing brakes would lead to high severity but would not affect probability of occurrence.
Let’s go through an example of calculating risk. We’ll say that severity has a scale of one to four, with one representing no injury and four representing fatal injury. Probability of occurrence will also be on a scale from one to four, one being an unlikely scenario like needing a jump start, while four will be a likely scenario like driving on a highway. Here’s our scenario, you’re driving on a snowy mountain side pass and the power steering malfunctions. I would say severity is a four because we could easily lose control of the vehicle, driving off the mountainside and suffer a fatal injury. Probability of occurrence could be a two because you would not find yourself driving on a snowy mountainside very often. Risk then is four times two equals eight. In functional safety analysis, we quantify risk to determine how much we need to lower the risk. Vehicle systems with high risks require more analysis and testing to bring the risk down to acceptable levels.
Reducing Risk with System Engg.
We’ve discussed how to recognize hazards and motor risks. But how exactly do we reduce risk to acceptable levels? Engineers use systems engineering to reduce risk in order to prevent and control accidents. Vehicles are complex. Think about all of the different mechanical elements, electric elements, hydraulic components, hardware components and software components that go into a vehicle. All of these functions have to work together in a variety of driving conditions, like freeway driving, driving in the desert heat and driving below freezing temperatures.
Now, think about the different players involved in designing and producing a vehicle. Product engineers, finance managers, project managers, safety engineers, testing engineers and car body designers. Players will impose different constraints on the design as they figure out what the vehicle needs to do. For example, a product engineer will want the lane keeping system to always be on and available for use. A safety engineer, will find cases where the lane keeping system needs to shut off or be limited. Besides safety and availability constraints, other constraints include costs, productivity, market demands and limits of current technology. This is where systems engineering comes into play.
Systems engineering gives you a methodical framework to figure out what your vehicle needs to do which is also called requirements engineering. Come up with a design that matches your requirements and allocate requirements to different parts of your design. This is called designing a system architecture and allocating requirements to the system. Test and verify your system to make sure that it really does what it is supposed to do. Which we will refer to as testing and verification. And finally, integrate all of the different parts so that everything plays well together. This is known as system integration.
How will we use system engineering? Let’s say a product engineering team is working on the lane departure warning function. The warning function vibrates the steering wheel if the driver crosses the lane by mistake. You, the safety engineer, look all the lane wanting functions design, you quickly realize that if the steering wheel vibrates too hard, the driver could loose control of the vehicle and crash. What are you going to do about it? You will use systems engineering.
First, figure out what the vehicle needs to do. The vehicle needs to limit the maximum vibration of the steering wheel. If the vibration exceeds the maximum, the lane departure warning system should shut off. This is requirements engineering. Now, you adjust the design of the lane departure wanting function so that it includes your new functionality. We call this, allocating requirements to the system architecture. The next step, is to test your design to make sure it works properly. You verify that the system turns off when vibration levels get too intense. This is the testing and verification phase. Finally, you integrate your design into the rest of the vehicle. For instance, you’ll make sure that the lane keeping system plays well with the automatic cruise control system. This is the system’s integration step. Your job as a functional safety engineer, is to insert yourself into the design and testing process as your company develops a vehicle.
Introduction to ISO 26262
We have now learned the basics of functional safety, hazard identification, evaluating risk, and using systems engineering to lower risk. It’s time to introduce the international functional safety standard, ISO 26262. ISO 26262 provides a framework for dealing with electronic system malfunctions in passenger vehicles. In other words, the standard helps us ensure that if our vehicle systems do not behave as intended the vehicle will not cause injury or harm to a person’s health.
ISO 26262 uses the V model to cover the entire vehicle safety lifecycle from planning, designing, testing, production, and post-production. Let’s take a look at the V model.
The left side represents system planning and design. The right side shows system testing and integration. The bottom of the V represents subsystems while the top integrated systems. Note that the V model makes a clear distinction between hardware development and software development. Each one has its own miniature V model within the larger model. Note also that we can connect to the left side of the V and right side of the V with horizontal lines as shown below:
Summary
Safety involves reducing risks to reasonable levels. We achieve safe systems by identifying hazards that could lead to accidents. Then we evaluate the risk of each hazard. Finally, we use systems engineering to lower risks to acceptable levels. Today’s society defines what’s an acceptable risk. Functional safety in the automotive industry specifically refers to reducing risk in electronic systems. ISO 26262 is a guideline for achieving automotive functional safety. It’s a standard philosophy model.
With this, we have come to the end of this article. Thanks for reading this and following along. Hope you loved it! Bundle of thanks for reading it!
My Linkedin :)
