Architecture Modeling - SPES 2020

Architecture Modeling ∗
Andreas Baumgart, Eckard Böde, Matthias Büker, Werner Damm,
Günter Ehmen, Tayfun Gezgin, Stefan Henkler, Hardi Hungar,
Bernhard Josko, Markus Oertel, Thomas Peikenkamp, Philipp Reinkemeier,
Ingo Stierand, Raphael Weber
Thursday 10 th March, 2011
∗ The research reported here has been mainly performed in the project SPES2020 (www.spes2020.de/)
which is funded by the Ministry of Science and Culture. Also the projects CESAR
(www.cesarproject.eu/) and SPEEDS (www.speeds.eu.com/) had major influences on the results of
this work.

Architecture Modeling
©2011 OFFIS.
All rights reserved. Copyright Notice: This material is presented to ensure timely dissemination
of scholarly and technical work. Copyright and all rights therein are retained by authors or by
other copyright holders. All persons copying this information are expected to adhere to the
terms and constraints invoked by each author’s copyright. In most cases, these works may not
be reposted without the explicit permission of the copyright holder.

Contents
1 Introduction 1
2 Quick-Tour 4
2.1 Abstraction levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2 Perspectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3 Heterogeneous Rich Components . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3.1 Component Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3.2 Hierarchy and Composition . . . . . . . . . . . . . . . . . . . . . . . 13
3 The Architecture Meta-Model 15
3.1 Abstraction levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.2 Perspectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.2.1 Operational Perspective . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.2.2 Functional Perspective . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.2.3 Logical Perspective . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.2.4 Technical Perspective . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.2.5 Geometrical Perspective . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.3 Heterogeneous Rich Components . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.3.1 Component Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.3.2 Hierarchy and Composition . . . . . . . . . . . . . . . . . . . . . . . 40
3.4 Mapping Component Parts . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4 Steps in Component-Based Design 45
4.1 Formalizing Requirement Specifications with Contracts . . . . . . . . . . . . . 46
4.1.1 Functional Specifications . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.1.2 Real–Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.1.3 Safety . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.2 Virtual Integration Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.2.1 Compatibility and VIT Condition . . . . . . . . . . . . . . . . . . . . 54
4.2.2 Refinement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.2.3 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
4.3 Satisfaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
4.3.1 Establishing Functional Specifications . . . . . . . . . . . . . . . . . . 60
4.3.2 Establishing Real-Time Contracts . . . . . . . . . . . . . . . . . . . . 61
4.3.3 Establishing Safety Contracts . . . . . . . . . . . . . . . . . . . . . . 61
4.4 Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
4.4.1 Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
4.4.2 Allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
4.4.3 Realization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
iii

5 Using the Architecture Meta-Model 67
5.1 On the Role of Perspectives and Abstraction Layers . . . . . . . . . . . . . . . 67
5.1.1 What We Can Learn from the EDA Domain . . . . . . . . . . . . . . . 67
5.1.2 Perspectives and abstraction layers in system-level design . . . . . . . 70
5.1.3 Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
5.2 On the role of contracts in system development processes . . . . . . . . . . . . 93
5.2.1 Coping with complexity of systems . . . . . . . . . . . . . . . . . . . 93
5.2.2 Coping with the Complexity of the Supply Chain . . . . . . . . . . . . 100
5.2.3 Getting Initial Requirements Right . . . . . . . . . . . . . . . . . . . . 101
5.2.4 Coping with Multi-Layer Design Optimization . . . . . . . . . . . . . 103
5.2.5 Managing Risk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
5.2.6 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
6 Annex 108
6.1 Syntax and Semantics of RSL . . . . . . . . . . . . . . . . . . . . . . . . . . 109
6.1.1 Pattern specification . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
6.1.2 Semantics of observers . . . . . . . . . . . . . . . . . . . . . . . . . . 140
6.1.3 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
6.2 Semantics of HRC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
6.2.1 Semantical Domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
6.2.2 Properties of Trace Sets . . . . . . . . . . . . . . . . . . . . . . . . . 142
6.2.3 Semantical Definitions for HRC . . . . . . . . . . . . . . . . . . . . . 143
6.3 Syntax and Semantics of Contracts . . . . . . . . . . . . . . . . . . . . . . . . 145
6.3.1 Contract Basics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
6.3.2 Contracts: Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
6.4 Formalization of Typical Design Steps . . . . . . . . . . . . . . . . . . . . . . 147
Glossary 150
Bibliography 153

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

Architecture Modeling
or their implementation, in terms of an executable model or even code, is deliberately left open
in the meta model, in order to provide flexibility in using aspect-specific modelling formalisms.
The formal foundation assumes, that – whatever modelling method is used – the capability to
associate with such models a what is often called trace-based semantics, which, for each interface
object, defines for each point in time the value of such interface objects. Implementations
are allowed to be non-deterministic, hence yielding sets of such traces as their formal representation,
but would typically be input-deterministic and responsive, i. e. yield for each valuation
of an interface object under control of the components environment a uniquely determined valuation
of interface objects under control of the component. Note that in particular modelling
approaches such as AutoFocus, which come with a formal semantics, meet this requirement.
When using commercial-off-the-shelf (COTS) tools for modelling the realization of a component,
a strictly formal development process requires the ability to verify compliance of such
models against contracts, requiring a formal definition of their semantics. Such formal semantics
have been given for a plurality of COTS tools [17, 19, 3]. Less formalized development
processes can use test cases automatically derivable from contract specifications to demonstrate
compliance of component realizations and specifications.
Within the generic landscape characterized by perspectives and abstraction layers, the emphasis
is on supporting the major phases of system development, from product requirements
to a specification of the technical architecture of the system. In particular, the transition to the
geometric perspective, which is served by tools like CATIA 1 or the Siemens PLM suite 2 , is
not elaborated in the current version of this document. In other project contexts, the role of
contracts as an interface between the geometric and the technical perspective has been demonstrated,
such as the impact of physical allocation decisions and routing of cables on the safety
case [4] has already been demonstrated.
This document is organized as follows. A quick tour in Section 2 elaborates on an informal
level the key concepts of perspectives, abstraction layers and Heteregenous Rich Components,
by way of example, providing first indications as to their possible role in design processes.
This is complemented by a detailed specification on the conceptual level of the architecture
meta-model.
The ensuing section adds more detail on the syntax of the meta-model and how design artifacts
are to be represented. It is thus technical in nature and could be skipped on first reading.
Section 4 presents primitive steps in component-based design. It introduces on an informal level
the main concepts underlying contract-based design — contract syntax and semantics, properties,
their usage in specification, verification and virtual integration testing — and how they are
applied to perform the design task from requirement definition to deployment. While this section
provides a bottom-up view of design, Section 5 on using the architecture meta-model adds
the top-down perspective, painting the broad picture of applying contract-based design in the
industrial context. In fact, readers with an industrial background may prefer to read this section
after the quick tour before delving into the more detailed sections 3 and 4.
The annex, finally, provides the formal underpinning of this approach. In particular, it provides
a reference manual for the proposed requirement specification language, a formal semantics
of contracts, a formal semantics of HRC components, and the formal foundations for
primitive design steps in component based design.
This document thus provides guidance in using the release of the architecture meta-model,
1 http://www.3ds.com/de/products/catia
2 http://www.plm.automation.siemens.com/en us/products/teamcenter/ , http://www.3ds.com/plm
2/ 156

Architecture Modeling
allowing to model applications using the concepts of the meta-model, as well as building component
specifications with contracts. OFFIS is offering end users to support such modelling
activities.
3/ 156

2 Quick-Tour
This section intends to provide an overview and basic understanding to the concepts of the SPES
meta-model architecture supporting a component-based design of embedded systems. First
concepts are presented in [10]. Further the terminology is introduced that is applied throughout
this document. Each term suffixed by (↑) can also be found in the glossary at the end of this
document. Keeping brevity in this section is intentional. All concepts are again discussed
in Section 3 in more detail, and how they are expressed in the architecture meta-model. In
Section 4, a set of primitive design steps are discussed that are typically performed in a design
employing the SPES meta-model architecture. Section 5 gives a broader view on how to use the
meta-model with regard to a development process, and also gives further examples. Section 6
finally provides the formal foundation.
Aspect
Specification
Aspect
Realization
Abstraction
Model
Real World
1. Dimension
Abstraction Levels
Safety
Functional
Behavior
View
System
other
aspect
Real-Time
Abstraction
2. Dimension
Perspectives
Figure 2.1: A view addressing different aspects placed in the two-dimensional design space
While distributed embedded systems become more and more complex, market pressure however
requires systems companies to develop high-quality products in short time. Thus, approaches
to architecture design are needed providing means to deal with complexity, and to
reason about qualities of the architecture already in early steps of the overall development process.
In order to deal with complexity, the SPES meta-model architecture provides abstraction
and refinement techniques, and views on an architecture model. Abstraction allows the designer
to concentrate on the essentials of a problem by eliminating unnecessary details. Abstraction
levels(↑) allow to describe a design item (e.g. component(↑), sub-system or the entire system
under development(↑)) with a specific degree of detail. Refinement(↑) adds detail to abstract
architecture models while preserving the semantics of the abstraction. That is e.g. a more concrete
description of a component also has to fulfill all specifications of the abstract component
it has been derived from. Following the principle of seperation of concerns, the architecture
meta-model also supports the concept of viewpoints(↑) that provide constructs and rules for describing
a view(↑) of the system under development(↑). A view is created by a set of models of
the system under development and/or its parts and is related to a viewpoint. The set of models
4/ 156

Architecture Modeling
creating a view belong to a specific abstraction level. In contrast the viewpoint that provides
means to describe a view is orthogonal to abstraction levels. The notion of viewpoints used
here corresponds to the notion of viewpoints of IEEE 1471-2000 [33]. The term model can be
understood as the description of some original entity that only reflects the relevant (from the
modeller point of view) properties of the original entity. A model is created for purpose and
is used in place of the original entity [46]. In this document when using the term model we
assume it has been created by means of the concepts provided by the architecture meta-model.
Thus, the meta-model is in fact a model of models, which means it describes relevant properties
of models.
A perspective(↑) combines views belonging to different abstraction levels. Thus, it is actually
a viewpoint, as a perspective provides means to construct a view. The terms view, perspective
and abstraction level are illustrated in Figure 2.2. Abstraction levels and perspectives form
a two-dimensional design space, where design artifacts may be placed in. According to the
definition each cell in the matrix is considered a view. The concept of aspects(↑) allow coping
with complexity in constructing a view, i.e. a cell of the matrix. Therefore an aspect is part of a
view. Examples for aspects are: Functional behavior, real-time and safety.
Considering a system under development, the structure of models of each considered perspective
are not necessarily congruent. A model of the functional perspective will be composed
differently than a model of the technical perspective. In contrast a view may address different
aspects of the same design item. Figure 2.1 illustrates that relationship. In Figure 2.2 the matrix
of abstraction levels and perspectives is shown. Some fields of the matrix are intentionally left
blank, because depending on the current phase of the development process certain perspectives
may not be regarded or refined.
Figure 2.2: Matrix of abstraction levels and perspectives
Any development of an embedded system is done according to some process model, which
describes the steps to be taken, together with the work products created in that steps. The Vmodel
(see Figure 2.3) has become a well established model for many development processes.
It shows how an embedded system can be developed along several abstraction levels starting
with user requirements for operational scenarios, analysis of functions with refined require-
5/ 156

Architecture Modeling
ments, design decisions with derived requirements and a final implementation. The developed
product has to be tested on all levels, which includes validating the integration of components,
systems and the entire product. On each design-phase on the left branch the architecture might
be regarded from different perspectives as the ones shown in Figure 2.2. Models of each perspective
can address different aspects. However not all aspects are relevant in each combination
of abstraction level and perspective. For example an aspect safety might be regarded in every
perspective whereas an aspect real-time is not regarded in a geometrical perspective.
e.g. Maintainability
Assessment Process
Analysis of Product Level
Requirements
Development of
Functional
Architecture
e.g Cost
Assessment Process
Development of
System
Architecture
Development of
Technology-oriented
Architecture
Safety
Assessment Process
Early virtual Integration
based on formal analysis
techniques
Development of
Deployment
Architecture
Mechanical
Electrical
Digital Hardware
Software
Modultest
Subsystem
Integration
System Integration
Figure 2.3: V-model
The architecture meta-model is based on the meta-model of Heterogeneous Rich Components
(HRC), which has formally defined semantics (discussed in Section 6.2). The meta-model,
which incorporates the concepts we describe in this quick-tour, is designed to be independent
of any application domain (e. g. automotive, avionics, medical). It defines the concepts and
how they are related to each other. That allows us to interpret domain specific meta-models
according to these concepts, thereby making analysis techniques available.
Note that it is out of the scope of this document to describe a development process defining
a sequence of steps to be carried out and what concepts to use in which development step.
That also means the way the design space, spanned by the two dimensions abstraction level
and perspective, is traversed is not prescribed here. The previous paragraph describing a development
process according to the V-model and relating it to the concepts of abstraction levels,
perspectives and aspects has to be understood as an example. Instead concepts for establishing
traceability are provided for carrying out transitions in the matrix, as well as resulting proof
obligations are described.
2.1 Abstraction levels
A system under development(↑) or a constituting design item (e.g. a component) can be modeled
on different abstraction levels(↑). Less abstract models belonging to a lower abstraction
level may increase the degree of detail of the description of the design item at hand. For example
the interface description may be refined as well as the demanded behavior. Therefore increasing
the level of detail, thus at the same time lowering the level of abstraction, adds knowledge about
Product
Integration
Certification
6/ 156

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

:ForwardSensor
:ForwardSensor
objects
Architecture Modeling
objects
Acc
RefinedAcc
:FollowCtrl
speed
accel
:Ctrl
speed
accel
«Realize»
:SpeedCtrl
speed
accel
accStatus
:Arbitration
accel
Figure 2.4: Refinement of a logical architecture of an ACC
These views correspond to a perspective(↑), which thereby is considered a viewpoint(↑). As
viewpoints are orthogonal to abstraction levels, the same holds for perspectives. The concept
of perspectives allows to group views of different disciplines in order to cope with complexity.
Currently we distinguish five perspectives.
Operational perspective In the operation perspective(↑) the context of the system is considered.
That means the embedding of the system under development in its environment is
modeled and analysed including the interactions of the system with its environment. As
a result the system boundary is determined, i. e. its interface, as well as requirements on
the interface behavior.
Functional perspective In the functional perspective(↑) the functional needs of the system
and their breakdown into sub-functions is modeled that together realize the top-level system
functions.
Logical perspective In the logical perspective(↑) the system under development is decomposed
by means of hierarchical components(↑) that implement the functions identified in
the functional perspective. Thus, the logical perspective serves as a partitioning of functions
driven by concerns(↑) like performance, reusability and management of the supply
chain, i. e. to consider the interfaces between organizations in the supply chain. However,
any kind of resources or properties of a target platform are still neglected here.
Technical perspective In the technical perspective(↑) the electrical and electronical architecture,
the software and mechanical parts of the system under development are described.
That encompasses mechanical, hydraulic parts, and electronic control units, buses, and
software tasks, where the components of a view corresponding to the logical perspective
shall be allocated to. While in the logical perspective it is usually assumed that each component
can always be executed, in the technical perspective resource limitations come
into play. Some resources, e. g. electronic control units, will be shared by multiple components,
whose behaviour will therefore depend on the properties of the resource as well
as other components allocated to the very same resource. The allocation of components
8/ 156

Architecture Modeling
of the logical perspective to elements of the technical perspective results in a hardwaresoftware
partitioning.
Geometrical perspective In the geometrical perspective(↑) the physical layout of the system
is considered. While in the technical perspective some resource is modelled in terms of
its properties, its interfaces and its behaviour, in the geometrical perspective its spatial dimensions
are modelled. The geometrical perspective deals for example with cable lengths
and space limitations.
The concept of different perspectives and abstraction levels is inspired by partitions of EAST-
ADL abstraction levels [6] and meetings with industrial partners of the SPES2020 project. Taking
a look at EAST-ADL one can see that one distinct EAST-ADL architecture level is split
into different perspective models: The Design Level contains a Functional Design Architecture
as well as a Hardware Design Architecture. We generalized that concept by means of the
perspectives allowing the partitioning of architectures in each level of abstraction.
The entities and their interfaces defined in different perspectives do not need to be compatible
to each other. For example, three interacting functions defined at the functional perspective
may be modelled as two components in a logical perspective. The palette of actually used
perspectives can be different at each abstraction level. In early design stages for example, when
the functions of the system are to be defined, the target platform (modelled in the technical
perspective later on) need not necessarily be of interest.
2.3 Heterogeneous Rich Components
The meta-model of Heterogeneous Rich Components (HRC), which originates from the European
SPEEDS project [42], constitutes the core of the architecture meta-model proposed in
SPES. This section gives a short introduction into its concepts.
2.3.1 Component Model
The paradigm of component-based design is well established and used in many different application
domains. In standards like EAST-ADL [6] and AUTOSAR [9], a component is the basic
design-entity structuring any model. A component(↑) has a well defined interfaces and is the
Component
Port
C1
aspect
specification
aspect
realization
conforms
to
Figure 2.5: Components, aspect specification and realization
basic entity of any model. The interfaces allow to abstract from the internals of a component
and to reuse it in different design contexts. The notion of components can be established independently
of any design domain. That is, a component can model a reusable piece of software,
9/ 156

Architecture Modeling
a specific sensor measuring temperature or a computing device (e. g. ECU or IMA module)
hosting software applications.
The generic concept of components is extended resulting in so called Heterogeneous Rich
Components (HRC)(↑). Per aspect these HRCs have a specification as well as a realization (cf.
Section 2.3.1.2). Figure 2.5 depicts those fundamental principles of an HRC. Per aspect it has
specifications of its behavior with respect to that aspect. Optionally an aspect realization of the
component is given. Parts of the behavior are exposed at the ports(↑) of the component.
2.3.1.1 Ports
Ports(↑) are the interaction points of a component. Together with their types they define the
syntactical interface of the component. A port can either define a data-oriented interaction
point or service-oriented interaction point. Further, they have a direction and are either input
port (sometimes called required ports), output ports (provided ports) or bidirectional.
p1:PortSpec1
p2:PortSpec2
Component
f1
f2
f3
PortSpec1
Flow
PortSpec2
s1(param,...):return
s2(param,...):return
Service
Figure 2.6: Typing of Ports
A port has a name and is typed by a port specification as illustrated in Figure 2.6. That
specification is a set of flows or a set of services. A flow also has a name and is typed by a
datatype like for example int. A Service has a name as well and is declared by its parameters
and return type.
2.3.1.2 Aspects
A view modeled by an HRC may address different aspects(↑). The concept of aspects classifies
descriptions of the dynamic behavior of an HRC. Though being extensible by user-defined
aspects, we currently consider three pre-defined aspects: functional behavior, real-time and
safety. The functional behavior aspect of an HRC characterizes its dynamics by relating events
to each other and describing the handling of conditions and invariants. The real-time aspect
of an HRC defines the timings of its functional behavior, such as assumed activation behavior
(e.g periodic with jitter) or end-to-end deadlines of chains of functions. The real-time aspect
usually abstracts from actual values received or sent at the ports of an HRC, but focusses on
the timing of events instead. The safety aspect of an HRC provides specification of single point
of failures, as well as failure conditions and hazards. This also encompasses probabilities for
the occurrence of failure conditions. Thus aspect specifications describe functional and nonfunctional
characteristics of an HRC.
For each aspect of an HRC there can be a specification and an aspect realization. A specification
of an aspect of an HRC is a characterization of the realization of the HRC with regard to
the aspect. That means an aspect specification defines ”what” an HRC does, while a realization
describes ”how” it does that. Specifications are done by means of so called contracts(↑). The
10/ 156

Architecture Modeling
realization of a certain aspect of an HRC can be modelled by any other formalism (e. g. FOCUS,
MechatronicUML [27], Matlab/Simulink, Stateflow). As the only prerequisite for compatibility,
that formalism must have a semantics based on traces.
In [38] exemplary Real-Time Statecharts are shown, which would be an example of a realization
of the aspect real-time.
2.3.1.3 Contracts
The concept of contracts(↑) is meant to provide a specification of an aspect(↑) of an HRC. One
of the key concepts is the ability to thereby abstract from the actual aspect realizations of HRCs
and to characterize the required behavior using contracts. The idea is insprired by Bertrand
Meyer’s programming language Eiffel and its design by contract paradigm [37].
A contract is a triple (As,Aw,G), where As is the strong assumption of a contract, Aw the weak
assumption and G the guarantee. A strong assumption characterizes the allowed design context
of an HRC, i. e. the environment from the point of view of the HRC. If the design context
does not comply to a strong assumption, then this constitutes an ”illegal” out of specification
usage of the corresponding HRC. As an analogy one can think about strong assumptions as a
specification of contractual liabilities. In fact, they may even be used that way in OEM/supplier
negotiations. A weak assumption defines different integration contexts by making case
distinctions. Thus a weak assumption actually refines the integration context required by the
strong assumption. If an HRC is used accordingly to its strong assumptions, it will guarantee
the behavior specified by the guarantee, provided the weak assumption is fulfilled. This enables
the verification of virtual system-integration at an early stage in a design flow, even when there
is no implementation yet.
A contract is a requirement with a specific structure (strong, weak assumptions and guarantee).
The concept of contracts makes assumptions about context explicit, which allows to
assign responsibilities in development processes. Typically contracts are derived from top-level
system requirements that may be captured in external requirements management tools like e. g.
DOORS. Keeping those requirements separate from an architecture model may be required by
certification processes.
Ports expose parts of the behavior of the HRC. Thus the specification of an aspect of an HRC
by means of a contract refers to its ports and constrains the behavior observable at those ports.
Note that when specifying assumptions (strong and weak), they must not limit the output ports
of the HRC. In turn the guarantee must not limit its input ports.
:FollowCtrl
objects accel
speed
:Arbitration
folwAccel
crsCtrlAccel
:Vlc
accel accel
Figure 2.7: FollowCtrl component of an ACC
As an example for the difference between strong and weak assumptions reconsider the
FollowCtrl component of an ACC from the example in Section 2.1 that controls the distance
between the ego-vehicle and those in front of it. The component has two input ports
on which it receives data of objects recognized by some sensor component and the current
travelling speed of the ego-vehicle, respectively. On its output port the component provides acceleration
commands. The example has been slightly modified by inserting a component Vlc
11/ 156

Architecture Modeling
(Vehicle Longitudinal Control) that receives the acceleration commands either produced by
the FollowCtrl component or by the SpeedCtrl component and processes them. Which
value is forwarded is determined by the Arbitration component based on the current overall
state of the ACC (not shown in the figure). Now for the FollowCtrl component suppose
there exist two contracts C1 and C11, which are defined as follows:
C1
strong assumption always (0 ≤ speed ≤ 70 m s )
weak assumption true
guarantee always (−3.0 m
s2 ≤ accel ≤ 3.0 m
s2 )
C11
strong assumption always (0 ≤ speed ≤ 70 m s )
weak assumption always (0 ≤ speed ≤ 50 m s )
guarantee always (−2.5 m
s2 ≤ accel ≤ 2.5 m
s2 )
Thus, the component FollowCtrl is designed to operate at travelling speeds up to 70 m s
and guarantees it will issue acceleration commands in the value range [−3.0 m
s2 ,3.0 m
s2 ]. It may
only be integrated in a context, where its environment ensures the strong assumption. Contract
C11 however adds a weak assumption that actually confines the strong assumption by
and guarantess acceleration commands in the value range
requiring a maximum speed of 50 m s
[−2.5 m
s2 ,2.5 m
s 2 ]. For the integration of the FollowCtrl component that means, if its con-
text can even ensure the weak assumption, then the smaller range specified in the guarantee of
C11 may be relied on when connecting FollowCtrl to the Arbitration and Vlc components.
In that case both components can be more restrictive with regard to its own strong
and weak assumptions as they only need to deal with a smaller range of acceleration values.
Note that actually the same range of acceleration values must be assumed on the port named
crsCtrlAccel of the Arbitration component such that it can also guarentee to provide
that value range on its output port accel.
2.3.1.4 Requirement Specification Language
The semantics of contracts and HRC provide the formal basis for reasoning about the relation of
specifications stated as contracts and about the composition of HRCs and their contracts. With
the requirements specification language (RSL)(↑) described in Section 6.1 we provide syntax
and semantics of a pattern-based language, which can be used to define the aspect specifications
of an HRC. An instance of a pattern of the RSL can be used to specify the assumption (strong
and weak) as well as the guarantee parts of a contract.
PortSpec1
e1
ComponentA
p1 p2
p3
refers to
C1
refers to
Figure 2.8: Linking contracts and components
PortSpec2
Suppose an HRC has been defined as sketched in Figure 2.8. It has two ports p1 and
p2, which are typed by two port specifications PortSpec1, PortSpec2 respectively.
Now the designer can select a pattern that suits the aspect, for which a contract shall
be specified. As an example assume that a latency of 10ms is to be specified from the
time data arrives at port p1 to the time data is provided at port p2. Such a specification
f1
12/ 156

Architecture Modeling
can usually only be realized by making assumptions about the frequency at which data arrives
at the input port p1. Thus for the real-time aspect of the HRC a contract might be:
C1
strong assumption p1.e1 occurs each 10ms with jitter 1ms
weak assumption true
guarantee delay between p1.e1 and p2.f1 within [0ms,10ms]
The different patterns, which can be instantiated in order to specify the assumptions and guarantees
of a contract, are defined in Section 6.1.1. Each pattern belongs to a category (functional
patterns, real-time patterns), which is reflected by its name. For example all patterns with names
prefixed by the letter F are functional patterns and the prefix R denotes a real-time pattern. The
category of a pattern gives a first hint for the specification of which aspect it may be suited best.
With regard to the example contract C1 an instance of the pattern R2 has been used for the
strong assumption and an instance of the pattern R3 for the guarantee. The concrete number of
the pattern does not need to be specified, as it can be automatically derived from the syntax of
the expression.
2.3.2 Hierarchy and Composition
When a component is used as part(↑) in the context of another component, its ports(↑) can
be linked to other parts forming a composition of components. That composition is again a
component, whose behavior is given by the behavior of its constituting parts. Thus components
can support both top-down as well as bottom-up design approaches and mixed forms thereof.
2.3.2.1 Hierarchy
ComponentC
part2:ComponentB
component
instance
role
Ports
part1:ComponentA
ComponentA
C1
aspect
specification
aspect
realization
Figure 2.9: Hierarchy of components
component
specification
The component model of HRC supports the type/part concept found in many other modeling
languages, e. g. the UML [41]. Figure 2.9 shows an illustration of that concept. An HRC
ComponentA is modelled with its ports and contracts that specify the behavior of that HRC
under the different aspects. That HRC can be used in the context of other HRCs playing the role
of a part in that context. A part denotes component instances that the surrounding HRC owns
by composition. In the example, the HRC ComponentA is used as part with the role name
part1 in the context of the HRC ComponentC. The aspect specifications characterized by
contracts that are linked to ComponentA and corresponding realizations are valid for part1
as well. This holds for any context, in which ComponentA is used as a part.
The type/part concept results in a possibly deeply nested hierarchy of components ultimately
leading to some top-level component specification. Such a hierarchy of HRCs can be con-
13/ 156

Architecture Modeling
structed for every combination of abstraction level and perspective, representing a view of the
system under development.
2.3.2.2 Composition
The ports of HRCs used as parts in the context of another HRC are interconnected forming a
composition of HRCs. In a component-based design there are two use-cases for the composition
concept. A component can be decomposed(↑) into smaller subcomponents in a top-down approach.
So, a large design is split into smaller components, that can be implemented or further
decomposed. Following a bottom-up approach one can also specify components and integrate
them in a composition to realize its specification.
ComponentC
delegation
connector
part2:ComponentB
part1:ComponentA
ComponentB
C2
C12
assembly
connector
ComponentA
C1
Figure 2.10: Compositions of components
To decide whether an HRC can be used in a given context and connected with other HRCs,
the ports that are connected must be compatible. Compatibility of ports is discussed in Section
3.3.2.2. Figure 2.10 shows the distinction between delegation connectors and assembly
connectors. The former connect the outer ports of an HRC to ports of its constituting parts. So
in order to connect the ports they must have the same direction. Assembly connectors link the
parts of a composition to each other.
Additionally with regard to the contracts a Virtual Integration Test(↑) must be carried out (cf.
Section 4.2). Related to the example from Figure 2.10 it must be checked, that the contracts C1
and C2 are compatible and that together with the interconnection they are a valid refinement of
C12.
p1
p2
14/ 156

3 The Architecture Meta-Model
In Section 2 we briefly introduced the fundamental concepts of the architecture modeling approach.
In this section these concepts are described in more detail. In addition it is shown how
they are expressed in the architecture meta-model and how concepts relate to each other. However
it is not in the scope of this document to give a complete specification of the architecture
meta-model. That specification is delivered seperately in [50]. Note, that we sometime use the
abbreviation SPESMM denoting the architecture meta-model.
3.1 Abstraction levels
The SPESMM introduces a generic concept of abstraction levels. An abstraction level represents
the system under development at a certain level of detail. A car for example may be
modelled at the top-level as a single component where only the interface of the car to the environment
is visible. At a lower level, certain components of the car may be visible (chassis,
engine, ...), and so on.
+subPackage
Package
SystemModel
+owner 0..1
1..*
+owner
0..1
0..*
+abstractionLevel
DeclarationZone
1 +topLevel
+declarationZone
0..1
+owner
AbstractionLev el 0..1 +ownedPerspective
Perspectiv e
+successor 0..1
0..*
+abstractionLevel 0..*
0..* +perspective
+declared
ReusableElement
0..*
+ kind: PerspectiveKind
AbstractionLev elCategory
+category 0..1
Figure 3.1: Meta-model integration of the concept of abstraction levels
A design item (e. g. the system under development or a component) may be modeled on
different levels of abstraction. An ordering relation on the abstraction levels within a model
is defined by means of the successor-association between AbstractionLevels (see
Figure 3.1). The highest abstraction level associated by the SystemModel in the role of
topLevel is intended to contain the most abstract description. Each AbstractionLevel
owns a set of Perspectives, that in turn contain models and requirements.
An abstraction level may be further categorized by AbstractionLevelCategory,
which allows to adapt the concept to development processes of a company. So for an abstraction
level of a certain category one can e. g. specify the set of considered perspectives.
The component hierarchy modelled within a certain abstraction level may be re-arranged
within the next lower abstraction level. Thus, a component-based architecture can not only be
15/ 156

Architecture Modeling
refined by decomposition of components (see Section 3.3.2.2), but also by means of a different
component hierarchy. So refinement subsumes but is not restricted to simple decomposition of
components. When switching abstraction levels the component-models must be related to each
other. This is done by Realize-trace links (shown in Figure 3.2), that constitute a mapping
relation between component instance roles of different abstraction levels. Due to its similarity
to Allocate-trace links, the superordinate concept of Mapping has been defined, that is
discussed in Section 3.4.
+type 1
RichComponent
+component 1
«isOfT ype»
+part 0..*
+m appedT o
RichComponentProperty
1 «instanceRef»
+m apped
1
«instanceRef»
Allocate
Mapping
Realize
Figure 3.2: Meta-model integration of the concept of Realize-trace links
While the models on lower abstraction levels usually provide more detail with regard to the
design item, the respective models still have to satisfy all functional and non-functional requirements
defined for their higher level counterparts with respect to a continuous development
process. The Realize-link provided by the meta-model also indicates the proof obligations,
that have to be performed to ensure a valid refinement with regard to the specified contracts.
The realize relation is discussed detailed in Section 4.4.
Since the design processes for different application domains like automotive and avionics are
very diverse, a fixed set of predefined abstraction levels has found to be insufficient to support
different domains. The EAST-ADL abstraction levels for example are just one possible instantiation
of the generic abstraction level concept. In other application domains, e. g. avionics, or
even for different companies in the same domain, the set of actually used concrete abstraction
levels may be different. The meta-model provides concepts for tailoring models to specific
needs. This allows to define so-called model libraries that provide predefined sets of abtraction
levels, such as those defined in EAST-ADL. The underlying formal semantics of the Realizelink
then allows the verfication of refinements of component-models.
3.2 Perspectives
Beside the distinction of different user-defined abstraction levels, a model of a system under development
may be associated with certain viewpoints, such as defined in [33]. The architecture
meta-model differentiates between viewpoints that establish structurally different views on the
system (perspectives), and viewpoints, that are orthogonal to the structure of the system and describe
different aspects of functional and/or non-functional properties of model elements. The
concept of aspects is discussed in Section 3.3.1.2.
So models of a system addressing a certain perspective will specify the structure of the system
from that particular perspective. This results in a two-dimensional organization of component
16/ 156

Abstraction-Levels
(detail increases)
Operational
Perspective
Architecture Modeling
Allocate
Functional
Perspective
Allocate
Allocate
Logical
Perspective
Realize
Technical
Perspective
Realize
Geometrical
Perspective
Figure 3.3: Matrix of abstraction levels and perspectives
models according to abstraction levels and perspectives like in Figure 3.3. We identified five
specific perspectives which are currently supported by the architecture meta-model: The operational
perspective, the functional perspective, the logical perspective, the technical perspective,
and the geometrical perspective.
+subPackage
Package
SystemModel
+owner 0..1
1..*
+owner
0..1
0..*
+abstractionLevel
DeclarationZone
1 +topLevel
+declarationZone
0..1
+owner
Perspectiv eKind
operational
functional
logical
technical
geometric
+declared
ReusableElement
AbstractionLev el 0..1 +ownedPerspective
Perspectiv e
+successor 0..1
0..*
+abstractionLevel 0..*
0..*
+perspective
0..*
SystemArtefact
+root 0..1
+ kind: PerspectiveKind
Figure 3.4: Meta-model integration of the concept of Perspectives
The combination of the perspectives at a certain abstraction level provides a specification of
the whole architecture at the given level of detail. The entities and their interfaces defined in
different perspectives do not need to be compatible to each other. For example, three interacting
functions defined at the functional perspective may be modelled as two logical components. Elements
of one perspective however can be allocated to elements of another perspective (cf. Section
4.4). Du to its similarity to Realize-trace links, the superordinate concept of Mapping
has been defined, that is discussed in Section 3.4. A function for example, that is defined in
the functional perspective, may be allocated to a logical component, which itself may be allocated
to a hardware resource defined in the technical perspective. The meta-model provides a
formal definition of Allocate-links, allowing to define simulation relations between linked
elements, and to reason about consistency of the system design among different perspectives.
17/ 156

Architecture Modeling
Depending on the system under development and on the respective development process,
the palette of actually used perspectives and elements may be different for each abstraction
level. In early design stages for example, when the functions of the system are to be defined,
the target platform (modelled in the technical perspective later on) might not be of interest.
This is reflected in the meta-model by allowing to aggregate the set of Perspectives from
an AbstractionLevel, that is considered relevant in that specific abstraction level (see
Figure 3.4).
3.2.1 Operational Perspective
Models of the operational perspective express the operational capabilities and activities that
are expected by the users and customers from the actors and their operational interaction. The
purpose is to identify the customer needs as one of the first steps towards a conrete functional
system design that fulfills these needs. This can be achieved by identifying actors and the
activities being intended to be performed. Scenarios describe the interaction between the actors
and their performed activities. This first analysis of system scenarios helps in determining the
functional needs of the system in subsequent design steps.
OperationalActor
RichComponent
Requirement
+ rationale: String [0..*]
OperationalActiv ity SystemRequirement
+aspect
SystemArtefact Aspect
0..*
+stakeholder
0..*
Stakeholder
Figure 3.5: Meta-model integration of the concepts for specifying the operational perspective
Figure 3.5 depicts the concepts of the meta-model for specifying the operational perspective.
As a first step to capture operational functionality the meta-model specification concept
of OperationalActivity can be used to model an operational activity. Being specialized
RichComponents their dynamics can be abstracted by means of contracts. The concept of
contracts is named SystemRequirement in the meta-model for reasons explained in Section
3.3.1.3. Actors that perform these activities can be modeled as OperationalActors
taking part in the scenario. Since in the beginning of the design process the concrete system
under design and its boundary are unknown in later refinement steps these actors of a scenario
performing operational activities can be realized by the system under design and its environment.
In [35] an approach to model-based requirements engineering is proposed, which includes
a process description how system scenarios can be derived from system goals. Note that the
concept of goals proposed in that approach is not part of the current version of the architecture
meta-model. However they may eventually be referenced by the rationale attribute of the
Requirement concept.
18/ 156

3.2.2 Functional Perspective
Architecture Modeling
Modeling the functional perspective of the system serves identifying the functional needs of the
system. Derived from an analysis of the operational context of the system in the Operational
Perspective, its behavior is specified from a user-centric point of view, establishing a blackboxview
of the functions of the system. Subsequently these top-level functions are refined by
sub-functions that together realize the top-level system functionality. Ideally, functions are
completely independent of any architecture.
Elements of an operational model defined at the same or a higher abstraction level can be
allocated on the defined functions. This way, the contribution of a function to an activity of
an actor can be explicated, which allows to investigate whether each activity is supported by
system-functions, and whether the design goals can be accomplished.
+part 0..*
RichComponentProperty
+component 1
+type
«isOfT ype» 1
RichComponent
Function
+aspect
SystemArtefact Aspect
Requirement
+ rationale: String [0..*]
SystemRequirement
0..*
+stakeholder
0..*
Stakeholder
Figure 3.6: Meta-model integration of the concepts for specifying the functional perspective
The architecture meta-model provides the concept of a Function (see Figure 3.6) to model
functions of the system. Function is a specialized RichComponent and thus can have
behavior. Inputs and outputs of a function are represented by ports. Functional as well as
non-functional specifications are defined and assigned to the modelled functions by means of
SystemRequirements (contracts).
3.2.3 Logical Perspective
The logical perspective constitutes the decomposition of a system into reusable components
and specifies their interaction. Additionally, the environment is modelled with respect to the
interfaces of the system, which includes both syntactical interfaces and behavioral interaction.
That way, the logical parts of the system and their relationships are identified. Technical aspects
and choices of any technology are typically not considered in the logical perspective. The
logical perspective is the entry to the design of the system. Functions modelled within the
functional perspective can be spread across the defined logical components.
Logical components of a system are modelled by the architecture meta-model concept
LogicalComponent (see Figure 3.7). LogicalComponent is a specialized
RichComponent, and thus can have behavior. Ports typed by PortSpecifications
specify the interaction points of the component. Functional as well as non-functional requirements
can be formulated as SystemRequirements. A LogicalComponent can
be instantiated in a given context of other component instantiations by using the concept
RichComponentProperty. The behavior of the component instance is determined by its
type.
The concepts EnvironmentComponent models a component of the environment interacting
with the System. Conceptionally an actor is also part of the environment.
19/ 156

PortSpecification
+part 0..*
Env ironmentComponent
+type
RichComponentProperty
1
«isOfT ype»
+component
System
+type
«isOfT ype» 1
Architecture Modeling
Port
+ isConjugated: Boolean
1
+port 0..*
+component
1
RichComponent
LogicalComponent
+aspect
SystemArtefact Aspect
Requirement
+ rationale: String [0..*]
SystemRequirement
0..*
+stakeholder
0..*
Stakeholder
Figure 3.7: Meta-model integration of the concepts for specifying the logical perspective
Activities and their performing actors of the operational perspective can be allocated to
EnvironmentComponents. This allows to refine the behavior at the interfaces of the system.
The concept System denotes a component, that defines the system boundaries. Thus,
such a component should exist at most once per abstraction level. If a System is used as
part in the context of another LogicalComponent, then the other parts should be typed by
EnvironmentComponents.
Allocating LogicalComponents to elements of a technical perspective realizes a
software-hardware partitioning and describes how an underlying platform executes the
LogicalComponents. However this does not mean that a designer cannot express that
partitioning in advance in a logical perspective. For example considering AUTOSAR [9] an
application is modeled as a composition of interconnected software components. On the design
entry in AUTOSAR these software components are connected by means of a so called Virtual
Functional Bus that abstracts from system topology, available resources (e. g. electronic control
units) and communication media. Thus, in scenarios where software-hardware partitioning
shall be decided but the allocation to platform resources is left open, one may explicitly model
software- as well as hardware-specific components in the logical perspective.
3.2.3.1 Communication Refinement
The logical perspective of the system is not concerned with the specification of properties of the
target platform hosting the logical component architecture. Especially it is also not decided how
the logical components are deployed. However a logical perspective of a system has to take into
account, that the communication between components will later on be mapped to a distributed
communication infrastructure (like e. g. a CAN-Bus or AFDX) or to a communication local to
a computing node.
LogicalComponent
part1:Controller part2:Actuator
...
p1 p2
com:Comm
Comm
C3
Figure 3.8: Enabling logical communication refinement in the logical perspective
...
20/ 156

Architecture Modeling
The semantics of HRC is defined such that behavior is always part of a RichComponent or
specializations thereof. The connection of ports (syntactically described in Section 3.3.2.2) is
semantically interpreted as the identity of the behavior observable at the connected ports. So if
in the example sketched in Figure 3.8 the ports p1 and p2 would have been directly connected,
then any event or data occuring at port p1 is at the same time observed at port p2. Thus, in
order to be able to specify assumptions about communication latencies from a real-time aspect,
one needs at least conceptionally a LogicalComponent. For that component contracts can
again be used for the specification of the different aspects of the logical communication, e. g.
expected latencies or failure hypothesis. Though conceptionally logical communcation has to
be represented as a RichComponent, the user-representation can be different. For example
a UML-profile based on the architecture meta-model, can introduce a stereotype, which is
applicable to uml::Connector and is mapped to the concept of LogicalComponent.
3.2.4 Technical Perspective
In the technical perspective the electric/electronic architecture of the system is specified, which
comprises mechanical and hydraulic components controlled by a network of control units, that
the logical components shall be allocated to. The electronic control units may be softwareprogrammable
hardware components or application specific integrated circuits (ASICs). Mechanical
components are for example cams, shafts, switches and relays. Hydraulic components
include for example valves and cylinders.
The concepts provided for describing a view corresponding to the technical perspective are
more specialized than those provided for modeling an operational, functional or logical perspective.
That is because it is intended to apply dedicated analysis techniques for checking
satisfaction of contracts (cf. Section 4.3) based on models of the technical perspective. In Section
5.1.3.5 an example is presented how the concepts described in this section can be used to
model a technical view.
+part 0..*
RichComponentProperty
«isOfType»
+component 1
+type
1
RichComponent
TechnicalComponent
+aspect
SystemArtefact Aspect
Requirement
+ rationale: String [0..*]
SystemRequirement
0..*
+stakeholder
0..*
Stakeholder
Figure 3.9: Meta-model integration of the concepts of TechnicalComponents
The architecture meta-model provides concepts to specify the technical perspective of a system
by means of TechnicalComponents (see Figure 3.9). While we do not provide specialized
concepts in the meta-model for mechanical or hydraulic components, their aspects however
can still be specified by means of contracts. That allows a characterization of their dynamics
and to assess whether requirements on functions are fulfilled by the mechanical or hydraulic
components and the electronic components controlling them.
In SPES the focus is on software-intensive systems. Therefore the meta-model incorporates
specialized concepts to describe the resources of a network of electronic control units, which
21/ 156

Architecture Modeling
allows to model execution platforms hosting the components of the logical perspective. Here
resource limitations come into play, e. g. the sharing of computing resources by multiple logical
components. The behavior of the allocated logical components will therefore depend on the
properties of the resource as well as the other logical components allocated to the very same
resource.
3.2.4.1 Resources
The concepts of the metamodel for specifying the technical perspective of a system are inspired
by the UML Profile for MARTE (Modeling and Analysis of Real-Time Embedded Systems)
[40].
RichComponent
Resource
+ isActive: Boolean
+ isProtected: Boolean
+ resMult: int [0..1] = 1
StorageResource
+elem entSize 1
ConcurrencyResource ProcessingResource
SchedulerSlot
+ isPreemptible: Boolean = true
Dev iceResource ComputingResource CommunicationResource
+ transmMode: T ransm ModeKind
+packetT ime
1
Expression
+elementSize
1
+blockingT ime
1
Scheduler
+ isPreemptible: Boolean = true
+capacity
1
+schedule
1
TextuallyRepresentedElement
Figure 3.10: Meta-model integration of the concepts of Resources
The concept Resource shown in Figure 3.10 constitute an abstraction of the resources a
platform provides and allocated behaviour from logical components. Examples for resource
are:
• computational resources, i. e. the computational power of some processor
• bandwidth of a communication resource
• storage capacity of a storage resource
As some of those resources might be shared by multiple consumers, this sharing of resources
can be explicated by means of schedulers. Such a scheduler distributes fractions of a resource
according to a given scheduling strategy. The concept Scheduler allows for modelling static
as well as dynamic scheduler types.
Schedulers: The concept Scheduler depicted in Figure 3.11 distributes fractions of a resource
according to a given strategy. The clients of a scheduler are modeled by the concept
SchedulerSlot. The Resource, whose capacity is shared and assigned by a scheduler is
22/ 156

Architecture Modeling
expressed by the concept ProcessingResource. The SchedulingPolicy concept allows
to specify the strategy of the scheduler, e. g. fixed-priority based. The SchedulerSlots,
which receive a fraction of the resource, aggregate the concept SchedParameterSpec, that
specifies parameters used by a scheduler to run its strategy. Such parameters are for example
the definition of a priority.
RichComponent
Resource
+ isActive: Boolean
+ isProtected: Boolean
+ resMult: int [0..1] = 1
+required
SchedulerPort
SchedulerRPort +required
ConcurrencyResource ProcessingResource SchedulerSlot
0..*
+ isPreem ptible: Boolean = true
Variable
SchedParameterSpec
+provided
SchedulerPort
SchedulerPPort +provided
0..1
+required 1
+provided 0..*
0..*
+schedParameters 1
1..*
Scheduler
+ isPreemptible: Boolean = true
+policy 1
+schedule
1
TextuallyRepresentedElement
Expression
+scheduleLength 0..1
SchedulingPolicy
+ otherSchedPolicy: String [0..1]
+ policy: SchedPolicyKind = FixedPriority
Figure 3.11: Meta-model integration of the concept Scheduler
The concept, which actually uses the fraction of the ProcessingResource, is a
ConcurrencyResource or specializations thereof. If some schedule was determined offline,
it can be directly specified by means of an Expression in the role schedule. This
overrides whatever was specified in the SchedulingPolicy.
The relation of the concepts Scheduler, SchedulerSlot and
ConcurrencyResource is modeled by the special ports SchedulerPPort and
SchedulerRPort. That ports must be typed by a PortSpecification, which is
conformant to the concept SchedulerPortSpec (see Figure 3.12). This specification
comprises five flows, that are referenced in the following roles:
activateEvent is a flow of kind event. The direction is always in. This event
denotes the request for the activation of a ConcurrencyResource. The
ConcurrencyResource thus notifies its need to access the capacity of a
ProcessingResource.
startEvent is a flow of kind event. The direction is always out. This event denotes the grant
of some Scheduler upon a previously received request (the activateEvent).
finEvent is a flow of kind event. The direction is always in. This event denotes the release
of the capacity of the ProcessingResource by the ConcurrencyResource. It
is triggered, when the ConcurrencyResource has finished its computation or communication.
suspendEvent is a flow of kind event. The direction is always out. The referenced flow
shall be triggered by some Scheduler or forwarded by some SchedulerSlot, when
access to the processing capacities of a scheduled resource has been granted before, but
shall now be revoked in favour of another SchedulerSlot. This reference to a flow is
only needed, if preemption can occur.
23/ 156

Architecture Modeling
resumeEvent is a flow of kind event. The direction is always out. The referenced flow shall
be triggered by some Scheduler or forwarded by some SchedulerSlot, when access
to the processing capacities of a scheduled resource has been granted and suspended
before and now access to the ProcessingResource is granted again. This reference
to a flow is only needed, if preemption can occur.
Port
+ isConjugated: Boolean
SchedulerPort
1
{redefines
type} +type
SchedulerPortSpec
«isOfT ype»
SchedulerPPort SchedulerRPort
+activateEvent 1
«isOfT ype»
+ direction: FlowDirection
+ kind: FlowKind
PortSpecification
+finEvent 1 +startEvent 1 +resumeEvent 0..1 +suspendEvent 0..1
Figure 3.12: Meta-model integration of the concept SchedulerPort
+type
1
Flow
+comSpec
+schedulerEvent 3..5
In a model the scheduling of a ProcessingResource will look like depicted in Figure
3.13. The ports marked in red color are SchedulerPorts. The figure also shows how to
make use of the Scheduler and SchedulerSlot concepts when modeling the hierarchical
scheduling of a ProcessingResource. A SchedulerSlot can also serve a second
Scheduler, which then only distributes the capacity of the ProcessingResource to its
clients that it receives through its underlying slot by the main scheduler.
ProcessingResource
:Concurrency
Resource
:Concurrency
Resource
:SchedulerSlot :SchedulerSlot
:Scheduler
:SchedulerSlot
:Scheduler
:Concurrency
Resource
:SchedulerSlot
Figure 3.13: Example of using the Scheduler concept
ComputingResources: The concept ComputingResource shown in Figure 3.14
models a processing device capable of storing and executing Tasks. This concept is an abstraction
of elements of an execution platform hosting multiple tasks, which require computing capacity
in order to carry out their computations. Being derived from ProcessingResource
a ComputingResource may be subject to scheduling of its computing capacity.
The Task concept models a computation task. As it is derived from
ConcurrencyResource, it can be connected to a SchedulerSlot, thus using the
24/ 156

Architecture Modeling
computing capacity the SchedulerSlot receives from a Scheduler. In the role
executionTime a Task can aggregate multiple declarations of its execution time,
that has been measured/analysed. Provided a task would have exclusive access to a
ComputingResource the execution time is the time from starting the task until it finishes.
As the execution time may vary depending on the kind of the computing device, one can
specify multiple execution times, each with a unique identifier. An example specification of an
execution time, would be: {ARM7;500us;1ms}. Where 500us is the best base execution time
and 1ms is the worst case execution time.
RichComponent
Resource
+ isActive: Boolean
+ isProtected: Boolean
+ resMult: int [0..1] = 1
Task
ConcurrencyResource ProcessingResource SchedulerSlot
+executionT ime
SchedulerPort
SchedulerRPort
0..* +required
0..*
Constant
ExecutionTimeSpec
ComputingResource
SchedulerPort
SchedulerPPort
+provided 0..*
+ isPreemptible: Boolean = true
Figure 3.14: Meta-model integration of the concept ComputingResource
CommunicationResources: The concept CommunicationResource shown in Figure
3.15 models an abstraction of a communication device of an execution platform
capable of transferring information from one location to another. The attributes of
CommunicationResource are used to describe its most relevant properties needed for
timing analysis of a technical architecture. Being derived from ProcessingResource a
CommunicationResource may be subject to scheduling of its communication capacity.
A frame is a data item, which is transmitted by a CommunicationResource. The concept
FrameTriggering models the triggering and identification of a frame transmitted by
a CommunicationResource. As the concept is derived from ConcurrencyResource,
it can be connected to a SchedulerSlot, thus using the communication capacity the
SchedulerSlot receives from a Scheduler.
SchedulerPort +required
SchedulerRPort 0..*
ConcurrencyResource
FrameTriggering
Resource
Resource
ProcessingResource
+ transmMode: T ransmModeKind
CommunicationResource
SchedulerSlot
Resource
+ isPreemptible: Boolean = true
+provided
SchedulerPort
0..* SchedulerPPort
Figure 3.15: Meta-model integration of the concept CommunicationResource
Describing data encapsulation in communication stacks: We consider the technical
architecture as a network of ComputingResources, that are interconnected by
means of CommunicationResources. The frames, that are transmitted by that
CommunicationResources are however not the data items, that would be sent directly
by some application task. Instead in most execution platforms an application programming
25/ 156

ReusableElement
ComData
+com Data 1
+referencedPorts
0..*
PortReference
Signal
+ length: int
Message
+ length: int
Frame
+ length: int
Architecture Modeling
+signal
1
+owner +signalT oMsgMapping
+message
1
+owner +msgT oFrameM apping
NamedElement
MsgToFrameMapping
0..*
+ offsetInFrame: int
0..*
«enumeration»
TransferPropertyKind
«enum eration»
triggered
pending
triggeredOnChange
SignalToMsgM apping
NamedElement
+ offsetInMessage: int
+ transferProperty: T ransferPropertyKind
Figure 3.16: Meta-model integration of the concepts for modeling data encapsulation
interface (API) is provided, that hides the complexity of different bus technologies and communication
protocols. Data sent by some application task is then processed by a communication
stack, which is typically organized in layers like in the Open Systems Interconnection model
(OSI) [51].
Beside the wish to abstract from the details of a layer of communication protocols from the
logical perspective of the system, in the technical perspective one needs a specification of e. g.
their real-time aspects or safety aspects. This allows to reason about whether requirements on
the communication of components in the logical perspective can be fulfilled when allocating
them to a technical architecture. Figure 3.16 shows the concepts of the meta-model, which
allow to capture the data encapsulations done by a communication stack and Figure 3.17 shows
their intended usage. For the sake of brevity the SchedulerSlots and a Scheduler are
not shown in that figure.
ComputingResource
header
header
app-task1:Task
app-task2:Task
Signal1
com:Task
Signal2
Signal1 Signal2
payload
Message1 Frame1
Message1
payload Frame1
bus-drv:Task
Figure 3.17: Example for specifying the data enscapsulation
The Signal concept represents data sent by some application tasks, which components
from the logical perspective have been allocated to. The declared Signal references Ports
in the technical architecture model to indicate at which ports it is sent or received. The concepts
Message and Frame also allow to reference multiple Ports. The data encapsulation by a
communication stack as sketched in the bottom half of Figure 3.17 is expressed by the concepts
SignalToMsgMapping and MsgToFrameMapping. They allow to describe the composition
of messages in frames and of signals in messages. The condition when a Task, which is
responsible for the encapsulation of Signals in Messages, actually triggers the Message
can be defined by the attributes of the concept SignalToMsgMapping. For example some
Signals mapped to the same Message may cause it to be triggered, while others just update
the value inside the Message.
26/ 156

3.2.5 Geometrical Perspective
Architecture Modeling
The geometrical perspective constitues the geometric installation of a technical system under
design and its geometric context. A geometric model can be based on CAD models like from
CATIA or AUTOCAD. The following description is a first draft of possible modeling concepts
for a geometric perspective. Two use cases motivate their usage in architecture modeling for
the optimization of cable lengths based on function allocation constraints and for the analysis
of particular risks.
Geometric Components Figure 3.18 provides an overview on the concepts for the description
of geometric components, their parts and failure conditions.
FailureCondition
GeometricFailure
+geometricFailure 0..1
+shapeProperty 0..1
ShapeProperty
+failureCondition
0..*
«isOfType»
+type
1
+shape 0..1
Shape
+component
+relatedComponent
0..*
GeometricLocationType
1
RichComponent
GeometricComponent
+zone 0..*
GeometricZone
+type
+location 1..*
1
GeometricLocation
+translation GeometricTranslation
+translation
0..1
+scaling
0..1
+rotation
0..1
+location 0..*
+translation 1
2
GeometricScaling
GeometricRotation
+type
1
1
+location
0..1
+component
+rotation
0..1
GeometricLocationLink
+location
1
+scaling
1
+scaling
0..1
+locationLink 0..*
«isOfType»
+route
1..*
{ordered}
Figure 3.18: Concepts of the geometrical perspective.
RoutedInstallation
RichComponentProperty
+part
0..*
GeometricInstallation
LocationInstallation
Geometric Components are specialized Rich Components. They define an own reference
system for all contained structures. As an example we consider the geometric structure of a car.
A geometric component declares Geometric Locations. These are positions within a geometric
component which can be used for installations. A geometric location type defines which geometric
components may be installed at a specific location. The position of a geometric location
is defined by its translation reletive to the reference system of the owning geometric component.
Geometric location links define an existing link between two locations which can be used for
routed installations. Since the lengteh of a link between two locations does not neccessarily
mean their euclidean distance and a link can have a width and a height this information is given
by a scaling. A geometric zone groups geometric locations to a zone within a geometric component.
I.e. inside a car there are different locations which can be used for technical installations
such as sensors, constrollers or cables. There are links in terms of channels between these locations
which can be used to lay cables. Furthermore the car can be sectioned into different
27/ 156

Architecture Modeling
zones such as cargo bay or engine bay. In order to describe the external structure of a geometric
component there can be a shape.
Geometric component installations are specialized rich component properties. Having the
role of rich component parts they are instances of geometrical components and therefore typed
by them. Instantiated technical components can be allocated to these installations. I.e. a technical
ECU of a car is allocated to an installation of a representing geometrical component. Geometric
installations can be location installations or routed installations. A location installation
refers to a defined location of the containing geometric component. The location installation
specifies that a geometric component of its type is installed to that location and therefore to the
position which is specified by the translation releative to the reference system of the containg
geometric component. I.e. an acceleration sensor is installed to a location x = 0m, y=-20cm and
z=1,2m relative to the middle of the car. Routed installations declare a route for a geometric
component along several component links. They are used for layable components like cables or
pipes. I.e. in the car the mentioned acceleration sensor is connected to an ECU in the cargo bay
by a cable component that is layed via several locations with a total length of 3 m.
Geometric failures are specialized failure conditions. They describe failure conditions which
have effects on geometric structures. Therefore, a geometric failure can have a shape property
which describes the sphere of effect that a geometric failure has. I.e. the battery of a car can
explode and damage other components inside a sphere with a radius of 20 cm.
Geometric Coordinates Figure 3.19 provides an overview on concepts to describe geometric
coordinates.
GeometricScaling
+length 0..1 +width 0..1 +height 0..1 +x 0..1
GeometricTranslation
+y 0..1
Expression
+z 0..1+roll
0..1
GeometricRotation
+pitch 0..1
+yaw 0..1
Figure 3.19: Concepts of the geometrical perspective to cover coordinates.
Geometric coordinates are relative to the respective reference system. They are given by
geometric scaling, geometric, translation and geometric rotation.
Geometric Shapes Figure 3.20 provides an overview on concepts to describe geometric
shapes.
Geometric shapes describe the shape of a geometric component or the sphere of effect of a
geometric failure. They can be primitive shapes such as spheres, cylinders or cuboids. A sphere
is defined by its radius, a cylinder is defined by its radius and its length and a cuboid is defined
by its length, its width and by its height. A shape can be a mesh. A mesh is a user defined shape
which consists of vertices and edges. The position of a vertex is given by a translation relativ
to its reference system. Edges connect vertices. A complex shape is defined by a composite
shape. A composite shape consists of shape properties as operands respectively typed by shapes.
A shape composition operator defines how the operands together provide a shape. The shape
operators are defined as follows:
28/ 156

ShapeCompositionOperator
intersection
union
difference
Shape
Sphere Cylinder Cuboid
+radius 1 +radius 1 +length 1 +length 1 +width 1 +height 1
Expression
Architecture Modeling
+type
1
Mesh
+edge 0..*
Edge
«isOfType»
CompositeShape
Vertex
ShapeProperty
+ operator: ShapeCompositionOperator
+compositeShape
+vertex
1..*
+vertex
2
+operand 2..*
+scaling
0..1
+rotation
0..1
+translation
Figure 3.20: Concepts of the geometrical perspective to cover shapes.
intersection The composed shape is given by the intersection of the operands.
intersection The composed shape is given by the union of the operands.
0..1
0..1
GeometricScaling
GeometricRotation
GeometricTranslation
+position 1
difference The composed shape is given by the difference between the first and the second
operand. For this operator ony two operands may be given.
3.2.5.1 Optimizing Cable lengths based on function allocation constraints
The different perspectives have already been introduced in this document. Now a use case shall
demonstrate how the perspectives get used in a real life example from the automotive domain
and how transformations between them are performed.
The use case arises from the idea to split the airbag system up on to existing general purpose
ECUs. To avoid having very high safety integrity levels for the ECUs the functions of the airbag
system have to be deployed redundantly. To allow an ASIL (Automotive Safety Integrity Level)
reduction, the independence of the functions have to be ensured. This especially means that
the redundant function must not be deployed on the same ECU. The Airbag system consists
out of 4 ECUs, in this simplified example, that are distributed across the ego vehicle and a set
of pressure and acceleration sensors. Each logical airbag system part requires a known set of
sensors at known locations. If a function gets mapped to an ECU also the corresponding sensors
need to be connected to the same ECU.
The use case consists of the creation of the allocation of logical airbag systems to the ECUs
by fulfilling the independence constraints on the one hand side and resource availability on
the other side. The resources are given by the available interfaces on one ECU that limits the
number and type of connectable sensors. Furthermore the length of the cable from the ECUs
to the sensors shall be minimized to reduce the costs of the system. The use case is an excerpt
from an automotive design process that deals only with the optimization problem of reducing
the length of the cable that connect sensors and ECUs that are distributed across the vehicle
and the different constraints that limit the abilities of solving the problem. The independence
constraints are typically a result from different safety analyzes but are considered as given in
this use case.
The problem basically consists of combining three perspectives:
• The logical perspective, where safety constraints for the elements are expressed
29/ 156

LSI 1
Architecture Modeling
• The hardware perspective in which the connections between the sensors and the computers
have to be found
• The geometrical perspective which gives the possibility to evaluate the result of connections
by allowing to express distances and length for the cables
Accel. Left
Sensor
Left Side
Impact
Logical Perspective Technical Perspective Geometrical Perspective
Pressure Left
Sensor
Redundant
Airbag System
Right Side
Impact
Front
Impact
LSI 2 RSI 1 RSI 2 FI 1 FI 2
… …
Decomposition
…
Pressure Front
Sensor
Pressure Front
Sensor
Independence constraint
Port
ECU1
Accel. Sensor
Front Type
ECU Type
ASF1 ASF2 ASF3 ASF4
Acceleration
Sensor Type
ECU2 ECU3 ECU4
Accel. Sensor
Left Type
Sensor
Type
Inheritance
Accel. Sensor
Right …
Pressure
Sensor Type
…
Acceleration Sensor
Pressure Sensor
Figure 3.21: Airbagsystem on the different perspectives
(x,y,z)
(x,y,z)
(x,y,z)
(x,y,z)
ECU
Connection/Cable
Figure 3.21 shows a schematic of the example system on these perspectives. All relations
between the elements are only partially displayed.
Logical Perspective The logical perspective contains the “Redundant Airbag System” as its
root node, which is decomposed into the three individual systems for crash detection. Each of
them shall detect a specific crash scenario. A frontal impact is recognized by the “Front Impact
System” (FI) and left or right side impacts by the “Left Side Impact” (LSI) and the “Right Side
Impact” (RSI) systems. Therefore each of the systems is connected to a set of pressure and
acceleration sensors located on the specific side of the car. For redundancy each of the systems,
together with the needed sensors, are duplicated.
To ensure independence between duplicates, constraints are added to the systems. They
restrict their mapping to ECUs in the technical perspective. Constraints are formalized using
the pattern based RSL. For the LSI1 and LSI2 systems this constraint looks like:
LSI1 and LSI2 shall not be mapped together on same ECU-Instance
30/ 156

Architecture Modeling
The constraint consists of a constant phrase (denoted by the bold text) and a left and right
side. On the left side a conjunction of elements from the logical perspective are named (here:
LSI1 and LSI2). Their mapping is constraint with respect to the element(s) from the technical
perspective on the right side of the pattern (here: ECU-Instance).
Based on these constraints other constraints for the connected sensors of each system can
be derived. To ensure independence of the duplicated systems, each of their sensors must not
be shared between them. In our example sensors are assumed to be a exclusive resources, so
sharing is not allowed and no additional independence constraints are needed.
Technical Perspective On the technical perspective the airbag systems needs to be allocated
to ECUs and sensors. In our example we have four ECUs available, which are all of the same
type “ECU Type”. Each ECU instance has a series of ports with an incoming direction modeling
the possibility to connect equipment to them.
In the same way acceleration and pressure sensors are modeled. They have a base type (one
for acceleration and one for pressure sensing) and ports with an outgoing direction.
All ports are typed by a PortSpecification. Together with the direction information it is therefore
known which components can be connected. Such a connection between an ECU and a
sensor represents a cable in the airbag example. It is also possible to model the cable explicitly
with a separate component, which allows to specify additional properties, but in our example
the representation by connections is sufficient.
The mapping between elements of the logical and technical perspective can be done by
adding links to the model. This allocation can be used to formulate a mapping
problem or a solution. By allocating a logical sensor element on a technical sensor type
(e.g. “Acceleration Sensor Left Type”) the mapping problem to find a suitable sensor instance
of this type is specified. Alternatively the allocation target can already be a instance in which
case the allocation models a concrete mapping, i.e. a mapping solution.
In our airbag system the sensor systems are mapped to the corresponding sensor type in the
technical perspective. This way a problem space is created. Since two pressure and acceleration
sensors are available on each side the optimal one depends on the allocation of the systems to
the ECUs. Also the computational parts can be executed on any of the available ECUs. Thus
the allocation of the LSI, RSI and FI systems to ECUs is an open mapping problem. A solution
to such a problem must fulfill all needed sensor inputs of the subsystem and the independence
constraints associated with the system. By connecting ports of sensors with ports of an ECU a
cable is added to the system. To be able to calculate the resulting cable length the geometrical
perspective is used.
Geometrical Perspective The geometrical perspective is used to organize the information
regarding the position of the ECUs, the positions of the Sensors and the distance between these
elements. The distance is determined by the actual cabling in the car, i.e. that the distance is
influenced by the physical environment of the vehicle. Some cable can be put through the roof
of the vehicle directly while other cables have to be put through the vehicle chassis. This can
lead to a very different cable length from two nearby sensors to an ECU a fact which underline
the importance of the automation of the optimization process, since the obvious solutions are
most probably not the optimal ones.
Model Processing As stated above the allocation links between the logical and the technical
perspective are capable of creating an allocation space. The geometrical perspective provides
the information to evaluate the different possibilities to solve the allocation. Furthermore the
31/ 156

Architecture Modeling
provided interfaces on the ECUs and the required interfaces on the sensors limit the solution
space. This data can be transformed automatically to be used by solving algorithms for finding
a solution. This solution is transferred back into the model itself to generate architecture out of
requirements and physical constraints.
In Addition to architecture generation this technique can also be used for design space exploration.
For different existing alternatives the minimal existing cable length can be calculated
and compared. This approach differs from the typical design space exploration techniques since
the metric for comparing designs is not based on the design that has been created until the run
of the test, but on the quality of the solution that is possible to be designed in the future, based
on the design decisions already made.
This use case demonstrated that the geometrical perspective can be used as a valuable input
for architecture generation and design space exploration. Furthermore the close relations
between perspectives were demonstrated.
3.2.5.2 Identification of particular risks
On the geometric perspective a particular risk analysis (PRA) can be performed in order to
identify safety impacts of geometric installation decisions for a technical system under design.
In the PRA failures that are external to the technical system are identified and analyzed in the
geometric context of the system. The SAE-ARP 4761 defines particular risks as “events which
are outside the system(s) concerned but which may violate event independence claims because
they ’may influence several zones at the same time”’ According to EASA CS25 Book 2 subpart
F particular risks are “those events or influences, which are outside the systems concerned. [...]
Each risk should be the subject of a specific study to examine and document the simultaneous or
cascading effects or influences, which may violate independence.” Therefore, these events are
failures in the geometric perspective that implicate safety risks for the technical system under
design. Technical components that are verified in a functional hazard analysis (FHA) to be
functionally independent can fail together because all of them are involved into the effects of
failures on the geometric perspective. Thus, functional hazards can be reached because of the
geometric installation of components which are located in a way that they are impacted together
by a particular risk. The PRA allows the identification and classification of such risks. Based
on the results of a PRA the geometric installation of a system under design can be optimized in
order to prevent functional hazards.
Particular risks on the geometric perspective Relevant Particular risks for a system under
design depend on the geometric context in which the system operates. Common particular risks
are explosions, fire, heat, lightning, hits by foreign parts or leakage leading to evacuation of gas
or liquids. For an individual system the particular risks are specific. I.e. for a space vehicle
the effects of radiation or the impact of space debris have to be regarded. Tire burst, bird strike
or engine burst are particular risks that can lead to the evacuation and the impact of fragments
that damage or even destroy installed technical components of an airplane. According to EASA
AMC20-128A when analyzing the burst of an airplane engine there can be different fragments
which are single one third disc fragment, intermediate fragment, small fragment and fan blade.
Performing a particular risk analysis on a geometric model In order to perform a PRA
a model of the system under design in the geometric perspective must exist. Components of
a technical perspective are allocated to geometric components of this model. The geometric
components have geometric locations within the system under design. Therefore, the effect
32/ 156

Architecture Modeling
of particular risks in the geometric perspective can be traced to the respective installed technical
components. A particular risk is a failure condition for a geometric component which
has a description of the sphere of effect in its geometric context. Such a description can be a
shape which has a position and orientation relative to the component to which the particular risk
belongs. I.e. the particular risk of a released airplane engine fragment has a description of a trajectory
which describes its possible flight. This trajectory provides information about locations
which may be impacted by the released fragment. Since the relative speed of an airplane engine
fragment is very high the fragment will probably break though the skin of the airplane. Thus
the trajectory can be considered to be the complete sphere of effect for the airplane. For other
particular risks the spheres of effect can vary regarding parameters like mass, speed or orientation.
An interference analysis provides information between the sphere of effect of particular
risks, like the trajectory of a fragment, and parts of a geometric system under design. The result
of such an analysis is a hitlist. Such a hitlist specifies geometric component parts of the geometric
system under design that can take damage being affected by a paricular risk. Impacted
installations of technical components which host essential safety functions can be determined
that way. Furthermore the effect of particular risks can be other failures of components on the
geometric perspective such as leaks which again effect involvement of liquids.
Relationship of particular risks to the technical perspective Particular risks can have several
effects on the safety of technical components in a system under design. I.e. a hit by an
airplane engine fragment can lead to leakage of a fuel tank or damage of electric cables which
results in lost of thrust. Such safety impacts can be identified based the results of a PRA. The
destruction or damage of geometric components are again failure conditions. Using the allocation
relationship from technical components to geometric components these failure conditions
can be mapped to failure conditions of technical components. These failure conditions can be
analyzed in an FHA to identify safety hazards which result from particular risks. Thus, the violation
of functional independence on a technical perspective can be determined based on related
failure conditions of a geometrical perspective which result from a PRA. Safety risks can be
calculated to estimate the probability for a failure condition on the technical perspective based
on the probability of a particular risk on the geometric perspective. Furthermore the installation
of technical components can be optimized to improve the safety. Target of such an optimization
can be the installation of technical components in a way that they are not impacted together
by the same particular risk. Such an analysis and optimization can be embedded in a Common
Cause Analysis (CCA) as defined in ARP 4761.
Exemplary Particular Risk Analysis In an example the airbag system of a car is enhanced
by an emergency call system. Considerable particular risks can be water intrusion due to leaks
and a crash with an obstacle or another car. Loss of airbag and emergency call functionality
is a failure which shall not be reached. Function loss due to intruding water can be prevented
by improving covering materials. Thus, for this particular risk a safety analysis to optimize the
component installation is not important. But in a crash an ECU can be completely destroyed
by the forces that take effect from the crash. We consider the in time reaction of the airbag
system to release the airbag during a crash to be verified. An emergency call system shall be
hosted on the same ECU as the airbag system to ensure direct call of emergency services in
case of a crash. Therefore, the ECU that hosts the airbag controller still has to work correctly
after having released the airbag. This implicates additional requirements on the installation of
the ECUs to positions in the car. As depicted in figure 3.22 an installation decision for the
redundant airbag system with emergency call function can be analyzed in a PRA on the effects
33/ 156

Architecture Modeling
of a crash as a particular risk. The analyzed particular risk is a front crash in an angle of 146°
relative to the car’s orientation and a speed of 60 km h . The red trapezoid represents the sphere of
effect of the particular risk. This sphere of effect is based on a physical model that describes a
region in which the forces yield by the crash act in a destructive way. An interference analysis
shows that the geometric installations of both ECUs are inside the sphere of effect and therefore
affected by this particular risk. Thus, the redundant enhanced airbag system will fail in case of
this particular risk. This can be prevented by choosing another position for at least one of the
ECUs. Anyway, further particular risks like crash situations with other angles or different speed
have to be analyzed in order to identify a safe position.
Logical Perspective Technical Perspective Geometrical Perspective
Redundant
Airbag System
with Emergency
Call Function
ECU1
ECU2
ECU3
ECU4
(x,y,z)
Port ECU
(x,y,z)
Figure 3.22: PRA Analaysis for the enhanced Airbag-System
Front Crash
angle = 146°
speed = 60 km/h
(x,y,z)
Particular Risk Analysis in Architecture Modeling A model with relevant information
for a PRA covers following architecture modeling concepts. The geometric
system context is described by a GeometricComponent in the geometric perspective.
System components are specified as GeometricComponents, too. A
RichComponentProperty typed by a component of a technical perspective is allocated to
a GeometricInstallation of a GeometricComponent that represents the geometric
system component. The GeometricInstallation being a LocationInstallation
is assigned to a GeometricLocation and being a RoutedInstallation it
is assigned to a set of GeometricLocationLinkss and therefore to a set of
GeometricLocationss within the containing GeometricComponent. A particular risk
is a special GeometricFailureConditions of a GeometricComponent. It has a
34/ 156

Architecture Modeling
Shape that describes its sphere of effect. GeometricInstallations being impacted by
a particular risk are listed as a result of a particular risk analysis.
3.3 Heterogeneous Rich Components
The concepts of Heterogeneous Rich Components (HRC) and contracts both originate from the
European SPEEDS project. Both are key concepts of the architecture meta-model.
3.3.1 Component Model
The component concept of HRC is compatible to many other modeling languages that have a
component concept. For example the meta-model of AUTOSAR defines a set of templates, one
of which is the SoftwareComponentTemplate [8] that establishes the concept of a SoftwareComponent.
The interface concept in terms of ports and their types is more refined in AUTOSAR
than in HRC, but is still compatible. SysML also provides a component concept (referred to as
blocks) [39]. In fact, alignment with SysML was an important goal when defining the component
and interface concept of the architecture meta-model.
Port
+ isConjugated: Boolean
Variable
+port
0..*
0..*
+attribute
+component
Aspect
RichComponent
SystemRequirement +satisfies
Satisfy
1
+component
0..1
1..*
+component 1..*
+aspect
0..1
+component
0..1
+behavior
0..*
Behav iorImplementation
Behavior
Figure 3.23: Meta-model integration of the concept of components
BlockOccurrence
A component is a module with well defined interfaces and is the basic entity of any model.
Resuability of components is an inherent property of the proposed architecture modeling approach.
Note that the concept of components proposed here is not restricted to software components.
It is rather an approach of how architecture modeling should be done, fostering reuse
of models for different developed products as well as enabling computer aided verification of
integration of models. So a component can model a reusable software module, a specific sensor
measuring temperature or a computing device (e. g. an ECU or IMA-module) hosting software
applications.
Figure 3.23 depicts how the component concept is embedded in the architecture meta-model.
A RichComponent optionally encapsulates a realization of a certain aspect, which is aggregated
in the role of behavior. The association to Aspect from Behavior provides means
to categorize the realization in terms of the addressed aspects. Parts of the behavior realizations
can be exposed at the Ports of the component. The set of all ports is considered the syntactic
interface of the RichComponent. The optional realization of an aspect is complemented by
its specification. A specification of an aspect can be expressed by means of contracts.
35/ 156

3.3.1.1 Ports
Architecture Modeling
Ports are the interaction points of a component. The set of all ports of a component constitutes
its syntactical interface. Figure 3.24 depicts how the port concept is embedded in
the architecture meta-model. Each Port of a component has a name and is typed by a
PortSpecification, which declares the Flows or Services required or provided at
some port. A flow is a data-oriented interaction point and services model services a component
provides or requires. The PortSpecification is either a set of flows or a set of services,
but not both.
Port
+ isConjugated: Boolean
+port
+component
1
RichComponent
FlowDirection
in
out
bidirectional
0..*
FlowKind
discrete
continuous
event
+portSpecification
+type
PortSpecification
0..*
InteractionPoint
«isOfType» 1
1
+interactionPoint
Flow
+ direction: FlowDirection
+ kind: FlowKind
Serv iceDirection
provided
required
«isOfType» 1
Serv ice
+ direction: ServiceDirection
«isOfType»
+returnType 1
+type
DataType
+type
+service
0..1
1 «isOfType»
Figure 3.24: Meta-model integration of the concept of Ports
0..*
Parameter
+formalParameter
Flows have a name, a direction (in, out or bidirectional) and are typed by a
DataType. The DataType concept is explained in [50] and is out of the scope of this document.
A flow declares the kind of a data-exchange of an owning component. Along with the
DataType and direction, its kind can be specified, which is either event, discrete or
continuous (see Figure 3.25). Declaring an event flow means there is a value available on
the flow only at certain time instants and the value can change from instant to instant. In a
discrete flow the value is always available, even between the time instants at which the value
changes. In a continuous flow there is also always a value available, but it can evolve continuously
during time durations and also change discretely at time instants. The trajectory of a
continuous flow can be described by a piecewise continuous function.
val
event
t
val
discrete
Figure 3.25: The different kinds of flows
t
val
continuous
Services have a name and a direction (provided or required). A Service is typed by
multiple DataTypes, that constitute the signature of the service. As shown in Figure 3.24 a
service owns a set of DataTypes, that define the parameters of the service and a DataType
in the role of returnType, that defines the return value of the service declaration.
t
36/ 156

Architecture Modeling
Conjugation of Ports is a concept to reverse the directions of all InteractionPoints of
a port. As the direction of a flow or service is specified by the flow or service itself, the direction
of the port is defined by the direction of its InteractionPoints. When ports of components
inside a composition are being connected (see Section 3.3.2.2), the attribute isConjugated
of a Port can be used in order to avoid defining two PortSpecifications, which only
differ in the directions of their InteractionPoints.
3.3.1.2 Aspects
An aspect defines a viewpoint which is orthogonal to the structure of the system, and describes
aspects of functional and/or non-functional properties of component models. Being orthogonal
to the structure of the system-model means, that the underlying component-model and interfaces
of each component are the same for all aspects. Currently we consider three aspects for a
component: functional behavior, real-time and safety. However the meta-model allows to define
additional aspects according to the needs of a company or application domain.
Aspect
+aspect 0..1
Behavior
+aspect
0..*
0..*
+behavior
Behav iorImplementation
+component
0..1
BehaviorBlock
+type 1
«isOfType»
BlockOccurrence
RichComponent
1..*
Satisfy
+component
SystemArtefact
+satisfies
1..*
Requirement
+ rationale: String [0..*]
SystemRequirement
Figure 3.26: Meta-model integration of the concept of Aspects
For each Aspect a RichComponent can have a specification and a realization. The
specification of an aspect is given by a SystemRequirement, that is associated with one or
more Aspects. The Satisfy-trace link allows to associate a set of RichComponents with
one or more SystemRequirements that the components shall satisfy.
A realization of an aspect is given by a Behavior, that is eventually associated
with an Aspect. A realization can be modelled in any behavior modeling tool or
provided as implemented source code. The latter would correspond to the specialized
BehaviorImplementation. If a behavior modeling tool is used and it has a trace-based
semantics, then the modeled behavior can be interpreted as a BlockOccurrence. A realization
of an aspect provided as a BlockOccurrence can be verified against the specification
(see Section 4.3). The BlockOccurrence is typed by an HRC state machine, which is also
defined in the meta-model but not described here (cf. [50]).
3.3.1.3 Contracts
A contract is a triple (As,Aw,G). As is the strong assumption of a contract, Aw the weak assumption
and G the guarantee. A strong assumption characterizes the allowed design context
of the component, i. e. the environment from the point of view of the component. If the design
37/ 156

Architecture Modeling
context does not comply to a strong assumption, then this constitutes an ”illegal” out of specification
usage of the corresponding component. Weak assumptions structure contracts according
to cases wrt. the integration context. That means a strong assumption can be confined by a weak
assumption and for that particular integration context a more precise guarantee may be given.
If a component is used accordingly to its strong assumptions, it will guarantee the behavior
specified by the guarantee, provided the weak assumption is fulfilled.
TextuallyRepresentedElement
+ textualRepresentation: String
Assertion
ProcessRequirement
+stronglyAssuming
+weakAssumption
0..1
1
+strongAssumption
0..1
+guarantee
+aspect
SystemArtefact Aspect
Requirement
+ rationale: String [0..*]
SystemRequirement
Stakeholder
InformalAssertion FormalAssertion +assertion +formal BlockOccurrence
+type
BehaviorBlock
0..1
0..1
0..1
+weaklyAssuming 0..1
0..*
+stakeholder
0..*
0..1
«isOfType»
+guaranting
Figure 3.27: Meta-model integration of the concept of Contracts
In the meta-model the concept of contracts is represented by the meta-class
SystemRequirement (see Figure 3.27). The naming difference is motivated by the existence
of the concept ProcessRequirement. Both are requirements and we wish to emphasise
that by name. However the concept of ProcessRequirement is out of the scope of this
document and we will use the terms SystemRequirement and Contract interchangeably.
A Contract associates an Assertion in three roles, which correspond to the elements
of its constituting triple. An assertion can be either an InformalAssertion or a
FormalAssertion. Apart from this, an assertion always is a specification of the dynamics
exposed at the interface (InteractionPoints in all Ports) of a component with regard
to a certain aspect. The loose coupling of SystemRequirement and RichComponent
allows the reuse of a SystemRequirement and to associate it with different components via
the Satisfy-trace link. Note that when specifying assumptions (strongAssumption and
weakAssumption), they must not limit the output ports of the component. In turn the guarantee
(guarantee) must not limit the input ports of the component. If an assumption (strong
or weak) has not been specified for a contract, then they are assumed to be true. That means
a component associated with that contract is not restricted with regard to any design context,
which is most certainly not the case!
The BlockOccurrence is typed by an HRC state machine, which is also defined in the
meta-model but not described here (instead see [50]).
Tracability of requirements is an important concept in order to be able to reason about refinement
of them and to provide arguments to certification authorities how implementation require-
1
38/ 156

RichComponent
Architecture Modeling
Satisfy Refine
1..* +component
+refinedBy 1..* 1 +refinedReq
Requirement
+ rationale: String [0..*]
+satisfies
1..*
SystemRequirement
+entailed
1
+entailing
Figure 3.28: Meta-model integration of the tracing of requirements and contracts
ments have been derived from initial product requirements. The meta-model supports tracability
by different trace-links between Requirements and RichComponents (see Figure 3.28).
The Satisfy concept links SystemRequirements to RichComponents, indicating
the components that have to satisfy the aspect specifications defined by the
SystemRequirements. The satisfaction relation is discussed detailed in Section 4.3. Note
that RichComponents are linked to SystemRequirements and do not own them. This
allows both of them to exist independently from each other, i. e. from the meta-model point of
view it is not necessary to first create a RichComponent along with its syntactical interface
in order to specify a SystemRequirement (contract). Indeed this loose coupling makes it
possible to first specify a contract and to define a RichComponent at a later time and link it
to that contract.
The Refine concept links Requirements to other Requirements. The motivation is
to express that a requirement referenced in the role refinedReq has been refined by a set of
more detailed requirements referenced in the role refinedBy. One use-case for this trace-link
is to document requirement formalizations. How requirements can be formalized is discussed
in Section 4.1.
The Entail concept links SystemRequirements to other SystemRequirements.
The composition of the contracts referenced in the role entailing establish a refinement
of the contract referenced in the role entailed. The role of Entail-trace link in design
steps carried out during the development process is discussed in Section 4.2. In this document
we consider a formal interpretation of contracts linked by the Entail concept and call it a
refinement or entailment of contracts (see Section 6.3.2).
3.3.1.4 Requirement Specification Language
In order to ease the specification of contracts we provide a pattern-based requirement specification
language (RSL) (see Section 6.1), that can be used to specify the aspects of a
RichComponent or specializations thereof.
The RSL is basically a set of textual patterns, that can be instatiated in order to specify an
Assertion. For example the syntax of the pattern F1 is defined as:
1..*
Entail
39/ 156

Architecture Modeling
F1 whenever event occurs event [does not] occur[s] [during interval]
Phrases in square brackets are optional, bold elements are static keywords of the pattern, and
elements printed in italics represent attributes that have to be instantiated by the requirements
engineer. So a valid instance of the pattern F1 is:
whenever p1.f1 occurs p2.f1 occurs during [8ms,10ms]
The RSL provides patterns that have been categorized according to aspects they address. Despite
that categorization they may also be used for the specification of other aspects. For example
a Probability Pattern can be useful when specifying a failure hypothesis of components,
which clearly is a Safety aspect.
While the concept Contract (resp. SystemRequirement) and BlockOccurrence
is directly expressed in the meta-model, this is not true for the syntax and semantics of
RSL patterns. Figure 3.27 shows that an Assertion referenced in any of the three
roles strongAssumption, weakAssumption or guarantee is a specialization of
TextuallyRepresentedElement. The attribute textualRepresentation contains
that text. Multiple instances of RSL patterns would then be entered in that text field.
Thus, a set of pattern instances specifies a FormalAssertion of a contract, i. e. its strong
and weak assumptions and its guarantee. See Section 6.1.1 for a formal definition of RSL.
3.3.2 Hierarchy and Composition
Once components are defined by means of the RichComponent concept and their syntactical
interface has been specified by Ports, components can be instantiated in the context of
other components as parts forming a composition of components. That composition is again a
component, whose behavior is given by the behavior of its constituting parts.
3.3.2.1 Hierarchy
The instantiation of components in the context of other components is represented in the
meta-model by the RichComponentProperty concept (see Figure 3.29). A component
with its ports and contained behavior is referenced in the role of type by a
RichComponentProperty. That RichComponentProperty is in turn aggregated by
another RichComponent as one of its parts. The behavioral specifications characterized by
contracts that are linked to a RichComponent and corresponding realizations are also instantiated
in any RichComponentProperty typed by the RichComponent. It is allowed to
have multiple instances of the same component in the context of a composition. As this concept
can be applied recursively, it allows to construct deeply nested hierarchies of components. Note
that this is consistent with type/part concepts found in e. g. UML [41] and SysML [39].
3.3.2.2 Composition
When components are used as parts in another component, they have to be interconnected by
binding the flows and services contained in the ports. The concept of Interconnection
is owned by the same component which also owns the parts. An interconnection is either a
delegation connection or an assembly connection. The former links the interaction points of the
outer component, i. e. the composition, with interaction points of its constituting parts. So the
interaction points need to have the same direction. Assembly connections link the interaction
points of parts of a composition to each other. So their directions must be reversed.
40/ 156

MultiplicityElement
+part 0..*
RichComponentProperty
+component
1
+type 1
Architecture Modeling
«isOfType»
RichComponent
+component
1
+component
0..1
Port
+ isConjugated: Boolean
+attribute
+port
Figure 3.29: Meta-model integration of hierarchy concepts
0..*
0..*
Variable
In the meta-model there is no distinction between the two kinds because it can be deduced
from the context the kind of the connection. Both kinds of connections between Ports is captured
by the concept Connector (cf. Figure 3.31). In most other languages (also UML) the
interconnection of components in compositions is done by binding of ports. Since the architecture
meta-model allows to declare multiple InteractionPoints per Port the concept
FlowBinding, resp. ServiceBinding, allows to only bind a subset of the flows or services
defining a port. Thus, linking Ports by means of Connectors is semantically just a
short-cut to bind all interaction points of the Ports. Note that a PortSpecification may
either contain multiple Flows or multiple Services, but not both.
Directions are defined by the InteractionPoints themselves. in, out or
bidirectional are possible directions of Flows and provided or required are possible
directions of Services. Ports typed by a PortSpecification carry an attribute
isConjugated. If this attribute is set to true the directions of all InteractionPoints
in the corresponding PortSpecification are treated as if reversed. By default the value
of the attribute is false. This facility allows to specify peer ports, i. e. with the same flows or
services, but complementary directions.
CompC
part1:CompA pA pB part2:CompB
(a) assembly connection
pC
CompC
pA
part1:CompA
(b) delegation connection
Figure 3.30: Example for assembly- and delegation connections
FlowBinding and compatibility of Flows There are two case distinctions for binding
Flows by means of FlowBinding. If flows of different ports shall be bound establishing an
assembly connection like illustrated in Figure 3.30a, then the directions of both flows need to be
complementary (in for out, out for in, bidirectional for bidirectional). In the
case of delegation connections like depicted in Figure 3.30b, the directions must be the same.
Further the flows must be compatible. Two flows are compatible if they associate the same
DataType and their kind is the same.
41/ 156

Architecture Modeling
ServiceBinding and compatibility of Services There are two case distinctions for
binding Services by means of ServiceBinding. If services of different ports shall be
bound establishing an assembly connection like illustrated in Figure 3.30a, then the directions
of both services need to be complementary (required for provided and vice versa). In the
case of delegation connections like depicted in Figure 3.30b, the directions must be the same.
Further the services must be compatible. Two services are compatible if their signatures are
the same. That means they associate the same DataType as returnType and have identical
Parameters with regard to their name and types.
Connector and compatibility of Ports When defining assembly connections
or delegation connections between Ports by means of the concept
Connector, all InteractionPoints of the Ports defined by their corresponding
PortSpecification are bound. Which pairs of InteractionPoints are bound is
determined by name. All pairs of InteractionPoints (Flows or Services) must be
compatible as described above.
FlowDirection
in
out
bidirectional
FlowKind
discrete
continuous
event
Serv iceDirection
provided
required
Parameter
+part 0..*
RichComponentProperty
PortSpecification
1
+component
+type
1
+portSpecification
+formalParameter +service
0..*
0..1
1
«isOfType»
+type 1
«isOfType»
+interactionPoint
RichComponent
Port
+ isConjugated: Boolean
0..*
Serv ice
InteractionPoint
+ direction: ServiceDirection
+service 1..*
«isOfType»
+component
+port
«isOfType»
1
0..*
+port
1..*
+component
1
Connector
«instanceRef»
+interconnection
Flow
+ direction: FlowDirection
+ kind: FlowKind
+returnType
1
«isOfType»
+type 1
DataType
+type 1
0..*
Interconnection
FlowBinding Serv iceBinding
«instanceRef»
Figure 3.31: Meta-model integration of the composition concepts
+flow
1..*
«instanceRef»
Composition of Contracts: If a composition of components is specified by means of the
described concepts, that composition is correct with regard to the syntactical interfaces of the
parts and the composition. However it must also be ensured, that the contracts specified for
the components typing the parts are compatible and are a valid refinement of the contracts
of the composition. Figure 3.32 illustrates that relation. The components ComponentA and
ComponentB have contracts C1 resp. C2. They are used as parts in the context of the composition
ComponentC, which in turn has a contract C12. The contracts are linked to the
components by means of the Satisfy-trace link described in 3.3.1.3. When constructing
a composition, the relationship of the contracts associated with the concerned components is
specified by means of the Entail-trace link.
42/ 156

ComponentC
Architecture Modeling
part1:ComponentA
part2:ComponentB
ComponentB
C2
«Entail»
C12
«Entail»
ComponentA
Figure 3.32: Composition of components and contracts
Note that this link only declares the proof obligations which have to carried out in order to
ensure a sound (de-)composition. Actually one needs to verify, that the entailing contracts
are compatible, meaning the strong assumption of a contract must not be violated by another
component, which is connected to it. If the entailing contracts are compatible, it must
be checked if the entailing contracts are indeed a refinement of the entailed contract.
Related to the example sketched in Figure 3.32, Compatibility of C1 and C2 needs to be verified
and the pair {C1,C2} must be a refinement of C12. We call such proof obligations Virtual
Integration Testing, which is discussed in Section 4.2.
3.4 Mapping Component Parts
In Section 3.1 the Realize-trace link has been introduced, which allows to trace component
realizations when switching abstraction levels. In Section 3.2 the Allocate-trace link has
been introduced, which allows to trace component allocations between different perspectives.
Both concepts are similar and therefore the superordinate concept of Mapping has been defined.
+type 1
RichComponent
+component 1
«isOfType»
+part 0..*
+mappedTo
RichComponentProperty
1 «instanceRef»
+mapped
1
«instanceRef»
TextuallyRepresentedElement
+ textualRepresentation: String
Allocate
Mapping
0..1
Realize
+mapping
+formal
1
MappingBlock
+mappingBlock 0..1
+behavior 1
BlockOccurrence
1
Serv ice
C1
+ direction: ServiceDirection
+mappingBlock
+mappingLink
«isOfType»
+service 0..1
«instanceRef»
0..*
+type
1
Flow
+ direction: FlowDirection
+ kind: FlowKind
MappingLink
BehaviorBlock
Figure 3.33: Meta-model integration of the mapping concepts
+flow 0..1
«instanceRef»
Figure 3.33 shows how a Mapping relates two parts of components
(RichComponentProperty) to each other. Further a mapping is formalized by means of a
MappingBlock, that has a BlockOccurrence, which is typed by a BehaviorBlock.
The concept of MappingLinks link flows or services of a component taking part in the
43/ 156

Architecture Modeling
mapping relation to pins of the BehaviorBlock (for BehaviorBlocks and Pins refer to
[50]).
A mapping specifies correlations of observable behavior of components by a formal specification
of how dynamics of InteractionPoints of one RichComponentProperty
are projected on corresponding behavior of InteractionPoints of another
RichComponentProperty. As the mapping relates component parts, the context
of both RichComponentProperty needs to be described. Therefore the concept of
instanceRefs is used, which has been inspired by the AUTOSAR and EAST-ADL
meta-models.
An InstanceRef defines a particular navigation within future M0 instance trees of M1
classifiers. The reason is that the concept of reusable RichComponents lead to a situation
where a flat M1 model of hierarchical components specifies deep, tree-like M0 instances. That
means when mapping parts of components on M1 level, one needs to describe navigation paths
in order to uniquely identify the parts. The problem when dealing with reusable structural
hierarchies and the concept of InstanceRefs is detailled described in [7].
44/ 156

4 Steps in Component-Based Design
The SPES architecture meta-model (SPESMM) intends to support development of complex
systems involving a large number of different engineers. In such a process, it is essential to
specify the roles and responsibilities of each engineer: who is responsible for ensuring what,
and under which conditions. Only if this is ensured, integration problems in later design phases
can successfully be identified and fixed.
In SPESMM, first class citizens are components and their interfaces. Components may interact
with each other and with the environment by means of their interfaces, thus forming
a model of the intended system. The SPESMM supports the development process in that it
allows to represent roles and responsibilities of engineers by corresponding concepts in the design
architecture. For example, engineers are usually responsible for distinct parts of the design.
Design artifacts have to be constructed, refined, and implemented in different perspectives and
at different abstraction levels. The SPESMM allows to (formally) express responsibilities for
components in form of contracts, which are an instance of the assume/guarantee specification
style. If different engineers, responsible for certain design artifacts, have to integrate the respective
parts of the design, contracts allow to define under which conditions this integration will be
successful. The same holds for example, if different engineers are responsible for specification
and implementation of certain components. SPESMM provides means to reason about under
which conditions an implementation satisfies the corresponding specification.
The underlying concepts of the SPESMM particularly allow to define proof obligations that
have to be performed in order to ensure whether responsibilities defined for model and component
interfaces are satisfied. In an early design step for example, functionality of the system may
be identified, together with a set of requirements to be satisfied by those functions. When in
a subsequent design phase decomposition of the system into logical components is performed,
it should be explicated which logical components are responsible to guarantee which system
functionality. If this is done ”the right way”, the SPESMM allows the application of tools that,
if not performing proof obligations automatically, explicate which proof obligations have to
be performed in order to ensure satisfaction of the identified function requirements. This section
intends to provide an overview of those concepts related to establish a continuous design
process, and to provide traceability of requirements and the corresponding relations between
design artifacts.
Typically, a design process along the SPESMM involves many different design steps:
• Entry point is the operational perspective, where system boundaries are identified, and
the relevant goals, or initial requirements, are defined.
• The system is then decomposed into distinct functions provided by the system in order to
achieve the goals. Functionality may be further refined into sub-functions in this phase.
Furthermore, requirements are identified for the respective functions which are typically
related to the initial goals and requirements.
• Functionality is partitioned into logical components providing the intended functions, and
45/ 156

Architecture Modeling
• Logical components are allocated to a technical system that distinguishes software, processing
and communication hardware, mechanical, hydraulic, and electrical components.
• The technical components are finally allocated to a geometrical space.
The design phases may be performed on different levels of abstraction, representing different
refinements of the initial design.
It should be noted that the SPESMM does not define a concrete design flow. For example,
not all design phases have to be performed on all abstraction levels. Even the number of abstraction
levels and perspectives may vary between different design processes. We can however
identify a set of primitive design steps that are repeatedly applied during such design processes.
More precisely, each design step identified in a certain process supported by the SPESMM can
typically be broken into a sequence of such primitive steps:
Decomposition Most component types defined in the SPESMM can be decomposed. That
is, components are broken down into smaller parts, or sub-components. This includes
for example functions that are decomposed into sub-functions, and the decomposition of
logical components.
Allocation Components within different perspectives of a design are entangled in that they
represent (partly) the same system entities. Functions for example are allocated onto
logical components.
Realization During the design process, the same system may be represented at different levels
of abstraction. We say, the system at a certain abstraction level (and the same perspective)
realizes the system at the higher levels.
Implementation Finally, components gets implemented. Depending on the perspective and abstraction
level, implementations may be automata models, StateCharts, MatLab models,
and even C-Code. Given a characterization of the responsibilities of a component and an
implementation, does it satisfy the responsibilities?
Each design step introduces a set of proof obligations clearly defining under which conditions
all responsibilities of the involved design artifacts are satisfied. This in advance allows to define
clear interfaces between the responsibilities of all engineers involved in a design process. In the
following, the corresponding proof obligations and involved model artifacts for each identified
primitive design step shall be discussed.
4.1 Formalizing Requirement Specifications with Contracts
In order to define how modeling along the SPESMM supports the primitive design steps, it is
important to understand the concept of contracts. In short, contracts characterize components
following the assume/guarantee reasoning style:
• The assumption of a contract defines under which environment conditions a component
is expected to work, and
• the guarantee characterizes ensured behavior of the component, given that the assumptions
are satisfied.
46/ 156

Architecture Modeling
Assume/guarantee reasoning is known for a long time. Various formal foundations exist
providing means to validation and verification of a design, and to ensure validity of design steps
such as decomposition and refinement. Contract based design with explicated assumptions is
however also a design philosophy:
• Contracts allow to differentiate responsibilities. A component is responsible to satisfy its
guarantees. But contracts also define responsibilities of the environment of the component,
that is, the conditions under which the guarantee holds.
• Contracts enable reuse. When a component is designed, the contexts it is expected to
work properly can be specified by means of (strong) assumptions.
Given for example a braking system of a car, one could state the requirement that the component
BrakingSystem must be able to absorb a certain amount of kinetic energy (depending,
beside other, on the mass and maximum speed of the car) within some maximum time. Such
requirement can be stated in terms of a contract. While the respective component is required to
perform its action within a maximal time span, the requirement also states that this only holds
for a certain maximum energy to absorb. Obviously, the component cannot (and should not) be
responsible to bound the kinetic energy of the whole car, but only to absorb it fast enough.
This indeed has also impact on the proof obligations for that component: For any implementation
of that component for example, it does not have to be verified that it satisfies the
requirement under all possible conditions, but only for those defined by the assumption. Moreover,
the component, once validated for all possible environments defined by the assumption,
can be used in any such context without further satisfaction validation. However, other proof
obligations exist for such cases, as explained in Section 4.2.
To be more formal, a contract C of a component as defined in the SPESMM is a triple
C := (As,Aw,G)
where As and Aw are the assumptions, and G is the guarantee of the contract. The distinction
between strong (As) and weak assumptions (Aw) deviates from traditional assume/guarantee approaches,
and affects two aspects when dealing with contracts: From a methodological point of
view, it may be desired for contracts to distinguish two types of assumptions. Strong assumptions
characterize the environment of the component to work correctly (strong assumptions).
Such characterization may be further refined by weak assumptions, discriminating for example
different contexts of the respective component (weak assumptions).
In this sense, strong assumptions rather correspond to the traditional idea of assume/guarantee
reasoning discussed before, while weak assumptions rather correspond to different settings in
which the component is intended to be used. This shall become more clear by an example:
• An air conditioning system of an airplane shall provide air of a certain quantity, temperature
range and humidity to the fuselage.
• A requirement may define for example the range of environmental conditions under which
the air conditioning system shall operate, say at an altitude between 0 and 12500m. In
our context, this requirement would be expressed as a strong assumption.
• Other requirements typically discriminate different modes of operation. For example, the
air temperature provided may be different when the air conditioning systems works in
normal operation mode, and when some components have failures.
47/ 156

Architecture Modeling
• In both cases, provided air must be within a certain range. This range could be between
12 ◦ C and 28 ◦ C in normal mode, while in degraded mode the maximum allowed temperature
may be 32 ◦ C. These requirements are the guarantees of the air conditioning system,
one for each corresponding weak assumption.
The distinction between strong and weak assumptions may also affect the way to verify certain
properties involving formal reasoning about contracts. This discussion is however out of
scope of this section, and the interested reader is referred to Section 6.2. From a user perspective,
strong assumptions can be seen as to be assigned to components instead of contracts. All
contracts associated to a component shall maintain the same strong assumptions. If we use in
the following the term assumption of a contract without attribution, we refer to the conjunction
of both strong and weak assumptions.
Deriving (formal) contracts from (informal) requirements is not always an obvious and easy
task. To avoid ambiguities, often formal languages are used to state requirements with well
defined meaning. It however does not only require some training to write requirements in such
formal languages, it may also be hard to read them. The pattern based Requirement Specification
Language RSL provides an easy to use formal language with well defined semantics, that is still
readable like natural language. RSL patterns consist of static text elements and attributes being
instantiated by the requirements engineer. Each pattern has well defined semantics in order
to ensure consistent interpretation of the written system specification across all project participants.
RSL allows writing of natural sounding requirements while being expressive enough
to formalize complex requirements. To gain a high degree of intuition, the language consist of
only a few constructs that can be easily remembered, to give the user the possibility to fully
understand the RSL and to choose the right pattern that fits the properties he wants to demand
of the system.
RSL aims at providing expression of a large scale of requirement domains. It defines patterns
for each of the following categories:
• Functional patterns express requirements such as relationship between events, handling
of conditions and invariants, and optional intervals in which a requirement (or parts of it)
is valid.
• Probability patterns, which are needed in almost all safety critical systems to express
failure or hazard probabilities.
• Safety related patterns outline relationships between system components. These patterns
enable the specification of single point of failures or other failure and hazard dependencies
between different components.
• Timing patterns are used to describe real-time behavior of systems. This includes recurring
activations, jitter and delay.
RSL patterns normally contain optional parts that need not be instantiated. A functional
pattern for example describing causality between two events looks like this:
whenever event1 occurs event2 occurs [during interval]
Phrases in square brackets are optional, bold elements are static keywords of the pattern, and
elements printed in italics represent attributes that have to be instantiated by the requirements
engineer. In the example above three attributes event1, event2 and interval exist, and the part
[during interval] is optional.
48/ 156

Architecture Modeling
When specifying requirements there is no strict typing like int or real but there are categories
that specify what is described by the different attributes. To not complicate the language too
much and to be also expressive enough, the set of supported attributes has been carefully chosen:
• Events represent activities in the system. An event can be for example a signal, a user
input by pressing a button, or the availability of a computational result. Events occur at
specific points in time and have no duration.
• Conditions are logical and/or arithmetical expressions over variables and the status of
events. Conditions can be used in two different ways. Firstly, they can be used as pseudo
events to trigger an action if the condition becomes true. And secondly, they may represent
the system state that has to hold for a specified time.
• Intervals describe a continuous fragment of time whose boundaries are either (relative)
time measures, or events. Intervals can be open “]x,y[“ or closed “[x,y]” or a combination.
• Components refer to entities that are able to handle events or condition variables.
RSL supports various combinations of elements. It allows for example filtering of events by
intervals or conditions. That is, whenever a pattern expects an event, one may also use “event
during interval”, or “event under (condition)”. Thus, one can e.g. specify
whenever request during [activate,deactivate] occurs response occurs during [l,u]
meaning that a response is constrained only if the request happened after an activate and before
some deactivate event. Filtering of events can be applied recursively. So activate could again
be filtered by some interval or condition.
The interested reader is referred to Section 6.1 for a detailed description of the RSL.
While specification languages such as RSL help the engineer to formalize requirements, there
are other pitfalls when specifying contracts. Two key properties of contracts, essential to maintain
sanity of the design-flow shall be discussed here, namely receptiveness and consistency.
Receptiveness Since the interface of a component distinguishes input ports and output ports,
there is a clear separation between those ports the component controls and those that are controlled
by the components environment. Receptiveness denotes the fact that also the responsibilities
of both assumption and guarantee of a contract are properly distinguished. More formally,
a contract is receptive only if the assumption does not restrict possible behavior of the output of
a component, and if the guarantee does not restrict the input ports.
To give an example, we assume a component with inport i and outport o. A guarantee stating
that, whenever the component sends an event to o, the environment responds by another event
send to i within, say 5 ms, violates the receptiveness property. It violates receptiveness because
it is not the duty of a components guarantee to require the environment to react in a certain
amount of time. For the same reason, an assumption stating that the component produces an
output event each 10 ms violates receptiveness. On the other hand, an assumption for such a
component, stating that whenever the component sends an event to o, the environment responds
by another event send to i within 5 ms, perfectly maintains receptiveness. A receptive contract
is denoted directed.
49/ 156

Architecture Modeling
Consistency Consistency captures the fact that a set of contracts is not contradictory. An
inconsistent set of contracts is not usable at all, because it does not allow for any useful implementation.
The most easy way to get an inconsistent set of contracts is to define an ”empty”
guarantee for any possible context. For example, we could state the following guarantees: (i)
whenever the component receives an event from its environment, the next event on its output
will be a, and (ii) whenever the component receives an event from its environment, the next
event on its output will be b. If we do not further restrict the behavior of the environment (for
example by saying that this happens under no conditions), the result will be inconsistent.
A detailed discussion about receptiveness and consistency together with formal definitions
can be found in Section 6.2.1.
4.1.1 Functional Specifications
A simple example for contract-based specification of functional requirements is depicted in
Figure 4.1. It shows a possible design of an air conditioning system at the logical perspective.
The interface of the (logical) component has been identified during former design steps. Not all
relevant ports have been shown, but we see a port providing status information about the current
air temperature (airTemp), an input port allowing to select the temperature (tempSelect),
and ports representing the current air flow (airIn, airOut).
The figure shows also some requirements associated to the component, stated in terms of
contracts. The specification is largely simplified and even does not follow correct RSL syntax.
The green part is the (strong) assumption of the component. The figure reflects the fact, that
all contracts of a component share the same strong assumptions. Blue parts are the guarantees.
Weak assumptions are yellow. In our case, they are always true and thus do not further restrict
the environment.
-20°C

Architecture Modeling
next selection. The second assertion defines what happens before this minute. Obviously, it
should not be allowed that the temperature provided after a new selection becomes too high
or too low (maybe due to inappropriate heating or cooling). The specification of the second
guarantee thus states, that temperature fluctuation is within an appropriate range, i.e., the first
momentum of some hull curve of the difference is less than 0.
4.1.2 Real–Time
The very same system could be instantiated at lower abstraction level as depicted in Figure
4.2. It shows a chain of components involved to perform the air conditioning function.
A tempSens component represents the sensor acquiring the temperature of the fuselage. The
sensor values are captured, stored for later use (such as visualization), and forwarded to the
temperature control component AirTempControl. The control component calculates control
parameters with respect to the incoming temperature and the selected one (not shown), thus
implementing a classical control loop. The AirCondition component models a physical
part, possibly consisting of heating and cooling elements, compressors, etc.
temp occurs each 50ms
with jitter 5ms
tempSensor
Delay between temp and tempData within [5ms,7ms]
tempData occurs each
50ms with jitter 10ms
temp tempData
Capture
Delay between tempData and control within [10ms,12ms]
control
AirTempControl AirCondition
Figure 4.2: Real-Time Contracts Example
Derived from the demands of such control loop (e.g. with respect to stability), it might be
required that the loop is executed periodically with a certain period and maximum jitter. Due
to other demands, maximum delays might needed to be satisfied by the control loop. These
requirements belong to the classical real-time domain, and can be represented by a set of realtime
contracts as depicted in the figure.
The contract associated to the component Capture specifies the strong assumption that the
component gets an input each 50ms with a maximum jitter of 5ms. Under this condition, the
component is required to deliver the sensor value within a time span of 5 to 7ms.
A similar contract is assigned to the control component, stating that the maximum jitter is
10ms, and the requirement to deliver control parameters between 10ms and 12ms after it has
received an input.
4.1.3 Safety
Looking at components under the safety aspect requires to address the dysfunctional behavior
of them. When designing a redundant architecture, for instance, the specification needs to
express that a functional failure can only occur when failures in (all) redundant sub-functions
can occur. A typical contract thus looks like as depicted in Figure 4.3. The contract has the
51/ 156

Architecture Modeling
strong assumption true since it holds for any environment. The weak assumption states that
the contract holds under the condition that the underlying hardware (BSCU) does not fail. In
this case, the braking system fails only if both redundant sub-systems hydraulic system A and
hydraulic system B fail.
true
BrakingSystem
BSCUFails does not fail
BrakingSystemFails shall only fail if HydraulicSystemAFails &&
HydraulicSystemBFails
BSCUFails BrakingSystemFails HydraulicSystemAFails HydraulicSystemBFails
Figure 4.3: Safety Contracts Example
Since failure conditions are usually complex, abbreviations can be defined for them:
failureCondition TooMuchEnergyConsumption is defined by:
(consumption > 2) holds longer than 2s
Later, these abbreviations may by used to simplify the definitions of safety-related patterns.
4.2 Virtual Integration Testing
Technically, a component may be a (composed) system, which is constructed from a set of
(sub-) components. In more detail, a system is given by a set of components, an interface and
a set of named (inter-) connections. An interface is a set of directed ports, denoted inports
and outports, respectively. Each port specifies a set of typed (data) flows or services 1 . In the
following, we assume for simplicity that ports specify single flows. Hence, we identify ports
and their corresponding flow. Furthermore, we abstract in the following discussion from the
fact, that we have to distinguish between components and instances of components. This fact is
important in the sense, that contracts are defined on components and not on instances (which are
referred as RichComponentProperty in the SPESMM). Thus, if we have two instances
of the same component, we have to uniquely identify the respective ports of these instances.
Otherwise, from a formal point of view, contracts cannot distinguish behavior of different ports.
If, for example, L and R in Figure 4.4 would be instances of the same component, the ports
would have the same name, and could not be distinguished from a semantical viewpoint without
unique identification.
A connection links two ports. It either links two sub-component ports, one outport and one
inport (e.g. port l2r), or one port of the system interface and one sub-component port with
the same direction (e.g. port r2e), or two system interface ports of opposite direction. Each
sub-component inport and each system outport must be linked to exactly one other port. Linked
1 We omit a discussion of services here, which can be seen as a derived concept.
52/ 156

Architecture Modeling
ports must have the same type (we do not treat issues related to types in depth, here, so we adopt
this simple principle for ease of exposition). A simple sample system is depicted in Figure 4.4,
where only the connection names and not the port names are given.
Figure 4.4: Simple example system
In a design process, composed systems usually do not exist a-priori (except in case of re-use),
but are the result of a concrete design step. For example, due to a design decision, it may be
found that an initially identified air condition system shall be realized by a sequential composition
of different sub-systems. The first subsystem may provide air from the environment, the
second one has to bring this air to its correct temperature, and so on. Contract-based design
helps in such situation not only to allocate responsibilities for the respective sub-components,
but also to trace back whether the requirements of the component are satisfied when all of
its sub-components satisfy their “local” requirements. The corresponding proof obligations are
subsumed by so-called Virtual Integration Testing (VIT). The term virtual is due to the fact, that
these proof obligations are independent from the implementation of the respective components.
That is, if a virtual integration test has been performed successfully, any set of implementations
satisfying the responsibilities of the respective sub-components are inherently covered by the
VIT. We will discuss satisfaction of an implementation in Section 4.3.
VIT defines the conditions under which the contracts of all sub-components, when put together,
satisfy the contract(s) of the parent component, and which verification steps have to be
performed in order to establish this property. The relevant property is denoted refinement and
is discussed in Section 4.2.2. VIT also defines proof obligations necessary to verify that two
(or more) components can be put together reasonably at all. Component R in the figure above
could for example state, that the input values on its input l2r always are below, say, 30 ◦ C. If the
guarantee of component L would state that its output on l2r is always between 25 and 35 ◦ C, it
would obviously be problematic to put L and R together. Compatibility of contracts is discussed
in Section 4.2.1.
Compatibility is however only one property necessary to properly compose components. As
for the contracts of a single component, VIT also requires that the composition of components
does not violate receptiveness and consistency. This becomes particularly evident when components
are composed to form a control loop as in Figure 4.4 via ports l2r and r2l, where inports
and outports of components are mutually connected. Thus, a reasonable design methodology
relies on receptiveness and consistency for composing components.
Another proof obligation of VIT, that shall not be discussed here in detail, concerns some
form of stability. In the figure above, contract CL could for example state that the output on
l2r becomes 0 if the input r2l is 1, and vice verse. Contract CR could equivalently state that
the output r2l becomes 0 if its input l2r becomes 1 (and vice verse). Although the respective
contracts are compatible, and even strongly consistent, the resulting system will not be stable,
53/ 156

Architecture Modeling
if there is no delay greater 0 specified in which toggling output takes place in the components.
This property is well-known, and also important in many formalisms used in control- and also
in real-time scheduling theory. In the context of the FOCUS methodology for example, it is
denoted strict causality. Strict causality ensures (beside other important properties) that proof
obligations of VIT can be performed sequentially.
4.2.1 Compatibility and VIT Condition
As stated before, two (or more) components will “work together” properly, only if they are compatible.
Due to the fact that components are characterized by their specifications, compatibility
is defined for contracts.
Compatibility reflects the distinction of responsibilities in that strong assumptions about the
environment of a component must not be violated by another component that is connected to
this component. Technically, this property is expressed by the following definition: Given
components L and R with contracts C L = (A L s ,A L w,G L ) and C R = (A R s ,A R w,G R ), respectively,
where only output ports of L are connected to input ports of R, it must hold
G L =⇒ A R s
(4.1)
that is, if the guarantee of component L is satisfied, then it will “satisfy” the strong assumptions
of component R.
If also output ports of R are connected to input ports of L, it further must hold
G R =⇒ A L s
To give an example, let GL be that statement that its output port o delivers values within
a range of [25,35] ◦C. It characterizes any possibly “behavior” of such temperature over the
time that is not lower than 25◦C and not higher than 35◦C at any time point. This specification
would satisfy an assumption AR s , stating that the temperature is in the range [20,40] ◦C. A more
detailed definition of “behavior” can be found in Section 6.2. However, Equation 4.1 states that,
if component L satisfies its guaranteed behavior, then this will also satisfy the assumption of R
about its environment.
Such definition of compatibility is in “simple” situations a necessary condition. It however
neglects the fact, that composites typically have an interface to their environment. In Figure 4.4
for example, there are four other ports of the composite component to its environment, namely
e2l, l2e, e2r and r2e. Moreover, it also defines compatibility for single contracts only. Since
the parent component of a composite usually also has assumptions about its environment, compatibility
of the composite must take this assumptions into account. Suppose for example, that
the input port e2l of component L specifies some air flow. Suppose further, L has the (strong)
assumption that this air flow is bounded by, say, 50l/s. If now the parent component S has
the (strong) assumption that this flow is bound by, say, 100l/s, the whole composition may
become contradictory with respect to receptiveness and consistency as discussed before. It is
obvious to see why. The specification for L assumes that the input flow is below 50l/s. Only
if this assumption applies, L is bound to its guarantee. Otherwise, its behavior is unspecified.
Compatibility on the other hand relies on the guarantees given by the respective components.
In other words, compatibility holds only if all guarantees given by the involved components are
adhered to.
Formally, compatibility in the general case is defined as follows. Given a component with
strong assumption As, and sub-components with contracts Ci = (Ai i, j
s,Aw ,Gi, j ), compatibility is
(4.2)
54/ 156

established if (and only if):
Architecture Modeling
As ∧C 1,1 ∧ ... ∧C n,mn =⇒ A 1 s ∧ ... ∧ A n s
We denote such compatibility a (strong) VIT Condition. The strong VIT condition is a sufficient
criterion for compatibility of components as further discussed in Section 6.2.
4.2.2 Refinement
The second proof obligation of VIT is to ensure that the composition of sub-components “satisfies”
the responsibilities of the respective parent component. To this end, the concept of refinement
is introduced. We say, a specification (say contract) C ′ refines another specification C if
and only if the behavior specified by C ′ is a subset (or maximal equal to) the behavior specified
by C. Formally, we say:
C ′ refines C if and only if [[C ′ ]] ⊆ [[C]]
where [[.]] formalizes what is meant to be the “behavior” specified by the contract, as defined in
Section 6.2.
To give an example, for the following requirements
• C1 ≡ whenever i is in the range of [2,5] then o = 2 i , otherwise o = undef
• C2 ≡ whenever i is in the range of [1,7] then o = 2 i , otherwise o = undef
where i and o are real-valued ports, it holds that C2 refines C1. This is not because it refines
the input behavior (which in fact is not the case, since in both contracts i may be arbitrary), but
because the output behavior is more confined in C2.
The same definition holds also for sets of contracts. A set of contracts C ′ 1 ,...,C′ m refines
another set of contracts C1,...,Cm if:
[[C ′ 1 ∧ ... ∧C ′ m]] ⊆ [[C1 ∧ ... ∧Cn]]
It is not trivial in any case to formally show refinement between contracts. Theories about
contract-based design thus introduce various sufficient conditions for refinement for ease of
verification (cf. [11]). An intuitive (and often easier to check) property is that of dominance.
We say, a contract C ′ dominates a contract C if (and only if) it holds:
[[As]] ⊆ [[A ′ s]] and [[Aw]] ⊆ [[A ′ w]] and [[G ′ ]] ⊆ [[G]]
That is, (i) the assumptions (both strong and weak) C ′ makes about the behavior of the environment
is less restrictive than or equal to that of C, and (ii) the guarantee C ′ provides confines
or is equal to that of C. It is easy to see that, if C ′ dominates C, then C ′ is also a refinement of C.
Checking for dominance often greatly reduces complexity when performing proof obligations.
Particularly in the case of decomposing components, where assertions to the environment
are often simply “copied” to the composite of the respective component. The same often holds
for the guarantees. In such cases, simple syntactical equivalence of assertions can be performed
in order to verify refinement. On the other hand, decomposition often involves introduction of
new contracts, specifying responsibilities for the interaction between sub-components. In many
situations, composition of components lead to the (logical) elimination of contracts such that
the proof chain ends up with single contracts. An example for this is discussed in the following
section.
55/ 156

4.2.3 Examples
VIT Example for Functional Contracts
Architecture Modeling
In the following, the application of VIT is discussed by a set of simple examples. We start with a
example for VIT checking of functional specifications as depicted in Figure 4.5. It shows an air
conditioning system providing tempered air. The AirTempSystem component has input ports
for the currently selected and the current temperature, and an output port for the temperature
of the provided air. The corresponding contract to AirTempSystem states that the difference
between selected and current air temperature must be at most 0.5 ◦ C. The contract further states
that whenever some temperature has been selected, it takes at most 60 seconds for the system to
provide air of this temperature. The strong assumption of the contract has three parts. The first
part states that the selected temperature is in the range of between 12 ◦ C and 35 ◦ C. The second
part states that the sensor value actTemp for the actual temperature is updated each 20 ms.
And the third assumption requires from the environment that the actually measured temperature
must not differ more than 0.2 ◦ C from the provided air.
C1
C2
C
tempSelect
actTemp
12°C < tempSelect < 35°C
actTemp occurs each 20ms
always abs(actTemp –
flowTemp) < 0.2°C
AirTempSystem
12°C < tempSelect < 35°C
actTemp occurs each 20ms
whenever chg(tempSelect) occurs nomTemp = tempSelect
holds during [10ms, chg(tempSelect) [
Whenever actTemp occurs control.act = actTemp &&
control.nom = nomTemp occurs within [12ms, 14ms]
tempSelectStore
AirTempControl
whenever chg(tempSelect) occurs abs(flowTemp – tempSelect) <
0.5°C holds during [60s, chg(tempSelect) [
nomTemp
C3
control occurs each 20ms
with jitter 2ms
control
AirCondition
Figure 4.5: VIT Example with Functional Contracts
whenever control occurs abs(flowTemp - control.nom) <
abs(control.act - control.nom) + epsilon holds during [10ms, control [
flowTemp
In order to perform VIT, we start with the VIT condition stating that the strong assumption
of the component, together with all local contracts must imply all local strong assumptions.
As Figure 4.6 shows, this is trivial to see for the local contracts C1 and C2. For C3 =
(A3s,A3w,G3), we can employ existing results from real-time analysis allowing us to derive
a periodical activation pattern for the occurrence of control events from contract C2. This
concludes the strong VIT condition, requiring that all strong assumptions of the sub-components
are satisfied if the strong assumptions of the parent component is (and if all local contracts are
satisfied). Interestingly, the example shows that different aspects of a design are often closely
entangled, in this case the functional and the real-time aspect.
Showing satisfaction of the guarantee of C needs a little more effort. Firstly, we can derive a
new guarantee from C1 and C2, and G3 that replaces in G3 occurrences of control.nom by
56/ 156

12°C < tempSelect < 35°C
actTemp occurs each 20ms
always abs(actTemp –
flowTemp) < 0.2°C
12°C < tempSelect < 35°C
actTemp occurs each 20ms
control occurs each 20ms
with jitter 2ms
Architecture Modeling
whenever chg(tempSelect) occurs abs(flowTemp – tempSelect) <
0.5°C holds during [60s, chg(tempSelect) [
whenever chg(tempSelect) occurs nomTemp = tempSelect
holds during [10ms, chg(tempSelect) [
Whenever actTemp occurs control.act = actTemp &&
control.nom = nomTemp occurs within [12ms, 14ms]
control occurs each 20ms
with jitter 2ms
whenever control occurs abs(flowTemp –
tempSelect) < abs(actTemp- tempSelect) +
epsilon holds during [10ms, control [
whenever control occurs abs(flowTemp - control.nom) <
abs(control.act - control.nom) + epsilon holds during [10ms, control [
Figure 4.6: VIT Example with Functional Contracts: Proof Chain
tempSelect. We can further calculate which epsilon is needed in G3 to achieve a maximal
temperature difference of 0.5 ◦ C for the air conditioning. To this end, we need the activation frequency
of the AirCondition component (20 ms), the maximum delay for control.act
to become the value of the selected temperature in case of a modification of tempSelect
(24 ms).
The maximum change of the selected temperature is 23 ◦ C. Due to the activation period,
the air condition has about 6000 cycles to achieve this temperature change (within 60 seconds
minus delays). So in each cycle, the temperature change must be at least ≈ 0.004 ◦ C. Together
with the assumption about the maximal deviation of airTemp from the air flow temperature
(0.2 ◦ C) of C, we can further derive the guarantee of C. Due to this we have shown dominance
C against the local contracts, which concludes the VIT.
VIT Example for Real-Time Contracts
Figure 4.7 depicts another simple decomposition situation of another part of the same system.
The local components have real-time contracts associated stating about the activation pattern
and maximum delays. The contract of the parent component AirTempSystem in fact specifies
an end-to-end deadline. Note that all assumptions in this example are strong.
The proof chain of the VIT for the example is shown in Figure 4.8. We start VIT by
showing compatibility of the local contracts C1 and C2. To this end, we derive a new guarantee
from the local contract C1 = (A1s,A1w,G1). According to [23], C1 implies contract
C1 ′ = (A1s,A1w,G1 ′ ) where:
G1 ′ = actTemp occurs each 50ms with jitter 7ms
With this, one can easily show implication of the strong assumption A2s of contract C2, and
thus G1 ′ =⇒ A2s. Since the whole system is acyclic, stability is not an issue here. Also
receptiveness is not an issue for such real-time contracts, because the assumptions reason about
input ports only, and the guarantees reason about the delay between inports and outports. The
whole system thus satisfies C1 ∧C2 =⇒ A1s ∧ A2s.
Furthermore, it can be shown that assumption As is a strict subset of A1s. This in advance
completes the strong VIT condition, and also the first part of the dominance relation between C
and C1 ∧C2 (all weak assumptions are true).
57/ 156

AirTempSystem
C1
C
temp occurs each 50ms
temp occurs each 50ms
with jitter 5ms
C2
Architecture Modeling
Delay between temp and actTemp within [5ms,7ms]
actTemp occurs each
50ms with jitter 10ms
temp actTemp
Capture
Delay between temp and control within [15ms,20ms]
Delay between actTemp and control within [10ms,12ms]
AirTempControl
Figure 4.7: VIT Example with Real-Time Contracts
control
Due to the fact that, when C1 is satisfied, then also the assumption of C2 is satisfied (remind
that C1 and C2 are compatible), we can eliminate A2s. If both guarantees G1 and G2 are satisfied,
both together satisfy G because the result of G1 ∧ G2 is a simple addition of delays. This
completes the proof chain.
temp occurs each 50ms
temp occurs each 50ms
with jitter 5ms
Delay between temp and actTemp within [5ms,7ms]
actTemp occurs each
50ms with jitter 7ms
actTemp occurs each
50ms with jitter 10ms
!
Delay between temp and control within [15ms,20ms]
Delay between temp and control within [15ms,19ms]
"
Delay between actTemp and control within [10ms,12ms]
Figure 4.8: VIT Example with Real-Time Contracts: Proof Chain
VIT Example for Safety Contracts
Modeling safety aspects is usually more elaborated than for real-time, since specification of
failure conditions and dependencies are often rather complex. A simple application example of
VIT for safety shall however be discussed. Figure 4.9 shows an abstract model of a wheel brake
system. The BSCU controls a hydraulic system, that provides the brake force to a wheel, by
sending commands via CMD AS. The braking system is redundantly implemented. Both BSCU
and Hydraulic contain the relevant parts twice. The figure shows that BSCU is composed of
two redundant control units BSCU1 and BSCU2. The control units take the (also redundant)
brake pedal positions (PedalPos1 and PedalPos2) and calculate respective commands
(CMD AS1 and CMD AS2) to control the hydraulic system. Both controls units maintain validation
ports (Valid1 and Valid2) indicating whether the commands send are valid or not.
58/ 156

Architecture Modeling
The component ValidSwitch takes these signals and decides whether the BSCU is considered
to deliver valid commands. The SelectSwitch finally takes the commands send by
the respective control units. In normal operation mode, it relays the commands from the first
control unit to the hydraulic system. If the first units fails, SelectSwitch switches over to
the second unit. In order to keep the example simple, the redundancy concept of the hydraulic
system is not shown here.
PedalPos1
BSCU1
CMD_AS1
C
always not(fail(PedalPos1))
&& not(fail(PedalPos2))
BSCU
Valid1 Valid2
Valid
Switch
Select
Switch
PedalPos2
BSCU2
CMD_AS2
always not(fault(BSCU1)) or
always not(fault(BSCU2))
C1
always
not(fail(PedalPos1))
C2
always
not(fail(PedalPos2))
CMD_AS
Valid
Hydraulic
always not(fail(CMD_AS1)) or
always not(fail(CMD_AS2))
always not(fault(BSCU1))
always not(fault(BSCU2))
Wheel
Figure 4.9: VIT Example with Safety Contracts
always not(fail(CMD_AS1))
always not(fail(CMD_AS2))
Figure 4.9 also shows some safety contracts. The top-level contract C = (As,Aw,G) defines as
the strong assumption that the brake pedals never fail to send correct position values. The weak
assumption of C states that the contract holds for such situations where not both redundant control
units fail together. In this case, the contract guarantees that at least one of the command lines
delivers correct commands to the hydraulic. Note, that this safety case is strongly simplified. A
comprehensive safety analysis usually would incorporate much more complex situations. For
example, none of the components ValidSwitch and SelectSwitch are considered here.
It is furthermore a rather unrealistic requirement that both brake pedals never fail.
We however assume that a further outcome of safety analysis are two local contracts for the
redundant control units. C1 strongly assumes that PedalPos1 never fails. The weak assumptions
captures situations where BSCU1 does not have a fault. In this case, C1 = (A1s,A1w,G1)
guarantees that the commands send by BSCU1 are correct. A similar contract C2 is defined for
BSCU2.
Showing satisfaction of VIT for this example is simple. We can firstly observe that As =⇒
A1s ∧ A2s, since As equals to A1s ∧ A2s. This proofs the strong VIT condition. Furthermore, it
holds that Aw =⇒ A1w ∨ A2w because Aw equals to A1w ∨ A2w. Assuming satisfaction of C1
and C2, we get A1s ∧ A1w =⇒ G1 for C1, and A2s ∧ A2w =⇒ G2 for C2 by definition.
If we put all four implications together, we can derive As ∧ Aw =⇒ G1 ∨ G2. Since G1 ∨
G2 =⇒ G because of, again, equivalence, we have shown dominance. This concludes the VIT.
59/ 156

4.3 Satisfaction
Architecture Modeling
Although implementation aspects are not considered here 2 , implementing identified components
is a primitive design step, and thus the necessary proof obligations shall be discussed.
Formally, the contracts of a component characterize allowed behavior of the component. Thus,
any implementation of a component must satisfy its contracts. In other words, an implementation
of a component satisfies its specification if its behavior does not violates its specified one,
or, it must not behave other than proposed by its specification. That way, the behavior of a
component defined by its implementation can be seen as a refinement which has to be shown:
M is a correct implementation of C if and only if [[M]] ⊆ [[C]]
where M denotes an implementation of the respective component.
SPESMM provides concepts to specify implementations for components employing the same
underlying formal semantics as for contracts. This is however convenient only for some special
cases and thus SPESMM does not rely on it. It rather provides an open and extensible approach
to integrate any kind of implementations such as Real-Time StateCharts, MatLab models and
even C-Code. That way, it is left to the needs of the respective design processes to reason
about satisfaction, and to define sufficient and necessary conditions based on the needs, e.g., for
certification.
4.3.1 Establishing Functional Specifications
At least two different approaches can be distinguished to establish functional specification:
formal verification due to model-checking, and testing.
4.3.1.1 Establish functional specifications with model-checking
Formal verification of functional behavior is a well-established research area, and various formalisms
and model-checking techniques have been developed so far. The AutoFocus and the
FUJABA Real-Time tool suites for example provide effective functional verification. Formal
verification techniques for Real-Time StateCharts and also for MatLab Simulink models exist.
Exhaustive verification is indeed a challenging task due to complexity reasons. There are however
industrial relevant approaches. For example, C-Code verification by model-checking is
known to be effectively applicable for a number of years.
4.3.1.2 Establish functional specifications with testing
Another way to establish functional contracts is due to HIL-testing. To this end, the implementation
is executed on a prototyping platform, and execution traces are captured while running
the system. In a subsequent hosted simulation, the traces are checked against the (executable)
contract specifications. Indeed also other ways exist for testing, such as the implementation of
the specification which runs in parallel to the implementation code. Also often more abstract
implementations are considered, which is the domain of simulation.
2 see for example Sections 3 and 6.2
60/ 156

Architecture Modeling
4.3.2 Establishing Real-Time Contracts
In fact, real-time contracts can be established by employing the same techniques as for functional
contracts. However, establishing real-time requirements is the traditional domain of realtime
scheduling theory. Implementations of the involved components, usually called tasks, are
taken in order to calculate execution times for invocations of the respective components. Due
to a characterization of the underlying (computational) resource, scheduling analysis calculates
worst-case scenarios in order to verify whether the requirements about maximal delays are satisfied.
Since real-time contracts usually define activation scenarios for components, and maximal
delays, real-time scheduling scheduling theory fits well to establish real-time contracts. For
more complex real-time contracts, and at higher abstraction levels where no detailed characterization
of the underlying resources exist, more involved analysis techniques can be applied
such as combination of scheduling analysis and model-checking. In order to improve efficiency,
model-checking techniques can be combined with testing approaches [14].
4.3.3 Establishing Safety Contracts
One possible way to establish safety contracts is to perform a traditional safety analysis (like
fault tree analysis) on an implementation model of the system enriched with failures. The
enriched model contains the nominal as well as the dysfunctional behavior of the system. This
allows to formalize the causality between failures resp. failure combinations and their effects.
As a consequence, notions of (minimal) cut sets and fault trees can be formally related with a
given implementation of the system.
4.3.3.1 Establish safety specification with testing
Based on the enriched model, both the nominal and dysfunctional behavior may be simulated.
Equipped with coverage notions that address that all failures and their combinations need to be
covered, test strategies can be designed to check that the expected safety contracts hold.
4.3.3.2 Establish safety specification with symbolic methods
Similar to the approach for functional specifications, safety contracts can also be established
by symbolic methods that compute the causality between failure combinations and their effect.
Here again, the crucial property of these methods is that they are complete (with respect to the
model enriched with failures). A detailed example for this approach is given ins Section 5.1.3.4.
4.4 Deployment
While the design steps discussed before reason about components of a particular design, two
further design steps are important with respect to different perspectives and abstraction levels,
that is, for the interfaces between whole models.
Perspectives At a certain abstraction level, a system may be designed “from left to right”.
Starting with the operational perspective, requirements engineering results in identifying the
system boundaries and interfaces, and some top-level requirements, often called goals. In the
functional perspective, the functions of the system are identified that are needed to achieve these
goals. In the logical perspective, components are identified that perform the identified functions,
61/ 156

Architecture Modeling
and so forth. Each of such design steps usually involves an assignment of requirements to
the identified components. Some requirements are usually derived from formerly identified
requirements, while other requirement occur due to the introduction of new components and
interfaces.
To stress the air conditioning example, we may have the requirement for an air-conditioning
function (in the functional perspective) to provide air from the environment of an airplane with
certain quantity and temperature. To show the simplest form of deriving a requirement for the
logical perspective at the same abstraction level, there may be exactly one logical component
performing the air conditioning function. In such a case, it seems to be obvious to assign the
same requirement to the logical component as to the corresponding function.
In more complex settings, logical components may perform several functions (sequentially,
parallel, or in any other order), or several logical components may be involved performing a
single functionality. Here, deriving requirements for one perspective from another may be more
complex, particularly for the latter case. 3
The same can be said for the relation between logical and technical components. A logical
component may be performed by a single technical entity. It may be also performed by a
composition of different entities, may be involving mechanical, computational and other components.
Indeed there may be requirements that are unique to specific perspectives. For example,
geometrical constraints such as packaging sizes, cable lengths, and so on become important
only in the geometrical perspective. On the other hand, there are typically requirements that
are important for multiple perspectives. Requirements identified for system functions for example
are important in order to establish justification for proper system design. Satisfaction
of those requirements can however often not be established in the functional perspective, e.g.
due to missing specification of internal behavior. SPESMM provides concepts to reason about
requirements across different perspectives, and to establish the corresponding relations.
Abstraction Levels The same problems that occur with respect to reasoning about contracts
across different perspectives hold for abstraction levels. When a system is designed incrementally,
the same system is represented at different levels of granularity. Although various refinement
steps can be established by decomposition of components, there are other cases where
changing the abstraction level is more appropriate. This may be simply due to organizational
boundaries, where different departments in a company are responsible for certain subsystems.
A more formal reason is the fact, that refinement not always follows a decomposition approach,
but demands for more complex m-to-n relations.
Note that there is no explicit deployment defined for different aspects of components. The
reason for this is, that the specification of different aspects has no direction. Instead, aspect
specifications of a component are often closely and interdependently entangled, and relations
between different aspects of specifications have to be made explicit. An example for multiaspect
specification can be found for example in [18].
4.4.1 Mapping
Since the requirements for creating interfaces between perspectives and between abstraction
levels are very similar, the SPESMM introduces the common concept of mapping. Technically,
3 A convenient way to circumvent such problems is to start with a surrounding component that uses decomposition
to achieve the intended result, and that keeps the simple one-to-one relation between functions and logical
components
62/ 156

Architecture Modeling
a mapping is similar to a component. It has interfaces consisting of ports, and it has internal
behavior defined in terms of an HRC state machine. Its interfaces are however not used for
interaction with other components but to relate different models. As Figure 4.10 shows, a mapping
connects (arbitrary) ports of two different models of a design. Mappings are asymmetric
in that the roles of connected model artifacts are different. A mapping can be considered as an
observer of one of the participating models. In Figure 4.10 for example, the depicted mapping
“observes” the behavior of component S of the right hand model. Due to its internal behavior,
a mapping provides a well defined (possibly modified) view to the behavior of the “observed”
model. More important, the observer approach gives means to the fact, that models of a design
are closely related to each other. Model artifacts within a perspective at a certain abstraction
level are allocated to artifacts of other perspectives, and artifacts at a lower level are considered
to realize those of a higher abstraction level. In this sense, a mapping provides the foundation
to reason about satisfaction of an observing model by another (observed) model.
Logical Perspective
temp occurs each
50ms
temp
Delay between temp and control within
[20ms,25ms]
AirTempSystem
control
Mapping
Technical Perspective
tempVal
temp
temp
Data
control
Var1
ECU
Capture
Task
Figure 4.10: Mapping Example
Scheduler
airTemp
CtrlTask
Technically, a mapping can be used to “replace” components within the observing model, as
depicted in Figure 4.11. While replacing, the mapping gets associated with the set of contracts
that have been associated to the replaced components. This gives means to the proof obligation
corresponding to the question whether the observed model satisfies the contracts defined for the
observing model. In fact, the situation is very similar to those of virtual integration testing. If
the resulting system, containing the mapping and the observed model, is considered as a single
component as shown in Figure 4.11, the same proof obligations apply as for VIT. However,
refinement has to be shown not for the composition of all contracts in the observed model, but
only for the composition of those contracts that are associated to components having links to the
mapping. The result is that, whenever the contracts of the components of the observed model
are satisfied, then the contracts of the observing models are also satisfied with respect to the
internal behavior of the mapping.
Mappings thus provide well-defined interfaces between artifacts of models within different
perspectives and abstraction levels. However, the corresponding proof obligations are valid only
with respect to the behavior of the mapping. Mapping can for example be used to perform interface
refinement. The upper part of Figure 4.12 shows a component with an outport providing
some integer valued data. At the next lower abstraction level, the same component has a refined
port providing 3-Bit digital data. The mapping shown in the figure “converts” the 3-Bit values
of the refined component into (more abstract) integer values. In this example, the internal be-
Var2
tempSel
63/ 156

temp occurs each
50ms
Delay between temp and control within
[20ms,25ms]
Architecture Modeling
Mapping
Technical Perspective
tempVal
temp
temp
Data
control
Var1
ECU
Capture
Task
Scheduler
Figure 4.11: Mapping: Proof Obligations
airTemp
CtrlTask
havior of the mapping provides the necessary conversion in order to reason about the intended
refinement relation between both representations of the component. Due to internal behavior of
the mapping, confidence of the result of a refinement check also depends on the faithfulness of
the mapping. For sake of traceability, mappings can be associated with contracts to allow formal
specification of their behavior. When proof obligations are violated during the design process,
mapping contracts may give means to reason about the faithfulness of the chosen behavior of
the involved mappings.
€
€
temp ∈ IN
temp = 4⋅ temp 2 + 2⋅ temp 1 + temp 0
€
temp0 ,temp1 ,temp2 ∈{0,1}
Capture
AirTempSystem
tempData
control
AirTempControl
Figure 4.12: Mapping with Interface Refinement
Two properties are essential when dealing with mappings:
Completeness Contracts are always associated to components. More precisely, contracts are
restricted to reason about the interface of the associated component. In order to obtain welldefined
relations between contracts, mappings are required to establish port relations that are
complete with respect to all associated contracts. If for example in Figure 4.10, only the right
port of component AirTempSystem would be linked to the mapping, the component could
not be replaced without provoking inconsistency of the model.
Receptiveness Mappings are required to be receptive. Their internal behavior must not restrict
any contracts of the observed model.
control
Var2
tempSel
64/ 156

Architecture Modeling
Another important issue when dealing with mappings is locality. Since there are no constraints
in the number of mappings to link certain models, it should be best practice to keep the
number of linked ports for a mapping as low as possible. The benefit it twofold: on one hand,
locality maintains traceability on the relation between contracts of different models. On the
other hand, it supports also locality of the respective proof obligations. However, each mapping
must be verified.
4.4.2 Allocation
While mappings provide the common concept to establish traceability in a design, the SPESMM
provides two instantiations of this concept. An allocate link associates two components within
different perspectives. The intuition of an allocate link is that the source component is “executed”
by the target component of the link. A function is executed by a logical component, and
a logical component is executed by a technical component. The intuition also holds if we say
that a technical component is “executed” by a box in the geometrical perspective.
The allocate link is a high-level construct in that for each link an underlying mapping is
created. Each allocate link thus requires further specification with respect the underlying mapping.
In many cases however, simple mapping functions are sufficient to define allocations.
SPESMM allows to refine allocate links by additional links specifying simple one-to-one relations
between ports, and by textual specification of such one-to-one relations within the mapping
object.
Figure 4.13 depicts an example for using the allocate link. The link shown allocates logical
component Capture to task CaptureTask in the technical perspective. The link is associated
to a mapping object that has been further refined (not shown in the figure) to specify that
the respective ports are directly linked.
Logical Perspective
temp tempData
Capture
4.4.3 Realization
AirTempControl
control
Technical Perspective
tempVal
temp
temp
Data
control
Var1
ECU
Capture
Task
Figure 4.13: Allocate-Link Example
Scheduler
airTemp
CtrlTask
The second high-level construct are realize links that associate components between different
abstraction levels. Since the realize link is the twin of the allocate link, the same holds as said
before.
Note however, that the direction of both allocate and realize links are converse. For realize
links, the source component by convention associates the observed components with respect to
Var2
tempSel
65/ 156

Architecture Modeling
the underlying mapping, while for allocation links, the observed components is denoted by the
link target.
temp
AirTempSystem
temp tempData
Capture
control
AirTempControl
control
Figure 4.14: Realize-Link Example
66/ 156

5 Using the Architecture Meta-Model
Design processes for embedded systems applications differ strongly within the range of application
domains considered in SPES 2020. In automation applications, the geometric layout of
the plant is determined early in planning stages, and defines boundary conditions for other design
phases. In contrast, while of course medical devices such as pace-makers must ultimately
fit into a physical packaging easily insertable into the body, other aspects such as algorithm
design are more dominant. Similarly, almost no industrial application will be developed purely
top-down, nor purely bottom-up, and tradeoffs such as between optimizing re-use and optimizing
for performance will determine the middle-out design strategy for a particular product
development. Finally, target architectures are often subject to domain specific standards, such
as AUTOSAR [9] in the automotive domain, and IMA in avionics, calling for a need to support
a variety of domain specific standards within the SPES Architecture Metamodel. The purpose
of this section can thus not be to describe something as “the SPES design process”. Rather, the
purpose of this section is to show how a broad variety of design styles and design processes can
be naturally expressed using the key concepts of the SPES Architecture Metamodel.
An orthogonal aspect covered in this section relates to the advocation of a contract-based
design style. We highlight, how typical design steps in industrial processes can benefit from
contract-based design, thus motivating the anchoring of this design paradigm in the SPES metamodel.
We cover these orthogonal aspects in separate sections. The style of writing is chosen so as
to address a typical systems engineer. Having read the quick tour (Section 2) is an indispensable
prerequisite for this section. Readers who are interested in more formal treatments of the
mentioned design steps are referred to Section 4 – “Steps in component based design” – and its
mathematical foundation given in the annex.
5.1 On the Role of Perspectives and Abstraction Layers
5.1.1 What We Can Learn from the EDA Domain
Electronic design automation (EDA) has early adopted the concept of abstraction layers (to cope
with complexity) and perspectives (there called “domains”) to achieve separation of concerns
between different views of an integrated circuit, such as its physical layout, its logical architecture,
and its behavior (see Gajski’s Y-Chart [25]). Established abstraction levels include (from
lower to higher) the transistor level, the gate level, the register transfer level, the system level,
and the instruction-set architecture level. Each level is essentially characterized by what is seen
as a primitive building block at the chosen level of abstraction. The identity of the building
block is obvious from the level name for the transistor and the gate level. For the register transfer
level, these blocks include both combinational circuits such as adders, multipliers, shifters,
etc., as well as sequential circuits such as latches, registers, register-files, and the various types
of memory. The naming of the next higher level is predominantly used in the domain of computer
architecture design, where clock-cycle accurate models describe the effect of executing
instructions on the visible processor state. The term system-level, then, traditionally referred to
67/ 156

Architecture Modeling
the organization of the overall computer system, in terms of CPUs, MMUs, bus-systems, I/O,
caches, memory etc. Note that this layering also motivates the wording of “abstraction layers”.
In fact, different design styles for integrated circuits are characterized by what abstraction
level is taken as a design basis. E.g., in gate-level design, a higher degree of automation is
achieved by taking gates as primitives (from a design library), while full-custom design processes
capitalize on the capabilities of building custom complex gates from transistors, and
most notably from the capability of optimizing the layout of individual transistors to optimize
performance. In contrast, in gate-level design, the internal realization of employed gates is
completely hidden, and designs are build purely based on characterization of such standards
cells as given in design libraries. Note also, that the type of underlying computational models
differs drastically between design levels. As an example, differential equations are used as
models to characterize how the transistor current is dependent on various parameters such as
the gate-to-source voltage, or the drain-to-source voltage. In contrast, at gate level design, such
continuos dynamics are abstracted to a boolean, discrete time domain, e. g. for gates and other
combinational circuits to boolean functions and maximal and minimal propagation delays.
Perspectives (in EDA jargon: domains) are orthogonal to these. The geometric perspective
(in the EDA domain, sometimes also called “physical domain”) speaks about the physical realization
of the integrated cuircuit. E.g. on the transistor level, the physical dimensions of all
materials used to realized transistors, such as the gate’s aspect ratio, the thickness of the insulation
layer below the gate, the extension of drain and source, but as well the routing of wires
on the layers of the integrated circuits and their physical dimensions etc. are described in a
standardized way allowing automatic production of the integrated circuit. With increasing integration
density, the system-level, which in the 80’s would talk about placement of ICs and their
interconnections on the printed cuircuit board, has moved to the level of on-chip positioning of
multiple processor cores, on-chip interconnection networks, on-chip cache hierarchies, etc. In
short, the geometric perspective covers all abstraction layers, and allows to physically build the
complete system, using the blue-prints or the physical realization of lower abstraction levels.
The information of what components, then, are to be built, and, in particular, how they are
connected comes from the technical perspective. Here, the focus is on architecture: how can
we architect a modern processor from RT-primitives supporting multiple-issue of instructions,
out-of-order execution of multiple instructions using multiple functional units and multi-port
register files, etc. This design is typically done not only using abstraction (that is, through the
concept of abstraction layers), but also by disregarding the physical realization of the system,
i. e. the geometrical perspective. This conscious choice of (initially) ignoring the geometric domain
comes with a price: clearly extra-functional characteristics of the integrated cuircuit are
highly dependent on the physical layout, and thus any analysis e. g. of timing aspects is only
indicative, since it typically ignores propagation delays induced by routing, and delay characteristics
of library elements are based on assumptions on capacities which can only be checked
in the physical domain. Yet, in spite of these caveats, and the lack of a formally establishable
link between extra-functional aspects in the technical perspective and the counterpart in the
physical perspective, industrial practice shows, that the productivity gains obtained by initially
disregarding the impact of the geometric domain by far outweigh the costs coming from patches
required to compensate for non-tolerable changes in such characteristics.
Finally, the behavioral domain is used, at each of the above abstraction layers, to capture the
specification of what the component of the circuit should do. Examples include the specification
of an instruction-set architecture, of caches, of a multiplier, of a complex gate, or, at the lowest
level, “Kennlinien”, i. e. curves characterizing the desired dependency of the drain-to-source
current in terms of other parameters.
68/ 156

Architecture Modeling
Design processes can then be described as trajectories in a two-dimensional design space
spanned by abstraction levels as horizontal dimensions and the three perspectives focussing on
behavior, architecture, and geometry as vertical dimensions. Typical steps include:
• Synthesis: This starts with a behavior specification on level N and produces a technical
architecture on level N-1, i. e. shows how primitives of level N-1 can be interconnected to
realize the level-N behavior specification by combining the lower level components based
as prescribed in the level-(N-1) architecture.
• Analysis: Takes a level-(N-1) netlist and “computes” the emergent behavior at level N.
• Implementation: Shows how to realize a level-N component in the physical domain.
• Integration (placement and routing): Combines level-(N-1) layouts of level-(N-1) components
according to a level-(N-1) architecture to build an implementation of a level-N
component.
In platform based design, we pick some abstraction level N as design basis, and assume as
given a library of level-N components, where each library element is given in all three perspectives
and characterized w.r.t. all aspects required for a complete automation of the design
processes (e. g. required voltage levels, leak currents, propagation delays etc). The determination
of the design basis comes from trade-off analysis involving costs, performance, design
time, etc. Clearly, lowering the design basis allows higher levels of optimization, at the price
of increased design time. Hence, even for one and the same application, the actual design
process will be determined by business constraints. Moreover, this shows the need to address
both library design and application design. We finally notice, that the degree of automation of
synthesis and analysis steps is increasing when moving to lower abstraction layers, as does the
automation of placement and routing. Implementations today are largely either given by design
libraries or derived with placement and routing. In incremental design, only parts of the system
are re-designed, in a way striving to minimize the impact of this re-design on the surrounding
components. Standardization and in particular standardized bus systems and interfaces are key
instruments allowing to completely localize the effect of such component replacements.
All of these have contributed to an exponential productivity boost in the EDA domain, allowing
so far (by adding higher and higher abstraction levels, such as Transaction Level Modeling)
to compensate the exponential growth in functionality realized in integrated circuits.
5.1.1.1 What We Want to Achieve for Embedded-Systems Based Product Development
We expect to achieve similarly productive boosts for embedded-system design through the introduction
of the architecture meta-model based on abstraction layers and perspectives in combination
with the contract-based multi-aspect component based design technique of Hierarchical
Rich Components, which allows to build design libraries at any abstraction layer, supporting all
phases of embedded systems product development. The large number of domain specific standardization
activities in Embedded Systems design (such as AUTOSAR, IMA) gives clear evidence
of the industrial drive to boost productivity through standardized interfaces, standardized
meta-models, and standardization of non-differentiating design components. Different design
styles (or, in “our” jargon, different design processes) can again be captured by different trajectories
in this richer design space. Concepts such as platform based design, synthesis, placement
and routing, etc., have natural counterparts. For the geometric domain, vendors of CAD and
PLM tool suites have gone a long way in providing industry strength design automation support,
69/ 156

Architecture Modeling
and are gradually enlarging their scope towards other perspectives, such as reflected in the move
by Dassault Systems 1 to integrate UML modeling tools, or their recent acquisition of Geensoft.
Vendors of modeling and specification tools offer increasingly higher abstraction levels supported
with simulation, analysis, and synthesis capabilities, and are increasingly opening their
tools to allow integration into tool chains to cover the complete design space. Environments
such as Eclipse have been instrumental in such tool integration activities.
5.1.2 Perspectives and abstraction layers in system-level design
The geometric perspective is offered to cover the physical layout of the system-underdevelopment.
As mentioned above, this is the classical domain of tools such as CATIA 2 or
the Siemens PLM suite 3 . While clearly the 3D design of products is out of scope of SPES, the
constraints coming from this, and in particular the concrete positioning of components of the
technical architecture as well as their interconnection, are of key relevance, since they impact
non-functional aspects and induce locally constraints.
Within the technical perspective, we propose to capture all design artifacts which jointly
support the realization of a new product function and which have a one-to-one correspondence
to physical entities in the geometric domain. By the fact that system-development processes
address the realization of functions of the complete product under given quality requirements
(notably safety), all aspects of hydraulic and mechanical subsystems relevant to achieving this
must be assessed to a level of detail ensuring sufficient observability by the supporting embedded
systems to assess their health status and react to this. Thus, at higher abstraction levels, the
internal realization of a system in terms of mechanical, hydraulic, and electronic subsystems are
visible, in our proposal as rich components, thus not only specifying interfaces between these,
but as well for all relevant aspects of the design contracts formalizing what each subsystem is
assuming to be guaranteed by other subsystems. E.g. for the safety aspect, such contracts would
characterize the class and probabilities of failures assumed by the electronic subsystem both wrt
the mechanical and the hydraulic subsystems.
Within the scope of SPES, we would assume that lower abstraction layers focus on refining,
then, the internal structure of the electronic subsystem. At some layer (which in the EDA
domain was called the system layer), this would e. g. depict the electronic architecture of a
car, in terms of a FlexRay backbone bus 4 , interconnected via bridges to subsystems dedicated
to specific “domains” such as body electronic, power-train, infotainment, stability, etc. with
domain specific bus-systems, as well as the electronic control units and intelligent sensors and
actuators linked to these, and employ the AUTOSAR meta-model to characterize these as well
as the computing resources inside electronic control units.
Within the operational perspective, we suggest, for each level of abstraction, to capture the
interactions at the system boundary of the system under development. This includes, on the
highest “product” level, a specification of the operational scenarios which must be supported
by the product (hence the naming of the perspective), such as the different classes of missions
for a military aircraft, or the characteristics and variances of product processes to be supported
in product automation applications. Other examples of operational scenarios to be supported
relate to maintenance, or to the production of the product itself (to identify requirements on
the design enabling particular production steps). In general, in this perspective and at this
1 http://www.3ds.com/
2 http://www.3ds.com/catia
3 http://www.plm.automation.siemens.com/en us/products/teamcenter/
4 http://www.flexray.com/
70/ 156

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

Architecture Modeling
the functional perspective would specify the desired control function.
We expect at a minimum abstraction levels to be used at interfaces between subprocesses
along the supply chain hierarchy. Additional abstraction levels can be chosen depending on the
tradeoff between design time and optimization needs – as discussed in the next section.
5.1.3 Example
In the following, the application of the primitive steps in component-based design presented in
section 4 is shown with the aid of a common example used in aeronautics case studies.
First, in section 5.1.3.1 the example of a wheel braking system is presented with a general
description of its functionality and a schematic overview. To demonstrate the different concepts
we walk exemplarily through the design process starting in section 5.1.3.2 with snapshots
of combinations of perspectives and abstraction levels. After that, the primitive design steps
decomposition, allocation and realization are shown exemplarily at selected parts of the previously
presented model snapshots. In section 5.1.3.3, we elaborate on the question of how an
allocation-link of components of the logical and technical perspective could be proved using
a virtual integration test by means of realtime contracts. Finally, we show in section 5.1.3.4
how the fourth primitive step implementation could be proven by a satisfaction-check against
a safety contract using fault-tree analysis. Here, the main purpose is not to give an overview
on safety analysis but to show how such methods can be integrated in the SPES methodology.
Finally, in section 5.1.3.5 we introduce a fourth level of abstraction, the Unit Level, to show
exemplarily how realtime contracts may be checked using scheduling analysis.
5.1.3.1 Aeronautic Example: Wheel Braking System
The Wheel Braking System (WBS) described in the ARP 4761 [5, p. 168 to 280] is a common
example used in aeronautics case studies. The WBS is supposed to decelerate the aircraft on the
ground by controlling the hydraulic pressure for the wheel brake actuators. The central control
unit of this system is called the brake system control unit (BSCU). In Figure 5.1 a schematic
overview of the WBS introduced in the ARP 4761 is depicted containing control units as well
as hydraulic and mechanical elements. Therefore, in the SPES context this figure would be part
of the technical perspective while the BSCU is modeled at a very high abstraction level.
The system operates two independent hydraulic circuits connected to each wheel of the
aircraft and in three different modes Normal, Alternate and Emergency which will be supplied
by either the green or the blue hydraulic lines or by the reserve offered by an accumulator. The
Selector Valve located in both the green (Normal) and blue (Alternate) line guarantees that only
one of the lines can propagate hydraulic pressure. If both lines are operational, the green one is
passed through. Switch over to the blue line occurs if either the green pressure fails, the BSCU
becomes in-operational (green pressure is cut off at Shut-Off Selector Valve) or if it is explicitly
selected by the pilot (not shown in the figure). The default mode of operation is Normal mode.
In this mode the aircraft can decelerate either automatically or manually by the pilot. In both
cases the BSCU generates the necessary control and anti-skid commands for the Meter Valve
in the green hydraulic line that operates individual hydraulic pistons located on every wheel. If
a switch-over to Alternate mode occurs (see above) automatic braking is not possible. The rate
of deceleration is controlled by the pedals and transmitted mechanically to the respective meter
valve. The hydraulic pressure is transmitted to an independent set of brake pistons operating
on sets of wheels. If the BSCU is still working, it will provide anti-skid commands via the
Anti-Skid Shut-Off Valve. When the system is in Alternate mode and pressure to the blue line
72/ 156

Pwr1 Pedal_Pos1 Pwr2 Pedal_Pos2
CMD_AS1
BSCU
Monitor 1
BSCU1
AS1
Valid1
Valid2
Valid_
Switch
Monitor 2
BSCU2
Command 1 Command 2
CMD_AS2
AS2
Select_Switch
Architecture Modeling
Valid
AS
CMD_AS
Shut Off
Selector
Valve
Green
Pump
Normal
Meter
Valve
Isolation
Valve
Selector
Valve
Anti Skid
Shut Off
Valve
Meter
Valve
Blue
Pump
Figure 5.1: Schematic Overview of the Wheel Braking System
Alternate
Reserve
Accumulator
Mech Pedal Position
Wheel
fails it switches to Emergency mode. In this mode the pressure is supplied via an accumulator.
Due to the limited capacity it is not possible to apply and release the brakes multiple times so
that it must be ensured that Anti-Skid Shut-Off Valve is disabled.
Please note, that the models we are presenting in the following sections might slightly
differ in some details from the ARP 4761 and that we do not show each perspective on each
abstraction level for the sake of brevity.
5.1.3.2 Abstraction Levels, Perspectives and Design Steps
In this section, we present how the wheel braking system is modeled on three abstraction levels
(Aircraft Level, System Level, Device Level) using the SPES architecture modeling concepts.
A fourth abstraction level named Unit Level is described in section 5.1.3.5. The example currently
covers four different perspectives starting with the operational perspective on Aircraft
Level where user-activities and actors that operate the system are identified. This is usually the
first design-step we consider in this framework and builds the reference for succeeding phases.
When all needs of operational actors are acquired, in the functional perspective the functions
are modeled that realize the operational activities. Furthermore, these functions may be decomposed
into subfunctions. In the logical perspective logical components are defined that realize
the functions identified in the previous step. A technical perspective is not part of the Aircraft
Level.
On the System Level, the logical architecture is refined by decomposition and an initial technical
architecture is proposed that is refined at the Device Level by adding redundant components
due to safety reasons.
73/ 156

Architecture Modeling
Figure 5.2: Operational Perspective – Abstraction Level 1 – Top Level
Operational and Functional Perspective The intention of the operational perspective (as introduced
in Section 3.2.1) is to model the interaction of different actors with the system under
development using (operational) activities. The top level component of the operational perspective
of the Aircraft Level is depicted in Figure 5.2. It shows a component systemcontext
which contains the system under development, that is Aircraft here, and all actors that interact
with this system. In this simple example we have just one actor namely the Pilot.
This actor interacts with the system via different ports e.g. to control the thrust-reverser or the
landing gear.
Figure 5.3: Operational Perspective – Aircraft Level – Aircraft
Having a closer look into the Aircraft system in Figure 5.3 shows a main activity named
DecelerateOnGround. This complex activity offers different ways to decelerate the aircraft
on the ground. This is expressed by a further decomposition of this activity into subactivities
shown in Figure 5.4.
First, there is the need to extend the landing gear before landing which is represented
by the activity ControlLandingGear. Furthermore, the forward thrust need to be removed
to reduce speed before touching down (RemoveForwardThrust). The activities
that model the actual braking process are the primary and secondary stopping force.
74/ 156

Architecture Modeling
Figure 5.4: Operational Perspective – Aircraft Level – Decelerate on ground
Here, the primary stopping force (ControlPrimaryStoppingForce) is realized by the
wheel brake system which is controlled by brake pedals. The secondary stopping force
(ControlSecondaryStoppingForce) is implemented by a thrust-reverser. The activity
DecelerateOnGround is annotated with a system requirement ARP-ACFT-R-0009
which asks for the existence of such a functionality. By this means, it is documented that this
requirement is realized by this activity.
Figure 5.5: Functional Perspective – Aircraft Level
In the functional perspective (as introduced in Section 3.2.2) of the Aircraft Level shown in
Figure 5.5, the user-demands from the operational perspective are depicted as top level functions
and decomposed into finer grained subfunctions proposing how these functions should be
75/ 156

Architecture Modeling
realized. The top level function relevant for the system we consider here, is the need for a primary
stopping force (coloured in green) whose subfunction is the wheel braking system itself
(coloured in blue). This function is further decomposed into an antiskid function, a parking
brake function, an automatic brake function (autobrake) and a hydraulic brake control function
(each coloured in red). Please note that this is a decomposition step on the same abstraction
level. The top level function is here annotated with the same requirement as the appendant
Figure 5.6: Functional Perspective – Aircraft Level – Contracts of subfunctions
acitivity of the operational perspective. Figure 5.6 shows further requirements that the subfunctions
need to satisfy.
Logical Perspective To illustrate the modeling of logical perspectives (as introduced in Section
3.2.3) we have a look at the logical perspective of the Aircraft Level in Figure 5.7. It
shows that the wheel brake system should be realized by one top level component that offers a
number of input ports as the rudderPedalPosition and parkingBrake from the cockpit
or aircraftSpeed and altitude from external sensors. This logical component is
annotated with several requirements that we know from the previous perspectives.
To have a closer look into the structure of the wheel brake system, we proceed to the second
abstraction level i.e. the System Level where the wheel brake system is refined. On the one hand,
it is decomposed into subcomponents and on the other hand some additional ports were added.
A snapshot of the top level architecture of this level is depicted in Figure 5.8. The wheel braking
system contains a logical component realizing the BSCU (BrakingSystemControlUnit)
on the left hand side receiving sensor inputs from other aircraft systems and commands
from the cockpit. Based on these inputs and the internal status of the wheel braking system
(wheelBrakeStatusInformation) control signals for the different actuator valves
are computed. The actuators are represented each by one logical component in the middle
of the figure. To determine the overall status of the wheel braking system there exists the
SystemStatusAggregator component that collects the status signals of each actuator
component and returns them as wheelBrakeStatus back to the BSCU (internal) and offers
it to other systems of the aircraft (external).
76/ 156

Architecture Modeling
Figure 5.7: Logical Perspective – Aircraft Level
To show the concept of contract-based design some components are annotated exemplary
with contracts using the satisfaction-link. Contracts are depicted throughout this example as a
pair of green and blue boxes where the green box contains the strong assumption As and the blue
box the guarantee G. The weak assumption Aw is for this and the following figures always true
and thus not shown explicitly. To be able to reference contracts, each contract has an identifier
annotated in the upper left corner. For example, C1 claims that if the assumption that the
pedalPosition is within certain bounds is fulfilled, it is guaranteed that meterControl
always occurs within an interval of 0 and 4 milliseconds after pedalPosition has occurred.
Furthermore, it is guaranteed that meterControl is again within certain specified bounds.
Technical Perspective While staying at the same abstraction level, we will now have a look
at the technical perspective (as introduced in Section 3.2.4) of the system in Figure 5.9. Here,
the BSCU is shown again on the left hand side as a computing resource. In contrast to the logical
perspective where actuators are modeled as one logical component, in the technical perspective
there are the actual hydraulic actuators modeled as actuator components and their driver units as
computing resources. The driver units mainly have the task to transform the BSCU commands
to signals the actuator can handle. In this snapshot MeterValveCtrl is an example for a
driver unit forwarding signals to the actuator MeterValveActuator. As before, on this
perspective some components are annotated with contracts derived from the contracts on the
logical perspective. How to check if these contracts match is shown in Section 5.1.3.3.
Decomposition Next, we demonstrate the design step of decomposition (as introduced in
Section 4) at the example of the BSCU component in the logical perspective of the System Level
which is depicted in Figure 5.10. The BSCU is decomposed into a Monitor and a Command
component in order do divide the functionality into two different logical units. The Monitor
component observes the state of the system and detects inconsistencies. The Command unit
77/ 156

Architecture Modeling
Figure 5.8: Logical Perspective – System Level
provides control signals to the respective actuators. For a valid decomposition, all input and
output ports of the parent component (which is the BSCU here) have to be linked to their
respective ports of the internal components.
In this decomposition example, the subcomponent Command is annotated with a contract
C1.1 which is here (not in general) the same as the contract C1 of its parent component. The
proof obligation for decomposition is a virtual integration test as shown in Section 5.1.3.3 for
allocation.
Allocation To complete the modeling of one abstraction level, the components of one perspective
have to be associated with components of another perspective. This link was introduced
in Section 4.4.2 as the primitive design step named allocation. This concept is exemplified
in Figure 5.11 for the logical perspective of the System Level, where the logical component
MeterValveActuator is allocated to two components of the technical perspective namely
the computing resource MeterValveControl and the actuator MeterValveActuator.
For a valid allocate-link all ports of the source component have to be mapped to ports of
the target component. In this example, meterControl is mapped to meterValve and
meterValveStatus to valveStatus. In Figure 5.11 again contracts are annotated that
already have been introduced in preceding figures and therefore are only referenced by their
78/ 156

Architecture Modeling
Figure 5.9: Technical Perspective – System Level
identifier. In Section 5.1.3.3 we show for a similar allocation-link how its validity may be
proven by a virtual integration test.
Realization When performing the design step from one abstraction level to the next (lower)
one, a realize-link (as introduced in Section 4.4.3) has to be established to ensure a valid refinement
step. To give an understanding of the idea how a system (part) is realized at a lower
abstraction level, the technical perspective at the Device Level is shown in Figure 5.12.
At this level, the BSCU is realized by three resource components: itsBSCUSelector,
itsBSCUMonCom1, and itsBSCUMonCom2. The reason for splitting the BSCU is due to the
decision to provide the system with redundant command and monitor units to meet safety requirements
(no single point of failure in the BSCU). These can be found in itsBSCUMonCom1
and itsBSCUMonCom2 respectively. The itsBSCUSelector, a combinational logic modeled
as a device resource, selects and forwards the signals to the driver unit of the appendant
actuator. For simplicity, the communication between these three components is represented by
an abstract signal for each component rather than the explicit modeling of the actual signals. In
this snapshot, a contract is shown with a more complex guarantee that contains implications.
The guarantee consists of two parts, each depicted in a blue box, that are connected by a conjunction
∧ (not shown in the figure). The implication is used here to model different modes of
the system i.e. the normal mode in the upper box where the itsBSCUSelector component
79/ 156

Architecture Modeling
Figure 5.10: Logical Perspective – System Level – Decomposition of BSCU
Figure 5.11: System Level – Allocation of Logical to Technical Component
gets input data from itsBSCUBSCUMonCom1 and the emergency mode in the lower box where
the itsBSCUSelector component gets input data from itsBSCUBSCUMonCom2. In both
80/ 156

Architecture Modeling
Figure 5.12: Technical Perspective – Device Level
cases, the guarantee is that the corresponding signals are forwarded via the meterValve output
port with a certain value range. The strong assumption assures that either dataIn1 or
dataIn2 delivers a meterValve value in a given value range.
The realize-link from the technical perspective of the System Level to the same perspective
on the Device Level is depicted in Figure 5.13. This link again may be validated using a virtual
integration test.
5.1.3.3 Proving Allocation for the Realtime Aspect using Virtual Integration Testing
In this section, we will show an example for validating an allocation-link using a virtual integration
test for the realtime aspect. In Figure 5.14 on the left hand side a snapshot of
the logical perspective at Device Level is depicted with one logical component namely the
MeterValveActuator with its in- and output ports. This component has a satisfy-link
to the contract C2.1.
C2.1 claims that, under the strong assumption that the BSCU control signal lies within
certain bounds, the reaction of the meter-valve actuator must occur within 5 milliseconds.
81/ 156

Architecture Modeling
Figure 5.13: Realize Links for BSCU (Iteration from System Level to Device Level)
Such a reaction is observed by the output of the metervalve actuator i. e. when the signal
meterValveStatus has been updated (upd).
On the right hand side of the figure the same snapshot at the same abstraction level is shown
for the technical perspective. In this perspective we differentiate between the driver unit for
the actuator (MeterValveControl) and the actuator itself (MeterValveActuator) as
well as the communication channel (Channel) between them. Furthermore, technical issues
are considered as the environmental temperatures TEMP1 and TEMP2 of the actuator and the
channel where the respective components are specified to work correctly. The temperatures
might be provided by some sensor components that are not shown here.
The logical meter-valve component is allocated to the three depicted technical components
while the allocate-link is defined by a mapping block that maps the ports of one perspective to
ports of the other perspective. The mapping links are depicted in red dotted lines. In this case,
82/ 156

Architecture Modeling
Figure 5.14: Example for proving Allocation by Virtual Integration Test
the ports meterControl and meterValveStatus of the logical perspective are mapped
to the ports meterValve and valveStatus of the technical perspective. The components
of the technical perspective have a satisfy-link to the contracts C2.1-T1, C2.1-T2, C2.1-T3 and
C2.1.2-T3 where C2.1-T1 is relevant for MeterValveControl, C2.1-T2 for Channel and
both C2.1-T3 and C2.1.2-T3 for MeterValveActuator. The composition of these four
contracts has an entailment link to the contract C2.1 of the logical perspective that has to be
ensured.
To prove an allocation-link a virtual integration test may be performed as introduced in Section
4.2 consisting of the two steps of assuring compatibility and refinement.
Compatibility For the scenario from Figure 5.14, we start with the validation of the compatibility
of the three neighbouring components in the technical perspective or, to be more precise,
the compatibility of their annotated contracts. For this, we have to analyze their strong assumptions
and guarantees. Note, that the weak asspumptions do not constrain the compatibility of
systems. In this example, the second part of the guarantee of C2.1-T1 is compatible to the
second part of the strong assumption of C2.1-T2. The same holds for C2.1-T2 and C2.1-T3.
Further, in this example the assumption parts about the temperature do not influence the validity
of the composition of these three components because they are parts of interfaces to other
components.
Refinement As a further step, the entailment-link between the contract on the logical perspective
and the composition of the four contracts on the technical perspective has to be proven
to be a valid refinement. Checking the refinement for this example results in a falsification,
as the strong assumptions of the contracts C2.1-T2 and C2.1-T3 are stronger than the parent
contract C2.1. To be more precise, the assumptions about the temperature cannot be assured
by C2.1. To solve this situation there are at least two possible scenarios. One solution would
83/ 156

Architecture Modeling
be to extend the assumption of C2.1 by the temperature assumptions of C2.1-T2 and C2.1-T3
which would result in a valid entailment-link. Another option would be to assure the temperature
assumptions by contracts of further neighbouring components on the technical level. This
would induce that the temperature assumptions are not any more existent in the composition of
all contracts on the technical perspective leading again to a valid entailment-link to C2.1.
Also, the weak assumption of C2.1.2-T3 leads to a falsification. This problem can be solved
analogous to the above mentioned one of the strong assumptions.
5.1.3.4 Satisfaction-Check for a Safety Contract Against a Component Implementation
In this section, we elaborate on the question of how a satisfaction check for a component against
its contract may be performed for the safety aspect. Satisfaction is the proof obligation for the
primitive design step implementation introduced in Section 4. For this, we consider a requirement
from the ARP 4761 and use the formalized contract to perform a safety analysis to ensure
its satisfaction.
The starting point is the FHA (Functional Hazard Analysis) where a number of failure conditions
are identified for the system and classified with respect to their impact on the system
and the environment (including passengers). These classifications are then used to derive safety
requirements that need to be investigated during PSSA (Preliminary Systems Safety Analysis)
and SSA (System Safety Analysis).
Safety Contract As an example throughout this text we will investigate the following two
safety requirements:
• No single failure shall lead to loss of wheel braking
• Loss of all wheel braking during landing or Rejected Take Off (RTO) shall be less than
5 · 10 −7 per flight.
These two requirements can be rewritten as safety contracts in the following form:
C3 strong assumption -
weak assumption -
guarantee Loss of wheel braking shall not be caused by 1 failures
C4 strong assumption -
weak assumption -
guarantee Loss of wheel braking shall not occur during Phase =
Landing or Phase = RTO with density higher than 5 ·
10 −7 per flight
In order to analyse whether an existing model satisfies these two contracts we first have to define
the failure condition Loss of wheel braking using a functional pattern. In a simple setting such
a formalisation may be done by characterising a safety-critical state (e. g. by specifying that
the pressure of the blue line is above a given limit). In this context we will define a contract
that implements the above requirement using a RSL (Requirement Specification Language)
pattern. The most obvious way to formalise the safety requirement is to state that whenever the
pilot pushes the braking pedals, either the green or the blue line have to supply pressure to the
wheels subsequently.
(Pedal pressed) implies ((Green pressure high) or (Blue pressure high)).
84/ 156

Architecture Modeling
However this does not account for the delay that is introduced when the command is propagated
through the system until it finally reaches the brake actuators. Instead, we use the following RSL
pattern:
whenever
(Pedal pressed holds during [tr (Pedal pressed), 10 ms])
occurs
tr((Green pressure high) or (Blue pressure high))
occurs
during [0 ms, 10 ms]
This pattern states that whenever the brake pedal is pressed for longer than 10 milliseconds
the disjunction from above needs to hold after at most 10 milliseconds. We require the pedals
to be pressed for at least 10 milliseconds in order to avoid situations where the pedal is pressed
and released over and over again. Otherwise, we run into situations, where one of the different
valves along each line is always closed thus blocking the pressure from reaching the wheels.
Failure Injection In order to evaluate the system behaviour in case of failures the model has
to be extended to reflect the non-nominal behaviour of the system. This is accomplished by
injecting a number of (candidate) failures (i. e. failures that might occur) into the model. Again,
a pattern-based approach is used to provide a list of failure-mode templates including stuck-at,
delay, noise, and random failures. When the provided failure-mode patterns are insufficient,
e. g. if the failure affects several model variables in a complex fashion, or the failure makes use
of some internal system mode (degraded system mode), it is possible to apply user-defined failures,
i. e. failures that are defined using the same modeling formalism employed to specify the
nominal system behaviour. In this case, the system ensures that nominal and failure behaviour
is separated by requiring the user to specify an input that triggers the failure.
The behaviour specification of these failures is merged with the original system model and
together they define the extended system model. In the extended model it is possible to switch
individual failures on and off in any order and with any amount of time passing between their
occurrences. When no failure is active the system behaviour is completely determined by the
system model, whereas when one or more failures become active it is altered according to the
specified failure pattern.
The failure injection was applied to the braking system in the following way: Failures of the
electrical and hydraulic power supplies are represented by user-defined failure-modes, since the
supplies are modelled as inputs to the model. A user-defined failure-mode may also be applied
to the manual mode selection thus modelling wrong behaviour of the pilot. Failures occurring
inside the braking system itself are modelled using stuck-at failure modes.
We defined stuck-at failure-modes for a variety of variables. Failures of each of the valves
are modelled using a stuck-at failure-mode with both states (open and close) as possible values.
This way, the failure-mode can force the valve to be stuck in the open position, passing
the incoming hydraulic pressure, or stuck close, blocking the pressure. Similarly, the validity
signals from the BSCU monitors can either be made stuck true or false. Further failure-modes
were created for the braking commands computed by the two redundant BSCU units and the
reference commands the monitoring units compute. Another failure-mode was created to model
the failure of the switch unit inside the BSCU.
Analysis After the safety requirement has been formalized and the system model has been
extended with failure-modes it is now possible to perform a fault-tree analysis (FTA). The re-
85/ 156

Architecture Modeling
sults from the FTA will then be used to show that the contracts C3 and C4 are satisfied. As a
Top-Level Event (TLE) in the FTA we will use the formalisation of the failure condition Loss of
wheel braking.
Figure 5.15: Auto generated fault-tree
The algorithms we are using to perform an FTA are based on formal verification and automatically
compute a set of all failure-combinations that are necessary to reach the TLE. As these
combinations are minimal by construction, they correspond to the minimal cut-sets that are often
used in traditional safety-analysis. The minimal cut-sets are the used as inputs to construct
a fault-tree.
When the fault-tree generation is applied to the braking system using the safety requirement
(Loss of wheel braking) and a subset of the failure-modes described above, the fault-tree shown
in Figure 5.15 is computed.
Sub-tree b) is directly related to the one depicted in the ARP 4761 (page 200), except that
we did not include failure-modes for the electrical power or the failures of the hydraulic system
(except for the pumps). The sub-tree shows that the safety requirement is violated, when all
three modes fail to operate. The reason for the failure of the normal mode is further broken
down to be caused by the failure of the green hydraulic pump or failure of the BSCU units
to command braking. Note that this also occurs, when the BSCU monitors fail to correctly
compute the reference signal, which is covered by the events 5 and 2 in the fault-tree.
86/ 156

Architecture Modeling
The consideration of monitoring failures is also the reason for the generated fault-tree to be
more comprehensive than the one depicted in the ARP, where the occurrence of monitoring
failures seems not to be considered. Sub-tree a) of Figure 5.15 is one of the additional sub-tree
stemming from this fact. The first remarkable observation of this sub-tree is the circumstance
that it only features failures occurring inside the BSCU, i. e. the TLE is reachable without any
failure of the alternate and emergency mode. This is due to the fact that the failure of the monitoring
unit inside the BSCU can inhibit its shutoff, thus preventing the system from changing
to alternate mode.
Results Satisfaction of contract C3 can easily be derived from the list of minimal cut-sets and
it is also shown in the fault-tree. At least two independent failures are required, therefore the
model satisfies C3.
For contract C4 some additional steps are required which we will only briefly sketch here.
First it is necessary to determine the probability for the occurrence of the basic failures. Typically
these are listed on data sheets provided by suppliers of the relevant sub-systems or they
can be derived from empirical data gained from in-service records of similar systems. Once
these values are assembled the probability for the TLE can be computed using the instructions
given in the fault-tree handbook [47].
5.1.3.5 Checking Real-Time Contracts using Scheduling Analysis
In this section, we will show an example of how to check real-time contracts using the OFFIStool
for Scheduling analysis named Orca. For this purpose, we introduce a fourth level of
abstraction: the Unit Level. On this level, there only exist the logical and the technical perspectives
refining the models of the previous abstraction level.
Figure 5.16: Logical Perspective – Unit Level
87/ 156

Architecture Modeling
Unit Level: Logical and Technical Perspectives We start with an overview
on the logical perspective on Unit Level depicted in Figure 5.16. Here, the
BrakingSystemControlUnit is shown as the top level component containing subcomponents
that realize the two channels of the BSCU each consisting of a command
(Command1/2) and a monitor (Monitor1/2) unit. Because command and monitor has
to communicate, there exists a further logical component that realizes the communication
named Com1ToMon1 and Com2ToMo2, respectively. The top level component is annotated
with two contracts specifying deadlines between certain signals. There exists one
contract for each channel saying that under the strong assumption that the input signal
cmd in1/2.cmdFlow occurs each 5 milliseconds, it is guaranteed that the output signal
control out1/2.controlFlow occurs within 3 milliseconds.
Figure 5.17: Logical Perspective – Unit Level – Contracts
The subcomponents of the BSCU each have a contract as well, as shown in Figure 5.17.
These contracts divide the channel deadlines of 3 milliseconds specified for the BSCU into
local deadlines for the three subcomponents of each channel. The deadline for each command
unit is 1200 microseconds, the deadline for communication via the respective component is 400
microseconds and the deadline for the monitor is defined as 1400 microseconds. How these
local deadlines are chosen is a design decision and may be refined e.g. because analysis results
show that some components violate their deadlines while others would satisfy also smaller
deadlines. Whether these subcontracts are valid with respect to the contracts of the top level
component has to be shown by a virtual integration test.
Next, we have a look at the top level component of the technical perspective as depicted
in Figure 5.18. Here, the BSCU as the top level component is composed of two computing
resources namely ECU1 and ECU2, and a communication resource named CANBus. Each ECU
component has input and output ports to the bus component to send and receive messages and
interfaces to the top level component to communicate with the environment. In this perspective
we have again contracts talking about the deadlines of the top level component specifying the
same deadlines as in the logical perspective.
To be able to specify contracts for the local deadlines, we need to consider the interna of
88/ 156

Architecture Modeling
Figure 5.18: Technical Perspective – Unit Level – BSCU
Figure 5.19: Technical Perspective – Unit Level – ECU 1
both ECUs and the bus and additionally have knowledge about the desired allocation of logical
components to technical components. In Figure 5.19, the component ECU1 is modeled containing
different types of technical components. First, there are two tasks named ECU1Task1
and ECU1Task2. To determine the necessary number of tasks, knowledge of the intended allocation
is required. In this example, we decided to allocate two logical components on ECU1
using two tasks.
A further component of ECU1 is a scheduler component ECU1Sched that schedules a number
of scheduler slots using a certain strategy which is here Fixed Priority Scheduling (FPS).
Each slot is linked to a task. For the communication with other ECUs via the CAN bus an
interface is needed that is modeled by the ECU1BusIf component. This interface component
has links to each task and to ports of the parent component ECU1 leading to the bus component.
89/ 156

Architecture Modeling
Figure 5.20: Unit Level – Allocation from Logical to Technical Perspective
ECU1 has two contracts specifying the local deadlines for the execution of the two tasks
ECU1Task1 and ECU1Task2. To choose the correct deadlines here, the allocation of logical
components to tasks of the technical perspective is necessary. The allocation is depicted in
Figure 5.20 while we use here an abbreviatory representation of the mapping of a single port
to another single port. A dotted arrow from a port a of a logical component (depicted on the
left side) to a port b of a technical component (depicted on the right side) means a mapping of
port a to port b. The dottet arrow from one component to another component annotated with an
> label indicates this mapping as an allocation.
For ECU1, the relevant allocation decisions are the mapping of Monitor1 to ECU1Task2
and the mapping of Command2 to ECU1Task1. This leads to the contracts in Figure 5.19
specifying the same deadlines as for the mapped logical components i.e. a deadline of 1200
microseconds for the execution (inclusive scheduling) of ECU1Task2 (delay from input signal
inA.P TecBusA to outA.P TecA) and a deadline of 1400 microseconds for ECU1Task1
(delay from input signal inB.P TecB to outB.P TecBusB).
The structure of the component ECU2 is almost similar to ECU1 and thus not depicted here.
The mapping to the tasks of ECU2 is also shown in the allocation in Figure 5.20. Communication
components such as Com1ToMon1 and Com2ToMon2 are mapped implicitly by the task
mapping.
The interna of the bus component CANBus are shown in Figure 5.21. It consists of a scheduler
component (depicted in blue) that schedules two slots (depicted in green). Each slot is then
linked to a frame-triggering component that sends and receives the frames. Again, we have two
contracts specifying how long a communication may take which is the identical deadline of 400
microseconds as for the logical communication components.
Scheduling Analysis with Orca Next, we want to show exemplarily how real-time contracts
may be checked using a scheduling analysis tool like Orca.
The first step is the translation of the model into the Orca data model. The result of this
90/ 156

Architecture Modeling
Figure 5.21: Technical Perspective – Unit Level – Bus
Figure 5.22: Orca Model of Unit Level
translation is depicted in Figure 5.22. On the left side, a task network is shown consisting of
triggers, tasks, signals, messages and deadlines while at the right edge of the figure the set
91/ 156

Architecture Modeling
of modeling artefacts in Orca is listed. The Orca tasks correspond to the components of the
logical perspective in the SPES metamodel that are allocated on the task components of the
technical perspective i.e. we have four tasks namely Command1, Monitor1, Command2
and Monitor2 building the two channels. For each channel, there exists a trigger node emitting
activation events with a certain period and jitter. Period and jitter are derived from the
assumptions of the triggered tasks Command1 and Command2 i.e. here both triggers produce
activation events with a period of 5 milliseconds. The communication between tasks is modeled
by signals in Orca which correspond to the communication components of the logical perspective
namely Com1ToMon1 and Com2ToMon2. The execution times for tasks were annotated
as attributes in the SPES model and translated to attributes of the Orca task nodes.
In the middle of the figure, the hardware architecture is depicted consisting of the two ECUs
ECU1 and ECU2. Each ECU has an ECUServer that implements the scheduler component
of the SPES model. Accordingly, each ECU-server contains two scheduler slots. Each task is
mapped to exactly one of these scheduler slots in the same way as described in Figure 5.20.
This mapping leads to the fact that each signal has to be transmitted using the bus component
CANBus which is part of the hardware architecture in Orca and offers a BusServer that
schedules two bus slots. The mapping of signals to bus slots is realized using messages. Each
signal that is not local is linked to a message and each message is mapped to a bus slot. The
mapping is not shown here explicitly.
The contracts of the SPES model are represented in different ways. First, as already mentioned,
the assumptions of triggered tasks are realized by their trigger nodes. The contracts
that define local deadlines for tasks or signals are realized by setting the deadline attribute of
the Orca nodes to the appropriate value. Contracts that define (non-local) deadlines over several
tasks or signals are modeled by end-to-end deadlines in the Orca model. There exist two
end-to-end deadlines, one for each channel, named according to the contracts they stem from.
Figure 5.23: Orca Deadline Violation
Using scheduling analysis, we now can check whether all contracts are fulfilled i.e. whether
all deadlines (local and end-to-end deadlines) of the Orca model are met. If there exists a
run such that a deadline is violated this is indicated by a red skull. For example, in Figure
5.22 the end-to-end deadline BSCUContractChannel1 and the local deadlines of the
92/ 156

Architecture Modeling
tasks Command1 and Monitor1 are not met. To get more detailed information about a deadline
violation one may choose a red skull and a window opens as it is depicted in Figure 5.23
for the task Command1. At the top of the window, we see beside the name, period and deadline
of the node a list of different results of the analysis. First of all, this is the response time and
how it is composed of different aspects as the blocking time by tasks with higher priority. This
is depicted at the bottom of Figure 5.23. The red line represents the deadline that is obviously
violated here.
One possible counter-measure to solve this violation would be two replace one or both ECUs
by other ones where the respective tasks have less execution times. In this example, the initial
architecture consists of two ECUs of an ARM7 type. When replacing both ECUs by an ARM9
type leading to less execution times, all deadline violations can be successfully removed. Another
possible measure would be to change the splitting of global deadlines into local deadlines
(deadline synthesis) in the SPES model.
5.2 On the role of contracts in system development
processes 5
In this section we discuss key design challenges
• Coping with complexity of systems
• Coping with the complexity of the supply chain
• Getting initial requirements right
• Coping with multi-layer design optimization
• Managing Risk
facing systems companies, and discuss industrial solutions in place to cope with these, and
point out how conservative extensions of current processes exploiting contract-based design
could tackle such weaknesses. We wrap up by condensing the essence of what we call contractbased
design.
5.2.1 Coping with complexity of systems
Multiple lines of attack have been developed by industry to cope with the exponential growth
in systems complexity:
1. Model-based development
2. Virtual integration
3. Layered design
4. Component-based design
5. Platform-based design
5 This section is co-authored with Alberto L. Sangiovanni-Vincentelli, University of California at Berkeley
93/ 156

5.2.1.1 Model Based Development
Architecture Modeling
Model based development is today generally accepted as a key enabler to cope with complex
system design due to its capabilities to support early requirement validation and virtual system
integration. While initially the overhead introduced by additional modeling activities for specification
and design models and the costs of maintaining coherency of such models and their
implementation slowed down the introduction of model-based development, the benefits of such
frontloading of processes in achieving high-quality design and avoiding deep iteration cycles is
increasingly seen as key benefit by systems industries, with sector- and application-specific
penetration rates reaching close to 100% such as for primary and secondary flight control in
aerospace, and engine control or dynamic stability control in automotive. Methods used depend
on design layer and application class, such as the use of SysML or AADL for complete
system modeling, Matlab-Simulink for control-law design, and UML, Scade and TargetLink
for detailed design. Today’s state-of-the-art in model based design includes automatic codegeneration,
simulation coupled with requirement monitoring, co-simulation of heterogeneous
models such as UML and Matlab-Simulink, model-based analysis including verification of
compliance of requirements and specification models, model-based test-generation, rapid prototyping,
and virtual integration testing as further elaborated below. We also delay the discussion
of the additional role of model-based design in enabling design-space exploration, architecture
evaluation and platform-based design to the subsection addressing the challenge of overall
optimization of the system under development.
While thus model-based design is already today instrumental in improving product quality
and boosting productivity in complex embedded system design, it is largely focusing on architecture
and function. Non-functional aspects such as performance-, timing-, power- or safety
analysis are typically addressed in dedicated specialized tools using tool-specific models, with
the entailed risk of incoherency with models actually driving design and implementation, and
models used to assess such non-functional characteristics of designs. To counteract these risks,
meta-models encompassing multiple views of design entities, enabling co-modeling and coanalysis
of typically heterogeneous viewpoint specific models have been developed. Examples
include the MARTE UML profile for real-time system analysis [40] and the Metropolis
meta-model [21] (the term meta-model is intended here in the semantic domain, i. e., a sort
of abstract semantics, while in the traditional use of the term, meta-model is a structural concept
and corresponds to abstract syntax). Along the same lines, the need to enable integration
of point-tools for multiple viewpoints with industry-standard development tools has been the
driving force in providing the SPEEDS meta-model building on and extending SysML, which
has been demonstrated to support co-simulation and co-analysis of system models for transportation
applications allowing co-assessment of functional, real-time and safety requirements,
and forms an integral part of the meta-model-based interoperability concepts of the CESAR
reference technology platform 6 .
5.2.1.2 Virtual Integration
Rather than “physically” integrating a system from subsystems at a particular level of the righthand
side of the V, model-based design allows to virtually integrate systems based on the models
of their subsystem and the architecture specification of the system, which in particular explicates
the information flow between subsystems and the systems environment. Such virtual
integration thus allows detecting potential integration problems up front, in the early phases
6 http://www.cesarproject.eu/
94/ 156

Architecture Modeling
of the V, such as exploiting type checking to detect type inconsistencies, up to verification of
system requirements based on simulation (more examples are given below). Virtual system integration
is often a source of heterogeneous system models, such as when realizing an aircraft
function through the combination of mechanical, hydraulic, and electronic systems – virtual
system integration then rests on well defined principles allowing the integration of such heterogeneous
models. Heterogeneous composition of models with different semantics was originally
addressed in Ptolemy [24] and Metropolis albeit with different approaches. These approaches
have then been further elaborated in the SPEEDS meta-model of heterogeneous rich components
[21, 11, 31].
While virtual integration is already well anchored in many system companies development
processes, the challenge rests in lifting this from the current level of simulation-based analysis
of functional system requirements to rich virtual integration testing catering as well for
non-functional requirements. In contract-based virtual integration testing, both subsystems
and the complete system are equipped with multi-viewpoint contracts. Since subsystems now
characterize their legal environments, we can flag situations, where a subsystem is used out of
specification, i. e. in a design context, for which no guarantees on the subsystems reaction can
be given. Our experience from a rich set of industrial applications shows, that such virtual integration
tests drastically reduce the number of late integration errors. Special instances of failed
virtual integration tests include:
• The lack of a component to provide complete fault isolation (a property presumed by a
neighboring subsystem);
• The lack of a subsystem to stay within the failure hypothesis assumed by a neighboring
subsystem;
• The lack of a subsystem to provide a response within an expected time-window;
• The unavailability of a shared resource such as a bus-system in a specified time-window;
• Non-allowed memory accesses;
• Glitch rates exceeding specified bounds;
• Signal strengths not meeting specified thresholds.
Multi-viewpoint contracts in virtual integration testing thus drastically extend the potential
to uncover integration errors early. Additionally, using such rich contracts in system specification
comes with two key benefits which help dealing with the complexity in the OEM-supplier
relationship.
First, the above approach to virtual integration testing is purely based on the subsystems’ contract
specifications. In other words, if virtual integration testing is successful, any implementation
of a subsystem compliant to this contract specification will not invalidate the outcome of
virtual integration testing. Second, assuming that the virtual integration test was passed successfully,
we can verify whether the system itself meets its contract purely based on the knowledge
of the subsystem contract and the system architecture (and evidence that the subsystem implementation
is compliant with this contract).
This entails that, at any level of the supplier hierarchy, the higher-level organization can
– prior to contracting suppliers – analyze, whether the subsystems contracts pass the virtual
integration test and are sufficient to establish the system requirements. By then basing the
contracts to suppliers on the subsystem contracts, and requiring subsystem suppliers to give
95/ 156

Architecture Modeling
evidence (such as through testing or through formal analysis methods) that their implementation
complies to their contract, the final integration of subsystems to the complete system will be free
of all classes of integration errors covered by contracts in the virtual integration test. Note that
this method allows to protect the IP of subsystem suppliers – the only evidence required, is the
confirmation that their implementation meets the subsystem contract specification.
5.2.1.3 Layered Design
Layered design copes with complex systems by focusing on those aspects of the system pertinent
to support the design activities at the corresponding level of the V diagram. This approach
is particularly powerful if the details of a lower layer of abstraction are encapsulated when the
design is carried out at the higher layer. Layered approaches are well understood and standard
in many application domains. As an example, AUTOSAR defines several abstraction layers.
Moving from “bottom” to “top”, the microcontroller abstraction layer encapsulates completely
the specifics of underlying microcontrollers, the second layer abstracts from the concrete configuration
of the Electronic Control Unit (ECU), the employed communication services and the
underlying operating system, whereas the (highest) application layer is not aware of any aspect
of possible target architectures, and relies on purely virtual communication concepts in specifying
communication between application components. Similar abstraction levels are defined by
the ARINC standard in the avionic domains [1].
The benefits of using layered design are manifold. Using AUTOSAR’s layer structure as example,
the complete separation of the logical architecture of an application (as represented by a
set of components interconnected using the so-called virtual function bus) and target hardware
is a key design objective of AUTOSAR, in that it allows complete decoupling of the number
of automotive functions from the number of hardware components. In particular, it is flexible
enough to mix components from different applications on one and the same ECU. This illustrates
the double role of abstraction layers, in allowing to focus completely in this case on the
logic of the application and abstracting from the underlying hardware, while at the same time
imposing a minimal (or even no) constraint on the design space of possible hardware architectures.
In particular, this allows re-using the application design across multiple platforms,
varying in number of bus-systems and/or number and class of ECUs. Such design layers can,
in addition, be used to match the boundaries of either organizational units within a company, or
to define interfaces between different organizations in the supply chain.
The challenge, then, rests in providing the proper abstractions of lower-level design entities,
which must meet the double criteria of on one hand being sufficiently detailed so as to support
– among others – virtual integration testing even with respect to non-functional viewpoints
on the next higher level, while at the same time not overly restricting the space of possible
lower-level implementations. As a concrete example, consider the AUTOSAR application layer
and an application requiring guaranteed service under a given failure hypothesis. Such failure
hypothesis would typically relate both to failures observable on the application layer itself (such
as a component sending an incorrect value, or a component flushing its neighbors with unwanted
messages), as well as to failures depending on the underlying (unknown!) target hardware.
This points to an inherent dilemma: on one side, the desire of completely abstracting from the
underlying hardware, while at the same time wishing to perform analysis of properties which
inherently depend on it.
This dilemma can be solved by using what we call vertical assumptions as abstractions of the
underlying target hardware. Returning to the above example, such vertical assumptions could
explicate the failure hypothesis of either execution platforms or communication platforms, and
96/ 156

Architecture Modeling
thus decorate either (individual runnables of) components, or entities of the virtual function
bus. More general, any logical communication must be seen as a (fictitious) component itself,
which, at deployment time, will be mapped to communication services of the operating system
inducing either bus-based communication or ECU local communication e. g. through shared
memory within one ECU.
5.2.1.4 Component-Based Design
Whereas layered designs decompose complexity of systems “vertically”, by splitting the design
into multiple design layers, component-based approaches reduce complexity “horizontally”
whereby designs are obtained by assembling (composing) strongly encapsulated design
entities called “components” equipped with concise and rigorous interface specifications. While
these interface specifications are key and relevant for any system, the “quality attribute” of perceiving
a subsystem as a component is typically related to two orthogonal criteria, that of “small
interfaces”, and that of minimally constraining the deployment context, so as to maximize the
potential for re-use. “Small interfaces”, i. e., interfaces which are both small in terms of number
of interface variables or ports, as well as “logically small”, in that protocols governing the
invocation of component services have compact specifications not requiring deep levels of synchronization,
constitute evidence of the success of encapsulation. The second quality attribute
is naturally expressible in terms of contract-based interface specifications, where re-use can be
maximized by finding the weakest assumptions on the environment sufficient to establish the
guarantees on a given component implementation.
One challenge, then, for component-based design of embedded systems, is to provide interface
specifications that are rich enough to cover all phases of the design cycle. The need
to thus include non-functional characteristics as part of the component interface specifications
was the key motivation in proposing rich components [20] offering multi-viewpoint contracts
with both vertical and horizontal assumptions as enablers of true component re-use in embedded
system design. Current component interface models, in contrast, are typically restricted to
purely functional characterization of components, and thus cannot capitalize on the benefits of
contract-based virtual integration testing, as outlined above.
The second challenge is related to product line design. While systematic approaches to derive
a weakest set of restrictions on environments exist [12], these assume a given set of service
guarantees. The challenge, then, rests in anticipating the space of future deployments of components
when formulating component guarantees, balancing the contradicting goals of striving for
generality versus achieving efficient component implementations. Methods for systematically
deriving “quotient” specifications for compensating for “minor” differences between required
and offered component guarantees by composing a component with a wrapper component compensating
for such differences as characterized by quotient specifications exists for restricted
classes of contracts and restricted classes of component models [36].
The third challenge is in the choice of granularity of the components. “Smaller” components
are intrinsically more re-usable since it is more likely that a fairly small component has
functionality that can be shared on a larger scale, but the gain in design time is less. “Larger”
components are less re-usable since it is relatively rare that a large part of the design can be
used as is in other designs, but if it can be re-used then the savings are considerable. A way
of balancing these trade-offs is to leverage layered design in that a component can be itself
considered as an assembly of lower complexity components. If both the component and its
“subcomponents” are considered part of the design library we are not giving up potential re-use
by choosing larger granularity components!
97/ 156

5.2.1.5 Platform-Based Design
Architecture Modeling
Platform-based design (PBD) was introduced in the late 1980s to capture a design process that
could encompass both horizontal and vertical decompositions and multiple viewpoints. It was
inspired by the development of personal computing and by the use of the term platform intended
to underline the importance of re-use and of building upon available results. The notion of
platform though was highly context dependent and meant different things to different people.
Thus, there was room to introduce a general approach that could be shared across industrial
domain boundaries and would subsume the various definition and design concepts.
The basic tenets of platform-based design are as follows:
• The design progresses in precisely defined abstraction layers; at each abstraction layer,
functionality (what the system is supposed to do) is strictly separated from architecture
(how the functionality could be implemented). This aspect is clearly related to layered
design and hence it subsumes it.
• Each abstraction layer is defined by a design platform. A design platform consists of
– A set of library components. This library not only contains computational blocks
that carry out the appropriate computation but also communication components that
are used to interconnect the computational components.
– Each element of the library has models that represent a characterization in terms of
performance and other non-functional parameters together with the functionality it
can support. Not all elements in the library are pre-existing components. Some may
be “place holders” to indicate the flexibility of “customizing” a part of the design
that is offered to the designer. In this case the models represent estimates of what
can be done since the components are not available and will have to be designed.
At times, the characterization is indeed a constraint for the implementation of the
component and it is obtained top-down during the refinement process typical of
layered designs. This layering of abstractions based on mathematical models is
typical of model-based methods.
– The rules that determine how the components can be assembled and how the functional
and non-functional characteristics can be computed given the ones of the components
to form an architecture. Then, a platform represents a family of designs
that satisfies a set of platform-specific constraints. This aspect is strictly related to
component-based design.
• This concept of platform encapsulates the notion of re-use as a family of solutions that
share a set of common features (the elements of the platform). Since we associate the
notion of platform to a set of potential solutions to a design problem, we need to capture
the process of mapping a functionality (what the system is supposed to do) with the platform
elements that will be used to build a platform instance or an “architecture” (how the
system does what is supposed to do). This process is the essential step for refinement and
provides a mechanism to proceed towards implementation in a structured way. Designs
on each platform are represented by platform-specific design models. A design is obtained
by a designer creating platform instances (architectures) via composing platform
components (a process that is typical of component-based design), by mapping the functionality
onto the components of the architecture and by propagating the mapped design
in the design flow onto subsequent abstraction layers and/or perspectives.
98/ 156

Architecture Modeling
In summary, PBD encompasses all the methods presented before and offers a unified intellectual
framework where several concers are harmonized. In particular:
• In PBD, the partitioning of the design into hardware and software is not the essence of
system design as many think, rather it is a consequence of decisions taken at a higher
level of abstraction. Critical decisions are about the architecture of the system, e.g., processors,
buses, hardware accelerators, and memories, that will carry on the computation
and communication tasks associated with the overall specification of the design.
• In the PBD refinement-based design process, platforms should be defined to eliminate
large loop iterations for affordable designs: they should restrict the design space via new
forms of regularity and structure that surrender some design potential for lower cost and
first-pass success. The library of functional and communication components is the design
space that we are allowed to explore at the appropriate level of abstraction.
• Establishing the number, location, and components of intermediate “platforms” is the
essence of PBD. In fact, designs with different requirements and specifications may use
different intermediate platforms, hence different layers of regularity and design-space
constraints. The trade-offs involved in the selection of the number and characteristics of
platforms relate to the size of the design space to be explored and the accuracy of the
estimation of the characteristics of the solution adopted. Naturally, the larger the step
across platforms, the more difficult is predicting performance, optimizing at the higher
levels of abstraction, and providing a tight lower bound. In fact, the design space for
this approach may actually be smaller than the one obtained with smaller steps because
it becomes harder to explore meaningful design alternatives and the restriction on search
impedes complete design-space exploration. Ultimately, predictions/abstractions may be
so inaccurate that design optimizations are misguided and the lower bounds are incorrect.
• The identification of precisely defined layers and perspectives where the mapping processes
take place is an important design decision and should be agreed upon at the top
design management level. Each layer supports a design stage where the performance
indices that characterize the architectural components provide an opaque abstraction of
lower layers that allows accurate performance estimations used to guide the mapping
process.
• PBD allows re-use, because it decouples independent aspects, that would otherwise be
tied, e.g., a given functional specification to low-level implementation details, or to a
specific communication paradigm, or to a scheduling algorithm. It is very important to
define only as many aspects as needed at every level of abstraction, in the interest of
flexibility and rapid design-space exploration.
In PBD, contracts play a fundamental role in determining the correct composition rules so
that when the architecture space is explored, only “legal” compositions of available components
are taken into consideration. They can also be used to verify whether the abstractions of the
components for the upper layers of the design satisfy the key concerns about accuracy and
fidelity that depend critically on the design goals. If both these sets of contracts are satisfied,
the mapping mechanism of PBD can be used to produce design refinements that are correct by
construction.
99/ 156

Architecture Modeling
5.2.2 Coping with the Complexity of the Supply Chain
To ensure coherent product development across complex supply chains, the following key trends
can be observed in the market:
1. Standardization of design entities
2. Harmonization/standardization of processes
5.2.2.1 Standardization of Design Entities
By agreeing on (domain specific) standard representations of design entities, different industrial
domains have created their own lingua franca, thus enabling a domain wide shared usage
of design entities based on their standardized representation. Examples of these standards in the
automotive sector include the recently approved requirement interchange format standard ReqIF
[28], the AUTOSAR de-facto standard, the OSEK operating system standard, standardized
bus-systems such as CAN and Flexray, standards for car2X communication, and standardized
representations of test supported by ASAM. Examples in the aerospace domain include ARINC
standards such as the avionics applications standard interface, integrated modular avionics, and
RTCA communication standards. In the automation domain, standards for interconnection of
automation devices such as Profibus are complemented by standardized design languages for
application development such as Structured Text.
As standardization moves from hardware to operating system to applications, and thus
crosses multiple design layers, the challenge increases to incorporate all facets of design entities
required to optimize the overall product, while at the same time enabling distributed development
in complex supply chains. As an example, AUTOSAR extended in transitioning from
release 3.1 to 4 its capability to capture timing characteristics of design entities, a key prerequisite
for assessing alternate deployments with respect to their impact on timing. In general,
the need for overall system optimization then calls for the standardization of all non-functional
characteristics of design entities in order to allow cross-layer optimization. Within the EDA domain,
such richness of design interface specifications is industrial practice. Within the systems
domain, the rich component model introduced in the Integrated Projects SPEEDS tackles this
key objective: in covering multiple design layers (from product requirements to deployment
on target architectures) and in providing means of associating multiple viewpoints with each
design entity, it is expressive enough to allow for cross-supply-chain optimization of product
developments. This approach is further elaborated and driven towards standardization in the
Artemis flagship project CESAR.
5.2.2.2 Standardization/harmonization of processes
Harmonizing or even standardizing key processes (development processes, safety processes,
etc.) provides for a further level of optimization in interactions across the supply chain. As
an example, Airbus Directives and Procedures (ADBs) provide requirements for design processes
of equipment manufactures. Often, harmonized processes across the supply chain build
on agreed maturity gates with incremental acceptance testing to monitor progress of supplier
development towards final acceptance, often building on incremental prototypes. Shared usage
of PLM databases across the supply chain offers further potentials for cross-supply chain
optimization of development processes.
There are multiple challenges in defining such interfaces between OEM and suppliers. Specifications
used for procurement should be precise, unambiguous, and complete. To this end,
100/ 156

Architecture Modeling
OEMs are increasingly using models within procurement processes, typically safeguarding
themselves against potential liability issues by requiring suppliers to validate such models
against textual requirement specifications. A re-appearing reason for failures causing deep iterations
across supply chain boundaries rests in incomplete characterizations of the environment
of the system to be developed by the supplier, such as missing information about failure modes
and failure rates, missing information on possible sources for interferences through shared resources,
missing boundary conditions, etc. This highlights the need to explicate assumptions on
the design context in OEM-supplier contracts. This key need was one of the major motivations
for introducing the contract-based design methodology for embedded systems, as initially developed
in the Integrated Project SPEEDS. In enforcing the analysis of the key characteristics of
the environment required to enforce the system specification up front, responsibilities between
what has to be guaranteed by the OEM (that the system provided by the supplier will be embedded
in an overall design meeting the assumptions on the environment specified in the contract)
and the supplier (in providing an implementation to the system specification provided that the
system is used in a context meeting the specified environment characteristics) are clearly defined.
In the light of an increased sharing of hardware resources by applications developed by
multiple suppliers, such a contract-based approach seems indispensable for resolving liability
issues and allowing co-existence of applications with different criticality levels (such as ASIL
levels in automotive).
In domains developing safety related systems, domain specific standards clearly define the responsibilities
and duties of companies across the supply chain to demonstrate functional safety,
such as in the ISO 26262 for the automotive domain, IEC 61508 for automation, its derivatives
Cenelec EN 50128 and 50126 for rail, and Do 178 B for civil avionics.
The challenge in defining standards rests in balancing the need for stability with the need of
not blocking process innovations seen as indispensible to cope with the exponential growth in
systems complexity and the overarching need of optimization techniques for cost reduction. As
an example, means for compositional construction of safety cases thus allowing modular certification
are seen as mandatory to reduce certification costs in the aerospace and rail domains.
Similarly, the potential of using formal verification techniques to cope with increasing system
complexity will lead to an adaptation of the current DO 178 B standard, establishing the role
of these techniques within the construction of safety cases. In general, this calls for a closed
feedback loop between design and safety processes, assessment the potential impact and benefit
of such design representations and enabled process optimizations on safety standards, and identifying
techniques with strong optimization potential and high industrial relevance early enough
for adaptation of standards enabling their usage in safety-critical system design.
5.2.3 Getting Initial Requirements Right
Depending on application domains, up to 50% of all errors result from imprecise, incomplete,
or inconsistent requirements. Out of the many approaches taken in industry for getting requirements
right, we focus here on those for initial systems requirements, relying on ISO 26262
compliant approaches such as discussed in the context of virtual system integration to systematically
reduce system contracts to contracts on subsystems which are jointly powerful enough
to establish the total set of system contracts.
To cope with the inherently unstructured problem of (in-)completeness of requirements, industry
has set up domain- and application-class specific methodologies striving towards completeness
of requirement analysis. As particular examples, we mention learning process, such as
employed by Airbus to incorporate the knowledge base of what is called external hazards from
101/ 156

Architecture Modeling
flight incidents, the Code of Practice proposed by the Prevent Project using guiding questions to
assess the completeness of requirements in the concept phase of the development of advanced
driver assistance systems, use-case analysis methods as advocated for UML based development
process, where an initial stakeholder based analysis is refined by scenarios capturing the typical
interactions between actors and the system-under-development, and the various approaches
based on rapid prototyping, including virtual reality based mock-ups. A common theme of these
approaches is the intent to systematically identify those aspects of the environment of the system
under development (SUD) (subsuming the physical environment, the operator of the system, and
– for systems-of-systems – other “surrounding” systems) whose observability is necessary and
sufficient to achieve the system requirements. As examples of extensions of systems parameters
based on such heuristic approaches, we mention the need to observe, whether the aircraft
is on-ground (as required to prevent inadvertent activation of reverse thrust of engines when in
cruise flight), blind-spot detection coupled with lane change assistance systems warning against
lane changes in critical traffic situations, or train-integrity control in ETCS-based train-safety
systems. Once this perimeter of the system-under-development is identified, the challenge rests
in characterizing those conditions on the environment, under which the system is expected to
perform according to its requirements. For example, advanced driver assistance systems dependent
on image processing for obstacle detection from video streams will be automatically
de-activated or switched to a degraded mode in complex lighting conditions. As other classes of
environment assumptions we mention assumed boundary values of physical parameters, such
as maximal relative and absolute speed of vehicles, maximal acceleration, types of road conditions,
curve radiuses on highways, traffic rules, average and worst case distributions of arrival
processes of systems in the environment, etc. The approach taken by the Code of Practice can
be generalized to other domains, using a Hazop-style analysis [45], where for each identified
class of interaction between actor and SUD and for each viewpoint specific guide-words could
be used to probe for undesired interactions or interferences, which should be excluded.
An initial phase of refining requirements to contracts is an important step in the design
methodology we describe in this paper. Based on a determined system boundary, responsibilities
of achieving requirements are split into those to be established by the system-underdevelopment
(the “guarantees” of the contract) and those characterizing admissible environments
of the system-under-development (the “assumptions” of the contract). To further
strengthen the capabilities for improving the quality of initial specifications, we advocate the
use of formal specification languages for expressing these, where the particular shape of such
formalizations is viewpoint and domain dependent. Examples include the usage of failure propagation
models for safety contracts, the use of probabilistic timed automata to specify arrival
processes, the use of live sequence charts for capturing scenarios in the interaction of actors
and systems [44], or the pattern-based contract specification language initially developed by the
integrated project SPEEDS, and further refined and elaborated to the RSL language presented
in the Annex advocated for usage in SPES. All these enable what Harel called “playing out”
for the particular case of live sequence charts, i. e. the use of formalized contract specifications
to generate trajectories of interface observations compliant to the currently derived set of
contracts. Such simulation capabilities turn out to be instrumental in further refining our specifications:
typically, they will exhibit unexpected traces, e. g. due to an insufficient restriction of
the environment, or only partially specified system reactions. Using contracts resting on logic
based formalisms comes with the advantage, that such “spurious” unwanted behaviors can be
excluded by “throwing in” additional contracts, or strengthening assumptions, or by considering
additional cases for guarantees. A second advantage of such formalized contracts rests in
the now available methods for checking for consistency: the formalism mentioned above do
102/ 156

Architecture Modeling
provide effective tests, whether a set of contracts is realizable, or whether, in contrast, facets of
these are inherently conflicting, and thus no implementation is feasible.
5.2.4 Coping with Multi-Layer Design Optimization
System designs are often the result of modifications of previous designs with the attempt of
minimizing risks and reducing delays and design costs. While this was an effective way of
bringing new products to market in the past, with the increase in demand for new functionality
and the advances of the implementation platforms, this strategy has yielded more problems than
it has fixed. Hence, there has been a constant progression towards thinking through anew the
requirements and the implementation strategies. However, there is a shared consensus that in
most of the cases the designs are not optimized in the sense that the full exploitation of the
new opportunities technology offers is not achieved and that having visibility of the available
options and an evaluation framework for design alternatives are a sorely missing capability.
An ideal scenario for optimization is to have access to the entire design space at the lowest
possible level of abstraction and then run a global optimization algorithm that could select these
components satisfying constraints and optimizing multiple criteria involving non-functional aspects
of the design. Unfortunately this approach is obviously out of the question for most
designs given the size of the design space and the capabilities of optimization algorithms. What
is possible is to select solutions in a pre-selected design space where the number of alternatives
to choose from is finite and searchable by state-of-the-art optimization programs. Indeed, the
platform-based design paradigm offers scaffolding that would support this approach. In fact, at
any abstraction layer, we need to optimize with respect to the components of the platform. The
selection process will have to look only at feasible combinations of the components as dictated
by the composability of contracts! If we take this argument further, we need also to formulate
the optimization problem that has to be solved. The basic question to be asked is whether a
particular legal composition of available components implements the given functionality and
satisfies the constraints expressed by the contracts. The question is then one of how to assess
whether the composition “covers” the functionality and of how to compute the non-functional
quantities for the composition given the ones of the components. The second part of the question
can be answered if analysis methods for non-functional aspects of components and there
composition is available. The first question is more complex to answer since there is no evidence
that the semantics of the global functionality and the one of the components be congruent.
This aspect is at the heart of heterogeneous design. Several approaches have been tried but not
in the optimization context. In the platform-based design context, there is a way of determining
how to link functionality and solutions and to set up a generic optimization framework. This
approach has been inspired by the optimization work done in logic synthesis, a mainstay of the
design flow used in integrated circuit design.
The mapping step is the core of platform-based design process, and greatly affects the performance
of the implemented system. However, it has been performed manually for most test cases
presented in literature. As the design methodology solidifies and design environments such as
Metropolis [21] are built to support it, there is a clear need for automatic optimized mapping
processes to increase productivity and design quality. To automate the mapping process, we
need to formulate the optimization problem in rigorous mathematical terms. We proposed a
mathematical formalism and a procedure for the PBD mapping process in [43].
To explain the basic ideas of the process, we consider first the analogous, but simpler case in
the EDA domain, the classic logic synthesis flow [48]. In this flow, the behavioral portion of
the design is captured using Register Transfer Languages (RTLs) such as Verilog and VHDL.
103/ 156

Architecture Modeling
The architecture platform is represented by a gate library which contains different types of
logical gates, each with its cost related to area, speed and power consumption. The mapping
process selects a set of interconnected gates from the gate library such that the functionality
of the network is the same as the one represented by the RTL. To optimize the gate selection
process, the semantic domain of the RTLs is first restricted to synchronous designs. Then,
the RTL is translated into Boolean expressions; the same semantic domain is chosen for the
gates in the library. To ease the gate selection process, both the Boolean equations and the gate
library are transformed into net-lists consisting of a primitive logical gate, such as a NAND2.
At this point, mapping, known in logic synthesis as technology mapping, is then reduced to a
minimum cost covering problem. Since optimal covering is NP-hard, heuristic algorithms are
used. Note that this mapping process is based on a common primitive - NAND2 gate - and
mathematical rules for defining the behavior of a set of interconnected primitives - Boolean
logic. Boolean logic is appropriate for synthesizing combinational logic between registers in
a synchronous hardware design. Hence, the process involves three aspects: restriction of the
functional domain to synchronous circuits, choosing a common mathematical representation
(Boolean expressions), and representing the functionality and architecture platform in terms of
primitives (NAND2).
We believe that these three aspects can be generalized and used to help solve any mapping
problem at system level. In the general system setting, however, each of these three aspects is
challenging. The models of computation used in system design are varied and certainly more
complex than Boolean logic with synchronous timing. The selection of a common mathematical
language for both the functionality and the architecture platform depends on critical decisions
involving expressiveness and ease of manipulation. Finally, selecting the primitive elements to
use involves a trade-off between granularity and optimality: coarser granularity allows the use
of exhaustive search techniques that may guarantee optimality while finer granularity allows the
possibility of exploring, albeit non-optimally, a much larger search space.
The formal mapping procedure is shown in Figure 5.24. Initially, we are given function and
architecture models, which are constructed from the functional specification and architecture
platform. During Stage 1 of the procedure, a common modeling domain (CMD) is chosen by
the designers for representing the functionality and architecture (platform). When choosing a
proper CMD, both the semantics and abstraction level for mapping are decided by considering
the trade-off between the size of the mapping space and the complexity of finding a good point
within this space. In Stage 2, a CMD-specific covering problem is formulated and solved by
automatic algorithms. Stage 3 is added to capture all further optimization that may be needed
to tune the design. It includes design concerns that have not been modeled within the covering
problem formulation because they make the solution of the covering problem too complex.
5.2.5 Managing Risk
The realization of complex systems calls for design processes that mitigate risks in highly concurrent,
distributed, and typically multi-domain engineering processes, often involving more
than one hundred sub-processes. Risk mitigation measures typically cover all phases of design
processes, ranging from assuring high quality initial requirements to early assessments of risks
in realizability of product requirements during the concept phase, to enforcing complete traceability
of such requirements with requirements management tools, to managing consistency and
synchronization across concurrent sub-processes using PLM tools. The topic of achieving high
quality of initial requirements has already been addressed above.
A key challenge rests in balancing risk reduction version development time and effort. For
104/ 156

Architecture Modeling
Figure 5.24: Multi-Layer Optimization
most classes of applications, which cannot benefit from a significant re-use and/or similarity
to existing product designs – and it is these, where the issue of realizability is most crucial
- achieving 100% of confidence in realizability of requirements essentially boils down to do
doing the complete design, taking ad adsurbum the very notion of a concept phase. Similarly,
completely eliminating the risks stemming from concurrent engineering essentially requires a
complete synchronization along a fine-grained milestone structure, which would kill any development
project due to the induced delays. To cope with the challenge of risk-mitigation with
balanced effort, the integrated project SPEEDS has proposed the concept of what we called
“controlled speculative design” [15]. Due to the de-facto unachievable fine-grained synchronization,
current practice leads to typically implicit assumptions about design aspects to be
guaranteed by concurrent processes – designers are “speculating” on outcomes of concurrent
engineering sub-processes, based on their experiences from previous designs. We propose to
make such assumptions explicit – another use case indicating the high methodological value
of assumptions – and associate these with risk-levels, which qualify or quantify the expected
risks in not achieving such assumptions. This very same instrument can be put in place during
the concept phase of development processes, where vertical assumptions form the key basis
for assessing realizability of requirements. We see the following key use-cases for exploiting
risk-level labeled assumptions within risk-mitigation strategies, assuming a setting with multiviewpoint
contracts:
A. Extending requirement management to dependency analysis and management between processes
B. Sensitivity analysis for hot-spot detection
C. Controlling speculation in concurrent design processes
D. Impact analysis of late requirement changes
E. Impact analysis of changing design bases
105/ 156

Architecture Modeling
Regarding A, we extend requirements management tool in exploiting the structure of contracts
to maintain a full dependency graph between guarantees and their supporting assumptions
including risk levels. Prototype implementations of this based on the Reqtify product of
Geensys (now a Dassault company) have been developed in the context of the integrated project
SPEEDS. This immediately supports D, and goes beyond current practice in its capability to
quantify the risk level for the parts of the design which must be modified.
Regarding B, we propose to generalize techniques used in safety analysis (such as FTA and
FMEA) to identify what can be seen as the analogue to critical cut sets in fault-tree analysis,
i. e. minimal sets of high-risk assumptions, whose un-realizability would endanger the overall
product objectives. This calls for a calculus for contracts for non-functional requirements, as
also needed for virtual integration testing discussed above. We can then use standard approaches
such as localized design space exploration or rapid prototyping to reduce the risk level of such
critical assumptions to a level balancing the overall trade-off between risk-mitigation and design
time and design effort.
Regarding C, the same approach of assessing the criticality of risk-levels for critical sets of
assumptions within individual sub-processes to achieve this sub-processes objectives can be
used to trigger synchronization with processes responsible for establishing such assumptions to
reduce their risk-level. Within the integrated projects SPEEDS, we have developed a process
advisor [29] for on-line monitoring the risk-level of assumptions as basis for advices on such
risk-reducing measures.
Regarding E, we can assess the effect of replacing parts of the design basis by computing
the cumulative risk induced from partially invalidated assumptions induced by the change, if
any. Ideally, the effect of the change can be completely encapsulated by re-establishing the
contracts of the original design base. If this is not achievable, one can exactly identify the
violated assumptions and quantify the resulting risk.
5.2.6 Summary
The above sections give ample evidence of the high industrial relevance of contracts. Their syntactic
simplicity and intuitive appeal allow for easy adaptation by system-engineers, as testified
by key users within the SPEEDS projects. In their most elementary form, they may just take
the form of informal textual requirements, yet with the key distinguishing feature of explicating
the separation of concerns: what must be guaranteed by the system itself, and what are the constraints
on environments, which are fundamentally required so as to allow the system – based
on such assumptions – to enforce its guarantees. We have then seen how this core paradigm
matches well with the orthogonal notion of aspects: contracts can thus be flagged as to the aspect
of the system they relate to. Clearly, the number of aspects to be supported may vary from
application to application – thus it is up to the customization of contract-based design within
a company’s development process, to determine the set of aspects that must be supported. For
sure, this will go beyond capturing the functionality, with safety- and real-time aspects being a
necessity in safety relevant embedded systems development. Business related viewpoints such
as reflecting costs, constraints from manufacturing, maintainability are natural choices, as are
those related to resource consumption.
Orthogonal to this discussion is the degree of formalization used in contracts. As highlighted
above, there is already high methodological value when using informal contracts. A natural
next step is to restrict the vocabulary of contracts to (domain specific) ontologies. Further steps
towards formalization are viewpoint dependent: as elaborated in subsequent sections, they can
take the form of automata-based specifications, employ suitable logics, build on a library of
106/ 156

Architecture Modeling
patterns, capitalize on sequence charts. Within the project SPES, we advocate the use of the
pattern based requirement specification language RSL, see Section 6.1. The additional effort in
providing a degree of formalization is typically well invested due to the additional benefits we
have outlined above, such as testing consistency of requirements, identifying complex integration
errors early through virtual integration testing, boosting re-use though component based
design, and allowing cross layer design optimizations based on performing platform based design.
The key point we raise, is that this formalization can be done incrementally and on a
case by case basis. Thus, there is a clear migration strategy from using contracts informally,
to incorporating domain ontologies, to gradually enriching the number of covered viewpoints,
and to gradually increase the degree of formalization. No matter in which order such steps are
taken, each of these comes with significant potentials for process improvements.
In spite of, or rather: due to their simplicity, the range of applicability of contracts in embedded
systems design is overwhelming. There is almost no phase in V-based development
processes, where today´s engineering practices would not benefit from the boost of process
improvements offered through contract-based design: the already extensive compilation of design
methods discussed in this section is by no means complete. Additional use-cases relate to
the usage of contracts in model-based testing, in automatic code-generation, in registering new
players in system-of-system designs, etc. This combination of simplicity and extremely high
methodological value are in our view a strong indicator for the identification of a fundamental
design principle, already implicitly underlying many of today´s engineering practices, but so
far a treasure hidden.
107/ 156

6 Annex
108/ 156

Architecture Modeling
6.1 Syntax and Semantics of RSL
Stating requirements is one of the essential tasks in developing products. These requirements build an
interface between different groups of people, i.e. customers, engineers, project managers and many
more.
Typically requirements are stored as natural language text which has the disadvantage that
ambiguities of the sentences can cause a huge amount of requirement changes in early as well in later
development phases. To reduce the costs coming from these ambiguities formal languages are used
to have a fixed semantic meaning for a requirement. But it does not only require some training to write
requirements in these formal languages, it can also be hard to read them.
The pattern based RSL fills this gap by providing an easy to learn formal language with a fixed
semantic that is still readable like natural language.
Patterns consist of static text elements and attributes being filled in by the requirements engineer.
Each pattern has a well defined semantic in order to ensure a consistent interpretation of the written
system specification across all project participants. On the one hand this limits the possibilities of
writing a requirement on the other hand it prevents misunderstandings regarding the interpretation of
the sentences. To gain a set of quality requirements this limitation is necessary. However writing
requirements shall still be possible in an intuitive way. Patterns allow the writing of natural sounding
requirements with defined semantics while being expressive enough to formalize complex
requirements.
To gain a high degree of intuitivism the language shall consist of only a few constructs that can be
easily remembered to give the requirement engineer the possibility to fully understand the RSL and
choose the right pattern that fits the properties he wants to demand on the system.
There exist patterns for each of the following categories:
Functional Patterns
These Patterns express functional requirements of the system. This includes the relationship
between events, handling of conditions and invariants and the possibility to define intervals in
which the requirements or parts of them are valid.
Probability Patterns
In nearly all safety critical system it is necessary to express failure or hazard probabilities.
Since there are various partly redundant forms of expressing probabilities that were used quite
ambiguous in common speech, these patterns guide the requirements engineer to express his
needs.
Safety related Patterns
Only a small part of safety related requirements can be covered with probability patterns. The
major part of the requirements outlines relationships between system components. These
patterns enable the specification of single point of failures or other failure and hazard
dependencies between different components.
Timing Patterns
These patterns can be used to describe real-time behavior of systems. This includes periodic
and aperiodic activations, jitter or delay.
Mapping Patterns
These patterns can be used to express requirements on the mapping from the functional
design perspective to the physical design perspective.
Patterns are noted in a form with optional parts that are not necessarily instantiated. A functional
pattern describing the causality between two events does look like this:
whenever request occurs response occurs during [0ms,10ms].
Phrases in square brackets are considered optional, bold elements are static keywords of the pattern
and italic printed elements represent attributes that have to be filled out by the requirements engineer.
When filling the attributes there are no general restrictions on the names but they should be
descriptive. The names of the attributes can be used later to be mapped to a given architecture or they
109/ 156

can be uused
to generate
the arch hitecture. Whhen
specifyin ng requireme ents there is nno
strict typin ng like int
or real but
there are categories th hat specify wwhat
is described
by the different d attribbutes.
To not ccomplicate
thhe
language e too much and to be also a expressive
enough the set of supported s
attributess
has to be ccarefully
chosen:
Event
Events repreesent
the act tivity in the syystem.
An ev vent can be for f example a received signal,
a
uuser
input byy
a pressed button, b a commputational
result r or the change of a value. Event ts occur
aat
one point of time and have h no duraation
in time. .
CCondition
A condition is
a logic and d/or arithmetiic
expression n based on variables v andd
the status of
eevents.
Condditions
can be b used in twwo
different ways w in patter rns. On the oone
hand the ey can be
uused
as pseudo
events to t trigger an action if the condition becomes
true. On the other
hand
tthe
conditionn
can be the system statee
that has to hold for a sp pecified time.
The values s the
ccondition
is bbased
on ma ay change wiith
time only.
IInterval
Intervals desscribe
a cont tinuous fragmment
of time which can ha ave relative aand
quantita ative time
mmeasures
ass
delimiters or o events. Inttervals
can be b open “]x,y[“
or closed “ “[x,y]” or a
ccombination
of them.
JJitter
JJitter
of an eevent
is the variation
in thhe
point of tim me of occurre ence in a reaal
time contex xt. In this
ddocument
jittter
is conside ered as alwaays
positive, i.e. the even nt is delayed. .
CComponentt
CComponentss
refer to entities
that aree
able to hand dle events or r condition vaariables.
Typ pically
tthese
compoonents
refer to t an actual architecture, , but in early design stagees,
where the
system
hhas
not beenn
designed completely c thhere
are also “possible” component
naames
allowe ed. These
iidentifiers
caan
either be used u to geneerate
the mis ssing architec cture or be mmapped
to the
design
iin
later development
stag ges.
6.1.1 PPattern
sppecification
In this ssection
the different pat tterns get described
in more detail.
The patterns
are liste ed in the
previoussly
mentioned
categories s. Some of tthe
patterns can be use ed to expresss
requireme ents from
more thaan
one cateegory.
Althou ugh there arre
only listed d in the mos st used cateegory,
other applying
categoriees
are menttioned
in the e descriptionn.
For each pattern the syntax and a descriptio on of the
semanticcs
are providded.
In secti ion 6.1.2 wee
give an exe emplary view w on the formmal
semantics
of the
observerr
of a patternn
that is used d to verify thee
correct beh havior of a co omponent aggainst
a requirement.
6.1.1.1
Functionnal
Pattern n:
Architecture Modeling
The funcctional
patterns
describe e relationshipps
between events, cond dition and suubjects.
For example
events ccan
depend on other ev vents or connditions
have e to hold af fter an evennt
has occurred.
This
pattern ccan
be usedd
to express the functional
behavior of a system.
Since all paatterns
have e optional
interval aattributes,
thhese
patterns s can also bbe
used to ex xpress simple
timing connstraints.
On n the one
hand theese
constrains
may refer
to events and conditio ons, on the other o hand tthese
constrains
may
refer to rreal
time.
Functionnal
pattern coonsist
of a tr rigger and ann
action. If the
trigger oc ccurs, the paattern
“starts”
and the
action haas
to occur tooo.
110/ 156

6.1.1.1.1
Attribuute
Definit tion and SSemantics
There are
three kinds
of attribu utes that aree
used in th he functional
patterns: EEvents,
Inter rvals and
Conditions.
In most ccases
these attributes arre
intuitive to o use and no o special knoowledge
is necessary n
to speciffy
requiremeents.
This se ection defines
the exact syntax and semantic of basic and advanced a
features of the attribuutes
and its possible p connversions
and d combinatio ons.
6.1.1.1.1.1
Evennts
Events aare
signals thhat
occur at a defined pooint
in time. Examples ar re messagess
that get se ent over a
bus systtem,
sporadic
signals fr rom sensorss
or even us ser interactio on like presssing
a butto on. While
specifyinng
events thhe
names ca an be choseen
by the re equirements engineer, bbut
have to be used
consistently,
i.e. samme
events ha ave to have the same id dentifiers. If there
exists aan
architectu ure these
names hhave
to be mapped
to the e correspondding
parts in the t design model m in laterr
design stag ges.
Specifyy
locationn
of event occurrencce
It is posssible
to specify
for each event e the loccation
where it occurred.
A compoonent
can reefer
to system m componennts
like “Brak ke Actuator” or “Engine CController”
bu ut also to
non systtem
artefactss
like “Driver r” or “Passennger”.
It is hig ghly recomm mended to usse
the same identifier
for samee
componentts.
In later ddesign
steps the compon nent identifierrs
can be ma apped to the actual archiitecture
of the
system
to start aanalysis
taskks.
Even the consistent uuse
of identif fiers can be one o of the poossible
analy yses, it is
not part of the speciffication
langu uage to guaraantee
consis stency, but allow
the checcking
of it.
The termm
“Componeent”
can be fu urther refinedd:
and
The requesst
event star rts the patterrn
and requires
a respon nse in the defined
time frame. Is
there no request
event there is no specification n for the occurrences
of tthe
response
events.
There mighht
be such an n event or noot.
But of courrse
there might
be otheer
patterns th hat restrict the t occurrennces
of the response
event.
Event on
whenever GearUp on ShifttPaddleCon
ntroller
occurs duuring
[0ms s,100ms].
Event on
Event on
Component t
user User r
system Sy ystem
Architecture Modeling
Component
Useer
System S
occurs oopen
on
clutch
It is posssible
to use component and user or system. The e later ones can be usedd
to explicitly y mention
user inteeraction
or syystem
behav vior.
111/ 156

Constrrain
Eventts
with Intervals
It is not always wanted
to react on every occcurrence
of f an event. Constraining
C
an event through
an
interval is
a natural wway
of filterin ng events. Thhis
can be ac chieved by th he following nnotation:
Event durring
[inte erval]
An exammple
shall demonstrate
th he use of thiss
language construct
A responsee
to a request
shall only bbe
send if the e system got activated through
a mes ssage.
This behavior
can be fo ormalized to:
whenever
occurs.
request t during
Architecture Modeling
[activa ate,deacti ivate] ooccurs
re esponse
There are eevents
that indicate
the aactivation
an nd the deactivation
of thee
system/component.
Only the requests
that occur o duringg
the specifie ed interval will
trigger thiss
pattern. The
interval
acts like a filter on the event. For mmore
informa ation on inter rvals see secction
6.1.1.1.1.2.
It is
also possibble
to use the e different kinnd
of bracket ts here for th he interval ass
described in
section
0. Further the
usage of real times (liike
5 ms) is allowed a in the
intervals.
The patternn
above typic cally needs a refinement, , since the sp pecification oof
the respon nse event
lacks an intterval
where it should occcur.
The bassic
block for building eve ent expressioon
with “during”
is shown
below. Forr
a description
of the
construcction
of open and closed intervals fromm
this basic block refer to o section 0.
Complexx
expressionn
can be buil lt by nestingg
of multiple during expre essions. For each nestin ng level a
basic block
is instaantiated
that sends a teemporary
ev vent to the higher levell.
Depending g on the
integratioon
in the oveerall
context, , the states “ “0” and “1” are a merged in nto the “pre” ” state resulting
in the
“out” state
to ensure correct beha avior when mmultiple
instances
of the event e occur.
112/ 156

Constrrain
Eventts
with Co onditions
In additioon
to filteringg
events with h intervals it iis
also possible
to constr rain events thhrough
a con ndition by
the followwing
expresssion:
Event undder
(Condi ition)
Architecture Modeling
To illustrrate
the usagge,
the exam mple above neeeds
only slight
changes s:
Requirement:
The syste em shall reacct
on reques sts with a res sponse if thee
status of the
system
is active.
Now the evvents
got rep placed by a conditional expression. The correspponding
patte ern looks
like this:
whenever request under u (staatus
== ac ctive) occ curs respoonse
occurs.
The patternn
above typic cally needs a refinement, , since the sp pecification oof
the respon nse event
lacks an intterval
when it
should occur.
In the coorrespondingg
observers the t guard off
the transitio on that is enabled
with cconstrained
event e has
to be exttended
with tthe
constrain ning conditionn:
113/ 156

Sequences of Events
It is typical to specify the order of the occurrences of different events. To do so, there are two
language constructs:
and
Event and then Event
N times Event
Architecture Modeling
Sequences with “and then”
The “and then” construct postulates a sequence of events. The following example demonstrates the
use of the pattern.
Requirement: When a crash was detected, first the airbag shall inflate and then the doors
shall be unlocked.
whenever CrashDetected occurs InflateAirbag and then UnlockDoors
occurs.
This pattern does not say anything about timing, it just specifies the order. To express timing
behaviour it is possible to use intervals with the events. E.g. if the door shall be unlocked in
at least 50 ms after the airbag inflated the pattern would look like this:
whenever CrashDetected occurs ReCheckSensors and then InflateAirbag
and then UnlockDoors during [0ms,50ms] and then EngineOff during
[0ms,300ms] occurs.
The “during” with timing entities differs semantically from the filter that can be used to constrain
events. If “during” with timing entities is used in an “and then” statement the interval is demanding, i.e.
that the event has to occur in the specified interval. The timer starts with the occurrence of the
preceding event. If the event does not occur in the specified interval the “and then” statement
continues its execution from the latest previous event in the chain, that was not constraint by timing
properties. The clock for the interval with the timing constraints is restarted by this event. This means
for the above example that a failing of the EngineOff events 300ms after the unlocking of the doors,
the observer would wait for a new InflateAirbag message, since this event has no timing constraints to
the preceding event.
In contrast to timing intervals the use of events in the intervals is semantically identical to the filter
described in section 0.
This backtracking behaviour can be further specified by the use of brackets.
whenever a occurs b and then (c and then d and then e during
[0ms,7ms]) occurs.
If e does not occur in the specified interval the observer would wait for a new c instead of a
new d.
114/ 156

These events used in the “and then” statement, of course, can be also limited with conditions. In the
corresponding observers an additional automaton is used to process the “and then” expression.
idle
idle
idle
idle
start
start
pre
e2
e:=true
e = e1 and then e2
pre
e1
e = e1 and then e2 during[3,5]
start
start
e2 && (3

Occurrences of a set of events in and arbitrary order
To specify the occurrences of a set of events without constraining their internal order, the “set”
statement can be used.
set{event1, event2, event3…} during Interval
A “set” statement is semantically equivalent to the permutation of all possible sequences of events
expressed by “and then” statements.
(event1 and then event2 and then event3 … during Interval) OR
(event1 and then event3 and then event2 … during Interval) OR
(event2 and then event1 and then event3 … during Interval) OR …
Unwanted events
Especially in sequences of events it is necessary to specify that there shall be no occurrences of some
events in a special interval:
Event not during Interval
This language construct is an event that occurs at the end of interval, if there was no occurrence of
this event. There is no relation to the filter construct “Event during interval”.
Creating Events from Conditions
It can be necessary to define the point in time where a condition becomes true or false. This is done
by the language constructs tr() and fs():
and
tr(Condition)
fs(Condition)
Architecture Modeling
Requirement:
If the cooling liquid exceeds 120 degrees celcius send a warning message.
Formalization:
whenever tr( liquitTemperature > 120) occurs
CoolingLiquidWarningMessage occurs.
To formulate requirements where a condition is true during a defined interval the following language
construct can be used:
Condition holds during Interval
Example Requirement: If the start button gets pushed signal a and signal b shall be equal for
at least 5 seconds.
116/ 156

Formalization:
whenever StartButtonPushed occurs (SignalA == SignalB) holds during
[0s,5s] occurs.
There is also a pattern that specifies that a condition shall not be true during a defined interval:
Condition holds not during Interval
This implies that the condition can be true at some point in the interval, but cannot be true for the
whole interval.
Creating Events from Intervals
It can be useful to describe the end of an interval, especially if there were additional constraints to that
interval..
or
At end of Interval
fs(in[interval])
Logical operations on Events
There exist some logical operations on events:
OR
event1 OR event2 accepts both events. This expression can be used in the trigger as well as in the
action.
AND
Event1 AND event2 only occurs if event1 and event2 occur at the same time. The order of the
occurrence does not make a difference. It is only necessary that at no clock in the timed automata is
running between the occurrences of the events. Note that there is no “NOT” operator for events.
Grouping of Events
Events can be grouped through the “.” operator.
Group.Event
Architecture Modeling
These groups refer to ports in the architecture of the specified system. This might be necessary if
there exist events with the same name in different ports.
117/ 156

6.1.1.1.1.2
Intervvals
Intervalss
describe the
“chunk” of time betweeen
two points s in time. The ese points inn
time can ei ither be a
event orr
a timed value.
In case of events thee
first occurr rence of the startevent sstarts
the inte erval and
the first ooccurrence
oof
the endeve ent ends the interval:
In case
timers.
[starteveent,
endev vent]
that timed vvalues
are the
boundaries
for an in nterval there must be reeference
poin nt for the
whenever
Architecture Modeling
Request occurs o Ressponse
occ curs durin ng [0ms,500ms].
The times iin
the action part refer too
the activati ion point of the t pattern thhrough
the trigger. t In
that sense it is not allow wed to use “nnot
bound” times
values in the triggeer.
The only exception e
where timed
values are e allowed in the trigger are a “and then”
statementts,
where the e interval
refers to thee
occurrence e of the previious
event.
Open/CClosed
inttervals
The bracces
for writing
the interva als can be ussed
to expres ss open and closed intervvals:
[a,b] -> close ed, closed intterval
]a,b[ -> open ned, opened interval
Butt
also the oth her combinattions
are pos ssible:
[a,b[ -> close ed, opened innterval
]a,b] -> open ned, closed innterval
Closed intervals
ends
indicate that
the point iin
time where e the event occurs o still beelongs
to the e interval,
open inteerval
ends inndicate
that the
point in time
at the ev vents represe enting the boorder
does not
belong
to the intterval.
The exact
semanticss
of open and d closed inteervals
are de escribed by showing s the nneeded
mod difications
of the foollowing
basic
block that constrains tthree
events s to occur in a given ordder
without re espect to
time; thiss
generic kinnd
of interval
is denoted by “{..}”. This
basic bloc ck is used too
build complex
event
expressiion
or whole patterns:
118/ 156

Architecture Modeling
Basic bloock
transformmed
for interv vals with opeen
start and with w open en nd:
Basic bloock
transformmed
for interv vals with botth
open start and open en nd:
Basic bloock
transformmed
for interv vals with clossed
start:
119/ 156

Basic bloock
transformmed
for interv vals with clossed
start and d with closed d end:
Basic bloock
transformmed
for interv vals with botth
closed start
and closed d end:
For interrvals
with timmed
values instead
of evvents
simple e parallel aut tomata are nneeded
that generate
events aat
the specifieed
points in time. t
Nestedd
intervalss
The posssibility
of constraining
ev vents througgh
intervals allows a the formulation
of f patterns wit th nested
intervalss.
Especially if there are e events ussed
multiple times in dif fferent intervvals
the nee ed for an
evaluatioon
principle ffor
intervals becomes b impportant.
In generral,
all intervaals
are indep pendent fromm
each other
and get sta arted and ennded
separately.
One
single evvent
can starrt
and end multiple
intervvals.
Ack durinng
[a, b during d [a, ,c]]
Run: a, ACK
Run: a, b, AACK
Run: a, c, bb,
ACK
Architecture Modeling
(accepted)
(not accepteed)
(accepted)
The first runn
is the mos st obvious caase:
a starts the interval in which Ackk
can be acc cepted. In
the second run a also starts s the intterval
where Ack shall be e accepted. TThis
a starts s also the
second inteerval,
which is
required foor
b. b occurs s and ends the
interval reequired
by Ack, A so an
occurrence of Ack would
not be acccepted.
The last
run ends s the interval of b with c, so b gets
not accepteed
and the interval
for Acck
is still valid d.
120/ 156

6.1.1.1.1.3 Conditions
Conditions can be evaluated at every point in time to a Boolean value. Conditions can be connected
with logical operators. The atomic elements are variables that may be later assigned to continuous
variables in the design phase and constant values.
Logical operators
|| OR
&& AND
^^ XOR
==> Imply
== Equal
!= Not equal
< Less than
> Greater than
= Greater or equal
Arithmetic Operators
+ Addition
- Subtraction
* Multiplication
\ Division
% Modulo
Specify the location of Conditions
Similar to event occurrences the location where a condition shall hold can be specified:
Condition on Component
Example: always (speed < 200) on vehicle.
Using Intervals in Conditions
To address intervals in conditions “in” can be used:
in [Interval]
Architecture Modeling
Requirement: If the start button gets pushed the inner and outer temperature of the heater
shall be the same unless the security doors are opened.
Formalization:
whenever startPushed occurs (innerTemp == outerTemp ^^
in[secdoorsOpen, secdoorsClosed]) holds during [0ms,stop].
121/ 156

6.1.1.1.2
Properrty
Definition
Some ppatterns
alloww
slightly different
interrpretations
of o their beha avior. This ccan
be cont trolled by
attributess
that are apppended
to th he pattern.
6.1.1.1.2.1
Iterattive
vs. Flowing
Obbservation
[D.2.4.5] ] Patterns, in
general, express e reactive
behavior
of the fo orm: "triggerring
behavio or implies
promisedd
behavior" wwhich
means:
wheneverr
the triggerin ng behavior is identified at some tim me instant
or intervval,
the prommised
behavio or will occur r at some tim me instant or r interval righht
now or in bounded
future.
wheneveer
car-reqquest
occu urs car-arrrives
oc ccurs during
[0min, 3min]
For instaance,
in the aabove
instantiated
patterrn
"car-reque est" is the trig ggering behaavior,
and "ca ar-arrives
within 3mmin"
is the ppromised
be ehavior. An ooccurrence-in
nstance of th he behavior of a reactiv ve pattern
refers too
the duratioon
that starts s with an ideentification
of o the triggering
behavioor
and ends with the
followingg
occurrencee
of the promised
behavioor.
A patternn
can be useed
in two manners,
depennding
on the evaluation of o its occurreence-instance
es:
Pattern.
In the "iterattive"
manner r only iterativve
occurrenc ce-instances s of the behaavior
are considered,
nnamely:
nextt
identificatio on of triggerinng
behavior does not sta art before thee
end of the promised
bbehavior
of previous instance
(hencee,
a triggerin ng behavior that occurs wwhile
an occ currence-
iinstance
takees
place is ig gnored).
In the “flowinng”
manner, every occurrrence-instanc
ce of the beh havior is conssidered.
In practicce,
most of tthe
patterns‟ ‟ usage is off
the iterative e manner. Flowing
interppretation
is significant s
only when
there is one-to-one matching between
occu urrences of the triggerinng
behavior and the
promisedd
behavior; ffor
instance, when the prromised
behavior
is expe ected to occuur
fixed dura ation after
the triggeering
behavior.
There arre
two kinds of flowing in nterpretation.
For both ki inds (both kinds
are speecified
by the e attribute
flowing) a new instannce
of the pa attern becommes
active fo or each occurrence
of thee
trigger and d requires
an action
in the inteerval.
In the standard caase
one occ currence of the t action caan
terminate e multiple
active instances
of thhe
same pattern.
If the aadditional
attr ribute “once” is specified,
for each oc ccurrence
of the triggger
exactly one occurre ence of the action
in the interval
is req quired.
Examplees
of standarrd
and “once”
specificatioon
of a flowin ng pattern:
whenever
whenever
Attribute es: attribb1,
attrib b2.
a occurs
a occurs
Architecture Modeling
b occurs
b occurs
during [e e,f]. Attr ribute: fllowing.
during [e e,f]. Attr ribute: fllowing,
once.
122/ 156

6.1.1.1.2.2
Seammless
Con ncatenatioon
of multi iple instan nces of a ppattern
The folloowing
switch controls the behavior of an iterative pattern when n it is triggereed
by the same
event
that is reequired
in thee
action of th he pattern.
The defaault
behaviorr
without this attribute is tthat
the actio on event cannot
trigger thhe
pattern ag gain.
6.1.1.1.3
Patternn
Listing
This is thhe
Listing of the functiona al patterns. TThe
placehol lders in italic printed letteers
can be replaced
with constructs
described
in section
1. There is one additional
possible
modificatioon
to the patterns:
“Occurs” ” can be detaailed
by using g:
and
whenever
a occurs
is emmitted
is reeceived
Architecture Modeling
a occurs
during [e e,f]. Attr ribute: seeamless.
These twwo
refinemennts
allow to specify s the diirection
of the
Events and d can be seeen
as inherite ed from
occurs:
ooccurs
is emitedd
is re eceived
This meaans
that it is still possible e to use “occuurs”
in the pa atterns to specify
behavioour
where the
directionn
shall not bee
specified.
The semmantics
of the functio onal patterns
is specif fied by obs server autommatons
for iterative
interprettation.
Becauuse
the specification
of thhe
flowing int terpretation is
difficult it ccannot
be giv ven for all
patterns.
Where posssible
the flow wing interpreetation
is des scribed by a language chharacterizatio
on based
123/ 156

on timed traces. As placeholders for events the names e1, e2, e3, … are used, for conditions the
placeholder c is used.
Pattern
F1:
whenever event occurs event [does not] occur[s] [during interval]
This pattern describes the dependency between two events that can occur on different subjects.
While using the optional interval attribute the pattern claims, that there occurs one event in the
specified interval. If no interval is specified, there are no constraints when the event has to occur.
Such a requirement has to be refined later.
Natural Language Requirement:
The System shall generate a error message when a query fails
Pattern based RSL:
whenever QueryFails occurs ErrorMessage occurs
Observers for iterative interpretation with open and closed intervals:
e3 && (clk==0)
e1
idle pre
e3 && (clk==0)
|fail:=true
e1
idle pre
Architecture Modeling
e2
e2
|clk:=0
e2
|clk:=0
sIn
e3
clk>0
|fail:=true
e3 && (clk>0)
e2 && (clk==0)
whenever e1 occurs e2 occurs during [e3,e4].
e2
|fail:=true
e2
|clk:=0
e2
|clk:=0
sIn
e3
clk>0
e3 && (clk>0)
e2 && (clk==0)
|fail:=true
whenever e1 occurs e2 does not occur during [e3,e4].
in
in
e4
|clk:=0
e4
|clk:=0
sOut
sOut
124/ 156

e3 && (clk==0)
e1
idle pre
e1
idle pre
idle
e1
e3 && (clk==0)
|fail:=true
e4
|fail:=true
e2
|clk:=0
e2
|clk:=0
sIn
e3
clk>0
e3 && (clk>0)
e4 && (clk==0)
|fail:=true
whenever e1 occurs e2 occurs during [e3,e4[.
e4
e2
|clk:=0
sIn
e3
e4 && (clk==0)
whenever e1 occurs e2 does not occur during [e3,e4[.
pre
e2 && (clk>0)
Architecture Modeling
e2
|clk:=0
clk>0
|fail:=true
e3
|clk:=0
clk>0
|fail:=true
e2 && (clk==0)
e3 && (clk>0)
e2 && (clk==0)
whenever e1 occurs e2 occurs during ]e3,e4].
in
in
in
e4
|clk:=0
e2
|clk:=0
e2
|clk:=0
sOut
sOut
sOut
125/ 156

idle
idle
idle
e1
e1
e1
pre
e2 && (clk>0)
|fail:=true
e3
|clk:=0
clk>0
e2 && (clk==0)
|fail:=true
e2 && (clk==0)
whenever e1 occurs e2 does not occur during ]e3,e4].
pre
e4
|fail:=true
whenever e1 occurs e2 occurs during ]e3,e4[.
pre
e4
Architecture Modeling
e3
|clk:=0
clk>0
e4 && (clk==0)
|fail:=true
e3
|clk:=0
clk>0
|fail:=true
e4 && (clk==0)
in
e2 && (clk==0)
whenever e1 occurs e2 does not occur during ]e3,e4[.
Definition of semantics with attributes flowing and once:
Not supported in this version
in
e2 && (clk==0)
in
e4
|clk:=0
e2 && (clk>0)
|clk:=0
e2 && (clk>0)
|clk:=0
sOut
sOut
sOut
126/ 156

Pattern whenever event occurs condition holds [during interval]
F2:
If the event occurs it has to be ensured that the condition is valid during the specified interval or, if
there is no interval specified, forever.
Natural Language Requirement:
If the start button gets pushed signal a and signal be shall be equal for at least 5 seconds.
Pattern based RSL:
whenever StartButtonPushed occurs (SigA == SigB) holds during [0s,5s].
Observers for iterative interpretation with open and closed intervals with events:
e2 && (clk==0)
|fail:=true
e1
idle pre
e1
idle pre
idle
e1
e2 && (clk==0)
|fail:=true
pre
!(c)
|fail:=true
!(c)
|clk:=0
!(c)
|clk:=0
sIn
e2
clk>0
e2 && (clk>0)
!(c) && (clk==0)
|fail:=true
whenever e1 occurs (c) holds during [e2,e3].
e3
!(c)
|clk:=0
!(c) && (clk>0)
|fail:=true
Architecture Modeling
!(c)
|clk:=0
sIn
e2
clk>0
|fail:=true
e2 && (clk>0)
e3 && (clk==0)
whenever e1 occurs (c) holds during [e2,e3[.
e2
|clk:=0
clk>0
!(c) && (clk==0)
!(c) && (clk==0)
|fail:=true
whenever e1 occurs (c) holds during ]e2,e3].
in
in
in
e3
|clk:=0
e3
|clk:=0
!(c)
|clk:=0
sOut
sOut
sOut
127/ 156

idle
e1
pre
e3
e2
|clk:=0
clk>0
|fail:=true
e3 && (clk==0)
!(c) && (clk==0)
whenever e1 occurs (c) holds during ]e2,e3[.
Definition of semantics with attributes flowing and once:
Not supported in this version
Pattern
F3:
always condition
in
!(c) && (clk>0)
|clk:=0
This pattern describes an invariant condition that has to be valid at the specified component, or, if
there has no component been defined, in general.
Natural Language Requirement:
The noise must be < 40dB.
Pattern based RSL:
always (noise < 40)
Observer:
Pattern
F4:
!(c)
|fail:=true
idle
always(c).
whenever condition holds during interval occurs event occurs
[during interval]
If the Boolean value of the specified condition is true during the interval an event occurs in an optional
interval. If no interval is specified, there are no constraints when the event has to occur. Such a
requirement has to be refined later.
Natural Language Requirement:
Architecture Modeling
sOut
128/ 156

If the brake force is above 80% for more than 500ms full braking shall be initiated during
100ms.
Pattern based RSL:
whenever (brakeForce > 80) holds during [0s,500ms] occurs
InitiateFullBraking occurs during [0s, 100ms]
Because this pattern is a combination of F1 and a sub automaton that converts the “holds during”
construct into an event, only the sub automaton is given here. This automaton is started by
localTmpPin0 and emits localTmpPin1 that is used by the corresponding F1 automaton.
Sub automata(for iterative interpretation):
idle
idle
out
localTmpPin0
!(c)
in
whenever (c) holds during [e1,e2] occurs action occurs during [e3,e4].
localTmpPin0
e1
!(c)
|clk:=0
e1 && (clk==0) sIn e1 && (clk>0)
e2
|localTmpPin1:=true
out
e2
|localTmpPin1:=true
!(c)
|clk:=0
e1
|clk:=0
!(c) && (clk>0)
whenever (c) holds during ]e1,e2] occurs action occurs during [e3,e4].
Definition of semantics with attributes flowing and once:
Not supported in this version
!(c) && (clk==0)
6.1.1.2 Probability
There are two patterns concerning probabilities. One of those is to describe the availability of a
component and the other to specify the number of events in an interval.
Pattern
P1:
Architecture Modeling
availability of component shall be comparator p
The Probability of a component to work correctly at any given time shall be “>”,”” and “>=” make sense.
in
129/ 156

Natural Language Requirement:
The system shall operate with 97% availability.
Pattern based RSL:
availability of system shall be >= 0.97
Pattern
P2:
number of event in time shall be comparator n [on average]
In the specified time there shall be “>”,”

Pattern
S3:
Failure shall not be caused by n independent failures
This pattern allows to specify that components have to be redundant and their failure may not be
caused be a given number of other failures.
Natural Language Requirement:
Loss of engine shall not be caused by 2 independent failures.
Pattern based RSL:
EngineLoss shall not be caused by 2 independent failures
Pattern hazard Hazard shall not occur with density higher than n per
S4: reference
This pattern can be used to express an hazard and specify its density.
Example Pattern:
hazard UnannunciatedLossOfDecelerationCapability shall not occur
with density higher than 10E-9 per flightHour.
There are also some patterns that allow to define some elements of the upper safety related patterns:
Pattern
S5:
Function is realized by function_list
This pattern is used to specify break-down of functions during system decomposition; function is
linked to a set of functions of sub-components.
In order to run safety analysis on a model, it is necessary to fully represent the flow and impact of
failures. Hence the decomposition of functions has to be expressed. The commonly used black box
view of components does not support the reference of elements inside a component from the
outside. Since this is necessary for this decomposition a grey-box view is used. [speeds reference]
Natural Language Requirement:
The ABS system shall consist of the measuring unit for wheel slip and the braking system
Pattern based RSL:
ABSSystem is realized by WheelSlipMeasurin && BrakingSystem
Pattern
S6:
Architecture Modeling
Failure is represented by failure_list
This pattern is used to specify break-down of failures during system decomposition, failure is linked to
a set of failures of sub-components. (see previous pattern for grey-box view).
Natural Language Requirement:
The braking system shall fail if the hydraulic system A fails and hydraulic system B fail.
Pattern based RSL:
BrakingSystemFails is represented by HydraulicSystemAFails &&
HydraulicSystemBFails
131/ 156

Patternn
Failuure
has cr riticalityy
critical lity
S7:
This paattern
allows to associate e failures withh
criticalities s that have been
derived for instance e from the
hazard classification
during FHA A (functional hazard asse essment).
Naturaal
Language Requirement:
Loss of the braking syst tem is considdered
hazard dous
Patternn
based RSLL:
LossOfBraakingSyste
em has criiticality
hazardous s
Patteern
hazarrd
Hazard is definned
by ( event e )
S8:
This ppattern
can bbe
used to describe
the hhazard.
The event repres sents the point
in time wh here the
hazarrd
occurs.
Natural
Languagge
Requirem ment:
Unannnounced
losss
of deceleration
capability
during landing
Patteern
based RSL:
Architecture Modeling
Hazaard
UnannoouncedLoss
sOfDecelerrationCapa
ability is s defined by
((CoontrolLampp==1)
hold ds not durring
[tr(p phase==Lan nding),PeddalPushed]
] and
thenn
Brake noot
during [PedalPusshed,500ms
s])
This eexample
is taaken
from the
ARP4754 standard. Th he following graphic g explaains
the form malization
in moore
detail:
The CControlLampp
indicates the
failure of thhe
braking system.
Since e the hazard only occurs if the
failuree
is unannouunced
there shall s be no innterruption
in n the Control lLamp signall
between the
start of
the laanding
proceess
and the PedalPushed
P d event. This is expressed d in the first part of the ev vent
descrription
of the pattern:
... (ControlLLamp==1)
holds h not during [t tr(phase== =Landing), ,PedalPush hed] ..
T1 exxpresses
thee
time in whic ch a brake reeaction
to the e request by the pedal is expected. Is s there no
Brakee
event in thiis
interval the e hazard occcurs:
.... ... Brakee
not duri ing [PedallPushed,50
00ms] .... ....
132/ 156

Pattern
S9:
failureCondition failureCondition is defined by: event does [not]
occur [during interval | under condition condition]
This pattern defines a failure condition by the occurrence (or absence) of an event during an interval
or while a condition holds. Conditions and intervals can be used as described for the functional
pattern.
Natural Language Requirement:
The failure “unintended inflation of airbag” happens if the crash signal gets emitted while
both gravity sensors detect no crash.
Pattern based RSL:
failureCondition UnintendedInflationOfAirbag is defined by: crash
does occur under condition (gravitySensor1.gnormal) gets violated
Pattern
S11:
Architecture Modeling
failureCondition failureCondition is defined by: condition holds
[longer|shorter] than timeunit
This pattern defines a failure condition by the violation of interval a condition holds. Conditions can be
written as described for the functional pattern.
Natural Language Requirement:
It is considered as a failure if the current of the engine control system is longer than 2 sec.
above 2A.
Pattern based RSL:
failureCondition TooMuchEnergyConsumption is defined by:
(consumption > 2) holds longer than 2s
133/ 156

Pattern
S12:
failureCondition failureCondition is defined by: event occurs
more than timeunit [earlier|later] than event
This pattern defines a failure condition by too late (too early) occurred events. This is a derived
pattern from S9.
Natural Language Requirement:
If the airbag inflates later than 60ms after the detection of the crash, it is considered as a
failure.
Pattern based RSL:
failureCondition LateAirbagInflation is defined by: inflation occurs
more than 60ms later than crashDetection
6.1.1.4 Real-Time Pattern
The detailed specification of real-time systems leads to special real-time requirements. In order to
express these requirements dedicated real-time patterns are necessary. Tools for real-time analysis
usually work on execution times, deadlines and activation rates. The patterns presented below can be
used to express the most relevant properties.
Pattern
R1:
event occurs sporadic with minperiod period [and maxperiod
period] [and jitter jitter]
This pattern describes the sporadic occurrence of an event. The minimal distance of the ideal
occurrences is defined by minperiod, which can be delayed by an additional jitter. If maxperiod is
given this specifies the maximal distance between the ideal occurrences. The minimal distance
between the real occurrences can be constrained by Pattern R3.
Natural Language Requirement:
Processing of received data is necessary at most each 10ms and may jitter 1ms.
Pattern based RSL:
dataReceived occurs sporadic with minperiod 10ms and jitter 1ms
idle
(0

Pattern
R2:
Event occurs each period [with jitter jitter]
This pattern describes the periodic occurrence of an event such as the activation of a task. The
event can be delayed by an additional jitter. This is a derived pattern from R1 such that
minperiod==maxperiod.
Natural Language Requirement:
The diagnosis task shall be executed every 10ms and may jitter 1ms.
Pattern based RSL:
diagnosisTaskActivate occurs each 10ms with jitter 1ms
Pattern
R3:
Delay between event and event within interval
This pattern specifies the minimum and maximum distance between two events. The Order of the
occurrences of the events is relevant here.
Natural Language Requirement:
The response time of the diagnosis task shall be 10ms +/- 1ms.
Pattern based RSL:
delay between diagTaskStart and diagTaskFinished within [9ms, 11ms]
Observers for iterative interpretation with open and closed intervals:
e1
|clk:=0
idle
e2 && (l

e1
|clk:=0
idle
e2 && (l

idle
e1
|clk:=0
e2 && (l

6.1.1.5 Mapping Pattern
Mapping patterns can be used to express the requirements on the mapping from the functional design
perspective to the physical design perspective. Functions are mapped to hardware elements.
Pattern
M1:
[under condition (condition)] function function-set shall [not]
be mapped to hw-element-set.
This pattern specifies that a set of functions shall [not] be mapped to a set of hardware elements. A
function set consists of multiple functions concatenated with “AND” or “OR”. A hardware element set
can consist of multiple hardware elements concatenated with “OR”. The condition can consist of other
mapping constraints like “a is mapped together with b”
Natural Language Requirement:
The functions a and b shall not be allocated to RDCa2.
Pattern based RSL:
function a OR b shall not be mapped to RDCa2.
Pattern
M2:
[under condition (condition)] function function-set shall [not]
be mapped together with function-set.
This pattern specifies that a set of functions shall [not] be mapped together to a hardware element
with another function set. A function set consists of multiple functions concatenated with “AND” or
“OR”. The condition can consist of other mapping constraints like “a is mapped together with b”
Natural Language Requirement:
The functions a and b shall not be allocated to the RDC where the function c is allocated to.
Pattern based RSL:
function a OR b shall not be mapped together with c.
Pattern
M3:
Architecture Modeling
[under condition (condition)] function function-set shall [not]
be mapped to same target.
This pattern specifies that a set of functions shall [not] be mapped to the same hardware element. A
function set consists of multiple functions concatenated with “AND” or “OR”. The condition can consist
of other mapping constraints like “a is mapped together with b”.
This is a derived pattern from M2.
Natural Language Requirement:
The functions a, b and c shall not be allocated to the same hardware element.
Pattern based RSL:
function a AND b AND c shall not be mapped to the same target.
6.1.1.5.1 Semantics of Mapping Pattern:
In the following we assume that is the set of all functions ∈ and the set of all hardware
elements ∈.
138/ 156

The function : allocates a single function on a hardware element written .
Using this function the semantics can be defined by the usual semantics of boolean expressions:
f shall be mapped to b
f1 AND f2 shall be mapped to b
∧ f1 OR f2 shall be mapped to b ∨ f shall be mapped to b1 OR b2
1∨2 f1 AND f2 shall be mapped to b1 OR b2
f1 OR f2 shall be mapped to b1 OR b2
Architecture Modeling
∧ ∨ ∧ ∨ ∨ ∨ The function set expressions can consist of all combinations of conjunctions and disjunctions of
functions. These formulas will be applied for the set of hardware elements on the right side of the
expression.
The semantics related to pattern M2 as follows:
f1 shall be mapped together with f2
f1 AND f2 shall be mapped together with f3 ∧
f1 OR f2 shall be mapped to f3 ∨
f1 shall be mapped together with f2 AND f3 ∧
f1 shall be mapped together with f2 OR f3 ∨
f1 AND f2 shall be mapped together with f3 OR
f4
∧
∨ ∧
The pattern M2 can map multiple boolean combinations of functions together. When combining the left
and the right side, the conjunctions are stronger binding than the disjunctions. This type can also be
interpreted as a short form of the first type. Any constraint FX shall be mapped together with
FY, where FX and FY are arbitrary junctions over functions, can be expressed as FX AND FY shall
be mapped to B1 OR ... OR BN.
In general, constraints are negated if the not token of the constraint is set:
f shall not be mapped to b
All constraints can have a precondition which is another constraint.
under condition (f2 is mapped to b1) f1 shall be mapped together with f2
→
The XOR operator is another short form to make modelling easier. It can be translated into two
separate constraint as follows:
f1 XOR f2 shall be mapped to b ⇔
f1 AND f2 shall not be mapped together ∧ f1 OR f2 shall be mapped to b
139/ 156

6.1.2 SSemanticss
of obser rvers
This secction
gives aan
overview w of the semmantics
of th he observer automata tthat
are use ed in this
documennt
to specifyy
the formal semantics oof
the pattern ns. These observers
aree
generated from the
patterns and can be used to veri ify that a giveen
compone ent with one input and onne
output sat tisfies the
requiremment.
Figure 1 illustrates the t relationship
between components s and observvers.
For a sinngle
pattern tthere
exist a set of differeent
automata a, depending g on the kind of intervals that t were
used. Thhese
automata
are com mposed withh
other auto omata or ext tended by aadditional
states
and
transitionns
to represeent
complex event expresssions
and conditions. c
The semmantics
are bbased
on HR RC state maachines
[D.2 2.1.c] for the current set of patterns a subset
(Timed AAutomata)
is sufficient. An A intuitive deescription
of the semantic cs is providedd
below.
Basic coomponents
off
automata:
AAutomata
coonsist
of state es and transitions.
SStates
have invariants, which w are nott
shown here e; clock’:=1 is s assumed foor
all clocks)
TTransitions
ccan
be fired if
their guard is true(even nt occurs or variable v is truue)
AActions
can be performed
when transsitions
are fir red
Examplees
of transitioons
with even nts:
• Run: {e} endds
in S1
• Run: {e, e} eends
in S0
Architecture Modeling
Figure 6: CComponent
with w observer
140/ 156

Examplees
of clocks:
• Run: {c=0@00ms,
c=1@1 1ms, c=0@3mms}
ends in S0
• Run: {c=0@00ms,
c=1@5 5ms, c=0@6mms}
ends in S1
6.1.3 RReferencees
[D.2.5.4] ]
[D.2.1.c] ]
Architecture Modeling
D.2.5.4 Cont tract Specificcation
Langu uage (CSL), SPEEDS S Prooject
D.2.1.c SPE EEDS Meta-mmodel
Syntax x and Draft Semantics, S SSPEEDS
Project
141/ 156

6.2 Semantics of HRC
6.2.1 Semantical Domain
Architecture Modeling
We assume a notion of time, given by a domain Time with a total order < on its instances.
Whether time is discrete (i.e., N) or continuous (R + , the non-negative real numbers) does not
matter for the general definitions in the following, whereas our more specific semantics of HRC
introduced lateron assumes a continuous domain. An initial segment of the time domain is a
downward-closed subset, i. e. a set T ⊆ Time satisfying t ∈ T ⇒ {t ′ ∈ Time|t ′ < t} ⊆ T .
There is a set of ports P, where each port has a type with an associated domain of values.
The universe of all values is V . We will assume all things being type correct and will not be
concerned with details of types and values. Also, we simplify the interface concept of HRC in
our presentation. We assume that each port contains just one flow, so that we can equate ports
and flows, and just speak of ports.
Given a set of ports P ⊆ P, a trace assigns, for any point in time, to each port a value of the
port’s type. Thus, the set T (P) of all traces T over P is a subset of
[Time → [P → V ]] .
For discrete time domains, usually every function in the set above will be a trace, whereas
with continous time and value domains, traces may be restricted e. g. to functions which are
continuous almost everywhere (continuous but for a null set).
In the following, whenever convenient we will freely apply decurrying, changing the argument
order and currying when referring to traces. Thus, a trace may also be viewed as an
element of [P → [Time → V ]].
We denote by σ ↓P (resp., Σ ↓P) the restriction of a trace (resp., trace set) to a subset of its
ports. Similarly, by σ ↓T we will denote its restriction to a subset T ⊆ Time.
A Note on the Choice of the Semantical Domain Basing the semantical definitions on sets
of (timed) traces is already some restriction. There are approaches to modeling which do not
fit into this framework. It would be, however, very difficult to incorporate all these approaches
in a general description, and it would result in a rather complex development. We will develop
our theory for timed traces and leave it to the reader (or future versions of this document, if necessary)
to perform the generalizations and modifications as appropriate for her/his semantical
domain.
One of the limitations of our approach concerns the synchronous nature of composition.
This is not always adequate, for instance it excludes the elegant abstraction of [34] and related
settings. It is, however, often possible to model asynchrony by synchrony, see e. g. [30].
6.2.2 Properties of Trace Sets
Traces do not distinguish between input and output, both are recorded in an equal manner.
Operationally, the diference is important: A component should not be able to restrict the values
on an inport, nor should its environment be able to influence the component’s outports. This
is reflected in the trace sets we get as semantic interpretations of components in HRC, and the
following definition formalizes the observation in a property of trace sets.
Definition 6.2.1 (Receptiveness) Let Σ be a set of traces over a set of ports P, and let P ′ ⊆ P .
142/ 156

Architecture Modeling
1. For σ ∈ Σ, the set Σ is called receptive on P ′ w.r.t. σ, if it is nonempty and for all initial
segments T ⊆ Time,
∀τ ∈ T (P). τ ↓T = σ ↓T ⇒ ∃σ ′ ∈ Σ. σ ′ ↓T = σ ↓T ∧σ ′ ↓ P ′= τ ↓ P ′
2. The receptive kernel of Σ on P ′ is the largest receptive subset of Σ, if there is a receptive
subset, or else the empty set.
Lemma 6.2.2 (Receptiveness Properties) Let Σ be a set of traces over a set of ports P, and let
P ′ ⊆ P .
1. An arbitrary nonempty union of subsets of Σ which are receptive on P ′ is again receptive.
Thus, the receptive kernel is always well defined.
2. The intersection of two subsets of Σ which are receptive on P ′ need not be receptive.
Proof:
Ad 1: This follows from the existential nature of the defining clause (1. in Definition 6.2.1).
Ad 2: Let us consider traces over one input and one output port, where each may take values
in {0,1}. We take the following two trace sets which are receptive on the input port. In
the first set, the output is always 0, in the second the output always equals the input. Both
trace sets are obviously receptive because the input is not restricted. Their intersection is
the set of traces where both output and input are always 0, which is not receptive on the
input port, because there is no trace where the input is 1. 1
Receptiveness over a port set P ′ essentially says that the values of the ports in P ′ are not restricted
– at any point in time there is a future behaviour for every possible future valuation of
P ′ . This captures the intuition about direction of ports. The reader may note that also pathological
cases like a component which guesses future outputs are excluded by requiring receptiveness
on the inports. The potential non-receptiveness (Item 2 in the lemma) should be taken seriously.
It is difficult to avoid inconsistencies in specifications, there are far more intricate cases than the
simple counterexample used in the proof.
As well as receptiveness, determinism can be expressed on the semantic level.
Definition 6.2.3 (Deterministic Trace Set) Let Σ be a set of traces over a set of ports P, and
let P ′ ⊆ P . Then Σ depends deterministically on P ′ if
6.2.3 Semantical Definitions for HRC
∀σ,σ ′ ∈ Σ. σ ↓ P ′= σ ′ ↓ P ′ ⇒ σ = σ ′ .
For a component M, we denote its semantics by [[M]]. It is a set of traces over the interface of the
component. We have already restricted ourselves to ports with just one flow. Service ports are
not considered here either, they are assumed to be implemented by more primitive constructs
(e. g. a protocol over directed ports). Furthermore, ports may only have direction in or out
and not bidirectional. With these simplifications, we sketch the semantical domain for
interpreting HRC and HRC state machines.
1 An even simpler, yet maybe less instructive, example takes just two receptive sets with constant, different output,
so that the intersection is empty.
143/ 156

Architecture Modeling
Ports may be either discrete, transmitting discrete values or events, or continuous, if they
serve to transmit values of type real. Thus, P = PD ⊎ PC. Traces assign to discrete ports,
for each point in time, a discrete value, resp., the information of presence or absence of the
event. To continuous ports, a real value is assigned, obeying certain smoothness conditions (see
below).
To accomodate hybrid behavior with continuous evolutions and discrete interaction, our time
domain is two-dimensional. Continuous evolutions may be interrupted by sequences of discrete
actions which take no physical time. This enables a sufficiently accurate and reasonably abstract
modelling of hybrid systems.
Definition 6.2.4 (HRC Time) The time domain for HRC traces is (TimeHRC,

Architecture Modeling
Traces according to Definition 6.2.5 can adequately represent the evolutions of HRC state
machines as used e. g. in Sec. 6.1: Discrete transitions happen at certain points in time in the
second time dimension, while between discrete transitions all changes are continuous (and discrete
ports do not change their values).
The parallel composition of components is defined by (essentially) the intersection of the
parts composed in parallel.
Definition 6.2.6 (Semantics of Composition) Let a hierarchically defined component M with
port set P and parts Mi, i = 1,...,n be given.
1. There are substitutions ρi, i = 1,...,n which map the port names of the Mi to the names
of assembly and delegation connectors they are connected to, and there is a substitution
ρ which similarly maps the delegation connectors to the names of the ports of M. We call
these substitutions the connecting substitutions of M.
2. The semantics of the composition is defined formally by:
n
[[M]] =
[[Mi]]ρi
i=1
6.3 Syntax and Semantics of Contracts
6.3.1 Contract Basics
For the formalization of specifications, we assume a logic whose formulas A, G, . . . serve
to define sets of traces. Thus, the semantics of the logics assigns sets of traces to formulas,
denoted by [[G]], [[A]], etc. A suitable logic in the design context could be a first-order extension
of linear-time temporal logic, or, more general, a second-order logic with primitve sorts Value
and Time and the second-order sort Port for ports as functions from Time to Value.
Contracts are constructed from formulas as triples (As,Aw,G) with strong (As) and weak (Aw)
assumptions and guarantee G. We usually assume the interface of a component be given, i. e.,
a set of ports with types and directions, and require that the three constituing formulas of the
contract refer to this port set. If necessary, the port sets of the constituing formulas are extended
to the set of component ports. In a contract, the assumptions may be viewed as antecedents and
the guarantee as conclusion. Formally, there is no semantical distinction between strong and
weak assumptions — they are to be conjuncted. Their different roles are just methodological in
nature.
Definition 6.3.1 (Contract Semantics) The semantics of a contract C = (As,Aw,G) is given
by the following equation.
where (.) cmpl denotes complementation.
ρ ↓P
[[C]] =def ([[As]] ∩ [[Aw]]) cmpl ∪ [[G]] ,
Remark 6.3.2 (Contracts as Formulas) If negation or implication is available in the assertion
logic, a contract can be translated into a formula:
form((As,Aw,G)) =def ¬As ∨ ¬Aw ∨ G , or
form((As,Aw,G)) =def As ∧ Aw ⇒ G .
145/ 156

Architecture Modeling
For our application as specifications, the logical formulas in question will denote sets of traces
of valuations of connections, resp., ports. Then we can define satisfaction of contracts by components
(and systems).
Definition 6.3.3 (Satisfaction) A component M satisfies a formula G, written M |= G, if and
only if [[M]] ⊆ [[G]]. Similarly, it satisfies a contract C, written M |= C, if and only if [[M]] ⊆ [[C]].
Thus, we have
6.3.2 Contracts: Properties
M |= (As,Aw,G) ⇔ [[M]] ∩ [[As]] ∩ [[Aw]] ⊆ [[G]] .
To be able to base the design process on contracts, we need operations on contracts and related
properties. The most basic relation between contracts is that of entailment, which is called
refinement here.
Definition 6.3.4 (Refinement) A contract C ′ = (A ′ s,A ′ w,G ′ ) refines a contract C = (As,Aw,G),
written C ′ ⇒ C, if
[[C ′ ]] ⊆ [[C]] and[[As]] ⊆ [[A ′ s]] ,
i. e. if it is (in total) more restrictive and its strong assumption is less restrictive. Equivalently,
C ′ ⇒ C if form(C ′ ) ⇒ form(C) and As ⇒ A ′ s in the usual logical meaning of implication.
Thus, a component satisfying a refinement of a contract C satisfies also C. The second part of the
condition for refinement states that the strong assumption may only get weaker in refinements.
As a consequence, the strong assumption of a contract will always remain sufficient to establish
the strong assumption made by a component satisfying a refinement. In practice, refinement
usually removes nondeterminism from the guarantee, thus strengthening it, and/or permits more
environment behaviour, weakening the assumption(s). This relation is called dominance.
Definition 6.3.5 (Dominance) A contract C ′ = (A ′ s,A ′ w,G ′ ) dominates a contract C =
(As,Aw,G), written C ′ C, if A ′ s ⇐ As, A ′ w ⇐ Aw and G ′ ⇒ G.
It is easy to see that dominance implies refinement but not vice versa. In practice, dominance is
easier to establish (i. e., less complex to check) and often sufficient for refinement proofs to go
through.
In the design process, often more general relations than refinement are called for because A
specification should be implementable. We capture this intuition by the notion of (strong) consistency.
Definition 6.3.6 (Consistency) Let the interface I of a component in HRC be given.
1. A contract C (resp., a set of contracts C ) over I is weakly consistent if [[C]] is nonempty
(resp.,
C∈C [[C]] is nonempty).
2. A contract C (resp., set of contracts C ) over I is strongly consistent if the receptive kernel
of [[C]] (resp.,
C∈C [[C]]) w.r.t. the inports in I is nonempty.
Weak consistency is consistency in the logical sense, a necessary condition for every meaningful
specification. Strong consistency takes the direction of ports into account, guaranteeing the
existence of an implementation on the semantic level. It is more difficult to check than weak
consistency.
Whether the direction of ports is taken into account in a contract can be defined on the logical
level.
146/ 156

Architecture Modeling
Definition 6.3.7 (Directed Contract) Let the interface I of a component be given. A contract
C = (As,Aw,G) over I is directed w.r.t. I if As and Aw are receptive on the outports in I and G is
receptive on the inports in I.
Directed contracts may be viewed as the most natural form of utilizing the contract format
for specifications. This is supported by the observation that directed contracts are strongly
consistent.
Lemma 6.3.8 (Directedness and Consistency) Let the interface I of a component and a contract
C = (As,Aw,G) be given.
1. If the guarantee of C is receptive on the inports in I, then C is strongly consistent.
2. A directed contract is strongly consistent.
Proof:
Ad 1: Since [[C]] ⊇ [[G]] and the receptive kernel of G w.r.t. the inports is nonempty, also the
receptive kernel of C is nonempty.
Ad 2: Follows immediately from 1.
An important operation to be performed on contracts is conjunction. This might be useful to
combine specifying contracts of one component, or to derive a contract valid for a composition
from part contracts. Though one can always find a contract equivalent to the conjunction of a set
of contracts, properties like directedness are not automatically retained. We provide different
schemata for performing the conjunction.
Lemma 6.3.9 (Contract Conjunction) Let (tt,B,G) and (tt,F,H) be contracts. Then
are equivalent to (tt,B,G) ∧ (ff ,F,H).
6.4 Formalization of Typical Design Steps
(tt,BG + FH , GH) (6.1)
(tt,BF + BG + FH , GH) (6.2)
(tt,B + F , BH + FG + GH) (6.3)
The parallel composition of components has a logical counterpart on the level of contracts.
Lemma 6.4.1 (Logical Composition) Let a hierarchically defined component M with port set
P, parts Mi, i = 1,...,n, and connecting substitutions (ρ1,...,ρn,ρ be given. Let the parts be
specified by sets of contracts Ci, j, i = 1,...,n, j = 1,...ni. Then
n ni
n
Mi |= Ci, j ⇒ M |=
i=1 j=1
i=1
ni
j=1
Ci, j
ρi
ρ ↓P .
The lemma follows from Definition 6.2.6. It immediately provides the criterion for virtual
integration testing.
147/ 156

Architecture Modeling
Theorem 6.4.2 (Virtual Integration Testing) Let a hierarchically defined component M with
port set P, parts Mi, i = 1,...,n, and connecting substitutions (ρ1,...,ρn,ρ) be given. Let the
parts be specified by a set of contracts Ci, j, i = 1,...,n, j = 1,...ni each. Then
n
Mi |=
i=1
ni
j=1
Ci, j
∧
n
i=1
and if P ′ is the set of assembly connectors of M,
n
∃P ′
i=1
ni
ni
j=1
j=1
Ci, j
Ci, j
ρi
ρi
ρ ⇒ C
⇒ M |= C (6.4)
ρ (6.5)
is the strongest assertion satisfied by M when the parts are instantiated by the respective contract
sets.
In words, the theorem says that all contracts valid for a composed component are logical consequences
of the logical composition of the contracts of its parts (if these contracts of the parts is
all that is known about them). As a consequence of this theorem, we can verify the correctness
of a parallel composition on the level of contracts (6.4). This constitutes the formal foundation
of contract-based design, modulo the expressiveness of the assertion language.
Expressiveness matters mainly at the level of parts of the composition. Most logics have
operators for conjunction, and substitutions can be performed on a syntactic level. The logical
operators for composition do not seem problematic. The quantification over the set of assembly
connectors might be more problematic. It is the logical counterpart of (semantical) hiding. In
second-order trace logic, this is expressable by second-order quantifiers.
Theorem 6.4.2 is the formal underpinning of hierarchical (de-)composition. It does, however,
not reflect specifics of strong versus weak assumptions. Logically, they are both antecedents.
Methodologically, they will be treated differently. Validity of the implication in (6.4) (the second
conjunct) means that the strong assumptions of the part specifications, which are part of
every contract of every part (see Sec. 4) are either discharged by contracts of other parts or still
present in the derived contract for the composition. This is, semantically, correct. But we want
the strong assumptions of parts which are not discharged to appear in the strong assumption
of the composition. Thus we require the following additional condition for the application of
virtual integration testing.
Definition 6.4.3 (Strong VIT Condition) Let a hierarchically defined component M with port
set P and strong assumption A and parts Mi, i = 1,...,n be given. Let the parts be specified
by a set of contracts Ci, j, i = 1,...,n, j = 1,...ni each, with Ci, j = (As,i,Aw,i, j,Gi, j). Then the
strong VIT condition is given by:
n
i=1
ni
j=1
Ci, j
∧ (Aρ −1 ) ⇒
n
(As,i) (6.6)
In the above, ρ −1 shall denote a formula operation that inverses the effect of the substitution ρ
which maps the delegation connectors to P. For a substitution which is not injective (e. g. if an
inport of M gets duplicated internally), this cannot in general be expressed by a substitution.
The strong VIT condition may even have a stronger motivation than said above. In some applications,
it might be necessary to assume a stricter interpretation of strong assumptions than
i
148/ 156

Architecture Modeling
the one given above in Sec. 6.3.1. Though, logically, nothing is assured of a component if the
strong assumption is violated, we still can compose it in parallel with other components without
affecting those — such is the nature of “parallelism as intersection”. If this is not justified,
the strong VIT condition would become mandatory, to preclude conclusions to be drawn from
the specifications of some components even though the operational conditions of others are not
met. Building a semantics on a concept (parallelism as intersection) which does not always hold
might seem badly advised. But one should bear in mind that all mathematical semantics of realworld
entities are simplifications. And the concept of “very strong” assumptions, as reflected
in the “Strong VIT condition” might enable a consistent use of helpful simplifications which
would otherwise be unsound. Handling the large formulas in (6.4) and (6.6) might be difficult
in practice – tautology checking for trace logics is computationally expensive. Thus, to reduce
the complexity, boolean reasoning should be used first to reduce the problem. A promising way,
to be supported by adequate methodological guidelines, is to eliminate assumptions wherever
possible when they are implied by commitments of other components as exemplified in Sec. 4.
149/ 156

Glossary
Architecture Modeling
System under development (SuD) The notion system under development denotes the software
intensive system on a defined abstraction level. A system under development may
involve various perspectives(↑).
Architecture An architecture describes the basic structure of the system under development(↑).
Component A component is self-contained and provides functions of a system. It has a well
defined interface. Typically a component itself consists of a set of parts(↑).
Ports Ports specify the interface of a component(↑). A port can either define a data-oriented or
a service-oriented interaction point. Further, ports have a direction and are either input or
output ports or bidirectional. A port is typed by a specification describing a set of flows
or services needed or offered by a port.
Part Parts are sub-components in the context of an encompassing component(↑). The concept
of parts enables the hierarchical structuring of components(↑).
Heterogeneous Rich Component (HRC) Heterogeneous Rich Components extend the concept
of components(↑): The term rich refers to the fact that a component can have
an aspect-specific specification and realization. Heterogeneous means that different
aspects(↑) typically use different modeling elements.
So, an aspect specification defines what a component should do and a realization defines
how the component actually behaves. Specifications in the context of SPES are done by
means of contracts(↑). The realization of a certain aspect of a component can be modelled
by any other formalism.
Contract Contracts give the specification of a component and formalize system-requirements.
This enables model based analysis techniques. Syntactically a contract consists of a
strong assumption, a weak assumption and a guarantee. The strong assumptions specify
the allowed design context. If a component is used outside this specification, product
liability does not apply. In contrast to this, the weak assumptions define different possible
system contexts. A single weak assumption defines a part of the allowed design context.
The guarantee specifies the behaviour guaranteed by the component, if it is used in the
allowed system context, i.e., its strong assumption does hold.
Requirement Specification Language (RSL) RSL is a pattern-based language which can be
used to formalize properties of design items. With RSL it is possible to capture
contracts(↑). For this, one RSL-expression is used to specify the strong assumption,
the weak assumption and the guarantee respectively.
Abstraction Level An abstraction level provides a specific level of description and analysis of
a design item (e.g. component). On the next lower abstraction level the granularity of the
design item is refined. Such a lower abstraction level is realized by specific decomposition
techniques. Models on different abstraction levels may differ in both their granularity and
their viewpoints(↑). Realize links(↑) between models allow to trace those refinements.
The use of abstraction layers may support both the reuse of solutions and the management
of the supply chain.
Note that components of models on lower abstraction levels still have to respect the aspect
specifications(↑) defined for their higher level counterparts.
150/ 156

Architecture Modeling
Decomposition A design item (e.g. component) can be decomposed into parts(↑). A decomposition
consists of linked parts(↑) realizing the interface of the design item.
Concern A concern characterizes a specific interest of one or more stakeholder with respect
to the system under development(↑). Concerns include system considerations such as
performance, reliability, security, distribution, and evolvability and are expressed in terms
of questions, e.g., “What functionality should the system offer to its users?” or “How
reliable is the designed system?”.
View A view is a set of models of the system under development(↑) or of a part of this within
an abstraction layer(↑) with respect to a specific viewpoint(↑). A view addresses one or
more concerns(↑).
Viewpoint A viewpoint defines a specific form of abstraction in order to focus on particular
concerns(↑) within a system. For each viewpoint a selected set of architectural constructs
and structuring rules is defined in order to design and use a viewpoint specific view(↑).
Thereby, a viewpoint is not constraint to a specific abstraction layer(↑).
Aspect An aspect is a part specific views(↑). Aspects help in coping with complexity in constructing
a view(↑). Examples for aspects are safety, realtime, performance and functionality.
Perspective A perspective combines views(↑) of different abstraction levels(↑) which are
related to similar viewpoints(↑). Perspectives can be used to group and to structure
views(↑) of different disciplines in order to cope with the complex task of developing
a system.
Operational Perspective In the operational perspective the context of the design item is regarded.
The focus lies on the analysis and documentation of the integration of the design
item in its technical and physical environment. The relations of the system under
development(↑) to other systems, to its users, and to its environment is modeled in this
perspective.
Moreover, requirements of the SuD(↑) are documented, which refer to the characteristics
constraining the interface behavior of the system. The SuD has to fulfill these requirements
in order to achieve its goal. These requirements especially encompass the
user-functions, which should be provided by the system.
Functional Perspective In the functional perspective the functional needs of the system and
their breakdown into sub-functions is modeled. The set of all sub-functions then realize
the top-level system functionality.
Logical Perspective On the logical perspective a structural decomposition of the system under
development(↑) with the aid of hierarchichal components(↑) is performed. These
components(↑) implement the functions specified on the functional perspective(↑).
Thereby, the structural decomposition is influenced by non-functional requirements like
performance, reusability, and verifiability. Further, the decomposition could also be influenced
by (↑) the supply chain.
Moreover, under the consideration of the interface of the system under development the
system context is modeled.
151/ 156

Architecture Modeling
Technical Perspective The technical perspective describes the electrical and electronical architecture,
the software architecture and the mechanical structure of the system under
development(↑). Modeling elements are for example electronic control units, bus
systems, tasks, and hydraulic systems. By allocating components(↑) of the logical
perspective(↑) to the technical perspective a software-hardware partitioning is realized.
Geometrical Perspective On this perspective the physical layout of the system under
development(↑) is modeled. This includes (amongst others) models describing the location
of control units, and the cable layout.
Refinement Refinement defines the derivation of a concrete desciption of the design item from
an abstract description. The derivation thereby conserves the characteristics of the abstract
description. In the case of a contract specification(↑), the derived component(↑)
has to fulfill all contracts of the more abstract component.
Dominance Dominance is a necessary but not sufficient condition to check a refinement(↑), in
that dominance implies refinement.
Mapping A mapping is a concept of the SPESMM which relates a set of component parts(↑)
to each other. In particular, it descibes the projection of interfaces of a set of component
parts to component parts of different perspectives(↑) or abstraction layers(↑). There are
two types of mappings: realization(↑) and allocation(↑).
Realization An realization describes a mapping(↑) between component parts(↑) of different
abstraction layers(↑).
Allocation (Allokation) An allocation describes a mapping(↑) between component parts(↑) of
different perspectives(↑).
Satisfaction Satisfaction is the proof obligation stating that an implementation of a desing
item must adhere to its specification. In context of SPES, this means that an aspect
realization(↑) of a component(↑) has to fulfill its contracts(↑), i.e., if its behavior does
not violate its specified one. That way, the behavior of a component defined by its aspect
realization can be seen as a refinement(↑).
Compatibility Compatibility reflects the distinction of responsibilities: The strong
assumptions(↑) about the environment of a component must not be violated by another
component that is connected to this component.
Virtual Integration Test (VIT) A virtual integration test verifies the correctness of a design
item, which is composed by a set of interconnected sub-design items. In particular, to
perform a virtual integration test in the context of SPES, one has to show on the one hand
the compatibility(↑) of the interconnected sub-components. On the other hand, one has to
check, whether the contract specifications of the composition of all sub-conponents refine
the contract specification of the composed component.
152/ 156

Bibliography
[1] ARINC 653 - Avionics Application Software Standard Interface. Part of ARINC 600-
Series Standards for Digital Aircraft & Flight Simulators, 2006.
[2] IEEE Standard for Property Specification Language (PSL). IEEE Std 1850-2010 (Revision
of IEEE Std 1850-2005), pages 1 –171, 6 2010.
[3] Aditya Agrawal, Gyula Simon, and Gabor Karsai. Semantic translation of simulink/stateflow
models to hybrid automata using graph transformations. Electr. Notes Theor. Comput.
Sci., 109:43–56, 2004.
[4] O. Akerlund, P. Bieber, E. Boede, M. Bozzano, M. Bretschneider, C. Castel, A. Cavallo,
M. Cifaldi, J. Gauthier, A. Griffault, O. Lisagor, A. Lüdtke, S. Metge, C. Papadopoulos,
T. Peikenkamp, L. Sagaspe, C. Seguin, H. Trivedi, and L Valacca. ISAAC, a framework for
integrated safety analysis of functional, geometrical and human aspects. In 3rd Embedded
Real Time Software (ERTS2006), 2006.
[5] ARP4761. Guidelines and Methods for Conducting the Safety Assessment Process on
Civil Airborne Systems and Equipment. Aerospace Recommended Practice, Society of
Automotive Engineers, Detroit, USA, 1996.
[6] The ATESST Consortium. EAST ADL 2.0 Specification, February 2008.
[7] AUTOSAR GbR. Generic Structure Template, November 2009. Version 3.0.0.
[8] AUTOSAR GbR. Software Component Template, November 2009. Version 4.0.0.
[9] AUTOSAR GbR. Virtual Functional Bus, November 2009. Version 2.0.0.
[10] Andreas Baumgart, Philipp Reinkemeier, Achim Rettberg, Ingo Stierand, Eike Thaden,
and Raphael Weber. A model-based design methodology with contracts to enhance the development
process of safety-critical systems. In Sang Min, Robert Pettit, Peter Puschner,
and Theo Ungerer, editors, Software Technologies for Embedded and Ubiquitous Systems,
volume 6399 of Lecture Notes in Computer Science, pages 59–70. Springer Berlin / Heidelberg,
2011.
[11] Albert Benveniste, Benoît Caillaud, Roberto Passerone, Bernhard Josko, Eric Badouel,
and Benoît Delahaye. SPEEDS Meta-model Behavioural Semantics. Technical report,
SPEEDS Consortium, Jan 2007.
[12] Matthias Brill, Bernd Finkbeiner, and Sven Schewe. Automatic synthesis of assumptions
for compositional model checking. In 26th International Conference on Formal Methods
for Networked and Distributed Systems (FORTE 2006), pages 143–158. Springer Verlag,
2006.
153/ 156

Architecture Modeling
[13] Manfred Broy, Franz Huber, and Bernhard Schätz. AutoFocus – Ein Werkzeugprototyp
zur Entwicklung eingebetteter Systeme. Informatik Forschung und Entwicklung,
(13(3)):121–134, 1999.
[14] Matthias Büker, Alexander Metzner, and Ingo Stierand. ”testing real-time task networks
with functional extensions using model-checking”. In 14th International Conference on
Emerging Technologies and Factory Automation, 2009.
[15] W. Damm. Controlling speculative design processes using rich component models. In 5th
International Conference on Application of Concurrency to System Design (ACSD 2005),
2005.
[16] W. Damm and D. Harel. LSCs: Breathing Life into Message Sequence Charts. In
FMOODS’99 IFIP TC6/WG6.1 Third International Conference on Formal Methods for
Open Object-Based Distributed Systems, 1999.
[17] W. Damm, B. Josko, H. Hungar, and A. Pnueli. A compositional real-time semantics of
Statemate designs. In W.-P. de Roever, H. Langmaack, and A. Pnueli, editors, Compositionality
- The Significant Difference, LNCS 1536, pages 186–238. Springer, 1998.
[18] Werner Damm, Hardi Hungar, Bernhard Josko, Thomas Peikenkamp, and Ingo Stierand.
Using contract-based component specifications for virtual integration testing and architecture
design. In Conference on Design, Automation and Test in Europe, DATE’11, 2011.
[19] Werner Damm, Bernhard Josko, Amir Pnueli, and Angelika Votintseva. A discrete-time
uml semantics for concurrency and communication in safety-critical applications. Sci.
Comput. Program., 55(1-3):81–115, 2005.
[20] Werner Damm, Angelika Votintseva, Alexander Metzner, Bernhard Josko, Thomas
Peikenkamp, and Eckard Böde. Boosting re-use of embedded automotive applications
through rich components. In Foundations of Interface Technologies, FIT’05, 2005.
[21] Abhijit Davare, Douglas Densmore, Trevor Meyerowitz, Alessandro Pinto, Alberto
Sangiovanni-Vincentelli, Guang Yang, Haibo Zeng, and Qi Zhu. A next-generation design
framework for platform-based design. In Proceedings of Conference on Using Hardware
Design and Verification Languages (DVCon) 2007, February 2007.
[22] Luca de Alfaro and Thomas A. Henzinger. Interface automata. In Proceedings of the 8th
European software engineering conference held jointly with 9th ACM SIGSOFT international
symposium on Foundations of software engineering, ESEC/FSE-9, pages 109–120,
New York, NY, USA, 2001. ACM.
[23] Henning Dierks, Alexander Metzner, and Ingo Stierand. Efficient model-checking for realtime
task networks. In 6th International Conference on Embedded Software and Systems,
May 2009.
[24] J. Eker, J.W. Janneck, E.A. Lee, Jie Liu, Xiaojun Liu, J. Ludvig, S. Neuendorffer, S. Sachs,
and Yuhong Xiong. Taming heterogeneity - the ptolemy approach. Proceedings of the
IEEE, 91(1):127 – 144, January 2003.
[25] Daniel Gajski and Robert H. Kuhn. New vlsi tools - guest editors’ introduction. IEEE
Computer, 16(12):11–14, 1983.
154/ 156

Architecture Modeling
[26] Holger Giese, Matthias Tichy, Sven Burmester, Wilhelm Schäfer, and Stephan Flake.
Towards the compositional verification of real-time uml designs. SIGSOFT Softw. Eng.
Notes, 28:38–47, September 2003.
[27] Holger Giese, Matthias Tichy, Sven Burmester, Wilhelm Schäfer, and Stephan Flake. Towards
the Compositional Verification of Real-Time UML Designs. SIGSOFT Softw. Eng.
Notes, 28:38–47, September 2003.
[28] Object Management Group. Requirements Interchange Format (ReqIF), July 2010. Document
Beta/2010-07.
[29] C. Haerdt and A. Keis. Model-based integration of analysis services: Experiences with an
analysis dashboard. In 3rd Workshop on Model-Driven Tool & Process Integration, 2010.
[30] Nicolas Halbwachs and Louis Mandel. Simulation and verification of asynchronous systems
by means of a synchronous model. In Application of Concurrency to System Design
(ACSD’06), volume 0, pages 3–14, Los Alamitos, CA, USA, 2006. IEEE Computer Society.
[31] Alexander Harhuin, Florian Hölzl, and Thomas Kofler. Spes Metamodel. SPES 2020
Deliverable D1.4.A, The SPES 2020 Project, September 2010.
[32] ISO. ISO15622: Transport information and control systems - Adaptive Cruise Control
systems - Performance requirements and test procedures, 2002.
[33] ISO/IEC/(IEEE). ISO/IEC 42010 (IEEE Std) 1471-2000 : Systems and Software engineering
- Recomended practice for architectural description of software-intensive systems,
July 2007.
[34] Gilles Kahn. The semantics of simple language for parallel programming. In IFIP
Congress, pages 471–475, 1974.
[35] Kim Lauenroth, Ernst Sikora, Heiko Stallbaum, and Bastian Tenbergen. Initialer modellbasierter
Requirements-Engineering-Ansatz für Embedded Systems. SPES 2020 Deliverable,
The SPES 2020 Project, Universität Duisburg-Essen, September 2009.
[36] J. Matevska-Meyer, W. Hasselbrink, and R. Reussner. On a software architecture description
supporting component deployment and system runtime reconfiguration. In Proceedings
of the WCOP’04 Ninth International Workshop on Component-Oriented Programming,
2004.
[37] Bertrand Meyer. Applying ”design by contract”. Computer, 25(10):40–51, 1992.
[38] Jan Meyer. SysML Erweiterung zur Modellierung von Zeitverhalten. SPES 2020 Deliverable
AU-D3.3.A, The SPES 2020 Project, Universität Paderborn and Hella KGaA Hueck
& Co., September 2009.
[39] Object Management Group. OMG Systems Modeling Language (OMG SysML ),
november 2008. Version 1.1.
[40] Object Management Group. A UML Profile for MARTE: Modeling and Analysis of Real-
Time Embedded Systems, November 2009. Version 1.0.
155/ 156

Architecture Modeling
[41] Object Management Group. OMG Unified Modeling Language(OMG UML), Superstructure,
May 2010. Version 2.3.
[42] WP.2.1 Partners. SPEEDS L-1 Meta-Model. Technical report, SPEEDS Consortium, May
2009.
[43] Roberto Passerone, Jerry R. Burch, and Alberto L. Sangiovanni-Vincentelli. Refinement
preserving approximations for the design and verification of heterogeneous systems. Form.
Methods Syst. Des., 31:1–33, August 2007.
[44] Daniel Ratiu, Wolfgang Schwitzer, and Judith Thyssen. A System of Abstraction Layers
for the Seamless Development of Embedded Software Systems. SPES 2020 Deliverable
D1.2.A-2, The SPES 2020 Project, October 2009.
[45] Marvin Rausand. System Reliability Theory. Wiley, 2 edition, 2004.
[46] Herbert Stachowiak. Allgemeine Modelltheorie. Springer Wien, 1973.
[47] W. E. Vesely, F.F. Goldberg, N. H. Roberts, and D. F. Haasl. Fault Tree Handbook.
NUREG-0492. U.S. Nuclear Regulatory Commission, Washington DC, 1981.
[48] Tiziano Villa, Timothy Kam, Robert K. Brayton, and Alberto Sangiovanni-Vincentelli.
Synthesis of finite state machines: logic optimization. Kluwer Academic Publishers, Norwell,
MA, USA, 1997.
[49] Thomas Wagner and Ulrich Löwen. Modellierung technischer systeme. Technical report.
[50] Raphael Weber, Eike Thaden, and Philipp Reinkemeier. Specification of the SPES Meta-
Model. SPES 2020 Deliverable D3.2.B, The SPES 2020 Project, OFFIS, November 2010.
[51] H. Zimmermann. OSI Reference Model–The ISO Model of Architecture for Open Systems
Interconnection. IEEE Transactions on Communications, 28(4):425–432, 1980.
156/ 156