Eine kurze Einführung in das Paradigma der Serverless-Architekturen – am Beispiel der AWS Cloud


Da das Schlagwort „serverlose Technologien“ im Kontext der Cloud Nutzung immer wieder genannt wird, fragen Sie sich möglicherweise, was den „serverlos“ in der Praxis genau bedeutet.

Es ist allgemein bekannt, dass man keine Rechenleistung (Compute-Workload) ohne einen physisch vorhandenen Computer bzw. Server erbringen kann. Das führt zu der Frage, wie spiegelt sich dies in den verschiedenen Serverless-Technologien wie Docker, Kubernetes und Function-as-a-Service (FaaS) wider?

Beginnen wir damit warum man diese Technologien überhaupt als „serverless“ bezeichnet, wenn doch immer noch ein Server zur eigentlichen Ausführung benötigt wird?

Ohne Software geht es nicht

Im Grunde genommen ist es aber ganz einfach: Es kommt auf den Betrachtungswinkel an.

In einer klassischen IT-Umgebung würde man einen Server bereitstellen, seine Anwendung dort installieren und diese dann dort ausführen lassen. Dabei muss man natürlich dafür sorgen, dass alle technischen Abhängigkeiten der betreffenden Anwendung (wie z.B. Sprachbibliotheken, Datenbanken, Visualisierungstools, usw.) auf dem betreffenden Server installiert sind.

Wenn ein neues Release der Anwendung verfügbar ist oder man weitere Ressourcen benötigt, weil das System zum Beispiel mehr Rechenleistung erbringen soll, muss ein Entwickler oder Administrator auf den Server zugreifen und dort die betreffende Software installieren. Das kann zwar mit Tools wie Configuration-Management, Continous-Delivery-Pipelines, zentralisiertem Logging, usw. vereinfacht werden, aber am Ende des Tages muss immer eine Person, also ein Entwickler oder Administrator, zumindest etwas Kenntnis über den betreffenden Server und seine darauf installierten Anwendungen haben. Nur dann ist sie in der Lage, im Falle, dass es technische Probleme gibt, nach einer Lösung zu suchen und diese zu beheben.

Container

An diesem Punkt müssen wir einen kleinen Abstecher in das grundlegende Konzept von Serverless machen – den sogenannten „Container“.

Ein „Container“ ermöglicht es eine Anwendung inklusive der benötigten Systemumgebung auszuliefern. Dies macht es überflüssig, anwendungsspezifische Abhängigkeiten separat zu installieren, da sie bereits zusammen mit der Anwendung als Image ausgeliefert werden.
Und daraus resultiert auch der große Vorteil von Containern: Sie laufen praktisch überall.

Mit dem Begriff „Container“ ist übrigens nicht unbedingt nur ein „Docker Container“ gemeint, sondern auch der gute alte LXC Container (worauf Docker basiert) oder jede andere Container-Technologie.

Die Nutzung von Containern verschiebt die Verwaltung der Abhängigkeiten und die Bereitstellung der für die Ausführung der Anwendung erforderliche Umgebung vom Administrator des Servers hin zu den Entwicklern der Anwendung.

Ich bin mir sicher, dass auch Ihr Betriebsteam ein Mitspracherecht haben will und sollte. Im Wesentlichen ist dies der Punkt, an dem Sie eine DevOps-Kultur oder noch besser eine DevSecOps-Kultur benötigen.

Container können verwendet werden, ohne große Änderungen in der klassischen Umgebung umzusetzen. Es ändern sich lediglich ein paar Zuständigkeiten.

Geht man einen Schritt weiter bei der Verwendung von Serverless-Technologien, verschiebt sich die Interaktion zwischen Entwickler und Anwendung vom Server zu dem gewählten Orchestration-Tool (ich verwende für den Rest des Artikels Kubernetes als Beispiel, aber dasselbe gilt auch für andere Tools). Es gibt kein direktes Deployen von Anwendungen auf dem Server oder manuelle Konfiguration von Netzwerk-Komponenten, z.B. ein Load-Balancer. Man übergibt Kubernetes einfach eine neue Konfiguration und die neuste Version der Anwendung wird auf dem verfügbaren Server (Node) oder auf mehreren Servern (Nodes) ausgeliefert.

Doch hier sind sie ja schon wieder, diese verflixten Server!?!

Ohne Server geht es nicht

Die Verwaltung dieser Server häng davon ab ob man sein Kubernetes-Cluster On-Premise oder in der Cloud als Managed-Service betreibt. Das macht einen großen Unterschied, wenn es darum geht, sein Cluster zu verwalten.

Läuft es On-Premise, so muss man das Kubernetes-Cluster selbst verwalten und pflegen. Die Systemadministratoren müssen sich nicht länger mit dem Verwalten einzelner Anwendungen beschäftigen, sondern nur um das Cluster (oder mehrere Cluster) und alle dazugehörigen Server kümmern.

Wenn Kubernetes als Managed-Service in einer Cloud wie Amazon (AWS) Elastic Kubernetes Service (EKS), Google (GCP) Google Kubernetes Engine (GKE) oder Azure Kubernetes Service (AKS) läuft, reduziert sich der Verwaltungsaufwand aufgrund der automatischen Updates und des Betriebs der Master-Nodes durch den Provider drastisch. Das einzige, was von dem Prozess übrig bleibt, ist die Sicherheitskonfiguration der Umgebung.

In beiden Fällen hat man immer noch Zugriff auf die Server VM-Instanzen, auch wenn man einen Cloud-Service verwendet, da die Server als ganz normale virtuelle Maschinen bereitgestellt werden. Aber nachdem das Cluster eingerichtet ist, kann man nach Belieben Server zum Cluster hinzufügen und das Bereitstellen geschieht automatisch. In der On-Premise Variante kommt man um den normalen Verwaltungsprozess nicht herum.

Also hat man bei einem verwalteten Kubernetes-Service zwar immer noch Server aus denen der Cluster besteht und man verwaltet lediglich, wie stark automatisiert es skaliert, aber die Server muss man nicht direkt verwalten.

Somit sind wir schon ein wenig weiter mit unserer Erwartung an eine Serverless-Infrastruktur: Der Entwickler sieht den Server nicht mehr und man muss ihn auch nicht mehr verwalten.

Weg mit der Zuständigkeit

Aber können wir noch ein Stück weiter gehen und Server komplett aus unserer Zuständigkeit entfernen?

Ja, das können wir! Da jedoch das Rechnen ohne Computer / Server nicht möglich ist, ist dies nur durch Dienste möglich, bei denen die untergeordneten Rechenressourcen von jemand anderem verwaltet werden und entsprechend abstrahiert sind.

AWS bietet derzeit den Fargate-Service an, mit dem Sie Docker-Container ausführen können, ohne Compute-Instances (EC2) bereitzustellen, auf denen die Container ausgeführt werden. Dies bedeutet, dass Sie Ihre Docker-Container ausführen können, ohne jemals einen Server zu sehen oder zu verwalten. Es besteht auch die Möglichkeit, dass AWS in Kürze eine Option anbietet, dass EKS-Cluster von Fargate unterstützt werden (https://github.com/aws/containers-roadmap/issues/32). Dies würde bedeuten, dass auch Server (EC2-Instanzen) aus Ihrem EKS-Cluster wegfallen.

Eine andere Möglichkeit, die Server, die Sie mit Rechenleistung versorgen, vollständig loszuwerden, ist FaaS. AWS bietet den Dienst AWS Lambda an, in dem die Anwendung nur dann ausgeführt wird, wenn sie tatsächlich gebraucht wird. Der Service wird ausgeführt, wenn er ausgelöst wird. Wie eine Funktion ausgelöst werden kann, hängt von dem von Ihnen ausgewählten Cloud-Anbieter ab, da diese alle unterschiedliche Funktionsumfänge in diesem Bereich haben. Die Verwendung des systemeigenen Dienstes der Plattform für Nachrichtenwarteschlangen und HTTPs funktioniert mit allen Anbietern. FaaS führt Ihre Anwendung auch in einem Container aus – dies ist möglicherweise nicht direkt ersichtlich, wenn Sie die Dienste verwenden, da Sie kein Container-Image bereitstellen. Ihre Anwendung wird jedoch in einem Container ausgeführt, um sie zu isolieren. GCP bietet außerdem auch einen Dienst „Cloud Run“ an, welcher zwar Docker Container unterstützt aber aktuell nur über einen HTTPS Aufruf getriggert werden kann.

 

Fazit

Sie können nur dann wirklich „serverlos“ werden, wenn Sie Managed-Services von Cloud-Providern wie z.B. AWS verwenden, welche die Interaktion mit den Servern so weit abstrahieren, dass Sie diese nicht mehr direkt verwalten müssen.

Das bedeutet in der Regel, dass die Architektur einer Anwendung entsprechend ausgelegt werden muss. Ja, das macht zunächst ein wenig Arbeit, aber die gesparten Kosten sowohl bei der Administration der Anwendung als auch beim Betrieb in der Cloud machen sich erfahrungsgemäß recht schnell bezahlt.


Gerne beraten Sie unsere Spezialisten zum Thema Serverless mit AWS und unterstützen Sie bei Ihren IoT-Projekten.

Nehmen Sie Kontakt mit uns auf:

zum Kontaktformular


 


Auf der diesjährigen SPS 2019 vom 26. bis 28. November in Nürnberg präsentiert SIC! Software als Mitglied des MICA.networks auf dem HARTING Stand (Nr. 140) in Halle 10 Softwarelösungen für IoT und Industrie 4.0 mit dem Edge Computing System MICA. Die Messebesucher der SPS erfahren bei uns, welche konkreten Mehrwerte IoT-Anwendungen bieten, indem sie einerseits bestehende Prozesse verbessern und andererseits auch völlig neue Geschäftsbereiche eröffnen können. Auf dem HARTING Messestand zeigen wir in der MICA.network Partner Area an Beispielen auf, wie ein IoT-Projekt vom ersten Schritt bis zur ganzheitlichen Lösung aussehen kann.

Mit einem aufgestellten Ventilator der Rosenberg GmbH wird als Basis für die Optimierung des Energie-Managements die Überwachung von Stromverbräuchen demonstriert.

Außerdem wird die Leistungsfähigkeit einer Bilderkennung mittels AWS Machine Learning-Komponenten gezeigt.

Als einzigartiges Highlight bietet SIC! Software kostenfreie IoT-Mini-Workshops mit unseren Spezialisten direkt auf dem Messestand an. Mit Hilfe von Design Thinking-Methoden können hier erste Ideen, Anforderungen oder Fragestellungen hinsichtlich des Prozesses, der involvierten Systeme und der Akteure visualisiert werden. Interessenten erhalten somit eine fundierte Basis für die weitere Beurteilung und Bewertung.

Sie haben noch keine Eintrittskarte?
Sichern Sie sich Ihr kostenloses Ticket für die SPS 2019 und vereinbaren Sie einen Termin vor Ort:
Ihr Ansprechpartner: Bernd Potyka – Tel. 07131 13355-55 – E-Mail: bernd.potyka@sic.software 


 

Wenn die ersten Konzeptstudien eines IoT-Projektes das Entwicklungslabor verlassen und mit der industriellen Realität konfrontiert werden, geraten die vielfach eingesetzten populären Bastel-Platinen-Rechner wie Raspberry PI oder Beaglebone beim Einsatz als Edge Computing Device schnell an ihre Grenzen. Dann ist eine leistungsfähige, professionelle Hardwareplattform erforderlich.

Hier hat sich in unserem Hause in vielen IoT-Projekten im Industrieumfeld die HARTING MICA® (Modular Industry Computing Architecture) als kleines, leistungsfähiges Edge-Computing System überaus bewährt.

Der gesamte mechanische Aufbau ist sehr robust gestaltet. Egal ob Staub, Öl-Nebel oder feine Eisenspäne aus dem CNC-Bohrwerk – die MICA® Box erfüllt die Schutzklasse IP67 und lässt sich davon nicht beeindrucken. Ebenso genügen die an der MICA® Box verbauten Steckverbinder höchsten Ansprüchen an Lebensdauer und Kontaktsicherheit. Damit ist die MICA® Box ohne Einschränkungen industrietauglich.

HARTING MICA als IoT Edge Computing Device 01

Dem interessierten Leser möchten wir deshalb hier einen Einblick in das Innenleben dieses Edge-Computing Devices geben.

Merkmale der MICA® BOX

Zunächst ist die Harting MICA® BOX eine sehr unscheinbare kleine Box aus Aluminium die nach IP67 geprüft ist. Die Hardware des Systems ist mit einem 1 GHz ARM-Prozessor, 1 GB RAM und 4 GB eMMC Speicher ausgestattet. Zudem kann das System um bis zu weitere 32 GB Flash über eine Micro-SD-Karte nachgerüstet werden.

Als Betriebssystem kommt ein virtualisiertes, auf dem Kernel 3.2.X basierendes, LINUX zum Einsatz. Dies kann mit einer Vielzahl von weiteren Betriebssystem-Komponenten erweitert werden. Zu den Möglichkeiten, die hier auf der Softwareseite beim Einsatz als Edge Computing Device bestehen, folgt in Kürze ein weiterer Blog-Artikel.

Das Gehäuse

Die MICA® Box besitzt ein robustes Alu-Druckgussgehäuse aus einer Aluminum-Slilizium-Magnesium-Legierung (AlSi10Mg). Das gibt dem Gehäuse eine hohe mechanische Stabilität, gute thermische Eigenschaften als passiver Kühlkörper und ein geringes Gewicht.

Das mechanische Konzept der MICA® erlaubt die flexible, modulare Konfiguration mit verschiedenen Schnittstellen. Dabei ist stets die Schutzklasse IP67 erfüllt und die MICA® kann in einem Temperaturbereich von -25 Grad Celsius bis +75 Grad Celsius im Dauerbetrieb eingesetzt werden.

Die Rückwand der MICA® Box ist mit einer Gummidichtung versehen, ebenso alle Bohrungen und Durchlässe für Steckverbinder, LED usw.

Nach dem Entfernen der Schrauben kann die Rückwand abgenommen und der Kühlkörper mit den einzelnen Platinen herausgezogen werden.

Die Module der MICA® Box

Es folgt hier der Blick auf das modulare Platinen-Konzept der MICA® Box. Oben in der Mitte die zentrale Prozessor-Platine mit dem SD-Karten Halter. Links die I/O-Platine – in diesem Falle die Version mit zwei USB 2.0 Schnittstellen. Rechts die Stromversorgungs- und Netzwerkplatine mit LAN-POE-Anschluss und Streckverbindern für eine externe 24V Stromversorgung.

Der Prozessor der MICA® Box ist auf der Unterseite der CPU-Platine montiert. Die Kühlung erfolgt passiv über einen groß dimensionierten Alu-Kühlkörper.

Hier der Blick auf die CPU-Platine mit entfernten Schnittstellenmodulen.

Die Verbindung zwischen CPU Platine und den Schnittstellenmodulen erfolgt über einen Kontaktbügel mit leitfähigem Gummi. Damit ist die Verbindung elektrisch sehr sicher und gegen Vibration geschützt.

So entsteht eine kompakte Einheit von Kühlkörper, Platinen und Steckverbindern die in das Gehäuse eingeschoben wird.

Im Inneren des Gehäuses sorgen dann großzügig dimensionierte Auflageflächen für eine formschlüssige Verankerung der Elektronik im Inneren. Gleichzeitig wird der Kontaktbügel mit definierter Kraft auf die Platinen gedrückt und so eine vibrationssichere elektrische Verbindung der einzelnen Module im Inneren der MICA® Box garantiert.

Es ist dieser intelligente mechanische Aufbau, dem die Harting MICA® Box ihre Widerstandskraft im industriellen Umfeld verdankt.

Hier zum Schluß noch ein Blick auf alle Bauteile einer MICA® Box.

Zusammenfassung

Mit der Harting MICA® Box steht ein Edge-Computing Device mit einer sehr hohen Fertigungsqualität „Made in Germany“ zur Verfügung. Die längerfristige Verfügbarkeit ist durch die Firma HARTING garantiert.


Sie haben eine prototypische IoT Anwendung lauffähig und wollen diese jetzt im Feld erproben?

Sie wollen Sicherheit, dass Ihr wertvolles IoT-Projekt nicht wegen unzulänglicher Edge-Computing Hardware verzögert wird oder gar scheitert?

Dann sprechen Sie uns an.

Gemeinsam mit unseren IoT-Experten finden wir sicherlich einen Weg, Ihr bestehendes IoT-Pilotprojekt von simpler Labor-Hardware wie dem Raspberry Pi auf eine industrietaugliche Edge Computing Plattform wie die HARTING MICA® Box zu heben.

Herausforderungen bei IoT- und Smart Products Projekten

Heutzutage ist Embedded Software Entwicklung nicht mehr vergleichbar mit dem, was noch vor 10 Jahren Stand der Technik war. Die IoT-Produkte werden immer komplexer und die IoT-Hardware immer leistungsfähiger. Steigende Komplexität beim Embedded Software Design führt aber aber zwangsweise auch zu einer höheren Fehleranfälligkeit.

Gerade bei Smart Products ist aber die Robustheit des Embedded Software Designs ein ganz entscheidendes Kriterium. Denn die IoT-Devices müssen häufig über sehr lange Zeiträume laufen, haben aber kein User Interface, um das Gerät neu zu starten, wenn es mal hängt.

Mit klassischen Software-Entwicklungs-Methoden lässt sich aber die Komplexität bei der Entwicklung eines robusten Embedded Software Designs kaum mehr beherrschen. Zahlreiche von uns durchgeführte Code-Review-Projekte zeigen das immer wieder schmerzlich aufs Neue.

Doch wie erreicht man nun einen anderen Level bei der Embedded Software Entwicklung für Smart Products mit einem Real Time OS wie z.B. RTOS oder ThreadX?

 

Quality by Design: Das Standard Finite State Machine Framework

Das Zauberwort heißt hier: Event Driven Architecture. Durch den Einsatz eines Standard Finite State Machine Framework (http://www.state-machine.com/) erreicht man einen neuen Level an Stabilität und Robustheit im Embedded Software Design. Dabei geht die Architektur weg von klassischen Thread-Syncronisations-Methoden hin zu Event gesteuerten Programmabläufen.

Dieses Schaubild verdeutlich diesen Paradigmenwechsel sehr gut:

Embedded Software Design Paradigm Shift

http://embedded-computing.com/eletter-products/asynchronous-event-driven-architecture-for-high-reliability-systems/

Doch warum ist nun eine Event Driven Architecture so viel besser als „klassische“ Embedded Software Entwicklungs-Methoden?

Dafür gibt es zwei Gründe:

 1. Threads

Threads sind eine große Hilfe bei der Entwicklung komplexer Embedded Software. Allerdings gestaltet sich die Synchronisation und Kommunikation schwierig und erfordert vom Entwickler ein sehr hohes Maß and Disziplin, Erfahrung und Überblick über den Code. Mit wachsender Komplexität der Anwendung wird das Thread Handling aber immer anfälliger für Fehler. Die üblichen damit einhergehenden Probleme sind Race Conditions, Deadlocks, Performance Probleme, usw. Fehler in diesem Bereich sind in der Regel auch am schwersten zu finden und zu reproduzieren.

Um diese Probleme beim Embedded Software Design zu adressieren, hat man entsprechende Regeln für die Software Entwickler erdacht.

Siehe: https://herbsutter.com/2010/07/12/effective-concurrency-prefer-using-active-objects-instead-of-naked-threads/


  1. Don’t block inside your code. Instead communicate among threads asynchronously via event objects → This makes threads run truly independently, without blocking on each other
  2. Don’t share any data or resources among threads. Keep data and resources encapsulated inside threads (“share-nothing” principle) and instead use events to share information
  3. Organize your threads as “message pumps” (event queue + event loop)

Wenn man es schafft, diese Regeln konsequent umzusetzen, erhält man entsprechend robusten Embedded Software Code. Die Erfahrung zeigt aber, dass Menschen immer wieder Fehler machen bzw. sich aufgrund von Komplexität Fehler einschleichen.

Die Lösung:
Durch den Einsatz des Standard Finite State Machine Framework erzwinge ich die Einhaltung der oben genannten Regeln einfach durch eine Umkehr der Kontrolle. Das Framework sorgt mit dem Design dafür, dass die Spielregeln bei der Embedded Software Entwicklung eingehalten werden und ich kann als Entwickler keine solchen Fehler mehr einbauen.

 2. Spaghetti Code

In der Regel fängt alles immer ganz harmlos an und der Entwickler schreibt eine Methode, um Events zu verarbeiten. Mit der Zeit kommen jedoch immer mehr neue Events und immer komplexere Bedingungen hinzu. Die if-then-else Statements werden mehr und mehr und immer verschachtelter – bis zu dem Punkt, dass ein Außenstehender nicht mehr versteht, was eigentlich passiert. Dieses Problem lässt sich dann durch entsprechendes Refactoring zwar wieder eindämmen – besser wäre es aber, wenn es erst gar nicht entstehen kann.

Die Lösung:
Auch dafür sorgt das Standard Finite State Machine Framework, weil hier gänzlich anders an die Problemstellung heran gegangen werden muss. Das führt nachweislich zu besseren Ergebnissen bei der Entwicklung eines robusten Embedded Software Designs. Eine sehr schöne Beschreibung (englisch) gibt es hier:
https://www.state-machine.com/doc/Modern_Programming_Slides.pdf


Wenn auch Sie Probleme mit unzuverlässigem Embedded Software Code haben, sprechen Sie uns an! Unsere Spezialisten prüfen gerne gemeinsam mit Ihnen, wie ein Re-Design Ihrer Lösung aussehen kann. Sie profitieren dabei von unserem speziellen Architektur- und Entwicklungs-Know-how für robustes Embedded Software Design und der langjährigen Erfahrung aus zahlreichen IoT- und Smart Products Projekten.

Auch für die Entwicklung neuer Smart Products und in neuen IoT-Projekten hat sich diese Vorgehensweise mit dem Standard Finite State Machine Framework als sehr erfolgversprechend gezeigt.


Vielleicht auch interessant:

Das MQTT Protokoll – Hintergründe (Teil 1)

Das MQTT Protokoll – Praxis (Teil 2)

IoT Protokolle – MQTT vs. AMQP

MQTT Protokoll – Anwendungsbeispiele

Modbus über MQTT – wie geht das?

 

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.


In einer kürzlich veröffentlichten Studie des IT-Dienstleisters HCL Technologies nannten 46 Prozent der befragten Projektverantwortlichen die Nutzung der richtigen IoT-Plattform als eine der größten Herausforderungen für das IoT-Projekt des Unternehmens.

Typischer Weise werden dabei die folgenden Anforderungen an die IoT-Plattform gestellt:

  • Quantitative Skalierbarkeit
  • Automatisierbarkeit
  • Offenheit, Schnittstellen
  • Technologische Reife der Plattform

Nun versucht das Unternehmen mit den bekannten Methodiken umfassend zu planen und so durch die Auswahl der „perfekten“ IoT-Plattform sein Projekt zum Erfolg zu führen.
Aber: Eine Digitalisierung nach Fahrplan gibt es nicht. Die Evaluation von IoT-Plattformen ist daher vielfach nur eine unnötige Geld- und Zeitverschwendung!

Warum ist das so? Weil eine Entscheidung pro oder Contra einer Plattform oftmals nur an kleinen technischen Detailfragen festgemacht wird, die zudem immer nur auf Basis des jeweils aktuellen Wissenstandes im Projekt erfolgen kann. Bei IoT-Projekten wird aber fast immer Neuland betreten. Die Anforderungen, Zielsetzungen, Use-Cases und Prioritäten ändern sich sehr schnell. Diese Änderungen sind aber unmöglich vorhersehbar. Alle Versuche, die möglichen Szenarien bei der Planung in Summe zu berücksichtigen, führen entweder zu einem Projekt mit gigantischen Kosten oder aber zu einer sehr langwierigen Planungsphase, die am Ende den Projektfortschritt sehr stark verlangsamt.

Unsere Empfehlung lautet daher:

Wählen Sie eine große, flexible Cloud-Plattform und fangen Sie einfach an. Denn während Ihr Wettbewerber noch überlegt, welche IoT-Plattform er nehmen soll, haben Sie schon den ersten Prof-of-Concept am Start und können echte Erfahrungen im Feld sammeln. Bei Umsetzung von IoT-Projekten lassen sich zwar viele technische Aufgaben im Zweifelsfall durch erhöhten Ressourceneinsatz beschleunigen, nicht aber das Sammeln von Erfahrungen im Feld! Wer hier zuerst kommt, mahlt zuerst und kann sich schnell einen Wettbewerbsvorteil sichern, der von der Konkurrenz nur schwer wieder aufgeholt werden kann.

Was ist wirklich wichtig bei der Plattformauswahl?

Über die Jahre haben sich folgende Parameter als wirklich strategisch relevant erwiesen:

  • Größe des Cloud-Anbieters
  • Flexibilität der Architektur und Ihrer Komponenten
  • schnelle Release-Zyklen der Cloud-Dienste

Warum eine große Plattform? Weil dieser Anbieter vermutlich auch in 24 Monaten noch existiert. Weil nur die großen Anbieter genügend in die kontinuierliche technologische Weiterentwicklung investieren können.

Warum Flexibilität? Weil nur damit die Chance besteht, dass auch Ihre künftigen Anforderungen erfüllt werden – und dies sowohl in technologischer als auch in funktionaler Hinsicht. Gerade der mögliche Einsatz verschiedener Technologien im Rahmen einer Microsystemarchitektur erleichtert und beschleunigt die Integration vorhandener Systeme ganz enorm.

Warum schnelle Release-Zyklen? Weil nur so die Chance besteht, dass in den verwendeten Cloud-Diensten die unvermeidlichen Kinderkrankheiten und Fehler schnell verschwinden, fehlende Funktionen in endlicher Zeit ergänzt werden.

Wenn Ihnen also ein Beratungsunternehmen als Einstieg in Ihr IoT-Projekt eine Studie für den Vergleich von 60 IoT-Plattformen empfiehlt, schicken Sie es nach Hause. Das Geld können Sie sinnvoller einsetzen.


Erwecken Sie Ihre Digitalisierungs-Idee zum Leben und präsentieren Sie sie LIVE vor Management, Kollegen und Kunden: IoT-Showcase-Angebot  


Warum hat sich SIC! Software bei IoT-Projekten auf die Cloud-Dienste von AWS fokussiert?

Die Gründe für AWS sind ganz einfach:

  • Großer internationaler Anbieter, der nicht vom Markt verschwinden wird
  • Transparentes Preismodell
  • Ausgereifte Infrastruktur, rationelle Administrationsmöglichkeiten
  • sehr breites Spektrum unterstützter Programmiersprachen
  • Kein erzwungener Technologischer Lock-In
  • Stabile SDKs und Bibliotheken, umfassende Dokumentation
  • Schnelle Release-Frequenz der Dienste
  • Breites MicroService Portfolio
  • Weltweite Hoch-Verfügbarkeit

Weil es sich bei Technologie-Integratoren wie bei einem 5-Sterne-Restaurant verhält: Wenn die Speisekarte zu groß ist, leidet die Qualität! Viel wichtiger ist die Kenntnis wie man mit den Zutaten das optimale Ergebnis erreicht. Daher gibt es in den Top-Gourment-Restaurants nur ein Menü auf der Speisekarte – genauso wie sich unser Top-Expertenteam auf einen flexiblen, leistungsfähigen und zukunftssicheren Technologiebaukasten fokussiert.


Wenn Sie lernen möchten, mit welchen Methodiken man die für die eigene IoT Anwendung strategisch relevanten Schlüsselkomponenten identifiziert, um die Kontrolle über seine Daten zu 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


Weitere Teile dieser Blog-Artikel Serie:

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

IoT Projekt-Know-how für Entscheider – Teil 2: Warum sollen wir jetzt IoT Projekte starten?

IoT Projekt-Know-how für Entscheider – Teil 3: Warum sollen wir in eine eigene IoT Anwendung investieren?


Ü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 

 


 

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.


„Es gibt doch jede Menge „fertiger“ IoT-Lösungen in der Cloud, an die wir ganz einfach unsere Maschinen anschließen können.“

Die Antwort hier ist ganz einfach: Damit klar ist, wem die von Ihren Maschinen und Sensoren erzeugten Daten gehören, ist eine eigene IoT Anwendung die bessere Lösung!

Alle Arten von Daten sind das Gold des 21 Jahrhunderts. Viele „öffentliche“ IoT Dienste vereinnahmen jedoch diese Daten und verkaufen die daraus gewonnenen Erkenntnisse an jedermann – möglicherweise sogar an Ihre direkte Konkurrenz.

„Aber die Vernetzung im IoT Umfeld lebt doch von der Weitergabe von Daten?“

Ja natürlich, eine IoT-Lösung ist ohne die Weitergabe von Daten in der Regel nur von sehr beschränktem Nutzen. Unabhängig davon ist es aber unverzichtbar, dass Sie es selbst kontrollieren können, wer Zugriff auf Ihre Daten erhält und wer nicht, wer die Daten auswerten und daraus lernen kann und wer nicht!

Diese strategisch relevante Kontrolle über Ihre Daten können Sie nur dann sicherstellen, wenn Sie an den Schlüsselstellen in der IoT-Datenschöpfungskette eigene IoT-Anwendungen / -Lösungen/ -Apps implementieren, die zu 100% unter Ihrer Kontrolle stehen.

Nur wenn Sie wissen, an welchen Stellen welche Daten entstehen, was man daraus an Erkenntnisse gewinnen kann ist können Sie „verstehen“ was Ihre Kunden an Daten brauchen. Das wiederum ermöglich es Ihnen, Ihr Produkt mit mehr Kundennutzen zu versehen – und am Ende möglicherweise auch neue Geschäftsmodelle für Ihr Unternehmen zu entwickeln.


Warum wir als Basis für Ihre eigene IoT-Anwendung Amazon Web Services (AWS) Cloud empfehlen, erfahren  Sie hier


Der schnelle Einsatz einer bestehenden IoT-Plattform statt des Aufwands einer eigenen IoT Anwendung ist natürlich sehr verlockend. Für nur ganz wenig Geld können Sie Ihre „intelligenten Maschinen“ auf diese Art und Weise ins Internet bringen. Und für einen ersten Showcase kann dies unter Umständen auch ein sinnvoller Weg sein. Wer aber strategisch und längerfristig denkt, der sollte hier sorgfältig prüfen, welche Konsequenzen solch eine Entscheidung haben kann.

Wenn Sie lernen möchten, mit welchen Methodiken man die für die eigene IoT Anwendung strategisch relevanten Schlüsselkomponenten identifiziert, um die Kontrolle über seine Daten zu 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


Weitere Teile dieser Blog-Artikel Serie:

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

IoT Projekt-Know-how für Entscheider – Teil 2: Warum sollen wir jetzt IoT Projekte starten?


Ü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 

 


 

 

 

 

 

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.