foreword

The MQTT protocol has long been a well-deserved mainstream protocol in the field of Internet of Things. It has been widely used in the construction of Internet of Things platforms in many industries by virtue of its features such as lightness, efficiency, reliability and security , and two-way communication.  So what is the application of the MQTT protocol in the Internet of Vehicles scenario?

This article will start from the actual case experience of users in the EMQ Internet of Vehicles industry, compare the advantages and disadvantages of different Internet of Things communication protocols in the construction and application of the Internet of Vehicles platform, and share how enterprises should choose appropriate MQTT message access products and services based on their own conditions, and the current The most popular technical solutions in data transmission security, data integration, etc.

Is the MQTT protocol suitable for the Internet of Vehicles?

The entire Internet of Vehicles business structure is complex and involves multiple communication links. In this article, we discuss the cloud-end message access module that the Internet of Vehicles platform is mainly responsible for.

MQTT is an IoT communication protocol based on the publish/subscribe model. It is simple and easy to implement, supports QoS, and has small packets. It occupies half of the IoT protocol. In the Internet of Vehicles scenario, MQTT is still capable of flexible, fast, and secure access to massive vehicle-machine systems, and ensures the real-time and reliability of messages in complex network environments. Its main application advantages are as follows:

• Open message protocol, simple and easy to implement. There are a large number of mature software libraries and hardware modules on the market, which can effectively reduce the difficulty and cost of vehicle access;
• Provide flexible publish-subscribe and topic design, and can communicate messages through a large number of topics to deal with various Internet of Vehicles services;
• The Payload format is flexible and the message structure is compact, which can flexibly carry various business data and effectively reduce vehicle-machine network traffic;
• Provide three optional QoS levels, which can adapt to different network environments of vehicles and equipment;
• Provide online status awareness and session retention capabilities to facilitate the management of the online status of the vehicle and the offline message retention.

In summary, the MQTT protocol will undoubtedly bring convenience to the construction of the Internet of Vehicles platform if it is matched with message middleware products with massive vehicle-end connections, soft real-time, high concurrent data throughput, and multiple security assurance capabilities.

Compared with MQTT, what are the differences between other protocols?

So far, most car networking customers prefer the MQTT protocol. We have also encountered some customers who have chosen other protocols such as private TCP and HTTP, but from the final result, MQTT is the best choice in the car networking scenario.

Before touching the MQTT protocol, a large OEM in South China adopted the privatized TCP protocol (ACP protocol) to build a car networking service platform. After a long period of protocol specification design and development, the main functions of the Internet of Vehicles platform have been basically realized. However, with the continuous increase of Internet of Vehicles business scenarios and the continuous growth of the number of vehicles, the disadvantages of privatized TCP have gradually become prominent: the definition of protocol privatization and version maintenance are difficult, and all protocol functions (such as keep alive, disconnection and reconnection, Offline messages, etc.) all require custom development, and proprietary protocols also require custom development for terminal hardware adaptation, resulting in high costs, long cycles, and slow update iterations. With the continuous improvement of the MQTT protocol ecology and its widespread adoption in the selection of communication protocols for the Internet of Vehicles platform, the OEM began to adopt the MQTT protocol in the development of the new generation of Internet of Vehicles platform, based on the perfection provided by the EMQX Internet of Things access platform. The MQTT protocol support not only reduces the development cost and shortens the development cycle, but also realizes more functional scenarios and operation and maintenance methods.

A large OEM in East China currently has more than one million vehicles in stock. The previous Internet of Vehicles platform was built with a private TCP protocol. Facing the massive message communication of millions of vehicles, the private TCP protocol has high maintenance costs and reliable information. The performance is not guaranteed, and the daily system maintenance and function expansion development workload is heavy. With the widespread adoption of the MQTT protocol in the group's internal car networking platform, the OEM has also started the transformation and upgrading of the MQTT protocol. At present, some models have been upgraded through OTA upgrade. In the future, they plan to gradually complete the upgrade of all models in stages. Upgrading work.

Another car company customer contacted us early, but considering the simplicity of the initial business and the selection of its own technology, it finally used the form of self-built HTTP service to access the car machine. With the development of the business, the traditional request-response mode communication has been unable to meet the new business needs. At the same time, with the increase in the number of functions and terminals, the communication volume of the entire platform has increased exponentially, and the use of HTTP access has resulted in a performance bottleneck. The customer finally chose MQTT as the access protocol, and used the data access solution provided by EMQX to solve the previous business problems.

In general, private protocols are characterized by closedness and exclusivity. They are designed to solve specific problems in the early stage of formulation, resulting in a lack of flexibility. It is often difficult to meet new needs after business adjustments. Enterprises have to add more protocols to the protocol. feature; or because of the increase in access volume, the server side of the private protocol prematurely reaches the bottleneck of performance and scalability. The above-mentioned reasons eventually lead to the shift of the user's focus from business development to the development of access layer and middleware, which increases the cost of platform projects virtually. Therefore, the MQTT protocol has naturally become the most suitable mainstream protocol in the field of car networking.

How to choose MQTT message access products/services?

In platform design, system architecture design and product selection are a rigorous process. Users must first evaluate whether the product functions meet business needs, whether the performance and scalability can support the short-term design capacity of the platform and possible future growth in combination with application scenarios; the cost of product use is also an important consideration, the cost of the product itself, IaaS foundation Facilities, development integration, and maintenance work will all affect the total cost of ownership of customers; in addition, it should be evaluated in conjunction with the product's globalization capabilities. For projects with overseas business, whether the product can support global deployment, whether it can meet the compliance of various regions, Whether it can avoid cloud computing provider lock-in these are the basis for choosing products.

EMQ's IoV customers often compare with cloud computing providers' IoT message access SaaS services during the model selection process. In contrast, EMQX's advantages mainly lie in private deployment and standardization capabilities - it supports private deployment to any cloud platform, without platform lock-in, and provides standard MQTT protocol, which is also a point commonly valued by Internet of Vehicles customers.

Avoiding cloud computing vendor lock-in helps enterprise users gain a competitive advantage, and can reduce the impact of companies suspending partnerships with cloud computing vendors. On the other hand, multi-cloud support can also make full use of the technical and commercial advantages of different cloud computing providers. For example, some companies operating globally can choose different cloud computing providers at home and abroad.

In addition, a considerable number of customers value the lower usage cost of EMQX. The fundamental reason is that due to different billing methods, the larger the business scale, the higher the access service cost of the cloud computing provider.

However, there are exceptions in terms of cost. Before, after evaluating the cloud provider's access service and EMQX, some car company users finally gave up private deployment and chose the cloud provider's access service after considering their own operation and maintenance costs and risks. With the launch of EMQ's fully managed MQTT messaging service - EMQX Cloud, this problem has also been resolved. Through EMQX Cloud, users can now avoid the burden of infrastructure management and maintenance, while maintaining the advantages of clear and controllable cost budget consistent with private deployment, cross-cloud and cross-platform, etc., and carry out the construction of the Internet of Vehicles platform without worries.

For customers with private deployment needs, EMQX also has its own unique advantages. EMQX provides global commercial support, high product performance can bring massive connection and throughput capabilities, and rule engine and data bridge provide rapid integration capabilities. At the same time, in the field of Internet of Vehicles, the highly reliable and easy-to-expand architecture capability and the V2X information interaction capability of cloud-side integration also make EMQX stand out among similar products that support private deployment.

In 2018, when SAIC Volkswagen was designing and developing a new generation of IoV system, the SC department took into account the scenario requirements of large concurrency, low latency, and high throughput of the new IoV, and referred to the mainstream new IoV system architecture at home and abroad, and finally adopted the MQTT-based system. Agreement to build a new generation of car networking platform.

In this project, the features of MQTT and EMQX's powerful rule engine data integration capabilities and general-purpose bus capabilities effectively meet the customer's requirements for real-time reliability of messages in complex networks, and solve the problem of tight project time, heavy tasks, and the need for rapid development and docking demand.

View customer success stories: ​​SAIC Volkswagen and EMQ to create a new generation of intelligent car networking system

What technical solutions are you using?

As a message middleware, EMQX provides rich and flexible integration capabilities, and each function provides different technical solutions for users to choose. After a long-term use summary, the more popular technical solutions are as follows:

security

At the transport link layer, we recommend that users enable TLS encrypted transmission, but most cloud computing providers' load balancing products do not support TLS termination. During production deployment, additional components such as HAProxy need to be deployed to uninstall the TLS certificate. In addition, some customers need the national encryption algorithm TLS encrypted transmission, and we also provide customized solutions.

The most common way to access TBox is to use certificate authentication. EMQX provides an extensible authentication chain and supports third-party authentication platform extensions (such as PKI systems), followed by external data sources and internal database authentication based on username/password.

In addition, most users have enabled the EMQX authentication function, and assign corresponding publishing and subscription permissions to different TBox terminals to effectively protect data security.

data integration

Connecting the massive IoV data flowing through EMQX with the business system is the most important capability for customers. EMQX has built-in rule engine and data bridging capabilities, which can stream MQTT data to Kafka, various SQL / NoSQL / time series databases, In actual projects, the vast majority of customers use Kafka as the back-end stream processing component.

Kafka focuses on the storage and reading of data, while EMQX focuses on communication between clients and servers. EMQX is used to quickly receive and process messages from a large number of IoT devices. Kafka can collect and store this data and send it For back-end programs to analyze and process, this architecture is currently the most widely used data integration solution.

write at the end

At present, the rapid development of automotive electronics has boosted the technology upgrade of the Internet of Vehicles industry. The future market prospects of the intelligent transportation and automotive industry are considerable. It is foreseeable that more car owners, consumers and bicycle manufacturers will benefit from it. Based on the perfect MQTT protocol and the powerful product capabilities of EMQX, it can help the IoV platform developers to quickly build a robust and flexible IoV platform. EMQ will also closely follow the development trend of the industry, promote the development and implementation of technologies related to message transmission and edge computing, and provide faster, better and smarter message service infrastructure for autonomous driving, vehicle collaboration, and Internet of Vehicles users.