Mittwoch, 1. Oktober 2014

Ingestion rates


Im September gab es eine (durchaus interessante) Veranstaltung in Stuttgart, die mongoDB IoT european city tour. Thema war, ob (na ja, also natürlich "das") mongodb die ideale Basis für das Internet of Things sei. Dabei ergab sich die Gelegenheit, einen der Chief sonstwas Architects von mongodb zu fragen, warum (zum Geier) man denn eine (dokumentenorientierte) NoSQL-Datenbank braucht, um sehr einfach strukturierte Sensordaten zu speichern. Nach meiner unmassgeblichen Ansicht ist eine relationale Datenbank hier viel besser geeignet.

Die Antwort war: "Ingestion rate" (nach einigem Nachdenken kam dann noch "If you want to annotate your data ...", das ist ein guter Punkt, aber halt nur, wenn man das dann auch in unstrukturierter Form machen will. Und nach noch längerem Nachdenken "Open Source").

Also "Ingestion rate". Das Lieblingswort der NoSQL-Anbieter, wie mir scheint. Solche Aussagen wecken immer ganz schnell meine Neugier. Also habe ich die Zeit vor Semesterstart für einen kleinen Benchmark genutzt.

Das Szenario ist einfach: Eine Anzahl von Sensoren, die Daten liefern, beispielsweise 100 Sensoren, die ein paar Mal pro Sekunde einen Wert (etwa einen Ort oder eine Geschwindigkeit) liefern. Gespeichert wird für jede Messung die Zeit, der Wert, die Art des Werts und die ID des Sensors. Alles ints. Transaktionen brauchen wir hier eigentlich keine, da keine Werte geändert werden. Die einzigen Operationen sind das Anlegen neuer Datensätze und Lesen bereits bestehender.

Zunächst in einer mysql-Datenbank. Ein INSERT pro Wert, MyISAM-Engine. Kein Index. Dann mongoDB. Zunächst auch ein Wert pro insert, dann bulk-insert mit jeweils 1000 Werten. Auch ohne Index. In der Realität werden hier also die Zahlen schlechter (also langsamer) werden, denn ohne Index dauert es viel zu lang, die Daten zu finden.

Wenn man sich mal genauer überlegt, was man in diesem Fall eigentlich braucht, dann kommt man (hoffentlich) früher oder später darauf, dass eine Datenbank eigentlich overkill ist: Eine Zeitreihe kann man leicht in einer (Binär-) Datei speichern. Das Einfügen (also hier ja nur ein Anhängen) geht einfach. Suchen ist etwas schwieriger. Die typischen Abfragen in einem solchen System sind "Gib mir die Werte aus einem bestimmten Zeitintervall", beispielsweise den letzten zehn Sekunden usw.

Wenn hier jeweils die ganze Datei durchsucht werden muss, dann ist das viel zu langsam. Also braucht man einen Index. Da man in der Regel aber sowieso aggregierte Werte haben will, um die Darstellung auf unterschiedlichen Zeitskalen zu beschleunigen, ist das gar nicht so schwierig: Man speichert sowieso nicht nur die Originaldaten, sondern dazu noch Mittelwerte (und ggf. andere Verteilungsparameter) je Sekunde, Minute, Stunde, Tag usw. Wenn man hier jeweils noch die (ungefähre) Position dieses Intervalls in der grossen Datei mit den Originaldaten speichert, hat man eine Art B*-Baum für Zeitreihendaten. Der oberste Knoten sind die Monate(oder Jahre oder wasauchimmer). Auf der nächsten Ebene kommen die Tage, dann die Stunden, dann die Minuten, dann die Sekunden, dann die Daten. Sucht man die Daten für einen bestimmten Zeitpunkt, fängt man oben an, kommt so zum richtigen Tag, dann zur richtigen Stunde, zur Minute, zur Sekunde und schliesslich in die Datei, wo man einen Block oder so liest und die Daten hat. Programmieraufwand so in der Größenordnung von ein paar Tagen.

Das Ergebnis ist beeindruckend: MySQL und mongoDB liegen eher nah beieinander, MySQL etwa doppelt so schnell wie mongoDB. Beide in der Größenordnung (genauer ist das eh nicht, wir wollen ja nur ungefähre Zahlen haben) von 10.000 Datensätzen pro Sekunde.

Die "handgestrickte" Version mit Dateien (hier wurde nur der Index für die Sekunden realisiert, die oberen Ebenen wurden, da für die Performance irrelevant, weggelassen) schafft etwa 2 Millionen Datensätze pro Sekunde, also etwa 200 mal mehr als die Datenbanken !

Interessant ist hier, dass der bulk insert bei mongoDB praktisch keine Verbesserung bringt (bulk inserts scheinen ein schwieriges Thema zu sein, siehe etwa hier und hier).

Wenn man bei den Datenbanken noch Indices verwendet, muss man sehr ausfpassen, dass die Performance nicht in den Keller geht (siehe etwa hier).



Also: Wegen "Ingestion rate" braucht man keine NoSQL-Datenbank !



Üblicherweise kommt dann der Einwand, dass man NoSQL-Datenbanken leichter verteilen kann und so eine bessere Performance erzielen kann. Einen interesasanten Benchmark mit verteilten MySQL-Datenbanken, bei dem 15 Instanzen etwa 1 Million Datensätze pro Sekunde schaffen, gibt's hier.
Die schaffen etwa 150.000 pro Sekunde, was ganz gut zu meinen Messungen passt: Ich habe mein 4 Jahre altes Macbook verwendet, die hatten eine dicke Amazon Instanz. Passt.

Braucht man mehr Performance muss man in jedem Fall verteilen. Das ist dann aber schon ganz schön viel: Nehmen wir mal an, dass ein vernünftiger Rechner mit SSDs den zehnfachen Durchsatz wie mein altes Macbook schafft (das ist eher konservativ), dann wären das immerhin 20 Millionen Datensätze pro Sekunde .... die muss man erstmal haben.

Falls jeder Sensor pro Sekunde einen Datensatz liefert (das sind so übliche Szenarien, etwa auch bei der IoT-Veranstaltung die intelligenten Akkuschrauber von Bosch), dann sind das 20 Millionen Sensoren .....

Aber in der Tat, es gibt Anwendungsfälle, wo man so viele hat (etwa bei TelCos). Dann sind verteilte Dateisysteme notwendig, ein schönes Beispiel mit 100 Millionen Datensätzen pro Sekunde gibt's hier.

Also nochmal: Wegen Ingestion rates braucht man keine NoSQL-Datenbank ! Zumindest in einem IoT-Szenario, bei komplexen Dokumenten mag das wohl sein. Haben wir hier aber nicht ! Nein !

Bleibt also noch das Argument mit der Annotation. Bei Sensordaten kann man hier zwei Grenzfälle sehen: Bei Massendate die Annotation mit Events. Das also aus anderen Quellen stammende oder durch Auswertungen erzeugte Informationen über besondere Ereignisse (etwa die Überschreitung von Grenzwerten oder die Clusterung von Daten) hinzugefügt werden. Das geht mit relationalen Datenbanken natürlich hervorragend. Einfach eine zusätzliche Tabelle angelegt, die per Fremdschlüssel auf die entsprechenden Datensätze verweist.

Der andere Grenzfall wären meistens manuell erstellte, in jedem Fall aber unstrukturierte Daten in unvorhersehbarer Form. Die kann man tatsächlich gut in NoSQL-Datenbanken speichern. Die Frage ist, was bringt das ? Unstrukturierte Daten auszuwerten ist, insbesondere wenn man überhaupt nicht weiss, worum es sich handelt, gar nicht so einfach. Da bleibt eigentlich nur eine Volltextsuche, semantische Textanalyse usw. Das kann man aber auch mit einer relationalen Datenbank gut machen, wenn man diese Annotationen als BLOB speichert.

Bleibt "Open Source". Ist MySQL auch. Zumindest die Community Edition. Wie bei mongoDB auch.

Was bleibt also von den Argumenten übrig ?

Nix.

Den Quellcode der verwendeten Programme gibt's hier.

Mittwoch, 2. Juli 2014

Wie in der guten alten Zeit ...


Von Intel gibt es ganz neu einen sehr schicken - na ja, was eigentlich - sagen wir mal Barebone (heisst NUC - Next Unit of Computing). Der ist wohl eigentlich für Kassensysteme oder Infoterminals gedacht: Sehr niedriger Stromverbrauch, sehr niedrige Rechenleistung, ohne mechanische Teile, also lüfterlos, 4GB Flash intern, VGA-Anschluss und, man höre und staune: eine serielle Schnittstelle.

Also ideal für embedded-Anwendungen wie das NBS. Die ideale Basisstation. Bisher war das ja ein Raspberry Pi mit einem LCD-Display, aber wenn man den Aufwand für das Gehäuse, Netzteil usw. mitrechnet, dann ist die Intel-Kiste ein Schnäppchen: Ohne RAM für etwa 140 Euro, insgesamt also etwa 180.

Bleibt die Frage nach dem Betriebssystem. Linux natürlich. In diesem Fall Lubuntu, ein Ubuntu für Systeme mit wenig Resourcen. Also nix wie los. Aber da gibt es ein Problem: Ich möchte natürlich keine separate Festplatte installieren, sondern das Betriebssystem auf das interne Flash packen.

Leider sagt Lubuntu bei der Installation aber, dass es mindestens 4,3 GB braucht *grrr* Das eigentliche Image braucht nämlich nur 2.3 GB. In den Anleitungen im Netz findet man überall, dass man die Größenberechnung patchen soll. Das hat bestimmt mal mit irgendeiner Version funktioniert .....

Die Lösung ist aber einfach: Letztlich muss man nur den Installer dazu bringen, trotz vermeintlich zu knappem Platz weiter zu machen. Und das erreicht man, indem man die Fehlerbehandlung dieses Problems (siehe oben, im File ubi-prepare.py) aehm, sagen wir mal, modifiziert:

In Zeile 102 einfach True statt False, dann läuft der Installer munter weiter .... wer bremst verliert ;-)

Und noch ein Versuch


Die Bewegungserkennung mit der-Maus-Kamera funktionierte im Labor zwar sehr gut, unterm dunklen Auto in der Tiefgarage allerdings nicht mehr. Zumindest ohne Beleuchtung wird das wohl nichts.

Da ich sowieso einen IR-Temperatursensor ausprobieren wollte, war das die Gelegenheit. Auch hier war das nicht besonders kompliziert, der Beispielcode funktionierte sofort. Beeindruckend ist die Auflösung, eine Hand in einem halben Meter davorgehalten erkennt der Sensor sofort, die Hauttemperatur wird mit etwa 30 Grad gut gemessen. Der einzige Hinderungsgrund, den Sensor für das Bewegungserkennungsprojekt einzusetzen, ist der Preis, etwa 20 Euro.

Da die Inbetriebnahme viel schneller ging, als gedacht, haben wir noch ein bisschen mit dem Sensor experimentiert: Unterschiedliche Materialien haben eine unterschiedliche Emissivität. Soll etwa die Temperatur einer (auch Infrarot spiegelnden) Metalloberfläche gemessen werden, wird das mit dieser Art Sensor schwierig.

Zum experimentieren verwendeten wir ein Stück Aluminium, auf der einen Seite blank poliert, auf der anderen mattschwarz lackiert. Man kann natürlich bei der Berechnung der Temperatur die Emissivität einstellen (sowohl beim verwendeten Sensor als auch bei dem als Kontrolle verwendeten IR-Thermometer), das löst aber das Problem nicht: Die von der Umgebung (in diesem Fall vom Experimentator) ausgehende Strahlung wird von der Metalloberfläche reflektiert. Man muss also sehr genau aufpassen, welche Temperatur man misst. Das ist kein (allzu grosses) Problem, wenn das zu messende Objekt sehr viel heisser ist als die Umgebung (die Temperatur geht in der vierten Potenz in die Sensorspannung ein), bei ähnlicher Temperatur (bei uns etwa 30 Grad Umgebung vs. gut vierzig Grad am Messobjekt) ist das praktisch aussichtslos.

Fazit: Geht, aber zu teuer. Den nächsten Versuch machen wir mit Ultraschallsensoren. Nächstes Mal ;-)

Dienstag, 24. Juni 2014

Eine sezierte Maus ...



kann mehr Freude machen als man denkt, Mikroschalter, Lichtschranken und vor allem eine Kamera. Zwar beschränkt in der Auflösung (typischerweise 18x18 Pixel, schwarzweiss, also nix für die Videokonferenz) aber manchmal ist das ja von Vorteil. 

Nämlich dann, wenn man keine "Bilder" fotografieren will, sondern nur ein paar Helligkeitswerte unterscheiden muss.

Im Rahmen unserer Summerschool "physical computing" hatte ein Student die Idee, den Kofferraum seines Autos berührungslos zu öffnen. Heißt durch Gesten, in diesem Fall mit dem Fuß, weil die Hände in dieser Situation ja oft bereits belegt sind. Den Auto-spezifischen Teil (wie öffnet man den Kofferraum, wie sorgt man dafür, dass das nur im Stillstand passiert usw.) hatte er sich schon überlegt, aber die Erkennung der Geste war noch ein ungelöstes Problem. Also genau das richtige für uns ;-)

Nach einer Weile brainstorming kam die Idee auf, dieses Problem optisch zu lösen, nicht mit einer Webcam, das wäre zwar einfach, aber man braucht eine ganze Menge Rechenleistung, sondern mit der Kamera aus einer optischen Maus und einem (stromsparenden und schnell bootenden) Arduino.

Wir sind natürlöich nicht die ersten, die sich mit dem Innenleben einer Maus beschäftigt haben, wir sind nach dieser Anleitung vorgegangen, da die Jungs dort den Code freundlicherweise schon an den auch in unserer Maus vorhandenen Kamerachip ANDS2610 angepasst hatten. Funktionierte auch (beinahe wider Erwarten) sofort.

Man muß eigentlich nicht viel tun: Die Maus ihres Gehäuses entledigen und die beiden Leitungen der seriellen Schnittstelle zwischen dem Optik-Chip und dem Controller in der Maus auftrennen und mit zwei Ports eines Arduino-Controllers verbinden. Fehlt noch die Stromversorgung, die auch der Arduino übernimmt, das war's.


Im ersten Versuch liest der Arduino nur die Daten vom Kamera-Chip und überträgt die dann per serieller Schnittstelle an den angeschlossenen PC. Dort läuft ein Processing-Sketch, der die Daten grafisch darstellt und auswertet. Im Versuchsaufbau ersetzt ein schwarzer Laptop-Deckel den Asphalt des Parkplatzes, die wischende Hand wird problemlos erkannt: Der Processing-Sketch berechnet pro Bild (zwanzig pro Sekunde) die mittlere Helligkeit und daraus dann einen gleitenden Mittelwert über hundert Bilder. Ist die Abweichung des aktuellen Bildes größer als eine Schwelle, ist was passiert.


Funktioniert ! Im Labor. Schau mer mal, wie das dann aussieht, wenn der Sensor in die Stosstange des Autos eingebaut ist.

Samstag, 10. Mai 2014

So sehen Probleme aus ...


Das ist die Versorgungsspannung des Roboter-Controllers. Man sieht, wie der Regler zu schwingen anfängt. Und das gefällt dem Gyrosensor gar nicht.

Aber zurück zu den Anfängen. Wie im letzten Beitrag beschrieben wollten wir den Roboter um einen Gyrosensor ergänzen, um eine exakte Drehung machen zu können. An sich eine einfache Sache, es gibt solche Sensoren günstig und auch entsprechende Beispielprogramme. Also flugs  den Sensor an einen Arduino angeschlossen, Testprogramm ausprobiert, geht. Eingepackt und an Ostern kurz in den Roboter eingebaut. Und dann die böse Überraschung: Geht nicht. Genauer gesagt funktionierte der Gyro-Sensor, solange die Motoren nicht liefen (Arduino über USB versorgt), sobald die Motoren mitliefen, ging gar nichts mehr, Sensor reagierte nicht mehr, Roboter drehte sich fröhlich im Kreis. Oh oh ....

Heute bin ich endlich dazu gekommen, dem Problem auf den Grund zu gehen (morgen ist Julius wieder hier und will den Roboter mitnehmen).

Die Motoren erzeugen lustige Störsignale, die den Spannungsregler zum fröhlichen mitschwingen anregen. Oh oh ....

Motoren mit einem (MKT-) Kondensator entstört, schluckt die tiefen Frequenzen gut weg, aber der HF-Müll bleibt:

Die saubere Lösung wäre vermutlich ein großer keramischer Kondensator (so in der Art 0,22 µF), hab ich aber leider nicht da :-( Oder andere Motoren. Hab ich auch nicht :-(

Weitere Verzweiflungstaten wie Leitungen zum Sensor möglichst kurz machen, die Pull-Up-Widerstände am I2C-Bus auf 2k2 runtersetzen und den Motor nur mit 2/3 Gas laufen lassen führen immerhin dazu, dass der Sensor nicht sofort ausfällt, sondern im Mittel eine halbe Minute oder so mitspielt. Schön ist das nicht, aber für eine kurze Vorführung ausreichend.

Freitag, 28. Februar 2014

Ein einfacher Robotor entsteht ....



aber wozu bloß ??

Man braucht bekanntlich Motiv, Gelegenheit und Mittel zur Umsetzung.

Wie bringt man Schülern (und angehenden Studenten) die Freuden der Programmierung näher ? Mit den"klassischen" Methoden, Beispielen aus Mathematik oder einfacher String-Verarbeitung klappt das heute eher nicht mehr. Ansätze, die ganz gut funktionieren, sind etwa die Verwendung von grafischen Beispielen, etwa mit Processing. Das machen wir in der WI in Heidenheim so. Eine vielversprechende Variante ist das Scripting von Spielen, etwa so. Der Ansatz, um den es hier geht, ist die Verwendung von Robots. Durch Lego Mindstorm populär gemacht ist die Verbindung von virtueller Programmierung und physikalischer Welt eine spannende Sache. Um tatsächlich in die (technische) Programmierung einzusteigen und genügend Potential für spätere Projekte zu haben, sollte die Plattform möglichst leistungsfähig und auch durchaus auch etwa anspruchsvoll sein. Schließlich geht es ja darum, die begabten Schüler zu fördern und zu motivieren.

Verwendet haben wir einen Bausatz, den es etwa bei ebay für wenig Geld gibt, etwa hier. Der liegt seit gut einem Jahr bei mir rum und wartet auf Zuwendung. Bisher erfolglos. Aber da kam in Gestalt eines Bogy-Praktikanten das ideale Versuchskaninchen zu mir ;-) Der ist für eine Woche da und so ergab sich auch unmittelbar das Projekt: Herauszufinden, ob es gelingt, ohne Vorkenntnisse in einer Woche einen irgendwie sinnvoll funktionierende Roboter aufzubauen, der das Potential hat, auch anspruchsvollere Projekte zu realisieren.

Der erste Tag: Auspacken, Teile sichten und Zusammenbauen. Die erste Hürde: Keine Anleitung, sondern selber denken. Am ersten Abend ist alles zusammen und der Roboter fährt geradeaus.

Am zweiten Tag geht's daran, mehr als nur geradeaus zu fahren. Das heisst, die beiden Seiten mit unterschiedlichen Geschwindigkeiten anzusteuern. Das geht im Prinzip zwar einfach per PWM, aber hier ist mehr Erklärung und auch Programmierung (Erstellen von Funktionen usw) und auch ausprobieren gefragt. Ergebnis: Der Robo kann schnell oder langsam, vorwärts oder rückwärts und auch (etwas eingeschränkt) Kurven fahren. Problem ist die eher schlechte Haftung der Reifen am Boden und die Tatsache, dass beide Motoren jeder Seite gemeinsam angesteuert werden (der Motortreiber hat nur zwei Kanäle). Hier ist zu überlegen, ob man nicht etwas aufrüstet um mehr Power zu bekommen.

Ein Roboter, der nur auf dem freien Feld fahren kann, wird schnell langweilig. Deshalb kommt am dritten Tag ein Ultraschallsensor dazu, der Hindernisse erkennen kann. Der ist schnell integriert, bloss was tut man, wenn man ein Hindernis erkennt ? Zunächst mal nix:

Ein Hindernis zu umgehen, ist schon etwas komplizierter. Dazu braucht man erstmal eine Strategie. Unsere ist, es ein Stückchen weiter zu probieren, d.h. ein Stück zurück zu fahren, dann etwas zur Seite und den nächsten Versuch zu machen. So tastet man sich langsam an einem Hindernis entlang und kommt hoffentlich irgendwann daran vorbei.

Das stellte sich aber als erheblich schwieriger heraus, als erwartet: Beim Fahren enger Kurven drehen die Räder leicht durch. Dadurch ist der Winkel am Ende der Kurve unbestimmt. Manchmal geht das gut:


Manchmal (das zeigen wir nicht ;-) leider nicht. Um das zu verbessern braucht man letztlich eine Rückmeldung über die tatsächlich erfolgte Bewegung: Eine Steuerung ("Motor rechts 500 msec  drehen lassen") reicht nicht, wir brauchen eine Regelung ("So lange drehen, bis wir einen Winkel von 90 Grad zur vorigen Richtung haben"). Dazu aber zunächst mal eine Möglichkeit, die tatsächliche Lage zu messen. Das geht am einfachsten mit einem Gyro-Sensor, der hoffentlich rechtzeitig geliefert wird.


Julius: Auch aus meiner Sicht war das ganze Projekt sehr spannend und interessant, da man immer dazulernte und es nie zu schwer war. Wenn wir ein Problem hatten, haben wir immer eine Lösung gefunden, wenn es auch oft eine sehr kreative und unerwartete war. Zum Schluss schaue ich freudig auf die zurückliegende Woche und hoffe noch weitere Sensoren etc. an dem Roboter anbringen zu können, um mich immer an dieses Erlebnis zu erinnern und noch mehr über die Programmierung zu lernen. Das Programmieren ist durchaus eine Berufsaussicht für mein späteres Leben, und wenn ich
meine Berufserkundung nochmal machen könnte, würde ich wieder kommen.

Schon am ersten Tag, als wir den Roboter ohne Anleitung zusammenbauen sollten, standen wir vor unserem ersten Problem. Mit Fachkenntnis und (etwas) Glück lösten wir dieses relativ schnell und konnten alles (ohne Kurzschluss :-))verkabeln. Als wir am zweiten Tag vor dem Problem standen, dass die Geschwindigkeit des Roboters sich nur beim Rückwärtsfahren verändern ließ, fanden wir leider keine Lösung außer ihn rückwärts fahren zu lassen. Das Hauptproblem wurde die Tage später immer deutlicher: Die Räder drehten mal durch und mal nicht, zudem waren die Batterien immer schwächer und brachten nicht die selbe Leistung wie am Anfang. Durch wechseln der Batterien wurde der Roboter wieder leistungsstark. Das Programm musste ich aber auch wieder umschreiben, da er die Kurven weiter fuhr als bisher.

PS: Der Sensor kam leider nicht mehr rechtzeitig hier an.

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