Synthesis and exploration of multi-level, multi-perspective architectures of automotive embedded systems

  • Jordan A. Ross
  • Alexandr Murashkin
  • Jia Hui Liang
  • Michał Antkiewicz
  • Krzysztof Czarnecki
Regular Paper

Abstract

In industry, evaluating candidate architectures for automotive embedded systems is routinely done during the design process. Today’s engineers, however, are limited in the number of candidates that they are able to evaluate in order to find the optimal architectures. This limitation results from the difficulty in defining the candidates as it is a mostly manual process. In this work, we propose a way to synthesize multi-level, multi-perspective candidate architectures and to explore them across the different layers and perspectives. Using a reference model similar to the EAST-ADL domain model but with a focus on early design, we explore the candidate architectures for two case studies: an automotive power window system and the central door locking system. Further, we provide a comprehensive set of question templates, based on the different layers and perspectives, that engineers can ask to synthesize only the candidates relevant to their task at hand. Finally, using the modeling language Clafer, which is supported by automated backend reasoners, we show that it is possible to synthesize and explore optimal candidate architectures for two highly configurable automotive sub-systems.

Keywords

Architecture synthesis Multi-level architectures Multi-perspective architectures E/E architecture Architecture optimization Candidate architectures Early design 

1 Introduction

Automotive E/E (electrical and electronic) architectures are continuing to grow in size and complexity due to the increasing amount of software functions being deployed to cars. These architectures consist of sensors, actuators, electronic control units (ECUs), and the physical connection media such as discrete signal wires, analog signal wires, and digital network buses. Premium cars can have 3 km of wiring connecting more than 70 ECUs with at least 2000 software functions running on them [12, 22]. Additionally, the architectures contain large amounts of variability in features, functions, devices, and the deployment, which further increases the complexity.

EAST-ADL is a reference architecture model and a set of domain-specific languages for modeling automotive E/E architectures. It was designed to capture E/E systems with sufficient detail to allow modeling for documentation, design, analysis, and synthesis [4]. Figure 1 shows the domain model for EAST-ADL and how the system model is composed of multiple abstraction levels which can be cross-cut by one or more perspectives (or extensions). Using EAST-ADL to model a system (or a family of systems) aids in managing the associated complexity [15]. In Sect. 2, we define a reference model for modeling architecture of E/E systems that is simplified (compared to EAST-ADL) for early design, where decomposition of software components may be too detailed to capture. However, the presented model could be extended to cover full EAST-ADL, and the presented synthesis and optimization would be equally applicable. Additionally, while being simplified, the presented reference model is composed of multiple abstraction levels and perspectives. We apply the reference model to building architectural models which represent many possible candidate architectures and which affords the engineers to find the ones that exhibit optimal values of their quality attributes1 such as total cost, mass, and timing and explore the trade-offs among them. In Sect. 3, we present a mechanism for constructing a set of design specifications to use in exploring the possible candidate architectures captured in models constructed using the reference model from Sect. 2.
Fig. 1

EAST-ADL domain model [4]

To appreciate the motivation, consider the following example scenario used throughout the remainder of the paper. Emily is an engineer at an automotive company. She is working on designing the E/E system architecture for the door power window. Emily wants to consider a set of candidate architectures and to compare them based on their mass and cost. The candidates themselves should be correct, meaning that they must meet any requirements and constraints specified by Emily (e.g., end-to-end latency and deployment restrictions).

While the EAST-ADL can help Emily in modeling multiple candidate E/E architectures, there is currently no approach allowing Emily to synthesize the candidate architectures, while considering design decisions at all layers, and explore trade-offs among them. In this work, we use a modeling language Clafer to model multilayer, multi-perspective architectures (Sect. 4). We show that by using Clafer we can model alternative design decisions for any component in addition to design constraints and objectives for a number of qualities such as latency, mass, and parts cost. Furthermore, we can join these decisions, constraints, and objectives together using first-order logic to write fine-grained design specifications for exploring the possible design space (Sect. 3).

In Sect. 5, we evaluate our approach qualitatively to show how it improves the state of the art. We also evaluate the performance of synthesizing the candidate architectures. We then provide the threats to validity, related work, and conclude in Sects 67, and 8, respectively.

This work provides the following contributions:
  • Design exploration approach for E/E architectures based on a multilayer and multi-perspective reference model; in contrast to previous work (see related work section), the approach explores many types of design decisions (at least 15) from multiple layers, constraints (at least 13), and objectives (at least 5) simultaneously.

  • The approach is supported by a modeling language, reasoning tool, and results visualization tool to enable a wide range of design exploration scenarios, which are characterized using specification templates.

  • Two large case studies of realistic automotive E/E systems; the corresponding models and exploration scenarios can serve as a future benchmark for comparing design exploration tools in the E/E systems domain.

  • We use one of the case studies to show the relevance of capturing multiple layers for obtaining more realistic exploration results.

  • We show that the majority of the exploration scenarios of the case studies are feasible in terms of performance; we also show that exact optimization is feasible for most of the optimization scenarios for most of the studied models; however, future work will need to address scalability to larger models.

2 Automotive E/E system reference model

Using the motivational scenario, in this section we define a reference model (for the remainder of this paper, we refer to it as the reference model) that supports early design of E/E system architectures. Similar to the EAST-ADL, the reference model is made up of multiple abstraction layers. Each layer describes the system, but at a different level of abstraction. We use the term multilayer to describe models consisting of multiple layers. The reference model also contains multiple perspectives, which augment the system with analysis-task or stakeholder-specific information such as points of variability, latency, and mass; we use the term multi-perspective to describe models that contain more than one perspective. Figure 2 shows the multilayered, multi-perspective reference model with the supported perspectives covered in this paper. We use an ellipses in the perspectives to show that the reference model is not limited to the ones shown, but could be extended with additional ones.
Fig. 2

Reference model used for early design of automotive E/E systems architecture

When a perspective is combined with a multilayered model, it may cross-cut some or all the layers. For example, the mass perspective applies primarily to the hardware architecture, where devices and wires are assigned mass; however, mass information can also be aggregated at the feature level.

The reference model we define is similar to the EAST-ADL domain model; however, the one defined here focuses on the early design stages and does not consider the lower-level software decomposition for the system. More precisely, the simplified model does not consider the functional design architecture of the EAST-ADL; instead, it maps the functional analysis architecture on the hardware design architecture. Additionally, the reference model contains cross-cutting concerns that are not present in the EAST-ADL such as cost and mass, which were introduced by Murashkin [35]. The following two subsections detail the different layers and perspectives of the model, respectively, using Emily’s power window as the running example.

2.1 Reference model layers

Starting with the top-most layer, the features of the system are captured in the feature model layer.2 A feature is a high-level system characteristic relevant to some stakeholder, such as the customer or the user. Features may represent functionality or performance. When defining the features of the power window system, Emily chooses to have three features:
  • basicUpDown:3 the basic functionality of the power window to close or open it by pulling up or pressing the switch until the window glass reaches an end position;

  • expressDown: the window glass retracts automatically when the user presses the switch once;

  • expressUp: the window glass closes automatically, unless an object is detected, when the user pulls up and releases the switch once.

Figure 3a shows a feature model, which organizes features into a hierarchy and indicates their variability, as Kang et. al. proposed in [26]. In Fig. 3a, the features are all mandatory (i.e., no variability). In Fig. 3b, the features express and expressUp are optional; the hierarchy also expresses an implication from expressUp to express, and from express to Driver PW. In this section, we will assume the feature model is representing a single system (Fig. 3a) for our example.
Fig. 3

Power window feature models

Fig. 4

Power window functional analysis architecture. The “HW” or “SW” in upper right corner of a function indicates the implementation choice in hardware or software, respectively

The features are then implemented by one or more functions in the functional analysis architecture (FAA) layer. There are two types of functions defined in the FAA: analysis functions, which model control functions with their inputs and outputs, and functional devices, which capture functions that represent sensors and actuators. Many of the analysis functions will be realized as software components; however, some functions or parts of them may be realized by specialized hardware (such as digital signal processor). Functional devices will typically be realized by hardware sensors and actuators plus additional software, such as device drivers or signal conditioning software. The FAA not only captures the functions, but also the communication among them in order to define a function graph (using function connectors). Figure 4 shows an FAA for the power window in which part of the feature expressUp is implemented by the functions PositionSensor, PinchDetection, and WinControl, including the communication among them.

The hardware architecture models the physical hardware devices and connectivity media in the system, which we decompose into the device node classification, communication topology, and power topology. The device node classification captures the device nodes in the system and their properties; one of which is the device node type. We define a device node as a piece of hardware such as a sensor, actuator, ECU, switch, electric center, or battery. We consider three types of device nodes:
  • Smart A device node that can be programmed with one or more analysis functions or functional devices which are implemented in software. Examples would be an ECU or a hardware device with embedded microcontroller.

  • Electric/Electronic (E/E) A device node that cannot be programmed with executable software but rather implements some hardware functionality described by a functional device or analysis function that is implemented in hardware. Examples would be an analog sensor or actuator.

  • Power A device node that generates, stores, or relays power to other device nodes. In this paper, we do not allow a power device node to have any logic associated with it (i.e., no functional devices or analysis functions deployed to it). An example would be a battery or fuse box.

Figure 5 shows a class diagram of the classification for device nodes, analysis functions, and functional devices. It also shows the allowed deployments of the different functions to the various device node types. Notice from the figure that the classification is a lattice, that is, a smart device also has E/E and power capabilities, whereas an E/E device also has power capability but not smart capability. Thus, a functional device or analysis function implemented in hardware can be deployed to either an E/E or a smart device node.
Fig. 5

Class diagram showing classification of device nodes and functions

In addition to classifying the device node type, we also differentiate between local and remote device nodes. A local device node is one that is owned by the modeled system, whereas a remote node is owned by another system. In her power window, Emily chooses to have three local device nodes:
  • Motor—an actuator that is smart.

  • Switch—a sensor that is E/E.

  • DoorModule—an ECU that is smart.

  • DoorInline—an interconnect that connects the wiring from the main body harness to the door harness and that is a power device node.

In addition to the local nodes, Emily has two remote device nodes: the BCM (body control module) and the EC (electric center). The BCM is an ECU that is shared among all body-domain systems, including the power window, and the EC is a fuse box that acts like a main power source for the car.
Fig. 6

Modeling of data connectors at different levels of abstraction. The lowest level is shown on the left, where connectors are modeled between pins; the middle shows connectors between ports; the right is the highest level, where two device nodes are connected via a connector. The dashed selection shows the level of abstraction used for data and power connectors in this paper

The next part of the hardware architecture is the communication topology, which defines the physical media that function connectors are deployed to. The following hardware connectors make up the topology:
  • Discrete data connectors A connector used to indicate the status of a binary input, such as a switch. Figure 6 shows the different levels of abstraction for modeling hardware connectors. We chose to model them at the highest level (shown in the dashed box) to reduce model complexity; thus, we do not model ports or pins on a device node.

  • Analog data connectors A connector which sends an analog signal (as opposed to digital), typically encoded as voltage amplitude. This is also an abstract connector similar to the discrete data connector.

  • Bus connectors An abstract connector between two or more device nodes in which all connected nodes may pass messages; these are typically serial buses such as CAN [10] and LIN [23].

Figure 7 shows the communication topology Emily chooses to connect the device nodes. The smart nodes are connected together using the bus, and only the switch and BCM are connected via a discrete data connector.
Fig. 7

Power window communication topology

The last part of the hardware architecture we consider is the power topology, which models how device nodes are connected with power and in which we consider two types of power connectors:
  • Load Power Connector An abstraction for lower gauge wires that distributes higher power to device nodes. These connectors are often used to power motors, heaters, and lights.

  • Device Power Connector An abstraction for higher gauge wires that distributes lower power to device nodes. These connectors are often used to power smart devices.

As with the data connectors, we choose to model the power connectors with a high level of abstraction and disregard ports, pins, and routing through the wiring harness.
Fig. 8

Power window power topology

Figure 8 shows the power topology Emily models for her power window. Two load power connectors are used to provide the necessary voltage from the EC to the motor. Additionally, three device power connectors are used to connect the EC with the smart devices in the architecture. Even though the BCM is smart, device power is not modeled because the EC and BCM belong to other systems (shown as remote device nodes).

The last part of the system model is the deployment of the FAA to the hardware architecture, which is represented by the block arrow in Fig. 2. The analysis functions and functional devices are deployed onto device nodes, whereas function connectors are mapped onto the different communication topology connectors.

The deployment step may result in different allowed topologies and node classifications. For example, in Emily’s power window, the communication topology only defines a discrete connector between Switch and BCM as well as the Switch being E/E. Therefore, the function WinArbiter has to be deployed to the BCM if WinSwitch is deployed to the Switch. This is the only correct deployment because the reference model does not support deploying a single function connector to more than one hardware communication medium.

2.2 Reference model perspectives

Until this point, Emily has only defined a single candidate architecture for her power window. In order for her to model multiple candidates, variability (also known as degrees of freedom [7]) has to be expressed in the model. First, Emily adds variability to the feature model in which the express features are made optional and the feature expressUp is only present if the feature express is (c.f. Fig. 3b). Just by adding variability at the feature level, Emily now has three possible candidates. Adding variability to the feature expressUp results in having optional functions and connectors which are used to implement the feature. Figure 9 shows the resulting variable functional analysis architecture in which the PinchDetectionFAA is optional; which implies all contained functions and connectors are optional as well (PositionSensor, position, PinchDetection, and object). Emily can also express variability in how a function is implemented; for example, in Fig. 9 Emily chooses to have WinArbiter be implemented in either hardware or software.
Fig. 9

Power window FAA with variability. Optional components are shown by a dotted border/line. “HW/SW” indicates the function can be implemented in either software or hardware

Additionally, variability can be expressed in the mapping of the FAA to the hardware architecture by allowing more than one valid deployment for a function to a device node or a function connector to a communication topology connector. We also consider variability for the type of device node in the device node classification. For example, Emily might have two types of Switch device nodes she can use in the system, either a smart or an electric/electronic one. Furthermore, variability can be expressed over the presence of a device node in the classification; such as the DoorModule being optional in the resulting candidate architectures. Lastly, the communication and power topologies can contain variability in the presence of connectors or in the case of a bus connector, the type of bus (i.e., LIN, CAN, or FlexRay). By adding variability to each of the layers in the power window model, Emily can end up modeling an exponential (in the number of variation points) number of candidate architectures. With adding variability to each individual layer, Emily also does not need to enumerate manually the complete variable configurations of the system; instead, she can simply add variations to individual components.

In order to evaluate the candidates based on metrics such as mass and cost, Emily must define qualities for the components of the different layers. When considering the mass, part unit cost, and part warranty cost of an architecture, we only assign values at the hardware architecture layer as it represents the physical elements in the architecture; we do not consider other costs in our model. Therefore, the components that add to the total mass and cost of a system are device nodes, power connectors, and communication connectors.

The last perspective that we define in this paper is for the latency of a system. We do this through timing chains—a sequence of executing functions with their communication as defined in the FAA. With the latency of a system being modeled, timing requirements such as end-to-end latency—the time taken to reach a target function from some source function—or input synchronization latency—the maximum difference in time taken to reach a target function from more than one source function. For the power window, Emily could model the timing requirement that the time taken from the function WinSwitch to function WinMotor is less than 500 ms.

In this work, we consider a simple latency model where schedulability and complex equations (such as the recurrence relation for worst-case transmission delay [17]) are not modeled. Instead, we assume the deployment of functions to nodes to be schedulable, and they are scheduled in a way to avoid any bus arbitration (no blocking times). Such a model is sufficient for very early exploration. We consider the following components to contribute to the latency of a system:
  • Functional device and analysis function a base latency is specified by the user. If the function is implemented in software, the base latency represents the latency a function is expected to take at some base ECU speed factor. If the function is implemented in hardware, the base latency is simply the hardware specification latency.

  • Function connector a size is specified by the user to represent the size of the message being sent. Then based on whether the function connector is deployed and to what type of hardware connector, the latency is calculated using the transfer rate of the hardware connector.

  • Device node a speed factor can be given to the device node which affects the resulting latency of deployed analysis functions.

  • Discrete/analog data connector the latency is assumed to be zero in our model.

  • Bus connector the transfer rate is dependent on the type of bus, which then affects the deployed to function connectors.

In the next section, we characterize the different design specifications, for exploration, that can be constructed for a model built using our reference model, such as Emily’s power window.

3 Characterizing the possible design scenarios

For Emily, building an architectural model of her system has provided no exploration benefits, yet. However, the model represents all possible candidate designs; being able to ask or query for a subset of them based on some decisions would provide such a benefit. Making design decisions is routinely done throughout the early stages of design. For example, Emily might need to decide whether having a dedicated ECU on each door is a cost-effective solution while meeting some high-level requirements such as end-to-end latency or mass. While making a decision is quite simple (i.e., Emily could just flip a coin), the challenge is finding the possible remaining candidates, which satisfy the high-level requirements and the model constraints when the decision is made. Additionally, if more than one decision is made (i.e., Emily chooses to have the dedicated ECU and have the feature expressUp), which is often done, it may be challenging to determine whether a candidate design is possible.

Another benefit Emily could reap from building the architectural model is comparing two or more sets of candidates. While an argument could be made that this comparison could be done manually (i.e., it is intuitive that adding a dedicated ECU will be of higher cost than not), it is limited to comparing a single candidate from each set. Consider the example shown in Fig. 10 in which Emily is trying to compare designs with a dedicated door ECU and designs without such an ECU. Doing this manually would require generating, by hand, a candidate for each design choice (shown as black circles in the figure) and then comparing them one at a time (shown as the red-rounded rectangles). Using the architectural model and a supporting reasoner, all candidates for both design decisions could be synthesized and the sets of architectures could be compared at one time (shown as the blue-rounded rectangle). Then, since we are comparing sets, we can group candidates by part cost values to show if there exists any candidate with the dedicated ECU which costs less than any without.
Fig. 10

Illustration of comparing candidate designs for different sets of architectures using a manual versus an automated model-based approach

Furthermore, Emily could ask for a comparison between only optimal candidates. This would allow her to compare the candidates with minimal part costs when either design decision holds. Doing this optimization manually would not be practical, unless the number of candidates is small; by considering all layers of the reference model, a reasoner would also produce candidates that are globally optimal rather than locally within only one or two of the layers.

In the following subsections, we first give example exploration scenarios using design decisions that Emily, or another engineer, might make for the power window model built using the reference model. Secondly, we generalize the decisions, constraints, and objectives that can be reasoned about for any model constructed using the reference model from Sect. 2. This generalized set of decisions covers a subset of the possible degrees of freedom and qualities that are captured by the reference model.

3.1 Possible design exploration scenarios

For the power window that Emily is designing, we give several design scenarios in which Emily would like to explore the possible designs based on her model using a set of decisions, constraints, and objectives.
  1. 1.

    Emily would like to investigate the possibility of adding a dedicated ECU to each door (we call the door module). Precisely, she would like to find out whether it is a cost-effective solution while meeting the requirements for mass and latency.

     
  2. 2.

    Suppose that Emily has made a set of decisions which captures the architecture of her company’s previous generation power window system. Now, she would like to know whether it is possible to implement the express up feature on the previous generation architecture while satisfying latency constraints. If so, she would like to find out what designs they would be.

     
  3. 3.

    Emily would like to compare having a dumb architecture which uses electric/electronic switches and motors versus a smart architecture where they are smart. She would like to explore optimal designs of both to see how they compare in respect to the qualities: mass, parts costs, and part warranty cost.

     
  4. 4.

    Emily is tasked with designing the power window for a higher-end car in which cost is irrelevant but mass should be minimized, she would like to explore the possible designs. Additionally, since it is a high-end car, all features should be included. Lastly, the end-to-end latency for pinch detection to react and reverse the motor should be less than 200 ms.

     
  5. 5.

    Emily would like to minimize the cost, regardless of the features, to support an “economy class” vehicle her company is rolling out. Is there an optimal car design that does include all features?

     
  6. 6.

    Emily is investigating whether it would be better in terms of all qualities (latency, mass, parts cost, and part warranty cost) to have a distributed architecture, when considering multiple power window systems (i.e., the driver and passenger doors), or a centralized one.

     
By using the reference model, we described in the previous section, Emily can construct a model that can be used in each of these scenarios. This is possible because of the layers we consider along with the cross-cutting perspectives. By modeling from the features down to the power and communication topology, Emily can consider the comprehensive impact of making decisions. Also, she is able to make decisions since each layer is augmented with a variability perspective, and thus, she can consider adding or removing elements, such as a feature or device node. In the next subsection, we formally state the set of design decisions, constraints, and objectives that can be expressed over any model using the reference model in order to explore the possible candidate architectures.
Table 1

A set of design decision templates based on the reference architecture model

Reference model concept

Design decision template

ID

Features

Feature X <is|is not> present in the system

DD1

Functions and connectors

Function X is deployed to device node(s) Y(1) or Y(2) or ...Y(m)

DD2

Function X <is|is not> present in the system

DD3

Function connector X <is|is not> present in the system

DD4

Function X is implemented in<hardware|software>

DD5

Function connector X is provided <to|from> function(s) Y(1) or Y(2) or ...Y(m)

DD6

Device nodes

Device node X is <smart|electric/electronic|power>

DD7

Device node X <is|is not> present in the system

DD8

Power connectors

<Load|Device> power connector X <is|is not> present in the system

DD9

The <load|device> power connector X is provided <to|from> device node(s) Y(1) or Y(2) or ...Y(m)

DD10

Communication connectors

<Bus|Discrete|Analog> connector X <is|is not> present in the system

DD11

Function connector X does not use any hardware connectors to communicate

DD12

Function connector X uses connector(s) Y(1) or Y(2) or ...Y(m) to communicate

DD13

Bus connector X is of type <LIN|Low Speed CAN|High Speed CAN|FlexRay>

DD14

The <bus|discrete|analog> connector X has device node(s) Y(1) or Y(2) or ...Y(m) as endpoints

DD15

3.2 Generalizing the possible design exploration scenarios

As we saw in the previous section, design-space exploration entails exploring resulting candidates when certain decisions are made, constraints are held, and objectives are optimized. Before we state what possible decisions, constraints, and objectives, one can make when using the reference model, we first define what design exploration is and its defining elements as follows:
  • Design-Space Exploration The activity of discovering and evaluating design alternatives, captured by design specifications, during system development (adapted from [25]).

  • Design Specification A set of one or more design decisions, constraints, and objectives joined together by Boolean logic formed over a architectural model to specify the desired candidate architectures.

  • Design Decision A restriction on the variability allowed by one or more components in the modeled architecture.

  • Design Constraint A restriction on the value for a system or component quality in the modeled architecture such as mass or latency.

  • Design Objective An optimization goal to maximize or minimize a system quality in the modeled architecture.

Table 2

A set of design constraint templates based on the reference architecture model

Quality attribute

Design constraint template

ID

Timing (end-to-end latency)

The timing chain latency X must be less than or equal to Y

DC1

The maximum difference for timing chain latencies X(1), X(2), ..., X(n) must be less than or equal Y

DC2

Timing (margin)

The margin between timing chain latency X and the required latency Y must be greater than or equal to Z

DC3

For all margins between the timing chain latencies X(1), X(2), ...X(n) and the requirement latencies Y(1), Y(2), ...Y(n) the minimum must be greater than or equal to Z

DC4

Mass

The total mass of the system must be less than or equal to Y

DC5

The mass of X must be less than or equal Y

DC6

The sum of mass for components X(1), X(2), ...X(n) must be less than or equal to Y

DC7

Part cost

The total cost of the system must be less than or equal to Y

DC8

The cost of X must be less than or equal to Y

DC9

The sum of cost for components X(1), X(2), ...X(n) must be less than or equal to Y

DC10

Warranty part cost

The total parts warranty cost of the system must be less than or equal to Y

DC11

The parts warranty cost of X must be less than or equal to Y

DC12

The sum of parts warranty cost for components X(1), X(2), ...X(n) must be less than or equal to Y

DC13

Table 3

A set of the design objective templates based on the reference architecture model

Quality attribute

Template design objectives

ID

Timing (margins)

<Maximize|Minimize> the margin between the timing chain X end-to-end latency and the requirement latency of Y

DO1

<Maximize|Minimize> the<smallest|largest> margin between the timing chain(s) X(1), X(2), ...X(n) end-to-end latency(s) and the requirement latency(s) Y(1), Y(2), ...Y(n)

DO2

Mass

<Maximize|Minimize> the total mass of the system

DO3

Parts cost

<Maximize|Minimize> the total cost of the system

DO4

Warranty parts cost

<Maximize|Minimize> the total parts warranty cost of the system

DO5

We consider two classes of design-space exploration scenarios. The first class uses a single design specification. Scenarios 2, 4, and 5 from the previous section fall into this class. A common example of this class would be causal analysis where a certain specification is made in order to observe the resulting possible candidates. The second class uses multiple design specifications. Comparative analysis would be a common example of this class where two or more sets of designs (captured by design specifications) are compared. Scenarios 1, 3, and 6 from the previous section fall into this class.

In order to analyze the set of exploration scenarios afforded by the reference model, we first characterize the range of possible specifications. This, in turn, requires characterizing the possible decisions, constraints, and objectives. We achieve this goal using specification templates.

Table 1 contains the templates that express a subset of all possible design decisions that can be made when using the reference model and first-order logic. The parameters X and Y in each of the templates are names of elements such as features, functions, and devices, present in the model. In the templates, we capture all possible presence variability for the elements (DD1, DD3, DD4, DD8, DD9, DD11). Additionally, device nodes and bus connectors have associated types (DD7, DD14), functions have implementation decisions (DD5), and connectors have endpoints that can be variable (DD6, DD10, DD15). Lastly, the deployment can also be variable with respect to function and their connectors (DD2, DD12, DD13). This is a subset because we do not capture arbitrary Boolean formulas between the deployment of a set to another in this characterization; however, note that Clafer can express arbitrary Boolean expressions. In Sect. 4, we show how to express these design decisions in our implementation.

Table 2 contains the templates for a subset of all design constraints that can be made when using the reference model. The constraints that we consider are simple inequalities that involve individual values or sums of mass, part cost, part warranty cost (DC5–DC13), and latency for end-to-end latency (DC1, DC3). Input synchronization (DC2, DC4) additionally uses maximum of a set of values. The parameter X in the templates is a quality associated with an element such as a device node mass or the latency of a timing chain, and parameters Y and Z are numbers.

Table 3 then shows a subset of the possible design objectives that can be captured when using the reference model. Parameter X is a quality associated with an element, as in the previous table, and parameter Y is a number. Although Clafer allows using arbitrary numeric expressions as objectives, we only focus on the subset in the table. The objectives that we consider are additive with respect to the mass, part cost, and part warranty cost as well as timing margins. We define total mass as the summation of mass for all elements (that define mass). Total part cost and total part warranty cost are defined in a similar manner.

In order to combine the design decisions, constraints, and objectives together to form design specifications, we use a workflow diagram shown in Fig. 11. The design decisions and constraints are joined together using Boolean operations. In the next subsection, we demonstrate how these templates can be used to build a set of design specifications to explore a concrete model constructed using the reference model.
Fig. 11

A workflow diagram for combining design decisions, constraints, and objectives together to create a design specification

3.3 Example design exploration using templates

Returning to Emily’s hypothetical design exploration scenarios in Sect. 3.1, we can now use the templates to form a set of specifications to be used in the exploration. As an example, we use scenario 4:

Emily is tasked with designing the power window for a higher-end car in which cost is irrelevant but mass should be minimized; she would like to explore the possible designs. Additionally, since its a high-end car, all features should be included. Lastly, the end-to-end latency for pinch detection to react and reverse the motor should be less than 200 ms.

This exploration requires just one design specification which includes one decision for wanting all features (i.e., having the feature expressUp), one constraint for the latency requirement, and one objective for minimizing the mass. Using template DD1, we can write the design decision as “Feature expressUp is present in the system,” which we abbreviate with a shorthand notation as DD1(expressUp, is). This notation replaces the arguments inside the parentheses with the configurable parameters in the template, in the same order as they appear. The design constraint “The timing chain latency PinchDetection_TC must be less than or equal to 200 ms” can then be written as DC1(PinchDetection_TC, 200 ms) in shorthand notation, where PinchDetection_TC is the latency for a timing chain constructed from the PositionSensor functional device to the WinMotor (Fig. 9). Lastly, the design objective can be written as “Minimize the total mass of the system”; DO3(Minimize) in shorthand notation.

We construct the design specification by combining the instantiated templates use the flow diagram in Fig. 11 “Feature expressUp is present in the system AND the timing chain latency PinchDetection_TC must be less than or equal to 200 ms AND Minimize the total mass of the system” or “DD1(expressUp, is) AND DC1(PinchDetection_TC, 200 ms) AND DO3(Minimize)” in shorthand notation.

In a different scenario, Emily may want the latency of pinch detection to be met only if the feature expressUp is present. This conditional design specification can be constructed using an implication between the two decisions as follows: “Feature expressUp is present in the system IMPLIES the timing chain latency PinchDetection_TC must be less than or equal to 200 ms” or “DD1(expressUp, is) IMPLIES DC1(PinchDetection_TC, 200 ms)” in shorthand notation.

4 Encoding the reference model using Clafer

In the previous sections, we defined a reference model for early design and showed a subset of the possible design specifications that can be formed over a design-space model built using the reference model from Sect. 2. In this section, we present how to encode the reference model and design-space models (models built using the reference model) using Clafer [3] in order to support the design specifications from Sect. 3.

Clafer is a lightweight, general-purpose, structural modeling language [9]. Clafer is supported by a backend reasoner that generates instances from Clafer models. Clafer compiler translates an input Clafer model into the input language of each backend reasoner, and the reasoner can generate instances according to three search strategies (smallest first, largest first, and random) or according to optimization criteria (Pareto-optimal instances given many optimization objectives).

Listing 1 shows an example Clafer model we use to explain the main language constructs. A Clafer model consists of “clafers,”4 which offer the modeling capabilities of classes, attributes, references, features, and feature groups, all integrated into a single language construct. Clafers are organized in a containment hierarchy (specified using indentation): Clafers can contain nested clafers, similarly to how classes can contain other classes and attributes (e.g., the clafer Person5 contains hasLicense). Clafers are also organized in an inheritance hierarchy (specified using :), like classes, with a restriction that only abstract clafers can be superclafers (e.g., John inherits from Person). Each clafer defines a set of instances, similarly to how a class defines a set of its instances (objects). The set of instances of a clafer is a subset of instances of its superclafer. The number of instances of a clafer per instance of its parent is restricted by clafer multiplicity (e.g., 0..1 for hasLicense, 1..1 for John, or 0..* for Person; ? is a shorthand for 0..1). A clafer can be one of two types: abstract or concrete, similarly to classes (e.g., Person is abstract, whereas John is concrete). A concrete clafer results in instances being generated, while an abstract one does not. The number of instances of the children of a clafer is specified using group cardinality (e.g., in line 9, the keyword xor specifies an exclusive or group, which requires exactly one instance of the children of transmission). By default, clafers have the group cardinality of 0..*, that is, they do not impose any constraints on their children. Also, the default multiplicity of a clafer is 1..1 if the clafer is nested under a clafer with the default group cardinality 0..*, otherwise it is 0..1. Instances of reference clafers (specified using ->) can point to primitive values or other instances (e.g., driver in line 12 is an optional reference clafer modeling that a car may or may not have a driver). An instance of driver points to exactly one instance of Person; however, an instance may not be present since driver is optional). Finally, the model contains constraints (specified using square brackets [ . ]) which express additional restrictions on model instances. The constraints are Boolean formulas required to hold for every instance of their context clafer (the clafer the constraint is nested under). The constraint language in Clafer is a first-order logic, including Boolean, quantified, arithmetic, and set expressions (e.g., in line 4, the constraint specifies that the clafer hasLicense has one instance per instance of John; in line 13, the constraint specifies that the target of the reference driver must contain an instance of hasLicense; in line 16, the constraint specifies that the set of instances of driver of JohnsCar point to the set of instances of John; in line 15, the constraint specifies that each instance of JohnsCar contains one instance of automatic and it showcases explicit navigation this.transmission.automatic).

After removing the inconsistent JanesCar, the model from Listing 1 has exactly two possible instances shown in Listings 2 and 3 because the transmission type of the ParkedCar is left underspecified (in the first instance, ParkedCar has an automatic transmission, whereas in the second instance it has a manual transmission). For readability, we omit the instance number suffix if there is only one instance of a given clafer (in Listing 2, we have instances automatic$1 and automatic$2; however, in Listing 2, we have automatic, which is the only instance of the clafer automatic).

For an overview of the Clafer language and its constructs important to encoding the reference model and the case studies, the reader should refer to [35, 39]. Formal semantics of Clafer [9] and other resources [3] are also available.

4.1 Encoding of reference model layers in Clafer

Using the language support for variability, when the reference model is encoded, there is no longer a separate variability model as there is with current EAST-ADL modeling tools. Thus, Fig. 12 shows a unified view of the early reference model diagram. The unification symbolizes that the variability, and other perspectives are present in the Clafer encoding of each of the layers.
Fig. 12

A unified view of the reference model used for early design of automotive E/E systems architecture

Next, we describe the implementation of each of the reference model layers in Clafer as well example use cases in the context of Emily’s power window.

The encoding for the feature model layer is shown in Listing 4. It defines two abstract clafers, FeatureModel and Feature, for feature model and feature, respectively. Neither clafer has quality attributes since they are not expressed at the feature model layer (as shown in Fig. 12).
Using these components, Emily can model her feature model (with variability) in Clafer as shown in Listing 5. With nesting, Emily is able to model the implication between the features express and expressUp and expressDown. Note that anytime clafer multiplicity is not shown it is assumed to be 1..1 by default.
Using optional multiplicity (0..1) for features, we support design decision DD1 (Feature X<is|is not> present in the system).
To encode the FAA layer, we define abstract clafers for analysis function, functional device, and function connector (Sect. 2). Listing 6 shows how we use inheritance, denoted by a colon (lines 12, 13) to model common “properties” or attributes of analysis functions and functional devices in a common super clafer FunctionalAnalysisComponent. Design decisions DD3 and DD4 (Function/Function connector X<is|is not> present in the system) are possible, similar as with features, by using optional multiplicity when declaring the function or connector; this can be seen on line 8 of Listing 7, which is a fragment of Emily’s power window FAA. For design decision DD5 (Function X is implemented in<hardware|software>), we capture the two alternatives using mutually exclusive group cardinality (xor) on line 4 of Listing 6. Note that in Clafer constraints are enclosed in brackets.
To capture the deployment of functions and function connectors to the hardware architecture, we need a relation between the two. This relation is captured using the reference deployedTo on lines 3 and 18 of Listing 6 (denoted by ->). In Clafer, a reference can also be given a multiplicity, which allows for a reference to point to a variable size set of targets. Furthermore, consider the constraint on line 4 of Listing 7; one can loosely restrict that the target of a reference must be in a set of possibilities. Thus, an instance of WinControl would be deployed to either DoorModule or Switch. This mechanism supports the design decision “Function X is deployed to device node(s) Y(1) or Y(2) or ...Y(m)” (DD2). Further, since the endpoints of a function connector are references, it supports the decision “Function connector X is provided<to|from> function(s) Y(1) or Y(2) or ...Y(m)“ (DD6).

Additionally, constraints nested in the reference model concepts ensure that each use of the concept must satisfy the constraints (for a satisfiable instance). For example, the constraint on line 9 of Listing 6 enforces that functions implemented in software are deployed to a device whose type (a child clafer of DeviceNode in Listing 8) must be smart. Note, the . operator navigates to the target of a reference or to a child of a clafer (see [9] for the full semantics).

In order to augment the FAA layer with the latency perspective, we explicitly define a latency property (captured by a child integer reference clafer) for functions and function connectors (lines 11 and 22 of Listing 6). Currently, the Clafer backend reasoner is limited to working with integer values so all quality attributes have to be modeled using integers only. The constraints on lines 7, 10, and 24 along with the clafer baseLatency enforce the relationships between latency and hardware factors, as we described in Sect. 2. Recall that a designer only typically specifies the base latency for a function; however, since Clafer is a constraint language, the designer can also leave the base latency of one or more functions unspecified and to be determined by the underlying solver.

The device node classification layer encoding is shown in Listing 8, where a device node has multiple properties to express mass, part cost, part warranty cost, and type. Design decision DD7 (Device node X<is|is not> present in the system) is afforded by using multiplicity 0..1 (i.e., optional) when declaring the node. The target of reference type on line 6 of Listing 8 must be one (by the multiplicity 1..1) of the types from the set DeviceNodeType. The set contains three possibilities: smart, electric/electronic, and power (Listing 8, line 2). This forms a mutually exclusive selection, identical to using an xor group cardinality as done for the implementation choice for a function; thus, supporting the design decision “Device node X is of type<smart|electric/electronic|power>” (DD7)

Mass, cost, ppm (part per million), replacement cost, and speed factor are all specified by the system designer. The part warranty cost is then constrained to be the number of failures per million (ppm) multiplied by the replacement cost, shown on line 10 of Listing 8.

Listing 9 shows part of the device node classification for Emily’s power window, containing the nodes Switch and DoorModule. In order to show the variability that Emily has both a smart and electric/electronicSwitch, we can use the constraint on line 3, which has identical form as a variable deployment constraint. Additionally, to express that the device node DoorModule is optional, a cardinality of 0..1 is expressed on line 9. Also take note that quality attribute values do not have to be assigned to one possible value by the modeler: On line 7, it shows how the device node type can be used to select between two values for ppm.

For the power and communication topologies, we need an encoding for the different types of connectors. Similar to the FAA layer encoding, we use inheritance in Listings 10 and 12 to model the various connectors and capture similar properties.

Using constant integer values such as Data.MassPer Length.LoadPowerConnector, the total mass and cost of the different connectors can be computed given their length. Both the load power connector and device power connector define a source and sink reference, which allow the endpoints of the connectors to vary. Similar to before, these references allow design decision DD10 (“The <load|device> power connector X is provided <to|from> device node(s) Y(1) or Y(2) or ...Y(m)”), and the presence variability can be captured via cardinalities, allowing for DD8 (“<Load|Device> power connector X<is|is not> present in the system”).
Using the clafers from Listing 10, Emily can express a fragment of her power topology for the motor in Listing 11. The fragment shows the device power connector for the motor, that is optional, and is present if and only if the device node Motor is smart. It also shows the load power connector for the motor (the connector source is not shown).
Listing 12 shows the communication topology modeled in Clafer, which consists of multiple data connectors that we introduced in Sect. 2. Recall that the discrete and analog data connectors were abstractions; in order to improve the accuracy of cost and mass, the constraint on lines 7 and 9 shows how the number of function connectors deployed to a hardware connector is used to represent the number of connectors in the bundle. Similar to power and function connectors, the endpoints of a data connector are references; however, the encoding allows for two or more endpoints to support the design decision DD15. Further, we support four types of common buses, where each has a different mass per length, cost per length, and transmission rate. This encoding uses a group cardinality, similar to the function implementation encoding, allowing the design decision “Bus Connector X is of type<LIN|Low Speed CAN|High Speed CAN|FlexRay>” (DD14). Lastly, the function connector deployment is modeled similar to functions (DD13), with the exception that it can be optional, supporting design decision DD12.

Listing 11 shows a fragment of the communication topology for the power window. The fragment shows two alternatives, in which the device nodes Motor and DoorModule can be connected at the hardware level. The selection of the alternatives is based on the constraints on line 11 of Listing 12, which enforces that all device nodes used as endpoints for the bus connector have to be smart. Therefore, if the device node Motor is smart, then the bus will be used, otherwise the discrete wire will be synthesized.

In the following subsection, we show an example for how element-level qualities can be aggregated to support the design constraints and objectives from Sect. 3. Additionally, we include an example for joining multiple decisions, constraints, and objectives together, in accordance with the earlier workflow diagram.

4.2 Using Clafer to model a simplified power window

Recall from Sect. 3 that many of the design constraints and objectives were a summation of component values such as device node masses or function latencies. To showcase how these constraints and objectives can be written in Clafer, we simplify Emily’s power window. We do so by showing the WinControl and WinMotor functions, with their connection, and two device nodes, DoorModule and Motor, as well as the possible media that connect them. Listing 13 shows the Clafer model for this simplified architecture.

Using the simplified model, we model a timing chain latency by adding the latency values of WinControl, WinMotor, and winCmd as shown on line 1 of Listing 14. Then using the timing chain, we encode the design constraint “The end-to-end latency for timing chain X must be less than or equal to Y” (DC1) on line 2 of Listing 14. Similarly, if we wanted to minimize the total mass of the architecture, as in DO3, we would need to sum up the device node and hardware connector masses. Line 3 shows how we can define a total mass, and line 4 then shows the Clafer encoding to minimize the value. Lastly, our example specification could state that we do not want the WinControl function to be deployed to the door module. This can be done using the quantifier no, as shown on line 5. The result of this specification would be an instance including only the motor, which is smart to contain the WinControl function, and no discrete data connector.

4.3 The supporting reasoner and tools

Chocosolver6, a part of the Clafer toolchain, compiles the model written in the Clafer modeling language down to a set of variables and constraints from the Choco7 constraint programming library [38]. Constraint programming is a powerful paradigm from artificial intelligence for performing search efficiently over a large search space. The Choco library is a notable open-source constraint programming implementation which has won awards in the past three MiniZinc challenges (2013, 2014, 2015). Chocosolver extends the Choco library to handle Clafer-specific features, such as reasoning over relational logic and multi-objective optimization. Any solution in the Choco domain gets mapped back to a solution in the Clafer domain.

For performing multi-objective optimization, we implemented the guided improvement algorithm (GIA) [24], which returns exact optimal solutions one by one. Early termination of the GIA optimization results in a partial Pareto-front in which the solutions are exact unlike in many other algorithms which return an approximation of the Pareto-front when terminated early (the solutions are approximate and it is not known how far they are from the exact ones). Finally, in GIA, all optimization objectives are treated as equally important, that is, we do not reduce the multi-objective optimization problem into a single-objective one by assigning weights to the objectives. Treating the objectives equally is very important in our work because it allows us to explore the trade-offs among design decisions without having to assign arbitrary weights to the objectives.

Chocosolver explores the search space for solutions by incrementally assigning variables in hope of finding a complete solution. After each assignment, the solver performs propagation by using the currently assigned variables to deduce the values of other variables, thus pruning the search space. If the solver detects that the current assignment of variables precludes all complete solutions, it will backtrack to an earlier state by unassigning some of the variables. This systematic backtracking search can be done efficiently by a combination of optimized data structures, efficient propagation of constraints, and effective search heuristics.

The solutions, or candidate architectures in our context that chocosolver finds can then be visualized using Clafer Web Tools [8, 36], another part of the Clafer toolchain. Clafer Multiple-Objective Optimization (MOO) Visualizer is one of the web tools that allows for visualizing optimal candidates using bubble front charts and parallel coordinate charts. Additionally, the candidates can be filtered using the feature quality matrix in order to visualize only ones that contain certain features, functions, deployments, etc.

5 Evaluation

We had three main objectives for evaluating the use of the reference model and Clafer and its supported tool chain to synthesize and explore automotive E/E architectures:
  1. 1.

    Comparison to state-of-the-art tools

     
  2. 2.

    Role of multiple layers

     
  3. 3.

    Performance evaluation

     
Then, to meet these objectives we formulated a set of research questions, which are as follows:
  • RQ1 What aspects of our reference model are unique and not found in current meta-models for E/E architecture or are found but not supported by reasoning?

  • RQ2 What exploration scenarios that are supported by the presented reference model and Clafer encoding are not possible with other existing reference models and tools?

  • RQ3 Does considering a subset of the layers from our reference model, when exploring the candidate architectures, produce different candidates in comparison with when considering all layers? If so, how different are these sets of candidates?

  • RQ4 Is it feasible to explore the individual design decisions, constraints, and objectives put forth in Sect. 3 for realistic models? We define feasible as the ability for the reasoner to find the first 10 non-optimal solutions in less than 10 min and the first 10 optimal solutions within 45 min. We want to obtain a handful of instances within minutes to enable quick iterations for engineers, and therefore, we pick 10 instances in 10 min. We give a higher time budget to optimization since it is a harder problem; we pick 45 minutes since waiting for hours would seriously slow down the exploration process.

  • RQ5 Is it feasible to explore the example design scenarios we presented in Sect. 3 using realistic power window models?

The first two research questions target our first objective: comparing Clafer to state-of-the-art tools. The third research question focuses on the second objective, whereas the last two are centered around evaluating the performance of using Clafer and its supported tools. In the following section, we outline our methodology for each objective. We follow it up with our findings for each research question.

5.1 Research methodology

As a part of our research methodology, we modeled two automotive E/E architectures in the body domain: a power window system and a central door locks system. We chose to model these two systems as they are self-contained and provide a rich design space to explore potentially interesting trade-offs. Additionally, for the power window system, we considered two variants: single door (the driver side door) and two door (the driver and front passenger doors).

We studied service documents of several car brands including GM, Ford, Nissan, Toyota, and BMW in order to come up with possible design alternatives. We provide the full details for both models in an accompanying technical report [39]. The report details the different layers of the architectures, the associated variability, and the quality attributes for both systems. Additionally, it provides the full encoding of both systems in Clafer using the reference model from Sect. 4. The full models are available in a GitHub repository.8

5.1.1 Comparison to state-of-the-art tools

To compare using Clafer and its supported tool chain to state-of-the-art tooling, we first conducted a literature review. We searched journal and conference proceedings in the following digital libraries: IEEE Xplore, Google Scholar, Elsevier Science Direct, Springer Digital Library, and ACM Digital Library. The literature was collected using the following set of keywords: E/E architecture, architecture modeling, design-space exploration, optimization, and tool support. From the gathered literature, we selected only tool-supported approaches targeting architectural modeling and design exploration for automotive E/E systems and similar domains, such as avionics, railway systems, building and factory automation, and oil and gas exploration.

Using the selected tools, we then attempted to model the single-door variant of the power window system. Next, we attempted to explore the models using the Clafer supported decision, constraint, and objective templates from Sect. 3. For each template, we determined whether it was natively possible, meaning without changing the tools’ original capabilities, and commented why.

5.1.2 Role of multiple layers

To investigate the role of multiple layers in design-space exploration, we systematically applied the following procedure:
  1. 1.

    Remove one of the following from the single-door power window design-space model: feature model, power topology, or communication topology. Additionally, remove all dependencies to the removed layer from the remaining layers.

     
  2. 2.

    Identify the quality attributes associated with the removed layer.

     
  3. 3.

    Write a design specification that minimizes mass, part cost, and part warranty cost qualities. Additionally, constrain the end-to-end latency for the timing chain constructed from the switch to the motor to be less than 500 ms. Gather the resulting instances for the single-door power window design-space model that has a layer removed (step 1) and the given specification.

     
  4. 4.

    Gather the resulting instances for the complete single-door power window design-space model and the given specification.

     
  5. 5.

    Compare the identified quality attributes, from step 2, for both sets of instances (steps 3 and 4).

     
We did not consider removing the functional analysis architecture or device node classification since the remaining information would not be sufficient for meaningful exploration.

5.1.3 Performance evaluation

To evaluate the performance of exploring realistic models using Clafer, and its supported tool chain, we use the power window and central door locks system design-space models as benchmarks. In order for readers to appreciate the size and complexity of the models, Table 4 shows the number of concrete components for a given reference model element, number of deployment configurations (for functions to device nodes), and number of possible candidates. For the concrete components, we give how many contain presence variability; that is, the component may or may not exist in the synthesized architecture.
Table 4

Number of concrete components for each reference model element, number of deployment configurations, and number of possible candidates for each design-space model

 

Single-door power window

Two-door power window

Central door locks

Features

3 (2)

6 (4)

7 (6)

Analysis functions

3 (1)

6 (2)

3 (2)

Functional devices

4 (1)

9 (2)

33 (15)

Function connectors

6 (2)

7 (4)

33 (18)

Device nodes

6 (2)

10 (3)

21 (14)

Discrete/analog connectors

13 (13)

18 (18)

34 (30)

Bus connectors

1 (1)

2 (1)

2 (1)

Power connectors

8 (6)

16 (12)

9 (5)

Deployment configurations

64

4096

96

Possible architectures

32,000

959,714,800

2028

(n) denotes that n of the concrete components have presence variability

Table 5

Size of Clafer encoding for each model

 

Reference model

Single-door power window

Two-door power window

Central door locks

Abstract clafers

25

8

8

6

Concrete clafers

66

85

114

195

Constraints

64

161

211

444

References

50

33

47

28

The design-space model numbers are reported minus the reference model elements

Table 6

Details for selected state-of-the-art tools to compare with Clafer

Tool Name

Version Used For Evaluation

Description

Targeted Domain

Tool Released to Public?

Sources

ArcheOpterix

Not Provided

A tool that supports modeling software components, communication between software components, ECUs, buses, and services. Additionally, the tool can optimize the deployment of software components to ECUs using objectives such as redundancy allocation, energy consumption, and cost

Automotive E/E Architecture

Yes

[1, 6, 30, 31, 32, 33, 34]

AutoFOCUS—AF3

2.9

A model-based development tool that supports architecture modeling from the requirements to code generation. Additionally, the tool can synthesize hardware platform architectures, given a functional architecture based on objectives such as end-to-end latency and number of nodes. The tool is also able to synthesize and explore optimal deployments and schedules

Automotive E/E Architecture

Yes

[2, 41, 42]

OSATE

2.2.1

A model-based development tool that implements the AADL (architecture analysis & design language), and supports modeling both aerospace and automotive systems. It does not have any optimization support; however, it supports model checking, schedulability analysis, and flow latency analysis

Automotive/ Aerospace E/E Architecture

Yes

[5, 18]

AAOL

N/A

A domain-specific constraint language used for modeling and optimization of automotive E/E architectures. The supporting tool can optimize based on user-defined objectives, and support design constraints, such as memory capacity, ASIL requirements, and predefined deployments

Automotive E/E Architecture

No

[27]

For the number of possible candidate architectures, expressed by the design-space model, we were able to run the reasoner and find all solutions for both the single-door variant of the power window and for the central door locks. The reasoner was run with no latency constraint specified. For the two-door variant, we estimated the number of possible solutions using the single-door variant and taking into account the allowed feature variants between the two doors (i.e., the passenger door cannot have the feature express if the driver door does not).

Table 5 gives statistics for encoding the models in Clafer. The table indicates a large number of constraints for the central door locks model in comparison with both variants of the power window model. As a result of the constraints, there are significantly fewer possible candidate architectures as seen in Table 4.
Table 7

Limitations we encountered when modeling the single-door variant of the power window system introduced in Sect. 2

 

ArcheOpterix

AutoFOCUS—AF3

OSATE

AAOL

Feature Model

The tool did not allow for modeling the features of the system

The tool did not allow for modeling the features of the system

The tool did not allow for modeling the features of the system

The tool did not allow for modeling the features of the system

FAA

The design-space model had to contain a fixed FAA. There was no distinction between functional devices or analysis functions, and only software components were considered. It was also not possible to model functions implemented in hardware

The design-space model had to contain a fixed FAA. There was no distinction between functional devices or analysis functions, and only software components were considered. It was also not possible to model functions implemented in hardware

The design-space model had to contain a fixed FAA. There was no distinction between functional devices or analysis functions, only processes and threads were considered

The tool made no distinction between functional devices or analysis functions

Device Node Classification

The design-space model had to contain a fixed hardware architecture including its type. Also, e/e and power devices could not be modeled, all nodes were considered smart

The design-space model had to contain a fixed hardware architecture, including its type. When using the generated hardware architecture, it was not possible to model node qualities. Lastly, power devices could not be modeled

The design-space model had to contain a fixed hardware architecture. The device node classification was not entirely separate from the FAA since the switch and motor were devices—an AADL concept representing an actuator or sensor—and could be used in both layers. Lastly, power devices could not be modeled

The tool did not consider power devices

Power Topology

The tool did not allow for modeling distribution of power from sources to devices

The tool did not allow for modeling distribution of power from sources to devices

The tool did not allow for modeling distribution of power from sources to devices

The language did not allow for modeling distribution of power from sources to devices

Comm. Topology

The tool did not allow for variable communication media

The tool did not allow for variable communication media. Additionally, the tool did not consider discrete/analog connectors

The tool did not allow for variable communication media. Additionally, the tool did not consider discrete/analog connectors

There were no limitations in modeling this layer

Deployment

The tool did not allow for modeling restrictions on deployments for function connectors to hardware data connectors

The tool did not allow alternatives to be specified for deployments of a software components connector. Additionally, deployment of software components to E/E devices was disallowed

There were no limitations in modeling this layer

The tool did not allow for modeling a restriction for what set, size greater than 1, of buses a software component could produce traffic on

Objectives & Constraints

The tool did not consider mass and part warranty cost as objectives. Also, no end-to-end latency or input synchronization constraint could be specified

The tool did not consider mass, part cost, or warranty part cost as objectives. No end-to-end latency or input synchronization constraint could be specified

The tool did not support optimization over any objective. Constraints for part cost, mass and warranty part cost were also unsupported

The input synchronization constraint could not be expressed in the tool

Using these models as benchmarks, we constructed two experiments for research questions RQ4 and RQ5. In the first experiment, we measured the time taken to find the first 10 instances for each of the design decision, constraint, and objective templates. However, we did not test each one with each of its possible parameters due to the exponential number of combinations. Rather, we tested each decision using a single selection of parameters (i.e., either the device was chosen to be smart or EE, not both); for constraints and objectives, we only tested one of the mass, part cost, and part warranty cost constraints due to their similar nature. We did, however, test each of the latency constraints with a single selection of the parameters. For both the single- and two-door variant of the power window model, the same parameters were selected for the template specification.

The time to find the first 10 instances was measured ten times, and the average, standard deviation, and number of instances found was recorded. A timeout was reported if the first 10 instances could not be found in 10 min or under, for the non-optimal specifications, and 45 min or under for the optimal specifications. If a timeout occurred, the number of instances found before time expired was reported. As mentioned earlier, we wanted to obtain a handful of instances within minutes to enable quick iterations for engineers, and therefore, we pick 10 instances in 10 minutes. We gave a higher time budget to optimization since it is a harder problem; we pick 45 min since waiting for hours would seriously slow down the exploration process.

The second experiment measured the time taken to find the first 10 instances for each of the example power window design specifications found in Sect. 3. For each of the multiple design specification scenarios (1, 3, and 6), we split the scenario into multiple specifications and measured the solving time individually. Additionally, for scenario 6, we do not consider the single-door power window model as a distributed vs. centralized trade-off is not applicable to a single window. Lastly, both experiments were carried out on a laptop with the following specs:
  • Intel® Core™ i7-3520M CPU @ 2.90 GHz

  • 4.00 GB RAM

  • Windows 10–64 bit

5.2 Comparison to state-of-the-art tools

We selected four tools, as a result of our literature review, to compare with Clafer. The description, version used in the evaluation, and other relevant details are provided in Table 6.

For ArcheOpterix, AutoFOCUS—AF3, and OSATE, we modeled the power window system (the single-door variant) up to what was supported by the tool. For AAOL, the tool was not publicly available so it was not possible to recreate the power window. Instead, the evaluation was done using the published details about the language and case study, a four door power window [27].

When modeling the single-door variant of the power window system, we developed a single domain-space model (as we did with Clafer, c.f.  [39]) for the system. For example, in ArcheOpterix a single domain-space model consisted of one XML file containing the model elements and their qualities. If variability for a certain element could not be captured, we did not consider the possibility of creating a second XML file with the new variant since the underlying reasoner accepted a single file. In the context of AF3, a single domain-space model consisted of one component architecture and one platform architecture. For OSATE, we considered a single-system implementation to be one domain-space model as the analyzers worked only with one implementation at a time. In AAOL, we consider a single domain-space model to consist of a single set of constraints, objectives, and orders; however, since the constraints can be written over a set of software architectures and hardware architectures we allow for multiple of both.

Table 7 shows the limitations we encountered when modeling using each of the tools. The resulting models are available together with the Clafer models.9

5.2.1 Research question 1

Using Table 7, the unique elements, along with a short explanation for each, are as follows:
  • Feature model and features Feature models and features were not explicitly a part of any reference model; however, in AADL there is a concept, feature, but it does not match our definition from Sect. 2. Rather, an AADL feature is used to model the incoming and outgoing data for a process, thread, or device.

  • Power Topology The distribution of power from sources to devices was not considered by any of the tools.

  • Power Devices None of the tools allowed modeling a device for relaying or distributing power, such as the door inline in the power window.

  • Deployment of Function Communication None of the tools allowed restricting the possible targets for which a function connector should be deployed, while taking account both buses and discrete/analog connectors.

While our reference model does contain unique elements not found in the surveyed tools, we also want to state that the surveyed tools contain elements not found in our reference model. For example, we do not consider energy consumption, bus reliability, memory capacity, or schedulability; these could be incorporated in future work.

5.2.2 Research question 2

Table 8 shows our findings for what decision templates are supported, indicated by a “Yes” in the table, by each of the surveyed tools. If the decision was not supported, we listed one of two reasons for why:
  1. 1.

    The template pertained to a model element that was not supported by the tool.

     
  2. 2.

    The tool could not capture the variability associated with the model element in the template.

     
Table 8

Supported (Yes) and unsupported (No) decision templates for each of the surveyed tools

ID

ArcheOpterix

AF3

OSATE

AAOL

DD1

No (1)

No (1)

No (1)

No (1)

DD2

Yes

Yes

Yes

Yes

DD3

No (2)

No (2)

No (2)

Yes

DD4

No (2)

No (2)

No (2)

No (1)

DD5

No (1)

No (1)

No (2)

No (1)

DD6

No (2)

No (2)

No (2)

No (1)

DD7

No (1)

No (1)

No (1)

No (1)

DD8

No (2)

No (2)

No (2)

Yes

DD9

No (1)

No (1)

No (1)

No (1)

DD10

No (1)

No (1)

No (1)

No (1)

DD11

No (2)

No (2)

No (2)

Yes

DD12

No (2)

No (2)

Yes

No (1)

DD13

No (2)

No (2)

Yes

No (1)

DD14

No (1)

No (1)

No (1)

No (2)

DD15

No (2)

No (2)

No (2)

Yes

If the decision is unsupported, one of the following reasons is listed: (1) Model element not supported. (2) Variability not captured

Table 9

Supported (Yes) and unsupported (No) constraint and objective templates for each of the surveyed tools

ID

ArcheOpterix

AF3

OSATE

AAOL

DC1

No (1)

No (2)

Yes

Yes

DC2

No (1)

No (2)

No (2)

No (2)

DC3

No (1)

No (1)

Yes

Yes

DC4

No (1)

No (1)

No (2)

No (2)

DC5

No (1)

No (1)

No (1)

Yes

DC6

No (1)

No (1)

No (1)

Yes

DC7

No (1)

No (1)

No (1)

Yes

DC8

No (2)

No (1)

No (1)

Yes

DC9

No (2)

No (1)

No (1)

Yes

DC10

No (2)

No (1)

No (1)

Yes

DC11

No (1)

No (1)

No (1)

Yes

DC12

No (1)

No (1)

No (1)

Yes

DC13

No (1)

No (1)

No (1)

Yes

DO1

No (1)

No (1)

No (2)

Yes

DO2

No (1)

No (1)

No (2)

No (2)

DO3

No (1)

No (1)

No (1)

Yes

DO4

No (2)

No (1)

No (1)

Yes

DO5

No (1)

No (1)

No (1)

Yes

If unsupported, one of the following reasons is listed: (1) Quality not supported (2) Expression not supported

Table 10

Resulting quality attribute values when removing portions of the power window model (single-door variant)

Removed portion

Associated quality attributes

Number of instances

Quality attribute values

Mass (g)

Parts cost ($)

Warranty parts cost ($ per million)

Margin latency (ms)

None

Mass, parts cost, warranty parts cost, margin latency

9

837

223

6452

440-445

Feature Model

None

6

837

223

6452

44-445

Power Topology

Mass, parts cost

41

{813,811}

{221,223}

{6452,10852}

{440–445,439–445}

Communication Topology

Mass, parts cost, margin latency

9

833

222

6452

440–445

The margin latency is for the timing chain from the switch to the motor. The margin latency value is given as a range denoting the smallest and largest values for the reported instances. We use the curly braces to denote an ordered set of values when more than one set of values exists on the Pareto-front

Fig. 13

A screenshot of the bubble front graph produced by ClaferMooVisualizer when exploring the candidate architectures without the power topology

Table 9 shows the supported constraint and objective templates, indicated with a “Yes” in the table, for each of the surveyed tools. As with the decisions, we listed one of two reasons for why the template was unsupported:
  1. 1.

    The template considered a quality attribute that was not supported by the tool.

     
  2. 2.

    The template contained a quantifier or optimization objective that was not supported by the tool.

     
Both tables show that none of surveyed tools are able to capture all decisions, constraints, and objectives that are possible when using Clafer.

In summary, the difference between Clafer and the compared tools is: Clafer synthesizes the valid candidate architectures based on a set of constraints and objectives, and allows modeling variability at all layers. The compared tools, ArcheOpterix, OSATE, and AF3, only allow for variability in the deployment of functions to device nodes. AAOL is limited by the elements considered in the language, rather than being able express variability as evident from Table 8. However, expressing the presence variability for components such as functions and device nodes required defining multiple software and hardware architectures to be used by the solver.

5.3 Role of multiple layers (research question 3)

In Table 10, we show the results of our experiment in removing the feature model, power topology, and communication topology from the single-door variant of the power window system model. Each row of the table shows the resulting quality attribute values when minimizing mass, part cost, and warranty part cost, while ensuring a end-to-end latency of 500 ms from the switch to the motor.

From the table, we found that the feature model layer does not play a role in the qualities, which we expected since no quality attributes were captured in this layer; however, the feature model layer contributed additional candidate architectures that were possible. The power topology, we found, did affect the mass, part cost, and warranty part cost. Furthermore, by removing the power topology, a trade-off was introduced, meaning that two sets of candidate architectures existed on the Pareto-front with differing quality attributes, this can be seen in the bubble front graph in Figure 13.
Table 11

Design decision and constraint solving time for three case study models

Design spec.

Single-door power window

Two-door power window

Door locks

Solving time (s)

SD (s)

Number of instances

Solving time (s)

SD (s)

Number of instances

Solving time (s)

SD (s)

Number of instances

DD1

6

0.6

10

20

1.4

10

314

7

10

DD2

6

1.2

10

20

1.9

10

91

2.2

10

DD3

6

0.3

10

21

3.3

10

315

7.8

10

DD4

6

0.3

10

20

2.8

10

476

7.9

10

DD5

6

0.2

10

20

2.1

10

93

1.4

10

DD7

5

0.1

10

19

1.3

10

313

9.2

10

DD8

6

0.8

10

503

16.4

10

317

8.1

10

DD9

5

0.4

10

18

1.2

10

27

1.5

10

DD10

6

0.3

10

20

1.3

10

94

2.3

10

DD11

6

0.4

10

17

2.2

10

32

2.2

10

DD12

6

0.3

10

19

1.3

10

101

1.6

10

DD13

6

0.7

10

19

2.9

10

96

4.2

10

DD14

6

0.9

10

18

1.0

10

33

3.4

10

DD15

21

1.1

10

Timeout

0

92

5

10

DC1

5

0.5

10

17

2.5

10

93

1.5

10

DC2

6

1

10

18

2.5

10

94

2.4

10

DC3

6

0.9

10

20

2.3

10

94

2.7

10

DC4

6

0.6

10

19

2.4

10

94

4.6

10

DC5

6

0.8

10

19

1.9

10

116

3.7

10

DC6

6

0.9

10

19

1.2

10

92

3.1

10

DC8

7

1

10

19

2.0

10

339

4.8

2

A timeout is reported if the solver takes more than 10 min to find the first 10 non-optimal solutions

The two sets of values are captured by curly braces in Table 10. This shows the importance of including the power topology in the overall model, as it eliminates designs that are not optimal when considering the full model. Lastly, by removing the communication layer, we found the values for mass and part cost were reduced. This was expected since less of the model is present; however, it was interesting to see no difference in the margin latency. The reason for this is due to the loss of precision when working with integers to represent smaller quantities.

5.4 Performance evaluation

5.4.1 Research question 4

Table 11 contains the results from running our outlined experiment on the design decision and constraint templates. The results show that for the single-door variant of the power window and the door locks models, all sample templates tested for each of the decisions and constraints were considered feasible. The two-door variant, however, did experience limitations in which one of the templates was not feasible. DD15 experiences a timeout because by requiring certain devices to communicate via the bus it increases the possible deployment targets for function connectors on both doors. We see this design decision that experiences scalability issues since this decision is more challenging for the single-door variant, as well, evidenced by taking 3.5 times longer, on average, than the other decisions.
Table 12

Design objective solving time for three case study models

Design Spec.

Single-Door Power Window

Two-Door Power Window

Door locks

Solving time (s)

SD (s)

Number of instances

Solving time (s)

SD (s)

Number of instances

Solving time (s)

SD (s)

Number of instances

DO1

2690

0

10

Timeout

0

Timeout

0

DO2

Timeout

0

Timeout

0

Timeout

0

DO3

59

1.5

9

Timeout

0

314

9.7

1

DO3, DO4, DO5

56

1.2

9

Timeout

0

Timeout

1

A timeout is reported if the solver takes more than 45 minutes to find the first 10 optimal solutions

Table 13

Design exploration scenario specification solving time for the power window case study models

Scenario

Single-door power window

Two-door power window

Solving time (s)

SD (s)

Number of instances

Solving Time (s)

Std. Dev. (s)

Number of Instances

1—With ECU

176

2.7

10

93

3.2

0

2—No ECU

24

0.4

10

Timeout

0

2

6

0.3

10

20

1.8

10

3—Smart

86

3.6

10

Timeout

0

3—Dumb

26

0.8

6

Timeout

0

4

26

0.6

3

Timeout

0

5

25

1.1

10

Timeout

0

6—Centralized

0

Timeout

0

6—Distributed

0

Timeout

0

A timeout is reported if the solver takes more than 10 min to find the first 10 non-optimal solutions and more than 45 min to find the first 10 optimal solutions

Table 12 shows the results from executing the same experiment as before, but for the optimization templates. From the table, we see that each model does experience some limitations in performance. Observing the different specifications, we see that DO1 and DO2 (optimization over the latency qualities) have by far the worst performance. Additionally, we see that as the models grow in the amount of variability (the two-door variant encodes over 959 million variants opposed to roughly 32 thousand for the single door), it is no longer feasible to optimize with respect to one or more objectives. As the models grow in size (the door locks contains over 133 concrete elements), we find the design decision and constraint specifications, on average, take longer than in the smaller models (36 concrete elements for the single power window and 70 for the two-door power window); however, they are all still feasible. Future work is needed to investigate techniques to improve the scalability in order for all optimization and decision templates to be considered feasible. In particular, we ran the experiments on stock hardware, and our implementation of optimization is not parallel despite GIA being well-suited for parallelization. Furthermore, the reasoning over Clafer models naturally benefits from all performance improvements achieved in the underlying Choco library.

5.4.2 Research question 5

From Table 13, we see that again it is feasible to ask all design exploration scenarios for the single-door variant of the power window. For the two-door variant, we see that only one out of the six scenarios are feasible. The reason for this is related to our earlier observation that due to the encoding of the large number of variants, the chocosolver is unable to feasibly find the first 10 optimal instances for single or multiple objectives. Therefore, we find that it is feasible to ask Emily’s design scenarios only if we are considering a smaller model such as the single-door power window which still encodes roughly 32 thousand candidate architectures.

6 Threats to validity

Research Questions 1 and 2 In our comparison to state of the art, we have two main threats to validity; the first being an incomplete literature review. We mitigated this threat by consulting multiple search engines, in addition to using a prior systematic literature review by Aleti et al. [7].

The second threat is a potential bias in our expertise with Clafer opposed to the compared state-of-the-art tools. It is to the best of our knowledge that our attempted models of the power window are accurate and demonstrate the full capabilities of the tool, in the scope of design-space exploration, as we have consulted with tutorials, user guides, and published works for each tool. However, in future work the threat could be further mitigated by having an expert, for each tool, carry out the exercise of modeling and exploring the power window.

Research Question 3 The main threat to validity for the third research question is the sensitivity of quality attribute values used in the comparison between the original and partial design-space models. We were able to partially mitigate this by using real-world quality attribute values found from OEM part supply stores, reliability handbooks, and other online shopping sites such as Amazon. Since Clafer, currently, can work only with integer values, a loss of precision was introduced when encoding these values. In the accompanying technical report [39], we detail how the values are scaled.

Research Questions 4 and 5 We have three main threats in our evaluation of performance for Clafer. The first is a lack of full coverage for the decision, constraint, and objective templates tested in the first experiment. We were able to mitigate this threat by ensuring we covered each of the decision templates, and each objective at least once. In the experiment, not all constraints were tested since mass, parts cost, and part warranty cost all had the same expression, but with different values. Additionally, not all parameters were tested for research question four, and a bias could have been introduced for the choice of parameters selected. We attempted to mitigate this threat by choosing similar parameters between each of the tested models; however, future work could be done to measure the sensitivity of the selected parameters. For the attribute values, we also ensured that at least 1 instance would be found, such that we did not report a trivially unsatisfiable result.

The second threat is a bias toward the current implementation of Clafer and its supported tool chain, the release 0.4.3. Since Clafer and its tools are continually evolving over time, our results may become invalid; however, the results are valid for the chosen release.

The last threat is the use of a CSP-based solver, chocosolver, opposed to a possibly more suitable one such as an SMT or ILP solver. We chose to use a CSP over SMT solver since our earlier work of encoding Clafer models to the SMT solver Z3 resulted in a worse performance compared to chocosolver. In particular, the Clafer backend using chocosolver has been optimized using custom constraint propagators, which are not available in SMT. However, a more efficient encoding of Clafer to SMT might have achieved better performance and should be investigated, along with an efficient encoding to ILP, in future works. Furthermore, a direct encoding of the case studies to SMT or ILP was not considered since one of the objectives of this work was to create high-level models.

7 Related work

7.1 Survey of architecture optimization

In 2013, Aleti et. al. [7] conducted a survey of the current literature in the area of architecture optimization. In the review, they considered not only embedded systems but also information systems. Many of the works surveyed are related to ours; however, in this section we highlight works with the most decisions, constraints, and objectives.

From the survey, we found the most design decisions (also known as degrees of freedom or points of variability) simultaneously considered by any work, in the embedded systems domain, was four [13, 14, 37]. These works considered degrees of freedom such as allocation, component selection, hardware selection, software selection, software replication, hardware replication, and scheduling. In our work, we consider additional degrees of freedom (c.f. Table 1); however, we do not take into account software or hardware replication.

From the survey, we found the most qualities considered in optimization, in the embedded systems domain, was four. This was work by Dave and Jha [16], in which they optimized the allocation of a hierarchal task graph to hardware, and its schedule with respect to performance, cost, reliability, and energy. In our work, we consider a simplified set of optimization objectives using mainly aggregation; however, we consider 15 degrees of freedom in our optimization, while Dave and Jha only consider three.

Lastly, we found that many of the works considered constraints over qualities such as performance, cost, reliability, energy, safety, and weight. However, from the surveyed works, in the embedded systems domain, they only considered a handful of constraints; on the other hand, in our work we consider 13 different quality constraints.

7.2 Recent advances in E/E architecture evaluation and optimization

Li et. al. [28] presented a framework which takes as input an AADL model, using OSATE, and optimizes with respect to cost, processor utilization, and data latency. This framework is limited by only considering the removal or addition of a processor or bus to the system, allocation of services, and replacement between hardware components; compared to our work, which we take into account feature variability and variable types of physical media. As stated earlier in Sect. 5, Aleti et. al. [6] also used OSATE to create AADL models and then translated them to their optimization framework, ArcheOpterix, to optimize based on data transmission reliability and communication overhead using evolutionary algorithms. Our work differs by covering variability and multiple layers and also using an exact optimization method.

Zeller et al. [43] compared SAT-solving and different heuristic search algorithms, in which they do not optimize but rather synthesize a satisfying deployment given a set of constraints. The constraints they consider are timing, resource utilization, and schedulability. They do not optimize, or consider variable hardware topologies, analog/discrete wires for communication, nor quality constraints such as mass, part cost, and warranty parts cost.

Glaß et al. [20] optimized hardware topologies w.r.t. area cost, power consumption, and reliability using evolutionary algorithms. However, they do not consider variability in the functional architecture, which could potentially lead to different optimal topologies due to deployment based on what functions are present. Additionally, they only consider networked topologies, whereas in this work we consider both buses and discrete/analog connectors.

Lin et. al [29] considered the wire routing problem, in which they optimized w.r.t cost, which was dependent on wire selection, wire length, and number of splices used. This work goes into more detail of the wire selection and routing through the vehicle, which we disregarded given our focus on early design.

As stated in Sect. 5, Kugele and Pucea introduced AAOL in [27]. The case study used in their work was a power window system, similar to ours; however, ours considered more than two concrete designs. In our model, the single-door variant alone encoded over 36,000 different candidate architectures as a result of being able to augment architectural elements with variability.

Walla et al. [21] present a novel framework for early design exploration with respect to power consumption by ECUs. This work generates the inputs needed for their earlier work of simulating the power consumption and also provides some visualizations of the results. However, this exploration is less automated than ours since users have to clone a modeled E/E architecture and then make modifications to add differences. On the other hand, Clafer only models the structure of the architectures and does not support simulation or behavioral analysis.

In [19], Florentz and Huhn present meta-models to describe embedded systems architectures as well as an evaluation method. The case study used to demonstrate is similar to our power window model in which they consider two distinct variants and only two objectives: cost and performance. In comparison with our work, we provide an automated approach using a backend reasoner such that we can synthesize the candidates rather than having to explicitly model the variants.

Brandt et al. in  [11] present an optimization approach for cost of an automotive E/E architecture and consider variable deployments and number of ECUs. Unlike in our work, they consider a comprehensive cost metric including development and manufacturing costs. However, their work is not tool supported and does not consider optional functions as we do in our work.

In [40], Schäuffele presents PREEvision for E/E architecture modeling and optimization. PREEvision is a rich modeling environment that captures the architecture in a multilayered approach as we do in Clafer as well as multiple optimization objective such as weight and cost. While this work considers more layers (wire routing and layout), it does not model variability for architectural elements and consequently does not support synthesis of functional designs and device topologies; rather, the architectural variants to be compared have to be modeled explicitly.

Overall, these works only considered a limited amount of variability, only very few perspectives, and many did not consider the entire multilayer architecture when doing the optimization (from the features down to the hardware topology).

7.3 Extensions to previous work

This paper extends work previously done by Murashkin in [35] in the following ways:
  • Extended the original power window case study by adding:
    • Latency and warranty cost quality attributes;

    • Implementation choice in the definition of a analysis function and functional device.

  • Revised the original reference model by providing structure for the power and communication topology layers, adding the deployment of function connectors to hardware connectors, and adding quality attributes into the reference model;

  • Added a new case study model for a central door locks system;

  • Systematically characterized of the possible exploration scenarios using specification templates;

  • Evaluated the approach against five research questions;

  • Improved the scalability of the multi-objective optimization by optimizing the chocosolver in response to the experience with the case studies.

8 Conclusions

We presented a workflow using the Clafer modeling language and its supported tool chain to synthesize multi-level, multi-perspective candidate E/E architectures for two automotive body-domain sub-systems. Additionally, we defined a reference model that supports early design such that models can be created with limited amount of information. This work also allows for synthesizing candidates from a design-space model with variability at all layers of the E/E architecture (i.e., features, functions, and deployment) and not just deployment or a single layer as with many previous works. By considering all layers and augmenting elements with variability in each of them, we are able to synthesize globally optimal candidate architectures captured by the reference model. Furthermore, by using Clafer, we are able to synthesize candidates based on many types of design decision, constraints, and objectives to support much richer design exploration scenarios compared to other tools. Importantly, since the reference model is entirely encoded in Clafer, it can be easily tailored and extended for particular applications, which is not easy to do with specialized tools.

In the future, we would like to improve on the solving performance of chocosolver to make it feasible to construct and find solutions for models of larger size and variability. One possibility is to exploit the modularity of systems in the models, such that individual sub-systems are solved first and then the results are used to explore their composition. By improving the reasoner, larger and more intricate case studies can be explored such as combining the power window and door locks systems as well as modeling the remainder of the body domain. In addition, new perspectives such as safety, memory, and energy consumption should be added to the reference model to further enrich the design-space exploration possibilities.

Footnotes

  1. 1.

    Quality attributes are sometimes referred to as non-functional properties.

  2. 2.

    We use italics to introduce a reference model component.

  3. 3.

    We use typeface to denote Emily’s model elements; a concrete component.

  4. 4.

    Throughout this paper if the word Clafer begins with an uppercase letter it describes the language, whereas a lowercase one denotes the language construct.

  5. 5.

    We use bold typeface to refer to a clafer in a listing.

  6. 6.
  7. 7.

    As of this writing, we are using Choco version 3.

  8. 8.
  9. 9.

References

  1. 1.
    Archeopterix: http://users.monash.edu.au/~aldeidaa/ArcheOpterix.html. Last accessed 21 Feb 2017
  2. 2.
    Autofocus 3: http://af3.fortiss.org. Last accessed 21 Feb 2017
  3. 3.
    Clafer: http://clafer.org. Last accessed 21 Feb 2017
  4. 4.
    EAST-ADL domain model specification, version V2.1.12.: http://east-adl.info/Specification/V2.1.12/EAST-ADL-Specification_V2.1.12.pdf. Last accessed 21 Feb 2017
  5. 5.
    OSATE, version 2.: http://osate.org. Last accessed 21 Feb 2017
  6. 6.
    Aleti, A., Bjornander, S., Grunske, L., Meedeniya, I.: Archeopterix: An extendable tool for architecture optimization of aadl models. In: ICSE Workshop on Model-Based Methodologies for Pervasive and Embedded Software, 2009, MOMPES ’09. pp. 61–71 (2009)Google Scholar
  7. 7.
    Aleti, A., Buhnova, B., Grunske, L., Koziolek, A., Meedeniya, I.: Software architecture optimization methods: a systematic literature review. IEEE Trans. Softw. Eng. 39(5), 658–683 (2013)CrossRefGoogle Scholar
  8. 8.
    Antkiewicz, M., Bąk, K., Murashkin, A., Olaechea, R., Liang, J., Czarnecki, K.: Clafer tools for product line engineering. In: Software Product Line Conference (2013)Google Scholar
  9. 9.
    Bąk, K., Diskin, Z., Antkiewicz, M., Czarnecki, K., Wąsowski, A.: Clafer: unifying class and feature modeling. Softw. Syst. Model. 15(3), 811–845 (2016)CrossRefGoogle Scholar
  10. 10.
    Bosch Semiconductors: CAN literature. http://www.bosch-semiconductors.de/en/automotive_electronics/ip_modules/can_literature_2.html. Last accessed 21 Feb 2017
  11. 11.
    Brandt, L., Krämer, N., Metzger, J., Lindemann, U., et al.: Optimization approach for function-partitioning in an automotive electric electronic system architecture. In: DS 70: Proceedings of DESIGN 2012 (2012)Google Scholar
  12. 12.
    Broy, M.: Challenges in automotive software engineering. In: 28th International Conference on Software Engineering, pp. 33–42 (2006)Google Scholar
  13. 13.
    Coit, D.W., Smith, A.E.: Solving the redundancy allocation problem using a combined neural network/genetic algorithm approach. Comput. Oper. Res. 23(6), 515–526 (1996)CrossRefMATHGoogle Scholar
  14. 14.
    Coit, D.W., Smith, A.E.: Redundancy allocation to maximize a lower percentile of the system time-to-failure distribution. IEEE Trans. Reliabil. 47(1), 79–87 (1998)CrossRefGoogle Scholar
  15. 15.
    Cuenot, P., Chen, D., Gerard, S., Lonn, H., Reiser, M.O., Servat, D., Sjostedt, C.J., Kolagari, R., Torngren, M., Weber, M.: Managing complexity of automotive electronics using the EAST-ADL. In: 12th IEEE International Conference on Engineering Complex Computer Systems, 2007, pp. 353–358 (2007)Google Scholar
  16. 16.
    Dave, B.P., Jha, N.K.: Cohra: hardware-software cosynthesis of hierarchical heterogeneous distributed embedded systems. IEEE Trans. Comput.-Aided Des. Integr. Circuits Syst. 17(10), 900–919 (1998)CrossRefGoogle Scholar
  17. 17.
    Davis, R.I., Burns, A., Bril, R.J., Lukkien, J.J.: Controller area network (can) schedulability analysis: refuted, revisited and revised. Real-Time Syst. 35(3), 239–272 (2007)CrossRefGoogle Scholar
  18. 18.
    Feiler, P., Hansson, J.: Flow latency analysis with the architecture analysis and design language (AADL). Tech. Rep. CMU/SEI-2007-TN-010, Software Engineering Institute, Carnegie Mellon University, Pittsburgh, PA (2007). http://resources.sei.cmu.edu/library/asset-view.cfm?AssetID=8229
  19. 19.
    Florentz, B., Huhn, M.: Embedded systems architecture: evaluation and analysis. In: Proceedings of the 2nd International Conference on Quality of Software Architectures, QoSA’06, pp. 145–162 (2006)Google Scholar
  20. 20.
    Glaß, M., Lukasiewycz, M., Wanka, R., Haubelt, C., Teich, J.: Multi-objective routing and topology optimization in networked embedded systems. In: Embedded Computer Systems: Architectures, Modeling, and Simulation 2008, 74–81 (2008)Google Scholar
  21. 21.
    Graf, S., Glaß, M., Teich, J., Lauer, C.: Multi-variant-based design space exploration for automotive embedded systems. In: Proceedings of the Conference on Design, Automation and Test in Europe, DAT ’14, pp. 7:1–7:6. European Design and Automation Association (2014)Google Scholar
  22. 22.
    Han, K., Kwon, Y., Kim, W., Cho, J.: Distributed hierarchical service network for automotive embedded system. In: Information Networking (ICOIN), pp. 188–192 (2012)Google Scholar
  23. 23.
    ISO: Road vehicles–local interconnect network (LIN)—part 6: Protocol conformance test specification (2015). ISO/DIS 17987-6.2Google Scholar
  24. 24.
    Jackson, D., Estler, H., Rayside, D., et al.: The guided improvement algorithm for exact, general-purpose, many-objective combinatorial optimization (2009)Google Scholar
  25. 25.
    Kang, E., Jackson, E., Schulte, W.: An approach for effective design space exploration. In: Foundations of Computer Software. Modeling, Development, and Verification of Adaptive Systems, pp. 33–54. Springer (2010)Google Scholar
  26. 26.
    Kang, K., Cohen, S., Hess, J., Novak, W., Peterson, A.: Feature-oriented domain analysis (foda) feasibility study. Tech. Rep. CMU/SEI-90-TR-021, Software Engineering Institute, Carnegie Mellon University, Pittsburgh, PA (1990). http://resources.sei.cmu.edu/library/asset-view.cfm?AssetID=11231
  27. 27.
    Kugele, S., Pucea, G.: Model-based optimization of automotive E/E-architectures. In: Proceedings of the 6th International Workshop on Constraints in Software Testing, Verification, and Analysis, CSTVA 2014, pp. 18–29 (2014)Google Scholar
  28. 28.
    Li, R., Etemaadi, R., Emmerich, M.T.M., Chaudron, M.R.V.: An evolutionary multiobjective optimization approach to component-based software architecture design. In: Evolutionary Computation (CEC), pp. 432–439 (2011)Google Scholar
  29. 29.
    Lin, C.W., Rao, L., Giusto, P., D’Ambrosio, J., Sangiovanni-Vincentelli, A.L.: Efficient wire routing and wire sizing for weight minimization of automotive systems. IEEE Trans. Comput.-Aided Des. Integr. Circuits Syst. 34(11), 1730–1741 (2015)CrossRefGoogle Scholar
  30. 30.
    Meedeniya, I.: Architecture optimisation of embedded systems under uncertainty in probabilistic reliability evaluation model parameters. Ph.D. thesis, Swinburne University of Technology, Melbourne, Australia (2012)Google Scholar
  31. 31.
    Meedeniya, I., Buhnova, B., Aleti, A., Grunske, L.: Architecture-driven reliability and energy optimization for complex embedded systems. In: Proceedings of the 6th International Conference on Quality of Software Architectures: Research into Practice—Reality and Gaps, QoSA’10, pp. 52–67 (2010)Google Scholar
  32. 32.
    Meedeniya, I., Buhnova, B., Aleti, A., Grunske, L.: Reliability-driven deployment optimization for embedded systems. J. Syst. Softw. 84(5), 835–846 (2011)CrossRefGoogle Scholar
  33. 33.
    Meedeniya, I., Moser, I., Aleti, A., Grunske, L.: Architecture-based reliability evaluation under uncertainty. In: Proceedings of the Joint ACM SIGSOFT Conference—QoSA and Symposium—ISARCS on Quality of Software Architectures, QoSA-ISARCS ’11, pp. 85–94 (2011)Google Scholar
  34. 34.
    Montgomery, J., Moser, I.: Parallel constraint handling in a multiobjective evolutionary algorithm for the automotive deployment problem. In: 6th IEEE International Conference on e-Science Workshops, 2010, pp. 104–109 (2010)Google Scholar
  35. 35.
    Murashkin, A.: Automotive electronic/electric architecture modeling, design exploration and optimization using Clafer. Master’s thesis, University of Waterloo (2014). https://uwspace.uwaterloo.ca/handle/10012/8780
  36. 36.
    Murashkin, A., Antkiewicz, M., Rayside, D., Czarnecki, K.: Visualization and exploration of optimal variants in product line engineering. In: Software Product Line Conference (2013)Google Scholar
  37. 37.
    Nicholson, M., Burns, A., Dd, Y.: Emergence of an architectural topology for safety-critical real-time systems (1997)Google Scholar
  38. 38.
    Prud’homme, C., Fages, J.G., Lorca, X.: Choco3 Documentation. TASC, INRIA Rennes, LINA CNRS UMR 6241, COSLING S.A.S. (2014). http://www.choco-solver.org. Last accessed 21 Feb 2017
  39. 39.
    Ross, J., Antkiewicz, M., Czarnecki, K.: Case studies on E/E architectures for power window and central door locks systems (2016). http://gsd.uwaterloo.ca/node/667
  40. 40.
    Schäuffele, J.: E/e architectural design and optimization using preevision. Tech. rep, SAE Technical Paper (2016)Google Scholar
  41. 41.
    Voss, S., Eder, J., Schaetz, B. (eds.).: Scheduling Synthesis for Multi-Period SW Components. SAE Technical Paper 2016-01-0012 (2016). doi:10.4271/2016-01-0012
  42. 42.
    Voss, S., Schatz, B.: Deployment and scheduling synthesis for mixed-critical shared-memory applications. In: 20th IEEE International Conference and Workshops on the Engineering of Computer Based Systems (ECBS), 2013, pp. 100–109 (2013)Google Scholar
  43. 43.
    Zeller, M., Prehofer, C.: Modeling and efficient solving of extra-functional properties for adaptation in networked embedded real-time systems. J. Syst. Archit. 59(10), 1067–1082 (2013)CrossRefGoogle Scholar

Copyright information

© Springer-Verlag Berlin Heidelberg 2017

Authors and Affiliations

  • Jordan A. Ross
    • 1
  • Alexandr Murashkin
    • 1
  • Jia Hui Liang
    • 1
  • Michał Antkiewicz
    • 1
  • Krzysztof Czarnecki
    • 1
  1. 1.University of WaterlooWaterlooCanada

Personalised recommendations