Synopsys Cloud
Cloud native EDA tools & pre-optimized hardware platforms
Request a Free Trial →
Thanks to advanced hardware and software, smart vehicles are improving with every generation. Capabilities that once seemed far-off and futuristic¡ªfrom automatic braking to self-driving at the very pinnacle¡ªare now either standard or within reach. However, considering how vehicle architectures have continued to evolve, the way that safety and security are being addressed also must change.
Vehicles have typically been designed with dozens of discrete microcontrollers, each managing a separate function, from window operations and door locks to engine control. Now, we¡¯re seeing increased centralization, with large systems-on-chip (SoCs) managing wider categories of functions. For example, one SoC might be dedicated for all vehicular communications, another for networking, and so on.
Considering the size and complexity of today¡¯s automotive SoCs, a sound approach is to really understand the safety architecture and develop a safety plan first, before defining the vehicle¡¯s architecture. The safety plan should be guided by automotive functional safety standards, namely ISO 26262. Developed by the International Organization for Standardization in conjunction with the International Electrotechnical Commission (IEC), ISO 26262 mandates a functional safety development process, from specification through production release, for automotive OEMs and suppliers to follow and document in order to have their devices qualified to run inside commercial vehicles. By following ISO 26262, automotive OEMs and suppliers provide assurance that their devices will perform as intended, when intended. The standard outlines a risk classification system, based on Automotive Safety Integrity Levels (ASIL), with the aim of reducing possible hazards caused by malfunctions in electrical and electronic systems. There are four ASILs, each based on the probability and acceptability of harm. ASIL D, the highest degree, is most relevant to safety-critical applications like Advanced Driver Assistance Systems (ADAS). ASIL D will only continue to grow in importance as vehicles incorporate increased levels of autonomous driving capabilities.
Another framework for which automotive safety devices must comply comes from , which was founded in 2003 to create an open and standardized automotive software architecture and has defined the use of C++14 for safety-critical environments. Also important in the early phases of safety planning is consideration of cybersecurity measures. The U.S. National Highway Traffic Safety Administration (NHTSA) has an updated 2020 draft of its document, which mandates compliance from anyone manufacturing or selling vehicles in the U.S. The organization considers vehicles to be ¡°cyber-physical systems and cybersecurity vulnerabilities could impact safety.¡± Other automotive security standards, such as ISO/SAE 21434, are in the early stages, but look to help drive best practices in developing security architectures for safety-critical SoCs.
Defining a Safety Plan for Automotive SoCs
A strong safety plan outlines and defines all of the safety mechanisms for a given component, including compliance with AUTOSAR standards and ASIL levels. It¡¯s also important to factor in cybersecurity at this stage. A key component of executing a safety plan is the implementation of a functional safety manager.
When designing with discrete microcontrollers, automotive engineers tend to utilize discrete safety managers from their chip vendors. With an SoC-centric approach, it¡¯s important from safety and performance perspectives to have a dedicated safety manager integrated on the SoC to initiate, manage, and schedule boot-up and mission-mode tests. A large SoC tends to have multiple processor cores. Devoting a dedicated processor core to serve as a safety manager prevents periodic safety checks and monitoring tasks from interfering with normal SoC operations, while also isolating safety code from non-safety application software. Other benefits include reduced power and area, lower system costs, and enhanced real-time response rates. The figure below illustrates the evolution from a multi-chip to a single-chip solution for an advanced driver assistance system (ADAS) application.
Meeting Functional Safety Software Requirements
With hardware comes the need for software, which is where functional safety manager software comes into play. Having an integrated functional safety manager provides many benefits, including:
- Independent and deterministic safety decision-making across various subsystems of a complex automotive SoC, with the option of having a dedicated safety routine per subsystem or IP module
- Faster time-to-market through substantially reduced software overhead
Automotive software developers can choose to write their own functional safety software. But, clearly, this requires an investment in time and resources. Alternatively, they can turn to a proven, off-the-shelf software library. An effective safety management software library consists of:
- A test manager that plans and schedules test execution, interacts with test providers for full SoC test coverage, works in boot and mission modes, and manages fault injection
- A fault manager that collects and post-processes raw fault notifications from SoC components and converts them into safety alarms; maintains severity, hierarchy, and aggregation of safety alarms; generates software-visible safety alarms via callbacks or non-maskable interrupts; and asserts hardware fault notification or reset signals
- A watchdog manager that handles internal watchdogs to control program execution flow, handles external watchdogs to guarantee system-level fault detection time intervals, and interacts with the test manager to provide the seed for test signature generation
Introducing ASIL-Certified Software
Synopsys recently unveiled a set of ASIL-certified ARC? embedded functional safety software components for safety-critical applications:
- A functional safety C runtime library provides building blocks for safety-critical applications
- Software test libraries provide a mechanism to achieve ASIL certification where redundant hardware isn¡¯t required
- Fault, watchdog, and test management components enable a fully programmable SoC safety management solution
- Example MCAL and complex drivers ease integration into an AUTOSAR environment
The functional safety software stack runs on ASIL D-compliant DesignWare? ARC functional safety processor IP to simplify safety-critical automotive SoC development and accelerate ISO 26262 qualification. To facilitate development, debugging, and optimization of embedded software for ARC processors, we offer ASIL D-certified ARC MetaWare Development Toolkit for Safety. The combination of the software stack and the processor IP can save several staff years of development time.
The ARC software stack and processor IP are part of a larger portfolio of Synopsys solutions for automotive design. With a long history of automotive expertise, Synopsys provides many other resources to help hardware designers and software developers comply with automotive functional safety requirements:
- Comprehensive automotive design solutions for complex functional safety analysis, implementation, and verification
- A unified functional safety verification platform that brings together technologies for failure modes and effect analysis (FMEA); failure modes, effects, and diagnostic analysis (FMEDA); and fault injection campaign management
- Test automation, simulation, and prototyping solutions
- And, in the area of security, automotive software security testing solutions that enable developers to build security and reliability into modern connected cars
Planning for safety early in the vehicle design process can pay big dividends for you and, ultimately, your customers. And by executing a safety plan with ASIL-compliant electronic design automation (EDA) tools and IP, along with robust software security testing solutions, you can save time and effort in the process of creating smarter, safer cars.