Skip to content
LoginRegister
DEENFRIT
Home
Open data platform mobility Switzerland
  2. Cookbook
  3. Traffic lights (road traffic)

Traffic lights (road traffic)

Basics

This cookbook describes a protocol for the transmission of measurement data from urban road traffic. The measurement data can be linked to fixed intervals (such as counting data) or not (such as public transport reporting points).

The protocol only supports data broadcast. There is no mechanism for selecting the 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 based on schemas in XSD format, but the data itself is transferred in JSON (JavaScript Object Notation) format, which can be derived from the XML structures that can be generated according to the XSD schemas.

Data concept

The data model contains three types of data and their transfer:

  1. Static data, which contains the supply of the transmitted data,
  2. Dynamic data that is transmitted periodically (e.g. counter values), on events (e.g. public transport telegrams) or when the value changes (e.g. signal group statuses),
  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 content of the files must be time-stamped with the date from which they are valid. The end date of a validity is implicitly given if a further supply with a later start date of validity is provided. In addition to the time stamp, a version status is also available.

Static data

The static data (1) is stored in a file structure that follows the logical addressing (see below). The files are formatted in XML and correspond to an XSD schema that is stored in the metadata (3). The scheme is based on OCIT-C and OCIT-I. The data is written and also queried via a REST protocol. In the query, the protocol must be able to restrict the desired supplies to “Area”, “Intersection” and “Supply” (area, node and measured values); in the supply, addressing takes place via the content of the file.

Static data may contain redundancies (e.g. the object number in links and the name of the object for better readability).

  1. The 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 measuring points, or
  2. a knot.

The reference to a group of nodes is necessary, for example, for journey times between nodes. Or such a group can be all counting points on a motorway.

The MAP file can also be saved in the static data1. 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. Therefore, an XML format can be generated for their transmission. However, the actual transmission takes place in JSON.

There must be no redundant information in the dynamic data, especially on supply data (e.g. measured value names). The dynamic data is reduced to what is absolutely necessary in order to save transmission capacity and keep the content of the telegrams lightweight. This is also reflected in the choice of tag names and the organisation of the structures.

Metadata

Metadata (3) is the schema data. The schema files, like the static data, can have a validity start date. It should be possible to store and query the files in a similar way to static data.

Logical addressing

There are three hierarchical address levels:

  1. Area,
  2. Nodal point,
  3. Type and channel number.

Range

City or an area that can be equated with a city is not specifically addressed in OCIT. For cross-city systems, the “SystemNr” of the node addressing is used for this purpose.

We declare the area ID to be mandatory here. It must be unique, not just within one data source. It must be assigned from a central location, if not implicitly given, so that it is unique worldwide. It is alphanumeric. Unicode is authorised.

An area is therefore addressed using an area ID as the primary key.

The name is only informative.

  1. An area or city can have several 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 several languages, they can be recorded with different language abbreviations in accordance with ISO 639 or RFC 17663 (of type “de-CH “4).
  3. If there is a name in the default language (DefaultLanguage), it is entered there with the language abbreviation, which is then omitted in the default name.

Nodal point

  • The node is usually addressed via a unique number within an area, the unit number. “Node” is the technical term for “road junction”.
  • There are cities with the same node number that has been assigned several times. The node number is supplemented there by SystemNr and SubsystemNr.
  • Nevertheless, the abbreviation must also be clear.

There are therefore within an area

  • a primary key consisting of unit number and optional SystemNr and SubsystemNr.

Type and channel number

All data points within a node (or possibly within an area) are addressed via their type (detector raw data, detector 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 only unique 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 measured values of the same type within the node
    • Measured values are usually addressed technically in OCIT via unit number, type and channel number, e.g. “184.D.2”.
    • Alternatively, addressing can be done via unit number, type and name, which is convenient in terms of traffic engineering: traffic engineer workstations like to use this type of addressing: 184.DR11.21.
  2. Addressing of measured values that only exist once per type
    • Addressing is rarely done via the node and the type alone, e.g. 184.TX (circulation second) or 184.PrgNr (current programme number), the operating status or the operating mode. Channel number 1 is technically assigned here by default
  3. Addressing of measured values that are independent of the node
    • Area-wide addressing is also rare, e.g. for the signalling points of public transport detection systems using beacon radio technology. In this case, a 2-byte value is used as the address, which is unique within the entire range: 37819.

Measured values (JSON)

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

Measured values can be retrieved periodically from the registered client in JSON via REST. The data collector queries all current data once at the beginning (“inquireAll”) and then always retrieves the data delta (“get”) at freely definable intervals. The number of simultaneous recipients depends on the system.

Snippet

A “snippet” is a summary of measured values.

  • AreaId is the address of the area.
  • SystemNr, SubsystemNr and UnitNr contain the address of a. UnitNr is mandatory, SystemNr and SubsystemNr are optional, but may be included in the unique addressing of the node together with UnitNr.
  • Timestamp indicates the time of the following measured values.
  • Measurements opens the branch for the measurements.

The “Measurements” branch contains the measured values. 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” to “F”),
    • The level of service (LOS) can be used for pedestrians, motor vehicles or public transport. The LOS is labelled with a letter for each category.
      • At a given point in time, a measuring point can take on the value of a letter, e.g. “B”,
      • or a statistical value group can be transmitted, which category has been measured how often (in per cent).
    • The interval specification cannot be represented as restrictively in JSON as in XSD. It is important that either “FixedInterval”, “CycleInterval” or no interval at all can be specified. The comments on the tags are not repeated here – they are in the XSD schema.
    • There are two options for the LOS:
      • Either a letter is transmitted “Letter”
      • or two arrays of equal length are transmitted with “Letters” and “Percentages”.

 

  • SpillbackLength: Spillback length in metres,
    • A backlog length in metres is transmitted here. As always, it can be a current value or a periodic calculation with a constant or variable period duration. A “Length” is transmitted for each “Channel”.
    • Here, too, there is the option of transmitting either a single “Channel” and “Length” value pair or two “Channels” and “Lengths” arrays of equal length.

 

  • GreenPercentage: Percentage of green in relation to the total time available,
    • Here, the green component of a signal group is transmitted as a percentage of the total time available. Here too, it can be a current value or a periodic calculation with a constant or variable period duration. A percentage figure “Percentage” is transmitted for each “Channel”.
    • Here, too, there is the option of transmitting either a single pair of values “Channel” and “Percentage” or two equally long arrays “Channels” and “Percentages”.

 

  • ODCount: Source-target loads,
    • Here, counter values are transmitted for each source (origin) and destination. It can be a current value or a periodic calculation with a constant or variable period duration. One “Count” value is transmitted per “Channel”.
    • Here, too, there is the option of transmitting either a single “Channel” and “Count” value pair or two “Channels” and “Counts” arrays of equal length.

 

  • DriveAwayHeadway: Time requirement value, determined when driving off.
    • The time gap between two vehicles is called the gross time gap. When moving off after a red light, the time requirement value is also used. This is the time that elapses between two consecutive vehicles. The maximum capacity of a junction depends on the time requirement value, and the critical access routes can also be determined from this.
    • The time requirement 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 listed in sequence under “Duration”. An average time requirement value can also be calculated from this. It is transmitted in “MeanDuration”, either preceding the details under “Duration” or on its own – as an event or as the result of a calculation over an interval.

 

Events or statistical data can be transmitted.

  • If no interval is specified in the measurement data, then this is a currently measured value.
  • If a “FixedInterval” is specified, this is a statistical value that is determined with a constant periodicity.
  • If a “CycleInterval” is specified, this is a statistical value that is determined “per cycle”, usually at the beginning of red. Such intervals usually do not have a constant length.

The measurement data is

  • via the type of measured value
  • and addresses the channel

or can be found underneath in the supply.

Swagger

Further information on the topic of snippets can be found in the JSON schema or directly in the swagger frame below.