Jedes Hersteller-Diagramm eines IoT-Deployments zeigt drei Kästen: Sensor, Cloud, Dashboard. Das Bild ist nicht falsch. Auf einer brauchbaren Plattform ist die technische Anbindung der einfache Teil.
Falsch ist das Bild beim Thema Zeit. Ein echtes Deployment besteht aus einer Reihe unspektakulärer Schritte mit fester Abhängigkeitsreihenfolge. Teams, die es zum ersten Mal machen, drehen diese Reihenfolge um: erst das Dashboard, weil das Spaß macht. Dann die Hardware, weil sich das Projekt dann echt anfühlt. Die Nutzer zuletzt, weil eine Woche vor dem Go-live jemandem einfällt, dass sich die Mitarbeiter des Kunden anmelden müssen. Jede Umkehrung kostet Wochen.
Im Folgenden ein generisches Deployment in der richtigen Reihenfolge: Ein Systemintegrator baut Temperatur- und Türsensoren in 40 Kühlräume an 6 Standorten eines Lebensmittelgroßhändlers ein. Tauschen Sie die Kühlräume gegen Tanks oder Zähler, die Phasen bleiben dieselben.
Scope und Abnahmekriterien (Woche 1 bis 2)
“Wir wollen die Kühlräume überwachen” ist ein Wunsch, kein Scope. Das Deployment braucht eine schriftliche Definition davon, was fertig heißt. Hier: Temperatur alle 10 Minuten, Markierung, wenn eine Tür länger als 5 Minuten offen steht, Alarm über 5 C für 20 Minuten, Push-Benachrichtigung an den Standortleiter und E-Mail an den Betriebsleiter, pro Standort eine Seite mit dem Verlauf je Raum.
Zwei Wochen klingen lang für ein Dokument. Die Zeit geht ins Warten: Der Betriebsleiter und der Haustechnik-Dienstleister sind sich nicht einig, wer die Alarmbearbeitung verantwortet, und niemand klärt das, solange Sie nicht schriftlich nachfragen. Wer diese Phase überspringt, verschiebt die zwei Wochen auf das Go-live, wo sie mehr kosten. Mehr dazu im Planungsleitfaden für nicht-technische Projektleiter.
Standortbegehung und Funkcheck (Woche 2 bis 3)
Kühlräume sind Metallkisten mit isolierten Türen. Funk mag das nicht. Bevor Sie 40 Sensoren bestellen, müssen Sie für jeden Raum wissen, ob ein LoRaWAN-Gateway im Flur bei geschlossener Tür nach innen reicht und ob dieses Gateway Strom und Backhaul hat.
Eine Person, zwei Testsensoren, ein Gateway, ein Tag pro Standort. Die Begehung schreibt die Hardwareliste um: Zwei Standorte brauchen ein zweites Gateway, einer hat im Technikraum keinen Mobilfunkempfang. Das jetzt zu finden kostet eine Woche. Es bei der Inbetriebnahme zu finden kostet pro Standort eine zweite Anfahrt. LoRaWAN-Reichweite in der Praxis liefert die Zahlen.
Hardwarebeschaffung (Woche 3 bis 8) und Plattformaufbau (Woche 3 bis 5), parallel
Sensoren und Gateways kommen in vier bis sechs Wochen. Neulinge warten. Erfahrene Teams bauen in diesem Fenster die komplette Plattformseite, ohne ein einziges Stück Hardware in der Hand zu haben. Das ist der größte Zeitgewinn im ganzen Projekt.
Auf TagoIO ist die Reihenfolge:
- Erstellen Sie ein Device mit dem Connector für das Sensormodell und dem Network für den LoRaWAN-Anbieter. Der Connector dekodiert die Bytes des Herstellers in Temperatur, Türzustand und Batterie.
- Schicken Sie einen Beispiel-Uplink aus dem Datenblatt durch den Payload Parser und prüfen Sie, ob dabei die Variablennamen entstehen, die Dashboard und Alarme später verwenden. Einheitenumrechnungen und Umbenennungen gehören jetzt in den Parser, einmalig.
- Legen Sie die Tag-Konvention fest, bevor irgendetwas anderes existiert: Standort, Raum,
asset_type, Kunde. Dashboards, Alarme, Zugriffsrichtlinien und Berichte filtern alle darüber. - Bauen Sie ein Blueprint Dashboard, das Devices über Tags auflöst. Ein Dashboard bedient alle 40 Räume und jeden künftigen Raum. Schicken Sie simulierte Daten an das Test-Device, damit die Widgets etwas zu zeigen haben.
Zwei Wochen Arbeit für einen Ingenieur. Wenn die Hardware ankommt, ist die Plattform fertig, nicht angefangen.
Inbetriebnahme der Hardware und Tag-Disziplin (Woche 8 bis 10)
Die Montage dauert so lange, wie sie dauert: ein Sensor pro Raum, Gateways an die Wand, Etiketten auf alles. Sechs Standorte mit je zwei Tagen sind zwei Wochen für einen Monteur.
Auf der Plattformseite zahlt sich die Tag-Disziplin aus. Legen Sie für jeden Sensor das Device aus demselben Connector an, setzen Sie die Tags auf den Raum, in dem er hängt, und bestätigen Sie den ersten Uplink. Raum 17 an Standort 3 erscheint im Blueprint Dashboard, sobald sein Device die richtigen Tags und einen Datenpunkt hat. Während der Inbetriebnahme baut niemand ein Dashboard. Wenn doch, wurde die vorige Phase übersprungen.
Führen Sie ein Inbetriebnahmeprotokoll: Device-EUI, Standort, Raum, Montagedatum, Monteur. Wenn ein Sensor im dritten Monat verstummt, macht dieses Protokoll aus einem verlorenen Nachmittag fünf Minuten Arbeit.
Alarme über Actions, und wer sie bekommt (Woche 10)
Die Schwellwerte stehen schon im Scope. Die Woche geht dafür drauf, zu klären, wer was bekommt. Richten Sie Actions ein, die auf die Variablenbedingung reagieren (Temperatur über dem Grenzwert für die vereinbarte Dauer, Tür zu lange offen) und eine Push-Benachrichtigung an die TagoRUN-Nutzer des Standorts sowie eine E-Mail an den Betriebsleiter senden. Eine Action pro Alarmtyp, nach Tag gefiltert, deckt jeden Raum ab. Legen Sie zusätzlich eine Action für “Device seit 2 Stunden stumm” an: Eine leere Batterie ist der häufigste Ausfall, und sie erzeugt keine Daten, also löst nie ein Schwellwert aus. Leiten Sie in den ersten Tagen alles an sich selbst um.
Endnutzerzugang über TagoRUN (Woche 10 bis 11)
Die Standortleiter sehen das TagoIO Admin nie. Sie melden sich in einem TagoRUN-Portal unter der Marke des Integrators an, im Web und in der TagoRUN Mobile App, damit Push-Benachrichtigungen auf ihren Telefonen ankommen. Eine Access Management-Richtlinie gibt jedem Nutzer das Blueprint Dashboard, beschränkt auf Devices, deren Standort-Tag zu ihm passt. Der Betriebsleiter bekommt eine Richtlinie über alle sechs Standorte. Legen Sie die Nutzer eine Woche vor dem Go-live an und führen Sie einen Standortleiter in einem Call durch die App. Seine Fragen werden die erste Seite des Runbooks.
Go-live und die ersten zwei Wochen (Woche 11 bis 13)
Das Go-live ist eine E-Mail, die sagt: Die Alarme gehen ab jetzt an den Kunden. Dann fangen die Fehlalarme an.
Jedes Kühlraum-Deployment liefert dieselben zwei Wochen: Der Schwellwert von 5 C löst aus, sobald ein Gabelstapler die Tür zum Einlagern offen hält. Der Türalarm geht bei der planmäßigen Reinigung los. Ein Raum läuft absichtlich wärmer, weil dort Obst und Gemüse lagern. Nichts davon war aus dem Scope-Dokument absehbar. Bei den Actions wird die Dauer verlängert, ein Reinigungsfenster wird ausgenommen, Raum 22 bekommt über einen Tag seinen eigenen Schwellwert. Sagen Sie dem Kunden vorher, dass diese Wochen der Feinabstimmung dienen. Sonst liest er das Rauschen als kaputtes System.
Übergabe an den Betrieb (Woche 13)
Die Übergabe ist ein Dokument und ein Termin: das Runbook (was jeder Alarm bedeutet, wer reagiert, wie man einen Sensor tauscht und sein Device neu taggt), das Inbetriebnahmeprotokoll, die aktuellen Schwellwerte und ein benannter Verantwortlicher auf jeder Seite. Wenn Sie das als Managed Service verkaufen, beginnt hier die monatliche Gebühr und endet das Projektbudget.
Der dritte Monat
Im dritten Monat ist das Deployment langweilig, und genau das ist das Ziel. Dann kommen die ungeplanten Anfragen.
Das Datenvolumen wird zum Posten auf der Rechnung. Vierzig Sensoren alle 10 Minuten sind über 5.700 Messwerte pro Tag, und die Rohdatenhistorie braucht nach ein paar Monaten niemand mehr. Data Retention an jedem Device begrenzt das.
Der Kunde fragt nach einem Monatsbericht. Eine zeitgesteuerte Analysis rechnet die Minuten außerhalb des Bereichs und die Minuten mit offener Tür pro Standort aus und schreibt eine Zusammenfassung für ein Widget oder eine E-Mail. Ein Tag Skriptarbeit, weil die Tags die Daten schon nach Standort trennen.
Der Kunde will zwei weitere Standorte. Erweiterung heißt: Begehung, Hardware, Devices mit demselben Connector und dem neuen Standortwert, dazu Nutzer mit einer passenden Richtlinie. Dashboard, Actions und Bericht funktionieren schon.
Dreizehn Wochen bis zur Übergabe, die Plattformarbeit passt in die Lieferzeit der Hardware, und der größte Teil des Kalenders geht fürs Warten auf Menschen, Funk und Lieferung. Die drei Kästen waren nie das Problem.
