0 mins to read•
EV OEM Quick Start Guide
0 mins to read•
Learn more about EV OEM integrations, including key milestones in the OEM journey and the sequence of steps needed to achieve integration. Explore resources for data requirements, data integration pathways, and auxiliary services and projects.
Step of OEM Journey
Initial Introduction & Discovery Meeting
Meet and Greet
Get to know about the OEM’s requirements and Geotab’s capabilities.
Initial Introduction & Discovery Meeting
(includes installation of GO device)
(no device installation)
Minimum standard signals required for Minimum Viable Product
Data validation scenarios are reviewed in a test environment to confirm precise data presentation.
Sign Off Data Validation
Data is successfully validated, and the OEM is open for additional projects.
✱ NOTE: Step 6 is possible only after the completion of Phase 1.
Step of OEM Journey
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).
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:
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:
✱ 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.
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:
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.
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.
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:
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.
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.
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.
For more information, please reach out to your Geotab point of contact.
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.
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.
For more information, reach out to your Geotab point of contact.
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:
To learn more about our auxiliary services, please reach out to your Geotab point of contact.
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.
✱ 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.
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.
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.
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.
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.
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.
A more in-depth explanation of the information in this document can be found in the following links:
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).
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.
J1850 Bus Positive/ J1708 Negative
J1850 Bus Negative/ J1708 Positive
Secondary CAN High
Secondary CAN Low
Main CAN High
Main CAN Low
ISO K Line
ISO L Line
+12V \ +24V
CAN 1 - J1939 Hi
CAN 2 - Hi
CAN 1 - J1939 Lo
CAN 2 - Lo
CAN 1 - Shield
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.
Speed: 125/250/500 kbps,
Single Wire CAN
Speed: 33/50/83.3 kbps,
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)