How to re-define param type of a method from the AutoID spec|OPC UA Companion Standards|Forum|OPC Foundation

Forum Scope


Forum Options

Minimum search word length is 3 characters - maximum search word length is 84 characters
Lost password?
sp_Feed sp_PrintTopic sp_TopicIcon
How to re-define param type of a method from the AutoID spec
Igor Gaidouk
New Member
Forum Posts: 1
Member Since:
sp_UserOfflineSmall Offline
08/11/2020 - 12:47
sp_Permalink sp_Print


We are using OPC UA for embedded devices based on AutoID Companion specification. This specification defines several standard methods to access various types of storage media, e.g. in case of RFID technology it would be ReadTag method to read out data from  RFID tags.

The method ReadTag has a list of parameters, that should be given upon the method calling.
The first parameter is of type ScanData, which is a union that defines the format of the data scanned by the device. The type definition of ScanData is also part of the AutoID spec.  The union refers to several data members, which are called ByteString, String and Custom to be able to represent various data formats. It can easily be deduced that there are corresponding standard types behind ByteString and String defined by the basic OPCUA specification, while Custom is intended to be defined and enhanced by the device manufacturer.

In the AutoID CS the  Custom member has the abstract data type BaseDataType that can’t be used directly.
In order to create an usable Custom member with valid data type I want to re-define its definition  and assign one of the standard data types, e.g. String to it.  

My question is, is there a standard way to achieve this?

Right now I can only think of one possible solution:

  1. Define a new union type based on ScanData with Custom member defined as a String instead of BaseDataType and give it a new type name in the device specific namespace, e.g. MyDeviceScanData.
  2. Remove the existing definition of ReadTag method from the NodeSet and define a new one with the same name and param list except the first parameter – it will reference the new MyDeviceScanData instead of ScanData now.


This approach raises several questions:

  • Should the “overloaded” method ReadTag be placed in the same device specific namespace as MyDeviceScanData other than AutoID namespace?
  • Or new ReadTag method definition can be left in the original AutoID namespace and reference the MyDeviceData in the another namespace?
  • Does this approach conform to the general concept at all or is there a different one?

Thanks in advance!

Randy Armstrong
Forum Posts: 1498
Member Since:
sp_UserOfflineSmall Offline
08/11/2020 - 14:33
sp_Permalink sp_Print

When a structure field is a BaseDataType then that means it is a represented by a Variant which is a union of all possible DataTypes.

This means the caller always provides the type information when it uses the 'Custom' option.

If the caller defines a structure then the NodeId of the DataType Encoding Node is always sent on the wire as well.

IOW, the server always knows exactly what the caller sent. There is no need for an a overload.

If a Server wants to advertise what DataTypes are valid for the 'Custom' option then there needs to be additional metadata. If the AutoID specification does not provide a standard way to do this then the Method Metadata Amendment could be adopted:


However, the AutoID spec will need to describe how it expects Servers to use Amendment 3 for this purpose.

Forum Timezone: America/Phoenix
Most Users Ever Online: 510
Currently Online: Ethan Olsen, Martin Lang
Guest(s) 38
Currently Browsing this Page:
1 Guest(s)
Top Posters:
Forum Stats:
Groups: 2
Forums: 10
Topics: 1380
Posts: 4679