Build In Functional Safety Early

In the automotive world, recalls for electronics affect about five percent of the vehicles on the road. That means 5 out of every 100 vehicles today have a problem with their electronics. If we want to see more autonomous driving vehicles, that number must be improved. There needs be more robustness in the development process.

Making cars safer today is Advanced Driver Assistance System (ADAS), a collection of enhancements that better inform the driver of the environment in and around the car. ADAS introduces a web of different sensors that can, among other things, detect other cars and objects on the road, day or night, and even help regulate the spacing of the cars on the freeway, or assist the driver in avoiding a collision by altering speed or stopping the vehicle. The addition of these sensors to a car has lowered the fatality rate among drivers significantly in the last decade. It has also increased the number of chips and lines of code in the software present in the car, greatly increasing the liability and risks of failure or a glitch within those systems.

Unlike a blue screen of death that may occur on a desktop or laptop computer, a chip or software failure within a vehicle traveling at highway speeds could result in significant injury or death to the driver, their passengers, or others.

Preventing this possibility requires building in functional safety, which is defined in ISO 26262 – Functional Safety for Road Vehicles. Specifically, ISO 26262 sets out definition for various Automotive Safety Integrity Levels (ASIL) with Level D (ASIL-D) being the highest automotive software integrity level, and often the hardest to achieve. To guarantee the safety of any vehicle, ASIL-D must be a part of even the smallest pieces of electronics.

That starts with the System on a Chip (SoC). Robust design can and should begin at the SoC level by integrating functional safety from automotive industry. In other words, functional safety doesn’t have to wait until later — in the system world, in the ECU world – it can be built into the chip design itself. This can be done with a virtual prototype, a model of the hardware in development, which can allow software development on those SoCs to begin at a very early phase.

Implicit is the continuous testing of these hardware and software designs throughout the automotive development lifecycle. If the chips and the software can be secured, step by step, within the automotive development process, this creates clear milestones that build in safety and security and quality along the way. It also “shifts left” the mitigation of errors that traditionally compound as the vehicle gets closer and closer to production, so the traditional error curve begins to flatten. This, then, accelerates the overall time to production.

Synopsys provides OEMs with multiple tools to optimize the quality, security, and safety throughout the vehicle lifecycle. For example, our ARC EM safety-island IP and dual-core lockstep processors and the new ASIL-D-ready-certified ARC EM4SI, EM6SI, EM5DSI, and EM7DSI processors come with a self-checking safety monitor as well as hardware safety features, such as error-correcting code and a programmable watchdog timer to help detect system failures and runtime faults.

Our virtual prototype technology allows Tier 1s and the entire automotive ecosystem to begin software development in parallel with hardware development – accelerating time to production. And our software development tools ensure systematic quality checks to sign off for the next milestone in the development process.