There is an ongoing expansion of Advanced Driver Assistance Systems (ADAS) – most every new car has such features these days. Typical offerings include lane-departure and blind-spot warnings, rear cross-traffic detection, and automatic emergency braking.
Automobile manufacturers tout these as safety devices and television advertising is blanketed with heart-warming portrayals of lives saved and injuries avoided because of these little electronic miracles.
But, be warned: As currently designed, many of these devices will not fully meet their expected purpose. Most ADAS systems are convenience features rather than full-fledged safety devices. Unfortunately, the mismatch between public perception and ADAS’ true capabilities can lead to public harm and potential liabilities for manufacturers.
The reason for this shortfall is due in large part to a lack of effective and methodical design that accounts for all the ins and outs of real life. Solutions can be found in requirements-based design and appropriate validation and verification testing. Existing guides and standards provide a path which, if followed, will lead to systems fulfilling safety expectations. With associated tools and procedures, the vision of ADAS safety can be achieved efficiently and economically.
Trouble in the ADAS World
When a driver understands both the capabilities and limitations of ADAS products, those features can contribute to the driver’s safety and satisfaction behind the wheel. Conversely, unaware vehicle operators relying inappropriately on those devices can place themselves and others at risk.
In 2018, the American Automobile Association performed a study to examine users' understanding and opinions regarding these assisting features. The study found that more than three out of four drivers considered ADAS technologies to be useful, and at least seven in ten car owners would want such features in their next vehicle.
However, the study also highlighted a lack of awareness and potentially unsafe behaviors among respondents. This points to an insufficient appreciation that the driver must remain vigilant to operational safety. Regarding some specific features:
Rather than ensuring that these systems work the way consumers expect, the collective reaction from manufacturers to the situation has largely been disclaimers.
Manufacturer Liability
Though the manufacturers are issuing disclaimers stating that the features are merely aids and that the driver must take full responsibility for on-the-road safety, this is generally contrary to the public perception that has been bolstered by advertising.
Even if the driver has read the disclaimers and is being attentive, ADAS, as designed today, sometimes misbehave in ways that can startle the driver and confuse neighboring traffic, potentially leading to collisions. For example:
A roundabout has two lanes. The inside lane has slow-moving traffic while the outside lane is free. A driver enters the free lane and their automated braking system views the car on the inside lane as being in front of the entering car. Depending on the distance between the two vehicles and their relative speed, the ADAS might either issue a collision warning or inappropriately apply the brakes.
When such a situation results in harm or injury, vehicle owners start looking for compensation. In cases of product liability, the legal system is often friendly to the plaintiff’s cause.
The “manufacturer,” which includes all stakeholders upstream of the end user, is liable for the product sold. Though the negligent party with the deepest pockets is typically the primary target in a liability suit, each of the parties can typically be held responsible for the full amount.
When a deep-pockets company could have done more with their product to reduce the risk of harm, public scrutiny tends to drive elevated awards.
The burden of proof is the duty of the manufacturer to prove that they acted with due care in the design and production of the vehicle. This proof comes from well-defined, repeatable processes with complete, comprehensible, consistent, unambiguous documentation. It must be evident that safety was a fundamental principle from beginning to end.
The solution and protections are found in the disciplined application of standards.
The Use of Standards
Standards drive a consistent and methodical approach to the development of vehicle systems. Applied to the entire product lifecycle (including concept development, design, testing, and production), standards help ensure that:
The result is a product conceived and developed with safety in mind, backed by complete, consistent, transparent, and traceable documentation.
LHP recommends the application of three standards which will lead to improved quality, lower risk, decreased costs, product differentiation, and greater brand value. These standards are:
Functional Safety
Functional safety focuses on safety-critical electrical and electronic (E/E) systems with the objective that they either operate and respond to inputs correctly or fail predictably and acceptably.
Standard ISO 26262 (from the International Standards Organization) provides guidelines for evaluating foreseeable malfunctions in both hardware and software and establishing measures to reduce risks to acceptable levels. It addresses random hardware failures and systematic failures that result from human errors during the design process (e.g., bad assumptions, software bugs). Comprehensive documentation is emphasized throughout.
Risk is determined from a combination of severity, exposure, and controllability. As risk increases, more rigor is required at each step of development and production.
Safety of the Intended Functionality
SOTIF (ISO/PAS 21448; under development) is the next step beyond functional safety. While ISO 26262 deals with avoidance or management of system or component malfunctions, SOTIF addresses the risk of unintended behaviors from systems operating “correctly.” Though all components are working as designed, the system might react inappropriately to real-world conditions, such as in the earlier example of the roundabout and the automated braking system incorrectly taking action.
SOTIF examines behaviors that may occur under known or predictable circumstances (including reasonably foreseeable misuse) and in unknown situations. Along the way, SOTIF may uncover additional safety goals that should be looped back into the product via ISO 26262.
Since unintended behaviors might only occur under certain conditions or combinations of conditions, verification and validation testing becomes critical in proving that designs work as specified.
ASPICE
Unlike ISO 26262 and SOTIF, ASPICE is not a safety standard. Instead, it provides a strategy for software development (using a typical V-model for the system development lifecycle) and a process assessment model for measuring the quality of the development.
The level of technology in the automotive industry is rapidly expanding, bringing an explosion in lines of code required to manage the multitude of components within a single vehicle. Where one million lines of code may have sufficed a decade ago, 100 million has become more the norm now. As systems become more complex, the risk of failure due to an undetected system design or software implementation issue increases.
The use of ASPICE brings traceability to the entire software development cycle (a requirement of ISO 26262), including the setting of requirements, code development, and testing.
Design and Testing
To avoid public harm, minimize product liabilities, and meet consumer expectations, ADAS must be founded on requirements-based design and testing – safety goals are set, design follows, and thorough testing confirms the functionality.
Unfortunately, today’s ADAS are being promoted as safety systems, though the associated design and testing often do not begin with safety in mind:
Instead, automakers might consider high-level goals, such as: For a vehicle operating under active adaptive cruise control, the acceptable risk of the vehicle colliding with another vehicle or other object in the road due to a malfunction or unintended system behavior is 1 in 10,000,000.
Possible hazardous events that could lead to this risk are examined for severity, exposure, and controllability and are each assigned an associated safety goal or set of requirements. These are systematically divided and passed down to subsystems and components at a level that design reasonably occurs. The developed system must then be thoroughly tested under a variety of conditions to show that it can meet the defined requirements and, ultimately, the safety goal.
Proper verification and validation of these complex E/E systems can require the testing of thousands of components and conditions. As vehicle development marches toward fully autonomous vehicles, that count will rise from thousands to many millions.
It is impractical to test a massive number of scenarios on open streets or the test track. The logistics, time, and cost become unmanageable. Lab testing is more suited to requirements-based design – more methodical, quicker, and less expensive. Automotive engineers can test both hardware and decision algorithms using hardware-in-the-loop methods to simulate driving scenarios in a controlled environment. Because many different combinations of conditions can be tested quickly, previously unknown ADAS reactions might be discovered.
Information Tools – Integration and Automation
Application of standards like ISO 26262 generates significant amounts of information and data involving tasks like:
|
|
|
|
|
|
It may be possible to use ordinary office products like Microsoft Excel for certain activities, but such tools do not provide the means for hard links and automated numbering schemes. This creates manual work which is prone to error. These simple tools become difficult and labor-intensive in tracing safety requirements, designs, and test results.Various software tools can help organize and store the details.
There are versions of Application Lifecycle Management (ALM) tools that could do most of the job, but none have yet evolved to cover Safety Lifecycle Management based on automotive safety standards. The solution will likely rely on a chain of tools.
Regardless of what toolset is selected, it is highly advised that the tools be integrated to avoid a) copy-and-paste for data flow between individual tools and b) multiple versions of the same information. As the complexity of systems increases, a non-optimized toolchain can paralyze an organization and its development process.
Unlocking Value
Implementing standards, setting up software tools, changing work processes, training staff – none of this comes free of charge, and none will happen overnight, but it is a worthy investment.
First, consider liability issues. Unsafe products lead to legal actions; the consequences can be crippling. In the last 10 to 20 years, awards of billions of dollars have been granted in cases involving Toyota (unintended acceleration) and Takata (failed airbags).
Both Toyota and Takata had flawed design processes. Toyota failed (primarily through insufficient documentation) to prove that safety was intrinsic to design. Compliance with standards such as ISO 26262 and SOTIF, including requirements-based design, proper information management, and adequate testing, is key to avoiding such problems.
Next, information tools, when properly applied, help minimize the likely (and hidden) cost of poor data flow – time lost through miscommunication, confusing records that do not provide clarity and traceability for future development, and products potentially leaving the factory without adequate testing.
In an integrated system with automated data flow, everyone is reading from the same book. The objective is that information – requirements, decisions, protocols, test results – passes automatically to those who need it. This is accomplished through the use of shared databases with no duplicated data, no miscommunication, and everyone notified of changes.
Finally, testing costs can be drastically reduced by using automated test equipment in a lab rather than performing tests with vehicles on a closed track. This is further enhanced if the information tools can be connected to the testing equipment in the lab – a complete data flow from setting safety goals through design to testing, where results can be fed back into the system for a new cycle.
Summary
Though ADAS are advertised as safety devices, they do not always work as drivers believe. When ADAS-related accidents occur, vehicle owners will turn to the courts for compensation from manufacturers who did not do all they could or should have to create safe systems.
Standards exist that can guide automakers and their suppliers toward vehicles and systems that are functionally safe and will perform as expected.
Applying the standards, purchasing tools, training staff, and instituting new procedures all come at a cost. However, there is value found in improved processes, better quality, lower testing costs, and avoidance of liability claims, first through safer products and second through diligent documentation of safety incorporated into the full vehicle lifecycle.
As systems become more complex and vehicles move toward full autonomy, there will be an even greater need for methodical, safety-based design and production.
LHP Engineering Solutions advises customers on commonsense approaches to applying standards, establishing methods, and creating safe automotive products.