Cloud native EDA tools & pre-optimized hardware platforms
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 AUTOSAR, 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 Cybersecurity Best Practices for the Safety of Modern Vehicles 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.
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.
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:
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:
Synopsys recently unveiled a set of ASIL-certified ARC® embedded functional safety software components for safety-critical applications:
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:
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.