Type system

	Requirements This functionality is only available for Data Access devices based on TwinCAT 3 and the import of TMC symbol files, as well as the online symbolism.

One of the biggest advantages of OPC UA is the meta-model, which can be used to provide base types as well as to extend the type system with custom models. The same mechanism is used to represent real objects (nodes) so that OPC UA clients can determine an object type.

The OPC UA server publishes type information from the IEC61131 world in its namespace. This includes not only base types such as BOOL, INT, DINT or REAL, but also extended type information such as the current class (function block) or structure that represents an object.

Type information

Type information is part of the UA namespace. The OPC UA server extends the base type information as follows:

Local type information that is only valid for one runtime is stored in the same namespace as the runtime symbols.
Global type information that can be valid for different runtimes is stored in a separate global namespace.

The type system is also virtually available and can be viewed in the Types area of the OPC UA server:

Every non-standard data type is entered in the BeckhoffCtrlTypes area.

Basics

Assuming the TwinCAT 3 PLC consists of a PLC program with different STRUCTs. Each STRUCT is represented as a node in a UA namespace, with each element of the structure as a subordinate node.

In this sample the STRUCT stSampleStruct consists of three subordinate elements: one variable nValue1 of the type INT, one variable bValue2 of the type BOOL and a further STRUCT stSubStruct, which contains only one subordinate element (variable nValue of the type INT).

The structure itself is a regular variable in the UA namespace and has the data type ByteString. The clients can therefore simply be connected to the root element (the structure itself), and its values can be read/written by interpreting the ByteString. To simplify the interpretation of each subordinate element, the type system contains more information about the structure itself, primarily in the instance reference:

In addition, the type system contains more information about ST_SampleStruct:

And in the references of ST_SampleStruct:

Overall, the type system can offer very useful information if a Client wants to interpret the structure further.

Object-orientated extensions

Assuming the TwinCAT 3 PLC runtime contains a PLC program whose structure can be visualized as follows:

The two function blocks Scanner and Drive are derived from the base class Device by using object-oriented extensions of IEC61131-3. The program MAIN now contains the following declarations:

PROGRAM MAIN
VAR
  {attribute 'OPC.UA.DA':='1'}
  Scanner1 : Scanner;
  {attribute 'OPC.UA.DA':='1'}
  Scanner2 : Scanner;
  {attribute 'OPC.UA.DA':='1'}
  DriveX : Drive;
END_VAR

All three objects are of type Device, but also of their special data type. The OPC UA server imports the objects as follows:

The base data type can now be determined in the reference of each object, e.g. object Scanner1:

According to the basic IEC61131 program, the object Scanner1 is of the data type Scanner and also shows which variables are contained and what type the variable is: input, output or internal (local) variable. The diagram above shows that not only the variables of the actual function block are displayed here, but also the derived variables of the base class. The entire IEC61131-3 inheritance chain is represented in the UA namespace.