TL;DR:

  • CAN (Controller Area Network) bus is a serial communication protocol used in virtually every modern vehicle and most industrial machines — it wasn’t designed for IP connectivity, which is why bridging it to edge computing requires a hardware gateway.
  • CAN-to-edge bridges decode raw CAN frames using DBC files (database CAN), translate signals to structured data, and forward over MQTT or REST to an edge broker or cloud platform.
  • The combination of CAN telemetry plus edge AI inference is the basis for next-generation predictive maintenance in vehicles, construction equipment, agricultural machinery, and factory automation.

CAN bus was invented by Bosch in the 1980s and became the dominant in-vehicle network protocol for good reasons: it’s robust under electrical noise, operates without a central host, supports real-time determinism, and works with cheap twisted-pair wiring. Every production vehicle since around 2008 is legally required to expose diagnostic data over OBD-II, which sits on top of CAN. Industrial protocols like CANopen and J1939 (for heavy vehicles and agriculture) use the same physical layer.

None of this was designed for edge computing or cloud connectivity. Bridging CAN to modern IoT and edge platforms is now a well-understood engineering problem, but it has enough subtlety to warrant a practical walkthrough.

How CAN Bus Works

CAN is a broadcast bus: all nodes on the network see all messages. Each message has an 11-bit (standard) or 29-bit (extended) identifier and up to 8 bytes of data. There’s no source or destination address in the frame — nodes subscribe to message IDs they care about.

Message timing in automotive CAN is deterministic: an engine ECU might broadcast RPM and throttle position at 10ms intervals, battery state at 100ms, body control signals at 500ms. Industrial CANopen adds a layer on top with object dictionaries and service data objects (SDOs) for configuration.

The DBC (Database CAN) file format is the industry standard for describing how raw CAN frames map to human-readable signals: which bits within a frame represent engine temperature, which represent wheel speed, what scaling and offset to apply, and what the physical units are. DBC files are proprietary — OEMs publish them selectively, and reverse-engineering them from captured bus data is a significant portion of automotive IoT integration work.

The CAN-to-Edge Architecture

A typical CAN-to-edge deployment has three layers:

Layer 1: CAN interface hardware

A CAN-to-USB or CAN-to-Ethernet adapter connects the physical bus to a gateway computer. Common options include:

  • Peak PCAN-USB: widely used in automotive development, Linux SocketCAN driver support
  • Kvaser Leaf: popular in industrial settings, good SDK support
  • CANable: low-cost open-source USB adapter for prototyping
  • Raspberry Pi with MCP2515 SPI module: for embedded gateway builds

For rugged industrial deployment, DIN-rail gateway hardware from vendors like Advantech, Moxa, and IXXAT integrates CAN interfaces with industrial I/O and cellular or Ethernet uplink in sealed enclosures rated for -40°C to 85°C.

Layer 2: Signal decoding and normalisation

The gateway software reads raw CAN frames from the interface and decodes them using a DBC file:

import can
import cantools

# Load the DBC file describing signals on this bus
db = cantools.database.load_file('vehicle_signals.dbc')

# Connect to the CAN interface (socketcan on Linux)
bus = can.interface.Bus(channel='can0', bustype='socketcan')

for message in bus:
    try:
        decoded = db.decode_message(message.arbitration_id, message.data)
        # decoded is now a dict: {'EngineRPM': 2400.0, 'CoolantTemp': 87.5, ...}
        publish_to_mqtt(decoded, timestamp=message.timestamp)
    except KeyError:
        pass  # Unknown message ID, skip

The cantools Python library handles DBC parsing and signal decoding. For production gateways, the same logic is often implemented in C++ or Rust for lower latency.

Layer 3: Edge broker and analytics

Decoded signals are published to an MQTT broker running on the edge device (Mosquitto or EMQX Neuron for industrial use). From there:

  • Local rules engine (Node-RED, AWS IoT Greengrass, or Azure IoT Edge) applies thresholds and generates alerts
  • Time-series database (InfluxDB, TimescaleDB) stores signals locally with configurable retention
  • Edge AI model (TensorFlow Lite, ONNX Runtime) runs inference for anomaly detection or predictive maintenance
  • Selective sync to cloud platform sends aggregated data or alerts rather than raw high-frequency telemetry

J1939 for Heavy Vehicles

J1939 is the CAN application layer used in heavy trucks, buses, construction equipment, and agricultural machinery. It uses 29-bit extended CAN IDs and defines Parameter Group Numbers (PGNs) — standardised signal groups for engine performance, transmission, brakes, and more.

Unlike automotive OBD-II, many J1939 PGNs are publicly documented in the SAE J1939 standard, making fleet telematics integration more straightforward for standard parameters. Vendor-specific PGNs (for features proprietary to a particular OEM) still require DBC files or reverse engineering.

For fleet management, J1939 telemetry is the basis of most modern telematics units: engine hours, fault codes (DTCs), fuel consumption, load sensing for predictive maintenance scheduling. Edge processing on the vehicle allows local alerting for driver-facing warnings and local storage for connectivity-challenged environments (mines, remote construction).

Edge AI on CAN Data

CAN telemetry is time-series data with high dimensionality (dozens to hundreds of signals per second), which makes it well-suited for machine learning approaches to anomaly detection and remaining useful life estimation.

A common pattern:

  1. Collect 6—12 months of CAN data from a fleet under normal operation
  2. Train an autoencoder or LSTM model on “normal” signal patterns
  3. Deploy the trained model to edge hardware on each vehicle or machine
  4. At runtime, inference runs locally on incoming CAN frames; elevated reconstruction error signals an anomaly
  5. The alert — with the raw signal snippet — is sent to the cloud for fleet management review

This architecture keeps inference on the asset, avoiding latency and connectivity dependencies, while centralising alert management and model retraining.

Hardware that works well for this: NVIDIA Jetson Orin NX (for high-throughput vision + CAN), Raspberry Pi 5 with Hailo-8 M.2 accelerator (for cost-sensitive fleet deployments), and industrial x86 edge boxes with discrete NVIDIA GPUs for larger multi-bus gateway scenarios.

Security Considerations

CAN was designed before cybersecurity was a concern for embedded systems. It has no authentication: any node can broadcast any message ID. Physical access to the bus is sufficient to inject arbitrary messages. This is the root cause of many automotive cybersecurity vulnerabilities.

For edge computing integrations:

  • Treat the CAN interface as a sensor, not a control plane: read telemetry data, don’t write commands from your edge computing layer unless you have a very specific and audited need to
  • Isolate the gateway: the edge computing platform that processes CAN data should be on a separate network segment from external connectivity — a cellular modem’s IP interface should not bridge directly to the CAN-connected internal network
  • Log all CAN traffic: on-device storage of raw CAN frames enables forensic analysis if anomalous behaviour is detected; compressed CAN logs are compact enough to store months of data on a small SSD

UN Regulation ECE R155 (mandatory for new vehicle type approvals in the EU from mid-2024) requires OEMs to demonstrate cybersecurity management systems for vehicle connectivity, and this increasingly affects third-party telematics integrations.

Tools and Libraries

  • python-can: Python CAN interface library with SocketCAN, Kvaser, PCAN, and Vector hardware support
  • cantools: DBC/KCD/SYM file parsing and signal encoding/decoding
  • Wireshark with SocketCAN plugin: CAN bus traffic capture and protocol analysis
  • can-utils: Linux command-line tools for SocketCAN (candump, cansend, cansniffer)
  • EMQX Neuron: industrial IoT connectivity platform with native J1939 and CANopen protocol support
  • OpenDBC: community-maintained DBC files for common vehicle platforms

References