Public transportation preference using V2X

This way of solving public transportation vehicle preference uses V2X communication protocols (via C-ITS systems). In general, it is a way of communication between vehicles equipped with OBU units (On Board Units) (in our production unit UCU 5.0) and RSU units (Road-Size Unit) at intersection controller units. The communication runs as per a defined communication diagram of assigning preference i.e. vehicle units send requests (sign ins, stationing, sign outs) to the intersection that they are approaching or passing through. Subsequently they receive a reply about the possibility of being assigned a preference or about the intersection control state (information about the future green light).

The supplied system is based on the document: C-ROADS CZ PTP 1.52 (hereinafter just „Document C-ROADS“) as it was approved by the Control committee of the C-ROADS CZ consortium. The preference system itself is in accordance with this document and it is based on our experience from numerous cities and it is publicly known.

Principle

In the vehicle above the driver cabin, there is a universal communication unit UCU 5.0V. At the intersection there is a communication unit UCU 5.0 I. These two units communicate with each other as commanded by an on-board computer using one of the following:

• V2X communication – direct fast communication of medium reach given by the position and quality of antennas,
• LTE communication -– distant communication and timely notification of the traffic lights controller unit.

Both ways are usually used if they are available. (however V2X is usually enough) All the needed information is  entered using EPCOMP v2 (SW for on-board computer data preparation) or it is obtained dynamically during operation (e.g. delays, etc.). All communication is controlled by position information from a GNSS module (global navigation satellite system) and it contains module GPS/GLONAS and GALILEO ready. The principle of communication between the units is depicted by the following picture.

On the controller unit side there is communication between unit UCU 5.0-I  and the traffic light controller unit. The UCU unit provides the controller with information from a public transportation vehicle via the below listed protocol. The unit uses two interfaces to communicate with the controller:

• RS-485 – this busbar is used for already existing intersections (deployed in Brno and tested in Ostrava)
• Ethernet – this busbar is used for new intersection installations

Currently  three types are in use:

1. sending requests to controller unis with no repetition – only used for classic radio modems (not suitable for V2X).
2. Sending to a controller unit with a confirmation from the controller unit – see the description of unilateral V2X communication below.
3. Communication vehicle– intersection controller unit.  The description of the first test of this technology is included in this  press release.

Sequence of states of the current preference control

The current state of using one-way public transportation vehicle preference has the following key features:

1. Municipal public transportation vehicle actively sends a preference request.
2. This request is sent from predefined geographical points (so called sign in and sign out areas) or during a defined vehicle state change (stopping at a stop, departing a stop, closing the doors, etc…).
3. The MPT vehicle can successively sign in from multiple geographical points (making its position more accurate) or otherwise update its state.
4. The preference request is most often created by the on-board computer and the OBU unit just transfers it to the controller unit via radio.
5. The request is created based on saved data in relation to “the vehicle drive” (behavior instructions).
6. The driver can request preference manually at an intersection or when driving from a “side“ direction (for example via an on-board computer).
7. Each request from an MPT vehicle is minimally confirmed by the RSU unit (in the Czech Republic not valid for all preferences in a TC) and this confirmation is displayed to the driver in such a way that the driver has to put into  place an individual control branch.
8. The vehicle can request preference at numerous intersections at the same time.
9. The decision whether the preference will be assigned lies fully within the controller’s authority and the driver has no information about the state of processing.
10. A sign out message is used to terminate the preference request. It is sent either from a given geographical point or during a change of the vehicle state (departure from a stop behind the intersection).

The vehicle operator i.e. a transportation company configures vehicle behavior in this public program. What is mainly configured:

• Geographical areas for signing in/out.
• Entry and exit intersection part.
• Sign in and sign out request sequence (multiple sign in areas, reaction to stopping at a stop, leaving the intersection).

Used V2X messages

Only standardized messages of the V2X protocol are used in the proposal of an MPT vehicle preference standard. In accordance with the C-ROADS document the following messages are proposed to be used:

• SRM (Signal Request Message) for preference requests from vehicles,
• SSM (Signal Status Message) fro replies from control units/RSU.

SRM is used to send a preference request (or a request update), while SSM is used to reply to this request. Both messages are addressed – they include information for which device they are meant. SRM contains the number of the intersection to which the preference request is sent. On the other hand SSM  contains the number of the vehicle to which the reply is sent.

SRM and SSM messages are defined in the  ETSI TS 103 301 standard that refers to the ISO TS 19091 standard that uses data structures from the SAE J2735 (profile C) norm. The usage of individual containers in a message is further refined in the C-Roads norm “C-ITS Infrastructure Functions and Specifications” and further in the Czech profile C-ROADS CZ PTP 1.52.

RSU has to reply to each request or request update sent from an MPT vehicle via an SRM message by sending an SSM message or an SSM message update. An SSM message can be continuously updated without any request update e.g. based on data from the controller unit (request received, preference assigned).

The C-Roads Document also mentions realizing preference by using CAM messages. This is not suitable as MPT vehicles can send requests to multiple intersections and CAM messages have no given addressee (it is not possible to communicate with a given controller unit). A CAM message (its Public Transport Activation container) can send up to 20 bytes of information about the vehicle state for internal needs of a transportation company (traction, vehicle number, line, course, delay, opening doors, operator, etc.)

The structure of SRM and SSM messages is chosen in such a way that all data data that is transferred to a controller unit can be transferred (respects e.g. even “stationing”). In the case of older controller units, RSU performs “reconstruction” and builds a packet which is then transferred to the controller unit via the RS-232 or RS-485 busbar as during any standard preference. If the controller unit is equipped with ethernet the protocol designed for this busbar is used.

Practical experience with preference

In Brno there more than 80 intersections where MPT preference is realized by using V2X. (81 systems were supplied but some of the intersection are under reconstruction) This was implemented by the Herman company as part of the  RIS II project for DPMB. Practical use has shown very high reliability of this communication – see below – where you can see an example of evaluation of DPMB MPT vehicle preference at the Husova – Pekařská intersection in November 2019. In this case none of the 160 thousand preference instructions got lost (it can happen in exceptional cases). This method also indicates very high permeability of communication meaning that the “preference channel cannot be overloaded”.