TS6100 | TwinCAT OPC UA
Home
twincat communication web


Vorwort

TS6100 | TwinCAT OPC UA
Vorwort
Vorwort
Weiterführende Informationen
•
Hinweise zur Dokumentation
•
Sicherheitshinweise


Hinweise zur Dokumentation

Vorwort [image] Hinweise zur Dokumentation
Hinweise zur Dokumentation
Diese Beschreibung wendet sich ausschließlich an ausgebildetes Fachpersonal der Steuerungs- und Automatisierungstechnik, das mit den geltenden nationalen Normen vertraut ist.
Zur Installation und Inbetriebnahme der Komponenten ist die Beachtung der Dokumentation und der nachfolgenden Hinweise und Erklärungen unbedingt notwendig.
Das Fachpersonal ist verpflichtet, für jede Installation und Inbetriebnahme die zu dem betreffenden Zeitpunkt veröffentliche Dokumentation zu verwenden.
Das Fachpersonal hat sicherzustellen, dass die Anwendung bzw. der Einsatz der beschriebenen Produkte alle Sicherheitsanforderungen, einschließlich sämtlicher anwendbaren Gesetze, Vorschriften, Bestimmungen und Normen erfüllt.
Disclaimer
Diese Dokumentation wurde sorgfältig erstellt. Die beschriebenen Produkte werden jedoch ständig weiter entwickelt.
Wir behalten uns das Recht vor, die Dokumentation jederzeit und ohne Ankündigung zu überarbeiten und zu ändern.
Aus den Angaben, Abbildungen und Beschreibungen in dieser Dokumentation können keine Ansprüche auf Änderung bereits gelieferter Produkte geltend gemacht werden.
Marken
Beckhoff®, TwinCAT®, EtherCAT®, Safety over EtherCAT®, TwinSAFE®, XFC®und XTS® sind eingetragene und lizenzierte Marken der Beckhoff Automation GmbH.
Die Verwendung anderer in dieser Dokumentation enthaltenen Marken oder Kennzeichen durch Dritte kann zu einer Verletzung von Rechten der Inhaber der entsprechenden Bezeichnungen führen.
Patente
Die EtherCAT Technologie ist patentrechtlich geschützt, insbesondere durch folgende Anmeldungen und Patente:
EP1590927, EP1789857, DE102004044764, DE102007017835
mit den entsprechenden Anmeldungen und Eintragungen in verschiedenen anderen Ländern.
Die TwinCAT Technologie ist patentrechtlich geschützt, insbesondere durch folgende Anmeldungen und Patente:
EP0851348, US6167425 mit den entsprechenden Anmeldungen und Eintragungen in verschiedenen anderen Ländern.
EtherCAT® ist eine eingetragene Marke und patentierte Technologie lizensiert durch die Beckhoff Automation GmbH, Deutschland
Copyright
© Beckhoff Automation GmbH & Co. KG, Deutschland.
Weitergabe sowie Vervielfältigung dieses Dokuments, Verwertung und Mitteilung seines Inhalts sind verboten, soweit nicht ausdrücklich gestattet.
Zuwiderhandlungen verpflichten zu Schadenersatz. Alle Rechte für den Fall der Patent-, Gebrauchsmuster- oder Geschmacksmustereintragung vorbehalten.


Sicherheitshinweise

Vorwort [image] Sicherheitshinweise
Sicherheitshinweise
Sicherheitsbestimmungen
Beachten Sie die folgenden Sicherheitshinweise und Erklärungen!
Produktspezifische Sicherheitshinweise finden Sie auf den folgenden Seiten oder in den Bereichen Montage, Verdrahtung, Inbetriebnahme usw.
Haftungsausschluss
Die gesamten Komponenten werden je nach Anwendungsbestimmungen in bestimmten Hard- und Software-Konfigurationen ausgeliefert. Änderungen der Hard- oder Software-Konfiguration, die über die dokumentierten Möglichkeiten hinausgehen, sind unzulässig und bewirken den Haftungsausschluss der Beckhoff Automation GmbH & Co. KG.
Qualifikation des Personals
Diese Beschreibung wendet sich ausschließlich an ausgebildetes Fachpersonal der Steuerungs-, Automatisierungs- und Antriebstechnik, das mit den geltenden Normen vertraut ist.
Erklärung der Symbole
In der vorliegenden Dokumentation werden die folgenden Symbole mit einem nebenstehenden Sicherheitshinweis oder Hinweistext verwendet. Die Sicherheitshinweise sind aufmerksam zu lesen und unbedingt zu befolgen!
SmallWarningYellow GEFAHR
Akute Verletzungsgefahr!
Wenn der Sicherheitshinweis neben diesem Symbol nicht beachtet wird, besteht unmittelbare Gefahr für Leben und Gesundheit von Personen!
SmallWarningYellow WARNUNG
Verletzungsgefahr!
Wenn der Sicherheitshinweis neben diesem Symbol nicht beachtet wird, besteht Gefahr für Leben und Gesundheit von Personen!
SmallWarningYellow VORSICHT
Schädigung von Personen!
Wenn der Sicherheitshinweis neben diesem Symbol nicht beachtet wird, können Personen geschädigt werden!
Hinweis
Schädigung von Umwelt oder Geräten
Wenn der Hinweis neben diesem Symbol nicht beachtet wird, können Umwelt oder Geräte geschädigt werden.
Tipp oder Fingerzeig
Dieses Symbol kennzeichnet Informationen, die zum besseren Verständnis beitragen.


Übersicht

Übersicht
Übersicht
OPC Unified Architecture (OPC UA) ist die nächste Generation des klassischen OPC‑Standards. Es handelt es sich hierbei um ein weltweit standardisiertes Kommunikationsprotokoll, über das Maschinendaten hersteller- und plattformunabhängig ausgetauscht werden können. OPC UA integriert gängige Sicherheitsstandards bereits direkt im Protokoll. Ein weiterer großer Vorteil von OPC UA gegenüber dem klassischen OPC-Standard ist die Unabhängigkeit vom COM/DCOM-System.
Detaillierte Informationen zu OPC UA finden Sie auf den Webseiten der OPC Foundation.
Komponenten
Folgende Softwarekomponenten wurden für Win32/64- und Windows-CE-basierte Systeme eingebunden:
Software-Komponente | Beschreibung
OPC UA Server | Stellt eine OPC-UA-Server-Schnittstelle zur Verfügung, damit UA-Clients auf die TwinCAT‑Laufzeit zugreifen können.
OPC UA Client | Stellt eine OPC-UA-Client-Funktionalität zur Verfügung, damit die Kommunikation mit anderen OPC UA Servern auf der Grundlage von PLCopen-genormten Funktionsbausteinen sowie einem einfach zu konfigurierenden I/O-Gerät möglich ist.
Folgenden Softwarekomponenten wurden für Win32/64-basierte Systeme eingebunden:
Software-Komponente (nur Windows) | Beschreibung
OPC UA Configurator | Grafische Benutzerschnittstelle für die Konfiguration des TwinCAT OPC UA Server
OPC UA Sample Client | Grafische Beispielimplementierung eines OPC UA Clients um einen ersten Verbindungstest mit dem TwinCAT OPC UA Server durchführen zu können.
OPC UA Gateway | Wrapper-Technologie, die sowohl eine OPC‑COM-DA-Server-Schnittstelle als auch OPC-UA-Server-Aggregationsfähigkeiten zur Verfügung stellt.
Weiterführende Informationen
•
Szenarien
•
Änderungsübersicht OPC UA Server
•
Versionsübersicht
•
Anwendungsbeispiele


Szenarien

Übersicht [image] Szenarien
Szenarien
Im Folgenden werden einige Szenarien erläutert, gemäß derer die Komponenten je nach Anwendungsfall und Infrastruktur implementiert und verwendet werden können:
▪
OPC UA Server: Integriert in Industrie-PC oder Embedded-PC
▪
OPC UA Server: Läuft auf einem Zentralrechner mit Verbindung zu ferner(n) TwinCAT‑Laufzeit(en).
▪
OPC UA Server: Zugriff auf BC Controller
OPC UA Server: Integriert in Industrie-PC oder Embedded-PC
Empfohlenes Szenario
Dieses Szenario beschreibt, wie der TwinCAT OPC UA Server unter normalen Umständen eingesetzt werden sollte.
Einer der größten Vorteile des TwinCAT OPC UA Servers besteht darin, dass er selbst in die kleinste Embedded-Plattform, z. B. die CX8000-Baureihe, integriert werden kann. Dank dieser Integration ist das allgemeine Handling sehr einfach und komfortabel. OPC UA Clients, z. B. HMI-oder MES/ERP-Systeme, können eine Verbindung mit dem OPC UA Server herstellen und aus der TwinCAT-Laufzeit stammende Symbolinformationen lesen oder schreiben.
Auf dem zentralen Server laufen folgende Softwarekomponenten und Konfigurationen:
▪
Dritter OPC UA Client, der z. B. ein HMI-, MES-, oder ERP-System sein kann.
Auf dem Industrie-PC oder Embedded-PC laufen folgende Softwarekomponenten und Konfigurationen:
▪
Der OPC UA Server stellt automatisch eine Verbindung mit der ersten lokalen TwinCAT‑SPS‑Laufzeit her.
▪
TwinCAT-Laufzeit
Dieses Szenario hat folgende Vorteile:
▪
Die Netzwerknutzung ist optimiert, weil sie auf OPC-UA-Kommunikationstechniken aufbaut, z. B. OPC-UA-Registrierungen.
▪
Die Speichernutzung ist dezentral. Jedes Gerät ist ausschließlich für den eigenen Speicherbedarf zuständig.
▪
OPC UA verfügt über direkt ins Protokoll integrierte Sicherheitsmechanismen. Dies ist z. B. sehr praktisch, wenn einer der Industrie-PCs oder Embedded-PC übers Internet verbunden ist.
OPC UA Server: Läuft auf einem Zentralrechner mit Verbindung zu ferner(n) TwinCAT-Laufzeit(en)
Dieses Szenario beschreibt die klassische Implementierung von OPC-Server. Server, die die alte OPC‑DA‑Technologie verwenden, waren häufig auf einem zentralen Server implementiert, statt auf dem Industrie-PC, auf dem die TwinCAT-Laufzeit ausgeführt wird, um die DCOM-Konfigurationen zu vermeiden. (Zur Erinnerung: Im Gegensatz zu OPC UA basiert OPC DA auf COM/DCOM‑Technologien)
Auf dem zentralen Server laufen folgende Softwarekomponenten und Konfigurationen:
▪
TwinCAT 3 ADS (oder TwinCAT 2 CP) für die erforderliche ADS-Konnektivität
▪
OPC UA Server mit Datenzugriffsgeräten für ferne TwinCAT-Laufzeiten konfiguriert
▪
ADS-Routen zu fernen TwinCAT-Laufzeiten
▪
Symboldateien von jeder fernen TwinCAT-Laufzeit
▪
OPC UA Client, der z. B. ein HMI-, MES- oder ERP-System sein kann.
Auf dem Industrie-PC oder Embedded-PC laufen folgende Softwarekomponenten und Konfigurationen:
▪
TwinCAT-Laufzeit
▪
ADS-Route zum zentralen Server
Je mehr ferne TwinCAT-Laufzeiten mit dem zentralen OPC UA Server verbunden werden, desto höher ist die Netzwerknutzung.
Der OPC UA Server verwendet fortschrittliche ADS-Aufzeichnungstechniken, um die Symbolwerte von der TwinCAT-Laufzeit abzufragen. Je mehr Symbole vorhanden sind, desto mehr zyklische Abfragen sind unterwegs. Demzufolge findet die optimierte OPC-UA-Kommunikation nur lokal auf dem zentralen Server statt (zwischen OPC UA Client und OPC UA Server).
Dieses Szenario weist im Vergleich zu Szenario 1 folgende Nachteile auf:
▪
Die Netzwerknutzung kann abhängig von der Anzahl vorhandener Geräte und Symbole sehr hoch sein.
▪
Der Speicherbedarf auf dem zentralen Server ist sehr hoch, weil der OPC UA Server Symbolinformationen von jeder TwinCAT-Laufzeit importieren muss.
▪
Keine Sicherheit zwischen zentralem Server und der TwinCAT-Laufzeit dank Datenverschlüsselung – ADS wurde auf hohe Leistung ausgelegt.
▪
Die Notwendigkeit, bei jeder SPS-Programmänderung Symboldateien zwischen TwinCAT‑Laufzeit und zentralem Server auszutauschen.
OPC UA Server: Zugriff auf BC Controller
Auch wenn kleine BC Controller nicht in der Lage sind, einen eigenen OPC UA Server auszuführen, können Sie trotzdem Zugriff auf die auf einem fernen BC Controller, z. B. ein BC9191, ausgeführte SPS‑Laufzeit haben und deren Symbolwerte über OPC UA veröffentlichen. Bei diesem Szenario muss der OPC UA Server zusammen mit einer TwinCAT 3 ADS (oder TwinCAT 2 CP) auf einem anderen Rechner ausführt und das Szenario auf die gleiche Weise wie Szenario 2 konfiguriert werden.


Änderungsübersicht OPC UA Server

Übersicht [image] Änderungsübersicht OPC UA Server
Änderungsübersicht OPC UA Server
In der nachfolgenden Änderungsübersicht werden wichtige Unterschiede zwischen den Produktversionen dargestellt. Diese Informationen sind wichtig, wenn das Softwareprodukt eine bedeutende Softwareaktualisierung erfährt.
Wichtige Änderungen in der Version | Komponente | Anmerkungen
Alle Versionen | Arrays in einem SPS-Programm | Standardmäßig werden Array-Elemente eines SPS-Arrays nicht als getrennte Knoten im UA-Namensraum angezeigt. Stattdessen wird nur ein Knoten für das gesamte Array verwendet und UA-Clients können auf jedes Element über dessen IndexRange zugreifen. (Siehe auch: Verwendung von Arrays)
2.1 | Aufzählungen (Enums) in einem SPS-Programm | Standardmäßig werden Aufzählungen in einem SPS-Programm nicht als EnumTypen im UA-Namensraum angezeigt. In der vorherigen Version waren diese einfach ein Int16.
2.1 | NamespaceName | Seit der Version 2.1 wird der NamespaceName gemäß dem URI-Konzept generiert und beinhaltet stets den Hostnamen des Rechners, auf dem der UA-Server läuft. In älteren Versionen ist der NamespaceName gleich dem Namen, der im Konfigurator festgelegt wurde, z. B. „PLC1“. Diese Information ist besonders dann wichtig, wenn ein UA-Client vor dem Zugriff auf einen Knoten den NamespaceName in einen NamespaceIndex auswertet. Für Kompatibilitätszwecke und zur Vereinfachung der Aktualisierung ohne Eingriff auf den UA-Client, bietet die Version 2.2 des TwinCAT OPC UA Servers einen Mechanismus, um das alte NamespaceName-Konzept zu aktivieren. (Siehe auch: Server)
2.2 | Strukturen in SPS | Seit Version 2.2.x kann auf Strukturen in einem SPS-Programm über ein StructuredType im UA-Namensraum zugegriffen werden. Dadurch können UA‑Clients Typen von Elementen im STRUCT interpretieren. (Siehe auch: StructuredTypes)
2.2 | Namensraum-Auslegung einer C++-Modulinstanz | Im Vergleich zu älteren Versionen (bis 2.1.x) wurde der UA-Namensraum eines C++‑Moduls in Version 2.2.x neu entworfen, um fortschrittliche Funktionalitäten, wie Methodenaufruf für eine C++‑Modulinstanz zuzulassen.


Versionsübersicht

Übersicht [image] Versionsübersicht
Versionsübersicht
Das Supplement/Function-Produkt TwinCAT OPC UA wird in verschiedenen Setup-Versionen ausgeliefert, welche unterschiedliche Entwicklungsstände widerspiegeln. Für neue Projekte wird der Wechsel auf die aktuellste Setup-Version empfohlen, um alle neuen Produktfunktionalitäten verwenden zu können. Für Bestandsprojekte stehen weiterhin ältere Setup-Versionen zum Download bereit.
Aktuell gibt es zwei Versionsstände:
▪
Setup-Version 3.x.x: Langjährige Bestandsversion, welche bereits eine Vielzahl an Funktionen bietet. Die Version wird weiterhin im Hinblick auf Optimierungen gepflegt.
▪
Setup-Version 4.x.x: Neue Version. Zukünftige Weiterentwicklungen und neue Produktfunktionalitäten finden nur noch in dieser Version statt.
Die folgende Tabelle gibt einen Überblick über die verschiedenen Versionsstände im Hinblick auf deren Produktfunktionalitäten.
Funktionalität | 3.x.x | 4.x.x | Bemerkungen
Data Access SPS | ja | ja | Ermöglicht Lese/Schreib-Zugriff auf die TwinCAT-2/3-SPS
Data Access TcCOM | ja | ja | Ermöglicht Lese/Schreib-Zugriff auf TwinCAT-3-TcCOM-Module
Data Access I/O Task | ja | ja | Ermöglicht Lese/Schreib-Zugriff auf die TwinCAT-2/3-I/O-Task
Data Access BC Steuerungen | ja | ja | Ermöglicht Lese/Schreib-Zugriff auf Beckhoff-BC-Steuerungen
Historical Access SPS | ja | ja | Ermöglicht die Aktivierung von Variablen aus der TwinCAT-2/3-SPS für Historical Access
Historical Access TcCOM | ja (nur TC3 C++) | ja | Ermöglicht die Aktivierung von Variablen aus einem TwinCAT-3-TcCOM-Modul für Historical Access
Historical Access I/O Task | nein | ja | Ermöglicht die Aktivierung von Variablen aus einer TwinCAT-2/3-I/O-Task für Historical Access
Historical Access BC Steuerungen | nein | ja | Ermöglicht die Aktivierung von Variablen aus einer Beckhoff-BC-Steuerung für Historical Access
Historical Access für existierende Projekte | nein | ja | Ermöglicht die Aktivierung von Variablen für Historical Access ohne dabei das Laufzeitprojekt anpassen zu müssen
Alarms and Conditions SPS | ja | ja | Ermöglicht die Aktivierung von Variablen aus der TwinCAT 2/3 SPS für Alarms and Conditions
Alarms and Conditions TcCOM | nein | ja | Ermöglicht die Aktivierung von Variablen aus einem TwinCAT-3-TcCOM-Modul für Alarms and Conditions
Alarms and Conditions I/O Task | nein | ja | Ermöglicht die Aktivierung von Variablen aus einer TwinCAT-2/3-I/O-Task für Alarms and Conditions
Alarms and Conditions BC-Steuerungen | nein | ja | Ermöglicht die Aktivierung von Variablen aus einer Beckhoff-BC-Steuerung für Alarms and Conditions
Alarms and Conditions für existierende Projekte | nein | ja | Ermöglicht die Aktivierung von Variablen für Alarms and Conditions ohne dabei das Laufzeitprojekt anpassen zu müssen
Methodenaufrufe SPS | ja | ja | OPC UA Server ermöglicht die Aktivierung und Darstellung von TwinCAT‑3‑SPS‑Methoden als OPC‑UA‑Methode
Methodenaufrufe TcCOM | ja (nur TC3 C++) | ja | OPC UA Server ermöglicht die Aktivierung und Darstellung von TwinCAT‑3‑C++‑Methoden als OPC‑UA‑Methode
Security X509 Zertifikate self-signed | ja | ja, konfiguierbar | Generierung von selbst-signierten Zertifikaten
Security X509 Zertifikate custom | ja | ja | Ermöglicht die Verwendung von eigenen Zertifikatsautoritäten
Security Benutzerauthentifizierung | ja | ja | OPC UA Server ermöglicht Authentifizierung von lokalen oder Domänenbenutzern
Security Zugriffslevel Namespace-Ebene | nein | ja | OPC UA Server ermöglicht Definition von verschiedenen Zugriffsleveln auf Namensraum-Ebene
Security Zugriffslevel Node-Ebene | nein | ja | OPC UA Server ermöglicht Definition von verschiedenen Zugriffsleveln auf Node-Ebene
Konfigurator im Visual Studio | nein | ja | -
Konfigurator Remotezugriff | nein | ja | Konfigurator ermöglicht die Remote-Konfiguration von TwinCAT OPC UA Servern unabhängig vom verwendeten Betriebssystem auf dem Zielgerät.


Anwendungsbeispiele

Übersicht [image] Anwendungsbeispiele
Anwendungsbeispiele
Weiterführende Informationen
•
Nachbearbeitung in der Cloud


Nachbearbeitung in der Cloud

Übersicht [image] Anwendungsbeispiele [image] Nachbearbeitung in der Cloud
Nachbearbeitung in der Cloud
Das Gesamtkonzept zur Bereitstellung einer generischen, standardisierten und aufrufbaren Schnittstelle in der Cloud, die eingehende Daten zur weiteren Analyse akzeptiert, basiert neben den dezentralisierten Clients, die diesen Service aufrufen, auf einem Endpunkt in der Cloud, der entweder eine Windows-basierte virtuelle Maschine oder ein echte Hardware ist, auf der ein Windows Betriebssystem läuft. In dieser Dokumentation wird dieses Gerät im Allgemeinen als „OPC UA Server” (in der Cloud) bezeichnet.
Grafik aus Post-processing in the Cloud (ie2en0n1.png)
Daten-Logger
Die Dokumentation zeigt, wie auf Rechenressourcen in der Cloud zugegriffen werden kann und dezentrale TwinCAT-SPS-Geräte angeschlossen werden können, um diese Ressourcen zu nutzen. Als erstes Anwendungsbeispiel kann dieser Anwendungsfall auf ein typisches Datenspeicherungsszenario angewandt werden, in dem dezentrale TwinCAT-SPS-Geräte Daten an die Cloud senden, in der die eingehenden Daten in einer SQL-Datenbank über den TwinCAT Database Server gespeichert werden. Obwohl das allgemeine Szenario ebenfalls das Hin- und Zurücksenden von Daten umfasst (d. h. Senden von Parametern an die Cloud, Ausführung der Berechnungen in der Cloud und dann Rücksendung der berechneten Ergebnisse), erfordert dieses spezifische Szenario nicht die Rückgabe von Ergebnissen aus der Cloud.
Grafik aus Post-processing in the Cloud (ifdspl62.png)
Systemanforderungen: OPC UA Server („Die Cloud“)
Die Cloud muss in der Lage sein, eine der folgenden Betriebssystemvarianten zu hosten. Beachten Sie dabei, dass die Verwendung von Virtualisierungstechnologie eine kostenintensivere Lösung für 64‑Bit‑Betriebssysteme erfordert.
Gerät ist eine virtuelle Maschine
▪
32-Bit-Windows-Betriebssystem
▪
64-Bit-Windows-Betriebssystem mit CPU Core Isolation (mindestens 2 Kerne erforderlich)
Gerät ist eine dedizierte Hardware
▪
32-Bit-Windows-Betriebssystem
▪
64-Bit-Windows-Betriebssystem
Zusätzlich müssen die folgenden Softwarekomponenten auf dem Gerät installiert werden:
▪
TwinCAT 3 XAR (nur Runtime) oder XAE (Runtime und Engineering)
▪
TwinCAT 3 Function TF6100 OPC UA
Beachten Sie, dass bei Installation eines kompletten TwinCAT 3 XAE weitere Konfigurationseinstellungen sinnvoll sein können, wie z. B. das Handling von Lizenzen oder die Möglichkeit zum Debuggen des Geräts direkt in der Cloud. Zum Speichern von Daten in einer zentralen Datenbank die von einem Client eingehen, müssen die folgenden Softwarekomponenten installiert sein:
▪
TwinCAT 3 Function TF6420 Database
Systemanforderungen: Dezentralisierter OPC UA Client
Der dezentralisierte OPC UA Client basiert auf einer TwinCAT-3-SPS-Laufzeit und kann daher auf jeder Hardwarekonfiguration gehostet werden, die den Betrieb einer TwinCAT-3-SPS unterstützt. Zudem muss die TwinCAT 3 Function TF6100 OPC UA auf dem Client-Gerät installiert werden, um den TwinCAT OPC UA Client nutzen zu können, um UA-Methoden auf dem Server in der Cloud auszuführen.
Technische Beschreibung
Die Realisierung eines OPC UA Servers in der Cloud ist sehr anwendungsspezifisch. Beckhoff stellt eine allgemeine Architekturbeschreibung zur Verfügung, unabhängig von dem Anwendungsfall im Einzelnen. Als Anwendungsbeispiel beschreibt dieser Artikel häufig ein Datenaggregationsszenario, bei dem Prozessdaten von dezentralisierten Clients über OPC UA zu einem zentralen Server übertragen werden, auf welchem die Daten in einer zentralen Datenbank angesammelt werden. Der Vorteil von OPC UA besteht in diesem Fall nicht nur in der standardisierten Schnittstelle (und daher zur Nutzung dieses Konzepts für jede Art von OPC UA Client), sondern auch in der Möglichkeit, den Kommunikationskanal zu sichern, indem der integrierte Sicherheitsmechanismus von OPC UA eingesetzt wird.
Der TwinCAT OPC UA Server wird verwendet, um die in der IEC61131-3 SPS-definierten Methoden dem OPC‑UA‑Namensraum offenzulegen. Diese Methoden können von jedem TwinCAT OPC UA Client (auf der Grundlage der PLCopen‑Funktionsbausteine) oder von 3rd-Party OPC UA Clients aufgerufen werden.
Dezentralisierter OPC UA Client
Der Hauptzweck des OPC UA Clients besteht darin, Methoden auf dem Remote-Server aufzurufen. Der Client ist mit großer Wahrscheinlichkeit ein TwinCAT-3-Embedded-Gerät, das den dezentralen Teil der Anwendung erfüllt. Dies würde für das Datenaggregations-Beispiel bedeuten, Prozessdaten abzufragen und sie durch Aufruf einer Methode an den Server zu senden.
Schnittstellenbeschreibung (zur Cloud)
Als Schnittstelle zu einem zentralisierten Cloud-System gibt es nur zwei vom Server bereitgestellte Methoden:
▪
int Send(data): Diese Methode überträgt die Daten über einen OPC-UA-Methodenaufruf vor und gibt eine JobID zurück
▪
int QueryState(jobID): Unter Verwendung der zuvor abgerufenen JobID kann der Client zyklisch den aktuellen Status des Jobs abfragen. Dies könnte ausgelassen werden, wenn der Server in der Cloud alle Situationen bearbeiten kann oder der Client bei Problemen ohnehin nicht aushelfen kann.
Die Kommunikation zwischen Clients und der Cloud kann durch die eingebauten Sicherheitskonzepte von OPC UA gesichert werden, z. B. durch die Verwendung von Client- und Server-Zertifikaten zur Verschlüsselung der Datenkommunikation.
Die Cloud
Der OPC UA Server in der Cloud basiert auf TwinCAT-3-SPS-Methoden, die dem OPC‑UA‑Namensraum offengelegt werden. Das SPS-Projekt enthält die folgenden drei Komponenten:
▪
MethodCall Provider: Diese Komponente bietet die zuvor erwähnte Send-Methode, bei der Daten gesammelt, eine JobID erstellt und die Daten als verschiedene Jobs in die Queue eingestellt werden. Darüber hinaus könnte es eine QueryState-Methode geben, um es OPC UA Clients zu ermöglichen, den aktuellen Jobstatus abzufragen.
▪
Queue: Die Warteschlange speichert eine Liste der Jobs, die ausgeführt werden sollen. Jeder Job in der Warteschlange enthält die folgenden Informationen: {ID, Status, Data}. Neue Elemente (Jobs) werden durch den MethodCall Provider hinzugefügt und können durch diesen auch gelöscht werden. Die gesamte Warteschlange kann innerhalb des SPS-Programms auf einer Hash-Tabelle basieren.
▪
Aggregator: Die Anwendung, die die Jobs verarbeitet. Sie schaut zyklisch in der Queue, ob es zu bearbeitende Jobs gibt. Wenn dies der Fall ist, übernimmt sie den Job (stellt den Status auf „verarbeitet“) und beginnt mit der Verarbeitung des Jobs, z. B. der Verbindung zu einer Datenbank über die Funktionsbausteine des TwinCAT Database Server. Beachten Sie, dass es mehr als einen Aggregator geben kann, um eine parallele Verarbeitung der Queue zu ermöglichen.
Grafik aus Post-processing in the Cloud (ivkkemq1.png)
Beispiel
Das folgende Beispiel illustriert das Szenario durch die Ausführung einfacher Jobs: Jobs können dem Server von einem OPC UA Client vorgelegt werden. In diesem Beispiel bestehen die Jobdaten aus einem definierbaren Zeitintervall, das vom Aggregator aufgenommen wird, um den Job fertigzustellen. Das Beispiel besteht aus den folgenden SPS-Komponenten auf dem OPC UA Server:
▪
ST_JobEntry: Repräsentiert einen Job in der Queue. Der Job besteht bei den Daten lediglich aus einem Namen und einer Zeitdauer. Eine Dauer definiert die Zeitspanne, die ein Job benötigt.
▪
E_JobState: Repräsentiert den Status eines Jobs. Die Beispielimplementierung definiert die folgenden Werte: QUEUED, PROCESSING, READY, FAILED und INVALID.
▪
LongTerm: Repräsentiert den MethodCall Server (besteht aus den Methoden Calc_Request und Calc_Response) sowie den Aggregator, der den Job verarbeitet (der im Funktionsbaustein implementiert ist)
▪
FB_SpecialHashTableCtrl: Repräsentiert die Queue in Form einer Hash-Tabelle, wie dies durch SPS-Beispiele vom Beckhoff Informationssystem wiedergegeben ist. Hier werden verschieden Methoden zum Umgang mit der Warteschlange gegeben (Hinzufügen, Zählen, GetFirst, GetNext, Lookup, Entfernen, Zurücksetzen).
Verwendung des Beispiels
Der UA-Expert könnte als Beispiel-Client verwendet werden, um die Methoden aufzurufen, die vom OPC UA Server in der Cloud bereitgestellt werden. Durch Aufruf der Methode Calc_Request erhält der Client eine JobID (oder 0 zur Anzeige eines Fehlers):
Grafik aus Post-processing in the Cloud (ij24v1l1.png)
Durch Aufruf der Methode Calc_Response mit der JobID kann der Client den JobState abfragen. Zudem werden die vorher eingestellte Dauer und der Jobname als spätere Referenz zurückgegeben.
Grafik aus Post-processing in the Cloud (igclmg7.png)
Installation
Das folgende Kapitel beschreibt die Installation und Konfiguration jeder Softwarekomponente, die auf dem Server in der Cloud erforderlich ist.
Nur Runtime
Wenn der Server nicht die Engineering‑Umgebung von TwinCAT 3 hostet, muss die TwinCAT‑3‑XAR‑Installation verwendet werden. Beachten Sie, dass in diesem Fall das gesamte Handling zur ordnungsgemäßen Funktion mehrere Schritte involviert und die zukünftige Wartung ggf. schwieriger ist, da der XAR-Installation die Programmierungs- und Debugging-Umgebung fehlt. In diesem Szenario muss der Benutzer sicherstellen, dass die Pflege der ADS-Routen zwischen dem tatsächlichen Engineering-Computer (auf dem das SPS-Programm für den Server entwickelt wird) und dem Gerät, das den Server in der Cloud hostet, nicht nur den Download und das Debugging des SPS-Programms erlauben muss, sondern auch die Aktivierung von Lizenzen für die TwinCAT‑3‑Laufzeit. Beachten Sie, dass Sie die Firewall-Ports öffnen müssen, um ADS-Verkehr zu ermöglichen. In der ADS‑Dokumentation erhalten Sie weitere Informationen. Zur einfacheren Handhabung der TwinCAT‑3‑Laufzeitlizenzen wurde das Tool TC3 License Request Generator entwickelt. Dieses kann über den Beckhoff FTP-Server heruntergeladen werden und ermöglicht die Erstellung von License Request Files und den Import von License Response Files:
Runtime und Engineering
Dies ist das empfohlene Setup-Szenario. Der Server in der Cloud hostet eine TwinCAT 3 Runtime und die entsprechenden Engineering‑Komponenten, um das Debuggen und eine einfachere Handhabung des Laufzeitsystems zu ermöglichen. In diesem Fall ist es erforderlich, TwinCAT 3 XAE auf dem System zu installieren.
Zusätzliche Software
Nach erfolgreicher Installation von TwinCAT XAE oder XAR müssen die folgenden Softwarekomponenten auf dem Gerät installiert und konfiguriert werden:
TF6100 OPC UA
Die Function TF6100 installiert einen OPC UA Server (und Client) auf dem Gerät. Der Server ist erforderlich, um den OPC UA Clients die SPS-Methoden zur Verfügung zu stellen. Wenn das SPS-Programm in die Laufzeit heruntergeladen wird, importiert der OPC UA Server automatisch die erste SPS-Laufzeit in seinen Namensraum. Sämtliche Variablen und Methoden der SPS, die als verfügbar über OPC UA gekennzeichnet sind, werden in den OPC-UA-Namensraum importiert und werden für Clients verfügbar. In der TF6100-Dokumentation erhalten Sie weitere Informationen.
TF6420 Database
Wenn der Server die von den Clients erhaltenen Daten in einer Datenbank speichern soll, muss die TF6420-Function verwendet werden. Sie bietet generische Funktionsblöcke für die TwinCAT-3-SPS für den Zugriff auf die Datenbank, z. B. um Werte in eine Datenbanktabelle einzufügen. Installieren Sie das TF6420-Setup und konsultieren Sie die TF6420-Dokumentation für weitere Informationen zur Nutzung der entsprechenden Funktionsbausteine.
Lizenzierung
Alle TwinCAT‑3‑Softwareprodukte erfordern eine Lizenz, um auf dem Server verfügbar zu sein. Die Lizenz kann entweder aus einer 7-Tage-Testlizenz oder aus einer uneingeschränkten Lizenz bestehen. Lizenzen können unter Verwendung des TwinCAT 3 XAE Lizenzmanagers aktiviert werden. Wenn eine TwinCAT-3-XAR-Installation auf dem Server verwendet wird, verwenden Sie den TC3 License Generator.


Installation

Installation
Installation
Weiterführende Informationen
•
Systemvoraussetzungen
•
Installation (TC3)
•
Installation (TC2)
•
Installation Windows CE (TC3)
•
Installation Windows CE (TC2)
•
Lizenzierung (TC3)
•
Lizenzierung (TC2)


Systemvoraussetzungen

Installation [image] Systemvoraussetzungen
Systemvoraussetzungen
OPC UA Server
Technische Daten | Beschreibung
Betriebssystem | Windows 7, 10 Windows CE 6/7 Windows Embedded Standard 2009 Windows Embedded 7 Windows Server 2008 R2 Windows Server 2012
Zielplattformen | PC-Architektur (x86, x64)
.NET Framework | 4.5.2 (nur benötigt für Konfigurator)
TwinCAT-Version | TwinCAT 2, TwinCAT 3
TwinCAT-Installationslevel | TwinCAT 2 CP, PLC, NC-PTP TwinCAT 3 XAE, XAR, ADS
Benötigte TwinCAT-Lizenz | TS6100 TwinCAT OPC UA (für TwinCAT 2) TF6100 TC3 OPC UA (für TwinCAT 3)
OPC UA Client
Technische Daten | Beschreibung
Betriebssystem | Windows 7, 10 Windows CE 6/7 Windows Embedded Standard 2009 Windows Embedded 7 Windows Server 2008 R2 Windows Server 2012
Zielplattformen | PC-Architektur (x86, x64)
.NET Framework | ---
Minimale TwinCAT-Version | TwinCAT 2, TwinCAT 3
Minimales TwinCAT-Installationslevel | TwinCAT 2 PLC, NC-PTP TwinCAT 3 XAE, XAR
Benötigte TwinCAT-Lizenz | TS6100 TwinCAT OPC UA (für TwinCAT 2) TF6100 TC3 OPC UA (für TwinCAT 3)
OPC UA I/O Client
Technische Daten | Beschreibung
Betriebssystem | Windows 7, 10 Windows CE 7 Windows Embedded 7 Windows Server 2008 R2 Windows Server 2012
Zielplattformen | PC-Architektur (x86, x64)
.NET Framework | 4.6 (only for namespace browser)
Minimale TwinCAT-Version | TwinCAT 3.1 Build 4022.4
Minimales TwinCAT-Installationslevel | TwinCAT 3 XAE, XAR
Benötigte TwinCAT-Lizenz | TF6100 TC3 OPC UA
OPC UA Gateway
Technische Daten | Beschreibung
Betriebssystem | Windows 7, 10 Windows Embedded Standard 2009 Windows Embedded 7 Windows Server 2008 R2 Windows Server 2012
Zielplattformen | PC-Architektur (x86, x64)
.NET Framework | ---
Minimale TwinCAT-Version | ---
Minimales TwinCAT-Installationslevel | ---
Benötigte TwinCAT-Lizenz | ---
OPC UA Configurator
OPC UA Configurator | Beschreibung
Betriebssystem | Windows 7, 10 Windows Embedded Standard 2009 Windows Embedded 7 Windows Server 2008 R2 Windows Server 2012
Zielplattformen | PC-Architektur (x86, x64)
.NET Framework | 4.5.2
Minimale TwinCAT-Version | TwinCAT 2 (Standalone-Tool, bis Setup-Version 3) TwinCAT 3 (Visual Studio integriert, ab Setup-Version 4)
Minimales TwinCAT-Installationslevel | TwinCAT 2 CP, PLC, NC-PTP (Standalone-Tool, bis Setup-Version 3) TwinCAT 3 XAE, XAR, ADS (Standalone-Tool, bis Setup-Version 3) TwinCAT 3 XAE (Visual Studio integriert, ab Setup-Version 4)
Benötigte TwinCAT-Lizenz | ---
UPC UA Sample Client
OPC UA Sample Client | Beschreibung
Betriebssystem | Windows 7, 10 Windows Embedded 7 Windows Server 2008 R2 Windows Server 2012
Zielplattformen | PC-Architektur (x86, x64)
.NET Framework | 4.6
Minimale TwinCAT-Version | ---
Minimales TwinCAT-Installationslevel | ---
Benötigte TwinCAT-Lizenz | ---


Installation (TC3)

Installation [image] Installation (TC3)
Installation (TC3)
Nachfolgend wird beschrieben, wie die TwinCAT 3 Function TF6100 OPC UA für Windows-basierte Betriebssysteme installiert wird.
➢
Die Setup-Datei der TwinCAT 3 Function wurde von der Beckhoff-Homepage heruntergeladen.
1.
Führen Sie die Setup-Datei als Administrator aus. Wählen Sie dazu im Kontextmenü der Datei den Befehl Als Administrator ausführen.
⇨
Der Installationsdialog öffnet sich.
2.
Akzeptieren Sie die Endbenutzerbedingungen und klicken Sie auf Next.
3.
Geben Sie Ihre Benutzerdaten ein.
4.
Wenn Sie die TwinCAT 3 Function vollständig installieren möchten, wählen Sie Complete als Installationstyp. Wenn Sie die Komponenten der TwinCAT 3 Function separat installieren möchten, wählen Sie Custom.
5.
Wählen Sie Next und anschließend Install, um die Installation zu beginnen.
⇨
Ein Dialog weist Sie darauf hin, dass das TwinCAT-System für die weitere Installation gestoppt werden muss.
6.
Bestätigen Sie den Dialog mit Yes.
7.
Wählen Sie Finish, um das Setup zu beenden.
⇨
Die TwinCAT 3 Function wurde erfolgreich installiert und kann lizenziert werden (siehe Lizenzierung (TC3)).


Installation (TC2)

Installation [image] Installation (TC2)
Installation (TC2)
Nachfolgend wird beschrieben, wie das TwinCAT 2 Supplement TwinCAT OPC UA für Windows-basierte Betriebssysteme installiert wird.
▪
Download der Setup-Datei und Installation
▪
Nach der Installation
Download der Setup-Datei und Installation
Genauso wie viele andere TwinCAT-Ergänzungsprodukte steht OPC UA als 30‑Tage‑Demoversion oder als Vollversion zum Download auf der Beckhoff Homepage www.beckhoff.com zur Verfügung.
➢
Die Setup-Datei des TwinCAT 2 Supplement wurde von der Beckhoff-Homepage heruntergeladen.
1.
Führen Sie die heruntergeladene Setup-Datei TcOpcUaSvr.exe als Administrator aus. Wählen Sie dazu im Kontextmenü der Datei den Befehl Als Administrator ausführen.
⇨
Der Installationsdialog öffnet sich.
2.
Wählen Sie eine Installationssprache.
3.
Klicken Sie auf Weiter und stimmen Sie der Lizenzvereinbarung zu.
Grafik aus Installation Tc2 (i7ud5kc1.png)
4.
Geben Sie Ihre Benutzerinformationen ein. Alle Felder müssen ausgefüllt werden. Wenn Sie eine 30-Tage-Demo installieren möchten, geben Sie bitte „DEMO“ als Lizenzschlüssel ein.
Grafik aus Installation Tc2 (iimv13l2.png)
5.
Klicken Sie auf Installieren, um die Installation zu starten.
Grafik aus Installation Tc2 (i4gasnj.png)
6.
Starten Sie den Computer neu, um die Installation abzuschließen.
Nach der Installation
Die TwinCAT-Ergänzung OPC UA wird automatisch während der Installation konfiguriert und es sind keine weiteren Einstellungen für die Nutzung dieses Produkts erforderlich. Zu den weiteren Schritten gehören gegebenenfalls:
▪
Stellen Sie eine erste Verbindung mit dem installierten UA-Server her und testen Sie dessen Konfiguration mit dem OPC UA Sample Client. (Siehe Sample Client)
▪
Personalisieren Sie das UA-Server-Setup mithilfe des OPC‑UA‑Konfigurators. (Siehe Konfiguration)
▪
Vergewissern Sie sich zudem, dass Ihre Firewall den TCP Port 4840 öffnet, weil der OPC UC Server diesen Port benötigt.


Installation Windows CE (TC3)

Installation [image] Installation Windows CE (TC3)
Installation Windows CE (TC3)
Nachfolgend wird beschrieben, wie die TwinCAT 3 Function TF6100 OPC UA auf einem Beckhoff Embedded-PC mit Windows CE installiert wird.
▪
Download der Setup-Datei und Installation
▪
CAB-Datei auf das Windows-CE-Gerät übertragen
▪
CAB-Datei auf dem Windows-CE-Gerät ausführen
Wenn schon eine ältere TF6100-Version auf dem Windows-CE-Gerät installiert ist, kann diese aktualisiert werden:
▪
Upgrade der Software
Download der Setup-Datei und Installation
Die für Windows CE ausführbare Datei ist Teil des TF6100-OPC-UA-Setups. Dieses wird Ihnen auf der Beckhoff Homepage www.beckhoff.com zur Verfügung gestellt und enthält automatisch alle Versionen für Windows XP, Windows 7 und Windows CE (x86 und ARM).
Laden Sie das Setup herunter und installieren Sie die Function wie es im Abschnitt Installation beschrieben wird.
Nach der Installation enthält der Installationsordner drei Verzeichnisse (pro Hardware‑Plattform ein Verzeichnis)
▪
CE-ARM: ARM-basierte Embedded-PC, die unter Windows CE laufen, z. B. CX8090, CX9020
▪
CE-X86: X86-basierte Embedded-PC, die unter Windows CE laufen, z. B. CX50xx, CX20x0
▪
Win32: Embedded-PC, die unter Windows XP, Windows 7 oder Windows Embedded Standard laufen
Die Verzeichnisse CE-ARM und CE-X86 enthalten die CAB-Dateien der TwinCAT 3 Function für Windows CE in Bezug auf die jeweilige Hardware-Plattform des Windows‑CE‑Gerätes.
Beispiel: Installationsordner „TF6310“
CAB-Datei auf das Windows-CE-Gerät übertragen
Übertragen Sie die entsprechende ausführbare Datei auf das Windows-CE-Gerät.
Für die Übertragung der ausführbaren Datei stehen Ihnen verschiedene Möglichkeiten zur Verfügung:
▪
über Netzwerkfreigaben
▪
über den integrierten FTP-Server
▪
über ActiveSync
▪
über CF/SD-Karten
Weitere Informationen finden Sie im Beckhoff Information System in der Dokumentation „Betriebssysteme“ (Embedded-PC> Betriebssysteme > CE).
CAB-Datei auf dem Windows-CE-Gerät ausführen
Nachdem Sie die CAB-Datei auf das Windows-CE-Gerät übertragen haben, führen Sie die Datei dort mit einem Doppelklick aus. Bestätigen Sie den Installationsdialog mit OK. Starten Sie das Windows-CE-Gerät anschließend neu.
Nach dem Neustart des Gerätes werden die Dateien (Client und Server) automatisch im Hintergrund geladen und sind verfügbar.
Die Software wird in dem folgenden Verzeichnis auf dem Windows-CE-Gerät installiert:
\Hard Disk\TwinCAT\Functions\TF6310-TCP-IP
Upgrade der Software
Wenn auf dem Windows-CE-Gerät bereits eine ältere TF6100-Version installiert ist, führen Sie die folgenden Schritte auf dem Windows-CE-Gerät durch, um ein Upgrade auf eine neue Version durchzuführen:
1.
Öffnen Sie den CE Explorer, indem Sie auf Start > Run klicken und „Explorer“ eingeben.
2.
Navigieren Sie nach \Hard Disk\TwinCAT\Functions\Tf6100-OPC-UA\Server bzw. (in einem zweiten Schritt) \Hard Disk\TwinCAT\Functions\Tf6100-OPC-UA\Client.
3.
Benennen Sie die Datei TcOpcUaServer.exe bzw. TcOpcUaClient.exe um.
4.
Starten Sie das Windows-CE-Gerät neu.
5.
Übertragen Sie die neue CAB-Datei auf das Windows-CE-Gerät.
6.
Führen Sie die CAB-Datei auf dem Windows-CE-Gerät aus und installieren Sie die neue Version.
7.
Löschen Sie die alten (umbenannten) Dateien.
8.
Starten Sie das Windows-CE-Gerät neu.
⇨
Nach dem Neustart ist die neue Version aktiv.


Installation Windows CE (TC2)

Installation [image] Installation Windows CE (TC2)
Installation Windows CE (TC2)
Nachfolgend wird beschrieben, wie das TwinCAT 2 Supplement auf einem Beckhoff Embedded-PC mit Windows CE, z. B. CX1000, CX1020, CX9000, CX9001, CX9010, CX8090, CP62xx, CP69xx, installiert wird.
▪
Download der Setup-Datei und Installation
▪
Setup-Datei auf ein Windows-CE-Gerät übertragen
▪
Setup-Datei auf dem Windows-CE-Gerät ausführen
Installation auf kleinen Embedded-Plattformen (CX9001, CX9010)
Sehr kleine Embedded-Geräte erfordern möglicherweise einige zusätzliche manuelle Schritte, damit die CAB-Datei installiert werden kann. Zu diesen Schritten kann z. B. das Löschen von unnötigen Dateien im Speicher der Geräte gehören, damit ausreichend Platz bereitsteht, um alle Dateien der Anwendung zu installieren.
Download der Setup-Datei und Installation
Genauso wie viele andere TwinCAT-Ergänzungsprodukte steht OPC UA für CE als Download auf dem Beckhoff Homepage zur Verfügung. Damit Sie die Installierungsdateien für Windows CE erhalten können, müssen Sie zunächst die heruntergeladene Setup-Datei auf einem Host-Computer installieren. Dieser kann ein beliebiges Windows-CE-basiertes System sein kann.
1.
Doppelklicken Sie auf die heruntergeladene Datei TcOpcUaSvrCE.exe.
2.
Wählen Sie eine Installationssprache.
3.
Klicken Sie auf Weiter und stimmen Sie der Lizenzvereinbarung zu.
Grafik aus Installation Windows CE Tc2 (irb07pl3.png)
4.
Geben Sie ihre Benutzerinformationen ein. Alle Felder müssen ausgefüllt werden. Beachten Sie, dass OPC UA für CE derzeit nicht als Demo-Version verfügbar ist. Demzufolge benötigen Sie einen gültigen Lizenzschlüssel, um mit der Installierung fortzufahren.
Grafik aus Installation Windows CE Tc2 (ikeeluv2.png)
5.
Wählen Sie als Installationsart Vollständig und klicken Sie auf Weiter
Grafik aus Installation Windows CE Tc2 (ip6f7ll3.png)
6.
Klicken Sie auf Installieren, um die Installation zu starten.
⇨
Nach der Installierung finden Sie die Setup-Dateien für Windows CE im Verzeichnis ...\TwinCAT\CE. Dieses Verzeichnis beinhaltet Setup-Dateien für die folgenden CE-Plattformen:
▪
TwinCAT OPC UA Client CE\I586: OPC UA Client (SPS-Bibliothek) für x86 basierte CPUs (wie CX10xx, CP62xx, C69xx, ...)
▪
TwinCAT OPC UA Client CE\ARMV4I: OPC UA Client (SPS-Bibliothek) für ARM-basierte CPUs (wie CX9001, CX9010, CP6608, ...)
▪
TwinCAT OPC UA Server CE\I586: OPC UA Server für x86-basierte CPUs (wie CX10xx, CP62xx, C69xx, ...)
▪
TwinCAT OPC UA Server CE\ARMV4I: OPC UA Server für ARM-basierte CPUs (wie CX9001, CX9010, CP6608, ...)
Setup-Datei auf das Windows-CE-Gerät übertragen
Übertragen Sie die entsprechende ausführbare Datei auf Ihr Windows-CE-Gerät. Für die Übertragung der Setup-Datei stehen Ihnen verschiedene Möglichkeiten zur Verfügung:
▪
über einen freigegebenen Ordner
▪
über den integrierten FTP-Server
▪
über ActiveSync
▪
über eine CF-Karte
Weitere Informationen finden Sie im Beckhoff Information System in der Dokumentation „Betriebssysteme“ (Embedded‑PC > Betriebssysteme > CE)
Setup-Datei auf dem Windows-CE-Gerät ausführen
Führen Sie die übertragene Setup-Datei TcOpcUaSvrCe.xxxx.CAB auf dem CE-Gerät aus:
1.
Navigieren Sie zu dem Verzeichnis, in das Sie die Setup-Datei übertragen haben.
Grafik aus Installation Windows CE Tc2 (ipb21v32.png)
2.
Doppelklicken Sie auf die CAB-Datei. Wird ein Meldungsdialog eingeblendet, dass dieses Programm nicht mit dem aktuellen Betriebssystem kompatibel ist, vergewissern Sie sich, dass Sie die richtige CAB-Datei (ARM, I586) für Ihren IPC/Embedded-PC verwenden.
3.
Wenn Sie sicher sind, dass die CAB-Datei zum Embedded-PC/IPC passt, bestätigen Sie diesen Meldungsdialog mit Ja.
Grafik aus Installation Windows CE Tc2 (i7nd0cg1.png)
4.
Wählen Sie \Hard Disk\System\ als Zielverzeichnis
Grafik aus Installation Windows CE Tc2 (i51h2g12.png)
5.
Klicken Sie auf OK, um die Installation zu starten.
Grafik aus Installation Windows CE Tc2 (irag07u2.png)
⇨
Nach der Installierung wird die Setup-Datei automatisch gelöscht.
Wenn Sie den OPC UA Server installiert haben, wird diese Komponente nach einem Neustart Ihres Windows-CE-Geräts verfügbar.


Lizenzierung (TC3)

Installation [image] Lizenzierung (TC3)
Lizenzierung (TC3)
Die TwinCAT 3 Function ist als Vollversion oder als 7-Tage-Testversion freischaltbar. Beide Lizenztypen sind über die TwinCAT-3-Entwicklungsumgebung (XAE) aktivierbar.
Nachfolgend wird die Lizenzierung einer TwinCAT 3 Function beschrieben. Die Beschreibung gliedert sich dabei in die folgenden Abschnitte:
▪
Lizenzierung einer 7-Tage Testversion
▪
Lizenzierung einer Vollversion
Weitere Informationen zur TwinCAT‑3‑Lizenzierung finden Sie im Beckhoff Information System in der Dokumentation „Lizenzierung“ (TwinCAT 3 > Lizenzierung).
Lizenzierung einer 7-Tage-Testversion
1.
Starten Sie die TwinCAT-3-Entwicklungsumgebung (XAE).
2.
Öffnen Sie ein bestehendes TwinCAT-3-Projekt oder legen Sie ein neues Projekt an.
3.
Wenn Sie die Lizenz für ein Remote-Gerät aktivieren wollen, stellen Sie das gewünschte Zielsystem ein. Wählen Sie dazu in der Symbolleiste in der Drop-down-Liste Choose Target System das Zielsystem aus.
⇨
Die Lizenzierungseinstellungen beziehen sich immer auf das eingestellte Zielsystem. Mit der Aktivierung des Projekts auf dem Zielsystems werden automatisch auch die zugehörigen TwinCAT-3-Lizenzen auf dieses System kopiert.
4.
Klicken Sie im Solution Explorer im Teilbaum SYSTEM doppelt auf License.
⇨
Der TwinCAT-3-Lizenzmanager öffnet sich.
5.
Öffnen Sie die Registerkarte Manage Licenses. Aktivieren Sie in der Spalte Add License das Auswahlkästchen für die Lizenz, die Sie Ihrem Projekt hinzufügen möchten (z. B. „TF6420: TC3 Database-Server“).
6.
Öffnen Sie die Registerkarte Order Information (Runtime).
⇨
In der tabellarischen Übersicht der Lizenzen wird die zuvor ausgewählte Lizenz mit dem Status „missing“ angezeigt.
7.
Klicken Sie auf 7 Days Trial License..., um die 7-Tage-Testlizenz zu aktivieren.
⇨
Ein Dialog öffnet sich, der Sie auffordert, den im Dialog angezeigten Sicherheitscode einzugeben.
8.
Geben Sie den Code genauso an, wie er angezeigt wird, und bestätigen Sie diesen sowie den nachfolgenden Dialog, der Sie auf die erfolgreiche Aktivierung hinweist.
⇨
In der tabellarischen Übersicht der Lizenzen gibt der Lizenzstatus nun das Ablaufdatum der Lizenz an.
9.
Starten Sie das TwinCAT-System neu.
⇨
Die 7-Tage-Testversion ist freigeschaltet.
Lizenzierung einer Vollversion
1.
Starten Sie die TwinCAT-3-Entwicklungsumgebung (XAE).
2.
Öffnen Sie ein bestehendes TwinCAT-3-Projekt oder legen Sie ein neues Projekt an.
3.
Wenn Sie die Lizenz für ein Remote-Gerät aktivieren wollen, stellen Sie das gewünschte Zielsystem ein. Wählen Sie dazu in der Symbolleiste in der Drop-down-Liste Choose Target System das Zielsystem aus.
⇨
Die Lizenzierungseinstellungen beziehen sich immer auf das eingestellte Zielsystem. Mit der Aktivierung des Projekts auf dem Zielsystems werden automatisch auch die zugehörigen TwinCAT-3-Lizenzen auf dieses System kopiert.
4.
Klicken Sie im Solution Explorer im Teilbaum SYSTEM doppelt auf License.
⇨
Der TwinCAT-3-Lizenzmanager öffnet sich.
5.
Öffnen Sie die Registerkarte Manage Licenses. Aktivieren Sie in der Spalte Add License das Auswahlkästchen für die Lizenz, die Sie Ihrem Projekt hinzufügen möchten (z. B. „TE1300: TC3 Scope View Professional“).
6.
Öffnen Sie die Registerkarte Order Information.
⇨
In der tabellarischen Übersicht der Lizenzen wird die zuvor ausgewählte Lizenz mit dem Status „missing“ angezeigt.

Eine TwinCAT-3-Lizenz wird generell an zwei Kennzahlen gebunden, welche die zu lizenzierende Plattform beschreiben:
System-ID: Identifiziert das Gerät eindeutig
Plattform-Level: Definiert die Performanz des Gerätes
Die zugehörigen Felder System Id und Platform können nicht geändert werden.
7.
Geben Sie die Auftragsnummer (License Id) für die zu aktivierende Lizenz sowie optional eine eigene Bestellnummer (Customer Id) und einen Kommentar für Ihre Zwecke an (Comment). Wenn Ihnen Ihre Beckhoff-Auftragsnummer nicht bekannt ist, wenden Sie sich an Ihren Ansprechpartner aus dem Beckhoff-Vertrieb.
8.
Klicken Sie auf die Schaltfläche Generate File..., um für die aufgeführte fehlende Lizenz eine Lizenzanforderungsdatei (License Request File) zu erzeugen.
⇨
Ein Fenster öffnet sich, in dem Sie festlegen können, wo das License Request File gespeichert werden soll. (Es wird empfohlen, die Voreinstellungen zu übernehmen.)
9.
Wählen Sie einen Speicherort und klicken Sie auf Save.
⇨
Eine Abfrage erscheint, ob Sie das License Request File zur Validierung an den Beckhoff‑Lizenzserver schicken wollen:
▪
Wenn Sie das License Request File verschicken wollen, klicken Sie auf Yes. Voraussetzung ist, dass auf Ihrem Rechner ein Mailprogramm installiert und Ihr Rechner mit dem Internet verbunden ist. Beim Klick auf Yes wird automatisch der Entwurf einer E-Mail generiert, die das License Request File mit allen erforderlichen Informationen erhält.
▪
Wenn auf Ihrem Rechner kein E-Mail-Programm installiert ist oder Ihr Rechner nicht mit dem Internet verbunden ist, klicken Sie auf No. Kopieren Sie dann das License Request File auf einen Datenträger (z. B. USB-Stick) und schicken Sie die Datei von einem Rechner mit Internet-Zugriff und E-Mail-Programm per Email an den Beckhoff-Lizenzserver (tclicense@beckhoff.com).
10.
Schicken Sie das License Request File ab.
⇨
Das License Request File wird an den Beckhoff-Lizenzserver geschickt. Der Server gleicht nach Erhalt der Email Ihre Lizenzanfrage mit der angegebenen Auftragsnummer ab und schickt Ihnen via E-Mail eine Lizenzdatei (License Response File) zurück. Der Beckhoff-Lizenzserver schickt das License Response File an die gleiche Email-Adresse, mit der Sie das License Request File versendet haben. Das License Response File unterscheidet sich vom License Request File nur durch eine Signatur, die die Gültigkeit des Inhalts der Lizenzdatei dokumentiert. Den Inhalt des License Response Files können Sie sich mit einem für XML-Dateien geeigneten Editor (z. B. „XML Notepad“) ansehen. Der Inhalt des License Response Files darf nicht verändert werden, da die Lizenzdatei sonst ungültig wird.
11.
Speichern Sie das License Response File.
12.
Um die Lizenzdatei zu importieren und die Lizenz zu aktivieren, klicken Sie in der Registerkarte Order Information auf License Response File...
13.
Wählen Sie in Ihrem Dateiverzeichnis das License Response File aus und bestätigen Sie den Dialog.
⇨
Das License Response File wird importiert und die enthaltene Lizenz wird aktiviert.
Bereits vorhandene Demo-Lizenzen werden entfernt.
14.
Starten Sie das TwinCAT-System neu.
⇨
Nach dem Neustart von TwinCAT ist die Lizenz freigeschaltet. Das Produkt kann als Vollversion genutzt werden. Während des Neustarts von TwinCAT wird die Lizenzdatei automatisch auf das jeweilige Zielsystem in das Verzeichnis ...\TwinCAT\3.1\Target\License kopiert.


Lizenzierung (TC2)

TS6100 | TwinCAT OPC UA
Installation [image] Lizenzierung (TC2)
Lizenzierung (TC2)
Die Lizenzierung der TwinCAT OPC UA für TwinCAT 2 erfolgt im Rahmen der Installation über die Eingabe eines Lizenzschlüssels.


Technische Einführung

Technische Einführung
Technische Einführung
Weiterführende Informationen
•
Server
•
Client I/O
•
Client PLCopen
•
Gateway
•
Sample Client


Server

Technische Einführung [image] Server
Server
Weiterführende Informationen
•
Übersicht
•
Schnelleinstieg
•
SPS
•
C++
•
I/O
•
Matlab/Simulink
•
Dateiübertragung
•
Sicherheit
•
Symbol-Caching
•
Verschiedenes


Übersicht

Technische Einführung [image] Server [image] Übersicht
Übersicht
Der TwinCAT OPC UA Server bietet eine standardisierte Kommunikationsschnittstelle für den Zugriff auf Symbolwerte aus der TwinCAT-SPS- und C++‑Laufzeit bzw. I/O-Task.
Dieser Teil der Dokumentation beschreibt die Basiskonfiguration des TwinCAT OPC UA Servers.
Themenbereiche:
▪
OPC UA Configurator: Grafische Oberfläche zur Konfiguration des OPC UA Servers
▪
OPC UA DA (Data Access): Zugriff auf TwinCAT-SPS- und IO-Task-Werte via OPC UA
▪
OPC UA HA (Historical Access): Speicherung von historischen Daten, z. B. im lokalen RAM, in einer Datei oder einer Datenbank
▪
OPC UA AC (Alarms and Conditions): Condition-Monitoring-Funktionalitäten für SPS-Variablen
▪
OPC UA Security: Sicherheitsmechanismen, die in OPC UA integriert sind
Siehe auch: Schnelleinstieg
Erweiterte Konfiguration
Je nach Art der Betriebsumgebung sind gegebenenfalls zusätzliche Konfigurationsparameter erforderlich.
Erweiterte Themenbereiche:
▪
Konfigurationsdatei: Beschreibt die Konfigurationsdatei ServerConfig.xml des OPC UA Servers. Diese Datei sollte üblicherweise über den OPC-UA-Konfigurator editiert werden (siehe Themenbereiche oben).
▪
Konfiguration von SPS-Variablen: Bietet eine Übersicht über alle konfigurierbaren Optionen (über SPS-Kommentare) an einer SPS-Variablen.
▪
Weitere ADS-Geräte: Beschreibt, wie weitere TwinCAT-Geräte in den Namensraum des OPC UA Servers integriert werden können.
▪
Mehrere UA Server: Beschreibt, wie mehrere OPC-UA-Server-Instanzen auf einem Gerät starten können.
▪
UA über NAT: Beschreibt, wie eine OPC-UA-Kommunikation über ein NAT-Gerät hergestellt werden kann, z. B. eine Firewall oder einen Router.
▪
Ändern der Handhabung von Arrays im OPC‑UA‑Namensraum: Beschreibt zwei Darstellungsoptionen von SPS-Arrays im OPC-UA-Namensraum.


Schnelleinstieg

Technische Einführung [image] Server [image] Schnelleinstieg
Schnelleinstieg
Dieser Schnelleinstieg setzt voraus, dass der OPC UA Server und die SPS-Laufzeit auf demselben System installiert sind.
Nach der erfolgreichen Installation und Lizenzierung führen Sie die folgenden Schritte aus, um eine erste Verbindung zu einer SPS-Laufzeit über den OPC UA Server aufzubauen:
▪
Schritt 1: SPS‑Variablen für den OPC-UA-Zugriff konfigurieren
▪
Schritt 2: OPC‑UA‑Namensraum konfigurieren
▪
Schritt 3: Verbindung zum OPC UA Server herstellen
Schritt 1: SPS-Variablen für den OPC-UA‑Zugriff konfigurieren
Öffnen Sie ein bestehendes SPS-Projekt und fügen Sie den folgenden Kommentar vor den ausgewählten Variablen ein.
TwinCAT 3 (mit TMC-Import):
{attribute 'OPC.UA.DA' := '1'}
bVariable : BOOL;
TwinCAT 2 (mit TPY-Import):
bVariable : BOOL; (*~ (OPC:1:some description) *)
Schritt 2: OPC-UA-Namensraum konfigurieren
Der OPC UA Server stellt standardmäßig eine Verbindung mit der ersten SPS-Laufzeit auf dem lokalen System her (lokal = das gleiche System, auf dem auch der OPC UA Server installiert ist) und verwendet deren entsprechende Symboldatei (TMC-Datei) für die Konfiguration des OPC‑UA‑Namensraums.
Damit die Symboldatei automatisch an die SPS-Laufzeit übergeben wird, aktivieren Sie den Download der Symboldatei in den Einstellungen des SPS-Projekts.
Bei jeder Aktivierung des SPS-Projekts wird die Symboldatei automatisch in das Verzeichnis C:\TwinCAT\3.x\Boot\Plc\ kopiert und dort nach dem entsprechenden ADS-Port des SPS-Projekts benannt, z. B. „Port_851.tmc“ für die erste SPS-Laufzeit. Die Standardkonfiguration des OPC UA Servers liest diese Symboldatei automatisch beim Start.
Lizenz
Prüfen Sie, ob eine Lizenz vorhanden ist. In TwinCAT 3 können Sie eine TF6100-Lizenz in der TwinCAT-Lizenzverwaltung eintragen (siehe Lizenzierung (TC3)).
Aktivieren Sie die Konfiguration und starten Sie TwinCAT neu. Loggen Sie sich anschließend in die SPS-Laufzeit ein und starten Sie das SPS-Programm.
Schritt 3: Verbindung zum OPC UA Server herstellen
Um eine Verbindung von einem OPC UA Client herzustellen, muss der Client eine Verbindung mit der URL des OPC UA Servers herstellen. Diese URL wird folgendermaßen beschrieben:
opc.xxx://<ip or name>:port
▪
opc = vordefiniert
▪
xxx = Transport an OPC UA Server, z. B. „tcp“
▪
port = Portnummer von OPC UA Server, z. B. 4840 (standardmäßig)
Standard-Port 4840
Beachten Sie, dass der Standard-Port 4840 eventuell von anderen OPC UA Servern verwendet wird, z. B. dem Local Discovery Server (LDS) von der OPC Foundation, die von manchen Anbietern mit OPC‑UA‑Softwarepaketen eingesetzt wird.
Beispiele:
▪
opc.tcp://CX_0215AF:4840
▪
opc.tcp://172.16.2.80:4840
Sie finden den mitgelieferten UA Sample Client im Windows-Startmenü oder im Installationsverzeichnis des Produkts, z. B. C:\TwinCAT\Functions\TF6100-OPC-UA\Win32\SampleClient\.
Starten Sie den UA Sample Client (bei Windows-Systemen mit aktiviertem UAC, z. B. Windows 7 mit dem Befehl Run As Administrator) und stellen Sie eine Verbindung mit der URL des OPC UA Servers her, z. B. opc.tcp://localhost:4840, indem Sie auf Endpunkte erhalten und anschließendem auf Verbinden klicken.
Nach erfolgreicher Herstellung der Verbindung finden Sie die SPS-Laufzeit „PLC1“ mit den veröffentlichten Variablen (siehe Schritt 1) im UA-Namensraum unterhalb des Knotens „Objects“.


SPS

Technische Einführung [image] Server [image] SPS
SPS
Weiterführende Informationen
•
Zugriff auf SPS-Laufzeit
•
Historical Access
•
Alarms and Conditions
•
Methodenaufruf
•
AnalogItemTypes
•
Typsystem
•
StructuredTypes
•
Verwendung von Arrays
•
Liste der Attribute und Kommentare
•
StatusCode


Zugriff auf SPS-Laufzeit

Technische Einführung [image] Server [image] SPS [image] Zugriff auf SPS-Laufzeit
Zugriff auf SPS-Laufzeit
In diesem Abschnitt wird beschrieben, wie Sie den Namensraum des OPC UA Servers konfigurieren. Der UA-Namensraum beschreibt die Struktur, in die die SPS-Variablen abgebildet werden. Damit eine SPS-Variable über den UA‑Namensraum erreichbar ist, muss sie im SPS-Programm freigegeben werden.
Beachten Sie, dass sich der OPC UA Server standardmäßig immer mit dem ersten lokalen SPS-Laufzeitsystem verbindet, eine Konfiguration ist also in den meisten Fällen nicht erforderlich (siehe auch Schnelleinstieg). Nur in Ausnahmefällen muss eine separate Konfiguration erfolgen, z. B. wenn im UA-Namensraum weitere Laufzeiten angezeigt werden sollen oder wenn auf die SPS eines BC-Geräts zugegriffen werden muss.
Dieser Abschnitt beinhaltet folgende Themen:
▪
Allgemeine Informationen
▪
Schritt 1: SPS-Variablen auswählen, die über OPC UA öffentlich zugänglich werden sollen
▪
Schritt 2: Symbolbeschreibung herunterladen und im SPS-Projekt aktivieren
▪
[Optional] Schritt 3: Datenzugriffgerät in OPC UA Server konfigurieren
▪
Explizites Ausblenden von Variablen
Allgemeine Informationen
Für die Konfiguration des OPC-UA-Namensraums und den Zugriff auf SPS-Variablen stehen mehrere Parameter zur Verfügung, die je nachdem, wie die SPS-Laufzeit angezeigt wird und wie die Kommunikation stattfindet, unterschiedliche Auswirkungen haben.
Sie können diese Parameter mithilfe des OPC-UA-Konfigurators oder direkt in der Konfigurationsdatei ServerConfig.xml festlegen.
Die folgende Tabelle gibt einen Überblick über alle Parameter, die beim Zugriff auf eine SPS-Laufzeit von Bedeutung sind:
Parameter | Beschreibung | Mögliche Werte
ADS Port | Definiert den ADS-Port, unter dem die SPS-Laufzeit zugänglich ist. Der ADS-Port kann in den Eigenschaften des SPS-Projekts gelesen werden. | 800 (BC Controller) 801 (TwinCAT 2) 811 (TwinCAT 2) … 851 (TwinCAT 3 - standardmäßig) 852 (TwinCAT 3) …
AutoCfg | Definiert zunächst den Typ der für die Kommunikation verwendeten Ziel-Laufzeit, z. B. SPS, C++, I/O. Anschließend kann eine weitergehende Unterscheidung innerhalb dieser Kategorien stattfinden. Jede AutoCfg-Option steht sowohl als ungefilterte als auch gefilterte Option zur Verfügung. Gefiltert bedeutet, dass der Nutzer bestimmen kann, welche SPS-Symbole über OPC UA via SPS-Kommentaren veröffentlicht werden sollen (siehe unten). Bei Verwendung einer ungefilterten Option wird jedes SPS-Symbol an OPC UA veröffentlicht. | 7 TwinCAT 2 (TPY) 8 TwinCAT 2 (TPY) gefiltert 4040 TwinCAT 3 (TMC) 4041 TwinCAT 3 (TMC) gefiltert
AutoCfgSymFile | Symboldatei der jeweiligen SPS-Laufzeit. Standardmäßig wird die automatisch erzeugte Symboldatei der ersten SPS-Laufzeit des lokalen Systems importiert. | Pfad zur Symboldatei. Zeigt standardmäßig auf die Symboldatei (TMC) der ersten lokalen SPS-Laufzeit.
IoMode | Definiert die Methode für den Zugriff auf Symbole. Dies ist besonders wichtig für den Zugriff auf BC-Geräte. | 1 (Zugriff über Handle - standardmäßig) 3 (Zugriff auf BC Controller)
ArraySubItemLegacySupport | Unterelemente eines Array werden standardmäßig nicht als separate Knoten im UA-Namensraum abgebildet. Stattdessen wird lediglich das Array als ein einzelnes Element abgebildet. Nichtsdestotrotz können UA Clients über deren sogenannten „IndexRange“ auf Unterelemente zugreifen. (Einige ältere OPC UA Clients unterstützen diese Möglichkeit noch nicht.) Das Flag wurde eingeführt, damit der Zugriff dennoch für diese Clients möglich wird. Es sorgt dafür, dass jede Array-Position als separater Knoten im UA-Namensraum angezeigt wird. Dies führt zu einem höheren Speicherbedarf des OPC UA Servers. | 0 (deaktiviert - standardmäßig) 1 (aktiviert)
Disabled | Deaktiviert die SPS-Laufzeit im UA‑Namensraum, woraufhin der entsprechende Knoten nicht angezeigt wird. Es wird empfohlen, diesen Parameter zu aktivieren, wenn bestimmte SPS-Laufzeiten zum Zeitpunkt der Projektplanung noch nicht verfügbar sind, weil z. B. die entsprechenden Geräte noch nicht ans Netzwerk angeschlossen sind. | 0 (deaktiviert - standardmäßig) 1 (aktiviert)
Im nachfolgenden Abschnitt wird anhand eines Beispiels gezeigt, wie Sie die Variablen aus einem SPS‑Programm in den UA‑Namensraum importieren können. Hierbei wird vorausgesetzt, dass sich der OPC UA Server in seiner Standardkonfiguration (Lieferzustand nach Installierung) und die SPS‑Laufzeit auf dem gleichen Computer befinden.
AutoCfg-Optionen
Die in diesem Artikel enthaltenen Informationen, einschließlich die folgenden SPS-Kommentare/Pragmas, basieren auf TwinCAT 3 und müssen demzufolge mit den AutoCfg-Optionen „4041 TwinCAT 3 (TMC) gefiltert“ (Standardkonfiguration) verwendet werden.
Beachten Sie, dass die AutoCfg-Optionen für TwinCAT 2 ein anderes SPS‑Kommentarformat verwenden (*~ (OPC:1:description) *), das nicht mehr in TwinCAT 3 verwendet wird, aber weiterhin aus Gründen der Kompatibilität unter Verwendung der AutoCfg‑Option „8“ verfügbar ist.
Schritt 1: SPS-Variablen auswählen, die über OPC UA öffentlich zugänglich werden sollen
Der OPC UA Server stellt automatisch eine Verbindung zur ersten SPS-Laufzeit auf dem lokalen System her. Die im SPS-Programm (TwinCAT-SPS-Steuerung) für OPC UA gekennzeichneten SPS-Symbole werden bereitgestellt. Sie kennzeichnen die SPS-Symbole über einen Kommentar an der entsprechenden Stelle (Instanz, Struktur, Variable) im SPS-Programmcode (siehe nachfolgende Beispiele).
Beispiel 1
In diesem Beispiel sind die SPS-Variablen bMemFlag1, bMemFlag2, bMemAlarm2 und iReadOnly über OPC UA freigegeben. Die SPS-Variable bMemAlarm1 soll nicht über den OPC UA Server zugänglich sein. Das SPS-Programm in PLC-Control sieht dann abhängig von der von Ihnen verwendeten TwinCAT‑Version wie folgt aus:
TwinCAT 3 (mit TMC-Import):
{attribute 'OPC.UA.DA' := '1'}
bMemFlag1 : BOOL;

{attribute 'OPC.UA.DA' := '1'}
bMemFlag2 : BOOL;

bMemAlarm1 : BOOL;

{attribute 'OPC.UA.DA' := '1'}
bMemAlarm2 : BOOL;

{attribute 'OPC.UA.DA' := '1'}
{attribute 'OPC.UA.DA.Access' := '1'}
iReadOnly : INT;
TwinCAT 2 (mit TPY-Import):
bMemFlag1 : BOOL; (*~ (OPC:1:some description) *)

bMemFlag2 : BOOL; (*~ (OPC:1:some description) *)

bMemAlarm1 : BOOL;

bMemAlarm2 : BOOL; (*~ (OPC:1:some description) *)

iReadOnly : INT; (*~ (OPC:1:some description)
(OPC_PROP[0005]:1:read-only flag) *)
Die TPY-Formatierung kann auch in TwinCAT‑3‑SPS‑Projekten für Migrationszwecke verwendet werden, wenn z. B. ein TwinCAT-2-Projekt bequem in ein TwinCAT‑3‑Projekt konvertiert werden soll.
Wegen des zusätzlichen Kommentars OPC.UA.DA.Access wird die Zugriffsebene für die Variable iReadOnly auf „ReadOnly“ gesetzt. Die verschiedenen Möglichkeiten finden Sie in der vollständigen Liste der SPS-Kommentare (siehe Liste der Attribute und Kommentare).
Um einer Variablen im UA-Namensraum eine Beschreibung zu geben, fügen Sie hinter der entsprechenden Variablen einen einfachen SPS-Kommentar ein, z. B.:
TwinCAT 3 (mit TMC-Import):
{attribute 'OPC.UA.DA' := '1'}
bMemFlag1 : BOOL; (* Description for variable bMemFlag1 *)
TwinCAT 2 (mit TPY-Import): Funktion nicht verfügbar
Der Kommentar wird automatisch zum Beschreibungsattribut des Knotens im UA-Namensraum.
Beispiel 2:
In diesem Beispiel sollen die beiden Instanzen fbTest1 und fbTest2 des Funktionsbausteins FB_BLOCK1 über OPC UA verfügbar sein. Wenn eine ganze Instanz freigegeben wird, sind über OPC UA auch alle ihre Symbole verfügbar. Das SPS-Programm sieht wie folgt aus:
TwinCAT 3 (mit TMC-Import):
PROGRAM MAIN
VAR
{attribute 'OPC.UA.DA' := '1'}
fbTest1 : FB_BLOCK1;
fbTest2 : FB_BLOCK1;
END_VAR
FUNCTION_BLOCK FB_BLOCK1
VAR_INPUT
{attribute 'OPC.UA.DA' := '1'}
ni1 : INT;
ni2 : INT;
END_VAR
VAR_OUTPUT
{attribute 'OPC.UA.DA' := '1'}
no1 : INT;
no2 : INT;
END_VAR
VAR
{attribute 'OPC.UA.DA' := '1'}
nx1 : INT;
nx2 : INT;
END_VAR
TwinCAT 2 (mit TPY-Import):
PROGRAM MAIN
VAR
fbTest1 : FB_BLOCK1; (*~ (OPC:1:some description) *)
fbTest2 : FB_BLOCK1;
END_VAR
FUNCTION_BLOCK FB_BLOCK1
VAR_INPUT
ni1 : INT; (*~ (OPC:1:some description) *)
ni2 : INT;
END_VAR
VAR_OUTPUT
no1 : INT; (*~ (OPC:1:some description) *)
no2 : INT;
END_VAR
VAR
nx1 : INT; (*~ (OPC:1:some description) *)
nx2 : INT;
END_VAR
Die Instanz fbTest1 wird für OPC UA freigegeben, wodurch alle enthaltenen Symbole automatisch auch für OPC UA freigegeben werden, sprich fbTest.ni1, fbTest.ni2, usw. Die Instanz fbTest2 ist nicht für OPC UA gekennzeichnet, allerdings wurden die drei enthaltenen Variablen ni1, no1 und nx1 im Funktionsbaustein gekennzeichnet. Diese sind demzufolge in allen Instanzen über OPC UA verfügbar.
Schritt 2: Symbolbeschreibung herunterladen und im SPS-Projekt aktivieren
Die sogenannte Symboldatei enthält Informationen über alle in einem SPS-Projekt verfügbaren SPS‑Variablen. Der OPC UA Server benötigt diese Informationen für den Aufbau seines Namensraums. Die aktuellen Symbolinformationen werden standardmäßig automatisch in eine Symboldatei heruntergeladen. Diese befindet sich im Projektordner des entsprechenden TwinCAT‑Projekts. Damit die Symboldatei in die Ziel-Laufzeit übertragen wird, aktivieren Sie den Download der Symboldatei in den Einstellungen des SPS‑Projekts.
TwinCAT 3:
TwinCAT 2:
Grafik aus Step 2_ TwinCAT PLC Control_ Download symbol description to target PLC runtime (iijv2oe2.png)
Bei der Erstellung eines Bootprojekts wird die Symboldatei automatisch in das Bootverzeichnis der SPS-Laufzeit kopiert. Der Dateiname gibt Auskunft über den entsprechenden ADS-Port der SPS-Laufzeit.
Wenn sich OPC UA Server und SPS-Laufzeit auf dem gleichen System befinden, müssen Sie nichts anderes tun, als den OPC UA Server neu zu starten. Der OPC UA Server wird automatisch so konfiguriert, dass er die Symboldatei aus dem Bootverzeichnis lädt und seinen Namensraum auf der Grundlage der in dieser Datei enthaltenen Symbolinformationen generiert. Wenn eine andere Symboldatei verwendet werden soll, können Sie diese entweder im OPC‑UA‑Konfigurator oder direkt in der Datei ServerConfig.xml konfigurieren.
[Optional] Schritt 3: Datenzugriffgerät in OPC UA Server konfigurieren
Standardmäßig verbindet sich OPC UA Server mit der ersten SPS-Laufzeit auf dem lokalen System. Wenn Sie mehr als eine SPS-Laufzeit im UA-Namensraum veröffentlichen möchten, müssen Sie zusätzliche Datenzugriffsgeräte im OPC‑UA‑Konfigurator konfigurieren. Das kann bei folgenden Szenarien erforderlich sein:
▪
Sie haben eine andere (zweite oder dritte) SPS-Laufzeit, von der Sie Symbolinformationen an OPC UA veröffentlichen möchten.
▪
Sie haben einen anderen Industrie-PC oder Embedded-PC, dessen SPS-Laufzeit und entsprechenden Symbolinformationen Sie OPC UA öffentlich zugänglich machen möchten.
Um zusätzliche Geräte für den Datenzugriff zu konfigurieren, öffnen Sie den OPC‑UA‑Konfigurator und fügen Sie neue Datenzugriffsgeräte hinzu.
Konfigurieren Sie alle weiteren notwendigen Parameter wie im Abschnitt Allgemeine Information beschrieben. Wenn Sie einen remote Industrie-PC oder Embedded-PC konfigurieren, müssen Sie die richtigen Parameter für AdsNetId, AdsPort eingeben und die entsprechende Symboldatei des SPS-Programms auf diesem PC bereitstellen.
Explizites Ausblenden von Symbolen
Neben den regulären SPS-Attributen zum Aktivieren eines SPS-Symbols, z. B. Variablen, können Sie SPS-Symbole auch explizit von einer Veröffentlichung im OPC-UA-Namensraum ausschließen. Dafür kann es mehrere Gründe geben:
▪
Sie möchten eine Datenstruktur veröffentlichen, aber nicht alle ihre Unterelemente (Beispiel 1).
▪
Sie haben eine Datenstruktur bei der Definition aktiviert und möchten z. B. eine einzelne Instanz dieser Datenstruktur ausblenden (Beispiel 2).
▪
Sie wollen das Hochfahren des OPC UA Servers beschleunigen (Beispiel 3).
Beispiel 1:
{attribute 'OPC.UA.DA' := '1'}
TYPE ST_TEST :
STRUCT
a : INT;
{attribute 'OPC.UA.DA' := '0'}
b : DINT;
END_STRUCT
END_TYPE

PROGRAM MAIN
VAR
instance1 : ST_TEST;
instance2 : ST_TEST;
END_VAR
In diesem Fall wird das SPS-Attribut zur Strukturdefinition hinzugefügt, wodurch jede Instanz dieser Struktur auf dem OPC UA Server verfügbar ist. Das Unterelement b (und all seine Unterelemente, falls b eine weitere Datenstruktur ist) wird (werden) von der Veröffentlichung auf dem OPC UA Server ausgeschlossen.
Beispiel 2:
{attribute 'OPC.UA.DA' := '1'}
TYPE ST_TEST :
STRUCT
a : INT;
b : DINT;
END_STRUCT
END_TYPE

PROGRAM MAIN
VAR
instance1 : ST_TEST;
{attribute 'OPC.UA.DA' := '0'}
instance2 : ST_TEST;
END_VAR
Obwohl das SPS-Attribut zur Strukturdefinition hinzugefügt wird, wodurch jede Instanz dieser Struktur auf dem OPC UA Server verfügbar ist, erhält instance2 das SPS-Attribut zum Deaktivieren dieser Vererbung. Dadurch ist nur instance1 im UA-Namensraum verfügbar, instance2 nicht.
Beispiel 3:
Während des Startvorgangs liest derOPC UA Server die SPS-Symboldateien zum Aufbau seines Namensraums ein. Dafür werden alle gefundenen Datenstrukturen vollständig ausgelesen, um alle Typdefinitionen zu finden und einzubinden. Wird ein SPS-Attribut OPC.UA.DA:=0 entdeckt, stoppt die Analyse aller nachfolgenden Unterelemente, wodurch das Hochfahren je nach Größe der Datenstrukturen erheblich beschleunigt werden kann.


Historical Access

Technische Einführung [image] Server [image] SPS [image] Historical Access
Historical Access
In diesem Abschnitt werden die notwendigen Schritte zur Konfiguration der Variablen im Namensraum des OPC UA Servers für Historical Access (HA) beschrieben.
Historical Access ist eine Funktion von OPC UA, bei der die Variablenwerte entweder dauerhaft auf einem Datenträger (Datei oder Datenbank) oder in der Geräte-RAM gespeichert werden, damit sie später vom Client abgerufen werden können. Die Art und Weise wie der OPC UA Server die Variablenwerte liest und speichert, kann konfiguriert werden.
Weiterführende Informationen
•
Setup-Version 3.x.x
•
Setup-Version 4.x.x
•
Historische Daten anzeigen


Setup-Version 3.x.x

Technische Einführung [image] Server [image] SPS [image] Historical Access [image] Setup-Version 3.x.x
Setup-Version 3.x.x
Allgemeines
Führen Sie die folgenden Schritte einmalig aus, um einen Werteverlauf von SPS‑Variablen über OPC UA Historical Access zu aktivieren:
▪
Historical Access auf dem UA Server aktivieren
▪
Historical Access im TwinCAT‑SPS‑Programm aktivieren
▪
Historical Access im TwinCAT‑C++‑Modul aktivieren
Wie Sie über Historical Access gespeicherte Variablenwerte mithilfe der UA‑Expert‑Software abrufen und in einem OPC UA Client anzeigen können, wird im Abschnitt Historische Daten anzeigen beschrieben.
Voraussetzungen
Es gelten die folgenden Voraussetzungen zur Nutzung von Historical Access:
▪
Das Laufzeitsystem, dessen Symbole für Historical Access gespeichert werden sollen, muss als Data Access konfiguriert sein.
▪
Um eine SQL-Compact-Datenbank als Speichermedium nutzen zu können, muss auf dem Rechner, auf dem der OPC UA Server läuft, SQL Compact Runtime 3.5 SP2 installiert sein.
▪
Zur Verwendung einer SQL-Server-Datenbank muss mindestens OPC-UA-Version 2.0 installiert sein.
▪
SQL-Compact-Datenbanken werden auch unter Windows CE unterstützt.
▪
SQL-Server-Datenbanken werden unter Windows CE nicht unterstützt.
Historical Access auf dem UA Server aktivieren
Für die Speicherung von Werteverläufen können verschiedene Speichermedien verwendet werden. Diese müssen einmal im OPC UA Server aktiviert werden. Die dazu notwendigen Einstellungen können Sie mithilfe des OPC‑UA‑Konfigurators oder in der Datei ServerConfig.xml vornehmen. Nachdem Sie ein oder mehrere Speichermedien auf dem OPC UA Server aktiviert haben, wählt das SPS-Programm das Speichermedium aus, das für jedes Symbol zu verwenden ist.
Derzeit werden die folgenden vier Speichermedien unterstützt:
▪
Hauptspeicher: Speichert die Symbolwerte in der RAM des Geräts, auf dem der OPC UA Server läuft.
▪
Datei: Speichert die Werte in einer Datei mit angegebenem Pfad.
▪
SQL Compact Database: Speichert die Werte in einer SQL Compact Database mit angegebenem Pfad. In diesem Fall muss die SQL Compact Runtime 3.5 SP2 als entsprechende Datenbankversion auf dem OPC UA Server installiert sein.
▪
SQL Server Database: Speichert die Werte in einer SQL Server Database, die mit den Parametern Servername, Databasename, Username und Password spezifiziert wird.
Konfiguration mithilfe des OPC‑UA‑Konfigurators:
Konfiguration direkt über die Datei ServerConfig.xml:
Fügen Sie die unten gezeigten XML-Tags in der Datei ServerConfig.xml zwischen <OpcServerConfig><UaServerConfig> und </UaServerConfig></OpcServerConfig> ein.
<HaModes>
<HaMode Type="RAM"/>
<HaMode Type="File" DataStore="C:\Temp\"/>
<HaMode Type="SQLServerCompact" DbName="C:\Temp\TcOpcUaServer.sdf"/>
<HaMode Type=”SQLServer” Servername=”SERVERNAME\SQLEXPRESS” DbName=”TcOpcUaServer” User=”sa” Pass=”123”/>
</HaModes>
Die für den jeweiligen Modus notwendigen Parameter sind:
Modus | Erforderliche Parameter
Speicher | Speichert die Werte in der RAM des Geräts, auf dem der OPC UA Server läuft. Es sind keine weiteren Parameter erforderlich. Nach einem Neustart des Geräts sind die gespeicherten Werte nicht mehr verfügbar. Das Speichermedium ist demzufolge kein dauerhaftes.
Datei | Speichert die Werte in mehreren Dateien, deren Speicherort mit dem Parameter DataStore festgelegt wird. Jedem für dieses Speichermedium konfigurierten Symbol (siehe Schritt 2) wird dessen eigene Datei in diesem Verzeichnis zugeordnet. Darüber hinaus besteht eine Sicherungskopie der Datei für jedes Symbol, die dann erzeugt wird, sobald die Pufferlänge (siehe Schritt 2) erreicht ist. Der Inhalt der Datendatei wird dann als Sicherungskopie gespeichert und es wird eine neue Datei erzeugt.
SQL Server Compact | Speichert die Werte in eine SQL Compact Database, dessen Speicherort mit dem Parameter DbName festgelegt wird. Es gelten die oben aufgeführten Anforderungen.
SQL Server | Speichert die Werte in einer SQL Server Database, die mit den Parametern Servername, DbName, User und Pass spezifiziert wird.
Historical Access im TwinCAT‑SPS‑Programm aktivieren
Wenn eine SPS-Laufzeit als ein Datenzugriffsgerät konfiguriert ist, dann werden die SPS-Variablen, die hierfür im SPS-Programm mithilfe von Kommentaren aktiviert werden, automatisch durch den OPC UA Server via OPC UA verfügbar gemacht.
Auf die gleiche Art und Weise, wie Sie Variablen für den Zugriff via OPC UA freigegeben können, können Sie einzelne Variablen für Historical Access freigegeben oder sperren. Ergänzen Sie dazu im SPS-Programmcode einen entsprechenden Kommentar auf der rechten Seite eines Symbols. Die folgenden Parameter können spezifiziert werden:
TwinCAT 3 (mit TMC-Import):
Parameter | Kommentar | Beschreibung
Aktivieren | {attribute 'OPC.UA.DA' := '1'} | Aktiviert das Symbol für Datenzugriff. Dies ist erforderlich, um das Symbol auch für Historical Access zur Verfügung zu stellen.
Für HA aktivieren | {attribute 'OPC.UA.HA' := '1'} | Aktiviert das Symbol für Historical Access.
Speichermedium | {attribute 'OPC.UA.HA.Storage' := '1'} | Legt das für die Speicherung der Symbolwerte zu verwendende Speichermedium fest (1 = RAM, 2 = Datei, 3 = SQL Compact Database, 4 = SQL Server Database).
Aufzeichnungsrate | {attribute 'OPC.UA.HA.Sampling' := '50'} | Definiert die Rate, mit der die Variablenwerte aus der Steuerung zu lesen und auf dem entsprechenden Speichermedium zu speichern sind. Der OPC UA Server verwendet vordefinierte feste Aufzeichnungsraten, die hier verwendet werden können. Die Aufzeichnungsraten können Sie ggf. in der ServerConfig-Datei erweitern. Allerdings ist dies normalerweise nicht erforderlich, und es wird auch davon abgeraten, diese Einstellungen vorzunehmen.
Pufferlänge | {attribute 'OPC.UA.HA.Buffer' := '10000'} | Legt die Anzahl Elemente fest, die der Puffer aufnehmen soll.
TwinCAT 2 (mit TPY-Import):
Parameter | Kommentar | Beschreibung
Aktivieren | (*~ (OPC:1:some description) *) | Aktiviert das Symbol für Datenzugriff. Dies ist erforderlich, um das Symbol auch für Historical Access zur Verfügung zu stellen.
Speichermedium | (*~ (OPC_UA_PROP[5000]:1:RAM) *) | Legt das für die Speicherung der Symbolwerte zu verwendende Speichermedium fest (1 = RAM, 2 = Datei, 3 = SQL Compact Database, 4 = SQL Server Database).
Aufzeichnungsrate | (*~ (OPC_UA_PROP[5000][1]:50:SamplingRate) *) | Definiert die Rate, mit der die Variablenwerte aus der Steuerung zu lesen und auf dem entsprechenden Speichermedium zu speichern sind. Der OPC UA Server verwendet vordefinierte feste Aufzeichnungsraten, die hier verwendet werden können. Die Aufzeichnungsraten können Sie ggf. in ServerConfig-Datei erweitern. Allerdings ist dies normalerweise nicht erforderlich, und es wird auch davon abgeraten, diese Einstellungen vorzunehmen.
Pufferlänge | (*~ (OPC_UA_PROP[5000][2]:5000:Buffer) *) | Legt die Anzahl Elemente fest, die der Puffer aufnehmen soll.
Der folgende Auszug eines SPS-Programms beschreibt die Verwendung der oben aufgeführten Parameter unter Verwendung von vier SPS-Variablen:
TwinCAT 3 (mit TMC-Import):
{attribute 'OPC.UA.DA' := '1'}
{attribute 'OPC.UA.HA' := '1'}
{attribute 'OPC.UA.HA.Storage' := '1'}
{attribute 'OPC.UA.HA.Sampling' := '5'}
{attribute 'OPC.UA.HA.Buffer' := '1000'}
_HistoryMem : UINT;

{attribute 'OPC.UA.DA' := '1'}
{attribute 'OPC.UA.HA' := '1'}
{attribute 'OPC.UA.HA.Storage' := '2'}
{attribute 'OPC.UA.HA.Sampling' := '20'}
{attribute 'OPC.UA.HA.Buffer' := '200'}
_HistoryFile : UINT;

{attribute 'OPC.UA.DA' := '1'}
{attribute 'OPC.UA.HA' := '1'}
{attribute 'OPC.UA.HA.Storage' := '3'}
{attribute 'OPC.UA.HA.Sampling' := '50'}
{attribute 'OPC.UA.HA.Buffer' := '10000'}
_HistoryDBcompact : UINT;

{attribute 'OPC.UA.DA' := '1'}
{attribute 'OPC.UA.HA' := '1'}
{attribute 'OPC.UA.HA.Storage' := '4'}
{attribute 'OPC.UA.HA.Sampling' := '5'}
{attribute 'OPC.UA.HA.Buffer' := '1000000'}
_HistoryDB : UINT;
TwinCAT 2 (mit TPY-Import):
_HistoryMem : UINT; (*~ (OPC:1:available for OPC UA Clients)
(OPC_UA_PROP[5000]:1:Memory)
(OPC_UA_PROP[5000][1]:5:SamplingRate)
(OPC_UA_PROP[5000][2]:1000:Buffer) *)

_HistoryFile : UINT; (*~ (OPC:1:available for OPC UA Clients)
(OPC_UA_PROP[5000]:2:File)
(OPC_UA_PROP[5000][1]:20:SamplingRate)
(OPC_UA_PROP[5000][2]:200:Buffer) *)

_HistoryDBcompact : UINT; (*~ (OPC:1:available for OPC UA Clients)
(OPC_UA_PROP[5000]:3:SQLCompact)
(OPC_UA_PROP[5000][1]:50:SamplingRate)
(OPC_UA_PROP[5000][2]:10000:Buffer) *)

_HistoryDB : UINT; (*~ (OPC:1:available for OPC UA Clients)
(OPC_UA_PROP[5000]:4:SQL)
(OPC_UA_PROP[5000][1]:5:SamplingRate)
(OPC_UA_PROP[5000][2]:1000000:Buffer) *)
Historical Access im TwinCAT-C++-Modul aktivieren
Jedes TwinCAT‑3‑C++‑Symbol, dessen Verlauf aufgezeichnet werden soll, muss entsprechend konfiguriert werden. Vergleichbar mit der Konfiguration von SPS-Symbolen für Historical Access, müssen die Parameter für ein C++‑Symbol konfiguriert werden:
Parameter | Kommentar | Beschreibung
Aktivieren | OPC.UA.DA := 1 | Aktiviert das Symbol für Datenzugriff. Dies ist erforderlich, um das Symbol auch für Historical Access zur Verfügung zu stellen.
HA aktivieren | OPC.UA.HA := 1 | Aktiviert das Symbol für Historical Access.
Speichermedium | OPC.UA.HA.Storage := 1 | Legt das für die Speicherung der Symbolwerte zu verwendende Speichermedium fest (1 = RAM, 2 = Datei, 3 = SQL Compact Database, 4 = SQL Server Database).
Aufzeichnungsrate | OPC.UA.HA.Sampling := 50 | Definiert die Rate, mit der die Variablenwerte aus der Steuerung zu lesen und auf dem entsprechenden Speichermedium zu speichern sind. Der OPC UA Server verwendet vordefinierte feste Aufzeichnungsraten, die hier verwendet werden können. Die Aufzeichnungsraten können Sie ggf. in ServerConfig-Datei erweitern. Allerdings ist dies normalerweise nicht erforderlich, und es wird auch davon abgeraten, diese Einstellungen vorzunehmen.
Pufferlänge | OPC.UA.HA.Buffer := 10000 | Legt die Anzahl Elemente fest, die der Puffer aufnehmen soll.
In TwinCAT 3 C++ konfigurieren Sie diese Parameter im TMC-Code-Editor des entsprechenden C++-Moduls. Navigieren Sie mithilfe des TMC-Code-Editors zu dem Symbol, das für Historical Access freigegeben werden soll und fügen Sie die Parameter in dem Bereich Optionale Eigenschaften der Symboleigenschaften hinzu. Vergewissern Sie sich, dass Sie das Kontrollkästchen Symbol erzeugen aktiviert haben.
Voraussetzungen
Produkte | Setup-Versionen | Zielplattform
TS6100, TF6100 | 3.x.x | IPC oder CX (x86, x64, ARM)


Setup-Version 4.x.x

Technische Einführung [image] Server [image] SPS [image] Historical Access [image] Setup-Version 4.x.x
Setup-Version 4.x.x
Ab Setup-Version 4.x.x wird Historical Access nicht mehr über Attribute bzw. Kommentare konfiguriert. Dies hat den Vorteil, dass die Historical-Access-Funktionalität nun auch für Laufzeiten zur Verfügung steht, die diese bisher nicht unterstützt haben, z. B. Variablen von einem BC9191 Controller. Des Weiteren kann eine Historical‑Access‑Konfiguration nun auch nachträglich, d. h. ohne Anpassung des SPS-Projekts durchgeführt werden.
Die Historical‑Access‑Konfiguration ist nun XML-basiert (TcUaHaConfig.xml) und kann über den OPC-UA-Server-Konfigurator vorgenommen werden. Die XML-Datei befindet sich in demselben Verzeichnis wie die TcOpcUaServer.exe.
Siehe auch:
▪
Konfiguration > Setup-Version 4.x.x > Übersicht (OPC-UA-Server-Konfigurator) und Historical Access konfigurieren)
Aufbau XML-Datei (TCUaHaConfig.xml)
<HistoryConfig>
<HistoryController>
<HistoryAdapter Type="Volatile" Id="0" File="" Server="" Database="" User="" Password=""/>
<HistoryAdapter Type="File" Id="1" File="historydb.dat" Server="" Database="" User="" Password=""/>
<HistoryAdapter Type="SQL" Id="2" File="" Server="" Database="database123" User="user" Password="pwd"/>
<HistoryAdapter Type="SQLCompact" Id="3" File="historydb.xyz" Server="" Database="" User="" Password=""/>
<HistoryAdapter Type="SQLCompact" Id="4" File="historydb2.xyz" Server="" Database="" User="" Password=""/>
</HistoryController>
<HistoryNodes>
<HistoryNode HistoryWriteable="true" SamplingRate="0" MaxSamples="100000" AdapterId="0" NS="urn:BeckhoffAutomation:Ua:PLC1" NodeId="s=PRG_HA_SingleNode.nMyValue"/>
<HistoryNode HistoryWriteable="true" SamplingRate="0" MaxSamples="100000" AdapterId="0" NS="urn:BeckhoffAutomation:Ua:PLC1" NodeId="s=PRG_HA_MultipleNodes.nMyValue1"/>
<HistoryNode HistoryWriteable="true" SamplingRate="0" MaxSamples="100000" AdapterId="0" NS="urn:BeckhoffAutomation:Ua:PLC1" NodeId="s=PRG_HA_MultipleNodes.nMyValue2"/>
<HistoryNode HistoryWriteable="true" SamplingRate="0" MaxSamples="100000" AdapterId="0" NS="urn:BeckhoffAutomation:Ua:PLC1" NodeId="s=PRG_HA_MultipleNodes.fMyValue3"/>
</HistoryNodes>
</HistoryConfig>
In dem Bereich HistoryController können Sie alle unterstützten Datenspeicher konfigurieren. Aktuell werden die folgenden Speicherorte unterstützt:
▪
Arbeitsspeicher („Volatile“)
▪
Datei („File“)
▪
SQL Compact
▪
SQL Server (wird nicht unter Windows CE unterstützt)
Jeder HistoryAdapter (außer „Volatile“) kann hierbei mehrfach verwendet werden, z. B. wenn die historischen Werte für einzelne Variablen in unterschiedlichen Datenspeichern abgelegt werden sollen.
Im Bereich HistoryNodes werden die einzelnen Nodes konfiguriert, einem Datenspeicher zugewiesen und mit einer SamplingRate sowie einer maximalen Größe für den zu verwendenden Ringbuffer im Datenspeicher versehen.
Das Attribut HistoryWriteable="true" bewirkt, dass der Datenspeicher für diese Node über einen Aufruf HistoryUpdate() mit Werten befüllt werden kann. Ein solcher Aufruf wird z. B. von dem TwinCAT OPC UA Client über den Funktionsbaustein UA_HistoryUpdate zur Verfügung gestellt. Wenn Sie einen Node mit diesem Attribut konfigurieren, dann „sampled“ der Server die Werte üblicherweise nicht selbst, sondern bekommt diese von anderen Clients gereicht. Die SamplingRate ist daher bei einer solchen Konfiguration üblicherweise gleich 0.
Voraussetzungen
Produkte | Setup-Versionen | Zielplattform
TF6100 | 4.x.x | IPC oder CX (x86, x64, ARM)


Historische Daten anzeigen

Technische Einführung [image] Server [image] SPS [image] Historical Access [image] Historische Daten anzeigen
Historische Daten anzeigen
Historical-Access-Werte in einem OPC UA Client anzeigen
Die folgende Schritt-für-Schritt-Anleitung beschreibt, wie Sie die UA-Expert-Software konfigurieren, um auf historische Daten zuzugreifen.
1.
Starten Sie die UA-Expert-Software und stellen Sie eine Verbindung mit dem OPC UA Server her.
2.
Fügen Sie eine neue „History Trend Ansicht“ hinzu.
3.
Durchsuchen Sie den PLC1-Namensraum und fügen Sie die SPS-Variablen _HistoryDB, _HistoryDBcompact, _HistoryFast und _HistorySlowPersist per Drag-and-drop hinzu.
⇨
Sie können nun den gewünschten Zeitraum, für den die Symbolwerte angezeigt werden sollen, mithilfe der Steuerelemente Start Time und End Time festlegen, oder falls erforderlich ein Cyclic Update für diese Variablen starten.


Alarms and Conditions

Technische Einführung [image] Server [image] SPS [image] Alarms and Conditions
Alarms and Conditions
In diesem Abschnitt werden die notwendigen Schritte zur Konfiguration von OPC UA Alarms and Conditions (A&C) auf dem OPC UA Server beschrieben. Das Grundkonzept ist unabhängig von der TwinCAT‑Laufzeit. Demzufolge sind die Konfigurationsschritte für SPS, C++, TcCOM-Laufzeit oder nur I/O-Task gleich.
OPC UA Alarms and Conditions (Teil 9 der OPC-UA-Spezifikation) beschreibt ein Modell für die Überwachung von Prozesswerten und das Ausgeben von Alarmen und Ereignissen bei Zustandsänderungen eines Laufzeit-Symbols.
Voraussetzungen
Die folgenden Voraussetzungen gelten für die Verwendung von OPC UA Alarms and Conditions:
▪
Das zu überwachende Laufzeitsymbol muss im Namensraum verfügbar sein.
▪
Der OPC UA Client muss Alarms and Conditions unterstützen. In diesem Abschnitt wird der UA Expert (von Unified Automation) als Referenz‑UA‑Client verwendet.
Allgemeine Informationen
Führen Sie die folgenden Schritte einmalig aus, um ein Symbol für Alarms and Conditions freizugeben:
▪
Schritt 1: Laufzeitsymbol für Datenzugriff aktivieren (damit das Symbol generell via OPC UA zugänglich wird.)
▪
Schritt 2: A&C für ein Symbol aktivieren
▪
Schritt 3: Eigene Benutzerdaten mit einem Ereignis übermitteln
▪
Schritt 4: Ereignis über die FireEvent-Methode auslösen
▪
Schritt 5: Mehrsprachige Alarmtexte konfigurieren
▪
Schritt 6: A&C bei einem Referenz-OPC-UA-Client anmelden
Diese Schritte werden nachfolgend ausführlicher erläutert. Am Ende des Abschnitts finden Sie Informationen zum Empfang von konfigurierten Alarmen über A&C mit dem UA‑Expert‑Referenz‑Client.
Unterstützte Alarmtypen
Die Implementierung von OPC UA Alarms and Conditions unterstützt derzeit die folgenden Alarmtypen:
▪
LimitAlarmType: Verschiedene Grenzen für ein Symbol definieren. Wird eine Grenze erreicht, gibt der UA Server einen Alarm aus.
▪
OffNormalAlarmType: Einen Wert definieren, der „normal“ ist. Wenn der aktuelle Wert vom „normalen“ Wert abweicht, gibt der UA Server einen Alarm aus.
Schritt 1: Laufzeitsymbol für Datenzugriff aktivieren
Damit eine Variable für A&C konfiguriert werden kann, muss diese im OPC UA Server zur Verfügung stehen. Im Falle einer SPS‑Variablen versehen Sie diese dazu mit einem Attribut (siehe Zugriff auf SPS-Laufzeit).
Schritt 2: A&C für ein Symbol aktivieren
Mit dem OPC-UA-Server-Konfigurator können Sie ein Laufzeitsymbol für A&C konfigurieren. Der Konfigurator hat eine einfache grafische Bedienoberfläche, um die dahinter stehende XML-Datei zu bearbeiten. Der Konfigurator steht, je nach Setup-Version, in zwei Varianten zur Verfügung: Standalone und integriert in das Visual Studio.
Der folgende Programmausschnitt zeigt ein Beispiel dieser XML-Datei, um das allgemeine Verhalten und den Aufbau der A&C-Implementierung besser zu verstehen.
<TcUaAcConfig>
<ConditionController Name="ConditionController1" >
<Condition Name="Counter" Severity="200">
<LimitAlarmType LowLowLimit="-10" LowLimit="0" HighLimit="10" HighHighLimit="20" MessageNormal="100" MessageLowLow="10" MessageLow="11" MessageHigh="12" MessageHighHigh="13"/>
<ItemToMonitor SamplingRate="100" NS="urn:[NodeName]:BeckhoffAutomation:Ua:PLC1" NodeId="s=MAIN.nCounter1" />
</Condition>
<Condition Name="Switch" Severity="500">
<OffNormalAlarmType Normal="0" MessageNormal="100" MessageOffNormal="20" />
<ItemToMonitor SamplingRate="100" NS="urn:[NodeName]:BeckhoffAutomation:Ua:PLC1" NodeId="s=MAIN.bSwitch" />
</Condition>
<Condition Name="Struct" Severity="300">
<LimitAlarmType LowLowLimit="-10" LowLimit="0" HighLimit="10" HighHighLimit="20" MessageNormal="100" MessageLowLow="10" MessageLow="11" MessageHigh="12" MessageHighHigh="13"/>
<ItemToMonitor SamplingRate="100" NS="urn:[NodeName]:BeckhoffAutomation:Ua:PLC1" NodeId="s=MAIN.stStruct" />
</Condition>
</ConditionController>
<ConditionController Name="ConditionController2" >
<Condition Name="Counter2" Severity="200">
<LimitAlarmType LowLowLimit="-10" LowLimit="0" HighLimit="10" HighHighLimit="20" MessageNormal="100" MessageLowLow="10" MessageLow="11" MessageHigh="12" MessageHighHigh="13"/>
<ItemToMonitor SamplingRate="100" NS="urn:[NodeName]:BeckhoffAutomation:Ua:PLC1" NodeId="s=MAIN.nCounter2" />
</Condition>
</ConditionController>
</TcUaAcConfig>
Eine „Bedingung“ definiert das zu überwachende Laufzeitsymbol und die Alarmgrenzen und -texte. Jede Bedingung ist in einem sogenannten „ConditionController“ organisiert, dem Objekt, das die OPC UA Clients später abonnieren.
Bei der Erstellung einer Bedingung (Condition) müssen der NamespaceName (NS) und die NodeID spezifiziert werden, um auf den zu überwachenden UA-Knoten zu verweisen. Der Konfigurator bietet einen einfachen Browsing-Mechanismus, um einen Knoten auszuwählen. In XML kann durch den Platzhalter [NodeName] in NamespaceName die XML-Datei einfach zwischen zwei verschiedenen Hardwaresystemen hin und her wechseln. NamespaceName beinhaltet immer den Hostnamen des IPC oder Embedded-PC, auf dem der OPC UA Server läuft. Wird [NodeName] gewählt, wird dieser Tag durch den Hostnamen des aktuellen IPCs oder Embedded-PCs ersetzt, auf dem der UA Server läuft.
Die SamplingRate bestimmt, wie oft der UA Server einen Wert vom Knoten abfragen soll, um festzustellen, ob eine der Alarmgrenzen erreicht wurde.
Die Alarmtexte werden über eine ID identifiziert. Die ID identifiziert eindeutig einen Alarmtext aus der Ressourcendatei (siehe Schritt 5: Mehrsprachige Alarmtexte konfigurieren).
Schritt 3: Eigene Benutzerdaten mit einem Alarm übermitteln
Alarme können Felder mit eigenen Benutzerdaten enthalten, die die mit dem Alarm ausgegebenen Daten ergänzen. Diese Benutzerdatenfelder können Sie in der Laufzeitanwendung erzeugen und ausfüllen. Erstellen Sie dazu ein STRUCT und nennen Sie dessen erstes Element „value“. Bei einem Alarm werden dann alle folgenden Elemente in einem zusätzlichen Benutzerdatenfeld gesendet.
Beispiel SPS-Anwendung:
TYPE ST_CustomStruct :
STRUCT
value : INT;
data : ST_SomeStruct;
END_STRUCT
END_TYPE

TYPE ST_SomeStruct :
STRUCT
Data1 : INT;
Data2 : REAL;
Data3 : LREAL;
END_STRUCT
END_TYPE
Die Instanz von ST_CustomStruct wird über den regulären Mechanismus, z. B. in TwinCAT 3, für den Datenzugriff aktiviert. Das STRUCT muss dazu als StructuredType aktiviert sein.
PROGRAM MAIN
VAR
{attribute 'OPC.UA.DA' := '1'}
{attribute 'OPC.UA.DA.StructuredType' := '1'}
stCustomStruct : ST_CustomStruct;
END_VAR
Bei der Anmeldung bei einem ConditionController müssen die OPC UA Clients besondere AlarmConditionTypes, sogenannte „BkUaLimitAlarmType“ und „BkUaOffNormalAlarmType“, abonnieren, damit sie die besonderen Benutzerdatenfelder beim Eingang eines Alarms empfangen können.
Der OPC UA Client empfängt dann die Benutzerdaten in den Feldern BkUaEventData und BkUaEventValue des eingehenden Alarms. Im obigen Beispiel sind das der Wert der SPS-Variablen sowie die Benutzerdaten, die mit der SPS-Struktur ST_SomeStruct dargestellt werden.
Grafik aus Alarms _ Conditions (i1d631q3.png)
Schritt 4: Ereignis über die FireEvent-Methode auslösen
Jeder ConditionController umfasst eine FireEvent-Methode, mit der die OPC UA Clients ein allgemeines Ereignis mit benutzerdefinierten EventFields auslösen können.
Wenn die Methode ausgeführt wird, dann wird ein Ereignis auf dem OPC UA Server ausgegeben. Andere OPC UA Clients können diese Ereignisse empfangen, wenn sie den entsprechenden ConditionController abonnieren.
Die benutzerdefinierten EventFields werden als „UserEventData“ an das Ereignis angehängt. Diesen Daten können von OPC UA Clients empfangen werden, die beim SimpleEventType „UserEventType“ angemeldet sind.
Schritt 5: Mehrsprachigen Alarmtexten konfigurieren
Die A&C-Implementierung im OPC UA Server unterstützt die Verwendung von mehrsprachigen Alarmtexten. Abhängig von der Sprache, mit der sich der UA Client mit dem Server verbindet, wird ein entsprechender Alarmtext verwendet.
Alarmtexte werden in XML-Dateien konfiguriert, für jede Sprache gibt es eine eigene Datei. Diese Dateien befinden sich im Ordner res (Ressource) des OPC UA Servers. Mit dem Konfigurator können Sie Alarmtexte einfach hinzufügen oder entfernen, ohne dass Sie die XML-Dateien direkt bearbeiten müssen. Jeder Alarmtext hat eine eigene ID, die in der Datei nur einmal vorkommt.
Beispiel:
<TcOpcUaSvrRes Lang="en">
<Text ID="0">Text not available</Text>
<Text ID="1">Some alarm text</Text>
<Text ID="2">Value is High range</Text>
<Text ID="3">Value is HighHigh range</Text>
<Text ID="4">Value is OffNormal</Text>
...
</TcOpcUaSvrRes>
Schritt 6: A&C bei einem Referenz-OPC-UA-Client anmelden
Ein OPC UA Client muss sich bei einem ConditionController anmelden, damit er Ereignisse für Bedingungen empfangen kann, die für diesen besonderen ConditionController konfiguriert sind. Der UA Expert stellt Funktionen zur Verfügung, um UA-Ereignisse zu abonnieren und zu empfangen.
Nachdem Sie den UA Expert gestartet und eine Verbindung zum OPC UA Server hergestellt haben, fügen Sie Ihrem Arbeitsbereich eine neue Dokumentenansicht Event View hinzu.
Sie können einen ConditionController dann durch Ziehen des entsprechenden Objekts in den Event View abonnieren. Die Ereignisse für diesen ConditionController werden im Event Window angezeigt.
Möglicherweise müssen spezielle Alarm- und/oder Ereignistypen abonniert werden, damit Sie alle Felder eines eingehenden Ereignisses oder Alarms empfangen können.


Methodenaufruf

Technische Einführung [image] Server [image] SPS [image] Methodenaufruf
Methodenaufruf
Methodenaufrufe sind ein grundlegender Teil der OPC-UA-Spezifikation. Mit der Einführung dieser Funktionalitäten in die SPS-Welt bietet TwinCAT 3 die Möglichkeit zur effizienten Ausführung von RPC‑Aufrufen in der IEC61131-Welt und verringert somit die klassischen Handshake-Pattern bei der Kommunikation zwischen den Geräten. Der OPC UA Server importiert SPS‑Methoden wie OPC‑UA‑Methoden über seinen TMC-Import.
IEC61131-Methode
Auch wenn die SPS-Methode eine normale Methode im UA-Namensraum zu sein scheint, ist sie immer noch eine IEC61131-Methode, die innerhalb des Echtzeit-Kontexts ausgeführt wird und somit unter den Kontext einer Echtzeit-Task fällt. Der SPS-Entwickler muss daher Vorsichtsmaßnahmen treffen, sodass die Ausführungszeit der Methode in die Task-Zykluszeit passt.
Grafik aus Method Call (icv0vpv2.png)
Methoden in IEC61131-3
Methoden in der IEC61131-Welt werden immer unterhalb eines Funktionsbausteins konfiguriert. Auf Hochsprachenebene kann der Funktionsbaustein als umgebende Klasse der Methode betrachtet werden. Die Methode selbst müssen Sie mit einem speziellen SPS-Attribut deklarieren, sodass das TwinCAT-System weiß, dass die Methode für einen remote Methodenaufruf aktiviert werden soll.
{attribute 'TcRpcEnable':='1'}
METHOD M_Sum : INT
VAR_INPUT
a : INT;
b : INT;
END_VAR
Gefilterter oder ungefilterter Modus
In Abhängigkeit davon, welcher Importmodus verwendet wird, müssen Sie den umgebenden Funktionsbaustein ebenfalls für den OPC‑UA‑Zugriff aktivieren. Dies kann durch Verwendung der normalen SPS‑Attribute für den OPC‑UA‑Zugriff erfolgen.
Beachten Sie dabei, dass Sie nur dann die SPS-Attribute verwenden müssen, wenn der gefilterte Modus verwendet wird, um Symbole aus der SPS für den Zugriff über OPC UA freizugeben. Dies ist die Standardeinstellung des OPC UA Servers.
Beispiel:
Die Methode M_Sum befindet sich im Funktionsbaustein FB_Mathematics. Die Deklaration der Funktionsbausteininstanz verwendet das SPS-Attribut, das den Funktionsbaustein und damit die Methode ebenfalls für den OPC-UA-Zugriff aktiviert hat.
PROGRAM MAIN
VAR
{attribute 'OPC.UA.DA':='1'}
fbMathematics : FB_Mathematics;
END_VAR


AnalogItemTypes

Technische Einführung [image] Server [image] SPS [image] AnalogItemTypes
AnalogItemTypes
AnalogItemTypes sind ein Bestandteil der OPC-UA-Spezifikation und ermöglichen es, Metainformationen wie z. B. Einheiten an eine Variable zu heften. In der TwinCAT 3 SPS können Sie diese Metainformationen in Form von SPS-Attributen definieren.
Folgende Einstellungen sind möglich:
▪
EngineeringUnits: Einheiten, definiert über die OPC-UA-Spezifikation
▪
EURange: Maximaler Wertebereich der Variablen
▪
InstrumentRange: Normaler Wertebereich der Variablen
▪
WriteBehavior: Verhalten, wenn bei einem Schreibvorgang der Wertebereich überschritten wird.
Das nachfolgende Beispiel zeigt, wie die Variable fillLevel als AnalogItemType konfiguriert wird. Folgenden Parameter werden hierbei gesetzt:
▪
Einheit: 20529 („Prozent“, definiert in der OPC-UA-Spezifikation)
▪
Max. Wertebereich: 0 bis 100
▪
Normaler Wertebereich: 10 bis 90
▪
Schreibverhalten: 1 (Clamping)
{attribute 'OPC.UA.DA' := '1'}
{attribute 'OPC.UA.DA.AnalogItemType' := '1'}
{attribute 'OPC.UA.DA.AnalogItemType.EngineeringUnits' := '20529'}
{attribute 'OPC.UA.DA.AnalogItemType.EURange' := '0:100'}
{attribute 'OPC.UA.DA.AnalogItemType.InstrumentRange' := '10:90'}
{attribute 'OPC.UA.DA.AnalogItemType.WriteBehavior' := '1'}
fillLevel : UINT;
EngineeringUnits können hierbei anhand der in OPC UA spezifizierten IDs (Teil 8 der OPC‑UA‑Spezifikation) konfiguriert werden. Die IDs orientieren sich hierbei nach den weit verbreiteten und akzeptierten „Codes for Units of Measurement (Recommendation N.20)“, die vom „United Nations Centre for Trade Facilitation and Electronic Business“ veröffentlicht wurden. CommonCode, der die dreistellige, alphanumerische ID angibt, wird von OPC UA laut Spezifikation in einen Int32-Wert konvertiert und referenziert (Auszug aus OPC‑UA‑Spezifikation v1.02, Pseudo-Code):
Int32 unitId = 0;
Int32 c;
for (i=0; i<=3;i++)
{
c = CommonCode[i];
if (c == 0)
break; // end of Common Code
unitId = unitId << 8; // shift left
unitId = unitId | c; // OR operation
}
Schreibverhalten
Beim Schreiben einer AnalogItemType-Variablen können Sie definieren, wie der OPC UA Server mit dem neuen Wert in Bezug auf den Wertebereich umgehen soll. Hierbei gibt es die folgenden Möglichkeiten:
▪
0: Alle Werte sind zugelassen und werden bei einem Schreibvorgang übernommen.
▪
1: Der zu schreibende Wert wird passend zum Wertebereich abgeschnitten.
▪
2: Der zu schreibende Wert wird abgewiesen, falls er den Wertebereich überschreitet.


Typsystem

Technische Einführung [image] Server [image] SPS [image] Typsystem
Typsystem
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 seinen 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:
Grafik aus Type system (ibf6eok2.png)
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.
Grafik aus Type system (i8a83g13.png)
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:
Grafik aus Type system (igrjfpt2.png)
Außerdem enthält das Typsystem mehr Informationen über ST_SampleStruct:
Grafik aus Type system (iun9n673.png)
Und in den Referenzen von ST_SampleStruct:
Grafik aus Type system (ibkg1h5.png)
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:
Grafik aus Type system (i9g54s22.jpg)
Die zwei Funktionsbausteine Scanner und Drive sind von der Basisklasse Device abgeleitet, indem objektorientierte Erweiterungen der IEC61131-3 verwendet werden. Das MAIN-Programm 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:
Grafik aus Type system (igooqku2.png)
Der zugrunde liegende Datentyp kann nun in der Referenz jedes Objekts bestimmt werden, z. B. Objekt Scanner1:
Grafik aus Type system (im6d77g.png)
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.


StructuredTypes

Technische Einführung [image] Server [image] SPS [image] StructuredTypes
StructuredTypes
StructuredTypes erlauben es, Strukturen zu lesen oder zu schreiben ohne dafür jedes Byte zu interpretieren, weil der UA Server den Informationstyp jedes Elements der Struktur zurückgibt. Durch komplexe Funktionen in modernen OPC UA SDKs können OPC UA Clients diese strukturellen Informationen durchsuchen und interpretieren.
Ab Version 2.2.x des OPC UA Servers werden Strukturen von der TwinCAT‑3‑Laufzeit (nur TMC- und TMI-Import) als ein StructuredType im UA‑Namensraum erzeugt.
Beispiel:
STRUCT ST_Communication:
TYPE ST_Communication :
STRUCT
a : INT;
b : INT;
c : INT;
END_STRUCT
END_TYPE
Programm MAIN:
PROGRAM MAIN
VAR
{attribute 'OPC.UA.DA' := '1'}
{attribute 'OPC.UA.DA.StructuredType' := '1'}
stCommunication : ST_Communication;
END_VAR
Gefilterter Modus
Werden Filter eingesetzt, um Symbole über OPC UA verfügbar zu machen, muss ein STRUCT oder Funktionsbaustein im UA‑Namensraum voll verfügbar sein, um als StructuredType angezeigt zu werden.
Pointer und Referenzen
Werden in der Struktur Pointer- und Referenztypen verwendet, dann können diese nicht in einen StructuredType überführt werden. Der OPC UA Server stellt diese Strukturen dann als reguläre FolderTypes mit der entsprechenden Membervariablen dar.
Die Instanz stCommunication wird dann im UA-Namensraum als StructuredType angezeigt:
Alternativ kann die STRUCT-Definition auch das SPS Attribut erhalten, um alle Instanzen von STRUCT als StructuredType verfügbar zu machen.
{attribute 'OPC.UA.DA.StructuredType' := '1'}
TYPE ST_Communication :
STRUCT
a : INT;
b : INT;
c : INT;
END_STRUCT
END_TYPE
Um StructuredType einer bestimmten Instanz zu deaktivieren, verwenden Sie das folgende Attribut:
PROGRAM MAIN
VAR
{attribute 'OPC.UA.DA' := '1'}
{attribute 'OPC.UA.DA.StructuredType' := '0'}
stCommunication : ST_Communication;
END_VAR
Funktionsbaustein StructuredType
Zusätzlich enthält jeder Funktionsbaustein der TwinCAT 3 SPS auch einen Kindknoten FunctionBlock, der den gesamten Funktionsbaustein als StructuredType beinhaltet.
Beispiel:
Funktionsbaustein:
FUNCTION_BLOCK FB_FunctionBlock
VAR_INPUT
Input1 : INT;
Input2 : LREAL;
END_VAR
VAR_OUTPUT
Output1 : LREAL;
END_VAR
Instanz des Funktionsbausteins:
PROGRAM MAIN
VAR
{attribute 'OPC.UA.DA' := '1'}
{attribute 'OPC.UA.DA.StructuredType' := '1'}
fbFunctionBlock : FB_FunctionBlock;
END_VAR
Instanz des Funktionsbausteins im OPC‑UA‑Namensraum:
FunctionBlock-Knoten mit StructuredType:
Alternativ kann der Funktionsbaustein auch ein SPS-Attribut erhalten, um alle Instanzen des Funktionsbausteins als StructuredType zur Verfügung zu stellen.
{attribute 'OPC.UA.DA.StructuredType' := '1'}
FUNCTION_BLOCK FB_FunctionBlock
VAR_INPUT
Input1 : INT;
Input2 : LREAL;
END_VAR
VAR_OUTPUT
Output1 : LREAL;
END_VAR
Um StructuredType einer bestimmten Instanz zu deaktivieren, verwenden Sie das folgende Attribut:
PROGRAM MAIN
VAR
{attribute 'OPC.UA.DA' := '1'}
{attribute 'OPC.UA.DA.StructuredType' := '0'}
fbFunctionBlock : FB_FunctionBlock;
END_VAR
Maximale Größe der Struktur
Die maximale Größe einer Struktur ist standardmäßig auf 16 kByte festgelegt. Jedes STRUCT tauscht ständig Daten mit dem Basis-ADS-Gerät aus, d. h. mit jedem Lese-/Schreibbefehl eines StructuredTypes wird eine große ADS-Meldung verschickt. Damit der ADS-Router nicht mit großen Meldungen überflutet wird, ist die maximale Größe beschränkt. Sie können diese Vorgabe in der Datei ServerConfig.xml ändern. Dazu muss der Schlüssel <MaxStructureSize> zu OpcServerConfig\UaServerConfig\ hinzugefügt und ein neuer Wert für die maximale Größe einer Struktur in Bytes festgelegt werden. Wenn eine Struktur die Größe <MaxStructureSize> überschreitet, wird sie als FolderType importiert, wo jedes Strukturelement als einzelner Knoten verfügbar ist.


Verwendung von Arrays

Technische Einführung [image] Server [image] SPS [image] Verwendung von Arrays
Verwendung von Arrays
Standardmäßig werden Arrays im UA-Namensraum als einzelner Knoten betrachtet. Dies bedeutet, dass, wenn Sie z. B. in der SPS ein Array dyn_BOOL[10] definieren (und dieses auch für OPC UA freigegeben haben), es anschließend im UA-Namensraum wie folgt auftaucht:
Der Vorteil dieser Vorgehensweise ist eine deutliche Reduzierung der Komplexität des UA-Namensraums und des Speicherverbrauchs, da nicht jede Position eines Arrays als einzelner Knoten im Namensraum zur Verfügung gestellt werden muss. Moderne UA Clients können jedoch weiterhin auf die einzelnen Array-Positionen über den sogenannten „RangeOffset“ zugreifen.
Damit jedoch auch ältere UA Clients unterstützt werden, welche dieses Feature nicht bieten, können Sie die Positionen eines Arrays auch als einzelne Knoten im UA-Namensraum verfügbar machen. Dies stellt sich wie folgt dar:
Diese Einstellung ist durch Aktivierung der Option Legacy Array Handling im UA-Konfigurator innerhalb der jeweiligen Namensraum-Konfiguration verfügbar.
Je nach Umfang des SPS-Projekts gewinnt der UA-Namensraum hierdurch deutlich an Komplexität, was sich wiederum in einer erhöhten Speicherauslastung des UA Servers widerspiegelt.
Eine Änderung der oben genannten Einstellungen wird erst aktiv, wenn Sie den UA Server neu starten.


Liste der Attribute und Kommentare

Technische Einführung [image] Server [image] SPS [image] Liste der Attribute und Kommentare
Liste der Attribute und Kommentare
Die Laufzeitvariablen für verschiedene OPC-UA-Funktionen (z. B. Data Access oder Historical Access) konfigurieren Sie direkt im SPS-Programm oder im TMC-Code-Editor (bei Verwendung von TwinCAT 3 C++). Der Vorteil ist, dass ein SPS-Entwickler direkt in dem Programm, mit dem er vertraut ist, entscheiden kann, ob und wie eine Variable für OPC UA freizugeben ist. Sie aktivieren eine Variable, indem Sie einen Kommentar und das entsprechenden OPC-UA-Tags vor der Variablen einfügen, z. B.:
TwinCAT 3 SPS (TMC):
{attribute 'OPC.UA.DA' := '1'}
bVariable : BOOL;
TwinCAT 2 SPS (TPY):
bVariable : BOOL; (*~ (OPC:1:available)*)
Eine detaillierte Beschreibung zur Verwendung von Attributen und Kommentaren erhalten Sie in den Abschnitten über die entsprechenden Laufzeitkomponenten:
▪
SPS
▪
C++
▪
I/O
▪
Matlab/Simulink
Die folgende Tabelle zeigt einen Überblick aller definierbaren Tags und ihrer Bedeutung. In den Unterschnitten der entsprechenden Funktion finden Sie eine ausführliche Beschreibung des Funktionsprinzips.
TwinCAT 3 (TMC):
OPC-UA-Funktion | SPS-Tag | C++ TMC-Code-Editor (Optionale Eigenschaften) | Bedeutung
Data Access (DA) | {attribute 'OPC.UA.DA' := '0'} | Name: OPC.UA.DA Wert: 0 | Sperrt eine Variable für OPC UA, woraufhin diese im UA‑Namensraum nicht mehr sichtbar ist.
Data Access (DA) | {attribute 'OPC.UA.DA' := '1'} | Name: OPC.UA.DA Wert: 1 | Aktiviert eine Variable für OPC UA, woraufhin diese im UA‑Namensraum sichtbar wird. Dieses Tag muss immer gesetzt sein, wenn eine Variable für UA verwendet werden soll.
Data Access (DA) | {attribute 'OPC.UA.DA.Access' := 'x'} | Name: OPC.UA.DA.Access Wert: siehe rechte Spalte | Setzt Lese-/Schreib-Zugriff für eine Variable, je nach Parameter „x“. 0 = Kein 1 = Schreibgeschützt 2 = Nur Schreibzugriff 3 = Lese- und Schreibzugriff (Standardwert, wenn kein Tag verwendet wird)
Data Access (DA) | {attribute 'OPC.UA.DA.Description' := 'x'} | Name: OPC.UA.DA.Description Wert: siehe rechte Spalte | Setzt einen Text für das OPC-UA-Attribut „Description“.
Data Access (DA) | {attribute 'OPC.UA.DA.StructuredType' := '0'} | Name: OPC.UA.DA.StructuredType Wert: 0 | Deaktiviert StructuredType für ein STRUCT oder einen Funktionsbaustein
Data Access (DA) | {attribute 'OPC.UA.DA.StructuredType' := '1'} | Name: OPC.UA.DA.StructuredType Wert: 1 | Aktiviert StructuredType für ein STRUCT oder einen Funktionsbaustein
Data Access | {attribute 'OPC.UA.DA.Status' := 'quality'} | Name: OPC.UA.DA.Status Wert: quality | StatusCode eines Symbols im UA‑Namensraum manuell festlegen. Nur für Datenstrukturen. Der Wert „quality“ legt fest, welches DINT Unterelement der Datenstruktur den StatusCode festlegt. Siehe entsprechenden Artikel der Dokumentation für weitere Informationen.
Historical Access (HA) | {attribute 'OPC.UA.HA' := '1'} | Name: OPC.UA.HA Wert: 1 | Aktiviert eine Variable für Historical Access. Muss mit {attribute 'OPC.UA.DA' := '1'} verwendet werden.
Historical Access (HA) | {attribute 'OPC.UA.HA.Storage' := 'x'} | Name: OPC.UA.HA.Storage Wert: siehe rechte Spalte | Definiert den Speicherort für Historical Access, abhängig von Parameter “x” 1 = Speicher 2 = Datei 3 = SQL Compact Database 4 = SQL Server Database
Historical Access (HA) | {attribute 'OPC.UA.HA.Sampling' := 'x'} | Name: OPC.UA.HA.Sampling Wert: siehe rechte Spalte | Legt die Abtastrate fest, mit der die Variablenwerte zu speichern sind, in Abhängigkeit des Parameters „x“ in [ms]
Historical Access (HA) | {attribute 'OPC.UA.HA.Buffer' := 'x'} | Name: OPC.UA.HA.Buffer Wert: siehe rechte Spalte | Definiert die maximale Anzahl Werte, die im Datenspeicher bleiben, in Abhängigkeit des Parameters „x“.
TwinCAT 2 (TPY):
OPC‑UA‑Funktion | SPS‑Tag | Bedeutung
Data Access (DA) | (*~ (OPC:0:not available) *) | Sperrt eine Variable für OPC UA, woraufhin diese im UA‑Namensraum nicht mehr sichtbar ist.
Data Access (DA) | (*~ (OPC:1:available) *) | Aktiviert eine Variable für OPC UA, woraufhin diese im UA‑Namensraum sichtbar wird. Dieses Tag muss immer gesetzt sein, wenn eine Variable für UA verwendet werden soll.
Data Access (DA) | (*~ (OPC_PROP[0005]:1:Schreibgeschützt) *) | Setzt den Schreibschutz für eine Variable. Muss zusammen mit (*~ (OPC:1: available) *) verwendet werden.
Data Access (DA) | (*~ (OPC_UA_PROP[5100] : x: Alias name) *) | Bestimmt x als Knotennamen im UA‑Namensraum, sogenanntes Alias Mapping.
Historical Access (HA) | (*~ (OPC_UA_PROP[5000]:x:Storage media) *) | Aktiviert eine Variable für „Historical Access“. Muss zusammen mit (*~ (OPC:1: available) *) verwendet werden. x definiert das Speichermedium für die Speicherung der Datenwerte: 1 = Speicher 2 = Datei 3 = SQL Compact Database 4 = SQL Server Database
Historical Access (HA) | (*~ (OPC_UA_PROP[5000][1]:x:SamplingRate) *) | Legt die Abtastrate fest, mit der die Variablenwerte zu speichern sind, in Abhängigkeit des Parameters „x“ in [ms]
Historical Access (HA) | (*~ (OPC_UA_PROP[5000][2]:x:Buffer) *) | Definiert die maximale Anzahl Werte, die im Datenspeicher bleiben, in Abhängigkeit des Parameters „x“.


StatusCode

Technische Einführung [image] Server [image] SPS [image] StatusCode
StatusCode
Der OPC UA Server ermöglicht einer SPS-Anwendung die Änderung des OPC UA StatusCode.
Führen Sie die folgenden Schritte aus, um den StatusCode einer Variablen zu konfigurieren und auf diesen einzuwirken:
▪
SPS-Struktur erstellen
▪
StatusCode überschreiben
SPS-Struktur erstellen
Damit die Datenkonsistenz gewährleistet ist, basiert das Konzept der Änderung des OPC UA StatusCode auf StructuredTypes (siehe StructuredTypes). Jede Variable, auf deren UA StatusCode eingewirkt werden soll, muss in ein STRUCT eingeschlossen sein.
Erzeugen Sie ein neues STRUCT und fügen Sie ein SPS-Attribut vor der STRUCT-Definition hinzu. Das STRUCT enthält die Variable selbst und eine Variable vom Datentyp DINT, die den StatusCode darstellt und auf die im Attribut vor der STRUCT‑Definition verwiesen wird.
{attribute 'OPC.UA.DA.STATUS' := 'quality'}
TYPE ST_StatusCodeOverride :
STRUCT
value : REAL;
quality: DINT;
END_STRUCT
END_TYPE
Erstellen Sie nun eine Instanz von diesem STRUCT, z. B. im MAIN-Programm, und fügen Sie das reguläre SPS-Attribut hinzu, damit die Instanz über OPC UA verfügbar wird.
PROGRAM MAIN
VAR
{attribute 'OPC.UA.DA' := '1'}
stStatusCodeOverride : ST_StatusCodeOverride;
END_VAR
Diese Instanz ist nun innerhalb des OPC‑UA‑Namensraums als ein StructuredType verfügbar.
StatusCode überschreiben
Um den UA StatusCode für das STRUCT zu überschreiben, bearbeiten Sie einfach den Wert der Variablen „quality“. Wenn Sie diesen z. B. auf „-2147155968“ setzen, ändert sich der StatusCode des STRUCT zu „BadCommunicationError“.
Der Wert muss entsprechend der Definition in der OPC‑UA‑Spezifikation festgelegt werden.
In der nachfolgenden Tabelle werden nur einige der verfügbaren StatusCodes und deren entsprechende dezimale Darstellung aufgelistet. Konsultieren Sie die offizielle OPC‑UA‑Spezifikation für eine umfassendere Liste der StatusCodes.
StatusCode | Hex | Decimal
BadUnexpectedError | 0x80010000 | -2147418112
BadInternalError | 0x80020000 | -2147352576
BadCommunicationError | 0x80050000 | -2147155968
BadTimeout | 0x800A0000 | -2146828288
BadServiceNotSupported | 0x800B0000 | -2146762752
UA StatusCodes
Beachten Sie bei der Berechnung der dezimalen Darstellung anderer UA StatusCodes auf der Grundlage ihrer hexadezimalen Darstellung, dass Ihr Rechner auf DWORD eingestellt ist, z. B. der Windows-Rechner („Programmierer“-Ansicht).


C++

Technische Einführung [image] Server [image] C++
C++
Weiterführende Informationen
•
Zugriff auf C++-Laufzeit
•
Historical Access
•
Alarms and Conditions
•
Methodenaufruf
•
StructuredTypes
•
Liste der Attribute und Kommentare


Zugriff auf C++-Laufzeit

Technische Einführung [image] Server [image] C++ [image] Zugriff auf C++-Laufzeit
Zugriff auf C++-Laufzeit
In diesem Abschnitt wird beschrieben, wie Sie den Namensraum des TwinCAT OPC UA Servers konfigurieren, um Zugriff auf die Symbole eines TwinCAT‑3‑C++‑Moduls zu erhalten. Hierzu können Sie entweder den OPC‑UA‑Konfigurator verwenden oder die Konfiguration direkt in der Datei ServerConfig.xml des OPC UA Servers vornehmen.
Dieser Abschnitt beinhaltet folgende Themen:
▪
Schritt 1: Projektbezogene Einstellungen
▪
Schritt 2: UA-Server konfigurieren
Schritt 1: Projektbezogene Einstellungen
Um bestimmte, in einer Instanz eines C++‑Moduls enthaltene Symbole so zu konfigurieren, dass sie über OPC UA zugänglich werden, sind folgende Einstellungen in der entsprechenden C++-Modulinstanz in TwinCAT XAE erforderlich.
1.
Der OPC UA Server benötigt die TMI‑Symboldatei, die standardmäßig nicht an die Ziel-Laufzeit übergeben wird. Aktivieren Sie die Übertragung durch Setzen der folgenden Optionen:
⇨
Die erzeugte TMI-Datei wird nach der Object Id benannt, z. B. „Obj_01010020.tmi“ und in das TwinCAT‑Bootverzeichnis, z. B. C:\TwinCAT\Boot\Tmi\, abgelegt.
2.
Legen Sie fest, welche Symbole für die entsprechenden Variablen zugänglich gemacht werden sollen, indem Sie das Kontrollkästchen Create symbol im TMC-Code-Generator aktivieren. Führen Sie den TMC-Code-Generator anschließend aus.
Schritt 2: UA Server konfigurieren
Sie können den Zugang zu TwinCAT‑3‑C++‑Modulen einfach mithilfe des OPC‑UA‑Konfigurators konfigurieren und parametrisieren. Fügen Sie hierzu im Bereich Datenzugriff ein neues Gerät vom Typ „CPP TwinCAT 3 (TMI) gefiltert“ hinzu.
Das Feld SymbolFile muss auf die TMI-Datei zeigen, die für die C++‑Modulinstanz erzeugt wurde. Diese TMI-Datei befindet sich im TwinCAT‑Bootverzeichnis, z. B. C:\TwinCAT\Boot\Tmi\, und wurde nach der ObjectID der TwinCAT‑3‑C++‑Modulinstanz benannt.
Die einstellbaren Parameter beschreiben die folgenden Funktionen:
Parameter | Beschreibung | Mögliche Werte
ADS Port | Definiert den ADS-Port, unter dem die C++‑Modulinstanz zugänglich ist. Der ADS-Port kann in den Eigenschaften des C++-Tasks gelesen werden. | 351 352 …
AutoCfg | Definiert zunächst den Typ der für die Kommunikation verwendeten Ziel-Laufzeit, z. B. SPS, C++, I/O. Anschließend kann eine weitergehende Unterscheidung innerhalb dieser Kategorien stattfinden. Jede AutoCfg‑Option steht sowohl als ungefilterte, als auch gefilterte Option zur Verfügung. Gefiltert bedeutet, dass der Nutzer bestimmen kann, welche C++‑Symbole über OPC UA öffentlich zugänglich gemacht werden. Bei Verwendung einer ungefilterten Option wird jedes C++-Symbol an OPC UA veröffentlicht. | 4020 CPP TwinCAT 3 (TMI) 4021 CPP TwinCAT 3 (TMI) gefiltert
AutoCfgSymFile | Symboldatei (TMI) der entsprechenden C++‑Modulinstanz. | Pfad zur Symboldatei. (TMI)
IoMode | Definiert die Methode für den Zugriff auf Symbole. | 1 (Zugriff über Handle - standardmäßig)
ArraySubItemLegacySupport | Unterelemente eines Array werden standardmäßig nicht als separate Knoten im UA-Namensraum abgebildet. Stattdessen wird lediglich das Array als ein einzelnes Element abgebildet. Nichtsdestotrotz können UA Clients über deren sogenannten „IndexRange“ auf Unterelemente zugreifen. (Einige ältere OPC UA Clients unterstützen diese Möglichkeit noch nicht.) Das Flag wurde eingeführt, damit der Zugriff dennoch für diese Clients möglich wird. Es sorgt dafür, dass jede Array-Position als separater Knoten im UA‑Namensraum angezeigt wird. Dies führt zu einem höheren Speicherbedarf des OPC UA Servers. | 0 (deaktiviert - standardmäßig) 1 (aktiviert)
Disabled | Deaktiviert die C++‑Modulinstanz im UA‑Namensraum, woraufhin der entsprechende Knoten nicht angezeigt wird. Es wird empfohlen, diesen Parameter zu aktivieren, wenn bestimmte C++‑Laufzeiten zum Zeitpunkt der Projektplanung noch nicht verfügbar sind, weil z. B. die entsprechenden Geräte noch nicht ans Netzwerk angeschlossen sind. | 0 (deaktiviert - standardmäßig) 1 (aktiviert)


Historical Access

Technische Einführung [image] Server [image] C++ [image] Historical Access
Historical Access
Weiterführende Informationen
•
Setup-Version 4.x.x
•
Historische Daten anzeigen


Setup-Version 4.x.x

Technische Einführung [image] Server [image] C++ [image] Historical Access [image] Setup-Version 4.x.x
Setup-Version 4.x.x
Ab Setup-Version 4.x.x wird Historical Access nicht mehr über Attribute bzw. Kommentare konfiguriert. Dies hat den Vorteil, dass die Historical-Access-Funktionalität nun auch für Laufzeiten zur Verfügung steht, die diese bisher nicht unterstützt haben, z. B. Variablen von einem BC9191 Controller. Des Weiteren kann eine Historical‑Access‑Konfiguration nun auch nachträglich, d. h. ohne Anpassung des SPS-Projekts durchgeführt werden.
Die Historical‑Access‑Konfiguration ist nun XML-basiert (TcUaHaConfig.xml) und kann über den OPC-UA-Server-Konfigurator vorgenommen werden. Die XML-Datei befindet sich in demselben Verzeichnis wie die TcOpcUaServer.exe.
Siehe auch:
▪
Konfiguration > Setup-Version 4.x.x > Übersicht (OPC-UA-Server-Konfigurator) und Historical Access konfigurieren)
Aufbau XML-Datei (TCUaHaConfig.xml)
<HistoryConfig>
<HistoryController>
<HistoryAdapter Type="Volatile" Id="0" File="" Server="" Database="" User="" Password=""/>
<HistoryAdapter Type="File" Id="1" File="historydb.dat" Server="" Database="" User="" Password=""/>
<HistoryAdapter Type="SQL" Id="2" File="" Server="" Database="database123" User="user" Password="pwd"/>
<HistoryAdapter Type="SQLCompact" Id="3" File="historydb.xyz" Server="" Database="" User="" Password=""/>
<HistoryAdapter Type="SQLCompact" Id="4" File="historydb2.xyz" Server="" Database="" User="" Password=""/>
</HistoryController>
<HistoryNodes>
<HistoryNode HistoryWriteable="true" SamplingRate="0" MaxSamples="100000" AdapterId="0" NS="urn:BeckhoffAutomation:Ua:PLC1" NodeId="s=PRG_HA_SingleNode.nMyValue"/>
<HistoryNode HistoryWriteable="true" SamplingRate="0" MaxSamples="100000" AdapterId="0" NS="urn:BeckhoffAutomation:Ua:PLC1" NodeId="s=PRG_HA_MultipleNodes.nMyValue1"/>
<HistoryNode HistoryWriteable="true" SamplingRate="0" MaxSamples="100000" AdapterId="0" NS="urn:BeckhoffAutomation:Ua:PLC1" NodeId="s=PRG_HA_MultipleNodes.nMyValue2"/>
<HistoryNode HistoryWriteable="true" SamplingRate="0" MaxSamples="100000" AdapterId="0" NS="urn:BeckhoffAutomation:Ua:PLC1" NodeId="s=PRG_HA_MultipleNodes.fMyValue3"/>
</HistoryNodes>
</HistoryConfig>
In dem Bereich HistoryController können Sie alle unterstützten Datenspeicher konfigurieren. Aktuell werden die folgenden Speicherorte unterstützt:
▪
Arbeitsspeicher („Volatile“)
▪
Datei („File“)
▪
SQL Compact
▪
SQL Server (wird nicht unter Windows CE unterstützt)
Jeder HistoryAdapter (außer „Volatile“) kann hierbei mehrfach verwendet werden, z. B. wenn die historischen Werte für einzelne Variablen in unterschiedlichen Datenspeichern abgelegt werden sollen.
Im Bereich HistoryNodes werden die einzelnen Nodes konfiguriert, einem Datenspeicher zugewiesen und mit einer SamplingRate sowie einer maximalen Größe für den zu verwendenden Ringbuffer im Datenspeicher versehen.
Das Attribut HistoryWriteable="true" bewirkt, dass der Datenspeicher für diese Node über einen Aufruf HistoryUpdate() mit Werten befüllt werden kann. Ein solcher Aufruf wird z. B. von dem TwinCAT OPC UA Client über den Funktionsbaustein UA_HistoryUpdate zur Verfügung gestellt. Wenn Sie einen Node mit diesem Attribut konfigurieren, dann „sampled“ der Server die Werte üblicherweise nicht selbst, sondern bekommt diese von anderen Clients gereicht. Die SamplingRate ist daher bei einer solchen Konfiguration üblicherweise gleich 0.
Voraussetzungen
Produkte | Setup-Versionen | Zielplattform
TF6100 | 4.x.x | IPC oder CX (x86, x64, ARM)


Historische Daten anzeigen

Technische Einführung [image] Server [image] C++ [image] Historical Access [image] Historische Daten anzeigen
Historische Daten anzeigen
Historical-Access-Werte in einem OPC UA Client anzeigen
Die folgende Schritt-für-Schritt-Anleitung beschreibt, wie Sie die UA-Expert-Software konfigurieren, um auf historische Daten zuzugreifen.
1.
Starten Sie die UA-Expert-Software und stellen Sie eine Verbindung mit dem OPC UA Server her.
2.
Fügen Sie eine neue „History Trend Ansicht“ hinzu.
3.
Durchsuchen Sie den PLC1-Namensraum und fügen Sie die SPS-Variablen _HistoryDB, _HistoryDBcompact, _HistoryFast und _HistorySlowPersist per Drag-and-drop hinzu.
⇨
Sie können nun den gewünschten Zeitraum, für den die Symbolwerte angezeigt werden sollen, mithilfe der Steuerelemente Start Time und End Time festlegen, oder falls erforderlich ein Cyclic Update für diese Variablen starten.


Alarms and Conditions

Technische Einführung [image] Server [image] C++ [image] Alarms and Conditions
Alarms and Conditions
In diesem Abschnitt werden die notwendigen Schritte zur Konfiguration von OPC UA Alarms and Conditions (A&C) auf dem OPC UA Server beschrieben. Das Grundkonzept ist unabhängig von der TwinCAT‑Laufzeit. Demzufolge sind die Konfigurationsschritte für SPS, C++, TcCOM-Laufzeit oder nur I/O-Task gleich.
OPC UA Alarms and Conditions (Teil 9 der OPC-UA-Spezifikation) beschreibt ein Modell für die Überwachung von Prozesswerten und das Ausgeben von Alarmen und Ereignissen bei Zustandsänderungen eines Laufzeit-Symbols.
Voraussetzungen
Die folgenden Voraussetzungen gelten für die Verwendung von OPC UA Alarms and Conditions:
▪
Das zu überwachende Laufzeitsymbol muss im Namensraum verfügbar sein.
▪
Der OPC UA Client muss Alarms and Conditions unterstützen. In diesem Abschnitt wird der UA Expert (von Unified Automation) als Referenz‑UA‑Client verwendet.
Allgemeine Informationen
Führen Sie die folgenden Schritte einmalig aus, um ein Symbol für Alarms and Conditions freizugeben:
▪
Schritt 1: Laufzeitsymbol für Datenzugriff aktivieren (damit das Symbol generell via OPC UA zugänglich wird.)
▪
Schritt 2: A&C für ein Symbol aktivieren
▪
Schritt 3: Eigene Benutzerdaten mit einem Ereignis übermitteln
▪
Schritt 4: Ereignis über die FireEvent-Methode auslösen
▪
Schritt 5: Mehrsprachige Alarmtexte konfigurieren
▪
Schritt 6: A&C bei einem Referenz-OPC-UA-Client anmelden
Diese Schritte werden nachfolgend ausführlicher erläutert. Am Ende des Abschnitts finden Sie Informationen zum Empfang von konfigurierten Alarmen über A&C mit dem UA‑Expert‑Referenz‑Client.
Unterstützte Alarmtypen
Die Implementierung von OPC UA Alarms and Conditions unterstützt derzeit die folgenden Alarmtypen:
▪
LimitAlarmType: Verschiedene Grenzen für ein Symbol definieren. Wird eine Grenze erreicht, gibt der UA Server einen Alarm aus.
▪
OffNormalAlarmType: Einen Wert definieren, der „normal“ ist. Wenn der aktuelle Wert vom „normalen“ Wert abweicht, gibt der UA Server einen Alarm aus.
Schritt 1: Laufzeitsymbol für Datenzugriff aktivieren
Damit eine Variable für A&C konfiguriert werden kann, muss diese im OPC UA Server zur Verfügung stehen. Im Falle einer SPS‑Variablen versehen Sie diese dazu mit einem Attribut (siehe Zugriff auf SPS-Laufzeit).
Schritt 2: A&C für ein Symbol aktivieren
Mit dem OPC-UA-Server-Konfigurator können Sie ein Laufzeitsymbol für A&C konfigurieren. Der Konfigurator hat eine einfache grafische Bedienoberfläche, um die dahinter stehende XML-Datei zu bearbeiten. Der Konfigurator steht, je nach Setup-Version, in zwei Varianten zur Verfügung: Standalone und integriert in das Visual Studio.
Der folgende Programmausschnitt zeigt ein Beispiel dieser XML-Datei, um das allgemeine Verhalten und den Aufbau der A&C-Implementierung besser zu verstehen.
<TcUaAcConfig>
<ConditionController Name="ConditionController1" >
<Condition Name="Counter" Severity="200">
<LimitAlarmType LowLowLimit="-10" LowLimit="0" HighLimit="10" HighHighLimit="20" MessageNormal="100" MessageLowLow="10" MessageLow="11" MessageHigh="12" MessageHighHigh="13"/>
<ItemToMonitor SamplingRate="100" NS="urn:[NodeName]:BeckhoffAutomation:Ua:PLC1" NodeId="s=MAIN.nCounter1" />
</Condition>
<Condition Name="Switch" Severity="500">
<OffNormalAlarmType Normal="0" MessageNormal="100" MessageOffNormal="20" />
<ItemToMonitor SamplingRate="100" NS="urn:[NodeName]:BeckhoffAutomation:Ua:PLC1" NodeId="s=MAIN.bSwitch" />
</Condition>
<Condition Name="Struct" Severity="300">
<LimitAlarmType LowLowLimit="-10" LowLimit="0" HighLimit="10" HighHighLimit="20" MessageNormal="100" MessageLowLow="10" MessageLow="11" MessageHigh="12" MessageHighHigh="13"/>
<ItemToMonitor SamplingRate="100" NS="urn:[NodeName]:BeckhoffAutomation:Ua:PLC1" NodeId="s=MAIN.stStruct" />
</Condition>
</ConditionController>
<ConditionController Name="ConditionController2" >
<Condition Name="Counter2" Severity="200">
<LimitAlarmType LowLowLimit="-10" LowLimit="0" HighLimit="10" HighHighLimit="20" MessageNormal="100" MessageLowLow="10" MessageLow="11" MessageHigh="12" MessageHighHigh="13"/>
<ItemToMonitor SamplingRate="100" NS="urn:[NodeName]:BeckhoffAutomation:Ua:PLC1" NodeId="s=MAIN.nCounter2" />
</Condition>
</ConditionController>
</TcUaAcConfig>
Eine „Bedingung“ definiert das zu überwachende Laufzeitsymbol und die Alarmgrenzen und -texte. Jede Bedingung ist in einem sogenannten „ConditionController“ organisiert, dem Objekt, das die OPC UA Clients später abonnieren.
Bei der Erstellung einer Bedingung (Condition) müssen der NamespaceName (NS) und die NodeID spezifiziert werden, um auf den zu überwachenden UA-Knoten zu verweisen. Der Konfigurator bietet einen einfachen Browsing-Mechanismus, um einen Knoten auszuwählen. In XML kann durch den Platzhalter [NodeName] in NamespaceName die XML-Datei einfach zwischen zwei verschiedenen Hardwaresystemen hin und her wechseln. NamespaceName beinhaltet immer den Hostnamen des IPC oder Embedded-PC, auf dem der OPC UA Server läuft. Wird [NodeName] gewählt, wird dieser Tag durch den Hostnamen des aktuellen IPCs oder Embedded-PCs ersetzt, auf dem der UA Server läuft.
Die SamplingRate bestimmt, wie oft der UA Server einen Wert vom Knoten abfragen soll, um festzustellen, ob eine der Alarmgrenzen erreicht wurde.
Die Alarmtexte werden über eine ID identifiziert. Die ID identifiziert eindeutig einen Alarmtext aus der Ressourcendatei (siehe Schritt 5: Mehrsprachige Alarmtexte konfigurieren).
Schritt 3: Eigene Benutzerdaten mit einem Alarm übermitteln
Alarme können Felder mit eigenen Benutzerdaten enthalten, die die mit dem Alarm ausgegebenen Daten ergänzen. Diese Benutzerdatenfelder können Sie in der Laufzeitanwendung erzeugen und ausfüllen. Erstellen Sie dazu ein STRUCT und nennen Sie dessen erstes Element „value“. Bei einem Alarm werden dann alle folgenden Elemente in einem zusätzlichen Benutzerdatenfeld gesendet.
Beispiel SPS-Anwendung:
TYPE ST_CustomStruct :
STRUCT
value : INT;
data : ST_SomeStruct;
END_STRUCT
END_TYPE

TYPE ST_SomeStruct :
STRUCT
Data1 : INT;
Data2 : REAL;
Data3 : LREAL;
END_STRUCT
END_TYPE
Die Instanz von ST_CustomStruct wird über den regulären Mechanismus, z. B. in TwinCAT 3, für den Datenzugriff aktiviert. Das STRUCT muss dazu als StructuredType aktiviert sein.
PROGRAM MAIN
VAR
{attribute 'OPC.UA.DA' := '1'}
{attribute 'OPC.UA.DA.StructuredType' := '1'}
stCustomStruct : ST_CustomStruct;
END_VAR
Bei der Anmeldung bei einem ConditionController müssen die OPC UA Clients besondere AlarmConditionTypes, sogenannte „BkUaLimitAlarmType“ und „BkUaOffNormalAlarmType“, abonnieren, damit sie die besonderen Benutzerdatenfelder beim Eingang eines Alarms empfangen können.
Der OPC UA Client empfängt dann die Benutzerdaten in den Feldern BkUaEventData und BkUaEventValue des eingehenden Alarms. Im obigen Beispiel sind das der Wert der SPS-Variablen sowie die Benutzerdaten, die mit der SPS-Struktur ST_SomeStruct dargestellt werden.
Grafik aus Alarms _ Conditions (i1d631q3.png)
Schritt 4: Ereignis über die FireEvent-Methode auslösen
Jeder ConditionController umfasst eine FireEvent-Methode, mit der die OPC UA Clients ein allgemeines Ereignis mit benutzerdefinierten EventFields auslösen können.
Wenn die Methode ausgeführt wird, dann wird ein Ereignis auf dem OPC UA Server ausgegeben. Andere OPC UA Clients können diese Ereignisse empfangen, wenn sie den entsprechenden ConditionController abonnieren.
Die benutzerdefinierten EventFields werden als „UserEventData“ an das Ereignis angehängt. Diesen Daten können von OPC UA Clients empfangen werden, die beim SimpleEventType „UserEventType“ angemeldet sind.
Schritt 5: Mehrsprachigen Alarmtexten konfigurieren
Die A&C-Implementierung im OPC UA Server unterstützt die Verwendung von mehrsprachigen Alarmtexten. Abhängig von der Sprache, mit der sich der UA Client mit dem Server verbindet, wird ein entsprechender Alarmtext verwendet.
Alarmtexte werden in XML-Dateien konfiguriert, für jede Sprache gibt es eine eigene Datei. Diese Dateien befinden sich im Ordner res (Ressource) des OPC UA Servers. Mit dem Konfigurator können Sie Alarmtexte einfach hinzufügen oder entfernen, ohne dass Sie die XML-Dateien direkt bearbeiten müssen. Jeder Alarmtext hat eine eigene ID, die in der Datei nur einmal vorkommt.
Beispiel:
<TcOpcUaSvrRes Lang="en">
<Text ID="0">Text not available</Text>
<Text ID="1">Some alarm text</Text>
<Text ID="2">Value is High range</Text>
<Text ID="3">Value is HighHigh range</Text>
<Text ID="4">Value is OffNormal</Text>
...
</TcOpcUaSvrRes>
Schritt 6: A&C bei einem Referenz-OPC-UA-Client anmelden
Ein OPC UA Client muss sich bei einem ConditionController anmelden, damit er Ereignisse für Bedingungen empfangen kann, die für diesen besonderen ConditionController konfiguriert sind. Der UA Expert stellt Funktionen zur Verfügung, um UA-Ereignisse zu abonnieren und zu empfangen.
Nachdem Sie den UA Expert gestartet und eine Verbindung zum OPC UA Server hergestellt haben, fügen Sie Ihrem Arbeitsbereich eine neue Dokumentenansicht Event View hinzu.
Sie können einen ConditionController dann durch Ziehen des entsprechenden Objekts in den Event View abonnieren. Die Ereignisse für diesen ConditionController werden im Event Window angezeigt.
Möglicherweise müssen spezielle Alarm- und/oder Ereignistypen abonniert werden, damit Sie alle Felder eines eingehenden Ereignisses oder Alarms empfangen können.


Methodenaufruf

Technische Einführung [image] Server [image] C++ [image] Methodenaufruf
Methodenaufruf
Methodenaufrufe sind ein grundlegender Teil der OPC‑UA‑Spezifikation. Mit der Einführung dieser Funktionalitäten in die SPS-Welt bietet TwinCAT 3 die Möglichkeit zur effizienten Ausführung von RPC-Aufrufen im C++‑Echtzeitkontext und verringert somit die klassischen Handshake‑Pattern bei der Kommunikation zwischen den Geräten. Der OPC UA Server importiert C++‑Methoden wie OPC‑UA‑Methoden über dessen TMI-Import.
Echtzeit-Methode
Auch wenn die C++-Methode eine normale Methode im UA-Namensraum zu sein scheint, ist sie immer noch eine Echtzeit-Methode, die innerhalb des Echtzeit-Kontexts ausgeführt wird und somit unter den Kontext einer Echtzeit-Task fällt. Der TwinCAT-C++-Entwickler muss daher Vorsichtsmaßnahmen treffen, sodass die Ausführungszeit der Methode in die Task-Zykluszeit passt.
Grafik aus Method Call (iu8otbl.png)
Methoden in TwinCAT 3 C++
TwinCAT‑Module können Schnittstellen implementieren, die über vordefinierte Methoden verfügen (siehe TcCOM‑Module). Die Methode selbst muss für RPC-Aufrufe während ihrer Definition aktiviert sein (siehe Dokumentation TwinCAT Module Class Wizard), sodass der OPC UA Server weiß, dass sie zur Ausführung bereitsteht.
Grafik aus Method Call (iilm68u2.png)
Damit auch der Rückgabewert der Methode zur Verfügung steht, muss die entsprechende Option Include Return Value aktiviert sein. Beachten Sie, dass die Schnittstelle, unter der die Methode erstellt wurde, implementiert werden muss.
Grafik aus Method Call (iv8eni22.png)
Gefilterter oder ungefilterter Modus
In Abhängigkeit davon, welcher Importmodus verwendet wird, müssen Sie die Methode für den Zugriff über OPC UA deklarieren. Dies kann durch Verwendung des TMC-Code-Editors und der üblichen OPC‑UA‑Attribute als optionale Eigenschaften erfolgen.
Grafik aus Method Call (ige1dvt3.png)


StructuredTypes

Technische Einführung [image] Server [image] C++ [image] StructuredTypes
StructuredTypes
StructuredTypes erlauben es, Strukturen zu lesen oder zu schreiben ohne dafür jedes Byte zu interpretieren, weil der UA Server den Informationstyp jedes Elements der Struktur zurückgibt. Durch komplexe Funktionen in modernen OPC UA SDKs können OPC UA Clients diese strukturellen Informationen durchsuchen und interpretieren.
Ab Version 2.2.x des OPC UA Servers werden Strukturen von der TwinCAT‑3‑Laufzeit (nur TMC- und TMI-Import) als ein StructuredType im UA‑Namensraum erzeugt.
Beispiel:
STRUCT ST_Communication:
TYPE ST_Communication :
STRUCT
a : INT;
b : INT;
c : INT;
END_STRUCT
END_TYPE
Programm MAIN:
PROGRAM MAIN
VAR
{attribute 'OPC.UA.DA' := '1'}
{attribute 'OPC.UA.DA.StructuredType' := '1'}
stCommunication : ST_Communication;
END_VAR
Gefilterter Modus
Werden Filter eingesetzt, um Symbole über OPC UA verfügbar zu machen, muss ein STRUCT oder Funktionsbaustein im UA‑Namensraum voll verfügbar sein, um als StructuredType angezeigt zu werden.
Pointer und Referenzen
Werden in der Struktur Pointer- und Referenztypen verwendet, dann können diese nicht in einen StructuredType überführt werden. Der OPC UA Server stellt diese Strukturen dann als reguläre FolderTypes mit der entsprechenden Membervariablen dar.
Die Instanz stCommunication wird dann im UA-Namensraum als StructuredType angezeigt:
Alternativ kann die STRUCT-Definition auch das SPS Attribut erhalten, um alle Instanzen von STRUCT als StructuredType verfügbar zu machen.
{attribute 'OPC.UA.DA.StructuredType' := '1'}
TYPE ST_Communication :
STRUCT
a : INT;
b : INT;
c : INT;
END_STRUCT
END_TYPE
Um StructuredType einer bestimmten Instanz zu deaktivieren, verwenden Sie das folgende Attribut:
PROGRAM MAIN
VAR
{attribute 'OPC.UA.DA' := '1'}
{attribute 'OPC.UA.DA.StructuredType' := '0'}
stCommunication : ST_Communication;
END_VAR
Funktionsbaustein StructuredType
Zusätzlich enthält jeder Funktionsbaustein der TwinCAT 3 SPS auch einen Kindknoten FunctionBlock, der den gesamten Funktionsbaustein als StructuredType beinhaltet.
Beispiel:
Funktionsbaustein:
FUNCTION_BLOCK FB_FunctionBlock
VAR_INPUT
Input1 : INT;
Input2 : LREAL;
END_VAR
VAR_OUTPUT
Output1 : LREAL;
END_VAR
Instanz des Funktionsbausteins:
PROGRAM MAIN
VAR
{attribute 'OPC.UA.DA' := '1'}
{attribute 'OPC.UA.DA.StructuredType' := '1'}
fbFunctionBlock : FB_FunctionBlock;
END_VAR
Instanz des Funktionsbausteins im OPC‑UA‑Namensraum:
FunctionBlock-Knoten mit StructuredType:
Alternativ kann der Funktionsbaustein auch ein SPS-Attribut erhalten, um alle Instanzen des Funktionsbausteins als StructuredType zur Verfügung zu stellen.
{attribute 'OPC.UA.DA.StructuredType' := '1'}
FUNCTION_BLOCK FB_FunctionBlock
VAR_INPUT
Input1 : INT;
Input2 : LREAL;
END_VAR
VAR_OUTPUT
Output1 : LREAL;
END_VAR
Um StructuredType einer bestimmten Instanz zu deaktivieren, verwenden Sie das folgende Attribut:
PROGRAM MAIN
VAR
{attribute 'OPC.UA.DA' := '1'}
{attribute 'OPC.UA.DA.StructuredType' := '0'}
fbFunctionBlock : FB_FunctionBlock;
END_VAR
Maximale Größe der Struktur
Die maximale Größe einer Struktur ist standardmäßig auf 16 kByte festgelegt. Jedes STRUCT tauscht ständig Daten mit dem Basis-ADS-Gerät aus, d. h. mit jedem Lese-/Schreibbefehl eines StructuredTypes wird eine große ADS-Meldung verschickt. Damit der ADS-Router nicht mit großen Meldungen überflutet wird, ist die maximale Größe beschränkt. Sie können diese Vorgabe in der Datei ServerConfig.xml ändern. Dazu muss der Schlüssel <MaxStructureSize> zu OpcServerConfig\UaServerConfig\ hinzugefügt und ein neuer Wert für die maximale Größe einer Struktur in Bytes festgelegt werden. Wenn eine Struktur die Größe <MaxStructureSize> überschreitet, wird sie als FolderType importiert, wo jedes Strukturelement als einzelner Knoten verfügbar ist.


Liste der Attribute und Kommentare

Technische Einführung [image] Server [image] C++ [image] Liste der Attribute und Kommentare
Liste der Attribute und Kommentare
Die Laufzeitvariablen für verschiedene OPC-UA-Funktionen (z. B. Data Access oder Historical Access) konfigurieren Sie direkt im SPS-Programm oder im TMC-Code-Editor (bei Verwendung von TwinCAT 3 C++). Der Vorteil ist, dass ein SPS-Entwickler direkt in dem Programm, mit dem er vertraut ist, entscheiden kann, ob und wie eine Variable für OPC UA freizugeben ist. Sie aktivieren eine Variable, indem Sie einen Kommentar und das entsprechenden OPC-UA-Tags vor der Variablen einfügen, z. B.:
TwinCAT 3 SPS (TMC):
{attribute 'OPC.UA.DA' := '1'}
bVariable : BOOL;
TwinCAT 2 SPS (TPY):
bVariable : BOOL; (*~ (OPC:1:available)*)
Eine detaillierte Beschreibung zur Verwendung von Attributen und Kommentaren erhalten Sie in den Abschnitten über die entsprechenden Laufzeitkomponenten:
▪
SPS
▪
C++
▪
I/O
▪
Matlab/Simulink
Die folgende Tabelle zeigt einen Überblick aller definierbaren Tags und ihrer Bedeutung. In den Unterschnitten der entsprechenden Funktion finden Sie eine ausführliche Beschreibung des Funktionsprinzips.
TwinCAT 3 (TMC):
OPC-UA-Funktion | SPS-Tag | C++ TMC-Code-Editor (Optionale Eigenschaften) | Bedeutung
Data Access (DA) | {attribute 'OPC.UA.DA' := '0'} | Name: OPC.UA.DA Wert: 0 | Sperrt eine Variable für OPC UA, woraufhin diese im UA‑Namensraum nicht mehr sichtbar ist.
Data Access (DA) | {attribute 'OPC.UA.DA' := '1'} | Name: OPC.UA.DA Wert: 1 | Aktiviert eine Variable für OPC UA, woraufhin diese im UA‑Namensraum sichtbar wird. Dieses Tag muss immer gesetzt sein, wenn eine Variable für UA verwendet werden soll.
Data Access (DA) | {attribute 'OPC.UA.DA.Access' := 'x'} | Name: OPC.UA.DA.Access Wert: siehe rechte Spalte | Setzt Lese-/Schreib-Zugriff für eine Variable, je nach Parameter „x“. 0 = Kein 1 = Schreibgeschützt 2 = Nur Schreibzugriff 3 = Lese- und Schreibzugriff (Standardwert, wenn kein Tag verwendet wird)
Data Access (DA) | {attribute 'OPC.UA.DA.Description' := 'x'} | Name: OPC.UA.DA.Description Wert: siehe rechte Spalte | Setzt einen Text für das OPC-UA-Attribut „Description“.
Data Access (DA) | {attribute 'OPC.UA.DA.StructuredType' := '0'} | Name: OPC.UA.DA.StructuredType Wert: 0 | Deaktiviert StructuredType für ein STRUCT oder einen Funktionsbaustein
Data Access (DA) | {attribute 'OPC.UA.DA.StructuredType' := '1'} | Name: OPC.UA.DA.StructuredType Wert: 1 | Aktiviert StructuredType für ein STRUCT oder einen Funktionsbaustein
Data Access | {attribute 'OPC.UA.DA.Status' := 'quality'} | Name: OPC.UA.DA.Status Wert: quality | StatusCode eines Symbols im UA‑Namensraum manuell festlegen. Nur für Datenstrukturen. Der Wert „quality“ legt fest, welches DINT Unterelement der Datenstruktur den StatusCode festlegt. Siehe entsprechenden Artikel der Dokumentation für weitere Informationen.
Historical Access (HA) | {attribute 'OPC.UA.HA' := '1'} | Name: OPC.UA.HA Wert: 1 | Aktiviert eine Variable für Historical Access. Muss mit {attribute 'OPC.UA.DA' := '1'} verwendet werden.
Historical Access (HA) | {attribute 'OPC.UA.HA.Storage' := 'x'} | Name: OPC.UA.HA.Storage Wert: siehe rechte Spalte | Definiert den Speicherort für Historical Access, abhängig von Parameter “x” 1 = Speicher 2 = Datei 3 = SQL Compact Database 4 = SQL Server Database
Historical Access (HA) | {attribute 'OPC.UA.HA.Sampling' := 'x'} | Name: OPC.UA.HA.Sampling Wert: siehe rechte Spalte | Legt die Abtastrate fest, mit der die Variablenwerte zu speichern sind, in Abhängigkeit des Parameters „x“ in [ms]
Historical Access (HA) | {attribute 'OPC.UA.HA.Buffer' := 'x'} | Name: OPC.UA.HA.Buffer Wert: siehe rechte Spalte | Definiert die maximale Anzahl Werte, die im Datenspeicher bleiben, in Abhängigkeit des Parameters „x“.
TwinCAT 2 (TPY):
OPC‑UA‑Funktion | SPS‑Tag | Bedeutung
Data Access (DA) | (*~ (OPC:0:not available) *) | Sperrt eine Variable für OPC UA, woraufhin diese im UA‑Namensraum nicht mehr sichtbar ist.
Data Access (DA) | (*~ (OPC:1:available) *) | Aktiviert eine Variable für OPC UA, woraufhin diese im UA‑Namensraum sichtbar wird. Dieses Tag muss immer gesetzt sein, wenn eine Variable für UA verwendet werden soll.
Data Access (DA) | (*~ (OPC_PROP[0005]:1:Schreibgeschützt) *) | Setzt den Schreibschutz für eine Variable. Muss zusammen mit (*~ (OPC:1: available) *) verwendet werden.
Data Access (DA) | (*~ (OPC_UA_PROP[5100] : x: Alias name) *) | Bestimmt x als Knotennamen im UA‑Namensraum, sogenanntes Alias Mapping.
Historical Access (HA) | (*~ (OPC_UA_PROP[5000]:x:Storage media) *) | Aktiviert eine Variable für „Historical Access“. Muss zusammen mit (*~ (OPC:1: available) *) verwendet werden. x definiert das Speichermedium für die Speicherung der Datenwerte: 1 = Speicher 2 = Datei 3 = SQL Compact Database 4 = SQL Server Database
Historical Access (HA) | (*~ (OPC_UA_PROP[5000][1]:x:SamplingRate) *) | Legt die Abtastrate fest, mit der die Variablenwerte zu speichern sind, in Abhängigkeit des Parameters „x“ in [ms]
Historical Access (HA) | (*~ (OPC_UA_PROP[5000][2]:x:Buffer) *) | Definiert die maximale Anzahl Werte, die im Datenspeicher bleiben, in Abhängigkeit des Parameters „x“.


I/O

Technische Einführung [image] Server [image] I/O
I/O
Weiterführende Informationen
•
Zugriff auf IO-Task
•
Historical Access
•
Alarms and Conditions


Zugriff auf IO-Task

Technische Einführung [image] Server [image] I/O [image] Zugriff auf IO-Task
Zugriff auf IO-Task
In diesem Abschnitt wird beschrieben, wie Sie IO‑Taskvariablen über die Datenzugriffsfunktionen des TwinCAT OPC UA Servers zugänglich machen.
Dieser Abschnitt beinhaltet folgende Themen:
▪
Allgemeine Informationen
▪
Schritt 1: TwinCAT‑I/O‑Task konfigurieren, um das Symbolhandling zu aktivieren.
▪
Schritt 2: I/O-Task dem OPC‑UA‑Namensraum hinzufügen
Allgemeine Informationen
Sie können die Variablen eines Tasks mit Prozessabbild über OPC UA veröffentlichen.
Die Art und Weise, wie die Variablen angezeigt und wie mit ihnen kommuniziert wird, wird anhand verschiedener Parameter festgelegt. Sie können die Parameter mithilfe des OPC‑UA‑Konfigurators oder direkt in der Konfigurationsdatei ServerConfig.xml festlegen.
Die folgende Tabelle gibt einen Überblick über alle Parameter, die beim Zugriff auf das I/O‑Task von Bedeutung sind:
Parameter | Beschreibung | Mögliche Werte
ADS Port | Definiert den ADS-Port, unter dem das I/O‑Task zugänglich ist. Der ADS Port kann in den Eigenschaften des I/O‑Tasks ausgelesen werden. | 301 302 …
AutoCfg | Definiert zunächst den Typ der für die Kommunikation verwendeten Ziel-Laufzeit, z. B. SPS, C++, I/O. Anschließend kann eine weitergehende Unterscheidung innerhalb dieser Kategorien stattfinden. Jede AutoCfg-Option steht sowohl als ungefilterte, als auch gefilterte Option zur Verfügung. Gefiltert bedeutet, dass die Nutzer bestimmen können, welche I/O‑Variablen dem OPC UA über Kommentare öffentlich zugänglich gemacht werden. Bei Verwendung einer ungefilterten Option wird jede Task‑Variable an OPC UA veröffentlicht. | 107 I/O TwinCAT 2/3 108 I/O TwinCAT 2/3 gefiltert
AutoCfgSymFile | Bestimmt den Pfad der CurrentConfig.xml‑Datei, die sich normalerweise im Ordner C:\TwinCAT\3.1\Boot\ befindet. | Pfad von CurrentConfig.xml
Disabled | Deaktiviert die I/O Task im UA‑Namensraum, woraufhin der entsprechende Knoten nicht angezeigt wird. Wir empfehlen die Aktivierung dieses Parameters wenn bestimmte Laufzeiten zum Zeitpunkt der Projektplanung noch nicht verfügbar sind, weil z. B. die entsprechenden Geräte noch nicht ans Netzwerk angeschlossen sind. | 0 (deaktiviert - standardmäßig) 1 (aktiviert)
Die folgenden Schritte beschreiben, wie Sie Variablen von einem I/O‑Task in den UA-Namensraum importiert können. Hierbei wird vorausgesetzt, dass sich der OPC UA Server und die Laufzeit sich auf dem gleichen Computer befinden.
Schritt 1: TwinCAT‑I/O‑Task konfigurieren, um das Symbolhandling zu aktivieren.
Öffnen Sie die I/O‑Task‑Einstellungen und aktivieren Sie die Option Symbole erzeugen. Notieren Sie an dieser Stelle auch den ADS-Port des I/O‑Tasks (im Beispiel ist das 301).
TwinCAT 3:
TwinCAT 2:
Grafik aus Access to IO task (i8692v52.png)
Schritt 2: I/O‑Task dem OPC-UA-Namensraum hinzufügen
Konfigurieren Sie den OPC UA Server so, dass er Zugriff auf das I/O‑Task bietet. Fügen Sie mithilfe des OPC-UA‑Konfigurators ein neues Gerät „IO TwinCAT 2/3“ hinzu und konfigurieren Sie dessen Einstellungen für AdsNetId, AdsPort und SymbolFile (Pfad zur Datei CurrentConfig.xml).
Starten Sie, nachdem Sie die entsprechenden Eigenschaften eingestellt haben, den OPC UA Server neu, damit die Einstellungen aktiv werden.


Historical Access

Technische Einführung [image] Server [image] I/O [image] Historical Access
Historical Access
Weiterführende Informationen
•
Setup-Version 4.x.x
•
Historische Daten anzeigen


Setup-Version 4.x.x

Technische Einführung [image] Server [image] I/O [image] Historical Access [image] Setup-Version 4.x.x
Setup-Version 4.x.x
Ab Setup-Version 4.x.x wird Historical Access nicht mehr über Attribute bzw. Kommentare konfiguriert. Dies hat den Vorteil, dass die Historical-Access-Funktionalität nun auch für Laufzeiten zur Verfügung steht, die diese bisher nicht unterstützt haben, z. B. Variablen von einem BC9191 Controller. Des Weiteren kann eine Historical‑Access‑Konfiguration nun auch nachträglich, d. h. ohne Anpassung des SPS-Projekts durchgeführt werden.
Die Historical‑Access‑Konfiguration ist nun XML-basiert (TcUaHaConfig.xml) und kann über den OPC-UA-Server-Konfigurator vorgenommen werden. Die XML-Datei befindet sich in demselben Verzeichnis wie die TcOpcUaServer.exe.
Siehe auch:
▪
Konfiguration > Setup-Version 4.x.x > Übersicht (OPC-UA-Server-Konfigurator) und Historical Access konfigurieren)
Aufbau XML-Datei (TCUaHaConfig.xml)
<HistoryConfig>
<HistoryController>
<HistoryAdapter Type="Volatile" Id="0" File="" Server="" Database="" User="" Password=""/>
<HistoryAdapter Type="File" Id="1" File="historydb.dat" Server="" Database="" User="" Password=""/>
<HistoryAdapter Type="SQL" Id="2" File="" Server="" Database="database123" User="user" Password="pwd"/>
<HistoryAdapter Type="SQLCompact" Id="3" File="historydb.xyz" Server="" Database="" User="" Password=""/>
<HistoryAdapter Type="SQLCompact" Id="4" File="historydb2.xyz" Server="" Database="" User="" Password=""/>
</HistoryController>
<HistoryNodes>
<HistoryNode HistoryWriteable="true" SamplingRate="0" MaxSamples="100000" AdapterId="0" NS="urn:BeckhoffAutomation:Ua:PLC1" NodeId="s=PRG_HA_SingleNode.nMyValue"/>
<HistoryNode HistoryWriteable="true" SamplingRate="0" MaxSamples="100000" AdapterId="0" NS="urn:BeckhoffAutomation:Ua:PLC1" NodeId="s=PRG_HA_MultipleNodes.nMyValue1"/>
<HistoryNode HistoryWriteable="true" SamplingRate="0" MaxSamples="100000" AdapterId="0" NS="urn:BeckhoffAutomation:Ua:PLC1" NodeId="s=PRG_HA_MultipleNodes.nMyValue2"/>
<HistoryNode HistoryWriteable="true" SamplingRate="0" MaxSamples="100000" AdapterId="0" NS="urn:BeckhoffAutomation:Ua:PLC1" NodeId="s=PRG_HA_MultipleNodes.fMyValue3"/>
</HistoryNodes>
</HistoryConfig>
In dem Bereich HistoryController können Sie alle unterstützten Datenspeicher konfigurieren. Aktuell werden die folgenden Speicherorte unterstützt:
▪
Arbeitsspeicher („Volatile“)
▪
Datei („File“)
▪
SQL Compact
▪
SQL Server (wird nicht unter Windows CE unterstützt)
Jeder HistoryAdapter (außer „Volatile“) kann hierbei mehrfach verwendet werden, z. B. wenn die historischen Werte für einzelne Variablen in unterschiedlichen Datenspeichern abgelegt werden sollen.
Im Bereich HistoryNodes werden die einzelnen Nodes konfiguriert, einem Datenspeicher zugewiesen und mit einer SamplingRate sowie einer maximalen Größe für den zu verwendenden Ringbuffer im Datenspeicher versehen.
Das Attribut HistoryWriteable="true" bewirkt, dass der Datenspeicher für diese Node über einen Aufruf HistoryUpdate() mit Werten befüllt werden kann. Ein solcher Aufruf wird z. B. von dem TwinCAT OPC UA Client über den Funktionsbaustein UA_HistoryUpdate zur Verfügung gestellt. Wenn Sie einen Node mit diesem Attribut konfigurieren, dann „sampled“ der Server die Werte üblicherweise nicht selbst, sondern bekommt diese von anderen Clients gereicht. Die SamplingRate ist daher bei einer solchen Konfiguration üblicherweise gleich 0.
Voraussetzungen
Produkte | Setup-Versionen | Zielplattform
TF6100 | 4.x.x | IPC oder CX (x86, x64, ARM)


Historische Daten anzeigen

Technische Einführung [image] Server [image] I/O [image] Historical Access [image] Historische Daten anzeigen
Historische Daten anzeigen
Historical-Access-Werte in einem OPC UA Client anzeigen
Die folgende Schritt-für-Schritt-Anleitung beschreibt, wie Sie die UA-Expert-Software konfigurieren, um auf historische Daten zuzugreifen.
1.
Starten Sie die UA-Expert-Software und stellen Sie eine Verbindung mit dem OPC UA Server her.
2.
Fügen Sie eine neue „History Trend Ansicht“ hinzu.
3.
Durchsuchen Sie den PLC1-Namensraum und fügen Sie die SPS-Variablen _HistoryDB, _HistoryDBcompact, _HistoryFast und _HistorySlowPersist per Drag-and-drop hinzu.
⇨
Sie können nun den gewünschten Zeitraum, für den die Symbolwerte angezeigt werden sollen, mithilfe der Steuerelemente Start Time und End Time festlegen, oder falls erforderlich ein Cyclic Update für diese Variablen starten.


Alarms and Conditions

Technische Einführung [image] Server [image] I/O [image] Alarms and Conditions
Alarms and Conditions
In diesem Abschnitt werden die notwendigen Schritte zur Konfiguration von OPC UA Alarms and Conditions (A&C) auf dem OPC UA Server beschrieben. Das Grundkonzept ist unabhängig von der TwinCAT‑Laufzeit. Demzufolge sind die Konfigurationsschritte für SPS, C++, TcCOM-Laufzeit oder nur I/O-Task gleich.
OPC UA Alarms and Conditions (Teil 9 der OPC-UA-Spezifikation) beschreibt ein Modell für die Überwachung von Prozesswerten und das Ausgeben von Alarmen und Ereignissen bei Zustandsänderungen eines Laufzeit-Symbols.
Voraussetzungen
Die folgenden Voraussetzungen gelten für die Verwendung von OPC UA Alarms and Conditions:
▪
Das zu überwachende Laufzeitsymbol muss im Namensraum verfügbar sein.
▪
Der OPC UA Client muss Alarms and Conditions unterstützen. In diesem Abschnitt wird der UA Expert (von Unified Automation) als Referenz‑UA‑Client verwendet.
Allgemeine Informationen
Führen Sie die folgenden Schritte einmalig aus, um ein Symbol für Alarms and Conditions freizugeben:
▪
Schritt 1: Laufzeitsymbol für Datenzugriff aktivieren (damit das Symbol generell via OPC UA zugänglich wird.)
▪
Schritt 2: A&C für ein Symbol aktivieren
▪
Schritt 3: Eigene Benutzerdaten mit einem Ereignis übermitteln
▪
Schritt 4: Ereignis über die FireEvent-Methode auslösen
▪
Schritt 5: Mehrsprachige Alarmtexte konfigurieren
▪
Schritt 6: A&C bei einem Referenz-OPC-UA-Client anmelden
Diese Schritte werden nachfolgend ausführlicher erläutert. Am Ende des Abschnitts finden Sie Informationen zum Empfang von konfigurierten Alarmen über A&C mit dem UA‑Expert‑Referenz‑Client.
Unterstützte Alarmtypen
Die Implementierung von OPC UA Alarms and Conditions unterstützt derzeit die folgenden Alarmtypen:
▪
LimitAlarmType: Verschiedene Grenzen für ein Symbol definieren. Wird eine Grenze erreicht, gibt der UA Server einen Alarm aus.
▪
OffNormalAlarmType: Einen Wert definieren, der „normal“ ist. Wenn der aktuelle Wert vom „normalen“ Wert abweicht, gibt der UA Server einen Alarm aus.
Schritt 1: Laufzeitsymbol für Datenzugriff aktivieren
Damit eine Variable für A&C konfiguriert werden kann, muss diese im OPC UA Server zur Verfügung stehen. Im Falle einer SPS‑Variablen versehen Sie diese dazu mit einem Attribut (siehe Zugriff auf SPS-Laufzeit).
Schritt 2: A&C für ein Symbol aktivieren
Mit dem OPC-UA-Server-Konfigurator können Sie ein Laufzeitsymbol für A&C konfigurieren. Der Konfigurator hat eine einfache grafische Bedienoberfläche, um die dahinter stehende XML-Datei zu bearbeiten. Der Konfigurator steht, je nach Setup-Version, in zwei Varianten zur Verfügung: Standalone und integriert in das Visual Studio.
Der folgende Programmausschnitt zeigt ein Beispiel dieser XML-Datei, um das allgemeine Verhalten und den Aufbau der A&C-Implementierung besser zu verstehen.
<TcUaAcConfig>
<ConditionController Name="ConditionController1" >
<Condition Name="Counter" Severity="200">
<LimitAlarmType LowLowLimit="-10" LowLimit="0" HighLimit="10" HighHighLimit="20" MessageNormal="100" MessageLowLow="10" MessageLow="11" MessageHigh="12" MessageHighHigh="13"/>
<ItemToMonitor SamplingRate="100" NS="urn:[NodeName]:BeckhoffAutomation:Ua:PLC1" NodeId="s=MAIN.nCounter1" />
</Condition>
<Condition Name="Switch" Severity="500">
<OffNormalAlarmType Normal="0" MessageNormal="100" MessageOffNormal="20" />
<ItemToMonitor SamplingRate="100" NS="urn:[NodeName]:BeckhoffAutomation:Ua:PLC1" NodeId="s=MAIN.bSwitch" />
</Condition>
<Condition Name="Struct" Severity="300">
<LimitAlarmType LowLowLimit="-10" LowLimit="0" HighLimit="10" HighHighLimit="20" MessageNormal="100" MessageLowLow="10" MessageLow="11" MessageHigh="12" MessageHighHigh="13"/>
<ItemToMonitor SamplingRate="100" NS="urn:[NodeName]:BeckhoffAutomation:Ua:PLC1" NodeId="s=MAIN.stStruct" />
</Condition>
</ConditionController>
<ConditionController Name="ConditionController2" >
<Condition Name="Counter2" Severity="200">
<LimitAlarmType LowLowLimit="-10" LowLimit="0" HighLimit="10" HighHighLimit="20" MessageNormal="100" MessageLowLow="10" MessageLow="11" MessageHigh="12" MessageHighHigh="13"/>
<ItemToMonitor SamplingRate="100" NS="urn:[NodeName]:BeckhoffAutomation:Ua:PLC1" NodeId="s=MAIN.nCounter2" />
</Condition>
</ConditionController>
</TcUaAcConfig>
Eine „Bedingung“ definiert das zu überwachende Laufzeitsymbol und die Alarmgrenzen und -texte. Jede Bedingung ist in einem sogenannten „ConditionController“ organisiert, dem Objekt, das die OPC UA Clients später abonnieren.
Bei der Erstellung einer Bedingung (Condition) müssen der NamespaceName (NS) und die NodeID spezifiziert werden, um auf den zu überwachenden UA-Knoten zu verweisen. Der Konfigurator bietet einen einfachen Browsing-Mechanismus, um einen Knoten auszuwählen. In XML kann durch den Platzhalter [NodeName] in NamespaceName die XML-Datei einfach zwischen zwei verschiedenen Hardwaresystemen hin und her wechseln. NamespaceName beinhaltet immer den Hostnamen des IPC oder Embedded-PC, auf dem der OPC UA Server läuft. Wird [NodeName] gewählt, wird dieser Tag durch den Hostnamen des aktuellen IPCs oder Embedded-PCs ersetzt, auf dem der UA Server läuft.
Die SamplingRate bestimmt, wie oft der UA Server einen Wert vom Knoten abfragen soll, um festzustellen, ob eine der Alarmgrenzen erreicht wurde.
Die Alarmtexte werden über eine ID identifiziert. Die ID identifiziert eindeutig einen Alarmtext aus der Ressourcendatei (siehe Schritt 5: Mehrsprachige Alarmtexte konfigurieren).
Schritt 3: Eigene Benutzerdaten mit einem Alarm übermitteln
Alarme können Felder mit eigenen Benutzerdaten enthalten, die die mit dem Alarm ausgegebenen Daten ergänzen. Diese Benutzerdatenfelder können Sie in der Laufzeitanwendung erzeugen und ausfüllen. Erstellen Sie dazu ein STRUCT und nennen Sie dessen erstes Element „value“. Bei einem Alarm werden dann alle folgenden Elemente in einem zusätzlichen Benutzerdatenfeld gesendet.
Beispiel SPS-Anwendung:
TYPE ST_CustomStruct :
STRUCT
value : INT;
data : ST_SomeStruct;
END_STRUCT
END_TYPE

TYPE ST_SomeStruct :
STRUCT
Data1 : INT;
Data2 : REAL;
Data3 : LREAL;
END_STRUCT
END_TYPE
Die Instanz von ST_CustomStruct wird über den regulären Mechanismus, z. B. in TwinCAT 3, für den Datenzugriff aktiviert. Das STRUCT muss dazu als StructuredType aktiviert sein.
PROGRAM MAIN
VAR
{attribute 'OPC.UA.DA' := '1'}
{attribute 'OPC.UA.DA.StructuredType' := '1'}
stCustomStruct : ST_CustomStruct;
END_VAR
Bei der Anmeldung bei einem ConditionController müssen die OPC UA Clients besondere AlarmConditionTypes, sogenannte „BkUaLimitAlarmType“ und „BkUaOffNormalAlarmType“, abonnieren, damit sie die besonderen Benutzerdatenfelder beim Eingang eines Alarms empfangen können.
Der OPC UA Client empfängt dann die Benutzerdaten in den Feldern BkUaEventData und BkUaEventValue des eingehenden Alarms. Im obigen Beispiel sind das der Wert der SPS-Variablen sowie die Benutzerdaten, die mit der SPS-Struktur ST_SomeStruct dargestellt werden.
Grafik aus Alarms _ Conditions (i1d631q3.png)
Schritt 4: Ereignis über die FireEvent-Methode auslösen
Jeder ConditionController umfasst eine FireEvent-Methode, mit der die OPC UA Clients ein allgemeines Ereignis mit benutzerdefinierten EventFields auslösen können.
Wenn die Methode ausgeführt wird, dann wird ein Ereignis auf dem OPC UA Server ausgegeben. Andere OPC UA Clients können diese Ereignisse empfangen, wenn sie den entsprechenden ConditionController abonnieren.
Die benutzerdefinierten EventFields werden als „UserEventData“ an das Ereignis angehängt. Diesen Daten können von OPC UA Clients empfangen werden, die beim SimpleEventType „UserEventType“ angemeldet sind.
Schritt 5: Mehrsprachigen Alarmtexten konfigurieren
Die A&C-Implementierung im OPC UA Server unterstützt die Verwendung von mehrsprachigen Alarmtexten. Abhängig von der Sprache, mit der sich der UA Client mit dem Server verbindet, wird ein entsprechender Alarmtext verwendet.
Alarmtexte werden in XML-Dateien konfiguriert, für jede Sprache gibt es eine eigene Datei. Diese Dateien befinden sich im Ordner res (Ressource) des OPC UA Servers. Mit dem Konfigurator können Sie Alarmtexte einfach hinzufügen oder entfernen, ohne dass Sie die XML-Dateien direkt bearbeiten müssen. Jeder Alarmtext hat eine eigene ID, die in der Datei nur einmal vorkommt.
Beispiel:
<TcOpcUaSvrRes Lang="en">
<Text ID="0">Text not available</Text>
<Text ID="1">Some alarm text</Text>
<Text ID="2">Value is High range</Text>
<Text ID="3">Value is HighHigh range</Text>
<Text ID="4">Value is OffNormal</Text>
...
</TcOpcUaSvrRes>
Schritt 6: A&C bei einem Referenz-OPC-UA-Client anmelden
Ein OPC UA Client muss sich bei einem ConditionController anmelden, damit er Ereignisse für Bedingungen empfangen kann, die für diesen besonderen ConditionController konfiguriert sind. Der UA Expert stellt Funktionen zur Verfügung, um UA-Ereignisse zu abonnieren und zu empfangen.
Nachdem Sie den UA Expert gestartet und eine Verbindung zum OPC UA Server hergestellt haben, fügen Sie Ihrem Arbeitsbereich eine neue Dokumentenansicht Event View hinzu.
Sie können einen ConditionController dann durch Ziehen des entsprechenden Objekts in den Event View abonnieren. Die Ereignisse für diesen ConditionController werden im Event Window angezeigt.
Möglicherweise müssen spezielle Alarm- und/oder Ereignistypen abonniert werden, damit Sie alle Felder eines eingehenden Ereignisses oder Alarms empfangen können.


Matlab/Simulink

Technische Einführung [image] Server [image] Matlab/Simulink
Matlab/Simulink
Weiterführende Informationen
•
Zugriff auf Matlab/Simulink-Module
•
Historical Access
•
Alarms and Conditions


Zugriff auf Matlab/Simulink-Module

Technische Einführung [image] Server [image] Matlab/Simulink [image] Zugriff auf Matlab/Simulink-Module
Zugriff auf Matlab/Simulink-Module
In diesem Abschnitt wird beschrieben, wie Sie TwinCAT-3-TMI-Dateien für TcCOM-Module zum Aufbau des Namensraums des OPC UA Servers nutzen.
Dieser Abschnitt beinhaltet folgende Themen:
▪
Allgemeine Informationen
▪
TMI-Datei für TcCom-Module generieren und importieren
▪
Gefilterter oder ungefilterter Modus
Allgemeine Informationen
Wenn Sie TwinCAT 3 C++ oder die Matlab/Simulink-Integration verwenden, können Sie für die entstehenden TcCom-Module aus dem TwinCAT 3 XAE heraus eine Symboldatei (TMI-Datei) generieren.
Diese TMI-Datei importiert der OPC UA Server und erzeugt mit den darin enthaltenen Symbolinformationen seinen Namensraum. Dieser kann dann aus Variablen (=Symbolen) bestehen, die in dem jeweiligen TcCom-Modul enthalten sind.
Sie konfigurieren den Import von TMI-Dateien im OPC‑UA‑Konfigurator.
TMI-Datei für TcCOM-Module generieren und importieren
Damit eine TMI-Datei generiert wird und TwinCAT automatisch die TMI-Datei zum Zielsystem kopieren kann, aktivieren Sie in den Einstellungen des TcCOM-Moduls die Option Copy TMI to Target.
Grafik aus Access to Matlab_Simulink modules (i1sg7jh1.png)
Grafik aus Access to Matlab_Simulink modules (iu98e452.png)
Nach Aktivierung des Projekts enthält das Bootverzeichnis des Zielsystems die TMI-Datei für das TcCOM-Modul. Diese können Sie dann mithilfe des OPC-UA-Konfigurators in den OPC-UA-Namensraum importieren.
Grafik aus Access to Matlab_Simulink modules (i5kqgjs3.png)
Der konfigurierte OPC‑UA‑Namensraum enthält dann eine Repräsentation des Matlab/Simulink‑Blockdiagramms:
Grafik aus Access to Matlab_Simulink modules (i7cvs461.png)
Grafik aus Access to Matlab_Simulink modules (iocmtge2.png)
Gefilterter oder ungefilterter Modus
Beachten Sie, dass es derzeit keinen gefilterten Modus für generische TcCOM-Modulinstanzen gibt. Der gefilterte Modus ist lediglich für TwinCAT‑3‑C++‑Modulinstanzen möglich, wenn der TMC-Code-Editor verwendet wird. Die TwinCAT‑Matlab/Simulink‑Integration bietet einige Filtermöglichkeiten. Diese werden in der Dokumentation TE1400 im Abschnitt Datenaustausch beschrieben.
Wenn eine generische TcCOM‑Modulinstanz (z. B. ein Matlab/Simulink-Modul) importiert werden soll, muss die ungefilterte Option verwendet werden und daher werden alle Symbole der Module im OPC‑UA‑Namensraum veröffentlicht.


Historical Access

Technische Einführung [image] Server [image] Matlab/Simulink [image] Historical Access
Historical Access
Weiterführende Informationen
•
Setup-Version 4.x.x
•
Historische Daten anzeigen


Setup-Version 4.x.x

Technische Einführung [image] Server [image] Matlab/Simulink [image] Historical Access [image] Setup-Version 4.x.x
Setup-Version 4.x.x
Ab Setup-Version 4.x.x wird Historical Access nicht mehr über Attribute bzw. Kommentare konfiguriert. Dies hat den Vorteil, dass die Historical-Access-Funktionalität nun auch für Laufzeiten zur Verfügung steht, die diese bisher nicht unterstützt haben, z. B. Variablen von einem BC9191 Controller. Des Weiteren kann eine Historical‑Access‑Konfiguration nun auch nachträglich, d. h. ohne Anpassung des SPS-Projekts durchgeführt werden.
Die Historical‑Access‑Konfiguration ist nun XML-basiert (TcUaHaConfig.xml) und kann über den OPC-UA-Server-Konfigurator vorgenommen werden. Die XML-Datei befindet sich in demselben Verzeichnis wie die TcOpcUaServer.exe.
Siehe auch:
▪
Konfiguration > Setup-Version 4.x.x > Übersicht (OPC-UA-Server-Konfigurator) und Historical Access konfigurieren)
Aufbau XML-Datei (TCUaHaConfig.xml)
<HistoryConfig>
<HistoryController>
<HistoryAdapter Type="Volatile" Id="0" File="" Server="" Database="" User="" Password=""/>
<HistoryAdapter Type="File" Id="1" File="historydb.dat" Server="" Database="" User="" Password=""/>
<HistoryAdapter Type="SQL" Id="2" File="" Server="" Database="database123" User="user" Password="pwd"/>
<HistoryAdapter Type="SQLCompact" Id="3" File="historydb.xyz" Server="" Database="" User="" Password=""/>
<HistoryAdapter Type="SQLCompact" Id="4" File="historydb2.xyz" Server="" Database="" User="" Password=""/>
</HistoryController>
<HistoryNodes>
<HistoryNode HistoryWriteable="true" SamplingRate="0" MaxSamples="100000" AdapterId="0" NS="urn:BeckhoffAutomation:Ua:PLC1" NodeId="s=PRG_HA_SingleNode.nMyValue"/>
<HistoryNode HistoryWriteable="true" SamplingRate="0" MaxSamples="100000" AdapterId="0" NS="urn:BeckhoffAutomation:Ua:PLC1" NodeId="s=PRG_HA_MultipleNodes.nMyValue1"/>
<HistoryNode HistoryWriteable="true" SamplingRate="0" MaxSamples="100000" AdapterId="0" NS="urn:BeckhoffAutomation:Ua:PLC1" NodeId="s=PRG_HA_MultipleNodes.nMyValue2"/>
<HistoryNode HistoryWriteable="true" SamplingRate="0" MaxSamples="100000" AdapterId="0" NS="urn:BeckhoffAutomation:Ua:PLC1" NodeId="s=PRG_HA_MultipleNodes.fMyValue3"/>
</HistoryNodes>
</HistoryConfig>
In dem Bereich HistoryController können Sie alle unterstützten Datenspeicher konfigurieren. Aktuell werden die folgenden Speicherorte unterstützt:
▪
Arbeitsspeicher („Volatile“)
▪
Datei („File“)
▪
SQL Compact
▪
SQL Server (wird nicht unter Windows CE unterstützt)
Jeder HistoryAdapter (außer „Volatile“) kann hierbei mehrfach verwendet werden, z. B. wenn die historischen Werte für einzelne Variablen in unterschiedlichen Datenspeichern abgelegt werden sollen.
Im Bereich HistoryNodes werden die einzelnen Nodes konfiguriert, einem Datenspeicher zugewiesen und mit einer SamplingRate sowie einer maximalen Größe für den zu verwendenden Ringbuffer im Datenspeicher versehen.
Das Attribut HistoryWriteable="true" bewirkt, dass der Datenspeicher für diese Node über einen Aufruf HistoryUpdate() mit Werten befüllt werden kann. Ein solcher Aufruf wird z. B. von dem TwinCAT OPC UA Client über den Funktionsbaustein UA_HistoryUpdate zur Verfügung gestellt. Wenn Sie einen Node mit diesem Attribut konfigurieren, dann „sampled“ der Server die Werte üblicherweise nicht selbst, sondern bekommt diese von anderen Clients gereicht. Die SamplingRate ist daher bei einer solchen Konfiguration üblicherweise gleich 0.
Voraussetzungen
Produkte | Setup-Versionen | Zielplattform
TF6100 | 4.x.x | IPC oder CX (x86, x64, ARM)


Historische Daten anzeigen

Technische Einführung [image] Server [image] Matlab/Simulink [image] Historical Access [image] Historische Daten anzeigen
Historische Daten anzeigen
Historical-Access-Werte in einem OPC UA Client anzeigen
Die folgende Schritt-für-Schritt-Anleitung beschreibt, wie Sie die UA-Expert-Software konfigurieren, um auf historische Daten zuzugreifen.
1.
Starten Sie die UA-Expert-Software und stellen Sie eine Verbindung mit dem OPC UA Server her.
2.
Fügen Sie eine neue „History Trend Ansicht“ hinzu.
3.
Durchsuchen Sie den PLC1-Namensraum und fügen Sie die SPS-Variablen _HistoryDB, _HistoryDBcompact, _HistoryFast und _HistorySlowPersist per Drag-and-drop hinzu.
⇨
Sie können nun den gewünschten Zeitraum, für den die Symbolwerte angezeigt werden sollen, mithilfe der Steuerelemente Start Time und End Time festlegen, oder falls erforderlich ein Cyclic Update für diese Variablen starten.


Alarms and Conditions

Technische Einführung [image] Server [image] Matlab/Simulink [image] Alarms and Conditions
Alarms and Conditions
In diesem Abschnitt werden die notwendigen Schritte zur Konfiguration von OPC UA Alarms and Conditions (A&C) auf dem OPC UA Server beschrieben. Das Grundkonzept ist unabhängig von der TwinCAT‑Laufzeit. Demzufolge sind die Konfigurationsschritte für SPS, C++, TcCOM-Laufzeit oder nur I/O-Task gleich.
OPC UA Alarms and Conditions (Teil 9 der OPC-UA-Spezifikation) beschreibt ein Modell für die Überwachung von Prozesswerten und das Ausgeben von Alarmen und Ereignissen bei Zustandsänderungen eines Laufzeit-Symbols.
Voraussetzungen
Die folgenden Voraussetzungen gelten für die Verwendung von OPC UA Alarms and Conditions:
▪
Das zu überwachende Laufzeitsymbol muss im Namensraum verfügbar sein.
▪
Der OPC UA Client muss Alarms and Conditions unterstützen. In diesem Abschnitt wird der UA Expert (von Unified Automation) als Referenz‑UA‑Client verwendet.
Allgemeine Informationen
Führen Sie die folgenden Schritte einmalig aus, um ein Symbol für Alarms and Conditions freizugeben:
▪
Schritt 1: Laufzeitsymbol für Datenzugriff aktivieren (damit das Symbol generell via OPC UA zugänglich wird.)
▪
Schritt 2: A&C für ein Symbol aktivieren
▪
Schritt 3: Eigene Benutzerdaten mit einem Ereignis übermitteln
▪
Schritt 4: Ereignis über die FireEvent-Methode auslösen
▪
Schritt 5: Mehrsprachige Alarmtexte konfigurieren
▪
Schritt 6: A&C bei einem Referenz-OPC-UA-Client anmelden
Diese Schritte werden nachfolgend ausführlicher erläutert. Am Ende des Abschnitts finden Sie Informationen zum Empfang von konfigurierten Alarmen über A&C mit dem UA‑Expert‑Referenz‑Client.
Unterstützte Alarmtypen
Die Implementierung von OPC UA Alarms and Conditions unterstützt derzeit die folgenden Alarmtypen:
▪
LimitAlarmType: Verschiedene Grenzen für ein Symbol definieren. Wird eine Grenze erreicht, gibt der UA Server einen Alarm aus.
▪
OffNormalAlarmType: Einen Wert definieren, der „normal“ ist. Wenn der aktuelle Wert vom „normalen“ Wert abweicht, gibt der UA Server einen Alarm aus.
Schritt 1: Laufzeitsymbol für Datenzugriff aktivieren
Damit eine Variable für A&C konfiguriert werden kann, muss diese im OPC UA Server zur Verfügung stehen. Im Falle einer SPS‑Variablen versehen Sie diese dazu mit einem Attribut (siehe Zugriff auf SPS-Laufzeit).
Schritt 2: A&C für ein Symbol aktivieren
Mit dem OPC-UA-Server-Konfigurator können Sie ein Laufzeitsymbol für A&C konfigurieren. Der Konfigurator hat eine einfache grafische Bedienoberfläche, um die dahinter stehende XML-Datei zu bearbeiten. Der Konfigurator steht, je nach Setup-Version, in zwei Varianten zur Verfügung: Standalone und integriert in das Visual Studio.
Der folgende Programmausschnitt zeigt ein Beispiel dieser XML-Datei, um das allgemeine Verhalten und den Aufbau der A&C-Implementierung besser zu verstehen.
<TcUaAcConfig>
<ConditionController Name="ConditionController1" >
<Condition Name="Counter" Severity="200">
<LimitAlarmType LowLowLimit="-10" LowLimit="0" HighLimit="10" HighHighLimit="20" MessageNormal="100" MessageLowLow="10" MessageLow="11" MessageHigh="12" MessageHighHigh="13"/>
<ItemToMonitor SamplingRate="100" NS="urn:[NodeName]:BeckhoffAutomation:Ua:PLC1" NodeId="s=MAIN.nCounter1" />
</Condition>
<Condition Name="Switch" Severity="500">
<OffNormalAlarmType Normal="0" MessageNormal="100" MessageOffNormal="20" />
<ItemToMonitor SamplingRate="100" NS="urn:[NodeName]:BeckhoffAutomation:Ua:PLC1" NodeId="s=MAIN.bSwitch" />
</Condition>
<Condition Name="Struct" Severity="300">
<LimitAlarmType LowLowLimit="-10" LowLimit="0" HighLimit="10" HighHighLimit="20" MessageNormal="100" MessageLowLow="10" MessageLow="11" MessageHigh="12" MessageHighHigh="13"/>
<ItemToMonitor SamplingRate="100" NS="urn:[NodeName]:BeckhoffAutomation:Ua:PLC1" NodeId="s=MAIN.stStruct" />
</Condition>
</ConditionController>
<ConditionController Name="ConditionController2" >
<Condition Name="Counter2" Severity="200">
<LimitAlarmType LowLowLimit="-10" LowLimit="0" HighLimit="10" HighHighLimit="20" MessageNormal="100" MessageLowLow="10" MessageLow="11" MessageHigh="12" MessageHighHigh="13"/>
<ItemToMonitor SamplingRate="100" NS="urn:[NodeName]:BeckhoffAutomation:Ua:PLC1" NodeId="s=MAIN.nCounter2" />
</Condition>
</ConditionController>
</TcUaAcConfig>
Eine „Bedingung“ definiert das zu überwachende Laufzeitsymbol und die Alarmgrenzen und -texte. Jede Bedingung ist in einem sogenannten „ConditionController“ organisiert, dem Objekt, das die OPC UA Clients später abonnieren.
Bei der Erstellung einer Bedingung (Condition) müssen der NamespaceName (NS) und die NodeID spezifiziert werden, um auf den zu überwachenden UA-Knoten zu verweisen. Der Konfigurator bietet einen einfachen Browsing-Mechanismus, um einen Knoten auszuwählen. In XML kann durch den Platzhalter [NodeName] in NamespaceName die XML-Datei einfach zwischen zwei verschiedenen Hardwaresystemen hin und her wechseln. NamespaceName beinhaltet immer den Hostnamen des IPC oder Embedded-PC, auf dem der OPC UA Server läuft. Wird [NodeName] gewählt, wird dieser Tag durch den Hostnamen des aktuellen IPCs oder Embedded-PCs ersetzt, auf dem der UA Server läuft.
Die SamplingRate bestimmt, wie oft der UA Server einen Wert vom Knoten abfragen soll, um festzustellen, ob eine der Alarmgrenzen erreicht wurde.
Die Alarmtexte werden über eine ID identifiziert. Die ID identifiziert eindeutig einen Alarmtext aus der Ressourcendatei (siehe Schritt 5: Mehrsprachige Alarmtexte konfigurieren).
Schritt 3: Eigene Benutzerdaten mit einem Alarm übermitteln
Alarme können Felder mit eigenen Benutzerdaten enthalten, die die mit dem Alarm ausgegebenen Daten ergänzen. Diese Benutzerdatenfelder können Sie in der Laufzeitanwendung erzeugen und ausfüllen. Erstellen Sie dazu ein STRUCT und nennen Sie dessen erstes Element „value“. Bei einem Alarm werden dann alle folgenden Elemente in einem zusätzlichen Benutzerdatenfeld gesendet.
Beispiel SPS-Anwendung:
TYPE ST_CustomStruct :
STRUCT
value : INT;
data : ST_SomeStruct;
END_STRUCT
END_TYPE

TYPE ST_SomeStruct :
STRUCT
Data1 : INT;
Data2 : REAL;
Data3 : LREAL;
END_STRUCT
END_TYPE
Die Instanz von ST_CustomStruct wird über den regulären Mechanismus, z. B. in TwinCAT 3, für den Datenzugriff aktiviert. Das STRUCT muss dazu als StructuredType aktiviert sein.
PROGRAM MAIN
VAR
{attribute 'OPC.UA.DA' := '1'}
{attribute 'OPC.UA.DA.StructuredType' := '1'}
stCustomStruct : ST_CustomStruct;
END_VAR
Bei der Anmeldung bei einem ConditionController müssen die OPC UA Clients besondere AlarmConditionTypes, sogenannte „BkUaLimitAlarmType“ und „BkUaOffNormalAlarmType“, abonnieren, damit sie die besonderen Benutzerdatenfelder beim Eingang eines Alarms empfangen können.
Der OPC UA Client empfängt dann die Benutzerdaten in den Feldern BkUaEventData und BkUaEventValue des eingehenden Alarms. Im obigen Beispiel sind das der Wert der SPS-Variablen sowie die Benutzerdaten, die mit der SPS-Struktur ST_SomeStruct dargestellt werden.
Grafik aus Alarms _ Conditions (i1d631q3.png)
Schritt 4: Ereignis über die FireEvent-Methode auslösen
Jeder ConditionController umfasst eine FireEvent-Methode, mit der die OPC UA Clients ein allgemeines Ereignis mit benutzerdefinierten EventFields auslösen können.
Wenn die Methode ausgeführt wird, dann wird ein Ereignis auf dem OPC UA Server ausgegeben. Andere OPC UA Clients können diese Ereignisse empfangen, wenn sie den entsprechenden ConditionController abonnieren.
Die benutzerdefinierten EventFields werden als „UserEventData“ an das Ereignis angehängt. Diesen Daten können von OPC UA Clients empfangen werden, die beim SimpleEventType „UserEventType“ angemeldet sind.
Schritt 5: Mehrsprachigen Alarmtexten konfigurieren
Die A&C-Implementierung im OPC UA Server unterstützt die Verwendung von mehrsprachigen Alarmtexten. Abhängig von der Sprache, mit der sich der UA Client mit dem Server verbindet, wird ein entsprechender Alarmtext verwendet.
Alarmtexte werden in XML-Dateien konfiguriert, für jede Sprache gibt es eine eigene Datei. Diese Dateien befinden sich im Ordner res (Ressource) des OPC UA Servers. Mit dem Konfigurator können Sie Alarmtexte einfach hinzufügen oder entfernen, ohne dass Sie die XML-Dateien direkt bearbeiten müssen. Jeder Alarmtext hat eine eigene ID, die in der Datei nur einmal vorkommt.
Beispiel:
<TcOpcUaSvrRes Lang="en">
<Text ID="0">Text not available</Text>
<Text ID="1">Some alarm text</Text>
<Text ID="2">Value is High range</Text>
<Text ID="3">Value is HighHigh range</Text>
<Text ID="4">Value is OffNormal</Text>
...
</TcOpcUaSvrRes>
Schritt 6: A&C bei einem Referenz-OPC-UA-Client anmelden
Ein OPC UA Client muss sich bei einem ConditionController anmelden, damit er Ereignisse für Bedingungen empfangen kann, die für diesen besonderen ConditionController konfiguriert sind. Der UA Expert stellt Funktionen zur Verfügung, um UA-Ereignisse zu abonnieren und zu empfangen.
Nachdem Sie den UA Expert gestartet und eine Verbindung zum OPC UA Server hergestellt haben, fügen Sie Ihrem Arbeitsbereich eine neue Dokumentenansicht Event View hinzu.
Sie können einen ConditionController dann durch Ziehen des entsprechenden Objekts in den Event View abonnieren. Die Ereignisse für diesen ConditionController werden im Event Window angezeigt.
Möglicherweise müssen spezielle Alarm- und/oder Ereignistypen abonniert werden, damit Sie alle Felder eines eingehenden Ereignisses oder Alarms empfangen können.


Dateiübertragung

Technische Einführung [image] Server [image] Dateiübertragung
Dateiübertragung
Weiterführende Informationen
•
Zugriff auf Dateien und Ordner über OPC UA


Zugriff auf Dateien und Ordner über OPC UA

Technische Einführung [image] Server [image] Dateiübertragung [image] Zugriff auf Dateien und Ordner über OPC UA
Zugriff auf Dateien und Ordner über OPC UA
Ab OPC‑UA‑Spezifikation Version 1.02 enthält OPC UA einen spezialisierten ObjectType zur Dateiübertragung, der in Anlage C der Spezifikation beschrieben ist. Dieser spezielle ObjectType namens „FileType“ beschreibt das Informationsmodell für die Datenübertragung. Dateien können in OPC UA mit ByteStrings als einfache Variablen modelliert werden. FileType ist eine Datei mit Methoden zum Zugriff auf die Datei. In der OPC‑UA‑Spezifikation erhalten Sie weitere Informationen zu FileType sowie Aufbau und Handhabung der zugrunde liegenden Methoden und Eigenschaften zum Zugriff auf eine Datei im OPC‑UA‑Namensraum.
Beckhoff hat einen generischen Weg implementiert, um Dateien und Ordner von einer lokalen Festplatte in den OPC‑UA‑Namensraum zu laden. Jede Datei wird durch einen FileType repräsentiert und ermöglicht Lese- und Schreibvorgänge für diese Datei. Zusätzlich enthält jeder Ordner eine Methode CreateFile(), um neue Dateien auf der Festplatte zu erstellen und einen eigenen FolderPath, um den tatsächlichen Pfad zum Ordner auf dem OPC UA Server festzulegen.
Grafik aus Access files and folders via OPC-UA (i0vu4ul.png)
FileTransfer im Device Manager OPC UA Server
Diese Funktion hat nur der OPC UA Server des Beckhoff Device Managers (IPC Diagnose). Der TwinCAT OPC UA Server stellt ebenfalls einige Teile dieser Dateiübertragung bereit. Die allgemeine Funktion, die eine Offenlegung aller Dateien und Ordner ermöglicht, steht aber nur im OPC UA Server zur Verfügung, der zum Gerätemanager gehört, der automatisch auf jedem Beckhoff Industrie-PC oder Embedded-PC verfügbar ist. In der Gerätemanagerdokumentation erhalten Sie weitere Informationen.
Konfiguration
FileType-Objekte werden in einem separaten Namensraum mit der Bezeichnung „FileTransfer” erstellt. Zur Konfiguration des Namensraums und zur Auswahl der über OPC UA verfügbaren Dateien und Ordner dient eine XML-Datei (files.xml), die in demselben Verzeichnis wie die ausführbare Datei des OPC UA Servers sein muss. Um die Konfiguration zu aktivieren, muss das System neu gestartet werden. Die XML-Datei enthält Informationen über den Ordnerpfad und eine Suchmaske, die definiert, welche Dateien im OPC‑UA‑Namensraum veröffentlicht werden:
<Files>
<FolderObject DisplayName="TwinCAT">
<FolderObject DisplayName="3.1">
<FolderObject DisplayName="Boot" Path="c:/TwinCAT/3.1/Boot" Search="*.*" >
<FolderObject DisplayName="Plc" Path="c:/TwinCAT/3.1/Boot/Plc" Search="*.*" ></FolderObject>
<FolderObject DisplayName="Tmi" Path="c:/TwinCAT/3.1/Boot/Tmi" Search="*.*" ></FolderObject>
</FolderObject>
</FolderObject>
</FolderObject>
</Files>
Beispiel: Lesen einer Datei mit UA Expert
Der allgemeine Umgang mit Dateien ist in Anhang C der OPC-UA-Spezifikation beschrieben. Das Lesen einer Datei via UA kann in folgende Schritte unterteilt werden:
▪
Aufruf der Open-Methode einer Datei. Diese Methode gibt ein Dateihandle zurück, das für den späteren Zugriff gespeichert werden muss. Der Modus legt fest, ob die Datei gelesen oder in sie geschrieben wird (siehe Dateimodi).
▪
Bestimmen der Größe der Datei mit der Eigenschaft „Size“. So kann die ganze Datei bei Aufruf der Read-Methode gelesen werden.
▪
Aufruf der Read-Methode. Dateihandle und Dateigröße als Eingaben einfügen. Zielordner wählen, in den der Dateiinhalt NACH dem Aufruf der Methode zu speichern ist.
▪
Aufruf der Close-Methode zur Freigabe des Dateihandles.
Dateimodi
Die folgende Tabelle zeigt alle verfügbaren Dateimodi.
Feld | Bit | Beschreibung
Lesen | 1 | Die Datei wird zum Lesen geöffnet. Wenn dieses Bit nicht gesetzt ist, kann Read nicht ausgeführt werden.
Schreiben | 4 | Die Datei wird zum Schreiben geöffnet. Wenn dieses Bit nicht gesetzt ist, kann Write nicht ausgeführt werden.
EraseExisting | 6 | Der vorhandene Dateiinhalt wird gelöscht und es wird eine leere Datei zur Verfügung gestellt.
Append | 10 | Die Datei wird geöffnet und ans Ende positioniert, sonst auf den Anfang. Diese Position kann mit SetPosition geändert werden.


Sicherheit

Technische Einführung [image] Server [image] Sicherheit
Sicherheit
Weiterführende Informationen
•
Übersicht
•
Authentifizierung
•
Zertifikatsaustausch
•
Zugriffsrechte


Übersicht

Technische Einführung [image] Server [image] Sicherheit [image] Übersicht
Übersicht
Sicherheit ist eine zentrale Anforderung bei der Entwicklung von OPC UA. Sie wird in verschiedenen Bereichen adressiert:
▪
Verschlüsselung
▪
Integrität
▪
Authentifizierung
Die Vertraulichkeit der ausgetauschten Information wird durch die Verschlüsselung der ausgetauschten Nachrichten sichergestellt. Dabei werden moderne Kryptographie-Algorithmen verwendet. Um auch den zukünftigen Sicherheitsanforderungen gewachsen zu sein, können im Nachhinein noch stärkere und modernere Algorithmen einer Anwendung hinzugefügt werden, ohne das Protokoll zu verändern.
Entsprechend der Anforderungen der jeweiligen Anwendung können verschiedene Sicherheitsstufen gewählt werden. In einigen Bereichen ist es ausreichend die Nachrichten zu signieren, um Änderungen durch Dritte auszuschließen, in anderen Fällen dürfen Daten auch nicht von Dritten gelesen werden und ein zusätzliches Verschlüsseln der Nachrichten ist erforderlich.
TF6100 OPC UA bietet die folgenden Security-Level (Security-Endpunkte) an, mit denen sich Clients verbinden können:
▪
None: Keine Sicherheit
▪
Sign: Signiert Nachrichten
▪
Sign & Encrypt: Signiert und verschlüsselt Nachrichten
Das Signieren der Nachrichten verhindert das Ändern des Inhalts einer Nachricht durch einen Dritten. So wird verhindert, dass beispielsweise eine Schreibanweisung zum Öffnen eines Schalters durch einen Dritten verfälscht wird und der Schalter stattdessen geschlossen wird.
OPC‑UA‑Anwendungen identifizieren sich über so genannte Software- und Applikationsinstanz-Zertifikate. Mithilfe von Software-Zertifikaten ist es möglich, bestimmten Client-Anwendungen einen erweiterten Zugriff auf Informationen eines OPC UA Servers zu geben, beispielsweise für das Engineering eines OPC UA Servers. Durch Applikationsinstanz-Zertifikate kann sichergestellt werden, dass ein OPC UA Server nur mit vorkonfigurierten Clients kommuniziert. Ein Client kann durch das Applikationsinstanz-Zertifikat des Servers sicherstellen, dass er mit dem richtigen Server spricht (ähnlich der Zertifikate eines Web-Browsers). Die Berücksichtigung dieser Zertifikate ist optional, d. h. ein OPC UA Server kann auch jedem Client den gleichen Zugriff abhängig der Benutzerrechte geben.
Der TwinCAT OPC UA Client und der TwinCAT OPC UA Server erzeugen ein selbst-signiertes Zertifikat während des ersten Startvorgangs. Dieses Zertifikat besteht aus einem privaten und einem öffentlichen Schlüssel. Der private Schlüssel wird in dem Verzeichnis \PKI\CA\private und der entsprechende öffentliche Schlüssel in dem Verzeichnis \PKI\CA\certs abgelegt. Wenn ein beliebiger OPC UA Client eine gesicherte Verbindung über einen der Security-Endpunkte (Sign, Sign&Encrypt) mit dem Server herstellen will, muss der Client den öffentlichen Schlüssel des OPC UA Servers kennen. Umgekehrt muss der OPC UA Server den öffentlichen Schlüssel des Clients kennen. Dieser sogenannte Schlüsselaustausch wird in den folgenden Artikeln beschrieben:
▪
Authentifizierung
▪
Zertifikatsaustausch
▪
Zugriffsrechte


Authentifizierung

Technische Einführung [image] Server [image] Sicherheit [image] Authentifizierung
Authentifizierung
Zusätzlich zum Zertifikataustausch bietet der TwinCAT OPC UA Server die Möglichkeit, eine Authentifizierung über Benutzername/Passwort durchzuführen. Ein OPC UA Client muss dann eine gültige Benutzername/Passwort-Kombination verwenden, damit die Herstellung einer Verbindung zum Server erfolgreich ist.
Der TwinCAT OPC UA Server verwendet Mechanismen des Betriebssystems für die Validierung der Benutzernamen und Passwörter. Wenn der Computer, auf dem der TwinCAT OPC UA Server läuft, Mitglied einer Windows-Domäne ist (z. B. Active Directory), dann wird eine Anfrage an den entsprechenden Domänencontroller durchgeführt. Wenn der betreffende Computer ein Einzelgerät ist, dann wird die lokale Benutzerdatenbank des Betriebssystems überprüft.
Die Konfiguration des TwinCAT OPC UA Servers ermöglicht zwei Einstellungen:
▪
Aktivierung/Deaktivierung anonymer Zugriffe (ohne Benutzerauthentifizierung)
▪
Aktivierung/Deaktivierung der Benutzernamen-/Passwort-Validierung
Beide Einstellungen können Sie im OPC‑UA‑Server‑Konfigurator vornehmen.


Zertifikatsaustausch

Technische Einführung [image] Server [image] Sicherheit [image] Zertifikatsaustausch
Zertifikatsaustausch
Die Kommunikation zwischen einem OPC UA Client und einem OPC UA Server kann optional durch Kommunikation mit einem gesicherten Endpunkt abgesichert werden. Standardmäßig generieren sowohl der TwinCAT OPC UA Server als auch der TwinCAT OPC UA Client beim ersten Start ein maschinenspezifisches, selbstsigniertes Zertifikat zur Authentifizierung.
Wenn Sie in Ihrer Umgebung eine solche verschlüsselte Kommunikationsverbindung verwenden möchten, müssen Sie ein Vertrauensverhältnis zwischen OPC UA Server und OPC UA Client herstellen.
Grafik aus Certificate exchange (i1oenvg2.png)
Vertrauenseinstellungen auf dem Server
Möchten Sie einen oder mehrere OPC UA Clients über Zertifikate am OPC UA Server authentifizieren, so muss der OPC UA Server den öffentlichen Schlüsseln der Clients vertrauen. Dies kann zum Beispiel über das Dateisystem erfolgen. Der Server verwaltet die Vertrauenseinstellungen für Zertifikate über das Dateisystem.
▪
Vertrauenswürdige Zertifikate: %InstallDir%\Server\PKI\CA\trusted\certs
▪
Abgewiesene Zertifikate: %InstallDir%\Server\PKI\CA\rejected\certs
Durch Verschieben von Client-Zertifikaten zwischen diesen Verzeichnissen können die Vertrauenseinstellungen entsprechend angepasst werden.
Client-Zertifikat auslesen
Nachfolgend wird ein einfacher Weg beschrieben, wie Sie an das Client-Zertifikat gelangen. Hierbei bauen Sie, ohne vorher das Client-Zertifikat auf den UA Server kopiert zu haben, eine Verbindung zum UA Server unter Verwendung eines sicheren Endpunkts auf (z. B. Basic128Rsa15/Sign&Encrypt). DieVerbindung wird vom UA Server initial natürlich abgewiesen, da dieser dem UA Client zum derzeitigen Zeitpunkt noch nicht vertraut. Der TwinCAT OPC UA Client würde in diesem Fall z. B. den Fehler 0xE4DD0102 zurückliefern. Nach Abweisen der Verbindungsaufforderung speichert der UA Server jedoch eine Kopie des Client-Zertifikats im oben genannten „Rejected“-Verzeichnis ab. Der Name des Zertifikats entspricht hierbei dem „Thumbprint“ des Zertifikats und lässt sich somit eindeutig dem Client-Zertifikat zuordnen. Diese Datei können Sie nun direkt in das oben genannte „Trusted“-Verzeichnis verschieben, damit der UA Server bei allen weiteren Verbindungsanforderungen dem UA Client vertraut und die Verbindung akzeptiert.
OPC UA Servers beim OPC UA Client bekannt machen
Abhängig vom verwendeten OPC UA Client müssen eventuell unterschiedliche Schritte vorgenommen werden, damit der OPC UA Client dem OPC UA Server vertraut. Typischerweise erfolgt bei Client‑Applikationen mit grafischer Benutzeroberfläche ein Warnhinweis bei der ersten Verbindung mit dem Server, wobei das Server-Zertifikat dann als vertrauenswürdig eingestuft werden kann.
Die folgende Anweisung ist daher nur für den TwinCAT OPC UA Client gültig.
Der öffentliche Schlüssel des OPC UA Servers befindet sich als DER-Datei in dem folgenden Verzeichnis: %InstallDir%\Server\PKI\CA\own\certs
Kopieren Sie die Datei beim TwinCAT OPC UA Client in das entsprechende „Trusted“-Verzeichnis: %InstallDir%\Client\PKI\CA\certs


Zugriffsrechte

Technische Einführung [image] Server [image] Sicherheit [image] Zugriffsrechte
Zugriffsrechte
Der TwinCAT OPC UA Server ermöglicht die Konfiguration von Berechtigungen auf Namespace- und Node-Ebene . Hierdurch kann sowohl der Zugriff auf ADS-Geräte (z. B. auf verschiedene SPS‑Laufzeiten) als auch Variablen feingranular eingestellt werden. Diese Sicherheitseinstellungen sind für alle ADS-Geräte verfügbar, die im Server-Namespace dargestellt werden können.
Graphic from Access Level (i6k0pr22.png)
Siehe auch:
Konfiguration > Setup-Version 4.x.x. > Konfiguration der Sicherheitseinstellungen im Konfigurator.
Voraussetzungen
Produkte | Setup-Versionen | Zielplattform
TF6100 | 4.x.x | IPC oder CX (x86, x64, ARM)


Symbol-Caching

Technische Einführung [image] Server [image] Symbol-Caching
Symbol-Caching
Ab Version 3.2 (Dateiversion) erstellt die Serveranwendung eine binäre Cache-Datei, wenn eine TwinCAT-Symboldatei (TMC-Datei) zum ersten Mal geladen wird.
In Abhängigkeit der Größe der Symboldatei und der zugrunde liegenden Architektur der Hardware kann das Parsen einer Symboldatei sehr lange dauern, was zu einer längeren Startzeit des Serverprozesses führt. Jede Symboldatei muss mindestens zweimal geparst werden, um Informationen zum Typsystem und allen Instanzen zusammenzutragen. Damit sichergestellt wird, dass der Server das nächste Mal schneller startet, wird eine Cache-Datei erstellt, die Informationen über alle TwinCAT-Symbole enthält, die an den Namensraum des Servers exponiert werden sollen.
Die Cache-Datei wird in einem komprimierten Binärformat erstellt, das effizienter geladen und bearbeitet werden kann als eine XML-basierte Symboldatei, und wird in dem Unterverzeichnis /symbolfiles/ des Servers gespeichert. Solange sich die Quellsymboldatei nicht ändert, wird die Cache-Datei anstatt der Symboldatei vom Server verwendet.
Wenn sich die Quellsymboldatei ändert (aufgrund der Checksumme innerhalb der Datei), wird die Cache-Datei neu erstellt.
Der Standardstartprozess des Servers besteht aus den folgenden Schritten:
1.
Die Serveranwendung lädt die Konfigurationsdatei TcUaDaConfig.xml, die eine Liste aller Namensräume (TwinCAT-Laufzeiten) enthält, die erstellt werden sollen.
2.
Die Serveranwendung lädt jede TMC-Symboldatei aus der Konfiguration und prüft, ob bereits eine binäre Cache-Datei für diese Symboldatei erstellt wurde.
3.
Wenn noch keine binäre Cache-Datei erstellt wurde, parst der Server die Symboldatei und erstellt eine entsprechende Cache-Datei.
4.
Wenn bereits eine binäre Cache-Datei erstellt wurde, validiert der Server die Checksumme der Symboldatei und vergleicht diese mit der Checksumme der Cache-Datei, um festzustellen, ob Änderungen gegenüber der Symboldatei vorgenommen wurden (z. B. aufgrund eines neuen oder aktualisierten SPS-Programms).
5.
Wenn sich die Checksumme unterscheidet, wird die Symboldatei erneut geparst und die Cache-Datei erneut erstellt.
6.
Wenn die Checksumme gleich ist, wird die binäre Cache-Datei anstatt der Symboldatei geladen.
Dieser Arbeitsablauf ist normalerweise vollständig transparent, da er automatisch als Standardverhalten des OPC UA Servers im Hintergrund ausgeführt wird. Das Verhalten des Servers können Sie jedoch in Schritt Nr. 5 über die folgende Konfigurationsoption in der DateiTcUaDaConfig.xml ändern:
<CacheFileMode>...</CacheFileMode>
Diese Konfigurationsoption kann folgende Werte aufweisen:
no_cache | Deaktiviert die Cache-Datei
dont_update | Erstellt eine Cache-Datei, aber aktualisiert die Datei nicht, wenn sich der Inhalt der Symboldatei ändert
always_create | Erstellt bei jedem Start eine neue Cache-Datei
Die Option „dont_update“ kann praktisch sein, wenn z. B. alle OPC-UA-Symbole in eine SPS-Bibliothek gespeichert sind. Auch wenn sich die SPS-Anwendung, die die Bibliothek verwendet, verändern kann (was zu einer geänderten Symboldatei führt), beeinträchtigt dies nicht den OPC-UA-Namensraum. Die Cache-Datei muss somit nicht notwendigerweise neu erstellt werden.


Verschiedenes

Technische Einführung [image] Server [image] Verschiedenes
Verschiedenes
Weiterführende Informationen
•
Endpunkte und Standard-Port
•
NamespaceURI generieren
•
Konfigurationsdatei bearbeiten
•
Mehrere TwinCAT-Laufzeiten konfigurieren
•
Mehrere Server-Instanzen konfigurieren
•
Firewalls konfigurieren
•
Namensraum konfigurieren


Endpunkte und Standard-Port

Technische Einführung [image] Server [image] Verschiedenes [image] Endpunkte und Standard-Port
Endpunkte und Standard-Port
Standardmäßig bietet der TwinCAT OPC UA Server die folgenden Endpunkte und Standard-Port für OPC UA Clients zur Verbindung an:
Grafik aus Endpoints and default port (ir0btqq3.png)
Standard-Port
Beachten Sie, dass der Standard-Port 4840 eventuell von anderen OPC UA Servern verwendet wird, z. B. dem Local Discovery Server (LDS) von der OPC Foundation, die von manchen Anbietern mit OPC‑UA‑Softwarepaketen eingesetzt wird.
Endpunkt | Beschreibung
Keine - Keine | Keine Sicherheit
Basic128Rsa15 - Sign & Encrypt | Signatur und Verschlüsselung von Nachrichten für mittlere Sicherheitsanforderungen. Erfordert Zertifikataustausch und die Verwaltung der Vertrauenslisten. Siehe auch: Server > Sicherheit
Basic256 - Sign & Encrypt | Signatur und Verschlüsselung von Nachrichten für mittlere bis hohe Sicherheitsanforderungen. Erfordert mehr Rechenzeit (höhere Anforderungen an die CPU des Computers). Erfordert Zertifikataustausch und die Verwaltung der Vertrauenslisten. Siehe auch: Server > Sicherheit


NamespaceURI generieren

Technische Einführung [image] Server [image] Verschiedenes [image] NamespaceURI generieren
NamespaceURI generieren
Der NamespaceURI ist wichtig für die einzigartige Identifizierung eines Knotens im UA‑Namensraum. Jede NodeID besteht aus einem NamespaceIndex, einem IdentifierType und einem Bezeichner. Weil der NamespaceIndex dynamisch von einem OPC UA Server generiert werden kann, sollte ein UA Client immer den statischen NamespaceURI verwenden, um diesen in dessen tatsächlichen NamespaceIndex aufzulösen. Alle NamespaceURI und deren entsprechender NamespaceIndex werden im sogenannten Namespace Array eines OPC UA Servers aufgelistet.
Weitere Informationen bezüglich des Namespace Array und seines Inhalts finden Sie im Abschnitt Wie Kommunikationsparameter zu bestimmen sind.
Für jede TwinCAT‑Laufzeit wird der NamespaceURI gemäß folgendem Benennungsschema generiert:
urn:[NodeName]:BeckhoffAutomation:Ua:[Name]
▪
[NodeName] steht für den Hostnamen des Computers, auf dem der TwinCAT OPC UA Server läuft
▪
[Name] ist eine Zeichenkette, die über die Konfigurationsdatei des Servers oder über den TwinCAT‑OPC‑UA‑Konfigurator festgelegt werden kann.
Beachten Sie, dass ältere Versionen des OPC UA Servers nicht das URI-basierte Format zur Generierung des NamespaceURI verwenden, sondern lediglich das <Name>-Attribut, wie es in der Konfigurationsdatei des Servers festgelegt wurde. Weil dies beim Upgrade von älteren Versionen eine unüberbrückbare Veränderung sein kann, bietet der OPC UA Server einen sogenannten Legacy‑URI‑Formatwechsel, den Sie für jede TwinCAT‑Laufzeit in der Konfigurationsdatei des Servers oder über den OPC‑UA‑Konfigurator aktivieren können.
<UaNodeManager>
<Name>PLC1</Name>
<AdsPort>851</AdsPort>
<AdsNetId>127.0.0.1.1.1</AdsNetId>
<AdsTimeout>2000</AdsTimeout>
<AdsTimeSuspend>20000</AdsTimeSuspend>
<AutoCfg>4041</AutoCfg>
<IoMode>1</IoMode>
<AutoCfgSymFile>C:\TwinCAT\3.1\Boot\Plc\Port_851.tmc</AutoCfgSymFile>
<Disabled>0</Disabled>
<ArraySubItemLegacySupport>0</ArraySubItemLegacySupport>
<MaxGetHandle>100</MaxGetHandle>
<ReleaseAdsVarHandles>0</ReleaseAdsVarHandles>
<LegacyUriFormat>1</LegacyUriFormat>
</UaNodeManager>
Wird der Legacy‑URI‑Formatwechsel auf „0“ gesetzt, dann wird der Namespace Name gemäß dem oben beschriebenen Schema generiert. Wird er auf „1“ gesetzt, dann ist der Namespace Name gleich dem XML-Tag <Name> und wird demzufolge wie in älteren Versionen des OPC UA Servers generiert.


Konfigurationsdatei bearbeiten

Technische Einführung [image] Server [image] Verschiedenes [image] Konfigurationsdatei bearbeiten
Konfigurationsdatei bearbeiten
Alle Einstellungen für den OPC UA Server können Sie mithilfe des OPC-UA-Konfigurators vornehmen, der über das Setup vom UA-Server-Version 1.6.80 geliefert wird (siehe Konfiguration > Setup-Version 3.x.x > Übersicht). Der Konfigurator erleichtert die Konfiguration des UA Servers über seine Konfigurationsdatei ServerConfig.xml. Die Konfigurationsdatei enthält eine hierarchische, XML-basierte Struktur aller einstellbaren Parameter des UA Servers. Die folgende Abbildung zeigt beispielhaft die Struktur der Datei:
In Allgemeinen wird die Verwendung des OPC‑UA‑Konfigurators empfohlen, da auf diese Weise Fehler bei der Konfiguration vermieden werden können.
Die Konfigurationsdatei ServerConfig.xml befindet sich immer in demselben Verzeichnis wie TcOpcUaServer.exe, z. B.:
▪
Windows XP / 7 mit TwinCAT 2: %TwinCATDIR%\OPC\UA\
▪
Windows XP / 7 mit TwinCAT 3: %TwinCATDIR%\Functions\TF6100-OPC-UA\Win32\Server\
▪
Windows CE TwinCAT 2 : HardDisk\System
▪
Windows CE TwinCAT 3 : HardDisk\TwinCAT\Functions\TF6100-OPC-UA\Server\


Mehrere TwinCAT-Laufzeiten konfigurieren

Technische Einführung [image] Server [image] Verschiedenes [image] Mehrere TwinCAT-Laufzeiten konfigurieren
Mehrere TwinCAT-Laufzeiten konfigurieren
Sie können optional weitere TwinCAT-ADS-Geräte zum UA-Namensraum hinzufügen. Durch die Konfiguration des Namensraums weiß der OPC UA Server, welches TwinCAT-ADS-Gerät (z. B. PLC, IO‑Task, C++‑Laufzeit,...) über den OPC UA Server verfügbar gemacht werden soll und blendet entsprechend dessen Symbolinformationen im UA-Namensraum ein. Diese Konfiguration muss nur einmalig durchgeführt werden.
Weiteren ADS-Geräten zu/aus dem UA‑Namensraum hinzufügen/entfernen
Der TwinCAT OPC UA Server ist standardmäßig so konfiguriert, dass er sich zur ersten SPS-Laufzeit des lokalen Systems verbindet. Um weitere ADS-Geräte bzw. weitere Laufzeiten über den UA-Namensraum verfügbar zu machen, führen Sie folgende Schritte aus:
▪
Wenn es sich bei dem hinzuzufügenden Gerät um ein lokales Gerät handelt:
–
Hinzufügen des Remotegeräts zur Konfiguration des OPC UA Servers, z. B. über den OPC‑UA‑Konfigurator oder durch direktes Editieren der Datei ServerConfig.xml
▪
Wenn es sich bei dem hinzuzufügenden Gerät um ein Remote-Gerät handelt:
–
Herstellen von ADS-Routen zwischen dem Rechner auf dem sich der OPC UA Server befindet und dem Remote-System
–
Hinzufügen des Remote-Geräts zur Konfiguration des OPC UA Servers, z. B. über den OPC‑UA‑Konfigurator oder durch direktes Editieren der Datei ServerConfig.xml
OPC-UA-Konfigurator verwenden
Verwenden Sie den OPC-UA-Konfigurator, um weitere ADS-Geräte zum UA-Namensraum hinzuzufügen.
Im Bereich Data Access des OPC-UA-Konfigurators können Sie die im UA-Namensraum eingebundenen ADS-Geräte verwalten bzw. neue Geräte hinzufügen oder existierende Geräte entfernen.
Zum Hinzufügen wählen Sie zunächst den Typ des Geräts aus der zugehörigen Drop-Down-Liste (z. B. „8 (PLC: Subset)“) und klicken dann auf Add. Es wird ein zusätzlicher Eintrag zur Liste der ADS-Geräte hinzugefügt. Nehmen Sie die gewünschten Einstellungen vor. Wenn Sie die Konfiguration sofort aktivieren möchten, klicken Sie anschließend im Menü Configuration auf Activate.
Abhängig von dem hinzuzufügenden Gerät müssen Sie unterschiedliche Einstellungen für die einzelnen Parameter vornehmen (siehe Konfiguration > Setup-Version 3.x.x > Data Access).
Beachten Sie, dass Sie den OPC UA Server neu starten müssen, damit die Änderungen wirksam werden. Dies können Sie ebenfalls über den Konfigurator erledigen, indem Sie im Menü Server die Option Restart auswählen. Alternativ können Sie auch TwinCAT neu starten.
[Optional] ServerConfig.xml editieren
Sie können die Datei ServerConfig.xml auch direkt editieren, um weitere ADS-Geräte zum UA‑Namensraum hinzuzufügen. In dieser Konfigurationsdatei gibt es einen Bereich UaNodeManager, der jeweils den Zugriff auf ein ADS-Gerät definiert, z. B.:
Abhängig von dem hinzuzufügenden Gerät müssen Sie unterschiedliche Einstellungen für die einzelnen Parameter vornehmen (siehe Konfiguration > Setup-Version 3.x.x > Data Access).
Beachten Sie, dass Sie den OPC UA Server neu starten müssen, damit die Änderungen wirksam werden. Dies können Sie ebenfalls über den Konfigurator erledigen, indem Sie im Menü Server die Option Restart auswählen. Alternativ können Sie auch TwinCAT neu starten.


Mehrere Server-Instanzen konfigurieren

Technische Einführung [image] Server [image] Verschiedenes [image] Mehrere Server-Instanzen konfigurieren
Mehrere Server-Instanzen konfigurieren
Es besteht die Möglichkeit, mehrere TwinCAT OPC UA Server auf einem System zu installieren. In diesem Abschnitt werden die hierfür notwendigen Konfigurationsschritte beschrieben. Die Konfiguration ist unter Windows-CE- und Windows-XP-basierten Betriebssystemen identisch und besteht aus den folgenden Teilschritten:
▪
Schritt 1: Installation des TwinCAT OPC UA Servers
▪
Schritt 2: Kopieren der installierten UA‑Server‑Dateien in ein neues Verzeichnis
▪
Schritt 3: Anpassen der Konfigurationsdatei des zweiten UA Servers
Lediglich die Pfade bei den beiden Betriebssystemvarianten sind unterschiedlich. In der Beschreibung der einzelnen Schritte wird auf die Unterschiede hingewiesen.
Der TwinCAT OPC UA Server ermöglicht eine Nutzung von OPC UA direkt aus der SPS-Ebene heraus. Hierfür wurde ein ADS-Server in das Produkt integriert, damit SPS-Programmierer per Funktionsbaustein Daten über OPC UA verschicken können. Wenn Sie mehrere TwinCAT OPC UA Server parallel auf einem System laufen lassen möchten, beachten Sie, dass nur die erste Instanz des UA Servers per Funktionsbaustein angesprochen werden kann.
Schritt 1: Installation des TwinCAT OPC UA Servers
Die Erstinstallation des TwinCAT OPC UA Servers erfolgt über die auf dem Beckhoff FTP-Server erhältliche Setup-Datei. Standardmäßig wird der UA Server in das folgende Verzeichnis installiert:
▪
Windows XP: %TwinCATDIR%\Function\TF6100-OPC-UA\Win32\Server\
▪
Windows CE: HDD\System
Schritt 2: Kopieren der installierten UA‑Server‑Dateien in ein neues Verzeichnis
Die installierten UA-Server‑Dateien müssen in ein neues Verzeichnis kopiert werden. Erstellen Sie ein neues Verzeichnis namens „Server2“ in einem Ordner Ihrer Wahl, z. B.:
▪
Windows XP: %TWINCATDIR%\Function\TF6100-OPC-UA\Win32\Server2\
▪
Windows CE: HDD\System\UA2
Kopieren Sie die Inhalte des Ursprungsordners in das neu erstellte Verzeichnis. Der Inhalt dieses Ordners sieht wie folgt aus:
Schritt 3: Anpassen der Konfigurationsdatei des zweiten UA Servers
Damit der zweite UA Server einen anderen TCP-Port benutzt, müssen Sie einmalig dessen Konfigurationsdatei anpassen. Öffnen Sie hierzu die Datei ServerConfig.xml mit einem Texteditor Ihrer Wahl, z. B. Notepad.
Weitere Informationen zur Konfigurationsdatei des UA Servers finden Sie im Abschnitt Konfigurationsdatei bearbeiten.
1.
Suchen Sie in dieser Datei den Eintrag <Url>opc.tcp://[NodeName]:4840</Url> unterhalb des Knotens <UaEndpoint> und ändern Sie dessen Portnummer (4840) in einen TCP-Port Ihrer Wahl, z. B. „4849“:
2.
Passen Sie zusätzlich den Knoten <ServerInstanceUri>[NodeName]/Beckhoff/TcOpcUaServer/ 1 </ServerInstanceUri> an und vergeben Sie eine neue Nummer, z. B.:
⇨
Durch Ausführen der Datei können Sie nun den zweiten TwinCAT OPC UA Server starten:
▪
Windows XP: %TWINCATDIR%\Function\TF6100-OPC-UA\Win32\Server2\TcOpcUaServer.exe -console


Firewalls konfigurieren

TS6100 | TwinCAT OPC UA
Technische Einführung [image] Server [image] Verschiedenes [image] Firewalls konfigurieren
Firewalls konfigurieren
Um eine OPC‑UA‑Kommunikation auch über ein NAT-Gerät, z. B. einen Internet-Router, zu ermöglichen, muss dieses den verwendeten UA-Port an den TwinCAT OPC UA Server weiterleiten können (sogenanntes „Port Forwarding“). Standardmäßig wird der TwinCAT OPC UA Server für eine UA-Kommunikation über den TCP-Port 4840 konfiguriert, diese Konfiguration kann jedoch bei Bedarf über die Server-Konfigurationsdatei oder den OPC‑UA‑Konfigurator selbst angepasst werden. Die folgende Abbildung verdeutlicht den Zusammenhang von Port Forwarding und dem UA Server.
In diesem Beispiel baut der OPC UA Client eine UA-Verbindung über den TCP-Port 4840 zum NAT‑Gerät auf, welches dann diese Kommunikationsverbindung über ein Port Forwarding an den TwinCAT OPC UA Server weiterleitet. Das NAT-Gerät muss also nur den im TwinCAT OPC UA Server konfigurierten UA-Port an das Zielgerät weiterleiten. Den vom UA Server verwendeten Port können Sie entweder in der Server-Konfigurationsdatei oder auch ganz bequem über den UA‑Konfigurator (im Auslieferungszustand ist dieser immer der TCP-Port 4840) einsehen. Die entsprechende Konfiguration Ihres NAT-Geräts für ein Port Forwarding entnehmen Sie bitte dessen Dokumentation.


Namensraum konfigurieren

Technische Einführung [image] Server [image] Verschiedenes [image] Namensraum konfigurieren
Namensraum konfigurieren
Ab der Version 2.1.x bietet der TwinCAT OPC UA Server eine separate Konfiguration des Namensraums, die die folgenden Funktionalitäten enthält:
▪
Verwaltung der Serverkonfigurationsdatei ServerConfig.xml (Lesen/Schreiben-Zugriff) des OPC UA Servers
▪
Zertifikatmanagement für vertrauenswürdige/abgelehnte Client-Zertifikate
Grafik aus Configuration namespace (i0mi0gg3.png)
Verwaltung der Serverkonfigurationsdatei
Die Serverkonfigurationsdatei ServerConfig.xml wird im Namensraum als regulärer OPC UA FileType veröffentlicht und bietet daher die entsprechenden Methoden und Eigenschaften, um Zugriff auf die Datei zu erhalten.
Verwaltung von Client-Zertifikaten
Jedes Client-Zertifikat, das dem Server bekannt ist, wird im Namensraum als OPC‑UA‑Zertifikattyp veröffentlicht. Zertifikate werden in „abgelehnte” und „vertrauenswürdige“ Zertifikate unterteilt, was durch einen separaten Ordner im Namensraum repräsentiert wird.
Durch Aufruf der Methode Move() kann ein Zertifikat zwischen den Vertrauenslisten verschoben werden.
Zudem bieten verschiedene Eigenschaften zur einfacheren Identifikation weitere Informationen über die Zertifikate selbst.
Verwendung der Namensraum-Konfiguration
Die Namensraum-Konfiguration darf nur von authentifizierten Benutzern verwendet werden. Dies bedeutet, dass ein OPC UA Client sich selbst gegenüber dem OPC UA Server durch Bereitstellung einer gültigen Benutzername-Passwort-Kombination authentifizieren muss. Gültige Benutzernamen sind entweder lokale Benutzer oder auch Benutzer von einer Windows-Domäne, wenn der Computer, auf dem der OPC UA Server läuft, ein Mitglied einer Windows-Domäne ist.
In seiner Konfigurationsdatei stellt der OPC UA Server die folgenden XML-Tags bereit, um den Zugriff auf die Namensraum-Konfiguration zu konfigurieren:
<ServerConfigNamespace Exposed="True" MinUserlevel="14" />
<Users>
<User Level="15">Administrator</User>
<User Level="10">domain\RegularUser</User>
</Users>
In dem vorstehenden Beispiel ist dem lokalen Benutzernamen „Administrator" der Zugriff auf den Konfiguration des Namensraums gestattet, wohingegen das Benutzerkonto „domain\RegularUser“ der Windows-Domäne nicht auf diesen Namensraum zugreifen darf, da die Benutzerebene zu niedrig ist.


Client I/O

Technische Einführung [image] Client I/O
Client I/O
Weiterführende Informationen
•
Übersicht
•
Schnelleinstieg
•
Unterstützte Datentypen
•
Knoten vom Server hinzufügen
•
Knotenattribute
•
Methodenaufruf
•
StructuredTypes
•
Datenaufnahme
•
Sicherheit


Übersicht

Technische Einführung [image] Client I/O [image] Übersicht
Übersicht
Diese Funktionalität erfordert TwinCAT 3.1 Build 4022.4 oder höher.
Der TwinCAT OPC UA Client ist ebenfalls als ein I/O-Treiber integriert und ist als solcher in der TwinCAT-I/O-Konfiguration verfügbar. Dies verringert nicht nur die Engineering-Zeit, die zur Herstellung der OPC-UA-Verbindung zu einem Remoteserver erforderlich ist, sondern ermöglicht die Realisierung vieler Anwendungsfälle, wie z. B. die Erstellung von einfach zu konfigurierenden Protokollbrücken.
Fügen Sie zunächst einen virtuellen Geräte-Container und anschließend ein OPC-UA-Client-Objekt zur Konfiguration hinzu.
Nachdem Sie das OPC-UA-I/O-Client-Objekt erstellt haben, können Sie seine Verbindung zu einem OPC UA Target Server konfigurieren und Variablen, Methoden und Strukturen zum Prozessabbild hinzufügen. Der Prozess des Datenaustauschs mit einem Target Server wird auf ein einfaches Mapping-Verfahren von Prozessvariablen reduziert.
Voraussetzungen
Produkte | Setup-Versionen | Zielplattform
TF6100 | 4.x.x | IPC oder CX (x86, x64, ARM)


Schnelleinstieg

Technische Einführung [image] Client I/O [image] Schnelleinstieg
Schnelleinstieg
Die folgende Anleitung ermöglicht einen Schnelleinstieg in den OPC UA I/O Client. In der Anleitung wird ein SPS‑Projekt erzeugt, das eine Variable über den OPC UA Server freigibt (zur Simulation eines UA Servers) und die freigegebene Variable wieder über den OPC UA I/O Client einliest. Dies kann natürlich auch auf zwei Projekte und zwei Steuerungen aufgeteilt werden.
Variablen für Server freigeben
Zur Simulation soll in diesem Schnelleinstieg der OPC UA Server verwendet werden.
1.
Erstellen Sie ein neues TwinCAT‑Projekt und fügen Sie dem Projekt ein neues SPS‑Projekt hinzu.
2.
Legen Sie im SPS-Projekt eine neue Variable „nQuickStartOut“ vom Datentyp INT an. Dies soll die Variable sein, die über den OPC UA Server freigegeben wird.
3.
Setzen Sie das OPC‑UA‑Attribut für diese Variable, um die Variable über den OPC UA Server freizugeben.
4.
Aktivieren Sie das Auswahlkästchen für den Download der TMC-Datei.
5.
Aktivieren Sie die Konfiguration.
⇨
Die Variable ist für den Server freigegeben.
I/O UA Client konfigurieren
1.
Legen Sie in demselben SPS-Projekt eine weitere Variable „nQuickStartIn“ vom Datentyp INT an und definieren Sie diese als Eingangsvariable (AT%I*). Dies soll die Variable sein, die vom OPC UA Client I/O‑Gerät über das Mapping mit der Variablen vom Server verknüpft wird.
2.
Kompilieren Sie das Projekt, sodass die Eingangsvariable im SPS‑Prozessabbild zur Verfügung steht.
3.
Fügen Sie ein neues „Virtual OPC UA Device“ hinzu.
4.
Fügen Sie einen neuen „OPC UA Client“ zum Device hinzu und öffnen Sie dessen Einstellungen.
5.
Navigieren Sie zur Registerkarte Settings. Tragen Sie dort die Server-URL des OPC UA Servers ein. In diesem Beispiel lautet diese „opc.tcp://localhost:4840“.
6.
Klicken Sie auf Add Nodes.
7.
Navigieren Sie zur freigegebenen Variable „nQuickStartOut“ auf dem OPC UA Server (zu finden unterhalb von PLC1 > MAIN) und selektieren Sie diese. Die Variable wird nun zum Prozessabbild des „Virtual OPC UA Device“ hinzugefügt.
Graphic from I_O (iv8g0st.png)
Graphic from I_O (ijr9k1v.png)
8.
Erweitern Sie die neu hinzugefügte Variable im Prozessabbild und klicken Sie doppelt auf Input > Value. Verknüpfen Sie die Variable mit der Variablen „nQuickStartIn“ aus dem SPS-Prozessabbild.
9.
Aktivieren Sie die Konfiguration.
⇨
Sie sollten nun die nachfolgend dargestellte Konfiguration vorfinden. Die beiden Prozessabbild-Variablen nQuickStartIn und nQuickStartOut sind miteinander verknüpft.
Graphic from I_O (iqj1ph6.png)
10.
Nach dem Aktivieren der Konfiguration loggen Sie sich in das SPS-Programm ein.
Graphic from I_O (imoapfd2.png)
Den aktuellen Wert können Sie auch im Prozessabbild-Mapping einsehen.
Graphic from I_O (i9p5rfm2.png)
11.
Über die Einstellungen am OPC UA Client können Sie Parameter wie z. B. die Sampling rate modifizieren.
Voraussetzungen
Produkte | Setup-Versionen | Zielplattform
TF6100 | 4.x.x | IPC oder CX (x86, x64, ARM)


Unterstützte Datentypen

Technische Einführung [image] Client I/O [image] Unterstützte Datentypen
Unterstützte Datentypen
Der OPC UA Client ermöglicht den Zugriff auf einen OPC UA Server direkt aus einer Echtzeitlogik heraus. Zum Lesen und Schreiben von Daten muss der Datentyp des OPC-UA-Knotens der TwinCAT-Umgebung zugeordnet werden (Mapping). Diese Zuordnung wird nachfolgend beschrieben.
Basisdatentypen
Die Zuordnung der Basisdatentypen wird in PLCopen OPC UA Information Model for IEC 61131-3 beschrieben.
OPC‑UA‑Datentyp | SPS‑Datentyp
Boolean | BOOL
SByte | SINT
Byte | USINT
Int16 | INT
Int32 | DINT
String | STRING
USint | BYTE
Float | REAL
Double | LREAL
UInt16 | UINT
UInt32 | UDINT
Int64 | LINT
UInt64 | ULINT
DateTime | DT
Das Mapping können Sie sowohl auf die OPC UA Client PLCopen-Funktionsbausteine als auch auf den OPC UA I/O Client anwenden.
Abgeleitete Datentypen
OPC UA definiert Basisdatentypen. Andere Datentypen sind davon abgeleitet.
Auf Client-Seite ist nur mit SPS-Datentypen Zugriff auf alle UA-Datentypen möglich. Datentypen, die von den Basisdatentypen abgeleitet sind, werden ab TcOpcUaClient Version 2.1.0.36 ebenfalls unterstützt.
Derzeit unterstützte Nicht-Basisdatentypen auf Client-Seite sind:
▪
Counter (UDINT in SPS nutzen)
Zudem unterstützt der OPC UA I/O Client strukturierte Datentypen (StructuredTypes), wenn der strukturierte Datentyp keinen nicht-unterstützten Datentyp umfasst (z. B. in einer Membervariablen). Die folgende Liste bietet einen Überblick über die derzeit nicht unterstützten Datentypen:
▪
ByteString
▪
NodeID
▪
LocalizedText (und somit AnalogItemTypen, DiscreteItemTypen)


Knoten vom Server hinzufügen

Technische Einführung [image] Client I/O [image] Knoten vom Server hinzufügen
Knoten vom Server hinzufügen
Zum Hinzufügen von Knoten eines OPC UA Target Servers zum Prozessabbild des OPC UA I/O Clients können Sie den Namensraum-Browser verwenden, der in dem I/O Client integriert ist.
Öffnen Sie die Registerkarte Settings der Client-Konfiguration und klicken Sie auf die Schaltfläche Add Nodes, um den Namensraum-Browser zu öffnen.
Der Namensraum-Browser-Dialog stellt automatisch eine Verbindung zum Target Server her, indem die spezifizierten Verbindungsparameter genutzt werden.
Innerhalb des Namensraum-Browsers können Sie die Auswählkästchen aktivieren und deaktivieren, um Knoten zum Prozessabbild hinzuzufügen oder von dort zu entfernen. Jeder ausgewählte Knoten wird im Prozessabbild als Eingangs- oder Ausgangsvariable dargestellt.
Die Eingangsvariable liest Daten vom Knoten und enthält den letzten vom Knoten erhaltenen Wert. Die Ausgangsvariable schreibt Daten zum Knoten, wenn ein Wert gesetzt wurde.


Knotenattribute

TS6100 | TwinCAT OPC UA
Technische Einführung [image] Client I/O [image] Knotenattribute
Knotenattribute
Wenn Sie auf einen Knoten im Prozessabbild doppelklicken, sehen Sie die UA-Attribute mit ihren aktuellen Werten zu dem Zeitpunkt, zu dem das Fenster geöffnet wurde.
Über das Auswahlkästchen Provide timestamp and status code variables fügen Sie dem Prozessabbild weitere Variablen hinzu, die zu Diagnosezwecken verwendet werden können.


Methodenaufruf

Technische Einführung [image] Client I/O [image] Methodenaufruf
Methodenaufruf
Der OPC UA I/O Client unterstützt den Aufruf von Servermethoden. Sie können eine Methode zu dem Prozessabbild wie jede andere Variable hinzufügen. Die „Eingangsargumente“ der Methode sind dann als Ausgangsvariable im Prozessabbild verfügbar, wohingegen die „Ausgangsargumente“ als Eingangsvariablen hinzugefügt werden. Zusätzliche Eingangs- und Ausgangsvariablen, z. B. bExecute, bBusy, bError, werden zu dem Prozessabbild hinzugefügt, so dass die Methode aufgerufen werden kann.
Beispiel: Methode auf Server
Beispiel: Methode nach dem Hinzufügen zum Prozessabbild
Sie können dann ein Mapping zwischen den Eingangs-/Ausgangsvariablen und den SPS-Variablen erstellen.
Aufruf einer Methode
Um eine Methode aufzurufen, setzen Sie die Ausgangsvariable bExecute auf TRUE. Über die Eingangsvariablen nErrorID, bDone, bBusy, bError können Sie prüfen, ob ein Methodenaufruf abgeschlossen wurde und erfolgreich war.


StructuredTypes

Technische Einführung [image] Client I/O [image] StructuredTypes
StructuredTypes
Der OPC UA I/O Client unterstützt Lese-/Schreibvorgänge bei strukturierten Datentypen (StructuredTypes). StructuredTypes können Sie dem Prozessabbild wie jede andere Variable auch hinzufügen. Beim Hinzufügen eines StructuredTypes zum Prozessabbild wird der zu parsende Typ dem Typsystem von TwinCAT hinzugefügt, um z. B. einfach von einer SPS-Anwendung verwendet zu werden.
Beispiel: StructuredType auf dem Server
In diesem Beispiel enthält der Server einen Knoten des strukturierten Datentyps „Person“, der verschiedene Membervariablen enthält (Name, Height, Weight, Gender).
Beispiel: StructuredTypes im Prozessabbild
Nachdem Sie einen Knoten dem Prozessabbild hinzugefügt haben, enthält das Prozessabbild den Knoten und die strukturellen Informationen des Typs, z. B. ob eine einzige Membervariable des Knotens gelesen oder geschrieben werden soll.
StructuredTypes im Typsystem von TwinCAT
Der Datentyp wird dem Typsystem von TwinCAT hinzugefügt. Die „Value“ Tree Items haben dann diesen Datentyp.
Sie können den Datentyp auch im Typsystem von TwinCAT unter SYSTEM > Type System einsehen.
Zur Unterscheidung des Datentyps von anderen Datentypen können Sie in den Einstellungen des OPC UA Clients ein Präfix hinzufügen. Grafik aus Structured data types (ihl6uo8.png)
Mapping eines StructuredType
Da jeder StructuredType dem Typsystem von TwinCAT hinzugefügt wird, ist das Mapping der Variablen einfach. Erstellen Sie eine Eingangs-/Ausgangsvariable dieses Datentyps und anschließend ein Mapping.


Datenaufnahme

Technische Einführung [image] Client I/O [image] Datenaufnahme
Datenaufnahme
Abtastraten konfigurieren Sie jeweils auf Gerätebasis. Sie öffnen die Konfiguration mit einem Doppelklick auf das OPC-UA-Client-Gerät. Der Bereich Process Data Configuration zeigt verschiedene Parameter, um die Geschwindigkeit der Datenerfassung von einem Server zu beeinflussen.
Parameter | Beschreibung
Read Cycle Time | Spezifiziert, wie schnell Variablen zyklisch gelesen werden.
Write Cycle Time | Legt fest, wie häufig ein Schreibbefehl auf dem OPC-UA-Kanal ausgelöst wird. Wenn sich ein Variablenwert innerhalb einer spezifizierten Zykluszeit mehrfach ändert, wird nur der letzte Wert auf den OPC-UA-Kanal geschrieben.
ReadList | Lesebefehle auf dem OPC-UA-Kanal werden gebündelt, um Bandbreite einzusparen. Dieser Parameter spezifiziert, wie viele Variablen in einen einzigen Lesebefehl auf dem OPC-UA-Kanal aufgenommen werden. Die Beschriftung dahinter gibt an, wie viele Lesebefehle sich aus der aktuellen Konfiguration ergeben.
Array Single Write | Bei Aktivierung wird jeder Schreibvorgang als ein einziger Schreibbefehl auf dem OPC-UA-Kanal ausgeführt.


Sicherheit

Technische Einführung [image] Client I/O [image] Sicherheit
Sicherheit
Weiterführende Informationen
•
Übersicht
•
Zertifikatsaustausch


Übersicht

Technische Einführung [image] Client I/O [image] Sicherheit [image] Übersicht
Übersicht
Sicherheit ist eine zentrale Anforderung bei der Entwicklung von OPC UA. Sie wird in verschiedenen Bereichen adressiert:
▪
Verschlüsselung
▪
Integrität
▪
Authentifizierung
Die Vertraulichkeit der ausgetauschten Information wird durch die Verschlüsselung der ausgetauschten Nachrichten sichergestellt. Dabei werden moderne Kryptographie-Algorithmen verwendet. Um auch den zukünftigen Sicherheitsanforderungen gewachsen zu sein, können im Nachhinein noch stärkere und modernere Algorithmen einer Anwendung hinzugefügt werden, ohne das Protokoll zu verändern.
Entsprechend der Anforderungen der jeweiligen Anwendung können verschiedene Sicherheitsstufen gewählt werden. In einigen Bereichen ist es ausreichend die Nachrichten zu signieren, um Änderungen durch Dritte auszuschließen, in anderen Fällen dürfen Daten auch nicht von Dritten gelesen werden und ein zusätzliches Verschlüsseln der Nachrichten ist erforderlich.
TF6100 OPC UA bietet die folgenden Security-Level (Security-Endpunkte) an, mit denen sich Clients verbinden können:
▪
None: Keine Sicherheit
▪
Sign: Signiert Nachrichten
▪
Sign & Encrypt: Signiert und verschlüsselt Nachrichten
Das Signieren der Nachrichten verhindert das Ändern des Inhalts einer Nachricht durch einen Dritten. So wird verhindert, dass beispielsweise eine Schreibanweisung zum Öffnen eines Schalters durch einen Dritten verfälscht wird und der Schalter stattdessen geschlossen wird.
OPC‑UA‑Anwendungen identifizieren sich über so genannte Software- und Applikationsinstanz-Zertifikate. Mithilfe von Software-Zertifikaten ist es möglich, bestimmten Client-Anwendungen einen erweiterten Zugriff auf Informationen eines OPC UA Servers zu geben, beispielsweise für das Engineering eines OPC UA Servers. Durch Applikationsinstanz-Zertifikate kann sichergestellt werden, dass ein OPC UA Server nur mit vorkonfigurierten Clients kommuniziert. Ein Client kann durch das Applikationsinstanz-Zertifikat des Servers sicherstellen, dass er mit dem richtigen Server spricht (ähnlich der Zertifikate eines Web-Browsers). Die Berücksichtigung dieser Zertifikate ist optional, d. h. ein OPC UA Server kann auch jedem Client den gleichen Zugriff abhängig der Benutzerrechte geben.
Der TwinCAT OPC UA Client und der TwinCAT OPC UA Server erzeugen ein selbst-signiertes Zertifikat während des ersten Startvorgangs. Dieses Zertifikat besteht aus einem privaten und einem öffentlichen Schlüssel. Der private Schlüssel wird in dem Verzeichnis \PKI\CA\private und der entsprechende öffentliche Schlüssel in dem Verzeichnis \PKI\CA\certs abgelegt. Wenn ein beliebiger OPC UA Client eine gesicherte Verbindung über einen der Security-Endpunkte (Sign, Sign&Encrypt) mit dem Server herstellen will, muss der Client den öffentlichen Schlüssel des OPC UA Servers kennen. Umgekehrt muss der OPC UA Server den öffentlichen Schlüssel des Clients kennen. Dieser sogenannte Schlüsselaustausch wird in den folgenden Artikeln beschrieben:
▪
Authentifizierung
▪
Zertifikatsaustausch
▪
Zugriffsrechte


Zertifikatsaustausch

Technische Einführung [image] Client I/O [image] Sicherheit [image] Zertifikatsaustausch
Zertifikatsaustausch
Die Kommunikation zwischen einem OPC UA Client und einem OPC UA Server kann optional durch Kommunikation mit einem gesicherten Endpunkt abgesichert werden. Standardmäßig generieren sowohl der TwinCAT OPC UA Server als auch der TwinCAT OPC UA Client beim ersten Start ein maschinenspezifisches, selbstsigniertes Zertifikat zur Authentifizierung.
Wenn Sie in Ihrer Umgebung eine solche verschlüsselte Kommunikationsverbindung verwenden möchten, müssen Sie ein Vertrauensverhältnis zwischen OPC UA Server und OPC UA Client herstellen.
Grafik aus Certificate exchange (i1oenvg2.png)
Vertrauenseinstellungen auf dem Server
Möchten Sie einen oder mehrere OPC UA Clients über Zertifikate am OPC UA Server authentifizieren, so muss der OPC UA Server den öffentlichen Schlüsseln der Clients vertrauen. Dies kann zum Beispiel über das Dateisystem erfolgen. Der Server verwaltet die Vertrauenseinstellungen für Zertifikate über das Dateisystem.
▪
Vertrauenswürdige Zertifikate: %InstallDir%\Server\PKI\CA\trusted\certs
▪
Abgewiesene Zertifikate: %InstallDir%\Server\PKI\CA\rejected\certs
Durch Verschieben von Client-Zertifikaten zwischen diesen Verzeichnissen können die Vertrauenseinstellungen entsprechend angepasst werden.
Client-Zertifikat auslesen
Nachfolgend wird ein einfacher Weg beschrieben, wie Sie an das Client-Zertifikat gelangen. Hierbei bauen Sie, ohne vorher das Client-Zertifikat auf den UA Server kopiert zu haben, eine Verbindung zum UA Server unter Verwendung eines sicheren Endpunkts auf (z. B. Basic128Rsa15/Sign&Encrypt). DieVerbindung wird vom UA Server initial natürlich abgewiesen, da dieser dem UA Client zum derzeitigen Zeitpunkt noch nicht vertraut. Der TwinCAT OPC UA Client würde in diesem Fall z. B. den Fehler 0xE4DD0102 zurückliefern. Nach Abweisen der Verbindungsaufforderung speichert der UA Server jedoch eine Kopie des Client-Zertifikats im oben genannten „Rejected“-Verzeichnis ab. Der Name des Zertifikats entspricht hierbei dem „Thumbprint“ des Zertifikats und lässt sich somit eindeutig dem Client-Zertifikat zuordnen. Diese Datei können Sie nun direkt in das oben genannte „Trusted“-Verzeichnis verschieben, damit der UA Server bei allen weiteren Verbindungsanforderungen dem UA Client vertraut und die Verbindung akzeptiert.
OPC UA Servers beim OPC UA Client bekannt machen
Abhängig vom verwendeten OPC UA Client müssen eventuell unterschiedliche Schritte vorgenommen werden, damit der OPC UA Client dem OPC UA Server vertraut. Typischerweise erfolgt bei Client‑Applikationen mit grafischer Benutzeroberfläche ein Warnhinweis bei der ersten Verbindung mit dem Server, wobei das Server-Zertifikat dann als vertrauenswürdig eingestuft werden kann.
Die folgende Anweisung ist daher nur für den TwinCAT OPC UA Client gültig.
Der öffentliche Schlüssel des OPC UA Servers befindet sich als DER-Datei in dem folgenden Verzeichnis: %InstallDir%\Server\PKI\CA\own\certs
Kopieren Sie die Datei beim TwinCAT OPC UA Client in das entsprechende „Trusted“-Verzeichnis: %InstallDir%\Client\PKI\CA\certs


Client PLCopen

Technische Einführung [image] Client PLCopen
Client PLCopen
Weiterführende Informationen
•
Übersicht
•
Unterstützte Datentypen
•
Best Practice
•
Sicherheit


Übersicht

Technische Einführung [image] Client PLCopen [image] Übersicht
Übersicht
Der TwinCAT OPC UA Client bietet mehrere Möglichkeiten direkt aus der Steuerungslogik heraus mit einem oder mehreren OPC UA Servern zu kommunizieren. Zum einen steht eine OPC‑UA‑Schnittstelle direkt aus der SPS zur Verfügung, bei der über PLCopen genormte Funktionsbausteine eine Verbindung mit einem OPC UA Server initiiert werden kann. Zum anderen gibt es ein OPC-UA-Client-I/O‑Gerät, das eine einfache, Mapping-basierte Schnittstelle bietet.
SPS‑Funktionsbausteine
Die folgende Tabelle gibt einen Überblick über die angebotenen Funktionalitäten:
Funktionalität | Beschreibung | Relevante Funktionsbausteine
Connect/Disconnect | Herstellen und Trennen von Verbindungen zu OPC UA Servern. | UA_Connect UA_Disconnect
Polling (Read/Write) | Lesen und Schreiben von Variablen im UA-Namensraum im Polling-Modus. Beinhaltet keine Subscriptions. | UA_Connect UA_Disconnect UA_Read UA_Write UA_GetNamespaceIndex UA_NodeGetHandle UA_NodeReleaseHandle
Method-Call | Ausführen von Methoden im UA‑Namensraum. | UA_Connect UA_Disconnect UA_MethodGetHandle UA_MethodReleaseHandle UA_MethodCall
Security | Herstellen einer verschlüsselten Verbindung zu einem OPC UA Server. | UA_Connect UA_Disconnect
Die Schnittstellen jedes Funktionsbausteins werden im Abschnitt SPS API beschrieben.
I/O-Gerät
Weitere Informationen zum TwinCAT OPC UA Client I/O-Gerät finden Sie im Abschnitt Client I/O > Schnelleinstieg.


Unterstützte Datentypen

Technische Einführung [image] Client PLCopen [image] Unterstützte Datentypen
Unterstützte Datentypen
Der OPC UA Client ermöglicht einen Zugriff auf OPC UA Server direkt aus der Echtzeitlogik heraus. Um Daten zu lesen und zu schreiben, müssen die Datentypen beider Umgebungen zugeordnet werden (Mapping). Nachfolgend wird diese Zuordnung beschrieben.
Basisdatentypen
Die Zuordnung der Basisdatentypen wird in PLCopen OPC UA Information Model for IEC 61131-3 beschrieben.
OPC‑UA‑Datentyp | SPS‑Datentyp
Boolean | BOOL
SByte | SINT
Byte | USINT
Int16 | INT
Int32 | DINT
String | STRING
USint | BYTE
Float | REAL
Double | LREAL
UInt16 | UINT
UInt32 | UDINT
Int64 | LINT
UInt64 | ULINT
DateTime | DT
Abgeleitete Datentypen
OPC UA definiert Basisdatentypen. Andere Datentypen sind davon abgeleitet.
Auf Client-Seite ist nur mit SPS-Datentypen Zugriff auf alle UA-Datentypen möglich. Datentypen, die von den Basisdatentypen abgeleitet sind, werden ab TcOpcUaClient Version 2.1.0.36 ebenfalls unterstützt.
Derzeit unterstützte Nicht-Basisdatentypen auf Client-Seite sind:
▪
Counter (UDINT in SPS nutzen)
Zugriff auf Arrays
Beim Anlegen eines Knotenhandle prüft das System die Zugriffsmöglichkeiten auf den Knoten. Weitere Prüfungen erfolgen beim Lesen und Schreiben.
Für den Zugriff auf Array-Knoten sowie Ein- und Ausgabeparameter von Methodenaufrufen müssen bestimmte Bedingungen erfüllt sein.
▪
Für den Zugriff auf Knoten: Array-Dimension und Datenlänge müssen beim Lesen und Schreiben zu den bereitgestellten Daten passen.
▪
Lesen von Zeichenketten: Sobald eine Zeichenkette die vorgegebene Länge für SPS‑Zeichenketten überschreitet, schlägt der Lesevorgang fehl.
▪
Es werden nur Array-Dimensionen bis zu drei Ebenen unterstützt.


Best Practice

Technische Einführung [image] Client PLCopen [image] Best Practice
Best Practice
Weiterführende Informationen
•
Wie Kommunikationsparameter zu bestimmen sind
•
Wie eine Verbindung hergestellt wird
•
Wie die Knoten auszulesen sind
•
Wie Knoten zu schreiben sind
•
Wie Methoden aufzurufen sind


Wie Kommunikationsparameter zu bestimmen sind

Technische Einführung [image] Client PLCopen [image] Best Practice [image] Wie Kommunikationsparameter zu bestimmen sind
Wie Kommunikationsparameter zu bestimmen sind
Im Allgemeinen wird ein grafischen OPC UA Client verwendet, um die Attribute eines Knotens oder Methoden zu bestimmen, die zusammen mit den SPS-Funktionsbausteinen verwendet werden müssen, z. B.:
▪
Node Identifier
▪
Node Namespace Index und entsprechender Namespace URI
▪
Node Data Type
▪
Method Node ID und Object Node ID
Die folgende Dokumentation verwendet den generischen OPC UA Client UA Expert als Beispiel. Dieser Client kann von den Websites von Unified Automation erworben werden: www.unified-automation.com.
Node Identifier
Eine allgemeine Aufgabe besteht aus dem Lesen oder Schreiben von Variablen, die im Hinblick auf OPC UA im Allgemeinen als Knoten bezeichnet werden.
Knoten sind durch die folgenden drei Attribute gekennzeichnet:
▪
NamespaceIndex: Namensraum, in dem sich der Knoten befindet, z. B. die SPS-Laufzeit
▪
Identifier: Eindeutiger Bezeichner des Knotens innerhalb seines Namensraums
▪
IdentifierType: Typ des Knotens: String, Guid und Numeric
Diese Attribute stellen die sogenannte NodeID dar – die Darstellung eines Knotens auf einem OPC UA Server – und werden von manchen Funktionsbausteinen benötigt.
Mithilfe von UA Expert können Sie die Attribute eines Knotens einfach bestimmen, indem Sie eine Verbindung zum OPC UA Server aufbauen und zum gewünschten Knoten browsen. Die Attribute sind dann im Attributes-Panel sichtbar.
Beispiel:
Grafik aus General information (inhhs0l2.png)
Node NamespaceIndex und entsprechender NamespaceURI
Nach der OPC‑UA‑Spezifikation kann der Namespace Index (wie vorstehend wiedergegeben) ein dynamisch generierter Wert sein. Daher müssen OPC UA Clients immer den entsprechenden NamespaceURI zur Auflösung des NamespaceIndex verwenden, bevor ein Knotenhandle erfasst wird.
Um den NamespaceIndex für einen NamespaceURI zu erfassen, verwenden Sie den Funktionsbaustein UA_GetNamespaceIndex. Den hierfür notwendigen NamespaceURI können Sie mithilfe von UA Expert bestimmen, indem Sie eine Verbindung zum OPC UA Server aufbauen und zum Knoten NamespaceArray browsen.
Grafik aus General information (i5q6eif.png)
Dieser Knoten enthält Informationen über alle eingetragenen Namespaces auf dem OPC UA Server. Die entsprechenden NamespaceURIs sind im Attributes-Panel sichtbar.
Beispiel:
Grafik aus General information (ibn3o203.png)
Im Abschnitt Node Identifier wird im Beispiel eine NodeID gezeigt, in der der NamespaceIndex 5 ist. Nach dem in der Abbildung gezeigten NamespaceArray ist der entsprechende NamespaceURI urn://SVENG-NB04/BeckhoffAutomation/Ua/PLC1. Dieser URI kann nun für den Funktionsbaustein UA_GetNamespaceIndex verwendet werden. Der OPC UA Server stellt sicher, dass der URI immer derselbe bleibt, auch nach einem Neustart. Da sich der gezeigte NamespaceIndex jedoch verändern kann, sollten für die spätere Nutzung mit anderen Funktionsbausteinen, z. B. UA_Read, UA_Write, zur Auflösung des korrekten NamespaceIndex immer der NamespaceURI in Kombination mit dem Funktionsbaustein UA_GetNamespaceIndex verwendet werden.
Node DataType
Der Datentyp eines Knotens ist erforderlich, um zu sehen, welcher SPS-Datentyp verwendet werden muss, um einen ausgelesenen Wert zuzuordnen oder um in einen Knoten zu schreiben. Mithilfe von UA Expert können Sie den Datentyp eine Knotens einfach bestimmen, indem Sie eine Verbindung zum OPC UA Server aufbauen und zum gewünschten Knoten browsen. Der Datentyp ist dann im Attributes-Panel sichtbar.
Beispiel:
Grafik aus General information (icm6j963.png)
In diesem Fall ist der Datentyp (DataType) „Int16“. Dieser muss einem äquivalenten Datentyp in der SPS zugeordnet werden, z. B. „INT“.
Die PLCopen IEC61131‑zu‑OPC‑UA‑Spezifikation beschreibt das definierte Datentyp-Mapping. Die folgende Tabelle ist ein Auszug aus dieser Spezifikation:
IEC61131 elementare Datentypen | OPC UAeingebaute Datentypen
BOOL | Boolean
SINT | SByte
USINT | Byte
INT | Int16
UINT | UInt16
DINT | Int32
UDINT | UInt32
LINT | Int64
ULINT | UInt64
BYTE | Byte
WORD | UInt16
DWORD | UInt32
LWORD | UInt64
REAL | Float
LREAL | Double
STRING | String
CHAR | Byte
WSTRING | String
WCHAR | UInt16
DT DATE_AND_TIME | DateTime
DATE | DateTime
TOD TIME_OF_DAY | DateTime
TIME | Double
Method NodeID und Object NodeID
Beim Aufruf von Methoden aus dem OPC‑UA‑Namensraum sind zwei Identifier erforderlich, wenn der Methodenhandle unter Verwendung des Funktionsbausteins UA_MethodGetHandle erfasst wird:
▪
ObjectNodeID: Identifiziert das UA-Objekt, das die Methode enthält
▪
MethodNodeID: Identifiziert die Methode selbst
Mithilfe von UA Expert können Sie beide NodeIDs einfach bestimmen, indem Sie eine Verbindung zum OPC UA Server aufbauen und zu der gewünschten Methode bzw. dem gewünschten UA-Objekt, das die Methode enthält, browsen.
Beispiel Methode M_Mul:
Grafik aus General information (iqsq5541.png)
Der Method Identifier ist dann im Attributes-Panel sichtbar.
Grafik aus General information (i31b57r2.png)
Beispiel Objekt fbMathematics:
Grafik aus General information (if4km5i3.png)
Der Object Identifier ist dann im Attributes-Panel sichtbar.
Grafik aus General information (idkncii3.png)


Wie eine Verbindung hergestellt wird

Technische Einführung [image] Client PLCopen [image] Best Practice [image] Wie eine Verbindung hergestellt wird
Wie eine Verbindung hergestellt wird
Im nachfolgenden Abschnitt wird beschrieben, wie Sie die Funktionsbausteine TcX_PLCopen_OpcUa verwenden, um eine Verbindung zu einem lokalen oder remote OPC UA Server herzustellen. Diese Verbindung kann dann verwendet werden, um weitere Funktionalitäten aufzurufen, z. B. Knoten auslesen oder schreiben, oder Methoden aufrufen.
Der Abschnitt beinhaltet folgende Themen:
▪
Übersicht
▪
Schematischer Arbeitsablauf
▪
Allgemeine Hinweise
▪
Code-Ausschnitt
Übersicht
Die folgenden Funktionsbausteine sind erforderlich, um eine Verbindung zu einem OPC UA Server herzustellen und später die Sitzung zu unterbrechen: UA_Connect, UA_Disconnect.
Lesen Sie zunächst den Abschnitt Wie Kommunikationsparameter zu bestimmen sind, um bestimmte UA-Funktionalitäten besser verstehen zu können (z. B. wie NodeIdentifier bestimmt werden können).
Schematischer Arbeitsablauf
Der schematische Arbeitsablauf jedes TwinCAT OPC UA Client kann in drei verschiedene Phasen kategorisiert werden: Preparation, Work und Cleanup.
Der in diesem Abschnitt beschriebene Verwendungsfall kann wie folgt visualisiert werden:
Grafik aus How to establish a connection (i687mi41.emf)
Allgemeine Hinweise
Der Funktionsbaustein UA_Connect erfordert die folgenden Informationen, um eine Verbindung zu einem lokalen oder remote OPC UA Server herstellen zu können:
▪
Server URL
▪
Session Connect Information
Die Server URL besteht grundsätzlich aus einem Präfix, einem Hostnamen und einem Port. Das Präfix beschreibt das OPC‑UA‑Transportprotokoll, das für die Verbindung verwendet werden sollte, z. B. “opc.tcp://” für eine binäre TCP-Verbindung (Standard). Der Hostname bzw. IP-Adressenteil beschreibt die Adressinformationen des OPC‑UA‑Zielservers, z. B. „192.168.1.1“ oder „CX-12345“. Die Portnummer ist der Zielport des OPC UA Servers, z. B. „4840“. Insgesamt kann die Server URL dann wie folgt aussehen: opc.tcp://CX-12345:4840.
Code-Ausschnitt
Deklaration:
(* Declarations for UA_Connect *)
fbUA_Connect : UA_Connect;
SessionConnectInfo : ST_UASessionConnectInfo;
nConnectionHdl : DWORD;

(* Declarations for UA_Disconnect *)
fbUA_Disconnect : UA_Disconnect;

(* Declarations for state machine and output handling *)
iState : INT;
bDone : BOOL;
bBusy : BOOL;
bError : BOOL;
nErrorID : DWORD;
Implementierung:
CASE iState OF

0:
bError := FALSE;
nErrorID := 0;
SessionConnectInfo.tConnectTimeout := T#1M;
SessionConnectInfo.tSessionTimeout := T#1M;
SessionConnectInfo.sApplicationName := '';
SessionConnectInfo.sApplicationUri := '';
SessionConnectInfo.eSecurityMode := eUASecurityMsgMode_None;
SessionConnectInfo.eSecurityPolicyUri := eUASecurityPolicy_None;
SessionConnectInfo.eTransportProfileUri := eUATransportProfileUri_UATcp;
stNodeAddInfo.nIndexRangeCount := nIndexRangeCount;
stNodeAddInfo.stIndexRange := stIndexRange;
iState := iState + 1;

1:
fbUA_Connect(
Execute := TRUE,
ServerURL := ‘opc.tcp://192.168.1.1:4840’,
SessionConnectInfo := SessionConnectInfo,
Timeout := T#5S,
ConnectionHdl => nConnectionHdl);
IF NOT fbUA_Connect.Busy THEN
fbUA_Connect(Execute := FALSE);
IF NOT fbUA_Connect.Error THEN
iState := iState + 1;
ELSE
bError := TRUE;
nErrorID := fbUA_Connect.ErrorID;
nConnectionHdl := 0;
iState := 0;
END_IF
END_IF

2:
fbUA_Disconnect(
Execute := TRUE,
ConnectionHdl := nConnectionHdl);

IF NOT fbUA_Disconnect.Busy THEN
fbUA_Disconnect(Execute := FALSE);
IF NOT fbUA_Disconnect.Error THEN
iState := 0;
ELSE
bError := TRUE;
nErrorID := fbUA_Disconnect.ErrorID;
iState := 0;
nConnectionHdl := 0;
END_IF
END_IF

END_CASE


Wie die Knoten auszulesen sind

Technische Einführung [image] Client PLCopen [image] Best Practice [image] Wie die Knoten auszulesen sind
Wie die Knoten auszulesen sind
Im nachfolgenden Abschnitt wird beschrieben, wie Sie die Funktionsbaustein TcX_PLCopen_OpcUa verwenden, um einen OPC‑UA‑Knoten von einem lokalen oder remote OPC UA Server auszulesen.
Dieser Abschnitt beinhaltet folgende Themen:
▪
Übersicht
▪
Schematischer Arbeitsablauf
▪
Allgemeine Hinweise
▪
Code-Ausschnitt
Übersicht
Die folgenden Funktionsbausteine sind erforderlich, um eine Verbindung zu einem OPC UA Server herzustellen, UA-Knoten auszulesen und später die Sitzung zu unterbrechen: UA_Connect, UA_GetNamespaceIndex, UA_NodeGetHandle, UA_Read, UA_NodeReleaseHandle, UA_Disconnect.
Lesen Sie zunächst den Abschnitt Wie Kommunikationsparameter zu bestimmen sind, um bestimmte UA-Funktionalitäten besser verstehen zu können (z. B. wie NodeIdentifier bestimmt werden können) sowie den Abschnitt Wie eine Verbindung hergestellt wird.
Schematischer Arbeitsablauf
Der schematische Arbeitsablauf jedes TwinCAT OPC UA Client kann in drei verschiedene Phasen kategorisiert werden: Preparation, Work und Cleanup.
Der in diesem Abschnitt beschriebene Verwendungsfall kann wie folgt visualisiert werden:
Grafik aus How to read nodes (i4flrbo.emf)
Allgemeine Hinweise
▪
Der Funktionsbaustein UA_Connect erfordert die folgenden Informationen, um eine Verbindung zu einem lokalen oder entfernten OPC UA Server herstellen zu können (siehe auch Wie eine Verbindung hergestellt wird):
–
Server URL
–
Session Connect Information
▪
Der Funktionsbaustein UA_GetNamespaceIndex erfordert einen Connection Handle (von UA_Connect) und einen NamespaceURI zur Auflösung in einen NamespaceIndex, der später von UA_NodeGetHandle verwendet wird, um einen Knotenhandle zu erfassen (siehe auch Wie Kommunikationsparameter zu bestimmen sind).
▪
Der Funktionsbaustein UA_NodeGetHandle erfordert einen Connection Handle (von UA_Connect) und die NodeID (von ST_UANodeID), um einen Knotenhandle zu erfassen (siehe auch Wie Kommunikationsparameter zu bestimmen sind).
▪
Der Funktionsbaustein UA_Read erfordert einen Connection Handle (von UA_Connect), einen Knotenhandle (von UA_NodeGetHandle) und einen Zeiger zur Zielvariablen (wo der ausgelesene Wert gespeichert werden sollte). Stellen Sie dabei sicher, dass die Zielvariable den korrekten Datentyp aufweist (siehe auch Wie Kommunikationsparameter zu bestimmen sind).
▪
Der Funktionsbaustein UA_NodeReleaseHandle erfordert einen Connection Handle (von UA_Connect) und einen Knotenhandle (von UA_NodeGetHandle).
Code-Ausschnitt
Deklaration:
(* Declarations for UA_GetNamespaceIndex *)
fbUA_GetNamespaceIndex : UA_GetNamespaceIndex;
nNamespaceIndex : UINT;

(* Declarations for UA_NodeGetHandle *)
fbUA_NodeGetHandle : UA_NodeGetHandle;
NodeID : ST_UANodeID;
nNodeHdl : DWORD;

(* Declarations for UA_Read *)
fbUA_Read : UA_Read;
stIndexRange : ARRAY [1..nMaxIndexRange] OF ST_UAIndexRange;
nIndexRangeCount : UINT;
stNodeAddInfo : ST_UANodeAdditionalInfo;
sNodeIdentifier : STRING(MAX_STRING_LENGTH) := 'MAIN.nCounter';
nReadData : INT;
cbDataRead : UDINT;

(* Declarations for UA_NodeReleaseHandle *)
fbUA_NodeReleaseHandle : UA_NodeReleaseHandle;
Implementierung:
CASE iState OF
0:
[...]

2: (* GetNS Index *)
fbUA_GetNamespaceIndex(
Execute := TRUE,
ConnectionHdl := nConnectionHdl,
NamespaceUri := sNamespaceUri,
NamespaceIndex => nNamespaceIndex
);
IF NOT fbUA_GetNamespaceIndex.Busy THEN
fbUA_GetNamespaceIndex(Execute := FALSE);
IF NOT fbUA_GetNamespaceIndex.Error THEN
iState := iState + 1;
ELSE
bError := TRUE;
nErrorID := fbUA_GetNamespaceIndex.ErrorID;
iState := 6;
END_IF
END_IF

3: (* UA_NodeGetHandle *)
NodeID.eIdentifierType := eUAIdentifierType_String;
NodeID.nNamespaceIndex := nNamespaceIndex;
NodeID.sIdentifier := sNodeIdentifier;
fbUA_NodeGetHandle(
Execute := TRUE,
ConnectionHdl := nConnectionHdl,
NodeID := NodeID,
NodeHdl => nNodeHdl);
IF NOT fbUA_NodeGetHandle.Busy THEN
fbUA_NodeGetHandle(Execute := FALSE);
IF NOT fbUA_NodeGetHandle.Error THEN
iState := iState + 1;
ELSE
bError := TRUE;
nErrorID := fbUA_NodeGetHandle.ErrorID;
iState := 6;
END_IF
END_IF

4: (* UA_Read *)
fbUA_Read(
Execute := TRUE,
ConnectionHdl := nConnectionHdl,
NodeHdl := nNodeHdl,
cbData := SIZEOF(nReadData),
stNodeAddInfo := stNodeAddInfo,
pVariable := ADR(nReadData));
IF NOT fbUA_Read.Busy THEN
fbUA_Read( Execute := FALSE, cbData_R => cbDataRead);
IF NOT fbUA_Read.Error THEN
iState := iState + 1;
ELSE
bError := TRUE;
nErrorID := fbUA_Read.ErrorID;
iState := 6;
END_IF
END_IF

5: (* Release Node Handle *)
fbUA_NodeReleaseHandle(
Execute := TRUE,
ConnectionHdl := nConnectionHdl,
NodeHdl := nNodeHdl);
IF NOT fbUA_NodeReleaseHandle.Busy THEN
fbUA_NodeReleaseHandle(Execute := FALSE);
IF NOT fbUA_NodeReleaseHandle.Error THEN
iState := iState + 1;
ELSE
bError := TRUE;
nErrorID := fbUA_NodeReleaseHandle.ErrorID;
iState := 6;
END_IF
END_IF

6:
[...]

END_CASE


Wie Knoten zu schreiben sind

Technische Einführung [image] Client PLCopen [image] Best Practice [image] Wie Knoten zu schreiben sind
Wie Knoten zu schreiben sind
Im nachfolgenden Abschnitt wird beschrieben, wie Sie die Funktionsbausteine TcX_PLCopen_OpcUa verwenden, um Werte in einem OPC‑UA‑Knoten von einem lokalen oder remote OPC UA Server zu schreiben.
Dieser Abschnitt beinhaltet folgende Themen:
▪
Übersicht
▪
Schematischer Arbeitsablauf
▪
Allgemeine Hinweise
▪
Code-Ausschnitt
Übersicht
Die folgenden Funktionsbausteine sind erforderlich, um eine Verbindung zu einem OPC UA Server herzustellen, UA-Knoten zu schreiben und später die Sitzung zu unterbrechen: UA_Connect, UA_GetNamespaceIndex, UA_NodeGetHandle, UA_Write, UA_NodeReleaseHandle, UA_Disconnect.
Lesen Sie zunächst den Abschnitt Wie Kommunikationsparameter zu bestimmen sind, um bestimmte UA-Funktionalitäten besser verstehen zu können (z. B. wie NodeIdentifier bestimmt werden können) sowie den Abschnitt Wie eine Verbindung hergestellt wird.
Schematischer Arbeitsablauf
Der schematische Arbeitsablauf jedes TwinCAT OPC UA Client kann in drei verschiedene Phasen kategorisiert werden: Preparation, Work und Cleanup.
Der in diesem Abschnitt beschriebene Verwendungsfall kann wie folgt visualisiert werden:
Grafik aus How to write nodes (i6bamlo2.emf)
Allgemeine Hinweise
▪
Der Funktionsbaustein UA_Connect erfordert die folgenden Informationen, um eine Verbindung zu einem lokalen oder remote OPC UA Server herstellen zu können (siehe auch Wie eine Verbindung hergestellt wird):
–
Server URL
–
Session Connect Information
▪
Der Funktionsbaustein UA_GetNamespaceIndex erfordert einen Connection Handle (von UA_Connect) und einen NamespaceURI zur Auflösung in einen NamespaceIndex, der später von UA_NodeGetHandle verwendet wird, um einen Knotenhandle zu erfassen (siehe auch Wie Kommunikationsparameter zu bestimmen sind).
▪
Der Funktionsbaustein UA_NodeGetHandle erfordert einen Connection Handle (von UA_Connect) und die NodeID (von ST_UANodeID), um einen Knotenhandle zu erfassen (siehe auch Wie Kommunikationsparameter zu bestimmen sind).
▪
Der Funktionsbaustein UA_Write erfordert einen Connection Handle (von UA_Connect), einen Knotenhandle (von UA_NodeGetHandle) und einen Zeiger zu einer Variablen, die den Wert enthält, der geschrieben werden soll. Stellen Sie dabei sicher, dass die Zielvariable den korrekten Datentyp aufweist (siehe auch Wie Kommunikationsparameter zu bestimmen sind).
▪
Der Funktionsbaustein UA_NodeReleaseHandle erfordert einen Connection Handle (von UA_Connect) und einen Knotenhandle (von UA_NodeGetHandle).
Code-Ausschnitt
Deklaration:
(* Declarations for UA_GetNamespaceIndex *)
fbUA_GetNamespaceIndex : UA_GetNamespaceIndex;
nNamespaceIndex : UINT;

(* Declarations for UA_NodeGetHandle *)
fbUA_NodeGetHandle : UA_NodeGetHandle;
NodeID : ST_UANodeID;
nNodeHdl : DWORD;

(* Declarations for UA_Write *)
fbUA_Write : UA_Write;
stIndexRange : ARRAY [1..nMaxIndexRange] OF ST_UAIndexRange;
nIndexRangeCount : UINT;
stNodeAddInfo : ST_UANodeAdditionalInfo;
sNodeIdentifier: STRING(MAX_STRING_LENGTH) := 'MAIN.nNumber';
nWriteData: INT := 42;

(* Declarations for UA_NodeReleaseHandle *)
fbUA_NodeReleaseHandle : UA_NodeReleaseHandle;
Implementierung:
CASE iState OF
0:
[...]

2: (* GetNS Index *)
fbUA_GetNamespaceIndex(
Execute := TRUE,
ConnectionHdl := nConnectionHdl,
NamespaceUri := sNamespaceUri,
NamespaceIndex => nNamespaceIndex
);
IF NOT fbUA_GetNamespaceIndex.Busy THEN
fbUA_GetNamespaceIndex(Execute := FALSE);
IF NOT fbUA_GetNamespaceIndex.Error THEN
iState := iState + 1;
ELSE
bError := TRUE;
nErrorID := fbUA_GetNamespaceIndex.ErrorID;
iState := 6;
END_IF
END_IF

3: (* UA_NodeGetHandle *)
NodeID.eIdentifierType := eUAIdentifierType_String;
NodeID.nNamespaceIndex := nNamespaceIndex;
NodeID.sIdentifier := sNodeIdentifier;
fbUA_NodeGetHandle(
Execute := TRUE,
ConnectionHdl := nConnectionHdl,
NodeID := NodeID,
NodeHdl => nNodeHdl);
IF NOT fbUA_NodeGetHandle.Busy THEN
fbUA_NodeGetHandle(Execute := FALSE);
IF NOT fbUA_NodeGetHandle.Error THEN
iState := iState + 1;
ELSE
bError := TRUE;
nErrorID := fbUA_NodeGetHandle.ErrorID;
iState := 6;
END_IF
END_IF

4: (* UA_Write *)
fbUA_Write(
Execute := TRUE,
ConnectionHdl := nConnectionHdl,
NodeHdl := nNodeHdl,
stNodeAddInfo := stNodeAddInfo,
cbData := SIZEOF(nWriteData),
pVariable := ADR(nWriteData));
IF NOT fbUA_Write.Busy THEN
fbUA_Write(
Execute := FALSE,
pVariable := ADR(nWriteData));
IF NOT fbUA_Write.Error THEN
iState := iState + 1;
ELSE
bError := TRUE;
nErrorID := fbUA_Write.ErrorID;
iState := 6;
END_IF
END_IF

5: (* Release Node Handle *)
fbUA_NodeReleaseHandle(
Execute := TRUE,
ConnectionHdl := nConnectionHdl,
NodeHdl := nNodeHdl);
IF NOT fbUA_NodeReleaseHandle.Busy THEN
fbUA_NodeReleaseHandle(Execute := FALSE);
IF NOT fbUA_NodeReleaseHandle.Error THEN
iState := iState + 1;
ELSE
bError := TRUE;
nErrorID := fbUA_NodeReleaseHandle.ErrorID;
iState := 6;
END_IF
END_IF

6:
[...]

END_CASE


Wie Methoden aufzurufen sind

Technische Einführung [image] Client PLCopen [image] Best Practice [image] Wie Methoden aufzurufen sind
Wie Methoden aufzurufen sind
Im nachfolgenden Abschnitt wird beschrieben, wie Sie die Funktionsbausteine TcX_PLCopen_OpcUa verwenden, um Methoden auf einem lokalen oder remote OPC UA Server aufzurufen.
Dieser Abschnitt beinhaltet folgende Themen:
▪
Übersicht
▪
Schematischer Arbeitsablauf
▪
Allgemeine Hinweise
▪
Code-Ausschnitt
Übersicht
Die folgenden Funktionsbausteine sind erforderlich, um eine Verbindung zu einem OPC UA Server herzustellen, UA-Methoden aufzurufen und später die Sitzung zu unterbrechen: UA_Connect, UA_GetNamespaceIndex, UA_MethodGetHandle, UA_MethodCall, UA_MethodReleaseHandle, UA_Disconnect.
Lesen Sie zunächst den Abschnitt Wie Kommunikationsparameter zu bestimmen sind, um bestimmte UA-Funktionalitäten besser verstehen zu können (z. B. wie MethodIdentifier bestimmt werden können) sowie den Abschnitt Wie eine Verbindung hergestellt wird.
Schematischer Arbeitsablauf
Der schematische Arbeitsablauf jedes TwinCAT OPC UA Client kann in drei verschiedene Phasen kategorisiert werden: Preparation, Work und Cleanup.
Der in diesem Abschnitt beschriebene Verwendungsfall kann wie folgt visualisiert werden:
Grafik aus How to call methods (ih9iml21.emf)
Allgemeine Hinweise
▪
Der Funktionsbaustein UA_Connect erfordert die folgenden Informationen, um eine Verbindung zu einem lokalen oder remote OPC UA Server herstellen zu können (siehe auch Wie eine Verbindung hergestellt wird):
–
Server URL
–
Session Connect Information
▪
Der Funktionsbaustein UA_GetNamespaceIndex erfordert einen Connection Handle (von UA_Connect) und einen NamespaceURI zur Auflösung in einen NamespaceIndex, der später von UA_NodeGetHandle verwendet wird, um einen Knotenhandle zu erfassen (siehe auch Wie Kommunikationsparameter zu bestimmen sind).
▪
Der Funktionsbaustein UA_MethodGetHandle erfordert einen Connection Handle (von UA_Connect), eine ObjectNodeID und eine MethodNodeID, um einen Methodenhandle zu erfassen (siehe auch Wie Kommunikationsparameter zu bestimmen sind).
▪
Der Funktionsbaustein UA_MethodCall erfordert einen Connection Handle (von UA_Connect), einen Methodenhandle (von UA_MethodGetHandle) und Informationen über die Eingangs- und Ausgangsargumente der Methode, die aufgerufen werden soll. Informationen über die Eingangsargumente werden durch die Eingangsparameter pInputArgInfo und pInputArgData von UA_MethodCall repräsentiert. Information über die Ausgangsparameter werden durch die pOutputArgInfo und pOutputArgData Eingangsparameter von UA_MethodCall repräsentiert. Der Eingangsparameter pOutputArgInfoAndData stellt dann einen Zeiger zu einer Struktur dar, die die Ergebnisse des Methodenaufrufs enthält, einschließlich aller Ausgangsparameter. In dem nachfolgenden Code-Ausschnitt werden die pInputArgInfo und pInputArgData Parameter in der M_Init-Methode berechnet und erstellt.
▪
Der Funktionsbaustein UA_NodeReleaseHandle erfordert einen Connection Handle (von UA_Connect) und einen Methodenhandle (von UA_MethodGetHandle).
Code-Ausschnitt
Initialisierungsmethode M_Init des Funktionsbausteins, der den UA-Methodenaufruf enthält
MEMSET(ADR(nInputData),0,SIZEOF(nInputData));
nArg := 1;

(********** Input parameter 1 **********)
InputArguments[nArg].DataType := eUAType_Int16;
InputArguments[nArg].ValueRank := -1; (* Scalar = -1 or Array *)
InputArguments[nArg].ArrayDimensions[1] := 0; (* Number of Dimension in case its an array *)
InputArguments[nArg].nLenData := SIZEOF(numberIn1); (* Length if its a STRING *)
IF nOffset + SIZEOF(numberIn1) > nInputArgSize THEN
bInputDataError := TRUE;
RETURN;
ELSE
MEMCPY(ADR(nInputData)+nOffset,ADR(numberIn1),SIZEOF(numberIn1)); (* VALUE in BYTES FORM *)
nOffset := nOffset + SIZEOF(numberIn1);
END_IF
nArg := nArg + 1;

(********** Input parameter 2 **********)
InputArguments[nArg].DataType := eUAType_Int16;
InputArguments[nArg].ValueRank := -1; (* Scalar = -1 or Array *)
InputArguments[nArg].ArrayDimensions[1] := 0; (* Number of Dimension in case its an array *)
InputArguments[nArg].nLenData := SIZEOF(numberIn2); (* Length if its a STRING *)
IF nOffset + SIZEOF(numberIn2) > nInputArgSize THEN
bInputDataError := TRUE;
RETURN;
ELSE
MEMCPY(ADR(nInputData)+nOffset,ADR(numberIn2),SIZEOF(numberIn2));(* VALUE in BYTES FORM *)
nOffset := nOffset + SIZEOF(numberIn2);
END_IF

cbWriteData := nOffset;
Deklaration:
(* Declarations for UA_GetNamespaceIndex *)
fbUA_GetNamespaceIndex : UA_GetNamespaceIndex;
nNamespaceIndex : UINT;

(* Declarations for UA_MethodGetHandle *)
fbUA_MethodGetHandle: UA_MethodGetHandle;
ObjectNodeID: ST_UANodeID;
MethodNodeID: ST_UANodeID;
nMethodHdl: DWORD;

(* Declarations for UA_MethodCall *)
fbUA_MethodCall: UA_MethodCall;
sObjectNodeIdIdentifier : STRING(MAX_STRING_LENGTH) := 'MAIN.fbMathematics';
sMethodNodeIdIdentifier : STRING(MAX_STRING_LENGTH) := 'MAIN.fbMathematics#M_Mul';
nAdrWriteData: PVOID;
numberIn1: INT := 42; // change according to input value and data type
numberIn2: INT := 42; // change according to input value and data type
numberOutPro: DINT; // result (output parameter of M_Mul())
cbWriteData: UDINT; // calculated automatically by M_Init()
InputArguments: ARRAY[1..2] OF ST_UAMethodArgInfo; // change according to input parameters
stOutputArgInfo: ARRAY[1..1] OF ST_UAMethodArgInfo; // change according to output parameters
stOutputArgInfoAndData: ST_OutputArgInfoAndData;
nInputData: ARRAY[1..4] OF BYTE; // numberIn1(INT16)(2) + numberIn2(INT16)(2)
nOffset: UDINT; // calculated by M_Init()
nArg: INT; // used by M_Init()

(* Declarations for UA_MethodReleaseHandle *)
fbUA_MethodReleaseHandle: UA_MethodReleaseHandle;
Implementierung:
CASE iState OF
0:
[...]

2: (* GetNS Index *)
fbUA_GetNamespaceIndex(
Execute := TRUE,
ConnectionHdl := nConnectionHdl,
NamespaceUri := sNamespaceUri,
NamespaceIndex => nNamespaceIndex);
IF NOT fbUA_GetNamespaceIndex.Busy THEN
fbUA_GetNamespaceIndex(Execute := FALSE);
IF NOT fbUA_GetNamespaceIndex.Error THEN
iState := iState + 1;
ELSE
bError := TRUE;
nErrorID := fbUA_GetNamespaceIndex.ErrorID;
iState := 7;
END_IF
END_IF

3: (* Get Method Handle *)
ObjectNodeID.eIdentifierType := eUAIdentifierType_String;
ObjectNodeID.nNamespaceIndex := nNamespaceIndex;
ObjectNodeID.sIdentifier := sObjectNodeIdIdentifier;
MethodNodeID.eIdentifierType := eUAIdentifierType_String;
MethodNodeID.nNamespaceIndex := nNamespaceIndex;
MethodNodeID.sIdentifier := sMethodNodeIdIdentifier;

M_Init();

IF bInputDataError = FALSE THEN
iState := iState + 1;
ELSE
bBusy := FALSE;
bError := TRUE;
nErrorID := 16#70A; //out of memory
END_IF

4: (* Method Get Handle *)
fbUA_MethodGetHandle(
Execute := TRUE,
ConnectionHdl := nConnectionHdl,
ObjectNodeID := ObjectNodeID,
MethodNodeID := MethodNodeID,
MethodHdl => nMethodHdl);
IF NOT fbUA_MethodGetHandle.Busy THEN
fbUA_MethodGetHandle(Execute := FALSE);
IF NOT fbUA_MethodGetHandle.Error THEN
iState := iState + 1;
ELSE
bError := TRUE;
nErrorID := fbUA_MethodGetHandle.ErrorID;
iState := 6;
END_IF
END_IF

5: (* Method Call *)
stOutputArgInfo[1].nLenData := SIZEOF(stOutputArgInfoAndData.pro);
fbUA_MethodCall(
Execute := TRUE,
ConnectionHdl := nConnectionHdl,
MethodHdl := nMethodHdl,
nNumberOfInputArguments := nNumberOfInputArguments,
pInputArgInfo := ADR(InputArguments),
cbInputArgInfo := SIZEOF(InputArguments),
pInputArgData := ADR(nInputData),
cbInputArgData := cbWriteData,
pInputWriteData := 0,
cbInputWriteData := 0,
nNumberOfOutputArguments := nNumberOfOutputArguments,
pOutputArgInfo := ADR(stOutputArgInfo),
cbOutputArgInfo := SIZEOF(stOutputArgInfo),
pOutputArgInfoAndData := ADR(stOutputArgInfoAndData),
cbOutputArgInfoAndData := SIZEOF(stOutputArgInfoAndData));
IF NOT fbUA_MethodCall.Busy THEN
fbUA_MethodCall(Execute := FALSE);
IF NOT fbUA_MethodCall.Error THEN
iState := iState + 1;
numberOutPro := stOutputArgInfoAndData.pro;
ELSE
bError := TRUE;
nErrorID := fbUA_MethodCall.ErrorID;
iState := 6;
END_IF
END_IF

6: (* Release Method Handle *)
fbUA_MethodReleaseHandle(
Execute := TRUE,
ConnectionHdl := nConnectionHdl,
MethodHdl := nMethodHdl);
IF NOT fbUA_MethodReleaseHandle.Busy THEN
fbUA_MethodReleaseHandle(Execute := FALSE);
bBusy := FALSE;
IF NOT fbUA_MethodReleaseHandle.Error THEN
iState := 7;
ELSE
bError := TRUE;
nErrorID := fbUA_MethodReleaseHandle.ErrorID;
iState := 7;
END_IF
END_IF

7:
[...]

END_CASE


Sicherheit

Technische Einführung [image] Client PLCopen [image] Sicherheit
Sicherheit
Weiterführende Informationen
•
Übersicht
•
Zertifikatsaustausch


Übersicht

Technische Einführung [image] Client PLCopen [image] Sicherheit [image] Übersicht
Übersicht
Sicherheit ist eine zentrale Anforderung bei der Entwicklung von OPC UA. Sie wird in verschiedenen Bereichen adressiert:
▪
Verschlüsselung
▪
Integrität
▪
Authentifizierung
Die Vertraulichkeit der ausgetauschten Information wird durch die Verschlüsselung der ausgetauschten Nachrichten sichergestellt. Dabei werden moderne Kryptographie-Algorithmen verwendet. Um auch den zukünftigen Sicherheitsanforderungen gewachsen zu sein, können im Nachhinein noch stärkere und modernere Algorithmen einer Anwendung hinzugefügt werden, ohne das Protokoll zu verändern.
Entsprechend der Anforderungen der jeweiligen Anwendung können verschiedene Sicherheitsstufen gewählt werden. In einigen Bereichen ist es ausreichend die Nachrichten zu signieren, um Änderungen durch Dritte auszuschließen, in anderen Fällen dürfen Daten auch nicht von Dritten gelesen werden und ein zusätzliches Verschlüsseln der Nachrichten ist erforderlich.
TF6100 OPC UA bietet die folgenden Security-Level (Security-Endpunkte) an, mit denen sich Clients verbinden können:
▪
None: Keine Sicherheit
▪
Sign: Signiert Nachrichten
▪
Sign & Encrypt: Signiert und verschlüsselt Nachrichten
Das Signieren der Nachrichten verhindert das Ändern des Inhalts einer Nachricht durch einen Dritten. So wird verhindert, dass beispielsweise eine Schreibanweisung zum Öffnen eines Schalters durch einen Dritten verfälscht wird und der Schalter stattdessen geschlossen wird.
OPC‑UA‑Anwendungen identifizieren sich über so genannte Software- und Applikationsinstanz-Zertifikate. Mithilfe von Software-Zertifikaten ist es möglich, bestimmten Client-Anwendungen einen erweiterten Zugriff auf Informationen eines OPC UA Servers zu geben, beispielsweise für das Engineering eines OPC UA Servers. Durch Applikationsinstanz-Zertifikate kann sichergestellt werden, dass ein OPC UA Server nur mit vorkonfigurierten Clients kommuniziert. Ein Client kann durch das Applikationsinstanz-Zertifikat des Servers sicherstellen, dass er mit dem richtigen Server spricht (ähnlich der Zertifikate eines Web-Browsers). Die Berücksichtigung dieser Zertifikate ist optional, d. h. ein OPC UA Server kann auch jedem Client den gleichen Zugriff abhängig der Benutzerrechte geben.
Der TwinCAT OPC UA Client und der TwinCAT OPC UA Server erzeugen ein selbst-signiertes Zertifikat während des ersten Startvorgangs. Dieses Zertifikat besteht aus einem privaten und einem öffentlichen Schlüssel. Der private Schlüssel wird in dem Verzeichnis \PKI\CA\private und der entsprechende öffentliche Schlüssel in dem Verzeichnis \PKI\CA\certs abgelegt. Wenn ein beliebiger OPC UA Client eine gesicherte Verbindung über einen der Security-Endpunkte (Sign, Sign&Encrypt) mit dem Server herstellen will, muss der Client den öffentlichen Schlüssel des OPC UA Servers kennen. Umgekehrt muss der OPC UA Server den öffentlichen Schlüssel des Clients kennen. Dieser sogenannte Schlüsselaustausch wird in den folgenden Artikeln beschrieben:
▪
Authentifizierung
▪
Zertifikatsaustausch
▪
Zugriffsrechte


Zertifikatsaustausch

Technische Einführung [image] Client PLCopen [image] Sicherheit [image] Zertifikatsaustausch
Zertifikatsaustausch
Die Kommunikation zwischen einem OPC UA Client und einem OPC UA Server kann optional durch Kommunikation mit einem gesicherten Endpunkt abgesichert werden. Standardmäßig generieren sowohl der TwinCAT OPC UA Server als auch der TwinCAT OPC UA Client beim ersten Start ein maschinenspezifisches, selbstsigniertes Zertifikat zur Authentifizierung.
Wenn Sie in Ihrer Umgebung eine solche verschlüsselte Kommunikationsverbindung verwenden möchten, müssen Sie ein Vertrauensverhältnis zwischen OPC UA Server und OPC UA Client herstellen.
Grafik aus Certificate exchange (i1oenvg2.png)
Vertrauenseinstellungen auf dem Server
Möchten Sie einen oder mehrere OPC UA Clients über Zertifikate am OPC UA Server authentifizieren, so muss der OPC UA Server den öffentlichen Schlüsseln der Clients vertrauen. Dies kann zum Beispiel über das Dateisystem erfolgen. Der Server verwaltet die Vertrauenseinstellungen für Zertifikate über das Dateisystem.
▪
Vertrauenswürdige Zertifikate: %InstallDir%\Server\PKI\CA\trusted\certs
▪
Abgewiesene Zertifikate: %InstallDir%\Server\PKI\CA\rejected\certs
Durch Verschieben von Client-Zertifikaten zwischen diesen Verzeichnissen können die Vertrauenseinstellungen entsprechend angepasst werden.
Client-Zertifikat auslesen
Nachfolgend wird ein einfacher Weg beschrieben, wie Sie an das Client-Zertifikat gelangen. Hierbei bauen Sie, ohne vorher das Client-Zertifikat auf den UA Server kopiert zu haben, eine Verbindung zum UA Server unter Verwendung eines sicheren Endpunkts auf (z. B. Basic128Rsa15/Sign&Encrypt). DieVerbindung wird vom UA Server initial natürlich abgewiesen, da dieser dem UA Client zum derzeitigen Zeitpunkt noch nicht vertraut. Der TwinCAT OPC UA Client würde in diesem Fall z. B. den Fehler 0xE4DD0102 zurückliefern. Nach Abweisen der Verbindungsaufforderung speichert der UA Server jedoch eine Kopie des Client-Zertifikats im oben genannten „Rejected“-Verzeichnis ab. Der Name des Zertifikats entspricht hierbei dem „Thumbprint“ des Zertifikats und lässt sich somit eindeutig dem Client-Zertifikat zuordnen. Diese Datei können Sie nun direkt in das oben genannte „Trusted“-Verzeichnis verschieben, damit der UA Server bei allen weiteren Verbindungsanforderungen dem UA Client vertraut und die Verbindung akzeptiert.
OPC UA Servers beim OPC UA Client bekannt machen
Abhängig vom verwendeten OPC UA Client müssen eventuell unterschiedliche Schritte vorgenommen werden, damit der OPC UA Client dem OPC UA Server vertraut. Typischerweise erfolgt bei Client‑Applikationen mit grafischer Benutzeroberfläche ein Warnhinweis bei der ersten Verbindung mit dem Server, wobei das Server-Zertifikat dann als vertrauenswürdig eingestuft werden kann.
Die folgende Anweisung ist daher nur für den TwinCAT OPC UA Client gültig.
Der öffentliche Schlüssel des OPC UA Servers befindet sich als DER-Datei in dem folgenden Verzeichnis: %InstallDir%\Server\PKI\CA\own\certs
Kopieren Sie die Datei beim TwinCAT OPC UA Client in das entsprechende „Trusted“-Verzeichnis: %InstallDir%\Client\PKI\CA\certs


Gateway

Technische Einführung [image] Gateway
Gateway
Weiterführende Informationen
•
Übersicht
•
Schnelleinstieg
•
Lizenzierung
•
Szenarien
•
Konfigurator
•
Migration von Tx6120
•
Sicherheit


Übersicht

TS6100 | TwinCAT OPC UA
Technische Einführung [image] Gateway [image] Übersicht
Übersicht
Das TwinCAT OPC UA Gateway ist die neueste Erweiterung des TS6100/TF6100-Softwareprodukts. Es beinhaltet nicht nur eine herkömmliche OPC‑DA‑Schnittstelle, um ältere OPC‑COM‑DA‑Anwendungen mit dem TwinCAT OPC UA Server zu verbinden und kann demzufolge als der Nachfolger des alten TwinCAT OPC DA Servers (TS6120/TF6120) betrachtet werden, sondern es bietet auch eine OPC‑UA‑Schnittstelle, um mehrere grundlegende TwinCAT OPC UA Server in einen zentralen OPC‑UA‑Serverkanal zu bündeln.
Grafik aus Overview (imgmlqb.png)


Schnelleinstieg

Technische Einführung [image] Gateway [image] Schnelleinstieg
Schnelleinstieg
Das TS6100/TF6100‑Setup installiert automatisch das TwinCAT OPC UA Gateway und registriert die Anwendung als einen Windows Service. Das Setup konfiguriert automatisch den Zugang zu einem TwinCAT OPC UA Server, der auf demselben Computer wie das Gateway läuft.
Wenn dem Gateway mehr als ein OPC UA Server hinzugefügt werden oder der Server auf einem anderen Computer läuft, müssen Änderungen an der Standardkonfiguration vorgenommen werden. Verwenden Sie den Konfigurator, um diese Einstellungen zu konfigurieren.
Konfiguration des TwinCAT OPC UA Servers
Prüfen Sie die Konfiguration des OPC UA Servers und vergewissern Sie sich, dass er wie erwartet arbeitet, bevor Sie fortfahren.
Für weitere Informationen bezüglich der Konfiguration des OPC UA Servers lesen Sie den Schnelleinstieg im Abschnitt „OPC UA Server“.
Schnelleinstieg OPC COM DA
Um einen OPC COM DA Client mit dem Gateway zu verbinden, starten Sie den Client und stellen Sie eine Verbindung zu der folgenden ProgId her:
UnifiedAutomation.UaGateway.1
Grafik aus Quick Start (Capture.PNG)
Beim Durchsuchen des Gateway werden ein oder mehrere OPC UA Server im Namensraum des Gateway sichtbar.
Grafik aus Quick Start (Capture2.PNG)
Schnelleinstieg OPC UA
Das Gateway bietet nicht nur eine OPC‑COM‑DA‑Schnittstelle, sondern erlaubt die Aggregation von einem oder mehreren OPC UA Servern. Hierzu öffnet das Gateway ebenfalls eine OPC‑UA‑Schnittstelle. Das Gateway ist über folgende OPC UA Server URL erreichbar:
opc.tcp://[HostnameOrIpAddressOrLocalhost]:48050
Grafik aus Quick Start (iis6mv71.png)
Der Namensraum des Gateway beinhaltet dann alle zugrunde liegenden TwinCAT OPC UA Server.
Grafik aus Quick Start (ihjcbaf1.png)


Lizenzierung

TS6100 | TwinCAT OPC UA
Technische Einführung [image] Gateway [image] Lizenzierung
Lizenzierung
Das TwinCAT OPC UA Gateway wird kostenfrei geliefert. Es ist kein weiterer Lizenzerwerb erforderlich.
Beachten Sie, dass die Gateway‑Komponente ausschließlich für die Verbindung mit TwinCAT OPC UA Servern verwendet werden kann. Die Verbindung mit UA Servern von Drittanbietern wird programmierungstechnisch verhindert. Wenn die Umgebung die Verbindung mit einem UA Server eines Drittanbieters erforderlich macht, wird das Unified Automation UA Gateway empfohlen. Diese kann bei http://www.unified-automation.com erworben werden.


Szenarien

Technische Einführung [image] Gateway [image] Szenarien
Szenarien
Aufgrund der offenen und flexiblen PC-basierten Automatisierungstechnik von Beckhoff kann das OPC UA Gateway auf verschiedene Arten betrieben und installiert werden. Im folgenden Abschnitt werden die verschiedenen Setup-Szenarien beschrieben und die Vor- und Nachteile einer jeden Einrichtung erläutert.
Grafik aus Setup scenarios (io8o9tb3.png)
Gateway und UA Server auf demselben Computer
Bei diesem Szenario sind das Gateway und der UA Server auf demselben Computer installiert. Das Gateway ist mit den Standardeinstellungen konfiguriert, um eine Verbindung mit dem lokalen OPC UA Server mit der folgenden Server-URL herzustellen: opc.tcp://localhost:4840.
Dieses Szenario funktioniert lediglich auf Nicht‑Windows‑CE‑Geräten.
Der TwinCAT OPC UA Server ist auch für Windows CE erhältlich, aber das Gateway ist nur für Big‑Windows-Plattformen erhältlich.
Gateway und UA Server auf verschiedenen Computern
Bei diesem Szenario sind das Gateway und der UA Server auf verschiedenen Computern installiert. Das Gateway ist für die Herstellung einer Verbindung mit dem remote OPC UA Server konfiguriert, indem dessen entsprechende Server‑URL, z. B. opc.tcp://192.168.1.1:4840, festgelegt wird.
Der OPC UA Server ist möglicherweise auf einem kleinen Embedded-Gerät (z. B. einem CX8090 mit Windows CE) installiert, während die Gateway‑Komponente auf einer getrennten Big‑Windows‑Plattform, z. B. einem zentralen Server-Gerät, installiert ist.
Gateway mit mehreren UA-Servergeräten verbunden
Beachten Sie, dass es, ungeachtet der oben beschriebenen Szenarien, möglich ist, andere TwinCAT OPC UA Server ebenfalls an das Gateway anzuschließen. So kann z. B. das Gateway konfiguriert werden, um auf folgende Server zuzugreifen:
▪
den lokalen TwinCAT OPC UA Server (z. B. opc.tcp://localhost:4840)
▪
einen remote TwinCAT OPC UA Server (z. B. opc.tcp://192.168.1.1:4840)
▪
einen anderen remote TwinCAT OPC UA Server (z. B. opc.tcp://192.168.1.21:4841)
▪
...


Konfigurator

Technische Einführung [image] Gateway [image] Konfigurator
Konfigurator
Weiterführende Informationen
•
Übersicht
•
Allgemeine Einstellungen
•
Zusätzliche UA Server
•
Zusätzliche Endpunkte
•
OPC‑COM‑DA‑Einstellungen


Übersicht

Technische Einführung [image] Gateway [image] Konfigurator [image] Übersicht
Übersicht
Das UA Gateway Administration Tool ist eine grafische Benutzerschnittstelle für die Konfiguration des Gateway.
Sie öffnen das Tool über das Kontextmenü des Gateway-Symbols in der Windows-Taskleiste. Nach dem Starten des Verwaltungswerkzeugs über den Befehl Administrate UaGateway wird die grafische Benutzerschnittstelle eingeblendet.
Grafik aus Overview (ill0qe23.png)
Die Schnittstelle bietet mehrere Konfigurationsoptionen:
▪
Allgemeine Einstellungen
▪
Zusätzliche UA Server
▪
Zusätzliche Endpunkte
▪
OPC‑COM‑DA‑Einstellungen


Allgemeine Einstellungen

Technische Einführung [image] Gateway [image] Konfigurator [image] Allgemeine Einstellungen
Allgemeine Einstellungen
Die Registerkarte General zeigt allgemeine Einstellungen des UA Gateway.
Grafik aus Overview (i4ohf7e3.png)
Autostart
In diesem Bereich können Sie das Autostart-Verhalten des UA Gateway konfigurieren.
Aktivieren UaGateway Runtime Process, um den UA Gateway Service automatisch beim Einschalten des Computers zu starten.
Aktivieren Sie Notification Area Icon, um das Symbol des Benachrichtigungsbereichs bei der Anmeldung eines Benutzers zu starten.
Startender User (Launching User)
Das UA Gateway wird als Windows NT Service ausgeführt. Diesem Service wird ein spezifischer Userkontext zugewiesen, damit COM/DCOM ordnungsgemäß konfiguriert werden kann. Der User, den Sie auswählen, wird dem UA Gateway Service zugeordnet. Darüber hinaus wird dem User ein LogOnAsService-Recht eingeräumt (so kann er/sie den Service starten) und er wird einer lokalen Nutzergruppe hinzugefügt („UaGatewayUsers“). Diese Gruppe wird der Zugriffskontrollliste (ACL, Access Control List) der lokalen Maschine hinzugefügt. Für die ordnungsgemäße COM/DCOM-Konfiguration müssen Sie dieser Gruppe alle User hinzufügen, die das UA Gateway starten und auf dieses zuzugreifen dürfen.
Konfigurationsberechtigungen (Configuration Permissions)
Es besteht die Möglichkeit, nur bestimmten Benutzern zu erlauben, die Konfiguration des UA Gateway zu verändern, sprich Verbindungen zu grundlegenden Servern hinzuzufügen oder zu entfernen. Sie können aus folgenden Einstellungen auswählen:
Jeder (Everyone) | Jeder (auch die anonym bei UA angemeldeten User), der mit dem UA Gateway in Verbindung treten kann, kann die Konfiguration verändern.
Beschränkt auf Betriebssystemnutzer (Limit to operating system users) | Nur lokale User und User von der gleichen Domain können die Konfiguration ändern.
Beschränkt auf Nutzer dieser Gruppe (Limit to users of this group) | Die Berechtigung, die Konfiguration zu ändern, nur den Usern einer bestimmten Gruppe zugestehen. Wenn nicht alle verfügbaren Gruppen in der Drop-down-Liste Group angezeigt werden (oder eine neu erstellt Gruppe fehlt), kann mittels Drücken der Schaltfläche Refresh diese Gruppe erneut eingelesen werden.
Remote‑DCOM‑Zugriff (Remote DCOM Access)
Bei der Aktivierung von Allow Remote Connection to UaGateway OPC COM Server, werden DCOM Port 135 und das ausführbare UA Gateway der Firewall-Ausnahmeliste hinzugefügt.
Wird Allow starting UaGateway by DCOM Clients deaktiviert, dann können DCOM‑Clients das UA Gateway nicht starten. In diesem Fall kann UA Gateway weiterhin mithilfe des Notification Area Icon oder den Startmenüeinträgen gestartet oder gestoppt werden.
UA‑Discovery‑Anmeldung (UA Local Discovery Server)
Aktivieren Sie Register at Local Discovery Server, wenn das UA Gateway beim OPC UA LDS (Local Discovery Server), falls einer installiert ist, angemeldet werden soll.


Zusätzliche UA Server

Technische Einführung [image] Gateway [image] Konfigurator [image] Zusätzliche UA Server
Zusätzliche UA Server
Die Registerkarte Configured UA Servers bietet Optionen für die Konfiguration der zugrunde liegenden OPC UA Server. Standardmäßig stellt das Gateway bereits eine Verbindung mit dem lokalen OPC UA Server (der auf demselben Computer läuft) her.
Grafik aus Additional OPC-UA Servers (issvfbq2.png)
Um weitere OPC UA Server zu konfigurieren oder aus der Konfiguration zu entfernen, klicken Sie auf die Plus- und Minus-Tasten unten rechts und anschließend auf Übernehmen (Apply), um die Änderungen zu speichern.


Zusätzliche Endpunkte

Technische Einführung [image] Gateway [image] Konfigurator [image] Zusätzliche Endpunkte
Zusätzliche Endpunkte
Die Registerkarte UA Endpoints zeigt die Einstellungen zur UA-Endpunktkonfiguration.
Der UA Endpunkt (Endpoint) ist die Verbindungsinformation, die ein UA Client benötigt, um eine Verbindung mit dem Gateway herzustellen.
Allgemeines
Spezifizieren Sie mithilfe der Kontrollkästchen die Anmeldemethoden, die ein Client für die Herstellung einer Verbindung mit Ihrem UA Gateway verwenden kann.
Endpunkte
An dieser Stelle können Sie alle notwendigen Einstellungen für verschiedene UA Endpunkte festlegen. Der Endpunkt wird standardmäßig mit Voreinstellungen konfiguriert. Diese stellen einen einzelnen UA Endpunkt dar, der zwei Sicherheitsoptionen anbietet: Keine und Basic128RSsa15.
Die Sicherheitsoption „Keine“ erlaubt jedem UA Client die Herstellung einer Verbindung mit dem UA Gateway und wird lediglich für die Inbetriebnahme und Prüfung empfohlen, während diese Konfiguration in der Produktionsumgebung ausgeschaltet werden sollte.
Die verschiedenen Konfigurationselemente werden in den folgenden Abschnitten beschrieben.
Netzwerkkonfiguration
Endpunkt URL | Dies ist die Endpunkt-URL des UA Gateway, so wie sie in FindServers und GetEndpoint Aufrufen zu sehen ist.
Protokoll | Dies ist das für diesen Endpunkt verwendete Protokoll.
Hostname/IP | Dies ist der Hostname des UA Gateway (es kann sich auch um die IP-Adresse des PC handeln, auf dem das UA Gateway ausgeführt wird).
Netzwerkadapter | Dies ist der Netzwerkadapter, mit dem eine Bindung herzustellen ist. Zur Auswahl stehen:
Alle | Auswahl, dass eine Bindung mit allen IP-Adressen des Computers herzustellen ist. Der Endpunkt wird über den gegebenen Anschluss auf allen IP-Adressen erreichbar sein.
Netzwerkadapter | Wählen Sie einen Netzwerkadapter und eine IP-Adresse (unten), um lediglich eine Bindung mit dieser Adresse herzustellen. Der Endpunkt wird nur für Clients erreichbar sein, die mit der ausgewählten IP-Adresse eine Verbindung herstellen.
Nur lokal | Bei dieser Auswahl stellt das UA Gateway lediglich eine Bindung mit dem Loopback-Adapter her. Der Endpunkt ist lediglich für die Clients erreichbar, die auf derselben Maschine wie das UA Gateway laufen.
Port | Dies ist das TCP-Port des Endpunkts (normalerweise 48050).
Sicherheit
In diesem Bereich können Sie die unterstützten Sicherheitseinstellungen des Endpunkts konfigurieren. Aktivieren Sie die Kontrollkästchen vor den Sicherheitsoptionen, die für einen bestimmten Endpunkt gelten sollen. Für die Optionen ungleich „Keine“, muss der (müssen die) verfügbare(n) Nachrichtensicherheitsmodus (modi) angegeben werden. Die Signierung sorgt dafür, dass Nachrichten nicht verändert werden können und dass sie zwischen den Anwendungen, die eine Verbindung hergestellt haben, ausgetauscht werden. Die Verschlüsselung garantiert, dass niemand die Nachrichten lesen kann.


OPC‑COM‑DA‑Einstellungen

Technische Einführung [image] Gateway [image] Konfigurator [image] OPC‑COM‑DA‑Einstellungen
OPC‑COM‑DA‑Einstellungen
Die Registerkarte OPC DA (COM) zeigt die Einstellungen zur Konfiguration des COM DA Servers des UA Gateway.
Im folgenden Abschnitt wird die Konfiguration des COM DA Servers des UA Gateway unter Verwendung des Administrationstools beschrieben.
Allgemeines
ItemIDs des COM DA Server werden aus dem URI‑Namensraum und dem Bezeichner des Variablenknotens im OPC‑UA‑Adressenraum gebildet. Der Namensraumteil kann im Fall eines einzigen Namensraums weggelassen werden.
Im Drop-down-Feld Default Name Space kann der standardmäßige Namensraum mit dem Namensraum eines Zugrundeliegenden OPC‑Servers festgelegt werden. Die ItemIDs dieses bestimmten Namensraums können dann mittels ausschließlicher Angabe des Bezeichners erreicht werden, weil beim Zugriff auf ein Element der standardmäßige Namensraum intern automatisch hinzugefügt wird. Dieses Merkmal kann dazu verwendet werden, alle ItemIDs im Client, der auf den UA Gateway Server zugreift, neu zu konfigurieren, wenn Letzterer als Tunnellösung für einen zugrundeliegenden COM DA Server fungiert, und um dabei die ItemIDs des ursprünglichen COM DA Servers beizubehalten.
Im zweiten Drop-down-Feld kann die Timestamp Source (Zeitstempelquelle) festgelegt werden. Folgende Optionen stehen zur Auswahl:
Interner | Die Zeitstempel werden vom OPC COM DA Server erzeugt.
SourceTimestamp | Die SourceTimestamps werden als Zeitstempel, die vom OPC COM DA Server bereitgestellt werden, verwendet.
ServerTimestamp | Die ServerTimestamps werden als Zeitstempel, die vom OPC COM DA Server bereitgestellt werden, verwendet.
Eigenschaften-Mapping vom UA zum COM DA
Bei der Herstellung der Verbindung mit dem OPC‑COM‑DA‑Server des UA Gateway werden alle sechs Standardeigenschaften (DataType, Value, Quality, TimeStamp, AccessRights und ScanRate) automatisch zugeordnet. Zugrunde liegende OPC‑Server können weitere Eigenschaften (z. B. benutzerdefinierte Eigenschaften, DI-Eigenschaften, usw.) bereitstellen. Diese Eigenschaften können herstellerspezifischen Eigenschaften (PropertyID ≧ 5000) im COM DA Server des UA Gateway zugeordnet werden.
Diese herstellerspezifischen PropertyIDs werden automatisch zugeordnet, wenn die Eigenschaften das erste Mal angefordert werden. Mithilfe dieses Dialogs können Sie die zugeordneten PropertyIDs ändern oder konfigurieren, wie die OPC‑UA‑Eigenschaften im UA-Gateway‑Adressenraum den herstellerspezifischen COM‑DA‑Eigenschaften zuzuordnen sind. Sie müssen den UA-seitigen Eigenschaftennamen und den Namensraum der Eigenschaft im UA Gateway festlegen und diese den COM DA PropertyIDs zuordnen. Bei der Herstellung der Verbindung mit dem COM‑DA‑Server des UA Gateway können Sie die verfügbaren Eigenschaften (QueryAvailableProperties) eines einzelnen OPCItems durchsuchen und dann werden Sie die zugeordneten Eigenschaften, so wie diese (im Bereich der herstellerspezifischen PropertyIDs oberhalb 5000) konfiguriert wurden, sehen können.
Drücken Sie die Tasten [+] oder [-], um eine bestimmte Eigenschaft hinzuzufügen bzw. zu entfernen. Um den Inhalt eines bestimmten Feldes zu ändern, doppelklicken Sie auf dieses und geben die gewünschten Werte ein. Wenn Sie auf einen Wert in der Spalte UA Property NameSpace URI doppelklicken, wird ein Drop-down-Menü eingeblendet, in dem Sie eine Auswahl treffen können.
Wenn Sie durch Drücken auf [+] eine neue Eigenschaft hinzufügen, werden die Werte des letzten Eintrags in die neue Zeile kopiert und die PropertyID automatisch inkrementiert.


Migration von Tx6120

Technische Einführung [image] Gateway [image] Migration von Tx6120
Migration von Tx6120
Einer der vorrangigen Zwecke des UA Gateway ist die Bereitstellung einer zukunftsfähigen Konnektivität, um das Supplement / die Function Tx6120 OPC DA zu ersetzen. Wenn Sie Tx6120 OPC DA nach UA Gateway migrieren möchten, beachten Sie die nachfolgenden Hinweise.
Standardkonfiguration
Die Standardkonfiguration des UA Gateway stellt automatisch eine Verbindung mit dem lokalen OPC UA Server her und bietet den OPC DA Clients eine OPC‑DA‑Schnittstelle. Bei einer Verbindung auf der Grundlage dieser Standardkonfiguration müssen die OPC‑DA‑Clients Folgendes berücksichtigen:
▪
Die standardmäßige ProgID des UA Gateway lautet „UnifiedAutomation.Gateway.1“. Der TwinCAT OPC DA Server verwendet eine andere ProgID („Beckhoff.TwinCATOpcServerDA“).
▪
Das UA Gateway verwendet stets eine ProgID anstelle von mehreren Klonen.
▪
Der ItemIdentifier eines OPC‑Symbols wird im UA Gateway anders erzeugt. Dieses Verhalten kann geändert werden.
Syntax eines ItemIdentifiers verändern
Die Syntax, die das UA Gateway für ItemIdentifier verwendet, kann verändert werden, damit letztere eher der Art des TwinCAT OPC DA Servers entsprechen. Standardmäßig verwendet das UA Gateway bei der Bildung seiner Identifier eine andere Syntax als der TwinCAT OPC DA Server.
Beispiel UA Gateway:
Grafik aus Migrating from Tx6120 (ijlkg2r2.png)
Beispiel TwinCAT OPC DA Server:
Grafik aus Migrating from Tx6120 (ih3fnei1.png)
Das UA Gateway verwendet ein Präfix, sodass der zugrunde liegende OPC UA Client, von dem die Variable stammt, eindeutig identifiziert werden kann.
Um das UA Gateway so zu konfigurieren, dass es seine Identifier in etwa so bildet, wie der TwinCAT OPC DA Server, sind die nachfolgenden Schritte erforderlich. Die Funktionalität wurde implementiert, um den Migrationsprozess zu vereinfachen.
1.
Öffnen Sie die UA-Gateway‑Konfigurationsdatei
C:\Program Files (x86)\UnifiedAutomation\UaGateway\bin\uagateway.config.xml
2.
Suchen Sie nach den folgenden XML-Tags in der XML-Datei:
<OpcServerConfig>
<ComDaServerConfig>
<ComDaNamespaceUseAlias>false</ComDaNamespaceUseAlias>
</ComDaServerConfig>
</OpcServerConfig>
1.
Wenn das XML-Tag ComDaNamespaceUseAlias auf „true“ gesetzt wird, können benutzerdefinierte Präfixes bestimmt werden. Suchen Sie hierfür nach dem folgenden XML-Tag in derselben XML-Datei:
<OpcServerConfig>
<UaServerConfig>
<ConfiguredNamespaces>
...
</ConfiguredNamespaces
</UaServerConfig>
</OpcServerConfig>
1.
Identifizieren Sie in dieser XML‑Struktur den TwinCAT‑OPC‑UA‑Server‑Namensraum. Standardmäßig sollte dieser folgendermaßen lauten:
<OpcServerConfig>
<UaServerConfig>
<ConfiguredNamespaces>
...
<Namespace>
<Index>...</Index>
<Uri>TcOpcUaServer/urn:Hostname:BeckhoffAutomation:Ua:PLC1</Uri>
<AllowRenameUri>false</AllowRenameUri>
<UniqueId>TcOpcUaServer#TcOpcUaServer/urn:Hostname:BeckhoffAutomation:Ua:PLC1</UniqueId>
<ComAlias>...</ComAlias>
</Namespace>
...
</ConfiguredNamespaces
</UaServerConfig>
</OpcServerConfig>
1.
Auf Ihrem Computer kann der Platzhalter „...” anders aussehen. Setzen Sie <ComAlias> auf das von Ihnen bevorzugte Präfix, zum Beispiel „PLC1“. Daraufhin werden die Bezeichner mit dem Präfix „PLC1“ gebildet.
Grafik aus Migrating from Tx6120 (i6tlpkc.png)


Sicherheit

Technische Einführung [image] Gateway [image] Sicherheit
Sicherheit
Weiterführende Informationen
•
Übersicht
•
Zertifikatsaustausch


Übersicht

Technische Einführung [image] Gateway [image] Sicherheit [image] Übersicht
Übersicht
Sicherheit ist eine zentrale Anforderung bei der Entwicklung von OPC UA. Sie wird in verschiedenen Bereichen adressiert:
▪
Verschlüsselung
▪
Integrität
▪
Authentifizierung
Die Vertraulichkeit der ausgetauschten Information wird durch die Verschlüsselung der ausgetauschten Nachrichten sichergestellt. Dabei werden moderne Kryptographie-Algorithmen verwendet. Um auch den zukünftigen Sicherheitsanforderungen gewachsen zu sein, können im Nachhinein noch stärkere und modernere Algorithmen einer Anwendung hinzugefügt werden, ohne das Protokoll zu verändern.
Entsprechend der Anforderungen der jeweiligen Anwendung können verschiedene Sicherheitsstufen gewählt werden. In einigen Bereichen ist es ausreichend die Nachrichten zu signieren, um Änderungen durch Dritte auszuschließen, in anderen Fällen dürfen Daten auch nicht von Dritten gelesen werden und ein zusätzliches Verschlüsseln der Nachrichten ist erforderlich.
TF6100 OPC UA bietet die folgenden Security-Level (Security-Endpunkte) an, mit denen sich Clients verbinden können:
▪
None: Keine Sicherheit
▪
Sign: Signiert Nachrichten
▪
Sign & Encrypt: Signiert und verschlüsselt Nachrichten
Das Signieren der Nachrichten verhindert das Ändern des Inhalts einer Nachricht durch einen Dritten. So wird verhindert, dass beispielsweise eine Schreibanweisung zum Öffnen eines Schalters durch einen Dritten verfälscht wird und der Schalter stattdessen geschlossen wird.
OPC‑UA‑Anwendungen identifizieren sich über so genannte Software- und Applikationsinstanz-Zertifikate. Mithilfe von Software-Zertifikaten ist es möglich, bestimmten Client-Anwendungen einen erweiterten Zugriff auf Informationen eines OPC UA Servers zu geben, beispielsweise für das Engineering eines OPC UA Servers. Durch Applikationsinstanz-Zertifikate kann sichergestellt werden, dass ein OPC UA Server nur mit vorkonfigurierten Clients kommuniziert. Ein Client kann durch das Applikationsinstanz-Zertifikat des Servers sicherstellen, dass er mit dem richtigen Server spricht (ähnlich der Zertifikate eines Web-Browsers). Die Berücksichtigung dieser Zertifikate ist optional, d. h. ein OPC UA Server kann auch jedem Client den gleichen Zugriff abhängig der Benutzerrechte geben.
Der TwinCAT OPC UA Client und der TwinCAT OPC UA Server erzeugen ein selbst-signiertes Zertifikat während des ersten Startvorgangs. Dieses Zertifikat besteht aus einem privaten und einem öffentlichen Schlüssel. Der private Schlüssel wird in dem Verzeichnis \PKI\CA\private und der entsprechende öffentliche Schlüssel in dem Verzeichnis \PKI\CA\certs abgelegt. Wenn ein beliebiger OPC UA Client eine gesicherte Verbindung über einen der Security-Endpunkte (Sign, Sign&Encrypt) mit dem Server herstellen will, muss der Client den öffentlichen Schlüssel des OPC UA Servers kennen. Umgekehrt muss der OPC UA Server den öffentlichen Schlüssel des Clients kennen. Dieser sogenannte Schlüsselaustausch wird in den folgenden Artikeln beschrieben:
▪
Authentifizierung
▪
Zertifikatsaustausch
▪
Zugriffsrechte


Zertifikatsaustausch

Technische Einführung [image] Gateway [image] Sicherheit [image] Zertifikatsaustausch
Zertifikatsaustausch
Die Kommunikation zwischen einem OPC UA Client und einem OPC UA Server kann optional durch Kommunikation mit einem gesicherten Endpunkt abgesichert werden. Standardmäßig generieren sowohl der TwinCAT OPC UA Server als auch der TwinCAT OPC UA Client beim ersten Start ein maschinenspezifisches, selbstsigniertes Zertifikat zur Authentifizierung.
Wenn Sie in Ihrer Umgebung eine solche verschlüsselte Kommunikationsverbindung verwenden möchten, müssen Sie ein Vertrauensverhältnis zwischen OPC UA Server und OPC UA Client herstellen.
Grafik aus Certificate exchange (i1oenvg2.png)
Vertrauenseinstellungen auf dem Server
Möchten Sie einen oder mehrere OPC UA Clients über Zertifikate am OPC UA Server authentifizieren, so muss der OPC UA Server den öffentlichen Schlüsseln der Clients vertrauen. Dies kann zum Beispiel über das Dateisystem erfolgen. Der Server verwaltet die Vertrauenseinstellungen für Zertifikate über das Dateisystem.
▪
Vertrauenswürdige Zertifikate: %InstallDir%\Server\PKI\CA\trusted\certs
▪
Abgewiesene Zertifikate: %InstallDir%\Server\PKI\CA\rejected\certs
Durch Verschieben von Client-Zertifikaten zwischen diesen Verzeichnissen können die Vertrauenseinstellungen entsprechend angepasst werden.
Client-Zertifikat auslesen
Nachfolgend wird ein einfacher Weg beschrieben, wie Sie an das Client-Zertifikat gelangen. Hierbei bauen Sie, ohne vorher das Client-Zertifikat auf den UA Server kopiert zu haben, eine Verbindung zum UA Server unter Verwendung eines sicheren Endpunkts auf (z. B. Basic128Rsa15/Sign&Encrypt). DieVerbindung wird vom UA Server initial natürlich abgewiesen, da dieser dem UA Client zum derzeitigen Zeitpunkt noch nicht vertraut. Der TwinCAT OPC UA Client würde in diesem Fall z. B. den Fehler 0xE4DD0102 zurückliefern. Nach Abweisen der Verbindungsaufforderung speichert der UA Server jedoch eine Kopie des Client-Zertifikats im oben genannten „Rejected“-Verzeichnis ab. Der Name des Zertifikats entspricht hierbei dem „Thumbprint“ des Zertifikats und lässt sich somit eindeutig dem Client-Zertifikat zuordnen. Diese Datei können Sie nun direkt in das oben genannte „Trusted“-Verzeichnis verschieben, damit der UA Server bei allen weiteren Verbindungsanforderungen dem UA Client vertraut und die Verbindung akzeptiert.
OPC UA Servers beim OPC UA Client bekannt machen
Abhängig vom verwendeten OPC UA Client müssen eventuell unterschiedliche Schritte vorgenommen werden, damit der OPC UA Client dem OPC UA Server vertraut. Typischerweise erfolgt bei Client‑Applikationen mit grafischer Benutzeroberfläche ein Warnhinweis bei der ersten Verbindung mit dem Server, wobei das Server-Zertifikat dann als vertrauenswürdig eingestuft werden kann.
Die folgende Anweisung ist daher nur für den TwinCAT OPC UA Client gültig.
Der öffentliche Schlüssel des OPC UA Servers befindet sich als DER-Datei in dem folgenden Verzeichnis: %InstallDir%\Server\PKI\CA\own\certs
Kopieren Sie die Datei beim TwinCAT OPC UA Client in das entsprechende „Trusted“-Verzeichnis: %InstallDir%\Client\PKI\CA\certs


Sample Client

Technische Einführung [image] Sample Client
Sample Client
Weiterführende Informationen
•
Übersicht
•
Sichere Verbindung mit OPC UA Server herstellen
•
UA-Namensraum durchsuchen
•
Watchliste verwenden


Übersicht

Technische Einführung [image] Sample Client [image] Übersicht
Übersicht
Ab Version 1.6.80 des TwinCAT OPC UA Servers wird ein kleines Programm „UA Sample Client“ automatisch installiert. Das Programm ermöglicht Ihnen, den OPC‑UA‑Namensraum zu durchsuchen und die UA‑Server‑Installierung zu testen. Es befindet sich im Windows Startmenü und im Installationsverzeichnis des/der Supplements/Function. Sie können das Programm sowohl direkt auf dem UA Server als auch auf einem Computer in Ihrem Netzwerk ausführen.
Derzeit bietet der UA Sample Client die folgenden Funktionalitäten:
▪
Verbindung mit OPC UA Server herstellen
▪
Sichere Verbindung mit OPC UA Server herstellen (siehe Sichere Verbindung mit OPC UA Server herstellen)
▪
Durchsuchen des UA‑Namensraums eines OPC UA Servers (siehe UA-Namensraum durchsuchen)
▪
Hinzufügen eines UA Nodes aus dem Namensraum in die Watchliste, die den Wert des Knotens regelmäßig liest (siehe Watchliste verwenden)
Diese Anwendung ist lediglich ein OPC‑UA‑Beispiel‑Client. Sie bietet keine anspruchsvollen Funktionalitäten, sondern wurde entwickelt, um den Benutzern eine einfach zu bedienende Schnittstelle zur Verfügung zu stellen, um erste Tests beim OPC UA Server durchzuführen
Um die Anwendung zu starten, führen Sie die Datei UA SampleClient.exe mit dem Befehl Als Administrator ausführen aus.
Endpunkte des OPC UA Servers
Der UA Sample Client verbindet sich zuerst mit einer spezifizierten Server‑URL. Der Client akquiriert alle Endpunkte des OPC UA Servers (siehe Drop-Down-Liste Endpoints). Die an den Server zurückgesandte Liste enthält dann mehr Informationen über alle verfügbaren Endpunkte, mit denen sich der Client verbinden kann. Jeder Endpunkt kann den Hostnamen des OPC UA Servers anstatt der IP-Adresse enthalten. Der Client verwendet dann die Informationen aus dem Endpunkt zur Verbindung mit dem Server.
Wenn die Namenslösung nicht im Netzwerk des Benutzers funktioniert, kann der Client die Verbindung nicht herstellen. Wenn der Endpunkt, mit dem sich der Client verbinden soll, den Hostnahmen des Servers enthält, stellen Sie sicher, dass die Namenslösung in Ihrem Netzwerk funktioniert und dass der Hostname auf dem Server erreichbar ist.


Sichere Verbindung mit OPC UA Server herstellen

Technische Einführung [image] Sample Client [image] Sichere Verbindung mit OPC UA Server herstellen
Sichere Verbindung mit OPC UA Server herstellen
1.
Geben Sie im oberen Textfeld des UA Sample Client die URL eines OPC UA Servers ein.
2.
Klicken Sie auf die Schaltfläche Get Endpoints.
⇨
Die vom UA Server bereitgestellten Endpunkte werden daraufhin in der Drop‑Down-Liste Endpoints angezeigt.
3.
Wählen Sie in diesem Beispiel den Eintrag „<SomeName>/Beckhoff/TcOpcUaServer/1 [Basic128Rsa15, SignAndEncrypt] [opc.tcp://<SomeName>:4840]“ und klicken Sie auf Connect.
Sie müssen den Public Key vom Zertifikat des UA Sample Clients auf den UA Server kopieren, damit dieser dem Sample Client „vertraut“. Anderenfalls wird der Verbindungsversuch über den sicheren Kanal vom UA Server abgewiesen („BadSecureChannelClosed“). Weitere Informationen über das Zertifikatsmanagement beim OPC UA Server finden Sie im Abschnitt Zertifikatsaustausch.
⇨
Über den Browser in der linken Hälfte des Fensters können Sie nun durch den UA‑Namensraum navigieren.


UA-Namensraum durchsuchen

TS6100 | TwinCAT OPC UA
Technische Einführung [image] Sample Client [image] UA-Namensraum durchsuchen
UA-Namensraum durchsuchen
Über den Browser in der linken Hälfte des UA Sample Client können Sie nach erfolgreichem Aufbau einer Verbindung durch den UA‑Namensraum navigieren. Unterhalb des Knotens PLC1 finden Sie das momentan laufende SPS-Programm und können sich die dort deklarierten und für UA freigegebenen Variablen anzeigen lassen.


Watchliste verwenden

TS6100 | TwinCAT OPC UA
Technische Einführung [image] Sample Client [image] Watchliste verwenden
Watchliste verwenden
Sie können SPS-Variablen aus dem UA-Namensraum in eine Watchlist einfügen, zum Beispiel um deren Werte zyklisch von dem UA Sample Client lesen zu lassen. Öffnen Sie dazu das Kontextmenü einer Variablen und wählen Sie Add to Watchlist. Die Variable wird daraufhin in die Watchlist übernommen und deren Werte werden automatisch zyklisch aus der SPS ausgelesen.


Konfiguration

Konfiguration
Konfiguration
Weiterführende Informationen
•
Setup-Version 3.x.x
•
Setup-Version 4.x.x


Setup-Version 3.x.x

Konfiguration [image] Setup-Version 3.x.x
Setup-Version 3.x.x
Weiterführende Informationen
•
Übersicht
•
Data Access
•
Historical Access
•
Server Security
•
Alarms and Conditions
•
Online Panel


Übersicht

Konfiguration [image] Setup-Version 3.x.x [image] Übersicht
Übersicht
Dieser Abschnitt beschreibt den Umgang mit dem TwinCAT‑OPC‑UA‑Konfigurator. Der OPC‑UA‑Konfigurator parametriert den OPC UA Server bzw. ist eine grafische Benutzeroberfläche zur Konfiguration der Datei ServerConfig.xml. Er bietet folgende Konfigurationsmöglichkeiten:
▪
Hinzufügen/Entfernen von Geräten zum Data Access (SPS-Laufzeiten, TwinCAT‑3‑C++‑Instanzen, I/O-Tasks)
▪
Aktivieren/Deaktivieren von Historical Access
▪
Aktivieren/Deaktivieren von anonymen Zugriffen bzw. Benutzername/Passwort‑Authentifizierung
▪
Neustart oder Shutdown des OPC UA Servers
Beim Starten des OPC‑UA‑Konfigurators wird automatisch die derzeit aktive Konfiguration des OPC UA Servers geladen, die sich standardmäßig als Datei ServerConfig.xml im Verzeichnis \%InstallDir%\Server\ befindet. Sie können über das Menü aber auch andere ServerConfig.xml-Dateien laden, abspeichern und aktivieren.
Die Benutzeroberfläche des OPC‑UA‑Konfigurators besteht aus folgenden Bereichen:
▪
Menü-Bereich (Menu): Speichern und Aktivieren von Konfigurationen
▪
Kategorien-Bereich (Category): Gruppiert die Einzelparameter in verschiedene Kategorien, z. B. Data Access
▪
Parameter-Bereich (Parameters): Einzelparameter zum Aktivieren/Deaktivieren bestimmter Features
Weitere Informationen zu den einzelnen Konfigurationsparametern finden Sie in den Beschreibungen der einzelnen Kategorien:
▪
Data Access
▪
Historical Access
▪
Server Security
▪
Alarms and Conditions
▪
Online Panel


Data Access

Konfiguration [image] Setup-Version 3.x.x [image] Data Access
Data Access
Die Registerkarte Data Access zeigt die Konfigurationseinstellung für TwinCAT‑Runtime‑Geräte. Hier konfigurieren Sie ein Gerät, wenn es über OPC UA verfügbar sein soll.
Einstellung | Beschreibung
Name | Anzeige Name der TwinCAT Runtime im OPC‑UA‑Namensraum
AdsNetId | AmsNetId der TwinCAT Runtime. 127.0.0.1.1.1 für eine lokale Laufzeit oder die entsprechende AmsNetId eines Remote-Geräts. ADS-Routen müssen konfiguriert werden, wenn mit einem Remote-Gerät kommuniziert wird.
AdsPort | AdsPort der TwinCAT‑Runtime, z. B. 851 für die erste TwinCAT‑3‑SPS‑Laufzeit.
SymbolFile | Symboldatei, die Informationen über alle verfügbaren Variablen und Objektinstanzen der Laufzeit enthält.
AdsTimeout | Timeout-Einstellung, wenn mit der Ziel-Runtime kommuniziert wird. Es wird empfohlen, diese Einstellung auf dem Standardwert zu belassen.
AdsTimeSuspend | TimeSuspend-Einstellung, wenn mit der Ziel-Runtime kommuniziert wird. Es wird empfohlen, diese Einstellung auf dem Standardwert zu belassen. TimeSuspend Timeout wird ausgelöst, wenn eine Ziel-Runtime vorübergehend nicht verfügbar ist. Der OPC UA Server startet nach TimeSuspend einen erneuten Kommunikationsversuch.
Typ | Typ der Ziel-Runtime, mit der der OPC UA Server kommunizieren soll, z. B. TwinCAT 3 SPS, TwinCAT 2 SPS, ...
AccessMode | Der Zugriffsmodus wird normalerweise nur benötigt, wenn der OPC UA Server mit einer auf einem Beckhoff BC/BX‑Gerät gehosteten Laufzeit kommunizieren soll. In diesem Fall muss die entsprechende Einstellung aktiviert werden. Ansonsten kann die Standardeinstellung übernommen werden.
LegacyArrayHandling | Wenn auf veralteten OPC UA Clients Array-Elemente als separate UA-Knoten verfügbar sein müssen, aktivieren Sie diese Einstellung.
LegacyUriFormat | Aktiviert verschiedene Namensschemata zum Generieren von NamespaceUri, wie im Abschnitt NamespaceURI generieren beschrieben.
ReleaseHandles | Aktiviert die Freigabe von Handles für TwinCAT‑Laufzeitsymbole, wenn UaClients einen Knoten nicht mehr „benötigen“. Das ist der Fall, wenn ein Knoten aus der Überwachung entfernt wird, (DeleteMonitoredItem) oder der Überwachungsmodus eines Elements deaktiviert wird.
ForceIdentifierCase | Gilt nur für die Typen TPY und SYM. Erzwingt die Groß- oder Kleinschreibung der Bezeichner aller Knoten.
Disabled | Kontrollkästchen anklicken, um die Laufzeit zu deaktivieren, sodass sie nicht im OPC‑UA‑Namensraum erscheint.
Weitere Informationen über laufzeitspezifische Parameter finden Sie im Abschnitt Server.


Historical Access

Konfiguration [image] Setup-Version 3.x.x [image] Historical Access
Historical Access
Die Registerkarte Historical Access zeigt die allgemeinen Einstellungen für die Konfiguration von Historical Access. Hier aktivieren und konfigurieren Sie die Speichermedien, die für Historical Access verwendet werden sollen.
Grafik aus Historical Access (ic7f01n1.png)
Weitere Informationen zu Historical Access erhalten Sie im Abschnitt Server.


Server Security

Konfiguration [image] Setup-Version 3.x.x [image] Server Security
Server Security
Die Registerkarte Server Security zeigt die allgemeinen Einstellungen zu Sicherheits- und Endpunktmechanismen des OPC UA Servers.
Grafik aus Security (in6g9r9.png)
Einstellungen | Beschreibung
Benutzeridentität (User Identity) | Aktivierung oder Deaktivierung einer bestimmten Benutzeridentität, z. B. Deaktivierung des Kontrollkästchens „Anonymous Access“ (Anonymer Zugriff), um eine Benutzerauthentifizierung zu erzwingen.
Endpunkte (Endpoints) | Aktivierung oder Deaktivierung bestimmter Endpunkte, z. B. zur Deaktivierung des Endpunkts „No security“ (Keine Sicherheit), um UA Clients zu zwingen, sich mit dem Endpunkt „Sign and Encrypt“ (Signieren und Verschlüsseln) zu verbinden.
Konfiguration des Namensraums (Configuration namespace) | Ermöglicht die Aktivierung oder Deaktivierung der Konfiguration des Namensraums und die Einstellung einer spezifischen Sicherheitsstufe, die für den Zugriff dieses Namensraums erforderlich ist (Benutzerauthentifizierung erforderlich).
Benutzerverwaltung (User Management) | Ermöglicht die Konfiguration bestehender Benutzerkonten und stellt eine Zugriffsebene für jedes Konto ein. Zugriffsebenen werden derzeit lediglich zur Konfiguration des Zugriffs auf die Konfiguration des Namensraums verwendet. Beachten Sie, dass das Benutzerkonto - wenn der Computer, auf dem der OPC UA Server läuft, ein Mitglied einer Windows-Domäne ist - ebenfalls ein Konto in dieser Domäne sein kann.
Client-Zertifikate (Client certificates) | Ermöglicht das Verschieben von OPC‑UA‑Client‑Zertifikaten zwischen den Vertrauenslisten „Abgelehnt“ und „Akzeptiert“. Hier können Client-Zertifikate einfach identifiziert, ihnen vertraut oder diese abgelehnt werden, wenn die Clients mit einem der sicheren Endpunkte verbunden werden.


Alarms and Conditions

Konfiguration [image] Setup-Version 3.x.x [image] Alarms and Conditions
Alarms and Conditions
Der Konfigurator Alarms and Conditions (A&C) ist ein separates grafisches Tool. Es erstellt eine XML-basierte Konfigurationsdatei, mit der der OPC UA Server seine A&C-Konfiguration erstellt.
Graphic from Alarms _ Conditions (io325pi2.png)
Der A&C‑Konfigurator befindet sich im Installationsverzeichnis von TwinCAT OPC UA: C:\TwinCAT\Functions\TF6100-OPC-UA\Win32\ConfiguratorAc.
Verwendung des A&C-Konfigurators
1.
Stellen Sie eine Verbindung mit dem OPC UA Server her, dessen Alarms and Conditions konfiguriert werden sollen. Geben Sie dazu die Server-URL ein und wählen Sie einen Endpunkt, mit dem sich der Konfigurator verbinden soll.
2.
Wenn die Verbindung hergestellt und der Namensraum des Servers sichtbar ist, erstellen Sie einen oder mehrere ConditionController. Ein ConditionController ist eine administrative Einheit, die die aktuelle Alarmkonfiguration als eine oder mehrere Conditions enthält.
3.
Wählen Sie einen ConditionController aus und erzeugen Sie eine oder mehrere Conditions, indem Sie zu überwachende Variablen in das Conditions-Fenster in der unteren rechten Ecke ziehen und dort ablegen.
4.
Folgen Sie schrittweise den Anweisungen der QuickStart-Information des Konfigurators.
Graphic from Alarms _ Conditions (i596mue1.png)


Online Panel

Konfiguration [image] Setup-Version 3.x.x [image] Online Panel
Online Panel
Das Online Panel erweitert den OPC‑UA‑Konfigurator um OPC‑UA‑Client‑Funktionalitäten. Es ermöglicht Ihnen die lokale oder Fernverbindung mit einem OPC UA Server zwecks Erhalt von Diagnose- oder Verwaltungsfunktionalitäten.
Grafik aus Online Panel (ids7tsp2.png)
Bereich/Registerkarte
Beschreibung
Serverinformationen (Server information)
Liefert allgemeine Diagnoseinformationen des derzeit mit dem OPC UA Server verbundenen Teilnehmers. Mögliche nützliche Informationen:
▪
Lizenzstatus
▪
Anzahl der derzeit hergestellten OPC‑UA‑Client‑Sitzungen
▪
Anzahl verfügbarer Knoten (Berechnung kann einige Zeit in Anspruch nehmen)
▪
Server-Version
Server-Protokollierung (Server Logging)
Stellt Funktionalitäten zur Verfügung, um eine Log-Datei auf dem OPC UA Server zu aktivieren. Diese sollte aber nur dann verwendet werden, wenn sie vom Beckhoff-Support empfohlen wurde, da die Erstellung der Log-Datei die allgemeine Systemleistung beeinträchtigen kann.
Gerätezustände (Device States)
Stellt Diagnoseinformationen über jedes auf dem OPC UA Server konfigurierte ADS-Gerät zur Verfügung. Diese Information kann sehr hilfreich sein, wenn die Verbindung mit einem ADS-Gerät überprüft werden muss. Häufig auftretendes Konfigurationsproblem kann z.B. darin bestehen, dass die entsprechende Symboldatei (TPY, TMC) nicht vom OPC UA Server geladen werden kann. Das Device States Panel wird in diesem Falle eine entsprechende Fehlermeldung ausgeben.


Setup-Version 4.x.x

Konfiguration [image] Setup-Version 4.x.x
Setup-Version 4.x.x
Weiterführende Informationen
•
Übersicht
•
Neues Projekt anlegen
•
Zielgerät auswählen
•
ADS-Geräte hinzufügen
•
Konfiguration downloaden und uploaden
•
Konfigurationsdateien importieren und exportieren
•
Historical Access konfigurieren
•
Alarms and Conditions konfigurieren
•
Alarmtexte konfigurieren
•
Endpunkte konfigurieren
•
Zertifikatsvertrauenseinstellungen konfigurieren
•
Sicherheitseinstellungen konfigurieren
•
Server neu starten
•
Troubleshooting und Logging


Übersicht

Konfiguration [image] Setup-Version 4.x.x [image] Übersicht
Übersicht
Das TF6100‑Setup (Version 4.x.x und höher) beinhaltet die aktuellste Version des OPC‑UA‑Server‑Konfigurators. Dieser wurde für ein durchgängiges und einheitliches Engineering-Konzept in Microsoft Visual Studio als eigener Projekttyp integriert. Sie können alle unterschiedlichen Facetten vom OPC UA Server konfigurieren und hierbei auch Source‑Control‑Mechanismen wie z. B. Team Foundation Server oder Subversion Integrationen verwenden.
Graphic from Übersicht (2017-10-24 09_37_24-Windows 7 Professional (32-bit) (Sicherungspunkt 2) [wird ausgeführt] - Oracle V.png)
Symbolleiste
Über die Symbolleiste des OPC‑UA‑Konfigurators können Sie eine Verbindung mit einem lokalen oder remote TwinCAT OPC UA Server herstellen. Für den jeweils selektierten Server können Sie dann sämtliche Konfigurationseinstellungen vornehmen.
Graphic from Übersicht (irmvtih1.png)
Wenn die Symbolleiste nicht eingeblendet ist, können Sie diese der Oberfläche über das Menü View > Toolbars hinzufügen.
Graphic from Übersicht (ifr7kfv2.png)
Voraussetzungen
Produkte | Setup-Versionen | Zielplattform
TF6100 | 4.x.x | IPC oder CX (x86, x64, ARM)


Neues Projekt anlegen

Konfiguration [image] Setup-Version 4.x.x [image] Neues Projekt anlegen
Neues Projekt anlegen
Das Projektpaket vom OPC‑UA‑Konfigurator bindet sich in das sogenannte Connectivity-Paket ein. Sie können dieses beim Anlegen eines neuen Visual‑Studio‑Projekts auswählen.
Projektvorlage „TwinCAT Connectivity Project“:
Graphic from Anlegen eines neuen Projekts (2017-11-02 14_27_36-Windows 7 Professional (32-bit) (Sicherungspunkt 2) [wird ausgeführt] - Oracle V.png)
Projektvorlage „TwinCAT OPC-UA Server Project”:
Graphic from Anlegen eines neuen Projekts (2017-11-02 14_29_00-Windows 7 Professional (32-bit) (Sicherungspunkt 2) [wird ausgeführt] - Oracle V.png)
Voraussetzungen
Produkte | Setup-Versionen | Zielplattform
TF6100 | 4.x.x | IPC oder CX (x86, x64, ARM)


Zielgerät auswählen

Konfiguration [image] Setup-Version 4.x.x [image] Zielgerät auswählen
Zielgerät auswählen
Der OPC‑UA‑Konfigurator ermöglicht die vollständige Parametrierung des Servers über OPC UA. Ähnlich wie im TwinCAT‑XAE‑System können Sie über die Symbolleiste einen Ziel-OPC-UA-Server auswählen.
Graphic from Auswahl eines Zielgeräts (2017-11-02 14_39_54-Windows 7 Professional (32-bit) (Sicherungspunkt 2) [wird ausgeführt] - Oracle V.png)
Sämtliche Einstellungen in der Konfiguration werden dann für diesen OPC UA Server vorgenommen. Grundlage hierfür ist der sogenannte Configuration-Namespace des Servers (siehe Namensraum konfigurieren).
Graphic from Auswahl eines Zielgeräts (ito06p.png)
Voraussetzungen
Produkte | Setup-Versionen | Zielplattform
TF6100 | 4.x.x | IPC oder CX (x86, x64, ARM)


ADS-Geräte hinzufügen

Konfiguration [image] Setup-Version 4.x.x [image] ADS-Geräte hinzufügen
ADS-Geräte hinzufügen
DerOPC UA Server kann mit einem oder mehreren ADS-Geräten „sprechen“. Zur Herstellung einer Verbindung ist eine Route zu dem jeweiligen ADS-Gerät erforderlich. Im OPC-UA-Konfigurator werden ADS-Geräte in der Facette Data Access angelegt, konfiguriert und somit dem OPC UA Server bekannt gegeben.
Neue ADS-Geräte fügen Sie der Konfiguration über den Kontextmenübefehl Add new Device Type hinzu.
Graphic from Hinzufügen von ADS Geräten (Configurator_AddNewDataAccessDevice.png)
Nach Ausführung des Befehls öffnet sich ein Dialogfenster, in dem Sie die Verbindungsparameter für dieses Gerät konfigurieren können, z. B. AMS Net ID, ADS-Port oder auch die Symboldatei.
Graphic from Hinzufügen von ADS Geräten (Configurator_AddNewDataAccessDeviceDialog.png)
Die Verbindungsparameter können Sie bei Bedarf nachträglich über das Eigenschaftenfenster von Visual Studio modifizieren.
Graphic from Hinzufügen von ADS Geräten (Configurator_DataAccessPropertiesWindow.png)
Symboldatei auswählen
Auf dem ausgewählten Zielgerät vorhandene Symboldateien können direkt eingelesen werden. Die Symboldateien können dabei entweder im TwinCAT‑Bootverzeichnis oder im Symbolverzeichnis des OPC UA Servers hinterlegt sein. Über den entsprechenden Dialog bei der Symboldatei-Konfiguration können Sie die Dateien selektieren.
Graphic from Hinzufügen von ADS Geräten (iodgp4h2.png)
Der TwinCAT OPC UA File Explorer kann entweder mit dem lokalen TwinCAT‑Verzeichnis oder dem Remote‑Bootverzeichnis verbunden werden. Letzteres wird über den Configuration-Namespace des Servers eingelesen (siehe Namensraum konfigurieren).
Graphic from Hinzufügen von ADS Geräten (2017-11-03 14_08_33-sveng - Remotedesktopverbindung.png)
Voraussetzungen
Produkte | Setup-Versionen | Zielplattform
TF6100 | 4.x.x | IPC oder CX (x86, x64, ARM)


Konfiguration downloaden und uploaden

Konfiguration [image] Setup-Version 4.x.x [image] Konfiguration downloaden und uploaden
Konfiguration downloaden und uploaden
Über den Konfigurator können Sie sowohl den Download/Upload von kompletten Server-Konfigurationen anstoßen als auch jede einzelne Facette (Data Access, Historical Access, etc.) einzeln auf ein Zielgerät aufspielen bzw. von dort öffnen. Die hierfür notwendigen Funktionen sind sowohl in die Symbolleiste als auch in das Kontextmenü der jeweiligen Facette eingebunden.
Konfiguration vom Zielgerät öffnen
Über die entsprechende Schaltfläche in der Symbolleisten können Sie die Konfiguration des selektierten Zielgeräts öffnen.
Graphic from Download_Upload der Konfiguration (irs51f33.png)
Siehe auch: Zielgerät auswählen
Konfiguration auf einem Zielgerät aktivieren
Über die entsprechende Schaltfläche in der Symbolleiste können Sie die aktuell geöffnete Konfiguration auf das selektierte Zielgerät herunterladen.
Graphic from Download_Upload der Konfiguration (i7rler63.png)
Siehe auch: Zielgerät auswählen
Teilkonfiguration öffnen
Über den Befehl Read Configuration from Target im Kontextmenü einer bestimmten Facette der Konfiguration können Sie die Teilkonfiguration vom selektierten Zielgerät öffnen.
Graphic from Download_Upload der Konfiguration (ijrrk6j1.png)
Siehe auch: Zielgerät auswählen
Teilkonfiguration herunterladen
Über den Befehl Write Configuration to Target im Kontextmenü einer bestimmten Facette der Konfiguration können Sie die Teilkonfiguration auf das selektierte Zielgerät herunterladen.
Graphic from Download_Upload der Konfiguration (iv2n4541.png)
Siehe auch: Zielgerät auswählen


Konfigurationsdateien importieren und exportieren

Konfiguration [image] Setup-Version 4.x.x [image] Konfigurationsdateien importieren und exportieren
Konfigurationsdateien importieren und exportieren
Die Befehle des Kontextmenüs ermöglichen den Import/Export von Konfigurationsdateien des OPC UA Servers.
Teilkonfiguration importieren
Über den Befehl Import UA Configuration im Kontextmenü einer bestimmten Facette der Konfiguration können Sie die Teilkonfiguration (z. B. Historical Access) aus einer XML-Konfigurationsdatei importieren.
Graphic from Import_Export von Konfigurationsdateien (i3tlrqm.png)
Teilkonfiguration exportieren
Über den Befehl Export UA Configuration im Kontextmenü einer bestimmten Facette der Konfiguration können Sie die Teilkonfiguration (z. B. Historical Access) in eine XML-Konfigurationsdatei exportieren.
Graphic from Import_Export von Konfigurationsdateien (im87nhb3.png)


Historical Access konfigurieren

Konfiguration [image] Setup-Version 4.x.x [image] Historical Access konfigurieren
Historical Access konfigurieren
Zur Konfiguration von Historical Access müssen zunächst die History Adapter eingerichtet werden. Hierbei handelt es sich um die unterschiedlichen Speicherorte für die historischen Daten, z. B. RAM, Datei, SQL Server.
History Adapter fügen Sie der Konfiguration über den Kontextmenübefehl Add new History Adapter hinzu.
Graphic from Konfiguration von Historical Access (Configurator_HistoricalAccessAddAdapter.png)
Je nach Adaptertyp müssen Sie weitere Parameter spezifizieren, z. B. den gewünschten Pfad zur Dateiablage oder die Zugangsdaten zum SQL Server.
Graphic from Konfiguration von Historical Access (Configurator_HistoricalAccessAddAdapter2.png)
Nachdem Sie einen History Adapter angelegt haben, können Sie dem Adapter die gewünschten Variablen hinzufügen. Die Variablen müssen zum Zeitpunkt des Engineerings bereits auf dem selektierten OPC UA Server vorliegen. Zur Selektion der Variablen können Sie den integrierten OPC UA Target Browser verwenden und die Variablen aus dem Target Browser per Drag-and-drop zum History Adapter hinzufügen.
Graphic from Konfiguration von Historical Access (Configurator_TargetBrowser.png)
Im Eigenschaftenfenster der neu hinzugefügten Variable können Sie weitere Parameter spezifizieren, z. B. die gewünschte SamplingRate oder die Größe des zu verwendenden Ringbuffers im History Adapter.
Graphic from Konfiguration von Historical Access (Configurator_HistoricalAccessPropertiesWindow.png)
Siehe auch: Zielgerät auswählen


Alarms and Conditions konfigurieren

Konfiguration [image] Setup-Version 4.x.x [image] Alarms and Conditions konfigurieren
Alarms and Conditions konfigurieren
Zur Konfiguration von Alarms and Conditions (A&C) müssen zunächst die Condition Controller eingerichtet werden. Hierbei handelt es sich um Container-Einheiten, die Alarme gruppieren.
Condition Controller fügen Sie der Konfiguration über den Kontextmenübefehl Add New Condition Controller hinzu.
Graphic from Konfiguration von Alarms _ Conditions (Configurator_AlarmsConditionsAddController.png)
Nachdem Sie einen Condition Controller angelegt haben, können Sie dem Controller die gewünschten Variablen hinzufügen und im Sinne des Alarms and Conditions überwachen. Für jede Variable wird hierbei eine Condition angelegt, welche die Parameter für die Überwachung spezifiziert. Die Variablen müssen zum Zeitpunkt des Engineerings bereits auf dem selektierten OPC UA Server vorliegen. Zur Selektion der Variablen können Sie den integrierten OPC UA Target Browser verwenden und die Variablen aus dem Target Browser per Drag-and-drop zum Condition Controller hinzufügen.
Graphic from Konfiguration von Historical Access (Configurator_TargetBrowser.png)
In dem sich öffnenden Dialogfenster können Sie den Condition-Typ und weitere Parameter für die Überwachung definieren, z. B. SamplingRate und Severity.
Graphic from Konfiguration von Alarms _ Conditions (Configurator_AlarmsConditionsAddCondition2.png)
Je nach ausgewähltem Condition-Typ können Sie zusätzliche Parameter im Eigenschaftenfenster der Condition spezifizieren. Die Schwellenwerte für den jeweiligen Condition‑Typ werden als einzelne Einträge in der Baumansicht der Konfiguration angezeigt. Auch hier können Sie die entsprechenden Parameter im Eigenschaftenfenster konfigurieren.
Graphic from Konfiguration von Alarms _ Conditions (Configurator_AlarmsConditionsPropertyWindow.png)
Anschließend müssen Sie die Alarmtexte definieren, die beim Triggern einer Condition an den OPC UA Client versendet werden sollen. Wie Sie Alarmtexte anlegen, wird im Abschnitt Alarmtexte konfigurieren beschrieben. Die Alarmtexte können Sie per Drag-and-drop auf den jeweiligen Schwellenwert einer Condition ziehen.
Graphic from Konfiguration von Alarms _ Conditions (Configurator_AlarmsConditionsDragDropAlarmText.png)
Alarmtyp OffNormal
Bei einem Alarmtyp OffNormal definieren Sie einen Normalwert, den eine Variable üblicherweise haben sollte. Wenn der Variablenwert hiervon abweicht, wird ein Alarm ausgelöst.
Graphic from Konfiguration von Alarms _ Conditions (Configurator_AlarmsConditionsOffNormalAlarmPropertyWindow.png)
Nachdem Sie den Normalwert konfiguriert haben, müssen Sie die zu versendenden Alarmtexte in dem Resources-Bereich selektieren und per Drag-and-drop auf den jeweiligen Schwellenwert der Condition ziehen.
Alarmtyp Limit
Bei einem Alarmtyp Limit definieren Sie unterschiedliche Schwellenwerte, bei deren Erreichen ein Alarm verschickt werden soll.
Graphic from Konfiguration von Alarms _ Conditions (Configurator_AlarmsConditionsLimitAlarmPropertyWindow.png)
Nachdem Sie die Schwellenwerte konfiguriert haben, müssen Sie die zu versendenden Alarmtexte in dem Resources-Bereich selektieren und per Drag-and-drop auf den jeweiligen Schwellenwert der Condition ziehen.
Voraussetzungen
Produkte | Setup-Versionen | Zielplattform
TF6100 | 4.x.x | IPC oder CX (x86, x64, ARM)
Siehe auch: Zielgerät auswählen


Alarmtexte konfigurieren

Konfiguration [image] Setup-Version 4.x.x [image] Alarmtexte konfigurieren
Alarmtexte konfigurieren
Der OPC‑UA‑Konfigurator ermöglicht die (mehrsprachige) Verwaltung von Alarmtexten, die zum Beispiel beim Alarms and Conditions verwendet werden. Die Konfiguration der Alarmtexte erfolgt in der Facette Resources. Jeder Alarmtext wird durch eine eindeutige ID identifiziert. Dieser ID können dann mehrere Sprachtexte zugeordnet werden.
Über den Befehl Add new Resource Item im Kontextmenü können Sie sogenannte „Resource Items“ anlegen.
Graphic from Konfiguration von Alarmtexten (Configurator_ResourcesAddItem.png)
Über den Befehl Add new Language Item im Kontextmenü eines „Resource Items“ fügen Sie diesem neue Sprachelemente („Language Items“) hinzu.
Graphic from Konfiguration von Alarmtexten (Configurator_ResourcesAddLanguage.png)
Im Eigenschaftenfenster können Sie ein Sprachelement weiter parametrieren, z. B. den Sprachtext und die zugeordnete Sprache. Wenn Sie die Sprache festlegen, wird automatisch die zugehörige LocaleID gesetzt. Die LocaleID wird vom OPC UA Client angefordert, um anzugeben, in welcher Sprache er Alarmtexte erwartet.
Graphic from Konfiguration von Alarmtexten (Configurator_ResourcesPropertyWindow.png)
Voraussetzungen
Produkte | Setup-Versionen | Zielplattform
TF6100 | 4.x.x | IPC oder CX (x86, x64, ARM)


Endpunkte konfigurieren

Konfiguration [image] Setup-Version 4.x.x [image] Endpunkte konfigurieren
Endpunkte konfigurieren
Die Endpunkte des OPC UA Servers geben an, welche Security-Mechanismen bei der Verbindungsherstellung eines Clients benutzt werden sollen. Diese reichen von „unverschlüsselt“ bis zu „verschlüsselt und signiert“, basierend auf verschiedenen Schlüsselstärken.
Die Endpunkte können Sie über den Konfigurator aktivieren und deaktivieren. Es kann z. B. sinnvoll sein, den unverschlüsselten Endpunkt zu deaktivieren, damit sich alle Clients nur mit gültigem und als vertrauenswürdig eingestuftem Zertifikat verbinden können.
Sie konfigurieren die Endpunkte direkt auf Ebene des OPC‑UA‑Server‑Projekts. Durch einen Doppelklick auf das Projekt können Sie in der Registerkarte UA Endpoints die entsprechenden Einstellungen vornehmen. Die Einstellungen werden nach einem Aktivieren der Konfiguration und einem anschließenden Neustart des Servers wirksam (siehe Konfiguration downloaden und uploaden und Server neu starten).
Graphic from Konfiguration der Endpunkte (Configurator_Endpoints.png)
Voraussetzungen
Produkte | Setup-Versionen | Zielplattform
TF6100 | 4.x.x | IPC oder CX (x86, x64, ARM)


Zertifikatsvertrauenseinstellungen konfigurieren

Konfiguration [image] Setup-Version 4.x.x [image] Zertifikatsvertrauenseinstellungen konfigurieren
Zertifikatsvertrauenseinstellungen konfigurieren
Die auf dem Server vorhandenen Client-Zertifikate können über den Konfigurator komfortabel verwaltet werden. In den Projekteinstellungen können Sie die Zertifikate in der Registerkarte UA Endpoints im Bereich Client certificates als vertrauenswürdig einstufen oder verweigern.
Nachdem ein OPC UA Client zum ersten Mal versucht hat, sich mit einem sicheren Endpunkt des Servers zu verbinden, wird das Client-Zertifikat auf dem Server hinterlegt und als „rejected“ deklariert. Anschließend kann der Server-Administrator das Zertifikat freischalten. Ein anschließender Verbindungsversuch des Clients mit einem gesicherten Endpunkt wird dann erfolgreich sein.
Graphic from Konfiguration von Zertifikats-Vertrauenseinstellungen (Configurator_CertificateManagementTrustList.png)


Sicherheitseinstellungen konfigurieren

Konfiguration [image] Setup-Version 4.x.x [image] Sicherheitseinstellungen konfigurieren
Sicherheitseinstellungen konfigurieren
Der OPC UA Server ermöglicht die Konfiguration von Berechtigungen auf Namespace- und Node-Ebene. Hierdurch kann sowohl der Zugriff auf ADS-Geräte (z. B. auf verschiedene SPS‑Laufzeiten) als auch Variablen feingranular eingestellt werden. Diese Sicherheitseinstellungen sind für alle ADS-Geräte verfügbar, die im Server-Namespace dargestellt werden können.
Graphic from Access Level (i6k0pr22.png)
Konfiguration
Die Konfiguration der Berechtigungen erfolgt auf Basis einer XML-basierten Konfigurationsdatei (TcUaSecurityConfig.xml), die in demselben Verzeichnis wie der Server liegt. Die Konfigurationsdatei besteht aus den drei Bereichen „Benutzer (Users)“, „Gruppen (Groups)“ und „AccessInfos“.
Benutzer (Users)
Im Bereich „Users“ können Sie Benutzerkonten konfigurieren, die vom OPC UA Server als Login akzeptiert werden sollen. Hierbei gibt es drei verschiedene Authentifizierungsmethoden:
OS (empfohlene Authentifizierungsmethode) | Es werden die Mechanismen vom Betriebssystem verwendet, um Benutzername und Passwort zu validieren. Das Benutzerkonto obliegt vollständig der Kontrolle des Betriebssystems und/oder der Domäne.
Server (nicht empfohlen) | Benutzername und Passwort sind nur dem OPC UA Server bekannt. Beide Informationen werden hierbei im Klartext in der XML-Datei hinterlegt.
None | Es wird nur der Benutzername vom Server ausgewertet, das Passwort wird ignoriert.
Benutzer können mit einem Tag <DefaultAccess> konfiguriert werden, das den Standardzugriff des Benutzers auf einen bestimmten Namespace angibt.
Benutzer können Mitglied einer oder mehrerer Gruppen sein. Dies können Sie über das Attribut MemberOf spezifizieren. Bei Mitgliedschaft in mehreren Gruppen trennen Sie die Gruppen durch ein Semikolon.
Grafik aus Konfiguration von Sicherheitseinstellungen (i602ipa.png)
Gruppen (Groups)
Um eine einfachere Konfiguration mit mehreren Benutzeraccounts zu ermöglichen, können Sie die Benutzer in Gruppen zusammenfassen.
Gruppen können ebenfalls mit einem Tag <DefaultAccess> konfiguriert werden.
Über das Attribut MemberOf können Sie Gruppen verschachteln. Bei Mitgliedschaft in mehreren Gruppen trennen Sie die Gruppen durch ein Semikolon.
Grafik aus Konfiguration von Sicherheitseinstellungen (inbgnvv1.png)
AccessInfos
Wenn eine feingranulare Einstellung von Berechtigungen auf Node-Ebene erfolgen soll, können Sie zusätzlich AccessInfos konfigurieren, welche die Zugriffsberechtigungen auf Nodes spezifizieren. Zugriffsrechte können hierbei auf Unterelemente vererbt werden. Obwohl AccessInfos die feingranularste Konfigurationsmöglichkeit von Berechtigungen ermöglichen, wird eine solche Konfiguration auch schnell unübersichtlich. Prüfen Sie daher, ob eine Konfiguration von Zugriffsrechten auf Namespace-Ebene (siehe oben) nicht ausreichend ist.
Die AccessInfo für eine Node beinhaltet die folgenden Einstellungen:
NS | Konfiguriert den NamespaceName, in dem die Node lokalisiert ist
Id | Konfiguriert den Identifier der Node, inklusive des IdentifierTypes (z. B. s = String)
Depth | Vererbungstiefe der Berechtigungen (-1 für unendlich)
User/Group | Benutzer oder Gruppe, der/die auf diese Node Zugriff erhalten soll, inklusive des AccessLevels
Grafik aus Konfiguration von Sicherheitseinstellungen (io7fnbk3.png)
AccessInfos können per Drag-and-drop von Variablen aus dem Target Browser konfiguriert werden. Die konfigurierbaren Berechtigungen sind kumulativ.
Beispielkonfiguration
Gegeben sei folgendes einfaches Steuerungsprogramm. Die Variablen sind bereits im OPC-UA-Namespace des Servers veröffentlicht. Der OPC UA Server befindet sich zunächst im Auslieferungszustand.
Grafik aus Konfiguration von Sicherheitseinstellungen (iaunslq.png)
Zugriffbeschränkungen
Der Zugriff auf den Server soll für Clients wie folgt eingeschränkt werden:
▪
Anonymous Zugriff soll deaktiviert werden.
▪
Es soll einen Benutzer „Administrator“ geben, der Vollzugriff auf den kompletten Server hat.
▪
Es soll einen Benutzer „User1“ geben, der ausschließlich Lesezugriff auf MAIN.Instance1 hat. Der Benutzer soll hierbei nicht aus dem Betriebssystem kommen, sondern nur intern im Server verwendet werden.
▪
Es soll einen Benutzer „User2“ geben, der ausschließlich Lesezugriff auf MAIN.Instance2 hat. Der Benutzer soll hierbei nicht aus dem Betriebssystem kommen, sondern nur intern im Server verwendet werden.
▪
Über eine Gruppe "Users" sollen allgemeine Zugriffsberechtigungen für alle Benutzer konfiguriert werden.
Einstellungen
Die Konfiguration des OPC UA Server wird wie folgt eingestellt:
Grafik aus Konfiguration von Sicherheitseinstellungen (ioukn0c3.png)
Einstellungen für den Benutzer „Administrator“:
Grafik aus Konfiguration von Sicherheitseinstellungen (it0baot3.png)
Einstellungen für den Benutzer „User1“:
Grafik aus Konfiguration von Sicherheitseinstellungen (imojdht3.png)
Einstellungen für den Benutzer „User2“:
Grafik aus Konfiguration von Sicherheitseinstellungen (i9c7sg02.png)
Einstellungen Access Infos „MAIN.Instance1“:
Grafik aus Konfiguration von Sicherheitseinstellungen (iddph031.png)
Einstellungen Access Infos „MAIN.Instance2“:
Grafik aus Konfiguration von Sicherheitseinstellungen (iarklrm2.png)
Einstellungen für die Gruppe „Users“:
Die Benutzergruppe wird sowohl mit grundlegendem Zugriff auf benötigte Server- und Typsystem-Namensräume ausgestattet als auch mit Read- und Browse-Berechtigungen auf den PLC1-Namensraum.
Grafik aus Konfiguration von Sicherheitseinstellungen (it7546f2.png)
Ergebnis
Nach Aktivierung der Konfiguration stellt sich der Namensraum des Servers für „User1“ nach einem Verbindungsaufbau wie folgt dar:
Grafik aus Konfiguration von Sicherheitseinstellungen (iduh9er1.png)
Auf die Node „Instance1“ hat der Benutzer nur Leserechte, was durch das Attribut UserAccessLevel deutlich wird:
Grafik aus Konfiguration von Sicherheitseinstellungen (i2336df2.png)
Der Benutzer „Administrator“ hingegen hat volle Zugriffsrechte auf alle Elemente des Namensraums:
Grafik aus Konfiguration von Sicherheitseinstellungen (iddlfkh3.png)


Server neu starten

Konfiguration [image] Setup-Version 4.x.x [image] Server neu starten
Server neu starten
Der OPC‑UA‑Konfigurator ermöglicht das Triggern eines Neustarts des OPC UA Server. Dies kann lokal oder remote erfolgen und bezieht sich auf das jeweils selektierte Zielgerät.
Verbindungsverlust
Ein Neustart des OPC UA Server führt immer zu einem Verbindungsverlust aller verbundenen Clients.
Den Neustart triggern Sie über die Symbolleiste.
Graphic from Neustart des Servers (iu8vdei2.png)
Voraussetzungen
Produkte | Setup-Versionen | Zielplattform
TF6100 | 4.x.x | IPC oder CX (x86, x64, ARM)
Siehe auch: Zielgerät auswählen


Troubleshooting und Logging

Konfiguration [image] Setup-Version 4.x.x [image] Troubleshooting und Logging
Troubleshooting und Logging
Für eine erweiterte Diagnose können Sie die Logging-Funktion des OPC UA Servers aktivieren.
Schreiben der Log-Datei
Durch das Aktivieren der Logging-Funktion auf dem Server wird eine Protokolldatei auf dem Dateisystem geschrieben. Stellen Sie sicher, dass ausreichend Speicherplatz zur Verfügung steht und setzen Sie die Logging-Parameter entsprechend (Anzahl Log-Dateien, Größe pro Log-Datei).
Performance- und Timingverhalten
Durch das Aktivieren der Protokollfunktionen verändert sich das Timing-Verhalten des OPC UA Servers. Hierdurch können je nach Plattform und Projekt Geschwindigkeitseinbußen entstehen.
Sie aktivieren die Logging-Funktion im Konfigurator des Projekts in der Registerkarte Online Panel über die Schaltfläche Activate. Sie können die Funktion je nach selektiertem Zielgerät lokal oder remote aktiveren. Die Logging-Funktion ist so lange aktiv, bis sie über den Konfigurator wieder deaktiviert oder bis der OPC UA Server neu gestartet wird.
Graphic from Troubleshooting _ Logging (Configurator_ServerLogging.png)
Activate App Trace
In den meisten Fällen ist es ausreichend ein sogenanntes „AppTrace“ zu erstellen. Es gilt: Je höher der „Trace level“, desto detailliertere (und mehr) Daten werden geschrieben.
Activate Stack Trace
In einigen wenigen Fällen ist es zusätzlich notwendig ein sogenanntes „StackTrace“ zu erstellen. Auch hier gilt: Je höher der „Trace level“, desto detailliertere (und mehr) Daten werden geschrieben.
Voraussetzungen
Produkte | Setup-Versionen | Zielplattform
TF6100 | 4.x.x | IPC oder CX (x86, x64, ARM)
Siehe auch: Auswahl eines Zielgeräts


SPS API

SPS API
SPS API
Weiterführende Informationen
•
Funktionsbausteine
•
Datentypen


Funktionsbausteine

SPS API [image] Funktionsbausteine
Funktionsbausteine
Weiterführende Informationen
•
UA_Connect
•
UA_Disconnect
•
UA_GetNamespaceIndex
•
UA_HistoryUpdate
•
UA_MethodCall
•
UA_MethodGetHandle
•
UA_MethodReleaseHandle
•
UA_NodeGetHandle
•
UA_NodeGetHandleList
•
UA_NodeReleaseHandle
•
UA_NodeReleaseHandleList
•
UA_Read
•
UA_ReadList
•
UA_Write


UA_Connect

SPS API [image] Funktionsbausteine [image] UA_Connect
UA_Connect
Dieser Funktionsbaustein stellt eine OPC-UA-Remote-Verbindung zu einem anderen OPC UA Server her, der via ServerUrl und SessionConnectInfo spezifiziert wird. Der Funktionsbaustein gibt ein Verbindungshandle zurück, der für andere Funktionsbausteine, z. B. UA_Read, verwendet werden kann.
VAR_INPUT
VAR_INPUT
Execute : BOOL;
ServerUrl : STRING(MAX_STRING_LENGTH);
SessionConnectInfo : ST_UASessionConnectInfo;
Timeout : TIME := DEFAULT_ADS_TIMEOUT;
END_VAR
Execute: Der Befehl wird durch eine steigende Flanke an diesem Eingang ausgelöst.
ServerUrl: OPC UA Server URL, d. h. 'opc.tcp://172.16.3.207:4840' oder 'opc.tcp://CX_0193BF:4840'.
SessionConnectInfo: Verbindungsinformation (siehe ST_UASessionConnectInfo)
Timeout: Zeit bis zum Abbruch der Funktion. DEFAULT_ADS_TIMEOUT ist eine globale Konstante, gesetzt auf 5 Sekunden. ST_UASessionConnectInfo.tSessionTimeout muss kürzer sein als dieses Timeout.
VAR_OUTPUT
VAR_OUTPUT
ConnectionHdl : DWORD;
Done : BOOL;
Busy : BOOL;
Error : BOOL;
ErrorID : DWORD;
END_VAR
ConnectionHdl: OPC‑UA‑Verbindungshandle.
Done: Schaltet auf TRUE, wenn der Funktionsbaustein erfolgreich ausgeführt wurde.
Busy: TRUE, bis der Baustein einen Befehl ausführt hat, maximal für die Dauer des „Timeout“ am Eingang. Solange Busy = TRUE ist, akzeptieren die Eingänge keinen neuen Befehl. Es wird nicht die Zeit der Verbindung sondern die Empfangszeit überwacht.
Error: Schaltet auf TRUE, wenn bei der Ausführung eines Befehls ein Fehler auftritt. Der befehlsspezifische Fehlercode ist in ErrorID enthalten.
ErrorID: Enthält den befehlsspezifischen Fehlercode des zuletzt ausgeführten Befehls.
Voraussetzungen
Entwicklungsumgebung | Zielplattform | Einzubindende SPS-Bibliotheken
TwinCAT 3.1 | Win32, Win64, CE-X86, CE-ARM | Tc3_PLCopen_OpcUa
TwinCAT 2.11 R3 Build 2245 | Win32, CE-X86, CE-ARM | Tc2_PLCopen_OpcUa


UA_Disconnect

SPS API [image] Funktionsbausteine [image] UA_Disconnect
UA_Disconnect
Dieser Funktionsbaustein schließt eine OPC-UA-Remote-Verbindung zu einem anderen OPC UA Server. Die Verbindung wird über ihr Verbindungshandle spezifiziert.
VAR_INPUT
VAR_INPUT
Execute : BOOL;
ConnectionHdl : DWORD;
Timeout : TIME := DEFAULT_ADS_TIMEOUT;
END_VAR
Execute: Der Befehl wird durch eine steigende Flanke an diesem Eingang ausgelöst.
ConnectionHdl: Verbindungshandle, das vorher vom Funktionsbaustein UA_Connect ausgegeben wurde.
Timeout: Zeit bis zum Abbruch der Funktion. DEFAULT_ADS_TIMEOUT ist eine globale Konstante, gesetzt auf 5 Sekunden.
VAR_OUTPUT
VAR_OUTPUT
Done : BOOL;
Busy : BOOL;
Error : BOOL;
ErrorID : DWORD;
END_VAR
Done: Schaltet auf TRUE, wenn der Funktionsbaustein erfolgreich ausgeführt wurde.
Busy: TRUE, bis der Baustein einen Befehl ausführt hat, maximal für die Dauer des „Timeout“ am Eingang. Solange Busy = TRUE ist, akzeptieren die Eingänge keinen neuen Befehl. Es wird nicht die Zeit der Verbindung sondern die Empfangszeit überwacht.
Error: Schaltet auf TRUE, wenn bei der Ausführung eines Befehls ein Fehler auftritt. Der befehlsspezifische Fehlercode ist in nErrID enthalten.
ErrorID: Enthält den befehlsspezifischen Fehlercode des zuletzt ausgeführten Befehls.
Voraussetzungen
Entwicklungsumgebung | Zielplattform | Einzubindende SPS-Bibliotheken
TwinCAT 3.1 | Win32, Win64, CE-X86, CE-ARM | Tc3_PLCopen_OpcUa
TwinCAT 2.11 R3 Build 2245 | Win32, CE-X86, CE-ARM | Tc2_PLCopen_OpcUa


UA_GetNamespaceIndex

SPS API [image] Funktionsbausteine [image] UA_GetNamespaceIndex
UA_GetNamespaceIndex
Dieser Funktionsbaustein erfasst den Namespace Index für einen Namespace URI. Der Namespace Index wird für die Identifizierung von Symbolen benötigt, z. B. wenn die Funktionsbausteine UA_Read oder UA_Write genutzt werden.
VAR_INPUT
VAR_INPUT
Execute : BOOL;
ConnectionHdl : DWORD;
NamespaceUri : STRING(MAX_STRING_LENGTH);
Timeout : TIME := DEFAULT_ADS_TIMEOUT;
END_VAR
Execute: Der Befehl wird durch eine steigende Flanke an diesem Eingang ausgelöst.
ConnectionHdl: Verbindungshandle, das vorher vom Funktionsbaustein UA_Connect ausgegeben wurde.
NamespaceUri: Namensraum-URI, der aufgelöst werden soll. Beim TwinCAT OPC UA Server ist das für die erste SPS-Laufzeit „PLC1“.
Timeout: Zeit bis zum Abbruch der Funktion. DEFAULT_ADS_TIMEOUT ist eine globale Konstante, gesetzt auf 5 Sekunden.
VAR_OUTPUT
VAR_OUTPUT
NamespaceIndex : UINT;
Done : BOOL;
Busy : BOOL;
Error : BOOL;
ErrorID : DWORD;
END_VAR
NamespaceIndex: Namespace Index des gegebenen Namensraum-URI. Dieser kann in anderen Funktionsbausteinen verwendet werden, z. B. UA_NodeGetHandle oder UA_MethodGetHandle.
Done: Schaltet auf TRUE, wenn der Funktionsbaustein erfolgreich ausgeführt wurde.
Busy: TRUE, bis der Baustein einen Befehl ausführt hat, maximal für die Dauer des „Timeout'“ am Eingang. Solange Busy = TRUE ist, akzeptieren die Eingänge keinen neuen Befehl. Es wird nicht die Zeit der Verbindung sondern die Empfangszeit überwacht.
Error: Schaltet auf TRUE, wenn bei der Ausführung eines Befehls ein Fehler auftritt. Der befehlsspezifische Fehlercode ist in ErrorID enthalten.
ErrorID: Enthält den befehlsspezifischen Fehlercode des zuletzt ausgeführten Befehls.
Voraussetzungen
Entwicklungsumgebung | Zielplattform | Einzubindende SPS-Bibliotheken
TwinCAT 3.1 | Win32, Win64, CE-X86, CE-ARM | Tc3_PLCopen_OpcUa
TwinCAT 2.11 R3 Build 2245 | Win32, CE-X86, CE-ARM | Tc2_PLCopen_OpcUa


UA_HistoryUpdate

SPS API [image] Funktionsbausteine [image] UA_HistoryUpdate
UA_HistoryUpdate
Dieser Funktionsbaustein schickt historische Daten über OPC UA zu einem Server, der die OPC-UA-HistoryUpdate-Funktionalität unterstützt, z. B. dem TwinCAT OPC UA Server. Mit einem Aufruf können Sie für ein Knotenhandle eine Vielzahl von Werten inklusive Zeitstempel an den Server übertragen. Dieser sorgt dafür, dass die übermittelten Werte in einem Datenspeicher gespeichert und über Historical Access verfügbar gemacht werden.
Wenn Werte von mehreren Knotenhandle (verschiedenen Variablen) übertragen werden sollen, kann der Funktionsbaustein mehrfach instanziiert werden.
Betrieb mit TwinCAT OPC UA Server
Der Funktionsbaustein eignet sich gut, wenn Sie im TwinCAT OPC UA Server Historical Access nutzen und Daten aus einem bestimmten Zeitintervall, in dem z. B. ein spezieller Maschinenzustand vorherrschte, zur Verfügung stellen wollen. Es lassen sich gezielt Werte für den gewünschten Zeitraum übertragen.
Wenn Werte hingegen zyklisch gesendet und über Historical Access im Server verfügbar gemacht werden sollen, so eignet sich die serverseitige Historical-Access-Funktionalität besser, da Sie hier lediglich die aufzuzeichnende Node im Konfigurator konfigurieren und die gewünschte Abtastrate einstellen müssen.
Siehe auch: Programmbeispiel TF6100_OPCUA_HASample
VAR_INPUT
VAR_INPUT
Execute : BOOL;
ConnectionHdl : DWORD;
NodeHdl : DWORD;
PerformInsert : BOOL;
PerformReplace : BOOL;
DataValueCount : UINT;
Timeout : TIME := DEFAULT_ADS_TIMEOUT;
END_VAR
Execute: Der Befehl wird durch eine steigende Flanke an diesem Eingang ausgelöst.
ConnectionHdl: Verbindungshandle, das vorher vom Funktionsbaustein UA_Connect ausgegeben wurde.
NodeHdl: Knotenhandle, der zuvor vom Funktionsbaustein UA_NodeGetHandle ausgegeben wurde.
PerformInsert: Der Default ist TRUE.
PerformReplace: Der Default ist FALSE. Sofern in der Historie bereits ein Wert für den gegebenen Zeitstempel existiert, soll dieser ersetzt werden, wenn die Option PerformReplace gesetzt ist (= TRUE). Diese Option kann aktuell nur für SQL Adapter ausgewählt werden. Andere Adapter unterstützen die Option nicht.
DataValueCount: Legt die Anzahl der übergebenen Werte fest. Eine Maximalanzahl von 1000 Werten wird unterstützt.
Timeout: Zeit bis zum Abbruch der Funktion. DEFAULT_ADS_TIMEOUT ist eine globale Konstante, gesetzt auf 5 Sekunden.
VAR_IN_OUT
VAR_IN_OUT
DataValues : ARRAY[*] OF UAHADataValue;
ValueErrorIDs : ARRAY[*] OF DWORD;
END_VAR
DataValues (read-only): Es werden alle gesammelten Werte in Form eines Feldes vom Typ UAHADataValue übergeben. Die Länge des Feldes ist nicht vorgeschrieben, muss jedoch mindestens der Angabe von DataValueCount entsprechen. Auf die Werte wird intern nur lesend zugegriffen.
ValueErrorIDs (write-only): Nach Ausführung des Befehls beinhaltet dieses Feld für jeden Wert einen Fehlercode. Die Länge des Feldes muss mindestens der Angabe von DataValueCount entsprechen. Wenn ein oder mehrere Werte einen Fehler melden, so wird dies auch über die Ausgänge Error und ErrorID des Funktionsbausteins signalisiert. Mithilfe dieses Feldes kann daraufhin ermittelt werden, für welchen Wert welcher Fehler aufgetreten ist. Der Fehlercode 16#80000000 beispielsweise signalisiert eine fehlgeschlagene Operation, sodass der Wert nicht geschrieben werden konnte.
VAR_OUTPUT
VAR_OUTPUT
Done : BOOL;
Busy : BOOL;
Error : BOOL;
ErrorID : DWORD;
END_VAR
Done: Schaltet auf TRUE, wenn der Funktionsbaustein erfolgreich ausgeführt wurde.
Busy: TRUE, bis der Baustein einen Befehl ausführt hat, maximal für die Dauer des „Timeout“ am Eingang. Solange Busy = TRUE ist, akzeptieren die Eingänge keinen neuen Befehl. Es wird nicht die Zeit der Verbindung sondern die Empfangszeit überwacht.
Error: Schaltet auf TRUE, wenn bei der Ausführung eines Befehls ein Fehler auftritt. Der befehlsspezifische Fehlercode ist in ErrorID enthalten.
ErrorID: Enthält den befehlsspezifischen ADS‑Fehlercode des zuletzt ausgeführten Befehls.
Anzahl der übergebenen Werte
Je größer die Anzahl ist, umso größer ist auch der benötigte Rechenaufwand und damit die SPS-Ausführungsdauer bei Befehlsausführung.
Voraussetzungen
Entwicklungsumgebung | Zielplattform | Einzubindende SPS Bibliotheken
TwinCAT 3.1.4022.27 | Win32, Win64, WinCE-x86 | Tc3_PLCopen_OpcUa >= v3.1.8.0


UA_MethodCall

SPS API [image] Funktionsbausteine [image] UA_MethodCall
UA_MethodCall
Dieser Funktionsbaustein ruft eine Methode auf einem Remote-UA-Server auf. Die Methode wird durch eine Verbindung und ein Methodenhandle bestimmt. Erstere kann durch UA_Connect und letzterer durch UA_MethodGetHandle abgefragt werden.
VAR_INPUT
VAR_INPUT
Execute : BOOL;
ConnectionHdl : DWORD;
MethodHdl : DWORD;
nNumberOfInputArguments : UDINT;
pInputArgInfo : POINTER TO ST_UAMethodArgInfo;
cbInputArgInfo : UDINT;
pInputArgData : PVOID;
cbInputArgData : UDINT;
pInputWriteData : PVOID;
cbInputWriteData : UDINT;
nNumberOfOutputArguments : UDINT;
pOutputArgInfo : POINTER TO ST_UAMethodArgInfo;
cbOutputArgInfo : UDINT;
pOutputArgInfoAndData : PVOID;
cbOutputArgInfoAndData : UDINT;
Timeout : TIME := DEFAULT_ADS_TIMEOUT;
END_VAR
Execute: Der Befehl wird durch eine steigende Flanke an diesem Eingang ausgelöst.
ConnectionHdl: Verbindungshandle, das vorher vom Funktionsbaustein UA_Connect ausgegeben wurde.
MethodHdl: Methodenhandle, zuvor vom Funktionsbaustein UA_MethodGetHandle ausgegeben.
nNumberOfInputArguments: Anzahl Eingabeparameter.
pInputArgInfo: Zeigt auf die Pufferadresse, wo Eingabeparameterinformationen in Form eines Arrays ST_UAMethodArgInfo hinterlegt sind.
cbInputArgInfo: Größe des Puffers, wo die Eingabeparameterinformation hinterlegt ist.
pInputArgData: Zeigt auf die Pufferadresse, wo Eingabeparameter (konstanter Länge) hinterlegt sind.
cbInputArgData: Größe des Eingabepuffers, wo Eingabeparameter (mit konstanter Länge) hinterlegt sind.
pInputWriteData: Zeiger auf Pufferadresse, wo Eingabeparameter (dynamischer Länge) hinterlegt sind.
cbInputWriteData: Größe des Eingabepuffers, wo Eingabeparameter (mit dynamischer Länge) hinterlegt sind.
nNumberOfOutputArguments: Anzahl Ausgabeparameter.
pOutputArgInfo: Zeigt auf die Pufferadresse, wo Ausgabeparameterinformationen als Array ST_UAMethodArgInfo hinterlegt sind.
Für die Bestimmung des Zielspeichers der einzelnen Ausgabeparameter ist nLenData erforderlich. Die anderen Elemente können so gesetzt werden, dass eine Typprüfung der zurückgegebenen Parameter erfolgt oder undefiniert bleiben.
cbOutputArgInfo: Größe des Puffers, wo die Ausgabeparameterinformation hinterlegt ist.
pOutputArgInfoAndData: Zeigt auf die Pufferadresse, wo die Ausgabeparameter als BYTE-Array gespeichert werden sollen. Das BYTE-Array enthält die Anzahl der Ausgabeparameter als DINT, 4 reservierte Bytes und Parameterinformationen als ARRAY OF ST_UAMethodArgInfo (mit der Länge der Ausgabeparameter) gefolgt von reinen Daten. Beachten Sie, dass die Daten als 1-byte-Alignment gepackt sind.
cbOutputArgInfoAndData: Größe des Puffers, in dem die Ausgabeparameter als BYTE-Array gespeichert werden sollen.
Timeout: Zeit bis zum Abbruch der Funktion. DEFAULT_ADS_TIMEOUT ist eine globale Konstante, gesetzt auf 5 Sekunden.
VAR_OUTPUT
VAR_OUTPUT
cbRead_R : UDINT;
Done : BOOL;
Busy : BOOL;
Error : BOOL;
ErrorID : UDINT;
END_VAR
cbRead_R: Zählt alle empfangenen Bytes.
Done: Schaltet auf TRUE, wenn der Funktionsbaustein erfolgreich ausgeführt wurde.
Busy: TRUE, bis der Baustein einen Befehl ausführt hat, maximal für die Dauer des „Timeout“ am Eingang. Solange Busy = TRUE ist, akzeptieren die Eingänge keinen neuen Befehl. Es wird nicht die Zeit der Verbindung sondern die Empfangszeit überwacht.
Error: Schaltet auf TRUE, wenn bei der Ausführung eines Befehls ein Fehler auftritt. Der befehlsspezifische Fehlercode ist in nErrID enthalten.
ErrorID: Enthält den befehlsspezifischen Fehlercode des zuletzt ausgeführten Befehls.
Voraussetzungen
Entwicklungsumgebung | Zielplattform | Einzubindende SPS-Bibliotheken
TwinCAT 3.1 | Win32, Win64, CE-X86, CE-ARM | Tc3_PLCopen_OpcUa


UA_MethodGetHandle

SPS API [image] Funktionsbausteine [image] UA_MethodGetHandle
UA_MethodGetHandle
Dieser Funktionsbaustein erfasst ein Handle für eine UA-Methode, das dann für den Aufruf einer Methode über UA_MethodCall verwendet werden kann.
VAR_INPUT
VAR_INPUT
Execute : BOOL;
ConnectionHdl : DWORD;
ObjectNodeID : ST_UANodeID;
MethodNodeID : ST_UANodeID;
Timeout : TIME := DEFAULT_ADS_TIMEOUT;
END_VAR
Execute: Der Befehl wird durch eine steigende Flanke an diesem Eingang ausgelöst.
ConnectionHdl: Verbindungshandle, das vorher vom Funktionsbaustein UA_Connect ausgegeben wurde.
ObjectNodeID: Objektknoten-ID der aufzurufenden Methode. (Typ: ST_UANodeID)
MethodNodeID: Methoden-Knoten-ID der aufzurufenden Methode. Entspricht dem ID-Atttribut im UA‑Namensraum. (Typ: UA_Connect)
Timeout: Zeit bis zum Abbruch der Funktion. DEFAULT_ADS_TIMEOUT ist eine globale Konstante, gesetzt auf 5 Sekunden.
VAR_OUTPUT
VAR_OUTPUT
MethodHdl : DWORD;
Done : BOOL;
Busy : BOOL;
Error : BOOL;
ErrorID : UDINT;
END_VAR
MethodHdl: Gibt ein Methodenhandle zurück, das für den Aufruf einer Methode über UA_MethodCall verwendet werden kann.
Done: Schaltet auf TRUE, wenn der Funktionsbaustein erfolgreich ausgeführt wurde.
Busy: TRUE, bis der Baustein einen Befehl ausführt hat, maximal für die Dauer des „Timeout“ am Eingang. Solange Busy = TRUE ist, akzeptieren die Eingänge keinen neuen Befehl. Es wird nicht die Zeit der Verbindung sondern die Empfangszeit überwacht.
Error: Schaltet auf TRUE, wenn bei der Ausführung eines Befehls ein Fehler auftritt. Der befehlsspezifische Fehlercode ist in nErrID enthalten.
ErrorID: Enthält den befehlsspezifischen Fehlercode des zuletzt ausgeführten Befehls.
Voraussetzungen
Entwicklungsumgebung | Zielplattform | Einzubindende SPS-Bibliotheken
TwinCAT 3.1 | Win32, Win64, CE-X86, CE-ARM | Tc3_PLCopen_OpcUa


UA_MethodReleaseHandle

SPS API [image] Funktionsbausteine [image] UA_MethodReleaseHandle
UA_MethodReleaseHandle
Dieser Funktionsbaustein gibt das spezifizierte Methodenhandle frei.
VAR_INPUT
VAR_INPUT
Execute : BOOL;
ConnectionHdl : DWORD;
MethodHdl : DWORD;
Timeout : TIME := DEFAULT_ADS_TIMEOUT;
END_VAR
Execute: Der Befehl wird durch eine steigende Flanke an diesem Eingang ausgelöst.
ConnectionHdl: Verbindungshandle, das vorher vom Funktionsbaustein UA_Connect ausgegeben wurde.
MethodHdl: Methodenhandle, das zuvor vom Funktionsbaustein UA_MethodGetHandle ausgegeben wurde.
Timeout: Zeit bis zum Abbruch der Funktion. DEFAULT_ADS_TIMEOUT ist eine globale Konstante, gesetzt auf 5 Sekunden.
VAR_OUTPUT
VAR_OUTPUT
Done : BOOL;
Busy : BOOL;
Error : BOOL;
ErrorID : UDINT;
END_VAR
Done: Schaltet auf TRUE, wenn der Funktionsbaustein erfolgreich ausgeführt wurde.
Busy: TRUE, bis der Baustein einen Befehl ausführt hat, maximal für die Dauer des „Timeout“ am Eingang. Solange Busy = TRUE ist, akzeptieren die Eingänge keinen neuen Befehl. Es wird nicht die Zeit der Verbindung sondern die Empfangszeit überwacht.
Error: Schaltet auf TRUE, wenn bei der Ausführung eines Befehls ein Fehler auftritt. Der befehlsspezifische Fehlercode ist in nErrID enthalten.
ErrorID: Enthält den befehlsspezifischen ADS Fehlercode des zuletzt ausgeführten Befehls.
Voraussetzungen
Entwicklungsumgebung | Zielplattform | Einzubindende SPS-Bibliotheken
TwinCAT 3.1 | Win32, Win64, CE-X86, CE-ARM | Tc3_PLCopen_OpcUa


UA_NodeGetHandle

SPS API [image] Funktionsbausteine [image] UA_NodeGetHandle
UA_NodeGetHandle
Dieser Funktionsbaustein fragt ein Knotenhandle für ein gegebenes Symbol im UA-Namensraum ab. Das Symbol wird durch ein Verbindungshandle und seine Knoten-ID spezifiziert.
VAR_INPUT
VAR_INPUT
Execute : BOOL;
ConnectionHdl : DWORD;
NodeID : ST_UANodeID;
Timeout : TIME := DEFAULT_ADS_TIMEOUT;
END_VAR
Execute: Der Befehl wird durch eine steigende Flanke an diesem Eingang ausgelöst.
ConnectionHdl: Verbindungshandle, das vorher vom Funktionsbaustein UA_Connect ausgegeben wurde.
Node ID: Eindeutige Adressierung der UA Node, bestehend aus Identifier, IdentifierType und NamespaceIndex, welcher aus einem NamespaceName aufgelöst wird, z.B. mittels der Methode UA_GetNamespaceIndex.
Timeout: Zeit bis zum Abbruch der Function. DEFAULT_ADS_TIMEOUT ist eine globale Konstante, gesetzt auf 5 Sekunden.
VAR_OUTPUT
VAR_OUTPUT
NodeHdl : DWORD;
Done : BOOL;
Busy : BOOL;
Error : BOOL;
ErrorID : DWORD;
END_VAR
NodeHdl: Knotenhandle, das für andere Funktionsbausteine verwendet werden kann, z. B. UA_Read oder UA_Write.
Done: Schaltet auf TRUE, wenn der Funktionsbaustein erfolgreich ausgeführt wurde.
Busy: TRUE, bis der Baustein einen Befehl ausführt hat, maximal für die Dauer des „Timeout“ am Eingang. Solange Busy = TRUE akzeptieren die Eingänge keinen neuen Befehl. Es wird nicht die Zeit der Verbindung sondern die Empfangszeit überwacht.
Error: Schaltet auf TRUE, wenn bei der Ausführung eines Befehls ein Fehler auftritt. Der befehlsspezifische Fehlercode ist in ErrorID enthalten.
ErrorID: Enthält den befehlsspezifischen ADS Fehlercode des zuletzt ausgeführten Befehls.
Voraussetzungen
Entwicklungsumgebung | Zielplattform | Einzubindende SPS-Bibliotheken
TwinCAT 3.1 | Win32, Win64, CE-X86, CE-ARM | Tc3_PLCopen_OpcUa
TwinCAT 2.11 R3 Build 2245 | Win32, CE-X86, CE-ARM | Tc2_PLCopen_OpcUa


UA_NodeGetHandleList

SPS API [image] Funktionsbausteine [image] UA_NodeGetHandleList
UA_NodeGetHandleList
Graphic from UA_NodeGetHandleList (il01v4n3.png)
Dieser Funktionsbaustein fragt Knotenhandles für Knoten im UA-Namensraum ab.
VAR_INPUT
VAR_INPUT
Execute : BOOL;
ConnectionHdl : DWORD;
NodeIDCount : UINT;
NodeIDs : ARRAY[1..nMaxNodeIDsInList] OF ST_UANodeID;
Timeout : TIME := DEFAULT_ADS_TIMEOUT;
END_VAR
Execute: Der Befehl wird durch eine steigende Flanke an diesem Eingang ausgelöst.
ConnectionHdl: Verbindungshandle, das vorher vom Funktionsbaustein UA_Connect ausgegeben wurde.
NodeIDCount: Anzahl Knoten, für die ein Knotenhandle erforderlich ist.
NodeIDs: Array von NodeIDs, die mit der struct ST_UANodeID erstellt wurden.
Timeout: Zeit bis zum Abbruch der Funktion. DEFAULT_ADS_TIMEOUT ist eine globale Konstante, gesetzt auf 5 Sekunden.
VAR_OUTPUT
VAR_OUTPUT
NodeHdls : ARRAY[1..nMaxNodeIDsInList] OF DWORD;
NodeErrorIDs : ARRAY[1..nMaxNodeIDsInList] OF DWORD;
cbData_R : UDINT;
Done : BOOL;
Busy : BOOL;
Error : BOOL;
ErrorID : DWORD;
END_VAR
NodeHdls: Array angeforderter Knotenhandles.
NodeErrorIDs: Array von Fehler-IDs, falls keine Knotenhandles zur Verfügung stehen.
cbData_R: Größe der gelesenen Daten.
Done: Schaltet auf TRUE, wenn der Funktionsbaustein erfolgreich ausgeführt wurde.
Busy: TRUE, bis der Baustein einen Befehl ausführt hat, maximal für die Dauer des „Timeout“ am Eingang. Solange Busy = TRUE ist, akzeptieren die Eingänge keinen neuen Befehl. Es wird nicht die Zeit der Verbindung sondern die Empfangszeit überwacht.
Error: Schaltet auf TRUE, wenn bei der Ausführung eines Befehls ein Fehler auftritt. Der befehlsspezifische Fehlercode steht in nErrID.
ErrorID: Enthält die Fehler-ID, wenn ein Fehler auftritt.
Voraussetzungen
Entwicklungsumgebung | Zielplattform | Einzubindende SPS-Bibliotheken
TwinCAT 3.1 | Win32, Win64, CE-X86, CE-ARM | Tc3_PLCopen_OpcUa
TwinCAT 2.11 R3 Build 2245 | Win32, CE-X86, CE-ARM | Tc2_PLCopen_OpcUa


UA_NodeReleaseHandle

SPS API [image] Funktionsbausteine [image] UA_NodeReleaseHandle
UA_NodeReleaseHandle
Dieser Funktionsbaustein gibt ein Knotenhandle frei.
VAR_INPUT
VAR_INPUT
Execute : BOOL;
ConnectionHdl : DWORD;
NodeHdl : DWORD;
Timeout : TIME := DEFAULT_ADS_TIMEOUT;
END_VAR
Execute: Der Befehl wird durch eine steigende Flanke an diesem Eingang ausgelöst.
ConnectionHdl: Verbindungshandle, das vorher vom Funktionsbaustein UA_Connect ausgegeben wurde.
NodeHdl: Freizugebendes Knotenhandle.
Timeout: Zeit bis zum Abbruch der Funktion. DEFAULT_ADS_TIMEOUT ist eine globale Konstante, gesetzt auf 5 Sekunden.
VAR_OUTPUT
VAR_OUTPUT
Done : BOOL;
Busy : BOOL;
Error : BOOL;
ErrorID : DWORD;
END_VAR
Done: Schaltet auf TRUE, wenn der Funktionsbaustein erfolgreich ausgeführt wurde.
Busy: TRUE, bis der Baustein einen Befehl ausführt hat, maximal für die Dauer des „Timeout“ am Eingang. Solange Busy = TRUE ist, akzeptieren die Eingänge keinen neuen Befehl. Es wird nicht die Zeit der Verbindung sondern die Empfangszeit überwacht.
Error: Schaltet auf TRUE, wenn bei der Ausführung eines Befehls ein Fehler auftritt. Der befehlsspezifische Fehlercode ist in ErrorID enthalten.
ErrorID: Enthält den befehlsspezifischen ADS Fehlercode des zuletzt ausgeführten Befehls.
Voraussetzungen
Entwicklungsumgebung | Zielplattform | Einzubindende SPS-Bibliotheken
TwinCAT 3.1 | Win32, Win64, CE-X86, CE-ARM | Tc3_PLCopen_OpcUa
TwinCAT 2.11 R3 Build 2245 | Win32, CE-X86, CE-ARM | Tc2_PLCopen_OpcUa


UA_NodeReleaseHandleList

SPS API [image] Funktionsbausteine [image] UA_NodeReleaseHandleList
UA_NodeReleaseHandleList
Graphic from UA_NodeReleaseHandleList (i76r9at2.png)
Dieser Funktionsbaustein gibt mehrere Knotenhandles frei.
VAR_INPUT
VAR_INPUT
Execute : BOOL;
ConnectionHdl : DWORD;
NodeHdlCount : UINT;
NodeHdls : ARRAY[1..nMaxNodeIDsInList] OF DWORD;
Timeout : TIME := DEFAULT_ADS_TIMEOUT;
END_VAR
Execute: Der Befehl wird durch eine steigende Flanke an diesem Eingang ausgelöst.
ConnectionHdl: Verbindungshandle, das vorher vom Funktionsbaustein UA_Connect ausgegeben wurde.
NodeHdlCount: Anzahl Knotenhandles.
NodeHdls: Array von Knotenhandles, die freizugeben sind.
Timeout: Zeit bis zum Abbruch der Funktion. DEFAULT_ADS_TIMEOUT ist eine globale Konstante, gesetzt auf 5 Sekunden.
VAR_OUTPUT
VAR_OUTPUT
NodeErrorIDs : ARRAY[1..nMaxNodeIDsInList] OF DWORD;
Done : BOOL;
Busy : BOOL;
Error : BOOL;
ErrorID : DWORD;
END_VAR
NodeErrorIDs: Array von Fehler-IDs, falls ein Knotenhandle nicht freigegeben werden konnte.
Done: Schaltet auf TRUE, wenn der Funktionsbaustein erfolgreich ausgeführt wurde.
Busy: TRUE, bis der Baustein einen Befehl ausführt hat, maximal für die Dauer des „Timeout“ am Eingang. Solange Busy = TRUE ist, akzeptieren die Eingänge keinen neuen Befehl. Es wird nicht die Zeit der Verbindung sondern die Empfangszeit überwacht.
Error: Schaltet auf TRUE, wenn bei der Ausführung eines Befehls ein Fehler auftritt. Der befehlsspezifische Fehlercode steht in nErrID.
ErrorID: Enthält die Fehler-ID, wenn ein Fehler auftritt.
Voraussetzungen
Entwicklungsumgebung | Zielplattform | Einzubindende SPS-Bibliotheken
TwinCAT 3.1 | Win32, Win64, CE-X86, CE-ARM | Tc3_PLCopen_OpcUa
TwinCAT 2.11 R3 Build 2245 | Win32, CE-X86, CE-ARM | Tc2_PLCopen_OpcUa


UA_Read

SPS API [image] Funktionsbausteine [image] UA_Read
UA_Read
Dieser Funktionsbaustein liest Werte aus einem gegebenen Knoten- und Verbindungshandle.
VAR_INPUT
VAR_INPUT
Execute : BOOL;
ConnectionHdl : DWORD;
NodeHdl : DWORD;
stNodeAddInfo : ST_UANodeAdditionalInfo;
pVariable : PVOID;
cbData : UDINT;
Timeout : TIME := DEFAULT_ADS_TIMEOUT;
END_VAR
Execute: Der Befehl wird durch eine steigende Flanke an diesem Eingang ausgelöst.
ConnectionHdl: Verbindungshandle, das vorher vom Funktionsbaustein UA_Connect ausgegeben wurde.
NodeHdl: Knotenhandle, das zuvor vom Funktionsbaustein UA_NodeGetHandle ausgegeben wurde.
stNodeAddInfo: Definiert zusätzliche Informationen, z. B. welches Attribut aus dem UA‑Namensraum gelesen (Standard: 'Value'-Attribut) oder welcher IndexRange verwendet werden soll. Wird durch STRUCT ST_UANodeAdditionalInfo spezifiziert.
pVariable: Zeiger auf Datenspeicher, wo die gelesenen Daten abgespeichert werden sollen.
cbData: Bestimmt die Größe der zu lesenden Daten.
Timeout: Zeit bis zum Abbruch der Funktion. DEFAULT_ADS_TIMEOUT ist eine globale Konstante, gesetzt auf 5 Sekunden.
VAR_OUTPUT
VAR_OUTPUT
Done : BOOL;
Busy : BOOL;
Error : BOOL;
ErrorID : UDINT;
cbData_R : UDINT;
END_VAR
Done: Schaltet auf TRUE, wenn der Funktionsbaustein erfolgreich ausgeführt wurde.
Busy: TRUE, bis der Baustein einen Befehl ausführt hat, maximal für die Dauer des „Timeout“ am Eingang. Solange Busy = TRUE ist, akzeptieren die Eingänge keinen neuen Befehl. Es wird nicht die Zeit der Verbindung sondern die Empfangszeit überwacht.
Error: Schaltet auf TRUE, wenn bei der Ausführung eines Befehls ein Fehler auftritt. Der befehlsspezifische Fehlercode ist in nErrID enthalten.
ErrorID: Enthält den befehlsspezifischen ADS‑Fehlercode des zuletzt ausgeführten Befehls.
cbData_R: Anzahl zu lesender Bytes.
Voraussetzungen
Entwicklungsumgebung | Zielplattform | Einzubindende SPS-Bibliotheken
TwinCAT 3.1 | Win32, Win64, CE-X86, CE-ARM | Tc3_PLCopen_OpcUa
TwinCAT 2.11 R3 Build 2245 | Win32, CE-X86, CE-ARM | Tc2_PLCopen_OpcUa


UA_ReadList

SPS API [image] Funktionsbausteine [image] UA_ReadList
UA_ReadList
Grafik aus UA_ReadList (i9hmrgm2.png)
Dieser Funktionsbaustein liest Werte aus mehreren gegebenen Knoten- und Verbindungshandles.
VAR_INPUT
VAR_INPUT
Execute : BOOL;
ConnectionHdl : DWORD;
NodeHdlCount : UINT;
NodeHdls : ARRAY[1..nMaxNodeIDsInList] OF DWORD;
stNodeAddInfo : ARRAY[1..nMaxNodeIDsInList] OF ST_UANodeAdditionalInfo;
pVariable : PVOID;
cbData : ARRAY[1..nMaxNodeIDsInList] UDINT;
cbDataTotal : UDINT;
Timeout : TIME := DEFAULT_ADS_TIMEOUT;
END_VAR
Execute: Der Befehl wird durch eine steigende Flanke an diesem Eingang ausgelöst.
ConnectionHdl: Verbindungshandle, das vorher vom Funktionsbaustein UA_Connect ausgegeben wurde.
NodeHdlCount: Anzahl Knotenhandles, die in der Eingangsvariablen NodeHdls gespeichert sind.
NodeHdls: Array von Knotenhandles, die vorher vom Funktionsbaustein UA_NodeGetHandle oder UA_NodeGetHandleList erhalten wurden.
stNodeAddInfo: Definiert zusätzliche Informationen, z. B. welches Attribut aus dem UA‑Namensraum gelesen (Standard: 'Value'-Attribut) oder welcher IndexRange verwendet werden soll. Wird durch STRUCT ST_UANodeAdditionalInfo spezifiziert.
pVariable: Zeiger auf Datenspeicher, wo die gelesenen Daten abgespeichert werden sollen.
cbData: Bestimmt die Größe der zu lesenden Daten.
cbDataTotal: Gesamtgröße der zu empfangenden Daten.
Timeout: Zeit bis zum Abbruch der Funktion. DEFAULT_ADS_TIMEOUT ist eine globale Konstante, gesetzt auf 5 Sekunden.
VAR_OUTPUT
VAR_OUTPUT
Done : BOOL;
Busy : BOOL;
Error : BOOL;
ErrorID : UDINT;
cbData_R : UDINT;
END_VAR
Done: Schaltet auf TRUE, wenn der Funktionsbaustein erfolgreich ausgeführt wurde.
Busy: TRUE, bis der Baustein einen Befehl ausführt hat, maximal für die Dauer des „Timeout“ am Eingang. Solange Busy = TRUE ist, akzeptieren die Eingänge keinen neuen Befehl. Es wird nicht die Zeit der Verbindung sondern die Empfangszeit überwacht.
Error: Schaltet auf TRUE, wenn bei der Ausführung eines Befehls ein Fehler auftritt. Der befehlsspezifische Fehlercode steht in nErrID.
ErrorID: Enthält den befehlsspezifischen ADS‑Fehlercode des zuletzt ausgeführten Befehls.
cbData_R: Anzahl der gelesenen Bytes
Voraussetzungen
Entwicklungsumgebung | Zielplattform | Einzubindende SPS-Bibliotheken
TwinCAT 3.1 | Win32, Win64, CE-X86, CE-ARM | Tc3_PLCopen_OpcUa
TwinCAT 2.11 R3 Build 2245 | Win32, CE-X86, CE-ARM | Tc2_PLCopen_OpcUa


UA_Write

SPS API [image] Funktionsbausteine [image] UA_Write
UA_Write
Dieser Funktionsbaustein schreibt Werte in ein gegebenes Knoten- und Verbindungshandle.
VAR_INPUT
VAR_INPUT
Execute : BOOL;
ConnectionHdl : DWORD;
NodeHdl : DWORD;
stNodeAddInfo : ST_UANodeAdditionalInfo;
pVariable : PVOID;
cbData : UDINT;
Timeout : TIME := DEFAULT_ADS_TIMEOUT;
END_VAR
Execute: Der Befehl wird durch eine steigende Flanke an diesem Eingang ausgelöst.
ConnectionHdl: Verbindungshandle, das vorher vom Funktionsbaustein UA_Connect ausgegeben wurde.
NodeHdl: Knotenhandle, der zuvor vom Funktionsbaustein UA_NodeGetHandle ausgegeben wurde.
stNodeAddInfo: Definiert zusätzliche Informationen, z. B. auf welchen IndexRange oder welches Attribut geschrieben werden soll (standardmäßig wird das 'Value'-Attribut verwendet). Wird durch STRUCT ST_UANodeAdditionalInfo spezifiziert.
pVariable: Zeiger auf zu schreibende Daten.
cbData: Legt die Größe der zu schreibenden Werte fest.
Timeout: Zeit bis zum Abbruch der Funktion. DEFAULT_ADS_TIMEOUT ist eine globale Konstante, gesetzt auf 5 Sekunden.
VAR_OUTPUT
VAR_OUTPUT
Done : BOOL;
Busy : BOOL;
Error : BOOL;
ErrorID : DWORD;
END_VAR
Done: Schaltet auf TRUE, wenn der Funktionsbaustein erfolgreich ausgeführt wurde.
Busy: TRUE, bis der Baustein einen Befehl ausführt hat, maximal für die Dauer des „Timeout“ am Eingang. Solange Busy = TRUE ist, akzeptieren die Eingänge keinen neuen Befehl. Es wird nicht die Zeit der Verbindung sondern die Empfangszeit überwacht.
Error: Schaltet auf TRUE, wenn bei der Ausführung eines Befehls ein Fehler auftritt. Der befehlsspezifische Fehlercode ist in ErrorID enthalten.
ErrorID: Enthält den befehlsspezifischen ADS‑Fehlercode des zuletzt ausgeführten Befehls.
Voraussetzungen
Entwicklungsumgebung | Zielplattform | Einzubindende SPS-Bibliotheken
TwinCAT 3.1 | Win32, Win64, CE-X86, CE-ARM | Tc3_PLCopen_OpcUa
TwinCAT 2.11 R3 Build 2245 | Win32, CE-X86, CE-ARM | Tc2_PLCopen_OpcUa


Datentypen

SPS API [image] Datentypen
Datentypen
Weiterführende Informationen
•
E_UAAttributeID
•
E_UADataType
•
E_UAIdentifierType
•
E_UASecurityMsgMode
•
E_UASecurityPolicy
•
E_UATransportProfile
•
ST_UASessionConnectInfo
•
ST_UAIndexRange
•
ST_UAMethodArgInfo
•
ST_UANodeID
•
ST_UANodeAdditionalInfo
•
UAHADataValue
•
UAHAUpdateStatusCode


E_UAAttributeID

SPS API [image] Datentypen [image] E_UAAttributeID
E_UAAttributeID
TYPE E_UAAttributeID:
(
eUAAI_NodeID := 1,
eUAAI_NodeClass := 2,
eUAAI_BrowseName := 3,
eUAAI_DisplayName := 4,
eUAAI_Description := 5,
eUAAI_WriteMask := 6,
eUAAI_UserWriteMask := 7,
eUAAI_IsAbstract := 8,
eUAAI_Symmetric := 9,
eUAAI_InverseName := 10,
eUAAI_ContainsNoLoops := 11,
eUAAI_EventNotifier := 12,
eUAAI_Value := 13,
eUAAI_DataType := 14,
eUAAI_ValueRank := 15,
eUAAI_ArrayDimensions := 16
)DINT;
END_TYPE
Voraussetzungen
Entwicklungsumgebung | Zielplattform | Einzubindende SPS-Bibliotheken
TwinCAT 3.1 | Win32, Win64, CE-X86, CE-ARM | Tc3_PLCopen_OpcUa
TwinCAT 2.11 R3 Build 2245 | Win32, CE-X86, CE-ARM | Tc2_PLCopen_OpcUa


E_UADataType

SPS API [image] Datentypen [image] E_UADataType
E_UADataType
TYPE E_UADataType:
(
eUAType_Undefinied := -1,
eUAType_Null := 0,
eUAType_Boolean := 1,
eUAType_SByte := 2,
eUAType_Byte := 3,
eUAType_Int16 := 4,
eUAType_UInt16 := 5,
eUAType_Int32 := 6,
eUAType_UInt32 := 7,
eUAType_Int64 := 8,
eUAType_UInt64 := 9,
eUAType_Float := 10,
eUAType_Double := 11,
eUAType_String := 12,
eUAType_DateTime := 13,
eUAType_Guid := 14,
eUAType_ByteString := 15,
eUAType_XmlElement := 16,
eUAType_NodeId := 17,
eUAType_ExpandedNodeId := 18,
eUAType_StatusCode := 19,
eUAType_QualifiedName := 20,
eUAType_LocalizedText := 21,
eUAType_ExtensionObject := 22,
eUAType_DataValue := 23,
eUAType_Variant := 24,
eUAType_DiagnosticInfo := 25
)DINT;
END_TYPE
Voraussetzungen
Entwicklungsumgebung | Zielplattform | Einzubindende SPS-Bibliotheken
TwinCAT 3.1 | Win32, Win64, CE-X86, CE-ARM | Tc3_PLCopen_OpcUa
TwinCAT 2.11 R3 Build 2245 | Win32, CE-X86, CE-ARM | Tc2_PLCopen_OpcUa


E_UAIdentifierType

SPS API [image] Datentypen [image] E_UAIdentifierType
E_UAIdentifierType
TYPE E_UAIdentifierType:
(
eUAIdentifierType_String := 1,
eUAIdentifierType_Numeric := 2,
eUAIdentifierType_GUID := 3,
eUAIdentifierType_Opaque := 4
)DINT;
END_TYPE
Voraussetzungen
Entwicklungsumgebung | Zielplattform | Einzubindende SPS-Bibliotheken
TwinCAT 3.1 | Win32, Win64, CE-X86, CE-ARM | Tc3_PLCopen_OpcUa
TwinCAT 2.11 R3 Build 2245 | Win32, CE-X86, CE-ARM | Tc2_PLCopen_OpcUa


E_UASecurityMsgMode

SPS API [image] Datentypen [image] E_UASecurityMsgMode
E_UASecurityMsgMode
TYPE E_UASecurityMsgMode:
(
eUASecurityMsgMode_BestAvailable := 0,
eUASecurityMsgMode_None := 1,
eUASecurityMsgMode_Sign := 2,
eUASecurityMsgMode_Sign_Encrypt := 3
)DINT;
END_TYPE
Voraussetzungen
Entwicklungsumgebung | Zielplattform | Einzubindende SPS-Bibliotheken
TwinCAT 3.1 | Win32, Win64, CE-X86, CE-ARM | Tc3_PLCopen_OpcUa
TwinCAT 2.11 R3 Build 2245 | Win32, CE-X86, CE-ARM | Tc2_PLCopen_OpcUa


E_UASecurityPolicy

SPS API [image] Datentypen [image] E_UASecurityPolicy
E_UASecurityPolicy
TYPE E_UASecurityPolicy:
(
eUASecurityPolicy_BestAvailable := 0
eUASecurityPolicy_None := 1,
eUASecurityPolicy_Basic128 := 2,
eUASecurityPolicy_Basic128Rsa15 := 3,
eUASecurityPolicy_Basic256 := 4
)DINT;
END_TYPE
None: Richtlinie für Konfigurationen mit geringsten Sicherheitsanforderungen.
Basic128: Richtlinie für Konfigurationen mit geringen bis mittleren Sicherheitsanforderungen.
Basic128Rsa15: Definiert eine Sicherheitsrichtlinie für Konfigurationen mit mittleren bis hohen Sicherheitsanforderungen.
Basic256: Definiert eine Sicherheitsrichtlinie für Konfigurationen mit hohen Sicherheitsanforderungen.
Voraussetzungen
Entwicklungsumgebung | Zielplattform | Einzubindende SPS-Bibliotheken
TwinCAT 3.1 | Win32, Win64, CE-X86, CE-ARM | Tc3_PLCopen_OpcUa
TwinCAT 2.11 R3 Build 2245 | Win32, CE-X86, CE-ARM | Tc2_PLCopen_OpcUa


E_UATransportProfile

SPS API [image] Datentypen [image] E_UATransportProfile
E_UATransportProfile
TYPE E_UATransportProfile:
(
eUATransportProfileUri_UATcp := 1,
eUATransportProfileUri_WSHttpBinary := 2,
eUATransportProfileUri_WSHttpXmlOrBinary := 3,
eUATransportProfileUri_WSHttpXml := 4
)DINT;
END_TYPE
Voraussetzungen
Entwicklungsumgebung | Zielplattform | Einzubindende SPS-Bibliotheken
TwinCAT 3.1 | Win32, Win64, CE-X86, CE-ARM | Tc3_PLCopen_OpcUa
TwinCAT 2.11 R3 Build 2245 | Win32, CE-X86, CE-ARM | Tc2_PLCopen_OpcUa


ST_UASessionConnectInfo

SPS API [image] Datentypen [image] ST_UASessionConnectInfo
ST_UASessionConnectInfo
TYPE ST_UASessionConnectInfo:
STRUCT
sApplicationUri : STRING(MAX_STRING_LENGTH);
sApplicationName : STRING(MAX_STRING_LENGTH);

eSecurityMode : E_UASecurityMsgMode;
eSecurityPolicyUri : E_UASecurityPolicy;
eTransportProfileUri : E_UATransportProfile;

tSessionTimeout : TIME;
tConnectTimeout : TIME;
END_STRUCT
END_TYPE
sApplicationUri: Anwendungs-Uri maximale Zeichenkettenlänge 255.
Ab TcUAClient 2.0.0.14 wird diese automatisch vom Zertifikat vorgegeben, wie in der PLCOpen Spezifikation definiert.
sApplicationName: Anwendungsname mit maximaler Zeichenkettenlänge von 255.
eSecurityMode: Sicherheitsmeldungsmodus. Verfügbare Modi siehe E_UASecurityMsgMode.
eSecurityPolicyUri: Sicherheitsrichtlinien-Uri. Verfügbare Sicherheitsrichtlinien-Uri siehe E_UASecurityPolicy.
eTransportProfileUri: Transportprofil-Uri. Verfügbare Transportprofil-Uri siehe E_UATransportProfile;
nSessionTimeout: Wert Sitzungstimeout.
nConnectTimeout: Wert Verbindungstimeout.
Voraussetzungen
Entwicklungsumgebung | Zielplattform | Einzubindende SPS-Bibliotheken
TwinCAT 3.1 | Win32, Win64, CE-X86, CE-ARM | Tc3_PLCopen_OpcUa
TwinCAT 2.11 R3 Build 2245 | Win32, CE-X86, CE-ARM | Tc2_PLCopen_OpcUa


ST_UAIndexRange

SPS API [image] Datentypen [image] ST_UAIndexRange
ST_UAIndexRange
TYPE ST_UAIndexRange:
STRUCT
nStartIndex : UDINT;
nEndIndex : UDINT;
END_STRUCT
END_TYPE
nStartIndex: Startindex der Daten.
nEndIndex: Endindex der Daten.
Für alle Dimensionen:
▪
StartinIndex und EndIndex müssen zugewiesen werden.
▪
StartIndex muss kleiner als EndIndex sein.
▪
Um auf alle Elemente in einer Dimension zugreifen zu können, müssen StartIndex und EndIndex abhängig von der Gesamtzahl Elemente in der Dimension zugewiesen werden.
▪
Einzelne Elemente einer Dimension können ausgewählt werden, indem der gleiche StartIndex und EndIndex angegeben wird.
Voraussetzungen
Entwicklungsumgebung | Zielplattform | Einzubindende SPS-Bibliotheken
TwinCAT 3.1 | Win32, Win64, CE-X86, CE-ARM | Tc3_PLCopen_OpcUa
TwinCAT 2.11 R3 Build 2245 | Win32, CE-X86, CE-ARM | Tc2_PLCopen_OpcUa


ST_UAMethodArgInfo

SPS API [image] Datentypen [image] ST_UAMethodArgInfo
ST_UAMethodArgInfo
TYPE ST_UAMethodArgInfo:
STRUCT
DataType : E_UADataType := -1;
ValueRank : DINT := 2147483647;
ArrayDimensions : ARRAY[1..3] OF UDINT := [0,0,0];
nLenData : DINT;
END_STRUCT
END_TYPE
DataType: Legt den UA‑Datentyp für den Methodenparameter fest. (Typ: E_UADataType)
ValueRank: Legt fest, ob der Parameter Skalar (-1) oder Array ist.
ArrayDimensions: Wenn der Parameter ein Array ist, spezifiziert dieser die Dimensionen des Arrays. Jedes Element bestimmt die Länge pro Dimension.
nLenData: Spezifiziert die Länge des Arguments. Bei Ausgabeinformationen wird von STRUCT nur dieses Element gefordert.
Voraussetzungen
Entwicklungsumgebung | Zielplattform | Einzubindende SPS-Bibliotheken
TwinCAT 3.1 | Win32, Win64, CE-X86, CE-ARM | Tc3_PLCopen_OpcUa
TwinCAT 2.11 R3 Build 2245 | Win32, CE-X86, CE-ARM | Tc2_PLCopen_OpcUa


ST_UANodeID

SPS API [image] Datentypen [image] ST_UANodeID
ST_UANodeID
TYPE ST_UANodeID:
STRUCT
nNamespaceIndex : UINT;
nReserved : ARRAY [1..2] OF BYTE; //fill bytes
sIdentifier : STRING(MAX_STRING_LENGTH);
eIdentifierType : E_UAIdentifierType;
END_STRUCT
END_TYPE
nNamespaceIndex: Namensraum-Index unter dem der Knoten verfügbar ist. Kann mit dem Funktionsbaustein UA_GetNamespaceIndex bestimmt werden.
sIdentifier: Bezeichner wie im UA‑Namensraum gezeigt (Attribut 'Identifier').
eIdentifierType: Typ der Variablen, beschrieben mittels E_UAIdentifierType.
Voraussetzungen
Entwicklungsumgebung | Zielplattform | Einzubindende SPS-Bibliotheken
TwinCAT 3.1 | Win32, Win64, CE-X86, CE-ARM | Tc3_PLCopen_OpcUa
TwinCAT 2.11 R3 Build 2245 | Win32, CE-X86, CE-ARM | Tc2_PLCopen_OpcUa


ST_UANodeAdditionalInfo

SPS API [image] Datentypen [image] ST_UANodeAdditionalInfo
ST_UANodeAdditionalInfo
TYPE ST_UANodeAdditionalInfo:
STRUCT
eAttributeID : E_UAAttributeID;
nIndexRangeCount : UINT;
nReserved : ARRAY[1..2] OF BYTE; // fill bytes
stIndexRange : ARRAY[1..nMaxIndexRange] OF ST_UAIndexRange;
END_STRUCT
END_TYPE
eAttributeID: Spezifiziert die ID des OPC‑UA‑Attributs. Standardmäßig wird eUAAI_Value verwendet. (Typ: E_UAAttributeID)
nIndexRangeCount: Legt fest, wie viele Indexbereiche in stIndexRange verwendet werden.
stIndexRange: Spezifiziert einen Indexbereich für das Lesen von Werten aus einem Array. (Typ: ST_UAIndexRange)
Voraussetzungen
Entwicklungsumgebung | Zielplattform | Einzubindende SPS-Bibliotheken
TwinCAT 3.1 | Win32, Win64, CE-X86, CE-ARM | Tc3_PLCopen_OpcUa
TwinCAT 2.11 R3 Build 2245 | Win32, CE-X86, CE-ARM | Tc2_PLCopen_OpcUa


UAHADataValue

SPS API [image] Datentypen [image] UAHADataValue
UAHADataValue
Dieser Funktionsbaustein agiert als Datenobjekt. Eine Instanz repräsentiert einen Wert für die OPC-UA-Historical-Access-Funktionalität. Dem Funktionsbaustein UA_HistoryUpdate wird ein ganzes Feld dieser Werte beim Aufruf übergeben.
Deklaration
aDataValues : ARRAY [1..50] OF UAHADataValue(ValueSize:=SIZEOF(LREAL));
Jedes Datenobjekt wird mit der zu erwartenden Größe (in Bytes) des Wertes initialisiert.
Eigenschaften
Value (PVOID): Gibt die Adresse einer Variablen an, welche den gewünschten Wert beinhaltet. Typischerweise wird diese mithilfe des Operators ADR() zugewiesen. Hiermit wird zugleich intern der Wert selbst zugewiesen und in das Datenobjekt kopiert.
StatusCode (UAHAUpdateStatusCode): Gibt den Statuscode des Wertes an.
SourceTimeStamp (ULINT): Gibt den Zeitstempel der Quelle im UTC-Format an. Dieser kann mit der Funktion F_GetSystemTime (Tc2_System SPS Bibliothek) ermittelt werden.
ServerTimeStamp (ULINT): Gibt den Zeitstempel des OPC UA Servers im UTC-Format an. Diese Funktionalität wird aktuell nicht unterstützt.
Datentypgröße des Wertes
Die Größe des verwendeten Datentypen wird bereits bei der Deklaration des Datenobjektes angegeben und damit festgelegt. Bei späterer Zuweisung eines Wertes wird diese Größe zugrunde gelegt.
Werte vom Typ STRING werden demnach ebenso mit fest initialisierter Größe abgespeichert und übertragen. Es kann keine Angabe über die aktuelle Textlänge gemacht werden.
Beispiel
{attribute 'OPC.UA.DA' := '1'}
fMyValue : LREAL; // Variable for HistorcalAccess
aDataValues : ARRAY [1..50] OF UAHADataValue(ValueSize:=SIZEOF(LREAL));
fMyValue := 27.75;
aDataValues[1].Value := ADR(fMyValue);
aDataValues[1].StatusCode := UAHAUpdateStatusCode.HistorianRaw;
aDataValues[1].SourceTimeStamp := F_GetSystemTime();
In diesem Beispiel wird ein Feld von 50 Werten definiert, welche jeweils durch ein Datenobjekt repräsentiert werden. Dem ersten Wert wird der aktuelle Inhalt der Variablen fMyValue (= 27.75) zugewiesen.
Das Feld kann nun mittels weiterer Zuweisungen in späteren SPS-Zyklen gefüllt werden.
Voraussetzungen
Entwicklungsumgebung | Zielplattform | Einzubindende SPS Bibliotheken
TwinCAT 3.1.4022.27 | Win32, Win64, WinCE-x86 | Tc3_PLCopen_OpcUa >= v3.1.8.0


UAHAUpdateStatusCode

SPS API [image] Datentypen [image] UAHAUpdateStatusCode
UAHAUpdateStatusCode
Jedem mit der OPC-UA-Historical-Access-Funktionalität übertragenen Datenwert wird ein Statuscode zugeordnet. Dies ist eine Eigenschaft des Objektes UAHADataValue.
Enumeration
{attribute 'qualified_only'}
TYPE UAHAUpdateStatusCode :
(
HistorianRaw := 0, // A raw data value.
HistorianCalculated := 1, // A data value which was calculated.
HistorianInterpolated := 2, // A data value which was interpolated.
Reserved := 3, // Undefined.
HistorianPartial := 4, // A data value which was calculated with an incomplete interval.
HistorianExtraData := 8, // A raw data value that hides other data at the same timestamp.
HistorianMultiValue := 16 // Multiple values match the Aggregate criteria (i.e. multiple minimum values at different timestamps within the same interval).
) UDINT;
END_TYPE
Voraussetzungen
Entwicklungsumgebung | Zielplattform | Einzubindende SPS Bibliotheken
TwinCAT 3.1.4022.27 | Win32, Win64, WinCE-x86 | Tc3_PLCopen_OpcUa >= v3.1.8.0


Beispiele

Beispiele
Beispiele
Übersicht
Beispiel
Kategorie
TwinCAT-Version
Beschreibung
Download
TF6100 Server und Client Sample
Server
Client
TC3 (>=3.1.4020.0)
Das Beispiel beinhaltet eine SPS zur Bereitstellung von Variablen für den TwinCAT OPC UA Server (Data Access). Des Weiteren sind Beispiele für die Verwendung der Funktionsbausteine UA_Read, UA_Write, UA_ReadList und UA_MethodCall (Tc3_PLCopen_OpcUa) enthalten.
TF6100 Client Funktonsbaustein UA_HistoryUpdate
Client
TC3
Das Beispiel beinhaltet eine SPS zur Verwendung des Funktionsbausteins UA_HistoryUpdate (Tc3_PLCopen_OpcUa)
TS6100 Client Funktionsbausteine
Client
TC2
Beispiele für die Verwendung der Funktionsbausteine UA_Read und UA_Write
TS6100 Server Historical Access
Server
TC2
Historical Access: SPS-Beispielprogramm


Anhang

Anhang
Anhang
Weiterführende Informationen
•
Fehlerdiagnose
•
OPC-UA-Client-Fehlercodes
•
ADS Return Codes
•
Support und Service


Fehlerdiagnose

Anhang [image] Fehlerdiagnose
Fehlerdiagnose
Die folgende Tabelle bietet einige hilfreiche Informationen zur Fehlerdiagnose.
TwinCAT OPC UA Server
Verhalten | Hinweise
Ein OPC UA Client sieht den PLC Namespace nicht | TF6100 Setup Version 3.x und kleiner: Dieser Status ist ein Hinweis auf eine fehlende Lizenz. Überprüfen Sie, ob Sie eine gültige TF6100 Lizenz aktiviert haben.
Ein OPC UA Client bekommt bei Auslesen von Nodes den StatusCode 0x810e0000 | TF6100 Setup Version 4.x: Dieser Status ist ein Hinweis auf eine fehlende Lizenz. Überprüfen Sie, ob Sie eine gültige TF6100 Lizenz aktiviert haben.
Die über Kommentare/Attribute freigegebenen Variablen werden nicht im OPC UA Server angezeigt | Überprüfen Sie, ob die Symboldatei ordnungsgemäß auf die Steuerung übertragen wurde (z. B. Auswahlkästchen im SPS-Projekt), im Bootverzeichnis vorhanden ist und der Pfad zur Symboldatei in der Konfigurationsdatei des Servers auf die richtige Symboldatei verweist. Sie können auch über die DeviceState Node im jeweiligen Namespace eventuell aufgetretene ErrorMessages überprüfen. Hier wird z. B. auch eingetragen, wenn die Symboldatei nicht gefunden wurde. Überprüfen Sie auch die ordnungsgemäße Schreibweise der Kommentare/Attribute.
Die vom OPC UA Client geforderte Samplingrate/PublishingInterval werden vom Server nicht eingehalten | OPC UA Client/Server ist kein Echtzeitprotokoll, d. h. dass es keine Garantie gibt, dass der Server eine vom Client geforderte Samplingrate oder PublishingInterval auch immer zu 100% einhält. Die zur Verfügung stehenden Samplingraten und PublishingIntervalle können in der Konfigurationsdatei des Servers eingesehen und bei Bedarf modifiziert werden (<AvailableSamplingRates> und <MinPublishingInterval>).
Ein OPC UA Client kann sich nicht mit dem Server verbinden, obwohl der Server im Windows Task Manager angezeigt wird. Es erscheint die Fehlermeldung „Host unreachable“ (o.ä.) | Überprüfen Sie, ob gegebenenfalls Firewall-Einstellungen eine Kommunikation mit dem Server verhindern. Der Serverport muss für eine eingehende TCP-Kommunikation geöffnet sein, damit sich ein Client verbinden kann.
Ein OPC UA Client sieht zwar die Endpunkte des Servers, eine Verbindung mit diesen schlägt jedoch mit der Fehlermeldung „Host unreachable“ fehl | Überprüfen Sie, ob die Namensauflösung in Ihrem Netzwerk ordnungsgemäß funktioniert und der Server unter seinem Hostnamen erreichbar ist. Auch wenn sich der OPC UA Client augenscheinlich mit der IP-Adresse des Servers verbindet (z. B. opc.tcp://192.168.0.1:4840), um auf die Endpunkte des Servers zuzugreifen, so returniert der Server in seinen Endpunkten dennoch immer den eigenen Hostnamen. Wenn sich nun der Client direkt mit einem der Endpunkte verbindet, so verwendet er wieder den Hostnamen des Servers. Im Falle einer nicht funktionierenden Namensauflösung schlägt dann die Verbindung fehl.
Ein OPC UA Client sieht zwar die Endpunkte des Servers, eine Verbindung mit einem sicheren Endpunkt schlägt jedoch fehl. Es erscheint die Fehlermeldung „BadSecurityChecksFailed“ | Überprüfen Sie, ob der Server dem Client-Zertifikat vertraut. Die notwendigen Konfigurationsschritte können Sie im Abschnitt Zertifikatsaustausch nachlesen.
Bei Verwendung eines SQL Servers zur Speicherung von Historical Access Informationen, werden die Werte nicht zur SQL-Datenbank hinzugefügt | Überprüfen Sie die Zugangsdaten zum SQL Server und dass der SQL Server auch im Netzwerk erreichbar ist. Stellen Sie auch sicher, dass Sie ein „Big Windows“-Betriebssystem auf dem TwinCAT OPC UA Server verwenden, da SQL Server nicht unter Windows CE für Historical Access verwendet werden können (SQL Compact hingegen schon).
Beim Auslesen von Variablen erhält ein OPC UA Client die Fehlermeldung „BadDeviceFailure“ | Dies ist ein Hinweis darauf, dass das zugehörige ADS-Gerät nicht erreichbar ist, z. B. wenn kein SPS-Programm gestartet ist. Überprüfen Sie die Konnektivität mit dem ADS-Gerät und stellen Sie sicher, dass die entsprechende Laufzeit aktiv ist.
Arrays werden nicht voll aufgelöst im Namespace dargestellt | Standardmäßig werden Arrays von einfachen Datentypen nicht „aufgeklappt“ im Namensraum dargestellt. Einzelne Array-Indizes sind dennoch über die sogenannte IndexRange Funktion von OPC UA adressierbar. Ein OPC UA Client sollte diese Funktion entsprechend unterstützen. Ist dies nicht der Fall, so kann über einen Optionsschalter in der Konfigurationsdatei des Servers bewirkt werden, dass ein Array „aufgeklappt“ dargestellt und somit jedes einzelne Arrayelement als separate Node adressierbar ist. Dieser Optionsschalter ist im Abschnitt Verwendung von Arrays beschrieben.


OPC-UA-Client-Fehlercodes

Anhang [image] OPC-UA-Client-Fehlercodes
OPC-UA-Client-Fehlercodes
Die Funktionsbausteine des TwinCAT OPC UA Client besitzen eigene Fehlercodes, die das Auftreten eines Fehlers signalisieren und mit einer ErrorID weitere Informationen zum aufgetretenen Problem anzeigen. Es können sowohl TwinCAT-ADS-Fehlermeldungen (ADS Return Codes) mit dem Highword 0x0000 als auch eigene Fehlermeldungen aus dem Client oder der SPS-Bibliothek mit dem Highword 0xE4DD auftreten.
Verwendete TwinCAT-ADS-Fehler sind beispielsweise folgende:
Hex | Name | Beschreibung
0x 0000 0705 | DEVICE_INVALIDSIZE | Parametergröße nicht korrekt
0x 0000 0706 | DEVICE_INVALIDDATA | Ungültige Parameterwerte
0x 0000 070A | DEVICE_NOMEMORY | Nicht genügend Speicher
Diese Fehlercodeliste führt die möglichen eigenen Fehlerwerte auf:
Hex | Name | Beschreibung
0x E4DD 0001 | UAC_E_FAIL | Aufruf von UA Service fehlgeschlagen
0x E4DD 0100 | UAC_E_CONNECTED | Server bereits verbunden
0x E4DD 0101 | UAC_E_CONNECT | Allgemeiner Fehler beim Aufbau einer Verbindung
0x E4DD 0102 | UAC_E_UASECURITY | UA Security konnte nicht eingerichtet werden
0x E4DD 0103 | UAC_E_ITEMEXISTS | Element ID bereits vorhanden
0x E4DD 0104 | UAC_E_ITEMNOTFOUND | Element existiert nicht
0x E4DD 0105 | UAC_E_ITEMTYPE | Ungültiger oder nicht unterstützter Elementtyp
0x E4DD 0106 | UAC_E_CONVERSION | Variablentypen können nicht konvertiert werden
0x E4DD 0107 | UAC_E_SUSPENDED | Gerät hängt. Bitte später erneut versuchen...
0x E4DD 0108 | UAC_E_TYPE_NOT_SUPPORTED | Konvertierung Variablentyp wird nicht unterstützt.
0x E4DD 0109 | UAC_E_NSNAME_NOTFOUND | Kein Namensraum mit dem angegebenen Namen gefunden.
0x E4DD 0110 | UAC_E_CONNECT_NOTFOUND | Verbindung fehlgeschlagen: Ziel-Host konnte nicht gefunden werden.
0x E4DD 0111 | UAC_E_TIMEOUT | Timeout: d. h. Ziel-Host antwortet nicht
0x E4DD 0112 | UAC_E_INVALIDHDL | Sitzungshandle ungültig
0x E4DD 0113 | UAC_E_INVALIDNODEID | UA-Knoten-ID unbekannt
0x E4DD 0114 | UAC_E_INVAL_IDENTIFIER_TYPE | Bezeichnertyp der UaNodeId ungültig
0x E4DD 0115 | UAC_E_IDENTIFIER_NOTSUPP | Bezeichnertyp UaNodeId wird nicht unterstützt
0x E4DD 0116 | UAC_E_INVAL_NODE_HDL | Ungültiges Knotenhandle
0x E4DD 0117 | UAC_E_UAREADFAILED | UA Read aus unbekannter Ursache fehlgeschlagen
0x E4DD 0118 | UAC_E_UAWRITEFAILED | UA Write aus unbekannter Ursache fehlgeschlagen
0x E4DD 0119 | UAC_E_INVAL_NODEMETHOD_HDL | Ungültiges Methodenhandle
0x E4DD 011A | UAC_E_CALL_FAILED | Aufruf fehlgeschlagen, Ursache unbekannt
0x E4DD 011B | UAC_E_CALLDECODE_FAILED | Aufruf erfolgreich, Decodierung Rückgabewert fehlgeschlagen
0x E4DD 011C | UAC_E_NOTMAPPEDTYPE | Nicht zugeordneter Datentyp in Rückgabewert
0x E4DD 011D | UAC_E_CALL_FAILED_BADINTERNAL | Aufruf fehlgeschlagen mit UA_BadInternal
0x E4DD 011E | UAC_E_METHODIDINVALID | Unbekannte MethodenID (bei Aufruf zurückgegeben, auch wenn von GetMethodHdl bereitgestellt)
0x E4DD 011F | UAC_E_TOOMUCHDIM | Methodenaufruf hat Parameter mit mehr als 3 Dimensionen zurückgegeben - wird nicht unterstützt.
0x E4DD 0120 | UAC_E_CALL_FAILED_INVALIDARG | Aufruf fehlgeschlagen mit OpcUa_BadInvalidArgument
0x E4DD 0121 | UAC_E_CALL_FAILED_TYPEMISMATCH | Aufruf fehlgeschlagen mit UAC_E_CALL_FAILED_TYPEMISMATCH
0x E4DD 0122 | UAC_E_CALL_FAILED_OUTOFRANGE | Aufruf fehlgeschlagen mit UAC_E_CALL_FAILED_OUTOFRANGE
0x E4DD 0123 | UAC_E_CALL_FAILED_BADSTRUCTURE | Aufruf fehlgeschlagen mit OpcUa_BadStructureMissing
0x E4DD 0124 | UAC_E_CALL_TYPEMISMATCH_OUTPARAM | Aufruf erfolgreich, aber keine Typenübereinstimmung der bereitgestellten Ausgabeinformation
0x E4DD 0125 | UAC_E_NONVALIDTYPEINFO | Knoten hat unzureichende Typinformationen
0x E4DD 0126 | UAC_E_INVALIDATTRIBID | Zugriff auf ungültiges Attribut von Knoten
0x E4DD 0128 | UAC_E_NOTSUPPORTED | Das Kommando wird vom verbundenen UaServer nicht unterstützt, z. B. beim Aufruf von UA_HistoryUpdate.
0x E4DE 0100 | UAC_E_INVALID_ARRAY_LENGTH | Es wurde eine ungültige, nicht zu DataValueCount passende, Array-Länge am UA_HistoryUpdate zugewiesen.
0x E4DE 0101 | UAC_E_INVALID_DATASIZE | Es wurde ein Datenwert mit ungültiger Datentypgröße am UA_HistoryUpdate zugewiesen. Alle zugewiesenen DataValues müssen vom gleichen Datentyp sein.
0x E4DE 0102 | UAC_E_SUBERROR | Ein unterlagerter Fehler an mindestens einem der übertragenen Datenwerte wurde ausgegeben. Siehe ValueErrorIDs am UA_HistoryUpdate.


ADS Return Codes

Anhang [image] ADS Return Codes
ADS Return Codes
Fehlercode: 0x000..., 0x500..., 0x700..., 0x1000......
Globale Fehlercodes
Hex | Dec | Beschreibung
0x0 | 0 | Kein Fehler
0x1 | 1 | Interner Fehler
0x2 | 2 | Keine Echtzeit
0x3 | 3 | Zuweisung gesperrt-Speicherfehler
0x4 | 4 | Postfach voll
0x5 | 5 | Falsches HMSG
0x6 | 6 | Ziel-Port nicht gefunden
0x7 | 7 | Zielrechner nicht gefunden
0x8 | 8 | Unbekannte Befehl-ID
0x9 | 9 | Ungültige Task-ID
0xA | 10 | Kein IO
0xB | 11 | Unbekannter ADS-Befehl
0xC | 12 | Win32 Fehler
0xD | 13 | Port nicht angeschlossen
0xE | 14 | Ungültige ADS-Länge
0xF | 15 | Ungültige AMS Net ID
0x10 | 16 | niedrige Installationsebene
0x11 | 17 | Kein Debugging verfügbar
0x12 | 18 | Port deaktiviert
0x13 | 19 | Port bereits verbunden
0x14 | 20 | ADS Sync Win32 Fehler
0x15 | 21 | ADS Sync Timeout
0x16 | 22 | ADS Sync AMS Fehler
0x17 | 23 | Keine Index-Map für ADS Sync vorhanden
0x18 | 24 | Ungültiger ADS-Port
0x19 | 25 | Kein Speicher
0x1A | 26 | TCP Sendefehler
0x1B | 27 | Host nicht erreichbar
0x1C | 28 | Ungültiges AMS Fragment
Router Fehlercodes
Hex | Dec | Name | Beschreibung
0x500 | 1280 | ROUTERERR_NOLOCKEDMEMORY | Lockierter Speicher kann nicht zugewiesen werden.
0x501 | 1281 | ROUTERERR_RESIZEMEMORY | Die Größe des Routerspeichers konnte nicht geändert werden.
0x502 | 1282 | ROUTERERR_MAILBOXFULL | Das Postfach hat die maximale Anzahl der möglichen Meldungen erreicht. Die aktuell gesendete Nachricht wurde abgewiesen.
0x503 | 1283 | ROUTERERR_DEBUGBOXFULL | Das Postfach hat die maximale Anzahl der möglichen Meldungen erreicht. Die gesendete Nachricht wird nicht im ADS Monitor angezeigt.
0x504 | 1284 | ROUTERERR_UNKNOWNPORTTYPE | Der Porttyp ist unbekannt.
0x505 | 1285 | ROUTERERR_NOTINITIALIZED | Router ist nicht initialisiert.
0x506 | 1286 | ROUTERERR_PORTALREADYINUSE | Die gewünschte Portnummer ist bereits vergeben.
0x507 | 1287 | ROUTERERR_NOTREGISTERED | Der Port ist nicht registriert.
0x508 | 1288 | ROUTERERR_NOMOREQUEUES | Die maximale Anzahl von Ports ist erreicht.
0x509 | 1289 | ROUTERERR_INVALIDPORT | Der Port ist ungültig.
0x50A | 1290 | ROUTERERR_NOTACTIVATED | Der Router ist nicht aktiv.
Allgemeine ADS Fehlercodes
Hex | Dec | Name | Beschreibung
0x700 | 1792 | ADSERR_DEVICE_ERROR | Gerätefehler
0x701 | 1793 | ADSERR_DEVICE_SRVNOTSUPP | Service wird vom Server nicht unterstützt
0x702 | 1794 | ADSERR_DEVICE_INVALIDGRP | Ungültige Index-Gruppe
0x703 | 1795 | ADSERR_DEVICE_INVALIDOFFSET | Ungültiger Index-Offset
0x704 | 1796 | ADSERR_DEVICE_INVALIDACCESS | Lesen und schreiben nicht gestattet.
0x705 | 1797 | ADSERR_DEVICE_INVALIDSIZE | Parametergröße nicht korrekt
0x706 | 1798 | ADSERR_DEVICE_INVALIDDATA | Ungültige Parameter-Werte
0x707 | 1799 | ADSERR_DEVICE_NOTREADY | Gerät ist nicht betriebsbereit
0x708 | 1800 | ADSERR_DEVICE_BUSY | Gerät ist beschäftigt
0x709 | 1801 | ADSERR_DEVICE_INVALIDCONTEXT | Ungültiger Kontext (muss in Windows sein)
0x70A | 1802 | ADSERR_DEVICE_NOMEMORY | Nicht genügend Speicher
0x70B | 1803 | ADSERR_DEVICE_INVALIDPARM | Ungültige Parameter-Werte
0x70C | 1804 | ADSERR_DEVICE_NOTFOUND | Nicht gefunden (Dateien,...)
0x70D | 1805 | ADSERR_DEVICE_SYNTAX | Syntax-Fehler in Datei oder Befehl
0x70E | 1806 | ADSERR_DEVICE_INCOMPATIBLE | Objekte stimmen nicht überein
0x70F | 1807 | ADSERR_DEVICE_EXISTS | Objekt ist bereits vorhanden
0x710 | 1808 | ADSERR_DEVICE_SYMBOLNOTFOUND | Symbol nicht gefunden
0x711 | 1809 | ADSERR_DEVICE_SYMBOLVERSIONINVALID | Symbol-Version ungültig
0x712 | 1810 | ADSERR_DEVICE_INVALIDSTATE | Gerät im ungültigen Zustand
0x713 | 1811 | ADSERR_DEVICE_TRANSMODENOTSUPP | AdsTransMode nicht unterstützt
0x714 | 1812 | ADSERR_DEVICE_NOTIFYHNDINVALID | Notification Handle ist ungültig
0x715 | 1813 | ADSERR_DEVICE_CLIENTUNKNOWN | Notification-Client nicht registriert
0x716 | 1814 | ADSERR_DEVICE_NOMOREHDLS | Keine weitere Notification Handle
0x717 | 1815 | ADSERR_DEVICE_INVALIDWATCHSIZE | Größe der Notification zu groß
0x718 | 1816 | ADSERR_DEVICE_NOTINIT | Gerät nicht initialisiert
0x719 | 1817 | ADSERR_DEVICE_TIMEOUT | Gerät hat einen Timeout
0x71A | 1818 | ADSERR_DEVICE_NOINTERFACE | Interface Abfrage fehlgeschlagen
0x71B | 1819 | ADSERR_DEVICE_INVALIDINTERFACE | Falsches Interface angefordert
0x71C | 1820 | ADSERR_DEVICE_INVALIDCLSID | Class-ID ist ungültig
0x71D | 1821 | ADSERR_DEVICE_INVALIDOBJID | Object-ID ist ungültig
0x71E | 1822 | ADSERR_DEVICE_PENDING | Anforderung steht aus
0x71F | 1823 | ADSERR_DEVICE_ABORTED | Anforderung wird abgebrochen
0x720 | 1824 | ADSERR_DEVICE_WARNING | Signal-Warnung
0x721 | 1825 | ADSERR_DEVICE_INVALIDARRAYIDX | Ungültiger Array-Index
0x722 | 1826 | ADSERR_DEVICE_SYMBOLNOTACTIVE | Symbol nicht aktiv
0x723 | 1827 | ADSERR_DEVICE_ACCESSDENIED | Zugriff verweigert
0x724 | 1828 | ADSERR_DEVICE_LICENSENOTFOUND | Fehlende Lizenz
0x725 | 1829 | ADSERR_DEVICE_LICENSEEXPIRED | Lizenz abgelaufen
0x726 | 1830 | ADSERR_DEVICE_LICENSEEXCEEDED | Lizenz überschritten
0x727 | 1831 | ADSERR_DEVICE_LICENSEINVALID | Lizenz ungültig
0x728 | 1832 | ADSERR_DEVICE_LICENSESYSTEMID | Lizenz der System-ID ungültig
0x729 | 1833 | ADSERR_DEVICE_LICENSENOTIMELIMIT | Lizenz nicht zeitlich begrenzt
0x72A | 1834 | ADSERR_DEVICE_LICENSEFUTUREISSUE | Lizenzproblem: Zeitpunkt in der Zukunft
0x72B | 1835 | ADSERR_DEVICE_LICENSETIMETOLONG | Lizenz-Zeitraum zu lang
0x72c | 1836 | ADSERR_DEVICE_EXCEPTION | Exception beim Systemstart
0x72D | 1837 | ADSERR_DEVICE_LICENSEDUPLICATED | Lizenz-Datei zweimal gelesen
0x72E | 1838 | ADSERR_DEVICE_SIGNATUREINVALID | Ungültige Signatur
0x72F | 1839 | ADSERR_DEVICE_CERTIFICATEINVALID | öffentliches Zertifikat
0x740 | 1856 | ADSERR_CLIENT_ERROR | Clientfehler
0x741 | 1857 | ADSERR_CLIENT_INVALIDPARM | Dienst enthält einen ungültigen Parameter
0x742 | 1858 | ADSERR_CLIENT_LISTEMPTY | Polling-Liste ist leer
0x743 | 1859 | ADSERR_CLIENT_VARUSED | Var-Verbindung bereits im Einsatz
0x744 | 1860 | ADSERR_CLIENT_DUPLINVOKEID | Die aufgerufene ID ist bereits in Benutzung
0x745 | 1861 | ADSERR_CLIENT_SYNCTIMEOUT | Timeout ist aufgetreten
0x746 | 1862 | ADSERR_CLIENT_W32ERROR | Fehler im Win32 Subsystem
0x747 | 1863 | ADSERR_CLIENT_TIMEOUTINVALID | Ungültiger Client Timeout-Wert
0x748 | 1864 | ADSERR_CLIENT_PORTNOTOPEN | ADS-Port nicht geöffnet
0x750 | 1872 | ADSERR_CLIENT_NOAMSADDR | Interner Fehler in Ads-Sync
0x751 | 1873 | ADSERR_CLIENT_SYNCINTERNAL | Hash-Tabelle-Überlauf
0x752 | 1874 | ADSERR_CLIENT_ADDHASH | Schlüssel nicht gefunden im Hash
0x753 | 1875 | ADSERR_CLIENT_REMOVEHASH | Keine weitere Symbole im Cache
0x754 | 1876 | ADSERR_CLIENT_NOMORESYM | Ungültige Antwort empfangen
0x755 | 1877 | ADSERR_CLIENT_SYNCRESINVALID | Sync Port ist gesperrt
RTime Fehlercodes
Hex | Dec | Name | Beschreibung
0x1000 | 4096 | RTERR_INTERNAL | Interner Fehler im TwinCAT Echtzeit-System.
0x1001 | 4097 | RTERR_BADTIMERPERIODS | Timer-Wert ist nicht gültig.
0x1002 | 4098 | RTERR_INVALIDTASKPTR | Task-Pointer hat den ungültigen Wert 0 (null).
0x1003 | 4099 | RTERR_INVALIDSTACKPTR | Task Stackpointer hat den ungültigen Wert 0.
0x1004 | 4100 | RTERR_PRIOEXISTS | Die Request Task Priority ist bereits vergeben.
0x1005 | 4101 | RTERR_NOMORETCB | Kein freies TCB (Task Control Block) zur Verfügung. Maximale Anzahl von TCBs beträgt 64.
0x1006 | 4102 | RTERR_NOMORESEMAS | Keine freien Semaphoren zur Verfügung. Maximale Anzahl der Semaphoren beträgt 64.
0x1007 | 4103 | RTERR_NOMOREQUEUES | Kein freier Platz in der Warteschlange zur Verfügung. Maximale Anzahl der Plätze in der Warteschlange beträgt 64.
0x100D | 4109 | RTERR_EXTIRQALREADYDEF | Ein externer Synchronisations-Interrupt wird bereits angewandt.
0x100E | 4110 | RTERR_EXTIRQNOTDEF | Kein externer Synchronisations-Interrupt angewandt.
0x100F | 4111 | RTERR_EXTIRQINSTALLFAILED | Anwendung des externen Synchronisierungs- Interrupts ist fehlgeschlagen
0x1010 | 4112 | RTERR_IRQLNOTLESSOREQUAL | Aufruf einer Service-Funktion im falschen Kontext
0x1017 | 4119 | RTERR_VMXNOTSUPPORTED | Intel VT-x Erweiterung wird nicht unterstützt.
0x1018 | 4120 | RTERR_VMXDISABLED | Intel VT-x Erweiterung ist nicht aktiviert im BIOS.
0x1019 | 4121 | RTERR_VMXCONTROLSMISSING | Fehlende Funktion in Intel VT-x Erweiterung.
0x101A | 4122 | RTERR_VMXENABLEFAILS | Aktivieren von Intel VT-x schlägt fehl.
TCP Winsock-Fehlercodes
Hex | Dec | Name | Beschreibung
0x274c | 10060 | WSAETIMEDOUT | Verbindungs Timeout aufgetreten. Fehler beim Herstellen der Verbindung, da die Gegenstelle nach einer bestimmten Zeitspanne nicht ordnungsgemäß reagiert hat, oder die hergestellte Verbindung konnte nicht aufrecht erhalten werden, da der verbundene Host nicht reagiert hat.
0x274d | 10061 | WSAECONNREFUSED | Verbindung abgelehnt. Es konnte keine Verbindung hergestellt werden, da der Zielcomputer dies explizit abgelehnt hat. Dieser Fehler resultiert normalerweise aus dem Versuch, eine Verbindung mit einem Dienst herzustellen, der auf dem fremden Host inaktiv ist—das heißt, einem Dienst, für den keine Serveranwendung ausgeführt wird.
0x2751 | 10065 | WSAEHOSTUNREACH | Keine Route zum Host Ein Socketvorgang bezog sich auf einen nicht verfügbaren Host.
 |  |  | Weitere Winsock-Fehlercodes: Win32-Fehlercodes


Support und Service

Anhang [image] Support und Service
Support und Service
Beckhoff und seine weltweiten Partnerfirmen bieten einen umfassenden Support und Service, der eine schnelle und kompetente Unterstützung bei allen Fragen zu Beckhoff Produkten und Systemlösungen zur Verfügung stellt.
Beckhoff Support
Der Support bietet Ihnen einen umfangreichen technischen Support, der Sie nicht nur bei dem Einsatz einzelner Beckhoff Produkte, sondern auch bei weiteren umfassenden Dienstleistungen unterstützt:
▪
Support
▪
Planung, Programmierung und Inbetriebnahme komplexer Automatisierungssysteme
▪
umfangreiches Schulungsprogramm für Beckhoff Systemkomponenten
Hotline: | +49(0)5246/963-157
Fax: | +49(0)5246/963-9157
E-Mail: | support@beckhoff.com
Beckhoff Service
Das Beckhoff Service-Center unterstützt Sie rund um den After-Sales-Service:
▪
Vor-Ort-Service
▪
Reparaturservice
▪
Ersatzteilservice
▪
Hotline-Service
Hotline: | +49(0)5246/963-460
Fax: | +49(0)5246/963-479
E-Mail: | service@beckhoff.com
Weitere Support- und Serviceadressen finden Sie auf unseren Internetseiten unter http://www.beckhoff.de.
Beckhoff Firmenzentrale
Beckhoff Automation GmbH & Co. KG
Hülshorstweg 20
33415 Verl
Deutschland
Telefon: | +49(0)5246/963-0
Fax: | +49(0)5246/963-198
E-Mail: | info@beckhoff.com
Die Adressen der weltweiten Beckhoff Niederlassungen und Vertretungen entnehmen Sie bitte unseren Internetseiten:
http://www.beckhoff.de
Dort finden Sie auch weitere Dokumentationen zu Beckhoff Komponenten.