Das Internet der Dinge (IoT) steckt, genau wie die industrielle Variante Industrie 4.0, zwar noch in den Kinderschuhen, doch die einzelnen Bausteine und Komponenten existieren schon und können bereits unabhängig vom IoT-Marketing-Hype in den verschiedensten Industrielösungen z. B. für M2M, HMI, Fernzugriff uvm. zum Einsatz kommen.
Im "normalen" Internet ist HTTP das am häufigsten benutzte Protokoll. Es basiert auf einem Request/Response-Prinzip. Soll ein Webbrowser den aktuellen Zustand eines auf einem Server gespeicherten Datenelements darstellen, sendet er einen Request an den Server. Dieser antwortet mit einer Response, in der das Datenelement enthalten ist. Ändert sich der Wert des Datenelements zwischen zwei Requests mehrfach, bekommt der Browser das nicht mit.
MQTT hingegen ist ein ereignisorientiertes Message-Protokoll, das auf einem Publish/Subscribe-Verfahren basiert. Hier kann der Browser ein bestimmtes Datenelement abonnieren (Subscribe). Bei jeder Änderung schickt der Server dann von sich aus per Server-Push den neuen Wert an den Browser. Das geht schneller, als die permanente Abfrage per Request/Response und es geht auch nichts verloren.
MQTT hat sehr gute Chancen, dauerhaft zu einem der wichtigsten Protokolle für das IoT zu werden. Es gibt aber auch noch andere Kandidaten, daher wird über die geeigneten Protokolle sehr intensiv diskutiert. Im Moment gibt es so etwas wie einen Wettstreit verschiedener Messaging-Protokolle für das IoT.
Sollte sich also in Zukunft ein anderes Protokoll als MQTT durchsetzen, dann lässt sich dieses einfach per Software-Update auf der RTDC-Plattform nachrüsten.
Sie möchten gerne Ihre eigenen Erfahrungen im Internet der Dinge sammeln?
Dann ist unser IoT-Entwicklerbaukasten genau das Richtige für Sie!
Wir Zeigen Ihnen gerne, welche Möglichkeiten die Real Time Data Channels noch eröffnen und wie Sie in Ihrem Unternehmen eingesetzt werden können.
Weitere Informationen finden Sie auch im SSV-Forum "Real Time Data Channels".
Die RTDC sind eine universelle IoT-Serviceplattform, mit der die Daten einer beliebigen Anlage gespeichert und in Echtzeit aktualisiert werden können. Anlagen, Sensoren, Aktoren, Devices aller Art - also die "Things" des Internet of Things - bilden in diesem Modell die physischen Repräsentanzen. Zu jeder dieser physischen Repräsentanzen wird nun durch die RTDC-Plattform eine virtuelle Repräsentanz (quasi ein Avatar des physischen Objekts) erzeugt.
Die RTDC dienen so als Datenbroker, der völlig unterschiedliche Datenquellen in einer Plattform zusammenführt, auf die wiederum andere Systeme wie SCADA, ERP, CRM, MES, SQL usw., Smartphone-Apps und Webanwendungen über verschiedene APIs (Application Programming Interface) zugreifen können. Dadurch lassen sich vielfältige Echtzeitanwendungen z. B. für Monitoring, Visualisierung und Alarmierung realisieren.
Die APIs unterstützen unterschiedliche Protokolle und plattformunabhängige Datenformate (wie JSON oder XML), wodurch sich nicht nur neuere Feldgeräte mit modernen Schnittstellen sondern auch ältere Systeme mit geringem Aufwand in das IoT integrieren und somit fit für Industrie-4.0-Anwendungen machen lassen.
Moderne Geräte werden über die sog. Native API (NAPI) mit der RTDC-Plattform verbunden. Die NAPI-Schnittstellen basieren auf weltweit etablierten Internetstandards wie REST (HTTP), HTML5-konforme WebSockets und das Publish-Subscribe-Message-Protokoll MQTT (Message Queue Telemetry Transport). Der Datenaustausch erfolgt in Form des JSON-Datenformats.
Speziell für ältere Geräte, die sich schon seit vielen Jahren im Einsatz befinden und keine modernen Standards wie REST, MQTT oder HTML5 unterstützen, wurden die Connector APIs (CAPI) entwickelt. Damit können Geräte z. B. auch über E-Mail oder SMS eingebunden werden. Außerdem können auch gerätespezifische Erweiterungen als Plugins erstellt und dadurch "Legacy Devices" integriert werden.
Die direkte Unterstützung der NAPIs ist nur mit offenen Systemen möglich, die wie Smartphones, PCs und moderne Steuerungen zumindest über passende Softwareschnittstellen verfügen und moderne Programmiersprachen unterstützen.
Um sich direkt mit der RTDC-Plattform verbinden zu können, muss ein Feldgerät also mindestens eine SMS versenden können oder einen Internetzugang haben, der bestimmte Protokolle unterstützt. Bei Baugruppen, die lediglich ein RS232-, RS485- oder USB-Interface bieten, muss ein geeignetes Remote Access Gateway, wie das IGW/922 oder das IGW/925 von SSV zwischen die Baugruppe und die RTDC-Plattform geschaltet werden, um die Felddaten mit der RTDC-Plattform zu verbinden.
Über ein IGW kann z. B. auch eine RS485-basierte Modbus-Baugruppe oder ein SMS- bzw. E-Mail-Alarmmodem per Internet in die RTDC-Plattform integriert und direkt als RTDC-Datenquelle genutzt werden.
Auf der RTDC-Plattform bildet jede einzelne IoT-Anwendung ein separates Datenprojekt und wird im JSON-Datenformat in einer speziellen Datenbank gespeichert. Ein Datenprojekt kann aus beliebig vielen Datenobjekten (den virtuellen Repräsentanzen) bestehen, die sich wiederum aus einzelnen Datenpunkten, den sog. Items, zusammensetzen.
Abbildung 1: Anlagen, Sensoren, Aktoren, Steuerungen etc. liefern bei jeder Änderung aktuelle Daten über APIs wie REST oder MQTT an ihre virtuelle Repräsentanz auf der RTDC-Plattform (hier im JSON-Datenformat).
Über die APIs werden nun Datenobjekte und -Items angelegt, gelesen, mit neuen Werten versehen und falls erforderlich auch wieder gelöscht. Mit Hilfe eines individuellen Schlüsselpaars wird zudem sichergestellt, dass nur berechtigte Zugriffe auf die RTDC-Plattform möglich sind.
Ein einzelnes Daten-Item enthält aber nicht nur die eigentlichen Nutzdaten, die z. B. ein Sensor liefert, sondern bietet zusätzliche Metadaten, also Daten über Daten. Diese beschreiben die eigentlichen Nutzdaten und geben u. a. Auskunft über die Einheit eines Datums, z. B. "°C" oder "kWh". Durch diese Metadaten lassen sich selbstbeschreibende Datenobjekte entwerfen. Damit greifen die RTDC die Idee hinter dem semantischen Internet der Dinge auf.
Limitierungen hinsichtlich der Datenprojekt-, Objekt- und Item-Anzahl existieren lediglich durch die Ressourcen der eingesetzten Server, auf denen die RTDC-Plattform läuft. Dadurch lässt sich das gesamte System sehr gut skalieren.
Das hängt in erster Linie davon ab, über welches API ein Client-System mit der RTDC-Plattform kommuniziert. Optimal ist eine Verbindung per NAPI und MQTT: hier liegt die Reaktionszeit des Systems bei wenigen Millisekunden für einen Datentransfer von der Datenquelle bis zur Datensenke - also z. B. zwischen Sensor und Aktor.
Ist die Datenquelle hingegen per E-Mail oder SMS mit einem CAPI-Plugin verbunden, können schon viele Sekunden vergehen, bis eine Visualisierungssoftware einen geänderten Wert darstellt oder ein Aktor reagieren kann.
Um die Reaktionsgeschwindigkeit in diesem Fall zu steigern, kann z. B. ein IGW/922 oder IGW/925 zwischengeschaltet werden, welches dann die Kommunikation per MQTT mit der RTDC-Plattform übernehmen kann.
Ein typisches Service-VPN (Virtual Private Network) dient als Infrastruktur, um Wartungsarbeiten und Störungsbeseitigungen ohne kostenintensive Reisezeiten und unnötigen Zeitverlust direkt vom Arbeitsplatz eines Servicemitarbeiters durchzuführen. Im Störungsfall muss der Mitarbeiter allerdings zunächst einmal benachrichtigt werden, bevor er per PC und VPN auf die Anlage zugreift. Hierfür kommt häufig eine SMS zum Einsatz, die von der Anlage über ein SMS-Alarmmodem verschickt wird.
Abbildung 2: Das IGW ist sowohl VPN-Router für den Fernzugriff als auch Gateway für die Echtzeitdaten der Anlagen, Sensoren, Aktoren etc. zur RTDC-Plattform. Diese wiederum bildet eine universelle Schnittstelle u.a. für Apps und IT-Systeme wie SCADA, ERP, CRM usw. Im Störungsfall kann so ein Servicemitarbeiter z. B. per Klingelton oder Vibrationsalarm einer App benachrichtigt werden. Das versenden einer SMS mit allen damit verbundenen Nachteilen entfällt.
Doch eine solche SMS ist aus drei Gründen unzuverlässig:
1. Es gibt keine Garantie, wann und ob sie überhaupt beim Empfänger ankommt.
2. Eine Quittierung ist nicht vorgesehen - die SMS kommt zwar beim Mitarbeiter an, wird aber nicht beachtet.
3. Die SMS wird im Klartext übertragen und bietet keinerlei Datensicherheit.
Zudem verursacht ein SMS-Alarmmodem durch Beschaffung und Betrieb überflüssige Zusatzkosten.
Wird ein IGW/922 oder IGW/925 als VPN-Router für den Fernzugriff eingesetzt, kann dieses auch die Kommunikation zwischen der Anlage und der RTDC-Plattform übernehmen. Da zwischen RTDC-Plattform und App MQTT verwendet wird, kann die App die SMS-Alarmierung vollständig ersetzen. Jedes Mal, wenn sich ein Wert in der Anlage ändert, sendet das IGW die neuen Daten an die RTDC-Plattform, welche die Daten sofort an alle Subscriber - hier die App - weiterleitet.
Die App löst bei Vorliegen einer Alarmkondition einen Klingelton und/oder den Vibrationsalarm aus. Weil die Alarmierung bestehen bleibt, bis ein Mitarbeiter per VPN auf die Anlage zugreift und die Alarmierungsursache beseitigt, ist sichergestellt, dass der Alarm auch wirklich wahrgenommen wird. Zwischen der Anlage und dem Smartphone besteht also durch die RTDC bzw. MQTT eine echtzeitfähige Verbindung, die neben der permanenten Zustandsvisualisierung einen Alarm innerhalb von Sekundenbruchteilen weiterleitet.
Alarme werden also mit Zustellgarantie übermittelt und müssen quittiert werden. Insofern können die RTDC als sinnvolle Erweiterung z. B. für die Automatisierung angesehen werden, die sich problemlos nachrüsten lässt.
Außerdem ergeben sich erhebliche Kosteneinsparungen im Vergleich zu SMS-Lösungen, da neben einem IGW als VPN-Router kein zusätzliches SMS-Meldesystem benötigt wird.
SSV Software Systems GmbH
Dünenweg 5
30419 Hannover
Fon: +49(0)511 · 40 000-0
Fax: +49(0)511 · 40 000-40
Impressum · Datenschutz · AGB
© 2024 SSV SOFTWARE SYSTEMS GmbH. Alle Rechte vorbehalten.
ISO 9001:2015
