GEFMA 928: White Paper IoT im Facility Management

Eine gemeinsame Sprache zwischen FM, IT, OT (Operational Technology), Dienstleistern und Management schaffen. Einheitliche Begriffe vermeiden Missverständnisse in Projekten und Verträgen.

• IoT/IIoT: Das Internet der Dinge (IoT) verbindet physische Objekte über Netzwerke mit digitalen Diensten. In der Industrie wird von Industrial IoT (IIoT) gesprochen.

• Sensorik und Aktorik: Sensoren messen physikalische Größen (z. B. Temperatur, CO₂, Druck). Aktoren wirken auf das System ein (z. B. Stellventile, Motoren). IoT‑Sensoren erfassen Daten und übertragen sie in Echtzeit an zentrale Plattformen. Laut Planon können batteriebetriebene Sensoren dank energiesparender Funktechniken bis zu zehn Jahre betrieben werden, wobei sie typische Messgrößen wie Temperatur, Feuchte, Luftqualität oder Belegung erfassen.

• Gateway/Edge: Gateways bündeln Daten von Sensoren, übersetzen Protokolle und stellen Verbindungen in übergeordnete Netze her. Edge‑Geräte übernehmen Vorverarbeitung (Filterung, Normierung) und entlasten zentrale Systeme.

• Plattform: Eine IoT‑Plattform verwaltet Geräte, nimmt Daten entgegen, modelliert sie und stellt sie für Analysen, Regeln und Integrationen bereit.

• Datenpunkte/Events: Einzelne Messwerte oder Ereignisse (z. B. Grenzwertüberschreitungen) mit Zeitstempel. Sie sind mit Assets oder Räumen verknüpft und bilden die Grundlage für Workflows.

• Telemetrie vs. Bestandsdaten: Telemetrie sind kontinuierlich gesammelte Messdaten aus dem Betrieb. Bestandsdaten (Stammdaten) stammen aus CAFM‑Systemen oder BIM‑Modellen.

• Monitoring vs. Steuerung: Monitoring erfasst Zustände; Steuerung löst aktive Handlungen aus. Nicht jede IoT‑Lösung muss aktorisch eingreifen; oft reicht die Übertragung von Alarmen und die manuelle Bearbeitung.

• Alarm vs. Ticket: Ein Alarm signalisiert eine Abweichung (z. B. hohe Temperatur). Ein Ticket in einem CAFM‑System initiiert einen Arbeitsauftrag.

• Messwert vs. prüffähiger Nachweis: Einige Daten dienen als Echtzeitinformation (z. B. Raumtemperatur); andere müssen revisionssicher archiviert werden, etwa für Compliance‑Nachweise.

• Datenquelle vs. „Single Source of Truth“: Datenquellen können vielfältig sein (Sensor, Zähler, BMS). Für Entscheidungen und Audits muss jedoch eine führende Datenbasis definiert werden.

• Data Owner/Steward: verantwortlich für Datenqualität und Zugriffsrechte.

• Betreiber/Serviceprovider: führt die technischen Services aus und nutzt IoT‑Daten zur Steuerung.

• Plattformbetreiber: verantwortet Betrieb, Sicherheit und Weiterentwicklung der IoT‑Plattform.

• Informationssicherheits‑ und Datenschutzrollen: stellen sicher, dass Anforderungen an IT‑/OT‑Sicherheit und Datenschutz eingehalten werden.

Welche Begriffe und Definitionen sind in Verträgen und SLA verbindlich? Welche Begriffe führen erfahrungsgemäß zu Missverständnissen zwischen IT, OT und FM und müssen präzise definiert werden?

Entwicklung einer Referenzarchitektur, die Planung, Beschaffung, Integration und Betrieb leitet. Laut der Untersuchung „Smart Buildings im Internet der Dinge“ der Technologiestiftung Berlin besteht die IoT‑Architektur aus drei Haupt­ebenen: dem Gebäude‑/Feldebene, der Übertragungsebene und der Managementebene. Diese Struktur lässt sich auf FM‑Prozesse übertragen.

• Feldgeräte/Sensoren: Messen Zustände (z. B. Temperatur, Energie, Belegung). Im Berlin‑Bericht wird unterschieden zwischen passiven Sensoren und aktiven Controllern; erstere erfassen Zustände, letztere beeinflussen das System.

• Konnektivität: Kabelgebundene (Ethernet, Modbus) und drahtlose Netze (WLAN, LoRaWAN, NB‑IoT, Bluetooth). Die richtige Wahl hängt von Reichweite, Bandbreite, Energiebedarf und Gebäudestruktur ab. Die Studie warnt vor offenen Funk‑Schnittstellen, da sie Sicherheitsrisiken bergen. Für remote Wartung werden VPN‑Tunnel empfohlen, um direkten Zugriff zu begrenzen.

• Edge/Gateway: Lokale Datenaggregatoren, die Protokolle (BACnet, M‑Bus, KNX, Modbus) übersetzen, Daten normalisieren und an die Plattform weitergeben. Beispiel: In einem Smart‑Building‑Projekt von Phoenix Contact normalisieren Inline‑Controller Daten aus Sensoren und Aktoren und geben sie an die Emalytics‑Plattform weiter.

• IoT‑Plattform: Zentrales System zur Geräteverwaltung, Datenaufnahme, Normalisierung, Speicherung, Regeldefinition (Event‑Engine), Analyse und Schnittstellen zu CAFM, BMS oder ERP.

• Integrationsebene: API‑basierte Kopplung zu CAFM/IWMS, Gebäudeleitsystem, Energiemanagement, ERP. Hier werden Daten in Workflows überführt (Alarm → Ticket).

• Analytics/Regelwerke: Algorithmen für Zustandsbewertung, Grenzwertüberwachung und predictive Maintenance. Phoenix Contact nutzt z. B. Daten aus Blockheizkraftwerken, um Anomalien zu erkennen und rechtzeitig Wartung auszulösen.

• Frontends/Dashboards: Unterschiedliche Nutzeroberflächen (Leitwarte, Objektleitung, Management) mit KPI‑Darstellungen, Alarmübersichten und Berichts‑Widgets.

Der Datenfluss verläuft von der Datenerfassung über Normalisierung und Speicherung zur Ereignislogik und schließlich zur Übergabe an Workflow‑Systeme. Rückmeldungen aus der Ticket‑Abwicklung aktualisieren den Datensatz im CAFM.

Verfügbarkeit, Latenz, Skalierbarkeit, Wartbarkeit (inkl. Device‑Lifecycle‑Management), Updatefähigkeit und „Security‑by‑Design“. Die Berlin‑Studie weist darauf hin, dass nicht jede Messgröße in Echtzeit erfasst werden muss; Messintervalle sollen dem Anwendungsfall entsprechen.

Wo endet die Verantwortung der OT und wo beginnt die der IT? Welche Integrationspunkte stellen kritische Pfade dar (z. B. Alarm → Ticket → Auftrag)? Welche Architekturentscheidungen (Plattform, Datenmodell, Identifikatoren) haben langfristige Auswirkungen?

Den digitalen Zwilling als betriebliche Fähigkeit verstehen, die Zustands‑ und Nutzungsdaten in den Kontext des Gebäudes bringt. GEFMA betont, dass der digitale Zwilling nicht lediglich ein räumliches Abbild ist, sondern den aktuellen Zustand eines Gebäudes aus Sensorik und Vernetzung ableiten muss. Nur so lassen sich fundierte Entscheidungen treffen.

• Twin‑Objekte: Räume, Anlagen, Komponenten, Zähler und Nutzerzonen erhalten eindeutige Identifikatoren (z. B. aus dem CAFM). Hierarchien (Gebäude → Etage → Raum → Objekt) müssen definiert werden.

• Betriebsmehrwert: Ein kontinuierlich aktualisierter digitaler Zwilling ermöglicht zustandsbasierte Instandhaltung, Simulation von Szenarien (z. B. Energieeinsparung), ESG‑Reporting und vorausschauende Portfoliosteuerung. Ein Beispiel aus der Praxis zeigt, dass digitale Zwillinge durch 3D‑Scanning und BIM erstellt und durch Echtzeit‑Sensorik (z. B. zur Fensterstellung oder Raumtemperatur) angereichert werden. So können Fernverwaltung, virtuelle Begehungen, ortsunabhängige Planungen und CO₂‑Reduktion ermöglicht werden.

• Mindestanforderung: Aktuelle und valide Daten sind unerlässlich. Die Synchronisation zwischen Bestandsdaten (CAFM/BIM) und Telemetrie (IoT) muss geregelt sein, um Widersprüche zu vermeiden.

Welcher „Twin‑Reifegrad“ wird benötigt (reiner Datenzwilling vs. funktionsfähiger Betriebszwilling)? Welche Daten sind betriebsentscheidend und müssen kontinuierlich erfasst werden? Wie wird die Datenqualität über den Lebenszyklus gesichert?

Eine Use‑Case‑Landkarte entwickeln, die Anwendungsfelder priorisiert und deren Nutzenbeiträge messbar macht. GEFMA benennt Anwendungsfelder wie Flächenmanagement, Betriebsoptimierung, User‑Experience und nachhaltige Unternehmensführung.

• Cluster und Priorisierung: Use‑Cases werden nach Wertbeitrag, Umsetzbarkeit, Risiko und Datenverfügbarkeit priorisiert. Quick‑Win‑Anwendungen (z. B. Zählerfernauslesung) können kurzfristig Kosten senken. Strategische Anwendungen (z. B. digitale Zwillinge für gesamte Portfolios) erfordern mehr Planung.

• Zuordnung zu FM‑Prozessen: Die Use‑Cases lassen sich den Prozessen Betrieb, Instandhaltung, Flächen‑/Belegungsmanagement, Energiemanagement, Nutzerkommunikation und Reporting zuordnen.

• KPI‑Systematik: Für jeden Use‑Case müssen Baselines, Zielwerte, Messmethodik und Verantwortlichkeiten festgelegt werden. Beispiele sind Energiekennzahlen, Raumbelegungsgrade oder Servicezeiten.

Welche Use‑Cases liefern kurzfristige Ergebnisse? Welche Daten sind dafür zwingend erforderlich? Welche FM‑Prozesse müssen angepasst werden (z. B. Störungsmanagement, Reinigungsplanung)?

Ziel dieses Feldes ist es, Umweltwirkungen im Gebäudebetrieb zu realisieren – insbesondere Energie‑ und Ressourceneinsparungen sowie Emissionsreduzierung. IoT‑Lösungen unterstützen die Steuerung, Nachweisfähigkeit und das Reporting.

• Belegungs‑ und Nutzungsgrade: Präsenz‑ und Bewegungssensoren liefern Informationen über die tatsächliche Nutzung von Räumen oder Zonen. Mithilfe von Belegungsdaten können Soll‑Ist‑Vergleiche zur Kapazitätssteuerung durchgeführt werden. Planon weist darauf hin, dass IoT‑Sensoren in der Lage sind, Echtzeitdaten über Belegung, Temperatur und Luftqualität zu liefern, wodurch Flächenmanagement, bedarfsorientierte Reinigung und Komfortsteuerung verbessert werden.

• Datengetriebene Services: Basierend auf Belegungsdaten lassen sich Reinigungsdienste bedarfsgerecht planen. InCaTec beschreibt Softwarelösungen, bei denen Sensoren bedarfsgerechte Reinigung und Budgettracking ermöglichen und für jeden Raum eine nachvollziehbare Historie bereitstellen.

• Governance: Datenschutz und Anonymisierung sind essenziell, da Belegungsdaten potenziell personenbezogen sind. Betriebsvereinbarungen und Einbindung des Betriebsrats sind erforderlich. Transparente Nutzerkonzepte fördern Akzeptanz.

Welche Flächenkennzahlen (m²‑Auslastung, Desk‑to‑Employee‑Ratio) sind steuerungsrelevant? Wie werden aus Messwerten belastbare Managemententscheidungen abgeleitet (z. B. Flächenkonsolidierung)? Welche Schutzmechanismen (Anonymisierung, Zugangskontrolle) sind notwendig?

• Zustandsüberwachung technischer Anlagen: Condition‑Monitoring ermöglicht es, Abweichungen oder Anomalien frühzeitig zu erkennen. Phoenix Contact nutzt Daten aus 27 Inline‑Controllern, die Sensor‑ und Aktorinformationen normalisieren und an die IoT‑Plattform Emalytics übergeben. Dadurch können z. B. Bauteile in Blockheizkraftwerken vor Ausfall ausgetauscht werden.

• Energie‑ und Betriebsführung: Sensorik in Heizungs‑, Lüftungs‑ und Klimaanlagen sowie in Beleuchtungssystemen ermöglicht bedarfsorientierte Regelstrategien. Die Emalytics‑Plattform koppelt Energieerzeugung, Verbrauch und Speicher, nutzt Lastmanagement zur Vermeidung von Spitzenlasten und verwendet historische Daten für Prognosen. Präsenzsensoren können HVAC und Beleuchtung automatisch anpassen; Planon verweist auf Studien, die Energieeinsparungen von über 38 % durch intelligente HVAC‑ und Beleuchtungssysteme zeigen.

• Nachweisfähigkeit: Für Audit‑ und Compliance‑Zwecke müssen Ereignisse revisionssicher dokumentiert werden. Sensordaten können ESG‑Berichte unterstützen, indem sie Energieverbräuche oder Emissionswerte automatisch erfassen und dokumentieren.

Welche Anlagen oder Komponenten sind kritisch hinsichtlich Verfügbarkeit, Risiko oder Kosten? Welche Regeln lösen welche Aktionen aus (Alarm, Ticket, Steuerung)? Wie werden Einsparungen und Qualitätsgewinne methodisch nachgewiesen?

Dieses Anwendungsfeld zielt darauf ab, die Nutzer‑ und Arbeitsplatzqualität zu verbessern. IoT‑Lösungen können gesundheitliche, komfort‑ und sicherheitsrelevante Aspekte überwachen.

• Indoor Environmental Quality: Sensoren erfassen Luftqualität (CO₂, TVOC), Temperatur, Luftfeuchte, Schallpegel oder Licht. Die Daikin IAQ‑Sensoren messen bis zu 15 Parameter wie Temperatur, relative Luftfeuchte, Druck, Schallpegel, Feinstaub, elektromagnetische Felder, CO₂ und TVOC. Überschreiten die Messwerte definierte Grenzwerte, werden Warnungen und Reaktionen ausgelöst. Gute Luftqualität ist für die Gesundheit entscheidend; hohe CO₂‑Konzentrationen führen zu Kopfschmerzen, Leistungsabfall und erhöhter Aerosolbelastung.

• Nutzerkommunikation: Benutzerfreundliche Apps oder Dashboards informieren über Raumklima, Belegung oder Störungen. Das Build‑Ing.‑Magazin betont, dass die Integration von Systemen und Daten eine transparente Kommunikation mit den Nutzern ermöglicht und die Interaktion zwischen Gebäudebetrieb und Nutzern optimiert.

• Akzeptanzmanagement: Klare Regelungen zur Datennutzung und transparente Informationsprozesse stärken die Akzeptanz. Datenschutz und Anonymisierung sind auch im sozialen Kontext relevant.

Welche Social‑Ziele stehen im Vordergrund (Gesundheit, Komfort, Sicherheit, Nutzererlebnis)? Wie lässt sich die User‑Experience anhand von Service Level Agreements (SLA) oder Experience Level Agreements (XLA) operationalisieren? Welche Kommunikations‑ und Eskalationsprozesse sind erforderlich?

• Verantwortungsmodell: Es müssen Data‑Owner und Plattformbetreiber definiert werden. Rollen für Informationssicherheit und Datenschutz legen Zugriffsrechte fest und überwachen die Einhaltung gesetzlicher Vorgaben (z. B. DSGVO).

• Reporting und Audit: KPIs (z. B. Energiekennzahlen, Betriebsstunden) müssen definiert werden, um interne und externe Berichtspflichten zu erfüllen. Ereignishistorien sind revisionssicher zu speichern.

• Risikomanagement: Technische und organisatorische Risiken wie Systemausfälle, Datenintegrität, Vendor‑Lock‑in und Cyberrisiken werden bewertet. Die Berlin‑Studie warnt vor offenen Funk‑Schnittstellen und empfiehlt, die Fernwartung über sichere VPN‑Verbindungen zu realisieren.

Wer ist Daten‑ und Systemverantwortlicher je Datenkategorie? Welche Mindestanforderungen gelten für Audit und Reporting? Welche Governance‑Entscheidungen (z. B. Plattformwahl, Datenschutzprinzipien) müssen vor der Skalierung festgelegt werden?

Eine IoT‑Plattform ist ein zentrales System, das Geräte verwaltet, Daten entgegennimmt, sie modelliert und analysiert, Regeln definiert und Integrationen bereitstellt. Das White Paper betont, dass IoT‑Plattformen auch die Basis für digitale Zwillinge bilden. Ihre Leistungsbausteine umfassen Geräteverwaltung (Onboarding, Authentifizierung), Datenaufnahme (Ingestion), Datenmodellierung und Tagging, Regel‑ und Ereignislogik, Schnittstellen (APIs) zu externen Systemen sowie Visualisierung und Sicherheit.

• Ingestion: Annahme von Datenströmen aus Sensoren und Gateways. Daten werden normalisiert und mit Metadaten (Zeitstempel, Asset‑ID) versehen.

• Processing: Verarbeitung der Daten durch Regelwerke, Anomalieerkennung und Aggregation. Edge‑Funktionen entlasten das zentrale System.

• Storage: Speicherung in Zeitreihen‑Datenbanken für Telemetrie sowie relationalen oder dokumentenbasierten Datenbanken für Stammdaten.

• Analytics: Analyse‑Module liefern Reports, Vorhersagen (Predictive Maintenance) und Optimierungsempfehlungen. Die Emalytics‑Plattform von Phoenix Contact verbindet Energieerzeugung, Verbrauch und Speichermanagement, nutzt Lastmanagement und analysiert historische Daten.

• API‑Layer: Schnittstellen (REST, MQTT, OPC UA) erlauben den Datenaustausch mit CAFM, BMS, ERP und anderen Systemen.

• Identity/Security: Verwaltung von Nutzer‑ und Geräteidentitäten, Rollen‑ und Berechtigungskonzepten, Zertifikaten und Schlüsselmanagement. Die Berlin‑Studie fordert, externe Zugriffe und Update‑Mechanismen abzusichern.

• Onboarding: Registrierung neuer Geräte und Zuordnung zu Assets/Räumen.

• Updates: Verteilung von Firmware‑ und Softwareupdates über sichere Kanäle.

• Monitoring: Überwachung der Konnektivität und Datenqualität; Alarmierung bei Ausfällen.

• Incident und Problem Management: Bearbeitung von Störungen und strukturierten Root‑Cause‑Analysen nach ITIL‑Prinzipien.

• Komplexe, vollumfängliche Plattformen (horizontal): Skalierbare Plattformen mit breitem Funktionsspektrum, die verschiedene Branchen adressieren und eine flexible Datenmodellierung ermöglichen. Sie unterstützen häufig Multi‑Tenant‑Betrieb und horizontale Skalierung. Beispiele sind Cloud‑basierte Plattformen internationaler Anbieter; in Deutschland sind u. a. offene Standards wie BACnet, Modbus oder OPC UA wichtig.

• Funktionsspezifische Plattformen (vertikal): Plattformen für bestimmte Anwendungsfelder wie Energiemanagement, Flächenmanagement oder Raumkomfort. Sie bieten Domänenlogik, aber begrenzte Erweiterbarkeit.

• Open‑Source‑Systeme: Plattformen, deren Quellcode offen ist und die individuell anpassbar sind. Die Berlin‑Studie weist darauf hin, dass zahlreiche Plattformtypen existieren und auch Open‑Source‑Lösungen verfügbar sind. Open‑Source‑Plattformen bieten Transparenz, aber der Betreiber muss Wartung und Sicherheit eigenständig gewährleisten.

Die Auswahl einer Plattform erfolgt anhand einer Entscheidungsmatrix mit Kriterien wie Skalierbarkeit, Integrationsfähigkeit, Datenmodell (Tagging), Betriebsmodell (Cloud vs. On‑Premises), Sicherheit, Kosten und Exit‑Fähigkeit.

Ein sauberes Datenmodell ist die Grundlage für Analysen und Workflows. Metadaten (Messgröße, Einheit, Standort, Asset‑ID) und Semantik/Tags erleichtern die Zuordnung und Aggregation. Datenqualitätsmechanismen (Plausibilitätsprüfungen, Wertebereiche) sichern zuverlässige Ergebnisse. Speicherstrategien unterscheiden zwischen kurzlebigen Telemetriedaten und langzeitarchivierten Nachweisen. Der Berlin‑Bericht betont, dass nicht alle Daten in Echtzeit gesammelt werden müssen; Speicherstrategien können Verdichtungen (z. B. 5‑min‑Mittelwerte) und Archivierung vorsehen.

Dashboards sind nach Rollen zu gestalten: Leitwarte/Technik benötigt Echtzeit‑Alarme und Anlagenzustände; Objektleitung braucht Kennzahlen zu Verfügbarkeit und Energie; das Management benötigt konsolidierte KPIs und ESG‑Berichte. Die Visualisierung dient als Betriebsinstrument, nicht als Selbstzweck. Sie muss belastbare Daten und historische Trends bieten, wobei Interaktionen (z. B. Ticketerstellung) integriert sein sollten.

CAFM‑Systeme (Computer‑Aided Facility Management) sind führende Systeme für Bestands‑ und Prozessdaten. IoT ergänzt sie um Echtzeit‑ und Zustandsdaten. Gemeinsam bilden sie einen geschlossenen Regelkreis: Messen → Entscheiden → Ausführen → Rückmelden. Durch die Kopplung können Alarme automatisch Tickets im CAFM auslösen, die Disposition vereinfachen und Rückmeldungen in Echtzeit in die Plattform zurückspielen.

Integrationen erfolgen über standardisierte Protokolle (REST, SOAP, OPC UA) und sichere Authentifizierungsmechanismen. Wichtige Punkte sind Datentransferprinzipien (Push vs. Pull), Fehler‑ und Retry‑Strategien, Transaktionssicherheit und vertraglich geregelte Schnittstellenverantwortungen.

Master‑Data‑Ownership ist zu klären (Asset‑ und Raum‑IDs). Mapping von Identifikatoren vermeidet Dubletten und Inkompatibilitäten. Synchronisationsregeln definieren, wann Daten von der Plattform zum CAFM und umgekehrt aktualisiert werden. Datenqualitäts‑KPIs (z. B. Aktualitätsgrad) unterstützen die Steuerung.

IoT‑Plattformen unterstützen ereignisgetriebene Workflows: Ein Alarm wird klassifiziert, ein Ticket im CAFM erzeugt, disponiert, ausgeführt und abschließend dokumentiert. SLA‑Eskalationen (z. B. Reaktionszeit) können automatisiert überwacht werden. Protokollierung und Lessons Learned verbessern langfristig die Prozesse.

Die Auswahl der richtigen IoT‑Technologien wird von Betriebssicherheit, Wartbarkeit, Funkabdeckung, Energieversorgung und Lebenszykluskosten beeinflusst. Ein klarer Überblick über die Komponenten erleichtert Planungs‑ und Beschaffungsentscheidungen.

• Endgeräte/Sensoren: Erfassen physikalische Größen. Planon beschreibt Sensoren für Temperatur, CO₂, Feuchte, Licht, Bewegung, Belegung und Energieverbrauch.

• Aktoren: Steuern Heizung, Lüftung, Beleuchtung und andere Anlagen. Sie sind häufig über lokale Bussysteme (z. B. DALI, KNX) angebunden. Phoenix‑Contacts Inline‑Controller unterstützen BACnet IP, M‑Bus, KNX/TP, DALI und Modbus, wodurch klassische und IP‑Geräte eingebunden werden können.

• Gateways: Bündeln Daten, übersetzen Protokolle und stellen sichere Verbindungen zur IoT‑Plattform her.

• Netze: Kabelgebundene Bus‑ und IP‑Netze (Ethernet, BACnet MS/TP) sowie drahtlose Netze (WLAN, Bluetooth, ZigBee, LoRaWAN, NB‑IoT). Funknetze müssen Funkausbreitung, Gebäudestruktur und Energiebedarf berücksichtigen.

• Plattformdienste: Bereits in Kapitel 4 beschrieben (Ingestion, Storage, Analytics).

• Integrationsschicht: Verbindet IoT mit CAFM, BMS, ERP und Energiemanagement.

• Betriebsmonitoring: Überwacht Geräte, Netzverbindungen und Datenflüsse; visualisiert den Zustand und meldet Ausfälle.

Die Auswahl der Funktechnik hängt von Reichweite, Bandbreite, Energiebedarf und Gebäudestruktur ab. LoRaWAN und NB‑IoT bieten weite Reichweiten und geringen Energiebedarf, eignen sich jedoch eher für einfaches Monitoring. WLAN und Bluetooth Low Energy sind für hohe Datenraten oder kurze Strecken geeignet. Die Berlin‑Studie weist darauf hin, dass offene Funk‑Schnittstellen Sicherheitsrisiken darstellen und restriktive Fernzugriffe mittels VPN‑Tunneln vorzusehen sind.

Typische Protokolle in Gebäuden sind BACnet, Modbus, M‑Bus, KNX, DALI, OPC UA sowie IoT‑Protokolle wie MQTT, CoAP oder REST. Die Protokollwahl richtet sich nach Sicherheitsniveau, Latenz und Integrationsfähigkeit. Zertifikats‑ und Schlüsselmanagement (Key‑Rotation, Deprovisioning) sowie regelmäßige Firmware‑Updates sind Governance‑Pflichten.

Telemetriedaten werden typischerweise in Zeitreihen‑Datenbanken gespeichert; Stammdaten bleiben im CAFM oder in relationalen Datenbanken. Für Nachweise und Audits müssen Archivierungs‑ und Retentionskonzepte definiert werden (z. B. Aufbewahrungspflichten von fünf Jahren). Verdichtungen können den Speicherbedarf reduzieren.

Sensoren müssen für den Einsatzzweck geeignet sein. Kalibrierung und Batteriemanagement stellen die Messgenauigkeit sicher. Planon betont, dass moderne Sensoren batteriebetrieben und kabellos installiert werden können, die Lebensdauer jedoch von Messintervall, Funktechnik und Temperatur abhängt. Plausibilitätsprüfungen der Daten sind im Betrieb essenziell.

Die Implementierung in Bestandsgebäuden erfordert ein systematisches Vorgehen. Untenstehender Ablauf orientiert sich an den Kapiteln des White Papers und überträgt sie in Projekt‑ und Betriebsprozesse.

Zu Beginn werden die strategischen Ziele und der Scope (einzelnes Objekt oder Portfolio) definiert. Ein Use‑Case‑Katalog mit KPIs, Datenschutz‑ und Informationssicherheitsabklärung sowie Abnahmekriterien wird erarbeitet. Datenschutz und Informationssicherheit sind „Entry Criteria“, bevor eine technische Umsetzung erfolgen darf.

Die Wirtschaftlichkeit wird anhand von CAPEX (z. B. Sensoranschaffungen) und OPEX (Betriebskosten, Lizenzgebühren) bewertet. Potenzielle Serviceeffekte und Risikokosten (z. B. Schaden durch Ausfall) werden quantifiziert. Es wird entschieden, ob die Lösung intern betrieben oder als Managed Service bezogen wird. Phoenix Contact demonstriert ein Beispiel für die Integration der Gebäudeautomation in eine IoT‑Plattform, die sowohl lokale Steuerung als auch Cloud‑Funktionalität bietet; dies zeigt, dass hybride Betriebsmodelle möglich sind.

Eine Stakeholder‑Matrix listet alle beteiligten Rollen: Eigentümer, Betreiber, IT‑/OT‑Spezialisten, Datenschutz‑ und Sicherheitsbeauftragte, Dienstleister und Nutzer. Ein Kommunikations‑ und Schulungskonzept sorgt dafür, dass alle Beteiligten informiert und befähigt werden. Besonderes Augenmerk gilt dem Change Management im Nutzerumfeld, da neue Sensorik und Transparenz zu Akzeptanzproblemen führen können.

Auf Basis der definierten Use‑Cases und des Business Cases werden Sensorik, Funktechnik und Plattform ausgewählt und dimensioniert. Ein Montage‑ und Inbetriebnahmeplan beschreibt die Integration in das bestehende BMS/CAFM und das Sicherheitskonzept (Netzsegmentierung, Firewalls). Ein Test‑ und Abnahmeplan definiert Erfolgskriterien (z. B. Datenübertragung, Genauigkeit, Alarmkette).

Ein Data‑Quality‑Management stellt die Qualität der erhobenen Daten sicher. Regelwerke und Alarmstrategien (Schwellwerte, Alarm‑Prioritäten) werden definiert. Dashboards visualisieren KPIs und unterstützen die kontinuierliche Optimierung. Betriebsprozesse regeln den Geräte‑Lifecycle, die Behandlung von Störungen und Firmware‑Updates.

Die Digitalisierung verändert Aufgaben im FM. Neben klassischen Gebäudetechnikern werden Data‑Scientists, IoT‑Architekten und Plattformmanager benötigt. Vertragsmodelle verändern sich hin zu ergebnisorientierten Services („Energy as a Service“, „Cleaning on Demand“) und datenbasierten Leistungsnachweisen. Hersteller wie Phoenix Contact und Softwareanbieter zeigen, dass Plattform‑ und Servicekompetenz zunehmend erfolgskritisch wird.

KI wird als nächste Stufe datengetriebener Betriebsführung betrachtet. Machine‑Learning‑Algorithmen können Anomalien erkennen, Verbrauch prognostizieren und Optimierungsstrategien ableiten. Voraussetzung ist eine hohe Datenqualität und Transparenz, wie sie durch IoT‑Plattformen und digitale Zwillinge geschaffen wird.

Der Standard „Matter“ (ehemals Project Connected Home over IP) zielt darauf ab, die Interoperabilität von Smart‑Home‑Geräten zu verbessern. Für gewerbliche Gebäude könnte Matter zukünftig interessante Anwendungsfelder bieten, etwa die herstellerübergreifende Integration von Sensoren und Aktoren. Aus FM‑Sicht ist entscheidend, ob der Standard skalierbar, sicher und für professionelle Anwendungen geeignet ist. Erste Testfelder zeigen, dass Matter‑fähige Geräte einfach einzubinden sind; jedoch müssen Fragen zu Management, Firmware‑Updates und Lifecycle‑Kosten geklärt werden.

Die Weiterentwicklung des digitalen Zwillings geht in Richtung Datenräume und Datensouveränität. Eigentümer und Betreiber wollen bestimmen, wer auf ihre Daten zugreifen darf, wie diese weitergegeben und genutzt werden. Technische Konzepte wie Gaia‑X und verteilte Datenräume adressieren diese Anforderungen. Für FM‑Projekte bedeutet dies, dass Zugriffskonzepte, Portabilität und langfristige Beherrschbarkeit bereits in der Planungsphase berücksichtigt werden müssen.