Steuerungen über das Internet ansprechbar

Abbild Kommunikationsmoeglichkeiten

Bild 2: Kommunikationsmoeglichkeiten (Quelle: Hochschule Heilbronn)

Abbild Geräte

Bild 3: Geräte (Quelle: Hochschule Heilbronn)

Eine Bridge sorgt dafür, dass die LAN-Teilnehmer (Steuerungen) auch über das Internet erreichbar sind, sofern dies gewünscht ist. Außerdem laufen auf dem Raspberry Pi folgende Softwarepakete bzw. Runtimes:

  • Codesys als Soft-SPS mit Modbus TCP/IP (Master) und integrierter Webvisualisierung,
  • Mosquitto als MQTT-Broker,
  • Node-RED als universelles Gateway und OPC-UA-Client sowie weiteren Funktionalitäten,
  • Apache 2 als Webserver und
  • „MySQL“ als Datenbanksystem.

 

Die Soft-SPS kann als lokale Funktionalität angesehen werden und die verbleibenden Programmpakete sind auch als Serverdienste interpretierbar. Auch wenn diese im vorliegenden Fall auf dem Raspberry Pi installiert sind, lassen sie sich ebenfalls in einer Cloud verwenden. Die speicherprogrammierbaren Steuerungen sind als MQTT-Clients programmierbar, indem auf vorhandene Bibliotheken des jeweiligen Herstellers zurückgegriffen wird. Bild 3 zeigt eine kleine Auswahl von kleineren Applikationen bzw. lauffähigen MQTT-Clients.


Netzwerke und Kommunikation

Wie in Bild 2 zu erkennen ist, besitzt der Aufbau drei Netzwerke. Das erste WLAN dient zur Kommunikation zwischen dem Raspberry Pi, den MQTT-Clients sowie verschiedenen Anzeigegeräten, PC oder Smartphones und stellt somit das Sensornetzwerk dar. Dabei fungiert der Raspberry Pi als DHCP-Server und vergibt den einzelnen Clients eine IP-Adresse. Wenn für das erste WLAN der integrierte WLAN-Chip des Raspberry Pi verwendet wird, muss das zweite WLAN über einen USB-WLAN-Dongle aufgebaut werden. Dieses dient zur Anbindung an ein anderes Netzwerk, welches zum Beispiel auch eine Internetverbindung haben kann (Verbindung zu einem Hot-Spot). Die Ethernet-Schnittstelle des Raspberry Pi wird als Kommunikationsschnittstelle zu den speicherprogrammierbaren Steuerungen (und zugehörigem Entwicklungsrechner) verwendet. Die Kommunikation zwischen dem Raspberry Pi, den Steuerungen bzw. Koppler erfolgt über OPC UA, MQTT und/oder Modbus TCP. Speziell der verbreitete und vor allem herstellerübergreifende Industrieeinsatz von Modbus sprach für die Verwendung dieser Kommunikation in der IoT-Box.
OPC UA ist ebenfalls ein herstellerunabhängiges Kommunikationsprotokoll für Automatisierungsapplikationen in der Industrie und basiert, wie Modbus TCP, auf einer Client-Server-Architektur [1]. OPC ist bereits mehrere Jahrzehnte im industriellen Umfeld zu finden, jedoch ermöglicht erst die Weiterentwicklung (UA) eine durchgängige, plattformunabhängige Kommunikation von der Sensor-Aktor-Ebene bis zum MES-System oder einer Cloud (vertikale Integration). Aktuell stellt die Client/Server-Architektur den Flaschenhals für eine deterministische und harte Echtzeitkommunikation dar, da das Request-Response-Konzept an die (zeitlichen) Grenzen stößt. Aus diesem Grund wird auch an einer Erweiterung (OPC UA TSN) gearbeitet, die wiederum das Publish/Subscribe-Konzept beinhaltet.
MQTT (Message Queuing Telemetry Transport) ist ein sehr schlankes Nachrichten-Protokoll, das nach dem Publish/Subscribe-Konzept arbeitet. Dabei kommuniziert der Sender (Publisher) einer Nachricht nicht direkt mit den Empfängern (Subscribern), sondern sendet seine Nachrichten an einen sogenannten Broker, der wiederum als Nachrichtenvermittler interpretiert werden kann. Die Empfänger melden sich beim Broker an und teilen diesem mit, welche Nachrichten an sie weitergeleitet werden sollen. Das bedeutet, dass sich ein Client nur einmal beim Broker anmeldet und somit nicht ständig nachfragen muss, ob neue Nachrichten vorliegen. Er bekommt diese automatisch zugesendet, sobald welche beim Broker eingegangen
sind. Das Konzept ist also ereignisorientiert. Viele Cloudanbieter unterstützen das MQTT-Protokoll bzw. bieten einen entsprechenden Broker an, was das Versenden zum Beispiel von Sensordaten oder den Daten einer SPS in die Cloud vereinfacht.

2 / 3

Ähnliche Beiträge