Method and system for synchronizing configuration data in a plant

Abstract

The invention relates to a method and system for synchronizing configuration data in a plant, in particular to a method for synchronizing configuration data of components within an industrial plant and the synchronization thereof. The method comprises the steps of partitioning a network in an industrial plant into a first sub-network and a second sub-network, the sub-networks being connected by a network connection. Storing first configuration data on a first local server and via the network connection on a second local server, and storing second configuration data on the second local server and via the network connection on the first local server. Interrupting the network connection; and updating the first configuration data and the second configuration data on the first local server. Reconnecting the network connection; and, if the first configuration data on the second local server has not been changed, overwriting the first configuration data on the second local server by the updated first configuration data.

Description

Technical Field

[0001] This invention relates to the field of industrial plants, and more particularly to the configuration data of components within an industrial plant and their synchronization. The invention also relates to a server, a program element, a computer-readable storage medium, and a method of use. Background Technology

[0002] Industrial plants can be designed for dynamic reconfiguration, and can be configured to manufacture and / or operate chemical, mechanical, or other processes. To this end, the components of the plant can be reconfigured by changing their configuration data. Particularly in plants with distributed control systems, this configuration data and / or copies of it can be distributed across several servers. Summary of the Invention

[0003] The objective of this invention is to provide a method for synchronizing configuration data in a facility, which is distributed across several servers. This objective is achieved through the subject matter of the independent claims. Other embodiments will be apparent from the appended claims and the following description.

[0004] One aspect relates to a method for synchronizing configuration data of components within an industrial plant. The method includes the following steps:

[0005] The network in the industrial plant is divided into a first subnetwork and a second subnetwork, which are connected by a network connection. A first local server and a first component including at least first configuration data are located in the first subnetwork, and a second local server and a second component including at least second configuration data are located in the second subnetwork.

[0006] The first configuration data is stored on a first local server and stored on a second local server via a network connection, and the second configuration data is stored on the second local server and stored on the first local server via a network connection;

[0007] Disconnect the network connection;

[0008] Update the first and second configuration data on the first local server;

[0009] Reconnect to the network; and

[0010] If the first configuration data on the second local server has not been changed, then the first configuration data on the second local server is rewritten using the updated first configuration data.

[0011] Industrial plants may have a network connecting components within the plant and / or components of the plant. Examples of components may include containers, valves, motors, heaters, control elements, sensors, frequency converters (drives), server-like IT infrastructure components, and / or other components. The network may be able to modify the configuration data of the components. Examples of configuration data may include the maximum permissible speed or power of motors, control characteristics of control elements, network configuration details, credentials, allocation of logical signals on physical I / O cards, and / or other configuration data. Configuration data may be distributed across several servers and / or other types of computing machines. Distributed storage of configuration data can facilitate redundancy strategies, i.e., redundancy strategies for components and / or configuration data. Redundancy strategies for components may, for example, include changing the maximum and / or current pump flow rates, for example, a so-called "warm redundancy" strategy used to implement several pumps. Redundancy strategies for configuration data may, for example, include implementing error identification and / or error correction strategies (e.g., a two-thirds strategy) to select the "true" value of the configuration data, where this value is stored on three servers.

[0012] The network of a factory can be divided or partitioned into multiple subnetworks. For the sake of simplicity, the following considerations and explanations are limited to the "first" and "second" subnetworks. However, the considerations and explanations also apply to multiple subnetworks, that is, to any number of subnetworks.

[0013] Network partitioning can be performed according to one or more partitioning strategies and / or criteria. Partitioning strategies may consider, for example, the spatial proximity of components, i.e., each plant or factory room can have its own subnet. Alternatively, partitioning strategies may consider functional relevance or proximity among components, e.g., all components implementing a process phase can be located in one subnet. All subnets can be connected directly (“single-hop”) or indirectly (“multi-hop”) via network connections. In each subnet, at least a component and a local server can be located. A “server” can be any type of computer machine, which can be a hardware and / or software component of any computer machine, and / or can be distributed via more than one computer machine. For simplicity, one or more components located in a first subnet are referred to as “first component”, their configuration data as “first configuration data”, and one or more local servers located in the first subnet as “first local servers”. Similar entities in other subnets are referred to as “second”. These can include entities in one or more subnets. For example, a two-thirds majority vote can consider a “first local server” and two “second local servers”.

[0014] The first configuration data is stored on a first local server and a second local server. The second local server is accessed via a network connection. Similarly, the second configuration data is stored on the second local server and also stored on the first local server via a network connection.

[0015] In the event of a network connection interruption, the second subnet is no longer accessible. Network connection interruption can be caused by network failure (e.g., due to hardware or software defects, maintenance issues), and / or other reasons. During the interruption, the first configuration data and / or the second configuration data can be updated on the first local server so that the updated first configuration data and / or the updated second configuration data are stored on the first local server. After the network connection is reconnected, the configuration data on the multiple local servers needs to be consistent (again). Consistency can be achieved, for example, by applying a strategy throughout the lifecycle of this subnet, network, or facility. The consistency strategy can be selected from several strategies and / or can vary throughout the lifecycle of the subnet, network, or facility. The consistency strategy may include checking whether the first configuration data on the second local server has not changed, and if so, rewriting the first configuration data on the second local server (or all second local servers) with the updated first configuration data. The updated second configuration data may remain unchanged and / or may be the body of the consistency strategy for the second local server.

[0016] Note that "checking whether the first configuration data on the second local server has not changed" is different from checking whether the first configuration data on the second local server has a different "lifetime" than the first configuration data on the first local server, i.e., whether it has been updated previously or later. The "checking unchanged policy" can advantageously lead to consistent configuration data—for example, consistent first configuration data—across all subnetworks without requiring comparison of all replicas of the (first) configuration data. This can facilitate a more robust and / or easily implemented consistency policy across multiple replicas in a distributed control system (DCS).

[0017] In various embodiments, the method further includes the step of: if the first configuration data on the second local server is older than the updated first configuration data, then rewriting the first configuration data on the second local server with the updated first configuration data. This consistency strategy can advantageously take into account the most recent updates to the first configuration data on all local servers of the subnetwork within this facility.

[0018] In various embodiments, the method further includes the step of: if the first configuration data on the second local server has been changed, rewriting the first configuration data on the second local server with the updated first configuration data.

[0019] This rewrite or consistency strategy can be based on the concept of "ownership" of configuration data, meaning that the local server storing configuration data for the same subnet can be considered the "most authentic" local server. The "ownership strategy" can be consistent with the partitioning strategy. Therefore, the "ownership strategy" can give rise to the primary role of the local server within this subnet. The reason for this primary role might be – for example, in spatial proximity – that the personnel caring for the configuration data of a component in a hall can be the one with the most complete configuration data for those components; or – for example, in functional relationships or proximity – this can ensure the functionality of a function or subprocess. Furthermore, this can be used to ensure that local changes are still possible even in the case of network partitioning, allowing for changes in the manufacturing process even under those undesirable conditions.

[0020] In various embodiments, the method further includes the step of writing the configuration data to a log when the first configuration data or the second configuration data is rewritten. This log can store all types of changes within the network or facility. The log can be secure, for example, via blockchain and / or other security mechanisms. The log can advantageously enable service personnel and / or other personnel to track and / or understand changes to the configuration data (e.g., historical changes).

[0021] In various embodiments, the log also includes timestamps for rewrite time, network connection interruption time, and reconnection time. Therefore, the log can facilitate a “global” view of all changes to configuration data within the network or facility. This can be used to correct for recent changes (including automatic changes) and / or to convey information about specific expected (“good”) or undesirable (“bad”) behavior of processes within the facility.

[0022] In various embodiments, the partitioning of the network includes partitioning the network according to at least one of the following: spatial proximity of components; functional proximity of components; security proximity of components; and / or organizational proximity of components.

[0023] Partitioning strategies considering spatial proximity of components can, for example, assign subnets to each building or plant room. Partitioning strategies considering functional relationships or proximity among components can, for example, assign subnets to all components within a process, process stage, and / or subprocess in a network or building. Partitioning strategies considering security proximity of components can, for example, assign subnets to all components behind a firewall. Organizational proximity can consider shared personnel allowed to change equipment configurations. Partitioning strategies can advantageously create "trust zones" within which configuration data resides.

[0024] The advantages, benefits, and / or methods indicated regarding the configuration data may – to a reasonable extent – ​​also apply to other types of data in a network or facility.

[0025] One aspect relates to a program element for performing the methods described above and / or below when the program element is run on a processing unit.

[0026] On the one hand, it relates to a computer-readable storage medium on which a program element, computer program, or computer program product as described above is stored.

[0027] One aspect involves a first local server located in a first subnetwork, which is part of the network in an industrial plant, wherein the first local server is configured as follows:

[0028] The first configuration data is stored on a first local server and on a second local server located in a second subnet, which is connected to the first local server via a network connection.

[0029] After the network connection is interrupted, update the first configuration data on the first local server; and

[0030] After reconnecting to the network, if the first configuration data on the second local server has not been changed, the first configuration data on the second local server is rewritten using the updated first configuration data.

[0031] In some embodiments, the first local server is further configured to: rewrite the first configuration data on the second local server with the updated first configuration data if the first configuration data on the second local server is older than the updated first configuration data.

[0032] In some embodiments, the first local server is further configured to: rewrite the first configuration data on the second local server with the updated first configuration data if the first configuration data on the second local server has been changed.

[0033] One aspect involves a central server configured to store a copy of the configuration data and a copy of the updated first configuration data when the first configuration data is rewritten.

[0034] In some embodiments, the copy of the configuration data also includes a timestamp of the rewrite time of the configuration data, as well as timestamps of the network connection interruption time and reconnection time.

[0035] In some embodiments, the central server includes a log in which a copy of the configuration data, along with optionally timestamps, interruption times, and reconnection times, is stored, and the log is used as the basis for examining the configuration data. The examination of the configuration data may, for example, include the examination of alarms, corrections, learning systems, and / or other events that have occurred on the network or facility.

[0036] On the one hand, it involves the use of a local server and / or a central server as described above and / or below for synchronizing configuration data of components within an industrial plant.

[0037] To further clarify the invention, the present invention is described by way of embodiments shown in the figures. These embodiments are considered as examples only and are not intended to be limiting. Attached Figure Description

[0038] The attached diagram depicts:

[0039] Figure 1 The network of the plant according to an embodiment is schematically depicted;

[0040] Figure 2 A flowchart according to an embodiment is depicted;

[0041] Figure 3 The network of a factory building according to another embodiment is schematically depicted;

[0042] Figure 4 The network of a factory building according to another embodiment is schematically depicted;

[0043] Figure 5 The network of a factory building according to another embodiment is schematically depicted;

[0044] Figure 6 The network of a factory building according to another embodiment is schematically depicted;

[0045] Figure 7 The network of a factory building according to another embodiment is schematically depicted;

[0046] Figure 8 The network of a factory building according to another embodiment is schematically depicted;

[0047] Figure 9 The network of a factory building according to another embodiment is schematically depicted;

[0048] Figure 10 The network of a factory building according to another embodiment is schematically depicted;

[0049] Figure 11 The network of the plant according to another embodiment is schematically depicted. Detailed Implementation

[0050] Figure 1 A network 400 of an industrial plant according to an embodiment is schematically illustrated. Network 400 includes a first subnetwork 100 and a second subnetwork 200, and – at least in some embodiments – further includes subnetworks ( Figure 1(Not shown in the image). The first subnetwork 100 includes at least one first component 110, but may have one or more other first components 120. The first components 110 and 120 include at least first configuration data 111, 112, 121, and 122. For example, the motor as component 110 may include a maximum permissible speed 111 and a maximum permissible power 112; the control element as component 120 may include control characteristics 121 and filtering functions 122. The first subnetwork 100 also includes at least one first local server 180, which is located in the first subnetwork 100 and stores the first configuration data 111, 112, 121, and 122. Similarly, the second subnetwork 200 has at least second components 210 and 220 and a second local server 280, which includes at least second configuration data 211, 212, 221, and 222; both are located in the second subnetwork 200.

[0051] The first subnet 100 and the second subnet 200 are connected via network connection 300. The second local server 280, in addition to the second configuration data 211, 212, 221, 222 that it "owns," also has at least some of the stored first configuration data 111, 112, 121, 122. On the other hand, the first local server 180, in addition to the first configuration data 111, 112, 121, 122 that it "owns," also has at least some of the stored second configuration data 211, 212, 221, 222. "Non-owned" configuration data is stored via network connection 300.

[0052] Sometimes, the network connection 300 between subnet 100 and subnet 200 can be interrupted or disrupted, for example, due to deformation or hardware failure 310. During the interruption, at least some of the configuration data in the first configuration data and the second configuration data 111–222 can be updated. After the deformation or hardware failure 310 is repaired, the network connection 300 is reconnected and the updated configuration data needs to be synchronized to re-establish the consistency of this data (and possibly other data) across all local servers 180, 280. Consistency can be achieved, for example, by applying a strategy throughout the lifecycle of this subnet, network, or facility. The consistency strategy can be selected from several strategies and / or can vary throughout the lifecycle of the subnet, network, or facility. The consistency strategy may include a "check for unchanged strategy," which checks whether the first configuration data 111–122 on the second local server 280 has changed, and if so, rewrites the first configuration data 111–122 on the second local server 280 (or all other local servers) with the updated first configuration data 111–122. The consistency strategy may include checking whether the first configuration data on the second local server 280 is older than the updated first configuration data 111–122. If so, the first configuration data 111–122 on the second local server 280 is rewritten using the updated first configuration data 111–122. Alternatively, the consistency strategy may include: if the first configuration data 111–122 on the second local server 280 has changed, then the first configuration data 111–122 on the second local server 280 is rewritten using the updated first configuration data 111–122.

[0053] Network 400 may also include a central server 480. This central server 480 may be configured to store copies of the configuration data 111–222 during rewriting of the first configuration data 111–222 and copies of the updated first configuration data 111–222. The copies of the configuration data 111–222 may also include a timestamp of the rewrite time of the configuration data, as well as timestamps of the interruption and reconnection times of the network connection 300. Furthermore, the central server 480 may include a log 490. Log 490 may hold copies of the configuration data 111–222, and optionally, timestamps, interruption times, and reconnection times are stored in log 490. Log 490 may advantageously be used as a basis for examining the configuration data 111–222. The examination of the configuration data may, for example, include the examination of alarms, corrections, learning systems, and / or other events that have occurred on the network or facility.

[0054] Figure 2 Configuration data 111–222 for components 110, 120, 210, and 220 within a network 400 in a synchronous industrial plant are shown (see, for example...). Figure 1 The method according to an embodiment is illustrated in flowchart 500. In step 502, network 400 is partitioned into a first subnetwork 100 and a second subnetwork 200, which are connected via network connection 300. The first subnetwork 100 includes at least a first local server 180 and first components 110 and 120, the first components including at least first configuration data 111, 112, 121, and 122. The second local server 280 includes at least a second local server 280 and second components 210 and 220, the second components including at least second configuration data 211, 212, 221, and 222.

[0055] In step 504, the first configuration data 111, 112, 121, and 122 are stored on the first local server 180 and on the second local server 280 via network connection 300. Furthermore, the second configuration data 211, 212, 221, and 222 are stored on the second local server 280 and on the first local server 180 via network connection 300.

[0056] In step 506, network connection 300 is interrupted. During this interruption, at least some configuration data in the first configuration data and the second configuration data 111–222 can be updated. After remedying the interruption, in step 508, network connection 300 is reconnected. The updated configuration data then needs to be synchronized to re-establish consistency of this data (and possibly other data) across all local servers 180, 280. Consistency can be achieved, for example, by applying a strategy throughout the lifecycle of this subnetwork, network, or facility. The consistency strategy can be selected from several strategies and / or can vary throughout the lifecycle of the subnetwork, network, or facility.

[0057] The consistency policy may include step 510, which includes "checking the unchanged policy," i.e., checking whether the first configuration data 111–122 on the second local server 280 has not changed; if so, rewriting the first configuration data 111–122 on the second local server 280 (or all other local servers) with the updated first configuration data 111–122. Alternatively, the consistency policy may include step 512, which includes checking whether the first configuration data on the second local server 280 is older than the updated first configuration data 111–122; if so, rewriting the first configuration data 111–122 on the second local server 280 with the updated first configuration data 111–122. Alternatively, the consistency policy may include step 512, which includes: if the first configuration data 111–122 on the second local server 280 has changed, rewriting the first configuration data 111–122 on the second local server 280 with the updated first configuration data 111–122.

[0058] Figure 3 The network 400 of the plant according to an embodiment is schematically shown. Figure 3 A small example within the first sub-network 100 includes a controller "c1" 110 and a network-connected remote I / O "i1" 120, which may have, for example, multiple physical sensors or actuators connected to its ports via a 4.20mA current loop. To decouple the control application from the I / O port names, a tag configuration database (DB) on a first local server 180 can be used. This DB can be used to decompose abstract tags, such as "tag 1" for a specific port of a specific I / O connector. This means that in order to write "tag 1", controller "c1" needs to first query the database to decompose the tag into the physical location "i1.port 2". Tag information can be stored in the configuration database, which runs on a compute node, such as the first local server 180, a physical or virtual PC, or a server. Note that "tag" is just one example of configuration data within the database, which may also include, for example, network configuration data, credentials, and other entities. To prevent the database from becoming a single point of failure, multiple instances of the database can be created and synchronized, such as... Figure 3As depicted in the example, two database replicas 180 and 280 are deployed in two spatial regions – mapped to subnetworks 100 and 200 of the facility – suitable for hardware deployment. Hardware nodes do not need to be servers: smaller devices such as switches and industrial PCs can be used as additional or alternative deployment targets for the DB replicas, for example, following concepts used in fog computing. Regions can be, for example, buildings, floors, cabinets, cables, or even the same rack within a data center. Because the regions are connected via network 300, the database replicas are synchronized and therefore store the same tagged data. Region segmentation can be chosen based on rules and / or requirements; this may include consideration of available computing resources and / or network infrastructure.

[0059] exist Figure 3 In this configuration, controllers and I / O connectors may have internal area dependencies: for example, “c1” 110 may read and write data from, for example, the input of connector “i1” 120. Furthermore, external area dependencies may exist, for example, for “tag 2” 211 in area 1 or sub-network 100, in case c1 110 needs to access this tag. Synchronization problems may occur between area 100 and area 200 in the event of network interruption 310. For example, inconsistencies between “tag 2” 211 on a second local server 280 and “tag 2” 211 on a first local server 180 (i.e., a copy) may occur when resolving network interruptions. For example, potentially conflicting changes in “tag 1” 111 in a first “owned” sub-network 100 (e.g., located in area 1) and a second “non-owned” sub-network 200 (e.g., located in area 2) may occur at the cost of potential misconfiguration of the facility. One approach to address this could be to "specifically define" network 400 in an industrial plant as a subnet, for example, a first subnet 100 and a second subnet 200. Note that the two subnets are used only as a simplified example; partitioning can be applied to multiple subnets.

[0060] When using spatial proximity of components (“spatial deployment-aware distributed configuration storage”), the spatial area of ​​the plant can be structured as follows:

[0061] a) Existing engineering artifacts in the plant can be used as a foundation. Each area can be associated with at least one computing node (e.g., 180, 280) that is physically located within this area (e.g., subnets 100 or 200, respectively) and connected to its infrastructure. Furthermore, other computing nodes in the IT plant class and controllers in the OT plant class, as well as I / O connectors operating within the area, can be mapped to selected subnets.

[0062] b) Additionally or alternatively, subnets can be structured based on network topology, logical, and / or other "proximity" considerations. Network topology and / or "logical" structures can be constructed using network scanning, monitoring network activity, or accessing information from network devices or a central network control system. Within a subnet, the placement of controllers, remote I / O, and interconnecting equipment in different parts of the network can be directed, which can be used to define the subnet. This approach is also applicable to, for example, Ethernet-based networks. Routers and managed switches can be monitored by a centralized network controller and physical links can be detected, for example, based on LLDP discovery. In networks with multiple Ethernet segments, IP-level routing information on the topology and Ethernet-based connectivity can be combined. Therefore, subnets can be defined, for example, based on spatial areas. A simple example could be a subnet based on IP subnets or Ethernet segments.

[0063] An example of this derived subnetwork is in Figure 4 The description in the middle, Figure 4 A network 400 of a facility with sub-networks 100 and 200 connected via network connection 300 is schematically shown. The description of the area may include hardware in terms of IT hardware (e.g., execution nodes for DB replication) and OT hardware (e.g., controllers and I / O connectors), which, for example, are physically located in the respective area.

[0064] exist Figure 4 In this network, network 400 is divided into subnetworks 100 "Area 1" and 200 "Area 2". Each area includes a first local server 180 ("Node A") and a second local server ("Node B"). Within each subnetwork, different OT (Operational Technology) facilities can operate, for example, controllers / PLCs "c1" 110 and I / O connectors "i1" 120 in subnetwork 100, and "c2" 210 and "i2" 220 in subnetwork 200. Furthermore, for DBs, a defined redundancy level (e.g., 2) can be selected, indicating the requirement that at least two DB replicas be available under normal operation of the inter-area network connectivity.

[0065] A software component called a partition manager can be deployed within each defined region, which becomes active after a network partition between regions is detected. The partition manager is depicted as a portion of local server 180 or 280, respectively. A software component called a merge manager can be deployed within each defined region, which becomes active after network connectivity is restored. These logical entities can, for example, run on one or more physical entities.

[0066] The partitioning and / or limiting of networks 100 and 200 can be done using engineering tools, such as through web-based or desktop-based applications. This tool can also be used for the integration of engineering artifacts, such as manufacturing and IT network connectivity, electronic communications, etc. Database replica deployment to nodes and redundant execution are achieved using distribution managers, such as Kubernetes or Docker Swarm, where container abstractions of database replicas can be used.

[0067] After partitioning, ownership information can be attached to each configuration DB item, such as to "tag". Figure 5 As shown, the tags can be “owned” by subnets 100 or 200 respectively. These tags can be indicated within databases 180 or 280 in the diagram by a prefix – namely “[1]” or “[2]”. Other ownership tags can indicate specific equipment, such as the “i2” or “global” tag, to indicate access only if a network partition between database copies is not detected.

[0068] Figure 6 A network 400 of a factory building according to an embodiment is schematically shown. Network outages 310 can be detected using the following techniques: (1) using a “partition manager” for each sub-network, which monitors the reachability of other areas via heartbeats; (2) a connection exists between the partition manager and the network infrastructure (e.g., switches or routers or network control systems), which can be used to directly detect outages. In the detected network segment ( Figure 6 In the case of interruption 310, the partition manager component is activated. The partition manager component can (a) create additional replicas within the area to meet redundancy requirements when multiple physical nodes are available within the area; and (b) lock entries in the database that do not belong to any subnet or device within the area, i.e., entries not owned by a subnet. Figure 6 In this process, two or more copies are generated within a region (and possibly on different compute nodes within the region). Furthermore, the markers within the database copies are locked (indicated by underlined entries).

[0069] After interrupting network connection 300 via interrupt 310, reconfiguration of the areas within those areas is still possible. For example, "Label 2" in area 2 can be changed to point to "i2.port 42". See [link to relevant documentation]. Figure 7 .

[0070] After the network connection 300 between subnet 100 and subnet 200 is reconnected, the merge manager for the two areas can be activated. For example... Figure 8As shown, this merge manager is configured to (a) infer redundancy to match the new network connectivity structure, and (b) merge the contents of two database replicas based on ownership information, where ownership tags allow for automatic conflict resolution because each entry has an authoritative source of information. Optionally, the merge can be manually confirmed or discarded, for example, by an operator. (c) Unlock previously locked database entries owned by the respective managers. Thus, the number of replicas per region is reduced to 1; the tag 2 entry has been copied to DB replica 1, as owned by region 2; and all tags within the database are unlocked. A consistent state within the plant configuration is restored.

[0071] Figure 9 The network 400 of the plant according to an embodiment is schematically shown.

[0072] In the case of a distributed version control system used to store configurations, this small (“minimum”) configuration can be used. Here, each of the subnets 100 and 200 can hold a local copy (LC) of the configuration data or engineering data. This data will eventually be synchronized with the central version management server. (An alternative may include a “fully decentralized” strategy.) In at least some embodiments of this principle, a continuous online connection between LCs may not be required. Conflicting changes can be made in each LC, for example, changing the flag 1111 to save the conflict mapping of I / O and ports. In this case, the merge manager can be used to (1) prevent the introduction of those changes into the engineering artifacts, or (2) allow for (semi-)automatic merging of engineering data using ownership information defined by plant segmentation.

[0073] Figure 10 A schematic diagram of a plant network 400 according to an embodiment is shown. This diagram illustrates the so-called "pre-commit workflow." Here, a component or client from sub-network 100 attempts to change "Tag 2," an artifact owned by sub-network 200. Ownership checks are performed by the merge manager 180 of sub-network 100 before submission to the version control server. Therefore, merge manager 180 can detect changes to non-owned information and can consult merge manager 280 of sub-network 200 that requires approval of the change. This may include the engineering team involved with sub-network 200. Until then, the commit is staged or rejected.

[0074] Alternatively, if a conflict commit has already been pushed, the merge process may require the following steps: Figure 11As depicted in the diagram. When two conflicting tasks are available in the LC, merge managers 180 and 280 can detect ownership information and perform automatic merging. Merge managers 180 and 280 can be implemented as dedicated servers or as integrated functionality within one or more computers in a facility. In the example, the task "Tag 2" in subnet 200 will have a higher priority than the task "Tag 2" in subnet 100 because it originates from the "owned" subnet 200. Therefore, both managers can take over the task "Tag 2" potentially without manual intervention from engineers. In at least one embodiment, the merge can be logged in log 490, which is located, for example, in a central server 480.

Claims

1. A method for synchronizing configuration data (111–222) of components (110, 120, 210, 220) within an industrial plant, the method comprising the steps of: The network (400) in the industrial plant is divided into a first subnetwork (100) and a second subnetwork (200), and the subnetworks (100, 200) are connected by a network connection (300). A first local server (180) and a first component (110, 120) including at least one first configuration data (111, 112, 121, 122) are located in the first sub-network (100), and The second local server (280) and the second component (210, 220) including at least one second configuration data (211, 212, 221, 222) are located in the second sub-network (200); The first configuration data (111, 112, 121, 122) is stored on the first local server (180) and on the second local server (280) via the network connection (300). The second configuration data (211, 212, 221, 222) is stored on the second local server (280) and also on the first local server (180) via the network connection (300); Disconnect the network connection (300); Update the first configuration data (111, 112, 121, 122) and the second configuration data (211, 212, 221, 222) on the first local server (180). Reconnect the network connection (300); and If the first configuration data (111, 112, 121, 122) on the second local server (280) has not been changed, then the first configuration data (111, 112, 121, 122) on the second local server (280) is rewritten using the updated first configuration data (111, 112, 121, 122); and If the first configuration data (111, 112, 121, 122) on the second local server (280) has been changed, the first configuration data (111, 112, 121, 122) on the second local server (280) is rewritten by the updated first configuration data (111, 112, 121, 122) because the first local server (180) is the owner of the first configuration data (111, 112, 121, 122), wherein the first configuration data (111, 112, 121, 122) is marked with ownership information indicating that the first local server (180) is the owner of the first configuration data (111, 112, 121, 122), and wherein the ownership information indicates the role assigned to the first configuration data (111, 112, 121, 122).

2. The method according to claim 1, further comprising the following step: If the first configuration data (111, 112, 121, 122) on the second local server (280) is older than the updated first configuration data (111, 112, 121, 122), then the first configuration data (111, 112, 121, 122) on the second local server (280) is rewritten using the updated first configuration data (111, 112, 121, 122).

3. The method according to claim 1, further comprising the following step: When the first configuration data (111, 112, 121, 122) or the second configuration data (211, 212, 221, 222) is rewritten, the configuration data is written to the log (490).

4. The method according to claim 3, The log (490) also includes a timestamp of the rewrite time, and timestamps of the interruption and reconnection times of the network connection (300).

5. The method according to claim 1, The partitioning of the network (400) includes partitioning the network (400) according to at least one of the following: The components (110, 120, 210, 220) are spatially adjacent; The components (110, 120, 210, 220) are functionally adjacent; The safety proximity of the components (110, 120, 210, 220); and / or The components (110, 120, 210, 220) are in close proximity.

6. A program element for executing the method of claim 1 when the program element is run on a processing unit.

7. A computer-readable storage medium wherein the program element according to claim 6 is stored on the computer-readable storage medium.

8. A first local server (180) located in a first sub-network (100), the first local server (180) being part of a network (400) in an industrial plant, wherein the first local server (180) is configured to: The first configuration data (111, 112, 121, 122) is stored on the first local server (180) and on a second local server (280) located in the second sub-network (200), the second local server (280) being connected to the first local server (180) via a network connection (300). After the network connection is interrupted (300), the first configuration data (111, 112, 121, 122) is updated on the first local server (180); and After reconnecting the network connection (300), if the first configuration data (111, 112, 121, 122) on the second local server (280) has not been changed, the first configuration data (111, 112, 121, 122) on the second local server (280) is rewritten using the updated first configuration data (111, 112, 121, 122). And if the first configuration data (111, 112, 121, 122) on the second local server (280) has been changed, the updated first configuration data (111, 112, 121, 122) is used to rewrite the configuration data. The first configuration data (111, 112, 121, 122) on the second local server (280) is rewritten because the first local server (180) is the owner of the first configuration data (111, 112, 121, 122), wherein the first configuration data (111, 112, 121, 122) is marked with ownership information indicating that the first local server (180) is the owner of the first configuration data (111, 112, 121, 122), and wherein the ownership information indicates the role assigned to the first configuration data (111, 112, 121, 122).

9. The first local server (180) according to claim 8 is further configured to: If the first configuration data (111, 112, 121, 122) on the second local server (280) is older than the updated first configuration data (111, 112, 121, 122), then the first configuration data (111, 112, 121, 122) on the second local server (280) is rewritten using the updated first configuration data (111, 112, 121, 122).

10. A central server (480) configured to store copies of configuration data (111–222) and copies of the updated first configuration data (111, 112, 121, 122) as claimed in claim 8 or 9 when rewriting first configuration data (111, 112, 121, 122).

11. The central server (480) of claim 10, wherein the copy of the configuration data (111–222) further includes a timestamp of the rewrite time of the configuration data, and timestamps of the interruption and reconnection time of the network connection (300).

12. The central server (480) according to claim 11, including a log (490). The copy of the configuration data (111–222), along with the timestamp, the interruption time, and the reconnection time, are stored in the log (490), and The log (490) is used as the basis for examining the configuration data (111–222).

13. The use of the local server (180) according to claim 8 or 9 and / or the central server (480) according to any one of claims 10 to 12 for synchronizing configuration data of components (110, 120, 210, 220) within an industrial plant.

Images