Software-intensive embedded systems are characterized by an increasing number of features that implement complex functionalities. To e ectively manage this complexity, development processes in general, and model-based approaches in particular, support the development of such systems as model-based approaches have been considered a central design approach to deal with increasing complexity in software and hardware development. A valid system design and con guration, especially a safety-critical system design, has to ful ll a corresponding set of requirements describing all desired system constraints and objectives. In general, these constraints may be contradicting and correspond to di erent dimensions (e.g. timing, safety, energy, cost, etc.). Thus, considering all system constraints during system design is a manually unsolvable task. To support the system designer, usable Design Space Exploration methods are needed. Therefore, a proper tool implementation is needed that supports the usability. In this paper, we describe a Design Space Exploration process which aims to explore the architectural design space during system design. This process has been implemented in the open source CASE tool AutoFOCUS31 with the focus on usability.
Page 51 The design space of distributed embedded systems is characterized by an ever increasing number of features, like for example in automotive vehicles. Due to this growing complexity, the process of manually exploring possible designs for these systems is getting even harder for system designers. Therefore, a design space exploration process is needed, which guides the system designer in a semiautomatic way to explore possible design solutions.
In this paper, we describe such a semi-automatic Design Space Exploration process which has been implemented in AutoFOCUS3. AutoFOCUS3 is a CASE Tool that allows for seamless, model-based development of distributed, embedded systems.
The goal of our approach is to provide a usable Design Space Exploration (DSE) process, enabling the system designer to calculate, explore and compare di erent design alternatives during system design. These design alternatives satisfy all requirements (constraints) that are of interest for the system design. Naturally, such requirements are mostly contradicting. Due to this fact, a semiautomatic approach is proposed, where not only one single nal design can be calculated. In fact, it enables trade-o analysis by automatic generation of possible (optimized) design alternatives, that can then be evaluated by a system designer. 2
In this section, we will shortly introduce related work concerning this paper. On the one hand AutoFOCUS3 and some related case studies and on the other hand other existing DSE frameworks. 2.1
CASE tool AutoFOCUS3
AutoFOCUS3 is a scienti c CASE tool, which supports the development of
component based, reactive distributed embedded systems on di erent levels of
abstraction [
AutoFOCUS3 also provides a design space exploration process, which will be explained in more detail in the next section. 2.2
DSE frameworks There are a variety of widely used UML/SysML modeling tools like IBM Rhapsody, PTC Integrity, Enterprise Architect and Papyrus. Until now, they do not o er any design space exploration techniques. Research-wise however, there are a few frameworks existing, which o er DSE techniques.
Here we will mention two of them. There is e.g. the FORMULA framework [
The CoBaSA tool provides a language for expressing system constraints [
The di erence from AutoFOCUS3 to the tools mentioned above is that AutoFOCUS3 has a strong focus on usability. This entails, e.g., that the tool provides a user interface which is easy to use and understand. In particular, this means that the user is only exposed to as little formalism as possible, while still being able to use the power of these methods.
The AutoFOCUS3 Design Space Exploration Process
A usable, tool-supported DSE process starts with a pre-de ned model of the
system (e.g. using SysML [
Deployment The Deployment is the connection between logical and technical architecture. The components are deployed onto execution units, where their functionality will be executed. The communication between components, which are mapped onto di erent execution units, is deployed to a communication unit connecting these execution units.
Schedule A schedule adds timing information to a deployment. That means starting times and durations of components deployed on execution units and messages deployed on communication units.
Depending on the synthesis step, which will be explained in the next section, this system model may di er. A logical architecture model and a technical architecture model is needed in order to perform a deployment synthesis. For synthesizing schedules a deployment model is needed. 3.1
The DSE process
Based on these models, we propose a three fold DSE-process, as depicted in
gure 1:
1. Objective and constraint modeling: Consideration of so called
Exploration Targets (see also [
Constraints Objective and constraint modeling
System
Model Deployment Synthesis Schedule
Synthesis 3. Visualization: Calculated results are visualized in an (interactive) Visualization process step using di erent visualization techniques to support the system designer.
In the following, we describe these process steps in detail: 3.2
Objective and constraint modeling
The de nition of constraints and objectives is essential as they constrain the
design space and de ne cost-functions in order to optimize solutions. The process
of constraint modeling limits the set of possible solutions and is (often) derived
from system requirements, such as safety requirements which require certain
safety integrity levels (SIL) [
On the other hand, objectives describe a cost function which shall be optimized. These objectives can also be derived from requirements such as minimization of hardware costs (e.g. if it is required to have the least possible hardware costs), or of energy consumption (e.g. if the energy consumption of the whole system shall be kept as minimal as possible).
Therefore, AutoFOCUS3 provides a domain speci c modeling language
which enables the formalization of such constraints and objectives. Equation
1 shows an exemplary constraint, which states that if a software component
is mapped to a hardware component, the software component's SIL must not
exceed the hardware components SIL (see also [
8h 2 HW; 8s 2 SW; sw ! hw : s:sil h:sil
Equation 2 shows an exemplary objective which is a cost function over all hardware components ( nancial) costs, where at least one software component is deployed on. This function shall be minimized.
min(8s 2 SW
X 9h2HW :s!h h:cost) (1) (2)
To e ectively support the system designer, constraints and objectives are de ned on a visual basis through editors. These editors o er patterns for this language, in order to abstract the exact syntax and semantics of the language. These patterns are provided through the graphical user interface of AutoFOCUS3 and do not require any knowledge of formal languages. Figure 2 shows how equation 2 describing an objective is modeled in AutoFOCUS3. Constraints are modeled similarly. Among all constraints and objectives, sub-sets of constraints and objectives are de ned, in order to explore a certain design space exploration problem. Such a Sub-Set categorizes constraints and objectives modeled in the previous process step. The selection of desired subsets (compare gure 3) provides the input of the design space exploration problem under consideration.
The design space exploration process in AutoFOCUS3 provides synthesis mechanisms for deployment synthesis and schedule synthesis. We provide a symbolic encoding scheme, resp. a formalization describing the DSE problem as a satis ability problem using boolean formulas and linear arithmetic constraints. A state-of-the-art satis ability modulo theory (SMT) solver is used to compute design alternatives. We use the Z3 Theorem Prover by Microsoft 2.
If a synthesis process cannot nd any solutions, the user gets noti ed which sub sets and which constraints in these sub sets made it impossible to synthesize 2 https://github.com/Z3Prover anything. Thus it is possible to check if either the constraint itself was phrased wrong or if the requirement this constraint is derived from is wrong. Deployment synthesis The deployment synthesis enables the exploration of the design space of deployments from logical components to technical components. Deployment means, that the functionality represented by a logical component is executed as a task, on the speci c electrical control unit it is deployed on, at runtime.
Thus, this synthesis method needs, besides the constraint and objectives sub sets, models of logical component architecture and technical architecture as input. Given all these three artifacts one can explore design space of possible deployments.
Schedule synthesis The schedule synthesis enables the exploration of the timing behavior of a system. Given the input of a deployment (mapping) model (which could have been synthesized in the previous step), this mechanism synthesizes possible solutions of execution times of tasks and messages while considering given constraint and objective sub sets.
Visualization The last DSE process step is the visualization of the calculated design alternatives. According to the given objectives in the previous synthesis step the results can be displayed in a 3D visualization or spider chart (compare gure 4), where each axis can be assigned one objective. They may also be visualized in a table where each column displays one objective. For schedules a gantt chart is provided which displays the (timed) sequence of tasks and messages.
By using these visualization techniques, a system designer is supported to select the desired solution. This solution includes information (either deployment or schedule information, depending on the performed synthesis step), that can be transferred back into the system model.
Another iteration of the DSE process can then be performed if necessary. For instance, if one wants to explore the design space of possible schedules with a recently chosen deployment.
Furthermore, it is also possible to go one or even two steps back to alter the previous steps. Either to model new constraints and objectives and/or to adapt the constraint and objective sub sets which where used for synthesis. 4
In this paper, we have presented a Design Space Exploration process implemented in the CASE tool AutoFOCUS3. This process is in particular usable, due to the fact that it guides the system designer through all the required steps of a DSE. Moreover the process provides easy to use formalization methods, which do not require any knowledge in the eld of formalization.