Table 37 defines the namespace metadata for this specification. The Object is used to provide version information for the namespace and an indication about static Nodes. Static Nodes are identical for all Attributes in all Servers, including the Value Attribute. See Part5 for more details.
The information is provided as Object of type NamespaceMetadataType. This Object is a component of the Namespaces Object that is part of the Server Object. The NamespaceMetadataType ObjectType and its Properties are defined in OPC 10000-5.
The version information is also provided as part of the ModelTableEntry in the UANodeSet XML file. The UANodeSet XML schema is defined in OPC 10000-6.
Table 37 – NamespaceMetadata Object for this Specification
|
Attribute |
Value |
|||
|
BrowseName |
||||
|
References |
BrowseName |
DataType |
Value |
|
|
HasProperty |
NamespaceUri |
String |
||
|
HasProperty |
NamespaceVersion |
String |
1.02 |
|
|
HasProperty |
NamespacePublicationDate |
DateTime |
2020-11-25 |
|
|
HasProperty |
IsNamespaceSubset |
Boolean |
Vendor-specific |
|
|
HasProperty |
StaticNodeIdTypes |
IdType[] |
{Numeric} |
|
|
HasProperty |
StaticNumericNodeIdRange |
NumericRange[] |
|
|
|
HasProperty |
StaticStringNodeIdPattern |
String |
|
|
This chapter defines the corresponding Profiles and Conformance Units for the OPC UA Information Model for IEC61131-3. Profiles are named groupings of Conformance Units. Facets are Profiles that will be combined with other Profiles to define the complete functionality of an OPC UA Server or Client.
The following tables specify the Facets available for Servers that implement the IEC 61131-3 Information Model companion specification.
Table 38 defines Conformance Units included in the minimum needed facet. It requires the support for profile BaseDevice Server Facet defined in OPC 10000-100. It is used together with the Embedded 2017 UA Server profile or the Standard 2017 UA Server profile defined in OPC 10000-7.
A server supporting all data types including complex data types must support the ComplexType Server Facet defined in OPC 10000-7.
Table 38 – Controller Operation Server Facet Definition
|
Conformance Unit |
Description |
Optional/ Mandatory |
|
Ctrl DeviceSet |
Support the full component hirarchy with Ctrl Configuration, Ctrl Resource, Ctrl Program and Ctrl FunctionBlock below the DeviceSet Object defined in OPC 10000-100. |
M |
|
Ctrl Configuration |
Support vendor defined Ctrl Configuration object types and object instances. |
M |
|
Ctrl Resource |
Support vendor defined Ctrl Resource object types and object instances |
M |
|
Ctrl Program |
Support user defined Ctrl Program object types and object instances. |
M |
|
Ctrl FunctionBlock |
Support user defined Ctrl FunctionBlock object types and object instances. |
M |
|
Ctrl Task |
Support of Ctrl Task objects. |
O |
|
Ctrl References |
Support of reference types specified in the IEC 61131-3 Information Model companion standard. |
O |
|
Profile |
||
|
BaseDevice_Server_Facet (defined in OPC 10000-100) |
M |
|
Table 39 defines a facet for the support of the engineering information defined in the IEC 61131-3 Information Model. The Controller Engineering Server Facet requires the Controller Operation Server Facet.
Table 39 – Controller Engineering Server Facet Definition
|
Conformance Unit |
Description |
Optional/ Mandatory |
|
Ctrl Engineering Data |
Support to provide all engineering data defined in this specification like properties describing data types. |
M |
|
Ctrl Engineering Change |
Support of engineering data changes through OPC UA |
O |
|
Ctrl Type Creation |
Support of type node creation through NodeManagement Services to create Ctrl Program Organization Unit declarations. |
O |
|
Profile |
||
|
Controller Operation Server Facet |
M |
|
The following tables specify the Facets available for Clients that implement the IEC61131-3 Information Model companion specification.
Table 40 defines a facet available for Clients that implement the IEC 61131-3 Information Model standard. Servers implementing the Controller Engineering Server Facet may use this facet to restrict the engineering features to clients supporting this Client facet.
Table 40 – Controller Engineering Client Facet Definition
|
Conformance Unit |
Description |
Optional/ Mandatory |
|
Ctrl Client Information Model |
Consume objects that conform to the types specified in the IEC 61131-3 Information Model companion standard. |
M |
|
Ctrl Client Engineering Data |
Consume engineering data defined in the IEC 61131-3 Information Model companion standard like properties describing data types. |
M |
|
Ctrl Client Engineering Change |
Use engineering data changes through OPC UA |
O |
|
Ctrl Type Creation |
Use type node creation through NodeManagement Services to create Ctrl Program Organization Unit declarations. |
O |
|
Profile |
||
|
|
|
|
|
|
|
|
Namespaces are used by OPC UA to create unique identifiers across different naming authorities. The Attributes NodeId and BrowseName are identifiers. A Node in the UA AddressSpace is unambiguously identified using a NodeId. Unlike NodeIds, the BrowseName cannot be used to unambiguously identify a Node. Different Nodes may have the same BrowseName. They are used to build a browse path between two Nodes or to define a standard Property.
Servers may often choose to use the same namespace for the NodeId and the BrowseName. However, if they want to provide a standard Property, its BrowseName shall have the namespace of the standards body although the namespace of the NodeId reflects something else, for example the EngineeringUnits Property. Another example shown in Figure 30 is the ParameterSet and the GlobalVars object components of a Ctrl Resource instance. The ParameterSet node BrowseName shall use the OPC DI namespace and the GlobalVars node BrowseName shall use the namespace defined by this specification. All NodeIds of Nodes not defined in this specification shall not use the standard namespaces and are typically using the same namespace like the Ctrl Resource object instance, for example local server.
Table 41 provides a list of mandatory and optional namespaces used in a Controller Server.
Table 41 – Namespaces used in a Controller Server
|
NamespaceURI |
Description |
Use |
|
Namespace for NodeIds and BrowseNames defined in the OPC UA specification. This namespace shall have namespace index 0. |
Mandatory |
|
|
Local Server URI |
Namespace for nodes defined in the local server. This may include types and instances used in a Ctrl Resource represented by the server. This namespace shall have namespace index 1. |
Mandatory |
|
Namespace for NodeIds and BrowseNames defined in OPC 10000-100. The namespace index is server specific. |
Mandatory |
|
|
Namespace for NodeIds and BrowseNames defined in this specification. The namespace index is server specific. |
Mandatory |
|
|
A server may provide IEC or PLCopen defined Ctrl Function Block libraries. |
Optional |
|
|
User defined types and instances in a Ctrl Resource |
A server that provides access to different Ctrl Resources may provide a separate namespace for each Ctrl Resources if it is required to create unique identifiers across Ctrl Resources. |
Optional |
|
Vendor specific types |
A server may provide vendor specific types like types derived from Ctrl Configuration or Ctrl Resource in a vendor specific namespace. |
Optional |
|
Global user defined library |
A server may provide global user defined Ctrl Function Block libraries in a user specific namespace. |
Optional |
Figure 30 shows an example for the use of namespaces in NodeIds and BrowseNames.
Figure 30 – Example for the use of namespaces in NodeIds and BrowseNames
Table 42 provides a list of namespaces and their index used for BrowseNames in this specification. The default namespace of this specification is not listed since all BrowseNames without prefix use this default namespace.
Table 42 – Namespaces used in this specification
|
NamespaceURI |
Namespace Index |
Example |
|
0 |
0:EngineeringUnits |
|
|
2 |
2:DeviceRevision |