Technolgy Behind ELD Implementation for Fleets in US: Learn About the System Design & J1939/OBD2 Stack Integration

In our previous article, we discussed in detail about the ELD mandate, its December 2017 deadline and all the socio-political motivations behind this regulation.

We also had a glimpse of benefits and potential challenges that this regulation can be confronted with, during implementation.

While USA based fleet management companies, Tier-I suppliers and road-safety regulators are all gearing up for the ELD mandate implementation. We spoke to our automotive experts to help you understand the technology behind Electronic Logging Device

In this article, we will share with you the ELD system design, technology architecture and factors to consider while selecting the automotive diagnostic stack (J1939/OBD2/UDS/KWP2000) for integration with ELD.

The Electronic Logging Device (ELD) System Design:

The Electronic Logging device has a layered architecture design as shown in the diagram below.

The hardware or the physical layer of the device is connected to the in-vehicle network (CAN/LIN network), to receive the vehicle data through an OBD port.

Three software layers are part of this system design namely, the low-level device drivers, middleware (diagnostics and communication stacks) and the application layer.

• • The main purpose of the low-level device driver is to provide hardware abstraction. The device driver facilitates compatibility between the application and the hardware of the device.

As a result the application code can be written without any dependency on any specific hardware platform

• The middleware comprises of the Diagnostic and communication stack which facilitates the communication between the different ECUs’ and it also fetches vehicle related diagnostic data for the application layer.
• The application layer enables data communication with the end-user applications. It fetches all the data from the lower-layers and responds to commands sent by the end-use application layer.

We will now talk about the behind-the-scene technologies within each layer of the device architecture.

The ELD Technology Architecture:

In this section we will learn in detail, about the underlying technology in each of the system design layer as discussed above.

1. Physical Layer:The physical layer is the CAN Bus which acts as an interface for the in-vehicle network communication. All the electronic control units (ECU) within a vehicle communicate with each other through CAN Bus.
2. Low-Level Device Drivers:These drivers facilitate the hardware to communicate with the middleware. This layer also works as a hardware abstraction layer (making the upper layers hardware independent).

   The low level driver layer contains different software modules which include the microcontroller clock unit, timer, scheduler and many more.

3. Vehicle Communication layer or the Middleware:The middleware comprises of the memory stack, the communication and diagnostic stacks. The stacks can range from UDS, OBD, KWP2000 to J1939.

   The type of stack that can be integrated with ELD will depend on the following   factors:

   • Type of Vehicle: While J1939 is typically implemented for commercial vehicles, on the other hand the OBD-II stack is used when the implementation has to done on a passenger vehicle.
   • Accessibility of vehicle data: If the fleet company or tier-I supplier chooses to implement UDS or KWP2000 stack they should also keep in mind that, these two stacks have special identifiers called DID.

   DID make sure that the vehicle data can only be securely accessed by the manufacturer or an OEM. Unless, a special permission from the OEM is obtained, the vehicle information cannot be accessed using UDS or KWP2000 stacks.

4. Application Layer As already discussed, the application layer helps in data communication with end-user application.

   This layer fetches data provided by the services in the lower layers to facilitate communication with the end-user application.

   The ELD system can be designed for efficient data transfer using wired, wireless or plug-and-play technologies. The technology used for data transfer also depends on the type of data storage. The data can be stored in the following ways:

   • Internal Flash:
     The internal flash is a non-volatile memory. It is used to store the vehicle data and the data can be transferred through an USB port (plug-and –play) to other devices like hard-drive, scan tool and more.
   • Cloud storage:
     The vehicle data can be stored in cloud for remote access. The application layer sends data to the cloud. This data can be accessed remotely though a mobile or web dashboard for data analytics or report generation
   • GSM/GPRS:
     The communication of data through GSM/GPRS technology will involve the role of Telecom service providers. The end-user receives the data through sms/text messages.
   • Bluetooth:
     The data transfer can also be achieved through Bluetooth technology. The end-user should have a Bluetooth application to facilitate the data reception.This is suitable for short-range communications.

Investing in a diagnostic and communication stack for ELD:

An automotive software stack (J1939/OBD 2) will be a key component of your ELD product roll-out

And if you plan to outsource the Electronic Logging Device (ELD) project to an embedded software expert; it is essential that you evaluate the quality of the J1939/OBD2 source code.

Refer to this blog, where our J1939 developers share the test-cases that will help you to check the quality of the source code. How to Test Quality of J1939 Software Source Code

Get in touch with us for software and hardware consulting regarding the ELD product roadmap

For any enquiries regarding J1939 or OBD 2 stack integration and software or hardware development, contact us at sales@embitel.com