Over-the-Air Automotive Updates

Modern vehicles are increasingly-connected devices with growing volumes of electronic systems. This systemic complexity means that even an average vehicle design will include over 150 ECUs, which control not just infotainment and communications, but powertrain, safety, and driving systems (figure 1). We see not just a surge in the volume and complexity of electronic hardware, but also software. New cars have about 100 million lines of code, and this is growing fast.

To ensure the correct and safe operation of these complex systems, designers have to build in functional monitoring to ensure functional safety, safety of the intended function, and security issues. Root of Trust (RoT) and other layered security mechanisms inside the chip ensures that chips are not compromised in manufacturing, in the supply chain, or during field use.

Fig. 1: Vehicles have a lot of electronics hardware and software.

However, the hardware and software in automotive devices also needs to be updated during the device’s lifecycle. Software errors, for example, account for a large and growing number of recalls in the automotive industry, about 46 percent of the total recalls.

We are all very accustomed to having updates not only to desktop computers, but to cellphones, TVs, even domestic appliances. Currently, only about 22 million vehicles have any type of wireless, or over-the-air (OTA) update capabilities. By 2025, that number is expected to grow to more than 250 million vehicles. IHS Markit estimates the total OEM cost savings from OTA updates to reach $60.9 billion by 2025.

Automotive safety and security regulations

The advantages of wirelessly connected and remotely updatable vehicles comes with cybersecurity risks. The new UNECE (United Nations  Economic Commission for Europe) regulation R155 (also known as WP.29/GRVA/79), which is due to come into force during this year,  is a conscious move towards treating the cybersecurity of a vehicle as an entity and ensuring OEMs take on the legal responsibility of automotive cybersecurity. In fact, it requires an automotive OEM to remain solely responsible for the cybersecurity of a vehicle throughout its entire lifecycle. The approach of the UNECE regulation aligns closely to existing and developing standards from the ISO (26262 [functional safety] and 21434 [cybersecurity]).

There are two obvious financial ramifications for non-compliance to UNECE R155 regulations:

• Inability to sell non-certified vehicles within EU, Asia, and Australia, as of 2024.
• The high cost of vehicle recall.

OEMs must start making the transition to compliance immediately, including for vehicle types that are already in production to minimize the potential financial impacts. R155 (or WP.29/GRVA/79) makes it clear that software security processes are inherent in any design, and extend to software updates. That means that vehicles in development and even some already on the roads should have their systems ‘upgraded’ to adhere to these standards.

Need for in-life, in-built embedded analytics

SoCs in complex automotive systems have to remain aware of threats and changes to the system and be able to receive updates—software and security patches to keep ahead of security threats and in-line with evolving regulatory requirements.

Silicon for automotive applications designed with intelligent embedded analytics will benefit from verification and validation in product development. But, the same embedded analytics IP provides powerful monitoring capabilities ‘in-life’ to spot both systemic and random errors, providing a new level of safety functionality and allowing in-field system health monitoring and advanced cybersecurity forensics.

Designers can incorporate intelligent self-analytic capabilities in the SoCs at the heart of today’s automotive electronics using Tessent Embedded Analytics semiconductor intellectual property (SIP).

Cars designed this year need to have systems that stay up to date and can be upgraded well into the 2030s, with continued support for OTA for an expected minimum of 15 years. That means an SoC designed into an automotive system today has to be capable of fighting off threats from hacking, changes to security and safety requirements as an absolute minimum. An embedded analytics infrastructure helps to monitor for changes that would indicate a threat to a vehicle system that can be life-threatening.

The evolving threats and design requirements mean there are also constant changes and development of the industry standards that govern automotive design and these are constantly being upgraded as threats and the automotive systems themselves change.

Defense in Depth

That brings us onto the issue of ‘Defense in Depth’, a strategy of delivering secure control systems by viewing threats and security solutions as multidimensional. It’s one thing to defend today’s threats, but who knows what is around the corner? We need to deploy as many threat prevention, detection and response measures as we can today, to do our absolute utmost to protect ourselves from the unknown threats of tomorrow. A Defense in Depth approach forces you to look holistically at all aspects of vehicle production and usage and layer on as many different techniques as you possibly can (figure 2).

Fig. 2: Defense in depth strategy for system’s lifecycle security and integrity. Source: Siemens

Secure access in implementing OTA

Ensuring chips are not compromised in manufacturing, in the supply chain, or during field use can be enabled by a root of trust (RoT) and other security mechanisms inside the chip. In an OTA update, only authorized and ‘suitable’ software should be ported to the automotive system, which makes it essential to have a hardware-embedded root of trust. To ensure that OEMs implement the highest security standards for OTA, UNECE defined R156 (Software Update Processes and Management System), which is accompanied by ISO24089, currently being developed.

Embedded analytics allow the SoCs to confirm compliance at the bit level, for safety, security and for suitability to match the hardware configuration in use. Traceability is fundamental here: tracking the build of any software through to its implementation with full software authentication and encryption to ensure payload is delivered appropriately.

At the design level, by architecting SoCs to integrate IP for sensors, security, and chip identifiers and inserting such IP along with DFT IP as part of the design flows, SoC suppliers can establish a foundation of hardware enablement for trusted and secure Silicon Lifecycle Management.

Fundamentally, the traceability needs to be included in the hardware design, with each chip granted a unique and permanent identifier, so that in-field provisioning, data gathering, monitoring, and management, including OTA, can all be linked back to the specific chip’s history and lifecycle data (figure 3). The traceability and root of trust identifiers are established at the chip level, but a ‘device identity’ could incorporate a number of chip-specific identifiers.

Fig. 3: Silicon lifecycle management establishes traceability.

Hardware enablement is not enough on its own. Software chip-to-cloud infrastructure platforms, open APIs and standards will enable SoC embedded analytics through secure SoC data access for monitoring and managing the population of chips in the supply chain and in the field. A software chip-to-cloud infrastructure can evolve by partnering with PLM and Cloud Service providers, if SoCs are architected to support a wide variety of use cases including mass zero-touch enrollment during manufacturing, traceability through the supply chain, onboarding to the cloud and ultimately monitoring and managing automotive devices over the air. In order for partnerships to create value, chip suppliers should focus on gathering requirements from the end application and using that as a strategic basis for their next-generation SoCs.  For more details on root of trust as part of a Secure Silicon Lifecycle Management strategy, see my previous article here.

Of course, it’s not just the deployment of updated software where security is important. Once we have implemented these advanced security and monitoring technologies, the data we collect from our SoCs is extremely valuable. This means the collection and storage of data from the vehicle/devices is critically important. There is a lot of discussion in the industry about the types of data collected and ensuring it is kept completely separate from any personal data that could also be collected from the vehicle.

Summary

With the technologies available today, we are able to address many of the challenges surrounding OTA updates and the regulations, from high-level application and data management through to the silicon-level threat-monitoring IP.