Die Vielfalt an Möglichkeiten kennen Sie vielleicht auch schon von zu Hause, von Ihrer Smart-Home-Ausstattung. Egal, ob bereits das ganze Haus vernetzt oder nur eine Lampe als Einstieg mit dem Internet verbunden ist – schon in diesem verhältnismäßig kleinen IoT-Umfeld bekommt man zu spüren, wie hoch der Aufwand an Einrichtung, Wartung und Nachbesserungen sein kann. Zumindest die Updates der Systeme erfolgen immer dann, wenn es nicht passt. Hat man dazu noch Spaß an technischen Basteleien, gibt es kaum noch Grenzen: Da wird die Ambilight-Lösung mit dem Raspberry Pi an das KNX-System des Hauses gekoppelt und das natürlich meist ohne jegliche Dokumentation.
Smart Buildings vereinen mittlerweile ein Vielfaches solcher IoT-Geräte. Es werden tausende Sensoren, Lampen, Kameras etc. verbaut und vor allem auch miteinander und mit Systemen zur Steuerung vernetzt. Um solche Technik zu betreiben und gleichzeitig ihr volles Potential auszunutzen, ist inzwischen ein ganz anderes Know-how notwendig als noch vor einigen Jahren.
Die klassische IT-Umgebung wird also zu einer IoT-Umgebung. Was bedeutet das für den Betreiber eines solchen Gebäudes oder einer ähnlich smarten Umgebung? Ändern sich durch den Wandel von IT zu IoT auch die Anforderungen an den Betreiber? Können bekannte Methoden und Prozesse in diesen Umgebungen noch angewandt werden oder benötigt man hier komplett neue Denkweisen?
IT-Betrieb – die Anfänge
Betrachten wir zunächst, was sich für einen Betreiber einer IT-Umgebung im Laufe der Jahre bereits geändert hat. Stellen Sie sich das typische Netz des 20. Jahrhunderts vor: Die Kommunikation innerhalb des Netzes bestand aus wenigen Megabytes (MB) pro Tag (siehe Abbildung 1). E-Mails gab es kaum, Webbrowsing wurde noch pro Zeiteinheit abgerechnet und dementsprechend auch selten genutzt. An zusätzlichen Endgeräten, neben den Desktop-PCs, gab es höchstens noch Drucker, oft lokal am PC angeschlossen.
Telefone und Faxgeräte waren in diesem IP-Netz nicht zu finden. Sie waren separat verdrahtet und hatten nichts mit IT zu tun. Auch Beleuchtung, Klimatechnik usw. waren nicht Teil der IT, sondern zählten zur Haustechnik.
Was man also als Tätigkeitsfeld des klassischen IT-Betreibers heutzutage kennt, war zu der Zeit oft auf verschiedene Bereiche aufgeteilt: (Büro-)IT, Anlagentechnik und Haustechnik. Es gab verschiedene Betreiber, die für die jeweiligen Bereiche zuständig waren.
Der IT-Betreiber war zu dieser Zeit eher ein Techniklieferant. Er war zwar auch damals schon dafür zuständig, die IT-Ausstattung am Laufen zu halten, allerdings bestanden die Aufgaben eher darin, Geräte bei Defekt auszutauschen oder Hardware zu reparieren.
Abbildung 1: Netz im letzten Jahrhundert mit wenig Datenverkehr
Zudem war seinerzeit auch der Zeitdruck ein anderer als heute. Funktionierte ein Endgerät nicht, arbeitete man offline weiter, schlug die Information im Fachbuch nach oder gab das Dokument einfach später in die Post, wenn der Drucker nicht mehr streikte. Die ganz „wichtigen“ Drucker waren lange Zeit oft noch lokal an den PCs der Hauptnutzer angeschlossen. Daher gab es zunächst auch kaum messbare Werte in Bezug auf den Betrieb. Entsprechend erfolgte keine Messung von Reaktionszeiten, Ausfallzeiten etc.
Als solche Geräte und entsprechende Software besser wurden, wandelte sich die elektronische Datenverarbeitung (EDV) zur echten Arbeitserleichterung und Beschleunigung von Arbeitsgängen. Je wichtiger und vernetzter IT-Ausstattung als Arbeitsmittel wurde, umso schädlicher wurden auftretende Störungen oder Ausfälle. Diese Geräte „irgendwie am Laufen halten“ war bald nicht mehr genug.
Als Konsequenz entstand die erste ITIL-Version, die auf einigen Ende der 80er-Jahre formulierten Empfehlungen einer britischen Behörde basierte. Die britische Regierung hatte IT-Dienstleistungen eingekauft und war mit der Leistung extrem unzufrieden. Also beauftragte sie eine Regierungsbehörde damit, Möglichkeiten zu finden, um IT-Dienstleistungen zu optimieren. Heraus kam die erste ITIL-Ausgabe. Sie bestand aus 42 Büchern. Viele der damaligen Methoden werden heute noch angewendet. Schon in V1 ging es um Change Management, Help-Desk-Funktion und Problem Management. Denkweise und Betriebsmodell konzentrierten sich dabei noch sehr auf den Betrieb von Hard- und Software und den Betrieb im traditionellen aus der Mainframe-Ära kommenden Rechenzentrum. Doch die Entwicklung ging weiter.
Klassischer IT-Betrieb
Mittlerweile sind unsere IT-Netze weitaus komplexer (Abbildung 2), die IT-Lösungen vielfältiger und stärker verteilt, die Datenmengen größer, und der Anwendernutzen bestimmt die Bewertung der Betriebsqualität. Die E-Mail-Kommunikation bewegt sich alleine schon im Gigabyte-Bereich. Telefone sind mittlerweile ganz klar IT-Komponenten. Lediglich die Haustechnik ist im klassischen IT-Netz weiterhin nicht zu finden. Dafür sind Collaboration-Tools hinzugekommen, und Webnutzung zu verschiedensten Zwecken ist selbstverständlich geworden. Digitales Dokumenten- und Informationsmanagement und softwarebasierte Unterstützung von Workflows verschiedenster Arbeitsbereiche sind ebenso selbstverständliche IT-Lösungen wie spezialisierte Applikationen für bestimmte Fachgebiete.
Abbildung 2: IT-Netz mit hohem Datenaufkommen
Wo solche Arbeitsformen und Arbeitsmittel noch nicht so stark genutzt werden, wird unter dem Stichwort „Digitalisierung“ zumindest daran gearbeitet, dass sie Einzug halten. Beispielsweise wird papierbasiertes Arbeiten immer mehr durch rein digitale Informationsketten verdrängt. Papiervermeidung spart Platz und schont die Umwelt. Elektronische Daten haben klare Vorteile beim Auffinden und Austauschen. Wer greift im Alltag noch zu Lexika oder gedruckten Straßenkarten, wenn er per Browser und App schneller an die benötigen Informationen kommt?
Alles wird vernetzter, schneller und kritischer. Welches Endgerät können Sie noch benutzen, wenn das Internet oder gar das interne Netz ausfällt? Die Anforderungen an die Verfügbarkeit sind also extrem stark gestiegen genauso wie die Anforderungen an das Know-how, das mittlerweile vorhanden sein muss, um all diese Technik entsprechend betreiben zu können.
Der IT-Betrieb ist kein reiner Techniklieferant mehr, er ist ein serviceorientierter Dienstleister. Komplexe Netze und neueste Technik müssen nicht mehr nur instandgehalten, sondern als Dienstleistung bereitgestellt und mit Support bei der Nutzung abgerundet werden. Funktionierende Technik allein reicht nicht mehr aus, um den angestrebten Nutzen aus den angeschafften Ressourcen ziehen zu können. Auf Anfragen von Anwendern muss zeitnah reagiert werden, da Ausfälle mittlerweile extrem zeitkritisch sind. Der Technikbetreiber wird zum Service-Anbieter.
Hinzu kommt: Die typische Erwartungshaltung an Services ist indessen messbar und nur IT-Services mit geeignetem Qualitätslevel liefern einen brauchbaren Wertebeitrag zum eigentlichen Geschäft der Nutzergruppen. Bei Störungen oder Ausfällen kann der Schaden bis nach außen hin spürbar sein. Es geht um Imageverlust, hohe Einkommensverluste und drohende Klagen in manchen Fällen. Nehmen Sie beispielsweise den Serverausfall Ihres Cloud-Dienstleisters, der nicht innerhalb von wenigen Stunden behoben werden kann – aus betrieblichen Gründen (z.B.: durch ein fehlerhaftes Update). Sie als Nutzer sind davon betroffen, je nach Cloud-Nutzungszweck mit empfindlichen Einschränkungen für Ihr Unternehmen und Ihre Kunden.
Auch in der ITIL-Welt gab es natürlich eine entsprechende Weiterentwicklung. Dienstleistungsgedanke, Service-Level-Ansatz und immer neue Technikangebote wurden als prägender Teil der Aufgabenstellung berücksichtigt. ITIL 4 ist als aktuelle Version seit letztem Jahr verfügbar. Der Blickwinkel richtet sich nun stark auf den Lebenszyklus einer Integration verschiedenster Service-Angebote und wie dieser kontinuierlich angepasst werden kann.
IoT-Betrieb
Was macht jetzt den Unterschied zwischen IT- und IoT-Betrieb aus, der zum besonderen Nachdenken zwingt?
Nehmen wir das oben bereits skizzierte Bild vom Netz als Einstieg. Wenn man moderne Netze betrachtet, fehlen in dem Bild noch einige Details. Mittlerweile werden in der Praxis oft die Gebäudetechnik sowie die eine oder andere Produktionsumgebung in das für klassische (Büro-)IT genutzte Netz eingebunden. Diese Entwicklung betrifft sämtliche smarten Geräte, wie sie in der Einführung schon beschrieben wurden. IoT-Komponenten sind mittlerweile ein Teil des IP-Netzes geworden (siehe Abbildung 3) und somit auch einhergehend mit Betriebspflichten. Da diese Komponenten meist die vorhandene Außenanbindung nutzen, beinhaltet das natürlich die typischen Sicherheits- und Betriebsrisiken, auf die ich hier nicht näher eingehen werde (Details hierzu bietet der Insider Artikel „IoT-Sicherheit – (Un-)möglich?“ von November 2019).
Abbildung 3: Herstellervergleich zwischen den Small-Cell-Lösungen von Huawei und Ericsson
Wenn das Netz ausfällt, kann mittlerweile mehr als nur die Büro-IT betroffen sein, die gesamte Gebäudetechnik ist potenziell betroffen. Im schlimmsten Fall ist ein smartes Gebäude offline und damit nur noch notdürftig nutzbar, oder eine Produktionsumgebung steht still. Das darf nicht passieren, denn hier geht es nicht mehr nur um Imageverluste und Einkommenseinbußen, sondern auch um mögliche Personenschäden, die vermieden werden müssen.
Ebenso überschreiten die Dimensionen das aus dem klassischen Netz bekannte Maß an Anschlusszahlen und Nutzungsumfang deutlich: In einem von uns betreuten smarten Gebäude sind 3500 Sensoren und 7000 Lampen verbaut. Dazu kommen noch viele weitere IoT-Produkte sowie zugehörige Gateways und die Endgeräte der Nutzer selbst. Aufgaben wie deren Inbetriebnahme, Austausch, Änderungen, Updates und die Außerbetriebnahme sind Teil des IT-Betriebs. Die Netzinfrastruktur und deren Betreiber müssen mit Kommunikationsformen ganz unterschiedlicher Datenmengen und Empfindlichkeiten zurechtkommen.
Um dem gerecht zu werden, braucht es tatsächlich neue Denkweisen und Betriebsabläufe, nicht nur im Netzbetrieb. Der smarte Teppich ist ein gutes Beispiel für ein komplexes smartes „Thing“. Eingewebte LEDs können beliebige Texte oder Symbole anzeigen und so für Indoor-Navigation mit Raumbuchungssystemen oder auch für Werbung genutzt werden. Die LEDs sind in deaktiviertem Zustand nicht sichtbar und der Teppich fühlt sich an wie sich ein Teppich anfühlt.
Wie betreibt man aber einen solchen Teppich, wie beantwortet man hier wichtige Fragen? Wer ist zuständig, sollte ein Technikproblem auftreten? Wer meldet Defekte? Und woher weiß derjenige, an wen er sich wenden muss? Wer patcht den Teppich? Wie patcht man den Teppich? Muss ich ihn gegen unbefugten Zugriff absichern? Wie? Was passiert bei einem Defekt? Wird er ausgetauscht – der ganze Teppich? Kann man den smarten Teppich als Fluchtwegbeleuchtung nutzen? Um das zu tun, müsste man ihn zumindest redundant auslegen. Wie soll das gehen?
Sie merken, allein schon bei diesem Beispiel kann man die Gedanken noch weiter-spinnen, und dabei handelt es sich zunächst nur um ein einziges Produkt.
Die Komplexität wächst mit der Art der Nutzung eines solchen Produkts: Damit der Teppich Ihnen den Weg weisen kann, benötigt er eine Kopplung mit Sensoren, Kalendern, Smartphones etc. Wenn angezeigt werden soll, welche Räume frei sind, ist z.B. eine Kopplung mit Exchange notwendig. Und schon haben wir das Internet of Things, eine Kopplung von mehreren smarten Geräten, die meist IP-basiert miteinander kommunizieren und Daten austauschen.
Bekannte Best Practices noch anwendbar?
Die Frage ist jetzt natürlich, ob die bekannten Methoden und Prozesse, die man aus dem klassischen IT-Umfeld kennt, noch anwendbar sind. Lassen sich dort bewährte Ansätze einfach auf den IoT-Betrieb übertragen, wie z.B. ein zentraler IT-Support mit Ticketsystem, Changes nach Feierabend, Ausrollen von Updates nach ausführlicher Testphase, Tests nach dem Ausrollen von Updates, die Sammlung von Methoden in einem Betriebshandbuch oder auch ein zentrales Monitoring?
Ein paar Beispiele möchte ich im Folgenden näher betrachten.
Support
Denken Sie an den klassischen zentralen First-Level-Support, so wie er bei Ihnen im Unternehmen wahrscheinlich existiert. Ist ein solcher bei IoT-Produkten in jedem Fall noch sinnvoll?
Entsprechende Fragen haben wir uns beim smarten Teppich bereits gestellt: Wenn IoT-Equipment defekt ist, wer ist dann zuständig? Die Haustechnik hat wahrscheinlich nicht das entsprechende Know-how. Die IT-Abteilung wird sich nicht mit sämtlichen IoT-Produkten auskennen. Deshalb greift man bei technischen Fragen rund um IoT-Produkte gerne auf den jeweiligen Hersteller-Support zurück.
Dieser Weg ist allerdings nicht pauschal zielführend. Sollten Sie mit dem Smartphone vor einem smarten Gebäude stehen und die zugehörige App öffnet die Türen nur bei Ihnen nicht wie erwartet, wird der Hersteller-Support der Zutrittskontrollsysteme nicht weiterhelfen können. Auch die App-Entwickler oder der Betreiber selbst können hier vermutlich nicht behilflich sein. Ein Pförtner, der bei solchen Problemen helfen kann oder zumindest an den richten Ansprechpartner verweist, wäre in diesem Fall wahrscheinlich zielführender.
Es sollte fallweise entschieden werden, welche Support-Strukturen für die jeweiligen IoT-Produkttypen sinnvoll sind. Das können bereits vorhandene interne Support- und Meldewege sein oder externe am Markt verfügbare Service-Optionen, die dem jeweiligen IoT-Produkttyp entsprechen. Man sollte sich schon bei der Produktentscheidung im Klaren sein, ob „Support-inklusive“-Angebote in Betracht gezogen werden oder nicht.
Ein weiterer Faktor in Bezug auf Support-Strukturen ist die I(o)T-Sicherheit. Ist es überhaupt möglich, Externen in jedem Fall Zutritt zu bzw. Zugriff auf interne Systeme zu gewähren? Das ist notwendig, wenn der First-Level-Support über Externe abgedeckt wird. In manchen Fällen ist es deshalb sinnvoller, zunächst interne Ressourcen zu nutzen und erst im kniffligen Fall auf den externen Dienstleister zurückzugreifen.
Neben der Frage, welche Support-Struktur am hilfreichsten wäre, muss man sich auch die Frage nach den finanziellen Möglichkeiten stellen. Manchmal ist es sinnvoller, intern bereits vorhandenes Personal zu schulen, als Support-Pauschalen zu zahlen. In manchen Fällen ist es wiederum einfacher, externe Hilfe einzubinden, als neue eigene Strukturen aufzubauen.
Die Support-Strukturen sollten in Bezug auf die verschiedenen IoT-Produkttypen neu durchdacht und definiert werden, sodass klar wird, wer der erste Ansprechpartner ist und wer letztendlich für die Durchführung einer Support- oder Betriebsaufgabe zuständig ist. Eventuell muss man sogar zwischen Routine-Betriebsaufgaben und auftretenden Störungen unterscheiden.
Herstellerwahl
Man merkt also, der Hersteller bzw. ein auf dessen Produkte spezialisierter Support-Dienstleister ist mittlerweile bei Überlegungen zur Betriebs- und Service-Organisation zu berücksichtigen. Solange IoT-Produkte verbaut sind, im Gebäude, in der Produktionsumgebung etc., arbeitet der Betreiber mit dem jeweiligen Hersteller oder einer vorgeschalteten Support-Organisation zusammen.
Hinzu kommt, dass die Lebensdauer eines Gebäudes das der verbauten Produkte oft weit überschreitet. Das bedeutet, dass man sich nicht nur einmal mit der Herstellerwahl beschäftigen, sondern auch einplanen muss, dass dieser sowie sämtliche Produkte aller Wahrscheinlichkeit nach ausgetauscht werden müssen. Selbst ohne Wechsel der Produktentscheidung ist aufzupassen: Je stärker IoT in die Gebäudestruktur integriert ist, umso ungünstiger ist es, wenn bei vorzeitigem Defekt oder normalem Verschleiß immer gleich ganze Baugruppen ausgetauscht werden müssen.
Warum eine ganze „smarte Lampe“ tauschen müssen, wenn nur das Leuchtmittel das Ende seiner Lebensdauer erreicht hat? Das ist weder nachhaltig noch betriebstechnisch „smart“. Hier muss man schon bei der Produktauswahl klare Ziele haben, entsprechend aufpassen und eventuell sogar aus derartigen Gründen bestimmte Hersteller im konkreten Fall ausschließen. Natürlich nützt eine solch durchdachte Produktauswahl nichts, wenn es zum Zeitpunkt des Leuchtmittelwechsels keine entsprechende Ersatz-Hardware mehr vom Hersteller gibt.
Das führt uns zu dem nächsten Punkt, der im IoT-Umfeld besonders wichtig ist: durchdachte Produktauswahl und durchdachte Verträge mit Herstellern und Dienstleistern.
Idealerweise werden als Teil der Verträge schon Service Levels mittels Service Level Agreement (SLA) definiert. Dieses klärt typischerweise insbesondere folgende Punkte:
- Was ist durch den Dienstleister/Hersteller bereitzustellen?
- Wie gut sollen die Leistungen sein?
- Was ist überhaupt „gut“, was ist „nicht gut genug“?
- Braucht man Pönalen bzw. helfen diese?
Es werden also Kennzahlen benannt, die diese Werte definieren, als Key Performance Indicators (KPIs) zur Bewertung der Qualität von Prozessen und Service Level Objectives als Parameter zu einzelnen, aber schon für sich genommen wichtigen Qualitätsaspekten.
Darüber hinaus sollte bei der Herstellerauswahl geprüft werden, ob es einen Hersteller-Support gibt und zu welchen Zeiten dieser erreichbar ist. Auch nachts oder am Wochenende müssen, je nach Wichtigkeit eingesetzter Technologie in der Einsatzumgebung, Ansprechpartner erreichbar sein. Zudem ist der Standort des Herstellers bzw. des Support-Partners entscheidend. Wenn dieser weite Strecken zurückzulegen hat, können im SLA definierte, wesentliche Zeitschranken vermutlich nicht eingehalten werden.
Insbesondere die genannten Anforderungen an Hersteller und Dienstleister sollten schon vor dem Auswahlverfahren definiert werden. So können diese im Auswahlprozess frühestmöglich geklärt werden, und es gibt keine bösen Überraschungen nach Vertragsabschluss, zumindest nicht in dieser Hinsicht.
Changes und Deployment
Ein typischer Change beinhaltet Aufgaben wie eine Änderung von Gerätekonfigurationen, einen Austausch oder die Installation eines Updates. Derartige Eingriffe werden in der klassischen IT-Umgebung bevorzugt außerhalb der Nutzungszeit durchgeführt, um Beeinträchtigungen bei der produktiven Nutzung zu vermeiden. Im Anschluss wird getestet, ob alles so funktioniert wie geplant. Allerdings gestalten sich alle entsprechenden Aspekte dieses Abschnittes als schwierig, wenn man in modernen Systemen bekannte Methoden aus dem IT-Betrieb übernehmen möchte.
Änderungen kann der Betreiber an vielen smarten Komponenten nicht mehr ohne Garantieverlust seitens des Herstellers durchführen. Es ist durchaus möglich, dass Komponenten aus der Support-Pauschale fallen, wenn eigene Änderungen durchgeführt werden und das Produkt somit nicht mehr dem Originalzustand entspricht. Sprich, hier ist oft wieder direkt der Hersteller oder ein autorisierter Partner involviert, wenn es um Änderungen an der Hard- oder Software geht.
Der nächste Punkt ist der Austausch von Geräten, z.B. als präventive Wartungsmaßnahme: Tauscht der Betreiber in IoT-Umgebungen wirklich in jedem Fall noch selbst Geräte aus? Ist das für ein bestimmtes Produkt ohne Spezialkenntnisse sinnvoll möglich? Ist es vom Hersteller so vorgesehen? Benötigt man spezielle Hilfsmittel, deren Anschaffung oder Anmietung unwirtschaftlich erscheint? Mit jedem neuen Produkttyp können sich diese Fragen neu stellen.
Nehmen wir Sensoren als einfaches Beispiel: In einem Gebäude sind 3500 Sensoren verbaut und nach und nach werden die Batterien leer. Geht der Betreiber selbst durch das Gebäude und tauscht sämtliche Batterien aus? Es ist wohl sinnvoller, diese Aufgabe an ein Sub-Unternehmen abzugeben, da ansonsten einige Mitarbeiter ganztägig beschäftigt sind und womöglich mangels Übung länger brauchen oder gar Schäden anrichten können.
Ein anderes Beispiel wäre der smarte Teppich, der im laufenden Betrieb nur schwer auszutauschen ist und sei der Defekt noch so groß. Natürlich gibt es auch Komponenten, die problemlos vom Betreiber, oder zuständigen Dritten, getauscht werden können. Allerdings sollte vorab klar sein, bei welchen Technologien dies möglich ist und bei welchen nicht und vor allem, wie in beiden Fällen vorzugehen ist (und das schon vor Auftreten eines entsprechenden Defektes).
Updates wurden in klassischen IT-Umgebungen häufig vom Hersteller bereitgestellt und vom Betreiber installiert. Auch hier muss man umdenken. Das kennen Sie vielleicht aus dem privaten Umfeld: Sie haben smarte Produkte verbaut und steuern diese per App. Wenn Sie die App öffnen, bekommen Sie (je nach Einstellung) eine Meldung, dass ein Update für Ihre Komponenten bereitsteht oder sogar schon installiert wurde. Auch für den Betreiber von verschiedensten IoT-Produkttypen gibt es hier oft wenig Handlungsspielraum.
Zudem muss über produktspezifische Maßnahmen sichergestellt werden, dass ein Rollback möglich ist, sollte ein solches Update nicht die gewünschten Resultate bringen. Eine Einbindung in interne Lösungen wie die Backup-Infrastruktur der Büro-IT ist bei einem nach außen offenen IoT-Netz nicht unproblematisch, selbst wenn das IoT-Produkt so etwas technisch unterstützt.
Ein weiterer Prüfpunkt für die Übertragbarkeit bewährter IT-Betriebsansätze auf das IoT ist der Zeitpunkt des Change. Klassisch „nach Feierabend“ ist in smarten Gebäuden schwierig realisierbar. Smarte Gebäude sind ständig online, müssen dauerhaft überwacht werden können und werden nachts meist nicht heruntergefahren oder neu gestartet. Automatisierte Updates funktionieren oft auf Basis fest eingestellter Check- und Pull-Zeitpunkte. Eine hier einmal getroffene Entscheidung will gut gewählt sein, da eine Änderung üblicherweise einen Configuration Change darstellt und somit einen eigenen Roll-out benötigt.
Je nach Art eines Produktes und eines dazu zu gestaltenden Change muss also individuell geprüft werden, welche Auswirkungen dieser hat und welche Voraussetzungen zu erfüllen sind, um einen reibungslosen Verlauf zu ermöglichen. Ein Update der Leuchtmittel ist vermutlich am helllichten Tag sinnvoller als in der Nacht, wenn diese gebraucht werden. Die Aufzüge sind hingegen nachts vermutlich weniger frequentiert als tagsüber, und somit bietet sich hier das Update nachts an. Generell sollte der Change auf keinen Fall unkontrolliert flächendeckend ausgerollt werden. Das ist allerdings keine Besonderheit von IoT-Umgebungen, sondern hat auch in klassischen IT-Umgebungen Normalität zu sein.
Der Abschluss eines jeden Change in der IT sollte prinzipiell darin bestehen, die geänderten Komponenten zu testen. Funktioniert die Komponente wie geplant? Funktionieren die verbundenen Komponenten ebenfalls noch so wie erwartet? Wer testet so etwas in einem smarten Gebäude, beispielsweise nach einem Update der oben angesetzten 7000 Leuchtmittel?
Für Tests vor der Durchführung eines Change lohnt es sich auf jeden Fall, eine Testumgebung aufzubauen. Abbildung 4 zeigt ein solches Demozentrum, wie es in mehreren unserer Projekte bewusst schon während der Planungsphase errichtet wurde.
Die Testumgebung hat erfahrungsgemäß mindestens zweierlei wichtigen Nutzen:
So war es in der Planungsphase bereits möglich, potentielle Komponenten auf Kompatibilität untereinander zu testen, bevor sie flächendeckend verbaut wurden. Als die Komponenten dann anschließend installiert waren, konnte dieses Demozentrum weiterhin als Testbasis genutzt werden. Der Change konnte in kleinstem Umfeld geprüft werden. Kam es hier schon zu Problemen, konnte ein entsprechender Roll-out verhindert werden. Natürlich verspricht auch eine solche Testumgebung keine reibungslosen Abläufe, verringert aber deutlich das Fehlerpotential.
Asset Management und Asset Monitoring
Ein sehr spannendes Thema in Bezug auf IoT-Produkte ist das Asset Management und das Asset Monitoring. IoT-Komponenten werden gerne zur Verwaltung des Lebenszyklus von Assets eingesetzt. Man kann mit Sensoren, Kameras etc. wunderbar andere Geräte beobachten und verfolgen, um so Defekte vorauszusagen (predictive maintenance) oder auch einfach nur darzustellen, in welchem Raum sich die überwachten Assets gerade befinden.
Der Punkt, der dabei meistens unbeachtet bleibt ist: IoT-Komponenten sind Assets! Wer überwacht die Überwacher? Wer sagt mir, wann ein Sensor kaputtgeht und wo sich dieser dann befindet? Auch bei IoT-Komponenten sollte der Lebenszyklus verwaltet werden, und zwar von der Bereitstellung, der Authentisierung von freigegebenen Geräten über die Konfiguration (wenn möglich) bis hin zu Monitoring, Wartung und Updates. Es gibt hier entsprechende Software zum sogenannten IoT-Device-Management. Allerdings ist diese nur bedingt zuverlässig.
Abbildung 4: Demozentrum für smarte Gebäude
Die größte Schwachstelle der IoT-Komponenten liegt darin, dass sie oft sehr kleine und einfache Geräte sind, die nach dem Prinzip „fire and forget“ funktionieren. Sie messen also Werte und senden diese an eine definierte Adresse. Zuhören und auf Befehle reagieren können sie in aller Regel nicht. Das würde zu viele Ressourcen kosten, die in solchen Sensoren eh meist begrenzt vorhanden sind.
Wie überwacht man solche Geräte, die nicht antworten können? Aus dem Bauch heraus würde man vielleicht von Folgendem ausgehen: Im Normalzustand sendet das Gerät kontinuierlich Daten, wenn es das nicht mehr tut, ist es defekt.
Diese Reaktion des Sensors kann aber unglücklicherweise auch eine Vielzahl von Ursachen haben: Die Hardware ist tatsächlich defekt, es gibt einen Bug in der Software, der Sensor hat vorübergehend keine Netzverbindung mehr, Paketkollisionen entstehen (was gerade bei Funkverbindungen wahrscheinlich ist), die Batterie ist leer etc.
Egal welcher der Ursachen dann die zutreffende ist, es folgt eine weitere Hürde: Wo befindet sich das Gerät? Ist es fest montiert oder vielleicht sogar in Bewegung, um ein anderes Asset zu tracken?
Beim Asset Monitoring von Sensoren kann ein dokumentierter Kontext betriebliche Abläufe erheblich vereinfachen. Nehmen wir an, Sie haben wertvolle Assets in Ihrem Unternehmen (Prototypen, Testequipment, etc.). Diese Assets tracken Sie mit Sensoren, um immer nachvollziehen zu können, wo sich diese befinden. Nachts werden die Assets in den Safe geschlossen, eben weil sie so wertvoll sind. Was heißt das jetzt für den Betrieb?
Tagsüber lassen sich die Assets problemlos tracken, Sie wissen genau, wo sich welche Komponente befindet. Ab einer undefinierten Uhrzeit bekommt der Betreiber, oder der zuständige Dritte, allerdings permanent Fehlermeldungen: Die Sensoren senden nicht mehr. Anstatt jetzt jeden der oben genannten Punkte zu prüfen und jede Nacht Suchtrupps loszuschicken reicht es, den Kontext zu den Sensoren zu dokumentieren: Nachts sind die Assets im Safe, daher gibt es kein Signal und das ist in Ordnung. Dass Sie nachts kein Signal empfangen impliziert zwar nicht, dass Ihre Assets sicher im Safe liegen, ist allerdings auch kein Grund, Alarm zu schlagen.
Sie merken, die Problematik des Asset Management bzw. Asset Monitoring kann schnell ein betriebliches Chaos werden. Es ist sinnvoll, für die jeweils verwendete IoT-Technologie eine abgestimmte Dokumentation zu erstellen, die den Kontext berücksichtigt, in welchem diese verwendet wird.
Betrieb moderner I(o)T-Systeme: organisieren statt improvisieren!
Anhand der oben genannten Beispiele haben wir gesehen, dass sich der IoT-Betrieb vom IT-Betrieb unterscheidet. Es gibt neue Technologien und neue Zusammenhänge, die betrachtet werden müssen, und andere Parteien werden in den Betrieb miteinbezogen. Wie kann es dennoch gelingen, den Überblick zu behalten und den Betrieb eines modernen IoT-Systems zu organisieren, anstatt nur fallweise zu improvisieren?
Der erste Schritt ist, möglichst früh mit der Organisation zu beginnen. Das bedeutet am besten schon mit einer sorgfältigen Produktauswahl. Beispielsweise hilft eine Anforderungsanalyse mit Muss- und Kann-Kriterien. Dabei werden unter anderem folgende Punkte definiert: Was muss das neue Produkt zwangsläufig erfüllen? Wozu muss dieses kompatibel sein? Auf welche Funktionen kann nicht verzichtet werden? Welche Funktionen sind zwar „nice-to-have“, aber nicht zwingend notwendig?
Erstellt man daraus nun einen Kriterienkatalog, der diese Anforderungen übersichtlich darstellt und eine Leistungsbeschreibung, die die Zusammenhänge definiert, können die Produkte zum Beispiel ausgeschrieben werden. So können vergleichbare Angebote abgefragt und schon bei der Anschaffung Punkte wie Kompatibilität und Sicherheit berücksichtigt werden.
Ähnliche Schritte helfen ebenfalls bei der Dienstleisterwahl. Hier sollte definiert werden, welchen Anforderungen der Dienstleister nachkommen soll und welchen er nachkommen muss. Diese Leistungen können entsprechend ausgeschrieben werden. Ist ein passender Dienstleister gefunden, helfen Verträge samt definierter SLAs, damit abgestimmte Regelungen eingehalten werden und diese somit eine Vertragsgrundlage bilden. Sollten Pönalen bei Nichteinhaltung der Regelungen für zielführend erachtet werden, sind diese ebenfalls vorab zu definieren.
Wenn dann Produkte eingekauft wurden, die den Anforderungen entsprechen und vielleicht sogar ein paar „nice-to-have“-Kriterien erfüllen und zudem ein fähiger Dienstleister eingestellt wurde – reicht das alles aus, um einen organisierten Betrieb aufrechtzuerhalten? Nein, wir haben oben schon gesehen, dass einige Regelungen und Prozesse dokumentiert werden müssen. Produkttypen sollten einzeln betrachtet werden, anstatt standardisierte Vorgehensweisen auf sämtliche IoT-Produkte anzuwenden.
Um auch langfristig den angestrebten Nutzen aus den vorhandenen Ressourcen ziehen zu können, helfen Betriebsunterlagen, die genau definieren, wie speziell in Ihrem Unternehmen/Gebäude der I(o)T-Betrieb definiert und geregelt ist.
Wie gestaltet man nun Betriebsunterlagen für den IoT-Betrieb, wenn für jede Technologie angepasste Regelungen definiert werden müssen?
Ein möglicher Ansatz wäre eine Aufteilung der Unterlagen: Beispielsweise werden ein Betriebskonzept und verschiedene Betriebshandbücher erstellt. Das übergeordnete Betriebskonzept beschreibt die groben Zusammenhänge des Netzes. Es definiert, wie die einzelnen Bereiche verknüpft sind und bietet insbesondere eine Vorlage für die Struktur der zugehörigen Betriebshandbücher.
Letztere können dann lösungsspezifisch erstellt werden, d.h. es werden jeweils die tatsächlich verbauten Produkte betrachtet. Dank des vorhandenen Konzeptes sind die Handbücher standardisiert aufgebaut, was das Wiederfinden von Informationen erleichtert und sicherlich notwendige Verweise und Bezüge vereinfacht. Bei Austausch oder nur Änderung einer Lösung reicht es aus, das jeweilige Betriebshandbuch anzupassen. Das gilt nicht für alle weiteren Betriebsunterlagen.
Fazit
Es wird deutlich, dass der Betreiber von IoT-Produkten heutzutage auf eine fachübergreifende Zusammenarbeit zurückgreifen muss. Sei es mit den Herstellern, mit der Abteilung für Sicherheit, mit der Abteilung für Datenschutz, Technikern etc. Die modernen Komponenten erfordern Spezialisten. Es ist wahrscheinlich nicht möglich, einen Spezialisten für alle verwendeten Technologien zu finden.
Der Abstimmungsaufwand schein demnach für den Betreiber erst einmal größer geworden zu sein. Allerdings ist dieser Aufwand auch notwendig und zahlt sich aus, wenn man im laufenden Betrieb weiß, wo Ansprechpartner und Lösungen zu finden sind, wie Technologien behandelt werden und wie der laufende Betrieb weitestgehend reibungslos ablaufen kann. Seien wir ehrlich – ganz ohne ungeplante Herausforderungen wird es niemals möglich sein. Dennoch kann man sich darauf vorbereiten, indem Betrieb organisiert geplant wird und solche Fragen, wie oben beschrieben, frühzeitig gestellt werden.
Wer bei der Produkt- und Herstellerwahl früh anfängt, ist im Nachhinein besser vorbereitet. Eine wirksame Nachbesserung ist in den meisten smarten Umgebungen kaum mehr möglich. Wenn die 7000 Lampen in Ihrem Gebäude verbaut sind, wäre ein Austausch aufgrund einer nicht beachteten Kompatibilität mit hohen Kosten und hohem Aufwand verbunden.
Darüber hinaus ist der Betrieb von IoT-Systemen nichts völlig Neues. Einzeln betrachtet sind es viele Herausforderungen und Lösungen, die bisher auch schon bestanden haben. Neu ist hingegen, dass jede Technologie separat betrachtet werden sollte. Es gibt vermutlich keine globale Lösung, die für alle Technologien funktioniert, sondern es wird fallweise entschieden, welche Strategien zielführend sind.
