Wie erklärt man Idempotenz ?

"Man bezeichnet ein Element einer Menge (also auch eine Funktion), das mit sich selbst verknüpft wieder sich selbst ergibt, als idempotent." (wikipedia). Dass es sich hierbei um eine der zentralen Anforderungen bei der Programmierung verteilter Systeme handelt, und dass das ganz erhebliche Auswirkungen auf Architektur und Entwurf solcher Systeme hat, ist (nach meiner Erfahrung) für Studenten nicht grade leicht verständlich.

Um das anschaulicher zu machen, habe ich eine "Lampe" gebaut:

Dazu gibt es einen Schalter, genauer gesagt einen Taster

Bei jedem Druck auf den Taster (ganz klein, rechts an der Platine) ändert sich der Zustand der Lampe: Ist sie aus, dann geht sie an, ist sie an, dann geht sie aus.

Soweit ganz einfach. Der Taster sendet eine Nachricht ("wurde gedrückt") an den Empfänger, der schaltet entsprechend hin und her. Kompliziert wird das dadurch, dass die Übertragung über Funk erfolgt. Die Übertragung ist deshalb nicht verläßlich. Insbesondere haben die Module nur eine beschränkte Reichweite. Vergrössert man den Abstand weit genug, gehen Nachrichten verloren.

Steht die Lampe in einem Raum und der Schalter in einem anderen, weiss man nach dem Drücken der Taste nicht mehr sicher, ob die Nachricht angekommen, die Lampe also an oder aus ist. Dies wäre nur der Fall, wenn jede Nachricht genau einmal zugestellt würde ("exactly once").

Das ist aber nicht realisierbar: Ein Ansatz wäre, dass der Empfänger eine Bestätigung schickt, wenn er die Nachricht erhält. Kommt diese beim ursprünglichen Absender an, weiss er, dass die Nachricht erfolgreich zugestellt wurde und damit, ob das Licht jetzt an oder aus ist. Er kennt also den Zustand der Lampe ("shared state", beide sind sich einig darüber, ob die Lampe brennt oder nicht).

Aber was passiert, wenn die Bestätigung nicht ankommt ? Wenn die Nachricht tatsächlich nicht angekommen ist, könnte sie ein weiteres Mal gesendet werden. Aber eben das läßt sich nicht feststellen, denn das Ausbleiben der Bestätigung könnte mehrere Ursachen haben: Entweder ist die ursprüngliche Nachricht verloren gegangen, oder die Nachricht ist zwar angekommen, aber der Empfänger ist abgestürzt, bevor er die Bestätigung schicken konnte oder die Bestätigung ist verloren gegangen. Je nachdem, welche Ursache vorliegt, ist die Lampe an oder aus, der Taster (Absender) weiss es nicht.

Wie ließe sich dieses Problem lösen ? Man könnte die Bestätigung bestätigen. Kommt diese an, ist alles OK, aber wenn nicht, gibt es verschiedene Ursachen usw.

So wird das Problem also nicht zufriedenstellend gelöst, da zumindest die letzte Nachricht in einer Kommunikation nicht verlässlich übertragen werden kann. Deshalb kann man nicht vermeiden, dass eine Nachricht gelegentlich entweder verloren geht, oder mehrfach übertragen wird. Es gibt nur "at most once" oder "at least once".

Bestätigungen sind also für diesen Fall nicht geeignet. So wird die Grundannahme, dass mit einem solchen Protokoll (wie es etwa TCP realisiert) eine verläßliche Übertragung von Nachrichten, die den Zustand ändern, möglich ist, erschüttert. Doch wie löst man das jetzt ?

Man betrachtet den Eingang einer Bestätigung nicht als verläßliche Bestätigung, sondern schickt eine Nachricht, falls nicht innerhalb einer bestimmten Zeitspanne eine Bestätigung eintrifft, einfach nochmal ("at least once"). Oder man überträgt gleich die Nachricht immer wieder. Dazu braucht man natürlich andere Nachrichten, mit unserem Beispiel würde die Lampe ständig an und aus geschaltet werden.

Man muss die Anwendung so konstruieren, dass kein Schaden entsteht, wenn eine Nachricht mehrfach empfangen wird. Das ist Idempotenz.

Im Bild sieht man einen Schalter, der zwei Zustände hat (an und aus) und den aktiven Zustand immer wieder (im Beispiel alle 200 Millisekunden) überträgt. Diese Nachricht (entweder "An" oder "Aus") kann beliebig oft übertragen werden, der Empfänger ist, sobald er mindestens eine (aktuelle) Nachricht erhält, im richtigen Zustand. Ist die Lampe an, und es wird nochmal "An" empfangen, passiert nichts (unerwünschtes).


Nächste Woche werde ich das in der Vorlesung ausprobieren, mal schauen, ob dieses Konzept so besser verständlich ist.

Realisiert wurde das System mit ZigBee zur Übertragung, hierfür wurden XBee-Module der Firma Digi verwendet. Das würde natürlich auch mit anderen Übertragungstechniken funktionieren, aber diese Module sind sehr bequem zu verwenden, die Funktionen, die man hier braucht, sind schon eingebaut: Im einen Fall wird der Zustand eines digitalen Eingangs bei jeder Änderung übertragen, im anderen Fall werden die Eingänge in einem festen Zeitintervall abgetastet und übertragen.

Für den Empfänger bräuchte man an sich nur ein bisschen Logik (im Taster-Betrieb ein Flip-Flop, das den aktuellen Zustand speichert und eine Erkennung mit entsprechender Logik, die erkennt, welche Betriebsart grade vorliegt, das wird durch einen weiteren Eingang mit entsprechend fixem Wert festgelegt). Das liesse sich leicht diskret ohne Controller realisieren, wenn nicht ... die XBee-Module mit 3.3 Volt arbeiten würden ... Man bräuchte also auch noch Level-Shifter. Und da ich den Arduino grade rumliegen hatte ....

Reichweitentest der ZigBee Module

Da zunächst nicht ganz klar war, wie die Reichweite der Sensoren innerhalb einer (im wesentlichen aus Metall bestehenden) Papiermaschine sein würde, war der erste Vorversuch ein simpler Ausleuchtungs-/ Reichweitentest. In der Abbildung sind einige der Messpositionen gezeigt. Zunächst wurden normale XBee-Module mit Drahtantennen verwendet (ein Unterschied zu Chipantennen war nicht erkennbar). Es wurde eine Reihe von Messungen über einen Zeitraum von mehreren Minuten ausgeführt, angegeben sind jeweils Mittelwerte. Die Werte sollten nur als Anhaltspunkt angesehen werden, eine exakte Messung müsste systematischer ausgeführt werden. Da das Ziel aber nicht eine genaue Ausleuchtungsmessung dieser einen Maschine war, sondern es darum ging, eine Idee von den im Allgemeinen erzielbaren Reichweiten zu erhalten, reicht diese grobe Art der Messung hier aus.


Von Messposition 1 aus wurde zuerst die Dämpfung horizontal in Maschinenrichtung erfasst (Position 2 – FS). Im Anschluss wurde von Messposition 1 aus die Dämpfung zu Position 3 (TS) erfasst. Dies entspricht nahezu der maximalen Distanz innerhalb der Trockenpartie diagonal durch die Sektion. Hier wurde eine Signaldämpfung von -20 bis -25 dB ermittelt --> kein Problem. Als zweites Datenset wurde die Dämpfung im Übergang von innerhalb der Trockenpartie nach aussen erfasst. Dazu wurde auf Höhe der Messposition 1 auf TS der Empfänger ausserhalb der Trockenpartie (auf PM Boden) platziert. Der Sender wurde – zunächst bei geöffneten Haubentüren – auf Messposition 3 positioniert. Danach wurden die Haubentüren (TS) nacheinander geschlossen um Auswirkungen auf die Dämpfung zu erkennen. Hier wurde eine Dämpfung von etwa -35 (Haubentüren offen) bis -55 dB ermittelt, das ist an der Grenze einer verläßlichen Datenübertragung.Als letztes wurde noch die Dämpfung mit stärkeren Modulen (XBEE Pro) und Stabanttennen vom Haubeninneren bis in die Warte geprüft. Anfangspunkt war die Positionierung des Senders in Position 2 und des Empfängers im nächstgelegenen Wartenraum. Im Anschluss wurde die Dämpfung erfasst, wenn die Distanz erhöht wird. Dazu wurde der Sender auf Position 1 platziert. Hier wurde eine Dämpfung von -25 bzw. -35 dB gemessen.Insgesamt sind die Ergebnisse sehr ermutigend. Im Gegensatz zu den Erwartungen reduziert die metallische Umgebung das Signal wesentlich weniger als beispielsweise Stahlbetonkonstruktionen. Es kann eindeutig gefolgert werden, dass sich der Sender mit geringer Sendeleistung für den Einsatz eignet. Somit können die Ziele Kompaktheit des Sensors, Einzelkosten, Einsatzdauer voraussichtlich mit reduziertem Aufwand erreicht werden.

In der Papiermaschine ...

ist dann doch alles etwas anders aus. Schmutziger zum Beispiel ;-) Lauter, heißer und vor allem viel mehr Metall um einen rum ...

Um zu testen, wie sich die XBee-Module in dieser Umgebung verhalten, haben wir eine einfache Reichweitenmessung (letztlich fast nichts anders als der Reichweitentest der von Digi gelieferten Software) durchgeführt: Ein Sensormodul (ein Standard-Xbee mit einem simplen Temperatursensor) sendet Daten an eine Basisstation, dort wird die Signalstärke (RSSI) ausgewertet:

Man erkennt das lose rumhängende XBee-Modul am USB-Kabel ... aber es ist ja schließlich nur der erste Versuch, der klären soll, ob sich weiterer Aufwand überhaupt lohnt: Wenn die Reichweite nur ein paar Meter beträgt, wird das Projekt umgehend wieder eingestampft.

Aber damit nicht alles "frei verdrahtet" aussieht, haben wir wenigstens den Sensor in ein Kästchen eingebaut:

Der hat inzwischen einen Ehrenplatz auf meinem Schreibtisch ;-)

Architektur des Sensornetzes

Die einzelnen Sensoren kommunizieren über ZigBee, verwendet werden Module der Firma Digi. ZigBee hat hier zwei entscheidende Vorteile gegenüber WLAN:

Erstens handelt es sich um ein Mesh-Netz, dessen Routing-Topologie sich nach Bedarf anpasst. Dies ist wichtig, da die Sensoren in verschiedenen Umgebungen eingesetzt werden, deren Funkabdeckung wechseln kann. Die Umgebung ist hier besonders kritisch zu sehen, da der zunächst geplante Einsatzort die Trockenpartie einer Papiermaschine ist, im wesentlichen eine sehr große Menge von Stahl, der von einer praktisch dichten Aluminiumhaube umgeben ist. Kann ein einzelner Sensor die Basisstation nicht erreichen, ist dies kein Problem, andere Sensoren können die Daten weiterleiten. Ist also etwa ein Sensor nicht zu erreichen, wird einfach zwischen diesen und den letzten erreichbaren ein weiterer Sensorknoten installiert. Da die Sensoren batteriebetrieben sind, ist dies praktisch kein Aufwand.

Zweitens kann mit ZigBee vergleichsweise leicht ein geringer Stromberbrauch realisiert werden. Die meiste Zeit sind die Module im Ruhezustand und werden nur gelegentlich zur Datenübertragung aufgeweckt. Für den Stromverbrauch letztlich entscheidend, ist die Minimierung der Dauer des aktiven Zustands.  Man kann zwar mit hoch optimierten Systemen (dazu siehe etwa Benedikt Ostermeier et al, Connecting Things to the Web using Programmable Low-power WiFi Modules, WoT '11 Proceedings of the Second International Workshop on Web of Things, Article No. 2, ACM, 2011) durchaus auch mit WLAN eine regelmäßige Datenübertragung bei Batteriebetrieb erreichen, aber ZigBee ist hier bereits "by design" schneller.

Als Sensoren für Temperatur und Luftfeuchtigkeit werden Sensoren vom Typ HYT939 verwendet. Diese bieten eine hohe Genauigkeit bei einfacher Anbindung und einfachem Einbau. Die Vorverarbeitung der Daten erfolgt durch einen Arduino FIO, der von einer LiPo-Batterie versorgt wird.

Die Daten werden von den Sensoren zu einer Basisstation (ein Raspberry Pi mit Funkinterfaces und einem LCD-Display) übertragen, die diese lokal speichert und eine grobe Auswertung zur Zustandsdiagnose durchführt. Diese Basisstation bietet ein WLAN-Interface, um Anzeigegeräte anzubinden. Die Darstellung der Daten erfolgt auf einem Smartphone oder Tablet.

Dadurch ist eine ständige Überwachung der Betriebsparameter durch die Maschinführer leicht möglich. In einer späteren Ausbaustufe sollen die Daten per UMTS-Modem direkt zur Erstellung von Analysen bereitgestellt werden.