HABIS:TD04

Aus HABISWiki

Wechseln zu: Navigation, Suche

Inhaltsverzeichnis

Anwendungsbereich

Anwendungsbereich der EVU-Schnittstelle TD04 ist der Datenaustausch zwischen EVUs und HABIS (als operativem System für den Rangierbetrieb, und als Knoten zum Verteilen der Daten an alle weiteren Beteiligten in den Prozessen der Hafenbahn).


Umfang

TD04 erstreckt sich auf den Austausch von Transportauftragsdaten und Zugreihungen. Abgedeckt wird der Bahnempfang/eingehende Züge und der Bahnversand/ausgehende Züge, für den KV und den WLV. Die Schnittstellen-Beschreibung definiert

  • allgemeine Regeln der Kommunikation für die Schnittstelle,
  • TD04-Nachrichten für Auftragsdaten, Reihungen, Quittungs- und Statusmeldungen,
  • Szenarien, d.h. mögliche Abfolgen von Nachrichten bei der Bearbeitung von Aufträgen und Reihungen.


Kommunikationsregeln

Registrierung

Organisationen, die über die TD04-Schnittstelle Daten mit HABIS austauschen wollen, müssen sich bei der HPA registrieren und einen Nutzungsvertrag abschließen. Sie erhalten dann einen Teilnehmer-Code, der im EDI-Header beim Nachrichtenversand anzugeben ist. Ein Teilnehmer kann auch eine Benutzerkennung erhalten für den Zugang zur Schnittstelle über den EVU-Webclient.

Eine Registrierung ist möglich als EVU oder als EDI-Provider, der für ein oder mehrere EVUs technisch die Schnittstelle betreiben kann. Die Registrierung ist für ein EVU in jedem Fall erforderlich, damit Daten dieses EVU an der TD04-Schnittstelle akzeptiert werden. Wenn sich das EVU der Dienste eines EDI-Providers bedient, ist bei der Registrierung des EVU der Teilnehmer-Code des Providers anzugeben.

Ein EDI-Provider muss nicht als EVU registriert sein, wenn er nur den Datenaustausch für andere betreibt. Er tritt dann nur in der Kommunikation als Provider auf, Eigentümer der Daten bleibt das EVU (d.h. die Daten sind mit dem Webclient auch nur unter der Benutzerkennung des EVU einsehbar).

Syntax

Bei den Nachrichten der TD04-Schnittstelle handelt es sich um Nachrichten im XML-Format. Sie sind mittels XSD definiert. Diese Schema-Beschreibungen sind Teil der TD04-Dokumentation, s. unter weiterführende Dokumentation.

Als Zeichensatz wird derzeit ISO 8859-15 benutzt (das ist eine Erweiterung von ISO 8859-1 um das Euro-Zeichen und um finnische Sonderzeichen). UTF-8 wäre eine mögliche Option für die Schnittstelle, allerdings würde die Benutzung von Sonderzeichen wegen der Darstellung in mehreren Bytes zu einem Problem in HABIS Classic führen.

Datum und Uhrzeit werden gemäß des Standards ISO 8601 dargestellt, allerdings ohne Zusatzangaben wie "Z" oder "+1h". Interpretiert wird die Uhrzeit als die lokale Zeit von Hamburg. Beispiele:

  • Datum: 2008-01-16
  • Uhrzeit: 17:30
  • Zeitstempel: 2008-01-16T13:18:22


EDI-Struktur

Ein TD04-XML-Dokument (= eine übertragene Datei) besteht aus einem EDI-Header ("Metainfo") und mindestens einer, evtl. mehreren Nachrichten.

Bild:TD04_Document_struct.jpg

Für ein Dokument wird eine Referenznummer ("ExchangeNumber") angegeben und Datum/Uhrzeit der Erzeugung. Außerdem kann die Anzahl der enthaltenen Nachrichten angegeben werden und eine Kennzeichnung, dass es sich um einen Test handelt. Es können nur Nachrichten der gleichen Art (Nachrichtentyp plus -version) in einem Dokument zusammgefasst werden.

Im EDI-Header werden Absender und Empfänger des Dokuments angegeben, evtl. auch ein EDI-Provider (s. auch Registrierung).

Jede Nachricht in einem Dokument erhält eine Nachrichtenreferenz, die pro Absender eindeutig sein muss. Außerdem kann für jede einzelne Nachricht eine Kontaktperson benannt werden.

Bild:TD04_Business_Doc_Detail.jpg

Jede Nachrichten beginnt (im Element "BusinessDocumentDetail") mit der Angabe des EVU, der fachlichen Referenz des Objekts, auf das sich die Nachricht bezieht, sowie der Version des Fachobjekts. Fachliche Referenzen eines Transportauftrags sind seine Auftragsnummern: die primäre, vom EVU vergebene eindeutige Auftragsnummer, und die von HABIS Classic vergebene sog. TA-Nummer. Fachliche Referenz einer Wagenreihung ist die Kombination Zugnummer + Verkehrstag.

Ein Fachobjekt wird neu angelegt mit der Version "01". Mit einer Änderung wird eine neue Versionsnummer vergeben, die höher sein muss als die aktuell in HABIS bekannte Version, ansonsten wird die Änderung abgelehnt (Lücken sind erlaubt). Bei einem Storno wird ebenfalls die zu stornierende Version des Objekts angegeben, sie darf nicht kleiner als die in HABIS bekannte Version sein. Mit diesem Verfahren wird verhindert, dass aktuelle Daten durch ältere Daten überschrieben werden (wenn sich z.B. wegen technischer Störungen Nachrichten überholen).

Die Daten eines fachlichen Objekts können mit unterschiedlicher Verbindlichkeit mitgeteilt werden. Für einen auf den Hafen zulaufenden Container kann beispielsweise ein Transportauftrag gesendet werden bei Anlage des Auftrags (d.h. der Transport ist geplant / beauftragt und die Daten sind evtl. noch unvollständig), bei Abfahrt (auch mehrfach, wenn der Container über mehrere Bahnhöfe geleitet wird) und bei Ankunft. Die Verbindlichkeit der Daten wird im Element "MessageSignificance" angegeben.

Quittierung

Nachrichten - außer Quittungsmeldungen selbst - werden grundsätzlich quittiert. Dies wird vom Empfänger der von HABIS versendeten Nachrichten erwartet, und HABIS quittiert seinerseits alle empfangenen Nachrichten.

Eine Quittung kann positiv oder negativ sein. Positiv bedeutet, dass nicht nur die quittierte Nachricht technisch empfangen wurde, sondern dass die Daten auch gespeichert und in die zuständige Anwendung weitergereicht wurden. Eine positive Quittung signalisiert dem Absender, dass er mit der weiteren Bearbeitung des übermittelten Vorgangs rechnen kann. Negativ bedeutet hingegen, dass zwar die Nachricht auf der EDI-Ebene angekommen ist (sonst könnte sie nicht quittiert werden), aber die Daten nicht übernommen werden konnten. Mit einer negativen Quittung werden auch die Gründe für die Ablehnung der Nachricht mitgeteilt.

Bleibt eine Quittung aus, so muss davon ausgegangen werden, dass eine Störung der Kommunikation vorliegt. Die Nachricht wurde entweder nicht gesendet, oder die versendete Nachricht ist nicht angekommen, oder sie ist im empfangenden System nicht verarbeitet worden. Die Zeitspanne, nach der eine Quittung als "fehlend" erklärt wird, ist in jedem an der Kommunikation teilnehmenden System selbst festzulegen, ebenso wie die Reaktion in so einem Fall.

Statusmeldungen

Statusmeldungen werden in drei unterschiedlichen Varianten benutzt, zur Information über den Bearbeitungsstatus eines Fachobjekts, als Rückweisung bei Bearbeitungs-Hindernissen, und zur Stornierung (Beschreibung s. unter Statusinformation).


Nachrichten

Quittungsmeldung

Bild:TD04_Response_Def.jpg

Die Quittungsmeldung (Response Message) dient dazu, den Empfang einer (anderen) Nachricht zu bestätigen (s. auch Quittierung). In der Quittungsmeldung wird die quittierte Nachricht durch ihre Nachrichtenreferenz angegeben, im Element <BusinessDocumentDetail>/<Reference> mit dem Attribut type = "ORIGMS".

Die Quittungsmeldung enthält mindestens ein Element <Text>, welches bei einer positiven Quittung (d.h. Nachricht empfangen) den Code 00000 enthält, bei einer negativen Quittung (Nachricht abgelehnt) einen Code > 99000. In beiden Fällen können weitere Elemente <Text> folgen, mit Angaben zu Fehlern bei einer negativen Quittung bzw. mit Hinweisen/Warnungen bei einer positiven Quittung. Zusätzlich zum ersten <Text>-Element kann noch im Element <GeneralResponseCode> spezifiziert werden, ob es sich um eine positive oder negative Quittung handelt. Positive Quittungen sind in diesem Element mit O (= o.k.) oder W (= warning) gekennzeichnet, negative mit E (= error).

Struktur der Nachricht: TD04_Response.html

Statusinformation

Bild:TD04_Status_Def.jpg

Die Statusnachricht wird in drei unterschiedlichen Varianten benutzt:

als Statusmitteilung 
gekennzeichnet durch <StatusInformation>. Statusmeldungen können, soweit sie in den Szenarien vorgesehen sind, als Information zu einem Fachobjekt von den Kommunikationspartnern beim Eintreten bestimmter Ereignisse oder nach Durchführung bestimmter Bearbeitungsschritte gesendet werden. Beispielsweise wird die Verladung eines Containers auf einen Waggon (Fachobjekt = Ladeeinheit eines Auftrags) oder die Einfahrt eines Zuges (Fachobjekt = Zug) als Statusmeldung von HABIS an das betroffene EVU gesendet. Statusmeldungen können auch vom EVU an HABIS kommuniziert werden (z.B. die Abfahrt eines Zuges).
 
Eine Statusangabe besteht immer aus <StatusQualifier> und <StatusCode> (zu den Werten s. die Interface Description unter weiterführende Dokumentation). Zusätzlich angegeben sein kann ein Status-Text und der Zeitpunkt des den Status auslösenden Ereignisses. Weitere Schlüsselwerte können zusammen mit der Statusinformation übertragen werden, diese Möglichkeit wird aber derzeit von HABIS nicht genutzt.
als Rückweisung 
gekennzeichnet durch <ErrorMessage>. Statusmeldungen als Rückweisung werden nur von HABIS ans EVU gesendet. Rückweisungen sind in der Regel manuell von HABIS-Mitarbeitern oder von der Ladestelle ausgelöste Mitteilungen darüber, dass ein Fachobjekt nicht wie vorgesehen weiter bearbeitet werden kann. In einer Rückweisung wird die auslösende Institution und der Begründungstext mit übertragen, sowie die Angabe, ob es sich um eine manuelle oder automatische Rückweisung handelt.
als Stornoantrag 
gekennzeichnet durch <DeletionRequest>. Ein EVU kann einen Transportauftrag stornieren, wenn dies vom Fortschritt der Bearbeitung her noch möglich ist. Dazu wird eine Statusmeldung als Stornoantrag vom EVU an HABIS gesendet. Wenn der Auftrag storniert wurde, wird der neue Status von HABIS als Statusmitteilung zurück übertragen. Als <Type> des zu stornierenden Objekts wird derzeit nur "T" für Transport Order berücksichtigt.

Struktur der Nachricht: TD04_StatusInformation.html

Transportauftrag

Die Nachricht TransportOrder dient zur Übermittlung von Daten eines Transportauftrags. Sie wird im Bahnversand und im Bahnempfang benutzt, für den KV wie für den WLV. Für die Neuanlage und zur Änderung von Aufträgen wird die TransportOrder von einem EVU an HABIS gesendet. Nach erfolgter Verladung wird ebenfalls mit dieser Nachricht der aktuelle Stand des Auftrags (als Verladedaten) von HABIS an das EVU zurück gemeldet.

Eine TransportOrder enthält immer die vollständigen Daten eines Transportauftrags. Löschen von Teilen des Auftrags, z.B. das Herausnehmen einer Ladeeinheit, geschieht durch übermitteln einer Änderung, in der die zu löschende Ladeeinheit nicht mehr enthalten ist. Änderung und Stornierung von Aufträgen sind Regeln unterworfen, die vom Arbeitsfortschritt auch anderer Beteiligter (z.B. der Ladestelle) abhängen. Siehe dazu auch die verschiedenen Szenarien, und die Schnittstellenbeschreibung unter weiterführende Dokumentation.

Struktur der Nachricht: TD04_TransportOrder.html

Zollinformation

Bild:TD04_Customs_Info_Def.jpg

Diese Nachricht wird nur im Bahnversand WLV benutzt. Sie dient dazu, zu den einzelnen Wagen eines Transportauftrags Daten für HABIS Zoll nachzuliefern. Es handelt sich hier um das Zollverfahren (<CustomsProcedure>) und - soweit erforderlich - die HA-Nummer. Diese Daten können im WLV oft erst nach Verladung geliefert werden, weil erst dann die Wagennummern bekannt sind.

Struktur der Nachricht: TD04_CustomsInformation.html

Wagenreihung

Die Wagenreihung dient zur Übermittlung von Zug- und Wagendaten für den Bahnbetrieb. Bei auf den Hafen zulaufenden Zügen wird die Meldung vom EVU an HABIS gesendet, bei ausfahrenden Zügen meldet HABIS an das EVU. Die Reihung kann nach Ende der Zugbildung erfolgen, oder bei Abfahrt des Zuges (auch mehrfach, z.B. bei Abfahrten in mehreren Bahnhöfen in Folge).

Zum Zug werden Abfahrts- und Ankunftsdaten genannt, sowie Angaben zu Längen und Gewichten. Es werden alle Wagen entsprechend ihrer Reihenfolge im Zug aufgelistet, jeweils mit den wichtigsten Daten und evtl. bestehenden Betriebseinschränkungen. Es können weiterhin für jeden Wagen Angaben zu den Ladeeinheiten und gegebenenfalls zu Gefahrgut in der Nachricht enthalten sein. Querverweise zu den Transportaufträgen können spezifiziert werden.

Struktur der Nachricht: TD04_WagonSequence.html

Szenarien

Es werden hier als Beispiele einige Abläufe dargestellt, die Standardsituationen beschreiben. Das sind zunächst diejenigen Abläufe, bei denen Transportaufträge gemeldet und ohne weitere Besonderheiten vollständig abgearbeitet werden:


Transportaufträge können geändert oder storniert werden. Insbesondere nach einer Rückweisung wird normalerweise eine Änderung der Auftragsdaten erwartet.


Deutlich weniger umfangreich sind die Szenarien für die Zugmeldungen (hier inklusive Änderungen, Stornierung einer Wagenreihung ist nicht vorgesehen):


Eine besondere Situation ergibt sich, wenn der Empfänger einer Nachricht mit einer Fehlermeldung antwortet:


weiterführende Dokumentation

Das TD04-Handbuch findet sich unter TD04-Dokumentation.

Aufträge können in HABIS ohne Nachbearbeitung weiterverarbeitet werden, wenn die Daten dafür vollständig angegeben wurden. Dazu werden zusätzliche Prüfungen von Auftragsdaten beim Empfang von Transportaufträgen vorgenommen.

Genauere Angaben zu den Statuswerten von Transportaufträgen und Zugreihungen finden sich auf der Seite TD04 - Statuswerte.

Persönliche Werkzeuge