Author: Liu Ding
https://blog.didiyun.com/index.php/2018/12/26/iot-infrastructure/
With the rapid development of the Internet of Things (IoT), the concept of connecting everything is no longer new. The Didi IoT platform is dedicated to the vehicle networking and transportation-related fields, providing IoT solutions and basic services for various scenarios.
The platform service support includes rapid IoT integration of devices, device management, data traffic, live/on-demand services, mapping services, storage services, and more. Solutions include vehicle monitoring, operation management, traffic management, transportation safety, data analysis, etc.
Secure Communication Link
Using a hierarchical security model, device manufacturers can choose the authentication and encryption methods based on the device’s computing power to ensure data integrity.
Fast Access
To accelerate the platform access period for device manufacturers, two access solutions are provided:
-
Providing an access SDK, which can be used to write code as a demo based on the actual access situation of manufacturers.
-
Collaborating with communication module manufacturers that support MQTT protocol commands to natively support IoT platform access and provide easy AT command methods for manufacturers to call, eliminating the need for manufacturers to understand communication protocols, thus improving access speed.
Stability
Each module of the platform adopts a fully distributed structure, eliminating single points of failure. SLA guarantees 99.99% message availability and 99.99% service stability.
Message Latency
The entire link adopts a non-blocking structure, triggering immediate message sending as soon as there is a message, i.e., messages are “delivered immediately”.
Multi-Service Compatibility
-
Seamless integration with storage services such as Fusion, Redis, Hbase, Hive, HDFS, Flink, with more products continuously being opened.
-
Seamless integration with basic services such as coordinate services, live/on-demand services, AI analysis services, with more services being integrated.
Various IoT scenarios are shown in the image above: underground parking lots, high-altitude power towers, crowded shared bicycles, shared cars, etc. Here are a few key features:
-
Weak connectivity
-
A large number of devices online 24 hours
-
Real-time control
-
Communication security
Maintaining long connections between devices and the server; message sending and receiving; ensuring secure channels with devices; supporting standard MQTT (compatible with both v3.1 and v3.1.1) and JT808 protocols.
As a major platform for transportation, we emphasize various access environments for vehicle networking. Currently, many hardware products related to vehicles, cars, and traffic communicate with the server using the JT808 protocol as the standard.
For traditional device manufacturers facing issues such as unfamiliarity with the vehicle networking environment, MQTT protocol, and the high costs of modifying existing stable devices, the platform can provide technical solutions compatible with existing JT808 protocol devices.
MQTT is based on a publish/subscribe model, allowing devices to independently subscribe to a topic to achieve point-to-point message sending, such as unlocking a specific shared car. When there are many devices, they can be grouped to achieve many-to-many communication; for example, sending self-check instructions to the same model of shared cars can use “batch identification” as a topic subscription, thus sending a message to control that batch.
MQTT protocol has small traffic. The header bytes are marked in bits for functionality, and the additional header information fields are only occupied when necessary, along with a 2-byte heartbeat, making the protocol design greatly simplify the package size.
MQTT protocol naturally supports handling weak network environments under public networks, such as network latency, message quality assurance during disconnections, and a 1.5 times heartbeat keep-alive mechanism.
Utilizing the built-in message quality (QoS) definitions of the MQTT protocol, the platform currently supports QoS=0 and QoS=1 levels.
QoS logic applies to both uplink and downlink messages. With QoS=0, the message will be sent to the recipient with the best effort, and will only be lost if the sender suddenly disconnects during sending. If the message is sent while the device is offline, it will be stored and sent once the device comes online.
With QoS=1, it is similarly tried, prioritizing persistent storage before sending to the device, waiting for a PubAck packet. If the PubAck is not received within 5 seconds, it will continue to be sent until the PubAck is received.
Security levels are divided into two:
1. Pure TCP connection, suitable for scenarios with lower computing power and where data is not critical, such as hidden GPS, valve detectors, and other small products that are small in size, low in power, and not suitable for excessive computation.
2. TLS connection, suitable for devices with certain computing power and high data confidentiality requirements, such as shared car control, dashcams, etc., where operations like unlocking cars, shutting down, and transmitting dashcam recordings require strong security control and confidentiality.
The platform supports two-way authentication for devices and servers. The device authenticates the server using an SSL certificate and encrypts transmission through a TLS connection. The server authenticates the device using a username and password carried by the device.
The platform generates a unique DeviceSecret for each device using the HMAC-SHA1 signing algorithm. To ensure password randomness, the signature content includes the device’s unique DeviceName and a user-defined unique ClientId.
However, just these two conditions for signing are not enough, as the signature content is fixed and can eventually be leaked, which would give others a permanent pass. Therefore, a random code is added to the device to ensure that the password generated by the signature is different each time; we use a timestamp as the random code, allowing the server to intercept passwords from earlier timestamps, permitting only valid passwords within a day to pass authorization.
The IoT platform provides basic video live/on-demand capabilities, as shown in the structure diagram below:
Video encoding transmits raw streams to Connsvr and is processed by the streaming server (if transcoding is needed, it will be transcoded; if not, it will be passed through), serving both as a live streaming function and as a recording function by storing it in the storage service.
In this structure, the live stream is transcoded only when played, not when written, thus suitable for scenarios with large transmission amounts but low playback amounts, such as when many devices report audio and video data to the server, and the playback end monitors specified devices’ real-time images and historical footage.
The streaming server supports both RTMP and HTTP streaming methods.
In many application scenarios, developers need to update device configuration information, including system parameters, network parameters, etc. Generally, updating device configuration information is done through firmware upgrades, which increases the maintenance cost of firmware versions and requires device downtime to complete the update.
To address these issues, the IoT platform provides a configuration center to solve the problem of remote configuration updates, allowing devices to complete configuration information updates online without rebooting or interrupting operation.
Device firmware upgrades, also known as OTA, are an important part of IoT communication services. When IoT devices have new functions or need to fix vulnerabilities, they can quickly upgrade firmware through OTA services.
In practical IoT application scenarios, millions, tens of millions, or even billions of IoT devices are typically deployed. After these devices are deployed in production systems, how to securely manage them, such as how to remotely upgrade devices, becomes a challenge.
IoT devices often lack screens and do not have personnel manually managing them. How are upgrade operations triggered? How to roll back after upgrade failures and report upgrade status?
For such scenarios, a set of OTA management system needs to be designed in advance to automate device management. Through the OTA management system, devices can be monitored, quickly located, functional failures can be diagnosed, firmware can be remotely updated, and devices can be remotely restarted, repaired, or restored to factory settings, greatly reducing the cost and workload of managing a large number of IoT devices.
As vehicles become more popular, more people are inclined to install various devices in their cars, such as entertainment devices, safety devices, vehicle control devices, monitoring devices, etc. These devices are scattered throughout the vehicle, each serving different functions, making user management a hassle. Therefore, the platform abstracts the concept of an “object model” to represent all devices in a car as one “object”, treating the functions of the devices as attributes of that “object”.
When installed in a vehicle, the devices are added as components of the car to the “object model”. As shown in the image below:
Through the object model, the management end only needs to specify the “object name” (for example, the license plate number) to obtain GPS, fuel level, battery level, driving record video, and control the unlocking, locking, and closing of windows of the car. The specific devices reporting information inside the car do not need to be concerned about. The management interaction is as follows:
The object model has a feature: when a user wants to send a status change message to a device that may be offline, the downlink message cannot be delivered to the device. At this time, the object model will record the status and wait for the device to come online to send the message. For the user, it is only necessary to know whether the message is delivered and the current status. Even if the device is offline, all reported statuses can be queried through the object model. In weak network environments, this is beneficial because when querying device status, the actual device does not need to be online to retrieve recent status.
DTS serves as a middleware for data transmission between gateways and backend storage and basic services, implementing configurable multi-line distribution of data based on DDMQ, seamlessly connecting the same data to different storage and backend services for business processing.
Data traffic supports simple data processing:
-
Filtering based on keywords.
-
Message formatting to unify or customize protocols for backend processing.
-
Write rate limiting to protect backend load, etc.
The architecture of the Didi IoT platform considers a one-stop connection from the device side to the access layer and then to backend data + services, integrating various basic service capabilities to create solutions for vehicle networking and transportation fields, laying a foundation for rapid business access and stability assurance, while also connecting more service ecosystems in the future to provide rich business model support.
Long press to subscribe for more ↓
Your Majesty, please grant me a beautiful one ↓↓↓