Use Case 16: iTLC Prioritisation of Public Transport

Operation use case

A service provider connects a fleet of public transport vehicles that are connected to their backend system or other facilities that can provide the necessary information. These vehicles can request priority according to their characteristics. For this use case, 'bus' and 'tram' vehicles will be able to be prioritised for iTLCs connected to the Mobilidata Traffic Light Exchange.

There are a few conditions that must be met:

• The route of the bus/tram must be known:
  • or communicated in advance (later further development to use timetable, now not in scope)
  • or known thanks to Truckmeister navigation
• The priority can only be requested 'on connection', which means that it must be known which manoeuvre it will perform at the traffic light/intersection).

The flow looks like this:

• the vehicle is connected (to transmit positions) to the Service Provider
  • or via a backend to backend connection
  • or via Truckmeister
• the Service Provider tracks the vehicle and calculates ETA to each traffic light
  • If the vehicle deviates from the route forwarded in advance, no priority can be given.
  • if the vehicle is driven via Truckmeister, a deviation will result in a recalculation to a new route and time.
• If the vehicle approaches a traffic light, priority is requested (taking into account the manoeuvre) at 1 minute from the traffic light
  • We don't take into account timetables (and the typical stop times at stops). In a separate commercial trajectory, Be-Mobile does offer this to the public transport companies as part of a full offering.
• the status of the priority request is visualized for the end user when using Truckmeister, or forwarded to the backend system

Position of the applicant:

• A connection is set up to get positions:
  • The driver starts up Truckmeister and selects the right vehicle class
  • OR the vehicle is connected to a track & trace system of the public transport party and forwards the stream of positions to the service provider backend
• The driver drives the planned or calculated route
• Approaching traffic lights is detected by the Service Provider and priority is requested

Data sources

Track & trace system of the public transport party

The track & trace system of the public transport party must be able to provide at least the following data elements:

• Position every second with the highest possible accuracy (HDOP < 5)
• Timestamp GNSS receiver
• Type of vehicle (bus, tram) which is later mapped to the correct role and subrole combination
• Unique ID per trip
• Speed
• Trip type (in commercial service or other type of trip that does not require priority)
• Planned route as WGS84 linestring. This must be accurate down to lane or track level, otherwise the correct signal group will not be selected.

Priority Configuration

A valid priority configuration with transit priority rules must be present in the Priority Configurator at the traffic lights that are present on a transit line.

Crossroads topology

There must be an intersection topology in ETSI MAP format in which the lanes and/or tracks are present. This is in accordance with the Dutch Profile 3.0.0.

Data processing

PIP

The PIP has no function in this priority use case.

Priority Validator

The priority validator retrieves all priority rules set by the road authority. These contain a set of parameters that must be met in order to be allowed to request priority, including the priority level at which a particular vehicle can request priority. When approaching an iTLC and starting a priority flow, the priority validator will check the current characteristics of the vehicle (e.g. id of the iTLC, approach, connection, vehicle type, etc.) and determine at what level the vehicle may request priority. If no rule is sufficient, the service provider will fall back on an SRM-0 message without priority. If a certain rule is met, the corresponding priority level will be entered in the priority requests (SRM) that have been sent. These are then put on the MI and forwarded to the priority agent.

Traffic Light Priority Configurator

The Traffic Light Priority Configurator consists of two components: the input tool for road authorities to define priority rules at his or her intersections which is an integral part of the Traffic Light Exchange platform, as well as an API on which these configured rules are made available to all service providers and the priority agent. The road authority can use this component to set which parameters must be met in order to be able to request priority with a certain level. The set of parameters that can be set as a road authority are fixed in the official priority broker configurator specifications which are defined in the Mobilidata program.

Traffic Light Priority Agent

The Traffic Light Priority Agent acts as a gateway in the Mobilidata ecosystem. This component receives the SRM requests from all service providers in the ecosystem and will check them for correctness. To do this, the agent will evaluate the set priority rules against the information available in the SRM. If the agent notices that the priority level from the service provider does not comply with the rules, the SRM request will be blocked. The agent also keeps a log of the number of incorrect requests per service provider in the ecosystem in order to detect underperforming service providers. In addition, the agent will also do a technical validation of the incoming SRM messages (correct protocol version, mandatory fields filled in, etc.)

RUF

Not applicable.

MI & Historical Archive

The following flows run through the MI:

• Validated SRM messages by the Service Provider
• SSM messages from the iTLC and Priority Agent
• MAP messages from the iTLC
• CAM messages from the public transport vehicle

MI & Historical Archive

High level architecture

The following flows run through the MI:

• Validated SRM messages by the Service Provider
• SSM messages from the iTLC and Priority Agent
• MAP messages from the iTLC
• CAM messages from the emergency vehicle

SRM, CAM and SSM messages contain location data of priority vehicles that can be linked to people. These messages are not (for the time being) stored in the historical archive.

MI headers

SREM

{
  "messageType": "SREM",
  "originatingCountry": "BE",
  "protocolVersion": "SREM:1.3.1",
  "publisherId": "BE00004",
  "publicationId": "BE00004:SREM_PV_02",
  "publisherType": "Priority Validator",
  "custom-mobilidata-dtapEnvironment": "production",
  "quadTree": [
  ]
}

SSEM

{
  "messageType": "SSEM",
  "originatingCountry": "BE",
  "protocolVersion": "SSEM:1.3.1",
  "publisherId": "BE00004",
  "publicationId": "BE00004:SSEM_PV_02",
  "publisherType": "Priority Validator",
  "custom-mobilidata-dtapEnvironment": "production",
  "quadTree": [
  ]
}

Service Provider Implementation

The Service Provider is responsible for executing the priority use case in accordance with the functional standard described in the Dutch Profiles. We refer to the following page: CROW. We briefly review the most important elements in the step-by-step plan below.

1. Calculate ETA. For each new position it obtains from the priority vehicle (PV), SP calculates the ETA (Estimated Time of Arrival) to the iTLCs that are on the route of the public transport vehicle. For every iTLC of which the ETA of the public transport vehicle is less than 1 minute, a priority request is initiated.
2. Priority request checking. In a second step, the Priority Validator checks the priority rules for the intersection and signal group where priority is requested. This takes into account all vehicle characteristics that are also used in the priority rules. How the Priority Validator works and how it uses the Priority Configurator. If the vehicle complies with the rules, step 3 will be taken. If this is not the case, no priority will be requested. The road user will not be informed of this.
3. Start of the priority request. The priority request is then initiated by creating an initial SRM message and sending it to TLEX, completely according to the specifications. The TLC from the iTLC package checks the request and returns a response via an SSM message. The different possible answers are listed in the SSM standard.
   • Update of the priority request. The CSP periodically calculates a new ETA and sends it in an SRM message to the TLC, to which the TLC replies again with an SSM message.
   • increased frequency and CAM messages in the MAP area. When the priority vehicle has reached the MAP area of the iTLC, we create CAM messages that are sent to the iTLC at a frequency of 1Hz via TLEX.
4. Canceling a priority request. When the public transport vehicle has crossed the stop line, the CSP creates a cancellation SRM . This is a special type of SRM, which informs the iTLC that the priority request has been aborted.