The definition of the objects in the previous paragraphs enables the generic access to POWERLINK Objectsfrom the POWERLINK Communication Profiles EPSG DS 301 and EPSG DS 302. Without an extension of the Information Modelthe access to vendor- or profile-specific POWERLINK Objectswould be only possible through the SDO Services defined in 6.2.A client would not be able to create MonitoredItemsand Subscriptionsto vendor-specific objects since they would not have an individual NodeId.

One way to generate individual NodeIdsis to convert the vendor specific device description from POWERLINK into an OPC UA Information Modeland to deploy the models of all involved POWERLINK Devicesto the OPC UA Server. This might be feasible for Serversthat run on the POWERLINK Deviceitself and represent only their own device.

This paragraph defines another, more generic way to provide individual NodeIdsfor random objects in a POWERLINK Object Dictionary.

For this generic access the Namespacehttp://opcfoundation.org/UA/POWERLINK/UA/DirectAccess/’ is used.

When using NodeIdsof the type OPAQUE_3 the NodeIdcontains information about address and DataTypein binary form. Compared to String-NodeIdsthis format is smaller and generates less overhead when registering Nodesfor Subscriptions.

To access POWERLINK Objectson a Server, which represents only one POWERLINK Object Dictionarythe size of the NodeIdis 4 byte and the format is defined in shown in Table 48.

Table 48– NodeIds for single instances

Byte

Description

0

LSB of the objects POWERLINK Index

1

HSB of the objects POWERLINK Index

2

POWERLINK Sub-Index

3

DataTypeId

Byte 0, 1 and 2 are the values of the POWERLINK addressing scheme Index / Sub-Index. If the POWERLINK Objectrequested by Index/Sub-Index is not existing the server shall signal this case with the StatusCode Bad_NodeIdUnknown.

With byte 3 the client specifies the expected DataTypeof the response data by using the built-in types defined in OPC 10000-6. Allowed values are 1 to 12, as well as 15. If byte 3 is set to 12 or 15 (Stringor ByteString) the server shall respond with the same length like the POWERLINK Object. Otherwise, if the bit-length of the referenced POWERLINK Objectis different to the bit-length of the requested DataType,the Servershall signal this case with the StatusCode Bad_NodeIdInvalid.

To access POWERLINK Objectson a Server, which represents more than one POWERLINK Object Dictionarythe size of the NodeIdis 6 byte and the format is defined in Table 49.

Table 49– NodeIds for multiple instances

Byte

Description

0

LSB of the objects POWERLINK Index

1

HSB of the objects POWERLINK Index

2

POWERLINK Sub-Index

3

DataTypeId

4

POWERLINK DeviceAddress

5

POWERLINK Network

Byte 0 to 3 have the same function like in Table 48.

Byte 4 defines the Address of the device in the POWERLINK network.

Byte 5 defines the interface/network number where this device is expected. The assignment of a number to a physical interface is application specific.

When using NodeIdsof type STRING_1 the NodeIdcontains information about address and DataTypeas string value. Compared to opaque NodeIdsthis format is easier for manual entry by the user.

The NodeId has the following form:

[[<Network>.]<DeviceAddress>.]<Index>.<Sub-Index>:<Datatype>

Network:

This parameter identifies the network and starts with “NW” followed by the decimal number of the selected network, e.g. “NW1” for the first POWERLINK network which is represented by this Server. If the parameter is omitted the selection of a network is server specific.

DeviceAddress:

This parameter identifies the POWERLINK Devicewithin a network. It shall either be “MN” for the POWERLINK Managed Nodeor “CN” followed by the device address, e.g. “CN2”.

Both parameters (Network and Device) are not relevant for Serversthat only implement one single POWERLINK Object Dictionaryand therefore they may be omitted.

Index:

Index of the POWERLINK Object, e.g. “0x1001” for the object ERR_ErrorRegister_U8. The value shall be given as decimal string, or as hexadecimal string preceding the characters “0x”.

Sub-Index:

Sub-Index of the POWERLINK Object, e.g. “17” for accessing Sub-Index 17. The value shall be given as decimal string, or as hexadecimal string preceding the characters “0x”.

If the POWERLINK Objectrequested by Index/Sub-Index is not existing the server shall signal this case with the StatusCode Bad_NodeIdUnknown.

Datatype:

Requested DataTypeof the response data for read access or MonitoredItems. Allowed values are the names of the built-in types 1 to 12, and 15. E.g. if Datatype is “UInt64” the Servershall respond with an unsigned 64 bit integer. Capitalisation of this parameter shall be irrelevant, so “uint64” and “UInt64” shall give the same result. If Datatype is set to “String” or “ByteString” the server shall respond with the same length like the POWERLINK Object. Otherwise, if the bit-length of the referenced POWERLINK Objectis different to the bit-length of the requested DataType,the Servershall signal this case with the StatusCode Bad_NodeIdInvalid.

Examples for String NodeIds:

“0x1001.0:byte” : Object ERR_ErrorRegister_U8

“NW2.CN104.24640.0:UInt16” : Object 0x6040, SubIndex 0, 16 Bit unsigned

“CN1.0x1018.1:UInt32” : VendorId_U32 in Object NMT_IdentityObject_REC