Remote device management – Provisioning and OTA updates

Standalone dash cams with inbuilt connectivity (LTE), compute for advanced AI on the edge (ADAS and DMS), and storage for video loop recording are rapidly becoming the norm in the commercial fleet space.

An illustration of remote device management

Standalone dash cams with inbuilt connectivity (LTE), compute for advanced AI on the edge (ADAS and DMS), and storage for video loop recording are rapidly becoming the norm in the commercial fleet space. This groundswell of demand cuts across fleet segments, sizes, and geographical locations – driven by the rapid evolution of video telematics solutions, hand in hand with a better appreciation by fleets of the benefits of video. In essence, for fleets, connected dash cams have become essential IoT devices critical to everyday operations.

As with any IoT device, giving solution administrators the ability to manage devices remotely is critical. This includes two main components, device provisioning and software updates over the air (OTA). Activating a device, assigning it to a particular account and asset, deactivating accounts and devices, and setting extensive device configurations come under the umbrella of device provisioning services. Everyone using a smartphone today is already aware of OTA updates, which cover software updates for enhancements, security patches, and bug fixes. The same functionality is needed for fleet dash cams, with an added management layer giving fleet managers the ability to approve updates and assign them to particular accounts and assets.

Our RideView software already supports LTE connected dash cams, and we are happy to announce the availability of our suite of device management services encompassing device provisioning and OTA updates.

Provisioning

Our device provisioning workflow is as follows:

  • When a shipment of cameras is sent to a customer (TSP in our case), the device vendor or TSP provides us a list of unique device ID’s, which are added to our devices library. A device in our system refers to a dash cam, identified by its unique IMEI.
  • We provide provisioning APIs and frontend interfaces on our administration portal that let TSPs assign devices to accounts and assets, specify the service and vehicle duty type, and more:
  • An asset refers to the vehicle that the device is installed in. For TSPs this provides the bridge connecting their RideView based video telematics solution to existing services, and they can map every device ID to a fleet, and a unique asset ID that refers to a particular vehicle (or a telematics black box) already registered in their backend. In the absence of a pre-existing asset ID, we default to using the IMEI itself as the asset ID.
  • We also provide a customizable metadata field for every asset that can be used by TSPs to attach other associated data to every device and asset. For example, end-users might not be able to recognize either device IMEI or asset ID and want to display vehicle registration numbers as something easier for them to identify. They can define and attach a custom metadata field to assets denoting a unique display ID for each asset corresponding to vehicle registration numbers.
  • TSPs can specify the level of service they want to enable on every device. We currently provide 3 levels of service, which can be upgraded or downgraded for any asset at any point in time, and is automatically reflected in the monthly billing:
  • RideCam+ (DVR and G-sensor events)
  • RideCam+ Pro (+ ADAS)
  • RideCam+ Standard (+ ADAS and DMS)
  • Assets also need to be tagged with the appropriate duty type (heavy/medium/light). This is critical as all event configurations are saved according to duty types, so properly assigning an asset to a duty type ensures that the driver notifications and events triggered are optimal for the vehicle the dashcam is installed in.
  • TSPs get access to extensive device configurations settings that affect device operation:
  • LED operations to reflect various device states.
  • Custom voice notifications – e.g., if there are fleets in different countries with different languages, notifications can according to the fleet’s language preferences.
  • Device awake duration post ignition off – i.e. duration during which it is drawing power from the vehicle’s battery.
  • And many more parameters providing granular control of the RideView SDK on the device.
  • Once provisioned, devices can be de-provisioned (disabled from service) or re-provisioned (moved to a different asset within the same fleet):
  • De-provisioning should be used when a vehicle is removed from operation, a camera is sent for RMA, etc. It also makes the device available for reassignment to another asset.
  • Re-provisioning should be used when a device is moved from one asset to another within the same fleet.

With these changes to our camera provisioning workflow it is now really as easy as 1-2-3 for fleets to get up and running with our solutions – put in a SIM, install and start driving.

OTA

On our connected dash cams, we provide a system application that does automatic trip processing and video recording from ignition on to ignition off. This app encapsulates the RideView SDK providing all on-device functionality including video loop recording, G-sensor events, ADAS and DMS. This application is updated regularly, in-sync with updates to our SDK for new functionality, enhancements to AI models, and bug-fixes.

To provide our customers a seamless way to update we have built OTA capability into our device management portal and our web APIs, providing a consistent experience across all the connected cameras that we support, with no dependence on third-party device management software. These provide account managers the ability to:

  • View what version is currently installed, and a list of available versions available for a device.
  • Select and approve an app version for updating a device or a batch of devices belonging to a fleet.
  • Approve app versions for updating all compatible devices in the field.

The update is pushed to the device at the next instant it is connected to the LightMetrics backend, and installed in the next boot-up cycle of the device. Our native OTA functionality significantly compresses the duration between the general availability of an update on our platform and the time when it is rolled out in the field.

We have previously spoken about how the features it provides are only part of what makes a solution successful, the others being how it is installed, managed, and monitored once deployed.  Connected dash cams that can be completely managed from the cloud are going to be a major driver of the rapid growth of video telematics, and with our suite of device management services, we take a significant step in that direction. In the coming weeks and months, we will be rolling out a host of other features that give solution providers a 360-degree view of their devices in operation, greatly enhancing the experience our customers and end-users have with our platform.