Road User Feedback (RUF)

Context

Every connected end-user is a potentially valuable data source: he/she can, faster than almost any other source, report that a certain problem occurs or is (no longer) active. The reports and evaluations from end users are called Road User Feedback (RUF). It is important to know that 2 different processes apply here:

1. An end user notices something on the road (e.g. stationary vehicle) and reports it
2. An end user receives a notification for an event (e.g. stationary vehicle) and evaluates this notification (e.g. is the stationary vehicle still there? yes or no)

In the Mobilidata architecture, these reports come through the service providers to the Mobilidata Interchange. A service provider can choose to forward each individual RUF message or to first evaluate the individual RUF messages and aggregate them into a more reliable RUF message.

The RUF information flows from the Mobilidata Interchange to the PIP which:

• creates new events based on RUF notifications
• updates existing events (keeps them active for longer) based on positive RUF evaluations
• opts out of existing events based on negative RUF evaluations

RUF Data Source: Service Providers

Service providers collect RUF from their users and put the RUF messages (DENM) on the feedback channel of the MI.

The RUF registrations of new events include the following information in the DENM:

• location
• Event Type
• Timestamp
• informationQuality

info

The RUF feedback DENMs are a replay of the original event with custom stationId (userId) in the header and informationQuality

RUF informationQuality

info

Not every user who gives RUF is equally reliable. Via the informationQuality field in the RUF DENM, the service provider can give an indication of the reliability of the user who gives the RUF notification. The PIP will take this reliability into account when evaluating all RUF reports.

C-Roads

C-Roads specifies informationQuality as follows:

"informationQuality expresses the likelihood of occurrence of an event and not the quality of the location information of the event, which is expressed by eventPosition and positionConfidence."

The informationQuality scores are described as follows:

Certain (6)

• The source is completely certain of the occurrence of the situation or event.
• Guidance on the source of information: Recent human verification of a detected event by a qualified person who belongs to the same organisation as the source or originator of the ITS message (e.g. road operator or operator of ITS stations). Human verification can be provided by a qualified person who is on-site or observes the event via CCTV.

Probable (4)

• The source has a reasonably high level of confidence of the occurrence of the situation or event.
• Guidance on the source of information: Automatic detection under conditions or within an environment, where detections are predictable.

Risk of (2)

• The source has a moderate level of confidence of the occurrence of the situation or event.
• Guidance on the source of information: Automatic detection under conditions where the results are not very reliable. Or reports from experienced or trustworthy third-party organisations.

Mobilidata

Within mobilidata, the interpretation of the informationQuality field is interpreted as follows:

• informationQuality Certain (6): RUF messages from professional information providers such as AWV, road inspectors, police, roadside assistance
• informationQuality Probable (4): RUF messages that have been generated in an automated manner, for example via SRTI data (whether or not already aggregated) or after aggregation of individual RUF by a service provider.
• informationQuality Risk or (2): individual RUF messages that have not been validated or aggregated in any way.

To allow for more granularity in the reliability of individual RUFs, the PIP will also support informationQuality 1 and 3.

The following interpretation of the RUF informationQuality field by the service providers is proposed:

• informationQuality 1: individual RUF of untrusted user
• informationQuality 2: Individual RUF of default user
• informationQuality 3: Individual RUF from reliable user
• informationQuality 4: aggregated RUF that arises after evaluation of multiple individual RUF reports by the service provider.

PIP

The PIP reads the RUF messages from the Mobilidata Interchange and groups all source events and RUF events as described in Merge & Decide.

The stationId (in the AMQP header) is used to check whether the messages do not originate from the same user. If a user sends out the same RUF several times within 1 hour and within a radius of 100m, the following identical messages will be ignored.

Next, the informationQuality field from DENMs is used to determine when there are 'enough' messages to log in or out of an event.

Registration for a new event

If there are enough RUF reports, the PIP creates a new event and the event is published on the MI. The PIP assigns a score to each RUF report, based on the informationQuality, and adds up all scores. When the threshold for registration is reached, the PIP will create the new event.

The TTL of the new event will be carried over from the event in the group with TTL furthest in the future. The TTL of each RUF message is determined per use case and is calculated from the timestamp on which the RUF message was created.

If this new event coincides with a previously cancelled event, the previously given negative feedback will expire and the original events will also become active again. For example: GIPOD reports roadworks, but they have not yet started > event is cancelled via RUF > roadworks start a little later > roadworks are registered via RUF > original GIPOD event comes back live.

Updating an existing event

In case of positive feedback (or a new RUF registration while an event already exists) the RUF message will be added to the existing group of events (according to Merge & decide logic). This has a potential impact on the TTL as it is carried over from the event in the group with TTL furthest in the future.

If there is also a source event in the group, there is a real chance that the source event has received a longer TTL from the source. In that case, there is no impact on (the TTL of) the event that has been broadcast.

The score (based on informationQuality) is not relevant in this case as the registration threshold has already been reached to make the event live. Unless there has already been negative feedback: see below.

Unsubscribe from an existing event

In case of negative feedback, the negative RUF message will be added to the existing group of events (according to Merge & decide logic). The PIP assigns a score to each negative RUF feedback report, based on the informationQuality, and adds up all scores. When the threshold for unsubscribe is reached, the PIP will cancel the new event.

warning

If negative feedback (without an event being unsubscribed) is followed by another positive feedback (or a new RUF registration), the score for unsubscribe will be corrected with the score linked to the informationQuality of the positive RUF message. The accumulated score can never go below 0.

RUF scores and thresholds

The PIP will assign the following scores to each RUF message, depending on the informationQuality.

Type RUF	InformationQuality	Score
Individual RUF of unreliable user	1	1
Individual RUF of standard user	2	2
Individual RUF from reliable user	3	3
Aggregated RUF by service provider	4	6

The scores of the RUF messages are added (or subtracted) until a threshold is reached, see logic above. The thresholds can be set per road type. A distinction is made between higher road network (OSM road class 1, 2, 3) and underlying road network (other roads).

Threshold	Registration event	Cancellation event
Higher road network	6	6
Underlying road network	3	3

Slightly fewer RUF reports are expected on the underlying road network, hence the threshold is set lower.

Historical archive

Aggregated RUF events are archived.

Individual RUF events are not archived.

Service Provider Implementation

The Service Provider must protect the chain against potentially harmful behavior. This involves:

• A RUF notification may only come from an end user within an end user application.
• An RUF report may only be confirmed or deregistered if it has been presented to the end user and the end user could reasonably have become aware of it.
• Repeated identical reports from the same user within a short distance (radius 100m) and within a short period of time (1 hour) must be blocked.
• The Service Provider must have a way to block individual users or instances of the end-user application in the event of misuse.
• The 'informationQuality' field must be filled in truthfully.