![](bg3.png)
“erroneous CLOSE command to the clutch”), a
special driving situation (“engine running, vehicle
standing”), and a type of scenario (“vehicle in front
of pedestrian crossing”) with a hazard (“unintended
forward acceleration”) and its impact on the
environment (“injury of persons”). Relevant impacts
are typically hit-ting objects or persons, where,
obviously, the severity is influenced by the type of
object.
4 MODELING FOUNDATIONS
4.1 Physical vs. Software Modeling
At a very high level, the model of a cyber-physical
system may not explicitly distinguish whether its
subsystems of components are software modules or
physical components, and they may be represented
in a uniform way, e.g. as black boxes with some
mapping from inputs to outputs or as transition
systems. Often, these models try to capture the
(intended) function of a system, rather than its entire
possible behavior. For instance, in early phases of
design, it may not yet have been decided whether a
certain subsystem will be realized by software, a
physical system, or a combination of both.
However, when the behavior has to be analyzed
in detail, the different nature of software and
physical components will often require models that
appropriately capture the physical phenomena that
determine system behavior. This is even mandatory
when the consideration of faulty behavior is
involved, as e.g. in diagnosis, testing, or safety
analysis: While the space of bugs in the software
components is created by erroneous (manual or
automated) transformations on the path from
requirements to code (and also inappropriate
requirements), faults of physical components are
exclusively subject to the physical defects, which
often makes it possible to enumerate and model the
relevant fault classes. Moreover, most physical
components, e.g. in electrical, mechanical,
hydraulic, and pneumatic circuits cannot be
modeled by input-output behavior. Even if they
have an intended preferred direction under nominal
system behavior, this may be totally perturbed under
the presence of a fault. Therefore, our approach
presented is based on relational models of the
physical components, which also induces a small set
of generic high-level (fault) models of the software
components.
The characteristics of the models used in our
solution are the following:
Compositional modeling: models of systems are
obtained through aggregation of models of its
parts, possibly across several layers of hierarchy.
Component-oriented modeling: the parts are
components, i.e. the building blocks that are
assembled to form the system and determine its
behavior (both physical and software components).
This is due to two reasons. Firstly, component
models can be reused in different system models
just as the components are reused in different
systems. Secondly, components are the entities
that are subject to faults, whose impact needs to be
determined in safety analysis.
Qualitative behavior models reflect the qualitative
and worst-case nature of the analysis.
Relational models (as opposed to transition
systems) are chosen to represent these qualitative
behavior descriptions, according to the
considerations above and justified by the
observation that hazards are commonly the result
of a fault in one state of the physical system (rather
than occurring after a sequence of state
transitions).
Deviation models are used, since faults, hazards,
and impact are characterized as (qualitatively)
distinct from nominal behavior.
In the following, we specify these characteristics
more formally, though in a nutshell (For
introductory material, see e.g. (Struss, 1997),
(Struss, 2008).
4.2 Component-Oriented Modeling
A component type (used to create different
instances) is represented under a structural and a
behavioral perspective:
It has a number of typed terminals, which can be
shared with other components.
Thus, a system structure is described by as
(COMPS, CONNECTIONS), where COMPS is a set
of (typed) components and CONNECTIONS is a set
of pairs of terminals of equal type belonging to
different components.
A component C
i
has a vector v
i
= (v
ik
) of variables,
comprising parameters and state variables,
which are considered as internal and constant and
changing dynamically, resp., and terminal
variables. The latter are obtained from the
instances of the terminal types, which have a set of
associated variable types.
The CONNECTIONS of a system structure induce a
set VARIABLECONNECTIONS of pairs of
corresponding terminal variables from connected
ICSOFT2013-8thInternationalJointConferenceonSoftwareTechnologies
286