With the development of smart vehicles, the functional scenarios and data volume of vehicle-cloud communication are gradually increasing. The MQTT protocol, characterized by its lightweight and reliability, has become a choice for many OEM vehicle-cloud communication protocols. This article mainly introduces the design of vehicle-cloud communication based on the MQTT protocol.
What is MQTT?
MQTT (Message Queuing Telemetry Transport) is an application layer protocol published by OASIS, utilizing a publish/subscribe communication model, with transmission based on TCP/IP. This standard is widely used in industrial IoT, vehicular networks, and other fields.
MQTT has the following main characteristics:
-
Publish/Subscribe Model: Achieves decoupling between Clients
-
Lightweight: Very small communication overhead, with a minimum message size of 2 bytes
-
Reliable: Based on TCP for reliable communication, and can provide three levels of Quality of Service (QoS) for message publishing to meet the transmission needs of unstable networks
-
Open Source: There are many open-source code projects available, supporting various popular programming languages, with high maturity
MQTT involves two roles during communication: Client and Broker:
-
Client: The MQTT client, a node that interacts with application data, where the role of publishing data is the Publisher, and the role of receiving data is the Subscriber
-
Broker: The MQTT server, which relays communication data, forwarding application data received from the Publisher to the Subscriber
The communication process of MQTT: The Subscriber subscribes to data from the Broker in the form of a Topic, while the Publisher publishes application data to the Broker in the form of a Topic. The Broker receives the Topic sent by the Publisher and then sends it to the Subscribers that have subscribed to the relevant Topic, thus achieving communication between the Publisher and Subscriber.
Figure 1: MQTT Communication Diagram
MQTT System Design
The typical application scenario of the MQTT protocol in vehicle communication is vehicle-cloud communication. Therefore, this article uses the communication scenario between in-vehicle nodes and the cloud as an example to introduce the main processes and methods of MQTT system design.
Figure 2: MQTT System Design Process
The design of the MQTT system relies on the prior completion of vehicle-cloud UC (Use Case) descriptions, communication matrices, in-vehicle topology, and cloud architecture deployment as inputs. Based on the characteristics of MQTT, the communication design is completed, with the main output being the MQTT communication matrix based on specific vehicle models or platforms. Development engineers on both the vehicle and cloud sides need to complete relevant software development based on the design output, and testing engineers also need to conduct MQTT testing and validation work based on the design output.
The design of the MQTT communication system involves the following aspects:
-
MQTT Role Design: Deploying roles for communication nodes based on functional requirements
-
Topic Design: Defining and determining the number of Topics
-
Data Type Design: Specifying the information to be transmitted for each Topic
-
QoS Design: Matching QoS policies to Topics
MQTT Role Definition
Based on the characteristics of the MQTT protocol, it is necessary to first clarify the MQTT roles of each node in the vehicle-cloud communication topology.
Since the data that needs to be exchanged between nodes must pass through the Broker, the server with better performance is generally deployed as the Broker in the cloud, while the nodes in the vehicle that need to communicate with the cloud are Clients, and nodes such as cloud backends/apps are also Clients.
Figure 3: MQTT Role Deployment
Topic Design
Nodes within the MQTT system interact with application data using Topics. The division of Topics can be based on data content or functional aspects, for example, vehicle condition upload data in one Topic, and remote vehicle control data in another Topic.
In addition, the design of MQTT Topic names should also follow certain principles, such as: the naming length should not exceed 65535 Bytes, it is recommended to adopt a unified naming convention, and hierarchical division should be done using the delimiter “/”. For example, for vehicle condition upload data for a specific platform, the Topic can be designed as: {vehicle_platform}/{vehicle_model}/{ECU}/vehicle_info/{vin}/up.
Data Type Design
The maximum transmission data supported by a single MQTT frame is 256M Bytes, so data that requires transmission exceeding this size is not suitable for MQTT.
The MQTT data format is not strictly defined, as long as both parties use a unified encoding/decoding rule, JSON data format is commonly used. The application data information to be transmitted is described using “key-value” pairs, where the definition of the key and the data type of the value need to refer to the communication matrix within the vehicle, maintaining consistency.
The advantage of using JSON format is that it only requires both parties to have a consistent understanding of the same key, and there are no strict requirements on the arrangement order of the “key-value” pairs. If there is a need for expansion, new “key-value” pairs can be directly added, and the “key-value” pairs are optional, allowing for sending or not sending based on time/event situations without the need for additional protocol layer strategies, providing high compatibility and flexibility.
Figure 4: Topic Data Definition
QoS Design
MQTT has QoS policies to ensure communication service quality under different circumstances, so it is necessary to design matching QoS policies for different data Topics based on functional scenario requirements. The overall principles are as follows:
-
For scenarios with high real-time requirements, where some frame loss is acceptable, QoS is recommended to be designed as 0, such as for periodically uploaded data used for real-time display
-
For scenarios where frame loss is not allowed and retransmission is acceptable, QoS is recommended to be 1, such as for signals confirming whether commands sent from the cloud are received normally
-
For scenarios with strict transmission requirements (no frame loss, no retransmission allowed), QoS is recommended to be 2, such as for safety-related data
Conclusion
This article first introduced the MQTT protocol, and then discussed the MQTT system design process and methods from the perspectives of MQTT role design, Topic design, data type design, and QoS design. Development engineers for vehicle ECUs and cloud systems need to complete subsequent software development based on the outputs of the MQTT system design to realize communication for vehicle-cloud functionalities.
As a member of the OPEN Alliance and a senior partner of the AUTOSAR Alliance, HIRAIN has long provided design and testing consulting services covering TCP/IP, SOME/IP, DoIP, AVB, TSN, DDS, and other technical fields for major OEMs and suppliers both domestically and internationally. HIRAIN actively researches and explores cutting-edge technologies in vehicle networks. Through practical experience from multiple projects, HIRAIN has established high-quality, localized integrated design and testing solutions to provide reliable support for vehicle network architecture.
Monthly Recommendation Plan
Contact Us
Official WeChat｜hirain_training
Phone｜16619945560
Email｜[email protected]