## 3 System Model
### Requirements  
The E/E architecture is going through fundamental changes. Driven by software-defined vehicle architecture, the vehicle is evolving into ECUs in which new functions and features are implemented and deployed primarily through software. The adaptation of the vehicle-centralized, zone-oriented E/E architecture takes place as an iterative process, introduced gradually in the vehicle. The E/E architecture transitions from being a decentralized system, connected by a central gateway in which functions are running on dedicated ECUs with software binding to hardware, towards more centralized systems with dedicated domain controllers handling a set of functions related to a specific area or domain before evolving into zonal controllers arranging functions according to their positions in the vehicle [23]. Throughout this transition, significant variation is expected across the various vehicle software. As shown in Figure 4, the software evolution goes in parallel with hardware evolution. The majority of software in decentralized architecture is combined with a function-specific ECU in a single package and fully controlled by OEMs. A typical new-generation vehicle likely has an architecture composed of five or more domains. The functions are abstracted from discrete ECUs and centered in software in fewer hardware modules. Domain-specific functions are optimized for their application and distributed flexibly to any cross-domain vehicle controllers and no longer tied to a particular ECU. High performance computing ECUs and service-based approaches (e.g., service-oriented communication) are essential for the zonal architecture. Software services can be subscribed across application and ECU boundaries. Signal-based real-time-controlled software continues to be used for sensors and control actuators. Due to the disruption in the E/E topology, OEMs cannot change the complete vehicle setup quickly and the transition will take place at different rates depending on OEM strategies. Therefore, legacy classical ECUs will remain part of the vehicle, and a mixed architecture will be implemented in tomorrow's vehicles. An application software entity can be placed either in a central computing controller, a zonal controller, a domain controller, or a persistent specialized ECU (e.g., actuator, sensor). The contents of software within an ECU can differ hugely due to many factors, such as segment (e.g., ADAS, Infotainment, Chassis), powertrain type, level of driving automation (SAE AV level), etc. The software functionalities range from real-time safety systems to interactive apps. The vehicles are expanded with cloud and backend solutions as well as services, enabling the vehicle to access and participate in mobility ecosystems to guarantee high availability and fast delivery of the updates. OEMs and suppliers have an opportunity to grow their business by adding on the fly certain software capabilities, e.g., functional safety, artificial intelligence, security capabilities. Optimization can be implemented globally across all vehicle platforms, as well as locally, limited to a particular vehicle model or market. Small, large, low-end, high-end vehicles are usually equipped with ECUs with different sets of software. Such flexibility and scalability are mainly achieved through software modularity and over-the-air update capabilities. Software modules are deployed based on the vehicle models or markets as well as relevant configurations. While variant handling and configuration options are traditionally performed at the time of vehicle purchasing, they will increase and be activated at a later point in time dependi  
Figure 4: Evolution of the E/E and software architecture from a distributed approach to a hierarchical, software-centric architecture with centralized computers and domain or zone controllers. and paid services.