Type Definition

Type definition nodes can be complex. A complex type definition node also defines references to other nodes as part of the type definition. The modelling rules specify how those nodes are handled when creating an instance of the type definition.

A type definition node references instances instead of other type definition nodes to allow unique names for several instances of the same type, to define default values and to add references for those instances that are specific to this complex type definition node and not to the type definition node of the instance. For example, in Figure 2 the ObjectType node AI_BLK_TYPE, representing a function block, has a HasComponent reference to a VariableSP of the VariableTypeSetPoint. AI_BLK_TYPE could have an additional setpoint Variable of the same type using a different name. It could add a Property to the Variable that was not defined by its type definition node SetPoint. And it could define a default value for SP, that is, each instance of AI_BLK_TYPE would have a VariableSP initially set to this value.

Figure 2: Example of a Complex TypeDefinition

This approach is commonly used in object-oriented programming languages in which the variables of a class are defined as instances of other classes. When the class is instantiated, each variable is also instantiated, but with the default values (constructor values) defined for the containing class. That is, typically, the constructor for the component class runs first, followed by the constructor for the containing class. The constructor for the containing class may override component values set by the component class.

To distinguish instances used for the type definitions from instances that represent real data, those instances are called instance declarations. However, this term is used to simplify this specification, if an instance is an instance declaration or not is only visible in the Address Space by following its references. Some instances may be shared and therefore referenced by type definition nodes, instance declarations and instances. This is similar to class variables in object-oriented programming languages.

This specification allows subtyping of type definitions. Subtyping of object types and variable types allows:

• clients that only know the supertype are able to handle an instance of the subtype as if it is an instance of the supertype;

• instances of the supertype can be replaced by instances of the subtype;

• specialised types that inherit common characteristics of the base type.

In other words, subtypes reflect the structure defined by their supertype but may add additional characteristics. For example, a vendor may wish to extend a general TemperatureSensorVariableType by adding a property providing the next maintenance interval. The vendor would do this by creating a new VariableType which is a target node for a HasSubtype reference from the original VariableType and adding the new property to it.

The instantiation of complex type definition nodes depends on the modelling rules. However, the intention is that instances of a type definition will reflect the structure defined by the type definition node. Figure 3 shows an instance of the type definition node AI_BLK_TYPE, where the modelling rule Mandatory was applied for its containing Variable. Thus, an instance of AI_BLK_TYPE, called AI_BLK_1, has a HasTypeDefinition reference to AI_BLK_TYPE. It also contains a VariableSP having the same valu of the BrowseName as the VariableSP used by the type definition node and thereby reflects the structure defined by the type definition node.

Figure 3: Object and its Components defined by an ObjectType

A client knowing the ObjectTypeAI_BLK_TYPE can use this knowledge to directly browse to the containing nodes for each instance of this type. This allows programming against the type definition node. For example, a graphical element may be programmed in the client that handles all instances of AI_BLK_TYPE in the same way by showing the value of SP.

To allow this simple addressing, a type definition node or an instance declaration shall never reference two nodes having the same BrowseName using hierarchical references in forward direction. Instances based on instance declarations shall always keep the same BrowseName as the instance declaration they are derived from. A special service described in section Services called TranslateBrowsePathsToNodeIds may be used to identify the instances based on the instance declarations. Using the simple Browse service might not be sufficient since the uniqueness of the BrowseName is only required for type definition nodes and instance declarations, not for other instances. Thus, AI_BLK_1 may have another Variable with the BrowseNameSP, although this one would not be derived from an instance declaration of the type definition node.

Note
Instances derived from an instance declaration shall be of the same type definition node or a subtype of this type definition node

A type definition node and its InstanceDeclarations shall always reside in the same server. However, instances may point with their HasTypeDefinition Reference to a type definition node in a different server.

Other Resources