Architecture Modeling - SPES 2020
Architecture Modeling - SPES 2020
Architecture Modeling - SPES 2020
Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
<strong>Architecture</strong> <strong>Modeling</strong> ∗<br />
Andreas Baumgart, Eckard Böde, Matthias Büker, Werner Damm,<br />
Günter Ehmen, Tayfun Gezgin, Stefan Henkler, Hardi Hungar,<br />
Bernhard Josko, Markus Oertel, Thomas Peikenkamp, Philipp Reinkemeier,<br />
Ingo Stierand, Raphael Weber<br />
Thursday 10 th March, 2011<br />
∗ The research reported here has been mainly performed in the project <strong>SPES</strong><strong>2020</strong> (www.spes<strong>2020</strong>.de/)<br />
which is funded by the Ministry of Science and Culture. Also the projects CESAR<br />
(www.cesarproject.eu/) and SPEEDS (www.speeds.eu.com/) had major influences on the results of<br />
this work.
<strong>Architecture</strong> <strong>Modeling</strong><br />
©2011 OFFIS.<br />
All rights reserved. Copyright Notice: This material is presented to ensure timely dissemination<br />
of scholarly and technical work. Copyright and all rights therein are retained by authors or by<br />
other copyright holders. All persons copying this information are expected to adhere to the<br />
terms and constraints invoked by each author’s copyright. In most cases, these works may not<br />
be reposted without the explicit permission of the copyright holder.
Contents<br />
1 Introduction 1<br />
2 Quick-Tour 4<br />
2.1 Abstraction levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6<br />
2.2 Perspectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7<br />
2.3 Heterogeneous Rich Components . . . . . . . . . . . . . . . . . . . . . . . . . 9<br />
2.3.1 Component Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9<br />
2.3.2 Hierarchy and Composition . . . . . . . . . . . . . . . . . . . . . . . 13<br />
3 The <strong>Architecture</strong> Meta-Model 15<br />
3.1 Abstraction levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15<br />
3.2 Perspectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16<br />
3.2.1 Operational Perspective . . . . . . . . . . . . . . . . . . . . . . . . . 18<br />
3.2.2 Functional Perspective . . . . . . . . . . . . . . . . . . . . . . . . . . 19<br />
3.2.3 Logical Perspective . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19<br />
3.2.4 Technical Perspective . . . . . . . . . . . . . . . . . . . . . . . . . . . 21<br />
3.2.5 Geometrical Perspective . . . . . . . . . . . . . . . . . . . . . . . . . 27<br />
3.3 Heterogeneous Rich Components . . . . . . . . . . . . . . . . . . . . . . . . . 35<br />
3.3.1 Component Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35<br />
3.3.2 Hierarchy and Composition . . . . . . . . . . . . . . . . . . . . . . . 40<br />
3.4 Mapping Component Parts . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43<br />
4 Steps in Component-Based Design 45<br />
4.1 Formalizing Requirement Specifications with Contracts . . . . . . . . . . . . . 46<br />
4.1.1 Functional Specifications . . . . . . . . . . . . . . . . . . . . . . . . . 50<br />
4.1.2 Real–Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51<br />
4.1.3 Safety . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51<br />
4.2 Virtual Integration Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52<br />
4.2.1 Compatibility and VIT Condition . . . . . . . . . . . . . . . . . . . . 54<br />
4.2.2 Refinement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55<br />
4.2.3 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56<br />
4.3 Satisfaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60<br />
4.3.1 Establishing Functional Specifications . . . . . . . . . . . . . . . . . . 60<br />
4.3.2 Establishing Real-Time Contracts . . . . . . . . . . . . . . . . . . . . 61<br />
4.3.3 Establishing Safety Contracts . . . . . . . . . . . . . . . . . . . . . . 61<br />
4.4 Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61<br />
4.4.1 Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62<br />
4.4.2 Allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65<br />
4.4.3 Realization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65<br />
iii
5 Using the <strong>Architecture</strong> Meta-Model 67<br />
5.1 On the Role of Perspectives and Abstraction Layers . . . . . . . . . . . . . . . 67<br />
5.1.1 What We Can Learn from the EDA Domain . . . . . . . . . . . . . . . 67<br />
5.1.2 Perspectives and abstraction layers in system-level design . . . . . . . 70<br />
5.1.3 Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72<br />
5.2 On the role of contracts in system development processes . . . . . . . . . . . . 93<br />
5.2.1 Coping with complexity of systems . . . . . . . . . . . . . . . . . . . 93<br />
5.2.2 Coping with the Complexity of the Supply Chain . . . . . . . . . . . . 100<br />
5.2.3 Getting Initial Requirements Right . . . . . . . . . . . . . . . . . . . . 101<br />
5.2.4 Coping with Multi-Layer Design Optimization . . . . . . . . . . . . . 103<br />
5.2.5 Managing Risk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104<br />
5.2.6 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106<br />
6 Annex 108<br />
6.1 Syntax and Semantics of RSL . . . . . . . . . . . . . . . . . . . . . . . . . . 109<br />
6.1.1 Pattern specification . . . . . . . . . . . . . . . . . . . . . . . . . . . 110<br />
6.1.2 Semantics of observers . . . . . . . . . . . . . . . . . . . . . . . . . . 140<br />
6.1.3 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141<br />
6.2 Semantics of HRC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142<br />
6.2.1 Semantical Domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142<br />
6.2.2 Properties of Trace Sets . . . . . . . . . . . . . . . . . . . . . . . . . 142<br />
6.2.3 Semantical Definitions for HRC . . . . . . . . . . . . . . . . . . . . . 143<br />
6.3 Syntax and Semantics of Contracts . . . . . . . . . . . . . . . . . . . . . . . . 145<br />
6.3.1 Contract Basics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145<br />
6.3.2 Contracts: Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . 146<br />
6.4 Formalization of Typical Design Steps . . . . . . . . . . . . . . . . . . . . . . 147<br />
Glossary 150<br />
Bibliography 153
1 Introduction<br />
This document proposes a meta-model for architectures of embedded systems. The overall<br />
scope taken is deliberately broad, aiming at covering multiple perspectives of embeddedsystems<br />
based product development. As e. g. pointed out in [49], risk mitigation strategies<br />
in product development require a holistic approach encompassing all sub processes and their<br />
interfaces, hence requiring to cover the full range of what we call perspectives, from a geometric/physical<br />
view of the product, to a view focusing on its technical architecture, to a view<br />
elaborating its logical architecture, grouping functionality according to (sub-) system organisation,<br />
to a purely functional perspective (getting the functional specifications right), and starting<br />
with an operational perspective, focusing on interface requirements e. g. based on operational<br />
scenarios. This separation of concerns by perspectives is complemented by offering abstraction<br />
levels, as a well known principle to cope with complexity in system design. Hence design artifacts<br />
can be placed in a two-dimensional design space, organized by perspective and level of<br />
abstraction.<br />
We enrich this generic approach by a component model largely derived from the concept of<br />
Heterogeneous Rich Components (HRC)[20]. Specifically, this allows to provide rigorous interface<br />
specifications for design artifacts residing in this two-dimensional design space. The term<br />
“rich” alludes to the key ingredient of HRC components to provide (rigorous) interface specifications<br />
for multiple what we call aspects, encompassing both functional and extra-functional<br />
(e.g. safety and real-time) characteristics of components. Specifically, we propose the usage of<br />
contract-based specifications, which allow, for each aspect, to characterize the allowed design<br />
contexts of a component (through what we call strong assumptions) - violating these constitutes<br />
an out-of-specification (“illegal”) usage of the component, thus “excluding liability”: no<br />
guarantees of the component’s functional and extra-functional characteristics are given for such<br />
illegal design contexts. For allowed design contexts, the guarantee part of the contract allows to<br />
characterize both functional and extra-functional properties of the component. Often, these are<br />
case-dependent; we support what we call weak assumptions structuring contract specifications<br />
according to cases (thus refining the allowed design contexts).<br />
Weak assumptions partition the context in which the system is intended to be used with<br />
respect to its strong assumption. Hence, a single weak assumption defines only a part of the<br />
allowed system context. With this, it is possible to define different use cases for a component. If<br />
the context is able to ensure a weak assumption of a component, this component may guarantee<br />
a more restricted behavior. Note, that the notion of weak assumptions does not adress operation<br />
modes, which are switched during operation of the corresponding system.<br />
We propose a formal pattern based specification language RSL for expressing both assumptions<br />
and guarantees. RSL comes with patterns supporting multiple aspects of components;<br />
within <strong>SPES</strong> we focus on modelling functional aspects, real-time aspects, and safety aspects.<br />
We point out, that the notion of contract-based specifications is independent of the choice of the<br />
concrete formal notation for expressing contracts. Indeed, contracts can as well be formalized<br />
within other formal specification languages, such as AutoFocus [13], Live Sequence Charts<br />
[16], PSL [2], Interface Automata [22], Real-Time Statecharts [26] etc.<br />
Aspects of components can thus be rigorously specified through contracts. Their realization,<br />
1/ 156
<strong>Architecture</strong> <strong>Modeling</strong><br />
or their implementation, in terms of an executable model or even code, is deliberately left open<br />
in the meta model, in order to provide flexibility in using aspect-specific modelling formalisms.<br />
The formal foundation assumes, that – whatever modelling method is used – the capability to<br />
associate with such models a what is often called trace-based semantics, which, for each interface<br />
object, defines for each point in time the value of such interface objects. Implementations<br />
are allowed to be non-deterministic, hence yielding sets of such traces as their formal representation,<br />
but would typically be input-deterministic and responsive, i. e. yield for each valuation<br />
of an interface object under control of the components environment a uniquely determined valuation<br />
of interface objects under control of the component. Note that in particular modelling<br />
approaches such as AutoFocus, which come with a formal semantics, meet this requirement.<br />
When using commercial-off-the-shelf (COTS) tools for modelling the realization of a component,<br />
a strictly formal development process requires the ability to verify compliance of such<br />
models against contracts, requiring a formal definition of their semantics. Such formal semantics<br />
have been given for a plurality of COTS tools [17, 19, 3]. Less formalized development<br />
processes can use test cases automatically derivable from contract specifications to demonstrate<br />
compliance of component realizations and specifications.<br />
Within the generic landscape characterized by perspectives and abstraction layers, the emphasis<br />
is on supporting the major phases of system development, from product requirements<br />
to a specification of the technical architecture of the system. In particular, the transition to the<br />
geometric perspective, which is served by tools like CATIA 1 or the Siemens PLM suite 2 , is<br />
not elaborated in the current version of this document. In other project contexts, the role of<br />
contracts as an interface between the geometric and the technical perspective has been demonstrated,<br />
such as the impact of physical allocation decisions and routing of cables on the safety<br />
case [4] has already been demonstrated.<br />
This document is organized as follows. A quick tour in Section 2 elaborates on an informal<br />
level the key concepts of perspectives, abstraction layers and Heteregenous Rich Components,<br />
by way of example, providing first indications as to their possible role in design processes.<br />
This is complemented by a detailed specification on the conceptual level of the architecture<br />
meta-model.<br />
The ensuing section adds more detail on the syntax of the meta-model and how design artifacts<br />
are to be represented. It is thus technical in nature and could be skipped on first reading.<br />
Section 4 presents primitive steps in component-based design. It introduces on an informal level<br />
the main concepts underlying contract-based design — contract syntax and semantics, properties,<br />
their usage in specification, verification and virtual integration testing — and how they are<br />
applied to perform the design task from requirement definition to deployment. While this section<br />
provides a bottom-up view of design, Section 5 on using the architecture meta-model adds<br />
the top-down perspective, painting the broad picture of applying contract-based design in the<br />
industrial context. In fact, readers with an industrial background may prefer to read this section<br />
after the quick tour before delving into the more detailed sections 3 and 4.<br />
The annex, finally, provides the formal underpinning of this approach. In particular, it provides<br />
a reference manual for the proposed requirement specification language, a formal semantics<br />
of contracts, a formal semantics of HRC components, and the formal foundations for<br />
primitive design steps in component based design.<br />
This document thus provides guidance in using the release of the architecture meta-model,<br />
1 http://www.3ds.com/de/products/catia<br />
2 http://www.plm.automation.siemens.com/en us/products/teamcenter/ , http://www.3ds.com/plm<br />
2/ 156
<strong>Architecture</strong> <strong>Modeling</strong><br />
allowing to model applications using the concepts of the meta-model, as well as building component<br />
specifications with contracts. OFFIS is offering end users to support such modelling<br />
activities.<br />
3/ 156
2 Quick-Tour<br />
This section intends to provide an overview and basic understanding to the concepts of the <strong>SPES</strong><br />
meta-model architecture supporting a component-based design of embedded systems. First<br />
concepts are presented in [10]. Further the terminology is introduced that is applied throughout<br />
this document. Each term suffixed by (↑) can also be found in the glossary at the end of this<br />
document. Keeping brevity in this section is intentional. All concepts are again discussed<br />
in Section 3 in more detail, and how they are expressed in the architecture meta-model. In<br />
Section 4, a set of primitive design steps are discussed that are typically performed in a design<br />
employing the <strong>SPES</strong> meta-model architecture. Section 5 gives a broader view on how to use the<br />
meta-model with regard to a development process, and also gives further examples. Section 6<br />
finally provides the formal foundation.<br />
Aspect<br />
Specification<br />
Aspect<br />
Realization<br />
Abstraction<br />
Model<br />
Real World<br />
1. Dimension<br />
Abstraction Levels<br />
Safety<br />
Functional<br />
Behavior<br />
View<br />
System<br />
other<br />
aspect<br />
Real-Time<br />
Abstraction<br />
2. Dimension<br />
Perspectives<br />
Figure 2.1: A view addressing different aspects placed in the two-dimensional design space<br />
While distributed embedded systems become more and more complex, market pressure however<br />
requires systems companies to develop high-quality products in short time. Thus, approaches<br />
to architecture design are needed providing means to deal with complexity, and to<br />
reason about qualities of the architecture already in early steps of the overall development process.<br />
In order to deal with complexity, the <strong>SPES</strong> meta-model architecture provides abstraction<br />
and refinement techniques, and views on an architecture model. Abstraction allows the designer<br />
to concentrate on the essentials of a problem by eliminating unnecessary details. Abstraction<br />
levels(↑) allow to describe a design item (e.g. component(↑), sub-system or the entire system<br />
under development(↑)) with a specific degree of detail. Refinement(↑) adds detail to abstract<br />
architecture models while preserving the semantics of the abstraction. That is e.g. a more concrete<br />
description of a component also has to fulfill all specifications of the abstract component<br />
it has been derived from. Following the principle of seperation of concerns, the architecture<br />
meta-model also supports the concept of viewpoints(↑) that provide constructs and rules for describing<br />
a view(↑) of the system under development(↑). A view is created by a set of models of<br />
the system under development and/or its parts and is related to a viewpoint. The set of models<br />
4/ 156
<strong>Architecture</strong> <strong>Modeling</strong><br />
creating a view belong to a specific abstraction level. In contrast the viewpoint that provides<br />
means to describe a view is orthogonal to abstraction levels. The notion of viewpoints used<br />
here corresponds to the notion of viewpoints of IEEE 1471-2000 [33]. The term model can be<br />
understood as the description of some original entity that only reflects the relevant (from the<br />
modeller point of view) properties of the original entity. A model is created for purpose and<br />
is used in place of the original entity [46]. In this document when using the term model we<br />
assume it has been created by means of the concepts provided by the architecture meta-model.<br />
Thus, the meta-model is in fact a model of models, which means it describes relevant properties<br />
of models.<br />
A perspective(↑) combines views belonging to different abstraction levels. Thus, it is actually<br />
a viewpoint, as a perspective provides means to construct a view. The terms view, perspective<br />
and abstraction level are illustrated in Figure 2.2. Abstraction levels and perspectives form<br />
a two-dimensional design space, where design artifacts may be placed in. According to the<br />
definition each cell in the matrix is considered a view. The concept of aspects(↑) allow coping<br />
with complexity in constructing a view, i.e. a cell of the matrix. Therefore an aspect is part of a<br />
view. Examples for aspects are: Functional behavior, real-time and safety.<br />
Considering a system under development, the structure of models of each considered perspective<br />
are not necessarily congruent. A model of the functional perspective will be composed<br />
differently than a model of the technical perspective. In contrast a view may address different<br />
aspects of the same design item. Figure 2.1 illustrates that relationship. In Figure 2.2 the matrix<br />
of abstraction levels and perspectives is shown. Some fields of the matrix are intentionally left<br />
blank, because depending on the current phase of the development process certain perspectives<br />
may not be regarded or refined.<br />
Figure 2.2: Matrix of abstraction levels and perspectives<br />
Any development of an embedded system is done according to some process model, which<br />
describes the steps to be taken, together with the work products created in that steps. The Vmodel<br />
(see Figure 2.3) has become a well established model for many development processes.<br />
It shows how an embedded system can be developed along several abstraction levels starting<br />
with user requirements for operational scenarios, analysis of functions with refined require-<br />
5/ 156
<strong>Architecture</strong> <strong>Modeling</strong><br />
ments, design decisions with derived requirements and a final implementation. The developed<br />
product has to be tested on all levels, which includes validating the integration of components,<br />
systems and the entire product. On each design-phase on the left branch the architecture might<br />
be regarded from different perspectives as the ones shown in Figure 2.2. Models of each perspective<br />
can address different aspects. However not all aspects are relevant in each combination<br />
of abstraction level and perspective. For example an aspect safety might be regarded in every<br />
perspective whereas an aspect real-time is not regarded in a geometrical perspective.<br />
e.g. Maintainability<br />
Assessment Process<br />
Analysis of Product Level<br />
Requirements<br />
Development of<br />
Functional<br />
<strong>Architecture</strong><br />
e.g Cost<br />
Assessment Process<br />
Development of<br />
System<br />
<strong>Architecture</strong><br />
Development of<br />
Technology-oriented<br />
<strong>Architecture</strong><br />
Safety<br />
Assessment Process<br />
Early virtual Integration<br />
based on formal analysis<br />
techniques<br />
Development of<br />
Deployment<br />
<strong>Architecture</strong><br />
Mechanical<br />
Electrical<br />
Digital Hardware<br />
Software<br />
Modultest<br />
Subsystem<br />
Integration<br />
System Integration<br />
Figure 2.3: V-model<br />
The architecture meta-model is based on the meta-model of Heterogeneous Rich Components<br />
(HRC), which has formally defined semantics (discussed in Section 6.2). The meta-model,<br />
which incorporates the concepts we describe in this quick-tour, is designed to be independent<br />
of any application domain (e. g. automotive, avionics, medical). It defines the concepts and<br />
how they are related to each other. That allows us to interpret domain specific meta-models<br />
according to these concepts, thereby making analysis techniques available.<br />
Note that it is out of the scope of this document to describe a development process defining<br />
a sequence of steps to be carried out and what concepts to use in which development step.<br />
That also means the way the design space, spanned by the two dimensions abstraction level<br />
and perspective, is traversed is not prescribed here. The previous paragraph describing a development<br />
process according to the V-model and relating it to the concepts of abstraction levels,<br />
perspectives and aspects has to be understood as an example. Instead concepts for establishing<br />
traceability are provided for carrying out transitions in the matrix, as well as resulting proof<br />
obligations are described.<br />
2.1 Abstraction levels<br />
A system under development(↑) or a constituting design item (e.g. a component) can be modeled<br />
on different abstraction levels(↑). Less abstract models belonging to a lower abstraction<br />
level may increase the degree of detail of the description of the design item at hand. For example<br />
the interface description may be refined as well as the demanded behavior. Therefore increasing<br />
the level of detail, thus at the same time lowering the level of abstraction, adds knowledge about<br />
Product<br />
Integration<br />
Certification<br />
6/ 156
<strong>Architecture</strong> <strong>Modeling</strong><br />
the design item. Often reducing the level of abstraction is accompanied by a refined granularity.<br />
That is, the design items under consideration are decomposed into multiple finer grained items<br />
in order to keep them at a manageable size. Refining the granularity is however not a necessary<br />
condition, when introducing a lower level of abstraction. For example one may describe the<br />
same design item on two different levels of abstraction with the same granularity, but precise<br />
the specification of a certain aspect. Despite an increasing level of detail, another motivation for<br />
introducing a dedicated abstraction level can be the handover of an initial system specification<br />
to another organizational unit. Thus the initial specification can remain unchanged and on a new<br />
abstraction level the model can be refined as well as the interface specifications of the components.<br />
Realization(↑) links between component parts allow to trace those refinements. While<br />
models on lower abstraction levels provide more detail, the components still have to respect the<br />
aspects(↑) specified for their higher level counterparts.<br />
For example, consider a logical architecture of an Adaptive Cruise Control (ACC) [32] modeled<br />
by means of components as depicted in the upper half of Figure 2.4. The component Acc<br />
is composed of a ForwardSensor that provides data about objects in front of a vehicle and a<br />
Ctrl component that controls the distance between the ego-vehicle and those in front of it or<br />
maintains a speed set by the driver (not shown in Figure 2.4) in case there are no other vehicles<br />
detected.<br />
Suppose that requirements in terms of aspect specifications formalized as contracts have been<br />
specified for the component Acc and its sub-components. During a refinement step the component<br />
Ctrl may be split up into multiple finer grained components, each realizing a dedicated<br />
part of the Ctrl component and its specification. In the example three new components have<br />
been introduced in the refined version of the Acc composition: A FollowCtrl component<br />
that controls the distance between the ego-vehicle and those in front of it, a SpeedCtrl component<br />
controling the speed set by the driver and an Arbitration component that chooses<br />
between the acceleration outputs of both controlers.<br />
Note that the entire interface of the RefinedAcc composition changed, as an output port<br />
accStatus has been added, which is connected with a corresponding output port of the<br />
FollowCtrl component. Therefore this design step cannot be captured by a simple decomposition.<br />
Instead realization-links can be used to trace such refinement steps. The realization-link<br />
relates component parts and also carries a set of attributes that allow to map ports owned by the<br />
parts, which are involved in the realization relationship. In the example the Realize-link from<br />
FollowCtrl to Ctrl would carry (amongst others) an attribute pointing to both ports named<br />
speed of each component. In Section 4.4 we discuss the primitive design step of switching<br />
abstraction levels by means of Realize-links and its semantic.<br />
In discussions with industrial partners during the <strong>SPES</strong> project it became clear, that design<br />
processes are very diverse for different domains like e. g. automotive and avionics. It depends<br />
on the design process and the role of a company in the supplier chain, how many levels of<br />
abstraction a system under development will undergo. In addition the domain specific terms<br />
used for designs at a given level of abstraction vary. Therefore we cannot define a unique fixed<br />
set of abstraction levels. Instead we consider a generic abstraction level concept, which can<br />
be tailored to the specific needs of a company or an application domain and provide semantics<br />
allowing to reason about realization between different abstraction levels.<br />
2.2 Perspectives<br />
Apart from the distinction of different user-defined abstraction levels, an abstraction level itself<br />
contains a set of model representations, i.e. views(↑) of the system under development(↑).<br />
7/ 156
:ForwardSensor<br />
:ForwardSensor<br />
objects<br />
<strong>Architecture</strong> <strong>Modeling</strong><br />
objects<br />
Acc<br />
RefinedAcc<br />
:FollowCtrl<br />
speed<br />
accel<br />
:Ctrl<br />
speed<br />
accel<br />
«Realize»<br />
:SpeedCtrl<br />
speed<br />
accel<br />
accStatus<br />
:Arbitration<br />
accel<br />
Figure 2.4: Refinement of a logical architecture of an ACC<br />
These views correspond to a perspective(↑), which thereby is considered a viewpoint(↑). As<br />
viewpoints are orthogonal to abstraction levels, the same holds for perspectives. The concept<br />
of perspectives allows to group views of different disciplines in order to cope with complexity.<br />
Currently we distinguish five perspectives.<br />
Operational perspective In the operation perspective(↑) the context of the system is considered.<br />
That means the embedding of the system under development in its environment is<br />
modeled and analysed including the interactions of the system with its environment. As<br />
a result the system boundary is determined, i. e. its interface, as well as requirements on<br />
the interface behavior.<br />
Functional perspective In the functional perspective(↑) the functional needs of the system<br />
and their breakdown into sub-functions is modeled that together realize the top-level system<br />
functions.<br />
Logical perspective In the logical perspective(↑) the system under development is decomposed<br />
by means of hierarchical components(↑) that implement the functions identified in<br />
the functional perspective. Thus, the logical perspective serves as a partitioning of functions<br />
driven by concerns(↑) like performance, reusability and management of the supply<br />
chain, i. e. to consider the interfaces between organizations in the supply chain. However,<br />
any kind of resources or properties of a target platform are still neglected here.<br />
Technical perspective In the technical perspective(↑) the electrical and electronical architecture,<br />
the software and mechanical parts of the system under development are described.<br />
That encompasses mechanical, hydraulic parts, and electronic control units, buses, and<br />
software tasks, where the components of a view corresponding to the logical perspective<br />
shall be allocated to. While in the logical perspective it is usually assumed that each component<br />
can always be executed, in the technical perspective resource limitations come<br />
into play. Some resources, e. g. electronic control units, will be shared by multiple components,<br />
whose behaviour will therefore depend on the properties of the resource as well<br />
as other components allocated to the very same resource. The allocation of components<br />
8/ 156
<strong>Architecture</strong> <strong>Modeling</strong><br />
of the logical perspective to elements of the technical perspective results in a hardwaresoftware<br />
partitioning.<br />
Geometrical perspective In the geometrical perspective(↑) the physical layout of the system<br />
is considered. While in the technical perspective some resource is modelled in terms of<br />
its properties, its interfaces and its behaviour, in the geometrical perspective its spatial dimensions<br />
are modelled. The geometrical perspective deals for example with cable lengths<br />
and space limitations.<br />
The concept of different perspectives and abstraction levels is inspired by partitions of EAST-<br />
ADL abstraction levels [6] and meetings with industrial partners of the <strong>SPES</strong><strong>2020</strong> project. Taking<br />
a look at EAST-ADL one can see that one distinct EAST-ADL architecture level is split<br />
into different perspective models: The Design Level contains a Functional Design <strong>Architecture</strong><br />
as well as a Hardware Design <strong>Architecture</strong>. We generalized that concept by means of the<br />
perspectives allowing the partitioning of architectures in each level of abstraction.<br />
The entities and their interfaces defined in different perspectives do not need to be compatible<br />
to each other. For example, three interacting functions defined at the functional perspective<br />
may be modelled as two components in a logical perspective. The palette of actually used<br />
perspectives can be different at each abstraction level. In early design stages for example, when<br />
the functions of the system are to be defined, the target platform (modelled in the technical<br />
perspective later on) need not necessarily be of interest.<br />
2.3 Heterogeneous Rich Components<br />
The meta-model of Heterogeneous Rich Components (HRC), which originates from the European<br />
SPEEDS project [42], constitutes the core of the architecture meta-model proposed in<br />
<strong>SPES</strong>. This section gives a short introduction into its concepts.<br />
2.3.1 Component Model<br />
The paradigm of component-based design is well established and used in many different application<br />
domains. In standards like EAST-ADL [6] and AUTOSAR [9], a component is the basic<br />
design-entity structuring any model. A component(↑) has a well defined interfaces and is the<br />
Component<br />
Port<br />
C1<br />
aspect<br />
specification<br />
aspect<br />
realization<br />
conforms<br />
to<br />
Figure 2.5: Components, aspect specification and realization<br />
basic entity of any model. The interfaces allow to abstract from the internals of a component<br />
and to reuse it in different design contexts. The notion of components can be established independently<br />
of any design domain. That is, a component can model a reusable piece of software,<br />
9/ 156
<strong>Architecture</strong> <strong>Modeling</strong><br />
a specific sensor measuring temperature or a computing device (e. g. ECU or IMA module)<br />
hosting software applications.<br />
The generic concept of components is extended resulting in so called Heterogeneous Rich<br />
Components (HRC)(↑). Per aspect these HRCs have a specification as well as a realization (cf.<br />
Section 2.3.1.2). Figure 2.5 depicts those fundamental principles of an HRC. Per aspect it has<br />
specifications of its behavior with respect to that aspect. Optionally an aspect realization of the<br />
component is given. Parts of the behavior are exposed at the ports(↑) of the component.<br />
2.3.1.1 Ports<br />
Ports(↑) are the interaction points of a component. Together with their types they define the<br />
syntactical interface of the component. A port can either define a data-oriented interaction<br />
point or service-oriented interaction point. Further, they have a direction and are either input<br />
port (sometimes called required ports), output ports (provided ports) or bidirectional.<br />
p1:PortSpec1<br />
p2:PortSpec2<br />
Component<br />
f1<br />
f2<br />
f3<br />
PortSpec1<br />
Flow<br />
PortSpec2<br />
s1(param,...):return<br />
s2(param,...):return<br />
Service<br />
Figure 2.6: Typing of Ports<br />
A port has a name and is typed by a port specification as illustrated in Figure 2.6. That<br />
specification is a set of flows or a set of services. A flow also has a name and is typed by a<br />
datatype like for example int. A Service has a name as well and is declared by its parameters<br />
and return type.<br />
2.3.1.2 Aspects<br />
A view modeled by an HRC may address different aspects(↑). The concept of aspects classifies<br />
descriptions of the dynamic behavior of an HRC. Though being extensible by user-defined<br />
aspects, we currently consider three pre-defined aspects: functional behavior, real-time and<br />
safety. The functional behavior aspect of an HRC characterizes its dynamics by relating events<br />
to each other and describing the handling of conditions and invariants. The real-time aspect<br />
of an HRC defines the timings of its functional behavior, such as assumed activation behavior<br />
(e.g periodic with jitter) or end-to-end deadlines of chains of functions. The real-time aspect<br />
usually abstracts from actual values received or sent at the ports of an HRC, but focusses on<br />
the timing of events instead. The safety aspect of an HRC provides specification of single point<br />
of failures, as well as failure conditions and hazards. This also encompasses probabilities for<br />
the occurrence of failure conditions. Thus aspect specifications describe functional and nonfunctional<br />
characteristics of an HRC.<br />
For each aspect of an HRC there can be a specification and an aspect realization. A specification<br />
of an aspect of an HRC is a characterization of the realization of the HRC with regard to<br />
the aspect. That means an aspect specification defines ”what” an HRC does, while a realization<br />
describes ”how” it does that. Specifications are done by means of so called contracts(↑). The<br />
10/ 156
<strong>Architecture</strong> <strong>Modeling</strong><br />
realization of a certain aspect of an HRC can be modelled by any other formalism (e. g. FOCUS,<br />
MechatronicUML [27], Matlab/Simulink, Stateflow). As the only prerequisite for compatibility,<br />
that formalism must have a semantics based on traces.<br />
In [38] exemplary Real-Time Statecharts are shown, which would be an example of a realization<br />
of the aspect real-time.<br />
2.3.1.3 Contracts<br />
The concept of contracts(↑) is meant to provide a specification of an aspect(↑) of an HRC. One<br />
of the key concepts is the ability to thereby abstract from the actual aspect realizations of HRCs<br />
and to characterize the required behavior using contracts. The idea is insprired by Bertrand<br />
Meyer’s programming language Eiffel and its design by contract paradigm [37].<br />
A contract is a triple (As,Aw,G), where As is the strong assumption of a contract, Aw the weak<br />
assumption and G the guarantee. A strong assumption characterizes the allowed design context<br />
of an HRC, i. e. the environment from the point of view of the HRC. If the design context<br />
does not comply to a strong assumption, then this constitutes an ”illegal” out of specification<br />
usage of the corresponding HRC. As an analogy one can think about strong assumptions as a<br />
specification of contractual liabilities. In fact, they may even be used that way in OEM/supplier<br />
negotiations. A weak assumption defines different integration contexts by making case<br />
distinctions. Thus a weak assumption actually refines the integration context required by the<br />
strong assumption. If an HRC is used accordingly to its strong assumptions, it will guarantee<br />
the behavior specified by the guarantee, provided the weak assumption is fulfilled. This enables<br />
the verification of virtual system-integration at an early stage in a design flow, even when there<br />
is no implementation yet.<br />
A contract is a requirement with a specific structure (strong, weak assumptions and guarantee).<br />
The concept of contracts makes assumptions about context explicit, which allows to<br />
assign responsibilities in development processes. Typically contracts are derived from top-level<br />
system requirements that may be captured in external requirements management tools like e. g.<br />
DOORS. Keeping those requirements separate from an architecture model may be required by<br />
certification processes.<br />
Ports expose parts of the behavior of the HRC. Thus the specification of an aspect of an HRC<br />
by means of a contract refers to its ports and constrains the behavior observable at those ports.<br />
Note that when specifying assumptions (strong and weak), they must not limit the output ports<br />
of the HRC. In turn the guarantee must not limit its input ports.<br />
:FollowCtrl<br />
objects accel<br />
speed<br />
:Arbitration<br />
folwAccel<br />
crsCtrlAccel<br />
:Vlc<br />
accel accel<br />
Figure 2.7: FollowCtrl component of an ACC<br />
As an example for the difference between strong and weak assumptions reconsider the<br />
FollowCtrl component of an ACC from the example in Section 2.1 that controls the distance<br />
between the ego-vehicle and those in front of it. The component has two input ports<br />
on which it receives data of objects recognized by some sensor component and the current<br />
travelling speed of the ego-vehicle, respectively. On its output port the component provides acceleration<br />
commands. The example has been slightly modified by inserting a component Vlc<br />
11/ 156
<strong>Architecture</strong> <strong>Modeling</strong><br />
(Vehicle Longitudinal Control) that receives the acceleration commands either produced by<br />
the FollowCtrl component or by the SpeedCtrl component and processes them. Which<br />
value is forwarded is determined by the Arbitration component based on the current overall<br />
state of the ACC (not shown in the figure). Now for the FollowCtrl component suppose<br />
there exist two contracts C1 and C11, which are defined as follows:<br />
C1<br />
strong assumption always (0 ≤ speed ≤ 70 m s )<br />
weak assumption true<br />
guarantee always (−3.0 m<br />
s2 ≤ accel ≤ 3.0 m<br />
s2 )<br />
C11<br />
strong assumption always (0 ≤ speed ≤ 70 m s )<br />
weak assumption always (0 ≤ speed ≤ 50 m s )<br />
guarantee always (−2.5 m<br />
s2 ≤ accel ≤ 2.5 m<br />
s2 )<br />
Thus, the component FollowCtrl is designed to operate at travelling speeds up to 70 m s<br />
and guarantees it will issue acceleration commands in the value range [−3.0 m<br />
s2 ,3.0 m<br />
s2 ]. It may<br />
only be integrated in a context, where its environment ensures the strong assumption. Contract<br />
C11 however adds a weak assumption that actually confines the strong assumption by<br />
and guarantess acceleration commands in the value range<br />
requiring a maximum speed of 50 m s<br />
[−2.5 m<br />
s2 ,2.5 m<br />
s 2 ]. For the integration of the FollowCtrl component that means, if its con-<br />
text can even ensure the weak assumption, then the smaller range specified in the guarantee of<br />
C11 may be relied on when connecting FollowCtrl to the Arbitration and Vlc components.<br />
In that case both components can be more restrictive with regard to its own strong<br />
and weak assumptions as they only need to deal with a smaller range of acceleration values.<br />
Note that actually the same range of acceleration values must be assumed on the port named<br />
crsCtrlAccel of the Arbitration component such that it can also guarentee to provide<br />
that value range on its output port accel.<br />
2.3.1.4 Requirement Specification Language<br />
The semantics of contracts and HRC provide the formal basis for reasoning about the relation of<br />
specifications stated as contracts and about the composition of HRCs and their contracts. With<br />
the requirements specification language (RSL)(↑) described in Section 6.1 we provide syntax<br />
and semantics of a pattern-based language, which can be used to define the aspect specifications<br />
of an HRC. An instance of a pattern of the RSL can be used to specify the assumption (strong<br />
and weak) as well as the guarantee parts of a contract.<br />
PortSpec1<br />
e1<br />
ComponentA<br />
p1 p2<br />
p3<br />
refers to<br />
C1<br />
refers to<br />
Figure 2.8: Linking contracts and components<br />
PortSpec2<br />
Suppose an HRC has been defined as sketched in Figure 2.8. It has two ports p1 and<br />
p2, which are typed by two port specifications PortSpec1, PortSpec2 respectively.<br />
Now the designer can select a pattern that suits the aspect, for which a contract shall<br />
be specified. As an example assume that a latency of 10ms is to be specified from the<br />
time data arrives at port p1 to the time data is provided at port p2. Such a specification<br />
f1<br />
12/ 156
<strong>Architecture</strong> <strong>Modeling</strong><br />
can usually only be realized by making assumptions about the frequency at which data arrives<br />
at the input port p1. Thus for the real-time aspect of the HRC a contract might be:<br />
C1<br />
strong assumption p1.e1 occurs each 10ms with jitter 1ms<br />
weak assumption true<br />
guarantee delay between p1.e1 and p2.f1 within [0ms,10ms]<br />
The different patterns, which can be instantiated in order to specify the assumptions and guarantees<br />
of a contract, are defined in Section 6.1.1. Each pattern belongs to a category (functional<br />
patterns, real-time patterns), which is reflected by its name. For example all patterns with names<br />
prefixed by the letter F are functional patterns and the prefix R denotes a real-time pattern. The<br />
category of a pattern gives a first hint for the specification of which aspect it may be suited best.<br />
With regard to the example contract C1 an instance of the pattern R2 has been used for the<br />
strong assumption and an instance of the pattern R3 for the guarantee. The concrete number of<br />
the pattern does not need to be specified, as it can be automatically derived from the syntax of<br />
the expression.<br />
2.3.2 Hierarchy and Composition<br />
When a component is used as part(↑) in the context of another component, its ports(↑) can<br />
be linked to other parts forming a composition of components. That composition is again a<br />
component, whose behavior is given by the behavior of its constituting parts. Thus components<br />
can support both top-down as well as bottom-up design approaches and mixed forms thereof.<br />
2.3.2.1 Hierarchy<br />
ComponentC<br />
part2:ComponentB<br />
component<br />
instance<br />
role<br />
Ports<br />
part1:ComponentA<br />
ComponentA<br />
C1<br />
aspect<br />
specification<br />
aspect<br />
realization<br />
Figure 2.9: Hierarchy of components<br />
component<br />
specification<br />
The component model of HRC supports the type/part concept found in many other modeling<br />
languages, e. g. the UML [41]. Figure 2.9 shows an illustration of that concept. An HRC<br />
ComponentA is modelled with its ports and contracts that specify the behavior of that HRC<br />
under the different aspects. That HRC can be used in the context of other HRCs playing the role<br />
of a part in that context. A part denotes component instances that the surrounding HRC owns<br />
by composition. In the example, the HRC ComponentA is used as part with the role name<br />
part1 in the context of the HRC ComponentC. The aspect specifications characterized by<br />
contracts that are linked to ComponentA and corresponding realizations are valid for part1<br />
as well. This holds for any context, in which ComponentA is used as a part.<br />
The type/part concept results in a possibly deeply nested hierarchy of components ultimately<br />
leading to some top-level component specification. Such a hierarchy of HRCs can be con-<br />
13/ 156
<strong>Architecture</strong> <strong>Modeling</strong><br />
structed for every combination of abstraction level and perspective, representing a view of the<br />
system under development.<br />
2.3.2.2 Composition<br />
The ports of HRCs used as parts in the context of another HRC are interconnected forming a<br />
composition of HRCs. In a component-based design there are two use-cases for the composition<br />
concept. A component can be decomposed(↑) into smaller subcomponents in a top-down approach.<br />
So, a large design is split into smaller components, that can be implemented or further<br />
decomposed. Following a bottom-up approach one can also specify components and integrate<br />
them in a composition to realize its specification.<br />
ComponentC<br />
delegation<br />
connector<br />
part2:ComponentB<br />
part1:ComponentA<br />
ComponentB<br />
C2<br />
C12<br />
assembly<br />
connector<br />
ComponentA<br />
C1<br />
Figure 2.10: Compositions of components<br />
To decide whether an HRC can be used in a given context and connected with other HRCs,<br />
the ports that are connected must be compatible. Compatibility of ports is discussed in Section<br />
3.3.2.2. Figure 2.10 shows the distinction between delegation connectors and assembly<br />
connectors. The former connect the outer ports of an HRC to ports of its constituting parts. So<br />
in order to connect the ports they must have the same direction. Assembly connectors link the<br />
parts of a composition to each other.<br />
Additionally with regard to the contracts a Virtual Integration Test(↑) must be carried out (cf.<br />
Section 4.2). Related to the example from Figure 2.10 it must be checked, that the contracts C1<br />
and C2 are compatible and that together with the interconnection they are a valid refinement of<br />
C12.<br />
p1<br />
p2<br />
14/ 156
3 The <strong>Architecture</strong> Meta-Model<br />
In Section 2 we briefly introduced the fundamental concepts of the architecture modeling approach.<br />
In this section these concepts are described in more detail. In addition it is shown how<br />
they are expressed in the architecture meta-model and how concepts relate to each other. However<br />
it is not in the scope of this document to give a complete specification of the architecture<br />
meta-model. That specification is delivered seperately in [50]. Note, that we sometime use the<br />
abbreviation <strong>SPES</strong>MM denoting the architecture meta-model.<br />
3.1 Abstraction levels<br />
The <strong>SPES</strong>MM introduces a generic concept of abstraction levels. An abstraction level represents<br />
the system under development at a certain level of detail. A car for example may be<br />
modelled at the top-level as a single component where only the interface of the car to the environment<br />
is visible. At a lower level, certain components of the car may be visible (chassis,<br />
engine, ...), and so on.<br />
+subPackage<br />
Package<br />
SystemModel<br />
+owner 0..1<br />
1..*<br />
+owner<br />
0..1<br />
0..*<br />
+abstractionLevel<br />
DeclarationZone<br />
1 +topLevel<br />
+declarationZone<br />
0..1<br />
+owner<br />
AbstractionLev el 0..1 +ownedPerspective<br />
Perspectiv e<br />
+successor 0..1<br />
0..*<br />
+abstractionLevel 0..*<br />
0..* +perspective<br />
+declared<br />
ReusableElement<br />
0..*<br />
+ kind: PerspectiveKind<br />
AbstractionLev elCategory<br />
+category 0..1<br />
Figure 3.1: Meta-model integration of the concept of abstraction levels<br />
A design item (e. g. the system under development or a component) may be modeled on<br />
different levels of abstraction. An ordering relation on the abstraction levels within a model<br />
is defined by means of the successor-association between AbstractionLevels (see<br />
Figure 3.1). The highest abstraction level associated by the SystemModel in the role of<br />
topLevel is intended to contain the most abstract description. Each AbstractionLevel<br />
owns a set of Perspectives, that in turn contain models and requirements.<br />
An abstraction level may be further categorized by AbstractionLevelCategory,<br />
which allows to adapt the concept to development processes of a company. So for an abstraction<br />
level of a certain category one can e. g. specify the set of considered perspectives.<br />
The component hierarchy modelled within a certain abstraction level may be re-arranged<br />
within the next lower abstraction level. Thus, a component-based architecture can not only be<br />
15/ 156
<strong>Architecture</strong> <strong>Modeling</strong><br />
refined by decomposition of components (see Section 3.3.2.2), but also by means of a different<br />
component hierarchy. So refinement subsumes but is not restricted to simple decomposition of<br />
components. When switching abstraction levels the component-models must be related to each<br />
other. This is done by Realize-trace links (shown in Figure 3.2), that constitute a mapping<br />
relation between component instance roles of different abstraction levels. Due to its similarity<br />
to Allocate-trace links, the superordinate concept of Mapping has been defined, that is<br />
discussed in Section 3.4.<br />
+type 1<br />
RichComponent<br />
+component 1<br />
«isOfT ype»<br />
+part 0..*<br />
+m appedT o<br />
RichComponentProperty<br />
1 «instanceRef»<br />
+m apped<br />
1<br />
«instanceRef»<br />
Allocate<br />
Mapping<br />
Realize<br />
Figure 3.2: Meta-model integration of the concept of Realize-trace links<br />
While the models on lower abstraction levels usually provide more detail with regard to the<br />
design item, the respective models still have to satisfy all functional and non-functional requirements<br />
defined for their higher level counterparts with respect to a continuous development<br />
process. The Realize-link provided by the meta-model also indicates the proof obligations,<br />
that have to be performed to ensure a valid refinement with regard to the specified contracts.<br />
The realize relation is discussed detailed in Section 4.4.<br />
Since the design processes for different application domains like automotive and avionics are<br />
very diverse, a fixed set of predefined abstraction levels has found to be insufficient to support<br />
different domains. The EAST-ADL abstraction levels for example are just one possible instantiation<br />
of the generic abstraction level concept. In other application domains, e. g. avionics, or<br />
even for different companies in the same domain, the set of actually used concrete abstraction<br />
levels may be different. The meta-model provides concepts for tailoring models to specific<br />
needs. This allows to define so-called model libraries that provide predefined sets of abtraction<br />
levels, such as those defined in EAST-ADL. The underlying formal semantics of the Realizelink<br />
then allows the verfication of refinements of component-models.<br />
3.2 Perspectives<br />
Beside the distinction of different user-defined abstraction levels, a model of a system under development<br />
may be associated with certain viewpoints, such as defined in [33]. The architecture<br />
meta-model differentiates between viewpoints that establish structurally different views on the<br />
system (perspectives), and viewpoints, that are orthogonal to the structure of the system and describe<br />
different aspects of functional and/or non-functional properties of model elements. The<br />
concept of aspects is discussed in Section 3.3.1.2.<br />
So models of a system addressing a certain perspective will specify the structure of the system<br />
from that particular perspective. This results in a two-dimensional organization of component<br />
16/ 156
Abstraction-Levels<br />
(detail increases)<br />
Operational<br />
Perspective<br />
<strong>Architecture</strong> <strong>Modeling</strong><br />
Allocate<br />
Functional<br />
Perspective<br />
Allocate<br />
Allocate<br />
Logical<br />
Perspective<br />
Realize<br />
Technical<br />
Perspective<br />
Realize<br />
Geometrical<br />
Perspective<br />
Figure 3.3: Matrix of abstraction levels and perspectives<br />
models according to abstraction levels and perspectives like in Figure 3.3. We identified five<br />
specific perspectives which are currently supported by the architecture meta-model: The operational<br />
perspective, the functional perspective, the logical perspective, the technical perspective,<br />
and the geometrical perspective.<br />
+subPackage<br />
Package<br />
SystemModel<br />
+owner 0..1<br />
1..*<br />
+owner<br />
0..1<br />
0..*<br />
+abstractionLevel<br />
DeclarationZone<br />
1 +topLevel<br />
+declarationZone<br />
0..1<br />
+owner<br />
Perspectiv eKind<br />
operational<br />
functional<br />
logical<br />
technical<br />
geometric<br />
+declared<br />
ReusableElement<br />
AbstractionLev el 0..1 +ownedPerspective<br />
Perspectiv e<br />
+successor 0..1<br />
0..*<br />
+abstractionLevel 0..*<br />
0..*<br />
+perspective<br />
0..*<br />
SystemArtefact<br />
+root 0..1<br />
+ kind: PerspectiveKind<br />
Figure 3.4: Meta-model integration of the concept of Perspectives<br />
The combination of the perspectives at a certain abstraction level provides a specification of<br />
the whole architecture at the given level of detail. The entities and their interfaces defined in<br />
different perspectives do not need to be compatible to each other. For example, three interacting<br />
functions defined at the functional perspective may be modelled as two logical components. Elements<br />
of one perspective however can be allocated to elements of another perspective (cf. Section<br />
4.4). Du to its similarity to Realize-trace links, the superordinate concept of Mapping<br />
has been defined, that is discussed in Section 3.4. A function for example, that is defined in<br />
the functional perspective, may be allocated to a logical component, which itself may be allocated<br />
to a hardware resource defined in the technical perspective. The meta-model provides a<br />
formal definition of Allocate-links, allowing to define simulation relations between linked<br />
elements, and to reason about consistency of the system design among different perspectives.<br />
17/ 156
<strong>Architecture</strong> <strong>Modeling</strong><br />
Depending on the system under development and on the respective development process,<br />
the palette of actually used perspectives and elements may be different for each abstraction<br />
level. In early design stages for example, when the functions of the system are to be defined,<br />
the target platform (modelled in the technical perspective later on) might not be of interest.<br />
This is reflected in the meta-model by allowing to aggregate the set of Perspectives from<br />
an AbstractionLevel, that is considered relevant in that specific abstraction level (see<br />
Figure 3.4).<br />
3.2.1 Operational Perspective<br />
Models of the operational perspective express the operational capabilities and activities that<br />
are expected by the users and customers from the actors and their operational interaction. The<br />
purpose is to identify the customer needs as one of the first steps towards a conrete functional<br />
system design that fulfills these needs. This can be achieved by identifying actors and the<br />
activities being intended to be performed. Scenarios describe the interaction between the actors<br />
and their performed activities. This first analysis of system scenarios helps in determining the<br />
functional needs of the system in subsequent design steps.<br />
OperationalActor<br />
RichComponent<br />
Requirement<br />
+ rationale: String [0..*]<br />
OperationalActiv ity SystemRequirement<br />
+aspect<br />
SystemArtefact Aspect<br />
0..*<br />
+stakeholder<br />
0..*<br />
Stakeholder<br />
Figure 3.5: Meta-model integration of the concepts for specifying the operational perspective<br />
Figure 3.5 depicts the concepts of the meta-model for specifying the operational perspective.<br />
As a first step to capture operational functionality the meta-model specification concept<br />
of OperationalActivity can be used to model an operational activity. Being specialized<br />
RichComponents their dynamics can be abstracted by means of contracts. The concept of<br />
contracts is named SystemRequirement in the meta-model for reasons explained in Section<br />
3.3.1.3. Actors that perform these activities can be modeled as OperationalActors<br />
taking part in the scenario. Since in the beginning of the design process the concrete system<br />
under design and its boundary are unknown in later refinement steps these actors of a scenario<br />
performing operational activities can be realized by the system under design and its environment.<br />
In [35] an approach to model-based requirements engineering is proposed, which includes<br />
a process description how system scenarios can be derived from system goals. Note that the<br />
concept of goals proposed in that approach is not part of the current version of the architecture<br />
meta-model. However they may eventually be referenced by the rationale attribute of the<br />
Requirement concept.<br />
18/ 156
3.2.2 Functional Perspective<br />
<strong>Architecture</strong> <strong>Modeling</strong><br />
<strong>Modeling</strong> the functional perspective of the system serves identifying the functional needs of the<br />
system. Derived from an analysis of the operational context of the system in the Operational<br />
Perspective, its behavior is specified from a user-centric point of view, establishing a blackboxview<br />
of the functions of the system. Subsequently these top-level functions are refined by<br />
sub-functions that together realize the top-level system functionality. Ideally, functions are<br />
completely independent of any architecture.<br />
Elements of an operational model defined at the same or a higher abstraction level can be<br />
allocated on the defined functions. This way, the contribution of a function to an activity of<br />
an actor can be explicated, which allows to investigate whether each activity is supported by<br />
system-functions, and whether the design goals can be accomplished.<br />
+part 0..*<br />
RichComponentProperty<br />
+component 1<br />
+type<br />
«isOfT ype» 1<br />
RichComponent<br />
Function<br />
+aspect<br />
SystemArtefact Aspect<br />
Requirement<br />
+ rationale: String [0..*]<br />
SystemRequirement<br />
0..*<br />
+stakeholder<br />
0..*<br />
Stakeholder<br />
Figure 3.6: Meta-model integration of the concepts for specifying the functional perspective<br />
The architecture meta-model provides the concept of a Function (see Figure 3.6) to model<br />
functions of the system. Function is a specialized RichComponent and thus can have<br />
behavior. Inputs and outputs of a function are represented by ports. Functional as well as<br />
non-functional specifications are defined and assigned to the modelled functions by means of<br />
SystemRequirements (contracts).<br />
3.2.3 Logical Perspective<br />
The logical perspective constitutes the decomposition of a system into reusable components<br />
and specifies their interaction. Additionally, the environment is modelled with respect to the<br />
interfaces of the system, which includes both syntactical interfaces and behavioral interaction.<br />
That way, the logical parts of the system and their relationships are identified. Technical aspects<br />
and choices of any technology are typically not considered in the logical perspective. The<br />
logical perspective is the entry to the design of the system. Functions modelled within the<br />
functional perspective can be spread across the defined logical components.<br />
Logical components of a system are modelled by the architecture meta-model concept<br />
LogicalComponent (see Figure 3.7). LogicalComponent is a specialized<br />
RichComponent, and thus can have behavior. Ports typed by PortSpecifications<br />
specify the interaction points of the component. Functional as well as non-functional requirements<br />
can be formulated as SystemRequirements. A LogicalComponent can<br />
be instantiated in a given context of other component instantiations by using the concept<br />
RichComponentProperty. The behavior of the component instance is determined by its<br />
type.<br />
The concepts EnvironmentComponent models a component of the environment interacting<br />
with the System. Conceptionally an actor is also part of the environment.<br />
19/ 156
PortSpecification<br />
+part 0..*<br />
Env ironmentComponent<br />
+type<br />
RichComponentProperty<br />
1<br />
«isOfT ype»<br />
+component<br />
System<br />
+type<br />
«isOfT ype» 1<br />
<strong>Architecture</strong> <strong>Modeling</strong><br />
Port<br />
+ isConjugated: Boolean<br />
1<br />
+port 0..*<br />
+component<br />
1<br />
RichComponent<br />
LogicalComponent<br />
+aspect<br />
SystemArtefact Aspect<br />
Requirement<br />
+ rationale: String [0..*]<br />
SystemRequirement<br />
0..*<br />
+stakeholder<br />
0..*<br />
Stakeholder<br />
Figure 3.7: Meta-model integration of the concepts for specifying the logical perspective<br />
Activities and their performing actors of the operational perspective can be allocated to<br />
EnvironmentComponents. This allows to refine the behavior at the interfaces of the system.<br />
The concept System denotes a component, that defines the system boundaries. Thus,<br />
such a component should exist at most once per abstraction level. If a System is used as<br />
part in the context of another LogicalComponent, then the other parts should be typed by<br />
EnvironmentComponents.<br />
Allocating LogicalComponents to elements of a technical perspective realizes a<br />
software-hardware partitioning and describes how an underlying platform executes the<br />
LogicalComponents. However this does not mean that a designer cannot express that<br />
partitioning in advance in a logical perspective. For example considering AUTOSAR [9] an<br />
application is modeled as a composition of interconnected software components. On the design<br />
entry in AUTOSAR these software components are connected by means of a so called Virtual<br />
Functional Bus that abstracts from system topology, available resources (e. g. electronic control<br />
units) and communication media. Thus, in scenarios where software-hardware partitioning<br />
shall be decided but the allocation to platform resources is left open, one may explicitly model<br />
software- as well as hardware-specific components in the logical perspective.<br />
3.2.3.1 Communication Refinement<br />
The logical perspective of the system is not concerned with the specification of properties of the<br />
target platform hosting the logical component architecture. Especially it is also not decided how<br />
the logical components are deployed. However a logical perspective of a system has to take into<br />
account, that the communication between components will later on be mapped to a distributed<br />
communication infrastructure (like e. g. a CAN-Bus or AFDX) or to a communication local to<br />
a computing node.<br />
LogicalComponent<br />
part1:Controller part2:Actuator<br />
...<br />
p1 p2<br />
com:Comm<br />
Comm<br />
C3<br />
Figure 3.8: Enabling logical communication refinement in the logical perspective<br />
...<br />
20/ 156
<strong>Architecture</strong> <strong>Modeling</strong><br />
The semantics of HRC is defined such that behavior is always part of a RichComponent or<br />
specializations thereof. The connection of ports (syntactically described in Section 3.3.2.2) is<br />
semantically interpreted as the identity of the behavior observable at the connected ports. So if<br />
in the example sketched in Figure 3.8 the ports p1 and p2 would have been directly connected,<br />
then any event or data occuring at port p1 is at the same time observed at port p2. Thus, in<br />
order to be able to specify assumptions about communication latencies from a real-time aspect,<br />
one needs at least conceptionally a LogicalComponent. For that component contracts can<br />
again be used for the specification of the different aspects of the logical communication, e. g.<br />
expected latencies or failure hypothesis. Though conceptionally logical communcation has to<br />
be represented as a RichComponent, the user-representation can be different. For example<br />
a UML-profile based on the architecture meta-model, can introduce a stereotype, which is<br />
applicable to uml::Connector and is mapped to the concept of LogicalComponent.<br />
3.2.4 Technical Perspective<br />
In the technical perspective the electric/electronic architecture of the system is specified, which<br />
comprises mechanical and hydraulic components controlled by a network of control units, that<br />
the logical components shall be allocated to. The electronic control units may be softwareprogrammable<br />
hardware components or application specific integrated circuits (ASICs). Mechanical<br />
components are for example cams, shafts, switches and relays. Hydraulic components<br />
include for example valves and cylinders.<br />
The concepts provided for describing a view corresponding to the technical perspective are<br />
more specialized than those provided for modeling an operational, functional or logical perspective.<br />
That is because it is intended to apply dedicated analysis techniques for checking<br />
satisfaction of contracts (cf. Section 4.3) based on models of the technical perspective. In Section<br />
5.1.3.5 an example is presented how the concepts described in this section can be used to<br />
model a technical view.<br />
+part 0..*<br />
RichComponentProperty<br />
«isOfType»<br />
+component 1<br />
+type<br />
1<br />
RichComponent<br />
TechnicalComponent<br />
+aspect<br />
SystemArtefact Aspect<br />
Requirement<br />
+ rationale: String [0..*]<br />
SystemRequirement<br />
0..*<br />
+stakeholder<br />
0..*<br />
Stakeholder<br />
Figure 3.9: Meta-model integration of the concepts of TechnicalComponents<br />
The architecture meta-model provides concepts to specify the technical perspective of a system<br />
by means of TechnicalComponents (see Figure 3.9). While we do not provide specialized<br />
concepts in the meta-model for mechanical or hydraulic components, their aspects however<br />
can still be specified by means of contracts. That allows a characterization of their dynamics<br />
and to assess whether requirements on functions are fulfilled by the mechanical or hydraulic<br />
components and the electronic components controlling them.<br />
In <strong>SPES</strong> the focus is on software-intensive systems. Therefore the meta-model incorporates<br />
specialized concepts to describe the resources of a network of electronic control units, which<br />
21/ 156
<strong>Architecture</strong> <strong>Modeling</strong><br />
allows to model execution platforms hosting the components of the logical perspective. Here<br />
resource limitations come into play, e. g. the sharing of computing resources by multiple logical<br />
components. The behavior of the allocated logical components will therefore depend on the<br />
properties of the resource as well as the other logical components allocated to the very same<br />
resource.<br />
3.2.4.1 Resources<br />
The concepts of the metamodel for specifying the technical perspective of a system are inspired<br />
by the UML Profile for MARTE (<strong>Modeling</strong> and Analysis of Real-Time Embedded Systems)<br />
[40].<br />
RichComponent<br />
Resource<br />
+ isActive: Boolean<br />
+ isProtected: Boolean<br />
+ resMult: int [0..1] = 1<br />
StorageResource<br />
+elem entSize 1<br />
ConcurrencyResource ProcessingResource<br />
SchedulerSlot<br />
+ isPreemptible: Boolean = true<br />
Dev iceResource ComputingResource CommunicationResource<br />
+ transmMode: T ransm ModeKind<br />
+packetT ime<br />
1<br />
Expression<br />
+elementSize<br />
1<br />
+blockingT ime<br />
1<br />
Scheduler<br />
+ isPreemptible: Boolean = true<br />
+capacity<br />
1<br />
+schedule<br />
1<br />
TextuallyRepresentedElement<br />
Figure 3.10: Meta-model integration of the concepts of Resources<br />
The concept Resource shown in Figure 3.10 constitute an abstraction of the resources a<br />
platform provides and allocated behaviour from logical components. Examples for resource<br />
are:<br />
• computational resources, i. e. the computational power of some processor<br />
• bandwidth of a communication resource<br />
• storage capacity of a storage resource<br />
As some of those resources might be shared by multiple consumers, this sharing of resources<br />
can be explicated by means of schedulers. Such a scheduler distributes fractions of a resource<br />
according to a given scheduling strategy. The concept Scheduler allows for modelling static<br />
as well as dynamic scheduler types.<br />
Schedulers: The concept Scheduler depicted in Figure 3.11 distributes fractions of a resource<br />
according to a given strategy. The clients of a scheduler are modeled by the concept<br />
SchedulerSlot. The Resource, whose capacity is shared and assigned by a scheduler is<br />
22/ 156
<strong>Architecture</strong> <strong>Modeling</strong><br />
expressed by the concept ProcessingResource. The SchedulingPolicy concept allows<br />
to specify the strategy of the scheduler, e. g. fixed-priority based. The SchedulerSlots,<br />
which receive a fraction of the resource, aggregate the concept SchedParameterSpec, that<br />
specifies parameters used by a scheduler to run its strategy. Such parameters are for example<br />
the definition of a priority.<br />
RichComponent<br />
Resource<br />
+ isActive: Boolean<br />
+ isProtected: Boolean<br />
+ resMult: int [0..1] = 1<br />
+required<br />
SchedulerPort<br />
SchedulerRPort +required<br />
ConcurrencyResource ProcessingResource SchedulerSlot<br />
0..*<br />
+ isPreem ptible: Boolean = true<br />
Variable<br />
SchedParameterSpec<br />
+provided<br />
SchedulerPort<br />
SchedulerPPort +provided<br />
0..1<br />
+required 1<br />
+provided 0..*<br />
0..*<br />
+schedParameters 1<br />
1..*<br />
Scheduler<br />
+ isPreemptible: Boolean = true<br />
+policy 1<br />
+schedule<br />
1<br />
TextuallyRepresentedElement<br />
Expression<br />
+scheduleLength 0..1<br />
SchedulingPolicy<br />
+ otherSchedPolicy: String [0..1]<br />
+ policy: SchedPolicyKind = FixedPriority<br />
Figure 3.11: Meta-model integration of the concept Scheduler<br />
The concept, which actually uses the fraction of the ProcessingResource, is a<br />
ConcurrencyResource or specializations thereof. If some schedule was determined offline,<br />
it can be directly specified by means of an Expression in the role schedule. This<br />
overrides whatever was specified in the SchedulingPolicy.<br />
The relation of the concepts Scheduler, SchedulerSlot and<br />
ConcurrencyResource is modeled by the special ports SchedulerPPort and<br />
SchedulerRPort. That ports must be typed by a PortSpecification, which is<br />
conformant to the concept SchedulerPortSpec (see Figure 3.12). This specification<br />
comprises five flows, that are referenced in the following roles:<br />
activateEvent is a flow of kind event. The direction is always in. This event<br />
denotes the request for the activation of a ConcurrencyResource. The<br />
ConcurrencyResource thus notifies its need to access the capacity of a<br />
ProcessingResource.<br />
startEvent is a flow of kind event. The direction is always out. This event denotes the grant<br />
of some Scheduler upon a previously received request (the activateEvent).<br />
finEvent is a flow of kind event. The direction is always in. This event denotes the release<br />
of the capacity of the ProcessingResource by the ConcurrencyResource. It<br />
is triggered, when the ConcurrencyResource has finished its computation or communication.<br />
suspendEvent is a flow of kind event. The direction is always out. The referenced flow<br />
shall be triggered by some Scheduler or forwarded by some SchedulerSlot, when<br />
access to the processing capacities of a scheduled resource has been granted before, but<br />
shall now be revoked in favour of another SchedulerSlot. This reference to a flow is<br />
only needed, if preemption can occur.<br />
23/ 156
<strong>Architecture</strong> <strong>Modeling</strong><br />
resumeEvent is a flow of kind event. The direction is always out. The referenced flow shall<br />
be triggered by some Scheduler or forwarded by some SchedulerSlot, when access<br />
to the processing capacities of a scheduled resource has been granted and suspended<br />
before and now access to the ProcessingResource is granted again. This reference<br />
to a flow is only needed, if preemption can occur.<br />
Port<br />
+ isConjugated: Boolean<br />
SchedulerPort<br />
1<br />
{redefines<br />
type} +type<br />
SchedulerPortSpec<br />
«isOfT ype»<br />
SchedulerPPort SchedulerRPort<br />
+activateEvent 1<br />
«isOfT ype»<br />
+ direction: FlowDirection<br />
+ kind: FlowKind<br />
PortSpecification<br />
+finEvent 1 +startEvent 1 +resumeEvent 0..1 +suspendEvent 0..1<br />
Figure 3.12: Meta-model integration of the concept SchedulerPort<br />
+type<br />
1<br />
Flow<br />
+comSpec<br />
+schedulerEvent 3..5<br />
In a model the scheduling of a ProcessingResource will look like depicted in Figure<br />
3.13. The ports marked in red color are SchedulerPorts. The figure also shows how to<br />
make use of the Scheduler and SchedulerSlot concepts when modeling the hierarchical<br />
scheduling of a ProcessingResource. A SchedulerSlot can also serve a second<br />
Scheduler, which then only distributes the capacity of the ProcessingResource to its<br />
clients that it receives through its underlying slot by the main scheduler.<br />
ProcessingResource<br />
:Concurrency<br />
Resource<br />
:Concurrency<br />
Resource<br />
:SchedulerSlot :SchedulerSlot<br />
:Scheduler<br />
:SchedulerSlot<br />
:Scheduler<br />
:Concurrency<br />
Resource<br />
:SchedulerSlot<br />
Figure 3.13: Example of using the Scheduler concept<br />
ComputingResources: The concept ComputingResource shown in Figure 3.14<br />
models a processing device capable of storing and executing Tasks. This concept is an abstraction<br />
of elements of an execution platform hosting multiple tasks, which require computing capacity<br />
in order to carry out their computations. Being derived from ProcessingResource<br />
a ComputingResource may be subject to scheduling of its computing capacity.<br />
The Task concept models a computation task. As it is derived from<br />
ConcurrencyResource, it can be connected to a SchedulerSlot, thus using the<br />
24/ 156
<strong>Architecture</strong> <strong>Modeling</strong><br />
computing capacity the SchedulerSlot receives from a Scheduler. In the role<br />
executionTime a Task can aggregate multiple declarations of its execution time,<br />
that has been measured/analysed. Provided a task would have exclusive access to a<br />
ComputingResource the execution time is the time from starting the task until it finishes.<br />
As the execution time may vary depending on the kind of the computing device, one can<br />
specify multiple execution times, each with a unique identifier. An example specification of an<br />
execution time, would be: {ARM7;500us;1ms}. Where 500us is the best base execution time<br />
and 1ms is the worst case execution time.<br />
RichComponent<br />
Resource<br />
+ isActive: Boolean<br />
+ isProtected: Boolean<br />
+ resMult: int [0..1] = 1<br />
Task<br />
ConcurrencyResource ProcessingResource SchedulerSlot<br />
+executionT ime<br />
SchedulerPort<br />
SchedulerRPort<br />
0..* +required<br />
0..*<br />
Constant<br />
ExecutionTimeSpec<br />
ComputingResource<br />
SchedulerPort<br />
SchedulerPPort<br />
+provided 0..*<br />
+ isPreemptible: Boolean = true<br />
Figure 3.14: Meta-model integration of the concept ComputingResource<br />
CommunicationResources: The concept CommunicationResource shown in Figure<br />
3.15 models an abstraction of a communication device of an execution platform<br />
capable of transferring information from one location to another. The attributes of<br />
CommunicationResource are used to describe its most relevant properties needed for<br />
timing analysis of a technical architecture. Being derived from ProcessingResource a<br />
CommunicationResource may be subject to scheduling of its communication capacity.<br />
A frame is a data item, which is transmitted by a CommunicationResource. The concept<br />
FrameTriggering models the triggering and identification of a frame transmitted by<br />
a CommunicationResource. As the concept is derived from ConcurrencyResource,<br />
it can be connected to a SchedulerSlot, thus using the communication capacity the<br />
SchedulerSlot receives from a Scheduler.<br />
SchedulerPort +required<br />
SchedulerRPort 0..*<br />
ConcurrencyResource<br />
FrameTriggering<br />
Resource<br />
Resource<br />
ProcessingResource<br />
+ transmMode: T ransmModeKind<br />
CommunicationResource<br />
SchedulerSlot<br />
Resource<br />
+ isPreemptible: Boolean = true<br />
+provided<br />
SchedulerPort<br />
0..* SchedulerPPort<br />
Figure 3.15: Meta-model integration of the concept CommunicationResource<br />
Describing data encapsulation in communication stacks: We consider the technical<br />
architecture as a network of ComputingResources, that are interconnected by<br />
means of CommunicationResources. The frames, that are transmitted by that<br />
CommunicationResources are however not the data items, that would be sent directly<br />
by some application task. Instead in most execution platforms an application programming<br />
25/ 156
ReusableElement<br />
ComData<br />
+com Data 1<br />
+referencedPorts<br />
0..*<br />
PortReference<br />
Signal<br />
+ length: int<br />
Message<br />
+ length: int<br />
Frame<br />
+ length: int<br />
<strong>Architecture</strong> <strong>Modeling</strong><br />
+signal<br />
1<br />
+owner +signalT oMsgMapping<br />
+message<br />
1<br />
+owner +msgT oFrameM apping<br />
NamedElement<br />
MsgToFrameMapping<br />
0..*<br />
+ offsetInFrame: int<br />
0..*<br />
«enumeration»<br />
TransferPropertyKind<br />
«enum eration»<br />
triggered<br />
pending<br />
triggeredOnChange<br />
SignalToMsgM apping<br />
NamedElement<br />
+ offsetInMessage: int<br />
+ transferProperty: T ransferPropertyKind<br />
Figure 3.16: Meta-model integration of the concepts for modeling data encapsulation<br />
interface (API) is provided, that hides the complexity of different bus technologies and communication<br />
protocols. Data sent by some application task is then processed by a communication<br />
stack, which is typically organized in layers like in the Open Systems Interconnection model<br />
(OSI) [51].<br />
Beside the wish to abstract from the details of a layer of communication protocols from the<br />
logical perspective of the system, in the technical perspective one needs a specification of e. g.<br />
their real-time aspects or safety aspects. This allows to reason about whether requirements on<br />
the communication of components in the logical perspective can be fulfilled when allocating<br />
them to a technical architecture. Figure 3.16 shows the concepts of the meta-model, which<br />
allow to capture the data encapsulations done by a communication stack and Figure 3.17 shows<br />
their intended usage. For the sake of brevity the SchedulerSlots and a Scheduler are<br />
not shown in that figure.<br />
ComputingResource<br />
header<br />
header<br />
app-task1:Task<br />
app-task2:Task<br />
Signal1<br />
com:Task<br />
Signal2<br />
Signal1 Signal2<br />
payload<br />
Message1 Frame1<br />
Message1<br />
payload Frame1<br />
bus-drv:Task<br />
Figure 3.17: Example for specifying the data enscapsulation<br />
The Signal concept represents data sent by some application tasks, which components<br />
from the logical perspective have been allocated to. The declared Signal references Ports<br />
in the technical architecture model to indicate at which ports it is sent or received. The concepts<br />
Message and Frame also allow to reference multiple Ports. The data encapsulation by a<br />
communication stack as sketched in the bottom half of Figure 3.17 is expressed by the concepts<br />
SignalToMsgMapping and MsgToFrameMapping. They allow to describe the composition<br />
of messages in frames and of signals in messages. The condition when a Task, which is<br />
responsible for the encapsulation of Signals in Messages, actually triggers the Message<br />
can be defined by the attributes of the concept SignalToMsgMapping. For example some<br />
Signals mapped to the same Message may cause it to be triggered, while others just update<br />
the value inside the Message.<br />
26/ 156
3.2.5 Geometrical Perspective<br />
<strong>Architecture</strong> <strong>Modeling</strong><br />
The geometrical perspective constitues the geometric installation of a technical system under<br />
design and its geometric context. A geometric model can be based on CAD models like from<br />
CATIA or AUTOCAD. The following description is a first draft of possible modeling concepts<br />
for a geometric perspective. Two use cases motivate their usage in architecture modeling for<br />
the optimization of cable lengths based on function allocation constraints and for the analysis<br />
of particular risks.<br />
Geometric Components Figure 3.18 provides an overview on the concepts for the description<br />
of geometric components, their parts and failure conditions.<br />
FailureCondition<br />
GeometricFailure<br />
+geometricFailure 0..1<br />
+shapeProperty 0..1<br />
ShapeProperty<br />
+failureCondition<br />
0..*<br />
«isOfType»<br />
+type<br />
1<br />
+shape 0..1<br />
Shape<br />
+component<br />
+relatedComponent<br />
0..*<br />
GeometricLocationType<br />
1<br />
RichComponent<br />
GeometricComponent<br />
+zone 0..*<br />
GeometricZone<br />
+type<br />
+location 1..*<br />
1<br />
GeometricLocation<br />
+translation GeometricTranslation<br />
+translation<br />
0..1<br />
+scaling<br />
0..1<br />
+rotation<br />
0..1<br />
+location 0..*<br />
+translation 1<br />
2<br />
GeometricScaling<br />
GeometricRotation<br />
+type<br />
1<br />
1<br />
+location<br />
0..1<br />
+component<br />
+rotation<br />
0..1<br />
GeometricLocationLink<br />
+location<br />
1<br />
+scaling<br />
1<br />
+scaling<br />
0..1<br />
+locationLink 0..*<br />
«isOfType»<br />
+route<br />
1..*<br />
{ordered}<br />
Figure 3.18: Concepts of the geometrical perspective.<br />
RoutedInstallation<br />
RichComponentProperty<br />
+part<br />
0..*<br />
GeometricInstallation<br />
LocationInstallation<br />
Geometric Components are specialized Rich Components. They define an own reference<br />
system for all contained structures. As an example we consider the geometric structure of a car.<br />
A geometric component declares Geometric Locations. These are positions within a geometric<br />
component which can be used for installations. A geometric location type defines which geometric<br />
components may be installed at a specific location. The position of a geometric location<br />
is defined by its translation reletive to the reference system of the owning geometric component.<br />
Geometric location links define an existing link between two locations which can be used for<br />
routed installations. Since the lengteh of a link between two locations does not neccessarily<br />
mean their euclidean distance and a link can have a width and a height this information is given<br />
by a scaling. A geometric zone groups geometric locations to a zone within a geometric component.<br />
I.e. inside a car there are different locations which can be used for technical installations<br />
such as sensors, constrollers or cables. There are links in terms of channels between these locations<br />
which can be used to lay cables. Furthermore the car can be sectioned into different<br />
27/ 156
<strong>Architecture</strong> <strong>Modeling</strong><br />
zones such as cargo bay or engine bay. In order to describe the external structure of a geometric<br />
component there can be a shape.<br />
Geometric component installations are specialized rich component properties. Having the<br />
role of rich component parts they are instances of geometrical components and therefore typed<br />
by them. Instantiated technical components can be allocated to these installations. I.e. a technical<br />
ECU of a car is allocated to an installation of a representing geometrical component. Geometric<br />
installations can be location installations or routed installations. A location installation<br />
refers to a defined location of the containing geometric component. The location installation<br />
specifies that a geometric component of its type is installed to that location and therefore to the<br />
position which is specified by the translation releative to the reference system of the containg<br />
geometric component. I.e. an acceleration sensor is installed to a location x = 0m, y=-20cm and<br />
z=1,2m relative to the middle of the car. Routed installations declare a route for a geometric<br />
component along several component links. They are used for layable components like cables or<br />
pipes. I.e. in the car the mentioned acceleration sensor is connected to an ECU in the cargo bay<br />
by a cable component that is layed via several locations with a total length of 3 m.<br />
Geometric failures are specialized failure conditions. They describe failure conditions which<br />
have effects on geometric structures. Therefore, a geometric failure can have a shape property<br />
which describes the sphere of effect that a geometric failure has. I.e. the battery of a car can<br />
explode and damage other components inside a sphere with a radius of 20 cm.<br />
Geometric Coordinates Figure 3.19 provides an overview on concepts to describe geometric<br />
coordinates.<br />
GeometricScaling<br />
+length 0..1 +width 0..1 +height 0..1 +x 0..1<br />
GeometricTranslation<br />
+y 0..1<br />
Expression<br />
+z 0..1+roll<br />
0..1<br />
GeometricRotation<br />
+pitch 0..1<br />
+yaw 0..1<br />
Figure 3.19: Concepts of the geometrical perspective to cover coordinates.<br />
Geometric coordinates are relative to the respective reference system. They are given by<br />
geometric scaling, geometric, translation and geometric rotation.<br />
Geometric Shapes Figure 3.20 provides an overview on concepts to describe geometric<br />
shapes.<br />
Geometric shapes describe the shape of a geometric component or the sphere of effect of a<br />
geometric failure. They can be primitive shapes such as spheres, cylinders or cuboids. A sphere<br />
is defined by its radius, a cylinder is defined by its radius and its length and a cuboid is defined<br />
by its length, its width and by its height. A shape can be a mesh. A mesh is a user defined shape<br />
which consists of vertices and edges. The position of a vertex is given by a translation relativ<br />
to its reference system. Edges connect vertices. A complex shape is defined by a composite<br />
shape. A composite shape consists of shape properties as operands respectively typed by shapes.<br />
A shape composition operator defines how the operands together provide a shape. The shape<br />
operators are defined as follows:<br />
28/ 156
ShapeCompositionOperator<br />
intersection<br />
union<br />
difference<br />
Shape<br />
Sphere Cylinder Cuboid<br />
+radius 1 +radius 1 +length 1 +length 1 +width 1 +height 1<br />
Expression<br />
<strong>Architecture</strong> <strong>Modeling</strong><br />
+type<br />
1<br />
Mesh<br />
+edge 0..*<br />
Edge<br />
«isOfType»<br />
CompositeShape<br />
Vertex<br />
ShapeProperty<br />
+ operator: ShapeCompositionOperator<br />
+compositeShape<br />
+vertex<br />
1..*<br />
+vertex<br />
2<br />
+operand 2..*<br />
+scaling<br />
0..1<br />
+rotation<br />
0..1<br />
+translation<br />
Figure 3.20: Concepts of the geometrical perspective to cover shapes.<br />
intersection The composed shape is given by the intersection of the operands.<br />
intersection The composed shape is given by the union of the operands.<br />
0..1<br />
0..1<br />
GeometricScaling<br />
GeometricRotation<br />
GeometricTranslation<br />
+position 1<br />
difference The composed shape is given by the difference between the first and the second<br />
operand. For this operator ony two operands may be given.<br />
3.2.5.1 Optimizing Cable lengths based on function allocation constraints<br />
The different perspectives have already been introduced in this document. Now a use case shall<br />
demonstrate how the perspectives get used in a real life example from the automotive domain<br />
and how transformations between them are performed.<br />
The use case arises from the idea to split the airbag system up on to existing general purpose<br />
ECUs. To avoid having very high safety integrity levels for the ECUs the functions of the airbag<br />
system have to be deployed redundantly. To allow an ASIL (Automotive Safety Integrity Level)<br />
reduction, the independence of the functions have to be ensured. This especially means that<br />
the redundant function must not be deployed on the same ECU. The Airbag system consists<br />
out of 4 ECUs, in this simplified example, that are distributed across the ego vehicle and a set<br />
of pressure and acceleration sensors. Each logical airbag system part requires a known set of<br />
sensors at known locations. If a function gets mapped to an ECU also the corresponding sensors<br />
need to be connected to the same ECU.<br />
The use case consists of the creation of the allocation of logical airbag systems to the ECUs<br />
by fulfilling the independence constraints on the one hand side and resource availability on<br />
the other side. The resources are given by the available interfaces on one ECU that limits the<br />
number and type of connectable sensors. Furthermore the length of the cable from the ECUs<br />
to the sensors shall be minimized to reduce the costs of the system. The use case is an excerpt<br />
from an automotive design process that deals only with the optimization problem of reducing<br />
the length of the cable that connect sensors and ECUs that are distributed across the vehicle<br />
and the different constraints that limit the abilities of solving the problem. The independence<br />
constraints are typically a result from different safety analyzes but are considered as given in<br />
this use case.<br />
The problem basically consists of combining three perspectives:<br />
• The logical perspective, where safety constraints for the elements are expressed<br />
29/ 156
LSI 1<br />
<strong>Architecture</strong> <strong>Modeling</strong><br />
• The hardware perspective in which the connections between the sensors and the computers<br />
have to be found<br />
• The geometrical perspective which gives the possibility to evaluate the result of connections<br />
by allowing to express distances and length for the cables<br />
Accel. Left<br />
Sensor<br />
Left Side<br />
Impact<br />
Logical Perspective Technical Perspective Geometrical Perspective<br />
Pressure Left<br />
Sensor<br />
Redundant<br />
Airbag System<br />
Right Side<br />
Impact<br />
Front<br />
Impact<br />
LSI 2 RSI 1 RSI 2 FI 1 FI 2<br />
… …<br />
<br />
Decomposition<br />
…<br />
Pressure Front<br />
Sensor<br />
Pressure Front<br />
Sensor<br />
Independence constraint<br />
Port<br />
ECU1<br />
Accel. Sensor<br />
Front Type<br />
ECU Type<br />
ASF1 ASF2 ASF3 ASF4<br />
Acceleration<br />
Sensor Type<br />
ECU2 ECU3 ECU4<br />
Accel. Sensor<br />
Left Type<br />
Sensor<br />
Type<br />
<br />
Inheritance<br />
Accel. Sensor<br />
Right …<br />
Pressure<br />
Sensor Type<br />
…<br />
Acceleration Sensor<br />
Pressure Sensor<br />
Figure 3.21: Airbagsystem on the different perspectives<br />
(x,y,z)<br />
(x,y,z)<br />
(x,y,z)<br />
(x,y,z)<br />
ECU<br />
Connection/Cable<br />
Figure 3.21 shows a schematic of the example system on these perspectives. All relations<br />
between the elements are only partially displayed.<br />
Logical Perspective The logical perspective contains the “Redundant Airbag System” as its<br />
root node, which is decomposed into the three individual systems for crash detection. Each of<br />
them shall detect a specific crash scenario. A frontal impact is recognized by the “Front Impact<br />
System” (FI) and left or right side impacts by the “Left Side Impact” (LSI) and the “Right Side<br />
Impact” (RSI) systems. Therefore each of the systems is connected to a set of pressure and<br />
acceleration sensors located on the specific side of the car. For redundancy each of the systems,<br />
together with the needed sensors, are duplicated.<br />
To ensure independence between duplicates, constraints are added to the systems. They<br />
restrict their mapping to ECUs in the technical perspective. Constraints are formalized using<br />
the pattern based RSL. For the LSI1 and LSI2 systems this constraint looks like:<br />
LSI1 and LSI2 shall not be mapped together on same ECU-Instance<br />
30/ 156
<strong>Architecture</strong> <strong>Modeling</strong><br />
The constraint consists of a constant phrase (denoted by the bold text) and a left and right<br />
side. On the left side a conjunction of elements from the logical perspective are named (here:<br />
LSI1 and LSI2). Their mapping is constraint with respect to the element(s) from the technical<br />
perspective on the right side of the pattern (here: ECU-Instance).<br />
Based on these constraints other constraints for the connected sensors of each system can<br />
be derived. To ensure independence of the duplicated systems, each of their sensors must not<br />
be shared between them. In our example sensors are assumed to be a exclusive resources, so<br />
sharing is not allowed and no additional independence constraints are needed.<br />
Technical Perspective On the technical perspective the airbag systems needs to be allocated<br />
to ECUs and sensors. In our example we have four ECUs available, which are all of the same<br />
type “ECU Type”. Each ECU instance has a series of ports with an incoming direction modeling<br />
the possibility to connect equipment to them.<br />
In the same way acceleration and pressure sensors are modeled. They have a base type (one<br />
for acceleration and one for pressure sensing) and ports with an outgoing direction.<br />
All ports are typed by a PortSpecification. Together with the direction information it is therefore<br />
known which components can be connected. Such a connection between an ECU and a<br />
sensor represents a cable in the airbag example. It is also possible to model the cable explicitly<br />
with a separate component, which allows to specify additional properties, but in our example<br />
the representation by connections is sufficient.<br />
The mapping between elements of the logical and technical perspective can be done by<br />
adding links to the model. This allocation can be used to formulate a mapping<br />
problem or a solution. By allocating a logical sensor element on a technical sensor type<br />
(e.g. “Acceleration Sensor Left Type”) the mapping problem to find a suitable sensor instance<br />
of this type is specified. Alternatively the allocation target can already be a instance in which<br />
case the allocation models a concrete mapping, i.e. a mapping solution.<br />
In our airbag system the sensor systems are mapped to the corresponding sensor type in the<br />
technical perspective. This way a problem space is created. Since two pressure and acceleration<br />
sensors are available on each side the optimal one depends on the allocation of the systems to<br />
the ECUs. Also the computational parts can be executed on any of the available ECUs. Thus<br />
the allocation of the LSI, RSI and FI systems to ECUs is an open mapping problem. A solution<br />
to such a problem must fulfill all needed sensor inputs of the subsystem and the independence<br />
constraints associated with the system. By connecting ports of sensors with ports of an ECU a<br />
cable is added to the system. To be able to calculate the resulting cable length the geometrical<br />
perspective is used.<br />
Geometrical Perspective The geometrical perspective is used to organize the information<br />
regarding the position of the ECUs, the positions of the Sensors and the distance between these<br />
elements. The distance is determined by the actual cabling in the car, i.e. that the distance is<br />
influenced by the physical environment of the vehicle. Some cable can be put through the roof<br />
of the vehicle directly while other cables have to be put through the vehicle chassis. This can<br />
lead to a very different cable length from two nearby sensors to an ECU a fact which underline<br />
the importance of the automation of the optimization process, since the obvious solutions are<br />
most probably not the optimal ones.<br />
Model Processing As stated above the allocation links between the logical and the technical<br />
perspective are capable of creating an allocation space. The geometrical perspective provides<br />
the information to evaluate the different possibilities to solve the allocation. Furthermore the<br />
31/ 156
<strong>Architecture</strong> <strong>Modeling</strong><br />
provided interfaces on the ECUs and the required interfaces on the sensors limit the solution<br />
space. This data can be transformed automatically to be used by solving algorithms for finding<br />
a solution. This solution is transferred back into the model itself to generate architecture out of<br />
requirements and physical constraints.<br />
In Addition to architecture generation this technique can also be used for design space exploration.<br />
For different existing alternatives the minimal existing cable length can be calculated<br />
and compared. This approach differs from the typical design space exploration techniques since<br />
the metric for comparing designs is not based on the design that has been created until the run<br />
of the test, but on the quality of the solution that is possible to be designed in the future, based<br />
on the design decisions already made.<br />
This use case demonstrated that the geometrical perspective can be used as a valuable input<br />
for architecture generation and design space exploration. Furthermore the close relations<br />
between perspectives were demonstrated.<br />
3.2.5.2 Identification of particular risks<br />
On the geometric perspective a particular risk analysis (PRA) can be performed in order to<br />
identify safety impacts of geometric installation decisions for a technical system under design.<br />
In the PRA failures that are external to the technical system are identified and analyzed in the<br />
geometric context of the system. The SAE-ARP 4761 defines particular risks as “events which<br />
are outside the system(s) concerned but which may violate event independence claims because<br />
they ’may influence several zones at the same time”’ According to EASA CS25 Book 2 subpart<br />
F particular risks are “those events or influences, which are outside the systems concerned. [...]<br />
Each risk should be the subject of a specific study to examine and document the simultaneous or<br />
cascading effects or influences, which may violate independence.” Therefore, these events are<br />
failures in the geometric perspective that implicate safety risks for the technical system under<br />
design. Technical components that are verified in a functional hazard analysis (FHA) to be<br />
functionally independent can fail together because all of them are involved into the effects of<br />
failures on the geometric perspective. Thus, functional hazards can be reached because of the<br />
geometric installation of components which are located in a way that they are impacted together<br />
by a particular risk. The PRA allows the identification and classification of such risks. Based<br />
on the results of a PRA the geometric installation of a system under design can be optimized in<br />
order to prevent functional hazards.<br />
Particular risks on the geometric perspective Relevant Particular risks for a system under<br />
design depend on the geometric context in which the system operates. Common particular risks<br />
are explosions, fire, heat, lightning, hits by foreign parts or leakage leading to evacuation of gas<br />
or liquids. For an individual system the particular risks are specific. I.e. for a space vehicle<br />
the effects of radiation or the impact of space debris have to be regarded. Tire burst, bird strike<br />
or engine burst are particular risks that can lead to the evacuation and the impact of fragments<br />
that damage or even destroy installed technical components of an airplane. According to EASA<br />
AMC20-128A when analyzing the burst of an airplane engine there can be different fragments<br />
which are single one third disc fragment, intermediate fragment, small fragment and fan blade.<br />
Performing a particular risk analysis on a geometric model In order to perform a PRA<br />
a model of the system under design in the geometric perspective must exist. Components of<br />
a technical perspective are allocated to geometric components of this model. The geometric<br />
components have geometric locations within the system under design. Therefore, the effect<br />
32/ 156
<strong>Architecture</strong> <strong>Modeling</strong><br />
of particular risks in the geometric perspective can be traced to the respective installed technical<br />
components. A particular risk is a failure condition for a geometric component which<br />
has a description of the sphere of effect in its geometric context. Such a description can be a<br />
shape which has a position and orientation relative to the component to which the particular risk<br />
belongs. I.e. the particular risk of a released airplane engine fragment has a description of a trajectory<br />
which describes its possible flight. This trajectory provides information about locations<br />
which may be impacted by the released fragment. Since the relative speed of an airplane engine<br />
fragment is very high the fragment will probably break though the skin of the airplane. Thus<br />
the trajectory can be considered to be the complete sphere of effect for the airplane. For other<br />
particular risks the spheres of effect can vary regarding parameters like mass, speed or orientation.<br />
An interference analysis provides information between the sphere of effect of particular<br />
risks, like the trajectory of a fragment, and parts of a geometric system under design. The result<br />
of such an analysis is a hitlist. Such a hitlist specifies geometric component parts of the geometric<br />
system under design that can take damage being affected by a paricular risk. Impacted<br />
installations of technical components which host essential safety functions can be determined<br />
that way. Furthermore the effect of particular risks can be other failures of components on the<br />
geometric perspective such as leaks which again effect involvement of liquids.<br />
Relationship of particular risks to the technical perspective Particular risks can have several<br />
effects on the safety of technical components in a system under design. I.e. a hit by an<br />
airplane engine fragment can lead to leakage of a fuel tank or damage of electric cables which<br />
results in lost of thrust. Such safety impacts can be identified based the results of a PRA. The<br />
destruction or damage of geometric components are again failure conditions. Using the allocation<br />
relationship from technical components to geometric components these failure conditions<br />
can be mapped to failure conditions of technical components. These failure conditions can be<br />
analyzed in an FHA to identify safety hazards which result from particular risks. Thus, the violation<br />
of functional independence on a technical perspective can be determined based on related<br />
failure conditions of a geometrical perspective which result from a PRA. Safety risks can be<br />
calculated to estimate the probability for a failure condition on the technical perspective based<br />
on the probability of a particular risk on the geometric perspective. Furthermore the installation<br />
of technical components can be optimized to improve the safety. Target of such an optimization<br />
can be the installation of technical components in a way that they are not impacted together<br />
by the same particular risk. Such an analysis and optimization can be embedded in a Common<br />
Cause Analysis (CCA) as defined in ARP 4761.<br />
Exemplary Particular Risk Analysis In an example the airbag system of a car is enhanced<br />
by an emergency call system. Considerable particular risks can be water intrusion due to leaks<br />
and a crash with an obstacle or another car. Loss of airbag and emergency call functionality<br />
is a failure which shall not be reached. Function loss due to intruding water can be prevented<br />
by improving covering materials. Thus, for this particular risk a safety analysis to optimize the<br />
component installation is not important. But in a crash an ECU can be completely destroyed<br />
by the forces that take effect from the crash. We consider the in time reaction of the airbag<br />
system to release the airbag during a crash to be verified. An emergency call system shall be<br />
hosted on the same ECU as the airbag system to ensure direct call of emergency services in<br />
case of a crash. Therefore, the ECU that hosts the airbag controller still has to work correctly<br />
after having released the airbag. This implicates additional requirements on the installation of<br />
the ECUs to positions in the car. As depicted in figure 3.22 an installation decision for the<br />
redundant airbag system with emergency call function can be analyzed in a PRA on the effects<br />
33/ 156
<strong>Architecture</strong> <strong>Modeling</strong><br />
of a crash as a particular risk. The analyzed particular risk is a front crash in an angle of 146°<br />
relative to the car’s orientation and a speed of 60 km h . The red trapezoid represents the sphere of<br />
effect of the particular risk. This sphere of effect is based on a physical model that describes a<br />
region in which the forces yield by the crash act in a destructive way. An interference analysis<br />
shows that the geometric installations of both ECUs are inside the sphere of effect and therefore<br />
affected by this particular risk. Thus, the redundant enhanced airbag system will fail in case of<br />
this particular risk. This can be prevented by choosing another position for at least one of the<br />
ECUs. Anyway, further particular risks like crash situations with other angles or different speed<br />
have to be analyzed in order to identify a safe position.<br />
Logical Perspective Technical Perspective Geometrical Perspective<br />
Redundant<br />
Airbag System<br />
with Emergency<br />
Call Function<br />
ECU1<br />
ECU2<br />
ECU3<br />
ECU4<br />
(x,y,z)<br />
Port ECU<br />
(x,y,z)<br />
Figure 3.22: PRA Analaysis for the enhanced Airbag-System<br />
Front Crash<br />
angle = 146°<br />
speed = 60 km/h<br />
(x,y,z)<br />
Particular Risk Analysis in <strong>Architecture</strong> <strong>Modeling</strong> A model with relevant information<br />
for a PRA covers following architecture modeling concepts. The geometric<br />
system context is described by a GeometricComponent in the geometric perspective.<br />
System components are specified as GeometricComponents, too. A<br />
RichComponentProperty typed by a component of a technical perspective is allocated to<br />
a GeometricInstallation of a GeometricComponent that represents the geometric<br />
system component. The GeometricInstallation being a LocationInstallation<br />
is assigned to a GeometricLocation and being a RoutedInstallation it<br />
is assigned to a set of GeometricLocationLinkss and therefore to a set of<br />
GeometricLocationss within the containing GeometricComponent. A particular risk<br />
is a special GeometricFailureConditions of a GeometricComponent. It has a<br />
34/ 156
<strong>Architecture</strong> <strong>Modeling</strong><br />
Shape that describes its sphere of effect. GeometricInstallations being impacted by<br />
a particular risk are listed as a result of a particular risk analysis.<br />
3.3 Heterogeneous Rich Components<br />
The concepts of Heterogeneous Rich Components (HRC) and contracts both originate from the<br />
European SPEEDS project. Both are key concepts of the architecture meta-model.<br />
3.3.1 Component Model<br />
The component concept of HRC is compatible to many other modeling languages that have a<br />
component concept. For example the meta-model of AUTOSAR defines a set of templates, one<br />
of which is the SoftwareComponentTemplate [8] that establishes the concept of a SoftwareComponent.<br />
The interface concept in terms of ports and their types is more refined in AUTOSAR<br />
than in HRC, but is still compatible. SysML also provides a component concept (referred to as<br />
blocks) [39]. In fact, alignment with SysML was an important goal when defining the component<br />
and interface concept of the architecture meta-model.<br />
Port<br />
+ isConjugated: Boolean<br />
Variable<br />
+port<br />
0..*<br />
0..*<br />
+attribute<br />
+component<br />
Aspect<br />
RichComponent<br />
SystemRequirement +satisfies<br />
Satisfy<br />
1<br />
+component<br />
0..1<br />
1..*<br />
+component 1..*<br />
+aspect<br />
0..1<br />
+component<br />
0..1<br />
+behavior<br />
0..*<br />
Behav iorImplementation<br />
Behavior<br />
Figure 3.23: Meta-model integration of the concept of components<br />
BlockOccurrence<br />
A component is a module with well defined interfaces and is the basic entity of any model.<br />
Resuability of components is an inherent property of the proposed architecture modeling approach.<br />
Note that the concept of components proposed here is not restricted to software components.<br />
It is rather an approach of how architecture modeling should be done, fostering reuse<br />
of models for different developed products as well as enabling computer aided verification of<br />
integration of models. So a component can model a reusable software module, a specific sensor<br />
measuring temperature or a computing device (e. g. an ECU or IMA-module) hosting software<br />
applications.<br />
Figure 3.23 depicts how the component concept is embedded in the architecture meta-model.<br />
A RichComponent optionally encapsulates a realization of a certain aspect, which is aggregated<br />
in the role of behavior. The association to Aspect from Behavior provides means<br />
to categorize the realization in terms of the addressed aspects. Parts of the behavior realizations<br />
can be exposed at the Ports of the component. The set of all ports is considered the syntactic<br />
interface of the RichComponent. The optional realization of an aspect is complemented by<br />
its specification. A specification of an aspect can be expressed by means of contracts.<br />
35/ 156
3.3.1.1 Ports<br />
<strong>Architecture</strong> <strong>Modeling</strong><br />
Ports are the interaction points of a component. The set of all ports of a component constitutes<br />
its syntactical interface. Figure 3.24 depicts how the port concept is embedded in<br />
the architecture meta-model. Each Port of a component has a name and is typed by a<br />
PortSpecification, which declares the Flows or Services required or provided at<br />
some port. A flow is a data-oriented interaction point and services model services a component<br />
provides or requires. The PortSpecification is either a set of flows or a set of services,<br />
but not both.<br />
Port<br />
+ isConjugated: Boolean<br />
+port<br />
+component<br />
1<br />
RichComponent<br />
FlowDirection<br />
in<br />
out<br />
bidirectional<br />
0..*<br />
FlowKind<br />
discrete<br />
continuous<br />
event<br />
+portSpecification<br />
+type<br />
PortSpecification<br />
0..*<br />
InteractionPoint<br />
«isOfType» 1<br />
1<br />
+interactionPoint<br />
Flow<br />
+ direction: FlowDirection<br />
+ kind: FlowKind<br />
Serv iceDirection<br />
provided<br />
required<br />
«isOfType» 1<br />
Serv ice<br />
+ direction: ServiceDirection<br />
«isOfType»<br />
+returnType 1<br />
+type<br />
DataType<br />
+type<br />
+service<br />
0..1<br />
1 «isOfType»<br />
Figure 3.24: Meta-model integration of the concept of Ports<br />
0..*<br />
Parameter<br />
+formalParameter<br />
Flows have a name, a direction (in, out or bidirectional) and are typed by a<br />
DataType. The DataType concept is explained in [50] and is out of the scope of this document.<br />
A flow declares the kind of a data-exchange of an owning component. Along with the<br />
DataType and direction, its kind can be specified, which is either event, discrete or<br />
continuous (see Figure 3.25). Declaring an event flow means there is a value available on<br />
the flow only at certain time instants and the value can change from instant to instant. In a<br />
discrete flow the value is always available, even between the time instants at which the value<br />
changes. In a continuous flow there is also always a value available, but it can evolve continuously<br />
during time durations and also change discretely at time instants. The trajectory of a<br />
continuous flow can be described by a piecewise continuous function.<br />
val<br />
event<br />
t<br />
val<br />
discrete<br />
Figure 3.25: The different kinds of flows<br />
t<br />
val<br />
continuous<br />
Services have a name and a direction (provided or required). A Service is typed by<br />
multiple DataTypes, that constitute the signature of the service. As shown in Figure 3.24 a<br />
service owns a set of DataTypes, that define the parameters of the service and a DataType<br />
in the role of returnType, that defines the return value of the service declaration.<br />
t<br />
36/ 156
<strong>Architecture</strong> <strong>Modeling</strong><br />
Conjugation of Ports is a concept to reverse the directions of all InteractionPoints of<br />
a port. As the direction of a flow or service is specified by the flow or service itself, the direction<br />
of the port is defined by the direction of its InteractionPoints. When ports of components<br />
inside a composition are being connected (see Section 3.3.2.2), the attribute isConjugated<br />
of a Port can be used in order to avoid defining two PortSpecifications, which only<br />
differ in the directions of their InteractionPoints.<br />
3.3.1.2 Aspects<br />
An aspect defines a viewpoint which is orthogonal to the structure of the system, and describes<br />
aspects of functional and/or non-functional properties of component models. Being orthogonal<br />
to the structure of the system-model means, that the underlying component-model and interfaces<br />
of each component are the same for all aspects. Currently we consider three aspects for a<br />
component: functional behavior, real-time and safety. However the meta-model allows to define<br />
additional aspects according to the needs of a company or application domain.<br />
Aspect<br />
+aspect 0..1<br />
Behavior<br />
+aspect<br />
0..*<br />
0..*<br />
+behavior<br />
Behav iorImplementation<br />
+component<br />
0..1<br />
BehaviorBlock<br />
+type 1<br />
«isOfType»<br />
BlockOccurrence<br />
RichComponent<br />
1..*<br />
Satisfy<br />
+component<br />
SystemArtefact<br />
+satisfies<br />
1..*<br />
Requirement<br />
+ rationale: String [0..*]<br />
SystemRequirement<br />
Figure 3.26: Meta-model integration of the concept of Aspects<br />
For each Aspect a RichComponent can have a specification and a realization. The<br />
specification of an aspect is given by a SystemRequirement, that is associated with one or<br />
more Aspects. The Satisfy-trace link allows to associate a set of RichComponents with<br />
one or more SystemRequirements that the components shall satisfy.<br />
A realization of an aspect is given by a Behavior, that is eventually associated<br />
with an Aspect. A realization can be modelled in any behavior modeling tool or<br />
provided as implemented source code. The latter would correspond to the specialized<br />
BehaviorImplementation. If a behavior modeling tool is used and it has a trace-based<br />
semantics, then the modeled behavior can be interpreted as a BlockOccurrence. A realization<br />
of an aspect provided as a BlockOccurrence can be verified against the specification<br />
(see Section 4.3). The BlockOccurrence is typed by an HRC state machine, which is also<br />
defined in the meta-model but not described here (cf. [50]).<br />
3.3.1.3 Contracts<br />
A contract is a triple (As,Aw,G). As is the strong assumption of a contract, Aw the weak assumption<br />
and G the guarantee. A strong assumption characterizes the allowed design context<br />
of the component, i. e. the environment from the point of view of the component. If the design<br />
37/ 156
<strong>Architecture</strong> <strong>Modeling</strong><br />
context does not comply to a strong assumption, then this constitutes an ”illegal” out of specification<br />
usage of the corresponding component. Weak assumptions structure contracts according<br />
to cases wrt. the integration context. That means a strong assumption can be confined by a weak<br />
assumption and for that particular integration context a more precise guarantee may be given.<br />
If a component is used accordingly to its strong assumptions, it will guarantee the behavior<br />
specified by the guarantee, provided the weak assumption is fulfilled.<br />
TextuallyRepresentedElement<br />
+ textualRepresentation: String<br />
Assertion<br />
ProcessRequirement<br />
+stronglyAssuming<br />
+weakAssumption<br />
0..1<br />
1<br />
+strongAssumption<br />
0..1<br />
+guarantee<br />
+aspect<br />
SystemArtefact Aspect<br />
Requirement<br />
+ rationale: String [0..*]<br />
SystemRequirement<br />
Stakeholder<br />
InformalAssertion FormalAssertion +assertion +formal BlockOccurrence<br />
+type<br />
BehaviorBlock<br />
0..1<br />
0..1<br />
0..1<br />
+weaklyAssuming 0..1<br />
0..*<br />
+stakeholder<br />
0..*<br />
0..1<br />
«isOfType»<br />
+guaranting<br />
Figure 3.27: Meta-model integration of the concept of Contracts<br />
In the meta-model the concept of contracts is represented by the meta-class<br />
SystemRequirement (see Figure 3.27). The naming difference is motivated by the existence<br />
of the concept ProcessRequirement. Both are requirements and we wish to emphasise<br />
that by name. However the concept of ProcessRequirement is out of the scope of this<br />
document and we will use the terms SystemRequirement and Contract interchangeably.<br />
A Contract associates an Assertion in three roles, which correspond to the elements<br />
of its constituting triple. An assertion can be either an InformalAssertion or a<br />
FormalAssertion. Apart from this, an assertion always is a specification of the dynamics<br />
exposed at the interface (InteractionPoints in all Ports) of a component with regard<br />
to a certain aspect. The loose coupling of SystemRequirement and RichComponent<br />
allows the reuse of a SystemRequirement and to associate it with different components via<br />
the Satisfy-trace link. Note that when specifying assumptions (strongAssumption and<br />
weakAssumption), they must not limit the output ports of the component. In turn the guarantee<br />
(guarantee) must not limit the input ports of the component. If an assumption (strong<br />
or weak) has not been specified for a contract, then they are assumed to be true. That means<br />
a component associated with that contract is not restricted with regard to any design context,<br />
which is most certainly not the case!<br />
The BlockOccurrence is typed by an HRC state machine, which is also defined in the<br />
meta-model but not described here (instead see [50]).<br />
Tracability of requirements is an important concept in order to be able to reason about refinement<br />
of them and to provide arguments to certification authorities how implementation require-<br />
1<br />
38/ 156
RichComponent<br />
<strong>Architecture</strong> <strong>Modeling</strong><br />
Satisfy Refine<br />
1..* +component<br />
+refinedBy 1..* 1 +refinedReq<br />
Requirement<br />
+ rationale: String [0..*]<br />
+satisfies<br />
1..*<br />
SystemRequirement<br />
+entailed<br />
1<br />
+entailing<br />
Figure 3.28: Meta-model integration of the tracing of requirements and contracts<br />
ments have been derived from initial product requirements. The meta-model supports tracability<br />
by different trace-links between Requirements and RichComponents (see Figure 3.28).<br />
The Satisfy concept links SystemRequirements to RichComponents, indicating<br />
the components that have to satisfy the aspect specifications defined by the<br />
SystemRequirements. The satisfaction relation is discussed detailed in Section 4.3. Note<br />
that RichComponents are linked to SystemRequirements and do not own them. This<br />
allows both of them to exist independently from each other, i. e. from the meta-model point of<br />
view it is not necessary to first create a RichComponent along with its syntactical interface<br />
in order to specify a SystemRequirement (contract). Indeed this loose coupling makes it<br />
possible to first specify a contract and to define a RichComponent at a later time and link it<br />
to that contract.<br />
The Refine concept links Requirements to other Requirements. The motivation is<br />
to express that a requirement referenced in the role refinedReq has been refined by a set of<br />
more detailed requirements referenced in the role refinedBy. One use-case for this trace-link<br />
is to document requirement formalizations. How requirements can be formalized is discussed<br />
in Section 4.1.<br />
The Entail concept links SystemRequirements to other SystemRequirements.<br />
The composition of the contracts referenced in the role entailing establish a refinement<br />
of the contract referenced in the role entailed. The role of Entail-trace link in design<br />
steps carried out during the development process is discussed in Section 4.2. In this document<br />
we consider a formal interpretation of contracts linked by the Entail concept and call it a<br />
refinement or entailment of contracts (see Section 6.3.2).<br />
3.3.1.4 Requirement Specification Language<br />
In order to ease the specification of contracts we provide a pattern-based requirement specification<br />
language (RSL) (see Section 6.1), that can be used to specify the aspects of a<br />
RichComponent or specializations thereof.<br />
The RSL is basically a set of textual patterns, that can be instatiated in order to specify an<br />
Assertion. For example the syntax of the pattern F1 is defined as:<br />
1..*<br />
Entail<br />
39/ 156
<strong>Architecture</strong> <strong>Modeling</strong><br />
F1 whenever event occurs event [does not] occur[s] [during interval]<br />
Phrases in square brackets are optional, bold elements are static keywords of the pattern, and<br />
elements printed in italics represent attributes that have to be instantiated by the requirements<br />
engineer. So a valid instance of the pattern F1 is:<br />
whenever p1.f1 occurs p2.f1 occurs during [8ms,10ms]<br />
The RSL provides patterns that have been categorized according to aspects they address. Despite<br />
that categorization they may also be used for the specification of other aspects. For example<br />
a Probability Pattern can be useful when specifying a failure hypothesis of components,<br />
which clearly is a Safety aspect.<br />
While the concept Contract (resp. SystemRequirement) and BlockOccurrence<br />
is directly expressed in the meta-model, this is not true for the syntax and semantics of<br />
RSL patterns. Figure 3.27 shows that an Assertion referenced in any of the three<br />
roles strongAssumption, weakAssumption or guarantee is a specialization of<br />
TextuallyRepresentedElement. The attribute textualRepresentation contains<br />
that text. Multiple instances of RSL patterns would then be entered in that text field.<br />
Thus, a set of pattern instances specifies a FormalAssertion of a contract, i. e. its strong<br />
and weak assumptions and its guarantee. See Section 6.1.1 for a formal definition of RSL.<br />
3.3.2 Hierarchy and Composition<br />
Once components are defined by means of the RichComponent concept and their syntactical<br />
interface has been specified by Ports, components can be instantiated in the context of<br />
other components as parts forming a composition of components. That composition is again a<br />
component, whose behavior is given by the behavior of its constituting parts.<br />
3.3.2.1 Hierarchy<br />
The instantiation of components in the context of other components is represented in the<br />
meta-model by the RichComponentProperty concept (see Figure 3.29). A component<br />
with its ports and contained behavior is referenced in the role of type by a<br />
RichComponentProperty. That RichComponentProperty is in turn aggregated by<br />
another RichComponent as one of its parts. The behavioral specifications characterized by<br />
contracts that are linked to a RichComponent and corresponding realizations are also instantiated<br />
in any RichComponentProperty typed by the RichComponent. It is allowed to<br />
have multiple instances of the same component in the context of a composition. As this concept<br />
can be applied recursively, it allows to construct deeply nested hierarchies of components. Note<br />
that this is consistent with type/part concepts found in e. g. UML [41] and SysML [39].<br />
3.3.2.2 Composition<br />
When components are used as parts in another component, they have to be interconnected by<br />
binding the flows and services contained in the ports. The concept of Interconnection<br />
is owned by the same component which also owns the parts. An interconnection is either a<br />
delegation connection or an assembly connection. The former links the interaction points of the<br />
outer component, i. e. the composition, with interaction points of its constituting parts. So the<br />
interaction points need to have the same direction. Assembly connections link the interaction<br />
points of parts of a composition to each other. So their directions must be reversed.<br />
40/ 156
MultiplicityElement<br />
+part 0..*<br />
RichComponentProperty<br />
+component<br />
1<br />
+type 1<br />
<strong>Architecture</strong> <strong>Modeling</strong><br />
«isOfType»<br />
RichComponent<br />
+component<br />
1<br />
+component<br />
0..1<br />
Port<br />
+ isConjugated: Boolean<br />
+attribute<br />
+port<br />
Figure 3.29: Meta-model integration of hierarchy concepts<br />
0..*<br />
0..*<br />
Variable<br />
In the meta-model there is no distinction between the two kinds because it can be deduced<br />
from the context the kind of the connection. Both kinds of connections between Ports is captured<br />
by the concept Connector (cf. Figure 3.31). In most other languages (also UML) the<br />
interconnection of components in compositions is done by binding of ports. Since the architecture<br />
meta-model allows to declare multiple InteractionPoints per Port the concept<br />
FlowBinding, resp. ServiceBinding, allows to only bind a subset of the flows or services<br />
defining a port. Thus, linking Ports by means of Connectors is semantically just a<br />
short-cut to bind all interaction points of the Ports. Note that a PortSpecification may<br />
either contain multiple Flows or multiple Services, but not both.<br />
Directions are defined by the InteractionPoints themselves. in, out or<br />
bidirectional are possible directions of Flows and provided or required are possible<br />
directions of Services. Ports typed by a PortSpecification carry an attribute<br />
isConjugated. If this attribute is set to true the directions of all InteractionPoints<br />
in the corresponding PortSpecification are treated as if reversed. By default the value<br />
of the attribute is false. This facility allows to specify peer ports, i. e. with the same flows or<br />
services, but complementary directions.<br />
CompC<br />
part1:CompA pA pB part2:CompB<br />
(a) assembly connection<br />
pC<br />
CompC<br />
pA<br />
part1:CompA<br />
(b) delegation connection<br />
Figure 3.30: Example for assembly- and delegation connections<br />
FlowBinding and compatibility of Flows There are two case distinctions for binding<br />
Flows by means of FlowBinding. If flows of different ports shall be bound establishing an<br />
assembly connection like illustrated in Figure 3.30a, then the directions of both flows need to be<br />
complementary (in for out, out for in, bidirectional for bidirectional). In the<br />
case of delegation connections like depicted in Figure 3.30b, the directions must be the same.<br />
Further the flows must be compatible. Two flows are compatible if they associate the same<br />
DataType and their kind is the same.<br />
41/ 156
<strong>Architecture</strong> <strong>Modeling</strong><br />
ServiceBinding and compatibility of Services There are two case distinctions for<br />
binding Services by means of ServiceBinding. If services of different ports shall be<br />
bound establishing an assembly connection like illustrated in Figure 3.30a, then the directions<br />
of both services need to be complementary (required for provided and vice versa). In the<br />
case of delegation connections like depicted in Figure 3.30b, the directions must be the same.<br />
Further the services must be compatible. Two services are compatible if their signatures are<br />
the same. That means they associate the same DataType as returnType and have identical<br />
Parameters with regard to their name and types.<br />
Connector and compatibility of Ports When defining assembly connections<br />
or delegation connections between Ports by means of the concept<br />
Connector, all InteractionPoints of the Ports defined by their corresponding<br />
PortSpecification are bound. Which pairs of InteractionPoints are bound is<br />
determined by name. All pairs of InteractionPoints (Flows or Services) must be<br />
compatible as described above.<br />
FlowDirection<br />
in<br />
out<br />
bidirectional<br />
FlowKind<br />
discrete<br />
continuous<br />
event<br />
Serv iceDirection<br />
provided<br />
required<br />
Parameter<br />
+part 0..*<br />
RichComponentProperty<br />
PortSpecification<br />
1<br />
+component<br />
+type<br />
1<br />
+portSpecification<br />
+formalParameter +service<br />
0..*<br />
0..1<br />
1<br />
«isOfType»<br />
+type 1<br />
«isOfType»<br />
+interactionPoint<br />
RichComponent<br />
Port<br />
+ isConjugated: Boolean<br />
0..*<br />
Serv ice<br />
InteractionPoint<br />
+ direction: ServiceDirection<br />
+service 1..*<br />
«isOfType»<br />
+component<br />
+port<br />
«isOfType»<br />
1<br />
0..*<br />
+port<br />
1..*<br />
+component<br />
1<br />
Connector<br />
«instanceRef»<br />
+interconnection<br />
Flow<br />
+ direction: FlowDirection<br />
+ kind: FlowKind<br />
+returnType<br />
1<br />
«isOfType»<br />
+type 1<br />
DataType<br />
+type 1<br />
0..*<br />
Interconnection<br />
FlowBinding Serv iceBinding<br />
«instanceRef»<br />
Figure 3.31: Meta-model integration of the composition concepts<br />
+flow<br />
1..*<br />
«instanceRef»<br />
Composition of Contracts: If a composition of components is specified by means of the<br />
described concepts, that composition is correct with regard to the syntactical interfaces of the<br />
parts and the composition. However it must also be ensured, that the contracts specified for<br />
the components typing the parts are compatible and are a valid refinement of the contracts<br />
of the composition. Figure 3.32 illustrates that relation. The components ComponentA and<br />
ComponentB have contracts C1 resp. C2. They are used as parts in the context of the composition<br />
ComponentC, which in turn has a contract C12. The contracts are linked to the<br />
components by means of the Satisfy-trace link described in 3.3.1.3. When constructing<br />
a composition, the relationship of the contracts associated with the concerned components is<br />
specified by means of the Entail-trace link.<br />
42/ 156
ComponentC<br />
<strong>Architecture</strong> <strong>Modeling</strong><br />
part1:ComponentA<br />
part2:ComponentB<br />
ComponentB<br />
C2<br />
«Entail»<br />
C12<br />
«Entail»<br />
ComponentA<br />
Figure 3.32: Composition of components and contracts<br />
Note that this link only declares the proof obligations which have to carried out in order to<br />
ensure a sound (de-)composition. Actually one needs to verify, that the entailing contracts<br />
are compatible, meaning the strong assumption of a contract must not be violated by another<br />
component, which is connected to it. If the entailing contracts are compatible, it must<br />
be checked if the entailing contracts are indeed a refinement of the entailed contract.<br />
Related to the example sketched in Figure 3.32, Compatibility of C1 and C2 needs to be verified<br />
and the pair {C1,C2} must be a refinement of C12. We call such proof obligations Virtual<br />
Integration Testing, which is discussed in Section 4.2.<br />
3.4 Mapping Component Parts<br />
In Section 3.1 the Realize-trace link has been introduced, which allows to trace component<br />
realizations when switching abstraction levels. In Section 3.2 the Allocate-trace link has<br />
been introduced, which allows to trace component allocations between different perspectives.<br />
Both concepts are similar and therefore the superordinate concept of Mapping has been defined.<br />
+type 1<br />
RichComponent<br />
+component 1<br />
«isOfType»<br />
+part 0..*<br />
+mappedTo<br />
RichComponentProperty<br />
1 «instanceRef»<br />
+mapped<br />
1<br />
«instanceRef»<br />
TextuallyRepresentedElement<br />
+ textualRepresentation: String<br />
Allocate<br />
Mapping<br />
0..1<br />
Realize<br />
+mapping<br />
+formal<br />
1<br />
MappingBlock<br />
+mappingBlock 0..1<br />
+behavior 1<br />
BlockOccurrence<br />
1<br />
Serv ice<br />
C1<br />
+ direction: ServiceDirection<br />
+mappingBlock<br />
+mappingLink<br />
«isOfType»<br />
+service 0..1<br />
«instanceRef»<br />
0..*<br />
+type<br />
1<br />
Flow<br />
+ direction: FlowDirection<br />
+ kind: FlowKind<br />
MappingLink<br />
BehaviorBlock<br />
Figure 3.33: Meta-model integration of the mapping concepts<br />
+flow 0..1<br />
«instanceRef»<br />
Figure 3.33 shows how a Mapping relates two parts of components<br />
(RichComponentProperty) to each other. Further a mapping is formalized by means of a<br />
MappingBlock, that has a BlockOccurrence, which is typed by a BehaviorBlock.<br />
The concept of MappingLinks link flows or services of a component taking part in the<br />
43/ 156
<strong>Architecture</strong> <strong>Modeling</strong><br />
mapping relation to pins of the BehaviorBlock (for BehaviorBlocks and Pins refer to<br />
[50]).<br />
A mapping specifies correlations of observable behavior of components by a formal specification<br />
of how dynamics of InteractionPoints of one RichComponentProperty<br />
are projected on corresponding behavior of InteractionPoints of another<br />
RichComponentProperty. As the mapping relates component parts, the context<br />
of both RichComponentProperty needs to be described. Therefore the concept of<br />
instanceRefs is used, which has been inspired by the AUTOSAR and EAST-ADL<br />
meta-models.<br />
An InstanceRef defines a particular navigation within future M0 instance trees of M1<br />
classifiers. The reason is that the concept of reusable RichComponents lead to a situation<br />
where a flat M1 model of hierarchical components specifies deep, tree-like M0 instances. That<br />
means when mapping parts of components on M1 level, one needs to describe navigation paths<br />
in order to uniquely identify the parts. The problem when dealing with reusable structural<br />
hierarchies and the concept of InstanceRefs is detailled described in [7].<br />
44/ 156
4 Steps in Component-Based Design<br />
The <strong>SPES</strong> architecture meta-model (<strong>SPES</strong>MM) intends to support development of complex<br />
systems involving a large number of different engineers. In such a process, it is essential to<br />
specify the roles and responsibilities of each engineer: who is responsible for ensuring what,<br />
and under which conditions. Only if this is ensured, integration problems in later design phases<br />
can successfully be identified and fixed.<br />
In <strong>SPES</strong>MM, first class citizens are components and their interfaces. Components may interact<br />
with each other and with the environment by means of their interfaces, thus forming<br />
a model of the intended system. The <strong>SPES</strong>MM supports the development process in that it<br />
allows to represent roles and responsibilities of engineers by corresponding concepts in the design<br />
architecture. For example, engineers are usually responsible for distinct parts of the design.<br />
Design artifacts have to be constructed, refined, and implemented in different perspectives and<br />
at different abstraction levels. The <strong>SPES</strong>MM allows to (formally) express responsibilities for<br />
components in form of contracts, which are an instance of the assume/guarantee specification<br />
style. If different engineers, responsible for certain design artifacts, have to integrate the respective<br />
parts of the design, contracts allow to define under which conditions this integration will be<br />
successful. The same holds for example, if different engineers are responsible for specification<br />
and implementation of certain components. <strong>SPES</strong>MM provides means to reason about under<br />
which conditions an implementation satisfies the corresponding specification.<br />
The underlying concepts of the <strong>SPES</strong>MM particularly allow to define proof obligations that<br />
have to be performed in order to ensure whether responsibilities defined for model and component<br />
interfaces are satisfied. In an early design step for example, functionality of the system may<br />
be identified, together with a set of requirements to be satisfied by those functions. When in<br />
a subsequent design phase decomposition of the system into logical components is performed,<br />
it should be explicated which logical components are responsible to guarantee which system<br />
functionality. If this is done ”the right way”, the <strong>SPES</strong>MM allows the application of tools that,<br />
if not performing proof obligations automatically, explicate which proof obligations have to<br />
be performed in order to ensure satisfaction of the identified function requirements. This section<br />
intends to provide an overview of those concepts related to establish a continuous design<br />
process, and to provide traceability of requirements and the corresponding relations between<br />
design artifacts.<br />
Typically, a design process along the <strong>SPES</strong>MM involves many different design steps:<br />
• Entry point is the operational perspective, where system boundaries are identified, and<br />
the relevant goals, or initial requirements, are defined.<br />
• The system is then decomposed into distinct functions provided by the system in order to<br />
achieve the goals. Functionality may be further refined into sub-functions in this phase.<br />
Furthermore, requirements are identified for the respective functions which are typically<br />
related to the initial goals and requirements.<br />
• Functionality is partitioned into logical components providing the intended functions, and<br />
45/ 156
<strong>Architecture</strong> <strong>Modeling</strong><br />
• Logical components are allocated to a technical system that distinguishes software, processing<br />
and communication hardware, mechanical, hydraulic, and electrical components.<br />
• The technical components are finally allocated to a geometrical space.<br />
The design phases may be performed on different levels of abstraction, representing different<br />
refinements of the initial design.<br />
It should be noted that the <strong>SPES</strong>MM does not define a concrete design flow. For example,<br />
not all design phases have to be performed on all abstraction levels. Even the number of abstraction<br />
levels and perspectives may vary between different design processes. We can however<br />
identify a set of primitive design steps that are repeatedly applied during such design processes.<br />
More precisely, each design step identified in a certain process supported by the <strong>SPES</strong>MM can<br />
typically be broken into a sequence of such primitive steps:<br />
Decomposition Most component types defined in the <strong>SPES</strong>MM can be decomposed. That<br />
is, components are broken down into smaller parts, or sub-components. This includes<br />
for example functions that are decomposed into sub-functions, and the decomposition of<br />
logical components.<br />
Allocation Components within different perspectives of a design are entangled in that they<br />
represent (partly) the same system entities. Functions for example are allocated onto<br />
logical components.<br />
Realization During the design process, the same system may be represented at different levels<br />
of abstraction. We say, the system at a certain abstraction level (and the same perspective)<br />
realizes the system at the higher levels.<br />
Implementation Finally, components gets implemented. Depending on the perspective and abstraction<br />
level, implementations may be automata models, StateCharts, MatLab models,<br />
and even C-Code. Given a characterization of the responsibilities of a component and an<br />
implementation, does it satisfy the responsibilities?<br />
Each design step introduces a set of proof obligations clearly defining under which conditions<br />
all responsibilities of the involved design artifacts are satisfied. This in advance allows to define<br />
clear interfaces between the responsibilities of all engineers involved in a design process. In the<br />
following, the corresponding proof obligations and involved model artifacts for each identified<br />
primitive design step shall be discussed.<br />
4.1 Formalizing Requirement Specifications with Contracts<br />
In order to define how modeling along the <strong>SPES</strong>MM supports the primitive design steps, it is<br />
important to understand the concept of contracts. In short, contracts characterize components<br />
following the assume/guarantee reasoning style:<br />
• The assumption of a contract defines under which environment conditions a component<br />
is expected to work, and<br />
• the guarantee characterizes ensured behavior of the component, given that the assumptions<br />
are satisfied.<br />
46/ 156
<strong>Architecture</strong> <strong>Modeling</strong><br />
Assume/guarantee reasoning is known for a long time. Various formal foundations exist<br />
providing means to validation and verification of a design, and to ensure validity of design steps<br />
such as decomposition and refinement. Contract based design with explicated assumptions is<br />
however also a design philosophy:<br />
• Contracts allow to differentiate responsibilities. A component is responsible to satisfy its<br />
guarantees. But contracts also define responsibilities of the environment of the component,<br />
that is, the conditions under which the guarantee holds.<br />
• Contracts enable reuse. When a component is designed, the contexts it is expected to<br />
work properly can be specified by means of (strong) assumptions.<br />
Given for example a braking system of a car, one could state the requirement that the component<br />
BrakingSystem must be able to absorb a certain amount of kinetic energy (depending,<br />
beside other, on the mass and maximum speed of the car) within some maximum time. Such<br />
requirement can be stated in terms of a contract. While the respective component is required to<br />
perform its action within a maximal time span, the requirement also states that this only holds<br />
for a certain maximum energy to absorb. Obviously, the component cannot (and should not) be<br />
responsible to bound the kinetic energy of the whole car, but only to absorb it fast enough.<br />
This indeed has also impact on the proof obligations for that component: For any implementation<br />
of that component for example, it does not have to be verified that it satisfies the<br />
requirement under all possible conditions, but only for those defined by the assumption. Moreover,<br />
the component, once validated for all possible environments defined by the assumption,<br />
can be used in any such context without further satisfaction validation. However, other proof<br />
obligations exist for such cases, as explained in Section 4.2.<br />
To be more formal, a contract C of a component as defined in the <strong>SPES</strong>MM is a triple<br />
C := (As,Aw,G)<br />
where As and Aw are the assumptions, and G is the guarantee of the contract. The distinction<br />
between strong (As) and weak assumptions (Aw) deviates from traditional assume/guarantee approaches,<br />
and affects two aspects when dealing with contracts: From a methodological point of<br />
view, it may be desired for contracts to distinguish two types of assumptions. Strong assumptions<br />
characterize the environment of the component to work correctly (strong assumptions).<br />
Such characterization may be further refined by weak assumptions, discriminating for example<br />
different contexts of the respective component (weak assumptions).<br />
In this sense, strong assumptions rather correspond to the traditional idea of assume/guarantee<br />
reasoning discussed before, while weak assumptions rather correspond to different settings in<br />
which the component is intended to be used. This shall become more clear by an example:<br />
• An air conditioning system of an airplane shall provide air of a certain quantity, temperature<br />
range and humidity to the fuselage.<br />
• A requirement may define for example the range of environmental conditions under which<br />
the air conditioning system shall operate, say at an altitude between 0 and 12500m. In<br />
our context, this requirement would be expressed as a strong assumption.<br />
• Other requirements typically discriminate different modes of operation. For example, the<br />
air temperature provided may be different when the air conditioning systems works in<br />
normal operation mode, and when some components have failures.<br />
47/ 156
<strong>Architecture</strong> <strong>Modeling</strong><br />
• In both cases, provided air must be within a certain range. This range could be between<br />
12 ◦ C and 28 ◦ C in normal mode, while in degraded mode the maximum allowed temperature<br />
may be 32 ◦ C. These requirements are the guarantees of the air conditioning system,<br />
one for each corresponding weak assumption.<br />
The distinction between strong and weak assumptions may also affect the way to verify certain<br />
properties involving formal reasoning about contracts. This discussion is however out of<br />
scope of this section, and the interested reader is referred to Section 6.2. From a user perspective,<br />
strong assumptions can be seen as to be assigned to components instead of contracts. All<br />
contracts associated to a component shall maintain the same strong assumptions. If we use in<br />
the following the term assumption of a contract without attribution, we refer to the conjunction<br />
of both strong and weak assumptions.<br />
Deriving (formal) contracts from (informal) requirements is not always an obvious and easy<br />
task. To avoid ambiguities, often formal languages are used to state requirements with well<br />
defined meaning. It however does not only require some training to write requirements in such<br />
formal languages, it may also be hard to read them. The pattern based Requirement Specification<br />
Language RSL provides an easy to use formal language with well defined semantics, that is still<br />
readable like natural language. RSL patterns consist of static text elements and attributes being<br />
instantiated by the requirements engineer. Each pattern has well defined semantics in order<br />
to ensure consistent interpretation of the written system specification across all project participants.<br />
RSL allows writing of natural sounding requirements while being expressive enough<br />
to formalize complex requirements. To gain a high degree of intuition, the language consist of<br />
only a few constructs that can be easily remembered, to give the user the possibility to fully<br />
understand the RSL and to choose the right pattern that fits the properties he wants to demand<br />
of the system.<br />
RSL aims at providing expression of a large scale of requirement domains. It defines patterns<br />
for each of the following categories:<br />
• Functional patterns express requirements such as relationship between events, handling<br />
of conditions and invariants, and optional intervals in which a requirement (or parts of it)<br />
is valid.<br />
• Probability patterns, which are needed in almost all safety critical systems to express<br />
failure or hazard probabilities.<br />
• Safety related patterns outline relationships between system components. These patterns<br />
enable the specification of single point of failures or other failure and hazard dependencies<br />
between different components.<br />
• Timing patterns are used to describe real-time behavior of systems. This includes recurring<br />
activations, jitter and delay.<br />
RSL patterns normally contain optional parts that need not be instantiated. A functional<br />
pattern for example describing causality between two events looks like this:<br />
whenever event1 occurs event2 occurs [during interval]<br />
Phrases in square brackets are optional, bold elements are static keywords of the pattern, and<br />
elements printed in italics represent attributes that have to be instantiated by the requirements<br />
engineer. In the example above three attributes event1, event2 and interval exist, and the part<br />
[during interval] is optional.<br />
48/ 156
<strong>Architecture</strong> <strong>Modeling</strong><br />
When specifying requirements there is no strict typing like int or real but there are categories<br />
that specify what is described by the different attributes. To not complicate the language too<br />
much and to be also expressive enough, the set of supported attributes has been carefully chosen:<br />
• Events represent activities in the system. An event can be for example a signal, a user<br />
input by pressing a button, or the availability of a computational result. Events occur at<br />
specific points in time and have no duration.<br />
• Conditions are logical and/or arithmetical expressions over variables and the status of<br />
events. Conditions can be used in two different ways. Firstly, they can be used as pseudo<br />
events to trigger an action if the condition becomes true. And secondly, they may represent<br />
the system state that has to hold for a specified time.<br />
• Intervals describe a continuous fragment of time whose boundaries are either (relative)<br />
time measures, or events. Intervals can be open “]x,y[“ or closed “[x,y]” or a combination.<br />
• Components refer to entities that are able to handle events or condition variables.<br />
RSL supports various combinations of elements. It allows for example filtering of events by<br />
intervals or conditions. That is, whenever a pattern expects an event, one may also use “event<br />
during interval”, or “event under (condition)”. Thus, one can e.g. specify<br />
whenever request during [activate,deactivate] occurs response occurs during [l,u]<br />
meaning that a response is constrained only if the request happened after an activate and before<br />
some deactivate event. Filtering of events can be applied recursively. So activate could again<br />
be filtered by some interval or condition.<br />
The interested reader is referred to Section 6.1 for a detailed description of the RSL.<br />
While specification languages such as RSL help the engineer to formalize requirements, there<br />
are other pitfalls when specifying contracts. Two key properties of contracts, essential to maintain<br />
sanity of the design-flow shall be discussed here, namely receptiveness and consistency.<br />
Receptiveness Since the interface of a component distinguishes input ports and output ports,<br />
there is a clear separation between those ports the component controls and those that are controlled<br />
by the components environment. Receptiveness denotes the fact that also the responsibilities<br />
of both assumption and guarantee of a contract are properly distinguished. More formally,<br />
a contract is receptive only if the assumption does not restrict possible behavior of the output of<br />
a component, and if the guarantee does not restrict the input ports.<br />
To give an example, we assume a component with inport i and outport o. A guarantee stating<br />
that, whenever the component sends an event to o, the environment responds by another event<br />
send to i within, say 5 ms, violates the receptiveness property. It violates receptiveness because<br />
it is not the duty of a components guarantee to require the environment to react in a certain<br />
amount of time. For the same reason, an assumption stating that the component produces an<br />
output event each 10 ms violates receptiveness. On the other hand, an assumption for such a<br />
component, stating that whenever the component sends an event to o, the environment responds<br />
by another event send to i within 5 ms, perfectly maintains receptiveness. A receptive contract<br />
is denoted directed.<br />
49/ 156
<strong>Architecture</strong> <strong>Modeling</strong><br />
Consistency Consistency captures the fact that a set of contracts is not contradictory. An<br />
inconsistent set of contracts is not usable at all, because it does not allow for any useful implementation.<br />
The most easy way to get an inconsistent set of contracts is to define an ”empty”<br />
guarantee for any possible context. For example, we could state the following guarantees: (i)<br />
whenever the component receives an event from its environment, the next event on its output<br />
will be a, and (ii) whenever the component receives an event from its environment, the next<br />
event on its output will be b. If we do not further restrict the behavior of the environment (for<br />
example by saying that this happens under no conditions), the result will be inconsistent.<br />
A detailed discussion about receptiveness and consistency together with formal definitions<br />
can be found in Section 6.2.1.<br />
4.1.1 Functional Specifications<br />
A simple example for contract-based specification of functional requirements is depicted in<br />
Figure 4.1. It shows a possible design of an air conditioning system at the logical perspective.<br />
The interface of the (logical) component has been identified during former design steps. Not all<br />
relevant ports have been shown, but we see a port providing status information about the current<br />
air temperature (airTemp), an input port allowing to select the temperature (tempSelect),<br />
and ports representing the current air flow (airIn, airOut).<br />
The figure shows also some requirements associated to the component, stated in terms of<br />
contracts. The specification is largely simplified and even does not follow correct RSL syntax.<br />
The green part is the (strong) assumption of the component. The figure reflects the fact, that<br />
all contracts of a component share the same strong assumptions. Blue parts are the guarantees.<br />
Weak assumptions are yellow. In our case, they are always true and thus do not further restrict<br />
the environment.<br />
-20°C
<strong>Architecture</strong> <strong>Modeling</strong><br />
next selection. The second assertion defines what happens before this minute. Obviously, it<br />
should not be allowed that the temperature provided after a new selection becomes too high<br />
or too low (maybe due to inappropriate heating or cooling). The specification of the second<br />
guarantee thus states, that temperature fluctuation is within an appropriate range, i.e., the first<br />
momentum of some hull curve of the difference is less than 0.<br />
4.1.2 Real–Time<br />
The very same system could be instantiated at lower abstraction level as depicted in Figure<br />
4.2. It shows a chain of components involved to perform the air conditioning function.<br />
A tempSens component represents the sensor acquiring the temperature of the fuselage. The<br />
sensor values are captured, stored for later use (such as visualization), and forwarded to the<br />
temperature control component AirTempControl. The control component calculates control<br />
parameters with respect to the incoming temperature and the selected one (not shown), thus<br />
implementing a classical control loop. The AirCondition component models a physical<br />
part, possibly consisting of heating and cooling elements, compressors, etc.<br />
temp occurs each 50ms<br />
with jitter 5ms<br />
tempSensor<br />
Delay between temp and tempData within [5ms,7ms]<br />
tempData occurs each<br />
50ms with jitter 10ms<br />
temp tempData<br />
Capture<br />
Delay between tempData and control within [10ms,12ms]<br />
control<br />
AirTempControl AirCondition<br />
Figure 4.2: Real-Time Contracts Example<br />
Derived from the demands of such control loop (e.g. with respect to stability), it might be<br />
required that the loop is executed periodically with a certain period and maximum jitter. Due<br />
to other demands, maximum delays might needed to be satisfied by the control loop. These<br />
requirements belong to the classical real-time domain, and can be represented by a set of realtime<br />
contracts as depicted in the figure.<br />
The contract associated to the component Capture specifies the strong assumption that the<br />
component gets an input each 50ms with a maximum jitter of 5ms. Under this condition, the<br />
component is required to deliver the sensor value within a time span of 5 to 7ms.<br />
A similar contract is assigned to the control component, stating that the maximum jitter is<br />
10ms, and the requirement to deliver control parameters between 10ms and 12ms after it has<br />
received an input.<br />
4.1.3 Safety<br />
Looking at components under the safety aspect requires to address the dysfunctional behavior<br />
of them. When designing a redundant architecture, for instance, the specification needs to<br />
express that a functional failure can only occur when failures in (all) redundant sub-functions<br />
can occur. A typical contract thus looks like as depicted in Figure 4.3. The contract has the<br />
51/ 156
<strong>Architecture</strong> <strong>Modeling</strong><br />
strong assumption true since it holds for any environment. The weak assumption states that<br />
the contract holds under the condition that the underlying hardware (BSCU) does not fail. In<br />
this case, the braking system fails only if both redundant sub-systems hydraulic system A and<br />
hydraulic system B fail.<br />
true<br />
BrakingSystem<br />
BSCUFails does not fail<br />
BrakingSystemFails shall only fail if HydraulicSystemAFails &&<br />
HydraulicSystemBFails<br />
BSCUFails BrakingSystemFails HydraulicSystemAFails HydraulicSystemBFails<br />
Figure 4.3: Safety Contracts Example<br />
Since failure conditions are usually complex, abbreviations can be defined for them:<br />
failureCondition TooMuchEnergyConsumption is defined by:<br />
(consumption > 2) holds longer than 2s<br />
Later, these abbreviations may by used to simplify the definitions of safety-related patterns.<br />
4.2 Virtual Integration Testing<br />
Technically, a component may be a (composed) system, which is constructed from a set of<br />
(sub-) components. In more detail, a system is given by a set of components, an interface and<br />
a set of named (inter-) connections. An interface is a set of directed ports, denoted inports<br />
and outports, respectively. Each port specifies a set of typed (data) flows or services 1 . In the<br />
following, we assume for simplicity that ports specify single flows. Hence, we identify ports<br />
and their corresponding flow. Furthermore, we abstract in the following discussion from the<br />
fact, that we have to distinguish between components and instances of components. This fact is<br />
important in the sense, that contracts are defined on components and not on instances (which are<br />
referred as RichComponentProperty in the <strong>SPES</strong>MM). Thus, if we have two instances<br />
of the same component, we have to uniquely identify the respective ports of these instances.<br />
Otherwise, from a formal point of view, contracts cannot distinguish behavior of different ports.<br />
If, for example, L and R in Figure 4.4 would be instances of the same component, the ports<br />
would have the same name, and could not be distinguished from a semantical viewpoint without<br />
unique identification.<br />
A connection links two ports. It either links two sub-component ports, one outport and one<br />
inport (e.g. port l2r), or one port of the system interface and one sub-component port with<br />
the same direction (e.g. port r2e), or two system interface ports of opposite direction. Each<br />
sub-component inport and each system outport must be linked to exactly one other port. Linked<br />
1 We omit a discussion of services here, which can be seen as a derived concept.<br />
52/ 156
<strong>Architecture</strong> <strong>Modeling</strong><br />
ports must have the same type (we do not treat issues related to types in depth, here, so we adopt<br />
this simple principle for ease of exposition). A simple sample system is depicted in Figure 4.4,<br />
where only the connection names and not the port names are given.<br />
Figure 4.4: Simple example system<br />
In a design process, composed systems usually do not exist a-priori (except in case of re-use),<br />
but are the result of a concrete design step. For example, due to a design decision, it may be<br />
found that an initially identified air condition system shall be realized by a sequential composition<br />
of different sub-systems. The first subsystem may provide air from the environment, the<br />
second one has to bring this air to its correct temperature, and so on. Contract-based design<br />
helps in such situation not only to allocate responsibilities for the respective sub-components,<br />
but also to trace back whether the requirements of the component are satisfied when all of<br />
its sub-components satisfy their “local” requirements. The corresponding proof obligations are<br />
subsumed by so-called Virtual Integration Testing (VIT). The term virtual is due to the fact, that<br />
these proof obligations are independent from the implementation of the respective components.<br />
That is, if a virtual integration test has been performed successfully, any set of implementations<br />
satisfying the responsibilities of the respective sub-components are inherently covered by the<br />
VIT. We will discuss satisfaction of an implementation in Section 4.3.<br />
VIT defines the conditions under which the contracts of all sub-components, when put together,<br />
satisfy the contract(s) of the parent component, and which verification steps have to be<br />
performed in order to establish this property. The relevant property is denoted refinement and<br />
is discussed in Section 4.2.2. VIT also defines proof obligations necessary to verify that two<br />
(or more) components can be put together reasonably at all. Component R in the figure above<br />
could for example state, that the input values on its input l2r always are below, say, 30 ◦ C. If the<br />
guarantee of component L would state that its output on l2r is always between 25 and 35 ◦ C, it<br />
would obviously be problematic to put L and R together. Compatibility of contracts is discussed<br />
in Section 4.2.1.<br />
Compatibility is however only one property necessary to properly compose components. As<br />
for the contracts of a single component, VIT also requires that the composition of components<br />
does not violate receptiveness and consistency. This becomes particularly evident when components<br />
are composed to form a control loop as in Figure 4.4 via ports l2r and r2l, where inports<br />
and outports of components are mutually connected. Thus, a reasonable design methodology<br />
relies on receptiveness and consistency for composing components.<br />
Another proof obligation of VIT, that shall not be discussed here in detail, concerns some<br />
form of stability. In the figure above, contract CL could for example state that the output on<br />
l2r becomes 0 if the input r2l is 1, and vice verse. Contract CR could equivalently state that<br />
the output r2l becomes 0 if its input l2r becomes 1 (and vice verse). Although the respective<br />
contracts are compatible, and even strongly consistent, the resulting system will not be stable,<br />
53/ 156
<strong>Architecture</strong> <strong>Modeling</strong><br />
if there is no delay greater 0 specified in which toggling output takes place in the components.<br />
This property is well-known, and also important in many formalisms used in control- and also<br />
in real-time scheduling theory. In the context of the FOCUS methodology for example, it is<br />
denoted strict causality. Strict causality ensures (beside other important properties) that proof<br />
obligations of VIT can be performed sequentially.<br />
4.2.1 Compatibility and VIT Condition<br />
As stated before, two (or more) components will “work together” properly, only if they are compatible.<br />
Due to the fact that components are characterized by their specifications, compatibility<br />
is defined for contracts.<br />
Compatibility reflects the distinction of responsibilities in that strong assumptions about the<br />
environment of a component must not be violated by another component that is connected to<br />
this component. Technically, this property is expressed by the following definition: Given<br />
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,<br />
where only output ports of L are connected to input ports of R, it must hold<br />
G L =⇒ A R s<br />
(4.1)<br />
that is, if the guarantee of component L is satisfied, then it will “satisfy” the strong assumptions<br />
of component R.<br />
If also output ports of R are connected to input ports of L, it further must hold<br />
G R =⇒ A L s<br />
To give an example, let GL be that statement that its output port o delivers values within<br />
a range of [25,35] ◦C. It characterizes any possibly “behavior” of such temperature over the<br />
time that is not lower than 25◦C and not higher than 35◦C at any time point. This specification<br />
would satisfy an assumption AR s , stating that the temperature is in the range [20,40] ◦C. A more<br />
detailed definition of “behavior” can be found in Section 6.2. However, Equation 4.1 states that,<br />
if component L satisfies its guaranteed behavior, then this will also satisfy the assumption of R<br />
about its environment.<br />
Such definition of compatibility is in “simple” situations a necessary condition. It however<br />
neglects the fact, that composites typically have an interface to their environment. In Figure 4.4<br />
for example, there are four other ports of the composite component to its environment, namely<br />
e2l, l2e, e2r and r2e. Moreover, it also defines compatibility for single contracts only. Since<br />
the parent component of a composite usually also has assumptions about its environment, compatibility<br />
of the composite must take this assumptions into account. Suppose for example, that<br />
the input port e2l of component L specifies some air flow. Suppose further, L has the (strong)<br />
assumption that this air flow is bounded by, say, 50l/s. If now the parent component S has<br />
the (strong) assumption that this flow is bound by, say, 100l/s, the whole composition may<br />
become contradictory with respect to receptiveness and consistency as discussed before. It is<br />
obvious to see why. The specification for L assumes that the input flow is below 50l/s. Only<br />
if this assumption applies, L is bound to its guarantee. Otherwise, its behavior is unspecified.<br />
Compatibility on the other hand relies on the guarantees given by the respective components.<br />
In other words, compatibility holds only if all guarantees given by the involved components are<br />
adhered to.<br />
Formally, compatibility in the general case is defined as follows. Given a component with<br />
strong assumption As, and sub-components with contracts Ci = (Ai i, j<br />
s,Aw ,Gi, j ), compatibility is<br />
(4.2)<br />
54/ 156
established if (and only if):<br />
<strong>Architecture</strong> <strong>Modeling</strong><br />
As ∧C 1,1 ∧ ... ∧C n,mn =⇒ A 1 s ∧ ... ∧ A n s<br />
We denote such compatibility a (strong) VIT Condition. The strong VIT condition is a sufficient<br />
criterion for compatibility of components as further discussed in Section 6.2.<br />
4.2.2 Refinement<br />
The second proof obligation of VIT is to ensure that the composition of sub-components “satisfies”<br />
the responsibilities of the respective parent component. To this end, the concept of refinement<br />
is introduced. We say, a specification (say contract) C ′ refines another specification C if<br />
and only if the behavior specified by C ′ is a subset (or maximal equal to) the behavior specified<br />
by C. Formally, we say:<br />
C ′ refines C if and only if [[C ′ ]] ⊆ [[C]]<br />
where [[.]] formalizes what is meant to be the “behavior” specified by the contract, as defined in<br />
Section 6.2.<br />
To give an example, for the following requirements<br />
• C1 ≡ whenever i is in the range of [2,5] then o = 2 i , otherwise o = undef<br />
• C2 ≡ whenever i is in the range of [1,7] then o = 2 i , otherwise o = undef<br />
where i and o are real-valued ports, it holds that C2 refines C1. This is not because it refines<br />
the input behavior (which in fact is not the case, since in both contracts i may be arbitrary), but<br />
because the output behavior is more confined in C2.<br />
The same definition holds also for sets of contracts. A set of contracts C ′ 1 ,...,C′ m refines<br />
another set of contracts C1,...,Cm if:<br />
[[C ′ 1 ∧ ... ∧C ′ m]] ⊆ [[C1 ∧ ... ∧Cn]]<br />
It is not trivial in any case to formally show refinement between contracts. Theories about<br />
contract-based design thus introduce various sufficient conditions for refinement for ease of<br />
verification (cf. [11]). An intuitive (and often easier to check) property is that of dominance.<br />
We say, a contract C ′ dominates a contract C if (and only if) it holds:<br />
[[As]] ⊆ [[A ′ s]] and [[Aw]] ⊆ [[A ′ w]] and [[G ′ ]] ⊆ [[G]]<br />
That is, (i) the assumptions (both strong and weak) C ′ makes about the behavior of the environment<br />
is less restrictive than or equal to that of C, and (ii) the guarantee C ′ provides confines<br />
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.<br />
Checking for dominance often greatly reduces complexity when performing proof obligations.<br />
Particularly in the case of decomposing components, where assertions to the environment<br />
are often simply “copied” to the composite of the respective component. The same often holds<br />
for the guarantees. In such cases, simple syntactical equivalence of assertions can be performed<br />
in order to verify refinement. On the other hand, decomposition often involves introduction of<br />
new contracts, specifying responsibilities for the interaction between sub-components. In many<br />
situations, composition of components lead to the (logical) elimination of contracts such that<br />
the proof chain ends up with single contracts. An example for this is discussed in the following<br />
section.<br />
55/ 156
4.2.3 Examples<br />
VIT Example for Functional Contracts<br />
<strong>Architecture</strong> <strong>Modeling</strong><br />
In the following, the application of VIT is discussed by a set of simple examples. We start with a<br />
example for VIT checking of functional specifications as depicted in Figure 4.5. It shows an air<br />
conditioning system providing tempered air. The AirTempSystem component has input ports<br />
for the currently selected and the current temperature, and an output port for the temperature<br />
of the provided air. The corresponding contract to AirTempSystem states that the difference<br />
between selected and current air temperature must be at most 0.5 ◦ C. The contract further states<br />
that whenever some temperature has been selected, it takes at most 60 seconds for the system to<br />
provide air of this temperature. The strong assumption of the contract has three parts. The first<br />
part states that the selected temperature is in the range of between 12 ◦ C and 35 ◦ C. The second<br />
part states that the sensor value actTemp for the actual temperature is updated each 20 ms.<br />
And the third assumption requires from the environment that the actually measured temperature<br />
must not differ more than 0.2 ◦ C from the provided air.<br />
C1<br />
C2<br />
C<br />
tempSelect<br />
actTemp<br />
12°C < tempSelect < 35°C<br />
actTemp occurs each 20ms<br />
always abs(actTemp –<br />
flowTemp) < 0.2°C<br />
AirTempSystem<br />
12°C < tempSelect < 35°C<br />
actTemp occurs each 20ms<br />
whenever chg(tempSelect) occurs nomTemp = tempSelect<br />
holds during [10ms, chg(tempSelect) [<br />
Whenever actTemp occurs control.act = actTemp &&<br />
control.nom = nomTemp occurs within [12ms, 14ms]<br />
tempSelectStore<br />
AirTempControl<br />
whenever chg(tempSelect) occurs abs(flowTemp – tempSelect) <<br />
0.5°C holds during [60s, chg(tempSelect) [<br />
nomTemp<br />
C3<br />
control occurs each 20ms<br />
with jitter 2ms<br />
control<br />
AirCondition<br />
Figure 4.5: VIT Example with Functional Contracts<br />
whenever control occurs abs(flowTemp - control.nom) <<br />
abs(control.act - control.nom) + epsilon holds during [10ms, control [<br />
flowTemp<br />
In order to perform VIT, we start with the VIT condition stating that the strong assumption<br />
of the component, together with all local contracts must imply all local strong assumptions.<br />
As Figure 4.6 shows, this is trivial to see for the local contracts C1 and C2. For C3 =<br />
(A3s,A3w,G3), we can employ existing results from real-time analysis allowing us to derive<br />
a periodical activation pattern for the occurrence of control events from contract C2. This<br />
concludes the strong VIT condition, requiring that all strong assumptions of the sub-components<br />
are satisfied if the strong assumptions of the parent component is (and if all local contracts are<br />
satisfied). Interestingly, the example shows that different aspects of a design are often closely<br />
entangled, in this case the functional and the real-time aspect.<br />
Showing satisfaction of the guarantee of C needs a little more effort. Firstly, we can derive a<br />
new guarantee from C1 and C2, and G3 that replaces in G3 occurrences of control.nom by<br />
56/ 156
12°C < tempSelect < 35°C<br />
actTemp occurs each 20ms<br />
always abs(actTemp –<br />
flowTemp) < 0.2°C<br />
12°C < tempSelect < 35°C<br />
actTemp occurs each 20ms<br />
control occurs each 20ms<br />
with jitter 2ms<br />
<strong>Architecture</strong> <strong>Modeling</strong><br />
whenever chg(tempSelect) occurs abs(flowTemp – tempSelect) <<br />
0.5°C holds during [60s, chg(tempSelect) [<br />
whenever chg(tempSelect) occurs nomTemp = tempSelect<br />
holds during [10ms, chg(tempSelect) [<br />
Whenever actTemp occurs control.act = actTemp &&<br />
control.nom = nomTemp occurs within [12ms, 14ms]<br />
control occurs each 20ms<br />
with jitter 2ms<br />
whenever control occurs abs(flowTemp –<br />
tempSelect) < abs(actTemp- tempSelect) +<br />
epsilon holds during [10ms, control [<br />
whenever control occurs abs(flowTemp - control.nom) <<br />
abs(control.act - control.nom) + epsilon holds during [10ms, control [<br />
Figure 4.6: VIT Example with Functional Contracts: Proof Chain<br />
tempSelect. We can further calculate which epsilon is needed in G3 to achieve a maximal<br />
temperature difference of 0.5 ◦ C for the air conditioning. To this end, we need the activation frequency<br />
of the AirCondition component (20 ms), the maximum delay for control.act<br />
to become the value of the selected temperature in case of a modification of tempSelect<br />
(24 ms).<br />
The maximum change of the selected temperature is 23 ◦ C. Due to the activation period,<br />
the air condition has about 6000 cycles to achieve this temperature change (within 60 seconds<br />
minus delays). So in each cycle, the temperature change must be at least ≈ 0.004 ◦ C. Together<br />
with the assumption about the maximal deviation of airTemp from the air flow temperature<br />
(0.2 ◦ C) of C, we can further derive the guarantee of C. Due to this we have shown dominance<br />
C against the local contracts, which concludes the VIT.<br />
VIT Example for Real-Time Contracts<br />
Figure 4.7 depicts another simple decomposition situation of another part of the same system.<br />
The local components have real-time contracts associated stating about the activation pattern<br />
and maximum delays. The contract of the parent component AirTempSystem in fact specifies<br />
an end-to-end deadline. Note that all assumptions in this example are strong.<br />
The proof chain of the VIT for the example is shown in Figure 4.8. We start VIT by<br />
showing compatibility of the local contracts C1 and C2. To this end, we derive a new guarantee<br />
from the local contract C1 = (A1s,A1w,G1). According to [23], C1 implies contract<br />
C1 ′ = (A1s,A1w,G1 ′ ) where:<br />
G1 ′ = actTemp occurs each 50ms with jitter 7ms<br />
With this, one can easily show implication of the strong assumption A2s of contract C2, and<br />
thus G1 ′ =⇒ A2s. Since the whole system is acyclic, stability is not an issue here. Also<br />
receptiveness is not an issue for such real-time contracts, because the assumptions reason about<br />
input ports only, and the guarantees reason about the delay between inports and outports. The<br />
whole system thus satisfies C1 ∧C2 =⇒ A1s ∧ A2s.<br />
Furthermore, it can be shown that assumption As is a strict subset of A1s. This in advance<br />
completes the strong VIT condition, and also the first part of the dominance relation between C<br />
and C1 ∧C2 (all weak assumptions are true).<br />
57/ 156
AirTempSystem<br />
C1<br />
C<br />
temp occurs each 50ms<br />
temp occurs each 50ms<br />
with jitter 5ms<br />
C2<br />
<strong>Architecture</strong> <strong>Modeling</strong><br />
Delay between temp and actTemp within [5ms,7ms]<br />
actTemp occurs each<br />
50ms with jitter 10ms<br />
temp actTemp<br />
Capture<br />
Delay between temp and control within [15ms,20ms]<br />
Delay between actTemp and control within [10ms,12ms]<br />
AirTempControl<br />
Figure 4.7: VIT Example with Real-Time Contracts<br />
control<br />
Due to the fact that, when C1 is satisfied, then also the assumption of C2 is satisfied (remind<br />
that C1 and C2 are compatible), we can eliminate A2s. If both guarantees G1 and G2 are satisfied,<br />
both together satisfy G because the result of G1 ∧ G2 is a simple addition of delays. This<br />
completes the proof chain.<br />
temp occurs each 50ms<br />
temp occurs each 50ms<br />
with jitter 5ms<br />
Delay between temp and actTemp within [5ms,7ms]<br />
actTemp occurs each<br />
50ms with jitter 7ms<br />
actTemp occurs each<br />
50ms with jitter 10ms<br />
!<br />
Delay between temp and control within [15ms,20ms]<br />
Delay between temp and control within [15ms,19ms]<br />
"<br />
Delay between actTemp and control within [10ms,12ms]<br />
Figure 4.8: VIT Example with Real-Time Contracts: Proof Chain<br />
VIT Example for Safety Contracts<br />
<strong>Modeling</strong> safety aspects is usually more elaborated than for real-time, since specification of<br />
failure conditions and dependencies are often rather complex. A simple application example of<br />
VIT for safety shall however be discussed. Figure 4.9 shows an abstract model of a wheel brake<br />
system. The BSCU controls a hydraulic system, that provides the brake force to a wheel, by<br />
sending commands via CMD AS. The braking system is redundantly implemented. Both BSCU<br />
and Hydraulic contain the relevant parts twice. The figure shows that BSCU is composed of<br />
two redundant control units BSCU1 and BSCU2. The control units take the (also redundant)<br />
brake pedal positions (PedalPos1 and PedalPos2) and calculate respective commands<br />
(CMD AS1 and CMD AS2) to control the hydraulic system. Both controls units maintain validation<br />
ports (Valid1 and Valid2) indicating whether the commands send are valid or not.<br />
58/ 156
<strong>Architecture</strong> <strong>Modeling</strong><br />
The component ValidSwitch takes these signals and decides whether the BSCU is considered<br />
to deliver valid commands. The SelectSwitch finally takes the commands send by<br />
the respective control units. In normal operation mode, it relays the commands from the first<br />
control unit to the hydraulic system. If the first units fails, SelectSwitch switches over to<br />
the second unit. In order to keep the example simple, the redundancy concept of the hydraulic<br />
system is not shown here.<br />
PedalPos1<br />
BSCU1<br />
CMD_AS1<br />
C<br />
always not(fail(PedalPos1))<br />
&& not(fail(PedalPos2))<br />
BSCU<br />
Valid1 Valid2<br />
Valid<br />
Switch<br />
Select<br />
Switch<br />
PedalPos2<br />
BSCU2<br />
CMD_AS2<br />
always not(fault(BSCU1)) or<br />
always not(fault(BSCU2))<br />
C1<br />
always<br />
not(fail(PedalPos1))<br />
C2<br />
always<br />
not(fail(PedalPos2))<br />
CMD_AS<br />
Valid<br />
Hydraulic<br />
always not(fail(CMD_AS1)) or<br />
always not(fail(CMD_AS2))<br />
always not(fault(BSCU1))<br />
always not(fault(BSCU2))<br />
Wheel<br />
Figure 4.9: VIT Example with Safety Contracts<br />
always not(fail(CMD_AS1))<br />
always not(fail(CMD_AS2))<br />
Figure 4.9 also shows some safety contracts. The top-level contract C = (As,Aw,G) defines as<br />
the strong assumption that the brake pedals never fail to send correct position values. The weak<br />
assumption of C states that the contract holds for such situations where not both redundant control<br />
units fail together. In this case, the contract guarantees that at least one of the command lines<br />
delivers correct commands to the hydraulic. Note, that this safety case is strongly simplified. A<br />
comprehensive safety analysis usually would incorporate much more complex situations. For<br />
example, none of the components ValidSwitch and SelectSwitch are considered here.<br />
It is furthermore a rather unrealistic requirement that both brake pedals never fail.<br />
We however assume that a further outcome of safety analysis are two local contracts for the<br />
redundant control units. C1 strongly assumes that PedalPos1 never fails. The weak assumptions<br />
captures situations where BSCU1 does not have a fault. In this case, C1 = (A1s,A1w,G1)<br />
guarantees that the commands send by BSCU1 are correct. A similar contract C2 is defined for<br />
BSCU2.<br />
Showing satisfaction of VIT for this example is simple. We can firstly observe that As =⇒<br />
A1s ∧ A2s, since As equals to A1s ∧ A2s. This proofs the strong VIT condition. Furthermore, it<br />
holds that Aw =⇒ A1w ∨ A2w because Aw equals to A1w ∨ A2w. Assuming satisfaction of C1<br />
and C2, we get A1s ∧ A1w =⇒ G1 for C1, and A2s ∧ A2w =⇒ G2 for C2 by definition.<br />
If we put all four implications together, we can derive As ∧ Aw =⇒ G1 ∨ G2. Since G1 ∨<br />
G2 =⇒ G because of, again, equivalence, we have shown dominance. This concludes the VIT.<br />
59/ 156
4.3 Satisfaction<br />
<strong>Architecture</strong> <strong>Modeling</strong><br />
Although implementation aspects are not considered here 2 , implementing identified components<br />
is a primitive design step, and thus the necessary proof obligations shall be discussed.<br />
Formally, the contracts of a component characterize allowed behavior of the component. Thus,<br />
any implementation of a component must satisfy its contracts. In other words, an implementation<br />
of a component satisfies its specification if its behavior does not violates its specified one,<br />
or, it must not behave other than proposed by its specification. That way, the behavior of a<br />
component defined by its implementation can be seen as a refinement which has to be shown:<br />
M is a correct implementation of C if and only if [[M]] ⊆ [[C]]<br />
where M denotes an implementation of the respective component.<br />
<strong>SPES</strong>MM provides concepts to specify implementations for components employing the same<br />
underlying formal semantics as for contracts. This is however convenient only for some special<br />
cases and thus <strong>SPES</strong>MM does not rely on it. It rather provides an open and extensible approach<br />
to integrate any kind of implementations such as Real-Time StateCharts, MatLab models and<br />
even C-Code. That way, it is left to the needs of the respective design processes to reason<br />
about satisfaction, and to define sufficient and necessary conditions based on the needs, e.g., for<br />
certification.<br />
4.3.1 Establishing Functional Specifications<br />
At least two different approaches can be distinguished to establish functional specification:<br />
formal verification due to model-checking, and testing.<br />
4.3.1.1 Establish functional specifications with model-checking<br />
Formal verification of functional behavior is a well-established research area, and various formalisms<br />
and model-checking techniques have been developed so far. The AutoFocus and the<br />
FUJABA Real-Time tool suites for example provide effective functional verification. Formal<br />
verification techniques for Real-Time StateCharts and also for MatLab Simulink models exist.<br />
Exhaustive verification is indeed a challenging task due to complexity reasons. There are however<br />
industrial relevant approaches. For example, C-Code verification by model-checking is<br />
known to be effectively applicable for a number of years.<br />
4.3.1.2 Establish functional specifications with testing<br />
Another way to establish functional contracts is due to HIL-testing. To this end, the implementation<br />
is executed on a prototyping platform, and execution traces are captured while running<br />
the system. In a subsequent hosted simulation, the traces are checked against the (executable)<br />
contract specifications. Indeed also other ways exist for testing, such as the implementation of<br />
the specification which runs in parallel to the implementation code. Also often more abstract<br />
implementations are considered, which is the domain of simulation.<br />
2 see for example Sections 3 and 6.2<br />
60/ 156
<strong>Architecture</strong> <strong>Modeling</strong><br />
4.3.2 Establishing Real-Time Contracts<br />
In fact, real-time contracts can be established by employing the same techniques as for functional<br />
contracts. However, establishing real-time requirements is the traditional domain of realtime<br />
scheduling theory. Implementations of the involved components, usually called tasks, are<br />
taken in order to calculate execution times for invocations of the respective components. Due<br />
to a characterization of the underlying (computational) resource, scheduling analysis calculates<br />
worst-case scenarios in order to verify whether the requirements about maximal delays are satisfied.<br />
Since real-time contracts usually define activation scenarios for components, and maximal<br />
delays, real-time scheduling scheduling theory fits well to establish real-time contracts. For<br />
more complex real-time contracts, and at higher abstraction levels where no detailed characterization<br />
of the underlying resources exist, more involved analysis techniques can be applied<br />
such as combination of scheduling analysis and model-checking. In order to improve efficiency,<br />
model-checking techniques can be combined with testing approaches [14].<br />
4.3.3 Establishing Safety Contracts<br />
One possible way to establish safety contracts is to perform a traditional safety analysis (like<br />
fault tree analysis) on an implementation model of the system enriched with failures. The<br />
enriched model contains the nominal as well as the dysfunctional behavior of the system. This<br />
allows to formalize the causality between failures resp. failure combinations and their effects.<br />
As a consequence, notions of (minimal) cut sets and fault trees can be formally related with a<br />
given implementation of the system.<br />
4.3.3.1 Establish safety specification with testing<br />
Based on the enriched model, both the nominal and dysfunctional behavior may be simulated.<br />
Equipped with coverage notions that address that all failures and their combinations need to be<br />
covered, test strategies can be designed to check that the expected safety contracts hold.<br />
4.3.3.2 Establish safety specification with symbolic methods<br />
Similar to the approach for functional specifications, safety contracts can also be established<br />
by symbolic methods that compute the causality between failure combinations and their effect.<br />
Here again, the crucial property of these methods is that they are complete (with respect to the<br />
model enriched with failures). A detailed example for this approach is given ins Section 5.1.3.4.<br />
4.4 Deployment<br />
While the design steps discussed before reason about components of a particular design, two<br />
further design steps are important with respect to different perspectives and abstraction levels,<br />
that is, for the interfaces between whole models.<br />
Perspectives At a certain abstraction level, a system may be designed “from left to right”.<br />
Starting with the operational perspective, requirements engineering results in identifying the<br />
system boundaries and interfaces, and some top-level requirements, often called goals. In the<br />
functional perspective, the functions of the system are identified that are needed to achieve these<br />
goals. In the logical perspective, components are identified that perform the identified functions,<br />
61/ 156
<strong>Architecture</strong> <strong>Modeling</strong><br />
and so forth. Each of such design steps usually involves an assignment of requirements to<br />
the identified components. Some requirements are usually derived from formerly identified<br />
requirements, while other requirement occur due to the introduction of new components and<br />
interfaces.<br />
To stress the air conditioning example, we may have the requirement for an air-conditioning<br />
function (in the functional perspective) to provide air from the environment of an airplane with<br />
certain quantity and temperature. To show the simplest form of deriving a requirement for the<br />
logical perspective at the same abstraction level, there may be exactly one logical component<br />
performing the air conditioning function. In such a case, it seems to be obvious to assign the<br />
same requirement to the logical component as to the corresponding function.<br />
In more complex settings, logical components may perform several functions (sequentially,<br />
parallel, or in any other order), or several logical components may be involved performing a<br />
single functionality. Here, deriving requirements for one perspective from another may be more<br />
complex, particularly for the latter case. 3<br />
The same can be said for the relation between logical and technical components. A logical<br />
component may be performed by a single technical entity. It may be also performed by a<br />
composition of different entities, may be involving mechanical, computational and other components.<br />
Indeed there may be requirements that are unique to specific perspectives. For example,<br />
geometrical constraints such as packaging sizes, cable lengths, and so on become important<br />
only in the geometrical perspective. On the other hand, there are typically requirements that<br />
are important for multiple perspectives. Requirements identified for system functions for example<br />
are important in order to establish justification for proper system design. Satisfaction<br />
of those requirements can however often not be established in the functional perspective, e.g.<br />
due to missing specification of internal behavior. <strong>SPES</strong>MM provides concepts to reason about<br />
requirements across different perspectives, and to establish the corresponding relations.<br />
Abstraction Levels The same problems that occur with respect to reasoning about contracts<br />
across different perspectives hold for abstraction levels. When a system is designed incrementally,<br />
the same system is represented at different levels of granularity. Although various refinement<br />
steps can be established by decomposition of components, there are other cases where<br />
changing the abstraction level is more appropriate. This may be simply due to organizational<br />
boundaries, where different departments in a company are responsible for certain subsystems.<br />
A more formal reason is the fact, that refinement not always follows a decomposition approach,<br />
but demands for more complex m-to-n relations.<br />
Note that there is no explicit deployment defined for different aspects of components. The<br />
reason for this is, that the specification of different aspects has no direction. Instead, aspect<br />
specifications of a component are often closely and interdependently entangled, and relations<br />
between different aspects of specifications have to be made explicit. An example for multiaspect<br />
specification can be found for example in [18].<br />
4.4.1 Mapping<br />
Since the requirements for creating interfaces between perspectives and between abstraction<br />
levels are very similar, the <strong>SPES</strong>MM introduces the common concept of mapping. Technically,<br />
3 A convenient way to circumvent such problems is to start with a surrounding component that uses decomposition<br />
to achieve the intended result, and that keeps the simple one-to-one relation between functions and logical<br />
components<br />
62/ 156
<strong>Architecture</strong> <strong>Modeling</strong><br />
a mapping is similar to a component. It has interfaces consisting of ports, and it has internal<br />
behavior defined in terms of an HRC state machine. Its interfaces are however not used for<br />
interaction with other components but to relate different models. As Figure 4.10 shows, a mapping<br />
connects (arbitrary) ports of two different models of a design. Mappings are asymmetric<br />
in that the roles of connected model artifacts are different. A mapping can be considered as an<br />
observer of one of the participating models. In Figure 4.10 for example, the depicted mapping<br />
“observes” the behavior of component S of the right hand model. Due to its internal behavior,<br />
a mapping provides a well defined (possibly modified) view to the behavior of the “observed”<br />
model. More important, the observer approach gives means to the fact, that models of a design<br />
are closely related to each other. Model artifacts within a perspective at a certain abstraction<br />
level are allocated to artifacts of other perspectives, and artifacts at a lower level are considered<br />
to realize those of a higher abstraction level. In this sense, a mapping provides the foundation<br />
to reason about satisfaction of an observing model by another (observed) model.<br />
Logical Perspective<br />
temp occurs each<br />
50ms<br />
temp<br />
Delay between temp and control within<br />
[20ms,25ms]<br />
AirTempSystem<br />
control<br />
Mapping<br />
Technical Perspective<br />
tempVal<br />
temp<br />
temp<br />
Data<br />
control<br />
Var1<br />
ECU<br />
Capture<br />
Task<br />
Figure 4.10: Mapping Example<br />
Scheduler<br />
airTemp<br />
CtrlTask<br />
Technically, a mapping can be used to “replace” components within the observing model, as<br />
depicted in Figure 4.11. While replacing, the mapping gets associated with the set of contracts<br />
that have been associated to the replaced components. This gives means to the proof obligation<br />
corresponding to the question whether the observed model satisfies the contracts defined for the<br />
observing model. In fact, the situation is very similar to those of virtual integration testing. If<br />
the resulting system, containing the mapping and the observed model, is considered as a single<br />
component as shown in Figure 4.11, the same proof obligations apply as for VIT. However,<br />
refinement has to be shown not for the composition of all contracts in the observed model, but<br />
only for the composition of those contracts that are associated to components having links to the<br />
mapping. The result is that, whenever the contracts of the components of the observed model<br />
are satisfied, then the contracts of the observing models are also satisfied with respect to the<br />
internal behavior of the mapping.<br />
Mappings thus provide well-defined interfaces between artifacts of models within different<br />
perspectives and abstraction levels. However, the corresponding proof obligations are valid only<br />
with respect to the behavior of the mapping. Mapping can for example be used to perform interface<br />
refinement. The upper part of Figure 4.12 shows a component with an outport providing<br />
some integer valued data. At the next lower abstraction level, the same component has a refined<br />
port providing 3-Bit digital data. The mapping shown in the figure “converts” the 3-Bit values<br />
of the refined component into (more abstract) integer values. In this example, the internal be-<br />
Var2<br />
tempSel<br />
63/ 156
temp occurs each<br />
50ms<br />
Delay between temp and control within<br />
[20ms,25ms]<br />
<strong>Architecture</strong> <strong>Modeling</strong><br />
Mapping<br />
Technical Perspective<br />
tempVal<br />
temp<br />
temp<br />
Data<br />
control<br />
Var1<br />
ECU<br />
Capture<br />
Task<br />
Scheduler<br />
Figure 4.11: Mapping: Proof Obligations<br />
airTemp<br />
CtrlTask<br />
havior of the mapping provides the necessary conversion in order to reason about the intended<br />
refinement relation between both representations of the component. Due to internal behavior of<br />
the mapping, confidence of the result of a refinement check also depends on the faithfulness of<br />
the mapping. For sake of traceability, mappings can be associated with contracts to allow formal<br />
specification of their behavior. When proof obligations are violated during the design process,<br />
mapping contracts may give means to reason about the faithfulness of the chosen behavior of<br />
the involved mappings.<br />
€<br />
€<br />
temp ∈ IN<br />
temp = 4⋅ temp 2 + 2⋅ temp 1 + temp 0<br />
€<br />
temp0 ,temp1 ,temp2 ∈{0,1}<br />
Capture<br />
AirTempSystem<br />
tempData<br />
control<br />
AirTempControl<br />
Figure 4.12: Mapping with Interface Refinement<br />
Two properties are essential when dealing with mappings:<br />
Completeness Contracts are always associated to components. More precisely, contracts are<br />
restricted to reason about the interface of the associated component. In order to obtain welldefined<br />
relations between contracts, mappings are required to establish port relations that are<br />
complete with respect to all associated contracts. If for example in Figure 4.10, only the right<br />
port of component AirTempSystem would be linked to the mapping, the component could<br />
not be replaced without provoking inconsistency of the model.<br />
Receptiveness Mappings are required to be receptive. Their internal behavior must not restrict<br />
any contracts of the observed model.<br />
control<br />
Var2<br />
tempSel<br />
64/ 156
<strong>Architecture</strong> <strong>Modeling</strong><br />
Another important issue when dealing with mappings is locality. Since there are no constraints<br />
in the number of mappings to link certain models, it should be best practice to keep the<br />
number of linked ports for a mapping as low as possible. The benefit it twofold: on one hand,<br />
locality maintains traceability on the relation between contracts of different models. On the<br />
other hand, it supports also locality of the respective proof obligations. However, each mapping<br />
must be verified.<br />
4.4.2 Allocation<br />
While mappings provide the common concept to establish traceability in a design, the <strong>SPES</strong>MM<br />
provides two instantiations of this concept. An allocate link associates two components within<br />
different perspectives. The intuition of an allocate link is that the source component is “executed”<br />
by the target component of the link. A function is executed by a logical component, and<br />
a logical component is executed by a technical component. The intuition also holds if we say<br />
that a technical component is “executed” by a box in the geometrical perspective.<br />
The allocate link is a high-level construct in that for each link an underlying mapping is<br />
created. Each allocate link thus requires further specification with respect the underlying mapping.<br />
In many cases however, simple mapping functions are sufficient to define allocations.<br />
<strong>SPES</strong>MM allows to refine allocate links by additional links specifying simple one-to-one relations<br />
between ports, and by textual specification of such one-to-one relations within the mapping<br />
object.<br />
Figure 4.13 depicts an example for using the allocate link. The link shown allocates logical<br />
component Capture to task CaptureTask in the technical perspective. The link is associated<br />
to a mapping object that has been further refined (not shown in the figure) to specify that<br />
the respective ports are directly linked.<br />
Logical Perspective<br />
temp tempData<br />
Capture<br />
4.4.3 Realization<br />
<br />
AirTempControl<br />
control<br />
Technical Perspective<br />
tempVal<br />
temp<br />
temp<br />
Data<br />
control<br />
Var1<br />
ECU<br />
Capture<br />
Task<br />
Figure 4.13: Allocate-Link Example<br />
Scheduler<br />
airTemp<br />
CtrlTask<br />
The second high-level construct are realize links that associate components between different<br />
abstraction levels. Since the realize link is the twin of the allocate link, the same holds as said<br />
before.<br />
Note however, that the direction of both allocate and realize links are converse. For realize<br />
links, the source component by convention associates the observed components with respect to<br />
Var2<br />
tempSel<br />
65/ 156
<strong>Architecture</strong> <strong>Modeling</strong><br />
the underlying mapping, while for allocation links, the observed components is denoted by the<br />
link target.<br />
temp<br />
AirTempSystem<br />
<br />
temp tempData<br />
Capture<br />
control<br />
AirTempControl<br />
control<br />
Figure 4.14: Realize-Link Example<br />
66/ 156
5 Using the <strong>Architecture</strong> Meta-Model<br />
Design processes for embedded systems applications differ strongly within the range of application<br />
domains considered in <strong>SPES</strong> <strong>2020</strong>. In automation applications, the geometric layout of<br />
the plant is determined early in planning stages, and defines boundary conditions for other design<br />
phases. In contrast, while of course medical devices such as pace-makers must ultimately<br />
fit into a physical packaging easily insertable into the body, other aspects such as algorithm<br />
design are more dominant. Similarly, almost no industrial application will be developed purely<br />
top-down, nor purely bottom-up, and tradeoffs such as between optimizing re-use and optimizing<br />
for performance will determine the middle-out design strategy for a particular product<br />
development. Finally, target architectures are often subject to domain specific standards, such<br />
as AUTOSAR [9] in the automotive domain, and IMA in avionics, calling for a need to support<br />
a variety of domain specific standards within the <strong>SPES</strong> <strong>Architecture</strong> Metamodel. The purpose<br />
of this section can thus not be to describe something as “the <strong>SPES</strong> design process”. Rather, the<br />
purpose of this section is to show how a broad variety of design styles and design processes can<br />
be naturally expressed using the key concepts of the <strong>SPES</strong> <strong>Architecture</strong> Metamodel.<br />
An orthogonal aspect covered in this section relates to the advocation of a contract-based<br />
design style. We highlight, how typical design steps in industrial processes can benefit from<br />
contract-based design, thus motivating the anchoring of this design paradigm in the <strong>SPES</strong> metamodel.<br />
We cover these orthogonal aspects in separate sections. The style of writing is chosen so as<br />
to address a typical systems engineer. Having read the quick tour (Section 2) is an indispensable<br />
prerequisite for this section. Readers who are interested in more formal treatments of the<br />
mentioned design steps are referred to Section 4 – “Steps in component based design” – and its<br />
mathematical foundation given in the annex.<br />
5.1 On the Role of Perspectives and Abstraction Layers<br />
5.1.1 What We Can Learn from the EDA Domain<br />
Electronic design automation (EDA) has early adopted the concept of abstraction layers (to cope<br />
with complexity) and perspectives (there called “domains”) to achieve separation of concerns<br />
between different views of an integrated circuit, such as its physical layout, its logical architecture,<br />
and its behavior (see Gajski’s Y-Chart [25]). Established abstraction levels include (from<br />
lower to higher) the transistor level, the gate level, the register transfer level, the system level,<br />
and the instruction-set architecture level. Each level is essentially characterized by what is seen<br />
as a primitive building block at the chosen level of abstraction. The identity of the building<br />
block is obvious from the level name for the transistor and the gate level. For the register transfer<br />
level, these blocks include both combinational circuits such as adders, multipliers, shifters,<br />
etc., as well as sequential circuits such as latches, registers, register-files, and the various types<br />
of memory. The naming of the next higher level is predominantly used in the domain of computer<br />
architecture design, where clock-cycle accurate models describe the effect of executing<br />
instructions on the visible processor state. The term system-level, then, traditionally referred to<br />
67/ 156
<strong>Architecture</strong> <strong>Modeling</strong><br />
the organization of the overall computer system, in terms of CPUs, MMUs, bus-systems, I/O,<br />
caches, memory etc. Note that this layering also motivates the wording of “abstraction layers”.<br />
In fact, different design styles for integrated circuits are characterized by what abstraction<br />
level is taken as a design basis. E.g., in gate-level design, a higher degree of automation is<br />
achieved by taking gates as primitives (from a design library), while full-custom design processes<br />
capitalize on the capabilities of building custom complex gates from transistors, and<br />
most notably from the capability of optimizing the layout of individual transistors to optimize<br />
performance. In contrast, in gate-level design, the internal realization of employed gates is<br />
completely hidden, and designs are build purely based on characterization of such standards<br />
cells as given in design libraries. Note also, that the type of underlying computational models<br />
differs drastically between design levels. As an example, differential equations are used as<br />
models to characterize how the transistor current is dependent on various parameters such as<br />
the gate-to-source voltage, or the drain-to-source voltage. In contrast, at gate level design, such<br />
continuos dynamics are abstracted to a boolean, discrete time domain, e. g. for gates and other<br />
combinational circuits to boolean functions and maximal and minimal propagation delays.<br />
Perspectives (in EDA jargon: domains) are orthogonal to these. The geometric perspective<br />
(in the EDA domain, sometimes also called “physical domain”) speaks about the physical realization<br />
of the integrated cuircuit. E.g. on the transistor level, the physical dimensions of all<br />
materials used to realized transistors, such as the gate’s aspect ratio, the thickness of the insulation<br />
layer below the gate, the extension of drain and source, but as well the routing of wires<br />
on the layers of the integrated circuits and their physical dimensions etc. are described in a<br />
standardized way allowing automatic production of the integrated circuit. With increasing integration<br />
density, the system-level, which in the 80’s would talk about placement of ICs and their<br />
interconnections on the printed cuircuit board, has moved to the level of on-chip positioning of<br />
multiple processor cores, on-chip interconnection networks, on-chip cache hierarchies, etc. In<br />
short, the geometric perspective covers all abstraction layers, and allows to physically build the<br />
complete system, using the blue-prints or the physical realization of lower abstraction levels.<br />
The information of what components, then, are to be built, and, in particular, how they are<br />
connected comes from the technical perspective. Here, the focus is on architecture: how can<br />
we architect a modern processor from RT-primitives supporting multiple-issue of instructions,<br />
out-of-order execution of multiple instructions using multiple functional units and multi-port<br />
register files, etc. This design is typically done not only using abstraction (that is, through the<br />
concept of abstraction layers), but also by disregarding the physical realization of the system,<br />
i. e. the geometrical perspective. This conscious choice of (initially) ignoring the geometric domain<br />
comes with a price: clearly extra-functional characteristics of the integrated cuircuit are<br />
highly dependent on the physical layout, and thus any analysis e. g. of timing aspects is only<br />
indicative, since it typically ignores propagation delays induced by routing, and delay characteristics<br />
of library elements are based on assumptions on capacities which can only be checked<br />
in the physical domain. Yet, in spite of these caveats, and the lack of a formally establishable<br />
link between extra-functional aspects in the technical perspective and the counterpart in the<br />
physical perspective, industrial practice shows, that the productivity gains obtained by initially<br />
disregarding the impact of the geometric domain by far outweigh the costs coming from patches<br />
required to compensate for non-tolerable changes in such characteristics.<br />
Finally, the behavioral domain is used, at each of the above abstraction layers, to capture the<br />
specification of what the component of the circuit should do. Examples include the specification<br />
of an instruction-set architecture, of caches, of a multiplier, of a complex gate, or, at the lowest<br />
level, “Kennlinien”, i. e. curves characterizing the desired dependency of the drain-to-source<br />
current in terms of other parameters.<br />
68/ 156
<strong>Architecture</strong> <strong>Modeling</strong><br />
Design processes can then be described as trajectories in a two-dimensional design space<br />
spanned by abstraction levels as horizontal dimensions and the three perspectives focussing on<br />
behavior, architecture, and geometry as vertical dimensions. Typical steps include:<br />
• Synthesis: This starts with a behavior specification on level N and produces a technical<br />
architecture on level N-1, i. e. shows how primitives of level N-1 can be interconnected to<br />
realize the level-N behavior specification by combining the lower level components based<br />
as prescribed in the level-(N-1) architecture.<br />
• Analysis: Takes a level-(N-1) netlist and “computes” the emergent behavior at level N.<br />
• Implementation: Shows how to realize a level-N component in the physical domain.<br />
• Integration (placement and routing): Combines level-(N-1) layouts of level-(N-1) components<br />
according to a level-(N-1) architecture to build an implementation of a level-N<br />
component.<br />
In platform based design, we pick some abstraction level N as design basis, and assume as<br />
given a library of level-N components, where each library element is given in all three perspectives<br />
and characterized w.r.t. all aspects required for a complete automation of the design<br />
processes (e. g. required voltage levels, leak currents, propagation delays etc). The determination<br />
of the design basis comes from trade-off analysis involving costs, performance, design<br />
time, etc. Clearly, lowering the design basis allows higher levels of optimization, at the price<br />
of increased design time. Hence, even for one and the same application, the actual design<br />
process will be determined by business constraints. Moreover, this shows the need to address<br />
both library design and application design. We finally notice, that the degree of automation of<br />
synthesis and analysis steps is increasing when moving to lower abstraction layers, as does the<br />
automation of placement and routing. Implementations today are largely either given by design<br />
libraries or derived with placement and routing. In incremental design, only parts of the system<br />
are re-designed, in a way striving to minimize the impact of this re-design on the surrounding<br />
components. Standardization and in particular standardized bus systems and interfaces are key<br />
instruments allowing to completely localize the effect of such component replacements.<br />
All of these have contributed to an exponential productivity boost in the EDA domain, allowing<br />
so far (by adding higher and higher abstraction levels, such as Transaction Level <strong>Modeling</strong>)<br />
to compensate the exponential growth in functionality realized in integrated circuits.<br />
5.1.1.1 What We Want to Achieve for Embedded-Systems Based Product Development<br />
We expect to achieve similarly productive boosts for embedded-system design through the introduction<br />
of the architecture meta-model based on abstraction layers and perspectives in combination<br />
with the contract-based multi-aspect component based design technique of Hierarchical<br />
Rich Components, which allows to build design libraries at any abstraction layer, supporting all<br />
phases of embedded systems product development. The large number of domain specific standardization<br />
activities in Embedded Systems design (such as AUTOSAR, IMA) gives clear evidence<br />
of the industrial drive to boost productivity through standardized interfaces, standardized<br />
meta-models, and standardization of non-differentiating design components. Different design<br />
styles (or, in “our” jargon, different design processes) can again be captured by different trajectories<br />
in this richer design space. Concepts such as platform based design, synthesis, placement<br />
and routing, etc., have natural counterparts. For the geometric domain, vendors of CAD and<br />
PLM tool suites have gone a long way in providing industry strength design automation support,<br />
69/ 156
<strong>Architecture</strong> <strong>Modeling</strong><br />
and are gradually enlarging their scope towards other perspectives, such as reflected in the move<br />
by Dassault Systems 1 to integrate UML modeling tools, or their recent acquisition of Geensoft.<br />
Vendors of modeling and specification tools offer increasingly higher abstraction levels supported<br />
with simulation, analysis, and synthesis capabilities, and are increasingly opening their<br />
tools to allow integration into tool chains to cover the complete design space. Environments<br />
such as Eclipse have been instrumental in such tool integration activities.<br />
5.1.2 Perspectives and abstraction layers in system-level design<br />
The geometric perspective is offered to cover the physical layout of the system-underdevelopment.<br />
As mentioned above, this is the classical domain of tools such as CATIA 2 or<br />
the Siemens PLM suite 3 . While clearly the 3D design of products is out of scope of <strong>SPES</strong>, the<br />
constraints coming from this, and in particular the concrete positioning of components of the<br />
technical architecture as well as their interconnection, are of key relevance, since they impact<br />
non-functional aspects and induce locally constraints.<br />
Within the technical perspective, we propose to capture all design artifacts which jointly<br />
support the realization of a new product function and which have a one-to-one correspondence<br />
to physical entities in the geometric domain. By the fact that system-development processes<br />
address the realization of functions of the complete product under given quality requirements<br />
(notably safety), all aspects of hydraulic and mechanical subsystems relevant to achieving this<br />
must be assessed to a level of detail ensuring sufficient observability by the supporting embedded<br />
systems to assess their health status and react to this. Thus, at higher abstraction levels, the<br />
internal realization of a system in terms of mechanical, hydraulic, and electronic subsystems are<br />
visible, in our proposal as rich components, thus not only specifying interfaces between these,<br />
but as well for all relevant aspects of the design contracts formalizing what each subsystem is<br />
assuming to be guaranteed by other subsystems. E.g. for the safety aspect, such contracts would<br />
characterize the class and probabilities of failures assumed by the electronic subsystem both wrt<br />
the mechanical and the hydraulic subsystems.<br />
Within the scope of <strong>SPES</strong>, we would assume that lower abstraction layers focus on refining,<br />
then, the internal structure of the electronic subsystem. At some layer (which in the EDA<br />
domain was called the system layer), this would e. g. depict the electronic architecture of a<br />
car, in terms of a FlexRay backbone bus 4 , interconnected via bridges to subsystems dedicated<br />
to specific “domains” such as body electronic, power-train, infotainment, stability, etc. with<br />
domain specific bus-systems, as well as the electronic control units and intelligent sensors and<br />
actuators linked to these, and employ the AUTOSAR meta-model to characterize these as well<br />
as the computing resources inside electronic control units.<br />
Within the operational perspective, we suggest, for each level of abstraction, to capture the<br />
interactions at the system boundary of the system under development. This includes, on the<br />
highest “product” level, a specification of the operational scenarios which must be supported<br />
by the product (hence the naming of the perspective), such as the different classes of missions<br />
for a military aircraft, or the characteristics and variances of product processes to be supported<br />
in product automation applications. Other examples of operational scenarios to be supported<br />
relate to maintenance, or to the production of the product itself (to identify requirements on<br />
the design enabling particular production steps). In general, in this perspective and at this<br />
1 http://www.3ds.com/<br />
2 http://www.3ds.com/catia<br />
3 http://www.plm.automation.siemens.com/en us/products/teamcenter/<br />
4 http://www.flexray.com/<br />
70/ 156
<strong>Architecture</strong> <strong>Modeling</strong><br />
abstraction level, we identify all stakeholders impacting the design of the product and analyze<br />
product requirements stemming from their interaction. Note that stakeholders include humans,<br />
such as human operators, cabin crew, maintenance staff. In systems-of-systems applications,<br />
stakeholders include interfaces to other systems (such as in car2X applications) or supervisory<br />
control (such as to flight control).<br />
A requirements analysis processes could, as final outcome, yield a formalized specification<br />
of the interface between the product and its stakeholders, in terms of contract specifications, for<br />
all aspects induced from operational and business requirements, which from then on take indeed<br />
the form of binding requirements, whose realization must be traceably supported in subsequent<br />
design steps.<br />
At lower abstraction levels, the interfaces between identified stakeholders and the product<br />
itself are refined, both in terms of representation of information and protocol.<br />
We propose to use two perspectives to close the gap between the operational and the technical<br />
perspective.<br />
The first, functional perspective is used to refine our understanding in what it takes to realize<br />
the product functions identified in the operational perspective. This is the scope of classical<br />
functional analysis methods, using both hierarchy and abstraction layers to break down toplevel<br />
functions to a level allowing a detailed assessment of their compliance to requirements<br />
identified in the operational perspective. As functions are decomposed into subfunctions, requirements<br />
on these (in terms of contracts) are identified. This is also the scope of classical<br />
V&V approaches ranging from simulation to testing to formal verification for requirement validation<br />
and verification.<br />
The second perspective, called logical perspective, re-groups design entities of the functional<br />
perspective such that locality in logical architecture corresponds to locality in the technical architecture.<br />
As an example, consider the design of an advanced driver assistance system using<br />
cooperative vehicle control strategies for highway entry, realizing a safe, smooth, and semiautonomous<br />
highway entry. Subfunctions include multi-channel sensor fusion (video, ladar,<br />
radar, wireless communication from roadside infrastructure and other vehicles) to build a mental<br />
map of the actual traffic situation, real-time scenary analysis with motion estimation, strategy<br />
determination, decision modules for invocation of semi-autonomous driving services such<br />
as car-following, lane keeping, lane changing, driver interface, etc. Within the logical architecture,<br />
leaves of the resulting function hierarchy would be regrouped to reflect the partitioning into<br />
different subsystems of the car’s electronic architecture, where subfunctions with close proximity<br />
in the functional architecture become separated e. g. due to the integration of the different<br />
sensors in one subsystem, and stability control in another subsystem.<br />
We suggest to refine the logical architecture to a level allowing to express the allocation of<br />
entities of the logical architecture on computation and communication resources of the technical<br />
architecture on a per-component basis. E.g. for the automotive domain this entails, that the<br />
structure of a software component as being composed of runnables is visible in the logical<br />
architecture, i. e. runnables appear as components.<br />
Discussions in <strong>SPES</strong> have shown, that the number of abstraction levels can not be uniformly<br />
determined for all application domains, but should be customizable for a given design process.<br />
Much as in EDA design, abstraction layers are characterized by the components to be considered<br />
primitive in the technical perspective, with other perspectives then containing components<br />
as primitives which relate to such primitive components of the technical perspective. E.g. at<br />
system level, we consider electronic control units as primitives in the technical perspective.<br />
Counterparts on the logical perspectives are then software components, which map to tasks in<br />
the technical perspective, such as those realizing control loops. A corresponding component in<br />
71/ 156
<strong>Architecture</strong> <strong>Modeling</strong><br />
the functional perspective would specify the desired control function.<br />
We expect at a minimum abstraction levels to be used at interfaces between subprocesses<br />
along the supply chain hierarchy. Additional abstraction levels can be chosen depending on the<br />
tradeoff between design time and optimization needs – as discussed in the next section.<br />
5.1.3 Example<br />
In the following, the application of the primitive steps in component-based design presented in<br />
section 4 is shown with the aid of a common example used in aeronautics case studies.<br />
First, in section 5.1.3.1 the example of a wheel braking system is presented with a general<br />
description of its functionality and a schematic overview. To demonstrate the different concepts<br />
we walk exemplarily through the design process starting in section 5.1.3.2 with snapshots<br />
of combinations of perspectives and abstraction levels. After that, the primitive design steps<br />
decomposition, allocation and realization are shown exemplarily at selected parts of the previously<br />
presented model snapshots. In section 5.1.3.3, we elaborate on the question of how an<br />
allocation-link of components of the logical and technical perspective could be proved using<br />
a virtual integration test by means of realtime contracts. Finally, we show in section 5.1.3.4<br />
how the fourth primitive step implementation could be proven by a satisfaction-check against<br />
a safety contract using fault-tree analysis. Here, the main purpose is not to give an overview<br />
on safety analysis but to show how such methods can be integrated in the <strong>SPES</strong> methodology.<br />
Finally, in section 5.1.3.5 we introduce a fourth level of abstraction, the Unit Level, to show<br />
exemplarily how realtime contracts may be checked using scheduling analysis.<br />
5.1.3.1 Aeronautic Example: Wheel Braking System<br />
The Wheel Braking System (WBS) described in the ARP 4761 [5, p. 168 to 280] is a common<br />
example used in aeronautics case studies. The WBS is supposed to decelerate the aircraft on the<br />
ground by controlling the hydraulic pressure for the wheel brake actuators. The central control<br />
unit of this system is called the brake system control unit (BSCU). In Figure 5.1 a schematic<br />
overview of the WBS introduced in the ARP 4761 is depicted containing control units as well<br />
as hydraulic and mechanical elements. Therefore, in the <strong>SPES</strong> context this figure would be part<br />
of the technical perspective while the BSCU is modeled at a very high abstraction level.<br />
The system operates two independent hydraulic circuits connected to each wheel of the<br />
aircraft and in three different modes Normal, Alternate and Emergency which will be supplied<br />
by either the green or the blue hydraulic lines or by the reserve offered by an accumulator. The<br />
Selector Valve located in both the green (Normal) and blue (Alternate) line guarantees that only<br />
one of the lines can propagate hydraulic pressure. If both lines are operational, the green one is<br />
passed through. Switch over to the blue line occurs if either the green pressure fails, the BSCU<br />
becomes in-operational (green pressure is cut off at Shut-Off Selector Valve) or if it is explicitly<br />
selected by the pilot (not shown in the figure). The default mode of operation is Normal mode.<br />
In this mode the aircraft can decelerate either automatically or manually by the pilot. In both<br />
cases the BSCU generates the necessary control and anti-skid commands for the Meter Valve<br />
in the green hydraulic line that operates individual hydraulic pistons located on every wheel. If<br />
a switch-over to Alternate mode occurs (see above) automatic braking is not possible. The rate<br />
of deceleration is controlled by the pedals and transmitted mechanically to the respective meter<br />
valve. The hydraulic pressure is transmitted to an independent set of brake pistons operating<br />
on sets of wheels. If the BSCU is still working, it will provide anti-skid commands via the<br />
Anti-Skid Shut-Off Valve. When the system is in Alternate mode and pressure to the blue line<br />
72/ 156
Pwr1 Pedal_Pos1 Pwr2 Pedal_Pos2<br />
CMD_AS1<br />
BSCU<br />
Monitor 1<br />
BSCU1<br />
AS1<br />
Valid1<br />
Valid2<br />
Valid_<br />
Switch<br />
Monitor 2<br />
BSCU2<br />
Command 1 Command 2<br />
CMD_AS2<br />
AS2<br />
Select_Switch<br />
<strong>Architecture</strong> <strong>Modeling</strong><br />
Valid<br />
AS<br />
CMD_AS<br />
Shut Off<br />
Selector<br />
Valve<br />
Green<br />
Pump<br />
Normal<br />
Meter<br />
Valve<br />
Isolation<br />
Valve<br />
Selector<br />
Valve<br />
Anti Skid<br />
Shut Off<br />
Valve<br />
Meter<br />
Valve<br />
Blue<br />
Pump<br />
Figure 5.1: Schematic Overview of the Wheel Braking System<br />
Alternate<br />
Reserve<br />
Accumulator<br />
Mech Pedal Position<br />
Wheel<br />
fails it switches to Emergency mode. In this mode the pressure is supplied via an accumulator.<br />
Due to the limited capacity it is not possible to apply and release the brakes multiple times so<br />
that it must be ensured that Anti-Skid Shut-Off Valve is disabled.<br />
Please note, that the models we are presenting in the following sections might slightly<br />
differ in some details from the ARP 4761 and that we do not show each perspective on each<br />
abstraction level for the sake of brevity.<br />
5.1.3.2 Abstraction Levels, Perspectives and Design Steps<br />
In this section, we present how the wheel braking system is modeled on three abstraction levels<br />
(Aircraft Level, System Level, Device Level) using the <strong>SPES</strong> architecture modeling concepts.<br />
A fourth abstraction level named Unit Level is described in section 5.1.3.5. The example currently<br />
covers four different perspectives starting with the operational perspective on Aircraft<br />
Level where user-activities and actors that operate the system are identified. This is usually the<br />
first design-step we consider in this framework and builds the reference for succeeding phases.<br />
When all needs of operational actors are acquired, in the functional perspective the functions<br />
are modeled that realize the operational activities. Furthermore, these functions may be decomposed<br />
into subfunctions. In the logical perspective logical components are defined that realize<br />
the functions identified in the previous step. A technical perspective is not part of the Aircraft<br />
Level.<br />
On the System Level, the logical architecture is refined by decomposition and an initial technical<br />
architecture is proposed that is refined at the Device Level by adding redundant components<br />
due to safety reasons.<br />
73/ 156
<strong>Architecture</strong> <strong>Modeling</strong><br />
Figure 5.2: Operational Perspective – Abstraction Level 1 – Top Level<br />
Operational and Functional Perspective The intention of the operational perspective (as introduced<br />
in Section 3.2.1) is to model the interaction of different actors with the system under<br />
development using (operational) activities. The top level component of the operational perspective<br />
of the Aircraft Level is depicted in Figure 5.2. It shows a component systemcontext<br />
which contains the system under development, that is Aircraft here, and all actors that interact<br />
with this system. In this simple example we have just one actor namely the Pilot.<br />
This actor interacts with the system via different ports e.g. to control the thrust-reverser or the<br />
landing gear.<br />
Figure 5.3: Operational Perspective – Aircraft Level – Aircraft<br />
Having a closer look into the Aircraft system in Figure 5.3 shows a main activity named<br />
DecelerateOnGround. This complex activity offers different ways to decelerate the aircraft<br />
on the ground. This is expressed by a further decomposition of this activity into subactivities<br />
shown in Figure 5.4.<br />
First, there is the need to extend the landing gear before landing which is represented<br />
by the activity ControlLandingGear. Furthermore, the forward thrust need to be removed<br />
to reduce speed before touching down (RemoveForwardThrust). The activities<br />
that model the actual braking process are the primary and secondary stopping force.<br />
74/ 156
<strong>Architecture</strong> <strong>Modeling</strong><br />
Figure 5.4: Operational Perspective – Aircraft Level – Decelerate on ground<br />
Here, the primary stopping force (ControlPrimaryStoppingForce) is realized by the<br />
wheel brake system which is controlled by brake pedals. The secondary stopping force<br />
(ControlSecondaryStoppingForce) is implemented by a thrust-reverser. The activity<br />
DecelerateOnGround is annotated with a system requirement ARP-ACFT-R-0009<br />
which asks for the existence of such a functionality. By this means, it is documented that this<br />
requirement is realized by this activity.<br />
Figure 5.5: Functional Perspective – Aircraft Level<br />
In the functional perspective (as introduced in Section 3.2.2) of the Aircraft Level shown in<br />
Figure 5.5, the user-demands from the operational perspective are depicted as top level functions<br />
and decomposed into finer grained subfunctions proposing how these functions should be<br />
75/ 156
<strong>Architecture</strong> <strong>Modeling</strong><br />
realized. The top level function relevant for the system we consider here, is the need for a primary<br />
stopping force (coloured in green) whose subfunction is the wheel braking system itself<br />
(coloured in blue). This function is further decomposed into an antiskid function, a parking<br />
brake function, an automatic brake function (autobrake) and a hydraulic brake control function<br />
(each coloured in red). Please note that this is a decomposition step on the same abstraction<br />
level. The top level function is here annotated with the same requirement as the appendant<br />
Figure 5.6: Functional Perspective – Aircraft Level – Contracts of subfunctions<br />
acitivity of the operational perspective. Figure 5.6 shows further requirements that the subfunctions<br />
need to satisfy.<br />
Logical Perspective To illustrate the modeling of logical perspectives (as introduced in Section<br />
3.2.3) we have a look at the logical perspective of the Aircraft Level in Figure 5.7. It<br />
shows that the wheel brake system should be realized by one top level component that offers a<br />
number of input ports as the rudderPedalPosition and parkingBrake from the cockpit<br />
or aircraftSpeed and altitude from external sensors. This logical component is<br />
annotated with several requirements that we know from the previous perspectives.<br />
To have a closer look into the structure of the wheel brake system, we proceed to the second<br />
abstraction level i.e. the System Level where the wheel brake system is refined. On the one hand,<br />
it is decomposed into subcomponents and on the other hand some additional ports were added.<br />
A snapshot of the top level architecture of this level is depicted in Figure 5.8. The wheel braking<br />
system contains a logical component realizing the BSCU (BrakingSystemControlUnit)<br />
on the left hand side receiving sensor inputs from other aircraft systems and commands<br />
from the cockpit. Based on these inputs and the internal status of the wheel braking system<br />
(wheelBrakeStatusInformation) control signals for the different actuator valves<br />
are computed. The actuators are represented each by one logical component in the middle<br />
of the figure. To determine the overall status of the wheel braking system there exists the<br />
SystemStatusAggregator component that collects the status signals of each actuator<br />
component and returns them as wheelBrakeStatus back to the BSCU (internal) and offers<br />
it to other systems of the aircraft (external).<br />
76/ 156
<strong>Architecture</strong> <strong>Modeling</strong><br />
Figure 5.7: Logical Perspective – Aircraft Level<br />
To show the concept of contract-based design some components are annotated exemplary<br />
with contracts using the satisfaction-link. Contracts are depicted throughout this example as a<br />
pair of green and blue boxes where the green box contains the strong assumption As and the blue<br />
box the guarantee G. The weak assumption Aw is for this and the following figures always true<br />
and thus not shown explicitly. To be able to reference contracts, each contract has an identifier<br />
annotated in the upper left corner. For example, C1 claims that if the assumption that the<br />
pedalPosition is within certain bounds is fulfilled, it is guaranteed that meterControl<br />
always occurs within an interval of 0 and 4 milliseconds after pedalPosition has occurred.<br />
Furthermore, it is guaranteed that meterControl is again within certain specified bounds.<br />
Technical Perspective While staying at the same abstraction level, we will now have a look<br />
at the technical perspective (as introduced in Section 3.2.4) of the system in Figure 5.9. Here,<br />
the BSCU is shown again on the left hand side as a computing resource. In contrast to the logical<br />
perspective where actuators are modeled as one logical component, in the technical perspective<br />
there are the actual hydraulic actuators modeled as actuator components and their driver units as<br />
computing resources. The driver units mainly have the task to transform the BSCU commands<br />
to signals the actuator can handle. In this snapshot MeterValveCtrl is an example for a<br />
driver unit forwarding signals to the actuator MeterValveActuator. As before, on this<br />
perspective some components are annotated with contracts derived from the contracts on the<br />
logical perspective. How to check if these contracts match is shown in Section 5.1.3.3.<br />
Decomposition Next, we demonstrate the design step of decomposition (as introduced in<br />
Section 4) at the example of the BSCU component in the logical perspective of the System Level<br />
which is depicted in Figure 5.10. The BSCU is decomposed into a Monitor and a Command<br />
component in order do divide the functionality into two different logical units. The Monitor<br />
component observes the state of the system and detects inconsistencies. The Command unit<br />
77/ 156
<strong>Architecture</strong> <strong>Modeling</strong><br />
Figure 5.8: Logical Perspective – System Level<br />
provides control signals to the respective actuators. For a valid decomposition, all input and<br />
output ports of the parent component (which is the BSCU here) have to be linked to their<br />
respective ports of the internal components.<br />
In this decomposition example, the subcomponent Command is annotated with a contract<br />
C1.1 which is here (not in general) the same as the contract C1 of its parent component. The<br />
proof obligation for decomposition is a virtual integration test as shown in Section 5.1.3.3 for<br />
allocation.<br />
Allocation To complete the modeling of one abstraction level, the components of one perspective<br />
have to be associated with components of another perspective. This link was introduced<br />
in Section 4.4.2 as the primitive design step named allocation. This concept is exemplified<br />
in Figure 5.11 for the logical perspective of the System Level, where the logical component<br />
MeterValveActuator is allocated to two components of the technical perspective namely<br />
the computing resource MeterValveControl and the actuator MeterValveActuator.<br />
For a valid allocate-link all ports of the source component have to be mapped to ports of<br />
the target component. In this example, meterControl is mapped to meterValve and<br />
meterValveStatus to valveStatus. In Figure 5.11 again contracts are annotated that<br />
already have been introduced in preceding figures and therefore are only referenced by their<br />
78/ 156
<strong>Architecture</strong> <strong>Modeling</strong><br />
Figure 5.9: Technical Perspective – System Level<br />
identifier. In Section 5.1.3.3 we show for a similar allocation-link how its validity may be<br />
proven by a virtual integration test.<br />
Realization When performing the design step from one abstraction level to the next (lower)<br />
one, a realize-link (as introduced in Section 4.4.3) has to be established to ensure a valid refinement<br />
step. To give an understanding of the idea how a system (part) is realized at a lower<br />
abstraction level, the technical perspective at the Device Level is shown in Figure 5.12.<br />
At this level, the BSCU is realized by three resource components: itsBSCUSelector,<br />
itsBSCUMonCom1, and itsBSCUMonCom2. The reason for splitting the BSCU is due to the<br />
decision to provide the system with redundant command and monitor units to meet safety requirements<br />
(no single point of failure in the BSCU). These can be found in itsBSCUMonCom1<br />
and itsBSCUMonCom2 respectively. The itsBSCUSelector, a combinational logic modeled<br />
as a device resource, selects and forwards the signals to the driver unit of the appendant<br />
actuator. For simplicity, the communication between these three components is represented by<br />
an abstract signal for each component rather than the explicit modeling of the actual signals. In<br />
this snapshot, a contract is shown with a more complex guarantee that contains implications.<br />
The guarantee consists of two parts, each depicted in a blue box, that are connected by a conjunction<br />
∧ (not shown in the figure). The implication is used here to model different modes of<br />
the system i.e. the normal mode in the upper box where the itsBSCUSelector component<br />
79/ 156
<strong>Architecture</strong> <strong>Modeling</strong><br />
Figure 5.10: Logical Perspective – System Level – Decomposition of BSCU<br />
Figure 5.11: System Level – Allocation of Logical to Technical Component<br />
gets input data from itsBSCUBSCUMonCom1 and the emergency mode in the lower box where<br />
the itsBSCUSelector component gets input data from itsBSCUBSCUMonCom2. In both<br />
80/ 156
<strong>Architecture</strong> <strong>Modeling</strong><br />
Figure 5.12: Technical Perspective – Device Level<br />
cases, the guarantee is that the corresponding signals are forwarded via the meterValve output<br />
port with a certain value range. The strong assumption assures that either dataIn1 or<br />
dataIn2 delivers a meterValve value in a given value range.<br />
The realize-link from the technical perspective of the System Level to the same perspective<br />
on the Device Level is depicted in Figure 5.13. This link again may be validated using a virtual<br />
integration test.<br />
5.1.3.3 Proving Allocation for the Realtime Aspect using Virtual Integration Testing<br />
In this section, we will show an example for validating an allocation-link using a virtual integration<br />
test for the realtime aspect. In Figure 5.14 on the left hand side a snapshot of<br />
the logical perspective at Device Level is depicted with one logical component namely the<br />
MeterValveActuator with its in- and output ports. This component has a satisfy-link<br />
to the contract C2.1.<br />
C2.1 claims that, under the strong assumption that the BSCU control signal lies within<br />
certain bounds, the reaction of the meter-valve actuator must occur within 5 milliseconds.<br />
81/ 156
<strong>Architecture</strong> <strong>Modeling</strong><br />
Figure 5.13: Realize Links for BSCU (Iteration from System Level to Device Level)<br />
Such a reaction is observed by the output of the metervalve actuator i. e. when the signal<br />
meterValveStatus has been updated (upd).<br />
On the right hand side of the figure the same snapshot at the same abstraction level is shown<br />
for the technical perspective. In this perspective we differentiate between the driver unit for<br />
the actuator (MeterValveControl) and the actuator itself (MeterValveActuator) as<br />
well as the communication channel (Channel) between them. Furthermore, technical issues<br />
are considered as the environmental temperatures TEMP1 and TEMP2 of the actuator and the<br />
channel where the respective components are specified to work correctly. The temperatures<br />
might be provided by some sensor components that are not shown here.<br />
The logical meter-valve component is allocated to the three depicted technical components<br />
while the allocate-link is defined by a mapping block that maps the ports of one perspective to<br />
ports of the other perspective. The mapping links are depicted in red dotted lines. In this case,<br />
82/ 156
<strong>Architecture</strong> <strong>Modeling</strong><br />
Figure 5.14: Example for proving Allocation by Virtual Integration Test<br />
the ports meterControl and meterValveStatus of the logical perspective are mapped<br />
to the ports meterValve and valveStatus of the technical perspective. The components<br />
of the technical perspective have a satisfy-link to the contracts C2.1-T1, C2.1-T2, C2.1-T3 and<br />
C2.1.2-T3 where C2.1-T1 is relevant for MeterValveControl, C2.1-T2 for Channel and<br />
both C2.1-T3 and C2.1.2-T3 for MeterValveActuator. The composition of these four<br />
contracts has an entailment link to the contract C2.1 of the logical perspective that has to be<br />
ensured.<br />
To prove an allocation-link a virtual integration test may be performed as introduced in Section<br />
4.2 consisting of the two steps of assuring compatibility and refinement.<br />
Compatibility For the scenario from Figure 5.14, we start with the validation of the compatibility<br />
of the three neighbouring components in the technical perspective or, to be more precise,<br />
the compatibility of their annotated contracts. For this, we have to analyze their strong assumptions<br />
and guarantees. Note, that the weak asspumptions do not constrain the compatibility of<br />
systems. In this example, the second part of the guarantee of C2.1-T1 is compatible to the<br />
second part of the strong assumption of C2.1-T2. The same holds for C2.1-T2 and C2.1-T3.<br />
Further, in this example the assumption parts about the temperature do not influence the validity<br />
of the composition of these three components because they are parts of interfaces to other<br />
components.<br />
Refinement As a further step, the entailment-link between the contract on the logical perspective<br />
and the composition of the four contracts on the technical perspective has to be proven<br />
to be a valid refinement. Checking the refinement for this example results in a falsification,<br />
as the strong assumptions of the contracts C2.1-T2 and C2.1-T3 are stronger than the parent<br />
contract C2.1. To be more precise, the assumptions about the temperature cannot be assured<br />
by C2.1. To solve this situation there are at least two possible scenarios. One solution would<br />
83/ 156
<strong>Architecture</strong> <strong>Modeling</strong><br />
be to extend the assumption of C2.1 by the temperature assumptions of C2.1-T2 and C2.1-T3<br />
which would result in a valid entailment-link. Another option would be to assure the temperature<br />
assumptions by contracts of further neighbouring components on the technical level. This<br />
would induce that the temperature assumptions are not any more existent in the composition of<br />
all contracts on the technical perspective leading again to a valid entailment-link to C2.1.<br />
Also, the weak assumption of C2.1.2-T3 leads to a falsification. This problem can be solved<br />
analogous to the above mentioned one of the strong assumptions.<br />
5.1.3.4 Satisfaction-Check for a Safety Contract Against a Component Implementation<br />
In this section, we elaborate on the question of how a satisfaction check for a component against<br />
its contract may be performed for the safety aspect. Satisfaction is the proof obligation for the<br />
primitive design step implementation introduced in Section 4. For this, we consider a requirement<br />
from the ARP 4761 and use the formalized contract to perform a safety analysis to ensure<br />
its satisfaction.<br />
The starting point is the FHA (Functional Hazard Analysis) where a number of failure conditions<br />
are identified for the system and classified with respect to their impact on the system<br />
and the environment (including passengers). These classifications are then used to derive safety<br />
requirements that need to be investigated during PSSA (Preliminary Systems Safety Analysis)<br />
and SSA (System Safety Analysis).<br />
Safety Contract As an example throughout this text we will investigate the following two<br />
safety requirements:<br />
• No single failure shall lead to loss of wheel braking<br />
• Loss of all wheel braking during landing or Rejected Take Off (RTO) shall be less than<br />
5 · 10 −7 per flight.<br />
These two requirements can be rewritten as safety contracts in the following form:<br />
C3 strong assumption -<br />
weak assumption -<br />
guarantee Loss of wheel braking shall not be caused by 1 failures<br />
C4 strong assumption -<br />
weak assumption -<br />
guarantee Loss of wheel braking shall not occur during Phase =<br />
Landing or Phase = RTO with density higher than 5 ·<br />
10 −7 per flight<br />
In order to analyse whether an existing model satisfies these two contracts we first have to define<br />
the failure condition Loss of wheel braking using a functional pattern. In a simple setting such<br />
a formalisation may be done by characterising a safety-critical state (e. g. by specifying that<br />
the pressure of the blue line is above a given limit). In this context we will define a contract<br />
that implements the above requirement using a RSL (Requirement Specification Language)<br />
pattern. The most obvious way to formalise the safety requirement is to state that whenever the<br />
pilot pushes the braking pedals, either the green or the blue line have to supply pressure to the<br />
wheels subsequently.<br />
(Pedal pressed) implies ((Green pressure high) or (Blue pressure high)).<br />
84/ 156
<strong>Architecture</strong> <strong>Modeling</strong><br />
However this does not account for the delay that is introduced when the command is propagated<br />
through the system until it finally reaches the brake actuators. Instead, we use the following RSL<br />
pattern:<br />
whenever<br />
(Pedal pressed holds during [tr (Pedal pressed), 10 ms])<br />
occurs<br />
tr((Green pressure high) or (Blue pressure high))<br />
occurs<br />
during [0 ms, 10 ms]<br />
This pattern states that whenever the brake pedal is pressed for longer than 10 milliseconds<br />
the disjunction from above needs to hold after at most 10 milliseconds. We require the pedals<br />
to be pressed for at least 10 milliseconds in order to avoid situations where the pedal is pressed<br />
and released over and over again. Otherwise, we run into situations, where one of the different<br />
valves along each line is always closed thus blocking the pressure from reaching the wheels.<br />
Failure Injection In order to evaluate the system behaviour in case of failures the model has<br />
to be extended to reflect the non-nominal behaviour of the system. This is accomplished by<br />
injecting a number of (candidate) failures (i. e. failures that might occur) into the model. Again,<br />
a pattern-based approach is used to provide a list of failure-mode templates including stuck-at,<br />
delay, noise, and random failures. When the provided failure-mode patterns are insufficient,<br />
e. g. if the failure affects several model variables in a complex fashion, or the failure makes use<br />
of some internal system mode (degraded system mode), it is possible to apply user-defined failures,<br />
i. e. failures that are defined using the same modeling formalism employed to specify the<br />
nominal system behaviour. In this case, the system ensures that nominal and failure behaviour<br />
is separated by requiring the user to specify an input that triggers the failure.<br />
The behaviour specification of these failures is merged with the original system model and<br />
together they define the extended system model. In the extended model it is possible to switch<br />
individual failures on and off in any order and with any amount of time passing between their<br />
occurrences. When no failure is active the system behaviour is completely determined by the<br />
system model, whereas when one or more failures become active it is altered according to the<br />
specified failure pattern.<br />
The failure injection was applied to the braking system in the following way: Failures of the<br />
electrical and hydraulic power supplies are represented by user-defined failure-modes, since the<br />
supplies are modelled as inputs to the model. A user-defined failure-mode may also be applied<br />
to the manual mode selection thus modelling wrong behaviour of the pilot. Failures occurring<br />
inside the braking system itself are modelled using stuck-at failure modes.<br />
We defined stuck-at failure-modes for a variety of variables. Failures of each of the valves<br />
are modelled using a stuck-at failure-mode with both states (open and close) as possible values.<br />
This way, the failure-mode can force the valve to be stuck in the open position, passing<br />
the incoming hydraulic pressure, or stuck close, blocking the pressure. Similarly, the validity<br />
signals from the BSCU monitors can either be made stuck true or false. Further failure-modes<br />
were created for the braking commands computed by the two redundant BSCU units and the<br />
reference commands the monitoring units compute. Another failure-mode was created to model<br />
the failure of the switch unit inside the BSCU.<br />
Analysis After the safety requirement has been formalized and the system model has been<br />
extended with failure-modes it is now possible to perform a fault-tree analysis (FTA). The re-<br />
85/ 156
<strong>Architecture</strong> <strong>Modeling</strong><br />
sults from the FTA will then be used to show that the contracts C3 and C4 are satisfied. As a<br />
Top-Level Event (TLE) in the FTA we will use the formalisation of the failure condition Loss of<br />
wheel braking.<br />
Figure 5.15: Auto generated fault-tree<br />
The algorithms we are using to perform an FTA are based on formal verification and automatically<br />
compute a set of all failure-combinations that are necessary to reach the TLE. As these<br />
combinations are minimal by construction, they correspond to the minimal cut-sets that are often<br />
used in traditional safety-analysis. The minimal cut-sets are the used as inputs to construct<br />
a fault-tree.<br />
When the fault-tree generation is applied to the braking system using the safety requirement<br />
(Loss of wheel braking) and a subset of the failure-modes described above, the fault-tree shown<br />
in Figure 5.15 is computed.<br />
Sub-tree b) is directly related to the one depicted in the ARP 4761 (page 200), except that<br />
we did not include failure-modes for the electrical power or the failures of the hydraulic system<br />
(except for the pumps). The sub-tree shows that the safety requirement is violated, when all<br />
three modes fail to operate. The reason for the failure of the normal mode is further broken<br />
down to be caused by the failure of the green hydraulic pump or failure of the BSCU units<br />
to command braking. Note that this also occurs, when the BSCU monitors fail to correctly<br />
compute the reference signal, which is covered by the events 5 and 2 in the fault-tree.<br />
86/ 156
<strong>Architecture</strong> <strong>Modeling</strong><br />
The consideration of monitoring failures is also the reason for the generated fault-tree to be<br />
more comprehensive than the one depicted in the ARP, where the occurrence of monitoring<br />
failures seems not to be considered. Sub-tree a) of Figure 5.15 is one of the additional sub-tree<br />
stemming from this fact. The first remarkable observation of this sub-tree is the circumstance<br />
that it only features failures occurring inside the BSCU, i. e. the TLE is reachable without any<br />
failure of the alternate and emergency mode. This is due to the fact that the failure of the monitoring<br />
unit inside the BSCU can inhibit its shutoff, thus preventing the system from changing<br />
to alternate mode.<br />
Results Satisfaction of contract C3 can easily be derived from the list of minimal cut-sets and<br />
it is also shown in the fault-tree. At least two independent failures are required, therefore the<br />
model satisfies C3.<br />
For contract C4 some additional steps are required which we will only briefly sketch here.<br />
First it is necessary to determine the probability for the occurrence of the basic failures. Typically<br />
these are listed on data sheets provided by suppliers of the relevant sub-systems or they<br />
can be derived from empirical data gained from in-service records of similar systems. Once<br />
these values are assembled the probability for the TLE can be computed using the instructions<br />
given in the fault-tree handbook [47].<br />
5.1.3.5 Checking Real-Time Contracts using Scheduling Analysis<br />
In this section, we will show an example of how to check real-time contracts using the OFFIStool<br />
for Scheduling analysis named Orca. For this purpose, we introduce a fourth level of<br />
abstraction: the Unit Level. On this level, there only exist the logical and the technical perspectives<br />
refining the models of the previous abstraction level.<br />
Figure 5.16: Logical Perspective – Unit Level<br />
87/ 156
<strong>Architecture</strong> <strong>Modeling</strong><br />
Unit Level: Logical and Technical Perspectives We start with an overview<br />
on the logical perspective on Unit Level depicted in Figure 5.16. Here, the<br />
BrakingSystemControlUnit is shown as the top level component containing subcomponents<br />
that realize the two channels of the BSCU each consisting of a command<br />
(Command1/2) and a monitor (Monitor1/2) unit. Because command and monitor has<br />
to communicate, there exists a further logical component that realizes the communication<br />
named Com1ToMon1 and Com2ToMo2, respectively. The top level component is annotated<br />
with two contracts specifying deadlines between certain signals. There exists one<br />
contract for each channel saying that under the strong assumption that the input signal<br />
cmd in1/2.cmdFlow occurs each 5 milliseconds, it is guaranteed that the output signal<br />
control out1/2.controlFlow occurs within 3 milliseconds.<br />
Figure 5.17: Logical Perspective – Unit Level – Contracts<br />
The subcomponents of the BSCU each have a contract as well, as shown in Figure 5.17.<br />
These contracts divide the channel deadlines of 3 milliseconds specified for the BSCU into<br />
local deadlines for the three subcomponents of each channel. The deadline for each command<br />
unit is 1200 microseconds, the deadline for communication via the respective component is 400<br />
microseconds and the deadline for the monitor is defined as 1400 microseconds. How these<br />
local deadlines are chosen is a design decision and may be refined e.g. because analysis results<br />
show that some components violate their deadlines while others would satisfy also smaller<br />
deadlines. Whether these subcontracts are valid with respect to the contracts of the top level<br />
component has to be shown by a virtual integration test.<br />
Next, we have a look at the top level component of the technical perspective as depicted<br />
in Figure 5.18. Here, the BSCU as the top level component is composed of two computing<br />
resources namely ECU1 and ECU2, and a communication resource named CANBus. Each ECU<br />
component has input and output ports to the bus component to send and receive messages and<br />
interfaces to the top level component to communicate with the environment. In this perspective<br />
we have again contracts talking about the deadlines of the top level component specifying the<br />
same deadlines as in the logical perspective.<br />
To be able to specify contracts for the local deadlines, we need to consider the interna of<br />
88/ 156
<strong>Architecture</strong> <strong>Modeling</strong><br />
Figure 5.18: Technical Perspective – Unit Level – BSCU<br />
Figure 5.19: Technical Perspective – Unit Level – ECU 1<br />
both ECUs and the bus and additionally have knowledge about the desired allocation of logical<br />
components to technical components. In Figure 5.19, the component ECU1 is modeled containing<br />
different types of technical components. First, there are two tasks named ECU1Task1<br />
and ECU1Task2. To determine the necessary number of tasks, knowledge of the intended allocation<br />
is required. In this example, we decided to allocate two logical components on ECU1<br />
using two tasks.<br />
A further component of ECU1 is a scheduler component ECU1Sched that schedules a number<br />
of scheduler slots using a certain strategy which is here Fixed Priority Scheduling (FPS).<br />
Each slot is linked to a task. For the communication with other ECUs via the CAN bus an<br />
interface is needed that is modeled by the ECU1BusIf component. This interface component<br />
has links to each task and to ports of the parent component ECU1 leading to the bus component.<br />
89/ 156
<strong>Architecture</strong> <strong>Modeling</strong><br />
Figure 5.20: Unit Level – Allocation from Logical to Technical Perspective<br />
ECU1 has two contracts specifying the local deadlines for the execution of the two tasks<br />
ECU1Task1 and ECU1Task2. To choose the correct deadlines here, the allocation of logical<br />
components to tasks of the technical perspective is necessary. The allocation is depicted in<br />
Figure 5.20 while we use here an abbreviatory representation of the mapping of a single port<br />
to another single port. A dotted arrow from a port a of a logical component (depicted on the<br />
left side) to a port b of a technical component (depicted on the right side) means a mapping of<br />
port a to port b. The dottet arrow from one component to another component annotated with an<br />
> label indicates this mapping as an allocation.<br />
For ECU1, the relevant allocation decisions are the mapping of Monitor1 to ECU1Task2<br />
and the mapping of Command2 to ECU1Task1. This leads to the contracts in Figure 5.19<br />
specifying the same deadlines as for the mapped logical components i.e. a deadline of 1200<br />
microseconds for the execution (inclusive scheduling) of ECU1Task2 (delay from input signal<br />
inA.P TecBusA to outA.P TecA) and a deadline of 1400 microseconds for ECU1Task1<br />
(delay from input signal inB.P TecB to outB.P TecBusB).<br />
The structure of the component ECU2 is almost similar to ECU1 and thus not depicted here.<br />
The mapping to the tasks of ECU2 is also shown in the allocation in Figure 5.20. Communication<br />
components such as Com1ToMon1 and Com2ToMon2 are mapped implicitly by the task<br />
mapping.<br />
The interna of the bus component CANBus are shown in Figure 5.21. It consists of a scheduler<br />
component (depicted in blue) that schedules two slots (depicted in green). Each slot is then<br />
linked to a frame-triggering component that sends and receives the frames. Again, we have two<br />
contracts specifying how long a communication may take which is the identical deadline of 400<br />
microseconds as for the logical communication components.<br />
Scheduling Analysis with Orca Next, we want to show exemplarily how real-time contracts<br />
may be checked using a scheduling analysis tool like Orca.<br />
The first step is the translation of the model into the Orca data model. The result of this<br />
90/ 156
<strong>Architecture</strong> <strong>Modeling</strong><br />
Figure 5.21: Technical Perspective – Unit Level – Bus<br />
Figure 5.22: Orca Model of Unit Level<br />
translation is depicted in Figure 5.22. On the left side, a task network is shown consisting of<br />
triggers, tasks, signals, messages and deadlines while at the right edge of the figure the set<br />
91/ 156
<strong>Architecture</strong> <strong>Modeling</strong><br />
of modeling artefacts in Orca is listed. The Orca tasks correspond to the components of the<br />
logical perspective in the <strong>SPES</strong> metamodel that are allocated on the task components of the<br />
technical perspective i.e. we have four tasks namely Command1, Monitor1, Command2<br />
and Monitor2 building the two channels. For each channel, there exists a trigger node emitting<br />
activation events with a certain period and jitter. Period and jitter are derived from the<br />
assumptions of the triggered tasks Command1 and Command2 i.e. here both triggers produce<br />
activation events with a period of 5 milliseconds. The communication between tasks is modeled<br />
by signals in Orca which correspond to the communication components of the logical perspective<br />
namely Com1ToMon1 and Com2ToMon2. The execution times for tasks were annotated<br />
as attributes in the <strong>SPES</strong> model and translated to attributes of the Orca task nodes.<br />
In the middle of the figure, the hardware architecture is depicted consisting of the two ECUs<br />
ECU1 and ECU2. Each ECU has an ECUServer that implements the scheduler component<br />
of the <strong>SPES</strong> model. Accordingly, each ECU-server contains two scheduler slots. Each task is<br />
mapped to exactly one of these scheduler slots in the same way as described in Figure 5.20.<br />
This mapping leads to the fact that each signal has to be transmitted using the bus component<br />
CANBus which is part of the hardware architecture in Orca and offers a BusServer that<br />
schedules two bus slots. The mapping of signals to bus slots is realized using messages. Each<br />
signal that is not local is linked to a message and each message is mapped to a bus slot. The<br />
mapping is not shown here explicitly.<br />
The contracts of the <strong>SPES</strong> model are represented in different ways. First, as already mentioned,<br />
the assumptions of triggered tasks are realized by their trigger nodes. The contracts<br />
that define local deadlines for tasks or signals are realized by setting the deadline attribute of<br />
the Orca nodes to the appropriate value. Contracts that define (non-local) deadlines over several<br />
tasks or signals are modeled by end-to-end deadlines in the Orca model. There exist two<br />
end-to-end deadlines, one for each channel, named according to the contracts they stem from.<br />
Figure 5.23: Orca Deadline Violation<br />
Using scheduling analysis, we now can check whether all contracts are fulfilled i.e. whether<br />
all deadlines (local and end-to-end deadlines) of the Orca model are met. If there exists a<br />
run such that a deadline is violated this is indicated by a red skull. For example, in Figure<br />
5.22 the end-to-end deadline BSCUContractChannel1 and the local deadlines of the<br />
92/ 156
<strong>Architecture</strong> <strong>Modeling</strong><br />
tasks Command1 and Monitor1 are not met. To get more detailed information about a deadline<br />
violation one may choose a red skull and a window opens as it is depicted in Figure 5.23<br />
for the task Command1. At the top of the window, we see beside the name, period and deadline<br />
of the node a list of different results of the analysis. First of all, this is the response time and<br />
how it is composed of different aspects as the blocking time by tasks with higher priority. This<br />
is depicted at the bottom of Figure 5.23. The red line represents the deadline that is obviously<br />
violated here.<br />
One possible counter-measure to solve this violation would be two replace one or both ECUs<br />
by other ones where the respective tasks have less execution times. In this example, the initial<br />
architecture consists of two ECUs of an ARM7 type. When replacing both ECUs by an ARM9<br />
type leading to less execution times, all deadline violations can be successfully removed. Another<br />
possible measure would be to change the splitting of global deadlines into local deadlines<br />
(deadline synthesis) in the <strong>SPES</strong> model.<br />
5.2 On the role of contracts in system development<br />
processes 5<br />
In this section we discuss key design challenges<br />
• Coping with complexity of systems<br />
• Coping with the complexity of the supply chain<br />
• Getting initial requirements right<br />
• Coping with multi-layer design optimization<br />
• Managing Risk<br />
facing systems companies, and discuss industrial solutions in place to cope with these, and<br />
point out how conservative extensions of current processes exploiting contract-based design<br />
could tackle such weaknesses. We wrap up by condensing the essence of what we call contractbased<br />
design.<br />
5.2.1 Coping with complexity of systems<br />
Multiple lines of attack have been developed by industry to cope with the exponential growth<br />
in systems complexity:<br />
1. Model-based development<br />
2. Virtual integration<br />
3. Layered design<br />
4. Component-based design<br />
5. Platform-based design<br />
5 This section is co-authored with Alberto L. Sangiovanni-Vincentelli, University of California at Berkeley<br />
93/ 156
5.2.1.1 Model Based Development<br />
<strong>Architecture</strong> <strong>Modeling</strong><br />
Model based development is today generally accepted as a key enabler to cope with complex<br />
system design due to its capabilities to support early requirement validation and virtual system<br />
integration. While initially the overhead introduced by additional modeling activities for specification<br />
and design models and the costs of maintaining coherency of such models and their<br />
implementation slowed down the introduction of model-based development, the benefits of such<br />
frontloading of processes in achieving high-quality design and avoiding deep iteration cycles is<br />
increasingly seen as key benefit by systems industries, with sector- and application-specific<br />
penetration rates reaching close to 100% such as for primary and secondary flight control in<br />
aerospace, and engine control or dynamic stability control in automotive. Methods used depend<br />
on design layer and application class, such as the use of SysML or AADL for complete<br />
system modeling, Matlab-Simulink for control-law design, and UML, Scade and TargetLink<br />
for detailed design. Today’s state-of-the-art in model based design includes automatic codegeneration,<br />
simulation coupled with requirement monitoring, co-simulation of heterogeneous<br />
models such as UML and Matlab-Simulink, model-based analysis including verification of<br />
compliance of requirements and specification models, model-based test-generation, rapid prototyping,<br />
and virtual integration testing as further elaborated below. We also delay the discussion<br />
of the additional role of model-based design in enabling design-space exploration, architecture<br />
evaluation and platform-based design to the subsection addressing the challenge of overall<br />
optimization of the system under development.<br />
While thus model-based design is already today instrumental in improving product quality<br />
and boosting productivity in complex embedded system design, it is largely focusing on architecture<br />
and function. Non-functional aspects such as performance-, timing-, power- or safety<br />
analysis are typically addressed in dedicated specialized tools using tool-specific models, with<br />
the entailed risk of incoherency with models actually driving design and implementation, and<br />
models used to assess such non-functional characteristics of designs. To counteract these risks,<br />
meta-models encompassing multiple views of design entities, enabling co-modeling and coanalysis<br />
of typically heterogeneous viewpoint specific models have been developed. Examples<br />
include the MARTE UML profile for real-time system analysis [40] and the Metropolis<br />
meta-model [21] (the term meta-model is intended here in the semantic domain, i. e., a sort<br />
of abstract semantics, while in the traditional use of the term, meta-model is a structural concept<br />
and corresponds to abstract syntax). Along the same lines, the need to enable integration<br />
of point-tools for multiple viewpoints with industry-standard development tools has been the<br />
driving force in providing the SPEEDS meta-model building on and extending SysML, which<br />
has been demonstrated to support co-simulation and co-analysis of system models for transportation<br />
applications allowing co-assessment of functional, real-time and safety requirements,<br />
and forms an integral part of the meta-model-based interoperability concepts of the CESAR<br />
reference technology platform 6 .<br />
5.2.1.2 Virtual Integration<br />
Rather than “physically” integrating a system from subsystems at a particular level of the righthand<br />
side of the V, model-based design allows to virtually integrate systems based on the models<br />
of their subsystem and the architecture specification of the system, which in particular explicates<br />
the information flow between subsystems and the systems environment. Such virtual<br />
integration thus allows detecting potential integration problems up front, in the early phases<br />
6 http://www.cesarproject.eu/<br />
94/ 156
<strong>Architecture</strong> <strong>Modeling</strong><br />
of the V, such as exploiting type checking to detect type inconsistencies, up to verification of<br />
system requirements based on simulation (more examples are given below). Virtual system integration<br />
is often a source of heterogeneous system models, such as when realizing an aircraft<br />
function through the combination of mechanical, hydraulic, and electronic systems – virtual<br />
system integration then rests on well defined principles allowing the integration of such heterogeneous<br />
models. Heterogeneous composition of models with different semantics was originally<br />
addressed in Ptolemy [24] and Metropolis albeit with different approaches. These approaches<br />
have then been further elaborated in the SPEEDS meta-model of heterogeneous rich components<br />
[21, 11, 31].<br />
While virtual integration is already well anchored in many system companies development<br />
processes, the challenge rests in lifting this from the current level of simulation-based analysis<br />
of functional system requirements to rich virtual integration testing catering as well for<br />
non-functional requirements. In contract-based virtual integration testing, both subsystems<br />
and the complete system are equipped with multi-viewpoint contracts. Since subsystems now<br />
characterize their legal environments, we can flag situations, where a subsystem is used out of<br />
specification, i. e. in a design context, for which no guarantees on the subsystems reaction can<br />
be given. Our experience from a rich set of industrial applications shows, that such virtual integration<br />
tests drastically reduce the number of late integration errors. Special instances of failed<br />
virtual integration tests include:<br />
• The lack of a component to provide complete fault isolation (a property presumed by a<br />
neighboring subsystem);<br />
• The lack of a subsystem to stay within the failure hypothesis assumed by a neighboring<br />
subsystem;<br />
• The lack of a subsystem to provide a response within an expected time-window;<br />
• The unavailability of a shared resource such as a bus-system in a specified time-window;<br />
• Non-allowed memory accesses;<br />
• Glitch rates exceeding specified bounds;<br />
• Signal strengths not meeting specified thresholds.<br />
Multi-viewpoint contracts in virtual integration testing thus drastically extend the potential<br />
to uncover integration errors early. Additionally, using such rich contracts in system specification<br />
comes with two key benefits which help dealing with the complexity in the OEM-supplier<br />
relationship.<br />
First, the above approach to virtual integration testing is purely based on the subsystems’ contract<br />
specifications. In other words, if virtual integration testing is successful, any implementation<br />
of a subsystem compliant to this contract specification will not invalidate the outcome of<br />
virtual integration testing. Second, assuming that the virtual integration test was passed successfully,<br />
we can verify whether the system itself meets its contract purely based on the knowledge<br />
of the subsystem contract and the system architecture (and evidence that the subsystem implementation<br />
is compliant with this contract).<br />
This entails that, at any level of the supplier hierarchy, the higher-level organization can<br />
– prior to contracting suppliers – analyze, whether the subsystems contracts pass the virtual<br />
integration test and are sufficient to establish the system requirements. By then basing the<br />
contracts to suppliers on the subsystem contracts, and requiring subsystem suppliers to give<br />
95/ 156
<strong>Architecture</strong> <strong>Modeling</strong><br />
evidence (such as through testing or through formal analysis methods) that their implementation<br />
complies to their contract, the final integration of subsystems to the complete system will be free<br />
of all classes of integration errors covered by contracts in the virtual integration test. Note that<br />
this method allows to protect the IP of subsystem suppliers – the only evidence required, is the<br />
confirmation that their implementation meets the subsystem contract specification.<br />
5.2.1.3 Layered Design<br />
Layered design copes with complex systems by focusing on those aspects of the system pertinent<br />
to support the design activities at the corresponding level of the V diagram. This approach<br />
is particularly powerful if the details of a lower layer of abstraction are encapsulated when the<br />
design is carried out at the higher layer. Layered approaches are well understood and standard<br />
in many application domains. As an example, AUTOSAR defines several abstraction layers.<br />
Moving from “bottom” to “top”, the microcontroller abstraction layer encapsulates completely<br />
the specifics of underlying microcontrollers, the second layer abstracts from the concrete configuration<br />
of the Electronic Control Unit (ECU), the employed communication services and the<br />
underlying operating system, whereas the (highest) application layer is not aware of any aspect<br />
of possible target architectures, and relies on purely virtual communication concepts in specifying<br />
communication between application components. Similar abstraction levels are defined by<br />
the ARINC standard in the avionic domains [1].<br />
The benefits of using layered design are manifold. Using AUTOSAR’s layer structure as example,<br />
the complete separation of the logical architecture of an application (as represented by a<br />
set of components interconnected using the so-called virtual function bus) and target hardware<br />
is a key design objective of AUTOSAR, in that it allows complete decoupling of the number<br />
of automotive functions from the number of hardware components. In particular, it is flexible<br />
enough to mix components from different applications on one and the same ECU. This illustrates<br />
the double role of abstraction layers, in allowing to focus completely in this case on the<br />
logic of the application and abstracting from the underlying hardware, while at the same time<br />
imposing a minimal (or even no) constraint on the design space of possible hardware architectures.<br />
In particular, this allows re-using the application design across multiple platforms,<br />
varying in number of bus-systems and/or number and class of ECUs. Such design layers can,<br />
in addition, be used to match the boundaries of either organizational units within a company, or<br />
to define interfaces between different organizations in the supply chain.<br />
The challenge, then, rests in providing the proper abstractions of lower-level design entities,<br />
which must meet the double criteria of on one hand being sufficiently detailed so as to support<br />
– among others – virtual integration testing even with respect to non-functional viewpoints<br />
on the next higher level, while at the same time not overly restricting the space of possible<br />
lower-level implementations. As a concrete example, consider the AUTOSAR application layer<br />
and an application requiring guaranteed service under a given failure hypothesis. Such failure<br />
hypothesis would typically relate both to failures observable on the application layer itself (such<br />
as a component sending an incorrect value, or a component flushing its neighbors with unwanted<br />
messages), as well as to failures depending on the underlying (unknown!) target hardware.<br />
This points to an inherent dilemma: on one side, the desire of completely abstracting from the<br />
underlying hardware, while at the same time wishing to perform analysis of properties which<br />
inherently depend on it.<br />
This dilemma can be solved by using what we call vertical assumptions as abstractions of the<br />
underlying target hardware. Returning to the above example, such vertical assumptions could<br />
explicate the failure hypothesis of either execution platforms or communication platforms, and<br />
96/ 156
<strong>Architecture</strong> <strong>Modeling</strong><br />
thus decorate either (individual runnables of) components, or entities of the virtual function<br />
bus. More general, any logical communication must be seen as a (fictitious) component itself,<br />
which, at deployment time, will be mapped to communication services of the operating system<br />
inducing either bus-based communication or ECU local communication e. g. through shared<br />
memory within one ECU.<br />
5.2.1.4 Component-Based Design<br />
Whereas layered designs decompose complexity of systems “vertically”, by splitting the design<br />
into multiple design layers, component-based approaches reduce complexity “horizontally”<br />
whereby designs are obtained by assembling (composing) strongly encapsulated design<br />
entities called “components” equipped with concise and rigorous interface specifications. While<br />
these interface specifications are key and relevant for any system, the “quality attribute” of perceiving<br />
a subsystem as a component is typically related to two orthogonal criteria, that of “small<br />
interfaces”, and that of minimally constraining the deployment context, so as to maximize the<br />
potential for re-use. “Small interfaces”, i. e., interfaces which are both small in terms of number<br />
of interface variables or ports, as well as “logically small”, in that protocols governing the<br />
invocation of component services have compact specifications not requiring deep levels of synchronization,<br />
constitute evidence of the success of encapsulation. The second quality attribute<br />
is naturally expressible in terms of contract-based interface specifications, where re-use can be<br />
maximized by finding the weakest assumptions on the environment sufficient to establish the<br />
guarantees on a given component implementation.<br />
One challenge, then, for component-based design of embedded systems, is to provide interface<br />
specifications that are rich enough to cover all phases of the design cycle. The need<br />
to thus include non-functional characteristics as part of the component interface specifications<br />
was the key motivation in proposing rich components [20] offering multi-viewpoint contracts<br />
with both vertical and horizontal assumptions as enablers of true component re-use in embedded<br />
system design. Current component interface models, in contrast, are typically restricted to<br />
purely functional characterization of components, and thus cannot capitalize on the benefits of<br />
contract-based virtual integration testing, as outlined above.<br />
The second challenge is related to product line design. While systematic approaches to derive<br />
a weakest set of restrictions on environments exist [12], these assume a given set of service<br />
guarantees. The challenge, then, rests in anticipating the space of future deployments of components<br />
when formulating component guarantees, balancing the contradicting goals of striving for<br />
generality versus achieving efficient component implementations. Methods for systematically<br />
deriving “quotient” specifications for compensating for “minor” differences between required<br />
and offered component guarantees by composing a component with a wrapper component compensating<br />
for such differences as characterized by quotient specifications exists for restricted<br />
classes of contracts and restricted classes of component models [36].<br />
The third challenge is in the choice of granularity of the components. “Smaller” components<br />
are intrinsically more re-usable since it is more likely that a fairly small component has<br />
functionality that can be shared on a larger scale, but the gain in design time is less. “Larger”<br />
components are less re-usable since it is relatively rare that a large part of the design can be<br />
used as is in other designs, but if it can be re-used then the savings are considerable. A way<br />
of balancing these trade-offs is to leverage layered design in that a component can be itself<br />
considered as an assembly of lower complexity components. If both the component and its<br />
“subcomponents” are considered part of the design library we are not giving up potential re-use<br />
by choosing larger granularity components!<br />
97/ 156
5.2.1.5 Platform-Based Design<br />
<strong>Architecture</strong> <strong>Modeling</strong><br />
Platform-based design (PBD) was introduced in the late 1980s to capture a design process that<br />
could encompass both horizontal and vertical decompositions and multiple viewpoints. It was<br />
inspired by the development of personal computing and by the use of the term platform intended<br />
to underline the importance of re-use and of building upon available results. The notion of<br />
platform though was highly context dependent and meant different things to different people.<br />
Thus, there was room to introduce a general approach that could be shared across industrial<br />
domain boundaries and would subsume the various definition and design concepts.<br />
The basic tenets of platform-based design are as follows:<br />
• The design progresses in precisely defined abstraction layers; at each abstraction layer,<br />
functionality (what the system is supposed to do) is strictly separated from architecture<br />
(how the functionality could be implemented). This aspect is clearly related to layered<br />
design and hence it subsumes it.<br />
• Each abstraction layer is defined by a design platform. A design platform consists of<br />
– A set of library components. This library not only contains computational blocks<br />
that carry out the appropriate computation but also communication components that<br />
are used to interconnect the computational components.<br />
– Each element of the library has models that represent a characterization in terms of<br />
performance and other non-functional parameters together with the functionality it<br />
can support. Not all elements in the library are pre-existing components. Some may<br />
be “place holders” to indicate the flexibility of “customizing” a part of the design<br />
that is offered to the designer. In this case the models represent estimates of what<br />
can be done since the components are not available and will have to be designed.<br />
At times, the characterization is indeed a constraint for the implementation of the<br />
component and it is obtained top-down during the refinement process typical of<br />
layered designs. This layering of abstractions based on mathematical models is<br />
typical of model-based methods.<br />
– The rules that determine how the components can be assembled and how the functional<br />
and non-functional characteristics can be computed given the ones of the components<br />
to form an architecture. Then, a platform represents a family of designs<br />
that satisfies a set of platform-specific constraints. This aspect is strictly related to<br />
component-based design.<br />
• This concept of platform encapsulates the notion of re-use as a family of solutions that<br />
share a set of common features (the elements of the platform). Since we associate the<br />
notion of platform to a set of potential solutions to a design problem, we need to capture<br />
the process of mapping a functionality (what the system is supposed to do) with the platform<br />
elements that will be used to build a platform instance or an “architecture” (how the<br />
system does what is supposed to do). This process is the essential step for refinement and<br />
provides a mechanism to proceed towards implementation in a structured way. Designs<br />
on each platform are represented by platform-specific design models. A design is obtained<br />
by a designer creating platform instances (architectures) via composing platform<br />
components (a process that is typical of component-based design), by mapping the functionality<br />
onto the components of the architecture and by propagating the mapped design<br />
in the design flow onto subsequent abstraction layers and/or perspectives.<br />
98/ 156
<strong>Architecture</strong> <strong>Modeling</strong><br />
In summary, PBD encompasses all the methods presented before and offers a unified intellectual<br />
framework where several concers are harmonized. In particular:<br />
• In PBD, the partitioning of the design into hardware and software is not the essence of<br />
system design as many think, rather it is a consequence of decisions taken at a higher<br />
level of abstraction. Critical decisions are about the architecture of the system, e.g., processors,<br />
buses, hardware accelerators, and memories, that will carry on the computation<br />
and communication tasks associated with the overall specification of the design.<br />
• In the PBD refinement-based design process, platforms should be defined to eliminate<br />
large loop iterations for affordable designs: they should restrict the design space via new<br />
forms of regularity and structure that surrender some design potential for lower cost and<br />
first-pass success. The library of functional and communication components is the design<br />
space that we are allowed to explore at the appropriate level of abstraction.<br />
• Establishing the number, location, and components of intermediate “platforms” is the<br />
essence of PBD. In fact, designs with different requirements and specifications may use<br />
different intermediate platforms, hence different layers of regularity and design-space<br />
constraints. The trade-offs involved in the selection of the number and characteristics of<br />
platforms relate to the size of the design space to be explored and the accuracy of the<br />
estimation of the characteristics of the solution adopted. Naturally, the larger the step<br />
across platforms, the more difficult is predicting performance, optimizing at the higher<br />
levels of abstraction, and providing a tight lower bound. In fact, the design space for<br />
this approach may actually be smaller than the one obtained with smaller steps because<br />
it becomes harder to explore meaningful design alternatives and the restriction on search<br />
impedes complete design-space exploration. Ultimately, predictions/abstractions may be<br />
so inaccurate that design optimizations are misguided and the lower bounds are incorrect.<br />
• The identification of precisely defined layers and perspectives where the mapping processes<br />
take place is an important design decision and should be agreed upon at the top<br />
design management level. Each layer supports a design stage where the performance<br />
indices that characterize the architectural components provide an opaque abstraction of<br />
lower layers that allows accurate performance estimations used to guide the mapping<br />
process.<br />
• PBD allows re-use, because it decouples independent aspects, that would otherwise be<br />
tied, e.g., a given functional specification to low-level implementation details, or to a<br />
specific communication paradigm, or to a scheduling algorithm. It is very important to<br />
define only as many aspects as needed at every level of abstraction, in the interest of<br />
flexibility and rapid design-space exploration.<br />
In PBD, contracts play a fundamental role in determining the correct composition rules so<br />
that when the architecture space is explored, only “legal” compositions of available components<br />
are taken into consideration. They can also be used to verify whether the abstractions of the<br />
components for the upper layers of the design satisfy the key concerns about accuracy and<br />
fidelity that depend critically on the design goals. If both these sets of contracts are satisfied,<br />
the mapping mechanism of PBD can be used to produce design refinements that are correct by<br />
construction.<br />
99/ 156
<strong>Architecture</strong> <strong>Modeling</strong><br />
5.2.2 Coping with the Complexity of the Supply Chain<br />
To ensure coherent product development across complex supply chains, the following key trends<br />
can be observed in the market:<br />
1. Standardization of design entities<br />
2. Harmonization/standardization of processes<br />
5.2.2.1 Standardization of Design Entities<br />
By agreeing on (domain specific) standard representations of design entities, different industrial<br />
domains have created their own lingua franca, thus enabling a domain wide shared usage<br />
of design entities based on their standardized representation. Examples of these standards in the<br />
automotive sector include the recently approved requirement interchange format standard ReqIF<br />
[28], the AUTOSAR de-facto standard, the OSEK operating system standard, standardized<br />
bus-systems such as CAN and Flexray, standards for car2X communication, and standardized<br />
representations of test supported by ASAM. Examples in the aerospace domain include ARINC<br />
standards such as the avionics applications standard interface, integrated modular avionics, and<br />
RTCA communication standards. In the automation domain, standards for interconnection of<br />
automation devices such as Profibus are complemented by standardized design languages for<br />
application development such as Structured Text.<br />
As standardization moves from hardware to operating system to applications, and thus<br />
crosses multiple design layers, the challenge increases to incorporate all facets of design entities<br />
required to optimize the overall product, while at the same time enabling distributed development<br />
in complex supply chains. As an example, AUTOSAR extended in transitioning from<br />
release 3.1 to 4 its capability to capture timing characteristics of design entities, a key prerequisite<br />
for assessing alternate deployments with respect to their impact on timing. In general,<br />
the need for overall system optimization then calls for the standardization of all non-functional<br />
characteristics of design entities in order to allow cross-layer optimization. Within the EDA domain,<br />
such richness of design interface specifications is industrial practice. Within the systems<br />
domain, the rich component model introduced in the Integrated Projects SPEEDS tackles this<br />
key objective: in covering multiple design layers (from product requirements to deployment<br />
on target architectures) and in providing means of associating multiple viewpoints with each<br />
design entity, it is expressive enough to allow for cross-supply-chain optimization of product<br />
developments. This approach is further elaborated and driven towards standardization in the<br />
Artemis flagship project CESAR.<br />
5.2.2.2 Standardization/harmonization of processes<br />
Harmonizing or even standardizing key processes (development processes, safety processes,<br />
etc.) provides for a further level of optimization in interactions across the supply chain. As<br />
an example, Airbus Directives and Procedures (ADBs) provide requirements for design processes<br />
of equipment manufactures. Often, harmonized processes across the supply chain build<br />
on agreed maturity gates with incremental acceptance testing to monitor progress of supplier<br />
development towards final acceptance, often building on incremental prototypes. Shared usage<br />
of PLM databases across the supply chain offers further potentials for cross-supply chain<br />
optimization of development processes.<br />
There are multiple challenges in defining such interfaces between OEM and suppliers. Specifications<br />
used for procurement should be precise, unambiguous, and complete. To this end,<br />
100/ 156
<strong>Architecture</strong> <strong>Modeling</strong><br />
OEMs are increasingly using models within procurement processes, typically safeguarding<br />
themselves against potential liability issues by requiring suppliers to validate such models<br />
against textual requirement specifications. A re-appearing reason for failures causing deep iterations<br />
across supply chain boundaries rests in incomplete characterizations of the environment<br />
of the system to be developed by the supplier, such as missing information about failure modes<br />
and failure rates, missing information on possible sources for interferences through shared resources,<br />
missing boundary conditions, etc. This highlights the need to explicate assumptions on<br />
the design context in OEM-supplier contracts. This key need was one of the major motivations<br />
for introducing the contract-based design methodology for embedded systems, as initially developed<br />
in the Integrated Project SPEEDS. In enforcing the analysis of the key characteristics of<br />
the environment required to enforce the system specification up front, responsibilities between<br />
what has to be guaranteed by the OEM (that the system provided by the supplier will be embedded<br />
in an overall design meeting the assumptions on the environment specified in the contract)<br />
and the supplier (in providing an implementation to the system specification provided that the<br />
system is used in a context meeting the specified environment characteristics) are clearly defined.<br />
In the light of an increased sharing of hardware resources by applications developed by<br />
multiple suppliers, such a contract-based approach seems indispensable for resolving liability<br />
issues and allowing co-existence of applications with different criticality levels (such as ASIL<br />
levels in automotive).<br />
In domains developing safety related systems, domain specific standards clearly define the responsibilities<br />
and duties of companies across the supply chain to demonstrate functional safety,<br />
such as in the ISO 26262 for the automotive domain, IEC 61508 for automation, its derivatives<br />
Cenelec EN 50128 and 50126 for rail, and Do 178 B for civil avionics.<br />
The challenge in defining standards rests in balancing the need for stability with the need of<br />
not blocking process innovations seen as indispensible to cope with the exponential growth in<br />
systems complexity and the overarching need of optimization techniques for cost reduction. As<br />
an example, means for compositional construction of safety cases thus allowing modular certification<br />
are seen as mandatory to reduce certification costs in the aerospace and rail domains.<br />
Similarly, the potential of using formal verification techniques to cope with increasing system<br />
complexity will lead to an adaptation of the current DO 178 B standard, establishing the role<br />
of these techniques within the construction of safety cases. In general, this calls for a closed<br />
feedback loop between design and safety processes, assessment the potential impact and benefit<br />
of such design representations and enabled process optimizations on safety standards, and identifying<br />
techniques with strong optimization potential and high industrial relevance early enough<br />
for adaptation of standards enabling their usage in safety-critical system design.<br />
5.2.3 Getting Initial Requirements Right<br />
Depending on application domains, up to 50% of all errors result from imprecise, incomplete,<br />
or inconsistent requirements. Out of the many approaches taken in industry for getting requirements<br />
right, we focus here on those for initial systems requirements, relying on ISO 26262<br />
compliant approaches such as discussed in the context of virtual system integration to systematically<br />
reduce system contracts to contracts on subsystems which are jointly powerful enough<br />
to establish the total set of system contracts.<br />
To cope with the inherently unstructured problem of (in-)completeness of requirements, industry<br />
has set up domain- and application-class specific methodologies striving towards completeness<br />
of requirement analysis. As particular examples, we mention learning process, such as<br />
employed by Airbus to incorporate the knowledge base of what is called external hazards from<br />
101/ 156
<strong>Architecture</strong> <strong>Modeling</strong><br />
flight incidents, the Code of Practice proposed by the Prevent Project using guiding questions to<br />
assess the completeness of requirements in the concept phase of the development of advanced<br />
driver assistance systems, use-case analysis methods as advocated for UML based development<br />
process, where an initial stakeholder based analysis is refined by scenarios capturing the typical<br />
interactions between actors and the system-under-development, and the various approaches<br />
based on rapid prototyping, including virtual reality based mock-ups. A common theme of these<br />
approaches is the intent to systematically identify those aspects of the environment of the system<br />
under development (SUD) (subsuming the physical environment, the operator of the system, and<br />
– for systems-of-systems – other “surrounding” systems) whose observability is necessary and<br />
sufficient to achieve the system requirements. As examples of extensions of systems parameters<br />
based on such heuristic approaches, we mention the need to observe, whether the aircraft<br />
is on-ground (as required to prevent inadvertent activation of reverse thrust of engines when in<br />
cruise flight), blind-spot detection coupled with lane change assistance systems warning against<br />
lane changes in critical traffic situations, or train-integrity control in ETCS-based train-safety<br />
systems. Once this perimeter of the system-under-development is identified, the challenge rests<br />
in characterizing those conditions on the environment, under which the system is expected to<br />
perform according to its requirements. For example, advanced driver assistance systems dependent<br />
on image processing for obstacle detection from video streams will be automatically<br />
de-activated or switched to a degraded mode in complex lighting conditions. As other classes of<br />
environment assumptions we mention assumed boundary values of physical parameters, such<br />
as maximal relative and absolute speed of vehicles, maximal acceleration, types of road conditions,<br />
curve radiuses on highways, traffic rules, average and worst case distributions of arrival<br />
processes of systems in the environment, etc. The approach taken by the Code of Practice can<br />
be generalized to other domains, using a Hazop-style analysis [45], where for each identified<br />
class of interaction between actor and SUD and for each viewpoint specific guide-words could<br />
be used to probe for undesired interactions or interferences, which should be excluded.<br />
An initial phase of refining requirements to contracts is an important step in the design<br />
methodology we describe in this paper. Based on a determined system boundary, responsibilities<br />
of achieving requirements are split into those to be established by the system-underdevelopment<br />
(the “guarantees” of the contract) and those characterizing admissible environments<br />
of the system-under-development (the “assumptions” of the contract). To further<br />
strengthen the capabilities for improving the quality of initial specifications, we advocate the<br />
use of formal specification languages for expressing these, where the particular shape of such<br />
formalizations is viewpoint and domain dependent. Examples include the usage of failure propagation<br />
models for safety contracts, the use of probabilistic timed automata to specify arrival<br />
processes, the use of live sequence charts for capturing scenarios in the interaction of actors<br />
and systems [44], or the pattern-based contract specification language initially developed by the<br />
integrated project SPEEDS, and further refined and elaborated to the RSL language presented<br />
in the Annex advocated for usage in <strong>SPES</strong>. All these enable what Harel called “playing out”<br />
for the particular case of live sequence charts, i. e. the use of formalized contract specifications<br />
to generate trajectories of interface observations compliant to the currently derived set of<br />
contracts. Such simulation capabilities turn out to be instrumental in further refining our specifications:<br />
typically, they will exhibit unexpected traces, e. g. due to an insufficient restriction of<br />
the environment, or only partially specified system reactions. Using contracts resting on logic<br />
based formalisms comes with the advantage, that such “spurious” unwanted behaviors can be<br />
excluded by “throwing in” additional contracts, or strengthening assumptions, or by considering<br />
additional cases for guarantees. A second advantage of such formalized contracts rests in<br />
the now available methods for checking for consistency: the formalism mentioned above do<br />
102/ 156
<strong>Architecture</strong> <strong>Modeling</strong><br />
provide effective tests, whether a set of contracts is realizable, or whether, in contrast, facets of<br />
these are inherently conflicting, and thus no implementation is feasible.<br />
5.2.4 Coping with Multi-Layer Design Optimization<br />
System designs are often the result of modifications of previous designs with the attempt of<br />
minimizing risks and reducing delays and design costs. While this was an effective way of<br />
bringing new products to market in the past, with the increase in demand for new functionality<br />
and the advances of the implementation platforms, this strategy has yielded more problems than<br />
it has fixed. Hence, there has been a constant progression towards thinking through anew the<br />
requirements and the implementation strategies. However, there is a shared consensus that in<br />
most of the cases the designs are not optimized in the sense that the full exploitation of the<br />
new opportunities technology offers is not achieved and that having visibility of the available<br />
options and an evaluation framework for design alternatives are a sorely missing capability.<br />
An ideal scenario for optimization is to have access to the entire design space at the lowest<br />
possible level of abstraction and then run a global optimization algorithm that could select these<br />
components satisfying constraints and optimizing multiple criteria involving non-functional aspects<br />
of the design. Unfortunately this approach is obviously out of the question for most<br />
designs given the size of the design space and the capabilities of optimization algorithms. What<br />
is possible is to select solutions in a pre-selected design space where the number of alternatives<br />
to choose from is finite and searchable by state-of-the-art optimization programs. Indeed, the<br />
platform-based design paradigm offers scaffolding that would support this approach. In fact, at<br />
any abstraction layer, we need to optimize with respect to the components of the platform. The<br />
selection process will have to look only at feasible combinations of the components as dictated<br />
by the composability of contracts! If we take this argument further, we need also to formulate<br />
the optimization problem that has to be solved. The basic question to be asked is whether a<br />
particular legal composition of available components implements the given functionality and<br />
satisfies the constraints expressed by the contracts. The question is then one of how to assess<br />
whether the composition “covers” the functionality and of how to compute the non-functional<br />
quantities for the composition given the ones of the components. The second part of the question<br />
can be answered if analysis methods for non-functional aspects of components and there<br />
composition is available. The first question is more complex to answer since there is no evidence<br />
that the semantics of the global functionality and the one of the components be congruent.<br />
This aspect is at the heart of heterogeneous design. Several approaches have been tried but not<br />
in the optimization context. In the platform-based design context, there is a way of determining<br />
how to link functionality and solutions and to set up a generic optimization framework. This<br />
approach has been inspired by the optimization work done in logic synthesis, a mainstay of the<br />
design flow used in integrated circuit design.<br />
The mapping step is the core of platform-based design process, and greatly affects the performance<br />
of the implemented system. However, it has been performed manually for most test cases<br />
presented in literature. As the design methodology solidifies and design environments such as<br />
Metropolis [21] are built to support it, there is a clear need for automatic optimized mapping<br />
processes to increase productivity and design quality. To automate the mapping process, we<br />
need to formulate the optimization problem in rigorous mathematical terms. We proposed a<br />
mathematical formalism and a procedure for the PBD mapping process in [43].<br />
To explain the basic ideas of the process, we consider first the analogous, but simpler case in<br />
the EDA domain, the classic logic synthesis flow [48]. In this flow, the behavioral portion of<br />
the design is captured using Register Transfer Languages (RTLs) such as Verilog and VHDL.<br />
103/ 156
<strong>Architecture</strong> <strong>Modeling</strong><br />
The architecture platform is represented by a gate library which contains different types of<br />
logical gates, each with its cost related to area, speed and power consumption. The mapping<br />
process selects a set of interconnected gates from the gate library such that the functionality<br />
of the network is the same as the one represented by the RTL. To optimize the gate selection<br />
process, the semantic domain of the RTLs is first restricted to synchronous designs. Then,<br />
the RTL is translated into Boolean expressions; the same semantic domain is chosen for the<br />
gates in the library. To ease the gate selection process, both the Boolean equations and the gate<br />
library are transformed into net-lists consisting of a primitive logical gate, such as a NAND2.<br />
At this point, mapping, known in logic synthesis as technology mapping, is then reduced to a<br />
minimum cost covering problem. Since optimal covering is NP-hard, heuristic algorithms are<br />
used. Note that this mapping process is based on a common primitive - NAND2 gate - and<br />
mathematical rules for defining the behavior of a set of interconnected primitives - Boolean<br />
logic. Boolean logic is appropriate for synthesizing combinational logic between registers in<br />
a synchronous hardware design. Hence, the process involves three aspects: restriction of the<br />
functional domain to synchronous circuits, choosing a common mathematical representation<br />
(Boolean expressions), and representing the functionality and architecture platform in terms of<br />
primitives (NAND2).<br />
We believe that these three aspects can be generalized and used to help solve any mapping<br />
problem at system level. In the general system setting, however, each of these three aspects is<br />
challenging. The models of computation used in system design are varied and certainly more<br />
complex than Boolean logic with synchronous timing. The selection of a common mathematical<br />
language for both the functionality and the architecture platform depends on critical decisions<br />
involving expressiveness and ease of manipulation. Finally, selecting the primitive elements to<br />
use involves a trade-off between granularity and optimality: coarser granularity allows the use<br />
of exhaustive search techniques that may guarantee optimality while finer granularity allows the<br />
possibility of exploring, albeit non-optimally, a much larger search space.<br />
The formal mapping procedure is shown in Figure 5.24. Initially, we are given function and<br />
architecture models, which are constructed from the functional specification and architecture<br />
platform. During Stage 1 of the procedure, a common modeling domain (CMD) is chosen by<br />
the designers for representing the functionality and architecture (platform). When choosing a<br />
proper CMD, both the semantics and abstraction level for mapping are decided by considering<br />
the trade-off between the size of the mapping space and the complexity of finding a good point<br />
within this space. In Stage 2, a CMD-specific covering problem is formulated and solved by<br />
automatic algorithms. Stage 3 is added to capture all further optimization that may be needed<br />
to tune the design. It includes design concerns that have not been modeled within the covering<br />
problem formulation because they make the solution of the covering problem too complex.<br />
5.2.5 Managing Risk<br />
The realization of complex systems calls for design processes that mitigate risks in highly concurrent,<br />
distributed, and typically multi-domain engineering processes, often involving more<br />
than one hundred sub-processes. Risk mitigation measures typically cover all phases of design<br />
processes, ranging from assuring high quality initial requirements to early assessments of risks<br />
in realizability of product requirements during the concept phase, to enforcing complete traceability<br />
of such requirements with requirements management tools, to managing consistency and<br />
synchronization across concurrent sub-processes using PLM tools. The topic of achieving high<br />
quality of initial requirements has already been addressed above.<br />
A key challenge rests in balancing risk reduction version development time and effort. For<br />
104/ 156
<strong>Architecture</strong> <strong>Modeling</strong><br />
Figure 5.24: Multi-Layer Optimization<br />
most classes of applications, which cannot benefit from a significant re-use and/or similarity<br />
to existing product designs – and it is these, where the issue of realizability is most crucial<br />
- achieving 100% of confidence in realizability of requirements essentially boils down to do<br />
doing the complete design, taking ad adsurbum the very notion of a concept phase. Similarly,<br />
completely eliminating the risks stemming from concurrent engineering essentially requires a<br />
complete synchronization along a fine-grained milestone structure, which would kill any development<br />
project due to the induced delays. To cope with the challenge of risk-mitigation with<br />
balanced effort, the integrated project SPEEDS has proposed the concept of what we called<br />
“controlled speculative design” [15]. Due to the de-facto unachievable fine-grained synchronization,<br />
current practice leads to typically implicit assumptions about design aspects to be<br />
guaranteed by concurrent processes – designers are “speculating” on outcomes of concurrent<br />
engineering sub-processes, based on their experiences from previous designs. We propose to<br />
make such assumptions explicit – another use case indicating the high methodological value<br />
of assumptions – and associate these with risk-levels, which qualify or quantify the expected<br />
risks in not achieving such assumptions. This very same instrument can be put in place during<br />
the concept phase of development processes, where vertical assumptions form the key basis<br />
for assessing realizability of requirements. We see the following key use-cases for exploiting<br />
risk-level labeled assumptions within risk-mitigation strategies, assuming a setting with multiviewpoint<br />
contracts:<br />
A. Extending requirement management to dependency analysis and management between processes<br />
B. Sensitivity analysis for hot-spot detection<br />
C. Controlling speculation in concurrent design processes<br />
D. Impact analysis of late requirement changes<br />
E. Impact analysis of changing design bases<br />
105/ 156
<strong>Architecture</strong> <strong>Modeling</strong><br />
Regarding A, we extend requirements management tool in exploiting the structure of contracts<br />
to maintain a full dependency graph between guarantees and their supporting assumptions<br />
including risk levels. Prototype implementations of this based on the Reqtify product of<br />
Geensys (now a Dassault company) have been developed in the context of the integrated project<br />
SPEEDS. This immediately supports D, and goes beyond current practice in its capability to<br />
quantify the risk level for the parts of the design which must be modified.<br />
Regarding B, we propose to generalize techniques used in safety analysis (such as FTA and<br />
FMEA) to identify what can be seen as the analogue to critical cut sets in fault-tree analysis,<br />
i. e. minimal sets of high-risk assumptions, whose un-realizability would endanger the overall<br />
product objectives. This calls for a calculus for contracts for non-functional requirements, as<br />
also needed for virtual integration testing discussed above. We can then use standard approaches<br />
such as localized design space exploration or rapid prototyping to reduce the risk level of such<br />
critical assumptions to a level balancing the overall trade-off between risk-mitigation and design<br />
time and design effort.<br />
Regarding C, the same approach of assessing the criticality of risk-levels for critical sets of<br />
assumptions within individual sub-processes to achieve this sub-processes objectives can be<br />
used to trigger synchronization with processes responsible for establishing such assumptions to<br />
reduce their risk-level. Within the integrated projects SPEEDS, we have developed a process<br />
advisor [29] for on-line monitoring the risk-level of assumptions as basis for advices on such<br />
risk-reducing measures.<br />
Regarding E, we can assess the effect of replacing parts of the design basis by computing<br />
the cumulative risk induced from partially invalidated assumptions induced by the change, if<br />
any. Ideally, the effect of the change can be completely encapsulated by re-establishing the<br />
contracts of the original design base. If this is not achievable, one can exactly identify the<br />
violated assumptions and quantify the resulting risk.<br />
5.2.6 Summary<br />
The above sections give ample evidence of the high industrial relevance of contracts. Their syntactic<br />
simplicity and intuitive appeal allow for easy adaptation by system-engineers, as testified<br />
by key users within the SPEEDS projects. In their most elementary form, they may just take<br />
the form of informal textual requirements, yet with the key distinguishing feature of explicating<br />
the separation of concerns: what must be guaranteed by the system itself, and what are the constraints<br />
on environments, which are fundamentally required so as to allow the system – based<br />
on such assumptions – to enforce its guarantees. We have then seen how this core paradigm<br />
matches well with the orthogonal notion of aspects: contracts can thus be flagged as to the aspect<br />
of the system they relate to. Clearly, the number of aspects to be supported may vary from<br />
application to application – thus it is up to the customization of contract-based design within<br />
a company’s development process, to determine the set of aspects that must be supported. For<br />
sure, this will go beyond capturing the functionality, with safety- and real-time aspects being a<br />
necessity in safety relevant embedded systems development. Business related viewpoints such<br />
as reflecting costs, constraints from manufacturing, maintainability are natural choices, as are<br />
those related to resource consumption.<br />
Orthogonal to this discussion is the degree of formalization used in contracts. As highlighted<br />
above, there is already high methodological value when using informal contracts. A natural<br />
next step is to restrict the vocabulary of contracts to (domain specific) ontologies. Further steps<br />
towards formalization are viewpoint dependent: as elaborated in subsequent sections, they can<br />
take the form of automata-based specifications, employ suitable logics, build on a library of<br />
106/ 156
<strong>Architecture</strong> <strong>Modeling</strong><br />
patterns, capitalize on sequence charts. Within the project <strong>SPES</strong>, we advocate the use of the<br />
pattern based requirement specification language RSL, see Section 6.1. The additional effort in<br />
providing a degree of formalization is typically well invested due to the additional benefits we<br />
have outlined above, such as testing consistency of requirements, identifying complex integration<br />
errors early through virtual integration testing, boosting re-use though component based<br />
design, and allowing cross layer design optimizations based on performing platform based design.<br />
The key point we raise, is that this formalization can be done incrementally and on a<br />
case by case basis. Thus, there is a clear migration strategy from using contracts informally,<br />
to incorporating domain ontologies, to gradually enriching the number of covered viewpoints,<br />
and to gradually increase the degree of formalization. No matter in which order such steps are<br />
taken, each of these comes with significant potentials for process improvements.<br />
In spite of, or rather: due to their simplicity, the range of applicability of contracts in embedded<br />
systems design is overwhelming. There is almost no phase in V-based development<br />
processes, where today´s engineering practices would not benefit from the boost of process<br />
improvements offered through contract-based design: the already extensive compilation of design<br />
methods discussed in this section is by no means complete. Additional use-cases relate to<br />
the usage of contracts in model-based testing, in automatic code-generation, in registering new<br />
players in system-of-system designs, etc. This combination of simplicity and extremely high<br />
methodological value are in our view a strong indicator for the identification of a fundamental<br />
design principle, already implicitly underlying many of today´s engineering practices, but so<br />
far a treasure hidden.<br />
107/ 156
6 Annex<br />
108/ 156
<strong>Architecture</strong> <strong>Modeling</strong><br />
6.1 Syntax and Semantics of RSL<br />
Stating requirements is one of the essential tasks in developing products. These requirements build an<br />
interface between different groups of people, i.e. customers, engineers, project managers and many<br />
more.<br />
Typically requirements are stored as natural language text which has the disadvantage that<br />
ambiguities of the sentences can cause a huge amount of requirement changes in early as well in later<br />
development phases. To reduce the costs coming from these ambiguities formal languages are used<br />
to have a fixed semantic meaning for a requirement. But it does not only require some training to write<br />
requirements in these formal languages, it can also be hard to read them.<br />
The pattern based RSL fills this gap by providing an easy to learn formal language with a fixed<br />
semantic that is still readable like natural language.<br />
Patterns consist of static text elements and attributes being filled in by the requirements engineer.<br />
Each pattern has a well defined semantic in order to ensure a consistent interpretation of the written<br />
system specification across all project participants. On the one hand this limits the possibilities of<br />
writing a requirement on the other hand it prevents misunderstandings regarding the interpretation of<br />
the sentences. To gain a set of quality requirements this limitation is necessary. However writing<br />
requirements shall still be possible in an intuitive way. Patterns allow the writing of natural sounding<br />
requirements with defined semantics while being expressive enough to formalize complex<br />
requirements.<br />
To gain a high degree of intuitivism the language shall consist of only a few constructs that can be<br />
easily remembered to give the requirement engineer the possibility to fully understand the RSL and<br />
choose the right pattern that fits the properties he wants to demand on the system.<br />
There exist patterns for each of the following categories:<br />
Functional Patterns<br />
These Patterns express functional requirements of the system. This includes the relationship<br />
between events, handling of conditions and invariants and the possibility to define intervals in<br />
which the requirements or parts of them are valid.<br />
Probability Patterns<br />
In nearly all safety critical system it is necessary to express failure or hazard probabilities.<br />
Since there are various partly redundant forms of expressing probabilities that were used quite<br />
ambiguous in common speech, these patterns guide the requirements engineer to express his<br />
needs.<br />
Safety related Patterns<br />
Only a small part of safety related requirements can be covered with probability patterns. The<br />
major part of the requirements outlines relationships between system components. These<br />
patterns enable the specification of single point of failures or other failure and hazard<br />
dependencies between different components.<br />
Timing Patterns<br />
These patterns can be used to describe real-time behavior of systems. This includes periodic<br />
and aperiodic activations, jitter or delay.<br />
Mapping Patterns<br />
These patterns can be used to express requirements on the mapping from the functional<br />
design perspective to the physical design perspective.<br />
Patterns are noted in a form with optional parts that are not necessarily instantiated. A functional<br />
pattern describing the causality between two events does look like this:<br />
whenever request occurs response occurs during [0ms,10ms].<br />
Phrases in square brackets are considered optional, bold elements are static keywords of the pattern<br />
and italic printed elements represent attributes that have to be filled out by the requirements engineer.<br />
When filling the attributes there are no general restrictions on the names but they should be<br />
descriptive. The names of the attributes can be used later to be mapped to a given architecture or they<br />
109/ 156
can be uused<br />
to generate<br />
the arch hitecture. Whhen<br />
specifyin ng requireme ents there is nno<br />
strict typin ng like int<br />
or real but<br />
there are categories th hat specify wwhat<br />
is described<br />
by the different d attribbutes.<br />
To not ccomplicate<br />
thhe<br />
language e too much and to be also a expressive<br />
enough the set of supported s<br />
attributess<br />
has to be ccarefully<br />
chosen:<br />
Event<br />
Events repreesent<br />
the act tivity in the syystem.<br />
An ev vent can be for f example a received signal,<br />
a<br />
uuser<br />
input byy<br />
a pressed button, b a commputational<br />
result r or the change of a value. Event ts occur<br />
aat<br />
one point of time and have h no duraation<br />
in time. .<br />
CCondition<br />
A condition is<br />
a logic and d/or arithmetiic<br />
expression n based on variables v andd<br />
the status of<br />
eevents.<br />
Condditions<br />
can be b used in twwo<br />
different ways w in patter rns. On the oone<br />
hand the ey can be<br />
uused<br />
as pseudo<br />
events to t trigger an action if the condition becomes<br />
true. On the other<br />
hand<br />
tthe<br />
conditionn<br />
can be the system statee<br />
that has to hold for a sp pecified time.<br />
The values s the<br />
ccondition<br />
is bbased<br />
on ma ay change wiith<br />
time only.<br />
IInterval<br />
Intervals desscribe<br />
a cont tinuous fragmment<br />
of time which can ha ave relative aand<br />
quantita ative time<br />
mmeasures<br />
ass<br />
delimiters or o events. Inttervals<br />
can be b open “]x,y[“<br />
or closed “ “[x,y]” or a<br />
ccombination<br />
of them.<br />
JJitter<br />
JJitter<br />
of an eevent<br />
is the variation<br />
in thhe<br />
point of tim me of occurre ence in a reaal<br />
time contex xt. In this<br />
ddocument<br />
jittter<br />
is conside ered as alwaays<br />
positive, i.e. the even nt is delayed. .<br />
CComponentt<br />
CComponentss<br />
refer to entities<br />
that aree<br />
able to hand dle events or r condition vaariables.<br />
Typ pically<br />
tthese<br />
compoonents<br />
refer to t an actual architecture, , but in early design stagees,<br />
where the<br />
system<br />
hhas<br />
not beenn<br />
designed completely c thhere<br />
are also “possible” component<br />
naames<br />
allowe ed. These<br />
iidentifiers<br />
caan<br />
either be used u to geneerate<br />
the mis ssing architec cture or be mmapped<br />
to the<br />
design<br />
iin<br />
later development<br />
stag ges.<br />
6.1.1 PPattern<br />
sppecification<br />
In this ssection<br />
the different pat tterns get described<br />
in more detail.<br />
The patterns<br />
are liste ed in the<br />
previoussly<br />
mentioned<br />
categories s. Some of tthe<br />
patterns can be use ed to expresss<br />
requireme ents from<br />
more thaan<br />
one cateegory.<br />
Althou ugh there arre<br />
only listed d in the mos st used cateegory,<br />
other applying<br />
categoriees<br />
are menttioned<br />
in the e descriptionn.<br />
For each pattern the syntax and a descriptio on of the<br />
semanticcs<br />
are providded.<br />
In secti ion 6.1.2 wee<br />
give an exe emplary view w on the formmal<br />
semantics<br />
of the<br />
observerr<br />
of a patternn<br />
that is used d to verify thee<br />
correct beh havior of a co omponent aggainst<br />
a requirement.<br />
6.1.1.1<br />
Functionnal<br />
Pattern n:<br />
<strong>Architecture</strong> <strong>Modeling</strong><br />
The funcctional<br />
patterns<br />
describe e relationshipps<br />
between events, cond dition and suubjects.<br />
For example<br />
events ccan<br />
depend on other ev vents or connditions<br />
have e to hold af fter an evennt<br />
has occurred.<br />
This<br />
pattern ccan<br />
be usedd<br />
to express the functional<br />
behavior of a system.<br />
Since all paatterns<br />
have e optional<br />
interval aattributes,<br />
thhese<br />
patterns s can also bbe<br />
used to ex xpress simple<br />
timing connstraints.<br />
On n the one<br />
hand theese<br />
constrains<br />
may refer<br />
to events and conditio ons, on the other o hand tthese<br />
constrains<br />
may<br />
refer to rreal<br />
time.<br />
Functionnal<br />
pattern coonsist<br />
of a tr rigger and ann<br />
action. If the<br />
trigger oc ccurs, the paattern<br />
“starts”<br />
and the<br />
action haas<br />
to occur tooo.<br />
110/ 156
6.1.1.1.1<br />
Attribuute<br />
Definit tion and SSemantics<br />
There are<br />
three kinds<br />
of attribu utes that aree<br />
used in th he functional<br />
patterns: EEvents,<br />
Inter rvals and<br />
Conditions.<br />
In most ccases<br />
these attributes arre<br />
intuitive to o use and no o special knoowledge<br />
is necessary n<br />
to speciffy<br />
requiremeents.<br />
This se ection defines<br />
the exact syntax and semantic of basic and advanced a<br />
features of the attribuutes<br />
and its possible p connversions<br />
and d combinatio ons.<br />
6.1.1.1.1.1<br />
Evennts<br />
Events aare<br />
signals thhat<br />
occur at a defined pooint<br />
in time. Examples ar re messagess<br />
that get se ent over a<br />
bus systtem,<br />
sporadic<br />
signals fr rom sensorss<br />
or even us ser interactio on like presssing<br />
a butto on. While<br />
specifyinng<br />
events thhe<br />
names ca an be choseen<br />
by the re equirements engineer, bbut<br />
have to be used<br />
consistently,<br />
i.e. samme<br />
events ha ave to have the same id dentifiers. If there<br />
exists aan<br />
architectu ure these<br />
names hhave<br />
to be mapped<br />
to the e correspondding<br />
parts in the t design model m in laterr<br />
design stag ges.<br />
Specifyy<br />
locationn<br />
of event occurrencce<br />
It is posssible<br />
to specify<br />
for each event e the loccation<br />
where it occurred.<br />
A compoonent<br />
can reefer<br />
to system m componennts<br />
like “Brak ke Actuator” or “Engine CController”<br />
bu ut also to<br />
non systtem<br />
artefactss<br />
like “Driver r” or “Passennger”.<br />
It is hig ghly recomm mended to usse<br />
the same identifier<br />
for samee<br />
componentts.<br />
In later ddesign<br />
steps the compon nent identifierrs<br />
can be ma apped to the actual archiitecture<br />
of the<br />
system<br />
to start aanalysis<br />
taskks.<br />
Even the consistent uuse<br />
of identif fiers can be one o of the poossible<br />
analy yses, it is<br />
not part of the speciffication<br />
langu uage to guaraantee<br />
consis stency, but allow<br />
the checcking<br />
of it.<br />
The termm<br />
“Componeent”<br />
can be fu urther refinedd:<br />
and<br />
The requesst<br />
event star rts the patterrn<br />
and requires<br />
a respon nse in the defined<br />
time frame. Is<br />
there no request<br />
event there is no specification n for the occurrences<br />
of tthe<br />
response<br />
events.<br />
There mighht<br />
be such an n event or noot.<br />
But of courrse<br />
there might<br />
be otheer<br />
patterns th hat restrict the t occurrennces<br />
of the response<br />
event.<br />
Event on<br />
whenever GearUp on ShifttPaddleCon<br />
ntroller<br />
occurs duuring<br />
[0ms s,100ms].<br />
Event on<br />
Event on<br />
Component t<br />
user User r<br />
system Sy ystem<br />
<strong>Architecture</strong> <strong>Modeling</strong><br />
Component<br />
Useer<br />
System S<br />
occurs oopen<br />
on<br />
clutch<br />
It is posssible<br />
to use component and user or system. The e later ones can be usedd<br />
to explicitly y mention<br />
user inteeraction<br />
or syystem<br />
behav vior.<br />
111/ 156
Constrrain<br />
Eventts<br />
with Intervals<br />
It is not always wanted<br />
to react on every occcurrence<br />
of f an event. Constraining<br />
C<br />
an event through<br />
an<br />
interval is<br />
a natural wway<br />
of filterin ng events. Thhis<br />
can be ac chieved by th he following nnotation:<br />
Event durring<br />
[inte erval]<br />
An exammple<br />
shall demonstrate<br />
th he use of thiss<br />
language construct<br />
A responsee<br />
to a request<br />
shall only bbe<br />
send if the e system got activated through<br />
a mes ssage.<br />
This behavior<br />
can be fo ormalized to:<br />
whenever<br />
occurs.<br />
request t during<br />
<strong>Architecture</strong> <strong>Modeling</strong><br />
[activa ate,deacti ivate] ooccurs<br />
re esponse<br />
There are eevents<br />
that indicate<br />
the aactivation<br />
an nd the deactivation<br />
of thee<br />
system/component.<br />
Only the requests<br />
that occur o duringg<br />
the specifie ed interval will<br />
trigger thiss<br />
pattern. The<br />
interval<br />
acts like a filter on the event. For mmore<br />
informa ation on inter rvals see secction<br />
6.1.1.1.1.2.<br />
It is<br />
also possibble<br />
to use the e different kinnd<br />
of bracket ts here for th he interval ass<br />
described in<br />
section<br />
0. Further the<br />
usage of real times (liike<br />
5 ms) is allowed a in the<br />
intervals.<br />
The patternn<br />
above typic cally needs a refinement, , since the sp pecification oof<br />
the respon nse event<br />
lacks an intterval<br />
where it should occcur.<br />
The bassic<br />
block for building eve ent expressioon<br />
with “during”<br />
is shown<br />
below. Forr<br />
a description<br />
of the<br />
construcction<br />
of open and closed intervals fromm<br />
this basic block refer to o section 0.<br />
Complexx<br />
expressionn<br />
can be buil lt by nestingg<br />
of multiple during expre essions. For each nestin ng level a<br />
basic block<br />
is instaantiated<br />
that sends a teemporary<br />
ev vent to the higher levell.<br />
Depending g on the<br />
integratioon<br />
in the oveerall<br />
context, , the states “ “0” and “1” are a merged in nto the “pre” ” state resulting<br />
in the<br />
“out” state<br />
to ensure correct beha avior when mmultiple<br />
instances<br />
of the event e occur.<br />
112/ 156
Constrrain<br />
Eventts<br />
with Co onditions<br />
In additioon<br />
to filteringg<br />
events with h intervals it iis<br />
also possible<br />
to constr rain events thhrough<br />
a con ndition by<br />
the followwing<br />
expresssion:<br />
Event undder<br />
(Condi ition)<br />
<strong>Architecture</strong> <strong>Modeling</strong><br />
To illustrrate<br />
the usagge,<br />
the exam mple above neeeds<br />
only slight<br />
changes s:<br />
Requirement:<br />
The syste em shall reacct<br />
on reques sts with a res sponse if thee<br />
status of the<br />
system<br />
is active.<br />
Now the evvents<br />
got rep placed by a conditional expression. The correspponding<br />
patte ern looks<br />
like this:<br />
whenever request under u (staatus<br />
== ac ctive) occ curs respoonse<br />
occurs.<br />
The patternn<br />
above typic cally needs a refinement, , since the sp pecification oof<br />
the respon nse event<br />
lacks an intterval<br />
when it<br />
should occur.<br />
In the coorrespondingg<br />
observers the t guard off<br />
the transitio on that is enabled<br />
with cconstrained<br />
event e has<br />
to be exttended<br />
with tthe<br />
constrain ning conditionn:<br />
113/ 156
Sequences of Events<br />
It is typical to specify the order of the occurrences of different events. To do so, there are two<br />
language constructs:<br />
and<br />
Event and then Event<br />
N times Event<br />
<strong>Architecture</strong> <strong>Modeling</strong><br />
Sequences with “and then”<br />
The “and then” construct postulates a sequence of events. The following example demonstrates the<br />
use of the pattern.<br />
Requirement: When a crash was detected, first the airbag shall inflate and then the doors<br />
shall be unlocked.<br />
whenever CrashDetected occurs InflateAirbag and then UnlockDoors<br />
occurs.<br />
This pattern does not say anything about timing, it just specifies the order. To express timing<br />
behaviour it is possible to use intervals with the events. E.g. if the door shall be unlocked in<br />
at least 50 ms after the airbag inflated the pattern would look like this:<br />
whenever CrashDetected occurs ReCheckSensors and then InflateAirbag<br />
and then UnlockDoors during [0ms,50ms] and then EngineOff during<br />
[0ms,300ms] occurs.<br />
The “during” with timing entities differs semantically from the filter that can be used to constrain<br />
events. If “during” with timing entities is used in an “and then” statement the interval is demanding, i.e.<br />
that the event has to occur in the specified interval. The timer starts with the occurrence of the<br />
preceding event. If the event does not occur in the specified interval the “and then” statement<br />
continues its execution from the latest previous event in the chain, that was not constraint by timing<br />
properties. The clock for the interval with the timing constraints is restarted by this event. This means<br />
for the above example that a failing of the EngineOff events 300ms after the unlocking of the doors,<br />
the observer would wait for a new InflateAirbag message, since this event has no timing constraints to<br />
the preceding event.<br />
In contrast to timing intervals the use of events in the intervals is semantically identical to the filter<br />
described in section 0.<br />
This backtracking behaviour can be further specified by the use of brackets.<br />
whenever a occurs b and then (c and then d and then e during<br />
[0ms,7ms]) occurs.<br />
If e does not occur in the specified interval the observer would wait for a new c instead of a<br />
new d.<br />
114/ 156
These events used in the “and then” statement, of course, can be also limited with conditions. In the<br />
corresponding observers an additional automaton is used to process the “and then” expression.<br />
idle<br />
idle<br />
idle<br />
idle<br />
start<br />
start<br />
pre<br />
e2<br />
e:=true<br />
e = e1 and then e2<br />
pre<br />
e1<br />
e = e1 and then e2 during[3,5]<br />
start<br />
start<br />
e2 && (3
Occurrences of a set of events in and arbitrary order<br />
To specify the occurrences of a set of events without constraining their internal order, the “set”<br />
statement can be used.<br />
set{event1, event2, event3…} during Interval<br />
A “set” statement is semantically equivalent to the permutation of all possible sequences of events<br />
expressed by “and then” statements.<br />
(event1 and then event2 and then event3 … during Interval) OR<br />
(event1 and then event3 and then event2 … during Interval) OR<br />
(event2 and then event1 and then event3 … during Interval) OR …<br />
Unwanted events<br />
Especially in sequences of events it is necessary to specify that there shall be no occurrences of some<br />
events in a special interval:<br />
Event not during Interval<br />
This language construct is an event that occurs at the end of interval, if there was no occurrence of<br />
this event. There is no relation to the filter construct “Event during interval”.<br />
Creating Events from Conditions<br />
It can be necessary to define the point in time where a condition becomes true or false. This is done<br />
by the language constructs tr() and fs():<br />
and<br />
tr(Condition)<br />
fs(Condition)<br />
<strong>Architecture</strong> <strong>Modeling</strong><br />
Requirement:<br />
If the cooling liquid exceeds 120 degrees celcius send a warning message.<br />
Formalization:<br />
whenever tr( liquitTemperature > 120) occurs<br />
CoolingLiquidWarningMessage occurs.<br />
To formulate requirements where a condition is true during a defined interval the following language<br />
construct can be used:<br />
Condition holds during Interval<br />
Example Requirement: If the start button gets pushed signal a and signal b shall be equal for<br />
at least 5 seconds.<br />
116/ 156
Formalization:<br />
whenever StartButtonPushed occurs (SignalA == SignalB) holds during<br />
[0s,5s] occurs.<br />
There is also a pattern that specifies that a condition shall not be true during a defined interval:<br />
Condition holds not during Interval<br />
This implies that the condition can be true at some point in the interval, but cannot be true for the<br />
whole interval.<br />
Creating Events from Intervals<br />
It can be useful to describe the end of an interval, especially if there were additional constraints to that<br />
interval..<br />
or<br />
At end of Interval<br />
fs(in[interval])<br />
Logical operations on Events<br />
There exist some logical operations on events:<br />
OR<br />
event1 OR event2 accepts both events. This expression can be used in the trigger as well as in the<br />
action.<br />
AND<br />
Event1 AND event2 only occurs if event1 and event2 occur at the same time. The order of the<br />
occurrence does not make a difference. It is only necessary that at no clock in the timed automata is<br />
running between the occurrences of the events. Note that there is no “NOT” operator for events.<br />
Grouping of Events<br />
Events can be grouped through the “.” operator.<br />
Group.Event<br />
<strong>Architecture</strong> <strong>Modeling</strong><br />
These groups refer to ports in the architecture of the specified system. This might be necessary if<br />
there exist events with the same name in different ports.<br />
117/ 156
6.1.1.1.1.2<br />
Intervvals<br />
Intervalss<br />
describe the<br />
“chunk” of time betweeen<br />
two points s in time. The ese points inn<br />
time can ei ither be a<br />
event orr<br />
a timed value.<br />
In case of events thee<br />
first occurr rence of the startevent sstarts<br />
the inte erval and<br />
the first ooccurrence<br />
oof<br />
the endeve ent ends the interval:<br />
In case<br />
timers.<br />
[starteveent,<br />
endev vent]<br />
that timed vvalues<br />
are the<br />
boundaries<br />
for an in nterval there must be reeference<br />
poin nt for the<br />
whenever<br />
<strong>Architecture</strong> <strong>Modeling</strong><br />
Request occurs o Ressponse<br />
occ curs durin ng [0ms,500ms].<br />
The times iin<br />
the action part refer too<br />
the activati ion point of the t pattern thhrough<br />
the trigger. t In<br />
that sense it is not allow wed to use “nnot<br />
bound” times<br />
values in the triggeer.<br />
The only exception e<br />
where timed<br />
values are e allowed in the trigger are a “and then”<br />
statementts,<br />
where the e interval<br />
refers to thee<br />
occurrence e of the previious<br />
event.<br />
Open/CClosed<br />
inttervals<br />
The bracces<br />
for writing<br />
the interva als can be ussed<br />
to expres ss open and closed intervvals:<br />
[a,b] -> close ed, closed intterval<br />
]a,b[ -> open ned, opened interval<br />
Butt<br />
also the oth her combinattions<br />
are pos ssible:<br />
[a,b[ -> close ed, opened innterval<br />
]a,b] -> open ned, closed innterval<br />
Closed intervals<br />
ends<br />
indicate that<br />
the point iin<br />
time where e the event occurs o still beelongs<br />
to the e interval,<br />
open inteerval<br />
ends inndicate<br />
that the<br />
point in time<br />
at the ev vents represe enting the boorder<br />
does not<br />
belong<br />
to the intterval.<br />
The exact<br />
semanticss<br />
of open and d closed inteervals<br />
are de escribed by showing s the nneeded<br />
mod difications<br />
of the foollowing<br />
basic<br />
block that constrains tthree<br />
events s to occur in a given ordder<br />
without re espect to<br />
time; thiss<br />
generic kinnd<br />
of interval<br />
is denoted by “{..}”. This<br />
basic bloc ck is used too<br />
build complex<br />
event<br />
expressiion<br />
or whole patterns:<br />
118/ 156
<strong>Architecture</strong> <strong>Modeling</strong><br />
Basic bloock<br />
transformmed<br />
for interv vals with opeen<br />
start and with w open en nd:<br />
Basic bloock<br />
transformmed<br />
for interv vals with botth<br />
open start and open en nd:<br />
Basic bloock<br />
transformmed<br />
for interv vals with clossed<br />
start:<br />
119/ 156
Basic bloock<br />
transformmed<br />
for interv vals with clossed<br />
start and d with closed d end:<br />
Basic bloock<br />
transformmed<br />
for interv vals with botth<br />
closed start<br />
and closed d end:<br />
For interrvals<br />
with timmed<br />
values instead<br />
of evvents<br />
simple e parallel aut tomata are nneeded<br />
that generate<br />
events aat<br />
the specifieed<br />
points in time. t<br />
Nestedd<br />
intervalss<br />
The posssibility<br />
of constraining<br />
ev vents througgh<br />
intervals allows a the formulation<br />
of f patterns wit th nested<br />
intervalss.<br />
Especially if there are e events ussed<br />
multiple times in dif fferent intervvals<br />
the nee ed for an<br />
evaluatioon<br />
principle ffor<br />
intervals becomes b impportant.<br />
In generral,<br />
all intervaals<br />
are indep pendent fromm<br />
each other<br />
and get sta arted and ennded<br />
separately.<br />
One<br />
single evvent<br />
can starrt<br />
and end multiple<br />
intervvals.<br />
Ack durinng<br />
[a, b during d [a, ,c]]<br />
Run: a, ACK<br />
Run: a, b, AACK<br />
Run: a, c, bb,<br />
ACK<br />
<strong>Architecture</strong> <strong>Modeling</strong><br />
(accepted)<br />
(not accepteed)<br />
(accepted)<br />
The first runn<br />
is the mos st obvious caase:<br />
a starts the interval in which Ackk<br />
can be acc cepted. In<br />
the second run a also starts s the intterval<br />
where Ack shall be e accepted. TThis<br />
a starts s also the<br />
second inteerval,<br />
which is<br />
required foor<br />
b. b occurs s and ends the<br />
interval reequired<br />
by Ack, A so an<br />
occurrence of Ack would<br />
not be acccepted.<br />
The last<br />
run ends s the interval of b with c, so b gets<br />
not accepteed<br />
and the interval<br />
for Acck<br />
is still valid d.<br />
120/ 156
6.1.1.1.1.3 Conditions<br />
Conditions can be evaluated at every point in time to a Boolean value. Conditions can be connected<br />
with logical operators. The atomic elements are variables that may be later assigned to continuous<br />
variables in the design phase and constant values.<br />
Logical operators<br />
|| OR<br />
&& AND<br />
^^ XOR<br />
==> Imply<br />
== Equal<br />
!= Not equal<br />
< Less than<br />
> Greater than<br />
= Greater or equal<br />
Arithmetic Operators<br />
+ Addition<br />
- Subtraction<br />
* Multiplication<br />
\ Division<br />
% Modulo<br />
Specify the location of Conditions<br />
Similar to event occurrences the location where a condition shall hold can be specified:<br />
Condition on Component<br />
Example: always (speed < 200) on vehicle.<br />
Using Intervals in Conditions<br />
To address intervals in conditions “in” can be used:<br />
in [Interval]<br />
<strong>Architecture</strong> <strong>Modeling</strong><br />
Requirement: If the start button gets pushed the inner and outer temperature of the heater<br />
shall be the same unless the security doors are opened.<br />
Formalization:<br />
whenever startPushed occurs (innerTemp == outerTemp ^^<br />
in[secdoorsOpen, secdoorsClosed]) holds during [0ms,stop].<br />
121/ 156
6.1.1.1.2<br />
Properrty<br />
Definition<br />
Some ppatterns<br />
alloww<br />
slightly different<br />
interrpretations<br />
of o their beha avior. This ccan<br />
be cont trolled by<br />
attributess<br />
that are apppended<br />
to th he pattern.<br />
6.1.1.1.2.1<br />
Iterattive<br />
vs. Flowing<br />
Obbservation<br />
[D.2.4.5] ] Patterns, in<br />
general, express e reactive<br />
behavior<br />
of the fo orm: "triggerring<br />
behavio or implies<br />
promisedd<br />
behavior" wwhich<br />
means:<br />
wheneverr<br />
the triggerin ng behavior is identified at some tim me instant<br />
or intervval,<br />
the prommised<br />
behavio or will occur r at some tim me instant or r interval righht<br />
now or in bounded<br />
future.<br />
wheneveer<br />
car-reqquest<br />
occu urs car-arrrives<br />
oc ccurs during<br />
[0min, 3min]<br />
For instaance,<br />
in the aabove<br />
instantiated<br />
patterrn<br />
"car-reque est" is the trig ggering behaavior,<br />
and "ca ar-arrives<br />
within 3mmin"<br />
is the ppromised<br />
be ehavior. An ooccurrence-in<br />
nstance of th he behavior of a reactiv ve pattern<br />
refers too<br />
the duratioon<br />
that starts s with an ideentification<br />
of o the triggering<br />
behavioor<br />
and ends with the<br />
followingg<br />
occurrencee<br />
of the promised<br />
behavioor.<br />
A patternn<br />
can be useed<br />
in two manners,<br />
depennding<br />
on the evaluation of o its occurreence-instance<br />
es:<br />
<br />
<br />
Pattern.<br />
In the "iterattive"<br />
manner r only iterativve<br />
occurrenc ce-instances s of the behaavior<br />
are considered,<br />
nnamely:<br />
nextt<br />
identificatio on of triggerinng<br />
behavior does not sta art before thee<br />
end of the promised<br />
bbehavior<br />
of previous instance<br />
(hencee,<br />
a triggerin ng behavior that occurs wwhile<br />
an occ currence-<br />
iinstance<br />
takees<br />
place is ig gnored).<br />
In the “flowinng”<br />
manner, every occurrrence-instanc<br />
ce of the beh havior is conssidered.<br />
In practicce,<br />
most of tthe<br />
patterns‟ ‟ usage is off<br />
the iterative e manner. Flowing<br />
interppretation<br />
is significant s<br />
only when<br />
there is one-to-one matching between<br />
occu urrences of the triggerinng<br />
behavior and the<br />
promisedd<br />
behavior; ffor<br />
instance, when the prromised<br />
behavior<br />
is expe ected to occuur<br />
fixed dura ation after<br />
the triggeering<br />
behavior.<br />
There arre<br />
two kinds of flowing in nterpretation.<br />
For both ki inds (both kinds<br />
are speecified<br />
by the e attribute<br />
flowing) a new instannce<br />
of the pa attern becommes<br />
active fo or each occurrence<br />
of thee<br />
trigger and d requires<br />
an action<br />
in the inteerval.<br />
In the standard caase<br />
one occ currence of the t action caan<br />
terminate e multiple<br />
active instances<br />
of thhe<br />
same pattern.<br />
If the aadditional<br />
attr ribute “once” is specified,<br />
for each oc ccurrence<br />
of the triggger<br />
exactly one occurre ence of the action<br />
in the interval<br />
is req quired.<br />
Examplees<br />
of standarrd<br />
and “once”<br />
specificatioon<br />
of a flowin ng pattern:<br />
whenever<br />
whenever<br />
Attribute es: attribb1,<br />
attrib b2.<br />
a occurs<br />
a occurs<br />
<strong>Architecture</strong> <strong>Modeling</strong><br />
b occurs<br />
b occurs<br />
during [e e,f]. Attr ribute: fllowing.<br />
during [e e,f]. Attr ribute: fllowing,<br />
once.<br />
122/ 156
6.1.1.1.2.2<br />
Seammless<br />
Con ncatenatioon<br />
of multi iple instan nces of a ppattern<br />
The folloowing<br />
switch controls the behavior of an iterative pattern when n it is triggereed<br />
by the same<br />
event<br />
that is reequired<br />
in thee<br />
action of th he pattern.<br />
The defaault<br />
behaviorr<br />
without this attribute is tthat<br />
the actio on event cannot<br />
trigger thhe<br />
pattern ag gain.<br />
6.1.1.1.3<br />
Patternn<br />
Listing<br />
This is thhe<br />
Listing of the functiona al patterns. TThe<br />
placehol lders in italic printed letteers<br />
can be replaced<br />
with constructs<br />
described<br />
in section<br />
1. There is one additional<br />
possible<br />
modificatioon<br />
to the patterns:<br />
“Occurs” ” can be detaailed<br />
by using g:<br />
and<br />
whenever<br />
a occurs<br />
is emmitted<br />
is reeceived<br />
<strong>Architecture</strong> <strong>Modeling</strong><br />
a occurs<br />
during [e e,f]. Attr ribute: seeamless.<br />
These twwo<br />
refinemennts<br />
allow to specify s the diirection<br />
of the<br />
Events and d can be seeen<br />
as inherite ed from<br />
occurs:<br />
ooccurs<br />
is emitedd<br />
is re eceived<br />
This meaans<br />
that it is still possible e to use “occuurs”<br />
in the pa atterns to specify<br />
behavioour<br />
where the<br />
directionn<br />
shall not bee<br />
specified.<br />
The semmantics<br />
of the functio onal patterns<br />
is specif fied by obs server autommatons<br />
for iterative<br />
interprettation.<br />
Becauuse<br />
the specification<br />
of thhe<br />
flowing int terpretation is<br />
difficult it ccannot<br />
be giv ven for all<br />
patterns.<br />
Where posssible<br />
the flow wing interpreetation<br />
is des scribed by a language chharacterizatio<br />
on based<br />
123/ 156
on timed traces. As placeholders for events the names e1, e2, e3, … are used, for conditions the<br />
placeholder c is used.<br />
Pattern<br />
F1:<br />
whenever event occurs event [does not] occur[s] [during interval]<br />
This pattern describes the dependency between two events that can occur on different subjects.<br />
While using the optional interval attribute the pattern claims, that there occurs one event in the<br />
specified interval. If no interval is specified, there are no constraints when the event has to occur.<br />
Such a requirement has to be refined later.<br />
Natural Language Requirement:<br />
The System shall generate a error message when a query fails<br />
Pattern based RSL:<br />
whenever QueryFails occurs ErrorMessage occurs<br />
Observers for iterative interpretation with open and closed intervals:<br />
e3 && (clk==0)<br />
e1<br />
idle pre<br />
e3 && (clk==0)<br />
|fail:=true<br />
e1<br />
idle pre<br />
<strong>Architecture</strong> <strong>Modeling</strong><br />
e2<br />
e2<br />
|clk:=0<br />
e2<br />
|clk:=0<br />
sIn<br />
e3<br />
clk>0<br />
|fail:=true<br />
e3 && (clk>0)<br />
e2 && (clk==0)<br />
whenever e1 occurs e2 occurs during [e3,e4].<br />
e2<br />
|fail:=true<br />
e2<br />
|clk:=0<br />
e2<br />
|clk:=0<br />
sIn<br />
e3<br />
clk>0<br />
e3 && (clk>0)<br />
e2 && (clk==0)<br />
|fail:=true<br />
whenever e1 occurs e2 does not occur during [e3,e4].<br />
in<br />
in<br />
e4<br />
|clk:=0<br />
e4<br />
|clk:=0<br />
sOut<br />
sOut<br />
124/ 156
e3 && (clk==0)<br />
e1<br />
idle pre<br />
e1<br />
idle pre<br />
idle<br />
e1<br />
e3 && (clk==0)<br />
|fail:=true<br />
e4<br />
|fail:=true<br />
e2<br />
|clk:=0<br />
e2<br />
|clk:=0<br />
sIn<br />
e3<br />
clk>0<br />
e3 && (clk>0)<br />
e4 && (clk==0)<br />
|fail:=true<br />
whenever e1 occurs e2 occurs during [e3,e4[.<br />
e4<br />
e2<br />
|clk:=0<br />
sIn<br />
e3<br />
e4 && (clk==0)<br />
whenever e1 occurs e2 does not occur during [e3,e4[.<br />
pre<br />
e2 && (clk>0)<br />
<strong>Architecture</strong> <strong>Modeling</strong><br />
e2<br />
|clk:=0<br />
clk>0<br />
|fail:=true<br />
e3<br />
|clk:=0<br />
clk>0<br />
|fail:=true<br />
e2 && (clk==0)<br />
e3 && (clk>0)<br />
e2 && (clk==0)<br />
whenever e1 occurs e2 occurs during ]e3,e4].<br />
in<br />
in<br />
in<br />
e4<br />
|clk:=0<br />
e2<br />
|clk:=0<br />
e2<br />
|clk:=0<br />
sOut<br />
sOut<br />
sOut<br />
125/ 156
idle<br />
idle<br />
idle<br />
e1<br />
e1<br />
e1<br />
pre<br />
e2 && (clk>0)<br />
|fail:=true<br />
e3<br />
|clk:=0<br />
clk>0<br />
e2 && (clk==0)<br />
|fail:=true<br />
e2 && (clk==0)<br />
whenever e1 occurs e2 does not occur during ]e3,e4].<br />
pre<br />
e4<br />
|fail:=true<br />
whenever e1 occurs e2 occurs during ]e3,e4[.<br />
pre<br />
e4<br />
<strong>Architecture</strong> <strong>Modeling</strong><br />
e3<br />
|clk:=0<br />
clk>0<br />
e4 && (clk==0)<br />
|fail:=true<br />
e3<br />
|clk:=0<br />
clk>0<br />
|fail:=true<br />
e4 && (clk==0)<br />
in<br />
e2 && (clk==0)<br />
whenever e1 occurs e2 does not occur during ]e3,e4[.<br />
Definition of semantics with attributes flowing and once:<br />
Not supported in this version<br />
in<br />
e2 && (clk==0)<br />
in<br />
e4<br />
|clk:=0<br />
e2 && (clk>0)<br />
|clk:=0<br />
e2 && (clk>0)<br />
|clk:=0<br />
sOut<br />
sOut<br />
sOut<br />
126/ 156
Pattern whenever event occurs condition holds [during interval]<br />
F2:<br />
If the event occurs it has to be ensured that the condition is valid during the specified interval or, if<br />
there is no interval specified, forever.<br />
Natural Language Requirement:<br />
If the start button gets pushed signal a and signal be shall be equal for at least 5 seconds.<br />
Pattern based RSL:<br />
whenever StartButtonPushed occurs (SigA == SigB) holds during [0s,5s].<br />
Observers for iterative interpretation with open and closed intervals with events:<br />
e2 && (clk==0)<br />
|fail:=true<br />
e1<br />
idle pre<br />
e1<br />
idle pre<br />
idle<br />
e1<br />
e2 && (clk==0)<br />
|fail:=true<br />
pre<br />
!(c)<br />
|fail:=true<br />
!(c)<br />
|clk:=0<br />
!(c)<br />
|clk:=0<br />
sIn<br />
e2<br />
clk>0<br />
e2 && (clk>0)<br />
!(c) && (clk==0)<br />
|fail:=true<br />
whenever e1 occurs (c) holds during [e2,e3].<br />
e3<br />
!(c)<br />
|clk:=0<br />
!(c) && (clk>0)<br />
|fail:=true<br />
<strong>Architecture</strong> <strong>Modeling</strong><br />
!(c)<br />
|clk:=0<br />
sIn<br />
e2<br />
clk>0<br />
|fail:=true<br />
e2 && (clk>0)<br />
e3 && (clk==0)<br />
whenever e1 occurs (c) holds during [e2,e3[.<br />
e2<br />
|clk:=0<br />
clk>0<br />
!(c) && (clk==0)<br />
!(c) && (clk==0)<br />
|fail:=true<br />
whenever e1 occurs (c) holds during ]e2,e3].<br />
in<br />
in<br />
in<br />
e3<br />
|clk:=0<br />
e3<br />
|clk:=0<br />
!(c)<br />
|clk:=0<br />
sOut<br />
sOut<br />
sOut<br />
127/ 156
idle<br />
e1<br />
pre<br />
e3<br />
e2<br />
|clk:=0<br />
clk>0<br />
|fail:=true<br />
e3 && (clk==0)<br />
!(c) && (clk==0)<br />
whenever e1 occurs (c) holds during ]e2,e3[.<br />
Definition of semantics with attributes flowing and once:<br />
Not supported in this version<br />
Pattern<br />
F3:<br />
always condition<br />
in<br />
!(c) && (clk>0)<br />
|clk:=0<br />
This pattern describes an invariant condition that has to be valid at the specified component, or, if<br />
there has no component been defined, in general.<br />
Natural Language Requirement:<br />
The noise must be < 40dB.<br />
Pattern based RSL:<br />
always (noise < 40)<br />
Observer:<br />
Pattern<br />
F4:<br />
!(c)<br />
|fail:=true<br />
idle<br />
always(c).<br />
whenever condition holds during interval occurs event occurs<br />
[during interval]<br />
If the Boolean value of the specified condition is true during the interval an event occurs in an optional<br />
interval. If no interval is specified, there are no constraints when the event has to occur. Such a<br />
requirement has to be refined later.<br />
Natural Language Requirement:<br />
<strong>Architecture</strong> <strong>Modeling</strong><br />
sOut<br />
128/ 156
If the brake force is above 80% for more than 500ms full braking shall be initiated during<br />
100ms.<br />
Pattern based RSL:<br />
whenever (brakeForce > 80) holds during [0s,500ms] occurs<br />
InitiateFullBraking occurs during [0s, 100ms]<br />
Because this pattern is a combination of F1 and a sub automaton that converts the “holds during”<br />
construct into an event, only the sub automaton is given here. This automaton is started by<br />
localTmpPin0 and emits localTmpPin1 that is used by the corresponding F1 automaton.<br />
Sub automata(for iterative interpretation):<br />
idle<br />
idle<br />
out<br />
localTmpPin0<br />
!(c)<br />
in<br />
whenever (c) holds during [e1,e2] occurs action occurs during [e3,e4].<br />
localTmpPin0<br />
e1<br />
!(c)<br />
|clk:=0<br />
e1 && (clk==0) sIn e1 && (clk>0)<br />
e2<br />
|localTmpPin1:=true<br />
out<br />
e2<br />
|localTmpPin1:=true<br />
!(c)<br />
|clk:=0<br />
e1<br />
|clk:=0<br />
!(c) && (clk>0)<br />
whenever (c) holds during ]e1,e2] occurs action occurs during [e3,e4].<br />
Definition of semantics with attributes flowing and once:<br />
Not supported in this version<br />
!(c) && (clk==0)<br />
6.1.1.2 Probability<br />
There are two patterns concerning probabilities. One of those is to describe the availability of a<br />
component and the other to specify the number of events in an interval.<br />
Pattern<br />
P1:<br />
<strong>Architecture</strong> <strong>Modeling</strong><br />
availability of component shall be comparator p<br />
The Probability of a component to work correctly at any given time shall be “>”,”” and “>=” make sense.<br />
in<br />
129/ 156
Natural Language Requirement:<br />
The system shall operate with 97% availability.<br />
Pattern based RSL:<br />
availability of system shall be >= 0.97<br />
Pattern<br />
P2:<br />
number of event in time shall be comparator n [on average]<br />
In the specified time there shall be “>”,”
Pattern<br />
S3:<br />
Failure shall not be caused by n independent failures<br />
This pattern allows to specify that components have to be redundant and their failure may not be<br />
caused be a given number of other failures.<br />
Natural Language Requirement:<br />
Loss of engine shall not be caused by 2 independent failures.<br />
Pattern based RSL:<br />
EngineLoss shall not be caused by 2 independent failures<br />
Pattern hazard Hazard shall not occur with density higher than n per<br />
S4: reference<br />
This pattern can be used to express an hazard and specify its density.<br />
Example Pattern:<br />
hazard UnannunciatedLossOfDecelerationCapability shall not occur<br />
with density higher than 10E-9 per flightHour.<br />
There are also some patterns that allow to define some elements of the upper safety related patterns:<br />
Pattern<br />
S5:<br />
Function is realized by function_list<br />
This pattern is used to specify break-down of functions during system decomposition; function is<br />
linked to a set of functions of sub-components.<br />
In order to run safety analysis on a model, it is necessary to fully represent the flow and impact of<br />
failures. Hence the decomposition of functions has to be expressed. The commonly used black box<br />
view of components does not support the reference of elements inside a component from the<br />
outside. Since this is necessary for this decomposition a grey-box view is used. [speeds reference]<br />
Natural Language Requirement:<br />
The ABS system shall consist of the measuring unit for wheel slip and the braking system<br />
Pattern based RSL:<br />
ABSSystem is realized by WheelSlipMeasurin && BrakingSystem<br />
Pattern<br />
S6:<br />
<strong>Architecture</strong> <strong>Modeling</strong><br />
Failure is represented by failure_list<br />
This pattern is used to specify break-down of failures during system decomposition, failure is linked to<br />
a set of failures of sub-components. (see previous pattern for grey-box view).<br />
Natural Language Requirement:<br />
The braking system shall fail if the hydraulic system A fails and hydraulic system B fail.<br />
Pattern based RSL:<br />
BrakingSystemFails is represented by HydraulicSystemAFails &&<br />
HydraulicSystemBFails<br />
131/ 156
Patternn<br />
Failuure<br />
has cr riticalityy<br />
critical lity<br />
S7:<br />
This paattern<br />
allows to associate e failures withh<br />
criticalities s that have been<br />
derived for instance e from the<br />
hazard classification<br />
during FHA A (functional hazard asse essment).<br />
Naturaal<br />
Language Requirement:<br />
Loss of the braking syst tem is considdered<br />
hazard dous<br />
Patternn<br />
based RSLL:<br />
LossOfBraakingSyste<br />
em has criiticality<br />
hazardous s<br />
Patteern<br />
hazarrd<br />
Hazard is definned<br />
by ( event e )<br />
S8:<br />
This ppattern<br />
can bbe<br />
used to describe<br />
the hhazard.<br />
The event repres sents the point<br />
in time wh here the<br />
hazarrd<br />
occurs.<br />
Natural<br />
Languagge<br />
Requirem ment:<br />
Unannnounced<br />
losss<br />
of deceleration<br />
capability<br />
during landing<br />
Patteern<br />
based RSL:<br />
<strong>Architecture</strong> <strong>Modeling</strong><br />
Hazaard<br />
UnannoouncedLoss<br />
sOfDecelerrationCapa<br />
ability is s defined by<br />
((CoontrolLampp==1)<br />
hold ds not durring<br />
[tr(p phase==Lan nding),PeddalPushed]<br />
] and<br />
thenn<br />
Brake noot<br />
during [PedalPusshed,500ms<br />
s])<br />
This eexample<br />
is taaken<br />
from the<br />
ARP4754 standard. Th he following graphic g explaains<br />
the form malization<br />
in moore<br />
detail:<br />
The CControlLampp<br />
indicates the<br />
failure of thhe<br />
braking system.<br />
Since e the hazard only occurs if the<br />
failuree<br />
is unannouunced<br />
there shall s be no innterruption<br />
in n the Control lLamp signall<br />
between the<br />
start of<br />
the laanding<br />
proceess<br />
and the PedalPushed<br />
P d event. This is expressed d in the first part of the ev vent<br />
descrription<br />
of the pattern:<br />
... (ControlLLamp==1)<br />
holds h not during [t tr(phase== =Landing), ,PedalPush hed] ..<br />
T1 exxpresses<br />
thee<br />
time in whic ch a brake reeaction<br />
to the e request by the pedal is expected. Is s there no<br />
Brakee<br />
event in thiis<br />
interval the e hazard occcurs:<br />
.... ... Brakee<br />
not duri ing [PedallPushed,50<br />
00ms] .... ....<br />
132/ 156
Pattern<br />
S9:<br />
failureCondition failureCondition is defined by: event does [not]<br />
occur [during interval | under condition condition]<br />
This pattern defines a failure condition by the occurrence (or absence) of an event during an interval<br />
or while a condition holds. Conditions and intervals can be used as described for the functional<br />
pattern.<br />
Natural Language Requirement:<br />
The failure “unintended inflation of airbag” happens if the crash signal gets emitted while<br />
both gravity sensors detect no crash.<br />
Pattern based RSL:<br />
failureCondition UnintendedInflationOfAirbag is defined by: crash<br />
does occur under condition (gravitySensor1.gnormal) gets violated<br />
Pattern<br />
S11:<br />
<strong>Architecture</strong> <strong>Modeling</strong><br />
failureCondition failureCondition is defined by: condition holds<br />
[longer|shorter] than timeunit<br />
This pattern defines a failure condition by the violation of interval a condition holds. Conditions can be<br />
written as described for the functional pattern.<br />
Natural Language Requirement:<br />
It is considered as a failure if the current of the engine control system is longer than 2 sec.<br />
above 2A.<br />
Pattern based RSL:<br />
failureCondition TooMuchEnergyConsumption is defined by:<br />
(consumption > 2) holds longer than 2s<br />
133/ 156
Pattern<br />
S12:<br />
failureCondition failureCondition is defined by: event occurs<br />
more than timeunit [earlier|later] than event<br />
This pattern defines a failure condition by too late (too early) occurred events. This is a derived<br />
pattern from S9.<br />
Natural Language Requirement:<br />
If the airbag inflates later than 60ms after the detection of the crash, it is considered as a<br />
failure.<br />
Pattern based RSL:<br />
failureCondition LateAirbagInflation is defined by: inflation occurs<br />
more than 60ms later than crashDetection<br />
6.1.1.4 Real-Time Pattern<br />
The detailed specification of real-time systems leads to special real-time requirements. In order to<br />
express these requirements dedicated real-time patterns are necessary. Tools for real-time analysis<br />
usually work on execution times, deadlines and activation rates. The patterns presented below can be<br />
used to express the most relevant properties.<br />
Pattern<br />
R1:<br />
event occurs sporadic with minperiod period [and maxperiod<br />
period] [and jitter jitter]<br />
This pattern describes the sporadic occurrence of an event. The minimal distance of the ideal<br />
occurrences is defined by minperiod, which can be delayed by an additional jitter. If maxperiod is<br />
given this specifies the maximal distance between the ideal occurrences. The minimal distance<br />
between the real occurrences can be constrained by Pattern R3.<br />
Natural Language Requirement:<br />
Processing of received data is necessary at most each 10ms and may jitter 1ms.<br />
Pattern based RSL:<br />
dataReceived occurs sporadic with minperiod 10ms and jitter 1ms<br />
idle<br />
(0
Pattern<br />
R2:<br />
Event occurs each period [with jitter jitter]<br />
This pattern describes the periodic occurrence of an event such as the activation of a task. The<br />
event can be delayed by an additional jitter. This is a derived pattern from R1 such that<br />
minperiod==maxperiod.<br />
Natural Language Requirement:<br />
The diagnosis task shall be executed every 10ms and may jitter 1ms.<br />
Pattern based RSL:<br />
diagnosisTaskActivate occurs each 10ms with jitter 1ms<br />
Pattern<br />
R3:<br />
Delay between event and event within interval<br />
This pattern specifies the minimum and maximum distance between two events. The Order of the<br />
occurrences of the events is relevant here.<br />
Natural Language Requirement:<br />
The response time of the diagnosis task shall be 10ms +/- 1ms.<br />
Pattern based RSL:<br />
delay between diagTaskStart and diagTaskFinished within [9ms, 11ms]<br />
Observers for iterative interpretation with open and closed intervals:<br />
e1<br />
|clk:=0<br />
idle<br />
e2 && (l
e1<br />
|clk:=0<br />
idle<br />
e2 && (l
idle<br />
e1<br />
|clk:=0<br />
e2 && (l
6.1.1.5 Mapping Pattern<br />
Mapping patterns can be used to express the requirements on the mapping from the functional design<br />
perspective to the physical design perspective. Functions are mapped to hardware elements.<br />
Pattern<br />
M1:<br />
[under condition (condition)] function function-set shall [not]<br />
be mapped to hw-element-set.<br />
This pattern specifies that a set of functions shall [not] be mapped to a set of hardware elements. A<br />
function set consists of multiple functions concatenated with “AND” or “OR”. A hardware element set<br />
can consist of multiple hardware elements concatenated with “OR”. The condition can consist of other<br />
mapping constraints like “a is mapped together with b”<br />
Natural Language Requirement:<br />
The functions a and b shall not be allocated to RDCa2.<br />
Pattern based RSL:<br />
function a OR b shall not be mapped to RDCa2.<br />
Pattern<br />
M2:<br />
[under condition (condition)] function function-set shall [not]<br />
be mapped together with function-set.<br />
This pattern specifies that a set of functions shall [not] be mapped together to a hardware element<br />
with another function set. A function set consists of multiple functions concatenated with “AND” or<br />
“OR”. The condition can consist of other mapping constraints like “a is mapped together with b”<br />
Natural Language Requirement:<br />
The functions a and b shall not be allocated to the RDC where the function c is allocated to.<br />
Pattern based RSL:<br />
function a OR b shall not be mapped together with c.<br />
Pattern<br />
M3:<br />
<strong>Architecture</strong> <strong>Modeling</strong><br />
[under condition (condition)] function function-set shall [not]<br />
be mapped to same target.<br />
This pattern specifies that a set of functions shall [not] be mapped to the same hardware element. A<br />
function set consists of multiple functions concatenated with “AND” or “OR”. The condition can consist<br />
of other mapping constraints like “a is mapped together with b”.<br />
This is a derived pattern from M2.<br />
Natural Language Requirement:<br />
The functions a, b and c shall not be allocated to the same hardware element.<br />
Pattern based RSL:<br />
function a AND b AND c shall not be mapped to the same target.<br />
6.1.1.5.1 Semantics of Mapping Pattern:<br />
In the following we assume that is the set of all functions ∈ and the set of all hardware<br />
elements ∈.<br />
138/ 156
The function : allocates a single function on a hardware element written .<br />
Using this function the semantics can be defined by the usual semantics of boolean expressions:<br />
f shall be mapped to b <br />
f1 AND f2 shall be mapped to b<br />
∧ f1 OR f2 shall be mapped to b ∨ f shall be mapped to b1 OR b2<br />
1∨2 f1 AND f2 shall be mapped to b1 OR b2<br />
f1 OR f2 shall be mapped to b1 OR b2<br />
<strong>Architecture</strong> <strong>Modeling</strong><br />
∧ ∨ ∧ ∨ ∨ ∨ The function set expressions can consist of all combinations of conjunctions and disjunctions of<br />
functions. These formulas will be applied for the set of hardware elements on the right side of the<br />
expression.<br />
The semantics related to pattern M2 as follows:<br />
f1 shall be mapped together with f2 <br />
f1 AND f2 shall be mapped together with f3 ∧ <br />
f1 OR f2 shall be mapped to f3 ∨ <br />
f1 shall be mapped together with f2 AND f3 ∧ <br />
f1 shall be mapped together with f2 OR f3 ∨ <br />
f1 AND f2 shall be mapped together with f3 OR<br />
f4<br />
∧ <br />
∨ ∧ <br />
<br />
The pattern M2 can map multiple boolean combinations of functions together. When combining the left<br />
and the right side, the conjunctions are stronger binding than the disjunctions. This type can also be<br />
interpreted as a short form of the first type. Any constraint FX shall be mapped together with<br />
FY, where FX and FY are arbitrary junctions over functions, can be expressed as FX AND FY shall<br />
be mapped to B1 OR ... OR BN.<br />
In general, constraints are negated if the not token of the constraint is set:<br />
f shall not be mapped to b <br />
All constraints can have a precondition which is another constraint.<br />
under condition (f2 is mapped to b1) f1 shall be mapped together with f2<br />
→ <br />
The XOR operator is another short form to make modelling easier. It can be translated into two<br />
separate constraint as follows:<br />
f1 XOR f2 shall be mapped to b ⇔<br />
f1 AND f2 shall not be mapped together ∧ f1 OR f2 shall be mapped to b<br />
139/ 156
6.1.2 SSemanticss<br />
of obser rvers<br />
This secction<br />
gives aan<br />
overview w of the semmantics<br />
of th he observer automata tthat<br />
are use ed in this<br />
documennt<br />
to specifyy<br />
the formal semantics oof<br />
the pattern ns. These observers<br />
aree<br />
generated from the<br />
patterns and can be used to veri ify that a giveen<br />
compone ent with one input and onne<br />
output sat tisfies the<br />
requiremment.<br />
Figure 1 illustrates the t relationship<br />
between components s and observvers.<br />
For a sinngle<br />
pattern tthere<br />
exist a set of differeent<br />
automata a, depending g on the kind of intervals that t were<br />
used. Thhese<br />
automata<br />
are com mposed withh<br />
other auto omata or ext tended by aadditional<br />
states<br />
and<br />
transitionns<br />
to represeent<br />
complex event expresssions<br />
and conditions. c<br />
The semmantics<br />
are bbased<br />
on HR RC state maachines<br />
[D.2 2.1.c] for the current set of patterns a subset<br />
(Timed AAutomata)<br />
is sufficient. An A intuitive deescription<br />
of the semantic cs is providedd<br />
below.<br />
Basic coomponents<br />
off<br />
automata:<br />
AAutomata<br />
coonsist<br />
of state es and transitions.<br />
SStates<br />
have invariants, which w are nott<br />
shown here e; clock’:=1 is s assumed foor<br />
all clocks)<br />
TTransitions<br />
ccan<br />
be fired if<br />
their guard is true(even nt occurs or variable v is truue)<br />
AActions<br />
can be performed<br />
when transsitions<br />
are fir red<br />
Examplees<br />
of transitioons<br />
with even nts:<br />
• Run: {e} endds<br />
in S1<br />
• Run: {e, e} eends<br />
in S0<br />
<strong>Architecture</strong> <strong>Modeling</strong><br />
Figure 6: CComponent<br />
with w observer<br />
140/ 156
Examplees<br />
of clocks:<br />
• Run: {c=0@00ms,<br />
c=1@1 1ms, c=0@3mms}<br />
ends in S0<br />
• Run: {c=0@00ms,<br />
c=1@5 5ms, c=0@6mms}<br />
ends in S1<br />
6.1.3 RReferencees<br />
[D.2.5.4] ]<br />
[D.2.1.c] ]<br />
<strong>Architecture</strong> <strong>Modeling</strong><br />
D.2.5.4 Cont tract Specificcation<br />
Langu uage (CSL), SPEEDS S Prooject<br />
D.2.1.c SPE EEDS Meta-mmodel<br />
Syntax x and Draft Semantics, S SSPEEDS<br />
Project<br />
141/ 156
6.2 Semantics of HRC<br />
6.2.1 Semantical Domain<br />
<strong>Architecture</strong> <strong>Modeling</strong><br />
We assume a notion of time, given by a domain Time with a total order < on its instances.<br />
Whether time is discrete (i.e., N) or continuous (R + , the non-negative real numbers) does not<br />
matter for the general definitions in the following, whereas our more specific semantics of HRC<br />
introduced lateron assumes a continuous domain. An initial segment of the time domain is a<br />
downward-closed subset, i. e. a set T ⊆ Time satisfying t ∈ T ⇒ {t ′ ∈ Time|t ′ < t} ⊆ T .<br />
There is a set of ports P, where each port has a type with an associated domain of values.<br />
The universe of all values is V . We will assume all things being type correct and will not be<br />
concerned with details of types and values. Also, we simplify the interface concept of HRC in<br />
our presentation. We assume that each port contains just one flow, so that we can equate ports<br />
and flows, and just speak of ports.<br />
Given a set of ports P ⊆ P, a trace assigns, for any point in time, to each port a value of the<br />
port’s type. Thus, the set T (P) of all traces T over P is a subset of<br />
[Time → [P → V ]] .<br />
For discrete time domains, usually every function in the set above will be a trace, whereas<br />
with continous time and value domains, traces may be restricted e. g. to functions which are<br />
continuous almost everywhere (continuous but for a null set).<br />
In the following, whenever convenient we will freely apply decurrying, changing the argument<br />
order and currying when referring to traces. Thus, a trace may also be viewed as an<br />
element of [P → [Time → V ]].<br />
We denote by σ ↓P (resp., Σ ↓P) the restriction of a trace (resp., trace set) to a subset of its<br />
ports. Similarly, by σ ↓T we will denote its restriction to a subset T ⊆ Time.<br />
A Note on the Choice of the Semantical Domain Basing the semantical definitions on sets<br />
of (timed) traces is already some restriction. There are approaches to modeling which do not<br />
fit into this framework. It would be, however, very difficult to incorporate all these approaches<br />
in a general description, and it would result in a rather complex development. We will develop<br />
our theory for timed traces and leave it to the reader (or future versions of this document, if necessary)<br />
to perform the generalizations and modifications as appropriate for her/his semantical<br />
domain.<br />
One of the limitations of our approach concerns the synchronous nature of composition.<br />
This is not always adequate, for instance it excludes the elegant abstraction of [34] and related<br />
settings. It is, however, often possible to model asynchrony by synchrony, see e. g. [30].<br />
6.2.2 Properties of Trace Sets<br />
Traces do not distinguish between input and output, both are recorded in an equal manner.<br />
Operationally, the diference is important: A component should not be able to restrict the values<br />
on an inport, nor should its environment be able to influence the component’s outports. This<br />
is reflected in the trace sets we get as semantic interpretations of components in HRC, and the<br />
following definition formalizes the observation in a property of trace sets.<br />
Definition 6.2.1 (Receptiveness) Let Σ be a set of traces over a set of ports P, and let P ′ ⊆ P .<br />
142/ 156
<strong>Architecture</strong> <strong>Modeling</strong><br />
1. For σ ∈ Σ, the set Σ is called receptive on P ′ w.r.t. σ, if it is nonempty and for all initial<br />
segments T ⊆ Time,<br />
∀τ ∈ T (P). τ ↓T = σ ↓T ⇒ ∃σ ′ ∈ Σ. σ ′ ↓T = σ ↓T ∧σ ′ ↓ P ′= τ ↓ P ′<br />
2. The receptive kernel of Σ on P ′ is the largest receptive subset of Σ, if there is a receptive<br />
subset, or else the empty set.<br />
Lemma 6.2.2 (Receptiveness Properties) Let Σ be a set of traces over a set of ports P, and let<br />
P ′ ⊆ P .<br />
1. An arbitrary nonempty union of subsets of Σ which are receptive on P ′ is again receptive.<br />
Thus, the receptive kernel is always well defined.<br />
2. The intersection of two subsets of Σ which are receptive on P ′ need not be receptive.<br />
Proof:<br />
Ad 1: This follows from the existential nature of the defining clause (1. in Definition 6.2.1).<br />
Ad 2: Let us consider traces over one input and one output port, where each may take values<br />
in {0,1}. We take the following two trace sets which are receptive on the input port. In<br />
the first set, the output is always 0, in the second the output always equals the input. Both<br />
trace sets are obviously receptive because the input is not restricted. Their intersection is<br />
the set of traces where both output and input are always 0, which is not receptive on the<br />
input port, because there is no trace where the input is 1. 1 <br />
Receptiveness over a port set P ′ essentially says that the values of the ports in P ′ are not restricted<br />
– at any point in time there is a future behaviour for every possible future valuation of<br />
P ′ . This captures the intuition about direction of ports. The reader may note that also pathological<br />
cases like a component which guesses future outputs are excluded by requiring receptiveness<br />
on the inports. The potential non-receptiveness (Item 2 in the lemma) should be taken seriously.<br />
It is difficult to avoid inconsistencies in specifications, there are far more intricate cases than the<br />
simple counterexample used in the proof.<br />
As well as receptiveness, determinism can be expressed on the semantic level.<br />
Definition 6.2.3 (Deterministic Trace Set) Let Σ be a set of traces over a set of ports P, and<br />
let P ′ ⊆ P . Then Σ depends deterministically on P ′ if<br />
6.2.3 Semantical Definitions for HRC<br />
∀σ,σ ′ ∈ Σ. σ ↓ P ′= σ ′ ↓ P ′ ⇒ σ = σ ′ .<br />
For a component M, we denote its semantics by [[M]]. It is a set of traces over the interface of the<br />
component. We have already restricted ourselves to ports with just one flow. Service ports are<br />
not considered here either, they are assumed to be implemented by more primitive constructs<br />
(e. g. a protocol over directed ports). Furthermore, ports may only have direction in or out<br />
and not bidirectional. With these simplifications, we sketch the semantical domain for<br />
interpreting HRC and HRC state machines.<br />
1 An even simpler, yet maybe less instructive, example takes just two receptive sets with constant, different output,<br />
so that the intersection is empty.<br />
143/ 156
<strong>Architecture</strong> <strong>Modeling</strong><br />
Ports may be either discrete, transmitting discrete values or events, or continuous, if they<br />
serve to transmit values of type real. Thus, P = PD ⊎ PC. Traces assign to discrete ports,<br />
for each point in time, a discrete value, resp., the information of presence or absence of the<br />
event. To continuous ports, a real value is assigned, obeying certain smoothness conditions (see<br />
below).<br />
To accomodate hybrid behavior with continuous evolutions and discrete interaction, our time<br />
domain is two-dimensional. Continuous evolutions may be interrupted by sequences of discrete<br />
actions which take no physical time. This enables a sufficiently accurate and reasonably abstract<br />
modelling of hybrid systems.<br />
Definition 6.2.4 (HRC Time) The time domain for HRC traces is (TimeHRC,
<strong>Architecture</strong> <strong>Modeling</strong><br />
Traces according to Definition 6.2.5 can adequately represent the evolutions of HRC state<br />
machines as used e. g. in Sec. 6.1: Discrete transitions happen at certain points in time in the<br />
second time dimension, while between discrete transitions all changes are continuous (and discrete<br />
ports do not change their values).<br />
The parallel composition of components is defined by (essentially) the intersection of the<br />
parts composed in parallel.<br />
Definition 6.2.6 (Semantics of Composition) Let a hierarchically defined component M with<br />
port set P and parts Mi, i = 1,...,n be given.<br />
1. There are substitutions ρi, i = 1,...,n which map the port names of the Mi to the names<br />
of assembly and delegation connectors they are connected to, and there is a substitution<br />
ρ which similarly maps the delegation connectors to the names of the ports of M. We call<br />
these substitutions the connecting substitutions of M.<br />
2. The semantics of the composition is defined formally by:<br />
<br />
n<br />
[[M]] =<br />
[[Mi]]ρi<br />
i=1<br />
6.3 Syntax and Semantics of Contracts<br />
6.3.1 Contract Basics<br />
For the formalization of specifications, we assume a logic whose formulas A, G, . . . serve<br />
to define sets of traces. Thus, the semantics of the logics assigns sets of traces to formulas,<br />
denoted by [[G]], [[A]], etc. A suitable logic in the design context could be a first-order extension<br />
of linear-time temporal logic, or, more general, a second-order logic with primitve sorts Value<br />
and Time and the second-order sort Port for ports as functions from Time to Value.<br />
Contracts are constructed from formulas as triples (As,Aw,G) with strong (As) and weak (Aw)<br />
assumptions and guarantee G. We usually assume the interface of a component be given, i. e.,<br />
a set of ports with types and directions, and require that the three constituing formulas of the<br />
contract refer to this port set. If necessary, the port sets of the constituing formulas are extended<br />
to the set of component ports. In a contract, the assumptions may be viewed as antecedents and<br />
the guarantee as conclusion. Formally, there is no semantical distinction between strong and<br />
weak assumptions — they are to be conjuncted. Their different roles are just methodological in<br />
nature.<br />
Definition 6.3.1 (Contract Semantics) The semantics of a contract C = (As,Aw,G) is given<br />
by the following equation.<br />
where (.) cmpl denotes complementation.<br />
ρ ↓P<br />
[[C]] =def ([[As]] ∩ [[Aw]]) cmpl ∪ [[G]] ,<br />
Remark 6.3.2 (Contracts as Formulas) If negation or implication is available in the assertion<br />
logic, a contract can be translated into a formula:<br />
form((As,Aw,G)) =def ¬As ∨ ¬Aw ∨ G , or<br />
form((As,Aw,G)) =def As ∧ Aw ⇒ G .<br />
145/ 156
<strong>Architecture</strong> <strong>Modeling</strong><br />
For our application as specifications, the logical formulas in question will denote sets of traces<br />
of valuations of connections, resp., ports. Then we can define satisfaction of contracts by components<br />
(and systems).<br />
Definition 6.3.3 (Satisfaction) A component M satisfies a formula G, written M |= G, if and<br />
only if [[M]] ⊆ [[G]]. Similarly, it satisfies a contract C, written M |= C, if and only if [[M]] ⊆ [[C]].<br />
Thus, we have<br />
6.3.2 Contracts: Properties<br />
M |= (As,Aw,G) ⇔ [[M]] ∩ [[As]] ∩ [[Aw]] ⊆ [[G]] .<br />
To be able to base the design process on contracts, we need operations on contracts and related<br />
properties. The most basic relation between contracts is that of entailment, which is called<br />
refinement here.<br />
Definition 6.3.4 (Refinement) A contract C ′ = (A ′ s,A ′ w,G ′ ) refines a contract C = (As,Aw,G),<br />
written C ′ ⇒ C, if<br />
[[C ′ ]] ⊆ [[C]] and[[As]] ⊆ [[A ′ s]] ,<br />
i. e. if it is (in total) more restrictive and its strong assumption is less restrictive. Equivalently,<br />
C ′ ⇒ C if form(C ′ ) ⇒ form(C) and As ⇒ A ′ s in the usual logical meaning of implication.<br />
Thus, a component satisfying a refinement of a contract C satisfies also C. The second part of the<br />
condition for refinement states that the strong assumption may only get weaker in refinements.<br />
As a consequence, the strong assumption of a contract will always remain sufficient to establish<br />
the strong assumption made by a component satisfying a refinement. In practice, refinement<br />
usually removes nondeterminism from the guarantee, thus strengthening it, and/or permits more<br />
environment behaviour, weakening the assumption(s). This relation is called dominance.<br />
Definition 6.3.5 (Dominance) A contract C ′ = (A ′ s,A ′ w,G ′ ) dominates a contract C =<br />
(As,Aw,G), written C ′ C, if A ′ s ⇐ As, A ′ w ⇐ Aw and G ′ ⇒ G.<br />
It is easy to see that dominance implies refinement but not vice versa. In practice, dominance is<br />
easier to establish (i. e., less complex to check) and often sufficient for refinement proofs to go<br />
through.<br />
In the design process, often more general relations than refinement are called for because A<br />
specification should be implementable. We capture this intuition by the notion of (strong) consistency.<br />
Definition 6.3.6 (Consistency) Let the interface I of a component in HRC be given.<br />
1. A contract C (resp., a set of contracts C ) over I is weakly consistent if [[C]] is nonempty<br />
(resp., <br />
C∈C [[C]] is nonempty).<br />
2. A contract C (resp., set of contracts C ) over I is strongly consistent if the receptive kernel<br />
of [[C]] (resp., <br />
C∈C [[C]]) w.r.t. the inports in I is nonempty.<br />
Weak consistency is consistency in the logical sense, a necessary condition for every meaningful<br />
specification. Strong consistency takes the direction of ports into account, guaranteeing the<br />
existence of an implementation on the semantic level. It is more difficult to check than weak<br />
consistency.<br />
Whether the direction of ports is taken into account in a contract can be defined on the logical<br />
level.<br />
146/ 156
<strong>Architecture</strong> <strong>Modeling</strong><br />
Definition 6.3.7 (Directed Contract) Let the interface I of a component be given. A contract<br />
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<br />
receptive on the inports in I.<br />
Directed contracts may be viewed as the most natural form of utilizing the contract format<br />
for specifications. This is supported by the observation that directed contracts are strongly<br />
consistent.<br />
Lemma 6.3.8 (Directedness and Consistency) Let the interface I of a component and a contract<br />
C = (As,Aw,G) be given.<br />
1. If the guarantee of C is receptive on the inports in I, then C is strongly consistent.<br />
2. A directed contract is strongly consistent.<br />
Proof:<br />
Ad 1: Since [[C]] ⊇ [[G]] and the receptive kernel of G w.r.t. the inports is nonempty, also the<br />
receptive kernel of C is nonempty.<br />
Ad 2: Follows immediately from 1. <br />
An important operation to be performed on contracts is conjunction. This might be useful to<br />
combine specifying contracts of one component, or to derive a contract valid for a composition<br />
from part contracts. Though one can always find a contract equivalent to the conjunction of a set<br />
of contracts, properties like directedness are not automatically retained. We provide different<br />
schemata for performing the conjunction.<br />
Lemma 6.3.9 (Contract Conjunction) Let (tt,B,G) and (tt,F,H) be contracts. Then<br />
are equivalent to (tt,B,G) ∧ (ff ,F,H).<br />
6.4 Formalization of Typical Design Steps<br />
(tt,BG + FH , GH) (6.1)<br />
(tt,BF + BG + FH , GH) (6.2)<br />
(tt,B + F , BH + FG + GH) (6.3)<br />
The parallel composition of components has a logical counterpart on the level of contracts.<br />
Lemma 6.4.1 (Logical Composition) Let a hierarchically defined component M with port set<br />
P, parts Mi, i = 1,...,n, and connecting substitutions (ρ1,...,ρn,ρ be given. Let the parts be<br />
specified by sets of contracts Ci, j, i = 1,...,n, j = 1,...ni. Then<br />
<br />
n ni <br />
n<br />
Mi |= Ci, j ⇒ M |=<br />
i=1 j=1<br />
i=1<br />
ni<br />
<br />
j=1<br />
Ci, j<br />
<br />
ρi<br />
<br />
ρ ↓P .<br />
The lemma follows from Definition 6.2.6. It immediately provides the criterion for virtual<br />
integration testing.<br />
147/ 156
<strong>Architecture</strong> <strong>Modeling</strong><br />
Theorem 6.4.2 (Virtual Integration Testing) Let a hierarchically defined component M with<br />
port set P, parts Mi, i = 1,...,n, and connecting substitutions (ρ1,...,ρn,ρ) be given. Let the<br />
parts be specified by a set of contracts Ci, j, i = 1,...,n, j = 1,...ni each. Then<br />
<br />
n<br />
Mi |=<br />
i=1<br />
ni <br />
j=1<br />
Ci, j<br />
<br />
∧<br />
n<br />
i=1<br />
and if P ′ is the set of assembly connectors of M,<br />
<br />
n<br />
∃P ′<br />
i=1<br />
ni<br />
<br />
ni<br />
<br />
j=1<br />
j=1<br />
Ci, j<br />
Ci, j<br />
<br />
<br />
ρi<br />
ρi<br />
<br />
<br />
ρ ⇒ C<br />
<br />
⇒ M |= C (6.4)<br />
ρ (6.5)<br />
is the strongest assertion satisfied by M when the parts are instantiated by the respective contract<br />
sets.<br />
In words, the theorem says that all contracts valid for a composed component are logical consequences<br />
of the logical composition of the contracts of its parts (if these contracts of the parts is<br />
all that is known about them). As a consequence of this theorem, we can verify the correctness<br />
of a parallel composition on the level of contracts (6.4). This constitutes the formal foundation<br />
of contract-based design, modulo the expressiveness of the assertion language.<br />
Expressiveness matters mainly at the level of parts of the composition. Most logics have<br />
operators for conjunction, and substitutions can be performed on a syntactic level. The logical<br />
operators for composition do not seem problematic. The quantification over the set of assembly<br />
connectors might be more problematic. It is the logical counterpart of (semantical) hiding. In<br />
second-order trace logic, this is expressable by second-order quantifiers.<br />
Theorem 6.4.2 is the formal underpinning of hierarchical (de-)composition. It does, however,<br />
not reflect specifics of strong versus weak assumptions. Logically, they are both antecedents.<br />
Methodologically, they will be treated differently. Validity of the implication in (6.4) (the second<br />
conjunct) means that the strong assumptions of the part specifications, which are part of<br />
every contract of every part (see Sec. 4) are either discharged by contracts of other parts or still<br />
present in the derived contract for the composition. This is, semantically, correct. But we want<br />
the strong assumptions of parts which are not discharged to appear in the strong assumption<br />
of the composition. Thus we require the following additional condition for the application of<br />
virtual integration testing.<br />
Definition 6.4.3 (Strong VIT Condition) Let a hierarchically defined component M with port<br />
set P and strong assumption A and parts Mi, i = 1,...,n be given. Let the parts be specified<br />
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<br />
strong VIT condition is given by:<br />
<br />
n<br />
i=1<br />
ni<br />
<br />
j=1<br />
Ci, j<br />
<br />
∧ (Aρ −1 ) ⇒<br />
n<br />
(As,i) (6.6)<br />
In the above, ρ −1 shall denote a formula operation that inverses the effect of the substitution ρ<br />
which maps the delegation connectors to P. For a substitution which is not injective (e. g. if an<br />
inport of M gets duplicated internally), this cannot in general be expressed by a substitution.<br />
The strong VIT condition may even have a stronger motivation than said above. In some applications,<br />
it might be necessary to assume a stricter interpretation of strong assumptions than<br />
i<br />
148/ 156
<strong>Architecture</strong> <strong>Modeling</strong><br />
the one given above in Sec. 6.3.1. Though, logically, nothing is assured of a component if the<br />
strong assumption is violated, we still can compose it in parallel with other components without<br />
affecting those — such is the nature of “parallelism as intersection”. If this is not justified,<br />
the strong VIT condition would become mandatory, to preclude conclusions to be drawn from<br />
the specifications of some components even though the operational conditions of others are not<br />
met. Building a semantics on a concept (parallelism as intersection) which does not always hold<br />
might seem badly advised. But one should bear in mind that all mathematical semantics of realworld<br />
entities are simplifications. And the concept of “very strong” assumptions, as reflected<br />
in the “Strong VIT condition” might enable a consistent use of helpful simplifications which<br />
would otherwise be unsound. Handling the large formulas in (6.4) and (6.6) might be difficult<br />
in practice – tautology checking for trace logics is computationally expensive. Thus, to reduce<br />
the complexity, boolean reasoning should be used first to reduce the problem. A promising way,<br />
to be supported by adequate methodological guidelines, is to eliminate assumptions wherever<br />
possible when they are implied by commitments of other components as exemplified in Sec. 4.<br />
149/ 156
Glossary<br />
<strong>Architecture</strong> <strong>Modeling</strong><br />
System under development (SuD) The notion system under development denotes the software<br />
intensive system on a defined abstraction level. A system under development may<br />
involve various perspectives(↑).<br />
<strong>Architecture</strong> An architecture describes the basic structure of the system under development(↑).<br />
Component A component is self-contained and provides functions of a system. It has a well<br />
defined interface. Typically a component itself consists of a set of parts(↑).<br />
Ports Ports specify the interface of a component(↑). A port can either define a data-oriented or<br />
a service-oriented interaction point. Further, ports have a direction and are either input or<br />
output ports or bidirectional. A port is typed by a specification describing a set of flows<br />
or services needed or offered by a port.<br />
Part Parts are sub-components in the context of an encompassing component(↑). The concept<br />
of parts enables the hierarchical structuring of components(↑).<br />
Heterogeneous Rich Component (HRC) Heterogeneous Rich Components extend the concept<br />
of components(↑): The term rich refers to the fact that a component can have<br />
an aspect-specific specification and realization. Heterogeneous means that different<br />
aspects(↑) typically use different modeling elements.<br />
So, an aspect specification defines what a component should do and a realization defines<br />
how the component actually behaves. Specifications in the context of <strong>SPES</strong> are done by<br />
means of contracts(↑). The realization of a certain aspect of a component can be modelled<br />
by any other formalism.<br />
Contract Contracts give the specification of a component and formalize system-requirements.<br />
This enables model based analysis techniques. Syntactically a contract consists of a<br />
strong assumption, a weak assumption and a guarantee. The strong assumptions specify<br />
the allowed design context. If a component is used outside this specification, product<br />
liability does not apply. In contrast to this, the weak assumptions define different possible<br />
system contexts. A single weak assumption defines a part of the allowed design context.<br />
The guarantee specifies the behaviour guaranteed by the component, if it is used in the<br />
allowed system context, i.e., its strong assumption does hold.<br />
Requirement Specification Language (RSL) RSL is a pattern-based language which can be<br />
used to formalize properties of design items. With RSL it is possible to capture<br />
contracts(↑). For this, one RSL-expression is used to specify the strong assumption,<br />
the weak assumption and the guarantee respectively.<br />
Abstraction Level An abstraction level provides a specific level of description and analysis of<br />
a design item (e.g. component). On the next lower abstraction level the granularity of the<br />
design item is refined. Such a lower abstraction level is realized by specific decomposition<br />
techniques. Models on different abstraction levels may differ in both their granularity and<br />
their viewpoints(↑). Realize links(↑) between models allow to trace those refinements.<br />
The use of abstraction layers may support both the reuse of solutions and the management<br />
of the supply chain.<br />
Note that components of models on lower abstraction levels still have to respect the aspect<br />
specifications(↑) defined for their higher level counterparts.<br />
150/ 156
<strong>Architecture</strong> <strong>Modeling</strong><br />
Decomposition A design item (e.g. component) can be decomposed into parts(↑). A decomposition<br />
consists of linked parts(↑) realizing the interface of the design item.<br />
Concern A concern characterizes a specific interest of one or more stakeholder with respect<br />
to the system under development(↑). Concerns include system considerations such as<br />
performance, reliability, security, distribution, and evolvability and are expressed in terms<br />
of questions, e.g., “What functionality should the system offer to its users?” or “How<br />
reliable is the designed system?”.<br />
View A view is a set of models of the system under development(↑) or of a part of this within<br />
an abstraction layer(↑) with respect to a specific viewpoint(↑). A view addresses one or<br />
more concerns(↑).<br />
Viewpoint A viewpoint defines a specific form of abstraction in order to focus on particular<br />
concerns(↑) within a system. For each viewpoint a selected set of architectural constructs<br />
and structuring rules is defined in order to design and use a viewpoint specific view(↑).<br />
Thereby, a viewpoint is not constraint to a specific abstraction layer(↑).<br />
Aspect An aspect is a part specific views(↑). Aspects help in coping with complexity in constructing<br />
a view(↑). Examples for aspects are safety, realtime, performance and functionality.<br />
Perspective A perspective combines views(↑) of different abstraction levels(↑) which are<br />
related to similar viewpoints(↑). Perspectives can be used to group and to structure<br />
views(↑) of different disciplines in order to cope with the complex task of developing<br />
a system.<br />
Operational Perspective In the operational perspective the context of the design item is regarded.<br />
The focus lies on the analysis and documentation of the integration of the design<br />
item in its technical and physical environment. The relations of the system under<br />
development(↑) to other systems, to its users, and to its environment is modeled in this<br />
perspective.<br />
Moreover, requirements of the SuD(↑) are documented, which refer to the characteristics<br />
constraining the interface behavior of the system. The SuD has to fulfill these requirements<br />
in order to achieve its goal. These requirements especially encompass the<br />
user-functions, which should be provided by the system.<br />
Functional Perspective In the functional perspective the functional needs of the system and<br />
their breakdown into sub-functions is modeled. The set of all sub-functions then realize<br />
the top-level system functionality.<br />
Logical Perspective On the logical perspective a structural decomposition of the system under<br />
development(↑) with the aid of hierarchichal components(↑) is performed. These<br />
components(↑) implement the functions specified on the functional perspective(↑).<br />
Thereby, the structural decomposition is influenced by non-functional requirements like<br />
performance, reusability, and verifiability. Further, the decomposition could also be influenced<br />
by (↑) the supply chain.<br />
Moreover, under the consideration of the interface of the system under development the<br />
system context is modeled.<br />
151/ 156
<strong>Architecture</strong> <strong>Modeling</strong><br />
Technical Perspective The technical perspective describes the electrical and electronical architecture,<br />
the software architecture and the mechanical structure of the system under<br />
development(↑). <strong>Modeling</strong> elements are for example electronic control units, bus<br />
systems, tasks, and hydraulic systems. By allocating components(↑) of the logical<br />
perspective(↑) to the technical perspective a software-hardware partitioning is realized.<br />
Geometrical Perspective On this perspective the physical layout of the system under<br />
development(↑) is modeled. This includes (amongst others) models describing the location<br />
of control units, and the cable layout.<br />
Refinement Refinement defines the derivation of a concrete desciption of the design item from<br />
an abstract description. The derivation thereby conserves the characteristics of the abstract<br />
description. In the case of a contract specification(↑), the derived component(↑)<br />
has to fulfill all contracts of the more abstract component.<br />
Dominance Dominance is a necessary but not sufficient condition to check a refinement(↑), in<br />
that dominance implies refinement.<br />
Mapping A mapping is a concept of the <strong>SPES</strong>MM which relates a set of component parts(↑)<br />
to each other. In particular, it descibes the projection of interfaces of a set of component<br />
parts to component parts of different perspectives(↑) or abstraction layers(↑). There are<br />
two types of mappings: realization(↑) and allocation(↑).<br />
Realization An realization describes a mapping(↑) between component parts(↑) of different<br />
abstraction layers(↑).<br />
Allocation (Allokation) An allocation describes a mapping(↑) between component parts(↑) of<br />
different perspectives(↑).<br />
Satisfaction Satisfaction is the proof obligation stating that an implementation of a desing<br />
item must adhere to its specification. In context of <strong>SPES</strong>, this means that an aspect<br />
realization(↑) of a component(↑) has to fulfill its contracts(↑), i.e., if its behavior does<br />
not violate its specified one. That way, the behavior of a component defined by its aspect<br />
realization can be seen as a refinement(↑).<br />
Compatibility Compatibility reflects the distinction of responsibilities: The strong<br />
assumptions(↑) about the environment of a component must not be violated by another<br />
component that is connected to this component.<br />
Virtual Integration Test (VIT) A virtual integration test verifies the correctness of a design<br />
item, which is composed by a set of interconnected sub-design items. In particular, to<br />
perform a virtual integration test in the context of <strong>SPES</strong>, one has to show on the one hand<br />
the compatibility(↑) of the interconnected sub-components. On the other hand, one has to<br />
check, whether the contract specifications of the composition of all sub-conponents refine<br />
the contract specification of the composed component.<br />
152/ 156
Bibliography<br />
[1] ARINC 653 - Avionics Application Software Standard Interface. Part of ARINC 600-<br />
Series Standards for Digital Aircraft & Flight Simulators, 2006.<br />
[2] IEEE Standard for Property Specification Language (PSL). IEEE Std 1850-2010 (Revision<br />
of IEEE Std 1850-2005), pages 1 –171, 6 2010.<br />
[3] Aditya Agrawal, Gyula Simon, and Gabor Karsai. Semantic translation of simulink/stateflow<br />
models to hybrid automata using graph transformations. Electr. Notes Theor. Comput.<br />
Sci., 109:43–56, 2004.<br />
[4] O. Akerlund, P. Bieber, E. Boede, M. Bozzano, M. Bretschneider, C. Castel, A. Cavallo,<br />
M. Cifaldi, J. Gauthier, A. Griffault, O. Lisagor, A. Lüdtke, S. Metge, C. Papadopoulos,<br />
T. Peikenkamp, L. Sagaspe, C. Seguin, H. Trivedi, and L Valacca. ISAAC, a framework for<br />
integrated safety analysis of functional, geometrical and human aspects. In 3rd Embedded<br />
Real Time Software (ERTS2006), 2006.<br />
[5] ARP4761. Guidelines and Methods for Conducting the Safety Assessment Process on<br />
Civil Airborne Systems and Equipment. Aerospace Recommended Practice, Society of<br />
Automotive Engineers, Detroit, USA, 1996.<br />
[6] The ATESST Consortium. EAST ADL 2.0 Specification, February 2008.<br />
[7] AUTOSAR GbR. Generic Structure Template, November 2009. Version 3.0.0.<br />
[8] AUTOSAR GbR. Software Component Template, November 2009. Version 4.0.0.<br />
[9] AUTOSAR GbR. Virtual Functional Bus, November 2009. Version 2.0.0.<br />
[10] Andreas Baumgart, Philipp Reinkemeier, Achim Rettberg, Ingo Stierand, Eike Thaden,<br />
and Raphael Weber. A model-based design methodology with contracts to enhance the development<br />
process of safety-critical systems. In Sang Min, Robert Pettit, Peter Puschner,<br />
and Theo Ungerer, editors, Software Technologies for Embedded and Ubiquitous Systems,<br />
volume 6399 of Lecture Notes in Computer Science, pages 59–70. Springer Berlin / Heidelberg,<br />
2011.<br />
[11] Albert Benveniste, Benoît Caillaud, Roberto Passerone, Bernhard Josko, Eric Badouel,<br />
and Benoît Delahaye. SPEEDS Meta-model Behavioural Semantics. Technical report,<br />
SPEEDS Consortium, Jan 2007.<br />
[12] Matthias Brill, Bernd Finkbeiner, and Sven Schewe. Automatic synthesis of assumptions<br />
for compositional model checking. In 26th International Conference on Formal Methods<br />
for Networked and Distributed Systems (FORTE 2006), pages 143–158. Springer Verlag,<br />
2006.<br />
153/ 156
<strong>Architecture</strong> <strong>Modeling</strong><br />
[13] Manfred Broy, Franz Huber, and Bernhard Schätz. AutoFocus – Ein Werkzeugprototyp<br />
zur Entwicklung eingebetteter Systeme. Informatik Forschung und Entwicklung,<br />
(13(3)):121–134, 1999.<br />
[14] Matthias Büker, Alexander Metzner, and Ingo Stierand. ”testing real-time task networks<br />
with functional extensions using model-checking”. In 14th International Conference on<br />
Emerging Technologies and Factory Automation, 2009.<br />
[15] W. Damm. Controlling speculative design processes using rich component models. In 5th<br />
International Conference on Application of Concurrency to System Design (ACSD 2005),<br />
2005.<br />
[16] W. Damm and D. Harel. LSCs: Breathing Life into Message Sequence Charts. In<br />
FMOODS’99 IFIP TC6/WG6.1 Third International Conference on Formal Methods for<br />
Open Object-Based Distributed Systems, 1999.<br />
[17] W. Damm, B. Josko, H. Hungar, and A. Pnueli. A compositional real-time semantics of<br />
Statemate designs. In W.-P. de Roever, H. Langmaack, and A. Pnueli, editors, Compositionality<br />
- The Significant Difference, LNCS 1536, pages 186–238. Springer, 1998.<br />
[18] Werner Damm, Hardi Hungar, Bernhard Josko, Thomas Peikenkamp, and Ingo Stierand.<br />
Using contract-based component specifications for virtual integration testing and architecture<br />
design. In Conference on Design, Automation and Test in Europe, DATE’11, 2011.<br />
[19] Werner Damm, Bernhard Josko, Amir Pnueli, and Angelika Votintseva. A discrete-time<br />
uml semantics for concurrency and communication in safety-critical applications. Sci.<br />
Comput. Program., 55(1-3):81–115, 2005.<br />
[20] Werner Damm, Angelika Votintseva, Alexander Metzner, Bernhard Josko, Thomas<br />
Peikenkamp, and Eckard Böde. Boosting re-use of embedded automotive applications<br />
through rich components. In Foundations of Interface Technologies, FIT’05, 2005.<br />
[21] Abhijit Davare, Douglas Densmore, Trevor Meyerowitz, Alessandro Pinto, Alberto<br />
Sangiovanni-Vincentelli, Guang Yang, Haibo Zeng, and Qi Zhu. A next-generation design<br />
framework for platform-based design. In Proceedings of Conference on Using Hardware<br />
Design and Verification Languages (DVCon) 2007, February 2007.<br />
[22] Luca de Alfaro and Thomas A. Henzinger. Interface automata. In Proceedings of the 8th<br />
European software engineering conference held jointly with 9th ACM SIGSOFT international<br />
symposium on Foundations of software engineering, ESEC/FSE-9, pages 109–120,<br />
New York, NY, USA, 2001. ACM.<br />
[23] Henning Dierks, Alexander Metzner, and Ingo Stierand. Efficient model-checking for realtime<br />
task networks. In 6th International Conference on Embedded Software and Systems,<br />
May 2009.<br />
[24] J. Eker, J.W. Janneck, E.A. Lee, Jie Liu, Xiaojun Liu, J. Ludvig, S. Neuendorffer, S. Sachs,<br />
and Yuhong Xiong. Taming heterogeneity - the ptolemy approach. Proceedings of the<br />
IEEE, 91(1):127 – 144, January 2003.<br />
[25] Daniel Gajski and Robert H. Kuhn. New vlsi tools - guest editors’ introduction. IEEE<br />
Computer, 16(12):11–14, 1983.<br />
154/ 156
<strong>Architecture</strong> <strong>Modeling</strong><br />
[26] Holger Giese, Matthias Tichy, Sven Burmester, Wilhelm Schäfer, and Stephan Flake.<br />
Towards the compositional verification of real-time uml designs. SIGSOFT Softw. Eng.<br />
Notes, 28:38–47, September 2003.<br />
[27] Holger Giese, Matthias Tichy, Sven Burmester, Wilhelm Schäfer, and Stephan Flake. Towards<br />
the Compositional Verification of Real-Time UML Designs. SIGSOFT Softw. Eng.<br />
Notes, 28:38–47, September 2003.<br />
[28] Object Management Group. Requirements Interchange Format (ReqIF), July 2010. Document<br />
Beta/2010-07.<br />
[29] C. Haerdt and A. Keis. Model-based integration of analysis services: Experiences with an<br />
analysis dashboard. In 3rd Workshop on Model-Driven Tool & Process Integration, 2010.<br />
[30] Nicolas Halbwachs and Louis Mandel. Simulation and verification of asynchronous systems<br />
by means of a synchronous model. In Application of Concurrency to System Design<br />
(ACSD’06), volume 0, pages 3–14, Los Alamitos, CA, USA, 2006. IEEE Computer Society.<br />
[31] Alexander Harhuin, Florian Hölzl, and Thomas Kofler. Spes Metamodel. <strong>SPES</strong> <strong>2020</strong><br />
Deliverable D1.4.A, The <strong>SPES</strong> <strong>2020</strong> Project, September 2010.<br />
[32] ISO. ISO15622: Transport information and control systems - Adaptive Cruise Control<br />
systems - Performance requirements and test procedures, 2002.<br />
[33] ISO/IEC/(IEEE). ISO/IEC 42010 (IEEE Std) 1471-2000 : Systems and Software engineering<br />
- Recomended practice for architectural description of software-intensive systems,<br />
July 2007.<br />
[34] Gilles Kahn. The semantics of simple language for parallel programming. In IFIP<br />
Congress, pages 471–475, 1974.<br />
[35] Kim Lauenroth, Ernst Sikora, Heiko Stallbaum, and Bastian Tenbergen. Initialer modellbasierter<br />
Requirements-Engineering-Ansatz für Embedded Systems. <strong>SPES</strong> <strong>2020</strong> Deliverable,<br />
The <strong>SPES</strong> <strong>2020</strong> Project, Universität Duisburg-Essen, September 2009.<br />
[36] J. Matevska-Meyer, W. Hasselbrink, and R. Reussner. On a software architecture description<br />
supporting component deployment and system runtime reconfiguration. In Proceedings<br />
of the WCOP’04 Ninth International Workshop on Component-Oriented Programming,<br />
2004.<br />
[37] Bertrand Meyer. Applying ”design by contract”. Computer, 25(10):40–51, 1992.<br />
[38] Jan Meyer. SysML Erweiterung zur Modellierung von Zeitverhalten. <strong>SPES</strong> <strong>2020</strong> Deliverable<br />
AU-D3.3.A, The <strong>SPES</strong> <strong>2020</strong> Project, Universität Paderborn and Hella KGaA Hueck<br />
& Co., September 2009.<br />
[39] Object Management Group. OMG Systems <strong>Modeling</strong> Language (OMG SysML ),<br />
november 2008. Version 1.1.<br />
[40] Object Management Group. A UML Profile for MARTE: <strong>Modeling</strong> and Analysis of Real-<br />
Time Embedded Systems, November 2009. Version 1.0.<br />
155/ 156
<strong>Architecture</strong> <strong>Modeling</strong><br />
[41] Object Management Group. OMG Unified <strong>Modeling</strong> Language(OMG UML), Superstructure,<br />
May 2010. Version 2.3.<br />
[42] WP.2.1 Partners. SPEEDS L-1 Meta-Model. Technical report, SPEEDS Consortium, May<br />
2009.<br />
[43] Roberto Passerone, Jerry R. Burch, and Alberto L. Sangiovanni-Vincentelli. Refinement<br />
preserving approximations for the design and verification of heterogeneous systems. Form.<br />
Methods Syst. Des., 31:1–33, August 2007.<br />
[44] Daniel Ratiu, Wolfgang Schwitzer, and Judith Thyssen. A System of Abstraction Layers<br />
for the Seamless Development of Embedded Software Systems. <strong>SPES</strong> <strong>2020</strong> Deliverable<br />
D1.2.A-2, The <strong>SPES</strong> <strong>2020</strong> Project, October 2009.<br />
[45] Marvin Rausand. System Reliability Theory. Wiley, 2 edition, 2004.<br />
[46] Herbert Stachowiak. Allgemeine Modelltheorie. Springer Wien, 1973.<br />
[47] W. E. Vesely, F.F. Goldberg, N. H. Roberts, and D. F. Haasl. Fault Tree Handbook.<br />
NUREG-0492. U.S. Nuclear Regulatory Commission, Washington DC, 1981.<br />
[48] Tiziano Villa, Timothy Kam, Robert K. Brayton, and Alberto Sangiovanni-Vincentelli.<br />
Synthesis of finite state machines: logic optimization. Kluwer Academic Publishers, Norwell,<br />
MA, USA, 1997.<br />
[49] Thomas Wagner and Ulrich Löwen. Modellierung technischer systeme. Technical report.<br />
[50] Raphael Weber, Eike Thaden, and Philipp Reinkemeier. Specification of the <strong>SPES</strong> Meta-<br />
Model. <strong>SPES</strong> <strong>2020</strong> Deliverable D3.2.B, The <strong>SPES</strong> <strong>2020</strong> Project, OFFIS, November 2010.<br />
[51] H. Zimmermann. OSI Reference Model–The ISO Model of <strong>Architecture</strong> for Open Systems<br />
Interconnection. IEEE Transactions on Communications, 28(4):425–432, 1980.<br />
156/ 156