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

Chapter 7. openETCS Meta Model
7.5.8. Static Semantics directly used in the Modelling Process
According to the tool chain introduced in Section 4.6, constraints are defined outside the
MetaEdit+ application and checked by an external generator. Therefore, the generated report
is pure textual and it has to be (manually) searched in MetaEdit+ for incorrect model elements.
This drawback cannot easily be avoided because the used GOPPRR XML format used as
interface is general and accordingly independent from the concrete meta model. However, it is
possible to check simple constraints directly during the manual modelling process.
The best way to do this is to use generators that do not produce any direct output to files
but graphical feedback. In MetaEdit+ [56], this is done by MERL scripts that directly output
information to the graphical representation of a GOPPRR element that is not a graph, a port,
or a property 12 . Those scripts are always executed in the scope of the current graph, which
the representation is displayed in. This is the obvious limitation for this method because, as
discussed in Chapter 4, constraints related to the project scope are in this way very difficult
to implement. Constraints that are related to graphs cannot be implemented because MERL
generators for graphs cannot be output on the graph representation itself. Properties do not
have any direct graphical representation at all, and ports are only graphical connection points.
Thus, only a subset of the above introduced constraints are implemented directly in the
graphical elements of the openETCS meta model. However, even this subset providing direct
graphical feedback in the case of model or rather static semantics violations can help an ETCS
expert during the specification process.
7.6. Dynamic Semantics for the Cyclic Execution
The presented openETCS meta model or formal specification language can mainly divided in
three major parts:
1. a superior state machine for ETCS Modes
2. data and control flows for behavioural and functional specification
3. specification of data structures for communication
The dynamic semantics of the superior state machine defined in a gEVCStateMachine graph is
described in general as for state machines [80]. As already discussed, no temporal behaviour
can be derived directly from a gEVCStateMachine graph because oModeGuard objects are
used as conditions for transitions. Since the oModeGuard objects are used in the data flows,
only the specification language part for data and control flow defines temporal behaviour of
the whole model. Although data flows can be modelled in general, it is obvious that when
the model is transformed to an executable binary 13 the data flow has to be implemented in
discrete manner. From control theory, it is known that for the establishment of stable, discrete
systems those must have a fixed sample time T s [30]. This means that the data flows or rather
their calculations k are executed at certain time points t, which all have the same temporal
distance:
t = kT s ; k = 0, 1, 2, . . . (7.1)
12 objects, roles, and relationships
13 for a certain computer platform
108