Architecture Modeling - SPES 2020

Architecture Modeling
abstraction level, we identify all stakeholders impacting the design of the product and analyze
product requirements stemming from their interaction. Note that stakeholders include humans,
such as human operators, cabin crew, maintenance staff. In systems-of-systems applications,
stakeholders include interfaces to other systems (such as in car2X applications) or supervisory
control (such as to flight control).
A requirements analysis processes could, as final outcome, yield a formalized specification
of the interface between the product and its stakeholders, in terms of contract specifications, for
all aspects induced from operational and business requirements, which from then on take indeed
the form of binding requirements, whose realization must be traceably supported in subsequent
design steps.
At lower abstraction levels, the interfaces between identified stakeholders and the product
itself are refined, both in terms of representation of information and protocol.
We propose to use two perspectives to close the gap between the operational and the technical
perspective.
The first, functional perspective is used to refine our understanding in what it takes to realize
the product functions identified in the operational perspective. This is the scope of classical
functional analysis methods, using both hierarchy and abstraction layers to break down toplevel
functions to a level allowing a detailed assessment of their compliance to requirements
identified in the operational perspective. As functions are decomposed into subfunctions, requirements
on these (in terms of contracts) are identified. This is also the scope of classical
V&V approaches ranging from simulation to testing to formal verification for requirement validation
and verification.
The second perspective, called logical perspective, re-groups design entities of the functional
perspective such that locality in logical architecture corresponds to locality in the technical architecture.
As an example, consider the design of an advanced driver assistance system using
cooperative vehicle control strategies for highway entry, realizing a safe, smooth, and semiautonomous
highway entry. Subfunctions include multi-channel sensor fusion (video, ladar,
radar, wireless communication from roadside infrastructure and other vehicles) to build a mental
map of the actual traffic situation, real-time scenary analysis with motion estimation, strategy
determination, decision modules for invocation of semi-autonomous driving services such
as car-following, lane keeping, lane changing, driver interface, etc. Within the logical architecture,
leaves of the resulting function hierarchy would be regrouped to reflect the partitioning into
different subsystems of the car’s electronic architecture, where subfunctions with close proximity
in the functional architecture become separated e. g. due to the integration of the different
sensors in one subsystem, and stability control in another subsystem.
We suggest to refine the logical architecture to a level allowing to express the allocation of
entities of the logical architecture on computation and communication resources of the technical
architecture on a per-component basis. E.g. for the automotive domain this entails, that the
structure of a software component as being composed of runnables is visible in the logical
architecture, i. e. runnables appear as components.
Discussions in SPES have shown, that the number of abstraction levels can not be uniformly
determined for all application domains, but should be customizable for a given design process.
Much as in EDA design, abstraction layers are characterized by the components to be considered
primitive in the technical perspective, with other perspectives then containing components
as primitives which relate to such primitive components of the technical perspective. E.g. at
system level, we consider electronic control units as primitives in the technical perspective.
Counterparts on the logical perspectives are then software components, which map to tasks in
the technical perspective, such as those realizing control loops. A corresponding component in
71/ 156