Skip to main content

UC 1: Static and dynamic speed limits

Operation use case​

Speed information (in the vehicle) is provided to road users during journeys. This can be both static and dynamic speed limits, valid for the road segment they are traveling on. The goal is to inform road users at all times during their journey about the applicable speed limits, as determined by regulations and the static or dynamic signage of the road authority (authorities).

We distinguish two types of speed limits which are then explored by subcategory:

  1. Static speed limits

    • Passenger traffic
    • Truck traffic
    • Buses and coaches

  2. Dynamic speed restrictions

    • Dynamic zone 30 areas
    • Dynamic speed restrictions on the main road network (RSS signs)
    • Dynamic speed limits during roadworks[1]

These dynamic speed limits refer to the adjusted speed limit indicated by temporary road signs. If these temporary changes flow into the TN-ITS feed or into the DVM (flemmish: Digitaal VerkeersManagement) Master, they are of course included.

The second subcategory is derived from the TN-ITS feed and (translated into IVI) published on the MI, except data related to truck traffic (1.b.), buses and coaches ( 1.c), as there are currently no conclusive sources to provide these data.

Dynamic lane signalisation views with gantry signs:​

The driver of a passenger car is driving on a freeway with a maximum authorized speed of 120km/h. For whatever reason, the speed limit is lowered to 90 and succeeding to 70 km/h by the roadsigns on the gantries. The application informs the driver of the changed maximum speed and he can adjust his own speed accordingly. The pattern of zones in the IVI messages is always the same: before the first indicating gantry-sign there is an awareness zone, followed by a relevance zone up to the next gantry-sign. If there is a preceeding gantry-sign, an awarenesszone is optional. If there is no follow-up gantry-sign, ending sign or road situation ending the signalized limitation, the relevance zone in the message will end after 750 meters.

In the figure:

  • Driving from right to left: vehicle is warned in zone A4, its limited in speed in zones R4 and R5, ending at the most left gantry. Ending sign is presented to the vehicle.
  • Driving from left to right: vehicle is warned in zone A1, its limited in speed in zones R2, R3 and R4, ending after 750 meters, because there is no follow-up gantry.

Dynamic speed signalisation with active roadsigns:​

The vehicle, approaching the speed limited zone will get an IVI message containing one to eight awareness zones, up the start of the limited zone (reference point), and one to eight relevance trace(s) for the length and route of the limited zone.

Data sources​

Static speed limits​

The static speed limits are retrievable via a Static Data API that is part of the MI. This solution was chosen to reduce data redundancy and thus not unnecessarily burden the system.

TypeSubtypeIn-scopeInterfaceProtocolSource
StaticPassenger trafficYesMI Static Data APITN-ITSAWV
StaticTruck trafficNo---
StaticBuses and coachesNo---

Static speed limits are retrieved from the source derived speed regimes (TN-ITS feed). If TN-ITS proves insufficient in quality during acceptance, a fallback to OSM is made. This is delivered in a map format with all roads and speed limits attached.

For the roads for which no data is available, no speed limit is shown.

Dynamic speed limits​

The dynamic speed limits are published on the MI in the form of IVI messages in accordance with C-Roads specification. The source also includes all lane signals and zone 30 areas.

TypeSubtypeIn-scopeInterfaceProtocolSource
DynamicDynamic zone 30 areasYesMI - AMQPIVIAWV
DynamicDynamic speed restrictions on the main road network (RSS signs)YesMI - AMQPIVIAWV
DynamicDynamic speed limits during roadworksNo---

We assume that the different dynamic sources do not overlap.

Each status of the matrix sign per lane is transmitted independent of whether it is a speed limit or not (e.g., an " arrow").

Minimal requirements​

The static data source should have 95% coverage on the publicly accessible road network, with validated speeds on the main road network.

The static data source shall verify, process and have published reports of erroneous information within 7 calendar days if changed.

The dynamic data source should be 98% correct, with a maximum latency of 5 seconds.

Data processing (PIP)​

Static speed limits​

The PIP aggregates, on daily basis, the TN-ITS feed into one fully up-to-date map that is always available and places it on the Static Data API. We keep the relevant identifiers from TN-ITS to match the appropriate entities to a RUF notification.

Dynamic speed limits​

Dynamic zone 30 areas​

The dynamic zone 30 data that will be available in the TN-ITS feed will be transformed by the PIP into dynamic speed information, which will be published in real time on the MI as IVI messages. In this way, the dynamic and temporary nature of zone 30 areas will be included in the ecosystem.

The locations of this zone-30 data will be found in the TN-ITS feed. The PIP interprets the switching regime the PIP and will generate the appropriate IVI messages accordingly.

Dynamic speed restrictions on the main road network (RSS signs)​

The PIP uses the RSS info from the DVM master feed to generate an IVI message per portal indicating the current status of all signaling devices on this portal. The IVI will contain per RSS sign an individual generalcontainer in which the icon code of the current status is given. Each individual signaler also has its own relevance and detection zone. In this way there is a uniform way of processing along service provider side and signs are separated from each other. This is advantageous for complex situations (e.g. around Antwerp) where some of the signaling devices will have a different relevance zone due to the split of the highway from the other signaling devices, as well as making the given information easier to interpret technically: each signaling device has its own detection and relevance zone. Here, the detection zone will be equal to the distance between the previous gantry and the current gantry. For the first gantry, the detection zone will be limited to 500 meters ahead on the same road on which the gantry is located.

The PIP will observe the positions of the RSS signs to calculate the relevance zones of the IVIs. Each lane under a gantry will result in a general container entry.

Dynamic speed limits during roadworks​

The PIP uses the roadworks with adjusted speeds from the VVC feed and publishes them as DENM messages on the MI.

RUF and sourcing​

The dataflow also indicates that road users can provide feedback on the displayed speed limits via the service providers (Flitsmeister, Truckmeister, 3PSPs, etc.). This feedback reaches the PIP through the feedback channel and is pushed (with HTTP POST) to an API hosted by AWV. The intention is for the client to validate the feedback and consequently modify the source data. These changes will flow through TN-ITS to the PIP, which can then publish the latest version of the TN-ITS on the MI. The PIP itself will not apply any changes based on the RUF.

Dynamic speed limits​

We expect the matrix signs and dynamic zone 30 signs to show 1-to-1 what the source indicates. So, in other words, it is not desirable to incorporate feedback from dynamic speed limits on RSS signs.

Static speed limits​

One cannot speak of road user feedback here, but of sourcing. The user can specify what the correct maximum speed should be. The PIP forwards the feedback (via a separate API) and does not validate it. AWV is the authority that will distribute the feedback and further validate for its own road network.

The service provider is not aware of what source the speed limitation came from. The PIP does know this information.

  • TN-ITS: TN-ITS feed is updated regularly and the changes will come through to the source. The PIP will not override itself.
  • OSM: OSM is used in the case of an erratic TN-ITS content block.

MI & Historical archive​

One can distinguish here between static speed constraints and dynamic speed constraints:

Static speed limits (TN-ITS feed) are available on the static Data API. We offer these unchanged. Sourcing of static speed limits from the service provider also runs over the static Data API.

Dynamic velocity constraints run over the interchange. Dynamic velocity constraints arrive in IVI format from activation and are sent out as long as they are active.

MI Headers​

Zone 30

{
  "messageType": "IVIM",
  "originatingCountry": "BE",
  "protocolVersion": "IVIM:1.2.1",
  "publisherId": "BE00004",
  "publicationId": "BE00004:IVIM_ACC_DYNAMIC_ZONE_30_01",
  "publisherType": "PIP",
  "custom-mobilidata-dtapEnvironment": "acceptance",
  "custom-mobilidata-useCase": [1],
  "custom-mobilidata-dynamicSignType": "Zone30",
  "quadTree": [
  ]
}

Service provider implementation​

Static speed limits​

ServiceProvider takes the information from the static Data API and will match locations to coordinates and display the then current allowed speed limit.

ServiceProvider will also check via 'HTTP head calls' whether the speed limits have changed. If yes, the new 'set' of static speeds will be retrieved and put live in ServiceProvider.

Reporting a different speed via sourcing the SP will create a notification with the ID on which the rest API is matched (if available), if no match should also be passed that no data is available (add boolean in data model 'no static sourcing data?' or source ID = empty).

The ServiceProvider will simultaneously read out the MI and as soon as an IVI comes in with a different max speed, this max speed at those coordinates will be leading.

The minimum of both speeds is always used.

It is intended that service providers use the static speed information in the TN-ITS feed as the default speed limit. If IVI messages are published on the MI with a different maximum speed than the static maximum speed, the dynamic one should be used. The most recently known TN-ITS set will always be available on the MI for parties connected to the MI.

Message Example​

UC 1 Message Example
{
  "iviType": ",regulatoryMessages,",
  "shardId": "1",
  "quadTree": ",120202122113201330,1202021221132,",
  "shardCount": "1",
  "messageType": "IVIM",
  "publisherId": "BE00004",
  "iviContainer": ",giv,glc,",
  "publicationId": "BE00004:IVIM_DYNAMIC_ZONE_30_02",
  "baselineVersion": "2.1.0",
  "protocolVersion": "IVIM:1.2.1",
  "originatingCountry": "BE",
  "pictogramCategoryCode": ",557,",
  "custom-mobilidata-useCase": ",1,",
  "custom-mobilidata-timestamp": "1741591959730",
  "custom-mobilidata-publisherType": "PIP",
  "custom-mobilidata-baselineVersion": "1.0.0",
  "custom-mobilidata-dtapEnvironment": "production",
  "custom-mobilidata-dynamicSignType": "Zone30"
}
Tags:
Last updated on by Maarten Taeymans