Remote offline data acquisition function deployment method and system

Abstract

The invention discloses a remote off-line data acquisition function deployment method and system, and relates to the technical field of vehicle remote data acquisition and terminal configuration management, and the method comprises the following steps: a cloud platform generates an off-line instruction containing an acquisition strategy and a file check code, and sends the off-line instruction to an Internet of Vehicles gateway, the Internet of Vehicles gateway stores the instruction and issues the instruction when the vehicle terminal establishes a connection with the cloud, the vehicle terminal periodically wakes up and tries to connect with the cloud in a dormant state, after receiving the instruction, the vehicle terminal sends a general response to the gateway, and after receiving the response, the gateway deletes the instruction; and the vehicle terminal analyzes the instruction, downloads and verifies the collected information file, sends a proprietary response to the cloud end after strategy configuration is completed, and re-sleeps, and if the cloud end does not receive the proprietary response within the time limit, re-generates and issues an offline instruction. According to the invention, reliable issuing and execution of the acquisition strategy in a vehicle offline or weak network environment are realized, and the success rate of data acquisition and the communication efficiency of the system are improved.

Description

Technical Field

[0001] This application relates to the field of vehicle remote data acquisition and terminal configuration management technology, and in particular to a method and system for deploying remote offline data acquisition functions. Background Technology

[0002] With the rapid development of vehicle networking technology and the increasing demand for big data applications, remote vehicle data acquisition has become an important means for OEMs to conduct fault diagnosis, R&D iteration and user behavior analysis. Typically, cloud platforms are used to send data acquisition strategy configuration files to vehicle terminals to dynamically define the list of signals to be collected, sampling frequency and reporting rules, thereby achieving flexible and efficient data acquisition.

[0003] However, existing technologies typically rely heavily on vehicles being ignited or online in order to establish an effective communication link for issuing commands. This results in the inability to push update strategies to a large number of vehicles that are in a long-term off, parked, or dormant state in a timely manner. Such vehicles are highly susceptible to network fluctuations and user vehicle usage frequency, leading to problems such as missing or mismatched configuration tasks, long periods of unreachability, and low deployment success rates. Summary of the Invention

[0004] The purpose of this invention is to provide a method and system for deploying remote offline data acquisition, which at least solves a technical problem in the prior art where effective communication can only be established when the vehicle is ignited or online in real time, making it difficult to push strategies to vehicles in a long-term idle state in a timely manner.

[0005] This invention provides the following solution:

[0006] According to one aspect of the present invention, a method for deploying a remote offline data acquisition function is provided, comprising the following steps:

[0007] S1. The cloud platform acquires vehicle information and generates a collection strategy, forming an offline instruction containing the collection strategy and a file verification code, and sends it to the vehicle network gateway.

[0008] S2. The vehicle network gateway stores the offline instructions and continuously monitors the vehicle communication status. When it detects that the vehicle terminal has established a communication connection with the cloud platform, it sends the offline instructions to the vehicle terminal.

[0009] S3. When the vehicle is in a sleep state, the vehicle terminal periodically wakes up according to a preset timer mechanism and initiates a connection request to the cloud platform.

[0010] S4. After receiving the offline instruction, the vehicle terminal sends a general response to the vehicle network gateway. After receiving the general response, the vehicle network gateway deletes the offline instruction stored locally to end the instruction delivery task in this wake-up cycle.

[0011] S5. The vehicle terminal parses the offline command, downloads the corresponding collection information file according to the parsing result, and completes the verification and parsing based on the file verification code. After completing the collection strategy configuration, the vehicle terminal sends a proprietary response containing the execution result to the cloud platform and enters the sleep state again.

[0012] S6. The cloud platform monitors whether the dedicated response has been received. If the dedicated response has not been received and the current time has not exceeded the preset time limit, the cloud platform regenerates the offline instruction and sends it to the vehicle network gateway for repeated distribution in the next cycle.

[0013] Furthermore, in step S1, generating the offline instruction containing the acquisition strategy and file verification code specifically includes the following steps:

[0014] Receive configuration requirements, which include a list of target vehicles, definitions of acquisition signals, and data acquisition cycles;

[0015] Generate a corresponding database file based on the defined acquisition signal and the data acquisition cycle, calculate the file check code of the database file, and upload the database file to the storage server to obtain the file download address;

[0016] The instruction operation type is determined based on the configuration requirements, and the operation type is one of the configuration strategy, deletion strategy, and query strategy.

[0017] The operation type, the file download address, the file verification code, and the target vehicle list are encapsulated into an instruction data packet;

[0018] Add an offline attribute tag to the instruction data packet to generate the offline instruction.

[0019] Furthermore, in step S2, the vehicle network gateway storing the offline instructions and continuously monitoring the vehicle communication status specifically includes the following steps:

[0020] Receive the offline instruction, parse the target vehicle identifier and offline attribute tag in the offline instruction, and write the offline instruction into the offline message cache queue associated with the target vehicle identifier;

[0021] Continuously monitor the network connection events corresponding to the target vehicle identifier;

[0022] Upon receiving a login request initiated by the vehicle terminal and completing identity authentication, it is determined that the vehicle terminal has established a communication connection with the cloud platform.

[0023] The offline message cache queue is retrieved. If the offline message cache queue is not empty, the offline instruction is extracted and pushed to the vehicle terminal through the currently established communication link.

[0024] Furthermore, in step S3, the periodic self-wake-up according to a preset timer mechanism and the initiation of a connection request to the cloud platform specifically includes the following steps:

[0025] When the vehicle is turned off and the vehicle network is in sleep mode, the remote communication module of the vehicle terminal is kept in low-power standby mode and the internal hardware timer is started.

[0026] When the hardware timer reaches the preset wake-up time, the remote communication module is triggered to enter the working mode, while keeping other control units of the vehicle in a sleep state.

[0027] Establish a wireless link with the mobile communication network and send a login message to the vehicle network gateway;

[0028] After receiving the login success confirmation message from the vehicle network gateway, maintain the heartbeat connection and wait to receive data.

[0029] Furthermore, in step S4, sending a general response to the vehicle network gateway specifically includes the following steps:

[0030] The received offline command is parsed to extract the message sequence number and command type identifier;

[0031] Verify the integrity of the offline command transmission;

[0032] If the transmission integrity verification passes, a general response message containing the message sequence number and the reception confirmation identifier is generated. The reception confirmation identifier is used to indicate that the terminal has successfully received the data packet but has not yet started service processing.

[0033] The general response message is sent to the vehicle network gateway first.

[0034] Furthermore, in step S4, deleting the offline command stored locally specifically includes the following steps:

[0035] Receive the general response message and parse the message sequence number and vehicle identity information contained therein;

[0036] Retrieve a target offline instruction that matches the vehicle identity information and the message sequence number from the offline message cache queue;

[0037] Remove the target offline instruction from the offline message cache queue and record the status of the instruction issued this time as delivered;

[0038] Stop the timeout retransmission timer for the target offline command.

[0039] Furthermore, in step S5, downloading the corresponding collected information file based on the parsing result and completing the verification and parsing based on the file verification code specifically includes the following steps:

[0040] Extract the file download address and the file verification code sent from the cloud from the offline instructions;

[0041] The collected information file is requested and downloaded through the file download address. The collected information file is a database file describing the vehicle communication matrix.

[0042] Calculate the local checksum of the downloaded collected information file;

[0043] Compare the local verification code with the file verification code sent from the cloud;

[0044] If the comparison results are consistent, the collected information file is parsed according to the database file format specification to extract the signal list, acquisition period and data type, and the extracted content is updated to the local data acquisition configuration library.

[0045] Furthermore, in step S5, the process of the vehicle terminal sending a proprietary response containing the execution result to the cloud platform specifically includes the following steps:

[0046] Based on the comparison results and the parsing status of the collected information file, an execution result code is generated, which includes configuration success, verification failure, and parsing error.

[0047] Get the version number of the currently used data collection strategy and the timestamp of the last update;

[0048] The execution result code, the collection strategy version number, and the message sequence number of the offline instruction are encapsulated into a business layer response message;

[0049] Establish an application-layer data channel with the cloud platform and send the business-layer response message as the proprietary response.

[0050] Furthermore, in step S6, the cloud platform's deployment status based on whether or not the proprietary response confirmation strategy has been received specifically includes the following steps:

[0051] Listen to the application layer data reporting interface from the vehicle terminal;

[0052] Upon receiving the proprietary response, the execution result code and the collection strategy version number are parsed.

[0053] When the execution result code indicates successful configuration, the deployment status of the vehicle terminal in the cloud management database is marked as complete, and the policy effective time is recorded;

[0054] When the execution result code indicates an abnormal state, including verification failure and parsing error, the error type is recorded and the deployment status is kept as pending retry;

[0055] If the proprietary response is not received by the end of the current retry cycle, the deployment status is marked as a communication timeout, and the instruction generation task for the next cycle is triggered.

[0056] According to two aspects of the present invention, a remote offline data acquisition function deployment system is provided, the system comprising a cloud platform, a vehicle network gateway, and a vehicle terminal;

[0057] Cloud platforms, including:

[0058] The strategy generation module is used to acquire vehicle information and generate a collection strategy, form an offline instruction containing the collection strategy and a file verification code, and send it to the vehicle network gateway.

[0059] The retransmission control module is used to monitor whether a dedicated response has been received; if the dedicated response has not been received and the current time has not exceeded the preset time limit, the offline instruction is regenerated and sent to the vehicle network gateway for repeated transmission in the next cycle.

[0060] Vehicle-to-everything (V2X) gateway, including:

[0061] The storage and distribution module is used to store the offline instructions and continuously monitor the vehicle communication status. When it detects that the vehicle terminal has established a communication connection with the cloud platform, it sends the offline instructions to the vehicle terminal.

[0062] The cache clearing module is used to receive a general response from the vehicle terminal, and after receiving the general response, delete the offline instructions stored locally to end the instruction delivery task in the current wake-up cycle;

[0063] The vehicle terminal includes:

[0064] The timed wake-up module is used to periodically wake up the vehicle and initiate a connection request to the cloud platform according to a preset timed mechanism when the vehicle is in a sleep state.

[0065] The handshake confirmation module is used to send the general response to the vehicle network gateway after receiving the offline instruction;

[0066] The deployment execution module is used to parse the offline instructions, download the corresponding collection information file according to the parsing result, and complete the verification and parsing based on the file verification code; after completing the collection strategy configuration, it sends the proprietary response containing the execution result to the cloud platform and controls the vehicle to enter the sleep state again.

[0067] The above solution achieves the following beneficial technical effects:

[0068] This application overcomes the limitation of traditional data collection relying on real-time online vehicles by asynchronously coordinating gateway offline command caching and periodic self-wake-up of terminals. It enables seamless deployment of strategies for vehicles that are turned off or in hibernation without starting the vehicle, significantly improving the configuration reach and coverage of large-scale fleets in offline scenarios.

[0069] This application utilizes a universal response to quickly release the gateway cache and combines it with a low-power strategy of waking up only the communication module. This avoids repeated instruction pushes and invalid file downloads caused by network latency, and significantly reduces battery power consumption and data traffic costs during vehicle hibernation while ensuring communication reliability.

[0070] This application, based on a proprietary response-based business closed-loop monitoring and automatic retry scheduling mechanism, can accurately identify the configuration effectiveness status and periodically resend abnormal tasks, ensuring the deployment consistency, version synchronization rate, and final execution success rate of the collection strategy in complex network environments. Attached Figure Description

[0071] Figure 1 This is a flowchart of a remote offline data acquisition function deployment method provided by one or more embodiments of the present invention.

[0072] Figure 2 This is an architecture diagram of a remote offline data acquisition function deployment system provided by one or more embodiments of the present invention. Detailed Implementation

[0073] The technical solution of the present invention will now be clearly and completely described with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. 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.

[0074] Figure 1 This is a flowchart of a remote offline data acquisition function deployment method provided by one or more embodiments of the present invention.

[0075] like Figure 1 The method for deploying a remote offline data acquisition function, as shown, includes:

[0076] S1. The cloud platform obtains vehicle information and generates a collection strategy, forming an offline instruction containing the collection strategy and file verification code, and sends it to the vehicle network gateway.

[0077] Furthermore, in S1, the process of generating an offline instruction containing the acquisition strategy and file verification code specifically includes the following steps:

[0078] Receive configuration requirements, which include a list of target vehicles, definitions of acquisition signals, and data acquisition cycles.

[0079] Generate a corresponding database file based on the definition of the acquired signal and the data acquisition cycle, calculate the file check code of the database file, and upload the database file to the storage server to obtain the file download address;

[0080] The command operation type is determined based on the configuration requirements. The operation type is one of the configuration strategy, deletion strategy, and query strategy.

[0081] The operation type, file download address, file verification code, and target vehicle list are encapsulated into an instruction data packet;

[0082] Add an offline attribute tag to the instruction data packet to generate offline instructions.

[0083] Specifically, the cloud platform first receives configuration requirements from external input through a human-machine interface or system interface. These requirements specify the target vehicle list for policy deployment, which consists of a unique set of vehicle identification codes. The configuration requirements also include specific signal definitions and data acquisition cycles. The signal definitions specify the identifiers, start bits, lengths, and scaling factors of vehicle bus signals such as engine speed and battery voltage. The data acquisition cycle specifies the time interval for terminal data reporting, in milliseconds. Based on the above signal definitions and data acquisition cycles, the cloud platform uses pre-built compilation tools to generate a corresponding vehicle communication description database file. This file records the signal parsing rules and acquisition logic in binary or text format.

[0084] To ensure the integrity and consistency of the policy file during subsequent transmission and storage, the cloud platform calculates a checksum on the generated database file and uses the MD5 message digest algorithm to calculate the file's digital fingerprint. The generated database file contains binary data streams. Given the bit length of the data stream, calculate the file checksum. The algorithm formula is expressed as:

[0085] ;

[0086] In this formula, This represents the MD5 hash function, which maps input data of arbitrary length to a fixed-length 128-bit hash value. Corresponding to the contents of the specifically generated vehicle communication description database file, This is a 32-bit hexadecimal string formatted file verification code. This verification code is directly associated with a specific data acquisition strategy version and is used by the vehicle terminal to perform anti-tampering verification after downloading the file.

[0087] After calculating the checksum, the cloud platform uploads the generated database file to the distributed object storage server via the internal network and obtains the file's unique Uniform Resource Locator (URL) on the storage server as the file download address. Subsequently, the cloud platform parses the intent field in the configuration requirements and determines the instruction operation type as one of the configuration strategy, deletion strategy, or query strategy. For example, the configuration strategy is mapped to the hexadecimal opcode 0x01. The cloud platform constructs an instruction data packet and fills the payload field of the data packet with the determined operation type code, the obtained file download address, the calculated file checksum, and the target vehicle list.

[0088] Finally, the cloud platform adds an offline attribute tag to the message header of the instruction data packet. This tag is a specific boolean value identifier or message attribute field used to indicate to the downstream gateway that the message belongs to a non-real-time message that needs to be cached, thereby generating the final offline instruction. The cloud platform sends the offline instruction to the vehicle network gateway through the message queue interface.

[0089] This transforms complex vehicle data collection requirements into structured, verifiable control commands with offline identifiers. By separating the policy file entity from the control commands and using a combination of file download address and checksum, this method effectively reduces the data load on the core control link. At the same time, the addition of offline attribute tags provides the necessary identification basis for the subsequent gateway to implement asynchronous distribution and cache management for dormant vehicles.

[0090] S2. The vehicle network gateway stores offline commands and continuously monitors the vehicle's communication status. When it detects that the vehicle terminal has established a communication connection with the cloud platform, it sends the offline command to the vehicle terminal.

[0091] Furthermore, in S2, the vehicle-to-everything (V2X) gateway stores offline commands and continuously monitors the vehicle's communication status, specifically including the following steps:

[0092] Receive offline instructions, parse the target vehicle identifier and offline attribute tag in the offline instructions, and write the offline instructions into the offline message cache queue associated with the target vehicle identifier;

[0093] Continuously monitor network connection events corresponding to the target vehicle identifier;

[0094] Upon receiving a login request initiated by the vehicle terminal and completing identity authentication, it is determined that the vehicle terminal has established a communication connection with the cloud platform.

[0095] Retrieve the offline message cache queue. If the offline message cache queue is not empty, extract the offline instructions and push them to the vehicle terminal through the currently established communication link.

[0096] Specifically, the vehicle-to-everything (V2X) gateway receives offline instruction data packets from the cloud platform through its internal high-throughput message middleware interface. The gateway's access layer service first decodes the message header of the data packet and reads the offline attribute tag bit. When the tag indicates that the message is offline, the gateway further parses the message body and extracts the target vehicle identification code, which consists of seventeen characters. The gateway uses a high-performance in-memory database to build an offline message cache queue. This queue is organized using a key-value pair data structure. Specifically, the gateway uses the parsed vehicle identification code as a unique index key, serializes the complete offline instruction into a binary stream, and appends it to the list structure corresponding to the index key. This list structure follows the first-in-first-out (FIFO) principle to ensure that the stored instructions maintain the order of their generation time.

[0097] Meanwhile, the connection management module of the vehicle network gateway continuously monitors socket connection events on the designated network port. When a vehicle terminal in a dormant state is woken up according to a timed mechanism and establishes a connection with the underlying transmission control protocol, the gateway will receive a login request message uploaded by the terminal. The gateway reads the terminal identity identifier and dynamic authentication token in the login message and compares them with the pre-stored data in the background authentication center. Only when the authentication token is verified will the gateway allocate independent session resources, update the status of the vehicle terminal in the gateway session mapping table from offline to online, and lock the currently established network communication link handle.

[0098] At the moment identity authentication and session link establishment are completed, the gateway triggers an asynchronous offline message retrieval mechanism. The gateway uses the vehicle identification code of the currently established connection as the query key to access the offline message cache queue in the memory database. The gateway checks the length attribute of the queue. If the length attribute is greater than zero, it indicates that there is an offline instruction to be sent. At this time, the gateway performs a dequeue operation, extracts the earliest offline instruction from the head of the queue, and then calls the network sending interface. Using the currently locked network communication link handle, the gateway encapsulates the extracted offline instruction into a downlink network packet and pushes it to the vehicle terminal.

[0099] By decoupling cloud commands from vehicle status and using the gateway as an intermediate cache medium, it is ensured that control commands generated even when the vehicle is off and in sleep mode are not lost, but are temporarily stored in the gateway's memory. Once the vehicle is briefly awakened, the commands can be pushed immediately, thereby significantly improving the reliability and timeliness of command delivery in non-real-time scenarios.

[0100] S3. When the vehicle is in sleep mode, the vehicle terminal periodically wakes up according to a preset timer mechanism and initiates a connection request to the cloud platform.

[0101] Furthermore, in S3, the periodic self-wake-up and connection request to the cloud platform according to a preset timer mechanism specifically includes the following steps:

[0102] When the vehicle is turned off and the vehicle network is in sleep mode, the remote communication module of the vehicle terminal is kept in low-power standby mode and the internal hardware timer is started.

[0103] When the hardware timer reaches the preset wake-up time, the remote communication module is triggered to enter the working mode, while keeping other control units of the vehicle in a dormant state.

[0104] Establish a wireless link with the mobile communication network and send a login message to the vehicle network gateway;

[0105] After receiving a successful login confirmation message from the vehicle network gateway, maintain the heartbeat connection and wait to receive data.

[0106] Specifically, the vehicle terminal's main microcontroller unit monitors the vehicle's ignition status signal in real time via a hardwired interface. When it detects that the ignition signal voltage has switched to a low level and that message transmission on the vehicle controller area network bus has stopped for more than a preset silence time, the vehicle terminal determines that the vehicle has entered an engine shutdown and network sleep state. At this time, the main microcontroller unit sends a command to the internal power management chip to cut off the power supply to all peripherals except for the real-time clock module and the circuits required to maintain minimum system operation. In particular, it cuts off the power supply to the high-power remote communication module and bus transceiver, causing the terminal to enter a low-power standby mode. The operating current at this time is usually controlled below the milliamp level. At the same time, the main microcontroller unit starts the internally integrated hardware real-time clock timer and calculates the next wake-up time, setting it as the system timestamp of the sleep state. Given a preset wake-up cycle duration, all in seconds, the formula for calculating the target timestamp for the next wake-up is as follows:

[0107] ;

[0108] The result of this formula is written into the compare register of a hardware timer, which is used to generate an interrupt signal when the time is reached.

[0109] When the hardware real-time clock time count reaches... The timer generates a hardware interrupt to wake up the main microcontroller unit. The main microcontroller unit executes some power-on logic, only supplying power to the remote communication module to put it into working mode. At the same time, it strictly controls the level of the general input / output interface connected to the vehicle network to ensure that no high-level pulses or specific network wake-up messages are sent to the bus, thereby keeping other electronic control units of the vehicle, such as the engine controller and body controller, in a dormant state.

[0110] After the remote communication module is started, it automatically searches for and camps on the mobile communication network base station with the best signal strength, obtains the Internet Protocol address, and the vehicle terminal uses the transmission control protocol to establish a reliable socket connection with the vehicle network gateway. After the connection is established, the terminal assembles a login message. The message payload includes the vehicle identification code, the terminal hardware serial number and the encrypted identity authentication token, and sends it to the vehicle network gateway through the wireless link.

[0111] After sending a login message, the vehicle terminal starts a response timeout timer. When it receives a login success confirmation message from the vehicle network gateway via the wireless link, the terminal closes the timeout timer and establishes the current session as valid. At this time, the terminal enters the heartbeat maintenance phase, sending extremely short link keep-alive data packets at preset heartbeat intervals to prevent network address translation mapping failure, and keeping the receive buffer open, in a ready mode waiting to receive data from the gateway.

[0112] This enables the vehicle to achieve a virtual connection state with extremely low power consumption. By utilizing some network wake-up technology, the vehicle-to-cloud communication link is established without waking up the high-energy-consuming equipment in the vehicle. This ensures that offline commands can be retrieved in a timely manner and protects the vehicle's battery power to the maximum extent, thus solving the risk of power depletion when the vehicle is parked for a long time and performing remote data collection.

[0113] S4. After receiving the offline command, the vehicle terminal sends a general response to the vehicle network gateway. After receiving the general response, the vehicle network gateway deletes the offline command stored locally to end the command delivery task in this wake-up cycle.

[0114] Furthermore, in S4, sending a general response to the vehicle-to-everything (V2X) gateway specifically includes the following steps:

[0115] The received offline instructions are parsed to extract the message sequence number and instruction type identifier;

[0116] Verify the integrity of offline command transmission;

[0117] If the transmission integrity verification passes, a general response message containing the message sequence number and the reception confirmation flag is generated. The reception confirmation flag is used to indicate that the terminal has successfully received the data packet but has not yet started service processing.

[0118] The general response message is sent to the vehicle network gateway first.

[0119] Furthermore, in S4, the offline command for deleting local storage specifically includes the following steps:

[0120] Receive a general response message and parse the message sequence number and vehicle identification information contained therein;

[0121] Retrieve the target offline command that matches the vehicle identity information and message serial number from the offline message cache queue;

[0122] Remove the target offline command from the offline message cache queue and record the status of the command issued this time as delivered;

[0123] Stop the timeout retransmission timer for the target offline command.

[0124] Specifically, the vehicle terminal's network protocol stack reads the binary data stream sent by the gateway from the socket receive buffer, parses the packet header according to the predefined communication protocol format, and extracts a two-byte message sequence number and a one-byte instruction type identifier from a fixed offset position in the protocol header. To ensure that the received instruction data has not experienced bit flipping or loss during wireless transmission, the terminal immediately performs a transmission integrity check. In this embodiment, a cyclic redundancy check algorithm is used to verify the packet payload, assuming it is the received instruction data payload after removing the packet header. For a pre-defined generator polynomial, such as the CRC-16-CCITT standard polynomial. The algorithm formula for calculating the check value is expressed as follows:

[0125] ;

[0126] In this formula, This represents the binary polynomial corresponding to the received data payload. The width of the checksum is 16 bits, here we take 16. The terminal compares the calculated remainder polynomial, i.e. the locally calculated check value, with the original checksum carried at the end of the data packet.

[0127] If the comparison results are consistent, it indicates that the transmission integrity verification has passed. The vehicle terminal immediately constructs a general response message. The payload of this message contains only the previously extracted message sequence number and a specific reception confirmation identifier, such as the hexadecimal value 0x06. This identifier clearly indicates that the terminal has physically received the data packet but has not yet entered the service parsing stage. The terminal network driver layer calls the high-priority sending interface to insert the general response message into the head of the sending queue, bypassing other low-priority log data that may exist in the queue, and ensuring that the message is sent to the vehicle network gateway with priority through the wireless link.

[0128] After receiving the general response message, the vehicle network gateway parses out the message sequence number and obtains the corresponding vehicle identification code by combining it with the session context of the current transmission link. The gateway uses these two key parameters as a combined index to access the offline message cache queue in the memory database. The gateway traverses the queue to find the target offline instruction record that completely matches the vehicle identification code and message sequence number.

[0129] Once the target offline instruction is retrieved in the queue, the gateway immediately performs a deletion operation, releasing the instruction data from the memory heap to prevent repeated pushes due to connection fluctuations. At the same time, the gateway updates the instruction lifecycle status field in the database, marking it as delivered. Next, the gateway locates the timeout retransmission timer handle assigned to this task, forcibly stops the timer's counting logic, and cancels the relevant timeout callback function, thereby terminating the automatic retry mechanism for this instruction.

[0130] This leads to the construction of a layered communication confirmation mechanism. This method utilizes lightweight general responses to achieve rapid release of the gateway-side cache, effectively solving the problem of repeated sending of large data packets due to excessive business processing time within the vehicle's short wake-up window, which causes the gateway to misjudge timeout. This significantly reduces communication traffic consumption and eliminates the risk of repeated instruction execution.

[0131] S5. The vehicle terminal parses the offline command, downloads the corresponding collection information file according to the parsing result, and completes the verification and parsing based on the file check code. After completing the collection strategy configuration, the vehicle terminal sends a proprietary response containing the execution result to the cloud platform and enters the sleep state again.

[0132] Furthermore, in S5, the corresponding collected information file is downloaded based on the parsing result, and the verification and parsing are completed based on the file checksum, specifically including the following steps:

[0133] Extract the file download address and the file verification code sent from the cloud from the offline command;

[0134] Request and download the collected information file via the file download address. The collected information file is a database file describing the vehicle communication matrix.

[0135] Calculate the local checksum of the downloaded collected information file;

[0136] Compare the local verification code with the file verification code sent from the cloud;

[0137] If the comparison results are consistent, the collected information file is parsed according to the database file format specification to extract the signal list, acquisition period and data type, and the extracted content is updated to the local data acquisition configuration library.

[0138] Furthermore, in S5, the process of the vehicle terminal sending a proprietary response containing the execution result to the cloud platform specifically includes the following steps:

[0139] Based on the comparison results and the parsing status of the collected information files, an execution result code is generated. The execution result code includes configuration success, verification failure, and parsing error.

[0140] Get the version number of the currently used data collection strategy and the timestamp of the last update;

[0141] The execution result code, the collection strategy version number, and the message sequence number of the offline instruction are encapsulated into a business layer response message;

[0142] Establish an application-layer data channel with the cloud platform and send business-layer response messages as proprietary responses.

[0143] Specifically, the application layer processing task of the vehicle terminal first extracts the file download address Uniform Resource Locator and the cloud-preset 32-bit file checksum from the payload field of the offline command. The terminal then launches the Hypertext Transfer Protocol client and initiates a GET request to the extracted download address. The information file is downloaded in segments via the wireless network. This file is a DBC format database file conforming to the ASAM standard, which is used to define the communication matrix between various electronic control units in the vehicle controller area network. After the download is completed, the file is temporarily stored in the terminal's non-volatile flash file system.

[0144] To verify the integrity and security of the downloaded file, the terminal reads the temporarily stored data stream of the collected information file and calculates the local checksum again using the MD5 algorithm. For locally downloaded file data, The algorithm formula for calculating the local 128-bit hash value is as follows:

[0145] ;

[0146] in Using the standard MD5 hash function, the terminal will calculate the result. Convert it to a hexadecimal string and compare it bit by bit with the file verification code extracted from the command and sent from the cloud.

[0147] Only when both are completely consistent will the terminal call the DBC parsing engine to read the file content. The parsing engine traverses the message definition blocks and signal definition blocks in the file according to the DBC format specification, extracts the CANID and start bit information of the signal list to be collected, such as engine speed, vehicle speed, etc., reads the acquisition cycle parameters and data type definitions in the attribute definition block, and serializes this structured data and writes it to the local embedded database or configuration file to complete the update of the data acquisition configuration library. If the checksum does not match, the terminal directly deletes the downloaded temporary file and does not perform further parsing.

[0148] After the configuration action is completed, the terminal generates a result code based on the execution status. If the configuration library is updated successfully, code 0x00 is generated to indicate successful configuration. If the MD5 check fails, code 0x01 is generated. If the DBC file format parsing is abnormal, code 0x02 is generated. At the same time, the terminal reads the system configuration table to obtain the currently effective policy version number and the system timestamp when the update was completed. The terminal encapsulates the above execution result code, policy version number, timestamp, and message sequence number of the original offline instruction into a business layer response message in JSON or TLV format.

[0149] The terminal uses the established or newly created application layer data channel to send the service layer response message as a proprietary response to the cloud platform. After the transmission is completed, the terminal main control unit executes the hibernation process, turns off the power of the remote communication module and other peripherals, and enters the low-power standby state again, waiting for the next timed wake-up or vehicle ignition.

[0150] This enables secure configuration updates in offline scenarios, prevents erroneous policies from taking effect through end-to-end MD5 strong verification mechanism, provides a definite business closed-loop feedback to the cloud using proprietary responses, and ultimately allows the terminal to return to sleep mode, ensuring business reliability and minimizing energy consumption throughout the entire offline deployment process.

[0151] S6. The cloud platform monitors whether a dedicated response has been received. If no dedicated response has been received and the current time has not exceeded the preset time limit, the cloud platform regenerates the offline command and sends it to the vehicle network gateway for repeated distribution in the next cycle.

[0152] Furthermore, in S6, the cloud platform's deployment status based on whether a proprietary response confirmation has been received includes the following steps:

[0153] Listen for application-layer data reporting interfaces from vehicle terminals;

[0154] Upon receiving a proprietary response, parse the execution result code and the collection strategy version number within it;

[0155] When the execution result code indicates that the configuration is successful, the deployment status of the vehicle terminal in the cloud management database is marked as complete, and the policy effective time is recorded;

[0156] When the execution result code indicates an abnormal state, including verification failure and parsing error, the error type is recorded and the deployment status is kept as pending retry;

[0157] If no dedicated response is received by the end of the current retry cycle, the deployment status will be marked as communication timeout, and the instruction generation task for the next cycle will be triggered.

[0158] Specifically, the cloud platform's access gateway service deploys a high-performance asynchronous I / O listener that continuously monitors data inflows from a specified message queue topic or HTTPRESTful interface. When an application-layer data packet from the vehicle terminal is detected, the access service identifies the packet as a proprietary response to policy deployment based on the protocol header and routes it to the policy management microservice. The policy management microservice deserializes the message payload and extracts the execution result code field, the feedback collection policy version number field, and the message sequence number of the original instruction.

[0159] The microservice first checks the value of the execution result code. When the code is 0x00, indicating successful configuration, the microservice locates the corresponding deployment task record in the task database based on the message sequence number, performs an atomic update operation, updates the deployment status field of the vehicle terminal from "in progress" to "completed", reads the current server's UTC time, writes it into the policy effective time field, and records the details of this successful interaction in the log system.

[0160] When the extracted execution result code is 0x01 (verification failure) or 0x02 (parsing error), indicating an abnormal status, the microservice inserts an error record in the task log table, detailing the error type code and the time of occurrence. However, it does not immediately change the deployment status in the main task table, but keeps it as "pending retry" or "in progress," waiting for subsequent scheduling logic to process it.

[0161] The task scheduler service on the cloud platform runs a periodic scanning job, which is executed every fixed time interval, such as one hour. The scanning job traverses the task database, filtering out all task records with a status of "pending retry" or "in progress" and whose current system time minus the task creation time does not exceed a preset total time limit, such as 720 hours. For each filtered record, the scheduler checks its associated "current retry cycle end time" field. If the current system time has exceeded the time point recorded in this field, and no valid dedicated response record is found in the associated feedback table, the scheduler determines that the offline push attempt has timed out. At this time, the scheduler updates the task status to "communication timeout" and immediately triggers a new instruction generation event, calls the logic in step S1 to regenerate the offline instruction, calculates the deadline of the next retry cycle, updates it to the database, and thus starts the next round of delivery attempts.

[0162] This achieves closed-loop management of offline vehicle deployment tasks. The method utilizes the combination of cloud state machine and timer scheduler to not only accurately record vehicle information that has been successfully deployed, but also to intelligently identify and automatically retry failures caused by network fluctuations, file corruption, or long-term vehicle hibernation, ensuring high coverage and data consistency of data collection strategy deployment in large-scale fleet management scenarios.

[0163] Figure 2 This is an architecture diagram of a remote offline data acquisition function deployment system provided by one or more embodiments of the present invention.

[0164] like Figure 2 As shown, this application also provides a remote offline data acquisition function deployment system, which includes a cloud platform, a vehicle network gateway, and a vehicle terminal;

[0165] Cloud platforms, including:

[0166] The strategy generation module is used to acquire vehicle information and generate a collection strategy, form an offline instruction containing the collection strategy and a file verification code, and send it to the vehicle network gateway.

[0167] The retransmission control module is used to monitor whether a dedicated response has been received; if the dedicated response has not been received and the current time has not exceeded the preset time limit, the offline instruction is regenerated and sent to the vehicle network gateway for repeated transmission in the next cycle.

[0168] Vehicle-to-everything (V2X) gateway, including:

[0169] The storage and distribution module is used to store the offline instructions and continuously monitor the vehicle communication status. When it detects that the vehicle terminal has established a communication connection with the cloud platform, it sends the offline instructions to the vehicle terminal.

[0170] The cache clearing module is used to receive a general response from the vehicle terminal, and after receiving the general response, delete the offline instructions stored locally to end the instruction delivery task in the current wake-up cycle;

[0171] The vehicle terminal includes:

[0172] The timed wake-up module is used to periodically wake up the vehicle and initiate a connection request to the cloud platform according to a preset timed mechanism when the vehicle is in a sleep state.

[0173] The handshake confirmation module is used to send the general response to the vehicle network gateway after receiving the offline instruction;

[0174] The deployment execution module is used to parse the offline instructions, download the corresponding collection information file according to the parsing result, and complete the verification and parsing based on the file verification code; after completing the collection strategy configuration, it sends the proprietary response containing the execution result to the cloud platform and controls the vehicle to enter the sleep state again.

[0175] Specifically, the cloud platform server is internally configured with a policy generation module and a deployment monitoring module. The policy generation module receives configuration requirements containing a vehicle list and signal definitions, generates a collection policy file using a pre-built database engine, calculates the checksum of the file using the SHA-256 algorithm, and then encapsulates the policy download address, checksum, and operation type into an offline instruction with an offline attribute tag, which is then sent to the vehicle network gateway. The deployment monitoring module maintains the policy's state machine and triggers the retransmission logic of the policy generation module if no dedicated response is received from the vehicle terminal and no timeout has occurred.

[0176] The vehicle-to-everything (V2X) gateway server is equipped with an offline message caching unit and a connection status monitoring unit. The offline message caching unit uses a persistent message queue to store received offline commands and establishes an index relationship between the vehicle's unique identifier and the command. The connection status monitoring unit monitors the vehicle's online status in real time. Once it detects that the target vehicle has established a communication session, it triggers the caching unit to push the offline command to the onboard terminal through the established link. After receiving the general response message returned by the terminal, it deletes the command from the cache queue.

[0177] The vehicle-mounted terminal integrates a low-power timed wake-up circuit and a data acquisition processor at the hardware level. The low-power timed wake-up circuit maintains independent power supply when the vehicle is off and is equipped with a hardware timer to trigger the remote communication module to power on and initiate a connection request to the cloud at preset intervals. Upon receiving an offline command, the data acquisition processor first sends a general response indicating successful transmission; then it parses the download address in the command, retrieves the acquisition strategy file via HTTP protocol, and calculates the hash value of the local file and compares it with the checksum in the command. If the comparison matches, the processor writes the strategy to the local configuration library and generates a proprietary response message containing execution result code, which is then sent to the cloud platform.

[0178] This system constructs a layered offline instruction processing architecture between the cloud, gateway, and terminal. It utilizes the gateway's caching mechanism to decouple cloud policy distribution from vehicle online status. Combined with the terminal's hardware timed wake-up circuit, it can reliably complete the synchronization and updating of data acquisition strategies even during the dormant period of a large fleet without consuming too much power from the vehicle's main battery.

[0179] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention.

Claims

1. A method for deploying a remote offline data collection function, characterized by, The method comprises the following steps: S1, the cloud platform acquires vehicle information and generates a collection strategy, forms an offline instruction containing the collection strategy and a file check code, and sends the offline instruction to a vehicle networking gateway; S2, the vehicle networking gateway stores the offline instruction and continuously monitors the communication state of the vehicle, and when it is monitored that the vehicle terminal establishes a communication connection with the cloud platform, the offline instruction is sent to the vehicle terminal; S3, the vehicle terminal periodically wakes up at a preset timing mechanism and initiates a connection request to the cloud platform when the vehicle is in a dormant state; S4, after receiving the offline instruction, the vehicle terminal sends a general response to the vehicle networking gateway, and the vehicle networking gateway deletes the locally stored offline instruction after receiving the general response to end the instruction sending task in the current wake-up period; S5, the vehicle terminal analyzes the offline instruction, downloads the corresponding collection information file according to the analysis result, and completes the verification and analysis based on the file check code, and after completing the collection strategy configuration, the vehicle terminal sends a special response containing the execution result to the cloud platform and enters the dormant state again; S6, the cloud platform monitors whether the special response is received, and if the special response is not received and the current time does not exceed the preset time limit, the cloud platform generates the offline instruction again and sends it to the vehicle networking gateway for the next cycle of repeated sending.

2. The method of claim 1, wherein, In S1, the offline instruction containing the collection strategy and the file check code specifically comprises the following steps: receiving configuration requirements, the configuration requirements including a target vehicle list, a collection signal definition, and a data collection period; generating a corresponding database file according to the collection signal definition and the data collection period, calculating the file check code of the database file, and uploading the database file to a storage server to obtain a file download address; determining the instruction operation type according to the configuration requirements, the operation type being one of configuration strategy, deletion strategy, and query strategy; packaging the operation type, the file download address, the file check code, and the target vehicle list into an instruction data packet; adding an offline attribute label to the instruction data packet to generate the offline instruction.

3. The method of claim 1, wherein, In S2, the vehicle networking gateway stores the offline instruction and continuously monitors the communication state of the vehicle, specifically comprising the following steps: receiving the offline instruction, analyzing the target vehicle identifier and the offline attribute label in the offline instruction, and writing the offline instruction into an offline message buffer queue associated with the target vehicle identifier; continuously listening to the network connection event corresponding to the target vehicle identifier; in the case that the login request initiated by the vehicle terminal is received and the identity authentication is completed, it is determined that the vehicle terminal establishes a communication connection with the cloud platform; retrieve the offline message buffer queue, and in the case that the offline message buffer queue is not empty, extract the offline instruction and push it to the vehicle terminal through the currently established communication link.

4. The method of claim 1, wherein, In S3, periodically waking up according to a preset timing mechanism and initiating a connection request to the cloud platform specifically comprises the following steps: In the case of vehicle engine off and vehicle network dormancy, the remote communication module of the vehicle terminal is kept in low-power standby mode, and an internal hardware timer is started; When the hardware timer reaches a preset wake-up time point, the remote communication module is triggered to enter working mode, while other control units of the vehicle are kept in dormant state; A wireless link with a mobile communication network is established, and a login message is sent to the vehicle networking gateway; After receiving the login success confirmation message fed back by the vehicle networking gateway, a heartbeat connection is maintained and data is received.

5. The method of claim 1, wherein, In the S4, sending a general response to the vehicle networking gateway specifically includes the following steps: Protocol header analysis is performed on the received offline instruction to extract message sequence number and instruction type identifier; The transmission integrity of the offline instruction is checked; In the case where the transmission integrity check is passed, a general response message containing the message sequence number and a reception confirmation identifier is generated, the reception confirmation identifier being used to indicate that the terminal has successfully received the data packet but has not started business processing; The general response message is preferentially sent to the vehicle networking gateway.

6. The method of claim 1, wherein, In the S4, deleting the locally stored offline instruction specifically includes the following steps: The general response message is received, and the message sequence number and vehicle identity information contained therein are analyzed; The target offline instruction matching the vehicle identity information and the message sequence number is searched in the offline message cache queue; The target offline instruction is removed from the offline message cache queue, and the instruction state of this time of delivery is recorded as having arrived; The timeout retransmission timer for the target offline instruction is stopped.

7. The method of claim 1, wherein, In the S5, according to the analysis result, the corresponding collection information file is downloaded, and the verification and analysis are completed based on the file verification code, specifically including the following steps: The file download address and the file verification code issued by the cloud are extracted from the offline instruction; The collection information file is requested and downloaded through the file download address, and the collection information file is a database file describing the vehicle communication matrix; The local verification code of the downloaded collection information file is calculated; The local verification code is compared with the file verification code issued by the cloud; In the case where the comparison result is consistent, the collection information file is parsed according to the database file format specification, the signal list, collection period and data type are extracted, and the extracted content is updated to the local data collection configuration library.

8. The method of claim 1, wherein, In the S5, the vehicle terminal sends a specific response containing the execution result to the cloud platform, specifically including the following steps: According to the comparison result and the parsing state of the collection information file, an execution result code is generated, including configuration success, verification failure and parsing error; The currently used collection strategy version number and the last update timestamp are obtained; The execution result code, the collection strategy version number and the message sequence number of the offline instruction are encapsulated into a business layer response message; An application layer data channel with the cloud platform is established, and the business layer response message is sent as the specific response.

9. The method of claim 1, wherein, The S6, cloud platform according to whether the specific steps comprising the following steps of receiving the exclusive response confirmation strategy deployment state: Listen to the application layer data reporting interface from the vehicle terminal; In the case of receiving the exclusive response, the execution result code and the collection strategy version number are parsed; When the execution result code indicates a successful configuration, the deployment state of the vehicle terminal in the cloud management database is marked as complete, and the policy effective time is recorded; When the execution result code indicates an abnormal state, the abnormal state includes verification failure and parsing error, the error type is recorded and the deployment state is kept as retry; In the case that the exclusive response is not received at the end of the current retry period, the deployment state is marked as communication timeout, and the next cycle of instruction generation task is triggered.

10. A remote offline data collection function deployment system, characterized by, A remote offline data collection function deployment method according to any one of claims 1-9, the system comprising a cloud platform, a vehicle networking gateway and a vehicle terminal; The cloud platform comprises: The strategy generation module is used for obtaining vehicle information and generating collection strategy, forming offline instruction containing the collection strategy and file check code, and sending it to the vehicle networking gateway; The retransmission control module is used for monitoring whether the exclusive response is received; In the case that the exclusive response is not received and the current time does not exceed the preset time limit, the offline instruction is regenerated and sent to the vehicle networking gateway for the next cycle of repeated issue; The vehicle networking gateway comprises: The storage distribution module is used for storing the offline instruction and continuously monitoring the vehicle communication state, and when the vehicle terminal and the cloud platform establish communication connection, the offline instruction is issued to the vehicle terminal; The cache clearing module is used for receiving the general response from the vehicle terminal, and deleting the locally stored offline instruction after receiving the general response, so as to end the instruction issue task in this wake-up period; The vehicle terminal comprises: The timing wake-up module is used for periodically waking up and initiating connection request to the cloud platform according to the preset timing mechanism when the vehicle is in sleep state; The handshake confirmation module is used for sending the general response to the vehicle networking gateway after receiving the offline instruction; The deployment execution module is used for parsing the offline instruction, downloading the corresponding collection information file according to the parsing result, and completing the verification and parsing based on the file check code; After completing the collection strategy configuration, the exclusive response containing the execution result is sent to the cloud platform, and the vehicle is controlled to enter sleep state again.

Images