Automotive computing: onboard, edge and cloud
Vehicles now depend on computing that runs in three places: in the car, at the edge of the network and in the cloud. This explainer sets out what runs where, what 5G adds, how carmakers organise the work, why hardware and software are being separated, and how vehicles are secured.
Why vehicles need more computing
- Four trends, known together as ACES, drive the growth in vehicle computing: autonomous driving, connected vehicles, electrification and shared mobility.Source: McKinsey on Semiconductors, No. 9, March 2024, p. 34.
Onboard, edge or cloud
- Each vehicle workload can run onboard, at the edge or in the cloud. Safety-critical functions stay onboard.Source: McKinsey on Semiconductors, No. 9, March 2024, pp. 34 to 36.
- Onboard
- The vehicle's own controllers and central computers. Braking, steering and driver assistance run here, because they cannot depend on a network connection.
- Edge
- Compute close to the road, in roadside units, cellular base stations or nearby data centres. It suits work that needs a short round trip and draws on more than one vehicle, such as local traffic and hazard information.
- Cloud
- Central data centres, for work that is not time-critical: map updates, fleet analytics, training driver-assistance models and preparing software updates.
See edge computing and edge AI in the glossary.
What 5G adds
The International Telecommunication Union (ITU) defined three usage scenarios for 5G, under the name IMT-2020, and 3GPP specifies the radio standard that meets them (5G NR). ITU's minimum requirements are the primary figures:
- Enhanced mobile broadband (eMBB): high data rates. The minimum peak data rate is 20 Gbit/s downlink and 10 Gbit/s uplink.Source: Report ITU-R M.2410-0 (11/2017), Minimum requirements related to technical performance for IMT-2020 radio interface(s).
- Massive machine-type communications (mMTC): very many low-power devices. The minimum connection density is one million devices per square kilometre.Source: Report ITU-R M.2410-0 (11/2017), Minimum requirements related to technical performance for IMT-2020 radio interface(s).
- Ultra-reliable low-latency communications (URLLC): short, dependable delay. The minimum user-plane latency requirement is 1 ms.Source: Report ITU-R M.2410-0 (11/2017), Minimum requirements related to technical performance for IMT-2020 radio interface(s).
- The report groups 5G capability into enhanced mobile broadband (about 10 Gbit/s), massive IoT (up to one million devices per square kilometre) and ultra-reliable low-latency communication (about 1 ms).Source: McKinsey on Semiconductors, No. 9, March 2024, p. 37.
For vehicles, enhanced mobile broadband carries infotainment and large software downloads, massive machine-type communications serves dense sensor and roadside networks, and low-latency communications is the basis for time-critical messages between vehicles and infrastructure.
How carmakers organise the work
Vehicle functions have long been grouped into domains, such as powertrain, chassis, body, infotainment and driver assistance, each with its own controllers. Many new designs move toward a few central computers and zonal controllers. Carmakers broadly follow one of three models, and many mix them by domain:
- In-house
- The carmaker designs the central computer and writes much of its software, buying chips and components directly.
- Supplier-led
- A tier-one supplier delivers an integrated system, hardware and software, to the carmaker's specification.
- Partnership
- The carmaker co-develops a platform with chip makers and software companies, sharing the work and the rights to it.
Work in progressThis section is the Hub's editorial summary of general practice and will gain cited detail. Suggest a source or a correction
Decoupling hardware and software
Traditionally each vehicle function came as a controller with its own software, developed and released together. Decoupling separates the two: software is written against a stable hardware abstraction and middleware layer, so it can be developed, tested and updated on its own schedule, and the hardware can change without rewriting every application. It is the basis of the software-defined vehicle.
- McKinsey forecast, 2022Decoupling hardware from software can cut development time by up to 40 percent.Source: McKinsey on Semiconductors, No. 9, March 2024, p. 40.
The firmware and software lifecycle shows how software is developed and released alongside the chip.
Cybersecurity
A connected, updatable vehicle can be attacked remotely. In the markets that apply UNECE vehicle regulations, such as the European Union and Japan, type approval requires a managed approach. The primary texts:
- Requires a vehicle manufacturer to run a certified cyber security management system across the vehicle's life, as a condition of type approval.Source: UN Regulation No. 155 (UNECE WP.29), Cyber security and cyber security management system.
- Requires a certified software update management system, covering how updates, including over-the-air updates, are made and recorded.Source: UN Regulation No. 156 (UNECE WP.29), Software update and software update management system.
- Sets out cybersecurity engineering for road vehicles: risk assessment, secure development, production, operation and decommissioning.Source: ISO/SAE 21434:2021, Road vehicles: Cybersecurity engineering.
Common practices that put these into effect:
- Threat analysis and risk assessment for each function, kept up to date for the life of the vehicle.
- A hardware root of trust and secure boot, so each controller runs only signed software.
- Signed and encrypted over-the-air updates, with protection against rolling back to an older version.
- Separation of safety-critical and connected domains, with gateways and firewalls between them.
- Intrusion detection in the vehicle and monitoring across the fleet, with a process for responding to incidents.
- Security requirements passed down to suppliers, with evidence collected back through the supply chain.
In the glossary: UNECE R155, UNECE R156, ISO/SAE 21434 and OTA.
Related
- Automotive chip lifecycle, for how an automotive chip is developed and qualified
- Firmware and software lifecycle, for the software that runs on it
Facts restated in our own words from McKinsey on Semiconductors, No. 9, March 2024, with the printed page. Forecasts are labelled as such and are the report's, not the Hub's. Where the report names a primary source, that source is the authority: check it before relying on a figure. The ITU figures and the regulation and standard summaries are read from the primary texts named under each.