Architekturen

Die OPC Unified Architecture bietet Mechanismen zur standardisierten, synchronen oder asynchronen,
verteilten Kommunikation. OPC UA ermöglicht den Zugriff auf Daten unterschiedlichster
Art in vertikaler als auch horizontaler Richtung. Dies ermöglicht ein breites Anwendungsspektrum,
schließt aber auch unterschiedliche Architekturvarianten und die Betrachtung der zugrunde liegenden
Netzinfrastruktur ein. OPC-UA-Komponenten können in unterschiedlichsten Varianten,
Plattformen, von verschiedenen Herstellern kombiniert werden. Das Spektrum reicht von
OPC-UA-Komponenten direkt integriert auf den Geräten und Steuerungen bzw. Maschinen und
Anlagen über sogenannte Gateways bis hin zu aggregierenden Servern. Daher sollen nachfolgend
mögliche Architekturvarianten mit einigen Beispielen vorgestellt werden, an denen sich zukünftige
Anwender orientieren können.

Im Fall von OPC UA handelt es sich um die IT-Architektur (System- und teilweise Software-Architektur),
die diverse Einflussfaktoren zur Ermittlung möglicher Realisierungsvarianten einbeziehen
muss. Dies können beispielsweise sein: Produktionskomponenten und deren Schnittstellen sowie
weitere vorhandene Infrastruktur, Hardware, Software, Schnittstellen, Netzwerke oder Standorte.
Die Definition einer Architektur ermöglicht die ganzheitliche Sicht auf ein System mit OPC-UAKomponenten
und sollte vor Beginn der Realisierung in jedem Fall (wenn auch nur rudimentär)
erstellt und diskutiert worden sein.
OPC-UA-Server- und auch -Client-Funktionalität wird normalerweise aufgrund der Komplexität
nicht von Grund auf implementiert, sondern auf Basis sogenannter Software Development Kits
(SDKs) erstellt. Hier gibt es sowohl kommerzielle Varianten (siehe Abschnitte 4.1 und 4.2) als auch
Open-Source-Lösungen (siehe Abschnitt 4.3), die abhängig von der Prozessorarchitektur, vom
Betriebssystem, aber auch von der Programmiersprache einzusetzen sind.
Prinzipiell sollten sich Anwender vor der Nutzung von OPC UA über den Einsatz und Nutzen von
OPC UA sowie die vorhandene Infrastruktur und Umgebung im Klaren sein.


Ist OPC UA als Brücke zwischen verschiedenen Komponenten und Stationen auf der Feldebene
geplant, können alle Komponenten innerhalb des Fabriknetzes betrieben werden

Ist ein überwachender und steuernder Eingriff auf Basis von berechneten Kennzahlen,
zentralen Arbeitszeitmodellen oder anderen MES-Funktionalitäten angedacht, wird die MESFunktionalität
sicherlich von der zentralen IT bzw. im Rechenzentrum betrieben. Ein Übergang
zwischen Fabriknetz und Office-IT, beispielsweise unter Nutzung einer DMZ (demilitarisierte
Zone) sollte diskutiert werden.


Soll das Ganze dem Zweck der Fernwartung dienen, ist sicherlich eine Verbindung zu
beispielsweise Clients in externen Netzen über verschiedene Netzgrenzen hinweg nötig. Auch
hier sind nochmals Diskussionen über eine DMZ zwischen zentraler IT und dem Internet bzw.
externen Firmennetzen sinnvoll.


Für die Überwachung einer bestimmten Gerätegruppe ist vielleicht kein schreibender Zugriff
nötig, sondern alle Werte werden nur lesend bereitgestellt. Dies senkt das Risiko der Beeinflussung
des Produktionsprozesses und reduziert die zu betrachtenden Bedrohungen.


Aber auch die Anzahl an zu erwartenden Kommunikationspartnern sollte vorab eingegrenzt
werden. Es muss geklärt werden, welche der möglichen Realisierungsvarianten das Mengengerüst
(nicht nur hinsichtlich der zu übertragenden bzw. verwalteten Informationen) überhaupt
abdecken können.


Sofern selbst implementiert und kein fertiges Produkt gekauft werden soll, ist die einzusetzende
Programmiersprache ebenfalls ein zu berücksichtigender Faktor, der die möglichen
Programmierhilfen einschränkt.


Eventuell gibt es verschiedene Realisierungsvarianten, beispielsweise mit einem in die Steuerung
integrierten OPC UA Server, der Werte des Geräts für den lesenden Zugriff bereitstellt,
oder einem OPC UA Client, der aktiv diese Werte in einen zentralen OPC UA Server schreibt.
Diese müssen mit all ihren Vor- und Nachteilen bezüglich Kosten, Wartungsaufwand,
Erweiterbarkeit und vielen anderen Zielkriterien Entscheidungen getroffen werden.

Außerdem muss geklärt werden, wo die einzelnen OPC-UA-Komponenten lokalisiert sind. Sind
diese im eigenen Produktionsnetz, direkt an der Maschine, laufen sie im Rechenzentrum des
Unternehmens oder sind sie gar beim Hersteller der Komponenten (außerhalb des Firmennetzes)
zu finden? Der Einsatzort beeinflusst die Realisierbarkeit ebenso wie die vorhandene
Infrastruktur und Implementierungsumgebung. Hiermit hängt eng das Konzept zur IT-Sicherheit
zusammen.

 

Schließlich beeinflusst der Einsatzzweck auch das zugrunde liegende Informationsmodell, die zu

realisierende Funktionalität, die Nutzung
möglicher Companion Specifications und damit auch die Realisierungsvarianten,
die diese Rahmenbedingungen umsetzen können.

Zusammenfassend lässt sich die Zielarchitektur nicht planen, ohne unter anderem die genannten
Einflussfaktoren zu kennen und zu berücksichtigen. Zunächst müssen also die Anforderungen definiert
und dann mit den möglichen Realisierungsvarianten abgeglichen werden.
OPC UA bietet mit den Möglichkeiten zur Konformitätsüberprüfung praktische Unterstützung,
um die geforderte Funktionalität zu gewährleisten bzw. zu prüfen.
Die meisten OPC-UA-Anwendungen basieren auf dem Client-Server-Modell für verteilte Anwendungen.
Der Server stellt Daten und Dienste bereit, die der Client anfordern und konsumieren
kann. Die bidirektionale Kommunikation zwischen Client und Server folgt dem Request-Response-
Modell. Der Client fordert, der Server antwortet. Dies bedeutet im Umkehrschluss, dass
der Server in letzter Instanz die Hoheit über die Daten besitzt.

Hinweis: Zur Unterstützung von verbindungsloser Kommunikation, beispielsweise in Anwendungsfällen
des Industrial Internet of Things (IIoT), unterstützt OPC UA mit der neuesten Pub-
Sub-Spezifikation [pubsub] ebenfalls das verbindungslose Publish-Subscribe-Modell. Dieses
Kapitel fokussiert allerdings die zuvor genannten Client-Server-Anwendungen.

BE IN 
TOUCH

Friedrichstr. 123 Berlin, DE 10117 

Email: contact@muellermation.com

Tel +49  800 23 44 967 

     +49 1522 23 44 967

  • Asset 7
  • Asset 6
  • Asset 8
  • Asset 9
  • Asset 10