A standardized engineering scheme popularization method and related device in a group multi-plant scenario

Abstract

The application provides a standardized engineering scheme popularization method and related device in a group multi-plant scene, including: S110, creating a scheme: creating a standardized engineering scheme; S120, setting a popularization configuration: configuring a plurality of station endpoint mappings, and setting a public variable value and a rule variable value for each station endpoint mapping; S130, saving the popularization configuration; S140, publishing the scheme: solidifying all related information at the current moment into a current version snapshot, generating a batch identifier, batch distributing the current version snapshot and the batch identifier, creating a popularization main log, and generating a popularization detail; S150, executing the scheme: executing the standardized engineering scheme after variable extraction and conversion processing based on the public variable value and the rule variable value extracted from the current version snapshot in each receiving endpoint, and updating the popularization main log and the popularization detail. The application can provide a layered decoupling, traceable, and solidifiable scheme popularization mechanism.

Description

Technical Field

[0001] This application relates to the field of group management technology, and in particular to a method and related apparatus for promoting standardized engineering solutions in a group-based multi-factory scenario. Background Technology

[0002] In large-scale, multi-factory scenarios (such as manufacturing groups promoting unified production standards, quality inspection standards, and equipment operation and maintenance rules to their various branches), a common contradiction exists between the group's standardized management and control and the heterogeneity of factory sites. Specifically, the engineering solutions formulated at the group level (such as data acquisition specifications, equipment linkage rules, and quality inspection judgment standards) are unified and standardized, while the actual operating environments of each factory (including equipment numbering systems, sensor physical locations, database connection configurations, filter threshold settings, and inspection cycle definitions) are all different.

[0003] Therefore, the existing methods of promoting solutions will face multiple bottlenecks due to the lack of a standardized system: (1) The lack of heterogeneous adaptation process and reliance on manual adaptation can easily lead to inconsistent execution standards, or the central end has a separate maintenance plan for each factory, resulting in a linear increase in the number of plans and uncontrolled maintenance costs.

[0004] (2) The standard content is deeply coupled with the differences in the factory site. The two are mixed in the same configuration, which leads to the generation of branch versions when the requirements of a single factory are modified, thus destroying the uniformity of the standard.

[0005] (3) The scheme is promoted as a one-time distribution action, which cannot lock the complete content at the time of release. Therefore, when a failure occurs, it is difficult to determine whether it is caused by a release defect or subsequent changes, and there is a lack of basis for audit tracing.

[0006] (4) The promotion feedback is coarse-grained and can only provide the overall success or failure status. Therefore, when promoting in batches, it is impossible to locate the anomalies of specific factories, endpoints or rules, resulting in long troubleshooting cycles and low operation and maintenance efficiency.

[0007] These issues collectively make it difficult to implement the group's standard solutions efficiently and consistently, necessitating a layered, decoupled, traceable, and solidified solution promotion mechanism. Summary of the Invention

[0008] This application provides a method and related apparatus for promoting standardized engineering solutions in a multi-factory group setting, in order to solve the problems existing in related technologies. The technical solution is as follows: Firstly, embodiments of this application provide a method for promoting standardized engineering solutions in a group-based, multi-factory scenario, including: S110. Create a solution: On the group side, create a standardized engineering solution for this promotion based on business needs. The standardized engineering solution includes a set of standard rules and rule logic, common variables, and rule variables defined for each standard rule in the set of standard rules. The standard rules in the set of standard rules work together. S120. Set up promotion configuration: Configure multiple station endpoint mappings for the standardized engineering scheme, and set common variable values ​​and rule variable values ​​for each station endpoint mapping. Each station endpoint mapping is used to describe the association records between the stations and endpoints involved in this promotion. The endpoints include the receiving endpoints deployed in the factory. S130. Save promotion configuration: Use an idempotent strategy to save all configured site endpoint mappings and the currently set public variable values ​​and rule variable values ​​for each site endpoint mapping; S140. Release plan: Solidify all relevant information of this promotion at the current moment into a current version snapshot, and generate a batch identifier for this promotion; batch send the current version snapshot and the batch identifier to each receiving endpoint in the promotion configuration, and create a promotion master log associated with the batch identifier, and generate promotion details for each site endpoint mapping, wherein the current version snapshot includes the standardized engineering plan, the currently set public variable values ​​and rule variable values ​​for each site endpoint mapping; S150, Execution Plan: From the current version snapshot received from each receiving endpoint, extract the standardized engineering plan and the currently set public variable values ​​and rule variable values ​​of the site endpoint mapping corresponding to each receiving endpoint; in each receiving endpoint, based on the extracted public variable values ​​and rule variable values, perform variable extraction and transformation processing on the standardized engineering plan to obtain and execute the target engineering plan; based on the execution result of each target rule in the target engineering plan, update the promotion master log and the promotion details corresponding to each receiving endpoint.

[0009] In one implementation, the execution order of the standard rules in the standard rule set is defined using a DAG (Directed Acyclic Graph). Each station endpoint mapping is uniquely determined by a relationship chain of four elements: sending station, receiving station, sending endpoint, and receiving endpoint. The sending station is the local end on the group side, the receiving station is the local end on the factory side, and the sending endpoint is the cloud deployed on the group side.

[0010] In one implementation, step S140 specifically includes: Before the standardized engineering solution is officially implemented and promoted, all relevant information of this promotion at the current moment is fixed into a snapshot of the current version, and a batch identifier for this promotion is generated; The current version snapshot is compared with the previously released version snapshot, and the comparison results are presented in a structured form for the publisher to confirm. After the publisher confirms the approval, the optimal publishing path is selected to send the current version snapshot and the batch identifier to each receiving endpoint, and the promotion master log is created, as well as the promotion details of each site endpoint mapping are generated.

[0011] In one implementation, the current version snapshot further includes application package information of the standardized engineering scheme; step S150 specifically includes: an application collaboration sub-process and a data collaboration sub-process; wherein, The application collaboration sub-process adopts a two-stage mechanism that separates download and installation, including: in the download stage, extracting the application package information from the current version snapshot received by each receiving endpoint, downloading the relevant application to the local storage of each receiving endpoint based on the application package information, and entering the installation stage after the integrity verification of the relevant application is passed; in the installation stage, performing installation and running status verification on the local storage of the relevant application at each receiving endpoint, and reporting the installation results. The data collaboration sub-process includes: extracting the standardized engineering scheme and the currently set public variable values ​​and rule variable values ​​of the site endpoint mapping corresponding to each receiving endpoint from the current version snapshot received by each receiving endpoint; performing variable extraction and transformation processing on the standardized engineering scheme based on the extracted public variable values ​​and rule variable values ​​in each receiving endpoint to obtain the target engineering scheme adapted to each receiving endpoint; executing the target engineering scheme through the relevant application in each receiving endpoint, recording the execution result of each target rule in the target engineering scheme, and backfilling the execution result of each target rule into the promotion details corresponding to each receiving endpoint to update the promotion details corresponding to each receiving endpoint; summarizing the execution results of each receiving endpoint, and updating the promotion master log based on the summarized results.

[0012] In one embodiment, the method further includes: S160, Rule Regression: Regress the general rules that have been verified and proven effective by multiple factories to the standardized engineering solution as standard rules, or update the corresponding standard rules in the standardized engineering solution based on the factory-customized and optimized rule logic.

[0013] In one embodiment, the method further includes: S170. Data cleanup after promotion termination: When the standardized engineering solution needs to be taken offline or the promotion is canceled, a solution cleanup request is sent to each receiving endpoint that has been promoted by the standardized engineering solution, so that each receiving endpoint deletes the data related to the standardized engineering solution stored locally after receiving the solution cleanup request.

[0014] In one embodiment, the method further includes: S180, Cross-Environment Migration Solution: When the standardized engineering solution needs to be migrated from the test environment to the production environment, or when the standardized engineering solution needs to be promoted to a new factory, only the standard rule set of the standardized engineering solution and the rule logic, public variables and rule variables defined by each standard rule are exported; when the standardized engineering solution is imported into the production environment or a new factory, it is allowed to refill the public variables defined by each standard rule in the standardized engineering solution according to the current production environment. After the import is completed, the standardized engineering solution is marked as pending release and the process returns to step S120.

[0015] Secondly, embodiments of this application also provide a device for promoting standardized engineering solutions in a group-based multi-factory scenario, comprising: A creation unit is used to create a solution: On the group side, a standardized engineering solution for this promotion is created based on business needs. The standardized engineering solution includes a set of standard rules and rule logic, common variables, and rule variables defined for each standard rule in the set of standard rules. The standard rules in the set of standard rules work together with each other. The setting unit is used to set the promotion configuration: configure multiple station endpoint mappings for the standardized engineering scheme, and set common variable values ​​and rule variable values ​​for each station endpoint mapping. Each station endpoint mapping is used to describe the association records between the stations and endpoints involved in this promotion, and the endpoints include the receiving endpoints deployed in the factory. The storage unit is used to save the promotion configuration: it uses an idempotent strategy to perform a save operation on all configured site endpoint mappings and the currently set public variable values ​​and rule variable values ​​for each site endpoint mapping; The publishing unit is used to publish the plan: it saves all relevant information of this promotion at the current moment into a current version snapshot and generates a batch identifier for this promotion; it batch distributes the current version snapshot and the batch identifier to each receiving endpoint in the promotion configuration, creates a promotion master log associated with the batch identifier, and generates promotion details for each site endpoint mapping, wherein the current version snapshot includes the standardized engineering plan, the currently set public variable values ​​and rule variable values ​​for each site endpoint mapping; An execution unit is used to execute the plan: extract the standardized engineering plan and the currently set public variable values ​​and rule variable values ​​of the site endpoint mapping corresponding to each receiving endpoint from the current version snapshot received from each receiving endpoint; perform variable extraction and transformation processing on the standardized engineering plan in each receiving endpoint based on the extracted public variable values ​​and rule variable values ​​to obtain and execute the target engineering plan; and update the promotion master log and the promotion details corresponding to each receiving endpoint based on the execution result of each target rule in the target engineering plan.

[0016] Thirdly, embodiments of this application also provide an electronic device, which includes a memory and a processor, wherein the memory stores instructions, the instructions are loaded and executed by the processor to implement the methods in any of the above embodiments, wherein the memory and the processor communicate with each other through an internal connection path.

[0017] Fourthly, embodiments of this application also provide a computer-readable storage medium storing a computer program that, when run on a computer, implements the methods in any of the above-described embodiments.

[0018] The advantages or beneficial effects of the above technical solutions include at least the following: This application creates a standardized engineering solution for this promotion based on business needs at the group level, configures multiple station endpoint mappings for the standardized engineering solution, sets common variable values ​​and rule variable values ​​for each station endpoint mapping, and uses an idempotent strategy to save all configured station endpoint mappings and the currently set common variable values ​​and rule variable values ​​for each station endpoint mapping. The coordination between these processes can separate the solution definition from the promotion target, achieving the effect that no matter how many new factories are added, the standardized engineering solution only needs to be maintained once. At the same time, the standard content in the standardized engineering solution (standard rule set and the rule logic, common variables and rule variables defined by each standard rule) can be decoupled from factory differences (such as equipment number, database connection, filtering threshold) in a layered manner, so that the standard content can evolve and optimize uniformly without branching versions due to factory differences. Each factory automatically inherits and updates the standard content, thereby achieving the effect of ensuring the consistency of the execution content of each factory and avoiding the linear expansion of the number of solutions with the number of factories. That is, one standardized engineering solution can cover all projects, the operation complexity is constant, and no manual follow-up modification is required from each factory when the standardized engineering solution is updated.

[0019] Furthermore, this application forcibly fixes all relevant information of this promotion at the current moment into a current version snapshot before the promotion is implemented. This current version snapshot serves as the sole factual basis for this promotion. Regardless of any subsequent modifications to the standardized engineering plan, the complete promotion content of any historical version can be traced back, thus meeting the requirements for compliance auditing and issue tracing.

[0020] Furthermore, this application performs variable extraction and transformation processing on the standardized engineering scheme based on the extracted public variable values ​​and rule variable values ​​at each receiving endpoint to obtain and execute the target engineering scheme. This automates the placeholder replacement process. Based on the execution results of each target rule in the target engineering scheme, it updates the promotion master log and the promotion details corresponding to each receiving endpoint. This establishes a hierarchical tracing link of promotion log → promotion details → traceId → rule execution log. By linking these links with batch identifiers, problems can be located to specific factories, specific station endpoint mappings, specific rules, and specific execution stages. This achieves refined tracing by factory and by rule, which can significantly shorten the problem discovery and repair cycle.

[0021] In summary, this application can provide a layered, decoupled, traceable, and solidified solution promotion mechanism.

[0022] The above overview is for illustrative purposes only and is not intended to be limiting in any way. In addition to the illustrative aspects, embodiments, and features described above, further aspects, embodiments, and features of this application will become readily apparent from the accompanying drawings and the following detailed description. Attached Figure Description

[0023] In the accompanying drawings, unless otherwise specified, the same reference numerals throughout the various drawings denote the same or similar parts or elements. These drawings are not necessarily drawn to scale. It should be understood that these drawings depict only some embodiments disclosed in this application and should not be construed as limiting the scope of this application.

[0024] Figure 1 A flowchart illustrating the first method for promoting standardized engineering solutions in a multi-factory group setting, as provided in this application embodiment; Figure 2 An example diagram of a download page for an application installation package provided in an embodiment of this application; Figure 3 A flowchart illustrating the second method for promoting standardized engineering solutions in a multi-factory group setting, as provided in this application embodiment; Figure 4 A flowchart illustrating the promotion method of the third type of standardized engineering solution in a multi-factory group scenario provided in this application embodiment; Figure 5A flowchart illustrating the promotion method of the fourth standardized engineering solution in a multi-factory group scenario provided in this application embodiment; Figure 6 A structural block diagram of a standardized engineering solution promotion device in a group-based multi-factory scenario provided in this application embodiment; Figure 7 This is a structural block diagram of an electronic device provided in an embodiment of this application. Detailed Implementation

[0025] In the following description, only certain exemplary embodiments are briefly described. As those skilled in the art will recognize, the described embodiments can be modified in various ways without departing from the spirit or scope of this application. Therefore, the drawings and description are considered to be exemplary in nature and not restrictive.

[0026] In related technologies, once the group-level organization has finalized the engineering plan, it directly promotes the plan to various factories. This leads to multiple bottlenecks in the implementation and promotion of the engineering plan: (1) Lack of standardized heterogeneous adaptation process: Currently, there is a lack of an automated and standardized promotion process from "single standard solution" to "multiple heterogeneous factories". Existing technologies usually adopt two extreme approaches: one is to require the technical personnel of each factory to manually extract applicable content from the standard solution (i.e., the engineering solution formulated by the group) and manually adapt it item by item. This approach is very prone to inconsistent execution standards among factories due to the misunderstanding of the technical personnel, and the promotion quality is uncontrollable; the other approach is for the central end of the group to maintain a separate solution for each factory. This approach will cause the number of solutions to increase linearly with the number of factories, and the maintenance cost will be uncontrollable.

[0027] (2) The standard content is seriously coupled with the differences in the field: The existing solution promotion method mixes the standard content and the differences in the factory in the same configuration. The standard content (i.e. the content of the standard solution) and the differences in the factory are not effectively decoupled in layers. As a result, once the standard content is modified due to the needs of a factory, the standard solution will be forced to generate branch versions, which will destroy the unity of the standard solution and make it extremely difficult to upgrade the standard uniformity, regression testing and version evolution across the entire group.

[0028] (3) Lack of a "release-and-fix" version snapshot mechanism in the promotion process: In the process of promoting and releasing the solution, the group's operation of promoting the standard solution to each factory is just a one-time distribution action, which lacks version abstraction. Therefore, it is impossible to accurately record and lock the complete content snapshot issued at the "release moment". When problems occur in the system (such as production abnormalities or data errors), the technical personnel cannot accurately distinguish whether the problem is a defect in the release itself or an abnormality caused by subsequent human modifications or environmental changes. This leads to a lack of reliable data foundation for problem tracing, responsibility definition and compliance audit.

[0029] (4) Coarse-grained tracking of execution results makes troubleshooting difficult: The existing promotion feedback mechanism can only provide a macro-level "overall success / failure" status, lacking the fine-grained tracking capability of "batch-based + rule-by-rule". When the batch promotion is extended to hundreds or thousands of factory nodes, if some nodes fail, the operation and maintenance personnel cannot quickly locate which factory, which endpoint or which specific rule is abnormal. This black-box promotion method is prone to problems that are difficult to reproduce and have a long repair cycle, which seriously affects the operation and maintenance efficiency.

[0030] In summary, for large-scale, multi-factory group scenarios, existing solutions cannot achieve efficient and consistent implementation of standardized group solutions. Therefore, this application provides technical solutions for large-scale, multi-factory group scenarios that enable layered decoupling, traceability, and solidification of standardized engineering solutions for widespread adoption.

[0031] To further understand the relevant technical solutions provided in the embodiments of this application, the relevant terms involved in the embodiments of this application will be explained before introducing the relevant technical solutions provided in the embodiments of this application.

[0032] Avro (Apache Avro): Refers to the Apache Avro data serialization framework, a programming language-independent data serialization system that supports binary and JSON formats. In this application embodiment, Avro is used for efficient serialization, storage, and cross-platform transmission of structured data in offline data synchronization scenarios.

[0033] DAG (Directed Acyclic Graph): A DAG is a graph data structure consisting of nodes and directed edges, where there are no cycles that start from a node and return to that node. In this embodiment, DAG is used to represent the execution dependencies between rules to ensure that the scheduling and execution order of rules is correct and there are no circular dependencies.

[0034] Hash: Refers to a hash function, a mathematical algorithm that maps input data of arbitrary length to a fixed-length output value (hash value). In the collaborative distribution application of this application embodiment, file hash comparison is used to verify the integrity of downloaded files to ensure that the files have not been tampered with or damaged during transmission.

[0035] JGraphT: Refers to the Java Graph Computation Library, an open-source Java graph data structure and algorithm library that provides capabilities such as graph construction, traversal, topological sorting, and shortest path calculation. In this embodiment, JGraphT serves as the underlying implementation of the DAG engine, responsible for managing and scheduling the rule-dependent graph.

[0036] MDM (Master Data Management): Refers to master data management, which is a system and method for centralized and unified management of core business entity data (such as materials, customers, suppliers, organizations, etc.) of an enterprise. In the example scenario of this application embodiment, the MDM system serves as the data source for material master data.

[0037] MinIO refers to an open-source, high-performance object storage service that is compatible with the Amazon S3 API and is suitable for storing unstructured data (files, images, logs, etc.). In this embodiment, MinIO serves as a data relay storage for cloud-edge collaboration, and edge-to-edge data synchronization is achieved through MinIO.

[0038] Orchestration and scheduling center / coordinator: In a distributed system, this refers to the central control component responsible for coordinating and managing the execution order and status of multiple services or tasks. In this embodiment, the cloud acts as the Orchestrator, uniformly orchestrating and scheduling data synchronization and application collaboration tasks across all endpoints.

[0039] SQL (Structured Query Language): A standard programming language used for managing and manipulating relational databases. In this embodiment, the data source and filtering conditions of the rule template typically contain SQL query statements, where placeholders are replaced with the actual parameter values ​​of each plant during execution.

[0040] traceId (Trace Identifier): Refers to the trace identifier, which is a globally unique ID used to uniquely identify a complete request chain in a distributed system. In the embodiments of this application, a traceId is generated for each promotion operation and sent to the receiving end along with the promotion data. After the receiving end completes the execution, it sends back the traceId, thereby linking the promotion log, promotion details, and rule execution log to achieve fine-grained tracing per factory and per rule.

[0041] ZIP stands for General Data Compression and Archiving Format, which supports merging multiple files and directories into a single compressed file, reducing storage space and transmission bandwidth. In the offline data synchronization mode of this application embodiment, the Avro serialized data files are packaged and distributed in ZIP format.

[0042] Cloud-edge hyperconverged infrastructure (HCI) is an architecture that integrates a cloud-based central platform with edge nodes. In this architecture, the cloud is responsible for unified management, orchestration, scheduling, and data storage, while the edge nodes perform local computation and real-time responses close to the data source. This application's embodiments utilize this HCI architecture to achieve solution promotion, application collaboration, and data collaboration between the group's central office and various factories.

[0043] Placeholder (${}): A special marker in a template used to mark variable parts. In this embodiment, the rule template uses the format "${variable name}" to declare the parts that need to be dynamically replaced according to plant differences. For example, "${material data source}" is a placeholder, which is replaced with the actual data source name configured for that plant during the rollout.

[0044] Topological sorting refers to an algorithm that linearly sorts all nodes in a directed acyclic graph (DAG) such that for any directed edge (u→v), node u always appears before node v in the sort. In this embodiment, the DAG engine uses topological sorting to determine the execution order of rules, ensuring that dependent rules are executed first.

[0045] Snapshot Immobilization: This refers to the operation of copying and saving the complete state of all relevant data (schemes, rules, variables, mappings, etc.) as an immutable record at the moment of release. The immobilized snapshot cannot be modified and serves as the sole factual basis for this rollout, used for post-launch auditing, issue backtracking, and version comparison.

[0046] Station-Endpoint Mapping: In this embodiment, it refers to the associated records describing "who promotes to whom" in a promotion, consisting of four elements: sending station, receiving station, sending endpoint, and receiving endpoint. Each station-endpoint map uniquely identifies a promotion target, completely separating "who to promote to" from "what to promote," allowing the same standardized engineering solution to be promoted to different factories without modifying the solution itself.

[0047] Idempotency refers to the fact that performing the same operation once or multiple times produces the same result and has the same side effects. In the embodiments of this application, the saving operation of the station endpoint mapping adopts an idempotent strategy—updates if it already exists, adds if it does not exist, and the same configuration can be saved repeatedly without generating duplicate data or orphan records; when importing across environments, it is also executed idempotently according to the identifier, and existing data is automatically skipped.

[0048] The relevant technical solutions provided in the embodiments of this application will be described in detail below with reference to the accompanying drawings.

[0049] Figure 1 A flowchart illustrating a method for promoting standardized engineering solutions in a group-based multi-factory scenario according to an embodiment of this application is shown. Figure 1 As shown, the method may include the following steps: S110. Create a solution: On the group side, create a standardized engineering solution for this promotion based on business needs.

[0050] In one implementation, a standardized engineering solution for this promotion can be created on the group-side management platform (such as a cloud-edge hyperconverged management platform) according to business needs.

[0051] In one implementation, the standardization engineering scheme includes a set of standard rules and rule logic, common variables, and rule variables defined for each standard rule in the set. The standard rules in the set work collaboratively with each other.

[0052] In practice, the rule logic of each standard rule is used to define the business logic of the standard rule in data processing; the public variables of each standard rule are used to declare the fields in the standard rule whose values ​​can change with the deployment environment; and the rule variables of each standard rule are used to declare the placeholders in the standard rule that need to be dynamically replaced during promotion.

[0053] As an example, the rule logic of each standard rule can be used to define, but is not limited to: data source, data transformation method, data filtering conditions, target field mapping, and data synchronization mode.

[0054] The data synchronization mode can be either full synchronization, incremental synchronization, real-time synchronization, or offline Avro+MinIO. In full synchronization, the group side pushes all data / complete configurations related to each standard rule to the factory side at once. In incremental synchronization, the group side only synchronizes the parts that have changed since the last synchronization (added, modified, and deleted records) to the factory side. In real-time synchronization, the group side pushes the standard rules that have changed in the standardized engineering plan to the factory side in real time. In offline Avro+MinIO, the group side serializes each standard rule into an Avro format binary file and uploads it to the MinIO object storage bucket; the factory side, when its network conditions permit, pulls the file from MinIO and completes local loading. In other words, offline Avro+MinIO is an asynchronous, batch, file-based synchronization that does not require a real-time online connection between the group side and the factory side.

[0055] As an example, taking a standard rule in a standardized engineering solution as a material data distribution rule, the rule logic of this material data distribution rule can be "read material master data from ${material data source}, filter it according to ${filter conditions} and then distribute it to ${target system}". The public variables can declare "factory code" and "warehouse number" as factory difference fields, and the rule variables can declare at least one of "${material data source}", "{filter conditions}", and "${target system}" as rule placeholders.

[0056] In practice, the execution order of the standard rules in this set of standard rules can be defined using a Directed Acyclic Graph (DAG) to enable the standard rules to work together. For example, the JGraphT engine can subsequently schedule the execution of the standard rules in this set of standard rules according to the topology.

[0057] In this embodiment, by executing step S110, a standardized engineering solution can be generated, serving as the unified source for this promotion. Furthermore, multiple business-related engineering solutions can be grouped into the same standardized engineering solution for unified management. This standardized engineering solution is used to organize and categorize a set of engineering solutions, supporting batch operations within the group and unified version control.

[0058] S120. Configure Promotion: Configure multiple station endpoint mappings for this standardized engineering solution, and set common variable values ​​and rule variable values ​​for each station endpoint mapping.

[0059] In one implementation, each site endpoint mapping is used to describe the association records between sites and endpoints involved in this promotion.

[0060] In practice, each station endpoint mapping is uniquely determined by a relationship chain of four elements: the sending station, the receiving station, the sending endpoint, and the receiving endpoint. Specifically, the sending station is the local endpoint on the group side, the receiving station is the local endpoint on the factory side, the sending endpoint is the cloud-based endpoint deployed on the group side, and the receiving endpoint is the edge endpoint deployed on the factory side. In other words, the endpoints in each station endpoint mapping include both the sending endpoint deployed on the group side and the receiving endpoint deployed on the factory side.

[0061] For example, when the group adopts a cloud-edge hyperconverged management platform, the mapping of a certain station endpoint can be "the group's local end (sending site) → the cloud deployed by the group (sending endpoint) → the local end of a certain factory (receiving site) → the edge end deployed by the factory (receiving endpoint)".

[0062] It can be understood that, in the embodiments of this application, a standardized engineering solution can configure multiple station endpoint mappings at the same time, and ensure that each station endpoint mapping is unique through the relationship chain of the four elements of "sending station + receiving station + sending endpoint + receiving endpoint".

[0063] In one implementation, the common variable values ​​and rule variable values ​​of the corresponding station endpoint mappings can be set differently according to the site conditions of each factory.

[0064] For example, if the common variables need to be set separately for the business values ​​corresponding to each factory, and the common variables are factory code and warehouse code, and each factory includes factory A, factory B and factory C, then the common variable values ​​for the station endpoint mapping corresponding to factory A can be set to F001 (factory code) and WH01 (warehouse code). Correspondingly, the common variable values ​​for the station endpoint mapping corresponding to factory B can be set to F002 and WH02, and the common variable values ​​for the station endpoint mapping corresponding to factory C can be set to F003 and WH03.

[0065] For example, each endpoint mapping can be bound to a specific standard rule in a standardized engineering scheme. Then, rule variable values ​​can be set according to the actual operating environment of the factory corresponding to each endpoint mapping. This allows the rule variable value to replace the placeholder in the rule logic of the specific standard rule bound to that endpoint mapping during rollout. For instance, if a specific standard rule bound to a certain endpoint mapping is the material data distribution rule "Read material master data from ${material data source} and distribute it to ${target system}", and in the actual operating environment of the corresponding factory, the material data source is f001_mdm_01 and the target system is erp_f001, then in this material data distribution rule, "${material data source}" takes the value f001_mdm_01 and "${target system}" takes the value erp_f001.

[0066] In this embodiment, by executing step S120, the "who to promote to" can be separated from the standardized engineering scheme itself, thus decoupling the scheme definition from the promotion target. By setting common variable values ​​and rule variable values ​​for each station endpoint mapping, differentiated management of "the same standardized engineering scheme, different factory values" can be achieved. The difference is only reflected in the variable values ​​of the standard rules. In subsequent processing, the rule logic of each standard rule can remain unchanged as a template, and the differences are dynamically injected in the promotion execution stage through common variables and rule variables. For example, the variable values ​​of each standard rule can be customized by each factory according to its own actual situation, without mandatory format constraints. In subsequent processing, it is only necessary to replace the variable values ​​with the placeholders in the rule logic one by one.

[0067] S130. Save Promotion Configuration: Use an idempotent strategy to save all configured site endpoint mappings and the currently set public variable values ​​and rule variable values ​​for each site endpoint mapping.

[0068] In one implementation, all configured endpoint mappings, along with the currently set public variable and rule variable values ​​for each endpoint mapping, can be committed within a single transaction. Then, the transaction is invoked to perform a save operation. If saving any endpoint mapping fails, the entire process is rolled back: S131. Determine whether each station endpoint mapping in all station endpoint mappings already has a mapping identifier in the target memory. If a certain station endpoint mapping in all station endpoint mappings (denoted as the first station endpoint mapping) already has a mapping identifier in the target memory, then execute step S132 for the first station endpoint mapping. If a certain station endpoint mapping in all station endpoint mappings (denoted as the second station endpoint mapping) does not have a mapping identifier in the target memory, then execute step S133 for the second station endpoint mapping.

[0069] S132. Then, based on the currently set public variable values ​​and rule variable values ​​of the first station endpoint mapping, update the first station endpoint mapping in the target memory according to the mapping identifier.

[0070] S133. Based on the four elements of sending station, receiving station, sending endpoint, and receiving endpoint, determine whether the second station endpoint mapping matches the station endpoint mapping already stored in the target memory. If the second station endpoint mapping matches a certain station endpoint mapping already stored in the target memory (denoted as the third station endpoint mapping), then execute step S134; otherwise, execute step S135 for the second station endpoint mapping.

[0071] S134. Based on the currently set public variable values ​​and rule variable values ​​of the second station endpoint mapping, update the third station endpoint mapping that matches it in the target memory, and assign a mapping identifier to the third station endpoint mapping.

[0072] In practice, the third-station endpoint mapping may be an existing record in the target memory based on the four elements, which was not assigned an identifier before the introduction of the mapping identifier mechanism or in previous operations. After the current transaction matches it through the four elements, it assigns a mapping identifier and updates the configuration value, which can ensure eventual data consistency.

[0073] S135. Store the second station endpoint mapping and its currently configured public variable values ​​and rule variable values ​​in the target memory, and assign a mapping identifier to the second station endpoint mapping.

[0074] S136. If any of the steps S132, S134 and S135 fails, the current save operation ends and the process returns to re-execute step S131.

[0075] It should be noted that the embodiments of this application do not impose specific limitations on the mapping identifier, as long as it can uniquely determine the mapping of its corresponding station endpoint.

[0076] In this embodiment of the application, by executing step S130, all currently submitted station endpoint mappings and their variable values ​​can be saved. At the same time, it can be ensured that the promotion configuration can be saved repeatedly without generating duplicate or orphan data.

[0077] In this embodiment, a three-layer decoupled architecture can be constructed through the collaboration between steps S110-S130: Standard Content Definition Layer—unified maintenance of standardized engineering schemes and their standard rules, with each standard rule working collaboratively and all factories sharing the same standard definition; Station / Endpoint Mapping Layer—uniquely identifying the promotion target through the association record between stations and endpoints, achieving separation of "who to promote to" and "what to promote"; Factory Difference Variable Layer—public variables and rule variables are declared with placeholders, and during promotion, values ​​are dynamically injected according to the target through variable extraction and transformation, ensuring that rule versions do not branch due to factory differences, thus solving the linear expansion problem of "number of schemes = number of factories × number of business scenarios" under existing scheme promotion methods. For example, taking 10 factories and 5 business scenarios as an example, the existing scheme promotion method requires maintaining 50 schemes, while this embodiment only requires 1 standardized engineering scheme + 50 sets of variable configurations.

[0078] S140, Release Plan: Solidify all relevant information of this promotion at the current moment into a snapshot of the current version, and generate a batch identifier for this promotion; batch send the current version snapshot and the batch identifier to each receiving endpoint in the promotion configuration, and create a promotion master log associated with the batch identifier, as well as generate promotion details mapped to each site endpoint.

[0079] In one implementation, the promotion master log can be used to record summary information about this promotion. The promotion details for each site endpoint mapping can be used to record the execution results of each site endpoint mapping scheme, such as status, reason, and time consumption.

[0080] In one implementation, before the formal implementation and promotion of a standardized engineering solution, all relevant information for the current promotion can be fixed into a current version snapshot, and a batch identifier for this promotion can be generated. In this way, a "release-as-you-go" version snapshot mechanism can be used to accurately record and lock the complete content snapshot issued at the "release moment." This current version snapshot is an immutable record and the only factual data for this promotion. Therefore, when system problems occur (such as production anomalies or data errors), technical personnel can accurately distinguish whether the anomaly is due to a defect in the release itself or to subsequent human modifications or environmental changes, thus providing a reliable data foundation for problem tracing, responsibility determination, and compliance auditing.

[0081] As an example, all relevant information may include, but is not limited to: standardized engineering schemes (standard rule sets and rule logic, public variables, and rule variables defined for each standard rule in the standard rule set); multiple station endpoint mappings currently configured in the standardized engineering schemes; public variable values ​​and rule variable values ​​currently set for each station endpoint mapping; application package information of the standardized engineering schemes; seed data (pre-set, relatively static basic reference data for the system, such as enumerations, dictionaries, constants, templates, etc., which are included in version snapshots to ensure that the configuration version can be completely and consistently restored and run in different times and environments); relevant station and endpoint information on the group side and the factory side; and tenant information provided by the group side.

[0082] In one implementation, the current version snapshot can be compared with the previously released version snapshot in a differentiated manner, and the comparison results can be presented in a structured form for the publisher's confirmation. For example, the current version snapshot and the previously released version snapshot can be compared layer by layer according to a preset comparison hierarchy, and the comparison results can be presented in a structured form for the publisher's confirmation. In this way, the publisher can confirm what has changed in this release compared to the previous release, which can prevent the release of unexpected standard rules or variable changes due to accidental operation. The publisher can discover unexpected rule or variable changes before confirmation, thus preventing accidental releases from the process. At the same time, the comparison results can serve as the basis for release approval, enhancing the control capabilities of the promotion process.

[0083] The preset comparison levels include, but are not limited to, five levels: addition, deletion, and modification of standard rule sets; addition, deletion, and modification of standard rules; changes in public variable definitions; changes in rule variable values; and changes in station endpoint mappings (addition / removal / unchanged). For example, during comparison, objects at the same level can be matched by ID identifier. If no ID identifier matches an object at the same level, they can be matched by name or order. The difference comparison results for each comparison level can be marked as one of four states: "added," "modified," "deleted," or "unchanged."

[0084] In one implementation, after the publisher confirms approval, they can choose the optimal publishing path to send the current version snapshot and batch identifier to each receiving endpoint, create a promotion master log, and generate promotion details for each site endpoint mapping.

[0085] In practical implementation, when this promotion involves multiple endpoint mappings (i.e., configuring multiple endpoint mappings for a standardized engineering solution), the optimal deployment path can be automatically selected based on the target endpoint type (cloud or edge) and network topology of each endpoint mapping. This path can be either cloud-to-edge direct delivery, edge-to-edge MinIO relay, or parallel distribution. Transmissions are grouped and merged by site to reduce redundant data exchange and improve throughput efficiency for simultaneous promotion across multiple factories. For example, taking simultaneous promotion of 5 edge endpoints as an example, under ideal network conditions, parallel distribution can shorten the overall promotion time to 1 / 5 of the original time compared to sequential waiting.

[0086] For example, in cloud-to-edge deployment scenarios, the current version snapshot and batch identifier can be directly deployed from the cloud to each edge device. In edge-to-edge collaborative scenarios, the source edge device first exports the current version snapshot and batch identifier and uploads them to the cloud's MinIO relay storage, and the target edge device then downloads and imports them from MinIO, with the cloud serving as the orchestration and scheduling center. In scenarios with parallel deployment across multiple edge devices, a parallel distribution strategy can be adopted to deploy the current version snapshot and batch identifier to each receiving endpoint (multiple edge devices receive and deploy simultaneously), rather than waiting sequentially one by one. In these scenarios, when selecting the optimal deployment path, the network topology, data volume, and historical success rate of the receiving endpoints mapped to each site endpoint can be comprehensively considered. Transmissions along the same path can be grouped and merged by site to reduce redundant data exchanges and improve the overall efficiency of multi-factory batch deployment.

[0087] After selecting the optimal publishing path for each site endpoint mapping's receiving endpoint, the current version snapshot and batch identifier can be distributed to each receiving endpoint sequentially through the selected optimal publishing path, according to each site endpoint mapping in the promotion configuration. A promotion master log record (hcm_publish_log) and promotion details (hcm_publish_log_detail) will also be created. That is, each site endpoint mapping corresponds to one promotion detail, and a single distribution is performed.

[0088] In one implementation, the promotion details can be used to record, but are not limited to: the specific site and endpoint mapped to each site endpoint, the distribution status, the execution result, the reason for failure, and the remote feedback.

[0089] In this embodiment of the application, step S140 automatically generates a complete version snapshot (including the complete state of standardized engineering scheme, standard rules, public variables and rule variables, and site endpoint mapping) before each promotion is executed. The snapshot cannot be modified and serves as the sole factual basis for this promotion. This allows the complete promotion content of any historical version to be traced back regardless of how the standardized engineering scheme is modified afterward, thus meeting the requirements for compliance auditing and issue tracing.

[0090] S150, Execution Plan: Extract the standardized engineering plan and the currently set public variable values ​​and rule variable values ​​of the site endpoint mapping corresponding to each receiving endpoint from the current version snapshot received by each receiving endpoint; in each receiving endpoint, based on the extracted public variable values ​​and rule variable values, perform variable extraction and transformation processing on the standardized engineering plan to obtain and execute the target engineering plan; based on the execution results of each target rule in the target engineering plan, update the promotion master log and the promotion details corresponding to each receiving endpoint.

[0091] In one implementation, step S150 can be divided into two parts: an application collaboration sub-process and a data collaboration sub-process.

[0092] In practice, the application collaboration sub-process can adopt a two-stage mechanism that separates download and installation, including: in the download stage, extracting application package information from the current version snapshot received by each receiving endpoint, downloading the relevant application to the local storage of each receiving endpoint based on the application package information, and entering the installation stage after the integrity verification of the relevant application is passed; in the installation stage, performing installation and running status verification on the local storage of the relevant application at each receiving endpoint, and reporting the installation results.

[0093] For example, during the download phase, combined with Figure 2 As shown, application package information can be extracted from the current version snapshot received by each receiving endpoint. Based on this application package information, the installation package of the relevant application is downloaded from the group's cloud to the local storage of each receiving endpoint. After downloading, the integrity of the installation package of the relevant application can be verified by file size comparison and / or hash verification. If the file size of the installation package of the relevant application is the same as the file size of the application package in the application package information, and / or the hash value of the installation package of the relevant application is the same as the hash value of the application package in the application package information, then the installation package of the relevant application has passed the integrity verification and enters the installation stage. The successful download status of the installation package of the relevant application can be recorded in the promotion details of each receiving endpoint, thus ensuring that the installation package of the relevant application has not been tampered with or damaged. If the download of the installation package of the relevant application fails (network interruption or integrity verification failure), the download can be automatically retried without affecting the already installed application. If the number of retry downloads exceeds the preset number of retry (which can be set according to actual needs), the download failure status and failure reason of the relevant application can be recorded in the promotion details of each receiving endpoint.

[0094] For example, during the installation phase, the relevant application is installed or updated locally on each receiving endpoint based on the downloaded installation package (an update operation is performed if the relevant application is already installed). After the update or installation of the relevant application is completed, the functionality of the relevant application is verified, and the installation result is reported. The installation result of the relevant application is recorded in the promotion details of each receiving endpoint. If the verification result of the relevant application's functionality is that it cannot function properly, the installation of the relevant application is determined to have failed. In this case, there is no need to download the installation package again; it can be reinstalled directly based on the locally stored installation package.

[0095] In this embodiment, by employing a two-stage mechanism that separates downloading and installation in the application collaboration sub-process, downloading and installation can be retried independently and their states recorded independently (i.e., large file transfers and installation operations do not interfere with each other). This avoids the repeated transmission of large packets due to network fluctuations, and eliminates the need for re-downloading if installation fails, saving edge bandwidth and time. It also ensures that the distribution process is controllable and the results are verifiable. Furthermore, the overall application collaboration supports application installation, updates, uninstallation, and version rollback, enabling unified management and batch distribution of application versions across multiple sites. For example, when batch distributing the current version snapshot and batch identifier to multiple receiving endpoints, related applications can be downloaded in parallel and installed in batches, thereby maximizing the utilization of bandwidth and edge computing resources.

[0096] In practice, the data collaboration sub-process may include the following steps: Step 1: Extract the standardized engineering scheme and the currently set public variable values ​​and rule variable values ​​of the station endpoint mapping corresponding to each receiving endpoint from the current version snapshot received by each receiving endpoint.

[0097] For example, the standard rule set of the standardized engineering scheme, as well as the rule logic, public variables and rule variables defined for each standard rule in the standard rule set, can be extracted from the current version snapshot received by each receiving endpoint. The station endpoint corresponding to each receiving endpoint maps the currently set public variable values ​​and rule variable values.

[0098] Step 2: Based on the extracted common variable values ​​and rule variable values ​​at each receiving endpoint, perform variable extraction and transformation processing on the standardized engineering scheme to obtain the target engineering scheme adapted to each receiving endpoint.

[0099] For example, in each receiving endpoint, all placeholders of the "${variable name}" pattern in the standard rule set can be identified through regular expressions or placeholder parsing. These placeholders are then extracted, and a mapping table between placeholders and actual values ​​is constructed by combining the extracted common variable values ​​and rule variable values. Subsequently, each standard rule in the standard rule set is traversed, and based on this mapping table, the placeholders in each standard rule are replaced with actual values ​​to obtain a target rule adapted to each receiving endpoint. After the traversal is complete, the target engineering solution adapted to each receiving endpoint can be obtained.

[0100] For example, in step 2, when a standard rule does not match any of the placeholders in the mapping table, the standard rule is marked as incomplete and its execution is prevented. At the same time, a list of missing variables is displayed, thus automating and verifying the placeholder replacement process, intercepting and displaying missing variable values ​​in advance, and avoiding runtime errors caused by incomplete configuration.

[0101] In this embodiment of the application, by performing variable extraction and transformation processing on the standardized engineering scheme in step S2, it can be ensured that the business semantics of the execution logic of each factory are consistent and the instance parameters are different after the same standard rule is transformed by different mapping tables.

[0102] Step 3: Execute the target engineering plan through the relevant application in each receiving endpoint, and record the execution result of each target rule in the target engineering plan. Fill the execution result of each target rule back into the promotion details corresponding to each receiving endpoint to update the promotion details corresponding to each receiving endpoint.

[0103] For example, each receiving endpoint can invoke the relevant application to perform data queries from the corresponding sending site and export query results, according to the data source, data transformation method, data filtering conditions, target field mapping, and data synchronization mode defined by the rule logic of each target rule. Then, each target rule and its corresponding query results are sent to the local storage of each receiving endpoint and data synchronization is performed. Finally, the execution results of each target rule (including rule-level execution logs and traceId) are populated back into the promotion details corresponding to each receiving endpoint to update the promotion details for each receiving endpoint.

[0104] Step 4: Summarize the execution results of each receiving endpoint and update the promotion master log based on the summarization results.

[0105] For example, the execution results reported by each receiving endpoint can be aggregated, and the promotion master log can be updated based on the aggregated results. If the promotion master log determines that all receiving endpoints have successfully executed the target engineering plan, the promotion of the standardized engineering plan is considered complete. If the promotion master log determines that some receiving endpoints have failed to execute the target engineering plan, the failed receiving endpoints and the reasons are recorded for targeted retries.

[0106] Combining steps 3 and 4, a hierarchical tracing chain can be established, from the main promotion log to promotion details, traceId, and rule execution log. This supports detailed tracing at the factory, endpoint, and rule levels. Furthermore, updating the main promotion log in step 4 allows for the persistent recording of the final execution status of each receiving endpoint, providing data for subsequent troubleshooting, success rate statistics, and retries for failed targets.

[0107] In this embodiment of the application, the data collaboration subprocess performs variable extraction and transformation processing on the standardized engineering scheme for each station endpoint mapping, which can completely decouple the rules and variable values. Modification of variable values ​​does not affect the version consistency of the rules. The same rule can generate final execution logic rules adapted to different factories through different variable mapping tables.

[0108] In this embodiment of the application, by executing step S150, based on the promotion log and promotion master log of each receiving endpoint, a fine-grained tracking capability of "batch + rule-by-rule" can be provided. For example, fine-grained tracing can be achieved by the hierarchical tracing link of promotion log → promotion details → traceId → rule execution log, which is a factory-by-factory and rule-by-rule tracing.

[0109] In an applicable scenario, combined with Figure 1 and Figure 3 As shown in the embodiments of this application, the method for promoting standardized engineering solutions in a multi-factory group setting may further include the following steps: S160, Rule Regression: Regress general rules that have been verified and proven effective in multiple factories to standard rules in the standardized engineering solution, or update the corresponding standard rules in the standardized engineering solution based on the factory's custom-optimized rule logic.

[0110] In practical applications, during the execution of the target engineering scheme transformed from the standardized engineering scheme at various receiving endpoints, it may be found that some rules have general value or that the standard rules have been optimized and improved.

[0111] Therefore, in this embodiment, for rules with general value, if they have been verified as effective by multiple factories, they can be elevated to standard rules and reintegrated into the standardized engineering scheme. The effectiveness of a rule can be determined by whether the receiving endpoint of a factory successfully executes the rule, or by other methods; this embodiment does not limit this determination. Furthermore, if a factory has customized and optimized the rule logic of a target rule, the rule logic of the standard rule corresponding to that target rule in the standardized engineering scheme can be updated based on this customized and optimized rule logic.

[0112] In one implementation, step S160 may further include: after the standardized engineering scheme is promoted and implemented, analyzing the promotion master log of this promotion, and then optimizing the standardized engineering scheme based on the analysis results. For example, if the analysis of the promotion master log determines that a certain standard rule of the standardized engineering scheme needs to be optimized, then that standard rule can be optimized.

[0113] In this embodiment of the application, by executing step S160, the standardized engineering solution can be continuously evolved and optimized with the promotion practice, absorbing the best practices of each factory, forming a continuous evolution closed loop of standard definition → multi-factory promotion → feedback optimization → standard update, thereby avoiding the disconnect between the standardized engineering solution and the actual factory.

[0114] In another applicable scenario, combined with Figure 1 and Figures 3-4 As shown in the embodiments of this application, the method for promoting standardized engineering solutions in a multi-factory group setting may further include the following steps: S170. Data cleanup after promotion termination: When a standardized engineering solution needs to be taken offline or its promotion is canceled, a solution cleanup request is sent to each receiving endpoint that has been promoted with the standardized engineering solution. After receiving the solution cleanup request, each receiving endpoint deletes the data related to the standardized engineering solution stored locally.

[0115] In practical applications, when a promotion task ends or a standardized engineering solution is taken offline, historical rules, variables, and logs remain in the operating environments of various factories. The long-term accumulation of these "zombie configurations" leads to an increasingly chaotic operating environment, not only consuming system resources but also potentially causing conflicts between old and new rules, increasing the uncontrollable risks of system operation. Existing solution promotion methods lack standardized, automated cleanup processes.

[0116] Based on this, in the embodiments of this application, when a standardized engineering solution needs to be taken offline or its promotion is canceled, all the site endpoint mappings that the standardized engineering solution has been promoted in the past can be read, and then a solution cleanup request can be sent to each receiving endpoint in all the site endpoint mappings one by one. After each receiving endpoint receives the solution cleanup request, it deletes the data related to the standardized engineering solution stored locally, such as the target engineering solution, the site endpoint mappings corresponding to each receiving endpoint, execution logs and version snapshots, etc.

[0117] In one implementation, for successfully cleaned endpoint mappings, the mapping record can be deleted on the group-side management platform to mark the target as having been cleaned, thus maintaining consistency between the data on the group-side management platform and the actual state of the receiving endpoint; for unsuccessfully cleaned endpoint mappings, the mapping record can be retained on the group-side management platform to mark the pending status, thus facilitating subsequent retries or manual intervention.

[0118] In this embodiment of the application, since the network status and operating environment of the receiving endpoints of each factory are independent, by executing step S170 to clean up the data of each receiving endpoint, the impact of data cleaning failure can be isolated, so that the failure of data cleaning of a single receiving endpoint will not affect the data cleaning of other receiving endpoints. At the same time, system resources can be released to avoid conflicts between old and new rules, thereby avoiding uncontrollable risks in system operation.

[0119] In yet another applicable scenario, combined with Figure 1 and Figures 3-5 As shown in the embodiments of this application, the method for promoting standardized engineering solutions in a multi-factory group setting may further include the following steps: S180, Cross-Environment Migration Solution: When it is necessary to migrate a standardized engineering solution from a test environment to a production environment, or when a standardized engineering solution needs to be promoted to a new factory, only the standard rule set of the standardized engineering solution and the rule logic, common variables and rule variables defined in each standard rule are exported; when importing the standardized engineering solution into the production environment or a new factory, it is allowed to refill the common variables defined in each standard rule in the standardized engineering solution according to the current production environment. After the import is completed, the standardized engineering solution is marked as pending release and the process returns to step S120.

[0120] In practical applications, when standardized engineering solutions need to be migrated across environments (such as from a test environment to a production environment, or from a group standard library to a new factory), existing technologies usually require a large number of manual modifications to configuration items that are strongly related to the environment (such as site identifiers, endpoint addresses, etc.), making the migration process cumbersome and prone to errors.

[0121] Based on this, in this embodiment, when a standardized engineering solution needs to be migrated from a test environment to a production environment, or when a standardized engineering solution needs to be promoted to a new factory, only the standard rule set of the standardized engineering solution and the rule logic, common variables, and rule variables defined in each standard rule are exported. This allows the removal of strongly bound environment data such as sites, endpoints, and site-endpoint mappings from the original environment. Furthermore, when importing the standardized engineering solution into the production environment or a new factory, the solution structure tree (used to show its organization and classification of a group of engineering solutions) and rule tree (used to show the standard rule set) of the standardized engineering solution can be displayed. This allows the common variables defined in each standard rule of the standardized engineering solution to be refilled according to the current production environment, while the rule variables defined in each standard rule remain consistent with the content of the exported package. After the import is completed, the standardized engineering solution is marked as pending release, and the process returns to step S120 to reconfigure the site-endpoint mappings and variable values ​​in the current environment before proceeding with the promotion.

[0122] As an example, standardized engineering solutions can be imported into a production environment or new factory in an idempotent manner, skipping existing data.

[0123] In this embodiment of the application, by executing step S180, a general standardized migration process of "stripping environmentally sensitive information → importing into the target environment → rebinding local resources" can be established, thereby realizing the standardization of cross-environment migration of standardized engineering solutions. The import and export process leaves no environmental residue: during export, environmental binding information such as sites, endpoints and site-endpoint mappings are actively stripped, and only standard business definitions are retained. After import, the standardized engineering solution is in draft state, and the recipient can reconfigure the site-endpoint mappings and variable values ​​according to the current environment before publishing. This avoids import failures and a large amount of manual correction work caused by environmental differences during cross-environment (testing → production, group → new factory) migration.

[0124] In summary, the standardized engineering solution promotion method for a multi-factory group scenario provided in this application creates a standardized engineering solution for this promotion based on business needs on the group side, configures multiple station endpoint mappings for the standardized engineering solution, sets common variable values ​​and rule variable values ​​for each station endpoint mapping, and performs a save operation on all configured station endpoint mappings and the currently set common variable values ​​and rule variable values ​​for each station endpoint mapping using an idempotent strategy. The coordination between these processes can separate the solution definition from the promotion object, achieving the effect that no matter how many new factories are added, the standardized engineering solution only needs to be maintained once. At the same time, the standard content in the standardized engineering solution (standard rule set and the rule logic, common variables and rule variables defined by each standard rule) can be decoupled from factory differences (such as equipment number, database connection, filtering threshold) in a layered manner, so that the standard content can evolve and optimize uniformly without branching versions due to factory differences. Each factory automatically inherits and updates the standard content, thereby ensuring the consistency of the execution content of each factory and avoiding the effect of linear expansion of the number of solutions with the number of factories. That is, one set of standardized engineering solutions can cover all projects, the operation complexity is constant, and each factory does not need to manually follow up and modify when the standardized engineering solution is updated.

[0125] Furthermore, by forcibly fixing all relevant information of this promotion at the current moment into a current version snapshot before the promotion is implemented, this current version snapshot serves as the sole factual basis for this promotion. Regardless of how the standardized engineering plan is modified afterward, the complete promotion content of any historical version can be traced back, thus meeting the requirements for compliance auditing and issue tracing.

[0126] Furthermore, by extracting and transforming variables based on the extracted public and rule variable values ​​at each receiving endpoint, the target engineering solution can be obtained and executed. This automates the placeholder replacement process. Based on the execution results of each target rule in the target engineering solution, the promotion master log and the promotion details corresponding to each receiving endpoint are updated. A hierarchical tracing link of promotion log → promotion details → traceId → rule execution log can be established. By linking these links with batch identifiers, problems can be located to specific factories, specific station endpoint mappings, specific rules, and specific execution stages. This achieves detailed tracing by factory and by rule, which can significantly shorten the problem discovery and repair cycle.

[0127] In summary, the standardized engineering solution promotion method for group-based multi-factory scenarios provided in this application embodiment can provide a layered, decoupled, traceable, and solidified solution promotion mechanism.

[0128] Figure 6 This diagram illustrates a structural block diagram of a standardized engineering solution promotion device for a group-based multi-factory scenario according to an embodiment of this application. Figure 6As shown, the device may include: Create Unit 210, used to create a solution: On the group side, create a standardized engineering solution for this promotion based on business needs. The standardized engineering solution includes a set of standard rules and the rule logic, common variables and rule variables defined for each standard rule in the set of standard rules. The standard rules in the set of standard rules work together. Setting unit 220 is used to set the promotion configuration: configure multiple station endpoint mappings for the standardized engineering scheme, and set common variable values ​​and rule variable values ​​for each station endpoint mapping. Each station endpoint mapping is used to describe the association records between the stations and endpoints involved in this promotion. The endpoints include the receiving endpoints deployed in the factory. Storage unit 230 is used to save the promotion configuration: an idempotent strategy is used to perform a save operation on all configured site endpoint mappings and the currently set public variable values ​​and rule variable values ​​of each site endpoint mapping; The publishing unit 240 is used to publish the plan: it saves all relevant information of this promotion at the current moment into a current version snapshot and generates a batch identifier for this promotion; it batch distributes the current version snapshot and batch identifier to each receiving endpoint in the promotion configuration, creates a promotion master log associated with the batch identifier, and generates promotion details for each site endpoint mapping. The current version snapshot includes the standardized engineering plan, the currently set public variable values ​​and rule variable values ​​for each site endpoint mapping. Execution unit 250 is used to execute the plan: extract the standardized engineering plan and the currently set public variable values ​​and rule variable values ​​of the site endpoint mapping corresponding to each receiving endpoint from the current version snapshot received by each receiving endpoint; perform variable extraction and transformation processing on the standardized engineering plan based on the extracted public variable values ​​and rule variable values ​​in each receiving endpoint to obtain and execute the target engineering plan; and update the promotion master log and the promotion details corresponding to each receiving endpoint based on the execution results of each target rule in the target engineering plan.

[0129] The functions of each unit in the standardized engineering solution promotion device for a group-based multi-factory scenario in this application embodiment can be found in the corresponding description in the above method, and will not be repeated here.

[0130] Figure 7 A structural block diagram of an electronic device according to an embodiment of this application is shown. Figure 7 As shown, the electronic device includes a memory 310 and a processor 320. The memory 310 stores instructions, which are loaded and executed by the processor 320 to implement the standardized engineering solution promotion method in the group-based multi-factory scenario described in the above embodiment. The number of memories 310 and processors 320 can be one or more.

[0131] The electronic device also includes: The communication interface 330 is used to communicate with external devices and perform data exchange and transmission.

[0132] If the memory 310, processor 320, and communication interface 330 are implemented independently, they can be interconnected via a bus to communicate with each other. This bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. This bus can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 7 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0133] Optionally, in a specific implementation, if the memory 310, processor 320 and communication interface 330 are integrated on a single chip, the memory 310, processor 320 and communication interface 330 can communicate with each other through an internal interface.

[0134] This application provides a computer-readable storage medium storing a computer program. When the computer program is run on a computer, it implements the method provided in this application.

[0135] This application also provides a chip, including a processor, for calling and executing instructions stored in a memory, causing a communication device with the chip installed to execute the method provided in this application.

[0136] This application also provides a chip, including: an input interface, an output interface, a processor, and a memory. The input interface, output interface, processor, and memory are connected through an internal connection path. The processor is used to execute code in the memory. When the code is executed, the processor is used to execute the method provided in this application.

[0137] It should be understood that the aforementioned processor can be a Central Processing Unit (CPU), or other general-purpose processors, Digital Signal Processors (DSPs), Application Specific Integrated Circuits (ASICs), Field-Programmable Gate Arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. General-purpose processors can be microprocessors or any conventional processor. It is worth noting that the processor can be a processor supporting Advanced Reduced Instruction Set Machines (ARM) architecture.

[0138] Further, optionally, the aforementioned memory may include read-only memory and random access memory, and may also include non-volatile random access memory. The memory may be volatile or non-volatile, or may include both. Non-volatile memory may include read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. Volatile memory may include random access memory (RAM), which serves as an external cache. Many forms of RAM are available by way of example, but not limitation. Examples include static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous linked dynamic random access memory (SLDRAM), and direct rambus RAM (DR RAM).

[0139] In the above embodiments, implementation can be achieved, in whole or in part, through 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. A computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the flow or function according to this application is 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 transferred from one computer-readable storage medium to another.

[0140] In the description of this specification, references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of this application. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification, as well as the features of those different embodiments or examples.

[0141] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature. In the description of this application, "a plurality of" means two or more, unless otherwise explicitly specified.

[0142] Any process or method description in the flowchart or otherwise herein can be understood as representing a module, segment, or portion of code comprising one or more executable instructions for implementing a particular logical function or process. Furthermore, the scope of the preferred embodiments of this application includes additional implementations in which functions may be performed not in the order shown or discussed, including substantially simultaneously or in reverse order depending on the functionality involved.

[0143] The logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as a sequenced list of executable instructions for implementing logical functions, and can be embodied in any computer-readable medium for use by, or in conjunction with, an instruction execution system, apparatus or device (such as a computer-based system, a processor-included system or other system that can fetch and execute instructions from, an instruction execution system, apparatus or device).

[0144] It should be understood that various parts of this application can be implemented using hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods can be implemented using software or firmware stored in memory and executed by a suitable instruction execution system. All or part of the steps of the methods in the above embodiments can be implemented by a program instructing related hardware, the program being stored in a computer-readable storage medium, which, when executed, includes one or a combination of the steps of the method embodiments.

[0145] Furthermore, the functional units in the various embodiments of this application can be integrated into a processing module, or each unit can exist physically separately, or two or more units can be integrated into a module. The integrated module can be implemented in hardware or as a software functional module. If the integrated module is implemented as a software functional module and sold or used as an independent product, it can also be stored in a computer-readable storage medium. This storage medium can be a read-only memory, a disk, or an optical disk, etc.

[0146] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any person skilled in the art can easily conceive of various variations or substitutions within the technical scope disclosed in this application, and these should all be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for promoting standardized engineering solutions in a multi-factory group setting, characterized in that, include: S110. Create a solution: On the group side, create a standardized engineering solution for this promotion based on business needs. The standardized engineering solution includes a set of standard rules and rule logic, common variables, and rule variables defined for each standard rule in the set of standard rules. The standard rules in the set of standard rules work together. S120. Set up promotion configuration: Configure multiple station endpoint mappings for the standardized engineering scheme, and set common variable values ​​and rule variable values ​​for each station endpoint mapping. Each station endpoint mapping is used to describe the association records between the stations and endpoints involved in this promotion. The endpoints include the receiving endpoints deployed in the factory. S130. Save promotion configuration: Use an idempotent strategy to save all configured site endpoint mappings and the currently set public variable values ​​and rule variable values ​​for each site endpoint mapping; S140. Release plan: Solidify all relevant information of this promotion at the current moment into a current version snapshot, and generate a batch identifier for this promotion; batch send the current version snapshot and the batch identifier to each receiving endpoint in the promotion configuration, and create a promotion master log associated with the batch identifier, and generate promotion details for each site endpoint mapping, wherein the current version snapshot includes the standardized engineering plan, the currently set public variable values ​​and rule variable values ​​for each site endpoint mapping; S150, Execution Plan: From the current version snapshot received from each receiving endpoint, extract the standardized engineering plan and the currently set public variable values ​​and rule variable values ​​of the site endpoint mapping corresponding to each receiving endpoint; in each receiving endpoint, based on the extracted public variable values ​​and rule variable values, perform variable extraction and transformation processing on the standardized engineering plan to obtain and execute the target engineering plan; based on the execution result of each target rule in the target engineering plan, update the promotion master log and the promotion details corresponding to each receiving endpoint.

2. The method according to claim 1, characterized in that, The execution order of the standard rules in the standard rule set is defined by a DAG (Directed Acyclic Graph). Each station endpoint mapping is uniquely determined by a relationship chain of four elements: sending station, receiving station, sending endpoint, and receiving endpoint. The sending station is the local end on the group side, the receiving station is the local end on the factory side, and the sending endpoint is the cloud deployed on the group side.

3. The method according to claim 1, characterized in that, Step S140 specifically includes: Before the standardized engineering solution is officially implemented and promoted, all relevant information of this promotion at the current moment is fixed into a snapshot of the current version, and a batch identifier for this promotion is generated; The current version snapshot is compared with the previously released version snapshot, and the comparison results are presented in a structured form for the publisher to confirm. After the publisher confirms the approval, the optimal publishing path is selected to send the current version snapshot and the batch identifier to each receiving endpoint, and the promotion master log is created, as well as the promotion details of each site endpoint mapping are generated.

4. The method according to claim 1, characterized in that, The current version snapshot also includes application package information of the standardized engineering solution; step S150 specifically includes: an application collaboration sub-process and a data collaboration sub-process; wherein... The application collaboration sub-process adopts a two-stage mechanism that separates download and installation, including: in the download stage, extracting the application package information from the current version snapshot received by each receiving endpoint, downloading the relevant application to the local storage of each receiving endpoint based on the application package information, and entering the installation stage after the integrity verification of the relevant application is passed; in the installation stage, performing installation and running status verification on the local storage of the relevant application at each receiving endpoint, and reporting the installation results. The data collaboration sub-process includes: extracting the standardized engineering scheme and the currently set public variable values ​​and rule variable values ​​of the site endpoint mapping corresponding to each receiving endpoint from the current version snapshot received by each receiving endpoint; performing variable extraction and transformation processing on the standardized engineering scheme based on the extracted public variable values ​​and rule variable values ​​in each receiving endpoint to obtain the target engineering scheme adapted to each receiving endpoint; executing the target engineering scheme through the relevant application in each receiving endpoint, recording the execution result of each target rule in the target engineering scheme, and backfilling the execution result of each target rule into the promotion details corresponding to each receiving endpoint to update the promotion details corresponding to each receiving endpoint; summarizing the execution results of each receiving endpoint, and updating the promotion master log based on the summarized results.

5. The method according to claim 1, characterized in that, The method further includes: S160, Rule Regression: Regress the general rules that have been verified and proven effective by multiple factories to the standardized engineering solution as standard rules, or update the corresponding standard rules in the standardized engineering solution based on the factory-customized and optimized rule logic.

6. The method according to claim 1, characterized in that, The method further includes: S170. Data cleanup after promotion termination: When the standardized engineering solution needs to be taken offline or the promotion is canceled, a solution cleanup request is sent to each receiving endpoint that has been promoted by the standardized engineering solution, so that each receiving endpoint deletes the data related to the standardized engineering solution stored locally after receiving the solution cleanup request.

7. The method according to any one of claims 1-6, characterized in that, The method further includes: S180, Cross-Environment Migration Solution: When the standardized engineering solution needs to be migrated from the test environment to the production environment, or when the standardized engineering solution needs to be promoted to a new factory, only the standard rule set of the standardized engineering solution and the rule logic, public variables and rule variables defined by each standard rule are exported; when the standardized engineering solution is imported into the production environment or a new factory, it is allowed to refill the public variables defined by each standard rule in the standardized engineering solution according to the current production environment. After the import is completed, the standardized engineering solution is marked as pending release and the process returns to step S120.

8. A device for promoting standardized engineering solutions in a multi-factory group setting, characterized in that, include: A creation unit is used to create a solution: On the group side, a standardized engineering solution for this promotion is created based on business needs. The standardized engineering solution includes a set of standard rules and rule logic, common variables, and rule variables defined for each standard rule in the set of standard rules. The standard rules in the set of standard rules work together with each other. The setting unit is used to set the promotion configuration: configure multiple station endpoint mappings for the standardized engineering scheme, and set common variable values ​​and rule variable values ​​for each station endpoint mapping. Each station endpoint mapping is used to describe the association records between the stations and endpoints involved in this promotion, and the endpoints include the receiving endpoints deployed in the factory. The storage unit is used to save the promotion configuration: it uses an idempotent strategy to perform a save operation on all configured site endpoint mappings and the currently set public variable values ​​and rule variable values ​​for each site endpoint mapping; The publishing unit is used to publish the plan: it saves all relevant information of this promotion at the current moment into a current version snapshot and generates a batch identifier for this promotion; it batch distributes the current version snapshot and the batch identifier to each receiving endpoint in the promotion configuration, creates a promotion master log associated with the batch identifier, and generates promotion details for each site endpoint mapping, wherein the current version snapshot includes the standardized engineering plan, the currently set public variable values ​​and rule variable values ​​for each site endpoint mapping; An execution unit is used to execute the plan: extract the standardized engineering plan and the currently set public variable values ​​and rule variable values ​​of the site endpoint mapping corresponding to each receiving endpoint from the current version snapshot received from each receiving endpoint; perform variable extraction and transformation processing on the standardized engineering plan in each receiving endpoint based on the extracted public variable values ​​and rule variable values ​​to obtain and execute the target engineering plan; and update the promotion master log and the promotion details corresponding to each receiving endpoint based on the execution result of each target rule in the target engineering plan.

9. An electronic device, characterized in that, include: A memory and a processor, wherein the memory stores instructions which are loaded and executed by the processor to implement the method as described in any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when run on a computer, implements the method as described in any one of claims 1-7.

Images