Architecture Modeling - SPES 2020

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