Author: Tian Zhen, former platform architect of SAIC Volkswagen, is now in charge of cloud technology of Zhongke Chuangda Automobile

preface

In the ecosystem of Internet of vehicles, TSP (Telematics Service Provider) platform plays a core role in the industrial chain. It is the core data connection platform for oEMS ‘vehicles and services, connected with automobile and vehicle equipment manufacturers and network operators, and connected with content providers. With the development of intelligent vehicles and the continuous improvement of the demand for application scenarios by the owners, the demand for equipment and application carrying capacity of TSP platform by oEMS will continue to increase.

In the previous article “MQTT Protocol in The Internet of Vehicles”, we mentioned that in the choice of data interaction protocol between vehicle equipment and TSP platform, MQTT is lightweight, easy to expand, and has a variety of message quality assurance (QoS). As well as the release and subscription model to achieve data generation and data consumption system decoupling and other advantages become the current major OEMS of the new generation OF TSP platform preferred protocol.

In this paper, we will introduce how to design MQTT message theme in the construction process of TSP platform of Internet of vehicles.

Requirements for message channels in the TSP scenario of the Internet of vehicles

In the TSP scenario of the Internet of vehicles, MQTT protocol serves as the business message channel between “vehicle-platform and application”, which not only ensures the two-way communication between vehicles and applications, but also identifies and distributes messages of different types through certain rules. Topics in the MQTT protocol are labels for these messages, which can also be considered business channels.

In the scenario of Internet of vehicles (IOT), messages can be divided into data ascending channel from vehicle to platform to application and data descending channel from application to platform to vehicle. For the TSP platform of the Internet of vehicles, different data directions imply different business types, which need to be clearly distinguished and isolated through MQTT topics.

  • From the end of the car:

    Vehicle data reporting is the main business type of uplink data in TSP platform. With the continuous enrichment of Internet of vehicles (IOT) services, the computing and communication capabilities of vehicle systems such as T-box are constantly enhanced, and the business scenarios, data volume and frequency of vehicle data reporting are also increasing. Based on the needs of business isolation, real-time and security, the Internet of vehicles has gradually developed from one vehicle to one vehicle with multiple message channels.

  • From the application side:

    As the receiver and consumer of vehicle data, the platform application also acts as the message sender of data delivery and instruction delivery. According to service requirements, message sending types can also be classified as follows:

    1. One-to-one message: For some businesses with critical business and high security requirements, such as car control 㩐, one-to-one message channel needs to be provided for each car.
    2. One-to-many message: for a certain type of business or a certain type of vehicle, instructions and data can be delivered to the vehicle and machine equipment through the same theme channel.
    3. Message broadcast: For large-scale message notification, you can configure the update scenario to send large-scale message broadcast to devices connected to the platform.

What is the subject of the MQTT protocol

Basic concept

There are three roles in the MQTT protocol communication mechanism: publisher, broker and subscriber. Messages are sent from the publisher to the proxy server and then received by the subscriber, and the topic is the agreed message channel between the publisher and the subscriber.

A publisher sends messages on a topic, a subscriber receives messages from a specified topic subscription, and the Broker acts as an agent to receive and distribute messages by topic. In the TSP platform scenario of the Internet of vehicles, on-board devices, mobile terminals and business applications can all be regarded as MQTT clients. The roles of vehicle-mounted devices, mobile terminals, and service applications also switch between publishers and subscribers based on services and data directions.

Definition and specification of topics

The MQTT protocol defines that the topic is a UTF-8 encoded string. The topic must meet the following rules:

  • All topic names and topic filters must contain at least one character.
  • The topic name and the topic filter are case sensitive. For example: ACCOUNTS and ACCOUNTS are different subject names.
  • Topic names and topic filters can contain space characters. Accounts payable is a legitimate subject name
  • The topic name or topic filter is distinguished by a leading or trailing slash /. / Finance is different from finance.
  • A theme name or theme filter containing only a slash/is valid.
  • Topic names and topic filters cannot contain null characters (Unicode U+0000).
  • Topic names and topic filters are UTF-8 encoded strings, and there is no limit on the number of levels of topic names or topic filters other than the utF-8 encoded string length limit.

Topic hierarchy

MQTT protocol topics can be divided into multiple levels by a slash (“/” U+002F); As a message channel, the client can subdivide message types by defining a topic hierarchy.

For example, an OEM has multiple models, and each model has multiple Internet of vehicles businesses. We can send messages to < model A>/ < unique identifier of the vehicle >/< business X> when defining the vehicle and vehicle direction to send messages to the business system of A certain model.

In the MQTT world, of course, themes can have many levels (there is no limit on the number of levels in the MQTT protocol), such as: < model A>/< unique vehicle identification (frame number)>/< business X>/< subbusiness 1>

In this way, we can design according to the topic level when defining the hierarchical business channels of the Internet of vehicles.

The wildcard

The topic filter for a subscriber’s subscription in the MQTT protocol can contain special wildcards that allow clients to subscribe to multiple topics at once.

  • Multilevel wildcards

    The # character number (” # “U+0023) is a wildcard used to match any level of the topic. A multilevel wildcard represents its parent and any number of child levels. Subscribers can receive by subscribing to < model A>/# :

    A > < model

    < model A>/< Frame No. 1>

    < model A>/< frame No. 1>/< business X>

    Messages on these topics.

  • Single-layer wildcard

    The plus sign (” + “U+002B) is used as a wildcard for a single subject-level match. For example: Subscribers can receive by subscribing to < model A>/+

    < model A>/< Frame No. 1>

    < model A>/< Frame No. 2>

    Unlike multi-level wildcards, single-level wildcards cannot match sub-level topics, such as < model A>/< frame number 1>/< business X> subject messages cannot be received.

Internet of Vehicles TSP platform theme design principles best practice

As mentioned above, MQTT theme defines the channel between business and data in the scenario of Internet of vehicles. The core of theme definition is to distinguish business scenarios. How to define a theme reasonably needs to be designed according to certain principles. We can design and define themes from the following dimensions:

Based on service data direction

First, the different upstream and downstream directions of data determine who produces and consumes the data. In the scenario of the Internet of vehicles, the uplink data channel of vehicle-mounted equipment to the platform and the downlink data of the platform to the vehicle need to be separated through the theme. Differentiating upstream and downstream themes helps designers, O&M, and business personnel quickly locate scenarios, problems, and stakeholders.

Some businesses may use both upstream and downstream themes at the same time, such as the data delivered by the platform after the vehicle application data is delivered, and the data reported by the vehicle after the platform requests the vehicle working data. In this case, due to the asynchronous communication mechanism of the MQTT protocol, the upstream and downstream topics of an overall business also need to be defined separately.

By vehicle type

In the scenario of Internet of vehicles, different models mean different data generated by vehicles, different capabilities of vehicles and machines, and different business applications for docking. We can thematically distinguish differentiated vehicle data and business based on model type. Of course, different models under the same OEM will also have the same business and data, which can be defined by themes across models.

By vehicle

In Internet of vehicles scenarios, business scenarios with high security levels such as car control often require one-to-one topics as data gateways. On the one hand, themes are used to isolate business information from vehicle to vehicle, and on the other hand, data can be interoperated point-to-point. In theme design, it is sometimes necessary to implement one-to-one message channels with the unique identifier of the vehicle as part of the theme. Common scenarios include using the vehicle VIN code as part of the theme.

Differentiate by user

In actual usage scenarios, there are also one-to-one messaging channels that need to be implemented for car cloud based on users (rather than vehicles). Such requirements often occur in user promotions, operations, AND ToB business scenarios. In theme design, there are two common schemes: one is to use user ID as part of the theme; Second, the theme is converted into vehicle-level theme through human-vehicle relationship. However, due to message timeliness and in-car user login status, both the production end and the consumer end need to add additional design and processing under this scheme, which is relatively complicated.

According to the r&d environment

From the perspective of project implementation, environment variables are generally added during theme design to realize resource reuse and correctness check in different RESEARCH and development environments through configuration.

By data throughput

Due to different services, the transmission frequency and packet size of upstream and downstream data vary. Different data throughput will affect the consumption of the processing and architectural design, such as we in dealing with a high frequency of vehicle data reporting business often want to consider the consumption ability of application layer, this time may be with the help of a high throughput like Kafka message queue for data buffer, to prevent the consumer is not timely data backlog and loss of data. So in the DEFINITION of MQTT topics, we often also need to distinguish between businesses with different data throughput.

Application of MQTT protocol theme design in Internet of Vehicles scenario

Active reporting of vehicle data

Vehicle-mounted equipment (T-box, vehicle-mounted machine, etc.), as the collector of vehicle operation data, packages various controllers, sensors and other data in the vehicle based on fixed frequency and sends them to the platform. Such data can be designed in accordance with multiple levels, such as vehicle type, frame number and business data type.

For example, with the consent of the user, the vehicle will report the location, speed, electric quantity and other information to the cloud platform at a fixed frequency during the driving process. Based on these data, the cloud application provides the services of location search, overspeed reminder, electric quantity reminder and geographical fence to the end user.

Report vehicle data after platform request is delivered

When the cloud platform needs to obtain the latest status and information of the vehicle, it can proactively issue commands requiring the vehicle to report data. Such scenarios can generally be designed according to the hierarchy of frame number, business type and so on.

For example, in the diagnosis scenario, the platform issues the diagnosis command to the vehicle through MQTT. After all the devices in the vehicle complete the diagnosis operation, the diagnostic data will be packaged and reported to the cloud platform. The vehicle diagnosis engineer will analyze the vehicle condition and locate the problem according to the collected diagnosis data.

Platform order delivery

Remote control of vehicles is the most common and typical scenario in the Internet of vehicles business. Various Oems provide various remote control functions in mobile phone apps, such as remote start, remote start door, remote flashing light and whistle, etc. In such scenarios, the mobile phone App sends control commands to the cloud platform, and the platform application delivers the commands to the vehicle for execution through MQTT after a series of operations such as permission check and security check. After successful execution, the vehicle will asynchronously inform the platform of the execution result.

Such scenarios can be designed in accordance with multiple levels, such as uplink and downlink, frame number, business type and operation type.

The platform data is delivered after the vehicle client requests it

In SDV (software defined cars), against the background of the car to the dynamics of many configurations can be achieved, such as data acquisition rules, security access rules, so the vehicle after the ignition starts, will take the initiative to request the latest related configuration platform, if both sides configuration, platform may be issued by the latest configuration information to the vehicle, vehicle lateral immediate effect.

Such scenarios can be designed in accordance with multiple levels, such as uplink and downlink, frame number and business type.

EMQX was used to design the TSP platform theme for the Internet of vehicles

EMQX as the world’s leading MQTT iot message middleware, based on the distributed clusters, large-scale concurrent connections, fast, low latency of message routing and other outstanding features, able to deal effectively with car networking scenario high timeliness business requirements, greatly shorten end-to-end delay, for large-scale car networking platform for rapid deployment MQTT provide standard services.

Advantages of EMQX in the scenario of Internet of vehicles

Massive theme support

With the continuous increase of services in the Internet of vehicles scenario, the number of themes carrying the business channel also increases, especially the demand for one vehicle with one theme and one vehicle with multiple themes required by the car control scenario is increasing. In this context, the topic number carrying capacity of MQTT server becomes an important evaluation indicator of TSP platform.

EMQX’s ability to support a large number of device connections and a large number of topics was planned in the underlying design from the very beginning. The common 16-core 32GB 3-node EMQX cluster can support millions of themes running at the same time, providing flexible design space for TSP platform theme design.

Powerful rules engine

EMQX provides a built-in rules engine that provides lookup, filtering, data fragmentation, and message re-routing for different topic data. Using the rule engine, we can reprocess the data in the existing theme by creating new routing rules and data preprocessing rules in the scenario where the existing vehicle equipment and application theme have been established. After the vehicle is launched, new business applications are supported by defining new rules on the platform side.

In EMQX Enterprise edition, the rules engine provides data persistence docking capability, which allows data from different topics to be directly connected to different persistence schemes through configuration in the rules engine. For example, the data with high data throughput can be buffered by the rule engine docking Kafka, Apache Pulsar and other high throughput message queues. However, vehicle alarm and other low-throughput and low-delay subject data can be directly connected to the application to realize the fast routing consumption of data.

Proxy subscription function

EMQX provides the proxy subscription function. When the client establishes a connection, it does not need to send an additional SUBSCRIBE message to automatically establish a preset subscription relationship. In this way, the platform side can directly manage the topic subscription relationship of vehicle-mounted devices, which is convenient for unified management on the platform side.

Rich topic monitoring with slow subscription statistics

EMQX Enterprise edition provides topic-specific running data monitoring. You can clearly see the total number of incoming and outgoing messages, discarded messages, and current rates in the EMQX Visual Dashboard under a topic.

Since version 4.4, EMQX has provided statistics on slow subscriptions. This function will track the time consumption of QoS1 and QoS2 messages after they arrive at EMQX and complete the whole process of message transmission, and then calculate the average message transmission delay of the subscriber by using the exponential moving average algorithm, and then statistically rank the subscribers according to the delay.

By constantly monitoring the data reception and consumption of various topics during the operation of the TSP platform, the platform operator can constantly adjust the platform business design and application design according to the business changes, and realize the continuous optimization and expansion of the platform.

Points to note

When we use EMQX as MQTT Broker of TSP platform for Internet of vehicles, we need to pay attention to the following issues in the design process:

  • Wildcards are used with subject number hierarchy

    Because EMQX uses the data structure of topic tree to filter and match topics. In scenarios where wildcards are used to match multiple topics, a large number of topic hierarchies can be a significant resource drain on EMQX. Therefore, when designing a theme, it is not recommended to have too many levels, generally not more than 5 levels.

  • Topics and memory consumption

    Since the number and length of topics in EMQX are mainly related to memory, we should focus on monitoring the memory usage of EMQX cluster while hosting a large number of topics.

conclusion

With the widespread use of MQTT protocol in the Internet of vehicles (IOT) business, the design of MQTT message theme on THE TSP platform of IOT will be a subject that oems and TSP platform solution providers must face. This paper is a multi-dimensional summary of MQTT theme design ideas for Internet of vehicles business based on our years of TSP platform construction experience, hoping to provide some help and inspiration to colleagues in the industry in the early stage of platform design and business expansion.

Copyright: EMQ

Original link: www.emqx.com/zh/blog/mqt…