OEM.connect

Webfleet uses real time vehicle status data to provide services to fleet managers helping them to take smart decisions and to optimize their operation. Connecting a single vehicle to Webfleet traditionally required the installation of a custom fit LINK box hardware into the vehicle which was able to continuously gather, process and transmit data to Webfleet backend servers. Such installation causes significant costs of time and money on top of the investments in the required LINK box hardware.​

By today, latest generations of vehicles come with connectivity fitted by the manufacturer which can be enabled and provisioned on request in a way that the vehicle owner allows live status of his car to become available to WEBFLEET.​

1. To develop the software needed to make use of such data provided by the manufacturers in a scalable way and to allow connecting new vehicles to WEBFLEET as a 100% digital process rather than the manual installation of a custom device.​

2. To harmonize incoming OEM specific data formats and semantics to make them compatible with standard WEBFLEET functionalities and features.​

Today vehicle manufacturers, also called OEMs, consider connectivity of vehicles already during the design process. As a result, the capability to select, filter, preprocess and transmit vehicle data over the air became a standard part of their offering. With that, next to deploying the car and usual service infrastructure, they also created the IT systems needed to receive, store, provision and forward vehicle data on request of the car owner to third parties like Webfleet Solutions.​

Provided data, depending on the vehicle brand, usually includes items like position, milage, trips, ignition, battery or fuel state, speed as well as safety-, performance-, maintenance- and service information.​

Manufacturers today usually provide data of their vehicle via REST APIs, via software buses like Apache Kafka or via remote procedure call systems like gRPC.​

Typical today's scalability requirements are querying & processing of 100.000 vehicles with <5min frequency.​

OEM interfaces typically provide methods for the  provisioning of vehicles (i.e., to make their data available to WEBFLEET on consent of the vehicle owner), for querying vehicle status data (e.g., vehicle mileage) and to provide events (e.g., to alert an engine fault). All that can be considered as input to OEM.connect.​

Output is vehicle data in WEBFLEET conform format, semantics and frequency which gets forwarded to the Webfleet message queue service responsible to feed vehicle data to all further processing mechanisms within the Webfleet Solutions Cloud Platform (WFSCP). ​

Processing between data supplied by the OEM and data expected by the Webfleet Solutions Cloud Platform (WFSCP) is handled by several micro services which are specific to the vehicle brand. ​

While creating specific services per brand could be considered overhead, it provides sufficient decoupling and autonomy between development teams to work efficiently on different integrations in parallel. Furthermore, this allows to acknowledge a wide range of implementation peculiarities which exist between different vehicle brands.

To achieve required performance horizontal scalability is implemented via uniform distributed micro services which evenly share workload. ​

With the basic unit of work being “querying and processing a single vehicle” the responsibility for every vehicle gets attached to a specific OEM.connect micro service instance.​

Load balancing is provided via an Apache Ignite in memory data grid which matches each unique Vehicle Identification Number (VIN) to a micro service instance while reducing disc IO.