Evolution from “Data Acquisition Device” to “Vehicle Communication Hub”

If you’re working on connected vehicle, fleet management, or intelligent vehicle projects, you’re likely familiar with the term CAN gateway. However, many people only understand its function as “collecting CAN data . ” A CAN gateway acts as a ” translator ” connecting different communication networks , primarily used in the automotive and industrial sectors to convert and transmit data between the CAN bus and other networks ( such as Ethernet, other CAN buses, etc.) .
A CAN gateway is more than just a “data collector”; it’s the crucial node that makes the vehicle’s underlying data truly usable.

First, let’s clarify one thing: why can’t we “directly connect to CAN”?

Many people’s first encounter with vehicle data acquisition has an intuitive feeling: there is a CAN bus in the car, can’t we just connect to it and read the data?

It’s not that simple, for several reasons:

A vehicle often has more than one CAN bus. The engine, transmission, chassis, and body systems may each use a separate network, with data distributed across different buses, requiring integration first.

CAN messages themselves have no semantic meaning. What you see is a string of hexadecimal numbers. What does the data under the ID “0x7E8” mean? A parsing layer must translate it into usable data such as “vehicle speed”, “fuel consumption”, and “SOC”.

The CAN bus does not have networking capabilities. For data to be transmitted to the cloud, someone must be responsible for converting the CAN format into a format that can be transmitted via 5G/4G/Ethernet.

The data volume is large and the frequency is high. Thousands of unfiltered CAN messages can be generated per second. Uploading them all would waste bandwidth, and the backend simply couldn’t handle them all.

The controller does not proactively “report”. To obtain the desired data, you need to actively send a diagnostic request or filter messages with specific IDs according to rules.

These issues combined are the reason for the existence of CAN gateways—they take care of all the dirty and tiring work.

Six things that a CAN gateway actually does

If you break down the operation of a modern CAN gateway, it goes far beyond what can be summarized by the word “data acquisition”.

① Simultaneous acquisition of multiple CAN channels + in-depth analysis

In new energy vehicles, the BMS, powertrain, and body systems typically operate on different CAN buses; similarly, the door control, instrument panel, and air conditioning systems in buses each use their own networks. A gateway supporting 2-3 CAN channels can simultaneously monitor multiple buses, filtering, triggering, and reassembling messages—extracting only the data you need, thus reducing bandwidth pressure and lowering the burden on the backend.

② CAN→5G/Ethernet data bridge

Engineering vehicles need to upload their operational status, buses need to bind and upload access control status and video, and new energy vehicles need to push BMS status in real time. The CAN gateway converts this data from the closed bus inside the vehicle into a format that can be transmitted via 5G, 4G, or Ethernet, and sends it to the cloud platform.

Taking the Starlink SV910 as an example, it supports dual 5G modules and features a primary and backup link redundancy design, ensuring no disconnection in critical scenarios.

③ Multi-protocol fusion: Allows CAN data to flow into different systems

The vehicle-to-everything (V2X) platform uses MQTT, the monitoring platform uses HJ212, the dispatch system uses an HTTP interface, and map positioning requires NTRIP…

If the gateway itself does not have protocol processing capabilities, an additional “translation layer” must be developed for each system it connects to, which is inefficient and prone to errors. A CAN gateway that supports multiple protocols can directly connect to these systems, eliminating the need for an intermediate layer.

④ Time synchronization: The most crucial hidden capability of intelligent connected vehicles

In typical fleet management, a time error of tens of milliseconds might be negligible. However, in autonomous driving testing and vehicle-to-infrastructure (V2I) scenarios, data from cameras, radar, IMUs, and CAN buses must be timestamped for sensor fusion analysis.

CAN gateways that support TSN, IEEE 802.1AS (GPTP), and IEEE 1588v2 PTP can provide clock synchronization accuracy at the microsecond or even nanosecond level—which is already the standard for autonomous driving data collection vehicles.

This is why more and more projects are upgrading from “ordinary CAN gateways” to “high-specification communication gateways”.

⑤ Data Calculation: Reduce Backend Pressure

CAN gateways are no longer just “data transporters.” Gateways with sufficient computing power (such as a quad-core A55 processor + 2GB of memory) can perform data filtering, rule judgment, early warning recognition, and data cleaning locally on the vehicle side—only the data that actually needs to be uploaded goes through 5G, significantly reducing cloud pressure and communication costs.

⑥ Support large-scale fleet operation and maintenance

With hundreds of engineering vehicles and thousands of buses, it’s impossible to perform on-site maintenance on every single one. The CAN gateway must support remote configuration, remote firmware upgrades (FOTA), a logging system, and status monitoring. Combined with mechanisms such as a hardware watchdog and power-off log saving, this ensures the long-term reliable operation of the vehicles in complex environments.

The focus of the CAN gateway varies depending on the vehicle model.

While both are “CAN gateways,” they play vastly different roles in different car models:

Traditional gasoline-powered vehicles: The core requirement is to collect data on vehicle speed, fuel consumption, engine speed, and fault codes, and then upload this data to the fleet or monitoring platform. Latency requirements are not high, but stability and protection capabilities are crucial.

New energy vehicles: The focus is on high-frequency data from BMS, electric drive, and battery thermal management systems, which have higher requirements for latency and stability. In some scenarios, they also need to meet national standard reporting protocols (such as GB/T 32960).

Public buses and passenger vehicles: mainly used for event-triggered data collection—door opening and closing status, station announcement system, passenger information system, and linked with video transmission to build a complete operation chain.

Engineering vehicles: have extremely high requirements for equipment protection level, shock resistance and wide temperature range, and must work stably in environments with high dust, strong vibration and large temperature difference.

Autonomous driving test vehicles: The CAN gateway is used as a data hub, requiring nanosecond-level time synchronization and the integration of data from multiple sensors such as cameras, radar, and GNSS—something that ordinary CAN gateways cannot do, requiring high-specification equipment that supports TSN/GPTP/PTP.

Which direction is the CAN gateway heading?

With the widespread adoption of automotive Ethernet, 5G, V2X, and TSN technologies, the evolution trend of CAN gateways is already very clear:

It’s not about “replacing CAN,” but rather about deeper integration around CAN.

Future CAN gateways will need to be deeply integrated with automotive Ethernet, support more link redundancy, have higher precision clock synchronization, and even support AI edge analytics capabilities. The CAN bus itself will not disappear, but its “exit”—the CAN gateway—will become increasingly intelligent and important.

Ethernet gateways like the Starlink SV910, which already support dual 5G, TSN, V2X, and multi-channel CAN , are actually at the forefront of this evolutionary path. Rather than calling them “CAN gateways,” it would be more accurate to call them “vehicle communication hubs.”

Regardless of your vehicle type, as long as it involves data collection, networking, remote maintenance, or intelligent applications, the CAN gateway is the key player that allows in-vehicle data to truly “go out”.

It’s not just about “collecting CAN data”; it’s the first exit point for vehicle digitization.