Component and Method for Synchronizing a Graph-based Infor mation Model

TECHNICAL FIELD

The present disclosure relates to a method for communication, such as communication between clients and servers according to an OPC UA protocol. More specifically, the present embodi ments relate to a method for at least partially synchronizing a graph-based information model. The method and the device can be suitable for different applications, in particular for communication in automation systems.

BACKGROUND

Industrial automation system components of the past have tra ditionally been interconnected by specialized networks using standard industrial protocols for access and data exchange. The development of present and future automation systems has put considerable focus on exchanging semantically enriched information aiming for a realization of flexible manufactur ing scenarios.

In order to overcome a still present low-level communication of signals in industrial automation systems, a protocol enti tled OPC UA has been proposed for enhancing field-level com munication to a semantic level. OPC UA (Open Platform Commu nications Unified Architecture) is an industrial standard protocol of the OPC Foundation for manufacturer-independent communication with the purpose of interchanging industrial data between components or clients and servers of a system, in particular for process automation.

OPC UA offers a concept for providing objects for clients, the so-called Address Space, since each Node of the graph is uniquely identifiable inside a namespace. Clients can browse this Address Space and query objects from the server. In oth er words, the structure of the Address Space in the server is a graph, the Nodes of which are connected to each other by References. A data model of OPC UA features a semantically enriched and graph-based data structure which is dedicated to automation purposes.

A cooperation between OPC UA components frequently includes a necessity to browse an Address Space of a remote component and/or to query attributes of its nodes. More specifically, a component acting as a server - particularly an edge server or an aggregating server - in relation to one or more sub ordinate clients might be frequently interested of changes or amendments encountered in the Address Space of its sub ordinate clients - which may itself act as servers in rela tion to other sub-ordinate clients - for the purpose of que rying attributes of interest. A present scheme of cooperation which is applied for a majority of aggregating servers is to forward each request to a subordinate component. This means that every time an attribute is requested the subordinate component must be queried for the actual value of this at tribute.

It is, however, technically cumbersome to query the graph of remote clients whenever a request arises and, moreover, im poses an enormous burden to the components and the capacities of the network interconnecting the remotely communicating components. It would consequently be desirable to host a copy of the graph of one or more clients within a memory of the aggregating server in order to query attributes of its Nodes in-situ, i.e. within the system of the aggregating server, instead of issuing numerous browse command message over the network followed by numerous query command messages depending on the client's responding messages. The comfort of browsing a local copy of the graph instead of browsing the original graph remotely inevitably leads to a need of synchronizing the copy of the graph with the originating graph in order to ensure actual values of queried attributes on the aggregating server hosting the copy of the graph.

Although OPC UA defines an OPC UA Event captioned as »ModelChangeEvent« by which a client can be notified about changes in the graph-structure, such notification merely co vers changes in the OPC UA References of OPC UA Nodes and therefore cannot be used to synchronize the OPC UA graph with the aggregating server in its entirety. This is mainly due to the fact that changes in attributes - OPC UA Attributes - of OPC UA Nodes are not completely notified by this event.

For the need of synchronizing the copy of the graph with the originating graph in order to ensure actual values of queried attributes on the aggregating server hosting the copy of the graph as motivated above, however, the actual values of such »mostly static« attributes need to be updated as well in or der to guarantee that the values of the attributes included in the copy of the graph are substantially in permanent con sistence with the originating graph.

Accordingly, there is a need in the art to facilitate a meth od for synchronizing amendments in a graph-based data model for automation purposes.

SUMMARY

Embodiments herein generally relate to a method for communi cating changes in a graph-based information model and aiming for at least partially synchronizing a first graph-based in formation model operated on a component with a second graph- based information model operated on an aggregating server.

In one embodiment, a computer-implemented method for synchro nizing a graph-based information model according to an OPC UA protocol is disclosed, the method including the steps of:

- operating a first graph-based information model in a com ponent; - providing, within an OPC UA Name Space of the first graph- based information model, a property type definition for defining a property type related to a static attribute;

- registering at least one property for at least one of said static attribute assigned to at least one node, the at least one property being based on said property type defi nition;

- providing, within the OPC UA Name Space of the first graph-based information model, an event type definition for defining an event type to be triggered on at least one modification of said at least one static attribute;

- registering at least one event for said at least one modi fication of said at least one property, the at least one event being based on said event type definition;

- operating a second graph-based information model in an ag gregating server, the second graph-based information model being a copy of the first graph-based information model at a specific point in time; and;

- on occurrence of said event, generating, by the component, an event message and transmitting the event message to the aggregating server maintaining a subscription for said event.

According to an embodiment a method is provided with the ad ditional steps of:

- retrieving, by the aggregating server, changes of said at least one static attribute; and;

- synchronizing the second graph-based information model by updating said changes.

According to an embodiment a method is provided wherein said providing a property type definition for defining a property type related to a static attribute includes providing a de fault property type definition as a subtype of an OPC UA ob ject type entitled NamespaceMetadataType. According to an embodiment a method is provided wherein at least one value attribute of the default property type defi nition contains a bitmask for determining a subset of static attributes for the given Namespace.

According to an embodiment a method is provided wherein said providing a property type definition for defining a property type related to a static attribute includes providing a node specific property type definition of an OPC UA object type entitled ServerType.

According to an embodiment a method is provided wherein a property registered based on said node-specific property type definition overrides at least one default value related to at least one static attribute determined a property registered based on said default property type definition.

According to an embodiment a method is provided with the ad ditional steps of:

- providing a first event type definition as a subtype of an OPC UA object type entitled BaseEventType, the first event type definition providing an indication in that at least one change in at least one static attribute has occurred; and;

- providing a second event type definition as subtype of the first type definition, the second event type providing in formation about the node for which at least one change in said at least one static attribute has occurred.

According to an embodiment a method is provided with the ad ditional steps of:

- providing a third event type definition as subtype of an OPC UA object type entitled BaseEventType, the third event type definition providing an indication that at least one change in at least one value of at least one static at tribute have occurred; and;

- providing a fourth event type definition as subtype of the first type definition, the second event type providing in formation about the node for which at least one change in said at least value of said at least one static attribute has occurred.

According to an embodiment a component comprising a processor and a data storage device having stored thereon a computer executable program code is provided. The data storage device may be implemented within or external to the component.

According to a further embodiment a non-transitory computer- readable storage medium having stored thereon computer exe cutable program code is provided.

DESCRIPTION OF THE DRAWING

The objects as well as further advantages of the present em bodiments will become more apparent and readily appreciated from the following description of the preferred embodiments, taken in conjunction with the accompanying drawing in which:

FIG. 1 shows a graphical representation of an additional property type definition under an OPC UA object type NamespaceMetadataType, the additional property type being related to a static attribute within an OPC UA Name Space;

FIG. 2 shows a graphical representation of an additional property type definition under an OPC UA object type ServerType, the additional property type being related to a static attribute within an OPC UA Name Space; and; FIG. 3 shows a graphical representation of an event type definition related to a static attribute within an OPC UA Name Space.

Detailed Description

OPC UA (Open Platform Communications Unified Architecture) is an industrial protocol of the OPC Foundation for manufactur er-independent communication with the purpose of interchang ing industrial data, in particular in process automation.

According to the OPC UA protocol information is modelled by a graph-based information model resulting in a flexible envi ronment for representing different kinds of domain infor mation, ranging from basic measurement information all the way up to higher level information representing complete pro duction units.

At a lower level the graph is divided into namespaces which create a division between the standardized information repre sentation and the vendor specific supplementary information. In OPC UA the graph is usually referred as an address space since each of the graph nodes are uniquely identifiable in side a namespace.

An application is able to query the namespaces and the graph contents, allowing the application to traverse through the graph and identifying the queried data. Furthermore, the OPC UA provisions segment the graph into groups of nodes having a certain common structure, which is referred to as an OPC UA type definition concept. Thereby, certain groups of nodes in herit a common well-defined structure. Further to that, types define their instances. Therefore, the types are referred as type definitions in the specification. The standard also cre ates some base definitions for example measurement represen tations containing actual measurement value, ranges and units. Companion specifications make extensions based on the type system by creating models for different kinds of equip ment and other resources. Of course, the vendors can further extend these types by creating sub types of the standard types. Therefore, applications utilizing these types can be sure on what to expect from the node hierarchy when travers ing the graph.

OPC UA provides various interfaces for obtaining information about the contents of the graph. On a basic level read ser vice for reading data related to an individual node are pro vided.

In OPC UA each node has various attributes related to it. These are for example name, description and value of a node. The structure of the graph is usually queried using Browse and Query services:

- The Browse service provides information about the struc ture of the graph related to an individual node, e.g. aim ing for a discovery of nodes connected to an individual node.

- The Query service is used to read contents of the graph in its entirety. This Query service allows both, simple que ries - e.g. querying all nodes whose names start with a specific string - and complex queries enabling for filter ing nodes based on their structure and hierarchy.

In the following, compound names with one or more medial cap itals - e.g. a compound name »TypeDefinitionNodes« - are used to refer to authoritative names used in the specification »OPC Unified Architecture« of the OPC Foundation. These au thoritative names are assumed to be known and for a person skilled in the art. Hereinafter, these authoritative names are, therefore, introduced without explanation.

A cooperation between a number of OPC UA components hierar chically organized in most cases. In complex organizations one or more components acting as servers are provided, where in an edge server or aggregating server is supervising or controlling one or more sub-ordinate components which may it self act as servers in relation to other sub-ordinate cli ents.

Type definitions in the OPC UA protocol include server relat ed ObjectTypes carrying, for example, information about diag nostics, configuration, or capabilities. An existence of an object of the type ServerType is mandatory, which contains general information about Namespaces or the status of the server, as well as diagnostics and capabilities.

At present, most aggregating servers, when encountering a re quest of querying attributes of their subordinated compo nents, are forwarding each request to the subordinate compo nent. This means that every time an attribute is requested, the subordinate component must be queried for the actual val ue of this attribute.

Mostly static or static attributes (e.g., NodeClass- Attribute) are hereinafter understood as attributes, whose values do not change so frequently than other attributes (e.g. Value-Attribute) - e.g. a process temperature - holding a value which is frequently subject for changes. The static character, however, may depend on the context. While in some industrial applications an attribute changing every second may be regarded as static, other application contexts may consider a variable as static, which changes only once a month. In the scope of this disclosure, the term static is therefore not limited by a temporal frequency of changes im posed to the attribute. The term static is rather to be un derstood as a tag assigned to an attribute.

Querying the graph of subordinate components by the aggregat ing server whenever a request arises is time consuming and imposes an enormous message traffic for the components and the network interconnecting communicating components. According to an embodiment, a copy of the graph of one or more components is hosted within a memory of the aggregating server. Specifically, a complete graph-based or partial in formation model of the component's graph-based information model is copied and transferred to a memory of the aggregat ing at a specific point in time. The provision of a local copy enables the aggregating server to query attributes with in its working space, thereby preventing numerous browse and query messages over a network.

Administering a local copy of the graph instead of browsing the original graph, however, means that elements - in partic ular attributes and their values - within the copy of the graph are not consistent with the originating graph for all times. Accordingly, there is a need for synchronizing the copy of the graph with the originating graph in order to en sure actual values of queried attributes on the aggregating server hosting the copy of the graph.

As to the graph structure - structuring the OPC UA References itself - an event referred to as ModelChangeEvent can be used to synchronize the aggregating server graph with the underly ing device graphs. However, as motivated above, the actual values of mostly static OPC UA Attributes cannot be synchro nized efficiently.

In fact, some of these static attributes OPC UA Attributes, particularly an attribute entitled NodeClass do not change over time during normal operations. However, in order to keep the copy of the graph at the aggregating server consistent with the originating graph in the component it is necessary, even for such static attributes, to guarantee conformance with the static attributes.

Although the OPC UA protocol (»OPC Unified Architecture« OPC UA, part 3, chapter »ModelChangeEvents«) defines an OPC UA Event entitled »ModelChangeEvent« by which a client can be notified about changes in the graph-structure, such notifica tion merely covers changes in the OPC UA References of OPC UA Nodes and therefore cannot be used to synchronize the OPC UA graph with the aggregating server in its entirety.

The ModelChangeEvent may be triggered by components newly added to an industrial network and a relating event message may be assessed by interested subscribers of this event in stead of periodically browsing the whole graph for distinc tions.

However, as noted above, a usage of ModelChangeEvent is not suitable for the context of synchronizing the OPC UA graph on the aggregating server which is mainly due to the fact that changes in OPC UA Attributes are not completely notified by this event. The remaining options offered by the OPC UA pro tocol are also sub-optimal:

- One possible option is to adapt the current practice of issuing repeated requests by the aggregating server to the subordinate OPC UA component in order to periodically syn chronize the local copy of the graph cached by and within the aggregating server. Requesting a static attribute at the subordinate component means to query for the actual value of this static attribute. This is to be preceded by parsing a browse path through the whole graph, wherein each BrowseName-Attribute of each Node has to be fetched. However, this frequent series of browse and query opera tions generate a huge unnecessary load on the underlying OPC UA component, because this a Type Search on subordi nate instances of these types could normally be done with out any additional request to the underlying component as the actually interesting static attributes typically do not change. In contrast, if dynamic attributes are to be accessed on the aggregation layer, a subscription typical ly already exists, or the aggregating server would fetch dynamic attributes frequently or on demand using a stand ard Read Service of OPC UA. - One possible option may include a monitoring of the static attributes by a publish-subscribe-method including a sub scription. However, each additional attribute for monitor ing needs also additional resources on the target OPC UA server and therefore it might not even be possible on each device to subscribe to all Nodes and all Attributes of these Nodes.

In order to alleviate these drawbacks of the present state of the art, the proposed embodiments introduce a novel concept of differentiating attributes of interest subject to a syn chronization of a graph. Hereinafter, these attributes of in terest are referred to as static attributes, although the static character - see the introductory remarks above - may depend on the context. The term »static« is rather to be un derstood as a tag assigned to an attribute.

According to the proposed embodiments, two concepts are in troduced:

- a concept of expressing static attributes within OPC UA information models; and;

- a concept of communicating changes in the static attrib utes to the aggregating server.

The concept of expressing static attributes includes the steps of:

- providing, within an OPC UA Name Space of the OPC UA in formation model, a property type definition for defining a property type related to a static attribute;

- registering at least one property for at least one of said static attribute assigned to at least one node, the at least one property being based on said property type defi nition;

Referring now to FIG. 1 in which a provision of a property type definition related to a static attribute within an OPC UA Name Space is shown. FIG. 1 shows an object type - or ObjectType according to the compound notation of the OPC UA reference - entitled NamespaceMetadataType 101 which is defined in the present OPC UA reference »OPC Unified Architecture^ version 1.04, part 5, chapter 6.3.13. This ObjectType NamespaceMetadataType 101 defines the metadata for a namespace provided by a server. Instances of this Object or ObjectType allow servers to pro vide more information like version information in addition to the namespace URI.

The ObjectType NamespaceMetadataType 101 provides further PropertyTypes 102,103,104 according to the present OPC UA reference, including a mandatory PropertyType entitled NamespaceURI 102 and an optional PropertyType entitled De- faultAccessRestrictions 104. A number of further Property- Types are symbolized by a placeholder 103 in the drawing. Be side these PropertyTypes 102,103,104 the OPC UA reference generally allows extending standard ObjectTypes with addi tional components.

The proposed embodiments provide for an additional Property- Type being a further optional property of the ObjectType NamespaceMetadataType 101. This additional PropertyType is hereinafter referred to as DefaultStaticAttributes 105. The designation chosen for this additional PropertyType De- faultStaticAttributes 105 is, however, arbitrarily replacea ble.

A property DefaultStaticAttributes can be registered for one or more nodes, the property DefaultStaticAttributes being based on this property type definition DefaultStaticAttrib utes 105 as depicted in FIG 1.

According to an embodiment, a - not shown - value attribute of this PropertyType DefaultStaticAttributes 105 contains a bitmask which determines what kind of Attributes are static for the given Namespace. In other words, the bitmask deter- mines a subset of static attributes within a set of Attrib utes for the given Namespace.

According to an embodiment this bitmask is preferably defined similar to the AttributeWriteMask of OPC UA Part 3. Within the bitmask, a bit having a Boolean value of 0 means that the Attribute assigned to the bitmask position of said bit is not tagged as static. If a bit is set to a Boolean value of 1, the Attribute assigned to the bitmask position of said bit is tagged as static. If a Node does not support a static attrib ute, the corresponding bit has to be set to 0. This configu ration by the PropertyType DefaultStaticAttributes 105 auto matically applies to all Nodes of the given Namespace.

According to a further embodiment illustrated by FIG. 2, de fault values determined by the PropertyType DefaultStaticAt tributes 105 - which are applied to all Nodes of the given Namespace - can be overridden individually for a specific Node by an additional PropertyType added to a specific Node.

FIG. 2 shows an object type - or ObjectType according to the compound notation of the OPC UA reference - entitled Serv- erType 201 which is defined in the present OPC UA reference »OPC Unified Architecture« OPC UA, part 5, chapter 6.3.1. The ServerType defines capabilities supported by an OPC UA Serv er. The ObjectType ServerType 201 provides further Property- Types including, for example, a mandatory PropertyType enti tled ServerArray 202 defining an array of Server URIs.

The proposed embodiments provide for an additional Property- Type being a further optional property of the ObjectType ServerType 201. This additional PropertyType is hereinafter referred to as StaticAttributes 203. The designation chosen for this additional PropertyType StaticAttributes 203 is, however, arbitrarily replaceable.

An additional property StaticAttributes can be registered for one or more nodes, the property StaticAttributes being based on the property type definition StaticAttributes 203. The property StaticAttributes, when added to a specific Node, overrides the default values related to static attributes de termined by the DefaultStaticAttributes Property. The proper ty type definition StaticAttributes 203 is, therefore, also referred to as node-specific property type definition. Or, in other words: A property registered based on the node-specific property type definition StaticAttributes 203 overrides at least one default value related to at least one static at tribute determined by a property registered based on the de fault property type definition DefaultStaticAttributes 105.

In summary, while the configuration of the Property De- faultStaticAttributes according to the PropertyType De- faultStaticAttributes 105 automatically apply to all Nodes of the given Namespace, the configuration of the property Stati cAttributes according to the PropertyType StaticAttributes 203 can be added to a single Node, thereby overriding the de fault values related to static attributes determined by the DefaultStaticAttributes Property according to the Property- Type DefaultStaticAttributes 105.

In the following, the concept of communicating changes in the static attributes to the aggregating server according to em bodiments is described.

Every time a static attribute is changed, an event will be generated on the OPC UA component, the event informing the subscribers of these changes. Particularly, the aggregating server - acting as a client towards the OPC UA component triggering the Event - is a subscriber of such events.

The concept of communicating changes in the static attributes to the aggregating server includes the steps of:

- providing, within the OPC UA Name Space of the first graph-based information model, an event type definition for defining an event type to be triggered on at least one modification of said at least one static attribute; - registering at least one event for said at least one modi fication of said at least one property, the at least one event being based on said event type definition.

Referring now to FIG. 3 in which a provision of an event type definition related to a static attribute within an OPC UA Name Space is shown.

FIG. 3 shows an event type entitled BaseEventType 301 which is defined in the present OPC UA reference »OPC Unified Ar chitecture^ version 1.04, part 5, chapter 6.4.2. The BaseEventType 301 defines all general characteristics of an Event.

The proposed embodiments provide for an additional EventType

- or event type definition - being a further subtype of the BaseEventType 301. This additional EventType is hereinafter referred to as BaseStaticAttributesChangeEventType 302 as de picted in FIG 3. The designation »BaseStaticAttributesChang- eEventType« chosen for this additional EventType 302 is, how ever, arbitrarily replaceable.

Instances of the BaseStaticAttributesChangeEventType 302 are events which are referred to as BaseStaticAttributesChang- eEvents or, in other words, BaseStaticAttributesChangeEvents are Events of the BaseStaticAttributesChangeEventType 302. BaseStaticAttributesChangeEvents do not contain information about details of changes but only indicate that changes have occurred. Therefore, a client - note that the aggregating server is acting as a client in relation to the component is suing this event - shall assume that any or all static At tributes of the Nodes may have changed.

The proposed embodiments provide for an additional EventType being a subtype of the BaseStaticAttributesChang- eEventType 302. This additional EventType is hereinafter re ferred to as GeneralStaticAttributesChangeEventType 303 as depicted in FIG 3. The designation chosen for this additional EventType 303 is likewise arbitrarily replaceable.

Instances of the GeneralStaticAttributesChangeEventType 303 are events which are referred to as GeneralStaticAttrib- utesChangeEvents or, in other words, GeneralStaticAttrib- utesChangeEvents are Events of the GeneralStaticAttrib- utesChangeEventType 303. The GeneralStaticAttributesChang- eEventType 303 contains information about the Node for which a static Attribute has changed. In the most generic version of an instantiated GeneralStaticAttributesChangeEvent, only the Nodeld shall be transmitted. In a more detailed Version of this Event for each Nodeld also a bitmask shall be trans mitted, which marks the static Attributes which have changed. A further embodiment provides a StaticAttributesChangeEvent containing an array of changes in order to allow event com pression.

The proposed embodiments provide for an additional EventType being a further subtype of the BaseEventType 301. This addi tional EventType is hereinafter referred to as BaseStaticAt- tributesConfigChangeEventType 304 as depicted in FIG 3. The designation »BaseStaticAttributesConfigChangeEventType« cho sen for this additional EventType 304 is, however, arbitrari ly replaceable.

Instances of the BaseStaticAttributesConfigChangeEventType 304 are events which are referred to as BaseStaticAttrib utesConfigChangeEvents or, in other words, BaseStaticAttrib utesConfigChangeEvents are Events of the BaseStaticAttrib utesConfigChangeEventType 304. BaseStaticAttributesCon- figChangeEvents do not contain information about details of changes but only indicate that changes have occurred. There fore, a client - note that the aggregating server is acting as a client in relation to the component issuing this event - shall assume that any or all Value-Attributes (bitmask) of the properties StaticAttribute or DefaultStaticAttributes Properties may have changed. The proposed embodiments provide for an additional EventType being a subtype of the BaseStaticAttributesConfigChang- eEventType 304. This additional EventType is hereinafter re ferred to as GeneralStaticAttributesConfigChangeEventType 305 as depicted in FIG 3. The designation chosen for this addi tional EventType 305 is likewise arbitrarily replaceable.

Instances of the GeneralStaticAttributesConfigChangeEventType 305 are events which are referred to as GeneralStaticAttrib utesConfigChangeEvents or, in other words, GeneralStaticAt tributesConfigChangeEvents are Events of the GeneralStaticAt tributesConfigChangeEventType 305. GeneralStaticAttrib utesConfigChangeEvents contain information about the Node for which the Value-Attributes (bitmask) of StaticAttribute or DefaultStaticAttributes Properties have changed. In the most generic version of this Event only the Nodeld of the Property shall be transmitted. In a more detailed version of this Event for each Nodeld also the new value of the bitmask (Val ue-Attribute of the Property) shall be transmitted. A further embodiment provides a StaticAttributesConfigChangeEvent con taining an array of changes in order to allow event compres sion.

In the following, characteristics and differences of all ad ditional EventTypes 302,303,304,305 are briefly listed:

BaseStaticAttributesChangeEventType 302 (hereinafter also re ferred to as first event type definition):

- Subtype of BaseEventType 301;

- Base type for events entitled StaticAttributesChang- eEvents;

- Event for indicating in that changes in static Attribute have occurred;

- Does not contain information about the changes;

- A client subscribing to an event of this EventType 302, shall, on occurrence of the event, assume that any or all static Attributes of the Nodes may have changed. GeneralStaticAttributesChangeEventType 303 (hereinafter also referred to as second event type definition):

- Subtype of BaseStaticAttributesChangeEventType 302;

- Contains information about the Node for which a static At tribute has changed;

In the most generic version of this event, only the Nodeld shall be transmitted

- In a verbose version of this Event for each Nodeld also a bitmask shall be transmitted, which marks the static At tributes which have changed;

- According to a further embodiment, a StaticAttrib- utesChangeEvent contains an array of changes in order to allow event compression.

BaseStaticAttributesConfigChangeEventType 304 (hereinafter also referred to as third event type definition):

- subtype of BaseEventType 301

- base type for events entitled StaticAttributesConfigChang- eEvents for indicating that changes in at least one value of stat ic attributes have occurred;

- does not contain information about the changes;

- a client subscribing to this event shall, on occurrence of the event, assume that any or all value attributes (bit- mask) of »StaticAttribute« or »DefaultStaticAttributes« Properties may have changed.

GeneralStaticAttributesConfigChangeEventType 305 (hereinafter also referred to as fourth event type definition):

- subtype of BaseStaticAttributesConfigChangeEventType 304;

- contains information about Nodes for which at least one Value-Attribute (bitmask) of »StaticAttribute« or »De- faultStaticAttributes« Properties has changed.

In the most generic version of this Event, only the Nodeld of the Property shall be transmitted - In a verbose version of this Event for each Nodeld also the new value of the bitmask (Value-Attribute of the Prop erty) shall be transmitted;

- According to a further embodiment, a StaticAttributesCon- figChangeEvents contains an array of changes in order to allow event compression.

These event type definitions allow for registering one or more events being based on said event type definitions. The events are triggered in the event of a modification - i.e. an addition, deletion or change in attributes - of properties and/or value attributes related to a static attribute.

On occurrence of an event, the component generates an event message and transmits an event message to the aggregating server maintaining a subscription for said event The aggre gating server is hereby a functional client in view of the component, which is functionally acting as server for this transaction. The event message as transmitted does not, in itself, include changed values of the static attributes sub ject to modification but rather reports the attributes or the Nodes to which static attributes have been assigned.

It is then in the discretion of the aggregating server to de cide of its own whether or not and when changes of said stat ic attributes are actively retrieved on the (first) graph- based information on the side of the component in order to synchronize its own copy of the (second) graph-based infor mation model by updating said changes.

Such a separation between notifying changes and actively re trieving these changes follows a basic principle of OPC UA, thereby advantageously maintaining standard procedures for retrieving the changes according to an embodiment in order to partially or completely synchronize the second graph-based information model. Still further, this separation advanta geously supports a design pattern referred to as »lazy load- ing« which is commonly used for deferring an update of a var- iable until the point at which the variable needs to be ac cessed.

Embodiments described herein generally allow for caching »static« attributes by an aggregating layer or more generally by components in between a boundary between an edge layer of an industrial network operating according to an OPC UA proto col and cloud layer. Components operating according to the described methods may significantly reduce the synchroniza tion workload on underlying devices as well as the aggregat ing server itself.

Both, network traffic and latency are reduced by accessing static attributes according to the embodiments instead of registering active subscriptions on the aggregating server. This is especially important for applications using query op erations, which typically are using static Attributes like Browse Name to reduce the result set prior to accessing spe cific values of interest.

The embodiments introduce conceptual extensions of the OPC UA information model and introduction of additional events to dynamically define static Attributes for each Namespace in cluding a solution how a client can be informed about changes in the static Attributes.

It is to be understood that the elements and features recited in the appended claims may be combined in different ways to produce new claims that likewise fall within the scope of the present invention. Thus, whereas the dependent claims append ed below depend from only a single independent or dependent claim, it is to be understood that these dependent claims can, alternatively, be made to depend in the alternative from any preceding or following claim, whether independent or de pendent, and that such new combinations are to be understood as forming a part of the present specification. While the present invention has been described above by ref erence to various embodiments, it should be understood that many changes and modifications can be made to the described embodiments. It is therefore intended that the foregoing de- scription be regarded as illustrative rather than limiting, and that it be understood that all equivalents and/or combi nations of embodiments are intended to be included in this description.