There has been stiff competition in the fleet management world where having an edge in the market could mean acquiring significant market proportions. The best way to get an edge is by making quick decisions based on real-time data. Many fleet owners have been converting their fleets into smart fleet networks that continuously pump diagnostic and road data to get better statistics on their fleet and better maintain fleet efficiency.
The data that’s needed to be acquired is heavily based on the questions that you need answering. For example, fleet owners want to avoid as much downtown as possible in their fleets, and how does one go about doing that. One way would be to maintain the individual vehicles within the fleet on time, or when they show wear, and to avoid any sudden breakdowns. Gathering data on things such as tread length, service lights, mileage, and road quality would help you figure out when parts are starting to show real wear. From this information, a program can set alarms when the vehicle needs to be serviced to avoid future failures.
There is a lot of useful information that needs to be tracked from your fleet. For example:
- Overall vehicle health information which is some of the things I have listed above and more (tread length, service lights, fluid capacity, fluid temperature, etc.)
- Mileage and HoS (hours of service) on individual drivers for computing work hours
- Road health, weather information, and traffic information for computing alternative routes
- Gas prices and mpg to accurately schedule gas stops to routes
Controlling all this data can help increase fleet efficiency, which in turn drives down costs and can help fleet owners price out the competition. Data becomes a powerful tool, and it serves well to get the information that matters most to the manufacturer as quickly as possible.
Gathering the data
All of this data needs to be gathered, and that can be a task on its own. Cars have now been their own moving IoT devices, sending up to 25 gigabytes of data to their respective clouds per hour
Automotive companies have been good at integrating new sensors that measure all sorts of things in the vehicle, and these sensors are only one part of the vast mesh network within the car. All of this data can be gathered with other sensor data to give an overall status of the health of the vehicle. Which in turn, an average life expectancy can be created for a particular vehicle model, or even for specific parts within the vehicle.
Besides the maintenance of the fleet, data can also be used to better decide which vehicle should be the one driving to the destination. Software systems can consider more information, such as:
- Which vehicle is closest to the destination
- Which driver is still on schedule
- Who is not working overtime
- If the vehicle can make it to the location without passing the vehicle maintenance threshold
All this information can be used to decide which vehicle to send who will drive that vehicle. An informed decision can be made very quickly.
Communicating with the Cloud
One of the challenges with constant communication with the cloud is the fleet needs a continuous connection, whether that is wifi or cellular. When you have a fleet that is continually driving to very remote locations, one can’t rely upon a constant connection. There will be times when the fleet will not have any service and will be cut off from the outside world. So what should we do when we lose a connection?
In a typical, big data architecture, there would be what’s called a message broker facilitating the communication between the devices and the cloud. A message broker handles routing the messages from the sensors to the cloud, effectively decoupling the sensors from the cloud. Multiple different message brokers can be used in this situation. For example, a very popular message broker is Apache Kafka, which is nice when you have massive amounts of unstructured and structured data being sent to many different locations. Kafka can handle hundreds of billions of messages per day, so it is excellent for when you have many devices sending data to the cloud. Although, if you use Kafka, it does not have any features to handle moments when the sensors have no internet connection. So a developer would need to put in extra effort to make sure to store the messages locally and resend the messages when the internet connection is back up. Also, Kafka has a message size limit of only 1 megabyte, as it is catered towards data points and unstructured data, rather than something like video streaming (which can be done in tiny bit-wise chunks, but not ideal).
Another solution would be to use a Message Broker that is more geared towards IoT devices since this is a common problem for IoT devices. MQTT is built for small sensors and mobile devices, optimized for high-latency or unreliable networks. MQTT can be configured to automatically store the messages for you locally and post them when the internet connection is back online. With a message size limit of 256 megabytes, MQTT can be used to send large amounts of blob data, such as videos, to any device that is willing to accept it. MQTT is also very nice for intercommunication between the sensors in a mesh network. Many manufacturers are starting to look into using MQTT to replace the traditional method of CAN for communications between the separate modules and sensors.
Connecting your fleet to the cloud and utilizing data from the vehicles enables you to optimize costs, improve fleet effectiveness, and identify new monetization possibilities. In this cut-throat market, fleet owners need every advantage they can get to stay on top and manage their fleet efficiently. Data science is here to help fleet owners to do just that and can be used in gaining an edge on the competition.