User Guide

0 mins to read

Key information for EV OEM integrations, sequence of steps, and key milestones

April 2022

High Level Overview of OEM Journey

Phase 1

Step of OEM Journey

Action Items

Additional Information

Step 1

Initial Introduction & Discovery Meeting

Meet and Greet

Get to know about the OEM’s requirements and Geotab’s capabilities.

Step 2

Initial Introduction & Discovery Meeting

Device-centric Integration

(includes installation of GO device)

API based integration

(no device installation)

Step 3

Minimum standard signals required for Minimum Viable Product

Data Requirements for Standard EV Support

Data Requirements for Standard FCEV Support

Step 4

Data Validation

Data validation scenarios are reviewed in a test environment to confirm precise data presentation.

Step 5

Sign Off Data Validation

Data is successfully validated, and the OEM is open for additional projects.

Phase 2

NOTE: Step 6 is possible only after the completion of Phase 1.

Step of OEM Journey

Action Items

Additional Information

Step 6

Additional Projects

Extendable Services

Expanded Signal Support

ECU OTA Updates

Partner Label

Remote Vehicle Controls


A vehicle is considered supported by Geotab when the minimum number of data points can be taken from that vehicle. Unlike conventional vehicles, EV OEMs are not mandated to follow standard CAN protocols and data standards (eg. J1939, OBDII).

Therefore, Geotab has developed unique capabilities to integrate with EV data, ensuring the OEM partner’s EVs continue to have strong data support today, and in the future as OEMs grow their EV models.

NOTE: Geotab’s Electric Vehicle definition does not include Hybrid vehicles (HEVs) that do not have plug-in charging capabilities. Geotab defines electric vehicles to be BEVs (Battery Electric Vehicles), PHEVs (Plug-in Hybrid Electric Vehicles), and FCEVs (Fuel Cell Electric Vehicles).

Data Requirements for Standard EV Support

In the Geotab ecosystem, once the GO device is able to capture the EV data points listed below, all the EV specific tools, features, functions, rules, and reports that are available in the MyGeotab platform will be compatible with that vehicle. The following list captures the data that we require from electric vehicles in order to establish standard support:

  1. State of Charge (SOC): A data element that indicates the current charge percentage of the vehicle.
  2. Charging Status (AC/DC): A data element that can identify whether the vehicle is charging or not. If charging, it helps to determine whether it is from an AC/DC source.
  3. Driving Energy: A data element that helps determine the energy that is going in and out of the vehicle. This data can be any of the following forms mentioned below.
    1. Propulsion,
    2. Auxiliary, or
    3. Regenerative braking.
  4. Charging Energy: A data element that can help determine the amount of energy that was added to the battery during a charging session.
  5. Odometer: A data element that is required to capture the odometer reading of the vehicle.
  6. Ignition: A data element that determines whether the vehicle is turned ON/OFF by its ignition status.
  7. GPS: To actively know the current latitude and longitude coordinates of the vehicle irrespective of its ignition status.
  8. VIN: A data element that captures the identification number of the vehicle.

Data Requirements for Standard FCEV Support

The energy source for FCEV vehicles is the electric energy generated from the hydrogen fuel cell. Therefore, in order to establish standard support for these vehicles, capturing the hydrogen fuel data is key. The following data points are required from a FCEV vehicle to get minimum viable support:

  1. Hydrogen Fuel Level: A data element that helps generate the hydrogen fuel percentage level from the vehicle.
  2. Hydrogen Fuel Used: A data element that helps determine the amount of fuel consumed during ignition ON/OFF.

NOTE: The above-mentioned data requirements are necessary for an EV OEM in order to make an integration complete and successful. It is difficult to establish support from Geotab without these standard mandatory data requirements. Please refer to the Electric Vehicle Make/Model Support Reference spreadsheet to view a list of vehicles that we provide support to, based on the standard data across all EV makes and models.

Data Element Suggestions for Enhanced/Advanced Support

In addition to the data points that comprise standard data support, there are other data points through which Geotab can derive value for end Customers by meeting different use cases. The following data elements are beneficial to have as they can allow Geotab and OEM Partners to provide enhanced experience to OEMs themselves, and the end Customers:

  1. State of Health,
  2. Cell Voltage,
  3. EV Battery Temperature,
  4. EV Battery Capacity,
  5. Weight of the vehicle, and
  6. Idling Hydrogen Fuel Used (For FCEV).

To understand this better and dive into use cases that leverage the EV features in My Geotab, please reach out to your Geotab point of contact.

Data Integration Pathways

There are different data integration pathways an OEM can take to get support with Geotab. We recommend the OEM Partner discuss the advantages and disadvantages of each option, as well as the timeline with the Geotab Solutions Engineering team.

To begin, Geotab requires all OEM Partners to be fully supported from a standard EV data perspective. The following diagram indicates the overview of the data integration pathways.

GO Device Installation

This type of integration involves GO devices being installed directly into the vehicle. Geotab offers support to OEMs to determine the best location to install the GO device within the vehicle, considering the GPS and cellular reception. This integration pathway allows for the following two possible methods for the GO device to support the vehicle:

  1. J1939 EV: A subset of EV-specific messages from the J1939 standard, or
  2. DBC File: A proprietary OEM signal definitions file.

J1939 EV Pathway

Many OEMs with Internal Combustion Engine (ICE) vehicles have programmed the signals on their vehicle’s CAN network as per the standards of SAE J1939. When it comes to electric vehicles, Geotab utilizes the same SAE J1939 standard for signals. The GO device firmware is pre-programmed to understand the signal definitions of SAE J1939. Further EV details can be found in the J1939 EV Implementation Guide for GO Compatibility guide.

OEMs tend to choose this pathway if their ICE vehicles are already programmed according to SAE J1939 standard. If an OEM wants to do the integration via J1939 EV method, they must implement the EV specific signals outlined in the J1939 EV Implementation Guide for GO Compatibility guide. Once these signals are implemented and validated, the OEM’s vehicles will be considered supported within the Geotab ecosystem.

Additional Considerations

  1. The OEM must be familiar with the SAE J1939 standard.
  2. If the OEM is able to adopt the J1939 EV signals, the Geotab Solutions Engineering team will support the OEM with the implementation of these signals on their CAN network.
  3. A Pro/Pro-plus subscription plan is required for EV data support.
  4. The J1939 EV implementation process with OEMs takes approximately 4 to 6 weeks.

Please refer to the J1939 EV Implementation Guide for GO Compatibility guide for any information regarding the J1939 EV implementation process or frequently asked questions. If you still need more information, reach out to your Geotab point of contact.

DBC File Pathway

This method of support is suitable for OEMs who have a proprietary set of signal definitions. Sometimes OEMs might prefer to implement their signals in a manner that does not follow any particular set of standard protocols. In that case, Geotab has an alternate way to support OEMs with such scenarios.

Geotab will request a DBC file from OEMs where all signal definitions are defined in their own proprietary form. Later the DBC file is taken and incorporated into our GO firmware to verify the signal definitions. Once the signal definitions are verified, Geotab establishes integration support between the OEM and the GO firmware.

Additional Considerations

  1. A DBC file with all signal definitions that are necessary to provide the standard EV support.
  2. A Pro/Pro-plus subscription plan is required for EV data support.
  3. CAN logs are required to verify the signal definitions that were presented to Geotab via the DBC file.

For more information, please reach out to your Geotab point of contact.

API Based Integration

When the OEM has either their own or a third-party telematics device installed in the vehicle or are not interested in installing the GO device, then an alternate integration pathway is a Cloud to Cloud integration.

OEM Cloud to Cloud Integration Pathway

The OEM Cloud to Cloud method of integration is suitable when an OEM partner does not want to install a GO device into their vehicle. This pathway becomes relevant when the OEMs have either their own telematics platform built internally, or by a third-party, to collect data and communicate within their ecosystem. In this case, Geotab asks OEMs to provide their API documentation in order to capture the data from their cloud system.

Once Geotab receives the OEM’s API documentation, Geotab will begin to take the necessary steps to take the data that is being output by the OEM cloud system. An effort will be taken to match as closely as possible the data that the GO device provides. The data ingestion as well as the data matching algorithms are implemented in Geotab’s OEM data platform (middleware).

The image below depicts the flow of data from the OEM’s cloud system to the MyGeotab platform.

Additional Considerations

  1. An NDA is required before any documentation is shared.
  2. OEM’s detailed API documentation is required.
  3. A Pro/Pro-plus subscription plan is required for EV data support.

For more information, reach out to your Geotab point of contact.

Auxiliary Services and Projects After Initial Data Integration

Regardless of the data integration pathways the OEM chooses, Geotab requires that the OEM’s vehicles are reporting the minimum data required to feed all the EV tools and features in the Geotab ecosystem (standard support). Once this milestone is reached, the Geotab team can move forward with all the specific use-cases and unique requirements for OEMs through the MyGeotab platform. The following services are offered once Geotab establishes the standard support:

  1. Extendable Services,
  2. Expanded Signal Support,
  3. ECU OTA Updates,
  4. Partner-Label, and
  5. Remote Vehicle Control.

To learn more about our auxiliary services, please reach out to your Geotab point of contact.

Extendable Services

Extendable Services allows Customers to share telematics services with their business partners and trusted organizations through subscriptions. Secondary subscriptions can be purchased at a Rate Plan share level allowed by the Customer. It is possible to have a higher-tier Rate Plan in the secondary databases.

How Extendable Services Works

  1. Extendable Services protect private fleet information in the Customer database, such as driver names, groups, zones, and more instead of adding user credentials for multiple third-parties on the same database.
  2. Data is split at the Gateway level. This means that no information captured in any MyGeotab databases is shared. Only the data relevant to the assigned Rate Plan will be sent to the new recipient.
  3. Currently, Extendable Services only support data originating from Geotab GO devices. Extendable Services supports the following Geotab software Rate Plans: Base, Regulatory, Pro and ProPlus. Customers can create subscriptions for different streams at different levels, as needed.

NOTE: All the EV features in My Geotab comes with Pro or ProPlus plan. EV OEMs must subscribe to Pro or ProPlus plans in case of integrating with GO devices. Please refer to the Rate Plan Feature Comparison document for more details.

Expanded Signal Support

Once the standard support is established, Geotab works with OEMs on other expanded signal sets that may solve a variety of use cases for different OEMs. Apart from the standard signals that are required for basic support, an OEM DBC file may contain numerous signals for which Geotab can extend its support to integrate into MyGeotab platform. Your Geotab point of contact can help initiate this support after the standard support is done.

Electronic Control Unit Over-the-Air (ECU OTA) Updates

ECU OTA updates is a service provided by Geotab to the OEM to update the different electronic control units of the vehicle. This is a capability developed by Geotab so the OEMs can take advantage of the installed GO device and remotely update their vehicles. This eliminates the need for a Customer to bring their vehicle to the shop floor for updates, and allows the OEM to collect performance information of their vehicle.

Partner Label

The partner-labeling of products is offered to Geotab Partners to remove branding from certain documents, and allows Partners to apply their own branding, for their own Customers. They can do this with Geotab products like MyGeotab, MyGeotab App, Geotab Drive, and the GO device. Although, the partner-labeling of Geotab products is feasible, it is required to create a request with strategic justification as to why this is needed.

For more information regarding partner-labeling, please refer to this document, or reach out to your Geotab point of contact.

Remote Vehicle Controls

Geotab also provides remote vehicle control features to OEMs. This is offered so that whenever a vehicle enters into a particular zone, the vehicle can go into a specific mode using the IOX capability.


Overview of Engagement Models with OEMs

Data Presentation

Integrating with the GO device allows for a significant improvement in the presentation of data collected from a given vehicle. Not only is the data organized into a format that is visually appealing and easy to search through, but it is also standardized across all Customers. This standardization enables a smoother integration with Geotab systems and support personnel who can immediately understand and work with newly provided data. If any issues arise in the data, support personnel can quickly troubleshoot engine data or connectivity issues for OEM devices. This makes for an improved Customer/Partner experience as issues are addressed faster and more effectively.

Relevant Documentation

A more in-depth explanation of the information in this document can be found in the following links:

  1. GO9 Support Document [PUB]
  2. Best Practices for GO Device Installation [PUB]
  3. GO9 RUGGED Support Document [PUB]
  4. Firmware Product Guide [PUB]
  5. J1939 EV Implementation Guide for GO Compatibility V1.9 [PUBLIC]
  6. Harness Identification and Application [PUB]

Supported Standard Protocols and Speeds

Supported Protocol



Old heavy-duty vehicle communication protocol used exclusively with the J1708 interface operating at 9.6 kbps. Caterpillar Legacy is a variation operating at 62.5 kbps. The J1708 protocol appears by itself on the J1708 interfaces. This protocol is mainly broadcast. There are few requests – but the most important information, including RPM, is broadcast.


Heavy-duty vehicle communication protocol used exclusively with CAN in extended frame mode (29 bit arbitration ID) and operating at 250 kbps or 500 kbps. CAN buses with J1939 can also have OBDII (usually standard OBDII; but manufacturer specific messages are also possible). This protocol is mainly broadcast. There are few requests – but the most important information, including RPM, is broadcast.


Automotive self diagnosing and reporting protocol. Used mainly with passenger vehicles and light duty commercial vehicles. OBDII can be present in ISO buses, J1850 VPW, J1850 PWM and CAN buses. OBDII messages and responses use a specific header (first 3 bytes of the message) when used with ISO and J1850 buses; and specific arbitration IDs when used with CAN. Other headers or CAN arbitration IDs are considered manufacturer specific messages and can coexist with OBDII. OBDII can also coexist with J1939 on the same bus. For CAN, standard OBDII messages are usually found on buses operating at 250 kbps or 500 kbps. OBDII is request based, there is no broadcast.


A manufacturer-specific protocol used by GM on CAN at 500 kbps. Has RPM source, and coexists with OBDII. The GO does not send GM LAN requests, almost everything we need, including RPM is broadcast (some OBDII requests are sent when the protocol is GM LAN).

Supported Standard Physical Interfaces

There are three diagnostic port types through which physical interfaces connect with a GO device. These supported ports are the OBDII 16-pin, 9-pin, and 6-pin ports, and they are standard for most vehicles. The GO device itself is compatible with the OBDII 16-pin port. If a vehicle has a 9-pin or 6-pin port, these are remapped with a harness to the OBDII 16-pin port which can then be connected to a GO device.

OBDII 16 Pin


Pin info


Pin info


Single-wire CAN




J1850 Bus Positive/ J1708 Negative


J1850 Bus Negative/ J1708 Positive


Secondary CAN High


Secondary CAN Low


Chassis Ground




Signal Ground




Main CAN High


Main CAN Low


ISO K Line


ISO L Line





9 Pin Port


Pin info


Pin info




J1708 Hi


+12V \ +24V


J1708 Lo


CAN 1 - J1939 Hi


CAN 2 - Hi


CAN 1 - J1939 Lo


CAN 2 - Lo


CAN 1 - Shield

6 Pin Port


Pin info


Pin info







Chassis Ground


BAtt+ (12V\24V)


Controller Area Network (CAN)

CAN uses many physical interfaces to connect to a given vehicle. The table below outlines the various CAN types, their speeds, data protocols, and diagnostic/application protocols.

Physical Interface


Standard CAN

Speed: 125/250/500 kbps,

  1. Data packet protocols: ISO 15765 CAN, GMLAN, VW TP 2.0, SAE J1939-21,SAE J1939-FMS,Diagnostic/application protocols: Std OBD2, WWH-OBD, UDS (ISO 14229).

Single Wire CAN

Speed: 33/50/83.3 kbps,

    1. Data packet protocols: GMLAN, OEM Specific.

    Speed: 50/125/250 kbps,Data packet protocols: GMLAN, OEM Specific, ISO 15765 CAN, SAE J1939-21, SAE J1939-FMS,

    Diagnostic/application protocols: Std OBD2, WWH-OBD, UDS (ISO 14229) * 2- or 3-wire install support (for older vehicles/asset tracking)