Off-line-Bluetooth cooperative adaptation updating method of vehicle-mounted Internet of Things communication system

Abstract

The invention relates to an offline-Bluetooth cooperative adaptation updating method of a vehicle-mounted Internet of Things communication system. The method comprises the steps that a power source is obtained through an OBD interface, and engine data frame specifications are analyzed; when the protocol library matching fails, receiving an update packet of the mobile terminal through the Bluetooth channel to carry out firmware and protocol library adaptive updating; periodically detecting a network state, and starting a circular queue caching strategy when the cellular network is unreachable; and when the network is recovered or the cloud is connected through the Bluetooth proxy, uploading the cache data according to a batch verification mechanism and deleting the confirmed frame. And efficient data management and transmission of the vehicle-mounted Internet of Things communication system in a complex network environment are realized. Through an offline caching strategy, it is ensured that the data can be completely stored and orderly uploaded in the network unreachable period, and the problem of data loss or repeated transmission is avoided.

Description

Technical Field

[0001] This invention belongs to the field of vehicle communication and Internet of Things (IoT) technology, and specifically relates to an offline-Bluetooth collaborative adaptation and update method for a vehicle IoT communication system. Background Technology

[0002] With the rapid popularization of intelligent connected vehicles, in-vehicle IoT terminals have become key components for remote vehicle monitoring, fault diagnosis, and over-the-air (OTA) upgrades. Existing solutions generally employ a single communication path of "cell-to-cloud direct connection": after the terminal powers on, it continuously collects real-time data from ECUs such as the engine via the CAN bus and uploads it directly to the cloud platform via the cellular network; the platform then performs protocol parsing, fault identification, and subsequent business processing based on the data stream. When the vehicle enters a cellular signal dead zone or the terminal's subscribed data allowance is exhausted, the data can only be temporarily stored in local Flash memory and uploaded centrally after the network is restored. To avoid data loss, some manufacturers introduce mobile phone Bluetooth hotspots as backup channels when cellular data fails, but existing implementations still have the following common problems: (1) There are many engine models and the data frame formats vary greatly. The protocol library pre-installed at the factory is difficult to cover all models. When the engine is replaced or the ECU is rewritten, the original protocol becomes invalid and the terminal cannot parse the new frame format, resulting in data interruption. The terminal must be returned to the factory for upgrade or manually rewritten.

[0003] (2) Local caches mostly use linear FIFO, with fixed capacity and lack of redundancy verification; once power is lost or abnormal restart, cached data is easily damaged; after upload recovery, there is no fine retransmission mechanism, and retransmission of the whole packet causes waste of cellular traffic and repeated calculation in the cloud.

[0004] (3) Single path-dependent cellular network, data upload is completely interrupted in signal blind spots; Bluetooth hotspots need to be manually turned on by the user, and there is no unified secure tunnel on the mobile phone side, which poses a risk of man-in-the-middle attack. (4) After the vehicle is turned off, the terminal still needs to maintain cellular online to wait for data to be uploaded. The static current is high, which leads to battery depletion. If the power is cut off directly, the cached data is not encrypted and there is no power-off protection, making it easy to be tampered with or lost.

[0005] (5) Firmware / protocol update packages are delivered via a single cellular channel, which is prone to interruption in weak network environments; there is no rollback mechanism for failed updates, and the terminal needs to be returned to the factory for repair after it becomes bricked.

[0006] (6) There is a lack of two-way authentication between the terminal and the cloud, and between the terminal and the mobile phone; protocol parsing and data caching share memory space, which poses a risk of out-of-bounds access and is easily triggered by malicious messages to cause system crashes. Summary of the Invention

[0007] To address the aforementioned problems in the existing technology, this invention provides an offline-Bluetooth collaborative adaptation and update method for an in-vehicle IoT communication system; the objective of this invention can be achieved through the following technical solutions: S1: The vehicle IoT box is connected to the vehicle bus via the OBD interface; when the vehicle IoT box is connected for the first time or the engine model is changed, the engine real-time data frame is read and the engine data specifications are parsed and identified. S2: The identified engine data specifications are matched with the protocol library stored locally in the vehicle IoT box. If the match is successful, the operation continues according to the matching protocol; if the match fails, the vehicle IoT box establishes a secure connection with the mobile terminal through the Bluetooth channel, receives the update package pushed by the mobile terminal that matches the engine data specifications, and loads the update package into the corresponding component firmware and protocol library inside the vehicle IoT box for adaptation and update. S3: The vehicle-mounted IoT box periodically performs network reachability detection, establishes a data link through the cellular mobile communication network, sends a handshake message to the preset IoT cloud signaling address and waits for a response; if no valid response within the expected latency threshold is received within the continuous detection period, it is determined that the current time period is in a network unreachable state, and the local offline caching strategy is activated, writing the collected vehicle operation data into the non-volatile storage area in the form of a circular queue according to the time sequence, and overwriting the earliest data frame according to the first-in-first-out principle when the storage capacity reaches the upper limit; S4: In each detection cycle, if the vehicle-mounted IoT box detects that the cellular mobile communication network has been restored and can reach the IoT cloud through the mobile terminal proxy after the Bluetooth channel is re-established with the mobile terminal, the offline caching strategy is terminated, and the complete data frame sequence in the local offline cache is uploaded to the IoT cloud according to the batch verification mechanism. After the upload is completed, the successfully confirmed data frames are deleted.

[0008] Specifically, the storage capacity of the circular queue described in S3 is up to 512 frames of data, and each frame of data contains a timestamp, vehicle VIN code, and a set of engine operating parameters.

[0009] Specifically, the steps in S4 to reach the IoT cloud via a mobile terminal agent include: The in-vehicle IoT box sends a cloud connection request carrying an encrypted identity token to the mobile terminal via Bluetooth. The mobile terminal uses its own cellular network to establish an HTTPS tunnel with the IoT cloud and forwards the request to the cloud through the tunnel; After verifying the validity of the identity token in the cloud, a successful proxy connection response is returned to the mobile terminal, which then forwards it to the in-vehicle IoT box.

[0010] Specifically, the pattern matching method described in S2 is as follows: Extract the physical layer features of the engine real-time data frames, including baud rate, frame length, and parity bit position, and perform a first-level match with the preset physical features of each protocol template in the protocol library; After the physical layer feature matching is successful, the storage offset address of the engine speed PID value and oxygen sensor PID value is located from the application layer of the data frame, and the offset address is matched with the preset address range of the corresponding protocol template in the protocol library for a second level. When physical layer feature matching fails but critical PID address matching fails, the data frame load area is traversed in 16-byte window units; the entropy volatility and numerical distribution dispersion of the data within the window are calculated in real time; based on the preset entropy volatility and dispersion judgment threshold, the current traversal window that meets the threshold condition is determined as the critical PID data area, and the current traversal window that does not meet the threshold condition is determined as the non-critical data area. Extract the numerical sequence change gradient of the suspected key PID data area; if the numerical sequence change gradient is consistent with the pre-stored standard engine speed change model within a preset similarity tolerance range, then the key PID data area is determined to be a valid engine speed PID data area. If the gradient of the numerical sequence change is consistent with the pre-stored standard oxygen sensor voltage and air-fuel ratio change model within the preset similarity tolerance range, then the suspected key PID data area is determined to be a valid oxygen sensor PID data area. Based on the identified valid PID data area and its offset address, a temporary protocol patch is generated and loaded into the protocol library of the vehicle IoT box.

[0011] Specifically, the engine real-time data frames in S1 are broadcast by the engine control unit via the vehicle bus at fixed time intervals, and the format of the data frames conforms to the J139 standard.

[0012] Specifically, the parsing and identification method in S1 is as follows: Extract the frame start identifier, frame length field and frame end identifier from the engine real-time data frame to determine the effective boundary and load area of ​​the data frame; Calculate the cyclic redundancy check code based on the load area and compare it with the check code carried in the data frame; if the check fails, discard the frame and trigger the reread mechanism. The sliding window matching algorithm identifies preset key fields in the load area, including engine control unit address code, service identifier, and parameter identifier location marker. Based on the identified engine control unit address code, service identifier distribution pattern, and parameter identifier density characteristics, an engine data specification descriptor containing physical layer parameters, application layer data structures, and key parameter identifier offset addresses is generated.

[0013] Specifically, the adaptation and update method is as follows: After receiving the update package pushed by the mobile terminal, verify the digital signature and version compatibility; parse the header fields of the update package to obtain metadata including the target firmware partition identifier, the offset of the protocol library update segment, and the checksum; Based on the target firmware partition identifier, the firmware image in the update package is written to the inactive storage partition of the vehicle IoT box; after the writing is completed, an integrity check is triggered: the hash value of the firmware in the partition is calculated and compared with the expected hash value declared in the update package; After the verification is successful, the boot flag of the bootloader is switched so that the system will boot from the updated inactive partition on the next restart; Based on the offset of the update segment in the protocol library, locate the temporary protocol patch data block in the update packet; create a temporary transaction area in the unallocated storage area of ​​the protocol library, and write the patch data in the form of a transaction log; Once all patch data has been written and the CRC check passes, the protocol library index table is atomically pointed to the new data area, and the storage space of the old protocol template is reclaimed. If there is no real-time data parsing task at present, the vehicle IoT box will be restarted immediately to make the update effective; if there is an ongoing parsing task, the new protocol library will be loaded through dynamic link library injection after the current data frame is processed to avoid system restart.

[0014] Specifically, the feature is that the in-vehicle IoT box implements a multi-level security protection mechanism during operation, specifically including: Upon power-up, the digital signatures of the bootloader and operating system kernel are verified based on the trusted root key; if the verification fails three times in a row, the system is locked and the temporary protocol patch in non-volatile memory is erased. Independent address spaces are divided by a memory management unit: the protocol parsing thread runs in a sandbox environment, and the offline caching thread runs in an encrypted memory area; the Bluetooth communication channel and the cellular network channel are isolated by a hardware firewall, and shared data needs to be converted by an encryption engine.

[0015] Specifically, the in-vehicle IoT box executes a low-power data preservation strategy after the vehicle is turned off: Real-time monitoring of power supply characteristics changes of the vehicle diagnostic interface; when a voltage decay characteristic that meets the preset shutdown judgment condition is detected, the high-power communication module and data processing unit are shut down, while the low-power wireless monitoring module is retained. The sequence of data frames to be uploaded in the offline cache is encrypted using a symmetric encryption algorithm and then transferred to a non-volatile, anti-interference memory; the physical storage location mapping relationship, time metadata range, and data integrity verification code of the encrypted data frames are generated and stored; The device status identifier is broadcast through the low-power wireless monitoring module. When the mobile terminal meets the preset near-field communication conditions, the established Bluetooth secure connection is automatically reused. When the power supply of the vehicle diagnostic interface is detected to be restored to the nominal operating voltage range, the high-power communication module is immediately restarted and the data upload service is restored.

[0016] Specifically, the batch verification mechanism includes: Before initiating the upload operation, the vehicle-mounted IoT box divides the sequence of data frames to be uploaded in the local offline cache into continuous data batches according to a preset number of frames; generates a cyclic redundancy check code independently for each data batch, and encapsulates the check code set of all batches in the first frame transmission message; After receiving the data frame sequence and check code set in the IoT cloud, the real-time check code of the received data is calculated frame by frame. The real-time check code is compared with the received check code set. When the check result of a specific data batch is found to be inconsistent, a retransmission request containing the abnormal batch identifier and frame sequence abnormal location information is returned to the vehicle IoT box. The vehicle-mounted IoT box performs data retransmission only for abnormal data batches according to the retransmission request; the verification feedback and retransmission process is repeated until all data batches pass the integrity verification. After the overall verification is passed, the cloud sends a global confirmation command. The vehicle IoT box deletes the confirmed uploaded local data according to the command. If a specific batch of data still fails to pass the verification after multiple retransmissions, it is transferred to the persistent storage management area and resubmitted for verification after the communication link is restored to stability.

[0017] The beneficial effects of this invention are as follows: By utilizing Bluetooth channels as a backup path when cellular networks fail and combining this with a mobile terminal proxy to achieve cloud connectivity, the problem of data upload interruption in signal blind spots is effectively solved. Secondly, through a dynamic protocol adaptation and update mechanism, the system can quickly respond to data frame parsing needs after engine model changes or ECU remapping, avoiding data stream interruptions caused by protocol incompatibility in traditional solutions. Thirdly, a multi-level security protection strategy, including trusted root verification, sandbox isolation, and hardware firewalls, comprehensively enhances the system's resistance to attacks. Finally, through low-power data preservation strategies and batch verification mechanisms, data integrity is ensured even after the vehicle is turned off, while data transmission efficiency is optimized, reducing unnecessary bandwidth consumption. These improvements not only enhance the intelligence level of in-vehicle IoT terminals but also provide strong support for the stable operation of intelligent connected vehicles. Attached Figure Description

[0018] To facilitate understanding by those skilled in the art, the present invention will be further described below with reference to the accompanying drawings.

[0019] Figure 1 This is a schematic diagram of the structure of an offline-Bluetooth collaborative adaptation and update method for an in-vehicle Internet of Things communication system according to the present invention; Figure 2 This is a schematic diagram of the protocol matching mechanism in this invention; Figure 3 This is a schematic diagram of the security update mechanism in this invention. Detailed Implementation

[0020] To further illustrate the technical means and effects of the present invention in achieving its intended purpose, the following detailed description of the specific implementation methods, structures, features, and effects of the present invention, in conjunction with the accompanying drawings and preferred embodiments, is provided.

[0021] Please see Figure 1-3 An offline-Bluetooth collaborative adaptation and update method for an in-vehicle IoT communication system, comprising: S1: The vehicle IoT box is connected to the vehicle bus via the OBD interface; when the vehicle IoT box is connected for the first time or the engine model is changed, the engine real-time data frame is read and the engine data specifications are parsed and identified. S2: The identified engine data specifications are matched with the protocol library stored locally in the vehicle IoT box. If the match is successful, the operation continues according to the matching protocol; if the match fails, the vehicle IoT box establishes a secure connection with the mobile terminal through the Bluetooth channel, receives the update package pushed by the mobile terminal that matches the engine data specifications, and loads the update package into the corresponding component firmware and protocol library inside the vehicle IoT box for adaptation and update. S3: The vehicle-mounted IoT box periodically performs network reachability detection, establishes a data link through the cellular mobile communication network, sends a handshake message to the preset IoT cloud signaling address and waits for a response; if no valid response within the expected latency threshold is received within the continuous detection period, it is determined that the current time period is in a network unreachable state, and the local offline caching strategy is activated, writing the collected vehicle operation data into the non-volatile storage area in the form of a circular queue according to the time sequence, and overwriting the earliest data frame according to the first-in-first-out principle when the storage capacity reaches the upper limit; S4: In each detection cycle, if the vehicle-mounted IoT box detects that the cellular mobile communication network has been restored and can reach the IoT cloud through the mobile terminal proxy after the Bluetooth channel is re-established with the mobile terminal, the offline caching strategy is terminated, and the complete data frame sequence in the local offline cache is uploaded to the IoT cloud according to the batch verification mechanism. After the upload is completed, the successfully confirmed data frames are deleted.

[0022] Specifically, the storage capacity of the circular queue described in S3 is up to 512 frames of data, and each frame of data contains a timestamp, vehicle VIN code, and a set of engine operating parameters.

[0023] Specifically, the steps in S4 to reach the IoT cloud via a mobile terminal agent include: The in-vehicle IoT box sends a cloud connection request carrying an encrypted identity token to the mobile terminal via Bluetooth. The mobile terminal uses its own cellular network to establish an HTTPS tunnel with the IoT cloud and forwards the request to the cloud through the tunnel; After verifying the validity of the identity token in the cloud, a successful proxy connection response is returned to the mobile terminal, which then forwards it to the in-vehicle IoT box.

[0024] In this embodiment, after determining that the network is unreachable, the vehicle-mounted IoT box executes a local data preservation strategy; a circular buffer is opened as a non-volatile storage area, with a maximum capacity of 512 data units. Each data unit contains a three-part tuple: a UTC timestamp accurate to milliseconds; a 17-bit Vehicle Identification Number (VIN) conforming to ISO 3779 standards; a set of engine operating parameters (including at least 8 key parameters such as engine speed, coolant temperature, and oxygen sensor voltage); a First-In-First-Out (FIFO) overwrite strategy is adopted: when the number of storage units reaches 512, newly acquired data automatically overwrites the earliest data at index 0; atomicity of write operations is guaranteed: data consistency is ensured in a multi-threaded environment through memory barrier instructions; and an integrated supercapacitor power supply module ensures that the last 32 frames of data are stored in the event of a sudden power outage.

[0025] The vehicle terminal sends a proxy request message to the paired mobile terminal via the Bluetooth Low Energy (BLE) channel. The message includes: an encrypted identity token generated using the HMAC-SHA256 algorithm (valid only once within its validity period); the target cloud service endpoint address; and a session negotiation random number (32-bit anti-replay code). The mobile terminal performs proxy relay operations: initiates a cellular network data connection; creates an end-to-end encrypted HTTPS tunnel; and encapsulates the original request into an HTTP / 2 frame format before forwarding it to the target cloud.

[0026] The IoT cloud security gateway decrypts the identity token and verifies the validity of the digital signature; verifies the token's validity and the uniqueness of the random number; and returns a proxy-ready response. When the cellular network determines that the mobile terminal is unreachable and the mobile terminal enters the BLE coverage area, the proxy connection process is as follows: T-Box issues a 128-bit encrypted identity token with the GATT feature UUID 0xFFF2. The token uses the COSE_Sign1 structure, the ECDSA-P256 signature algorithm, and the payload includes the device certificate serial number, validity period, and random challenge.

[0027] After successful pairing, the mobile terminal establishes a TLS 1.3 tunnel to the cloud signaling domain iot.example.com:443 using the system network stack; then it encapsulates the received identity token into an HTTPS POST / proxy / handshake request body and forwards it.

[0028] If the verification is successful, an HTTP 204 response is returned, and a one-time session key (AES-128-GCM) is included in the X-Proxy-Token header.

[0029] The mobile terminal sends the X-Proxy-Token back to the T-Box via the BLE feature 0xFFF3, and the T-Box immediately switches to the proxy link: uplink data is transmitted to the mobile terminal via BLE, and then forwarded to the cloud by the mobile terminal through the aforementioned TLS tunnel; downlink data is transmitted back via the same path.

[0030] When the cellular signal is restored or the vehicle is powered on again, the T-Box actively releases the proxy link and restores the cellular direct connection. The mobile terminal simultaneously cancels the session key to ensure two-way secure isolation.

[0031] Specifically, the pattern matching method described in S2 is as follows: Extract the physical layer features of the engine real-time data frames, including baud rate, frame length, and parity bit position, and perform a first-level match with the preset physical features of each protocol template in the protocol library; After the physical layer feature matching is successful, the storage offset address of the engine speed PID value and oxygen sensor PID value is located from the application layer of the data frame, and the offset address is matched with the preset address range of the corresponding protocol template in the protocol library for a second level. When physical layer feature matching fails but critical PID address matching fails, the data frame load area is traversed in 16-byte window units; the entropy volatility and numerical distribution dispersion of the data within the window are calculated in real time; based on the preset entropy volatility and dispersion judgment threshold, the current traversal window that meets the threshold condition is determined as the critical PID data area, and the current traversal window that does not meet the threshold condition is determined as the non-critical data area. Extract the numerical sequence change gradient of the suspected key PID data area; if the numerical sequence change gradient is consistent with the pre-stored standard engine speed change model within a preset similarity tolerance range, then the key PID data area is determined to be a valid engine speed PID data area. If the gradient of the numerical sequence change is consistent with the pre-stored standard oxygen sensor voltage and air-fuel ratio change model within the preset similarity tolerance range, then the suspected key PID data area is determined to be a valid oxygen sensor PID data area. Based on the identified valid PID data area and its offset address, a temporary protocol patch is generated and loaded into the protocol library of the vehicle IoT box.

[0032] Specifically, the engine real-time data frames in S1 are broadcast by the engine control unit via the vehicle bus at fixed time intervals, and the format of the data frames conforms to the J139 standard.

[0033] Specifically, the parsing and identification method in S1 is as follows: Extract the frame start identifier, frame length field and frame end identifier from the engine real-time data frame to determine the effective boundary and load area of ​​the data frame; Calculate the cyclic redundancy check code based on the load area and compare it with the check code carried in the data frame; if the check fails, discard the frame and trigger the reread mechanism. The sliding window matching algorithm identifies preset key fields in the load area, including engine control unit address code, service identifier, and parameter identifier location marker. Based on the identified engine control unit address code, service identifier distribution pattern, and parameter identifier density characteristics, an engine data specification descriptor containing physical layer parameters, application layer data structures, and key parameter identifier offset addresses is generated.

[0034] Specifically, the adaptation and update method is as follows: After receiving the update package pushed by the mobile terminal, verify the digital signature and version compatibility; parse the header fields of the update package to obtain metadata including the target firmware partition identifier, the offset of the protocol library update segment, and the checksum; Based on the target firmware partition identifier, the firmware image in the update package is written to the inactive storage partition of the vehicle IoT box; after the writing is completed, an integrity check is triggered: the hash value of the firmware in the partition is calculated and compared with the expected hash value declared in the update package; After the verification is successful, the boot flag of the bootloader is switched so that the system will boot from the updated inactive partition on the next restart; Based on the offset of the update segment in the protocol library, locate the temporary protocol patch data block in the update packet; create a temporary transaction area in the unallocated storage area of ​​the protocol library, and write the patch data in the form of a transaction log; Once all patch data has been written and the CRC check passes, the protocol library index table is atomically pointed to the new data area, and the storage space of the old protocol template is reclaimed. If there is no real-time data parsing task at present, the vehicle IoT box will be restarted immediately to make the update effective; if there is an ongoing parsing task, the new protocol library will be loaded through dynamic link library injection after the current data frame is processed to avoid system restart.

[0035] In this embodiment, as Figure 3 As shown, the mobile terminal pushes the update.zip update package to the vehicle via HTTPS. The package structure is as follows: manifest.json: Digital signature, version number, list of target ECUs; firmware.bin.enc: AES-128-CBC encrypted firmware image; protocol.patch: BSDiff incremental patch; hash.sha256: A list of expected hashes for each file; T-Box uses the ECDSA-P256 public key to verify the COSE_Sign1 signature in manifest.json; if verification fails, it is discarded and error code 0xF001 is returned.

[0036] Version compatibility check: The targetVersion in the manifest must be greater than or equal to the local firmware version number, and the ECU_ID must be consistent with the local storage; otherwise, the update will be aborted.

[0037] During firmware writing and verification, the bootloader maintains an A / B dual partition table (Active partition: the currently running image; Inactive partition: the upgrade target image). Based on the partitionFlag field in the manifest, the T-Box streams and decrypts firmware.bin.enc and writes it to the starting address of the Inactive partition.

[0038] The protocolOffset field in manifest.json specifies the starting byte offset and length of the patch in update.zip.

[0039] A temporary transaction area is created at the end of the protocol library storage area, with the following structure: [Header|PatchData|CRC32|CommitMark] The header contains the old version number, the new version number, and the length L.

[0040] Patch data is written in 256-byte pages, with each page having an additional CRC32 checksum; after all pages are written, the CRC32 of the entire area is calculated and compared with the protocol_crc in the manifest.

[0041] After the CRC passes, an atomic pointer switch is performed.

[0042] If the CAN receive buffer is empty, NVIC_SystemReset() is triggered immediately to restart, and the bootloader loads the new firmware according to the BootFlag.

[0043] After the current frame is processed (by setting the frame_done flag of the parsing thread), dlopen() is called to dynamically replace libprotocol.so; The old library is automatically unloaded after its reference count reaches zero, and the CAN interrupt remains active throughout the process, so the system does not need to be restarted.

[0044] Specifically, the feature is that the in-vehicle IoT box implements a multi-level security protection mechanism during operation, specifically including: Upon power-up, the digital signatures of the bootloader and operating system kernel are verified based on the trusted root key; if the verification fails three times in a row, the system is locked and the temporary protocol patch in non-volatile memory is erased. Independent address spaces are divided by a memory management unit: the protocol parsing thread runs in a sandbox environment, and the offline caching thread runs in an encrypted memory area; the Bluetooth communication channel and the cellular network channel are isolated by a hardware firewall, and shared data needs to be converted by an encryption engine.

[0045] Specifically, the in-vehicle IoT box executes a low-power data preservation strategy after the vehicle is turned off: Real-time monitoring of power supply characteristics changes of the vehicle diagnostic interface; when a voltage decay characteristic that meets the preset shutdown judgment condition is detected, the high-power communication module and data processing unit are shut down, while the low-power wireless monitoring module is retained. The sequence of data frames to be uploaded in the offline cache is encrypted using a symmetric encryption algorithm and then transferred to a non-volatile, anti-interference memory; the physical storage location mapping relationship, time metadata range, and data integrity verification code of the encrypted data frames are generated and stored; The device status identifier is broadcast through the low-power wireless monitoring module. When the mobile terminal meets the preset near-field communication conditions, the established Bluetooth secure connection is automatically reused. When the power supply of the vehicle diagnostic interface is detected to be restored to the nominal operating voltage range, the high-power communication module is immediately restarted and the data upload service is restored.

[0046] Specifically, the batch verification mechanism includes: Before initiating the upload operation, the vehicle-mounted IoT box divides the sequence of data frames to be uploaded in the local offline cache into continuous data batches according to a preset number of frames; generates a cyclic redundancy check code independently for each data batch, and encapsulates the check code set of all batches in the first frame transmission message; After receiving the data frame sequence and check code set in the IoT cloud, the real-time check code of the received data is calculated frame by frame. The real-time check code is compared with the received check code set. When the check result of a specific data batch is found to be inconsistent, a retransmission request containing the abnormal batch identifier and frame sequence abnormal location information is returned to the vehicle IoT box. The vehicle-mounted IoT box performs data retransmission only for abnormal data batches according to the retransmission request; the verification feedback and retransmission process is repeated until all data batches pass the integrity verification. After the overall verification is passed, the cloud sends a global confirmation command. The vehicle IoT box deletes the confirmed uploaded local data according to the command. If a specific batch of data still fails to pass the verification after multiple retransmissions, it is transferred to the persistent storage management area and resubmitted for verification after the communication link is restored to stability.

[0047] The above description is merely a preferred embodiment of the present invention and is not intended to limit the present invention in any way. Although the present invention has been disclosed above with reference to preferred embodiments, it is not intended to limit the present invention. Any person skilled in the art can make some modifications or alterations to the above-disclosed technical content to create equivalent embodiments without departing from the scope of the present invention. Any simple modifications, equivalent changes and alterations made to the above embodiments based on the technical essence of the present invention without departing from the scope of the present invention shall still fall within the scope of the present invention.

Claims

1. An offline-Bluetooth collaborative adaptation and update method for an in-vehicle Internet of Things (IoT) communication system, characterized in that, include: S1: The in-vehicle IoT box is connected to the vehicle bus via the OBD interface; When the vehicle-mounted IoT box is connected for the first time or the engine model is changed, the engine real-time data frame is read and the engine data specifications are parsed and identified. S2: The identified engine data specifications are matched with the protocol library stored locally in the vehicle IoT box. If the match is successful, the operation continues according to the matching protocol; if the match fails, the vehicle IoT box establishes a secure connection with the mobile terminal through the Bluetooth channel, receives the update package pushed by the mobile terminal that matches the engine data specifications, and loads the update package into the corresponding component firmware and protocol library inside the vehicle IoT box for adaptation and update. S3: The vehicle-mounted IoT box periodically performs network reachability detection, establishes a data link through the cellular mobile communication network, sends a handshake message to the preset IoT cloud signaling address and waits for a response; If no valid response within the expected latency threshold is received within the continuous detection period, the current time period is determined to be in a network unreachable state, and a local offline caching strategy is activated. The collected vehicle operation data is written to the non-volatile storage area in the form of a circular queue according to the time sequence, and the earliest data frame is overwritten according to the first-in-first-out principle when the storage capacity reaches the upper limit. S4: In each detection cycle, if the vehicle-mounted IoT box detects that the cellular mobile communication network has been restored and can reach the IoT cloud through the mobile terminal proxy after the Bluetooth channel is re-established with the mobile terminal, the offline caching strategy is terminated, and the complete data frame sequence in the local offline cache is uploaded to the IoT cloud according to the batch verification mechanism. After the upload is completed, the successfully confirmed data frames are deleted.

2. The method according to claim 1, characterized in that, The storage capacity of the circular queue described in S3 is up to 512 frames of data. Each frame of data contains a timestamp, vehicle VIN code, and a set of engine operating parameters.

3. The method according to claim 1, characterized in that, The specific steps in S4 for reaching the IoT cloud via a mobile terminal agent include: The in-vehicle IoT box sends a cloud connection request carrying an encrypted identity token to the mobile terminal via Bluetooth. The mobile terminal uses its own cellular network to establish an HTTPS tunnel with the IoT cloud and forwards the request to the cloud through the tunnel; After verifying the validity of the identity token in the cloud, a successful proxy connection response is returned to the mobile terminal, which then forwards it to the in-vehicle IoT box.

4. The method according to claim 1, characterized in that, The pattern matching method described in S2 is as follows: Extract the physical layer features of the engine real-time data frames, including baud rate, frame length, and parity bit position, and perform a first-level match with the preset physical features of each protocol template in the protocol library; After the physical layer feature matching is successful, the storage offset address of the engine speed PID value and oxygen sensor PID value is located from the application layer of the data frame, and the offset address is matched with the preset address range of the corresponding protocol template in the protocol library for a second level. When physical layer feature matching fails but critical PID address matching fails, the data frame load area is traversed in 16-byte window units; the entropy volatility and numerical distribution dispersion of the data within the window are calculated in real time; based on the preset entropy volatility and dispersion judgment threshold, the current traversal window that meets the threshold condition is determined as the critical PID data area, and the current traversal window that does not meet the threshold condition is determined as the non-critical data area. Extract the gradient of the numerical sequence change of the suspected key PID data area; if the gradient of the numerical sequence change is consistent with the pre-stored standard engine speed change model within a preset similarity tolerance range, then the key PID data area is determined to be a valid engine speed PID data area. If the gradient of the numerical sequence change is consistent with the pre-stored standard oxygen sensor voltage and air-fuel ratio change model within the preset similarity tolerance range, then the suspected key PID data area is determined to be a valid oxygen sensor PID data area. Based on the identified valid PID data area and its offset address, a temporary protocol patch is generated and loaded into the protocol library of the vehicle IoT box.

5. The method according to claim 1, characterized in that, The engine real-time data frames mentioned in S1 are broadcast by the engine control unit via the vehicle bus at fixed time intervals, and the format of the data frames conforms to the J139 standard.

6. The method according to claim 1, characterized in that, The parsing and identification method described in S1 is as follows: Extract the frame start identifier, frame length field and frame end identifier from the engine real-time data frame to determine the effective boundary and load area of ​​the data frame; Calculate the cyclic redundancy check code based on the load area and compare it with the check code carried in the data frame; If the verification fails, the frame is discarded and a rereading mechanism is triggered. The sliding window matching algorithm identifies preset key fields in the load area, including engine control unit address code, service identifier, and parameter identifier location marker. Based on the identified engine control unit address code, service identifier distribution pattern, and parameter identifier density characteristics, an engine data specification descriptor containing physical layer parameters, application layer data structures, and key parameter identifier offset addresses is generated.

7. The method according to claim 1, characterized in that, The method for adaptation and updating is as follows: After receiving the update package pushed by the mobile terminal, verify the digital signature and version compatibility; parse the header fields of the update package to obtain metadata including the target firmware partition identifier, the offset of the protocol library update segment, and the checksum; Based on the target firmware partition identifier, the firmware image in the update package is written to the inactive storage partition of the vehicle IoT box; After the write operation is complete, an integrity check is triggered: the hash value of the firmware for this partition is calculated and compared with the expected hash value declared in the update package; After the verification is successful, the boot flag of the bootloader is switched so that the system will boot from the updated inactive partition on the next restart; Based on the offset of the updated segment in the protocol library, locate the temporary protocol patch data block in the update packet; Create a temporary transaction area in the unallocated storage area of ​​the protocol library and write the patch data in the form of a transaction log; Once all patch data has been written and the CRC check passes, the protocol library index table is atomically pointed to the new data area, and the storage space of the old protocol template is reclaimed. If there is no real-time data parsing task at present, the vehicle IoT box will be restarted immediately to make the update effective; if there is an ongoing parsing task, the new protocol library will be loaded through dynamic link library injection after the current data frame is processed to avoid system restart.

8. The method according to claim 1, characterized in that, The in-vehicle IoT box implements a multi-level security protection mechanism during operation, specifically including: Upon power-up, the digital signatures of the bootloader and operating system kernel are verified based on the trusted root key; if the verification fails three times in a row, the system is locked and the temporary protocol patch in non-volatile memory is erased. Independent address spaces are divided by a memory management unit: the protocol parsing thread runs in a sandbox environment, and the offline caching thread runs in an encrypted memory area; the Bluetooth communication channel and the cellular network channel are isolated by a hardware firewall, and shared data needs to be converted by an encryption engine.

9. The method according to claim 1, characterized in that, The in-vehicle IoT box executes a low-power data preservation strategy after the vehicle is turned off: Real-time monitoring of power supply characteristics changes of the vehicle diagnostic interface; when a voltage decay characteristic that meets the preset shutdown judgment condition is detected, the high-power communication module and data processing unit are shut down, while the low-power wireless monitoring module is retained. The sequence of data frames to be uploaded in the offline cache is encrypted using a symmetric encryption algorithm and then transferred to a non-volatile, anti-interference memory. Generate and store the physical storage location mapping relationship of encrypted data frames, the time metadata range, and the data integrity verification code; The device status identifier is broadcast through the low-power wireless monitoring module. When the mobile terminal meets the preset near-field communication conditions, the established Bluetooth secure connection is automatically reused. When the power supply of the vehicle diagnostic interface is detected to be restored to the nominal operating voltage range, the high-power communication module is immediately restarted and the data upload service is restored.

10. The method according to claim 1, characterized in that, The batch verification mechanism includes: Before initiating the upload operation, the vehicle-mounted IoT box divides the sequence of data frames to be uploaded in the local offline cache into continuous data batches according to a preset number of frames; generates a cyclic redundancy check code independently for each data batch, and encapsulates the check code set of all batches in the first frame transmission message; After receiving the data frame sequence and check code set in the IoT cloud, the real-time check code of the received data is calculated frame by frame. The real-time check code is compared with the received check code set. When the check result of a specific data batch is found to be inconsistent, a retransmission request containing the abnormal batch identifier and frame sequence abnormal location information is returned to the vehicle IoT box. The vehicle-mounted IoT box performs data retransmission only for abnormal data batches according to the retransmission request; the verification feedback and retransmission process is repeated until all data batches pass the integrity verification. After the overall verification is passed, the cloud sends a global confirmation command. The vehicle IoT box deletes the confirmed uploaded local data according to the command. If a specific batch of data still fails to pass the verification after multiple retransmissions, it is transferred to the persistent storage management area and resubmitted for verification after the communication link is restored to stability.

Images