A method and system for intelligent management and operation optimization of a smart park

Abstract

This application provides a method and system for intelligent management and operation optimization of smart parks, relating to the field of smart park management and operation optimization technology. The key points of its technical solution are: by recording the current occupancy status and update time of the target physical space, receiving events to be processed and obtaining their source type and occurrence time, determining the proof capability level and status coverage conditions according to the source type, comparing the event occurrence time with the status update time, when the event occurrence time is earlier than the status update time, recording it as historical evidence and maintaining the current status unchanged, when the event occurrence time is later than the status update time and the proof capability level meets the status coverage conditions, updating the current occupancy status, updating the status update time, and generating a device control command containing a control source identifier to be sent to the end execution unit. This control source identifier is used to distinguish between platform control actions and hardware degradation.

Description

Technical Field

[0001] This application relates to the field of smart park management and operation optimization technology, specifically to a method and system for intelligent management and operation optimization of smart parks. Background Technology

[0002] In smart parks that have deployed a unified management and operation platform, the platform typically connects to multiple subsystems such as access control, meeting booking, spatial infrared sensing, lighting control, air conditioning terminals, fresh air units, operation and maintenance work order system, and park service mini-program through a public event bus, and receives events such as space presence, equipment operation, and user interaction.

[0003] In existing technologies, different subsystems have different semantic definitions for presence or occupancy. For example, swiping a card at an access control system indicates entry into an area, checking in on a conference panel indicates occupancy of the conference room, while Bluetooth positioning or geofencing reporting from mobile terminals usually only indicates that the user is reachable. Due to the different spatial granularity, semantic overlap, and varying strength of the event sources, the platform struggles to form a unified and accurate spatial occupancy judgment for multi-source events.

[0004] Meanwhile, the generation delays and reporting rhythms of various events are inconsistent. Terminals may also have local caching, batch reporting, and centralized uploading of historical heartbeats after background wake-up, resulting in discrepancies between the event occurrence time and the order in which they arrive at the platform. In particular, when mobile terminals report location heartbeats in a concentrated manner after sleep or network recovery, there may be significant arrival delays and occurrence time drifts. In network congestion scenarios, this time misalignment is even more pronounced, easily causing delayed events to be mistakenly used as real-time evidence in occupancy determination.

[0005] For example, during peak conference periods, the same person may trigger multiple events in a short period of time, such as access control, infrared activation, conference check-in, and mobile terminal heartbeat. Existing platforms often use event-triggered control commands to regulate energy consumption, which makes it difficult to effectively distinguish between short-term and stable usage, easily leading to frequent start-ups, shutdowns, or adjustments of terminal devices such as air conditioners, lighting, and fresh air systems.

[0006] However, end-efficiency units such as water valves and fans have physical response characteristics such as mechanical friction, valve core hysteresis, inertia, and start-up delay. Frequent control can cause sudden current changes, response delays, and output fluctuations. Maintenance systems typically determine equipment malfunctions based on rules such as the number of actions per unit time, average response delay, and current deviation. However, existing rules struggle to distinguish between frequent actions caused by platform control strategies and genuine equipment degradation, easily generating a large number of false fault work orders and impacting the efficiency of handling real faults.

[0007] In addition, the event bus typically consumes events in the order they arrive. Later-arriving, lagging position events may overwrite previous real-time sensor states, leading to misjudgments of space occupancy, resulting in miscontrol of equipment and energy waste.

[0008] To address the aforementioned problems, this application proposes a new solution. Summary of the Invention

[0009] The purpose of this application is to provide a method and system for intelligent management and operation optimization of smart parks, which has the advantages of solving the problems of inconsistent time sequence of multi-source events, inaccurate judgment of space occupancy due to semantic differences, and misjudgment of frequent equipment actions as hardware degradation, thereby improving the accuracy and efficiency of management and operation.

[0010] This application provides a method for intelligent management and operation optimization of smart parks, the technical solution of which is as follows: Record the current occupancy status of the target physical space and the status update time; Receive pending events for the target physical space, and obtain the event source type and occurrence time of the pending events; The evidentiary capability level of the event to be processed and the corresponding state coverage conditions are determined based on the type of event source. Compare the occurrence time of the event to be processed with the state update time of the target physical space; When the occurrence time of the pending event is earlier than the state update time, the pending event is recorded as historical evidence, and the current occupancy state of the target physical space remains unchanged. When the occurrence time of the pending event is later than the state update time, and the proof capability level of the pending event meets the state coverage condition corresponding to the current occupancy state, the current occupancy state of the target physical space is updated according to the pending event, the state update time is updated to the occurrence time of the pending event, and a device control command containing a control source identifier is generated and sent to the end execution unit corresponding to the target physical space. The control source identifier is used to distinguish between device actions caused by the current occupancy state update and the hardware degradation of the end execution unit itself at the operation and maintenance end.

[0011] The above solution solves the problems of inconsistent time sequence of multi-source events, inaccurate space occupancy judgment due to semantic differences, and misjudgment of frequent device actions as hardware degradation, thereby improving the accuracy and efficiency of management and operation.

[0012] Furthermore, this application proposes a step for determining the probative value level of an event to be processed and the corresponding state coverage conditions based on the type of event source, including: Determine the semantic strength corresponding to the event source type; The event to be processed is assigned a corresponding proof capability level based on its semantic strength. The higher the semantic strength of the event source type, the higher the proof capability level. State coverage conditions are determined based on the proof capability level. These conditions restrict events with lower proof capability levels from covering the currently occupied state established by events with higher proof capability levels.

[0013] The above scheme further refines the methods for determining the proof capability level and state coverage conditions, thereby improving the accuracy and robustness of event handling.

[0014] Furthermore, this application also proposes that the step of generating a device control command containing a control source identifier and issuing it to the end-effector corresponding to the target physical space includes: When updating the current occupancy status of the target physical space based on the pending event and triggering the device control command, obtain the source context information of the pending event that triggered the update of the current occupancy status; Convert the source context information into control input interpretation bits; Add the control input interpretation bit as a control source identifier to the device control command; The device control command with the control source identifier is sent to the end execution unit.

[0015] The above solution provides specific methods for generating and attaching control source identifiers, offering crucial information for subsequent operation and maintenance diagnostics.

[0016] Furthermore, this application also proposes that the method further includes: Obtain anomaly diagnosis requests for the terminal execution unit from the operations and maintenance side; Based on the anomaly diagnosis request, read the control source identifier from the device control command that triggered the action of the end effector unit; When the control source identifier contains control input interpretation bits, it is determined that the action of the end-effector that triggered the abnormal diagnostic request is a normal response caused by the platform control policy, and the maintenance work order for the end-effector is blocked. When the control source identifier does not contain the control input interpretation bit, it is determined that the end effector has suffered hardware degradation, and a maintenance work order is generated for the end effector.

[0017] The above solution effectively distinguishes between normal actions caused by platform control and hardware degradation by using control source identification, reducing fake maintenance work orders and optimizing operation and maintenance efficiency.

[0018] Furthermore, this application also proposes that the status coverage conditions include the single evidence direct coverage condition and the multi-source evidence combination coverage condition; When the occurrence time of the pending event is later than the state update time, and the proof capability level of the pending event meets the state coverage condition corresponding to the current occupied state, the steps for updating the current occupied state of the target physical space based on the pending event include: When the probative value level of the event to be processed is the first preset level, and it is determined that the event to be processed meets the condition of direct coverage by a single piece of evidence, the current occupancy status of the target physical space is directly updated from the candidate status to the confirmed status based on the event to be processed. When the proof capability level of the event to be processed is lower than the first preset level, obtain the set of historical events for the target physical space within the preset time window; Based on the pending events and the set of historical events, determine whether the pre-configured evidence combination threshold rules are met. The evidence combination threshold rules include the required set of evidence types, the minimum number of occurrences of each evidence type, and the maximum time limit. When the evidence combination threshold rule is met, and the event to be processed is determined to meet the multi-source evidence combination coverage condition, the current occupancy status of the target physical space is updated from the candidate status to the confirmed status.

[0019] The above scheme introduces a single evidence and multi-source evidence combination coverage mechanism, making the judgment of state update more flexible and accurate, especially when dealing with events with low probative value.

[0020] Furthermore, this application also proposes that the steps for receiving pending events for a target physical space include: When a pending event of type mobile terminal heartbeat event is received, the unique device identifier corresponding to the pending event is extracted. Based on the device's unique identifier, add the events to be processed to the corresponding first sliding window; When the first sliding window meets the preset batch formation conditions, all pending events in the first sliding window are packaged into a candidate batch. Calculate the evaluation metrics for candidate batches, including arrival density, occurrence time span, and distribution characteristics of the deviation between arrival time and occurrence time; The evaluation results of the candidate batches are determined by judging whether they meet the preset self-consistency conditions based on the evaluation indicators.

[0021] The above solution effectively addresses the latency and time drift issues of mobile terminal heartbeat events through a sliding window and batch evaluation mechanism, thereby improving the reliability of event processing.

[0022] Furthermore, this application also proposes that the method further includes: When the evaluation result indicates that the self-consistency condition is not met, the candidate batch will be marked as a locked batch. All pending events in the locked batch are assigned to the weak evidence counting path. All pending events in the locked batch are prohibited from triggering the update operation of the current occupancy status of the target physical space. Only the weak evidence counter corresponding to the target physical space is updated using all pending events in the locked batch. When the evaluation result meets the self-consistency condition, update the continuous unlocked batch counter corresponding to the device's unique identifier; When the consecutive unlocked batch counter reaches the preset consecutive batch threshold, and there is a strong proof capability event within the preset time window that is consistent with the target physical space direction indicated by the candidate batch, the pending events in the candidate batch are allowed to participate in the update determination of the current occupancy status of the target physical space.

[0023] The above scheme further distinguishes the processing paths of self-consistent and non-self-consistent batches, avoids interference from unreliable events on state updates, and allows reliable events to participate in state updates, thereby improving system stability.

[0024] Furthermore, this application proposes that when the occurrence time of a pending event is earlier than the state update time, the pending event is recorded as historical evidence to maintain the current occupancy state of the target physical space. The steps include: When the occurrence time of the pending event is earlier than the status update time, the pending event is added to the evidence counter corresponding to the event source type to increase the count value of the evidence counter; During the period when the current occupancy status is confirmed, the count value is periodically decayed based on a pre-configured time decay window; The method also includes: When a pending event is received that occurs later than the status update time and has a proof capability level not lower than the second preset level, the count value is increased according to the pending event. Based on the accumulated count, the retention period of the target physical space in the confirmed state is extended by a first preset duration, wherein the total extended duration of the retention period does not exceed a second preset duration.

[0025] The above scheme introduces a historical evidence counting and time decay mechanism, and extends the state retention period based on accumulated evidence, effectively utilizing historical information, avoiding frequent state switching, and improving the stability of state judgment.

[0026] Furthermore, this application also proposes that the step of generating a device control command containing a control source identifier and issuing it to the end-effector corresponding to the target physical space includes: After generating device control commands containing control source identifiers, obtain the expected sequence of scheduling events in the target physical space within a preset look-ahead time window; Extract the expected occupancy status and scheduling priority of each scheduling event in the expected scheduling event sequence; The updated current occupancy status is compared with the expected occupancy status, and the proof capability level and scheduling priority of the pending event that triggered the update of the current occupancy status are also compared. When the updated current occupancy status conflicts with the expected occupancy status, and the scheduling priority is higher than the proof capability level, the device control command is intercepted. Calculate the time difference between the occurrence time of the event to be processed and the expected occurrence time of the scheduled event that will cause a mutual exclusion conflict; Based on the time difference, a degradation control command is generated and sent to the end execution unit with the control source identifier attached. At the same time, the current occupancy status of the target physical space is corrected to a restricted occupancy status.

[0027] The steps for generating degradation control instructions based on the time difference include: When the time difference is less than the preset response sunk cost time threshold, a static hold instruction is generated to maintain the current operating parameters of the end execution unit, and the static hold instruction is used as a degradation control instruction. When the time difference is greater than or equal to the sunk cost time threshold, extract the energy consumption response level parameter corresponding to the end execution unit; Remove the startup parameters from the intercepted device control commands that exceed the threshold corresponding to the energy consumption response level parameters, generate a partial wake-up command that retains the basic environment maintenance parameters, and use the partial wake-up command as a degradation control command.

[0028] The above scheme introduces a conflict comparison and degradation control mechanism with the expected scheduling event sequence, which effectively avoids conflicts between control commands and preset scheduling, and can intelligently adjust the control strategy according to the time difference, reducing energy waste and frequent equipment operation.

[0029] As can be seen from the above, the method and system for intelligent management and operation optimization of smart parks provided in this application record the current occupancy status and update time of the target physical space, receive events to be processed and obtain their source type and occurrence time, determine the proof capability level and status coverage conditions according to the source type, compare the event occurrence time with the status update time, record the event as historical evidence when the event occurrence time is earlier than the status update time and maintain the current status unchanged, update the current occupancy status and update the status update time when the event occurrence time is later than the status update time and the proof capability level meets the status coverage conditions, and generate a device control command containing a control source identifier and send it to the end execution unit. The control source identifier is used to distinguish between platform control actions and hardware degradation, thereby solving the problems of inconsistent time sequence of multi-source events, semantic differences leading to inaccurate space occupancy judgment, and frequent device actions being misjudged as hardware degradation, thus improving the accuracy and efficiency of management and operation. Attached Figure Description

[0030] Figure 1 This is a schematic diagram illustrating a method for intelligent management and operation optimization of a smart park, as provided in this application.

[0031] Figure 2 This application provides a schematic diagram of a smart park intelligent management and operation optimization system.

[0032] In the diagram: 210, Recording module; 220, Receiving module; 230, Determining module; 240, Comparison and judgment module. Detailed Implementation

[0033] The technical solutions of this application will now be clearly and completely described with reference to the accompanying drawings. Obviously, the described embodiments are merely some embodiments of this application, and not all embodiments. The components of this application described and shown in the accompanying drawings can generally be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely to illustrate selected embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0034] It should be noted that similar reference numerals and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures. Furthermore, in the description of this application, terms such as "first," "second," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0035] Reference Figure 1This application provides a method for intelligent management and operation optimization of a smart park, which specifically includes the following steps: S110. Record the current occupancy status of the target physical space and the status update time; The target physical space can be an independently manageable unit within the park, such as a meeting room, a corridor, an open office area, or a public rest area. For such spaces, a set of data records describing their current status is maintained on the management platform.

[0036] The current occupancy status is the basis for subsequent automated control. For example, the occupancy status determines whether to turn on the lights, start the air conditioner, or adjust the fresh air volume. The status update time records the moment when the current occupancy status was established by the last valid event.

[0037] In a specific implementation, the current occupancy state can be defined as a finite state machine, whose state set can contain at least four states: confirmed vacancy, candidate occupancy, confirmed occupancy, and candidate vacancy. For example, the initial state of a meeting room is confirmed vacancy. When the infrared sensor at the door is triggered, its state can transition to candidate occupancy. Subsequently, after the participants complete the check-in on the meeting panel, the state is further promoted to confirmed occupancy. This approach can more accurately describe the state evolution process.

[0038] S120. Receive pending events for the target physical space, and obtain the event source type and occurrence time of the pending events; The system continuously receives event streams from various subsystems. Whenever an event related to the target physical space arrives, two key pieces of information need to be extracted: the event source type and the occurrence time. The event source type indicates which subsystem or device generated the event, such as an access control card swipe event, a conference panel check-in event, an infrared sensor trigger event, or a location heartbeat event reported by a mobile terminal. The occurrence time is the timestamp carried by the event itself, recording the actual moment the event occurred on the front-end device.

[0039] S130. Determine the proof capability level of the event to be processed and the corresponding state coverage conditions based on the type of event source. This step aims to translate the semantic and credibility differences between various event sources into a set of enforceable rules, as not all events indicating attendance are equally persuasive. For example, a proactive meeting attendance check-in has a much higher degree of certainty and conviction in confirming space occupancy than an unintentional infrared trigger that might simply be a passing by. Therefore, a proof capability level needs to be pre-configured for each event source type, representing the strength of that type of event in proving that a space is stably occupied. Simultaneously, a set of state coverage conditions needs to be configured for each level, explicitly defining which existing space states can be covered or altered by events possessing that level of proof capability.

[0040] S140. Compare the occurrence time of the event to be processed with the state update time of the target physical space.

[0041] By comparing the occurrence time of the event to be processed with the current state update time of the target physical space, it can be determined whether the event represents the latest change in the spatial state or a historical record that is delayed due to network latency or device caching.

[0042] The first scenario is when the event to be processed occurs earlier than the state update time. In this case, the event is recorded as historical evidence, and the current occupancy state of the target physical space remains unchanged. This scenario means that the spatial state has already been updated based on a later, more credible event. This newly arrived event, which occurred earlier, regardless of its content, cannot overturn the established and updated understanding.

[0043] For example, a meeting room is confirmed as occupied at 9:05 AM by a meeting check-in event, and the status update time is recorded as 9:05 AM. Subsequently, at 9:06 AM, the platform receives a mobile terminal location heartbeat that occurred at 9:02 AM. Because this heartbeat occurred earlier than the status update time, the platform will treat it as historical data, using it only for recording and archiving, and will not use it to change the current occupancy status of the meeting room.

[0044] The second scenario involves updating the current occupancy state of the target physical space based on the pending event only when the event's occurrence time is later than the state update time, and the event's proof capability level meets the state coverage condition corresponding to the current occupancy state. In other words, it processes valid events that are both temporally new and sufficiently strong in proof capability. Meeting these two conditions means that the event truly reflects the latest changes in the spatial state, and its credibility is sufficient to cover the current state.

[0045] At this point, the current occupancy status of the space will be updated according to the content of the event, such as from confirmed empty to candidate occupied, or from candidate occupied to confirmed occupied. At the same time as updating the status, the status update time of the space will also be updated to the occurrence time of this triggering event, thereby establishing a new time anchor point for the next round of comparison.

[0046] When the occupancy status is successfully updated and an action needs to be triggered on the end device, such as turning on the air conditioner or lighting, a device control command containing a control source identifier will be generated and sent to the end execution unit corresponding to the target physical space.

[0047] This control source identifier can be a special data field attached to the control command. Its function is to provide the operation and maintenance end with an explanation of the device action. By parsing this identifier, it can be understood whether a device action is a normal response caused by the platform's occupancy status update policy, or an abnormal action that may indicate a hardware failure, which occurs without a clear control command. This method can effectively distinguish between device actions caused by platform control input and the device's own hardware degradation, thereby significantly reducing the generation of false maintenance work orders and allowing operation and maintenance personnel to focus on dealing with real device failures.

[0048] Through the above scheme, this application constructs a logical process for spatial status management and operation optimization. This logical process can effectively distinguish between short-term passing and stable occupancy, prevent delayed or batch-reported location events from directly covering the real-time status, ensure that occupancy determination converges to a reliable and stable state to reduce frequent control inputs to end devices, and provide an explanation of the control source for operation and maintenance judgments. Thus, while improving the level of automation in park operations, it significantly reduces unnecessary energy consumption and operation and maintenance costs.

[0049] Furthermore, the steps of determining the proof capability level of the event to be processed and the corresponding state coverage conditions based on the event source type may specifically include: First, determining the semantic strength corresponding to the event source type. Semantic strength is a predefined, quantified indicator used to measure the extent to which an event source can directly prove the stable occupancy of the space.

[0050] For example, a numerical range from 0 to 100 can be set. Events like meeting panel check-in, which have clear user intent and high determinism, could have a semantic strength of 95. Access control card swipes for entering a floor area could have a semantic strength of 70. Corridor infrared sensor trigger events, which may simply involve people passing by, could have a semantic strength of 30. Mobile terminal location heartbeat events, because they are easily affected by network and device status, might have a semantic strength set to only 10.

[0051] After determining the semantic strength, a corresponding level of probative value is assigned to the event to be processed based on the semantic strength. For example, a semantic strength of 90 or above can be defined as Level 1 probative value, representing strong evidence; 70 to 89 as Level 2 probative value, representing general evidence; 20 to 69 as Level 3 probative value, representing weak evidence; and below 20 as Level 4 probative value, representing corroborating evidence. Thus, the higher the semantic strength of the event source type, the higher its corresponding level of probative value.

[0052] State coverage conditions are determined based on the proof capability level. These conditions are a set of rules used to restrict events with lower proof capability levels from covering currently occupied states established by events with higher proof capability levels. For example, the following rules can be configured: Events with Level 1 probative power can cover any state. Events with Level 2 probative power cannot cover states established by Level 1 probative power events, but can cover states established by Level 2, 3, or 4 events. Events with Level 3 probative power can generally only advance the spatial state from confirmed vacancy to candidate occupancy, but cannot directly confirm occupancy, and cannot cover states established by higher-level evidence.

[0053] This coverage constraint ensures that state decisions are always dominated by higher-quality evidence, effectively preventing frequent state fluctuations and misjudgments.

[0054] In a specific embodiment, to implement the above logic, an event level configuration table can be maintained. This table can contain fields such as event type, semantic strength, proof capability level, and default coverage conditions. When the platform receives an event, it queries this table to obtain its corresponding level and coverage rules, and then performs subsequent state transition judgments based on these rules. By using a configuration table, all rules are clear, searchable, and adjustable, making it easy for operations personnel to optimize according to actual operational conditions without modifying the core code.

[0055] Furthermore, the step of generating a device control command containing a control source identifier and issuing it to the end execution unit corresponding to the target physical space can specifically include: when updating the current occupancy status of the target physical space according to the pending event and triggering the device control command, firstly, obtaining the source context information of the pending event that triggered this update of the current occupancy status. In addition to the source type of the event, the context information can also include the unique identifier that triggered the event, the probative value level of the event, whether it was triggered by the multi-source evidence combination rule, and can also include the upstream evidence density within a time window near the triggering time. That is, near the time point of this status update or device control triggering, statistically analyze the occurrence frequency or weighted occurrence frequency of the preceding evidence that is causally related to this triggering within a time window to reflect whether this triggering is caused by an isolated event or by multiple pieces of evidence supporting it in a short period of time.

[0056] After obtaining the source context information, this information is converted into a standardized control input interpretation bit. This control input interpretation bit can be a structured data format, such as a 32-bit integer or a bitmask, where different bits or fields represent different contextual meanings. For example, specific bits can be used to identify whether the event source is access control, meeting check-in, or infrared. Other bits are used to identify the capability level. A flag bit is then used to indicate whether the trigger was due to a high-frequency event within a short period.

[0057] The generated control input interpretation bits are used as a control source identifier and appended to the device control command to be issued. For example, a command sent to an air conditioning terminal controller, in addition to containing control parameters such as target temperature and fan speed, will also carry this control source identifier field.

[0058] The device control command, with an attached control source identifier, is sent through the control network to the corresponding end-effector in the target physical space. While executing the command, the end-effector also records the command and its associated control source identifier in its operation log.

[0059] Furthermore, in some embodiments, the method further includes, when an abnormal diagnosis request for a certain end execution unit is obtained at the operation and maintenance end, for example, the operation and maintenance monitoring module discovers that a certain wind turbine has started and stopped ten times in the past five minutes according to preset rules, exceeding the health threshold, thereby triggering a diagnosis request.

[0060] Based on the anomaly diagnosis request, read the device control command log that triggered the recent action of the end effector and extract the control source identifier from it.

[0061] When the control source identifier contains valid control input interpretation bits, it is determined that the action of the end-effector that triggered this abnormal diagnostic request is a normal response caused by the platform's control policy. For example, the parsed interpretation bits indicate that these ten start-stop cycles were caused by the platform issuing a series of dense commands to respond quickly when processing a high-frequency, dense stream of occupancy events. In this case, although the device is moving frequently, it is not a fault of the device itself. Therefore, the maintenance process will intercept the originally planned maintenance work order for this end-effector or automatically downgrade it to a low-priority observation record.

[0062] Conversely, if the control source identifier does not contain a control input interpretation bit, or if there is no control command corresponding to the abnormal device action in the command log, it will be determined that the end effector unit is likely to have experienced hardware degradation or internal failure, because the abnormal device action lacks a reasonable explanation from the platform side. In this case, the original fault diagnosis process will continue to be executed, and a maintenance work order for the end effector unit will be generated and dispatched to maintenance personnel for on-site inspection.

[0063] This mechanism can prevent maintenance personnel from being misled by false alarms, thereby improving maintenance efficiency and response speed to real faults.

[0064] Furthermore, the status coverage conditions can be specifically divided into two types: single evidence direct coverage conditions and multi-source evidence combination coverage conditions. These two conditions correspond to different scenarios for handling strong evidence and weak evidence, respectively.

[0065] When the occurrence time of the pending event is later than the state update time, and the proof capability level of the pending event meets the state coverage condition corresponding to the current occupied state, the steps for updating the current occupied state of the target physical space based on the pending event can be divided into the following two paths: The first approach is to update the current occupancy status of the target physical space from a candidate state to a confirmed state directly when the probative value of the event to be processed is at the first preset level (e.g., assessed as Level 1 probative value) and the event meets the direct coverage condition of a single piece of evidence. This direct coverage condition of a single piece of evidence is typically configured for events with clear semantics and extremely high credibility, such as meeting panel check-in. When such events occur, the platform can confirm the space status as occupied without waiting for corroborating evidence, thus ensuring a rapid response to these highly deterministic scenarios and promptly activating equipment such as air conditioning and lighting, improving the user experience.

[0066] The second approach is when the proof capability level of the event to be processed is lower than the first preset level, such as level two or three proof capability. In this case, the strength of a single event is insufficient to directly confirm occupancy. Firstly, it is necessary to obtain a set of historical events for the same target physical space within a preset time window. This preset time window can be configured according to the characteristics of the space; for example, it might be thirty seconds for a conference room and ten seconds for a corridor.

[0067] After obtaining the set of historical events, the system uses the current pending event and the set of historical events to jointly determine whether a pre-configured evidence combination threshold rule is met. This evidence combination threshold rule typically includes: the required set of evidence types, i.e., which types of events are required to confirm occupancy; the minimum number of occurrences for each type of evidence, i.e., how many times each type of event must occur; and a maximum time limit, i.e., within what time frame all these pieces of evidence must appear to be valid.

[0068] Specifically, based on the occurrence time of the event to be processed, a preset time window equal to the maximum time limit is traced back, and all historical events falling within the preset time window are captured to form a valid verification set. Subsequently, the matching degree between the event source types in the valid verification set and the required evidence type set is compared, and it must cover all key source types specified in the required evidence type set.

[0069] Finally, the independent occurrence count of each key source type in the valid verification set is counted, and the statistical values ​​are verified against the minimum occurrence count for each evidence type. Only when the time span does not exceed the limit, the required types are fully covered, and the occurrence frequency of each type reaches or exceeds the minimum occurrence count threshold, is the pre-configured evidence combination threshold rule finally determined to be met, thereby preventing sporadic weak interference signals from being incorrectly combined and amplified.

[0070] For example, for a conference room, the rule can be configured as follows: within 30 seconds, there must be at least one access control event with proof capability level 2, and at least two infrared trigger events at the conference room door with proof capability level 3.

[0071] When the arrival of the event to be processed results in its combination with the set of historical events exactly satisfying the above evidence combination threshold rule, and it is determined that the combination meets the multi-source evidence combination coverage condition, the current occupancy status of the target physical space will be updated from the candidate status to the confirmed status.

[0072] This approach sets a higher threshold for escalating weak evidence to a valid occupancy status, requiring a chain of evidence in both time and type to jointly confirm the occupancy status. This effectively avoids situations where a single, incidental weak piece of evidence, such as infrared sensors triggered by a person passing by, leads to a space being incorrectly identified as occupied for an extended period. Thus, while ensuring the reliability of occupancy determination, energy-saving requirements are also taken into account.

[0073] Furthermore, for special and high-risk event sources such as mobile terminal heartbeats, the steps for receiving pending events targeting a physical space may include: when a pending event of type mobile terminal heartbeat is received, firstly extracting the unique device identifier corresponding to the pending event. This identifier may be the device's media access control address or a unique device identification code generated by an application, used to aggregate events from the same terminal.

[0074] Based on the extracted unique device identifier, the newly arrived pending event is added to a first sliding window corresponding to that identifier. The first sliding window is used to aggregate a series of consecutive heartbeats from the same device in time.

[0075] As heartbeat events continue to arrive, when the first sliding window meets the preset batch formation conditions, such as the number of events in the first sliding window reaching a batch size threshold, or the arrival time difference between the earliest and latest events in the first sliding window exceeding the length of the first sliding window, all pending events in the first sliding window will be packaged into a candidate batch. At this point, the event has been upgraded from a single event to an event batch, thus forming a candidate batch.

[0076] Next, evaluation metrics are calculated for the formed candidate batches to determine the consistency and reliability of their internal data. Evaluation metrics include at least: arrival density (the total number of events in the batch divided by the difference between the earliest and latest arrival times within the batch), used to identify the presence of concentrated reporting; occurrence time span (the difference between the latest and earliest occurrence times of all event records within the batch), used to identify whether the batch contains historical cached data with a long time span; and the distribution characteristics of the deviation between arrival time and occurrence time, calculated by subtracting the occurrence time from the arrival time of each event within the batch, and analyzing the mean, standard deviation, and distribution of these delay values ​​to identify the presence of timestamp drift or unstable network latency.

[0077] The process of determining whether a candidate batch meets the preset self-consistency conditions based on evaluation indicators. For the arrival density indicator, a maximum tolerance density threshold is set. When the calculated arrival density is higher than the maximum tolerance density threshold, it indicates that excessive data has flooded in within a very short period of time.

[0078] For the time span indicator, a span tolerance upper limit is set. When the span exceeds the span tolerance upper limit, it indicates that this batch of data has spanned too long a historical period.

[0079] Based on the distribution characteristics of the deviation between arrival time and occurrence time, the standard deviation and skewness coefficient of the deviation values ​​are extracted. When the standard deviation exceeds the preset divergence threshold, or the absolute value of the skewness coefficient is greater than the preset skewness limit, it indicates that the delay fluctuation of this batch of data is severe and does not conform to the stable distribution characteristics of conventional network transmission.

[0080] In the specific execution of the judgment, as long as any of the above arrival density, occurrence time span or deviation distribution characteristics exceeds the corresponding threshold boundary, the candidate batch is immediately determined to be not to meet the preset self-consistency condition, thereby effectively identifying the data distortion phenomenon caused by centralized reporting after the equipment goes into hibernation.

[0081] Finally, based on the calculated evaluation indicators, it is determined whether the candidate batch meets the preset self-consistency conditions, so as to determine the final evaluation result of the candidate batch.

[0082] After evaluating candidate batches, the method further includes marking a candidate batch as a locked batch when the evaluation result does not meet the self-consistency condition. Once marked as locked, all pending events within that batch are uniformly assigned to a weak evidence counting path. This means that these events are prohibited from triggering any update operations on the current occupancy state of the target physical space, especially from triggering promotion from a candidate state to a confirmed state. These events are used to update a weak evidence counter corresponding to the target physical space. This counter can be used in other scenarios, such as extending the holding time of a confirmed state, but it cannot play a dominant role in critical decisions regarding state reversal.

[0083] When the evaluation result meets the self-consistency condition, it indicates that the data of that batch is relatively reliable at present. At this time, the counter for consecutive unlocked batches corresponding to the device's unique identifier will be updated by incrementing its count by one.

[0084] However, the consistency of a single batch is insufficient to fully trust the data from the mobile terminal. Therefore, only when the cumulative count of this continuous unlocked batch reaches a preset continuous batch threshold, such as three consecutive batches passing the consistency check, and within the most recent preset time window, there exists a strong proof-of-concept event consistent with the target physical space direction indicated by the candidate batch, such as a card swipe or meeting attendance record pointing to the same meeting room, will the pending events in the candidate batch be ultimately allowed to participate in the update determination process of the current occupancy status of the target physical space.

[0085] This multi-gating mechanism, which combines batch locking, continuous verification, and strong evidence collaboration, raises the threshold for accepting mobile terminal heartbeat events. It ensures that only when the data exhibits continuous stability and reliability can the risk of misjudgment be suppressed by the time conversion drift caused by mobile terminal sleep and the delay stratification caused by network congestion.

[0086] Furthermore, for pending events that are determined to have occurred earlier than the status update time during the time comparison process, the step of recording these events as historical evidence and maintaining their current occupancy status can specifically include: when the occurrence time of a pending event is earlier than the status update time, adding the pending event to an evidence counter corresponding to the event source type to increase the count value of the evidence counter. For example, the platform can maintain an infrared trigger counter and an access control entry counter for each space.

[0087] While the current occupancy status of the space is confirmed, to reflect the timeliness of the evidence, the count values ​​of these evidence counters are periodically decayed based on a pre-configured time decay window. For example, every minute, the value of all counters is automatically reduced by 10%. This ensures that the counter values ​​primarily reflect the intensity of recent activity, avoiding the continued impact of distant historical events on the current state.

[0088] The method also includes incrementing the corresponding evidence counter value based on the received event when it occurs later than the state update time and has a proof capability level of not less than a second preset level, such as level two or above. This means that new, valid, and highly credible evidence will also strengthen the evidence strength of space occupancy.

[0089] Finally, based on the accumulated and dynamically decaying counts of these evidence counters, the period for maintaining the confirmed status of the target physical space can be extended by thirty seconds for a first preset duration, for example, whenever the count reaches a certain threshold.

[0090] The purpose of this mechanism is that once a space is confirmed to be occupied, even if no new strong evidence emerges in a short period, but if weak evidence or historical evidence indicates that the space still shows signs of activity, the determination process can appropriately extend its occupancy status. This avoids frequent start-stop cycles caused by premature shutdowns and immediate restarts due to temporary scarcity of evidence. To prevent spaces from being locked indefinitely in an occupied state due to continuous noise or false alarms, a cap is set on the total cumulative extension period, which cannot exceed a second preset duration, for example, the total extension cannot exceed five minutes.

[0091] Furthermore, before generating and issuing device control commands containing the control source identifier, a conflict coordination mechanism with the predetermined scheduling plan can be introduced. The specific steps include: after generating the device control commands containing the control source identifier, first obtaining the expected sequence of scheduling events for the target physical space within a preset forward-looking time window, such as the next fifteen minutes. This sequence typically comes from the meeting booking system or the building automation system's timing strategy and contains information on how the space is planned to be used in the future.

[0092] Next, the expected occupancy status and scheduling priority of each scheduling event in the expected scheduling event sequence are extracted. For example, the sequence may include a high-priority board meeting starting at 10:00 AM, whose expected occupancy status is occupied.

[0093] Then, the current occupancy state, updated by the pending event, is compared with the expected occupancy state. Simultaneously, the proof capability level of the pending event that triggered this update of the current occupancy state is compared with the scheduling priority of the scheduling event that caused the conflict.

[0094] When there is a mutual exclusion conflict between the updated current occupancy status and the expected occupancy status—for example, a real-time event updates the space to occupied, but the scheduling plan requires the space to remain vacant for cleaning after a few minutes, and the priority of the scheduling event is higher than the proof capability level that triggered the real-time update event—then the originally scheduled device control commands will be intercepted. This step ensures that high-priority scheduled plans are not interfered with by low-confidence real-time events.

[0095] After intercepting the command, the time difference between the occurrence time of the current pending event and the expected occurrence time of the scheduling event that caused the mutual exclusion conflict is calculated. Based on this time difference, a degradation control command is generated and sent to the end execution unit with the control source identifier attached. At the same time, in order to reflect this special state internally, the current occupancy state of the target physical space is corrected to a restricted occupancy state.

[0096] The specific rules for eliminating and retaining degradation control commands based on the time difference rely on a refined breakdown of the energy consumption response level parameters of the end-effector. These parameters incorporate a multi-dimensional equipment operation specification mapping table, which categorizes equipment operating states into different energy levels. When the time difference is greater than or equal to the sunk cost time threshold, it means there is still a sufficient buffer period before the expected high-priority event occurs.

[0097] At this point, all control parameters in the original equipment control command are extracted and compared one by one with the high energy consumption trigger threshold in the energy consumption response level parameters. For starting parameters that exceed the high energy consumption trigger threshold, such as starting the core compressor, turning on the high-power heating resistor, or increasing the fan speed to the highest level, a rejection operation is performed.

[0098] At the same time, parameters for maintaining the basic environmental baseline of the space are extracted from the mapping table, such as maintaining the minimum fresh air exchange rate and turning on the extremely low brightness guide lighting. These basic environmental maintenance parameters are recombined and then encapsulated to generate some wake-up instructions. This elimination and retention mechanism can avoid the equipment from running at full power and preheat the environment at low cost in advance for the upcoming high-priority occupancy events.

[0099] The step of generating degradation control instructions based on time difference can be further divided into two cases: When the calculated time difference is less than a preset response sunk cost time threshold, such as less than three minutes, it means that the scheduling event is about to occur. At this time, starting any high-energy-consuming equipment would be counterproductive. Therefore, a static hold instruction to maintain the current operating parameters of the end execution unit will be generated, such as keeping the current ventilation status unchanged. This static hold instruction will be issued as a degradation control instruction.

[0100] When the time difference is greater than or equal to the sunk cost response time threshold, for example, there are still eight minutes until the scheduled meeting time. This means there is some room for preparation, but full power operation is not necessary. In this case, the energy consumption response level parameters corresponding to the end-effector are extracted. These parameters define the operating specifications of the equipment at different energy-saving levels. Then, startup parameters that exceed the threshold corresponding to the energy consumption response level parameters in the intercepted original equipment control commands are removed. For example, parameters that start the main compressor or adjust the lighting to 100% brightness are removed. This generates a partial wake-up command that retains only the basic environmental maintenance parameters, such as turning on the fresh air only or adjusting the lighting to 30%. This partial wake-up command is then issued as a degraded control command.

[0101] This cost-sensitive degradation control strategy enables a flexible and energy-efficient response to real-time occupancy demands while adhering to predetermined plans.

[0102] Secondly, referring to Figure 2 This application also proposes a system for intelligent management and operation optimization of smart parks, including: The recording module 210 is used to record the current occupancy status of the target physical space and the status update time; The receiving module 220 is used to receive events to be processed for the target physical space and obtain the event source type and occurrence time of the events to be processed. The determination module 230 is used to determine the proof capability level of the event to be processed and the corresponding state coverage conditions based on the event source type. The comparison and judgment module is used to compare the occurrence time of the event to be processed with the state update time of the target physical space; When the occurrence time of the pending event is earlier than the state update time, the pending event is recorded as historical evidence, and the current occupancy state of the target physical space remains unchanged. When the occurrence time of the pending event is later than the state update time, and the proof capability level of the pending event meets the state coverage condition corresponding to the current occupancy state, the current occupancy state of the target physical space is updated according to the pending event, the state update time is updated to the occurrence time of the pending event, and a device control command containing a control source identifier is generated and sent to the end execution unit corresponding to the target physical space. The control source identifier is used to distinguish between device actions caused by the current occupancy state update and the hardware degradation of the end execution unit itself at the operation and maintenance end.

[0103] By recording the current occupancy status and update time of the target physical space, receiving pending events and obtaining their source type and occurrence time, determining the proof capability level and status coverage conditions based on the source type, comparing the event occurrence time with the status update time, recording the event as historical evidence and maintaining the current state unchanged when the event occurrence time is earlier than the status update time, and updating the current occupancy status and status update time when the proof capability level meets the status coverage conditions when the event occurrence time is later than the status update time, and generating a device control command containing a control source identifier to be sent to the end execution unit. This control source identifier is used to distinguish between platform control actions and hardware degradation, thereby solving the problems of inconsistent time sequences of multi-source events, semantic differences leading to inaccurate space occupancy judgments, and frequent device actions being misjudged as hardware degradation, thus improving the accuracy and efficiency of management and operation.

[0104] Furthermore, in some preferred embodiments, the smart park intelligent management and operation optimization system proposed in this application can perform any one of the steps in the above methods.

[0105] The above description is merely an embodiment of this application and is not intended to limit the scope of protection of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application.

Claims

1. A method for intelligent management and operation optimization of a smart park, characterized in that, include: Record the current occupancy status of the target physical space and the status update time; Receive pending events for the target physical space, and obtain the event source type and occurrence time of the pending events; The proof capability level of the event to be processed and the corresponding state coverage conditions are determined based on the event source type. The occurrence time of the event to be processed is compared with the state update time of the target physical space; When the occurrence time of the pending event is earlier than the state update time, the pending event is recorded as historical evidence, and the current occupancy state of the target physical space remains unchanged. When the occurrence time of the pending event is later than the state update time, and the proof capability level of the pending event meets the state coverage condition corresponding to the current occupancy state, the current occupancy state of the target physical space is updated according to the pending event, the state update time is updated to the occurrence time of the pending event, and a device control command containing a control source identifier is generated and sent to the end execution unit corresponding to the target physical space. The control source identifier is used to distinguish between the device action caused by the current occupancy state update and the hardware degradation of the end execution unit itself at the operation and maintenance end.

2. The method for intelligent management and operation optimization of a smart park according to claim 1, characterized in that, The step of determining the proof capability level of the event to be processed and the corresponding state coverage condition based on the event source type includes: Determine the semantic strength corresponding to the event source type; The event to be processed is assigned a corresponding proof capability level based on the semantic strength, and the higher the semantic strength of the event source type, the higher the proof capability level. The state coverage condition is determined based on the proof capability level, and the state coverage condition is used to restrict events with low proof capability levels from covering the current occupied state established by events with high proof capability levels.

3. The method for intelligent management and operation optimization of a smart park according to claim 1, characterized in that, The step of generating a device control command containing a control source identifier and sending it to the end-effector corresponding to the target physical space includes: When updating the current occupancy status of the target physical space based on the pending event and triggering a device control command, the source context information of the pending event that caused the update of the current occupancy status is obtained; Convert the source context information into control input interpretation bits; The control input interpretation bit is appended to the device control command as the control source identifier; The device control command, which includes the control source identifier, is sent to the end-effector.

4. The method for intelligent management and operation optimization of a smart park according to claim 3, characterized in that, The method also includes: Obtain an anomaly diagnosis request for the terminal execution unit from the operation and maintenance side; Based on the anomaly diagnosis request, read the control source identifier from the device control command that triggered the action of the end execution unit; When the control source identifier contains the control input interpretation bit, it is determined that the end-effector action that triggered the abnormal diagnosis request is a normal response caused by the platform control policy, and the maintenance work order for the end-effector is blocked. When the control source identifier does not contain the control input interpretation bit, it is determined that the end effector has experienced hardware degradation, and a maintenance work order is generated for the end effector.

5. The method for intelligent management and operation optimization of a smart park according to claim 1, characterized in that, The state coverage conditions include single evidence direct coverage conditions and multi-source evidence combination coverage conditions; The step of updating the current occupancy state of the target physical space according to the pending event when the occurrence time of the pending event is later than the state update time, and the proof capability level of the pending event satisfies the state coverage condition corresponding to the current occupancy state, includes: When the proof capability level of the event to be processed is the first preset level, and it is determined that the event to be processed meets the single evidence direct coverage condition, the current occupancy status of the target physical space is directly updated from the candidate status to the confirmed status according to the event to be processed. When the proof capability level of the event to be processed is lower than the first preset level, obtain the set of historical events for the target physical space within a preset time window; Based on the pending event and the set of historical events, determine whether the pre-configured evidence combination threshold rule is met. The evidence combination threshold rule includes the required set of evidence types, the minimum number of occurrences of each evidence type, and the maximum time limit. When the evidence combination threshold rule is met, and the event to be processed is determined to meet the multi-source evidence combination coverage condition, the current occupancy status of the target physical space is updated from the candidate status to the confirmed status.

6. The method for intelligent management and operation optimization of a smart park according to claim 1, characterized in that, The step of receiving pending events for the target physical space includes: When a pending event of type mobile terminal heartbeat event is received, the device unique identifier corresponding to the pending event is extracted. Based on the device's unique identifier, the event to be processed is added to the corresponding first sliding window; When the first sliding window meets the preset batch formation conditions, all the events to be processed in the first sliding window are packaged into a candidate batch. Calculate the evaluation indicators for the candidate batches, including arrival density, occurrence time span, and distribution characteristics of the deviation between arrival time and occurrence time; The evaluation results of the candidate batch are determined by judging whether the candidate batch meets the preset self-consistency conditions based on the evaluation indicators.

7. The method for intelligent management and operation optimization of a smart park according to claim 6, characterized in that, The method also includes: When the evaluation result indicates that the self-consistency condition is not met, the candidate batch is marked as a locked batch; All pending events in the locked batch are assigned to the weak evidence counting path, all pending events in the locked batch are prohibited from triggering the update operation of the current occupancy status of the target physical space, and only all pending events in the locked batch are used to update the weak evidence counter corresponding to the target physical space; When the evaluation result satisfies the self-consistency condition, update the continuous unlocked batch counter corresponding to the device unique identifier; When the continuous unlocked batch counter reaches a preset continuous batch threshold, and a strong proof capability event that is consistent with the target physical space direction indicated by the candidate batch exists within a preset time window, the pending event in the candidate batch is allowed to participate in the update determination of the current occupancy status of the target physical space.

8. The method for intelligent management and operation optimization of a smart park according to claim 1, characterized in that, The step of recording the pending event as historical evidence and maintaining the current occupancy state of the target physical space unchanged when the occurrence time of the pending event is earlier than the state update time includes: When the occurrence time of the pending event is earlier than the state update time, the pending event is added to the evidence counter corresponding to the event source type to increase the count value of the evidence counter. During the period when the current occupancy status is confirmed, the count value is periodically decayed based on a pre-configured time decay window; The method also includes: When a pending event is received that occurs later than the state update time and the proof capability level is not lower than the second preset level, the count value is increased according to the pending event. Based on the accumulated count value, the retention period for maintaining the confirmed state in the target physical space is extended by a first preset duration, wherein the total extended duration of the retention period does not exceed a second preset duration.

9. The method for intelligent management and operation optimization of a smart park according to claim 1, characterized in that, The step of generating a device control command containing a control source identifier and sending it to the end-effector corresponding to the target physical space includes: After generating the device control command containing the control source identifier, the expected scheduling event sequence of the target physical space within a preset look-ahead time window is obtained; Extract the expected occupancy status and scheduling priority of each scheduling event in the expected scheduling event sequence; The updated current occupancy status is compared with the expected occupancy status, and the proof capability level and scheduling priority of the pending event that triggered the update of the current occupancy status are compared. When the updated current occupancy status conflicts with the expected occupancy status, and the scheduling priority is higher than the proof capability level, the device control command is intercepted. Calculate the time difference between the occurrence time of the event to be processed and the expected occurrence time of the scheduling event that caused the mutual exclusion conflict; A degradation control instruction is generated based on the time difference, and the degradation control instruction with the control source identifier is sent to the end execution unit. At the same time, the current occupancy status of the target physical space is corrected to a restricted occupancy status. The step of generating a degradation control command based on the time difference includes: When the time difference is less than the preset response sunk cost time threshold, a static hold instruction is generated to maintain the current operating parameters of the end execution unit, and the static hold instruction is used as the degradation control instruction. When the time difference is greater than or equal to the response sunk cost time threshold, extract the energy consumption response level parameter corresponding to the end execution unit; Remove the startup parameters from the intercepted device control commands that exceed the threshold corresponding to the energy consumption response level parameter, generate a partial wake-up command that retains the basic environment maintenance parameters, and use the partial wake-up command as the degradation control command.

10. A system for intelligent management and operation optimization of a smart park, used to perform the method according to any one of claims 1 to 9, characterized in that, include: The recording module is used to record the current occupancy status of the target physical space and the status update time; The receiving module is used to receive events to be processed for the target physical space and to obtain the event source type and occurrence time of the events to be processed. The determination module is used to determine the proof capability level of the event to be processed and the corresponding state coverage conditions based on the event source type. The comparison and judgment module is used to compare the occurrence time of the event to be processed with the state update time of the target physical space; When the occurrence time of the pending event is earlier than the state update time, the pending event is recorded as historical evidence, and the current occupancy state of the target physical space remains unchanged. When the occurrence time of the pending event is later than the state update time, and the proof capability level of the pending event meets the state coverage condition corresponding to the current occupancy state, the current occupancy state of the target physical space is updated according to the pending event, the state update time is updated to the occurrence time of the pending event, and a device control command containing a control source identifier is generated and sent to the end execution unit corresponding to the target physical space. The control source identifier is used to distinguish between the device action caused by the current occupancy state update and the hardware degradation of the end execution unit itself at the operation and maintenance end.

Images