Ocit-O Protokoll v3.0 A01 PDF

Open Communication Interface for Road Traffic Control Systems
Offene Schnittstellen für die Straßenverkehrstechnik
OCIT-Outstations
Regeln und Protokolle
OCIT-O_Protokoll_V3.0_A01
OCIT Developer Group (ODG)

OCIT® ist eine registrierte Marke der Firmen AVT-STOYE, Siemens, Stührenberg und SWARCO
OCIT-Outstations
Regeln und Protokolle
Dokument: OCIT-O_Protokoll_V3.0_A01
Herausgeber: OCIT Developer Group (ODG)
Kontakt: www.ocit.org
Copyright  2018 ODG. Änderungen vorbehalten. Dokumente mit Versions- oder Ausgabestände
neueren Datums ersetzen alle Inhalte vorhergehender Versionen.
OCIT-O_Protokoll_V3.0_A01 Seite 2 von 67

Inhaltsverzeichnis
Spezifikationen ........................................................................................................... 7
1 Einführung ............................................................................................................ 8
1.1 Systemgrenzen .............................................................................................. 8
2 Schnittstellen und Systemfunktionen OCIT-Outstations ....................................... 9
2.1 Zentrale Ebene ............................................................................................ 10
2.2 Datenübertragung und Protokoll .................................................................. 10
2.3 Feldgeräte .................................................................................................... 11
3 Kommunikationsmodell OCIT-Outstations ......................................................... 12
3.1 Sicherung der Übertragung .......................................................................... 13
3.1.1 Sicherheitsalgorithmus .................................................................... 13
3.1.2 Firewall ............................................................................................ 13
3.2 Adressen ...................................................................................................... 14
3.3 IP-Netz ......................................................................................................... 14
3.4 Routen ......................................................................................................... 14
3.5 Zeitverhalten ................................................................................................ 14
3.5.1 Systemzeit ....................................................................................... 15
3.5.1.1 Feldgeräte mit permanenten Datenverbindungen zur Zentrale ....... 15
3.5.1.2 Feldgeräte mit temporären Verbindungen zur Zentrale ................... 15
3.5.2 Ereignisorientierte Übertragung ...................................................... 16
3.5.3 Zeitliche Zuordnung......................................................................... 16
3.5.4 Reaktionszeit ................................................................................... 16
3.6 Logische Zuordnung .................................................................................... 16
3.7 Störung der Übertragungseinrichtung .......................................................... 16
4 Übertragungsprotokolle ...................................................................................... 17
4.1 Übertragungsprotokoll der OSI-Schicht 3 (IP) .............................................. 17

4.2 Verwendung der OSI-Schicht 4 Protokolle (UDP, TCP)............................... 17
4.2.1 UDP mit Rückmeldung .................................................................... 17
4.2.2 UDP ohne Rückmeldung ................................................................. 18
4.2.3 TCP mit Rückmeldung .................................................................... 18
4.2.4 TCP ohne Rückmeldung ................................................................. 19
4.2.5 Übertragungssicherung in der Transportebene ............................... 19
5 OCIT-Outstations Protokoll BTPPL (OSI-Schichten 5-7).................................... 19
5.1 Basis Transport Paket Protokoll Layer - BTPPL .......................................... 20
5.1.1 Telegrammaufbau BTPPL: .............................................................. 21
5.2 Allgemeine Kommunikation Client – Server ................................................. 23
5.2.1 Änderung des Domain-Namens von Feldgeräten über einen DNS . 24
5.3 Zeitliche Zuordnung (Zeitstempel) ............................................................... 24
5.3.1 Timeout ........................................................................................... 25
5.4 Logische Zuordnung .................................................................................... 25
5.5 Codierung der Daten.................................................................................... 25
5.6 Objekte ........................................................................................................ 26
5.6.1 Member-Nummer ............................................................................ 28
5.6.2 Identifizierung der Objekte .............................................................. 28
5.6.2.1 Auswahl der Returncodes (RetCodes) ............................................ 29
5.6.3 DNS-Cache-Invalidierung................................................................ 31
5.7 Sicherung der Übertragung beim OCIT-Outstations Protokoll ..................... 32
5.7.1 OCIT-O Passworte .......................................................................... 32
5.7.1.1 Installation eines neuen Gerätes ..................................................... 33
5.7.1.2 Wechsel des OCIT-O Passworts eines Feldgerätes ........................ 33
5.7.2 Übertragungssicherung durch den Fletcher-Algorithmus ................ 34
5.7.3 Übertragungssicherung durch den SHA-1 Algorithmus ................... 35
5.7.3.1 Bildung der Prüfsumme ................................................................... 36

5.7.3.2 Übertragen eines Befehls ................................................................ 36
5.7.3.3 Vom Sicherheitsprotokoll verwendete Returncodes ........................ 38
5.8 Prüfung des TCP-Kanals ............................................................................. 38
6 Typisierung......................................................................................................... 39
6.1 Schnittstellenobjekte .................................................................................... 39
6.1.1 Grunddatentypen: ........................................................................... 39
6.1.2 Metaelement DECL ......................................................................... 41
6.1.3 REFPATH ....................................................................................... 41
6.1.3.1 REFPATH_DATA ............................................................................ 42
6.1.3.2 EXTENSIBLE .................................................................................. 42
6.1.3.3 MINCOUNT MAXCOUNT ................................................................ 43
6.1.4 Metaelement MSGPART ................................................................. 44
6.1.4.1 Formatstrings................................................................................... 44
6.1.5 METHOD......................................................................................... 45
6.1.6 CLASSATTRIBUTE......................................................................... 45
6.1.6.1 FRAME ............................................................................................ 46
6.1.6.2 FRAME_DATA ................................................................................ 46
6.1.6.3 CATEGORY .................................................................................... 46
6.1.6.4 DEGREE ......................................................................................... 46
6.1.6.5 FORMAT ......................................................................................... 46
6.2 Datendefinitionen ......................................................................................... 46
6.2.1 OCIT-Outstation-DTD-Datei ............................................................ 47
6.2.2 OCIT-Outstations-Objekte-TYPE-Dateien ....................................... 47
6.2.3 Aufbau der TYPE-Dateien ............................................................... 47
6.3 Standard-Interfaces ..................................................................................... 53
6.3.1 Systeminterface .............................................................................. 53
6.3.1.1 Get ................................................................................................... 53

6.3.1.2 Update ............................................................................................. 54
6.3.1.3 Create .............................................................................................. 54
6.3.1.4 Delete .............................................................................................. 54
7 Beispiel für Abbildung der XML in Telegramme ................................................. 55
7.1 Typen, XML Beschreibung ........................................................................... 55
7.2 Instanzen ..................................................................................................... 58
7.3 Telegramme ................................................................................................. 58
8 Trace-Möglichkeiten ........................................................................................... 62
8.1 Trace-Datei .................................................................................................. 62
8.2 Externes Tracen........................................................................................... 62
8.2.1 Trace-Connection ............................................................................ 62
8.3 Binäres trace file format ............................................................................... 63
8.4 Auftragsstruktur............................................................................................ 64

Dokumentenstand
Version Verteiler Datum Kommentar
Zustand
V3.0_A01 PUBLIC 15.03.18 OCIT-O V3.0
Spezifikationen
Das OCIT-Outstations Konfigurationsdokument OCIT-O KD V3.0 enthält eine
Übersicht über alle von der ODG urheberrechtlich verwalteten Spezifikationen und
ordnet Versionen und Ausgabestände nach:
 zusammengehörenden Spezifikationen der Schnittstelle „OCIT-Outstations für

Lichtsignalsteuergeräte“ mit Referenz auf die dazugehörigen OCIT-C Spezifikatio-
nen,
 gibt Hinweise zum Einsatz der Übertragungsprofile und
 enthält eine Übersicht über Pakete von Spezifikationen für Schnittstellen, für de-
ren Nutzung von der ODG eine Schutzgebühr verlangt wird
Der jeweils aktuelle Stand ist auf www.ocit.org veröffentlicht.

1 Einführung
Das Dokument OCIT-O Protokoll enthält Definitionen im Bereich OCIT-Outstations,
die für die Realisierung konformer Schnittstellen einzuhalten sind. Das Dokument be-
schreibt:
 die Systemgrenzen,
 das OCIT-Outstations Protokoll,
 und enthält Regeln für die Definition von Objekten.
Die Definitionen gelten für Feldgeräte und Zentralen.
1.1 Systemgrenzen
Ein Überblick über das OCIT-System findet sich im Dokument OCIT-O System. Im
vorliegenden Dokument wird nur der Bereich OCIT-Outstations behandelt. Der mit
OCIT-Outstations gekennzeichnete Bereich in Bild 1, stellt zugleich den Bereich der
Definitionen, daher die OCIT-Outstations Systemgrenzen dar. Schnittstellen, die über
die dargestellten Systemgrenzen hinausführen, werden in diesem Dokument nicht
definiert.
Ein OCIT-Outstations System besteht aus einer Zentrale (zentrale Ebene) und OCIT-
Outstations Feldgeräten. Zentrale und Feldgeräte kommunizieren über die OCIT-
Outstations Schnittstellen.
Abbildung 1: OCIT-Outstations – Schnittstellen

OCIT-Outstations sind standardisierte Schnittstellen mit dem Anwendungsbereich
zwischen Zentrale und Feldgeräten:
 Zentrale - Feldgeräte
Verbindung zwischen Zentrale und Steuergeräten zum Zwecke der Steuerung,
Überwachung und Datensammlung. Die Feldgeräte sind Single-Master-Geräte,
daher ist ihre Gegenstelle logisch gesehen immer die Zentrale oder ein Ser-
vicetool in der Zentrale.
 Zentrale - Servicetools (Zentraler Systemzugang)

Erlaubt den Anschluss von Servicetools in der Zentrale und ermöglicht darüber
den Zugang zu den Feldgeräten. Für die Anbindung der Servicetools wird das
zentrale LAN verwendet. Zusätzliche Festlegungen finden sich im Dokument
OCIT-O Basis.
 Feldgerät - Servicetools (Lokaler Systemzugang)

Gedacht zum Anschluss von Servicetools direkt ans Steuergerät. Bisher wur-
den dazu in OCIT-O keine Festlegungen getroffen.
2 Schnittstellen und Systemfunktionen OCIT-

Outstations
Die typische Aufgabe von OCIT-Outstations ist die sichere Bedienung und Überwa-
chung von Feldgeräten aus der Ferne, wobei eine sofortige Quittierung, Reaktion
und Fehlerbehandlung erfolgt. Für die sichere Übertragung der Daten zwischen Zent-
ralen und Feldgeräten werden die aus dem Internet bekannten Protokolle TCP und
IP verwendet. Dadurch hängt die Übertragungsgeschwindigkeit von den Wegen im
Netz und vom Datenaufkommen ab. Die Übertragungszeiten können daher nicht in
jedem Einzelfall vorausgesagt werden. Sie machen sich für den Bediener im allge-
meinen jedoch nicht bemerkbar. Dieses Zeitverhalten wird in allen Spezifikationen
berücksichtigt. OCIT-Outstations kann so die rasant wachsenden Möglichkeiten der
Telekommunikations- und Netzwerktechnik auch auf der Straße nutzen und verfügt
damit über eine zukunftssichere technische Basis. Diese erlaubt es auch, OCIT-
Outstations im Laufe der Zeit an neue Anforderungen anzupassen und funktionell zu
erweitern, wobei der Umfang dieser Erweiterungen heute noch nicht bekannt ist. Dar-
aus lässt sich eine Forderung ableiten: die Übertragungsstrecke darf nicht mit zeitkri-
tischen Daten belastet werden, um eine zukünftige Überlastung vom Ansatz her zu
vermeiden.
Diese Forderung wird dann erfüllt, wenn zeitkritische Steuerungsaufgaben in den Ge-
räten vor Ort wahrgenommen und nicht zwischen Zentrale und Gerät über die
Schnittstelle abgewickelt werden. Solche Systeme bezeichnet man als ”dezentrale
Systeme“. Die OCIT-Outstations Feldgeräte besitzen daher Prozessoren, die kom-
plexe Abläufe lokal beherrschen und entsprechende Verarbeitungen durchführen
können.
Über die OCIT-O Schnittstelle werden Befehle und Daten beim Eintreffen bestimmter
Ereignisse übertragen. Systemweite, zeitgenaue Aktionen werden uhrzeitgesteuert

durchgeführt. Dazu ist in der Zentrale ein Zeitdienst vorhanden, nach dem alle gerä-
teinternen Uhren gestellt werden, so dass im gesamten System alle Geräte über eine
einheitliche Zeitbasis verfügen. Alle Meldungen und Befehle sind mit einem „Zeit-
stempel“ versehen, der sie zeitlich einordnet. Auch die Synchronisierung „grüner
Wellen“ erfolgt mittels der genauen Systemzeit und nicht durch Synchronisationsbe-
fehle der Zentrale.
2.1 Zentrale Ebene

Die Feldgeräte werden von einer zentralen Ebene aus gesteuert und überwacht. Die
zentrale Ebene kann aus mehreren Komponenten und Teilsystemen bestehen, die
sich an verschiedenen Orten befinden können. Eine definierte Funktion des Lichtsig-
nalsteuergerätes setzt auch eine entsprechende Funktion in der Zentrale voraus.
Darüber hinaus verfügen diese Zentralen über den sogenannten Zentralen System-
zugang. Servicetools können darüber von der Zentrale aus direkt mit den Feldgerä-
ten kommunizieren. Der Zugriff der Servicetools zu den Feldgeräten erfolgt quasi pa-
rallel zu den Zugriffen der Zentrale. Die wichtigste Funktion liegt darin, dass über den
zentralen Systemzugang die Fernversorgung der Lichtsignalsteuergeräte möglich ist.
Für Zentralen, die mit OCIT-O kommunizieren sind folgende Eigenschaften verpflich-
tend:
 Unterstützung aller OCIT-Outstations Funktionen,
 Bereitstellen einer genauen Systemzeit,
 Bereitstellen der zentralen OCIT-Outstations Systemzugänge.
2.2 Datenübertragung und Protokoll

Die Übertragungstechnik in OCIT-Outstations setzt auf dem Standard-Transportpro-
tokoll TCP/IP auf, das unabhängig von der physikalischen Datenübertragung einsetz-
bar ist und sichere Datenverbindungen gewährleistet. Diesen Standard verwenden
beispielsweise im Internet gebräuchliche Dienste wie http, FTP oder Email.
OCIT hat eine eigene Definition für das Übertragungsprotokoll der Anwenderebene,
die mit den Internet-Standards koexistieren kann, das „Basis Transport Paket Proto-
koll Layer“ (BTPPL). BTPPL wurde mit Blick auf die in städtischen Steuernetzen
manchmal vorhandenen Kabelverbindungen mit eingeschränkter Übertragungsleis-
tung entwickelt. Es arbeitet mit einem kleinen Datenoverhead und ermöglicht es
dadurch auch diese Strecken zu nutzen.
BTPPL bietet für den Datentransport 2 Kanäle. Ein Kanal mit hoher Priorität kann für
Schaltbefehle und Meldungen verwendet, auf den Kanal mit niedriger Priorität kann
zum Beispiel die Daten-Fernversorgung erfolgen. Die Arbeitsweise ist asynchron. Ein
Sender kann fortlaufend neue Telegramme senden und muss nach dem Absenden
von Telegrammen nicht auf zugehörige Rückmeldungen warten, sondern kann diese
nach ihrem Eintreffen zeitlich zuordnen. Ein fester Bestandteil des Protokolls ist der
SHA-1 Algorithmus, der über einen 24-Byte- Passwortschutz sicherstellt, dass die

Befehlstelegramme zwischen Zentrale und Feldgerät nicht manipuliert werden kön-
nen.
BTPPL kann mittels TCP/IP über verschiedene Übertragungswege kommunizieren.

Für etliche dieser Kommunikationsarten existieren Standards und damit auch Stan-
dard-Kommunikationsgeräte. Beispiele: DSL, Ethernet, digitales öffentliches Telefon-
netz und Standleitungsbetrieb in privaten Netzen über analoge Modems.
Im OCIT-System sind einige dieser Standardverfahren zur Kommunikation zwischen

Feldgeräten und Zentralen geeignet. Die entsprechenden Festlegungen im OCIT-
Standard werden als OCIT-Übertragungsprofile bezeichnet. Sie bestehen aus Festle-
gungen zu Systemfunktionen, Art der Übertragungsmedien und -geräte, Mindestan-
forderungen an Übertragungsleistung, Leitungseigenschaften u.a.
Mit OCIT-Übertragungsprofilen sind unterschiedliche Lichtsignalsteuergeräte ver-

schiedener Hersteller ohne weitere Absprachen betreibbar.
Bisher festgelegt sind:
„Profil 1 – Übertragungsprofil für Punkt-zu-Punkt-Verbindungen auf fest geschalteten

Übertragungswegen“. Die Übertragung erfolgt hier mit analogen Modems CCITT
V.34 mit typisch 28800 bps.
„Profil 3 – Ethernet mit DHCP“. Standardisiert ist die Anbindung an Ethernet, eine
kabelgebundene Datennetztechnik für lokale Datennetze, über die eine einfache An-
bindung an verschiedenste Kommunikationsnetze möglich ist.
Nicht in OCIT standardisierte Übertragungsprofile können herstellerspezifisch reali-

siert werden, bedingen jedoch Hard- und Softwareänderungen an Steuergeräten und
Zentralen.
2.3 Feldgeräte
Die Feldgeräte mit OCIT-O Schnittstellen sind sogenannte Single-Master-Geräte.
Ihre Gegenstelle ist logisch gesehen immer eine „einzige Zentrale“, auch wenn diese
aus mehreren Systemteilen bzw. Komponenten besteht. Von der Zentrale eintref-
fende Befehle werden daher von den Geräten immer in gleicher Art und Weise aus-
geführt, ohne zu unterscheiden von welcher Komponente sie stammen.
Auf Grund des Zeitverhaltens des OCIT-Outstations-Protokolls sind die Feldgeräte

speziell für Einsatz in dezentral aufgebauten Systemen gebaut. Zeitkritische Steue-
rungsaufgaben werden in diesen Systemen lokal in den Feldgeräten abgewickelt. Die
Feldgeräte besitzen daher Prozessoren, die komplexe Abläufe lokal beherrschen und
entsprechende Verarbeitungen durchführen können.

3 Kommunikationsmodell OCIT-Outstations
Das Kommunikationsmodell orientiert sich am ISO-OSI-Referenzmodell. Das ISO-
OSI-Referenzmodell (international standard organisation - open systems inter-
connection), auch als OSI-Modell oder OSI-Schichtenmodell bezeichnet, ist eine abs-
trakte Definition eines Modells, mit dessen realer Implementierung die verschiedens-
ten Netzsysteme (z.B. unterschiedliche Hersteller mit ihren unterschiedlichen techni-
schen Komponenten, öffentliche Anbieter, lokale Netze mit unterschiedlichen Zu-
griffsverfahren und Datenübertragungsprotokollen, usw.) zu einem offenen, d.h. zuei-
nander kompatiblen Kommunikationsnetz verbunden werden können.
Abbildung 2: Die Schichten im ISO-OSI-Refernzmodell
Das speziell für OCIT-Outstations entwickelte, bandbreitenoptimierte Protokoll

BTPPL umfasst Funktionen der Anwenderebenen 5 bis 7. Mit Ausnahme des OCIT-
Outstations Protokolls BTPPL werden nur Standardprotokolle eingesetzt.
TCP/UDP/IP sind die Transportprotokolle der mittleren Ebenen 3 und 4. Alle Befehle,
die größer als 4 KB sind, müssen per TCP übertragen werden. TCP ist zwingend zu
implementieren!
Sowohl mit UDP als auch TCP ist es möglich, dass für spätere Festlegungen ver-
schiedenartige Übertragungseinrichtungen definiert werden können, ohne dass der
Hauptteil des Protokolls sich ändert. Grundsätzlich können alle üblichen Medien und
Telekommunikationsdienste durch die Schichten 2 und 1 angebunden werden. Ver-
bindungsprotokolle werden entsprechend des zu verwendenden Übertragungsmedi-
ums und der Übertragungseinrichtung eingesetzt. In OCIT wird die Art der Übertra-
gungseinrichtung in den Dokumenten „Profile“ festgelegt. Welche Schnittstelle und
welchen Stecker der Hersteller zum Anschluss dieser Einrichtungen verwendet,
bleibt ihm freigestellt.
Für die Anwendung zwischen Zentralen und Feldgeräten kommen in erster Linie
Punkt-zu-Punkt-Verbindungen auf festgeschalteten Übertragungswegen in Frage,
daher bei Lichtsignalanlagen die vorhandenen kundeneigenen Kabelwege. Deshalb
wurde dieses Übertragungsprofil als erstes definiert (Profil 1 - Übertragungsprofil für
Punkt-zu-Punkt-Verbindungen auf fest geschalteten Übertragungswegen). Hier wird
das Protokoll PPP (Point-to-Point) eingesetzt und als Übertragungseinrichtung ein

Modem verwendet. Die dafür passenden Protokolle in den Schichten 2 und 1 sind in
Bild 2 dargestellt.
3.1 Sicherung der Übertragung

Die Übertragungssicherung erfolgt in der Transportebene und je nach Protokoll auch
in Schicht 2 (data link layer).
Da Zentralen oft an Netzwerken wie Intranet oder Internet angeschlossen sind, kann
eine unbekannte Zahl von Nutzern Zugriff haben. Insbesondere bei internen Netz-
werken haben viele Nutzer berechtigten Zugriff. In beiden Fällen ist ein Angriff durch
„Hacker“ möglich. Deshalb ist im OCIT-Outstations Protokoll die Kontrolle über die
Feldgeräte in der Anwenderebene zweistufig gesichert
3.1.1 Sicherheitsalgorithmus
In der Anwenderebene wird zwischen SHA-1-gesicherter und nicht gesicherter
Übertragung unterschieden:
 Nicht sicherheitsrelevante Kommunikation, wie z.B. die Übertragung von Visu-

alisierungsdaten, die den weit überwiegenden Teil der Kommunikation ausmacht
(je nach Projekt teilweise mehr als 95% des Datenvolumens), wird nur gegen un-
beabsichtigte, zufällige Übertragungsfehler und fehlgeleitete UDP-Pakete gesi-
chert. Eine solche Sicherung erfordert nur 2 Byte pro Paket. Die Bildung der Prüf-
summe ist auf dem PC mit wenigen Assemblerbefehlen pro übertragenes Byte
möglich (Fletcher Algorithmus).
 Die sicherheitsrelevante Kommunikation:
 Anwenderversorgung,
 Steuerbefehle und Kommandos mit Auswirkung auf das Systemverhalten
werden gegen beabsichtigte Zugriffe mit dem SHA-1 Algorithmus gesichert.
SHA-1 ist ein sicheres Prüfsummenverfahren, das jede unberechtigte Übertragung

erkennt und verwirft. SHA-1 wird in anderem Zusammenhang auch zur Bildung digi-
taler Unterschriften eingesetzt und ist weltweit als sicher anerkannt. Für die Übertra-
gungssicherung ist ein eigenes Passwort notwendig (OCIT-O Passwort), das die
Kommunikationspartner prüfen. Die Anwendung dieses Verfahrens hat unter ande-
rem den Vorteil, dass der Systemzugang nicht zwingend über eine Firewall gesichert
werden muss. Der Aufwand für dieses Verfahren hält sich bezogen auf die Gesamt-
laufzeit in engen Grenzen, weil nur ein sehr kleiner Teil der Kommunikation auf diese
Weise gesichert wird.
3.1.2 Firewall
Der SHA-1-Algorithmus schützt das Feldgerät, das ungesicherte Befehle ignoriert.
Falls Hacker die Verbindungen zwischen den Feldgeräten und Zentralen elektrisch

anzapften, wäre ein Eindringen in zentrale Systemteile und weiter in das Verwal-
tungsnetz dennoch möglich. Dieser Angriff kann durch die missbräuchliche Nutzung
der Netzwerkprotokolle der Schichten 3 und 4 erfolgen.
Die Hersteller von Zentralen bieten in ihren zentralen Kommunikationseinrichtungen

meist einen mehr oder weniger hohen Schutz vor diesen Eindringversuchen. Verwal-
tungsnetze werden üblicherweise durch den Einsatz von Firewalls in verschiedenen
Systemebenen gesichert.
3.2 Adressen
Feldgeräte und Zentralen kommunizieren über IP-Adressen. In einem Betreibernetz
muss daher jedes Feldgerät eine eindeutige IP-Adresse haben. In erster Linie kom-
men dabei selbst verwaltete Adressen in Frage. Die kostenpflichtige Nutzung von
echten Internet-Adressen ist möglich, allerdings aufgrund der hohen Anzahl benötig-
ter Internetadressen unrealistisch. Dieses „Feldgerätenetz“ wird häufig ein sternför-
miges Netz über kundeneigene Leitungen sein. Jedes Gerät hat einen eindeutigen
Hostnamen (siehe Pkt. 5.2).
3.3 IP-Netz
Es ist projektspezifisch festzulegen, ob OCIT-Outstations und Adressen der zentra-
len Komponenten in einem gemeinsamen IP-Netz liegen. Gegebenenfalls ist projekt-
spezifisch eine Firewall einzusetzen.
Eine direkte Kommunikation zwischen zentralen verkehrstechnischen Terminals und

Feldgeräten über das IP-Netz ist nur beim zentralen Systemzugang definiert.
3.4 Routen
Auf Grund der Nutzung von IP in der OSI Schicht 3 ist es technisch prinzipiell mög-
lich, Nachrichten zu „Routen“, daher Übertragungen von Feldgerät zu Feldgerät oder
zu anderen Systemteilen durchzuführen. Bei sternförmigen Verbindungen erfolgt da-
bei das „Routen“ über die Zentrale, die hier ähnlich wie eine Telefonvermittlung ar-
beitet. Für diese Funktionen wurden bisher keine Festlegungen getroffen.
3.5 Zeitverhalten
Das System ist nicht konzipiert für Übertragungen mit deterministischem Zeitverhal-
ten. Die erreichbare Übertragungsgeschwindigkeit im Netz hängt vom Kommunikati-
onssystem und der Datenlast im Netz ab. Systemweite, zeitgenaue Aktionen werden
deshalb uhrzeitgesteuert durchgeführt. Dazu ist in der Zentralen Ebene ein Zeitdienst
vorhanden, nach dem (im Standardfall) alle geräteinternen Uhren gestellt werden, so
dass im gesamten System alle Geräte über eine einheitliche Zeitbasis verfügen. Alle
Meldungen und Befehle sind mit einem „Zeitstempel“ versehen, der sie zeitlich ein-
ordnet.

3.5.1 Systemzeit
Das System verlangt eine übereinstimmende Systemzeit in der Zentrale und allen
Feldgeräten mit einer Genauigkeit von  500 ms.
Die Zentrale stellt dazu den Zeitdienst NTP Version 4 (RFC 5905) zur Verfügung
der von den OCIT- Lichtsignalsteuergeräten zur Synchronisierung der Gerätezeit mit
der zentralen Zeit verwendet werden kann.
Hinweis: Sind an einer Zentrale auch Feldgerät mit einer OCIT Version kleiner V3.0
(z.B. V2.0 oder V1.1) angeschlossen muss der Zeitdienst der Zentrale auch NTP
Version 3 (RCF 1305) bereitstellen bzw. so konfiguriert sein das Anfragen nach
NTPv3 entsprechend den Definitionen dieser Version beantwortet werden.
Das Synchronisierverfahren kompensiert die Übertragungszeiten im Netz. Der Zeit-

dienst liefert eine monotone Zeitbasis, die keine Sprünge durch Sommer- Winterzeit-
umschaltungen und keine Zeitzonen kennt (UTC-Zeit). Die UTC-Zeit ist die interne
Zeitbasis des Systems. Zur Umrechnung auf die Lokalzeit werden Standortinformati-
onen (Zeitzone) und die Schaltpunkte für die Sommer/Winterzeit benötigt. Diese sind
in OCIT-Outstations nicht definiert Die Umrechnung der von OCIT-Geräten in ihren
Meldungen gelieferten UTC-Zeiten auf Lokalzeit erfolgt in der Zentrale.
Als NTP-Server gilt grundsätzlich FNr. 0 (fg0) in der Zentrale, wobei die IP-Adresse
durch „reverse lookup“ erhalten werden kann. Eine manuelle Konfiguration von NTP-
Servern ist eine projektspezifische Lösung.
3.5.1.1 Feldgeräte mit permanenten Datenverbindungen zur Zentrale
Wird vom Betreiber keine explizite Anforderung angegeben, so besitzt der zentrale
Zeitdienst die höchste Priorität bei der Zeitsynchronisation der Gerätezeit mit der
zentralen Zeit. Uhren in den Feldgeräten bilden die Gerätezeit nur nach dem Ein-
schalten oder wenn der zentrale Zeitdienst über eine vom Hersteller vorgegebene
Zeit nicht erreichbar ist.
Der zentrale Zeitdienst NTP ist bei permanenten Verbindungen wie z. B. OCIT-O
Profil 1, mindestens alle 15 Minuten und sofort nach dem Aufbau der Verbindung ab-
zufragen.
Optional kann das Steuergerät vom Hersteller so konfiguriert werden, dass eine lo-
kale Uhr die priorisierte Zeitreferenz für die Gerätezeit bildet. Der zentrale Zeitdienst
wird dann nicht bzw. nur bei Ausfall der lokalen Uhr verwendet. Mit dieser Option
wird die geforderte einheitliche Systemzeit nur gewährleistet, wenn auch die zentrale
Zeitreferenz für den Zeitdienst über eine gleichartige Uhr wie in den Lichtsignalsteu-
ergeräten gewonnen wird.
3.5.1.2 Feldgeräte mit temporären Verbindungen zur Zentrale
Eine Konfiguration mit priorisierten zentralen Zeitdienst ist hier nicht sinnvoll, da dazu
permanente Verbindungen benötigt werden. Deshalb bilden lokale Uhren in den
Feldgeräten (DCF 77 oder andere Systeme) die priorisierte Zeitreferenz für die Gerä-
tezeit. Die geforderte einheitliche Systemzeit wird nur gewährleistet, wenn auch die

zentrale Zeitreferenz für den Zeitdienst über eine gleichartige Uhr wie in den Licht-
signalsteuergeräten gewonnen wird.
3.5.2 Ereignisorientierte Übertragung

 Jeder Übertragungsvorgang wird durch ein Ereignis (Event) ausgelöst:
 wenn der Betriebszustand des Gerätes wechselt (Bedienung, Störung, Fehler),
 wenn ein Aggregierungszeitraum abgelaufen ist, oder
 wenn durch die Gerätelogik entschieden wird, dass eine Übertragung durchzu-
führen ist.
 Die Übertragung von Ereignissen kann sowohl von der Zentrale als auch von
den Feldgeräten ausgehen. Ob eine Quittierung der übertragenden Nachricht
erfolgt oder nicht, oder ob die Nachricht bei fehlender Quittierung wiederholt
wird, ist abhängig von der jeweiligen Definition.
3.5.3 Zeitliche Zuordnung

Aggregierte und zwischengepufferte Daten werden mit Zeitstempel übertragen. Der
Zeitstempel ist ein Teil der übertragenen Daten.
3.5.4 Reaktionszeit
Bei quittierten Übertragungen ist ein Timeout vorzusehen, der die zu erwartende ma-
ximale Reaktionszeit berücksichtigt.
3.6 Logische Zuordnung

Das BTPPL-Protokoll verwendet ein asynchrones Aufrufverfahren, das heißt das auf-
rufende Programm läuft weiter, ohne die Ausführung bzw. Quittierung eines des Be-
fehls abzuwarten. Antworten auf Befehle können daher in zeitlich unterschiedlicher
Reihenfolge eintreffen. Die logische Zuordnung zwischen Befehl und Antwort wird
durch den asynchronen Call - Respond Mechanismus des BTPPL -Protokolls sicher-
gestellt.
3.7 Störung der Übertragungseinrichtung

Das Systemverhalten bei einer Störung der Übertragungseinrichtung ist abhängig
vom Gerätetyp und Übertragungssystem. Systemweit gültige Festlegungen dazu fin-
den sich im Dokument „Basis“. Zusätzliche Festlegungen finden sich in den Doku-
menten der Übertragungsprofile.

4 Übertragungsprotokolle
In diesem Kapitel werden die OSI-Schichten 3 und 4 beschrieben. Die OSI-Schichten
1 und 2 sind in den Dokumenten OCIT-O Profile aufgeführt.
4.1 Übertragungsprotokoll der OSI-Schicht 3 (IP)

In der Vermittlungsschicht wird in allen Fällen Standard-IP verwendet.
4.2 Verwendung der OSI-Schicht 4 Protokolle (UDP, TCP)

Hinweis: Funktion wurde gegenüber Vorgängerversion geändert (neue Telegramm-
größe)!
Für die BTPPL-Kommunikation mit den OCIT-Outstations Geräten wird je nach
Größe der Pakete entweder TCP oder UDP eingesetzt. Alle Pakete, die kleiner als 4
KByte sind, können per TCP oder UDP übertragen werden; alle Pakete die größer
als 4 KByte müssen immer per TCP übertragen werden. Ob per TCP übertragen wird
oder per UDP, entscheidet die Zentrale. Bei einer Anfrage per TCP wird per TCP ge-
antwortet, bei einer Anfrage per UDP mit UDP.
Für jedes Versorgungselement wird ein OCIT-O Objekt angelegt.
Es werden die bestehenden OCIT-O Methoden, Fehlermeldungen etc. verwendet.
Versorgungsobjekte werden mit btppl als Nachricht mit niedriger Priorität (siehe auch
5.1) übertragen.
Die Telegrammgröße ist auf 2 MByte bei TCP begrenzt. Das Feldgerät muss einen
entsprechend großen Speicher zum Zwischenspeichern einer gesamten Versorgung
(Puffer) vorhalten. Bei TCP sind btppl-Telegrammgrößen von bis zu 2 Megabyte zu
verarbeiten.
4.2.1 UDP mit Rückmeldung

Bei einer Übertragung per UDP wird vom Client von irgendeinem Sendeport aus das
Paket abgeschickt und zur Zuordnung der Antwort die Jobnummer (siehe 5.1.1) und
der Sendeport + IP-Adresse des Senders gespeichert. Die Verwendung der Jobnum-
mer stellt sicher, dass von einem Sendeport aus mehrere Befehle abschickt werden
können, ohne dass auf die Antwort eines Befehls gewartet werden muss. Je nach
Wichtigkeit des Befehls wird das Paket entweder an PNP oder an PHP abgeschickt.
Das Paket wird vom Server empfangen und dort bearbeitet. Für die Bearbeitung
müssen die Jobnummer und die IP-Adresse des Senders und der Originalport zwi-
schengespeichert werden, um die Antwort zurücksenden zu können. Wenn die glei-
che Portnummer / Jobnummernkombination während der Bearbeitung ein weiteres
Mal auftritt, ist es der Implementierung freigestellt, diesen Befehl entweder zu igno-
rieren oder ein weiteres mal abzuarbeiten. Sobald der Befehl abgearbeitet ist, wird
die Antwort mit der Original-Jobnummer an den Originalport zurückgeschickt. Wenn

nach diesem Absenden der Antwort ein Befehl mit der gleichen Portnummer und
dem gleichen Job kommt, muss der Server den Befehl erneut bearbeiten.
Der Server sendet die Antwort (Respond Paket) an die Adresse zurück, von welcher
der Request (Jobnummer + Port + IP-Adresse) kam. Wenn der Client das Antwortte-
legramm nicht vor Ablauf des Timeouts (Retry) empfängt, wiederholt er den Request
(ggf. mehrfach). Erst wenn nach einem zweiten Timeout (Fail) noch keine Antwort
zurückgekommen ist, wird der Befehl als fehlgeschlagen nach oben zurückgemeldet.
Der Aufrufer weiß dann nicht, ob der Befehl nicht durchgeführt wurde oder der Befehl
durchgeführt wurde und lediglich die Antwort verloren ging oder ob sich der Befehl
noch in einer Warteschlange befindet. Es ist die Aufgabe des aufrufenden Prozes-
ses, in diesem Fall den Befehl zu wiederholen oder zu ignorieren. Sobald eine Ant-
wort zurückgesendet wird oder wenn der Fail-Timeout abgelaufen ist, wird die ent-
sprechende Meldung zum aufrufenden Programm übertragen. Alle folgenden Ant-
wortpakete, die verspätet eintreffen, werden einfach ignoriert.
Zum Senden eines Telegramms wird ein „Request“-Paket, für die Antwort ein „Res-
pond“-Paket verwendet.
4.2.2 UDP ohne Rückmeldung

Die Nachricht wird von irgendeinem Sendeport aus abschickt. Je nach Wichtigkeit
des Befehls sendet der Client das Paket (Request) entweder an den PNP oder an
den PHP des Servers.
Das Paket wird vom Server empfangen und dort bearbeitet.
Als Pakete ohne Rückmeldungen werden lediglich die unten definierten „Messages“
verwendet.
4.2.3 TCP mit Rückmeldung

Bevor ein Paket über TCP übertragen wird, wird geprüft, ob ein TCP-Kanal bereits
offen ist. Ist dies nicht der Fall, so wird ein TCP-Kanal geöffnet. Je nach Wichtigkeit
des Befehls wird das Paket entweder an PNP (Port niederpriorisiert) oder an PHP
(Port hochpriorisiert) abgeschickt. Die Jobnummer wird übertragen, da sie bei Mul-
tithreaded-Servern und -Clients benötigt wird. Der Kanal bleibt mindestens so lange
geöffnet, bis die Antwort ankommt oder bis der Timeout (Fail) auftritt. Es muss aber
während der Befehlsausführung geprüft werden, ob der Kanal nach wie vor existiert.
Im Fehlerfall wird der Befehl abgebrochen. Der Kanal wird erst wieder für den nächs-
ten Befehl geöffnet.
Die Antwort wird an den Port zurückgeschickt, von dem die Sendung ausging. Wäh-
rend der Bearbeitung bleibt der Kanal geöffnet. Der Server überträgt auch bei TCP
die Jobnummer aus dem Request- in das Respondtelegramm. Wenn der Server das
Antworttelegramm nicht übertragen kann, verwirft er es und versucht nicht den Kanal
erneut zu öffnen.
Am Sendeport wartet der Client auf die Antwort (Respondtelegramm) auf den abge-
sendeten Befehl (Requesttelegramm). Wenn nach einem Timeout (Fail) noch keine

Antwort zurückgekommen ist, wird der Befehl als fehlgeschlagen nach oben zurück-
gemeldet.
Der Aufrufer weiß dann nicht, ob der Befehl nicht durchgeführt wurde oder der Befehl
durchgeführt wurde und lediglich die Antwort verloren ging oder ob der Befehl sich
noch in einer Warteschlange befindet. Es ist die Aufgabe des aufrufenden Prozes-
ses, in diesem Fall den Befehl zu wiederholen oder zu ignorieren. Sobald eine Ant-
wort empfangen wird oder wenn der Fail-Timeout abgelaufen ist, wird dies dem Auf-
rufer rückgemeldet. Es ist nicht notwendig, dass der Kanal nach der Ausführung ge-
schlossen wird. Allerdings müssen sowohl Client als auch Server so programmiert
werden, dass auf ein Abreißen des Kanals korrekt reagiert wird.
Zum Senden eines Telegramms wird ein „Request“-Paket, für die Antwort ein „Res-
pond“-Paket verwendet.
4.2.4 TCP ohne Rückmeldung

TCP ohne Rückmeldung ist möglich.
4.2.5 Übertragungssicherung in der Transportebene

Übertragungssicherung gegen Datenverfälschungen erfolgt in der Transportebene
nur bei TCP, nicht aber bei UDP. TCP initialisiert, überwacht und beendet die Verbin-
dung und stellt sicher, dass die Telegramme ankommen.
5 OCIT-Outstations Protokoll BTPPL (OSI-Schichten 5-7)

Dieses Kapitel enthält die Beschreibung des OCIT-Outstations Protokolls und weitere
mit dem Protokoll in Zusammenhang stehende Definitionen wie z. B. der in OCIT-
Outstations verwendete Sicherheitsalgorithmus.
Abbildung 3: Protokolle für OCIT-Outstations
Das OCIT-Outstations Protokoll in den OSI-Schichten 5 – 7 umfasst:

 die Anbindung der Kommunikation an die Geräte-SW (inkl. OCIT-Objekte) der
jeweiligen Hersteller und
das speziell für OCIT-Outstations entwickelte Protokoll BTPPL. Dieses verbindet die
Objekte in den entfernten Systemen (Zentrale und Feldgeräte) durch Methodenauf-
rufe. BTPPL bildet diese Methodenaufrufe durch Telegramme auf UDP/TCP/IP
Ebene ab. BTPPL verwendet sehr kompakte Telegrammstrukturen.
5.1 Basis Transport Paket Protokoll Layer - BTPPL

BTPPL umfasst:
 Telegrammaufbau
- Header
- Serialisierung der Daten (Aufrufparameter der Methoden)
- Prüfsummen (Fletcher, SHA-1)
 Ablauf von Methodenaufrufen

- Funktionen mit Rückgabeparameter
- Funktionen ohne Rückgabeparameter
 Methoden für Wechsel des OCIT-O Passwortes.
BTPPL umfasst nicht
 die Methoden zur Bedienung von Gerätefunktionen (diese liegen in der Anwen-
dung),
 Definitionen für OSI-Schichten unterhalb von IP und
 Methoden zur Speicherung von Daten.
BTPPL ist ein symmetrisches Protokoll. Es wird kein prinzipieller Unterschied zwi-
schen einem Feldgerät und einer Zentrale gemacht. Alle teilnehmenden Geräte sind
sowohl Client als auch Server. Daher ist es vom Protokoll her ohne weiteres möglich,
dass auch Feldgeräte Befehle an andere Feldgeräte senden können (wie die Zent-
rale Ebene).
BTPPL verwendet sog. asynchrone Methodenaufrufe. Hierbei werden durch das Pro-
tokoll Funktionen ("Methoden") in einem angeschlossenen Gerät aufgerufen und aus-
geführt. Der Ressourcenbedarf asynchroner Methodenaufrufe ist erheblich geringer
als der von synchronen Methodenaufrufen. Die zu definierenden Funktionalitäten der
Schnittstelle werden in "Objekttypen", "Objekte" und "Methoden" unterteilt. Die Auftei-
lung hat dabei folgenden Hintergrund: In allen Geräten gibt es eine Reihe von Ele-
menten, die mehr oder weniger unabhängig voneinander sind. In einem Lichtsignal-
steuergerätsind dies z.B. Signalpläne mit ihren jeweils eigenen Befehlen, Messstel-
len, Betriebstagebücher oder VA-Logiken. Jedes dieser Elemente, obwohl physisch
nicht vorhanden, ist im Sinne der objektorientierten Programmierung ein bestimmter
Typ eines Objekts (Objekttyp). Jedes dieser Objekte kann einzeln angesprochen
werden und besitzt eigene Funktionen (Methoden), die sich auf eben genau dieses

Objekt beziehen. Von bestimmten Objekttypen wie z.B. Signalplänen gibt es im Ge-
rät mehrere Objekte. Damit diese Objekte unterschieden werden können, hat jedes
Objekt eine genaue Bezeichnung (ObjektId).
OCIT-Outstations benötigt zwei Ports pro TCP und UDP: Über einen Port werden
Nachrichten mit niedriger Priorität übertragen, über den anderen Port Nachrichten mit
hoher Priorität. Beide Ports werden sowohl für TCP als auch für UDP verwendet. Bei
der Installation sind beide Ports vorbelegt:
 Nachrichten mit niedriger Priorität werden an Port 3110 übertragen. Der Port
wird im folgenden als PNP abgekürzt.
 Nachrichten mit hoher Priorität werden an Port 2504 übertragen. Der Port wird
im folgenden als PHP abgekürzt.
Der Sendeport ist jeweils frei festlegbar. Die Antwort wird an den Port im gleichen
Protokoll zurückgeschickt, von dem der Auftrag stammt. Wenn ein Request per UDP
gesendet wird und die Antwort > 4 KByte ist, wird als Antwort ein Fehler zurückge-
meldet.
5.1.1 Telegrammaufbau BTPPL:

Offset Offset + 0 Offset + 1 Offset + 2 Offset + 3
0 BL (MSB) ... ... BL (LSB)
4 HdrLen T V r r S JobTime (Hi) JobTime (Lo)
8 JobTimeCount JobTimeCount Member (Hi) Member (Lo)
12 OType (Hi) OType (Lo) Method (Hi) Method (Lo)
16 ZNr (Hi) ZNr (Lo) FNr (Hi) FNr (Lo)
20 Path, Länge: HdrLen-16
4+HdrLen Parameterblock:
Länge: BL-HdrLen-2 (ohne SHA-1 Sicherung)
Länge: BL-HdrLen-26 (mit SHA-1 Sicherung)
BL-22 UTC (MSB) ... ... UTC (LSB)
BL-18 SHA-1 Prüfsumme
BL-14 SHA-1 Prüfsumme
Bl-10 SHA-1 Prüfsumme
Bl+2 Fletcher (Hi) Fletcher (Lo)

Bei nicht sicherheitsrelevanten Telegrammen fehlen die Zeilen BL-22 bis BL-2.
Anmerkung:
MSB: most significant byte (2^31 ... 2^24)
LSB: least significant byte (2^7 ... 2^0)
Die Felder haben folgende Bedeutung:
Name Bedeutung
BL Blocklänge. Die Blocklänge wird nur bei TCP verwendet. Bei UDP
wird die Blocklänge des UDP-Blockes benutzt.
HdrLen Länge des Kopfes inkl. Pfad in Byte. Ab der Adresse HdrLen begin-
nen die Parameter des Befehls. Wenn kein Pfad vorhanden ist, hat
HdrLen den Wert 16, ansonsten 16+<Länge des Pfadeintrags in
Byte>.
T Typ des Telegramms (Flag >> 5):
0: Request (Befehlstelegramme).
1: Respond (Antworttelegramme auf Befehlstelegrammtyp
„Request“)
2: Message (Befehlstelegramme ohne Antwort)
3..8: reserviert
V OCIT-Outstations-BTPPL Version ((Flag >> 3) & 3):
0: OCIT-Outstations-BTPPL Version 1
1..3: reserviert
r Reservierte Bits (immer 0)
S SHA-1 Prüfsumme (Flag & 0x01):
0: nur Fletcher Prüfsumme
1: Fletcher Prüfsumme und SHA-1 Prüfsumme
JobTime JobTime und JobTimeCount zusammen bilden die Jobnummer. Die
Jobnummer wird für ein Request-Telegramm vom Sender generiert
Job- und darf bis zur Antwort (Respond-Telegramm) nicht neu vergeben
TimeCount werden. Im Respond-Telegramm wird die gleiche Nummer eingetra-
gen. Damit kann der Respond zugeordnet werden. In Message-Te-
legrammen ist dieses Feld auf 0 zu setzen.
Member Nummer des Herstellers, der das Access-Objekt definiert hat. Die
Herstellernummern (Member-Nummern) werden von der ODG ver-
geben
OType Typ des Objekts
Method Nummer der Methode innerhalb des Interfaces
ZNr Nummer der Zentrale. Jede Zentrale eines Betreibers muss eine
eindeutige Zentralen-Nummer haben.
FNr Nummer des Feldgerätes unterhalb der Zentrale. Alle Geräte, die
von einer Zentrale gesteuert werden, müssen zentralenweit einen

Name Bedeutung
eindeutigen Namen haben. Die Zentrale hat immer die Feldgeräte-
Nummer 0.
Path Objekte, die mehrfach in einem Gerät existieren, werden hier ein-
deutig definiert. Die Länge des Pathtyps ist verschieden. Sie lässt
sich unmittelbar aus HdrLen ableiten. Der Pfad kann auch eine un-
gerade Länge haben.
Parameter- Eingabeparameter bei Request- und Message-Blöcken, bei Res-
block pond-Blöcken die Ausgabe-Parameter. In Respond-Blöcken sind
die ersten zwei Byte immer das Statuswort, in dem das Funktions-
ergebnis eingetragen ist. Der Parameterblock ist unterschiedlich
lang. Der Parameterblock kann eine ungerade Länge haben.
UTC Uhrzeit, zu dem das Paket abgeschickt wurde, als unsigned-32 For-
mat. Das UTC-Feld wird nur verwendet, wenn ein gesichertes Tele-
gramm (also mit SHA-1) übertragen wird.
SHA-1 Prüfsumme. Die Prüfsumme wird über den Bereich von HdrLen
(Offset 0 bei UDP, 4 bei TCP) (einschließlich) bis UTC(LSB) (ein-
schließlich) gebildet. Detaillierte Beschreibung in Kapitel 5.7.3.
Fletcher Fletcher-Prüfsumme. Die Prüfsumme wird über den Block von
HdrLen (einschließlich) bis zu dem Byte vor der Prüfsumme (ein-
schließlich) gebildet. Sie umfasst damit also immer den Parameter-
block und – falls übertragen – auch die SHA-1 Prüfsumme. Detail-
lierte Beschreibung in Kapitel 5.7.2.
5.2 Allgemeine Kommunikation Client – Server

Alle im Protokoll vorhandenen Kommunikationen lassen sich auf das Prinzip Client -
Server zurückführen, welches hier zunächst beschrieben wird. Welche Rolle die ein-
zelnen Geräte dann jeweils einnehmen, ist unten aufgeführt.
Jedes Gerät hat einen eindeutigen Hostnamen. Der Hostname ist folgendermaßen
aufgebaut:
fg<Gerätenummer>.z<Zentralennummer>.<Betreiber-Domain>
Die OCIT-Outstations LSA 5 an der Zentrale 3 der Betreibers „ruebenstadt-sv.de“ hat

damit den Hostnamen:
fg5.z3.ruebenstadt-sv.de
In der Zentrale wird ein DNS-Server (Nameserver) eingerichtet und dort die IP-
Adressen der Feldgeräte projektspezifisch fest versorgt. Auch die Die OCIT-
Outstations Systemzugänge (Hinweis: In OCIT-O V2.0 nicht angeboten) verwenden
zur Bestimmung der IP-Adresse den DNS-Server (RFC 1034, RFC 1035, RFC 974,
RFC 1912).
Die Kommunikation der Feldgeräte untereinander läuft über IP-Routing (bisher noch
nicht standardisiert). Die Vergabe der IP-Adressen erfolgt dabei projektspezifisch.

5.2.1 Änderung des Domain-Namens von Feldgeräten über einen
DNS
Mit dieser Möglichkeit werden Änderungen von Domain-Namen der Betreiber-Do-
main, die üblicherweise alle Lichtsignalsteuergeräte / Feldgeräte eines Regelgebiets
betreffen, automatisch durchgeführt. Die proprietär durchzuführende Umversorgung
der Domain-Namen aller betroffenen Feldgeräte ist damit nicht mehr notwendig.
Die Feldgeräte ermitteln dazu ihren gültigen Domain-Namen aus Daten, die bei der
Initialisierung von der zentralen Ebene an die Feldgeräte übertragen werden. Diese
Daten sind in den bisher festgelegten Übertragungsprofilen definiert. Das Feldgerät
erhält somit schon bisher
 die IP-Adresse des zentralen Peers,
 die IP-Adresse des Feldgerätes (FG-IP Adresse) und
 zwei Adressen von Domain Name Servern.
Um den Domainnamen bzw. mögliche Änderungen des Domain-Namens festzustel-

len, führt das Feldgerät bei jedem Verbindungsaufbau eine Rückwärtssuche im DNS
(reverse DNS look-up) über die FG-IP Adresse durch und erhält daraus vom DNS
seinen vollständigen Domain-Namen (fully qualified domain name). Dieser ist gemäß
OCIT-O Protokoll:
"fg<Gerätenummer>.z<Zentralennummer>.<Betreiber-Domain>"
also zum Beispiel fg5.z3.ruebenstadt-sv.de. Daraus wird der für das Feldgerät gültige
Domain-Name der Betreiber-Domain, im Beispiel ruebenstadt-sv.de, abgeleitet.
Erkennt das Feldgerät eine Änderung seines Domain-Namens aktualisiert es seine

Einstellungen. Falls der reverse look-up fehlschlägt, behält das Feldgerät seine alte
Einstellung bei.
Jede zentrale Ebene mit OCIT-O Komponenten muss den reverse DNS look-up der
FG-IP Adresse unterstützen.
5.3 Zeitliche Zuordnung (Zeitstempel)

 Aggregierte Daten werden mit der Uhrzeit (Zeitstempel) des Intervallbeginns
übertragen. Der Zeitstempel ist nicht Bestandteil von BTPPL sondern des je-
weiligen Objekts.
 Zwischengepufferte Daten werden mit der Uhrzeit (Zeitstempel) bei Auftreten

des Ereignisses übertragen. Der Zeitstempel ist nicht Bestandteil von BTPPL
sondern des jeweiligen Objekts.
 Als Format des Zeitstempels wird die UNIX-Codierung der UTC festgelegt. Die
Codierung speichert die Anzahl der Sekunden seit dem 1.1.1970 in einer 32-
Bit Variable. Diese Codierung wird von praktisch allen Betriebssystemen un-
terstützt, sie ist kompakt und erleichtert die Sortierung von Ereignissen. Es ist
darauf zu achten, dass dieses Zeitformat am 19.1.2038 überläuft. Für die
Kommunikation in OCIT-Outstations wird die 32-Bit-Variable in diesem Fall
einfach weitergezählt und läuft damit erst ca. 2100 n.Chr. über.
5.3.1 Timeout
Hinweis: Funktion wurde gegenüber Vorgängerversion geändert (neue Rechenregel
für Timeout)!
Bei quittierten Übertragungen ist ein Timeout in der Applikation vorzusehen, der die
zu erwartende maximale Reaktionszeit berücksichtigt. Für alle quittierten Übertragun-
gen wird der gleiche Timeout:
120 s + Telegrammlängen/( n Bytes/s) verwendet.
n = 1000 Bytes/s bei Profil 1
Telegrammlängen = Länge des Request + Länge des Respond Telegramms, jeweils

von HdrLen bis einschließlich Fletcher.
Die Timeout-Zeit wird erst ab dem Start der Übertragung (Start Übergabe des Requ-
est Telegramms an TCP) gerechnet. Mit dem Empfang der Länge des Respond Te-
legramms ist der Timeout-Zähler speziell bei langen Antworttelegrammen gemäß
obiger Formel zu korrigieren.
5.4 Logische Zuordnung

Für Befehle kann eine 32-Bit Vorgangskennung definiert werden, die systemweit ein-
deutig ist und für Betriebstagebücher etc. verwendet wird. Die Vorgangskennung ist
ein Teil der Daten eines Objektes. Sie ist im Dokument OCIT-O Basis beschrieben.
Die Spezialisierung für Lichtsignalsteuergeräte findet sich im Dokument OCIT-O
Lstg.
Antworten auf Befehle können in zeitlich unterschiedlicher Reihenfolge eintreffen. Die

logische Zuordnung erfolgt durch IP-Adresse, Port und 32-Bit Jobnummer (die Job-
nummer ist ein Bestandteil des BTPPL-Protokolls).
5.5 Codierung der Daten

Für die Codierung der Daten wird in OCIT-Outstations ein abgewandeltes XDR-
Format eingesetzt (RFC 1014). Um Bandbreite zu sparen werden folgende Änderun-
gen am XDR-Format durchgeführt:
 Die Basic-Block-Size (RFC 1014, Punkt 2) wird auf 1 Byte heruntergesetzt. Die
Verwendung von 32 Bit pro Byte ist zu groß. Entsprechend wird bei den Punk-
ten RFC 1014 - 3.8, 3.9 und 3.10 der Wert von r auf 0 gesetzt (kein Padding).
 Zusätzlich zum Signed-Integer (RFC 1014, Punkt 3.1) wird ein Signed-Short
(16 Bit) und ein Signed-Char (8 Bit) hinzugefügt. Entsprechend werden zum

Unsigned-Integer (RFC 1014, Punkt 3.2) ein Unsigned-Short (16 Bit) und ein
Unsigned-Char (8 Bit) hinzugefügt. Ein Padding findet in keinem Fall statt.
 Boolean-Werte werden als Unsigned-Char gespeichert.
 Strings werden immer mit einem 16-Bit (USHORT) Längenwort dargestellt, wel-
ches die Anzahl der BYTES(!) im String angibt.
 Abhängig von der maximalen Zahl an Elementen wird entweder ein Längen-
byte (max. 255 Elemente), ein Längenwort (65535 Elemente) oder ein ULONG
vorangestellt, welches die Zahl von Elementen angibt.
Die Union-Diskriminatoren (die nur sehr selten sind) bleiben bei jeweils 4 Byte
Länge, um nicht verschiedene Typen von Unions einführen zu müssen.
5.6 Objekte
Die Funktions-Aufrufe in OCIT-Outstations sind objektorientiert aufgebaut. Anders als
z.B. bei RPC wird eine Funktion nicht nur durch eine Zahl repräsentiert, sondern
durch die Kombination von Objekttyp, ObjektId und Methode. Dies soll zunächst ge-
nauer erläutert werden:
Element Beschreibung
Objekttyp Alle Elemente, auf die in einem OCIT-Gerät zugegriffen werden kann,
sind einem Objekttyp zugeordnet. Beispiele für solche Objekttypen sind:
(Member, Signalplan, Detektor, Betriebstagebuch usw. Es gibt eine Reihe von
OType)
Objekttypen, die sehr einfach sind und auf die z.B. nur schreibend oder
lesend zugegriffen werden kann, wie z.B. Gerätename.
Der Objekttyp wird durch die Felder Member und OType beschrieben.
Member ist die Member-Nummer des Herstellers, der den Objekttyp
verwendet. Bei OCIT-Outstations Objekttypen wird immer eine 0 oder 1
eingetragen, für herstellerspezifische Objekte steht hier die Nummer
des Herstellers.
OType ist der Objekttyp selbst. Die Nummer muss für die Standard-Ob-
jekte eindeutig vergeben werden. Bei herstellerspezifischen Objekten
können sie durch die Hersteller festgelegt werden, da sich die Objekte
schon durch Member unterscheiden.
ObjektId
(ZNr,
Die meisten Objekttypen sind mehrfach vorhanden. Dies gilt z.B. für
FNr, Signalpläne 1 bis n, Detektoren 1 bis n, Betriebsmeldungsarchive usw.
Path) Um die sog. Instanzen dieser Objekte unterscheiden zu können, wird
eine ObjektId benötigt, die für einen Betreiber zentralenübergreifend
eindeutig ist. Anders als in den meisten Kommunikationssystemen ist in
OCIT-Outstations diese Adresse (ObjektId) von variabler Länge und vor

allem "sprechend". Das bedeutet, dass sich aus der ObjektId bereits re-
levante Daten herauslesen lassen. Die ObjektId für ein Signalprogramm
besteht beispielsweise aus drei Elementen: Zentralen-Nummer (ZNr),
Feldgeräte-Nummer (FNr) und der Signalprogrammnummer, die im
Path gespeichert sind. Alle drei Elemente sind für den Benutzer und
noch wichtiger für die Programme unmittelbar auswertbar und "ver-
ständlich".
Die Einträge ZNr und FNr sind in jeder ObjektId vorhanden, obwohl
z.B. eine Zentrale keine Gerätenummer haben müsste. Der Grund dafür
ist, dass sich aus der Kombination ZNr und FNr die Zieladresse des
Gerätes feststellen lässt. Würde FNr nicht bei jedem Objekt enthalten
sein, müsste die Zentrale zunächst immer anhand des Objekttyps fest-
stellen, ob das Objekt an das Kreuzungsgerät weitergeleitet werden
muss.
Der Path enthält in den meisten Fällen kein oder nur ein Element. Es
ist jedoch möglich, dass der Path auch mehrere Elemente enthält, so-
lange die Gesamtlänge nicht 240 Byte übersteigt.
Objekt Die Kombination aus Objekttyp und ObjektId wird als Objekt bezeich-
net. Wie aus den obigen Beschreibungen bereits hervorgeht, gibt es pro
Gerät mindestens ein Objekt (das eigentliche Gerät) und im Normalfall
zusätzlich weitere Objekte. Diese sind z.T. von OCIT-Outstations vorge-
geben, z.T. durch die Hersteller selbst definiert.
Methode Alle "Funktionen", die in einem OCIT-Gerät ausgeführt werden, bezie-

(Method) hen sich auf Objekte. Daher werden sie wie in der objektorientierten
Programmierung üblich als Methoden bezeichnet. Es ist immer möglich,
dass die gleichen Methoden auf unterschiedliche Objekte angewendet
werden können. Methoden sind in OCIT-Outstations immer zu Inter-
faces gruppiert.
Alle Methoden sind Funktionen mit Ein- und Ausgabeparametern sowie

einem Funktionsergebnis. Das Funktionsergebnis ist ein 16-Bit-Wert.
Die ersten 10000 Einträge sind für OCIT-Outstations reserviert. 0 be-
deutet dabei immer "Fehlerfreie Ausführung", während die Werte von
1...9999 für OCIT-Outstations spezifische Fehler stehen. Werte über
10000 sind Herstellern vorbehalten und haben pro Hersteller und pro
Objekt eine unterschiedliche Bedeutung.
Die Ein- und Ausgabeparameter sind in einer komprimierten XDR-

Variante codiert (siehe Pkt. 5.5). Die Ein- und Ausgabeparameter pro
Methode sind fix und ändern sich nicht, egal auf welches Objekt die Me-
thode angewendet wird. Einen Ausnahmefall bilden die Methoden des
Interface 0 (Pkt. 6.3). Sie sind vom jeweiligen Objekt abhängig.
Parameter Im OCIT-Outstations Protokoll wird jede Methode mit 0...n Eingangspa-

rametern aufgerufen und liefert 0...n Ausgangsparameter zurück. Jeder

der Parameter kann strukturiert sein. Die Eingangs- und die Aus-
gangsparameter werden in einem komprimierten XDR-Format codiert.
Bei Messages (Methoden ohne Rückgabeparameter) läuft das aufru-

fende Programm weiter, ohne die Ausführung des Befehls abzuwarten
(asynchroner Aufruf).
5.6.1 Member-Nummer
Mit Hilfe der Member-Nummer ist im OCIT-Outstations-Systems eine Unterscheidung
zwischen OCIT-Objekten und Hersteller-Objekten möglich. Member 0 und 1 sind die
von der ODG festgelegten OCIT-Outstations-Objekte. Sie kennzeichnen den Stan-
dard. Die sogenannten Hersteller-Objekte werden entsprechend den OCIT-Regeln in
eigener Verantwortung des jeweiligen Urhebers erzeugt. Die Verwaltung der Mem-
ber-Nummern obliegt der ODG. Sie aktuelle Liste wird auf der Homepage
www.ocit.org veröffentlicht.
5.6.2 Identifizierung der Objekte

Alle Objekte werden weltweit durch einen eindeutigen Access-Pfad identifiziert. Die-
ser Pfad besteht aus drei festen Bestandteilen und einem "Path" variabler Länge.
 Der erste feste Bestandteil ist die Betreiber-Identifizierung. Diese ermöglicht

eine zentralenübergreifende Kommunikation. Als Betreiber-Identifizierung kann
eine echte Internet-Domain Adresse verwendet werden oder eine ähnlich auf-
gebaute Adresse eines Inselnetzes. Die Betreiberdomain ist nicht Bestandteil
der BTPPL-Telegramme, sie wird nur zum Aufbau von zentralenübergreifenden
Verbindungen verwendet.
 Zur Geräteidentifizierung werden im BTPPL-Header 2 Einträge verwendet: Die

Zentralen-Nummer (ZNr) und die Feldgeräte-Nummer (FNr). Die Zentralen-
Nummer ist eine eindeutige Nummer der Zentrale bei einem Betreiber. Sie um-
fasst einen Wertebereich von 0...65534. Die Feldgeräte-Nummer ist eindeutig
bezogen auf die Zentrale. Sie umfasst einen Wertebereich von 1...65534. Die
Feldgeräte-Nummer für Zentralen ist immer die Nummer 0.
Mit diesen ersten Teilen lassen sich eindeutig der Hostname und damit die IP-
Adresse bestimmen, die das Gerät hat. Ein Gerät wird immer nur über eine IP-
Adresse angesprochen.
Der Path dient dazu, Objekte innerhalb des Gerätes zu identifizieren. Er besteht
meist aus 0 oder 1, seltener aus 2 oder mehr Einträgen. Für Objekte, die nur einmal
pro Gerät vorhanden sind, ist der Path leer. Objekte wie z.B. Detektoren, die sich
über einen Eintrag identifizieren lassen, haben die Nummer als Path-Eintrag. Nur
Objekte, die unterhalb solcher mehrfach vorhandenen Objekte stehen, wie z.B. Ein-
träge in einer Matrix, die mehrfach im Gerät vorkommt, haben mehr als einen Eintrag
(z.B. 3).

Die Struktur des Pfades ist durch Member und OType eindeutig gekennzeichnet. Das
Feld Method im BTPPL Telegramm gibt die aufzurufende Schnittstellenfunktion (Me-
thode) an.
Die Nichtverfügbarkeit eines von der Zentrale aufgerufenen Leistungsmerkmals

muss zu einer erkennbaren Reaktion des Feldgeräts führen. Dazu wird der aufru-
fende Befehl vom Feldgerät mit einem negativen Returncode quittiert, explizite OCIT-
O Meldungen des Feldgeräts werden nicht erwartet. Auf der Grundlage negativer Re-
turncodes kann die Zentrale entsprechende Meldungen oder Handlungen generieren
(optionales und herstellerspezifisch implementiertes Merkmal der Zentrale).
Hinweis: Reaktionen der Zentrale auf die Returncodes werden nicht festgelegt!
5.6.2.1 Auswahl der Returncodes (RetCodes)

1. Es werden die bei den Methoden stehenden RetCodes verwendet, aber nur wenn
die Bedingungen lt. Beschreibung zutreffen.
2. Treffen die Bedingungen nicht zu, werden andere passende RetCodes nach der
Definition in der XML ausgewählt: Objekt RetCode 0:66 (OCIT-O_Basis_vv.xml).
3. Falls dabei mehrere RetCodes zutreffen bzw. geeignet erscheinen, wird die Aus-
wahl nach den in der nachfolgenden Tabelle festgelegten Prioritäten durchge-
führt. Die Priorität eines RetCode Wertes hat den Zweck Mehrdeutigkeiten an der
OCIT-O Schnittstelle aufzulösen. Treffen die Bedingungen für mehrere RetCode
Werte zu, ist der RetCode mit der numerisch höheren Priorität zu senden.
Die in der Tabelle nicht farbig markierten RetCodes werden von der Anwendung er-
zeugt und über die Leitung versendet.
Die in der Tabelle grün markierten RetCodes werden von der BTPPL-Lib erzeugt und
über die Leitung versendet.
Die in der Tabelle grau markierten RetCodes werden von der lokalen BTPPL-Instanz
erzeugt und nicht über die Leitung versendet. Diese RetCodes haben deshalb eine
höhere Priorität als die RetCodes der Anwendung. Zwischen Anwendung und
BTPPL-Lib dürfen die RetCodes lokal auch mit abweichenden Prioritäten auftreten.

Prio Name Description Value
0 OK Methode erfolgreich ausgeführt 0
2 NO_SF Liste enthält keinen Sekundenframe, der die Bedingung erfüllt 1000
3 SF_NOFOLLOW Sekundenframes richtig geliefert und keine später eingetrage- 1002

nen Sekundenframes in Liste vorhanden.
4 SF_FOLLOW Sekundenframes richtig geliefert und weitere Sekundenframes, 1001

die später als diese eingetragen wurden, sind in der Liste
5 ERROR Allgemeiner Fehler 1
10 PARAM_INVALID Fehlerhafter Parameter 32
11 NOT_INACTIVE Die Liste darf nicht gestartet sein um diese Methode auszufüh- 1003
ren.
12 BUFFER_TOO_SMALL BUFFER_TOO_SMALL: wird geliefert, wenn der Sekunden- 1005

frame so groß werden kann, dass weniger als vier Einträge in
den Ringpuffer passen.
13 CYCLE_TOO_SHORT CYCLE_TOO_SHORT: Die angegebene Zykluszeit ist zu kurz. 1007
14 UNKNOWN_OP UNKNOWN_OP: Nicht unterstützter Operator 1008
15 NO_EVENT NO_EVENT: der Event kann aus irgendeinem Grund nicht ein- 1009
getragen werden
16 NOT_POSSIBLE wenn der Auftragstyp keine Auftragselemente zulässt, wie z.B. 1006
bei Meldungen, R09 und AMLi oder keine weiteren Aufträge o-
der Auftragselemente mehr möglich.
20 ILLEGAL_STATE Die Transaktion befindet sich im illegalen Zustand. 38
25 NOT_CONFIGURED Die angesprochene Funktion ist wegen fehlender Versorgung 34

nicht verfügbar
29 EXISTS_ALREADY Element existiert bereits, Funktion wurde nicht ausgeführt. 36
30 INTERVALL_INVALID ungültiges oder bereits abgelaufenes Intervall angegeben 33
45 ACCESS_DENIED Der Zugriff auf die gewünschte Funktion ist nicht erlaubt. 35
46 ERR_METHOD BTPPL: angegebene Methodennummer ist nicht bekannt/imple- 8

mentiert.
47 ERR_PATH_VAL Keine Instanz zu angegebenem Pfad (Wert) gefunden 17
48 ERR_PATH_LEN Unerwartete Pfadlänge 16
49 ERR_TYPE BTPPL: Typ, bestehend aus ODG-MemberId und OType ist 7

nicht bekannt/implementiert.
50 ERR_DEST_UNKNOWN BTPPL: unbekannte Zieladresse 9
90 TOO_MANY Funktion konnte wegen Ressourcenbegrenzung nicht ausge- 37

führt werden.

Prio Name Description Value
100 ERR_BAD_CALLCHK BTPPL: Die Methode wurde mit einer falschen Checksumme 2
aufgerufen.
101 ERR_BAD_CALLTIME BTPPL: Die Uhrzeit des Aufrufs stimmt nicht auf 30 Minuten ge- 3
nau mit der lokalen Uhrzeit überein.
102 ERR_BAD_RETCHK BTPPL: Wird nach der Übertragung vom Sender generiert, 4
wenn die Prüfsumme beim Return-Telegramm nicht überein-
stimmt.
103 ERR_BAD_RETTIME BTPPL: Wird nach der Übertragung vom Sender generiert, 5
wenn die Uhrzeit des Returnblockes nicht stimmt, der Sende-
block aber korrekte Uhrzeit hatte. In diesem Fall wurde der Be-
fehl bereits durchgeführt, es ist aber eine Synchronisation der
Uhrzeit notwendig. Wenn der Code nach der Zeitsynchronisa-
tion wieder auftritt, deutet dies auf Hacker oder Bug hin.
105 ERR_FRAME BTPPL: invalid Header(length, flags, fletcher checksum) 13
200 ERR_SYNCHRONIZE BTPPL: Wird nach der Übertragung vom Sender generiert, 6
wenn die Uhrzeit des Returnblockes nicht stimmt und der Be-
fehl bereits vom Sendeblock her eine falsche Uhrzeit hatte. Die-
ser Code wird zwischen Steuergerät und Zentrale nicht verwen-
det.
200 OSERR Allgemeiner Systemfehler 18
201 ERR_DEST_UNREACHABLE BTPPL: Ziel zwar bekannt aber z.Zt. nicht erreichbar 10
202 ERR_TIMEOUT BTPPL: Funktion wurde mit Timeout abgebrochen 11
203 ERR_NOREQUEST BTPPL: no Request found to send the Respond 12
204 OSERR_SOCKET Systemfehler beim Anlegen von socket 19
205 OSERR_BIND Systemfehler bei bind 20
206 OSERR_CONNECT Systemfehler bei connect 21
207 OSERR_WRITE Systemfehler bei write 22
208 OSERR_READ Systemfehler bei read 23
209 OSERR_LOCK Systemfehler bei mutex grab/release 24
5.6.3 DNS-Cache-Invalidierung
Es ist möglich, dass während des Betriebs die IP-Adresse des Feldgeräts gewech-
selt wird (nicht jedoch sein Hostname!). BTPPL sollte nicht für jeden Befehl eine
DNS-Abfrage machen, da diese Abfrage ressourcen- und zeitraubend ist. Stattdes-
sen sollten die Ergebnisse der Abfrage gecachet werden. Um die Kohärenz des
Caches zu gewährleisten, muss in BTPPL eine DNS-Cache-Invalidierung stattfinden.
Sobald diese stattfindet, müssen die entsprechenden Adressen neu bestimmt wer-
den:

 Beim Empfangen einer Übertragung mit einem falschen SHA-1 Passwort
 Nach einem mehrfachen Timeout
 Beim Hochlaufen
5.7 Sicherung der Übertragung beim OCIT-Outstations Protokoll

 OCIT-Outstations Telegramme werden durch verschiedene Maßnahmen gegen
Datenverfälschungen oder Angriffe von außen geschützt.
 OCIT-O Passworte, die jeder Kommunikationspartner versorgt hat.
 Die Übertragungssicherung gegen Datenverfälschungen sowie z.B. fehlgelei-

tete UDP-Pakete oder Angriffe von außen erfolgt durch einen Fletcher-Algorith-
mus.
 Eine erhöhte Sicherheit gegen Angriffe von außen wird bei der Übertragung si-
cherheitsrelevanter Daten benötigt und durch einen SHA-1 Algorithmus ge-
währleistet (der aus den Passworten und dem Dateninhalt die Prüfsumme be-
rechnet).
 Die Übertragungssicherung gegen Datenverfälschungen erfolgt in der Trans-

portebene (und bei Verwendung von PPP auch im Data-Link-Layer) jeweils
durch das Protokoll.
5.7.1 OCIT-O Passworte

Für die Übertragungssicherung werden Passwörter verwendet, die von den jeweili-
gen Empfängern zur Kennzeichnung oder Überprüfung des Absenders und zur SHA-
1 Übertragungssicherung (siehe Pkt. 5.7.3) verwendet werden. Die Anwendung die-
ses Verfahrens hat den Vorteil, dass die Systemzugänge und andere Verbindungen
nicht zwingend über Firewall gesichert werden müssen.
Feldgeräte kennen mindestens folgende OCIT-O Passwörter:

 Passwort des Feldgerätes selbst (bei Auslieferung vorbelegt mit
„OCITPASSWORT“)
 Passwort der Zentrale (bei Auslieferung vorbelegt mit „OCITPASSWORT“)
 Passwort der Ersatzzentrale
 Passwort des zentralen Systemzugangs
 Passwort für unbekannte IP-Adressen (Default)
Für jede dieser Verbindungen ist ein Paar von Passwörtern notwendig:
 Das Passwort des Gerätes selbst (Passwort des Feldgeräts, der Zentrale oder
der anderen Einrichtungen)
o zur Kennzeichnung des Absenders und
o zur SHA-1 Datensicherung der ausgehenden Kommunikation.

 Das Passwort des jeweiligen Kommunikationspartners
o zur Prüfung auf Zulässigkeit der eingehenden Kommunikation und
o zur Kennzeichnung des Absenders von Request–Telegrammen.
Als Passwort wird bei Request- und Message-Telegrammen das Passwort des Ab-
senders verwendet, bei Respond-Telegrammen das Passwort des Absenders des
zugehörigen Request-Telegramms.
Da definitionsgemäß eine zentrale Einrichtung die Passwörter in den Feldgeräten än-

dern kann, ist es notwendig, dort für jedes Feldgerät die entsprechenden Passwort-
paare vorzuhalten. Mehr dazu im Dokument OCIT-O Basis, Systemobjekt Remo-
teDevice
Hinweis: Vorzugsweise sollen alle Feldgeräte innerhalb eines zentralen Systems das
gleiche Feldgeräte-Passwort verwenden.
5.7.1.1 Installation eines neuen Gerätes
 Das Gerät wird mit dem Standard OCIT-O Passwort "OCITPASSWORT" aus-
geliefert.
 In der Zentrale wird ein OCIT-O Passwort P1 gespeichert. (Zum Wechsel der
Passwörter wird ein zweiter Eintrag P2 in der Zentrale angelegt, der im Normal-
fall mit dem OCIT-O Passwort P1 belegt ist). Das OCIT-O Passwort P1 wird bei
Auslieferung der Zentrale ebenfalls mit "OCITPASSWORT" vorbelegt.
 Die Zentrale führt als ersten Befehl einen Wechsel des Standard OCIT-O Pass-
worts im Gerät auf das Passwort durch, welches in der Zentrale verwendet wird
(Vorgehen s.u.).
5.7.1.2 Wechsel des OCIT-O Passworts eines Feldgerätes
Das OCIT-O Passwort wird nur von der Zentrale aus gewechselt. Der Wechsel findet
folgendermaßen statt:
 Die Zentrale schickt einen Passwort-Wechselbefehl an das Gerät.
 Das Gerät wechselt das Passwort aus und verwendet sofort das neue OCIT-O
Passwort. Die Antwort wird nicht gesichert übertragen. Alle folgenden Antwor-
ten sowie alle Befehle des Gerätes zur Zentrale codiert es mit dem neuen
OCIT-O Passwort.
 Die Zentrale akzeptiert nach dem Aufruf nur Antworten nur mit dem neuen
OCIT-O Passwort.
Alle im Retry-Cache verbliebenen Nachrichten werden mit dem neuen OCIT-O Pass-
wort umcodiert.

5.7.2 Übertragungssicherung durch den Fletcher-Algorithmus
Übertragungssicherung gegen Datenverfälschungen wird bei allen OCIT-Outstations
Telegrammen durch einen Fletcher-Algorithmus (Prüfsumme) erreicht. Außerdem
können damit z.B. fehlgeleitete UDP-Pakete eliminiert werden. Der Fletcher-Algorith-
mus ist Bestandteil des OCIT-Outstations Protokolls.
Alle Pakete mit falscher Fletcher-Prüfsumme werden verworfen.
Der Fletcher-Algorithmus ist ein einfacher aber effektiver Algorithmus, der nur 2 Byte
pro Paket erfordert. Er ist ein eher unbekannter Algorithmus, was Ad-hoc-Angriffe er-
schwert:
unsigned char c0, c1;
void initialize_fletcher()
{
c0 = c1 = 0;
}
void do_check(unsigned char inbyte)

{
c0 = (c0 + inbyte) % 255;
c1 = (c1 + c0) % 255
}
short fletcher()
{
unsigned char hi_fletcher = 255 - ((c0 + c1) % 255);
unsigned char lo_fletcher = c1;
return ((short)hi_fletcher << 8) | lo_fletcher;
}
char check_fletcher()
{
return (c0 == 0) && (c1 == 0);
}
Um den Algorithmus auszuführen, muss vor der Bildung der Prüfsumme initia-
lize_fletcher aufgerufen werden, pro Byte Sachdaten dann do_check und schließlich
mit fletcher die Prüfsumme gebildet werden. Um die Prüfsumme zu verifizieren, wird
do_check über den Block Sachdaten und (!) die Fletcher-Prüfsumme durchgeführt
und dann mit check_fletcher geprüft, ob die Prüfsumme korrekt ist.

In Assembler ist der Algorithmus noch effizienter, da die do_check Operation z.B. in
8086-Assembler so gelöst werden kann:
MOV al, c0 ; c0 in den Accu laden
ADD al, inbyte ; Carry-Flag ist gesetzt, wenn das Ergebnis >= 256 ist
ADC al, 01 ; Ergebnis ist richtig, wenn die Summe 255 oder 510 ist,
sonst 1 zu gross
; Wenn das Ergebnis richtig ist, ist auch das Carry-Flag gesetzt
ADC al, FF ; -1, wenn das Carry-Flag nicht gesetzt ist, sonst +-0
MOV c0, al ; c0 abspeichern
ADD al, c1 ; c1 hinzuaddieren
ADC al, 01 ; s.o.
ADC al, FF ; s.o.
MOV c1, al ; c1 abspeichern
Der Algorithmus kann selbstverständlich noch weiter optimiert werden. Das Beispiel
verwendet nur 8-Bit Operationen und ist damit für die Portierung in einen Embedded-
Controller geeignet.
Mit dem oben beschriebenen Fletcher-Algorithmus werden alle OCIT-Outstations Te-

legramme 'gesichert'. Dadurch wird erreicht, dass die wenigsten zufällig vagabundie-
renden UDP-Telegramme, die von Nicht-OCIT-Software stammen, als gültige Tele-
gramme akzeptiert werden und damit das Geschehen durcheinanderbringen. Weiter-
hin werden Angriffsversuche von Nichtfachleuten unwahrscheinlich gemacht.
5.7.3 Übertragungssicherung durch den SHA-1 Algorithmus

Sicherheitsrelevante Kommunikation wie z.B. neue Grundversorgungen oder Be-
triebsmeldungen wird zusätzlich noch durch einen SHA-1 Algorithmus gegen beab-
sichtigte Zugriffe gesichert. SHA-1 ist ein Prüfsummenverfahren, das jede unberech-
tigte Übertragung erkennt und verwirft. SHA-1 wird in anderem Zusammenhang auch
zur Bildung digitaler Unterschriften eingesetzt und ist weltweit als sicher anerkannt.
Der SHA-1 Algorithmus dient nicht zur Verschlüsselung, sondern nur zur Checksum-
menbildung (Verschlüsselungsalgorithmen bedürfen in vielen Ländern einer geson-
derten Exporterlaubnis). Die Wahrscheinlichkeit, dass ein falsches Paket als richtig
erkannt wird, ist kleiner als 10-48.
Der SHA-1 Algorithmus ist nach aktuellem Kenntnisstand frei von Patentrechten.
(Dokumentation unter http://csrc.nist.gov/cryptval/shs.html )
Weiteres:
 Nach heutigem Wissensstand ist die Chance, durch Kenntnis von bisher über-
tragenen Paketen ein Paket zu konstruieren, gegenüber der Wahrscheinlich-
keit, das OCIT-O Passwort zu erraten, vernachlässigbar.
 Es wird davon ausgegangen, dass während der Installationsphase des Gerätes

kein Lauscher die Datenübertragung mit verfolgt.
 Während der normalen Datenübertragung kann der Datenaustausch mitgele-

sen werden.

 Es soll verhindert werden, dass gültige Datenpakete über Tage hinweg gesam-
melt und anschließend in das Gerät übertragen werden.
 Gesicherte Datenpakete, die länger verzögert werden, werden automatisch un-

gültig.
 Die eigentliche Datenübertragung erfolgt im Klartext, um Debugging zu erleich-

tern, und um nicht mit Kryptologieverboten bestimmter Länder zu kollidieren.
 Die Absicherung erfolgt über ein OCIT-O Passwort, welches von der Zentrale
geändert werden kann. Ein Lauscher, der nicht das alte OCIT-O Passwort
kennt, kann nicht das neue OCIT-O Passwort erfahren.
5.7.3.1 Bildung der Prüfsumme
Bevor die Prüfsumme gebildet wird, wird das UTC-Feld des BTPPL Datenblocks mit
der aktuellen Systemzeit gefüllt.
Zur Bildung der Prüfsumme wird der SHA-1 Algorithmus über folgenden Block aus-
geführt:
 OCIT-O Passwort des Absenders (kein Längenbyte, ISO8859-1 Codierung)

aufgefüllt mit binär-0 auf 512 Bit. (Der Algorithmus komprimiert in 512-Bit
Schritten, dadurch kann dieser erste Block vorberechnet und gespeichert wer-
den).
 BTPPL-Datenblock beginnend mit HdrLen (einschließlich) bis UTC (LSB) (ein-

schließlich).
 OCIT-O Passwort des Absenders (kein Längenbyte, ISO8859-1 Codierung).

Die so ermittelte Prüfsumme wird in das SHA-1 Datenfeld des BTPPL-Datenblocks
geschrieben. Anschließend wird der Fletcher-Algorithmus über den gesamten
BTPPL-Datenblock beginnend ab Feld HdrLen (Offset 4 bei TCP, Offset 0 bei UDP)
durchgeführt.
5.7.3.2 Übertragen eines Befehls
Befehle können in drei verschiedene Sicherheitsstufen übertragen werden:
1.) SHA-1 bei Request und Respond (hohe Sicherheit)

2.) SHA-1 bei Request aber nicht bei Respond (mittlere Sicherheit)
3.) kein SHA-1
Mit SHA-1 gesicherte Befehle:
 Für jeden Befehl, der in der OCIT-Outstations Type-Datei als sicherheitsrele-

vant gespeichert wird, wird die Prüfsumme mit OCIT-O Passwort P1 erzeugt
und an das Ende des Parametersatzes angefügt.

 Der Empfänger bildet für jeden sicherheitsrelevanten Befehl ebenfalls die Prüf-
summe und vergleicht seine berechnete Prüfsumme mit der übertragenen Prüf-
summe.
 Wenn beide Werte voneinander abweichen, wird der Befehl mit einem Fehler
zurückgewiesen und eine Meldung an die Zentrale abgesetzt.
 Der Empfänger vergleicht, ob die Uhrzeit, die im Befehl mit übertragen wird, um
mehr als ± 30 Minuten von der internen Uhrzeit abweicht. Wenn die Uhrzeit ab-
weicht, wird der Befehl mit einem Fehler zurückgewiesen und ebenfalls eine
Meldung an die Zentrale abgesetzt.
 Die Antwort des Befehls wird ebenfalls mit der Prüfsumme versehen und an
den Sender zurückgeschickt. Als Passwort wird das gleiche OCIT-O Passwort
verwendet, welches auch beim Request eingesetzt wurde.
 Die Zentrale vergleicht die Prüfsumme mit dem OCIT-O Passwort für das Ge-
rät. Schlägt dieser Vergleich fehl wird die Rückmeldung als falsch interpretiert.
 In der Rückantwort für die falsche Uhrzeit ist die lokale Uhrzeit mit enthalten.
Dieser Fall sollte eigentlich nicht auftreten, da die Geräte immer die korrekte
Uhrzeit haben sollten. Um in einem solchen Fall trotzdem Befehle schicken zu
können, muss der Client ein ungesichertes GetTime des Systemobjekts aufru-
fen und sich beim Befehl an die falsche Zeit anpassen.

5.7.3.3 Vom Sicherheitsprotokoll verwendete Returncodes
Folgende Basisreturncodes werden durch das Sicherheitsprotokoll generiert/verwen-

det:
Memo Nummer Beschreibung
ERR_BAD_CALLCHK Die Funktion wurde mit einer falschen Check-

summe aufgerufen. Deutet auf Hacker, Bug o-
der falsches OCIT-O Passwort hin.
ERR_BAD_CALLTIM Die Uhrzeit des Aufrufs stimmt nicht auf 30 Mi-

E nuten genau mit der lokalen Uhrzeit überein.
ERR_BAD_RETCHK Wird nach der Übertragung vom Sender gene-

riert, wenn die Prüfsumme beim Return-Tele-
gramm nicht übereinstimmt. Deutet auf Hacker,
Bug oder falsches OCIT-O Passwort hin.
ERR_BAD_RETTIME Wird nach der Übertragung vom Sender gene-

riert, wenn die Uhrzeit des Returnblockes nicht
stimmt, der Sendeblock aber korrekte Uhrzeit
hatte. In diesem Fall wurde der Befehl bereits
durchgeführt, es ist aber eine Synchronisation
der Uhrzeit notwendig. Wenn der Code nach
der Zeitsynchronisation wieder auftritt, deutet
dies auf Hacker oder Bug hin.
ERR_SYNCHRONIZE Wird nach der Übertragung vom Sender gene-

riert, wenn die Uhrzeit des Returnblockes nicht
stimmt und der Befehl bereits vom Sendeblock
her eine falsche Uhrzeit hatte. Dieser Code
wird zwischen Steuergerät und Zentrale nicht
verwendet. Wenn der Code nach der Zeitsyn-
chronisation wieder auftritt, deutet dies auf Ha-
cker oder Bug hin.
5.8 Prüfung des TCP-Kanals

Um zu prüfen, ob der Kanal noch offen ist, kann der Client oder der Server ein Test-
telegramm über den TCP-Kanal schicken. Das Testtelegramm sind einfach 4 Byte
Nullen in Folge. Da BTPPL an dieser Stelle die Länge eines folgenden Pakets erwar-
tet (in diesem Fall also 0), kann das Testtelegramm einfach eingebaut werden.

6 Typisierung
6.1 Schnittstellenobjekte
Eine Idee von OCIT-Outstations ist, die Schnittstelle in formaler maschinenlesbarer
Form festzulegen. Dazu dient folgendes Metamodell:
Abbildung 4: Metamodell
6.1.1 Grunddatentypen:
In SimpleDomain.Basetypename (Entry BASETYPENAME) können folgende Grund-
datentypen angegeben werden:
Grund- Datentyp in C Maximal gültiger Übertragungsart Bemerkung
datentyp Bereich
BYTE signed char -128 ... +127 als 1 Byte übertragen 8-Bit mit Vorzeichen
(ohne alignment)
UBYTE unsigned char 0 ... 255 als 1 Byte übertragen 8-Bit ohne Vorzeichen
(ohne alignment)
SHORT signed short -32.768 ... 32.767 als 2 Byte übertragen, 16-Bit mit Vorzeichen
High-Byte zuerst (ohne
alignment)
USHORT unsigned short 0 ... 65.535 als 2 Byte übertragen, 16-Bit ohne Vorzeichen
alignment)

Grund- Datentyp in C Maximal gültiger Übertragungsart Bemerkung
datentyp Bereich
LONG signed long -2.147.483.648 ... als 4 Byte übertragen, 32-Bit mit Vorzeichen
2.147.483647 High-Byte zuerst (ohne
alignment)
ULONG unsigned long 0 ... 4.294.967.295 als 4 Byte übertragen, 32-Bit ohne Vorzeichen
alignment)
FLOAT float -1E38 ... 1E38 Codierung wie Codierung 32-bit Fließkommazahl
eines Einzel-Float in 4
Byte in CDR, aber ohne
alignment
DOUBLE double -1E308 ... 1E308 Codierung wie Codierung 64-bit Fließkommazahl
eines Einzel-Float in 8
Byte in CDR, aber ohne
alignment
STRING struct { Längenwort des folgenden Feldes (2 BYTE) 1, Null-terminierter ANSI
USHORT len, String (ISO 8859-1 [Latin-1]) Steuerzeichen werden ignoriert
char str[ ] }
BLOB struct{ ULONG Binary large object, in dem die Daten opaque übertragen werden.
sz, BYTE data[
]}
Tabelle 1: Grunddatentypen
Vererbung im Metamodell (ENTRY BASEDOMAIN in StructDomain) für:
 DynAttribut
Die dynamischen Attribute werden vererbt, d.h. eine spezialisierte Klasse hat
auch alle dynamischen Attribute ihrer Basisklasse(n).
 STDMETHODS
Standardmethoden werden nicht vererbt. Grund: Die Signatur von Get, Update
hängt von den dynamischen Attributen der Domain ab.
 Methoden
werden vererbt, die Methodennummern sind jedoch absolut anzugeben, dabei
ist zu beachten, dass sie kleiner als die größte Standardmethodennummer
(=15), größer als MAXMETHODNR der Basisklasse und kleiner als
MAXMETHODNR der eigenen Klasse sein müssen.
 Path
wird mit vererbt. Wenn die Basisklasse einen Path definiert, hat auch die spezi-
alisierte Klasse mindestens den gleichen Path. Falls die BASEDOMAIN bereits
ein OBJTYPE ist, muss auch die spezialisierte Domain eine OBJTYPE Domain
sein. In der OCIT-Outstations Type Datei wird der Path nicht neu angegeben.
1 Beim String „abc“ ist die Länge 4!

6.1.2 Metaelement DECL
Das Element REFERENCE verweist auf einen anderen Typ (Domain) und kann so-
mit alle zulässigen DOMAIN Typen referenzieren (NUMBERDOMAIN,
STRINGDOMAIN, STRUCTDOMAIN, OBJTYPE etc.).
Die Elemente EXTENSIBLE und REFPATH bzw. REFPATH_DATA geben an, was
an der Stelle dieser DECL vom referenzierten Typ übertragen wird.
REFPATH und REFPATH_DATA sind alternativ und nur bei Referenzen auf Objekt-
Typen (OBJTYPE-Domains) zulässig. Wenn weder REFPATH noch
REFPATH_DATA angegeben ist, werden die Daten des referenzierten Typs allein
übertragen. Bei SimpleDomain ist dies das Datum des Typs selbst, bei StructDomain
die ggf. vorhandenen dynamischen Attribute.
6.1.3 REFPATH
Wenn REFPATH gesetzt ist, wird eine Referenz in Form eines Pfads (daher der
Name) auf das Objekt, welches in der DECL angegeben ist, übertragen. Wenn z.B.
ein Verweis auf einen relativen Knoten benötigt wird, wird in der DECL das Objekt
„Relativer Knoten“ angegeben und REFPATH gesetzt. Abhängig vom durch
REFPATH angegebenen Wert (siehe weiter unten) wird also ein bestimmter Teil des
Pfades des referenzierten Objekts übertragen. REFPATH darf nur gesetzt werden,
wenn REFERENCE auf eine OBJTYPE-Domain zeigt (nur OBJTYPE-Domains ha-
ben einen PATH).
Eine leere REFPATH / REFPATH_DATA ohne Wert ist unzulässig.
Der Pfad ist weltweit eindeutig. Er beginnt mit
 Betreiber –Domain (String)
 ZNr (2 Byte)
 FNr (2 Byte)
und ist dann je nach Objekttyp unterschiedlich. Im Fall des relativen Knotens folgt
noch genau ein Byte mit der relativen Knotennummer. Bei Signalgruppen folgen zwei
Werte: Die relative Knotennummer und die Signalgruppennummer. Der Pfad ist somit
hierarchisch aufgebaut.
Da der erste Teil des Pfades in den allermeisten Fällen redundant ist, kann bei
REFPATH angegeben werden, wie viele Elemente aus dem einbettenden Objekt
übernommen werden können und deshalb nicht explizit übertragen werden. Wenn
also in einem Befehl an ein Signalprogramm eines Kreuzungsgerätes (der Befehl ist
in das BTPPL-Telegramm eingebettet) eine Liste von AP-Werten (die in den Signal-
programm-Befehl eingebettet sind) adressiert wird, teilt sich die Referenz wie folgt
auf:
 Der BTPPL-Header enthält Betreiber-Domain (implizit), ZNr und FNr

 Der Pfad des BTPPL-Headers adressiert den Signalprogramm-Befehl über re-
lative Knotennummer und Signalprogrammnummer
 Jeder einzelne AP-Wert wird nur über den Namen adressiert.
REFPATH kann positive und negative Werte annehmen. Wenn REFPATH >= 0 ist,
wird die Anzahl von Elementen (hierarchischen Pfadanteilen) codiert, die aus dem
einbettenden Objekt übernommen werden. Der Rest der Pfadelemente des Zielob-
jekts wird anstelle der Referenz übertragen.
Die wichtigsten Werte sind:
0: Keine implizite Übernahme von Pfadanteilen, d. h. alle Pfadelemente des

Zielobjekts Betreiber-Domain, ZNr, FNr sowie alle weiteren Pfadanteile
werden übertragen.
1: Betreiber-Domain wird implizit übernommen. ZNr, FNr und der weitere

Pfad des referenzierten Objektes werden übertragen.
3: Gerätebezogen. Betreiber, ZNr, FNr werden implizit übernommen, der

weitere Pfad innerhalb des Feldgeräts wird übertragen
4: Bezogen auf den relativen Knoten, sofern das eingebettete Objekt über-
haupt auf den relativen Knoten bezogen ist. Übertragen werden die
Pfadanteile hierarchisch nach dem relativen Knoten
5: Objektbezogen auf das umschließende Objekt. Ein umschließendes Ob-

jekt referenziert ein in sich enthaltenes Objekt. Vom referenzierten Objekt
werden alle zusätzlichen hierarchischen Pfadanteile, die nicht bereits Teil
des es umschließenden Objektes sind, übertragen.
Wenn REFPATH < 0 ist, bedeutet dies: Als Referenz werden nur die folgenden n-
letzten Werte übertragen. Bei –1 z.B. wird die Referenz nur durch das letzte Pfad-
Element des Zielobjekts aufgebaut, bei –2 durch die beiden letzten Pfad-Elemente
des Zielobjekts usw.
Wenn REFPATH nicht gesetzt ist, wird keine Referenz übertragen (also nur die Da-
ten wie bei 6.1.2 dargestellt.).
6.1.3.1 REFPATH_DATA
REFPATH_DATA überträgt wie REFPATH den Pfad, führt aber zusätzlich am Ende
des Pfades die Datenelemente mit, also die eventuell vorhandenen dynamischen At-
tribute. Die Nummerierung ist dieselbe wie bei REFPATH.
6.1.3.2 EXTENSIBLE
Hinweis: Funktion wurde gegenüber Vorgängerversion geändert (DataLen = 2 oder 4

Byte)!
EXTENSIBLE wird angegeben, wenn unterschiedliche Objekttypen, die von dem in

der DECL angegebenen Datentyp abstammen, übertragen werden. Das Element

EXTENSIBLE kann ohne Inhalt (z.B.: <EXTENSIBLE/>) oder mit der Ziffer '4' als In-
halt angegeben werden. Im ersteren Fall wird die DataLen mit 2 Bytes als USHORT,
wenn der Inhalt 4 ist, wird die DataLen mit 4 Bytes als ULONG übertragen.
Bei gesetztem EXTENSIBLE werden bei gesetztem REFPATH bzw.
REFPATH_DATA vor den REFPATH drei Elemente gesetzt:
 Länge der übertragenen Daten der Referenz (inkl. Member/OType) in Byte

(Wertebereich 4...255)
 Member (2 Byte)
 OType (2 Byte)
es folgt der Pfad des durch Member und OType gegebenen Typs.
Bei REFPATH_DATA folgt noch:
 DataLen, Länge der folgenden Daten in Bytes als 2 oder 4 Byte codiert (siehe
oben).
 Daten des durch Member, OType gegebenen Typs (bei SimpleDomain ist dies
das Datum des Typs selbst, bei StructDomain die ggf. vorhandenen dynami-
schen Attribute).
Ist EXTENSIBLE ohne REFPATH oder REFPATH_DATA gesetzt, wird an Stelle die-
ser DECL folgendes übertragen:
 Member (2 Byte)
 OType (2 Byte)
 DataLen, Länge der folgenden Daten in Bytes als 2 oder 4 Byte codiert (siehe
oben).
 Daten des durch Member, OType gegebenen Typs (bei SimpleDomain ist dies
das Datum des Typs selbst, bei StructDomain die ggf. vorhandenen dynami-
schen Attribute).
6.1.3.3 MINCOUNT MAXCOUNT
Die Felder MINCOUNT und MAXCOUNT geben die Anzahl der in dieser DECL de-
klarierten Elemente an. Beide Felder sind optional, wenn sie fehlen gilt
MINCOUNT=MAXCOUNT=1, d.h. immer genau ein Element des in REFERENCE
angegebenen Typs. MAXCOUNT muss immer größer oder gleich MINCOUNT sein.
Falls MAXCOUNT größer MINCOUNT ist, handelt sich es um ein Array. In diesem
Fall wird die Anzahl der tatsächlichen Elemente vorangestellt. Diese Anzahl ist ein
UBYTE, falls MAXCOUNT-MINCOUNT <256, sonst ein USHORT.
PATHPART darf keine Arrays enthalten, d.h. MINCOUNT=MAXCOUNT=1.

6.1.4 Metaelement MSGPART
Das Metaelement MSGPART ist nur eine spezielle STRUCTDOMAIN, bei der drei
ClassAttributes vordefiniert sind: CATEGORY, DEGREE und FORMAT. CATEGORY
enthält die Meldungskategorie als Zahl, DEGREE den MeldungsDegree als Zahl und
FORMAT den Formatstring.
6.1.4.1 Formatstrings
Hinweis: Funktion wurde gegenüber Version 1.1 erweitert (Formatstring für Check-
summen)!
Im Rahmen von OCIT ist es möglich, den Standard um herstellerspezifische Objekte

und Methoden zu erweitern. Um diese Erweiterungen auch anderen Herstellern bei
Einsatz von herstellergemischten Systemen zugänglich zu machen, sind diese Ob-
jekte vollständig als xml-Datei (<hersteller>AddOns.xml) zu beschreiben. Hierbei ist
die im OCIT-Standard vorgegebene Nomenklatur zu verwenden. Dies ist insbeson-
dere bei den Nebenmeldungen relevant. Damit diese von der Zentrale zur Anzeige
automatisch geparst und verarbeitet werden können und eine Klartextanzeige dieser
Meldungen an der Oberfläche möglich ist, muss das Format exakt eingehalten wer-
den. Es wird lediglich ein kurzer charakteristischer Text für die Meldung hinterlegt.
Er kann einen beliebigen Text und zusätzlich Werte der Meldung enthalten. Da eine
Meldung aber i.d.R. mehrere Meldungsparameter hat, die unterschiedliche Werte
enthalten, muss der Wert zur Laufzeit in den Formattext eingesetzt werden. Um an-
zuzeigen, welcher Wert eines Meldungsparameters eingesetzt werden soll, muss im
Formattext der Name des Parameters zwischen @-Zeichen stehen.
Die Namen bzw. Bezeichner der Meldungsparameter, die in einen Formatstring mit
@...@ eingesetzt werden können, müssen dem sich ergebenden „Pfad“ zum darzu-
stellenden Wert entsprechen (im folgenden bezeichnet als ValuePath). Im einfachs-
ten Fall ist der ValuePath einfach der einfache Name des Meldungsparameters. Oft
wird aber ein Wert über mehrere Objektreferenzen angesprochen, damit ergibt sich
ein durch Punkt getrennter ValuePath. Der ValuePath ist beispielsweise in der html-
Dokumentation des Typetool dargestellt.
Beispiel: Eine Nachricht hat den Meldungsparameter mit dem ValuePath
a.b.c mit dem Wert 4711
In der Grammatik muss dann der Formattext wie folgt aussehen:
<FORMAT>Der Wert ist @a.b.c@</FORMAT>
Nach Auswertung des Formatstrings wird der Formattext dann wie folgt angezeigt:
Der Wert ist 4711
Besonderheit bei Arraywerten:

Enthält eine Meldung Arraywerte, können auch diese im Formattext angezeigt wer-
den. Wenn eine Nachricht z.B. folgenden Parameter und Werte enthält

x.y[0].z = 4712
x.y[1].z = 4713
dann können die Werte mit dem folgenden Formattext angezeigt werden:
<FORMAT>Arraywerte @x.y[].z@</FORMAT>
Nach Auswertung des Formatstrings werden dann alle Werte des Arrays angezeigt:
Arraywerte [ 4712 4713 ]
Für Checksummen wird folgende Darstellung verwendet:
Die erzeugten Checksummen (20 Byte) sollen aus Gründen der Lesbarkeit in 10
Gruppen je 4 Hexadezimalzeichen dargestellt werden. Beispiel: CAFE-1234-ABCD-
5678-A1B2-C3D4-1A1D-1234-CAFE-ABBA
6.1.5 METHOD
Dieses Metaelement beschreibt eine Methode. Eine Methode hat eine eindeutige
Nummer innerhalb des Interfaces bzw. OBJTYPES (und seiner Basisdomains), in
welchem sie steht.
Eine Methode hat Eingabe- und Ausgabeparameter, welche in den Entrys IN und
OUT deklariert werden. BTPPL überträgt die Eingabeparameter mit einem Request,
die Ausgabeparameter mit einem Respond Telegramm.
Im Entry AUTH wird angegeben ob:
 Request und Respond (AUTH=Full)
 nur der Request (AUTH=Request)
 weder Request noch Respond (AUTH=None)
mit SHA-1 Authentifizierung auszuführen ist.
Hinweis: In den OCIT-O Versionen 1.0 und 1.1 ist die Art Authentifizierung nicht bei
allen Methoden wählbar. Falls der Tag AUTH in der Definition der Methoden fehlt,
wird dies als AUTH=None betrachtet.
6.1.6 CLASSATTRIBUTE
Die Elemente bilden frei definierbare Attribute einer StructDomain nach dem Key/Va-
lue Prinzip. Ein CLASSATTRIBUTE besteht aus dem Tag NAME, dem Key, sowie
dem Tag VALUE, dem Wert, und einer zusätzlichen beliebigen Beschreibung. Die
Bedeutung ist abhängig vom konkreten Typ (Domain), d.h., ein CLASSATTRIBUTE
eines MSGPART-Typ besitzt üblicherweise eine andere Bedeutung als beispiels-
weise das eines Auftrags (OBJTYPE). Innerhalb eines Typs (StructDomain,
MSGPART oder OBJTYPE) ist ein Key eindeutig. Sie sind also für alle Objektinstan-
zen eines Typs bekannt und gültig. Die Attribute dienen dazu, Definitionen, die nicht
durch die übliche Form des XML Metamodels in der Spezifikation zu beschreiben
sind, in maschinenlesbarer Form zu hinterlegen. Der Inhalt des VALUE-Tags ist ab-
hängig vom Key (CLASSATTRIBUTE-Typ, Tag NAME). Die Verwendung der Attri-
bute wird im folgenden spezifiziert.
6.1.6.1 FRAME
(Key ist definiert für OBJTYPE, Auftrag): Spezifiziert den Auftragsframe, der von die-
sem Auftrag in einen Sekundenframe geschrieben wird. Das VALUE-Tag gibt die Re-
ferenz auf Member/OType einer von 0:290 abzuleiteten Structdomain an, die das
Frameformat beschreibt. Die referenzierte Domain beschreibt einen kompletten Auf-
tragsframe. Der Auftragsframe ist anzugeben mit <Member#>:<AuftragsFrame_Typ-
name> (Beispiel: 0:MWAuftragFrameR09). Das Attribut kann für Aufträge verwendet
werden, für die das Datenformat statisch ist, z.B. RBL-Telegramme.
6.1.6.2 FRAME_DATA
(Key ist definiert für OBJTYPE, AE): Spezifiziert die Nutzdaten, die von diesem Auf-
tragselement in den Auftragsframe geschrieben werden. Der VALUE-Tag gibt die
Referenz auf Member/OType einer Domain an, die das Datenformat im Auftrags-
frame beschreibt. Wird eine SimpleDomain referenziert, wird deren skalarer Wert in
den AF geschrieben. Bei einer StructDomain werden deren dynamischen Attribute in
den AF geschrieben. (Beispiel: 1:ZEITINTERVALL). Das Attribut kann für die Be-
schreibung des Datenformats von Aufträgen verwendet werden, bei denen sich das
Auftragsframeformat dynamisch aus der Zuordnung von Auftragselementen zum Auf-
trag ergibt. Das CLASSATTRIBUTE wird somit Auftragselementen zugeordnet.
6.1.6.3 CATEGORY
(Key ist definiert für MSGPART): Weist einer Meldung eine Unterkategorie zu, z.B.
Hardware, Übertragungssystem, Anwenderprogramm.
6.1.6.4 DEGREE
(Key ist definiert für MSGPART): Spezifiziert den Schweregrad einer Meldung.
6.1.6.5 FORMAT
(Key ist definiert für MSGPART): Spezifiziert einen Formattext für die Präsentation
der Meldung. Der Formatstring kann Parameter eines MSGPART-Elements enthal-
ten, die innerhalb von DECL-Tags definiert sind
6.2 Datendefinitionen
Die in OCIT-Outstations verwendeten Datendefinitionen teilen sich in OCIT-
Outstations-Objekte und Hersteller-Objekte auf. Zur ihrer exakten Beschreibung wird
der XML-Standard verwendet, der von namhaften Softwareherstellern (Microsoft,

Oracle, ...), aber auch in der Free-Software-Szene (Linux) unterstützt wird. Weiter-
führende Dokumentationen sind z.B. unter http://www.w3c.org/xml zu finden.
6.2.1 OCIT-Outstation-DTD-Datei
Die Datei OCIT-O-DTD_Vx.x.dtd beschreibt die Struktur aller im Definitionsbereich
von OCIT-Outstations verwendeter TYPE-Dateien. Siehe auch Pkt. 6.2.3.
6.2.2 OCIT-Outstations-Objekte-TYPE-Dateien
Die OCIT-Outstations-Objekte sind mittels TYPE-Dateien beschrieben:
 Die Datei OCIT-O-Basis-TYPE_Vx.x.xml enthält die Basisdefinitionen
 Die Datei OCIT-O-Feldgeräte-TYPE_Vx.x.xml enthält die Definitionen für be-

stimmte Arten von Feldgeräten.
6.2.3 Aufbau der TYPE-Dateien

Alle Type-Dateien sind wie folgt aufgebaut. Das Haupt-Tag ist OCT (OCIT TYPE).
<!ELEMENT NAME (#PCDATA)>
<!ELEMENT DESCRIPTION (#PCDATA)>
<!ELEMENT MIN (#PCDATA)>
<!ELEMENT MAX (#PCDATA)>
<!ELEMENT VALUE (#PCDATA)>
<!ELEMENT MEMBER (#PCDATA)>
<!ELEMENT OTYPE (#PCDATA)>
<!ELEMENT NO_TCP (#PCDATA)>
<!ELEMENT BASETYPENAME (#PCDATA)>
<!ELEMENT DOMAIN (NAME, DESCRIPTION, MEMBER, OTYPE)>
<!ELEMENT CLASSATTRIBUTE (NAME, DESCRIPTION, VALUE)>

<!ELEMENT REFERENCE (MEMBER, NAME)>
<!ELEMENT BASEDOMAIN (MEMBER, NAME)>
<!ELEMENT MINCOUNT (#PCDATA)>
<!ELEMENT MAXCOUNT (#PCDATA)>
<!ELEMENT REFPATH (#PCDATA)>
<!ELEMENT REFPATH_DATA (#PCDATA)>
<!ELEMENT EXTENSIBLE (#PCDATA)>
<!ELEMENT DECL (NAME, DESCRIPTION, REFERENCE, (MINCOUNT?, MAXCOUNT)?, (REFPATH|REFPATH_DATA)?,
EXTENSIBLE?)>
<!ELEMENT STRUCTDOMAIN (NAME, DESCRIPTION, MEMBER, OTYPE, BASEDOMAIN?, DECL*,
CLASSATTRIBUTE*)>
<!ELEMENT DEGREE (#PCDATA)>
<!ELEMENT CATEGORY (#PCDATA)>
<!ELEMENT FORMAT (#PCDATA)>
<!ELEMENT MESSAGEPART (NAME, DESCRIPTION, MEMBER, OTYPE, BASEDOMAIN?, DECL*, CLASSATTRIBUTE*,
CATEGORY, DEGREE, FORMAT)>
<!ELEMENT NULLVAL (#PCDATA)>

<!ELEMENT RESOLUTION (#PCDATA)>
<!ELEMENT UNIT (#PCDATA)>
<!ELEMENT NUMBERDOMAIN (NAME, DESCRIPTION, MEMBER, OTYPE, BASETYPENAME, MIN?, MAX?, NULLVAL?,
RESOLUTION?, UNIT?)>
<!ELEMENT MAXLEN (#PCDATA)>

<!ELEMENT STRINGDOMAIN (NAME, DESCRIPTION, MEMBER, OTYPE, BASETYPENAME, MAXLEN)>
<!ELEMENT ENUMENTRY (NAME, DESCRIPTION, VALUE)>

<!ELEMENT BASEENUM (MEMBER, NAME)>
<!ELEMENT ENUMDOMAIN (NAME, DESCRIPTION, MEMBER, OTYPE, BASETYPENAME, MAX, BASEENUM?,
ENUMENTRY*)>

<!ELEMENT IN (DECL+)>
<!ELEMENT OUT (DECL+)>
<!ELEMENT AUTH (#PCDATA)>
<!ELEMENT NR (#PCDATA)>
<!ELEMENT MAXMETHODNR (#PCDATA)>
<!ELEMENT METHOD (NAME, DESCRIPTION, NR, AUTH?, IN?, OUT?)>
<!ELEMENT INTERFACE (NAME, DESCRIPTION, MEMBER, MAXMETHODNR, METHOD*)>
<!ELEMENT PATHPART (NAME, DESCRIPTION, REFERENCE, (REFPATH|REFPATH_DATA)?, EXTENSIBLE?)>
<!ELEMENT METHODNR_OFFSET (#PCDATA)>

<!ELEMENT STDMETHOD (#PCDATA)>
<!ELEMENT IMPLEMENTS (NAME, MEMBER, METHODNR_OFFSET)>
<!ELEMENT OBJTYPE (NAME, DESCRIPTION, MEMBER, OTYPE, BASEDOMAIN?, DECL*, CLASSATTRIBUTE*,
PATHPART*, STDMETHOD*, (MAXMETHODNR, METHOD*)?, IMPLEMENTS*)>
<!ELEMENT MANUFACTURER (#PCDATA)>

<!ELEMENT DEVICETYPE (#PCDATA)>
<!ELEMENT VERSION (#PCDATA)>
<!ELEMENT SUBVERSION (#PCDATA)>
<!ELEMENT OCT (MANUFACTURER, DEVICETYPE, VERSION, SUBVERSION, NO_TCP?, (DOMAIN | NUMBERDOMAIN
| STRINGDOMAIN | ENUMDOMAIN | STRUCTDOMAIN | MSGPART | INTERFACE | OBJTYPE)*)>
<!ELEMENT OCIT_TYPE_DATEI (OCT+)>
Die Bedeutung der einzelnen Elemente soll im Folgenden an einem Beispiel erläutert
werden. Das Beispiel hat keinerlei Beziehung zu den realen OCIT-Outstations Struk-
turen, es dient nur zur Veranschaulichung der Struktur der OCIT-Outstations Type-
Datei. Der Kommentar steht jeweils hinter der Zeile. Um die Beschreibung nicht zu
lang zu gestalten, werden für das Verständnis irrelevante Teile, d.h. alle Sachen, die
sich wiederholen, mit [...] herausgekürzt.
<?xml version="1.0" encoding="ISO-8859-1"?>
In dieser Zeile wird nur angegeben, dass es sich um eine XML 1.0 Datei , im Zeichensatz ISO-
8859-1 codiert handelt. Die Zeile ist für alle Versorgungen fest
<!DOCTYPE OCIT_TYPE_DATEI SYSTEM "ocit.dtd">
Verweis auf die verwendeten Strukturinformationen. Fehlt der Eintrag, werden beliebige XML-
Dateien akzeptiert
<OCIT_TYPE_DATEI>
<OCT>
Eigentlicher Beginn der OCIT-Type-Datei
<MANUFACTURER>Ampelpower Ltd.</MANUFACTURER>
Hersteller des Kreuzungsgerätes. Der Hersteller im Beispiel ist fiktiv, wie die ganze Ver-
sorgungsdatei.
<DEVICETYPE>Standardampel</DEVICETYPE>
Typ des Kreuzungsgerätes
<VERSION>1</VERSION>
zugehörige OCIT-Version
<SUBVERSION>15</SUBVERSION>
Herstellerspezifische. Nummerierung
<NUMBERDOMAIN>
numerischer Datentyp, der später eingesetzt wird. Integer- und Fließkommatypen werden
mit NUMBERDOMAIN spezifiziert.
wenn nur die einzelnen Werte eine Bedeutung haben, steht anstelle von INTDOMAIN eine
ENUMDOMAIN (s.u.)
<NAME>ZEITSTEMPEL_UTC</NAME>
Name des Datentyps. Namen sind wie Bezeichner in C aufgebaut. D.h. sie dürfen im spezi-
ellen keine Blank und Punkte beinhalten.
<DESCRIPTION>Universal Time Coordinated</DESCRIPTION>
Beschreibung des Datentyps
<MEMBER>0</MEMBER>
Nummer des Herstellers innerhalb der ODG, der das Access-Objekt definiert hat. Die Her-
stellernummern werden von der ODG vergeben. Objekte, die im Standard definiert sind, ha-
ben im Member-Feld den Eintrag 0
<OTYPE>48</OTYPE>
<BASETYPENAME>ULONG</BASETYPENAME>
Basistyp der Domain. Es sind die Basistypen BYTE, SHORT, LONG, UBYTE, USHORT, ULONG,
FLOAT, DOUBLE, STRING, WSTRING, BLOB erlaubt, siehe Tabelle 1: Grunddatentypen.
<MIN>1</MIN>
Kleinste erlaubte Zahl des Typs
<MAX>0xffffffff</MAX>

Größte erlaubte Zahl des Typs. Für Nicht-C-Programmierer: 0xF bedeutet die Zahl „F“ im
Hexadezimalformat, also 15.
<NULLVAL>0</NULLVAL>
Wert, der - sofern gesetzt - die Bedeutung hat, dass eine Variable mit diesem Wert als
Inhalt nicht gesetzt ist.
</NUMBERDOMAIN>
<ENUMDOMAIN>
Für die Aufzählung von Werten mit Bedeutung (z.B. für enum's)
<NAME>RetCode</NAME>
<DESCRIPTION>Allgemeiner Rückgabewert von Methoden</DESCRIPTION>
<MEMBER>0</MEMBER>
<OTYPE>66</OTYPE>
<BASETYPENAME>USHORT</BASETYPENAME>
<MAX>999</MAX>
Maximaler Wert des ENUM-Bereiches
Es ist möglich, dass bestimmte Aufzählungen mehrfach verwendet werden. Hierzu gibt es
den optionalen Eintrag BASEENUMDOMAIN, der genau an dieser Stelle stehen würde. Der
Eintrag enthält einen Verweis auf einen bereits deklarierten TYPE, der ebenfalls ein
ENUMDOMAIN ist. Wenn ein BASEENUMDOMAIN gesetzt ist, werden alle Einträge dieses
ENUMS übernommen und alle neuen Werte müssen größer als der MAX-Wert des
BASEENUMDMAINS sein. Wenn ein BASEENUMDOMAIN vorhanden ist, kann sogar auf MAX und
weitere ENTRY-Einträge verzichtet werden.
<ENUMENTRY>
Ein Eintrag für den ENUM-Bereich
<NAME>OK</NAME>
Bezeichnung des Eintrags
<DESCRIPTION>Methode erfolgreich ausgeführt</DESCRIPTION>
<VALUE>0</VALUE>
Der eigentliche Wert. Er muss kleiner als MAX sein.
</ENUMENTRY>
<ENUMENTRY>
Der nächste Eintrag für den ENUM-Bereich. Es sind 'beliebig' viele Einträge möglich.
<NAME>ERROR</NAME>
<DESCRIPTION>allgemeiner Fehler</DESCRIPTION>
<VALUE>1</VALUE>
</ENUMENTRY>
[...]
</ENUMDOMAIN>
[...]
<STRUCTDOMAIN>
Zusätzlich zu den Domain-Datentypen gibt es Struktur-Datentypen, die den bekannten struct's
oder records in PASCAL entsprechen. Jedes Element einer Struktur ist dann in einem DECL-
Feld (s.u.) abgespeichert. Eindimensionale Arrays sind möglich. Auf mehrdimensionale Array
wird verzichtet, da diese immer als Array von einer Struktur, die wieder ein Array ist, de-
klariert werden können und diese (etwas längere) Definition, den Vorteil hat, verständlich
zu sein, was den Aufbau des Telegramms angeht.
<NAME>ZEITINTERVALL</NAME>
<DESCRIPTION>gibt ein absolutes Zeitintervall an</DESCRIPTION>
<MEMBER>0</MEMBER>
<OTYPE>63</OTYPE>
<DECL>
<NAME>StartZeit</NAME>
<DESCRIPTION>Anfangszeitpunkt des Intervalls</DESCRIPTION>
<REFERENCE>
Eine REFERENCE ist ein besonderer Eintrag, der nur auf DOMAIN Definitionen verweisen
kann. Ads sind DOMAIN, NUMBERDOMAIN, ENUMDOMAIN, STRINGDOMAIN, STRUCTDOMAIN, OBJTYPE.
Die folgenden Felder besagen, dass eine Domaindefinition mit dem Namen
ZEITSTEMPEL_UTC vom Odgmember 0 (=ODG) referenziert wird.
<MEMBER>0</MEMBER>
</REFERENCE>
</DECL>
<DECL>
<NAME>EndZeit</NAME>
<DESCRIPTION>Endezeitpunkt des Intervalls</DESCRIPTION>
<REFERENCE>
<MEMBER>0</MEMBER>
</REFERENCE>
</DECL>
</STRUCTDOMAIN>
<INTERFACE>

Ein Interface ist eine Sammlung von Methoden, die von mehreren Objekttypen genutzt werden.
In einem Interface werden Methoden und ihre Parametrierungen zusammengefasst.. Die Referen-
zierung des Interfaces erfolgt durch die Kombination von MEMBER und Name. MEMBER ist eine
Nummer der Firma, die das Inerface designt hat. Die Liste aller ODGMember sind in Dokument
1 angegeben.
<NAME>ArchivLesen</NAME>
Name des Interfaces, muss zusammen mit MEMBER eindeutig sein.
<DESCRIPTION>Dieses Interface dient dazu Archive in F von Z auszulesen</DESCRIPTION>
Erläuterung zum Namen
<MEMBER>0</MEMBER>
<MAXMETHODNR>8</MAXMETHODNR>
Gibt die größte reservierte Methodennummer dieses Interfaces an. Wenn ein OBJTYPE ein
Interface implementiert, müssen alle Methoden aller von diesem OBJTYPE implementierten
Methoden durchnummeriert werden. Falls dieses Interface erweitert wird und noch freie
Methodennummern verfügbar sind, so bleiben die restlichen Methodennummern alle gleich.
<METHOD>
Funktionalität, die das Interface anbietet. Es gibt in OCIT keine Prozeduren oder Funk-
tionen, sondern nur Methoden. Eine Methode ist wie hier einem Interface zugeordnet oder
direkt einem Objekt.
<NAME>GetAeltestes</NAME>
Name der Methode
<DESCRIPTION>Ältestes Archivelement und dessen Position aus Archiv
lesen</DESCRIPTION>
Erläuterung zum Namen
<NR>1</NR>
NR der Methode. Als Nr ist der Zahlenbereich von 1..MAXMETHODNR zugelassen, bei Me-
thoden, die direkt am Objekt gespeichert sind, nur der Bereich von 16..64535.
<AUTH>NO</AUTH>
Der Eintrag AUTH kann folgende Werte Annehmen:
None keine Sicherung der Parameter mit SHA-1 Checksumme
Request Nur die Eingabeparameter werden mit SHA-1 Checksumme gesichert.
Full Die Ein- und Ausgabeparameter werden mit SHA-1 Checksumme gesichert.
Fehlt der Eintrag, werden die Ein- und Ausgabeparameter gesichert.
<OUT>
Bereich der Ausgabeparameter. Eingabeparameter werden auf die praktisch gleiche Art
definiert (<IN>) und müssen vor den Ausgabeparametern definiert werden. Bei Eingabe-
parametern fehlt der ENUMDOMAIN-Eintrag. Wenn der OUT-Parameter fehlt, wird die Me-
thode nicht mit einem Request/Reply beantwortet, sondern mit einer Message. Es kann
daher bei Methoden ohne Ausgabeparameter nicht sichergestellt werden, dass der Aufruf
durchgekommen ist. Dafür ist der Aufruf sehr schnell (z.B. für Visualisierungsdaten
etc.)
<DECL>
Der erste OUT-Parameter ist für den Ergebniswert des Methodenaufrufs. Der referen-
zierte Datentyp muss entweder RetCode oder eine Spezialisierung dessen sein. In
diesem Wert werden auch eventuelle Fehler der unterlagerten Protokollschichten zu-
rückgegeben.
<NAME>ret</NAME>
<DESCRIPTION>OK, KEIN_ELEMENT, Fehler</DESCRIPTION>
<REFERENCE>
<MEMBER>0</MEMBER>
</REFERENCE>
</DECL>
<DECL>
Zusätzliche Ausgabeparameter werden durch DECL-Anweisungen wie Strukturelemente im
Type deklariert.
<NAME>PosNr</NAME>
<DESCRIPTION>Positionsnummer des gelieferten Elements</DESCRIPTION>
<REFERENCE>
<MEMBER>0</MEMBER>
<NAME>ARCHIVPOSNR</NAME>
</REFERENCE>
</DECL>
<DECL>
<NAME>Element</NAME>
<DESCRIPTION>Ältestes Element</DESCRIPTION>
<REFERENCE>
<MEMBER>0</MEMBER>
<NAME>ARCHIV_ELEMENT</NAME>
</REFERENCE>
<ENCODETYPE>IdData</ENCODETYPE>
ENCODETYPE gibt die Art an, wie die dynamischen Daten vom referenzierten Typ
(ARCHIV_ELEMENT) übertragen werden. IdData gibt an, dass die ID und die Daten
übertragen werden. Dies ist dann von Vorteil, falls verschiedene Spezialisie-
rungen(spezielle Archivelemente) übertragen werden. Die ID besteht aus MEMBER
und OTYPE des Typs der übertragenen Daten. Fehlt dieses Feld so ist das Äquiva-
lent zu Data, d.h. nur die Daten werden übertragen.
</DECL>

</OUT>
</METHOD>
<METHOD>
[...]
</METHOD>
<METHOD>
<NAME>GetElementeSeit</NAME>
<DESCRIPTION>Elemente ab übergebener Zeit</DESCRIPTION>
<NR>3</NR>
<NOAUTHENTIFICATION/>
Wenn dieser Eintrag gesetzt wird, werden die Eingabe und die Rückgabeparameter der
Methode nicht mit der SHA-1 Checksumme gesichert. Fehlt der Eintrag, werden die Para-
meter gesichert.
<IN>
Bereich der Eingabeparameter. Eingabeparameter werden auf die praktisch gleiche Art
wie Ausgabeparameter definiert
<DECL>
<NAME>Zeit</NAME>
<DESCRIPTION>Zeitpunkt ab welchem Elemente gelesen werden</DESCRIPTION>
<REFERENCE>
<MEMBER>0</MEMBER>
</REFERENCE>
</DECL>
[...]
</IN>
<OUT>
[...]
<DECL>
<NAME>Elemente</NAME>
<DESCRIPTION>Gelesene Elemente. Können von unterschiedlichen, von
ARCHIV_ELEMENT abgeleiteten Typen sein.</DESCRIPTION>
<REFERENCE>
<MEMBER>0</MEMBER>
<NAME>ARCHIV_ELEMENT</NAME>
</REFERENCE>
<MAXCOUNT>1024</MAXCOUNT>
<ENCODETYPE>IdData</ENCODETYPE>
Hier wird ein Array mit variablen Typen übertragen, d.h. zuerst wird die tat-
sächliche Anzahl Elemente als UWORD und dann entsprechend viele Elemente je-
weils mit ID (bestehend aus MEMBER und OTYPE) und Data übertragen.
</DECL>
</OUT>
</METHOD>
</INTERFACE>
<OBJTYPE>
Der eigentliche Objekttyp ist als OBJTYPE deklariert. Er besteht aus mehreren Elementen: Im
TYPE wird die Struktur der Daten festgelegt, die mit Hilfe von Get gelesen und von Update
geschrieben werden kann. Get und Update sind Systemmethoden, die nicht immer neu deklariert
zu werden brauchen, weil sie hardcodiert sind. Mit INTERFACENAME werden Interfaces aufge-
führt, die von dem Objekt unterstützt werden. Die Interfaces sind bereits oben deklariert.
In STDMETHOD wird angegeben, welche Standardfunktionen (Create, Delete, Get, Update) unter-
stützt werden. In Method schließlich werden Methoden definiert, die nur für diesen Objekt-
typ einzeln gelten und für keinen anderen Objekttyp. Das System kennt nur public einfach-
Vererbung. Wenn mehrere Objekttypen die gleichen Methoden unterstützen sollen, sollte ein
Interface deklariert werden.
<NAME>StoerungsFehlerArchiv</NAME>
<DESCRIPTION>Archiv fuer Stoerungs- und Fehlermeldungen</DESCRIPTION>
<MEMBER>0</MEMBER>
<OTYPE>299</OTYPE>
Nummer des Objekttyps (1..65535).
kein Eintrag BASEDOMAIN, d.h. StoerungsFehlerArchiv ist keine Spezialisierung einer an-
deren DOMAIN .
keine DECL Einträge, d.h. Keine eigenen (public) Daten.
keine CLASSATTRIBUTES
kein PATH, d.h. pro Feldgerät kann es nur eine Instanz mit MEMBER=0, OTYPE=299 geben.
Keine STDMETHODS, wenn keine eigenen Daten definiert werden, sind auch die Standardme-
thoden nicht sinnvoll.
größte mögliche Methodennummer
<IMPLEMENTS>
Dieses Objekt implementiert das im Folgenden referenzierte Interface. Alle im Interface
angegebenen Methoden sind für dieses Objekt verfügbar, sie müssen also implementiert
werden.
<NAME>ArchivLesen</NAME>

Name des Interfaces, dessen Methoden das Objekt unterstützt.
<MEMBER>0</MEMBER>
<METHODNR_OFFSET>15</METHODNR_OFFSET>
Die in BTPPL übertragenen Methodennummern berechnen sich aus der im Interface genann-
ten Nummer+15, GetElementeSeit hat also die Methodennummer 18.
</IMPLEMENTS>
</OBJTYPE>
<OBJTYPE>
<NAME>ZSignalProgramm</NAME>
<DESCRIPTION>von der Zentrale eingestellter Signalprogrammschaltwunsch</DESCRIPTION>
<MEMBER>0</MEMBER>
<OTYPE>222</OTYPE>
<DECL>
<NAME>Aktuell</NAME>
<DESCRIPTION>aktueller oder zuletzt eingestellter Zentralenschaltwunsch</DESCRIPTION>
<REFERENCE>
<MEMBER>0</MEMBER>
<NAME>ZSO_SIGNALPROGRAMM</NAME>
</REFERENCE>
</DECL>
<DECL>
<NAME>Next</NAME>
<DESCRIPTION>zeitlich nächster Zentralenschaltwunsch</DESCRIPTION>
<REFERENCE>
<MEMBER>0</MEMBER>
</REFERENCE>
</DECL>
<PATHPART>
Objekte, die mehrfach in einem Feldgerät vorhanden sind, werden über einen Pfad eindeu-
tig referenziert. Dieser Pfad ist hier angegeben.
<NAME>RelKnotenNr</NAME>
<DESCRIPTION>Pfadparameter ist relative Knotennummer. Damit sind mehrere
Knotensteuerungen innerhalb eines Feldgerätes möglich.</DESCRIPTION>
<REFERENCE>
<MEMBER>0</MEMBER>
<NAME>OBJECT_ID_UBYTE</NAME>
</REFERENCE>
</PATHPART>
<STDMETHOD>Get</STDMETHOD>
Die Variablen des Objekttyps können gelesen werden, allerdings nur alle gemeinsam. Um
Variablen auch getrennt bearbeiten zu können, muss das Objekt aus weiteren Objekttypen
bestehen .Wenn die Objekttypen direkt integriert sind, ist es möglich, das gesamte Ob-
jekt zu lesen, bei einem Verweis über Referenz kommt nur die jeweilige Referenz zurück.
<METHOD>
<NAME>Schalte</NAME>
<DESCRIPTION>Nächsten Signalprogrammschaltwunsch der Zentrale entgegennehmen
</DESCRIPTION>
<NR>16</NR>
<IN>
<DECL>
<NAME>Schaltauftrag</NAME>
<DESCRIPTION>von Zentrale übergebener Schaltauftrag</DESCRIPTION>
<REFERENCE>
<MEMBER>0</MEMBER>
</REFERENCE>
</DECL>
</IN>
<OUT>
<DECL>
<NAME>ret</NAME>
<DESCRIPTION>OK, PARAM_INVALID, INTERVALL_INVALID</DESCRIPTION>
<REFERENCE>
<MEMBER>0</MEMBER>
</REFERENCE>
</DECL>
</OUT>
</METHOD>
</OBJTYPE>
[...]
</OCT>
</OCIT_TYPE_DATEI>

6.3 Standard-Interfaces
Im Protokoll sind zwei Bereiche fest definiert: Das Systeminterface und das System-
objekt. Das Systeminterface besteht aus den Methoden 0...15, welche für jedes Objekt
unterschiedliche Funktionen beinhalten.
Das Systemobjekt ist das Objekt 0 des Members ODG. Der Subtype ist immer 0. Es
enthält lediglich die Funktionen zum Setzen und Lesen des OCIT-O Passworts.
Diese Funktionen sind nicht in einem Interface zusammengefasst, sondern im Inter-
face 0 als spezielle Funktionen ausgewiesen.
6.3.1 Systeminterface
Das Systeminterface hat folgende Funktionen:
Nr. Name Input Output
0 Get ./. status +THISTYPE
1 Update THISTYPE Status
2 Create THISTYPE Status
3 Delete ./. Status + Referenzliste
4..15 (reserviert)
Um eine Standardmethode zu verwenden, ist im Element OBJTYPE.STDMETHOD

der oben angegebene Name einzutragen. Dabei ist THISTYPE die Datenstruktur des
Objekts selbst inkl. der Datenstrukturen aller Unterobjekte. Referenzen werden nicht
mit ihren Inhalten aufgelöst, sondern mit einer REFPATH-Struktur.2
Der Status ist der Standard-Status (RetCode) der Operation (s.u.).
Im Einzelnen funktionieren die Funktionen wie folgt:
6.3.1.1 Get
Get erhält keine Eingabeparameter und hat (neben dem Funktionsstatus) nur einen
Ausgabeparameter. Der Ausgabeparameter unterscheidet sich je nach Objekttyp und
hat genau die Struktur, die über die DECL Einträge der DynAttribut Liste (und der al-
ler BaseDomains) des OBJTYP angegeben ist.
2 Hinweis: Durch diese Technik ist es einfach, einen Browser aufzubauen. Alle komplexeren Objekte,
die sich getrennt behandeln lassen, werden nur über Referenzen verwiesen, so dass z. B. beim Aus-
lesen eines Feldgerätes die Basisinformationen (Name, Nr., ...) direkt übertragen werden, während die
komplexeren Elemente wie Signalprogramme als Referenzen abgelegt sind und nur ihr Name ange-
zeigt werden muss. Erst wenn der Benutzer das jeweilige Element auswählt, wird das Objekt auch
wirklich geladen.

Referenzen sind DECL Einträge, die einen REFPATH Eintrag enthalten.
Die Methode Get wird ohne SHA-1 Authentifizierung abgewickelt.
6.3.1.2 Update
Update setzt den Wert eines Feldes neu. Als Eingabeparameter wird Update genau
dieselbe Struktur übergeben, die vorher mit Get geliefert wurde. Es können auch Re-
ferenzen mit dieser Funktion gesetzt werden. Eine Garbage-Collection findet nicht
statt, weil Objekte jederzeit direkt referenziert werden können.
Die Methode Update wird mit SHA-1 Authentifizierung abgewickelt.
6.3.1.3 Create
Mit „Create“ werden neue Objekte angelegt. Create funktioniert wie Update. Die
neuen Objekte werden vom Kreuzungsgerät automatisch korrekt hinzugefügt. Create
erhält als Eingabe genau die gleichen Werte wie ein Update, nur existierte das Ob-
jekt vorher noch nicht.
Die Methode Create wird mit SHA-1 Authentifizierung abgewickelt.
6.3.1.4 Delete
Mit Delete werden Objekte gelöscht. Die Funktion lässt ein Löschen nur zu, wenn
kein Objekt mehr auf das Element verweist. Ansonsten wird eine Liste von Objekten
zurückgegeben, die aus Referenzen auf Objekte besteht, die auf den Löschkandidat
noch verweisen. Die Referenzen werden als EXTENSIBLE REFPATH gespeichert.
Die Methode Delete wird mit SHA-1 Authentifizierung abgewickelt

7 Beispiel für Abbildung der XML in Telegramme
7.1 Typen, XML Beschreibung

<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE OCT SYSTEM "ocit.dtd">
<OCIT_TYPE_DATEI>
<OCT>
<MANUFACTURER>odg</MANUFACTURER>
<DEVICETYPE>Beispiel</DEVICETYPE>
<VERSION>1</VERSION>
<SUBVERSION>1</SUBVERSION>
<NUMBERDOMAIN>
<DESCRIPTION>Universal Time Coordinated</DESCRIPTION>
<MEMBER>0</MEMBER>
<OTYPE>48</OTYPE>
<BASETYPENAME>ULONG</BASETYPENAME>
<MIN>1</MIN>
<MAX>0xffffffff</MAX>
<NULLVAL>0</NULLVAL>
<RESOLUTION>1</RESOLUTION>
<UNIT>Sekunden</UNIT>
</NUMBERDOMAIN>
<NUMBERDOMAIN>
<DESCRIPTION>Identifikation eines Objektes</DESCRIPTION>
<MEMBER>0</MEMBER>
<OTYPE>49</OTYPE>
<BASETYPENAME>UBYTE</BASETYPENAME>
<MIN>0</MIN>
<MAX>0xfe</MAX>
<NULLVAL>0xff</NULLVAL>
<RESOLUTION>1</RESOLUTION>
<UNIT/>
</NUMBERDOMAIN>
<STRINGDOMAIN>
<NAME>OBJECT_NAME</NAME>
<DESCRIPTION>Bezeichnung eines Objektes</DESCRIPTION>
<MEMBER>0</MEMBER>
<OTYPE>52</OTYPE>
<BASETYPENAME>STRING</BASETYPENAME>
<MAXLEN>255</MAXLEN>
</STRINGDOMAIN>
<ENUMDOMAIN>
<DESCRIPTION>Allgemeiner Rückgabewert von Methoden</DESCRIPTION>
<MEMBER>0</MEMBER>
<OTYPE>66</OTYPE>
<BASETYPENAME>USHORT</BASETYPENAME>
<MAX>999</MAX>
<ENUMENTRY>
<NAME>OK</NAME>
<DESCRIPTION>Methode erfolgreich ausgeführt</DESCRIPTION>
<VALUE>0</VALUE>
</ENUMENTRY>
<ENUMENTRY>
<NAME>ERROR</NAME>
<DESCRIPTION>allgemeiner Fehler</DESCRIPTION>
<VALUE>1</VALUE>
</ENUMENTRY>
<ENUMENTRY>
<NAME>ERR_BAD_CALLCHK</NAME>
<DESCRIPTION>BTPPL: Die Methode wurde mit einer falschen Checksumme
aufgerufen.</DESCRIPTION>
<VALUE>2</VALUE>
</ENUMENTRY>
<ENUMENTRY>
<NAME>ERR_BAD_CALLTIME</NAME>
<DESCRIPTION>BTPPL: Die Uhrzeit des Aufrufs stimmt nicht auf 30 Minuten genau mit der
lokalen Uhrzeit überein.</DESCRIPTION>
<VALUE>3</VALUE>
</ENUMENTRY>
<ENUMENTRY>

<NAME>ERR_BAD_RETCHK</NAME>
<DESCRIPTION>BTPPL: Wird nach der Übertragung vom Sender generiert, wenn die
Prüfsumme beim Return-Telegramm nicht übereinstimmt.</DESCRIPTION>
<VALUE>4</VALUE>
</ENUMENTRY>
<ENUMENTRY>
<NAME>ERR_BAD_RETTIME</NAME>
<DESCRIPTION>BTPPL: Wird nach der Übertragung vom Sender generiert, wenn die Uhrzeit
des Returnblockes nicht stimmt, der Sendeblock aber korrekte Uhrzeit hatte. In diesem Fall
wurde der Befehl bereits durchgeführt, es ist aber eine Synchronisation der Uhrzeit not-
wendig. Wenn der Code nach der Zeitsynchronisation wieder auftritt, deutet dies auf Hacker
oder Bug hin.</DESCRIPTION>
<VALUE>5</VALUE>
</ENUMENTRY>
<ENUMENTRY>
<NAME>ERR_SYNCHRONIZE</NAME>
<DESCRIPTION>BTPPL: Wird nach der Übertragung vom Sender generiert, wenn die Uhrzeit
des Returnblockes nicht stimmt und der Befehl bereits vom Sendeblock her eine falsche Uhrzeit
hatte. Dieser Code wird zwischen Steuergerät und Zentrale nicht verwendet.</DESCRIPTION>
<VALUE>6</VALUE>
</ENUMENTRY>
<ENUMENTRY>
<NAME>ERR_TYPE</NAME>
<DESCRIPTION>BTPPL: Typ, bestehend aus ODG-MemberId und OType ist nicht
bekannt/implementiert.</DESCRIPTION>
<VALUE>7</VALUE>
</ENUMENTRY>
<ENUMENTRY>
<NAME>ERR_METHOD</NAME>
<DESCRIPTION>BTPPL: angegebene Methodennummer ist nicht
bekannt/implementiert.</DESCRIPTION>
<VALUE>8</VALUE>
</ENUMENTRY>
<ENUMENTRY>
<NAME>ERR_PATH_LEN</NAME>
<DESCRIPTION>unerwartete Pfadlänge</DESCRIPTION>
<VALUE>16</VALUE>
</ENUMENTRY>
<ENUMENTRY>
<NAME>ERR_PATH_VAL</NAME>
<DESCRIPTION>Keine Instanz zu angegebenem Pfad (Wert) gefunden</DESCRIPTION>
<VALUE>17</VALUE>
</ENUMENTRY>
<ENUMENTRY>
<NAME>PARAM_INVALID</NAME>
<DESCRIPTION>fehlerhafter Parameter</DESCRIPTION>
<VALUE>32</VALUE>
</ENUMENTRY>
<ENUMENTRY>
<NAME>INTERVALL_INVALID</NAME>
<DESCRIPTION>ungültiges oder bereits abgelaufenes Intervall angegeben</DESCRIPTION>
<VALUE>33</VALUE>
</ENUMENTRY>
<ENUMENTRY>
<NAME>NOT_CONFIGURED</NAME>
<DESCRIPTION>Die angesprochene Funktion ist wegen fehlender Versorgung nicht
verfügbar</DESCRIPTION>
<VALUE>34</VALUE>
</ENUMENTRY>
</ENUMDOMAIN>
<OBJTYPE>
<NAME>objA</NAME>
<DESCRIPTION>Beispielobjekt A</DESCRIPTION>
<MEMBER>0</MEMBER>
<OTYPE>500</OTYPE>
<DECL>
<NAME>zeit</NAME>
<DESCRIPTION>beispielzeit</DESCRIPTION>
<REFERENCE>
<MEMBER>0</MEMBER>
</REFERENCE>
</DECL>
<DECL>
<NAME>nr</NAME>
<DESCRIPTION>Beispiel Byte id</DESCRIPTION>
<REFERENCE>
<MEMBER>0</MEMBER>

</REFERENCE>
</DECL>
<DECL>
<NAME>name</NAME>
<DESCRIPTION>Beispielname</DESCRIPTION>
<REFERENCE>
<MEMBER>0</MEMBER>
</REFERENCE>
</DECL>
<PATHPART>
<NAME>PfadNr</NAME>
<DESCRIPTION>BeispielPfad</DESCRIPTION>
<REFERENCE>
<MEMBER>0</MEMBER>
</REFERENCE>
</PATHPART>
</OBJTYPE>
<OBJTYPE>
<NAME>objB</NAME>
<DESCRIPTION>Beispielobjekt B, von objA abgeleitet</DESCRIPTION>
<MEMBER>0</MEMBER>
<OTYPE>501</OTYPE>
<BASEDOMAIN>
<MEMBER>0</MEMBER>
<NAME>objA</NAME>
</BASEDOMAIN>
<DECL>
<NAME>nameB</NAME>
<DESCRIPTION>Beispielname B</DESCRIPTION>
<REFERENCE>
<MEMBER>0</MEMBER>
</REFERENCE>
</DECL>
</OBJTYPE>
<OBJTYPE>
<NAME>objC</NAME>
<DESCRIPTION>Beispielobjekt C</DESCRIPTION>
<MEMBER>0</MEMBER>
<OTYPE>502</OTYPE>
<DECL>
<NAME>name</NAME>
<DESCRIPTION>Name</DESCRIPTION>
<REFERENCE>
<MEMBER>0</MEMBER>
</REFERENCE>
</DECL>
<DECL>
<NAME>objs</NAME>
<DESCRIPTION>Beispiel Embedded Objekte als Polymorpher array</DESCRIPTION>
<REFERENCE>
<MEMBER>0</MEMBER>
<NAME>objA</NAME>
</REFERENCE>
<MINCOUNT>0</MINCOUNT>
<MAXCOUNT>4</MAXCOUNT>
<REFPATH_DATA>3</REFPATH_DATA >
<EXTENSIBLE></EXTENSIBLE>
</DECL>
</OBJTYPE>
</OCT>
</OCIT_TYPE_DATEI>

7.2 Instanzen
Instanzen in Gerät 5, für Beispiel:
Pfad ab Gerät 5/
ObjC
name=ObjC
0
ObjA
Zeit=0x38d0dea4
nr=17
name=ObjA1
1
ObjA
Zeit=0x38d0dfa9
nr=23
name=ObjA2
3
ObjB
Zeit=0x38d0dfb9
nr=37
name=ObjA3
nameB=ObjB1
7.3 Telegramme
Request Telegramm für ObjA/1.Get()mit udp von Zentrale 0.
Offset Offset+0 Offset+1 Offset+2 Offset+3
UDP
HdrLen 000 00 r r 0 JobTime JobTime (Lo)
0
11 (Hi) 83
Job Time E6
Member
Job Time Cnt(Hi) Member (Lo)
4 Cnt(Lo) (Hi)
00 00
00 00
Method
OTYPE (Hi) OTYPE (Lo) Method (Lo)
8 (Hi)
01 F4 00
00
ZNr (Hi) ZNr (Lo) FNr (Hi) FNr (Lo)
12 00 00 00 05
Fletcher Fletcher
Path
16 (Hi) (Lo)
01
F1 77

Daraufhin antwortet das Gerät mit:
UDP
HdrLen 001 00 r r 0JobTime JobTime (Lo)
0
10 (Hi) 83
Job Time Job Time E6
Member (Hi) Member (Lo)
4 Cnt(Hi) Cnt(Lo)
00 00
00 00
OTYPE (Hi) OTYPE (Lo) Method (Hi) Method (Lo)
8 01 F4 00 00
12 00 00 00 05
RetCode RetCode
16 38 D0
0 0
20 DF A9 17 06
24 4F Ó´ 62 ´b´ 6A ´j´ 41 Á´

Fletcher Fletcher
28 32 ´2´ 00 (Hi) (Lo)
3E D4
Request Telegramm für ObjC.Get()mit udp von Zentrale 0
UDP
HdrLen 000 00 r r 0 JobTime JobTime (Lo)
0
10 (Hi) 84
Job Time Job Time 15
Member (Hi) Member (Lo)
4 Cnt(Hi) Cnt(Lo)
00 00
00 00
OTYPE (Hi) OTYPE (Lo) Method (Hi) Method (Lo)
8 01 F6 00 00
12 00 00 00 05
Fletcher
Fletcher (Hi)
16 (Lo)
A8
A6

Daraufhin antwortet das Gerät mit:
UDP
0 HdrLen 001 00 r r 0 JobTime JobTime (Lo)

10 (Hi) 84
Job Time Job Time 15
Member
Member (Lo)
4 Cnt(Hi) Cnt(Lo) (Hi)
00
00 00 00
Method
OTYPE (Hi) OTYPE (Lo) Method (Lo)
8 (Hi)
01 F6 00
00
12
00 00 00 05
RetCode RetCode Name len Name
16
0 0 05 4F Ó´
20 62 ´b´ 6A ´j´ 43 Ć´ 00
ID.Member ID.Member
Anzahl objs RefLen
24 (Hi) (Lo)
03 5
00 00
ID.OTYPE
ID.OTYPE (Hi) ID.Path DataLen(Hi)
28 (Lo)
01 00 00
F4
DataLen(Lo) Zeit
32 D0 DE
0C 38
Nr Name len Name
36 E4
11 06 4F Ó´
40 62 ´b´ 6A ´j´ 41 Á´ 31 ´1´
ID.Member ID.Member
RefLen
44 00 (Hi) (Lo)
5
00 00
ID.OTYPE
48 (Lo)
01 01 00
F4
DataLen(Lo) Zeit
52 D0 DF
0C 38
Nr Name Len Name
56 A9
17 06 4F Ó´
60 62 ´b´ 6A ´j´ 41 Á´ 32 ´2´
ID.Member ID.Member
RefLen
64 00 (Hi) (Lo)
5
00 00

ID.OTYPE
68 (Lo)
01 03 00
F5
DataLen(Lo) Zeit
72 D0 DF
13 38
Nr Name len Name
76 B9
25 06 4F Ó´
80 62 ´b´ 6A ´j´ 41 Á´ 33 ´3´
Name len Name
84 00 62 ´b´
06 4F Ó´
88 6A ´j´ 42 ´B´ 31 ´1´ 00
Fletcher
Fletcher (Hi)
92 (Lo)
FB
BA

8 Trace-Möglichkeiten
Hinweis: Versionsstand des Feldgeräts beachten!
Die Erfassung des btppl-Telegrammverkehrs zu Prüfzwecken wird als „Tracen“ be-

zeichnet. Es gibt 2 Möglichkeiten:
8.1 Trace-Datei
Der Telegrammverkehr wird im Lichtsignalsteuergerät oder in einer zentralen Einrich-
tung erfasst und in einer „Trace-Datei“ gespeichert. Diese Möglichkeit zum vollständi-
gen Erfassen des btppl-Telegrammverkehrs in Trace-Dateien ist für Zentralen und
Feldgeräte verpflichtend.
In der OCIT-O Library (src_btppl_type_040701.zip) sind Module zur Erzeugung der

Trace-Dateien (btppl_trace.c und btppl_trace.h) enthalten.
Die Trace-Dateien können mit dem OCIT-O Typetool (typetool_WIN_....exe, type-

tool_LINUX_....) gelesen werden. Es bietet folgende Funktionen:
 OCIT-Type (.dtd und .xml) einlesen und prüfen
 HTML Darstellung der OCIT-Type
 Trace-Datei (binäres btppl trace file) in lesbaren Text umsetzen
 Client Aufrufe (btppl client), Ausgabe des Request und Respond
 Sonderfunktion: Serverfunktion für EvList Objekt (Empfang von Events)
8.2 Externes Tracen

Der Telegrammverkehr wird online durch ein externes Erfassungsgerät (Trace-Tool)
an dafür vorgesehenen Ports (Standard Trace-Ports) am Lichtsignalsteuergerät oder
einer zentralen Einrichtung erfasst und gespeichert.
Ein Trace-Tool bietet typischerweise folgende Funktionen:
 Erfassen des btppl-Telegrammverkehrs über den Standard Trace-Port (Online-

Tracen)
 Online Visualisieren des Trace
 Trace- Datei in lesbarer Text umsetzen (Offline)
8.2.1 Trace-Connection
Die Trace-Connection ist grundsätzlich von VD-Server (Zentrale) und Lichtsignal-
steuergerät zu implementieren.

Standard Trace-Port: Servicename: ocit-trace (Port 5001, tcp).
Hinweis: Die Physik des Anschlusses ist nicht festgelegt.
Optional kann beim Socketaufbau ein Filterkriterium ZNR=xxxxx und/oder

FNR=xxxxx vom Analysetool gesendet werden, mindestens aber ein LF (\n).
Beispiele:
ZNR=42;FNR=23\n
FNR=23\n
ZNR=42\n
\n
Socket-Timeout: Das Trace-Tool muss die Daten binnen 5 Sekunden abgenommen
haben, ansonsten kann die Verbindung geschlossen werden.
Hinweis: Trace-Tools sollten vorzugsweise über eigene, schnelle Verbindungen mit

der Zentrale oder dem Lichtsignalsteuergerät verbunden werden, weil durch das On-
line-Tracen das Datenaufkommen verdoppelt wird. Bei gleichzeitiger der Verwen-
dung der Übertragungsprofile 1 oder 2 für Gerätesteuerung und Tracen können
dadurch die Grenzen der Übertragungskapazität erreicht werden.
8.3 Binäres trace file format

Ein binäres btppl trace file besteht aus einer Folge von Trace Datensätzen des unten
beschriebenen Aufbaus. Alle Daten werden in „btppl“ byte order (d.h. MSB zu-
erst, LSB zuletzt) geschrieben.
Name Typ Bemerkung
trclen OCIT_UI4 Anzahl der Bytes des folgenden Trace Datensat-
zes .
Sec OCIT_UI4 UTC Sekunde wann Tracedatensatz geschrie-

ben wurde.
usec OCIT_UI4 Mikrosekunde der UTC Sekunde wann Traceda-

tensatz geschrieben wurde.
ipadr btppl_ip_address Remote Ip Adresse.
port btppl_port remote port (NBO)
proto- OCIT_UI1 'u' für udp LoPrio, 't' für tcp LoPrio, 'U' für udp
koll
HiPrio, 'T' für tcp HiPrio.
Die Werte 'uUtT' beschreiben Datensätze, die

aufgrund von entfernten Methodenaufrufen zwi-
schen Client und Server entstehen.

Der Wert 'x' bzw. 'X' beschreibt Datensätze, die
aufgrund von lokalen Methodenaufrufen entste-
hen. Diese Methodenaufrufe werden von der
Tracefunktion der BTPPL-Lib ausgelöst.
direc- OCIT_UI1 '>' fuer received Telegramm, '<' fuer sent Tele-
tion gramm.
Tele- HdrLen, Flags… Original Telegramm wie übertragen, start mit
gramm Fletcher btppl header.
s. Kap. 5.1.1
Datentypen in der OCIT-O Library:

Datentyp Datentyp in C Maximal gültiger Be- Übertragungsart Bemerkung
reich
OCIT_UI1 unsigned 0 ... 255 als 1 Byte übertragen 8-Bit ohne Vorzeichen
char (ohne alignment)
OCIT_UI2 unsigned 0 ... 65.535 als 2 Byte übertragen, High-Byte zu- 16-Bit ohne Vorzeichen
short erst (ohne alignment)
OCIT_UI4 unsigned 0 ... 4.294.967.295 als 4 Byte übertragen, High-Byte zu- 32-Bit ohne Vorzeichen
long erst (ohne alignment)
OCIT_SI1 signed char -128 ... +127 als 1 Byte übertragen 8-Bit mit Vorzeichen
(ohne alignment)
OCIT_SI2 signed short -32.768 ... 32.767 als 2 Byte übertragen, High-Byte zu- 16-Bit mit Vorzeichen
erst (ohne alignment)
OCIT_SI4 signed long -2.147.483.648 ... als 4 Byte übertragen, High-Byte zu- 32-Bit mit Vorzeichen
2.147.483647 erst (ohne alignment)
btppl_ip_address unsigned 0 ... 4.294.967.295 als 4 Byte übertragen, High-Byte zu- 32-Bit ohne Vorzeichen
long erst (ohne alignment)
btppl_port unsigned 0 ... 65.535 als 2 Byte übertragen, High-Byte zu- 16-Bit ohne Vorzeichen
short erst (ohne alignment)
8.4 Auftragsstruktur
Um Auftragsframes der Trace Datensätze von z.B. Liste.GetSFSince parsen zu kön-
nen ist die Information über die zum Zeitpunkt der Übertragung vorhandene Auftrags-
struktur notwendig. Hierzu wird am Anfang jeder Trace-Datei ein Trace-Eintrag des
Aufrufs der Methode GetListConfig() von SystemobjektFeldgeraet eingetragen (Re-
quest und Respond). Die Methode wird nicht explizit von einer externen Instanz (z.B.
Trace-Tool) aufgerufen, es wird eine Struktur mit der Auftragsinformation in die
Trace-Datei eingetragen, welche der Rückgabe des Aufrufs GetListConfig() ent-
spricht. Dieser lokale Methodenaufruf wird nicht in die Zentrale oder das Lichtsignal-
steuergerät übertragen.
In den Tracedatensätzen erhalten die Felder "ipadr" und "port" den Wert 0, das Feld
"protokoll" erhält den Wert 'x'.

Fall 1: Trace-Datei
In den Aufrufparameter ZnrFnrFilter muss für FNr und ZNr jeweils der NullValue
(65535) eingetragen werden, damit die Konfiguration aller Feldgeräte eingetragen
wird.
Aufrufparameter ListNrs (leeres Array), somit wird die Konfiguration aller veränderba-
ren Listen eingetragen.
Fall 2: Trace-Connection
In den Aufrufparameter ZnrFnrFilter muss das beim Aufbau der Traceverbindung

ausgewertete Filterkriterium eingetragen werden. Für nicht im Filterkriterium enthal-
tene Werte ist der NullValue (65535) einzutragen. Damit wird die Listenkonfiguration
nur für Geräte eingetragen, für die auch Trace-Datensätze übertragen werden.
Aufrufparameter ListNrs (leeres Array), somit wird die Konfiguration aller veränderba-
ren Listen eingetragen.
Bei der Analyse über Socket wird diese Auftragsinformationen einmal bei Socketauf-
bau gesendet. Der Stream über den Trace-Port und die Trace-Datei sind inhaltlich
identisch und ineinander überführbar.

Glossar
Die Erklärungen der fachtechnische Begriffe und Abkürzungen die in diesem Doku-
ment verwendet werden, finden Sie im Dokument „OCIT – O Glossar V3.0“.
Abbildungsverzeichnis
Abbildung 1: OCIT-Outstations – Schnittstellen ......................................................................... 8
Abbildung 2: Die Schichten im ISO-OSI-Refernzmodell ............................................................ 12
Abbildung 3: Protokolle für OCIT-Outstations .......................................................................... 19
Abbildung 4: Metamodell ......................................................................................................... 39

OCIT-O_Protokoll_V3.0_A01
Copyright  2018 ODG

Ocit-O Protokoll v3.0 A01 PDF

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Ocit-O Protokoll v3.0 A01 PDF

Hochgeladen von

Copyright:

Verfügbare Formate

Open Communication Interface for Road Traffic Control Systems

Offene Schnittstellen für die Straßenverkehrstechnik

OCIT Developer Group (ODG)

Herausgeber: OCIT Developer Group (ODG)

OCIT-O_Protokoll_V3.0_A01 Seite 2 von 67

1.1 Systemgrenzen .............................................................................................. 8

2 Schnittstellen und Systemfunktionen OCIT-Outstations ....................................... 9

2.1 Zentrale Ebene ............................................................................................ 10

2.2 Datenübertragung und Protokoll .................................................................. 10

2.3 Feldgeräte .................................................................................................... 11

3 Kommunikationsmodell OCIT-Outstations ......................................................... 12

3.1 Sicherung der Übertragung .......................................................................... 13

3.1.1 Sicherheitsalgorithmus .................................................................... 13

3.1.2 Firewall ............................................................................................ 13

3.2 Adressen ...................................................................................................... 14

3.3 IP-Netz ......................................................................................................... 14

3.4 Routen ......................................................................................................... 14

3.5 Zeitverhalten ................................................................................................ 14

3.5.1 Systemzeit ....................................................................................... 15

3.5.1.1 Feldgeräte mit permanenten Datenverbindungen zur Zentrale ....... 15

3.5.1.2 Feldgeräte mit temporären Verbindungen zur Zentrale ................... 15

3.5.2 Ereignisorientierte Übertragung ...................................................... 16

3.5.3 Zeitliche Zuordnung......................................................................... 16

3.5.4 Reaktionszeit ................................................................................... 16

3.6 Logische Zuordnung .................................................................................... 16

3.7 Störung der Übertragungseinrichtung .......................................................... 16

4.1 Übertragungsprotokoll der OSI-Schicht 3 (IP) .............................................. 17

OCIT-O_Protokoll_V3.0_A01 Seite 3 von 67

4.2.1 UDP mit Rückmeldung .................................................................... 17

4.2.2 UDP ohne Rückmeldung ................................................................. 18

4.2.3 TCP mit Rückmeldung .................................................................... 18

4.2.4 TCP ohne Rückmeldung ................................................................. 19

4.2.5 Übertragungssicherung in der Transportebene ............................... 19

5 OCIT-Outstations Protokoll BTPPL (OSI-Schichten 5-7).................................... 19

5.1 Basis Transport Paket Protokoll Layer - BTPPL .......................................... 20

5.1.1 Telegrammaufbau BTPPL: .............................................................. 21

5.2 Allgemeine Kommunikation Client – Server ................................................. 23

5.2.1 Änderung des Domain-Namens von Feldgeräten über einen DNS . 24

5.3 Zeitliche Zuordnung (Zeitstempel) ............................................................... 24

5.3.1 Timeout ........................................................................................... 25

5.4 Logische Zuordnung .................................................................................... 25

5.5 Codierung der Daten.................................................................................... 25

5.6 Objekte ........................................................................................................ 26

5.6.1 Member-Nummer ............................................................................ 28

5.6.2 Identifizierung der Objekte .............................................................. 28

5.6.2.1 Auswahl der Returncodes (RetCodes) ............................................ 29

5.7 Sicherung der Übertragung beim OCIT-Outstations Protokoll ..................... 32

5.7.1 OCIT-O Passworte .......................................................................... 32

5.7.1.1 Installation eines neuen Gerätes ..................................................... 33

5.7.1.2 Wechsel des OCIT-O Passworts eines Feldgerätes ........................ 33

5.7.2 Übertragungssicherung durch den Fletcher-Algorithmus ................ 34

5.7.3 Übertragungssicherung durch den SHA-1 Algorithmus ................... 35

5.7.3.1 Bildung der Prüfsumme ................................................................... 36

OCIT-O_Protokoll_V3.0_A01 Seite 4 von 67

5.7.3.3 Vom Sicherheitsprotokoll verwendete Returncodes ........................ 38

5.8 Prüfung des TCP-Kanals ............................................................................. 38

6.1 Schnittstellenobjekte .................................................................................... 39

6.1.1 Grunddatentypen: ........................................................................... 39

6.1.2 Metaelement DECL ......................................................................... 41

6.1.3 REFPATH ....................................................................................... 41

6.1.3.1 REFPATH_DATA ............................................................................ 42

6.1.3.2 EXTENSIBLE .................................................................................. 42

6.1.3.3 MINCOUNT MAXCOUNT ................................................................ 43