Skip to main content

UC 21: Truck parking information

Operation use case​

What

To make available both static and dynamic real-time highway parking information for truck drivers (+3.5 tons) along highways.

Purpose

Use this info to avoid overcrowded parking lots, by planning routes smarter taking into account legal driving and rest periods. Increase traffic safety through fewer trucks on the breakdown lane and lay-bys.

Actors:

Highway authority or highway parking operator provides info on number of free parking spaces and services offered.

Service provider relays information about truck parking service to truck drivers.

Truck driver receives information about truck parking and makes informed decision.

Service provider collects information from road users (RUF).

Flow

  1. Service provider receives the information through the MI.
  2. The information flows through the service provider to an appropriate HMI used by the truck driver.
  3. The driver uses this information to plan his trip.
  4. The service provider also collects RUF itself and sends this information to the PIP.

Vehicle viewpoint

The service provider shares available information of the parking facility to road users looking for a suitable parking space before or during the trip.

Viewpoint other road users

The service provider collects real-time information from other road users (RUF) who are in truck parking.

Data sources​

Following static data sources are taken in:

RUF

  • Occupancy Rate: RUF is used to estimate the real-time occupancy rate in the form of a qualitative indicator (quiet, crowded full). The representation of exact occupancy is not possible in the absence of a quantitative data source.
  • Free text: general user feedback on the available static parking information.

Minimum requirements. The most important requirement is the completeness of the data source so that every parking lot is included and fully described in it. In addition, it is important to have a regular update process (at least every month) where the feed is updated. Although the RUF can be the source of error messages to a significant extent, it is highly desirable that an autonomous "refresh cycle" also happens.

Data processing (PIP)​

  1. Collect and make available static parking information. The PIP combines the static information from the two open data sources and publishes the parking information on the Static Data API, in DATEX-II v3 format.

  2. Collect, process and make available RUF dynamic occupancy rates Service providers collect RUF from their users to get a qualitative indication of crowding in each parking lot. Users can enter three classes of busy: quiet, busy, full. Service providers forward each individual RUF message via MI to the PIP (in DATEX-II v3 format). The PIP processes all qualitative parking occupancy information and publishes the occupancy rate for each parking lot on the MI (in DATEX-II v3 format). The RUF message (DATEX II v3) contains the following info:

    • ID of the parking lot
    • Crowding Indicator (RUF): "quiet", "busy", "full"
    • timestamp on which the RUF was given

    The PIP does a technical validation of the received RUF messages before processing them: does format conform, are there missing values, are the values within possible ranges, is the information sufficiently current (TTL).

    The PIP will determine a qualitative occupancy rate for each parking lot based on all individual RUF messages from different service providers. The PIP will only publish information if enough recent RUF messages are received and if there is sufficient agreement in the RUF messages. If too many conflicting messages are obtained in a short period of time, no information will be published.

    The PIP applies the following rules:

    • only RUF messages less than 1h old are considered
    • With each new RUF message, the most frequent occupancy status is sent out, IF the number of RUF messages with the most frequent status >= number of RUF messages with other statuses +5
      • If the condition is not met, the PIP will not send out an updated status
    • Time to live (TTL) of an outgoing occupancy on the MI is 2h, calculated from the last RUF message received. As the number of incoming RUF messages increases, the time to live may be reduced.
      • At night, fewer messages are likely to be received because most drivers are already parked. To prevent occupancy information from being lost at night (due to TTL expiration), all occupancies whose TTL expires between 10pm and 5am are kept active until 5am.

  3. Making free text RUF available on AWV feedback API. The service provider forwards the free text and associated parking id to the PIP via the feedback channel on the Static Data API, in custom JSON format. The PIP then makes the individual RUF messages available for 3 days on the AWV feedback API, hosted by Be-Mobile.

    The free text RUF message (custom JSON) contains the following info:

    • ID of the parking
    • Parking name
    • User confidence level
    • Free text feedback
    • timestamp on which RUF was given

RUF and sourcing​

Occupancy A data source with real-time occupancy information on parking lots (number of free parking spaces) is not available. Alternatively, service providers collect qualitative occupancy information through RUF. Upon arrival at a parking lot, truckers will be asked about parking lot occupancy via a pop-up. Users can enter three classes of busy: quiet, busy, full.

Feedback regarding occupancy is requested when a user arrives at a parking lot. Also when an end user starts the app in a parking lot, when the user leaves again, the feedback is requested. When a user drives past a parking lot (i.e. is not in the parking lot), this question is not asked.

Free text At any time, the user can click on a parking lot in the map view and provide general feedback on the available static data via a free text field. Via the free text RUF, the correctness of the static parking data can be found out. This information is transferred one-to-one to the AWV feedback API and is made available there to the publishing authority with a 3-day retention. The publishing authority is expected to evaluate the feedback and adjust the data source if necessary.

MI & Historical archive​

The following data streams run over the Static Data API:

  • Static parking info from each parking lot
  • RUF free text

Following data streams run over the MI:

  • Dynamic info about occupancy of each parking lot (quiet, busy, full) based on RUF
  • RUF dynamic occupancy

The following data streams are archived after conversion:

  • Static parking info of each parking lot
  • Dynamic info on occupancy of each parking lot (quiet, busy, full) based on RUF.
  • This dataset can be used in the future to calculate typical occupancy rates. For now: out-of-scope.

MI header​

{
  "messageType": "DATEX2",
  "originatingCountry": "BE",
  "protocolVersion": "DATEX2:3.4",
  "publisherId": "BE00004",
  "publicationId": "BE00004:DATEX2_ACC_PARKING_OCCUPANCY_01",
  "custom-mobilidata-publisherType": "PIP",
  "baselineVersion": "1_0",
  "custom-mobilidata-dtapEnvironment": "acceptance",
  "custom-mobilidata-publisherName": "AWV",
  "custom-mobilidata-publicationType": "ParkingStatusPublication",
  "custom-mobilidata-useCase": [21, 22],
  "quadTree": [
  ]
}

Service provider implementation​

The service provider displays the static & dynamic parking information to the end user through the map view.

  • The user can preview all truck parking through the map view. By selecting a truck parking, the user can view all available static and dynamic real-time info.
    • Optionally, a service provider can provide a filter by pressure level: "Show only truck parking lots with available parking."
  • The user can navigate to a truck parking as a stopover or a final destination.
    • When navigation is active, a user can add a parking lot as an intermediate stop
  • The truck parking lots on/along the route are displayed on the map while driving.

The service provider collects real-time occupancy information - quiet, busy, full - via RUF and transfers this information to the PIP (where a qualitative indicator of the level of crowding in the parking lot is calculated).

The service provider collects general information about the facilities available in the parking lot via free text RUF and transfers this information to the PIP (which makes the feedback available on the AWV feedback API).

Tags:
Last updated on by Wiggertsm