5_DATEX-II-Schnittstelle DORA-Server AdB.pdf

[Seite 1]

Anlage 2:

DATEXII-Schnittstelle zum DORA-Server

Dateninhaltsbeschreibung

!!! Anmerkung !!! Die nachstehende Dateninhaltsbeschreibung beschreibt den Dateninhalt in aktueller Version 1.0 zum Zeitpunkt der Erstellung der Dokumentation. Im Rahmen erforderlicher Qualitätssicherung wird die Schnittstelle jedoch kontinuierlich weiterentwickelt. Somit sind vor Beginn der Schnittstellenumsetzung etwaige Aktualisierungen (Versionsupdates) anzufragen um die erforderliche Aktualität sicherzustellen.

November 2013

1

[Seite 2]

Inhaltsverzeichnis

1. VORWORT ...................................................................................................................................... 3

2. UMSETZUNG .................................................................................................................................. 3

2.1. DATENÜBERTRAGUNG ................................................................................................................ 3 2.2. ALLGEMEINE RANDBEDINGUNGEN ZUR DATENÜBERTRAGUNG FÜR FREMDFIRMEN ......................... 4 2.3. DATENINHALT ............................................................................................................................ 6 2.3.1. Versionsinformation ......................................................................................................... 7 2.3.2. Informationen zum Lieferanten der Daten ....................................................................... 7 2.3.3. Informationen zur Art der Meldung .................................................................................. 8 2.3.4. Informationen zum Übersendungszeitpunkt und dessen Ersteller .................................. 9 2.3.5. Einzelner Einsatz (SituationRecord) .............................................................................. 10 2.3.6. Informationen zur Gültigkeit einer Meldung und zur Beendigung eines aktiven Einsatzes 11 2.3.7. Informationen zur genaueren Beschreibung der Punkt Location .................................. 12 2.3.8. Art der Baustelle, Zustand der Systeme........................................................................ 13 2.3.9. Beschilderung des Sperrhängers .................................................................................. 15

3. ANHANG – PRAXISBEISPIEL ..................................................................................................... 17

3.1. EINLEITUNG ............................................................................................................................. 17 3.2. BEISPIEL ................................................................................................................................. 17 3.3. ÜBERTRAGUNG ........................................................................................................................ 17 3.4. MELDUNGEN ............................................................................................................................ 17 3.4.1. Keep Alive ..................................................................................................................... 18 3.4.2. Intervall .......................................................................................................................... 19 3.4.3. Status............................................................................................................................. 20 3.4.4. Fehler............................................................................................................................. 20

Abbildungsverzeichnis

Abbildung 1: Datenfluss mit DATEXII-Schnittstelle ................................................................ 3 Abbildung 2: Tafel Oben -> Meldungen von Ort und Zeit der Absperrtafel ; Tafel Unten -> keine Meldungen ................................................................................................................... 4

2

[Seite 3]

1. Vorwort

Die nachfolgende Schnittstellenbeschreibung definiert der im Rahmen von DORA (Dynamische Ortung von Arbeitsstellen kürzerer Dauer) erforderliche Attribute und Inhalte die im Gesamtkontext eines Dateninformationsflusses mit Bezug zu einer Absperrtafel und damit einhergehenden Arbeitsstelle zu beachten sind.

Im Anhang sind praxisnahe Beispiele in der Auszeichnungssprache xml (Extensible Markup Language) befindlich, die die praxisnahe Umsetzung der DATEXII –Schnittstelle zur Anbindung an DORA insbesondere durch Fremdfirmen unterstützen.

2. Umsetzung

2.1. Datenübertragung

Der Datenfluss im Rahmen des Projektes DORA mit Einbeziehung der Fremdfirmen sieht vor, über den Standard DATEXII Positions-, Zustands- sowie weitere Absperrtafelinformationen auszutauschen. DATEXII ist eine standardisierte Form des Datenaustausches zwischen den Straßenbetreibern sowie dessen Dienstanbietern und wird zur Kommunikation zwischen Rechenzentralen verwendet.

Von einem Datenlieferanten/ einer Fremdfirma wird eine Schnittstellenanbindung an das System DORA per DATEXII erwartet. Diese Art der Anbindung, sowie dessen Kommunikationsvorgaben obliegen der Autobahn GmbH des Bundes (AdB). Das System DORA beinhaltet einen Zugangspunkt, den Vorknoten, an den durch den Datenlieferant Informationen der Absperrtafel in DATEXII gesendet werden.

hessen.mobil Vorrechner Sperranhänger

DATEXII VOR- DORA Knoten

Fremdfirmen Vorrechner (Rechner)

Abbildung 1: Datenfluss mit DATEXII-Schnittstelle

Es wird davon ausgegangen, dass ein Datenlieferant einen eigenen Vorrechner verwenden, der zentral die einzelnen Meldungen der Absperrtafeln entgegennimmt und an das DORA-System übergibt.

3

[Seite 4]

Zugangspunkt der Datenanbieter an DORA VOR-Knoten:

IP und Port: wird auf Anfrage bereitgestellt

Protokoll: TCP/ http

Die Art der Kommunikation von der Absperrtafel zum Vorrechner des Datenlieferanten obliegt dem Anbieter selbst. Die Übergabe der Daten von der Absperrtafel an den Vorrechner sind auf Basis geltender IT-Sicherstandards durch Fremdzugriffe unzugänglich auszugestalten.

2.2. Allgemeine Randbedingungen zur Datenübertragung für Fremdfirmen

Grundsätzlich werden ausschließlich Informationen der Absperrtafeln im Rahmen eines Arbeitseinsatzes gefordert. Ein Einsatz beginnt, durch das Öffnen der Absperrtafel (siehe Abb. Tafel oben) und endet durch das Herunterfahren der Tafel (siehe Abb. Tafel unten).

Abbildung 2: Tafel Oben -> Meldungen von Ort und Zeit der Absperrtafel ; Tafel Unten -> keine Meldungen

Durch Definition eines Einsatzes durch die Tafel ist davon auszugehen, dass unter Berücksichtigung der „Richtlinien und zusätzlichen technischen Vertragsbedingungen für die Sicherung von Arbeitsstellen an Straßen“ Arbeitseinsätze durchgeführt werden.

Im Rahmen eines Arbeitseinsatzes werden folgende Meldungen unterschieden:

• Intervallmeldungen

Meldungen innerhalb eines definierten Intervalls unter Berücksichtigung zeitlicher und örtlicher Vorgaben. Zu einer Intervallmeldung der Absperrtafel zählen auch Fahrtübergänge vom Stillstand zur Fahrt und andersherum.

• Statusmeldungen

Meldungen bei verändertem Status der Absperrtafel.

• Fehlermeldungen

Meldungen, die bei Fehlern zu übermitteln sind

• KeepAlive Meldungen

4

[Seite 5]

Dienen ausschließlich der Überprüfung einer aufrechten Datenkommunikation.

Detailierung der zu sendenden Datenintervalle:

o Intervallmeldung bei Fahrt (Geschwindigkeit >= 4 km/h)  jede Minute oder alle 2000m (diese Vorgaben sind genau einzuhalten)  Fahrtübergänge vom Stillstand zur Fahrt (oder andersherum) ohne Statusveränderung  bei Richtungsänderungen +-30° (bezogen auf Fahrtrichtung gegen Nord) o Intervallmeldungen im Stillstand (Geschwindigkeit < 4km/h)  alle 30min o Statusmeldung bei Schaltänderungen  der Tafel  der Leuchttafel  des Richtungspfeils o Fehlermeldungen  Art des Fehlers für Fremdfirmen:  101 = Datenlage QS Stufe 1 = ohne Prüfung = nicht vertrauenswürdig  102 = Datenlage QS Stufe 2 = mit Prüfung, jedoch fraglich = bedingt vertrauenswürdig  103 = Datenlage QS Stufe 3 = vertrauenswürdig  Art des Fehlers für AdB interne Absperrtafeln:  0 = Unbekannt,  1 = GPS Empfänger defekt,  2 = Status eines Tafelelementes kann nicht ermittelt werden  3 = Ein externes Gerät ist angeschlossen und meldet einen Fehler  4 = Ein externes Gerät ist angeschlossen aber reagiert nicht  5 = Batterie schwach  99 = kein Fehler (Diese Liste wird in Zusammenarbeit mit der AdB, sowie den beauftragten Zulieferern im Rahmen der Vertragslaufzeiten erweitert) o KeepAlive Meldung  Zum Test der Verbindung auf Anfrage

5

[Seite 6]

2.3. Dateninhalt

Es wurde ein Tagesbaustellen-Rahmengerüst definiert, welches die Zielanforderungen zur Kommunikation von Zentralen der Fremdfirmen zur DORA Anbindung erfüllt und über den europäischen Verkehrsdatenstandard DATEX II ausgetauscht werden kann.

Das entsprechende DATEX II-Profil beinhaltet (nachfolgend in Abbildung mit Bezug zur XML dargestellt):

• Versionsinformationen
• Informationen zum Lieferanten der Daten
• Informationen zur Art der Meldung
• Informationen zum Übersendungszeitpunkt und dessen Ersteller
• Einzelner Einsatz (SituationRecord)
• Informationen zur Gültigkeit einer Meldung
• Informationen zur genaueren Beschreibung der Punkt Location
• Beschilderung des Sperrhängers

Abbildung 3: XML-Struktur einer DATEXII Meldung und Kennzeichnung der jeweiligen Position der Dateninhalte innerhalb dieser Struktur

Die einzelnen Elemente des DATEX II Profils werden im Folgenden beschrieben.

6

[Seite 7]

2.3.1. Versionsinformation

Die Versionsinformation gibt Auskunft über die Versionsnummer des XML-Schemas und ist in der Schemadatei (.xsd) verzeichnet:

Der Header einer XML-Instanz (.xml) sieht wie folgt aus:

2.3.2. Informationen zum Lieferanten der Daten

Der Datenlieferant (der Suplier) beliefert den Vorknoten des DORA-Systems mit den Informationen aller zentral auf seinen Vorrechner eingehenden Absperrtafeln. Unterschiedliche Fremdfirmen, die über einen zentralen Datenlieferanten übergeben werden, unterscheiden sich durch unterschiedlcihe Datenersteller (den Publication Crator siehe Kap. 2.3.4)

7

[Seite 8]

2.3.3. Informationen zur Art der Meldung

Im Rahmen der Schnittstellenanbindung durch DATEX II an das DORA-System, den DORA Vor-Knoten, werden Einzeldatenübertragungen, sprich eine Meldung je Intervall, Status- oder Fehlermeldung - singleElementUpdate unterstützt. Zusätzlich werden keepAlive-Meldung (für sich gestellte Meldung) als Verbindungstest verarbeitet. Die Meldungen beinhalten den Zeitpunkt ihrer Veröffentlichung subscriptionStartTime, sowie die IT-technische Zieladresse (IP, Port und Datenübertragungsprotokoll) der Datenmeldung (siehe ).

Im nachfolgenden Text werden weitere Zeitstempel erläutert. Zusammenfassend wird unterschieden:

• zwischen der Datenlieferungszeit subscriptionStartTime (Zeitstempel der Absendezeit von einem Vorrechner an den Vor-Knoten des DORA-Systems)

• der Publikationszeit publicationTime (Zeitstempel der Absendung von Daten von der Absperrtafel an einen Vorrechner eines Datenlieferanten) -> siehe 2.3.4

• und der Erstellungszeit situationRecordCreationTime (Zeitpunkt der Erstellung einer Meldung infolge Intervall-, Status-, oder Fehlerdefinitionen) -> 2.3.5

8

[Seite 9]

2.3.4. Informationen zum Übersendungszeitpunkt und dessen Ersteller

Es wird der Zeitpunkt der Übermittlung der Daten an der Box, d.h. wann Daten von der Hardwareeinheit übertragen werden festgeschrieben. Zusätzlich sind Informationen enthalten, wer den Datensatz/ welche Fremdfirma im Einsatz erstellt hat. Mit Bezug zum Datenlieferanten (siehe 2.3.2 Information zum Lieferanten der Daten) ist es an diesem Punkt relevant Informationen zum Dienstleister, derjenige der die Absperrtafel verwendet, zu erhalten. Sofern diese Informationen nicht veröffentlicht werden, sind zumindest unterschiedliche Fremdfirmen, die über einen Datenlieferanten übertragen werden, zu unterscheiden. Die publicationTime ist der dazugehörige Zeitstempel, wann eine Meldung (erzeugt an der Hardware) von der Absperrtfafel an den zentralen Datenlieferanten überliefert wird.

In unserem Beispiel ist der Hardware-Datenlieferant als Creator benannt.

9

[Seite 10]

2.3.5. Einzelner Einsatz (SituationRecord)

Ein SituationRecord ist mit einem Einsatz einer Absperrtafel gleich zu setzen. Ein SituationRecord besitzt eine eindeutige ID und Versionierung und ist in eine Situation eingebetet. Aufgrund erforderlicher Echtzeitdatenverarbeitung wird je Situation ausschließlich ein SituationRecord mitgegeben.

Jeder SituationRecord enthält außerdem die Bezeichnung „Absperrtafel“ sowie eine betriebliche ID (hier: Absperrtafel_123).

Zusätzlich werden an dieser Stelle die zeitliche Nachvollziehbarkeit der Meldungen und deren Zusammenhänge erläutert. Jede vorliegende Situation hat eine eindeutig zugehörige Zeit (Zeit der Erstellung der Meldung an der Box -> Creation Time = Erstmeldung mit Tafel Oben). Weitere erstellte Meldungen an der Absperrtafel werden mit einer definierten Versionierungszeit (Folgemeldung -> VersionTime) zeitlich mitgeführt.

10

[Seite 11]

2.3.6. Informationen zur Gültigkeit einer Meldung und zur Beendigung eines aktiven Einsatzes

Jede Meldung erhält eine Gültigkeit (bei validityStatus definedByValidityTimeSpec). Diese ist standardisiert auf 40 Minuten eingestellt. In der Schnittstelle ist dies durch eine Start und End Time definiert (overall Start/ EndTime). Der Gültigkeitsstart ist identisch zur SituationRecordVersionTime (d.h. letzte Meldung der Tour).

Um einen Einsatz beenden zu können (Tafel unten) ist der validityStatus suspended mit Zeitpunkt der Beendigung (in der Regel mit Zeitstempel der Absendung) zu übertragen. Dies führt direkt zu einer Beendigung des aktiven Einsatzes.

Der Wert active überschreibt die Zeitangaben(!) und setzt die Maßnahme in jedem Fall aktiv. Dieser Wert sollte nur in sehr seltenen Fällen eingesetzt werden.

11

[Seite 12]

2.3.7. Informationen zur genaueren Beschreibung der Punkt Location

Die Georeferenzierung wird in Form der Punkt-Referenzierung angegeben.

Das System DORA verlangt für alle Koordinatenangaben die Verwendung geodätischer Koordinaten nach dem WGS84 innerhalb der DATEXII Übergabe.

12

[Seite 13]

2.3.8. Art der Baustelle, Zustand der Systeme

Die Baustelle wird grundsätzlich als shortTerm klassifiziert.

Es wird unterschieden zwischen einer statischen (stationary) und dynamischen (mobile) Situation einer Absperrtafel (ggf. auch unknown). Unter statisch wird eine sich nicht bewegende Tagesbaustelle (Geschwindigkeit < 4 km/h) verstanden. Eine Tagesbaustelle wird als dynamisch bezeichnet, wenn die Bewegungsgeschwindigkeit >= 4 km/h ist.

Darüber hinaus kann mit der blockingDirection die gesperrte Richtung bezogen auf den mit bearing angegebenen Winkel (siehe Punkt-Location) angegeben werden.

Weiterhin gibt es die Möglichkeit, den Status des GPS zu klassifizieren, die Anzahl der genutzten Satelliten anzugeben und ggf. einen Fehlerzustand zu übermitteln.

Die Elemente der MobilityExtended-Klasse sind als sog. Level B-Erweiterung dem DATEX Modell hinzugefügt worden.

13

[Seite 14]

14

[Seite 15]

2.3.9. Beschilderung des Sperrhängers

Die Baustelle an sich wird durch das verpflichtende Aufzählungsliteral maintenanceWork charakterisiert.

Die Beschilderung des Hängers wird durch die drei danach folgenden Aufzählungen beschrieben; dabei handelt es sich ebenfalls um eine DATEX II Level B-Erweiterung:

15

[Seite 16]

d2:maintenanceLightStatearrowLeft</d2:maintenanceLightState> d2:maintenanceTableStateflippedUp</d2:maintenanceTableState> d2:maintenanceArrowStateunknown</d2:maintenanceArrowState> </d2:maintenanceVehiclesExtended> </d2:maintenanceVehiclesExtension> </d2:maintenanceVehicles> d2:roadMaintenanceTypemaintenanceWork</d2:roadMaintenanceType>

16

[Seite 17]

3. Anhang – Praxisbeispiel

Nachfolgend ein Praxisbeispiel aus der funktionalen Anwendung, zum Aufzeigen der Verwendung des Vorknotens sowie der DATEXII.

3.1. Einleitung

Bei Registrierung als Fremdfirma bei hessen.mobil erhält der Lieferant Verbindungsdaten zu einem der Vorrechner von Dora, Kennungen sowie einem Zahlenbereich für den er seine Absperrtafeldaten melden darf. Die Zuordnung von Werten aus diesem Zahlenbereich zur entsprechenden Warntafel muss nachhaltig sein.

3.2. Beispiel

Der Datenlieferant B möchte Daten, welche er seinerseits von dem Betreiber/Hersteller der Boxen (Unternehmen A) bezieht, an DORA senden. Nachdem er sich bei hessen.mobil erfolgreich registriert hat bekommt er folgende Informationen zugesandt:

• IP Vorknoten Dora
• Port an dem der Lieferant melden darf.
• Zahlenbereich [5000 – 5100]
• Kennung Lieferant: de.b
• Kennung Ersteller: de.b.a

3.3. Übertragung

Der Lieferant öffnet Für jede Meldung, welche er übertragen möchte, eine neue Verbindung zu dem ihm mitgeteiltem Port des Vorknotens. Der „Content-Type“ der Verbindung sollte „text/xml; charset=utf-8“ sein. In diese Verbindung schreibt der Lieferant eine DatexII mit den entsprechenden Meldungsdaten (siehe Punkt 3.4). Eine Bestätigung bzw. Fehlermeldung wird vom Vorknoten als Rückantwort in die noch offene Verbindung geschrieben.

3.4. Meldungen

Im Folgendem wird jeder Meldungstyp mit einem Beispiel aufgeführt. Die grau hinterlegten Felder sind, unabhängig im Standard definierter Optionalität, als Pflichtangaben zur Funktionalität von DORA erforderlich.

17

[Seite 18]

3.4.1. Keep Alive Wie in Punkt 2.2 erläutert kann eine Keep Alive Meldung jederzeit vom Lieferanten an den Vorknoten gesandt werden, um die Verbindung zum Vorknoten zu testen. Dieser Meldungstyp wird lediglich geloggt und gegen die XSD validiert. Er stößt keine weiteren Aktionen an.

<d2:d2LogicalModel xmlns:d2="http://datex2.eu/schema/2/2_0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://datex2.eu/schema/2/2_0 DORA_Knotenvorrechner.xsd" modelBaseVersion="2"> d2:exchange d2:keepAlivetrue</d2:keepAlive> d2:supplierIdentification d2:countryde</d2:country> d2:nationalIdentifierde.b</d2:nationalIdentifier> </d2:supplierIdentification> d2:subscription d2:operatingModeoperatingMode2</d2:operatingMode> d2:subscriptionStartTime2013-11-01T09:38:55+00:00</d2:subscriptionStartTime> -> Zeitpunkt der Überlieferung des Datensatzes vom Absender von Server zu Server d2:subscriptionStateactive</d2:subscriptionState> d2:updateMethodsingleElementUpdate</d2:updateMethod> d2:target d2:address127.0.0.1</d2:address> d2:protocolTCP/http</d2:protocol> </d2:target> </d2:subscription> </d2:exchange> </d2:d2LogicalModel> Beispiel 1: Keep Alive

18

[Seite 19]

3.4.2. Intervall

Unter Punkt 2.2 ist angeben unter welchen Umständen eine Intervallmeldung zu senden ist.

<d2:d2LogicalModel xmlns:d2="http://datex2.eu/schema/2/2_0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://datex2.eu/schema/2/2_0 DORA_Knotenvorrechner.xsd" modelBaseVersion="2"> d2:exchange d2:keepAlivefalse</d2:keepAlive> d2:supplierIdentification d2:countryde</d2:country> d2:nationalIdentifierde.DatenlieferantB</d2:nationalIdentifier> </d2:supplierIdentification> d2:subscription d2:operatingModeoperatingMode2</d2:operatingMode> d2:subscriptionStartTime2013-11-01T09:49:36+00:00</d2:subscriptionStartTime> -> Zeitpunkt der Überlieferung des Datensatzes vom Absender von Server zu Server d2:subscriptionStateactive</d2:subscriptionState> d2:updateMethodsingleElementUpdate</d2:updateMethod> d2:target d2:address127.0.0.1</d2:address> d2:protocolTCP/http</d2:protocol> </d2:target> </d2:subscription> </d2:exchange> <d2:payloadPublication xsi:type="d2:SituationPublication" lang="de"> d2:publicationTime2013-11-01T09:49:33+00:00</d2:publicationTime> -> Datenübertragung von Box zum Server d2:countryde</d2:country> d2:nationalIdentifierde.DatenlieferantB.UnternehmenA</d2:nationalIdentifier> </d2:publicationCreator> <d2:situation id="60C6ADFD-27BD-4662-9ABA-4D7023F0493C" version="1"> d2:headerInformation d2:confidentialitynoRestriction</d2:confidentiality> d2:informationStatusreal</d2:informationStatus> </d2:headerInformation> <d2:situationRecord xsi:type="d2:MaintenanceWorks" id="5E9657B6-A458-48D3-84CC-268CD7C1ACF7" version="3"> d2:situationRecordCreationReferenceAbsperrtafel_5006</d2:situationRecordCreationReference> d2:situationRecordCreationTime2013-11-01T09:49:33+00:00</d2:situationRecordCreationTime> d2:situationRecordVersionTime2013-11-01T09:49:33+00:00</d2:situationRecordVersionTime> -> Zeitstempel der Meldungserstung an der Box. Dieser Zeitstempel wird als Meldungsgenerierungszeit in den weiterverarbeitenden Systemen (insbesondere DORA) verwendet. d2:probabilityOfOccurrencecertain</d2:probabilityOfOccurrence> d2:validity d2:validityStatusactive</d2:validityStatus> d2:validityTimeSpecification d2:overallStartTime2013-11-01T09:49:33+00:00</d2:overallStartTime> d2:overallEndTime2013-11-01T09:49:33+00:00</d2:overallEndTime> </d2:validityTimeSpecification> </d2:validity> <d2:groupOfLocations xsi:type="d2:Point"> d2:pointByCoordinates d2:bearing316</d2:bearing> d2:pointCoordinates

<d2:latitude </d2:latitude> <d2:longitud </d2:longitude>

d2:pointCoordinatesExtension d2:pointCoordinatesExtended d2:altitude336</d2:altitude> </d2:pointCoordinatesExtended> </d2:pointCoordinatesExtension> </d2:pointCoordinates> </d2:pointByCoordinates> Be i s p i<e/ld 22: g(rToeuiplO 1f Lvoocanti o2n)s:> I ntervallmeldung ...

19

[Seite 20]

… d2:roadworksDurationshortTerm</d2:roadworksDuration> d2:mobility d2:mobilityTypemobile</d2:mobilityType> d2:mobilityExtension d2:mobilityExtended d2:speed14</d2:speed> d2:blockingDirectioninDirectionOfBearing</d2:blockingDirection> d2:numberOfSatellites6</d2:numberOfSatellites> d2:gpsStatusgps3D</d2:gpsStatus> </d2:mobilityExtended> -> Ergänzung bei vorhandenem Fehler durch FEHLER-Meldung (siehe 3.4.4) </d2:mobilityExtension> </d2:mobility> d2:maintenanceVehicles d2:maintenanceVehiclesExtension </d2:maintenanceVehiclesExtension> </d2:maintenanceVehicles> -> Ergänzung bei verändertem Status durch STATUS-Meldung (siehe 3.4.3) d2:roadMaintenanceTypemaintenanceWork</d2:roadMaintenanceType> </d2:situationRecord> </d2:situation> </d2:payloadPublication> </d2:d2LogicalModel> Beispiel 2 (Teil 2 von 2): Intervallmeldung

3.4.3. Status Unter Punkt 2.2 ist angeben unter welchen Umständen eine Statuslmeldung zu senden ist. Die Statusmeldung gleicht der Intervallmeldung, meldet jedoch zusätzlich die Status der Tafel und deren Elemente im Tag „maintenanceVehicles“.

… d2:maintenanceVehicles d2:maintenanceVehiclesExtension d2:maintenanceVehiclesExtended d2:maintenanceLightStatearrowLeft</d2:maintenanceLightState> d2:maintenanceTableStateflippedUp</d2:maintenanceTableState> d2:maintenanceArrowStateleft</d2:maintenanceArrowState> </d2:maintenanceVehiclesExtended> </d2:maintenanceVehiclesExtension> </d2:maintenanceVehicles> … Beispiel 3: Statusmeldung

3.4.4. Fehler Unter Punkt 2.2 ist angeben unter welchen Umständen eine Fehlerlmeldung zu senden ist. Die Fehlermeldung gleicht der Intervallmeldung, meldet jedoch zusätzlich das Tag „errorState“ innerhalb dem Tag „mobilityExtended“.

… d2:mobilityExtended d2:speed16</d2:speed> d2:blockingDirectioninDirectionOfBearing</d2:blockingDirection> d2:numberOfSatellites12</d2:numberOfSatellites> d2:gpsStatusdgps3D</d2:gpsStatus> d2:errorState101</d2:errorState> </d2:mobilityExtended> …

Beispiel 4: Fehlermeldung

20