Architecture Modeling - SPES 2020

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