New Standardisierung der Schnittstellen von Lichtsignalanlagen · 2018. 11. 15. · Standardisierung der Schnittstellen von Licht-signalanlagen Systeme und Geräte der Straßenverkehrstechnik,

Berichte derBundesanstalt für Straßenwesen

Verkehrstechnik Heft V 116

Standardisierung derSchnittstellen von

Lichtsignalanlagen

von

Axel KroenMichael Klod

Uwe Sorgenfrei

SSP Consult — Beratende Ingenieure GmbHBergisch Gladbach

Berichte derBundesanstalt für Straßenwesen

Standardisierung derSchnittstellen von

Lichtsignalanlagen

Verkehrstechnik Heft V 116

hier:

Zentralrechner/Knotenpunktgerätund

Zentralrechner/Ingenieurarbeitsplatz

Die Bundesanstalt für Straßenwesen veröffentlicht ihre Arbeits- und Forschungs-ergebnisse in der Schriftenreihe Berichte der Bundesanstalt für Straßenwesen. Die Reihebesteht aus folgenden Unterreihen:

A - AllgemeinesB - Brücken- und IngenieurbauF - FahrzeugtechnikM- Mensch und SicherheitS - StraßenbauV - Verkehrstechnik

Es wird darauf hingewiesen, dass die unter dem Namen der Verfasser veröffentlichtenBerichte nicht in jedem Fall die Ansicht desHerausgebers wiedergeben.

Nachdruck und photomechanische Wieder-gabe, auch auszugsweise, nur mit Genehmi-gung der Bundesanstalt für Straßenwesen, Referat Öffentlichkeitsarbeit.

Die Hefte der Schriftenreihe Berichte derBundesanstalt für Straßenwesen können direkt beim Wirtschaftsverlag NW, Verlag für neue Wissenschaft GmbH, Bgm.-Smidt-Str. 74-76, D-27568 Bremerhaven, Telefon (04 71) 9 45 44 - 0, bezogen werden.

Über die Forschungsergebnisse und ihre Veröffentlichungen wird in Kurzform imInformationsdienst BASt-Info berichtet.Dieser Dienst wird kostenlos abgegeben;Interessenten wenden sich bitte an dieBundesanstalt für Straßenwesen, Referat Öffentlichkeitsarbeit.

Impressum

Bericht zum Forschungsprojekt 77.437/1999: Standar-disierung der Schnittstellen von Lichtsignalanlagen, ins-besondere Zentralrechner/Knotenpunktgerät und Zent-ralrechner/Ingenieurarbeitsplatz -

Projektbetreuung Fritz BolteRalf Meschede

HerausgeberBundesanstalt für StraßenwesenBrüderstraße 53, D-51427 Bergisch GladbachTelefon: (0 22 04) 43 - 0Telefax: (0 22 04) 43 - 674

RedaktionReferat Öffentlichkeitsarbeit

Druck und VerlagWirtschaftsverlag NWVerlag für neue Wissenschaft GmbHPostfach 10 11 10, D-27511 BremerhavenTelefon: (04 71) 9 45 44 - 0Telefax: (04 71) 9 45 44 77Email: [email protected]: www.nw-verlag.de

ISSN 0943-9331ISBN 3-86509-166-0

Bergisch Gladbach, Oktober 2004

Kurzfassung – Abstract

Standardisierung der Schnittstellen von Licht-signalanlagen

Systeme und Geräte der Straßenverkehrstechnik,insbesondere zur städtischen LSA-Steuerung,haben bisher keine offen gelegten Schnittstellen,die einen bundesweit standardisierten Aufbau vonherstellergemischten Lichtsignalsteuerungssyste-men erlauben. Als Reaktion auf die Forderung vie-ler LSA-Betreiber nach einem funktionellen Zusam-menwirken der uneinheitlichen Systeme entwickelnund spezifizieren die ODG, der OCA e. V., die OTECund der VIV e. V. offene Schnittstellen für Systemeund Komponenten der Straßenverkehrstechnik(Open Communication Interface for Traffic ControlSystems – OCIT). Für die von diesen Interessen-gruppen initiierte und begonnene Erarbeitung vonSchnittstellenstandards hat die BASt im Auftragdes BMVBW die Gesamtmoderation übernommen.Sie wird hierbei durch die Forschungsarbeiten imFE-Projekt 77.437/1999 unterstützt, dessen Zielehauptsächlich in der neutralen Moderation (Kon-sensschaffung), der Organisation und Dokumenta-tion der erreichten Standardisierungsstufen, derZusammenstellung der erarbeiteten Schnittstellen-definitionen und der fachlichen Begleitung von La-bortests liegen. Im Ergebnis liegen die ersten offengestalteten Schnittstellen, OCIT-Outstations zurVernetzung von Zentralen und Feldgeräten und dieOCIT-Instations zur Ankopplung der verkehrstech-nischen Basisversorgung via Verkehrsingenieurar-beitsplatz vor. Analysen an diesen Schnittstel-lenspezifikationen ergaben keine signifikanten Auf-fälligkeiten, die auf eine Verhinderung der ange-stoßenen Standardisierungsentfaltung schließenlassen. Die Erkenntnisse aus den Labortests ver-deutlichen, dass der erste Schritt zur Realisierungvon OCIT-Geräten erfolgreich absolviert wurde.Neben den Schnittstellendefinitionen wurden desWeiteren ergänzende Hinweise und Textvorschlägefür OCIT-Ausschreibungen erarbeitet. Der Schlus-sbericht zum FE 77.437/1999 enthält ein Vademe-kum (Leitfaden), um den Einstieg in die Thematikvon OCIT primär für Anlagenbetreiber zu erleich-tern.

Der Originalbericht enthält als Anlagen eine u. a.Dokumentationen der Schnittstellen (D: OCIT-Out-stations, E: OCIT-Instations, F: OCIT-Ausschrei-bung). Auf den Abdruck dieser sehr umfangreichen

Anlagen wurde in der vorliegenden Veröffentli-chung verzichtet. Sie liegen bei der Bundesanstaltfür Straßenwesen auf CD vor und können kosten-los angefordert werden.

Standardisation of interfaces for light-signalsystems

Traffic systems and devices, in particular those designed for controlling urban light-signal systems(Lichtsignalanlagen – LSA), have hitherto not hadopen interfaces which would enable the development of nationally standardised light-signal control systems from different manufacturers. In response to the call by many LSA operators fornon-standardised systems to function in combination, ODG, OCA e. V., OTEC and VIV e. V.are developing, and drawing up specifications foropen interfaces for traffic systems and components (Open Communication Interface forTraffic Control Systems – OCIT). Under commissionto the Federal Ministry of Transport, Building andHousing (Bundesministerium für Verkehr, Bau- undWohnungswesen – BMVBW), the BASt has assumed overall coordination of the drawing up ofinterface standards, which had originally been initiated and begun by the above interest-groups.The BASt is supported in this by the research workcarried out in FE project 77.437/1999, the aims ofwhich are mainly concerned with neutral coordi-nation (creating consensus), organisation and documentation of the levels of standardisation attained, the bringing together of the interface definitions which have been drawn up, and thetechnical support of laboratory tests. The work hasresulted in the first open interfaces, OCIT out-stations to network control centres and field devices and OCIT in-stations to link up the basicsupply of traffic technology via the traffic engineer’s workplace. Analyses of these interfacespecifications did not show any significant conspicuous developments which could have hindered the development of standardisationwhich has been initiated. The results from the laboratory tests showed that the first step towardsimplementing OCIT devices had been successful.As well as the interface definitions, supplementaryinformation and text proposals were drawn up for

3

OCIT invitations to tender. The final report on FE77.437/1999 contains a vade mecum (guide) inorder to make it easier to become acquainted withthe subject of OCIT, primarily for system operators.

The appendices to the original report contain interalia documentation of the interfaces (D: OCIT-Outstations, E: OCIT-Instations, F: OCIT invitationto tender). These very extensive appendices havebeen omitted from this publication. They are contained on CD at the Federal Highway ResearchInstitute (Bundesanstalt für Straßenwesen) andmay be ordered there free of charge.

4

Inhalt

Vorwort . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . 13

2 Ausgangssituation und Aufgabenstellung der Forschungsarbeit . . . . . . . . . . . . . . . . 14

3 Inhalt, Gliederung und Ziel-setzung des Schlussberichtes . . . . . 14

4 Ergebnisstand September 2002 derStandardisierung offener Schnitt-stellen der Straßenverkehrstechnikim Bereich von Lichtsignalanlagen (Vademekum) . . . . . . . . . . . . . . . . . . . 17

4.1 Entwicklungsanforderungen an eine offene Schnittstelle für Lichtsignalanlagen . . . . . . . . . . . . . . . . 17

4.1.1 Allgemein gültige Anforderungen an offene Schnittstellen . . . . . . . . . . . . 17

4.1.2 Allgemeine (funktionale) Anforde-rungen an offene Schnittstellen für Geräte der Straßenverkehrs-technik im Bereich von Licht-signalanlagen . . . . . . . . . . . . . . . . . . . . 17

4.1.3 Schnittstellenrelevante Richtlinien, Merkblätter und Forschungs-projekte . . . . . . . . . . . . . . . . . . . . . . . . . 20

4.1.4 Beispiele schnittstellenrelevanter Entwicklungen in der Kommunika-tions- und Verkehrstechnik . . . . . . . . . . 21

4.2 Hinweise zur Standardisierung einer offenen Schnittstelle der Verkehrstechnik, insbesondere fürLichtsignalanlagen . . . . . . . . . . . . . . . . 25

4.2.1 OCIT-Systemkonzeption . . . . . . . . . . . . 254.2.2 Externe Systemzugänge . . . . . . . . . . . 264.2.3 Aufbau und Anwendungsbereiche

der OCIT-Schnittstellen . . . . . . . . . . . . 264.2.4 Datenbeschreibungssprache XML . . . . 27

4.3 Aktueller Ergebnisstand der OCIT-Entwicklungstätigkeiten . . . . . . . . . . . . 28

4.3.1 OCIT-Outstations . . . . . . . . . . . . . . . . . 284.3.2 OCIT-Instations . . . . . . . . . . . . . . . . . . . 37

4.4 Rechtliche Aspekte . . . . . . . . . . . . . . . . 41

4.5 Organisationsformen . . . . . . . . . . . . . . 42

4.5.1 Gruppierungen . . . . . . . . . . . . . . . . . . . 42

4.5.2 Tätigkeitsfelder der OCIT-Gruppenim Standardisierungsprozess . . . . . . . . 43

4.5.3 Modus der Kooperation . . . . . . . . . . . . 45

5 Bericht zu (funktionalen) Schnitt-stellentests im Laboraufbau . . . . . . . 48

5.1 Zielsetzung der Labortests . . . . . . . . . . 48

5.2 Erarbeitung eines Testprocederes . . . . . . . . . . . . . . . . . . . 48

5.3 Laboraufbau zur Testdurchführung . . . . . . . . . . . . . . . . . 49

5.4 Erkenntnisse aus den Labortests . . . . . . . . . . . . . . . . . . . . . . . 50

6 Fachliche Einordnung und Aus-blick der Standardisierung . . . . . . . . 51

6.1 Konkludenz zu technologisch innovativen Entwicklungs-prozessen . . . . . . . . . . . . . . . . . . . . . . . 51

6.2 Stringenz im Entwicklungsprozess einer offenen Schnittstelle in der Straßenverkehrstechnik . . . . . . . . . . . . 54

6.3 Konsens zum Standardisierungsprozess . . . . . . . . . . 55

6.3.1 Realisierungsstrategie . . . . . . . . . . . . . 55

6.3.2 Abgestimmte Realisierungs-schritte der Standardi-sierungsgruppe . . . . . . . . . . . . . . . . . . . 56

6.4 Potenziale (Perspektiven) der OCIT-Schnittstellen bei Einsatz von Daten- und Prozessmodellen . . . . . . . . . . . . . . 57

6.4.1 Abwägung von objektorientierter contra prozeduraler Programmierung . . . . . . . . . . . . . . . . . . 57

6.4.2 Anwendungsfall OCIT-Innovationsprozess . . . . . . . . . . . . . . . . 59

7 Zusammenfassung . . . . . . . . . . . . . . . . 60

Danksagung . . . . . . . . . . . . . . . . . . . . . . . . . . 61

Literatur- und Dokumentenverweise . . . . . . 62

5

Dem Originalbericht liegen folgende Dokumentebei:

Bislang unveröffentlichte Dokumente

· Übersicht zu allen begleiteten Sitzungen/Veran-staltungen

· Protokolle der OCIT-Gruppen-Meetings

· Protokolle zu den internen OCIT-Arbeitskreis-Sitzungen

· Protokolle zu den Arbeitskreissitzungen „Aus-schreibung

· Protokolle zu den Sitzungen der Betreuungs-gruppe bei der BASt

· ODG: Protokoll „Vorbereitung Demo der Konfor-mitätstests„ am 05.07.2002

· Protokolle zu den Labortests am 22.08.02 inKöln und München

· ODG: „Wie testet die ODG?“, PowerPointprä-sentation vom 22.08.02

· ODG: OCIT-Outstations-Lichtsignalsteuergerä-te-V1.0-Konformitätsprüfung Version 1.3

· Testsuite zum Labortest am 22.08.02 in Kölnzwischen STOYE-Zentrale und Siemens-Steu-ergerät

· Testsuiten zum Labortest am 22.08.02 in Mün-chen zwischen Siemens-Zentrale und Sie-mens-, Signalbau-Huber, STOYE- und Stühren-berg-Steuergeräten

· OTEC: OCIT instation VI für Lichtsignalsteue-rung, VT-Basisversorgungsdaten Version 1,15.11.2001 – Lizenzvereinbarungen und Nen-nung des Interessenzwecks

· OCA e. V.: Protokoll zum Workshop OCIT-AP3am 07.05.02 in Frankfurt

· Präsentationsfolie von SSP Consult BeratendeIngenieure GmbH zur Informationsveranstal-tung in Graz

Dokumente, die frei über das Internet zugäng-lich sind

Anmerkung: Zitiert wird die bei Erstellung des Ori-ginalberichts verfügbare Version. Auf den nachfol-gend beschriebenen Webseiten können aktuellereFassungen angeboten werden.

OCIT-round-table-Webseite (http://www.ocit.org/roundtable/):

· Memorandum of Understanding

· Alle aktuellen Protokolle zu den OCIT-Plenumsund OCIT-Steuergremiumssitzungen initiiertdurch das Forschungsprojekt 77.0466/2002„Vereinheitlichung und praktische Erprobung of-fener Schnittstellen für Geräte der Straßenver-kehrstechnik“ als offizieller Nachfolger des For-schungsprojektes 77.437/1999

ODG-Webseite (http://www.ocit.org):

· ODG: OCIT-Outstations – Einführung in das System OCIT-O System V1.0

· ODG: OCIT-Outstations-Protokoll V1.0 – Regelnund Protokolle

· ODG: OCIT-Outstations-Basis V1.0 – Basisdefi-nitionen für Feldgeräte

· ODG: OCIT-Outstations-Lstg V1.0 – Lichtsignal-steuergeräte

· ODG: OCIT-Outstations-Profil 1 V1.0 – Profil 1Übertragungsprofil für Punkt-zu-Punkt-Verbin-dungen auf festgeschalteten Übertragungswe-gen

· ODG: Nutzungsvereinbarung „OCIT-Outstationsfür Lichtsignalsteuergeräte Version 1“

OTEC-Konsortium-Webseite (http://www.otec-konsortium.de/):

· OTEC: OCIT instation VI für Lichtsignalsteue-rung, VT-Basisversorgungsdaten Version 1,15.11.2001 – Beschreibung der Schnittstelle

VIV-Webseite (http://www.viv-ev.de/):

· Publikation von OCIT-AK-Ausschreibung: OCIT-Ausschreibung (Teil 1 und Teil 2), Version 1.2vom 10.05.02

6

Verzeichnis der Abkürzungen

7

Kürzel Langtext Herkunft

ASCII American Standard Code for Information Inter-change

BEFA-15 Schnittstelle zum Verkehrsrechner Siemens

bps bits per second (= bit/s)

BTPPL Basis Transport Paket OCIT-Protokoll Layer Outstati-

ons

CRC Cyclic Redundancy Check, zyklische Blockprüfung

CWA europäische Fachverein-barungen (CEN Workshop Agreement)

DCF77 Langwellensender der dt. Telekom AG

DN Domain Name

DNS Domain Name Service

FE Forschungs- und Ent-wicklungsvorhaben

FTP File Transfer Protocol

HDLC High Level Data Link Protocol ISO

http Hypertext Transfer Protocol

IP Internet Protocol RFC 791 (Internet)

IPCP Internet Protocol ControlProtocol Internet

ISO International Organizationfor Standardization

ITS Intelligent Transportation Systems

ITU-T International Telecommu-nications Union (früher CCITT)

LAN Local Area Network

LB Leistungsbeschreibung

LCP Link Control Protocol Internet


LV Leistungsverzeichnis

MAN Metropolitan Area Network

MNP4 Fehlersicherungsproto-koll ITU-T

MNP5 Datenkompressionspro-tokoll ITU-T

NTCIP National Transportation Communications for ITS Protocol

OCIT Open Communication Interface for Road Traffic Control Systems ODG

OSI Open Systems Interconnect ITU-T

PAS Publicly Available Speci-fication (öffentlich verfüg-bare Spezifikation)

PPP Point to Point Protocol Internet

RFC Request for Comment (= Arbeitspapiere, Proto-koll-Spezifikationen od.Kommentare zu Netz-werk-Themen) Internet

RIPID Ringpuffer ID OCIT-Outstati-

ons

SHA-1 Secure Hash Algorithm Internet

TCP Transmission Control RFC 793Protocol (Internet)

TELIS

TLS Technische Lieferbedin-gungen für Strecken-stationen

UDP User Datagram Protocol – low end transport service Internet

V.xx Standards der ITU-T (Inter-national Telecommunica-tions Union), früher CCITT

VSR Verkehrsrechner oder -Zentrale

Glossar

AnalysedatenAusgewählte Daten des -> Lichtsignalsteuergerä-tes, die zur Analyse des Verkehrsgeschehens die-nen. Analysedaten werden in der Zentrale je nachAnalysezweck unterschiedlich behandelt, z. B. ge-speichert und offline analysiert oder einer Quasi-on-line-Analyse unterzogen (in kurzen Zeitabständen).

Analysedaten sind z. B.: Phasenübergänge, Mess-werte, Variable, Signalgruppenzustände.

ArchiveIn Archiven werden vorgegebene Daten des ->Lichtsignalsteuergerätes, die zur Dokumentationvon -> Betriebszuständen bzw. zur allgemeinenZwischenspeicherung von -> dynamischen Wertendienen, gesammelt. Das Speicherformat (Bereit-stellungsformat) kann vom Format der einzelnenDaten abweichen, um damit eine Datenkomprimie-rung zu erreichen.

Archive werden sowohl in der Zentrale als auch inden Geräten geführt. In den Geräten geführte Ar-chive können von der Zentrale gelesen werden.

Die Anzahl der Archive ist gerätespezifisch. Be-stimmte Archive sind für OCIT-Outstations obliga-torisch.

Für Archive können Einschränkungen definiert sein,die festlegen, welche Typen von dynamischen Wer-ten abgelegt werden können.

Archive: Betriebstagebücher für Betriebszustände,Signalsicherung, Störungen, ÖPNV-Archiv, Mess-wertarchive u. a.

Dynamische WerteÜberbegriff für ausgewählte interne Variablen desLichtsignalsteuergerätes, wie Betriebszustände,Messwerte, Variablen, Phasenübergänge, Signal-gruppenzustände usw.

BefehleBefehle gehen von der Zentrale aus und veranlas-sen das -> Lichtsignalsteuergerät zu bestimmtenAktionen. Auch Abfragen und Änderungen vonDaten sind Befehle.

Kann ein Befehl nicht ausgeführt werden, weil ernicht prior ist oder ein anderer Grund vorliegt, wirdeine entsprechende -> Fehlermeldung für die Zen-trale generiert.

8


W3C World Wide Web Con-sortium

WAN Wide Area Network

WWW World Wide Web

XDR External Data Representation

XOR Exclusive OR, exclusiveODER-Verknüpfung

XML herstellerunabhängigeAuszeichnungssprache, mit der u. a. eine Schnitt-stellenbeschreibung verteilter Applikationenrealisiert werden kann (spezifiziert durch W3C,⇒HTML) Internet

BefehlsquellenBefehlsquellen sind unterschiedliche Verursacherder Befehle für die Wahl des -> Signalprogrammsoder der -> Betriebsart.

BetriebsartEine Bezeichnung für bestimmte Arten der Steue-rung (z. B. lokal, zentral) oder eines Zustandes, wiez. B. Ein, Aus, Störung.

BetriebszustandEine Bezeichnung für einen Zustand, wie z. B. Ein,Aus, Störung. Oft auch als -> Betriebsart bezeich-net.

ContainerEin Container ist ein OCIT-Basisobjekt, mit dessenHilfe Dateien mit in OCIT nicht festgelegtem Inhalttransportiert werden, wie z. B. herstellerspezifischeVersorgungsdaten. Die Containergröße ist abhän-gig vom eingesetzten Protokoll (TCP oder UDP).

dezentrale Architekturhier: Der Aufbau der Feldgeräte ist für einen autar-ken Betrieb (ohne regelmäßig eingreifende Steue-rung durch die Zentrale) ausgelegt.

Ein/AusschaltbilderEine Signalisierungsfolge, über die ein Gerät vonAus nach Ein in das gewünschte Signalprogrammwechselt oder von Ein nach Aus wechselt, wobeider Signalisierungszustand Aus durch ein Bild derSignalisierungsfolge bestimmt wird.

FehlermeldungIm Gegensatz zu Störungen (-> Störungsmeldung)sind Fehler nicht durch einen technischen Defektbedingt, sondern Fehler in der Versorgung oderBedienung des Feldgerätes.

Versorgungsfehler: Verletzung einer Zwischenzeit.Derartiges wird bei modernen Geräten automatischerkannt; führt aber zu einer Fehlermeldung.

Bedienungsfehler: nicht ausführbarer Befehl. Eineentsprechende Meldung erscheint als Rückgabe-wert des Befehles. Im Rückgabewert ist zusätzlichabgelegt, aus welchem Grund der Befehl nicht aus-führbar ist.

FeldgerätEin auf der Straße (im Feld) installiertes Gerät, dasAufgaben der Verkehrsüberwachung oder -steue-

rung ausführt und das über eine Kommunikations-einrichtung mit einer -> Zentrale verbunden ist.Feldgeräte beinhalten als Obergruppe die -> Licht-signalsteuergeräte.

Intelligentes (LSA-)SteuergerätIntelligente Geräte mit leistungsfähigen Prozesso-ren, die komplexe Verkehrsabhängigkeiten lokalbeherrschen und zudem Messwerte in geeigneterWeise aggregieren (Aufarbeiten der rohen Detek-torwerte).

Knotenpunktauch: Kreuzung, Knoten

Sammelbegriff für die unterschiedlichsten Formenvon Straßenkreuzungen, d. h. auch Kreisverkehre.

Ein Lichtsignalsteuergerät kann mehrere Knoten-punkte steuern. Es ist auch möglich, dass mehrereLichtsignalsteuergeräte einen Knotenpunkt steuern.

Lichtsignalanlageauch: Lichtzeichenanlage (RiLSA), Anlage, Signal-anlage, LSA. Sie gehören laut StVO zu Verkehrs-einrichtungen und haben die Aufgabe der Rege-lung des Verkehrs mittels Lichtzeichen an -> Kno-tenpunkten. Ihre Lichtzeichen geben Vorrangre-geln, Verkehrsschilder und Markierungen vor.

Zu einer LSA gehören alle Teile die im Kreuzungs-bereich installiert werden, also Lichtsignalsteuer-geräte, Maste, Signalgeber, Verkehrserfassungs-einrichtungen sowie die gesamte elektrische Ins-tallation.

Lichtsignalsteuergerät-> Feldgerät zur Steuerung von Lichtsignalen

MeldungenMeldungen sind Ereignisse, die vom -> Feldgerätan die Zentrale gemeldet werden und abhängigvon der Art des Ereignisses dieses genauer spezi-fizieren. Nur konfigurierte Ereignisse generiereneine Meldung.

MesswerteMesswerte sind von der Sensorik gelieferte Daten,die als Originalwert oder vorverarbeitet eine Aussa-ge über das Verkehrsgeschehen darstellen. Mess-werte werden von Schleifen, Infrarot- und anderenDetektoren sowie Tastern geliefert.

9

OCIT-SystemzugangOCIT-konforme Schnittstelle in der Zentrale, an derWerkzeuge für Versorgung oder Service ange-schlossen werden können, die darüber Zugang zuden Feldgeräten erhalten.

ÖPNV-ArchivIn das ÖPNV-Archiv werden die -> ÖPNV-Tele-gramme, ergänzt mit Werten aus dem Steuergerät,archiviert. Es enthält die - > ÖPNV-Telegramme, er-gänzt um Umlaufsekunde, Signalplan-Nr., Phase/Phasenübergang, Fahrzeit, Rot- u. Grünende.

ÖPNV-Telegramm

auch: ÖV-Telegramm

Standard-Telegramm nach R09-xx Aufbau.

Ein ÖPNV-Telegramm besteht aus folgenden Ein-trägen:

· Datum, Uhrzeit, Melde-, Linien-, Kurs- und Rou-tennummer, Priorität, Zuglänge, Richtung, Fahr-planabweichung.

ParserDer Parser stellt einer Anwendung ein Dokumentaufbereitet und zur Weiterverarbeitung zur Verfü-gung

Peer-to-Peer-TechnikDurch die Peer-to-Peer-Technik können Internet-Nutzer direkt auf die Datenbanken bzw. freigege-benen Ressourcen anderer Nutzer bzw. ihrer Rech-ner zugreifen. P2P beruht auf dem Prinzip der De-zentralisierung von Information. Die Dateien wer-den nicht auf zentralen Rechnern gespeichert, son-dern liegen nur auf den Computern der Nutzer.

PhasenEine Phase ist ein Teil eines -> Signalzeitenplanes,in dem ein bestimmter -> Signalisierungszustandunverändert bleibt. Dabei kann es vorkommen,dass Übergangszustände noch während des Be-ginns einer Phase automatisch ablaufen.

Die Versorgungsdaten für Phasen gliedern sich inPhasen und Phasenübergänge auf. Sie sind ein Teilder Geräteversorgungsdaten für eine verkehrsab-hängige Logik. Bei Phasen handelt es sich um eineZuordnung von Schaltzuständen zu Signalgrup-pen, bei Phasenübergängen um eine Auflistungvon Schaltzuständen und Schaltzeiten der Signal-gruppen.

RouterEin Router hat die Funktion, zwei räumlich getrenn-te Netzwerke über eine Telekommunikations-Lei-tung miteinander zu verbinden.

RoutingMit Routing bezeichnet man den Weg von Daten-paketen zwischen den Netzen. Das Internet kenntkeine Direktverbindungen zwischen Rechnern;stattdessen erfolgt der Versand von Daten grund-sätzlich in kleinen Paketen und nach Bedarf überverschiedene Zwischensysteme – nach Möglich-keit natürlich auf dem zum Zeitpunkt günstigstenWeg (dynamisches Routing). Diese Form des Da-tenverkehrs ermöglicht die hohe Flexibilität undAusfallsicherheit des Internet.

TagesplanListe von Schaltaktionen für einen Tag.

SignalgruppeEine Signalgruppe umfasst all jene Lichtsignale aneinem -> Knotenpunkt, die zu jedem Zeitpunkt inihrem -> Signalisierungszustand übereinstimmen.

SignalgruppenfernsteuerungAlle Schaltbefehle für die LSA sowie die Auswer-tungen der Detektoren erfolgen durch den VSR,weil in der Regel das Steuergerät vor Ort überkeine nennenswerte Intelligenz verfügt.

SignalgruppenversorgungSignalgruppenversorgung ist ein Teil der Geräte-versorgungsdaten. Es handelt sich um die Versor-gung der Signalgruppentypen, Farbkombinationen,Zwischenzeit-Matrix, Ein/Ausschaltbilder etc. Si-cherheitsrelevante Daten dürfen von der Zentraleaus während des normalen Betriebes nicht verän-dert werden.

SignalprogrammfernversorgungDer -> Signalzeitenplan wir unmittelbar vor derUmschaltung des Signalprogramms an das Steuer-gerät geschickt.

Signalisierungszustandauch: Signalisierung, Signalzustand, Signalbild

Die an den Signalgebern geschalteten Lichtsigna-le, die einen bestimmten Zustand an einer -> Sig-nalgruppe ergeben, z. B. Grün, Gelb, Rot, Dunkel,Blinken usw.

10

SignalplanEr enthält die Dauer von Signalzeiten und die Zu-ordnung zu bestimmten Signalgruppen (Signalisie-rungszustände). Dazu kommen Daten für Synchro-nisierung und Signalprogrammwechsel. Signalplä-ne sind ein Teil der Geräteversorgungsdaten fürFestzeit- und/oder verkehrsabhängige Steuerver-fahren.

Nicht aktiv laufende Signalpläne können währenddes Normalbetriebes von der Zentrale geändertwerden. Sondersignalpläne wie z. B. Feuerwehr-pläne sind ebenfalls Signalpläne.

SignalprogrammeSignalprogramme sind Anweisungen für denSteuerungsablauf. Sie bestimmen die zeitlicheFolge der -> Signalisierungszustände auf derGrundlage von Signalplänen und/oder den Logik-typ (Festzeit, Phasen, Verkehrsabhängig).

Jedem -> Signalprogramm sind -> Ein/Ausschalt-bilder zugeordnet.

Der Betriebszustand „Aus” ist kein Signalpro-gramm.

SignalzeitenplanDer Signalzeitenplan ist die grafische Darstellungdes Signalplans im Zeitmaßstab.

SondereingriffAuswahl eines nur temporär gültigen Signalpro-gramms, z. B. eines Feuerwehrplanes. Nach Endedes Sondereingriffes kehrt das Gerät in den ur-sprünglichen Zustand/Signalprogramm zurück.

StadtfahrplanListe von Schaltaktionen mit variabler Anfangszeit,die für verschiedene Situationen bereitgestellt wird.

Beispiel: Verlängerung eines Fußballspieles ver-langt spezielle Schaltaktionen bei Ende.

StatusDer Status gibt den aktuellen Zustand des Gerätesan (Betriebszustand). Er enthält die aktive Betriebs-art (auch Ein/Auszustand, Signalprogramm) undeine Sammelstörungsinformation.

StörungsmeldungenStörungsmeldungen melden das Auftreten einerdurch einen technischen Defekt verursachtenStörung einer Systemkomponente.

Störungen können innerhalb des Lichtsignalsteuer-gerätes unterschiedliche Verursacher haben, z. B.Steuerung oder Signalsicherung und auch unter-schiedliche Auswirkungen. Störungsmeldungenbeinhalten den Verursacher mit möglichst genauerLokalisierung des Störungsortes und die Art derStörung.

Sie gliedern sich in:

· Abschaltrelevante Meldungen (RiLSA/VDE)· Betriebsrelevante Meldungen (Service)· Herstellerrelevante Meldungen in Form eines

OCIT-Basisobjektes, das einen Datensatz trans-portiert, dessen Semantik in OCIT nicht herstel-lerübergreifend festlegt ist. Darüber hinaus sinddafür spezifische Objekte verwendbar

(Unterscheidung: -> Fehlermeldungen)

SynchronisationDie Synchronisierung in grünen Wellen basiert aufgleichlaufenden Uhren. Das dazu notwendigeRückrechenverfahren ist projektspezifisch festzule-gen, da das Rückrechenverfahren im System (Be-stand + OCIT) gleich sein muss.

SynchronitätsüberwachungDie Synchronitätsüberwachung überwacht dieFunktion von grünen Wellen. Sie kann auf verschie-denen Arten erfolgen, z. B. durch zeitliche Kontrol-le des Grünbeginns an allen beteiligten Knoten.

TeilknotenAufteilung der Schaltzustände in Signalisierungs-bereiche, die zueinander nicht feindlich sind. Teil-knoten können von der Zentrale ein- und ausge-schaltet werden.

UpdateÜbertragung der Lizenz auf Software/Hardwareneuerer Versionen.

UpgradeErweiterung der Lizenz in Hinsicht auf Funktiona-lität.

Verkehrstechnische ParameterVerkehrstechnische Parameter sind ein Teil der ->Versorgungsdaten. Sie können (von Fachleuten) imlaufenden Betrieb geändert werden. Es sind keineumfangreichen Datensätze, sondern eher einzelneWerte.

11

VersorgungsdatenVersorgungsdaten sind alle veränderbaren Daten,die das Gerät zur Erfüllung seiner bestimmungs-gemäßen Funktion benötigt. Das Gerät kann nur inBetrieb gehen, wenn alle Versorgungsdaten kom-plett und fehlerfrei im Gerät vorliegen.

Die Versorgungsdaten haben eine unterschiedlicheGranularität:

· -> Verkehrstechnische Parameter

· Teilversorgung(z. B. alle Daten eines Signalplanes)

· Vollversorgung (SISI-Daten nur vor Ort schreibbar)

VisualisierungsdatenEs handelt sich um Daten, die zur Anzeige vonsekündlichen Abläufen an der LSA auf dem Bild-schirm der Zentrale dienen. Diese Daten könnenauch für Analysezwecke benutzt werden. Um dieBelastung der Übertragungsstrecke zu minimieren,sollen diese Daten gesammelt und in Abständenvon mehreren Sekunden übertragen werden. Fürdie Anzeige am Bildschirm der Zentrale werden dieDaten zeitlich entzerrt.

Zentraleauch: VSR, Verkehrsrechner

Definition OCIT: Eine aus einer oder mehrerenKomponenten bestehende Einrichtung, welche dieArbeitsweise der Feldgeräte vorgibt und über-wacht. Die Komponenten der Zentrale können sichan verschiedenen Orten befinden.

12

Vorwort

Die Durchführung des Forschungsprojekts77.437/1999 zur „Standardisierung von Lichtsig-nalanlagen” erfolgte im Auftrag des Bundesminis-teriums für Verkehr, Bau- und Wohnungswesen(BMVBW). Die Bundesanstalt für Straßenwesen(BASt) wurde hierfür mit der Gesamtmoderationbeauftragt. Über das Forschungsprogramm Stadt-verkehr (FOPS) wird diese Aufgabe durch den For-schungsauftrag unterstützt.

Mitglieder der forschungsbegleitenden Betreu-ungsgruppe waren:

BDir Dipl.-Ing. RohloffBMVBW

BDir Dr. Bolte BASt

Dipl.-Ing. Kühnelt BASt

OAR Dipl.-Ing. Stüben Ministerium für Wirtschaft und Mittelstand, Energie und Verkehr

Dipl.-Ing. Meschede BASt

Dipl.-Ing. Reich OTEC/FGSV/PTV AG

Dipl.-Ing. Wenter ODG/Siemens AG

Dipl.-Ing. Schöttler OCA e. V./FGSV/Stadt Frankfurt

Dipl.-Ing. (FH) Doll VIV e. V./GEVAS Ingenieurgesellschaft mbH

Die Projektdurchführung erfolgte auftragsgemäß inenger und aktiver Zusammenarbeit mit folgendenInstitutionen:

· OCIT Developer Group (ODG)

· Open Communication for Traffic EngineeringComponents (OTEC)

· Open Traffic Systems City Association e. V.(OCA)

· Verband der Ingenieurbüros für Verkehrstechnike. V. (VIV)

1 Einleitung

Systeme und Geräte der Straßenverkehrstechnik,insbesondere zur städtischen Lichtsignalsteuerungwie zentraler Verkehrsrechner, Bereichsrechner,Knotenpunkt-Steuergeräte, Mess- und Ausgabe-einrichtungen sowie Verkehrsingenieur-Arbeitsplät-ze, haben bisher keine offen gelegten Schnittstel-len, die einen bundesweit standardisierten Aufbauvon herstellergemischten Lichtsignalsteuerungs-systemen erlaubt. Dies führt zu einer einseitigenAbhängigkeit der Betreiber und Nutzer solcher Systeme von ihrem jeweiligen Systemlieferanten.Nicht nur das Bestreben der Nutzer, herstellerun-abhängig Komponenten von Verkehrssteuerungs-und Informationssystemen zusammenzustellen,sondern ganz wesentlich auch der Wunsch, dieWirtschaftlichkeit bei Beschaffung und Betrieb zuverbessern und neueste Technologie einzusetzen,gibt Anlass für eine Neuausrichtung der Technik.

Auch vor dem Hintergrund, dass künftige Verkehrs-managementaufgaben nicht nur auf einige wenigeGroßstädte beschränkt bleiben, ist die unproble-matische Vernetzung der Verkehrstechnikkompo-nenten ein wichtiger Teil der Investitions- und Zu-kunftssicherung für die Systeme der Straßenver-kehrstechnik. Die herstellerübergreifende Standar-disierung liegt deshalb auch im Interesse der Her-steller derartiger Systeme oder Komponenten.

Als Reaktion auf die Forderung vieler Betreiber vonVerkehrssteuerungseinrichtungen und Lichtsignal-anlagen nach einem funktionellen Zusammenwir-ken der Systeme und Geräte verschiedener Her-steller arbeiten derzeit (Stand September 2002) fol-gende Interessengruppen aktiv an offenen Schnitt-stellen für Systeme und Komponenten der Stra-ßenverkehrstechnik:

· OCIT Developer Group (ODG),

· Open Communication for Traffic EngineeringComponents (OTEC),

· Open Traffic Systems City Association e. V.(OCA),

· Verband der Ingenieurbüros für Verkehrstechnike. V. (VIV).

Für die von diesen Interessengruppen initiierte undbegonnene Erarbeitung von Schnittstellenstan-dards hat die Bundesanstalt für Straßenwesen(BASt) im Auftrag des Bundesministeriums für Ver-kehr, Bau- und Wohnungswesen (BMVBW) die Ge-

13

samtmoderation übernommen. Sie wird hierbeidurch die Forschungsarbeiten im FE-Projekt77.437/1999 „Standardisierung der Schnittstellenvon Lichtsignalanlagen” unterstützt.

2 Ausgangssituation und Auf-gabenstellung der Forschungs-arbeit

Die Dimension des erforderlichen Schnittstellenin-novationsprozesses zur Schaffung einer offenenSchnittstelle für die Straßenverkehrstechnik (OpenCommunication Interface for Traffic Control Sys-tems = OCIT) per se und die Vielfalt der daran zubeteiligenden Hersteller und Betreiber manifestier-ten bereits vor Beginn des Forschungsprojektesden hohen wie anspruchsvollen Bedarf und, ambi-valent hierzu, die damit einhergehenden Entwick-lungsrisiken aller Akteure dieses Vorhabens [1, 2, 3].

Aufgrund des vordringlichen Bedarfs einer Stan-dardisierung von Schnittstellen im Bereich vonLichtsignalanlagen, insbesondere einer Erarbeitungvon Schnittstellenstandards zur Vereinheitlichungder Informationsübertragung zwischen Zentral-rechner(einheiten) und Knotenpunktgeräten sowiezum Informationsaustausch mit Verkehrsingenieur-Arbeitsplätzen [3], konzentriert sich der For-schungsauftrag auf diesen OCIT-Anwendungsbe-reich. Dieser Anwendungsbereich bildet als Kern-stück der Lichtsignalsteuerung ein relevantes Teil-system und Instrument zum städtischen und stadt-peripheren Verkehrsmanagement, insbesondere inverkehrlichen Ballungsräumen [4].

Die Anwendbarkeit respektive Übertragbarkeiteines für Lichtsignalsteuerungssysteme geeigne-ten implementierbaren OCIT auf inner- und außer-städtische Nachbarsysteme der Verkehrstechnik,wie z. B. Parkleitsysteme, Verkehrsbeeinflussungs-anlagen auf Bundesautobahnen etc. zum system-oder gar trägerübergreifenden Verkehrsmanage-mentaufbau, bedarf weitergehender (Grand-de-sign-)Überlegungen in der (Straßen-)Verkehrstech-nik, die zum Anlass und Gegenstand künftiger For-schung werden kann.

Die Aufgabenschwerpunkte im Forschungsprojekt77.437 zur Standardisierung der Schnittstellen vonLichtsignalanlagen sind thematisch eng verknüpftund korrespondieren mit der von der BASt im Auf-trag des BMVBW hierfür übernommenen Gesamt-moderation. Der Forschungsbeginn erfolgte am

01.08.2000 zu einem Zeitpunkt und im Stadiumeines von mehreren Interessengruppen gemeinsaminitiierten, jedoch zeitlich und inhaltlich unter-schiedlich begonnenen und damit betreiberherstel-lerübergreifend unabgestimmten Entwicklungspro-zesses.

Die Forschungsaufgabe konzentrierte sich daherauf

· Zusammenführung der Arbeiten der einzelnenInteressengruppen OCA, ODG, OTEC und VIV,um unabgestimmte Einzelentwicklungen zu ver-meiden,

· Herbeiführung eines Entwicklungskonsens beikontroversen Vorstellungen auf Hersteller-und/oder Betreiberseite einschließlich hierzu er-forderlichem Projektmanagement und

· Organisationsaufbau,

· fortlaufende Dokumentation der erreichtenStandardisierungsstufen,

· Zusammenstellung der erarbeiteten Schnittstel-lendefinitionen zu einem Gesamtdokument,

· fachliche Begleitung und Beurteilung vonSchnittstellentests im Laboraufbau.

Ziel des mit vorliegendem Schlussbericht abge-schlossenen Forschungsprojektes war – zum Ab-gleich unterschiedlicher Hersteller- und Betreiber-interessen auf neutralem Moderationswege – dieEntwicklung einer herstellerübergreifenden, offe-nen und zukunftsorientierten Schnittstelle vonLichtsignalanlagen, insbesondere zwischen Zen-tralrechner und Knotenpunktgerät sowie zwischenZentralrechner und Ingenieurarbeitsplatz, im vor-genannten Aufgabenspektrum fachlich zu beglei-ten und zu beurteilen.

Mit der Erreichung einer bundeseinheitlich aner-kannten und standardisiert einführbaren offenenSchnittstelle als übergeordnetem Ziel soll der freieWettbewerb, auch im Interesse der Straßenbauver-waltung, bei der Beschaffung einzelner Kompo-nenten gesichert werden.

3 Inhalt, Gliederung und Zielset-zung des Schlussberichtes

Die im Forschungszeitraum vom 01.08.2000 bis31.10.2002 abgeschlossenen Ausarbeitungen zurBeschreibung erster so genannter OCIT-Schnitt-

14

stellen im Bereich der Straßenverkehrstechnik er-folgten gemäß dem Forschungsauftrag in engerund aktiver Zusammenarbeit und unter Mitarbeitaller vorgenannten Interessengruppen sowie dervon der BASt eingesetzten forschungsbegleiten-den Betreuungsgruppe.

Der hierzu erforderliche, aufwändige Interessenab-gleich zur Auffindung eines Entwicklungskonsenszur Definition auch für die Weiterentwicklung ge-eigneter OCIT-Basisschnittstellen ist im Anhangdes vorliegenden Schlussberichtes umfassend do-kumentiert. Für Interessierte, die diese Stationender Fachdiskussion auf dem bisherigen Entwick-lungsweg rekapitulieren wollen, sind die Sitzungs-protokolle dem vorliegenden Schlussbericht dortzusätzlich zu den ebenfalls umfangreichen, fach-spezifisch erstellten Schnittstellendokumenten bei-gelegt. Zwischenresumees zur Schnittstellenent-wicklung enthalten der 1. und 2. Zwischenberichtder Forschungsarbeit.

Insgesamt erfolgten im Forschungszeitraum 38 mitExperten der Hersteller- und Anwenderseite durch-geführte Abstimmungssitzungen, davon etwa dieHälfte in Zusammensetzung von Betreibern undHerstellern am so genannten „runden Tisch”, demmittlerweile von und zu der Standardisierungsbe-wegung etabliertem (Streit-)Forum aller Interessen-gruppen.

Hervorzuheben ist das hohe Schnittstellenengage-ment aller Akteure, das beträchtliche finanzielle In-vestitionen bereits in die konzeptionelle Entwick-lung von OCIT-Schnittstellen auf der Herstellerseiteebenso wie zeitliche Aufwendungen zur bedarfsge-rechten Anforderungsprofilierung dieser Schnitt-stellen auf der Betreiberseite abverlangt. OhneBerücksichtigung der für die Geräteneuentwick-lung/-anpassung entstehenden Folgekosten lässtsich bei Monetarisierung des Gesamtaufwandesmit konservativer Schätzung bis dato ein Betragoberhalb 1 Million Euro belegen.

Mit weltweiter Publikation via Internet der im Ge-meinschaftswerk von Herstellern und Betreibernerarbeiteten Version 1 – Dokumentationen eines sogenannten OCIT (= Open Communication Interfacefor Road Traffic Control Systems) als offeneSchnittstelle für die Straßenverkehrstechnik zumSeptember 2002 ergeben sich im Verbund mit derim Bereich der Datenverarbeitung und der Tele-kommunikation in den vergangenen Jahre schnellfortgeschrittenen Entwicklung neue Perspektiven

für die Verkehrssteuerung, insbesondere in lichtsig-nalgeregelten Straßennetzen.

Aus Sicht der Betreiber solcher Systeme, die Licht-signalsteuerungssysteme in ein städtisches oderregionales Verkehrsmanagement zu integrieren be-absichtigen, resultier(t)en mit dem Markteintritteines OCIT – nach EU-kartellrechtlicher Genehmi-gung zum 01.04.2001 – Fragen im Hinblick auf eineden Verkehrsproblemen adäquaten wie zukunfts-stabilen technischen Ausstattung des Verkehrsbe-triebes. Da mit der Fertigstellung und Publikationder OCIT-Schnittstellenbeschreibung, deren Pra-xiseinführung nunmehr unmittelbar ansteht, sichdie Festlegung von Schnittstellenstandards zu-nächst grundsätzlich in den Widerspruch einer ak-tiven technischen Weiterentwicklung begibt, dievorhersehbar im Bereich der Informations- undKommunikationstechnologien weiterhin rasantfortschreiten wird, ist bei der Festlegung auf einenSchnittstellenstandard besondere Weitsicht gebo-ten. Dies gilt für den Bereich von Lichtsignalanla-gen in besonderem Maße, da aufgrund begrenzterFinanzressourcen die Lebenszyklen der zur Licht-signalsteuerung erforderlichen Gerätschaften über-wiegend im dekadischen Jahrrhythmus ablaufen.

Unstrittig besteht jedoch gerade in der Standardi-sierung einer offenen Schnittstelle die Vorausset-zung zur Öffnung eines freien Wettbewerbes derSystem- und Komponentenhersteller. Mittels ge-eigneter Herstellerproduktmischung, und damitkompositionellen Verfahren, ergeben sich hierausnicht nur mehr Auswahlmöglichkeiten, die räum-lich-zeitlich wie in ihrer Ausprägung unterschiedlichauftretenden Verkehrsproblematiken mit effiziente-rem finanziellen Mitteleinsatz zu lösen, sondernauch mit gleichzeitig höherem Gesamtnutzen. Zu-mindest ergeben sich Optionen, nutzenadditiv Ziel-und Performanzkomponenten bedarfsvariabler zugestalten.

Hinsichtlich der Entwicklung geeigneter Beschaf-fungsstrategien war daher beginnend mit derAnkündigung des OCIT-Markteintrittes, nicht zu-letzt auch aufgrund der Mittelknappheit der Kom-munen, zunehmend zu beobachten, dass die Be-treiber von städtischen Verkehrssteuerungen undVerkehrsmanagementeinrichtungen hierfür – nacheiner eingehenden verkehrlichen und verkehrs-technischen Analyse der Bestands- und Planungs-gegebenheiten – konkreter katalogisieren, welcheSystemeigenschaften und welche Ausprägungender Schnittstelle für eine nachhaltige Ausstattung

15

zum Betrieb ihres stadtspezifischen Lichtsignal-steuerungssystems respektive Verkehrsmanage-ments relevant sind.

Für deren Auswahl war und ist grundsätzlich zu be-achten, dass sie, insofern sich das Potenzial eineroffenen Schnittstelle im Bereich der Verkehrstech-nik standardisiert entfalten soll,

· verkehrsproblemrelevant sind,

· die Systemeigenschaften vom Betreiber beein-flussbar sowie

· untereinander unabhängig sind,

· die Eigenschaftsausprägungen realisierbar und

· in einer kompensatorischen Beziehung zueinan-der stehen,

· keine Ausschlusskriterien (K.O.-Kriterien) bin-den und

· die Anzahl der Systemeigenschaften/Ausprä-gungen überschaubar bleibt.

Sieht man die Systemeigenschaften/Ausprägun-gen einer offenen Schnittstelle als Zielstimuli zurLösung der aktuellen wie künftig vorrangigen Ver-kehrsprobleme aufgrund staubedingter Störfälle,Verkehrsüberbelastungen, Unfälle und Baustellen-situationen, besteht bei Durchführung eines Ab-stimmungsprozesses unter Beteiligung von Betrei-bern und Herstellern die Möglichkeit, eine Teilmen-ge von Systemeigenschaften zu finden, die ein voll-ständiges Design einer Basisschnittstelle im Be-reich von Lichtsignalanlagen nicht ausschließt und– z. B. im Selbstverständnis eines funktionalenDaten-bottom-up aus der Feldebene – auch künfti-ge Standards im Bereich des Verkehrsmanage-ments repräsentiert ergänzt.

Hierbei besteht betreiber- und herstellerindividuellwie im (bundesweit) standardisierenden Modus,und somit abhängig von den weiteren Standardi-sierungszielen, grundsätzlich die Möglichkeit, denDesignprozess iterativ durch entwicklungsinkre-mentell unterschiedliche (z. B. mittels auf der Zeit-achse variierter Komposition der verkehrsrelevan-ten Teilnutzen, die sich für die relevanten Schnitt-stelleneigenschaften in Relation zur Ziel- und Per-formanzebene ergeben) und – unter Einbeziehungder Experten (Hersteller und Betreiber) – vereinheit-lichte Folgeversionen der standardisierten Basis-schnittstelle fortzusetzen. Die betreiber-hersteller-übergreifende Konsensfindung zur Schnittstellen-

definition differenziert nach Bereichen, Realisie-rungsstufen und hierzu geeignetem basic frame-work für den originär forschungsgegenständlichenAnwendungsbereich von Lichtsignalanlagen aufdem Hintergrund von Verkehrsmanagement-Anfor-derungen erfolgte entsprechend diskussionsinten-siv.

Ziel des vorliegenden Schlussberichtes ist es, demkünftigen Betreiber und Nutzer von OCIT-fähigenKomponenten und Netzwerken, vor allem dem Be-treiber von Lichtsignalanlagen, die wesentlichenMerkmale und Eigenschaften erster, im Gemein-schaftswerk von OCA, ODG, OTEC und VIV ent-standenen und während des Forschungsprojektsim Auftrag des BMVBW von der BASt als Gesamt-moderator, unterstützt durch den Forschungsneh-mer, begleiteten OCIT-Schnittstellen aufzuzeigen.Dies mit der mit diesen Schnittstellen verbundenenund zugrunde liegenden Organisation und Strukturgeordnet nach relevanten technischen, rechtlichenund organisatorischen Aspekten. Berichtet wirdzudem über die im Rahmen des Forschungsprojek-tes mit Herstellerfirmen durchgeführten Labortestsder Schnittstellen.

Die Schlussberichtsfassung abstrahiert bewusstdie detailliert dargestellten Schnittstellenbeschrei-bungen, um Tautologien zu vermeiden. Vielmehr istdas Anliegen des Schlussberichtes, auch demNicht-Datenübertragungsexperten in verständli-cher Ausdrucksweise als Wegweiser und Leitfaden(Vademekum) durch diese komplexe Schnittstel-len-Gesamtdokumentation zu dienen.

Die in dem vorliegenden Schlussbericht einge-brachten Hinweise zur Standardisierung von Licht-signalanlagen mit OCIT-Schnittstellen können undsollen somit dem Betreiber und Nutzer solcherSchnittstellen den Entscheid der Beschaffung nichtabnehmen, sondern ausschließlich zur Verbesse-rung seiner Entscheidungsgrundlagen dienen.Ebenso kann die im weiteren Standardisierungs-prozess noch zu erwartende anwachsende Zahlvon OCIT-Dokumenten weder abgelöst noch er-setzt werden. Im Ausblick des Schlussberichteswird dies mit der über das Forschungsprojekt hi-nausgehend geplanten Weiterentwicklung derSchnittstellen verdeutlicht. Dieser Ausblick setztauf der fachlichen Einordnung der bisherigen Stan-dardisierungsergebnisse auf.

Das vorliegende Gesamtdokument liefert damit inZusammenfassung der bisherigen Schnittstellener-gebnisse mit Stand September 2002 einen Einstieg

16

in die Thematik von OCIT. Sie ist primär gedacht fürAnlagenbetreiber, die künftig offene Schnittstellenim Bereich von Lichtsignalanlagen implementieren,z. B. im Zuge von

· Neu- und Ersatzerrichtungsmaßnahmen,

· Aufrüstungsmaßnahmen zur Beseitigung vonGeräte- und Übertragungsengpässen zur Ver-kehrsdatenerfassung,

· Maßnahmen zur Erweiterung der Kommunikati-onswege mit neuen Übertragungsmedien wieFunk, städtische Glasfasernetze etc.

4 Ergebnisstand September 2002der Standardisierung offenerSchnittstellen der Straßen-verkehrstechnik im Bereichvon Lichtsignalanlagen (Vademekum)

4.1 Entwicklungsanforderungen an eineoffene Schnittstelle für Lichtsignal-anlagen

Vor den organisatorischen Grundlagen des Stan-dardisierungsprozesses werden im Folgenden dietechnischen Anforderungen an eine offene Schnitt-stelle erläutert. Zum besseren Verständnis der ak-tuellen Entwicklungen – hierzu bewusst, ohne demLeser spezifisches Fachwissen abzuverlangen –werden wichtige verkehrs- und nachrichtentechni-sche Grundlagen allgemein zusammengefasst. Zurweiteren Erleichterung des Lesestoffes befindetsich im Glossar eine ergänzende Nomenklatur rele-vanter Fachtermini. Ein Verzeichnis erläutert dieverwendeten Abkürzungen.

4.1.1 Allgemein gültige Anforderungen an offene Schnittstellen

Schnittstellen werden generell nach DIN 44300 als„(...) Übergang an der Grenze zwischen zweigleichartigen Einheiten mit vereinbarten Regeln fürdie Übergabe von Daten oder Signalen” definiert.„Solche – auch nicht gleichartigen – Einheiten, zwi-schen denen ein Informationsaustausch stattfindet,können

· Hardware-Komponenten,

· Datenübertragungseinrichtungen,

· Programmbausteine und

· im weiteren Sinne die Benutzeroberfläche

sein.”

Die in der Schnittstellendefinition erwähnten „ver-einbarten Regeln” könnten auch durch den Begriff„Standard” ersetzt werden. Standardisierungsakti-vitäten werden u. a. von Organisationen wie Inter-national Standard Organization (ISO) oder Deut-sches Institut für Normung (DIN) durchgeführt.

Ziel der Standardisierungsbemühungen beiSchnittstellen sind „Open Systems Interconnec-tion” (OSI), d. h. offene Kommunikationssysteme.Sie sollen eine Kommunikation zwischen verschie-denen Rechnern, Betriebssystemen und Netzwerk-modellen ermöglichen. Hierbei bedeutet der Begriff„offen”, dass die einzelnen Kommunikationspart-ner durch die Nutzung gemeinsamer Standards(Schnittstellendefinitionen) in der Lage sind, Infor-mationen miteinander auszutauschen, d. h., die Systeme sind für diese Art der Kommunikationoffen. Dies ist nicht mit offener Kommunikationgleichzusetzen. Offene „verstehbare” Informationbedingt daher in Syntax und Semantik der Infor-mationsdarstellung vereinbarte und definierte Re-geln (Standards).

Folglich muss jeder Hersteller einer offenenSchnittstelle hinsichtlich Hard- und Software ver-bindliche Festlegungen einhalten für

· Systemarchitektur und Designregeln,

· Kommunikationsmedien und Protokolle,

· Gerätefunktionen, Betriebs- und Versorgungs-daten.

4.1.2 Allgemeine (funktionale) Anforderungenan offene Schnittstellen für Geräte derStraßenverkehrstechnik im Bereich vonLichtsignalanlagen

Für die Entwicklung einer offenen Schnittstelle vonLichtsignalanlagen ist zunächst erforderlich, denrelevanten Bedarf an derzeitigen und zukünftig zuerwartenden Informationen zu untersuchen. DieDatenvernetzung von Lichtsignalanlagen an (funk-tional) übergeordnete Zentralsteuerungssysteme(z. B. Verkehrsrechner mit integriertem oder ange-schlossenem Verkehrsingenieurarbeitsplatz) dientzur Fernsteuerung und Fernüberwachung vonLichtsignalanlagen, der Fernversorgung der Licht-signalanlage sowie zur Erfassung von Daten zur

17

Verkehrssteuerung und Verkehrsüberwachung. DerBedarf an Informationsübertragung für die offeneSchnittstelle kann demgemäß beispielsweise wiefolgt untergliedert werden:

· Übertragung von Daten für die Betriebsführung,

· Übertragung von Verkehrssteuerungsdaten,

· Übertragung von Daten zur verkehrstechni-schen Analyse,

· Übertragung von Daten für Fernversorgung undParametrierung,

· Übertragung von Daten zur ÖPNV-Erfassungund -diagnose,

· zusätzliche Informationen.

Zum Übertragungsaustausch von Befehlen, Mel-dungen und Daten mit zentralen Kommunikations-stellen lassen sich für den Bereich der

· Steuergeräte und

· Verkehrsingenieurarbeitsplätze

18

Bild 1: Funktionalitäten eines Steuergerätes (exemplarisch);Quelle: OCIT-Gruppe

Bild 2: Funktionalitäten eines Verkehrsingenieur-Arbeitsplatzes(exemplarisch); Quelle: OCIT-Gruppe

Forderungen an die Funktionalitäten profilieren.Solche Anforderungen an die Funktionalitäteneines Steuergerätes zeigt abstrahiert und exempla-risch Bild 1.

Einen entsprechenden Funktionenspiegel in eben-falls stark vereinfachter, exemplarischer Darstel-lungsweise für einen Verkehrsingenieur-Arbeits-platz zeigt Bild 2.

Eine Strukturierung der Informationsübertragung inFunktionsebenen kann nach unterschiedlichen Kri-terien (z. B. physikalisch, logisch oder Steuerung)erfolgen. Bild 3 zeigt ein Beispiel für den hierarchi-

schen Aufbau eines Verkehrssteuerungssystemsnach strategischen, operativen und taktischen Kri-terien.

Aus historischen Gründen benutzen bestehendeSysteme für jede Übertragungsebene bislang spe-zielle Übertragungstechniken und Protokolle sowieangepasste Nutzdaten.

Ansätze zur Öffnung derartiger Systeme wurdenbereits 1993 durch den von der US-amerikani-schen Federal Highway Administration 1993 initi-ierten Versuch unternommen, eine nationale Archi-tektur für intelligente Transportsysteme (ITS) zu

19

Bild 3: Hierarchischer Aufbau und Datenkommunikation eines Verkehrssteuerungssystems; Quelle: BASt

entwickeln. 1995 wurden diese ITS-Standards ver-öffentlicht und vehement kritisiert. Wesentliche Kri-tik an der (unter wesentlicher Beteiligung von immilitärischen Bereich tätigen Firmen) entwickeltenITS-Architektur war, dass sie nur bei streng hierar-chischen Entscheidungsstrukturen möglich sei, wiesie außerhalb des militärischen Bereiches in derRegel nicht gegeben sind. Gefordert wurde statt-dessen eine offene Architektur, die folgende Forde-rungen erfüllt [5]:

· Berücksichtigung der Anforderungen der Ge-bietskörperschaften,

· Wiederverwendung bestehender Infrastruktur,

· Beibehaltung bereits bestehender räumlich be-grenzter Standards,

· gute Bedienbarkeit in Abhängigkeit von denvorhandenen personellen Ressourcen und

· Anpassung an die verfügbaren Haushaltsmittel.

Die einzig notwendige Standardisierung soll da-nach im Bereich der Datenprotokolle erfolgen, umeinen reibungslosen Informationsaustausch zu ge-währleisten. Dabei gilt der Grundsatz, dass dieNutzung bestehender, anwendungsunabhängigerStandards der Schaffung von neuen, anwendungs-bezogenen Standards vorzuziehen ist.

Auf derartige schnittstellenrelevante Entwicklungenin der Verkehrs- und Kommunikationstechnik wirdim Folgenden kurz eingegangen.

4.1.3 Schnittstellenrelevante Richtlinien, Merk-blätter und Forschungsprojekte

In Deutschland sind Herausgeber technischer Hin-weise, Merkblätter und Richtlinien für den Ver-kehrsbereich überwiegend „Der Bundesminister fürVerkehr, Bau- und Wohnungswesen (BMVBW)”, die„Bundesanstalt für Straßenwesen” (BASt) und die„Forschungsgesellschaft für Straßen- und Ver-kehrswesen”. Ergänzt werden diese durch DIN-Normen für technische Ausrüstung und deren In-standhaltung.

Die „Richtlinien für Lichtsignalanlagen (RiLSA) [6]sind die wichtigste Unterlage für die Einrichtungund den Betrieb von Lichtsignalanlagen. Sie ent-halten wesentliche Angaben für die Konzeptioneiner Lichtsignalanlage, die Steuerungsverfahrenund die Berechnung von Signalprogrammen. De-taillierte Angaben über die Kommunikation zwi-schen verkehrstechnischen Komponenten (in-

tern/extern) bzw. die Gestaltung von Schnittstellensind in den RiLSA nicht enthalten. Stattdessen wirdhinsichtlich der Anforderungen an die elektrotech-nische Ausführung der Anlagenteile, insbesondereder Signalsicherung, sowie der Anforderungen andie Instandhaltung auf die DIN VDE 0832 [7] ver-wiesen. Bei den Steuerungstechniken, Gerätear-ten, Steuerzentralen und Übertragungseinrichtun-gen wird auf das „Merkblatt über Schalt- und Steu-ergeräte für Lichtsignalanlagen” [8], das „Merkblattüber Verkehrsrechner” [9] bzw. das „Merkblatt zurÜbertragung von Daten, Befehlen und Meldungenbei Verkehrsrechnern und Lichtsignalanlagen” [10]verwiesen. Mittlerweile ersetzen die „Hinweise zuVerkehrsrechnern als Bestandteil der innerörtlichenLichtsignalsteuerung, Ausgabe 2001” [11] das„Merkblatt über Verkehrsrechner“, Ausgabe 1981[9] sowie das „Merkblatt über Steuerungssystemefür Lichtsignalanlagen in innerörtlichen Straßennet-zen, Ausgabe 1978” [12].

Weit gehend eindeutige technische Vorgaben fürSchnittstellen auf einem relativ aktuellen Niveau lie-gen dagegen für die Ausrüstung des Bundesfern-straßennetzes mit Verkehrs- und Umfelddatener-fassungseinrichtungen vor. Sie wurden bereits mitdem Ziel entwickelt, Geräte unterschiedlicher Her-steller vom Leistungsumfang her weit gehend iden-tisch und damit auch im Wettbewerb miteinandervergleichbar zu erhalten.

Das „MerkbIatt für die Ausstattung von Verkehrs-rechnerzentralen und Unterzentralen (MARZ)” [13]enthält hierzu alle notwendigen Festlegungen wieAufgaben der Zentralen, Beschreibung der ver-kehrstechnischen Anforderungen, Anforderungenan Hard- und Software, Art der Datenübertragungzwischen den Zentralen. Ergänzt wird es durch die„Technischen Lieferbedingungen für Streckensta-tionen (TLS)”, die aktuell mit einer Ausgabe im Ok-tober 2000 [14] fortgeschrieben wurden.

1995 war von der BASt das Forschungsprojekt„Einsatzmöglichkeiten und -grenzen herstellerge-mischter Steuerungssysteme und Erarbeitungeines ersten Anforderungsprofils an einen Schnitt-stellenstandard” [3] vergeben worden. Der größteHandlungsbedarf für eine Standardisierung derSchnittstelle wurde danach zwischen Zentralrech-ner und Knotenpunktgerät sowie zwischen Zentral-rechner und Verkehrsingenieurarbeitsplatz gese-hen. Darüber hinaus sei eine Fortschreibung derVÖV/VDV-Richtlinien dringend erforderlich.

20

Im Anschluss daran wurde von der BASt das Pro-jekt „Standardisierung und Modularisierung ver-kehrstechnischer Grundprobleme in der Lichtsig-nalsteuerung” [1] beauftragt. Hauptziel des Projek-tes war die Entwicklung von Anforderungen an dieFestlegung der Funktionalität und die Beschrei-bung der Handhabung von universell einsetzbarenSoftware-Modulen für die verkehrsabhängigeLichtsignalsteuerung. Hiermit sollte die Basis füreine weitestgehend planer- und herstellerunabhän-gige sowie einheitliche Behandlung verkehrstech-nischer Problemstellungen bei der Entwicklung vonLichtsignalsteuerprogrammen geschaffen werden.Ergebnis des Projektes waren Vorschläge für eineModulspezifikation, die zukünftig dem Standard füreine Steuerlogik zugrunde gelegt werden können.

Zusammenfassend ist festzustellen, dass für die in-nerstädtische Verkehrstechnik hinsichtlich internerund externer Schnittstellen keine eindeutigen undverbindlichen technischen Vorgaben vorliegen.Zudem sind die teilweise über 15 Jahre alten Un-terlagen nicht auf dem neuesten technischenStand. Für den Bereich der Bundesfernstraßenkonnten bereits Standardisierungsvorgaben fürSchnittstellen erfolgreich entwickelt und durchge-setzt werden. Basierend auf diesen Erfolgen undden Ergebnissen von Forschungsprojekten ist ab-zuleiten, dass die größte Dringlichkeit für die Stan-dardisierung von Schnittstellen zwischen Periphe-rie und der Ebene von Zentralrechnern besteht.

4.1.4 Beispiele schnittstellenrelevanter Ent-wicklungen in der Kommunikations- undVerkehrstechnik

4.1.4.1 Datenaustauschformate

Syntax und Semantik von Daten werden bei derDatenübertragung durch das Datenaustauschfor-mat definiert. Ein aktueller internationaler Standardist die Extensible Markup Language (XML) desWorld-Wide-Web-Konsortiums. XML hat gegen-über der herkömmlichen HTML-Kodierung denVorteil, dass diese erweiterte Beschreibungsspra-che die Struktur der darzustellenden Daten vonderen Gestaltung trennt. Der Standard XML

· stellt ein syntaktisches Grundgerüst für die Be-schreibung von Informationen zur Verfügung,

· ist unabhängig von Art, Hierarchie und Inhaltder Daten und

· ermöglicht das Lesen und Validieren von Datenmit verschiedenen Parsern.

(Anmerkung: Die OCIT-Schnittstellen setzen aufXML auf. Die XML-Basierung wird im Kapitel 4.2.4ausführlich behandelt).

4.1.4.2 Datenübertragungsstandards

Für die Datenübertragung hat sich mit dem so ge-nannten ISO-OSI-Schichtenmodell eine hersteller-neutrale Kommunikationsstruktur, die zur Integra-tion mehrerer Netzprotokolle, heterogener System-welten und Anwendungen erforderlich ist, amMarkt etabliert.

Dieses Kommunikationsmodell hat die ISO 1983 inKooperation mit anderen internationalen Standar-disierungsgremien als Basisreferenzsystem mitdem Titel „Basic Reference Modell for Open Sys-tems Interconnection (OSI)” entwickelt. Dieses Mo-dell ist in der DIN/ISO-Norm 749 definiert.

Ein Kommunikationssystem stellt aus ISO-Sichtdemnach die Verbindung zwischen dem Kommuni-kationsmedium und den Anwendungen dar. Diegrundlegende Anforderung ist, dass beim Daten-austausch zwischen zwei Kommunikationspart-nern beide die Informationen verstehen und gleichinterpretieren. Deshalb wird der Datenaustauschformal definiert. Sollen Komponenten eines Kom-munikationspartners getrennt realisiert und Kom-ponenten verschiedener Hersteller miteinander zueinem Kommunikationssystem gekoppelt werden,ist diese formale Definition der Schnittstellen not-wendig. Das interne Verhalten der Kommunikati-onspartner braucht i. d. R. nicht beschrieben zuwerden.

Zur Gliederung des Kommunikationssystems unddessen Funktionalitäten verfolgt ISO ein Schich-tenkonzept. Jede Schicht nutzt die Dienste der tie-feren Schicht, um ihrerseits mit Hilfe von Protokol-len neue, höherwertige Dienste für die ihr überge-ordnete Schicht bzw. die Anwendungen zu realisie-ren. Die unterste Schicht nutzt direkt das Übertra-gungsmedium. Die Schichten tauschen hierzu Pro-tokolldateneinheiten (PDU) mit ihren Partnerinstan-zen aus. Die Protokollabläufe sind für den Dienst-nutzer nicht sichtbar, die Nutzung erfolgt „transpa-rent”. Hierdurch wird es Anwendungen möglich,ohne Kenntnis der Realisierung der Kommunika-tion Daten auszutauschen. Ebenso wird es mög-lich, für Anwendungen identische Dienste auf un-terschiedlichen Kommunikationsmedien und -plattformen zu realisieren.

21

Die Schichten 1 bis 4 im ISO-OSI-Schichtenmodellsind für die Datenübertragung zwischen den End-geräten zuständig (Übertragungsschichten), dieSchichten 5 bis 7 koordinieren bei der Datenüber-tragung das Zusammenwirken mit dem Anwender-programm und dem Betriebssystem des verwen-deten Rechners (Anwendungsschichten). (Anmer-kung: Die Anwendung des ISO-OSI-Schichtenmo-delles zum Aufbau von OCIT-Schnittstellen wird imKapitel 4.3.1.4 erläutert.)

Seit 1971 wurde für den herstellerneutralen Daten-austausch in heterogenen Netzen das „Transmissi-on Control Protocol (TCP)” im Zusammenhang miteiner speziellen Ausführung der „Internet suite ofprotocols (IP)”, abgekürzt TCP/IP, als allgemein an-erkannter Standard entwickelt. Dieses aus einerAuftragsentwicklung des amerikanischen Verteidi-gungsministeriums entstandene TCP/IP-Protokollist sowohl in lokalen Netzen zur Kommunikationverschiedenartiger Rechner untereinander als auchfür den Zugang von Local Area Networks (LAN) zuWide Area Networks (WAN) einsetzbar [15].

Betrachtet man das TCP/IP-Protokoll in der Denk-weise des OSI-Modells, so umfasst es im weiterenSinne vier logische Schichten: Die oberste Schichtenthält die jeweils gewünschte Anwendung, zumBeispiel File Transfer (FT) oder Virtual Terminal (VT),während die darunter liegende Schicht Diensteklassifiziert, die das Transport Control Protocol(TCP) den verschiedenen Kommunikationsanwen-dungen zur Verfügung stellt. Das sich darunter be-findende Transport Protocol benutzt seinerseits zurÜbertragung zwischen den verschiedenen Knoteneines Netzes das Internet Protocol (IP), das einenDienst zur Übertragung von Datenpaketen zwi-schen Sender und Empfänger über das Internetrealisiert. Die letzte Schicht ist schließlich für dieAnpassung des Internet Protocols an das darunterliegende Netz zuständig [16]. (Anmerkung: DieTCP/IP-Protokollanwendung zu OCIT-Schnittstel-len wird im Kapitel 4.3.1.5 ausführlich behandelt).

4.1.4.3 Netzwerktopologie

Werden mehrere Teile eines Verkehrssteuerungs-systems miteinander verknüpft, entsteht ein Netz-werk. Unter dem Begriff Netzwerktopologie sindhierbei zum einen die logische Anordnung der Teil-nehmer (unabhängig von der Geometrie) und zumanderen die geometrische Anordnung der Teilneh-mer im Netzwerk zu verstehen.

Geometrische Anordnungsmöglichkeiten bestehenin

· Zweipunktverbindungen,

· Busstruktur (Linienstruktur),

· Baumsstruktur,

· Ringstruktur und

· Sternstruktur.

Die einfachste Möglichkeit, Daten auszutauschen,besteht darin, zwei Kommunikationspartner übereine Leitung zu verbinden, wie z. B. bei einemModem oder der Verbindung zwischen PC undDrucker. Die notwendige Steuerung eines Kommu-nikationsprozesses in Zweipunktverbindung ist imso genannten Handshake-Betrieb über Steuer-,Melde- und Taktleitung realisierbar.

Werden mehrere Teilnehmer mit Zweipunktverbin-dungen verknüpft, entsteht ein vermaschtes Netz.Bei dieser Topologie besteht dann zwischen zweikommunizierenden Teilnehmern eine Zweipunkt-verbindung. Dabei werden (n-1) Schnittstellen proTeilnehmer und (n) Verbindungsleitungen benötigt.Daraus resultiert

2

ein entsprechend hoher Kosten-proporz. Im Falle eines Fehlers würde theoretischjedoch entweder nur ein Teilnehmer oder nur einKommunikationskanal ausfallen, und die Fehler-diagnose wäre relativ einfach.

Sollen Zweipunktverbindungen Kosten sparendvon mehr als zwei Teilnehmern benutzt werden,müssen Maßnahmen getroffen werden, die einegegenseitige Signalbeeinflussung und damit Zer-störung der Signale verhindern. Möglichkeiten, diedies verhindern, bestehen im Zeitmultiplex-Verfah-ren und Frequenzmultiplex-Verfahren. Wird dasZeitmultiplexverfahren angewendet, handelt essich i. d. R. um eine Basisbandübertragung, da hierdas unmodulierte Signal im Frequenzband von 0 Hz bis zur Grenzfrequenz des Trägermediums zurVerfügung steht. Bei Verwendung des Frequenz-multiplex-Verfahrens wird dagegen ein moduliertesSignal mit einer definierten Bandbreite übertragen.Erfolgt die Nachrichtenübertragung im Zeitmulti-plexverfahren ausschließlich in eine Richtung, be-zeichnet man das allgemein als Simplexbetrieb. Er-folgt die Informationsübertragung nacheinander inbeide Richtungen, handelt es sich i. d. R. um einenso genannten Halbduplexbetrieb. So genannteVollduplexübertragung ermöglicht das Frequenz-multiplex-Verfahren, wenn der Übertragungskanal

22

in voneinander unabhängige Frequenzbänder mitdefinierter Bandbreite eingeteilt wird.

Als Modulationsarten eigenen sich grundsätzlichAmplituden-, Frequenz- und Phasenmodulation,wobei der Vorteil in der optimalen Nutzung desÜbertragungsmediums liegt. Da die zur Modulationbenötigten Baugruppen relativ teuer sind, findetdiese Breitbandübertragung ihre Anwendunghauptsächlich in so genannten Weitverkehrsnetzen(Wide Area Networks, WAN).

Bei der Bus-Struktur, auch Linienstruktur genannt,kommunizieren alle Teilnehmer über eine gemein-same Leitung. Die Anbindung der Teilnehmer andas Buskabel geschieht über kurze Stichleitungen,so genannte Dropkabel. Dadurch wird der Kabel-aufwand, verglichen mit dem vermaschten Netz,erheblich reduziert. Jeder Teilnehmer benötigt hiernur noch eine Schnittstelle, um mit einem beliebi-gen, an den Bus angeschlossenen Teilnehmerkommunizieren zu können. Hier entsteht allerdingsdas Problem, dass immer nur ein Teilnehmer zueinem bestimmten Zeitpunkt senden darf. Somitwerden Regeln notwendig, die das Zugriffsrechtauf den Bus festlegen, so genannte Buszugriffsver-fahren. Bei Verbindung der Busstruktur tretenzudem folgende grundsätzlich Probleme auf:

· Da ein beliebiger Datenverkehr gefordert ist,müssen alle Teilnehmer jede Informationssen-dung „mithören”. Dadurch wird bei steigenderTeilnehmerzahl der Sender immer stärker belas-tet.

· Die Übertragungsstrecken für Feldbussystemeliegen häufig in einem Bereich von wenigenhundert Metern. Damit ist die Leitungslängenicht mehr vernachlässigbar klein gegenüberder zu übertragenden Wellenlänge. Deshalbmuss die Busleitung an beiden Enden mit ihremWellenwiderstand abgeschlossen werden, umReflexionen auf die Leitung zu vermeiden, wel-che die Signalqualität erheblich beeinflussenkönnten. Dieser Abschlusswiderstand belastetebenfalls den Sender.

· Damit der Empfänger eine Änderung des logi-schen Zustandes akzeptiert, muss bei derÜbertragung ein so genannter nicht definierter(i. d. R. erzeugt durch Spannungssprünge derSender zum Informationsübertragungsbeginn)Bereich komplett durchlaufen werden. Dazuwird eine Zeit t benötigt, die von Kabelkennwer-ten (u. a. Induktivitäts- und Leitwertbelag) ab-

hängig ist. Wird die Leitung verlängert, steigenWiderstands- und Kapazitätswert der Leitung,was zur Folge hat, dass auch t anwächst.

In der Praxis hat dies zur Konsequenz, dass diemaximale Übertragungsrate und die maximale Lei-tungslänge miteinander verknüpft sind. HoheÜbertragungsraten und Leitungslänge sind bei Ver-wendung von Lichtwellenleitern (LWL) erreichbar.Jedoch ist in diesem Fall die Ankopplung der Teil-nehmer an eine Busleitung kompliziert und teuer.

Bei der Baumstruktur handelt es sich um eine Wei-terentwicklung der Linienstruktur. Mit dieser Topo-logie sind größere Flächen als bei der Bustopologievernetzbar. Die Ausführungen bzgl. der maximalenLeitungslänge, der maximalen Teilnehmerzahl undder maximalen Übertragungsrate gelten wie bei derBusstruktur. Diese Werte können mit so genanntenRepeatern vergrößert werden. Bei diesen Elemen-ten handelt es sich um Verstärkerelemente, die in-nerhalb der Baumstruktur i. d. R. zur Bildung einesneuen Übertragungszweiges verwendet werden.

Ringstrukturen werden i. d. R. durch mehrere Zwei-punktverbindungen aufgebaut, die einen physikali-schen Ring bilden. Dabei wird die übertragende In-formation von Teilnehmer zu Teilnehmer weiterge-reicht. Auch hier muss ein entsprechendes Buszu-griffsverfahren sichergestellt sein, was die vorbe-schriebenen Nachteile mit sich zieht. Dadurch,dass die Ringstruktur aus Zweipunktverbindungenaufgebaut ist und jeder Teilnehmer als Repeaterwirken kann, sind relativ große Entfernungen über-brückbar. Diese liegen zwischen zwei Teilnehmernbei Verwendung von Lichtwellenleiter im (bis ca.100-)Kilometerbereich, bei gleichzeitig sehr hohenDatenraten. Problematisch ist diese Topologie beiAusfall eines Teilnehmers, Kabelbruch oder sonsti-gen die Ringkommunikation störenden Ausfällen.Ausfallsicherheit wird daher i. d. R. durch redun-dante Ringauslegung hergestellt.

Bei der Sternstruktur ist die Zentralstation mittelsZweipunktverbindung mit jedem anderen Teilneh-mer verbunden. Grundsätzlich bestehen bei dieserTopologie die Möglichkeiten, mit einem so genann-ten Sternkoppler (Hub) oder durch Intelligenzimple-mentation in der Zentralstation zu realisieren. Auf-gabe eines Hubs ist es, die Informationssignaleausschließlich vom Sender zum richtigen Empfän-ger weiterzuleiten. Dabei kann der Hub sowohlpassiv sein als auch aktiv, d. h., die empfangenenInformationssignale werden vor der Weiterleitungnoch aufbereitet. Ist die Intelligenz in der Zentral-

23

station implementiert, hat dies den Vorteil, dassdiese Station den gesamten Kommunikationspro-zess übernehmen kann, der bei einem Hub-Aufbauhierzu im Gegensatz von allen anderen Teilneh-mern vorgenommen werden müsste. Prinzipiell je-doch findet die Kommunikation bei Aufbau einerSternstruktur zwischen zwei Teilnehmern über dieZentralstation statt, die insofern auch einen Eng-pass darstellt. Ein Ausfall dieser Station hat beiAufbau einer Ringstruktur zur Folge, dass die ge-samte angeschlossene Kommunikation ausfällt.

4.1.4.4 Ableitung von (kompatiblen) Anforde-rungen im Schnittstellenbereich vonLichtsignalanlagen

Basierend auf den zuvor erläuterten Anforderungenbenötigen offene Schnittstellen von Lichtsignalan-lagen Festlegungen zu(r)

· Systemarchitektur,

· Kommunikation (Protokolle, Übertragungsein-richtungen),

· den Gerätefunktionen, die über die Schnittstellebeeinflusst werden, und

· den Schnittstellenfunktionen.

Die Kommunikation muss hierbei im Zusammen-hang mit den Gerätefunktionen betrachtet werden.Als Kommunikationsmedien können einfache Erd-kabel aus Kupfer in Frage kommen, aber auchLichtwellenleiter, Funkverbindungen oder neue Me-

dien wie beispielsweise GSM. Eine universell ein-setzbare offene Schnittstelle muss hierbei unab-hängig vom Kommunikationsmedium sein. Für eineflexible Anpassung an neue Anforderungen sollteeine funktionale Erweiterungsmöglichkeit gewähr-leistet sein.

Aus der jeweiligen Informationsübertragung erge-ben sich, abhängig vom jeweils vorhandenen oderzukünftig eingesetzten physikalischen Medium, fürdie Datenübertragung im Volumen und der Datenü-bertragungsgeschwindigkeit unterschiedliche Ka-pazitäten. Um hinsichtlich einer offenen Schnitt-stelle unabhängig vom Übertragungsmedium zuwerden, darf die Übertragungsstrecke nicht mitzeitkritischen Daten belastet werden, sondern diezukünftige Überlastung ist bereits vom Ansatz hervorausschauend zu vermeiden.

Diese Forderung kann durch ein dezentrales, aberauch teilzentrales System erfüllt werden, bei demdie zeitkritischen Steuerungsaufgaben in denGeräten vor Ort wahrgenommen und nicht zwi-schen Zentrale und Gerät über die Schnittstelle ab-gewickelt werden.

Um die Unabhängigkeit von der Netzwerktopologiezu gewährleisten, d. h. beispielsweise die Möglich-keit eines offenen Netzwerkes gemäß Bild 4, müs-sen die Schnittstellenbereiche mit jeder Hardware(d. h. Kommunikationsmedium) realisiert werdenkönnen.

Hierfür müssen standardisierte Kommunikations-modelle verwendet werden. Nach dem aktuellen

24

Bild 4: Beispiel einer offenen Netzwerkarchitektur; Quelle: OCA

Stand der Technik eignen sich hierfür insbesonde-re

· als Datenaustauschformate XML-Strukturen,· das ISO-OSI-Schichtenmodell für die Daten-

übertragung sowie

· Ethernet, LAN- , MAN- oder WAN-Verbindun-gen für die Nutzung aller üblichen Medien undTelekommunikationsdienste für die Datenüber-tragung.

4.2 Hinweise zur Standardisierungeiner offenen Schnittstelle der Verkehrstechnik, insbesondere für Lichtsignalanlagen

4.2.1 OCIT-Systemkonzeption

4.2.1.1 Gültigkeitsbereich und Einsatzgrenzenvon OCIT

Das Akronym OCIT steht für Open CommunicationInterface for Traffic Control Systems (= OffeneSchnittstelle der Straßenverkehrstechnik). OCIT-Schnittstellen bilden die Basis einer offenen Sys-temarchitektur, die sich hauptsächlich an den Anforderungen der städtischen Straßenverkehrs-technik orientiert. Der Standardisierungsprozessschließt neben den Kommunikationsprotokollen dieüber die OCIT-Schnittstellen bedienten Funktionenmit ein. Damit wird der Umfang der Standardisie-rung eindeutig beschrieben. Aufgabengebiete wieDatenbankarchitekturen, Methoden der Software-einbindung, Bedienoberflächen, Applikationen etc.gehören somit nicht zum Prozess. Den Schwer-punkt bilden die standardisierten Verbindungenzwischen verteilten zentralen und dezentralen Kom-ponenten, wie Teilsystemen, Werkzeugen und Feld-geräten. Mit Nutzung der Internettechnologie er-möglichen sie den Aufbau von Verkehrsmanage-mentsystemen und systemweiter Netzwerke, dieFeldgeräte und Zentralen umfassen.

Die Standardisierungsarbeiten an OCIT basierenauf den technischen Systemarchitekturen und vor-liegenden Regelwerken zur Straßenverkehrstechnikin der Bundesrepublik Deutschland. Daraus ergibtsich eine Abgrenzung des Einsatzbereiches auf jeneLänder, die ähnliche Systemlandschaften wieDeutschland aufweisen. Daneben gibt es internatio-nal noch die großen Systemlandschaften UK undUS (z. B. NTCIP) sowie regionale Ausprägungen.Eine internationale Normung unter Einbeziehungdieser Systemlandschaften ist nicht vorgesehen.

4.2.1.2 Eigenschaften der OCIT-Schnittstellen

OCIT-Schnittstellen sind grundsätzlich als „offeneSchnittstellen” konzipiert und ausgelegt. Der Be-griff „offen” bedeutet, dass die einzelnen Kommu-nikationspartner durch die Nutzung gemeinsamerStandards (Schnittstellendefinitionen) in der Lagesind, Informationen miteinander auszutauschen, d. h., die Systeme sind für diese Art der Kommuni-kation offen.

Aus diesem Grund wurde bereits in einer frühenEntwicklungsphase damit begonnen, folgendePunkte eindeutig festzuschreiben [17]:

· Systemarchitektur und Regeln,

· Protokolle der Anwendung,

· Gerätefunktionen und Daten,

· Kommunikation/Übertragungsprotokolle.

4.2.1.3 Systemkomponentenaufbau

Ein so genanntes OCIT-System [17] mit offenenSchnittstellen für den Bereich von Lichtsignalanla-gen besteht aus einer oder mehreren OCIT-Zentra-len und OCIT-Feldgeräten. Zentralen und Feldgerä-te werden über die OCIT-Schnittstellen entspre-chend angeschlossen. Die Feldgeräte müssen zurvollen projektbezogenen Funktionstüchtigkeit nichtden gesamten Funktionsumfang von OCIT-Objek-ten/Funktionen implementiert haben. Zu beachtenist, dass auf der Zentralenseite die funktionalenVorgaben der Feldgeräteversorgung vollständig er-füllt sein müssen, damit alle angeschlossenenOCIT-Feldgeräte, im weiteren als OCIT-Outstationsbenannt, einwandfrei (kommunikativ und funktio-nal) betrieben werden können.

Die physikalische Datenübertragung gehört nichtzum Standardisierungsprozess und ist deshalbgrundsätzlich unabhängig von der Schnittstelle zubetrachten. Für Ethernet, LAN-, MAN- oder WAN-Verbindungen existieren bislang für die OCIT-Out-stations keine Übertragungsprofile (siehe 4.3.1.16).

4.2.1.4 Zentralen

Die Zentralen können aus mehreren Bereichen, wiez. B. Bedienplätze, davon abgesetzte Gebietsrech-ner, Subsysteme und anderen zentralen Teilen, be-stehen. Ihre Hauptaufgaben sind die Betriebs-steuerung und Überwachung der angeschlossenenFeldgeräte.

25

Die Schnittstellen, welche die physikalischen zen-tralen Bereiche (Hardwarekomponenten) unterei-nander verbinden, sind über OCIT bislang nichtfestgelegt. Beispielsweise können jedoch Subsys-teme am LAN der Bedienplätze und die Feldgeräteam Gebietsrechner angeschlossen werden.

4.2.1.5 Feldgeräte

Feldgeräte definieren die Obermenge aller Steue-rungssysteme, die vor Ort verkehrstechnischeMessungen und Schaltungen vornehmen können,ohne unbedingt mit einer Zentrale in Verbindung zustehen. Zeitkritische Steuerungsaufgaben sind beiEinsatz von OCIT in den Geräten vor Ort zu absol-vieren und dürfen gemäß der Spezifikation vonOCIT (kalkulierbares Zeitverhalten im Sekunden-takt durch das deterministische IP-Protokoll nichtgegeben) nicht zwischen Zentrale und Gerät überdie Schnittstelle abgewickelt werden. Für denOCIT-Einsatz können deshalb nur teil-/dezentraleSysteme, d. h., die eingesetzten Feldgeräte verfü-gen über geeignete Prozessoren, die komplexe Ab-läufe lokal beherrschen und entsprechende Verar-beitungen durchführen können, zur Anwendungkommen.

Ein Beispiel derartiger Feldgeräte sind Lichtsignal-steuergeräte für dezentral aufgebaute Systeme, diekomplexe Verkehrsabhängigkeiten lokal beherr-schen und Verkehrsmesswerte erfassen und verar-beiten („intelligente Steuergeräte”). Für den Daten-transfer wird vorausgesetzt, dass für eine in OCITdefinierte Funktion des Lichtsignalsteuergerätesauch eine entsprechende Funktion in der Zentralevorhanden ist und umgekehrt.

Das Steuerverfahren „Signalgruppenfernsteue-rung” wird deshalb durch OCIT in der jetzigen Fas-sung nicht unterstützt, weil die vorhandenenNetzressourcen und das IP-Protokoll eine zeitge-rechte Weiterleitung grundsätzlich nicht garantie-ren können.

Der Einsatz von intelligenten Feldgeräten bedarfhauptsächlich einer modernen Hard- und Soft-warearchitektur. Feldgeräte älteren Datums (Alt-geräte), die bisweilen ausschließlich über die Zen-trale verkehrsabhängig schalten können und an-sonsten reine Festzeitprogramme abarbeiten, wer-den in den meisten Fällen aus wirtschaftlichenGründen nicht mit einer OCIT-Schnittstelle aus-gerüstet werden können. Die neue Schnittstellestellt durch die universelle Netzwerkfähigkeit in derRegel höhere Anforderungen an die bestehende

Leistungsfähigkeit der Gerätehardware. Zudemschränken fehlende Anschlussmöglichkeiten, star-re Programmgebilde oder der Einsatz veralteterProgrammiersprachen die Chance eines OCIT-Up-dates bzw. -Upgrades durch den Geräteherstellerzusätzlich ein.

Die prinzipielle Erweiterung bestehender Anlagenfunktioniert über eine, als OCIT-Vorschaltbaugrup-pe oder als Gerätevorsatz bezeichnete, Baugrup-pe, die je nach Altgerät einen Komponentenaus-tausch, -umbau oder -anbau erfordert. Die neu zuentwickelnden OCIT-Feldgeräte setzen in der Regelkonsequent auf der innerhalb der Informations-technologie (IT) etablierten NetzwerktechnikTCP/IP auf und erfordern somit geringere Aufwän-de im individuellen Hardwaredesign.

4.2.2 Externe Systemzugänge

4.2.2.1 Lokaler Systemzugang

Insbesondere für Wartungszwecke ist im Steuer-gerät eine Anschlussmöglichkeit/physikalischeSchnittstelle für Servicetools vorgesehen, welcheim Gegensatz zu den üblichen Diagnosewerkzeu-gen nicht direkt auf die Speicherinhalte zugreifen,sondern mittels BTPPL-Protokoll mit dem Steuer-gerät Daten austauschen. Dazu wird das Service-tool analog zur Vorgehensweise bei Zentralen undFeldgeräten mit einer in der Regel temporären IP-Adresse ausgestattet, über welche es Daten ver-senden und empfangen kann.

4.2.2.2 Zentraler Systemzugang

Analog zu dem lokalen Systemzugang ermöglichteine externe Schnittstelle an der Zentrale den An-schluss optionaler Geräte, mit denen per BTPPLVerbindungen zum Feldgerätebestand und derZentrale hergestellt werden können, um z. B. dieherstellerspezifische Versorgung der LSA-Steuer-geräte durchzuführen, solange diese Funktionalitä-ten nicht explizit im Verkehrsrechner (VSR) imple-mentiert sind. Die Anbindung erfolgt in der Regelüber das LAN.

4.2.3 Aufbau und Anwendungsbereiche derOCIT-Schnittstellen

Geräte und Software-Komponenten der Straßen-verkehrstechnik werden innerhalb eines OCIT-Systems über drei grundsätzliche Schnittstellenuntereinander angebunden (siehe Bild 5), der sogenannten

26

· OCIT-Control,

· OCIT-Instations (OCIT-I),

· OCIT-Outstations (OCIT-O).

Innerhalb des Feldgeräts ist die Schnittstelle OCIT-Control als Gegenstand künftiger Standardisierunggeplant. Sie wird unter funktionaler Betrachtungzwischen Gerätetechnik und zentraler Verkehrs-technik anzuordnen sein. Der Sinn und Zweck die-ser Schnittstelle wertden evident, wenn die gegen-wärtige Versorgung von standardisierten, externenSteuerungsverfahren begutachtet wird: Im Regel-fall muss jeder Steuergerätehersteller für die inFrage kommenden Steuergeräte gerätespezifischeAnschlussmöglichkeiten soft- und hardwaretechni-scher Natur festlegen, um die Implementierung zuermöglichen. Jedes Steuerungsverfahren kannunter ungünstigen Umständen einen eigenen An-schlussplan vorsehen. Ergeben sich durch Up-grades/Updates des Steuerungsverfahrens neueAusgangsbedingungen, die nicht mehr konform mitder vorherigen Anbindung sind, muss der Herstellerdies unter Berücksichtigung der Wirtschaftlichkeitentsprechend für jede involvierte Gerätefamilie an-passen. Der Betreiber schränkt sich zurzeit durchdie Wahl eines bestimmten Steuerungsverfahrens

bei seinen Geräten meist selbstständig ein, weil füreinen eventuellen Umstieg auf ein anderes Verfah-ren die gesamte verkehrstechnische Steuerung imExtremfall ersetzt werden müsste. Die konzeptio-nellen Überlegung ergaben daher, künftig eine stan-dardisierte Geräteschnittstelle einzurichten, überdie die Implementierung von Steuerungsverfahrenund Anwendungssoftware beliebiger Herstellerüber Application-Sockets1 vollzogen werden kann.

OCIT-Instations sind standardisierte Schnittstellenzwischen zentralen Komponenten und Systemen.Wesentliches Merkmal der OCIT-Architektur ist es,dass all diese Schnittstellen am „Rand” der Zentra-le, die als Einheit gesehen wird, angesiedelt sind.Es ist im Realisierungskonzept daher nicht vorge-sehen, alle denkbaren Schnittstellen, die zwischenden Komponenten innerhalb der Zentrale vorhan-den sind, zu erfassen (siehe hierzu auch Kapitel4.3.2).

OCIT-Outstations sind standardisierte Schnittstel-len mit dem Anwendungsbereich zwischen Zentra-le und Feldgeräten sowie als zentrale und lokaleSystemzugänge für Servicetools. Anmerkung: Aus-führliche Informationen zur technischen Spezifika-tion befinden sich im Kapitel 4.3.1.

4.2.4 Datenbeschreibungssprache XML

XML (eXentsible Markup Language) ist eine Meta-sprache, mit deren Hilfe sich eigene neue Spra-

27

Bild 5: Schnittstellenbereiche und Systemarchitektur von OCIT; Quelle: OCA/ODG

1 auf eine Anwendung/Programm zugeschnittene Program-mierschnittstelle

chen zur Gliederung von Daten definieren lassen.Über vorher festgelegte projektbezogene Aus-zeichnungen (engl. Markups) sind inhaltliche Struk-turierungen von Informationen in Dokumentendurchführbar. Dokumentenstrukturen sind damit inihrer Komplexität an die erforderlichen Informatio-nen anpassungsfähig.

Auf die wesentlichen Stärken von XML beschränkt,ergeben sich folgende prägnante Vorzüge:

· flexible Datenstruktur,

· Plattformunabhängigkeit,

· Textorientiertheit (ASCII).

Die projektspezifischen Grundregeln für die Struk-tur eines Dokuments werden intern (im Dokumentselbst) oder extern (als eigenständige Datei) ineiner DTD (Document Type Definition) einmaligfestgelegt. Darauf aufsetzende XML-Dokumentelassen sich jederzeit anhand ihrer DTD bezüglichihrer „Gültigkeit” durch einen validierenden Parseroder eine Applikation überprüfen. Nicht validieren-de Parser prüfen nur die Wohlgeformtheit des Do-kuments.

Ein Dokument besitzt Gültigkeit, wenn folgendeForderungen erfüllt werden:

· Dokument ist „wohlgeformt”,

· eine interne/externe DTD existiert,

· Dokument ist in Bezug auf die in der DTD auf-gestellten Regeln gültig.

Die Wohlgeformtheit eines Dokuments besagt,dass sich das vorliegende Konstrukt vollständig andie offiziellen Regeln des W3C zur Erstellung vonXML-Dokumenten hält:

· Das Dokument besteht aus einem Prolog undmindestens einem umschließenden Wurzelele-ment.

· Alle Wohlgeformtheitsbeschränkungen der Spe-zifikation treffen zu.

· Eingesetzte Elemente sind korrekt ineinanderverschachtelt.

Mit der XML-Schema-Sprache [18], die selbst inXML 1.0 dargestellt ist und deren Namensräumeverwendet, werden die Ausdrucksmöglichkeitender XML 1.0 DTD durch ein abstraktes Datenmo-dell beträchtlich erweitert. Der Zweck eines Sche-mas zeigt sich in der Definition und Beschreibung

einer Klasse von XML-Dokumenten durch Verwen-dung von Schemakomponenten. Diese Schema-komponenten schränken die Bedeutung, den Ge-brauch und die Beziehungen der Bestandteile – Datentypen, Elemente und ihr Inhalt, Attributeund ihre Werte – der Schema-(XML-)Dokumenteein und dokumentieren diese. Schemata könnenauch die Spezifikation zusätzlicher Dokumentinfor-mationen, wie beispielsweise Normalisierung unddie Vorgabe von Attribut- und Elementwerten, bie-ten. Jede Anwendung, die wohlgeformtes XML ver-arbeitet, kann den Formalismus von XML-Schema-Strukturen verwenden, um syntaktische, strukturel-le und Wertebereich-Beschränkungen auszu-drücken, die auf ihre Dokumentinstanzen anwend-bar sind. Der Formalismus von XML-Schema-Strukturen ermöglicht das Beschreiben und Imple-mentieren von Beschränkungsprüfungen für einbreites Spektrum von XML-Anwendungen.

4.3 Aktueller Ergebnisstand der OCIT-Entwicklungstätigkeiten

4.3.1 OCIT-Outstations

Die nachfolgenden Aussagen beziehen sich aus-schließlich auf die Ende September 2002 publizier-te OCIT-Outstations Version 1. Es gilt zu beachten,dass im Rahmen von OCIT standardisierte Schnitt-stellen definiert wurden und nicht der spezielleFunktionsumfang eines einzelnen Gerätes. Im Klar-text bedeutet dies, das in OCIT-Outstations-kon-formen Geräten eine Mindest- und Basisfunktiona-lität von OCIT vorauszusetzen sind, der restlicheAusbau der Systemeigenschaften und -fähigkeitenhingegen von den aktuellen Projektanforderungabhängt.

4.3.1.1 Begriffsdefinitionen

Die technischen Dokumente zur OCIT-O nutzenbzw. verwenden naturgemäß vielfach Fachtermini,die besonders aus der objektorientierten Program-mierung oder allgemein aus der IT-Branche ent-stammen. Neben verkehrstechnischen Termini(siehe hierzu auch Nomenklatur im Glossar) werdenvielfach Begriffe wie „Methoden“, „Objekte” etc.benutzt, die nachfolgend kurz erläutert werden.

Objekt

Documents

New Standardisierung der Schnittstellen von Lichtsignalanlagen · 2018. 11. 15. · Standardisierung der Schnittstellen von Licht-signalanlagen Systeme und Geräte der Straßenverkehrstechnik,