L'année dernière, lors de la mise en place d'un système de gestion de flotte pour une entreprise de logistique, le client souhaitait un suivi en temps réel de la consommation de carburant, du régime du moteur et de la température du liquide de refroidissement pour chaque camion. Il ne voulait pas seulement que les données soient stockées localement, mais aussi qu'elles soient transmises en continu à la plateforme en nuage afin que les répartiteurs puissent contrôler l'état des véhicules.

Sounded straightforward enough. But once we got into it, pulling data from inside vehicles turned out way more complicated than expected. All vehicle information travels over CAN bus, but message formats vary wildly between vehicle models. Reading engine RPM from a FAW truck versus a Dongfeng truck means dealing with completely different CAN message IDs, data field positions, and conversion factors.

We ended up using a dual 5G vehicle gateway to crack this problem. The gateway connects to vehicle bus through CAN interfaces, parses all the messages, then uploads everything via 5G network to the cloud. That whole project gave me deep appreciation for how vehicle gateways and CAN bus need to work together.

What CAN Bus Does in Vehicles

Let’s start with what CAN bus actually is. CAN stands for Controller Area Network. Bosch designed this communication bus for automotive use back in the 1980s.

Why do we need CAN bus? Modern vehicles pack dozens or even hundreds of electronic control units. Engine ECU, transmission ECU, ABS ECU, instrument cluster ECU, body control ECU – the list goes on. These ECUs need to communicate. If you ran individual wires between every pair of ECUs, the wiring harness would be a nightmare.

CAN bus connects all ECUs to one shared bus. Think of it like a subway line – all the stations sit on the same route. Any ECU can send messages that all other ECUs receive. Each ECU selectively processes messages relevant to its function.

Commercial vehicles typically run 2-3 separate CAN buses. The powertrain CAN connects engine, transmission, ABS and other drivetrain ECUs, usually running at 500 kbps or 250 kbps. Body CAN handles lights, locks, climate control and comfort systems, typically at 125 kbps. There might also be a dedicated diagnostic CAN bus.

Vehicle gateways need to tap into these CAN buses to read data. Take the SV910 for example – it comes with 3 CAN ports that can simultaneously connect to multiple vehicle CAN buses.

The Process of Reading CAN Data

 

 

How exactly do you read this data? Let’s walk through reading engine RPM as an example.

Step one is physical connection. Connect the gateway’s CAN interface to the vehicle’s OBD diagnostic port or directly to the CAN bus. Commercial vehicles generally have standard OBD ports, usually located below the dashboard or next to the driver’s seat. The connector is trapezoidal with 16 pins.

CAN bus uses differential signaling with two wires: CAN_H and CAN_L. On the OBD connector, pin 6 is CAN_H and pin 14 is CAN_L. The gateway’s CAN interface has corresponding wires – just match them up. Important note: CAN bus ends need 120-ohm terminating resistors to prevent signal reflection. Some gateways integrate terminating resistors internally, configurable through software.

Step two is configuring baud rate. CAN bus communication speed must match or you won’t receive any data. Commercial vehicle powertrain CAN typically runs at 250 kbps or 500 kbps – you need to verify first. Check the vehicle service manual or test with a professional CAN analyzer.

Configure the gateway’s CAN interface to the same baud rate. Gateways like the SV910 support multiple baud rates, adjustable through configuration files or management interfaces.

Step three is monitoring and parsing CAN messages. CAN bus data transmits as frames. Each frame contains several parts: message ID, data length, data content, checksum.

Message ID is the key to identifying what each message contains. For engine RPM, standards like GB/T 27930 and SAE J1939 define the IDs. J1939 is common for commercial vehicles – engine RPM uses ID 0x0CF00400, with data in bytes 4 and 5.

The gateway continuously monitors the CAN bus, captures frames with specific IDs, then extracts RPM values from the data bytes. The extracted value is raw data that needs conversion to actual RPM using a formula. In J1939 standard, engine RPM resolution is 0.125 rpm/bit, so multiply the raw value by 0.125 for true RPM.

Step four is packaging and uploading data. After parsing the RPM value, the gateway packages it into appropriate format for uploading via 5G network to the cloud. Common formats include JSON, Protobuf, and MQTT messages.

Upload frequency depends on requirements. Real-time monitoring might need updates every second, while general fleet management could use 10 or 30 second intervals. Higher frequency means higher data costs.

The Challenge of Different Vehicle Models

 

Sounds simple in theory. Reality is that adapting to different vehicle models causes the biggest headaches.

National standard GB/T 32960 defines data formats for new energy vehicles, but only covers EVs. Traditional fuel-powered commercial vehicles mostly follow SAE J1939 standard, yet specific implementations still vary.

Even trickier, many automakers use proprietary CAN messages beyond standard definitions. Some brands put fault codes and maintenance reminders in private messages with undocumented formats. Reading that data requires reverse engineering or getting technical documentation from the automaker.

During projects, we adapt to each vehicle model individually. First collect CAN protocol documentation for that model. If documentation isn’t available, use a CAN analyzer to record bus data and manually analyze message formats. Then configure corresponding parsing rules in the gateway.

Gateways like the SV910 support flexible configuration. You can define custom parsing rules, specifying which bytes in which message ID represent what data and what conversion formula to apply. Different vehicle models just need different configuration files, no code changes required.

We built a vehicle model database storing CAN protocol configurations for different brands and models. New projects start by checking if configurations already exist. If not, we adapt once then add it to the database. The library now holds configurations for forty to fifty vehicle models.

Ensuring Real-Time Performance and Data Accuracy

Reading CAN data with vehicle gateways demands good real-time performance. Especially in autonomous driving or ADAS scenarios, data delays can impact safety.

CAN bus itself has very low latency, measured in microseconds. But gateway processing, packaging, and uploading add extra delay. How to control this?

First, minimize processing steps. After receiving CAN frames, parse immediately in interrupt handlers or high-priority tasks instead of queuing. Once parsed, put directly into transmission buffer and send via 5G network.

Second, use hardware acceleration. Some advanced vehicle gateways integrate CAN controllers with hardware filtering. Configure filter rules at hardware level to only accept message IDs of interest, discarding others. This reduces CPU load and increases processing speed.

Third, manage timestamps carefully. Each CAN frame should get a timestamp immediately upon gateway reception. This timestamp needs microsecond precision. Data uploaded to the cloud should carry this timestamp so the cloud knows when data was collected.

The SV910 supports PTP/GPTP time synchronization protocols, ensuring high-precision clock sync between the gateway and other devices. Critical for scenarios requiring multi-device coordination.

Data accuracy must also be guaranteed. Though CAN bus has built-in error checking, occasional corrupt data still appears. Gateways need secondary validation. For engine RPM, normal operation can’t suddenly jump from 1000 to 5000 rpm and back. Flag such anomalous data as suspect rather than using it directly.

Handle bus silence situations too. If a certain message hasn’t been received for extended periods, the corresponding ECU might have failed or the bus got disconnected. Gateways must detect this condition and report the anomaly.

Advantages of Dual 5G Architecture

The SV910 features dual 5G architecture with two 5G modules. Why dual 5G?

First reason is redundancy backup. Commercial vehicles on long-haul routes may pass through areas with poor signal. With single 5G, signal loss means no data transmission. Dual 5G uses SIM cards from different carriers – China Telecom and China Unicom, or China Mobile and China Unicom. When one signal degrades, switch to the other.

Switching can be automatic. The gateway monitors signal strength and latency on both 5G links in real-time, using whichever has better quality. Or use both links simultaneously for link aggregation, doubling bandwidth.

Second reason is traffic distribution. Vehicle applications typically involve multiple data streams – CAN bus data, camera video, positioning data, V2X communication. These data types have different characteristics and different bandwidth/latency requirements.

Route critical control data through one 5G link, high-traffic video through the other. This prevents interference and ensures real-time delivery of critical data.

Third reason is security isolation. Some fleet management platforms require physical separation between vehicle control channels and data collection channels for security. Dual 5G satisfies this requirement perfectly. Control commands use dedicated links, collected data uses another. Even if hackers compromise the data channel, they can’t tamper with control commands.

Integration with Fleet Management Platforms

After collecting data, vehicle gateways upload to fleet management platforms. Platforms are typically cloud services providing vehicle monitoring, route playback, statistical reports, fault warnings, and other functions.

Several protocol options exist for data upload. MQTT is most common. It’s a lightweight message queue protocol designed specifically for IoT. Gateways act as MQTT clients, connecting to cloud MQTT servers and publishing messages periodically.

MQTT supports different QoS (Quality of Service) levels. QoS 0 is at most once – fire and forget, possible loss. QoS 1 is at least once – guaranteed delivery but possible duplicates. QoS 2 is exactly once – guaranteed delivery without duplication. Choose appropriate QoS based on data importance.

HTTP/HTTPS is also widely used. Gateways periodically package collected data and upload via HTTP POST requests to cloud APIs. This approach is simple and direct with good compatibility. Downside is HTTP overhead exceeds MQTT, less suitable for high-frequency small data transmission.

Some specialized protocols exist too. For example JT/T 808 is the Ministry of Transport’s standard communication protocol for road transport vehicle satellite positioning system terminals. Many commercial vehicle fleet management platforms use this standard. Supporting JT/T 808 requires implementing the complete protocol stack.

Data format needs agreement with the platform. JSON is common – human-readable and easy to debug. But JSON takes up space, so if data costs are sensitive, use binary formats like Protobuf or custom compact formats.

Implementing Diagnostic Functions

Beyond reading real-time data, vehicle gateways can perform diagnostics.

Vehicle ECUs generate diagnostic trouble codes (DTCs). When the engine malfunctions, it produces codes like P0001, P0002. These codes store in ECUs and can be read via CAN bus.

Standard diagnostic protocols are ISO 14229 (UDS – Unified Diagnostic Services) and SAE J1939-73. The gateway acts as diagnostic client, sending diagnostic requests to ECUs, which return fault codes and related information.

After reading fault codes, translate them into readable descriptions. What does P0001 mean? Fuel volume regulator control circuit/open. This translation requires a fault code database. Gateways can store descriptions for common codes internally, or upload to the cloud for translation.

With fault codes, fleet management platforms can provide early warnings. For instance, detecting a coolant temperature high code immediately notifies drivers and maintenance departments, preventing engine overheating damage.

Advanced applications perform predictive maintenance. Analyze trends in various vehicle parameters to predict potential failures. For example, gradual engine oil pressure decline hasn’t triggered fault codes yet but shows warning signs – prompt drivers to check oil.

Lessons from Real Projects

After numerous projects, we’ve hit plenty of snags.

First lesson: protect the CAN bus properly. Vehicle CAN bus is critical. If gateway failures pull the bus low or transmit erroneous messages, normal vehicle operation could be affected.

Gateway CAN interfaces need electrical isolation to prevent fault propagation. Bus protection circuits should automatically disconnect during overvoltage or overcurrent. Software also needs protection mechanisms – stop transmitting if anomalies detected to avoid bus interference.

Second lesson: vehicle modifications must comply with regulations. Installing vehicle gateways on commercial vehicles constitutes vehicle modification. Must meet national and local regulatory requirements without compromising vehicle safety performance. Some regions require registration with vehicle administration after modifications.

Third lesson: data security and privacy protection matter greatly. Vehicle driving routes and behavior involve privacy. Encrypt data transmission, anonymize storage. Cloud platform access needs permission controls – can’t casually leak to third parties.

Overall, reading vehicle data through CAN bus with vehicle gateways forms the foundation of connected vehicle applications. The technology itself isn’t complex, but doing it well requires attention to many details. Adapting different vehicle models, ensuring real-time performance, data accuracy, communication reliability – every aspect needs careful refinement to provide stable, reliable service.