What is a stale notification?
Stale notifications are setup to ensure recipients, be it the driver or supervisor, do not receive alerts of violations for a certain specified period after a violation occurred.
This functionality thus allows users to set up thresholds for when a violation is deemed stale and that the notification therefore not be sent to the recipients that have been set up. The default threshold value when setting up an HOS notification to not be sent after the violation occurred is set to 1 hour.
When would you use this functionality?
HOS violation notifications are usually send as they occur or right after they have occurred so that the driver or supervisor can act on the violation immediately or after the configurable escalation level has been met. Sometimes, however a driver goes into an area with poor communication and the onboard computer (OBC) or unit may lose communication with the system. In these cases the system assumes that the driver is still in the last known state. Read more about assumed data here.
The system still records information and will normally still send notifications if violations occurred during the period of lost communication as soon as the unit starts communicating again. To reduce the frustration caused by scenarios where the receiving of driver data is delayed, you can now set up thresholds for stale notifications, meaning notifications that are sent too late to action after a violation occurred.
To decide on a stale notification threshold ask yourself how long after the violation has occurred you would still like to be notified to take action. If a driver was out of communication range for 5 hours for instance, would you still want to be notified and take action?
Take note that these violations will not be removed from the system if you have set up a 5 hour threshold for example. They will still be recorded and available in the reports, you will just not receive a notifications 5 hours after a violation occurred.
Also note that if you have various escalation levels with different thresholds setup for your HOS notifications, the stale notification thresholds will apply to each of these escalation levels.
Set up the stale data configuration
- Click Manage.
- Under Operations, click Database administration.
- Click the '+' to view the organizational hierarchy and go to the relevant organisation.
- Click the organisation name to open the settings.
- Click on the HOS tab on the left.
- Under the Stale date configuration section, check the box to enable the stale data indicator.
- Enter a value for driving hours - this will be the threshold after which a violation will be deemed stale.
- Enter a value for on duty not driving hours - this will be the threshold after which a violation will be deemed stale.
- Calculation settings - choose if you want the available hours to be calculated up to the "current date and time", which is the default and uses the assumed data as true and will sent a notification irrelevant of the stale violation setting. You can also choose "the last communication data and time from the asset" during driving which will not sent a notification after the thresholds have been received as set up above. Choosing this setting will eliminate the scenarios where multiple stale notifications were sent at once as soon as the system received data from the unit to run the HOS calculations. In some cases days could go by without receiving data from the driver and multiple violations might have been recorded. To ensure that only relevant/valuable notifications are sent to users, this option will specify when a notification is stale and if this criteria is met, the notification should not be sent. Read more about the calculation settings here.
See this scenario where a drivers is in an assumed driving state and the configuration was set to "current date and time". A violation is raised based on assumed data driving data and a notification will be sent at escalation level 1.
The default configuration is for notifications to be sent at the "current date and time", which means the system will use the assumed data as correct and sent the notification.
Please note that when the driver’s assumed duty status is driving, the HOS notifications will still be sent based on assumed data.
Additional scenarios - selecting current date and time
If you choose to calculate hours of service from the current date and time where a driver was off duty, even though the system lost communication and the driver was in fact driving, no violation will be raised because it was assumed that the driver was off duty. The violation will only be raised when communication has been restored and the assumed data has been corrected in the system. The violation notification will then be sent pending if it was within the stale notification threshold as set up above.
The following example uses the same scenario where a driver's last duty status was off duty and because the system uses assumed data it will be displayed as such, even though the driver was actually driving. The point where communication is restored will correct the data in the system and the violation will be raised correctly. A violation notification will however not be sent as the communication was restored 30 minutes outside of the stale notification threshold.
Additional scenarios - selecting the last communication data and time from the asset
If you chose "the last communication data and time from the asset" during driving, it means the system will not trigger a violation on assumed data and it will not send a notification based on assumed data as shown in the example below.
If, however you chose the "the last communication data and time from the asset" option and communication has been restored within the state notification threshold period you will receive a HOS violation notification. Say for instance the driver was in an off duty driving status and started driving during a period where communication was lost, the system will assume the driver is in a state of not driving. When communication is restored, the system will automatically immediately update the information and realize that the driver is in an HOS driving violation. The HOS violation notification will be sent because it is not considered stale as per the stale threshold setup. See the diagram below:
In the last scenario, the "the last communication data and time from the asset" option was chosen but comms was restored 30 minutes outside of the stale notification threshold. This means that the violation is only raised when communication has been restored but no violation notification will be sent as per the stale notification setup.
