Vehicle Abstraction Layer

Overview

This project explores how an electric vehicle Fleet Management System can process data from vehicles that use different sensors, communication protocols, and signal definitions.

I designed and implemented an Intelligent Agent System as a modular vehicle abstraction layer on the edge. The system converts raw vehicle data into a consistent representation before sending it to backend services.

The Problem

Vehicle data does not always use the same format.

One vehicle may provide data through OBD-II, another through SAE J1939, while other vehicles may use proprietary CAN definitions. GPS data also uses a different structure through NMEA sentences.

Without an abstraction layer, every backend service must understand each vehicle-specific protocol and signal name.

Design Approach

The system is positioned within an edge-to-cloud Fleet Management System architecture.

The architecture consists of three main layers:

• Vehicle Side: Sensors and ECUs produce CAN frames and NMEA location data. The Intelligent Agent System collects, processes, and standardizes this data at the edge.
• Cloud Platform: Kafka distributes the resulting Protobuf messages, while the Schema Registry, databases, and FMS backend manage validation, storage, and further processing.
• Client Side: Web and mobile applications consume the processed data for vehicle monitoring and fleet operations.

Within this architecture, IAS acts as the boundary between vehicle-specific data and the rest of the FMS. Differences in protocols and signal definitions are handled before the data reaches backend or application services.

Technical Implementation

To keep protocol-specific logic separate from the main processing pipeline, IAS was implemented using a modular architecture.

The implementation consists of three main components:

• Core: Provides the shared processing pipeline, data models, infrastructure connections, NMEA parser, and decoder interface.
• Protocol Decoder Modules: Handle CAN decoding for specific protocols, including OBD-II, SAE J1939, and CReATE_ECU.
• Variant Manager: Configures the deployment, selects the required decoder, registers it with the core, and manages the pipeline lifecycle.

This structure allows support for a new protocol to be added as a separate decoder module without rewriting the shared IAS core.

The processing flow is:

1. Collect CAN frames or NMEA sentences
2. Decode or parse the source data
3. Map vehicle signals to Vehicle Signal Specification paths
4. Build Protocol Buffer payloads
5. Publish the standardized data through Kafka

Tech Stack

The primary technologies used were:

• Go for the concurrent edge-processing pipeline
• CAN DBC files for protocol-specific decoding
• Vehicle Signal Specification for semantic standardization
• MongoDB for the signal-mapping dictionary
• Protobuf for structured payloads
• Kafka for real-time data distribution

---