Von der Bewegung zur Zahl - was zwischen Sensor und Dashboard passiert
Zwischen einem Menschen, der durch eine Tür geht, und der Zahl im Dashboard liegen rund zehn Schritte. Jeder davon kann eine Zahl verfälschen, ohne dass sie falsch aussieht.
Die meisten Anbieter beschreiben diesen Weg mit einem Satz: Der Sensor zählt, die Plattform zeigt es an. Das stimmt ungefähr so, wie „das Flugzeug fliegt“ die Luftfahrt beschreibt. Wer eine Anlage kauft, deren Zahlen in Budgets, Dienstpläne und Berichte an den Verwaltungsrat eingehen, sollte wissen, was dazwischen passiert. Die Antworten auf die richtigen Fragen sind nämlich sehr verschieden.
Dieser Beitrag geht die ganze Kette einmal durch. Viele Glieder sind in früheren Beiträgen ausführlich beschrieben. Hier stehen sie zum ersten Mal in ihrer Reihenfolge, und vier davon, die bisher nirgends erklärt sind, bekommen einen eigenen Abschnitt.
Die Kette in zehn Gliedern
| # | Glied | Was passiert | Ausführlich in |
|---|---|---|---|
| 1 | Sensor | Das Bild wird im Gerät ausgewertet, hinaus geht Text | Welche Technologie zählt Personen wie genau? |
| 2 | Übertragung | Push per HTTPS an eine standorteigene Adresse, alle paar Sekunden | Datenschutz ist eine Architekturentscheidung |
| 3 | Anmeldung | Schlüssel je Standort, zeitkonstant verglichen | ebenda |
| 4 | Grenzen | Grösse und Aufbau der Nachricht geprüft | unten |
| 5 | Duplikat | Eine Nachricht wird einmal gezählt, auch wenn sie zweimal kommt | Datenschutz ist eine Architekturentscheidung |
| 6 | Schreiben | Ein atomarer Schreibvorgang in den Minutenzähler | unten |
| 7 | Wiederholen | Was scheitert, wird aufbewahrt und nachgeholt | unten |
| 8 | Ableiten | Zonen, Wege, Warteschlangen, Alarme aus derselben Nachricht | unten |
| 9 | Belegung | Eintritte minus Austritte, mit Nullpunkt in der Nacht | Belegung ist eine Bilanz |
| 10 | Auswertung | Ausfalltage erkennen, in der Zeitzone des Standorts rechnen | Der halbe Ausfall |
Die Reihenfolge ist nicht beliebig. Geprüft wird, bevor gezählt wird, und gezählt wird, bevor irgendetwas anderes aus der Nachricht entsteht. Warum das wichtig ist, zeigen die Abschnitte unten.
Glied 4: Warum die Grenze auf den Bytes liegt
Jede Nachricht im Netz kündigt im Kopf an, wie gross sie ist. Ein naheliegender Schutz wäre, diese Angabe zu prüfen und zu grosse Nachrichten abzuweisen. Das Problem: Die Angabe kommt vom Absender. Ein fehlerhaftes Gerät oder ein Angreifer kann eine kleine Grösse ankündigen und eine grosse Nachricht schicken.
Belastbar ist deshalb nur eine Grenze, die auf den tatsächlich empfangenen Bytes liegt. Dazu kommt eine Prüfung des Aufbaus gegen ein festes Schema - mit Obergrenzen dafür, wie viele Bilder, Ereignisse und Objekte eine einzelne Nachricht enthalten darf. Was diese Grenzen verletzt, wird abgewiesen, bevor Rechenzeit entsteht, und mit einem klaren Fehlercode beantwortet.
Das klingt nach Sicherheitstechnik, und das ist es auch. Es ist aber vor allem Datenqualität: Eine Nachricht, deren Aufbau nicht stimmt, ist nicht nur verdächtig, sie ist auch als Zahl unbrauchbar.
Glied 6: Warum ein Zähler nicht lesen darf, bevor er schreibt
Der naheliegende Weg, einen Zähler zu erhöhen, hat drei Schritte: aktuellen Stand lesen, eins dazuzählen, neuen Stand zurückschreiben. Das funktioniert, solange immer nur eine Nachricht auf einmal kommt.
An einem Standort mit mehreren Sensoren kommen aber Nachrichten gleichzeitig an. Dann passiert Folgendes: Beide lesen den Stand 11, beide rechnen 12, beide schreiben 12. Zwei Menschen sind durch die Tür gegangen, gezählt ist einer. Der Fehler taucht in keinem Protokoll auf, und das Ergebnis sieht plausibel aus - es ist nur zu klein.
Die Lösung ist ein einziger Schreibvorgang, der die Erhöhung selbst an die Datenbank übergibt: „erhöhe um eins“ statt „setze auf 12“. Die Datenbank führt ihn als unteilbaren Vorgang aus. Parallele Nachrichten können sich dann weder überschreiben noch doppelt zählen. Das Fachwort ist atomares Inkrement, und die Frage, ob ein Anbieter so schreibt, gehört in jede technische Prüfung.
1'440 Minuten statt 34'560 Meldungen
Ein Sensor meldet sich alle zweieinhalb Sekunden. Würde jede Meldung als eigener Datensatz gespeichert, entstünden je Standort und Tag 34'560 Einträge. Geschrieben wird stattdessen in einen Zähler je Minute: 1'440 Datensätze je Tag, rund 96 Prozent weniger, ohne die Minutenauflösung zu verlieren. Bei mehreren Sensoren entsteht ein Zähler je Sensor und Minute, sodass sich jeder einzeln prüfen lässt.
Die Minute ist dabei eine bewusste Wahl. Sie ist fein genug, um eine Spitze um 12:07 von einer um 12:15 zu unterscheiden, und grob genug, dass eine Auswertung über ein ganzes Jahr schnell bleibt. Welche Auflösung eine Auswertung zeigt, von der Minute bis zum Tag, legt der Server je nach Zeitraum fest - nicht das Werkzeug, das die Daten abruft.
Glied 7: Wenn das Schreiben scheitert
Datenbanken sind gelegentlich kurz nicht erreichbar. Die Frage ist nicht, ob das passiert, sondern was dann mit der Zahl geschieht. Drei Antworten sind möglich: Sie geht verloren. Sie wird sofort noch einmal versucht, und wenn das auch scheitert, geht sie verloren. Oder sie wird dauerhaft aufbewahrt und später nachgeholt.
Nur die dritte ist belastbar. Das Verfahren dafür heisst Dead-Letter-Queue: Ein gescheiterter Schreibvorgang landet in einer dauerhaften Warteschlange und wird bis zu dreimal wiederholt, mit wachsendem Abstand von rund 5, 10 und 20 Sekunden. Der Abstand trägt eine Zufallsschwankung von 20 Prozent. Das ist kein Schönheitsfehler, sondern Absicht: Ohne sie würden nach einer kurzen Störung alle gescheiterten Vorgänge im selben Augenblick wiederkommen und die gerade erholte Datenbank sofort wieder überlasten.
Dazu kommt ein Detail, das nur Plattformen betrifft, die auf serverlosen Funktionen laufen. Eine solche Funktion kann nach ihrer Antwort eingefroren werden, mitten in einer Arbeit, die sie noch nicht abgeschlossen hat. Ein Vorgang, der deshalb länger als fünf Minuten als „in Bearbeitung“ markiert ist, wird automatisch freigegeben und erneut versucht. Ohne dieses Netz bliebe er für immer liegen.
Weil der Duplikat-Anspruch vor dem Schreiben sitzt, ist jede dieser Wiederholungen ungefährlich. Eine Nachricht, die dreimal versucht wird, zählt trotzdem einmal.
Glied 8: Eine Nachricht, viele Auswertungen
Dieselbe Nachricht, die den Minutenzähler erhöht, enthält mehr als eine Zahl. Aus ihr entstehen danach die Verweildauer je Zone, die Wege durch eine Fläche, die Blickrichtung, Geschwindigkeit und Körpergrösse, die Wartesituationen, die Prüfung der Alarmregeln und die Aufrufe an Anzeigen und Gebäudetechnik.
Wichtig ist die Reihenfolge. All das entsteht erst, nachdem die Zählung sicher geschrieben ist. Eine aufwendige Auswertung, die länger braucht oder scheitert, kann damit die Grundzahl nie mitreissen. Die Zählung ist das Fundament, alles andere steht darauf.
Wie diese abgeleiteten Grössen zu lesen sind, steht in den Beiträgen dazu: Zonen und Verweildauer in Verweildauer messen, Warteschlangen in Warteschlangen steuern, Demografie und Objekte in Was ein Zähler unterscheiden kann, Alarme in Von der Zahl zur Handlung.
Was eine Kette belastbar macht
Fasst man die zehn Glieder zusammen, bleiben vier Eigenschaften, an denen sich jede Plattform messen lassen muss:
- Keine Zählung wird doppelt geschrieben, auch wenn eine Nachricht zweimal kommt oder wiederholt wird.
- Keine Zählung wird überschrieben, auch wenn mehrere Sensoren gleichzeitig melden.
- Keine Zählung geht still verloren, auch wenn die Datenbank kurz nicht antwortet.
- Keine Auswertung sieht besser aus, als sie ist, auch wenn ein Sensor halb ausfällt oder die Uhr umgestellt wird.
Die ersten drei betreffen das Schreiben und sind in diesem Beitrag beschrieben. Die vierte betrifft das Lesen und steht in Der halbe Ausfall. Beide Hälften braucht es: Eine sauber geschriebene Zahl, die falsch gelesen wird, ist so wertlos wie eine falsch geschriebene.
Was in die Ausschreibung gehört
- Wird die Grösse einer eingehenden Nachricht auf den empfangenen Bytes geprüft, und gibt es Obergrenzen für ihren Aufbau?
- Wie erkennt die Plattform eine Nachricht, die zweimal zugestellt wird?
- Wird der Zähler in einem einzigen atomaren Schreibvorgang erhöht, oder wird vorher gelesen?
- Was passiert mit einem Schreibvorgang, der scheitert - wie oft wird er wiederholt, in welchem Abstand, und wo liegt er in der Zwischenzeit?
- Entstehen abgeleitete Auswertungen erst nach der gesicherten Zählung?
- In welcher Auflösung wird gespeichert, und wer legt fest, in welcher Auflösung ausgewertet wird?
- Ist die Planung der Zähllinien Teil der Installation, damit sich zwei Sensoren an derselben Tür nicht überschneiden?
Wie wir das machen
Das ANALYSIT Counting System nimmt den Live-Data-Push des Sensors per HTTPS an einer standorteigenen Adresse entgegen, mit Ratenlimit, Bearer-Schlüssel je Standort im zeitkonstanten Vergleich, einer harten Grenze von 1 MB auf den empfangenen Bytes und vollständiger Schema-Validierung mit höchstens 100 Frames sowie 500 Ereignissen und 500 Objekten je Frame.
Vor jeder Zählung beansprucht ACS atomar einen Duplikat-Schlüssel aus Mandant, Standort, Sensor-Seriennummer und Framenummer. Danach geht die Zählung als ein einziger atomarer Upsert in den Minuten-Bucket, und der Live-Zähler des Standorts wird ebenso atomar inkrementiert. Beide Kernschreibpfade laufen durch eine Dead-Letter-Queue mit bis zu drei Wiederholungen, exponentiellem Backoff und Jitter; Ansprüche, die länger als fünf Minuten in Bearbeitung stehen, werden automatisch freigegeben.
Ein Dokument je Minute ergibt 1'440 Buckets je Standort und Tag, gespeichert über 730 Tage, mit serverseitig erzwungener Granularität von einer Minute bis zu einem Tag. Zonen-Verweildauer, Journeys, Wartesituationen, Alarmprüfungen und Display-Trigger entstehen erst danach aus demselben Push.
Wenn du wissen willst, wie eure Zahlen entstehen, bevor sie in einem Bericht an den Verwaltungsrat stehen, sprich mit uns. Wir gehen die zehn Glieder gern mit deiner IT durch.