Data trend prediction system based on AI analysis

Abstract

The invention specifically relates to a data trend prediction system based on AI analysis, and relates to the technical field of data processing and Internet of Things. A service state machine and logic hard coding execution module; a business state vector difference extraction module; a local degradation and autonomous control module; and a cloud vector clock synchronization and conflict resolution module. According to the invention, a heartbeat detection mechanism of a local degradation and autonomous control module adopts a self-defined deterministic heartbeat protocol to identify an off-network event of an edge and a cloud end, and a preset degradation control decision-making tree in a local ROM is immediately started after a broken link is detected; and after the network is recovered, the system is automatically switched to a cloud collaboration mode, operation logs, abnormal records and differential packets in a network outage period are reported in batches, the newest rules and data of the cloud are synchronized, and smooth transition of services is realized.

Description

Technical Field

[0001] This invention relates to the fields of data processing and Internet of Things (IoT) technology, and in particular to a data trend prediction system based on AI analysis. Background Technology

[0002] With the rapid development of IoT technology, edge computing and cloud collaboration have become the mainstream architecture. The massive amounts of data generated by various sensors require real-time processing, analysis, and transmission to achieve accurate prediction and control of business status. However, existing IoT data trend prediction systems still have the following problems: Traditional sensor data reading uses a kernel-mode and user-mode data copying method, which has high transmission latency and is difficult to adapt to the high-speed data acquisition needs of massive sensors; Existing systems rely heavily on cloud computing power to execute business logic, with edge nodes only responsible for data collection and uploading. When network latency is high or unstable, business response speed drops significantly, failing to meet real-time control requirements. The method of continuously reporting raw time-series data between the edge and the cloud is often used, which transmits data even if there is no substantial change. This leads to a serious waste of bandwidth resources, especially in scenarios with a large number of edge nodes and limited network bandwidth.

[0003] Therefore, a data trend prediction system based on AI analysis is proposed to address the aforementioned problems. Summary of the Invention

[0004] The purpose of this invention is to provide a data trend prediction system based on AI analysis in order to solve the above-mentioned problems.

[0005] To achieve the above objectives, the present invention adopts the following technical solution: A data trend prediction system based on AI analysis includes: The multi-source data convergence module is configured to read sensor data, complete verification, filtering and format unification, and combine AI anomaly detection algorithm to identify sensor data anomalies, providing standardized input for subsequent modules. The business state machine and logic hard-coded execution module are configured to compile cloud-based business rules into a hard-coded deterministic finite state machine to achieve local business response and physical control. The business state vector differential extraction module is configured to generate differential packets and report them to the cloud only when a substantial transition occurs in the business state. The local degradation and autonomous control module is configured to detect network outages through heartbeat detection and automatically activate the locally preset degradation control decision tree; The cloud-based vector clock synchronization and conflict resolution module is configured to use vector clocks to handle data conflicts between the edge and the cloud during network outages, achieving eventual consistency of global data after network recovery.

[0006] Preferably, the multi-source data convergence module specifically includes: Memory mapping or zero-copy technology is used to read massive amounts of raw data from underlying sensors; The lightweight protocol parsing pipeline is designed for heterogeneous IoT scenarios with multiple protocols. The specific process is as follows: Phase 1: The original messages sent by the sensor are captured using a circular buffer. The verification content includes the message header identifier, message length, and checksum. Phase 2: Built-in protocol identification library, which automatically identifies protocols through message header identifiers and protocol field features; Phase 3: Employ dead zone filtering algorithms to set differentiated dead zone thresholds for different types of sensors; Phase 4: Define a unified basic business event structure within the system. The structure contains fixed fields, including: sensor ID, data acquisition timestamp, data type, data value, protocol type, data status, checksum, and reserved fields. Fill the parsed valid data according to the structure format. After filling, perform structure validation. If the validation passes, it is used as the final output for subsequent input to the edge business state machine.

[0007] Preferably, the business state machine is a deterministic finite state machine, and the construction process is as follows: The DFA is used as the execution vehicle for business logic. The DFA consists of a 5-tuple. Composition, in which: A set of states: A finite number of state nodes are preset according to the specific business scenario, and each state node has a unique identifier; The input symbol set consists of data values ​​and data states in the basic business event structure; The state transition function is written into the ROM of the edge gateway using a hard-coded method. Initial state: The default is standby state. After the edge device is started, the state machine automatically enters the initial state. The set of termination states includes fault shutdown states.

[0008] Preferably, the compilation, deployment, and execution of the DFA include: A DFA compilation tool is built in the cloud to convert the user-defined business rules into DFA state transition function code. After compilation, the code is sent to the edge gateway and written into ROM. The state machine is executed in a polling manner. Each polling cycle reads the basic business event structure, extracts the input symbols, and executes the state transition according to the state transition function.

[0009] Preferably, in the business state vector differential extraction module, the definition of the business state vector and the extraction and generation of the differential state vector specifically include: Definition and maintenance of business state vectors: Edge nodes set up a state vector storage area of ​​preset size in memory to maintain the current business state vector. : It is an N-dimensional vector, with each dimension corresponding to a core business state parameter; After the edge device starts up, Initialize to default values. After initialization, wait for state transition instructions from the business state machine and the logic hard-coded execution module before starting the update. ; The update is synchronized with the state transitions of the business state machine and the logic hard-coded execution module. That is, each time the business state machine and the logic hard-coded execution module complete a state transition, it triggers... Update; Differential state vector Extraction and generation: The difference vector is extracted and the difference packet is generated only when there is a substantial node transition between the business state machine and the DFA in the logic hard-coded execution module, as detailed below: When a change in the state node identifier of the DFA is detected, it is determined that a substantial state transition has occurred, triggering differential vector extraction; otherwise, it is only a change in the state node identifier of the DFA. If the parameter changes of the non-state identifier do not trigger a state transition, then the difference vector will not be extracted and will not be reported. Extracting the historical state vector before the state transition , with the current state vector Perform dimension-by-dimensional difference calculation; After a state transition occurs, differential calculation and differential packet generation are completed within a preset time period. After generation, the packets are stored in the reporting buffer and await reporting.

[0010] Preferably, the differential packet reporting mechanism to the cloud is as follows: After the differential packet is generated, if the edge node and the cloud network are connected normally, it will be reported immediately; if the network connection is abnormal, it will be temporarily stored in the reporting buffer and reported in batches after the network is restored. The reporting buffer uses a circular storage mechanism and records the generation timestamp of each differential packet. After receiving the differential packets, the cloud sorts them according to the timestamp. If a missing differential packet is found, a retransmission request is sent to the edge node, and the edge node retransmits the corresponding differential packet according to the request.

[0011] Preferably, the process of identifying network disconnection through heartbeat detection includes: A dedicated heartbeat communication link is established between the edge node and the cloud, using a custom deterministic heartbeat protocol to detect network connection status in real time. The specific implementation is as follows: The heartbeat protocol uses a binary format, with a fixed heartbeat packet length. The fields include: frame header, edge node ID, heartbeat sequence number, status identifier, checksum, and reserved fields. Edge nodes send heartbeat packets to the cloud at preset time intervals; after receiving the heartbeat packets, the cloud must return a heartbeat response packet within a preset time period. Edge nodes have a built-in disconnection counter that records the number of heartbeat failures. When the number of consecutive heartbeat failures reaches the preset maximum allowed number, it is determined that the connection with the cloud is lost, triggering a disconnection event.

[0012] Preferably, after the link failure event is triggered, the edge node stops sending data to the cloud, closes the communication link with the cloud, and releases communication resources; at the same time, it activates the degradation control decision tree preset in the local ROM and starts the autonomous control module. After the autonomous control module is started, it reads the basic business event structure output by the multi-source data convergence module in a polling manner, extracts the core data, inputs it into the degradation control decision tree, and executes the corresponding physical control commands according to the rules of the decision tree. During the execution, all control commands are directly output to the execution components of the edge nodes, and the execution results are fed back to the autonomous control module in real time. Once the edge node detects that the network has recovered, it stops executing the degradation control decision tree, exits the autonomous control mode, and restores the communication link with the cloud.

[0013] Preferably, the cloud-based vector clock synchronization and conflict resolution module specifically includes: Vector clock Given a 2-dimensional vector, ,in For cloud-based event counters, For the event counter of the edge node; The cloud allocates an independent vector clock storage area for each edge node, recording the corresponding edge node data in real time. Value; when data changes in the cloud, Counter incremented by 1, update value; Edge nodes maintain local data in memory. The value, when data changes occur at edge nodes during network outages. Counter incremented by 1, update value; After the network is restored, the edge node first sends a synchronization request to the cloud, including the edge node ID and the current local status. Value, that is After receiving the synchronization request, the cloud will store the data of the edge nodes it maintains. Value, that is Returned to the edge node; the edge node receives. Afterwards, with the local Perform a comparison and determine the data synchronization method based on the comparison results; When data changes are detected at both the edge and the cloud, the changed data from both sides are merged based on preset deterministic conflict resolution rules.

[0014] Preferably, the conflict resolution execution process is as follows: The cloud-based merging engine extracts the change events from both conflicting parties and obtains the change events from both sides. Value, changed content, change timestamp, change type; Based on the conflict resolution priority rules, determine the priority of the change operations of both parties and determine which party's change result shall prevail; According to the determined priority, merge the changed data from both parties and update the global database in the cloud; at the same time, generate a conflict resolution log. The cloud will display the latest merged data, conflict resolution logs, and the latest... Values ​​are sent to edge nodes; After receiving the data, the edge node updates its local data and The value clears merged events from the local operation log, completing data synchronization and conflict resolution.

[0015] In summary, due to the adoption of the above technical solution, the beneficial effects of the present invention are: 1. This invention uses a heartbeat detection mechanism of local degradation and autonomous control module, and adopts a custom deterministic heartbeat protocol to identify network outage events at the edge and cloud. When a network outage is detected, the degradation control decision tree pre-set in the local ROM is immediately started. After the network is restored, the system automatically switches to cloud collaborative mode, and reports the operation logs, anomaly records and differential packets during the network outage in batches, and synchronizes the latest rules and data in the cloud to achieve a smooth transition of business.

[0016] 2. This invention addresses the latency issues caused by kernel-mode and user-mode copying in traditional data reading by employing a dual technology of memory mapping and zero-copy in the multi-source data convergence module. The memory mapping technology enables direct reading and writing of sensor data, adapting to sensor scenarios with different data volumes. Combined with an AI fault self-diagnosis model, it detects sensor connection status and module malfunctions in real time, processes and reports them promptly, ensuring the continuity and integrity of data acquisition. This addresses the issues of data redundancy and inefficient parsing in traditional systems, providing high-quality and highly reliable standardized input for subsequent AI analysis and data trend prediction. Attached Figure Description

[0017] Further details, features, and advantages of this application are disclosed in the following description of exemplary embodiments in conjunction with the accompanying drawings, in which: Figure 1 This is a system structure diagram of the present invention. Detailed Implementation

[0018] Several embodiments of this application will now be described in more detail with reference to the accompanying drawings to enable those skilled in the art to implement this application. This application may be embodied in many different forms and for various purposes and should not be limited to the embodiments set forth herein. These embodiments are provided to make this application thorough and complete, and to fully convey the scope of this application to those skilled in the art. The embodiments described do not limit this application.

[0019] Unless otherwise defined, all terms used herein (including technical and scientific terms) shall have the same meaning as commonly understood by one of ordinary skill in the art to which this application pertains. It will be further understood that terms such as those defined in commonly used dictionaries shall be interpreted as having a meaning consistent with their meaning in the relevant field and / or the context of this specification, and shall not be interpreted in an idealized or overly formal sense unless expressly defined herein.

[0020] Example 1

[0021] Its specific implementation method is combined with the appendix Figure 1 Please provide a detailed explanation.

[0022] Appendix Figure 1 This invention provides a data trend prediction system structure block diagram based on AI analysis, which shows the connection relationship between the multi-source data convergence module and the cloud vector clock synchronization and conflict resolution module, and marks the main functional interaction flow of each module.

[0023] In this embodiment, it includes: The multi-source data convergence module is configured to read sensor data through memory mapping / zero-copy technology, and completes verification, filtering and format unification through a protocol parsing pipeline. Combined with AI anomaly detection algorithm, it identifies sensor data anomalies and provides standardized input for subsequent modules. Specifically, it includes: Low-level sensor data reading technology: This technology employs memory mapping or zero-copy techniques to achieve extremely fast reading of massive amounts of raw low-level sensor data. Specific parameters and implementation methods are as follows: Memory mapping implementation: The edge gateway uses a 32-bit / 64-bit ARM architecture processor (such as STM32H743, RK3568) to map the sensor register address to the virtual memory address space of the edge device (mapped address range is 0x40000000-0x400FFFFF), with a mapping granularity of 4 bytes. Sensor messages are read by directly reading and writing virtual memory addresses. The reading frequency is configurable (range is 10Hz-1000Hz, adaptively adjusted according to the sensor type, such as 10Hz for temperature sensors and 1000Hz for current sensors). A timeout mechanism is set during the reading process, with a timeout threshold of 50ms. If the timeout occurs, a hardware interrupt is triggered, the mapping relationship is reinitialized, and an exception log is recorded (the log format includes timeout time, sensor ID, and mapping address).

[0024] Zero-copy technology implementation: When the sensor data volume is large (single message ≥ 128 bytes), zero-copy mode is enabled. Through the sendfile() system call of the Linux system, the data in the sensor buffer is directly transmitted to the memory buffer of the edge gateway, skipping the data copying process between kernel mode and user mode. The data transmission latency is controlled within 10μs. At the same time, a buffer size threshold is set (default 1MB, which can be dynamically adjusted according to the number of sensors). When the buffer data reaches 80% of the threshold, batch data processing is triggered to avoid buffer overflow.

[0025] Lightweight protocol parsing pipeline design: Specifically designed for heterogeneous multi-protocol IoT scenarios, it consists of four sequentially executed stages. Each stage has clearly defined inputs / outputs, processing logic, and fault tolerance mechanisms, and can be directly compiled and deployed to edge gateways. The specific process is as follows: Phase 1: Message Capture and Verification (Input: Raw sensor messages; Output: Raw messages that pass verification). A circular buffer (512KB) is used to capture the raw messages sent by the sensor. Verification includes the message header identifier (e.g., 0x01 for Modbus protocol messages, 0x00 for MQTT protocol messages), message length (conforming to the corresponding protocol specification, e.g., 8~256 bytes for Modbus RTU messages), and checksum (CRC16 checksum, polynomial 0xA001). Messages that fail verification are discarded, and the reason for discarding is recorded (e.g., incorrect message header, checksum mismatch). The discard rate is controlled within 0.1%. Phase 2: Protocol Identification and Parsing (Input: Verified raw message; Output: Parsed raw data). A built-in protocol identification library includes Modbus (RTU / TCP), MQTT, OPCUA, and three common proprietary industrial protocols. Automatic protocol identification is achieved through message header identifiers and protocol field characteristics (such as the Modbus function code field and the MQTT control message type field), with an identification time ≤1μs. During parsing, corresponding fields for each protocol are parsed. For example, Modbus RTU protocol parses the slave address, function code, data register address, and data value; MQTT protocol parses the topic and payload data. A retry mechanism is triggered when parsing errors occur (maximum 3 retries, each 10ms interval). Failed retry data is marked as abnormal and temporarily stored in a local abnormal buffer (64KB in size), and periodically (every 10 minutes) reported to the cloud.

[0026] Phase 3: Dead Zone Filtering (Input: Raw data after protocol parsing; Output: Filtered valid data). A dead zone filtering algorithm is used, setting differentiated dead zone thresholds for different sensor types (configurable remotely via the cloud or manually locally). Specific threshold ranges are: temperature sensor ±0.1℃, current sensor ±0.5A, voltage sensor ±1V, humidity sensor ±1%RH. The filtering logic is as follows: record the previous valid data value. If the difference between the current data and the previous data is less than the corresponding dead zone threshold, it is considered invalid data and not processed further. If the difference is greater than or equal to the dead zone threshold, it is considered valid data and proceeds to the next phase. An exception mechanism is also set up: when data exceeds the sensor's range (e.g., the temperature sensor's range is -40℃ to 85℃, exceeding this range is considered an exception), regardless of the difference, it is considered valid data and an anomaly warning is triggered.

[0027] Phase 4: Format Unification (Input: Filtered valid data; Output: Standardized basic business event structure). Define a unified basic business event structure within the system. The structure contains 8 fixed fields, with the following field definitions, data types, and lengths: Sensor ID (string, 16 bytes), Data Acquisition Timestamp (uint64_t, 8 bytes, accurate to microseconds, synchronized with the edge device's local clock), Data Type (enumerated type, 1 byte, e.g., 0x01 represents temperature, 0x02 represents current), Data Value (float, 4 bytes, retaining 2 decimal places), Protocol Type (enumerated type, 1 byte, e.g., 0x01 represents Modbus, 0x02 represents MQTT), Data Status (enumerated type, 1 byte, 0x00 represents normal, 0x01 represents abnormal), Checksum (uint16_t, 2 bytes, CRC32 check), and Reserved Field (4 bytes, for subsequent expansion). Fill the parsed valid data according to the structure format. After filling, perform structure validation. If the validation passes, it becomes the final output, used as input for the subsequent edge business state machine.

[0028] The module incorporates an AI-based fault self-diagnosis model to monitor sensor connectivity in real time (by periodically sending detection commands at 1-second intervals). If a sensor is detected as offline (no response received after 3 consecutive attempts), it is marked as offline, data reading from that sensor is stopped, and the data is reported to the cloud. Simultaneously, an error counter is set for each stage of the protocol parsing pipeline. When the cumulative error count reaches 10 times per minute, the module is restarted (restart time ≤ 100ms). After restarting, the error counter is cleared, and normal operation resumes. A 128KB log storage area is reserved locally to record all anomalies during module operation (such as sensor offline, protocol parsing failure, buffer overflow, etc.). The logs are retained for 7 days and automatically overwritten after this period.

[0029] The business state machine and logic hard-coded execution module are configured to compile cloud-based business rules into hard-coded deterministic finite state machines, enabling local business responses and physical control without relying on cloud computing power. The construction process is as follows: Instead of traditional database query or rule engines, DFA is adopted as the execution vehicle for business logic. The specific construction process, parameter settings, and execution mechanism are as follows: The structural definition of a DFA: A DFA consists of quintuples. The composition, and the specific definitions and implementations of each element are as follows: A set of states: A finite number of state nodes are preset according to specific business scenarios. Each state node has a unique identifier (uint8_t type, value range 0x00-0xFF). State nodes include initial state, normal operation state, warning state, abnormal state, shutdown state, etc. For example, in the scenario of intelligent low-voltage distribution cabinet, Q includes 5 core state nodes: "standby state (0x00)", "normal billing state (0x01)", "early warning load reduction state (0x02)", "overload protection state (0x03)" and "fault shutdown state (0x04)". The number of states can be expanded according to business needs (up to 256 states are supported).

[0030] The input symbol set consists of the data values ​​and data states in the basic business event structure output by the multi-source data convergence module. Each input symbol corresponds to a specific business condition (such as current value ≥100A, voltage value ≤220V, data state is abnormal, etc.). The type of the input symbol is completely matched with the data type of the structure output by the multi-source data convergence module to ensure input compatibility.

[0031] The state transition function is written to the edge gateway's ROM (read-only memory, capacity ≥128KB) using a hard-coded method. The function expression is as follows: ,in This is the current state. For input symbols, This represents the state after the transition; the specific rules for the transition function are compiled and generated from commercial rules distributed from the cloud.

[0032] For example, in the scenario of intelligent low-voltage distribution cabinet, the transfer rules include: if the current state is "normal billing state (0x01)" and the input symbol is "current value ≥ 100A and lasts for 500μs", then transfer to "early warning load reduction state (0x02)"; if the current state is "early warning load reduction state (0x02)" and the input symbol is "current value ≤ 80A and lasts for 1000μs", then transfer back to "normal billing state (0x01)"; if the current state is "early warning load reduction state (0x02)" and the input symbol is "current value ≥ 120A and lasts for 300μs", then transfer to "overload protection state (0x03)". All transfer rules are deterministic rules, and there is no situation where one input symbol corresponds to multiple state transfers.

[0033] Initial state: The default is "standby state (0x00)". After the edge device is started, the state machine automatically enters the initial state. When the first valid input symbol output by the multi-source data convergence module is received, the state transition begins. If no valid input symbol is received within 30 seconds after startup, the initial state is maintained and an abnormal warning is triggered (reported to the cloud).

[0034] The set of termination states includes "fault shutdown state (0x04)". When the state machine transitions to the termination state, it stops executing business logic, shuts down relevant execution components (such as the power supply switch of the intelligent low-voltage distribution cabinet), and immediately reports to the cloud. At the same time, it records the termination reason (such as overload, short circuit, etc.) locally.

[0035] The compilation, deployment, and execution of DFA include: DFA Compilation and Deployment: A dedicated DFA compilation tool is built in the cloud to convert user-defined business rules (such as power distribution safety rules and billing compliance rules) into DFA state transition function code (written in C language and adapted to the ARM architecture of edge devices). During the compilation process, syntax verification and conflict detection are performed (to ensure the determinism of transition rules). After compilation, a binary file (.bin format) is generated and distributed to the edge gateway over the network. After receiving the binary file, the edge gateway writes it to ROM (which cannot be modified to prevent rule invalidation due to accidental operation). After deployment, the state machine is automatically restarted and the new transition rules are loaded. It supports remote rule updates in the cloud without affecting the normal operation of the state machine during the update process (using a double buffer mechanism, switching to execution only after the new rule is loaded).

[0036] The execution mechanism of DFA: The state machine is executed in a polling manner. The polling period is synchronized with the data output frequency of the multi-source data convergence module (10Hz~1000Hz). Each polling reads the basic business event structure output by the multi-source data convergence module, extracts the input symbols, and executes the state transition according to the state transition function. During the execution, all operations of the state machine are completed in the memory of the edge device (memory usage ≤64KB), without involving any external storage or network interaction, ensuring execution speed.

[0037] The state machine has a built-in state verification mechanism. After each state transition, it verifies the matching between the current state and the input symbol. If a mismatch occurs (such as an invalid input symbol causing the transition to fail), the current state is maintained and the verification error is recorded in the log. Meanwhile, a state machine watchdog is set up to periodically (every 100ms) check the running status of the state machine. If the state machine is detected to be stuck (it has not completed a polling cycle for more than 500ms), the edge gateway is triggered to restart. After restarting, the state machine is restored to its initial state to ensure stable system operation. The state transition rules in the ROM are redundantly stored (two copies, with addresses 0x00000-0x01FFFF and 0x020000-0x03FFFF respectively). If one copy of the rules is corrupted, it will automatically switch to the other copy to avoid rule failure.

[0038] The business state vector differential extraction module is configured to generate differential packets and report them to the cloud only when a substantial transition occurs in the business state, which greatly saves communication bandwidth while ensuring data integrity. Specifically, it includes: This solution addresses the communication bottleneck of "huge bandwidth consumption for data interaction between the edge and the cloud" in IoT scenarios. It significantly reduces network bandwidth consumption by only reporting "commercially significant state changes" instead of continuously reporting the original time-series data stream. At the same time, it ensures that the cloud can monitor the business status of the edge in real time, balancing communication efficiency and data integrity. It is well-suited to the characteristics of IoT scenarios with many edge nodes and limited network bandwidth.

[0039] Definition and maintenance of business state vectors: Edge nodes have a dedicated state vector storage area of ​​a preset size (256KB, using SRAM, read / write speed ≥100MB / s) in memory to maintain the current business state vectors. The specific definitions and maintenance mechanisms are as follows: Composition: It is an N-dimensional vector (N is the number of business state parameters, which can be configured according to the business scenario, ranging from 8 to 64 dimensions). Each dimension corresponds to a core business state parameter. The selection of parameters is related to the state nodes of the DFA in the business state machine and the logic hard-coded execution module, as well as the business rules. For example, in a smart low-voltage distribution cabinet scenario, N=6. The six dimensions are: current status identifier (uint8_t), current current value (float), current voltage value (float), billing factor (float), number of loads running (uint8_t), and status duration (uint32_t, in ms). The parameters of each dimension have a clear data type, value range and update frequency, and are updated synchronously with the state transitions of the business state machine and the logic hard-coded execution module.

[0040] Initialization: After the edge device starts up, Initialize to default values ​​(e.g., current status identifier = 0x00, current value = 0A, voltage value = 0V, billing factor = 1.0, number of loads running = 0, state duration = 0ms). After initialization, wait for state transition instructions from the business state machine and the logic hard-coded execution module before starting the update. ; Update mechanism: The update is synchronized with the state transitions of the business state machine and the logic hard-coded execution module, that is, it is triggered immediately after each state transition is completed by the business state machine and the logic hard-coded execution module. The update includes the following: The current state identifier (updated to the state node identifier after the transition), corresponding business parameters (such as current and voltage values ​​updated to the latest output data from the multi-source data convergence module), and state duration (reset to 0 and start timing again) are updated. If the business state machine and the logic hard-coded execution module do not undergo a state transition, but the core data output by the multi-source data convergence module (such as current and voltage values) changes (and exceeds the dead zone threshold), only the parameters of the corresponding dimension are updated, and the state duration is cumulatively increased (the increase time for each update is the output cycle of the multi-source data convergence module). Data verification is set during the update process to ensure... Each dimension parameter is within a preset value range. If it exceeds the range, it is marked as abnormal, will not be updated, and an alert will be triggered.

[0041] Differential state vector Extraction and generation: Differential vectors are extracted and differential packets are generated only when there is a substantial node transition between the business state machine and the DFA in the logic hard-coded execution module (i.e., a commercially meaningful state change is triggered, such as a transition from the normal billing state to the warning and load reduction state). The specific process and technical details are as follows: State transition determination: The module has a built-in transition detection module that monitors the state transitions of the business state machine and the logic hard-coded execution module in real time. When a change in the state node identifier of the DFA is detected (i.e., When this occurs, it is determined that a substantial state transition has occurred, triggering the extraction of the difference vector; if it is only a... If the parameter changes of the non-state identifier (such as the current value fluctuating within the normal range) do not trigger a state transition, then the differential vector will not be extracted and will not be reported. Difference calculation algorithm: Employs a dimension-by-dimensional difference calculation method to extract the historical state vector before the state transition. (The historical buffer stored in the state vector storage area is 128KB in size and can store the most recent 100 historical state vectors), and the current state vector. Perform dimension-by-dimensional interpolation calculation; the calculation formula is as follows: ( For vector dimension, 1 ≤ ≤N); for discrete parameters (such as status indicators, number of loads in operation), the difference is the absolute value; for continuous parameters (such as current value, voltage value), the difference is retained to 2 decimal places and stored according to the IEEE 754 standard.

[0042] Differential packet format definition: The differential packet adopts a binary format, with a fixed total length of (N×4+12) bytes. The specific fields are as follows (arranged in order): Frame header (2 bytes): fixed at 0xAA55, used for cloud identification of differential packets; Edge Node ID (4 bytes): Uniquely identifies the edge node, pre-assigned by the cloud, such as 0x00000001; Timestamp (6 bytes): The time when the state transition occurred, accurate to microseconds, in the format of "year (2 bytes) + month (1 byte) + day (1 byte) + hour (1 byte) + minute (1 byte) + second (1 byte) + microsecond (3 bytes)"; Difference vector data (N×4 bytes): The difference in each dimension occupies 4 bytes, according to... Arranged in dimensional order; Checksum (2 bytes): CRC16 checksum, polynomial is 0xA001, used to verify the integrity of differential packets and prevent data loss or tampering during transmission.

[0043] Differential packet generation timing: After a state transition occurs, differential calculation and differential packet generation are completed within a preset time period. After generation, the packets are temporarily stored in the reporting buffer (64KB in size, which can store the most recent 1000 differential packets) and reported when the network is idle. If the reporting buffer is full, the earliest generated differential packet is overwritten and the overwrite log is recorded.

[0044] The mechanism for reporting differential packets to the cloud is as follows: Reporting trigger conditions: After the differential packet is generated, if the edge node and the cloud network are connected normally (confirmed by the heartbeat detection mechanism of the local degradation and autonomous control module), the report will be submitted immediately; if the network connection is abnormal, the packet will be temporarily stored in the reporting buffer and submitted in batches after the network is restored; the report uses the TCP protocol, port number 8080, and the reporting timeout threshold is 100ms. If the timeout occurs, the report will be retried (up to 3 times, with an interval of 500ms between each retry). If the retry fails, the report will be marked as a failure, the failure log will be recorded, and the report will be submitted again after the network is restored.

[0045] Explanation of bandwidth saving effect: Taking the scenario of intelligent low-voltage distribution cabinet as an example, the data output frequency of the multi-source data convergence module is 1000Hz, and each piece of raw time-series data is 32 bytes (basic business event structure). Therefore, the bandwidth usage of the raw data is 1000Hz × 32 bytes = 32000 bytes / second ≈ 31.25KB / s. The frequency of state transitions is an average of 1 time / minute (during normal operation), and the length of the differential packet is (6 × 4 + 12) = 36 bytes. Therefore, the bandwidth usage of the differential packet is 1 time / minute × 36 bytes ≈ 0.006KB / s. The bandwidth saving ratio is (31.25 - 0.006) / 31.25 × 100% ≈ 99.98%, which means that more than 99% of the invalid communication bandwidth is saved. Even in abnormal scenarios (where the state transition frequency is increased to 1 time / 10 seconds), the bandwidth usage is only 0.036KB / s, which can still save bandwidth significantly.

[0046] The reporting buffer uses a circular storage mechanism and records the generation timestamp of each differential packet. After receiving the differential packets, the cloud sorts them according to the timestamps. If a missing differential packet is found (judged by the timestamp interval), a retransmission request is sent to the edge node. The edge node retransmits the corresponding differential packet according to the request, ensuring that the cloud can obtain complete state transition data.

[0047] If during the difference calculation process, if... or If the data is abnormal (such as parameters exceeding the value range), the differential extraction will be abandoned, a differential packet will not be generated, and an error log will be recorded. If the checksum is calculated incorrectly after the differential packet is generated, the differential packet will be regenerated (up to 3 times). If the network is interrupted during the reporting process, the differential packet will be automatically stored and reported in batches after the network is restored to avoid data loss. All reporting records (including successful, failed, and retransmission status) will be recorded locally for 7 days to facilitate subsequent troubleshooting.

[0048] The local degradation and autonomous control module is configured to detect network outages through heartbeat detection and automatically start the locally preset degradation control decision tree to achieve independent service control in the network outage state. Specifically, it includes: To address the system availability issue of "shutdown upon network outage" (single point of failure) in IoT scenarios, a deterministic heartbeat detection, link failure identification, and local degradation autonomous mechanism are designed to ensure that edge nodes can automatically switch to offline autonomous mode when they lose connection with the cloud. Based on locally pre-configured control logic, they can independently complete basic business operations and physical control, avoid business interruption, and improve the robustness and reliability of the system.

[0049] Heartbeat detection and connection loss identification mechanism: A dedicated heartbeat communication link is established between the edge node and the cloud, using a custom deterministic heartbeat protocol to detect network connection status in real time. The specific implementation is as follows:

[0050] Heartbeat Protocol Definition: The heartbeat protocol uses a binary format, with a fixed heartbeat packet length of 16 bytes. Fields include: frame header (2 bytes, 0xBB66), edge node ID (4 bytes), heartbeat sequence number (4 bytes, incrementing from 0, increasing by 1 with each heartbeat packet), status identifier (2 bytes, 0x00 for normal, 0x01 for abnormal), checksum (2 bytes, CRC16 check), and reserved fields (2 bytes). The heartbeat protocol is a deterministic protocol with no redundant fields, resulting in high transmission efficiency and suitability for low-bandwidth scenarios.

[0051] Heartbeat detection parameter settings: Edge nodes send heartbeat packets to the cloud at preset time intervals (the time interval can be configured remotely via the cloud, ranging from 0.5s to 10s); after receiving the heartbeat packet, the cloud must return a heartbeat response packet within a preset duration (500ms) (the format is the same as the heartbeat packet, but the status identifier is changed to 0x02); the edge node starts a heartbeat timeout timer, with a timeout threshold of 1.5s (heartbeat cycle + 500ms response time). If no response packet is received from the cloud within the timeout threshold, it is considered a heartbeat failure. Disconnection detection logic: Edge nodes have a built-in disconnection counter that records the number of heartbeat failures. When the number of consecutive heartbeat failures reaches the preset maximum allowed number (preferably 3 times, configurable, ranging from 2 to 5 times), it is determined that the connection with the cloud is lost, triggering a disconnection event and immediately starting the local degraded autonomous mode. If the edge node receives a heartbeat response packet from the cloud again after the disconnection, it is determined that the network has recovered, the counter is reset to zero, the degraded autonomous mode is exited, and the normal cloud collaboration mode is restored. At the same time, during the disconnection detection process, the network link status (such as the connection status of the network interface and whether the IP address is valid) is detected in real time. If the network interface is physically disconnected (such as the network cable is detached), it is directly determined as a disconnection without waiting for the heartbeat failure count to accumulate.

[0052] Startup and execution process of local degraded autonomous mode: Degraded autonomous mode is the core operating mode of edge nodes when they are offline. All control logic is executed based on locally preset deterministic rules and does not rely on any external computing power or network interaction. The specific process is as follows: Mode Activation: After a link failure event is triggered, the edge node immediately stops sending data (including differential packets, exception logs, etc.) to the cloud, closes the communication link with the cloud, and releases communication resources; at the same time, it activates the pre-set degradation control decision tree in the local ROM and starts the autonomous control module. Construction and storage of the degradation control decision tree: The degradation control decision tree is based on the deterministic decision logic preset in the business scenario. It adopts a tree structure (depth ≤ 8 levels, number of nodes ≤ 64). Each node contains decision conditions, execution actions if the conditions are met, and jump nodes if the conditions are not met. There are no fuzzy decisions or probabilistic judgments. The construction of the decision tree is set by the user according to business needs (such as basic life support control, security protection control). For example, in the smart agriculture scenario, the root node of the decision tree is "whether the temperature and humidity exceed the preset range", the branch nodes are "whether the water tank has sufficient reserves", and the leaf nodes are the specific execution actions (such as turning on the sprinkler or turning off the irrigation pump). The decision tree is stored in binary format in the ROM of the edge node (occupying space ≤ 64KB). It is redundantly stored with the DFA rules of the business state machine and the logic hard-coded execution module to ensure normal reading when the network is disconnected. It supports remote cloud updates of the decision tree. The update method is consistent with the DFA rule update (double buffer mechanism).

[0053] Autonomous Control Execution Mechanism: After the autonomous control module starts, it uses a polling method (the polling period is synchronized with the data output frequency of the multi-source data convergence module) to read the basic business event structure output by the multi-source data convergence module, extract core data (such as temperature and humidity, water tank capacity, equipment operating status, etc.), and input it into the degradation control decision tree. It then executes the corresponding physical control commands according to the rules of the decision tree. During execution, all control commands are directly output to the execution components of the edge nodes (such as relays, water pumps, valves, etc.), and the execution results are fed back to the autonomous control module in real time for subsequent decision adjustments. At the same time, the autonomous control log (including execution time, execution action, input data, and execution result) is recorded in local memory. The log occupies ≤128KB of space and is retained for 7 days. It will be reported to the cloud after the network is restored.

[0054] Mode switching after network recovery: When the edge node detects network recovery (receives a heartbeat response packet from the cloud), it immediately stops executing the degradation control decision tree, exits autonomous control mode, and restores the communication link with the cloud. Simultaneously, it batch-reports the autonomous control logs, exception logs, and differential packets (temporarily stored in the reporting buffer) recorded during the network outage to the cloud. After reporting is complete, it synchronizes the latest business rules and control instructions from the cloud, and updates the local DFA state machine. State vectors restore normal cloud collaboration mode; the basic business execution of edge nodes is not interrupted during the switching process, avoiding business fluctuations.

[0055] The autonomous control module has a built-in fault self-diagnosis function, which monitors the operating status of the execution components in real time (by reading the feedback signals of the execution components). If a fault is detected in the execution component (such as the sprinkler system failing to start), a restart mechanism is executed (up to 3 restarts). If the restart fails, the component is marked as faulty, the control of the component is stopped, the fault log is recorded, and the execution logic of the decision tree is adjusted (such as prioritizing the opening of the ventilation fan when the sprinkler system fails). The degradation control decision tree uses redundant storage to avoid the decision logic from failing due to ROM damage. At the same time, a watchdog timer is set up for the autonomous control module to check the module's operating status periodically (100ms). If the module is detected to be stuck, the edge node is triggered to restart, ensuring the stability of the autonomous control.

[0056] The cloud-based vector clock synchronization and conflict resolution module is configured to use vector clock or CRDTs algorithm to resolve data conflicts between the edge and the cloud during network outages and achieve eventual consistency of global data after network recovery. Specifically, it includes: Implementation and Application of Vector Clocks: Vector clocks are a deterministic algorithm used in distributed systems to record the order of events and resolve data conflicts. This module uses the vector clock algorithm to achieve data synchronization and conflict resolution between the edge and the cloud. The specific implementation is as follows: Definition of a vector clock: Vector clock Given a 2-dimensional vector, ,in This is an event counter in the cloud (of type uint64_t, initially 0, incremented by 1 each time data changes in the cloud). An event counter for the edge node (uint64_t type, initial value 0, incremented by 1 each time data changes occur on the edge node); a vector clock is bound to each data change event, recording the counter status of the cloud and the edge node when the event occurs.

[0057] Vector clock maintenance mechanism: Cloud-based maintenance: The cloud allocates an independent vector clock storage area for each edge node, recording the corresponding clock data for that edge node in real time. Value; when data changes occur in the cloud (such as receiving external orders or updating business rules), Counter incremented by 1, update The value is recorded, and the data change event is logged. Changes include: content changes and timestamp changes. Edge node maintenance: Edge nodes maintain their local data in memory. The value is set when data changes occur at the edge node during a network outage (e.g., modifying device operating status or adjusting billing parameters during autonomous control). Counter incremented by 1, update The value is recorded in the local operation log, and the data change event is logged (the log contains...). The operation log includes the value, change content, change timestamp, and change type. It uses a circular buffer (256KB in size, capable of storing the most recent 1000 change events) for storage. It continuously records during network outages and reports in batches after the network is restored.

[0058] Vector clock synchronization mechanism: After network recovery, the edge node first sends a synchronization request to the cloud, including the edge node ID and the current local clock. Value, that is After receiving the synchronization request, the cloud will store the data of the edge node it maintains. Value, that is Returned to the edge node; the edge node receives. Afterwards, with the local A comparison is performed, and the data synchronization method is determined based on the comparison results: like = ( , (If both are equal): This means that no data changes occurred between the two parties during the network outage, no synchronization is required, and normal communication can be resumed directly. like and This indicates that during the network outage, only the edge nodes experienced data changes, while the cloud remained unchanged. The edge nodes uploaded their operation logs for the outage period to the cloud in batches. Upon receiving the logs, the cloud verified the validity of the vector clock for each operation log (ensuring...). (Consistent with the current cloud data), after verification, execute each change operation sequentially, synchronously updating the cloud data and the corresponding vector clock (to... (Updated to the values ​​reported by the edge nodes), after synchronization is complete, a confirmation response is sent to the edge nodes. After receiving the response, the edge nodes clear their local operation logs and the synchronization is complete. like and This indicates that during the network outage, only data changes occurred in the cloud, and no changes occurred on the edge nodes. The cloud batch-sends all data change events (including vector clocks and changed content) during the network outage to the edge nodes. After receiving the data, the edge nodes verify the validity of the vector clocks (ensuring...). (Consistent with the current local data), after verification, perform the change operations sequentially, updating the local data and vector clock (to... (Update to the value sent from the cloud), and after execution, send a confirmation response to the cloud to complete the synchronization; like and This indicates that data changes occurred on both sides during the network outage, resulting in a data conflict and triggering the conflict resolution mechanism.

[0059] Conflict resolution mechanism: When data changes (conflicts) are detected at both the edge and the cloud, the changed data from both sides are merged based on preset deterministic conflict resolution rules to ensure that the merged result is unique, correct, and conforms to business logic. The specific rules and implementation are as follows: Conflict identification: After receiving the operation logs reported by the edge nodes, the cloud extracts the information for each change event. The value, content of change, and type of change are compared with the change events in the cloud. If the change events of both parties target the same data object (such as the operating status of the same device or the quantity of the same inventory), it is determined that there is a conflict; if the change objects are different, there is no conflict, and the change data of both parties are directly merged.

[0060] Conflict resolution priority rules: Conflict resolution priorities are set according to the principles of "physical operations have higher priority than logical operations," "real-time operations have higher priority than delayed operations," and "safety operations have higher priority than normal operations," from highest to lowest: Physical control operations on the edge side (such as turning on the sprinkler or turning off the power switch): have the highest priority. Regardless of whether there is a corresponding logical operation in the cloud, the result of the physical operation on the edge side shall prevail. Cloud-based security compliance operations (such as modifying overload protection thresholds and setting security alert rules) have the next lowest priority. If they conflict with non-physical operations on the edge, the cloud-based security compliance operations shall prevail. Billing and statistical operations on the edge side (such as adjusting billing coefficients and recording device runtime): medium priority. If they conflict with similar operations on the cloud, the operation with the newer timestamp shall prevail. Ordinary logical operations in the cloud (such as updating business rules and adjusting parameter configurations) have the lowest priority. If they conflict with high-priority operations on the edge side, the operations on the edge side shall prevail.

[0061] The conflict resolution process is as follows: Step 1: The cloud-based merging engine extracts the change events from both sides of the conflict (events in the edge-side operation logs and the cloud's own change events) to obtain the change events from both sides. Value, changed content, change timestamp, change type; Step 2: Based on the conflict resolution priority rules, determine the priority of the change operations of both parties and determine which party's change result shall prevail; Step 3: Merge the changed data from both sides according to the determined priority and update the global database in the cloud; at the same time, generate a conflict resolution log (including the changes from both sides, the priority judgment process, and the merge result). Step 4: The cloud will merge the latest data, conflict resolution logs, and the latest... value( and (All values ​​are updated to the maximum values ​​of the counters from both sides) and sent to the edge nodes; Step 5: After receiving the data, the edge node updates its local data and... The value clears merged events from the local operation log, completing data synchronization and conflict resolution.

[0062] During synchronization, if data loss occurs (e.g., incomplete operation logs reported by edge nodes), the cloud uses vector clock comparison to detect the missing data. If a jump occurs, a retransmission request is sent to the edge node. The edge node retransmits the corresponding operation log according to the request to ensure the integrity of the synchronized data. The synchronization timeout threshold is set to 500ms. If the timeout occurs, a retry will be made (up to 3 retries, with an interval of 200ms each time). If the retry fails, it will be marked as a synchronization error and reported to the cloud administrator. At the same time, the edge node retains the local operation log and will resynchronize after the network is restored.

[0063] If an anomaly occurs in the rule determination process during conflict resolution (such as an incorrect priority determination), a downgrade resolution mechanism will be triggered. By default, the principle of "safety first, on-site first" will be followed, prioritizing the retention of safety-related data and edge control-related data. At the same time, an anomaly log will be recorded and synchronized to the cloud after the network is restored for subsequent investigation. Both the cloud and edge nodes store conflict resolution records (including conflict content, resolution rules, resolution results, and timestamps), which are retained for 7 days and are traceable.

[0064] The vector clocks of edge nodes are stored in both memory and ROM (double redundancy), while the vector clocks in the cloud are stored in the main database and backup database. This avoids the loss of vector clocks due to the failure of a single storage medium and ensures that synchronization and conflict resolution can be performed normally. After the vector clock is updated, it is immediately synchronized to the redundant storage medium.

[0065] Example 2

[0066] Taking the power distribution control scenario of an intelligent low-voltage switchgear as an example, the construction process of a deterministic finite state machine is as follows: Scenario preset conditions: The rated voltage of the intelligent low-voltage distribution cabinet is 220V / 380V, the rated current is 100A, the overload threshold is 120A, the warning threshold is 100A, and the billing rule is "billing according to actual current consumption under normal billing state, billing coefficient is 0.8 under warning and load reduction state, and billing stops under overload protection state".

[0067] DFA status node configuration: As mentioned above, it includes 5 states: standby state (0x00), normal billing state (0x01), early warning load reduction state (0x02), overload protection state (0x03), and fault shutdown state (0x04).

[0068] State transition rules (hard-coded implementation): (0x00, Data Status = Normal) = 0x01 (Normal data was received in standby mode, and the system was transferred to normal billing mode). (0x01, current value ≥100A and lasts for 500μs) = 0x02 (current reaches the warning threshold under normal billing state, and transfers to warning load reduction state). (0x02, current value ≤ 80A and lasts for 1000μs) = 0x01 (the current returns to normal after the warning load reduction state, and the system switches back to normal billing state). (0x02, current value ≥120A and lasts for 300μs) = 0x03 (the current reaches the overload threshold under the warning and load reduction state, and then switches to the overload protection state). (0x03, current value ≤ 80A and lasts for 3000μs) = 0x01 (the current returns to normal after the overload protection state, and the system switches back to normal billing state). (0x03, current value ≥150A and lasts for 100μs) = 0x04 (current seriously exceeds the limit under overload protection state, transfer to fault shutdown state);

[0069] In any state, if the data status is abnormal (such as sensor failure), the current status will be maintained and an abnormality warning will be triggered.

[0070] The execution process is as follows: The edge gateway receives data from current and voltage sensors in the power distribution cabinet in real time (after being processed by the multi-source data convergence module, a basic business event structure is output). The state machine polls and reads the structure, extracts the current value and data status, and executes the state transition according to the above transition rules. When transitioning to the early warning load reduction state (0x02), the state machine outputs a load reduction control command (controlling the load switch in the distribution cabinet to disconnect some non-core loads and reduce current consumption), and updates the billing factor at the same time; When transitioning to overload protection state (0x03), an overload protection command is output (disconnect the main switch and stop power supply), and billing is stopped at the same time; when transitioning to fault shutdown state (0x04), a shutdown command is output, all execution components are shut down, and fault information is reported to the cloud.

[0071] Example 3

[0072] In the local degradation and autonomous control module, the activation and execution of the local degradation autonomous mode are illustrated using a smart agriculture integrated management scenario as an example: Scenario preset conditions: The core control requirement of the smart agricultural greenhouse is to "ensure the basic growth environment of crops when the network is disconnected". The preset environmental thresholds are: temperature 15℃~30℃, humidity 60%RH~80%RH, and water storage tank capacity ≥20%; the execution components include the sprinkler system, ventilation fan, and irrigation pump. The degradation control decision tree depth is 3 layers and the number of nodes is 8.

[0073] Specific rules for the degradation control decision tree (hardcoded in ROM): Root node (node ​​1): The input parameter is "current temperature", and the decision condition is "temperature < 15℃ or temperature > 30℃"; if the condition is met, jump to node 2; if the condition is not met, jump to node 3. Node 2 (Temperature Anomaly Node): The input parameter is "current humidity", and the decision condition is "humidity < 60%RH or humidity > 80%RH". If the condition is met, jump to Node 4; otherwise, execute "turn on ventilation fan and adjust temperature", and jump to Node 7. Node 3 (Normal Temperature Node): The input parameter is "current humidity", and the decision condition is "humidity < 60%RH or humidity > 80%RH". If the condition is met, jump to Node 5; if the condition is not met, execute "maintain current state" and jump to Node 7. Node 4 (Node with abnormal temperature and humidity): The input parameter is "reservoir capacity", and the decision condition is "reservoir capacity ≥ 20%". If the condition is met, execute "turn on the sprinkler system and turn on the ventilation fan at the same time", and jump to node 7; if the condition is not met, execute "turn on the ventilation fan only and turn off the sprinkler", and jump to node 7. Node 5 (Humidity Anomaly Node): The input parameter is "Water Tank Balance", and the decision condition is "Water Tank Balance ≥ 20%"; if the condition is met, execute "Start Sprinkler System" and jump to Node 7; if the condition is not met, execute "Maintain Current State and Record Humidity Anomaly" and jump to Node 7. Node 7 (Execution Feedback Node): The input parameter is "Execution Component Running Status", and the decision condition is "Execution Component Running Normally". If the condition is met, wait for the next round of polling. If the condition is not met, execute "Restart the corresponding execution component (maximum 3 restarts)" and record the fault log.

[0074] The autonomous control implementation process is as follows: When the greenhouse aggregation node loses connection with the cloud, the edge node immediately starts the degraded autonomous mode. The autonomous control module polls and reads the data from the temperature and humidity sensor and the water level sensor in the water storage tank (after processing by the multi-source data convergence module), and inputs it into the degraded control decision tree. For example, when the temperature is detected to be 32℃ (exceeding the threshold), humidity is detected to be 55%RH (exceeding the threshold), and water tank capacity is detected to be 30% (meeting the conditions), the decision tree executes the instruction to "turn on the sprinkler system and turn on the ventilation fan at the same time", controlling the sprinkler system and ventilation fan to start and adjust the temperature and humidity in the greenhouse. After execution, the system checks the operating status of the sprinkler system and ventilation fan. If they are operating normally, it waits for the next round of polling. If the sprinkler system fails to start, it restarts the sprinkler system (up to 3 times) and records the fault log. The entire execution process is completed locally without cloud intervention, ensuring that the crop growth environment is basically guaranteed when the network is down.

[0075] The foregoing has only described certain exemplary embodiments of the present invention by way of illustration. Undoubtedly, those skilled in the art can modify the described embodiments in various ways without departing from the spirit and scope of the present invention. Therefore, the foregoing drawings and descriptions are illustrative in nature and should not be construed as limiting the scope of protection of the claims of the present invention.

[0076] It should be noted that, in this document, the use of relational terms such as "first" and "second" is merely for distinguishing one entity or operation from another, and does not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes the element.

[0077] It should be understood that in the various embodiments of this application, the order of the above-mentioned processes does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0078] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0079] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0080] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0081] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0082] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0083] The foregoing has only described certain exemplary embodiments of the present invention by way of illustration. Undoubtedly, those skilled in the art can modify the described embodiments in various ways without departing from the spirit and scope of the present invention. Therefore, the foregoing drawings and descriptions are illustrative in nature and should not be construed as limiting the scope of protection of the claims of the present invention.

Claims

1. A data trend prediction system based on AI analysis, characterized in that, include: The multi-source data convergence module is configured to read sensor data, complete verification, filtering and format unification, and combine AI anomaly detection algorithm to identify sensor data anomalies, providing standardized input for subsequent modules. The business state machine and logic hard-coded execution module are configured to compile cloud-based business rules into a hard-coded deterministic finite state machine to achieve local business response and physical control. The business state vector differential extraction module is configured to generate differential packets and report them to the cloud only when a substantial transition occurs in the business state. The local degradation and autonomous control module is configured to detect network outages through heartbeat detection and automatically activate the locally preset degradation control decision tree; The cloud-based vector clock synchronization and conflict resolution module is configured to use vector clocks to handle data conflicts between the edge and the cloud during network outages, achieving eventual consistency of global data after network recovery.

2. The data trend prediction system based on AI analysis according to claim 1, characterized in that, The multi-source data convergence module specifically includes: Memory mapping or zero-copy technology is used to read massive amounts of raw data from underlying sensors; The lightweight protocol parsing pipeline is designed for heterogeneous IoT scenarios with multiple protocols. The specific process is as follows: Phase 1: The original messages sent by the sensor are captured using a circular buffer. The verification content includes the message header identifier, message length, and checksum. Phase 2: Built-in protocol identification library, which automatically identifies protocols through message header identifiers and protocol field features; Phase 3: Employ dead zone filtering algorithms to set differentiated dead zone thresholds for different types of sensors; Phase 4: Define a unified basic business event structure within the system. The structure contains fixed fields, including: sensor ID, data acquisition timestamp, data type, data value, protocol type, data status, checksum, and reserved fields. Fill the parsed valid data according to the structure format. After filling, perform structure validation. If the validation passes, it is used as the final output for subsequent input to the edge business state machine.

3. The data trend prediction system based on AI analysis according to claim 1, characterized in that, The business state machine is a deterministic finite state machine, and its construction process is as follows: The DFA is used as the execution vehicle for business logic. The DFA consists of a 5-tuple. Composition, in which: A set of states: A finite number of state nodes are preset according to the specific business scenario, and each state node has a unique identifier; The input symbol set consists of data values ​​and data states in the basic business event structure; The state transition function is written into the ROM of the edge gateway using a hard-coded method. Initial state: The default is standby state. After the edge device is started, the state machine automatically enters the initial state. The set of termination states includes fault-related shutdown states.

4. The data trend prediction system based on AI analysis according to claim 3, characterized in that, The compilation, deployment, and execution of DFA include: A DFA compilation tool is built in the cloud to convert the user-defined business rules into DFA state transition function code. After compilation, the code is sent to the edge gateway and written into ROM. The state machine is executed in a polling manner. Each polling cycle reads the basic business event structure, extracts the input symbols, and executes the state transition according to the state transition function.

5. A data trend prediction system based on AI analysis according to claim 1, characterized in that, In the business state vector differential extraction module, the definition of the business state vector and the extraction and generation of the differential state vector specifically include: Definition and maintenance of business state vectors: Edge nodes set up a state vector storage area of ​​preset size in memory to maintain the current business state vector. : It is an N-dimensional vector, with each dimension corresponding to a core business state parameter; After the edge device starts up, Initialize to default values. After initialization, wait for state transition instructions from the business state machine and the logic hard-coded execution module before starting the update. ; The updates are synchronized with the state transitions of the business state machine and the logic hard-coded execution module; Differential state vector Extraction and generation: When a substantial node transition occurs between the business state machine and the DFA in the logic hard-coded execution module, the difference vector is extracted and a difference packet is generated, as follows: When a change in the state node identifier of the DFA is detected, it is determined that a substantial state transition has occurred, triggering differential vector extraction; otherwise, it is only a change in the state node identifier of the DFA. If the parameter changes of the non-state identifier do not trigger a state transition, then the difference vector will not be extracted and will not be reported. Extracting the historical state vector before the state transition , with the current state vector Perform dimension-by-dimensional difference calculation; After a state transition occurs, differential calculation and differential packet generation are completed within a preset time period. After generation, the packets are stored in the reporting buffer and await reporting.

6. The data trend prediction system based on AI analysis according to claim 5, characterized in that, The mechanism for reporting differential packets to the cloud is as follows: After the differential packet is generated, if the edge node and the cloud network are connected normally, it will be reported immediately; if the network connection is abnormal, it will be temporarily stored in the reporting buffer and reported in batches after the network is restored. The reporting buffer uses a circular storage mechanism and records the generation timestamp of each differential packet. After receiving the differential packets, the cloud sorts them according to the timestamp. If a missing differential packet is found, a retransmission request is sent to the edge node, and the edge node retransmits the corresponding differential packet according to the request.

7. A data trend prediction system based on AI analysis according to claim 1, characterized in that, The process of identifying network outages through heartbeat detection includes: A dedicated heartbeat communication link is established between the edge node and the cloud, using a custom deterministic heartbeat protocol to detect network connection status in real time. The specific implementation is as follows: The heartbeat protocol uses a binary format, with a fixed heartbeat packet length. The fields include: frame header, edge node ID, heartbeat sequence number, status identifier, checksum, and reserved fields. Edge nodes send heartbeat packets to the cloud at preset time intervals; after receiving the heartbeat packets, the cloud must return a heartbeat response packet within a preset time period. Edge nodes have a built-in disconnection counter that records the number of heartbeat failures. When the number of consecutive heartbeat failures reaches the preset maximum allowed number, it is determined that the connection with the cloud is lost, triggering a disconnection event.

8. A data trend prediction system based on AI analysis according to claim 7, characterized in that, After the link failure event is triggered, the edge node stops sending data to the cloud, closes the communication link with the cloud, and releases communication resources; at the same time, it activates the degradation control decision tree preset in the local ROM and starts the autonomous control module. After the autonomous control module is started, it reads the basic business event structure output by the multi-source data convergence module in a polling manner, extracts the core data, inputs it into the degradation control decision tree, and executes the corresponding physical control commands according to the rules of the decision tree. During the execution, all control commands are directly output to the execution components of the edge nodes, and the execution results are fed back to the autonomous control module in real time. Once the edge node detects that the network has recovered, it stops executing the degradation control decision tree, exits the autonomous control mode, and restores the communication link with the cloud.

9. A data trend prediction system based on AI analysis according to claim 1, characterized in that, The cloud-based vector clock synchronization and conflict resolution module specifically includes: Vector clock Given a 2-dimensional vector, ,in For cloud-based event counters, For the event counter of the edge node; The cloud allocates an independent vector clock storage area for each edge node, recording the corresponding edge node data in real time. Value; when data changes in the cloud, Counter incremented by 1, update value; Edge nodes maintain local data in memory. The value, when data changes occur at edge nodes during network outages. Counter incremented by 1, update value; After the network is restored, the edge node first sends a synchronization request to the cloud, including the edge node ID and the current local status. Value, that is After receiving the synchronization request, the cloud will store the data of the edge nodes it maintains. Value, that is Returned to the edge node; the edge node receives. Afterwards, with the local Perform a comparison and determine the data synchronization method based on the comparison results; When data changes are detected at both the edge and the cloud, the changed data from both sides are merged based on preset deterministic conflict resolution rules.

10. A data trend prediction system based on AI analysis according to claim 9, characterized in that, The conflict resolution process is as follows: The cloud-based merging engine extracts the change events from both conflicting parties and obtains the change events from both sides. Value, changed content, changed timestamp, changed type; Based on the conflict resolution priority rules, determine the priority of the change operations of both parties and determine which party's change result shall prevail; According to the determined priority, merge the changed data of both parties and update the global database in the cloud; at the same time, generate a conflict resolution log. The cloud will display the latest merged data, conflict resolution logs, and the latest... Values ​​are sent to edge nodes; After receiving the data, the edge node updates its local data and... The value clears merged events from the local operation log, completing data synchronization and conflict resolution.

Images