Architecture Modeling - SPES 2020

Architecture Modeling
the design item. Often reducing the level of abstraction is accompanied by a refined granularity.
That is, the design items under consideration are decomposed into multiple finer grained items
in order to keep them at a manageable size. Refining the granularity is however not a necessary
condition, when introducing a lower level of abstraction. For example one may describe the
same design item on two different levels of abstraction with the same granularity, but precise
the specification of a certain aspect. Despite an increasing level of detail, another motivation for
introducing a dedicated abstraction level can be the handover of an initial system specification
to another organizational unit. Thus the initial specification can remain unchanged and on a new
abstraction level the model can be refined as well as the interface specifications of the components.
Realization(↑) links between component parts allow to trace those refinements. While
models on lower abstraction levels provide more detail, the components still have to respect the
aspects(↑) specified for their higher level counterparts.
For example, consider a logical architecture of an Adaptive Cruise Control (ACC) [32] modeled
by means of components as depicted in the upper half of Figure 2.4. The component Acc
is composed of a ForwardSensor that provides data about objects in front of a vehicle and a
Ctrl component that controls the distance between the ego-vehicle and those in front of it or
maintains a speed set by the driver (not shown in Figure 2.4) in case there are no other vehicles
detected.
Suppose that requirements in terms of aspect specifications formalized as contracts have been
specified for the component Acc and its sub-components. During a refinement step the component
Ctrl may be split up into multiple finer grained components, each realizing a dedicated
part of the Ctrl component and its specification. In the example three new components have
been introduced in the refined version of the Acc composition: A FollowCtrl component
that controls the distance between the ego-vehicle and those in front of it, a SpeedCtrl component
controling the speed set by the driver and an Arbitration component that chooses
between the acceleration outputs of both controlers.
Note that the entire interface of the RefinedAcc composition changed, as an output port
accStatus has been added, which is connected with a corresponding output port of the
FollowCtrl component. Therefore this design step cannot be captured by a simple decomposition.
Instead realization-links can be used to trace such refinement steps. The realization-link
relates component parts and also carries a set of attributes that allow to map ports owned by the
parts, which are involved in the realization relationship. In the example the Realize-link from
FollowCtrl to Ctrl would carry (amongst others) an attribute pointing to both ports named
speed of each component. In Section 4.4 we discuss the primitive design step of switching
abstraction levels by means of Realize-links and its semantic.
In discussions with industrial partners during the SPES project it became clear, that design
processes are very diverse for different domains like e. g. automotive and avionics. It depends
on the design process and the role of a company in the supplier chain, how many levels of
abstraction a system under development will undergo. In addition the domain specific terms
used for designs at a given level of abstraction vary. Therefore we cannot define a unique fixed
set of abstraction levels. Instead we consider a generic abstraction level concept, which can
be tailored to the specific needs of a company or an application domain and provide semantics
allowing to reason about realization between different abstraction levels.
2.2 Perspectives
Apart from the distinction of different user-defined abstraction levels, an abstraction level itself
contains a set of model representations, i.e. views(↑) of the system under development(↑).
7/ 156