Implementation of PT preference using V2X

  • News

The article is about implementing urban and regional public transportation (hereinafter public transportation) preference using communication technology V2X when this preference is provided by a general unit OBU (On Board Unit) in a vehicle and a general on-board computer for checking and information systems (PP OLS) – 3rd party solution

Our new V2X unit for intersections – type RSU 5.0 – providing communication with a tram.

Introductin

One of the uses of the V2X mid-range vehicle-vehicle and vehicle-infrastructure communication technology is providing preference to public transportation vehicles (PT) at intersections. A typical use case utilizes a vehicle on-board unit OBU (short for On-Board Unit) which manages the sending of preference commands and processes replies. The OBU unit uses its configuration and traffic data provided by an on-board computer (OC) of the information and checking vehicle system. The OBU unit receives driving information from the on-board computer and returns information about preference requests.The communication is based on European standards, mainly those set by the C-ROADS projects (coordinated by the European Commission: www.c-roads.eu). The basis of the C-ROADS projects standards consists of European norms issued by the ETSI institute.

PT vehicle preference system architecture

System composition

The below described units and programs are the basic elements of the system of public transportation (UPT and RPT) preference at intersections (the bullet point numbers correspond with the numbers in the below picture):

  1. Vehicle unit OBU (in our concept, UCU 5.0 produced and supplied in many versions) – a communication unit placed in a PT vehicle which provides communication with intersections via normalized V2X messages. It sends preference requests in the form of SREM messages and receives request processing status in the form of SSEM messages. It also receives information about other vehicles, warnings, intersection control unit signal plans.
  2. On-board computer managing the information system and possibly also the checking system (OC) in a PT vehicle (in our concept, on-board computers EPIS 4.x or 5.x, with integrated V2X control) – informs the driver and passengers about the vehicle route and adherence to the schedule, communicates with dispatching, can provide passenger checking (mainly RPT) and communicates with other systems in the vehicle. It also provides a user interface used by the driver.Displaying of MAP and SPAT messages at two intersections by two different manufacturers with a broadcasted intersection signal plan.

  3. Displaying of MAP and SPAT messages at two intersections by two different manufactures with a broadcasted intersection signal plan.

    Unit RSU (Road-side unit) (in our conception, RSU 5.0) – V2X communication unit installed at intersections which communicates with an intersection controller unit (usually via ethernet; before that RS 485 or a similar technology). Facilitates communication between the controller unit and vehicles in the vicinity, not only RPT and UPT vehicles (also with ES). It receives requests from PT vehicles and sends back the status of „intersection events“ and of request processing (based on the information from the intersection controller). It can also broadcast a map of the intersection and the current signal plan.

  4. Intersection controller unit – controls the traffic light and is supplied by the manufacturer of this controller (in CZ usually Cross, Yunex (formerly Siemens Mobility), and Swarco Traffic CZ). The controller uses its signal plan control logic to decide about granting preference and the RSU unit forwards these messages in V2X format. Communication between the RSU and the controller runs via a proprietary protocol from the controller manufacturer.
  5. OBU/RSU configuration server (in our conception, server UCU-BOS (SW Back Office Server for units UCU) – this server prepares PT preference control configuration data and updates this data in OBU units. Typically, data from this server updates FW and data in OBU units – In this case, for the purpose of controlling PT vehicle preference. Other functions include e.g. monitoring and assessing the quality of preference granted to PT vehicles (the ratio of sent and processed requests, etc.). This server is used to enter preference points into the system.
  6. Server for configuration/preparation of data for on-board computers OC (more precisely for the vehicle information and checking system (ICS)) – SW supplied by the manufacturer of the on-board computer OC (in our conception, EPCOMP or POGEy), which is used to prepare all data for the OC, this data determines the behavior of the vehicle on its route.

In this schema, all the preference control logic is concentrated in the OBU unit in the vehicle and it functions completely independently (no connection to „some“ control server is necessary).

Connection between servers is very important as the OBU unit configuration server (5) reads schedule data from the On-board computer configuration server (6).

Communication diagram for independent OC and OBU systems:

Diagram of communication among individual elements of the PT preference system. Preference is controlled by the OBU unit that acquires the needed data from the on-board computer and its own configuration. Part of the configuration can come from server (5) – server (6) communication.

Advantages of the V2X technology architecture

Advantages of the architecture where PT vehicle preference is controlled by an OBU unit using V2X technology:

  1. Adherence to ISO 19091, i.e. international standards.
  2. Faster reactions to changes of standards: although messages are defined today, usage of their parts is not yet fully set. Broadcasting logic is not fully set either – when to send a request form OBU and in what conditions to update the request. This is thanks to the know how of the supplier (we have a lot of experience from the implementation of the largest V2X project in Europe - project RIS II, where 750 UPT vehicles are connected to the system) or the system owner, and it depends on the local traffic conditions (traffic solution of the intersection).
  3. Preference point entry into the OBU/RSU configuration server (5) is independent of the line routes, only the sequence of the stops on the given line matters. There is no need for duplicate entry when the line route changes.
  4. Simple statistic creation on the OBU/RSU configuration server (5) – if both OBU and RSU are from the same manufacturer, it is easy to validate preference functionality in UPT or in e.g. EMS (emergency medical services).
  5. Possibility of above-standard control, if both OBU and RSU are supplied by the same manufacturer, the standard mode can provide bilateral V2X communication between the OBU unit and the intersection controller, and „controlled stationing“ a type of “ecological preference”, when a vehicle receives messages about future green lights from an intersection controller (unlike in signal plan broadcasting, this means that green light is fully „fixed“ in the signal plan).

Each part of this system works in such a way that data entry duplicates and consequent complications during integration into a vehicle on-board computer are prevented.

Data from OC required for preference

Basic information from OC required for correct preference functioning

The OBU unit needs the following data from the on-board computer (see the description of the PP – OBU communication protocol) to control PT vehicle preference correctly:

  1. Line number,
  2. Connection number,
  3. Course number,
  4. Target number,
  5. Vehicle number,
  6. Vehicle type (tram, trolleybus, bus),
  7. Current delay in relation to the given drive,
  8. Last passed stop, including GPS coordinates,
  9. The closest stop on the route, including GPS coordinates,
  10. Next stop on the route, including GPS coordinates,
  11. Presence of the vehicle at a stop or activation of the door.

The OBU unit must get this data with minimum delay. It is recommended to send the data periodically e.g. every 10 seconds, or whenever any of the parameters changes. Another possibility is sending the data often enough to prevent latency during message handover, e.g. every 1 second (especially when controlled stationing is used). Sending the whole sequence of stops for the given drive is also useful, then you can just indicated at what stop the vehicle is located (similar to the IBIS-IP protocol used today in Germany (e.g. Ludwigsburg) and integrated in UCU 5.0 units).

Geographical line route

Geographical line route is another important information in PT preference. Currently, it is created from information about lines/connections obtained from the data for on-board computers where it is compared to the data about individual intersections. OBU units request preference based on their knowledge of the geographical route and as the case may be a map (topology) broadcasted by RSU.

OBU evaluates the geographical route on the basis of the following data:

  • Communication between the server UCU-BOS (5) and the server from the OC supplier (6), when the on-board computer data creation server (6) provides the line route to the OBU unit control and configuration server (5).
  • Communication between the on-board computer and OBU, when the on-board computer provides the OBU unitwith this route data during the drive as per the preceding sub-chapter.

Data from the controller (OBU) for OC

The vehicle unit OBU sends preference commands based on its own configuration data received from the server (5) and the data about the current setting and status of the on-board system received from OC via the communication protocol. OBU can send information about each sent preference command to the on-board computer (as per requirements to inform the driver about the preference status).The RSU unit replies to each preference command via an SSEM message, which states the status of request processing (processing / preference granted / preference refused). This status can change over time.The information about the processing status should also be delivered to the on-board computer too. Each processing status update from the controller/RSU unit is sent to the on-board computer by OBU.If needed, OBU sends a message to the on-board computer that contains:

  1. Intersection ID
  2. Vehicle entry and exit branch (defined by the server (5))
  3. Request type (login / log off / correction)
  4. Request processing state (sent by OBU / received by RSU / processed by the controller / preference granted / preference refused).
  5. It is also possible to indicate a command to leave the stop in front of an intersection (controlled stationing)

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

  • Information that the unit sends commands and that RSU receives them (preference function check) – can be signalized by a simple icon on OC.
  • Command to leave the stop in front of an intersection, if this command is supported by the intersection controller.

Communication protocol PP-OBU

Connection types

The communication protocol between OBU and OC in a vehicle must provide OBU with the needed data and can save preference data in the vehicle log. Preference and OBU unit status can be displayed to the driver.The protocol we have prepared can be started in various versions:

  • HTTP client + server, data in JSON or XML,
  • UDP client + server, data in JSON or XML,
  • Websocket (OBU as a client),
  • drawing from the API interface of OC
  • German standard based on the protocol VDV 301-2 – IBIS-IP. A service for notifying about an activated preference is not yet defined in this protocol.

An example of a proposal of a proprietary protocol for a V2X communication unit – type UCU 5.0x – designed for communication with OC manufacturers other than the Herman company (3rd party board computer) follows:

General properties of the protocol

OBU (UCU 5.0) supports the following interfaces for IP communication:

  • Ethernet
  • LTE
  • Wi-Fi (client or AP)

Typically, Ethernet is presumed for connection in a vehicle.

Communication services

Two basic services are designed for communication between OC and OBU:

  • Service that provides data from OC to OBU during a drive (service 3250 – ucu3rdPartyBoardComputerData)
  • Service informing PP about the status of OBU (service 3251 – PublicTransportPriorityStatus)