Sichere Datenkonnektivität OPC UA richtig implementieren

Auf Betriebsdaten besser zugreifen zu können, wird immer wichtiger. »Embedded OPC UA« ermöglicht es, ihre Automatisierungsprodukte durch native, offene Datenkonnektivität aufzuwerten. Doch es gibt auch Herausforderungen, welche die Anbieter meistern müssen, um die Vorteile dieser Technik zu nutzen.

von Darek Kominek, Senior Strategic Marketing Manager bei MatrikonOPC.

OPC (OLE for Process Control) ist ein Standard für offene Konnektivität von Automatisierungsdaten. Die Lösung ist eine Sammlung von Spezifikationen, die festlegen, wie sich Automatisierungsdaten zwischen Steuerungen, Sensoren, Anwendungen und nahezu allen vernetzten Geräten austauschen lassen. OPC UA (Unified Architecture) wiederum ist die nächste Generation von OPC-Standards der OPC Foundation. Diese Architektur ermöglicht es, nahtlos zwischen allen Komponenten eines Automatisierungssystems und dem Unternehmen zu kommunizieren, und hat sich mittlerweile nicht nur in der Prozesssteuerungsbranche etabliert, sondern auch in vielen anderen Bereichen.

Dank der Flexibilität des Standards können OPC-UA-Anwendungen auch für nicht-Windows-basierte Plattformen wie Linux oder für Embedded Systeme entwickelt werden, die in Umgebungen mit Echtzeitbetriebssystem (Real Time Operating System, RTOS) oder gar als »Bare Metal«-Anwendung laufen, das über gar kein Betriebssystem verfügt. OPC UA lässt sich sogar in Mikrocontroller der günstigsten Preisklasse einbetten.

Warum einen OPC-UA-Server in ein Gerät einbetten? Kurz gesagt: um der Einfachheit willen. Für Endnutzer ist die Suche nach dem einfachsten, effizientesten und kostengünstigsten Weg, jederzeit und überall auf die eigenen Daten zuzugreifen, äußerst schwierig – vor allem, wenn keine zusätzlichen PCs, Konfigurations- und Wartungsaufgaben hinzukommen sollen. OPC UA als native, also eingebettete Technik direkt in die Geräte selbst zu integrieren, verspricht also deutliche Vorteile.

Wenn Unternehmen einen OPC-Server direkt in ein Gerät einbetten, können sie eine Lösung für nahezu jede Anwendung erstellen. Weil die OPC-Tags direkt im Gerät verfügbar sind, muss der Inbetriebsetzungsingenieur nur per Point&Click die OPC-Tags auswählen, die er visualisieren oder protokollieren möchte. Weil das Netzwerk OPC »end-to-end« einsetzt, sind keine Tags manuell zu erstellen oder Prozessvariablen aus anderen Protokollen zu entschlüsseln. Das kann die Dauer der Inbetriebnahme und das Fehlerpotenzial erheblich reduzieren. Darüber hinaus lässt sich der Datenaustausch bei OPC UA authentifizieren und verschlüsseln, wodurch die Installation besser vor Hackerangriffen geschützt ist. Das bloße Eindringen in das Netzwerk reicht dann nämlich nicht aus, um einen Prozess zu kompromittieren.

Ein weiterer Vorteil: Weil die Daten aus eingebetteten UA-Servern normalerweise über einen zentralen oder redundante Server geleitet werden, besteht immer die Möglichkeit, bei Bedarf eine direkte Verbindung mit dem Gerät herzustellen. Das eröffnet viele Optionen für die Gerätekonfiguration und -verwaltung und spart zudem die Kosten für sehr kleine Installationen ein.

Letztendlich ist OPC UA weit mehr als nur ein Automatisierungsprotokoll für Betriebsdaten. Es enthält ein erweiterbares Datenmodell, das es für viele vertikale Märkte interessant macht. Wenn Unternehmen ihr Gerät OPC-UA-fähig machen, haben sie die Chance, neue Absatzmärkte für ihr Produkt zu erschließen. Das Einbetten eines OPC-UA-Servers in ein Produkt kann viele Vorteile mit sich bringen. Ob Unternehmen in den Genuss dieser Vorteile kommen, hängt allerdings davon ab, wie gut sie die Entwicklungshürden meistern. Darauf gehen wir im Folgenden ein.

Entwicklungskosten und Markteinführungszeit

OPC UA ist eine immense Sammlung von Spezifikationen, die mehr als 13 Dokumente und tausend Seiten umfasst. Der Standard behandelt verschiedene Aspekte wie zum Beispiel Transportprotokolle, Sicherheit, Services, Datenmodelle, Profile und viele mehr. Die erste Frage, die sich ein Entwicklerteam bei der Planung der OPC-UA-Einbettung in ein Produkt stellen muss, ist, wie lange die Entwicklung dauern wird und welche Risiken dabei bestehen.

Der Versuch, von vornherein einen eingebetteten OPC-UA-Server in ein Produkt mit Mikrocontroller zu integrieren, ist ein aufwendiges Unterfangen. Daher sollten Unternehmen dies nicht in Angriff nehmen, wenn sie ihr Produkt unter Zeitdruck auf den Markt bringen müssen, weil dieses Unterfangen jahrelange Vorbereitung erfordert und man selbst dann die Produktqualität, den Fertigstellungszeitpunkt und den Erfolg des Gesamtprojekts nicht zuverlässig vorhersehen kann. In den meisten Fällen ist ein kommerzielles Software Development Kit (SDK) der einzig sinnvolle Weg. MatrikonOPC bietet ein OPC UA Embedded Server SDK speziell für ressourcenbeschränkte Plattformen wie Mikrocontroller an. Das Kit soll die Arbeit des Anwendungsentwicklers erleichtern, indem es die komplexen Abläufe automatisch abwickelt. So ist eine schnelle Entwicklung möglich.

Wenn Unternehmen ein neues Produkt entwickeln, möchten sie die Kosten, die Komplexität, den Formfaktor und den Energiebedarf möglichst gering halten, um ihre Kapitalrentabilität (Return on Invest, ROI) zu steigern und ihren Kunden zugleich einen hohen Nutzwert zu garantieren. Haben sie dagegen ein bereits fertiges Produkt und möchten es OPC-UA-fähig machen, sind Firmen an die bestehende Hardware gebunden. Es ist nur eine begrenzte Flash- und RAM-Speicherkapazität für zusätzliche OPC-UA-Funktionen vorhanden. Passt die Implementierung nicht in diesen Rahmen, können Unternehmen den Entwicklungsprozess nicht abschließen. Für eine erfolgreiche Entwicklung ist es daher entscheidend, eine Implementierungsmethode zu wählen, die die Speicherauslastung minimiert. Die Lösung ist wiederum die Verwendung eines Server-SDK. Dieses beseitigt Unsicherheiten bei der Bestimmung des Speicherplatzes, den der OPC-UA-Server letztlich belegen wird, da dies größtenteils vorab festgelegt ist. Das OPC UA Embedded Server SDK von MatrikonOPC belegt minimal 240 KByte Flash- und 35 KByte RAM-Speicher, daher passt der Server sogar in den internen Speicher eines Mikrocontrollers der untersten Preisklasse (Tabelle 1).

KonfigurationFlash (KByte)*RAM (KByte)
Nano Embedded Device Server-Profil24035
Micro Embedded Device Server-Profil26565
Micro Embedded Device Server-Profil
(mit vollständigem Typen-Informationsmodell)
37065

 

Tabelle 1: Mindest-Speicherplatzbedarf des Servers (*Kennzahlen erhoben für ARM-Thumb2-Befehlssatz (Cortex-M4F, GCC-Os)