Typsystem

	Voraussetzungen Diese Funktionalität steht nur für Data-Access-Geräte basierend auf TwinCAT 3 und dem Import von TMC-Symboldateien, sowie der Online-Symbolik zur Verfügung.

Einer der größten Vorteile von OPC UA ist das Meta-Modell, das zur Bereitstellung von Basistypen genauso verwendet werden kann, wie zur Erweiterung des Typsystems durch eigene Modelle. Derselbe Mechanismus wird zur Darstellung realer Objekte (Nodes) verwendet, sodass OPC UA Clients einen Objekttyp bestimmen können.

Der OPC UA Server veröffentlicht Typinformationen von der IEC61131-Welt in seinem Namensraum. Dies umfasst nicht nur Basistypen, wie z. B. BOOL, INT, DINT oder REAL, sondern auch erweiterte Typinformationen, wie z. B. die aktuelle Klasse (Funktionsbaustein) oder Struktur, die ein Objekt repräsentiert.

Typinformationen

Typinformationen sind Bestandteil des UA-Namensraums. Der OPC UA Server erweitert die Basistypinformationen wie folgt:

Lokale Typinformationen, die nur für eine Laufzeit gültig ist, werden in demselben Namensraum, wie die Laufzeitsymbole, gespeichert.
Globale Typinformationen, die über verschiedene Laufzeiten gültig sein können, werden in einem eigenen globalen Namensraum gespeichert.

Das Typsystem ist ebenfalls virtuell verfügbar und kann im Bereich Types des OPC UA Servers eingesehen werden:

Jeder Nicht-Standarddatentyp wird im Bereich BeckhoffCtrlTypes eingetragen.

Grundlagen

Angenommen, die TwinCAT-3-SPS besteht aus einem SPS-Programm mit verschiedenen STRUCTs. Jeder STRUCT wird als Knoten in einem UA-Namensraum repräsentiert, mit jedem Element der Struktur als untergeordneten Knoten.

In dem Beispiel besteht der STRUCT stSampleStruct aus drei untergeordneten Elementen: einer Variable nValue1 vom Typ INT, einer Variable bValue2 vom Typ BOOL und einem weiteren STRUCT stSubStruct, das mit der Variablen nValue vom Typ INT lediglich ein untergeordnetes Element enthält.

Die Struktur selbst ist eine reguläre Variable im UA-Namensraum, die den Datentyp ByteString hat. Die Clients können daher einfach mit dem Wurzelelement (der Struktur selbst) verbunden werden und dessen Werte durch Interpretation des ByteString gelesen/geschrieben werden. Damit die Interpretation jedes untergeordneten Elements vereinfacht wird, enthält das Typsystem mehr Informationen über die Struktur selbst; in erster Linie in der Referenz zur Instanz:

Außerdem enthält das Typsystem mehr Informationen über ST_SampleStruct:

Und in den Referenzen von ST_SampleStruct:

Insgesamt kann das Typsystem sehr nützliche Informationen bieten, wenn ein Client die Struktur weiter interpretieren will.

Objektorientierte Erweiterungen

Angenommen, die TwinCAT-3-SPS-Laufzeit enthält ein SPS-Programm, dessen Struktur wie folgt visualisiert werden kann:

Die zwei Funktionsbausteine Scanner und Drive sind von der Basisklasse Device abgeleitet, indem objektorientierte Erweiterungen der IEC61131-3 verwendet werden. Das Programm MAIN enthält nun die folgenden Deklarationen:

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

Alle drei Objekte sind vom Typ Device, aber auch von ihrem speziellen Datentyp. Der OPC UA Server importiert die Objekte wie folgt:

Der zugrunde liegende Datentyp kann nun in der Referenz jedes Objekts bestimmt werden, z. B. Objekt Scanner1:

Entsprechend des zugrundeliegenden IEC61131-Programms ist das Objekt Scanner1 vom Datentyp Scanner und zeigt ebenfalls, welche Variablen enthalten sind und welcher Art die Variable ist: Eingangs-, Ausgangs- oder interne (lokale) Variable. Das Diagramm oben zeigt, dass nicht nur die Variablen des tatsächlichen Funktionsbausteins hier wiedergegeben werden, sondern auch die abgeleiteten Variablen der Basisklasse. Die gesamte IEC61131-3-Vererbungskette wird im UA-Namensraum repräsentiert.