A BIM-based digital engineering management method and system

Abstract

The application discloses a kind of based on BIM's digital engineering management method and system, belong to BIM engineering management technical field, specifically include: configuration metadata model is built index, define index dimension entity and its with BIM object attribute mapping relationship;According to index dimension entity and its with BIM object attribute mapping relationship, periodically execute BIM model data extraction, fill project characteristic table and synchronize index dimension configuration;Based on project characteristics, execute business rule matching, generate custom index template;Threshold and alarm level in custom index template are parsed, and compiled into executable alarm rule script;Execute alarm rule script and generate alarm event entity, push to message queue;According to user management role loading corresponding custom index template and alarm event, render exclusive index panel.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of BIM engineering management, and particularly relates to a BIM-based digital engineering management method and system. BACKGROUND

[0002] The existing BIM-based engineering management platform generally takes a three-dimensional model as the core, integrates multi-stage data such as design, construction and operation and maintenance, and realizes the centralized storage and unified viewing of project overall information through the interface connection with external business systems such as progress management systems, cost control systems and safety monitoring systems. The platform has built-in preset KPI panels for progress, cost and safety, which can synchronously display various indicators of the project in the form of column charts, line charts and pie charts in the three-dimensional scene, and support time period and region switching for browsing. In addition, the platform can automatically extract quantity data according to the BIM object attributes, and assist managers in visual report export and static document archiving.

[0003] For the above platform, the problem of insufficient customization in index dimension and visual analysis needs to be solved. Different projects have different management needs, and different roles (such as project managers, cost engineers and safety officers) pay attention to different index dimensions, threshold definitions and alarm rules, but the existing system only provides fixed panels, and it is difficult to flexibly configure the index dimension mapping relationship and threshold calculation logic. SUMMARY

[0004] The purpose of the present application is to provide a BIM-based digital engineering management method and system, which solves the following technical problems:

[0005] The existing BIM-based engineering management platform is too rigid in index display, only providing preset KPI panels for progress, cost and safety, and cannot flexibly customize index dimensions, thresholds and alarm rules according to different project characteristics or management roles.

[0006] The purpose of the present application can be achieved by the following technical solutions:

[0007] A BIM-based digital engineering management method, comprising:

[0008] S1: Constructing an index configuration metadata model, defining index dimension entities and their mapping relationship with BIM object attributes;

[0009] S2: According to the index dimension entities and their mapping relationship with BIM object attributes, regularly performing BIM model data extraction, filling the project feature table and synchronizing the index dimension configuration;

[0010] S3: Based on the project features, performing business rule matching to generate a custom index template;

[0011] S4: Parse the thresholds and alarm levels in the custom indicator template and compile them into an executable alarm rule script;

[0012] S5: Execute the alarm rule script and generate alarm event entities, then push them to the message queue;

[0013] S6: Load corresponding custom indicator templates and alarm events based on user management roles, and render a dedicated indicator panel.

[0014] As a further aspect of the present invention: the process of constructing the indicator configuration metadata model and defining the indicator dimension entities and their mapping relationship with BIM object attributes is as follows:

[0015] Create metric dimension entities in the metadata layer and define their attributes;

[0016] Based on the IFC standard, IfcPropertySet and IfcProperty parser are used to extract component attribute sets and attribute items in BIM models in batches; the extraction results are then mapped to BIM object attribute metadata tables.

[0017] Establish a set of mapping rules for indicator dimension entities and BIM object attribute metadata; each rule includes: indicator identifier, target attribute set, target attribute item and mapping method; the mapping method adopts function reference and supports two modes: single attribute extraction and multi-attribute calculation and aggregation.

[0018] As a further aspect of the present invention: the process of periodically extracting BIM model data, populating the project feature table, and synchronizing the configuration of indicator dimensions is as follows:

[0019] The scheduling system calls the metadata service to retrieve all current indicator dimension entities and their mapping relationship with BIM object attributes, and dynamically generates extraction operation templates.

[0020] In the scheduling system, an independent extraction DAG is configured for each project, with the extraction period defined in the indicator dimension entity as the trigger condition. The scheduling system triggers the extraction job based on the project's time zone and period to ensure that the jobs do not interfere with each other in a multi-project environment.

[0021] The task template is extracted and the BIM data interface is called to retrieve the attributes of specified components in batches according to the mapping relationship; for attribute set fields, an incremental extraction strategy is executed.

[0022] During the ETL transformation phase, the original attribute values ​​are subjected to type conversion, unit standardization, and multi-attribute aggregation calculations according to the mapping function; the processing results are then mapped to the fields defined in the project feature table.

[0023] After the extraction job is completed, the version interface of the metadata service is called to pull the latest indicator dimension configuration and write it to the configuration table; the configuration table and the project feature table share the same transaction boundary.

[0024] As a further aspect of the present invention: the process of performing business rule matching based on project characteristics to generate a custom indicator template is as follows:

[0025] The business rule library is maintained in the rule management module. Each rule consists of a condition expression and a target indicator dimension identifier. The condition expression is defined based on the project feature fields using a decision table or a domain-specific language.

[0026] Read all feature fields of the current project from the project feature table, and construct the rule engine input context, which includes: feature key, feature value and feature timestamp;

[0027] Submit the rule engine input context and business rule base to the rule engine, and match them according to rule priority and conflict resolution strategy execution conditions; the rules that are successfully matched output the corresponding indicator identifier and associated threshold parameter set.

[0028] Aggregate all matching outputs and combine each indicator identifier, calculation expression, low threshold, high threshold, and alarm level into a custom indicator template entry; encapsulate all entries into JSON documents grouped by project.

[0029] As a further aspect of the present invention: the process of parsing the threshold and alarm level in the custom indicator template and compiling them into an executable alarm rule script is as follows:

[0030] The template parsing module is called to perform structural validation on the custom indicator template based on the predefined JSON Schema. After the validation is successful, it is deserialized into a collection of template model objects in memory. Each template model corresponds to a TemplateEntry, which includes: indicator identifier, calculation expression, low threshold, high threshold, and alarm level.

[0031] Iterate through the template model collection, extract the low threshold, high threshold, and alarm level for each TemplateEntry, and build a threshold mapping table;

[0032] The AST builder is used to synthesize the calculated expression of each TemplateEntry and the threshold mapping table into a conditional expression tree. The node types include: indicator calculation, threshold comparison, and alarm level triggering, forming an intermediate representation that can be generated by code.

[0033] The intermediate representation is passed to the alarm rule script generator, which translates ConditionAST into an executable script for the target platform based on the script template, and generates the script text ScriptText.

[0034] The script compiler interface is called to perform syntax checks and performance linting on ScriptText. After the checks pass, the script is uploaded to the stream processing platform rule repository via the publishing API. The RuleID and deployment version number are returned, completing the generation and registration of the executable alarm rule script.

[0035] As a further aspect of the present invention: the process of executing the alarm rule script, generating alarm event entities, and pushing them to the message queue is as follows:

[0036] The compiled alarm rule script (ScriptText) is submitted to the stream processing engine as a job; the BIM parameter event stream is bound through the source connector built into the job; the Flink CEP library is used to define the pattern inside the alarm rule script (ScriptText), and the threshold comparison logic in the intermediate representation is used as a condition function; the engine maintains the status handle of each indicator to accumulate continuous out-of-bounds judgments across event windows, ensuring that complex alarms can also be triggered.

[0037] After the Complex Event Processing (CEP) matches a threshold exceeding the limit or a pattern being met, it executes the ProcessFunction to instantiate an alarm event entity object. After generating the alarm event entity, it calls the metadata service interface to inject the indicator dimension metadata and project context information, forming an alarm event entity with a richer dimension context.

[0038] The enriched alarm event entities are serialized according to the Avro serialization format or Protobuf mode, and written to the message queue through Flink's output connector.

[0039] As a further aspect of the present invention: the process of loading corresponding custom indicator templates and alarm events based on user management roles and rendering a dedicated indicator panel is as follows:

[0040] When a user logs in, the identity authentication service issues a JWT containing a management role declaration; the front-end gateway parses the JWT and writes the management role into the request context, providing unified identity information for subsequent access control and data filtering;

[0041] In the template configuration service, a many-to-many permission mapping is established between custom indicator templates and management roles; the rendering engine calls the RESTful interface of the template configuration service, passes in the management role identifier in the request context, obtains the list of templates that the role can access, and returns the custom indicator template payload in JSON format after filtering by role.

[0042] In the alarm event consumption service, access policies are configured for alarm event entities according to metric dimensions and project levels; the rendering engine uses the GraphQL query interface to obtain the set of alarm event entities that the management role is concerned about, with pagination and sorting parameters to ensure that the event list is real-time and focused.

[0043] The front end uses a template-driven rendering framework, which dynamically maps custom indicator templates to the component library. The component factory receives the configuration fields of each template item, instantiates a visualization component that corresponds one-to-one with the indicator dimension, and mounts it to the dedicated indicator panel layout container.

[0044] After the panel is rendered, a long connection is established with the alarm event push service via the WebSocket bidirectional communication protocol or server push event. When a new alarm event entity arrives, the front-end message processor locates the corresponding component based on the indicator dimension in the event and updates the component status.

[0045] A BIM-based digital engineering management system includes:

[0046] The indicator metadata management module is used to build an indicator configuration metadata model and define indicator dimension entities and their mapping relationship with BIM object attributes.

[0047] The BIM data extraction and synchronization module periodically extracts BIM model data based on the entity of the indicator dimension and its mapping relationship with the attribute of BIM object, populates the project feature table and synchronizes the indicator dimension configuration.

[0048] The custom template generation module performs business rule matching based on project characteristics to generate custom indicator templates;

[0049] The alarm rule compilation module is used to parse the thresholds and alarm levels in the custom indicator template and compile them into executable alarm rule scripts;

[0050] The alarm execution and event push module is used to execute alarm rule scripts and generate alarm event entities, which are then pushed to the message queue.

[0051] The visualization panel rendering module loads corresponding custom indicator templates and alarm events based on the user's management role, and renders a unique indicator panel.

[0052] The beneficial effects of this invention are:

[0053] This invention constructs an indicator configuration metadata model, defining indicator dimension entities and their mapping rules to BIM object attributes. This enables the generation of custom indicator templates for multiple projects and roles, eliminating the traditional platform's rigid reliance on KPI panels for schedule, cost, and safety. It allows different management roles, such as project managers, cost engineers, and safety officers, to flexibly configure indicators based on their preferred dimensions, thresholds, and alarm levels, and synchronize these indicators in real-time to the BIM 3D scene for dynamic visualization. Based on this, the system's adaptability and scalability are significantly improved, reducing secondary development and maintenance costs.

[0054] By leveraging a custom indicator template parser and AST builder, thresholds and alarm levels are compiled into executable alarm rule scripts. Complex event processing is then performed using the Flink CEP engine within a stream processing platform, enabling real-time monitoring and continuous boundary judgment of BIM model parameter event streams. The generated alarm event entities are serialized and pushed to a message queue, where they are accurately rendered and promptly pushed through a role-aware, dedicated indicator panel. This allows managers to quickly pinpoint the root cause of problems and take targeted measures when indicators are abnormal, effectively improving the level of engineering safety management, cost control efficiency, and the visual monitoring capabilities of schedule execution. Attached Figure Description

[0055] The invention will now be further described with reference to the accompanying drawings.

[0056] Figure 1 This is a flowchart illustrating a BIM-based digital engineering management method according to the present invention.

[0057] Figure 2 This is a schematic diagram of a BIM-based digital engineering management system according to the present invention. Detailed Implementation

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

[0059] Please see Figure 1 As shown, this invention is a BIM-based digital engineering management method, comprising:

[0060] S1: Construct an indicator configuration metadata model, defining indicator dimension entities and their mapping relationship with BIM object attributes;

[0061] In step S1, an indicator configuration metadata model is constructed, defining indicator dimension entities and their mapping relationship with BIM object attributes.

[0062] Create a metric dimension entity in the metadata layer, defining its attributes: metric identifier, metric name, calculation expression, data type, and unit. This metric dimension entity inherits from the general metadata parent class, ensuring that all metric dimension instances have a unified metadata structure.

[0063] In BIM project management, when managing a batch of project indicators, such as "remaining schedule," "concrete volume," and "material cost," the first thing to do is to list the name of each indicator, explain how it is calculated, what units are needed (days, cubic meters, yuan), and where the data is obtained. This step is equivalent to creating an "indicator list" in a spreadsheet, with each row representing one indicator, followed by notes on how the data was obtained and calculated.

[0064] Based on the IFC standard, the IfcPropertySet and IfcProperty parser are used to extract component attribute sets and attribute items in batches from the BIM model. The extraction results are then mapped to a BIM object attribute metadata table, with fields including attribute set name, attribute name, value type, and associated component type.

[0065] The BIM model contains numerous components (beams, columns, walls) and their attributes (length, height, material type). This step involves using tools to automatically extract the attributes of each component (such as the cross-sectional area of ​​a beam and the height of a column) and store them in a table. This provides the foundational data for subsequent calculations of concrete volume.

[0066] A set of mapping rules is established between indicator-dimensional entities and BIM object attribute metadata. Each rule includes: indicator identifier, target attribute set, target attribute item, and mapping method. The mapping method uses function references and supports both single-attribute extraction and multi-attribute calculation aggregation modes. For example, the indicator "concrete volume" needs to be calculated by finding the "cross-sectional area" and "length" of each column in the BIM table; "remaining construction period" needs to be calculated by finding the timestamps of the progress nodes. This step involves creating a "correspondence table" in the system, matching the indicator with the part attributes it needs, and specifying whether to directly retrieve the data or to calculate several attributes together.

[0067] Next, the indicator dimension entities and mapping rule sets are persisted to a graph database or triple repository, and graph model nodes are constructed: MetricDimension, BIMProperty, and MappingRule; a REST-style query interface based on Cypher or SPARQL is provided for the upper-layer ETL process to retrieve indicator dimension definitions and their mapping relationships.

[0068] For typical project samples, perform mapping rule testing: After calling the query interface to obtain the mapping rules, verify whether the BIM object attribute extraction results can correctly fill the input parameters required by the indicator dimensions; based on the test feedback, perform version management of the ontology and mapping rule set to ensure that the mapping relationship can be seamlessly extended when adding new indicator dimensions or BIM attributes.

[0069] In step S2, based on the entity of the indicator dimension and its mapping relationship with the attributes of BIM objects, BIM model data extraction is performed periodically to populate the project feature table and synchronize the indicator dimension configuration.

[0070] The scheduling system (such as Apache Airflow) calls the metadata service to retrieve all current indicator dimension entities and their mapping relationship with BIM object attributes, and dynamically generates extraction job templates. The template content includes: target BIM attribute set, attribute name, mapping function reference and output field mapping.

[0071] Each project is configured with an independent extraction DAG in the scheduling system, with the extraction period defined in the indicator dimension entity as the trigger condition. The scheduling system accurately triggers the extraction operation based on the project's time zone and period, ensuring that the operations do not interfere with each other in a multi-project environment.

[0072] The task template is extracted by calling the BIM data interface to batch retrieve the attributes of specified components according to the mapping relationship. For attribute set fields, an incremental extraction strategy is executed to retrieve only the attribute values ​​that have changed since the last extraction.

[0073] During the ETL transformation phase, the original attribute values ​​are converted to different types, standardized in units, and aggregated using the mapping function. The processing results are then mapped to the fields defined in the project feature table, and an extraction timestamp and data source identifier are appended.

[0074] After the extraction job is completed, the version interface of the metadata service is called to pull the latest indicator dimension configuration and write it to the configuration table; the configuration table and the project feature table share the same transaction boundary to ensure the consistency between feature data and configuration version.

[0075] Further explanation: Just like issuing a "material requisition form" to a construction team, the system first automatically opens the "Indicator Dictionary" and the "Indicator-BIM Attribute Correspondence Table," generating a "Material Requisition Data Description Sheet" based on these two. The sheet lists which BIM model attributes to retrieve (such as beam length and wall thickness), and which column in the "Project Feature Table" these attributes should be placed in after retrieval. Next, the "Material Requisition Data Description Sheet" is placed on the scheduling tool (similar to a construction site schedule board), allowing for individual scheduling of data retrieval frequency and time for each project. The system will precisely initiate data retrieval tasks according to the "daily / weekly / monthly" schedule specified on the sheet, ensuring no conflicts between different projects. At the scheduled time, the system connects to the BIM model according to the instructions in the sheet (like a worker taking the sheet to a warehouse), batch-extracting the specified attribute values ​​(such as component dimensions and progress nodes). To improve efficiency, the system only extracts data that has changed since the last data retrieval. The system cleans the raw data retrieved earlier: units are converted to a uniform format (meters, days, square meters); related data are grouped together (e.g., area is calculated using length and width); the organized data is then entered into the "Project Feature Table" according to the corresponding columns, along with the current data retrieval time and data source. Finally, the system reads the latest "Indicator Dictionary" and "Corresponding Rules," storing them together in the configuration table. This step, along with updating the "Project Feature Table," is the same operation, like locking the new rules and data in a safe to ensure they are always a corresponding version. This way, subsequent analyses and alerts relying on this data use the latest and most accurate configuration.

[0076] In step S3, business rule matching is performed based on project characteristics to generate a custom indicator template.

[0077] The business rule base is maintained in the rule management module. Each rule consists of a condition expression and a target indicator dimension identifier. The condition expression is defined using a decision table or domain-specific language based on project feature fields (such as component volume, schedule milestones, and subcontractor risk level).

[0078] Read all feature fields of the current project from the project feature table, construct the rule engine input context, including: feature key, feature value and feature timestamp, to ensure that the rule evaluation is based on the latest project status.

[0079] Submit the rule engine input context and business rule base to the rule engine (such as Drools or Apache FlinkCEP), and match the execution conditions according to the rule priority and conflict resolution strategy; the successfully matched rule outputs the corresponding indicator and associated threshold parameter set, including low threshold, high threshold and alarm level.

[0080] Aggregate all matching outputs and combine each metric identifier, calculation expression (from metric dimension metadata), low threshold, high threshold, and alarm level into a custom metric template entry; encapsulate all entries into JSON documents grouped by project.

[0081] Further explanation: The business rule base is like a large table, where each row indicates "If this value in the project meets a certain condition, a certain indicator should be monitored." For example, "If the subcontractor's safety level is high-risk, a safety inspection indicator should be added," or "If a progress node is not yet completed, the remaining construction period indicator should be monitored." This way, the system knows under what circumstances which indicators need to be included in the template. All current data recorded in the "Project Feature Table" is extracted, such as the thickness of each wall, the volume of each structure, the rating of each subcontractor, the completion time of each milestone, etc., and integrated into a "rule evaluation package." This package ensures that the latest and complete project status is used when making rule judgments. This "rule evaluation package" is then handed over to the "rule engine"—which acts like a scheduler, checking each rule in the "business rule base" to see which rules' conditions are met under the current project status. Whenever a rule is triggered, it tells the system "to track this indicator," and outputs the pre-written thresholds (what values ​​are considered normal, what values ​​trigger an alarm) and alarm level for that rule. Compile all triggered metrics, their corresponding calculation methods, alarm thresholds, and alarm levels into a list. Then, package this list into a "custom metric template" specifically for the current project. This template is like a checklist, listing which metrics need to be monitored for this project, how each metric is calculated, when an alarm should be triggered, and what the alarm level should be.

[0082] In step S4: the thresholds and alarm levels in the custom indicator template are parsed and compiled into an executable alarm rule script.

[0083] The template parsing module is invoked to perform structural validation on the custom indicator template based on the predefined JSON Schema. After the validation is successful, the template is deserialized into a collection of template model objects in memory. Each template model corresponds to a TemplateEntry, which includes: indicator identifier, calculation expression, low threshold, high threshold, and alarm level.

[0084] Iterate through the template model set, extract the low threshold, high threshold, and alarm level for each TemplateEntry, and build a threshold mapping table. The table entries contain: indicator identifier, low threshold, high threshold, and alarm level, which can be referenced by subsequent rule logic.

[0085] The AST builder is used to synthesize the calculated expression of each TemplateEntry with the threshold mapping table to form a conditional expression tree. The node types include: MetricEvaluation, ThresholdComparison, and AlertAction, forming an intermediate representation (IR) that can be generated by code.

[0086] The intermediate representation is passed to the alarm rule script generator (RuleScriptGenerator). Based on the script template (such as Flink CEP template or SQL UDF template), the ConditionAST is translated into an executable script for the target platform, generating the script text ScriptText. The script includes: event source definition, condition judgment logic after ConditionAST transformation and AlertAction call.

[0087] The script compiler interface is called to perform syntax checks and performance linting on ScriptText. After the checks pass, the script is uploaded to the stream processing platform rule repository via the publishing API. The RuleID and deployment version number are returned, completing the generation and registration of the executable alarm rule script.

[0088] Further explanation: Similar to receiving a monitoring list, you first need to check its format for correctness (whether any columns are missing or names are misspelled). Once confirmed, you import it into the computer and use a program to store each indicator (such as "concrete strength" or "construction progress") into an easily accessible internal list. Then, you review the imported list one by one, extracting the "lower alarm limit," "upper alarm limit," and "alarm level" (severe, moderate, minor) for each indicator, creating an "indicator-alarm parameter" lookup table so that these three values ​​can be easily found later. Next, the calculation method for each indicator (e.g., "dividing volume by area to get thickness") and alarm parameters are combined to construct a flowchart model similar to "first calculate the thickness, then check if it is below the lower limit or above the upper limit; if it exceeds the limit, an alarm is triggered." This lays the foundation for subsequent script writing. Taking the flowchart model from the previous step, it's inserted into a script template (like filling in text in a blank space on a notice board), automatically outputting a piece of program code that can be directly run in the monitoring system. This code specifies "where to read data," "how to calculate indicators," and "when to trigger which level of alarm." Finally, the generated code undergoes an automatic "syntax check" to ensure there are no spelling or logical errors before being uploaded to the monitoring system. Once the code is successfully deployed, the system will monitor the indicators in real time according to this code and issue corresponding alarms when alarm conditions are met.

[0089] In step S5: Execute the alarm rule script and generate alarm event entities, and push them to the message queue;

[0090] Submit the compiled alarm rule script (ScriptText) as a job to the stream processing engine (such as Apache Flink); bind the BIM parameter event stream (such as a project feature topic from Kafka) through the job's built-in source connector to ensure that the alarm rule script can receive input events containing MetricID, FeatureValue, and FeatureTimestamp in real time.

[0091] The alarm rule script uses the Flink CEP library to define patterns and uses the threshold comparison logic in the intermediate representation as a condition function. The engine maintains the state handle of each indicator to accumulate continuous out-of-bounds judgments across event windows, ensuring that complex alarms (such as those that are continuously higher than the threshold N times) can also be triggered.

[0092] After the Complex Event Processing (CEP) matches a threshold exceeding the limit or a pattern being met, it executes the ProcessFunction to instantiate an alarm event entity object. The attributes include: alarm ID, associated indicator dimension ID, trigger timestamp, alarm level, associated BIM component ID, and original feature value.

[0093] After generating the alarm event entity, the metadata service interface is called to inject the metric dimension metadata (such as metric name and unit) and project context information (such as ProjectID and stage label) to form an alarm event entity with richer dimension context, which improves readability and traceability when consumed downstream.

[0094] The enriched alarm event entities are serialized according to the Avro serialization format or Protobuf mode, and written to a message queue (such as the "alert-events" topic in Kafka) through the Flink output connector. After the message is successfully pushed, the version can be recorded in the Schema Registry for monitoring and backtracking.

[0095] Further explanation: Similar to installing an alarm rule program within a data factory, the program continuously monitors the latest parameters coming from the BIM model, such as the progress or temperature of each beam. This ensures the code can see all real-time arriving values ​​and is ready to make judgments. The program sets alarm patterns, such as "alarm if three consecutive measurements exceed the safety limit," and internally maintains a small "notebook" for each indicator to record the previous measurement results to determine if it meets the criteria for continuous exceeding of limits. Once the program detects that an indicator has truly exceeded the threshold, it immediately creates an "alarm event" record, specifying: alarm number, which indicator, time, alarm level, which component triggered it, and the measured value at that time. To help those receiving the alarm understand the situation more quickly, the program includes the full name of the indicator, unit (e.g., "temperature in °C"), and the name or stage of the project within this "alarm event," placing the alarm within the specific project context in a single sentence. Finally, the system compresses and packages the complete alarm event in a standardized format (similar to a pre-filled form) and sends it to the backend or monitoring platform via a message channel (like pushing it to a public address system) for the responsible person and downstream systems to receive and process in real time.

[0096] In step S6: Load the corresponding custom indicator template and alarm event according to the user management role, and render the exclusive indicator panel;

[0097] When a user logs in, the identity authentication service (such as OAuth2 or OpenID Connect) issues a JWT containing a "management role" declaration; the front-end gateway parses the JWT and writes the management role into the request context, providing unified identity information for subsequent access control and data filtering.

[0098] In the template configuration service, a many-to-many permission mapping is established between custom indicator templates and management roles; the rendering engine calls the RESTful interface of the template configuration service, passes in the management role identifier in the RequestContext, obtains the list of templates that the role can access, and returns the custom indicator template payload in JSON format after filtering by role.

[0099] In the alarm event consumption service, access policies are configured for alarm event entities according to metric dimensions and project levels; the rendering engine uses the GraphQL query interface to obtain the set of alarm event entities that the management role is concerned about, with pagination and sorting parameters, to ensure that the event list is real-time and focused.

[0100] The front end uses a template-driven rendering framework (such as React + JSON Schema Form) to dynamically map custom indicator templates to component libraries (such as chart components and dashboard components). The component factory receives the configuration fields of each template item, instantiates visualization components that correspond one-to-one with the indicator dimensions, and mounts them to a dedicated indicator panel layout container.

[0101] After the panel is rendered, a long connection is established with the alarm event push service via WebSocket or Server-Sent Events. When a new alarm event entity arrives, the front-end message handler (EventHandler) locates the corresponding component based on the indicator dimension identifier in the event, updates the component status (such as highlighting alarms and refreshing values), and maintains real-time consistency between the dedicated indicator panel and the back-end alarm stream.

[0102] Please see Figure 2 As shown, the present invention also includes a BIM-based digital engineering management system for implementing the above-described BIM-based digital engineering management method, comprising:

[0103] The indicator metadata management module is used to build an indicator configuration metadata model and define indicator dimension entities and their mapping relationship with BIM object attributes.

[0104] The BIM data extraction and synchronization module periodically extracts BIM model data based on the entity of the indicator dimension and its mapping relationship with the attribute of BIM object, populates the project feature table and synchronizes the indicator dimension configuration.

[0105] The custom template generation module performs business rule matching based on project characteristics to generate custom indicator templates;

[0106] The alarm rule compilation module is used to parse the thresholds and alarm levels in the custom indicator template and compile them into executable alarm rule scripts;

[0107] The alarm execution and event push module is used to execute alarm rule scripts and generate alarm event entities, which are then pushed to the message queue.

[0108] The visualization panel rendering module loads corresponding custom indicator templates and alarm events based on the user's management role, and renders a unique indicator panel.

[0109] The foregoing has provided a detailed description of one embodiment of the present invention, but this description is merely a preferred embodiment and should not be construed as limiting the scope of the invention. All equivalent variations and modifications made within the scope of the claims of this invention should still fall within the patent coverage of this invention.

Claims

1. A BIM-based digital engineering management method, characterized in that, include: S1: Construct an indicator configuration metadata model, defining indicator dimension entities and their mapping relationship with BIM object attributes; The specific process is as follows: Create an indicator dimension entity in the metadata layer and define the following attributes: indicator identifier, indicator name, calculation expression, data type and unit; Based on the IFC standard, IfcPropertySet and IfcProperty parser are used to extract component attribute sets and attribute items in BIM models in batches; the extraction results are then mapped to BIM object attribute metadata tables. Establish a set of mapping rules for indicator dimension entities and BIM object attribute metadata; each rule includes: indicator identifier, target attribute set, target attribute item and mapping method; the mapping method adopts function reference and supports two modes: single attribute extraction and multi-attribute calculation and aggregation; S2: Based on the entity of the indicator dimension and its mapping relationship with the attribute of BIM object, BIM model data extraction is performed periodically to populate the project feature table and synchronize the indicator dimension configuration; the specific process is as follows: The scheduling system calls the metadata service to retrieve all current indicator dimension entities and their mapping relationship with BIM object attributes, and dynamically generates extraction operation templates. In the scheduling system, an independent extraction DAG is configured for each project, with the extraction period defined in the indicator dimension entity as the trigger condition. The scheduling system triggers extraction operations based on the project's time zone and cycle; The task template is extracted and the BIM data interface is called to retrieve the attributes of specified components in batches according to the mapping relationship; for attribute set fields, an incremental extraction strategy is executed. During the ETL transformation phase, the original attribute values ​​are subjected to type conversion, unit standardization, and multi-attribute aggregation calculations according to the mapping function; the processing results are then mapped to the fields defined in the project feature table. After the extraction job is completed, the version interface of the metadata service is called to pull the latest indicator dimension configuration and write it to the configuration table; the configuration table and the project feature table share the same transaction boundary; S3: Perform business rule matching based on project characteristics to generate custom indicator templates; the specific process is as follows: The business rule base is maintained in the rule management module. Each rule consists of a condition expression and an indicator identifier. The condition expression is defined based on the project feature fields using a decision table or a domain-specific language. Read all feature fields of the current project from the project feature table, and construct the rule engine input context, which includes: feature key, feature value and feature timestamp; Submit the rule engine input context and business rule base to the rule engine, and match them according to rule priority and conflict resolution strategy execution conditions; the rules that are successfully matched output the corresponding indicator identifier and associated threshold parameter set. Aggregate all matching outputs and combine each indicator identifier, calculation expression, low threshold, high threshold, and alarm level into a custom indicator template entry; encapsulate all entries into JSON documents grouped by project. S4: Parse the thresholds and alarm levels in the custom indicator template and compile them into an executable alarm rule script; S5: Execute the alarm rule script and generate alarm event entities, then push them to the message queue; S6: Load corresponding custom indicator templates and alarm events based on user management roles, and render a dedicated indicator panel.

2. The BIM-based digital engineering management method according to claim 1, characterized in that, The process of parsing the thresholds and alarm levels in the custom indicator template and compiling them into an executable alarm rule script is as follows: The template parsing module is called to perform structural validation on the custom indicator template based on the predefined JSON Schema. After the validation is successful, it is deserialized into a set of template models in memory. Each template model corresponds to a TemplateEntry, which includes: indicator identifier, calculation expression, low threshold, high threshold, and alarm level. Iterate through the template model collection, extract the low threshold, high threshold, and alarm level for each TemplateEntry, and build a threshold mapping table; The AST builder is used to synthesize the calculated expression of each TemplateEntry and the threshold mapping table into a conditional expression tree. The node types include: indicator calculation, threshold comparison, and alarm level triggering, forming an intermediate representation that can be generated by code. The intermediate representation is passed to the alarm rule script generator, which translates ConditionAST into an executable script for the target platform based on the script template, and generates the script text ScriptText. The script compiler interface is called to perform syntax checks and performance linting on ScriptText. After the checks pass, the script is uploaded to the stream processing platform rule repository via the publishing API. The RuleID and deployment version number are returned, completing the generation and registration of the executable alarm rule script.

3. The BIM-based digital engineering management method according to claim 1, characterized in that, The process of executing the alarm rule script, generating alarm event entities, and pushing them to the message queue is as follows: The compiled alarm rule script is submitted to the stream processing engine as a job; the BIM parameter event stream is bound through the source connector built into the job; the pattern is defined using the Flink CEP library inside the alarm rule script, and the threshold comparison logic in the intermediate representation is used as a condition function; the engine maintains the status handle of each indicator for accumulating continuous out-of-bounds judgments across event windows. After the Complex Event Processing (CEP) matches a threshold exceeding the limit or a pattern being met, it executes the ProcessFunction to instantiate the alarm event entity. After generating the alarm event entity, it calls the metadata service interface to inject the indicator dimension metadata and project context information, forming an alarm event entity with richer dimension context. The enriched alarm event entities are serialized according to the Avro serialization format or Protobuf mode, and written to the message queue through Flink's output connector.

4. The BIM-based digital engineering management method according to claim 1, characterized in that, The process of loading corresponding custom indicator templates and alarm events based on user management roles and rendering a dedicated indicator panel is as follows: When a user logs in, the identity authentication service issues a JWT containing a statement of management roles; The front-end gateway parses the JWT and writes the management role into the request context, providing unified identity information for subsequent access control and data filtering. In the template configuration service, a many-to-many permission mapping is established between custom indicator templates and management roles; The rendering engine calls the RESTful interface of the template configuration service, passes in the management role identifier in the request context, obtains the list of templates accessible to that role, and returns the custom metric template load in JSON format after filtering by role. In the alarm event consumption service, access policies are configured for alarm event entities according to indicator dimensions and project level; The rendering engine uses the GraphQL query interface to retrieve the set of alarm event entities that the management role is concerned about, with pagination and sorting parameters to ensure that the event list is real-time and focused. The front end uses a template-driven rendering framework, which dynamically maps custom indicator templates to the component library. The component factory receives the configuration fields of each template item, instantiates a visualization component that corresponds one-to-one with the indicator dimension, and mounts it to the dedicated indicator panel layout container. After the panel is rendered, a long connection is established with the alarm event push service via the WebSocket bidirectional communication protocol or server push event; when a new alarm event entity arrives, the front-end message processor locates the corresponding component based on the indicator in the event and updates the component status.

5. A BIM-based digital engineering management system, used to implement the BIM-based digital engineering management method according to any one of claims 1-4, characterized in that, include: The indicator metadata management module is used to build an indicator configuration metadata model and define indicator dimension entities and their mapping relationship with BIM object attributes. The specific process is as follows: Create an indicator dimension entity in the metadata layer and define the following attributes: indicator identifier, indicator name, calculation expression, data type and unit; Based on the IFC standard, IfcPropertySet and IfcProperty parser are used to extract component attribute sets and attribute items in BIM models in batches; the extraction results are then mapped to BIM object attribute metadata tables. Establish a set of mapping rules for indicator dimension entities and BIM object attribute metadata; each rule includes: indicator identifier, target attribute set, target attribute item and mapping method; the mapping method adopts function reference and supports two modes: single attribute extraction and multi-attribute calculation and aggregation; The BIM data extraction and synchronization module periodically extracts BIM model data based on the entity of the indicator dimension and its mapping relationship with BIM object attributes, populates the project feature table, and synchronizes the indicator dimension configuration; the specific process is as follows: The scheduling system calls the metadata service to retrieve all current indicator dimension entities and their mapping relationship with BIM object attributes, and dynamically generates extraction operation templates. In the scheduling system, an independent extraction DAG is configured for each project, with the extraction period defined in the indicator dimension entity as the trigger condition. The scheduling system triggers extraction operations based on the project's time zone and cycle; The task template is extracted and the BIM data interface is called to retrieve the attributes of specified components in batches according to the mapping relationship; for attribute set fields, an incremental extraction strategy is executed. During the ETL transformation phase, the original attribute values ​​are subjected to type conversion, unit standardization, and multi-attribute aggregation calculations according to the mapping function; the processing results are then mapped to the fields defined in the project feature table. After the extraction job is completed, the version interface of the metadata service is called to pull the latest indicator dimension configuration and write it to the configuration table; the configuration table and the project feature table share the same transaction boundary; The custom template generation module performs business rule matching based on project characteristics to generate custom indicator templates; the specific process is as follows: The business rule base is maintained in the rule management module. Each rule consists of a condition expression and an indicator identifier. The condition expression is defined based on the project feature fields using a decision table or a domain-specific language. Read all feature fields of the current project from the project feature table, and construct the rule engine input context, which includes: feature key, feature value and feature timestamp; Submit the rule engine input context and business rule base to the rule engine, and match them according to rule priority and conflict resolution strategy execution conditions; the rules that are successfully matched output the corresponding indicator identifier and associated threshold parameter set. Aggregate all matching outputs and combine each indicator identifier, calculation expression, low threshold, high threshold, and alarm level into a custom indicator template entry; encapsulate all entries into JSON documents grouped by project. The alarm rule compilation module is used to parse the thresholds and alarm levels in the custom indicator template and compile them into executable alarm rule scripts; The alarm execution and event push module is used to execute alarm rule scripts and generate alarm event entities, which are then pushed to the message queue. The visualization panel rendering module loads corresponding custom indicator templates and alarm events based on the user's management role, and renders a unique indicator panel.

Images