iVRI Interface RIS-FI, IDD RIS-FI
Datum besluit SC 14-03-2023
D3047-4 / Version 2.0.2 (=incl. [CO-53])
D3047-4 / Version 2.0.2 (=incl. [CO-53])
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
Version filename : D3047-4_IDD RIS-FI_1.4.0.pdf
Contents
1 – Introduction
1.1 – Overview
1.2 – Version
1.3 – Purpose and scope
1.4 – Advice for the reader
1.5 – Document conventions
1.1 – Overview
1.2 – Version
1.3 – Purpose and scope
1.4 – Advice for the reader
1.5 – Document conventions
2 – References
3 – Acronyms, abbreviations and concepts
4 – Functional description
4.1 – General
4.2 – LDM
4.3 – Message services
4.4 – RIS-FI
4.4.1 – General
4.4.2 – Opening and closing a connection
4.4.3 – Object ownership
4.4.4 – Creating a new object
4.4.5 – Updating an existing object
4.4.6 – Deleting an existing object
4.4.7 – Reading objects
4.4.8 – Monitoring objects
4.5 – Filtering
4.6 – Map-Matching
4.1 – General
4.2 – LDM
4.3 – Message services
4.4 – RIS-FI
4.4.1 – General
4.4.2 – Opening and closing a connection
4.4.3 – Object ownership
4.4.4 – Creating a new object
4.4.5 – Updating an existing object
4.4.6 – Deleting an existing object
4.4.7 – Reading objects
4.4.8 – Monitoring objects
4.5 – Filtering
4.6 – Map-Matching
5 – RIS-FI Objects
5.1 – Introduction
5.2 – Object types
5.3 – Protocol-version
5.4 – Base
5.5 – Cause codes
5.6 – RISFacilities
5.7 – ItsStation
5.8 – ItsEvent
5.9 – Intersection
5.10 – SignalGroup
5.11 – PrioritizationRequest
5.12 – ActivePrioritization
5.13 – Signage
5.14 – Protocol objects
5.1 – Introduction
5.2 – Object types
5.3 – Protocol-version
5.4 – Base
5.5 – Cause codes
5.6 – RISFacilities
5.7 – ItsStation
5.8 – ItsEvent
5.9 – Intersection
5.10 – SignalGroup
5.11 – PrioritizationRequest
5.12 – ActivePrioritization
5.13 – Signage
5.14 – Protocol objects
6 – Methods
6.1 – CreateEvents
6.2 – UpdateObjects
6.3 – TerminateEvents
6.4 – RequestObjects
6.5 – SubscribeObjects
6.6 – NotifyObjects
6.7 – UnsubscribeObjects
6.1 – CreateEvents
6.2 – UpdateObjects
6.3 – TerminateEvents
6.4 – RequestObjects
6.5 – SubscribeObjects
6.6 – NotifyObjects
6.7 – UnsubscribeObjects
7 – Protocol error handling
7.1 – Error codes
7.1 – Error codes
8 – Functional use-cases
8.1 – Monitoring of traffic
8.2 – Bus priority handling
8.2.1 – Priority handling based on CAM
8.2.2 – Priority handling based on SRM
8.3 – Create an ItsEvent
8.4 – Update an ItsEvent
8.5 – Delete an ItsEvent
8.6 – Monitoring of events
8.7 – Inform on the signalling status
8.1 – Monitoring of traffic
8.2 – Bus priority handling
8.2.1 – Priority handling based on CAM
8.2.2 – Priority handling based on SRM
8.3 – Create an ItsEvent
8.4 – Update an ItsEvent
8.5 – Delete an ItsEvent
8.6 – Monitoring of events
8.7 – Inform on the signalling status
9 – Exception handling use-cases
9.1 – Invalid request
9.2 – Invalid parameters
9.3 – Request could not be completed
9.4 – Not authorized
9.5 – Invalid Object reference
9.1 – Invalid request
9.2 – Invalid parameters
9.3 – Request could not be completed
9.4 – Not authorized
9.5 – Invalid Object reference
Appendix A Country specific public transport encoding
Appendix B
Appendix C
Intersections
Names
Intersections
Signal Groups
Intersections
Signal Groups
ITF naming
Limitations
Conventions
Limitations
Conventions
Data mapping examples
Single conflict area
Multiple conflict areas controlled as one logical intersection
Multiple conflict areas controlled by separate logical controllers
Single conflict area
Multiple conflict areas controlled as one logical intersection
Multiple conflict areas controlled by separate logical controllers
1 Introduction
1.1 Overview
The iTLC architecture combines the ability to control traffic lights and the ability to communicate to ITS stations such as cars, busses etc. It allows external ITS applications to control or monitor traffic lights via the TLC-FI interface. It also allows ITS applications to monitor or inform ITS stations via the RIS-FI interface.
[ link ]
Figure 1 RIS-FI in system over view
The scope of this document is limited to the RIS-FI interface, the faded elements shown in Figure 1 are not in the scope of this document.
The RIS-FI is the interface between the Roadside ITS Station (RIS) and the (external) ITS applications. There is no (technical) interface defined in the ETSI standard, other than a high level description of the LDM and its functionality. However, the underlying ETSI standards regarding ITS G5 messages have been followed
The RIS facilities can communicate with other ITS stations in the neighbourhood via ITS G5 messages. The information received from other ITS stations via ITS G5 messages, and the information received from ITS applications via the RIS-FI interface, is used to assemble a local view on the traffic situation.
Communication can also be performed through other communication media (such as mobile phones). This document does not prescribe any media to be used, only the information that needs to be communicated. However, in the presented examples it is assumed that ITS G5 is used.
Communication can also be performed through other communication media (such as mobile phones). This document does not prescribe any media to be used, only the information that needs to be communicated. However, in the presented examples it is assumed that ITS G5 is used.
Information provided by ITS applications via the RIS-FI is shared with the other ITS stations using ITS G5 messages and information received from other ITS stations via ITS G5 messages is shared with subscribed ITS applications using the RIS-FI.
The RIS-FI as described in this document tries to hide the radio level details for the ITS applications, so that these application can implement their use cases more easily.
1.2 Version
This document describes the protocol version 2.0.1 of the RIS-FI.
This version assumes the implementation of the Generic Facilities Interface IDD defined in [REF061].
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 RIS-FI with respect to
- Functional behaviour.
- RIS 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 Advice for the reader
It is advised that the reader understands the contents of the following document:
- iTLC Architecture as described in [REF060]
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 RIS object type Intersection, which has an attribute status, this is identified as Intersection.status.
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
| CAM | Cooperative Awareness Message. |
| 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. |
| DENM | Decentralized Environmental Notification Message. |
| ETSI | European Telecommunications Standards Institute |
| 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 G5 | ITS messages broadcasted over the 5GHz radio band supporting GeoNetworking, as specified by ETSI. |
| 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. |
| IVI | In Vehicle Information (Message on traffic signs and other related traffic information). |
| IVERA | Management protocol for traffic light controllers in the Netherlands (An implementation of a TMS-IF). |
| iVRI | See iTLC. |
| MAP | Message providing the topology of an area. |
| OBU | On-Board Unit |
| RIS | Roadside ITS Station |
| RSU | Roadside Unit, usually the radio modem. |
| SPAT | Signal Phase and Timing (message providing traffic light information). |
| SRM | Signal Request Message; a priority request. |
| SSM | Signal Status Message; the state of a priority request. |
| TLC | Traffic Light Controller; controls the signals of one or more intersections. |
| TMS | Traffic Management System. |
| TMS-IF | TMS Interface, an interface used by a TMS to manage ITS Applications. |
| UTC | Coordinated Universal Time. |
Concepts
| Traffic Control Application | Application that implements a traffic control algorithm and is able to request signal group states. |
| ITS Control Application | A Traffic Control Application that uses TLC- and/or RIS-interfaces. |
| ITS Application | An application that 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:
|
| RIS Facilities | Component providing facilities of a RIS to users (internal and/or external). |
4 Functional description
4.1 General
The RIS consist of two main functional parts and an interface to access this functionality:
- Local Dynamic Map (LDM)
- Message services
- RIS Facilities Interface (RIS-FI)
[ link ]
Figure 2 RIS system overview
4.2 LDM
The Local Dynamic Map (LDM) holds the overall view on the traffic state in the area that the Roadside ITS Station (RIS) covers. The LDM contains a set of objects, each with its own set of attributes that represent real-world objects such as cars or traffic lights.
The objects have a limited lifetime and will be deleted if they are not regularly updated. The different type of objects available in the LDM are described in section 5.
All the object instances in the LDM have at least a location, which can be related to the topology, and a timestamp of the last update.
The objects in the LDM are created and updated from two sources:
- C-ITS messages received from other ITS stations via either UDAP-FI or directly via for example DSRC/CV2X.
- Objects created or updated by ITS applications via the RIS-FI.
The topology is provided by an external source in the format described in [REF096]. It cannot be configured through the RIS-FI.
4.3 Message services
The message services in the RIS are responsible for the transmission and reception of the ITS G5 messages.
Currently the following messages are supported:
- Cooperative Awareness Messages (CAM), which contain information about the ITS stations such as type, position, speed etc.
- Decentralized Environmental Notification Messages (DENM), which contains information about the occurrence of potential dangerous (traffic) situations.
- Signal Phase And Timing (SPAT) messages, which contain information on the status of a traffic light controller and its signal groups at an intersection.
- MapData (MAP) messages, which contain the topology of the area associated with the RIS.
- Signal Request Messages (SRM), which are sent by a vehicle to the RSU to request priority at a signalized intersection.
- Signal Status Messages (SSM), which are sent by an RSU to inform vehicles about the status and activation of previously made prioritization requests.
- In Vehicle Information (IVI) messages, which contain signage information; e.g. speed limits, traffic signs etc.
The information needed for the transmission of these message is provided by ITS applications in the form of objects (see section 5), configured in the RIS. The information that is received from other ITS stations will be made available through the same objects.
4.4 RIS-FI
4.4.1 General
ITS applications can interact with the RIS using the RIS Facilities Interface (abbreviated to RIS-FI).
The base of the RIS-FI consist of an Object model with which ITS applications can interact. These objects represent concepts that are relevant in the RIS environment.
ITS applications can create, update and read these objects when its security profile allows this. ITS application can also delete the objects they have created.
ITS applications can ask to be informed on changes made to the objects that match a set of criteria. A notification is then given to the ITS application when one or more objects are changed that match the selection criteria.
Created objects are not persistent at the RIS. When the RIS is restarted ITS applications must re-create their objects if they are necessary.
When an ITS application creates or updates an object, the related ITS G5 message will be sent by the corresponding message service and the object is stored in the LDM.
The precise timing and encoding of the message will be determined by the RIS, based on the object and the requirements of the radio channel. Consequently, if a RIS-FI based object has been accepted by the RIS this does not necessarily imply that the radio message has been transmitted, due to the inherent nature of this transmission medium.
Therefore it is not possible to provide feedback to the ITS application whether or not the message is actually sent. The LDM will however persist in transmitting messages for the duration of their validity.
4.4.2 Opening and closing a connection
The procedures for opening, maintaining and closing a connection to the RIS-FI are described in detail in [REF061].
The message size produced by the RIS-FI could exceed the 32 kBytes described in [REF061]. The RIS-FI does not provide a means to split messages in smaller parts.
Because no SessionObject is defined for the RIS-FI, no SessionEvents can be sent by the RIS Facilities when closing the connection because of a server shutdown or other RIS Facilities triggered events as prescribed by [REF061].
4.4.3 Object ownership
Objects are owned by the system that created them. For objects created based on incoming ITS G5 messages the owner will be the RIS. Also the objects created by configuration (such as topology) will be owned by the RIS.
Objects created by an ITS application will be owned by that application, i.e. they are linked to the ApplicationUsername of the application.
For objects that are owned by the RIS, an ITS application should get the right authorizations from the RIS to be able to modify these objects (see 4.4.5 below).
4.4.4 Intersection ownership
The intersection objects and associated signalgroup objects are owned by the RIS. An ITS-CLA shall claim ownership (via Intersection.owner) before it writes to an intersection of signal group object. The ownership ends when:
- The ITS-CLA releases the ownership, or
- The ITS-CLA deregisters, or
- The ITS-CLA disconnects, or
- An alive timeout occurs, causing the session with the ITS-CLA to disconnect.
When ownership ends the intersection and associated signal groups will be reset to the default state by the Facilities and the (i.e. 'noValidSPATisAvailableAtThisTime' bit shall be set for the corresponding intersection.).
Facilities will respond with ProtocolErrorCode=NotAuthorized(1) when an ITS-CLA, that does not have the ownership, writes to an intersection or signalgroup object.
4.4.5 Creating a new object
In general, each newly created object in the LDM has a reference position and a validity time. The validity time of an object is either configured in the RIS or is an attribute of the object itself. For example; ItsStation objects will have a validity determined by the LDM based on configuration, SignalGroup and ItsEvent objects have an attribute to specify the validity.
Currently only ItsEvent objects can be created by an ITS application. The RIS-FI will return an ObjectID if creation was successful.
4.4.6 Updating an existing object
When updating an existing object, the ObjectID and the (writable) attributes to be updated must be provided. Not all object data has to be provided, according to the following rules:
- If an attribute is provided, its value will be updated.
- If an attribute is not provided, the current value will remain.
- If an optional attribute is provided with a null value, the attribute will be removed.
An ITS application can only update objects it owns, e.g. objects it created. However, ITS applications can get credentials assigned during the authentication process that allow these applications to write (update) the state of configured objects, such as the signal group states, intersection states and prioritization states.
4.4.7 Deleting an existing object
An ITS application can request to delete an object identified by its ObjectID from the LDM.
If the object exists and it is owned by the application, it will be deleted from the LDM.
4.4.8 Reading objects
ITS applications can request the LDM for objects of a given object types that (optionally) match certain selection criteria (see also section 4.5). The LDM will return a set of matching objects, or an empty set if none can be matched to the selection criteria.
4.4.9 Monitoring objects
ITS applications can monitor objects by taking a subscription on objects of an object type that (optionally) match certain selection criteria (see also section 4.5). By default, changes made on objects that match the selection criteria will trigger a notification of these objects to be sent to the subscriber. However, an ITS application can request, with a subscription, to be notified periodically instead of event-based. In this case all matching objects will be returned after each period.
4.5 Filtering
The top level RIS-FI objects can be requested directly with the method RequestObjects or can be monitored by taking a subscription with the method SubscribeObjects for the corresponding object type.
The set of objects returned as a result of the request or in a notification to a subscriber can be filtered by applying selection criteria. If no filter is given, all objects of the requested object type will be returned.
This filter mechanism is meant as a pre-selection on the objects returned by the RIS to the ITS application. Therefore, the filter capabilities are limited to comparison on simple attribute types; e.g. Integer, Float, Boolean and String. The existence of (optional) attributes can be filtered by applying a null-check. There is a maximum of two attributes that can be used in a filter, which is sufficient for the use cases presented in this document.
More complex filtering has to be done by the ITS application itself and is not provided by the RIS-FI as a compromise between performance and complexity.
4.6 Map-Matching
Received Cooperative Awareness Messages (CAM) will result in the creation (or update) of an ItsStation object. This object contains an attribute that holds the map-matching result.
The RIS performs map-matching by taking the reference position of the ITS station, and the accuracy of this position1)See [REF075], paragraph 5.7.2 for more details., and projects that onto the intersection topology, as shown in Figure 3. If a CAM message is older than a previous message of the same ITS station it shall be discarded by the RIS and not provided on the RIS-FI interface. In addition, if the timestamp of a message is older than 2s or more than 500ms in the future it shall be discarded too.
[ link ]
Figure 3 Projection of a vehicle onto the topology
Next only the Lanes that have the same (driving) direction as the ITS station and where the vehicle type of the ITS station is allowed are considered. For these lanes the distance to the stop line (or the start of the lane) and the path offset are calculated. Distance to the start of the lane shall be indicated as a positive value, i.e. in upstream direction from the stop line on ingress lanes and in downstream direction on egress lanes.
The path offset is the distance between the ITS station and the orthogonal projection on the path describing the Lane, as shown inFigure 4.
Multiple Map-Match result may be returned for each calculated offset that is within the, at the RIS configured, maximum offset. The maximum offset is at least 20 meters. In case an ITS station is Map-Matched to multiple lanes with varying probability, these Map-Matches shall be sorted in descending order and the Map-Match with the highest probability (i.e. the smalles offset) shall be provided first.
[ link ]
Figure 4 Path offset and distance of a Map-Match
4.7 State and predictions
Please refer to [REF060], section 7.1 for the processing of signal group states and timing by the ITS-CLA. And section 8.8 outlines the functional description in a use case.
4.8 Abnormal lights
Please refer to [REF060], section 7.2 for providing the signal group states by the ITS-CLA in case of abnormal lights .
4.9 iTLC configuration information
The manufacturer name, product name and version as listed on the iTLC certificates of the active iTLC components (TLC, RIS, ITS control application) shall be collected in the RIS so that it can be forwarded to UDAP.
The TLC publishes its own configuration information as meta data and this data is read by the ITS application when it starts up. At the moment that the ITS control application becomes active it publishes both the TLC s and it s own configuration information towards the RIS. Publication needs to be done at startup of a iTLC component and in case of a ITS Application handover. See paragraph 8.9 for the details.
4.10 Queue Length
The queueLength data entry is used to state the distance from the stop line to the back edge of the last vehicle in the queue as measured in the upstream direction along the lane centre line. This data field is part of the SPAT message in the ConnectionManeuverAssist data frame, which is bound to a single LaneConnectionID. This implies that in SPAT queueLength is provided for a single LaneConnectionID, which effectively corresponds to a single lane. The unit of measurement is meters. The purpose of communicating queue length information is to enable service providers to provide more accurate advice to end-users, e.g. by taking into account queues when calculating green light optimal speed advisory.
To determine the queue length the following conditions apply:
- The provided queue length is an approximation of the actual queue length and heavily dependent on the available sensor equipment and the local intersection topology;
- Vehicles with an (estimated) speed less than 15% of the freeflow speed on that segment should be counted as stopped and included in the queue;
- In case traffic disperses over multiple lanes downstream of a sensor location and no other means of vehicle detection is present, it should be assumed that traffic disperses evenly over the number of lanes;
- The assumed length of a passenger-vehicle-equivalent when is queue is set to 6m.
4.11 Sharing route information of non-priority vehicles
Vehicles approaching an intersection can share route information via the a so-called SRM0 message.
The route information received in the RIS with the SRM0 message, is provided to the ITS application by the signalgroup attribute of the ItsStation object of the corresponding CAM message.
The SRM0 message content and message handling is specified in [REF075].
5 RIS-FI Objects
5.1 Introduction
The RIS-Facilities contains a geographical, consistent and real-time view of the world around the RIS. This view contains information that ranges from static data such as road topology elements to mapped dynamic objects such as vehicles.
ITS-Applications can use this view as provided by the RIS-FI to gather all information needed about the surroundings around the RIS.
To be able to provide simple access to this view, so-called RIS-Objects are available at the RIS-FI. Together, all instances of RIS-Objects provide the real-time updated consistent view.
The RIS-Objects available at RIS-FI are described in this chapter.
ITS-Applications can use this view as provided by the RIS-FI to gather all information needed about the surroundings around the RIS.
To be able to provide simple access to this view, so-called RIS-Objects are available at the RIS-FI. Together, all instances of RIS-Objects provide the real-time updated consistent view.
The RIS-Objects available at RIS-FI are described in this chapter.
5.2 Object types
The following objects are provided by the RIS-FI; some of them are directly related to ITS G5-messages:
| Object | Description | Related ITS G5 message |
| RISFacilities | Provides information about the RIS itself. | - |
| ItsStation | Describes an ITS-Station, like Car or Bicycle . | CAM |
| ItsEvent | Contains information about the occurrence of a traffic event, like weather conditions or dangerous situations. | DENM |
| Intersection | Describes geometry and topology of an intersection and contains the state of the TLC controlling the intersection. | SPAT/MAP |
| SignalGroup | Contains the state, and predicted states, of a signal group as controlled by the TLC. | SPAT |
| Signage2) Signage is currently not supported . | Describes signage information e.g. speed limits, traffic signs etc. | IVI |
| PrioritizationRequest | Signal priority request, received from vehicles and owned by the RIS. | SRM |
| ActivePrioritization | Signal priority status, set by the ITS Application and owned by the RIS. | SSM |
| ConfigurationInformation | Contains the configuration information of the TLC and active ITS control application components. | TLCConf3) TLCConf is the message to exchange iTLC configuration information from iTLC to UDAP. See [REF06 0 ] for more details. |
Information provided by RIS-FI should be easily usable by an ITS-Application to achieve simple application logic; e.g. mapping several geographical positions (WGS84-coordinates) onto a topology-element shall be implemented by the RIS Facilities and is not considered a function implemented by every ITS Application.
The relationships amongst various instances of ItsStations and the topology is described by using instances of the MapMatch Object.
Not all the features of the DENM protocol are provided. The corresponding ItsEvent object represents the subset of DENM possibilities that are relevant for TLC related ITS applications.
Note that received SPAT/MAP from other ITS stations, or another RIS nearby, are not processed and therefore not available at the RIS-FI. Only received CAM and DENM will be processed and made available at the RIS-FI. All messages will of course be sent by the RIS, but an ITS application cannot create an ItsStation object that would result in a CAM.
5.3 Protocol-version
The definition of RIS-FI Objects in this document is defined as version 2.0.0 of the RIS-FI.
It also uses generic object types from [REF061] and object types from [REF065] (these object types are indicated with an asterisk).
5.4 Base
This section contains the basic attribute type definitions of various RIS-FI objects. These types can be derived from simple types, such as integers and strings, but can also be objects themselves.
RISObjectType
| Descriptive name | RISObjectType |
| Definition | This list contains all the different object types for the RIS-FI. This is an implementation of the abstract type ObjectType. |
| Representation | Integer |
| Range | ENUM { RISFacilities(0) ItsStation (1) ItsEvent2) Intersection(3) SignalGroup(4) Signage(5) PrioritizationRequest(6) ActivePrioritization (7) ConfigurationInformation (8) } |
| Unit | N/A |
Acceleration
| Descriptive name | Acceleration |
| Definition | Vehicle acceleration at the longitudinal direction in the centre of the mass of the empty vehicle. Negative values indicate that the vehicle is slowing down. Positive values indicate that the vehicle is speeding up. When the information is not available, the value shall be set to null. |
| Representation | Float |
| Range | -16.0 to 16.0 |
| Unit | meter / second 2 |
ApproachID
| Descriptive name | ApproachID |
| Definition | Number used to group all approaching lanes of an arm into one group. This value is used to find all other lanes of an arm when driving on one of them, for example before the road fans out. Cycling and pedestrians lanes crossing an approach have the same ApproachID as the approach they cross (therefore should be excluded to find all vehicle driving lanes). A value of 0 means unknown . |
| Representation | Integer |
| Range | 0 to 15 |
| Unit | - |
Area
| Descriptive name | Area |
| Definition | This object describes a geographical area, specified by a geometric shape. The MajorAxis is the distance between the centre point and the short side of the geometric shape (perpendicular bisector of the short side). The Angle is the azimuth angle of the long side of the geometric shape. For a circle the MajorAxis and MinorAxis have the same value (and Circular has the value true ). When the attribute Circular has the value false the area will represent a rectangular area, instead of a circular area. |
| Representation | { Locationcentre LengthmajorAxis LengthminorAxis Headingangle Booleancircular } |
| Range | N/A |
| Unit | N/A |
Duration
| Descriptive name | Duration |
| Definition | Duration of a traffic event validity. |
| Representation | Integer |
| Range | 0 to 86400 |
| Unit | seconds |
Interval
| Descriptive name | Interval |
| Definition | Time interval between two consecutive message transmissions. |
| Representation | Integer |
| Range | 0 to 10000 |
| Unit | Milliseconds |
Heading
| Descriptive name | Heading |
| Definition | Orientation of a heading with regards to the WGS84 North, clockwise. When the information is not available, the value shall be set to null. |
| Representation | Float |
| Range | 0.0 to 360.0 |
| Unit | degrees |
Path
| Descriptive name | Path |
| Definition | This object describes a path with a set of path points. Points are defined in order starting at the closest distance from the reference location of the path (e.g. the stop line). |
| Representation | { Locationpoints[] } |
| Range | N/A |
| Unit | N/A |
Punctuality
| Descriptive name | Punctuality |
| Definition | Time difference that indicates the punctuality for public transport vehicles. Negative values indicate early arrival. |
| Representation | Integer |
| Range | -3600 to 3600 |
| Unit | seconds |
SubscriptionID
| Descriptive name | SubscriptionID |
| Definition | An identifier that is unique for a subscription with the RIS Facilities. This is a specific type of ObjectID used to identify subscriptions. |
| Representation | See ObjectID |
| Range | See ObjectID |
| Unit | See ObjectID |
TrustState
| Descriptive name | TrustState |
| Definition | This object defines the trust status of an object, which is based on the presence of a digital signature of the incoming object, and on the validity of the signature. |
| Representation | Integer |
| Range | ENUM { unsecured(0)no digital signature present untrusted(1)the digital signature is not trusted or cannot be verified trusted(2)the digital signature is trusted } |
| Unit | N/A |
5.5 Cause codes
Within the cooperative messages, incidents and traffic events are indicated by cause codes. These codes consist of a direct cause of a detected event and a sub type of the direct cause. Refer to Appendix B for more information.
SubCauseCode (abstract)
| Descriptive name | SubCauseCode |
| Definition | An abstract object type to group sub causes of traffic events. |
| Representation | Integer |
| Range | N/A |
| Unit | N/A |
CauseCode
| Descriptive name | CauseCode |
| Definition | This list contains all the possible traffic event types. |
| Representation | Integer |
| Range | ENUM { unknown(0) trafficCondition(1) accident(2) roadworks(3) adverseWeatherCondition-Adhesion(6) hazardousLocation-SurfaceCondition(9) hazardousLocation-ObstacleOnTheRoad(10) hazardousLocation-AnimalOnTheRoad(11) humanPresenceOnTheRoad(12) wrongWayDriving(14) rescueAndRecoveryWorkInProgress(15) adverseWeatherCondition-ExtremeWeatherCondition(17) adverseWeatherCondition-Visibility(18) adverseWeatherCondition-Precipitation(19) slowVehicle(26) dangerousEndOfQueue(27) vehicleBreakdown(91) postCrash(92) humanProblem(93) stationaryVehicle(94) emergencyVehicleApproaching(95) hazardousLocation-DangerousCurve(96) collisionRisk(97) signalViolation(98) dangerousSituation(99) } |
| Unit | N/A |
AccidentSubCauseCode
| Descriptive name | AccidentSubCauseCode |
| Definition | This object implements the abstract object SubCauseCode and contains the sub cause codes of the event type accident (2). |
| Representation | Integer |
| Range | ENUM { unavailable(0) multiVehicleAccident(1) heavyAccident(2) accidentInvolvingLorry(3) accidentInvolvingBus(4) accidentInvolvingHazardousMaterials(5) accidentOnOppositeLane(6) unsecuredAccident(7) assistanceRequested(8) } |
| Unit | N/A |
AdverseWeatherAdhesionSubCauseCode
| Descriptive name | AdverseWeatherAdhesionSubCauseCode |
| Definition | This object implements the abstract object SubCauseCode and contains the sub cause codes of the event type adverseWeatherCondition-Adhesion (6). |
| Representation | Integer |
| Range | ENUM { unavailable(0) heavyFrostOnRoad(1) fuelOnRoad(2) mudOnRoad(3) snowOnRoad(4) iceOnRoad(5) blackIceOnRoad (6) oilOnRoad(7) looseChippings(8) instantBlackIce(9) roadsSalted(10) } |
| Unit | N/A |
AdverseWeatherConditionVisibilitySubCauseCode
| Descriptive name | AdverseWeatherConditionVisibilitySubCauseCode |
| Definition | This object implements the abstract object SubCauseCode and contains the sub cause codes of the event type adverseWeatherCondition-Visibility (18). |
| Representation | Integer |
| Range | ENUM { unavailable(0) fog(1) smoke(2) heavySnowfall(3) heavyRain(4) heavyHail(5) lowSunGlare(6) sandstorms(7) swarmsOfInsects (8) } |
| Unit | N/A |
AdverseWeatherConditionPrecipitationSubCauseCode
| Descriptive name | AdverseWeatherConditionPrecipitationSubCauseCode |
| Definition | This object implements the abstract object SubCauseCode and contains the sub cause codes of the event type adverseWeatherCondition-Precipitation (19). |
| Representation | Integer |
| Range | ENUM { unavailable(0) heavyRain(1) heavySnowfall(2) softHail(3) } |
| Unit | N/A |
AdverseWeatherExtremeWeatherSubCauseCode
| Descriptive name | AdverseWeatherExtremeWeatherSubCauseCode |
| Definition | This object implements the abstract object SubCauseCode and contains the sub cause codes of the event type adverseWeatherCondition-ExtremeWeatherCondition (17). |
| Representation | Integer |
| Range | ENUM { unavailable(0) strongWinds(1) damagingHail(2) hurricane(3) thunderstorm(4) tornado(5) blizzard(6) } |
| Unit | N/A |
CollisionRiskSubCauseCode
| Descriptive name | CollisionRiskSubCauseCode |
| Definition | This object implements the abstract object SubCauseCode and contains the sub cause codes of the event type collisionRisk (97). |
| Representation | Integer |
| Range | ENUM { unavailable(0) longitudinalCollisionRisk (1) crossingCollisionRisk(2) lateralCollisionRisk(3) vulnerableRoadUser(4) } |
| Unit | N/A |
DangerousEndOfQueueSubCauseCode
| Descriptive name | DangerousEndOfQueueSubCauseCode |
| Definition | This object implements the abstract object SubCauseCode and contains the sub cause codes of the event type dangerousEndOfQueue (27). |
| Representation | Integer |
| Range | ENUM { unavailable(0) suddenEndOfQueue(1) queueOverHill(2) queueAroundBend(3) queueInTunnel(4) } |
| Unit | N/A |
DangerousSituationSubCauseCode
| Descriptive name | DangerousSituationSubCauseCode |
| Definition | This object implements the abstract object SubCauseCode and contains the sub cause codes of the event type dangerousSituation (99). |
| Representation | Integer |
| Range | ENUM { unavailable(0) emergencyElectronicBrakeEngaged(1) preCrashSystemEngaged(2) espEngaged(3) absEngaged(4) aebEngaged(5) brakeWarningEngaged(6) collisionRiskWarningEngaged(7) } |
| Unit | N/A |
EmergencyVehicleApproachingSubCauseCode
| Descriptive name | EmergencyVehicleApproachingSubCauseCode |
| Definition | This object implements the abstract object SubCauseCode and contains the sub cause codes of the event type emergencyVehicleApproaching (95). |
| Representation | Integer |
| Range | ENUM { unavailable(0) emergencyVehicleApproaching(1) prioritizedVehicleApproaching(2) } |
| Unit | N/A |
HazardousLocation-AnimalOnTheRoadSubCauseCode
| Descriptive name | HazardousLocation-AnimalOnTheRoadSubCauseCode |
| Definition | This object implements the abstract object SubCauseCode and contains the sub cause codes of the event type hazardousLocation-AnimalOnTheRoad (11). |
| Representation | Integer |
| Range | ENUM { unavailable(0) wildAnimals(1) herdOfAnimals(2) smallAnimals(3) largeAnimals(4) } |
| Unit | N/A |
HazardousLocation-DangerousCurveSubCauseCode
| Descriptive name | HazardousLocation-DangerousCurveSubCauseCode |
| Definition | This object implements the abstract object SubCauseCode and contains the sub cause codes of the event type hazardousLocation-DangerousCurve (96). |
| Representation | Integer |
| Range | ENUM { Unavailable(0) dangerousLeftTurnCurve(1) dangerousRightTurnCurve(2) multipleCurvesStartingWithUnknownTurningDirection(3) multipleCurvesStartingWithLeftTurn(4) multipleCurvesStartingWithRightTurn(5) } |
| Unit | N/A |
HazardousLocation-ObstacleOnTheRoadSubCauseCode
| Descriptive name | HazardousLocation-ObstacleOnTheRoadSubCauseCode |
| Definition | This object implements the abstract object SubCauseCode and contains the sub cause codes of the event type hazardousLocation-ObstacleOnTheRoad (10). |
| Representation | Integer |
| Range | ENUM { unavailable(0) shedload(1) partsOfVehicles(2) partsOfTyres(3) bigObjects(4) fallenTrees(5) hubCaps(6) waitingVehicles(7) } |
| Unit | N/A |
HazardousLocation-SurfaceConditionSubCauseCode
| Descriptive name | HazardousLocation-SurfaceConditionSubCauseCode |
| Definition | This object implements the abstract object SubCauseCode and contains the sub cause codes of the event type hazardousLocation-SurfaceCondition (9). |
| Representation | Integer |
| Range | ENUM { unavailable(0) rockfalls(1) earthquakeDamage(2) sewerCollapse(3) subsidence(4) snowDrifts(5) stormDamage(6) burstPipe(7) volcanoEruption)8) fallingIce(9) } |
| Unit | N/A |
HumanPresenceOnTheRoadSubCauseCode
| Descriptive name | HumanPresenceOnTheRoadSubCauseCode |
| Definition | This object implements the abstract object SubCauseCode and contains the sub cause codes of the event type humanPresenceOnTheRoad (12). |
| Representation | Integer |
| Range | ENUM { unavailable(0) childrenOnRoadway(1) cyclistOnRoadway(2) motorcyclistOnRoadway(3) } |
| Unit | N/A |
HumanProblemSubCauseCode
| Descriptive name | HumanProblemSubCauseCode |
| Definition | This object implements the abstract object SubCauseCode and contains the sub cause codes of the event type humanProblem (93). |
| Representation | Integer |
| Range | ENUM { unavailable(0) glycemiaProblem(1) heartProblem(2) } |
| Unit | N/A |
PostCrashSubCauseCode
| Descriptive name | PostCrashSubCauseCode |
| Definition | This object implements the abstract object SubCauseCode and contains the sub cause codes of the event type postCrash (92). |
| Representation | Integer |
| Range | ENUM { unavailable(0) accidentWithoutECallTriggered(1) accidentWithECallManuallyTriggered(2) accidentWithECallAutomaticallyTriggered(3) accidentWithECallTriggeredWithoutAccessToCellularNetwork(4) } |
| Unit | N/A |
RescueAndRecoveryWorkInProgressSubCauseCode
| Descriptive name | RescueAndRecoveryWorkInProgressSubCauseCode |
| Definition | This object implements the abstract object SubCauseCode and contains the sub cause codes of the event type rescueAndRecoveryWorkInProgress (15). |
| Representation | Integer |
| Range | ENUM { unavailable(0) emergencyVehicles(1) rescueHelicopterLanding(2) policeActivityOngoing(3) medicalEmergencyOngoing(4) childAbductionInProgress(5) } |
| Unit | N/A |
RoadworksSubCauseCode
| Descriptive name | RoadworksSubCauseCode |
| Definition | This object implements the abstract object SubCauseCode and contains the sub cause codes of the event type roadworks (3). |
| Representation | Integer |
| Range | ENUM { unavailable(0) majorRoadworks(1) roadMarkingWork(2) slowMovingRoadMaintenance(3) shortTermStationaryRoadworks(4) streetCleaning(5) winterService(6) } |
| Unit | N/A |
SignalViolationSubCauseCode
| Descriptive name | SignalViolationSubCauseCode |
| Definition | This object implements the abstract object SubCauseCode and contains the sub cause codes of the event type signalViolation (98). |
| Representation | Integer |
| Range | ENUM { unavailable(0) stopSignViolation(1) trafficLightViolation(2) turningRegulationViolation(3) } |
| Unit | N/A |
SlowVehicleSubCauseCode
| Descriptive name | SlowVehicleSubCauseCode |
| Definition | This object implements the abstract object SubCauseCode and contains the sub cause codes of the event type slowVehicle (26). |
| Representation | Integer |
| Range | ENUM { unavailable(0) maintenanceVehicle(1) vehiclesSlowingToLookAtAccident(2) abnormalLoad(3) abnormalWideLoad(4) convoy(5) snowplough(6) deicing(7) saltingVehicles(8) } |
| Unit | N/A |
StationaryVehicleSubCauseCode
| Descriptive name | StationaryVehicleSubCauseCode |
| Definition | This object implements the abstract object SubCauseCode and contains the sub cause codes of the event type stationaryVehicle (94). |
| Representation | Integer |
| Range | ENUM { unavailable(0) humanProblem(1) vehicleBreakdown(2) postCrash(3) publicTransportStop(4) carryingDangerousGoods(5) } |
| Unit | N/A |
TrafficConditionSubCauseCode
| Descriptive name | TrafficConditionSubCauseCode |
| Definition | This object implements the abstract object SubCauseCode and contains the sub cause codes of the event type trafficCondition (1). |
| Representation | Integer |
| Range | ENUM { unavailable(0) increasedVolumeOfTraffic(1) trafficJamSlowlyIncreasing(2) trafficJamIncreasing(3) trafficJamStronglyIncreasing(4) trafficStationary(5) trafficJamSlightlyDecreasing(6) trafficJamDecreasing(7) trafficJamStronglyDecreasing(8) } |
| Unit | N/A |
VehicleBreakdownSubCauseCode
| Descriptive name | VehicleBreakdownSubCauseCode |
| Definition | This object implements the abstract object SubCauseCode and contains the sub cause codes of the event type vehicleBreakdown (91). |
| Representation | Integer |
| Range | ENUM { unavailable(0) lackOfFuel(1) lackOfBatteryPower(2) engineProblem(3) transmissionProblem(4) engineCoolingProblem(5) brakingSystemProblem(6) steeringProblem(7) tyrePuncture(8) } |
| Unit | N/A |
WrongWayDrivingSubCauseCode
| Descriptive name | WrongWayDrivingSubCauseCode |
| Definition | This object implements the abstract object SubCauseCode and contains the sub cause codes of the event type wrongWayDriving (14). |
| Representation | Integer |
| Range | ENUM { unavailable(0) wrongLane(1) wrongDirection(2) } |
| Unit | N/A |
5.6 RISFacilities
The RISFacilities object provides information about the RIS itself.
RISFacilities
| Descriptive name | RISFacilities |
| Definition | This object describes the RIS Facilities. |
| Access | ConsumerProvider |
| RR | |
| Representation | { FacilitiesID4) This type is defined in [REF065] .id Locationlocation FacilitiesInformation [3] infoObjectID Intersection>intersections[] } |
| Range | N/A |
| Unit | N/A |
5.7 ItsStation
The ItsStation object is an abstraction of the Cooperative Awareness Message (CAM). When a CAM is received by the RIS the corresponding attributes of the ItsStation object are written. After the RIS has performed the map-matching process the results are written to the matches attribute. When a SRM0 is received, the list of received connections are translated to the corresponding signalgroups and written to the corresponding signalgroup attribute of the ItsStation object.
ItsStation
| Descriptive name | ItsStation |
| Definition | This object describes properties of a ItsStation. The ID is the same as the string representation of the StationID of the corresponding CAM. The attribute locationTime is derived from generationDeltaTime in the CAM and gives the time when the CAM was generated at the OBU at the specified location. When the vehicle role is not specified within the received CAM, the value default (0) will be set by the RIS. The attribute signalGroup[] is the translation result from the connection(s) received with the corresponding SRM0 message. As a single SRM message may contain multiple requests for different connections, each signalGroup entry corresponds to one request. The attribute positionConfEllipse is derived from positionConfidenceEllipse in CAM. Note: even though the RIS must perform map-matching upon receipt of a CAM message, the map-matching may produce no result therefore no map-match will be provided on RIS-FI. |
| Access | ConsumerProvider |
| RR | |
| Representation | { ObjectIDid StationTypestationType TimestamplocationTime VehicleRolerole Lengthlength Lengthwidth Directiondirection Locationlocation Headingheading Speedspeed Accelerationacceleration RoleAttributesroleAttributes PositionConfEllipsepositionConfEllipse TurnIntentionturn OPT> MapMatchmatches[] OPT> TrustStatetrust OPT> ObjectID signalGroup>signalGroup[] OPT> } |
| Range | N/A |
| Unit | N/A |
DangerousGoods
| Descriptive name | DangerousGoods |
| Definition | This list contains the possible types of dangerous goods that can be carried by a (heavy) vehicle according to the European Agreement concerning the International Carriage of Dangerous Goods by Road. |
| Representation | Integer |
| Range | ENUM { explosives1(0) explosives2(1) explosives3(2) explosives4(3) explosives5(4) explosives6(5) flammableGases(6) nonFlammableGases(7) toxicGases(8) flammableLiquids(9) flammableSolids(10) substancesLiableToSpontaneousCombustion(11) substancesEmittingFlammableGasesUponContactWithWater(12) oxidizingSubstances(13) organicPeroxides(14) toxicSubstances(15) infectiousSubstances(16) radioactiveMaterial(17) corrosiveSubstances(18) miscellaneousDangerousSubstances(19) } |
| Unit | N/A |
MapMatch
| Descriptive name | MapMatch |
| Definition | This object describes a map-matching result of an ItsStation onto a Lane of an Intersection. The Distance represents the distance to the start of the lane (stop-line) along the path of the Lane, and the Offset represents the perpendicular distance to the path of the Lane. See also section 4.6. When the ItsStation is map-matched to one of the connecting paths that runs over the conflict area, a lane value of 0 will be returned. In this case the distance and offset have no meaning. Note: the connection paths are defined within the ITF data, but are not made available on the RIS-FI interface. The optional signalGroup will only be set when possible to determine. |
| Representation | { ObjectID Intersection>intersection Integerlane ObjectID SignalGroup>signalGroup OPT> Lengthdistance Lengthoffset } |
| Range | N/A |
| Unit | N/A |
PublicTransport
| Descriptive name | PublicTransport |
| Definition | This object describes the additional attributes of a vehicle that is used to operate public transport service. The attributes presented here are encoded within the CAM. Refer to [REF094] for more details. |
| Representation | { Booleanembarkation IntegerlineNr IntegervehicleIDUnique per company IntegerserviceNrSame as block number IntegerjourneyNr IntegersupportNrSupport journey number IntegercompanyNr IntegeroccupancyNumber of passengers } |
| Range | N/A |
| Unit | N/A |
RoleAttributes
| Descriptive name | RoleAttributes | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Definition | This object defines the role-dependent attributes of an ItsStation. The attributes marked with M are mandatory and the attributes marked with O are optional for ItsStations with the corresponding VehicleRole value. The attributes marked with - are not applicable for those with the corresponding VehicleRole value. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Representation |
|
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Range | N/A | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Unit | N/A | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
SpecialTransport
| Descriptive name | SpecialTransport |
| Definition | This object describes the different classifications of special transport types. For the classifications that apply to the special cargo being transported the corresponding attribute values are set to true , the other attributes shall have a value of false . |
| Representation | { BooleanheavyLoad BooleanexcessWidth BooleanexcessLength BooleanexcessHeight } |
| Range | N/A |
| Unit | N/A |
TurnIntention
| Descriptive name | TurnIntention |
| Definition | The turn an ItsStation intends to take derived from the turn signals. |
| Representation | Integer |
| Range | ENUM { unknown (0) left (1) straight (2) right (3) } |
StationType
| Descriptive name | StationType |
| Definition | This list contains all the different station types for an ItsStation. |
| Representation | Integer |
| Range | ENUM { unknown(0) pedestrian(1) cyclist(2) moped(3) motorcycle(4) passengerCar(5) bus(6) lightTruck(7) heavyTruck(8) trailer(9) specialVehicles(10) tram(11) roadSideUnit(15) } |
| Unit | N/A |
VehicleRole
| Descriptive name | VehicleRole |
| Definition | This list contains all the different vehicle roles for an ItsStation. A vehicle can be assigned a role which identifies a certain expected behaviour. This assigned role also determines the additional RoleAttributes of an ItsStation. The VehicleRole can also be used during prioritization, in that case values beyond safetyCar may not be used. |
| Representation | Integer |
| Range | ENUM {Description default(0)Default vehicle role as indicated by the vehicle type. publicTransport(1)Vehicle is used to operate public transport service. specialTransport(2)Indication for special transport, e.g. oversized trucks. dangerousGoods (3)Vehicle used for dangerous goods transportation. roadwork (4)Vehicle used to realize roadworkor road maintenance mission. rescue(5)Vehicle used for rescue purposes,e.g. as a towing service. emergency(6)Vehicle used for emergency mission, e.g. ambulance, fire brigade. safetyCar (7)Vehicle is used for public safety, e.g. patrol. agriculture(8)Vehicle is used for agriculture, e.g. farm tractor. commercial(9)Vehicle is used for transportation of commercial goods. military(10)Vehicle is used for military purpose. roadOperator(11)Vehicle is used in road operator missions. taxi(12)Vehicle is used to provide an authorized taxiservice. } |
| Unit | N/A |
VehicleSubRole
| Descriptive name | VehicleSubRole |
| Definition | This list contains all the different vehicle sub roles. |
| Representation | Integer |
| Range | ENUM {Description unknown(0)Default vehicle role as indicated by the vehicle type. bus(1) tram(2) metro(3) train(4) emergency(5)emergency vehicle with siren/lights smooth(6)ambulance smooth drive timetable (7)public transport time table service interval(8)public transport time interval service expresstransit(9) noservice (10)vehicles that are not in active service platoon (11)vehicles that are driving as a platoon ecodriving (12)vehicles that want to reduce emissions |
| Unit | N/A |
Direction
| Descriptive name | Direction |
| Definition | This list contains the direction the vehicle is travelling in which is received as driveDirection with CAM. |
| Representation | Integer |
| Range | ENUM { forward(0) backward(1) unavailable(2) } |
| Unit | N/A |
PositionConfEllipse
| Descriptive name | PositionConfEllipse |
| Definition | This object represents the positionConfidenceEllipse received with CAM. For horizontal positions a confidence area is used instead of a single confidence interval. The confidence area is specified via a major axis, minor axis and orientation of the major axis relative to navigation coordinate north. See [REF075] more details. |
| Representation | { Length semiMajorConfidence LengthsemiMinorConfidence Heading semiMajorOrientation } |
| Range | semiMajorConfidence, semiMinorConfidence: 1-40,93 where a value greater than 40,93 indicates out of range. The value shall be set to null if the information is unavailable. semiMajorOrientation: 0-360,0. The value shall be set to null if the information is unavailable. |
| Unit | semiMajorConfidence, semiMinorConfidence: length in meters semiMajorOrientation: degrees with regards to WGS84 north |
5.8 ItsEvent
The ItsEvent object is an abstraction of the Decentralized Environmental Notification Message (DENM). An ITS-Application can request the RIS for dissemination of DENM by writing an ItsEvent object. Also when a DENM is received by the RIS the corresponding attributes of the ItsEvent object are written.
ItsEvent
| Descriptive name | ItsEvent | |
| Definition | This object describes a detected event, like weather conditions or dangerous situations. The id is the same as the string representation of the ActionID of the corresponding DENM (an underscore is used as field seperator). The detectionTime is the moment in time the event has been detected. If this moment lies in the future the behaviour of the RIS is undefined. When no DestinationArea is specified, a circle around EventPosition with a radius of RelevanceDistance will be taken. When no RepetitionInterval is specified, the corresponing DENM is broadcasted only once. Otherwise the RepetitionInterval specifies the time between between two consecutive message transmissions. The TrustState can only be available for incoming events. | |
| Access | ConsumerProvider | |
| RR/W | ||
| Representation | { ObjectIDid TimestampdetectionTime CauseCodeeventType SubCauseCodeeventSubType LocationeventPosition DurationvalidityDuration LengthrelevanceDistance TrafficDirectiontrafficDirection Pathtraces[] AreadestinationArea OPT> IntervalrepetitionInterval OPT> TrustStatetrust OPT> } | |
| Range | N/A | |
| Unit | N/A | |
TrafficDirection
| Descriptive name | TrafficDirection |
| Definition | This list contains all the different traffic directions that are relevant to information indicated in an ItsEvent. Upstream traffic corresponds to the incoming traffic; towards the event, and downstream traffic corresponds to the departing traffic; away from the event. |
| Representation | Integer |
| Range | ENUM { allTrafficDirections(0) upstreamTraffic(1) downstreamTraffic(2) oppositeTraffic(3) } |
| Unit | N/A |
5.9 Intersection
The Intersection object is an abstraction of the MapData message. It describes the intersection geometry that is derived from the topology as specified in [REF096].
Intersection
| Descriptive name | Intersection | |
| Definition | This object describes the topology of an intersection. An Intersection is defined as a Conflict area that cannot be split into smaller conflict areas. It also contains the (dynamic) information about the traffic light controller state. The ID of this object should be equal to the ID of the corresponding Intersection object as received from the TLC-FI. The enabledLanes is used to list the laneNrs of enabled lanes, in case dynamic lanes are available. Non-dynamic lanes may not be listed. Note: the ID of the intersection can be retrieved from the ITF controlData section, element name in controlledIntersection . The element name in this object is derived from the ITF controlData section, element descriptive name in controlledIntersection . The lanes elements in this object is derived from the ITF IntersectionGeometry section. The owner element is used to claim ownership of an intersection and the associated signal groups (see paragraph 4.4.4) -Set owner=RegistrationReply.sessionid to claim ownership. -Set owner=null to release the ownership. | |
| Access | ConsumerProvider | |
| RR/W | ||
| Representation | {Access ObjectIDidR StringnameR LocationreferencePositionR SpeedspeedLimit OPT>R Lanelanes[]R IntegerenabledLanes[]R/W ObjectID SignalGroup>signalGroups[]R IntersectionStatestatusR/W SessionIDownerR/W } | |
| Range | N/A | |
| Unit | N/A | |
AllowedManeuvers
| Descriptive name | AllowedManeuvers |
| Definition | This list contains the allowed (possible) maneuvers from a lane connected to another lane . |
| Representation | Integer |
| Range | {Description straight(0)A Straight movement is allowed in this lane. leftTurn(1)A Left Turn movement is allowed in this lane. rightTurn(2)A Right Turn movement is allowed in this lane. uTurn(3)A U Turn movement is allowed in this lane. leftTurnOnRed(4)A Stop, and then proceed when safe movement isallowed in this lane. rightTurnOnRed(5)A Stop, and then proceed when safe movement isallowed in this lane. laneChange(6)A movement which changes to an outer lane onthe egress side is allowed in this lane(example: left into either outbound lane). noStopping(7)The vehicle should not stop at the stop line(example: a flashing green arrow). yieldAllways(8)The allowed movements above are not protected(example: a permanent yellow condition). goWithHalt(9)After making a full stop, may proceed. caution(10)Proceed past stop line with caution. } |
| Unit | N/A |
Connection
| Descriptive name | Connection |
| Definition | This object describes the connection between two lanes. The Lane attribute is the lane number where the Lane in question is connected to. This can (optionally) be at another Intersection. If a SignalGroup is specified, the connection is guarded by that signal group. The Maneuver attribute indicates what kind of movement is represented by this connection. |
| Representation | { Integerlane ObjectID Intersection>intersection OPT> ObjectID SignalGroup>signalGroup OPT> AllowedManeuversmaneuver OPT> } |
| Range | N/A |
| Unit | N/A |
IntersectionState
| Descriptive name | IntersectionState |
| Definition | This object contains the traffic controller status information that may be sent to local OBUs as part of the SPAT process. All applicable states will be set to the value true or "false" by the ITS application that provides this information. All other attributes must not be set. Note: when no IntersectionState info is available, the SPAT IntersectionStatus should be set to 'noValidSPATisAvailableAtThisTime'. |
| Representation | {Description BooleanmanualControlIsEnabledTiming reported is per programmedvalues, etc. but person at cabinetcan manually request that certainintervals are terminated early(e.g. green). BooleanstopTimeIsActivatedAll counting/timing has stopped. BooleanfailureFlashTo be used for any detectedhardware failures, e.g. conflictmonitor as well as for police flash. BooleanpreemptIsActive BooleansignalPriorityIsActive BooleanfixedTimeOperationSchedule of signals is based on timeonly(i.e. the state can becalculated). BooleantrafficDependentOperationOperation is based on differentlevels of traffic parameters(requests, duration of gaps or morecomplex parameters). BooleanstandbyOperationPartially switched off or partiallyamber flashing. BooleanfailureModeController has a problem or failurein operation. BooleanoffController is switched off. } |
| Range | N/A |
| Unit | N/A |
Lane
| Descriptive name | Lane |
| Definition | This object describes the basic attribute information of a lane. The LaneNr is a unique number within the intersection.The nodes are defined starting closest to the centre (position) of the intersection going outwards. Connections are defined by the Lane(s) this Lane is connected to. The dynamic field determines if the lane is dynamic, i.e. it can be disabled or enabled. Enabling or disabling of a lane is done via the Intersection object. |
| Representation | { IntegerlaneNr ApproachIDingress ApproachIDegress LaneDirectiondirection Pathnodes ConnectionconnectsTo[] Booleandynamic } |
| Range | N/A |
| Unit | N/A |
LaneDirection
| Descriptive name | LaneDirection |
| Definition | This list contains all the different (driving) directions of a Lane. |
| Representation | Integer |
| Range | ENUM { none(0) ingress(1) egress(2) bothWays(3) } |
| Unit | N/A |
5.10 SignalGroup
The SignalGroup object is an abstraction of the Signal Phase and Timing (SPAT) message. It describes the movement states of each signal group of an intersection, including any active or pending priority events.
SignalGroup
| Descriptive name | SignalGroup | |
| Definition | This object describes the various information about the current or future movement state of a designated collection of one or more lanes under a signal group. The ID must be unique within the RIS. Therefore this is constructed from the ID of the intersection the signal group belongs to, followed by an underscore, and the ID of the corresponding SignalGroup object as received from the TLC-FI. Note: The SignalGroup ObjectID names are constructed from ITF ControlData elements: name in controlledIntersection and name in sg , with an underscore as separator. The Predictions should be ordered in time; first entry is the first state to be activated. [CO-53] | |
| Access | ConsumerProvider | |
| RR/W | ||
| Representation | {Access ObjectIDidR SignalGroupState5) This type is defined in [REF065] .stateR/W [CO-53] SignalGroupPredictionpredictions[]R/W [CO-53-END] SpeedProfilespeedProfiles[] OPT>R/W TimeExceptionreason6) T he use of TimeException ‘unknown’ should be minimized . OPT>R/W QueueLength queue[] OPT> R/W } | |
| Range | prediction: minimum 1 entry, maximum 16 entries; speedProfiles: minimum 0 entry, maximum 16 entries; queue: minimum 0 entry, maximum 16 entries | |
| Unit | N/A | |
SignalGroupPrediction
| Descriptive name | A signal group prediction update |
| Definition | Prediction of the end time of a specific signal group state. This structure is used by an ITS-CLA when it updates the predictions towards the RIS. The prediction is provided in ticks. startTime: tick at which this state is started, or expected to start *1) minEnd: minimum tick at which this state may end* 2)*4) maxEnd: maximum tick at which or before this state must end *3)*4) likelyEnd: likely tick at which this state will end next : rough estimate of the tick at which this state will be activated next The requirements for the state and timing processing by an ITS-CLA are outlined in [REF060], section 7.1. |
| Representation | { SignalGroupStatestate TicksstartTime OPT> TicksminEnd TicksmaxEnd TickslikelyEnd OPT> Confidenceconfidence OPT> * 5 ) Ticksnext OPT> } |
| Range | startTime, minEnd, maxEnd, likelyEnd and next: as Ticks, when set to null = unknown |
| Unit | N/A |
*1) startTime is not used.
*2) minEnd is used to convey the earliest time possible at which the signal group could change, except when unpredictable events relating to a pre-emption or priority call disrupt a currently active timing plan. minEnd shall not decrease with more than 500ms without provision of a valid TimeException*5).
*3) maxEnd is used to convey the latest time possible which the signal group could change, except when unpredictable events relating to a pre-emption or priority call come into play and disrupt a currently active timing plan. maxEnd shall not increase with more than 500ms without provision of a valid TimeException*5).
*4) The difference between the minEnd and maxEnd is a measure for the reliability of the prediction.
*5) Confidence is mandatory for the state StopAndRemain(3). For other states confidence shall be omitted or set to null.
Confidence
| Descriptive name | The confidence of a prediction |
| Definition | The confidence of a prediction, encoded in the SPaT way. Note: confidence is only used in a SignalGroupPrediction for the state StopAndRemain(3). |
| Representation | Integer |
| Range | ENUM{ RedNoDemand (1) RedTrafficPresentTimeToGreenUnknown (3) RedOtherDirectionsBecomeGreenFirst (6) RedNextToGetGreen (9) RedWillBecomeGreenExceptionStillPossible (12) RedWillBecomeGreen (15) } |
| Unit | N/A |
AdvisoryType
| Descriptive name | AdvisoryType |
| Definition | This list contains the different types of advices a given speed refers to. |
| Representation | Integer |
| Range | ENUM { none(0) greenwave(1) ecoDrive(2) transit(3) } |
| Unit | N/A |
SpeedProfile
| Descriptive name | SpeedProfile |
| Definition | This object describes a recommended traveling approach speed to an intersection. The Distance indicates the region for which the advised speed is recommended. It is specified as the distance from the stop line, along the centre path of the lane. This region can be cut short when another SpeedProfile, with a shorter Distance, is defined. An advised Speed with a value of 0.0 m/s indicates that no reasonable speed can be advised, e.g. for the region of a waiting queue. |
| Representation | { AdvisoryTypetype Lengthdistance Speedspeed } |
| Range | N/A |
| Unit | N/A |
TimeException
| Descriptive name | TimeException |
| Definition | This list contains different reasons why a previously predicted time has changed unexpectedly. |
| Representation | Integer |
| Range | ENUM { unknown (0) publicTransportPriority(1) emergencyVehiclePriority(2) trainPriority(3) bridgeOpen(4) vehicleHeight(5) weather(6) trafficJam(7) tunnelClosure(8) meteringActive(9) truckPriority(10) bicyclePlatoonPriority(11) vehiclePlatoonPriority(12) } |
| Unit | N/A |
QueueLength
| Descriptive name | QueueLength |
| Definition | The queueLength data entry is used to state the distance from the stop line to the back edge of the last vehicle in the queue as measured in the upstream direction along the lane centre line. |
| Representation | { Integer zoneLength Integer lane } |
| Range | N/A |
| Unit | 1 meter, 0 = no queue, 10.000 = distances > 10.000 meters |
5.11 PrioritizationRequest
PrioritizationRequest
| Descriptive name | PrioritizationRequest |
| Definition | This object describes a prioritization request as sent from a vehicle in the form of a Signal Request Message (SRM). It relates the intersection and signal group to the vehicle that requests prioritization. The id is created from the StationID and the RequestID, separated with an underscore. The referred iItsStation may not exist if no related CAM message has been received yet. If no valid eta is provided in the SRM, the attribute eta shall be set tot null. Once a PrioritizationRequest is created by the RIS, the related ActivePrioritization is also created. The PrioritizationRequest will be removed when the eta plus the duration expires. If no duration is provided in the SRM, the PrioritizationRequest will be removed after eta plus 65 seconds. If eta is null, the PrioritizationRequest will be removed after the duration, or if not provided after 65 seconds. |
| Access | ConsumerProvider |
| RR | |
| Representation | { ObjectIDid IntegersequenceNumber PriorityRequestTyperequestType ObjectID ItsStation>itsStation ObjectID Intersection>intersection VehicleRolerole VehicleSubRolesubrole TimestampetaEstimated Time of Arrival ObjectID SignalGroup>signalGroup OPT> ApproachIDapproach OPT> String routeName OPT> TransitStatustransitStatus OPT> Punctualitypunctuality OPT> Integerimportance OPT> TrustStatetrust OPT> } |
| Range | N/A |
| Unit | N/A |
PriorityRequestType
| Descriptive name | PriorityRequestType |
| Definition | This list contains the enumeration to indicate if a request (found in the SRM) represents a new service request, a request update, or a request cancellation. |
| Representation | Integer |
| Range | ENUM { none(0) request(1) update(2) cancellation(3) } |
| Unit | N/A |
TransitStatus
| Descriptive name | TransitStatus |
| Definition | This object describes the transit status. |
| Representation | { Booleanloadingparking and unable to move at this time BooleananADAusean ADA7) ADA Americans with Disabilities Act access is in progress, wheelchairs,kneeling, etc. BooleanaBikeLoadloading of a bicycle is in progress BooleandoorOpena vehicle door is open for passenger access Booleancharginga vehicle is connected to charging point BooleanatStopLinea vehicle is at the stop line for the lane it is in } |
| Range | N/A |
| Unit | N/A |
5.12 ActivePrioritization
ActivePrioritization
| Descriptive name | ActivePrioritization |
| Definition | This object describes the response status of a prioritization request as send to a vehicle in the form of a Signal Status Message (SSM). It relates the prioritization state to the vehicle that requested prioritization via the id and sequenceNumber, which must identify an existing PrioritizationRequest. If the related PrioritizationRequest is removed, the ActivePrioritization will be removed too by the RIS. When updating this object the sequenceNumber must be copied from the associated PrioritizationRequest. |
| Access | ConsumerProvider |
| RR/W | |
| Representation | { ObjectID PrioritizationRequest>id IntegersequenceNumber PrioritizationStateprioState } |
| Range | N/A |
| Unit | N/A |
PrioritizationState
| Descriptive name | PrioritizationState |
| Definition | This list contains the possible states of a prioritization request. |
| Representation | Integer |
| Range | ENUM { unknown(0)Unknown state. requested(1)This prioritization request was detected bythetraffic controller, but the contents have not beenevaluated yet, control is not changed. processing(2)The request has been validated and is changing the control, changed timing is reported via SPaT. watchOtherTraffic(3) presentSame as granted, but signals will be changed to all red. Only used for emergency vehicles. granted(4)Intervention was successful and now prioritizationis active, the requested signal will be green. Control for the requested signal will not change until thevehicle has passed thestop line. Changed timing isreported via SPaT. rejected(5)The prioritization request is rejectedby thetraffic controller (e.g. due to conflicting priorities or because the (updated) ETA exceeds the maximum acceptable ETA) . maxPresence(6)The request is rejected, because ithas exceeded maxPresencetime.Can only be given after processing or granted states. reserviceLocked(7)The request is rejected, because the service is locked; the controllerrequires the passage of timebefore another similar request will be accepted. } |
| Unit | N/A |
5.13 Signage
The Signage object is an abstraction of the In-Vehicle Information service message (IVI). However, the relevant specification documents for this service are not finalized at the time of writing. Therefore, the contents of the Signage object are to be defined in another version of this document.
5.14 ConfigurationInformation
| Descriptive name | ConfigurationInformation | |
| Definition | This object contains the configuration information of the iTLC components (TLC, RIS and ITS-CLA). Note: the ID can be retrieved from the ITF controlData section, element “tlcIdentifier” in “controller”. | |
| Access | ConsumerProvider | |
| RR/W | ||
| Representation | {Access ObjectIDidR ProductInformationTLCInfoR/W ProductInformationITSInfoR/W ProductInformationRISInfoR } | |
| Range | N/A | |
| Unit | N/A | |
ProductInformation
| Descriptive name | Productinformation of an iTLC Component |
| Definition | manufacturerName, certifiedName and certifiedVersion shall literally correspond with the manufacturer name, product name and product version listed on iTLC certificate of the product. Set to null if unknown or not available. version needs be used to indicate the actual product version (which is relevant if the actual product version differs from the version on the certificate). Semantic versioning is mandatory for certifiedVersion and version. Note: the certifiedVersion and version received over TLC-FI from the TLC need to be converted to a string on the following way “major.minor.revision” |
| Representation | { ManufacturerNamemanufacturerName ProductNamecertifiedName ProductVersioncertifiedVersion ProductVersionversion } |
| Range | N/A |
| 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 productversion of a 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 |
ManufacturerName
| Descriptive name | ManufacturerName |
| Definition | The name of the manufacturer of a 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 |
5.15 Protocol objects
This section contains the objects that are used for executing the methods as described in section 6.
Comparator
| Descriptive name | Comparator |
| Definition | This object defines the possible comparison operators that can be used when filtering objects. |
| Representation | String |
| Range | CHOICE { "=="Equals. " "Less than. " ="Less than or equal to. "!="Not equal to. ">"Greater than. ">="Greater than or equal to. } |
| Unit | N/A |
ObjectContent (abstract)
| Descriptive name | ObjectContent |
| Definition | Abstract object type to group all data of RIS objects. The contents are defined by the object, indicated by the RISObjectType, itself containing all attributes that are requested within the request parameters. The ObjectID will always be returned regardless of the requested parameters. The rest of the content are the requested attributes of one of the following object types: ItsStation, ItsEvent, Intersection or SignalGroup. |
| Representation | N/A |
| Range | N/A |
| Unit | N/A |
ObjectFilter
| Descriptive name | ObjectFilter |
| Definition | This object defines the selection criteria of objects. When no Selection if given, all the objects of the given Type will be present. The optional and attribute can be used to create a filter for two top-level object attributes. |
| Representation | { RISObjectTypetype SelectionCriteriaselection OPT> SelectionCriteriaand OPT> } |
| Range | N/A |
| Unit | N/A |
ObjectNotification
| Descriptive name | ObjectNotification |
| Definition | This object describes a state change of one or more RIS objects matching a subscription. The ticks attribute defines the moment at which the notification was created by the RIS. The expired attribute is used to notify the subscriber of the expired (or deleted) objects it is subscribed to. Subscribers with a notificationInterval unequal to 0 in their subscription will be notified directly on expiration/deletion of an object. |
| Representation | { SubscriptionIDsubscription ObjectContentobjects[] ObjectIDexpired[] OPT> Ticksticks } |
| Range | N/A |
| Unit | N/A |
ObjectReport
| Descriptive name | ObjectReport |
| Definition | An object describing the data of one or more RIS objects. The ObjectReport represents the contents of the RIS object within the scope of the requested parameters. The ticks attribute defines the moment at which the report was created by the RIS. |
| Representation | { ObjectContentobjects[] Ticksticks } |
| Range | N/A |
| Unit | N/A |
ObjectUpdate
| Descriptive name | ObjectUpdate |
| Definition | This object is used to define object (state) updates. All attribute types of this object are defined in [REF061]. The different updates are in the update attribute. The ticks attribute defines the tick that can be used as reference to the ticks in the state attributes. The time attribute defines the reference time that corresponds to the ticks value. |
| Representation | { ObjectStateUpdateupdate[] Timestamptime Ticksticks } |
| Range | N/A |
| Unit | N/A |
RequestFilter
| Descriptive name | RequestFilter |
| Definition | This object defines the selection and presentation criteria of a request. It determines the content of the ObjectReport. When no Report is given, all the attributes of the object will be present. Only top level attributes of the objects defined in RISObjectType can be used in the Report. |
| Representation | { ObjectFilterfilter Stringreport[] OPT> } |
| Range | N/A |
| Unit | N/A |
SelectionCriteria
| Descriptive name | SelectionCriteria |
| Definition | This object defines the selection filter on (top-level) object attributes. The filter can only be used for attributes that consist of simple types; Integer, Float, Boolean, String or null. For attributes that consist of objects themselves, only the existence can be filtered ( == or != null). When no Comparator is given, by default the == comparison is used. Optional attributes for which a selection value other than null is specified will not match when not present. |
| Representation | { Stringattribute SimpleType>value Comparatorcomparator OPT> } |
| Range | N/A |
| Unit | N/A |
SubscriptionFilter
| Descriptive name | SubscriptionFilter |
| Definition | This object defines the selection and presentation criteria of a subscription. It determines the content of the ObjectNotification. When no NotificationInterval is specified, the ObjectNotification objects are reported as soon as a state change is detected. When a NotificationInterval is specified, the ObjectNotification objects are only reported once every NotificationInterval, including only the last known state of the objects. When no Report is specified, all the attributes of the objects in the ObjectNotification will be present. |
| Representation | { ObjectFilterobjects DurationnotificationInterval OPT> Stringreport[] OPT> } |
| Range | N/A |
| Unit | N/A |
SubscriptionReference
| Descriptive name | SubscriptionReference |
| Definition | This object contains the reference to a subscription. |
| Representation | { SubscriptionIDsubscription } |
| Range | N/A |
| Unit | N/A |
6 Methods
6.1 CreateEvents
This method is used to create a new ItsEvent object with a given set of attributes.
Request:
| Method: CreateEvents | ||
| Parameter name | Type | Description |
| params | ObjectReport | For each ItsEvent all the mandatory attributes, except the ObjectID, must be provided. Optional attributes can be omitted if their value is unavailable. The ObjectID(s) of the created ItsEvent(s) will be returned by the RIS. |
Result:
| Parameter name | Type | Description |
| result | ObjectReference | The ObjectID as generated by the RIS. This serves as a reference for future updates on the event. |
Error:
| Parameter name | Type | Description |
| code | ProtocolErrorCode | See error codes. |
| message | String | Optional message. |
Example
{
"method": "CreateEvents",
"params": {
"objects": [
{
"detectionTime": 1468914482126,
"eventType": 92,
"eventSubType": 0,
"eventPosition": {
"latitude": 52.0243508,
"longitude": 5.1412147,
"elevation": 5.0
},
"validityDuration": 900,
"relevanceDistance": 800,
"trafficDirection": 1,
"traces": [
{
"points": [
{
"latitude": 52.0238990,
"longitude": 5.1375616
},
{
"latitude": 52.0239930,
"longitude": 5.1375619
}
]
}
],
"destinationArea": {
"centre": {
"latitude": 52.0243508,
"longitude": 5.1412147
},
"majorAxis": 900,
"minorAxis": 900,
"angle": 0,
"circular": true
},
"repetitionInterval": 1000
}
],
"ticks": 1808
},
"id": 27,
"jsonrpc": "2.0"
}
{
"result": {
"type": 2,
"ids": [ "71004_5" ]
},
"id": 27,
"jsonrpc": "2.0"
}
6.2 UpdateObjects
This method is used to update the writable attributes of RIS objects when a change is detected.
The objects that can be updated are: ItsEvent, Intersection, ActivePrioritization and Signalgroup.
Not all the writable attributes of an object need to be provided with an update.
The following rules apply:
The following rules apply:
- The update to all objects in one method invocation is atomic.
- Attributes that are not supplied will keep their current value.
- Optional attributes that are set to null are removed.
Request:
| Method: UpdateObjects | ||
| Parameter name | Type | Description |
| params | ObjectUpdate | The ObjectUpdate object is used here to provide the objects and the attributes that need to be updated. In order to generate absolute times for the signal group predictions from the ticks received from the TLC-FI, the reference time of these ticks needs to be provided. |
Result:
| Parameter name | Type | Description |
| result | - | On successful update an empty object is returned. |
Error:
| Parameter name | Type | Description |
| code | ProtocolErrorCode | See error codes. |
| message | String | Optional message. |
Example (see next page)
{
"method": "UpdateObjects",
"params": {
"update": [
{
"objects": {
"type": 2,
"ids": [ "71004_5" ]
},
"states": [
{
"detectionTime": 1468914487454,
"eventPosition": {
"latitude": 52.024404,
"longitude": 5.1415781
},
"validityDuration": 600,
"relevanceDistance": 450,
"trafficDirection": 0,
"repetitionInterval": 2000
}
]
},
{
"objects": {
"type": 4,
"ids": [ "103_FC02", "103_FC08" ]
},
"states": [
{
"state": 6,
"validityDuration": 1,
"predictions" : [ {
"state": 3,
"likely":3712
} ]
},
{
"state": 4,
"validityDuration": 1,
"predictions" : [ {
"state": 6,
"likely":1463
} ]
}
]
}
],
"time": 1468914487673,
"ticks": 1380
},
"id": 28,
"jsonrpc": "2.0"
}
{
"result": {},
"id": 28,
"jsonrpc": "2.0"
}
6.3 TerminateEvents
This method is used to terminate (remove) a previous created ItsEvent.
Request:
| Method: TerminateEvents | ||
| Parameter name | Type | Description |
| params | ObjectReference | The ObjectID, that was returned as reference by the RIS, of the ItsEvent to be terminated. |
Result:
| Parameter name | Type | Description |
| result | - | On successful removal an empty object is returned. |
Error:
| Parameter name | Type | Description |
| code | ProtocolErrorCode | See error codes. |
| message | String | Optional message. |
Example
{
"method": "TerminateEvents",
"params": {
"type": 2,
"ids": [ "71004_5" ]
},
"id": 29,
"jsonrpc": "2.0"
}
{
"result": {},
"id": 29,
"jsonrpc": "2.0"
}
6.4 RequestObjects
This method is used to request objects from the RIS of the current traffic state.
The requesting application is provided with an ObjectReport object containing the objects that match the request filter.
Request:
| Method: RequestObjects | ||
| Parameter name | Type | Description |
| params | RequestFilter | The request filter describing what type of objects are requested to and how to report them. |
Result:
| Parameter name | Type | Description |
| result | ObjectReport | Array containing the data of the object(s) matching the request filter. Only the attributes defined in the report are returned. |
Error:
| Parameter name | Type | Description |
| code | ProtocolErrorCode | See error codes. |
| message | String | Optional message. |
Example (request all ItsStations with a length greater than 4.5 meters)
{
"method": "RequestObjects",
"params": {
"filter": {
"type":1,
"selection": {
"attribute": "length",
"value": 4.5,
"comparator": ">"
}
},
"report": [ "stationType", "speed", "matches" ]
},
"id": 5,
"jsonrpc": "2.0"
}
{
"result": {
"objects": [
{
"id": "373552793",
"stationType": 6,
"speed": 13.8,
"matches" : [
{
"intersection" : "103",
"lane": 2,
"signalgroup": "103_FC01",
"distance" : 73.8,
"offset" : 3.1
}
]
},
{
"id": "56946",
"stationType": 7,
"speed": 22.2,
"matches" : [
{
"intersection" : "103",
"lane": 12,
"distance" : 27,
"offset" : 1.4
}
]
}
],
"ticks": 64506
},
"id": 5,
"jsonrpc": "2.0"
}
6.5 SubscribeObjects
This method is used to set a subscription for objects from the RIS.
The requesting application is provided with an initial ObjectNotification object containing the objects that match the subscription filter. Successive updates and changes matching the subscription filter will be communicated through the NotifyObjects method.
ITS applications may subscribe more than once to the same object type with different subscription filters.
Note: Objects that match the subscription filter can also be notified on updates even when none of the attributes in the report have changed.
Request:
| Method: SubscribeObjects | ||
| Parameter name | Type | Description |
| params | SubscriptionFilter | The subscription filter describing what type of objects to subscribe to and how to report them. |
Result:
| Parameter name | Type | Description |
| result | ObjectNotification | Array containing the data of the object(s) matching the subscription filter. Only the attributes defined in the report are returned. |
Error:
| Parameter name | Type | Description |
| code | ProtocolErrorCode | See error codes. |
| message | String | Optional message. |
Example (subscribe to all ItsStations of type bus that are map-matched)
{
"method": "SubscribeObjects",
"params": {
"objects": {
"type": 1,
"selection": {
"attribute": "stationType",
"value": 6
},
"and": {
"attribute": "matches",
"value": null,
"comparator": "!="
}
},
"report": [ "role", "roleAttributes", "matches" ]
},
"id": 12,
"jsonrpc": "2.0"
}
{
"result": {
"subscription": "4624",
"objects": [],
"ticks": 1808
},
"id": 12,
"jsonrpc": "2.0"
}
6.6 NotifyObjects
This method is used to notify an ITS-Application when objects from the RIS changed according to a subscription that was previously placed.
Notification:
| Method: NotifyObjects | ||
| Parameter name | Type | Description |
| params | ObjectNotification | Object updates. Only the attributes specified in the corresponding Report are present in the content. Note: Objects that match the subscription filter can also be notified on updates even when none of the attributes in the report have changed. |
Example (notification of a map-matched ItsStation of type bus )
{
"method": "NotifyObjects",
"params": {
"subscription": "4624",
"objects": [
{
"id": "373552793",
"role": 1,
"roleAttributes": {
"publicTransport": {
"embarkation": false,
"lineNr": 9,
"serviceNr": 45,
"journeyNr": 44,
"companyNr": 512,
"punctuality": -23
}
},
"matches": [
{
"intersection": "103",
"lane": 2,
"signalGroup": "103_FC01",
"distance": 73.8,
"offset": 3.1
},
{
"intersection": "103",
"lane": 3,
"signalGroup": "103_FC02",
"distance": 74.3,
"offset": 2.6
}
]
}
],
"ticks": 31513
},
"jsonrpc": "2.0"
}
6.7 UnsubscribeObjects
This method is used to remove a previously set subscription at the RIS.
Request:
| Method: UnsubscribeObjects | ||
| Parameter name | Type | Description |
| params | SubscriptionReference | The subscription identifier that was returned with the creation of the subscription. |
Result:
| Parameter name | Type | Description |
| result | - | On successful removal an empty object is returned. |
Error:
| Parameter name | Type | Description |
| code | ProtocolErrorCode | See error codes. |
| message | String | Optional message. |
Example
{
"method": "UnsubscribeObjects",
"params": {
"subscription": "4624"
},
"id": 230,
"jsonrpc": "2.0"
}
{
"result": {},
"id": 230,
"jsonrpc": "2.0"
}
7 Protocol error handling
7.1 Error codes
The RIS facility interface part uses the generic error codes as defined in [REF061], and the RIS-FI specific codes in the range 2001 - 3000.
| Code | Description |
| 2001 | Object not created |
| 2002 | ObjectID does not exist |
| 2003 | Object type inconsistent with object indicated by ObjectID |
| 2004 | Object not deleted |
| 2005 | Parameter out of range |
8 Functional use-cases
This section contains the use-cases describing the functional behaviour of the entities communicating over the interface.
8.1 Monitoring of traffic
| Name | Monitoring of traffic |
| Description / context | The RIS receives information about other ITS stations in the neighbourhood via Cooperative Awareness Messages (CAM), such as:
In case the ITS station does not exist in the Local Dynamic Map (LDM) a new ItsStation object is created in the LDM, otherwise the existing ItsStation object is updated. The ITS station may be mapped on the topology of the intersection. In this way, the LDM holds the current view of the traffic in the LDM. ITS applications can take a subscription on the LDM to be notified on changes in the LDM. |
| Actor | ITS-CRA |
| Goal | To get a continuous updated view of the traffic situation on the intersection. |
| Pre-condition(s) | The ITS-CRA is registered and authenticated at the RIS. |
| Trigger | A change in the traffic situation is received by the RIS i.e. a CAM is received. |
| ITS-CRA functions | The ITS-CRA executes the method SubscribeObjects at the RIS with object type ItsStation (1). The ITS-CRA waits for the response of the RIS. Note: The ITS-CRA may also use a filter to be notified of ItsStation objects that are map-matched for example. Note: The ITS-CRA could also indicate which attributes to receive in the notification. |
| RIS functions | When the method SubscribeObjects is invoked
When a CAM is received by the RIS
|
| Post-conditions | - |
| Exception 1 | The subscription parameters are invalid.
|
| End result | The LDM holds the current updated view on the traffic and subscribed ITS applications are informed on the view. |
8.2 Bus priority handling
An ITS application can use subscriptions at the RIS to get notified on approaching public transport vehicles (busses). With this information a prioritization request can be made using the TLC-FI. Prioritization will be done based on ITS G5 message SRM. The prioritization status can be informed by two types of ITS G5 messages; SPAT and SSM.
| Name | Bus priority handling based on SRM |
| Description / context | The RIS receives information about busses in the neighbourhood via Cooperative Awareness Messages (CAM) and Signal Request Messages (SRM). Based upon this information, an ITS-A can request for priority at the TLC-FI to give way to these busses. Also the status of currently active or pending prioritizations can be broadcasted with a Signal Status Message (SSM). |
| Actor | ITS-CRA |
| Goal | To give priority to busses crossing the intersection. |
| Pre-condition(s) | The ITS-CRA is registered and authenticated at the RIS and has sufficient credentials to update the active prioritizations. |
| Trigger | A bus is approaching the intersection broadcasting CAM and SRM. |
| ITS-CRA functions | The ITS-CRA executes the method SubscribeObjects at the RIS with object type PrioritizationRequest (6) with possible filter on role (1) and subrole (1). Note: The ITS-CRA could also indicate which attributes to receive in the notification. Note: The ITS-CRA could also take a subscription on the ItsStation object to track the bus, or to provide extra information about position, speed, etc. When the method NotifyObjects is invoked
|
| RIS functions | When the method SubscribeObjects is invoked
When a SRM from a bus is received by the RIS
When the method UpdateObjects is invoked
Note: an ActivePrioritization is valid when the corresponding PrioritizationRequest has not expired. |
| Post-conditions | - |
| Exception 1 | The subscription parameters are invalid.
|
| End result | A priority is handled for the approaching bus. |
8.3 Create an ItsEvent
| Name | Create an ItsEvent |
| Description / context | Events are used to inform ITS stations about potentially dangerous situations (e.g. Traffic jam ahead, animal on the road, bad weather condition etc.). In the case that an ITS application detects such a dangerous situation, it can request the RIS to create an ItsEvent object. An event contains at least the following attributes:
The ItsEvent object is stored in the LDM and a Decentralized Environment Notification Message (DENM) is made which is broadcasted to other ITS stations in the neighbourhood. |
| Actor | ITS-PRA |
| Goal | Inform other ITS stations of a potentially dangerous situation using DENM. |
| Pre-condition(s) | The ITS-PRA is registered and authenticated at the RIS. |
| Trigger | The ITS-PRA detects a potentially dangerous situation. |
| ITS-PRA functions | The ITS-PRA executes the method CreateEvents at the RIS with (at least) all the mandatory attributes present. |
| RIS functions | When the method CreateEvents is invoked
|
| Post-conditions | If configured the DENM is repeatedly transmitted until it is expired. |
| Exception 1 | The request is invalid.
|
| End result | The newly created ItsEvent object is stored in the LDM and the associated DENM message is broadcasted. The exact moment in time the DENM is broadcasted is up to the RIS and the applicable radio conditions. |
8.4 Update an ItsEvent
| Name | Update an ItsEvent |
| Description / context | The ITS application has previously detected a potentially dangerous situation and created an ItsEvent object for this situation. The ITS application continues to monitor the situation and detects a change in the situation e.g. changed location, validity time. The ITS application updates the ItsEvent object at the RIS using the reference it received when it created the ItsEvent object. |
| Actor | ITS-PRA |
| Goal | Inform other ITS stations the updated information about the situation using DENM messages. |
| Pre-condition(s) | The ITS-PRA is registered and authenticated at the RIS and has a reference to a previously created ItsEvent (by the same ITS-PRA). |
| Trigger | The ITS application detects a change in the situation. |
| ITS-PRA functions | The ITS-PRA executes the method UpdateObjects at the RIS for object type ItsEvent (2) and the object reference to update. Note: for an update only the attributes of which the value have changed need to be provided. |
| RIS functions | When the method UpdateObjects is invoked for an ItsEvent
|
| Post-conditions | If configured the DENM is repeatedly transmitted until it is expired. |
| Exception 1 | The request is invalid.
|
| Exception 2 | The ItsEvent does not exist.
|
| Exception 3 | The ITS-PRA is not the owner of the ItsEvent
|
| End result | The ItsEvent object is updated in the LDM and the associated updated DENM message is broadcasted. The exact moment in time the DENM is broadcasted is up to the RIS and the applicable radio conditions. |
8.5 Delete an ItsEvent
| Name | Delete an ItsEvent |
| Description / context | The ITS application has created an ItsEvent object for a potentially dangerous situation and the situation no longer exists. The ITS application wants to inform the other ITS stations that the situation no longer exists and deletes the ItsEvent object at the RIS. The ItsEvent is removed from the LDM and the associated DENM message with termination indication is broadcasted. |
| Actor | ITS-PRA |
| Goal | Inform other ITS stations of the no longer existing situation using DENM messages. |
| Pre-condition(s) | The ITS-PRA is registered and authenticated at the RIS and has a reference to a previously created ItsEvent (by the same ITS-PRA). |
| Trigger | The ITS application detects that the situation no longer exists. |
| ITS-PRA functions | The ITS-PRA executes the method TerminateEvents at the RIS for object type ItsEvent (2) and the object reference to delete. |
| RIS functions | When the method TerminateEvents is invoked for an ItsEvent
|
| Post-conditions | The DENM is broadcasted only once, without repetition. |
| Exception 1 | The request is invalid.
|
| Exception 2 | The ItsEvent does not exists.
|
| Exception 3 | The ITS-PRA is not the owner of the ItsEvent
|
| End result | The ItsEvent object is removed from the LDM and the associated DENM message with termination indication is broadcasted. The exact moment in time the DENM is broadcasted is up to the RIS and the applicable radio conditions. |
8.6 Monitoring of events
| Name | Monitoring of events |
| Description / context | In addition of creating ItsEvent objects, ITS applications can also be informed of potentially dangerous situations detected or relayed by other ITS stations. |
| Actor | ITS-CRA |
| Goal | To be informed about a potentially dangerous situation detected by other ITS stations. |
| Pre-condition(s) | The ITS-CRA is registered and authenticated at the RIS. |
| Trigger | A change in the traffic situation is received by the RIS i.e. a DENM is received. |
| ITS-CRA functions | The ITS-CRA executes the method SubscribeObjects at the RIS with object type ItsEvent (2). The ITS-CRA waits for the response of the RIS. Note: The ITS-CRA may also use a filter to be notified of ItsEvent objects that have a certain direct cause for example. Note: The ITS-CRA could also indicate which attributes to receive in the notification. |
| RIS functions | When the method SubscribeObjects is invoked
When a DENM is received by the RIS
|
| Post-conditions | - |
| Exception 1 | The subscription parameters are invalid.
|
| End result | The LDM holds the current valid ItsEvent(s) and subscribed ITS applications are informed on the ItsEvent(s). |
8.7 Inform on the signalling status
| Name | Inform on the signalling status |
| Description / context | The state of signal groups of an intersection provided by an active ITS CLA should be broadcasted to other ITS stations with the Signal Phase and Timing (SPAT) messages. |
| Actor | ITS-CLA |
| Goal | To inform other ITS stations on the signalling status of the intersection(s). |
| Pre-condition(s) | The ITS-CLA is registered and authenticated at the RIS and is in control of the intersection (controlState = InControl or EndControl). |
| Trigger | The ITS-CLA receives information on changes in the signalling state from the Traffic Light Controller (TLC) via the TLC-FI. |
| ITS-CLA functions | The ITS-CLA writes the signal group states received from the TLC-FI by executing the UpdateObjects method for the object types Intersection (3) and SignalGroup (4). When the status of the TLC has changed
When the state of a SignalGroup has changed Sets SignalGroup.state to the current state of the signal group. When the ITS-PRA has calculated advisory speeds
|
| RIS functions | When the method UpdateObjects is invoked
|
| Post-conditions | - |
| Exception 1 | The request is invalid.
|
| End result | The signalling information on the intersection(s) is updated in the LDM and the associated SPAT message is broadcasted periodically. |
8.8 State and predictions
| Name | State and predictions |
| Description / context | This use case applies to an ITS-CLA with a Prediction Verification Logic function, which sends signal group predictions directly to the RIS. The ITS-CLA control state machine is outlined in [REF060] section 7.1. |
| Actor | ITS-CLA, RIS |
| Goal | To inform other ITS stations on the signalling status of the intersection(s). |
| Pre-condition(s) | TLC-FI connection established between ITS-CLA and TLC facilities. RIS-FI connection established between ITS-CLA and RIS facilities. |
| Trigger | The ITS-CLA is registered and authenticated at the RIS. |
| ITS-CLA functions |
The ITS-CLA claims ownership of the intersection and associated signal groups
|
| RIS functions | When the method UpdateObjects is invoked
|
| Post-conditions | - |
| Exception 1 | The request is invalid.
|
| Exception 2 | Setting intersection or signal group attributes by an ITS-A that does not have the ownership of the intersection. Attributes are not updated
|
| Exception 3 | Alive timeout on the session (with the ITS-CLA that has ownership).
|
| Exception 4 |
|
| Exception 5 | The RIS Facilities detects that Intersection.state has not been updated for 60 seconds (while an ITS-A has ownership). Reset the intersection and associated signal groups to the default state ((i.e. 'noValidSPATisAvailableAtThisTime').
|
| Exception 6 | The ITS-CLA (that is in control of the intersection) claims ownership while intersection.owner != null. (i.e. another ITS-A has the ownership of the intersection) An error message (ProtocolErrorCode=NotAuthorized(1)) is returned. The ITS-CLA shall log an error.
|
| Exception 7 | An ITS-A writes an invalid sessionId to intersection.owner.
|
| End result | The signalling information on the intersection(s) is updated in the LDM and the associated SPAT message is broadcasted periodically. |
8.9 Inform on configuration
| Name | Inform on configuration |
| Description / context | Provide configuration information of the ITS-CLA and TLC. |
| Actor | ITS-CLA, RIS |
| Goal | The RIS knows the configuration information of the ITS-CLA and the TLC. |
| Pre-condition(s) | The ITS-CLA controls the first intersection listed in RISFacilities.intersections[] (see exception 4). |
| Trigger | ITS-CLA connected to the RIS. |
| ITS-CLA functions | When the ITS-CLA gets in control (Application.ControlState = StartControl) it performs the following actions: Set ConfigurationInformation.ITSInfo = ITS-CLA info> Set ConfigurationInformation.TLCInfo = TLC info> |
| RIS Facilities functions | At startup the RIS Facilities clears the ConfigurationInformation object. When an update of the ConfigurationInformation object is received the RIS forwards the ConfigurationInformation towards UDAP. |
| Post-conditions | - |
| Exception 1 | RIS-FI connection with ITS-CLA lost No action in RIS or ITS-CLA (i.e. RIS remembers the last received configuration information). |
| Exception 2 | RIS-FI connection established while ITS-CLA is inControl The ITS-CLA performs the following actions: Set ConfigurationInformation.ITSInfo = ITS-CLA info> Set ConfigurationInformation.TLCInfo = TLC info> |
| Exception 3 | Older version TLC (i.e. TLC that does not support configuration information) The ITS-CLA performs the following action: Detect older version TLC (based on TLC-FI protocol version) Set ConfigurationInformation.TLCInfo = null |
| Exception 4 | Multiple TLC s connected to the ITS-CLA The ITS-CLA publishes the configuration information of the first TLC only. |
| Exception 5 | Multiple active ITS-CLA s Only the ITS-CLA that controls the first intersection (see pre-conditions) executes this use case. Other ITS-CLA s do not execute this use case (i.e. do not write ConfigurationInformation) |
| End result | The RIS has/knows the configuration information of the iTLC components (TLC, ITS application and RIS). |
9 Exception handling use-cases
9.1 Invalid request
The request method is not recognized.
9.2 Invalid parameters
The input parameters in a request are not valid.
9.3 Request could not be completed
The request could not be completed due to an RIS internal error situation.
9.4 Not authorized
The request is not authorized for the user
9.5 Invalid Object reference
For Objects than can expire, or are dynamically created and removed by the RIS, the connection must not be closed; only an error may be returned. This deviates from the Generic-FI ([REF061]).
10 Compatibility
The compatibility described in this section applies to the following older RIS-FI protocol versions.
- Protocol version 1.2.0 (this version is deprecated and systems in the field have been updated)
- Protocol version 1.2.1
10.1 ITS-A (2.0.0) versus RIS (1.2.1)
This combination of protocol versions is not compatible, because:
- The RIS Facilities will identify ProductInformation as an unknown object type and close the connection (see [REF061] section 9.5 item 2).
A RIS Facilities that implements protocol version 1.2.x does not support protocol negotiation.
An ITS-A that supports 2.0.0 and 1.2.1 can use protocol negotiations to establish a connection with RIS Facilities version 1.2.1. The ITS-A shall register with:
- RegistrationRequest.supportedVersions=(2,0,0),(1,2,1).
- RegistrationRequest.version=(1.2.1)
The RIS Facilities will:
- (Silently) ignore RegistrationRequest.supportedVersions
- Replies with RegistrationResponse.version=(1.2.1)
The ITS-A shall then use protocol version 1.2.1, meaning that:
- The ITS-A will not send ProductInformation to the RIS Facilities.
- The ITS-A can send queueLength (i.e. the RIS Facilities will silently ignore this attribute).
N.B. An ITS-A that only supports version 2.0.0 (or higher) shall close the connection with the RIS Facilities when RegistrationResponse.version=(1.2.1) or (1.2.0)
10.2 ITS-A (1.2.1) versus RIS (2.0.0)
This combination of protocol versions is not compatible, because:
- direction and positionConfEllipse are not available in version 1.2.1 and mandatory attributes of the ItsStation object in version 2.0.0.
A ITS-A that implements protocol version 1.2.1 does not support protocol negotiation and shall ignore the direction and positionConfEllipse attributes of the ItsStation object sent by the RIS.
Appendix A Country specific public transport encoding
The CAM data provided by public transport vehicles is encoded in a country specific way.
PtActivation ::= SEQUENCE {
ptActivationType PtActivationType,
ptActivationData PtActivationData
}
PtActivationType ::= INTEGER {undefinedCodingType(0), r09-16CodingType(1), vdv-50149CodingType(2)} (0..255)
PtActivationData ::= OCTET STRING (SIZE(1..20))
The table below shows the fields defined in the Dutch KAR standard that are not present in any form in the ETSI message set, and thus are encoded in the PtActivationData.
The PtActivationData contents for the Netherlands have been defined in [REF094].
| Octet # | KAR field name | size | RIS attribute |
| 0, 1 | Line number PT | 16 bits unsigned | lineNr |
| 2, 3 | Vehicle ID | 16 bits unsigned | vehicleID |
| 4, 5 | Block number | 16 bits unsigned | serviceNr |
| 6, 7 | Journey number | 16 bits unsigned | journeyNr |
| 8, 9 | Support journey number | 16 bits unsigned | supportNr |
| 10 | Company number | 8 bits unsigned | companyNr |
| 11, 12 | Occupancy | 16 bits unsigned | Occupancy |
16 bit numbers are encoded in big endian format (most significant octet first).
The table below shows the mapping between the KAR fields, the RIS attributes and the related ETSI messages.
| CVN Nr | Fieldname | Size (in bytes) | Range | RIS attribute | ITS G5 message |
| 1 | Virtual local loop number | 1 | 0..127 | approach/signalGroup | SRM |
| 2 | Vehicle type | 1 | 0..99 | stationType | CAM |
| 3 | Line number PT | 2 | 0 9999 | CAM (PtActivation) | |
| 4 | Block number | 2 | 0 9999 | CAM (PtActivation) | |
| 5 | Company number | 1 | 0 255 | CAM (PtActivation) | |
| 6 | Vehicle id | 2 | 0 32767 | CAM (PtActivation) | |
| 7 | Direction at intersection/signal group number | 1 | 0 255 | approach/signalGroup | SRM |
| 8 | Vehicle status | 1 | 0 99 | Embarkation | CAM |
| 9 | Priorityclass | 1 | 0 99 | SRM | |
| 10 | Punctualityclass | 1 | 0 99 | ||
| 11 | Punctuality [s] | 2 | -3600 to +3600 | SRM | |
| 12 | Vehicle / train length [m] | 1 | 0 255 | length | CAM |
| 13 | Actual vehicle speed [m/s] | 1 | 0 99 | speed | CAM |
| 14 | Distance till passage stop line [m] | 2 | -99 to 9999 | distance | CAM / MAP |
| 15 | Driving time till passage stop line | 1 | 0 255 | speed / distance | CAM / MAP |
| 16 | Journey number | 2 | 0 9999 | CAM (PtActivation) | |
| 17 | Type of Journey or Fortify seq number | 1 | 0 99 | ||
| 18 | Route Public Transport | 1 | 0 99 | SRM | |
| 19 | Type of command | 1 | 0 99 | requestType | SRM |
| 20 | Activation pointnr | 2 | 0 32767 | ||
| 21a | Location- reference Latitude [degrees] | 1 | 0 89 | location | CAM |
| 21b | Location-reference Latitude [minutes] | 1 | 0 59 | location | CAM |
| 21c | Location-reference Latitude [seconds] | 1 | 0 59 | location | CAM |
| 21d | Location-reference Latitude [hundreds of seconds] | 1 | 0 99 | location | CAM |
| 21e | Location-reference Longitude [degrees] | 1 | 0 179 | location | CAM |
| 21f | Location-reference Longitude [minutes] | 1 | 0 59 | location | CAM |
| 21g | Location-reference Longitude [seconds] | 1 | 0 59 | location | CAM |
| 21h | Location-reference Longitude [hundreds of seconds] | 1 | 0 99 | location | CAM |
| 22a | Year | 2 | 0 9999 | locationTime | CAM |
| 22b | Month | 1 | 1 12 | locationTime | CAM |
| 22c | Day | 1 | 1 31 | locationTime | CAM |
| 22d | Hours | 1 | 0 23 | locationTime | CAM |
| 22e | Minutes | 1 | 0 59 | locationTime | CAM |
| 22f | Seconds | 1 | 0 59 | locationTime | CAM |
| 23 | Reserve | 2 | |||
| 24 | Reserve | 2 |
Appendix B
TISA specification TAWG11071 (2011-11-07, drafted to potentially become ISO/TS 21219
Part 15): "Intelligent Transport Systems (ITS) - Traffic and Travel Information (TTI) via Transport
Protocol Experts Group, Generation 2 (TPEG2) - Part 15: Traffic Event Compact
(TPEG2-TEC-3.1/001)".
Part 15): "Intelligent Transport Systems (ITS) - Traffic and Travel Information (TTI) via Transport
Protocol Experts Group, Generation 2 (TPEG2) - Part 15: Traffic Event Compact
(TPEG2-TEC-3.1/001)".
| Cause code description | Direct cause code | Mapping with TPEG-TEC | Sub cause code | Sub cause description |
| Traffic condition | 1 | Specified as traffic congestion in tec002 of clause 9.2 in TISA TAWG11071 [i.10] | 0 | Unavailable |
| 1 | As specified in tec101 of clause 9.11 in TISA TAWG11071 [i.10] | |||
| 2 | Traffic jam slowly increasing, as specified in clause 5.3.8 in ETSI TS 101 539-1 [i.4], not specified in TISA TAWG11071 [i.10] | |||
| 3 | Traffic jam increasing, as specified in clause 5.3.8 in ETSI TS 101 539-1 [i.4], not specified in TISA TAWG11071 [i.10] | |||
| 4 | Traffic jam strongly increasing, as specified in clause 5.3.8 in ETSI TS 101 539-1 [i.4], not specified in TISA TAWG11071 [i.10] | |||
| 5 | Traffic stationary, as specified in clause 5.3.8 in ETSI TS 101 539-1 [i.4], not specified in TISA TAWG11071 [i.10] | |||
| 6 | Traffic jam slightly decreasing, as specified in clause 5.3.8 in ETSI TS 101 539-1 [i.4], not specified in TISA TAWG11071 [i.10] | |||
| 7 | Traffic jam decreasing, as specified in clause 5.3.8 in ETSI TS 101 539-1 [i.4], not specified in TISA TAWG11071 [i.10] | |||
| 8 | Traffic jam strongly decreasing, as specified in clause 5.3.8 in ETSI TS 101 539-1 [i.4], not specified in TISA TAWG11071 [i.10] | |||
| Accident | 2 | Specified as accidents in tec002 of clause 9.2 in TISA TAWG11071 [i.10] | 0 | Unavailable |
| 1 to 7 | As specified in tec102 of clause 9.12 in TISA TAWG11071 [i.10] | |||
| 8 | Assistance requested (e-call) | |||
| Roadworks | 3 | Specified as road works in tec002 of clause 9.2 in TISA TAWG11071 [i.10] | 0 | Unavailable |
| 1 to 3 | As specified in tec103 of clause 9.13 in TISA TAWG11071 [i.10] | |||
| 4 | Short-term stationary roadworks | |||
| 5 | Street cleaning | |||
| 6 | Winter service | |||
| Adverse weather condition - adhesion | 6 | Specified as slippery road in tec002 of clause 9.2 in TISA TAWG11071 [i.10] | 0 | Unavailable |
| 1 to 10 | As specified in tec106 of clause 9.16 in TISA TAWG11071 [i.10] | |||
| Hazardous location - Surface condition | 9 | Specified as hazardous driving conditions in tec002 of clause 9.2 in TISA TAWG11071 [i.10] | 0 | Unavailable |
| 1 to 9 | As specified in tec109 of clause 9.18 in TISA TAWG11071 [i.10] | |||
| Hazardous location - Obstacle on the road | 10 | Specified as objects on the road in tec002 of clause 9.2 in TISA TAWG11071 [i.10] | 0 | Unavailable |
| 1 to 7 | As specified in tec110 of clause 9.19 in TISA TAWG11071 [i.10] | |||
| Hazardous location - Animal on the road | 11 | Specified as animals on the road in tec002 of clause 9.2 in TISA TAWG11071 [i.10] | 0 | Unavailable |
| 1 to 4 | As specified in tec111 of clause 9.20 in TISA TAWG11071 [i.10] | |||
| Human presence on the road | 12 | Specified as people on roadway in tec002 of clause 9.2 in TISA TAWG11071 [i.10] | 0 | Unavailable |
| 1 to 3 | As specified in tec112 of clause 9.21 in TISA TAWG11071 [i.10] | |||
| Wrong way driving | 14 | Specified as vehicle on wrong carriageway in tec002 of clause 9.2 in TISA TAWG11071 [i.10] | 0 | Unavailable |
| 1 | Vehicle driving in wrong lane | |||
| 2 | Vehicle driving in wrong driving direction | |||
| Rescue and recovery work in progress | 15 | Specified as Rescue and recovery work in progress in tec002 of clause 9.2 in TISA TAWG11071 [i.10] | 0 | Unavailable |
| 1 to 5 | As specified in tec115 of clause 9.23 in TISA TAWG11071 [i.10] | |||
| Adverse weather condition - extreme weather condition | 17 | Specified as extreme weather condition in tec002 of clause 9.2 in TISA TAWG11071 [i.10] | 0 | Unavailable |
| 1 to 6 | As specified in tec117 of clause 9.25 in TISA TAWG11071 [i.10] | |||
| Adverse weather condition - visibility | 18 | Specified as visibility reduced in tec002 of clause 9.2 in TISA TAWG11071 [i.10] | 0 | Unavailable |
| 1 to 8 | As specified in tec118 of clause 9.26 in TISA TAWG11071 [i.10] | |||
| Adverse weather condition -Precipitation | 19 | Precipitation as defined in TISA TAWG11071 [i.10], clause 8.3.2 | 0 | Unavailable |
| 1 to 3 | As defined in tec119 of clause 9.27 in TISA TAWG11071 [i.10] | |||
| Slow vehicle | 26 | Specified as slow moving vehicles in tec002 of clause 9.2 in TISA TAWG11071 [i.10] | 0 | Unavailable |
| 1 to 8 | As defined in tec126 of clause 9.32 in TISA TAWG11071 [i.10] | |||
| Dangerous end of queue | 27 | Specified as dangerous end of Queue in tec002 of clause 9.2 in TISA TAWG11071 [i.10] | 0 | Unavailable |
| 1 to 4 | As defined in tec127 of clause 9.33 in TISA TAWG11071 [i.10] | |||
| Vehicle breakdown | 91 | Values are assigned referring to ETSI TS 101 539-1 [i.4], clause 6.3.3 | 0 | Unavailable |
| 1 | Lack of fuel | |||
| 2 | Lack of battery | |||
| 3 | Engine problem | |||
| 4 | Transmission problem | |||
| 5 | Engine cooling problem | |||
| 6 | Braking system problem | |||
| 7 | Steering problem | |||
| 8 | Tyre puncture | |||
| Post-crash | 92 | Values are assigned referring to ETSI TS 101 539-1 [i.4], clause 6.3.3 | 0 | Unavailable |
| 1 | Accident without e-Call triggered | |||
| 2 | Accident with e-Call manually triggered | |||
| 3 | Accident with e-Call automatically triggered | |||
| 4 | Accident with e-Call triggered without a possible access to a cell network. | |||
| Human problem | 93 | Values are assigned referring to ETSI TS 101 539-1 [i.4], clause 6.3.3 | 0 | Unavailable |
| 1 | Glycaemia problem | |||
| 2 | Heart problem | |||
| Stationary vehicle | 94 | Not specified in TISA TAWG11071 [i.10] Values are assigned referring to ETSI TS 101 539-1 [i.4], clause 6.3.3 | 0 | Unavailable |
| 1 | Human Problem | |||
| 2 | Vehicle breakdown | |||
| 3 | Post-crash | |||
| 4 | Public transport stop | |||
| 5 | Carrying dangerous goods | |||
| Cause code description | Direct cause code | Mapping with TPEG-TEC | Sub cause code | Sub cause description |
| Emergency vehicle approaching | 95 | Not specified in TISA TAWG11071 [i.10] Values are assigned referring to ETSI TS 101 539-1 [i.4], clause 6.3.1 | 0 | Unavailable |
| 1 | Emergency vehicle approaching | |||
| 2 | Prioritized vehicle approaching | |||
| Hazardous location indication - Dangerous Curve | 96 | Not specified in TISA TAWG11071 [i.10]. Values are assigned referring to ETSI TS 101 539-1 [i.4], clause 6.3.7 | 0 | Unavailable |
| 1 | Dangerous left turn curve | |||
| 2 | Dangerous right turn curve | |||
| 3 | Multiple curves starting with unknown turning direction | |||
| 4 | Multiple curves starting with left turn, | |||
| 5 | Multiple curves starting with right turn | |||
| Collision risk | 97 | Intersection collision Not specified in TISA TAWG11071 [i.10] Values are assigned referring to ETSI TS 101 539-2 [i.5] | 0 | Unavailable |
| 1 | Longitudinal collision risk | |||
| 2 | Crossing collision risk | |||
| 3 | lateral collision risk | |||
| 4 | Collision risk involving vulnerable road user | |||
| Signal violation | 98 | Intersection violation | 0 | Unavailable |
| 1 | Stop sign violation | |||
| 2 | Traffic light violation | |||
| 3 | Turning regulation violation | |||
| Dangerous situation | 99 | Not specified in TISA TAWG11071 [i.10] Values are assigned referring to ETSI TS 101 539-1 [i.4], clause 6.3.4 | 0 | Unavailable |
| 1 | Emergency electronic brake lights | |||
| 2 | Pre-crash system activated | |||
| 3 | ESP(Electronic Stability Program) activated | |||
| 4 | ABS (Anti-lock braking system) activated | |||
| 5 | AEB (Automatic Emergency Braking) activated | |||
| 6 | Brake warning activated | |||
| 7 | Collision risk warning activated |