OCIT-C Center to Center Transport Protokoll
Transcript of OCIT-C Center to Center Transport Protokoll
O C I T D e v e l o p e r G r o u p ( O D G ) & P a r t n e r
OCIT® Registered trade mark of AVT-STOYE, Siemens, Stührenberg, SWARCO
Open Communication Interface for Road Traffic Control Systems
Offene Schnittstellen für die Straßenverkehrstechnik
OCIT-C Center to Center
Transport Protokoll
OCIT-C_Protokoll_V1.1_R1
OCIT-C_Protokoll_V1.1_R1 Seite 2 von 43
OCIT-C Center to Center
Transport Protokoll
Dokument: OCIT-C_Protokoll_V1.1_R1
Herausgeber: ODG & Partner
Kontakt: www.ocit.org
Copyright 2014 ODG. Änderungen vorbehalten. Dokumente mit Versions- oder Ausgabe-stände neueren Datums ersetzen alle Inhalte vorhergehender Versionen.
OCIT-C_Protokoll_V1.1_R1 Seite 3 von 43
Inhalt
1 Einführung ...................................................................................................................... 6
1.1 Begriffe und Abkürzungen ....................................................................................... 7
2 Protokoll ......................................................................................................................... 9
2.1 Übertragungsprotokoll SOAP .................................................................................. 9
2.1.1 Technik ...................................................................................................... 9
2.1.2 Anforderungen ans Protokoll .....................................................................10
2.1.3 Sicherheit ..................................................................................................10
2.1.4 Erforderliche Bandbreite ...........................................................................10
2.2 Protokollfunktionen .................................................................................................10
2.2.1 Lesen von Daten durch den Client ............................................................11
2.2.2 Senden von Daten zum Server .................................................................12
2.3 Ablaufsteuerung .....................................................................................................13
2.3.1 Datenpufferung und Positionsbehandlung ................................................14
2.3.2 Zu lange Transaktionszeit .........................................................................15
2.3.3 Zu lange Abfragen ....................................................................................15
2.3.4 Handhabung von Abfragen historischer Daten ..........................................16
2.3.5 Multi Client Fähigkeit .................................................................................16
2.3.6 Resynchronisieren ....................................................................................17
2.3.7 Bidirektionale Kommunikation ...................................................................18
2.3.7.1 Bidirektionale Kommunikation mit Client und Server Paar ..................19
2.3.7.2 Bidirektionale Kommunikation mit regelmäßiger Zustandsabfrage (polling) ..............................................................................................22
2.3.8 Vermeidung von Abtastverzögerungen .....................................................22
2.4 OSI – Schichten ......................................................................................................24
2.5 Protokollfunktionen im Detail ..................................................................................25
2.5.1 Standard-Parameter .................................................................................26
2.5.2 put .............................................................................................................27
2.5.3 get .............................................................................................................28
OCIT-C_Protokoll_V1.1_R1 Seite 4 von 43
2.5.4 inquireAll ...................................................................................................31
2.5.5 delete ........................................................................................................33
2.5.6 getContentInfo ..........................................................................................35
2.5.7 wait4Get ....................................................................................................36
2.6 Datenstrukturen ......................................................................................................37
2.7 Definition ErrorCodes .............................................................................................38
2.8 Anwendungsempfehlungen ....................................................................................38
2.8.1 Datenlieferung bei mehreren Abnehmern .................................................39
2.8.2 Konfigurations-Schnittstelle .......................................................................39
2.8.3 Daten-Update zwischen zentralen Einrichtungen (unidirektional) ..............40
2.8.4 Daten-Update zwischen zentralen Einrichtungen (bidirektional) ................41
OCIT-C_Protokoll_V1.1_R1 Seite 5 von 43
Dokumentenstand
Version
Zustand
Datum Verteiler Kommentar
V1.1_R1 30.10.2014 PUBLIC Version 1.1 Ausgabe 1
OCIT-C_Protokoll_V1.1_R1 Seite 6 von 43
11 EEiinnffüühhrruunngg
OCIT-C steht für Open Communication Interface for Road Traffic Control Systems – Center to Center. Mit OCIT-C werden die Funktionen zur Kommunikation zwischen zentralen Ver-kehrssteuerungs- und Verkehrslenkungssystemen abgedeckt:
Verkehrsrechnerzentralen und Verkehrsmanagementzentralen (kommunal, regional, überregional)
Verkehrsingenieurarbeitsplatz mit Verkehrsrechnerzentralen
Parkleitsysteme, Parkhaussysteme
Baustellenmanagementsysteme
Lokale Internetanwender (städtische Info im Internet)
Die Definition und Pflege der Schnittstelle OCIT-C wird von der ODG und ihren Partnern durchgeführt.
Mit OCIT-C steht ein Standard zur Verfügung, der über die Standardisierungsergebnisse von OCIT-I (OCIT-Instations) hinausreicht und OCIT-O passgenau ergänzt. Mit OCIT-C und OCIT-O für die Kommunikation von Zentralen zu Feldgeräten werden alle Anforderungen von der Verkehrssteuerung bis hin zum übergeordneten Verkehrsmanagement abgedeckt.
OCIT-C orientiert sich konsequent an den praktischen Anforderungen. Durch niedrige Im-plementierungskosten ist der Einsatz auch für Lösungen mit schmalen Budgets geeignet.
Charakteristische Eigenschaften von OCIT-C sind:
Auf dem Standard SOAP basierendes Austauschprotokoll mit einfachem Request-Response-Kommunikationsmuster (direktes Abfragen von Daten).
Definition eines umfassenden, alle Teilbereiche der Verkehrssteuerung und Verkehrslenkung enthaltenen Datenmodells im Prozessdatenbereich, Verwendung des OCIT-I Versorgungsdatenmodells für LSA. Die Funktionalität des Datenmodells von OCIT-I wird vollständig abgebildet.
Systemintegration und gewünschte Anpassungen werden vorab über Projektierung geregelt.
Konformitätstests des Protokolls werden in einer über www.ocit.org bereitgestellten Testumgebung durchgeführt. Tests von gesamten Implementierungen (Protokoll und Dateninhalte) werden projektbezogen durchgeführt.
Erweiterungen um DATEX II Bestandteile sind je nach Projektanforderungen möglich.
Die Kommunikationsschnittstelle soll in allen zentralen Einheiten in gleicher Weise imple-mentiert werden. Dazu wird das SOAP-Protokoll als übergeordnete Kommunikationsschnitt-stelle, über die die gesamte Kommunikation erfolgt, verwendet. Die hier beschriebene Aus-prägung wird als OCIT-C Protokoll bezeichnet.
Diese Schnittstelle ist offen und kann in diversen Systemen, vorwiegend im Bereich der Straßenverkehrstechnik, eingesetzt werden. Die Aufgabe dieses Dokuments ist es, das
OCIT-C_Protokoll_V1.1_R1 Seite 7 von 43
OCIT-C Protokoll und seine Verwendung zu beschreiben. Es ist nicht die Aufgabe dieses Dokuments, die Datenstrukturen der zu übertragenden Daten zu beschreiben. Diese sind im Dokument „OCIT-C Daten“ beschrieben.
11..11 BBeeggrriiffffee uunndd AAbbkküürrzzuunnggeenn
Begriff / Abkürzung Beschreibung
AP Anwenderprogramm
Client Ein Programm, das von anderen (Servern) angebotene Dienste in An-spruch nehmen will und diese dazu aktiv aufruft.
DATEX II Spezifikationen des Technischen Komitees 278 des Europäischen Komi-tees für Normung (CEN) zum Austausch von Verkehrsinformationen zwischen Verkehrszentralen.
FTP File Transfer Protocol, ein Netzwerkprotokoll zur Dateiübertragung
http Hypertext Transfer Protocol, ein Protokoll zur Übertragung von Daten über ein Netzwerk.
LSA Lichtsignalanlage
Methode Die einer Klasse von Objekten zugeordneten Algorithmen. Auch syno-nym gebraucht als Funktion, Prozedur, Befehl, Aktion.
ÖV Öffentlicher Nahverkehr
OCIT Open Communication Interface for Road Traffic Control Systems / Offe-ne Schnittstellen für die Straßenverkehrstechnik.
OCIT-C Open Communication Interface for Road Traffic Control Systems – Cen-ter to Center. Mit OCIT-C werden die Funktionen zur Kommunikation zwischen zentralen Verkehrssteuerungs- und -Verkehrslenkungssystemen abgedeckt.
OCIT-O OCIT-Outstations Schnittstelle zwischen Verkehrssteuerungszentralen und Lichtsignal-steuergeräten zur Steuerung und Versorgung der Lichtsignalsteuergerä-te
OCIT-I PD OCIT-Instations Schnittstellen zwischen zentralen Einrichtungen zum Austausch von Pro-zessdaten der Lichtsignalsteuerung
OCIT-I VD OCIT-Instations Schnittstellen zwischen zentralen Einrichtungen zum Austausch von Versorgungsdaten der Lichtsignalsteuerung
ODG OCIT Developer Group
OSI OSI-Schichtenmodell (auch OSI-Referenzmodell; englisch Open Sys-
OCIT-C_Protokoll_V1.1_R1 Seite 8 von 43
tems Interconnection Reference Model), ein Kommunikationsmodell der Internationalen Organisation für Normung (ISO) für Kommunikationspro-tokolle in Rechnernetzen.
OTS 2 Open Traffic Systems, Version 2
Server Ein Programm, das bestimmte Dienste anbietet und dazu passiv auf eingehende Aufrufe (von Clients) wartet.
SOAP SOAP (Simple Object Access Protocol), ist ein Protokoll mit dessen Hilfe Daten zwischen Systemen ausgetauscht werden können. SOAP ver-wendet „Remote Procedure Call“ und ermöglicht dadurch den Aufruf von Funktionen in anderen Computern. Siehe http://www.w3.org/TR/SOAP
SSL Secure Socket Layer.
SoapServer-Interface Soap and ProtocolManager auf der Server-Seite
SoapClient-Interface Soap and ProtocolManager auf der Client-Seite
Protocolmanager Protokollschicht zur Implemtierung von Komm andos im Puffer
TLS Technische Lieferbedingungen für Streckenstationen. Die TLS sind ein Standard für den Aufbau von Verkehrsbeeinflussungsanlagen an Bun-desfernstraßen. Herausgeber: Bundesanstalt für Straßenwesen.
TCP / IP Transmission Control Protocol / Internet Protocol, eine Familie von Netzwerkprotokollen für das Internet.
VDV Verband Deutscher Verkehrsunternehmen
WSDL Web Services Description Language, eine plattform-, programmierspra-chen- und protokollunabhängige Beschreibungssprache für Netzwerk-dienste (Webservices) zum Austausch von Nachrichten auf Basis von XML.
XML Extensible Markup Language, eine Auszeichnungssprache zur Darstel-lung strukturierter Daten in Form von Text. XML wird u. a. für den platt-form- und implementationsunabhängigen Austausch von Daten zwischen Computersystemen eingesetzt. Ein XML-Dokument besteht aus Textzei-chen, im einfachsten Fall in ASCII-Kodierung, und ist damit maschinen-lesbar. Binärdaten enthält es nicht. Die XML-Spezifikation wird vom World Wide Web Consortium (W3C) als Empfehlung (Recommendation) herausgegeben.
XSD XML Schema, eine Empfehlung des World Wide Web Consortium (W3C) zum Definieren von Strukturen für XML-Dokumente. Die Struktur wird in Form eines XML-Dokuments beschrieben. Darüber hinaus wird eine große Anzahl von Datentypen unterstützt. In der XSD Schemaspra-che werden Datentypen, einzelne XML-Schema-Instanzen (Dokumente) und Gruppen solcher Instanzen beschrieben. Ein konkretes XML Sche-ma wird auch als eine XSD (XML Schema Definition) bezeichnet und hat als Datei üblicherweise die Endung „.xsd“.
OCIT-C_Protokoll_V1.1_R1 Seite 9 von 43
22 PPrroottookkoollll
Die gesamte Kommunikation über die Schnittstelle wird mittels des SOAP Protokolls abge-wickelt.
In diesem Kapitel wird die Anwendung des Protokolls für die Schnittstelle OCIT-C beschrie-ben. Diese Konfiguration muss in allen Clients und Servern installiert werden.
Die genaue Beschreibung des dem Protokoll zugrunde liegenden Datenmodells, sowie die elementare Beschreibung der Attribute und Elemente erfolgt vollständig innerhalb der ein-zelnen Schemadefinitionen in Form von XML Schemadefinitionen (XSD). Diese sind sowohl maschinell verarbeitbar als auch als Text lesbar. Die Schemadefinitionen wurden in engli-scher Sprache erarbeitet und werden nicht übersetzt.
22..11 ÜÜbbeerrttrraagguunnggsspprroottookkoollll SSOOAAPP
Dieses Kapitel beschreibt die SOAP Schnittstelle.
22..11..11 TTeecchhnniikk
Die zu übertragenden Daten werden als XML codiert. Dies hat folgende Vorteile:
Übliches Protokoll für alle Bereiche,
Unabhängigkeit von der Art der Daten,
plattformunabhängig,
einfach zu erweitern.
Als Übertragungsverfahren wird SOAP auf der Basis von http benutzt. SOAP verwendet ebenfalls XML, um seine Daten aufzubauen.
Das Protokoll enthält einfache Befehle wie Empfange (get) oder Lösche (delete).
OCIT-C_Protokoll_V1.1_R1 Seite 10 von 43
22..11..22 AAnnffoorrddeerruunnggeenn aannss PPrroottookkoollll
Das Protokoll ist ein Server-Client Protokoll.
Daten werden an der Ausgangs-Schnittstelle als XML dargestellt.
Daten werden an der Eingangs-Schnittstelle als XML akzeptiert.
Befehle sind in XML eingebettet.
Objekte werden durch externe Bezeichner identifiziert.
Unterschiedliche Objekttypen dürfen nicht auf einmal angefordert (in einem „request“) werden.
Das Protokoll ist innerhalb des Servers zustandslos. Der Server weiß nichts über den Client.
22..11..33 SSiicchheerrhheeiitt
Der Server enthält eine Liste der Benutzernamen und der mit ihnen verbundenen Passwör-ter, sowie die dem Nutzer erlaubten Operationen und Zugänge zu Clients.
22..11..44 EErrffoorrddeerrlliicchhee BBaannddbbrreeiittee
Die erforderliche Bandbreite hängt von der Anzahl der Clients, der Objekttypen und Objekte im System ab. Daher können hier keine Angaben zur Bandbreite gemacht werden. Ein Local Area Network (LAN) zwischen den zentralen Anwendungen wird jedoch eine ausreichende Übertragungskapazität bieten.
22..22 PPrroottookkoollllffuunnkkttiioonneenn
Das Protokoll erlaubt Lesen und Konfigurieren von Daten. Außerdem ist es ist möglich, Ob-jekte hinsichtlich der Verwendbarkeit auszuwerten und während der Laufzeit dynamisch zu strukturieren. Jeder Befehl besteht einer Anforderung (Request) und einer Antwort (Res-pond).
Bei einem Request wird eine XML Struktur vom Client zum Server geschickt. Das Ergebnis wird vom Server als „Resultat“ (auch „response structure“ genannt) zum Client zurückge-schickt.
Verfügbare Methoden:
Aufruf (request) Antwort (response) Funktion
put putResponse Konfigurieren von Objekten
get getResponse Abfragen von geänderten Daten seit der letzten Abfrage
inquireAll inquireAllResponse Abfragen aller Objekte eines Objekttyps
OCIT-C_Protokoll_V1.1_R1 Seite 11 von 43
Aufruf (request) Antwort (response) Funktion
delete deleteResponse Löschen von dynamischen Daten
getContentInfo getContentInfoResponse Abfragen von Objektinhalten
wait4Get wait4GetResponse Abfragen von geänderten Daten seit der letzten Abfrage (wie get) mit dem Unter-schied, dass die Response verzögert wird, bis Daten zur Verfügung stehen.
22..22..11 LLeesseenn vvoonn DDaatteenn dduurrcchh ddeenn CClliieenntt
Alle Protokollfunktionen zum Lesen von Daten beinhalten einen Parameter (Filter), der die Objekte kennzeichnet, die gelesen werden sollen.
Falls der Filter leer ist, werden alle Objekte in der zugehörigen Antwort zurückgesendet. Damit sich der Client im Falle einer Unterbrechung wieder synchronisieren kann, werden die Startinformationen der vorhergehenden Antwort eines Lesezugriffs mit übertragen.
Der Server bietet alle lesbaren Daten der vorhandenen Objekte an seiner äußeren Schnitt-stelle an. Die vorhandenen Objekt-Typen können vom Client mit dem Befehl getContentInfo abgefragt werden. Diese können vom Client mit „get“ oder „inquireAll“ gelesen werden (wenn der Lesezugriff erlaubt ist).
Der Unterschied zwischen inquireAll und get ist:
inquireAll (Resynchronisierungsfunktion) liefert alle Objekte des abgefragten Objekt-Typs mit dem letzten Zustand bzw. dem Inhalt der Objekte. inquireAll muss in jedem Fall einer Synchronisierung (z. B. Wiederanlauf des Servers oder Clients) verwendet werden.
get (hier als Lesen von Änderungen gebraucht) liefert alle seit der letzen Abfrage vorgenommen inhaltlichen Änderungen des abgefragten Objekt-Typs. Dieser Mechanismus wird im Detail im Kapitel 2.3.1, Datenpufferung und Positionsbehandlung, beschrieben.
Das folgende Ablaufdiagramm Bild1 zeigt, wie Daten des Servers periodisch mithilfe der Protokollfunktionen inquireAll und get angefordert werden.
OCIT-C_Protokoll_V1.1_R1 Seite 12 von 43
Soap-
Client-I
Soap-
Server-I
Data-
Base
Data
inquireAll
inquireAll-
ResponseNow the
client knows all objects
of the requested object
type
Data
Data
Data
Data
Data
Data
get
getResponse
Now the
client knows all changes
since last request
get
Soap-
Client-I
Soap-
Server-I
Data-
Base
get
getResponse
Bild 1: Übliche Reihenfolge zum Lesen von Daten vom SOAPserverInterface
22..22..22 SSeennddeenn vvoonn DDaatteenn zzuumm SSeerrvveerr
Es ist möglich, Daten vom Client zum Server zu senden. Dazu wird die Protokollfunktion „put“ verwendet. Das Verhalten des Servers hängt vom Objekt-Typ ab. Im Falle von unbe-kannten Objekten im put Befehl wird entweder das Objekt erzeugt oder eine Störung zu-rückgesendet. Um Objekte zu löschen wird der Befehl „delete“ abgesetzt.
Zur Konfiguration der Schnittstelle werden die entsprechenden Daten mit put zum Server gesendet. Der Server nimmt sie an oder weist alle nicht konfigurierbaren Objekte zurück und listet sie in der putResultlist auf.
OCIT-C_Protokoll_V1.1_R1 Seite 13 von 43
Soap-
Client-I
Soap-
Server-I
Data-
Base
put
put-
Response
Data
Data
put
put-
Response
Soap-
Client-I
Soap-
Server-I
Data-
Base
Now the
client knows about
successfull configured
objects and errors
Now the
client knows about
successfull configured
objects and errors
Bild 2: Übliche Reihenfolge zum Schreiben oder Konfigurieren von Daten zum SOAPserverInterface
22..33 AAbbllaauuffsstteeuueerruunngg
Das Protokoll ist verbindungslos. Zu Ablaufsteuerung (sequence control) reicht es aus auf die Antwort einer Anfrage zu warten. Dies wird durch das Protokoll http geregelt. Eine zu-sätzliche Ablaufsteuerung wird nicht benötigt. Passende Abläufe werden in folgenden Kapi-teln beschrieben.
OCIT-C_Protokoll_V1.1_R1 Seite 14 von 43
22..33..11 DDaatteennppuuffffeerruunngg uunndd PPoossiittiioonnssbbeehhaannddlluunngg
Bild 3: Datenpufferung am Server und Positionsbehandlung am Client
Der Server legt die vom Client angeforderten Daten aus seiner Datenbank in einem Ringpuf-fer ab. Nach der Durchführung eines inquireAll, kennt der Client den letzten Zustand der der Datenbank. Außer der InquireAll Antwort empfängt der Client die letzte Positionszahl und zeigt die letzten Informationen vom Server an (Zeiger zu den letzten empfangenen Daten im Datenpuffer). Mithilfe dieser Positionszahl erzeugt der Client die nächste Anforderung (get). Durch die Positionszahl weis der Server, welche Daten zur Verfügung gestellt werden müs-sen, um alle aufgetreten Änderungen zu liefern. Die erhaltene Antwort umfasst die ge-wünschten Daten und eine neue Positionszahl, die für die nachfolgende Abfrage verwendet wird.
Wenn ein Client mehr als einen Objekt-Typ abfragen will, müssen mehrere Anfragen benutzt werden.
Jede Anfragenreihe muss eine eigene Positionsbehandlung durchführen, um Objekt-Typ bezogene Deltawerte zu erhalten. Dies gilt auch im Falle der Verwendung von unterschiedli-chen Filterlisten und bei der Verwendung von Parametern mit dem optionalen XML Element getdata.
OCIT-C_Protokoll_V1.1_R1 Seite 15 von 43
22..33..22 ZZuu llaannggee TTrraannssaakkttiioonnsszzeeiitt
Normalerweise enthält eine Antwort die angeforderten Daten. Falls der Server mehr Zeit als zulässig benötigt (> 60s), wird eine leere Antwort wird zum Client zurückgegeben. Die über-schrittene Transaktionszeit wird durch einen Störungscode angezeigt. Trotzdem fährt der Sever fort, weiter angeforderten Daten von seiner Datenbank (oder vom Archiv) zu holen. Der Client wiederholt seine Anfrage nach einer bestimmten Zeit. Nach dieser Zeit sollte der Server in der Lage sein, die Daten zu liefern. Falls der Server noch immer nicht liefern kann, wird wieder ein Störungscode angezeigt.
Soap-
Client-I
Soap-
Server-I
Data-
Base
inquireAll
inquireAllResponse
(error=too long time)
Soap-
Client-I
Soap-
Server-I
Data-
Base
data access
data
access
requires
time
data access
returns data
inquireAll
inquireAllResponse
(data, pos. number)
wa
iting
time
Bild 4: Handhabung langer Transaktionszeiten (ähnliche Reihenfolge gilt auch für „get“)
22..33..33 ZZuu llaannggee AAbbffrraaggeenn
Der Server liefert einen Störungscode zurück, falls der Inhalt einer Antwort eine bestimmte Schwelle übersteigt. Dieses kann geschehen, falls
zu viele historischen Daten angefordert werden (Zeitbereich zu groß), oder
seit der letzten Abfrage zu viele Änderungen angefallen sind, oder
zu viele Objekte abgefragt werden.
Der Client muss seine Anforderung durch Reduktion der Anzahl der Objekte oder des Ab-fragezeitraums entsprechend verringern.
OCIT-C_Protokoll_V1.1_R1 Seite 16 von 43
22..33..44 HHaannddhhaabbuunngg vvoonn AAbbffrraaggeenn hhiissttoorriisscchheerr DDaatteenn
Der Befehl „get“ wird verwendet, falls ein Zugang zu den historischen Daten angefordert wird.
Das Element „storetime“ wird benutzt, um den Anfangszeitpunkt der gespeicherten historischen Daten zu definieren.
Das Element „endstore“ wird benutzt, um den Endezeitpunkt der gespeicherten historischen Daten zu definieren.
Die Antwort des Servers enthält die Daten von „storetime“ bis „endstore“, sofern das Abfrageintervall nicht zu groß definiert wurde.
Sollte das Abfrageintervall zu groß definiert worden sein, wird die Abfrage so weit als möglich befriedigt, indem entweder nicht alle Objekte oder nicht der gesamte Zeitbereich zurückgegeben wird. Die unvollständige Rückgabe wird über den errorCode (in der protocol.xsd) signalisiert (errorCode: missingDatasets)
Es wird empfohlen:
Den Zeitbereich so kurz wie möglich zu wählen
Filter zu verwenden und damit die Menge der abzufragenden Objekte zu verringern.
Bei historischen Abfragen soll der beim Startzeitpunkt der Abfrage vorliegende Wert (Status, Messwert o.a.) in der Antwort aufgeführt werden. Der Wert erhält dann als Zeitstempel ent-weder exakt den Originalzeitstempel des Wertes oder, sollte dieser nicht vorliegen, wird der initiale Zeitstempel nicht aufgeführt (Zeitstempel ist optionales Element in der protocol.xsd).
Kann der Initialwert nicht geliefert werden, oder macht deren Lieferung keinen Sinn (z.B. bei dem Objekttyp „operatingMessages“), so wird erst dann ein Wert geliefert, wenn innerhalb des Abfragezeitraums ein Zustandswechsel stattfindet.
22..33..55 MMuullttii CClliieenntt FFäähhiiggkkeeiitt
Der Server arbeitet verbindungslos. Durch die Positionszahl ist es nicht notwendig auf der Serverseite Wissen über den Client aufzubauen.
Bei der Implementierung von OCIT-C muss sichergestellt werden, dass die benutzten Biblio-theken der unteren Kommunikationsschichten einen mehrfachen Client-Zugang erlauben.
OCIT-C_Protokoll_V1.1_R1 Seite 17 von 43
Bild 5: Multi Client Fähigkeit
22..33..66 RReessyynncchhrroonniissiieerreenn
Es gibt verschiedene Gründe für eine erneute Synchronisierung (Resynchronisation):
Neustart des Clients
o Der Client erkennt dies und wird daher mit „inquireAll“ resynchronisieren.
o Der Server kann möglicherweise den Neustart des Clients mittels eines optional implementierbaren Watchdogs erkennen.
OCIT-C_Protokoll_V1.1_R1 Seite 18 von 43
Neustart des Servers
o Der Client erkennt möglicherweise über „socket timeout“, dass der Server nicht erreichbar ist.
o Der Server reagiert auf jede mögliche Protokollfunktion (inquireAll, get oder put), einschließlich lastStart, das anzeigt, wenn der Server gestartet wurde.
o Der Client muss mit inquireAll resynchronisieren, falls sich lastStart von vorherigen unterscheidet.
Soap-
Client-I
Soap-
Server-I
Soap::inquireAll
get-Response
The client recognises
server restart with modified
lastStat in get response
Soap-
Client-I
Soap-
Server-I
get
Serverrestart
get-Response
get
getClient recognises server
restart with socket error
inquireAll-Response
get-Response
get
get-Response
get
Bild 6: Neustart des Servers
22..33..77 BBiiddiirreekkttiioonnaallee KKoommmmuunniikkaattiioonn
Die folgenden Anwendungsfälle benötigen bidirektionale Kommunikation:
LSA Steuerung oder Schildersteuerung:
o Schaltbefehl wird übertragen von Zentrale nach Geräteserver
o Schaltzustand wird asynchron übertragen von Geräteserver nach Zentrale
OCIT-C_Protokoll_V1.1_R1 Seite 19 von 43
CCTV
o PTZ (pan/til/zoom) Befehl wird übertragen von Zentrale nach Geräteserver
o - Aktueller Zustand wird asynchron übertragen von Geräteserver nach Zentrale
Die folgenden Kapitel beschreiben mögliche Konfigurationen. Als Beispiel wird die „Schilder-steuerung“ verwendet.
22..33..77..11 BBiiddiirreekkttiioonnaallee KKoommmmuunniikkaattiioonn mmiitt CClliieenntt uunndd SSeerrvveerr PPaaaarr
Schalten eines Schildes (Ablaufreihenfolge im Gutfall)
Soap-
Client-I
Soap-
Server-I
put (Sign Switch
Command)
Soap::put-
Result
Soap-
Client-I
Soap-
Server-I
Soap-
Client-I
Soap-
Server-I
Soap-
Server-I
Soap-
Server-I
forward switch to
application
switch command to the
interface
put (Sign Switch State-o.k./content information)
Soap::put-
Result
change state
to
o.k.(successful
switch
command)
change state
to o.k.
central system sign
S
i
g
n
-
S
e
r
v
e
r
-
A
p
p
l
c
s
-
S
e
r
v
e
r
-
A
p
p
l
Bild 7: Schalten eines Schildes (Ablaufreihenfolge im Gutfall)
OCIT-C_Protokoll_V1.1_R1 Seite 20 von 43
Schalten eines Schildes (Ablaufreihenfolge im Fehlerfall)
Soap-
Client-I
Soap-
Server-Iput (Sign Switch
Command)
Soap::put-
Result
Soap-
Client-I
Soap-
Server-I
Soap-
Client-I
Soap-
Server-I
Soap-
Server-I
Soap-
Server-I
put (Sign Switch State-n.o.k.)
Soap::put-
Result
forward switch to
application
change state
to n.o.k( not
accepted
switch
command)
switch command to the
interface
change state
n.o.k.
central system sign
S
i
g
n
-
S
e
r
v
e
r
-
A
p
p
l
c
s
-
S
e
r
v
e
r
-
A
p
p
l
put (Sign Switch
Command)
Soap::put-
Result
forward switch to
application
switch command to the
interface again (repeat after
delay max. 3 times)
Sequence continues
depending on the
following answeres
of the sign server.
Bild 8: Schalten eines Schildes (Ablaufreihenfolge im Fehlerfall)
Im Falle einer fehlenden Antwort werden die Schaltbefehle nach einer konfigurierbaren Ver-zögerung wiederholt. Dies gilt unabhängig davon wo die Störung auftritt (es erfolgt kein Zu-standsübergang zum Zustand „busy“ oder „o.k.“). Das Wiederholen wird nachdem drei er-folglosen Versuchen gestoppt. Dann ändert sich der aktuelle Zustand an der Seite des zent-ralen Systems zu n.o.k.
OCIT-C_Protokoll_V1.1_R1 Seite 21 von 43
Zustand-, Inhalts- und Verbindungsüberwachung
Soap-
Client-I
Soap-
Server-I
Soap-
Client-I
Soap-
Server-I
Soap-
Client-I
Soap-
Server-I
Soap-
Server-I
Soap-
Server-I
put (Sign Switch State-n.o.k.)
Soap::put-
Result
change state
to n.o.k(any
errer detcted
on sign)
change state
n.o.k.
central system sign
S
i
g
n
-
S
e
r
v
e
r
-
A
p
p
l
c
s
-
S
e
r
v
e
r
-
A
p
p
l
put (Sign Switch State-o.k.)
Soap::put-
Result
change state
to o.k(sign
becomes o.k.)
change state
o.k.
put (Sign Switch State-o.k.)
Soap::put-
Result
change state
to o.k(sign
becomes o.k.)
change state
o.k.
The signserver updates the
central system periodicly.
(Lifecycle telegramm). In
case of non reachable
serverTMS the sign falls
back to default.
Bild 9: Schaltzustand
Der Schilder-Server (sign server) aktualisiert das zentrale System (central system) periodisch, auch wenn sich der Schaltzustand nicht ändert. Folglich erhält das zentrale System Nachricht:
falls ein Schild, das an das Schilder-Server angeschlossen wird, seinen Zustand ändert
falls ein Schild seinen Inhalt ändert
falls der Schilder-Server unerreichbar ist (die max. Wartezeit gibt das zentrale System vor)
Falls das zentrale System unerreichbar ist, setzt der Schilder-Server die Schilder auf einen vordefinierten Anzeigezustand.
OCIT-C_Protokoll_V1.1_R1 Seite 22 von 43
22..33..77..22 BBiiddiirreekkttiioonnaallee KKoommmmuunniikkaattiioonn mmiitt rreeggeellmmääßßiiggeerr ZZuussttaannddssaabbffrraaggee ((ppoolllliinngg))
Die Auswertung der Zustände erfolgt sinngemäß wie in Kapitel 2.3.7.1.
Soap-
Client-I
Soap-
Server-I
put (Sign Switch Command)
Soap::put-
Result
Soap-
Client-I
Soap-
Server-I
forward switch to
application
switch command to
the interface
get (Sign Switch State)
get-response
change state to o.k.(successful
switch command)
change state to o.k.
central system sign
S
i
g
n
-
S
e
r
v
e
r
-
A
p
p
l
c
s
-
S
e
r
v
e
r
-
A
p
p
l
get (Sign Switch State)
get-response
get (Sign Switch State)
get-response
Bild 10: Regelmäßige Zustandsabfrage
22..33..88 VVeerrmmeeiidduunngg vvoonn AAbbttaassttvveerrzzööggeerruunnggeenn
Zur Vermeidung von ungewollt grossen Abtastverzögerungen durch zyklische Abfragen vom Client zum Server wird eine neue Funktion im Protokoll eingeführt. Diese Funktion arbeitet nach folgendem Prinzip:
Aufbau wie die Funktion „get“ (d.h. gleiche Parameter, nur andere Funktionsbezeichnung)
Name der Funktion „wait4Get“
Die neue Funktion wait4Get arbeitet wie die Funktion get mit dem Unterschied, dass im Falle keiner vorliegenden Daten am Server (d.h. die Rückgabeliste wäre leer) die Response aus dem wait4Get verzögert wird bis entweder ein Timeout auftritt oder Daten am Server verfügbar werden.
Der Client würde also unmittelbar nach Empfang einer Antwort die Funktion wait4Get wiederum aufrufen, um dann den Rückkanal indirekt permanent geöffnet zu halten.
OCIT-C_Protokoll_V1.1_R1 Seite 23 von 43
Zur Vermeidung von mehreren Abfragen innerhalb einer Sekunde kann der Server Schutzmaßnahmen ergreifen. Eine mögliche Schutzmaßnahme wäre nur eine Antwort pro Sekunde zuzulassen und die sich in dieser Sekunde angesammelten Werte in der Antwort zurückzugeben.
Der Server kann die Anzahl der Clients bzw. Objekttypen/Objekte, die auf diese Weise abgefragt werden, einschränken.
Zur Vermeidung zu vieler geöffneter Sockets ermöglicht die Funktion wait4Get die gleichzeitige Abfrage verschiedener Objekttypen. Dies wurde entsprechend in den Da-tenstrukturen der Funktion berücksichtigt.
Das folgende Sequenzdiagramm verdeutlicht das Vorgehen (vereinfacht für die Abfrage eines Objekttyps:
Bild 11: Kommunikationschichten Client und Server
Soap-
Client-I
Soap-
Server-I
Server
data
buffer
inquireAll
inquireAllResponse (data, pos=p1)
The client initiates
wait4get without any
delaywait4get (pos=p1)
wait4get-Response
(data since last pos =p1, pos=p2)
Soap-
Client-I
Soap-
Server-I
(data, pos=p1)
(data, pos=p2)
(data, pos=p3)
The server has no new data
(related to p1). Server delays the
answere til data available
wait4get (pos=p2)(data, pos=p4)
wait4get-Response
(data : pos=p3 and p4)
The client initiates next
call of wait4get without
any delay
OCIT-C_Protokoll_V1.1_R1 Seite 24 von 43
22..44 OOSSII –– SScchhiicchhtteenn
Server und Client besitzen entsprechend dem OSI Modell in verschiedene Abschnitte mit unterschiedlicher Funktion unterteilt.
Die unterste Protokollschicht bildet das Protokoll http, das für die Datenübertragung im Netzwerk zuständig ist.
Darüber liegt das SOAP-Protokoll als Client- oder Server Ausführung.
Der Protokollmanager hat die Aufgabe, alle Befehle einschließlich den erforderlichen Daten-puffer für die Serverfunktionalität bereit zu stellen.
Die Applikationsschicht stellt die Verbindung zur Datenbank her.
Das folgende Bild beschreibt zeigt diese Schichtmodell.
Soap-ClientWebServer
(Soap)
PM-ClientProtokoll-
Manager
Data/
Application
httphttp
Data/
Application
Bild 12: Kommunikationschichten Client und Server
OCIT-C_Protokoll_V1.1_R1 Seite 25 von 43
22..55 PPrroottookkoollllffuunnkkttiioonneenn iimm DDeettaaiill
Verfügbare Methoden:
Bild 13: Verfügbare Methoden
OCIT-C_Protokoll_V1.1_R1 Seite 26 von 43
22..55..11 SSttaannddaarrdd--PPaarraammeetteerr
Die Standard-Parameter der Methoden sind:
Eingangs-Parameter
UserName und UserPasswd authentifizieren den Benutzer UserName und UserPasswd werden als normaler Text übertragen. Diese Authentifizierung sollte daher nicht für hohe Sicherheitsanforderungen verwendet werden.
watchdog ist eine Struktur mit der der Client dem Server mitteilt, wenn der nächste Aufruf erwartet werden kann. Dies kann zur zeitlichen Überwachung (timeout) des Client durch den Server verwendet werden.
storeTime bezeichnet den Start der angeforderten oder gesendeten Daten. Diese Methode wird nur bei Zugriffen auf gespeicherte historische Daten verwendet.
end_store bezeichnet das Ende der angeforderten oder gesendeten Daten. Diese Methode wird nur bei Zugriffen auf gespeicherte historische Daten verwendet.
position bezeichnet die Position eines Zeigers im Puffer des Servers. Die Position wird in mit den Methode inquireAll oder getResponse erhalten und für die nächste get Anforderung verwendet (siehe Kapitel 2.3.1, Datenpufferung und Positionsbehandlung).
filterList ist eine Liste der Objekte, welche gelesen werden sollen. Damit kann die Datenmenge begrenzt werden.
Ausgangs-Parameter
LastStart ist der Zeitstempel des letzten Starts des Servers. Falls sich LastStart von einer auf die nächste Antwort des Servers ändert, ist das ein Zeichen, dass die Daten neu synchronisiert werden müssen. Der Client resynchronisiert (resynchronise) deswegen mit der Methode inquireAll.
Errorcode ist ein Fehlercode, der im Falle von fehlerhaften Befehlen erzeugt wird. Im Falle von fehlerhaften XML-Strukturen wird er nicht verwendet. Dazu gibt es die Meldung aus dem SOAP-Protokoll (Fault).
Errortxt ist eine von Menschen lesbare Beschreibung des Errorcode.
position ist die Position des letzten Datenzugriffs. Sie muss für den darauffolgenden Datenzugriff verwendet werden.
Datalist ist eine mit den angeforderten Daten.
OCIT-C_Protokoll_V1.1_R1 Seite 27 von 43
22..55..22 ppuutt
Die Methode put dient zum konfigurieren von Objekten. Sie enthält alle Instanzen der Daten, die konfiguriert werden sollen.
OCIT-C_Protokoll_V1.1_R1 Seite 28 von 43
putResponse ist die Antwort auf put.
Sie enthält alle nicht-konfigurierbaren Daten, üblicherweise keine.
22..55..33 ggeett
Die Methode get dient zum Abfragen von Daten.
Sie hat außer dem Standardparametern
entweder Start- und Endezeit um alle Werte innerhalb dieser Zeitspanne zu erhalten
oder die Positionsnummer der abzufragenden Daten. Normalerweise ist dies die Positionsnummer, die durch letzte Methode inquireAllResponse oder getResponse zurückgebracht wurde.
OCIT-C_Protokoll_V1.1_R1 Seite 31 von 43
22..55..44 iinnqquuiirreeAAllll
Methode zum Abfragen aller Objekte eines Objekttyps mit dem letzten Zustand bzw. dem Inhalt der Objekte. Diese Methode garantiert dem Client, dass in der Antwort alle abgefrag-ten Objekte in der Antwort enthalten sind. Die Methode InquireAll enthält nur die Standard Parameter.
OCIT-C_Protokoll_V1.1_R1 Seite 32 von 43
inquireAllResponse ist die Antwort mit allen angeforderten Inhalten.
OCIT-C_Protokoll_V1.1_R1 Seite 33 von 43
22..55..55 ddeelleettee
Die Methode delete dient zum Löschen von dynamischen Daten (bei denen dies erlaubt ist). Instanzen der zu löschenden Daten müssen in die Filterliste eingetragen werden.
OCIT-C_Protokoll_V1.1_R1 Seite 34 von 43
deleteResponse ist die Antwort auf delete. Sie enthält die Instanzen der Daten, die nicht gelöscht werden konnten.
OCIT-C_Protokoll_V1.1_R1 Seite 35 von 43
22..55..66 ggeettCCoonntteennttIInnffoo
Methode zum Abfragen von Objektinhalten des Servers. Die Methode hat als Parameter nur den Namen des Clients, das Passwort und optional die Zeit für den „Watchdog“.
Die Antwort getContentInfoResponse enthält eine Liste der verfügbaren Objekttypen mit ihren Zugriffsrechten und empfohlenen Update-Zyklen.
OCIT-C_Protokoll_V1.1_R1 Seite 36 von 43
22..55..77 wwaaiitt44GGeett
Methode zum Abfragen von Daten des Servers. Die Methode hat als Parameter die gleichen Parameter wie ein get, ermöglicht jedoch die gleichzeitige Abfrage mehrerer Objekttypen.
OCIT-C_Protokoll_V1.1_R1 Seite 37 von 43
Wait4GetResponse ist die Antwort mit den Änderungen seit der letzten Abfrage.
22..66 DDaatteennssttrruukkttuurreenn
Datenstrukturen, die ins Protokoll eingefügt werden, z. B. die Methoden put, inquireAll-Response usw., werden in eigenen Schemadateien des Protokolls definiert.
OCIT-C_Protokoll_V1.1_R1 Seite 38 von 43
22..77 DDeeffiinniittiioonn EErrrroorrCCooddeess
Folgende errorCodes sind in der protocol.xsd definiert:
errorCode Bedeutung
0 no error
1 access error
2 buffer overflow
10 requested data unavailable
11 requested data cannot be sent
12 requested data cannot be deleted
13 values cannot be set
14 found empty object type
15 object type not found
16 error writing data
17 error creating data
18 error deleting data
19 missing filter for deletions
20 server shortly unavailable
21 missing parameters to execute the method
22 internal error
23 other registered accessing client
30 one file cannot be accessed
31 error opening a file
32 error reading a file
33 internal error, reading the archive
34 internal error, parsing the archive
35 error, parsing the archive
36 error activating
37 error deactivating
38 error reading data
39 object not found
40 invalid time range.
41 time range complete (no error)
42 missing data sets
43 returned time range incomplete
22..88 AAnnwweenndduunnggsseemmppffeehhlluunnggeenn
Dieses Kapitel beschreibt, wie Server und Client in verschiedenen Anwendungsfällen ge-handhabt werden können. Dies sind nur Empfehlungen, von denen projektspezifisch abge-wichen werden kann.
OCIT-C_Protokoll_V1.1_R1 Seite 39 von 43
22..88..11 DDaatteennlliieeffeerruunngg bbeeii mmeehhrreerreenn AAbbnneehhmmeerrnn
In Fällen, bei denen es mehrere Abnehmer von Daten des Servers gibt, die gelegentlich Daten anfordern und keine Echtzeit-Verbindung benötigen, wird die im Folgenden beschrie-bene Architektur empfohlen.
Die Datenquelle enthält das sogenannte SOAPServerInterface, welches Funktionalitäten zur Datenpufferung enthält. Die Datensenke enthält das sogenannte SOAPClientInterface, welches den Zugriff auf den SOAP Server ermöglicht (Methoden inquireAll und get).
Damit erreicht man dass der Client auf den Server nur bei Verlangen zugreift. Darüber hin-aus ist das Protokoll mit geringem Aufwand zu implementieren. Im Falle einer Internetanbin-dung sind die Datenquelle der Server und ein Internet-Dienst der Client.
Data Sink
Data Source Data Sink
SoapServer-
Interface
Data
SoapClient-
Interface
further use of
data
Bild 14: Datenlieferung an mehrere Abnehmer
22..88..22 KKoonnffiigguurraattiioonnss--SScchhnniittttsstteellllee
Falls ein System (als Datenquelle) eine Konfigurations-Schnittstelle an der Datensenke be-nötigt, empfiehlt sich folgende Architektur:
Die Datenquelle ist Client
Die Datensenke ist Server
Eigenschaften:
Datenübertragung nur auf Verlangen
Echtzeit Konfiguration, kein „Polling“ erforderlich
Mehrere Konfigurations-Schnittstellen mit einheitlichem Kommunikations-Interface an einer Datensenke möglich.
OCIT-C_Protokoll_V1.1_R1 Seite 40 von 43
Data Source
SoapClient-
Interface
Data
Data Sink
SoapServer-
Interface
further use of
data
Data Source
SoapClient-
Interface
Data
Bild 15: Mehrere Konfigurations-Schnittstellen
Ein Anwendungsfall dafür sind Subsysteme (als Client), die ihre erfassten Daten sofort wei-tergeben, z.B. Daten über Verkehrsstörungen. Diese Konfiguration soll nur verwendet wer-den um Überlastungssituationen zu vermeiden.
22..88..33 DDaatteenn--UUppddaattee zzwwiisscchheenn zzeennttrraalleenn EEiinnrriicchhttuunnggeenn ((uunniiddiirreekkttiioonnaall))
In diesem Fall wird empfohlen:
Datenquelle ist Server
Datensenke ist Client
OCIT-C_Protokoll_V1.1_R1 Seite 41 von 43
CentralUnit as Data
Source
Central Unit(s) as
Consumer
SoapServer-
Interface
Data
SoapClient-
Interface
further use of
data
Bild 16: Konfiguration bei Datenlieferung an Client
Praktisch ist dies dieselbe Konfiguration wie bei Datenlieferung bei mehreren Abnehmern.
22..88..44 DDaatteenn--UUppddaattee zzwwiisscchheenn zzeennttrraalleenn EEiinnrriicchhttuunnggeenn ((bbiiddiirreekkttiioonnaall))
Falls eine bidirektionale Schnittstelle gefordert wird, kann die die Schnittstelle zweimal aus-geführt werden, weil die zentrale Einrichtung gleichzeitig Client und Server ist.
OCIT-C_Protokoll_V1.1_R1 Seite 42 von 43
CentralUnit 1 CentralUnit2
SoapServer
-Interface
Data
Soap-
Client-
Interface
SoapServer
-Interface
Soap-
Client-
Interface
Data
Bild 17: Konfiguration bei Datenaustausch Server - Server