CAN network cloud extension method and system in Internet of Things environment

Abstract

The invention relates to a CAN network cloud extension method and system in an Internet of Things environment. The method comprises the following steps: loading a physical layer protocol stack and a preset security certificate by adopting a dual-core processor, generating a related buffer area and a secret key, registering a publishing-subscribing theme pair to a cloud end based on an equipment identity secret key, and establishing a theme mapping relation between equipment and a dual-channel availability flag bit; extracting a CAN message from the buffer area to generate a data frame with metadata, packaging the data frame into a secure MQTT load through an encryption channel, uploading the secure MQTT load to a cloud end, and analyzing a cloud end instruction to generate a physical CAN-ID instruction set; realizing cross-domain instruction transparent transmission according to a theme mapping relation, and dynamically adjusting communication parameters according to a network quality collaborative report; and finally, triggering an off-network continuous transmission strategy according to the dual-channel availability flag bit, and dynamically allocating a bus access right in combination with a conflict time period thermodynamic diagram. The problems of real-time performance and reliability defects existing in interaction between a traditional CAN network and the cloud are solved, and efficient cloud extension of the CAN network in the environment of the Internet of Things is achieved.

Description

Technical Field

[0001] The present invention belongs to the technical field of Internet of Things, and in particular relates to a CAN network cloud extension method and system in an Internet of Things environment. Background Art

[0002] In the field of Internet of Vehicles and Industrial Internet of Things, the interaction between traditional CAN network devices and the cloud usually adopts a direct connection architecture with a single communication channel. This architecture has significant real-time and reliability defects.

[0003] Existing technologies often rely on a single-core processor to sequentially handle CAN message parsing and network communication tasks when devices transmit data to the cloud. This can lead to uncontrollable transmission delays for critical commands in high-load scenarios. Furthermore, control commands issued from the cloud rely on a central server for device addressing and protocol conversion. This centralized processing model creates additional communication loops when direct interaction between devices is required, severely restricting the real-time response requirements of industrial control scenarios.

[0004] What is more prominent is that when the network environment is unstable, the existing solutions lack an intelligent fault-tolerant mechanism for communication interruptions. Devices often directly discard unsent CAN messages, resulting in the loss of key control instructions.

[0005] In addition, most systems use the MQTT communication mode with fixed topics. The communication paths between devices need to be statically configured in advance, which makes it difficult to adapt to dynamically changing device group relationships.

[0006] The above technical defects make it difficult for existing systems to balance the contradictions between real-time performance, reliability and resource overhead when IoT devices are deployed on a large scale, which restricts the implementation of CAN networks extending to the cloud. Summary of the Invention

[0007] Based on this, it is necessary to provide a CAN network cloud extension method and system in an Internet of Things environment to address the above technical problems.

[0008] In a first aspect, the present application provides a CAN network cloud extension method in an IoT environment, comprising:

[0009] S1. Load the physical layer protocol stack and pre-set the security certificate on the dual-core processor to generate a CAN message receiving ring buffer and device identity key;

[0010] S2. Register a publish-subscribe topic pair with the cloud based on the device identity key, establish a topic mapping table between devices, and a dual-channel availability flag;

[0011] S3. Extract CAN messages from the CAN message receiving ring buffer to generate data frames with metadata. Encapsulate the data frames into secure MQTT payloads according to the inter-device topic mapping table. Upload the secure MQTT payloads to the cloud through the publish topic in the publish-subscribe topic pair. Simultaneously, receive cloud instructions through the subscribe topic in the publish-subscribe topic pair to generate a physical CAN-ID instruction set.

[0012] S4. Transmit the secure MQTT payload to the target device’s subscription topic based on the inter-device topic mapping table, and generate a network quality collaboration report based on the physical CAN-ID instruction set;

[0013] S5. Trigger the network-disconnected transmission resumption strategy based on the dual-channel availability flag, and dynamically allocate bus access rights based on the conflict period heat map of the network quality collaborative report.

[0014] In a second aspect, the present application also provides a CAN network cloud extension system in an IoT environment, including:

[0015] The protocol and security configuration module is used to load the physical layer protocol stack and pre-set the security certificate for the dual-core processor, and generate the CAN message receiving ring buffer and device identity key;

[0016] The topic registration and mapping module is used to register publish-subscribe topic pairs with the cloud based on the device identity key, establish the topic mapping relationship table between devices and the dual-channel availability flag;

[0017] The data processing and transmission module is used to extract CAN messages from the CAN message receiving ring buffer to generate data frames with metadata, encapsulate the data frames into secure MQTT payloads based on the inter-device topic mapping relationship table, and upload the secure MQTT payloads to the cloud through the publish topic in the publish-subscribe topic pair. At the same time, it receives instructions from the cloud through the subscribe topic in the publish-subscribe topic pair and generates a physical CAN-ID instruction set.

[0018] The data transmission and reporting module is used to transparently transmit the secure MQTT payload to the target device's subscription topic according to the inter-device topic mapping table, and generate a network quality collaborative report based on the physical CAN-ID instruction set;

[0019] The network management module is used to trigger the network disconnection and resumption strategy based on the dual-channel availability flag, and dynamically allocate bus access rights based on the conflict period heat map of the network quality collaborative report.

[0020] In a third aspect, the present application further provides a computer device comprising a memory and a processor, wherein the memory stores a computer program, and when the processor executes the computer program, it implements a CAN network cloud extension method in an Internet of Things environment as described in the first aspect.

[0021] In a fourth aspect, the present application further provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements a CAN network cloud extension method in an Internet of Things environment as described in the first aspect.

[0022] The aforementioned method and system for extending a CAN network to the cloud in an IoT environment utilizes a dual-core processor to load a physical layer protocol stack and pre-installed security certificates, generating relevant buffers and keys. Based on the device identity key, the system registers publish-subscribe topic pairs with the cloud, establishing inter-device topic mappings and a dual-channel availability flag. CAN messages are then extracted from the buffer to generate data frames with metadata, which are then encapsulated as secure MQTT payloads and uploaded to the cloud via an encrypted channel. Cloud commands are then parsed to generate physical CAN-ID instruction sets. Cross-domain command transmission is then transparently implemented based on the topic mappings, and communication parameters are dynamically adjusted based on network quality collaborative reports. Finally, a network-disconnected retransmission strategy is triggered based on the dual-channel availability flag, and bus access rights are dynamically allocated based on a conflict period heat map. This method effectively addresses the real-time and reliability deficiencies of traditional CAN networks interacting with the cloud, overcoming drawbacks such as uncontrollable transmission delays in high-load scenarios, communication detours caused by cloud-issued commands, a lack of intelligent fault-tolerance mechanisms when the network is unstable, and difficulty adapting to dynamic device group relationships. This method enables efficient cloud-based extension of CAN networks in IoT environments, improving the real-time and reliability of inter-device communication, optimizing resource overhead, and enhancing the effectiveness of extending CAN networks to the cloud. BRIEF DESCRIPTION OF THE DRAWINGS

[0023] In order to more clearly illustrate the technical solutions in the embodiments of the present application or related technologies, the following briefly introduces the drawings required for use in the embodiments or related technical descriptions. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0024] Figure 1 A flow chart of a CAN network cloud extension method in an Internet of Things environment provided by the present invention;

[0025] Figure 2 Schematic diagram of the process of step S2 in an optional embodiment of the present invention;

[0026] Figure 3 Schematic diagram of the process of step S3 in an optional embodiment of the present invention;

[0027] Figure 4 Schematic diagram of the process of step S4 in an optional embodiment of the present invention;

[0028] Figure 5 This is a structural diagram of a CAN network cloud extension system in an Internet of Things environment provided by the present invention. DETAILED DESCRIPTION

[0029] In order to make the purpose, technical solutions and advantages of this application more clear, the following further describes this application in detail with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain this application and are not intended to limit this application.

[0030] refer to Figure 1 , which presents a flow chart of a CAN network cloud extension method in an IoT environment provided by this application, the method comprising the following steps:

[0031] S1. Load the physical layer protocol stack and pre-set the security certificate on the dual-core processor to generate a CAN message receiving ring buffer and a device identity key.

[0032] Specifically, the physical layer protocol stack can be loaded and security certificates pre-set on the ESP32 dual-core processor. The ESP32 features a 32-bit dual-core processor with a normal CPU operating speed of 80MHz, reaching a maximum of 240MHz, and a computing power of up to 600 MIPS. It has 448KB of built-in ROM and 520KB of SRAM, and supports up to 16MB of off-chip SPI Flash and 8MB of off-chip SPI SRAM. Its powerful processing and storage capabilities provide hardware support for subsequent complex data processing tasks. The CAN2.0B protocol physical layer protocol stack, compliant with the ISO11898 specification, is loaded to ensure compatibility and communication compliance between the device and the CAN bus. Security certificates are pre-set, and a CAN message receiving ring buffer and device identity key are generated. The ring buffer efficiently stores received CAN messages to prevent data loss. The device identity key is used for secure authentication of the device in the cloud and for identity identification and encryption and decryption operations during subsequent data interaction.

[0033] S2. Register publish-subscribe topic pairs with the cloud based on the device identity key, establish a topic mapping relationship table between devices and a dual-channel availability flag.

[0034] Specifically, based on a pre-generated device identity key, the device registers a unique publish-subscribe topic pair with the cloud. Leveraging the ESP32's WiFi communication capabilities, the device achieves a fast and stable connection to the cloud. The inter-device topic mapping table details the associations and mappings between different device topics, providing a basis for accurate data forwarding between subsequent devices. A dual-channel availability flag monitors the operating status of two communication channels—the CAN channel and the network channel—in real time, providing a basis for triggering response strategies in the event of communication interruptions.

[0035] S3. Extract CAN messages from the CAN message receiving ring buffer to generate data frames with metadata, encapsulate the data frames into secure MQTT payloads according to the inter-device topic mapping relationship table, and upload the secure MQTT payloads to the cloud through the publish topic in the publish-subscribe topic pair; at the same time, receive instructions from the cloud through the subscribe topic in the publish-subscribe topic pair to generate a physical CAN-ID instruction set.

[0036] Specifically, CAN messages are extracted from the CAN message receiving ring buffer and complete data frames are generated by adding necessary metadata. Leveraging the processing power of the ESP32, CAN messages are parsed and processed, adding metadata containing key information such as the message generation timestamp, device identification, and data type. This provides important context for subsequent cloud-based data analysis and accurate command generation. Based on the inter-device topic mapping table, the generated data frames are encapsulated into secure MQTT payloads. This encapsulation process not only involves data format conversion but also encrypts the data using the device identity key to ensure data security during transmission. The secure MQTT payload is uploaded to the cloud by publishing to a topic, while commands issued by the cloud are received by subscribing to topics. The freeRTOS multitasking operating system, based on the official ESP-IDF, is integrated into the ESP32. Officially defined Wi-Fi events are invoked during Wi-Fi connections, triggering an automatic reconnection procedure when Wi-Fi is disconnected, ensuring stable communication. Upon receiving cloud commands, they are parsed and processed to generate a physical CAN-ID instruction set. This instruction set corresponds to the physical identifier used in CAN network communications, enabling accurate execution of the corresponding instructions on the CAN network.

[0037] S4. Transmit the secure MQTT payload to the target device's subscription topic according to the inter-device topic mapping relationship table, and generate a network quality collaboration report based on the physical CAN-ID instruction set.

[0038] Specifically, based on the inter-device topic mapping table, previously uploaded secure MQTT payloads are precisely transparently transmitted to the target device's subscribed topics, enabling data exchange between devices. Using the ESP32, two tasks and a queue are created. One task receives messages from the MQTT server, parses the JSON data, and sends the parsed CAN ID and content to the vehicle via the CAN network. It also determines whether there are any CAN messages in the queue to send to the server. The other task continuously checks for messages on the CAN network. If a message appears, it packages the message in JSON format, sends the packaged string to the queue, and then sends the message content to the server through the previous task, achieving efficient data transmission. Based on the generated physical CAN-ID instruction set, network communication quality is monitored and analyzed, generating a collaborative report containing multi-dimensional network quality indicators. The report covers key parameters such as communication latency, packet loss rate, and signal strength, comprehensively reflecting the network's operating status and providing data support for network optimization and adjustment.

[0039] S5. Trigger the network-disconnected transmission resumption strategy based on the dual-channel availability flag, and dynamically allocate bus access rights based on the conflict period heat map of the network quality collaborative report.

[0040] Specifically, based on the status information monitored by the dual-channel availability flag, a preset network interruption and transmission resumption strategy is triggered when a network interruption is detected. Leveraging the ESP32's storage capabilities, a local cache mechanism is activated to temporarily store pending data. Upon detecting network recovery, the connection is automatically reestablished and data transmission resumes, ensuring data transmission integrity. Furthermore, the conflict period heat map in the network quality collaboration report is combined to analyze the distribution of network conflicts in different time periods. Bus access rights are dynamically adjusted to prioritize data communication for critical devices, optimize network resource utilization, and enhance the reliability and real-time performance of the overall communication system.

[0041] The aforementioned method for extending a CAN network to the cloud in an IoT environment utilizes a dual-core processor to load a physical layer protocol stack and pre-installed security certificates, generating relevant buffers and keys. Based on the device identity key, it registers publish-subscribe topic pairs with the cloud, establishing inter-device topic mappings and a dual-channel availability flag. CAN messages are then extracted from the buffer to generate data frames with metadata, encapsulated as secure MQTT payloads via an encrypted channel and uploaded to the cloud. Cloud commands are then parsed to generate physical CAN-ID instruction sets. Cross-domain command transparent transmission is then achieved based on the topic mappings, and communication parameters are dynamically adjusted based on network quality collaborative reports. Finally, a network-disconnected retransmission strategy is triggered based on the dual-channel availability flag, and bus access rights are dynamically allocated based on a conflict period heat map. This method effectively addresses the real-time and reliability deficiencies of traditional CAN networks interacting with the cloud. It overcomes existing drawbacks such as uncontrollable transmission delays in high-load scenarios, communication detours caused by cloud-issued commands, a lack of intelligent fault-tolerance mechanisms when the network is unstable, and difficulty adapting to dynamic device group relationships. This method enables efficient cloud-based extension of CAN networks in IoT environments, improving the real-time and reliability of inter-device communication, optimizing resource consumption, and enhancing the effectiveness of CAN network extension to the cloud.

[0042] In an optional embodiment, S1 includes the following steps:

[0043] A physical layer protocol stack is loaded into core 1 of the dual-core processor, and a CAN message receiving ring buffer including a WiFi channel status table is generated based on the loaded physical layer protocol stack.

[0044] Specifically, the physical layer protocol stack can be a protocol stack that complies with the CAN 2.0B protocol and follows the ISO 11898 specification. Its main function is to implement the communication function between the data link layer and the physical layer on the CAN bus, ensuring that the device can correctly receive and send CAN messages. During the loading process, the processing power of core one is used to complete the initial configuration of the protocol stack, so that it can identify and adapt to the communication specifications of the CAN bus. After the loading of the physical layer protocol stack is completed, a CAN message receiving ring buffer containing a WiFi channel status table is further generated. The generation of this ring buffer is intended to efficiently temporarily store the message data received from the CAN bus, and combined with the WiFi channel status table, it can monitor and record the status information of the WiFi communication channel in real time, providing a basis for subsequent data transmission optimization. The WiFi channel status table records in detail the current WiFi channel usage, interference conditions and other relevant parameters. By storing this information together with the CAN message in the ring buffer, comprehensive monitoring and management of the communication process can be achieved.

[0045] Perform security certificate chain verification on core 2 of the dual-core processor, compile dynamic ID whitelist filtering rules based on the verified certificates, and generate device identity keys.

[0046] Specifically, security certificate chain verification is a critical step in ensuring secure communication between devices and the cloud. Its purpose is to verify that the device's certificate is issued by a trusted certificate authority, thereby ensuring the device's identity and communication security. During the verification process, Core 2 performs chain verification on the device's identity certificate against pre-stored root and intermediate certificates, checking key information such as the certificate's signature, validity period, and revocation status. Only when the certificate chain verification passes can communication between the device and the cloud be secure and reliable, thereby ensuring the security of subsequent data transmission. Based on the verified certificates, dynamic ID whitelist filtering rules are further compiled. These rules are compiled to filter the source IDs of messages on the CAN bus, allowing or denying messages with specific IDs, thereby enhancing system security and reliability. This dynamic compilation mechanism allows for flexible generation and update of ID whitelist filtering rules based on actual communication needs and security policies, adapting to changing communication environments and security requirements. Finally, based on the verified certificates and compiled filtering rules, a highly secure device identity key is generated. The device identity key is used for device registration and identity authentication during communication in the cloud, ensuring that the communication between the device and the cloud is unique and secure, preventing unauthorized device access and data tampering or leakage.

[0047] refer to Figure 2 In an optional embodiment, S2 includes the following steps:

[0048] S21. Initiate authentication to the cloud server based on the device identity key, and generate device-specific publishing topics and subscription topics after authentication.

[0049] Specifically, after receiving the request, the cloud server verifies the device's identity key to confirm its legitimacy. Once authenticated, the cloud server assigns the device a unique publish-subscribe topic pair. The publish topic is used by the device to send data to the cloud, while the subscribe topic is used by the device to receive commands from the cloud. After receiving the assigned topic, the device stores it in its local configuration for subsequent data uploads and command reception.

[0050] S22: parsing the naming rules of the publishing topics and subscribing topics of the paired devices, and generating a topic mapping relationship table between devices based on the matching naming rules.

[0051] Specifically, the naming rules can include information such as device identification, function type, and data flow direction. For example, a topic may be named according to the format of "device type / device ID / data type." By parsing these naming rules, the device can identify the topic structure and semantic meaning of different devices. On this basis, the device constructs a topic mapping relationship table between devices based on the topic information of the paired device and its own topic information. This mapping relationship table records the topic correspondence between devices in detail, including the mapping of local device topics to remote device topics, providing a basis for the subsequent accurate forwarding of data between devices.

[0052] S23. Connect the CAN controller error counter value to the event bus, and generate a bus health evaluation index based on the incremental change of the CAN controller error counter.

[0053] Specifically, the CAN controller error counter records the number of errors that occur during CAN bus communication. When a bus error occurs, the counter increments accordingly. After connecting to the event bus, the device can obtain real-time updates to the CAN controller error counter. Based on the incremental changes in the CAN controller error counter, the device generates a bus health assessment index using a pre-set health assessment algorithm. This index can be presented as a percentage or fraction, reflecting the current communication health of the CAN bus. For example, a large error counter increment decreases the health assessment index, while a small error counter increment increases it.

[0054] S24. Perform a logical AND operation on the WiFi channel status table and the bus health evaluation index to generate a dual-channel availability flag that controls the start and stop of the data pipeline.

[0055] Specifically, the WiFi channel status table reflects the quality and availability of the current WiFi channel, while the bus health assessment indicator reflects the communication status of the CAN bus. Through a logical AND operation, these two status information are comprehensively evaluated to generate a dual-channel availability flag that controls the start and stop of the data pipeline. For example, the dual-channel availability flag is valid only when the WiFi channel is in good condition and the CAN bus is in high health, allowing the data pipeline to operate normally. If either condition is not met, the flag is invalid, triggering a data pipeline pause or the implementation of other protective measures to ensure reliable and stable data transmission.

[0056] refer to Figure 3 In an optional embodiment, S3 includes the following steps:

[0057] S31. Extracting raw data from the CAN message receiving ring buffer, adding a timestamp to the raw data based on a hardware clock signal, and generating a data frame with metadata.

[0058] Specifically, the ring buffer is generated based on the CAN 2.0B protocol stack loaded on Core 1 of the ESP32 dual-core processor, efficiently storing messages received from the CAN bus. During the extraction process, the ring buffer's read and write pointer mechanism ensures data order and integrity, preventing data loss or misordering.

[0059] Leveraging the ESP32's built-in high-precision hardware clock, we add precise timestamp information to each piece of extracted raw data. This timestamp uses a standard time format to record the exact moment the data was generated, providing a time reference for subsequent cloud-based data analysis and ensuring data timeliness and traceability.

[0060] In addition to timestamps, other key metadata can be added, including device identification, data type, and data length. Device identification distinguishes data generated by different devices, data type indicates the specific meaning of the data, and data length specifies the payload size. These metadata are combined with the original data to form a complete and standardized data frame, improving data readability and usability.

[0061] S32. Encapsulate the data frame in JSON format according to the device ID in the inter-device subject mapping relationship table to generate an encryption-ready data block.

[0062] Specifically, the inter-device topic mapping table records the correspondence between devices and topics. Based on the device ID information in this table, the data frame is encapsulated in JSON format. JSON format is highly readable and easy to parse, facilitating rapid processing and analysis in the cloud. During the encapsulation process, the data frame contents are mapped to key-value pairs in JSON objects, ensuring data integrity and accuracy, and generating encryption-ready data blocks.

[0063] S33. Call the encryption engine associated with the device identity key, perform AES-GCM encryption on the encryption-ready data block, generate a secure MQTT payload, and inject the secure MQTT payload into the cloud by publishing the topic.

[0064] Specifically, the ESP32's built-in cryptographic engine, using the previously generated device identity key, executes the AES-GCM encryption algorithm on the encryption-ready data block. AES-GCM encryption not only ensures data confidentiality but also integrity and authenticity. The encryption process generates key material based on the device identity key. The encryption engine then encrypts the encryption-ready data block into a secure MQTT payload, preventing data theft or tampering during transmission.

[0065] Leveraging the ESP32's WiFi communication capabilities, data can be uploaded to the cloud quickly and reliably. Within the ESP32's integrated freeRTOS multitasking operating system, based on ESP-IDF, a dedicated task handles the sending of MQTT messages. This task retrieves the encrypted, secure MQTT payload from the queue and publishes it to the cloud's MQTT server via a pre-registered publish topic, enabling seamless data transmission from the device to the cloud.

[0066] S34. Receive the MQTT message sent down from the cloud by subscribing to the topic, and generate a physical CAN-ID instruction set based on the dynamic ID whitelist filtering rules and the MQTT message.

[0067] Specifically, leveraging the ESP32's WiFi communication capabilities and the freeRTOS multitasking operating system, the device maintains real-time communication with the cloud by subscribing to topics and receiving command messages from the cloud. After preliminary parsing, received MQTT messages are then verified for security and filtered according to dynamic ID whitelist filtering rules. Based on previously compiled rules, the dynamic ID whitelist filtering rules allow or deny messages with specific IDs, ensuring that received command messages originate from a trusted cloud source and fall within the device's intended operating range.

[0068] The validated and filtered MQTT messages are further parsed to extract the command content. Based on the device's CAN network communication specifications and predefined command mappings, the cloud-based commands are converted into a specific physical CAN-ID instruction set. This instruction set corresponds to the physical identifier on the CAN bus and can directly instruct devices on the CAN bus to perform the corresponding operation, such as controlling a vehicle actuator or adjusting a parameter, thereby enabling remote and precise control of CAN network devices from the cloud.

[0069] refer to Figure 4 In an optional embodiment, S4 includes the following steps:

[0070] S41. Parse the logical device ID in the secure MQTT payload, locate the subscription topic of the target device based on the inter-device topic mapping relationship table, and generate a cross-domain instruction routing path.

[0071] Specifically, secure MQTT payloads carry a wealth of data information, including a logical device ID that uniquely identifies the device participating in the communication. During parsing, the ESP32 leverages its processing power to decrypt the payload (e.g., using the AES-GCM decryption algorithm) and parse the data format to extract the critical logical device ID information. This logical device ID allows devices to identify the source or destination of the data, providing the basis for subsequent data routing.

[0072] The subscription topic of the target device is located based on the inter-device topic mapping relationship table. The inter-device topic mapping relationship table records the correspondence between devices and topics. By searching for entries in the table that match the parsed logical device ID, the subscription topic of the target device can be accurately located. This process ensures that data can be sent to the specified device accurately and achieves efficient communication between devices. After locating the subscription topic of the target device, a cross-domain instruction routing path is further generated. This path defines the data transmission channel and forwarding rules from the current device to the target device, ensuring that instructions can accurately reach the target device across different network domains (such as the CAN network and the cloud network).

[0073] S42. Inject the physical CAN-ID instruction set into the CAN sending queue according to the cross-domain instruction routing path, synchronously collect the channel response delay and number of conflicts received through the subscription topic, and generate a network quality collaboration report.

[0074] Specifically, the cross-domain command routing path not only defines the data transmission channel but also includes data transmission priority and sequence information. When the physical CAN-ID command set is injected into the CAN transmit queue, the priority and sequence information in the routing path is used to arrange the command transmission order, ensuring that critical commands are sent first. At the same time, the ESP32 hardware resources and processing power are utilized to perform the necessary format conversion and optimization of the command set, ensuring that the commands are sent to the CAN bus according to the correct format and protocol.

[0075] Synchronously collect channel response latency and collision counts received through subscribed topics to generate a collaborative network quality report. During the command transmission process, the device receives real-time response information from the target device or network node through the subscribed topic. Channel response latency reflects the delay between command transmission and reception, while collision counts record conflicts that occurred during CAN bus communication. This data is synchronously collected in real time via the event bus mechanism and used to generate a collaborative network quality report. The report also incorporates multi-dimensional information such as the WiFi channel status table and incremental changes in the CAN controller error counter to comprehensively reflect the current communication network operating status and potential issues.

[0076] S43. Based on the transmission load status of the cross-domain instruction routing path and the conflict period heat map of the network quality collaborative report, the MQTT payload sending frequency of the publishing topic is dynamically adjusted.

[0077] Specifically, the transmission load status of the cross-domain command routing path reflects the current network load and transmission efficiency, while the conflict period heat map visually displays the distribution of network conflicts in different time periods. By analyzing this information, the device can identify time periods with high network load and frequent conflicts. During these time periods, the frequency of sending MQTT payloads is appropriately reduced to reduce network load and the probability of conflicts. During periods of good network conditions, the frequency of sending can be appropriately increased to optimize data transmission efficiency. This dynamic adjustment mechanism not only improves the stability and reliability of the overall communication system, but also effectively extends the service life of the equipment and reduces the system's operating costs.

[0078] In an optional embodiment, S5 includes the following steps:

[0079] When the dual-channel availability flag is in an abnormal state, a disconnected transmission queue is generated based on the command priority of the secure MQTT payload.

[0080] Specifically, the priority of commands in the secure MQTT payload can be predefined based on their urgency, importance, and impact on system operation. For example, commands related to critical vehicle safety functions have a higher priority, while routine data upload commands have a lower priority. When generating the network resumable transmission queue, high-priority commands are prioritized to ensure that critical commands are processed first within the limited communication recovery time. The network resumable transmission queue is stored based on the ESP32's off-chip SPIFlash and SPI SRAM, supporting up to 16MB of Flash for storing large amounts of offline data, and 8MB of SRAM to ensure fast data reading and writing, thereby ensuring the efficiency and reliability of network resumable transmission.

[0081] Analyze the conflict period heat map of the network quality collaborative report, and insert a virtual time window offset into the network interruption and resumption queue based on the spatiotemporal distribution characteristics of the heat map.

[0082] Specifically, the conflict period heat map visually displays the distribution of communication conflicts at different time points and between different devices. Based on the temporal and spatial distribution characteristics, the device inserts a virtual time window offset into the network disconnection and transmission resumption queue. This virtual time window offset is inserted to optimize data transmission timing and avoid sending data during periods of high conflict. By analyzing the heat map, time periods with fewer network conflicts are identified and data transmission tasks are shifted to these periods, thereby reducing the probability of communication conflicts and improving the success rate of data transmission.

[0083] The bus access right allocation strategy is reconstructed according to the virtual time window offset, and the access right parameters in the adjusted bus access right allocation strategy are injected into the dual-channel availability flag calculation model to complete the dynamic allocation.

[0084] Specifically, traditional bus access rights allocation strategies are usually based on fixed time slices or priorities, while this method introduces a virtual time window offset to enable dynamic adjustment of bus access rights allocation. The device adjusts the allocation order and duration of bus access rights based on the offset to ensure that data transmission can be completed with higher efficiency under the same communication resources. The adjusted bus access rights allocation strategy is injected into the dual-channel availability flag calculation model through a specific parameter interface. This calculation model comprehensively considers factors such as the current network status, CAN bus load, and inter-device communication requirements, and dynamically adjusts the availability flags of the dual channels, thereby realizing real-time dynamic allocation of bus access rights.

[0085] The aforementioned method for extending a CAN network to the cloud in an IoT environment utilizes a dual-core processor to load a physical layer protocol stack and pre-installed security certificates, generating relevant buffers and keys. Based on the device identity key, it registers publish-subscribe topic pairs with the cloud, establishing inter-device topic mappings and a dual-channel availability flag. CAN messages are then extracted from the buffer to generate data frames with metadata, encapsulated as secure MQTT payloads via an encrypted channel and uploaded to the cloud. Cloud commands are then parsed to generate physical CAN-ID instruction sets. Cross-domain command transparent transmission is then achieved based on the topic mappings, and communication parameters are dynamically adjusted based on network quality collaborative reports. Finally, a network-disconnected retransmission strategy is triggered based on the dual-channel availability flag, and bus access rights are dynamically allocated based on a conflict period heat map. This method effectively addresses the real-time and reliability deficiencies of traditional CAN networks interacting with the cloud. It overcomes existing drawbacks such as uncontrollable transmission delays in high-load scenarios, communication detours caused by cloud-issued commands, a lack of intelligent fault-tolerance mechanisms when the network is unstable, and difficulty adapting to dynamic device group relationships. This method enables efficient cloud-based extension of CAN networks in IoT environments, improving the real-time and reliability of inter-device communication, optimizing resource consumption, and enhancing the effectiveness of CAN network extension to the cloud.

[0086] It should be understood that, although the various steps in the flowcharts involved in the various embodiments described above are displayed in sequence according to the instructions of the arrows, these steps are not necessarily executed in sequence in the order indicated by the arrows. Unless otherwise specified herein, there is no strict order restriction on the execution of these steps, and these steps can be executed in other orders. Moreover, at least a portion of the steps in the flowcharts involved in the various embodiments described above can include multiple steps or multiple stages, and these steps or stages are not necessarily executed and completed at the same time, but can be executed at different times, and the execution order of these steps or stages is not necessarily to be carried out in sequence, but can be executed in turn or alternately with other steps or at least a portion of steps or stages in other steps.

[0087] Based on the same inventive concept, embodiments of the present application also provide a system for implementing the aforementioned method for extending a CAN network to the cloud in an IoT environment. The solution provided by this system is similar to the solution described in the aforementioned method. Therefore, the specific limitations of the embodiments of one or more CAN network cloud extension systems in an IoT environment provided below can be found in the aforementioned limitations of the method for extending a CAN network to the cloud in an IoT environment, and will not be further elaborated here.

[0088] In an exemplary embodiment, Figure 5 As shown, a CAN network cloud extension system 50 in an Internet of Things environment is provided, including:

[0089] The protocol and security configuration module 51 is used to load the physical layer protocol stack and preset the security certificate to the dual-core processor, and generate a CAN message receiving ring buffer and a device identity key.

[0090] The topic registration and mapping module 52 is used to register the publish-subscribe topic pair with the cloud based on the device identity key, and establish a topic mapping relationship table between devices and a dual-channel availability flag.

[0091] The data processing and transmission module 53 is used to extract CAN messages from the CAN message receiving ring buffer to generate data frames with metadata, encapsulate the data frames into secure MQTT payloads according to the inter-device topic mapping relationship table, and upload the secure MQTT payloads to the cloud through the publishing topic in the publish-subscribe topic pair; at the same time, it receives instructions from the cloud through the subscription topic in the publish-subscribe topic pair to generate a physical CAN-ID instruction set.

[0092] The data transmission and reporting module 54 is used to transmit the secure MQTT payload to the subscription topic of the target device according to the inter-device topic mapping relationship table, and generate a network quality collaborative report based on the physical CAN-ID instruction set.

[0093] The network management module 55 is used to trigger the network disconnection and resumption strategy according to the dual-channel availability flag, and dynamically allocate bus access rights in combination with the conflict period heat map of the network quality collaborative report.

[0094] Optional, protocol and security configuration modules include:

[0095] The protocol loading and buffer construction unit is used to load the physical layer protocol stack into the core 1 of the dual-core processor, and generate a CAN message receiving ring buffer containing a WiFi channel status table based on the loaded physical layer protocol stack.

[0096] The certificate verification and key generation unit is used to verify the security certificate chain of Core 2 of the dual-core processor, compile dynamic ID whitelist filtering rules based on the verified certificates, and generate device identity keys.

[0097] Optionally, the subject registration and mapping module includes:

[0098] The cloud authentication unit is used to initiate authentication to the cloud server based on the device identity key, and generate device-specific publishing topics and subscription topics after authentication.

[0099] The topic mapping table generating unit is used to parse the naming rules of the publishing topics and subscription topics of the paired devices, and generate a topic mapping relationship table between devices based on the matching naming rules.

[0100] The bus health assessment unit is used to connect the CAN controller error counter value to the event bus and generate a bus health assessment indicator based on the incremental change of the CAN controller error counter.

[0101] The dual-channel flag generation unit is used to perform a logical AND operation on the WiFi channel status table and the bus health assessment index to generate a dual-channel availability flag that controls the start and stop of the data pipeline.

[0102] Optionally, the data processing and transmission module includes:

[0103] The data frame generation unit is used to extract raw data from the CAN message receiving ring buffer, add a timestamp to the raw data based on the hardware clock signal, and generate a data frame with metadata.

[0104] The data encapsulation unit is used to encapsulate the data frame in JSON format according to the device ID in the inter-device subject mapping relationship table to generate an encryption-ready data block.

[0105] The encryption processing unit is used to call the encryption engine associated with the device identity key, perform AES-GCM encryption on the encryption-ready data block, generate a secure MQTT payload, and inject the secure MQTT payload into the cloud by publishing the topic.

[0106] The instruction set generation unit is used to receive MQTT messages from the cloud by subscribing to topics, and generate a physical CAN-ID instruction set based on the dynamic ID whitelist filtering rules and MQTT messages.

[0107] Optional data transmission and reporting modules include:

[0108] The cross-domain routing generation unit is used to parse the logical device ID in the secure MQTT payload, locate the subscription topic of the target device based on the inter-device topic mapping relationship table, and generate a cross-domain instruction routing path.

[0109] The network quality monitoring unit is used to inject the physical CAN-ID instruction set into the CAN send queue according to the cross-domain instruction routing path, synchronously collect the channel response delay and number of conflicts received through the subscription topic, and generate a network quality collaborative report.

[0110] The sending frequency adjustment unit is used to dynamically adjust the MQTT payload sending frequency of the publishing topic based on the transmission load status of the cross-domain instruction routing path and the conflict period heat map of the network quality collaborative report.

[0111] Optionally, the network management module includes:

[0112] The network disconnection resume transmission queue generation unit is used to generate a network disconnection resume transmission queue based on the instruction priority of the secure MQTT payload when the dual-channel availability flag is in an abnormal state.

[0113] The time window management unit is used to analyze the conflict period heat map of the network quality collaborative report and insert a virtual time window offset into the network disconnection and resumption queue based on the spatiotemporal distribution characteristics of the heat map.

[0114] The bus access right allocation unit is used to reconstruct the bus access right allocation strategy according to the virtual time window offset, inject the access right parameters in the adjusted bus access right allocation strategy into the dual-channel availability flag calculation model to complete dynamic allocation.

[0115] An embodiment of the present application further provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor implements the steps in the above-mentioned method embodiments when executing the computer program.

[0116] An embodiment of the present application further provides a computer-readable storage medium on which a computer program is stored. When the computer program is executed by a processor, the steps in the above-mentioned method embodiments are implemented.

[0117] For the device embodiments, since they basically correspond to the method embodiments, the relevant parts can be referred to the partial description of the method embodiments. The device embodiments described above are merely illustrative, wherein the components described as separate parts may or may not be physically separated, and the parts displayed as units may or may not be physical units, that is, they may be located in one place, or they may be distributed on multiple network units. Some or all of the modules can be selected according to actual needs to achieve the purpose of the disclosed solution. A person of ordinary skill in the art can understand and implement it without expending creative work.

[0118] The above-described embodiments merely represent several implementation methods of the embodiments of the present application. While the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the patent application. It should be noted that a person skilled in the art may make various modifications and improvements without departing from the concept of the embodiments of the present application, and these modifications and improvements fall within the scope of protection of the embodiments of the present application.

Claims

1. A CAN network cloud extension method in an Internet of Things environment, characterized in that: The method comprises: S1. Load the physical layer protocol stack and pre-set the security certificate on the dual-core processor to generate a CAN message receiving ring buffer and device identity key; S2. Register a publish-subscribe topic pair with the cloud based on the device identity key, and establish a topic mapping relationship table between devices and a dual-channel availability flag; S3. Extracting CAN messages from the CAN message receiving ring buffer to generate data frames with metadata, encapsulating the data frames into secure MQTT payloads according to the inter-device topic mapping relationship table, and uploading the secure MQTT payloads to the cloud through the publish topic in the publish-subscribe topic pair; simultaneously, receiving instructions from the cloud through the subscribe topic in the publish-subscribe topic pair to generate a physical CAN-ID instruction set; S4. Transparently transmitting the secure MQTT payload to the subscription topic of the target device according to the inter-device topic mapping relationship table, and generating a network quality collaboration report based on the physical CAN-ID instruction set; S5. Trigger a network-disconnected transmission resume strategy based on the dual-channel availability flag, and dynamically allocate bus access rights based on the conflict period heat map of the network quality collaborative report.

2. The method according to claim 1, characterized in that Said S1 comprises: Loading a physical layer protocol stack into core 1 of the dual-core processor, and generating the CAN message receiving ring buffer including a WiFi channel status table based on the loaded physical layer protocol stack; A security certificate chain is verified for the core 2 of the dual-core processor, and a dynamic ID whitelist filtering rule is compiled based on the verified certificate to generate the device identity key.

3. The method according to claim 2, characterized in that The S2 includes: Initiate authentication with the cloud server based on the device identity key, and generate device-specific publishing topics and subscription topics after authentication; Parsing the naming rules of the publishing topics and the subscribing topics of the paired devices, and generating the inter-device topic mapping relationship table based on the matching naming rules; Connecting the CAN controller error counter value to the event bus, and generating a bus health evaluation indicator based on the incremental change of the CAN controller error counter; A logical AND operation is performed on the WiFi channel status table and the bus health evaluation index to generate the dual-channel availability flag for controlling the start and stop of the data pipeline.

4. The method according to claim 3, characterized in that The S3 includes: Extracting raw data from the CAN message receiving ring buffer, adding a timestamp to the raw data based on a hardware clock signal, and generating the data frame with metadata; According to the device ID in the inter-device subject mapping relationship table, the data frame is encapsulated in JSON format to generate an encryption-ready data block; Invoking the encryption engine associated with the device identity key, performing AES-GCM encryption on the encryption-ready data block to generate the secure MQTT payload; and injecting the secure MQTT payload into the cloud through the publishing topic; The MQTT message transmitted downlink from the cloud is received through the subscription topic, and the physical CAN-ID instruction set is generated based on the dynamic ID whitelist filtering rule and the MQTT message.

5. The method according to claim 4, characterized in that The S4 includes: Parsing the logical device ID in the secure MQTT payload, locating the subscription topic of the target device based on the inter-device topic mapping relationship table, and generating a cross-domain instruction routing path; Injecting the physical CAN-ID instruction set into a CAN transmit queue according to the cross-domain instruction routing path, synchronously collecting the channel response delay and the number of conflicts received through the subscription topic, and generating the network quality collaborative report; Based on the transmission load status of the cross-domain instruction routing path and combined with the conflict period heat map of the network quality collaborative report, the MQTT payload sending frequency of the publishing topic is dynamically adjusted.

6. The method according to any one of claims 1 to 5, characterized in that The S5 includes: When the dual-channel availability flag is in an abnormal state, a disconnected transmission queue is generated based on the instruction priority of the secure MQTT payload; parsing a heat map of conflicting periods in the network quality collaborative report, and inserting a virtual time window offset into the network-disconnected transmission resume queue based on the spatiotemporal distribution characteristics of the heat map; The bus access right allocation strategy is reconstructed according to the virtual time window offset, and the access right parameters in the adjusted bus access right allocation strategy are injected into the dual-channel availability flag calculation model to complete dynamic allocation.

7. A CAN network cloud extension system in an Internet of Things environment, characterized by: The system comprises: The protocol and security configuration module is used to load the physical layer protocol stack and pre-set the security certificate for the dual-core processor, and generate the CAN message receiving ring buffer and device identity key; A topic registration and mapping module is used to register publish-subscribe topic pairs with the cloud based on the device identity key, establish a topic mapping relationship table between devices and a dual-channel availability flag; a data processing and transmission module, configured to extract CAN messages from the CAN message receiving ring buffer to generate data frames with metadata, encapsulate the data frames into secure MQTT payloads according to the inter-device topic mapping relationship table, and upload the secure MQTT payloads to the cloud via the publish topic in the publish-subscribe topic pair; and simultaneously receive instructions from the cloud via the subscribe topic in the publish-subscribe topic pair to generate a physical CAN-ID instruction set; A data transparent transmission and reporting module, configured to transparently transmit the secure MQTT payload to the subscription topic of the target device according to the inter-device topic mapping relationship table, and generate a network quality collaborative report based on the physical CAN-ID instruction set; The network management module is used to trigger the network disconnection and resumption strategy according to the dual-channel availability flag, and dynamically allocate bus access rights in combination with the conflict period heat map of the network quality collaborative report.

8. A computer device comprising a memory and a processor, wherein the memory stores a computer program, wherein: When the processor executes the computer program, the method according to any one of claims 1 to 6 is implemented.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the method according to any one of claims 1 to 6 is implemented.

Images