The Milkman Van of the 21st Century

admin
Joris Wolters 23 Jun, 2021 30 - 5 min read
Share on facebook
Share on twitter
Share on linkedin

Picnic makes grocery delivery effortless for the customer, and even makes the whole process seem effortless. However, behind the scenes we have built up a system of both hardware and software solutions to make this possible. The hardware layer includes distribution and fulfilment centers, hubs, trucks, and vans. The software layer includes apps for both customers and employees as well as many backend services. Often, these two layers are connected, in order to monitor or automate processes. So far our last-mile delivery vehicle had escaped such oversight. However, we have now started to fully incorporate the vehicle into our IT ecosystem to fully leverage the potential for safety, delivery quality, and business efficiency.

The last-mile vehicle that we use, beloved by both our customers and our drivers, excels in its simplicity. What you might not expect though, is that even this relatively spartan vehicle sends hundreds of different data points over its CAN bus, from the state of charge of the battery to whether the lights are activated or by how much the accelerator is pressed. Leveraging this wealth of data has only recently begun.

The opportunities are immense, just to name a few:

  • Automatic asset tracking
  • Automating maintenance request to reduce vehicle down time
  • Tracking battery health of individual vehicles to improve vehicle to trip planning and thus vehicle utilization
  • Tailor-made coaching for our drivers, based on their driving actions, to improve safety and vehicle range
  • And the list goes on…

The first step we have taken is gathering data from our vehicles. We have plugged small telematic dongles into the vehicle’s diagnostic port (OBD port) to read all CAN bus traffic and send that to the Picnic back-end. The CAN bus is the network that is used by all the controllers of the vehicle to communicate directly with one another. For example, the BMS (battery management system) will tell the charger at what power the battery may be charged. Once the battery is at 100% state of charge, i.e. full, the charger may not overcharge the battery. Reading this data and storing it in our backend allows Picnic to better understand the vehicles and the way we interact with them.

For example, one of the ways that we can improve vehicle utilization is by automating the process of planning vehicles to delivery trips. Until now, this is a manual process that relies on the puzzling skills of the operations manager at the distribution hub to make an efficient schedule. Since we started doing deliveries in the mornings, we see that some of the older vehicles are not able to drive all back-to-back trips, especially if some of those trips cover longer distances..

Historical data analysis of delivery trips allows us to determine the components that determine the reach of a vehicle for a particular trip: vehicle (or battery) age, ambient temperature, speed profile, cargo payload, and driving behaviour. The puzzle starts once the trips have been planned out by our planning algorithm. We then find the optimum planning of vehicles to trips, and drivers to vehicles to minimize the number of vehicles required to drive that day. Practically this means planning vehicles with longer range (newer vehicles) with drivers that drive efficiently on the longer trips. In the future we will also determine the exact charging plan per vehicle, so that, for example, only the vehicles that need to drive that day are charged.

The next step is to use the vehicle data to improve the working environment of the Runners. The Runners carry an Android OS mobile device that runs our home-build RunnerApp, which supports them in their complete work journey and allows Picnic to monitor the quality of delivery. For example, it shows on which side of the vehicle the crates are located when finding a parking spot and when they stand next to the vehicle it shows them which crates to take to the customer.

To coach Runners in driving safely, the device records high accelerations to identify harsh cornering. Differentiating between device accelerations due to harsh cornering and accelerations of the device in the pocket of the Runner during a delivery have proved to be difficult to fully prevent. Such imperfections reduce the trust our Runners put in the Driving Coach. Access to the vehicle data makes this much easier, as we will be able to use the vehicle acceleration measurements to accurately determine driving behavior. Furthermore, as we drive very regular routes, we are able to recognize unsafe spots and warn our other drivers that they are about to pass the potentially tricky road situation.

Picnic is also keen to share this data with the city and municipalities, so that they can improve and update their safety risk maps. This might seem counterintuitive in an age where monopoly of data is instrumental to a company’s value, but in fact it makes sense as it will improve the safety and thus the life of the people we serve.

The use case stretches far beyond reading data from the vehicle. Our first trials of smart charging have already been successful. In our system, the OBD dongle can halt the charging process by simple remote commands from the Picnic backend. This will improve battery life time, as charging cycles are reduced by only charging vehicles up to the point that is required to drive their trips. And some margin for drivers getting lost of course 😉

Another potential cost cutter for maintenance is over-the-air updates. We are still fine tuning and improving the vehicle as we scale our operation, and when we wanted to change the maximum reversing speed of the vehicle, our mechanics needed to hook up their laptop to each of the 1500 vehicles individually. Doing such operations OTA during the night makes outroll much quicker and more efficient.

Further in the future we can imagine scenarios of higher vehicle automation. Specifically for the delivery use case you can think about unlocking the cargo doors as the vehicle halts for a delivery, but of course not when the vehicle stops at a traffic light. Dynamically changing the vehicle parameters, e.g. speed limit based on geolocation or weather warnings, could be a further measure to implement a safer work environment.

With increasing the connectivity and the amount of data shared, we also need to think very carefully about the security of the data as well as that of the vehicle. The Runner needs to be able to stay in full control of the vehicle at all times. We cannot lose focus on vehicle and data security as we develop the features we just talked about.

The possibilities are endless for connected vehicles and you could lose yourself in them. It therefore remains essential to keep focus on the original goal: creating a safe, stress free and fun working environment for our Runners all while getting the most out of our vehicles. A happy Runner is a happy customer. That truly creates the value that is Picnic.

Want to join Joris Wolters in finding solutions to interesting problems?