Software-defined Vehicles Are Driving the Evolution of Automotive Electronic Architecture

The modern vehicle has been characterized as an advanced computing system on wheels, with capabilities once unimaginable. Drivers have access to a full array of in-vehicle infotainment and Advanced Driver Assistance Systems (ADAS) that improve the quality of the driving experience, driver safety, fuel efficiency and more. As these systems become more available in both high-end and mainstream vehicles, adopting an electronic architecture that future-proofs against obsolescence while providing a major competitive advantage will be the primary goal for automotive OEMs. To achieve this, automobiles will need to transform from highly electromechanical terminals into intelligent, extensible and upgradable electronic terminals¹. However, today’s existing electronic architectures limit this ability in vehicles, prompting a shift away from existing hardware-defined systems toward software-defined systems. Developing and deploying software-defined vehicles offers multiple benefits to consumers and manufacturers alike. First and foremost, they offer improved safety systems benefitting the driver and passengers. Software-defined vehicles retain higher value over time, because they can be updated with the latest security features, other updates and new applications over the air, similar to a mobile phone. Finally, OEMs can benefit from a continued post-purchase revenue stream, as new features can be commoditized and delivered in the form of add-on services. However, traditional architectures need to evolve to support this transition. Let’s take a look at today’s prevailing architecture and the changes necessary to support software-defined systems in the modern, intelligent vehicle. The Domain Architecture In existing architecture, key functions such as power steering, anti-lock brakes, door and seat controls, and environmental controls, are divided into separate systems, each consisting of sensors and actuators connected to a dedicated ECU. The individual ECUs are grouped by similar functionality and connected to a central domain controller, such as an ADAS or IVI. Each domain controller is then connected to a gateway that can pass information between domains as required (see Figure 1).

This type of architecture is efficient when the sensors and actuators are in close proximity to the ECU and processing can be done independently. Moreover, the domain architecture is flexible, in that a new function can be added to a vehicle simply by using an ECU, sensors, and actuators. However, the drawback to the Domain architecture approach is the amount of cabling required to connect the sensors and actuators to the ECUs. When the sensors and actuators are further away or in multiple locations throughout the vehicle, more cabling is required and configuration becomes complex. Today’s average vehicle has over 100 ECUs² and anywhere from 1-3mi³ of cabling. Aside from the engine and chassis, wire and cable harnesses are now the third heaviest item⁴ in a vehicle! As safety-critical and in-vehicle applications become more sophisticated, the amount of computational power in a vehicle must also increase significantly. In fact, the lines of code per vehicle are expected to grow at a 40% CAGR to over 300 million lines of code⁵ by the end of the decade (see Figure 2).

“In addition to more sophisticated applications, vehicle autonomy is also increasing, and demand for full-featured infotainment centers that support the streaming of content such as music, videos, gaming, and information is accelerating,” says Ryan Suzuki, Sr Automotive Product Marketing Manager. As a result, more processing power is essential. Processing and bandwidth will need to be able to scale accordingly, as new services are introduced over the life of a vehicle. To meet future software requirements and future-proof automobiles against obsolescence, the next-generation automotive electronic architecture should have sufficient processing power and communication bandwidth to handle complex computations and communications. One solution that OEMs are increasingly adopting is Zonal architecture. Why Zonal Architectures Will Replace Domain Architectures in Next-Generation Automotive Design In a Zonal architecture, instead of the systems being separated by domains, all functions within a certain region of the vehicle are connected to a zonal gateway. Each gateway is connected to other zonal gateways – as well as high-performance, centralized processors – through a multi-Gig Ethernet communication channel (see Figure 3). This means fewer cables are needed to power the individual functions.

A Zonal architecture provides several benefits: ● Simplified cabling: Sensors and actuators are closer to the gateways, so the connections between gateways and the central processor becomes a high-speed network rather than a complex automotive wire harness. ● High-performance central compute: The central processing module provides enough processing power to support computation for all functions within the vehicle. ● Ethernet backbone: Ethernet enables the efficient transmission of data between sensors and the central processing module for faster processing. While shifting from a Domain architecture to a Zonal architecture will support the increased processing and computational needs of next-generation automobiles, it will also have a significant impact on memory and storage requirements. In our next blog post, we’ll explore these requirements and explain how memory and storage solutions from Samsung can facilitate a smooth transition, to empower OEMs to embrace innovation and remain competitive in the rapidly evolving automotive industry. Meanwhile, you can learn more about Samsung’s memory and storage solutions here. _{¹ According to Deloitte, the "software-defined vehicles" transformation will drive the development of the automotive industry over the next 5-10 years. ² An electronic control unit (ECU) is a small device in a vehicle’s body that is responsible for controlling a specific function. ³ A centralized zonal architecture could reduce the number of ECUs needed by 20%, saving OEMs up to 10% in material and hardware costs. ⁴ In one test, dropping from 35.0mm2 to 25.0mm2 reduced the copper weight by 30%, and lessened the cable area by 38%. ⁵ One million lines of code is equivalent to 18,000 A4 pages.}