Table of contents

Search on the page

Traffic lights (road traffic)

#AutoTranslate

Brief Description

This Cookbook describes a protocol for transmitting measurement data from inner-city road traffic. The measurement data can be linked to rigid intervals (such as count data) or not (such as public transport reporting points).

Functional Description

The protocol only supports data broadcast. There is no mechanism for selecting measurement data. It also only supports online data and no archive queries.

The protocol is based on OCIT-C and its predecessor, OCIT-I, and can be seen as a ‘light’ version of this protocol.

All data structures are Schemas in XSD format basically, however, the data itself is transmitted formatted in JSON (JavaScript Object Notation), which can be deduced from the XML structures that can be created according to the XSD schemas.

Data concept

The data model includes three types of data and their transmission:

  1. Static data, which include the provision of the transmitted data,
  2. Dynamic data, which are transmitted periodically (e.g. count values), in the event of events (e.g. public transport telegrams) or when the value changes (e.g. signal group states),
  3. Metadata that describes and defines the static and dynamic data (e.g. schemas).

The descriptive data, both static data and metadata, can change over time. No history of past descriptions is kept, only the current data. The contents of the files must be time stamped indicating when they are valid. The end date of a validity is implicit if there is another provision with a later start date of the validity. In addition to the time stamp, a version status is also available.

Static data

The static data (1) is kept in a file structure following logical addressing (see below). The files are formatted in XML and correspond to an XSD schema stored in the metadata (3). The schema is based on OCIT-C and OCIT-I. The data is written via a REST protocol and also queried. The protocol must be able to restrict the desired supplies in the query to ‘Area,’ ‘Intersection’ and ‘Supply’; the supplies are addressed via the content of the file.

Static data may have redundancies (e.g. the object number and, for easier readability, the name of the object). Static data, also known as supply data:

  • Always refer to an area, e.g. a city or a thematic or geographical group of intersections or measurement points.
  • Or a knot.

The reference to a group of nodes is required, for example, for travel times between nodes. Alternatively, such a group can be all counting points on a motorway.

The MAP file can also be saved in the static data. The MAP file follows its own rules (ISO/TS 19091:2019).

Dynamic data

The format for the dynamic data (2) is also based on OCIT-C or OCIT-I. Their structures are also defined via XSD schemas with notes on how to proceed with array types in JSON. An XML format can therefore be created for transferring them. However, the actual transfer takes place in JSON.

No redundant information may be present in the dynamic data, in particular on service data (e.g. measurement value names). The dynamic data is reduced to what is absolutely necessary in order to save transmission capacity and to keep the content of the telegrams light. This is reflected in the naming of the tags and the structure of the modelling.

Metadata

Metadata (3) is schema data. Like the static data, the schema files can have a validity start date. It should be possible to hold and retrieve the files in a similar way to the static data.

Technical Description

Logical addressing

There are three hierarchical address levels:

  1. Unit
  2. Nodal point
  3. Type and channel number

Unit

A city or an area that can be defined as a city is not specifically addressed in OCIT. In the case of city-spanning systems, the «SystemNr» of node addressing.

We explain the «AreaID» here as mandatory. It must be unique, not just within one data source. If it is not automatically assigned uniquely, it must be uniquely assigned worldwide by a central authority. All alphanumeric characters in Unicode are allowed.

An area is thus covered by a «AreaID» as a primary key.

The following applies to the informative name:

  1. An area or city can have multiple names in different languages or transcriptions.
  2. There does not have to be a unique name, as city names do not have to be unique. If an area or city has several names in more than one language, they can be recorded with different language abbreviations according to ISO 639 or RFC 17663 (of the type ‘de-CH’4).
  3. If there is only one name in the standard language, this is recorded there with a language abbreviation, which is then omitted in the standard name.

Nodal point

  • The node is usually addressed by a unique number within a range that «UnitID». Knot is the technical term for road crossings.
  • There are cities in which the same node number has been assigned several times. In these cities, the node number is supplemented by «UnitID» and «Provider».
  • Nevertheless, the abbreviation must also be unambiguous.

So, within a range, there are

  • a primary key comprising: «UnitID» and optional «UnitID» and «Provider».

Type and channel number

All data points within a node (or possibly within a range) are addressed by their type (sensor raw data, light signal interval values, signal groups) and their channel number (e.g. detector with channel number 2 – ‘D.2’ or signal group with channel number 3 – ‘S.3’).

At the same time, a name can be assigned to the data point, which should be unique within the node (‘DR11.21’). In exceptional cases, it is unique only within the data type. To avoid misunderstandings, both the addressing and the name are usually preceded by the unit number of the node: ‘184.D.2’ (short form of addressing) and ‘184.DR11.21’ (name).

  1. Addressing several measurement values of the same type within the node:
    • Normally, measured values are technically entered in OCIT via «UnitID», type and channel number, e.g. ‘184.D.2’.
    • Alternatively, addressing can be carried out via «UnitID», type and name happen, which is convenient from a traffic point of view: Traffic engineer workstations like to use this type of addressing: 184.DR11.21.
  2. Addressing of measured values that only exist once per type:
    • Rarely, addressing takes place via the node and the type alone, e.g. 184.TX (rotating second) or 184.PrgNr (current program number), the operating state or the operating mode. In this case, the channel number 1 is assigned by default.
  3. Addressing of measurement values that are independent of the node:
    • Area-wide addressing, e.g. for the reporting points of the public transport detection systems of a radio beacon (Radio beacon). In this case, a 2-byte value is used as the address, which is unique throughout the range. E.g.: 37819.

Measured values

Measured values are dynamic data. Their structure is recorded in the metadata.

Measured values can be periodically retrieved from the logged-in client in JSON via REST. At the beginning, the data recipient requests all current data once «inquireAll» and then always fetches the data delta with GET at freely definable time intervals.

Snippet

One «Snippet» is a summary of the readings:

  • «AreaID» is the address of the range.
  • «UnitID», «Provider» and «UnitID» contain the address of a node. «UnitID» is mandatory, «UnitID» and «Provider» are optional, but may be included in the unique addressing of the node together with «UnitID» be included.
  • A timestamp indicates the time of the following measurements.
  • Measurements opens the branch for the measurements.

In the branch «Snippets» the measured values are stored. The structures are defined specifically for each type.

The following types of measured values are defined in this first version C:

  • Level of Service (LOS): Quality level for pedestrians, motor vehicles or public transport (e.g. «A» by «F»):
    • The Level of Service can be used for pedestrians, motor vehicles or for public transport. The LOS is identified by a letter for each category:
      • At a given point in time, a measurement point can assume the value of a letter, e.g. «B»,
      • or a statistical group of values can be transmitted, indicating the measurement frequency in percent per category.
    • The interval specification can be given in XSD more restrictive than in JSON. It is important that either «FixedInterval», «CycleInterval» or no interval is specified. The comments on the tags are not repeated here – they are in the XSD schema.
    • There are two options for LOS:
      • Either a letter such as «Letter»
      • or there will be two of the same length Arrays transmitted with «Letters» and «Percentages».
  • SpillbackLength, Backflow length in metres:
    • Here, a backflow length in metres is transmitted. As always, it can be a current value or a periodic calculation with a constant or variable period duration. Per «Channel» becomes a length «Length» transmitted.
    • Here, too, it is possible to choose either a single pair of values «Channel» and «Length» or two of the same length Arrays «Channels» and «Lengths».
  • GreenPercentage, percentage of green in relation to the total time available:
    • Here, the green portion of a signal group is transmitted as a percentage of the total available time. Here, too, it can be a current value or a periodic calculation with a constant or variable period duration. Per «Channel» a percentage is transmitted.
    • Here, too, it is possible to choose either a single pair of values «Channel» and «Percentage» or two of the same length Arrays «Channels» and «Percentages».
  • ODCount, Source-target loads:
    • Count values per source are displayed here (Origin) and objective (Destination) It can be a current value or a recurring calculation with a constant or variable period duration. Per «Channel» we have a count value «Count» transmitted.
    • Here, too, it is possible to choose either a single pair of values «Channel» and «Count» or two of the same length Arrays «Channels» and «Counts».
  • DriveAwayHeadway, Time requirement value, determined during start-up:
    • The time gap between two vehicles is called the gross time gap. When starting after a red light, this is also referred to as the time required value. This is the time that elapses between two consecutive vehicles. The maximum capacity of a node depends on the time required value, and critical approaches can also be determined from this value.
    • The time required value is determined here as a function of the position of the vehicles in the approaching vehicle convoy. The values of the individual vehicles can be determined in sequence under «Duration» It is also possible to calculate an average time requirement value from this. A «MeanDuration» either the details under «Duration» preceding or alone, as an event or as the result of a calculation over an interval.

Events or statistical data can be transmitted:

  • If no interval is included in the measurement data, then it is a currently measured value.
  • Will be a «FixedInterval» then it is a statistical value which is determined with constant periodicity.
  • If a «CycleInterval» in which case it is a statistical value that is determined for each rotation, usually at the start of red. Such intervals usually do not have a constant length.

The measured data are determined by the type of the measured value and the Channel or can be addressed below in the «Supply» can be found again.

Further information

Further information on the topic «Snippet» are located in OpenAPI schema.

The Traffic-Lights Interface can be tested directly in our OpenAPI: OpenAPI traffic lights