E/E Designer: A Framework to Design and Synthesize Vehicle E/E Architecture

In recent years, the electrical and/or electronic (E/E) architecture of vehicles has evolved significantly, driven by the demand for increased computational power to support safety-critical applications and advanced driver assistance systems (ADAS) functionalities. This evolution has led to the adoption of centralized architectures with high-performance computing units. These architectures also require high-bandwidth and deterministic communication protocols to handle numerous sensors and actuators, especially in mixed-criticality systems. However, configuring and integrating essential applications into a vehicle's E/E architecture while meeting safety requirements, guaranteeing reliable communication, and considering optimization objectives are time-consuming, complex, and error-prone tasks. This article presents a novel model-based framework, called E/E Designer, to facilitate the synthesis of a car's E/E architecture supporting automotive embedded systems modeling. The framework automates mapping of software components to hardware elements and computes schedules for application threads. It establishes network message routing and schedules communication tasks within the car's topology while addressing safety requirements such as redundancy. The E/E Designer also optimizes the system model using multi-objective optimization, and utilizes a single-step approach to solve mixed-integer programming (MIP) constraints in order to reduce the solving time and consider the relations among various constraints. We use an experimental setup to investigate the framework's performance through design-time and run-time evaluations. The results of our design-time experiments indicate that our formulations can scale to systems of reasonable size. During our run-time evaluations, we observed no timing deadline violations after deploying the design-time solutions on the experimental setup.

E/E Designer: A Framework to Design and Synthesize Vehicle E/E Architecture Hadi Askaripoor , Thilo Mueller , and Alois Knoll , Fellow, IEEE Abstract-In recent years, the electrical and/or electronic (E/E) architecture of vehicles has evolved significantly, driven by the demand for increased computational power to support safety-critical applications and advanced driver assistance systems (ADAS) functionalities.This evolution has led to the adoption of centralized architectures with high-performance computing units.These architectures also require high-bandwidth and deterministic communication protocols to handle numerous sensors and actuators, especially in mixed-criticality systems.However, configuring and integrating essential applications into a vehicle's E/E architecture while meeting safety requirements, guaranteeing reliable communication, and considering optimization objectives are time-consuming, complex, and error-prone tasks.This article presents a novel modelbased framework, called E/E Designer, to facilitate the synthesis of a car's E/E architecture supporting automotive embedded systems modeling.The framework automates mapping of software components to hardware elements and computes schedules for application threads.It establishes network message routing and schedules communication tasks within the car's topology while addressing safety requirements such as redundancy.The E/E Designer also optimizes the system model using multi-objective optimization, and utilizes a single-step approach to solve mixed-integer programming (MIP) constraints in order to reduce the solving time and consider the relations among various constraints.We use an experimental setup to investigate the framework's performance through designtime and run-time evaluations.The results of our design-time experiments indicate that our formulations can scale to systems of reasonable size.During our run-time evaluations, we observed no timing deadline violations after deploying the design-time solutions on the experimental setup.
Index Terms-Autonomous driving, design automation, design space exploration, E/E architecture synthesis, functional safety, message routing, model-based development, multi-core mapping, multi-objective optimization, optimization, time-triggered scheduling.

I. INTRODUCTION
T HE complexity and types of applications required in to- day's vehicles have increased significantly, particularly The authors are with the Chair of Robotics, Artificial Intelligence and Real-time Systems, Technical University of Munich, 85768 Garching bei Muenchen, Germany (e-mail: hadi.askari@tum.de;thilo.mueller@tum.de;knoll@in.tum.de).
Color versions of one or more figures in this article are available at https://doi.org/10.1109/TIV.2023.3324617.
Digital Object Identifier 10.1109/TIV.2023.3324617 with advanced driver assistance systems (ADAS) and selfdriving capabilities.Multiple factors need to be considered when developing a car's E/E architecture.Automotive software architecture needs to be configured during the early design phase to meet both safety and non-safety-related requirements, including ISO 26262 and safety of the intended functionality (SOTIF) [1], [2].As a result, the vehicle's E/E architecture has evolved to accommodate the increased complexity of the new applications and functionalities that need to be integrated into the car.The E/E architecture has evolved from distributed/decentralized, with interconnected electronic control units (ECUs), to domaincentralized and centralized/zonal architectures [3], [4].Multicore computing units are commonly utilized in ADAS and automated driving to ensure sufficient performance for AI-based applications while reducing hardware (e.g., wiring harness and number of ECUs) and software complexities.A significant amount of data needs to be transmitted over the in-vehicle communication network for new infotainment and driver assistance features [5].However, the transmission must be highly reliable when the vehicle relies on messages over its communication network, to make safety-critical decisions.Low latency or even deterministic message transmissions and correct schedules for each communication frame are also necessary to meet the demands of real-time applications.Therefore, developing an E/E architecture with ADAS functionalities and algorithms that meets all safety-related (e.g., timing, freedom from interference (FFI), and redundancy) and nonsafety-related requirements is a laborious and time-consuming task that requires domain-specific knowledge [6], [7].Manually integrating and configuring the software architecture for an automotive high-performance computing unit (HPCU) is challenging and prone to errors, given the need to fulfill various hardware, application, operating system (OS), middleware, and hypervisor requirements and properties.This also applies to configuring an automotive communication network, which must enable reliable data transmission of safety-critical ADAS applications.These configurations can be optimized for multiple goals, including power consumption, resource utilization, reliability, bandwidth usage, temperature, cost, response time, end-to-end latency, and more [3].
Our study presents a model-based framework that simplifies the synthesis of vehicle E/E architectures and reduces the effort and complexity of the design process for multi-core embedded systems and communication networks used in the vehicle's E/E architecture.It supports the automated mapping of software components, such as applications, processes, and threads, to hardware components, like processors, cores, and ECUs, for multi/many-core embedded systems.It calculates time-triggered (TT) schedules for processes and threads assigned to a specific core/processor for real-time applications.In addition, the E/E Designer automatically generates network message routings for the vehicle communication network and computes TT schedules for each predefined communication task routed over a network link.The E/E Designer also covers various safety requirements and optimization objectives.
This framework consists of a backend and a frontend.In the backend, after collecting and analyzing architectural requirements based on the user design in the frontend, all requirements are automatically transformed into constraints using mixed-integer programming (MIP) and model-driven development (MDD) approach [8].These constraints represent the mathematical formulation of mapping, message routing, safety, and scheduling requirements.The set of constraints is then solved using single-step solving algorithms and a joint constraint set based on predefined optimization goals.The result includes optimized mapping, message routing, and TT schedules for the designed E/E architecture.To evaluate the performance of this framework, two types of experiments are proposed.The first is a design-time evaluation, where the synthesis time of the E/E Designer is measured for different use cases.The second is a run-time evaluation, as presented in [9], where the design-time solutions comprising mapping, scheduling, and message routing made by the E/E Designer are deployed on an experimental setup.The experiment includes different hardware platforms and various evaluation metrics, such as jitter, response time, end-to-end latency, device temperature, and measurements imposed on central processing unit (CPU), and random access memory (RAM).In summary, this article makes the following contributions: r We propose a model-based software framework that facil- itates the automation of the design of vehicle E/E architecture.
r We introduce a single-step approach and a joint set of constraints that support automated mapping, communication message routing, path and message dependencies, and scheduling used in the mapping and routing.These constraints, along with various boundary goals and optimization objectives, are described in a single MIP model and solved simultaneously.
r Our framework proposes a communication message rout- ing method that provides single, multicast, redundant, and homogeneous redundant (HR) paths for automotive networks.
r Our framework introduces various safety and boundary constraints, as well as optimization goals, in one package.r We propose design-time and run-time evaluations using a real hardware platform.This article is structured as follows: Section II discusses related work.Section III outlines our methodology, which consists of background, the E/E Designer system architecture, system model, constraint MIP formulation, optimization objectives and boundary constraints, and constraints expression for a MIP solver.Section IV describes the E/E Designer frontend consisting of modeling, requirements and properties, solving and solutions, and model validation.Section V presents evaluation of the E/E Designer, including design-time and run-time evaluations.Section VI presents a discussion of this work, and finally, Section VII illustrates the conclusion and future steps.

II. RELATED WORK
There are several approaches, studies, and commercial and non-commercial tools for automotive software integration, configuration, and E/E architecture synthesis.These works focus on mapping problems and modeling of the software components comprising design space exploration (DSE) and optimization methods.We have comprehensively presented and analyzed these in our previous work [3].In the following, we explain the most related ones.
Archepotrix is an open-source tool that supports modeling of software components and communication between software components, ECUs, buses, and services.It can also optimize the deployment of software components to ECUs based on various objectives, such as redundancy allocation, energy consumption, and cost [10].However, it does not support mapping analysis or solving for multi-core architectures.Additionally, the tool does not integrate safety-related attributes, such as those specified in ISO 26262, except for reliability, and does not support model checking or analysis.
MechatronicUML is an engineering approach proposed by Becker et al. [11] for modeling software/hardware components, specifying constraints, and verifying the models using the UP-PAAL model checker for distributed mechatronic systems [12].However, it has limitations for mapping and software integration in the automotive domain.Firstly, it does not cover mapping analysis and DSE related to the mapping problem in computing units, and does not support optimization.Additionally, safetyrelated attributes for modeling, analysis, or solving, and multicore or HPCU modeling and analysis are not considered.Aut-oFOCUS3 is an open-source tool that models architectures for embedded systems, from requirements to code generation [13].It can synthesize hardware platforms, calculate latency, and optimize deployments and schedules.However, it does not solve the mapping problem for functional and non-functional requirements, lacks mapping analysis for multi-core platforms, and only supports a limited number of safety attributes and optimization goals, specifically automotive safety integrity level (ASIL) level.
A model-based approach called Assist was introduced in [14] to solve and optimize the deployment of safety-critical applications on avionics hardware for distributed aviation systems.It uses the DSE mechanism to find optimal mapping solutions while considering optimization objectives such as resource usage, weight, and cost.This Eclipse-based tool [15] can also create a periodic schedule for real-time tasks and ensure deterministic timing behavior.However, this framework has some hindrances including a limited number of specified architectural elements at the hardware and software levels and only supporting redundancy as a safety-relevant attribute for the mapping problem.It also does not support model checking or model analysis, and has an insufficient number of defined optimization goals.
OSATE is another open-source tool that implements the architecture analysis and design language (AADL) and supports modeling for aerospace and automotive systems [16], [17].It has capabilities for model checking, schedulability analysis, and flow latency analysis, but does not use or cover DSE approaches for solving mapping problems for multi-core automotive computing units and does not support optimization.It also has a limited number of supported safety attributes.APP4MC is an open-source Eclipse-based platform for performance simulation and timing analysis in multi-core platforms [18].It uses a model-based development approach to optimize solutions based on predefined objectives such as load balancing and energy consumption.However, it does not automate task deployment and has limitations in the number of covered safety attributes and optimization goals.It also does not consider a significant number of E/E architecture elements.
To the best of our knowledge, none of the previously mentioned frameworks support message routing and TT scheduling for automotive or non-automotive networks.They also do not offer a single-step solution for exploring the design space for mapping, routing, and scheduling problems.
It should be added that several research studies have investigated message routing and TT scheduling for networks, such as Smirnov et al. [19], who present an approach for creating message routings and valid schedules in a single step for TT networks.The authors of [20] provide a framework for calculating TT schedules for time-sensitive networking (TSN) systems while meeting the standards.Zhang et al. [21] formulate a method for computing TT schedules for tasks routing over communication links and applications running on the network end stations.However, these studies do not support automated mapping and message routing while calculating TT schedules for application threads and communication tasks.
None of the above-mentioned researches or frameworks offer an approach to synthesizing an E/E architecture that covers mapping and TT scheduling for assigned applications and their threads, including single, redundant, HR, and multi-cast message routings creation.Furthermore, calculating TT schedules for communication tasks, supporting path dependency, and applying optimization objectives such as end-to-end latency, response time, resource usage, link occupation rate, maximum resource utilization, and cost simultaneously using a joint constraint set are not considered by them.The E/E Designer, instead, offers various safety requirements such as FFI, redundancy, and ASIL level for mapping and redundancy and homogeneous redundancy for message routing.We also evaluate the performance of the E/E Designer by deploying design-time solutions on an experimental setup, which none of the previously discussed works have done.

III. METHODOLOGY
The E/E Designer framework consists of a backend and a frontend.As shown in Fig. 1, the frontend includes inputs, given by a system integrator, and outputs.Moreover, the middle box refers to the backend of E/E Designer.A. Background 1) Mapping: Allocation of tasks in multi-core computing units can be done in design time or run-time.When assigning tasks during design time, no application is running, unlike runtime mapping, where tasks can be set to different cores while the system is running.Design-time mapping is preferably utilized when the application requirements are reasonably deterministic.Static mapping uses all system information (e.g., hardware and application properties) to find the optimal solution.This type of mapping is appropriate when there is a set of predefined requirements for the applications and hardware.Whereas, dynamic mapping occurs during run-time and allows for the allocation and deallocation of resources based on the current system state and requirements [3].Fig. 2 shows the static mapping of applications to a vehicle HPCU.
2) Time-Triggered Scheduling: In mixed-critical systems, especially those focused on real-time applications, enabling deterministic message delivery (i.e., all computations must be complete before their respective deadlines), avoiding message overlap, and ensuring low latency are extremely important.Scheduling policies help meet these requirements using various algorithms.TT scheduling is one of the most common scheduling schemes used in the automotive industry to schedule communication tasks and activities [19], [21].In this type of Fig. 3. (a) Vehicle topology, which shows generated paths for communication messages from senders to the receivers and mapped applications to the control nodes.Each colorful dot represents a communication task associated with a communication message.In this example, each application comprises a single application thread.(b) Calculated TT schedules from the sender (n cz 1 ) to the receiver (n cz 7 ).It includes schedules for the sender (number one, with thread slots that are not crossed) and the receiver application threads (number seven, with thread slots that are crossed).The schedules of communications tasks (yellow and red tasks frames in numbers two to six) over the generated path (only the enumerated route in (a)) are also included.The path routing two communication messages (d 1 and d 2 ) is considered.As can be seen, message dependency for the sender and receiver and path dependency for communication tasks are fulfilled.The representations for red and turquoise frames are similar to that of the yellow one.
scheduling, activities/tasks that are periodic are initiated at predefined times (See Fig. 3(b)).In other words, everything is scheduled before the system is deployed, and it is known in advance which activity will run and when.Moreover, all tasks must not overlap during execution [21].Examples of calculated TT schedules based on periods, the execution time of application threads, and the frame length of communication tasks are depicted in Fig. 3(b).
3) Message Routing: The capabilities of ADAS and new infotainment systems are introducing a significant amount of needed computational power in control units and data that needs to be transmitted through an in-car communication network.To transmit messages from one node (e.g., an ECU), as a sender, to another node, as a receiver, a valid routing path is required.In addition, to ensure that messages can be transmitted even in the event of permanent failures such as broken links or defective switches, a certain degree of transmission redundancy is necessary, according to ISO 26262 [2].As the size of automotive communication networks increases, finding a valid path between two nodes becomes increasingly complex and time-consuming due to a large number of applications, nodes, and transmitted messages [6], [19].The topology in Fig. 3(a) shows possible paths, such as the enumerated route, for sending communication messages, including communication tasks (colored dots) over the network's links from sender to receiver applications.
4) Path and Message Dependencies: As explained above, several communication tasks can be sent over each link.In a communication task, a frame must only be forwarded along the routes in the correct temporal order.In other words, the timing order of all threads and tasks for a communication message starting from threads assigned to a sender, routed tasks over links, and mapped threads on a receiver, must be correct.In Fig. 3(b), the right temporal order of two message chains containing application threads and communication tasks (yellow and red frames) for a route, including five links, are visualized.Due to message dependency, the threads and communication tasks in a task chain of a message (i.e., sending a message from the sender application to the receiver application over the vehicle's topology) must be executed in the correct temporal order.

B. The E/E Designer System Architecture
The E/E Designer framework utilizes the extension of the model-based approach presented in [6], [7].As shown in Fig. 1, the system architecture of our framework collects hardware and software properties and requirements selected by the user in the frontend (e.g., ASIL level, safety-criticality, communication and process/thread execution times and periods, cost, memory and bandwidth capacities, forced mapping, link's type, node's type, sender and receiver of a communication message, the desired network topology, or a full-mesh topology including the number of required nodes and links, etc.) as inputs to the system.This framework creates the system metamodel, which is an overall model composed of elements, and the elements are themselves, models, using the MDD approach to transform the inputs (i.e., the user's design) into MIP constraints.This work utilizes an open-source graphic modeling tool utilizing the unified modeling language (UML) from Eclipse Foundation similarly to [6].The designed metamodel, which employs UML to describe another model as an instance, consists of 36 elements.This metamodel comprises 29 classes, with 13 of them serving as the primary elements within our system model.These 13 main elements include Node, Application, Link, Data, Data-in, Data-out, Process, Task, Mapping, ECU, Processor, Core, and Settings.
As Fig. 1 depicts, the main integrated constraints in the E/E Designer are automated mapping of hardware/software components, calculation of TT schedules for mapped application processes/threads, automatic message routing generation comprising single, redundant, HR, and multi-cast routes, TT schedule computation for communication tasks, and path and message dependency for each communication message chain.In addition, various optimization goals, including end-to-end latency, response time, resource usage, maximum resource utilization, link occupation rate (LOR), maximum bandwidth utilization, cost, and multi-objective optimization are integrated into the set of constraints.To solve and optimize the MIP constraints in the E/E Designer system model, a Gurobi optimization solver is utilized [22].After the solving step, a solution regarding all the defined constraints is created as the output of the E/E Designer and is visualized by the frontend.

C. System Model
The E/E Designer system model is a distributed system that consists of multiple nodes and links.We represent this system as a graph G(N, L), with vertices N representing vehicle nodes (such as HPCUs, ECUs, gateways, and network switches) and edges L representing full-duplex links (such as Ethernet, FlexRay, and time-triggered (TT) CAN bus).Gateways and switches only act as networking or intermediate nodes (i.e., they are neither sender nor receiver) to transfer data from one point to another.Whereas, HPCUs and ECUs can function as control nodes, where applications can be assigned, and they are able to send/receive data.The control nodes can also operate as intermediate nodes.
Additionally, each HPCU may have sub-components, such as processors, cores, graphics processing units (GPUs), and memory.To distinguish between different types of nodes, we use the notation n cz to symbolize a control node and n nz to represent a networking node.A single core that belongs to a control node, such as an HPCU core, is denoted as n cz c .A full-duplex link between two nodes n a and n b is represented by l a,b ∈ L and l b,a ∈ L, indicating directed links from n a to n b and from n b to n a , respectively.The E/E Designer system model includes several components, explained as follows.
1) Application Thread: In our system model, each application running on a control node can have multiple processes/threads.Hence, a thread running on a control node is defined as an application thread.We assume that threads are periodic, denoted as t i , and specified by a tuple t i = {t i .p,t i .st,t i .e}.The description of each element is explained in Table I.In the example shown in Fig. 2, there are four applications, each including one thread, running on n cz 1 .

2) Communication Task:
A communication task c i can be specified as c i = {c i .p,c i .st,c i .fl} (For more details, see Table I).Each communication task is represented as a unique frame with frame length c i .fl.As explained in Section III-A3, a route is defined as a path from a sender to a receiver transmitting c i .For example, in Fig. 3(a), there are three communication tasks flowing from one control node to another over created paths (e.g., the enumerated route).
A single schedule on a link l a,b is indicated as c i .stl a,b , which represents the starting time of the frame c i .It should be noted that the entire process of sending, forwarding, and receiving a frame over the network is represented as a communication task.
3) Mapping: Assigning applications, which consist of processes/threads, to control nodes such as ECUs or the cores of an HPCU is defined as a mapping action (See Fig. 2).To automate the mapping process, we consider a mapping indication as m ij in our system model comprising different sub-variables., respectively (See Fig. 3(a)).Similarly, each n cz i includes all mappings of existing applications, meaning that each a i , which consists of a t i or multiple t i , can be executed on each n cz i .4) Communication Message: We define multiple variables in the system model to create automatic message routings for a designed vehicle E/E architecture using the E/E Designer.A communication message is a piece of information sent from a sender to a receiver.In our model, a communication message The message chain is characterized by d i .chi , containing the threads, as the sender and receiver, and a communication task that transfers the communication message in a correct temporal order.A communication task which carries the message, as described before, symbolized with d i .ci .The message d i received by a node n is represented as d in i while d out i designates the d i sent by the node n.Following the shown example in Fig. 3, the message chain d 1 .ch 1 for d 1 consists of two threads related to applications a 1 and a 4 and a communication task c 1 (yellow dots in Fig. 3(a) over the enumerated path) routing over five links in the visualized temporal order (yellow frames in Fig. 3(b)).Note that each application thread can only generate one communication message, which is then transmitted via one communication task.
In addition, the message d i sent out from n a over l a,b is denoted as d out i .ln a a,b , whereas the message d i received by n a over l b,a is characterized as d in i .ln a b,a (See Table I).The response time of a communication message is indicated by d i .rt,which represents the time between the beginning of the period and the end of the last communication task.Meanwhile, the end-to-end latency d i .elrepresents the time between the start of the first task and the end of the last task.The significance of these two parameters will be explained in the following sections.
5) Application: An application a i is a collection of application threads that can act as senders or receivers of communication messages to perform a specific function.The application is defined by the tuple  I.

6) Timing Parameters:
The current version of the E/E Designer offers a non-preemptive TT scheduling scheme for all application threads running on the control nodes and routed communication tasks over the links.As a result, we have incorporated some additional timing constraints in our system, similar to those presented in [21], which are explained below.When a thread completes its task, it takes some time before the data can be packed into frames and sent over the network.This time is denoted by sd.Similarly, when a frame arrives at a control node, it requires a specific amount of time to be unpacked and processed before the relevant node can use the data.This time is referred to as rd.The maximum processing delay of a communication frame in a networking node is represented as pd.It is defined as the time between the reception of the last bit on the input port and the earliest possible transmission of the first bit on the output port.Additionally, we consider the interpacket gap, or ipg, which is the required time between network packets or frames.This gap is necessary as a brief recovery time to allow devices to prepare for the reception of the next packet.Finally, the bandwidth is indicated by bw, which represents the maximum possible amount of data transfer between two points of a network over the link in a specific time.

D. Constraint MIP Formulation
The E/E Designer framework creates automated mapping and automatic message routings.It considers path and message dependencies and calculates the TT schedules for different application threads and communication tasks c i for a designed vehicle E/E architecture.These threads run on various control nodes n cz i , and the communication tasks route over the network.The framework takes predefined optimization objectives into account.We characterize the E/E architecture presented in Section III-C as a distributed system.We do this to proceed with the E/E Designer goals using a set of constraints.
1) Automated Mapping: To automatically assign applications, including their threads, to control nodes, the following constraint set is formulated: The condition (1) ensures that each application is only mapped once on each n cz i .Moreover, to distribute the applications, including their threads, to all existing control nodes, each n cz i must execute at least one a i which is encoded in (2).Based on the constraint (3), the sender and receiver threads from two different applications, transferring a communication message, cannot be executed on the same control node.
Furthermore, we define the sets of all mapping variables as M and all applications, including safety-critical ones, as A.
Note that all mapping variables are defined as binary variables (i.e., 0 or 1).To meet the redundancy requirement following ISO 26262, the safety-critical applications A sc set must run redundantly.Hence, condition (4) forces each A sc to be executed twice on various n cz i .In addition, to fulfill the FFI demand for a sc and a asil (e.g., ASIL D applications), non-safety a j and safety-critical a k applications must not run on the same n cz i which is formulated in (5).The same constraints are applied for each core of an HPCU (n cz c ).That is, the redundancy and FFI conditions are valid for various cores with different ASIL levels.
2) Overlapping-Free Application Threads Considering Automated Mapping: This condition applies the TT scheduling, as illustrated in Section III-A2, only to the assigned application threads on each control node.In other words, the constraint set ensures that on every single control node, one mapped application thread is only triggered when the node is idle, i.e., after the last thread is finished.We extend the presented overlapping constraints in ( 6) from [21] based on our system model so that automated mapping and TT scheduling for application threads on each control node can be performed in a single-step solving.We define the set of all application threads as T .In addition, the activated mapping variables, m kα and m kβ , regarding each pair of application threads running on a control node, are specified as the mapping variable denoting M. The pair of threads can belong to the same or different applications.This condition can be encoded as follows.represent the related binary mapping variables of the threads t i and t j , respectively.In this set of constraints, we define all variables as double-precision except for binary mapping variables.Based on constraint (6), one of the equations are valid at the time.Constraint (7) ensures that the calculated starting time of thread t i becomes greater than or equal to zero, and condition (8) states that the thread job t i must be finished in its period slot.The same conditions are applied for t j .Following Fig. 3, there are three sender application threads from three diverse applications a 1 .ts 11 , a 2 .ts 21 , and a 3 .ts 31 which are assigned to a control node n cz 1 automatically and the correct schedule of each thread is visualized in Fig. 3(b) using this constraint set.
3) Automatic Message Routing: Our previous work [6] presented all the constraints required to automatically create network message routing, including single, redundant, and HR routings.HR routes are backup paths in a network that are identical in terms of capacity, topology, and performance to the primary path.Therefore, they are disjoint.HR routes are typically implemented to provide high availability and fault tolerance for critical applications and services.On the other hand, redundant routes refer to the presence of any backup or alternative paths in a network.They are not necessarily disjoint.The main goal of redundant routes is to ensure network availability and reduce downtime in the event of a failure.
In the E/E Designer, we use similar constraints to as [6] to create routes but with changes regarding multicast routing, automated mapping, and the joint constraint set.These changes affect the entire routing system model.However, only changes related to multicast paths will be explained in the following.
or 4) Overlapping-Free Communication Tasks Considering Automated Mapping: To ensure that there is no collision of frames being sent over a single directed link, a frame can only start its transmission ipg time units after the last frame is finished.The same TT scheduling policy for application threads is applied for the communication tasks routing over a directed link only once the related link is activated, i.e., when the relevant link is part of a created route.The set of all communication tasks is defined as C, and d out i and d out j , which are pairs of d out relevant to a directed link, are part of the set of activated routing variables symbolized by D. This condition can be formulated as follows.
Authorized licensed use limited to the terms of the applicable license agreement with IEEE.Restrictions apply. considering Constraints (10), (11), and ( 12) are encoded for the same reason as constraints ( 6), (7), and (8) for application threads, with the only difference that here they are applied for pair of communication tasks c i and c j instead.By using r, we ensure that the starting time of communication tasks is only computed for the activated links, which are part of a generated path.Note that c i .fl/bw represents the transmission time of the packet c i .fl for a given bandwidth bw.In this constraint set, we define all variables as double precision float number except for binary variables d out i .ci and d out j .cj which represent d out i related to communication task c i and d out j related to communication task c j , respectively.In Fig. 3(a), for example, in link number two, three communication tasks share the same link to route three messages (d 1 .c 1 , d 2 .c 2 , and d 3 .c3 ).

5) Path Dependency of Communication Tasks and Message Dependency Considering Automatic Message Routing:
The constraint set ( 13) is encoded to ensure path dependency only for the active routes in communication.This condition only becomes activated when the corresponding outgoing message over the related link, e.g., d out i .lk−1 , is active.In Fig. 3(a), the enumerated path consists of five links (nl = 5) and on each link, communication tasks are transmitted.The starting time of these tasks is represented with c i .stl k d i , must be in the correct temporal order satisfying (13) (see, for example, the yellow schedule slots for links number two to six in Fig. 3(b)).Here, k represents the link number that bounds to nl, representing the number of existing links in each possible path, and L is defined as the set of directed links.Based on our assumption, all schedules are referenced to the local time of the networking nodes.
Due to the message dependency, the application threads and communication tasks in the message chain must be executed in the correct temporal order, as illustrated above.Furthermore, constraint (14) states that the thread's starting time of the sender, t s i .std i , sending d i , must be less than the starting time of the related communication task over the first link of the path denoted by l s .This rule is only applied to the activated link, d out i .ls , which is part of a created route.While the thread's starting time of the receiver, t r i .std i , must be greater than the related communication task over the last link l f of the route based on (15), considering only the activated edge.
For instance, in Fig. 3(b), the yellow slot a 1 .ts 11 .d 1 is followed by d 1 .c 1 over link number two (14).Also, based on (13), all d 1 .c 1 Algorithm 1: The PD Algorithm.frames meet the correct temporal order over links two to six.Finally, d 1 .c 1 over link six is followed by a 4 .tr 41 .d 1 , according to the condition (15).
As mentioned earlier, we solve our system model in a single step, which includes automated mapping, automatic message routing, and TT scheduling.Our approach allows us to use the same joint constraint set for mapping, routing, and scheduling throughout the entire optimization run.Several algorithms are applied to fulfill this approach.In the following, one of these algorithms is presented.
To fulfill the path dependency, we present the PD algorithm.The path dependency is only triggered for activated paths.For each communication message (d), all links pass through several conditions.Firstly, for all tasks, the task carrying the same message as d i is extracted and stored in the variable t (lines 3 to 7).The subsequent tasks over subsequent links are investigated and stored in a list (lines 8 to 13).Then, from the lines (14) to Fig. 4. End-to-end latency and response time for a communication message (d i .eland d i .rt,respectively).Number one indicates a i .ts ij slot, as a sender, number two represents c i frame.As a receiver, a j .tr ji slot is shown by number three.(19), the d out s related to the same d i are retrieved and saved in a list.In addition, all tasks with the same communication message are extracted from the list of subsequent tasks (lines 20 to 24).In the last step, for each variable of the last created list regarding d out (line 25), all variables of the task list generated in line (22) pass through an if condition, which checks if the extracted task (t) in line ( 5) has the same related link as each d out listed in id out _list.If the condition is satisfied, then the condition ( 13) is applied.

E. Optimization Objectives and Boundary Constraints
Several optimization goals and boundary conditions as requirements are supported by the E/E Designer which are described in the following.
1) End-to-end Latency: It refers to the time it takes for a message to travel from the sender to the receiver.This metric considers all the delays that may occur along the way, such as network congestion, processing delays, and transmission delays.Low end-to-end latency means the system can transmit messages quickly and reliably.Based on Fig. 4, the end-to-end latency of a communication message (d i .el) is the time between the start of the application thread acting as the sender (a i .ts ij .st)and the finishing of the application thread operating as the receiver (a j .tr ji .st+ a j .tr ji .e) of its message chain (d i .chi ) (See equation (16) and Fig. 4).
Fig. 4 depicts an example of an end-to-end latency computation for a communication message where the message chain comprises two threads belonging to two various applications and a communication task.To minimize the end-to-end latency of each communication message, (17) is applied.In addition, a hard constraint, as (18), can be used to limit the end-to-end latency to under a specific maximum bearable value.

∀i ∈ N; d i ∈ D:
2) Response Time: It is the time it takes for a system to respond to a request.This metric is important because it reflects the system's ability to process requests quickly and efficiently.A low response time means that the system is able to handle requests quickly and respond promptly.The response time of a communication message (d i .rt) is explained as the time between the beginning of a period, represented as p.st, and the time when the job of the last thread in the corresponding message chain is finished.It is given by Fig. 4 shows an example of the response time for a communication message (d i ) similar to the end-to-end latency.In practice, because of the unavailability of resources, a i .ts ij .st= p.st.Note that if a i .ts ij .st= p.st, the response time becomes equal to the end-to-end latency (d i .el= d i .rt).Like the end-to-end latency, to minimize the response time, which is stated as a time limit that the information of time-triggered systems requires to be updated within this time bound, ( 20) is presented.Similar to the end-to-end latency, condition (21) can be specified to enforce the response time to be within a tolerable maximum limit.∀i ∈ N; d i ∈ D: Note that multicast messages are treated as separate messages when calculating the end-to-end latency.Therefore, the end-to-end latency for a multicast message is determined by the maximum of the individually calculated latencies.Furthermore, for redundant and HR routes, each route has its own latency, and the maximum latency is considered as the final latency for a redundant message.The same policy is applied for the response time.
3) Resource Utilization (RU) and Maximum Resource Usage: Resource usage optimization is crucial for embedded system developers to avoid facing limited resources.Load balancing can prevent irregularly overloading some control nodes while leaving others idle.Therefore, we define boundary constraints and an optimization goal to automatically assign applications to available resources such as ECUs and HPCUs, including cores and processors, while meeting the resource usage and maximum resource utilization conditions.
Based on (22), the number of mapped applications on each control node is minimized, i.e., the applications a j are equally distributed on control nodes n cz i .aj possibly to keep load balancing of each control node the same.Equation ( 23) is used to average the utilization of control nodes.Based on (23), the number of mapped applications on each control node must be greater than or equal to a tolerable bound represented as the apn value, which is the total number of applications divided by the total number of control nodes.The applications are as equally as possible distributed on control nodes to maintain the load balancing of each control node.A similar equation is considered for control node cores such as HPCU cores.
In addition, it is necessary to consider maximum resource utilization, such as the maximum usage of memory and processor of an ECU, due to vehicle software updates.In other words, a specific amount of memory and processor usage must Authorized licensed use limited to the terms of the applicable license agreement with IEEE.Restrictions apply.
be left intact during the design-time configuration process, as a vehicle software update may require extra memory and processor capacities.We specify the maximum memory utilization constraint, formulated as (24).Based on this equation, the sum of application memories that is mapped on n cz i must be within the maximum memory capacity of the node (n cz i .m max ).∀i, j ∈ N; m ij ∈ M; a j ∈ A; n cz i ∈ N : 4) Link Occupation Rate (LOR) and Maximum Bandwidth Utilization: Load balancing is also a technique used to manage communication messages in a network.It helps to reduce the overall density of communication tasks and prevents the overloading of links.Reducing the number of scheduling competitions decreases the system's complexity, resulting in shorter synthesis times.To accomplish this, we use a constraint (25) that assists decreasing the LOR ratio.Based on (25), during exploration of message routing for each communication message d i , the sum of possible outgoing messages d out i over each link l j must be minimized, resulting in frame balancing for each link.Correspondingly to the last optimization goals, the LOR can also be forced to be within a maximum tolerable bound by specifying a hard constraint as (26).We can extend this constraint by adding the bandwidth of each link to ensure that each network link's maximum bandwidth utilization is not exceeded during finding message paths.This leads to condition (27), which states that the sum of bandwidths used by communication tasks over each link l j must be less than or equal to the specified maximum bandwidth for the same link (l j .bwmax ).Here, transT denotes a transmission time of each frame.∀i, j ∈ N; d out i ∈ D; l j ∈ L:

5) Cost Reduction (CR):
Since each communication link in the E/E Designer can have different types, such as Ethernet, FlexRay, and TTCAN-bus, and subsequently varying costs, we also define the cost optimization objective (28) to minimize the cost of the created paths regarding user demand.Similarly, this objective can be applied to other software/hardware components.
∀i, j ∈ N; d out j ∈ D; l i ∈ L: In equation ( 28), the cost of a chosen path, including link/links for a specific data d j , is reduced.In other words, considering the routing constraints, the E/E Designer creates the most costoptimized route for each specific data.

6) Multi-Objective Optimization:
Given the above representation of the E/E Designer optimization goals, different classes of objectives are to be considered in the multi-objective optimization problem.For instance, one combination of objectives can simultaneously minimize the end-to-end latency, response time, LOR, and resource usage, with different predefined priorities.The hierarchical approach introduced by Gurobi [22] is utilized, assigning priority to each objective and optimizing the objectives in descending priority order.In this approach, a higher number is interpreted as a higher priority.For example, based on the goal ( 29), the number four represents the priority of each objective.

F. Constraint Formulation as MIP for Gurobi Solver
All constraints described in Section III-D can be converted into a MIP problem supported by the Gurobi solver.Each condition is represented as a single inequality or equation.For example, constraints (7) and ( 8) are already in this format.
Nevertheless, as the constraints ( 6), (9), and (10) are either-or conditions, they need to be converted.The Big M method [23] is used by introducing a binary decision variable for conditions (6) and (10).Hence, these conditions can be represented as (30), where q indicates the defined binary variable, ω represents the total number of possible collisions between application threads on each control node, and M is specified as a large constant number.Similar methods can be applied to constraint (10).Additionally, we formulate the either-or condition for constraint (9) by multiplying two different binary variables x and y to (31).However, only one of these variables can be one at a time, as specified by (32).
Authorized licensed use limited to the terms of the applicable license agreement with IEEE.Restrictions apply.x + y = 1. (32) In addition, to apply the multiplication of Gurobi variables (e.g., v in constraint ( 30)) to each variable of inequality as their coefficients, we utilize the Gurobi quadratic expression approach (QuadExpr) [22].

IV. THE E/E DESIGNER FRONTEND
Here we explain the frontend of the E/E Designer, a graphical modeling tool where the user can model a desired car E/E architecture or vehicle topology comprising various hardware/software components.The frontend uses Sirius Web [24], an open-source web-based extension of Sirius Desktop, as its foundation.By using Sirius Web, users can directly utilize the modeling features of Sirius from a web browser [24].Once Sirius Web is deployed on a server, users can access and modify editing contexts and download and upload projects without requiring specific installation on their desktops.The frontend of E/E Designer has been modified and developed to integrate our defined attributes, functional requirements, boundary constraints, and optimization objectives specified in the E/E Designer backend and the E/E Designer's outputs into the Sirius Web project.

A. Modeling
The E/E Designer framework allows users to design E/E architectures and car topologies graphically.Fig. 5 presents an example created with our tool.After creating a project, users can select various hardware/software components, such as gateways, network switches, applications (including threads), ECUs (including sub-components like processors and memory), HPCUs (comprising sub-components such as processors, cores, memory, and GPUs), communication messages (in this case, data), communication tasks, and more.Clicking on an empty field brings up a window that displays the available objects that can be chosen and created.Additionally, users can force applications be mapped to specific hardware components before the solving step.For example, in Fig. 5, App 2 is forced to run on ECU 6 (blue arrow).The framework also includes an option for generating a full-mesh network topology for selected hardware nodes, where each node will be connected directly to all other nodes (See the full-mesh option in top-left window of Fig. 6).

B. Requirements and Properties
Apart from modeling, each component's requirements and properties must be determined to solve a designed model.The details regarding several components and the solving settings are taken into consideration.For example, as part of an HPCU, a core can have various ASIL levels as a safety-critical property, a turbo boost feature, and an arbitrary name.While for a link, its type (comprising Ethernet, FlexRay, and TT CAN bus), maximum bandwidth capacity, cost, and name can be selected.Moreover, each link type has a unique visualization symbol.For instance, ECU 7 and ECU 8 are connected with two different links to gateway 2 based on Fig. 5.The application thread properties include the execution time, period, and name of each thread (in the tool named process).Moreover, an application can be defined as safety or non-safety-critical in the application properties and have a specified memory usage.Additionally, each communication task includes a name, frame length, and period as its properties.Also, the sender and receiver of a communication message can be specified.
As mentioned above, our framework supports several requirements, optimization goals, and multi-objective optimization.Hence, we integrated a setting into the frontend where the user can choose the multi-objective type, activate or deactivate the whole optimization method, and each objective and requirement, e.g., LOR maximum tolerable bound, maximum bandwidth utilization, resource usage, maximum resource usage, safetycriticality of an application, and cost.In addition, the type of route, such as single, multi-cast, redundant, and HR, as well as the number of required HR paths, can be chosen.To visualize the solution clearly in the frontend, the created routes and mappings are only shown for related messages.This feature can be selected by the user in the Data properties.
Authorized licensed use limited to the terms of the applicable license agreement with IEEE.Restrictions apply.

C. Solving and Solutions
To solve and optimize a model created with the defined properties, requirements, and optimization objectives (e.g., the model shown in Fig. 6), the E/E Designer includes a Solve option.Clicking on Solve enables the tool to solve the problems associated with the designed architecture while optimizing the solution and fulfilling the specified requirements, as explained in the previous section.
In the model shown in Fig. 6, there are eight applications, six of which include one or two threads with the same periods and different execution times and two applications without a thread.Two applications here are selected as safety-critical (App 5 and App 6 shown with a red frame).Also, the model consists of four communication messages with the same periods as application threads and various frame lengths.We aim to automatically assign the applications to eight ECUs while meeting our defined requirements.We need to ensure that the threads running on each ECU have the correct TT schedules and that all conditions for automated mapping of safety and non-safety-critical applications, as explained above, are fulfilled.Fig. 7 displays the solution of the design model depicted in Fig. 6, which includes message routing, mapping, and scheduling for application threads and communication tasks.As a mapping solution, the E/E Designer determines which applications should be assigned to which ECUs (e.g., blue arrows in Fig. 7).The current mapping requirements in this example are redundancy conditions for safety-critical applications, and the constraint ensures that the threads running on each ECU are not the sender and receiver of the same communication message.In Fig. 7, only mappings related to sender and receiver applications of communication message Data 4 are visualized.Similarly, a created route for a specific communication message to route a message from a sender to a receiver can be shown in the frontend.In Fig. 7, four communication messages need to be sent from senders to receivers.As described earlier, each message comprises a communication task routing over the network links, and the user must specify the threads as the sender and receiver of each message in the frontend before the solving step.Therefore, after solving the model, the user can observe the correct path for each communication message and related mappings for sender and the receiver applications relevant to the same communication message by choosing a desired message.Based on Fig. 7, the red path shows a generated route from ECU 8 as a sender to a receiver ECU 3 routing the communication message d 4 .
Moreover, Fig. 8 shows the calculated schedules for the application threads executing on ECU 3 in Fig. 7 within a computed hyperperiod.As can be observed, each color represents an application, and each slot indicates a thread's schedule.Depending on the thread's period, each slot may be executed multiple times within the hyperperiod.In addition, the computed TT schedules for four communication tasks routed over links can be visualized similarly to Fig. 8. Similar to the scheduling for application threads, the communication task slots are displayed during the related hyperperiod.It should be added that end-to-end latency optimization goal was applied in the solution presented in Fig. 8.

D. Model Validation
Requirements for a valid model include meeting several different criteria.To help ensure a valid model, the validation process of the E/E Designer is continuous, checking the model after each change and displaying validation messages if needed.The message validation consists of a problem description, including the elements, mappings, or attributes that lead to an issue.Additionally, the message indicates the severity of the problem and the urgency to change the model.Based on this, we introduce three different message types: error, warning, and message.An error appears if a model violation occurs.That breaks critical safety requirements or leads to MIP constraint violations.This message type implies that the user must change the model.A warning is used for violations that should not be done but do not cause a severe issue.Finally, the system displays a message to provide simple tips, notes, and other information.

V. EVALUATION
In this section, we evaluate our framework's performance, applicability, and scalability in design-time by performing seven experiments and run-time by deploying the E/E Designer solutions, including mapping, message routing, and scheduling on an experimental setup.

A. Design-Time Evaluation of the E/E Designer Framework
Our proposed framework facilitates the design process for system architects.Nonetheless, high computation times for generating and solving the constraints will have a negative impact on practical usage.Therefore, we investigate how different parameters of the designed system using the E/E Designer affect the time required to generate and solve the constraint set used in our framework.In addition, we present a scalability analysis and show that our single-step solving algorithms and formulation scale to systems with reasonably large sizes.We used Gurobi 9.5 [22] to solve the system models and executed all design-time experiments on a laptop with a 2.80 GHz Core i7 processor and 32 GB memory.
In the first three case studies, we solve the mapping problem by applying the resource utilization (RU) objective as a hard constraint and the scheduling for threads running on each control node using the E/E Designer.In the first case study, we design a distributed system consisting of 10 applications, each including two threads with random execution times t i .e and even periods t i .p,and 10 ECUs as control nodes.In this case study, we increase the system size from 10 to 50 applications and ECUs to measure solving time of the constraint set and the time for generation of MIP constraints (See Fig. 9(a)).In the second case study, a distributed system with 8 ECUs and ten applications, each comprising two threads, is modeled, and the same constraints and solving options as for the first use case are applied.We increase the number of applications from 10 to 70 while maintaining the number of ECUs constant to observe the timing behavior for constraint set solving and generation.Based on Fig. 9(b), the solving time rises exponentially as more thread schedules must be calculated for each ECU.For instance, considering 70 applications assigned to 8 ECUs means that each ECU executes at least eight applications or 16 threads (taking RU objective into account), which must have correct schedules.We perform the exact measurement with a model including eight applications and 8 ECUs, but in this use case, we only increase the number of threads from 2 to 12 for each application while specifying all threads' periods as odd values.As Fig. 9(c) shows, exponential growths can be seen for solving and generation times.Finding schedules for several threads with odd periods is more complicated than even periods due to the least common multiplier and the hyperperiod calculations.
Fig. 9(d) shows measurements for solving a mapping problem and finding correct schedules for application threads.A zonal architecture, similar to Fig. 5, was modeled, including 15 ECUs.We increased the number of applications from 4 to 60 while defining all applications, each including one application thread, as safety-critical.During the solving step, ECU usage and maximum memory utilization of each ECU are set as boundary constraints, and further mapping constraints, as explained in the automated mapping conditions such as redundancy for safety-critical applications are involved.Since the safety-critical application must be executed redundantly, in the case of 60 safety-critical applications, 120 applications are running in the topology.
In Fig. 9(e), we investigate the influence of the creation of various types of routes on the solving time while applying automatic mapping and the application threads and communication tasks schedulings in a single-step for the same zonal E/E architecture modeled in Fig. 9(d).We measure the solving time for creating three types of routes: single, redundant, and HR paths (generating three disjoint routes) from senders to receivers (chosen automatically based on mapping constraints) while increasing the number of communication messages from 4 to 50 and applications from 8 to 100 (each including one thread).Furthermore, the multi-objective optimization, including end-to-end latency, response time, and LOR, using a hierarchical approach and RU and maximum memory usage as single boundary goals are applied.In other words, for example, in Fig. 9(e), when we have 50 communication messages, the solution consists of 50 paths such as single, redundant, and HR routes created from senders to receivers, the schedules of tasks over links only for activated routes, the mapping of applications to ECUs, and the thread schedules on each ECU.As expected, the number of generated routes can influence the solving time.Consequently, based on Fig. 9(e), the HR path requires more time as it needs to find three disjoint routes in each scenario.
1) Scalability Analysis: To evaluate the scalability of the E/E Designer, we measure the time required to generate the system model variables and solve the constraint set for two different architectures, such as a full-mesh topology and a zonal topology, each including 15 ECUs.The automatic message routing (for Authorized licensed use limited to the terms of the applicable license agreement with IEEE.Restrictions apply.generating single paths) and mapping, as well as the application threads and communication tasks schedulings, are solved in a single step for these two architectures.In addition, we apply the multi-objective optimization, including end-to-end latency, response time, and LOR, and the RU and maximum memory utilization as boundary single objectives.All threads have identical execution times and periods.Similarly, the frame lengths of communication tasks are the same, and their periods are as same as the values of their senders' and receivers' periods.
Based on Fig. 10(a), for the full-mesh topology, we increase the number of messages from 10 to 90 and applications from 20 to 180, each comprising an application thread.While, for a zonal topology in Fig. 10(b), the messages rise to 100 and applications to 200.This means that the E/E Designer creates 100 routes from senders to receivers, including their schedules.As Fig. 10 depicts, the solving time for both use cases grows exponentially.Moreover, as expected, the solving time for the full-mesh topology is significantly higher than that of the zonal one due to the larger exploration space.Considering the zonal topology in Fig. 10(b) and its scale up to 100 communication messages and 200 applications, the solving time is reasonable for problems such as mapping, scheduling, and routing, which are known to be NP-hard problems [25], using our single-step solving approach.In practice, the illustrated values are appropriate for an automotive application domain.
The experimental results during the design phase demonstrate that our formulation and approach enable users to synthesize their desired system model that supports mapping, routing, and scheduling within a reasonable time frame while meeting predefined requirements.Furthermore, applying single and multi-objective optimizations can solve more complex problems and conditions.It is worth noting that our tool, the E/E Designer, is suitable for synthesizing any type of vehicle E/E architecture and network topology, including various configurations of applications, threads, and communication tasks.

B. Run-Time Evaluation of the E/E Designer Framework
This section describes how the design-time solutions calculated by the E/E Designer were evaluated experimentally on real hardware.For the experiments, three different hardware platforms commonly found in automotive systems were used.First, an Nvidia Drive AGX Xavier Developer kit was chosen because it is a popular choice for an HPCU in autonomous driving.The development kit is built around two Xavier SoCs, each comprising an 8-core ARM CPU, RAM, and hardware accelerators for deep-learning inference.It runs a modified version of Ubuntu 18.04 with the Preempt-RT-patch as the operating system.Secondly, experiments were conducted on an Intel i210-based evaluation board to simulate a communication network gateway.Thirdly, a Discovery kit with an STM32L476VG microcontroller was utilized as an example of an energy-efficient ECU.
1) Software Setup: a) Tasks: Each task is modeled as a Linux process of a custom benchmark application.The benchmark calculates ten digits of pi using the Gauss-Legendre algorithm in an infinite loop and is thus CPU-bound.Besides, there are sender and receiver applications that support TCP-based message transfer.
b) Scheduling and Dispatching: The scheduling is simulated by another standard Linux process that is assigned the highest real-time priority, 99.It is implemented using a C timer function that invokes a callback every 1000 nanoseconds to check if a thread/task should be scheduled or stopped at that specific timestamp.Before the simulation starts, the number of hyperperiods must be specified so that every task's start and stop times can be calculated in advance and stored in a sorted array.Therefore, in the timer callback, it is only necessary to compare the current counter value with the top entry of the array mentioned above, thus reducing the invocation time of the callback to a minimum.When a task must be started or stopped, the scheduler will send a POSIX signal to the corresponding task.The task is terminated using the SIGKILL signal and restarted using the SIGCONT signal.
c) Task mapping: The tasks are mapped to specific cores before the start of the simulation.Their CPU affinity is set using the taskset command, which will cause the Linux scheduler to bind the process to a given CPU core.To ensure that the tasks are not interrupted by any other processes running on the system, each task is assigned the second-highest real-time priority of 98.With this priority, the tasks are prioritized over every other process by the Linux scheduler but can still be interrupted by the simulation scheduler.Furthermore, all other system and extraneous processes are mapped to CPU core 0, except for bound kernel threads, to isolate the simulated cores.
d) Task synchronization: Clock synchronization among multiple nodes was achieved by connecting them through jumper wires and sending a trigger signal to start the simulation simultaneously.
e) Monitoring: Monitoring is a significant component of performance evaluation because the measurements must be highly accurate and lightweight to avoid influencing the measured metrics.The main performance metric was the start and stop time of each task [26].From this, one can calculate the start and stop jitter, which refers to the difference between the actual and expected start and stop times.Start and stop times were determined by tracing the system calls that indicate a change in process state using strace.Other performance metrics included f) GUI: To facilitate the deployment of calculated solutions, a graphical user interface is developed that integrates all the above-described functionalities into one program.By that, mapping and communication solutions can automatically be deployed onto the hardware to repeat the experiments easily.Furthermore, the developed GUI starts the monitoring and takes care of gathering and processing the measured data.
2) Mapping Evaluation: The mapping evaluation was based on 40 applications, each consisting of three threads.The periods and execution times of these threads can be found in the left section of Table II.A total of 120 application threads are mapped onto different cores.The time-triggered scheduling was evaluated against first in, first out (FIFO) and Round Robin with a time quantum of 1 ms, which was selected based on the shortest execution time.FIFO scheduling is a simple and intuitive scheduling algorithm that operates on a first-come, first-served basis.In this approach, the process that arrives first is executed first, and subsequent processes are executed in the order of their arrival [27].While, Round Robin scheduling is a preemptive scheduling algorithm that allocates a fixed time quantum to each process in a cyclic manner.It ensures fairness by allowing each process to execute for a predefined time slice or quantum before moving to the next process.If a process does not complete its execution within the time quantum, it is temporarily suspended, and the next process in the queue is allowed to run.The suspended process is then placed back in the ready queue, and execution resumes from where it left off during the next scheduling cycle [28].
Since the execution of all cores is independent of one another and the workload is distributed approximately equally among all cores in the evaluated solution, for illustration purpose, only results on one core is shown, as other cores demonstrate similar behavior.
Fig. 11 depicts the jitter measurements for time-triggered scheduling on all the hardware platforms.It can be seen that the jitter produced on the Nvidia Drive is generally significant.The average jitter is approximately 36.6 times higher on the Nvidia Drive compared to the Intel i210 for the same setup.Fig. 12 shows the expected and actual starting and stop times for the three tested scheduling policies on the Nvidia Drive for the first 200 ms.It can be observed that, in all configurations, there are threads that start even after the expected stop time.This is particularly true for shorter execution times and, therefore, more prominent in the Round Robin setup.Furthermore, the offset between the actual and expected execution times remains relatively constant with FIFO scheduling.This indicates that the jitter produced by the dispatcher is centered around a constant value with low variation.Nevertheless, all threads finished within their specified period, indicating that no deadline violations occurred in any of the tested setups.
The results of the CPU, RAM, and temperature measurements of CPU are depicted in Fig. 13.There are noticeable but not significant differences among all the setups.Also, none of the scheduling schemes outperforms the others in all the metrics.
Authorized licensed use limited to the terms of the applicable license agreement with IEEE.Restrictions apply.3) Communication Evaluation: Communication was tested using a scenario consisting of three connected nodes (ECU 1 to ECU 3 ).STM32-based development boards were used for the communication experiments because their low scheduling jitter has only minimal influence on the execution of the synthesized communication solution.
OnECU 1 , three applications ran, each including one thread.Each application thread sent a communication message to a respective receiver thread on ECU 3 via ECU 2 .Fig. 14 visualizes the setup.As defined above, we measured the end-to-end latencies and response times of the three communication messages.The CAN setup was selected as the communication protocol between ECUs since it is a very common protocol in the automotive domain and is simple compared to other protocols in terms of required hardware setup and software realization.In addition, it has relatively little overhead and thus simplifies the calculations.
The communication links had a theoretical bandwidth of 11,520 bytes/s, which is a common baud rate.The size of the communication messages was chosen to be 145 bytes, deliberately kept small to fit into a single frame and avoid fragmentation and long verification times that could potentially influence the results.Each communication task's frame length was set to 12.6 ms, calculated by dividing the size of the communication message by the bandwidth.The interpacket gap was set to 10 ms.These communication properties can be specified by the user for each network protocol in the framework, similar to how timing parameters can be determined in the frontend.The solution calculated by the E/E Designer is presented in the right section of Table II.It shows the start and stop times for the sender and receiver application threads, as well as for the communication tasks, over one hyperperiod.
Fig. 15 shows the results of the communication experiments.It can be seen that the measured response-times and end-to-end latencies are very close to the expected values.

VI. DISCUSSION
The E/E Designer framework be easily extended with new features since we utilize the MDD approach as described.For example, algorithms for event-triggered and/or priority-based scheduling [29] can be integrated into this tool by including new Authorized licensed use limited to the terms of the applicable license agreement with IEEE.Restrictions apply.
constraints to the existing constraint set, and new classes and attributes, if necessary, to the current E/E Designer metamodel.Additionally, new requirements, such as safety requirements, can be incorporated to adapt the current tool for additional automotive safety features.Consequently, this tool is not limited to the current set of constraints and can accommodate other rules.However, the addition of new conditions to the current system model will increase the solving time.The framework introduced in this article is open source and accessible on GitHub [30], offering the research community an opportunity to explore, utilize, and contribute to its development.We believe that open sourcing our framework is essential for fostering collaboration, reproducibility, and transparency in research.

VII. CONCLUSION AND FUTURE STEPS
This article proposes a novel model-based framework called E/E Designer for modeling and synthesizing automotive electrical and/or electronic (E/E) architectures.The framework enables users to model mixed-critical networks, providing automated mapping of applications, calculating schedules for mapped application threads on different ECUs, processors, and cores, creating valid paths for communication messages between senders and receivers (including single, multicast, redundant, and homogeneous redundant routings), and computing schedules for communication tasks routing over network links.It also supports various safety requirements, such as automotive safety integrity level (ASIL), redundancy, and freedom from interference (FFI).The framework optimizes the designed model using multi-objective optimization, including end-to-end latency, response time, resource usage, maximum resource utilization, maximum bandwidth usage, link occupation rate, and cost.We use mixed-integer programming (MIP) to transform the requirements into constraints.Additionally, we utilize an approach that allows us to solve all constraint sets for mapping, application threads scheduling, message routing, and communication tasks scheduling throughout the entire optimization run in a single step.This single-step approach reduces the solving time and respects the interrelations between the specified constraint decisions.Finally, we evaluate the performance of the E/E Designer using two methods: a design-time evaluation, where we assess the solving and generation times of constraint sets in different scenarios, including a scalability analysis, and a run-time evaluation, where we deploy the solution on an experimental setup.The design-time experiments show that our formulations scales to systems with reasonably large size.In the course of our run-time experiments, we noted that there were no instances of timing deadline breaches following the deployment of the design-time solutions on an experimental configuration.
In future work, we will develop a design error analysis approach for our framework to identify the source of violated constraints in case of an infeasible solution after the solving step.This will be especially useful when the system model includes many constraints, as the manual investigation can be timeconsuming and complex.We will also add new optimization goals and safety requirements, such as reliability for mapping and routing problems.

Manuscript received 30
July 2023; revised 19 September 2023; accepted 30 September 2023.Date of publication 13 October 2023; date of current version 25 September 2024.This work was supported by the German Federal Ministry of Education and Research BMBF) through KI-FLEX under Grant 16ES1027, within the framework of the guidelines on promoting research initiatives in the field of AI-based electronic solutions for safe autonomous driving.(Corresponding author: Hadi Askaripoor.)

Fig. 1 .
Fig. 1.Architecture of the E/E Designer framework.The left and right columns, comprising E/E System Integrator Inputs and the E/E Designer Output, represent the frontend and the middle box denotes the backend.

Fig. 5 .
Fig. 5. Example of a zonal E/E architecture model using the E/E Designer.

Fig. 7 .
Fig. 7. Solution of the designed model in Fig. 6 including mapping, message routing, and scheduling.Here, only the mappings for applications one and two, which are related to the communication message four, are displayed.

Fig. 8 .
Fig. 8. Calculated TT schedules by the E/E Designer tool for running application threads on ECU 3 after mapping action as the solution for the model in Fig. 7.

Fig. 9 .
Fig. 9. Design-time performance evaluation of the Designer.(a) Each application consists of two threads.(b) It is applied on a topology comprising eight ECUs, and each application includes two threads.(c) The topology consists of eight applications and eight ECUs.(d) In this use case, a zonal architecture including 15 ECUs is applied, and each safety-critical application has one thread.The boundary goals for resource utilization and maximum memory usage, as well as the safety-critical mapping constraints, are applied.(e) The same architecture as in (d) is used.This time, multi-objective optimization is involved, including end-to-end latency, response time, and LOR, as well as the goals for resource utilization and maximum memory usage.

Fig. 10 .
Fig. 10.Scalability analysis of the E/E Designer.Generation and solving times for (a) a full-mesh architecture and (b) a zonal topology each including 15 ECUs.

Fig. 11 .
Fig. 11.Start and stop jitters of each thread measured for the TT scheduling over one hyperperiod.These are the measurements on CPU core 5. Red bars represent the start jitter, green bars the stop jitter.

Fig. 12 .
Fig. 12. Gantt charts of the different scheduling solutions for CPU 5.The red bars represent the planned execution while the hatched bars stand for the actual execution.

Fig. 13 .
Fig. 13.Comparison of different metrics.Yellow is the TT scheduling, red is FIFO and green is Round Robin scheduling.

Fig. 15 .
Fig. 15.Results of the communication evaluation experiment.The yellow bars represent the expected execution, while the hatched bars represent the actual execution times of the sender and receiver applications.The green bars indicate the planned schedule of the communication messages.The response time and end-to-end latency of each communication message are also shown.

TABLE I NOTATION
a communication message are symbolized as m ij s and m ij r , respectively.For example, the mapping variables of t 1 from a 1 as the sender running on n cz 1 , and t 1 from a 4 as the receiver executing on n cz 7 are indicated with m s 11 .a 1 REFERENCEIt represents a possible mapping of different applications (j) to various control nodes (i).According to the example presented in Fig.2, assigning a 4 to n cz 1 is denoted by m 14 .a4n cz 1 as a mapping variable.Moreover, the mapping variables of a thread belonging to an application that is set as a sender or a receiver Authorized licensed use limited to the terms of the applicable license agreement with IEEE.Restrictions apply.of where a i .tij includes one or multiple application threads t ij = {t i1 , t i2 , . .., t ij }, with j ∈ N, indicating that each a i can have one or many t.Additionally, a i .ts ij .di represents the application thread t j belonging to a i that sends the communication message d i , whereas a i .tr ij .di denotes the t j of a i that receives d i , as stated in Table (9) activated mapping variables, m s ij and m r ij , related to sender and receiver threads of d p , respectively, are members of the set of mapping variables denoted by M. Based on (9), n j .d in p states the d i which enters to the n j over a link and n j .doutiexpresses the d i going out from n j (See TableI).Applying condition(9)to intermediate nodes, which are neither the sender nor receiver of a communication message, states that either the number of d in i must be equal to d out d in p d in p and d out p belong to the set of routing variables symbolized by D. i for each n j or the number of d in i must be less than or equal to d out i to satisfy multicast routing.

TABLE II LEFT TABLE :
PERIODS AND EXECUTION TIMES OF THREADS FOR EACH SAMPLE APPLICATION THREAD.RIGHT TABLE: COMMUNICATION SOLUTION CALCULATED BY THE E/E DESIGNER CPU and RAM utilization, as well as the thermal development of the CPU.