Technische Anforderungen an die TLS-Schnittstelle

Transkript

1 DokumentNummer Version Gültig ab DokumentenStatus Verteilerstatus Arbeitsgruppe Anzahl Seiten öffentlich PLaPB Technisches Planungshandbuch der ASFINAG AUTOBAHNEN- UND SCHNELLSTRASSEN-FINANZIERUNGS-AKTIENGESELLSCHAFT Rotenturmstraße 5 9, 1010 WIEN, Telefon +43 (0) , Telefax + 43 (0)

2 Änderungsberechtigte Name Firma / Abteilung Telefon - Nummer Fax - Nummer E - Mail ASFINAG BMG / EM +43 (0) (0) Wissounig Wolfgang wolfgang.wissounig@asfinag. at Dokumentenfreigabe Erstellt von: Geprüft von: Freigegeben von: Gesellschaft/ Abt./ Name BMG / EM / W. Wissounig e.h. Gesellschaft/ Abt./ Name BMG / EM / K. Portschy e.h. Gesellschaft/ Abt./ Name BMG / EM / R. List e.h Datum: Datum: Datum: Gültigkeit Version gültig von: gültig bis: Dokumentenhistorie Version gültig ab Dokumenten- Status Verteiler- Status Verantwortlicher Änderungsgrund öffentlich ASFINAG Anpassung an interne Richtlinie (Version 2.00), Ergebnisse der Begutachtungsphase Entwurf Konzern ASFINAG Erstausgabe Druckdatum: Seite 2 von 28 Dokumentname: PLaPB Technische Anforderungen an die TLS Schnittstelle TKo - UZ

3 Inhaltsverzeichnis 1 ALLGEMEINES AUSPRÄGUNG DER SCHNITTSTELLE Meldeschnittstellen VBA Tunnelsteuerung Tunnelsteuerung VMIS Systemebenen Verkehrsdatenerfassung Wechselverkehrszeichen DETAILLIERTE FESTLEGUNG DES FUNKTIONSUMFANGS KRI Funktionalität Funktionsgruppe Fehlermeldungen Initialisierungsmeldung Zeitsynchronisation Kommunikationsstatus Statische Gerätekenndaten Logische Adressierung DE-Konfiguration Knotennummer und Konfigurationstabellen OSI3-Routingfeld Reset Abläufe Anwendungsfunktionsgruppen allgemein Herstellercode DE-Fehlermeldungen Ergänzende DE-Fehlermeldung Kanalsteuerung Geographische Kenndaten Funktionsgruppe 1 Verkehrsdaten Kurzzeitdaten Langzeitdaten Einzelfahrzeugdaten Abfragen von Verkehrsdaten Abfragen von Pufferdaten Geschwindigkeitsklassen Streckenbezogenen Verkehrsdaten LVE-Betriebsparameter Abläufe Druckdatum: Seite 3 von 28 Dokumentname: PLaPB Technische Anforderungen an die TLS Schnittstelle TKo - UZ

4 3.5 Funktionsgruppe 2 Achslastdaten Funktionsgruppe 3 Umfelddaten Funktionsgruppe 4 Wechselverkehrszeichensteuerung Funktionsgruppenspezifische Fehlermeldungen Betriebsart Helligkeitssteuerung Anzeigeprinzipien Steuerungsprinzipien Grundeinstellung Codedefinition Codeliste Stellzustände Nachrichtenpufferung Abläufe Programmsteuerung durch die Zentralentechnik Funktionsgruppe 6 Betriebsmeldungen Abläufe Tunnelspezifische Meldungstypen DE-Block-Struktur im Typ 132 Höhenkontrolle DE-Block-Struktur im Typ 133 Brandmeldung DE-Block-Struktur im Typ 134 CO-Wert Überschreitung DE-Block-Struktur im Typ 135 Sichttrübung DE-Block-Struktur im Typ 136 Notfall DE-Block-Struktur im Typ 137 zu viele Fahrzeuge DE-Block-Struktur im Typ 138 Richtungsbetriebsart Funktionsgruppe 7 steuerung Funktionsgruppe 8 Geschwindigkeitsüberwachung Funktionsgruppe 9 Zuflussregelung Druckdatum: Seite 4 von 28 Dokumentname: PLaPB Technische Anforderungen an die TLS Schnittstelle TKo - UZ

5 1 ALLGEMEINES Die Kommunikation zwischen dem VMIS und der Tunnelleittechnik erfolgt auf Seiten des VMIS grundsätzlich vollständig TLS-konform. Dies betrifft insbesondere Das Objekt- und Adressierungsschema Die Funktionsgruppen und Telegrammtypen Die Meldungsklassen Die Abläufe Einschränkungen existieren hinsichtlich des jeweiligen Umfangs. So müssen nicht alle Funktionsgruppen der TLS implementiert werden, innerhalb der Funktionsgruppen auch nicht alle Abläufe. Es ist insbesondere zulässig, zweckmäßig und teils sogar erforderlich, dass (in der TLS-Welt zulässige) Abläufe zur Beeinflussung und Parametrierung straßenseitiger Infrastruktur durch das VMIS im Umfeld der Tunnelsteuerung unterbunden werden. Diese Abläufe müssen aber trotz allem im Sinne der TLS-Kommunikation vollständig implementiert werden, die Einschränkung besteht darin, dass diese Abläufe tunnelseitig nicht ausgeführt, sondern lediglich entsprechend negativ quittiert werden. Darüber hinaus müssen Informationsinhalte, welche im Rahmen der TLS als eine Nachricht übertragen werden, auch vom Schnittstellenkonverter immer als eine Einheit behandelt werden, auch wenn die in der Nachricht zusammengefassten Informationsinhalte auf der Gegenseite der Schnittstelle als unabhängige Datenpunkte implementiert sind. Druckdatum: Seite 5 von 28 Dokumentname: PLaPB Technische Anforderungen an die TLS Schnittstelle TKo - UZ

6 2 AUSPRÄGUNG DER SCHNITTSTELLE Die Schnittstellen zwischen Tunnelsteuerung und VMIS haben inhaltlich folgende Aufgaben: Meldeschnittstellen Übermittlung von Daten des VMIS (Freifeld) an die Tunnelsteuerung Schaltzustände von dem Tunnel vor- und ggf. nachgelagerten Anzeigequerschnitten Ggf. vom VMIS erfasste Verkehrs- und Umfelddaten. Übermittlung von Daten der Tunnelinfrastruktur an das VMIS Verkehrszählwerte Schaltzustandsinformationen der VLSA und WZG Ggf. Gefahrmeldungen/Alarme der Tunnelsteuerung Anforderungsschnittstellen Übermittlung von Schaltanforderungen/-empfehlungen der Tunnelsteuerung an das VMIS Übermittlung von Schaltanforderungen/-empfehlungen des VMIS an die Tunnelsteuerung 2.1 Meldeschnittstellen VBA Tunnelsteuerung Die Übermittlung von Daten des VMIS (Freiland-VBA) an die Tunnelsteuerung kann grundsätzlich durch Nutzung von Mithörschnittstellen der die jeweilige VBA-Infrastruktur abschließenden KRIs erfolgen. Diese Schnittstellen sind standardmäßig in ausreichender Anzahl vorhanden und können (nach Inbetriebnahme der KRIs) sofort genutzt werden. Die Kommunikation erfolgt IP-basiert (TLSoIP). Der Tunnelsteuerung wird damit der gesamte Telegrammverkehr zwischen Unterzentrale und der straßenseitige Infrastruktur zur Verfügung gestellt. Es erfolgt dabei seitens des KRI keine Filterung nach Funktionsgruppen, Telegrammtypen oder Infrastrukturobjekten. Diese Filterung (entspricht Ignorieren nicht relevanter Information) erfolgt seitens der mithörenden Tunnelsteuerung. Umfang und Inhalt der TLS-Kommunikation sind üblicherweise vollständig in der IHB-Dokumentation des entsprechenden AA-Gewerks definiert. Diese Schnittstelle ist auf OSI2-Ebene selbstverständlich bidirektional (TLSoIP), wobei in der Regel der KRI den Server und die Tunnelsteuerung den Client realisiert. Auf Anwendungsebene (OSI7) ist diese Schnittstelle strikt unidirektional, d.h. alle von der Tunnelsteuerung eintreffenden Telegramme in Abrufrichtung werden bereits durch den KRI verworfen. Erforderlichenfalls kann an den jeweiligen mitzuhörenden KRIs auch eine (weitere, temporär zu nutzende) Schnittstelle für Generalabfragen eingerichtet werden. Über diese Schnittstellen kann und darf die Tunnelsteuerung Abfragetelegramme an die VBA- Infrastruktur versenden. Diese Schnittstelle darf in der Regel nur nach Neuanlauf der mithörenden Tunnelsteuerung verwendet werden, damit diese sich über den aktuellen Gesamtstatus der relevanten VBA-teile informieren kann. Die Filterung auf aus- Druckdatum: Seite 6 von 28 Dokumentname: PLaPB Technische Anforderungen an die TLS Schnittstelle TKo - UZ

7 schließlich Abfragetelegramme wird dabei ebenfalls vom KRI übernommen, andere als abfragende Telegramme werden (vom KRI) negativ quittiert. Eine Beeinflussung der VBA-Infrastruktur ist damit nicht möglich Tunnelsteuerung VMIS Diese Schnittstelle soll grundsätzlich gleich funktionieren wie die unter Punkt beschriebene. Dies bedeutet insbesondere, dass sich die Schnittstelle gegenüber dem VMIS wie ein KRI2B entsprechend PLaNT verhält. Da aber in der Regel die Infrastruktur des Tunnels nicht gemäß TLS errichtet ist, sind hier weitere Definitionen und Festlegungen erforderlich Systemebenen Die für das VMIS relevante Tunnelinfrastruktur muss virtuell entsprechend den in der TLS definierten Systemebenen Steuermodule (SM), Ein-/Augabekonzentratoren (EAK) und Datenein- und ausgabegeräte (DEG/DAG) konfiguriert werden. Diese Elemente müssen im TLS-Protokoll sowohl logisch (Knotennummern und DE-Kanalnummern) als physikalisch (OSI2-Ein- und Ausgangsadressen sowie EA-Kanalnummern) adressiert werden. Die Zuordnung vorhandener Infrastruktur zu virtuellen Steuermodulen ist dabei relativ frei, empfehlenswert ist eine standortbezogene Zusammenfassung, wobei zumindest auf zwei Richtungsfahrbahnen gegenüberliegende Betriebsmittel jeweils dem gleichen Steuermodul zugeordnet werden sollen. Eine weitere Zusammenfassung von mehreren dicht (ca. < 500m) beieinander liegenden Querschnitten unterhalb eines SM bedarf der Abstimmung im Einzelfall. Die Zuordnung der tunnelseitig relevanten Betriebsmittel zu den Funktionsgruppen gemäß TLS ist eindeutig: Verkehrsdatenerfassungsgeräte gehören zur Funktionsgruppe 1 Wechselverkehrszeichen (inklusive VLSA) gehören zur Funktionsgruppe 4 Ggf. zur Helligkeitssteuerung der Wechselzeichengeber verwendete Helligkeitssensoren gehören zur Funktionsgruppe 3 Gefahrenmeldungen gehören zur Funktionsgruppe 6 Es empfiehlt sich, pro Funktionsgruppe jeweils einen eigenen virtuellen EAK zu modellieren, lediglich die Funktionsgruppe eines ggf. vorhandenen Helligkeitssensors muss auf dem zugehörigen FG4-EAK realisiert werden Verkehrsdatenerfassung Die durch die Tunnelsteuerung erfassten Verkehrsdaten sollen dem VMIS vollständig zur Verfügung gestellt werden, und zwar sowohl in Form von Kurzzeitdaten als auch in Form von Langzeitdaten. Welche Version (0-6) von Kurzzeitdaten übertragen werden können, hängt von der Ausprägung der jeweiligen Tunnelinfrastruktur ab. Als Mindestversion wird in der Regel die LVE-Ergebnismeldung Version 3 erwartet. Druckdatum: Seite 7 von 28 Dokumentname: PLaPB Technische Anforderungen an die TLS Schnittstelle TKo - UZ

8 Als Erfassungsintervall wird grundsätzlich 1 Minute erwartet, Abweichungen davon bedürfen der jeweiligen Abstimmung. Für Langzeitdaten wird als Intervall 1 Stunde erwartet. Eine Veränderung der LVE-Betriebsparameter über diese Schnittstelle ist in der Regel nicht vorgesehen. Eine Abfrage der verwendeten Betriebsparameter (mit ID 19) über das Telegramm Typ32 (sowie ggf. Typ37 und Typ38) soll allerdings möglich sein und korrekt beantwortet werden, eine Zuweisung dieser Parameter soll durch die Tunnelsteuerung negativ quittiert werden. Darüber hinaus sind Funktionsstörungen der Verkehrserfassungsgeräte mindestens als DE-Fehlermeldung (Typ1) zu melden, wenn die jeweiligen Detektoren nicht betriebsbereit sind. Abfragen der Typ1-Fehlermeldung sollen jederzeit möglich sein und korrekt beantwortet werden, alle anderen Meldungen der ID1 (Störmeldungen) können bei Abfrage negativ quittiert werden Wechselverkehrszeichen Der Umfang der für das VMIS relevanten Wechselzeichengeber hängt (neben der Ausstattung des Tunnels) von der Integrationskomplexität ab. Als Mindestanforderung gilt, dass die Schaltzustände der Portals-VLSA übertragen werden, wobei jede VLSA als einzelnes DE zu adressieren ist. Aus Gründen der optimalen Reaktionsfähigkeit einer VBA-Steuerung ist es allerdings sinnvoll, grundsätzlich den Zustand aller WZG (VLSA, WZG A und WZG B sowie, falls vorhanden, der Infotafeln und weiterer WZG) zu übertragen. Lediglich die Übertragung der Schaltzustände von Blinkern in Notrufnischen kann in der Regel immer entfallen. Ggf. kann auch die Übertragung von Wiederholungs-WZG im Tunnel entfallen. WZG der Portals- und Vorportalsquerschnitte allerdings sollen immer vollständig übertragen werden, genauso ggf. hinter dem Tunnel befindliche Aufhebungsquerschnitte. Alle WZG sind in der Regel als WZG nach Anzeigeprinzip b zu modellieren, das heißt als aktiv leuchtend mit festen oder quasi-festen Zeicheninhalten Der jeweils aktuelle Stellzustand soll immer mit dem Telegramm Typ 55 spontan übertragen werden. Eine Mehrfachübertragung des Telegramms aufgrund des Wechsels mehrerer beteiligter Datenpunkte auf der IEC-Seite ist dabei zu unterbinden. Eine Abfrage des aktuellen Stellzustandes soll jederzeit über das entsprechende Abruftelegramm Typ 55, ID 21 möglich sein und korrekt beantwortet werden. Eine Zuweisung von Stellzuständen soll durch die Tunnelsteuerung negativ quittiert werden. Darüber hinaus sind Funktionsstörungen der WZG mindestens als DE-Fehlermeldung (Typ1) zu melden, wenn die jeweiligen WZG nicht betriebsbereit sind. Abfragen der Typ1-Fehlermeldung sollen jederzeit möglich sein und korrekt beantwortet werden, alle anderen Meldungen der ID1 (Störmeldungen) können bei Abfrage negativ quittiert werden. An einem Standort zusammengehörende WZG sind als ein Anzeigequerschnitt zu modellieren, d.h. insbesondere jeweils einem Clusterkanal zuzuordnen. Dabei sind Be- Druckdatum: Seite 8 von 28 Dokumentname: PLaPB Technische Anforderungen an die TLS Schnittstelle TKo - UZ

9 triebsmittel auf unterschiedlichen Richtungsfahrbahnen auch bei gleicher Stationierung als unterschiedliche Anzeigequerschnitte zu betrachten. Für jeden Anzeigequerschnitt muss auch die Betriebsart übertragen werden, wobei hier immer die Betriebsart Handbetrieb gemeldet werden soll, um der steuernden UZ zu signalisieren, dass eine Beeinflussung nicht möglich ist. Auch die Betriebsart muss jederzeit abgefragt werden können. Eine Zuweisung der Betriebsart wird negativ quittiert. Druckdatum: Seite 9 von 28 Dokumentname: PLaPB Technische Anforderungen an die TLS Schnittstelle TKo - UZ

10 3 DETAILLIERTE FESTLEGUNG DES FUNKTIONSUMFANGS In den folgenden Tabellen werden alle Abläufe der OSI 7-Schicht mit Ausnahme von Fehlerfällen und der Initialisierungsphase dargestellt. Jeder Ablauf besteht bis auf spontane Meldungen aus einer DE-Block-Struktur in Abrufrichtung, auf die mit einer oder mehreren DE-Block-Strukturen in Antwortrichtung reagiert werden muss. Im Normalfall ist die Antwort positiv. Kann der Abruf nicht beantwortet werden, wird eine negative Antwort gesendet. Jeder Ablauf innerhalb einer FG hat einen eindeutigen Namen. Die Namen von Abläufen, bei denen Daten oder Parameter abgerufen werden, beginnen mit einem Fragezeichen?. Die Namen von Abläufen, bei denen Parameter oder Befehle zugewiesen werden, beginnen mit einem Ausrufezeichen!. Die Namen von spontanen Abläufen beginnen mit einem Gleichheitszeichen =. Sind auf eine Nachricht in Abrufrichtung mehrere alternative Antworten erlaubt, stehen diese in der entsprechenden Zelle untereinander. Müssen in einem Telegramm DE-Blöcke mit unterschiedlichen Typen gesendet werden, so sind diese in der Tabelle mit einem Pluszeichen + verbunden. Alle unterstrichenen Abläufe und Telegramme sind Standard, während die optionalen Abläufe nicht unterstrichen sind. Die Unterstreichung ist nur in der Spalte Name ausgeführt. 3.1 KRI Funktionalität KRI-Parameter: C_UZ_Port C_WaitInitComplete C_StopPolling C_MirrorScripttOut C_ScriptKommStatusOk C_ScriptKommStatusNotOk TLSoIP-Server-Parameter: C_AcceptPort C_PortMode C_ClientCount C_ActivePort C_XmitRequest C_XmitAnswer TLS-Master-Parameter: C_TelTypeList C_3_Address C_7_IDList Druckdatum: Seite 10 von 28 Dokumentname: PLaPB Technische Anforderungen an die TLS Schnittstelle TKo - UZ

11 C_7_JopRange Auszug aus PLaNT : Abbildung 1: Musterkonfiguration der ServerPorts gemäß TLSoverIP 3.2 Funktionsgruppe 254 Die Funktionsgruppe 254 Systemsteuerung muss zur Gewährleistung einer TLSkonformen Kommunikation jedenfalls implementiert werden. Alle Geräte (KRI, SM, EAK) sind jedoch rein virtuell und haben in der Regel auch keine direkte physikalische Entsprechung in der Tunnelinfrastruktur, sondern höchstens in der SW- bzw. Prozessarchitektur des die Schnittstelle implementierenden Treibers Fehlermeldungen Wenn der Schnittstellentreiber keine speziellen, insbesondere verteilte Prozessarchitekturen verwendet, ist in der Regel davon auszugehen, dass alle systemtechnischen Komponenten (KRI, SM, EAK) jeweils funktionsfähig sind und bleiben, solange der Schnittstellenprozess läuft. Die Fehlermeldungen Typ 1 und 14 sind daher (im Anlaufverhalten und auf Abruf) jeweils als Gutmeldungen auszuführen. Druckdatum: Seite 11 von 28 Dokumentname: PLaPB Technische Anforderungen an die TLS Schnittstelle TKo - UZ

12 3.2.2 Initialisierungsmeldung Die Implementierung des Telegramms für den virtuellen KRI ist erforderlich. Eine Meldung auf Ebene der SM ist in der Regel aufgrund der SW-Emulation nicht sinnvoll Zeitsynchronisation Die Implementierung der Zeitsynchronisation ist jedenfalls erforderlich. Sie ist aber nicht im Sinne einer Beeinflussung der Systemuhr(en) der Tunnelsteuerung zu verstehen, sondern wird lediglich im Schnittstellentreiber zur Generierung TLS-konformer Zeitstempel verwendet. Der Treiber hat dabei bei Empfang einer Zeitsynchronisation jeweils den Zeitoffset zur aktuellen Systemzeit der Tunnelsteuerung zu ermitteln und in der Folge bei der Generierung eines jeden Zeitstempels diesen Zeitoffset auf die dann aktuellen eigene Systemzeit bzw. die Meldezeit der Nachricht zu addieren. Ebenso muss der Treiber bei tunnelinternen Korrekturen der eigenen Systemzeit diesen intern verwalteten Zeitoffset entsprechend mitführen. Die mit der Zeitsynchronisation übermittelte Zeitzone ist ebenfalls in allen in der Folge zu generierenden Zeitstempeln zu verwenden Kommunikationsstatus Abruf und Beantwortung des Telegramms Typ 19 sind auf dem KRI-Link erforderlich. Der Schnittstellenprozess hat beim Neustart für alle emulierten SM den Kommunikationsstaus zu übermitteln, wobei dieser aufgrund der Realisierung als SW-Emulation immer als ok gemeldet werden kann. Eine Verwendung des Telegramms auf dem Lokalbus zwischen SM und EAK ist nicht erforderlich Statische Gerätekenndaten Die Nachricht soll den Hersteller sowie die Hardware- und Softwareversion (Firmware) des Schnittstellentreibers enthalten Logische Adressierung DE-Konfiguration Diese Nachricht ist als reine Lokalbusnachricht nicht erforderlich Knotennummer und Konfigurationstabellen Ein Abruf von Konfigurationstabelle (Typ 34 oder 39) und Knotennummer (Typ 37) und die korrekte Beantwortung sind jedenfalls zu implementieren. Abhängig vom der Anzahl maximal einem SM zugeordneter DEs ist entweder Typ 34 oder Typ 39 (erweiterte Konfigurationstabelle) zu implementieren. Ebenso sind Abruf und Beantwortung des Telegramms Typ 127 Konfigurationstabelle KRI zu implementieren. Druckdatum: Seite 12 von 28 Dokumentname: PLaPB Technische Anforderungen an die TLS Schnittstelle TKo - UZ

13 Eine Zuweisung und damit Änderung der logischen Adressen ist aus administrativen Gründen der Zentralentechnik dringend erwünscht. Es kann aber im Einzelfall projektspezifisch festgelegt werden, dass eine Zuweisbarkeit nicht implementiert werden muss. In diesem Fall ist ein Parametertelegramm der Zentralentechnik mit Code 1 unbekannte oder nicht auswertbare ID negativ zu quittieren. Wir die Zuweisung der Knotennummer implementiert, so ist auch die entsprechende spontane Änderungsmeldung der Konfigurationstabelle KRI zu implementieren OSI3-Routingfeld Abruf und Beantwortung des Telegramms Typ 35 sind zu implementieren. Es ist zulässig, dass lediglich Nullrouting für alle Funktionsgruppen gehandhabt wird. Eine Zuweisung des OSI3-Routingfelds mit ID 3 soll dann mit Code 1 unbekannte oder nicht auswertbare ID negativ quittiert werden Reset Das Telegramm Reset (Typ 38) muss nur für die Adresse des virtuellen KRI implementiert werden. Es hat zur Folge, dass der TLS-Schnittstellentreiber neu gestartet werden muss. Da die SM und EAK im Schnittstellentreiber lediglich per SW emuliert werden, hat eine separate Reset-Funktionalität auf dieser Ebene in der Regel keinen Sinn Abläufe Tabelle 1: Abläufe der FG 254 Name Bem. Abruf Pos. Antwort neg. Antwort =DE-Fehlermeldung ?DE-Fehlermeldung =Ergänzende DE- Fehlermeldung?Ergänzende DE- Fehlermeldung =Initialisierungsmeldung !Zeitsynchronisation ?Zeitsynchronisation =Kommunikationsstatus?Kommunikationsstatus Nur auf dem KRI-Link Druckdatum: Seite 13 von 28 Dokumentname: PLaPB Technische Anforderungen an die TLS Schnittstelle TKo - UZ

14 ?Statische Gerätekenndaten !Konfigurationstabelle ?Konfigurationstabelle !OSI3-Routingfeld ?OSI3-Routingfeld !Geographische Kenndaten ?Geographische Kenndaten !Knotennummer ?Knotennummer !Reset !Erweiterte Konfigurationstabelle?Erweiterte Konfigurationstabelle =Zustand externe Steuerung ?Zustand externe Steuerung =Konfigurationstabelle KRI?Konfigurationstabelle KRI Anwendungsfunktionsgruppen allgemein Herstellercode Ist in einem Telegramm die Verwendung eines Herstellercodes erforderlich, so ist grundsätzlich der Herstellercode desjenigen zu verwenden, der die (emulierte) TLS- Schnittstelle implementiert hat. Der Herstellercode des Herstellers des jeweiligen tatsächlichen Endgerätes kann optional (wenn definiert) ebenfalls verwendet werden. 2 Nicht auf dem Lokalbus Druckdatum: Seite 14 von 28 Dokumentname: PLaPB Technische Anforderungen an die TLS Schnittstelle TKo - UZ

15 3.3.2 DE-Fehlermeldungen Für alle DE-Kanäle muss die DE-Fehlermeldung Typ 1 implementiert werden. Störungen des jeweiligen Endgeräts sind im Sinne einer Summenstörmeldung abzusetzen. Die Meldung ist mit Störung vom EAK erkannt zu kennzeichnen. Für gestört gemeldete Endgeräte/Datenquellen werden in der Folge keine spontanen Telegramme mehr versendet Ergänzende DE-Fehlermeldung Für alle DE-Kanäle muss die ergänzende DE-Fehlermeldung Typ 14 implementiert werden. Von den funktionsgruppenspezifisch festgelegten Meldungsinhalten muss lediglich der Meldungsinhalt Teilstörung (codiert im TLS-Fehlerbyte 1, Bit 0) implementiert werden. Die Verwendung und Codierung weiterer Teilstörungsmeldungen ist optional, wobei die Codierungsvorgaben in den TLS-Fehlerbytes jedoch nicht verändert werden dürfen. Ebenso ist die Verwendung von Hersteller Fehlerbytes optional. Bei Teilstörungsmeldungen ohne gleichzeitig gemeldete Störung im Typ 1 erfolgt die spontane Datenübertragung weiterhin Kanalsteuerung Für alle DE-Kanäle muss das Prinzip der Kanalsteuerung vollständig TLS-konform implementiert werden Geographische Kenndaten Die Implementierung von Geographischen Kenndaten ist wie generell in der TLS optional. Wird das Telegramm nicht unterstützt, so sind alle empfangenen Telegramme vom Typ 36 in der jeweils korrekten Funktionsgruppe mit Code 2 unbekannter oder nicht auswertbarer Typ negativ zu quittieren. 3.4 Funktionsgruppe 1 Verkehrsdaten Die folgenden Festlegungen zur Funktionsgruppe 1 gelten unabhängig davon, ob die TLS-Schnittstelle in der aktiven oder passiven Variante implementiert wird. Von Tunnelsteuerung werden die Verkehrsdaten in der Regel sowohl als Kurzzeit- als auch als Langzeitdaten jeweils nur in einer (projektspezifisch festzulegenden) Version und in je einem (ebenfalls projektspezifisch festzulegenden) fixen Intervall aggregiert. Ebenso werden die Glättungsparameter und der Startwert für die Ermittlung der geglätteten mittleren Geschwindigkeit projektspezifisch festgelegt (Defaultwerte sind nachfolgend definiert). Druckdatum: Seite 15 von 28 Dokumentname: PLaPB Technische Anforderungen an die TLS Schnittstelle TKo - UZ

16 3.4.1 Kurzzeitdaten Für die Übertragung der Kurzzeitdaten soll bei Klassifizierung in 2 Klassen mindestens die Version 3 bzw. bei 5+1 (oder genauerer) Klassifizierung die Version 5 übertragen werden. Als Aggregationsintervall ist in der Regel 1 Minute vorzusehen. Eine Unterscheidung zwischen 8- und 16-Bit Version kann entfallen. Da aufgrund der verkehrlichen und baulichen Gegebenheiten in Tunneln Verkehrsstärken von über 254 Fahrzeugen pro Fahrstreifen, Aggregationsintervall und Fahrzeugklasse in aller Regel ausgeschlossen sind, genügt generell die Implementierung der 8-Bit-Version Langzeitdaten Für die Übertragung der Langzeitdaten ist bei Klassifizierung in 2 Klassen mindestens die Version 12 (Typ 67), bei Klassifizierung in 5+1-Klassen mindestens die Version 15 (Typ 70) und bei Klassifizierung in 8+1 Klassen mindestens die Version 20 (Typ 75) übertragen werden. Als Aggregationsintervall ist in der Regel 1 Stunde vorzusehen Einzelfahrzeugdaten Grundsätzlich ist die Übertragung der Sammelmeldung Kfz_Einzeldaten (Typ 62) sowie die zugehörige Parametrierung (Typ 33) vorzusehen. Dies dient insbesondere der Übertragungsmöglichkeit von detektierten Geisterfahrern (Meldeoption Falschfahrerdetektion ). Weitergehende Festlegungen/Einschränkungen bzgl. der Parametrierbarkeit können jeweils projektspezifisch erfolgen Abfragen von Verkehrsdaten Abfragen von anderen als den projektspezifisch festgelegten LVE-Versionen werden mit Code 2 unbekannter oder nicht auswertbarer Typ negativ quittiert. Abfragen mit Typ 48 und 64 sind zulässig und müssen TLS-konform beantwortet werden Abfragen von Pufferdaten Der Abruf von Pufferdaten durch die Zentralentechnik ist zulässig und muss vollständig TLS-konform implementiert werden. Es ist die Pufferung der Langzeitdaten der mindestens letzten 4x24 Stunden vorzusehen Geschwindigkeitsklassen Eine Übertragung von nach Geschwindigkeitsklassen aufgeschlüsselten Verkehrsdaten ist nicht vorgesehen. Alle Telegramme der Typen 37 und 38 werden mit Code 2 unbekannter oder nicht auswertbarer Typ negativ quittiert. Druckdatum: Seite 16 von 28 Dokumentname: PLaPB Technische Anforderungen an die TLS Schnittstelle TKo - UZ

17 3.4.7 Streckenbezogenen Verkehrsdaten Eine Übertragung von streckenbezogenen Verkehrsdaten erfolgt nicht. Alle erhaltenen Telegramme der Typen 34, 96 und 97 werden mit Code 2 unbekannter oder nicht auswertbarer Typ negativ quittiert LVE-Betriebsparameter Aufgrund der Tatsache, dass sowohl die Versionen der zu übertragenden Verkehrsdaten als auch die zu verwendenden Aggregationsintervalle projektspezifisch festgelegt sind, ist eine davon abweichende Zuweisung über die LVE-Betriebsparametern durch die Zentralentechnik nicht zulässig. Solche Zuweisungen sind mit den Fehlercodes 3,4,5 oder 6 negativ zu quittieren, maßgebend ist die Reihenfolge der entsprechenden Bytes im Telegramm. Abweichungen bei den Glättungsparametern und dem Startwert für die geglättete mittlere Geschwindigkeit werden mit Code 0 sonstige Fehlerursache quittiert. Die Behandlung des Bytes Längengrenzwert erfolgt grundsätzlich so wie für Datenendgeräte ohne Längenauswertung Abläufe Für die projektspezifischen Festlegungen bzgl. der zu übertragenden Datenversionen werden folgende Abkürzungen festgelegt: V Version der Kurzzeitdaten L Version der Langzeitdaten KV Typ des Kurzzeitdatentelegramms LV Typ des Langzeitdatentelegramms Tabelle 2: Abläufe der FG 1 Name Bem. Abruf pos. Antwort neg. Antwort =DE-Fehlermeldung ?DE-Fehlermeldung =ergänzende DE-Fehlermeldung ?Ergänzende DE-Fehlermeldung ?Puffer LV !Kanalsteuerung ?Kanalsteuerung !LVE-Betriebsparameter ?LVE-Betriebsparameter Druckdatum: Seite 17 von 28 Dokumentname: PLaPB Technische Anforderungen an die TLS Schnittstelle TKo - UZ

18 !EFZ-Betriebsparameter ?EFZ-Betriebsparameter !Geographische Kenndaten ?Geographische Kenndaten ?Intervalldaten für Kurzzeitdaten 8 Bit KV =LVE-Ergsmldg. Version v 8 Bit KV?LVE-Ergsmldg. Version v 8 Bit 1 20 KV KV =Sammelmeldung Kfz- Einzeldaten =Kfz-Einzeldaten ?Intervalldaten für Langzeitdaten LV ?LVE-Ergsmldg. Version l 1 20 LV LV Funktionsgruppe 2 Achslastdaten Im Kontext von Tunnelsteuerungen nicht relevant. Alle Telegramme, welche von der TLS-Schnittstelle in der FG 2 empfangen werden, sollen daher vom adressierten Knoten mit der DE-Nummer 0 in der FG 254 mit dem Fehlercode 64 nicht vorhandene Funktionsgruppe negativ quittiert werden. 3.6 Funktionsgruppe 3 Umfelddaten Eine Übertragung von Umfelddaten aus der Tunnelsteuerung ist in der Regel nicht vorgesehen. Dies betrifft auch die Werte von Helligkeitserfassungen. 3.7 Funktionsgruppe 4 Wechselverkehrszeichensteuerung Funktionsgruppenspezifische Fehlermeldungen Da eine Beeinflussung der Wechselverkehrszeichen durch die Zentralentechnik nicht vorgesehen ist und auch ansonsten kein Störungsmanagement durch die Zentralentechnik stattfindet, kann die Implementierung der Fehlermeldungen Typ 2, 3, 4, 5 und 6 entfallen. Entsprechend sollen alle Abrufe dieser Meldungstypen mit Code 2 unbekannter oder nicht auswertbarer Typ negativ quittiert werden. Ebenso entfällt die Meldungsverpflichtung zu diesen Typen im Anlaufverhalten. 3 Nur zu Prüfzwecken, Schnittstelle am EAK analog Lokalbus Druckdatum: Seite 18 von 28 Dokumentname: PLaPB Technische Anforderungen an die TLS Schnittstelle TKo - UZ

19 3.7.2 Betriebsart Da eine Beeinflussung der Wechselverkehrszeichen durch die Zentralentechnik nicht vorgesehen ist, melden alle AQs (über ihre Clusterkanäle) als Betriebsart immer und ausschließlich den Handbetrieb (Codierung 3). Damit wird der Zentralentechnik signalisiert, dass eine Beeinflussung nicht möglich ist. Alle erforderlichen Abläufe und Reaktionen sind bereits in der TLS definiert und genauso zu implementieren Helligkeitssteuerung Da eine Beeinflussung der Wechselverkehrszeichen durch die Zentralentechnik nicht vorgesehen ist, melden alle AQs (über ihre Clusterkanäle) immer die automatische, lokale Helligkeitssteuerung. Das Meldeverhalten ist immer wie keine spontanen Meldungen des aktuellen Helligkeitswertes zu implementieren. Dies entspricht einer Codierung von 1 im Helligkeitsstatusbyte des Telegramms Typ 49. Alle an der Schnittstelle empfangenen Telegramme Typ 49, welche ein abweichendes Steuer- oder Meldeverhalten beinhalten, werden mit Code 9 Betriebsart unbekannt bzw. nicht einstellbar negativ quittiert Anzeigeprinzipien Alle leuchtenden Betriebsmittel sind entsprechend Anzeigeprinzip b zu implementieren, nicht leuchtende entsprechend Anzeigeprinzip a. Insbesondere werden auch Textzeilen in aller Regel als Anzeigeprinzip b modelliert. Lediglich in dem Fall, dass auch die Verkehrssteuerung des Tunnels die Vorgabe von frei definierten Texten erlaubt, sind diese Textzeilen als AP d zu implementieren, um ggf. den frei definierten Anzeigeinhalt übertragen zu können Steuerungsprinzipien Alle Wechselverkehrszeichen sind gemäß Steuerungsprinzip 2 Programmmodus zu implementieren. Lediglich tatsächlich im Betrieb frei definierbare Textzeilen sind gemäß Steuerungsprinzip 3 umschaltbar zu implementieren Grundeinstellung Das Prinzip des TLS-konformen Autarkbetriebs ist in der Regel nicht auf die Steuerungstechnik eines Tunnels übertragbar. Das Telegramm Typ 33 muss daher nicht implementiert werden. Alle empfangenen Telegramme vom Typ 33 können mit Code 2 unbekannter oder nicht auswertbarer Typ negativ quittiert werden Codedefinition Für DEs nach Anzeigeprinzip a und b ist die Implementierung von Codedefinitionen nicht sinnvoll resp. nicht erforderlich. Auch für frei definierbare Textzeilen nach Anzeigeprinzip d kann die Implementierung des Telegramms Typ 44 Codedefinition entfallen. Druckdatum: Seite 19 von 28 Dokumentname: PLaPB Technische Anforderungen an die TLS Schnittstelle TKo - UZ

20 Alle empfangenen Telegramme vom Typ 44 können mit Code 2 unbekannter oder nicht auswertbarer Typ negativ quittiert werden Codeliste Der Abruf und die entsprechende Beantwortung von Codelisten muss für alle WZG implementiert werden Stellzustände Die Stellzustände aller Wechselzeichengeber müssen bei jeder Änderung immer spontan mit Typ 55 gemeldet werden. Ebenso müssen Abrufe der Stellzustände immer korrekt beantwortet werden. Stellbefehle von der Zentralentechnik werden aufgrund der Festlegung, dass sich alle AQs ständig im Handbetrieb befinden, immer TLS-konform mit Code 10 Befehl bzw. Programm in dieser Betriebsart nicht ausführbar negativ quittiert Nachrichtenpufferung Die virtuellen EAKs der FG 4 müssen die Nachrichtenpufferung vollständig implementieren. Entsprechend sind Abrufe des Pufferinhalts durch die Zentralentechnik TLS-konform zu beantworten. Der Nachrichtenpuffer muss mindestens jeweils mindestens die letzten 50 Nachrichten (Einzeltelegramme) verwalten Abläufe Tabelle 3: Abläufe der FG 4 Name Bem. Abruf pos. Antwort neg. Antwort =DE-Fehlermeldung ?DE-Fehlermeldung =Ergänzende DE-Fehlermeldung ?Ergänzende DE-Fehlermeldung =Betriebsart !Betriebsart ?Betriebsart ?Abruf Pufferinhalt Druckdatum: Seite 20 von 28 Dokumentname: PLaPB Technische Anforderungen an die TLS Schnittstelle TKo - UZ

21 !Kanalsteuerung ?Kanalsteuerung !Geographische Kenndaten ?Geographische Kenndaten =Codeliste ?Codeliste =Helligkeit !Helligkeit ?Helligkeit =Stellzustand !Stellzustand ?Stellzustand Programmsteuerung durch die Zentralentechnik Wenn die TLS-Schnittstelle in der aktiven Variante implementiert wird, so dass eine Steuerung des Tunnels durch Programmnummernvorgabe durch die Zentralentechnik realisiert wird, dann ist dazu ein zusätzliches virtuelles SM mit je einem FG4-EAK pro Richtungsfahrbahn zu konfigurieren. Diese EAKs haben jeweils (neben dem Clusterkanal) nur einen DE-Kanal. Für diesen DE-Kanal ist die Verwendung des Telegrammtyps Typ 55 Stellbefehl auch in Abrufrichtung (ID 5) erforderlich. Im Gegensatz zu obiger Festlegung melden die Clusterkanäle dieser EAKs in der Regel die Betriebsart Normalbetrieb und signalisieren so der Zentralentechnik, dass eine Vorgabe von Schaltanforderungen möglich ist. Lediglich wenn die Tunnelsteuerung aus welchem Grund auch immer keine Schaltanforderungen der Zentralentechnik entgegennehmen und umsetzen kann, signalisiert sie dies durch Meldung der Betriebsart Handbetrieb. Die Zentralentechnik überträgt im Normalbetrieb bei Schaltwünschen an diese DE- Kanäle die Programmnummer des gewünschten, in der Verkehrsmatrix definierten Verkehrsprogramms. Sobald das Verkehrsprogramm von der Tunnelsteuerung umgesetzt wurde, wird dies in Form der Stellzustandsrückmeldung (mit der Jobnummer der Anforderung) bestätigt. Wurde die Anforderung nicht vollständig umgesetzt, so ist dies im Funktionsbyte durch Setzen von Bit 2 signalisiert. Druckdatum: Seite 21 von 28 Dokumentname: PLaPB Technische Anforderungen an die TLS Schnittstelle TKo - UZ

22 Neben der Rückmeldung des Stellzustands für das entsprechende Richtungs-DE melden alle DEs, welche die tatsächlichen Endgeräte darstellen, ihren entsprechenden Stellzustandswechsel als spontane Stellzustandsmeldung. Eine Veränderung der Betriebsart durch die Zentralentechnik ist nicht zulässig und wird entsprechend mit Code 9 Betriebsart unbekannt bzw. nicht einstellbar negativ quittiert. Die Clusterkanäle implementieren entsprechend der Festlegung, dass die Richtungs- DEs gemäß Anzeigeprinzip a gehandhabt werden, den Typ 49 Helligkeitssteuerung nicht. 3.8 Funktionsgruppe 6 Betriebsmeldungen Da eine Betriebsüberwachung seitens der Zentralentechnik nicht vorgesehen ist, müssen die in der TLS definierten Meldungstypen der FG 6 nicht vollständig implementiert werden. Es sind jedoch durch die ASFINAG speziell für die Integration von Tunneldaten in die Zentralentechnik einige zusätzliche Meldungstypen definiert worden, welche jeweils spontan gemeldet werden müssen. Ein Abruf dieser Daten muss TLS-konform möglich sein Abläufe Tabelle 4: Abläufe der FG 6 Name Bem. Abruf pos. Antwort neg. Antwort =DE-Fehlermeldung ?DE-Fehlermeldung =Ergänzende DE- Fehlermeldung?Ergänzende DE- Fehlermeldung Kanalsteuerung ?Kanalsteuerung !Betriebsparameter ?Betriebsparameter !Geographische Kenndaten?Geographische Kenndaten =Höhenkontrolle ?Höhenkontrolle Druckdatum: Seite 22 von 28 Dokumentname: PLaPB Technische Anforderungen an die TLS Schnittstelle TKo - UZ

23 =Brandmeldung ? Brandmeldung =CO-Wert Überschreitung?CO-Wert Überschreitung =Sichttrübung ?Sichttrübung =Notfall ?Notfall =zu viele Fahrzeuge ?zu viele Fahrzeuge =Richtungsbetriebsart ?Richtungsbetriebsart Tunnelspezifische Meldungstypen Folgende Meldungstypen müssen implementiert werden: Typ Bezeichnung 132 Höhenkontrolle 133 Brandmeldung 134 CO-Wert Überschreitung 135 Sichttrübung 136 Notfall 137 zu viele Fahrzeuge 138 Richtungsbetriebsart Druckdatum: Seite 23 von 28 Dokumentname: PLaPB Technische Anforderungen an die TLS Schnittstelle TKo - UZ

24 DE-Block-Struktur im Typ 132 Höhenkontrolle Ergänzende Beschreibung: Die Meldung ist entweder pro Erfassungseinheit oder als Summenmeldung mindestens je Tunnelröhre zu übertragen. Die Festlegung erfolgt projektspezifisch. Telegrammdefinition: Position Bezeichnung Erläuterung Byte 1 Länge DE-Block Länge des folgenden DE-Blocks [ 5 ] Byte 2 Daten-Endgeräte-Kanal [ ] Byte 3 Typ der DE-Daten [ 132 ] Byte 4 Herstellercode siehe TLS2002, Anhang 7, Kapitel 2 Byte 5 Anzahl der Ereignismeldungen [ 2 ] Byte 6 Ereignismeldung Ereignismeldung siehe unten Inhalt Ereignismeldung: Bit Zustand 0 Zustand 1 0 Keine Warnung Warnung 1 Kein Alarm Alarm 2-7 reserviert reserviert DE-Block-Struktur im Typ 133 Brandmeldung Ergänzende Beschreibung: Die Meldung ist entweder pro Erfassungseinheit oder als Summenmeldung mindestens je Tunnelröhre zu übertragen. Die Festlegung erfolgt projektspezifisch. Vom AN sind die jeweiligen Alarme, die als Summenmeldungen resultieren anzugeben. Telegrammdefinition: Position Bezeichnung Erläuterung Byte 1 Länge DE-Block Länge des folgenden DE-Blocks [ 5 ] Byte 2 Daten-Endgeräte-Kanal [ ] Byte 3 Typ der DE-Daten [ 133 ] Byte 4 Herstellercode siehe TLS2002, Anhang 7, Kapitel 2 Byte 5 Anzahl der Ereignismeldungen [ 2 ] Byte 6 Ereignismeldung Ereignismeldung siehe unten Inhalt Ereignismeldung: Bit Zustand 0 Zustand 1 0 Keine Warnung Warnung 1 Kein Alarm Alarm 2-7 reserviert reserviert Druckdatum: Seite 24 von 28 Dokumentname: PLaPB Technische Anforderungen an die TLS Schnittstelle TKo - UZ

25 DE-Block-Struktur im Typ 134 CO-Wert Überschreitung Ergänzende Beschreibung: Die Meldung ist entweder pro Erfassungseinheit oder als Summenmeldung mindestens je Tunnelröhre zu übertragen. Die Festlegung erfolgt projektspezifisch. Die Schwellwerte sind vom AN anzugeben. Telegrammdefinition: Position Bezeichnung Erläuterung Byte 1 Länge DE-Block Länge des folgenden DE-Blocks [ 5 ] Byte 2 Daten-Endgeräte-Kanal [ ] Byte 3 Typ der DE-Daten [ 134 ] Byte 4 Herstellercode siehe TLS2002, Anhang 7, Kapitel 2 Byte 5 Anzahl der Ereignismeldungen [ 2 ] Byte 6 Ereignismeldung Ereignismeldung siehe unten Inhalt Ereignismeldung: Bit Zustand 0 Zustand 1 0 Keine Warnung Warnung 1 Kein Alarm Alarm 2-7 reserviert reserviert DE-Block-Struktur im Typ 135 Sichttrübung Ergänzende Beschreibung: Die Meldung ist entweder pro Erfassungseinheit oder als Summenmeldung mindestens je Tunnelröhre zu übertragen. Die Festlegung erfolgt projektspezifisch. Die Schwellwerte sind vom AN anzugeben. Telegrammdefinition: Position Bezeichnung Erläuterung Byte 1 Länge DE-Block Länge des folgenden DE-Blocks [ 5 ] Byte 2 Daten-Endgeräte-Kanal [ ] Byte 3 Typ der DE-Daten [ 135 ] Byte 4 Herstellercode siehe TLS2002, Anhang 7, Kapitel 2 Byte 5 Anzahl der Ereignismeldungen [ 2 ] Byte 6 Ereignismeldung Ereignismeldung siehe unten Inhalt Ereignismeldung: Bit Zustand 0 Zustand 1 0 Keine Warnung Warnung 1 Kein Alarm Alarm 2-7 reserviert reserviert Druckdatum: Seite 25 von 28 Dokumentname: PLaPB Technische Anforderungen an die TLS Schnittstelle TKo - UZ

26 DE-Block-Struktur im Typ 136 Notfall Ergänzende Beschreibung: Die Meldung ist entweder pro Erfassungseinheit oder als Summenmeldung mindestens je Tunnelröhre zu übertragen. Die Festlegung erfolgt projektspezifisch. Vom AN sind die jeweiligen Alarme, die als Summenmeldung resultieren anzugeben. Telegrammdefinition: Position Bezeichnung Erläuterung Byte 1 Länge DE-Block Länge des folgenden DE-Blocks [ 5 ] Byte 2 Daten-Endgeräte-Kanal [ ] Byte 3 Typ der DE-Daten [ 136 ] Byte 4 Herstellercode siehe TLS2002, Anhang 7, Kapitel 2 Byte 5 Anzahl der Ereignismeldungen [ 2 ] Byte 6 Ereignismeldung Ereignismeldung siehe unten Inhalt Ereignismeldung: Bit Zustand 0 Zustand 1 0 Keine Warnung Warnung 1 Kein Alarm Alarm 2-7 reserviert reserviert DE-Block-Struktur im Typ 137 zu viele Fahrzeuge Ergänzende Beschreibung: Die Meldung ist entweder pro Erfassungseinheit oder als Summenmeldung mindestens je Tunnelröhre zu übertragen. Die Festlegung erfolgt projektspezifisch. Der Schwellwert (Füllstand in Prozent) ist vom AN anzugeben. Telegrammdefinition: Position Bezeichnung Erläuterung Byte 1 Länge DE-Block Länge des folgenden DE-Blocks [ 5 ] Byte 2 Daten-Endgeräte-Kanal [ ] Byte 3 Typ der DE-Daten [ 137 ] Byte 4 Herstellercode siehe TLS2002, Anhang 7, Kapitel 2 Byte 5 Anzahl der Ereignismeldungen [ 2 ] Byte 6 Ereignismeldung Ereignismeldung siehe unten Inhalt Ereignismeldung: Bit Zustand 0 Zustand 1 0 Keine Warnung Warnung 1 Kein Alarm Alarm 2-7 reserviert reserviert Druckdatum: Seite 26 von 28 Dokumentname: PLaPB Technische Anforderungen an die TLS Schnittstelle TKo - UZ

27 DE-Block-Struktur im Typ 138 Richtungsbetriebsart Ergänzende Beschreibung: Im Gegenbetrieb sind Bit 0 und Bit 1 gesetzt. Die Richtungsart (Verkehrsführung) ist für jede Tunnelröhre als Meldung zu übertragen. Telegrammdefinition: Position Bezeichnung Erläuterung Byte 1 Länge DE-Block Länge des folgenden DE-Blocks [ 5 ] Byte 2 Daten-Endgeräte-Kanal [ ] Byte 3 Typ der DE-Daten [ 138 ] Byte 4 Herstellercode siehe TLS2002, Anhang 7, Kapitel 2 Byte 5 Anzahl der Ereignismeldungen [ 2 ] Byte 6 Ereignismeldung Ereignismeldung siehe unten Inhalt Ereignismeldung: Bit Zustand 0 Zustand 1 0 Sonst FR in Stationierungsrichtung 1 Sonst FR gegen Stationierungsrichtung 2-7 reserviert reserviert 3.9 Funktionsgruppe 7 steuerung Die Funktionsgruppe 7 nach TLS ist von Ihrer Aufgabenstellung her funktional für diverse Steuerungserfordernisse von betriebstechnischen Ausstattungen geeignet, wie sie auch in Tunnelsteuerungen typischerweise verwendet werden (z.b. Schranken, Leiteinrichtungen, Pumpstationen, Lüfter, Beleuchtungsanlagen usw.). Sie kommt aber im Kontext der Tunnelsteuerungen im Bereich der ASFINAG bisher nicht zum Einsatz, insbesondere, da die gesamte Tunnelausrüstung in der Regel nicht TLS-konform realisiert wird. Alle Telegramme, welche von der TLS-Schnittstelle in der FG 7 empfangen werden, sollen daher vom adressierten Knoten mit der DE-Nummer 0 in der FG 254 mit dem Fehlercode 64 nicht vorhandene Funktionsgruppe negativ quittiert werden Funktionsgruppe 8 Geschwindigkeitsüberwachung Geschwindigkeitsüberwachungsanlagen werden im Zuständigkeitsbereich der ASFINAG gemäß PLaNT oder als Section Control realisiert. Zur Anbindung an die Verkehrssteuerung zur Übernahme der aktuell gültigen Geschwindigkeitsregime können im Kontext Tunnelsteuerung nicht gemäß PLaNT gelöst werden, da eine entsprechende Gegenstelle in Form eines FG4-EAKs aufgrund nicht TLSkonformer Ausstattung generell nicht vorhanden ist. Druckdatum: Seite 27 von 28 Dokumentname: PLaPB Technische Anforderungen an die TLS Schnittstelle TKo - UZ

28 Alle Telegramme, welche von der TLS-Schnittstelle in der FG 8 empfangen werden, sollen daher vom adressierten Knoten mit der DE-Nummer 0 in der FG 254 mit dem Fehlercode 64 nicht vorhandene Funktionsgruppe negativ quittiert werden Funktionsgruppe 9 Zuflussregelung Zuflussregelungen auf Basis des ALINEA-Algorithmus kommen derzeit im Zuständigkeitsbereich der ASFINAG in Tunnelanlagen nicht zum Einsatz. Eine Anwendbarkeit der FG 9 ist daher nicht gegeben. Alle Telegramme, welche von der TLS-Schnittstelle in der FG 9 empfangen werden, sollen daher vom adressierten Knoten mit der DE-Nummer 0 in der FG 254 mit dem Fehlercode 64 nicht vorhandene Funktionsgruppe negativ quittiert werden. Druckdatum: Seite 28 von 28 Dokumentname: PLaPB Technische Anforderungen an die TLS Schnittstelle TKo - UZ