CAN Bus is a communication protocol widely used in the automotive and industrial fields, which enables multiple devices to interact on the same network. MQTT is a communication protocol widely used in the field of Internet of Things. As a lightweight publish-subscribe message transmission protocol, it effectively facilitates communication between machines.
By bridging CAN Bus data to MQTT, CAN Bus devices can be integrated with IoT platforms and applications. Although there are various solutions and tools on the market to achieve this goal, they usually only transmit raw binary CAN data, which makes filtering and processing the signal very inconvenient.
In this article, we will introduce a brand-new solution to flexibly extract meaningful data and required signals from CAN Bus by using the open source edge streaming SQL engine eKuiper, and realize the seamless bridge from CAN Bus to MQTT .
How the CAN Bus works
CAN Bus is a communication system that enables different devices in a vehicle to communicate data with each other. It also provides a lot of useful vehicle information such as speed, fuel level, engine temperature and diagnostic codes. However, obtaining and interpreting these messages from the CAN Bus is not an easy task as they are usually stored in binary form.
For an in-depth understanding of CAN Bus, welcome to read: Introduction to the CAN Bus Protocol of the Internet of Vehicles and Real-time Data Stream Processing
CAN frame
From the CAN Bus we can receive a stream of CAN frames containing the signal we are interested in in binary form. Each CAN frame contains ID, Data Length Code (DLC) and payload.
- ID is used to identify the type of data in the frame.
- DLC is used to specify the number of bytes of data in the frame.
- Payload is the actual data carried in the frame.
There are several CAN protocols with slightly different definitions of ID and payload length. Below is an example of a CAN 2.0A frame with an ID of 11 bits and a payload length of up to 8 bytes.
The payload consists of a sequence of signals. Each signal has a name, length and value.
- The length is the number of bits the signal occupies in the payload.
- Value is the actual data contained in the signal.
In order to convert binary data into meaningful information, we need to extract these signals.
signal extraction
A CAN database (DBC) is a text file that describes how the signals are organized in the CAN frame payload. It is equivalent to a dictionary, providing calculation methods for the name, length and value of each signal, so that we can communicate through CAN frames.
Below is a section of the DBC file. It defines a CAN frame with ID 544 and DLC 8. The frame contains 5 signals, each with a name, length and value. For example, the signal EngineSpeed has a length of 16 bits and a value range of 0 to 16383.75. The value of the signal is calculated by multiplying the raw data by 0.25 and adding 0.
BO_ 544 EMS_220h: 8 EMS
SG_ EngineSpeed : 0|16@1+ (0.25,0) [0|16383.75] "rpm" Vector__XXX
SG_ CurrentEngineTorque : 16|16@1+ (0.25,-500) [-500|1547.5] "Nm" Vector__XXX
SG_ DriverRequestTorque : 32|16@1+ (0.25,-500) [-500|1547.5] "Nm" Vector__XXX
SG_ CurrentEngineTorqueStatus : 48|1@1+ (1,0) [0|1] "" Vector__XXX
SG_ DriverRequestTorqueStatus : 49|1@1+ (1,0) [0|1] "" Vector__XXX
The decoding process of the CAN frame is as follows:
After decoding, we can know that the speed of the engine is 1000 revolutions per minute. However, if the signal is decoded by writing an application, once the signal changes or is updated, we must redevelop and deploy the entire decoding process and update it through OTA. Using eKuiper can save you such tedious work.
Protect your DBC
DBC is the key to decoding CAN frames. Even if CAN Bus data is leaked, it is almost impossible to decode without DBC. Therefore, the DBC is your valuable asset and should not be disclosed to anyone, including engineers involved in the development of the decoding. eKuiper can load the DBC file at runtime, thus avoiding it from being seen by the developer. Additionally, it can hot load DBC files without restarting the process when the scene changes. This helps protect your DBC files and keeps them private.
eKuiper "understands" CAN Bus data
As an edge streaming engine, eKuiper is very lightweight and can be deployed near CAN Bus devices. It can collect data from various southbound data sources such as HTTP, file system, MQTT, and the CAN Bus mentioned in this article. Collected data can be efficiently processed and published to northbound data sources such as MQTT and HTTP.
eKuiper has the ability to understand CAN Bus data. It simplifies the decoding of CAN frames and turns them into some configuration information. To process CAN Bus data, you can create a stream with the following SQL statement:
CREATE STREAM canDemo () WITH (TYPE="can", FORMAT="can", SHARED="TRUE", SCHEMAID="dbc")
This statement creates a stream named canDemo for fetching data from the CAN Bus. This statement also specifies the connection method and data format, and specifies the use of DBC mode to decode CAN frames into signals.
DBC settings
The DBC file acts as a schema when decoding CAN frames. Just like specifying a *.proto file for the protobuf format, you can specify a DBC file in the SCHEMAID attribute, which can be a file path or a directory path. This means that you can specify a single DBC file or a directory containing multiple DBC files. eKuiper will load all DBC files in the directory and use them as schemas.
At runtime, users can update DBC files by replacing files or adding new files to the directory. eKuiper can hot load DBC files and decode CAN frames with new modes by restarting the rules. This helps you protect your DBC file and keep it private.
Connection and Format Separation
In the statement that creates the stream, we set both typethe property and formatthe property to "can". This is because eKuiper separates the connection method and data format of the data source.
typeThe attribute specifies the connection method, CAN Bus in this case.formatThe attribute specifies the data format, in this case a CAN frame.
This separation enables eKuiper to support various combinations of CAN frames and transmission protocols, which is very common when using some CAN adapters. A CAN adapter may log CAN frames to a file, or send raw CAN frames to an MQTT Broker, or send CAN frames in batches over TCP or UDP. In these cases, typethe property will be "file" or "mqtt", and formatthe property will be "can".
If typeit is "can", eKuiper will connect to CAN Bus through socketCan. In the example below, eKuiper reads CAN frames from a file:
CREATE STREAM canDemo () WITH (TYPE="file", FORMAT="can", SHARED="TRUE", SCHEMAID="dbc")
Bridging CAN Bus to MQTT flexibly
CAN Bus devices periodically send messages on the bus at a high frequency (such as 100HZ). Due to memory or bandwidth constraints, we may only want to sample the data at a lower frequency and selectively preserve the signal. With eKuiper, we can:
- Data is sampled by specifying a sampling rate.
- Filter the data at the signal level by selecting the desired signal.
- Only bridge signals that change.
- Combine signals from different CAN frames into one message.
All of these functions can be implemented through rule SQL, and because of the ability to hot load rules, there is almost no cost to change. Let's look at some examples below.
## 过滤信号
SELECT EnginSpeed, DriverRequestTorqueStatus FROM canDemo
## 将不同 CAN 帧中的信号合并
SELECT latest(EnginSpeed) as speed, latest(anotherSignal) as anotherSignal FROM canDemo
## 只桥接发生变化的信号
SELECT CHANGED_COLS(EngineSpeed, DriverRequestTorqueStatus) FROM canDemo
Once we have the desired signal, we need to decide which MQTT topic to publish the data to. Users can specify a fixed topic name, or use a dynamic topic name derived from the data.
For example, in the rule below, each parsed CAN frame signal is bridged to an MQTT topic can/{
{CanId}}. {
{CanId}}It is a dynamic topic name derived from the data, for example, a CAN frame with CAN ID 123 will be bridged to the MQTT topic can/123.
{
"id": "distributeRule",
"sql": "SELECT *, meta(id) as canId FROM canDemo",
"actions": [
{
"mqtt": {
"server": "tcp://broker.emqx.io:1883",
"topic": "can/{
{.canId}}",
"sendSingle": true
}
}
]
}
eKuiper allows multiple rules to process the same flow. Therefore, users can create as many rules as needed to bridge CAN Bus data to different MQTT topics.
epilogue
To realize the bridging between CAN Bus and MQTT, our solution must be able to read data from CAN Bus devices, filter and transform the data according to requirements, and publish the data to MQTT Broker. That's where eKuiper comes in, providing an easy, efficient and flexible way to do the job.
In addition to the bridging function, eKuiper can also help in various scenarios of edge rule engine and edge computing. We will discuss these scenarios in detail in subsequent articles.
Copyright statement: This article is original by EMQ, please indicate the source for reprinting.
Original link: https://www.emqx.com/zh/blog/bridging-demanded-signals-from-can-bus-to-mqtt-by-ekuiper