Schnittstelle für Anzeigesysteme mit Vorortbedienung

Transkript

1 Schnittstelle für Anzeigesysteme mit Vorortbedienung Seite 1 von 33 Seite(n)

2 1 EINLEITUNG BEZUGSDOKUMENTE ZIEL DER STANDARDISIERUNG MOTIVATION DER AUFTRAGGEBER EINORDNUNG / ABGRENZUNG BEGRIFFSDEFINITIONEN GRUNDBEGRIFFE / BEZÜGE (REFERENZEN) ZU ANDEREN STANDARDS HEUTIGE SYSTEMUMGEBUNG VON ANZEIGESYSTEMEN ALLGEMEINE SYSTEMARCHITEKTUR AM BEISPIEL EINES PARKLEITSYSTEMS AKTOREN (ANZEIGETECHNIK) SENSOREN (DATENERFASSUNGEN) OPERATIVER BETRIEB KOMMUNIKATION MIT FREMDSYSTEMEN ZUKÜNFTIGE SYSTEMUMGEBUNG VON ANZEIGESYSTEMEN ALLGEMEINE SYSTEMARCHITEKTUR AKTOREN (ANZEIGETECHNIKEN) SENSOREN (DATENERFASSUNGEN) FELDGERÄT Aufgaben des Feldgerätes KOMMUNIKATION MIT FREMDSYSTEMEN STANDARDISIERUNGSKONZEPT FÜR ANZEIGESYSTEME KATEGORISIERUNG DER ANZEIGETECHNIKEN Attribute Element <PROGRAMM> Element <PICTURE> Kategorie Schaltungen 1..n Zustände Element <PRISM> Kategorie Alphanumerisch frei programmierbar Element <MULTILINE> Element <POSITION> Element <TEXT> Element <FUNCTION> Element <SYMBOL> Element <IMAGE> Element <FUNCTION> Element <SYMBOL> SYSTEMADRESSIERUNG MELDUNGEN Meldungsunterscheidung Hauptmeldungen Nebenmeldungen Prinzip der Meldungsstruktur DATEN- UND KOMMUNIKATIONSSTRUKTUREN Anforderungen an die Daten- und Kommunikationsstrukturen Mögliche Daten- und Kommunikationsstrukturen Bevorzugte Daten- und Kommunikationsstrukturen LEBENSZEICHEN ZUR ÜBERWACHUNG DER VERFÜGBARKEIT VON SCHILDERN UND SERVERN Überwachung der Schilder vom Server Überwachung der Serververfügbarkeit und Durchgängigkeit der Datenverbindung BEISPIELE ANSTEUERUNG EINES PRISMENWENDERS ANSTEUERUNG EINER RESTPLATZANZEIGE (LCD) ANSTEUERUNG EINER VARIOTAFEL Seite 2 von 33 Seite(n)

3 5.3.1 Definition eines Schilderinhaltes, der aus ASCII Text und Grafiken besteht Seite 3 von 33 Seite(n)

4 Abbildungen Abbildung 1: Versionskonflikte innerhalb des Systems...7 Abbildung 2: Heutige Systemarchitektur...11 Abbildung 3: Zukünftige Systemarchitektur...13 Abbildung 4: Einsatzbereiche der Feldgeräte...14 Abbildung 5: Physikalische Kommunikationsmöglichkeiten...22 Abbildung 6: Auflösung unterschiedlicher Datenpakete durch das Feldgerät...23 Abbildung 7: Adressierung eines Standortes...24 Abbildung 8: Meldungsübertragung...25 Abbildung 9:Haupt- und Nebenmeldung...27 Tabellen Tabelle 1: Begriffsdefinitionen...9 Tabelle 2: Kategorisierung der Anzeigetechnik...16 Tabelle 3: Quittierungsmeldungen...26 Tabelle 4: Mögliche Daten- und Kommunikationsstrukturen...29 Seite 4 von 33 Seite(n)

5 Änderungshistorie: Version Datum Änderung Autor Datei Aufteilung der alten Dokumente in Budde zwei separate und neue Formatierung Überarbeitung des Dokument Przetak Formatierungen ohne inhaltliche Änderungen und Freigabe Ergänzung Abbildung 3 zur besseren Verdeutlichung bei Schwarz-Weiß-Druck Budde Heine Seite 5 von 33 Seite(n)

6 1 Einleitung 1.1 Bezugsdokumente "SS-Anzeigesysteme_mit_Vorortbedienung_Protokoll_ doc Stand Ziel der Standardisierung Derzeit existieren am Markt verschiedene Hersteller für Anzeigesysteme. Diese sind in der Regel durch herstellerabhängige (proprietäre) Schnittstellen und Systemlösungen nicht kompatibel zueinander, welches eine Vermischung unterschiedlicher Hersteller innerhalb einer Anzeigesystem- Landschaft nicht ermöglicht. Insbesondere für Migrationen und Erweiterungen von existierenden Anlagen ist daher seitens des Auftraggebers nur eine eingeschränkte Auswahl von Herstellern möglich. Werden Neuanlagen ausgeschrieben, stellt sich eine ähnliche Abhängigkeit ein. Der Auftraggeber ist i.d.r. an einen Hersteller gebunden, der eine vollständige Lösung anbieten kann, auch hier besteht nur eingeschränkt die Möglichkeit Anlagenteile von verschiedenen Herstellern einzusetzen. In Zukunft wird es möglich sein, dass eine offene Schnittstelle Transparenz zwischen den wesentlichen Anlagenteilen schafft. Diese Transparenz ermöglicht dem Auftraggeber Anlagenteile von unterschiedlichen Herstellern einzusetzen unabhängig davon ob es sich um eine Migration, Erweiterung oder eine Neubeschaffung handelt. Im Fokus dieses Standards stehen somit nicht nur Neuanlagen, sondern auch bereits existierende Systeme, die in absehbarer Zeit innoviert werden. Ziel der Standardisierung ist es somit, einen Großteil der vorhandenen Infrastruktur zu erhalten, aber dennoch eine Transparenz zu schaffen, die dem Auftraggeber größtmögliche Flexibilität in der Auswahl der Herstellerfirmen bietet. Alle Bestandteile von Verkehrserfassungssystemen werden hier nicht behandelt, da diese bereits in anderen Standards definiert sind. 1.3 Motivation der Auftraggeber Die Gestaltung der Standardisierung muss sich an die Kundenanforderungen halten um sicherstellen zu können, dass erforderliche Entwicklungsleistungen entsprechend der Marktanforderungen umgesetzt werden. In diesem Kapitel werden die wesentlichen Kundenanforderungen beschrieben. Ziel des gesamten Standardisierungsprozesses ist es, stets diese Anforderungen an den technisch diskutierten Lösungsansätzen wiederzuspiegeln. Die Motivation der Auftraggeber lässt sich in zwei Gruppen einteilen, zum einen die monetäre Motivation mit dem Ziel dem Auftraggeber Kosten bei neuen Bauvorhaben zu ersparen und zum anderen die technische Motivation mit dem Ziel zukunftssichere Technologien so einzusetzen, dass der Auftraggeber einen höheren Komfort bzw. Flexibilität bei der Steuerung und Systempflege erhält. Innerhalb der monetären Motivation sind folgende Punkte als maßgebliche Forderungen anzusehen: - Herstellerunabhängigkeit bei Erweiterungen des Systems, damit erhöhter Preiskampf - Mischbetrieb zwischen Zentralenhersteller und Schilderhersteller, damit Möglichkeit der losweisen Ausschreibung von Neuanlagen, getrennt nach Zentrale und Außenanlage - Austausch der Zentralentechnik ohne Auswirkungen auf die Außenanlage dadurch kostengünstige Migration - Nutzung der Kommunikationswege zur Lichtsignalanlage (LSA) damit entfallen u. U. längere Kabelwege und damit teure Tiefbauarbeiten Die technische Motivation umfasst folgende Forderungen: Seite 6 von 33 Seite(n)

7 - Die Ansteuerung verschiedener Anzeigetechnologien soll ermöglicht werden - Alle technischen Leistungsmerkmale der Schilder sollen durch die Zentrale unterstützt - Anbindung über alle technisch realisierbaren Kommunikationsmedien - Anbindung über Infrastruktur des Verkehrsrechners 1.4 Einordnung / Abgrenzung Im Rahmen dieses Dokumentes wird eine standardisierte, logische und physikalische Anbindung von Anzeigesystemen verschiedener Hersteller definiert. Um innerhalb des Systems kompatibel zu bleiben, dürfen nur Feldgeräte angeschlossen werden die einen kleineren oder gleichen Versionsstand der Standardschnittstelle auf der Zentralenseite unterstützen. Beispiel: Höhere Versionen der Schnittstelle unterstützen einen erweiterten Befehlssatz. Dieser erweiterte Befehlssatz ist mit einer alten Version innerhalb der Zentrale nicht verwendbar um dies auszuschließen muss die Zentrale auf den neuen Befehlssatz aufgerüstet werden. Zentrale Version 1 Feldgerät Version 1 Version 2 Anzeige Version 1 Version 2 Anzeige benötigt Befehle aus Version 2 um Inhalte korrekt darzustellen Abbildung 1: Versionskonflikte innerhalb des Systems Nicht behandelt werden: - Problematiken, die sich aufgrund von unterschiedlichen Anzeigetypen ergeben - Ankopplung und Integration von Parkdatenerfassungseinheiten - Strategie zur Migration bestehender Anlagen - Kommunikation zu übergeordneten Systemen (Instations-Kommunikation) Im Folgenden ist die Problematik beschrieben, die sich bei der Verwendung von unterschiedlichen Anzeigetypen ergeben kann: Annahme: Ein System verfügt über eine Variotafel mit (Höhe x Breite) 100 x 250 Pixel, geliefert von Hersteller. Außenmaße Gehäuse: 2,00m x 3,00m. Für eine Erweiterung werden Variotafeln mit gleichem Gehäusemaß ausgeschrieben, Hersteller B erhält den Auftrag. Die logische und physikalische Anbindung ist über die Standardisierung definiert. Jedoch benötigt Hersteller B, um die Forderungen der Norm (pren 12966) zu erfüllen, die doppelte Anzahl von Pixel je Flächeneinheit. Zu dem kommt der Hersteller B bauartbedingt (Platinengröße) auf eine Pixelanzahl von 231 x 434. Generelles Problem: Piktogramme, die für die vorhandenen Variotafeln entwickelt wurden, können nicht 1:1 vom Hersteller B übernommen werden. Zu dem kann der verwendete Seite 7 von 33 Seite(n)

8 Bildeditor für den neuen Schildertyp nicht verwendet werden. Im Bereich der Zentrale (die jedoch nicht Auftragsgegenstand des Herstellers B ist) sind Anpassungen erforderlich. Generelle Empfehlung: Alle Schilder im System sollten die gleiche Anzahl von Pixel enthalten. Ist dies nicht möglich muss die Anzahl der Schilder mit unterschiedlichen Pixelanzahlen gering gehalten werden. Um die Wirtschaftlichkeit feststellen zu können müssen die Aufwendungen in der Zentrale immer berücksichtigt werden. 1.5 Begriffsdefinitionen Begriff Erläuterung Aktor Aktorsteuerung Befehl Befehlssatz- Information Gerät, das auf Grund von Befehlen des Datenendgerätes (DE) verschiedene Schaltzustände annehmen kann. Proprietär, steuert ein oder mehrere DE, mehrere Aktorsteuerungen je Standort sind möglich. Eine Anweisung von der Zentrale an das Feldgerät um eine bestimmte Funktion auszulösen. Liste aller für eine DE möglichen Befehle und deren Constraints (z.b. Helligkeit von 0 bis 100 %, in Stufen von 10%) alle Steuerbefehle und Anteile der Versorgungsbefehle (derzeit erkennbar: Definition von Bildinhalten und Szenarien). Betriebsmeldung DE DE-Adresse Feldgerät Informationen Kommunikation Kommunikationsausfall Kommunikationsstörung Konfiguration Konfigurationsbefehlssatz Konfigurations- Informationen Kritischer Fehler Status-Information Meldung, die aktiv vom Schild (DE) generiert wird und ein reguläres Betriebsereignis meldet. Datenendgeräte sind Aktoren (evt. mit Sensoren) mit herstellerspezifischen Eigenschaften und Schnittstellen zur Ansteuerung. Logische Bezeichnung des DE. Diese Adresse stellt eine Konstante im System dar und ist eindeutig definiert sie setzt sich aus Standortbezeichnung und DE-Nummer zusammen. Gateway zwischen standardisiertem und proprietärem Protokoll. Inhalt von Befehlen und Meldungen. Übertragung und Bestätigung des Erhalts eines Datentelegramms. Übertragung ohne Rückmeldung oder Bestätigung. Übertragung und Rückmeldung des Erhalts eines fehlerhaften Datentelegramms. Konfiguration wie Displaygröße, DE-Typ... Diese können mittels herstellerspezifischen Konfigurationsbefehlen über die vorhandene Kommunikationsstruktur übermittelt werden. Betriebsoftware (Firmware) ist ein Teil der Konfiguration. Dieser ist proprietär und wird nicht von FG an die Zentrale übergeben werden (z.b. Kommunikation zwischen FG und DE, Matrixgröße, Farbtiefe...) Meldung, die vom Schild (DE) auf Anfrage geliefert wird. Statische Informationen über die Konfiguration wie Displaygröße, DE-Typ... Ein Fehler der die Funktion unmittelbar gefährdet (z.b. Ausfall von Haupt- und Nebenlampe). Notzustand Zustand eines DE bei einer andauernden Störung oder bei Kommunikationsausfall, nur ein Notzustand je DE und Störungskategorie zulässig. Massendaten Meldungen Sensor Standort Daten mit Übertragungsraten von >= 20ms [Bemerkung: Fallen i.d.r. bei Schildersteuerungen nicht an] Eventgetriggerte Meldung vom Feldgerät zur Zentrale. Gerät, das Umgebungsbedingungen und Schaltzustände der Aktoren erkennt und meldet. Diskreter Ort, an dem sich eine bestimmte Anzahl von Datenendgeräten (DE) unterschiedlichen Typs befinden. Meldung, die aktiv vom Schild (DE) oder auf Anfrage geliefert wird. Komplette Seite 8 von 33 Seite(n)

9 Steuerbefehle/Schalt befehle Störmeldung Subsystem Informationen über den aktuellen Zustand des Schildes, insbesondere Zustände die über Befehle geändert werden können (dynamische Informationen wie blinkend, Helligkeit=80%), aber auch (Sammel-) Störzustand. Versorgungsinformationen sind in der Status-Information nicht enthalten. Ändern DE-Status Meldung, die aktiv vom Schild (DE) generiert wird und ein nicht reguläres Betriebsereignis meldet (Lampenausfall etc.). Anwendung, die über eine standardisierte Schnittstelle zu übergeordneten Systemen verfügt (z.b. OCIT-Instations). Unkritischer Fehler Ein Fehler der die Funktion nicht unmittelbar gefährdet (z.b. Hauptlampenausfall bei intakter Nebenlampe). Versorgung Übertragung von Information (Anzeigeinhalte, Stellzustand, Ablauffolgen und Szenarien), die im FG gespeichert wird ohne den Status der DE unmittelbar zu ändern. Die Information kann zu einem späteren Zeitpunkt durch einen entsprechenden Steuer-/Schaltbefehl aufgerufen werden. Tabelle 1: Begriffsdefinitionen Seite 9 von 33 Seite(n)

10 1.6 Grundbegriffe / Bezüge (Referenzen) zu anderen Standards Nr. Titel Version Autor Dokument 1 OCIT-Outstations Anzeigensteuerung Lastenheft 1 OCIT Gruppe OCIT-O- Anzeigen_V1_LH E_ Seite 10 von 33 Seite(n)

11 2 Heutige Systemumgebung von Anzeigesystemen 2.1 Allgemeine Systemarchitektur am Beispiel eines Parkleitsystems PLC PLC Client Client PLC Zentrale Netzwerke Fremdsysteme Kommuniaktionseinheiten PLC Schild PLC Schild PLC Schild Parkdatenerfassung Parkdatenerfassung Parkdatenerfassung PLC Schild PLC Schild PLC Schild Parkdatenerfassung Parkdatenerfassung Parkdatenerfassung Linie 1...n Abbildung 2: Heutige Systemarchitektur Heutige Parkleitsysteme sind entsprechend eines hierarchischen Musters aufgebaut. Eine Kommunikationseinheit übernimmt die Kommunikation zu den Außenanlagen. Diese Kommunikation erfolgt über unterschiedlichste Medien. Die Gebräuchlichste stellt in diesem Zusammenhang das Kabelnetz dar. Alle Hersteller auf dem Markt unterstützen in diesem Zusammenhang einen Partylinebetrieb, der einen Anschluss von ca. 10 Endgeräten an einer Doppelader (Linie) zulässt. Neben dem Medium Kabel werden noch GSM, GPRS, Bündelfunk und Zeitschlitzverfahren verwendet. Derzeit werden ausschließlich herstellerspezifische Protokolle eingesetzt. Innerhalb der Zentrale erfolgt die Auswertung der Meldungen aus der Außenanlage. Entsprechende Berechnungsalgorithmen stellen die Anzahl der noch zur Verfügung stehenden freien Parkkapazitäten zur Verfügung. Diese Angaben werden zurück auf die Schilder projiziert. In besonderen Fällen werden auch ergänzende Informationen in Form von Informationstafeln (Grafik/Text) angezeigt. 2.2 Aktoren (Anzeigetechnik) Klassische Parkleitsysteme verfügen i.d.r. über so genannte Restplatzanzeigen, in LCD-, LED- und Klappankertechnik. Als Erweiterung zu den Restplatzanzeigen werden auch vermehrt so genannte Textanzeigen verwendet. Dieser Anzeigetyp stellt ASCII Zeichen dar und kann im kleinerem Umfang dazu verwendet werden zusätzliche Informationen direkt an den Verkehrsteilnehmer weiterzuleiten. In sehr modernen Anzeigesystemen kommen auch vermehrt so genannte Informationstafeln zum Einsatz, sie integrieren i.d.r. frei programmierbare Anzeigeflächen. Diese Schilder werden an verkehrstechnisch wichtigen Punkten platziert, es können neben den Restplatzanzeigen weitere einoder mehrfarbige Text oder Grafikinformationen angezeigt werden. Seite 11 von 33 Seite(n)

12 2.3 Sensoren (Datenerfassungen) Anderer Datenerfassungen sind: Helligkeitssensoren Anforderungsschleifen, Temperatursensoren, Funkuhren 2.4 Operativer Betrieb Benutzerklassen definieren: Gast Operator Administrator Superuser Klassische Parkleitsysteme verfügen i.d.r. über so genannte Parkdatenerfassungseinheiten (PDE). Alle am Markt erhältlichen Zentralen für Anzeigesysteme laufen i.d.r. automatisiert, ohne dass ein Operator eingreifen muss. Trotzdem lassen sich für den manuellen Betrieb folgende Benutzerkreise / Gast Der Gast stellt einen Anwender dar, der keine Bedienrechte hat. Er ist lediglich berechtigt, den aktuellen Status des Systems anzusehen, darf diesen jedoch nicht verändern. Tätigkeiten sind beispielsweise: Abruf des aktuellen Schaltbildes; Abruf des aktuellen Systemstatus. Operator Der Operator ist der alltägliche Benutzer des Systems. Er ist berechtigt, alle für den täglichen Betrieb notwendigen Funktionen des Systems zu bedienen. Tätigkeiten sind beispielsweise: Umschalten von automatischen in manuellen Betriebsmodus und ändern des aktuellen Schaltbildes. Administrator Der Administrator ist berechtigt, das System zu konfigurieren. Tätigkeiten sind beispielsweise: Hinzufügen oder Entfernen von Aktoren oder Sensoren; Konfigurieren von Aktoren oder Sensoren. Superuser Der Superuser ist berechtigt, herstellerspezifische Aufgaben durchzuführen. Tätigkeiten sind beispielsweise: Änderung des Quellcodes der Software; Anwendung aller herstellerspezifischen Test- und Protokollierroutinen. 2.5 Kommunikation mit Fremdsystemen Die Kommunikation zu Fremdsystemen wird immer wieder praktiziert, diese sind im Wesentlichen darauf optimiert, Systemdaten mit Dritten auszutauschen. Hierfür werden proprietäre Schnittstellen eingesetzt. Seite 12 von 33 Seite(n)

13 3 Zukünftige Systemumgebung von Anzeigesystemen 3.1 Allgemeine Systemarchitektur übergeordnete OCIT- Anwendungen Instation-Netzwerk (standardisiert) Subsystem 1 Subsystem 2 2) z.b. VLS Outstation Anwendung mit Anzeigensteuerung (z.b. PLS) Feldgerät IP-Adresse DE DE Feldgerät IP-Adresse DE DE Optionale Nutzung der Netzwerk- Infrastruktur Abbildung 3: Systemarchitektur Konfigurations- und Serviceanwendung standardisiertes Protokoll (Umfang der Standardisierung) proprietäre Protokolle (nicht Umfang der Standardisierung) Konfigurations- und Serviceprotokoll Die obenaufgeführte Abbildung stellt die allgemeine Systemarchitektur dar. Zudem wird der Umfang der Standardisierung durch dieses Dokument abgegrenzt. Kommunikationen im Instationsbereich bzw. Konfigurationsmöglichkeiten durch herstellerabhängige Tools können nicht Bestandteil der Standardisierung sein. Grundsätzlich sieht die IP basierte Kommunikation auch vor, dass Konfigurations- und Serviceanwendungen unabhängig von der Standardisierung auf die Feldgeräte und ggf. auch auf die Aktorik direkt zugreifen können. Dieser Zugriff soll evt. bestehende Fernwartungszugänge zu den einzelnen Geräten weiterhin ermöglichen. 3.2 Aktoren (Anzeigetechniken) Folgende Aktoren sollen eingesetzt werden: - Poller / Schranken - Prismenwender - WVZ - Blinker - Alphanumerische Anzeigen - frei programmierbare Anzeigen (einfarbig und mehrfarbig) 3.3 Sensoren (Datenerfassungen) Folgende Sensoren sollen eingesetzt werden: anzeigenorientierte Sensorik wie z.b. Helligkeits- und Temperatursensoren, Türkontaktschalter, Phasen-, Spannungs- und Stromüberwachung. Nicht behandelt werden Sensoren, die ein eigenes DE benötigen; z.b. Verkehrsdatenerfassung, Umweltdetektion, Parkdatenerfassung etc. 3.4 Feldgerät 1)+3) 2)+3) Die Standardisierung sieht vor, dass ein Feldgerät zum Einsatz kommt. Das Feldgerät wird zwischen der Zentrale und den Schildern installiert und wird in der Lage sein, standardisierte Befehle der Zentrale entgegenzunehmen und diese in ein für die Schilder verständliches Datenformat 1 ) 2 ) 3 ) Seite 13 von 33 Seite(n)

14 umzukonvertieren. Gleichzeitig nimmt das Feldgerät Betriebs- und Störmeldungen auf und leitet diese an die Zentrale im Standard-Format weiter. Schilder, die an dem Feldgerät angeschlossen sind, arbeiten weiterhin mit einem herstellerabhängigen Format. Dies hat den Vorteil, dass: - nur geringe Anpassungen der Schilder erforderlich werden, - ein Partylinebetrieb unterstützt werden kann, der im OCIT System nicht zur Verfügung steht, - weitere Mechanismen wie GPRS, GSM, Bündelfunk etc. möglich sind, die ebenfalls in der OCIT Welt nicht existieren, aber in der PLS Technik weit verbreitet sind. Durch die Standardisierung wird eine IP basierte Kommunikation bis zum Feldgerät unterstützt. Hierdurch ist die örtliche Gebundenheit des Feldgerätes für den Aufbau eines Anzeigsystems nicht mehr entscheidend. Die physikalische Installation kann also beliebig ausfallen. Einzige Voraussetzung ist eine IP-Kopplung zu dem PLS Netzwerk. Methoden, wie z.b. Routing, können Datenpakete über verschiedene Netzwerke hinweg transportieren. Die Einsatzbereiche der Feldgeräte lassen sich in folgende Gruppen einteilen: - Installation des Feldgerätes im Feld - Installation des Feldgerätes in der PLS Zentrale - Installation des Feldgerätes an dem Feldgerät der Lichtsignalanlage - Installation von datenliefernden Systemen am Feldgerät Folgende Skizzen stellen die Einsatzbereiche kurz vor: Zentrale PLS Zentrale PLS Zentrale VSR Zentrale PLS Zentrale FG FG FG Leitungsweg FG FG FG FG LSA Zielgebiet Schild 1...n Schild 1...n Schild 1...n Schild 1...n Schild 1...n Schild 1...n FG (PLS) Schild 1...n FG im "Feld" FG in der Zentrale FG in der LSA (Routing) Abbildung 4: Einsatzbereiche der Feldgeräte Aufgaben des Feldgerätes Die Verhaltensweise des Feldgerätes im Netzwerk soll weitestgehend transparent gestaltet werden, so dass eigene Versorgungsaufwendungen nicht anfallen. Dennoch müssen gewisse Grundfunktionalitäten im Feldgerät realisiert werden. Nachfolgend sind die wichtigsten Funktionen des Feldgerätes aufgelistet: Protokollkonvertierung vom Standard-Protokoll auf ein oder mehrere herstellerabhängige Formate, für ein oder mehrere DE s Auflösung der einzelnen DE Adressen Physikalische Umsetzung der TCP IP Schnittstelle auf herstellerabhängige Topologie (DSL/Klipp Klapp Technik) Seite 14 von 33 Seite(n)

15 3.5 Kommunikation mit Fremdsystemen Die Kommunikation zu Fremdsystemen muss durch einen anderen Standard festgelegt werden (Instationsstandard). 4 Standardisierungskonzept für Anzeigesysteme 4.1 Kategorisierung der Anzeigetechniken Um eine abstrahierte Schnittstelle generieren zu können, ist es erforderlich, dass die vorhandenen Anzeigetechniken in Kategorien zusammengefasst werden. Die Kategorisierung reicht von der einfachsten Ausprägung, wie z.b. einem Poller / Schranken, bis hin zu vollgrafischen RGB Matrix- Anzeigen, deren Fläche vollfarbig frei programmierbar ist. Die nachfolgende Tabelle stellt die wichtigsten Merkmale dieser Anzeigetechniken dar. Typ Schaltungen 1 n Zustände Poller / Schranke Blinker an/aus WVZ (Prismenwender, Faseroptikanzeigen, limitierte LED-Anzeigen) Alphanumerisch Frei programmierbar Ein- oder mehrfarbige alphanumerische Anzeige die über ASCII Codes angesteuert wird. Grafisch Frei programmierbar Ein- oder mehrfarbige grafische Anzeige die über Pixel Codes angesteuert wird. Befehle Meldungen Befehlssatz- Information auslesbar 1 ) Steuerbefehle/ Schaltbefehle (direkt Anzahl der möglichen Schaltzustände; Set_Schaltzustand Get_Status_Gesamt Attribute Zustand Zustand Betriebsmeldung Heizung (Möglichkeiten der Lüftung Betriebsmeldungen Türkontakte sind abhängig vom Beleuchtungszustand herstellerspezifischen Helligkeitsregelung Protokoll zwischen FG Temperatur und Schild) Schaltzustand... Liste der darstellbaren ASCII Codes; Anzahl der Farben; Anzahl der Stufen je Farbe Anzahl der darstellbaren Schriftarten Schriftgrößen Blinkfrequenz Anzahl der lokal hinterlegten Texte Position von Texten Set_Schaltzustand Set_Inhalt Get_Status_Gesamt Set_Sequenz Ausrichtung_horizontal Ausrichtung_vertikal Farbe-Hintergrund Farbe-Schrift Schriftart Schriftgröße Position Inhalt Heizung Lüftung Türkontakte Beleuchtungszustand Helligkeitsregelung Temperatur Dargestellter alphanumerischer Inhalt in Klartextform... Liste der darstellbaren ASCII Codes Anzahl der Farben Anzahl der Stufen je Farbe Anzahl der darstellbaren Schriftarten und Schriftgrößen Blinkfrequenz Anzahl der lokal hinterlegten Bilder Position von Grafiksymbolen und Texten Set_Schaltzustand Set_Inhalt Get_Status_Gesamt Set_Sequenz Zustand Ausrichtung_horizontal Ausrichtung_vertikal Farbe-Hintergrund Farbe-Schrift Schriftart Schriftgröße Position Inhalt Heizung Lüftung Türkontakte Beleuchtungszustand Helligkeitsregelung Temperatur Dargestellte grafische Anzeige (z.b. x,y Startkoordinaten von Text und Grafiksymbolen)... 1 Das Auslesen der Befehlssatzinformationen erfolgt in späteren Ausbaustufen. Im Rahmen dieses Dokumentes werden mögliche Befehlsätze in der Zentrale gespeichert. Seite 15 von 33 Seite(n)

16 Informationen Versorgun g Amt für Verkehrsmanagement Schaltungen 1 n Zustände Störmeldung Kommunikationsfehler (Kategorien) (zwischen FG und DE) Aufzählungspunkte Totalausfall stellen kritische und Übertragungsstörung unkritische logische Fehler Hauptmeldungen dar; Syntaxfehler Nebenmeldungen sind nicht umsetzbarer Befehl herstellerspezifisch (Semantik) und ergänzen den elektrische Fehler Infogehalt der Aktorikausfall Hauptmeldungen in Sensorikausfall Klartextform Leuchtmittelausfall mechanische Fehler Aktorikausfall Umfeldfehler Spannungsausfälle Sicherungsfall Klima Schaltungen 1 n Zustände Status-Information Zyklische Bereitschaftsmeldung des FG (Is alive Message) Konfigurations- Informationen Notzustand Argumente der Befehle: Definition der Schaltzustände Optionaler Notzustand (Versorgung erfolgt vor Ort im Anzeigequerschnitt) Alphanumerisch Frei programmierbar Kommunikationsfehler (zwischen FG und DE) Totalausfall Übertragungsstörung logische Fehler Syntaxfehler nicht umsetzbarer Befehl (Semantik) elektrische Fehler Aktorikausfall Sensorikausfall Leuchtmittelausfall mechanische Fehler Aktorikausfall Umfeldfehler Spannungsausfälle Sicherungsfall Klima Alphanumerisch Frei programmierbar Zyklische Bereitschaftsmeldung des FG (Is alive Message) Argumente der Befehle: Definition der Schaltzustände Definition der Schriftarten (Font-ID, fixe Spationierung aufgrund Schilderbeschaffenheit) Befehlsunabhängige Info s: Displaygröße Optionaler Notzustand definierbar (Versorgung erfolgt vor Ort im Anzeigequerschnitt) Grafisch Frei programmierbar Kommunikationsfehler (zwischen FG und DE) Totalausfall Übertragungsstörung logische Fehler Syntaxfehler nicht umsetzbarer Befehl (Semantik) elektrische Fehler Aktorikausfall Sensorikausfall Leuchtmittelausfall mechanische Fehler Aktorikausfall Umfeldfehler Spannungsausfälle Sicherungsfall Klima Graphisch Frei programmierbar Zyklische Bereitschaftsmeldung des FG (Is alive Message) Argumente der Befehle: Definition der Schaltzustände Definition der Schriftarten (Font-ID, Pixelarray pro Buchstabe oder True Type Schriftart, variable Spationierung) Befehlsunabhängige Info s: Displaygröße Optionaler Notzustand (Versorgung erfolgt vor Ort im Anzeigequerschnitt) Tabelle 2: Kategorisierung der Anzeigetechnik Seite 16 von 33 Seite(n)

17 4.1.1 Attribute Übergreifende Attribute, die in jeder Kategorie eingesetzt werden Element <PROGRAMM> Das Element <PROGRAMM> stellt das Wurzelelement dar. Ein Programm kann aus 1 bis n Bildern bestehen, die zeitabhängig auf das Schild geschaltet werden. Beispiel: <?xml version="1.0" encoding="utf-8"?> <PROGRAM xmlns:xsi=" xsi:nonamespaceschemalocation="sign.xsd" id="prgram_1" DateTime=" T12:37:20"> </PROGRAM> Element <PICTURE> Das Element <PICTURE> beschreibt ein Bild, welches für eine bestimmte Zeitdauer auf einem Schild angezeigt werden soll. Beispiel: <PROGRAM > <PICTURE id="picture_1" duration="pt30m20s"> </PICTURE> </PROGRAM> Seite 17 von 33 Seite(n)

18 4.1.2 Kategorie Schaltungen 1..n Zustände Element <PRISM> Zur Ansteuerung dieser Kategorie wird ein Element <PRISM> definiert. Die anzuzeigenden Stellungen werden über den Wert im Element adressiert. Handelt es sich um weitere Gerätearten, die 1..n Zustände schalten können wird ebenfalls dieses Element verwendet. Beispiel: <PROGRAM> <PICTURE> <PRISM id="prism_1" index="2"> </PRISM> </PICTURE> </PROGRAM> Seite 18 von 33 Seite(n)

19 4.1.3 Kategorie Alphanumerisch frei programmierbar Element <MULTILINE> Das Element <MULTILINE> leitet die Beschreibung der Inhalte für Alphanumerisch Frei programmierbare Anzeigen ein. Beispiel: <PROGRAM> <PICTURE> <MULTILINE id="multiline_1" color="112233" bg_color="002200"> </ MULTILINE > </PICTURE> </PROGRAM> Element <POSITION> Das Element <POSITION> beschreibt die Position in der Zeile, ab der die Ausgabe erfolgen soll. Beispiel: <PROGRAM> <PICTURE> <MULTILINE> <POSITION row="0" col_start="4" col_end="8" color="332211" bg_color="110022" h_alignment="center"> </POSITION> </MULTILINE> </PICTURE> </PROGRAM> Element <TEXT> Das Element <TEXT> enthält den anzuzeigenden Text. Beispiel: <PROGRAM> <PICTURE> <MULTILINE id="multiline_1" color="112233" bg_color="002200"> <POSITION row="0" col_start="4" col_end="8" > <TEXT font="font_path/font_name.fnt" size="12" style="bold italic"> Text </TEXT> </POSITION> </ MULTILINE > </PICTURE> </PROGRAM> Seite 19 von 33 Seite(n)

20 Element <FUNCTION> Das Element <FUNCTION> adressiert über festgelegte Bezeichner eine Funktion, die auf dem Zielschild verfügbar ist. Zum Beispiel kann ein Schild die Funktion Uhrzeit bereitstellen, so dass im angegebenen Bereich die aktuelle Uhrzeit angezeigt wird. Beispiel: <PROGRAM> <PICTURE> <MULTILINE id="multiline_1" color="112233" bg_color="002200" effect="flash"> <POSITION row="0" col_start="4" col_end="8" > <TEXT font="font_path/font_name.fnt" size="12" style="bold italic"> Text </TEXT> <FUNCTION>temperature</ FUNCTION > </POSITION> </ MULTILINE > </PICTURE> </PROGRAM> Element <SYMBOL> Mit dem Element <SYMBOL> können Sonderzeichen übertragen werden. Beispiel: <PROGRAM> <PICTURE> <MULTILINE id="multiline_1" color="112233" bg_color="002200" effect="flash"> <POSITION row="0" col_start="4" col_end="8" > <TEXT font="font_path/font_name.fnt" size="12" style="bold italic"> Text </TEXT> <FUNCTION>temperature</ FUNCTION > < SYMBOL >s-bahn</ SYMBOL > </POSITION> </ MULTILINE > </PICTURE> </PROGRAM> Seite 20 von 33 Seite(n)