Architecture Modeling - SPES 2020

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