Freitag, 17. Januar 2014

Warum Thermostaten interessant sind ....

oder: Warum gibt google mehr als 3 Milliarden Dollar für einen Hersteller von Thermostaten aus ?

Glaubt man etwa der FAZ, dann „scheint [Nest Labs] zwar auf Thermostate und Feuermelder fokussiert zu sein, aber es ist nicht abwegig, dass Google diese Technologie mit der Zeit auf andere Geräte überträgt“, denn „Die Automatisierung von Haushalten ist eine der größten Geschäftsmöglichkeiten, wenn man vom allgegenwärtigen Internet redet, das alles verbinden wird.“

Das klingt ja alles nett, aber die Hausautomatisierung wurde schon vor fünf Jahren als die kommende Technologie gepriesen, die dem Internet der Dinge zum Durchbruch verhelfen würde. Wer erinnert sich noch an den intelligenten Kühlschrank, der automatisch Milch nachbestellt oder Rezepte vorschlägt ?

Blödsinn !

Es geht (google) nicht darum, zu erkennen, ob jemandem der Toast anbrennt, oder welche Lieblingstemperatur der Durchschittsamerikaner im Wohnzimmer hat. Worum es wirklich geht, wird klar, wenn man sich die Daten eines Temperatursensors mal genauer anschaut. Solche Sensoren setzt man etwa im industriellen Umfeld zur Optimierung der Produktionsabläufe ein. Die Abbildung zeigt Daten, die solche Sensoren in meinem Büro über ein paar Tage aufgenommen haben (hier zwei, einer neben meinem Schreibtisch - rot und einer auf dem Besuchertisch - grün). Auf der Zeitachse entsprechen die größeren Striche jeweils einem Tag, die kleineren jeweils 6 Stunden.



Von links nach rechts erkennt man zunächst einen ganz normalen Arbeitstag: Ich komme gegen 8 Uhr ins Büro, die Temperatur steigt schnell an. Im Lauf des Vormittags geht immer mal wieder die Tür auf und zu, kurz vor Mittag gehe ich schnell ein Brötchen holen (die Temperatur fällt kurz ab), dann mache ich die Tür zu, um in Ruhe zu essen (die Temperatur steigt an), dann mache ich wieder auf, falls Studenten zu mir wollen, Temperatur fällt und schwankt dann ein bisschen, wenn jemand vorbeiläuft. Gegen 16 Uhr  ein kurzer Gipfel wegen hektischer Bewegung beim Aufbruch, dann Feierabend: Die Temperatur fällt langsam wieder ab. Gegen 18 Uhr kommt die Putzfrau, kurze Schwankung.

Am nächsten Tag ein interessanteres Bild: Am späten Vormittag bin ich kurz in einer Besprechung, der Temperaturanstieg hat eine leichte "Delle", kurz vor Mittag kriege ich Besuch. Der sitzt am Gästetisch, dort (grüne Kurve) steigt die Temperatur plötzlich an. Danach gehe ich in Ruhe essen, bin gut anderthalb Stunden weg. Gegen 17 Uhr Feierabend, etwas später dann wieder die Putzfrau.

Am Samstag ist niemand da, am Sonntag vormittag komme ich kurz vor neun ins Büro um in Ruhe zu arbeiten. Man sieht (bis auf die kleine Schwankung gegen halb elf, da war ich auf der Toilette) einen ruhigen, ungestörten Vormittag. Gegen Mittag dann Feierabend.

Man sieht: Nichts, was man mit einer Überwachungskamera nicht auch sehen könnte. Aber deren Daten wären viel schwieriger auszuwerten. Und ausserdem wäre eine Kamera zumindest in Deutschland verboten. Aber einen Thermostaten braucht man halt ....

Kombiniert man das mit ein paar anderen Daten (vielleicht noch die Helligkeit, braucht man zur Steuerung der Jalousie, Stromverbrauch) und ein paar Informationen aus dem Internet (welche Website besuche ich grade, wonach suche ich denn so) kann man die Bewegungs- und Kommunikationsdaten, die man aus dem GPS-Empfänger und den Mobilfunk-Verbindungsdaten hat, schön anreichern.

Mit einem Thermostaten kann man den Teil des (Privat-) Lebens untersuchen, den man mit anderen (legalen) Mitteln nicht sieht. Und man sieht schon im Büro ziemlich viel ....


Mittwoch, 15. Januar 2014

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 ....