Combining safety and security is critical for automotive SoCs.
With the evolution of autonomous vehicles, today’s cars are becoming both more connected and complex. Consumers and suppliers worldwide are demanding much more intelligence and customization, which adds pressure on product development teams to validate the underlying technology and start their design processes months earlier. Enhancements in hardware and software features also mean that the way designers think about automotive safety and security at the system-on-chip (SoC) level must evolve.
While fully autonomous vehicles are still a ways off, there’s a good chance that your car already has driver assistance features such as adaptive cruise control, lane guidance, or active braking. However, as the number of sensors being integrated in automotive systems increases to enable new capabilities, building security and quality into all stages of the design’s lifecycle becomes integral.
The requirements for automotive design are changing, from the silicon all the way to the fully assembled vehicle. Going forward, security and safety are inseparable considerations for automotive SoCs.
Today, every vehicle requires a different blend of sensors to operate at each driving automation level. For instance, a combination of LiDAR, radar, ultrasound, infrared, and camera sensors deliver an increasingly comprehensive picture of the driving environment through object detection and scene segmentation. The role of these sensors is not only to track and identify objects. They must also be able to discern a person from a building in real-time and predict their consequent actions within the context of the “scene.”
As you might expect, this level of intelligence calls for a remarkable amount of processing power to take place locally or be distributed within the vehicle itself. This means connecting the vehicle solely to the cloud isn’t a favorable option since any amount of delay between sending and receiving the information has the potential to endanger the safety of the passenger(s).
All of this has major implications for the future of processor architecture and automotive SoC design. In line with the ISO 26262 functional safety standard for production vehicles, any underlying hardware and software must have functional safety built in to minimize the risk of failure — and potential catastrophe. If that isn’t enough, security of an equally high level is essential for the automotive system to work as designed.
Redundancy of functionality is one way to achieve safety in a manner that also simplifies hardware and software integration, with both “safety” and “mission” mode applications running on a single chip. This makes for easier verification and certification than is possible when functionality is distributed over a board, throughout the car, or across different electronic control units (ECUs).
While safety is one key consideration, it must go hand-in-hand with security. It is no coincidence that in a number of languages, like German or Chinese, the same word describes both. Combining the two is becoming a critical design criterion for teams worldwide.
As cars become more automated and gain access to over-the-air updates, they naturally become more connected. The nature of their operations means they constantly collect and transmit valuable information, which makes them potential prey for malicious attacks by cybercriminals. An attack might take the form of stealing “key” information from a keyless car system to enable a break-in; running a chip in a test or debug mode to gain system privileges; or hacking an infotainment system with a virus via a mobile handset. Whatever the attack approach, if a system is easily hacked, it is simply unsafe. Going forward, this will impact the entire supply chain, from IP blocks to the final assembled vehicles themselves.
An essential component in high-performing automotive SoCs is the role of a functional SoC safety manager. It acts as the brain of the vehicle for monitoring and escalating system failures in real-time, independent of other processing occurring in the chip. This is necessary to meet the top-level ISO 26262 safety standards, including Automotive Safety Integrity Levels (ASIL) D, a risk classification that dictates functional safety for a vehicle’s electrical and electronics systems.
In most cases, it is implemented as a dual-processor setup with both cores operating in a lockstep manner along with a small shift to prevent a fault from transpiring in the same area and comparing those results to detect the occurrence of an error. Synopsys ARC Functional Safety Processor IP is certified for both ASIL B and ASIL D operations, and these are increasingly used as a chip’s safety manager. It supports holistic design with an ASIL D-compliant processor and security to resist attack. It also detects physical tampering and supports a trusted execution environment, while providing comprehensive documentation required for ISO 26262 certification. This in turn is backed with functional safety software to help prioritize and optimize functional safety, add flexibility, and reduce the effort required for implementation and development.
Our ASIL D compliant ARC SEM130FS Processor adds safety-critical hardware features, such as dual-core lockstep, to meet strict automotive safety requirements as well as mitigate random hardware faults and avoids system failures.
Fig. 1: Synopsys ARC SEM130FS Safety & Security Processor.
Secure systems require SoCs with integrated security features. With automobiles becoming the next-generation application hub, embedding a hardware root of trust enables chip manufacturers to secure the device identity and uniquely identify and authenticate themselves to create secure channels for remote device management and service deployment.
At Synopsys, we make automotive SoC design and verification highly predictable for teams to achieve target ASILs with the least impact to quality of results. The ASIL B compliant Synopsys tRoot Hardware Secure Module (HSM) for the automotive segment amalgamates the Root of Trust security solution with hardware safety mechanisms, protecting SoCs against rising data tampering and physical attacks.
Fig. 2: tRoot Hardware Secure Modules with Root of Trust.
Both our IP products fit safety process and documentation requirements, targeting a broad range of applications for telematics, radar, advanced driver assistance systems (ADAS), V2X communications, and industrial SoCs. This allows SoC designers to find ways to implement advanced levels of security while eliminating points of failure.
The automotive industry is transforming on many levels, but its development of smarter, safer cars is perhaps the most noteworthy. Teams responsible for the automotive applications of today and tomorrow will need to think more holistically to factor in both safety and security. As designers continue to address both parameters during the early stages of the design cycle, a “fully” autonomous vehicle on a road near you is no longer far from reality.
Leave a Reply