A cloud-edge collaborative intelligent management method and system for rental houses

Abstract

This invention discloses a cloud-edge collaborative intelligent management method and system for rental housing, relating to the field of electronic digital data processing technology. It includes: S1: Determining a robust hybrid logic clock corresponding to each event through edge computing nodes and a cloud management platform, and determining the occurrence state of each event based on the robust hybrid logic clock, obtaining a hybrid vector timestamp corresponding to each event, and simultaneously sorting and connecting all events based on the hybrid vector timestamps to construct a corresponding local causal graph; S2: Determining the hybrid vector timestamp corresponding to each event based on the local causal graph, and processing all events in an ordered manner based on the hybrid vector timestamps. This invention, through the setting of a robust hybrid logic clock and a local causal graph, can accurately capture the causal and concurrent relationships between events, effectively avoiding false triggering of intelligent scenarios or misjudgment of decisions caused by timing discrepancies.

Description

Technical Field

[0001] This invention relates to the field of electronic digital data processing technology, specifically a cloud-edge collaborative intelligent management method and system for rental housing. Background Technology

[0002] With the acceleration of urbanization and the continuous growth of the floating population, the housing rental market is expanding rapidly, and rental housing management is facing increasingly complex challenges. Traditional rental housing management models mainly rely on manual inspections, paper records, or simple local electronic systems, which suffer from inefficiency, slow response, difficulty in timely detection of safety hazards, and poor tenant experience. Especially in scenarios such as scattered housing resources, long-term rental apartments, and short-term rental homestays, landlords or operators often need to manage a large number of geographically dispersed housing units simultaneously, lacking real-time, unified, and intelligent monitoring methods for equipment status, energy consumption, safety conditions, and tenant behavior.

[0003] In recent years, the widespread adoption of Internet of Things (IoT) technology has provided fundamental support for the intelligentization of rental properties. By deploying terminal devices such as smart door locks, water and electricity meters, smoke detectors, cameras, and temperature and humidity sensors, real-time monitoring and remote control of the property's status can be achieved. However, if all the data generated by these massive heterogeneous devices is uploaded to the cloud for processing, it will not only put enormous pressure on network bandwidth and cause transmission delays, but may also lead to the loss of critical alarm information due to network instability, affecting emergency response efficiency. In addition, centralizing all data in the cloud also poses risks of privacy leaks and data security, especially in sensitive scenarios involving tenant behavior recognition and video surveillance.

[0004] To address these challenges, edge computing, a technology that pushes computing, storage, and network resources down to the network edge closer to the data source, is increasingly being adopted in smart buildings and smart communities. Edge nodes can perform tasks such as data preprocessing, anomaly detection, and real-time decision-making locally, effectively reducing cloud load, improving system response speed, and enhancing data privacy protection capabilities.

[0005] Chinese invention application CN121301034A discloses a joint resource allocation and task offloading optimization method and system. The method includes: constructing a global resource view to perceive the real-time residency status of cache lines on each computing node in a distributed system; establishing a cache-aware joint optimization model for task offloading and data prefetching, whose decision variables simultaneously include task offloading variables and data prefetching variables; and endogenously constructing cache capacity constraints using task offloading schemes to predict the set of cache lines to be evicted due to task execution; solving the joint optimization model with the objective of minimizing the total task completion time, and simultaneously generating task offloading decisions and collaborative prefetching decisions, wherein the prefetching decision is determined based on the predicted eviction set and task data dependencies. This invention solves the problem of mutual interference caused by independent optimization of task offloading and data prefetching within a unified optimization framework, achieving global proactive orchestration of computing and cache resources.

[0006] However, the above and similar technical solutions still have the following shortcomings: In a distributed cloud-edge environment, due to network latency, asynchronous local clocks of edge nodes, and parallel processing of multiple subsystems, cross-device event timing disorder and system state inconsistency are likely to occur, affecting the correctness of complex linkage scenarios. This will not only destroy the correctness of intelligent scenarios, but also cause subsequent event-based analysis and decision-making to make misjudgments. Summary of the Invention

[0007] The purpose of this invention is to provide a cloud-edge collaborative intelligent management method and system for rental housing, so as to solve the problems mentioned in the background art.

[0008] The technical solution of this invention is: a cloud-edge collaborative intelligent management method for rental housing, comprising: S1: Local causal graph construction: Through edge computing nodes and cloud management platform, the robust hybrid logic clock corresponding to each event is determined, and the occurrence state of each event is determined according to the robust hybrid logic clock. The hybrid vector timestamp corresponding to each event is obtained. At the same time, according to the hybrid vector timestamp, all events are sorted and connected to construct the corresponding local causal graph. S2: Event Detection Arbitration: Based on the local cause-effect graph, determine the mixed vector timestamp corresponding to each event, and process all events in an ordered manner according to the mixed vector timestamps, including: S2.1: Concurrency Alert: Based on the local physical estimated time corresponding to the event sending timestamp, all events are arranged in chronological order. At the same time, based on the count value of the logic counter corresponding to the event sending timestamp, different events corresponding to the same local physical estimated time are arranged in order. The events are processed in an orderly manner according to the arrangement order. During the processing, a concurrency alarm signal is triggered for concurrent events. S2.2: Conflict Identification: By setting the event conditions, conflict objects, and rule IDs, a corresponding rule base is set, and each event in the concurrent events is identified and matched. If any identical matching result occurs, each event in the concurrent events is considered a conflict event and is handled through an arbitration mechanism. Otherwise, each event in the concurrent events is not considered a conflict event and is handled through a machine learning analysis model. S2.3: Model Processing: Using the local cause-effect graph, obtain the spatial-functional topology graph corresponding to each event in the concurrent events, determine the corresponding operating device and operation type, and according to the operating device and operation type, obtain the corresponding concurrent operation records and operation results in the historical event database. At the same time, according to the concurrent operation records and operation results, determine the corresponding operation pair in the set sliding event window, and determine the corresponding processing result according to the operation pair. S2.4: Arbitration Processing: Based on the local cause-effect graph corresponding to each event in the concurrent events, determine the corresponding arbitration executor, and process each event in the concurrent events through the arbitration executor.

[0009] Furthermore, the corresponding local causal graph is constructed, including: S1.1: Clock Deployment: A clock module, an event sending unit, and an event receiving unit are set in each edge computing node and cloud management platform. The event sending unit and the event receiving unit interact with the clock module. The event sending unit is used to obtain the corresponding event sending timestamp from the clock module, and the event receiving unit is used to obtain the corresponding event receiving timestamp from the clock module. S1.2: Node Construction: Combine the event sending timestamp, event identifier, and event type corresponding to each event to construct the corresponding event node. Based on the time relationship and event occurrence relationship between each event node, determine the corresponding causal type. At the same time, based on the causal type, set the corresponding causal edge and connect each event node through the causal edge. S1.3: Node Insertion: Compare the event sending timestamp corresponding to the new event with the event sending timestamps corresponding to all event nodes to determine the closest event sending timestamp. At the same time, based on the causal edge between the event node corresponding to the closest event sending timestamp and the new event, connect the new event and the event node corresponding to the closest event sending timestamp to construct the corresponding local causal graph.

[0010] Furthermore, both the event sending unit and the event receiving unit interact with the clock module, including: S1.1.1: Reception time determination: Obtain the corresponding event timestamp, including the event sending timestamp and the event receiving timestamp, through the robust hybrid logic clock set in the clock module; S1.1.2: Determining the transmission time: Based on the local physical reception estimated time corresponding to the event reception timestamp, the reception count value of the logic counter, and the maximum allowed clock reception offset threshold, obtain the time difference between the local physical reception estimated time and the local physical estimated time, and determine the corresponding event transmission timestamp based on the time difference. S1.1.3: Clock Update: Based on the local physical estimated time, update the local physical received estimated time to obtain the updated local physical received estimated time. At the same time, increment the received count value of the logic counter to obtain the updated received count value of the logic counter. Combine the updated local physical received estimated time and the updated received count value of the logic counter to obtain the corresponding event sending timestamp.

[0011] Furthermore, the robust hybrid logic clock includes a local physical estimated time, a logic counter count value, and a set maximum allowed clock offset threshold. The local physical estimated time is set to the current time corresponding to the local operating system clock, and the initial count value of the logic counter is set to 0.

[0012] Furthermore, the time difference is compared with the maximum allowed clock reception offset threshold, and the corresponding event transmission timestamp is determined based on the comparison result, specifically: When the time difference is greater than the maximum allowed clock reception offset threshold, the corresponding event reception timestamp will experience clock drift, and the event reception timestamp will be updated; otherwise, the corresponding event reception timestamp will be the event transmission timestamp.

[0013] Furthermore, the count value of the logical counter corresponding to the new event is compared with the event sending timestamp of the event node corresponding to the nearest event sending timestamp. Based on the comparison result, the causal edge between the new event and the event node corresponding to the nearest event sending timestamp is determined, specifically as follows: When the count values ​​of the logic counters are the same, there is no causal edge between the new event and the event node corresponding to the nearest event sending timestamp; otherwise, there is a causal edge, and the new event and the event node corresponding to the nearest event sending timestamp are connected.

[0014] Furthermore, when the logical counters are arranged in an ordered manner, the count values ​​are compared only between different events within the same event node.

[0015] Furthermore, based on the operation pairs within the sliding event window, the corresponding occurrence count and negative count are determined, and the ratio between the negative count and the occurrence count is obtained. Simultaneously, based on the comparison between the ratio and a preset threshold, the corresponding event processing result is determined, specifically: When the ratio of the number of times is less than a preset threshold, each event in the concurrent events is processed according to the corresponding execution result of the operation; otherwise, each event in the concurrent events is processed through an arbitration mechanism.

[0016] Furthermore, processing is performed on each of the concurrent events, including: S2.4.1: Arbitration decision: Based on the local cause-effect graph corresponding to each event in the concurrent events, determine the operating device corresponding to each event and the jurisdiction corresponding to each operating device. When the corresponding jurisdictions all belong to the same edge computing node, arbitration is carried out through the corresponding edge arbitrator; otherwise, arbitration is carried out through the cloud arbitrator. S2.4.2: Arbitration Determination: In the edge arbitrator, execution events are determined from the concurrent events through the set execution strategy, and the execution events are processed. In the cloud arbitrator, the local causal graph of each edge computing node is obtained according to the edge computing node corresponding to each event in the concurrent events, and the corresponding causal subgraph is constructed. At the same time, the causal subgraph is analyzed through the constructed global strategy model to determine the corresponding arbitration result. Based on the arbitration result and the robust hybrid logic clock, the updated timestamp of each event in the concurrent events is obtained, and each event in the concurrent events is processed in an orderly manner based on the updated timestamp.

[0017] A cloud-edge collaborative intelligent management system for rental housing uses the aforementioned cloud-edge collaborative intelligent management method for rental housing.

[0018] This invention provides an improved cloud-edge collaborative intelligent management method and system for rental housing, which has the following improvements and advantages compared with the prior art: Firstly, this invention, through a robust hybrid logic clock and a constructed local causal graph, can accurately capture the causal and concurrent relationships between events and establish a globally consistent logical time sequence for all events. This effectively avoids false triggering of intelligent scenarios or misjudgment of decisions caused by timing disorder, thereby improving the reliability and state consistency of the system. Secondly, this invention can automatically identify concurrent events with semantic conflicts through concurrent early warning, conflict identification, model processing, and arbitration processing. It can also intelligently judge the conflict risk through rule base matching and machine learning analysis based on historical data. At the same time, it can make decisions on events that need to be arbitrated by using edge arbitrators or cloud arbitrators within the jurisdiction, thereby avoiding device state conflicts or resource contention and ensuring the rationality of operation and system stability. Thirdly, the localized local causal graph construction and edge arbitration of this invention reduce the dependence on cloud communication, reduce network bandwidth pressure and data transmission latency, enabling millisecond-level rapid response to emergency events. At the same time, for complex concurrent events across edge nodes, the cloud arbitrator can analyze based on a global perspective and causal subgraph, formulate corresponding global decision-making strategies, thereby achieving a balance between real-time response and global optimization decision-making, and improving the overall system efficiency. Fourthly, the robust hybrid logic clock mechanism of this invention can detect and correct timestamp errors caused by clock drift, enhancing fault tolerance in scenarios where physical clocks are not fully synchronized. At the same time, when handling concurrent events, it can query the historical event database and determine the execution results of operation pairs within the sliding event window, dynamically assess the corresponding operational risks, and automatically trigger an arbitration mechanism for high-risk operation pairs, thereby effectively preventing system failures caused by historically frequent problems and improving the overall robustness of the system. Attached Figure Description

[0019] The present invention will be further explained below with reference to the accompanying drawings and embodiments: Figure 1 This is a flowchart illustrating the cloud-edge collaborative intelligent management method of the present invention; Figure 2 This is a schematic diagram of the construction of the clock module in this invention; Figure 3 This is a schematic diagram of the process for determining the event sending timestamp in this invention; Figure 4This is a schematic diagram of the construction process of the local cause-effect graph in this invention; Figure 5 This is a schematic diagram of the concurrent event identification and processing flow in this invention; Figure 6 This is a schematic diagram of the concurrent event model processing flow in this invention. Detailed Implementation

[0020] 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.

[0021] refer to Figure 1 This embodiment provides a cloud-edge collaborative intelligent management method for rental housing, which specifically includes the following steps: Step S1: Local Cause-Effect Graph Construction. This involves setting up a corresponding robust hybrid logic clock in each edge computing node and cloud management platform. Each robust hybrid logic clock includes a local physical estimated time, a logic counter value, and a set maximum allowed clock offset threshold to determine the robust hybrid logic clock corresponding to each event.

[0022] Furthermore, based on the robust hybrid logic clock corresponding to each event, the robust hybrid logic clock of each event is judged to determine the occurrence state of each event, including normal state and anti-drift state. At the same time, according to the occurrence state of the event, the robust hybrid logic clock of the event is processed accordingly to obtain the hybrid vector timestamp corresponding to each event.

[0023] Furthermore, based on the mixed vector timestamps corresponding to each event, all mixed vector timestamps are arranged in chronological order. At the same time, based on the arranged mixed vector timestamps, the corresponding events are sorted and connected to construct the corresponding local causal graph.

[0024] Step S2: Event Detection and Arbitration. Based on the local causal graph constructed in Step S1, the mixed vector timestamp corresponding to each event is determined, and the events are processed in an ordered manner according to the mixed vector timestamps. It is worth noting that for concurrent events corresponding to the same mixed vector timestamp, a semantic conflict and arbitration mechanism is used to handle concurrent events.

[0025] This embodiment also provides a cloud-edge collaborative intelligent management system for rental properties, which uses the aforementioned cloud-edge collaborative intelligent management method for rental properties.

[0026] In this embodiment, a robust hybrid logic clock is used to determine the hybrid vector timestamps corresponding to each event. Based on these timestamps, the events are sorted and connected to construct a corresponding local causal graph. (See reference) Figure 3 and Figure 4 This embodiment provides a method for constructing a local cause-effect graph, which specifically includes the following steps: Step S1.1: Clock Deployment. This involves setting up a clock module, an event sending unit, and an event receiving unit in each edge computing node and cloud management platform. Both the event sending and receiving units interact with the clock module. The event sending unit retrieves the corresponding event sending timestamp from the clock module when sending an event. The event receiving unit retrieves the corresponding event receiving timestamp from the clock module when receiving an event. (Reference) Figure 2 The details are as follows: Step S1.1.1: Determining the Reception Time. Each clock module is equipped with a robust hybrid logic clock, which includes a local physical estimated time, a logic counter value, and a set maximum allowable clock offset threshold. The corresponding event timestamps, including event transmission timestamps and event reception timestamps, are determined using the local physical estimated time, the logic counter, and the set maximum allowable clock offset threshold.

[0027] It is worth noting that the local physical estimated time is the current time corresponding to the local operating system clock. The initial count value of the logic counter is set to 0, and it is logically incremented based on the result of the local physical estimated time. The maximum allowable clock offset threshold can be set according to the network round-trip time and clock accuracy, and can be specifically selected according to the actual situation, so it is not specifically described in this embodiment.

[0028] Furthermore, based on the local physical estimated time determined in the clock module, the count value of the logic counter, and the maximum allowable clock offset threshold, the event receiving timestamp corresponding to the event receiving unit is obtained.

[0029] Step S1.1.2: Determine the transmission time. Based on the event reception timestamp obtained in step S1.1.1, determine the corresponding local physical reception estimated time (i.e., the local physical estimated time in the event reception timestamp), the reception count value of the logic counter (i.e., the count value of the logic counter in the event reception timestamp), and the maximum allowed clock reception offset threshold (i.e., the maximum allowed clock offset threshold in the event reception timestamp). Simultaneously, obtain the corresponding local physical estimated time using the current time corresponding to the local operating system clock; in other words, determine the corresponding local physical real-time estimated time.

[0030] Furthermore, based on the determined local physical reception estimate time and local physical real-time estimate time, the time difference between the corresponding local physical estimates time is obtained. Simultaneously, the obtained time difference is compared with the maximum allowable clock reception offset threshold, and based on the comparison result, the event transmission timestamp corresponding to the event transmission unit is determined. Specifically: When the obtained time difference is greater than the maximum allowed clock reception offset threshold, the corresponding event reception timestamp shows clock drift, and the obtained event reception timestamp is updated. Conversely, when the obtained time difference is not greater than the maximum allowed clock reception offset threshold, the corresponding event reception timestamp is the final event timestamp. That is, the local physical reception estimate time and the reception count value of the logic counter in the event reception timestamp are combined to determine the corresponding event transmission timestamp.

[0031] Step S1.1.3: Clock Update. This involves obtaining the corresponding local physical estimated time by using the current time of the local operating system clock, determining the corresponding local physical real-time estimated time, and updating the local physical reception estimated time in the event reception timestamp based on the determined local physical real-time estimated time.

[0032] To elaborate further, based on the receive count value of the corresponding logic counter in the event reception timestamp, the receive count value of the logic counter is incremented, for example, by 1, to obtain the update count value of the corresponding logic counter. In other words, the receive count value of the logic counter in the event reception timestamp is updated by obtaining the update count value of the logic counter.

[0033] Furthermore, based on the updated local physical reception estimate time in the event reception timestamp and the updated reception count value of the logical counter, the local physical real-time estimate time and the updated count value of the logical counter are combined to determine the corresponding event sending timestamp.

[0034] Step S1.2: Node Construction. This involves combining the event sending timestamp determined for each event in Step S1.1.3, the event sending timestamp, event identifier (e.g., event ID), event content index (e.g., pointers or indexes of control commands or sensor data), and event type (e.g., raw sensing events, arbitration decision events, compensation transaction events) corresponding to each event to construct the corresponding event node.

[0035] Furthermore, based on the constructed event nodes, the temporal and event occurrence relationships between each event node are determined, thereby identifying the causal type between adjacent event nodes (such as message passing or local generation). In other words, based on the causal type between event nodes, the corresponding causal edges are determined, and each event node is connected through these determined causal edges.

[0036] Step S1.3: Node Insertion. This involves comparing the event sending timestamp corresponding to the new event with the event sending timestamps corresponding to all event nodes from Step S1.2 to determine the event sending timestamp of the event node closest to the new event's timestamp. Simultaneously, based on the comparison between the new event and the event node corresponding to the closest event sending timestamp, the corresponding causal edge is determined.

[0037] Specifically, when the count value of the logic counter corresponding to a new event is the same as the count value of the logic counter corresponding to the nearest event node, the new event and the nearest event node are concurrent events, meaning there is no causal edge between them. Conversely, when the count value of the logic counter corresponding to a new event is different from the count value of the logic counter corresponding to the nearest event node, the new event and the nearest event node are connected by a causal edge, thus obtaining the corresponding local causal graph.

[0038] In this embodiment, semantic conflicts and arbitration mechanisms are used to handle concurrent events in an orderly manner. (See reference...) Figure 5 and Figure 6 This embodiment provides an event detection arbitration method, which specifically includes the following steps: Step S2.1: Concurrency Alert. This involves arranging each event in chronological order based on its local physical estimated time corresponding to its event sending timestamp. Simultaneously, for different events corresponding to the same local physical estimated time, they are arranged in order of count value based on the logical counter value corresponding to each event's event sending timestamp. It's important to note that during the process of arranging events in order of count value, the count values ​​corresponding to different event nodes cannot be compared; that is, the comparison of count values ​​is only for different events corresponding to the same event node.

[0039] Furthermore, during the comparison of count values, if the count values ​​cannot be compared or are the same, the corresponding events are considered concurrent events, and a concurrent alarm signal is triggered simultaneously. Otherwise, each sorted event is processed in an ordered manner according to its sequence.

[0040] Step S2.2: Conflict Identification. This involves setting up a corresponding rule base based on the defined event conditions (i.e., event characteristics, such as event ID and operation type), conflict objects (i.e., conflicting event characteristics), and rule IDs (i.e., log recording and management). Simultaneously, using this rule base, each event in the concurrent events is identified and matched to determine its corresponding event conditions, conflict objects, and rule IDs. The event conditions, conflict objects, and rule IDs for each event are then compared. If any matching result (same event conditions, same conflict objects, and same rule ID) is found, then each event in the concurrent events is considered a conflict event, and it is handled through the set arbitration mechanism. Conversely, if no matching result is found, then each event in the concurrent events is not a conflict event, and it can be directly processed using a machine learning analysis model.

[0041] Step S2.3: Model Processing. Based on the concurrent events identified in Step S2.1, and using the local cause-effect graph constructed in Step S1.3, a spatial-functional topology graph corresponding to each event in the concurrent events is obtained. Simultaneously, based on the obtained spatial-functional topology graph, the corresponding operating device and operation type for each event are determined. Using the determined operating device and operation type, a keyword search is performed in the historical event database to identify the corresponding concurrent operation records and operation results. It is worth noting that when performing a keyword search in the historical event database, not all concurrent events will yield corresponding concurrent operation records and operation results.

[0042] Furthermore, based on the set sliding event window (the window size can be specifically set according to actual needs, so it is not specifically described in this embodiment, such as all events and processing results within 24 hours), operation pairs that are the same as or similar to concurrent events are identified within the sliding event window. At the same time, based on the execution results corresponding to the identified operation pairs, the execution feedback results corresponding to each operation pair are determined, so as to identify operation pairs that have negative results (such as error logs, status abnormality alarms, and manual correction by the user).

[0043] Furthermore, based on the number of negative results from the operation pair and the number of times the operation pair appears within the sliding event window, the number of negative results and the number of appearances are compared to obtain the ratio between the two. Simultaneously, this ratio is compared with a preset threshold (which can be specifically set according to actual needs, and is not specifically described in this embodiment, for example, 50%), and the corresponding processing result is determined based on the comparison result. Specifically: When the ratio of the number of occurrences obtained is less than a preset threshold, each event in the concurrent events is processed according to the corresponding execution result of the operation. Conversely, when the ratio of the number of occurrences obtained is not less than the preset threshold, each event in the concurrent events is processed through the set arbitration mechanism.

[0044] Step S2.4: Arbitration Processing. This involves determining the corresponding arbitration executor based on the local cause-effect graph for each event in the concurrent events, determining the arbitration result within each executor, and then processing each event in the concurrent events according to the determined arbitration result. Specifically: Step S2.4.1: Arbitration Decision. This involves determining the operating device corresponding to each event in the concurrent events based on the local cause-effect graph. Simultaneously, based on the determined operating devices, the jurisdiction of each operating device is determined, including the edge computing node and the cloud management platform. Specifically, when the operating devices corresponding to each event in the concurrent events belong to the same edge computing node, arbitration can be directly performed through the edge arbitrator set up in the edge computing node. Conversely, when the operating devices corresponding to each event in the concurrent events do not belong to the same edge computing node, arbitration is performed through the cloud arbitrator set up in the cloud management platform.

[0045] Step S2.4.2: Arbitration Determination. This means the edge arbitrator is configured with a corresponding execution strategy to process each event in the concurrent events. Simultaneously, the cloud arbitrator, based on the constructed local causal graph, determines the updated timestamp for each event in the concurrent events and processes each event in an ordered manner according to the updated timestamp.

[0046] Specifically, the execution strategy in this embodiment includes, but is not limited to, a preset execution priority and a current operating mode. That is, based on the preset execution priority and the current operating mode, the edge arbitrator determines the arbitration result corresponding to the concurrent events, that is, determines the execution events in the concurrent events, and performs execution processing on the concurrent events based on the determined execution events.

[0047] Furthermore, in this embodiment, the cloud arbitrator obtains the local causal graph corresponding to each edge computing node involved in each concurrent event, and then concatenates the obtained local causal graphs to construct the corresponding causal subgraph. Simultaneously, it analyzes the constructed causal subgraph using a constructed global policy model (such as a reinforcement learning model) to determine the corresponding arbitration result. Further, based on the determined arbitration result, the cloud arbitrator determines the updated timestamp corresponding to each event in the concurrent event using a corresponding robust hybrid logic clock, and then processes each event in the concurrent event in an ordered manner based on the determined updated timestamps.

[0048] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the appended claims and their equivalents.

Claims

1. A cloud-edge collaborative intelligent management method for rental housing, characterized in that, Including: S1: Local causal graph construction: Through edge computing nodes and cloud management platform, the robust hybrid logic clock corresponding to each event is determined, and the occurrence state of each event is determined according to the robust hybrid logic clock. The hybrid vector timestamp corresponding to each event is obtained. At the same time, according to the hybrid vector timestamp, all events are sorted and connected to construct the corresponding local causal graph. S2: Event Detection Arbitration: Based on the local cause-effect graph, determine the mixed vector timestamp corresponding to each event, and process all events in an ordered manner according to the mixed vector timestamps, including: S2.1: Concurrency Alert: Based on the local physical estimated time corresponding to the event sending timestamp, all events are arranged in chronological order. At the same time, based on the count value of the logic counter corresponding to the event sending timestamp, different events corresponding to the same local physical estimated time are arranged in order. The events are processed in an orderly manner according to the arrangement order. During the processing, a concurrency alarm signal is triggered for concurrent events. S2.2: Conflict Identification: By setting the event conditions, conflict objects, and rule IDs, a corresponding rule base is set, and each event in the concurrent events is identified and matched. If any identical matching result occurs, each event in the concurrent events is considered a conflict event and is handled through an arbitration mechanism. Otherwise, each event in the concurrent events is not considered a conflict event and is handled through a machine learning analysis model. S2.3: Model Processing: Using the local cause-effect graph, obtain the spatial-functional topology graph corresponding to each event in the concurrent events, determine the corresponding operating device and operation type, and according to the operating device and operation type, obtain the corresponding concurrent operation records and operation results in the historical event database. At the same time, according to the concurrent operation records and operation results, determine the corresponding operation pair in the set sliding event window, and determine the corresponding processing result according to the operation pair. S2.4: Arbitration Processing: Based on the local cause-effect graph corresponding to each event in the concurrent events, determine the corresponding arbitration executor, and process each event in the concurrent events through the arbitration executor.

2. The cloud-edge collaborative intelligent management method for rental housing according to claim 1, characterized in that, The corresponding local causal graph is constructed, including: S1.1: Clock Deployment: A clock module, an event sending unit, and an event receiving unit are set in each edge computing node and cloud management platform. The event sending unit and the event receiving unit interact with the clock module. The event sending unit is used to obtain the corresponding event sending timestamp from the clock module, and the event receiving unit is used to obtain the corresponding event receiving timestamp from the clock module. S1.2: Node Construction: Combine the event sending timestamp, event identifier, and event type corresponding to each event to construct the corresponding event node. Based on the time relationship and event occurrence relationship between each event node, determine the corresponding causal type. At the same time, based on the causal type, set the corresponding causal edge and connect each event node through the causal edge. S1.3: Node Insertion: Compare the event sending timestamp corresponding to the new event with the event sending timestamps corresponding to all event nodes to determine the closest event sending timestamp. At the same time, based on the causal edge between the event node corresponding to the closest event sending timestamp and the new event, connect the new event and the event node corresponding to the closest event sending timestamp to construct the corresponding local causal graph.

3. The cloud-edge collaborative intelligent management method for rental housing according to claim 2, characterized in that, Both the event sending unit and the event receiving unit interact with the clock module, including: S1.1.1: Reception time determination: Obtain the corresponding event timestamp, including the event sending timestamp and the event receiving timestamp, through the robust hybrid logic clock set in the clock module; S1.1.2: Determining the transmission time: Based on the local physical reception estimated time corresponding to the event reception timestamp, the reception count value of the logic counter, and the maximum allowed clock reception offset threshold, obtain the time difference between the local physical reception estimated time and the local physical estimated time, and determine the corresponding event transmission timestamp based on the time difference. S1.1.3: Clock Update: Based on the local physical estimated time, update the local physical received estimated time to obtain the updated local physical received estimated time. At the same time, increment the received count value of the logic counter to obtain the updated received count value of the logic counter. Combine the updated local physical received estimated time and the updated received count value of the logic counter to obtain the corresponding event sending timestamp.

4. A cloud-edge collaborative intelligent management method for rental housing according to claim 1 or 3, characterized in that, The robust hybrid logic clock includes a local physical estimated time, a logic counter count value, and a set maximum allowed clock offset threshold. The local physical estimated time is set to the current time corresponding to the local operating system clock, and the initial count value of the logic counter is set to 0.

5. The cloud-edge collaborative intelligent management method for rental housing according to claim 3, characterized in that, The time difference is compared with the maximum allowed clock reception offset threshold, and the corresponding event transmission timestamp is determined based on the comparison result, specifically as follows: When the time difference is greater than the maximum allowed clock reception offset threshold, the corresponding event reception timestamp will experience clock drift, and the event reception timestamp will be updated. Conversely, the corresponding event receiving timestamp is the event sending timestamp.

6. The cloud-edge collaborative intelligent management method for rental housing according to claim 2, characterized in that, The count value of the logical counter corresponding to the new event is compared with the event sending timestamp of the event node corresponding to the nearest event sending timestamp. Based on the comparison result, the causal edge between the new event and the event node corresponding to the nearest event sending timestamp is determined, specifically as follows: When the count values ​​of the logic counters are the same, there is no causal edge between the new event and the event node corresponding to the nearest event sending timestamp; otherwise, there is a causal edge, and the new event and the event node corresponding to the nearest event sending timestamp are connected.

7. The cloud-edge collaborative intelligent management method for rental housing according to claim 1, characterized in that, When the logical counters are arranged in order, the count values ​​are compared only between different events within the same event node.

8. The cloud-edge collaborative intelligent management method for rental housing according to claim 1, characterized in that, Based on the operations performed within the sliding event window, the corresponding occurrence count and negative count are determined, and the ratio between the negative count and the occurrence count is obtained. Simultaneously, based on the comparison between the ratio and a preset threshold, the corresponding event processing result is determined, specifically: When the ratio of the number of times is less than a preset threshold, each event in the concurrent events is processed according to the corresponding execution result of the operation. Conversely, each event in the concurrent events is handled through an arbitration mechanism.

9. A cloud-edge collaborative intelligent management method for rental housing according to claim 1, characterized in that, Processing each of the concurrent events includes: S2.4.1: Arbitration decision: Based on the local cause-effect graph corresponding to each event in the concurrent events, determine the operating device corresponding to each event and the jurisdiction corresponding to each operating device. When the corresponding jurisdictions all belong to the same edge computing node, arbitration is carried out through the corresponding edge arbitrator; otherwise, arbitration is carried out through the cloud arbitrator. S2.4.2: Arbitration Determination: In the edge arbitrator, execution events are determined from the concurrent events through the set execution strategy, and the execution events are processed. In the cloud arbitrator, the local causal graph of each edge computing node is obtained according to the edge computing node corresponding to each event in the concurrent events, and the corresponding causal subgraph is constructed. At the same time, the causal subgraph is analyzed through the constructed global strategy model to determine the corresponding arbitration result. Based on the arbitration result and the robust hybrid logic clock, the updated timestamp of each event in the concurrent events is obtained, and each event in the concurrent events is processed in an orderly manner based on the updated timestamp.

10. A cloud-edge collaborative intelligent management system for rental housing, characterized in that, The cloud-edge collaborative intelligent management method for rental housing, as described in any one of claims 1-9, was used.

Images