Synchronizing information model changes between hierarchical systems of smart plants

Abstract

A system and method for synchronizing information model changes between hierarchical systems of a smart plant is disclosed. A model generator instantiates an object of an aggregated information model for each of a plurality of subsystems in a smart plant based on an OPC UA standardized model. The synchronization engine maintains a global timestamp variable of a last successful synchronization performed by the parent OPC UA server for synchronization to a second aggregate information model instance stored in the lower level OPC UA server. Model nodes are annotated with node-by-node timestamps in response to modifications to the nodes. All the nodes undergoing the modification are pushed to a priority queue as a serialized node set format having an annotation extension that includes synchronization related data. The first aggregated information model and the second aggregated information model are synchronized by updating the nodes with the synchronization-related data.

Description

Technical Field

[0001] The present application relates to information modeling. More specifically, the present application relates to information models and data exchange between hierarchical systems of synchronized smart factories. Background Art

[0002] A smart factory, also known as a connected factory, is a digital manufacturing facility that uses connected devices, machinery, and production systems to continuously collect and share data. This data is then used to inform decisions to improve processes and resolve any issues that may arise. The smart manufacturing practices used by smart factories are enabled by a variety of technologies including artificial intelligence (AI), big data analytics, cloud computing, and the Industrial Internet of Things (IIoT). Smart factories rely on providing seamless information exchange between systems at various levels of the manufacturing hierarchy.

[0003] The technical problem faced in the industry is that different information models are created individually within various industrial control and software systems such as programmable logic controllers (PLCs), supervisory control and data acquisition (SCADA), historians, and in cloud applications. Often, these various information models do not match in schema and therefore inconsistencies occur. A lot of effort may be invested in the manual engineering of such information models and in trying to connect the information models while keeping the information synchronized. Existing technical solutions rely on manual information model onboarding in the cloud and then sending data on the already established model. Changing the semantics of information on one system (e.g., the underlying hierarchical device) requires a lot of re-engineering effort on the other side of the hierarchical system (e.g., the cloud). Therefore, the cost of maintaining consistent information at various levels of the smart factory is very high. Summary of the invention

[0004] A system and method for synchronizing information model changes between hierarchical systems of a smart factory is disclosed. A model generator instantiates an object of an aggregate information model of each of a plurality of subsystems in a smart factory based on an Open Platform Communications Unified Architecture (OPC UA) standardized model. OPC UA is a data exchange standard for industrial communications (e.g., machine to machine, PC to machine). A synchronization engine maintains a global timestamp variable of the last successful synchronization performed by a parent OPC UA server for synchronization to a second aggregate information model instance stored in a subordinate hierarchical (i.e., child) OPC UA server. Model nodes are annotated with node-by-node timestamps in response to modifications to the nodes. All nodes that have undergone modifications are pushed to a priority queue as a serialized node set format having an annotation extension including synchronization-related data. The first aggregate information model and the second aggregate information model are synchronized by updating the nodes with synchronization-related data. BRIEF DESCRIPTION OF THE DRAWINGS

[0005] Non-limiting and non-exhaustive embodiments of the present invention are described with reference to the following figures, wherein like reference numerals refer to like elements throughout unless otherwise specified.

[0006] Figure 1 A framework for synchronizing changes to information models across multiple levels of a hierarchical system in a smart factory according to an embodiment of the present disclosure is illustrated.

[0007] Figure 2 An example of an information model for synchronization according to an embodiment of the present disclosure is shown.

[0008] Figure 3 An example of a flow chart of a method for synchronizing nodes in a cold start scenario according to an embodiment of the present disclosure is shown.

[0009] Figure 4 An example of a flow chart of a method for synchronizing nodes in a running scenario according to an embodiment of the present disclosure is shown.

[0010] Figure 5 An example of a method flow chart of a synchronization process according to an embodiment of the present disclosure is shown.

[0011] Figure 6 An example of a computing environment is illustrated within which embodiments of the present disclosure may be implemented. DETAILED DESCRIPTION

[0012] Methods and systems are disclosed for seamlessly creating, managing, synchronizing, and providing information at all hierarchical levels in a smart factory to enable bottom-up and top-down information exchange. For example, information from bottom-level subsystems (e.g., on the shop floor) such as robots and computer numerical control (CNC) machines needs to be continuously available at upper levels (e.g., the cloud) for monitoring, dashboard, and analysis purposes. The technical problem of information model sharing is how to timely and accurately reflect changes in bottom-level operations due to production downtime, upgrades, etc. Information may also be enhanced at the top level through business intelligence, which may directly affect operations at the bottom level in terms of optimizing processes (e.g., throughput) or resources (e.g., energy consumption).

[0013] Embodiments of the present disclosure automate the engineering and synchronization process of information (schema and data changes) between various levels in a smart factory (e.g., shop floor to cloud, and vice versa). On the one hand, the OPC-UA standard is used to engineer information models, thereby taking advantage of the availability of already existing supporting specifications. The schema and data associated with the information generated on the shop floor are automatically synchronized with upstream subsystems that aggregate information from several subsystems in near real time with zero engineering work. On the one hand, object model updates are pushed to computers with advanced computing capabilities, typically cloud-based computers, where detailed data analysis is performed. Object model updates can also be pushed to other computing devices, such as devices at the edge or in the shop floor. Therefore, information is instantly received at the upper levels of the hierarchical system, allowing near real-time monitoring, dashboards, and analysis use cases. With the automation of information model push and synchronization, the steps of creating and maintaining models at several levels are avoided. The technical advantages of the disclosed embodiments include pushing object model structure information instead of pushing all data as a data streaming process. Utilizing a replicated model at an upper level that is able to generate data just like the equipment on the shop floor eliminates the need to send all sensor data upstream in real time. This improves responsiveness by avoiding the lag in conventional systems that stream all data.

[0014] The configuration for synchronization is done on the OPC-UA server of one of the downstream systems. These systems enable the model to be pushed to the next higher level system as soon as the information changes. The semantics of the information is thus preserved between the shop floor and the cloud, providing a unified way to query consistent information across all levels of the entire hierarchical system.

[0015] The OPC UA standardized model is designed to be platform-independent. It relies on an object-oriented framework in which information is specified by objects and associated variables, methods, and properties. OPC UA operates using a protocol binding layer with standardized transports and encodings. Transports can include client / server (e.g., RCP, HTTPS protocols for one-to-one communication) and publish / subscribe (e.g., UDP, TSN, QMQP, MQTT protocols for one-to-many communication). Encodings can include client / server and publish / subscribe (e.g., UA binary, JSON, XML). However, OPC UA does not have a built-in mechanism for model synchronization. Although mechanisms exist for model change notifications, there is not enough capability to build complex synchronization mechanisms. For example, using the OPC UA mechanism without modification will not adequately cope with connection loss, because during this period there is no information whether the information model has changed or which parts of the information model have changed. This leads to the trouble of re-browsing the address space after reconnection. The OPC UA Publish / Subscribe (Pub / Sub) messaging mechanism does not provide subscriptions to model changes, but only subscriptions to value changes.

[0016] In one aspect, embodiments of the present disclosure implement technical improvements made on top of the OPC UA mechanism. For example, a framework for using timestamps and confirmations between the two system layers is built. In addition, the XML node collection files of the OPC UA protocol are also used as a means to carry synchronization specific information (such as representations of information in an OPC UA server). Updates are reflected in the model on the server itself, including any deleted or added nodes on the model. The current OPC UA publish / subscribe mechanism does not support this synchronization capability.

[0017] Figure 1A framework for synchronizing information model changes at various levels of a hierarchical system in a smart factory according to an embodiment of the present disclosure is illustrated. The smart factory 100 includes a hierarchical system including a bottom level 101 and a top level 121, the bottom level having various subsystems 105, robot 1, robot 2, PLC 108, and the top level with an OPC UA server 122 running as a cloud 123 device or an industrial edge 124 device. The hierarchical structure may include one or more intermediate levels, such as those shown by the OPC UA server 110. In some instances, the OPC UA server 110 may be an edge device having a parent server 122 as a cloud-based device. The subsystem 105 may include plant equipment and associated industrial control and software systems, such as PLCs, SCADA, and historical databases. The problem that needs to be solved is that each type of plant equipment may have its own vendor-provided server, and the information from these different servers needs to be integrated and synchronized according to the hierarchical structure of the smart factory 100 (e.g., unit, production line, plant area). For example, a cell may consist of three robots, a production line may have three cells, and a plant may have twenty production lines. The user may choose to set up synchronization for the top level 121 at a cloud-based server or an edge-based server. Different information models may be aggregated at a single server as a plant-wide aggregation, such as at a UPC UA server 110 or 122. Alternatively, a framework for embodiments of the present disclosure may involve localized aggregation at multiple levels. Based on the type of aggregation arrangement, a parent server is identified and specified for how to push model information updates.

[0018] Each OPC UA server can be configured as shown in OPC UA server 110, which includes a model generator 111 and a synchronization engine 112. The model generator 111 is configured to instantiate objects of the information model of each corresponding subsystem 105 and objects of the aggregated information model that are pushed to the top level 121 for monitoring and analysis by the OPC UA server 122. For example, an engineer using the OPC UA client 113 or an OPC UA client located elsewhere in the smart factory 100 can instantiate a specific PLC 108. The model generator 111 of the OPC UA server 122 then models the variables and parameters associated with the specific PLC using a unified, standardized OPC UA protocol. Similarly, other PLCs and all OPC UA-compatible devices (e.g., SCADA, Profinet) in all levels of the smart factory 100 can be instantiated so that each modeled object has a similar, unified structure to be read and understood, regardless of the type of hardware or device implementation.

[0019] Figure 2 An example of an information model for synchronization according to an embodiment of the present disclosure is shown. In this example, Figure 1 A portion of the hierarchical structure shown in is represented in information model 200 for illustrative purposes. The nodes of the OPC UA-based information model include objects of the smart factory, such as robot 1, robot 2, and PLC. In some instances, the nodes are connected by relationships, such as drive train_1 moves axis_1, and the gear is driven by the motor. To illustrate how the need for model synchronization arises, information model 200 represents an aggregate information model instance of OPC UA server 110. When changes to the information model occur, such as adding a new node to the model to represent the addition of PLC 108 to the smart factory 100, OPC UA server 118 must synchronize its instance of the information model with the current information model stored by the parent server 110. The new node for PLC 108 will be added to the information model 200 through information, timestamps, and / or confirmations between server 110 and server 118. The model update will then be pushed upward from OPC UA server 110 to its parent OPC UA server 122.

[0020] The synchronization engine 112 of the OPC UA server is configured to perform automated synchronization of information model changes of each of the subsystems 105 with the aggregate information model used by the parent OPC UA server. In an embodiment, when the synchronization engine 112 of the OPC UA server 110 detects any information model changes, these changes are pushed to the aggregate information model of the parent OPC UA server 122 in near real time. The synchronization engine 112 is configured to perform synchronization according to one or more of the following design features.

[0021] Feature 1: Synchronization is strictly unidirectional from the bottom level 101 (eg, unit level) to the top level 121 (eg, cloud).

[0022] Feature 2: The OPC UA servers in the smart factory 100 are configured with a tree-like system structure, whereby each OPC UA server can have multiple children but only one parent.

[0023] Feature 3: Synchronization is independent of the actual transmission channel, which can be configured according to the specifics of the platform (e.g. Industrial Edge Platform or MindSphere) or even lead to a completely different protocol, as long as the required quality is met.

[0024] Feature 4: Synchronization is performed at a node-by-node granularity. Not all nodes of the information model must be included in the synchronization process. For example, some nodes associated with specific lower-level subsystem components 105 can be excluded at the user's discretion to keep the synchronization process more streamlined and easier to manage. Since there are nodes that represent type definitions (i.e., the semantics and properties of variables) and nodes that represent instances, some exclusions may include type nodes while other exclusions may include instances. As an example of a type node, type information can be used by a knowledge graph that can extract information from a large amount of interrelated and semantic data. As a specific example, a motor temperature variable can be used to monitor motor strain, which can be extracted from the semantics attached to the variable.

[0025] Feature 5: Each synchronized node is confirmed by the parent server. The parent server confirms when it receives the process push information of the node object model. In an embodiment, the confirmation indicates that a single node has been synchronized. In another embodiment, the confirmation indicates the collective synchronization of the set of node model information pushed to the parent server. For example, an edge-based child OPC UA server can sense the presence of multiple new node object models and push the new model information as a serialized node information format (such as an XML node collection) to a cloud-based parent server. The parent server deserializes the information into an OPC UA node in the aggregate information model by appending to an OPC structure or OPC address list. Once this is processed at the parent server, the confirmation sent by the parent server indicates that the push information of (one or more) nodes has been verified and persisted in the replication model, and therefore will be available if any failure occurs that requires restarting. Therefore, when a lower-level server (e.g., an edge server) is cold-started after an outage, the replicated model of the parent server can be compared with the repaired model on the lower-level server, and the difference between the two models needs to be synchronized for checking the repaired model. In this example, the replicated model at the parent server serves as a backup for the mirror image of the repaired model at the subordinate tier servers.

[0026] In an embodiment, confirmation is solved by a publish / subscribe mechanism that utilizes a proxy that can also act as a subscriber. Communication protocols with QoS level 1 or 2 (e.g., MQTT) can further ensure that the message reaches the well-known subscriber, while the conventional setup with a separate proxy in the middle can only ensure that the message is received by the proxy, but will not give any indication to the subscriber. In the latter setup, subscribers and publishers are independent of each other. In addition, application-level protocols (e.g., confirmation on separate topics) can be used.

[0027] Feature 6: Synchronization is applied to changes detected in the object model; node value changes are not within the scope of one-way synchronization. For example, changes in the real-time temperature value from a temperature sensor node do not need to be synchronized.

[0028] Feature 7: Synchronization occurs between two aggregate information model instances: one model on a subordinate level server, and the other model on its parent level server.

[0029] In an embodiment, the synchronization engine 112 synchronizes individual nodes (either individually or in some kinds of bulk operations, lists of nodes) built around OPC UA (XML) node sets. Synchronization is accomplished by signaling modifications upward and getting confirmation from the parent server that the modifications were received and successfully applied. Timestamps are used to keep track of modifications and / or synchronization status. All modifications are signaled via messages carrying at least one affected node that is undergoing synchronization. In bulk operations, several nodes may be packaged into a single message. To avoid overwhelming the parent server with update messages, different messages associated with different nodes are not sent in parallel.

[0030] Model changes include node addition, node update and node detection and are notified using the OPC UA object GeneralModelChangeEventType. Model change events for connected devices at the lower level are detected by the lower level (child) OPC UA server and the server then captures the changes to the information model of that level. Once the model update is complete, the lower level OPC UA server notifies the parent OPC UA server of the change, which initiates the synchronization process between the child OPC UA server and the parent OPC UA server. Normally, value changes are not reported through synchronization. However, there are exceptions for values ​​that have some semantic meaning. For example, a change in the measurement unit from Fahrenheit to Celsius will be notified using the OPC UA object type SemanticChangeEventType, but will be treated like a regular value change in this concept. Nodes that are removed but not yet synchronized must remain in the local node collection, and all references to these nodes have been removed. This converts these nodes into hidden nodes during browse operations. After confirmation by the parent server, the nodes can eventually be discarded.

[0031] Since individual nodes use addresses that refer to local namespace arrays of collections of nodes or servers, synchronization requires additional knowledge about the composition of node IDs. When nodes are exchanged between two aggregate information model instances, the models either share the same namespace array or provide a local namespace array to the parent for index transformation. When the namespace array is shared, the namespace is shared across all aggregate information model instances in the system. This sharing simplifies addressing efforts by having a stable namespace index throughout the overall system, and by enabling the use of short addresses rather than fully qualified addresses with lengthy namespace strings.

[0032] In an embodiment, node annotations are applied using extensions via an OPC UA (XML) node collection definition. Extensions can have local or proprietary meaning, such as mapping definitions between an internal process image and an OPC UA information model. For example, the Siemens OPC Modeling Editor (SiOME) can be used to generate annotations for mapping tags. Another example is an editor for creating node collection files. The synchronization engine 112 annotates nodes with extensions that include synchronization-related data. One or more of the following attributes can be included in the node annotation: (1) an indication of whether the node participates in synchronization; (2) any constraints on the parent server, including adjusted permissions, such as nodes that can be read or written locally but should be read-only on the parent level (e.g., in the cloud); (3) the scope of the synchronization level, such as the maximum number of synchronization levels (e.g., only two synchronizations / jumps) or the final synchronization level (e.g., only up to the plant level, but not to the cloud); (4) the timestamp of the last modification or synchronization. Extensions do not undergo synchronization, except for those extensions that are relevant to further synchronization. The synchronization of the previous level can be synchronized. Constraints on the parent may not be synchronized. Instead, the node may simply reflect the correct permissions according to the defined constraints when it is sent to the parent server.

[0033] The synchronization procedure can be triggered by changes to the local Aggregate Information Model instance, such as when a node is created, updated, or removed. The synchronization procedure can also be triggered by the local Aggregate Information Model instance and its parent (re)establishing a connection. While the Node Collection may save all relevant information in various cases, including: (1) whether the node participates in synchronization, (2) when it was last synchronized, and (3) whether it has recently undergone a modification (CUD), the Aggregate Information Model instance can keep track of a reference list of all affected nodes to be synchronized as an optimization feature. At runtime, the Aggregate Information Model instance only processes those nodes that have not yet been synchronized. On a cold start, the Aggregate Information Model instance processes all nodes when importing the Node Collection into the address space of the OPC UA Server.

[0034] Two examples of timestamp strategies are now described. As a first example, modification timestamps are recorded in response to model modifications. The advantage of this approach is that the node set must be persisted anyway; the timestamp is part of the persistence. Once the parent server confirms that the node change is received and the parent server's information model instance is updated accordingly, all nodes up to a certain timestamp can be considered synchronized successfully. For this approach, synchronized nodes are pushed in strict chronological order. For cold starts, this may result in an additional run to collect all nodes to be synchronized and sort them according to timestamps. Nodes with the same timestamp must be sent (and confirmed) together in a batch operation to ensure that the complete set of nodes with that timestamp can be considered synchronized. Modifications are published once the previous message is confirmed. Otherwise, messages may surpass each other and the most recently confirmed timestamp will be higher, while nodes with older timestamps have not yet been confirmed.

[0035] As a second example of a timestamp strategy, timestamps are performed in response to confirmations. The advantage of this approach is that the temporal order of modifications is irrelevant. For cold starts, processing of nodes can be performed in the order in which the nodes appear. The local aggregate information model instance can simply publish a synchronization message when it is triggered or processes any node. For each node, the stamping of confirmations must be tracked. This may cause the node collection to be persisted after each confirmed modification, which works well in the case of batch operations. Alternatively, the timestamps can be tracked based on a list stored separately from the node collection itself.

[0036] Figure 3An example of a method flow chart for steps associated with a cold start synchronization scenario according to an embodiment of the present disclosure is shown. In an embodiment in which synchronization is achieved in response to a modification, the synchronization engine 112 annotates each node with a modification timestamp (i.e., a node-by-node timestamp) of the time when the node was last modified. A global flag of the information model called Last_successful_sync is maintained using a timestamp value that reflects the last time that the information model instance was successfully synchronized with another information model instance. For a cold start, the following steps apply to each node associated with the serialized node set to be pushed to the parent server. At step 301, the synchronization engine 112 waits until the address space of the OPC UA server is created. A node is selected from the address space (step 302), and the node is checked to see if it meets the synchronization conditions (step 303). As explained in feature 4 above, in order to maintain the efficiency and manageability of synchronization, not all nodes must be included in the synchronization. For example, based on a cost / benefit analysis, it can be determined that all nodes of type "X" can be excluded from synchronization with minimal impact on the aggregate information model across the plant. As a specific example, node types that contain certain static information (e.g., device-specific information that never changes) should be excluded from synchronization. Additionally, blob data (i.e., unstructured data) resulting from historical data dumps can be quite large and can be passed from a child OPC UA Server to a parent OPC UA Server over different channels as part of different processes. Any nodes tied to such data would be excluded from synchronization. Information exchange during Information Model Synchronization is reserved only for minor changes to the OPC UA Model.

[0037] If the selected node meets the synchronization conditions, the modification timestamp of the node is read (step 304) and compared with the timestamp value of the variable Last_successful_sync (step 305). If the read timestamp is later than the timestamp value of the variable Last_successful_sync, the node is pushed to the priority queue for synchronization (step 306). The priority queue can be a list of pending synchronizations sorted by timestamp, starting with the earliest timestamp. For the timestamp comparison of step 305, if the timestamp is not later than the timestamp value of the variable Last_successful_sync, the process repeats steps 302 to 305 for the next node. In step 307, the address space is scanned to obtain more nodes to be checked for synchronization until all nodes are exhausted. All nodes in the priority queue are now ready to be serialized for synchronization.

[0038] In an alternative embodiment where timestamps are recorded in response to sync acks from a parent server, each node is associated with two timestamps: (1) a modification timestamp reflecting the last modification to the node, and (2) a syncAck (sync ack) timestamp representing the time of the last sync ack by the parent server for an update to the node in the parent server's information model instance. In one aspect, the syncAck values ​​may be stored in a separate file with references to the node IDs (e.g., a table or list of all node IDs and corresponding syncAck timestamp values), and thus, annotation of the node with that timestamp is optional. According to this alternative embodiment, Figure 3 The process shown in is modified at step 305a, the modification timestamp is compared with the syncAck timestamp. In addition, since the identification of nodes undergoing modification is based on node-by-node synchronization confirmation, no priority queue is required, and the modified step 306a reflects the push to the normal queue.

[0039] Figure 4 An example of a method flow chart for steps associated with a running synchronization scenario during runtime according to an embodiment of the present disclosure is shown. In an embodiment of synchronization during runtime, each node that undergoes modification (addition, update, removal) is added to a node set with a current timestamp. In this example, the nodes of the model instance of the OPC UA server 110 are being compared with the model instance of the OPC UA server 115. The synchronized node set can be persisted for later cold starts including timestamps. Nodes are added to a list of pending synchronizations called a priority queue, and the list is continuously sorted with each new entry with the most recent timestamp added to the end.

[0040] Figure 4 The method shown in is similar to the one described above for Figure 3The method described shares common steps 302 to 307. Additional steps 401 to 403 are about address spaces and persistence of nodes related to processing only nodes that have not yet been synchronized, which enables efficient synchronization. The process starts by the OPC UA server 115 checking for any updates to its own model, which then needs to be synchronized with the parent OPC UA model. In step 401, the synchronization engine 112 browses each node of the information model of the subordinate level OPC UA server 115 and timestamps each node as it is browsed. If the synchronization condition is met (e.g., newly created, updated, or deleted), the node can be marked as meeting the synchronization condition by the synchronization engine 112. In step 402, an address space is created for the newly browsed node at the OPC UA server 110. In step 403, a node set (e.g., Nodeset2.xml) of the browsed node is persisted. Execute steps 302 to 304, 305 / 305a, 306 / 306a, 307 to generate a node set in the priority queue, which node set will be as described above for Figure 3 The nodes are synchronized using any of the timestamping methods described above. For this example, step 304 reads the browsed timestamp, and in step 305 the browsed timestamp is compared with the timestamp value of the variable Last_successful_sync. If the browsed timestamp is not later than the timestamp value of the variable Last_successful_sync, then the node has been synchronized. Similarly, in step 305a, the browsed timestamp is compared with the timestamp value of the variable syncAck.

[0041] Figure 5An example of a method flow chart for serialization and synchronization of nodes according to an embodiment of the present disclosure is shown. In an embodiment, the synchronization process runs in parallel threads and picks nodes from a priority queue (when available). There is a global timestamp variable Last_successful_sync maintained at the information model level (i.e., the timestamp of each node is compared with the common timestamp variable value (Last_successful_sync)). For this example, the OPC UA server 110 is synchronizing its model instance with the information model instance of the parent OPC UA server 122. In step 501, the synchronization engine 112 checks whether the parent OPC UA server 122 is available. If not, the synchronization engine 112 waits for the parent to come online (step 502). When the parent server comes online, the timestamp value of the variable Last_successful_sync of the local server is obtained from the parent server (step 504). In step 503, for each node, it is checked whether it is available for synchronization in the priority queue. The priority queue uses the modification timestamp to prioritize. In step 505, if the node is available, the node is picked from the priority queue and serialized (step 506). In an alternative embodiment where the timestamp is verified at the node level, the modified step 506a can be performed in parallel for multiple nodes. At least one serialized node is sent to the parent server in a synchronization message for synchronization (step 507) and awaits confirmation (step 508). In the case of multiple nodes with equal timestamps, all serialized nodes are included in the same synchronization message. If confirmation is received in step 509, the timestamp value of the variable Last_successful_sync is updated with the timestamp value of the current node (step 510). If the parent cannot be reached, or the parent does not confirm in time, further attempts are made. Timestamps are local to the aggregate information model instance.

[0042] In one aspect, the parent OPC UA Server may track the child OPC UA Server timestamp and provide the last known timestamp of Last_successful_sync when the communication link is established. In this case, the parent server resets the timestamp variable Last-successful-sync for the child OPC UA Server (e.g., because the parent cannot fully persist the last synchronization state or must roll back to a historical state). If the timestamp can be decreased (to a previous point in time), all nodes are iterated as in the cold start scenario to find all nodes to be considered. The removed nodes should remain in the local node set for a period of time and then be finally deleted.

[0043] In an alternative embodiment where timestamps are recorded in response to a sync ack from a parent server, each node is associated with two timestamps: (1) a modification timestamp reflecting the last modification to the node, and (2) a syncAck timestamp representing the time of the last sync ack by the parent server for an update to the node in the parent server's information model instance. According to this alternative embodiment, because the identification of nodes undergoing modification is based on a node-by-node sync ack, a priority queue is not required, and the modified steps 503a and 506a reflect a normal (non-prioritized) queue. In addition, the modified steps 510a, 510b reflect the acquisition, update, and persistence of the syncAck timestamp, rather than the global variable Last_successful_sync.

[0044] Figure 6 An example of a computer environment in which embodiments of the present disclosure may be implemented is shown. The computing device 610 includes a processor 615 and a memory 616 (e.g., a non-transitory computer-readable medium) on which various computer applications, modules, or executable programs are stored. In embodiments, the computing device 610 is used to implement Figure 1 The OPC UA servers 110, 115 to 118 shown in FIG. As described above, the model generator 611 module is used to implement the functionality of the model generator 111, and the synchronization engine module 612 is used to implement the functionality of the synchronization engine 112.

[0045] A network 660 such as a local area network (LAN), wide area network (WAN), or Internet-based network connects one or more QPC UA Clients 641 and OPC UA Servers 651 to the modules 611, 612 of the computing device 610 for messaging, pushing information, timestamping, and acknowledgment as described above.

[0046] The computer-readable medium instructions for implementing the operations of the present disclosure may be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​(such as Smalltalk, C++, etc.) and traditional procedural programming languages ​​(such as "C" programming language or similar programming languages). The computer-readable program instructions may be executed entirely on a computing device, partially on a computing device, partially on a computing device and partially on a remote computer as a stand-alone software package, or entirely on a computing device or server. In the latter scenario, the remote computer may be connected to the computing device through any type of network (including a local area network (LAN) or a wide area network (WAN)), or a connection to an external computer may be made (e.g., through the Internet using an Internet service provider). In some embodiments, an electronic circuit including, for example, a programmable logic circuit, a field programmable gate array (FPGA), or a programmable logic array (PLA) may execute computer-readable program instructions by personalizing the electronic circuit using the state information of the computer-readable program instructions so as to perform various aspects of the present disclosure.

[0047] Various aspects of the present disclosure are described with reference to flowchart illustrations and / or block diagrams of methods, devices (systems) and computer program products according to embodiments of the present disclosure. It should be understood that each block of the flowchart illustration and / or block diagram and the combination of blocks in the flowchart illustration and / or block diagram can be implemented by computer-readable medium instructions.

[0048] Figure 6 The program modules, applications, computer executable instructions, codes, etc. depicted as being stored in system memory 616 are merely illustrative and non-exhaustive, and the processing described as being supported by any particular module may alternatively be distributed across multiple modules or performed by different modules. In addition, various program modules, scripts, plug-ins, application programming interfaces (APIs), or any other suitable computer executable code hosted locally on computer system 610 and / or hosted on other computing devices accessible via one or more of network(s) 660 may be provided to support the functionality provided by the program modules, applications, or computer executable code and / or additional or alternative functionality. Furthermore, the functionality may be modularized in various ways such that the processing described as being supported by any particular module may alternatively be distributed across multiple modules or performed by different modules. In addition, various program modules, scripts, plug-ins, application programming interfaces (APIs), or any other suitable computer executable code may be provided hosted locally on computer system 610 and / or hosted on other computing devices accessible via one or more of network(s) 660. Figure 6The processing collectively supported by the collection of program modules depicted in the description may be performed by a fewer or greater number of modules, or the functionality described as supported by any particular module may be supported at least in part by another module. In addition, the program modules supporting the functionality described herein may form part of one or more applications that are executable on any number of systems or devices according to any suitable computing model (such as, for example, a client-server model, a peer-to-peer model, etc.). In addition, the processing collectively supported by the collection of program modules depicted in the description may be performed by a fewer or greater number of modules, or the functionality described as supported by any particular module may be supported at least in part by another module. In addition, the program modules supporting the functionality described herein may form part of one or more applications that are executable on any number of systems or devices according to any suitable computing model (such as, for example, a client-server model, a peer-to-peer model, etc.). Figure 6 Any of the functionality supported by any of the program modules depicted in FIG. 1 may be implemented at least partially in hardware and / or firmware on any number of devices.

[0049] It should also be understood that, without departing from the scope of the present disclosure, the computer system 610 may include alternative and / or additional hardware, software or firmware components beyond those described or depicted. More specifically, it should be understood that the software, firmware or hardware components depicted as forming part of the computer system 610 are merely illustrative, and some components may not exist or additional components may be provided in various embodiments. Although various illustrative program modules have been depicted and described as software modules stored in the system memory 616, it should be understood that the functionality described as supported by the program modules can be implemented by any combination of hardware, software and / or firmware. It should also be understood that each of the modules mentioned above can represent a logical partition of the supported functionality in various embodiments. For ease of explanation of functionality, the logical partition is depicted, and it does not represent the structure of the software, hardware and / or firmware used to implement the functionality. Therefore, it should be understood that the functionality described as provided by a specific module can be provided at least in part by one or more other modules in various embodiments. Furthermore, one or more of the depicted modules may not be present in certain embodiments, while in other embodiments, additional modules not depicted may be present and may support at least a portion of the described functionality and / or additional functionality. Furthermore, while certain modules may be depicted and described as submodules of another module, in certain embodiments, such modules may be provided as stand-alone modules or as submodules of other modules.

[0050] Although specific embodiments of the present disclosure have been described, it will be appreciated by those of ordinary skill in the art that many other modifications and alternative embodiments are within the scope of the present disclosure. For example, any functionality and / or processing capability described with respect to a specific device or component can be performed by any other device or component. In addition, although various illustrative implementations and architectures have been described according to embodiments of the present disclosure, it will be appreciated by those of ordinary skill in the art that many other modifications to the illustrative implementations and architectures described in the present invention are also within the scope of the present disclosure. In addition, it should be understood that any operation, element, component, data, etc. described in the present invention as being based on another operation, element, component, data, etc., can be additionally based on one or more other operations, elements, components, data, etc. Therefore, the phrase "based on" or its variants should be interpreted as "based at least in part on".

[0051] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality and operation of the possible implementations of the systems, methods and computer program products according to various embodiments of the present disclosure. In this regard, each frame in the flowchart or block diagram may represent a module, a fragment or a portion of an instruction, which includes one or more executable instructions for implementing a specified logical function. In some alternative implementations, the functions indicated in the frame may not appear in the order indicated in the accompanying drawings. For example, the two frames shown in succession may in fact be substantially executed concurrently, or the frames may sometimes be executed in the opposite order, depending on the functionality involved. It should also be noted that each frame of the block diagram and / or flowchart illustration and the combination of frames in the block diagram and / or flowchart illustration can be implemented by a system based on special-purpose hardware, which performs a specified function or action or implements a combination of special-purpose hardware and computer instructions.

Claims

1. A method for synchronizing information model changes between hierarchical systems of a smart factory, comprising: maintaining a global timestamp variable of the last successful synchronization performed by a parent OPC UA server between a first aggregate information model instance stored in the parent OPC UA server and a second aggregate information model instance stored in a subordinate OPC UA server; for each node in the second aggregate information model, annotating the node with a node-by-node timestamp in response to a modification to the node, wherein the modification comprises one of a node addition, a node update, or a node deletion; pushing all nodes in the second aggregate information model that are subject to modification to a priority queue as a serialized node set format having an annotation extension including synchronization related data; and The first aggregate information model is synchronized with the second aggregate information model by updating the node with the synchronization related data.

2. The method according to claim 1, further comprising: updating the global timestamp variable of the last successful synchronization in response to the synchronization; as well as In response to determining a later timestamp value of the node-by-node timestamp than the value of the global timestamp variable, a node in the second aggregate information model that is subject to modification is identified.

3. The method according to claim 1, further comprising: Shares namespace array information associated with a node ID.

4. The method according to claim 1, wherein: The synchronization related data includes at least one of the following: an indication of whether the node participates in synchronization; any constraints on the parent OPC UA Server, including adjusted permissions; the scope of the synchronization level; or The timestamp of the last modification or synchronization.

5. The method according to claim 1, wherein: The synchronization is triggered by a modification of one or more nodes in an aggregate information model at the lower level OPC UA server.

6. The method according to claim 1, wherein: The synchronization is triggered by an established or re-established connection between the lower-level OPC UA server and the parent OPC UA server.

7. A method for synchronizing information model changes between hierarchical systems of a smart factory, comprising: maintaining a node-by-node timestamp variable syncAck of an acknowledgement time of a synchronization performed by a parent OPC UA Server between a first aggregate information model instance stored in the parent OPC UA Server and a second aggregate information model instance stored in a subordinate OPC UA Server, the synchronization being associated with a node that is subject to modification; annotating the node with a node-by-node timestamp in response to a modification to the node, wherein the modification comprises one of a node addition, a node update, or a node deletion; pushing the node undergoing modification in the second aggregate information model to a queue as a serialized node set format having an annotation extension including synchronization related data; and The first aggregate information model is synchronized with the second aggregate information model by updating the node with the synchronization related data.

8. The method according to claim 7, further comprising: receiving, at the lower level OPC UA server, from the parent OPC UA server, confirmation of synchronization of the first aggregate information model with respect to the modified node; Update the timestamp variable syncAck with the confirmation time; as well as In response to determining a timestamp value of the node-by-node timestamp that is later than a confirmation time synchronized with a value of the node-by-node timestamp variable, a node in the second aggregate information model that is subject to modification is identified.

9. The method according to claim 7, further comprising: Shares namespace array information associated with a node ID.

10. The method according to claim 7, wherein: The synchronization related data includes at least one of the following: an indication of whether the node participates in synchronization; Any constraints on the parent OPC UA Server, including adjusted permissions; the scope of the synchronization level; or The timestamp of the last modification or synchronization.

11. The method according to claim 7, wherein: The synchronization is triggered by a modification of one or more nodes in an aggregate information model at the lower level OPC UA server.

12. The method according to claim 7, wherein: The synchronization is triggered by an established or re-established connection between the lower-level OPC UA server and the parent OPC UA server.

13. A system for synchronizing information model changes between hierarchical systems of a smart factory, comprising: processor; as well as a memory having a module having instructions stored thereon that can be executed by the processor, the module comprising: a model generator configured to instantiate an object of an aggregate information model for each of a plurality of subsystems in the smart factory, the aggregate information model being in accordance with objects defined by an OPC UA standardized model; The sync engine is configured to: maintaining a global timestamp variable of the last successful synchronization performed by a parent OPC UA server between a first aggregate information model instance stored in the parent OPC UA server and a second aggregate information model instance stored in a subordinate OPC UA server; for each node in the second aggregate information model, annotating the node with a node-by-node timestamp in response to a modification to the node, wherein the modification comprises one of a node addition, a node update, or a node deletion; pushing all nodes in the second aggregate information model that are subject to modification to a priority queue as a serialized node set format having an annotation extension including synchronization related data; and The first aggregate information model is synchronized with the second aggregate information model by updating the node with the synchronization related data.

14. The system according to claim 13, wherein: The synchronization engine is further configured to: updating the global timestamp variable of the last successful synchronization in response to the synchronization; as well as In response to determining a later timestamp value of the node-by-node timestamp than the value of the global timestamp variable, a node in the second aggregate information model that is subject to modification is identified.

15. The system of claim 13, wherein: The synchronization engine is further configured to share namespace array information associated with the node ID.

16. The system of claim 13, wherein: The synchronization related data includes at least one of the following: an indication of whether the node participates in synchronization; any constraints on the parent OPC UA Server, including adjusted permissions; the scope of the synchronization level; or The timestamp of the last modification or synchronization.

Images