[:de]OPC UA – Was ist das eigentlich?[:en]OPC UA – what exactly is that?[:]

[:de]

OPC UA – was ist das eigentlich?

Zur Ermöglichung einer Kommunikation zwischen unterschiedlichen Systemen (z.B. einer Kunststoffverarbeitungsmaschine / Spritzgießmaschine / Extruder) und einer PC-Anwendung (z.B. einem virtuellen Assistenzsystem) oder übergeordneten Organisationssystemen (z.B. Produktleitsysteme, BDE etc.) ist es notwendig, dass bekannt ist in welchem Datenmodell die Signale von der jeweiligen Anlage gesendet werden.

Zur Veranschaulichung der Hintergründe einer solchen Kommunikationsaufgabe wird zunächst in leicht verständlicher Form das OSI Schichtenmodell der Datenkommunikation erläutert. Dieses bildet die Basis für jede Art der digitalen Kommunikation und ist zum Verständnis einer Maschinenkommunikation hilfreich.

 

Hintergrund zur Realisierung einer digitalen Datenkommunikation

Das Basis Modell für nahezu jede Form der digitalen Datenkommunikation bildet das OSI Modell. Das OSI Modell wurde bereits 1984 eingeführt und unterteilt die Maschinenkommunikation in 7 hierarchische Ebenen. Für jede einzelne dieser Ebenen sind (verschiedene) Standards definiert. Das OSI Modell ist der bis heute gültige Standard zur Datenkommunikation in IT Systemen. Beim Versand einer digitalen Information durchlaufen die Daten hintereinander alle Stufen des OSI Modells von Stufe 1 bis Stufe 7 bzw. umgekehrt.

 

Um zu verstehen wie eine Datenkommunikation funktioniert, werden einmal die Aufgaben jeder einzelnen dieser 7 OSI Schichten an einem einfachen Beispiel – leicht verständlich und anschaulich – erläutert.

Das hier verwendet Beispiel für die Datenkommunikation sieht so aus, dass ein PC-Benutzer eine Eingabe mit der Tastatur vornimmt und einen kurzen Text erzeugt, der dann über das Internet versendet und auf einem entfernten PC wieder dargestellt werden soll – quasi also eine identische Aufgabe im Vergleich mit der Kommunikation eines Sensorwertes von einer Maschine an eine andere.

Der Mensch gibt seine Eingabe an seinem PC ein. Dafür verwendet er eine Anwendung, z.B. eine E-Mail Programm. Diese Anwendung ist Teil der Schicht 7 – wir beginnen die Erläuterung somit also am Ende des OSI Modells.

Schicht 7: Anwendungsschicht / Application Layer – z.B. Webbrowser

Die Anwendungsschicht ist das was der Benutzer sieht, die Anwendung die er auf seinem PC (oder mobile Device) geöffnet hat und mit der er interagiert. Hier können Interaktionen durchgeführt werden, Eingaben getätigt werden oder Ausgaben abgefragt werden. Der Programmcode der Anwendung wandelt die Eingaben in unterschiedlichste andere Datenformate um, was dem Anwender aber verborgen bleibt.

Die vom Menschen vorgenommene Eingabe in der Anwendung wurde von dieser in einem Datenformat gespeichert, welche für diese Anwendung sinnvoll ist, dies muss aber keinem Standard-Format entsprechen. Um eine Kommunikation mit anderen Systemen zu ermöglichen, ist es somit notwendig, diese individuelle Codierung in eine Standard Codierung umzuwandeln. Dies geschieht in der 6. Schicht.

 

Schicht 6 – Darstellungsschicht / Presentation Layer – z.B. ISO 8822 / X.216

Die Datendarstellungsschicht wandelt die Daten aus dem Format der Anzeige (z.B. ASCII) in eine unabhängige Form und ermöglicht somit den syntaktisch korrekten Datenaustausch zwischen unterschiedlichen Systemen, unabhängig von deren Anzeigeformat. Sie dient somit als Übersetzer zwischen verschiedenen Datenformaten.

Nachdem die Eingaben des Benutzers nun also in einem standardisierten Datenformat zur Verfügung stehen, kann der Transport der Daten beginnen. Softwaresysteme sind jedoch so aufgebaut, dass nicht jedes Softwaresystem eine eigene individuelle Kommunikationslösung generiert, sondern dass Softwaresysteme auf andere Anwendungen (sogenannte Dienste) zugreifen und sich derer Fähigkeiten bedienen. In einem Softwareprogramm, wie einem E-Mail Programm, existieren somit beispielsweise keinerlei Funktionen zur Datenkommunikation, sondern es werden lediglich die notwendigen Dienste angesprochen, die diese Funktion bereitstellen. Derartige Dienste sind in der Regel Standard-Komponenten des Betriebssystems, also beispielsweise Windows, Linux, Android, MacOS, etc. Im übertragenen Sinne ist ein solcher Dienst eine Ressource auf der die Anwendung aufbaut, wie die Stromversorgung eine Ressource eines Produktionsbetriebes ist, die man einfach nutzt anstatt den Strom selbst zu erzeugen.

Die Eingabe des Benutzers in der Anwendung (Schicht 7), die dann in einem Dienst aus Schicht 6 standardisiert wurde, wird nun an einen weiteren Dienst übergeben (Schicht 5), der eine Sitzung für den Datentransport aufbaut.

Für diesen Dienst ist die Realisierung der Kommunikation so etwas wie eine Art kleines Projekt. Dieses Projekt wird in Teilprojekte zerlegt und durchgeführt. Dieser Dienst achtet dabei auch darauf, dass im Falle von auftretenden Problemen (z.B. Datentransport wurde unterbrochen), die Gesamtaufgabe der Datenkommunikation am Ende erfolgreich abgeschlossen werden kann.

 

Schicht 5 – Sitzungsschicht / Session Layer – z.B. ISO 8326

Die Sitzungsschicht oder auch Kommunikationssteuerungsschicht sorgt für die Kommunikation von unterschiedlichen Prozessen oder Systemen miteinander. Dazu werden Dienste für einen organisierten und synchronisierten Datenaustausch zur Verfügung gestellt. Eine beispielhafte Funktion eines solchen Dienstes ist der Einsatz von Check-Points an denen eine auf der Transportschicht unterbrochene Kommunikation wieder nahtlos fortgeführt und synchronisiert werden kann.

Nachdem die Gesamtaufgabe der Datenkommunikation von diesem Dienst (Schicht 5) in Teilaufgaben zerlegt wurde, werden die einzelnen Teilaufgaben in den Versand gegeben, und damit einem Dienst der Schicht 4 (Transportschicht) zugeführt. Dort werden die einzelnen Daten erneut zerteilt, so dass kleine in sich abgeschlossene Elemente übertragen werden können.

 

Schicht 4 – Transportschicht / Transport Layer z.B. TCP, UDP

Auf dieser Ebene werden die Daten zwischen den weiter oben liegenden Ebenen und den darunter liegenden Ebenen transportiert. Innerhalb der Transportschicht werden die Daten segmentiert und organisatorisch abgestimmt und beispielsweise das Entstehen von Staus vermieden. In der Transportschicht werden die Daten, die von den weiter oben liegenden Schichten erzeugt werden in einzelne Segmente (Datenpakete) unterteilt, so dass auch riesige Daten in kleinen in sich gekapselten Elementen ihren Weg durch das Netzwerk finden. Heute gebräuchliche Transport Layer sind beispielsweise TCP/IP oder UDP.

Diese in der Transportschicht zerlegten kleinen Datenbausteine werden nun für die Übertragung vorbereitet. Dazu wird der Empfänger der Daten ausgelesen und es wird eine Route identifiziert, auf der die Datenpakete vom Ausgangspunkt zum Zielpunkt übertragen werden können. So können die Datenpakete beispielsweise von einem PC in Deutschland über einen Server in Frankfurt zu einem Server in Amsterdam und von dort zu einem PC in London übertragen werden. Diese Route ist der in der Vermittlungsschicht geplante Weg (Routing), den die einzelnen Datenpakete nehmen werden.

 

Schicht 3 – Vermittlungsschicht / Network Layer – z.B. IP

Auf Ebene 3 wird die Verbindung zwischen Sender und Empfänger aufgebaut, getrennt und überwacht. Ein häufig verwendeter Standard ist der IP Standard. Diese Ebene dient als Vermittlungsschicht. Dabei werden Aufgaben wie das “Weg-Suchen” und die “Weitervermittlung” von Daten übernommen. Eine Datenübertragung findet selten direkt vom Sender zum Zielempfänger statt, meist gehen die Daten über Zwischenstationen (Knoten). Die Knoten empfangen die Daten und leiten diese auf dem richtigen Weg (Routing) an den nächsten Knoten weiter, bis die Daten am Ziel angelangt sind. Typische Formate auf dieser Ebene sind IP, IPsec, etc.

Nachdem nun die Route festgelegt ist, werden die Daten an die Sicherungsschicht übergeben, in der die einzelnen kleinen Datenblöcke so vorbereitet werden, dass eine sichere und fehlerfreie Datenübertragung sichergestellt werden kann. Die Daten werde dazu so segmentiert, dass in jedem Datenpaket Informationen dazu vorhanden sind wie diese Daten am Anfang und am Ende aussehen, und welche Gesamtmenge an Daten (Prüfsumme) in diesen Daten enthalten ist. Diese Informationen werden jedem einzelnen Datenpaket hinzugefügt und an jedem Knoten auf der Route der Daten überprüft. Fehlt bei einem Datenelement diese Prüfinformation, der Anfang oder das Ende oder stimmt die Prüfsumme nicht mit der übermittelten Prüfsumme überein, werden diese Daten erneut übertragen, so lange bis die Daten korrekt übermittelt wurden.

 

Schicht 2 – Sicherungsschicht / Data Link Layer – z.B. MAC

Die Aufgabe des Data Link Layer ist die Sicherstellung einer zuverlässigen und fehlerfreien Übertragung. In dieser Ebene wird also beschrieben, auf welche Art und Weise der Datenfluss aufgebaut und getrennt wird, wie mit Fehlern umgegangen wird und wie der Datenstrom gehandelt wird. Zu dieser Schicht gehörige Regelungen sind beispielsweise MAC (Media Access Control) oder LLC sowie IEEE. Der Bit-Datenstrom wird aufgeteilt in Blöcke (Frames) und es werden Prüfsummen hinzugefügt, so dass fehlerhafte Blöcke erkannt werden können.

Hardware auf dieser Schicht: z.B. Switch

Zur physikalischen Datenübertragung, werden dann alle Datensegmente in digitale Daten (Bits) zerlegt und diese Signale werden in Form von Einsen und Nullen (digitale Signale) von Endpunkt zu Endpunkt übertragen.

 

Schicht 1 – Bitübertragungsschicht / Physical Layer – z.B. Ethernet

Die physische Ebene beschreibt den physischen Aufbau der Datenkommunikation. Ein Beispiel für den physischen Layer wäre der IEEE 802.3 Standard bzw. auch als Ethernet (Lan Kabel und RJ45 Stecker) bekannt. Auf dieser Ebene werden Bits übertragen, sozusagen also Einsen und Nullen.

Hardware auf dieser Schicht: Netzwerkleitungen, Stecker, etc.

 

Wenn nach Durchlaufen all dieser Schritte die Daten am Zielpunkt angelangt sind, durchwandern diese Daten alle Schichten von Schicht 1 – Schicht 7 erneut, so dass der Empfänger der abgesendeten Textnachricht diese in seiner individuellen Anwendung (z.B. einem anderen E-Mail Programm) und einer anderen Schriftart und Sprache (z.B. im Kyrillischen Alphabet) angezeigt bekommt.

 

Hinweis: Für die Erfüllung der Aufgaben innerhalb jeder einzelnen Schicht existieren mehrere unterschiedliche Möglichkeiten/Dienste. Als Transportprotokoll kann also beispielsweise TCP eingesetzt werden oder UDP oder Profibus, Modbus, Profinet (oder andere). Als Übertragungsschicht kann Ethernet oder WLAN eingesetzt werden, oder, oder oder. Jeder Dienst hat seine eigenen Besonderheiten.

Zudem haben sich für unterschiedliche Systeme in der Vergangenheit unterschiedliche Standards etabliert. PC Systeme arbeiten beispielsweise standardmäßig mit der TCP/IP (Ethernet) Kommunikation während ältere Maschinensteuerungen häufig auf die Kommunikation via Profibus (z.B. RS485) erreichbar sind. Exakt hier setzt OPC UA an…

 

Aber welchen Nutzen bringt diese OSI Schichtarchitektur nun?

Der Nutzen der OSI Architektur liegt darin, dass je nach Zweck und Umgebung für unterschiedlichste Szenarien fertige Dienste genutzt werden können. So ist es beispielsweise möglich, eine TCP/IP Kommunikation sowohl über kabelgebundene Netzwerktypen (Ethernet) als auch über drahtlose Netzwerke wie (WLAN 802.11) aufzubauen. Der besondere Vorteil liegt somit darin, dass der Anwendungsschicht (Schicht 7) völlig egal sein kann, ob über ein WLAN oder ein LAN kommuniziert wird. Die Software (z.B. das E-Mail Programm) funktioniert unabhängig davon völlig problemlos ohne irgendwelche Kommunikationswege oder Logiken in der Software zu ändern.

 

Und welche Aufgabe soll OPC UA nun eigentlich lösen?

Durch die Verwendung von OPC UA soll sichergestellt werden, dass eine sichere, einfache und robuste Kommunikation zwischen unterschiedlichsten Systemen realisiert werden kann.

Der Kommunikationsstandard OPC UA ersetzt dabei keine etablierten Kommunikationsprotokolle (z.B. TCP/IP, Profibus, etc.) sondern er definiert einen Rahmen wie verschiedene Systeme, unabhängig von deren Kommunikationsprotokollen miteinander kommunizieren können.

Ziel von OPC UA ist die Herstellung von Kommunikation zu jedem System, unabhängig davon welches Protokoll dort verwendet wird.

 

Beispiel:

Eine Software kommuniziert mit unterschiedlichsten Systemen und visualisiert in einem Graphen Informationen von allen Systemen gleichzeitig (z.B. Vipra® Graphs):

  • Benutzerinterface der Software
    • Software fungiert als OPC Client (integriert oder extern)
      • OPC Client kommuniziert mit OPC Server (integriert oder extern)
        • OPC UA Server kommuniziert über
          • Profibus mit SPS Maschinensteuerung
          • Profinet mit SPS Maschinensteuerung
          • Canbus mit SPS Maschinensteuerung
          • TCP/IP mit einem anderen System (SPS, PC)
          • RS232 mit einem anderen System (SPS, PC)
          • RS485 mit einem anderen System (SPS, PC)

 

OPC UA ersetzt somit nicht RS232, Profibus, RS485 oder TCP/IP sondern OPC UA legt fest, WAS über die jeweilige Schnittstelle WIE übertragen werden muss, um unabhängig von der Transportebene in gewohnter und identischer Weise auf diese Komponente zugreifen zu können.

 

Was sind dabei die Kernfunktionen die in dem Kommunikationsstandard OPC UA festgelegt werden?

Folgende Funktionen sind in dem Kommunikationsstandard OPC UA definiert:

  • Grundfunktionen
    • Auffindbarkeit: Systeme die OPC UA kommunikationsfähig sind sollen für andere Systeme problemlos im Netzwerk auffindbar sein
    • Strukturen: Alle Datenstrukturen sollen einheitlich sein, so dass z.B. Datei und Ordnerstrukturen erhalten bleiben und keine unstrukturierten Listen entstehen
    • Zugriff: Der Zugriff auf die Strukturen soll durch Zugangsberechtigungen kontrolliert werden können
    • Abonnements: Daten sollen abonniert werden können, so dass diese automatisiert permanent kommuniziert werden und nicht immer abgefragt werden müssen
    • Ereignisse: Festlegungsmöglichkeiten, welche Ereignisse automatisiert gemeldet werden sollen
    • Methoden: es existiert die Möglichkeit unterschiedliche Funktionen aus der Ferne zu starten
  • Plattform-Unabhängigkeit
    • Kompatibel zu PC-Systemen, cloudbasierte Server, beliebige SPS-Steuerungen, Mikrocontrollern
    • Kompatibel zu allen Betriebssystemen: Windows, Apple OSX, Android, Linux, etc.
  • Sicherheit:
    • Firewall-freundliche Gestaltung
    • Kontrollmöglichkeiten
  • Transport:
    • Definition einer Vielzahl von Protokollen von binärem Transport bis hin zu JSON
    • Sitzungsverschlüsselung, verschlüsselte Datenübertragung
    • Nachrichtensignaturen, Prüfung von Herkunft und Integrität der Daten
    • Authentifizierung, Zertifizierung der Zugriffserlaubnisse
    • Benutzerkontrolle, Zugriffsrechtdefinitionen
    • Protokollierung: Zugriffe werden protokolliert
  • Erweiterbarkeit:
    • Offene und wachsende Plattform in die neue Kommunikationsmöglichkeiten kontinuierlich eingebunden werden

 

Worin liegt jetzt der Vorteil zu den klassischen OPC-Versionen?

OPC UA ist der aktuellste OPC-Standard und löst damit vorangegangene OPC-Versionen ab. Bereits in den vorhergehenden Versionen wurden aber bereits erste grundlegende Schnittstellen definiert und der herstellerunabhängige Datenaustausch ermöglicht.

Die klassischen Versionen sind allerdings an ein Windows-Betriebssystem gebunden. Eine direkte Kommunikation über verschiedene Plattformen (Linux, Mac, Android etc.) ist damit nicht möglich. Zusätzlich werden dynamische TCP/IP Protokolle zur netzwerkübergreifenden Kommunikation verwendet. Dies führt häufig zu Firewallproblemen. Ein Umgehen dieser Probleme ist nur über Umwege möglich und ist mit einem erheblichen Aufwand verbunden. Eine gängige Lösung ist das Tunneling. Hierbei wird der Datenverkehr in einem einfachen TCP/IP Protokoll gekapselt, durch die Firewall transportiert und im Zielnetzwerk entpackt.

Wichtige OPC Komponenten wie OPC DA (Datenpunktorientierter Datenaustausch), oder OPC HDA (historische Datenpunkte) werden als Spezifikationen in OPC UA integriert. Diese Spezifikationen können unabhängig voneinander, je nach Anwendungsfall, verwendet werden.

OPC UA vereint nun alle klassischen Funktionen und ermöglicht zusätzlich eine plattformunabhängige, netzwerkübergreifende Kommunikation.

 

Wie werden die Aufgaben im OPC Netzwerk verteilt?

OPC verwendet ein Server-Client-Modell. Hierbei stellt der OPC Server die Basis der Kommunikation. Hier sind der OPC Standard, die OPC Schnittstelle und ein Kommunikationsprotokoll zur Steuerung implementiert. Das logische Gegenstück stellen die OPC Clients dar. Diese können aufgrund des implementierten OPC Standards mit beliebigen Servern verbunden werden und die Daten anwendungsspezifisch auslesen.

(Das virtuelle Assistenzsystem Vipra® kann beispielsweise sowohl die Rolle eines OPC Servers, als auch die eines OPC Clients einnehmen. Es kann somit Daten von allen OPC UA -fähigen Systeme empfangen, als auch Daten an alle OPC UA -fähigen Systeme senden.)

 

OPC UA – nochmal zusammengefasst:

Hinter OPC UA verbirgt sich somit die Beschreibung einer Struktur für eine offene Plattformkommunikation mit einer einheitlichen Architektur (OPC UA – Open Plattform Communication Unified Architecture) entwickelt von der gleichnamigen OPC Foundation, einer unabhängigen Institution.

Hinter diesem Kommunikationsstandard verbirgt sich eine Beschreibung, wie die Kommunikation stattzufinden hat und welche Besonderheiten dabei beachtet werden müssen. Jeder der diesen Standard verwendet, ist kompatibel zu allen anderen Systemen die ebenfalls diese Standards verwenden. Dabei ist die Beschreibung dieser Standards aber vollkommen „offen“ und für jeden zugänglich – es existieren somit keinerlei herstellerspezifische Besonderheiten oder Geheimnisse, wie bei einer sogenannten proprietären Kommunikationsschnittstelle.

Jeder der OPC UA Kommunikation beherrscht, kann somit mit einem anderen OPC UA Kommunikationssystem kommunizieren.

Der OPC UA Kommunikationsstandard ist aber nicht etwa eine Art Dienst oder eine Software und es ist auch keine Protokollbeschreibung wie TCP, IP, etc. In dem Kommunikationsstandard ist lediglich beschrieben, wie die Daten zu strukturieren sind und welche Formate und Dienste eingesetzt werden und in welcher Art diese miteinander kombiniert werden können.

 

Und welchem Konzept folgt die Datenstruktur?

Das grundlegendste Element der OPC UA-Datenstruktur ist ein Datenpunkt, der sogenannte Node. Ein Node  lässt sich vorzugsweise mit einem Objekt aus der objektorientierten Programmierung gleichsetzen.

Jeder Node besitzt Attribute. Diese können Nutz- bzw. Metadaten sein.  Alle Nodes stehen in einer entsprechenden Relation zueinander. Sie werden über Namensräume (engl. Namespaces), in einer Baumstruktur, organisiert.

Innerhalb eines jeden Namespaces ist jeder Node eindeutig bezeichnet. In einem anderen Namespace steht die Bezeichnung aber wieder zur Verfügung. Das sorgt für große Flexibilität und einen dynamischen Code, schafft aber auch komplexe Datenmodelle.

Eine Lösung kann hier die Implementierung von anwendungsspezifische Companion Specifications Plug-ins (bsp. EUROMAP) sein.

 

Stark vereinfachte Beispiele zur Veranschaulichung

Datenzugriff auf eine proprietäre Schnittstelle:

„HT1, 210.5, HT2, 211.5, HT3, 222.3, HT4, 221.0, UM, 75.9, STR, 55, NB, 33, SE, 1278936756123“

Daten sind aus einer solchen Schnittstelle lesbar, es fehlen aber die Strukturen und es ist oft nicht erkennbar um welche Art von Informationen es sich handelt. Der Hersteller kann diese Informationen natürlich leicht auslesen, da ihm die Struktur seiner Daten bekannt ist. Er weiß, dass sich hinter dem Kürzel „HT3“ der Wert der „Temperatur der Heizzone 3“ in der Einheit „°C“ verbirgt und kann dies abfragen. Jemand der diese Information nicht hat, muss dies erst aufwändig „entschlüsseln“.

Datenzugriff über OPC UA – Baumstruktur:

  • Extr:
    • Extr_Zyl_Temp
      • Extr_Zyl_Temp_1:             210.5
      • Extr_Zyl_Temp_2:             205.3
      • Extr_Zyl_Temp_3:             207.4
    • Extr_Antr_Data
      • Extr_Antr_Data_Drehz:     75.9
      • Extr_Antr_Data_Str:          55

In der OPC UA Struktur (insbesondere in Kombination mit einer Branchenspezifizierung wie z.B. EUROMAP) ist genau festgelegt, welcher Wert wie und mit welcher Bezeichnung und Struktur übertragen wird – die Kommunikation mit einem solchen System ist somit erheblich erleichtert.

Wenn dieses Thema für Sie interessant ist, wird Sie vielleicht auch unser nachfolgender Beitrag zum Thema „EUROMAP – Was ist das eigentlich?“ interessieren.

 

Melden Sie sich hier (kostenlos) als Premiummitglied an und erhalten Sie Zugang zu unserem Downloadbereich. Dort finden Sie verschiedene Excel-Tools sowie andere Hilfsmittel und Checklisten. Zudem bleiben Sie als Premium-User stets informiert über neue Beiträge.

 

 

Zusätzlich verwendete Quellen:

https://opcfoundation.org
https://opcua.vdma.org
https://de.wikipedia.org[:en]

OPC UA – what exactly is that?

To enable communication between different systems (e.g. a plastics processing machine / injection moulding machine / extruder) and a PC application (e.g. a virtual assistance system) or higher-level organisational systems (e.g. product control systems, MES, etc.) it is necessary to know in which data model the signals are sent by the respective system.

To illustrate the background of such a communication task, the OSI layer model of data communication is first explained in a short and easily understandable way.

Background to the realization of digital data communication

The basic model for almost every form of current data communication is the OSI model. The OSI model was already introduced in 1984 and divides the machine communication into 7 hierarchical levels. For each of these levels (different) standards are defined. The OSI model is the still valid standard for data communication in IT systems. When sending digital information, the data passes through all levels of the OSI model from level 1 to level 7 or vice versa.

To understand how data communication works, the tasks of each of these 7 OSI layers are explained using a simple example – easy to understand and clear.
The example of data communication used here is that a PC user makes an entry with the keyboard and generates a short text which is then sent over the Internet and displayed on a remote PC – in other words, an identical task compared to the communication of a sensor value from one machine to another.

The human enters his input on his PC. For this purpose he uses an application, e.g. an e-mail program. This application is part of layer 7 – so we start the explanation at the end of the OSI model.

Layer 7: Application layer – e.g. e-mail client software
The application layer is what the user sees, the application he has opened on his PC (or mobile device) and with which he interacts. Here, interactions can be carried out, inputs can be made or outputs can be queried. The program code of the application converts the input into various other data formats, but this is hidden from the user.

The human input in the application is stored in a data format which is useful for this application, but this does not have to be a standard format. To enable communication with other systems, it is therefore necessary to convert this individual coding into a standard coding. This is done in the 6th layer.

Layer 6 – Presentation Layer – e.g. ISO 8822 / X.216
The data presentation layer converts the data from the display format (e.g. ASCII) into an independent form and thus enables syntactically correct data exchange between different systems, regardless of their display format. It thus serves as a translator between different data formats.

Now that the user’s entries are available in a standardized data format, the data transport can begin. However, software systems are structured in such a way that not every software system generates its own individual communication solution. Instead, software systems access other applications (called services) and use their capabilities. In a software program such as an e-mail program, for example, there are therefore no functions for data communication whatsoever, but only the necessary services that provide this function are addressed. Such services are usually standard components of the operating system, for example Windows, Linux, Android, MacOS, etc. In a figurative sense, such a service is a resource on which the application is built, just as the power supply is a resource of a production company that is simply used instead of generating the power itself.
The user input in the application (layer 7), which was then standardized in a service from layer 6, is now passed on to another service (layer 5), which establishes a session for data transport.

For this service the realization of the communication is something like a small project. This project is broken down into sub-projects and executed. This service also makes sure that in case of problems (e.g. data transport was interrupted), the overall task of data communication can be completed successfully at the end.

 

Layer 5 – Session Layer – e.g. ISO 8326
The session layer or communication control layer ensures that different processes or systems communicate with each other. For this purpose, services for an organized and synchronized data exchange are provided. An exemplary function of such a service is the use of check points at which a communication interrupted on the transport layer can be seamlessly resumed and synchronized.

After the overall task of the data communication has been split up into subtasks by this service (layer 5), the individual subtasks are sent to the dispatch department, and thus supplied to a service of layer 4 (transport layer). There, the individual data are divided again, so that small self-contained elements can be transmitted.

Layer 4 – Transport Layer e.g. TCP, UDP
At this level, the data is transported between the higher levels and the levels below. Within the transport layer, the data is segmented and organizationally coordinated and, for example, the creation of traffic jams is avoided. In the transport layer, the data generated by the upper layers is divided into individual segments (data packets), so that even huge data finds its way through the network in small, encapsulated elements. Transport layers commonly used today are, for example, TCP/IP or UDP.

These small data blocks, which are broken down in the transport layer, are now prepared for transmission. For this purpose, the recipient of the data is read out and a route is identified on which the data packets can be transmitted from the starting point to the destination. For example, the data packets can be transferred from a PC in Germany via a server in Frankfurt to a server in Amsterdam and from there to a PC in London. This route is the route planned in the network layer (routing) that the individual data packages will take.

 

Layer 3 – Network Layer – e.g. IP
On level 3 the connection between transmitter and receiver is established, disconnected and monitored. A frequently used standard is the IP standard. This level serves as the switching layer. Tasks such as searching for routes and forwarding data are performed here. Data is rarely transmitted directly from the sender to the destination receiver, usually the data is transmitted via intermediate stations (nodes). The nodes receive the data and forward it to the next node along the correct path (routing) until the data has reached its destination. Typical formats at this level are IP, IPsec, etc.

Once the route has been determined, the data is transferred to the security layer, where the individual small data blocks are prepared in such a way that secure and error-free data transmission can be ensured. The data is segmented in such a way that each data packet contains information about how the data looks like at the beginning and at the end, and what total amount of data (checksum) is contained in this data. This information is added to each individual data packet and checked at each node on the route of the data. If this check information, the beginning or the end is missing for a data element, or if the checksum does not match the transmitted checksum, this data is transmitted again until the data has been transmitted correctly.

 

Layer 2 – Security layer / Data Link Layer – e.g. MAC
The task of the data link layer is to ensure reliable and error-free transmission. This layer therefore describes the way in which the data flow is set up and separated, how errors are handled and how the data stream is handled. Regulations belonging to this layer include MAC (Media Access Control) or LLC as well as IEEE. The bit data stream is divided into blocks (frames) and checksums are added so that faulty blocks can be detected.
Hardware on this layer: e.g. switch

For physical data transmission, all data segments are then broken down into digital data (bits) and these signals are transmitted in the form of ones and zeros (digital signals) from endpoint to endpoint.

 

Layer 1 – Bit transmission layer / physical layer – e.g. Ethernet
The physical layer describes the physical structure of the data communication. An example for the physical layer would be the IEEE 802.3 standard or also known as Ethernet (Lan cable and RJ45 connector). Bits, i.e. ones and zeros, are transmitted on this layer.
Hardware on this layer: network cables, connectors, etc.

When the data has passed through all these steps and arrived at the destination, it travels through all layers from layer 1 – layer 7 again, so that the recipient of the sent text message can see it in his individual application (e.g. another e-mail program) and in a different font and language (e.g. in the Cyrillic alphabet).

Note: There are several different options/services available for fulfilling the tasks within each layer. For example, TCP can be used as transport protocol or UDP or Profibus, Modbus, Profinet (or others). As transmission layer Ethernet or WLAN can be used, or, or, or. Each service has its own special features.
In addition, different standards have been established for different systems in the past. PC systems, for example, work with TCP/IP (Ethernet) communication as standard, while older machine controls are often based on Profibus (e.g. RS485) communication. This is exactly where OPC UA comes in.

 

And what benefits does this OSI layer architecture bring?

The benefit of the OSI architecture is that, depending on the purpose and environment, ready-made services can be used for a wide variety of scenarios. For example, it is possible to establish TCP/IP communication both via wired network types (Ethernet) and wireless networks such as (WLAN 802.11). The particular advantage is therefore that the application layer can be completely independent of whether communication takes place via a WLAN or a LAN. The software (e.g. the e-mail program) works without any problems without changing any communication paths or logic in the software.

 

And which task should OPC UA actually solve?

The use of OPC UA should ensure that secure, simple and robust communication between different systems can be realized.
The communication standard OPC UA does not replace established communication protocols (e.g. TCP/IP, Profibus, etc.) but it defines a framework how different systems can communicate with each other, independent of their communication protocols.
The goal of OPC UA is to establish communication to any system, regardless of which protocol is used.

Example:
A software communicates with different systems and visualizes in a graph information from all systems simultaneously (e.g. Vipra® Graphs):

 

  • User interface of the software
    • Software acts as OPC client (integrated or external)
      • OPC client communicates with OPC server (integrated or external)
        • OPC UA Server communicates via
          • Profibus with SPS machine control
          • Profinet with SPS machine control
          • Canbus with SPS machine control
          • TCP/IP with another system (PLC, PC)
          • RS232 with another system (PLC, PC)
          • RS485 with another system (PLC, PC)

Thus OPC UA does not replace RS232, Profibus, RS485 or TCP/IP but OPC UA determines WHAT has to be transmitted via the respective interface HOW in order to be able to access this component in the usual and identical way independent of the transport level.

What are the core functions defined in the OPC UA communication standard?

The following functions are defined in the OPC UA communication standard:

  • Basic functions
    • Findability: Systems that are OPC UA communication enabled should be easily findable in the network for other systems
    • Structures: All data structures should be uniform, so that e.g. file and folder structures are preserved and no unstructured lists are created
    • Access: It should be possible to control access to the structures through access authorizations
    • Subscriptions: Data should be able to be subscribed to so that they are permanently communicated automatically and do not always have to be queried
    • Events: Possibilities to define which events are to be reported automatically
    • Methods: it is possible to start different functions remotely
    • Platform Independence
    • Compatible with PC systems, cloud-based servers, any SPS controls, microcontrollers
    • Compatible with all operating systems: Windows, Apple OSX, Android, Linux, etc.
  •  Security
    • Firewall-friendly design
    • Control options
  • Transport
    • Definition of a variety of protocols from binary transport to JSON
    • Session encryption, encrypted data transmission
    • Message signatures, checking the origin and integrity of data
    • Authentication, certification of access permissions
    • User control, access right definitions
    • Logging: Accesses are logged
  • Extensibility:
    • Open and growing platform in which new communication possibilities are continuously integrated

What is the advantage over the classic OPC versions?

OPC UA is the latest OPC standard and replaces previous OPC versions. However, the basic interfaces have already been defined here and manufacturer-independent data exchange is now possible.
However, the classic versions are bound to a Windows operating system. Direct communication via different platforms (Linux, Mac, Android etc.) is therefore not possible. Additionally, dynamic TCP/IP protocols are used for cross-network communication. This often leads to firewall problems. Avoiding these problems is only possible via detours and involves considerable effort. A common solution is tunneling. Here, the data traffic is encapsulated in a simple TCP/IP protocol, transported through the firewall and unpacked in the target network.
Important OPC components such as OPC DA (data point oriented data exchange), or OPC HDA (historical data points) are integrated as specifications in OPC UA. These specifications can be used independently, depending on the application.
OPC UA now combines all classic functions and additionally enables platform-independent, cross-network communication.

 

How are tasks distributed in the OPC network?

OPC uses a server-client model. Here the OPC server is the basis of communication. The OPC standard, the OPC interface and a communication protocol for the control system are implemented here. The OPC clients are the logical counterpart. Due to the implemented OPC standard, these can be connected to any server and read out the data in an application-specific way. Vipra® can, for example, take on the role of an OPC server as well as that of an OPC client. It can therefore receive data from all OPC UA-enabled systems and send data to all OPC UA-enabled systems.

 

OPC UA – summarized again:

OPC UA is a description of a structure for open platform communication with a uniform architecture (OPC UA – Open Platform Communication Unified Architecture) developed by the OPC Foundation, an independent institution.
Behind this communication standard is a description of how the communication has to take place and which special features have to be considered. Anyone who uses this standard is compatible with all other systems that also use these standards. However, the description of these standards is completely “open” and accessible to everyone – there are therefore no manufacturer-specific features or secrets, as with a so-called proprietary communication interface.
Anyone who has mastered OPC UA communication can thus communicate with another OPC UA communication system.
However, the OPC UA communication standard is not a service or a software, nor is it a protocol description like TCP, IP, etc. The communication standard only describes how the data is to be structured and which formats and services are used and how they can be combined.

 

What concept does the data structure follow?

The most basic element of the OPC UA data structure is a data point, the so-called node. A node can preferably be equated with an object from object-oriented programming. Every node has attributes. These can be useful data or metadata. All nodes are in a corresponding relation to each other. They are organized via namespaces in a tree structure. Within each namespace, each node is uniquely identified. However, the designation is available again in another namespace. This ensures great flexibility and dynamic code, but also creates complex data models. A solution here can be the implementation of application-specific Companion Specifications Plug-ins (e.g. EUROMAP).

Simplified examples for illustration
Data access to a proprietary interface:
“HT1, 210.5, HT2, 211.5, HT3, 222.3, HT4, 221.0, UM, 75.9, STR, 55, NB, 33, SE, 1278936756123”

Data can be read from such an interface, but the structures are missing and it is often not clear what kind of information is involved. The manufacturer can of course read this information easily, since he knows the structure of his data. He knows that behind the abbreviation “HT3” the value of the “temperature of heating zone 3” is hidden in the unit “°C” and can query this. Someone who does not have this information must first “decipher” it at great expense.

Data access via OPC UA – tree structure:

  • Extr:
    • Extr_Zyl_Temp
      • Extr_Zyl_Temp_1: 210.5
      • Extr_Cyl_Temp_2: 205.3
      • Extr_Cyl_Temp_3: 207.4
    • Extr_Antr_Data
      • Extr_Antr_Data_Drehz: 75.9
      • Extr_Antr_Data_Str: 55

The OPC UA structure (especially with an companion specification such as EUROMAP) defines exactly which value is transmitted how and with which designation and structure – communication with such a system is thus considerably facilitated.

If this topic is of interest to you, you might also be interested in our following article on “EUROMAP – What is it?

 

Register here (free of charge) as a premium member and get access to our download area. There you will find various tools and checklists. In addition, as a premium user you will always be informed about new contributions.[:]

Leave a Reply

Your email address will not be published. Required fields are marked *