Internet-of-things multi-protocol fusion limo intelligent control system

Abstract

The invention discloses an internet of things multi-protocol fusion limo intelligent control system, which relates to the field of limo intelligent control and comprises a hardware irrelevant layer, a multi-protocol adaptation layer, a data abstraction layer, a programmable logic layer, a security and redundancy mechanism and an edge AI module. According to the invention, a physical bus is packaged into an independent module, an MCU / SoC and a protocol transceiver are built in, hot plugging is realized through a standardized PC I e / EdgeConn backboard, a core processing board only exposes a unified backboard interface, module drive localization execution is realized, master control firmware does not need to sense protocol details, only the module needs to be replaced when a protocol is newly added, and the master control firmware or upper software does not need to be modified. The defect that the whole vehicle firmware needs to be refreshed when a bus is replaced in a traditional system is overcome, each protocol corresponds to an independent drive micro-service deployed in a containerization mode, the drive micro-service analyzes a message into a unified data model and uploads the unified data model to a data abstraction layer, a downlink control instruction is packaged and issued according to a target protocol, and it is guaranteed that the protocols are diversified and interfaces are consistent.

Description

Technical Field

[0001] This invention relates to the field of intelligent control of RVs, and more particularly to an intelligent control system for RVs that integrates multiple Internet of Things protocols. Background Technology

[0002] The field of intelligent RV control is a comprehensive management platform designed for camping RVs. It aims to achieve unified monitoring and automated management of in-vehicle equipment, energy, safety and other functions through Internet of Things (IoT) technology, treating the RV as a "mobile smart home". By integrating communication, data analysis and decision-making modules, it provides users with a convenient, safe and efficient travel experience.

[0003] A published patent, "Control System and Control Method for a Camping Vehicle," (Publication No.: CN112019580B), describes a control system that connects at least one control local area network bus formed by multiple body units within a camping vehicle. The system includes: a sensor control center module, a central processing module, a server, at least one electronic control device, and a smart screen. The control method includes: an online step, an operation selection step, a transmission step, a processing step, and a control step. This invention, through the coordinated operation of the aforementioned modules, server, and devices, and in conjunction with the aforementioned steps, achieves diverse choices in operating modes, thereby improving the accuracy of control, diagnosis, and warning. It also features a unified control platform, high automation, and the ability to achieve remote control and automatic alarms.

[0004] The aforementioned patent has the following defects: The system adopts a master-slave dual-processor structure, but the slave module still relies on the master module to forward wireless and vehicle communication. Once the master module fails, the whole system may still be paralyzed, resulting in limited redundancy. The bus type is too simple and it is difficult to support high-speed new buses such as vehicle Ethernet or FlexRay. In scenarios without public networks, such as deep mountains, only mobile phones are allowed to connect directly via Wi-Fi, resulting in limited communication distance. Wide-area loops such as NB-IoT, satellite links, or LoRa are not considered, resulting in insufficient remote monitoring capabilities. The system is still positioned as "unified control + remote alarm". It lacks open APIs, OTA upgrades, and mechanisms for connecting with the cloud and smart home ecosystems. It also does not introduce voice or scene adaptive functions, resulting in insufficient intelligence and ecosystem openness. Summary of the Invention

[0005] The purpose of this invention is to address the shortcomings of existing technologies by proposing an IoT multi-protocol fusion intelligent control system for RVs.

[0006] To achieve the above objectives, the present invention adopts the following technical solution: an IoT multi-protocol fusion intelligent control system for RVs, comprising a hardware-independent layer, a multi-protocol adaptation layer, a data abstraction layer, a programmable logic layer, a security and redundancy mechanism, and an edge AI module; the hardware-independent layer is equipped with a pluggable gateway module, which integrates an MCU / SoC and a protocol transceiver, and is connected to the main control board via a PCIe / EdgeConn backplane; the multi-protocol adaptation layer adopts a driver microservice framework to convert data from different communication protocols into a unified data model, with new protocols dynamically loaded as containers or plug-ins; the data abstraction layer maps device variables to status variables, alarm variables, measurement variables, and configuration variables. It includes control variables and publishes / subscribes according to the MQTT / gRPCTopic specification; the programmable logic layer has a built-in graphical process orchestrator and script engine, supports logic blocks and AI inference blocks, and provides RESTful, gRPC, WebSocket, Matter, and HomeKit APIs; the security and redundancy mechanisms include dual redundant controllers, full-link TLS1.3 / DTLS1.3 encryption, hardware security modules, trusted boot, OTA and intrusion detection, and a fault isolation zone; the edge AI module stores historical data through a local time-series database, predicts energy consumption and the health of key components, and supports offline caching and post-launch synchronization.

[0007] As a further description of the above technical solution:

[0008] The pluggable gateway module with a hardware-independent layer supports hot-swapping. The standardized PHY interface backplane fixes the power supply, differential channels, and detection pins, and integrates plug-in / plug-out detection, power-on timing control, and surge suppression circuitry.

[0009] As a further description of the above technical solution:

[0010] The multi-protocol adaptation layer supports protocols including CAN, LIN, RS485, RS232, automotive Ethernet, Wi-Fi, BLE, ZigBee, Z-Wave, LoRa, NB-IoT, LTE-Cat-M, 5G, NFC, and satellite links. In the microservice-based driver framework, each protocol corresponds to a driver microservice. The driver microservice parses the underlying messages into a unified data model and sends it to the data abstraction layer through the message bus.

[0011] As a further description of the above technical solution:

[0012] The state variables in the data abstraction layer are of type BOOL / ENUM to represent switch or enumerated states. Alarm variables have levels and timestamps. Measurement variables are numerical and have units and ranges. Configuration variables are readable and writable parameters. Control variables are trigger-type commands. The data abstraction layer establishes MQTT / gRPCTopics according to a fixed hierarchy.

[0013] As a further description of the above technical solution:

[0014] The programmable logic layer provides multiple interfaces to expose all defined rules, scripts, and real-time variables, supporting scenarios such as cloud orchestration, smart home linkage, and mobile phone notifications. The programmable logic layer performs real-time statistics on CPU usage, execution time, and number of errors for each rule block, script block, and AI inference block. When the indicators exceed the limits, the corresponding block is automatically paused and logs are recorded for diagnostic purposes.

[0015] As a further description of the above technical solution:

[0016] The dual-redundant controller has independent communication modules and certificates for both the primary and backup MCUs, and the other can take over directly in the event of a failure in either case; it uses TLS1.3 / DTLS1.3 for full-link encryption, and the key is stored in the hardware security module; the fault isolation zone can automatically take the faulty gateway offline and switch to the backup channel.

[0017] As a further description of the above technical solution:

[0018] The local AI model of the edge AI module runs pre-deployed LSTM, regression or classification models to predict energy consumption curves and health indicators of key components. It continues to subscribe to the alarm quantities and predicted measurements it writes, calculates errors by combining subsequent real sample values, and automatically updates model evaluation indicators. New models and parameter packages are securely delivered via OTA, and hot-swapped after signature verification. It performs offline inference in environments without public network access, and synchronizes historical data and prediction results to the cloud after network recovery.

[0019] The present invention has the following beneficial effects:

[0020] 1. In this invention, the physical bus is first encapsulated as an independent module, with a built-in MCU / SoC and protocol transceiver. Hot-swappable functionality is achieved through a standardized PCIe / EdgeConn backplane. The core processing board only exposes a unified backplane interface. The module driver is executed locally, and the main control firmware does not need to be aware of protocol details. When adding a new protocol, only the module needs to be replaced, without modifying the main control firmware or upper-layer software. This solves the problem of traditional systems requiring a complete vehicle firmware update when changing the bus. Each protocol corresponds to an independent driver microservice deployed in a containerized manner, supporting hot loading of new protocol containers / plugins at runtime, enabling dynamic expansion without downtime. The driver microservice parses messages into a unified data model and sends it to the data abstraction layer. Downlink control commands are encapsulated and sent according to the target protocol, ensuring that the interfaces are consistent despite the diversity of protocols.

[0021] 2. In this invention, device variables are categorized into status variables, alarm variables, measurement variables, configuration variables, and control variables, eliminating cross-protocol semantic differences. Topics are created to drive microservices to directly publish / subscribe, shielding underlying protocol details and ensuring that upper-layer applications do not need modification when retrofitted devices are connected. Business logic is assembled by dragging and dropping IFTTT rule blocks, state machine blocks, and timing blocks, with inputs and outputs bound to Topic variables to achieve cross-protocol device linkage. Complex scripts are written in a Lua / PythonWASM sandbox, calling ONNXRuntime inference blocks to execute pre-trained models. The results are published to Topics as control / configuration variables, achieving a hybrid "rule + AI" decision-making approach. Scripts and rules support second-level hot updates, and the sandbox limits file system / network / CPU resources, ensuring that a single logic failure does not affect the main control OS.

[0022] 3. In this invention, a local time series database continuously caches sensor data, runs an LSTM / regression model to predict energy consumption and component health, and publishes the results to the measurement / alarm topic to form a closed loop. The model is executed locally in a weak network environment, and after the network is restored, historical data and prediction results are synchronized to the cloud to ensure continuity. Dual redundant controllers are set up, with the primary and backup controllers operating independently and taking over within 100 milliseconds in case of failure. The entire link uses TLS1.3 / DTLS1.3 encryption, and the key is stored in the hardware security module. Trust verification is performed during the startup phase, and the fault isolation zone automatically isolates abnormal gateway modules and switches the backup channel. Combined with intrusion detection, it resists hardware failure and network attacks. Attached Figure Description

[0023] Figure 1 This is a system architecture diagram of the present invention;

[0024] Figure 2 This is a flowchart illustrating the operation of the present invention. Detailed Implementation

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

[0026] Reference Figure 1-2This invention provides an embodiment of an IoT multi-protocol fusion intelligent control system for RVs, comprising a hardware-independent layer, a multi-protocol adaptation layer, a data abstraction layer, a programmable logic layer, a security and redundancy mechanism, and an edge AI module. The hardware-independent layer includes a pluggable gateway module, which integrates an MCU / SoC and a protocol transceiver, and connects to the main control board via a PCIe / EdgeConn backplane. The multi-protocol adaptation layer employs a driver-based microservice framework to convert data from different communication protocols into a unified data model, with new protocols dynamically loaded as containers or plugins. The data abstraction layer maps device variables to status variables, alarm variables, measurement variables, configuration variables, and control variables. It publishes and subscribes according to the MQTT / gRPCTopic specification; the programmable logic layer has a built-in graphical process orchestrator and script engine, supports logic blocks and AI inference blocks, and provides RESTful, gRPC, WebSocket, Matter, and HomeKit APIs; the security and redundancy mechanisms include dual redundant controllers, full-link TLS1.3 / DTLS1.3 encryption, hardware security modules, trusted boot, OTA and intrusion detection, and a fault isolation zone is set up; the edge AI module stores historical data through a local time series database, predicts energy consumption and the health of key components, and supports offline caching and post-launch synchronization.

[0027] Example 1:

[0028] The pluggable gateway module in the hardware-independent layer supports hot-swapping. A standardized PHY interface backplane secures the power supply, differential channels, and detection pins, integrating pluggable detection, power-on timing control, and surge suppression circuitry. The multi-protocol adaptation layer supports protocols including CAN, LIN, RS485, RS232, automotive Ethernet, Wi-Fi, BLE, ZigBee, Z-Wave, LoRa, NB-IoT, LTE-Cat-M, 5G, NFC, and satellite links. In the microservice-based driver framework, each protocol corresponds to a driver microservice. These driver microservices parse the underlying messages into a unified data model and send it to the data abstraction layer via a message bus. The data abstraction layer uses BOOL / ENUM types to represent switch or enumerated states. Alarm quantities have levels and timestamps, measurement quantities are numerical with units and ranges, configuration quantities are readable and writable parameters, and control quantities are trigger commands. The data abstraction layer establishes MQTT / gRPC Topics according to a fixed hierarchy. The programmable logic layer provides multiple interfaces to expose all defined rules. The system supports cloud orchestration, smart home integration, and mobile notification scenarios. The programmable logic layer provides real-time statistics on CPU usage, execution time, and error count for each rule block, script block, and AI inference block. When the metrics exceed limits, the corresponding block is automatically paused and logged for diagnostic purposes. The dual-redundant controller's primary and backup MCUs each have independent communication modules and certificates, and the other takes over directly in the event of a failure in either case. TLS1.3 / DTLS1.3 is used for end-to-end encryption, and the key is stored in the hardware security module. The fault isolation zone can automatically take down the faulty gateway and switch to the backup channel. The edge AI module's local AI model runs pre-deployed LSTM, regression, or classification models to predict energy consumption curves and key component health indicators. It continues to subscribe to its own alarm quantities and predicted measurements, calculates errors based on subsequent real sample values, and automatically updates model evaluation metrics. New models and parameter packages are securely delivered via OTA, and hot-swapped after signature verification. Offline inference is possible in environments without public networks, and historical data and prediction results are synchronized to the cloud after network recovery.

[0029] Example 1:

[0030] The hardware-independent layer features a pluggable gateway module architecture. Firstly, the physical buses CAN, LIN, RS485, RS232, automotive Ethernet, Wi-Fi, BLE, ZigBee, Z-Wave, LoRa, NB-IoT, LTE-Cat-M, 5G, NFC, and satellite links are uniformly encapsulated into independent gateway modules. Each module integrates an MCU / SoC and a transceiver for the corresponding protocol, responsible for local signal conditioning and physical layer driving. A high-speed backplane specification is defined based on PCIe / EdgeConn, with fixed power supply and differential... The system uses a standardized PHY interface backplane with separate channels and detection pins. The main control board only needs to expose this unified backplane; any module from a manufacturer conforming to the specifications can be recognized and powered on by the system, achieving plug-and-play functionality across manufacturers. To meet the needs of adding or removing modules while the RV is in motion, a hardware-independent layer integrates insertion / removal detection, power-on timing control, and surge suppression circuitry on the backplane side. When a module is detected being inserted or removed, power supply and link restoration can be completed without interfering with the main control board's operation, ensuring safe and reliable hot-swapping from a hardware perspective. To completely shield hardware differences, the backplane provides each... Each slot provides sufficient high-speed differential channels, RF shielding, and EMI constraints, increasing the physical carrying capacity for multiple protocols. This allows the system to simultaneously support all the aforementioned wired or wireless PHYs without requiring hardware modifications to the main control board, achieving true protocol independence. All low-level driver code and protocol transceiver timings are stored in the module's local flash memory and executed by the module's MCU. The core processing board treats the module only as an Ethernet node and does not need to compile kernel drivers for different physical buses. This avoids the predicament of traditional automotive systems where changing a bus requires flashing the entire vehicle's firmware. The main control firmware does not need to be sensitive to external signals. Knowing the protocol details, when a single module ages or is damaged, maintenance personnel can directly replace the module without disassembling and inspecting the main control board, thereby reducing wiring complexity, shortening maintenance time, and leaving room for aftermarket upgrades. All drives are completed on the module side, so any manufacturer can add or replace communication interfaces for RVs by making a new module that conforms to the backplane specifications. This means that accessing the new physical bus only involves adding or replacing the gateway module, without modifying the main control firmware or upper-level software, thus completely decoupling the hardware and software. This lays the foundation for subsequent function expansion, protocol evolution, and even vehicle platformization.

[0031] The multi-protocol adaptation layer natively supports CAN, LIN, RS485, RS232, 100 / 1000BASE-T1, Wi-Fi, BLE, ZigBee, Z-Wave, Thread, LoRa, NB-IoT, LTE-Cat-M, 5G, NFC, and satellite link protocols. Within the main control Linux environment, an independent driver microservice is instantiated for each communication protocol. Each microservice is responsible for frame transmission and reception, handshake maintenance, error detection, and retransmission control for its respective protocol, and runs in parallel with other microservices in the same layer without interference. The plug-in design allows for dynamic runtime expansion when a new protocol emerges or an existing protocol needs upgrading. Simply download the corresponding driver container or plugin package to the system and hot-load it for immediate use, eliminating the need for system downtime, recompilation, or firmware updates. Containers maintain consistency through image version numbers and signature metadata, ensuring secure and rollback-friendly driver updates. The driver microservice parses the underlying physical packets into a unified data model object defined by the system, then sends it to the data abstraction layer via an internal message bus, achieving protocol diversity while maintaining a consistent interface. Downstream, when the upper layer generates control commands, the multi-protocol adaptation layer is responsible for... The target protocol format is re-encapsulated into frames and sent to the corresponding gateway module, achieving bidirectional transparent conversion without changing the business semantics. When the hardware-independent layer detects a new gateway module coming online, the multi-protocol adaptation layer automatically enumerates its MAC and BusID, matches the corresponding driver microservice, and establishes a session. If a module is hot-swapped, the relevant microservice is immediately notified to release the channel. The entire process is completed by the multi-protocol adaptation layer, without requiring the data abstraction layer and programmable logic layer to participate, thus ensuring decoupling between layers. When a device first connects, its E-DeviceProfile enters the multi-protocol adaptation layer along with the uplink packet, and the driver... The microservice parses the variable-protocol mapping relationship in the Profile, encapsulates the result into a unified data model object, and sends it up. The multi-protocol adaptation layer exposes a health check terminal and standardized log stream for each driver microservice. The upper-layer monitoring service can subscribe to these state variables to provide early warning of communication anomalies without having to delve into the protocol details. All drivers run in a container sandbox, and the network namespace, file system, and process space are isolated from the system root environment. The failure or crash of a single driver will not affect other protocol NOR host OS. At the same time, an interface is reserved for future implementation of fault isolation in "FI-Zone".

[0032] The data abstraction layer is responsible for mapping all raw message parsing results uploaded by the multi-protocol adaptation layer into five basic data types: status variables, alarm variables, measurement variables, configuration variables, and control variables. Status variables represent the on / off or enumerated state of the device; alarm variables include alarm level and timestamp; measurement variables are numerical data with units and ranges; configuration variables are readable and writable device parameters; and control variables are trigger commands. Each variable in the unified data model carries metadata such as name, data type, unit / range or alarm level, timestamp, and permissions, forming a consistent semantic space across manufacturers and protocols. When a terminal device accesses through a gateway and uploads an E-DeviceProfile along with a message, the data abstraction layer maps the data according to the unified data model object. Variable entries are automatically created and then archived according to the five types mentioned above. For each registered variable, the data abstraction layer creates a standardized Topic identifier for each device variable, in the format: / rv / {device_id} / {datatype} / {name}, where {device_id} is the unique identifier of the device, {datatype} is one of the five basic data types, and {name} is the specific name of the variable. This identifier is written to the Topic-variable mapping table. All variables are published or subscribed to on the corresponding Topic via the MQTT / gRPC protocol. This process ensures that when new devices or new protocols are launched, new variables can be recognized and used without modifying the upper-layer application. This ensures that subsequent device data updates are handled efficiently. In the new era, driving microservices only need to publish or subscribe to the corresponding Topic to complete uplink and downlink data exchange, thus completely shielding the protocol details from the adaptation layer. There's no need to repeatedly resolve mapping relationships. Upper-layer applications only need to subscribe to the target Topic to access device variables across protocols and vendors, without needing to concern themselves with the underlying communication details. The data abstraction layer acts as the system's internal message bus. Uplink, it receives variable values ​​pushed by the adaptation layer, converts them into unified data model objects, and publishes them to the corresponding Topic. Downlink, it receives control / configuration values ​​written to the Topic by the programmable logic layer or external applications, verifies the type, and then sends them back to the multi-protocol adaptation layer, which encapsulates them into target protocol frames for distribution. This design ensures consistency in business semantics while leaving all protocol conversion to the multi-protocol adaptation layer. Internally, the adaptation layer performs range checks on measured quantities and read / write permission verification on configuration quantities before deployment. It also uniformly appends timestamps and levels to alarm quantities. If out-of-bounds or semantic conflicts are detected, an alarm is immediately published on the erroneous topic within this layer for monitoring subscription, preventing illegal data from entering business logic. All topic streams are output to the programmable logic layer in real time for direct subscription by IFTTT rules, state machines, or script engines. Measurement and state quantity streams are continuously provided to the edge AI unit. The AI ​​model's prediction results are then written back to the measurement or alarm quantity topics, achieving a closed loop. Measurement quantity topics are copied to the time-series database for historical playback and energy / health analysis. Throughout this process, the data abstraction layer is only responsible for standardizing the data stream.Computation and storage are handled by the logic layer, AI module, and TSDB respectively, avoiding functional overlap. Since all variable metadata and topics are automatically generated at runtime, adding new protocols, replacing gateway modules, or upgrading scripts does not affect established data channels. Old variable entries can be marked as deprecated and retained as read-only entries through version comparison, ensuring that legacy applications continue to function normally.

[0033] The programmable logic layer persistently subscribes to a unified Topic identifier generated by the data abstraction layer, acquiring real-time updates to device variables. Once a change in status, measurement, or alarm values ​​is detected, the corresponding event is pushed to the internal rule engine, providing a real-time trigger source for subsequent logic blocks. The system features a built-in visual drag-and-drop interface, allowing for the rapid connection of IFTTT rule blocks, state machine blocks, and timing blocks to complete conditional judgments, scheduled tasks, and sequential control business processes. Each block's inputs and outputs are bound to the aforementioned topic, enabling cross-protocol and cross-vendor device linkage without writing underlying code. For complex strategies not covered by the graphical interface, developers can utilize Lua / PythonWASM. Scripts can be written within a sandbox to implement complex strategies. The sandbox isolates and limits file system, network, and CPU resources, ensuring that script crashes or malicious code will not affect the security of the main control system. Scripts can directly read Topic variables, call a unified API to read variables or publish control variables, achieving second-level hot updates without restarting. They can call the ONNXRuntime inference block to execute AI models, dragging pre-trained AI model files into the inference block and selecting input topics and output target variables in the parameter panel. Model calculation results can be published to the abstraction layer as new control or configuration variables. Script logic cannot modify Topic structure or data type definitions, enabling a hybrid "rule + AI" decision-making approach. Whether it's a graphical stream, script, or AI inference, as long as the triggering condition is met, two types of instructions—control or configuration—are published to the target Topic and posted to the corresponding topic. After the instructions are verified by the data abstraction layer, they are encapsulated and issued by the multi-protocol adaptation layer. The programmable logic layer does not participate in protocol encapsulation, maintaining consistency in business semantics while completely shielding protocol details. To facilitate access from third-party systems or mobile devices, the programmable logic layer exposes all defined rules, scripts, and real-time variables through RESTful, gRPC, WebSocket, Matter, and HomeKit interfaces, supporting scenarios such as cloud orchestration, smart home linkage, and mobile notifications. Each process or script carries... Version number and signature metadata: When a new version is released, the programmable logic layer first runs it in a sandbox in a gray-scale test. After confirming that there are no anomalies, the old rules are replaced and a rollback point is retained to ensure the safe continuity of logic upgrades during RV operation. After a rule is triggered, in addition to issuing control variables, the programmable logic layer can also call the built-in Webhook / push service to synchronize alarms or status changes to the user's mobile phone or cloud monitoring panel, realizing the unification of local control and remote operation and maintenance. The programmable logic layer performs real-time statistics on CPU usage, execution time and error count for each rule block, script block and AI inference block. When the indicators exceed the limits, the corresponding block is automatically paused and logs are recorded for diagnosis, while ensuring that other blocks and the core system processes continue to run normally.

[0034] The edge AI module continuously subscribes to all "measurement quantities" and "state quantities" topic streams through the unified Topic specification provided by the data abstraction layer, ensuring that it obtains raw time-series data of sensor readings and operating status as soon as possible for inference and training input. All sensor data is continuously cached through a local time-series database. The module has a built-in TSDB to locally persist the subscribed time-series data, forming a complete historical dataset for model training, feature engineering, and result backtesting. In scenarios without public network access, data continues to be written to the local cache and synchronized with the cloud once the network is restored, ensuring data continuity. The local AI model runs pre-deployed LSTM, regression, or classification models to predict energy consumption curves and key component health indicators. The inference process is completely offline and does not rely on cloud computing power, ensuring that the RV can still obtain intelligent analysis results in weak network environments. New models or parameter packages can be securely delivered via OTA, with verification signatures... The module performs hot-swap after name registration, without affecting other modules. When the model detects that the RMSE exceeds the threshold or the remaining lifespan is less than 30 days, it writes the corresponding alarm quantity or publishes energy consumption prediction values ​​or optimization suggestions in the corresponding topic for use by the upper-layer logic and user interface. This integrates AI results into a unified data model while maintaining loose coupling with the business logic layer. The module continues to subscribe to the alarm quantity and predicted measurement quantity it writes, calculates the error based on subsequent real sample values, and automatically updates the model evaluation indicators. If necessary, it triggers incremental training or requests the cloud model to be deployed, realizing continuous iteration on the vehicle without interfering with the rule execution of the programmable logic layer. When the public network is detected to be unavailable, the module enters offline mode: inference and TSDB writing continue as usual, and all prediction results and key logs are marked for synchronization. After the network is restored, cached data and model evaluation reports are uploaded to the cloud analysis platform in batches to maintain consistency between local and cloud data.

[0035] The safety and redundancy mechanism features a dual-redundant controller hot standby architecture, equipped with two independent MCU controllers, a primary and a backup. Each controller has its own communication module and digital certificate. When either controller detects a disconnection or hardware failure in the other, it can automatically take over all bus and business logic within 100ms, ensuring uninterrupted vehicle control. The entire link is encrypted, with keys managed by hardware. All local-remote channels uniformly execute TLS1.3 / DTLS1.3 sessions. Private keys and certificates are stored in an onboard hardware security module, preventing any process from directly reading plaintext keys. Session updates are automatically rotated according to certificate validity periods to prevent man-in-the-middle attacks and key leakage. Upon power-up, the BootROM first verifies the bootloader signature, and the bootloader then verifies the kernel and root file system signatures. Failure at any stage results in a forced shutdown and alarm reporting. Loading unknown or tampered code is prohibited, ensuring the system is trustworthy from the first instruction. After receiving new firmware metadata, the primary controller first compares the version and verifies the signature, downloading only the differential package to the backup "B" partition. After completion, it switches to the boot partition. During the observation period, key indicators are monitored by watchdog and IDS. If an anomaly is detected, the system automatically rolls back to partition "A" and issues an alarm. This process ensures that the upgrade process saves bandwidth and can be instantly restored in case of failure. The built-in IDS service continuously analyzes bus traffic and network packets. When an abnormal handshake, data flooding, or driver crash threat is detected, the corresponding gateway module or microservice is placed in FI-Zone, cutting off its connection with the business plane. At the same time, the multi-protocol adaptation layer is instructed to enable the backup channel to block malicious propagation and maintain system continuity. The primary and backup controllers send hardware heartbeats to each other. Each gateway module, driver microservice, and critical system process reports CPU usage, error count, and temperature to the security mechanism via software heartbeats. When the threshold is exceeded or the heartbeat is lost, the security mechanism triggers fault switching, isolation, or degraded operation according to the contingency plan. All events of the controller, HSM, IDS, and OTA process are written to an encrypted circular buffer and periodically synchronized to a read-only partition. When the network is available, they are asynchronously reported to the cloud for auditing. In this way, even if the attacker attempts to clear the logs, the evidence collection link can be preserved.

[0036] Example 3:

[0037] The RV originally only had CAN and Wi-Fi gateways installed. When users need to provide access capabilities for newly added ZigBee lighting and Thread sensors while traveling, they simply insert the corresponding pluggable gateway module into a unified PCIe / EdgeConn backplane slot. The hardware-independent layer enables hot-swapping through plug-in / plug-out detection, power-on timing control, and surge suppression circuitry, ensuring stable operation of the main control board. After the multi-protocol adaptation layer detects the new module's online status, it automatically matches and hot-loads the ZigBee and Thread driver microservices. The driver microservices parse the underlying messages into a unified data model object, which is then sent to the data abstraction layer via the message bus. The data abstraction layer generates a Topic " / rv / {device_id} / {datatype} / {name}" for the new device variables in real time, performs range checks on measured quantities, and adds timestamps and levels to alarm quantities, achieving seamless integration with existing CAN and Wi-Fi devices. The dual-redundant controller ensures that it can take over the service within 100ms in the event of any module failure through hardware heartbeat. The bus encryption continues to use TLS1.3 / DTLS1.3, and the key is stored in the hardware security module to ensure communication continuity and security.

[0038] Example 4:

[0039] The edge AI module continuously subscribes to battery SOC, current, voltage, and compressor power under the measurement topic and writes the data to a local time-series database. Even in environments without public network access, it continues offline inference, using a pre-deployed LSTM model to predict the energy consumption curve and remaining compressor lifespan for the next 24 hours. When the prediction shows a remaining lifespan of less than 30 days, the edge AI module publishes a maintenance reminder in the alarm topic. If the energy consumption prediction exceeds a threshold, it writes air conditioner operating parameter suggestions in the configuration topic for reference by programmable logic layer rules. When the model evaluation error exceeds a threshold, the system securely distributes a new model package via OTA, performs hot-swap after signature verification, and does not affect other processes. After the prediction results are synchronized to the cloud, users can view the energy consumption report on their mobile phones, achieving closed-loop management of "measured quantities → predicted measured quantities → alarm quantities".

[0040] Example 5:

[0041] The programmable logic layer exposes RESTful, gRPC, WebSocket, Matter, and HomeKit interfaces, connecting the RV's internal status with the home's central platform. Users can drag and drop IFTTT rule blocks, state machine blocks, and timing blocks in a visual interface to set a control variable to unlock the smart door and start the interior ventilation fan when the RV enters the home's Wi-Fi coverage area and the state variable 'Parking Mode' is TRUE. For more complex scenarios, developers can write scripts in Lua or Python WASM sandboxes to call a unified API to read Topic variables and publish configuration variables, achieving second-level hot updates without affecting system security isolation. When dynamic adjustment of lighting brightness based on weather conditions is needed, the script can call the ONNXRuntime inference block to load a pre-trained classification model, output the target brightness, and write it back to the control variable topic; the multi-protocol adaptation layer then encapsulates the instructions into Z-Wave frames and sends them to the lighting gateway, achieving cross-protocol automation. Throughout the process, the programmable logic layer monitors the CPU usage, execution time, and number of errors for each rule block, script block, and AI inference block in real time. When the indicators exceed the limits, the corresponding block is automatically paused and logs are recorded for diagnostic purposes, ensuring the reliability of the integrated operation of the RV and home system.

[0042] Finally, it should be noted that the above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art can still modify the technical solutions described in the foregoing embodiments or make equivalent substitutions for some of the technical features. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A multi-protocol IoT-integrated intelligent control system for RVs, characterized by: It includes a hardware-independent layer, a multi-protocol adaptation layer, a data abstraction layer, a programmable logic layer, security and redundancy mechanisms, and an edge AI module; the hardware-independent layer is equipped with a pluggable gateway module, which has a built-in MCU / SoC and protocol transceiver, and is connected to the main control board through a PCIe / EdgeConn backplane; The multi-protocol adaptation layer adopts a driver-based microservice framework to convert data from different communication protocols into a unified data model, and new protocols are dynamically loaded in the form of containers or plugins. The data abstraction layer maps device variables to status variables, alarm variables, measurement variables, configuration variables, and control variables, and publishes and subscribes according to the MQTT / gRPCTopic specification; the programmable logic layer has a built-in graphical process orchestrator and script engine, supports logic blocks and AI inference blocks, and provides RESTful, gRPC, WebSocket, Matter, and HomeKit APIs; the security and redundancy mechanisms include dual redundant controllers, full-link TLS1.3 / DTLS1.3 encryption, hardware security modules, trusted boot, OTA, and intrusion detection, and a fault isolation zone is set up; the edge AI module stores historical data through a local time-series database, predicts energy consumption and the health of key components, and supports offline caching and post-launch synchronization.

2. The IoT multi-protocol fusion intelligent control system for RVs according to claim 1, characterized in that: The pluggable gateway module with a hardware-independent layer supports hot-swapping. The standardized PHY interface backplane fixes the power supply, differential channels, and detection pins, and integrates plug-in / plug-out detection, power-on timing control, and surge suppression circuitry.

3. The IoT multi-protocol fusion intelligent control system for RVs according to claim 1, characterized in that: The multi-protocol adaptation layer supports protocols including CAN, LIN, RS485, RS232, automotive Ethernet, Wi-Fi, BLE, ZigBee, Z-Wave, LoRa, NB-IoT, LTE-Cat-M, 5G, NFC, and satellite links. In the microservice-based driver framework, each protocol corresponds to a driver microservice. The driver microservice parses the underlying messages into a unified data model and sends it to the data abstraction layer through the message bus.

4. The IoT multi-protocol fusion intelligent control system for RVs according to claim 1, characterized in that: The state variables in the data abstraction layer are of type BOOL / ENUM to represent switch or enumerated states. Alarm variables have levels and timestamps. Measurement variables are numerical and have units and ranges. Configuration variables are readable and writable parameters. Control variables are trigger-type commands. The data abstraction layer establishes MQTT / gRPCTopics according to a fixed hierarchy.

5. The IoT multi-protocol fusion intelligent control system for RVs according to claim 1, characterized in that: The programmable logic layer provides multiple interfaces to expose all defined rules, scripts, and real-time variables, supporting scenarios such as cloud orchestration, smart home linkage, and mobile phone notifications. The programmable logic layer performs real-time statistics on CPU usage, execution time, and number of errors for each rule block, script block, and AI inference block. When the indicators exceed the limits, the corresponding block is automatically paused and logs are recorded for diagnostic purposes.

6. The IoT multi-protocol fusion intelligent control system for RVs according to claim 1, characterized in that: The dual-redundant controller has independent communication modules and certificates for both the primary and backup MCUs, and the other can take over directly in the event of a failure in either one; it uses TLS1.3 / DTLS1.3 for end-to-end encryption, and the key is stored in the hardware security module; The fault isolation zone can automatically take the faulty gateway offline and switch it to the backup channel.

7. The IoT multi-protocol fusion intelligent control system for RVs according to claim 1, characterized in that: The local AI model of the edge AI module runs pre-deployed LSTM, regression or classification models to predict energy consumption curves and health indicators of key components. It continues to subscribe to the alarm quantities and predicted measurements it writes, calculates errors by combining subsequent real sample values, and automatically updates model evaluation indicators. New models and parameter packages are securely delivered via OTA, and hot-swapped after signature verification. It performs offline inference in environments without public network access, and synchronizes historical data and prediction results to the cloud after network recovery.

Images