Industrial configuration method and system based on model driving

Abstract

The invention provides an industrial configuration method and system based on model driving, the system comprises a domain model layer, a model conversion engine, a code generator and a configuration engine, the domain model layer determines related data of a preset industrial scene, and configures the related data to construct a layered and executable domain model system; the focus points of the configuration in the preset industrial scene are separated; the model conversion engine configures corresponding target engine resources and a target predefined rule base according to the domain model system; the code generator automatically converts the domain model system into a specific and executable configuration project file according to the target engine resource and the target predefined rule base; the configuration project file comprises a code and a configuration file; and the configuration engine deploys the configuration project file to a target configuration software operation environment corresponding to the preset industrial scene to obtain target industrial configuration software. According to the scheme, the implementation efficiency of the industrial configuration software can be improved.

Description

Technical Field

[0001] This application relates to the fields of industrial automation and information technology, and in particular to a model-driven industrial configuration method and system. Background Technology

[0002] Industrial configuration software is often considered the core of the "host computer" of industrial control systems. It can be used to monitor, operate, and manage industrial production processes.

[0003] Traditional industrial configuration methods are typically based on graphical drag-and-drop and manual configuration, and are highly dependent on human experience. As a result, the configuration process heavily relies on the engineer's personal experience and understanding of specific processes. Configuration projects completed by different engineers vary greatly in structure, style and quality, making standardization and reuse difficult. In other words, the implementation efficiency of industrial configuration software is low. Summary of the Invention

[0004] This application provides a model-driven industrial configuration system and method that can reduce reliance on human experience, automate and intelligently generate industrial configuration software, and improve the efficiency of industrial configuration software implementation.

[0005] On one hand, embodiments of this application provide a model-driven industrial configuration system, which includes: a domain model layer, a model conversion engine, a code generator, and a configuration engine, wherein... The domain model layer is used to determine relevant information for a preset industrial scenario and configure the relevant information to construct a hierarchical, executable domain model system to separate the concerns configured in the preset industrial scenario. The model conversion engine is used to configure corresponding target engine resources and target predefined rule base according to the domain model system; The code generator is used to automatically convert the domain model system into a specific, executable configuration project file based on the target engine resources and the predefined rule base; the configuration project file includes code and configuration files; The configuration engine is used to deploy the configuration engineering file to the target configuration software runtime environment corresponding to the preset industrial scenario, thereby obtaining the target industrial configuration software.

[0006] Secondly, embodiments of this application provide a model-driven industrial configuration method applied to a model-driven industrial configuration system. The model-driven industrial configuration system includes: a domain model layer, a model conversion engine, a code generator, and a configuration engine. The model-driven industrial configuration method includes: The relevant data of the preset industrial scenario is determined through the domain model layer, and the relevant data is configured to construct a hierarchical and executable domain model system to separate the configuration concerns in the preset industrial scenario; The model conversion engine configures the corresponding target engine resources and target predefined rule library according to the domain model system. The code generator automatically converts the domain model system into a specific, executable configuration project file based on the target engine resources and the predefined rule base; the configuration project file includes code and configuration files. The configuration engineering file is deployed to the target configuration software runtime environment corresponding to the preset industrial scenario through the configuration engine to obtain the target industrial configuration software.

[0007] The embodiments of this application have the following beneficial effects: By implementing the embodiments of this application, a model-driven industrial configuration system includes: a domain model layer, a model conversion engine, a code generator, and a configuration engine. The domain model layer is used to determine relevant data for a preset industrial scenario and configure this data to construct a hierarchical, executable domain model system, thereby separating the configuration concerns within the preset industrial scenario. The model conversion engine is used to configure corresponding target engine resources and target predefined rule bases according to the domain model system. The code generator is used to automatically convert the domain model system into specific, executable configuration project files based on the target engine resources and target predefined rule bases. The configuration project files include code and configuration files. The configuration engine is used to deploy the configuration project files to the target configuration software runtime environment corresponding to the preset industrial scenario, obtaining the target industrial configuration software. This allows for the construction of a hierarchical, executable domain model system, separation of configuration concerns, and, through model conversion technology, automatic conversion of high-level abstract business models into low-level technical implementation models, ultimately generating deployable configuration projects. This reduces reliance on manual experience, automates and intelligentizes the generation of industrial configuration software, and improves the implementation efficiency of industrial configuration software. Attached Figure Description

[0008] To more clearly illustrate the technical solutions of the embodiments of this application, the drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0009] Figure 1A This is a system architecture diagram of a model-driven industrial configuration system provided in an embodiment of this application; Figure 1BThis is a schematic diagram of the domain model layer in a model-driven industrial configuration system provided in an embodiment of this application; Figure 1C This is another system architecture diagram of a model-driven industrial configuration system provided in the embodiments of this application; Figure 1D This is a schematic diagram of the system execution flow of a model-driven industrial configuration system provided in an embodiment of this application; Figure 2 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application; Figure 3 This is a schematic flowchart of a model-driven industrial configuration method provided in an embodiment of this application. Detailed Implementation

[0010] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of the present application.

[0011] The terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish different objects, not to describe a specific order. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or apparatus that includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to these processes, methods, products, or apparatuses.

[0012] It should be understood that the term "and / or" in this document is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. Additionally, the character " / " in this document indicates that the preceding and following related objects are in an "or" relationship. In the embodiments of this application, "multiple" refers to two or more.

[0013] In the embodiments of this application, "at least one item" or its similar expression refers to any combination of these items, including any combination of a single item or a plurality of items. "One or more" means one or more, while "multiple" means two or more. For example, "at least one item" of a, b, or c can represent the following seven cases: a, b, c; a and b; a and c; b and c; a, b, and c. Each of a, b, and c can be an element or a set containing one or more elements.

[0014] In this application, the term "connection" refers to various connection methods, such as direct connection or indirect connection, to achieve communication between devices. This application does not impose any limitations on this.

[0015] In this document, the term "embodiment" means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0016] In this application embodiment, the electronic device may include a model-driven industrial configuration system, which may include at least one of the following: server, smart car, industrial robot, industrial control platform, industrial machine tool, etc., without limitation.

[0017] In related technologies, traditional industrial configuration methods are mainly based on graphical drag-and-drop and manual configuration, which have the following significant drawbacks: A. Highly dependent on human experience Specifically, the configuration process heavily relies on the engineer's personal experience and understanding of specific processes. Configuration projects completed by different engineers will vary greatly in structure, style and quality, making them difficult to standardize and reuse.

[0018] B. Low development efficiency and long development cycle

[0019] Specifically, from requirements analysis, graphical interface design, data point binding, logic programming to debugging and deployment, each step requires a significant amount of manual work. This is especially true when dealing with complex or similar projects, where repetitive tasks are common and efficiency is low.

[0020] C. Difficult to maintain, poor consistency

[0021] Specifically, when the process flow changes or equipment is upgraded, it is necessary to manually modify the graphical interface, control logic, database tables, and other related parts, which is prone to omissions or errors and results in high maintenance costs. The control logic and data relationships behind the graphical interface are implicit and difficult to understand and trace directly.

[0022] D. Difficulty in accumulating knowledge and assets

[0023] Specifically, excellent process design and operational experience cannot be effectively preserved in a digital and reusable form; instead, they are lost as personnel leave.

[0024] While the "model-driven" approach has been applied in some software engineering fields, in the industrial configuration field, most so-called model-driven approaches only remain at the level of equipment data models. They fail to integrate and hierarchically model and automatically convert process flows, operational logic, and human-machine interfaces, thus failing to fundamentally solve the aforementioned problems. Therefore, there is an urgent need in this field for a new configuration method that can automate, standardize, and reuse knowledge in configuration work.

[0025] To achieve the above objectives, this application provides a model-driven industrial configuration system, which includes: a domain model layer, a model conversion engine, a code generator, and a configuration engine, wherein... The domain model layer is used to determine relevant information for a preset industrial scenario and configure the relevant information to construct a hierarchical, executable domain model system to separate the concerns configured in the preset industrial scenario. The model conversion engine is used to configure corresponding target engine resources and target predefined rule base according to the domain model system; The code generator is used to automatically convert the domain model system into a specific, executable configuration project file based on the target engine resources and the predefined rule base; the configuration project file includes code and configuration files; The configuration engine is used to deploy the configuration engineering file to the target configuration software runtime environment corresponding to the preset industrial scenario, thereby obtaining the target industrial configuration software.

[0026] In this embodiment of the application, the core concept of the model-driven industrial configuration system is to construct a hierarchical and executable domain model system, separate the configuration concerns, and automatically convert the high-level abstract business model into a low-level technical implementation model through model conversion technology, and finally generate a deployable configuration project.

[0027] For easier understanding, please refer to Figure 1A , Figure 1A This application provides a system architecture diagram of a model-driven industrial configuration system, which includes: a domain model layer, a model conversion engine, a code generator, and a configuration engine. The domain model layer is used to determine relevant information for a preset industrial scenario and configure the relevant information to construct a hierarchical, executable domain model system to separate the concerns configured in the preset industrial scenario. The model conversion engine is used to configure corresponding target engine resources and target predefined rule base according to the domain model system; The code generator is used to automatically convert the domain model system into a specific, executable configuration project file based on the target engine resources and the predefined rule base; the configuration project file includes code and configuration files; The configuration engine is used to deploy the configuration engineering file to the target configuration software runtime environment corresponding to the preset industrial scenario, thereby obtaining the target industrial configuration software.

[0028] The system architecture of a model-driven industrial configuration system can mainly include: a domain model layer, a model conversion engine, a code generator, and a configuration engine. The domain model layer, model conversion engine, code generator, and configuration engine can all be software or hardware modules, and they can be electrically connected and / or communicatively connected.

[0029] Among them, the model-driven industrial configuration system can be used for model-driven design, development and implementation of industrial configuration software.

[0030] The preset industrial scenarios can be pre-set or set by system default, and can be configured based on requirements. For example, preset industrial scenarios may include reactor feed control.

[0031] In practice, big data can be used to determine relevant information for a preset industrial scenario. For example, keywords related to the preset industrial scenario can be obtained, and a search can be performed on the preset database based on the keywords to obtain relevant information for the preset industrial scenario. Then, the requirements of the preset industrial scenario (e.g., product form, process flow, etc.) can be preset, and relevant information can be configured to build a hierarchical and executable domain model system to separate the concerns configured in the preset industrial scenario.

[0032] In practice, the model conversion engine can configure the corresponding target engine resources and target predefined rule base according to the domain model system. That is, based on a clear domain model system, the corresponding engine template can be selected, and the corresponding predefined rule base can be configured based on the corresponding hierarchical structure of the domain model system.

[0033] In its implementation, the code generator can automatically convert the domain model system into specific, executable configuration project files based on the target engine resources and the target predefined rule library. These configuration project files include code and configuration files. For example, users can complete or import models at various levels defined in the domain model layer using graphical tools. Then, the model conversion engine automatically converts high-level models into low-level models according to predefined rules (target predefined rule library). Based on the final configuration data model and graphical interface description, the code generator generates project files specific to the target configuration software platform, including but not limited to: database scripts, control logic programs, graphical display files, alarm and report configurations.

[0034] In practice, the configuration engine can deploy the configuration project file to the target configuration software runtime environment corresponding to the preset industrial scenario to obtain the target industrial configuration software.

[0035] Construct a layered, executable domain model system, separate the configuration concerns, and use model conversion technology to automatically convert the high-level abstract business model into a low-level technical implementation model, ultimately generating a deployable configuration project.

[0036] By implementing the embodiments of this application, a model-driven industrial configuration system includes: a domain model layer, a model conversion engine, a code generator, and a configuration engine. The domain model layer is used to determine relevant data for a preset industrial scenario and configure this data to construct a hierarchical, executable domain model system, thereby separating the configuration concerns within the preset industrial scenario. The model conversion engine is used to configure corresponding target engine resources and target predefined rule bases according to the domain model system. The code generator is used to automatically convert the domain model system into specific, executable configuration project files based on the target engine resources and target predefined rule bases. The configuration project files include code and configuration files. The configuration engine is used to deploy the configuration project files to the target configuration software runtime environment corresponding to the preset industrial scenario, obtaining the target industrial configuration software. This allows for the construction of a hierarchical, executable domain model system, separation of configuration concerns, and, through model conversion technology, automatic conversion of high-level abstract business models into low-level technical implementation models, ultimately generating deployable configuration projects. This reduces reliance on manual experience, automates and intelligentizes the generation of industrial configuration software, and improves the implementation efficiency of industrial configuration software.

[0037] Optionally, the domain model layer includes at least: a process logic model, a functional design model, and a human-computer interaction model; In constructing a hierarchical, executable domain model system based on the configured relevant data, the following aspects are included: The process logic model is used to determine the business logic used to describe the industrial process in the preset industrial scenario based on the relevant data. The functional design model is used to instantiate the process logic model to bind it to a specific equipment type; The human-computer interaction model is used to determine visualization configuration parameters related to the preset industrial scenario based on the relevant data. The visualization configuration parameters include at least one of the following: the structure of the monitoring screen, style guidelines, screen elements, and mapping rules of elements in the functional design model.

[0038] In specific implementation, such as Figure 1B As shown, the domain model layer includes at least: a process logic model, a functional design model, and a human-computer interaction model. The process logic model, functional design model, and human-computer interaction model can all be software modules or hardware modules. The process logic model, functional design model, and human-computer interaction model can be electrically connected and / or communication connected.

[0039] In practice, when building a domain-specific model, at least three levels of domain models can be established: process logic model, functional design model, and human-computer interaction model.

[0040] Specifically, the process logic model can be used to describe the business logic of an industrial process, independent of the specific implementation platform. For example, the process logic model can define process units (such as reactors, pumps, valves, etc.), material flows, energy flows, control strategies (such as sequential control, interlocking control), and topological relationships between units based on the scenario requirements of a pre-defined industrial scenario. The process logic model can be described using a domain-specific language based on a meta-model or a UML configuration file.

[0041] Specifically, the functional design model can instantiate the process logic model. For example, it can bind specific equipment types (such as "centrifugal pump type A"), I / O signal points (such as DI / DO / AI / AO), alarm parameters, and basic control algorithms (such as PID regulation). This functional design model can be platform-independent but equipment-dependent.

[0042] Specifically, for the human-computer interaction model, it can define the structure and style guidelines of the monitoring screen, as well as the mapping rules between screen elements (such as symbols, trend charts, and alarm windows) and elements in the functional design model. For example, the functional design model can specify "how to display" rather than "what to draw specifically".

[0043] In specific implementation, the process logic model can determine the business logic used to describe the industrial process in the preset industrial scenario based on relevant data, while the functional design model can instantiate the process logic model to bind specific equipment types, and the human-computer interaction model can determine the visualization configuration parameters related to the preset industrial scenario based on relevant data. The visualization configuration parameters include at least one of the following: the structure of the monitoring screen, style guidelines, screen elements, and mapping rules of elements in the functional design model. That is, the corresponding functions and related structures of the process logic model, functional design model, and human-computer interaction model can constitute a hierarchical and executable domain model system.

[0044] Optionally, in configuring the corresponding target engine resources and target predefined rule base according to the domain model system, the model conversion engine is specifically used for: Obtain the number of layers and scale of the domain model system; The target engine resources corresponding to the preset industrial scenario are determined based on the number of layers and the scale. Configure the target predefined rule base according to the domain model system.

[0045] In specific implementation, the number of layers and scale of the domain model system can be obtained, and the target engine resources corresponding to the preset industrial scenario can be determined according to the number of layers and scale. That is, the appropriate engine resources can be adapted "according to local conditions" based on the model hierarchy and scale to avoid poor engine resources or waste. Then, the target predefined rule library can be configured according to the domain model system, that is, the predefined rule library can be adaptively scheduled according to the model hierarchy to achieve hierarchical predefined rule library scheduling.

[0046] Optionally, the target predefined rule base includes a first predefined rule base, a second predefined rule base, and a third predefined rule base; in configuring the target predefined rule base according to the domain model system, the model conversion engine is specifically used for: The first predefined rule base is determined based on the process logic model; The second predefined rule base is determined based on the functional design model; A third predefined rule base is determined based on the human-computer interaction model.

[0047] The first, second, and third predefined rule bases can all be preset or set by system default. For example, in this embodiment, a series of model conversion rules can be predefined when establishing the model conversion rule base.

[0048] In practice, a first predefined rule base can be determined based on the model structure and corresponding functions of the process logic model, a second predefined rule base can be determined based on the model structure and corresponding functions of the functional design model, and a third predefined rule base can be determined based on the model structure and corresponding functions of the human-computer interaction model.

[0049] In practice, the process logic model can correspond to the conversion rules of the functional design model. For example, the "feed pump" in the process logic can be automatically mapped to the specific "pump control function block" in the functional design model, and default I / O points such as start / stop and fault states can be assigned to it.

[0050] In practice, the functional design model can correspond to the conversion rules of the configuration data model. Specifically, the elements in the functional design model can be converted into intermediate representations of data point tables, device communication configurations, and control logic scripts (such as ST and IL languages) that can be recognized by specific configuration software platforms (such as WinCC, iFix, KingSCADA, etc.).

[0051] In practical implementation, the human-computer interaction model and the functional design model can correspond to the conversion rules described in the graphical interface. Specifically, based on the style and mapping rules defined in the human-computer interaction model, specific monitoring screen files (such as XML, HTML5 Canvas descriptions, etc.) can be automatically generated, and screen elements can be bound to data points in the configuration data model.

[0052] Optionally, the model-driven industrial configuration system further includes an update unit, wherein, The update unit is used to determine the corresponding target fine-tuning parameters when the graphics or parameters are fine-tuned in the configuration interface of the target industrial configuration software during operation, determine the corresponding target system update parameters according to the target fine-tuning parameters, and update the target system update parameters in reverse to the corresponding functional design model or human-computer interaction model.

[0053] Among them, such as Figure 1C As shown, the model-driven industrial configuration system also includes an update unit, which can be a software module or a hardware module. The update unit can be electrically connected and / or communicatively connected to other modules in the model-driven industrial configuration system.

[0054] In this embodiment of the application, the engineering deployment and reverse synchronization functions can also be realized. The generated configuration engineering file is deployed to the target configuration software runtime environment and a two-way synchronization mechanism is provided. When the graphics or parameters are fine-tuned in the configuration interface during runtime, the system can reverse update these changes to the corresponding functional design model or human-computer interaction model, maintain the consistency between the model and the runtime engineering, and realize "the model is the truth".

[0055] In practice, when fine-tuning graphics or parameters in the configuration interface of the target industrial configuration software during runtime, the corresponding target fine-tuning parameters can be determined. Then, the corresponding target system update parameters can be determined based on the target fine-tuning parameters, and the target system update parameters can be updated in reverse to the corresponding functional design model or human-computer interaction model. In this way, the consistency between the model and the runtime engineering is maintained, and the "model is the truth" is realized.

[0056] Compared with solutions in related technologies, this solution has the following significant advantages: 1. Significantly improves efficiency and quality by automating the entire process from process design to code generation, freeing engineers from repetitive manual configuration and shortening project development cycles by more than 50%. Automated generation avoids human error and ensures consistent project quality.

[0057] 2. It achieves standardization and knowledge reuse, as the domain model itself serves as a carrier of enterprise standards, best practices, and knowledge. New projects can be quickly built by reusing and adapting existing domain models, greatly promoting knowledge accumulation and standardization.

[0058] 3. Lowering the technical threshold and maintenance costs allows process engineers to focus more on modeling business logic (process logic model) without needing to delve into the complex technical details of configuration software. When the process changes, only the top-level model needs to be modified and regenerated to quickly complete the engineering update, making maintenance simple and accurate.

[0059] 4. Enhance system flexibility and traceability. The models are linked through conversion rules, ensuring that any modification can be clearly traced back to its impact. As a core asset, the model makes the system more adaptable to migrations across different configuration software platforms or technical architectures.

[0060] For example, Figure 1D As shown, the starting point (modeling) is where the entire process begins with domain experts or engineers using a graphical modeling tool developed based on this method to perform business modeling. The core model layer is the cornerstone of this solution. Users need to build three core models: Process logic model: describes "what to do".

[0061] Functional design model: describes "what to do with".

[0062] Human-computer interaction model: describes "how to display".

[0063] In practice, the system undergoes automated conversion and generation: the model conversion engine automatically converts high-level domain models into specific, executable configuration project files (such as database scripts, screen files, control logic, etc.) based on a predefined rule base. Deployment and operation: the generated project files are deployed to a standard configuration software runtime environment, and the system begins formal operation.

[0064] Furthermore, this solution also provides bidirectional synchronization. Specifically, when system fine-tuning is required during runtime, the process determines the nature of the change. If it's a business logic change: it's strongly recommended to return to the model layer for modification and then regenerate to ensure consistency across all parts, reflecting the core idea of ​​"model-driven" development. If it's purely a minor UI display adjustment (such as moving icon positions), the system can capture this change and update it in the human-computer interaction model, thus maintaining consistency between the design model and the running system and solving the problem of "model and code disconnect" in traditional model-driven development.

[0065] In practice, domain experts / engineers use graphical tools to model and obtain the process logic model (describes business logic and processes), functional design model (binds specific equipment and I / O), and human-computer interaction model (defines interface style and rules) of the domain model layer (design phase). During code generation and deployment, the process logic model, functional design model, and human-computer interaction model use corresponding conversion rules to schedule the model conversion engine to generate configuration engineering files (data point tables, control logic, graphical interface, etc.), which are then deployed to the configuration software runtime environment for formal system operation and monitoring.

[0066] Furthermore, during runtime fine-tuning (such as modifying parameters or graphical positions), it is determined whether the change involves business logic. If not, the graphical interface-level fine-tuning is recorded, and the human-computer interaction mechanism is updated synchronously to keep the model consistent with the runtime environment. If so, it is recommended to modify the model and regenerate the implementation.

[0067] The system in this embodiment is a closed-loop system with a domain model as its core, automatic generation as its means, and bidirectional synchronization as its guarantee, which greatly improves the efficiency, standardization, and maintainability of industrial configuration.

[0068] In practical implementation, the basic technical architecture of the system can be based on the following technology stack, as follows: Modeling Tool Layer: Develop desktop or web-based graphical modeling tools based on the Eclipse Modeling Framework (EMF). Use GMF or Sirius frameworks to create domain-specific graphical model editors. Model Layer: Use EMF's Meta-Object Facility (Ecore) to define the process logic meta-model, functional design meta-model, and human-machine interaction meta-model. Model files are stored in XMI format. Model Transformation Engine: Use model transformation languages ​​and engines such as Eclipse's ATL (AtlasTransformation Language) or QVT (Query / View / Transformation). Transformation rules are written as .asm or .qvto files. Code Generator: Use template engines such as Eclipse Acceleo or Apache Velocity to generate specific code and configuration files based on the model. Target Platform: Use mainstream configuration software such as Siemens WinCC OA or Rockwell FactoryTalkView as the target runtime environment.

[0069] In practical implementation, a domain meta-model can be defined. For example, three core meta-models need to be defined first: process logic meta-model, functional design meta-model, and human-computer interaction meta-model.

[0070] Specifically, for the process logic meta-model, the core concepts are defined as: ProcessUnit, MaterialFlow, and ControlRecipe. ProcessUnit includes attributes: id, name, and type (e.g., Reactor, Pump). ControlRecipe includes: Step and TransitionCondition (e.g., "Level > 50%").

[0071] Specifically, for the functional design metamodel, the core concepts are defined as follows: FunctionalDevice, IOChannel, and ControlAlgorithm. FunctionalDevice inherits from ProcessUnit and adds the following attributes: controllerAddress and ioChannels (a list of associated I / O channels). ControlAlgorithm can be PIDAlgorithm (PID algorithm) or MotorStarter (motor starter), and includes specific parameters.

[0072] Specifically, for the human-computer interaction meta-model, the core concepts are defined as: HMIView (view), HMISymbol (symbol), and DataBinding (data binding). HMISymbol contains the following attributes: svgTemplatePath (the path to the corresponding SVG graphic template) and bindings (a list that defines which graphic attribute of the symbol, such as fill color, and which variable of the functional device it is bound to, such as running status).

[0073] To illustrate further, taking "reactor feed control" as an example for instantiated modeling, the user can create the following model instance using graphical tools: First, create the process logic model: Drag and drop a ProcessUnit from the toolbar, setting its type to Reactor and its id to R101. Drag and drop another ProcessUnit, setting its type to Pump and its id to P101. Create a MaterialFlow that points from P101 to R101. Create a ControlRecipe for R101 named "Feed Recipe," containing the following steps: Step 1: Start P101 (Start P101 pump), Transfer condition T1: R101.Level > 90%.

[0074] Secondly, a functional design model is created: the tool automatically instantiates R101 and P101 in the process logic model as FunctionalDevice. The user binds an AIChannel (analog input channel) to R101, named LT101, representing a level transmitter. A DOChannel (digital output channel) is bound to P101, named MV101, representing a motor starter. A basic MotorStarter control algorithm is assigned to P101.

[0075] Next, create the human-computer interaction model: the user defines an HMIView named "Reactor Unit Screen". Drag and drop a ReactorSymbol from the symbol library onto the screen and associate its dataBinding with the functional device R101. This means that the symbol will automatically display data from R101.

[0076] Similarly, drag and drop a PumpSymbol and associate it with P101.

[0077] To illustrate further, the rule configuration for the transformation between configuration and execution models is as follows: The conversion rules are pre-defined in the system. For example, a rule for translating a process logic model into a functional design model can be described as follows: Rule name: ProcessUnit2FunctionalDevice Element: ProcessUnit (type='Pump') Target element: FunctionalDevice, and automatically add a MotorStarter control algorithm to it and reserve 2 DI points (run, failure) and 1 DO point (startup).

[0078] Execute the conversion: The user clicks the "Generate" button on the tool interface. The following process occurs in the background: The model conversion engine loads the process logic model and conversion rules.

[0079] The engine recognizes P101 (of type Pump), triggers the ProcessUnit2FunctionalDevice rule, generates a corresponding FunctionalDevice instance, and completes the initial configuration.

[0080] Next, the conversion rule from Functional Design Model to Configuration Data Model is triggered, converting FunctionalDevice and its IOChannel and ControlAlgorithm into the intermediate data structure required by the target configuration software (such as a list of data points in a JSON structure).

[0081] To illustrate further, regarding code generation: The code generator calls the Acceleo template preset for WinCC OA. After traversing and transforming the template, the resulting configuration data model generates a line of code in a WinCC OA PDE file (device database import file) for each data point. For example: DP1: "P101", "Start_Cmd", "1" / / Digital point, DO number 1 DP2: "P101", "Running_Status", "1" / / Digital point, DI number 1 Simultaneously, based on the human-machine interaction model and the graphic template, a WinCC OA screen file (.xml format) is generated, containing a pump icon whose "color" attribute is dynamically bound to data point P101.Running_Status.

[0082] To illustrate further, regarding deployment and reverse synchronization: Deployment: The generated PDE files and screen files are automatically packaged. Users can deploy using the tool's one-click deployment function or by copying the files to the corresponding directory of the WinCC OA project. Upon restarting the configuration software, the automatically generated screens and data structures will be displayed. Regarding reverse synchronization: Suppose an operator finds the pump icon's position on the running screen unsatisfactory and simply drags it to a new location. This system embeds a "change capture agent" during configuration software operation. This agent records such modifications to the interface layout. When an engineer selects the "synchronize" function in the design tool, the tool connects to the running system and retrieves these layout change records.

[0083] The tool will automatically update the coordinate attributes of the corresponding PumpSymbol in the local human-computer interaction model.

[0084] Consequently, the result is as follows: when the project is regenerated from the model the next time, the pump icon will appear in the new position without losing this manual adjustment. This solves the core pain point of "disconnect between the design-phase model and the runtime instance" in model-driven development. For more important modifications such as control parameters, the system will force modifications to the functional design model to ensure consistency.

[0085] The following is combined Figure 2 The electronic devices in the embodiments of this application will be described. Figure 2 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. The electronic device includes one or more processors, a memory, a communication interface, and one or more programs. The processor is connected to the memory and the communication interface through an internal communication bus. The electronic device is applied to a model-driven industrial configuration system. The model-driven industrial configuration system includes: a domain model layer, a model conversion engine, a code generator, and a configuration engine.

[0086] It is understood that the electronic device may include more or fewer structural elements than those shown in the above block diagram. For example, the electronic device may also include at least one of the following modules: a Bluetooth module, a sensor, a Wi-Fi module, a power module, physical buttons, a speaker, a display module, etc., without limitation. The electronic device may be equipped with... Figure 1A , Figure 1C The system architecture described above.

[0087] The processor can be used for: The relevant data of the preset industrial scenario is determined through the domain model layer, and the relevant data is configured to construct a hierarchical and executable domain model system to separate the configuration concerns in the preset industrial scenario; The model conversion engine configures the corresponding target engine resources and target predefined rule library according to the domain model system. The code generator automatically converts the domain model system into a specific, executable configuration project file based on the target engine resources and the predefined rule base; the configuration project file includes code and configuration files. The configuration engineering file is deployed to the target configuration software runtime environment corresponding to the preset industrial scenario through the configuration engine to obtain the target industrial configuration software.

[0088] The one or more programs are stored in the aforementioned memory and configured to be executed by the aforementioned processor, and the one or more programs include instructions for performing any step in the above method embodiments.

[0089] The processor can be a central processing unit (CPU), an application-specific integrated circuit (ASIC), a general-purpose processor, a digital signal processor (DSP), a field-programmable gate array (FPGA), or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof.

[0090] Furthermore, the processor can also implement or execute various exemplary logic blocks, units, and circuits described in conjunction with the disclosure of this application. Additionally, the processor can also be a combination of components implementing computational functions, such as a combination of one or more microprocessors, a combination of a DSP and a microprocessor, etc. Communication units can be communication interfaces, transceivers, transceiver circuits, etc., and storage units can be memory.

[0091] The memory can be volatile or non-volatile, or may include both. The non-volatile memory can be a programmable read-only memory (PROM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), or flash memory.

[0092] Furthermore, the volatile memory can be random access memory (RAM), which serves as an external cache. By way of example, but not limitation, many forms of random access memory (RAM) are available, such as double data rate synchronous dynamic random access memory (DDR SDRAM), enhanced synchronous dynamic random access memory (ESDRAM), static RAM (SRAM), synchronous dynamic random access memory (SDRAM), dynamic random access memory (DRAM), synchronous linked dynamic random access memory (SLDRAM), and direct rambus RAM (DR RAM).

[0093] The following is combined Figure 3 This application describes a model-driven industrial configuration method based on embodiments of the present application. Figure 3 This is a flowchart illustrating a model-driven industrial configuration method provided in this application embodiment, applied to a model-driven industrial configuration system. The model-driven industrial configuration system includes: a domain model layer, a model conversion engine, a code generator, and a configuration engine. The model-driven industrial configuration method specifically includes the following steps: S301: Determine relevant information for the preset industrial scenario through the domain model layer, and configure the relevant information to construct a hierarchical and executable domain model system to separate the configuration concerns in the preset industrial scenario; S302: Configure the corresponding target engine resources and target predefined rule library according to the domain model system through the model conversion engine; S303: The code generator automatically converts the domain model system into a specific, executable configuration project file based on the target engine resources and the predefined rule base; the configuration project file includes code and configuration files; S304: Deploy the configuration project file to the target configuration software runtime environment corresponding to the preset industrial scenario through the configuration engine to obtain the target industrial configuration software.

[0094] Optionally, the domain model layer includes at least: a process logic model, a functional design model, and a human-computer interaction model; The configuration of the relevant data constructs a hierarchical, executable domain model system, including: Based on the relevant data, the process logic model is used to determine the business logic used to describe the industrial process in the preset industrial scenario. The process logic model is instantiated through the functional design model to bind to specific equipment types; The human-computer interaction model determines visualization configuration parameters related to the preset industrial scenario based on the relevant data. The visualization configuration parameters include at least one of the following: the structure of the monitoring screen, style guidelines, screen elements, and mapping rules of elements in the functional design model.

[0095] Optionally, configuring the corresponding target engine resources and target predefined rule base according to the domain model system includes: Obtain the number of layers and scale of the domain model system; The target engine resources corresponding to the preset industrial scenario are determined based on the number of layers and the scale. Configure the target predefined rule base according to the domain model system.

[0096] Optionally, the target predefined rule base includes a first predefined rule base, a second predefined rule base, and a third predefined rule base; configuring the target predefined rule base according to the domain model system includes: The first predefined rule base is determined based on the process logic model; The second predefined rule base is determined based on the functional design model; The third predefined rule base is determined based on the human-computer interaction model.

[0097] Optionally, the model-driven industrial configuration system further includes an update unit, and the method further includes: When the update unit makes fine-tuning adjustments to graphics or parameters in the configuration interface of the target industrial configuration software during operation, it determines the corresponding target fine-tuning parameters, determines the corresponding target system update parameters based on the target fine-tuning parameters, and then updates the corresponding functional design model or human-computer interaction model with the target system update parameters.

[0098] In the embodiments of this application, the specific descriptions of some or all of the steps of any method can be referred to the above. Figures 1A-1C The corresponding system description shown will not be repeated here.

[0099] This application also provides a computer-readable storage medium storing a computer program for electronic data interchange, which causes a computer to perform some or all of the steps of any of the methods described in the above method embodiments, wherein the computer includes an electronic device.

[0100] This application also provides a computer program product, which includes a non-transitory computer-readable storage medium storing a computer program operable to cause a computer to perform some or all of the steps of any of the methods described in the above method embodiments. The computer program product may be a software installation package, and the computer may include an electronic device.

[0101] It should be noted that, for the sake of simplicity, the above embodiments are all described as a series of actions. Those skilled in the art should understand that this application is not limited to the described order of actions, as some steps in the embodiments of this application can be performed in other orders or simultaneously. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions, steps, modules, or units involved are not necessarily essential to the embodiments of this application.

[0102] In the above embodiments, the descriptions of each embodiment in this application have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.

[0103] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. This program can be stored in a computer-readable storage medium, and when executed, it can include the processes described in the above method embodiments. The aforementioned storage medium includes various media capable of storing program code, such as ROM or random access memory (RAM), magnetic disks, or optical disks.

[0104] The steps of the methods or algorithms described in the embodiments of this application can be implemented in hardware or by a processor executing software instructions. The software instructions can consist of corresponding software modules, which can be stored in RAM, flash memory, ROM, EPROM, electrically erasable programmable read-only memory (EEPROM), registers, hard disk, portable hard disk, read-only optical disk (CD-ROM), or any other form of storage medium well known in the art. An exemplary storage medium is coupled to a processor, enabling the processor to read information from and write information to the storage medium. Of course, the storage medium can also be a component of the processor. The processor and storage medium can reside in an ASIC. Furthermore, the ASIC can reside in a terminal device or management device. Alternatively, the processor and storage medium can exist as discrete components in the terminal device or management device.

[0105] Those skilled in the art will recognize that, in one or more of the examples above, the functions described in the embodiments of this application can be implemented, in whole or in part, by software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product. This computer program product includes one or more computer instructions. When these computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium accessible to a computer or a data storage device such as a server or data center that integrates one or more available media. The available media can be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., digital video discs (DVDs)), or semiconductor media (e.g., solid-state disks (SSDs)).

[0106] The modules / units included in the various devices and products described in the above embodiments can be software modules / units, hardware modules / units, or a combination of both. For example, for devices and products applied to or integrated into a chip, all modules / units can be implemented using hardware methods such as circuits, or at least some modules / units can be implemented using software programs that run on a processor integrated within the chip, while the remaining (if any) modules / units can be implemented using hardware methods such as circuits. For devices and products applied to or integrated into a chip module, all modules / units can be implemented using hardware methods such as circuits. Different modules / units can be located in the same component (e.g., chip, circuit module, etc.) or different components of the chip module, or at least some modules / units can be implemented using hardware methods such as circuits. The implementation is achieved through a software program that runs on the processor integrated within the chip module. The remaining modules / units (if any) can be implemented using hardware methods such as circuits. For various devices and products applied to or integrated into terminal equipment, each of their modules / units can be implemented using hardware methods such as circuits. Different modules / units can be located in the same component (e.g., chip, circuit module, etc.) or different components within the terminal equipment. Alternatively, at least some modules / units can be implemented through a software program that runs on the processor integrated within the terminal equipment, while the remaining modules / units (if any) can be implemented using hardware methods such as circuits.

[0107] The specific embodiments described above further illustrate the purpose, technical solution, and beneficial effects of the embodiments of this application. It should be understood that the above descriptions are merely specific embodiments of the embodiments of this application and are not intended to limit the protection scope of the embodiments of this application. Any modifications, equivalent substitutions, improvements, etc., made on the basis of the technical solutions of the embodiments of this application should be included within the protection scope of the embodiments of this application.

Claims

1. A model-driven based industrial configuration system, characterized in that, The model-driven industrial configuration system includes: a domain model layer, a model conversion engine, a code generator, and a configuration engine, wherein... The domain model layer is used to determine relevant information for a preset industrial scenario and configure the relevant information to construct a hierarchical, executable domain model system to separate the concerns configured in the preset industrial scenario. The model conversion engine is used to configure corresponding target engine resources and target predefined rule base according to the domain model system; The code generator is used to automatically convert the domain model system into a specific, executable configuration project file based on the target engine resources and the predefined rule base; the configuration project file includes code and configuration files; The configuration engine is used to deploy the configuration engineering file to the target configuration software runtime environment corresponding to the preset industrial scenario, thereby obtaining the target industrial configuration software.

2. The model-driven industrial configuration system as described in claim 1, characterized in that, The domain model layer includes at least: a process logic model, a functional design model, and a human-computer interaction model; In constructing a hierarchical, executable domain model system using the aforementioned configuration data, the following are included: The process logic model is used to determine the business logic used to describe the industrial process in the preset industrial scenario based on the relevant data. The functional design model is used to instantiate the process logic model to bind to a specific equipment type; The human-computer interaction model is used to determine visualization configuration parameters related to the preset industrial scenario based on the relevant data. The visualization configuration parameters include at least one of the following: the structure of the monitoring screen, style guidelines, screen elements, and mapping rules of elements in the functional design model.

3. The model-driven industrial configuration system as described in claim 2, characterized in that, Regarding the configuration of corresponding target engine resources and target predefined rule bases according to the domain model system, the model conversion engine is specifically used for: Obtain the number of layers and scale of the domain model system; The target engine resources corresponding to the preset industrial scenario are determined based on the number of layers and the scale. Configure the target predefined rule base according to the domain model system.

4. The model-driven industrial configuration system as described in claim 3, characterized in that, The target predefined rule base includes a first predefined rule base, a second predefined rule base, and a third predefined rule base; regarding configuring the target predefined rule base according to the domain model system, the model conversion engine is specifically used for: The first predefined rule base is determined based on the process logic model; The second predefined rule base is determined based on the functional design model; The third predefined rule base is determined based on the human-computer interaction model.

5. The model-driven industrial configuration system as described in any one of claims 2-4, characterized in that, The model-driven industrial configuration system also includes an update unit, wherein, The update unit is used to determine the corresponding target fine-tuning parameters when the graphics or parameters are fine-tuned in the configuration interface of the target industrial configuration software during operation, determine the corresponding target system update parameters according to the target fine-tuning parameters, and update the target system update parameters in reverse to the corresponding functional design model or human-computer interaction model.

6. A model-driven industrial configuration method, characterized in that, This is applied to a model-driven industrial configuration system, which includes: a domain model layer, a model conversion engine, a code generator, and a configuration engine. The model-driven industrial configuration method includes: The relevant information of the preset industrial scenario is determined through the domain model layer, and the relevant information is configured to construct a hierarchical and executable domain model system to separate the configuration concerns in the preset industrial scenario; The model conversion engine configures the corresponding target engine resources and target predefined rule library according to the domain model system. The code generator automatically converts the domain model system into a specific, executable configuration project file based on the target engine resources and the predefined rule base; the configuration project file includes code and configuration files. The configuration engineering file is deployed to the target configuration software runtime environment corresponding to the preset industrial scenario through the configuration engine to obtain the target industrial configuration software.

7. The model-driven industrial configuration method as described in claim 6, characterized in that, The domain model layer includes at least: a process logic model, a functional design model, and a human-computer interaction model; The configuration of the relevant data constructs a hierarchical, executable domain model system, including: Based on the relevant data, the process logic model is used to determine the business logic used to describe the industrial process in the preset industrial scenario. The process logic model is instantiated through the functional design model to bind to specific equipment types; The human-computer interaction model determines visualization configuration parameters related to the preset industrial scenario based on the relevant data. The visualization configuration parameters include at least one of the following: the structure of the monitoring screen, style guidelines, screen elements, and mapping rules of elements in the functional design model.

8. The model-driven industrial configuration method as described in claim 7, characterized in that, The step of configuring the corresponding target engine resources and target predefined rule library according to the domain model system includes: Obtain the number of layers and scale of the domain model system; The target engine resources corresponding to the preset industrial scenario are determined based on the number of layers and the scale. Configure the target predefined rule base according to the domain model system.

9. The model-driven industrial configuration method as described in claim 8, characterized in that, The target predefined rule base includes a first predefined rule base, a second predefined rule base, and a third predefined rule base; configuring the target predefined rule base according to the domain model system includes: The first predefined rule base is determined based on the process logic model; The second predefined rule base is determined based on the functional design model; The third predefined rule base is determined based on the human-computer interaction model.

10. The model-driven industrial configuration method according to any one of claims 7-9, characterized in that, The model-driven industrial configuration system further includes an update unit, and the model-driven industrial configuration method further includes: When the update unit makes fine-tuning adjustments to graphics or parameters in the configuration interface of the target industrial configuration software during operation, it determines the corresponding target fine-tuning parameters, determines the corresponding target system update parameters based on the target fine-tuning parameters, and then updates the corresponding functional design model or human-computer interaction model with the target system update parameters.

Images