Mit dieser Serie von Blog-Artikeln werden wir einige grundlegende Gedanken zum Themenkomplex des „Internet of Things“ – auch kurz „IoT“ genannt – für Planer und Entscheider in mittelständischen Unternehmen zusammengefasst haben.

Wir wollen damit häufig gestellte Fragen beantworten und unseren Lesern einen Einstieg geben, um erste Gedanken zum Thema IoT für das jeweilige Unternehmen zu formulieren.


„Unsere Kunden haben doch gar keinen Bedarf für IoT!“

Hier wollen wir Ihnen kurz erläutern, warum Sie gerade deshalb jetzt Ihre ersten Schritte im Bereich des Internet of Things gehen und ihre eigenen IoT-Projekte starten müssen.

Wie wir in vielen Projekten erleben konnten, resultiert der fehlende „Bedarf“ auf Kundenseite aus einem Mangel an Vorstellungskraft, welchen neuen Nutzen eine IoT-fähige Maschine oder ein „Smarter Sensor“ bieten können.

„Na dann haben wir ja noch Zeit und können erst mal abwarten bis unsere Kunden soweit sind“

Dieses Denken kann sehr teuer werden, insbesondere dann, wenn Sie typischerweise Maschinen und Anlagen auf Kundenwunsch hin bauen.

Sobald nämlich Ihre Kunden selbst anfangen, die Chancen des Internet of Things zu erkennen und Anforderungen für eine IoT-Lösung selbst formulieren, hat Ihr Unternehmen die Innovationsführerschaft verloren.

Denn in der Regel wird Ihr Kunde nicht nur mit Ihrem Unternehmen sprechen, sondern auch mit Ihren Wettbewerbern, möglicherweise auch mit ganz neuen potentiellen Lieferanten und dabei eigene IoT Projekte starten.


Wenn wir bei SIC! Software Smart Products, Industrie 4.0- und IoT-Projekte starten, setzen wir primär Amazon Web Services (AWS) Cloud ein. Warum, das erfahren Sie hier


Und schneller als Ihnen lieb ist, befinden Sie sich mit Ihrem Angebot in einem Preiskampf. Die Innovationen werden nicht mehr von Ihnen getrieben sondern von Ihrem Kunden – Sie sind nicht mehr ein Partner auf Augenhöhe sondern nur noch ein Erfüllungsgehilfe.

„Wie sollen wir mit unseren Kunden ins Gespräch kommen, wenn diese den Nutzen nicht erkennen?“

Um diese Engpass zu lösen, empfehlen wir in einem ersten Schritt die Umsetzung eines Show-Case (auch Demonstrator genannt). Damit können Sie den Kunden Ihre grundsätzliche IoT Lösung und die daraus resultierenden Chancen anschaulich zeigen. Aber nicht nur das. Weil der Kunde ein konkretes Szenario vor sich liegen hat, können Sie auch die Wünsche und Bedürfnisse des Kunden mit einer ganz anderen Qualität diskutieren.

Im Ergebnis erhalten Sie in vielen Fällen eine völlig andere Sicht der Dinge. Es werden neue Chancen sichtbar, die zuvor niemand erkennen konnte. So wird der Weg geebnet, dass Sie mit IoT Ihren Produkten einen einzigartigen Nutzen geben und Sie auch in Zukunft als innovativer Partner auf Augenhöhe wahrgenommen werden.

Wie Sie IoT-Projekte starten, indem Sie an die Planung und Konzeption eines kundenorientierten IoT-Showcase herangehen und wie Sie die strategisch relevanten Themen identifizieren, erfahren Sie in Folge 1 unserer Webinar-Reihe „IoT Projekt-Know-how für Planer und Entscheider“ mit dem Titel „Die Cloud als notwendige Basis für IoT-Lösungen – das AWS-Praxisbeispiel „tempmate“.  Infos & Anmeldung


Weitere Teile dieser Blog-Artikel Serie:

IoT Projekt-Know-how für Entscheider – Teil 1: Warum müssen wir in die Cloud?


Übrigens: Als integrativer Entwicklungsdienstleister für AWS (Amazon Web Services) Cloud-Lösungen bieten wir Ihnen ein fundiertes Know-How in den Themenfeldern Internet of Things (IoT), Smart Products und Industrie 4.0 und helfen Ihnen gerne auch dabei Ihre IoT-Projekte zu starten. … mehr 

 


 

Mit dieser Serie von Blog-Artikeln werden wir einige grundlegende Gedanken zum Themenkomplex des „Internet of Things“ – auch kurz „IoT“ genannt – für Planer und Entscheider in mittelständischen Unternehmen zusammengefasst haben.

Wir wollen damit häufig gestellte Fragen beantworten und unseren Lesern einen Einstieg geben, um erste Gedanken zum Thema IoT für das jeweilige Unternehmen zu formulieren.


Warum müssen IoT-Anwendungen eigentlich in die Cloud?

Ganz einfach: Das Internet of Things lebt von der Vernetzung. Ein „smarter Sensor“ kann nur dann smart (also scheinbar intelligent) sein, wenn er in der Lage ist, mit anderen Systemen zu kommunizieren. Die Begriffe Interoperabilität und Vernetzung sind hier die Schlagworte.

Kein Produktentwickler kann heute voraussehen, mit welchen Systemen seine IoT-Lösung in Zukunft zusammenarbeiten muss. Keine noch so umfassende Analyse kann einem Unternehmen heute verlässlich sagen, wie das digitale Ökosystem aussehen wird, in dem seine Produkte künftig eingesetzt werden.

Eine zentrale Anforderung die aber heute und in Zukunft auf jeden Fall besteht, ist der Umstand, dass die IoT-Systeme und deren Komponenten eine schnelle und unkomplizierte Vernetzung erlauben müssen. Nur dann wird es gelingen, strategische Partnerschaften mit Leben zu erfüllen und tatsächlichen Nutzen zu schaffen.


Warum wir bei SIC Software bei der Realisierung der IoT-, Smart Products und Industrie 4.0-Projekte für unsere Kunden primär Amazon Web Services (AWS) Cloud einsetzen, erfahren Sie hier


Eine IoT Lösung in der Cloud löst nun wichtige zentrale technische Anforderungen:

  • Eine zentrale Softwarelösung in der Cloud erlaubt wirtschaftliches Abbilden standardisierter Schnittstellen. Es muss bei notwendigen Änderungen nur an einer zentralen Stelle gearbeitet werden.
  • Schnellere Innovation für alle Ihre Kunden. Das Hinzufügen neuer Dienstmerkmale zu einer bestehenden IoT-Lösung in der Cloud steht sofort allen angeschlossenen Systemen zur Verfügung.
  • Die IT-Infrastruktur in der Cloud kann bei sich ändernden Anforderungen schnell skaliert werden – und das in beide Richtungen. Systeme können sowohl vergrößert als auch verkleinert werden.
  • Sie können mit vergleichsweise geringem Aufwand bestehende Funktionen externer Anbieter in Ihr eigenes digitales Ökosystem aufnehmen oder aber Ihr IoT-System anderen Ökosystemen zur Verfügung stellen.

Nur mit einer IoT-Lösung, die in der Cloud betrieben wird, ist Ihr Unternehmen in der Zukunft in der Lage, schnell und flexibel zu überschaubaren Kosten auf neue Anforderungen dieser Art zu reagieren.

Welche strategisch relevanten Punkte bei der Auswahl eines Cloud-Anbieters beachtet werden müssen und wie Sie die Kontrolle über Ihre Systeme behalten, erfahren Sie in Folge 1 unserer Webinar-Reihe „IoT Projekt-Know-how für Planer und Entscheider“ mit dem Titel „Die Cloud als notwendige Basis für IoT-Lösungen – das AWS-Praxisbeispiel „tempmate“.  Infos & Anmeldung


Übrigens: Als integrativer Entwicklungsdienstleister für AWS (Amazon Web Services) Cloud-Lösungen bieten wir Ihnen ein fundiertes Know-How in den Themenfeldern Internet of Things (IoT), Smart Products und Industrie 4.0 und unterstützen Sie gerne auch bei Ihrem IoT-Projekt. … mehr 

 


 

Modbus über MQTT – wie geht das?

Im Zeitalter der Digitalisierung und im Rahmen von Industrie 4.0 Anwendungen kommt zwangsläufig die Frage auf, wie bestehende Anlagen zukunftsfähig gemacht werden können. Die Grundlage hierfür sind die am Markt gängigen Systeme für die Vernetzung und den Informationsaustausch von Industrie-Steuerungen und angeschlossenen Sensoren und Aktoren.

Dieser Artikel beschäftigt sich mit der Möglichkeit, vorhandene Systeme zu vernetzen, um Industrie 4.0 Anwendungen überhaupt erst zu ermöglichen. Ganz konkret soll es in diesem Artikel um das Thema „Modbus“ und dessen Vernetzung gehen.

Modbus ist eines von mehreren gängigen Kommunikationsprotokollen für industrielle Anlagen und in der Automationstechnik. Modbus hält zusammen mit der TCP Variante immerhin einen Anteil von 11% am Gesamtmarkt der industriellen Netzwerke.

Quelle: http://www.elektroniknet.de/markt-technik/automation/feldbusse-und-ethernet-im-zeitalter-von-industrie-4-0-128660.html

Modbus ist ein relativ einfaches Master/Slave-Protokoll (https://de.wikipedia.org/wiki/Modbus), welches über verschiedene Leitungswege übertragen werden kann.
Die Frage, wie bestehende Modbus-Systeme mit einer Remote-Überwachung ausgestattet werden können, bzw. wie sich in solchen Systemen eine Predictive-Maintenance-Lösung aufbauen lässt, begegnet uns in Projekten immer häufiger.

Grund genug, hier ein paar grundlegende Gedanken zu diesem Thema zu Papier zu bringen.
Für die Übertragung der Daten in eine Cloud-Lösung á la Azure oder IBM Watson braucht es ein modernes Protokoll, welches auch dafür gemacht ist, mit geringem Ballast relevante Daten zu übermitteln. Ein in diesem Umfeld bewährtes Protokoll ist das MQTT Protokoll, welches wir in früheren Beiträgen schon ausführlich beschrieben haben, siehe:

Das MQTT Protokoll & Hintergründe (Teil 1)

Das MQTT Protokoll & Praxis (Teil 2)

Die Frage die sich nun stellt, ist: Wie kommen die Daten aus einem Modbus in MQTT? Eine kurze Internetrecherche bringt hier einige Ansätze, wie den von Oliver Wagner (https://github.com/owagner/modbus2mqtt) zum Vorschein. Allerdings ist diese Lösung genau wie viele andere für den Einsatz in bestehenden Installation ungeeignet. Der Grund liegt einfach in der Konzeption, denn die meisten gehen davon aus dass Sie ein Modbus Master sind und dann die Daten in MQTT übersetzen.

Das würde allerdings bedeuten, dass die MQTT Implementierung z.B. auf der bestehenden SPS erfolgen müsste, was in der Praxis nicht realisierbar ist.
Der Weg für bestehende Anlagen kann nur über einen Modbus Slave erfolgen. Einen solchen Slave könnte man relativ leicht auf einem Gateway implementieren. Dieses Gateway kann als normaler Busteilnehmer am Modbus arbeiten, ohne den Betrieb zu beeinflussen und alle Daten, die über den Bus laufen, mithören.
Eingriffsmöglichkeiten gibt es in dieser Konstellation zwar keine, aber das ist bei bestehenden Anlagen auch nicht wirklich gewollt.
Sollte man auch Steuerungsmöglichkeiten benötigen, könnte das Gateway als Busteilnehmer Register setzen, welche dann von der SPS in entsprechende Befehle für die anderen Busteilnehmer umgesetzt werden müssen.

Wie man einen solches Gateway aufbaut und welche Komponenten (Software/Hardware) zum Einsatz kommen können, wird der nächste Artikel beleuchten.


Vielleicht auch interessant:

Das MQTT Protokoll – Hintergründe (Teil 1)

Das MQTT Protokoll – Praxis (Teil 2)

IoT Protokolle – MQTT vs. AMQP

MQTT Protokoll – Anwendungsbeispiele

Embedded Software Entwicklung mit dem Standard Finite State Machine Framework

 

Azure IoT in der Praxis – Teil 1 Systemaufbau

Einleitung

Das Internet der Dinge, kurz „IoT“ ist derzeit in aller Munde. Hier übertreffen sich die „Experten“ mit Ihren Ideen und Visionen einer rosigen Zukunft. Wenn es aber um konkrete, praktische Umsetzungen geht, wenn beispielsweise die Frage beantwortet werden soll wie ein IoT Szenario in der Praxis tatsächlich gestaltet werden kann, dann wird es vertiefenden Informationen schnell sehr dünn.
Mit dieser mehrteiligen Artikelserie „Azure IoT in der Praxis“ wollen wir deshalb Abhilfe schaffen. Hier werden wir die verschiedenen Aspekte bei der Realisierung einer praxistauglichen IoT-Lösung anschaulich darstellen und beschreiben.
In diesem ersten Artikel erläutern wir einen industrietauglichen Systemaufbau und die dabei verwendeten Hard- und Software Komponenten. In den weiteren Artikeln werden wir dann einige spezielle Aspekte technisch vertiefen – beispielhaft seien hier die Themen „Datensicherheit“ oder „Alarmierung bei Störfällen“ genannt.


Wenn Sie keinen dieser Beiträge auf diesem Blog versäumen wollen, so empfehlen wir Ihnen, sich in die Mailingliste einzutragen. Sie erhalten dann eine kurze Nachricht, sobald der nächste Artikel zum Thema IoT erschienen ist. Es erfolgt keine Weitergabe der Email-Adresse an Dritte und Sie werden von uns auch keine Werbeemails bekommen. Das versprechen wir Ihnen.


Zielsetzung des IoT-Showcase

Das Team von SIC! Software hat das erste IoT Projekt mit Mobile Anbindung bereits im Jahre 2013/14 realisiert. Seitdem wächst die Zahl der erfolgreich umgesetzten Projekte ständig und damit natürlich auch der Wunsch vieler Unternehmen, mehr über diese Projekte zu erfahren und zu sehen, wie solche Lösungen erfolgreich umgesetzt werden können.
Dabei handelt es sich in nahezu allen Fällen um neuartige Konzepte und Ideen, mit denen bestehende Systeme für das digitale Zeitalter erweitert und fit gemacht werden sollen. Daher wollen unserer Kunden verständlicherweise nichts über ihre neuen Ideen veröffentlichen.
Wir haben uns daher entschlossen, einen eigenen, realitätsnahen IoT-Showcase zu schaffen, der eine durchgängige Technologiekette zeigt, wie sie von SIC! geliefert werden kann.
Dieser Showcase zeigt ein praxisnahes Beispiel von der Embedded Plattform bis hin zur Auswertung der Daten in der Cloud. Es wurde unter Verwendung von Standard-Hardware von STMicroelectronics für das IoT-System, sowie den Cloud-komponenten Microsoft Azure IoT und Microsoft PowerBI umgesetzt. Wir haben uns hier beispielhaft für die Microsoft Azure-Architektur entschieden, da dies derzeit die von unseren Kunden favorisierte IoT-Plattform ist.
Ein denkbarer Anwendungsfall einer solchen Lösung ist beispielsweise ein „Predictive Maintenance“-Szenario, bei dem der möglicherweise drohende Ausfall eines Motors erkannt wird.
Die physikalische Grundlage der Erkennung sind ungewöhnliche Schwingungsmuster, die darauf schließen lassen, dass eventuell ein Schaden am Motor vorliegt.

Auswahl der IoT-Embedded Plattform

Es gibt am Markt eine nahezu unüberschaubare Anzahl von Embedded-Plattformen für solche Anwendungen. Wir haben uns in diesem Fall für eine Evaluationshardware von STMicroelectronics entschieden. Basis ist eine auf dem STM32 Prozessor basierende Hardware (http://www.st.com/en/evaluation-tools/nucleo-f401re.html). Entscheidendes Auswahlkriterium war hier der Umstand, dass hier die für unsere Anwendung nötigen Hardwareerweiterungen für Motorsteuerung, WLAN Modul und Accelerometer-Sensorik als aufsteckbare Nucleo-Komponenten für das STM Evaluationsboard gibt.

BILD

Tiefergehende technische Details findet der interessierte Leser unter den nachfolgenden Links:
Motorsteuerung:
http://www.st.com/content/st_com/en/products/ecosystems/stm32-open-development-environment/stm32-nucleo-expansion-boards/stm32-ode-move-actuate-hw/x-nucleo-ihm11m1.html
WLAN -Modul:
http://www.st.com/content/st_com/en/products/ecosystems/stm32-open-development-environment/stm32-nucleo-expansion-boards/stm32-ode-connect-hw/x-nucleo-idw01m1.html
Accelerometer:
http://www.st.com/content/st_com/en/products/mems-and-sensors/accelerometers/lis3dh.html

Messverfahren und Sensorik

Das Messobjekt ist ein kleiner Drehstrom-Elektromotor mit 15W Leistung, der vom STM32 Board gesteuert, einen kleinen Propeller antreibt. Dieser ist schwingend gelagert montiert. Unter dem Motor ist der Accelerometer-Sensor am Motorträger montiert, mit welchem die Schwingungen des Motors gemessen werden.

Die fehlerhaften Schwingungen im Betrieb werden simuliert, indem am Propeller ein Klebeband angebracht und somit eine Unwucht erzeugt wird.

Signal Theorie und Motor Vibration

Spannend war die Frage, ob es mit dem Accelerometer möglich ist, die feinen Abweichungen der Schwingungsmuster sicher zu detektieren. Die üblichen Accelerometer haben einen Messbereich von +/- 2g mit einer Auflösung von 16 Bit. Das bedeutet, ein Bit entspricht 0,5mg.
Wenn man die technische Dokumentation studiert, stellt man aber fest, dass die tatsächliche, sicher zu detektierende Auflösung eher im Bereich von 1mg aufwärts liegt. (Siehe http://www.st.com/resource/en/datasheet/lis3dh.pdf). Dies sollte aber für diese Anwendung ausreichend sein.
Der kleine Drehstrommotor in unserem Prototyp läuft mit einer Drehzahl von 1500 U/Min, also 25 U/s. Es soll eine mögliche Exzentrizität gemessen und erkannt werden. Dazu gehen wir davon aus, daß jede Vibration eine Sinuswelle produziert. Zur Vereinfachung nehmen wir ferner an, dass die Drehzahl des Motors die niedrigste Frequenz produzieren wird, also rund 25Hz. Um die Sinuswelle sicher zu erkennen, muss mindestens mit der doppelten Frequenz gemessen werden, also 50Hz. In unserer Beispiellösung messen wir mit einer Abtastrate von 400 Hz. Das sollte also auch für deutlich höhere Drehzahlen des Motors noch ausreichend sein.
Für die Errechnung der Vibration gibt es mehrere Möglichkeiten. Wir haben uns hier für die Varianz als einfachste Möglichkeit entschieden (https://de.wikipedia.org/wiki/Stichprobenvarianz). Entscheidend für die Messung ist die Definition des Zeitabschnittes für eine einzelne Messung. In unserem Fall nehmen wir 512 Samples, was bei der Frequenz von 400 Hz eine Aufzeichnungsdauer von 1,2s die Daten zum Analysieren liefert.
Das ermittelte Ergebnis ist ein Messwert, welcher die Abweichung von einem Mittelwert zeigt und damit das Maß der Vibration. Steigt dieser Wert, steigt die Vibration.

Azure IoT Cloud Anbindung Embedded

Nach der Auswahl der Hardware für die Messung und Kommunikation beschrieben wurde, folgt nun der interessante Teil – die Software zur Datenerfassung und Auswertung.
Für die Integration in die Azure Cloud stellt ST eine Referenz-Implementierung für sein Evaluationsboard zur Verfügung, auf die wir weiter aufgebaut haben (http://www.st.com/content/st_com/en/products/embedded-software/mcus-embedded-software/stm32-embedded-software/stm32-ode-function-pack-sw/fp-cld-azure1.html).

Quelle: http://www.st.com/content/ccc/fragment/product_related/rpn_information/board_photo/group0/f3/24/5d/c0/08/39/4c/af/FP-CLD-AZURE1%20image/files/fp-cld-azure1.jpg/_jcr_content/translations/en.fp-cld-azure1.jpg

Das reine IoT SDK von Microsoft, welches im ST-Beispielcode enthalten ist, kann unter dem nachfolgenden Link eingesehen werden (https://github.com/azure/azure-IoT-sdk-c).
Und da der Code ein Multi-Threading verwendet, ist natürlich auch ein entsprechendes Betriebssystem auf der STM32 Plattform erforderlich. Wir setzen hier aus das vielfach bewährte FreeRTOS, das auch von ST für den IoT-Einsatz empfohlen wird.

Microsoft Azure IoT Hub

Der eingesetzte Cloud-Service wird aus den entsprechenden Komponenten auf der Microsoft Azure Seite zusammengestellt. Als zentraler Knotenpunkt wird der ein Azure IoT Hub eingesetzt. Dieser dient dazu, die Daten aller IoT-Geräte entgegenzunehmen und für die weitere Auswertung den nachfolgenden Diensten zur Verfügung zu stellen.
Das Aufsetzen des IoT Hub ist unkompliziert, da dieser einfach im Azure Portal angelegt werden kann. Für diesen Showcase haben einen kostenfreien Demo- Hub eingesetzt, der bis zu 8000 Meldungen pro Tag verarbeiten kann.

Dort werden die Zugangsdaten erzeugt, welche man benötigt, um die IoT-Geräte zu Authentifizieren, damit diesen dann mit dem Hub kommunizieren können.
Anmerkung: Das Thema Sicherheit in IoT Anwendungen werden wir in Kürze in einem weiteren Artikel auf diesem Blog behandeln.

Die Darstellung der Daten im IoT Hub ist allerdings noch relativ unspektakulär. Man sieht zwar, dass Daten fließen und wie viele Geräte aktiv sind, aber für eine sinnvolle Auswertung ist dies noch nicht ausreichend.

Microsoft Azure Power BI

Um nun die gemessenen Vibrationen zu überwachen und Abweichungen erkennen zu können, werden die erfassten Messdaten mit dem Microsoft Power BI visualisiert.
Zu diesem Zweck bietet Microsoft Azure den Dienst „Stream Analytics“ an. Stream Analytics dient – wie der Name schon sagt – dazu, Datenströme zu transportieren und zu analysieren. Dabei werden der Stream Analytics Auftrag und der IoT-Hub am selben Azure-Standort gehostet, um zusätzliche Hosting-Kosten zu vermeiden.

Als Eingabequelle wird der angelegte IoT Hub ausgewählt, als Datenausgabe ein PowerBI Konto.

Damit fließen die erfassten Messdaten vom IoT-Gerät über den Azure IoT Hub und den Stream Analytics Dienst in das Microsoft PowerBI.
Dort wird ein Dashboard zu Visualisierung angelegt, auf dem in einem Liniendiagramm die Werte unserer IoT-Plattform dargestellt werden. Dieses Streamingdataset lässt sich jetzt mit allen von PowerBI zur Verfügung gestellten Mitteln auswerten.

Auswertung und Erkennung

Nachfolgende Masken zeigen, wie unser Algorithmus zur Schwingungserkennung funktioniert.
Im folgenden Diagramm sieht man deutlich den Sprung im Diagramm „Schwingung“ genau in dem Moment, wo der Motor gestoppt das Klebeband befestigt wird.

Beginnt sich der Motor mit angebrachtem Klebeband wieder zu drehen, so erhalten wir einen deutlich höheren Schwingungswert. Dies ist am höheren Schwingungsniveau zu erkennen.
In der Praxis, zum Beispiel bei einem langsam eintretenden Lagerschaden, würde dieser Schwingungs-Messwert wohl eher langsam ansteigen und nicht so schlagartig wie bei unserem Eingriff mit dem Klebeband. In diesem Falle wäre auch optisch am langfristigen Verlauf nicht viel zu bemerken, weshalb hier eine geeignete Logik zum Auswertung der Messwerte und zur Alarmierung vorzusehen ist.
Wie man auf Basis dieser Daten ein entsprechende Erkennung und Alarmierung implementiert, wird Inhalt eines nachfolgenden, vertiefenden Blogartikels sein.


Wie hat Ihnen dieser Artikel gefallen? Gerne lesen wir Ihre Kommentare.
Wenn Sie keinen dieser Beiträge auf diesem Blog versäumen wollen, so empfehlen wir Ihnen, sich in die Mailingliste einzutragen. Sie erhalten dann eine kurze Nachricht, sobald der nächste Artikel zum Thema IoT erschienen ist. Es erfolgt keine Weitergabe der Email-Adresse an Dritte und Sie werden von uns auch keine Werbeemails bekommen. Das versprechen wir Ihnen.


 

Viele Leser unseres Blogs haben uns nach dem Studium unseres Grundlagenartikels zum MQTT-Protokoll nach Anwendungsbeispielen gefragt. Diesem Wunsch wollen wir gerne entsprechen und präsentieren Ihnen nachfolgend eine kleine Sammlung einiger interessanter Projekte, bei denen das MQTT-Protokoll zum Einsatz kommt.

Wir bei SIC! Software setzen das MQTT Protokoll im Bereich von Embedded Projekten sehr häufig ein, da dieses Protokoll einfach zu handhaben ist und sich dank breiter Unterstützung zum DeFacto-Standard im Bereich von Internet of Things (IoT) und Industrie 4.0 entwickelt hat.

Wie z.B. beim Forschungsprojekt IMPROVE, bei dem das MQTT Protokoll dazu eingesetzt wird, um Echtzeitdaten vom Fahrzeug zu übertragen.
/forschungsprojekte/improve-automotive/

 

Da unsere Kundenprojekte der Vertraulichkeit unterliegen, listet die nachfolgende Sammlung beispielhaft öffentlich zugängliche Projekte mit MQTT-Support auf.

 

Beispiel 1: Übermittlung von Temperatursensor-Daten

Implementierung von MQTT auf dem  ESP8266 WIFI Funkmodul mit einer „einfachen“ publish / subscribe Routine.

http://www.s6z.de/cms/index.php/homeautomation-homecontrol/hardwareplattformen/esp8266/113-mqtt-basic-esp8266-mqtt-example

Beispiel 2: Übertragung des Haustürklingel-Signals

Installation des Moskito MQTT Broker auf einem Raspberry Pi. Ein ESP8266 nimmt das Klingelsignal an der Haustür auf und sendet es drahtlos an Fhem via MQTT.

http://blog.wenzlaff.de/?p=6487

Beispiel 3: Temperatur-Überwachung (Englisch)

Eine Musterhafte Lösung zur Überwachung von Temperaturen mit dem ESP8266 WIFI Funkmodul und der Anbindung an einen MQTT-Broker-Dienst unter Ubuntu:

http://www.instructables.com/id/Remote-Temperature-Monitoring-Using-MQTT-and-ESP82/

Beispiel 4: Basis-Plattform für Home-Automation (Englisch)

Implementierung eines MQTT-Stacks auf einem ATMEL  ATmega328p

http://blog.atx.name/building-avr-board-with-mqtt-support-for-iot/

Beispiel 5: Steuerung einer LED-Beleuchtung (Englisch)

Steuerung einer LED-Beleuchtung mit einem WS2812 LED Controller über das MQTT-Protokoll.

http://www.instructables.com/id/ESP8266-Led-Strip-MQTT-Control-Lights-WS2812/?ALLSTEPS

Beispiel 6: Regelung der CPU-Kühlung eines Raspberry Pi (Englisch)

Regelung der CPU-Kühlung eines Raspberry Pi über einen mit dem MQTT-Protokoll konfigurierbaren PID Regler:

http://www.instructables.com/id/PID-Control-for-CPU-Temperature-of-Raspberry-Pi/

Beispiel 7: Steuerung eines LCD-Displays (Englisch)

Applikationsbeispiel zur Steuerung eines LCD-Displays am INTEL Edison über das MQTT-Protokoll:

http://www.instructables.com/id/MQTT-what-is-this/

Weitergehende Grundlagen und Informationen zur MQTT-Standardisierung sind auf der Webseite http://mqtt.org/ beschrieben.


Vielleicht auch interessant:

Das MQTT Protokoll – Hintergründe (Teil 1)

Das MQTT Protokoll – Praxis (Teil 2)

IoT Protokolle – MQTT vs. AMQP

Modbus über MQTT – wie geht das?

Embedded Software Entwicklung mit dem Standard Finite State Machine Framework

Das „Internet of Things“ – kurz „IoT“ – ist im Moment das große Thema in der Industrie und Softwarebranche. Nachdem wir schon in einem etwas älteren Blockartikel das Thema MQTT aufbereitet und analysiert haben, ist es Zeit, sich einem zweiten wichtigen Protokoll im Umfeld von IoT anzunehmen. In diesem Artikel werden wir die beiden Protokolle vergleichen und mögliche Unterschiede bei den Einsatzszenarien beschreiben.

Wer heute ein IoT-Projekt umsetzen möchte, muss sich vor allem Gedanken darum machen, wie er die auszutauschenden Daten möglichst effizient und standardisiert übertragen kann. Zu diesem Zweck gibt es verschiedenste Protokollstandards, die entwickelt wurden, damit Plattform und Technologie übergreifend miteinander kommunizieren können.

Speziell im IoT Umfeld erfüllen die entwickelten Protokolle vor allem noch die Aufgabe möglichst mit wenigen Ressourcen auszukommen.

Was ist also AMQP und was kann es leisten?

AMQP steht für Advanced Message Queuing Protocol und wurde durch ein Konsortium von großen Unternehmen aus verschiedenen Branchen – u.a. VMware, Microsoft und Cisco – entwickelt. Bereits in 2010 gab es den ersten Draft des Protokolls.

Im Kern handelt es sich um ein asynchrones Protokoll zur Nachrichtenübertragung. Die bisher beste Erklärung zur Idee hinter AMQP findet man auf der Seite von RabbitMQ (https://www.rabbitmq.com/tutorials/amqp-concepts.html).

AMQP funktioniert demnach nach folgendem Prinzip:
Nachrichten werden an sogenannte Börsen (Exchanges) übertragen (vergleichbar mit einem Postamt). Die Börsen verteilen dann Nachrichtenkopien in Warteschlangen (Queue) basierend auf Regeln, sogenannten Bindings.

Die Nachrichten werden dann vom Empfänger direkt abgeholt, wenn er das möchte. Alternativ kann der Empfänger die Nachrichten auch bei einer Warteschlange abonnieren und bekommt diese dann direkt zugestellt.

Wenn die Nachrichten publiziert werden, kann der Herausgeber der Nachricht diese noch mit Attributen (Meta-Daten) versehen. Diese Metadaten können vom Empfänger beliebig genutzt werden.

Nachrichten bleiben so lange in den Warteschlangen, bis der Empfänger bestätigt hat, die Nachricht auch wirklich empfangen zu haben. Damit ist auch bei schlechtem Netz und Abbrüchen bei der Verbindung sichergestellt, dass die Nachricht den Empfänger erreicht.

Wenn eine Nachricht nicht zugestellt werden kann, erhält der Sender eine entsprechende Nachricht.
Die Umsetzung der Börse und der Warteschlange erfolgt innerhalb des sogenannten Brokers. Ein Broker ist z.B. der freie Server von RabbitMQ.

Die Börse ist dafür zuständig, die Nachrichten in eine oder mehrere Warteschlangen zu übertragen. Die Regeln dafür leiten sich aus den vordefinierten Austauschformaten (exchange types) und den Bindings ab.

Es gibt vier solche Austauschformate:

  • Direct –> Stellt eine feste Verbindung zwischen einer Börse und einer Warteschlange dar. Wenn eine Nachricht mit einem entsprechenden Schlüssel ankommt, wird diese gleich an die verknüpfte Warteschlange zugestellt.
  • Fanout –> Wird für sogenannte Broadcast Nachrichten verwendet. Die Nachricht wird von der Börse an alle angeschlossenen Warteschlangen zugestellt
  • Topic –> Wird für Publish/Subscribe Szenarien verwendet. Die Nachrichten werden an eine oder mehrere Warteschlangen ausgeliefert, abhängig vom Binding Key. Folgendes Bild von RedHat veranschaulicht das sehr schön.
  • Headers –> Die Zustellung der Nachricht zur Warteschlange erfolgt hier über den Nachrichten-Header und nicht den Routing Key. Es ist vergleichbar mit dem Direct Routing – nur mit etwas mehr Möglichkeiten zur Regelerstellung.

Neben den Austauschformaten gibt es eine Reihe von Attributen für die Nachrichten. Die wichtigsten sind:

  • Name
  • Durability (gibt an, ob die Börse einen Neustart des Broker übersteht)
  • Auto-delete (Börse wird gelöscht, wenn keine Warteschlange diese benötigt)

AMQP vs. MQTT im Vergleich

Der größte Unterschied der beiden Protokolle besteht in den Möglichkeiten für die Nachrichtenzustellung. Während MQTT ausschließlich auf Publish/Subscribe basiert, lassen sich mit AMQP auch andere Zustellungsformen realisieren.

Außerdem ist der Unterschied bei der Implementierung nicht zu unterschätzen. MQTT ist mit seinen 5 Methoden relativ schnell und einfach umzusetzen, während AMQP schon einen vergleichsweise großen Umfang mit sich bringt. Das betrifft sowohl die Definition des eigenen Protokoll wie auch die Implementierung und Test.

Die kleinste Paketgröße bei AMQP ist mit 60 Byte auch nicht zu vernachlässigen. MQTT begnügt sich im besten Fall mit 2 Byte. Das beeinflusst insbesondere bei einer großen Zahl von Geräten und Nachrichten den aufzuwendenden Aufwand erheblich. Dazu kommen größer Laufzeiten der Pakete die je nach Anwendungsfall auch kritisch zu betrachten sind.

Es gilt also abzuwägen, ob der Funktionsumfang von AMQP im jeweiligen Anwendungsfall wirklich benötigt wird oder nicht. Wenn man mit dem Publish/Subscribe Model von MQTT auskommen kann, hat man in jedem Fall eine einfacher umzusetzende und auch ressourcenschonende Lösung.


Vielleicht auch interessant:

Das MQTT Protokoll – Hintergründe (Teil 1)

Das MQTT Protokoll – Praxis (Teil 2)

MQTT Protokoll – Anwendungsbeispiele

Modbus über MQTT – wie geht das?

Embedded Software Entwicklung mit dem Standard Finite State Machine Framework

 

Beacons
Im Sommer 2013 wurden sie offiziell vorgestellt und so langsam kommt die ganze Sache auch ins Rollen. Die Rede ist von der Beacon Technologie. Beacons (Signalfeuer) sind kleine Bluetooth-Sender, welche an einem Ort angebracht werden können und in regelmäßigen Zeitintervallen ein Erkennungssignal aussenden. Dieses Signal kann dann von einem Beacon-fähigen Gerät wie einem Smartphone oder Tablet empfangen und in ortsabhängige Informationen umgewandelt werden. Die Anzahl an Anwendungsgebieten ist dabei grenzenlos. Meistens werden Beacons mit typischen Einsatzgebieten wie …

Weiterlesen

Während unser erster Blog-Artikel zum Thema MQTT eher theoretischer Natur war, möchten wir uns nun dem praktischen Teil widmen.

Alles was wir dazu benötigen ist eine MQTT-Client Library sowie einen Broker. Eine große Auswahl an verschiedenen Client- und Broker Implementierung bietet das Eclipse Paho Projekt. Zur Zeit stellt es Implementierungen für C, Java, Javascript, Python, Lua, C++, Embedded C und bald auch Objective-C bereit. Als Broker empfehlen wir die kostenlose Lösung von Mosquitto. Wer Probleme mit der Installation hat, sollte sich diesen Link zu Gemüte führen: Guide to Installing Mosquitto MQTT. Zu Demonstrationszwecke oder einfachen Versuchen, lohnt es sich allerdings die sogennanten Public-Brokers zu verwenden. Eine kleine Auswahl an solchen ist hier zu finden: Public Brokers.
Weiterlesen

Internet of things: Viele haben schon mal was davon gehört, aber nur wenige können so richtig beschreiben was es überhaupt ist… dieses „Internet of things“? Wikipedia beschreibt es folgendermaßen:

The Internet of Things refers to the interconnection of uniquely identifiable embedded computing like devices within the existing Internetinfrastructure. 

Weiterlesen