In unseren Kundenprojekten wird von unseren UX Design Spezialisten regelmäßig ein sehr hilfreiches und nützliches Tool eingesetzt: Das „User Story Mapping“. Hierbei handelt es sich um eine von Jeff Patton entwickelte Methode, mit der im Rahmen von agiler Produktentwicklung eine stimmige User Experience geschaffen wird. So lässt sich der Erfolg für die auf diese Weise realisierten digitalen Produkte maximieren.

Beim User Story Mapping wird der Arbeitsfluss des Users, also des Produktnutzers, in einzelne „User Stories“ unterteilt und mit Hilfe von Klebezetteln auf einer Wand in Form einer Art Karte („Map“) visualisiert. Die Flexibilität der Klebezettel ermöglicht eine schnelle und einfache Optimierung der Prozesse bzw. des Produktes durch Umsortieren, Aufteilen, Ergänzen, Erweitern, Vertiefen, usw. An einer User Story Mapping Session nehmen idealerweise alle am Produkt Beteiligten – vom Auftraggeber über den Designer bis zum Entwickler – teil und erarbeiten einen Konsens. Durch das bessere gemeinsame Gesamtverständnis vom Produkt, seinen Eigenschaften und seiner Anwendung wird die Gefahr reduziert, sich in unwichtigen Details zu verzetteln oder das Produkt an den Bedürfnissen des Produktnutzers vorbei zu entwickeln.

Mit User Story Mapping wird ein Produkt mit genau jenen Features entwickelt, die für den Anwender wirklich nützlich und dabei auch noch realisierbar und bezahlbar sind. Dabei können mehrere aufeinanderfolgende Release-Stufen festgelegt werden – angefangen vom „Minimum Viable Product (MVP)“ über Zwischenversionen bis zur finalen Version mit dem kompletten Feature-Set. Die in der ersten Session erstellte User Story Map bildet gleichzeitig eine Basis für das Projektmanagement. Im Verlauf des Projekts kann und soll die Story Map im Rahmen einer agilen Produktentwicklung in weiteren Sessions anhand von User Feedback, Tests und Erfahrungen dann permanent weiter optimiert werden.

Entsprechend einem vielfach von unseren Kunden geäußerten Wunsch nach einer kompakten Übersicht und Kurzanleitung zum User Story Mapping haben unsere Grafiker eine Infografik mit dem Titel „Innovationsentwicklung mit User Story Mapping“ erstellt, die wir hiermit gerne allen an der Methode Interessierten zur Verfügung stellen. zur Infografik

vorschau-infografik-user-story-mapping

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

Zahlreiche Workshops zum Thema Vertriebssoftware bei unseren Kunden ergeben immer das gleiche Bild in Sachen CRM. Man hat teure CRM-Systeme angeschafft, aber die tatsächlich erzielten Erfolge bleiben weit hinter den Erwartungen zurück. Warum ist das so?

Gruppe mit Tablet

Hier unsere Erfahrungen:

Weiterlesen