Semiconductor solutions and electronics have played a key role in vehicle electronics and will continue to do so. Looking ahead, innovations will happen by software consolidation and integration of formerly separate domains. For most original equipment manufacturers (OEMs) with a wide range of car platforms, the actual electric/electronic (E/E) architecture transformation to a fully software-defined vehicle will happen in incremental steps, moving more and more functionalities into zone architectures while increasing centralized processing where it makes sense.
Today’s E/E architectures primarily employ a domain architecture, organizing electronic control units (ECUs) and cabling together into specific functional domains like the powertrain domain. In contrast, zone architectures group many, if not all, domain functions based on their geographical location, or zone, inside the car.
The zone architecture will facilitate independence of sensors and actuators from the central vehicle compute node. In other words, hardware and software update cycles can differ, and sensor and actuator designs can last longer than vehicle design cycles. Moreover, zone architectures will reduce the number of ECUs and cable lengths, simplifying the vehicle architecture and the associated system validation effort.
Additionally, this architecture will allow OEMs to increase their ownership over the software content, especially with firmware over-the-air (FOTA) updates and by moving to a service-based structure and aggregating real-time control. Equally important, the zone module will enable more granular and energy-conserving power distribution topologies by powering down the unused sub-modules.
This article will focus on these initial drivers of the zone architecture, enabling improved FOTA and power distribution concepts, and will discuss the next potential evolutionary steps toward fully software-defined vehicles.
FOTA enables future-proofing
FOTA updates are a key driver for zone control architectures and a vital part of a software-defined vehicle. In the past, legacy networks, primarily Controller Area Network (CAN)-based, were slow; local ECU memory was scarce, and due to the associated cost, updates were very rare. Today, car OEMs want to enable firmware updates anytime, anywhere—no longer limited to service stations—and as frequently as needed, not only to fix bugs but to enhance features after the vehicle sale and test new functions, such as a new autonomous-driving (AD) capability in the background.
The zone architecture offers multiple advantages for such updates versus legacy E/E architectures. The combination of fewer ECUs overall and the more dominant role of high-speed in-vehicle communication networks are drastically reducing update times.
Zone architectures will have an always-on cloud connection via a telematics unit, typically with a link to a central storage location. The deployment with central storage for all ECUs simplifies the architecture, but at the same time, the zone ECUs require more non-volatile memory, allowing temporary storage of new firmware while the older firmware is still operating. The exposure of the entire car network and its update storage location also drives security requirements, mainly for authentication and encryption. This is vital to ensure that only validated and safe firmware can be applied to all of the ECUs.
The corresponding secure network can ideally be based on MACSec (IEEE_802.1AE), protecting all Layer 2 protocols, offering identification/exclusion of unauthorized connections and reducing latency and performance needs versus higher-layer protocols like IPSec or SSL.
There is also some less obvious impact of frequent FOTA updates, nevertheless an essential piece to deploying a fully service-based software approach. The idea is to keep sensor and actuator code unchanged as long as possible to avoid heavy validation effort while adding more application-level features to higher layers in the software. This mainly works well when control loops can be implemented locally in the zone module and the content of “smart” sensors and actuators increases.
The improved FOTA update architecture will also bring benefits for the so-called “shadow mode,” which fully relies on easy-to-deploy firmware upgrades. Conceptually, this means all major ECUs will offer more compute performance than needed at the beginning of the car life cycle. Figure 1 illustrates this idea. When looking on the left, you can see multiple SoCs have only minimal resource loading for initial target use cases.
Figure 1: ECU shadow-mode use cases for ADAS (Source: Texas Instruments Inc.)
This availability of resources allows several interesting scenarios, especially for advanced driver-assistance system (ADAS) use cases. First, the free resources can be used for testing L3–L5 AD functions in the background for validating the algorithms and finding integration issues. This facilitates OEMs to gather a lot of test cases/test data from real-world experience without deploying a big field-test car fleet to achieve the required test mileage. Second, the results of the ADAS processing and its driver interactions are compared with the L3–L5 algorithms running in the background. Optionally, this also enables forwarding of the data to the OEM cloud.
And eventually, another nice side benefit for car manufacturers can be after the vehicle sale. Once most L3–L5 field testing is finalized, the surplus compute and memory resources can be used for enhancing features, developed at a later stage, allowing OEMs to create a new additional revenue stream.
A paradigm change in power distribution
Another driver for migration to zone architectures is power distribution in the vehicle. All ECUs in a vehicle are powered by the battery/alternator or battery/DC/DC. In domain architectures, power distribution boxes, comprised of fuses and relays like those shown in Figure 2, distribute this power in a protected way.
Figure 2: A typical power distribution box with fuses and mechanical relays (Source: Texas Instruments Inc.)
Fuses in power distribution boxes have different time-current characteristics (TCC) to support the wide variety of loads in a car. Wire harnesses that carry the currents to the loads are designed to match the fuse TCC. This, along with the fact that the power distribution box is located in an accessible spot in the vehicle, results in wire harnesses with lengths and widths that are not optimal.
As OEMs implement zone architectures, system designers are rethinking power distribution with two considerations: decentralization of power distribution and replacing uses with semiconductor MOSFET-based fuses. Decentralized power distribution implemented in zonal modules results in shorter wire harnesses, while semiconductor-based resettable fuses allow the use of optimized wire gauges. Shorter and thinner wire harnesses lead to a weight reduction, an important factor in improving vehicle drive range.
At first glance, one may conclude that replacing the fuse with semiconductor solutions requires just implementing the relevant TCC. However, we note that additional design challenges—including charging of large capacitors during power-up, low-Iq operation during ignition off state and safe operation during MOSFET failure—need to be solved when implementing MOSFET-based solutions.
To diagnose and to control the resettable fuses, real-time software is executed in the zone controller. For potential updates and future upgrades of the zone and central computer software, FOTA support is essential.
Zone modules: decoupling software from hardware
After decentralization of power distribution and implementation of FOTA, the next natural step will be to rework the sensor and actuator side. The zone E/E architecture will significantly affect sensing and actuation functions. In domain architectures, dedicated ECUs that are typically in proximity to the sensors or actuators perform distinct functions. Each ECU requires battery power, a communication interface and signal lines for actuators and sensors, which increases harness complexity, weight, cost and architectural scaling.
The introduction of zonal modules can greatly reduce harness complexity by grouping the logical input/output (I/O) functions of multiple ECUs into the zonal module in proximity and by maintaining sensor and actuator locations. This results in a separation of physical and logical I/O functionality, as shown in Figure 3, which simplifies the implementation of a FOTA concept. Moreover, the introduction of a service-oriented architecture (SOA), which relies on predefined self-contained software units, decouples software from hardware. This is key for extending hardware lifetime while updating software more frequently.
Figure 3: Separation of logical and physical I/O functionality from a domain architecture (left) to a zone architecture (right) (Source: Texas Instruments Inc.)
Advanced microcontrollers (MCUs) are needed to inherit the different logical I/O functions from various ECUs in a single zonal module and to provide a service-oriented interface to the central computer. A zonal MCU shall have sufficient real-time performance with support of mixed criticality and high-speed interfaces toward the backbone. Moreover, large internal and external memories for program and data storage, as well as a rich set of low-end communication peripherals for interfacing with actuators and sensors, are characteristics for this class of MCUs.
The separation of logical and physical I/O functions reveals new optimization potential on the sensors and actuators side. Smart ICs for sensor signal conditioning or driving actuators will be equipped with local intelligence to autonomously perform the necessary physical I/O functions. In addition, they run background diagnostics and communicate with the zone MCU, which requires the integration of a protocol handler like a local interconnect network responder. These smart ICs will support a cost- and size-optimized solution that could be implemented in cramped space like sensor or actuator housings. Simple sensors or actuators will be directly controlled from the zonal module via dedicated signal lines.
On the other side, composite actuators like a seat control module or complex sensors like a radar sensor will maintain the classic approach of a small ECU. Development engineers may choose one of the aforementioned solutions depending on various criteria, such as the number of control and sense signals, sensor and actuator complexity and mounting constraints.
The enormous potential of zone architectures
As previously outlined, the key drivers of a zone-based architecture are:
- FOTA update capability that allows update and upgrade of the software in the field
- Decentralization of power distribution, which optimizes the harness
- SOA that enables decoupling of software from hardware
These are the first evolutionary steps toward a fully software-defined vehicle. The change of vehicle architectures to zone architectures will enable more natural next steps, including integration of audio and video systems, ADAS sensors and powertrain and chassis functions.
Audio and video
Over time, zone modules will also add more and more audio and video features over Ethernet. Many current infotainment architectures already use well-proven audio-video bridging, for which time synchronization is important. But existing domain-architecture–oriented networks are agnostic to many concurrency problems; thus, new time-sensitive networking (TSN) features gain importance. This refers especially to audio use cases, in which latency targets are demanding. This latency requirement, typically in milliseconds, is less strict than powertrain and chassis control, which typically requires latency to be in microseconds.
When routing massive amounts of other data traffic (e.g., ADAS) through the same network, the audio latency must be kept sufficiently low and packets cannot be dropped. That’s why arbitration and fine-tuning of the existing TSN knobs is important. For example, time-aware shaping guarantees the transfer of lower-bandwidth traffic after a predefined time window, independent of other heavy traffic on the network.
ADAS sensors
The zone architecture with high bandwidth communication links between zone ECUs and the central computer provides a future-proof backbone to route lower-level sensor data to the ADAS/AD SoCs. This builds the foundation for a scalable and upgradable platform ranging from assistance functions to highly automated driving features. It fully supports fusion of all sensor modalities at a lower level, leading to more accurate and reliable results necessary for higher automation levels. In addition, lower-level sensor data means a simplification and cost optimization of the sensor elements at the perimeter of the vehicle. The lifetime of leaner sensor elements can be extended, while signal processing software in the central computer can be updated and upgraded over time to improve and add new features.
Powertrain and chassis control
Most of the zone architecture discussions have centered around low-voltage electronics. However, high-voltage powertrain and chassis control systems, which are the backbone real-time control systems of a car, could also take advantage of the new zone architectures. A high-speed communication link, which is low-latency and deterministic, is a must for powertrain and chassis control systems. In addition, because the traction motor may be directly coupled to the wheel without a “clutch” to disconnect it from the vehicle, a communication network with functional safety would be required. Moreover, as more systems are powered directly by the high-voltage battery, a high-voltage zone power network could be established.
Full integration enables the software-defined vehicle
The integration of the aforementioned domains, like in-vehicle infotainment, ADAS/AD, powertrain and chassis control, in the zone architecture will happen gradually over time. Once all domains are integrated, the ultimate goal of a complete separation of all logical software-based functions from physical actuation and sensing functions will be reached. This will enable a fully software-defined vehicle, which means that all key functions of a car will be executed in the central computer by utilizing services provided by the zone modules.
Advertisement
Learn more about Texas Instruments
