Abbildung von OPC UA-Typen nach IEC-Typen

Basistypen

Boolean

BOOL

Byte

BYTE

SByte

SINT

Int16

INT

UInt16

UINT

INT32

DINT

UInt32

UDINT

Int64

LINT

UInt64

ULINT

FLOAT

REAL

Double

LREAL

Duration

LREAL

DateTime

LDATEANDTIME

UtcTime

LTIME

String

STRING

Einfache Strings werden in IEC-Strings umgewandelt.

Die Länge des IEC-Strings kann nachträglich bearbeitet werden und ist frei wählbar.

LocalizedText

STRING

Lokalisierbare Strings werden in einen IEC-String abgebildet.

Spezialtypen:

NodeId

Bytestring

XmlElement

Guid

ExpandedNodeId

StatusCode

QualifiedName

LocalizedText

ExtensionObject

DataValue

DiangosticInfo

Abbildung auf den entsprechenden Typ aus der OPC UA-Spezifikation: OpcUA_<Name>,

Beispiel: OpcUA_NodeId

Es handelt sich um Datentypen aus der OPC UA-Spezifikation, die eine Sonderbehandlung in der SPS-Applikation erfordern.

Nur Lesezugriff wird unterstützt.

Vererbung

Vererbung ist bei allen OPC UA-Typen erlaubt. Beispielsweise können also auch von String und Int32 neue Typen abgeleitet werden.

Hinweis: Bei Ableitungen von Basistypen wird der Basistyp als Grundlage für das Abbilden verwendet. Dadurch ist der abgeleitete OPC UA-Typ in IEC nicht mehr vorhanden.

BaseObjectType als Datentyp

siehe Beschreibung

Wenn in einem Informationsmodell mehr als ein konkreter Objekttyp für eine Variable zulässig ist und es dem Verwender des Modells obliegt den konkreten Typ auszuwählen, dann wird einfach nur BaseObjectType als Typ der Variablen angegeben. Normalerweise generiert CODESYS in diesem Fall einen eigenen Funktionsbaustein und fügt eventuell vorhandene Kindelemente dort ein. Der Anwender darf aber diesen Funktionsblock löschen und auch einen anderen Objekttyp in der Deklaration verwenden. Die einzige Einschränkung ist das es ein Objekttyp aus dem gleichen Informationsmodell sein muss.

VariableType

siehe Beschreibung

Eine Variable in OPC UA kann zusätzlich zu einem Datentyp auch einen VariableType mittels einer HasTypeDefinition referenzieren. Dies wird oft verwendet um eine Variable mit zusätzlichen Metadaten zu dekorieren (AnalogItemType, EngineeringUnits, etc.).

Da in IEC eine Variable immer nur genau einen Typ haben kann, wird eine Struktur generiert, die:

Für einen OPC UA Client ist diese generierte Struktur unsichtbar, er sieht wie erwartet nur den korrekten Datentyp an der Variable und die Metadaten als Kindelemente.

OPC UA-Objekttypen

Funktionsbausteine

Interfaces und AddIns

Funktionsbaustein

Die Member des Interfaces werden Member des Funktionsbausteins.

Beispiel:

Vererbung

Anstatt mehrerer Funktionsbausteine mit Extends zu generieren, wird eine flache Hierarchie erzeugt.

Beispiel:

Ordner

Ein eigener Typ für jede Instanz eines Ordners in einem OPC UA-Objekttyp

Der Anwender darf die Instanzen selbst hinzufügen, indem er die Deklaration der IEC-Bausteine editiert. Dabei müssen allerdings Funktionsbausteine verwendet werden, die aus einer OPC UA Companion Spezifikation stammen.

Alle Instanzen von Funktionsbausteinen unter dem Ordner werden exportiert. Semantische Prüfungen auf Basis der NodeSet2.xml sind nicht möglich.

Initial ist in OPC UA ein Ordner ein Objekttyp. Einen FolderType zur erzeugen ist jedoch nicht ausreichend.

Es liegt in der Verantwortung des Anwenders, dem Ordner geeignete Elemente hinzuzufügen.

BaseObjectType als Ordner

Siehe Beschreibung

(wie bei Ordner)

OPC UA definiert einen eigenen Datentyp für Ordner: der FolderType, siehe oben : Ordner. Allerdings gibt es auch die Möglichkeit, statt diesem Typ nur BaseObjectType in einer Instanz zu deklarieren und dann diesen Typ wie einen Ordner zu verwenden. Seitens OPC UA gibt es hier keine Einschränkungen was als Kindelemente erlaubt ist. Die Abbildung nach IEC sieht in diesen Fall genauso aus wie bei einem FolderType.

Struktur

DUT

Union

Wird aktuell nicht unterstützt

Optionale Member

Werden aktuell nicht unterstützt

Vererbung

Umsetzung wie bei den Objekttypen

Organizes

In der Regel sind nur die Ableitungen dieses Typs relevant. Die Ausnahme ist, wenn Ordner direkt nach IEC abgebildet werden, siehe Abbildung von OPC UA-Typen nach IEC-Typen

HasSubtype

Siehe Abbildung von OPC UA-Typen nach IEC-Typen

HasTypeDefinition

HasComponent

Variablen und Objekte werden in IEC als Variable abgebildet. Jede HasComponent-Referenz wird also zu einer Variablendeklaration in IEC. Methoden werden auch in IEC zu Methoden des Funktionsbausteins.

Die Modellierungsregeln müssen vom Anwender im Informationsmodell-Editor angewendet werden, bevor die IEC-Bausteine generiert werden. Optionale Komponenten können an-/abgewählt werden und konkrete Komponenten für Platzhalter können erzeugt werden.

HasProperty

Properties haben in OPC UA den Charakter von zusätzlicher Metainformation bei Prozessdaten. Sie können statischer Natur sein, zum Beispiel Engineering Units. Sie können sich aber auch durchaus zur Laufzeit des Servers verändern.

Diese Referenz wird in IEC genauso behandelt wie HasComponent. Es werden also auch Variablen dafür am Funktionsbaustein angelegt. Ein offenes Problem ist die Behandlung von Eigenschaften an Variablen in UA (über den Umweg von HasTypeDefinition und VariableType). In IEC müsste die Variable vom Typ INT quasi nochmal strukturiert werden und Kinder haben. Aktuell werden Properties an Variablen in OPC UA ignoriert und sind aus IEC nicht erreichbar.