Autonomous Driving and Functional Safety

The timelines proposed by automobile manufacturers for enabling fully autonomous driving are extremely aggressive. At the recent DAC55 conference in San Francisco, I attended a panel discussion on Functional Safety issues for assisted and autonomous driving, sponsored by Mentor Graphics. I also had the opportunity to chat with Bryan Ramirez, DVT Strategic Marketing Manager at Mentor, about the progress, opportunities, and challenges in addressing these issues. The insights shared by Bryan and the panel were eye-opening (to me, at least).

Classes of Autonomous/Assisted Driving

First, I needed to review the different “classes” associated with assisted and autonomous driving. The figure below highlights the 5 categories defined by the Society of Automotive Engineers (SAE) and the National Highway and Traffic Safety Administration (NHTSA).

“The 5 levels of automated driving (6 levels, if you include no automation)” Source: link.

The figure depicts the operational aspects of the driver-vehicle interaction, but does not really highlight the functional safety measures that are also required. Bryan educated me by providing the following background info.

“Automotive system design in the era of assisted and autonomous driving requires additional focus on failure detection and diagnosis. Safety mechanisms must be incorporated to react to faults.”, Bryan began. “Levels 2 and 3 require ‘fail safe’ support – for example, upon detection of a system fault, the car can be directed (by the driver)to the side of the road away from traffic. Levels 4 and 5 require ‘fail over’ systems, where the vehicle remains operational(for some period of time).”

Functional Safety and System “Faults”

I asked, “Faults is perhaps an overloaded term (thinking of IC fabrication terminology). In this context, what is the nature of the faults that system designers must consider?”

“There are three classes of faults in system design which need to be addressed as part of functional safety.”, Bryan explained. Here are the key characteristics of each:

• systematic fault

In short, a systematic fault means that the design does not fully satisfy the system requirements.

A major EDA flow and methodology emphasis is to provide designers with the capability to demonstrate traceabilitybetween implementation features (and verification testbenches) to the corresponding system requirement.

The demonstration of traceability applies to both the hardware and embedded software, of course. To assist with this effort, Siemens acquired Polarion Software in 2016, to leverage their expertise in software application lifecycle management (ALM) – their tools assist software developers with requirements management, software development and integration, testing and traceability, software maintenance, and version release management. This group is now part of the larger Siemens Product Lifecycle Management team. (link)

Nevertheless, Bryan indicated,“Traceability throughout system development – especially the IC flow – remains an automotive design challenge. Significant progress has been made to improve requirements-to-implementation verification methods, but more needs to be done. Mentor and Siemens are addressing this need by integrating the Siemens Polarion Lifecycle Management software with Mentor’s EDA software to bring traceability down to the IC flow.”

Separately, the Functional Safety panel echoed the same sentiment, providing the example: “System design standards are evolving, and thus, so are the requirements. Comprehensive traceability and PLM support is needed, so that it can readily be determined that an SoC verified to application 1 can be used for application 2.”

• random faults

Failures in electronic hardware will occur over the product lifetime – automotive systems must ‘fail safely’, as mentioned earlier. There are a few areas where functional safety considerations arise to respond to a random fault:

(1) addition of ‘safety mechanisms’ to the hardware design to reduce susceptibility to faults

Siemens recently acquired Austemper Design Systems, whose expertise relates to the integration and verification of hardware reliability (link). For example, Austemper provides software that automates the insertion of safety mechanisms into the RTL to detect and correct errors resulting from hardware faults. These constructs include ECC, CRC, parity, redundancy, and protocol checking, and are directly incorporated into an SoC design – “safety synthesis”, in other words.

(2) proving the design is safe from faults

The goal of this safety verification is to provide metrics as evidence of the safeness of the design. The Austemper acquisition also brings safety analysis. Additionally, Mentor’s Tessent DefectSim provides defect coverage analysis for analog/mixed-signal IP, to get a more comprehensive safety assessment of the SoC.

(3) exercising system diagnostic tests to identify failures

Bryan indicated, “Exercising system diags is an integral part of functional safety, and the detection of random faults. As an example, an exhaustive set of diags can be run at ‘key on’ or ‘key off’, which are used to identify permanent faults. System diags work in conjunction with the real-time detection, associated with the Austemper safety mechanism insertion. The Austemper acquisition also brings high performance fault simulation and safety analysis. To assist with diagnostic analysis, Mentor offers Tessent MissionMode, a full methodology for test controller insertion on an SoC, to improve internal DFT architecture examination and operational diagnosis.”

• a “security” (malicious) fault

Given the vehicle-to-vehicle (V2V) and/or vehicle-to-everything (V2X) communication capabilities that are envisioned as requirements for autonomous driving, the security of that communication with regards to a malicious attack is paramount.

“Frankly, identifying and addressing the functional safety issues associated with security faults is still a work in progress.”, Bryan acknowledged.

EDA tool testing

I asked Bryan, “What is the role of the EDA tool vendor to ensure tools are safe to use when addressing functional safety?”

(One of the panel members said, “Actually, I don’t mind using tools from different EDA vendors in design flows – I feel that independence provides an additional level of validation against any systematic faults in a specific tool and its data model.”)

Bryan said, “The Mentor SAFE program defines an extensive set of EDA tool development requirements, consistent with the ISO26262 standard. SAFE involves preparation of tool qualification methods and reports, and validation coverage evaluations, all intended for customer review. Additionally, Mentor engages third-party auditing firms to provide independent ISO26262 certification.” (link)

“The SAFE program addresses not only point tool qualification, but also cross-validation – for example, between simulation and formal verification toolsets.”, Bryan added.

Functional Safety Verification and the “Digital Twin”

Bryan quoted a source from Toyota, who stipulated that “Class 5 autonomous on-the-road testing would require 8B+ miles traveled, throughout diverse types of roads, traffic, pedestrian and bicycle interactions, and weather conditions.” Clearly, physical testing is not feasible, and must utilize an alternative verification method for potential scenarios.

As a result, EDA vendors and system developers are striving to establish a “digital twin” employing a complete, comprehensive system model. “The automotive industry is transitioning to model-based engineering.”, as one panel member described the approach.

The first step in pursuing a digital twin is to develop a suitable model for the sensors and actuators at the edge of the automotive system.

The validation scenarios for the digital twin involve a full sense-compute-actuate operational sequence.

To address the digital twin model validation requirements, Mentor’s Veloce Strato emulation platform is well-suited.

Bryan added, “There aren’t sufficient functional safety experts out there – developing functional safety use cases requires both a broad understanding of automotive systems, as well as precise modeling experience. The Siemens acquisition of TASS and Austemper brings that expertise.”

Functional Safety Challenges

I asked Bryan, “What are the big challenges ahead? What keeps you up at night?”

“Among many, there are two challenges I’ll highlight.”, Bryan said. “First, machine learning is clearly an important facet to developing the inference engines to be used in automotive systems. Yet, the flows for network architecture definition and training are relatively new, and very unique. Understandably, the focus has been on demonstrating correctness, rather than the functional safety implications.”

“Second, we talked about random faults as if a single point-of-failure arose, and functional safety features could ensure ‘fail safe’ or ‘fail over’ operation. Yet, what about the case of cascaded faults? For example, what if a capacitor blew, which took out a regulator, which brought down a power supply, which made an ECU inoperable? There are many, many (cascaded) scenarios yet to define, and subsequently develop and verify the corresponding functional safety features.”

Wow! I walked away from the panel discussion and the meeting with Bryan with a mixed outlook. The good news is that all tiers of automotive suppliers (and EDA vendors) are focused on functional safety issues, with “digital twin” modeling and simulation support. The bad news is that addressing these issues will require considerable resource and specialized expertise to define, validate, and implement functional safety measures for an increasingly complex set of scenarios – we may be in an ongoing “alpha” or “beta” testing era for some time.

-chipguy

PS. The recent acquisition strategy pursued by Siemens clearly demonstrates a focus on all facets of complex automotive system design (and PLM). For those who may have been skeptical when first announced, the Mentor Graphics acquisition has clearly been extremely synergistic to that goal.

Share this post via:

• 
• 
• 
•