C-ITS for priority of public transport vehicles

  • Articles and technical information
  • Articles

The article deals with the implementation of priority of public transport using V2X communication technology in cases where a general OBU (On Board Unit) in the vehicle provides priority with general on-board computers for the check-in and information system - the so-called 3rd-party solution.

Introduction

RSU-50N-mV2X is a medium distance communication technology among vehicles and between vehicle and traffic infrastructure. One of its uses is the priority of public transport (PT) vehicles at intersections. In a typical application, it is the On-Board Unit (OBU for short) that controls the actual transmission of preference instructions and processes the responses. The OBU does so based on its own configuration and the vehicle service traffic data obtained from the on-board computer (OBC) of the vehicle information and dispatch system. Thus, the OBU receives the trip information from the on-board computer and transmits back the preference request information.

The communication follows European standards, in particular those defined by the C-ROADS project (coordinated by the European Commission: www.c-roads.eu). The C-ROADS project standards are based on European standards issued by ETSI.


Vehicle Priority System Architecture


Composition of the system

The basic elements of the intersection preference management system for public transport (public transport and VLD) are the units or programmes described below (the numbers of the bullets correspond to the numbers in the figure below):

  1. On-Board Unit (OBU) (UCU 5.0 in our concept, produced and delivered in several versions) - a communication unit located in the public transport vehicle (PTV) that enables communication with the intersection using standardized V2X messages. For preference purposes, it sends preference requests in the form of an SREM message and receives the status of the request processing in the form of an SSEM message. In addition, it receives information about other vehicles, warnings and also the signal plan of the intersection controller.
  2. On-board computer controlling information and possibly check-in system (OBC) on the VD vehicle (in our concept, these are EPIS 4.x or 5.x series on-board computers, which have V2X control integrated) - it provides information to passengers and driver about the vehicle route, compliance with the timetable, communication with the dispatching centre, possibly also enables passenger check-in and communicates with other systems on the vehicle. It also includes a user interface for the driver.
  3. MAP-a-SPATRoadside unit (RSU) (in our concept of RSU 5.0) - a V2X technology communication unit installed at an intersection and communicating with the traffic light controller (usually via Ethernet bus, formerly RS 485 or similar technology). It provides communication for the controller with vehicles in the vicinity of the intersection, not only for the VD or public transport (from special emergency services and with the IZS). According to the description in this document, it mainly receives requests from VD vehicles and transmits back to them the status of "what is happening in the intersection" for their processing (based on information from the intersection controller). In addition, it can, for example, transmit a map of the intersection and the current signal plan.
    The figure shows the display of MAP and SPAT messages at two intersections from two different manufacturers with the transmitted signal plan of the intersection.
  4. Traffic light controller –controls the traffic signal (SSZ) and is supplied by the manufacturer of the controller (in the Czech Republic usually Cross, Yunex (formerly Siemens Mobility) or Swarco Traffic CZ). Based on the internal logic of the intersection signal plan control, the controller decides on the granting of preference and the RSU just transmits these messages from the controller in V2X data format. The RSU communicates with the intersection controller using the controller manufacturer's proprietary protocol.
  5. OBU/RSU Configuration Server (Anbos server in our terms (SW Back Office Server for UCUs)) - the server prepares the configuration data for VD preference management and updates it in the OBU. The data from it now typically updates the data and FW in the OBUs - in this case for VD vehicle preference management. Other functions are e.g. monitoring and evaluating the quality of the preference provided to the VD vehicles (ratio of requests sent and processed, etc.). Within this server, preference points are entered into the system. The Anbos server also provides hybrid communication, where the same C-ITS message is sent via V2X and at the same time via a mobile Internet connection. The server then ensures its delivery to the target area (addressing is to a geographical area, not a specific unit).
  6. Server for configuration/preparation of data for the on-board computer (or for the On-board Information and Check-in System (OIS)) - software supplied by the manufacturer of the PP on-board computer (in our concept EPCOMP or POGEy), in which all data for the PP are prepared, which determine the behaviour of the vehicle on the route.

Based on this scheme, all the preference control logic is concentrated in the OBU in the vehicle and works completely autonomously (no need to have a connection to "some" control server).

The interconnection between the servers is very important, with the OBU Configuration Server (5) reading the schedule data from the On-Board Computer Configuration Server (6).


The communication scheme for independent PP and OBU systems is therefore as follows:

Princip-systemu-preference-220426

Schematic of the communication between the elements of the preference system VD. The preference is controlled by the OBU, which receives the necessary data.

Advantages of the V2X architecture

The advantage of an architecture where the VD vehicle preference is controlled by the OBU in V2X technology is:

  1.  Compliance with ISO 19091, i.e. international standards with support for SREM+SSEM messages.
  2.  Faster response to changes in standards: although the messages are already defined today, the use of parts of them is not yet fully established. What is also not fully determined is the posting logic - when to post a request from the OBU and in what conditions to update it. This is determined by the know-how of the supplier (we have a lot of experience from the implementation of the largest project in Europe with V2X - e.g. the RIS II project, where 750 public transport vehicles or Hradec Kralove vehicles are connected to the system) or the system operator and depends on the local traffic conditions (traffic layout of the intersection).
  3. The input of preference points to the OBU/RSU configuration server (5) is independent of the routes of the line, only the sequence of stops on a given line/connection is relevant. Thus, there is no need for duplicate input in case of a change of the line route. Some form of configuration on the OBU is necessary because there is no protocol today for the on-board computer to communicate the geographical route of the line to the OBU. Therefore, preference requests are configured using a sequence of stops (identifying junctions and entry + exit branches).
  4. Possibility of simple statistics creation on the OBU/RSU Configuration Server (5) - if the OBU and RSU are from the same manufacturer, it is possible to easily validate how the preference works in public transport or e.g. in the Emergency Medical Service (EMS).
  5.  Above-standard control option, if both OBU and RSU are from the same manufacturer, it is possible to provide V2X bidirectional communication services between the vehicle OBU and the intersection controller as standard, and "green preference" of the "controlled stationing" type, where the vehicle receives a premonition of a future green from the intersection controller (as opposed to sending a signal plan, this means that the "green" is already "fixed" in the signal plan).

Each part of the system described herein thus operates in such a way as to avoid duplication of data entry and without the subsequent rather complicated integration of the preference into the vehicle's on-board computer.
Required data from the PP for the preference



Required data from the OBC for the preference

Basic data required from the PP for the correct functioning of the preference



For the correct control of the VD preference, the OBU needs the following data from the on-board computer (see description of the communication protocol between PP and OBU):


  1. Geographical route of the line (but usually not available).
  2. Line number. 
  3. Course number,
  4. Destination number,
  5. Vehicle number,
  6. Car type (tram, trolleybus, bus),
  7. Current delay of the car in relation to the journey,
  8. Last stop travelled, including GPS coordinates,
  9. Nearest transfer stop, including GPS coordinates,
  10. Following stop, including GPS coordinates
  11. Presence of the vehicle at the stop or activation of the door contact.


These data shall be received from the TA by the OBU with minimum delay. It is therefore advisable to send them periodically, e.g. after 10 seconds, or when a parameter is changed. The second option is to send them so frequently that no latency in message transmission occurs, e.g. 1 second (especially for the controlled stationing option). It is also useful to send the entire sequence of stops for a given trip. Then it is enough to indicate which stop the car is possibly at (similar to the IBIS-IP protocol used today in Germany (e.g. Ludwigsburg) and integrated into the UCU 5.0).


Geographical route of the line


Another important information for the VD preference function is the geographical route of the line. It is currently generated by retrieving line/connection information from the data for the on-board computer, where it is then compared with the data entered for each intersection. The OBU thus requests a preference based on the RSU's knowledge of its geographic route and the transmitted map (topology - MAPEM message) of the intersection.


The OBU thus evaluates the vehicle's geographical route based on the following data:

  • Anbos communication server (5) - PP vendor server (6), where the on-board computer data generation server (6) provides the link route for the OBU monitoring and configuration server (5).
  • On-board computer - OBU communication, where the on-board computer provides the OBU with this route during the data run according to the previous subclause. However, no such standardized protocol exists today.



Data from controller (OBU) to OBC


The OBU sends preference instructions based on its own configuration data received from the server (5) and data about the current settings and status of the on-board system (trip) received from the PP using a communication protocol. The OBU may also send information about each preference instruction sent to the on-board computer (according to the requirements for informing the driver about the preference status).
In addition, the RSU shall respond to each preference instruction with an SSEM message indicating the status of the request (processing / preference granted / preference denied). This status may change over time.
It is of course appropriate to deliver the processing status information to the on-board computer as well. Each time the processing status is updated in the controller/RSU, the OBU then sends this status information to the on-board computer.

The OBU will therefore send a message to the on-board computer, if necessary, which includes:


  • Intersection ID
  • Vehicle entry and exit branch (defined in server (5))
  • Request type (check-in / check-out / correction)
  • Request processing status (sent from OBU / received by RSU / processed by controller / preference granted / preference denied).
  • It is also possible to indicate an instruction to leave the stop before the junction (so-called controlled stopping)



The on-board computer can thus display the following to the driver:

  • Information that the unit is sending instructions and that the RSU is receiving them (checking the functionality of the preference) - can be indicated by a simple icon on the PP
  • An instruction to leave the stop before the intersection, if this instruction is supported by the traffic solution in the intersection controller.



Communication protocol OBC-OBU


Connection methods


The communication protocol between the OBU and the in-vehicle PP shall provide the necessary data to the OBU and vice versa, it may provide preference data to the vehicle log. Furthermore, the progress or status of the preferences or OBUs can be displayed to the driver.

The protocol we have prepared can be run in several variants:

  • HTTP client + server, data in JSON or XML format,
  • UDP client + server, data in JSON or XML format,
  • Websocket (OBU as client),
  • German standard according to VDV 301-2 protocol - IBIS-IP. For this protocol, however, no service for communicating the activated preference has been defined so far.