Implementation method and system for automatically switching cloud data channel of two-wheeled electric vehicle

Abstract

The invention provides an implementation method and system for automatically switching a vehicle cloud data channel of a two-wheeled electric vehicle, and the method comprises the steps: enabling a cloud end to judge whether the current state of MQTT long connection is online or not when a user triggers a vehicle control service through a terminal; if yes, service data are issued through the MQTT, and a timer is started to monitor a vehicle end PUBACK event of the issued data; if the vehicle end PUBACK event is not received within the preset time threshold value, triggering a process logic which is not online with the MQTT long connection; when the in-vehicle infotainment system collects data generated in the use process of the vehicle according to the sensor frequency, if a report event reported to the cloud is generated, whether MQTT long connection exists or not is verified; if yes, uploading the reported data through the MQTT, and starting a timer to monitor a PUBACK event of the reported data; and if the PUBACK event is not received within the preset time threshold, triggering a process logic which does not exist with the MQTT long connection session.

Description

Technical Field

[0001] This invention relates to the field of electric vehicle technology, and in particular to a method and system for automatically switching the vehicle-to-cloud data channel of a two-wheeled electric vehicle. Background Technology

[0002] After electric two-wheelers and electric tricycles are equipped with IoT network cards, when the network signal in the physical environment of the device is poor, the success rate of data communication between the vehicle system and the cloud platform through the network channel is low, resulting in the electric two-wheelers and electric tricycles losing contact in emergency situations, causing losses to users.

[0003] Currently, the two-wheeled vehicle industry uniformly divides the vehicle-mounted system and cloud platform interaction services into near-field (≤ 150 meters) and far-field. Near-field uses Bluetooth channels, while far-field uses network channels. Within the service range supported by the two types of channels, there is no detailed priority division of the vehicle-mounted system and cloud platform interaction services. In the event of a fault or high system resource load, the high availability of high-priority core services cannot be well guaranteed, resulting in a poor user experience. Summary of the Invention

[0004] In view of this, the purpose of this invention is to provide a method and system for automatically switching cloud data channels for two-wheeled electric vehicles, which ensures high availability of high-priority core services by prioritizing them, thereby improving user experience.

[0005] In a first aspect, embodiments of the present invention provide a method for automatically switching cloud data channels for two-wheeled electric vehicles, the method comprising: When a user triggers vehicle control services through a terminal, the cloud determines whether the current status of the MQTT long connection is online. If so, the business data is sent via MQTT, and a timer is started to listen for the vehicle-side PUBACK event when the data is sent. If the vehicle-side PUBACK event is received within a preset time threshold, the timer is deleted, and the service data delivery is completed. If the vehicle-side PUBACK event is not received within the preset time threshold, the process logic of being offline with the MQTT long connection is triggered. When the vehicle system collects data generated during vehicle use according to the sensor frequency, if a reporting event is generated and reported to the cloud, the existence of the MQTT long connection is verified. If it exists, the data is uploaded and reported via the MQTT, and the timer is started to listen for the PUBACK event of the reported data; If the PUBACK event is received within the preset time threshold, the timer is deleted, and the data reporting is completed. If the PUBACK event is not received within the preset time threshold, the process logic of the non-existent MQTT long connection session is triggered.

[0006] Furthermore, the process logic that triggers the offline status of the MQTT long connection includes: If the MQTT long connection is offline, determine the priority of the issued command; If the priority of the issued instruction is normal issuance, a issuance failure log is recorded, the data is cached according to the caching strategy of various services, and retransmitted after the subsequent channel connection is established, and a reminder message is sent to the user; wherein, the reminder message is poor vehicle network, please try again later; If the issued instruction is emergency alarm data, then determine whether the amount of data sent through the vehicle's IoT network card via SMS channel on that day has reached a preset threshold. If the preset threshold number is reached, a transmission failure log is recorded, data is cached according to the caching strategy of various services, and retransmitted after the subsequent channel connection is established. The user is then given a reminder message, which states that the vehicle network is poor and to try again later. If the preset quantity threshold is not reached, the service SMS command is assembled, the data is encrypted using AES encryption, and the SMS command is sent by calling the operator's development interface.

[0007] Furthermore, after triggering the process logic of the MQTT long connection going offline, the method also includes: When the vehicle receives an SMS instruction sent by the operator's development interface, it performs a secondary verification to check whether the peer number is on the whitelist. If successful, the business data will be decrypted using the AES decryption algorithm.

[0008] Furthermore, after decrypting the business data using the AES decryption algorithm, the method further includes: Once decryption is successful, determine whether the service type supports SMS delivery; If supported, the detailed processing flow of vehicle-side instructions will be triggered.

[0009] Furthermore, the process logic that triggers the non-existence of the MQTT long-connection session includes: When the channel session of the MQTT long connection does not exist, determine the service priority of the reported data; If the priority of the business is non-urgent ordinary reporting, then record the reporting failure log and cache the data according to the local caching strategy of each type of business; If the service priority is emergency alarm data, then determine whether the amount of data reported by the vehicle IoT network card via SMS channel on the same day has reached the reporting threshold. If the reporting threshold is reached, a reporting failure log is recorded, and the reported data is cached according to the local caching strategy for retransmission after a subsequent channel connection is established. If the reporting threshold is not reached, the connection status between the module and the base station is determined. If the connection is successful, the SMS command will be sent via the SMS channel; If the connection fails, the failure log is recorded and the reported data is cached according to the local caching strategy, and then retransmitted after the subsequent channel connection is established.

[0010] Furthermore, after triggering the process logic that the MQTT long connection session does not exist, the method also includes: the cloud listens for operator SMS notification message events, and upon receiving the reported SMS, verifies whether the peer number has completed registration and binding in the vehicle center; If it exists, the reported data is decrypted using the AES decryption algorithm.

[0011] Furthermore, after decrypting the reported data using the AES decryption algorithm, the method further includes: After successful decryption, determine whether the service type supports SMS reporting; If supported, the cloud-reported data processing flow will be triggered.

[0012] Secondly, embodiments of the present invention provide a system for automatically switching cloud data channels for two-wheeled electric vehicles, the system comprising: The judgment module is used to determine whether the current status of the MQTT long connection is online when the user triggers the vehicle control service through the terminal. The first startup module is used to send business data via MQTT when the current status is online, and to start a timer to listen for the PUBACK event on the data sending vehicle. The first deletion module is used to delete the timer when the vehicle-side PUBACK event is received within a preset time threshold, and the service data delivery is completed. The first triggering module is used to trigger the process logic of being offline with the MQTT long connection if the vehicle-side PUBACK event is not received within the preset time threshold. The verification module is used to verify the existence of the MQTT long connection when the vehicle system collects data generated during vehicle use according to the sensor frequency and a reporting event to the cloud is generated. The second startup module is used to upload and report data via the MQTT when the MQTT long connection exists, and to start the timer to listen for the PUBACK event of the reported data; The second deletion module is used to delete the timer when the PUBACK event is received within the preset time threshold, and the reporting of the data is completed. The second triggering module is used to trigger the process logic that the MQTT long connection session does not exist if the PUBACK event is not received within the preset time threshold.

[0013] Thirdly, embodiments of the present invention provide an electronic device, including a memory and a processor, wherein the memory stores a computer program that can run on the processor, and the processor executes the computer program to implement the method described above.

[0014] Fourthly, embodiments of the present invention provide a computer-readable medium having processor-executable non-volatile program code that causes the processor to perform the method described above.

[0015] This invention provides a method and system for automatically switching cloud data channels for two-wheeled electric vehicles, including: when a user triggers vehicle control services through a terminal, the cloud determines whether the current status of the MQTT long connection is online; if so, it sends service data via MQTT and starts a timer to listen for the vehicle-side PUBACK event of the sent data; if the vehicle-side PUBACK event is received within a preset time threshold, the timer is deleted, and the service data sending is completed; if the vehicle-side PUBACK event is not received within the preset time threshold, the process logic of the MQTT long connection being offline is triggered; when the vehicle system collects data generated during vehicle use according to the sensor frequency, if a reporting event to the cloud is generated, the existence of the MQTT long connection is checked; if it exists, the reporting data is uploaded via MQTT, and a timer is started to listen for the reporting data PUBACK event; if the PUBACK event is received within the preset time threshold, the timer is deleted, and the reporting data is completed; if the PUBACK event is not received within the preset time threshold, the process logic of the MQTT long connection session not existing is triggered; by prioritizing, the high availability of high-priority core services is ensured, thereby improving the user experience.

[0016] Other features and advantages of the invention will be set forth in the description which follows, and will be apparent in part from the description, or may be learned by practicing the invention. The objects and other advantages of the invention are realized and obtained in accordance with the structures particularly pointed out in the description, claims and drawings.

[0017] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description

[0018] To more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0019] Figure 1 This is a flowchart illustrating the method for automatically switching cloud data channels for two-wheeled electric vehicles, as provided in Embodiment 1 of the present invention. Figure 2 This is a schematic diagram illustrating the classification levels of network availability status provided in Embodiment 1 of the present invention; Figure 3 This is a schematic diagram illustrating the classification of interactive services between the vehicle infotainment system and the cloud, as provided in Embodiment 1 of the present invention. Figure 4 This is a schematic diagram of the reconnection strategy provided in Embodiment 1 of the present invention; Figure 5 This is a schematic diagram illustrating the classification and specific functions of MQTT control messages provided in Embodiment 1 of the present invention; Figure 6 This is a schematic diagram of the MQTT protocol interaction between the vehicle system and the cloud provided in Embodiment 1 of the present invention; Figure 7 This is a schematic diagram of the system architecture for automatically switching cloud data channels for two-wheeled electric vehicles, as provided in Embodiment 1 of the present invention. Figure 8 This is a schematic diagram of the backup channel switching process for sending business SMS messages provided in Embodiment 1 of the present invention; Figure 9 This is a schematic diagram of the switching process for the backup channel of the reporting service SMS provided in Embodiment 1 of the present invention; Figure 10 This is a schematic diagram of the system for automatically switching cloud data channels for two-wheeled electric vehicles provided in Embodiment 2 of the present invention. Detailed Implementation

[0020] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0021] When the network signal is weak in the physical location of electric two-wheelers and electric tricycles, and the owner is far away from the vehicle, the success rate of remotely controlling the vehicle by calling the cloud platform through the network channel via mobile phone is very low. The SMS function using the signaling channel is more stable than the network function using the data channel. With the implementation of the new national standard for electric bicycles (GB 17761-2024), the country is paying more and more attention to the safety of electric two-wheelers and electric tricycles. After the vehicles are equipped with Beidou positioning and IoT network cards, it has become possible to carry out refined management of the vehicle-cloud interaction channel. When electric two-wheelers or electric tricycles are involved in emergencies such as theft, overheating during charging, collisions, or reversing, and the network quality is poor, the data will be reported dynamically through the SMS backup channel based on the service priority. When electric two-wheeled or three-wheeled vehicles are continuously in a poor network environment, they will continuously initiate cellular network reconnection when the network is down during the periodic reporting of location data and other information, causing unnecessary power consumption loss. All operators have a consistent standard for defining network signal strength for IoT network cards. Signal strength can be directly mapped to network quality. Furthermore, operators have comprehensive management strategies for IoT network cards, making them highly applicable to various industries. The SMS channel limits the content size to 140 bytes. Based on this, the open interfaces of various operators can support data up to 120 bytes, which is very suitable for the transmission of emergency commands in electric two-wheeled vehicles, connected vehicles, and cloud applications. The AES symmetric encryption and decryption algorithm offers high security, high encryption and decryption efficiency, and low resource consumption, making it ideal for encrypting and decrypting data in SMS channels and ensuring user data security.

[0022] Advantages of this application: All operators have consistent definitions of network signal data standards. The network availability status within each signal strength range has been tested and can be directly used to judge network quality. When the network connection is good, the signal quality data is reported to the cloud platform based on the network channel. The vehicle system and the cloud platform determine whether the network is available based on whether the network channel is established and the signal strength. When an emergency occurs in the vehicle, system, or cloud platform, and the network channel is deemed unusable, a downgrade strategy is triggered, using a backup SMS channel to send high-priority commands, ensuring coverage of high-risk scenarios for users and reducing direct personal and property losses to users. The vehicle system abstracts network signal quality by analyzing the connection status between modules and base stations. It then reports signal quality data to the cloud via a long-term MQTT (a lightweight, publish / subscribe-based IoT communication protocol designed to solve communication problems for IoT devices in low-bandwidth, low-resource, and unstable network scenarios) connection channel according to a regular strategy. The cloud then constructs a big data network signal map based on the reported network quality data and corresponding location information. This map is used for network diagnosis, assisting in problem localization, and ultimately providing feedback to the operator for basic network infrastructure construction, thus providing users with a high-quality network environment.

[0023] The following explains the terminology used in this application: Module (Modem): The core network communication hardware module of the vehicle-to-everything (V2X) device. As the nerve center for the vehicle to connect to the external network, it is responsible for the information interaction between the vehicle and the outside world (vehicle, road, people, cloud).

[0024] MQTT: A lightweight, low-bandwidth, low-power IoT communication protocol based on TCP long connections. It is suitable for high-frequency, real-time, small message service scenarios in the Internet of Things. Based on the publish / subscribe model, it is designed for vehicle networks, sensors, and unstable networks with limited physical hardware.

[0025] AES: A symmetric advanced encryption algorithm that uses a fixed-length key to encrypt and decrypt fixed-length data blocks. It has high security, high efficiency, and low resource consumption, and is often used in data encryption and decryption scenarios in the Internet of Things (IoT) environment. Reporting instructions: refers to business data actively reported to the cloud platform by the vehicle-mounted system of electric two-wheelers and electric tricycles, such as vehicle GPS location information, battery power information, road condition warning information, and component damage alarm information.

[0026] Issuing instructions: refers to business data that needs to be sent to electric two-wheelers and electric tricycles through the cloud platform, such as holiday theme skins for electric vehicle screens, vehicle system upgrade instructions, users turning on seat heating via mobile phone, and users starting vehicle inspection via mobile phone.

[0027] To facilitate understanding of this embodiment, the embodiments of the present invention will be described in detail below.

[0028] Example 1: Figure 1 The flowchart illustrates the implementation method of automatically switching cloud data channels for two-wheeled electric vehicles provided in Embodiment 1 of the present invention.

[0029] Reference Figure 1 The method includes the following steps: Step S101: When the user triggers the vehicle control service through the terminal, the cloud determines whether the current status of the MQTT long connection is online. Step S102: If yes, then send business data via MQTT and start a timer to listen for the vehicle-side PUBACK event when sending data; Step S103: If the vehicle-side PUBACK event is received within a preset time threshold, the timer is deleted and the service data delivery is completed. Step S104: If no vehicle-side PUBACK event is received within the preset time threshold, the process logic of offline connection with MQTT is triggered. Step S105: When the vehicle system collects data generated during vehicle use according to the sensor frequency, if a reporting event to the cloud is generated, the existence of the MQTT long connection is verified. Step S106: If it exists, upload the reported data via MQTT and start a timer to listen for the PUBACK event of the reported data; Step S107: If a PUBACK event is received within a preset time threshold, the timer is deleted and the data reporting is completed. Step S108: If no PUBACK event is received within the preset time threshold, the process logic of the non-existent MQTT long connection session is triggered.

[0030] Furthermore, step S104 includes the following steps: Step S201: If the MQTT long connection is offline, determine the priority of the sent command; Step S202: If the priority of the issued instruction is normal issuance, record the issuance failure log, cache the data according to the caching strategy of various services, retransmit it after the subsequent channel connection is established, and send a reminder message to the user; the reminder message is: the vehicle network is poor, please try again later. Step S203: If the issued instruction is emergency alarm data, then determine whether the amount of data sent by the vehicle IoT network card through the SMS channel on that day has reached the preset threshold. Step S204: If the preset quantity threshold is reached, record the transmission failure log, cache the data according to the caching strategy of various services, retransmit it after the subsequent channel connection is established, and send a reminder message to the user; the reminder message is: the vehicle network is poor, please try again later. In step S205, if the preset quantity threshold is not reached, the service SMS command is assembled, the data is encrypted using AES encryption, and the operator's development interface is called to send the SMS command.

[0031] Furthermore, after triggering the process logic of the MQTT long connection going offline, the method also includes the following steps: Step S301: When the vehicle receives the SMS instruction sent by the operator's development interface, it performs a secondary verification to check whether the peer number is on the whitelist. Step S302: If successful, the business data is decrypted using the AES decryption algorithm.

[0032] Furthermore, after decrypting the business data using the AES decryption algorithm, the method also includes: Step S303: After successful decryption, determine whether the service type supports SMS delivery; Step S304: If supported, trigger the detailed processing flow of vehicle-side instructions.

[0033] Furthermore, step S108 includes the following steps: Step S401: When the MQTT long-connection channel session does not exist, determine the service priority of the reported data; Step S402: If the business priority is non-urgent ordinary reporting, record the reporting failure log and cache the data according to the local caching strategy of each type of business. Step S403: If the service priority is emergency alarm data, then determine whether the amount of data reported by the vehicle IoT network card via SMS channel on the same day has reached the reporting threshold. Step S404: If the reporting threshold is reached, record the reporting failure log, cache the reported data according to the local caching strategy, and retransmit it after the subsequent channel connection is established. Step S405: If the reporting threshold is not reached, determine the connection status between the module and the base station. Step S406: If the connection is successful, send an SMS command through the SMS channel; In step S407, if the connection fails, record the reporting failure log, cache the reported data according to the local caching strategy, and retransmit it after the subsequent channel connection is established.

[0034] Furthermore, after triggering the process logic that the MQTT long connection session does not exist, the method also includes the following steps: Step S501, the cloud listens for operator SMS notification message events, and after receiving the reported SMS, verifies whether the peer number has completed registration and binding in the vehicle center; Step S502: If it exists, use the AES decryption algorithm to decrypt the reported data.

[0035] Furthermore, after decrypting the reported data using the AES decryption algorithm, the method also includes the following steps: Step S503: After successful decryption, determine whether the service type supports SMS reporting; Step S504: If supported, the cloud-reported data processing flow is triggered.

[0036] Specifically, the detailed design of this application is as follows: Application scenario: Electric two-wheeled vehicle and electric tricycle usage scenarios.

[0037] Network signal strength: The vehicle system determines the basic network availability by checking whether a connection is established between the IoT network card (Modem, an embedded communication device specifically designed for IoT device networking, responsible for establishing connections between digital devices and mobile communication networks and enabling wireless data transmission; its main functions include modulation / demodulation between digital data and analog signals, 2G / 3G / 4G / 5G network connections, and data transmission between IoT devices and the cloud network) and the base station. After establishing a connection, the module obtains the network signal strength value through signal interaction with the base station. Based on the signal strength value, a signal strength level is abstracted, and the network availability status is divided into categories such as... Figure 2 As shown.

[0038] Vehicle infotainment systems and cloud-based interactive services are categorized according to interaction frequency, whether they cause user loss, data packet size, and communication security, as follows: Figure 3 The hierarchy shown, and the corresponding channel strategy for each hierarchy.

[0039] Network quality signal upload mechanism: The vehicle system abstracts network signal quality based on the connection status between the modem and the base station, and reports signal quality data to the cloud through an MQTT long-connection channel according to a periodic strategy. When the vehicle is not in user working mode and the modem is in sleep mode, after being woken up at a specified wake-up period, the vehicle software system uploads the latest network quality signal data through the network channel. When the vehicle enters user working mode and the modem is awake, the latest network quality signal data is uploaded to the cloud every 10 seconds. When the vehicle system and the cloud network channel are unavailable, the vehicle system caches the location information and the network quality signal data of that location. The caching strategy is to cache the latest 5 data entries. When the vehicle system and the cloud network channel are restored, the data is aggregated and uploaded to the cloud.

[0040] Module Layer: As the vehicle's physical location changes, and it finds itself in an area with poor network signal quality, if the underlying network connection is disconnected when the vehicle's infotainment system needs to report data, the modem uses a gradient strategy for reconnection to avoid power loss and wasted system CPU, memory, and network resources caused by frequent modem reconnection. The specific reconnection strategy is as follows: Figure 4 As shown.

[0041] Network Layer: Building upon the core network connection established at the module layer, the network application layer also employs the same approach during the TCP connection establishment process. Figure 4 The gradient reconnection strategy avoids power consumption loss, CPU, memory and network resource waste caused by network layer reconnection. When the vehicle fails to initiate the first TCP connection operation, the subsequent reconnection interval is twice the previous interval.

[0042] Data Security: After the vehicle system's IoT network card is enabled for SMS functionality, to prevent third parties from bombarding users with SMS messages after obtaining the IoT network card number, the IoT network card must be bound to a specific T-Box physical device and undergo real-name authentication. The entire lifecycle of the IoT network card must be maintained and managed in an online system. Secondly, a whitelist function must be enabled, ensuring that the device-side IoT network card only receives SMS messages from trusted numbers corresponding to those in the cloud. Regarding SMS content, data is encrypted and decrypted using AES encryption and decryption algorithms according to a fixed data message format. The device parses the service type according to the specified message format and only processes specified types of SMS commands. At the monitoring and alarm level, SMS traffic usage is monitored through the operator's monitoring system. When abnormal situations are triggered, the sending source is traced, and the sending source's SMS function is disabled if necessary. Finally, rate limiting and circuit breaking policies are enabled on the device side, allowing only a specified number of SMS commands to be received within a certain time frame.

[0043] SMS command triggering strategy: In vehicle-side data reporting scenarios, the vehicle system checks for the existence of an available MQTT long connection. If no connection exists, a long connection gradient reconnection strategy is triggered. If a connection exists, alarm commands are reported via MQTT long connection PUBLISH control messages. If a PUBACK control message is not received from the cloud within 5 seconds of initiating the PUBLISH request, the current network channel is considered unstable, and a backup SMS channel is selected for data reporting. In cloud command delivery scenarios, the cloud checks for the existence of an online long connection session on the device. If no connection exists, a backup SMS channel is selected for SMS command delivery. If a connection exists, alarm commands are delivered via MQTT long connection Pub control messages. If a PUBACK control message is not received from the vehicle within 5 seconds of initiating the PUBLISH request, the current network channel is considered unstable, and a backup SMS channel is selected for command delivery. The classification and specific functions of MQTT control messages are as follows: Figure 5 As shown. The MQTT protocol interaction between the vehicle infotainment system and the cloud is as follows. Figure 6 As shown.

[0044] Reference Figure 7 The system architecture includes a vehicle networking service platform, an IoT platform, an operator IoT card management platform, and a vehicle infotainment system.

[0045] The vehicle infotainment system's T-Box is bound one-to-one with an IoT network card, and the vehicle's serial number static data and network card information are maintained in the vehicle center of the vehicle networking business platform; The operator's IoT card management platform enables the SMS channel function, sets up a whitelist of IoT network cards to receive SMS messages, and enables the daily SMS sending limit for a single card. When the vehicle is powered on, the in-vehicle infotainment system's modem periodically searches for and connects to base stations, detects signal strength, and caches signal data locally within the in-vehicle infotainment system. The vehicle system periodically reports location information and network signal detection data to the cloud via the MQTT network channel, and the cloud caches the vehicle network signal detection data.

[0046] In the detailed downgrade process for issued services, refer to Figure 8 When a user triggers vehicle control services through a mobile app, mini-program, or other terminal, the cloud-based backend program determines whether the MQTT long connection is currently online. If it is online, it uses MQTTPUBLISH control messages to send data and starts a 5-second timer to listen for the PUBACK event on the vehicle side when the data is sent. If a PUBACK event is received from the vehicle end within 5 seconds, the timer is deleted and the business data delivery is complete. If no PUBACK event is received from the vehicle side within 5 seconds, the process logic of offline connection with MQTT is triggered. If the MQTT long connection is offline, determine the priority of the sent command. If the command priority is normal, record the sending failure log, cache the data according to the specific caching strategy of various services, and retransmit it after the channel is reconnected. Feedback the user with "Vehicle network is poor, please try again later"; If it is an emergency alarm data, determine whether the amount of data sent through the SMS channel of the vehicle's IoT network card on that day has triggered the threshold. If it has, record the failed transmission log, cache the data according to the specific caching strategy of each type of business, and retransmit it after the channel is connected later. Feedback the user with "Vehicle network is not good, please try again later"; If the daily SMS sending limit is not triggered, the business SMS command is assembled, the data is encrypted using AES encryption, and the SMS command is sent by calling the operator's development interface. After receiving the SMS instruction, the vehicle performs a secondary verification to check whether the other party's number is on the whitelist. If it passes the verification, the AES decryption algorithm is used to decrypt the data. Once decryption is successful, determine whether the business type supports SMS delivery. If it does, trigger the detailed processing flow of the vehicle-side instruction.

[0047] In the detailed downgrade process for reported business items, refer to Figure 9 The vehicle system collects data generated during vehicle use according to the sensor frequency. When an event that needs to be reported to the cloud occurs, it checks whether the MQTT long connection channel exists. If it exists, it uses MQTT PUBLISH control class messages to upload data and starts a 5-second timer to listen for the PUBACK event in the cloud for data reporting. If a PUBACK event is received from the cloud within 5 seconds, the timer is deleted and the data reporting is complete. If no PUBACK event is received from the cloud within 5 seconds, the logic of the non-existent MQTT long connection session is triggered. If the MQTT long connection channel session does not exist, determine the business priority of the reported data. If the data is a non-urgent ordinary report, record the reporting failure log and cache the data according to the specific local caching strategy of each business. If it is an emergency alarm data, determine whether the amount of data reported by the vehicle's IoT network card through the SMS channel on the same day has triggered the reporting threshold. If it has, record the reporting failure log, cache the data according to the local caching strategy, and retransmit it after the channel is connected in the future. If the daily SMS reporting limit is not triggered, the connection status between the module and the base station is checked. If the connection is successful, an SMS command is sent through the SMS channel. If the module fails to establish a connection with the base station, a reporting failure log is recorded, and the message data is cached according to the local caching policy and retransmitted after the subsequent channel connection is established. The cloud monitors SMS notification events from operators. Upon receiving a reported SMS, it verifies whether the peer number has been registered and bound in the vehicle center. If so, it uses the AES decryption algorithm to decrypt the data. Once decryption is successful, determine whether the business type supports SMS reporting. If it does, trigger the detailed data processing flow for cloud reporting.

[0048] Example 2: Figure 10 This is a schematic diagram of the system for automatically switching cloud data channels for two-wheeled electric vehicles provided in Embodiment 2 of the present invention.

[0049] Reference Figure 10 The system includes: The judgment module is used to determine whether the current status of the MQTT long connection is online when the user triggers the vehicle control service through the terminal. The first startup module is used to send business data via MQTT when the current status is online, and to start a timer to listen for the PUBACK event on the vehicle side when sending data; The first deletion module is used to delete the timer and complete the service data delivery when a vehicle-side PUBACK event is received within a preset time threshold. The first triggering module is used to trigger the process logic of being offline with the MQTT long connection if no PUBACK event is received from the vehicle end within a preset time threshold. The verification module is used to verify the existence of the MQTT long connection when the vehicle system collects data generated during vehicle use according to the sensor frequency and a reporting event to the cloud is generated. The second startup module is used to upload and report data via MQTT when a long MQTT connection exists, and to start a timer to listen for the PUBACK event of the reported data. The second deletion module is used to delete the timer and complete the data reporting when a PUBACK event is received within a preset time threshold. The second triggering module is used to trigger the process logic that the MQTT long connection session does not exist if no PUBACK event is received within a preset time threshold.

[0050] This invention also provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the steps of the method for automatically switching the cloud data channel of a two-wheeled electric vehicle provided in the above embodiments.

[0051] This invention also provides a computer-readable medium having processor-executable non-volatile program code, on which a computer program is stored. When the computer program is run by a processor, it executes the steps of the method for automatically switching the cloud data channel of a two-wheeled electric vehicle as described above.

[0052] The computer program product provided in this embodiment of the invention includes a computer-readable storage medium storing program code. The instructions included in the program code can be used to execute the methods described in the preceding method embodiments. For specific implementation details, please refer to the method embodiments, which will not be repeated here.

[0053] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working process of the system and apparatus described above can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0054] Furthermore, in the description of the embodiments of the present invention, unless otherwise explicitly specified and limited, the terms "installation," "connection," and "linking" should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral connection; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium; and they can refer to the internal connection of two components. Those skilled in the art can understand the specific meaning of the above terms in the present invention based on the specific circumstances.

[0055] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, essentially, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0056] In the description of this invention, it should be noted that the terms "center," "upper," "lower," "left," "right," "vertical," "horizontal," "inner," and "outer," etc., indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings. They are used only for the convenience of describing the invention and for simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, they should not be construed as limitations on the invention. Furthermore, the terms "first," "second," and "third" are used for descriptive purposes only and should not be construed as indicating or implying relative importance.

[0057] Finally, it should be noted that the above-described embodiments are merely specific implementations of the present invention, used to illustrate the technical solutions of the present invention, and not to limit it. The scope of protection of the present invention is not limited thereto. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that any person skilled in the art can still modify or easily conceive of changes to the technical solutions described in the foregoing embodiments within the technical scope disclosed in the present invention, or make equivalent substitutions for some of the technical features; and these modifications, changes, or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be covered within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A method for automatically switching cloud data channels for two-wheeled electric vehicles, characterized in that, The method includes: When a user triggers vehicle control services through a terminal, the cloud determines whether the current status of the MQTT long connection is online. If so, the business data is sent via MQTT, and a timer is started to listen for the vehicle-side PUBACK event when the data is sent. If the vehicle-side PUBACK event is received within a preset time threshold, the timer is deleted, and the service data delivery is completed. If the vehicle-side PUBACK event is not received within the preset time threshold, the process logic of being offline with the MQTT long connection is triggered. When the vehicle system collects data generated during vehicle use according to the sensor frequency, if a reporting event is generated and reported to the cloud, the existence of the MQTT long connection is verified. If it exists, the data is uploaded and reported via the MQTT, and the timer is started to listen for the PUBACK event of the reported data; If the PUBACK event is received within the preset time threshold, the timer is deleted, and the data reporting is completed. If the PUBACK event is not received within the preset time threshold, the process logic of the non-existent MQTT long connection session is triggered.

2. The method for automatically switching cloud data channels for two-wheeled electric vehicles according to claim 1, characterized in that, The process logic that triggers the offline status of the MQTT long connection includes: If the MQTT long connection is offline, determine the priority of the issued command; If the priority of the issued instruction is normal issuance, a issuance failure log is recorded, the data is cached according to the caching strategy of various services, and retransmitted after the subsequent channel connection is established, and a reminder message is sent to the user; wherein, the reminder message is poor vehicle network, please try again later; If the issued instruction is emergency alarm data, then determine whether the amount of data sent through the vehicle's IoT network card via SMS channel on that day has reached a preset threshold. If the preset threshold number is reached, a transmission failure log is recorded, data is cached according to the caching strategy of various services, and retransmitted after the subsequent channel connection is established. The user is then given a reminder message, which states that the vehicle network is poor and to try again later. If the preset quantity threshold is not reached, the service SMS command is assembled, the data is encrypted using AES encryption, and the SMS command is sent by calling the operator's development interface.

3. The method for automatically switching cloud data channels for two-wheeled electric vehicles according to claim 1, characterized in that, After triggering the process logic of the MQTT long connection going offline, the method further includes: When the vehicle receives an SMS instruction sent by the operator's development interface, it performs a secondary verification to check whether the peer number is on the whitelist. If successful, the business data will be decrypted using the AES decryption algorithm.

4. The method for automatically switching cloud data channels for two-wheeled electric vehicles according to claim 3, characterized in that, After decrypting the business data using the AES decryption algorithm, the method further includes: Once decryption is successful, determine whether the service type supports SMS delivery; If supported, the detailed processing flow of vehicle-side instructions will be triggered.

5. The method for automatically switching cloud data channels for two-wheeled electric vehicles according to claim 1, characterized in that, The process logic that triggers the non-existence of the MQTT long-connection session includes: When the channel session of the MQTT long connection does not exist, determine the service priority of the reported data; If the priority of the business is non-urgent ordinary reporting, then record the reporting failure log and cache the data according to the local caching strategy of each type of business; If the service priority is emergency alarm data, then determine whether the amount of data reported by the vehicle IoT network card via SMS channel on the same day has reached the reporting threshold. If the reporting threshold is reached, a reporting failure log is recorded, and the reported data is cached according to the local caching strategy for retransmission after a subsequent channel connection is established. If the reporting threshold is not reached, the connection status between the module and the base station is determined. If the connection is successful, the SMS command will be sent via the SMS channel; If the connection fails, the failure log is recorded and the reported data is cached according to the local caching strategy, and then retransmitted after the subsequent channel connection is established.

6. The method for automatically switching cloud data channels for two-wheeled electric vehicles according to claim 1, characterized in that, After triggering the process logic that the MQTT long connection session does not exist, the method further includes: the cloud listens for operator SMS notification message events, and when a reported SMS is received, it verifies whether the peer number has completed registration and binding in the vehicle center; If it exists, the reported data is decrypted using the AES decryption algorithm.

7. The method for automatically switching cloud data channels for two-wheeled electric vehicles according to claim 6, characterized in that, After decrypting the reported data using the AES decryption algorithm, the method further includes: After successful decryption, determine whether the service type supports SMS reporting; If supported, the cloud-reported data processing flow will be triggered.

8. A system for automatically switching cloud data channels for two-wheeled electric vehicles, characterized in that, The system includes: The judgment module is used to determine whether the current status of the MQTT long connection is online when the user triggers the vehicle control service through the terminal. The first startup module is used to send business data via MQTT when the current status is online, and to start a timer to listen for the PUBACK event on the data sending vehicle. The first deletion module is used to delete the timer when the vehicle-side PUBACK event is received within a preset time threshold, and the service data delivery is completed. The first triggering module is used to trigger the process logic of being offline with the MQTT long connection if the vehicle-side PUBACK event is not received within the preset time threshold. The verification module is used to verify the existence of the MQTT long connection when the vehicle system collects data generated during vehicle use according to the sensor frequency and a reporting event to the cloud is generated. The second startup module is used to upload and report data via the MQTT when the MQTT long connection exists, and to start the timer to listen for the PUBACK event of the reported data; The second deletion module is used to delete the timer when the PUBACK event is received within the preset time threshold, and the reporting of the data is completed. The second triggering module is used to trigger the process logic that the MQTT long connection session does not exist if the PUBACK event is not received within the preset time threshold.

9. An electronic device comprising a memory and a processor, wherein the memory stores a computer program executable on the processor, characterized in that, When the processor executes the computer program, it implements the method described in any one of claims 1 to 7.

10. A computer-readable medium having processor-executable non-volatile program code, characterized in that, The program code causes the processor to execute the method described in any one of claims 1 to 7.

Images