An industrial monitoring system generation method and system based on a large language model

Abstract

The application discloses an industrial monitoring system generation method and system based on a large language model. By locking a unique reference design document and constraining subsequent models to only perform mapping, the application eliminates attribute name inconsistencies and cross-reference errors in manual configuration from the source, reducing system delivery time. By limiting attribute references to the current node subtree range and performing reference legality verification, the application effectively suppresses field hallucinations and cross-node misreferences of large language models. By using segmented generation and double verification mechanisms, the application avoids configuration file truncation and syntax damage caused by single long output. By creating platform resources in leaf node to root node order, the application eliminates cascading failures caused by upper-level indicators depending on lower-level indicators not being ready. By using supporting mechanisms such as global state recording compression context, pre-push unit calibration and duplicate name repair, post-push asynchronous state polling, and exception rollback recovery, the application guarantees the reliability and robustness of end-to-end automatic generation.

Description

Technical Field

[0001] This application relates to the field of big data platforms, and in particular to a method and system for generating industrial monitoring systems based on large language models. Background Technology

[0002] With the rapid development of industrial internet and digital twin technologies, building time-series data monitoring and visualization systems for specific business scenarios has become a key technology supporting digital transformation for industrial enterprises. These demonstration systems typically integrate core capabilities such as asset tree hierarchical modeling, time-series data simulation, key indicator analysis, alarm rule configuration, and visualization dashboards.

[0003] In traditional construction methods, technical personnel typically complete multiple stages manually, including scenario design, data modeling, indicator formula writing, alarm condition configuration, and dashboard setup. This approach is not only time-consuming for single-scenario delivery, but also prone to errors due to numerous cross-references between stages. Indicator formulas reference attribute identifiers of asset tree nodes, dashboard data sources are bound to indicator analysis task outputs, and alarm conditions rely on attribute values ​​for threshold judgments. Manual configuration is highly susceptible to inconsistencies in attribute names and misaligned references. The efficiency and accuracy of the entire demonstration system construction are highly dependent on the professional experience and meticulousness of the executors. Summary of the Invention

[0004] The purpose of this application is to provide a method and apparatus for generating an industrial monitoring system based on a large language model, which solves the problems of low efficiency and poor consistency in the manual construction of industrial demonstration systems.

[0005] To address the aforementioned technical problems, this application provides the following technical solutions: The first aspect of this application provides a method for generating an industrial monitoring system based on a large language model, the method comprising: The system receives a natural language scene description input by the user, calls the language model to generate a baseline design document, which includes the asset tree hierarchy, data collection specifications, key indicators for each level, alarm rules, key event definitions, and visualization panel requirements. After generation, the baseline design document is set to an immutable state, and the locked hierarchy and attribute definitions in the baseline design document are prohibited from being modified when the language model is called subsequently. Extract entity types from the asset tree hierarchy of the baseline design document, split the configuration file to be generated into multiple generation segments based on the entity types, call the language model segment by segment to generate the content of each segment and assemble them into a complete configuration file. The configuration file contains data table definitions and configuration rules for generating simulation data. Perform consistency verification on the assembled complete configuration file. After the verification passes, push it to the industrial data management platform, obtain the asset tree node identifier returned by the industrial data management platform, and generate simulation data based on the configuration rules. Based on the key indicators, alarm rules and key event definitions at each level defined in the benchmark design document, the language model is called to generate indicator calculation formulas, alarm conditions and key event triggering conditions; wherein, the attribute referenced in any indicator calculation formula or alarm condition belongs to the subtree of the current node. Based on the asset tree node identifiers, the hierarchical relationships in the benchmark design document, the associations between each node and the data table in the configuration file, the indicator calculation formulas, the alarm conditions, and the triggering conditions of the key events, indicator analysis tasks, alarm rules, and key events are created sequentially through the industrial data management platform interface in order from leaf nodes to root nodes; and after determining the type and data source of each visualization panel according to the visualization panel requirements in the benchmark design document, the visualization panels are created. Using the asset tree hierarchy and simulation data as the data foundation, a data query and event triggering channel is established between the indicator analysis task, the alarm rules, the key events, the visualization panel, and the corresponding nodes in the asset tree hierarchy. The visualization panel obtains calculation results from the simulation data through the indicator analysis task and displays them in chart form. The alarm rules generate alarm events when the simulation data meets the triggering conditions and display them in the alarm list. The key events are generated and displayed in the event list when the simulation data meets the triggering conditions. The resulting operational industrial monitoring system on the industrial data management platform is then output.

[0006] A second aspect of this application provides an industrial monitoring system generation system based on a large language model, the system comprising: The baseline design document generation module is used to receive natural language scene descriptions input by users, call the language model to generate a baseline design document, which includes the asset tree hierarchy, data collection specifications, key indicators at each level, alarm rules, key event definitions and visualization panel requirements; after generation, the baseline design document is set to an immutable state, and the locked hierarchy and attribute definitions in the baseline design document are prohibited from being modified when the language model is called subsequently. The configuration file generation module is used to extract entity types from the asset tree hierarchy of the baseline design document, split the configuration file to be generated into multiple generation segments according to the entity types, call the language model segment by segment to generate the content of each segment and splice them into a complete configuration file. The configuration file contains data table definitions and configuration rules for generating simulation data. The complete configuration file is subjected to consistency verification. After the verification is passed, it is pushed to the industrial data management platform. The module obtains the asset tree node identifier returned by the industrial data management platform and generates simulation data based on the configuration rules. The constraint generation module is used to generate indicator calculation formulas, alarm conditions, and key event triggering conditions by calling the language model based on the key indicators, alarm rules, and key event definitions defined in the benchmark design document. Among them, the attribute referenced in any indicator calculation formula or alarm condition belongs to the subtree of the current node. The platform resource creation module is used to create indicator analysis tasks, alarm rules, and key events sequentially through the industrial data management platform interface, based on the asset tree node identifiers, the hierarchical relationships in the benchmark design document, the association relationships between each node and the data table in the configuration file, as well as the indicator calculation formulas, alarm conditions, and triggering conditions of the key events, in order from leaf nodes to root nodes; and to create the visualization panels after determining the type and data source of each visualization panel according to the visualization panel requirements in the benchmark design document. The system output module is used to establish data query and event triggering channels between the indicator analysis task, the alarm rules, the key events, the visualization panel, and the corresponding nodes in the asset tree hierarchy, using the asset tree hierarchy and simulation data as the data foundation. The visualization panel obtains calculation results from the simulation data through the indicator analysis task and displays them in chart form. The alarm rules generate alarm events when the simulation data meets the triggering conditions and display them in the alarm list. The key events are generated and displayed in the event list when the simulation data meets the triggering conditions. The resulting operational industrial monitoring system on the industrial data management platform is then output.

[0007] Compared to existing technologies, the industrial monitoring system generation method and system based on a large language model provided in this application eliminates inconsistencies in attribute names and cross-reference errors in manual configuration from the source by locking a unique baseline design document and constraining subsequent models to perform only mapping execution, reducing the delivery time of the demonstration system from tens of man-hours to a few man-hours; by forcing attribute references to be limited to the current node subtree and performing reference validity checks, it effectively suppresses field illusions and cross-node misreferences in the large language model; it adopts a segmented generation and dual verification mechanism to avoid configuration file truncation and syntax corruption caused by single long output; it strictly creates platform resources according to the order from leaf node to root node, eliminating cascading failures caused by upper-level indicators depending on the incomplete lower-level indicators; at the same time, through supporting mechanisms such as global state recording and context compression, unit calibration and name duplication correction before push, asynchronous state polling after push, and abnormal rollback recovery, it further ensures the reliability and robustness of end-to-end automatic generation. Attached Figure Description

[0008] The above and other objects, features, and advantages of exemplary embodiments of this application will become readily understood by reading the following detailed description with reference to the accompanying drawings. In the drawings, several embodiments of this application are illustrated by way of example and not limitation, with the same or corresponding reference numerals denoteing the same or corresponding parts, wherein: Figure 1 A flowchart illustrating a method for generating industrial monitoring systems based on a large language model is shown schematically. Figure 2 A schematic diagram of the structure of an industrial monitoring system generation system based on a large language model is shown. Detailed Implementation

[0009] Exemplary embodiments of this application will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of this application are shown in the drawings, it should be understood that this application may be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided to enable a more thorough understanding of this application and to fully convey the scope of this application to those skilled in the art.

[0010] It should be noted that, unless otherwise stated, the technical or scientific terms used in this application shall have the ordinary meaning as understood by one of ordinary skill in the art to which this application pertains.

[0011] The methods described in the embodiments of this application will be explained in detail below.

[0012] This embodiment provides an automatic generation method for an industrial time-series data platform demonstration system based on a large language model. It can be applied to rapid proof-of-concept and demonstration environment construction in scenarios such as industrial monitoring, equipment maintenance, and structural health monitoring. This method is executed by electronic devices with data processing capabilities, including but not limited to servers, cloud inference nodes, desktop computers, embedded AI inference boxes, mobile terminals, or tablets. The overall flow of this embodiment's method is as follows: Figure 1 As shown, it includes the following steps: Step S110: Receive the natural language scene description input by the user, call the language model to generate a baseline design document. The baseline design document includes the asset tree hierarchy, data collection specifications, key indicators for each level, alarm rules, key event definitions, and visualization panel requirements. After generation, the baseline design document is set to an immutable state, and the locked hierarchy and attribute definitions in the baseline design document are prohibited from being modified when the language model is called subsequently.

[0013] This step is the starting point of the entire industrial time series data platform's automatic generation process. Its core task is to transform the unstructured natural language description input by the user into a structured benchmark design document that can be accurately referenced by downstream steps, and to ensure the consistency of this document throughout the entire process through a locking mechanism.

[0014] The baseline design document is configured according to a "unique baseline locking mechanism." Once generated, the baseline design document is locked and established as the "unique factual baseline" throughout the entire process. Under this mechanism, downstream modules only have read-only access to the document. The system combines prompt word constraints and code verification to limit the model's divergent output during subsequent generation processes, prohibiting modifications to established hierarchical definitions and attribute names. This design transforms the model's role in subsequent operations into that of an executor of baseline mapping, ensuring strict consistency between full configuration and the preceding design, and effectively blocking design drift paths from the workflow.

[0015] First, this step receives a natural language scenario description input from the user. Typical examples include "Generate a set of demonstration data and dashboards for the structural health monitoring of a key bridge group in a certain city" or "Generate a set of demonstration data and dashboards for the full-process monitoring of wastewater discharge from a chemical plant." This description is in text format and does not require the user to have any experience in configuring industrial platforms or programming skills.

[0016] The large language model is invoked to perform semantic parsing on the input natural language description. In this step, the large language model acts as a "scene parser and document generator," and its task is to transform the ambiguous natural language intent into a structured output that conforms to preset specifications.

[0017] The baseline design document generated by the large language model is a structured design specification document (such as Markdown format) that contains at least the following six parts: Asset tree hierarchical structure: Defines a multi-level topological relationship from the root node to the leaf nodes. Taking a bridge monitoring scenario as an example, the asset tree is usually divided into four levels: L1 is the bridge group level (e.g., "key bridge group in a certain city"), L2 is the single bridge level (e.g., "Bridge No. 1", "Bridge No. 2"), L3 is the subsystem level (e.g., "main beam", "bridge tower", "cable system", "support", "environmental monitoring", "operation and maintenance system"), and L4 is the measuring point / equipment level (e.g., "main beam strain measuring point S01", "main beam displacement measuring point D01", "bridge tower tilt measuring point T01", "cable force measuring point C01", "anemometer W01", etc.). Each node has a clear hierarchical relationship, and the leaf nodes (L4) are the end devices that actually generate the raw data.

[0018] Data Acquisition Specification: Define the physical quantity attributes acquired by each leaf node (measuring point / device). List the name, unit of measurement, acquisition frequency, and typical value range of each attribute in tabular form. For example, the attributes bound to a strain gauge include "strain" (unit με, acquisition frequency 5s) and "temperature" (unit °C, acquisition frequency 60s); the attributes bound to an anemometer include "wind speed" (unit m / s, acquisition frequency 1s) and "wind direction" (unit °, acquisition frequency 1s); the attribute bound to an online rate acquisition device includes "online rate" (unit %, acquisition frequency 60s). The attribute names in the data acquisition specification are the "predefined attribute titles" in subsequent steps, and all downstream indicator formulas and alarm conditions must reference these titles verbatim.

[0019] Key Indicators at Each Level: Define the calculation logic for aggregated indicators at each level. For example, key indicators for the L3 "Main Girder" node include "Maximum Strain of the Main Girder" (takes the maximum value of strain measurements from all L4 points) and "Average Displacement of the Main Girder" (takes the average value of displacement measurements from all L4 points); key indicators for the L2 "Bridge No. 1" node include "Overall Bridge Status" (aggregates indicators from all L3 subsystems); key indicators for the L1 "Bridge Group" node include "Overall Health of the Bridge Group" (aggregates indicators from all L2 individual bridges). Indicator definitions are described in natural language or pseudo-formula form, allowing subsequent steps to convert them into aggregated expressions executable by the industrial data management platform.

[0020] Alarm rules: Define the conditions for triggering an alarm, its duration, and severity level. For example, the alarm rule "Strong Wind Alarm" is triggered by "Wind speed > 35 m / s", lasts for 30 seconds, and has a severity level of "Major"; the alarm rule "Data Disconnection Alarm" is triggered by "Online rate < 80%", lasts for 300 seconds, and has a severity level of "Warning"; the alarm rule "Main Beam Strain Sudden Change Alarm" is triggered by "Strain > 800 με", lasts for 10 seconds, and has a severity level of "Emergency".

[0021] Critical Event Definition: Define the typical operating conditions that need to be captured and recorded, along with their triggering conditions. Unlike alarm rules, critical events focus on recording changes in operating conditions that have business analysis value, rather than simply triggering alarm notifications. For example, the triggering condition for a "strong wind event" is a wind speed exceeding 30 m / s for 60 seconds, used to record the complete period during which the bridge experiences strong winds; the triggering condition for a "main beam abnormal displacement event" is a vertical displacement of the main beam exceeding 20 mm, used to capture abnormal periods in the structural response; and the triggering condition for a "data interruption event" is an online rate drop of any measuring point to 0% for 120 seconds, used to record the occurrence and recovery process of data acquisition interruption. The critical event definition must include at least the event name, triggering conditions, and the event's distribution requirements across asset tree nodes (e.g., distribution across more than two leaf nodes).

[0022] Visualization Panel Requirements: Define the types, data sources, and display formats of visualization panels required at each level of the demonstration system, grouped and described according to the asset tree hierarchy. For example, L1 bridge group level panel requirements include "Overview of Overall Health of Bridge Group" (stat value card, data source is L1 key indicators) and "Status Distribution of Each Bridge" (bar chart, data source is the comprehensive status indicators of each L2 individual bridge); L2 single bridge level panel requirements include "Status Overview of Each Subsystem of a Single Bridge" (table data table, data source is the key indicators of all L3 subsystems under this bridge); L3 subsystem level panel requirements include "Main Girder Strain Trend Chart" (line graph, data source is the original data of each L4 strain measurement point under this main girder), "Main Girder Displacement Change" (line graph, data source is the original data of each L4 displacement measurement point under this main girder), and "Environmental Wind Speed ​​Monitoring" (gauge dashboard, data source is real-time data from an anemometer); L4 measurement point level panel requirements include "Measurement Point Online Rate Statistics" (state-history status history chart, data source is the historical data of the online rate collector). The panel requirements clearly define the data source binding relationships for each panel, so that subsequent steps can determine the panel type and create it accordingly.

[0023] Optionally, the baseline design document may also include a section titled "Survey Summary".

[0024] Research Summary: As a supplementary section to the baseline design document, this summary provides a general overview of the key design points for the entire industrial scenario. It includes a scenario overview, monitoring scale, main equipment types and quantities, total number of core physical quantities, hierarchical distribution of key indicators, number of alarm rules, number of key events, and panel requirements. This facilitates a quick grasp of the overall scenario for human reviewers and also provides a reference for the large language model to understand the overall scenario context in downstream steps. The research summary does not participate in the automated configuration mapping of subsequent steps; it serves only as a supplement to the document's completeness.

[0025] Once the baseline design document is generated, it is immediately placed into an immutable state. This "locking" operation involves two levels of constraints: At the document level, the baseline design document itself is marked as read-only and locked, and its original content cannot be modified by any downstream step.

[0026] At the behavioral level, the large language model invoked in subsequent steps is constrained by system prompts, limiting its role to the "mapping executor" of this baseline design document.

[0027] Specifically, in subsequent steps, when the large language model generates configuration files, index formulas, or alarm conditions, it is only permitted to extract defined hierarchical structures, attribute names, units, and collection frequencies from the benchmark design document and perform engineering mapping. The model is strictly prohibited from independently modifying or supplementing locked content. For example, the model must not arbitrarily rename "strain" to "micro-strain," must not adjust the hierarchical relationship of "main beam" to add an undefined subsystem under "main beam," and must not fabricate an attribute identifier that does not exist in the benchmark design document.

[0028] In this step, when calling the large language model, instead of simply using the brief scene description input by the user as prompts, a pre-defined structured skill description file (SKILL.md) is introduced. This file defines the calling constraints, output format, and validation rules of the large language model in this step. Specifically, step S110, when calling the language model to generate the baseline design document, will execute the following specific steps: When a language model is invoked, its invocation constraints, output format, and validation rules are defined by a pre-defined structured skill description file. The language model performs the generation operation under the constraints of the structured skill description file.

[0029] In this specific implementation, the structured skill description file is a structured prompt template written for the specific skill of "industrial scenario research and benchmark design document generation," and it contains at least the following structured prompt elements: Task Objective Statement: Clearly inform the large language model that its role in this step is an "industrial scenario analysis expert," and its task is to generate a complete scenario design document that conforms to industrial standards based on a brief scenario description input by the user and under the constraints of preset specifications.

[0030] Domain knowledge injection: The structured skill description file pre-contains domain knowledge references for common industrial scenarios, including but not limited to typical industry asset hierarchy patterns (such as the four-layer structure of "bridge group → single bridge → subsystem → measuring point" in bridge monitoring, and the five-layer structure of "plant area → workshop → process section → equipment → measuring point" in the chemical industry), common physical quantities and their standard units of measurement (such as strain / με, displacement / mm, pressure / MPa, flow rate / m³ / h, temperature / ℃), typical acquisition frequency ranges (such as high-speed vibration signals at the millisecond level, ambient temperature at the second to minute level, and online rate at the minute level), and industry-standard alarm threshold experience ranges. This domain knowledge is embedded in the prompt words in the form of structured constraints, enabling the large language model to "stand on the shoulders of domain experts" during generation, rather than relying solely on its general pre-trained knowledge.

[0031] Output format constraints: The structured skill description document mandates the output structure of the baseline design document, which can include the following seven sections: hierarchical structure (L1→L4 topology tree), data collection specifications (including four columns: name, unit, frequency, and typical value), key indicators for each level (with explicit citation format), alarm rules (including triggering conditions, duration, and severity level), key event definitions, visualization panel requirements (grouped by level), and survey summary. Each section provides detailed format templates and completion examples. The large language model is required to generate content within the template framework, rather than freely organizing the document structure.

[0032] Hierarchical Constraint Rules: The structured skill description file predefines hard constraints that the large language model must not violate when generating the asset tree, including: the depth of the tree does not exceed the preset maximum number of levels; child nodes under the same parent node must have unique names; leaf nodes must be attached to specific physical quantity attributes and the attribute type must match the device type of the node (e.g., a "wind speed sensor" node cannot be attached to a "strain" attribute); the number of child nodes of each non-leaf node must not exceed the preset fan-out limit.

[0033] Attribute Naming Conventions: Structured skill description documents mandate that all physical quantity attributes must use standardized full names (e.g., "strain" instead of "strain value," "vertical displacement" instead of "displacement"), and that units of measurement must use standard symbols (e.g., με instead of microstrain, m / s instead of meters per second). Data collection frequencies must be standardized to second-level values ​​(e.g., 5s, 60s, 300s). These conventions prevent cross-referencing errors caused by inconsistent naming in subsequent steps.

[0034] Once the large language model receives a brief scenario description from the user, the structured skill description file and the scenario description are injected into the large language model's context. When generating the baseline design document, the large language model's behavior is constrained by the following three levels: Structural constraints: The large language model is forced to organize its output according to the seven-chapter structure preset in the structured skill description document, and no chapters may be omitted or merged. The organizational form within each chapter (such as the four-column table of the data collection specification, the indented topology tree of the hierarchical structure) is also predefined by the structured skill description document, and the model only needs to fill in the specific content within the given framework.

[0035] Knowledge Layer Constraints: When determining the asset tree hierarchy, the large language model must refer to the pre-defined industry-typical hierarchy patterns in the structured skill description file, and select a matching hierarchy template by combining keywords in the user scenario description (e.g., "bridge group" corresponds to bridge monitoring mode, "sewage discharge" corresponds to chemical process mode). Appropriate customization adjustments should then be made under the constraints of this template. When determining attribute definitions, the correct attribute set must be attached to each leaf node according to the pre-defined physical quantity-equipment type matching relationship in the structured skill description file; attaching mismatched attribute types is prohibited.

[0036] Rule-based constraints: During the generation of the large language model, predefined hierarchical constraint rules and attribute naming conventions from the structured skill description file are applied as hard constraints to the model's decoding process. When generating each node name, attribute name, or unit of measurement, the candidate token space is restricted to valid values ​​conforming to the conventions. If the model tends to generate content that does not conform to the constraints (such as exceeding the maximum hierarchical depth or using non-standard unit symbols), the system directly blocks the violating tokens through the constraint decoding mechanism, forcing the model to resample.

[0037] Through the aforementioned triple constraint mechanism, the large language model can "expand" the user-described scenario into a complete, structurally standardized, and semantically consistent benchmark design document based on the brief scenario description input by the user, under the guidance and constraint of the structured skill description document, thus bridging the information gap between brief natural language and detailed industrial design documents.

[0038] In this embodiment, a global state recording mechanism is also designed. After the baseline design document is locked, a global state record is initialized based on the document's storage path and current execution state. This global state record can be represented as a JSON-formatted state file, whose initial structure includes a scene identifier, the storage path of the baseline design document, platform connection information, a current execution state flag, and reserved fields for outputs of subsequent steps. When subsequent steps call the large language model, only the field references related to the current step in the global state record are injected into the context, without retransmitting the original full text of the baseline design document, thus controlling the effective context length for each inference step.

[0039] In a specific implementation, this global state record can be represented as a JSON-formatted state file (such as state.json). Its initial structure includes the following key fields: scene identifier (scene_name, which records the name of the industrial scene described by the user, such as "bridge structure health monitoring"), storage path of the baseline design document (baseline_doc_path, which records the location of the locked baseline design document in the file system), platform connection information (platform_credentials, which records the URL and authentication credentials of the industrial data management platform), current execution status (current_step, which marks the current step as completed to step S110), and reserved fields for outputs of subsequent steps (step_outputs, which records intermediate results such as configuration file path and asset tree node identifier returned by the platform).

[0040] This global state record serves as a hub for information transmission in subsequent steps. When a subsequent step calls the large language model, only references to fields relevant to the current step (such as the baseline design document path and node identifiers) from the global state record are injected into the context, without retransmitting the original full text of the baseline design document. For example, when the large language model is called to generate the configuration file in step S120, only the storage path of the baseline design document is injected into the context. The model reads the document content itself through the path, rather than passing the entire baseline design document as input again. This mechanism keeps the effective context length for each large language model inference within a limited range, thus suppressing the token consumption inflation problem caused by the linear increase in context length as steps progress.

[0041] In a specific implementation, after calling the language model to generate the baseline design document, the process of generating the global state record can be performed by the following steps: Based on the storage path of the baseline design document and the current execution status, a global status record is initialized to transfer execution progress and intermediate results between each step.

[0042] When subsequent steps call the large language model, the complete documents generated in previous steps (such as the full text of the benchmark design document, complete configuration files, etc.) are no longer passed in as input again. Instead, only field references related to the current step are extracted from the global state record—such as the storage path of the benchmark design document, the asset tree node identifier returned by the target platform, etc.—and injected into the context of the large language model. The large language model locates and reads the required data itself through these field references, thereby controlling the effective context length of each inference within a limited range and avoiding the token consumption inflation problem caused by the linear growth of the context length as the process progresses. Therefore, in a specific implementation, the above mechanism can be executed as follows: When the language model is invoked, references to fields in the global state record relevant to the current step are injected into the context instead of retransmitting the original full text of the document generated by the previous step, so as to keep the effective context length for each inference within a limited range.

[0043] Based on this global state record, the system further supports the following anomaly recovery mechanisms: In this embodiment, an abnormal rollback and breakpoint recovery mechanism is also designed. During the serial execution of steps S110 to S150, if an execution abnormality occurs in any step and the abnormality cannot be automatically recovered by the retry strategy, such as continuous network interruption causing configuration file push failure, the target platform interface returning multiple non-retry error codes, or the large language model still failing the consistency check after multiple partial regenerations, this mechanism is triggered.

[0044] Specifically, the global state record continuously updates the current execution progress, completed step identifiers, and intermediate output results of each step (such as configuration file paths and asset tree node identifiers returned by the platform) during normal execution of each step. When an anomaly is determined to be unrecoverable automatically, the system, based on the execution progress and dependencies between steps recorded in the global state record, identifies the most recently successfully executed step as the rollback target, marks all subsequent steps after that step as unexecuted, releases allocated resources, and outputs diagnostic information to the user, explaining the cause of the anomaly and the rollback location.

[0045] Once the cause of the anomaly is eliminated (e.g., network recovery, platform interface restoration, or user manual configuration correction based on diagnostic information), the system resumes execution from the target rollback step when the recovery conditions are met. Because the global status record stores the intermediate execution results of each step, for sub-operations successfully completed before the rollback step (e.g., pushed super tables, created indicator analysis tasks, configured alarm rules, etc.), the system automatically identifies and skips them by reading checkpoint information from the global status record, avoiding re-execution and thus preventing the waste of time and computing resources caused by rerunning the entire process from scratch.

[0046] The above mechanism can be executed as follows: If any step fails to execute and cannot be automatically recovered, the execution progress and step dependencies recorded in the global state record are used to roll back to the step that was most recently marked as successfully executed in the global state record. Once the recovery conditions are met, execution will continue from that step, and sub-operations that have been successfully completed will be automatically skipped.

[0047] Step S120: Extract each entity type from the asset tree hierarchy of the baseline design document, split the configuration file to be generated into multiple generation segments according to the entity type, call the language model segment by segment to generate the content of each segment and splice them into a complete configuration file. The configuration file contains data table definitions and configuration rules for generating simulation data; perform consistency verification on the spliced ​​complete configuration file, and push it to the industrial data management platform after the verification passes. Obtain the asset tree node identifier returned by the industrial data management platform, and the industrial data management platform generates simulation data based on the configuration rules.

[0048] This step transforms the asset tree hierarchy and data acquisition specifications in the baseline design document locked in step S110 into an engineering configuration file that can be recognized and loaded by the industrial data management platform, and pushes it to the platform to generate simulation data, providing a data foundation and node location basis for the subsequent creation of indicators, alarms, events and panels.

[0049] First, the entity types of all leaf nodes are extracted from the asset tree hierarchy of the baseline design document, and duplicates are removed to form an entity type set. Taking a bridge monitoring scenario as an example, the entity types in the L4 leaf layer include: strain sensors, displacement sensors, tilt sensors, cable tension sensors, wind speed sensors, temperature sensors, and online rate data acquisition devices, totaling 7 categories. The cardinality of the entity type set determines the number of data tables in the configuration file. Each entity type corresponds to one data table (i.e., a super table in the industrial data management platform). Therefore, the number of intermediate generated segments is the cardinality of the entity type set.

[0050] Based on the entity type set, the complete configuration file to be generated is split into multiple generation segments: the first segment is the data source definition and the beginning part of the top-level data structure of the configuration file; each intermediate segment corresponds to the data table definition of each entity type in the asset tree hierarchy; the last segment is the closing part of the asset tree node hierarchy definition and the top-level data structure of the configuration file. The number of segments is the cardinality of the entity type set plus 2.

[0051] Each segment is generated sequentially by calling the large language model using a different write mode, and then incrementally concatenated into a complete configuration file. The first segment is generated in overwrite write mode, writing the data source definition and enabling the top-level data structure of the configuration file. The data source definition includes the connection parameters of the industrial data management platform (such as database address, port, authentication information, etc.). The starting part of the top-level data structure includes project metadata (such as scene name and version number in the info object), data source configuration (such as connection type and parameters in the datasource object), database declaration (such as database name in the database object), and the starting syntax identifier of the data table array (such as "supertables": [).

[0052] Each intermediate segment is generated sequentially in append-only mode, with each segment corresponding to a data table definition for a specific entity type in the asset tree hierarchy. When generating each intermediate segment, all physical quantity attributes (including attribute name, data type, and unit of measurement) bound to that entity type are extracted from the data acquisition specifications in the baseline design document, forming a field whitelist for the current segment. This whitelist constrains the large language model to output the corresponding data table column definitions (columns array) within the whitelist range. For example, the data table corresponding to a strain sensor contains two data columns: "Strain" (float type, unit με) and "Temperature" (float type, unit °C); the data table corresponding to a wind speed sensor contains two data columns: "Wind Speed" (float type, unit m / s) and "Wind Direction" (float type, unit °). Each data table also contains a tag column (tags) for association with asset tree nodes, such as equipment number and installation location. When generating each intermediate segment, the array separator at the end of the previous segment serves as the syntax concatenation point, ensuring the syntactic continuity of the concatenated data table array.

[0053] The final section is generated in append mode, writing the asset tree node hierarchy definition and closing the top-level data structure of the configuration file. The asset tree node hierarchy definition (tree node) contains the complete hierarchical relationship from the root node to each leaf node. Each node definition includes the node name, node type, parent node reference, associated data table name, and a list of attributes bound to the node. After the final section is generated, the data table array and the top-level JSON object are closed sequentially to form a syntactically complete configuration file.

[0054] In this step, when the large language model is invoked to generate each segment of content, the calling constraints, output format, and validation rules of the large language model are all defined by a pre-defined structured skill description file. This structured skill description file is a structured prompt template written for the specific skill of "Industrial Data Platform Asset Configuration File Generation," and it contains at least the following structured prompt elements: task objective statement (clearly informing the model that the task of this step is to convert the entity types and data collection specifications in the baseline design document into data table definitions and asset tree node definitions for the target platform), input parameter definition (specifying the fields extracted from the baseline design document and global status records), output format constraints (mandating the JSON schema of each segment's output, including the column array format of the data table definition, the nested structure of asset tree nodes, etc.), quality validation rules (defining the judgment criteria and triggering conditions for syntax structure validation and reference relationship validation), and error handling strategy (defining the local regeneration rules and field whitelist injection methods when validation fails). The large language model performs the generation operation under the constraints of this structured skill description file, ensuring that the output content of each segment maintains strict consistency with the baseline design document in terms of format, semantics, and reference relationships.

[0055] In this embodiment, the configuration file to be generated is split into multiple generation segments according to the entity type, which can be performed in the following three steps: The first segment is generated using the beginning of the top-level data structure of the data source definition and configuration file as the first segment, in an overwrite write mode. The data table definition corresponding to each entity type in the asset tree hierarchy is defined as an intermediate segment, and generated segment by segment in append write mode; The asset tree node hierarchy definition and top-level structure closure are used as the final segment, generated in append write mode.

[0056] After all segments are concatenated into a complete configuration file, two-level consistency checks are performed sequentially.

[0057] The first level is syntax structure validation: JSON parsing is performed on the concatenated complete configuration file to check for syntax errors such as mismatched parentheses, missing commas, unclosed strings, and improperly terminated arrays. If the parsing process is interrupted at a certain byte offset, the corresponding generated segment is located backwards from that offset and marked as a syntax-damaged segment.

[0058] The second level is reference relationship verification: Based on the data collection specifications and asset tree hierarchy in the baseline design document, a mapping table between nodes and attributes is constructed. The attribute list (attributes array) and data table references (superTable field) of all asset tree nodes in the configuration file are traversed. Each attribute name is verified to exist in the column definition of the corresponding data table, and each data table reference is verified to point to a defined data table in the data table array. If an attribute name is found to be absent from its corresponding data table, or if a data table reference points to an undefined data table, the reference is marked as a dangling reference, and the relevant generation segment is located.

[0059] When any level of validation identifies a failed segment, the large language model is regenerated only for that failed segment. During regeneration, a whitelist of valid fields for the current segment and a description of the failure reason are injected into the large language model. Segments that have passed validation remain unchanged and are not involved in the regeneration. This mechanism of partial rollback and constraint regeneration avoids the uncertainty diffusion and computational resource waste caused by full regeneration.

[0060] In this embodiment, the consistency check of the assembled complete configuration file can be performed in the following two steps: Perform syntax structure validation on the assembled complete configuration file, and verify the legality of the data table definitions and reference relationships between asset tree nodes in the configuration file based on the data collection specifications and asset tree hierarchy in the benchmark design document; When any level of validation locates a failed segment, the language model is regenerated only for that failed segment. During regeneration, a whitelist of valid fields for the current segment is injected into the language model, while segments that have passed validation remain unchanged.

[0061] After the configuration file is loaded, the industrial data management platform automatically generates historical simulation data based on the data table definitions and configuration rules used to generate simulation data in the configuration file. The configuration rules include the time range of the simulation data (e.g., 30 days), the sampling interval (consistent with the sampling frequency of each attribute in the data acquisition specification, such as 5 seconds, 10 seconds, 60 seconds, etc.), the numerical distribution parameters of each attribute (e.g., mean, variance, fluctuation range), and the data injection strategy for simulating abnormal operating conditions. The generated simulation data is stored in various data tables and associated with asset tree nodes through label columns, providing a dynamic data source for subsequent steps such as indicator calculation, alarm judgment, and visualization.

[0062] In this application embodiment, a preprocessing mechanism for pushing data to an industrial data management platform is also designed to solve the problem that the configuration file push is rejected by the target platform due to missing units of measurement or equipment naming conflicts.

[0063] This mechanism is executed after the configuration file passes consistency verification and before it is officially pushed to the industrial data management platform. It includes the following two preprocessing operations: The first step is unit calibration: Iterate through the unit fields of each data table in the configuration file (i.e., the unit field of each column in the columns array), query the unit table of the industrial data management platform one by one, and for units of measurement that do not exist in the platform's unit table (such as "με" commonly seen in bridge monitoring scenarios), call the unit creation interface of the industrial data management platform to complete the registration, ensuring that the target platform has complete unit definitions when pushing.

[0064] Secondly, automatic name conflict repair: The device nodes in the asset tree hierarchy are traversed in breadth-first order to check for duplicate device nodes. For naming conflicts that may occur for similar measurement points (such as multiple "strain measurement points" existing in different subsystems), a unique alternative name is automatically generated according to the rule of "parent node name-device name-serial number" (such as "main beam-strain measurement point-01", "main beam-strain measurement point-02", "bridge tower-strain measurement point-01"). The repaired name is then written back to the global status record for reference in subsequent steps.

[0065] In a specific implementation, the above mechanism can be obtained by performing the following two steps: Iterate through the unit of measurement fields in each data table of the configuration file, and for units of measurement that do not exist in the unit of measurement table of the industrial data management platform, call the unit of measurement creation interface of the industrial data management platform to complete the registration. The device nodes in the asset tree hierarchy are traversed in breadth-first order. For device nodes with the same name, a unique alternative name is automatically generated according to the rule of "parent node name-device name-serial number".

[0066] In this embodiment of the application, an asynchronous loading status polling and confirmation mechanism is also designed to solve the problem of uncertain data activation timing caused by the asynchronous loading method after the industrial data management platform receives the configuration file push. This avoids subsequent steps from starting to create resources such as indicators and alarms before the platform data has been fully loaded, thus preventing cascading failures.

[0067] After preprocessing, the complete configuration file is pushed to the industrial data management platform. Since the industrial data management platform typically uses an asynchronous loading mechanism, the interface returns a status code immediately upon receiving the request, but actual data loading takes time. Therefore, asynchronous loading status polling is initiated after the push: the loading status query interface of the industrial data management platform is periodically called at preset time intervals (e.g., 60 seconds), and subsequent steps only proceed after confirming a loading completion status (e.g., COMPLETED). If loading is not completed after exceeding the preset maximum number of retries (e.g., 5 times), the current task is marked as pending and written to the global status record, the process is terminated, and diagnostic information is output to the user explaining the timeout reason and current progress.

[0068] After loading is complete, obtain the unique identifier (Node ID) assigned to each asset tree node by the industrial data management platform. These identifiers are used as the location basis when creating indicator analysis tasks, alarm rules, key events, and visualization panels via API in subsequent steps. Write the obtained asset tree node identifiers and their corresponding hierarchical relationships into the global status record for reference in steps S130 and S140.

[0069] In a specific implementation, the above mechanism can be obtained by performing the following two steps: Poll the loading status query interface of the industrial data management platform to confirm that loading is complete before proceeding to the next step; If loading is not completed after exceeding the preset maximum number of retries, the current task will be marked as pending and the process will be terminated.

[0070] Step S130: Based on the key indicators, alarm rules and key event definitions at each level defined in the baseline design document, call the language model to generate indicator calculation formulas, alarm conditions and key event triggering conditions; wherein, the attribute referenced in any indicator calculation formula or alarm condition belongs to the subtree of the current node.

[0071] This step is based on the key indicators, alarm rules, and key event definitions at each level in the baseline design document locked in step S110. Under strict restrictions on the scope of attribute references, the large language model is called to generate indicator calculation formulas, alarm condition expressions, and key event triggering conditions that can be directly executed on the industrial data management platform. The legality of attribute references in the generated results is verified to ensure the semantic correctness and reference compliance of each formula and condition.

[0072] This step is based entirely on three core elements from the baseline design document. Specifically, the key indicators at each level define the aggregated indicators to be calculated for each asset tree node and their business implications (e.g., the "maximum strain of the main beam" for the L3 "main beam" node); the alarm rules define the trigger threshold, duration, and severity level for each alarm (e.g., the condition for a "strong wind alarm" is "wind speed > 35 m / s"); and the key event definitions define the typical operating conditions to be captured and their triggering logic (e.g., the trigger condition for a "strong wind event" is a wind speed exceeding 30 m / s for 60 seconds). The task of the large language model is to transform this business logic, described in natural language or pseudo-formula form, into structured expressions that the industrial data management platform API can parse and execute.

[0073] When generating the above content in the large language model, a strict attribute reference range restriction is enforced: any attribute referenced in an indicator calculation formula or alarm condition must have its definition node located within the current asset tree node itself or its child nodes, and cannot reference attributes of sibling nodes or nodes across paths. This constraint prevents errors from occurring during the generation process of the large language model. For example, when generating an aggregation formula for the L3 "main beam" node, the model can only reference the attributes of each L4 measuring point under that main beam node (such as the "strain" of the main beam strain measuring point S01 and the "vertical displacement" of the main beam displacement measuring point D01), and cannot reference the cable force or inclination attributes under the sibling node "bridge tower" subtree, nor can it reference attributes under other subtrees of the parent node "bridge 1".

[0074] To eliminate ambiguity in attribute references at the source, all attribute references in the indicator calculation formulas and alarm conditions generated by the large language model must adopt a strong reference format that is identical to the predefined attribute titles in the baseline design document's data collection specification. This strong reference format uses a predefined fixed syntax template (e.g., ${attributes['<predefined title>']}). The model is only allowed to fill in the attribute name that exactly matches the data collection specification in the identifier slot of the template; it is not allowed to abbreviate, rewrite, or substitute synonyms. For example, if the attribute name defined in the data collection specification is "strain," then the formula generated by the model must be written as ${attributes['strain']}, and cannot be changed to ${attributes['strain value']} or ${attributes['micro-strain']}.

[0075] In this embodiment, taking a bridge monitoring scenario as an example, the large language model generates the following content based on the benchmark design document: Regarding the calculation formulas for indicators: At the L4 measuring point level, since the measuring points directly collect raw data, aggregation formulas are usually unnecessary, and the attribute values ​​are directly output as indicators. At the L3 subsystem level, the formula for generating aggregation formulas such as "maximum strain of the main beam" is max(${attributes['strain']}), and the "strain" attribute referenced belongs to each L4 strain measuring point under the main beam node, which conforms to the subtree range constraint. The formula for "average displacement of the main beam" is avg(${attributes['vertical displacement']}), and the "vertical displacement" attribute referenced belongs to each L4 displacement measuring point under the main beam node. At the L2 single bridge level, higher-level aggregation formulas such as "overall status of Bridge No. 1" are generated, and their aggregation scope covers the indicators of all L3 subsystems under that bridge. At the L1 bridge group level, global aggregation formulas such as "overall health of the bridge group" are generated, and their aggregation scope covers the indicators of all L2 single bridges.

[0076] Regarding alarm conditions: Alarm condition expressions are generated as follows: ${attributes['wind speed']} > 35 (corresponding to "Strong Wind Alarm", lasting 30 seconds, severity level "Major"), ${attributes['Online Rate']} < 80 (corresponding to "Data Disruption Alarm", lasting 300 seconds, severity level "Warning"), ${attributes['Strain']} > 800 (corresponding to "Main Beam Strain Sudden Change Alarm", lasting 10 seconds, severity level "Emergency"). The "wind speed", "online rate", and "strain" attributes referenced in these alarm conditions all belong to the subtree range of their respective nodes.

[0077] Regarding the triggering conditions for critical events: generate event triggering conditions such as "wind speed continuously exceeds 30m / s for 60 seconds" (corresponding to "strong wind event"), "vertical displacement of main beam exceeds 20mm" (corresponding to "abnormal displacement of main beam event"), and "online rate of any measuring point drops to 0% for 120 seconds" (corresponding to "data interruption event"), and specify the distribution requirements of the event on each asset tree node in the event definition.

[0078] After the large language model generates all formulas and conditions, the system performs a reference closure check on the generated results. The check process includes two dimensions: First, an existence check, which extracts all attribute reference identifiers in each formula and alarm condition, and performs an exact match search in the legal reference symbol table of the corresponding node. This symbol table is jointly constructed by the data collection specifications of the benchmark design document in step S110 and the asset tree hierarchy, and contains all defined attribute identifiers within the subtree of the current node; Second, a legality check, which traces the definition node of each reference identifier in the asset tree to confirm that the definition node is indeed within the subtree of the node to which the current formula belongs.

[0079] If all formulas and conditions pass existence and attribution validity checks, the generated result of that node is marked as passed and proceeds to the next step. If any reference fails the check, the node is marked as a validation failure, triggering a local regeneration of the corresponding content. During regeneration, the system forcibly injects a whitelist of valid attribute identifiers for the current node and its child nodes into the large language model. The model is regenerated under the constraints of this whitelist, and the regenerated result undergoes reference closure validation again until all pass. This closed-loop mechanism of "constraint generation → validation → failure regeneration and whitelist injection" effectively suppresses field illusions and cross-node misreferences that may occur during the generation process of the large language model, ensuring the absolute correctness of each formula and condition in terms of semantics and reference relationships.

[0080] In this step, when calling the large language model to generate indicator calculation formulas, alarm conditions, and triggering conditions for key events, the calling constraints, output format, and verification rules of the large language model are also defined by the preset structured skill description file. This structured skill description file is a structured prompt template written for the specific skill of "industrial scenario indicator and alarm generation". It contains at least the following structured prompt elements: task objective statement (clearly informing the model that the task of this step is to transform the business logic described in natural language or pseudo-formula in the benchmark design document into a structured expression that can be executed by the industrial data management platform), attribute reference format specification (mandating that all attribute references must adopt the strong reference format of ${attributes['<predefined title>']}, and the referenced attribute identifier must be consistent with the predefined title in the data collection specification word for word), reference scope constraint (clearly limiting attribute references to the current node subtree range, prohibiting cross-node or cross-path references), output format constraint (mandating the output structure of indicator calculation formulas and alarm conditions, including fields such as aggregate function type, calculation window parameters, alarm threshold, duration and severity level), and error handling strategy (defining the local regeneration rules and the whitelist injection method of legal attribute identifiers when the reference legality verification fails). The large language model performs generation operations under the constraints of the structured skill description file, ensuring that every generated formula and condition conforms to the specifications of the baseline design document in terms of syntactic structure, attribute references, and business semantics.

[0081] Step S140: Based on the asset tree node identifier, the hierarchical relationship in the benchmark design document, the association relationship between each node and the data table in the configuration file, as well as the indicator calculation formula, alarm conditions and key event triggering conditions, create indicator analysis tasks, alarm rules and key events sequentially through the industrial data management platform interface in the order from leaf node to root node; and create visualization panels after determining the type and data source of each visualization panel according to the visualization panel requirements in the benchmark design document.

[0082] Before execution, this step gathers key data from multiple sources: Step S120 obtains the unique identifiers (Node IDs) assigned to each asset tree node by the industrial data management platform and the association relationships between each node and data table in the configuration file; Step S130 obtains the verified indicator calculation formulas, alarm conditions, and triggering conditions for key events; and the hierarchical relationships and visualization panel requirements are obtained from the baseline design document. This data collectively constitutes the request parameters and location basis for subsequent API calls.

[0083] The aggregation of indicators in the industrial asset tree has a clear directionality; the aggregated indicators of upper-level nodes depend on the data or calculation results of lower-level nodes. Therefore, this step strictly follows the order of creating resources from leaf nodes to root nodes: first, create L4 measurement point-level indicator tasks, then sequentially create L3, L2, and L1 level aggregation indicator tasks, ensuring that the lower-level indicators referenced by each upper-level node already exist when it is created. The creation of alarm rules and critical events also follows this order. Through this sequential constraint, the cascading creation failure caused by inverted reference dependencies is eliminated from the mechanism.

[0084] Following a leaf-to-root order, indicator analysis tasks at each level are created sequentially through the industrial data management platform interface, using the indicator calculation formulas generated in step S130 as request parameters. Simultaneously, alarm rules are created, configuring alarm condition expressions as trigger rules and setting duration and severity levels. Similarly, the creation of critical events involves configuring the event trigger conditions generated in step S130 onto designated nodes. During creation, when the platform interface returns an abnormal error code, adaptive fault tolerance processing is performed according to preset error code classification rules: for errors that do not support calculated attributes, the alarm rule is moved down to the leaf node and recreated; for errors with incompatible interface types, the system automatically switches to an alternative interface for retry.

[0085] After the indicator analysis tasks, alarm rules, and key events are created, the type definitions and data source binding relationships of each panel are extracted according to the visualization panel requirements in the baseline design document. Visualization panels at each level are then created, and the panel data sources are bound to the corresponding indicator analysis tasks. Panel types cover various visualization formats, including stat cards, line charts, bar charts, and gauge dashboards.

[0086] Step S150: Using the asset tree hierarchy and simulation data as the data foundation, establish data query and event triggering channels between the indicator analysis tasks, alarm rules, key events, and visualization panels and the corresponding nodes in the asset tree hierarchy; the visualization panels obtain calculation results from the simulation data through the indicator analysis tasks and display them in chart form; alarm rules generate alarm events when the simulation data meets the triggering conditions and display them in the alarm list; key events are generated and displayed in the event list when the simulation data meets the triggering conditions; the resulting operational industrial monitoring system is output on the industrial data management platform.

[0087] This step is the final output of the entire automatic generation process. Its core task is to establish a runtime association between all the static resource configurations, indicator analysis tasks, alarm rules, key events and visualization panels created in the previous steps and the asset tree hierarchy and simulation data already in place on the industrial data management platform, so as to make it an interactive and dynamically operating industrial monitoring demonstration system.

[0088] The indicator analysis tasks, alarm rules, key events, and visualization panels created in the previous steps were independent at creation and had not yet formed a closed data flow loop. In this step, the system establishes data query and event triggering channels for corresponding nodes in the resource and asset tree hierarchy: a query association is established between the indicator analysis tasks and the simulation data table to periodically read raw data and perform aggregation calculations; a data binding is established between the visualization panel and the indicator analysis tasks to drive chart rendering with calculation results; a monitoring association is established between alarm rules and corresponding attribute data to continuously monitor simulation data and trigger conditions; and a detection association is established between key events and data streams to automatically capture and record specified operating conditions. After the runtime associations are established, the demonstration system enters a runnable state. The visualization panel periodically obtains calculation results from the indicator analysis tasks and displays them in chart form; alarm rules continuously monitor simulation data, and automatically generate alarm events and display them in the alarm list when the data meets the trigger conditions, including information such as alarm time, level, and trigger conditions; key events generate event records and display them in the event list when the simulation data meets the corresponding trigger conditions, providing users with a complete post-event analysis basis for operating conditions.

[0089] It should be noted that in the demonstration system generated in this embodiment, the data read by each indicator analysis task, alarm rule, and key event comes from the simulation data automatically generated by the industrial data management platform based on configuration rules in step S120. This simulation data is simulated historical data automatically generated by the platform according to the attribute names, units of measurement, collection frequency, and typical value range defined in the data collection specifications in the benchmark design document, and is used to simulate the operating status of real industrial equipment in the demonstration scenario.

[0090] When this embodiment is applied to a real industrial production environment, the simulation data will be replaced with actual operational data collected in real time and written to the industrial data management platform by devices such as sensors, programmable logic controllers (PLCs), supervisory control and data acquisition (SCADA) systems, or IoT gateways in the industrial field. Since the asset tree hierarchy, data table definitions, indicator calculation formulas, alarm rules, and visualization panels generated in the preceding steps are decoupled from specific data sources—that is, these configurations only define "how the data is organized, how it is calculated, and how it is displayed"—without binding the "source" of the data, when switching from the demonstration system to the real production system, only the data source needs to be replaced with the actual collected data; no reconfiguration of the generated asset tree structure, indicator analysis tasks, alarm rules, and visualization panels is required.

[0091] This application eliminates inconsistencies in attribute names and cross-reference errors in manual configuration from the source by locking a unique baseline design document and constraining subsequent models to perform only mapping execution, reducing the delivery time of the demonstration system from tens of man-hours to a few man-hours. By forcing attribute references to be limited to the current node's subtree and performing reference validity checks, it effectively suppresses field illusions and cross-node misreferences in large language models. It adopts a segmented generation and dual verification mechanism to avoid configuration file truncation and syntax corruption caused by single long outputs. It strictly creates platform resources in the order from leaf nodes to root nodes, eliminating cascading failures caused by upper-level metrics depending on lower-level metrics not being ready. At the same time, through supporting mechanisms such as global state recording and context compression, pre-push unit calibration and name duplication correction, asynchronous state polling after push, and abnormal rollback recovery, it further ensures the reliability and robustness of end-to-end automatic generation.

[0092] Based on the same inventive concept, as an implementation of the above-mentioned method for generating industrial monitoring systems based on large language models, this application also provides an industrial monitoring system generation system based on large language models. Figure 2 This is a structural diagram of the system in an embodiment of this application. See also... Figure 2 As shown, the system may include: The baseline design document generation module is used to receive natural language scene descriptions input by users, call the language model to generate baseline design documents, which include asset tree hierarchy, data collection specifications, key indicators for each level, alarm rules, key event definitions and visualization panel requirements. After generation, the baseline design document is set to an immutable state, and the locked hierarchy and attribute definitions in the baseline design document are restricted from being modified when the language model is called in the future. The configuration file generation module extracts entity types from the asset tree hierarchy of the baseline design document, splits the configuration file to be generated into multiple generation segments based on the entity type, calls the language model segment by segment to generate the content of each segment, and splices them into a complete configuration file. The configuration file contains data table definitions and configuration rules for generating simulation data. The module performs a consistency check on the spliced ​​complete configuration file. After the check passes, it is pushed to the industrial data management platform to obtain the asset tree node identifier returned by the industrial data management platform. The industrial data management platform then generates simulation data based on the configuration rules. The constraint generation module is used to generate indicator calculation formulas, alarm conditions, and key event triggering conditions by calling the language model based on the key indicators, alarm rules, and key event definitions defined in the baseline design document. Among them, the attribute referenced in any indicator calculation formula or alarm condition belongs to the subtree of the current node. The platform resource creation module is used to create indicator analysis tasks, alarm rules, and key events sequentially through the industrial data management platform interface, based on the asset tree node identifiers, the hierarchical relationships in the benchmark design document, the association relationships between each node and the data table in the configuration file, as well as the indicator calculation formulas, alarm conditions, and trigger conditions for key events, in order from the leaf node to the root node; and to create visualization panels after determining the type and data source of each visualization panel according to the visualization panel requirements in the benchmark design document. The system output module uses the asset tree hierarchy and simulation data as the data foundation to establish data query and event triggering channels between indicator analysis tasks, alarm rules, key events, and visualization panels and corresponding nodes in the asset tree hierarchy. The visualization panel obtains calculation results from the simulation data through indicator analysis tasks and displays them in chart form. Alarm rules generate alarm events when the simulation data meets the triggering conditions and display them in the alarm list. Key events are generated and displayed in the event list when the simulation data meets the triggering conditions. The resulting operational industrial monitoring system on the industrial data management platform is then output.

[0093] This application eliminates inconsistencies in attribute names and cross-reference errors in manual configuration from the source by locking a unique baseline design document and constraining subsequent models to perform only mapping execution, reducing the delivery time of the demonstration system from tens of man-hours to a few man-hours. By forcing attribute references to be limited to the current node's subtree and performing reference validity checks, it effectively suppresses field illusions and cross-node misreferences in large language models. It adopts a segmented generation and dual verification mechanism to avoid configuration file truncation and syntax corruption caused by single long outputs. It strictly creates platform resources in the order from leaf nodes to root nodes, eliminating cascading failures caused by upper-level metrics depending on lower-level metrics not being ready. At the same time, through supporting mechanisms such as global state recording and context compression, pre-push unit calibration and name duplication correction, asynchronous state polling after push, and abnormal rollback recovery, it further ensures the reliability and robustness of end-to-end automatic generation.

[0094] This application also provides an electronic device, comprising: a processor, a memory, and a computer program stored in the memory and executable on the processor, such as a program for a method for generating an industrial monitoring system based on a large language model. When the processor executes the computer program, it implements all the steps in the aforementioned method for generating an industrial monitoring system based on a large language model, such as S110 to S150 and their sub-steps. Alternatively, when the processor executes the computer program, it implements the functions of each module / unit in the aforementioned system embodiments.

[0095] For example, the computer program may be divided into one or more modules / units, which are stored in the memory and executed by the processor to complete this application. The one or more modules / units may be a series of computer program instruction segments capable of performing a specific function, which describe the execution process of the computer program in the electronic device.

[0096] The electronic device may be a computing device such as a server or cloud server deployed in an industrial monitoring system based on a large language model. The electronic device may include, but is not limited to, processors and memory. Those skilled in the art will understand that the above components are merely examples of electronic devices and do not constitute a limitation on the electronic device. It may include more or fewer components than described above, or a combination of certain components, or different components. For example, the electronic device may also include data acquisition cards and output cards for connecting sensors and actuators, network communication devices, buses, etc.

[0097] The processor can be a central processing unit, or other general-purpose processors, digital signal processors, application-specific integrated circuits (ASICs), off-the-shelf programmable gate arrays (OPGs) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor can be a microprocessor or any conventional processor. The processor is the control center of the electronic device, connecting various parts of the entire electronic device via various interfaces and lines.

[0098] The memory can be used to store the computer programs and / or modules. The processor implements various functions of the electronic device by running or executing the computer programs and / or modules stored in the memory and by calling data stored in the memory. The memory may mainly include a program storage area and a data storage area. The program storage area may store the operating system, at least one application program required for a function, etc.; the data storage area may store data created according to system usage, etc. In addition, the memory may include high-speed random access memory, and may also include non-volatile memory, such as hard disk, RAM, plug-in hard disk, smart memory card, secure digital card, flash memory card, at least one disk storage device, flash memory device, or other volatile solid-state storage device.

[0099] Wherein, if the modules / units integrated in the electronic device are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, all or part of the processes in the methods of the above embodiments can also be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable medium can include: any entity or device capable of carrying the computer program code, a recording medium, a USB flash drive, a portable hard drive, a magnetic disk, an optical disk, a computer memory, a read-only memory, a random access memory, an electrical carrier signal, a telecommunication signal, and a software distribution medium, etc.

[0100] Obviously, those skilled in the art can make various modifications and variations to this application without departing from the spirit and scope of this application. Therefore, if such modifications and variations fall within the scope of the claims of this application and their equivalents, this application also intends to include such modifications and variations.

Claims

1. A method for generating an industrial monitoring system based on a large language model, characterized in that, The method includes: The system receives a natural language scene description input by the user, calls the language model to generate a baseline design document, which includes the asset tree hierarchy, data collection specifications, key indicators for each level, alarm rules, key event definitions, and visualization panel requirements. After generation, the baseline design document is set to an immutable state, and the locked hierarchy and attribute definitions in the baseline design document are prohibited from being modified when the language model is called subsequently. Extract entity types from the asset tree hierarchy of the baseline design document, split the configuration file to be generated into multiple generation segments based on the entity types, call the language model segment by segment to generate the content of each segment and assemble them into a complete configuration file. The configuration file contains data table definitions and configuration rules for generating simulation data. Perform consistency verification on the assembled complete configuration file. After the verification passes, push it to the industrial data management platform, obtain the asset tree node identifier returned by the industrial data management platform, and generate simulation data based on the configuration rules. Based on the key indicators, alarm rules and key event definitions at each level defined in the benchmark design document, the language model is called to generate indicator calculation formulas, alarm conditions and key event triggering conditions; wherein, the attribute referenced in any indicator calculation formula or alarm condition belongs to the subtree of the current node. Based on the asset tree node identifiers, the hierarchical relationships in the benchmark design document, the associations between each node and the data table in the configuration file, the indicator calculation formulas, the alarm conditions, and the triggering conditions of the key events, indicator analysis tasks, alarm rules, and key events are created sequentially through the industrial data management platform interface in order from leaf nodes to root nodes; and after determining the type and data source of each visualization panel according to the visualization panel requirements in the benchmark design document, the visualization panels are created. Using the asset tree hierarchy and simulation data as the data foundation, a data query and event triggering channel is established between the indicator analysis task, the alarm rules, the key events, the visualization panel, and the corresponding nodes in the asset tree hierarchy. The visualization panel obtains calculation results from the simulation data through the indicator analysis task and displays them in chart form. The alarm rules generate alarm events when the simulation data meets the triggering conditions and display them in the alarm list. The key events are generated and displayed in the event list when the simulation data meets the triggering conditions. The resulting operational industrial monitoring system on the industrial data management platform is then output.

2. The method according to claim 1, characterized in that, After the language model is invoked to generate the baseline design document, the method includes: Based on the storage path of the benchmark design document and the current execution status, a global status record is initialized to transmit execution progress and intermediate results between each step.

3. The method according to claim 2, characterized in that, After initializing a global state record, the method further includes: When the language model is invoked, references to fields in the global state record relevant to the current step are injected into the context instead of retransmitting the original full text of the document generated by the previous step, so as to keep the effective context length of each inference within a limited range.

4. The method according to claim 2, characterized in that, The method further includes: If any step fails to execute and cannot be automatically recovered, the execution progress and step dependencies recorded in the global state record are used to revert to the step that was most recently marked as successfully executed in the global state record. Once the recovery conditions are met, execution will continue from that step, and sub-operations that have been successfully completed will be automatically skipped.

5. The method according to claim 1, characterized in that, The step of splitting the configuration file to be generated into multiple generation segments based on the entity type includes: The first segment is generated using the beginning of the top-level data structure of the data source definition and configuration file as the first segment, in an overwrite write mode. The data table corresponding to each entity type in the asset tree hierarchy is defined as an intermediate segment, and generated segment by segment in append write mode. The asset tree node hierarchy definition and top-level structure closure are used as the final segment, generated in append write mode.

6. The method according to claim 1, characterized in that, The consistency check performed on the concatenated complete configuration file includes: Perform syntax structure verification on the assembled complete configuration file, and verify the legality of the data table definitions and the reference relationships between asset tree nodes in the configuration file based on the data collection specifications and asset tree hierarchy in the benchmark design document. When any level of validation locates a failed segment, the language model is regenerated only for that failed segment. During regeneration, a whitelist of valid fields for the current segment is injected into the language model, while segments that have passed validation remain unchanged.

7. The method according to claim 1, characterized in that, Before pushing the configuration file to the industrial data management platform, the method further includes: Iterate through the unit of measurement fields of each data table in the configuration file, and for units of measurement that do not exist in the unit of measurement table of the industrial data management platform, call the unit of measurement creation interface of the industrial data management platform to complete the registration. The device nodes in the asset tree hierarchy are traversed in breadth-first order. For device nodes with duplicate names, a unique alternative name is automatically generated according to the rule of "parent node name-device name-serial number".

8. The method according to claim 1, characterized in that, After pushing the configuration file to the industrial data management platform, the method further includes: The loading status query interface of the industrial data management platform is polled to confirm that loading is complete before proceeding to the next step; If loading is not completed after exceeding the preset maximum number of retries, the current task will be marked as pending and the process will be terminated.

9. The method according to claim 1, characterized in that, The method further includes: When a language model is invoked, the invocation constraints, output format, and validation rules of the language model are defined by a preset structured skill description file, and the language model performs a generation operation under the constraints of the structured skill description file.

10. An industrial monitoring system generation system based on a large language model, characterized in that, The system includes: The baseline design document generation module is used to receive natural language scene descriptions input by users, call the language model to generate a baseline design document, which includes the asset tree hierarchy, data collection specifications, key indicators at each level, alarm rules, key event definitions and visualization panel requirements; after generation, the baseline design document is set to an immutable state, and the locked hierarchy and attribute definitions in the baseline design document are prohibited from being modified when the language model is called subsequently. The configuration file generation module is used to extract entity types from the asset tree hierarchy of the baseline design document, split the configuration file to be generated into multiple generation segments according to the entity types, call the language model segment by segment to generate the content of each segment and splice them into a complete configuration file. The configuration file contains data table definitions and configuration rules for generating simulation data. The complete configuration file is subjected to consistency verification. After the verification is passed, it is pushed to the industrial data management platform. The module obtains the asset tree node identifier returned by the industrial data management platform and generates simulation data based on the configuration rules. The constraint generation module is used to generate indicator calculation formulas, alarm conditions, and key event triggering conditions by calling the language model based on the key indicators, alarm rules, and key event definitions defined in the benchmark design document. Among them, the attribute referenced in any indicator calculation formula or alarm condition belongs to the subtree of the current node. The platform resource creation module is used to create indicator analysis tasks, alarm rules, and key events sequentially through the industrial data management platform interface, based on the asset tree node identifiers, the hierarchical relationships in the benchmark design document, the association relationships between each node and the data table in the configuration file, as well as the indicator calculation formulas, alarm conditions, and triggering conditions of the key events, in order from leaf nodes to root nodes; and to create the visualization panels after determining the type and data source of each visualization panel according to the visualization panel requirements in the benchmark design document. The system output module is used to establish data query and event triggering channels between the indicator analysis task, the alarm rules, the key events, the visualization panel, and the corresponding nodes in the asset tree hierarchy, using the asset tree hierarchy and simulation data as the data foundation. The visualization panel obtains calculation results from the simulation data through the indicator analysis task and displays them in chart form. The alarm rules generate alarm events when the simulation data meets the triggering conditions and display them in the alarm list. The key events are generated and displayed in the event list when the simulation data meets the triggering conditions. The resulting operational industrial monitoring system on the industrial data management platform is then output.

Images