Requirements-Driven Automotive Electrical/Electronic Architecture: A Survey and Prospective Trends

The automotive E/E architecture has undergone a paradigm shift in the past century. Particularly, the new requirements of automated driving are severely challenging the existing architecture, which has led to ongoing revolutionary innovation in E/E architecture. In this paper, we reviewed the evolution of E/E architecture and outlined the requirements-driven developments. We illustrated the state-of-the-art E/E architecture, including network topology, standards, simulator and software platform. We also discussed the next generation of E/E architecture from the perspective of different OEMs and suppliers. The analysis shows that software-defined, hierarchical, reconfigurable and customized E/E architecture is universally accepted. Furthermore, the automotive industry has been experiencing several transitions related to OEMs and suppliers. With the emergence and maturation of automated driving, we analyzed the new requirements on E/E architecture and proposed prospective development trends.


INDEX TERMS
Driven by the global trends of ''connected, automated, electrified, and shared'', a fundamental change in automotive E/E architecture is currently underway. In the early days, automobiles were dominated by mechanics. Driven by the development of electronic devices and electronic control units (ECUs), the electronic components of automobiles have grown rapidly, which has led to continuously increasing complexity of automotive E/E architecture. In recent decades, the electronic system of cars has developed into a highly complex network with dozens of dispersed ECUs, or even hundreds in luxury automobiles [1]. In the evolution from mechanical devices into mobile servers with complex functions and high interconnection, automobiles have experienced continuous improvements related to power, fuel economy, functional safety and comfort. In this process, the E/E architecture has gradually evolved and undergone a paradigm shift in the last decades. We have summarized our survey of the historical evolution in terms of the automotive E/E architecture, as illustrated in Fig. 1. Details will be presented in the following sections.
The E/E architecture has been recognized as the key foundation for supporting automotive applications and the increasing complexity of automobiles. Generally, the automotive E/E architecture is a network infrastructure, used to interconnect and organize ECUs and mechanical/electronic components. A previous article defined the E/E architecture as the fundamental organization of automotive E/E components, including ECUs, sensors, power systems and wire harnesses, to realize the expected functions, especially the mutuality and interactions among these elements from different perspectives [2]. Given this definition, the E/E architecture is considered from the following three perspectives, the physical topology, i.e., the packaging, placement and wire routing, logical topology with emphasis on the interactivity among these elements, and the guidelines and principles for architecture design.
In a recent survey, Navale et al. presented an overview of the evolution and revolution of automotive E/E architectures [3]. The bottlenecks of current the E/E architecture were discussed, and the future of E/E architecture was envisioned based on new technology trends. Additionally, functionalities, such as automated driving, and their implementation in mainstream automobiles were expounded. Jiang also studied the evolution of automotive E/E architecture from the perspective of the latest technical trends, such as electrification, automated driving, and connectivity [2]. Zeng et al. reviewed the five most widely used in-vehicle protocols, namely, LIN, CAN, FlexRay, Ethernet and MOST, from the perspectives of system cost, transmission capability and fault-tolerance [4]. Huang et al. investigated in-vehicle protocols from both wired and wireless perspectives, then identified the challenges to current solutions [5].
In recent years, automated driving and networked automobiles have been very popular research filed. Although the existing in-vehicle communication network based on CAN and FlexRay was sufficient to meet the requirements of communication bandwidth in the past few years, the increased level of intelligence and automated driving, as well as the escalation of in-vehicle infotainment systems, have made it increasingly difficult for traditional in-vehicle networks to support and effectively handle the growing requirements for high-speed, high-bandwidth communication [6]. On one hand, massive data has driven the emergence of new in-vehicle network architectures. In the early 2010s, Ethernet was gradually recognized as a potential in-vehicle communication protocol [6], [7].The Ethernet's security issues, such as authenticated access and data encryption standards, have also become a concern [8]. On the other hand, data sharing and coordinated control between automotive systems is becoming more common, especially for automated driving, which has promoted the integration of computing units and domains.
These new trends and requirements challenge the existing E/E architecture. Thus, a suitable E/E architecture for new technology trends should be developed. Hence, this paper reviews the development of E/E architecture in the past century from a novel requirement-driven perspective and provides a comprehensive view of the evolution. Focusing on the new changes to the E/E architecture driven by automated driving, recent progress from both academic and industrial VOLUME 9, 2021 perspectives are summarized. Finally, a possible future E/E architecture is proposed. This paper is organized as follows. First, the design method and evaluation of E/E architecture is introduced in Section II. The requirement-driven evolution of E/E architecture is demonstrated in Section III. The changes to E/E architecture driven by automated driving are introduced, and the standards, OEMs, suppliers, IT companies and simulation platforms are discussed in Section IV. On the basis of above analyses, potential future E/E architectures are discussed in Section V. Finally, this paper is concluded in Section VI.

II. THE DESIGN AND EVALUATION OF E/E ARCHITECTURE A. THE DESIGN METHODOLOGY AND PROCEDURE OF E/E ARCHITECTURE
Scientifically, two main stabilization mechanisms exist in the design of E/E architecture, the bottom-up, hardware-oriented approach and top-down, software-oriented approach [9]. The bottom-up approach refers to a design method that is derived from the existing architecture and developed by adding new devices and functions. By contrast, the top-down approach involve the entire top-down design process and starts with the functional requirements analysis [10].
Since the bottom-up design method is based on the existing E/E architecture, the cost and difficulty of the development process are relatively lower. However, this approach is limited by the original framework. This method is also relatively limited when designing large distributed software-intensive systems. The top-down design method is a new design process that follows complete development steps and is typically used when developing new vehicle platforms, so it is costly and time consuming.
For the top-down design process, in the initial stage of the design, it is necessary to define the requirements and decompose the functions. The design of E/E architecture is closely related to its functionality, especially the division and design of domains. Two architectures, i.e., the functional architecture and technical architecture, are often used in modeling E/E systems [9]. The separation of the functional architecture (logical level) from the specific implementation details enables the establishment of a complex functional architecture in the redesign stage without implementation restrictions. Then, according to different functional requirements, functional modules are divided. Stolz et al. proposed that domains should be divided into groups that are as large as possible while maintaining synergies by means of functional and nonfunctional criteria, such as the functional dependency, innovation speed and technology similarity [10].
Moreover, when the functional modules are divided, the corresponding specific design requirements must be determined and how to implement the design at the software and hardware levels must be considered. The hardware layer also involves the physical topology of the in-vehicle network, which is closely related to the weight of the wiring harness, wiring pattern and cost.

B. EVALUATION OF E/E ARCHITECTURE
In the process of designing and selecting an E/E architecture, many trade-offs must be considered, and a reasonable evaluation method should be proposed to establish criteria for the evaluation and decision making. Generally, the indicators of architectural design include many complex factors, such as the physical component package size, layout, energy efficiency, architecture reliability, scalability, reusability, and cost. Many studies have focused on these various trade-off indicators [11]- [14].
Specifically, as a market competitive product, automobiles are largely driven by production costs. Depending on the market segment, the E/E architectures can be quite different. For example, [15] discussed the E/E architecture of Brazilian B entry automobiles. The E/E architecture of South America markets in the 2000s did not contain power window or door locking features, which was entirely different from typical architectures. Vehicles named Celta, Palio and Fox contained only 4 or 5 ECUs, and no network protocol or only low-cost 10.4 kbps was used in these vehicles.
The design of the next-generation E/E architecture will be largely related to automated driving. The function of automated driving, the compatibility of configurations, and the costs will influence and determine the next-generation E/E architecture. Different OEMs may have inconsistent positioning and technical maturity in automated driving systems, which may lead to different solutions in the nextgeneration architecture. However, the complexity of automotive architecture has driven the need for collaboration with OEMs and suppliers. By means of increased cooperation to formulate automotive industry standards, OEMs and suppliers will jointly develop the next-generation automotive E/E architecture [16].

III. THE REQUIREMENTS-DRIVEN EVOLUTION OF E/E ARCHITECTURE
Different from the aforementioned reviews, the evolution of E/E architecture is surveyed from the perspective of requirements in this paper. Requirements have been the essential power motivating the development of automotive industry, and various types of E/E architecture have been designed to satisfy the ever-increasing requirements.
The development of automobiles shows different characteristics in different stages. E/E architecture, as the infrastructure for the connection and organization of automotive electronic components, provides a basic guarantee for the normal operation of automobiles. The contradiction between requirements and the existing circumstances has promoted the technological progress and revolution of E/E architecture. The requirements that drive the evolution of E/E architecture include the following.
• Interconnection of ECUs. • Improvement of automobile performances, such as braking, stability, safety and economy.
• Reduction in the cost and weight in automotive manufacturing.
• High bandwidth and low latency of in-vehicle communication.
• Connectivity with the outside.
• Flexible decoupling of hardware and software. The market requirement has promote industry reform, and the requirement of new technology brought has created a new direction for academic research. Academic progress, in turn, has driven industry progress.

A. POINT-TO-POINT ARCHITECTURE
In 1912, Dayton Electrical Laboratory Company developed the first starter motor, and the advent of the first car with an electric start function marked the beginning of a new era in the history of automotive electrical systems. Furthermore, the first 7V DC generator was developed to charge batteries and provide energy to lighting and ignition systems, and in 1955, the electrical system began to transition to 12/14 V [17].
At the beginning of 1970s, the automotive industry entered an era of electrification. Electronic devices were equipped in automobiles to partially replace mechanical components, such as electronic ignition devices with transistors and diode-rectified alternators [9]. At this point, E/E architecture was almost unknown owing to the extremely small number of electronic devices in automobiles. Moreover, electrical systems, which has gradually replaced mechanical or hydraulic systems, have increased the requirements for electrical energy.
The emergence of integrated circuits (ICs) sparked a landmark revolution in automotive electrical systems. The rapid expansion of ICs, from small-scale applications to very large-scale integration (VLSI) promoted the formation of large-scale automotive networks, and ECUs were gradually applied in automobiles with the applications such as engines and airbags [2].
In this period, these electronic devices substantially improved the automobiles performance. Connections of these devices was point to point and realized the transition from totally isolated to connected systems in a stepwise manner.

B. ARCHITECTURE EQUIPPED WITH VEHICLE BUS
Since the 1980s, the electronic progression of automobiles has gradually accelerated, and requirements for automotive safety, emissions and energy saving have become increasingly stringent. Within a few years, considerable electronic control systems, such as electronic fuel injection, ignition and emission system, anti-lock braking, airbag system, anti-collision system, GPS navigation and fault diagnosis, were applied. The emerging electronic technology has almost replaced the original electro-hydraulic control system. Furthermore, the microprocessor has been widely used in automobiles to achieve these specific functional requirements, and the control systems of the vehicles have become more comprehensive, which has improved the control precision and performance.
However, complexity of the automotive control system and wiring harness increase exponentially with the pointto-point connection. The wiring harness was too large and complicated to ensure the maintainability and reliability with the former wiring method. To simplify the wiring harness and improve communication efficiency, field bus were adopted. The number of communication lines around the vehicle can be effectively reduced by adopting the field bus as communication system. The signal transmission between all ECUs can be completed through a few buses, and precise control of vehicle performance can be realized via communication and coordinated control.
Manufacturers developed their own bus technologies initially, but the inconsistency made assembly and packaging difficult. The standardization and modularization of the data bus system made the design and reconstruction of automotive networks easier. BOSCH GmbH introduced the first fieldbus, the controller area network (CAN-bus), in 1983 [18], which was standardized in the beginning of the 1990s and has been widely used since then [19].
Subsequently, various kinds of field buses, such as the local interconnection network (LIN), media-oriented system transport (MOST) and FlexRay, were developed and applied in vehicles to satisfy different communication requirements in different vehicle domains. From 20 kbps to 20 Mbps, the vehicle bus makes the E/E architecture more cost effective, and standardization of the vehicle bus has ensured interoperability and consistency and promoted the assembly and mass production of vehicles.

C. ARCHITECTURE EQUIPPED WITH CENTRALIZED GATEWAY
To make full use of the respective advantages and constitute a low-cost and fully functional automotive network to improve automobiles performance, different field buses for different control systems and gateway-connected solutions are generally accepted.
Consequently, designing an appropriate E/E architecture has gradually become critical [20]. E/E architectures with a centralized gateway connected to different subnetworks were commonly applied until relatively recently. This kind of architecture is adopted by many manufacturers for various automobiles, such as the Volkswagen Passat [4], BMW 7 series [21] and Audi [22].
In terms of the power system, the load is connected directly to the battery using a switch or an electromechanical relay. This structure has led to complex and bulky wiring harnesses, and the addition of new electronic components further entails higher wiring complexity, longer and heavier cables, and higher costs.
With the increased implementation of high-power applications, such as electric heating and electric pumps, the requirement for electricity has continued to increase. The traditional 12 V power can hardly provide sufficient power for such applications. Thus, in the 2000s, 48 VDC-36 VDC high-voltage electrical systems were widely discussed [23], [24]. The dual-voltage power supply network became a general architecture to smoothly transition to high-voltage networks. Since the early 1990s, international associations, such as MIT and SAE, had been promoting regular meetings with car manufacturers. They believed that the establishment of a 42 V DC voltage bus was the future standard for the automotive industry [17].
At the same time, the junction boxes in the power distribution system were replaced by intelligent power distribution units (PDUs). Compared to the junction box, the PDU adds intelligent functions, such as fault diagnosis and power management. Additionally, PDU modularizes the E/E system to reduce the complexity of the wiring harness [24].
Decentralization of power distribution gradually became popular. Compared to centralized distribution, decentralization reduces the wiring harness, thereby improving the weight of the system. Practical applications in Europe's popular cars verified these improvements in circuit quantity, length, weight, and cost [23]. The optimal number, location, and content of distribution boxes also needed to be determined, and several arrangements of distribution boxes are discussed in [25].
In terms of reducing the complexity of power network, several initiatives have been applied, for example, replacing traditional fuses with maintenance-free solid state fuses that can be placed in key locations instead of easily accessible locations, thereby reducing the complexity of the power supply network [3].
The central gateway architecture improves the security of the automotive bus system. Moreover, the gateway converts different protocols and regulates network traffic. The increase in electronic devices and the power requirement made the power supply system more important, and the application of high-voltage systems and PDUs has improved the efficiency of power supplies and reduced the complexity of power distribution systems.

D. DOMAIN-BASED ARCHITECTURE
ECUs typically support only one specific application, such as electronic power steering. Only a few components are cooperative, such as the combination of brakes and airbag ECUs. In addition, the sensor data and algorithms are processed locally in each dedicated ECU [26].
With the ever-increasing number of automated driving functions, the traditional method of adding a new ECU for each new function will increase the complexity of the E/E architecture. Excessive distribution leads to complex wiring, poor networking performance and a reduction in the communication speed of critical information. In the previous central gateway-based architecture, all components and sensors are connected with the gateway. Both intradomain and crossdomain communication pass through the gateway, which leads to a high load of the gateway, especially when the requirements of bandwidth and latency increase [30]. Furthermore, breakdown of the centralized gateway can easily lead to collapse of the entire network [4].
Considering the bottleneck problems of ECUs and information security, domain control units (DCUs), such as Bosch, Continental and Delphi, were proposed by Tire1 [28]. The application of a domain controller relieved some of the stress on the system. However, due to the increased complexity and cost, domain-controlled architecture and an Ethernet backbone are critical for future E/E architecture development.
The domains provide appropriate isolation of the ECU based on similar functions and communication access. Each domain integrates a portion of the ECUs that communicate in the bus system. In addition, the gateway interconnects different networks and coordinates ECUs in different domains to communicate [16]. In general, DCUs contain OEMs' specific software components [29], and DCUs reduce the material costs and weight in automotive manufacturing [30].
Currently, domain-based E/E architecture is applied in most newly unveiled cars. OEMs had different but similar classification criteria of automotive domains based on the specific functions, and E/E architectures are commonly divided into body, powertrain, chassis, infotainment, ADAS and telematics domains [31], [32]. In addition, the ADAS domain gradually developed and became one of the fastest growing areas. ADAS DCUs usually require powerful computing processors that are supplied by various solution providers, including NVIDIA, Infineon, Renesas, TI, NXP and Mobileye [28].
Domain-based architecture is an inevitable consequence of excessive decentralization. The application of a domain controller effectively improved the gateway load and ECU bottleneck problems. An important driver of this architecture is the automotive Ethernet and switches. However, when local processing is not performed, additional delays that may be introduced between the sensor and the actuator must be considered. Therefore, a guaranteed determined delay may be required for automobiles [26].

E. ZONE-BASED ARCHITECTURE
To reduce the wiring cost and weight, Brunner proposed the zone-based architecture, where in addition to functional domain clusters, components can be integrated based on their physical location in the vehicle [27]. In this way, the components around the vehicle are no longer classified by function, and automotive software and hardware platforms must be reconsidered. Reducing engineering time and cost by reusing components and smooth integration is important.
The architecture is also beneficial for power supply. The area controller can provide both communication and power supply for corresponding peripheral components [27]. At present, different networks are applied for communication and power supply; however, the introduction of Ethernet can combine these networks and reduce cables and costs, providing greater flexibility in the network layout.
Power over Ethernet (PoE) is a technology that provides power while an Ethernet cable transmits data signals. After the first PoE standard IEEE 802.3af (15.4 W) [33] was proposed in 2003, PoE + (IEEE 802.3at) [34], which supports higher power (25.5 W), was proposed. However, PoE is not entirely suitable for the application of automotive Ethernet. Conventional PoE is designed for 4-pair cable Ethernet, and the automotive Ethernet physical layer protocol BoardR-Reach uses one pair of un-shielded twisted-pair cables. Therefore, PoE cannot be used directly on the vehicle Ethernet. The IEEE has developed a new power supply standard called power over data lines (PoDL) for automotive and industrial applications, as defined in IEEE 802.3bu [35].
The zone-based architecture is greatly beneficial in reducing cabling, especially for Ethernet, with the combination of communication and power. However, the architecture entails higher requirements for software platforms owing to the location clustering.

IV. STATE-OF-THE-ART E/E ARCHITECTURE
Automated driving was divided into 6 levels by SAE. Different levels correspond to different degrees of vehicle automation. The functions of human drivers are gradually taken over by the automotive system, and systems therefore need more sensing capabilities and greater decision-making intelligence. In the process of continuously improving of autonomous intelligence, the improvement in perception and decisionmaking capabilities requires the support of the underlying architecture. The vehicle requires large-bandwidth, lowlatency, scalable and flexible E/E architecture.
In this way, the existing bottlenecks of automotive E/E architecture can be summarized as follows: 1) Bandwidth bottleneck: The sudden increase in data volume caused by the increase in sensors has limited the bandwidth of traditional in-vehicle networks. 2) Wiring complexity: The wiring complexity and wiring harness weight brought by the increase of nodes have a negative impact on vehicle maintenance, weight reduction, power performance and economy. 3) Low deterministic latency: Intra-domain and crossdomain communications increase, and existing bus technologies are difficult to meet the requirements of low deterministic latency in the case of high concurrency and high traffic. 4) Flexible architecture and scalability: It is difficult to achieve online upgrade and maintenance of vehicle equipment, scalability, and dynamic network configuration requirements.
In order to solve the above bottlenecks, standardization organization, the automotive industry including OEMs and suppliers,and academia are committed to developing and innovating E/E platforms,as shown in Fig.2, which will be illustrated below.

A. IN-VEHICLE COMMUNICATION STANDARDS 1) VEHICLE BUS
Since the 1990s, in-vehicle network has gradually matured and become widely used. Vehicle manufacturers first developed their own bus technology, but the inconsistencies between products made it difficult to assemble and debug vehicles. Therefore, the standardization and modularization of data bus systems are gradually being motivated to better promote the design and construction of automotive networks. There are many different standards for in-vehicle networks.
According to the transmission speed of different communication protocols, SAE divides the in-vehicle network bus into classes A-D. Each type contains various protocols. Some are still widely used, and some have been gradually phased out [36].
Class A contains UART, Sinebus, LIN, etc. Among these protocols, LIN is widely used in automobile body control, such as the door, lighting and other occasions with low realtime requirements. Low-speed CAN, SAE J1580, etc. can be summarized as class B protocols. High-speed CAN, SAE 1939 (based on CAN2.0), FlexRay, ByteFlight, etc. can be classified as Class C. Class C is mainly used in automotive real-time control systems, such as engine and chassis control, VOLUME 9, 2021 safety control and other systems. And the protocol MOST is summarized as Class D and used in automotive multimedia applications.
With the development of automotive electronics, new requirements for deterministic, real-time, and fault-tolerant have been proposed for traditional in-vehicle networks. In order to meet these needs, different from the eventtriggered mode, the concept of time-triggered networks was proposed to improve the performance of in-vehicle networks, such as TTP(Time Triggered Protocol) [37], TTCAN [38], FlexRay, and TTEthernet(Time Triggered Ethernet) [39].

2) TIME TRIGGLED ETHERNET
Considerable data caused by the development of intelligent driving are beyond the in-vehicle networks nowadays. Therefore, the network with higher bandwidth, lower latency and higher security, such as automotive Ethernet, is gradually gaining people's attention. Ethernet shows ob?vious advantages in terms of bandwidth requirements, openness, scalability, physical layer transmission costs, technology maturity and standardization [40]. At the same time, high-bandwidth Ethernet links can support software-driven architecture and centralized processing, while greatly reducing the need for the number of bus types.Ethernet was firstly deployed in the diagnostic system [41]. Afterwards the increasing requirement of bandwidth in vehicles made the Ethernet-based network architecture popular for OEMs, such as GM, BMW, and Mercedes-Benz.
The OPEN SIG Alliance [42] that aims to establish BroadR-Reach as a standard for the physical layer of automotive Ethernet is developing and standardizing BroadR-Reach technology, such as 100BASE-T1, 1000BASE-T1. UTP Ethernet consists of a single pair of twisted-pair copper wires, which is small, flexible, lightweight, and cheap to manufacture. The IEEE 802.3 Ethernet working group has set up many standards groups on the physical layer of automotive Ethernet, such as IEEE 802.3 Greater than 10 Gb/s Automotive Ethernet Electrical PHYs Study Group [43].
Although Ethernet has been widely adopted, traditional Ethernet fundamentally lacks the deterministic quality of service (QoS) characteristics of end-to-end flow. Its uncertain delay and low reliability cannot meet the requirements of automotive control networks [44]. This is the major challenge for Ethernet to become an automotive communication standard. The main limitations of Ethernet's lack of support for deterministic low-latency applications are reflected in the following aspects: synchronization, management mechanisms, policy enforcement mechanisms and flow control mechanisms [45].
To this end, Tier1 companies such as Bosch, NXP, Cisco and TTTech are gradually introducing automotive Ethernet related solutions and hardware. The real-time Ethernet standards such as Audio / Video Bridging (AVB), Time Triggled Ethernet(TTEthernet) and Time-Sensitive Networking (TSN) have been proposed to solve these problems in Ethernet technology and provide different levels of endto-end bounded delay guarantees for different priority data in vehicles. In addition, organizations like AVnu Alliance [46] and OPEN Alliance [42] are gradually forming and participating in automotive Ethernet standardization projects to promote the use of automotive Ethernet.
TTEthernet, an extension of normal Ethernet, is a scalable and open real-time Ethernet platform. It was proposed by TTTech and mainly used in security Related applications in transportation and industrial automation. TTEthernet allows the time triggered traffic to coexist with low-priority standard event-triggered Ethernet traffic. Kopetz et al. [47] regarded TTEthernet as the combination of standard Ethernet and TTP/C. Three traffic classes consisting of time-triggered(TT), rate-constrained(RC) and besteffort(BE) traffic are included [127]. TT traffic is transmitted according to a TT schedule table. And time synchronization is necessary so that nodes can rely on schedules to complete the sending and receiving of time-triggered traffic, ensuring that time-triggered services can conflict-free transmit over the network. The current mainstream time synchronization methods include IEEE 1588 [49] and SAE AS6802 [50].
Steinbach et al. proved that TTE can provide comparable the latency and jitter as low as FlexRay while achieving much higher communication bandwidth than FlexRay [51].The time scheduling algorithm is the focus of TTE design. Due to the complex network topology, chaotic application requirements, and numerous hardware constraints in the actual control system, its complexity is determined by the network topology, traffic characteristic and related constraints such as hardware and application-oriented constraints [52], [53].Many scheduling mechanisms are proposed [53]- [56]. Steiner [53] introduced a kind of SMT solver. Firstly, the messages that need to be scheduled, the network topology, and the constraints is abstracted as the input of the SMT solver. Then the solver calculates whether the resource can be allocated in the corresponding physical network and then generate the corresponding configuration arrangement.

3) TIME-SENSITIVE NETWORKING
In addition, the IEEE 802.1 work group has developed the Audio / Video Bridging (AVB) standards to address some of the key issues in Ethernet technology. AVB is listed by the academic and industrial circles as another automotive Ethernet service assurance technology, originally developed for automobiles audio, video, and multimedia systems. Ethernet AVB is a collection of different standards. The Ethernet AVB protocol set includes IEEE 802.1 As (precise clock synchronization protocol) [57], 802.1 Qav (queue and forwarding rule protocol) [58], 802.1 Qat (flow reservation protocol) [59],and 802.1 BA [60]. Based on traditional Ethernet networks, it provides high quality of service (QoS) through accurate clock synchronization, guaranteed bandwidth, and limited delay. It supports various audio-based, Network multimedia applications for video.
The IEEE's AVB working group was renamed the Time-Sensitive Networking Task Group in 2012. TSN evolved from AVB, also known as the second-generation AVB. Based on the revision of the original standard, it has more comprehensively expanded and improved the original AVB protocol set. The IEEE 802.1 TSN TG standard and protocol extends the traditional Ethernet data link layer standard to ensure data transmission with limited latency, low latency jitter, and extremely low packet loss, making it ideal for industrial control and automotive applications. Its application range extends from the original audio and video bridging network to various fields of high stability requirements such as industrial automation and automated driving. Through the combination of these protocol standards, TSN can complete the scheduling management of the network and provide excellent results. Table2 lists the main sets of existing TSN protocols and their functions by category. TSN protocols can be divided into four types which respectively focus on flow Synchronization [57], flow management [59], [61]- [63], flow control [58], [64]- [68] and flow reliability [69]- [71].
In the past few years, many timing analysis methods for Ethernet have been studied. For example, IEEE802.1Q [72] analyzes the end-to-end delay of standard full-duplex switched Ethernet, and [73] proposes a real-time calculation timing analysis technique and analyzes the Ethernet based on the automotive E/E architecture AVB. [74] proposed the worst-case analysis using strict priority and credit-based shaping algorithms in Ethernet AVB, and evaluated in a typical centralized topology use case in industrial automation. [75]- [77] proposed a network calculus-based analysis method for deterministic and delay range analysis of TT flow in TTEthernet.
Many researches have analyzed and compared these different protocols using traffic shaping methods. For example, Boiger [78]compared BLS and PS shapers, and Meyer et al. [79] proposed a network scenario to analyze the effect of TAS on AVB's Class A traffic. The author proposed a theoretical analysis of the maximum end-to-end latency of AVB Class A traffic and compares it with simulation results.Then, Thangamuthu et al. [80] made a detailed comparison of standard TSN traffic shaping methods. The article compared BLS, TAS, and PS shapers in detail and analyzed the worst-case end-to-end delay of AVB traffic and control traffic in small car network scenarios. Simulation shows that for a typical 100 Mbps Ethernet network, most applications meet vehicle-mounted latency requirements except for applications with strict latency requirements. However, the analysis in [80] has the limitation that does not consider the competition between the frames with the same priority. In this regard, based on considering this limitation, Thiele's Different shapers of the topology such as TAS, PS [81], BLS [82] performed formal timing analysis and worst-case delay analysis to evaluate whether these shapers can meet the stringent requirements of automotive networks for deterministic low latency.
In addition to the shapers described above, other traffic control mechanisms including asynchronous traffic scheduling algorithm such as UBS [83] and ATS [84], [85], preshaping [86] and frame preemption [87], [88], [132] are analyzed, focusing on the worst-case performance such as end-to-end delay and jitter of critical traffic.

4) DISCUSSION
We concluded the communication protocols discussed above in table 3. Especially, considering about the application prospects of Ethernet, TTEthernet and TSN are discussed. Alderisi et al. [90] compared the performance of TTEthernet and AVB in ADAS, and the results show that both meet the vehicle requirements. But TTEthernet p erforms better on deterministic transmission due to the time trigger mechanism of TT stream, While due to the reservation mechanism AVB is more flexible in network configuration under changing bandwidth requirements. Compared with TTEthernet, TSN also provides a bandwidth reservation mechanism through 802.1Qat and 802.1Qcc. AS for flow control, the TT flow in TTEthernet is transmitted according to the TT schedule. In TSN, many shapers such as CBS, TAS, BLS, PS, and ATS are used to ensure the real-time requirements and the problem that low priority traffic is always blocked by high priority. TSN allows frame preemption for high priority traffic. Among these shapers, similar to the TT flow in TTEthernet, TAS uses a gate list to ensure that a specified set of traffic can access the network within a certain time interval. However, the scheduling configuration in TTEthernet is to provide a fixed sending time of TT frames for each node. TAS uses a gate list to indicate the behavior of the corresponding queue, and the configuration is more flexible. In terms of redundancy, IEEE 802.1 Qca and 802.1CB protocols have been used in TSN to achieve redundancy. The above points reflect the advantages of TSN [91].

B. AUTOSAR
Automotive software is critical to develop consistent, reliable, and high-quality electronic controls and interfaces. Software is considered as a key strategic element that needs to be easily added with new features and software should be upgradable and maintainable [15]. Car-grade standards and requirements are needed in automotive industries.
The automobiles needs to integrate components developed by various suppliers. The specifications of these components are defined by OEMs. But the actual construction of the components is done by the supplier. These components usually come with their own electronic control unit (ECU) and software stack. These separate software stacks constitute a large amount of software in modern automobiles [92]. The complexity of E/E architecture is one of the challenges in automotive industry.
All parties involved in the software and hardware design of automobiles need to be tightly coupled. The overall design process is hindered not only by heterogeneous development systems, but also by the various modeling and specification languages of development tools used by different OEMs, Tier1, and Tier2. Reusability, testability, and security are needed to be addressed in the above systems [93]. Basic software, interface applications and data buses must be standardized [94].
Therefore, the increasingly complex automotive E/E architecture, the scalability and transferability of automotive production, the flexibility of product updates, and the reliability of E/E architecture, need to be improved [95]. Leading automotive manufacturers and suppliers have introduced AUTOSAR (Automotive Open System Architecture), which improves the complexity through reusable software components and possibly standard hardware components [96], [97]. These years more and more companies in the industry have joined the AUTOSAR alliance, including OEM (automotive manufacturers), Tier1 (auto parts suppliers), chip manufacturers. AUTOSAR has also become the future of automotive E/E design.
AUTOSAR Alliance aims to establish a standardized software architecture for automobiles. The goal of AUTOSAR is to increase the reuse of software components, especially between different automobile platforms, and between OEMs and suppliers. AUTOSAR enhances the transferability of system functions throughout the automotive industry, maintainability of the entire life cycle, including the integration of functional modules from different vendors, and software updates [92].
The AUTOSAR standard contains a set of specifications that describe software architecture components. These standard rules and interfaces are managed by standard description files established by the AUTOSAR Alliance throughout continuous modification and update. The AUTOSAR standard defines an architecture that separates application software from infrastructure-related basic software. It distinguishes three main software layers running on a microcontroller: application software, runtime environment (RTE), and basic software (BSW). The use of AUTOSAR allows the ECU functionality to be abstracted into the middleware layer. Using a common middleware framework means that applications can be developed once and deployed multiple times, saving development time and reducing complexity [92].
Simultaneously, the development of vehicle domain controllers is also supported and promoted by the standardization of the software architecture. The separation of software and electronic hardware is achieved through standardization of basic software and software interfaces [10]. In the process of migrating from the initial software to AUTOSAR, automotive OEMs gradually introduced AUTOSAR-compatible software components into the overall architecture [95], such as migrating from OSEK/VDX to AUTOSAR. OSEK/VDX was originally a joint project of the German automotive industry, which aimed at developing an open architecture of distributed systems in vehicles [98]. Many studies have focused on the migration process of AUTOSAR systems [92], AUTOSAR modeling and development methods [99]- [102], the challenges and problems faced by AUTOSAR [103]- [105].
The trend of autonomous driving also puts forward new requirements for the next-generation software platform including flexible and dynamic deployment of software applications, support of high-computing hardware, security, determinism, and real-time performance. These new requirements challenges the AUTOSAR platform [106]. As a global standardization alliance, in addition to the traditional classic software platform, AUTOSAR is also developing a second software platform-the AUTOSAR Adaptive Platform to adapt the tendency of autonomous driving [107].

C. INDUSTRIAL SOCIETY 1) OEMs
There is no universal standard E/E architecture among OEMs. But most of them are similar. The trend of high-performance computing architecture is the consensus. Increasing computing power will gradually lead to a central EE architecture. Intelligent vehicle architecture with high-performance central computing unit will replace the outdated distributed computing architecture.
Tesla has been working to reduce the wiring length of vehicles. The wiring of Model S is about 3 kilometers, and Model 3 has been shortened to 1.5 kilometers. However, Tesla is still developing a new wiring architecture for future vehicle platforms, hoping to reduce the Model Y to 100 meters [108]. Manual wiring makes the assembly a labor-intensive process in the automobile production. Tesla hopes to use robots to more easily manipulate the wiring harness system, thereby reducing costs. But more details of the Tesla's E/E architecture have not been disclosed.
GM has released a new generation of E/E architecture, mounted on newly-unveiled Cadillac CT5. The architecture is 5 times faster than the current speed with OTA function. The new architecture is equipped with 100 Mbps, 1 Gbps and 10 Gbps Ethernet. At the same time, it focuses on safety performance by benchmarking the architecture as an aviation system [109].
BMW introduced a layered software architecture. Top of the architecture is a central computing platform. The next level is the integrated control unit which integrated specific control functions. The next is the commodity control unit which is standard parts without specific OEM functions. The bottom of architecture is the sensor and actuator. BMW hopes VOLUME 9, 2021 that all central computers have a unified software platform, which improves the reuse and reduces development and verification workload [110].
In Toyota's vision for next-generation architecture, a central and zone-based architecture is expected and recognized as ultimate goal of Physical E/E Architecture [111]. In this way, minimized wire, flexibility of new ECUs and additional software can be guaranteed. To ensure security, Toyota listed three key factors including isolation, OTA and individuality [112].

2) SUPPLIERS
With the development of ee architecture, the relationship between OEM and Tier1 is sustainably changing. The integration of ECUs has weakened the role of original ECU electronics suppliers, while DCU suppliers become increasingly important. At the same time, Tier1 also gradually cooperates with OEMs by providing hardware, middleware and system platforms. Meanwhile, OEMs are responsible for developing software systems related to autonomous driving [28]. Thus, many Tire1 companies are actively exploring the promising future E/E architectures. Under the trend of autonomous driving, they will seize the OEM market with technological maturity and foresight.
Tier1 suppliers choose to cooperate with chip suppliers for solution design and development of central domain controller, such as Continental ADCU (The Assisted & Automated Driving Control Unit) which is the safe & secure multipurpose processing platform [113]. Nvidia launches a scalable open autonomous driving computing platform NVIDIA DRIVE AGX [118]. And NXP developed the next generation S32x automotive processing platform [114]. The platform aims to maximizes hardware and software reuse across products and applications and enables over-the-air updates.
In the anticipation of NXP, 3+1 Compute elements of E/E architectures are proposed. 3 means sensor and actuator, domain and centralized computing, and 1 means cloud. The E/E architecture is motivated to domain-based architecture, which is composed of Body and comfort, powertrain and chassis, infotainment domain and high performance ADAS computer, with the gateway processor and Ethernet switch [114]. At the same time, Ethernet(Gbps) will be applied in backbone with CAN, FlexRay or 100Base-T1 used intra domains.
Aptiv proposed a smart automobile architecture, which is mainly composed of the brain, the nervous system and cloud. The brain is mainly composed of three supercomputers, including an autopilot supercomputer, a central location sensor super-computer, and a network-side security supercomputer [115].
The redundant design of Aptiv's intelligent vehicle architecture is extraordinary. Computer, the network or signal, and then the power, the redundant setting of these three elements makes the automotive safety and reliability fully guaranteed. Accidents can be avoided when the computer, network or energy fails [116].
Bosch listed the evolution of E/E architecture and envisages a centralized E/E architecture in the future [3]. With the increasing of software, the fusion of DCUs motivated the application of zone-based ECUs and vehicle computer. And then some functions in vehicle computer will be transferred into cloud computing.
Similarly, Continental put forward a centralized architecture. The core concept of this architecture is the centralized processing and ''all-to-some'' communication [117], which is driven by software.
Both OEMs and suppliers are looking for the possibility of the next-generation E/E architecture for more market share. In general, their road-maps are similar but some are more aggressive such as Tesla. To some extent, this is related to the different approaches they took in the design of the E/E architecture. However, the trend of software and hardware decoupling is consensus, and the role of software will become more and more important.

D. SIMULATION PLATFORMS
Before the mass production of automobiles equipped with a new E/E architecture, the E/E architecture needs to be simulated for analysis and verification. Modification and iteratively updates are essential. Many studies have used simulation tools to model and analyze the performance of E/E architectures and in-vehicle networks. The main simulation analysis platforms contain the E/E architecture design platform Preevision [119], automotive bus development and analysis tools CANoe [120]. In addition, timing requirements are the basis of automotive real-time embedded systems. Other timing analysis tools are also used to analyze the timing of automotive embedded systems, such as OTAWA, TuBound, Chronos, RapiTime, Cheddar, MAST, SymTA/S and RapidRMA. These softwares are described in detail in [121]. Besides, discrete event simulator OMNeT ++, NS3, etc. are commonly used in network simulation.
Preevision focuses on E/E architecture design, while Symtavision and OMNeT ++ focus on simulation and verification. Preevision is a mature model-based tool for developing E/E systems including requirements design, software, communication design and harness development. Many researches have carried out development work from architecture design to wiring layout based on Preevision [122].
Many researches on in-vehicle networks are based on OmNeT++ including CAN, FlexRay and especially Ethernet. In OMNeT++, some mature frameworks is available such as FiCo4OMNeT for CAN and FlexRay [123] and open-source model library INET. Lots of researches on TSN are being done on OMNeT++. For example, Steinbach et al. [124] developed CORE4INET framework which is still updating. Häckel et al. [125] modeled a SDN-based networking architecture.
In addition, many researchers have developed their own simulation models based on the OMNeT ++ platform with different model establishment and protocol implementation. Alderisi et al. [90] Used OMNeT ++ to evaluate the performance of AVB and TTE two technologies in automobiles ADAS and multimedia systems; Heise et al. [126] implements all non-time-based features in TSN based on the OMNeT ++ simulation framework for avionics networks including flow authentication, flow filtering and flow supervision, frame preemption. And an open source simulation framework was provided. Steinbach et al. [127] compared the simulation prototype of the Volkswagen Golf 7 with a complete heterogeneous in-vehicle network design. And the paper compared the results of traditional central gateway based network with real-time Ethernet backbone network. The results show that real-time Ethernet solutions can provide better end-to-end delay and jitter, while providing significant bandwidth reserves.
Jiang et al [128] developed a TSN simulation model based on OMNET++ and implemented 802.1Qbv, 802.1AS on the basis of an open source framework. Jiang introduced how to perform network scheduling calculations and how to derive gate control list, which was verified through simulation. Similarly, Falk et al. [129] proposed a simulation model NeSTiNg (Network Simulator for Time-Sensitive Networking) to analyze the performance of a converged IEEE 802.1 TSN network. It is a TSN specific extension to the popular OMNeT ++ / INET framework for networks simulation, especially the time-triggered scheduling mechanism of IEEE Std 802.1Qbv, also includes frame preemption of IEEE 802.1Qbu and IEEE 802.3br.

V. PROSPECTIVE TRENDS FOR E/E ARCHITECTURE
The automobile in the future could be described as ''computers-on-wheels'' and the innovation of E/E architecture is inevitable. The E/E architecture will gradually evolve into a ''communication-control-computation'' platform.
Several key trends will lead the innovation of automotive E/E architecture, and technological breakthroughs make transformations possible. Some future possibilities and potentials will be discussed. Fig.3 shows the aspects including overall architecture, in-vehicle communication, power supply, and software platform, which will be continually improved in the coming decades. With the development of automated driving, more and more electron devices, such as ECUs, sensors, and actuators will be equipped on the automobiles. It is predicted that there will be more than 4,000 electronic nodes in a L5 level automated driving automobile. Therefore, strong computing and communication capability are essential. In addition, to simply wiring harness system, power and data should be transferred mixed.

A. ARCHITECTURE
At present and several years in the future, plenty of automotive E/E architectures will still be domain-based architectures. It is partly dependent on the current level of intelligent driving and limited by the existing E/E manufacturing platforms. At the same time, some aggressive companies chose the zone-based architecture, which is likely to be the direction of automotive industry in the next ten years. During the period, the increase in computing power will also make it possible for the central computing platform. Automobiles are going to be more like a moving server. The maturity of cloud will also promote the virtualization of the architecture. Considering the huge amount of data and the interaction delay, proper edge comuputing may be considered in the future. The architecture that combines centralization and distributed computing improves the flexibility of ECU virtualization owing to its edge processing capabilities. At the same time, the architecture does not rely solely on the central processing, which improve the security of automobiles.

B. IN-VEHICLE COMMUNICATION
With the development of intelligent driving, more sensors will be equipped on the automobile in order to satisfy the functional requirements of automated driving, such as camera, LiDAR, ultrasonic sensor, IMU(inertial measurement unit) and so on. Data fusion makes the perception of the environment more comprehensive and reliable. However, it also means greater bandwidth requirements, higher reliability and deterministic low latency, which is the basic guarantee for upper-layer computing. Taking the camera for an example, many cameras are used for object detection, recognition and classification, such as surround-view cameras, front-view cameras, and in-car cameras. For example, a 1080p 60fps camera probably requires 3Gbps bandwidth theoretically. And a 4K 60fps HD camera probably requires more than 10Gbps. Ethernet-based in-vehicle network is an inevitable trend in the future.
And considering about the safety criticality of calculation and decision-making and the uncertainty caused by insufficient computing power, low deterministic delay in communication is very important. Therefore, under the trend of more complex in-vehicle traffic, how to schedule and control traffic so that the delay and jitter of critical and non-critical traffic are acceptable will gradually become the focus. At the same time, frequent changes in network topology or traffic patterns make the static configuration methods no longer adapted. And automobiles probably need to dynamically change the in-vehicle network in the future. New communication sensors, new ECUs or software applications may be added to vehicles [130]. In this case, softwaredefined networking (SDN) approaches have been proved to be effective [130]- [135]. It can ensure the quality of service even in changing topologies by implementing monitoring, analysis, planning and execution. Applying the SDN to in-vehicle network is becoming a promising research.

C. POWER SUPPLY
The wiring harness of in-vehicle network should be paid more and more attention in the future to reduce the wiring length and weight, which is beneficial to the automotive lightweight, fuel economy and maintainable. As mentioned above, PoE is a promising solution. Simultaneously, the trend of automobile electrification has put forward higher requirements on the power network, especially the electromagnetic interference of high-voltage systems. The use of measures such as shielding and filtering, as well as reasonable arrangements on the wiring, require special attention.

D. SOFTWARE PLATFORM
Software in automotive systems has been increasing crucial. Automotive systems will be more software-intensive in the future. Therefore software engineering is gradually becoming an integral part of the automotive E/E architecture [136].
Originally, the update of automobile software is implemented at the vehicle service stations, connecting to the Internet via the On Board Diagnostic (OBD) interface. Software updates over the air (SOTA) releases the update time or space constraints. For the software service package released by the OEM back-end, the ECU is updated through the WiFi, cellular network or satellite communications. SOTA can fix system flaws, reduce warranty and recall costs and enhance the vehicle's service capabilities [2] At the same time, the safety and availability of the vehicle should be ensured as much as possible in the OTA update process to avoid vehicle downtime or even update failure [137]. It is also important to have sufficient available power when updating to avoid update interruption [138].
Service-Oriented Architecture (SOA) is an IT architecture that supports service orientation and allows integration of distributed and heterogeneous components based on standardized interfaces [139]. SOA emphasizes the separation of services from applications. The separation of software and hardware is an essential element of SOA [140]. Recently, SOA has become the key to the integration and interoperability of different applications and systems in an organization. In SOA, applications are split into small units that can share services between different applications. As a result, SOA promotes integration and demonstrate the high degree of adaptability. SOA enables the easy adaptation to changes and new requirements, rapid design and integration of complex functions [141]. SOA has proven to be an efficient and flexible software design method, mainly due to its scalability and reusability.
SOA has a huge impact on the IT industry and it is already a proven architecture model [142], [143]. It has also been successfully carried out in other industries such as industrial, financial and transportation fields [141]. An end-toend approach to integrate vehicle EE architectures for such heterogeneous applications is SOA. The more flexible the functions required while running, the more communication bandwidth and computing power are required [143]. Therefore, for automotive embedded systems, the solution of Ethernet technology, provides a basis for the development of SOA. Gopu [142] discussed the feasibility study on whether SOA can be implemented on automotive embedded systems. It showed that SOA can be implemented by modifying existing protocols or creating standards. For example, the AUTOSAR architecture can use SOME / IP and integrate SOA into the automotive embedded system without affecting existing ones. With the development of automotive Ethernet and the increase use in Internet services in vehicles, SOA will be more suitable and applied to vehicles [143]. BMW has proposed an SOA method for the next generation of EE architecture, which reduces system complexity through the abstract services, strict encapsulation and hierarchy provided by SOA [144].

VI. CONCLUSION
The E/E architecture needs continuous transformation and innovation to adapt to new automotive technologies. This paper summarizes the design and evaluation of the E/E architecture, and the development of the last century in detail. In addition, we elaborate the state-of-the-art E/E architecture from the perspective of automotive industry, organizational standards, and academic research. Finally? we propose the prospective trends based on current bottlenecks.