# Analysis and Synthesis of Architectures for Automotive Battery Management Systems
### E/E- Architectures  
Nowadays, top segment cars use up to 100 different ECUs [6]. Each ECU obtains data from different sensors and advises the actors to act based on the given and processed data. According to the \"divide and conquer\" approach, several ECUs are connected together, each of which performs only minor tasks in a car. Subsequently, the totality of these units then builds a very complex overall system architecture. Often, the several smaller control units later must communicate to each other to keep the car operating safe and properly. Due to the various amount of data different ECUs must process, their size and performance can differ. This is why CAN-BUS, LIN-BUS and FlexRay are used to connect several units together. Depending on the importance of a controller, its priority in terms of safety and the demand on communication speed, either CAN-BUS, LIN-BUS or FlexRay are used. WhileCAN-BUS systems can handle up to 1 Mbps [11], LIN-BUS can handle 19.2 Kbps [12] and FlexRay up to 10 Mbps [13]. Besides the distributed E/E-architecture as it is common today, there are already some manufacturers which try to establish new architectures. Bosch GmbH [14] tries to establish a cross-domain computing architecture following a zonal architecture approach. The company Continental [15] builds high performance computers (HPC) for the Volkswagen ID.3 and ID.4 already. Tesla manufactures its own powerful computing unit named \"Hardware 3\" [16]. The Domain architecture merges several ECUs together and builds up a general subsystem such as the powertrain, infotainment or advanced driver assistant systems (ADAS). While nowadays the single ECUs are connected to one grand ECU (the domain controller) [17; 18] which handles the communication between the sub-ECUs, manufacturers try to combine all small ECUs on one central control unit to lower the number of controllers and simplify the overall system. A possible next step is that the centralized domain computing units (DCUs) are replaced by zonal gateways and a few centralized computing units. The gateways collect and preprocess the data from the different zones in the car [19]. Therefore, the sensors and actors do not need to be connected directly to one DCU; instead, those can communicate their data to the zonal gateway. The zonal gateway then communicates the pre-processed data to an HPC, where all the functions are combined [6; 20]. In a further step, the zonal gateways might be removed and all sensors and actors will be connected directly to one powerful computing unit (HPC). Figure 1 provides an overview of the architectures mentioned. The illustration shows which evolutionary development steps are possible via the domains to zonal and finally to completely central architectures. In modern planes and flight systems, centralized systems are already in use. Different systems often share one physical multiprocessing unit. This saves space and weight, as both are limited in avionics. A multiprocessing unit provides multiple cores, which enables the parallel and separated working on different tasks on one physical unit [21; 22]. The separation in different cores is important to avoid an influence between the different systems. On the other hand, this could be used to define clear borders and combine several systems which need to work together. This means that several layers either work on their own, or can be connected in some parts, if needed. This approach using virtual machines  
Figure 1: Overview on E/E-architectures and evolution possibilities. and multicore ECUs can lower the number of physical ECUs in avionics as well as in vehicles [6]. Due to the constant growth in data size of in vehicle networks (IVN), the common communication systems CAN-BUS, LIN-BUS, and FlexRay probably will not be able to provide sufficient data transfer rates. Therefore, communication technologies such as Ethernet gain importance drastically [6].