According to the International Transport Forum, in 2014 there were over one million traffic related fatalities. “Inappropriate behaviour of road users, such as excessive and inappropriate speed, remain important contributory factors in fatal crashes and for injuries.” Reducing dangerous driving plays a critical role in increasing road safety. The Geotab GO6 and GO7 vehicle tracking devices have three main types of data that can be used for determination of dangerous driving:
Acquired using an accelerometer in three directions: forward/backward, up/down, left/right.
Vehicle Road Speed
Acquired from up to two sources:
- Data from GPS modules
- Data from the vehicle’s diagnostic data bus (if available)
Vehicle Engine Speed (Acquired from a vehicle’s diagnostic data bus,if available)
Using this data it is possible to determine if a vehicle is:
- Speeding (in combination with map data)
- Braking harshly
- Accelerating harshly
- Cornering harshly
- Over-revving (which can result in harsh acceleration events)
Thresholds for the accelerometer and RPM values need to be selected carefully. If the threshold is too low, many safe events will be identified as dangerous. If the threshold is too high, the available data will not be used to its full potential and true dangerous driving events will not be detected. In addition to that, the expected “safe” accelerations will differ based on the vehicle. Geotab has carefully selected threshold values for different vehicle weight classes. The default threshold values can be modified through the MyGeotab interface.
Sources of Error
As is the case with most sensors, the data acquired is not always perfect.
If a device is hit or kicked it will record high acceleration values. In the case that a device is not installed securely, the accelerometer may never properly calibrate. Such installs can result in the loss of accelerometer data for the purposes of harsh driving detection. Accelerometer data will still be logged in the case of accident level events. This is one of many reasons why proper secure installs are crucial to GO device operation. In many cases, the GO devices are able to detect improper installs and will log faults, which are visible in MyGeotab.
Some geographical areas, such as mountains or urban areas with large buildings, can cause a reflection of GPS signal. This is known as the “multipath effect”. In some cases this can result in augmented location and speed data provided by the GPS unit.
Diagnostic Data Based Road Speed
Legacy communication protocols such as J1708 are notorious for providing erroneous data due to weak checksum validation. The GO device will begin to ignore diagnostic data based road speed and rely solely on GPS if it detects that the vehicle based road speed cannot be trusted. The good news is that such protocols are being replaced in modern vehicles by CAN based ones, which are much more robust in terms of data integrity. The GO device will use engine data from a CAN based protocol if it is available on both a legacy protocol and a CAN based one simultaneously.
Engine Speed Data
A vehicle going uphill will require higher engine speed to maintain a constant road speed. Sharp increases in incline often appear as over-revving events, however, in these cases the high engine speed is necessary and should not be considered as dangerous. Due to the fact that engine speed is also acquired from the vehicle’s diagnostic data bus, it suffers the same limitations as road speed in terms of data validity.
Managing Sources of Error
Even with all the potential sources of error, over a period of time dangerous driving behaviour can be identified with high accuracy. This is due to the fact that a large portion of dangerous drivers, on average, have more speeding, harsh braking, harsh cornering, harsh acceleration, and over-revving events. This data is easily viewed on a risk management report in MyGeotab.
Note: The Risk Management report hows how many rules were broken and also the total distance driven for the time frame chosen. This metric is also very important – when you take a view across the entire organisation, you can see how many rules were broken over a standard amount of kilometres. For instance, how many rules were broken per 100 kilometres driven? This places all drivers on a more even playing field, and allows organisations to enforce fair practices. To provide a more specific example, consider this: A driver that breaks 10 rules and drives 500 kilometres is very different than the driver that breaks 10 rules and drives 50 kilometres.
Note: The Exceptions report shows the location of where each rule was broken. This data is oftentimes the most important for organisations, since it encompasses all of the weak spots and can easily be communicated to management when broken. It optimises the saying ‘no news is good news’ – meaning that management only needs to be notified if a rule has actually been broken.
Specific events can also be analysed and confirmed on a case-by-case basis. For example, if a vehicle reported high forward acceleration, increased RPM and an increasing road speed during a speeding event, it is virtually impossible that the speeding event was incorrect.
Improving Dangerous Driving Detection
Installing a Mobileye system into a vehicle and interfacing it with a GO device can provide additional information, which can be used in order to detect dangerous driving behaviour. The Mobileye system uses a front-facing camera to detect events where:
- the vehicle is following the vehicle ahead too closely
- the vehicle comes close to a collision with a pedestrian or a vehicle ahead
- the vehicle does not use a turn signal when changing lanes
These events are logged by the GO device and are then available on MyGeotab. This data can be added to a risk management report, to provide a better picture of one’s driving habits.
Fleet and driver safety are incredibly important here at Geotab. To learn more about how Geotab can assist with dangerous driving detection, ask away in the comments box below, you can also download GEOTAB Whitepaper on Telematics in Safety here
Credits: Alex Sukhov, Junior Embedded Systems Developer