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

Chapter 7. openETCS Meta Model
The syntax is presented in Figure 7.9. The gCommunicationSender graph type also uses a data
gCommunicationSender
DataFlow
oTelegram
1...*
DataFlow
DataInput
1...1
DataOutput
1...1
oPacket
1...*
DataInput
1...1
DataOutput
1...1
telegramInput
1...*
oSenderDevice
1...1
oTelegram
1...*
oVariableInstance
1...*
oVariableStorage
1...*
oVariableInstance
1...1
Figure 7.9.: gCommunicationSender binding syntax
flow syntax, but this is reduced to the flow from a composed telegram to a sending device – a
sub-type instance of oSenderDevice – and from oVariableStorage objects to oVariableInstance
objects. The oVariableInstance object type represents the atomic data element used in balise
communication [85]. The concrete structuring of the large elements will be explained in sections
about the gTelegram and gPacket graph types.
In this graph type, only those modelled structures must be used. To compose a certain
oTelegram object, it has to be modelled that it graphically includes one or more oPacket objects
that are also part of the gTelegram graph decomposition of it. The same must be done for
each oVariableInstace object in the gPacket graph decompositions of the oPacket objects. The
data flow from an oVariableStorage to an oVariableInstace object can be interpreted as filling
of the telegram elements with values from the active data flows. This data flow is also of the
pseudo type bit because telegrams are transferred only digital.
7.3.5. gCommunicationReader Graph Type
The gCommunicationReader graph type is used for the opposite purpose of the gCommunicationSender
to get values from received telegrams by track-to-train communication. Therefore,
only the direction of the data flows is changed: From the receiving device – a sub type of
oReaderDevice – to a oTelegram object and from the included oVariableInstance objects to
oVariableInstace objects. The binding syntax is shown in Figure 7.10.
94