Architecture Modeling - SPES 2020

1 Introduction
This document proposes a meta-model for architectures of embedded systems. The overall
scope taken is deliberately broad, aiming at covering multiple perspectives of embeddedsystems
based product development. As e. g. pointed out in [49], risk mitigation strategies
in product development require a holistic approach encompassing all sub processes and their
interfaces, hence requiring to cover the full range of what we call perspectives, from a geometric/physical
view of the product, to a view focusing on its technical architecture, to a view
elaborating its logical architecture, grouping functionality according to (sub-) system organisation,
to a purely functional perspective (getting the functional specifications right), and starting
with an operational perspective, focusing on interface requirements e. g. based on operational
scenarios. This separation of concerns by perspectives is complemented by offering abstraction
levels, as a well known principle to cope with complexity in system design. Hence design artifacts
can be placed in a two-dimensional design space, organized by perspective and level of
abstraction.
We enrich this generic approach by a component model largely derived from the concept of
Heterogeneous Rich Components (HRC)[20]. Specifically, this allows to provide rigorous interface
specifications for design artifacts residing in this two-dimensional design space. The term
“rich” alludes to the key ingredient of HRC components to provide (rigorous) interface specifications
for multiple what we call aspects, encompassing both functional and extra-functional
(e.g. safety and real-time) characteristics of components. Specifically, we propose the usage of
contract-based specifications, which allow, for each aspect, to characterize the allowed design
contexts of a component (through what we call strong assumptions) - violating these constitutes
an out-of-specification (“illegal”) usage of the component, thus “excluding liability”: no
guarantees of the component’s functional and extra-functional characteristics are given for such
illegal design contexts. For allowed design contexts, the guarantee part of the contract allows to
characterize both functional and extra-functional properties of the component. Often, these are
case-dependent; we support what we call weak assumptions structuring contract specifications
according to cases (thus refining the allowed design contexts).
Weak assumptions partition the context in which the system is intended to be used with
respect to its strong assumption. Hence, a single weak assumption defines only a part of the
allowed system context. With this, it is possible to define different use cases for a component. If
the context is able to ensure a weak assumption of a component, this component may guarantee
a more restricted behavior. Note, that the notion of weak assumptions does not adress operation
modes, which are switched during operation of the corresponding system.
We propose a formal pattern based specification language RSL for expressing both assumptions
and guarantees. RSL comes with patterns supporting multiple aspects of components;
within SPES we focus on modelling functional aspects, real-time aspects, and safety aspects.
We point out, that the notion of contract-based specifications is independent of the choice of the
concrete formal notation for expressing contracts. Indeed, contracts can as well be formalized
within other formal specification languages, such as AutoFocus [13], Live Sequence Charts
[16], PSL [2], Interface Automata [22], Real-Time Statecharts [26] etc.
Aspects of components can thus be rigorously specified through contracts. Their realization,
1/ 156