Ph.D. - geht es zur Homepage der Informatik des Fachbereiches 3 ...

7.2. Concrete Syntax for Graph Types and Sub-Graphs
The developed meta model is based on the ETCS SRS version 2.3.0, which was already
referred to in the general ETCS introduction in Section 2.2. Accordingly, all following instances
of the openETCS DSL in this case study are also based on this SRS version.
7.2. Concrete Syntax for Graph Types and Sub-Graphs
To begin the meta model description with an overview, Figure 7.2 introduces all graph types
and their connection by explosions and decompositions. For clarification, all graph types are
denoted by a “g” as prefix and objects by an “o”. In the real meta model, those prefixes do not
exist. The general meaning of graph types is explained in this section while the certain binding
syntax and the used object types for each graph type are explained in the next section.
gEVCStateMachine graph type The ETCS standard specifies EVC behaviour according to
operational Modes. In each Mode, a well-defined collection of functions is active. Transitions
between Modes are specified in the standard as the so-called transition tables while related
descriptions of guard conditions are presented in structured natural language [88, pp. 37-40].
gMainFunctionBlock, gSubFunctionBlock, and gEmbeddedStateMachine
graph types The specification of ETCS Application Levels applicable in a certain Mode is
realised in the openETCS meta model by explosions from Modes (object type oMode) to
graphs of type gMainFunctionBlock: One for each level applicable in the respective Mode.
A gMainFunctionBlock graph defines the EVC operations to be executed in a given mode
and ETCS Application Level [88, 90, 89]. To determine the ETCS Application Level of a
function block, the gMainFunctionBlock graph type holds an oApplicationLevelType object
in its property list. This object carries the level identification of each gMainFunctionBlock
instance associated with an ETCS mode via explosion.
Function blocks are used to model data flow between objects that can be sources, like sensors
or actuators, but also to model variables describing internal states. Experience with system
modelling has shown that it is often necessary to complement data flow specifications by control
flow descriptions in order to model the complete system behaviour [8]. Therefore, the oEmbeddedStateMachine
object type in the gMainFunctionBlock graph type has a decomposition
into state machines (gEmbeddedStateMachine graph type) embedded within the data flow.
Conversely, state machine control states may be decomposed again into gSubFunctionBlock,
which model the active behaviour while residing in the control state. It should be noted that
this recursive relationship allows to specify hierarchic control states as used in the so-called
“OR-states” of statecharts [36].
Another special object is the oSubFunction object within the gMainFunctionBlock graph
type. Its purpose is to structure certain functionality into sub-graphs for better graphical
clarity and re-usability. For this reason, it has a decomposition to the gSubFunctionBlock
graph type.
The gSubFunctionBlock type differs from gMainFunctionBlock mainly in the lack of the
assignment to a certain Application Level by a property. This enables the re-usability of certain
(sub) functionality in several Modes and Application Levels. Therefore, object types related to
81