BIM-based building equipment monitoring system cross-platform integration docking method

Abstract

The application relates to the technical field of monitoring systems, in particular to a building equipment monitoring system cross-platform integration docking method based on BIM, which is realized based on a cross-platform integration docking system and is characterized by the following steps: analyzing a building information model, extracting a building equipment object and a spatial topological relation thereof, and generating an equipment semantic graph model; based on the generated equipment semantic graph model, performing semantic labeling on private protocol data points of each subsystem accessed, and constructing a protocol-independent equipment semantic instantiation graph; based on the equipment semantic graph model and the equipment semantic instantiation graph, constructing a cross-protocol semantic mapping table, and generating a bidirectional conversion script. The application has the characteristics of high cross-protocol semantic fidelity, strong linkage strategy space perception capability, and significantly improved system self-healing and anti-configuration drift capability, and is suitable for high-reliability cross-platform integration docking scenes of multiple heterogeneous subsystems such as heating ventilation air conditioning, fire fighting, security and lighting in a building equipment monitoring system.

Description

Technical Field

[0001] This invention relates to the field of monitoring system technology, specifically a cross-platform integration and docking method for BIM-based building equipment monitoring systems. Background Technology

[0002] Building equipment monitoring systems typically encompass multiple subsystems, including HVAC, water supply and drainage, power supply and distribution, lighting, fire protection, and security. These subsystems are provided by different vendors and use their own proprietary communication protocols and data models. In actual projects, to achieve cross-subsystem linkage and centralized monitoring, integrators often employ a solution of protocol conversion gateways plus a standard bus, or rely on OPCDA servers for data relay, or directly achieve point-to-point transmission of critical signals through hardware dry contacts.

[0003] However, existing solutions generally suffer from the following prominent drawbacks: Protocol conversion gateways can only perform point-to-point mapping of data registers, converting proprietary protocol data into point tables of standard protocols such as Modbus or BACnet. During the conversion process, the physical semantics, functional attributes, and spatial location information of the device data are completely lost, resulting in the upper-layer platform only being able to obtain meaningless numerical sequences and being unable to understand the meaning of the device's operating status represented by the data; Existing integration methods heavily rely on manual configuration, requiring engineers to verify the correspondence between proprietary protocol addresses and standard point tables point by point. Mapping tens of thousands of data points is time-consuming and error-prone. Once the gateway fails or the configuration is lost, restoring the mapping relationship is as difficult as re-debugging; Existing linkage rules are configured using a static hard-coded method, and the linkage logic is disconnected from the physical location and spatial topology of the devices. It is impossible to perform fine-grained collaborative control based on dynamic conditions such as the spatial region and functional group to which the devices belong. Adjusting the linkage strategy requires modifying the underlying code, resulting in poor flexibility; Furthermore, there is a lack of a closed-loop verification mechanism for the validity of the mapping link. When field devices are replaced, communication parameters are changed, or points are reassigned, the mapping relationship becomes invalid without the system's knowledge, and the system runs on erroneous data for a long time, creating a maintenance black hole.

[0004] Based on this, the present invention provides a cross-platform integration and docking method for a BIM-based building equipment monitoring system to solve the aforementioned technical problems. Summary of the Invention

[0005] The purpose of this invention is to provide a cross-platform integration and docking method for a BIM-based building equipment monitoring system, thereby solving the problems mentioned in the background.

[0006] To achieve the above objectives, the present invention provides the following technical solution: This invention proposes a cross-platform integration and docking method for a BIM-based building equipment monitoring system. The method, implemented using a cross-platform integration and docking system, includes the following steps: S1. Parse the building information model, extract building equipment objects and their spatial topological relationships, and generate a semantic graph model of the equipment; S2. Based on the device semantic graph model generated in S1, semantic annotation is performed on the private protocol data points of each access subsystem to construct a protocol-independent device semantic instantiation graph; S3. Based on the device semantic graph model of S1 and the device semantic instantiation graph of S2, construct a cross-protocol semantic mapping table and generate a bidirectional conversion script. The bidirectional conversion script includes mapping rules between private protocol addresses and unified semantic identifiers and data format conversion functions. S4. Load the bidirectional conversion script generated in S3 onto the edge protocol conversion node, parse the data packets of each subsystem in real time, and output a unified semantic event stream; S5. Based on the unified semantic event stream of S4 and the spatial topology relationship in S1, the linkage decision engine generates device linkage control instructions according to the condition-action rule matrix, and converts the device linkage control instructions into the private protocol control messages of the target subsystem through the bidirectional conversion script of S3. S6. Based on the execution status feedback of the monitoring equipment linkage control commands from S1 to S5, calculate the deviation between the feedback signal and the expected status signal. When the deviation meets the preset conditions, trigger the adaptive update of the device semantic instantiation graph and the cross-protocol semantic mapping table.

[0007] Preferably, the implementation process of step S1 is as follows: S1.1. Extract entities from the building information model, identify the IfcBuildingElement subclass and IfcDistributionElement instance in the IFC, and obtain the equipment entities; S1.2. Extract the spatial relationships between device entities, including inclusion relationships, adjacency relationships, and port connection relationships, and construct a device graph with device entities as nodes and spatial relationships as edges; S1.3. Attach a static attribute set to each node in the device diagram. The static attribute set includes device type, functional classification and design parameters to form a device semantic graph model.

[0008] Preferably, the implementation process of step S2 is as follows: S2.1. Obtain the list of data points and private protocol addresses exposed by each subsystem controller through protocol probing; S2.2. In the device semantic instantiation graph, associate the private protocol addresses in the data point list with the device nodes in the device semantic graph model of S1. to determine the building device object corresponding to each data point; S2.3. Semantically label each data point and assign a unified semantic identifier. The unified semantic identifier adopts a hierarchical naming rule and includes the device function type, attribute type and instance number. Generate a protocol-independent device semantic instantiation graph, in which the nodes are unified semantic identifiers and the edges are the spatial connection relationships extracted in S1.

[0009] Preferably, the implementation process of step S3 is as follows: S3.1. For each subsystem, iterate through its data points and create a one-way mapping record from private protocol address to unified semantic identifier; S3.2. Based on the spatial connection relationship between nodes in the device semantic instantiation graph in S2, establish a reverse mapping record from the unified semantic identifier to the private protocol address of other subsystems to form a mapping tuple; S3.3. Automatically match data format conversion functions according to data point type, and generate bidirectional conversion scripts containing read and write operations. The read operation converts private protocol values ​​into unified semantic event values, and the write operation converts unified control commands into private protocol messages.

[0010] Preferably, the implementation process of step S4 is as follows: S4.1. Load the bidirectional conversion script generated by S3 in the edge protocol conversion node and initialize the protocol listening session; S4.2. Real-time capture of data packets on the communication bus of each subsystem, look up the mapping table based on the address field in the packet, apply the read conversion function to extract the value and attach a timestamp and unified semantic identifier to form a semantic event; S4.3. Push semantic events to the stream processing window of the linkage decision engine and persist them to the event log storage module.

[0011] Preferably, the implementation process of step S5 is as follows: S5.1. The linkage decision engine receives the unified semantic event stream and extracts the event type, event value, and unified semantic identifier of the source device; S5.2. Based on the unified semantic identifier of the source device, retrieve spatial topology-related devices in the device semantic graph model of S1 to form a candidate set of affected devices; S5.3. Match the event type with the executable actions of the devices in the candidate set of affected devices. The condition-action rule matrix stores the correspondence between the triggering conditions and the target actions in advance. When a match is found, a unified control command for the target device is generated. S5.4. Call the write operation function in the bidirectional conversion script of S3 to convert the unified control command of the target device into the private protocol control message of the target subsystem, and distribute it through the edge protocol conversion node.

[0012] Preferably, the implementation process of step S6 is as follows: S6.1. After the target subsystem sends the private protocol control message, capture the target device's response message or periodically read the status data point through the protocol listening session of S4 to obtain the actual status value; S6.2. Compare the actual state value with the expected state value generated in S5, and calculate the normalization deviation; S6.3. When the normalization deviation of N consecutive samples exceeds the preset tolerance, it is determined that the mapping link has failed and the update process is triggered. N is an integer greater than or equal to 3. The S6.4 update process first isolates the failed link, then re-executes S2.2 and S2.3 to re-label the data points of the corresponding devices, and incrementally updates the cross-protocol semantic mapping table and bidirectional conversion script in S3.

[0013] This invention also proposes a cross-platform integration and interoperability system for a BIM-based building equipment monitoring system, the system comprising: BIM model parsing module, which uses BIM file parser to execute the equipment semantic map model construction step in step S1; The semantic annotation module is used to execute the protocol-independent device semantic instantiation graph construction step in step S2 through the point table import interface and the semantic annotation engine. A mapping table generation module, which uses a script compiler to execute the bidirectional conversion script generation step in step S3; An edge protocol conversion module, which is used to execute the unified semantic event stream output step in step S4 through a multi-protocol communication interface and script runtime; The linkage decision module uses a rule engine to execute the linkage control instruction generation and conversion steps in step S5.

[0014] Preferably, the system further includes: An adaptive update module is used to execute the adaptive update step in step S6 through a deviation detector and a mapping update engine.

[0015] Preferably, the system further includes: The event log storage module uses a time-series database to perform the semantic event persistence step in step S4; The rule configuration interface module is used to configure the condition-action rule matrix through a visual management interface.

[0016] Compared with the prior art, the beneficial effects of the present invention are: This invention utilizes a BIM model parsing engine to extract entities and construct spatial relationships from a building information model (BIM), generating a device semantic graph model that includes equipment types, functional classifications, design parameters, and spatial topology. This transforms static building design information into a machine-understandable device knowledge graph. It acquires private protocol data points from each subsystem through protocol detection and automatically associates these data points with nodes in the device semantic graph model, assigning unified semantic identifiers using hierarchical naming rules. This constructs a protocol-independent device semantic instantiation graph, eliminating semantic gaps between heterogeneous protocols and ensuring the complete preservation of the physical meaning of the data. By traversing the semantic instantiation graph, it generates bidirectional conversion scripts containing forward and reverse mappings. Read operations convert private protocol values ​​into unified semantic event values, and write operations convert unified control commands into private protocol messages, enabling automated compilation and hot loading of cross-system data read / write paths. Edge protocol conversion nodes parse data messages from each subsystem in real time and output unified semantic event streams, linking with the decision engine. This invention retrieves a candidate set of affected devices based on event flow and spatial topology relationships, generates unified control commands for target devices according to a condition-action rule matrix, and converts them into private protocol control messages for the target subsystems via a bidirectional conversion script. This enables precise, spatially-aware collaborative linkage between multiple subsystems, avoiding disconnection between linkage logic and physical location. By monitoring the execution status feedback of device linkage control commands, the normalized deviation between the feedback signal and the expected status signal is calculated. When the deviation continuously exceeds the limit, a mapping link failure isolation is triggered, and the device association and semantic annotation process is adaptively re-executed. The cross-protocol semantic mapping table and bidirectional conversion script are incrementally updated, and the mapping link automatically performs closed-loop verification and self-repair, eliminating the black hole of manual operation and maintenance. In summary, this invention features high cross-protocol semantic fidelity, strong spatial awareness of linkage strategies, and significantly improved system self-healing and anti-configuration drift capabilities. It is suitable for highly reliable cross-platform integration and docking scenarios of multiple heterogeneous subsystems such as HVAC, fire protection, security, and lighting in building equipment monitoring systems. Attached Figure Description

[0017] Figure 1 This is a flowchart of the cross-platform integration and docking method for the BIM-based building equipment monitoring system of the present invention. Detailed Implementation

[0018] The technical solutions of the present invention will be clearly and completely described below with reference to the embodiments of the present invention. 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 of ordinary skill in the art without creative effort are within the scope of protection of the present invention.

[0019] Example 1, please refer to Figure 1This invention proposes a cross-platform integration and docking method for a BIM-based building equipment monitoring system. The method is implemented based on a cross-platform integration and docking system, which includes: BIM model parsing module, which uses BIM file parser to execute the equipment semantic map model construction step in step S1; The semantic annotation module is used to execute the protocol-independent device semantic instantiation graph construction step in step S2 through the point table import interface and the semantic annotation engine. A mapping table generation module, which uses a script compiler to execute the bidirectional conversion script generation step in step S3; An edge protocol conversion module, which is used to execute the unified semantic event stream output step in step S4 through a multi-protocol communication interface and script runtime; The linkage decision module uses a rule engine to execute the linkage control instruction generation and conversion steps in step S5.

[0020] It should also be noted that the system also includes: An adaptive update module is used to execute the adaptive update step in step S6 through a deviation detector and a mapping update engine.

[0021] It should also be noted that the system also includes: The event log storage module uses a time-series database to perform the semantic event persistence step in step S4; The rule configuration interface module is used to configure the condition-action rule matrix through a visual management interface.

[0022] Based on the system, the method of the present invention includes the following steps: S1. Parse the building information model, extract building equipment objects and their spatial topological relationships, and generate a semantic graph model of the equipment; It should also be noted that the implementation process of step S1 is as follows: S1.1. Extract entities from the building information model, identify the IfcBuildingElement subclass and IfcDistributionElement instance in the IFC, and obtain the equipment entities; S1.2. Extract the spatial relationships between device entities, including inclusion relationships, adjacency relationships, and port connection relationships, and construct a device graph with device entities as nodes and spatial relationships as edges; S1.3. Attach a static attribute set to each node in the device diagram. The static attribute set includes device type, functional classification and design parameters to form a device semantic graph model.

[0023] S2. Based on the device semantic graph model generated in S1, semantic annotation is performed on the private protocol data points of each access subsystem to construct a protocol-independent device semantic instantiation graph; It should also be noted that the implementation process of step S2 is as follows: S2.1. Obtain the list of data points and private protocol addresses exposed by each subsystem controller through protocol probing; S2.2. In the device semantic instantiation graph, associate the private protocol addresses in the data point list with the device nodes in the device semantic graph model of S1. to determine the building device object corresponding to each data point; S2.3. Semantically label each data point and assign a unified semantic identifier. The unified semantic identifier adopts a hierarchical naming rule and includes the device function type, attribute type and instance number. Generate a protocol-independent device semantic instantiation graph, in which the nodes are unified semantic identifiers and the edges are the spatial connection relationships extracted in S1.

[0024] S3. Based on the device semantic graph model of S1 and the device semantic instantiation graph of S2, construct a cross-protocol semantic mapping table and generate a bidirectional conversion script. The bidirectional conversion script includes mapping rules between private protocol addresses and unified semantic identifiers and data format conversion functions. It should also be noted that the implementation process of step S3 is as follows: S3.1. For each subsystem, iterate through its data points and create a one-way mapping record from private protocol address to unified semantic identifier; S3.2. Based on the spatial connection relationship between nodes in the device semantic instantiation graph in S2, establish a reverse mapping record from the unified semantic identifier to the private protocol address of other subsystems to form a mapping tuple; S3.3. Automatically match data format conversion functions according to data point type, and generate bidirectional conversion scripts containing read and write operations. The read operation converts private protocol values ​​into unified semantic event values, and the write operation converts unified control commands into private protocol messages.

[0025] S4. Load the bidirectional conversion script generated in S3 onto the edge protocol conversion node, parse the data packets of each subsystem in real time, and output a unified semantic event stream; It should also be noted that the implementation process of step S4 is as follows: S4.1. Load the bidirectional conversion script generated by S3 in the edge protocol conversion node and initialize the protocol listening session; S4.2. Real-time capture of data packets on the communication bus of each subsystem, look up the mapping table based on the address field in the packet, apply the read conversion function to extract the value and attach a timestamp and unified semantic identifier to form a semantic event; S4.3. Push semantic events to the stream processing window of the linkage decision engine and persist them to the event log storage module.

[0026] S5. Based on the unified semantic event stream of S4 and the spatial topology relationship in S1, the linkage decision engine generates device linkage control instructions according to the condition-action rule matrix, and converts the device linkage control instructions into the private protocol control messages of the target subsystem through the bidirectional conversion script of S3. It should also be noted that the implementation process of step S5 is as follows: S5.1. The linkage decision engine receives the unified semantic event stream and extracts the event type, event value, and unified semantic identifier of the source device; S5.2. Based on the unified semantic identifier of the source device, retrieve spatial topology-related devices in the device semantic graph model of S1 to form a candidate set of affected devices; S5.3. Match the event type with the executable actions of the devices in the candidate set of affected devices. The condition-action rule matrix stores the correspondence between the triggering conditions and the target actions in advance. When a match is found, a unified control command for the target device is generated. S5.4. Call the write operation function in the bidirectional conversion script of S3 to convert the unified control command of the target device into the private protocol control message of the target subsystem, and distribute it through the edge protocol conversion node.

[0027] S6. Based on the execution status feedback of the monitoring equipment linkage control commands from S1 to S5, calculate the deviation between the feedback signal and the expected status signal. When the deviation meets the preset conditions, trigger the adaptive update of the device semantic instantiation graph and the cross-protocol semantic mapping table.

[0028] It should also be noted that the implementation process of step S6 is as follows: S6.1. After the target subsystem sends the private protocol control message, capture the target device's response message or periodically read the status data point through the protocol listening session of S4 to obtain the actual status value; S6.2. Compare the actual state value with the expected state value generated in S5, and calculate the normalization deviation; S6.3. When the normalization deviation of N consecutive samples exceeds the preset tolerance, it is determined that the mapping link has failed and the update process is triggered. N is an integer greater than or equal to 3. The S6.4 update process first isolates the failed link, then re-executes S2.2 and S2.3 to re-label the data points of the corresponding devices, and incrementally updates the cross-protocol semantic mapping table and bidirectional conversion script in S3.

[0029] Example 2, please refer to Figure 1 In practical applications, this embodiment provides a cross-platform integration and docking method for a building equipment monitoring system based on BIM. By constructing a semantic graph model of building equipment, and using the semantic graph as the core, it realizes the annotation, conversion, linkage and adaptive updating of multi-protocol data, solving the problems of semantic loss, rigid linkage and heavy manual maintenance in traditional integration. The system is executed collaboratively by a BIM model parsing engine, an edge protocol conversion node, and a linkage decision engine. Specifically, the BIM model parsing module uses a BIM file parser to execute the equipment semantic graph model construction step in step S1; the semantic annotation module uses a point table import interface and a semantic annotation engine to execute the protocol-independent equipment semantic instantiation graph construction step in step S2; the mapping table generation module uses a script compiler to execute the bidirectional conversion script generation step in step S3; the edge protocol conversion module uses a multi-protocol communication interface and script runtime to execute the unified semantic event stream output step in step S4; and the linkage decision module uses a rule engine to execute the linkage control command generation and conversion step in step S5.

[0030] The system's adaptive update module uses a deviation detector and a mapping update engine to execute the adaptive update step in step S6; the event log storage module uses a time series database to execute the semantic event persistence step in step S4; and the rule configuration interface module uses a visual management interface to configure the condition-action rule matrix. Specifically, the steps for cross-platform integration and interoperability of BIM-based building equipment monitoring systems are as follows: S1. Generation of Device Semantic Graph Model: This step extracts the geometric and engineering information from the building information model into a machine-understandable device semantic graph. S1.1. Traverse the IFC file and extract all device entities of type IfcBuildingElement subclass and IfcDistributionElement instance according to entity inheritance relationship, such as air conditioning unit, fan coil unit, variable air volume terminal, water pump, etc. The IFC entity resolver is used to establish a set of device entities using the unique identifier GlobalId. ; S1.2. Extract the spatial relationships between device entities and define three relationship types: containment relationship, adjacency relationship, and port connection relationship; Containment relations are extracted from IfcRelContainedInSpatialStructure, and adjacency relations are calculated by dividing the Euclidean distance between device bounding boxes and using a spatial adjacency threshold. The comparison yields port connection relationships extracted from IfcRelConnectsPorts or pipe / fitting associations; Construct a device graph using device entities as nodes and spatial relationships as directed or bidirectional edges. ,in correspond edge set Includes triples , ; For adjacency relationships, edge weights can be defined as normalized distances: ; To weaken the direct correlation strength of more distant devices; S1.3 is the diagram. Each node is appended with a set of static attributes To form a device semantic graph model ; Attribute vector Includes device type Functional classification (Such as "terminal air conditioning", "cold and heat source", "ventilation"), rated power, rated air volume and other design parameters; final Stored in attribute graph format, supporting subsequent graph queries; S2. Construction of Protocol-Independent Device Semantic Instantiation Graph: This step establishes a connection between the private protocol data points of each subsystem on site and the device semantic nodes in S1, and assigns them a unified semantic identifier to eliminate protocol heterogeneity. S2.1. The edge protocol conversion node initiates protocol probing on the attached subsystem controller; For the ModbusRTU protocol, a probe frame to read the holding register is sent; for the BACnet protocol, the Who-Is service primitive is sent, and the I-Am response is parsed to obtain the list of device objects and attribute identifiers. After the detection is completed, a list of data points is generated, with each record containing a private protocol address. (e.g., serial port number / slave address / register address) and data type hints; S2.2. Establish the association between the private protocol address and the building equipment object; Import the data point list into the device semantic instantiation engine, which reads the installation location labels of the data points or matches them using the coordinates on the installation drawings, and sets each... and device nodes in To pair up; If the label match is ambiguous, then a string similarity-based scoring function is enabled: ; in , For tag name, For device name, The coordinates are Euclidean distances; Select the highest score that is greater than the threshold The node is the corresponding device; S2.3. Assign a unified semantic identifier to each data point that has been associated. ; The hierarchical naming convention is adopted, and the specific expression is: ; in Indicates a hierarchy separator. Indicates the attribute separator; The physical quantity attribute name, such as "RoomTemp", "ValveOpening", "RunStatus"; A number for similar devices within the same space; This generates a protocol-independent device semantic instantiation graph. The nodes in this graph are , inherit from The spatial connection relationship, that is, if and Corresponding equipment and In the figure If there is an edge in the middle, then in Establish corresponding edges in the middle; Each node also records its private protocol address set. ; S3. Generation of cross-protocol semantic mapping table and bidirectional conversion script: This step starts from the semantic instantiation graph. The system automatically derives cross-system mapping relationships and compiles conversion scripts that can be directly loaded. S3.1. Construct a forward mapping table ; For each subsystem, iterate through its data points, using the private protocol address as the key. Generate a hash table for the value; S3.2. Constructing a reverse mapping table ,in Represents a power set; Based on the spatial connection edges between middle nodes, for any , perform breadth-first search with a depth of in the graph , , combine the subsystems of the searched neighborhood with private addresses and add them to reverse mapping records to form mapping tuples ; this provides direct addressing basis for cross-protocol write instructions in subsequent linkage; S3.3. Automatically match conversion functions according to data types and generate bidirectional conversion scripts; The conversion function is defined as: Read the conversion function (for analog quantity) or (for enumerated quantity); If is a 16-bit integer corresponding to temperature, the engineering range corresponds to the physical quantity , and linear mapping is adopted: ; If it is an enumerated state, establish a lookup table , where is a state set, for example , , ; Write the conversion function (for analog quantity) or (for enumerated quantity); Adopt inverse mapping, and add data type clamping and byte order processing at the same time; The generated script is stored in an extensible script object notation. Each script includes a read segment and a write segment. The read segment registers a callback function. When the edge node matches the specified , call and attach output events; the write segment exposes a remote call interface, receives and a target value, searches for the corresponding , calls and executes a bus write operation; S4. Real-time output of unified semantic event flow: This step runs the script in the edge protocol conversion node, and normalizes heterogeneous data streams into semantically identified events; S4.1. The script runtime in edge nodes loads all bidirectional conversion scripts generated in S3, and initializes listening sessions for each private protocol; ​For serial buses, open communication ports according to parameters such as baud rate and data bit configuration; for IP networks, establish TCP / UDP sockets and register read events. S4.2. When a data packet is detected, the parsing engine looks up the packet address. ; If a hit occurs, the corresponding function is invoked. Functions that generate semantic events: ; in For high-precision timestamps, This serves as a data quality identifier, with a value determined based on the communication verification results. or ; S4.3. Semantic events are pushed into the stream processing bus, serialized, and then pushed to the sliding window of the linkage decision engine. The window length is... The event log is dynamically adjusted based on the number of events to ensure sequential processing; another path writes the event log to the storage module in an efficient columnar format for post-event auditing and adaptive update analysis. S5. Coordinated Decision-Making Based on Spatial Topology: This step calculates linkage control commands in real time based on semantic events and spatial topology, and then distributes the commands across protocols. S5.1. The linkage decision engine retrieves a batch of semantic events from the sliding window; For each event, extract the event type. Event Value Source device unified semantic identifier ; S5.2. Based on source device In the device semantic graph model Search for spatial topology-related equipment in the middle; The retrieval algorithm uses constrained subgraph queries: corresponding nodes Starting from, along , , Controlled diffusion is carried out, with the diffusion depth limited to [value missing]. The edge weight decay factor is Add the end-of-path device node to the candidate set of affected devices. ; Nodes of the same type as the source device are filtered out during screening to prevent self-oscillation. S5.3. Condition-Action Rule Matrix It is a pre-configured set of predicate-action pairs, where each rule takes the form of: ; Among them, predicates For example, a Boolean expression. ;action For example, a set of device operations ,in For equipment Functional classification; The engine traversal rules use the event type and source device type as conditions, and... Match the executable actions of the device in the middle; Rule matching uses a variant of the Rete algorithm to construct a pattern network, accelerating the evaluation of multi-condition branches; Upon successful hit, a unified control command for the target device is generated: ; S5.4. Call the write interface of the bidirectional conversion script generated in S3, and pass in... ; Interface based on Query Obtain the private protocol address of the target subsystem. and its subsystem identifier, select the corresponding The function generates control messages conforming to the private protocol frame format and sends them to the target bus through the edge nodes. S6. Adaptive closed-loop update of linkage execution effect: This step evaluates the effectiveness of the mapping link by monitoring the device status feedback after the command is executed, and triggers the self-repair of semantic mapping when a persistent deviation occurs. S6.1. A response time window after the target subsystem's private protocol control message is sent. Internally, the S4 protocol is used to listen to sessions and capture response messages from the target device, or to periodically query the device's status data points to obtain the actual status value. ; S6.2. The deviation calculation adopts the normalized deviation index; For switch signals, the deviation is defined as follows: ; For analog quantities, the normalized bias is defined as follows: ; in and For physical range; Recently Secondary sampling Calculate the exponentially weighted moving average deviation: EWMA EWMA ; in ; S6.4. Trigger the adaptive update process: Re-execute the device association in S2.2 for the private protocol address corresponding to the exception \(\text{semID}\), and re-match the real-time data features with the device operation model to update the association relationship of the corresponding node in the device semantic instantiation graph; then re-execute S2.3 for semantic annotation, and if a new device or attribute is detected, perform incremental updates. Finally, the incremental update algorithm of the mapping table in S3 is called to regenerate only the affected mapping tuples and transformation script fragments, inject them into the edge nodes through the hot loading mechanism, replace the original failed scripts, and restore the link. The entire process records version numbers, forming a mapping evolution log; Through the closed-loop collaboration of steps S1 to S6 above, this embodiment tightly couples the BIM static model with real-time dynamic data, realizing cross-protocol semantic alignment, spatial awareness linkage, and mapping self-healing, thus solving the problems of data silos and operation and maintenance black holes in traditional integration.

[0031] In the description of this specification, references to terms such as "an embodiment," "example," "specific example," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of the invention. In this specification, illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0032] The preferred embodiments of the present invention disclosed above are merely illustrative of the invention. These preferred embodiments do not exhaustively describe all details, nor do they limit the invention to the specific implementations described. Clearly, many modifications and variations can be made based on the content of this specification. This specification selects and specifically describes these embodiments to better explain the principles and practical applications of the invention, thereby enabling those skilled in the art to better understand and utilize the invention. The invention is limited only by the claims and their full scope and equivalents.

Claims

1. A cross-platform integration and docking method for a BIM-based building equipment monitoring system, wherein the method is implemented based on a cross-platform integration and docking system, characterized in that, Includes the following steps: S1. Parse the building information model, extract building equipment objects and their spatial topological relationships, and generate a semantic graph model of the equipment; S2. Based on the device semantic graph model generated in S1, semantic annotation is performed on the private protocol data points of each access subsystem to construct a protocol-independent device semantic instantiation graph; S3. Based on the device semantic graph model of S1 and the device semantic instantiation graph of S2, construct a cross-protocol semantic mapping table and generate a bidirectional conversion script. The bidirectional conversion script includes mapping rules between private protocol addresses and unified semantic identifiers and data format conversion functions. S4. Load the bidirectional conversion script generated in S3 onto the edge protocol conversion node, parse the data packets of each subsystem in real time, and output a unified semantic event stream; S5. Based on the unified semantic event stream of S4 and the spatial topology relationship in S1, the linkage decision engine generates device linkage control instructions according to the condition-action rule matrix, and converts the device linkage control instructions into the private protocol control messages of the target subsystem through the bidirectional conversion script of S3. S6. Based on the execution status feedback of the monitoring equipment linkage control commands from S1 to S5, calculate the deviation between the feedback signal and the expected status signal. When the deviation meets the preset conditions, trigger the adaptive update of the device semantic instantiation graph and the cross-protocol semantic mapping table.

2. The cross-platform integration and docking method for a BIM-based building equipment monitoring system according to claim 1, characterized in that, The implementation process of step S1 is as follows: S1.

1. Extract entities from the building information model, identify the IfcBuildingElement subclass and IfcDistributionElement instance in the IFC, and obtain the equipment entities; S1.

2. Extract the spatial relationships between device entities, including inclusion relationships, adjacency relationships, and port connection relationships, and construct a device graph with device entities as nodes and spatial relationships as edges; S1.

3. Attach a static attribute set to each node in the device diagram. The static attribute set includes device type, functional classification and design parameters to form a device semantic graph model.

3. The cross-platform integration and docking method for a BIM-based building equipment monitoring system according to claim 2, characterized in that, The implementation process of step S2 is as follows: S2.

1. Obtain the list of data points and private protocol addresses exposed by each subsystem controller through protocol probing; S2.

2. In the device semantic instantiation graph, associate the private protocol addresses in the data point list with the device nodes in the device semantic graph model of S1. to determine the building device object corresponding to each data point; S2.

3. Semantically label each data point and assign a unified semantic identifier. The unified semantic identifier adopts a hierarchical naming rule and includes the device function type, attribute type and instance number. Generate a protocol-independent device semantic instantiation graph, in which the nodes are unified semantic identifiers and the edges are the spatial connection relationships extracted in S1.

4. The cross-platform integration and docking method for a BIM-based building equipment monitoring system according to claim 3, characterized in that, The implementation process of step S3 is as follows: S3.

1. For each subsystem, iterate through its data points and create a one-way mapping record from private protocol address to unified semantic identifier; S3.

2. Based on the spatial connection relationship between nodes in the device semantic instantiation graph in S2, establish a reverse mapping record from the unified semantic identifier to the private protocol address of other subsystems to form a mapping tuple; S3.

3. Automatically match data format conversion functions according to data point type, and generate bidirectional conversion scripts containing read and write operations. The read operation converts private protocol values ​​into unified semantic event values, and the write operation converts unified control commands into private protocol messages.

5. The cross-platform integration and docking method for a BIM-based building equipment monitoring system according to claim 4, characterized in that, The implementation process of step S4 is as follows: S4.

1. Load the bidirectional conversion script generated by S3 in the edge protocol conversion node and initialize the protocol listening session; S4.

2. Real-time capture of data packets on the communication bus of each subsystem, look up the mapping table based on the address field in the packet, apply the read conversion function to extract the value and attach a timestamp and unified semantic identifier to form a semantic event; S4.

3. Push semantic events to the stream processing window of the linkage decision engine and persist them to the event log storage module.

6. The cross-platform integration and docking method for a BIM-based building equipment monitoring system according to claim 5, characterized in that, The implementation process of step S5 is as follows: S5.

1. The linkage decision engine receives the unified semantic event stream and extracts the event type, event value, and unified semantic identifier of the source device; S5.

2. Based on the unified semantic identifier of the source device, retrieve spatial topology-related devices in the device semantic graph model of S1 to form a candidate set of affected devices; S5.

3. Match the event type with the executable actions of the devices in the candidate set of affected devices. The condition-action rule matrix stores the correspondence between the triggering conditions and the target actions in advance. When a match is found, a unified control command for the target device is generated. S5.

4. Call the write operation function in the bidirectional conversion script of S3 to convert the unified control command of the target device into the private protocol control message of the target subsystem, and distribute it through the edge protocol conversion node.

7. The cross-platform integration and docking method for a BIM-based building equipment monitoring system according to claim 6, characterized in that, The implementation process of step S6 is as follows: S6.

1. After the target subsystem sends the private protocol control message, capture the target device's response message or periodically read the status data point through the protocol listening session of S4 to obtain the actual status value; S6.

2. Compare the actual state value with the expected state value generated in S5, and calculate the normalization deviation; S6.

3. When the normalization deviation of N consecutive samples exceeds the preset tolerance, it is determined that the mapping link has failed and the update process is triggered. N is an integer greater than or equal to 3. The S6.4 update process first isolates the failed link, then re-executes S2.2 and S2.3 to re-label the data points of the corresponding devices, and incrementally updates the cross-protocol semantic mapping table and bidirectional conversion script in S3.

8. A cross-platform integration and docking system for a BIM-based building equipment monitoring system as described in any one of claims 1-7, characterized in that, The system includes: BIM model parsing module, which uses BIM file parser to execute the equipment semantic map model construction step in step S1; The semantic annotation module is used to execute the protocol-independent device semantic instantiation graph construction step in step S2 through the point table import interface and the semantic annotation engine. A mapping table generation module, which uses a script compiler to execute the bidirectional conversion script generation step in step S3; An edge protocol conversion module, which is used to execute the unified semantic event stream output step in step S4 through a multi-protocol communication interface and script runtime; The linkage decision module uses a rule engine to execute the linkage control instruction generation and conversion steps in step S5.

9. The system according to claim 8, characterized in that, The system also includes: An adaptive update module is used to execute the adaptive update step in step S6 through a deviation detector and a mapping update engine.

10. The system according to claim 8, characterized in that, The system also includes: The event log storage module uses a time-series database to perform the semantic event persistence step in step S4; The rule configuration interface module is used to configure the condition-action rule matrix through a visual management interface.

Images