Lichtsignalanlagen (Strassenverkehr)

Grundlagen

Dieses Cookbook beschreibt ein Protokoll zur Übertragung von Messdaten aus dem innerstädtischen Strassenverkehr. Die Messdaten können an starre Intervalle geknüpft sein (wie Zähldaten) oder auch nicht (wie Meldepunkte des öffentlichen Verkehrs).

Das Protokoll unterstützt nur Daten-Broadcast. Es ist kein Mechanismus zur Auswahl der Messdaten vorgesehen. Es unterstützt ebenso nur Online-Daten und keine Archivabfragen.

Das Protokoll lehnt sich an OCIT-C und an seinen Vorgänger OCIT-I an und kann als «light»-Version dieses Protokolls gesehen werden.

Allen Datenstrukturen liegen Schemata im XSD-Format zu Grunde, die Übertragung der Daten selber geschieht jedoch formatiert nach JSON (JavaScript Object Notation), was aus den XML-Strukturen hergeleitet werden kann, welche nach den XSD-Schemata erzeugbar sind.

Daten-Konzept

Das Datenmodell beinhaltet drei Typen von Daten und ihre Übertragung:

1. Statische Daten, welche die Versorgung der übertragenen Daten beinhalten,
2. Dynamische Daten, welche periodisch (z.B. Zählwerte), bei Ereignissen (z.B. ÖV-Telegramme) oder bei Änderung des Wertes (z.B. Signalgruppen-Zustände) übertragen werden,
3. Metadaten, welche die statischen und dynamischen Daten beschreiben und definieren (z.B. Schemata).

Die beschreibenden Daten, sowohl statische Daten als auch Metadaten, können sich im Lauf der Zeit verändern. Es wird keine Historie vergangener Beschreibungen gehalten, sondern nur die aktuellen Daten. Die Dateien müssen im Inhalt mit Zeitstempeln versehen sein, ab wann sie gültig sind. Das Enddatum einer Gültigkeit ist implizit gegeben, wenn eine weiter Versorgung mit späterem Anfangsdatum der Gültigkeit vorliergt. Neben dem Zeitstempel ist auch ein Versionsstand verfügbar.

Statische Daten

Die statischen Daten (1) werden in einer Dateistruktur gehalten, welche der logischen Adressierung folgt (siehe weiter unten). Die Dateien sind in XML formatiert und entsprechen einem XSD-Schema, das in den Metadaten (3) hinterlegt ist. Das Schema lehnt sich an OCIT-C und OCIT-I an. Die Daten werden über ein REST-Protokoll geschrieben und auch abgefragt. Das Protokoll muss in der Abfrage die gewünschten Versorgungen auf «Area», «Intersection» und «Supply» (Bereich, Knoten und Messwerte) einschränken können, in der Versorgung geschieht die Adressierung über den Inhalt der Datei.

Statische Daten dürfen Redundanzen aufweisen (z.B. in Links die Objektnummer und für bessere Lesbarkeit den Namen des Objekts).

1. Die statischen Daten, auch Versorgungsdaten genannt, beziehen sich immer auf
   Einen Bereich, z.B. eine Stadt oder eine thematische oder geographische Gruppe von Kreuzungen oder Messstellen, oder
2. einen Knoten.

Der Bezug auf eine Gruppe von Knoten ist z.B. bei Fahrzeiten zwischen Knoten nötig. Oder eine solche Gruppe können alle Zählstellen auf einer Autobahn sein.

In den statischen Daten kann auch die MAP-Datei gespeichert werden1. Die MAP-Datei folgt eigenen Regeln (ISO/TS 19091:2019).

Dynamische Daten

Das Format für die dynamischen Daten (2) lehnt sich ebenfalls an OCIT-C oder OCIT-I an. Ihre Strukturen sind ebenfalls über XSD-Schemata definiert mit Anmerkungen, wie in JSON mit Array-Typen zu verfahren ist. Deshalb kann ein XML-Format für ihre Übertragung erzeugt werden. Die eigentliche Übermittlung geschieht jedoch in JSON.

In den dynamischen Daten darf keine redundante Information vorhanden sein insbesondere auf Versorgungsdaten (z.B. Messwert-Namen). Die dynamischen Daten sind auf das absolut Notwendige reduziert, um Übertragungskapazität zu sparen und den Inhalt der Telegramme leichtgewichtig zu halten. Das schlägt sich auch in der Wahl der Namen der Tags und dem Aufbau der Strukturen nieder.

Metadaten

Metadaten (3) sind die Schemadaten. Die Schemadateien können, wie auch die statischen Daten, einen Gültigkeits-Beginn haben. Die Dateien sollen ähnlich den statischen Daten gehalten und abgefragt werden können.

Logische Adressierung

Es gibt drei hierarchische Adress-Ebenen:

1. Bereich,
2. Knoten,
3. Typ und Kanalnummer.

Bereich

Stadt bzw. ein Bereich, welcher mit einer Stadt gleich gesetzt werden kann, wird in OCIT nicht besonders adressiert. Bei Stadt-übergreifenden Systemen wird die «SystemNr» der Knoten-Adressierung dazu verwendet.

Wir erklären die Bereich-ID hier als obligatorisch. Sie muss eindeutig sein, nicht nur innerhalb einer Datenquelle. Sie muss von zentraler Stelle vergeben werden, wenn nicht implizit gegeben, so dass sie weltweit eindeutig ist. Sie ist alphanumerisch. Unicode ist zugelassen.

Ein Bereich wird somit über eine Bereichs-ID als Primärschlüssel adressiert.

Der Name ist nur informativ.

1. Ein Bereich bzw. eine Stadt kann mehrere Namen in verschiedenen Sprachen oder Transkriptionen haben.
2. Einen eindeutigen Namen muss es nicht geben, da Namen von Städten nicht eindeutig sein müssen. Sollte ein Bereich oder eine Stadt mehrere Namen in mehreren Sprachen haben, so können sie mit verschiedenen Sprachkürzeln gemäss ISO 639 bzw. RFC 17663 (vom Typ «de-CH»4) erfasst werden.
3. Gibt es einen Namen in Standard-Sprache (DefaultLanguage), so wird sie dort mit dem Sprachkürzel erfasst, welches dann im Standard-Namen entfällt.

Knoten

• Der Knoten wird üblicherweise über eine eindeutige Nummer innerhalb eines Bereichs angesprochen, der Unit-Nummer. «Knoten» ist der Fachausdruck für «Strassenkreuzung».
• Es gibt Städte mit derselben Knotennummer, die mehrfach vergebenen worden ist. Dort wird die Knotennummer ergänzt durch SystemNr und SubsystemNr.
• Nichts desto trotz muss auch die Kurzbezeichnung eindeutig sein.

Es gibt also innerhalb eines Bereichs

• einen Primärschlüssel aus Unit-Nummer und fakultativer SystemNr und SubsystemNr.

Typ und Kanalnummer

Alle Datenpunkte innerhalb eines Knotens (oder evtl. innerhalb eines Bereichs) werden über ihren Typ (Detektor-Rohdaten, Detektor-Intervallwerte, Signalgruppen) und ihre Kanalnummer angesprochen (z.B. Detektor mit der Kanalnummer 2 – «D.2» oder Signalgruppe mit der Kanalnummer 3 – «S.3»).

Gleichzeitig kann dem Datenpunkt ein Name zugewiesen werden, welcher innerhalb des Knotens eindeutig sein sollte («DR11.21»). In Ausnahmefällen ist er nur innerhalb des Datentyps eindeutig. Zur Vermeidung von Missverständnissen wird üblicherweise sowohl der Adressierung als auch dem Namen die Unit-Nummer des Knotens vorangestellt: «184.D.2» (Kurzform der Adressierung) und «184.DR11.21» (Name).

1. Adressierung mehrerer Messwerte desselben Typs innerhalb des Knotens
   • Üblicherweise werden Messwerte technisch in OCIT via Unit-Nummer, Typ und Kanalnummer adressiert, z.B. «184.D.2».
   • Alternativ kann die Adressierung über Unit-Nummer, Typ und Name gesche-hen, was verkehrstechnisch komfortabel ist: Verkehrsingenieur-Arbeitsplätze verwenden gerne diese Art der Adressierung: 184.DR11.21.
2. Adressierung von Messwerten, die es pro Typ nur 1 Mal gibt
   • Selten geschieht die Adressierung über den Knoten und den Typ alleine, z.B. 184.TX (Umlaufsekunde) oder 184.PrgNr (aktuelle Programmnummer), der Betriebszustand oder die Betriebsart. Hier wird technisch standardmässig die Kanalnummer 1 vergeben
3. Adressierung von Messwerten, die unabhängig vom Knoten sind
   • Ebenfalls selten ist eine bereichsweite Adressierung, z.B. für die Meldepunkte der ÖV-Detektionssysteme nach Bake-Funk-Technologie. In diesem Fall wird ein 2-Byte-Wert als Adresse verwendet, welcher innerhalb des gesamten Bereichs eindeutig ist: 37819.

Messwerte (JSON)

Messwerte sind dynamische Daten. Ihre Struktur ist in den Metadaten festgehalten.

Messwerte können via REST periodisch von den angemeldeten Client in JSON abgeholt werden. Der Datenabnehmer fragt am Anfang einmalig alle aktuellen Daten ab («inquireAll») und holt nachfolgend in frei definierbaren Zeitabständen immer das Datendelta («get») ab. Die Anzahl gleichzeitiger Abnehmer ist systemabhängig.

Snippet

Ein «Snippet» ist eine Zusammenfassung von Messwerten.

• AreaId ist die Adresse des Bereichs.
• SystemNr, SubsystemNr und UnitNr enthalten die Adresse eines. UnitNr ist obligatorisch, SystemNr und SubsystemNr sind fakultativ, dürfen aber in die eindeutige Adressierung des Knotens zusammen mit UnitNr einbezogen werden.
• Timestamp gibt den Zeitpunkt der folgenden Messwerte an.
• Measurements öffnet den Ast für die Messungen.

Im Ast «Measurements» stecken die Messwerte. Die Strukturen sind spezifisch für jeden Typ festgelegt.

Folgende Typen von Messwerten sind in dieser ersten Version C definiert:

• Level of Service (LOS): Qualitätsstufe für Fussgänger, Motorfahrzeuge oder öffentlichen Verkehr (z.B. «A» bis «F»),
  • Der Level of Service (LOS) kann für Fussgänger, Motorfahrzeuge oder für den öffentlichen Verkehr verwendet werden. Der LOS wird mit einem Buchstaben für jeweils eine Kategorie bezeichnet.
    • Zu einem gegebenen Zeitpunkt kann ein Messpunkt den Wert eines Buchstaben an-nehmen, z.B. «B»,
    • oder es kann eine statistische Wertegruppe übermittelt werden, welche Kategorie wie häufig (in Prozent) gemessen worden ist.
  • Die Intervall-Angabe kann in JSON nicht gleich restriktiv dargestellt werden wie in XSD. Wichtig ist, das entweder «FixedInterval», «CycleInterval» oder gar kein Intervall gegeben werden kann. Die Kommentare zu den Tags sind hier nicht noch einmal wiederholt – sie stehen im XSD-Schema.
  • Es gibt zwei Möglichkeiten für den LOS:
    • Entweder wird ein Buchstabe übermittelt «Letter»
    • oder es werden zwei gleich lange Arrays übermittelt mit «Letters» und «Percentages».

 

• SpillbackLength: Rückstaulänge in Metern,
  • Hier wird eine Rückstaulänge in Metern übermittelt. Wie immer kann es ein aktueller Wert sein oder eine periodische Berechnung mit konstanter oder variabler Periodendauer. Pro «Channel» wir eine Länge «Length» übermittelt.
  • Auch hier gibt es die Möglichkeit, entweder ein einzelnes Wertepaar «Channel» und «Length» zu übermitteln oder zwei gleich lange Arrays «Channels» und «Lengths».

 

• GreenPercentage: Prozentualer Anteil von Grün bezüglich der gesamten, zur Verfügung stehenden Zeit,
  • Hier wird der Grünanteil einer Signalgruppe in Prozent der gesamthaft zur Verfügung stehenden Zeit in Prozent übermittelt. Auch hier kann es ein aktueller Wert sein oder eine periodische Berechnung mit konstanter oder variabler Periodendauer. Pro «Channel» wir eine Prozentzahl «Percentage» übermittelt.
  • Auch hier gibt es die Möglichkeit, entweder ein einzelnes Wertepaar «Channel» und «Percentage» zu übermitteln oder zwei gleich lange Arrays «Channels» und «Percentages».

 

• ODCount: Quell-Ziel-Belastungen,
  • Hier werden Zählwerte pro Quelle (Origin) und Ziel (Destination) übermittelt. Es kann ein aktueller Wert sein oder eine periodische Berechnung mit konstanter oder variabler Periodendauer. Pro «Channel» wir ein Zählwert «Count» übermittelt.
  • Auch hier gibt es die Möglichkeit, entweder ein einzelnes Wertepaar «Channel» und «Count» zu übermitteln oder zwei gleich lange Arrays «Channels» und «Counts».

 

• DriveAwayHeadway: Zeitbedarfswert, beim Anfahren ermittelt.
  • Der zeitliche Abstand zwischen zwei Fahrzeugen wird Bruttozeitlücke genannt. Beim Anfahren nach einem Rotlicht spricht zusätzlich man vom Zeitbedarfswert. Das ist die Zeit, welche zwischen zwei aufeinanderfolgenden Fahrzeugen verstreicht. Am Zeitbedarfswert hängt die maximale Kapazität einer Knotenpunktes, und auch die kritischen Zufahrten lassen sich daraus ermitteln.
  • Der Zeitbedarfswert wird hier als Funktion der Position der Fahrzeuge in der anfahrenden Fahrzeugkolonne ermittelt. Die Werte der einzelnen Fahrzeuge können der Reihe nach unter «Duration» aufgezählt werden. Es kann daraus auch ein mittlerer Zeitbedarfswert errechnet werden. Er wird in «MeanDuration» übermittelt, entweder dem Details unter «Duration» vorangestellt oder alleine – als Ereignis oder als Ergebnis einer Berechnung über ein Intervall.

 

Es können Ereignisse oder statistische Daten übermittelt werden.

• Wird in den Messdaten jeweils kein Intervall mitgegeben, dann handelt sich um einen aktuell gemessenen Wert.
• Wird ein «FixedInterval» angegeben, dann handelt es sich um einen statistischen Wert, welcher mit konstanter Periodizität ermittelt wird.
• Wenn ein «CycleInterval» angeben wird, dann handelt es sich um einen statistischen Wert, welcher «pro Umlauf» ermittelt wird, meist am Anfang von Rot. Solche Intervalle haben meistens keine konstante Länge.

Die Messdaten werden

• über den Typ des Messwerts
• und den Channel adressiert

bzw. können darunter in der Versorgung wiedergefunden werden.

Swagger

Weiterführende Informationen zum Thema Snippet sind im JSON-Schema oder direkt im untenstehenden Swagger-Frame zu finden.