iVRI Interface TLC-FI, IDD TLC-FI
Datum besluit SC 08-11-2022
D3047-6 / Version 2.0.1
D3047-6 / Version 2.0.1
Disclaimer (NL):
Bij het gebruik en toepassen van de Landelijke iVRI standaarden® is en blijft de gebruiker, te weten de wegbeheerder respectievelijk opdrachtnemer van de wegbeheerder, zelf aansprakelijk voor de mogelijke risico’s die ontstaan of kunnen ontstaan uit het aanbieden of laten aanbieden van (combinaties van) diensten en producten die conform deze standaarden werken in de eigen organisatie of elders in de keten waarvoor de wegbeheerder verantwoordelijk is. Dit geldt in het bijzonder ten aanzien van het verzamelen, opslaan en delen van gegevens en meer specifiek indien daar waar al dan niet direct of indirect herleidbare persoonsgegevens worden verwerkt op grond van de AVG. Gebruikers zijn zelf verantwoordelijk om bij het gebruik van de standaarden telkens na te gaan of gebruik van standaarden, dan wel de combinatie van data vanuit de standaarden in de basis voldoet aan de wet- en regelgeving, in het bijzonder de AVG. Het gebruik conform de standaarden kan het risico op aansprakelijkheid van de wegbeheerder verkleinen, maar niet altijd wegnemen of geheel uitsluiten. Dit is mede afhankelijk van de wijze waarop de wegbeheerder zelf in haar eigen organisatie of bij gebruik van opdrachtnemers in de keten de data verwerkt en gebruikt. Het is dan ook een dringend advies zowel voorafgaand aan de implementatie en ingebruikname door de gebruiker van de standaarden als periodiek een risico-analyse (zoals Data Protection Impact Assessment (DPIA)) en controle van de keten op het gebruik van de standaarden en bijkomende individuele risico’s bij de wegbeheerder en haar opdrachtnemers uit te laten voeren. Het doel van dergelijke analyses en controles is dat mogelijke risico’s die onbedoeld kunnen optreden op voorhand geïdentificeerd kunnen worden, zodat de wegbeheerder zelf de nodige beheersmaatregelen kan treffen om (alsnog) aan de wettelijke voorschriften te kunnen voldoen. CROW en de opstellers van de standaarden hebben deze documenten met de grootst mogelijke zorg en met aandacht opgesteld, maar kunnen geen aansprakelijkheid aanvaarden voor een mogelijke overtreding van wet- en regelgeving door de wegbeheerder respectievelijk opdrachtnemer van de wegbeheerder, door te verwijzen naar de standaarden als oorzaak van een mogelijke overtreding van de AVG of andere wettelijke voorschriften. CROW en de opstellers van de standaarden wijzen derhalve een aansprakelijkheid door gebruikers ten aanzien van het gebruik van de standaarden Landelijke iVRI standaarden® van de hand.
Bij het gebruik en toepassen van de Landelijke iVRI standaarden® is en blijft de gebruiker, te weten de wegbeheerder respectievelijk opdrachtnemer van de wegbeheerder, zelf aansprakelijk voor de mogelijke risico’s die ontstaan of kunnen ontstaan uit het aanbieden of laten aanbieden van (combinaties van) diensten en producten die conform deze standaarden werken in de eigen organisatie of elders in de keten waarvoor de wegbeheerder verantwoordelijk is. Dit geldt in het bijzonder ten aanzien van het verzamelen, opslaan en delen van gegevens en meer specifiek indien daar waar al dan niet direct of indirect herleidbare persoonsgegevens worden verwerkt op grond van de AVG. Gebruikers zijn zelf verantwoordelijk om bij het gebruik van de standaarden telkens na te gaan of gebruik van standaarden, dan wel de combinatie van data vanuit de standaarden in de basis voldoet aan de wet- en regelgeving, in het bijzonder de AVG. Het gebruik conform de standaarden kan het risico op aansprakelijkheid van de wegbeheerder verkleinen, maar niet altijd wegnemen of geheel uitsluiten. Dit is mede afhankelijk van de wijze waarop de wegbeheerder zelf in haar eigen organisatie of bij gebruik van opdrachtnemers in de keten de data verwerkt en gebruikt. Het is dan ook een dringend advies zowel voorafgaand aan de implementatie en ingebruikname door de gebruiker van de standaarden als periodiek een risico-analyse (zoals Data Protection Impact Assessment (DPIA)) en controle van de keten op het gebruik van de standaarden en bijkomende individuele risico’s bij de wegbeheerder en haar opdrachtnemers uit te laten voeren. Het doel van dergelijke analyses en controles is dat mogelijke risico’s die onbedoeld kunnen optreden op voorhand geïdentificeerd kunnen worden, zodat de wegbeheerder zelf de nodige beheersmaatregelen kan treffen om (alsnog) aan de wettelijke voorschriften te kunnen voldoen. CROW en de opstellers van de standaarden hebben deze documenten met de grootst mogelijke zorg en met aandacht opgesteld, maar kunnen geen aansprakelijkheid aanvaarden voor een mogelijke overtreding van wet- en regelgeving door de wegbeheerder respectievelijk opdrachtnemer van de wegbeheerder, door te verwijzen naar de standaarden als oorzaak van een mogelijke overtreding van de AVG of andere wettelijke voorschriften. CROW en de opstellers van de standaarden wijzen derhalve een aansprakelijkheid door gebruikers ten aanzien van het gebruik van de standaarden Landelijke iVRI standaarden® van de hand.
Disclaimer (EN):
When using and applying the Landelijke iVRI standaarden® the end user, being the road authority or its principal, remains solely responsible for the possible risks that emerge or can emerge from the provision of services and products that operate by these standards, either within the own organisation or elsewhere in the chain of the road authority’s responsibility. This especially applies to the activities where data is gathered, stored and shared, and more specifically in cases where, be it directly or by inference, private data of individuals are processed, based on the GDPR and/or its national implementation. The user of these standards are themselves responsible for ascertaining that either the use of these standards, or the combination of data that is processed from applying these standards, are legal, especially in terms of the GDPR and/or its national implementation. The use of these standards can reduce the risks for liability of road users, but they can not eliminate these risks; the beforementioned risks of violating privacy legislation are mainly dependent on the way in wicht the road authority uses and processes the data within the own organisation and in relation to contractors within the chain of responsibility. It is urgently advised that, not alone when preparing a project, but also when implementing and operating a service or product, the road authority performs a periodic risk analysis (like a Data Protection Impact Assessment (DPIA)) and a check on the whole chain of information in terms of compliance to standards and additional individual risks on behalf of the road authority and its contractors. The purpose of these analyses and checks is to identify the possible risks beforehand, in order to take preventive and controlling measures, so that the road authority (eventually) is compliant to the legal framework that is applicable. CROW and the authors of these standards have created this document with the utmost care, but will not accept liability for a possible violation of any legislation by the road authority or its contractors by referring to these standards as the root cause of a possible violation of the GDPR, its national implementation or any other legal prescription. CROW and the authors of the Landelijke iVRI standaarden® therefore explicitly waive all responsibility for the use of these standards.
When using and applying the Landelijke iVRI standaarden® the end user, being the road authority or its principal, remains solely responsible for the possible risks that emerge or can emerge from the provision of services and products that operate by these standards, either within the own organisation or elsewhere in the chain of the road authority’s responsibility. This especially applies to the activities where data is gathered, stored and shared, and more specifically in cases where, be it directly or by inference, private data of individuals are processed, based on the GDPR and/or its national implementation. The user of these standards are themselves responsible for ascertaining that either the use of these standards, or the combination of data that is processed from applying these standards, are legal, especially in terms of the GDPR and/or its national implementation. The use of these standards can reduce the risks for liability of road users, but they can not eliminate these risks; the beforementioned risks of violating privacy legislation are mainly dependent on the way in wicht the road authority uses and processes the data within the own organisation and in relation to contractors within the chain of responsibility. It is urgently advised that, not alone when preparing a project, but also when implementing and operating a service or product, the road authority performs a periodic risk analysis (like a Data Protection Impact Assessment (DPIA)) and a check on the whole chain of information in terms of compliance to standards and additional individual risks on behalf of the road authority and its contractors. The purpose of these analyses and checks is to identify the possible risks beforehand, in order to take preventive and controlling measures, so that the road authority (eventually) is compliant to the legal framework that is applicable. CROW and the authors of these standards have created this document with the utmost care, but will not accept liability for a possible violation of any legislation by the road authority or its contractors by referring to these standards as the root cause of a possible violation of the GDPR, its national implementation or any other legal prescription. CROW and the authors of the Landelijke iVRI standaarden® therefore explicitly waive all responsibility for the use of these standards.
Voorwoord
Met de landelijke publiek private standaarden voor iVRI’s uit 2016 is de afgelopen jaren veel ervaring opgedaan. Enkele van deze standaarden waren al op onderdelen aangescherpt. Eind 2020 is besloten tot een integrale zogenaamde consolidatieslag op al deze standaarden. Met als doel om o.b.v. de opgedane ervaringen en inzichten de ontwikkeling, configuratie, werking en het beheer van (diensten in) de gehele dataketen eenvoudiger en betrouwbaarder te maken. Dit betreft niet alleen standaarden voor iVRI’s, maar ook landelijke afspraken en standaarden over data die cloud service providers aanleveren aan en afnemen van iVRI’s.
Grotere aanpassingen, zoals iVRI security, herziening van beheerinterfaces, ketenbeheer en functionele doorontwikkelingen van diensten (use cases), zijn buiten deze consolidatieslag gehouden en zullen nadien stapsgewijs moeten worden opgepakt. In die zin zal doorontwikkeling van (diensten in) de dataketen doorgaan.
Het voorliggende CROW document is vastgesteld door de landelijke publiek private Strategic Committee en omvat een van de landelijke publiek private iVRI CROW standaarden die is geactualiseerd als onderdeel van de Consolidatie. Aan de actualisatie hebben deskundigen van bedrijven, zowel leveranciers van hardware en software voor iVRI’s als cloud service providers, en overheden actieve bijdragen geleverd. Zoals altijd het geval is bij landelijke standaardisatie, was het niet mogelijk om met de resulterende specificaties en standaarden volledig recht te doen aan alle soms uiteenlopende visies, meningen en standpunten. Door het gevolgde landelijke publieke private proces via de Change Advisory Board en de Strategic Committee zijn al deze visies, meningen en standpunten wel gehoord en gewogen.
De volgende bedrijven hebben actieve bijdragen geleverd aan de iVRI CROW standaarden (in alfabetische volgorde):
- Be-Mobile
- Dynniq
- KPN
- Monotch
- RHDHV
- Siemens Nederland
- Siemens België
- Swarco
- Sweco
- Van Grinsven software
- Vialis
Vanuit alle landsdelen hebben overheden actieve bijdragen geleverd aan de landelijke iVRI CROW standaarden, te weten de landsdelen Noord, Noordwest, Oost, Zuid en Zuidwest. Daarnaast hebben het Vlaamse Agentschap Wegen en Verkeer, het ministerie van Infrastructuur en Milieu en Rijkswaterstaat actieve bijdragen geleverd.
Dank gaat uit naar allen voor deze bijdragen.
Verdere gewenste aanpassingen en doorontwikkeling van de nu voorliggende standaarden zal plaatsvinden via het daartoe ingerichte landelijke proces via Change Advisory Board en Strategic Committee.NB. De rest van dit document is geschreven in het Engels om internationale uitwisseling te ondersteunen.
The rest of this deliverable has been written in English to facilitate international exchange. Publication level: Public
Contents
1 – Introduction
1.1 – Overview
1.2 – Version
1.3 – Purpose and scope
1.4 – Advise for the reader
1.5 – Document conventions
1.1 – Overview
1.2 – Version
1.3 – Purpose and scope
1.4 – Advise for the reader
1.5 – Document conventions
2 – References
3 – Acronyms, abbreviations and concepts
4 – Functional description
4.1 – Overview
4.2 – Intersections
4.2.1 – Multiple intersections
4.2.2 – States
4.2.3 – Facilities responsibilities
4.3 – Signal groups
4.3.1 – States
4.3.2 – SPaT
4.3.3 – Clearance timing
4.3.4 – Predictions
4.3.5 – Application responsibilities
4.3.6 – Facilities responsibilities
4.4 – Outputs
4.5 – Inputs
4.6 – Detectors
4.7 – Variables
4.8 – Control Application
4.8.1 – States
4.8.2 – Control State logic
4.8.3 – Application selection
4.8.4 – Application handover
4.8.5 – Backup ITS-CLA
4.9 – Timing
4.10 – Objects
4.11 – Object exchange model
4.11.1 – Object synchronization
4.11.2 – Event Object generation
4.11.3 – Atomic updates
4.11.4 – Time reference
4.11.5 – Calendar time (UTC)
4.1 – Overview
4.2 – Intersections
4.2.1 – Multiple intersections
4.2.2 – States
4.2.3 – Facilities responsibilities
4.3 – Signal groups
4.3.1 – States
4.3.2 – SPaT
4.3.3 – Clearance timing
4.3.4 – Predictions
4.3.5 – Application responsibilities
4.3.6 – Facilities responsibilities
4.4 – Outputs
4.5 – Inputs
4.6 – Detectors
4.7 – Variables
4.8 – Control Application
4.8.1 – States
4.8.2 – Control State logic
4.8.3 – Application selection
4.8.4 – Application handover
4.8.5 – Backup ITS-CLA
4.9 – Timing
4.10 – Objects
4.11 – Object exchange model
4.11.1 – Object synchronization
4.11.2 – Event Object generation
4.11.3 – Atomic updates
4.11.4 – Time reference
4.11.5 – Calendar time (UTC)
5 – Objects
5.1 – Base
5.2 – Application session
5.3 – Detectors
5.4 – Inputs
5.5 – Intersections
5.6 – Outputs
5.7 – Signal groups
5.8 – Special vehicles
5.9 – TLC Facilities
5.10 – Variables
5.1 – Base
5.2 – Application session
5.3 – Detectors
5.4 – Inputs
5.5 – Intersections
5.6 – Outputs
5.7 – Signal groups
5.8 – Special vehicles
5.9 – TLC Facilities
5.10 – Variables
6 – Methods
6.1 – Subscribe
6.2 – UpdateState
6.3 – NotifyEvent
6.4 – ReadMeta
6.1 – Subscribe
6.2 – UpdateState
6.3 – NotifyEvent
6.4 – ReadMeta
7 – Functional use-cases
7.1 – Startup
7.2 – ITS-CLA in-control
7.3 – ITS-CLA handover
7.4 – ITS-CLA goes off-line
7.5 – ITS-CLA requests hand-over
7.6 – Change the intersection state
7.7 – Change the signal group state
7.8 – Control exclusive outputs
7.9 – Control non-exclusive outputs
7.10 – Obtain updates of TLC State Objects
7.11 – Update TLC State Objects by an ITS-A
7.12 – Update the signal group predictions
7.13 – Update the state of a variable
7.1 – Startup
7.2 – ITS-CLA in-control
7.3 – ITS-CLA handover
7.4 – ITS-CLA goes off-line
7.5 – ITS-CLA requests hand-over
7.6 – Change the intersection state
7.7 – Change the signal group state
7.8 – Control exclusive outputs
7.9 – Control non-exclusive outputs
7.10 – Obtain updates of TLC State Objects
7.11 – Update TLC State Objects by an ITS-A
7.12 – Update the signal group predictions
7.13 – Update the state of a variable
8 – Exception handling
8.1 – Network
8.2 – Session
8.3 – Timing
8.4 – Intersection control
8.1 – Network
8.2 – Session
8.3 – Timing
8.4 – Intersection control
9 – IRS Requirements tracing
10 – VECOM TLC-FI SpecialVehicleEvent transpation
1 Introduction
1.1 Overview
The iTLC architecture defines several interfaces of the iTLC. One of these interfaces is the so called: TLC-FI, Traffic Light Controller Facilities Interface. In Figure 1 the position of the TLC-FI is shown within this architecture. Interfaces and functional elements that are not in scope of this document are faded.
[ link ]
Figure 1 TLC-FI in System overview
The TLC-FI is to be considered as a robust interface between (external) ITS
Applications (ITS-A s) and the TLC. The TLC provides information through the TLC-FI and guarantees a safe operation of the traffic lights. It controls the signal groups and, if applicable, additional outputs based on requests from the TLC-FI.
The functional description of the information and services offered by the TLC Facilities by the TLC-FI and the accompanying interface requirements of TLC-FI are described in [REF060].
The TLC- and RIS-FI share common technical requirements and as ITS-A s will communicate with both, it is chosen to design the interfaces on common technological base, such as transport protocols and security as well as on a common information transaction model.
This technological base is defined in [REF061] and is assumed in this document. This document is as such technology agnostic, assuming the following key principles:
- Physical, network and transport layers including security aspects is handled by the underlying mechanisms.
- A mechanism is used, with which TLC Objects describing a state are synchronized between an ITS-A and TLC Facilities
- A mechanism is used with which it is possible to exchange momentary events
This document focuses on functional behaviour based on the exchange of TLC Objects between ITS-A s and TLC Facilities, the definition of TLC Objects and relations between these.
1.2 Version
This document describes the protocol version 2.0.1 of the TLC-FI.
This version assumes the implementation of the Generic Facilities Interface IDD defined in [REF061].
1.3 Purpose and scope
This document describes the interface design of the TLC-FI with respect to
- Functional behaviour
- TLC Object definitions and relations
Technology used to encapsulate, transport and secure the data is not in-scope of this document. For this information please refer to [REF061]
1.4 Advise for the reader
It is advised that the reader understands the iTLC Architecture as described in [REF060].
Furthermore, the underlying mechanisms described in [REF061] should be understood to have a complete view of the functional and technical behaviour of this interface.
1.5 Document conventions
In this document, the objects and methods are transport and encoding agnostic. To identify an Object and its attributes, the following format is used:
<Object type name>. <attribute name>
For instance for the TLC Object type Intersection, which has an attribute reqState, this is identified as Intersection.reqState
This document contains decision tables to describe logic, these tables are typically formatted as follows:
| CONDITIONS | condition 1 | N | Y | Y |
| condition 2 | - | Y | Y | |
| condition 3 | - | N | Y | |
| ACTIONS | ERROR: failure 1 encountered | √ | ||
| ERROR: failure 2 encountered | √ | |||
| Execute action | √ |
Several CONDITIONS are used to indicate which conditions must be valid for any number of ACTIONS.
Boolean CONDITIONS are used.
Y = Yes, the condition is valid
N = No, the condition is not valid
- = Conditions doesn t matter for the actions
N = No, the condition is not valid
- = Conditions doesn t matter for the actions
The ACTIONS taken are indicated with a checkmark ( )
2 References
A complete list of references for the iTLC standards, specifications and profiles is published in D30xx: References for the iTLC standards.
3 Acronyms, abbreviations and concepts
Acronyms and abbreviations
| C-ITS | Cooperative ITS functionality for exchange of data between in-vehicle and/or road side devices making use of either cellular or short range wireless communication |
| IDD | Interface Design Description |
| IRS | Interface Requirements Specification |
| iTLC | Intelligent TLC performing traffic light controller functions and allowing for ITS Applications |
| ITS | Intelligent Transport Systems |
| ITS Station | Functional entity specified by the ITS station reference architecture (see [REF060]) |
| ITS-A | ITS Application |
| ITS-CLA | ITS Control Application |
| ITS-CRA | ITS Consumer Application |
| ITS-PRA | ITS Provider Application |
| IVERA | Management protocol for traffic light controllers in the Netherlands (An implementation of a TMS-IF) |
| iVRI | See iTLC |
| TLC | Traffic Light Controller; controls signals of one or more intersections |
| TMS | Traffic Management System |
| TMS-IF | TMS InterFace, an interface used by a TMS to manage an ITS Application |
| UTC | Coordinated Universal Time |
Concepts
| Traffic Control Application | Application which implements a traffic control algorithm and is able to request signal group states |
| ITS Control Application | A Traffic Control Application which uses TLC- and/or RIS-Facilities Interfaces |
| ITS Application | An application which supports one or more ITS use-cases. Range of possible ITS Applications include an ITS Control Application |
| TLC Facilities | Component providing facilities of a TLC to users (internal and/or external). Includes amongst others:
|
| Permissive Mode | A mode of traffic control signal operation in which, when a CIRCULAR GREEN signal indication is displayed, left and/or right turns are permitted to be made after yielding to pedestrians and/or oncoming traffic. |
| Protected Mode | A mode of traffic control signal operation in which left or right turns are permitted to be made when a left or right GREEN ARROW signal indication is displayed. |
4 Functional description
The TLC-FI is an interface to a TLC used to exchange information about a signalized intersection as well as to control signal groups and other traffic signals part of this intersection. This chapter contains a functional description of the TLC-FI in this context.
4.1 Overview
Viewing the TLC as a black box, the following figure shows the main entities interacting with it relevant for the TLC-FI. The arrows indicate the main interaction directions for the external entities.
[ link ]
Figure 2 TLC context
A Traffic Management System can manage a Traffic Light Controller using the TLC management interface (e.g. IVERA-TLC). The management for example includes the configuration of ITS applications allowed to interact with the TLC.
The TLC receives signals from detectors such as loops, push buttons, radar and video detectors. The TLC receives information about approaching special vehicles such as public transport and emergency vehicles. Based on this received information, the TLC can together with the ITS-CLA s activate traffic signals such as signal groups and warning signals used to regulate the traffic on an intersection.
4.2 Intersections
4.2.1 Multiple intersections
A TLC can control multiple intersections, each intersection consists of signal groups, warning signals, detectors etc. Each intersection in a TLC is controlled through the TLC-FI, one ITS-CLA controls one intersection. This is visualized in Figure 3.
[ link ]
Figure 3 Multiple intersections
4.2.2 States
The traffic signals in the states, transition states and timing is dictated by state or region regulation. For the Netherlands, this is defined in the NEN3384 ([REF040]).
The general states of an intersection are listed in the following table:
| State | NEN3384 | Description |
| Dark | Off | All signals are off. |
| Standby | Standby | Selected signals on the intersection are flashing (e.g. amber flashing) |
| SwitchOn | Start up | Intersection is switching on. Usually a transition state for a limited time and regulation impose signal group states and timing. |
| Control | Normal | Intersection is in operation. The traffic signalling is controlled by a traffic application. |
| AllRed | Normal | All signals are in the stop state. The traffic signalling is controlled by the TLC Facilities. |
| SwitchOff | Shut down | Intersection switches off. Usually a transition state for a limited time, regulation impose signal group states and timing. |
| Error | Failure | Intersection is in the error state. The signal groups are usually amber flashing or dark. |
4.2.3 Facilities responsibilities
The TLC Facilities is responsible for the safe execution of the requests issued by the active ITS-CLA. In case the TLC Facilities can no longer safely execute the requests it shall bring the intersection to a safe state in according with the regulation. For The Netherlands this is outlined in the NEN3384.
4.3 Signal groups
The most common traffic signals in Europe are depicted below. These signal sequences comply with the Vienna Convention on Road Signs and Signals which came into force in 1978.
[ link ]
Figure 4 Signal sequences
4.3.1 Control states
To support mapping of the various signal sequences the interface is based on 5 control states.
| State | Description |
| RED (STOP) | The signal group is typically red indicating that the traffic flow controlled by the signal group has to stop. |
| RED/AMBER | The signal shows a fixed period of red/amber, indicating that the signal is about to change (i.e. from red to green). |
| GREEN (GO) | The signal group is typically green indicating that the traffic flow controlled by the signal group can proceed. |
| GREEN FLASHING | The signal group shows a fixed period of green flashing at the end of green indicating the traffic to slow down because green is ending soon (followed by the amber or red state). |
| AMBER | The signal shows a fixed period of amber, indicating stop if possible (or a fixed period of green flashing for a pedestrian signal). |
The figure below outlines the control state transitions. The control states RED/AMBER, GREEN FLASHING and AMBER are identified with alternative transitions indicating that these states are not present in some signal group types. The optional transition from AMBER to GREEN is only used under specific conditions in Sweden.
[ link ]
Figure 5 Signal group control-state transitions (Control)
An ITS-CLA can request the explicit states for control matching a signal group state sequence as seen in Figure 5. The TLC Facilities actively prevents violation of maximum time by proceeding from a state with a maximum guaranteed time to the next state.
Alternatively, an ITS-CLA can request STOP and GO control states. The TLC Facilities executes the required transitions between the STOP and GO states taking the minimum timing into account.
4.3.2 Signal group states
The states are represented in the interface using signal group states as similarly used in SPaT message (See [REF021]).
The table below outlines the mapping of the control states on the signal group states. The signal group states 10 and 11 are added to facilitate the control state Green Flashing as described in paragraph 4.3.1, but are not part of SPaT.
The table below outlines the mapping of the control states on the signal group states. The signal group states 10 and 11 are added to facilitate the control state Green Flashing as described in paragraph 4.3.1, but are not part of SPaT.
| Signal group state | Functional state | Used in CONTROL | Description |
| Unavailable (0) | - | - | - |
| Dark (1) | DARK | - | no signal |
| StopThenProceed (2) | RED | YES | stop at stop line and proceed when safe (Typically not used in the Netherlands) |
| StopAndRemain (3) | RED | YES | stop at stop line and do not proceed |
| PreMovement (4) | RED/AMBER | YES | prepare to proceed |
| PermissiveMovementAllowed (5) | GREEN | YES | proceed, be aware of possible conflicting traffic at the intersection |
| ProtectedMovementAllowed (6) | GREEN | YES | proceed, no conflicting traffic expectedat the intersection |
| PermissiveClearance (7) | AMBER | YES | prepare to stop and stop if possible, be aware of possible conflicting traffic at the intersection |
| ProtectedClearance (8) | AMBER | YES | prepare to stop and stop if possible, no conflicting traffic expected at the intersection |
| CautionConflictingTraffic (9) | STANDBY / AMBER FLASHING | - | proceed with caution, conflicting traffic may be present at the intersection |
| PermissiveMovementPreClearance1) Added for the TLC-FI, not part of standard SPaT state (10) | GREEN FLASHING | YES | proceed, be aware of possible conflicting traffic at the intersection |
| ProtectedMovementPreClearance2) Added for the TLC-FI, not part of standard SPaT state (11) | GREEN FLASHING | YES | proceed, no conflicting traffic expected at the intersection |
Note: A signal group is configured in the TLC as protected or permissive.
4.3.3 Abnormal lights
The tables below provide an overview of special signals and how they shall be presented as SignalGroupState on the TLC-FI. The counterpart of these tables which are included in [REF060] show how these signals shall be presented by the ITS-CLA as eventState in SPaT on UDAP-FI or signalGroupState on RIS-FI. As these two presentations are different the two sets of tables are supportive to determine these differences.
In the following cases a single manoeuvre (connection) is controlled by multiple signal groups, often a primary (main) signal head combined with a secondary signal such as a single lens. These are treated separately in the tables below.
4.3.4 Dummy Signalgroups
Only signal groups included in MAP and SPAT messages shall be published on the TLC-FI interface.
Dummy signal groups shall not be part of the TLC-FI interface
For example: It may occur that a TLC or ITS-CLA contains dummy signal groups. For example, in the TLC as a preparation to future extensions of the intersection, or a signal group that is mis-used for special sign (e.g. bicycles to the right freeway, an output signal should be used for that), or in the ITS-CLA because it is used for creating fictive conflicts. In any case it is never allowed to present these dummy groups on the TLC-FI interface.
4.3.5 Clearance timing
The clearance times published as META data by the TLC Facilities via the TLC-FI are inter-green timings.
[ link ]
Figure 6 Clearance timing
4.3.6 Application responsibilities
The ITS-CLA in control of an intersection is responsible for requesting signal group control states in order to implement signal sequences and timing (i.e. the ITS-CLA shall implement correct sequence and timing and not rely on the TLC Facilities for safe signal sequences and timing).
4.3.7 Facilities responsibilities
The TLC Facilities is responsible for safely executing the requested control state and doing so adhering to the signal group s characteristics such as allowed transitions, minimum and maximum timing and clearance times and protected or permissive type signal heads.
The TLC Facilities is also responsible for executing the correct signal group sequences when an intersection is not in the Control state.
4.4 Outputs
The following types of outputs are supported by the TLC Facilities:
- Exclusive outputs
- Non-exclusive outputs
Exclusive outputs are outputs that are bound to a specific Intersection. These outputs may only be controlled by the timeITS-CLA that is in control of the Intersection. They will be reset to default state during handover between ITS-CLA s and when an ITS-CLA ends control. An example of such an output is demand feedback for a pedestrian pushbutton.
Non-exclusive outputs are outputs that are not bound to a specific Intersection. They can be controlled by any ITS Provider Application (ITS-PRA), there is no validation that the output is only controlled by one ITS-PRA. They will be reset to a default state when not refreshed within the time defined in 4.8. An example for such an output is informative signs.
4.4.1 Wait time prediction signal
A wait time prediction signal can have three different appearances, two with LED s or one with a number (remaining seconds till green):
A wait time prediction signal shall be controlled by an exclusive output.
- Bits 0..7: Remaining number of (LED)indicators or remaining seconds till green
- Bit 8: The signal BUS or TRAM is flashing lit (type A only) or the signal BUS is flashing lit (type C only)
- Bit 9: The signal TRAM is flashing lit (type C only)
The value 0 indicates that the wait time prediction signal is off.
While value bits 0-7 0 the signal Wacht is lit (type A and C only)
4.4.2 Dummy output signals
Only generic outputs shall be published on the TLC-FI, they represent an agreed functionality in the ITS-CLAP as well as in the TLC. Dummy outputs shall not be part of the TLC-FI interface.
For example: output-to-input connections between two ITS-CLA s or two TLC s cannot be defined for sending timing messages or internal states. In any case these outputs and inputs should not appear on the TLC-FI interface.
4.5 Inputs
The inputs published by the TLC Facilities can be monitored by ITS-A s.
4.5.1 Dummy input signals
Only generic Inputs shall be published on TLC-FI, they represent an agreed functionality in the ITS-CLA as well as in the TLC.
Dummy inputs shall not be part of the TLC-FI interface.
4.6 Detectors
The detectors published by the TLC Facilities can be monitored by ITS-A s.
4.6.1 Dummy detectors
Only generic detectors shall be published on TLC-FI, they represent an agreed detector in the ITS-CLA as well as in the TLC.
Dummy detectors shall not be part of the TLC-FI interface.
4.7 Control Application
An ITS-CLA is a specific type of ITS-A that can control the signals and exclusive outputs of an intersection through the TLC-FI. This involves requesting the intersection state, the signal group states and exclusive output states. The TLC Facilities executes these requests.
4.7.1 States
The TLC Facilities manages a state machine per ITS-CLA. The state machine consists of two parts: Session State and Control State. The design also takes into account the distributed iTLC architecture (i.e. TLC Facilities and ITS-CLA are asynchronous), therefore the ITS-CLA needs to acknowledge the state transitions (STOP/START CONTROL) initiated by the TLC Facilities and the TLC Facilities checks for a timely response of the ITS-CLA using timeouts.
Figure 7 defines the states for an ITS-CLA. Transition states that must be guarded by timeouts are explicitly defined, as are states in which the ITS-CLA is responsible for controlling the intersection.
[ link ]
Figure 7 ITS-CLA Control State transitions
The following table shows the Session States of an ITS-CLA:
| Session state | Description |
| Disconnected | The ITS-CLA is not connected to the TLC Facilities. The TLC Facilities waits for the ITS-CLA to establish a TCP socket connection and authenticate itself. |
| Connected | The ITS-CLA is connected to the TLC Facilities, it is authenticated and authorised. |
The Control States specific to an ITS-CLA are defined in the following table and are states within the session state Connected:
| Control State | Description |
| NotConfigured | The ITS-CLA is connected to the TLC Facilities, it is authenticated and authorised. In this state the ITS-CLA takes the initiative to read Meta data from the TLC Facilities and subscribes to objects. The TLC Facilities verifies that the ITS-CLA meets the minimum requirements for an ITS-CLA (see control state logic in 4.7.2). |
| Offline | The ITS-CLA is not ready or not able to control the intersection. Note: The reasons why the ITS-CLA is not ready or not able are outside the scope of this document. |
| ReadyToControl | The ITS-CLA is ready to control the intersection when the TLC Facilities allows it to. |
| StartControl | The TLC Facilities requests the ITS-CLA to take control of the intersection. The TLC Facilities wait in this state for the ITS-CLA to acknowledge the state. The ITS-CLA provides a (valid) set of control requests to the TLC Facilities and acknowledges that it has control. |
| InControl | ITS-CLA is in control of the intersection The TLC Facilities executes the control requests from the ITS-CLA according to signal group and intersection state rules. The ITS-CLA has control over the signal groups when Intersection.state = Control. The TLC Facilities has control over the signal groups in all other intersection states. The control requests are:
|
| EndControl | The TLC Facilities requests the ITS-CLA to release control of the intersection. The TLC Facilities wait in this state for the ITS-CLA to acknowledge the state. The ITS-CLA may release control immediately or bring the intersection in a defined state before releasing the control. Examples of a defined state are all red or main direction green. The ITS-CLA has control over the signal groups when Intersection.state = Control. The TLC Facilities has control over the signal groups in all other intersection states. A typical situation is when the TLC Facilities wants to give the control of the intersection to another ITS-CLA. |
| Error | The ITS-A is moved to this state when there has been an unrecoverable error. The TLC waits for an action to reset the errors of this application. The ITS-A should:
|
The (default) timeout values of the different states are listed in the following table:
| State | Timeout | Description |
| NotConfigured timeout | 60s | Default timeout of an ITS-CLA to finalize the procedures of the NotConfigured state. |
| StartControl timeout | 5s | Default timeout of an ITS-CLA to finalize the procedures of the StartControl state. |
| EndControl timeout | 180s | Default timeout of an ITS-CLA to finalize the procedures of the EndControl state. |
4.7.2 Control State logic
This section contains the state logic of the Control States. This is done by defining decision tables for the TLC Facilities logic.
For each Control State, different CONDITIONS that must be fulfilled are defined. The expected reaction by the TLC Facilities is documented in ACTIONS including ERROR conditions.
Table 1 Control state logic - NotConfigured
| CONDITIONS | Application.type = ControlApplication AND Application session state = Connected AND Application.controlState = NotConfigured | N | Y | Y | Y | Y |
| Application.reqIntersection = null | - | N | - | - | N | |
| Application.reqControlState= null | - | - | N | - | N | |
| Application.reqIntersection = Intersection.ID | - | N | - | - | Y | |
| Application.reqControlState= Offline | - | - | N | - | Y | |
| NotConfigured state timeout expired | - | - | - | Y | N | |
| ITS-CLA has subscribed to the intersection | - | - | - | - | Y | |
| ITS-CLA has subscribed to all signal groups | - | - | - | - | Y | |
| ITS-CLA has subscribed to the exclusive outputs | - | - | - | - | Y | |
| ACTIONS | Invalid intersection ID Set Application.controlState = Error | ✓ | ||||
| Not configured timeout Set Application.controlState = Error | ✓ | |||||
| Invalid requested control state Set Application.controlState = Error | ✓ | |||||
| Set Application.controlState = Offline | ✓ | |||||
| Log the state transition. | ✓ | |||||
| Log error situation | ✓ | ✓ | ✓ |
Table 2 Control state logic - Offline
| CONDITIONS | Application.type = ControlApplication AND Application session state = Connected Application.controlState = Offline | N | Y | Y | Y |
| Application.reqControlState= Offline | - | N | Y | - | |
| Application.reqControlState= ReadyToControl | - | N | - | Y | |
| ACTIONS | Invalid requested control state Set Application.controlState = Error | ✓ | |||
| Set Application.controlState = ReadyToControl | ✓ | ||||
| Log the state transition. | ✓ | ||||
| Log error situation | ✓ |
Table 3 Control state logic - ReadyToControl
| CONDITIONS | Application.type = ControlApplication AND Application session state = Connected Application.controlState = ReadyToControl | N | Y | Y | Y |
| Application.reqControlState= Offline | - | N | Y | - | |
| Application.reqControlState= ReadyToControl | - | N | - | Y | |
| START CONTROL | - | - | - | Y | |
| ACTIONS | Invalid requested control state Set Application.controlState = Error | ✓ | |||
| Set Application.controlState = Offline | ✓ | ||||
| Set Application.controlState = StartControl | ✓ | ||||
| Log the state transition. | ✓ | ✓ | |||
| Log error situation | ✓ |
Table 4 Control state logic - StartControl
| CONDITIONS | Application.type = ControlApplication AND Application session state = Connected Application.controlState = StartControl | N | Y | Y | Y | Y | Y | Y |
| Application.reqControlState= Offline | - | N | Y | - | - | - | - | |
| Application.reqControlState= ReadyToControl | - | N | - | Y | - | - | - | |
| Application.reqControlState= InControl | - | N | - | - | Y | Y | - | |
| StartControl state timeout expired | - | - | - | Y | - | - | - | |
| STOP CONTROL | - | - | - | - | - | - | Y | |
| Intersection.state = Control | - | - | - | - | Y | N | - | |
| ACTIONS | Invalid requested control state Application.controlState = Error | ✓ | ||||||
| StartControl timeout Set Application.controlState = Error | ✓ | |||||||
| Set Application.controlState = Offline | ✓ | ✓ | ||||||
| Set Application.controlState = InControl | ✓ | ✓ | ||||||
| Log the state transition | ✓ | ✓ | ✓ | ✓ | ||||
| Execute the ITS-CLA signal group control requests | ✓ | |||||||
| Execute the ITS-CLA output control requests | ✓ | ✓ | ||||||
| Execute the ITS-CLA intersection state request | ✓ | ✓ | ||||||
| Log error situation | ✓ | ✓ |
Table 5 Control state logic InControl
| CONDITIONS | Application.type = ControlApplication AND Application session state = Connected Application.controlState = InControl | N | Y | Y | Y | Y | Y | Y | Y | Y | Y |
| Application.reqControlState= Offline | - | N | Y | - | - | - | - | - | - | - | |
| Application.reqControlState= ReadyToControl | - | N | - | Y | - | - | - | - | - | - | |
| Application.reqControlState= InControl | - | N | - | - | Y | Y | Y | Y | - | - | |
| Application.reqControlState= EndControl | - | N | - | - | - | - | - | - | Y | Y | |
| STOP CONTROL | - | - | - | - | N | N | Y | Y | - | - | |
| Intersection.state = Control | - | - | - | - | N | Y | N | Y | N | Y | |
| ACTIONS | Invalid requested control state Set Application.controlState = Error | ✓ | ✓ | ||||||||
| Set Application.controlState = Offline | ✓ | ||||||||||
| Set Application.controlState = EndControl | ✓ | ✓ | ✓ | ✓ | |||||||
| Log the state transition | ✓ | ✓ | ✓ | ✓ | ✓ | ||||||
| Execute the ITS-CLA signal group control requests | ✓ | ✓ | ✓ | ||||||||
| Execute the ITS-CLA output control requests | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | |||||
| Execute the ITS-CLA intersection state request | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | |||||
| Log error situation | ✓ | ✓ |
Table 6 Control state logic - EndControl
| CONDITIONS | Application.type = ControlApplication AND Application session state = Connected Application.controlState = EndControl | N | Y | Y | Y | Y | Y | Y |
| Application.reqControlState= Offline | - | N | Y | - | - | - | - | |
| Application.reqControlState= ReadyToControl | - | N | - | Y | - | - | - | |
| Application.reqControlState= InControl or EndControl | - | N | - | - | Y | Y | Y | |
| EndControl state timeout expired | - | - | - | - | Y | N | N | |
| Intersection.state = Control | - | - | - | - | - | N | Y | |
| ACTIONS | Invalid requested control state Set Application.controlState = Error | ✓ | ||||||
| EndControl timeout Set Application.controlState = Error | ✓ | |||||||
| Set Application.controlState = Offline | ✓ | |||||||
| Set Application.controlState = ReadyToControl | ✓ | |||||||
| Log the state transition | ✓ | ✓ | ||||||
| Execute the ITS-CLA signal group control requests | ✓ | |||||||
| Execute the ITS-CLA output control requests | ✓ | ✓ | ||||||
| Execute the ITS-CLA intersection state request | ✓ | ✓ | ||||||
| Log error situation | ✓ | ✓ |
4.7.3 Application selection
The TLC Facilities selects the active ITS-CLA per intersection. A non-exhaustive list of sources considered by the TLC Facilities is outlined below.
Table 7 Application selection sources
| Source | Description |
| Control panel | A user actively requests a specific ITS-CLA using the user interface or control panel. |
| Time-of-day | ITS-CLA selected based on a configured time-of-day table |
| Traffic Management system | The Traffic Management system actively requests a specific ITS-CLA |
4.7.4 Application handover
The TLC Facilities is responsible for the correct hand-over of an active ITS-CLA to another ITS-CLA. The following methods are supported:
- Cleared handover
- Pre-defined point handover
- Direct handover
In the cleared handover method, the ending ITS-CLA finishes its control, the TLC Facilities makes sure that the intersection is cleared (AllRed) and hands control to the new ITS-CLA.
During the pre-defined point handover method, the ending ITS-CLA ends its control and enters a pre-defined point. The new ITS-CLA listens to information about the signal groups and detection and when the old ITS-CLA is finished, the TLC Facilities hands control to the new ITS-CLA during the Control intersection state.
During the direct handover method, the ending ITS-CLA ends its control directly in an un-defined point. The TLC Facilities hands control to the new ITS-CLA.
Application handover is partly the responsibility of the two ITS-CLA s and partly of the TLC Facilities. Regulations may dictate the chosen method, which must be adhered to by the TLC Facilities and ITS-CLA s. The handover procedures are supported by the EndControl and StartControl Control States for the ITS-CLA ending respectively starting control.
For each ITS-CLA allowed to control an intersection, the TLC may be configured with the required handover method. When an ITS-CLA prepares to control an intersection, it provides its supported handover methods. All ITS-CLA s are expected to handle the cleared handover method.
The TLC considers local configuration and an ITS-CLA s reported capabilities when it initiates a handover to this Application.
4.7.5 Backup ITS-CLA
The TLC Facilities is responsible for selecting a suitable alternative ITS-CLA, local backup application or to switch the intersection to the Standby state, in case the selected ITS-CLA is not available or not ready to control an intersection. Please refer to the control state logic and the functional use cases for details.
4.8 Timing
This section contains timing parameters.
Table 8 Timing parameters
| Item | Time | Description |
| Application minimum control | 180s | Default time an application (backup or ITS-CLA) that has been given control can assume to be in-control. |
| Start-up application selection timeout | 15s | Default time the TLC-FI shall wait before selecting a (backup) application to take control of an Intersection after the TLC Facilities has been powered up (or restarted). This is necessary to give the ITS-CLA time to register to the TLC Facilities and get control. |
| Non-exclusive outputs fall back to default | 30s | Default time after which an Output is set back to its default configured state when it is not being controlled by any ITS-A or for which the requested state has been set by an ITS-A which is no longer connected to the TLC-FI |
4.9 Objects
The TLC Facilities and ITS-A s exchange different types of information as TLC Objects.
A TLC Object consists of the following information:
- TLC Object Type
- Identifier
- Attributes
There are two categories of FI Objects:
- TLC State objects. These objects describe physical or logical entities and their states. The objects are uniquely identifiable by means of an explicit identifier and typically exist throughout the lifetime of the TLC instance. Examples of such objects are signal groups and loop detectors containing states such as external signal group state and detection input state.
- TLC Event Objects. These objects convey the occurrence of a specific event related to a TLC state object. These objects can be seen as generated by TLC State Objects. Such an event can for instance be a vehicle message (KAR) or speed and length detected by a speed and length detector. The objects are valid when they occur and are not persistent within the TLC.
A TLC Object can have many attributes, the following types of attributes exists:
- Meta: Contains constant meta-data of the object, will not change during the lifetime of the object. Typically this attribute is determined by the TLC and provided to ITS-A s on request.
- State: Contains a state of the object
For a State Object: This state is updated throughout the lifetime of the object. Typically such an attribute can be updated by either the TLC or an ITS-A s.
For an Event Object: This state is conveyed once and is valid at that point.
4.10 Object exchange model
[ link ]
Figure 8 Object exchange
4.10.1 Object synchronization
TLC State Objects are objects implemented in the TLC.
The following principles are adhered to.
- Local copy: Applications monitoring TLC State Objects keep a local copy of the objects
- On Change: TLC State objects are synchronized when they change
- Changes Only: Only attributes of a TLC State object actually changed are transmitted to a peer listening to this object
ITS-A s can update attributes of TLC State Objects by writing the changed attribute to the TLC. For objects with (default) lifetime expiration, the ITS-A must write the (unchanged) attributes periodically.
A notification mechanism synchronizes the TLC State Object between the ITS-A(s) and the TLC.
4.10.2 Event Object generation
TLC Event Objects appear at the Facilities when they are generated by a TLC State Object and are conveyed once to ITS-A s interested in this information.
Each event object type contains (optional) attributes. Only attributes actually relevant for the event are conveyed, others are omitted.
The following principles are adhered to when conveying TLC Event Objects:
- On Event: A TLC Event Object is created when a corresponding event is detected. The event objects as such don t have a state that will be synchronized
- Complete: When an event object is created and distributed, all attributes available are sent to the listener. Attributes not part of the event are omitted.
- Volatile: A TLC Event Object is synchronized once, then it is removed from the originator as such it will not be explicitly tracked by the TLC.
4.10.3 Atomic updates
When objects have functional relations with each other and therefore must be updated as a consistent set of objects, the updates to the objects are sent as a single update containing multiple objects. Different Object Types may be part of such a set. This update is atomic, which means that either all object updates are accepted or none are.
When modifying objects, the ITS-A is responsible for maintaining functional consistency by grouping these object updates in one update, the TLC is responsible for treating this update as an atomic set and takes decisions based on the complete set.
For instance, when an ITS-CLA updates the requested signal group state of a set of signal groups, it needs to modify a set of objects in one update.
4.10.4 Time reference
See [REF061].
4.10.5 Calendar time (UTC)
See [REF061].
5 Objects
This section contains the definition of all TLC Objects. The following figure gives an overview of the top-level objects.
[ link ]
Figure 9 Top-level objects for the TLC-FI
5.1 Base
SwicoState
| Descriptive name | Swico state | |
| Definition | A value describing the state of a software input commando (SWICO) | |
| Representation | Integer | |
| Range | ENUM { | |
| NoSwico | (0) | |
| SwicoOff | (1) | |
| SwicoOn | (2) | |
| } | ||
| Unit | N/A | |
TLCObjectType
| Descriptive name | TLC Object Type | ||
| Definition | This list contains all the different object types for the TLC-FI. This is an implementation of the abstract type ObjectType | ||
| Representation | Integer | ||
| Range | ENUM { | ||
| Session | (0) | Note: This is a specific object type which is only exchanged between peers about the session, the different session types are defined in 5.2 | |
| TLCFacilities | (1) | ||
| Intersection | (2) | ||
| SignalGroup | (3) | ||
| Detector | (4) | ||
| Input | (5) | ||
| Output | (6) | ||
| SpecialVehicleEventGenerator | (7) | ||
| } | |||
| Unit | N/A | ||
5.2 Application session
ControlApplication
| Descriptive name | An ITS Control Application object | |||
| Definition | This describes a session with an ITS Control Application. The object is of type Session. | |||
| Consumer | Provider | Control | attr | |
| Access | N/A | N/A | R/W | |
| Representation | { | |||
| META { | ||||
| SessionID | sessionid | R | ||
| ApplicationType | type | R | ||
| } | ||||
| STATE { | ||||
| HandoverCapability | startCapability | W | ||
| HandoverCapability | endCapability | W | ||
| ObjectID<Intersection> | reqIntersection | W | ||
| ControlState | reqControlState | W | ||
| ControlState | controlState | R | ||
| HandoverCapability | reqHandover | R | ||
| } | ||||
| } | ||||
| Events | SessionEvent | |||
| Range | N/A | |||
| Unit | N/A | |||
ProviderApplication
| Descriptive name | An ITS Provider Application object |
| Definition | This describes a session with an ITS Provider Application. The object is of type Session. |
| ConsumerProviderControlattr | |
| Access | N/AN/AN/A |
| Representation | { META { SessionIDsessionidR ApplicationTypetypeR } } |
| Events | SessionEvent |
| Range | N/A |
| Unit | N/A |
ConsumerApplication
| Descriptive name | An ITS consumer application object |
| Definition | This describes a session with an ITS Consumer Application. The object is of type Session. |
| ConsumerProviderControlattr | |
| Access | N/AN/AN/A |
| Representation | { META { SessionIDsessionidR ApplicationTypetypeR } } |
| Events | SessionEvent |
| Range | N/A |
| Unit | N/A |
HandoverCapability
| Descriptive name | Control Application handover capabilities |
| Definition | Defines the different capabilities an ITS Control Application has to end its control and to start control. |
| Representation | Integer |
| Range | ENUM { Cleared(0) PreDefined(1) Direct(2) } |
| Unit | N/A |
ControlState
| Descriptive name | Control Application control states |
| Definition | Control states of an ITS Control Application |
| Representation | Integer |
| Range | ENUM { Error(0) NotConfigured(1) Offline(2) ReadyToControl(3) StartControl(4) InControl(5) EndControl(6) } |
| Unit | N/A |
SessionEventCode
| Descriptive name | Session event codes |
| Definition | Code defining an event for the Session. This is an extension of the SessionEventCode of [REF061]. |
| Representation | Integer |
| Range | ENUM { UpdateStateFailedIncorrectControlState(1000) UpdateStateFailedIncorrectApplicationType(1001) UpdateStateFailedIncorrectIntersection(1002) } |
| Unit | N/A |
5.3 Detectors
Detector
| Descriptive name | A detector |
| Definition | This object describes a detector. The stateticks attribute defines the tick of the TLC Facilities when the state attribute within the STATE {} scope was last changed. |
| ConsumerProviderControl | |
| Access | RRR |
| Representation | { META { ObjectIDid Boolean generatesEvents } Ticksstateticks STATE { DetectorStatestate DetectorFaultStatefaultstate SwicoStateswico } } |
| Events | DetectorEvent |
| Range | |
| Unit |
DetectorFaultState
| Descriptive name | The fault state of a dectector |
| Definition | Defines the fault state of a detector |
| Representation | Integer |
| Range | ENUM { None(0) TooLongUnoccupied(1) TooLongOccupied(2) Flutter(3) HardwareError(4) } |
| Unit | N/A |
DetectorState
| Descriptive name | The state of a detector |
| Definition | Defines the state of a detector. |
| Representation | Integer |
| Range | ENUM { Unoccupied(0) Occupied(1) } |
| Unit | N/A |
DetectorEvent
| Descriptive name | A detector event |
| Definition | This object describes an event generated by a detector. When it occurs the id is the same as the origination Detector. This object implements the abstract object ObjectEventContent. |
| Representation | { Speedobjectspeed Lengthobjectlength Lengthobjectheight <OPT> Lengthobjectwidth <OPT> DetectorClassificationclassification DetectorDirectiondirection } |
| Range | N/A |
| Unit | N/A |
DetectorClassification
| Descriptive name | The vehicle class |
| Definition | The vehicle class as detected by a detector |
| Representation | Integer |
| Range | ENUM { Unknown(0) Pedestrian(1) Bicycle(2) Motorcycle(3) Car(4) CarWithTrailer(5) Lorry(6) LorryWithTrailer(7) Bus(8) BusWithTrailer(9) RoadTrain(10) } |
| Unit | N/A |
DetectorDirection
| Descriptive name | The driving direction |
| Definition | The driving direction detected by a detector |
| Representation | Integer |
| Range | ENUM { Normal(0) Reverse(1) } |
| Unit | N/A |
5.4 Inputs
Input
| Descriptive name | An input |
| Definition | This object describes an input. SwicoOff sets the state to 0, SwicoOn sets the state to 1. The stateticks attribute defines the tick of the TLC Facilities when the state attribute within the STATE {} scope was last changed. |
| ConsumerProviderControl | |
| Access | RRR |
| Representation | { META { ObjectIDid } Ticksstateticks STATE { InputStatestate InputFaultStatefaultstate SwicoStateswico } } |
| Range | N/A |
| Unit | N/A |
InputFaultState
| Descriptive name | Input fault state |
| Definition | A value representing the fault state of an Input |
| Representation | Integer |
| Range | ENUM { None(0) HardwareError(1) } |
| Unit | N/A |
InputState
| Descriptive name | Input state |
| Definition | A value representing the state of an Input |
| Representation | Integer |
| Range | -32768 to 32767 |
| Unit | N/A |
5.5 Intersections
Intersection
| Descriptive name | Intersection |
| Definition | An object defining an intersection with all inputs, Outputs, Special Vehicles, Detectors en Signal Groups that are controlled by one ITS Control application. This Intersection with its own IntersectionControlState is identical to a ControlUnit in the ITF format. The stateticks attribute defines the tick of the TLC Facilities when the state attribute within the STATE {} scope was last changed. |
| ConsumerProviderControlattr | |
| Access | RRR/W |
| Representation | { META { ObjectIDidR ObjectID<Output>outputs[]R ObjectID<Input>inputs[]R ObjectID<SignalGroup> signalgroups[]R ObjectID<Detector>detectors[]R ObjectID<SpecialVehicleEventGenerator> spvehgeneratorR } TicksstateticksR STATE { IntersectionControlStatereqStateW *1) IntersectionControlStatestateR } } |
| Events | N/A |
| Range | N/A |
| Unit | N/A |
*1) An ITS-CLA can only write Intersection.reqState when ControlApplication.controlState = StartControl, InControl or EndControl. Writing Intersection.reqState during any other ControlApplication.controlState will result in an error.
IntersectionControlState
| Descriptive name | Operational state |
| Definition | A value describing the operational state of an intersection |
| Representation | Integer |
| Range | ENUM { Error(0) Dark(1) Standby(2) AlternativeStandby(3) SwitchOn(4) SwitchOff(5) AllRed(6) Control(7) } |
| Unit | N/A |
5.6 Outputs
Output
| Descriptive name | An output |
| Definition | This object describes a non-signal group output signal. The stateticks attribute defines the tick of the TLC Facilities when the state attribute within the STATE {} scope was last changed. This object is refreshed by the ITS-A writing reqState (non-exclusive outputs). |
| ConsumerProviderControlattr | |
| Access | RR/WR/W |
| Representation | { META { ObjectIDidR ObjectID<Intersection>intersectionR } TicksstateticksR STATE { OutputStatereqStateW *1) OutputStatestateR OutputFaultStatefaultstateR } } |
| Range | N/A |
| Unit | N/A |
*1) An ITS-CLA can only write Output.reqState for exclusive outputs when ControlApplication.controlState = StartControl, InControl or EndControl. Writing Output.reqState (for an exclusive output) during any other ControlApplication.controlState will result in an error.
OutputFaultState
| Descriptive name | Output fault state |
| Definition | A value describing the fault state of an output |
| Representation | Integer |
| Range | ENUM { None(0) HardwareError(1) } |
| Unit | N/A |
OutputState
| Descriptive name | Output state |
| Definition | A value describing the state of an output |
| Representation | Integer |
| Range | -32768 to 32767, when set to null , the default TLC defined/configured value of the output is used. |
| Unit | N/A |
5.7 Signal groups
SignalGroup
| Descriptive name | A signal group |
| Definition | This object describes a signal group The stateticks attribute defines the tick of the TLC Facilities when the state attribute within the STATE {} scope was last changed. |
| ConsumerProviderControlattr | |
| Access | RRR/W |
| Representation | { META { ObjectIDidR ObjectID<Intersection>intersectionR SignalConflictintergreen[]R SignalTimingtiming[]R } TicksstateticksR STATE { SignalGroupStatereqStateW *1) SignalGroupStatestateR } } |
| Range | N/A |
| Unit | N/A |
*1) An ITS-CLA can only write SignalGroup.reqState when ControlApplication.controlState = StartControl, InControl or EndControl. Writing SignalGroup.reqState during any other ControlApplication.controlState will result in an error.
SignalConflict
| Descriptive name | A signal conflict |
| Definition | A conflict with a given SignalGroup, and the time to wait after that SignalGroup turned to STOP to clear the intersection. |
| Representation | { ObjectID<SignalGroup>signalgroup Integerintergreentime } |
| Range | intergreentime: from 0 to 65535 |
| Unit | 0.1s |
SignalGroupState
| Descriptive name | The state of a signal group |
| Definition | The state of a signal group, encoded in the SPaT way. To be used to request a new state and to report the current state. |
| Representation | Integer |
| Range | ENUM { Unavailable(0) Dark(1) StopThenProceed(2) StopAndRemain(3) PreMovement(4) PermissiveMovementAllowed(5) ProtectedMovementAllowed(6) PermissiveClearance(7) ProtectedClearance(8) CautionConflictingTraffic(9) PermissiveMovementPreClearance(10) ProtectedMovementPreClearance(11) } |
| Unit | N/A |
SignalTiming
| Descriptive name | Safety timing of a signal group |
| Definition | The minimum safety time a signal group must be in a state and the maximum time a signal group may be in a state. |
| Representation | { SignalGroupStatestate Integermin Integermax } |
| Range | min / max: From 0 to 65535, null : undefined |
| Unit | 0.1s |
5.8 Special vehicles
SpecialVehicleEventGenerator
| Descriptive name | A special vehicle event generator object |
| Definition | This object generates events for special vehicles. |
| Representation | { META { ObjectIDid } STATE { SpecialVehicleEventGeneratorFaultStatefaultstate } } |
| Events | SpecialVehicleEvent |
| Range | N/A |
| Unit | N/A |
SpecialVehicleEventGeneratorFaultState
| Descriptive name | Special vehicle event generator fault state |
| Definition | Defines the fault state a special vehicle event generator object can be in. When in fault, there are seen faults in underlying mechanisms / hardware that produce events. As there may be multiple units producing such events events may still be generated, but the receiver can use the fault status as an indication that some events may be missed. |
| Representation | Integer |
| Range | ENUM { None(0) Error(1) } |
| Unit | N/A |
SpecialVehicleEvent
| Descriptive name | A special vehicle event data type |
| Definition | This object describes the contents of a special vehicle event. The contents are based on the contents of a KAR message (see [REF142]). For the translation of the content of a VECOM message to a TLC-FI SpecialVehicleEvent see chapter 9. This object implements the abstract object ObjectEventContent |
| Representation | { VirtualLoopvirtualLoop <OPT> VehicleTypevehType <OPT> LineNumberlineNr <OPT> ServiceNumberserviceNr <OPT> CompanyNumbercompanyNr <OPT> VehicleId vehId <OPT> DirectionSGdirectionSG <OPT> VehicleStatusstatus <OPT> PriorityClasspriorityClass <OPT> PunctualityClasspunctuality <OPT> PunctualityTimepunctualityTime <OPT> Lengthlength <OPT> Speedspeed <OPT> DistanceToStoplinedistToStopLine <OPT> TimeToStopLinetimeToStopLine <OPT> JourneyNumberjourneyNr <OPT> JourneyCategoryjourneyCat <OPT> RoutePublicTransportroutePT <OPT> AnnouncementTypetype <OPT> ActivationPointNractivationPointNr <OPT> Locationlocation <OPT> DateTimedateTime <OPT> SpvehSparereserve23 <OPT> SpvehSparereserve24 <OPT> } |
| Range | N/A |
| Unit | N/A |
ActivationPointNr
| Descriptive name | Activation point number |
| Definition | Location-information (in database PT-company) |
| Representation | Integer |
| Range | 0 to 32767 |
| Unit | N/A |
AnnouncementType
| Descriptive name | Announcement type |
| Definition | Defines the type of announcement for a special vehicle. |
| Representation | Integer |
| Range | ENUM { NoInformation(0) Checkin(1) Checkout(2) PreCheckin(3) } |
| Unit | N/A |
CompanyNumber
| Descriptive name | public transport company number |
| Definition | The company number of the public transport company |
| Representation | Integer |
| Range | 0 to 255 |
| Unit | N/A |
DateTime
| Descriptive name | Time and date structure |
| Definition | This structure defines the date and time |
| Representation | { Yeary <OPT> Monthm <OPT> Dayd <OPT> Hoursh <OPT> Minutesmin <OPT> Secondss <OPT> Millisecondsms <OPT> } |
| Range | N/A |
| Unit | N/A |
Year
| Descriptive name | Year |
| Definition | Defines the year in 4 digits |
| Representation | Integer |
| Range | 0 to 9999 |
| Unit | year |
Month
| Descriptive name | Month |
| Definition | Defines the month of the year |
| Representation | Integer |
| Range | 1 to 12 |
| Unit | month |
Day
| Descriptive name | Day |
| Definition | Defines the day of the month |
| Representation | Integer |
| Range | 1 to 31 |
| Unit | day |
Hours
| Descriptive name | Hours |
| Definition | Defines the hour of the day |
| Representation | Integer |
| Range | 0 to 23 |
| Unit | hours |
Minutes
| Descriptive name | Minutes |
| Definition | Defines the minute of the hour |
| Representation | Integer |
| Range | 0 to 59 |
| Unit | minutes |
Seconds
| Descriptive name | Seconds |
| Definition | Defines the second of the minute |
| Representation | Integer |
| Range | 0 to 59 |
| Unit | seconds |
Milliseconds
| Descriptive name | Milliseconds |
| Definition | Defines the millisecond of the second |
| Representation | Integer |
| Range | 0 to 999 |
| Unit | milliseconds |
DirectionSG
| Descriptive name | Signal group direction |
| Definition | The direction at the intersection, i.e. signal group number. Specific values defined in [REF142] |
| Representation | Integer |
| Range | 0 to 255 |
| Unit | N/A |
DistanceToStopline
| Descriptive name | Distance to the stopline |
| Definition | The distance a vehicle has to the stopline. Negative number means it has passed the stopline |
| Representation | Integer |
| Range | -99 to 9999 |
| Unit | meter |
JourneyCategory
| Descriptive name | Public transport journey category |
| Definition | Defines the type of public transport journey. Specific values defined in [REF142]. |
| Representation | Integer |
| Range | 0 to 99 |
| Unit | N/A |
JourneyNumber
| Descriptive name | Public transport journey number |
| Definition | The journey number of a public transport vehicle |
| Representation | Integer |
| Range | 0 to 9999 |
| Unit | N/A |
LineNumber
| Descriptive name | public transport line number |
| Definition | The line number of a public transport vehicle |
| Representation | Integer |
| Range | 0 to 9999 |
| Unit | N/A |
PriorityClass
| Descriptive name | Priority class |
| Definition | Defines the priority class requested. |
| Representation | Integer |
| Range | ENUM { NoInformation(0) NoPriority(1) Conditional(2) Absolute(3) AlarmLight(4) } |
| Unit | N/A |
PunctualityClass
| Descriptive name | Public transport punctuality class |
| Definition | Defines which class of punctuality the vehicle announces. |
| Representation | Integer |
| Range | ENUM { NoInformation(0) Late(1) OnTime(2) Early(3) OffSchedule(4) } |
| Unit | N/A |
PunctualityTime
| Descriptive name | Public transport punctuality time |
| Definition | Defines which time of punctuality the vehicle announces. Specific values defined in [REF142] |
| Representation | Integer |
| Range | -3600 to 3600 |
| Unit | seconds |
RoutePublicTransport
| Descriptive name | Public transport route |
| Definition | Public transport route |
| Representation | Integer |
| Range | 0 to 99 |
| Unit | N/A |
ServiceNumber
| Descriptive name | Public transport service number |
| Definition | The service number of the public transport vehicle |
| Representation | Integer |
| Range | 0 to 9999 |
| Unit | N/A |
SpvehSpare
| Descriptive name | Spare attribute |
| Definition | Spare (free-to use) attribute |
| Representation | Integer |
| Range | 0 to 32767 |
| Unit | N/A |
TimeToStopLine
| Descriptive name | Time to stop line |
| Definition | Driving time till passage stop line |
| Representation | Integer |
| Range | 0 to 255 |
| Unit | seconds |
VehicleId
| Descriptive name | Vehicle identification |
| Definition | A value describing the identification of a vehicle |
| Representation | Integer |
| Range | 0 to 32767 |
| Unit | N/A |
VehicleStatus
| Descriptive name | vehicle status |
| Definition | Defines the current status of the vehicle |
| Representation | Integer |
| Range | ENUM { NoInformation(0) Driving(1) Stopping(2) Departure(3) StandStill(4) } |
| Unit | N/A |
VehicleType
| Descriptive name | Vehicle type |
| Definition | Defines the type of vehicle. Specific values defined in [REF142]. |
| Representation | Integer |
| Range | 0 to 99 |
| Unit | N/A |
VirtualLoop
| Descriptive name | VirtualLoop |
| Definition | A value describing the virtual loop provided in a SpecialVehicleEvent |
| Representation | Integer |
| Range | 0 to 127 |
| Unit | N/A |
5.9 TLC Facilities
TLCFacilities
| Descriptive name | Traffic Light Controller Facilities |
| Definition | This object describes the TLC Facilities. |
| ConsumerProviderControl | |
| Access | RRR |
| Representation | { META { FacilitiesIDid ObjectID<Intersection>intersections[] ObjectID<SignalGroup>signalgroups[] ObjectID<Detector>detectors[] ObjectID<Input>inputs[] ObjectID<Output>outputs[] ObjectID<SpecialVehicleEventGenerator>spvehgenerator FacilitiesInformationinfo } |
| Range | N/A |
| Unit | N/A |
FacilitiesID
| Descriptive name | Facilities identifier |
| Definition | An identifier uniquely defining the TLC Facilities. This is a specific type of ObjectID used to identify the TLC Facilities. The identifier always starts with the identification of the manufacturer (see Manufacturer), followed by an identifier of the particular facilities as assigned by the manufacturer. The identifier is intended to allow for a unique identification of the TLC Facilities. |
| Representation | See ObjectID. Always starts with one of the identifiers defined in Manufacturer followed by a _ (underscore, ASCII 95) |
| Range | See ObjectID |
| Unit | See ObjectID |
FacilitiesInformation
| Descriptive name | Information about the TLC Facilities |
| Definition | This structure defines information about the facilities. The companyname contains the name of manufacturer of the TLC and should correspond literally with the name listed in the iTLC certificate. The certifiedName contains the TLC productname and should correspond literally with the name listed on the iTLC certificate. The certifiedVersion contains the TLC productversion which corresponds literally with the version listed on the iTLC certificate. The version contains the actual, internal TLC productversion. Semantic versioning is mandatory for certifiedVersion and version. |
| Representation | { ProtocolVersionfiVersion CompanyNamecompanyname FacilitiesVersionfacilitiesVersion ProductNamecertifiedName ProductVersioncertifiedVersion ProductVersionversion } |
| Range | N/A |
| Unit | N/A |
CompanyName
| Descriptive name | Company Name |
| Definition | Company name of a TLC-FI manufacturer |
| Representation | String |
| Range | Values 32 through 126 from the ASCII character set, except (double quotes, ASCII 34) and , (comma, ASCII 44) Maximum 32 characters |
| Unit | N/A |
FacilitiesVersion
| Descriptive name | The version of the facilities |
| Definition | The version of the facilities, this is a string which is defined by the manufacturer of the Facilities. |
| Representation | String |
| Range | Values 32 through 126 from the ASCII character set, except (double quotes, ASCII 34) and , (comma, ASCII 44) Maximum 32 characters |
| Unit | N/A |
Manufacturer
| Descriptive name | Manufacturer |
| Definition | Defines the manufacturer of the Facilities Note: This list of manufacturers is extendible, an implementor of the protocol must accept other values. |
| Representation | String |
| Range | ENUM { KoHartog KOH Vialis VIA Siemens SIE Swarco SWA Dynniq DYN } |
| Unit | N/A |
ProductName
| Descriptive name | ProductName |
| Definition | The certified product name of an iTLC Component. |
| Representation | String |
| Range | Values 32 through 126 from the ASCII character set, except (double quotes, ASCII 34) and , (comma, ASCII 44) Maximum 32 characters |
| Unit | N/A |
ProductVersion
| Descriptive name | ProductVersion |
| Definition | The product version of a iTLC Component. |
| Representation | { Integermajor Integerminor Integerrevision } |
| Range | major: 0 1000 minor: 0 1000 revision: 0 - 1000 |
| Unit | N/A |
6 Methods
6.1 Subscribe
This method is used to set subscription on TLC Objects in the TLC.
The requesting application is provided with an initial complete object without the parts defined in the Meta{} group. The application subscribes to updates of states part of the State{} group as well as all Events generated by the object.
The TLC Facilities replaces any existing subscription to an Object Type when a subscription is placed.
Request:
| Method: Subscribe | ||
| Parameter name | Type | Description |
| params | ObjectReference | Reference to the TLC Object Type and a list of identifiers to subscribe to |
Result:
| Parameter name | Type | Description |
| result | ObjectData | Array containing the data of the object(s) subscribed to. Only Readable attributes are returned. |
Error:
| Parameter name | Type | Description |
| code | ProtocolErrorCode | See error codes |
| message | String | optional message |
Example (Subscribe to detectors)
{
"method": "Subscribe",
"params": {
"type":4,
"ids":["D1","D2"]
},
"id": 14,
"jsonrpc": "2.0"
}
{
"result": {
"objects": {
"type":4,
"ids":["D1","D2"]
},
"data": [
{
"stateticks":1798,
"faultstate":0,
"state":0
},
{
"stateticks":1798,
"faultstate":0,
"state":1
}
],
"ticks":1808
},
"id":14,
"jsonrpc": "2.0"
}
6.2 UpdateState
This method is used to update state attributes of TLC Objects both when the state is changed by an ITS-A and when a state is changed in the TLC.
Notification:
| Method:UpdateState | ||
| Parameter name | Type | Description |
| params | ObjectStateUpdateGroup | Object state updates ITS-A uses the method: Only writeable attributes are part of the content TLC Facilities uses the method: Only readable attributes are part of the content. |
{
"method": "UpdateState",
"params": {
"update":[
{
"objects": {
"type":3,
"ids":["02","08"]
},
"states": [
{
"reqState":3
},
{
"reqState":5
}
]
},
{
"objects": {
"type":6,
"ids":["OUT1","OUT2"]
},
"states": [
{
"reqState":123
},
{
"reqState":4
}
]
}
],
"ticks":1808
},
"jsonrpc": "2.0"
}
6.3 NotifyEvent
This method is used to notify TLC Event Objects.
Notification:
| Method:NotifyEvent | ||
| Parameter name | Type | Description |
| params | ObjectEvent | object event(s) |
{
"method": "NotifyEvent",
"params": {
"objects": {
"type":7,
"ids":["SPV1"]
},
"events": [
{
"type":1,
"directionSG":"02",
"directionDET":null,
"distToStopLine":12,
"lineNr":123,
"serviceNr":34,
"companyNr":7,
"journeyNr":18,
"journeyCat":0,
"priorityClass":1,
"punctuality":1,
"status":0,
"speed":32
}
],
"ticks" : 1808
},
"jsonrpc": "2.0"
}
6.4 ReadMeta
This method is used to read meta-data (constants) of TLC Objects.
The requesting application is provided with all parts defined in the Meta{} group.
Request:
| Method: ReadMeta | ||
| Parameter name | Type | Description |
| params | ObjectReference | Reference to the TLC Objects |
Result:
| Parameter name | Type | Description |
| result | ObjectMeta | meta-data of object(s) requested |
Error:
| Parameter name | Type | Description |
| code | Integer | See error codes |
| message | String | optional message |
Examples
{
"method": "ReadMeta",
"params": {
"type":4,
"ids":["D1","D2"]
},
"id": 23,
"jsonrpc": "2.0"
}
{
"result": {
"objects": {
"type":4,
"ids":["D1","D2"]
},
"meta": [
{
"id":"D1",
"generatesEvents":true
},
{
"id":"D2",
"generatesEvents":false
}
],
"ticks":1808
},
"id":14,
"jsonrpc": "2.0"
}
7 Functional use-cases
This chapter contains functional use cases, showing interaction between ITS-A and the TLC Facilities. The interactions are described on a functional level describing
Object state attributes that must be synchronized between the ITS-A and the TLC Facilities as well as Object events required for the functional behaviour.
7.1 Startup
| Name | iTLC startup |
| Description / context | Power up of the TLC Facilities and the ITS-CLA (e.g. assume both are located inside the roadside cabinet). |
| Actor | TLC Facilities |
| Goal | TLC Facilities executes the start up sequence and gives control to the ITS-CLA. |
| Pre-condition(s) | TLC Facilities is switched off (traffic lights are dark) |
| Trigger | Power up (or restart) of the TLC Facilities and the ITS-CLA. |
| ITS-A functions | The ITS-CLA initializes itself. The ITS-CLA connects to the TLC Facilities and authenticates itself (see [REF061]).The ITS-CLA configures the TLC-FI connection (see control state logic 4.7.2) and indicates that it is ready to control the intersection Sets Application.reqControlState = ReadyToControl The ITS-CLA waits for the start control request from the TLC-Facilities Application.controlState = StartControl The ITS-CLA sets the requested states (intersection, outputs and signal groups) and acknowledges that it has control over the intersection Sets Application.reqControlState= InControl |
| TLC Facilities functions | The TLC Facilities initializes the TLC Facilities (and the TLC). The TLC Facilities goes to Standby ( Amber Flashing ) The TLC Facilities waits until the ITS-CLA is ready to control the intersection (see control state logic 4.7.2) Application.controlState = ReadyToControl The Facilities gives the control to the ITS-CLA Sets Application.controlState = StartControl The Facilities waits for the acknowledge from the ITS-CLA Application.reqControlState= InControl AND hands the control the ITS-CLA Sets Application.controlState = InControl |
| Post-conditions | |
| Exception 1 | There is no connection with the ITS-CLA The TLC Facilities selects another (backup) ITS-CLA after a configured Start-up application selection timeout (4.8), or stays in Standby in case no ITS-CLA is ready to control the intersection. |
| Exception 2 | An error is encountered during the configuration of the TLC-FI connection The TLC Facilities selects another (backup) ITS-CLA, or stays in Standby in case no ITS-CLA is ready to control the intersection. |
| Exception 3 | There is connection with the ITS-CLA but the ITS-CLA requests to stay off-line The TLC Facilities selects another (backup) ITS-CLA after a configured start up timeout, or stays in Standby in case no ITS-CLA is ready to control the intersection. |
| End result | The ITS-CLA is in control of the intersection Application.reqControlState= InControl Application.controlState = InControl |
7.2 ITS-CLA in-control
| Name | ITS-CLA in-control |
| Description / context | An ITS-CLA is in control of the intersection. |
| Actor | ITS-CLA and TLC Facilities |
| Goal | The ITS-CLA and TLC Facilities work together to control the intersection. Depending on Intersection.state either the ITS-CLA or the TLC Facilities is in control of the signal groups. The TLC Facilities manages the intersection state based on variety of sources. An exhaustive list of all these sources and the logic used by the TLC Facilities is outside the scope of this document. The ITS-CLA can request the TLC Facilities to change the intersection state by setting Intersection.reqState. |
| Pre-condition(s) | |
| Trigger | Transition from Application.controlState = StartControl to InControl. |
| ITS-A functions | The ITS-CLA issues the following requests: Sets Intersection.reqState Sets SignalGroup.reqState Sets Output.reqState |
| TLC Facilities functions | The TLC Facilities reacts to the requests by setting: Intersection.state (see 7.6 ) SignalGroup.state (see 7.7) Output.state (see 7.8) |
| Post-conditions | |
| Exception 1 | The ITS-CLA goes off-line The TLC Facilities brings the intersection in a defined state and requests a (ITS-CLA) backup application to take control or goes to Standby. |
| Exception 2 | The connection with the ITS-CLA is lost or an error occurs The TLC Facilities brings the intersection to a defined state and requests a (ITS-CLA) backup application to take control or goes to Standby. |
| Exception 3 | A fault occurs in the TLC (for example a lamp fault or supervision) The TLC Facilities brings the intersection to a defined state (Intersection.state) while the ITS-CLA remains the active application (Application.controlState = InControl). |
| End result | The ITS-CLA and the TLC Facilities are in control of the intersection. |
7.3 ITS-CLA handover
| Name | ITS-CLA handover |
| Description / context | The TLC Facilities hands the control over the intersection from one ITS-CLA to another ITS-CLA. |
| Actor | TLC Facilities |
| Goal | TLC Facilities executes a controlled sequence to hand the control from one ITS-CLA to another ITS-CLA. |
| Pre-condition(s) | The ITS-CLA1 is in control of the intersection Application.controlState = InControl AND ITS-CLA2 is ready to control the intersection Application.controlState = ReadyToControl |
| Trigger | A non-exhaustive list of events that can trigger the hand-over in the TLC Facilities: Program selection based on time of day. A manual program selection. ITS-CLA1 is a backup application. |
| ITS-A functions | The ITS-CLA1 detects the stop control request Application.controlState = EndControl AND takes handover request into account Application.reqHandover The ITS-CLA1 releases the control of the intersection Sets Application.reqControlState= ReadyToControl The ITS-CLA2 acknowledges the start control request Sets Application.reqControlState= InControl |
| TLC Facilities functions | The TLC Facilities requests ITS-CLA1 to hand-over the control over the intersection Sets Application.controlState = EndControl Requests handover type selection as defined in Table 9. The TLC Facilities waits for ITS-CLA1 to acknowledge the hand-over. Application.reqControlState= ReadyToControl In case of Cleared Handover, the TLC Facilities brings the intersection to AllRed and waits until the configured all red period is expired. The TLC Facilities requests ITS-CLA2 to take the control over the intersection Sets Application.controlState = StartControl The TLC Facilities waits for ITS-CLA2 to acknowledge the control over the intersection Application.reqControlState= InControl The TLC Facilities acknowledges the InControl request Sets Application.controlState = InControl |
| Post-conditions | |
| Exception 1 | The ITS-CLA1 does not acknowledge the EndControl request Error, after the configured timeout is expired, the TLC Facilities brings the intersection to AllRed and waits until the configured all red period is expired before continuing the process. . |
| Exception 2 | ITS-CLA2 gets disconnected or goes Offline When the sequence to end the control of ITS-CLA1 is completed, the TLC Facilities checks if there is an ITS-CLA that can control the intersection. If there is, the control is handed to this ITS-CLA, if not the TLC Facilities brings the intersection to Standby. |
| End result | The ITS-CLA2 is in control over the intersection. |
Table 9 Handover type selection TLC Facilities decision table
| CONDITIONS | Application.controlState = InControl AND STOP CONTROL | N | Y | Y | Y | Y | Y | Y |
| ITS-CLA2.startCapability = Direct | - | Y | Y | Y | N | N | N | |
| ITS-CLA2.startCapability = PreDefined | - | - | - | - | Y | Y | N | |
| ITS-CLA2.startCapability = Cleared | - | - | - | - | - | - | Y | |
| ITS-CLA1.endCapability = Direct | - | Y | N | N | - | - | - | |
| ITS-CLA1.endCapability = PreDefined | - | - | Y | N | N | Y | - | |
| ITS-CLA1.endCapability = Cleared | - | - | - | Y | - | - | - | |
| ACTIONS | Set ITS.CLA1.reqHandover = Direct | - | √ | |||||
| Set ITS.CLA1.reqHandover = PreDefined | - | √ | √ | |||||
| Set ITS.CLA1.reqHandover = Cleared | - | √ | √ | √ |
7.4 ITS-CLA goes off-line
| Name | ITS-CLA goes off-line |
| Description / context | The ITS-CLA that is in control of the intersection goes off-line. |
| Actor | TLC Facilities |
| Goal | TLC Facilities executes a controlled sequence to hand the control to another ITS-CLA or goes to Standby (fallback). |
| Pre-condition(s) | The ITS-CLA1 is in control of the intersection Application.controlState = InControl |
| Trigger | ITS-CLA1 goes off-line Sets Application.reqControlState= Offline |
| ITS-A functions | ITS-CLA2 to acknowledges the control over the intersection Sets Application.reqControlState= InControl |
| TLC Facilities functions | The TLC Facilities confirms the off-line state (for ITS-CLA1) Sets Application.controlState = Offline The TLC Facilities brings the intersection to AllRed and waits until the configured all red period is expired. If ITS-CLA2 is ready to the control the intersection. Application.reqControlState= ReadyToControl The TLC Facilities requests ITS-CLA2 to take the control over the intersection Sets Application.controlState = StartControl The TLC Facilities waits for ITS-CLA2 to acknowledge the control over the intersection Application.reqControlState= InControl Else The TLC Facilities brings the intersection to Standby. |
| Post-conditions | |
| Exception 1 | ITS-CLA2 gets disconnected or goes Offline The TLC Facilities brings the intersection to Standby. |
| Exception 2 | ITS-CLA1 shortly goes off-line and it is ready to the control intersection again before the all red period is expired AND the TLC Facilities has not selected another ITS-CLA to give control to: The TLC Facilities brings the ITS-CLA1 back to control |
| End result | An ITS-CLA2 is in control over the intersection, or The intersection is in Standby. |
7.5 ITS-CLA requests hand-over
| Name | ITS-CLA requests hand-over |
| Description / context | The ITS-CLA that is in control of the intersection requests to hand-over the control to another ITS-CLA. |
| Actor | TLC Facilities |
| Goal | TLC Facilities executes a controlled sequence to hand the control to another ITS-CLA or goes to Standby (fallback). |
| Pre-condition(s) | The ITS-CLA1 is in control of the intersection Application.controlState = InControl |
| Trigger | ITS-CLA1 requests a hand-over Sets Application.reqControlState= EndControl |
| ITS-A functions | ITS-CLA1 releases control Sets Application.reqControlState= Offline ITS-CLA2 to acknowledges the control over the intersection Sets Application.reqControlState= InControl |
| TLC Facilities functions | The TLC Facilities confirm the stop control request Sets Application.controlState = EndControl The TLC Facilities waits for ITS-CLA1 to acknowledge the hand-over. Sets Application.reqControlState= Offline In case of Cleared Handover, the TLC Facilities brings the intersection to AllRed and waits until the configured all red period is expired. If ITS-CLA2 is ready to the control the intersection. Application.reqControlState= ReadyToControl The TLC Facilities requests ITS-CLA2 to take the control over the intersection Sets Application.controlState = StartControl The TLC Facilities waits for ITS-CLA2 to acknowledge the control over the intersection Application.reqControlState= InControl Else The TLC Facilities brings the intersection to Standby. |
| Post-conditions | |
| Exception 1 | ITS-CLA2 gets disconnected or goes off-line. The TLC Facilities brings the intersection to Standby. |
| Exception 2 | ITS-CLA1 immediately goes to ReadyToControl after it has released the control over the intersection AND the TLC Facilities has not selected another ITS-CLA to give control to: The TLC Facilities activates the ITS-CLA1 instead of ITS-CLA2 |
| End result | An ITS-CLA2 is in control over the intersection OR The intersection is in Standby. |
7.6 Change the intersection state
| Name | Change the intersection state | ||||||||||||||||||
| Description / context | The ITS-CLA decides by its internal logic that the Intersection it controls shall change state | ||||||||||||||||||
| Actor | ITS-CLA | ||||||||||||||||||
| Goal | ITS-CLA changes the Intersection.reqState | ||||||||||||||||||
| Pre-condition(s) | ITS-CLA is in-control of the intersection Application.controlState = InControl OR Application.controlState = EndControl | ||||||||||||||||||
| Trigger | ITS-CLA internal logic determines that the intersection must change state Sets Intersection.reqState = <new state> | ||||||||||||||||||
| ITS-A functions | The ITS-CLA monitors the Intersection.State When Intersection.reqState != Control AND Intersection.State = Control Assume that the Facilities will take over the control of the signal groups When Intersection.reqState = Control Update SignalGroup.reqState to prepare for transition from Intersection.State != Control to Intersection.State = Control When Intersection.reqState = Control AND Intersection.State = Control Control signal groups as defined in use-case 7.7 Note: The ITS-CLA should be aware that the requested signal group state is ignored by the TLC Facilities when Intersection.state != Control. Note: The ITS-CLA should be aware that the TLC Facilities may be configured to not follow the Intersection state requests from an ITS-CLA in-control due to a higher priority source. In this case the ITS-CLA shall continue controlling outputs if it can, otherwise it shall request to handover control as defined in use-case 7.5 | ||||||||||||||||||
| TLC Facilities functions | The Facilities monitors the Intersection.reqState. When Intersection.reqState = Control AND Intersection.state = Control Follow signal group requests Follow Output requests When Intersection.reqState != Control AND Intersection.state = Control AND TLC Facilities allows the ITS-CLA to control the Intersection.state Stop following signal group requests Follow Output requests Transition to Intersection.reqState. Update Intersection.state When Intersection.reqState = Control AND Intersection.state != Control Follow Output requests Transition to Control state Update Intersection.state | ||||||||||||||||||
| Post-conditions | Intersection.state is <new state> Application.controlState is InControl | ||||||||||||||||||
| Exception 1 | TLC Facilities doesn t react to the Intersection.reqState within adequate time ITS-CLA may see this as a functional error and take its own measures. Request to handover (7.3) Go to Offline (7.4) Deregistering from the TLC-FI. | ||||||||||||||||||
| Exception 2 | Invalid requested intersection state by the ITS-CLA The TLC Facilities shall verify the requested intersection control states against the following table. In case the requested state is not allowed the requested state shall be ignored. The following states can be requested by the ITS-CLA:
| ||||||||||||||||||
| End result | Intersection has changed state as expected |
7.7 Change the signal group state
| Name | Change the signal group state | ||||||||||||||||||||||||||||||||||||
| Description / context | An ITS-CLA is in control of the signal groups of an intersection. This use case describes required interactions between the ITS-CLA and TLC for the ITS-CLA to change signal group states. | ||||||||||||||||||||||||||||||||||||
| Actor | ITS-CLA | ||||||||||||||||||||||||||||||||||||
| Goal | Change the external state of a signal group | ||||||||||||||||||||||||||||||||||||
| Pre-condition(s) | ITS-CLA is in-control of the intersection Application.controlState = InControl OR Application.controlState = EndControl | ||||||||||||||||||||||||||||||||||||
| Trigger | ITS-CLA internal logic | ||||||||||||||||||||||||||||||||||||
| ITS-A functions | Requests a new signal group state Sets SignalGroup.reqState= <new signal group state> Note: TLC Facilities executes the requested signal group states that are present in the TLC Facilities when it enters Intersection.state = Control | ||||||||||||||||||||||||||||||||||||
| TLC Facilities functions | ITS-CLA is in control AND Intersection.state = Control Monitors changes to SignalGroup.reqState while ITS-CLA is in control of the intersection.When it detects a change itexecutes signal group state transitions respecting: Signal group type allowed State transitions Signal group minimum timing Clearance times against conflicting signal groups Duration of intermediate states such as red/amber and amber During the state transitions, the TLC Facilities Updates SignalGroup.state object to reflect the actual state. ITS-CLA is in control and Intersection.state != Control Bring the signal group to a defined state depending on the intersection state. Signal group state transitions are executed respecting: Signal group type allowed State transitions Signal group minimum timing Clearance times against conflicting signal groups Duration of intermediate states such as red/amber and amber During the state transitions, the TLC Facilities Updates SignalGroup.state object to reflect the actual state. Note: The SignalGroup.state is in general updated to the state requested by the SignalGroup.reqState. When the TLC Facilities executes a state change as part of a STOP / GO control, to avoid maximum time violations or the requested protected / permissive state doesn t match the configured, the following rules are used:
During AllRed or switch on, the following states are reported For states not explicitly requested by the ITS-CLA, when the TLC Facilities executes a state change to avoid maximum time violations or goes to AllRed, the SignalGroup.state is mapped to the following states:
| ||||||||||||||||||||||||||||||||||||
| Post-conditions | n/a | ||||||||||||||||||||||||||||||||||||
| Exception 1 | Violation of minimum signal group timing The TLC Facilities receives signal group requested states that would lead to violation of SG state minimum times or clearance times if executed by the TLC Facilities. The cause may be a difference in the configured signal group timing, a functional failure in the application or network conditions. The TLC Facilities shall prevent violation of the minimum timing: The TLC Facilities shall keep a signal group in a control state until the configured minimum time for the control state is expired The TLC Facilities shall keep a signal group in Red until the clearance time with all conflicting signal groups is expired | ||||||||||||||||||||||||||||||||||||
| Exception 2 | Violation of maximum signal group timing The TLC Facilities receives signal group requested states that would lead to violation of SG state maximum times if executed by the TLC Facilities. The cause may be a difference in the configured signal group timing, a functional failure in the application or network conditions. TLC Facilities shall prevent violation of the maximum timing: If the maximum amber time is expired the TLC Facilities shall make the signal group red. If the maximum red/amber time is expired the TLC Facilities shall make the signal group green. If the maximum green flashing time is expired the TLC Facilities shall make the signal group amber or red (depending on the configuration). Note: The TLC Facilities does not check for the maximum timing in the state red and green. | ||||||||||||||||||||||||||||||||||||
| Exception 3 | Invalid signal group state transitions The TLC Facilities receives a signal group requested state for which there is no transition possible from the current signal group state. The TLC Facilities shall verify the requested signal group states against the current states according to the following table. In case the requested state is not allowed the requested state should be ignored. A = allowed, - = ignore, E = Error
Note: Violation of the maximum timing leads (exception 2) to a situation that the actual signal group state and requested signal group state are out-of-sync. | ||||||||||||||||||||||||||||||||||||
| Exception 4 | ITS-CLA requests conflicting signal groups An ITS-CLA may request conflicting signal groups to be Green at the same time as part of an atomic update. The TLC Facilities shall: treat this as a malfunctioning application remove the application from control Inform the application that it is in failure The ITS-CLA shall Monitor such application failures Don t attempt to go back to control before the failure has been corrected | ||||||||||||||||||||||||||||||||||||
| Exception 5 | ITS-CLA is not in the controlState StartControl, InControl or EndControl The TLC Facilities shall: Set the controlState to Error Send a SessionEvent with SessionEventCode = UpdateStateFailedIncorrectControlState, optionally with additional information about the cause of the failure in the SessionEventInformation attribute Close the connection | ||||||||||||||||||||||||||||||||||||
| Exception 6 | ITS-CLA is not in-control of the Intersection to which the SignalGroup belongs The TLC Facilities shall: Set the controlState to Error Send a SessionEvent with SessionEventCode = UpdateStateFailedIncorrectIntersection, optionally with additional information about the cause of the failure in the SessionEventInformation attribute Close the connection | ||||||||||||||||||||||||||||||||||||
| End result | Signal group has changed its State and the ITS-A is updated with this information. |
7.8 Determine protected or permissive
| Name | Determine protected of permissive | ||||||||||||||
| Description / context | A signal group is configured in the TLC as protected or permissive, however this information is not published as part of the signal group meta data. An ITS-CLA can use the logic below to determine how the TLC is configured. | ||||||||||||||
| Actor | ITS-CLA | ||||||||||||||
| Goal | ITS-CLA knows for each signal group the protected/permissive configuration from the TLC. | ||||||||||||||
| Pre-condition(s) | ITS-CLA is not in-control of the intersection | ||||||||||||||
| Trigger | Application.controlState = StartControl | ||||||||||||||
| ITS-A functions | The ITS-CLA sets the ProtectedPermissiveState for all signal groups to Unknown. The ITS-CLA runs its algorithm to determine the state of the traffic lights (this algorithm is out of the scope of this specification). The ITS-CLA uses the following table to request GREEN:
The ITS-CLA uses the following table to determine the ProtectedPermissiveState based on SignalGroup.state (i.e. the state published by the TLC).
This use case ends when the ProtectedPermissiveState is known for all signal groups. | ||||||||||||||
| TLC Facilities functions | The functions of the TLC facilities are specified in paragraph 7.7 Change the signal group state. | ||||||||||||||
| Post-conditions | n/a | ||||||||||||||
| End result | The ProtectedPermissiveState is known (in the ITS-CLA) for all signal groups. |
7.9 Control exclusive outputs
| Name | Control exclusive outputs |
| Description / context | An ITS-CLA is in-control of an Intersection. This intersection contains several outputs used for signalling. These outputs coupled to a single Intersection are exclusive outputs for the ITS-CLA in control of that Intersection. This use-case describes activation of these outputs. |
| Actor | ITS-CLA |
| Goal | Change the state of an exclusive output |
| Pre-condition(s) | ITS-CLA is in-control of the Intersection Application.controlState = StartControl OR Application.controlState = InControl OR Application.controlState = EndControl |
| Trigger | ITS-CLA internal logic |
| ITS-A functions | ITS-CLA changes the output: Sets the Output.reqState |
| TLC Facilities functions | Monitors changes to Output.reqState, while ITS-CLA is in control of the intersection. Executes the Output state change according to reqState. Updates Output.state accordingly |
| Post-conditions | Output.state is changed. |
| Exception 1 | ITS-CLA is not in the controlState StartControl, InControl or EndControl. The TLC Facilities shall: Set the controlState to Error Send a SessionEvent with SessionEventCode = UpdateStateFailedIncorrectControlState, optionally with additional information about the cause of the failure in the SessionEventInformation attribute Close the connection |
| Exception 2 | ITS-CLA is not in-control of the Intersection to which the (exclusive) Output belongs The TLC Facilities shall: Set the controlState to Error Send a SessionEvent with SessionEventCode = UpdateStateFailedIncorrectIntersection, optionally with additional information about the cause of the failure in the SessionEventInformation attribute Close the connection |
| Exception 3 | The ITS-CLA gets disconnected. TLC Facilities sets the output to a configured default value. |
| Exception 4 | The ITS-CLA gets off-line. TLC Facilities sets the output to a configured default value. |
| End result | Output changed its state according to request by ITS-CLA |
7.10 Control non-exclusive outputs
| Name | Control non-exclusive outputs |
| Description / context | An output is coupled to the TLC, the output can be controlled by any ITS Provider or Control Application, there is no resource management of this output. As such it is defined as a non-exclusive or normal output. This use-case describes how this output is changed. |
| Actor | ITS Provider or Control Application (ITS-A) |
| Goal | Change the state of a non-exclusive output |
| Pre-condition(s) | The Output is configured as a non-exclusive output. The ITS-A has subscribed to the output. |
| Trigger | ITS-A Internal logic |
| ITS-A functions | ITS-A changes the output: Sets the Output.reqState |
| TLC Facilities functions | Monitors changes to Output.reqState. When it detects a change: Executes the Output state change according to reqState. Updates Output.state accordingly |
| Post-conditions | Output.state is changed. |
| Exception 1 | The ITS-A sets Output.reqState for an output without a subscription TLC Facilities ignores the request. |
| Exception 2 | Multiple ITS-A s are writing different requested states to the same output The latest state written is used at any time |
| Exception 3 | The ITS-A that is controlling the output gets disconnected After a timeout, TLC Facilities sets the output to a configured default value unless it is controlled by a different ITS-A |
| End result | Output changed its state. |
7.11 Obtain updates of TLC State Objects
| Name | Obtain updates of TLC State Objects |
| Description / context | An ITS-A needs to monitor the state of a specified object type. For this it places a subscription for the object type and which object it wants to monitor. |
| Actor | ITS-A |
| Goal | ITS-A is kept up-to-date of the TLC Object s state and events |
| Pre-condition(s) | ITS-A is authenticated and authorised as an ITS-A Application session state = Connected |
| Trigger | internal logic |
| ITS-A functions | ITS-A subscribes to being updated of the state of TLC Objects using the SubscribeState method ITS-A monitors the result of this request: The result contains the current state of the objects. ITS-A takes the result of this request and updates its local copy. After a successful subscription has been placed, ITS-A monitors all updates to the objects: Updates State attributes keeping its local copy up-to-date Handles Generated Events |
| TLC Facilities functions | Monitors Object subscriptions placed by ITS-A s. When an ITS-A places a places a subscription to an Object: Checks if the TLC Object Type is valid Stores the list of object identifiers the ITS-A subscribes to Provides as a response the current state of the subscribed objects While a subscription is active and the ITS-A session is active: Provides the ITS-A with changed objects (attributes) Provides the ITS-A with Events generated by the Object Note: The ITS-CLA should be aware that the TLC Facilities replaces any existing subscription to an Object Type. |
| Post-conditions | |
| Exception 1 | An ITS-A places a subscription on a TLC Object Type it is not allowed to read Reject the complete subscription Respond with error |
| Exception 2 | An ITS-A places a subscription on an invalid object identifier Reject the complete subscription, including any identifiers that may have been valid Respond with error. |
| End result | ITS-A is kept up-to-date on the state of the TLC Objects it is interested in. |
7.12 Update TLC State Objects by an ITS-A
| Name | Obtain object updates |
| Description / context | An ITS-A executes functions via the TLC. It does this by updating (attributes of) TLC State objects. The ITS-A requests to update an attribute of a TLC State object for which it is authorised. For a generic object, this attribute can be identified as TLCStateObject.attribute. The procedure is the same for all types of TLC State Object attributes. This can for instance be: Update the SignalGroup.reqState by an ITS-CLA Update the Output.reqState by an ITS-PRA |
| Actor | ITS-A |
| Goal | Change of the TLC State object s attribute. |
| Pre-condition(s) | ITS-A must be subscribed to the TLCStateObject ITS-A is allowed to change the attribute TLCStateObject.attribute = <old value> |
| Trigger | |
| ITS-A functions | ITS-A changes the object value: Sets the TLCStateObject.attribute = <new value> ITS-A monitors any relevant objects to check if the change has had the desired functional effect. |
| TLC Facilities functions | TLC Facilities monitors changes to attributes that can be updated by ITS-A s. When TLCStateObject.attribute is changed Updates the TLCStateObject.attribute to <new value> Performs any functional action(s) required after the update Updates any listening ITS-A s with the changes following use-case 7.11 Possibly, the actions leads to update of other attributes of the TLCStateObject. Updates any relevant related attributes of TLCStateObject Executes use-case 7.11 to update the related attributes in the ITS-A. |
| Post-conditions | Attribute has been changed. TLCStateObject.attribute = <new value> |
| Exceptions | |
| End result | Attribute has been changed. |
7.13 Inform on configuration
| Name | Inform on configuration |
| Description / context | Provide configuration information of the TLC. |
| Actor | ITS-CLA and TLC |
| Goal | The ITS-CLA knows the configuration information of the TLC. |
| Pre-condition(s) | The TLC facilities is initialized |
| Trigger | Power up (or restart) of the ITS-CLA |
| ITS-A functions | The ITS-CLA initializes itself, connects to the TLC facilities and authenticates itself. The ITS-CLA reads the TLCFacilities(1) meta data. The ITS-CLA extracts the configuration information, meaning the companyname, certifiedName, certifiedVersion and version, from TlcFacilities.info |
| TLC Facilities functions | Provide the TLCFacilities(1) meta data when requested. |
| Post-conditions | n/a |
| Exception 1 | Older version TLC (i.e. TLC that does not support configuration information) The ITS-CLA shall handle this as TLC configuration information not available. |
| Exception 2 | Invalid configuration information The TlcFacilities.info is valid when companyname, certifiedName, certifiedVersion and version are provided. The ITS-CLA shall handle invalid configuration information as TLC configuration information not available |
| End result | The ITS-CLA has retrieved the configuration information of the connected TLC. |
8 Exception handling
This chapter focuses on exceptions which can occur and describes how ITS-A and/or Facilities shall detect the exception and respond to it. This chapter does not address exceptions caused by a specific protocol implementation, but addresses implementation-independent exceptions only.
8.1 Network
| ID | Title | Description |
| 1 | Regular communication problems | As result of communication problems the TCP connection between ITS-CLA and the TLC is closed regularly. As result ITS-CLA re-connects and asks the TLC to switch back to the ITS-CLA control mode. If this happens too often the traffic at the intersection will be disturbed due to the regular transitions in the control mode. In worst case scenario s some signal groups will not show green for a long period of time (e.g. resulting in red negation by annoyed drivers). To prevent this (unsafe) situation ITS-CLA implements an exponential back off algorithm (e.g. time between re-connect will become longer each time a failure occurs). The TLC Facilities must allow a traffic application (backup or ITS-CLA) control for at least 180 seconds. |
8.2 Session
| ID | Title | Description |
| 1 | Heartbeat fails for an ITS-CLA | When heartbeat fails, the network or processing has failed to recover within the expected time. Both the ITS-CLA and the TLC-FI monitors the heartbeat and regards the session as lost (this exception is defined in [REF061]. The TLC Facilities shall additionally Select a new ITS-CLA (alternatively) select a backup application (alternatively) go to intersection standby state The ITS-CLA shall Reconnect and monitor the heartbeat for at least the alive timeout interval of 2.5 * 2 seconds (as defined in [REF061]) before attempting to regain control of the intersection. |
| 2 | TLC Facilities receives an UpdateState for an attribute the ITS-A does not have write access due to its ApplicationType | The TLC Facilities shall: Send a SessionEvent with SessionEventCode = UpdateStateFailedIncorrectApplicationType, optionally with additional information about the cause of the failure in the SessionEventInformation attribute |
8.3 Timing
| ID | Title | Description |
| 1 | Deviating calendar time (UTC) | The calendar time in an ITS-A can deviate from the calendar time in the TLC Facilities. There may be time jumps in the calendar time (e.g. user sets the clock, leap-seconds, synchronization by external system, etc.). Both the Facilities and ITS-A shall use the calendar time for informational purposes only. To measure or control short time periods (like the timing of the signal groups or a detector occupancy) the time-ticks shall be used. When a peer uses the calendar time in its processing, it shall take a maximum deviation into account before taking appropriate exception measures. |
8.4 Intersection control
| ID | Title | Description |
| 1 | TLC doesn't follow ITS-CLA control requests | ITS-CLA shall monitor the effectiveness of its requests for activation of outputs and intersection states. An ITS-CLA shall Determine if the TLC follows with sufficient quality Keep track of failures to follow Remove the ITS-CLA from control if the quality is not sufficient |
9 Compatibility
The compatibility described in this section applies to the following (older) TLC-FI protocol versions.
- Protocol version 1.1.0
- Protocol version 1.1.1
9.1 ITS-A (2.0.0) versus TLC (1.1.x)
This combination of protocol versions is not compatible, because:
- reqPredictions and predictions are mandatory attribute of the SignalGroup object in version 1.1.x.
- version 1.1 supports variables.
- certifiedName, certifiedVersion and version are not available in version 1.1.x and mandatory attributes of the FacilitiesInformation object in version 2.0.0.
A TLC Facilities that implements protocol version 1.1.x does not support protocol negotiation.
ITS-A that supports 2.0.0 and 1.1.x can use protocol negotiations to establish a connection with TLC Facilities version 1.1.x. The ITS-A shall register with:
- RegistrationRequest.supportedVersions=(2,0,0),(1,1,1),(1.1.0).
- RegistrationRequest.version=(1.1.0)
The TLC Facilities will:
- (Silently) ignore RegistrationRequest.supportedVersions
- Replies with RegistrationResponse.version=(1.1.1) or (1.1.0)
The ITS-A shall then use protocol version 1.1.1 or 1.1.0, meaning that:
- The ITS-A will send an empty reqPredictions (i.e. reqPredictions :null or reqPredictions :[])
- The ITS-A will ignore the predictions send by the TLC Facilities
- The ITS-A will ignore information from the TLC Facilities regarding variables.
N.B. An ITS-A that only supports version 2.0.0 (or higher) shall close the connection with the TLC Facilities when RegistrationResponse.version=(1.1.1) or (1.1.0)