Safeguarding Automotive Electronics

Modern automobiles can have up to 100 Electronic Control Units (ECUs) depending on their class, make, and model, with the number of ECUs rising even higher in the case of electric vehicles. An ECU is an embedded system in the car’s electronics. They are used to control all the vehicle’s functions, including engine, powertrain, transmission, brakes, suspension, dashboard, entertainment system and more.

Self-driving vehicles’ emergence accelerates the trend, given the critical reliance on sensors and actuators to control the car and respond to external conditions. The reliability of these electronic components can be mission critical to the safety and reliability of the vehicle. As such, industry standards such as ISO 26262 have been developed to ensure the functional safety of automotive electrical and electronic systems.

The ISO 26262 standard defines a risk-based approach to dealing with hazardous operational situations occurring with the automobile’s electronic equipment. It relies on Automotive Safety Integrity Levels (ASILs) to determine risk classes for different ECUs in the vehicle. For example, the engine control ECU belongs to a higher risk class than the ECU responsible for the taillights. Four integrity levels exist from A (the least demanding) to D (the strictest), leading to different constraints and requirements for the ECUs.

From a practical standpoint, building ECUs to be ASIL-compliant requires the addition of verification hardware and safety mechanisms such as redundancy of critical components, error correction codes, Built-in Self-Tests (BIST), system watchdogs, or cyclic-redundancy checks. The ECUs also need to control an increasing number of sensors and actuators; for instance, an airbag ECU controls several airbags in a vehicle in addition to acceleration, angular rate and pressure sensors to evaluate direction and intensity of impact. These added mechanisms and components increase the complexity of the system and the hardware verification process. They require a different verification flow than the one used for non-automotive hardware. The verification process must also support fault-injection to test for various fault handling scenarios.

Several factors make the verification of automotive ECUs and sensors a challenging process. Verification needs to cover real-time embedded mixed-signal domains and must be done at the system level, not only at the component level.  Some verification scenarios require time to complete, which conflicts with the automotive industry’s stringent production calendars that demand first-time-right designs.

Finally, as there are four different ASIL levels, the verification scope must now verify a device not only against its own internal specification, but also against an external one depending on its expected safety level. All devices within a specified category will have to meet or exceeded the ASIL established threshold. This provides a uniform, unbiased criteria for evaluating solutions that are critical components for the design of safety-critical systems.

Automotive cybersecurity adds another set of constraints to verification because all safety-critical systems are security-critical systems. This arises from the fact that a successful cyber-attack on a safety-critical system could lead to human endangerment. Note that the converse is not true, as security-critical systems, such as infotainment, are not necessarily safety critical.

Automobiles are an attractive target for hackers. They have been successfully breached in many highly publicized experiments, sometimes leading to a take-over of the vehicle from a remote location using its infotainment system as a gateway. Standards such as SAE J3061 and ISO/SAE 21434 focus on automotive cybersecurity to avoid such occurrences.

Cybersecurity focuses on potential threats rather than hazards, and those threats are more challenging because they may be undiscovered. Security requires known behavior under all circumstances, so the verification scope must be increased to cover expected inputs and unexpected/unauthorized/illegal inputs. This dramatically increases the scale of the verification effort. The challenge is to include the additional input set and perform proper verification, and all this within the time constraints imposed by automotive production calendars.

Foundational to safeguarding any electronic system is security anchored in hardware. This can be done by embedding a hardware root of trust in the ICs used in automotive ECUs. Rambus offers ISO-26262 ASIL-B and ASIL-D ready hardware root of trust cores tailored for automotive applications. These root of trust cores (RT-640 and RT-645 respectively) protect against a wide range of failures such as permanent, transient and latent faults, and hardware and software attacks with state-of-the-art anti-tamper security techniques. Partnering with Rambus, a company with over twenty years of renowned security experience, automotive designers can help ensure their safety critical SoCs are safeguarded against cyberattack.

Additional Resources:
White Paper: Implementing Security by Design
Blog: Rambus CryptoManager Root of Trust Cores Certified ASIL-B/D Ready for Enhanced Security in Automotive Applications
Website: Rambus Root of Trust Solutions
Website: Rambus CryptoManager Root of Trust RT-640 (ASIL-B ready)
Website: Rambus CryptoManager Root of Trust RT-645 (ASIL-D ready)