Tag Archive for: ADAS

Functional Safety for Autonomous Driving

This post on functional safety for autonomous driving is Part III in our three-part series with automotive expert Patrick Freytag. If you haven’t already, please go back and read Part I, which talks about how the automotive sector is changing – and Part II, which discusses ways to address functional safety.

Since functional safety has a product lifecycle approach, it has a wide impact on all processes in a company. As a newcomer to functional safety, it’s challenging to focus on the most important aspects, especially for new entrants in the knowledge-intensive automotive sector. Here are best practices based on my observations and experience.

Functional Safety for Autonomous Driving – Best Practices for New Market Entrants 

Executive Management Team: Pay Attention to Functional Safety 

Product safety should be at topic of conversation for the Executive Management Team (EMT) because of the legal responsibilities placed upon the company by deploying a vehicle to customers. The EMT should understand that it needs dedicated resources to achieve product safety. One of the most important tasks of the EMT is to implement a Safety Engineering Management and to assure that roles and responsibilities for quality and safety are defined and communicated in the company. Members of the safety team need a specific skill set, so it is important to invest in functional safety education and qualification. It is important to foster a quality and safety culture in the company. For that reason, quality and safety should be part of goal agreement and performance evaluation. Quality and safety have to be recognized as a core responsibility and a performance indicator for employees.  

Project Management: Plan and Track Functional Safety 

Project management has to incorporate functional safety in the product concept and development plan. The Project Manager (PM) should consider the additional time and cost in the project plan and the project budget. Product development plans must include quality and safety milestones and the related work products. What should be done if the PM doesn’t receive proof that quality and safety milestones are reached at the gate reviews, for example? Well, that’s for sure a red flag. Situations like these may point to deeper rooted issues, and should not be brushed under the rug. The PM should start a GAP analysis and request an action plan. I recommend escalating the issue to the executive team ASAP in case there is missing proof of product safety. It won’t get better without commitment and planned actions, the longer you wait the worse the situation will get. Since safety considerations most typically permeate several layers of system design, it is not an attribute that can be tagged on shortly before the start of production, it has to be implemented from the beginning. 

Development & Functional Safety Team: Implement and Validate Functional Safety 

Industry experience shows that functional safety is not a topic you can assign to one responsible person. For example, a technical safety concept is created by a team of software, hardware, and system-level experts and moderated by a systems architect in collaboration with functional safety engineers. This means that the functional safety manager is a role that is played a few times in a company, while the role of a safety engineer can be assigned to even an entire team. As mentioned, functional safety requires specific domain knowledge and safety engineering expertise. But what can be done if this expertise is missing in-house? My recommendation is to compensate it with external resources as an interim solution. Start functional safety education and qualification as a long-term solution. Safety must be addressed in product development with adequate engineering methods and domain knowledge to define safety requirements. These safety requirements have to be implemented, tracked, managed, verified, and validated to make sure that risk reduction is realized, and the product is safe.  

The Evolution of Functional Safety for Autonomous Driving 

The functional safety focus is on avoiding and mitigating failures in E/E systems. That also works well for Advanced Driver Assistance Systems (ADAS). When a failure is detected, the driver gets alerted, and mitigation measures are performed to reach a safe state. These systems are called fail-safe. Let’s take Adaptive Cruise Control (ACC) as an example. When a failure is detected, a warning will be displayed in the Instrument Cluster. This visual warning is typically combined with an acoustical warning to get the attention of the driver. The ACC function will be switched off, and the driver is in charge to control the vehicle’s speed and keep a safe distance again.  

Additional Safety Considerations for Autonomous Driving 

The ADAS safety mechanism described above will not be sufficient for a fully autonomous vehicle. It’s not possible to switch off the automated driving system because there is no driver in the loop to take over. An Autonomous Vehicle (AV) has to work under all (failure) conditions, it has to be fail-operational. An AV without a driver in the loop also needs situational awareness, understand the surrounding world, decide, and act. This situational awareness is created by data fusion from a variety of complex sensor systems based on lidars, cameras, and radars. The combined data is then interpreted to plan and take action. This interpretation and planning are achieved by complex algorithms, driven by Artificial Intelligence (AI) and Machine Learning (ML).  

Today, many connected and ADAS-equipped cars are already available. Connectivity features and information sharing are increasingly used for updating vehicle features, maintenance-related diagnostics, and traffic services. This development will also increase the attractiveness of an attack on vehicles by hackers with different motivations and it introduces additional risks for vehicle cybersecurity.  

Safety Concerns Due to System Limitations and Misuse 

What happens if an automated driving system has no system failure but doesn’t work as intended? Unsafe behavior could be triggered by limitations in the sensor systems, extreme conditions, or unforeseen situations. In addition, misuse could confuse the AI algorithms and result in unsafe behavior too.  

An example of misuse of an ADAS was showed by Consumer Reports. Consumer Reports reported in April 2021 that it was able to trick a Tesla into driving in autopilot mode with no one at the wheel. Real-life proof followed in May – Police arrested Tesla driver for operating his car from the back seat while traveling on a San Francisco Bay Area freeway. The officer confirmed the sole occupant was in the backseat, so he took action to stop the car and saw the occupant move to the driver’s seat before the car stopped. In response, Tesla activated the cabin camera with a software update to detect and alert driver inattentiveness while autopilot is engaged for Model 3 and Model Y end of May.  

Here a typical example of limitations, an AV is driving and confronted with black ice conditions. While an experienced driver should be able to comprehend the situation and respond properly, an AI-based AV might not. Without sensing the icy road condition, an AV might drive faster than is safe for the condition. 

As a result, there has to be an addition to functional safety considering safety violations that occur in absence of a system failure. 

RELATED: Watch a demonstration of the Jama Connect for Automotive Solution

Safety of Intended Functionality or SOTIF (ISO/PAS 21448) 

The publicly available specification ISO/PAS 21448, titled “Road vehicles — Safety of the intended functionality” was published in 2019. SOTIF is defined in the standard as: “The absence of unreasonable risk due to hazards resulting from functional insufficiencies of the intended functionality or by reasonably foreseeable misuse by persons.” The goal of SOTIF is to avoid situations where vehicles are working as designed, but are failing under real-world scenarios. ISO 21448 provides guidance on the design, verification, and validation measures to achieve the SOTIF. The current version covers Advanced Driver Assistance Systems (SAE J3016 L1 and L2). It can be considered for higher levels of automation; however, additional measures will be necessary. 

 The Standard for the Evaluation of Autonomous Products (ANSI/UL 4600) 

The UL 4600 standard was issued in April 2020 with the scope of the Safety Evaluation of fully Autonomous Driving Systems that operate without human intervention. The goal of UL 4600 is to ensure that a comprehensive safety case is created, including safety goals, argumentation, and evidence. UL 4600 covers the safety principles, risk mitigation, tools, techniques, and life-cycle processes for building and evaluating a safety argument for vehicles that can operate in an autonomous mode without human supervision. Therefore, the ML-based system aspects of the autonomous operation are covered. UL 4600 works well with existing automotive safety standards such as ISO 26262 and ISO/PAS 21448 by building on their strengths while also filling their autonomy-specific gaps.  

Conclusion

The safety challenge for autonomous vehicles can’t be addressed with a single standard as of today. As we move on from existing Advanced Driver Assistance (L1 and L2+) to fully Automated Driving Systems (L5) the standards and methods will evolve too.  

Current state-of-the-art automotive safety is achieved with a combination of different engineering methods and processes: 

Functional Safety (ISO 26262)

Guards the E/E malfunction behavior due to systematic and random hardware failures for vehicles with a human driver present responsible for safe operation

Safety of the Intended Functionality (ISO/PAS 21448) 

Deals with the functional limitation regarding the absence of unreasonable risk due to hazards resulting from functional insufficiency of the intended functionality or reasonably foreseeable misuse by persons. SOTIF covers L1 & L2 ADAS vehicles with a human driver present responsible for safe operation. 

Cybersecurity engineering (ISO/SAE 21434)  

Protects road vehicle systems and components from harmful attacks, unauthorized access, damage, or anything else that could interfere and compromise safety functions 

Evaluation of Autonomous Products (ANSI/UL4600) 

Proofs the safety of fully autonomous road vehicles that can operate without human supervision  

Take Away: The combination of different engineering methods is needed on the way to fully Autonomous Driving  

  • Functional Safety helps you to do things right 
  • Safety of Intended Functionality helps you to do the right things 
  • Cybersecurity helps to protect the safety functions from being compromised 
  • Evaluation of Autonomous Products helps you to provide proof that you did enough safety engineering work to achieve a safe autonomous product

This blog post concludes the 3-blog miniseries on automotive insights and best practices on the way to autonomous driving. Special thanks to Jama Software for the opportunity to share my observations and experience with you. I hope you enjoyed reading my thoughts and got useful insights into the complex and interesting world of automotive safety and autonomous driving.  


functional safetyMy last blog post covered why and how the automotive sector is changing fast over the last few years – you can find that post here. A common expectation is that our future cars will be connected, automated, shared, and electric. In a current Motional Consumer Mobility report, Americans were asked what is their most important consideration to use a self-driving vehicle. Nearly two-thirds of Americans (65 percent) say safety is the most important consideration when deciding to use a self-driving vehicle. So let’s take a closer look at automotive functional safety and how to deliver a safe product. 

Safety Considerations for Product Design 

Modern cars are a complex piece of technology. They are connected, have sophisticated Infotainment Systems (IVI) and Advanced Driver Assistance Systems (ADAS). You will be surprised about the amount of software used in the 30 to 70 electronic control units in a car. There are up to 100 million lines of code deployed in a modern high-end car today. System complexity will increase even more when we move beyond ADAS-supported driving to Automated Driving Systems (ADSs) in the future.

The challenge for the industry is that new potential hazards may arise with the increasing use of electronics and software in cars. Apart from complex technology and consumers’ expectations, we will get regulations covering the safety of future cars. In the U.S., this is the responsibility of the National Highway Traffic Safety Administration (NHTSA).

Defined by the Vehicle Safety Act in 1966, the NHTSA has the sole authority to make final decisions on rules and safety standards for future road vehicles. Once the NHTSA establishes a standard, the Agency is required to ensure that manufacturers comply when producing new vehicles.

In 2016 the NHTSA published “Vision for Safety,” a non-regulatory approach to automated vehicle technology safety. “Entities are encouraged to follow a robust design and validation process based on a systems-engineering approach to design ADSs free of unreasonable safety risks. The overall process should adopt and follow industry standards, such as the functional safety process standard for road vehicles…” 

Which industry standard is the NHTSA referring to? 

The mentioned standard is the ISO 26262 standard. First issued by International Organization for Standardization (ISO) in 2011 and later updated in 2018. The ISO 26262 is titled “Road vehicles – functional safety,” the first comprehensive voluntary industry standard for safety engineering of Electrical and Electronic Systems (E/E) in road vehicles. This standard recognizes that safety is a system attribute and can be addressed using systems engineering methods. ISO 26262 emphasizes the importance of implementing a safety engineering management and fostering a safety culture. 

What is functional safety and how to comply? 

Functional safety is defined as the “absence of unreasonable risk due to hazards caused by malfunctioning behavior of electrical/electronic systems.” The goal of ISO 26262 is to ensure safety from the earliest concept to the point when the vehicle is retired. To ensure vehicle safety, the standard outlines an automotive safety life cycle that describes the entire production life cycle.  

Specific steps are required in each phase of the safety life cycle. One of the most important steps at the beginning of the safety life cycle is the Hazard & Risk Analysis of potential hazards (HARA). The result is an Automotive Safety Integrity Level (ASIL) classification of the hazard and the formulation of an overall safety goal. Safety goals are basically the level of safety required by a system or component to function without posing any threats to the vehicle. 

An ASIL is assigned by evaluating three risk parameters, severity, exposure, and controllability. Severity defines the consequences to the life of people due to the failure that may occur. Exposure is the likelihood of the conditions under which a particular failure would result in a safety hazard. Controllability determines the extent to which the driver will be able to control the vehicle should a safety goal be breached due to the failure or malfunctioning. An ISO 26262 method provides guidance on how to assign the ASIL for a hazard once severity, exposure, and controllability are determined.  

In the next step, a functional safety concept is developed for each safety goal. The functional safety concept defines functional safety requirements within the context of the vehicle architecture, including fault detection and failure mitigation mechanisms, to satisfy the safety goals. Then the technical safety concept is developed to specify the technical safety requirements within the system architecture. The technical safety concept is the basis for deriving the hardware and software safety requirements that are used for developing the product. These safety requirements have to be traced, managed and validated through product development to assure the delivery of a safe product. 

RELATED: Watch a demonstration of the Jama Connect for Automotive Solution

Why is functional safety important? 

Functional Safety describes a risk-based system engineering approach to avoid unreasonable risk. From a business aspect, using ISO 26262 as a guideline helps you to avoid costly product recalls due to safety hazards. Tesla recalled roughly 135,000 Model S and Model X vehicles over Touch-Screen failures in February 2021. The move came after the National Highway Traffic Safety Administration requested a safety recall. NHTSA asked for the recall because the center display in some models can fail when a memory chip runs out of storage capacity, affecting safety functions such as windshield defogging and defrosting controls, exterior turn signal lighting, and rearview backup camera display. 

Following the standard minimizes the risk of harm to people and non-acceptance of your products by the market. In particular, automobile manufacturers have a legal responsibility to design their vehicles to guarantee driver, passenger, and pedestrian safety. As a consequence, automobile manufacturers can be named as defendants in a product liability suit. For example, Toyota Motors agreed to pay $1.2 billion to settle the Justice Department’s criminal investigation into whether the company hid safety defects related to unintended acceleration in 2014. 

Takeaway 

Functional safety is an essential part of product development and needs to be addressed early in the concept phase and considered through the full product life-cycle. ISO 26262 offers an engineering guideline and methods to avoid or at least mitigate systematic failures and random hardware failures of Electrical and Electronic Systems. The derived functional safety requirements have to be implemented at the lowest level up to the system level, both from a hardware and software perspective. This offers the ability to prove that the added E/E-systems are free of unreasonable safety risks. 

The pragmatic engineering approach is to use existing knowledge, or how I call it, to use the industry’s memory. You should look at the ISO 26262 series as the framework, and set of guidelines and methods. ISO 26262 can help you with system engineering methods for a safe product and still give you some flexibility in the development process. This is especially helpful for newcomers to the automotive industry, who may lack specific automotive safety engineering experience. 

Let’s put it that way, using existing engineering methods and knowledge is like standing on the shoulders of a giant – you can see further. This is even more true for automotive product safety because there is no room for trial and error. 

Stay tuned: The next blog post in this series will give real-life advice on how to implement functional safety in your organization and products, and a glance at the evolution of functional safety for autonomous driving.