TDCA: improved optimization algorithm with degree distribution and communication traffic for the deployment of software components based on AUTOSAR architecture

Automotive Open System Architecture (AUTOSAR), as an open, standardized framework for automotive electronic software development, has gradually become the standard followed by major automotive manufacturers and automotive electronic device suppliers. The electronic software system problem improves the development efficiency and portability of the system by reducing the development cost of automotive electronic software while ensuring the quality of products and services, which is beneficial for subsequent upgrades and updates of the system. In order to improve the reliability of the software component deployment algorithm based on AUTOSAR architecture, we proposed the TDCA algorithm. During the execution of the algorithm, communication volume and communication degree are introduced to improve the accuracy of the deployment plan by optimizing the bus load and ECU balancing. Algorithm comparison experiments show that comparing heuristic and linear optimization algorithms, the TDCA algorithm proposed in this paper has significant advantages in reducing bus load and ECU utilization. The algorithm can reduce the communication between cores and balance ECU load according to the constraints of AUTOSAR architecture.


Introduction
The traditional development model of automotive electronic software is no longer suitable for today's increasingly complex software systems. There is an urgent need for new and efficient automotive electronic software architecture to replace the traditional automotive electronics software development. In response to the intricate design of automotive electronic systems, leading automotive original equipment manufacturers and Tier 1 suppliers jointly established AUTOSAR, which defines a set of support for function-driven, distributed automotive electronic software development methods and software on ECUs Architecture standards to apply to different automotive ECU platforms [1][2][3]. AU-TOSAR is an open and standardized framework for developing automotive electronic software, with the concept of "cooperating on standards and competing in implementation." The purpose is to solve the renewal and replacement of automotive electronic systems and efficiently carry out more complex tasks. The development of the automotive electronic software system improves the software's reusability, reduces the development cost, and solves low software portability and software integration difficulties [3].
AUTOSAR originated in Europe. At first, it was only applied to some sizeable international automobile manufacturers. The applied products were also minimal, only partially applied in engine control modules, body control modules, and gateway modules [4]. Besides, there were only controllers with relatively simple functions in the car at that time, and the software accounted for a small proportion of the entire car electronic control system [5]. It was easy to transplant a complete software system to different hardware platforms.
The application rate of AUTOSAR is relatively low. However, with the rapid development of new technologies in recent years, more and more artificial intelligence and Internet of Things technologies have gradually begun to be applied to automotive electronic systems, such as automatic parking, remote upgrades, fatigue monitoring, workshop communication, lane monitoring and alarm, Pedestrian detection and other functions. The most significant feature of these technologies is that the software algorithms are very complicated, and the software has become the core of the entire automotive system. Therefore, complex car embedded systems need to integrate various essential or critical application functions, and car systems have been upgraded to distributors with many ECUs(Electronic Control Units) [6]. The number of software components implemented as application functions increases to more than tens of thousands with the increase of automobiles' complex functions. At the same time, it will be more complex while the software executes on the ECU. AUTOSAR defines an architecture based on component standardized interfaces, which improves the reusability of components by extracting functions from the hardware [7].
AUTOSAR contains three layers of the automotive embedded system from top to bottom, shown as Fig.1. Application software layer which composed of software components of different granularities. RTE(Runtime Environment) is the heart of AUTOSAR ECU architecture. It is the realization (for particular ECU) of the interfaces of the AUTOSAR VFB(Virtual Function Bus) RTE maps all the runnable of each component in local ECU to the OS tasks and builds the existing intra-ECU communications among them. The AUTOSAR Basic Software layer(BSW) is mainly used to provide essential software services, including standardized system functions and functional interfaces. It comprises of a series of essential service software components, including system services, memory services, communication services, etc. [4,8]. The deployment of SWC to ECU is an essential step in system configurations [9]. For a system composed of ECUs, there are many feasible solutions for deploying SWC to ECUs. The conventional software component deployment problem has been proved to be NPhard [10,11]. Therefore, we purpose an improved algorithm to configure and deploy the SWC to ECU instead of manual operation [12]. However, the initial ECU of the CAT [6] algorithm is randomly selected. Facing the SWC with a low communication degree in the complex communication network, because the CAT algorithm cannot effectively optimize the ECU's internal communication traffic, it will increase bus traffic. On the one hand, the initial ECU communication degree is small, and the busload increases, and on the other hand, it will increase the algorithm execution time.
In this paper, we optimized based on the CAT algorithm [6] and proposed a faster and more effective deployment of SWC based on the traffic degree and communication traffic clustering algorithm named TDCA. TDCA has the following unique functions. First, TDCA sorts SWCs by degree distribution statistics, selects k SWCs with the enormous degree value as the initial ECU cluster center, and deploys other SWCs to ECUs. Second, we defined a penalty function in the trafficdependent clustering process to adjust the ECU load factor's weight value dynamically. We use the current ECU utilization and the parameters defined in advance to calculate the penalty function value's function value. When deploying all SWCs, the system's ECU can balance the load and effectively control the communication network's bus speed. The main contributions of this paper are summarized as follows.
(1)We formulate the optimization deployment problem of SWC to ECU in AUTOSAR architecture to optimize the bus traffic and ECU load.
(2)A clustering optimization algorithm based on degree distribution and traffic (TDCA) is proposed for solving the optimization problem. TDCA introduces the degree value and traffic of SWC to optimize the algorithm performance and algorithm execution time during the deployment of SWC to ECU. The TDCA algorithm has more advantages in optimizing bus traffic and ECU load.
(3)The performance of the proposed method is verified by performing the simulation. For comparison, TD-SCA(Traffic-Degree-Subset-Cluster-Algorithm) ,aheuristic optimization algorithm and linear optimization algorithm are introduced to evaluate the proposed TDCA algorithm's performance in the deployment of SWC to ECU. Moreover, the stability of the algorithm under different data models was tested .   1  2  3  4  5  6  7  8  9  10  11  12  13  14  15  16  17  18  19  20  21  22  23  24  25  26  27  28  29  30  31  32  33  34  35  36  37  38  39  40  41  42  43  44  45  46  47  48  49  50  51  52  53  54  55  56  57  58  59  60  61  62  63  64 65 The rest of this paper is organized as follows. Related research is described in Section II. The concept of component-based distributed systems is described in Section III. Section IV formulates the deployment problems and parameter simulation of SWC. Section V proposes the TDCA and TDSCA algorithm. Section VI introduces the experimental evaluation and result analysis. Section VII presents a summary of findings and conclusions.

Related research
Most researchers investigating multi-processor task deployment have utilized integer programming [13], simulated annealing and tabu search heuristic algorithm [14], particle swarm optimization [15], dynamic programming [16] and ant colony algorithm [17]. Heuristic algorithm [18], the greedy grouping strategy [19] has essential reference significance for component mapping problems [20,21]. The CTMC model [22] is used to handle distributed systems' availability and uses a rule-based hierarchical genetic algorithm with random scheduling strategies to complete task deployment [6].
However, the algorithm does not consider load balancing [23,24]. Dougherty focuses on the deployment of distributed real-time embedded systems of software components [25]. The bin packing algorithm has been used in this problem, but the communication between tasks has not been considered [6].
Zhang Ming, and Z.Gu formulated and solved two optimization problems: mapping SWC to ECU, the purpose is to minimize the busload; for a given SWC to ECU mapping, mapping the runnable entities on each ECU To the OS task, and assign a data consistency mechanism to each shared data item to minimize the memory size requirement on each ECU, while ensuring the schedulability of the task set on all ECUs [17].
Faragardi, Hamid Reza introduced a heuristic algorithm to compare the task granularity of all runnable entities whose tasks are hosted on the same core, which improves the flexibility of assigning runnable entities to each core [20]. Faragardi, Hamid Reza, proposed to reduce the overall network communication time and meet the given timing and priority constraints, without considering the load balance of ECU. Saidi, Salah Eddine, et al. proposed an ILP (Integer Linear Programming) equation for AUTOSAR running mapping process on a multi-core architecture, aiming to minimize inter-core communication and balance the processor load [26]. Ran, Zheng, et al. proposed a traffic-based software component deployment algorithm, CAT algorithm, under the premise of optimizing bus communication costs while balancing the ECU load [6].

Software components and Runnable entities
In the AUTOSAR architecture, the automotive electronics application software consists of software components located on the AUTOSAR RTE [27]. The specific behavior of software components depends on the cooperation of runnable entities. Generally, a software component contains one or more runnable entities. In the AUTOSAR architecture, a runnable entity is a piece of program code used to implement a simple algorithm or a specific function.
There are n SWCs communicating with each other in the automotive software system, denoted by A = {a i | i =1, 2,...,n},l e ta i = {b i,j | j =1, 2,...,m i }, b i,j is the set of runnable entities of the software com- ponent a i ,w h e r em i,j is the number of runnable entities. b i,j =(P (b i,j ),e(b i,j ),I(b i,j ),O(b i,j )) among them, P (b i,j ) is the execution period of b i,j , e(b i,j ) is the worst execution time of a runnable entity b i,j , I(b i,j ) is the order of the runnable entity in the software component of According to AUTOSAR, all runnable entities are activated by RTE-Event. Two runnable entities are defined in AUTOSAR RTE, Category1: No waiting time, execute immediately, offset=0. Category2: contains at least one waiting time, or when the server calls, it needs to wait for response feedback. There are 12 RTE-Events defined in Classic AUTOSAR. Most of the RTE-Events in AUTOSAR is periodic; that is, they will be triggered at intervals. However, periodic events are divided into RTE-Events with a strict instruction period and RTE-Events with a non-strict instruction period. The underlying timing triggers directly trigger RTE-Events with strict instruction periods. In contrast, other periodic RTE-events are generated by periodic runnable entities, that is, a series of periodic runnable entities may generate a series of events during operation. RTE-event. We assume that all runnable entities are triggered periodically, and each runnable entity is equal to the timer period. We defined the period of the runnable entity b i,j as P (b i,j ) [6].
In AUTOSAR, the runnable entity is responsible for SWC communication, and its code requirements are as simple as possible to meet reuse requirements and response time constraints. Because the function and structure of the runnable entity are relatively simple, usually, the runnable entity's worst execution time is much shorter than its period e(b i,j ) >P (b i,j ) [6].

Bus architecture
The SWC communication with each SWC by RTE through such as CAN, local interconnect network(LIN), FlexRay, and automotive Ethernet to provide communication to higher layers through a uniform interface [6,[28][29][30]. A typical hardware topology composed of three parts, with three buses and 9 ECUs, is shown as Fig.2. The ECU0 and ECU1 connect to BUS0, ECU2, and ECU3 connect to BUS1, and ECU4 to ECU6 connect to BUS1. Gateway0 is a gateway that acts as a bridge between BUS0 and BUS1, and Gateway1 is a gateway that acts as a bridge between BUS0 and BUS2.
In the current automotive electronic system, the hardware topology is more complicated, and the number of buses is more extensive than before. For complex hardware topology, the gateway can be used as a node to isolate and analyze the entire hardware topology. In the experiment, we presume that the ECU has the same

Communication Network
AUTOSAR defines different ports and interfaces for communication between SWCs according to the communication direction and communication type, including Provide-Port for data output and Receive-Port data requests. At the same time, AUTOSAR divides the application's overall function into a combination of several SWCs (including atomic SWC and non-atomic SWC). Non-atomic SWC can be divided into multiple interconnected atomic SWC. SWC communicates through runnable located inside SWC. The communication between runnable entities is divided into software component internal communication, and software component communication. Runnable entities deployed in the same software component communicate through shared variables in the software component, and runnable entities deployed in different software components communicate through ports. AUTOSAR software components provide well-defined connection points, namely ports. Three types of ports are defined in AUTOSAR: demand port Require-In, supply port Provides-Out, Provide-Require InOut (introduced in AUTOSAR 4.1) demand ports. Naturally, the AUTOSAR port can refer to the following types of interfaces: send-receive interface Sender-Receiver; client-server interface client-server; mode switch interface mode switch; non-volatile data interface nonvolatile data; parameter interface Parameters; Trigger interface trigger. A software component contains multiple interface ports, which are used for data access and function calls.

Problem simulation
The method proposed in this paper is mainly to find the optimal deployment plan for SWC deployment to ECU. Assume that there are n SWCs and need to be deployed to k ECUs in a unique bus architecture. The deployment problem could be transformed into a communication network N cut and optimized into n (N = (n 1 [ n 2 [···[n n )) small communication networks and deploy the n communication into k ECUs. In order to obtain better system performance, we need to consider the factors as follows.

Traffic and traffic degree
There two types of traffic are in AUTOSAR. One is internal traffic in the same ECU, and the other one is bus traffic. The internal traffic means that the SWCs communicate by internal or shared data. The total communication traffic T all is a fixed network that is constant. The transmission of a large amount of data through the bus will lead the bus congestion, and the sharing of data within the ECU will not increase the bus traffic. To reduce the bus congestion caused by data communication, therefore, when we optimize bus traffic in TDCA, we need to make the internal traffic of each T (ecu l ) as more significant as possible. Therefore, the bus traffic T bus as the total traffic minus the traffic inside the ECU T (ecu l ).

The number of ECU
For selecting the number of ECUs, for the mapping process from SWC to ECU in the AUTOSAR architecture, we define the minimum k value.
In fact, in the number of deployed ECUs, the minimum k value will lead to the optimal ECU load, which will result in some SWCs without target ECU deployment. Therefore, the value of k is used as a reference value for the minimum number of ECUs, and the number of ECUs is usually more significant than the value of k.

ECU equalization
Because if the SWC is deployed only based on the amount of communication, it will not only lead to unbalanced ECU utilization among ECUs but also cause specific tasks in the ECUs to fail to be scheduled for execution. Therefore, in the deployment process, we need to use W (ecu l ) the total utilization of the ECU as a reference for the tasks in each ECU that can be executed and scheduled. The e(bi,j ) P (bi,j ) is the utilization of b i,j deployed on the ECU.
For a distributed operating system, each ECU obtains approximately the same ECU utilization rate to obtain better performance. Now we use the standard deviation of W (Standard Deviation) as a measure of ECU equalization [31].
Where E(W ) is the mathematical expectation of E(ecu l ), we treated the STD as the reference for ECU equalization.

TDCA algorithm and TDSCA algorithm
In this section, a faster and more effective Traffic-Degree-Clustering-Algorithm and Traffic-Degree-Subset-Clustering-Algorithm are used to deploy SWCs to ECUs. The TDCA and TDSCA algorithm is described as follows.
For evaluating deployment quality for TDCA, we use the utility function utility (ecu i ,a j ) and to dynamically adjust the ECU load balance and bus traffic. The value of the utility function is directly proportional to the deployment quality of ECU load and traffic bus. utility(ecu i ,a j ) is the product of the communication traffic ct (ecu i ,a j )b e t w e e nS W Ca j and ecu i and fitness value f (ecu i ).
In order to better evaluate TDCA algorithm, we add communication subsets to TDCA algorithm to construct TDSCA algorithm, and optimize the deployment of the relationship between communication subsets of SWCs with large degree value.
Here, the optimization problem equation is as follows. Find all SWC mapping functions M (a i )=ecu l .
Goal 1: Minimize bus communication traffic in the system, that is find the maximum internal traffic of all ECUs, P k l=1 T (ecu l ). Goal 2: On the premise of ensuring that each ECU can be dispatched, ECU load balancing is realized.

T-Traffic
Define ct(ecu i ,a j ) as the traffic between ECU ecu i and SWC a j , which represents the communication traffic between current software component a j and the all SWCs that deployed on ECU ecu i .

D-Degree
In the TDCA process deployment, we defined the traffic degree D i the value that SWC has a communication relationship with other SWCs of each SWC.
TD is defined as the degree matrix of the network. The larger the TD value, the more other SWCs are communicating with the SWC. Therefore, selecting a larger SWC can ensure that the SWC that has a close communication relationship with the SWC is deployed to the same ECU, which can effectively increase the internal communication traffic of the ECU, reduce the busload and algorithm execute time.

S-Subset
The communication relationship in modern automotive electronics is complex, and the same communication targets may exist between SWCs with multiple communication objects. Therefore, we introduced the concept of communication subsets and defined communication subsets based on the degree of communication, as shown in Fig.4 1  2  3  4  5  6  7  8  9  10  11  12  13  14  15  16  17  18  19  20  21  22  23  24  25  26  27  28  29  30  31  32  33  34  35  36  37  38  39  40  41  42  43  44  45  46  47  48  49  50  51  52  53  54  55  56  57  58  59  60  61  62  63  64  65 large degree may have some common communication relationship with others. For example there are 35 degrees and 46 degrees for a i and a j , we can inform that from Fig.4 that the communication subset of a i and a j is Subset(a i ,a j ) = 5, and it shown in the middle part colored with dark blue in Fig.4. The definition of subset is shown in formula (8). (1:n) . ⇤ a j,(1:n)

C-Cluster algorithm
The fitness function f (ecu i ) can automatically adjust the effectiveness function value in the clustering process. At the beginning of the algorithm, the deployment of SWC is mainly based on ECU internal communication. As ECU utilization increases, the fitness function value decrease rapidly. Therefore, the deployment of SWC gradually depends on the ECU load as the algorithm executes. In the end, both bus traffic and ECU load have been optimized.
In the iterative calculation process of the TDCA algorithm, the initial ECUs will select by degree value. The SWC will be deployed to the ECU with the maximum utility value if Judge < 0.69. After completing the iteration, update the initial SWC and communication traffic in the ECU, respectively, and redeploy until no better deployment plan can be obtained. At the beginning of the TDCA algorithm, the k SWCs with an enormous degree value are selected as the cluster center points of the initial k ECUs.
The specific operation is as follows, select {C 1 ,C 2 ,...,C k } to become the current cluster corresponding to the ECU. For SWC a i that has not been deployed to any ECU, recalculate the distance from a i to all clusters to obtain {ct(ecu 1 ,a i ),ct(ecu 2 ,a i ),...,ct(ecu k ,a i )}. Then calculate the utility value of each SWC through the fitness function, {utility(ecu 1 ,a i ),...,utility(ecu k ,a i )}.SW C a i will be deployed on the ECU with the highest utility value.
According to the RM schedule strategy in 1973 [32], the ECU will be non-schedulable when the utilization is more significant than 0.69. Therefore, the utilization of each ECU and the ECU's average utilization should both be less than 0.69. Assuming that SWC a i is deployed on ECU ecu j ,S W Ca i included in cluster C j , cluster C j will become more extensive, and then the distance will be updated. C j = C j [ a i , and the utilization rate of ECU ecu j has been updated. The Judge is a function to verify whether the ECU task can be scheduled when the SWC is deployed to the ECU.
The bus traffic T bus needs to be calculated to determine whether the stop condition is met after the iteration. If necessary, to continue the iterative calculation, the SWC with the enormous internal communication traffic in each ECU will become the new cluster center for the next iteration.

Fitness function
To ensure that each ECU is schedulable and ECU equalization in the TDCA algorithm, the f (ecu i )isdefinedto correct the utility value in the TDCA algorithm, shown as follows.
Among them, in order to set the weight of the TDCA algorithm execution process bus traffic and ECU load, the artificial setting adjustment parameter η is defined. The more significant value of η means the internal communication traffic gets more weight; a smaller value means the ECU load gets more weight. The internal communication traffic of the ECU and inversely proportional to the ECU load.
f (ecu i ) is a monotonically decreasing concave function, mainly used to control the ECU load to ensure that it can be scheduled. When the value of W (ecu i )i s less than (EW η), because f (ecu i ) decreases slowly, f (ecu i ) has little effect on the effectiveness function. At this time, the TDCA algorithm is mainly based on the amount of communication. When W (ecu i ) 2 [EW η, EW + η], f (ecu i ) decreases rapidly. Due to the rapid decrease of f (ecu i ), SWC deployment will be different from ECU. ECU load becomes the main factor of cluster quality. When W (ecu i ) is greater than EW + η, the function f (ecu i ) is less than zero, and the fitness function is negative. This means that the load of ECU ecu i is very heavy, and no SWC will be deployed on this ECU. Therefore, the adaptive function can ensure the schedulability of ECUs and achieve a good balance in each ECU.

Penalty function
In addition to defining a fitness function similar to CAT, TDCA also defines a penalty function to correct the bus traffic weight for each ECU. In order to ensure the ECU load balance and effectively reduce the communication between ECUs, especially the penalty function item is added on the basis of the fitness function. The penalty function is used to dynamically adjust the ECU load while affecting the communication between ECUs. The penalty function is shown as follows.
In formula (12),α 1 is the penalty factor for utilization, and α 2 is the penalty factor for bus load. To be fair, we respectively defined α 1 = α 2 =0.5; in this way, the weights assigned to ECU utilization and bus load remain constant. Step5: if exit (T bus )  MNI end the algorithm. else go to Step3. The exit(T bus ) records the bus traffic T bus during each iteration to determine whether to end the iteration. The TDCA algorithm consists of 5 Steps: In Step1, initialize all variables. In Step2, TD will be calculated. In Step3, deploy SWCs to ECUs. In Step4, the W and ct will be updated. In Step5, if there is no smaller T bus , or the iteration period is reached, the algorithm ends.

Performance evaluation
This section conducts an experimental evaluation of the TDCA, TDSCA, CAT, and heuristic SPA algorithms and compares the results with ILP-based load balancing and ILP-based non-load balancing algorithms.

Dataset description
The data set AIS is extracted from the application program interface example and has five complex functions provided by the AUTOSAR specification. Based on the communication network of the data set AIS, we generated 904 atomic SWCs. The statistical analysis of the data set AIS shows that AIS's communication density is λ =0.14. The data set AIS is shown in Fig.5.
For the artificially synthesized automobile electronic software component set, firstly generate a random connection diagram according to the number of components, and then transform it into a component communication network. Since components are mainly used for communication, runnable entities with enormous communication traffic have longer execution times, and vice versa. Therefore, the executable entities' execution time and period are combined according to the components communication traffic. When generating the executable entities' execution time and period in the component, the average utilization rate of all ECUs must be less than 0.69. In actual automotive electronic applications, the average utilization rate of ECUs will not be too high.
For the synthetic experimental data set, we convert the random connected graph into a specified number of SWC communication network and generate the worst execution time and period of SWC according to the traffic. The worst execution time of runnable entities in SWC is proportional to SWC's communication traffic.
In the experiment process, the PLP model (Planted l-partition model) planned by the graph segmentation algorithm plan using the implantable segmentation model is a multi-level Erdos Renyi model [33] to generate random connected graphs and is expressed as (n, k, p, q). The data set we generated based on the PLP model is shown as Fig.6.

Comparison of algorithms with ECU equalization
For the data set AIS, four algorithms are used to deploy SWCs to 6,8,10,12,14 and 16 ECUs. For CAT, SPA, TDSCA, and TDCA algorithms, η is set to EW/2k. For ILP Var, we set the max utilization of each ECU equal to the overall utilization average.
Evaluate the performance of algorithms of deployment base on bus load(T bus ), ECU balancing(STD), and the algorithm execution time(Runtime). Fig.8 shows the effect of the number of ECUs on bus traffic. TDCA's bus traffic from 700 to 1100, the value of TDSCA ranges form 1100 to 2200, the bus traffic range of CAT is between 1200 and 1700, the value of SPA ranges from 400 to 1600, and the value of ILP Var ranges from 1300 to 1800. Compared with other algorithms, the optimization performance of TDCA algorithm for bus traffic is better than other algorithms, and the fluctuation is smaller.
ECU load balancing is shown in Fig.9. Since the maximum utilization of each ECU is manually set in the initial stage, the ILP Var algorithm has significant performance in ECU load. However, we can inform the ILP Var could not decrease the bus traffic T bus from Fig.9. For the AIS data set, as the number of ECUs increases, in addition to ILP Var, the best performance in ECU equalization is the TDCA algorithm, followed by the SPA algorithm, TDSCA algorithm and finally, the CAT algorithm.
The execution time of algorithms is shown in Fig.10. Compared with CAT, TDSCA, SPA, and ILP Var, TD-SCA has the longest execution time, the execution time of the SPA algorithm is in the middle, while TDCA,  CAT, and ILP Var are all less than 100ms, and TDCA is between CAT and ILP Var in most times. Fig.8, Fig.9, Fig.10 and Table 2 show that the TDCA algorithm has good performance in reducing bus traffic, optimizing ECU equalization, and algorithm execution time during the deployment process based on the AIS data set.Compared with other algorithms, TDCA algorithm is the best in terms of comprehensive bus load, ECU balance and algorithm running time.
3.Algorithm execution time: Fig.13 shows the execution time, regardless of the communication data under the PLP model or the communication data under  the RGE model, the CAT algorithm, TDCA algorithm, TDSCA algorithm and SPA algorithm is acceptable when the number of SWCs is small. However, when the number of SWCs increases, the TDSCA and SPA algorithm's execution time increases significantly, especially for TDSCA, while the TDCA algorithm and CAT algorithm still have significant advantages in algorithm execution time. Compared with other algorithms, the TDCA algorithm also has advantages in algorithm execution. In summary, compared with algorithms that meet ECU load balancing, whether it is the AIS data set or randomly generated experimental data set, the TDCA algorithm has advantages in reducing busload, ECU load balancing, and algorithm execution time. With the number of ECUs and SWCs increasing, the TDCA is more stable than others.

Comparison of algorithm without ECU equalization
Since the clustering algorithm may not be the best, we set up another experiment to compare and analyze the 1  2  3  4  5  6  7  8  9  10  11  12  13  14  15  16  17  18  19  20  21  22  23  24  25  26  27  28  29  30  31  32  33  34  35  36  37  38  39  40  41  42  43  44  45  46  47  48  49  50  51  52  53  54  55  56  57  58  59  60  61  62  63  64  65 Fig. 14 Bus traffic with TDCA and ILP Non Var TDCA algorithm and the ILP Non Var (integer linear programming without ECU equalization). In the deployment process of ILP Non Var, we only need to ensure that the utilization rate of each ECU after the algorithm is executed less than 0.69. Compared with the ILP Var algorithm, the ILP Non Var algorithm cannot optimize the ECU load balance, so ILP Non Var has poor performance in ECU load optimization shown as Fig.15. This part uses ILP Non Var algorithm and TDCA algorithms to deploy the 200 to 400 SWCs that conform to the RGE model distribution, and the number of ECUs is set to 5. Fig.14, Fig.15, and Fig.16 respectively show the bus communication, standard deviation, and algorithm execution time of each algorithm. Fig.14 shows that TDCA is better than ILP Non Var in bus traffic. In terms of ECU equalization, the TDCA algorithm's advantages gradually weaken as the number of SWCs increases, as shown in Fig.15. For the algorithm execution time, as the number of SWC increases, the gap between TDCA and ILP Non Var algorithm execution time is getting smaller and smaller. Finally, the algorithm execution time of the TDCA algorithm is beyond ILP Non Var.

Conclusion
This paper proposes a novel TDCA algorithm is suitable for the SWC deployment algorithm of AUTOSAR architecture. TDCA introduced two improvement factors to improve the busload and ECU load balance of 1  2  3  4  5  6  7  8  9  10  11  12  13  14  15  16  17  18  19  20  21  22  23  24  25  26  27  28  29  30  31  32  33  34  35  36  37  38  39  40  41  42  43  44  45  46  47  48  49  50  51  52  53  54  55  56  57  58  59  60  61  62  63  64  65 the deployment plan, which software components can be automatically deployed to ECUs in automotive electronic systems. This algorithm can reduce the bus traffic while ensuring schedulability, and get a good performance of ECUs equalization. Compared with CAT, SPA, TDSCA and ILP algorithms, TDCA has an excellent performance in reducing bus traffic and ensuring ECU equalization. The algorithm execution time of TDCA is better than others. Under normal circumstances, the TDCA algorithm can meet the deployment requirements of SWC to ECU under the AUTOSAR architecture.
In actual situations, it is more complicated in the deployment process of SWC to ECUs with a strict end-toend time limit for deployment. In the paper, the SWC is deployed into the ECU without considering the final time limit of the SWC. In this case, the SWC with a strict end-to-end execution time limit can be constructed into a composite SWC before SWC deployment. In this way, regardless of the communication rate of the two SWCs, the two SWCs will be deployed to identical ECU. An ideal method is to consider the endto-end execution deadline of the SWC in analyzing the SWC with greater relevance. In the follow-up research work, the objective function will be optimized and adjusted according to this factor to achieve the desired effect .  1  2  3  4  5  6  7  8  9  10  11  12  13  14  15  16  17  18  19  20  21  22  23  24  25  26  27  28  29  30  31  32  33  34  35  36  37  38  39  40  41  42  43  44  45  46  47  48  49  50  51  52  53  54  55  56  57  58  59  60  61  62  63  64  65