iVRI specificaties

Deze tekst is gepubliceerd op 24-06-21

Specifications iVRI Architecture, iVRI Architecture

Datum besluit SC 08-11-2022
D3047-1 / Version 2.0.1

Disclaimer (NL):

Bij het gebruik en toepassen van de Landelijke iVRI standaarden® is en blijft de gebruiker, te weten de wegbeheerder respectievelijk opdrachtnemer van de wegbeheerder, zelf aansprakelijk voor de mogelijke risico’s die ontstaan of kunnen ontstaan uit het aanbieden of laten aanbieden van (combinaties van) diensten en producten die conform deze standaarden werken in de eigen organisatie of elders in de keten waarvoor de wegbeheerder verantwoordelijk is. Dit geldt in het bijzonder ten aanzien van het verzamelen, opslaan en delen van gegevens en meer specifiek indien daar waar al dan niet direct of indirect herleidbare persoonsgegevens worden verwerkt op grond van de AVG. Gebruikers zijn zelf verantwoordelijk om bij het gebruik van de standaarden telkens na te gaan of gebruik van standaarden, dan wel de combinatie van data vanuit de standaarden in de basis voldoet aan de wet- en regelgeving, in het bijzonder de AVG. Het gebruik conform de standaarden kan het risico op aansprakelijkheid van de wegbeheerder verkleinen, maar niet altijd wegnemen of geheel uitsluiten. Dit is mede afhankelijk van de wijze waarop de wegbeheerder zelf in haar eigen organisatie of bij gebruik van opdrachtnemers in de keten de data verwerkt en gebruikt. Het is dan ook een dringend advies zowel voorafgaand aan de implementatie en ingebruikname door de gebruiker van de standaarden als periodiek een risico-analyse (zoals Data Protection Impact Assessment (DPIA)) en controle van de keten op het gebruik van de standaarden en bijkomende individuele risico’s bij de wegbeheerder en haar opdrachtnemers uit te laten voeren. Het doel van dergelijke analyses en controles is dat mogelijke risico’s die onbedoeld kunnen optreden op voorhand gedentificeerd 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.

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.

1 Introduction

1.1 Purpose and scope

This document describes the architecture of an Intelligent Traffic Light Controller (iTLC), which will be used to integrate the C-ITS domain (connected and cooperative communication with road users) with the TLC domain. The key elements and interfaces of this architecture are outlined in Figure 1.

[ link ]

Figure 1 System overview

The architecture has been set up with the aim of being as compatible as possible with European standardization initiatives such as C-Roads and, where possible, also contributing to improvement.

The intention of the architecture is to allow ITS Applications to use facilities from both the TLC and C-ITS domains through either cooperative (short range) or connected (long-range) channels. The interfaces to a TLC and a Roadside ITS Station are open specifications enabling different vendors to build ITS Applications using both TLCs and Roadside ITS stations (RIS) to support various ITS use-cases and services.

A special type of ITS Application can act as a traffic control application requesting traffic light signal states to the TLC. This way the ITS Application is decoupled from the TLC and RIS by open protocols, which enables various parties to provide such applications.

1.2 Audience

This document has been written for:

Road authorities
ITS Application providers
TLC manufacturers
RIS manufacturers

1.3 Reader advise

The reader is assumed to have knowledge of the ITS- and TLC-domains.

The architecture is documented according to the architectural design approach as described in section 1.4.

1.4 Architectural design approach

The architecture is described according to methodology introduced by Rozanski and Woods, See [REF144]) which implements the ISO42010 Systems and software engineering Architecture description ([REF022]).

The methodology is stakeholder centric. It aims to describe the architecture from the point of view of various stakeholders and their concerns with the architecture. Different views capture relevant concerns of stakeholders, important quality attributes are defined and each view is enriched with input from these quality attributes. I.e. each view is seen from a different perspective. Viewpoints as defined in [REF144] are used as template models to construct the necessary views, by re-using architectural knowledge.

The following views are presented in this architecture description:

Context view in chapter 5
Functional view in chapter 6, 7, 8, 9 and 10
Deployment view in chapter 11
Information view in chapter 12
Concurrency view in chapter 13
Operational view in chapter 13

The quality attributes are described in chapter 14.

The interface requirements for TLC-FI, RIS-FI and VLOG are listed in chapters 15, 16 and 17 respectively.

1.5 References

A complete list of references for the iTLC standards, specifications and profiles is published in D30xx: References for the iTLC standards.

2 Acronyms, abbreviations and concepts

Acronyms and abbreviations

BBV	Beter Benutten Vervolg: Program for standardization of interfaces with TLCs for connected and cooperative functionality
CAM	Cooperative Awareness Message; ETSI defined service and message used for ITS-Station presence, location and status
CCOL	Traffic control algorithm implemented in the C programming language
CEN	European Committee for Standardization
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
C-ITS-S	Central ITS station
CVN	Contactgroep Verkeersregeltechnici Nederland¹⁾ Group of traffic control specialists/engineers in the Netherlands
DENM	Decentralized Environmental Notification Message; ETSI defined service and message used to defined and location notable events (e.g. Road works, accidents, stranded vehicles, congestion)
EMV	EMergency Vehicle
ETSI	European Telecommunications Standards Institute
HSM	Hardware Security Module
IDD	Interface Design Description
IenM	Ministerie van Infrastructuur en Milieu²⁾ Ministry of Infrastructure and the Environment
IRS	Interface Requirements Specification
ISO	International Organization for Standardization
iTLC	Intelligent TLC performing traffic light controller functions and allowing for ITS applications
ITS	Intelligent Transport Systems
ITS Station	Functional entity specified by the ITS station reference architecture (see ETSI EN 302 665, V1.1.1)
IVERA	Management protocol for traffic light controllers in the Netherlands
IVI	In Vehicle Information (see ISO/TS 19321:2015)
KAR	Korte Afstands Radio³⁾ Short Distance Radio; system used to implement prioritization of special vehicles like public transport
LDM	Local Dynamic Map; Concept of data store containing a reflection of physical infrastructure and current on-street traffic and environment
MAP	Message to convey the current road topology to road-users, often used in conjunction with SPAT
N&T	Networking & Transport, a conceptual layer of the ETSI ITS-S reference architecture (see [REF006])
NEN	NEderlands Norm
PTV	Public Transport Vehicle
RIS	See R-ITS-S
RIS-FI	RIS Facilities Interface
R-ITS-S	Roadside ITS Station, responsible for a geographic area.
RSU	Roadside Unit
RWS-C	Traffic control algorithm implemented in the C programming language
SPAT	Signal Phase And Timing message; used to convey the current status of one or more signalized intersections
TCS	Traffic Control System
TLC	Traffic Light Controller; controls the signalling of one or more intersections
TLC-FI	TLC Facilities Interface
TMS	Traffic Management Centre
UDAP	Urban Data Access Point; I2V platform as iVRI overnamepunt for Talking Traffic
VIS	See V-ITS-S
V-ITS-S	Vehicle ITS Station
VLOG	Traffic data log

Concepts

Traffic Control Application	Application which implements a traffic control algorithm and is able to request signal group states
ITS Control Application	A Traffic Control Application which uses TLC- and/or RIS-interfaces
ITS Application	An application which supports one or more ITS use-cases. Range of possible ITS Applications include an ITS Control Application
RIS Facilities	Component providing RIS Facilities to users (internal and/or external). Includes amongst others: Access to information stored in the LDM Services to trigger C-ITS messages
TLC Facilities	Component providing facilities of a TLC to users (internal and/or external). Includes amongst others: Access to information from the TLC Services to trigger actuators
TLC Middleware⁴⁾ Dutch: Procesbesturing	Component of a traffic light controller responsible for physically activating signal groups and process hardware for detection

3 Stakeholders and requirements

3.1 Stakeholders

Road authorities; it is in their interest to be able to deploy iTLCs, independently of a manufacturer, but with standard interfaces and clearly defined behaviour.
TLC manufacturers; who implements the defined architecture and standard interfaces into the various TLC products
RIS manufacturers; who implements the defined architecture and standard interfaces into the various RIS products
Certification bodies; who needs to make sure the system complies with regulations and standards
Standardization bodies; where applicable, the architecture, concepts and interfaces need to comply with standards and regulations
Application providers
Road users
Maintenance engineers

3.2 Overview of requirements

This section contains high level requirements relevant for the architecture presented.

Req-ID	REQ-01
Title	ITS G5 message handling
Description	iTLC is able to receive and transmit ITS G5 messages
Source
Comment

Req-ID	REQ-02
Title	Equal and symmetric access to facilities
Description	ITS Applications can use both TLC Facilities as well as RIS Facilities
Source
Comment

Req-ID	REQ-03
Title	ITS Applications may be deployed on multiple platforms
Description	ITS Applications can for instance be deployed to a TLC, RIS, Central location etc.
Source
Comment

3.3 System scenarios

A separate working group (BBV WG2) has developed use-cases for the iTLC. These use-cases form the basis for the functional and quality scenarios described below. They also serve as a validation and illustration role after this architecture design is complete, both on paper and as the starting point for the tests of an architectural prototype.

3.3.1 Functional scenarios

The following use-cases (see [REF076]) are elaborated as functional scenarios and will be used to verify the architecture:

TT Service	TT Use-case		Description
Priority at TLCs (UC3)	Conditional priority	a1	Priority for public transport
		a2	Priority for heavy trucks
		a3	Priority for platoons of vehicles
		a4	Priority for groups of cyclists
	Absolute priority	b1	Priority for emergency vehicles
In-car information from TLCs (UC4)		1	In-car information on time-to-green for the current lane, including speed advice when approaching the intersection
		2	In-car information on time-to-red for an approaching vehicle, including speed advice within legal boundaries
		3	In-car information on the approach of an emergency vehicle for vehicles waiting at an intersection, including expected waiting time
Optimisation of traffic with TLCs (UC5)		1	Optimisation of signal phases at intersection level, depending in local policies, through use of a combination of all available data
		2	Optimisation of signal phases at intersection level, depending in local policies, through use of a combination of all available data

3.3.2 System quality scenarios

3.3.2.1Signal Phase And Timing (SPAT)-transmission

This scenario describes the way changes in actual signal group states are used to disseminate SPAT-messages. It also describes the (maximum) latencies and possible failures. See section 14.

4 Architectural forces

4.1 Goals

Main goals and business drivers:

Allow for vendor-independent development and deployment of ITS Applications, supporting ITS use-cases. It should be possible to execute vendor-independent applications within the iTLC context.
Enable ITS applications to access TLC Facilities and RIS Facilities regardless of the TLC- or RIS-vendors.
Enable ITS Applications and/or RIS s to be deployed on a TLC, RIS or somewhere else.

4.2 Constraints

Technical capabilities of the installed base TLCs
Architecture description must comply with applicable international and national standards (for example as published by ETSI, CEN/NEN and ISO)
The iTLC still has to comply with all the existing national and international standards like NEN3384, EN12675 and EN50556 etc.

4.3 Principles

Principle Reference	PR-1
Principle Statement	Traffic Light Controller is responsible for safely realizing traffic signal images.
Rationale	TLC actually controls and guards the statuses of the signal groups. It must do this in compliance with national and international standards.
Implications
Further Information

Principle Reference	PR-2
Principle Statement	Comply with international and national standards.
Rationale	Defined architecture shall be aligned with international developments, possibly usable outside the Netherlands as well.
Implications	Use architectural descriptions described in standards. E.g. ETSI reference architecture of an ITS-S
Further Information

Principle Reference	PR-3
Principle Statement	ITS Applications (for example a Traffic Control Application) must be able to access both RIS and TLC Facilities. Multiple ITS Applications can operate at the same time.
Rationale	Market principle, different manufacturers of applications must be given equal opportunities to access TLC and RIS Facilities.
Implications	The interfaces to the facilities must have mechanisms to allow for multiple applications interacting with them
Further Information

Principle Reference	PR-4
Principle Statement	Open standards and protocols shall be used as far as possible.
Rationale	Market principle, different manufacturers of applications must be given equal opportunities to access TLC- and RIS-Facilities.
Implications
Further Information

Principle Reference	PR-5
Principle Statement	Access to RIS Facilities shall be independent of TLC Facilities (and vice versa).
Rationale	Vendor independent solution, allows for instance for situations where there is no TLC nor RIS.
Implications
Further Information

Principle Reference	PR-6
Principle Statement	Interfaces with the TLC and RIS Facilities should allow for international adoption.
Rationale	Alignment with international standards
Implications
Further Information

5 Context view

Describes the relationships, dependencies and interactions between the iTLC and its environment (the people, systems and external entities that it interacts with).

5.1 Context diagram

The following figure describes the top-level context with main interactions.

[ link ]

Figure 2 Context diagram

External entity	Who
Traffic Engineer	Responsible for implementing, defining, designing and functional maintenance of traffic algorithm for the Traffic Control System and/or Intelligent TLC.
Maintenance Engineer	Responsible for operational maintenance of the Intelligent TLC by using diagnostic facilities.
Installation Engineer	Responsible for deployment of hardware, software and infrastructure of the Intelligent TLC.
Road Traffic Manager	Responsible for determining and setting of traffic management policies.
Operator	Executes policies for the traffic system by using the Traffic Management System.
Traffic Control System	External system implementing a traffic control algorithm actively influencing the Intelligent TLC to control traffic. Realizing set traffic control policies.
Traffic Management System	External system responsible for monitoring, evaluation and management of the functional and technical state of the Intelligent TLC and Traffic Control System. Used to set high-level policies.
Traffic Data Centre	Responsible for collecting, aggregating, distributing and managing (e.g. deleting) of traffic data.
Service Provider	Responsible for providing services to one or more customers. Customers can include other systems and end-users.
C-ITS Vehicle	A vehicle equipped with ETSI cooperative functionality using ITS G5 or cellular technology. Complies with the definition of a Vehicle ITS Station (V-ITS-S). For instance a car, lorry or a bicycle.
Other Vehicle	Other vehicle, not being a C-ITS Vehicle.
Road User	A person participating in the traffic. Can be equipped with a personal nomadic device such as a mobile phone, or Personal-ITS-Station.

Table 1 Description of external entities as used in context diagram

5.2 Interaction scenarios

Relevant interaction scenarios can be found in [REF076].

6 Functional view

6.1 High level view

[ link ]

Figure 3 Functional model

Figure 3 provides a high-level view of the functional blocks of the iTLC and major relevant relations with external entities. Note that the relations in some cases define an interface between blocks.

The green interfaces are or will be standardized as part of this architecture:

TLC-FI (TLC Facility Interface)
RIS-FI (RIS Facility Interface)
VLOG
IVERA-TLC (part of IVERA related to TLC-management)
IVERA-APP (part of IVERA related to management of ITS Control Applications)
IVERA-RIS (part of IVERA related to manage the RIS)
UDAP-FI (Interface towards UDAP)

The red interfaces are proprietary and out-of-scope of this document:

TCS-IF (Traffic Control Centre Interface)
TLC-MIF (Traffic Light Controller Middleware Interface)
NF-SAP (Network Facilities Service Access Point).

The ITS Application can take many forms and will in the broad sense support one or more ITS use-cases. To fulfil its use-case it interacts with facilities offered by TLCs and RISs. Instead of using facilities offered by a RIS a ITS Control Application can also directly connect to UDAP. Note that per iTLC there can only be one connection towards UDAP: either via the RIS or directly with the ITS application.

Both the TLC and RIS Facility layers make information and control methods of their own domain available to ITS Applications. Based on access rights, certain ITS Applications can access particular information and/or methods. In particular, write access rights to request traffic signal images and intersection control modes is granted only to specific applications to guarantee consistent signal images.

There may be multiple different ITS Applications executed simultaneously, where each of these applications supports different use-cases and require their own access to the RIS and TLC Facilities. Only the ITS application that controls the intersection/is in control is allowed to write towards RIS Facilities or to provide information to UDAP⁵⁾ In case of a direct connection between ITS application and UDAP there is only one ITS application allowed to connect to UDAP . When this ITS application does not control the intersection/is not in control ( but for example another ITS application is ) , none of the ITS applications is allowed to provide information to UDAP. .

Note that when more than one ITS Application is active only the ITS application that controls the intersection/is in control is allowed to provide asingle consistent VLOG stream to the Traffic Data Centre.

6.2 iTLC conceptual layers

The following figure shows the iTLC functional blocks in relation with existing conceptual functional blocks of the TLC and RIS.

[ link ]

Figure 4 Multiple applications

This architecture is an addition to current TLCs, all containing some sort of conceptual TLC middleware layer⁶⁾ Dutch: Procesbesturing. This layer is responsible for actuation of signal groups as well as processing of detection. It may consist of a supervision circuit to assure traffic safety according to the applicable norms. As can be seen in Figure 4, the TLC Facilities is added as a new interface layer on top of the traditional TLC middleware layer.

Figure 4 shows that multiple ITS applications can use RIS and TLC Facilities, but also that each of those facilities can be used by multiple ITS applications.

In the following chapters, for each of the functional blocks of the iTLC the functional view is described.

7 Functional view - ITS Application

In Figure 5 the interfaces and functional blocks of an ITS Application as used in an iTLC are shown. Note that the functional blocks are defined on a high level as the functionality of an ITS Application may vary considerably.

[ link ]

Figure 5 ITS Application - functional blocks

Element Name	ITS Application
Responsibilities	Supports an ITS use-case by using the TLC and/or RIS Facilities The ITS is UTC-time synchronised.
Functional blocks	ITS Application Management An ITS Application can be managed by a management system. Management for instance comprises setting of parameters and reading logbooks. ITS Functions There are a wide range of ITS Applications, this block fulfils the functions of each ITS Application. Traffic Data The Traffic Data supports a continuous stream of traffic control related events, which can be retrieved from the VLOG interface by a Traffic Data Centre or an internal component for rerouting. Traffic control related events are for example detection-, input-, output- and group events. Also signal group timings and predictions. An ITS Control application must implement this functionality. Prediction Verification Logic The predictions provided by an ITS Application to a RIS or UDAP must be verified by the Prediction Verification Logic. C-ITS messages Idem as for a RIS. See paragraph 9.3.2 for more details. SPAT/MAP service Idem as for a RIS. See paragraph 9.3.3 for more details. Information support (LDM) (optional) Idem as for a RIS. See paragraph 9.3.5 for more details. iTLC configuration The product name and version as listed on the iTLC certificates of the active iTLC components (TLC, RIS, ITS control application) shall be forwarded to UDAP.
Interfaces Provides	IVERA-APP: used for functional management of the ITS application. TCS-IF (optional): Interface for functional influence of the ITS Application when acting as a traffic control application. This interface may be proprietary or standard. VLOG: Used to provide traffic data from the ITS Application to a Traffic Data Centre. VLOG supports 1 VLOG client at the same time
Interfaces Requires	TLC-FI for interaction with a TLC RIS-FI for interaction with a RIS UDAP-FI for interaction with UDAP

A non-exhaustive list of ITS Applications in this context:

Traffic control algorithm
Heavy vehicle detection, extension and priority (Tovergroen)
Speed advice for bicycles and vehicles
Platoon detection (vehicle, bicycle)

7.1 Signal group state and timing

The figure below outlines the processing of signal group state and timing by the ITS-CLA.

[ link ]

Figure 6 Signal group state and prediction

The active ITS-CLA performs the following actions:

It controls the traffic lights by sending signal group state requests to the TLC (reqState)
It forwards the signal group states published by the TLC to RIS (state).
It generates signal group timing (reqPrediction).
It verifies the signal group timing and sends the verified timing to the RIS (predictions)
It generates Time exceptions (e.g. reason delay)
It generates speed profiles (if supported by the ITS-CLA).
It sends the intersection state to RIS.

The ITS-CLA shall guarantee that a consistent set of signal group states published by the TLC is published as a consistent set of signal group states and corresponding timing to the RIS (i.e. the ITS-CLA is not allowed to publish states received from the TLC in one JSON message in multiple JSON message to the RIS. However the ITS-CLA is allowed to combine multiple JSON messages from the TLC into one JSON message towards to the RIS).

The ITS-CLA shall have two functions for processing signal group timing:

A function that generates the signal group timing (in the figure named Traffic Control Algorithm)
A function that verifies the signal group timing (e.g. Prediction Verification Logic)

The responsibilities of the Prediction Verification Logic is described in the table below.

Signal group timing for the current state is mandatory when the signal group is in any of the following states:

StopThenProceed,
StopAndRemain,
PreMovement,
PermissiveMovementAllowed,
ProtectedMovementAllowed,
PermissiveClearance,
ProtectedClearance,
PermissiveMovementPreClearance and
ProtectedMovementPreClearance

N.B. The signal group states (StopThenProceed, .., ProtectedMovementPreClearance) are defined in the TLC-FI and RIS-FI IDD.

N.B. The Prediction Verification Logic outlined in this paragraph is based on an iTLC with a RIS. However the logic also applies to an ITS-CLA with an integrated RIS. In that case the information is not send to the RIS (using RIS-FI), but in a SPAT message to the UDAP.

N.B. Please refer to paragraph 8.3 TLC Functions for a description of the functions performed by the TLC. What is important in this context is that the TLC safeguards that the published signal group state corresponds with the actual state of the traffic light.

N.B. Please refer to paragraph 9.2 for a description of the functions performed by the RIS. What is important in this context is that information published by the ITS-CLA in one JSON message on the RIS-FI is published by the RIS in one SPAT message.

Element Name	Prediction Verification Logic
Responsibilities	The Prediction Verification Logic of an active ITS control application verifies the signal group timing before they are provided to the RIS or UDAP. The following verification rules shall be applied for each signal group: minEnd = maxEnd for any timing prediction. minEnd = likelyEnd for any timing prediction. likelyEnd = maxEnd for any timing prediction. maxEnd is now or in the future The minEnd of the first prediction is greater or equal the remaining minimum signal group state time. The maxEnd of the first prediction is less or equal the remaining maximum signal group state time. (If state is Red) The first prediction does not violate the clearance timing: When a conflicting signal group state is Green: the minEnd of the provided prediction >= the moment at which the minimum possible remaining green time and inter green time of the conflicting signal group ends, or When a conflicting signal group state is Amber or Red: the minEnd of the provided prediction >= the moment at which the minimum possible remaining inter green time of the conflicting signal group ends. The state of the first prediction shall be equal to the state published by the TLC. The ITS-CLA shall take the following actions if any of the verification rules fails: The timing for the signal group shall be cleared (i.e. the ITS-CLA shall publish no timing available). The ITS-CLA shall log an event. The ITS-CLA shall obtain the minimum and maximum signal group state timing (used in rule 5 and 6) from the TLC using the TLC-FI. If the minimum signal group state time configured in the ITS-CLA is higher than the value from the TLC the minimum signal group state time from the ITS-CLA shall be used. If the maximum signal group state time configured in the ITS-CLA is lower than the value from the TLC the maximum signal group state time from the ITS-CLA shall be used. The ITS-CLA shall obtain the clearance timing (used in rule 7) from the TLC using the TLC-FI. If the clearance time configured in the ITS-CLA is higher than the value from the TLC the clearance time from the ITS-CLA shall be used. N.B. The prediction verification logic is timing critical. Please see QA_SAFE_002 in paragraph 14.3 for details.
Permissions	Only the active ITS-CLA is allowed to publish signal group state and timing (to the RIS).
Interfaces	RIS-FI interface, or UDAP-FI interface (in case of ITS-CLA with integrated RIS functionality)

7.2 Abnormal lights

For some signal configurations there is no 1:1 relation between signal heads and connection states, e.g. if a connection is controlled by 2 signals. In such cases the combined state of both signals shall be reflected in the eventState in SPaT. Meaning that the data element eventState (of type DE_MovementPhaseState) in SPaT shall be set to represent the actual allowed movement state permissions according to the applicable traffic rules as indicated by the (both) traffic lights.

The rationale for this principles is that vehicles (road users) need to know the applicable permissions and not the precise physical representation or colour of the physical traffic lights, i.e. the applicable traffic rules are of relevance.

The tables below provide an overview of special signals and how they shall be presented by the ITS-CLA as eventState in SPaT on UDAP-FI or signalGroupState on RIS-FI.

[ link ]

In the following cases a single manoeuvre (connection) is controlled by multiple signal groups, often a primary (main) signal head which halso controls other manoeuvres, combined with a secondary signal such as a single lens. The signals and manoeuvres are treated separately in the tables below.

[ link ]

7.3 Traffic Data

The responsibilities of the Traffic Data is described in the table below.

Element Name	Traffic data
Responsibilities	The Traffic Data provides the active control ITS application with defined and reliable streaming of Traffic Data (VLOG). Note: File based VLOG is stored on the same platform where the ITS control application runs. This might be the TLC.
Permissions	Only the active control ITS application is allowed to provide streaming of Traffic Data (VLOG). N.B. When the control ITS application gets in control it accepts the VLOG connectionrequest from the Traffic Data Centre to be able to provide VLOG data over this connection. When the control ITS application is not in control anymore it has to release the VLOG connection.
Interfaces	VLOG interface from the ITS application to a Traffic Data Centre.

7.4 iTLC configuration

The responsibilities of the iTLC configuration is described in the table below.

Element Name	iTLC configuration
Responsibilities	The iTLC provides the certified product name certified version and actual version of the iTLC components to UDAP.
Permissions	Configuration information of the first active (inControl) ITS control application. Configuration information of the first TLC. Configuration information of the RIS (if applicable). N.B. An iTLC can consists of one or more TLC s and one or more ITS control applications. First refers to the ITS application and/or TLC that controls the first intersection defined in the intersection topology.
Interfaces	TLC-FI interface to provide the configuration information for the TLC to the ITS application. RIS-FI interface to provide the configuration information of the TLC and the ITS application to the RIS. UDAP-FI interface to provide the configuration information to UDAP.

8 Functional view - TLC Facilities

In Figure 7 the interfaces and functional blocks of the TLC Facilities layer as used in an iTLC are shown.

[ link ]

Figure 7 TLC Facilities layer - functional blocks

The responsibilities of the TLC Facilities as used in the iTLC are described in the following table. Each functional block will be elaborated in detail later:

Element Name	TLC Facilities
Responsibility	TLC Facilities provides Traffic Control functionality to ITS Applications, by giving access to TLC Functions and TLC Information through the TLC-FI interface. The TLC Facilities supports multiple ITS Applications at the same time. The TLC is UTC-time synchronised.
Functional Blocks	TLC Access Control ITS Applications first need to authenticate/authorize themselves with the TLC-FI in order to use the TLC Facilities. This login leads to registration of the ITS Application, while predefined permissions for reading and updating TLC Information are granted. TLC Management The TLC supports multiple IVERA connections in order to be managed remotely. Management comprises setting of parameters, selecting programs, reading logbooks, reading group-, detection- and intersection status. It is also used for setting the permissions for ITS Applications, and reading the status of the ITS Applications. TLC Information The TLC Information is the collection of all kinds of runtime TLC Objects that is exchanged between the TLC and multiple ITS Applications over the TLC-FI interface. TLC Functions The TLC Functions is the collection of all kinds of TLC related functions, needed to support a proper exchange of TLC Objects, and processing by the TLC middleware.
Interfaces - Provides	TLC-FI: Used for operational interaction with the TLC. TLC-FI supports at least 10 different ITS Applications simultaneously. IVERA-TLC: Used for operational and functional management of the TLC. IVERA-TLC supports at least 4 different IVERA clients at the same time.
	TLC-MIF: interface with TLC-Middleware, used by TLC-Facilities to for example control outputs and acquire inputs. This interface is vendor specific.

8.1 TLC Access Control

The responsibility of the TLC Access Control as used in the TLC Facilities is described in the following table:

Element Name	TLC Access Control
Responsibility	The TLC Access Control provides the TLC with defined and secure entrance and exit for the different types of ITS Applications over the TLC-FI.
Functionality	Each ITS Application has to log in to the TLC Facility layer with a username/password. The same username/password combination may be used by multiple ITS Applications. The ITS Application is notified of the success (or failure) of authentication. After a number of subsequent incorrect login attempts, the TLC Access Control shall deny following attempts to login by the ITS Application. A new access may be allowed after administrator intervention or a timeout period. Registration failures shall be logged; log files may be accessed using the Management Entity. In case of a successful login the ITS Application is registered in the TLC Access Control registration by its unique Application-ID. The TLC Access Control returns information to the ITS Application, which tells the ITS Application what it can expect from the TLC Facility layer, in terms of permissions for reading and updating TLC Information. In case an ITS Application decides to logoff from the TLC Facility layer, it will be unregistered from the TLC Facility layer. The TLC Facility layer continuously checks if an ITS Application is still alive.
Permissions	The TLC Facility layer grants permissions to ITS Applications based on the used username/password combination. Permissions for access to TLC Information are configured per type of Application. The following Application-types are defined: ITS Control application An ITS control application has permissions to control signal groups. It has also permissions to update output states. On top of the registration of ITS Applications in general, an ITS control application has to inform the TLC about the dimensions of control (intersection identification, signal groups, detector, input and output configurations). Only if these dimensions match the dimensions of the intersection as known by the TLC, the ITS control application is allowed to control signal groups. ITS Provider application An ITS provider application has no permissions to control signal groups, but it has permissions to update (non-exclusive) output states. It can be used for different kind of TLC related functionality. ITS Consumer application An ITS consumer application has no permissions to control signal groups, or set signal group or update output states. An ITS consumer application is only allowed to read data from the TLC Facility layer.
Priority	For ITS Applications a priority is configured in the TLC Facility layer. The priority is related to the Application-ID. Requests of an ITS Application with a higher priority are processed first.
Interfaces	By using the IVERA-TLC interface, it is possible to inquire the status of the configured ITS-Applications. In addition, the IVERA-TLC interface permits to read and update the permissions and priority for each ITS-Application.

8.2 TLC Management

The responsibility of the TLC Management as used in the TLC Facilities is described in the following table:

Element Name	TLC Management
Responsibility	The TLC Management provides the Traffic Management Centre with access to the TLC Objects.
Functionality	The TLC Management supports the information exchange over the IVERA-TLC interface. All TLC related IVERA objects as described in the IVERA Object Definition are supported. To support management of ITS Applications that can be connected to the TLC extra IVERA objects need to be defined: ITS Application permissions Supported ITS-Application-ID s ITS Application priorities ITS Application state ITS Application Type permissions For each ITS Application Type (Control, Provider and Consumer) it must be possible to read and update the permissions per data type. Supported ITS-Application-ID s For all ITS Applications, that are allowed to connect to the TLC-FI, it must be possible to read and update their (unique) ITS-Application-ID s. ITS Application priorities For each ITS Application(-ID) a priority (in service, time) can be read or updated. A control application is a special case in this; if a control application is in control its actual priority is temporarily increased (the initial assigned priority stays unchanged). ITS Application state For each ITS Application it must be possible to read the session state. Possible states are described in detail the chapter 15.
Permissions	Depending on the IVERA login level the objects mentioned can be read or written.
Interfaces	The TLC Management Centre is connected to the TLC over the IVERA-TLC interface.

8.3 TLC Functions

The responsibilities of the TLC Functions, as used in the TLC Facilities, are described in the following table. The typical TLC Functions for controlling the signal groups, reading and writing inputs and outputs, as well as the safety CPU (complying to the international standards) are assumed to be present in the TLC and well known, and not elaborated in the table below.

Element Name

TLC Functions

Responsibilities

The TLC Functions provides the TLC with defined and secure functionality needed for handling the TLC-FI data exchange.

The following TLC Functions are distinguished:

Providing the detector states and speed information

Providing public transport vehicle information

Providing emergency vehicle information

Controlling and providing the signal group states

Switching and providing the intersection state(s)

Switching the intersection program(s) (control application)

Providing the input states

Controlling and providing the output states

Meta data

Time synchronization

Detector states and speed information

In the TLC Facilities, update of the detector states is made available.

The TLC Facilities performs the mapping from physical devices to detectors, check the detector behaviour and state, and is able to switch detectors on or off or traffic dependent (SWICO).

For other intelligent detectors the TLC Facilities performs the mapping, the right presentation of the vehicle information like speed, length etc.

Public transport vehicle information

The TLC Facilities receives the PTV-messages from KAR, VECOM or equivalent systems and makes the corresponding vehicle information available on the TLC-FI.

Emergency vehicle information

The TLC Facilities receives the EMV-messages from KAR, VECOM or equivalent systems and makes the corresponding vehicle information available on the TLC-FI.

Controlling and providing the signal group states

The TLC Facilities first determines which ITS control application is allowed to control the signal groups of which intersection, based on the selection, quality-attributes (like number of occurred errors) and priority made by manual panel, clock, central system or TLC itself.

If the requested program is available the TLC will start the program, and from that moment on the TLC will use the signal group state requests of the selected control application (for the corresponding intersection).

The TLC Facilities will try to realize the requested group states, and will report back the realized signal group states.

Switching and providing the intersection state

ITS control applications are allowed to request from the TLC to go to another intersection state (e.g. DARK or AMBER BLINKING), as long as they are in control . Depending on priority of different sources that can request for another intersection state, the TLC will honour the request.

Multiple ITS Applications are able to read the current intersection state of the TLC at the same time.

Switching and providing the intersection program (control application)

As soon as the ITS Control Application is selected, the TLC informs the control applications to start or stop.

The TLC is always responsible for safe switching on and off procedures, as well as safe switchingover procedure.

In case of errors with a selected and active ITS control application, the TLC must be able to switch over to a backup application or AMBER BLINKING.

Providing the intersection program

Multiple ITS Applications are able to read the current selected program number in the TLC.

Providing the input states

Multiple ITS Applications are able to read the input states from the TLC.

Controlling and providing output states

ITS Applications are able to read output states from the TLC. Only ITS control or provider applications can update the non-exclusive outputs and ITS control applications can update exclusive outputs.

There may be several ITS Applications updating the same output at the same time. The TLC Functions will make sure that the last update is used.

M eta data

ITS Applications can request meta data from the TLC. The meta data describes for instance the signal groups, detectors, inputs and outputs. The TLC provides this information based on the TLC- configuration at the TLC-IF.

Finally, the version of the TLC-IF is available.

Time synchronization

The TLC must be UTC-Time synchronized.

8.4 TLC Information

The responsibilities of the TLC-Information as used in the TLC-facilities are described in the following table:

Element Name

TLC Information

Responsibilities

The TLC Information describes what information, related to the TLC, can be exchanged between the TLC Facilities layer and an ITS Application.

TLC Information elements are dedicated to an intersection (iTLC supports multiple intersections).

Detection state

Authorized ITS Applications can retrieve the real detector information from the TLC. The TLC-FI provides for each detector e.g. the following attributes:

Occupied / not occupied

Occupation time

Upper behaviour / under behaviour

Hardware error

Flutter behaviour

Software switch (SWICO)

The detector meta data can also be read from the TLC Facilities.

Intelligent detection

Authorized ITS Applications can retrieve vehicle information from more intelligent detectors of a TLC. The TLC-FI provides for each intelligent detector e.g. the following attributes:

Vehicle classification

Speed

Length

Direction

The detector meta data can also be read from the TLC Facilities.

Public transport message

Authorized ITS Applications can retrieve public transport messages (like KAR or VECOM) from the TLC. The TLC-FI provides the information received from devices like KAR or VECOM.

Emergency vehicle message

Authorized ITS Applications can retrieve emergency vehicle messages (like KAR and VECOM) from the TLC. The TLC-FI provides the information received from devices like KAR or VECOM.

Signal group state and control

Authorized ITS Applications can retrieve the real signal group state from the TLC intersection. The TLC-FI provides the following attributes:

Functional state

Time in the current state

The signal group meta data can also be read from the TLC Facilities.

Authorized and selected ITS Control Applications can update the signal group states of the corresponding intersection.

The TLC itself determines which control application is allowed to set signal group state (per intersection). The TLC will always take care of the minimum times, clearing times and conflicts, in order to avoid unsafe situations caused by TLC signals at the intersection.

A TLC shall allow an ITS control application to control the signal groups using either external state or functional state . The internal state is used for information only.

Multifunctional digital inputs

All ITS Applications can retrieve the state of digital inputs of the TLC (like parallel signals, bridge signals, etc.). Digital inputs can only be set by the TLC itself. The TLC-FI provides for each input the following attributes:

Value

Time since last change

Software switch (SWICO)

The input meta data can also be read from the TLC Facilities.

Multifunctional digital outputs

ITS Applications can retrieve the actual state of digital outputs of the TLC (like parallel signals, pushbutton wait signals, acoustic signals, etc.). ITS Control and provider applications can set the digital outputs. Multiple applications may have permissions to set digital outputs at the same time.

The TLC will map the outputs to e.g. the physical digital outputs or to signals on the manual panel for visualization etc. The TLC-FI provides for each output the following attributes:

Value

Time since last change

ITS Application that last changed the value

The output meta data can also be read from the TLC Facilities.

Intersection state

Authorized ITS Applications can retrieve the real intersection state (e.g. CONTROL, ALLRED, AMBER BLINKING or DARK) from the TLC.

The active ITS control application can request to set the intersection state. The TLC will execute the request depending on the priority of different possible sources that can request the intersection state (like clock, manual panel, central system etc.). The TLC is responsible for executing these state transitions according to the applicable standards, and configured minimum timings.

Intersection program

Authorized ITS Applications can retrieve the actual program(s) (like CCOL1, CCOL2 etc.) that is active in the TLC. The TLC will select the actual program depending on the priority of different possible sources that can request a program (like clock, manual panel, central system etc.).

The selected program must be present and able to control the intersection.

Intersection error state

Authorized ITS Applications can retrieve the intersection error state. The TLC updates the intersection error state automatically. It is not possible to reset errors over the TLC Facility Interface.

Multifunctional Variables

Authorized ITS Applications can read and update multifunctional variables. The TLC hosts these variables. These variables can be used for iTLC internal interaction between the different ITS Applications mutually and the TLC, they are project specific.

The ITS Application ID that last changed the multifunctional variable is made available as meta information.

Special function variables

The TLC-FI provides default the following variables (as signal group- or intersection-properties):

Heavy vehicle (HGV) detected

Prioritization request for specified vehicle (E.g. cooperative implementation of current KAR-systems)

Platoon of vehicles detected

Magic GREEN (special green priority for HGV, in Dutch known as Tovergroen) active in this intersection

Reason for waiting

GREEN WAVE active in the intersection

The TLC-FI provides also project specific variables that can be freely defined.

Meta data

ITS Applications can read meta data from the TLC Facilities. The TLC hosts this information.

9 Functional view - RIS Facilities

Below, the functional view of the RIS Facilities is described.
Where possible, the descriptions are limited to functionality not already mentioned in ITS-standards; applicable ITS-standards are listed instead.

In addition, it does not describe the Facilities layer in detail, but describes the (requirements of the) parts of the Facility layer needed to provide the required services through the FA-SAP of the Facilities layer.
Detailed design and implementation of different parts is vendor specific.

Referenced standards can be either normative or informative (see reference tables).

9.1 RIS Facilities within ITS-S reference architecture

The RIS Facilities as depicted in Figure 3 is in fact part of the ETSI ITS-S reference architecture (see [REF006]), whereas FA-SAP is implemented by RIS-FI:

[ link ]

Figure 8 Position of RIS Facilities and FA-SAP in ETSI ITS-S reference architecture

The Facilities-layer interfaces with other building blocks of this reference architecture.
In order to be able to describe the relations between the Facilities and these other blocks, the following summarized description is given (partly from [REF006]):

The layer "Applications" represents the ITS-S applications making use of the ITS-S services to connect to one or more other ITS-S applications. An association of two or more complementary ITS-S applications constitutes an ITS application which provides an ITS service to a user of ITS. Within the scope of this document, the applications within this layer are defined as ITS Application .

The left hand side of Figure 8 represents the entity "Management" which is in charge of managing communications- and security-parameters in the ITS station. This entity grants access to the Management Information Base (MIB), see [REF009]. It provides a way for secure maintenance allowing application management (installation, de-installation, updates), station management (configuration) and management of security (certificate updates, permissions, etc.). The Management -entity provides the IVERA-RIS interface as depicted in Figure 3.

The right hand side of Figure 8 represents the entity "Security" which provides security services to the communication protocol stack (Access, Networking & Transport (N&T) and Facilities), to the Applications and to the management entity. "Security" can also be considered as a specific part of the management entity.

It provides authentication- and authorization-services as well as security-profile management; it can also contain management of crypto-keys and certificates.

The RIS Facilities presented in the figures below provide the required functionality also based on interactions with the security entity via the SF-interface and the management entity via the MF-interface.

9.2 RIS Facilities in iTLC

Figure 9 shows the interfaces and functional blocks of the RIS Facilities layer as used in an iTLC. Each functional block will be elaborated in detail later. Where applicable, the interfaces are renamed according to the iTLC-definitions.

[ link ]

Figure 9 RIS Facilities layer - functional blocks

The responsibilities and interfaces of the RIS Facilities as used in an iTLC are described in the following table:

Element name	RIS Facilities
Responsibilities	Provides cooperative functions to ITS Applications through the RIS-FI. The RIS Facilities must support multiple sessions as multiple ITS Applications can use the RIS Facilities at the same time. C-ITS message services C-ITS message transmission Applications can provide the RIS Facilities with new message-data, or can update or terminate previous message-data. Message-data is stored in the Local Dynamic Map (LDM). The C-ITS message services of the RIS Facilities generate different kinds of C-ITS messages according to the message-data supplied by ITS Applications. This service also implements the protocol operation of various C-ITS messages according to standards (for example described in [REF002] for DENM s). C-ITS message reception Received C-ITS messages are stored and processed by the C-ITS message services. Each received message can add or update information of objects (e.g. ITS Station ) stored in the LDM. ITS Applications can use the RIS-FI to query the LDM Object Dictionary to retrieve the status of these objects. SPAT / MAP service The RIS Facilities of an iTLC always includes a SPAT/MAP service. This service not only implements the standard protocol operation as described above, but also autonomously generates SPAT- and MAP-messages based on information provided by ITS Applications, and broadcasts these at the intersection. Therefore, it is described as a separate functional block. Information Support (LDM) Georeferenced data model The RIS Facilities also maintains a geo-referenced data model, the Local Dynamic Map. The LDM contains a real-time mapping of relevant static, temporary and dynamic infrastructure and non-infrastructure elements and objects around the ITS Station. Functions of the LDM include amongst others the mapping of positions of ITS Stations onto topology-elements of the intersection. For example, a CAM of a vehicle received through the NF-SAP is stored in this model; the position of the vehicle is then mapped onto the applicable driving-lane. LDM Object Dictionary The RIS Facilities provides a LDM Object Dictionary, which ITS Applications can use to retrieve information about objects stored in the LDM. Retrieval of information is possible by means of query, subscribe/notify, timed-interval, event based, filtered, prioritized, etc. according to [REF040] , [REF003] and [REF004]. By providing access to this model, it can decouple C-ITS messages from ITS Applications by allowing them to obtain the information (as Data Consumers) stored in the LDM. ITS Applications can act as Data Providers themselves by using the RIS-FI to store objects not directly related to C-ITS messages in the LDM. By doing this, ITS Applications are also decoupled mutually. Security / access control The RIS Facilities performs above described services according to security-constraints (e.g. permissions). It first provides a way in which ITS Applications can register themselves with the RIS Facilities after which certain access-rights/permissions are granted to this ITS Application. The security constraints are resolved by using the C-ITS SF-SAP. Station Services For management purposes, it provides quality-, operational and statistical information about the state of the RIS Facilities by using the C-ITS MF-SAP. In addition, the management-interface can be used to change the security-configuration. Optional, the MF-SAP provides means for debugging the RIS Facilities (e.g. monitor/log received and transmitted ITS-G5 messages. iTLC configuration The product name and version as listed on the iTLC certificates of the active iTLC components (TLC, RIS, ITS control application) shall be forwarded to UDAP The RIS is UTC-time synchronised.
Interfaces Provides	RIS-FI: used by ITS Applications to access provided facilities IVERA -RIS: used for operational and functional management of the RIS
Interfaces Requires	C-ITS NF-SAP C-ITS MF-SAP C-ITS SF-SAP UDAP-FI: used for exchanging messages with UDAP.

9.3 Description of functional blocks of RIS Facilities

Below, each functional block as depicted in Figure 9, is described in detail.

9.3.1 Security / Access Control

This functional block enables authorization and authentication of ITS Applications before they can access the services provided by the RIS Facilities. It uses SF-SAP to implement certain features (or possibly, some features may be implemented within the Security entity itself).
Requirements as defined in standards:

From ETSI TR 102 863, V1.1.1: In order to avoid potential abuse of LDM data by 3rd-party ITS applications, it will be necessary to implement information access control functions. An application will need to identify itself and be authenticated before it can be authorized to access specific LDM information.

From ETSI EN 302 665, V1.1.1: Every ITS application class/ITS application shall be uniquely identified by an application identifier in order to be handled in ITS . See also ETSI TS 102860.

In accordance with applicable standards, an ITS Application shall register itself with the RIS Facilities before the RIS Facilities processes any further requests of this Application.
In order to do so, Security and Access Control implements:

Authentication
Authorization, based on roles (with permission-set)

9.3.1.1Authentication

Authentication is used to make sure that for a connecting ITS Application:

the ITS Application can trust the RIS Facilities
the RIS Facilities can trust the ITS Application

An ITS Application needs to be authenticated by the RIS Facilities to be able to use the provided services. This is done by starting an in-band login-procedure (handled by Facilities) where the ITS Application identifies itself by using a username and password.

The ITS Application is notified of the success (or failure) of authentication. After 5 subsequent registration-failures, the account shall be disabled (no further registration is possible without intervention). Registration failures shall be logged; log files may be accessed using the Management Entity.

The ITS Application may deregister itself from further using the RIS-FI.

The login-procedure can take place while one of the following levels of security applies to the Facility:

A simple security enhancement is the use of a VPN tunnel. This protects against attacks in the global network but at the VPN end points the login procedure is still visible.
Add TLS with single side authentication; the RIS Facility needs a certificate to identify itself. After successful handshake the in-band login procedure is encrypted. However, the application-id and password as used by the ITS Application might be visible to others and can be copied.

The plain and TLS versions of the RIS Facilities can use different well-known port numbers. A RIS with enhanced security can disable access on the plain port.

Whereas the Facilities supports all 4 levels of security, the applicable security level is determined per project.

9.3.1.2Authorization

The RIS Facilities uses the Security entity to check if the ITS Application is authorized to further use the RIS-FI.

An ITS Application identifier (username as used during login) is used to authorize the ITS Application by matching the identifier with table of known ITS Applications or Application classes, as stored in the Security entity. Each known identifier is assigned one or more groups.

Each group refers to permission-attributes at API-level (e.g. adding of IVI message-data may be restricted, or: which LDM-information may be accessed (read) or changed, etc.), which then are applicable to any future requests of the connecting ITS Application.

The ITS Application is notified of the applicable permissions.

While the ITS Application is authorized, it may use the services provided by RIS-FI, according to allowed permissions. For each API-request, the applicable permissions (per ITS Application) shall be evaluated before the request is processed any further by the RIS Facilities.

Permissions may change over time:

Some roles/permissions may be assigned to one ITS Application at a time, although multiple ITS Applications are (potentially) permitted to act as this role based on their credentials. In these cases, the RIS Facilities is responsible to determine which ITS Application is allowed (exclusively) to this role, and must revoke/re-assign actual permissions/roles amongst available ITS Applications.
Permissions/roles can be (partially) revoked for a specific ITS Application by the Security-layer; usage of RIS-Facilities by this ITS Application is permitted according to the new applicable permissions/roles.

To inform an already registered ITS Application of a change of permissions, a Permission Changed -event will be added to the RIS-FI.

9.3.1.3Groups and Permissions

Groups of permissions are defined to determine which permissions apply to an ITS Application.
Each ITS Application is assigned one or more groups.

Management of assigned roles, available roles and permissions is done using the Management-entity.

9.3.2 C-ITS message services

This functional block contains the infrastructure services responsible for transmission and reception of C-ITS messages.

In addition, the C-ITS message services notify the LDM of received C-ITS messages.
The C-ITS message service as defined in this architecture, will consist of at least the following services for transmission and reception of C-ITS messages:

Message type	Purpose	Standards
SPAT	Disseminate information about signal group state and timing	[REF001]
MAP	Dissemination of road topology	[REF001]
IVI	Provides information of physical road signs, virtual signs or road works.	[REF023]
DENM⁷⁾ DENM is optional within the iTLC architecture	Decentralized environmental notifications	[REF002]
CAM	Cooperative awareness messages	[REF008], especially requirements regarding RISs

Table 2 Supported C-ITS messages

Reception of messages

According to various standards (e.g. [REF002]) the data of the received messages as listed in Table 2 shall be stored in the LDM.

For signed messages, the services shall check the message content against the Application identifier ITS-AID⁸⁾ This is not the same identifier as the Application-ID used for the ITS Application authentication function of section 9.3.1 ([REF005]) and Service Specific Parameters (SSP s) as contained in used certificate. If the message content is not consistent with the SSP or the signature could not be validated, the message shall be marked as not trusted or dropped before delivered to the LDM.

For not signed messages the message shall be marked as not signed before delivered to the LDM.

Transmission of messages

Authorized ITS Applications can add LDM Objects with parameters to the RIS Facilities which could lead to C-ITS message transmission. Amongst others, parameters can include dissemination area, repetition and traffic class.

If such a request is in accordance with the permissions of requesting ITS Application, the RIS Facilities handles the request by the executing following actions (in arbitrary order):

adding/updating the LDM Object to the LDM
generating a message payload and starts transmission of the message according to specific protocol handling.
sending a response (with LDM object identifier) to the requesting ITS Application

The RIS Facilities and underlying layers send C-ITS messages according to available security certificates. If such certificates are not available and signing is requested, the response for the ITS Application will contain an error.

An ITS Application may also update or delete a previously added LDM object by using the LDM object identifier as received during the creation-request of the object. Updating a LDM object may change the C-ITS message content, whereas deleting a LDM object terminates the transmission of a C-ITS message.

Processing an ITS Application request (add, update or delete) includes validation of given parameter-values.

9.3.3 SPAT/MAP service

The RIS Facilities in an iTLC always contains a SPAT/MAP-service.
In addition to applicable standards (see Table 2), this service is responsible for:

Autonomous periodically broadcasting MAP-messages according to intersection-topology (available in LDM)
Autonomous broadcasting of SPAT-messages according to (signal group-) information, supplied by ITS Applications. A new SPAT-message is created periodically each second, or when updated SPAT-information is available.

A SPAT-message as broadcasted by the RIS Facilities minimally contains the mandatory information. This at least includes:

general status of the iTLC (IntersectionStatusObject)
actual state of each signal group (MovementPhaseState)

Signal group states and timing are added to the LDM as (part of) a LDM Object, with a lifetime indication. When states or timing is changed, this LDM Object needs to be updated by an ITS Application (typically the TLC Adapter Application). If no actual data is available, the SPAT-service shall broadcast a SPAT-message containing the status “noValidSPATisAvailableAtThisTime”.

A MAP-message contains, besides the mandatory fields, at least also:

connectsTo -element of a GenericLane-instance (in laneSet) for ingress lanes.

See also sections 0 and 0 for common scenarios.

Additional information may be added to the SPAT-payload; this depends on the completeness and quality of information supplied by ITS Applications and the way this information is processed by the LDM.
Examples are:

TimeChangeDetails (could be added to inform Vehicle ITS stations (VIS s) of signal group timing).
Prioritization States (to inform vehicles about status of prioritization requests)

9.3.4 Station Services

Station Services offer a number of services regarding the RIS itself.

9.3.4.1Configuration

By using the Management Entity, the Station-configuration can be changed.
The Configuration facility contains the configuration-items of (amongst others) the RIS Facilities. The configuration-items can be changed by using the Management Entity (which is vendor specific) of the RIS.

The following configuration-items should at least be available:

station type, e.g. vehicle profile or roadside unit profile
station capabilities, e.g. the supported ITSC communication channels and other static or variable information related to the station itself
permissions and roles
known ITS Applications and Application classes with assigned roles
security certificates

Although the way in which the Management Entity is used and accessed is vendor specific, it shall be subject to security constraints to prevent unauthorized access.

9.3.4.2Information services

This service provides static and dynamic information of the ITS station as may be required by ITS Applications and other facilities. This could include statistical information needed for evaluation, reporting (SLA) and active performance-monitoring purposes of the RIS.

The way in which statistics are collected, is vendor specific.

9.3.4.3Time synchronization

The TLC Facilities, RIS Facilities and ITS Applications shall be time-synchronized to UTC-time within 100 ms accuracy. ITS Applications can request the synchronized system time from the RIS although it is advised to use standardized methods like NTP (RFC 5905).

All timestamps used at RIS-FI and TLC-FI are in UTC; if needed, the Facilities may convert the timestamp into TimestampITS, as defined in [REF007].

9.3.4.4Logging

The RIS maintains several log files containing errors and significant events about the operation of the RIS.
At least, the following is logged:

registration attempts and result
role switches
SPAT-performance (SPAT data availability)
information about transmitted and received ITS-G5 messages (may contain message content as well)

These log files can be accessed via IVERA-RIS by using the Management Entity.

9.3.5 Information support (LDM)

A functional component of the RIS Facilities is the LDM. This is a dynamic data store, which contains a geographical view of the world around the RIS. It contains information that ranges from static data such as road topology elements to dynamic objects such as vehicles. The LDM is responsible for making a consistent world-view available to the ITS Applications. It decouples ITS messages from the information they consists of and makes this information available as RIS-FI objects for use by ITS Applications based on geometry.

In the scope of this document, the services provided by the LDM are described from a roadside point-of-view. E.g. the geographical maintenance area of the LDM is fixed (stationary map).

The position of the LDM within the RIS Facilities layer, as well as the services and interfaces of the LDM are described in ETSI EN 302 895, V1.1.1. See also ETSI TR 102 863, V1.1.1 and CEN/ISO TS18750:2015.
Information is stored at various conceptual layers of the LDM (see figure below) as described in e.g. ETSI TR 102 863, V1.1.1, par. 4.1.

[ link ]

Figure 10 Local dynamic map, model-view from SafeSpot/CVIS

The model consist of 4 layers, with increasing dynamics:

Layers 1 & 2 represents the road-topology and geometry. In a RIS, layer 1 is not necessarily available as a tiled image (however, could be optionally available for example to create a graphical image with content on a user-interface).
Layers 3 & 4 together represent the objects (events, ITS Stations, ) which are using (and mapped onto) the road-topology. Layer 3 could contain event like weather situation or traffic information, whereas layer 4 could contain vehicle information.

These layers are geographically related to each other.
This model is frequently updated by the LDM as well as in time as in space (space is not relevant for RIS Facilities of iTLC).

The LDM removes outdated information (e.g. based on lifetime of a LDM Object) from the model.
In addition to the contents of referred standards, the following responsibilities are part of the LDM:

Maintaining relationships between dynamical objects (like vehicles) and topology-elements (e.g. driving lanes) by map matching the objects onto the topology.
Maintaining relationships between static objects (like signal groups, stop bars or inductive loop detection) and more dynamical objects (like vehicles) by using concepts like reference track .

Optionally, vendor specific services like aggregation of data could be available.

The data of the layers as described above are stored in the LDM as LDM Objects.

Authorized ITS Application can act (dependent on applicable roles, see section 0, 9.3.1.3Groups and Permissions ) as Data Provider as well as Data Consumer (see below).

9.3.5.1Data Providers

Data Providers can request the storage of information in the LDM. The LDM must validate the provided information (e.g. relevance checking) before storing or updating a LDM Object.

The LDM is responsible for maintaining a consistent data set (for example in the case when different ITS Applications added events for overlapping geographical areas with different content).

9.3.5.2Data Consumers

Data Consumers can use the LDM Object Dictionary to retrieve information about LDM Objects from the LDM by using subscribe/notify-pattern and spatial queries, giving access to:

Map data & road topology
State and relationships of dynamic objects (like Car )

See also the RIS-FI requirements in chapter 16.

9.4Description of Interfaces

Below, the interfaces needed by and provided by the RIS Facilities are described.

9.4.1 RIS Facilities Interface (RIS-FI)

The RIS-FI interface implements the FA-SAP interface of the C-ITS reference stack as depicted in Figure 11 below:

[ link ]

Figure 11 C-ITS Facilities layer

The RIS-FI can be used by multiple ITS Applications at the same time and can be used to add, update or delete LDM Objects.
The interface is IP-based.

Below, a high-level description of RIS-FI is given. The RIS-FI requirements are elaborated in chapter 16.

9.4.1.1RIS-FI high level description

The RIS-FI provides for the following:

Authentication and authorization of ITS Applications
Register and deregister of ITS Applications with RIS-FI
Means to add, update and delete LDM Objects (by using LDM Objects, transmission of ITS G5 messages can be triggered, updated or deleted).
Execution of spatial queries of LDM Objects
Subscribe to data-changes of specified objects from the LDM Object Dictionary
Allow for subscriptions on other data (like security permissions)
Means to publish information (periodically, or event based) to subscribed ITS Applications
Query RIS ITS Station information (e.g. synchronized time)

To allow for efficient information distribution of above listed information amongst ITS Applications, the RIS-FI supports the two data-distribution patterns:

Subscribe/notify
Request/reply

If required by the ITS Application, replies/notifications supplied by RIS-FI can be:

filtered on 2 levels (as specified in CEN/ISO TS18750:2015):
first level filtering
second level filtering (optionally for RIS Facilities)
Ordered output as described in ETSI EN 302 895, V1.1.1, Ordering Data Request Results
Periodically (in case of notifications)

Only subscriptions and requests of authorized ITS Application are processed; otherwise, these are dropped (ITS Application is notified with not-authorized -reply).
The RIS-FI supports at least 10 concurrent ITS Applications.

9.4.1.2QoS

ITS Application can request certain level of QoS by specifying a priority-level and application role.
See chapter 16 for elaboration of levels and roles.

9.4.1.3Alive checking

The RIS Facilities shall be able to determine whether an ITS Application is still connected and responding.
Non-responding of disconnected ITS Applications shall be detected and deregistered.

Checking is based on a bi-directional heartbeat-message (keep-alive); see for elaboration chapter 16.

9.4.2 Interface “MF-SAP“

The interface with the Management entity is described in:

ETSI TS 102 723-5: "Intelligent Transport Systems; OSI cross-layer topics; Part 5: Interface between management entity and facilities layer".

9.4.3 Interface “SF-SAP“

The interface with the Security entity is described in:

ETSI TS 102 723-9: "Intelligent Transport Systems; OSI cross-layer topics; Part 9: Interface between security entity and facilities layer". (not released at the time of writing this architecture)

9.4.4 Interface “NF-SAP“

This is a vendor specific interface and is outside the scope of this document.

10 Functional view - Scenarios

10.1 Decouple ITS Application logic by using the LDM

ITS Applications can exchange/share information by using the LDM of the RIS Facilities.

One example is an ITS Application (TLC Adapter Application) dedicated to updating the LDM with current signal group states. Another ITS Application (Warning Application) may subscribe itself with the LDM to signal group state-events and vehicle-events. In case of a possible red-light negation, it may transmit a warning (DENM) by using the RIS Facilities.

In this way, there is no need for the Warning Application to subscribe with the TLC Facilities to the signal group state, although it is possible when needed.

10.2 Example of a Public transport application

The TLC receives KAR/detection messages from public transport vehicles (PTVs). The ITS Application (PTA) has subscribed to this information and receives this when it is received by the TLC and made available on the TLC-FI.

The RIS Facilities receives CAM messages from PTVs, the ITS Application has subscribed to this information and receives this when it is made available on the RIS-FI.

If the PTA wants to grant priority, it send this request to the TLC-FI. The ITS Control Application receives this information as it is subscribed to this information. The ITS Control Application handles the request and sends the result (status of the request and actuated state timing) to the TLC-FI.

An ITS Application (TLC Adapter Application) should be subscribed to this information and performs the needed actions. This can be the ITS Application that is responsible for updating all the SPAT message-data, but it can also be an application that only writes this particular information to the RIS-FI.

11 Deployment view

This view describes the deployment of the functional elements of section 6 to run-time processing platforms and places these platforms in physical locations. The deployment views following in this chapter are intended as examples of deployment.

The following run-time processing platforms are identified:

TLC ; Traffic light controller, from the point of view of this document this is the platform on which the TLC function resides including signal group actuation and detection
TLC extension processor; Platform, which extends the TLC functionality in case the TLC cannot perform all the iTLC functions required
RIS ; from the point of view of this document this is the platform on which the RIS function resides
RIS modem ; Interfaces with the lower layers of the ITS-S stack
ITS Application processor ; platform containing ITS applications
Integrated iTLC processing platform ; platform containing both the TLC and RIS functionalities

The following physical locations are used in this section:

Cabinet - physical compartment where the TLC is mounted
Road-side - location somewhere next to the road
Central processing location - central location not necessarily close to the road-side physical elements where functionality is deployed
Central data and management location - location where services such as Traffic Management is executed and Traffic Data is deployed

The following functional elements must be deployed:

ITS Application(s)
TLC Facilities
RIS Facilities

The following functional elements are not defined in section 6, but they have an important supporting role for the deployment variants and will also be identified in the deployment views:

TLC middleware
Network & Transport ; ITS-S stack layer
Access; ITS-S stack layer

To which platforms and on which location these elements are deployed depends on amongst others the following factors. This list is by no means complete and a deployment scenario should be chosen based on the requirements for each individual location.

Expected processing power needed by an element
Expected network load and network latency requirements
Ability of existing systems to be upgraded to iTLC capabilities. Some (older) systems may have restrictions that require addition of processor platforms. E.g. systems with insufficient processing power, security support or other facilities not conforming to the iTLC Architecture
Required availability of a service

Depending on the function the ITS Application performs, its requirements on the processing platform and environment, it can be deployed on different locations and on different processing platforms.

11.1 Run-time platform models

In the following views, run-time processing platforms are shown in their physical location and functional elements are assigned to these platforms. The connections between the platforms are defined and variants of deployment is shown. To each connection, the relevant protocols that will use these connections depicted, for the RIS-FI interface the <<RIS-FI>> protocol, etc.

1.1.1 Base platform deployment

This view forms the base of all the coming views. It contains the essence of the deployment intended by the Intelligent TLC architecture, namely:

A TLC containing TLC Facilities and ITS Applications
A RIS containing RIS Facilities and ITS Applications
An ITS Application processor containing ITS Applications

ITS Applications residing on any of these platforms can access the RIS and TLC Facilities.

[ link ]

Figure 12 Deployment 1: Base platform deployment (TLC+RIS+ITS Application host)

11.1.2 Basic platform deployment

This view is a likely variant of 11.1.1 where a complete iTLC is deployed by adding a RIS to a TLC.

[ link ]

Figure 13 Platform 1: Basic platform deployment (TLC + RIS)

11.1.3 TLC and RIS deployment variants

This view is a variant of the base deployment view of Figure 12. The view shows that it is possible to deploy a TLC and/or RIS with the functional elements organized on different processing platforms.

Reasons for such a deployment may be:

Existing deployed TLC cannot host ITS applications and TLC Facilities due to resource requirements
RIS may need to have a technical separation to place the modem in a suitable location

[ link ]

Figure 14 Deployment 2: Combined TLC and RIS deployment variants

11.1.4 Integrated iTLC processing platform

The previous views showed deployment with a clear separation between the TLC and RIS functionalities. Figure 15 shows a variant with an integrated TLC and RIS processing platform. This platform may internally consist of separate execution environments (e.g. for security reasons) and still a separate ITS Application processor may be deployed interacting with the integrated iTLC processing platform.

[ link ]

Figure 15 Deployment 3: Integrated iTLC processing platform

11.1.5 Central location deployment variant

Figure 16 shows a deployment variant where parts of the functionality is deployed in processing nodes in the central location.

[ link ]

Figure 16 Deployment 4: Central deployment variant

11.1.6 Direct-UDAP-connection deployment variant

In all of the above deployments the ITS Application makes use of the RIS-FI interface and RIS. For an ITS control application it is also possible to connect directly to UDAP without using the RIS-FI/RIS. Figure 17shows a deployment variant where the ITS control application resides in a Central processing location, but this could also be in the Cabinet.

Note: this deployment-variant supports multiple ITS Applications but only one of these ITS applications is allowed to connect to UDAP. This also means that no RIS can be used at the same time to connect to UDAP. If multiple ITS applications must be able to provide data to UDAP, a RIS is required to preserve the single point of contact principle.

[ link ]

Figure 17 Deployment 5: Direct-UDAP-connection deployment

11.2 Network infrastructure

In the following views, the deployment of the functional elements on run-time platforms in their physical location defined in section 11.1 is shown in a network context. Connections identified are replaced by network connections and elements. For clarity, external elements are added to the views. Figure 18 shows a network infrastructure in case of mainly locally deployed components. Figure 19 shows a network infrastructure in case of more distributed deployed components.

[ link ]

Figure 18 Network infrastructure road-side

[ link ]

Figure 19 Network infrastructure central processing variant

11.3 Hosting ITS Applications

Within the deployment models described in this chapter, it is indicated that ITS Applications may be deployed on different hardware platforms:

ITS Applications processor
TLC
RIS

It is possible that the vendor of an ITS Application is not the vendor of the platform, or the vendor of a platform offers as a service to host ITS Applications on their platform.
For this purpose, the vendor of a processing platform shall publish the facilities offered by the platform along with the requirements and limitations imposed on the ITS Applications.
At all times, it shall be clear who is responsible for the security established in this architecture based on the requirements and facilities offered.

12 Information view

The Information view of the system defines the structure of the system s stored and transient information and how related aspects such as information ownership, flow, currency, latency and retention will be addressed.

The functional view defines three main functional components, the TLC Facilities, RIS Facilities (including LDM) and ITS Applications. From the point of view of this architecture these functional components each run in their own process with inter-process communication defined by the TLC-FI and RIS-FI interfaces, see also chapter 13.

From their role these components contain different sorts of data items.

RIS Facilities contains a LDM as local data exchange and storage point.
TLC Facilities contains TLC objects about the intersection. This is typical data such as signal group states and detection.
ITS Applications are responsible for managing their local data. That means e.g. initializing and storing of parameters. Information management within ITS-Application is highly application specific and outside the scope of this view.

[ link ]

Figure 20 Example data flows

Data flows are implemented by messages on the RIS-FI and TLC-FI. The messages are initialized by an ITS Application. The VLOG interface is also depicted to describe in this architecture.

12.1 TLC

The TLC provides the following interfaces:

TLC-FI
IVERA-TLC

The TLC provides data objects related to

Traffic signals
Detection
Inputs
Outputs

A detailed description can be found in chapter 8.

12.1.1 Startup state

The TLC Data Objects are available after startup. The time to build up the actual information depends on detection- and input unit start-up times. In general these units have a shorter start-up time as the TLC-FI itself. Exceptions on this can be e.g. video detection systems. Outputs are initialized at an defined state so the related object data is also available. The objects are available at the moment TLC-FI is accessible. Because the VLOG information is created by an ITS Application, the VLOG-stream will become available after an ITS Application is connected to TLC-FI and is “in control”. IVERA-TLC will also be accessible after startup.

12.1.2 Data storage

The TLC objects are stored in volatile memory and initialized at startup.
Settings, configuration, logs and topology are stored in persistent memory.

12.1.3 Data throughput

Two aspects are relevant: latency and message load. Message load consist of message count and data volume. A high message load will normally have a negative impact on the latency. The latency requirements are mentioned in section 14.1.1. How is handled with load conditions is mentioned in section 14.1.3.

VLOG Data

A traffic control application that is in control can create VLOG data. Streaming VLOG data is provided directly to the Traffic Data Centre.

12.2 RIS

The RIS provides the following interfaces:

RIS-FI
IVERA-RIS

The RIS provides data objects related to

ITS Stations
Road objects

The objects are stored internally in a LDM. A detailed description can be found in section 9.3.5.

12.2.1 Startup state

The LDM may not contain highly dynamic information at startup. ITS station objects will be created after receiving this information. Typically, these objects are stored in volatile memory. If a LDM is restarted and the lifetime of these objects is not expired a LDM might contain these objects. This way a valid view is available at startup. The other solution is to wait for messages to build up a new view. The time to realize this new view depends on the update frequency of the object. For example a CAM message is send minimal every second resulting in an object into the LDM within a second.
Static objects will be available.
Special care should be taken for semi dynamic information. The RIS is not able to handle this correctly because updates during the time the LDM was not available can be missed. Semi dynamic information will be stored in persistent memory. At startup, the lifetime of the objects is evaluated and processed. This means that a data provider should resend updates that are not confirmed by the RIS-FI. (Messages that are send during the time the RIS-FI was not available.) The RIS-FI should store semi dynamic information before sending a confirmation.

12.2.2 Data storage

The storage capacity should be enough to contain minimal the expected number of objects in the area that should be covered. In normal situations calculate with 5 meters occupied space for each ITS Station and take the total length of all the corridors in the area to calculate the expected number of objects. Objects related to infrastructure are known and appropriate storage need to be available. Depending the local situation, also other (human) ITS-stations/objects may be expected, an assumption should be made with respect to the data storage. The data storage might be evaluated after some time of use.

Three types of data objects are considered: Highly dynamic information,Semi-dynamic information and Static information. Each type of object may have other data storage requirements. The implementation and so the storage is Vendor dependent.
A implementation can be:
Static information - Stored in persistent memory.
Semi-dynamic information - Stored in volatile memory and persistent memory.
Highly dynamic information - Stored in volatile memory.

12.2.3 Data throughput

The LDM is provided with information from the ITS-G5 interface and RIS-FI. This can theoretically result in more than 1000 updates per second, but the messages are aggregated in the LDM Objects resulting in less object updates. At the RIS-FI messages are processed with highly dynamic information at highest priority and static information at lowest priority.

Two aspects are relevant: latency and message load. Message load consist of message count and data volume. A high message load will normally have a negative impact on the latency. The latency requirements are mentioned in section 14.1.2 How is handled with load conditions is mentioned in section 14.1.3.

12.3 ITS Application

From the view of the architecture an ITS Application does not store data, however it can have data for own use. The ITS Application should arrange storage and handling of this data. The IVERA-APP or another interface can be used to manage data and settings.

An ITS Control Application can generate VLOG data and makes this available on its VLOG interface.

13 Concurrency view

13.1 Processes

Three separate concurrently running processes are distinguishable whereby part of the RIS facilities functionalities may be provided by the ITS application (which makes RIS-FI redundant).
Inter-process communication is defined by the TLC-FI and RIS-FI interfaces.

[ link ]

Figure 21 Functional block - process mapping

Each of these main functional blocks may consist of several internal functional blocks. These internal functional blocks may require internal separate processes or threads and consequently inter-process communication. The internal architecture is beyond the scope of this architecture description.

13.1.1 ITS Application

This process may use the TLC-Facilities and/or RIS-Facilities to implement an ITS-use case.

It runs concurrent of other ITS Applications.

In this architecture, there is no explicit interface defined between ITS Applications; information exchange is done by using the TLC-FI, the RIS-FI or UDAP-FI.

13.1.1.1ITS Application Management

The ITS Application may provide the Traffic Management Centre with access to read and write the IVERA Control Interface Objects through the IVERA-APP interface. There may be multiple TMC s connected simultaneously as IVERA-APP clients. The IVERA-APP acts as an asynchronous service, allowing request/replies as well as notifications:

Each request is handled asynchronous of other requests.
Notifications are sent asynchronously to subscribed IVERA-APP clients.

IVERA Objects are not protected against being changed by multiple sources simultaneously, nor are there any checks within the IVERA-APP protocol to guarantee consistency within or between objects. IVERA-APP clients are responsible for consistency.

13.1.2 TLC Facilities

There is one instance of this process per iTLC available; it can be used by multiple ITS-Applications.

13.1.2.1TLC Facilities Interface

An ITS Application can use services provided by TLC Facilities by using the TLC-FI.
The TLC-FI acts as an asynchronous service, allowing request/replies as well as notifications:

Each request is handled asynchronous of other requests.
Notifications are sent asynchronously to subscribed ITS Applications.

Timeouts on requests are handled by the ITS Application issuing the request.

Non-responding or disconnected clients are detected by the TLC-Facilities by using a periodic heartbeat-message.

13.1.2.2TLC Management

The TLC Management functional block provides the Traffic Management Centre with access to read and write the IVERA Objects through the -TLC interface. There may be multiple TMC s connected simultaneously as IVERA-TLC clients. The IVERA-TLC acts as an asynchronous service, allowing request/replies as well as notifications:

Each request is handled asynchronous of other requests.
Notifications are sent asynchronously to subscribed IVERA-TLC clients.

IVERA Objects are not protected against being changed by multiple sources near-simultaneously, nor are there any checks within the IVERA-TLC protocol to guarantee consistency within or between objects. IVERA-TLC clients are responsible for consistency.

13.1.3 RIS Facilities

The RIS Facilities is optional. When it is available then multiple ITS-Applications can use it.

13.1.3.1 RIS Facilities Interface

An ITS Application can use services provided by RIS Facilities by using the RIS-FI.
The RIS-FI acts as an asynchronous service, allowing request/replies as well as notifications:

Each request is handled asynchronous of other requests.
Notifications are sent asynchronously to subscribed ITS Applications.

Timeouts on requests are handled by the ITS Application issuing the request.
Non-responding or disconnected clients are detected by the TLC-Facilities by using a periodic heartbeat-message.

13.1.3.2RIS Management

The RIS Management functional block provides the Traffic Management Centre with access to read and write the Control Interface Objects through the IVERA-RIS interface. There may be multiple TMC s connected simultaneously as IVERA-RIS clients. The IVERA-RIS acts as an asynchronous service, allowing request/replies as well as notifications:

Each request is handled asynchronous of other requests.
Notifications are sent asynchronously to subscribed IVERA-RIS clients.

Control Interface Objects are not protected against being changed by multiple sources near-simultaneously, nor are there any checks within the IVERA-RIS protocol to guarantee consistency within or between objects. IVERA-RIS clients are responsible for consistency.

14 System qualities

Facilities used below without being preceded by RIS or TLC is assumed to apply to both RIS and TLC Facilities.

14.1 Performance and scalability

Latency requirements are depicted and described below.
Subsequently, other performance- and scalability-requirements are described.

14.1.1 Latency requirements TLC & TLC Facilities

[ link ]

Figure 22 Latency requirements overview TLC & TLC-FI

Latency requirements are documented in the table below, the paths defined are shown in Figure 22.

ID	Path	Requirement	How Met
		TLC
QA_PERF_001	A	Latency between request at TLC-FI and resulting response at TLC-FI must be known. Includes checking permissions & data-validity checking and processing (updating internal TLC objects).	Maximum latency: 100 ms. See chapter 15.
QA_PERF_002	B	Latency between change of hardware inputs and internal state of TLC objects.	Several performance classes are defined in chapter 15 The applicable class is vendor specific. Applicable performance class can be requested from each TLC-FI.
QA_PERF_003	C	Latency between updated internal TLC objects (like requested output-states ) and actual changed hardware outputs.	Several performance classes are defined in chapter 15 The applicable class is vendor specific. Applicable performance class can be requested from each TLC-FI.
QA_PERF_004	D	When ITS provider applications change TLC objects of the TLC Facilities, the updated TLC object shall be made available (published) to consumers within specified time.	Maximum latency: 50 ms. See chapter 15.
QA_PERF_005	E	Maximum latency of transportation of information from TLC-FI to ITS Applications.	Depends on used network-layer. Advise: 75 ms
QA_PERF_006	F	Maximum latency of transportation of information from an ITS Application to TLC-FI.	Depends on used network-layer. Advise: 75 ms


QA_PERF_009	x	Latency between status change of signal group and internal state of TLC object. NB: includes the latency in the ex-ceptional case the safety-facility kicks in	Maximum latency: 50 ms.

14.1.2 Latency requirements RIS Facilities

[ link ]

Figure 23 Latency requirements overview RIS & RIS-FI

Latency requirements are documented in the table below, the paths defined are shown in Figure 23.

ID	Path	Requirement	How Met
		RIS
QA_PERF_009	A	Latency between request at RIS-FI and resulting response at RIS-FI. This includes checking permissions, validation of request-data, processing and transmission of respond at RIS-FI	Maximum latency: 100 ms. See chapter 16
QA_PERF_010	B	Maximum latency between the reception of an ITS-G5 message and the update of a corresponding LDM Object	Maximum latency: 70 ms. Vendor specific implementation in RIS.
QA_PERF_011	C	Maximum latency between an update/addition of a LDM Object and the delivery of an ITS-G5 message at the radio-modem	Maximum latencies: SPAT: 100 ms. MAP: 100 ms. DENM: 100 ms. IVI: 100 ms. Vendor specific implementation in RIS.
QA_PERF_015	D	Maximum latency between an addition/update/delete of a LDM object and a transmitted notification to subscribed ITS Applications	Maximum latency: 50 ms. See chapter 16.
QA_PERF_016	E	Maximum latency of transportation of information from RIS-FI to ITS Applications.	Depends on used network-layer. Advise: 75 ms. Also part of SPAT-latency scenario, see section 0.
QA_PERF_017	F	Maximum latency of transportation of information from an ITS Application to RIS -FI.	Depends on used network-layer. Advise: 75 ms. Also part of SPAT-latency scenario, see section 0.

14.1.3 Other performance and scalability requirements

ID	Requirement	How Met
	System
QA_PERF_018	The architecture must guarantee the system quality of service faced with a heavy load. For instance, some ITS Application subscribes to the world and wants to know about the world every 100ms while Traffic Control Applications may suffer from this.	Implement measures: Quality of Service Application update frequency Content characteristics See [ REF006] .
QA_PERF_019	The Facilities shall be synchronized with UTC time with accuracy of 100 ms.	When a time difference > 100 ms with UTC is encountered, the facilities shall achieve the proper time within 10 seconds preferable in a gradual way without making any time jumps. In case this is not possible, the local time shall be immediately set to a new time indicating this in appropriate logging (e.g. VLOG). Use standardized time sources. For example GPS or NTP-servers. Specific case: when TLC Facilities is not time-sync ed (deviation > 100 ms), no SPAT timing estimates shall be published by TLC Facilities. Sanity-check on requests/replies: include absolute timestamp in certain messages. See also c hapter 15 and 16 .
QA_PERF_020	The RIS-FI and TLC-FI shall conserve processing power and network bandwidth as much as possible.	Only changes to relevant information is sent to subscribed applications, repeated identical data is not needed by the interfaces. Information is filtered. See also c hapter 15 and 16 .
	TLC Facilities
QA_PERF_021	TLC-FI shall be able to handle a number of concurrent ITS applications a number of active subscriptions (per ITS application and total) a number of requests/replies per second (per ITS application and total) a number of notifications per second (per ITS application and total)	The actual numbers the interface must be able to handle is documented in c hapter 16
	RIS Facilities
QA_PERF_025	RIS-FI shall be able to handle a number of concurrent ITS applications a number of active subscriptions (per ITS application and total) a number of requests/replies per second (per ITS application and total) a number of notifications per second (per ITS application and total)	The actual numbers the interface must be able to handle is documented in c hapter 15
QA_PERF_026	At least, the RIS Facilities shall be able to process at least 250 received ITS-G5 messages per second (for rationale, see 0)	Vendor specific implementation

14.2 Security

ID	Requirement	How Met
	System
QA_SEC_001	Each ITS Application must be authenticated and authorized by the Facilities before being allowed to access other functions of the RIS-FI or TLC-FI	See section 9.3.1 and 8.1
QA_SEC_002	The Facilities may revoke the authorization of an ITS Application while an ITS Application is connected	See section 9.3.1 and 8.1
QA_SEC_003	It shall be possible to enforce encryption of each connection between an ITS Application and RIS-FI or TLC-FI. When encryption is required, authentication and authorization must be done within an encrypted communication channel.	The TLC and/or RIS Facilities can apply security policies such as encryption using TLS for a connected application. An application may then only connect after encrypting its communication accordingly. No encryption may be necessary when the iTLC and all of its components are deemed to be in a trusted environment (inside cabinet, VPN). See section 9.3.1
QA_SEC_004	RIS-FI or TLC-FI requests of ITS Applications are processed according to the actual permissions of the calling ITS Application	See section 9.3.1 and 8.1
QA_SEC_005	Results of registration-requests shall be logged	Accessible by management interface See section 8.2
	TLC Facilities
QA_SEC_007	After successful registration of an ITS control application, during its lifetime (and connection with TLC-FI), the TLC Facilities denies subsequent registration requests of the same ITS control application instance.	See section 8.3
	RIS Facilities
	N/A (see Facilities above)

14.3 Safety

[ link ]

Figure 24 Latencies signal group state-change to SPAT-message (see QA_SAFE_002)

ID	Requirement	How Met
	System
QA_SAFE_001	SPAT-payload shall be consistent with actual displayed images at traffic lights.	See section 8.3
QA_SAFE_002	Maximum latency between update of hardware signal group states and dissemination of SPAT-message ( including the updated data at Access layer of the RIS )	See sections 14.1.1 and 14.1.2 , and Figure 24 Max latency: 150 ms.
	TLC Facilities
QA_SAFE_003	The TLC Facilities shall validate the functional configuration of a traffic control application before it is allowed to request signal group changes	Configuration of intersection (name) signal groups (count) and detection (count) is validated during the application setup process.
QA_SAFE_004	The TLC Facilities shall translate signal group requests from traffic control applications to actual actuation according to safety constraints	Safety (clearance times, minimum timing, etc.) is configured in the TLC Facilities. TLC Facilities considers these when performing the actuation and publishes its expected timing for switching.
QA_SAFE_005	The TLC Facilities shall only publish signal group time estimates that are safe from a traffic safety point-of-view.	See chapter 8.3
QA_SAFE_006	TLC Facilities shall allow maximum of one traffic control application per intersection to control signals groups).	See chapter 8.3
	RIS Facilities
QA_SAFE_007	SPAT-service shall transmit a SPAT-message at every update of SPAT-data, and at least once a second.	See section 9.3.3 , SPAT/MAP service
QA_SAFE_009	If no recent SPAT-data is available (see QA_SAFE_010) a SPAT-message with status noValidSPATisAvailableAtThisTime shall be sent.	Implement status noValidSPATisAvailableAtThisTime See chapter 16.
QA_SAFE_010	The RIS Facilities shall remove signal group state change estimates from the LDM and stop transmitting these in case the responsible ITS Application (TLC Adapter Application) doesn t provide new estimates in a timely manner. This may be due to for instance application malfunction or network problems.	Network problems are detected with a keep-alive mechanism. Application malfunction is detected when lifetime of LDM Object times out before receiving new estimates. An ITS Application responsible for this function must be able to provide a continuous signal image for all signal groups around an intersection.

14.4 Availability and resilience

ID	Requirement	How Met
	System
QA_AVAIL_001	It shall be possible to detect a connection failure between an ITS Application and the Facilities	The Facilities maintain a keep-alive mechanism. See chapter 15 and 16.
	TLC Facilities
QA_AVAIL_002	An iTLC shall be able to provide operational availability (control traffic) even if the network connection between a designated traffic control application and the TLC Facilities is lost due to for instance a broken cable or the unavailability of a suitable traffic control application	The architecture allows for brief interruptions of the network connections. The architecture allows for an internal backup traffic control application, which can control traffic while the network connection is lost for a long time. See chapter 8.3 .
QA_AVAIL_003	Failure of (communication with) a traffic control application is detected by TLC Facilities within 1000ms. After 2000ms handled by switching to an available traffic control application or amber flashing.	Every 500ms sending a keep alive message. See chapter 8.1 .
QA_AVAIL_004	The TLC Facilities shall monitor the quality of a connected ITS application controlling traffic and switch over to another application in case the quality of the application is not sufficient. Possible reasons for insufficient qualities: Application itself decides that its requested signal group states are not followed by the TLC Facilities (self-assessment) Signal groups are not activated within timeout (signal group activation supervision) Slow or bad network connection causing excessive timeouts (Facilities assessment)	See chapter 15.
QA_AVAIL_005	The TLC Facilities shall be able to perform traffic control when the TLC Facilities is not synchronized with the actual time. For instance due to not being able to access an NTP server.	TLC-FI defines no direct reliance on UTC timestamps when controlling signal groups, relative times are used.
QA_AVAIL_006	When the TLC Facilities detects it is not time-synched within 100ms of the real time, all estimates explicitly related to this UTC time must be cleared.	See safety model, section 8.3
QA_AVAIL_007	Inputs should be set to unknown if the source is no longer available	An input gets a (default) lifetime
	RIS Facilities
QA_AVAIL_008	If signal group state and timing is not updated each 1000ms, the SPAT-service sends no spat data available.	See section 9.3.3
QA_AVAIL_009	The RIS Facilities must clear the signal group states and state change estimates when they are not updated within set lifetime.	An ITS Application providing signal group states shall provide a lifetime of this information. When this lifetime expires, the information is removed by the RIS Facilities. See section 9.3.3

14.5 Evolution

ID	Requirement	How Met
	System
QA_EVO_001	Extension of or addition to the set of information exchanged/provided by RIS-FI or TLC-FI shall not necessarily lead to a change of data encoding or a change of transport mechanism.	RIS-FI and TLC-FI defined with extension of methods and data objects in mind.
QA_EVO_002	The RIS-FI and TLC-FI must allow for new encoding types or transport mechanisms	Facilities publish their capabilities of encoding and transport. An ITS Application may request transport and encoding. Messages contain encoding identifier and encoded data.
QA_EVO_003	It must be possible for an ITS Application to determine the specification of the data exchanged over the TLC-FI and RIS-FI	Organizational: The TLC-FI and RIS-FI interface specifications need to be standardized and managed, Technical: The TLC-FI and RIS-FI contains version number of the protocols and data elements as standardized.

	TLC Facilities
	N/A
	RIS Facilities
QA_EVO_005	RIS Facilities shall be prepared to be able to use different media to disseminate messages.	Vendor specific

14.6 Accessibility

Not applicable as the system is not directly used by people.
(Maybe Maintenance/Support Engineer is an exception; access to the system is however vendor specific).

ID	Requirement	How Met
	N/A

14.7 Internationalism

	Requirement	How Met
	System
QA_INTL_001	The Architecture must allow for deployment outside the Netherlands	Standardized signal group states are used (according to SAE2735) Possibility to execute traffic control using STOP/GO (green, red) statements and allowing the TLC to handle transitions with respect to safety timing. The architecture has no explicit dependency on a specific traffic control philosophy.
QA_INTL_002	Naming of interface-objects / topics etc. in English language	All deliverables
	TLC Facilities
QA_INTL_003	TLC-FI supports all signal group state changes as used in EU. Only local allowed states are actuated. On not allowed state requests, an error is replied.
	RIS Facilities
	N/A

14.8 Location

ID	Requirement	How Met
	System
QA_LOC_001	It must be possible to deploy functional elements of the architecture in different locations	Deployment variants offer options for deployment
QA_LOC_002	All time-references at RIS-FI and TLC-FI are UTC-timestamps (incl. leap seconds). If needed for further processing, timestamps are converted by Facilities to TimestampIts as defined in [REF007] .	See chapter 16 a nd 15.
	TLC Facilities
n/a
	RIS Facilities
QA_LOC_004	RIS Facilities need to be able to determine if a registered ITS Application is still (logical) connected and alive.	See section 0

14.9 Regulation

ID	Requirement	How Met
	System
	N/A
	TLC Facilities
QA_REG_001	The addition of the TLC Facilities interface does not have any effect of the TLC s Traffic Safety regulation as specified in Dutch and/or European standards.	The TLC itself handles safety as part of the conceptual TLC middleware layer.
	RIS Facilities
QA_REG_002	RIS shall comply with ETSI standards.
QA_REG_003	The RIS Facilities adhere to all relevant privacy standards.

14.10 Testability

	Requirement	How Met
	System
QA_TEST_001	The TLC and RIS Facilities shall maintain basic statistics of their operation	See section 0 and 8.2 Vendor specific implementation
QA_TEST_002	The TLC and RIS facilities shall maintain an event log containing errors and significant events pertaining to their operation	See section 0 and 8.2 Vendor specific implementation
QA_TEST_003	An error log is available with different error-levels and possible a root cause algorithm.	See section 0 Vendor specific
QA_TEST_004	An event log is available. This includes registrations, role switches and other relevant events.	See section 0 and 8.2
QA_TEST_005	TLC-FI and RIS-FI could have a Test account	Vendor specific
	TLC Facilities
	N/A
	RIS Facilities
QA_TEST_006	Logging of transmitted and received ITS-G5 messages is available at the RIS Management-interface.	See section 0

14.11 System quality scenario SPAT transmission

This scenario described the way changes in actual signal group states are used to disseminate SPAT-messages. It also describes the (maximum) latencies and possible failures.

[ link ]

Figure 25 Signal group estimate (SPAT data)

15 TLC-FI Interface requirements

This chapter contains requirements of the TLC Facilities Interface (TLC-FI).

15.1 General requirements

Req-ID	IRS-TLCFI-TIME-001
Title	UTC time
Description	All absolute time references of the TLC-FI shall be done using UTC time
Source
Comment

15.2 Protocol

Req-ID	IRS-TLCFI-PROT-001
Title	IP based
Description	The protocol used when communicating with the TLC-FI shall be based on the Internet Protocol
Source
Comment

Req-ID	IRS-TLCFI-PROT-002
Title	Access channel non secure
Description	The TLC-FI shall be accessible on a specific channel or port number for non-encrypted access
Source
Comment

Req-ID	IRS-TLCFI-PROT-003
Title	Access channel - encrypted
Description	The TLC-FI shall be accessible on a specific channel or port number for encrypted access
Source
Comment

15.3 Communication patterns

Req-ID	IRS-TLCFI-COM-001
Title	Messaging pattern - Request response
Description	It shall be possible to execute a request on the TLC-FI, which results in a response containing the requested TLC Objects. Requests are handled asynchronously (see Concurrency view )
Source
Comment

Req-ID	IRS-TLCFI-COM-002
Title	Messaging pattern Publish subscribe
Description	It shall be possible to subscribe to (attributes of) certain TLC Objects and be notified of their change by the TLC Facilities. It shall be possible to subscribe to notification on change of (attributes of) TLC Objects periodic notification of the status of (attributes of) TLC Objects The ITS application requesting the subscription shall be returned: success / failure of the subscription a unique subscription identifier actual (attributes of) TLC Objects upon which future changes will be sent A subscriber shall be able to remove the subscription by using the subscription identifier.
Source
Comment

Req-ID	IRS-TLCFI-COM-003
Title	Subscriptions inactivity removal
Description	Subscriptions shall be removed by the TLC-FI whenever the subscriber is no longer active due to for instance a broken communication path or deregistration of a subscriber.
Source
Comment	Subscriptions are also removed after power interruption of the TLC Facilities.

15.4 Registration and session

An ITS Application shall be able to connect to the TLC-FI and register itself as an ITS Application. The TLC Facilities is responsible for checking the identity of the ITS Application and check if the authenticated ITS Application is authorised to access the TLC-FI. Conceptually, the ITS Application will follow the state transitions as described in Figure 26.

[ link ]

Figure 26 Session state diagram

Req-ID	IRS-TLCFI-REG-001
Title	ITS Application registration
Description	An ITS Application shall register itself at the TLC-FI before it can access any further services through the TLC-FI. The ITS Application at least provides the following information when registering: Identification credentials (username and password) Requested role (Application type) Requested priority level The TLC-FI is responsible for checking the authenticity and to grant the ITS Application authorisation to access services for which the ITS Application is authorised. In case the ITS Application is either not authenticated or authorised, the TLC-FI will deny access to any further services and shall disconnect the ITS Application.
Source
Comment	The authorisation to access services of the TLC Facilities can be pre-configured in a TLC Facilities layer or it can be provisioned using a TMS-IF interface such as IVERA-TLC.

Req-ID	IRS-TLCFI-REG-002
Title	ITS Application registration Application types
Description	An ITS Application shall be one of the following application types ITS control application ITS provider application ITS consumer application
Source
Comment

Req-ID	IRS-TLCFI-REG-003
Title	ITS Application registration - priority levels
Description	An ITS Application shall be assigned a priority level. This priority level is managed by the TLC Facilities. The priority levels shall be relative values giving an ITS Application a unique priority within the set of ITS Applications registered with the TLC-FI. An ITS Application with a higher priority is served first when the TLC-FI has to make a choice between serving multiple ITS Applications.
Source
Comment	For instance, two ITS Applications subscribed to the same changes in TLC Objects will be provided this information in prioritized order. When manipulating a TLC object, the same priority is enforced. When multiple ITS Applications have rights to manipulate a single TLC object, access is handled at the organizational level.

Req-ID	IRS-TLCFI-REG-004
Title	ITS Application deregistration request
Description	It shall be possible for an ITS Application to deregister itself from the TLC-FI. The TLC-FI shall inform the ITS Application about the result of the deregistration, after which the ITS Application may no longer use the services of the TLC-FI.
Source
Comment	The TLC-FI shall (by preference) gracefully terminate the sessions and therefore be conservative in closing any lower layer connection so that the ITS Application can properly receive feedback on its request.

Req-ID	IRS-TLCFI-REG-005
Title	ITS Application deregistration by TLC-FI
Description	It shall be possible for the TLC-FI to deregister an registered ITS Application, and thereby remove it from the list of registered ITS Applications. The TLC-FI shall inform the ITS Application about the deregistration, the ITS Application may no longer use the services of the TLC-FI. The TLC-FI may revoke the rights to access of the services prior to sending the notification.
Source
Comment	This may be used when an ITS Application is revoked access from to the TLC Facilities.

Req-ID	IRS-TLCFI-REG-006
Title	Alive Checking
Description	Both TLC-FI as well as registered ITS Applications shall be able to detect broken communication paths or not responding applications/interface.
Source
Comment

Req-ID	IRS-TLCFI-REG-007
Title	Alive Checking TLC-FI actions
Description	If the TLC Facilities detects a not responding ITS Application or a broken communication path, the following actions are taken: ITS Application is deregistered Subscriptions are removed Session is terminated Entry added to system log
Source
Comment	The ITS Application is responsible for re-establishing the connection. The TLC-FI will not attempt to restore the connection.

15.5 ITS control application

An ITS control application performs the current major use-case of a TLC: regulating traffic flow by means of requesting intersection-wide status changes such as amber flashing, dark, or all-red as well as requesting external signal group states. Specific requirements for this application type are described in this paragraph.

15.5.1 Registration

Prior to being allowed to control signal groups or intersection states, the ITS control application is assumed to have been properly registered according to the requirements in section 15.4. The ITS Control application requires additional registration with the TLC-FI to allow for actual control of the signal groups and intersection.

Req-ID	IRS-TLCFI-ICA-REG-001
Title	ITS Control application - specific registration
Description	An ITS control application which has been registered with the TLC-FI, shall proceed with a specific ITS control application registration procedure to be allowed to execute control of the intersection and its assigned signal groups. The ITS Application shall provide configuration information of the intersection of which it wants to take control to the TLC-FI so that the TLC-FI can decide if the ITS control application is configured correctly and is allowed to take control. The following information shall at least be provided: Intersection IDto control List of signal groups it requests to control for this intersection List of detectors it will monitor for the intersection When the TLC-FI accepts the configuration, the ITS control application may be given the rights to actively control the intersection and its signal groups.
Source
Comment	The ITS Application can request meta information from the TLC-FI prior to the control specific registration, for instance for configuration of the ITS control application.

15.5.2 Activation and deactivation

Req-ID	IRS-TLCFI-ICA-AD-001
Title	ITS Control application - ready to control
Description	An ITS control application, which is allowed by the TLC-FI to be given active control of an intersection must, prior to being activated by the TLC-FI, indicate that it is ready to control the intersection.
Source
Comment

Req-ID	IRS-TLCFI-ICA-AD-002
Title	ITS Control application - activate control
Description	The TLC-FI is responsible for activating an ITS control application. It is the responsibility of the TLC-FI to only select an ITS control application which has explicitly indicated that it is ready to control. The ITS control application is said to be in control from this moment.
Source
Comment

Req-ID	IRS-TLCFI-ICA-AD-003
Title	ITS Control application - deactivate
Description	The TLC-FI shall be able to deactivate an ITS Control application which is in control. The TLC-FI shall inform the ITS Control application of the deactivation and the ITS control application shall be in control until the deactivation procedure is concluded. The TLC-FI is responsible for notifying the ITS control application being deactivated when it is no longer in control
Source
Comment

Req-ID	IRS-TLCFI-ICA-AD-004
Title	ITS Control application - abandon control
Description	An ITS control application which is in control shall be able to abandon control. The TLC-FI is then responsible for deactivating the ITS control application and selecting a new one. The ITS Control application which abandoned control shall only be allowed to control again after it requests control.
Source
Comment	The ITS control application may for instance perform such a request when it is scheduled to be terminated for maintenance.

Req-ID	IRS-TLCFI-ICA-AD-005
Title	Exclusive intersection control
Description	There shall be only one ITS control application in control for a specific intersection and its associated signal groups at a given moment in the time. The TLC-FI shall enforce this by selecting the ITS control application allowed to be in control of a specific intersection.
Source
Comment	There may be different sources selecting a specific program, such as IVERA-APP, time of day, manual panel etc.

Req-ID	IRS-TLCFI-ICA-AD-006
Title	Multiple intersection control
Description	It shall be possible for an ITS control application to control multiple intersections and their associated signal groups within one session.
Source
Comment

Req-ID	IRS-TLCFI-ICA-AD-007
Title	Multiple ITS control applications
Description	When a TLC is responsible for multiple intersections, it shall be possible that different ITS Control applications are in control of the different intersections.
Source
Comment

15.6 ITS provider application

An ITS provider application is allowed to provide information to the TLC-FI. This includes adding and deleting specific TLC Object types, updating attributes of existing TLC Objects types. This is described in more detail in section 15.8.

15.7 ITS consumer application

An ITS consumer application is allowed to read and subscribe to changes of TLC Objects.

15.8 TLC Information

15.8.1 TLC Object dictionary

The information exchanged between ITS Applications and the TLC-FI are stored in TLC Objects. A TLC Object is of a specific type and contains attributes. TLC Objects and their attributes can be mandatory or optional. TLC Objects can be added, updated, read, deleted as well as subscribed for notifications when changes are made to them. This section provides description of the TLC Object types.

Req-ID	IRS-TLCFI-TIF-OD-001
Title	TLC Object dictionary
Description	The TLC Object dictionary shall contain Version TLC Objects with attributes For each TLC Object and its attributes if it is mandatory or optional For each TLC Object type and its attributes, what type of access rights can be assigned to it (Add, Update, Delete, Read) For each TLC Object type, the pre-defined filters.
Source
Comment

Req-ID	IRS-TLCFI-TIF-OD-002
Title	TLC Objects
Description	All information accessible to ITS Applications on the TLC-FI is made available as TLC Objects. A TLC Object is of a specific type and can have several attributes.
Source
Comment

Req-ID	IRS-TLCFI-TIF-OD-003
Title	TLC Object dictionary version
Description	The TLC Object dictionary shall be under version control and the version shall be made available as meta information on the TLC-FI
Source	QA_EVO_001, QA_EVO_003
Comment

Req-ID	IRS-TLCFI-TIF-OD-004
Title	TLC Object requirements
Description	For each TLC Object type and for each of its attributes it shall be identified if it is mandatory or optional.
Source
Comment

Req-ID	IRS-TLCFI-TIF-OD-005
Title	TLC Object access rights
Description	For each TLC Object type access rights shall be defined. The following access rights shall be assigned to objects and attributes of objects: Update : Update this object s attributes Read : Read the content of this object The access rights are defined per ITS Application type.
Source
Comment

Req-ID	IRS-TLCFI-TIF-OD-006
Title	TLC Object identification
Description	Each instance of a TLC Object shall be uniquely identified within the TLC-FI.
Source
Comment

15.8.2 TLC Object query and manipulation

Req-ID	IRS-TLCFI-TIF-OM-002
Title	Updating a TLC Object
Description	Authorized ITS Applications shall be able to update a TLC Object and its attributes.
Source
Comment	Updating attributes of TLC Objects may result in change of outputs of the TLC such as signal group external states.

Req-ID	IRS-TLCFI-TIF-OM-003
Title	Querying a TLC Object
Description	Authorized ITS Applications shall be able to query a TLC Object The result set contains the TLC-Objects with attributes requested. The querying of a TLC Object shall be subject to the filtering requirements.
Source
Comment

15.8.3 TLC Object types

As described in previous sections, the TLC Object types are described in the TLC Object dictionary. This is the authoritative source of the definition of the objects. This section provides the required types of objects from a functional level while the TLC Object dictionary describes the details.

Req-ID	IRS-TLCFI-TIF-OT-001
Title	TLC Object types
Description	The following TLC Object types shall be supported Intersection Detector Signal group Public transport / Emergency vehicle Multifunctional digital input Multifunctional digital output Meta information
Source
Comment

Req-ID	IRS-TLCFI-TIF-OT-002
Title	TLC Object Intersection
Description	The Intersection object shall contain the following attributes: Identification Active state (state and source) Requested state Fault state Special function variables Manual intervention request Manual control active Active ITS control application List of signal groups List of detectors
Source
Comment

Req-ID	IRS-TLCFI-TIF-OT-003
Title	Intersection requested state
Description	An authorized ITS control application shall be able to update the Requested stateattribute of the Intersection object. The TLC-FI is then responsible for executing the transition from the current active state to the new requested state. In case a higher priority request is present which has selected the active state, the ITS control application must be informed of this.
Source
Comment

Req-ID	IRS-TLCFI-TIF-OT-004
Title	TLC Object Signal group
Description	The Signal Group object shall contain the following attributes: Identification Functional stateTime in state Requested state Fault state (deadlock, lamps) Meta information Timing (E.g. Minimum red, minimum green) Conflicts

Comment

Req-ID	IRS-TLCFI-TIF-OT-005
Title	Signal group requested external state
Description	An ITS control application shall be able to change the requested external state attribute of a Signal group. The change may be a functional change (GO / STOP) or it may be an explicit external signal group state (Red, Green, Amber) A change of the requested external state shall have the following consequences: The TLC-FI shall acknowledge the change and update attributes related to timing of this signal group state change The TLC Facilities shall use the requested external state to perform an orderly transition to the requested state including safety times and transition states. External signal group states shall be based on the definitions of [REF140]
Source	QA_INTL_001, [REF140]
Comment

Req-ID	IRS-TLCFI-TIF-OT-007
Title	TLC Object Detector
Description	The Detector object shall contain the following attributes: Identification Active state (Active, Inactive, Fault, SWICO ON, SWICO OFF) Time in active state Fault state (occupy timeouts , hardware error, flutter) Speed Length Classification Direction Meta information Detector functions
Source
Comment

Req-ID	IRS-TLCFI-TIF-OT-008
Title	TLC Object Public transport and Emergency Vehicle
Description	The Public transport and Emergency vehicle object shall contain the following attributes: Identification Vehicle type Information type (checkin, checkout, etc.) Location / Distance to stop line Line number Service number Company number Journey number Journey category Direction Punctuality class Punctuality Priority class Length Speed Vehicle status (Driving, halted, etc.)
Source
Comment

Req-ID	IRS-TLCFI-TIF-OT-009
Title	TLC Object Multifunctional digital inputs
Description	The Multifunctional digital inputs shall contain the following attributes: Identification Value Time since last change Software switch status (SWICO ON, SWICO OFF)
Source
Comment

Req-ID	IRS-TLCFI-TIF-OT-010
Title	TLC Object Multifunctional digital outputs
Description	The Multifunctional digital output shall contain the following attributes: Identification Value Time since last change
Source
Comment

Req-ID	IRS-TLCFI-TIF-OT-012
Title	TLC Object Meta information
Description	The Meta information object shall contain the following attributes: TLC Object dictionary version Manufacturer information Intersection topology data Clearance matrix
Source
Comment

15.9 Quality attributes

15.9.1 Performance

Req-ID	IRS-TLCFI-QA-PERF-001
Title	Latency classes
Description	For a number of performance requirements different classes of latency can be used. The following list defines the different classes: Class 1 : 10ms Class 2 : 25ms Class 3 : 50ms Class 4 : 75ms Class 5 : 100ms Class 6 : 200ms Class 7 : 300ms
Source	QA_PERF_002, QA_PERF_003
Comment

Req-ID	IRS-TLCFI-QA-PERF-002
Title	Concurrent ITS Applications
Description	TLC-FI shall support at least 10 concurrent ITS Applications
Source
Comment

Req-ID	IRS-TLCFI-QA-PERF-003
Title	ITS Applications number of subscriptions
Description	TLC-FI shall support at least 5 subscriptions per ITS application
Source
Comment

Req-ID	IRS-TLCFI-QA-PERF-004
Title	ITS Applications number of requests / replies
Description	TLC-FI supports at least 10 request/replies per second per ITS Application
Source
Comment

Req-ID	IRS-TLCFI-QA-PERF-005
Title	ITS Applications number of notifications
Description	TLC-FI supports at least 10 notifications per second per ITS Application
Source
Comment

Req-ID	IRS-TLCFI-QA-PERF-006
Title	TLC-FI latency
Description	The latency between a request at TLC-FI and the resulting response shall comply to class 5 of Requirement IRS-TLCFI-QA-PERF-001.
Source	, QA_PERF_001
Comment

Req-ID	IRS-TLCFI-QA-PERF-007
Title	Publish subscribe latency
Description	When an ITS application has changed an (attribute) of a TLC Object, the changed object shall be published within 50ms in case the subscribing application has the highest priority and is subscribed to real-time updates.
Source	, QA_PERF_004
Comment

15.9.2 Availability

Req-ID	IRS-TLCFI-QA-AVAIL-001
Title	Resilience against temporal network disruption
Description	It shall be possible for a TLC-FI to withstand temporal network disruption without major loss of function.
Source	, QA_AVAIL_002
Comment	For instance, the possibility for a functional request of signal group state without hard timing constraints make this possible.

Req-ID	IRS-TLCFI-QA-AVAIL-002
Title	ITS control application self-assessment
Description	It shall be possible for an ITS control application to provide the TLC-FI with its own quality self-assessment. This assessment will include the results from for instance Excessive deviations between requested and actual signal group states Internal processing failures Restart attempts The TLC-FI shall receive this information and based on the information, the TLC facilities shall make a decision of the ITS control application must be deactivated and replaced with a new ITS control application.
Source	, QA_AVAIL_004
Comment

Req-ID	IRS-TLCFI-QA-AVAIL-003
Title	Traffic control with relative timing
Description	It shall be possible for an ITS control application provide functional traffic control even if the ITS control application is not synchronized with the UTC time. The information exchanged between the ITS control application and TLC-FI shall therefore have no explicit dependency on the UTC time. Some attributes of TLC Objects such as the estimated time to external state change can therefore be updated using a relative time, while an ITS consumer application expects the TLC-FI to provide the values with absolute UTC time stamps.
Source	, QA_AVAIL_005
Comment

Req-ID	IRS-TLCFI-QA-AVAIL-004
Title	Estimated signal group states UTC time
Description	The Signal group estimated time to external state change attribute shall be set to the value unknown by the TLC Facilities when the local time is not synchronized with the UTC time within 100ms.
Source	, QA_AVAIL_006
Comment

15.9.3 Evolution

16 RIS-FI Interface requirements

This chapter contains requirements of the RIS Facilities Interface (RIS-FI).
General requirements

The following requirements are applicable to the RIS-FI in general.

Req-ID	IRSIDD_RISFI_GEN_001
Title	Time referencing
Description	Time-references used at RIS-FI shall be UTC-based. Notation of time-references shall be according to ISO8601
Source
Comment

Req-ID	IRSIDD_RISFI_GEN_002
Title	Geo referencing
Description	References to geographical locations are described as a coordinate according to WGS84.
Source
Comment

16.1 Protocol

Below some high level requirements regarding the interface-protocol are described.

Req-ID	IRSIDD_RISFI_PROT_001
Title	IP-based
Description	The interface between the RIS and the ITS-Applications shall be IP-based.
Source
Comment

Req-ID	IRSIDD_RISFI_PROT_002
Title	Request-reply
Description	For each request sent by an ITS Application the RIS Facilities shall send a reply.
Source
Comment

Req-ID	IRSIDD_RISFI_PROT_003
Title	Publish-Subscribe
Description	ITS Applications can register subscriptions with the RIS-Facilities. Notifications shall be sent by the Facilities according to the subscription-properties (e.g. filter, periodicity).
Source
Comment

Req-ID	IRSIDD_RISFI_PROT_004
Title	Concurrency
Description	Requests are handled asynchronously (non-blocking).
Source
Comment

16.2 Security

Before ITS Applications can use the RIS-FI, authentication has taken place (2-way). After an ITS-Application is authenticated, the application needs to register itself with the RIS-FI (see section 16.3). During registration, applicable permissions are assigned to the application. After registration, authorization takes places based on these assigned permissions.

Req-ID	IRSIDD_RISFI_SEC_001
Title	Permissions checking
Description	Each request sent by an ITS Application shall be validated by the RIS Facilities according to the applying permission of the specific ITS Application instance. If the permissions do not permit the execution of the request, a failure notification shall be sent to the calling ITS-Application.
Source
Comment

16.3 ITS Application Registration

Registration of ITS Applications involves the following:

registration of the ITS Application (including authentication and authorization) at the RIS-FI
notification of ITS Application of updated/revoked roles or permissions ( Permission Changed -event)
deregistration of ITS Applications

Below, the requirements to support the registration of ITS-Applications are described:

Req-ID	IRSIDD_RISFI_REG_001
Title	Registration of ITS Applications (authorization)
Description	An ITS Application needs to register itself before it can use the RIS-FI any further.
Source
Comment	With the registration request, the ITS Application provides at least the following information: Application Identifier Requested Role (see IRSIDD_RISFI_REG_007) Requested maximum priority-level The request is processed by the RIS Facilities by using the Security Entity which will authorize the ITS Application (assign permissions). The result of the request (rejected with reason or accepted with applicable permissions) is replied to requesting ITS Application. If registration is accepted, the ITS Application is informed about the applicable permissions and priority-level. The ITS Application may decide to deregister if it concludes the returned priority level it too low or applicable permissions not sufficient. Used priority levels per ITS Application need to be agreed upon between suppliers of ITS Applications. A successful registration will start the alive-checking feature.

Req-ID	IRSIDD_RISFI_REG_002
Title	ITS Application identification
Description	Every ITS Application instance registered at RIS-FI shall be uniquely identifiable.
Source
Comment

Req-ID	IRSIDD_RISFI_REG_003
Title	Alive Checking
Description	Both RIS-FI as well as registered ITS Applications shall be able to detect broken communication paths or not responding applications/interface.
Source
Comment	Detection-properties (e.g. heartbeat-frequency or time-out values) need to be agreed upon between the ITS-Application and the RIS-FI during Application-registration.

Req-ID	IRSIDD_RISFI_REG_004
Title	Deregistration by Facilities
Description	If the RIS Facilities detects a not responding ITS Application or a broken communication path, the following actions are taken: ITS Application is deregistered Subscriptions are removed Session is terminated Entry added to system log
Source
Comment	The ITS Application is responsible for re-establishing the connection after a keep-alive timeout. The RIS-FI will not make any attempts to restore the connection.

Req-ID	IRSIDD_RISFI_REG_005
Title	Permissions Changed Notification
Description	A notification of changed permission shall be sent by the RIS-FI to the applicable ITS Application when applying permissions of this ITS Application have been changed.
Source
Comment	A Permission Changed Notification can be send because of the following reasons: Maximum set of permissions changed (e.g. actual permissions of an already registered ITS Application may be revoked by e.g. the Management Entity) Actual applicable set of permissions has changed; used to implement exclusive permissions (only 1 of n ITS Applications is permitted). The notification also contains the reason for change.

Req-ID	IRSIDD_RISFI_REG_006
Title	Deregistration Request
Description	An ITS Application can deregister itself if it will not use the RIS Facilities any further. Because of the deregistration, the RIS Facilities will: remove subscriptions of this ITS Application terminate the session add entry to system log
Source
Comment	Deregistration is useful to free resources at the RIS-FI. Can also be used prior to updating an ITS Application.

Req-ID	IRSIDD_RISFI_REG_007
Title	Available ITS Application groups
Description	The following groups (roles) shall be available for ITS Applications to use during registration: Data Consumer Data Provider Topology Provider An ITS Application can have multiple roles at the same time (e.g. act as a Data Consumer and Data Provider).
Source
Comment

16.4 Station Services

The RIS contains additional services, some of which are accessible by using the RIS-FI.

Req-ID	IRSIDD_RISFI_SVC_002
Title	RIS meta data
Description	It shall be possible to request meta data of the RIS. The meta data contains at least the following information: Version of RIS-FI Topology meta data: Versions of software components, e.g.: RIS Facilities RIS geographical position as WGS84-coordinate RIS manufacturer
Source
Comment

16.5 Quality attributes

16.5.1 Multiple applications - scalability

Req-ID	IRSIDD_RISFI_QA_SCAL_001
Title	Concurrent ITS Applications
Description	The RIS-FI shall support at least 10 concurrent ITS Applications.
Source	QA_PERF_025
Comment

Req-ID	IRSIDD_RISFI_QA_SCAL_002
Title	Number of requests/replies
Description	RIS-FI shall be able to process at least 20 concurrent API-requests/replies each second per ITS Application
Source	, QA_PERF_025
Comment

Req-ID	IRSIDD_RISFI_QA_SCAL_003
Title	Number of subscriptions
Description	RIS-FI supports at least 10 subscriptions per ITS Application.
Source	, QA_PERF_025
Comment

Req-ID	IRSIDD_RISFI_QA_SCAL_004
Title	Notification update interval
Description	RIS-FI shall be able to send 25 notifications per second per ITS Application
Source	, QA_PERF_025
Comment

4.8.1.1 Latencies / Performance

Req-ID	IRSIDD_RISFI_QA_PERF_001
Title	Latency of interface
Description	Latency max 100 msec between request at RIS-FI and resulting in response at RIS-FI.
Source	QA_PERF_009
Comment

Req-ID	IRSIDD_RISFI_QA_PERF_003
Title	Process number of ITS-G5 messages
Description	At least, the RIS Facilities shall be able to process 250 received ITS-G5 messages per second.
Source	, QA_PERF_029
Comment

16.5.2 Availability

Req-ID	IRSIDD_RISFI_QA_AVAIL_001
Title	Resilience against temporary network disruption
Description	It shall be possible for a RIS-FI to withstand temporary network disruption without major loss of function.
Source
Comment

17 VLOG Interface requirements

This chapter contains requirements of the VLOG interface.

Req-ID	IRS-VLOG3-001
Title	Standards compliance
Description	When defining functional additions to the protocol, conformance with international standards shall be sought.
Source
Comment	For instance, standards such as specified for cooperative systems in ETSI shall be followed.

Req-ID	IRS-VLOG3-002
Title	Protocol compliancy
Description	The V-Log protocol shall be an extension of the current V-Log 2.1 protocol
Source
Comment

Req-ID	IRS-VLOG3-003
Title	Time-to-green (TTG) information
Description	The V-Log data shall contain information about the expected time remaining until green realization. The following information is required: Minimum time (unit [s], resolution 0.1s). Maximum time (unit [s], resolution 0.1s) Likely time (unit [s], resolution 0.1s) A specific value shall be used in case any of the above mentioned times are unknown. Confidence (OPTIONAL) value of the likely time following [SAE-J2735]
Source
Comment	All times identifies an explicit time in the future. This time is a combination of the time-reference message, delta-time field of the status and/or change messages in combination with the expected times. When the minimum time is known, it may not be changed to an earlier point in time with a new message. Similarly, a maximum time may not be changed to a later point in time. However, minimum and maximum times can be changed to unknown . When the minimum and maximum times are equal, the actual time is guaranteed. (Not conform SAE) Maximum is always larger than or equal to the minimum time. The likely time provides the most likely remaining time. This time may be based on historical values, detection data or any other means to give accurate predictions. It is always between the minimum and maximum times. The confidence value indicates the level of confidence of the likely time. Note: The confidence value is defined to be compliant with the [SAE-J2735] Signal Phase and Timing (SPAT) messages.

Req-ID	IRS-VLOG3-004
Title	Remaining green time (RGT) information
Description	The V-Log data shall contain information about the expected remaining green time. The following information is required: Minimum time (unit [s], resolution 0.1s). Maximum time (unit [s], resolution 0.1s) Likely time (unit [s], resolution 0.1s) A specific value shall be used in case any of the above mentioned times are unknown. Confidence (OPTIONAL) value of the likely time following [SAE-J2735]
Source
Comment	All times identifies an explicit time in the future. This time is a combination of the time-reference message, delta-time field of the status and/or change messages in combination with the expected times. When the minimum time is known, it may not be changed to an earlier point in time with a new message. Similarly, a maximum time may not be changed to a later point in time. However, minimum and maximum times can be changed to unknown . When the minimum and maximum times are equal, the actual time is guaranteed. (Not conform SAE) Maximum is always larger than or equal to the minimum time. The likely time provides the most likely remaining time. This time may be based on historical values, detection data or any other means to give accurate predictions. It is always between the minimum and maximum times. The confidence value indicates the level of confidence of the likely time. Note: The confidence value is defined to be compliant with the [SAE-J2735] Signal Phase and Timing (SPAT) messages

Req-ID	IRS-VLOG3-005
Title	TTG and RGT update
Description	A TTG or RGT update shall be sent when the expected times have changed. The number of messages shall be limited by sending one message at most every 1 second. For changes less than one second no update shall be sent. Changes more than 10% of the current value will lead to an update.
Source
Comment	The intention is to avoid congestion of messages. It is allowed to limit the number of messages even further when the impact on the prediction is low.

Req-ID	IRS-VLOG3-006
Title	Reason for Wait time
Description	It shall be possible to indicate a general reason for extra wait time. Each reason is either active or inactive. Examples of type of reasons: Public transport priority Emergency vehicle priority Train crossing active Bridge intervention Height warning Weather intervention Traffic jam intervention Tunnel closed Dosing active
Source
Comment

Req-ID	IRS-VLOG3-007
Title	Active environmental factors
Description	It shall be possible to indicate a change in active environmental factors. Each factor can be either active or inactive. Examples Rain Mist Risk of slipperiness
Source
Comment

Appendix 1. Estimation of ITS-G5 message rate at RIS

According to QA-attribute Performance QA_PERF_026, the RIS Facilities shall be able to at least process a minimum of 250 received ITS-G5 messages per second.

This minimum number is based on received CAM s only and is estimated by evaluating measured traffic intensity of an average intersection.

By calculating the density (using an assumed average velocity) the number of ITS-vehicles within the ITS Stations (RIS) radio-coverage can be calculated. For this number of vehicles, with an estimated Cam generation-frequency, the total number of CAM s received at a RIS is determined.

Assumptions:

Velocity at intersection(-arms): 60 km/h
Radio-coverage: 500 m (radius)
Number of vehicles equipped with WifiP: 24% (in 2021) of total vehicles
CAM generation frequency: 5Hz

[ link ]

Figure 27 Appendix B. Estimation of ITS-G5 message rate at RIS

Interesse?

Specifications iVRI Architecture, iVRI Architecture