IT-Konzept GLT: Gebäudeautomation, Schnittstellen, Alarmmanagement

Das Datenmodell ist objektorientiert, hierarchisch und durchgängig schlüsselbasiert aufzubauen. Grundstruktur sind Standort, Liegenschaft, Gebäude, Bauwerksteil, Ebene, Raum, technische Anlage, Asset, Messpunkt, Dokument, Auftrag, Ticket und Vertrag. Jedes Objekt erhält genau eine systemweite Primär-ID, eine Parent-ID zur Hierarchiebildung sowie definierte Fremdschlüssel zu Kostenstellen, Lieferanten, Verträgen, Dokumenten, GLT-Punkten und gegebenenfalls BIM-/IFC-Referenzen. Die Datenhaltung ist entlang eines Attributkatalogs zu standardisieren; Pflichtattribute, optionale Attribute, Wertebereiche, Datentypen, Defaultwerte, Validierungsregeln und Änderungsverantwortung sind je Objektklasse festzulegen. Die Informationsanforderungen sind dabei zweck-, zeitpunkt- und qualitätsbezogen zu definieren.

Unterschieden werden Stammdaten, Bewegungsdaten und abgeleitete Zustands- bzw. Ereignisdaten. Bestands- bzw. Stammdaten umfassen im FM die für die Prozesssteuerung erforderlichen Daten zu Liegenschaften, Gebäuden, Anlagen und Einrichtungen; sie schließen grafisch-geometrische und alphanumerische Daten ein. Bewegungsdaten umfassen insbesondere Tickets, Aufträge, Rückmeldungen, Wartungsnachweise, Buchungen, Sensor- und Alarmereignisse, Verbrauchswerte, Eskalationen und Freigaben. Der Attributkatalog ist so auszulegen, dass geometrische, alphanumerische und dokumentarische Informationen für Planung, Errichtung und Betrieb in der jeweils benötigten Qualität übergeben und weitergeführt werden können. Für modellbasierte Übergaben sind offene, herstellerneutrale Strukturen vorzusehen; IFC ist hierfür ein offener, globaler und maschinenlesbarer Standard, der vendor-neutralen Informationsaustausch ermöglicht.

Die Semantik des Attributkatalogs ist konsistent und systemübergreifend aufzubauen. Für Klassen, Eigenschaften, zulässige Werte, Einheiten und Übersetzungen ist eine kontrollierte Begriffsverwaltung vorzusehen. Dafür kann eine semantische Referenzierung an ein gemeinsames Datenwörterbuch angebunden werden; das buildingSMART Data Dictionary ist als Sammlung verknüpfter Fachdatenwörterbücher für Begriffe des gebauten Umfelds angelegt und unterstützt die konsistente Zuordnung von Klassen und Eigenschaften.

Die nachstehende Feldliste wird als Mindestumfang für Stammdaten empfohlen. Sie leitet sich aus den Anforderungen an standardisierte Datenstrukturen, Datenqualität, Schnittstellenfähigkeit, Betriebshistorie und dokumentierten Informationsbedarf ab.

Das Rechte- und Rollenmodell ist strikt rollenbasiert aufzubauen. Rechte sind nach dem Minimalprinzip zu vergeben; administrative Rechte sind von fachlichen Bearbeitungsrechten zu trennen und über separate administrative Rollen zu verwalten. Das Berechtigungsmanagement hat zu regeln, ob und wie Benutzer oder IT-Komponenten auf Informationen oder Dienste zugreifen dürfen. Für Produktivbetrieb, Stammdatenpflege, Ticketdisposition, Auftragsbearbeitung, Berichtswesen, Systemadministration, Schnittstellenbetrieb, Revision, externe Dienstleister und Auditoren sind getrennte Rollen mit eindeutigem Rechteprofil vorzusehen.

Mindestens vorzusehen sind die Rollen CAFM-Systemverantwortung, Stammdatenverantwortung, Flächenmanagement, technisches FM, infrastrukturelles FM, Helpdesk/Disposition, Reporting/Controlling, Leserechte für Betreiberrollen, externe Servicepartner, Administrator sowie Revisor/Audit. Für externe Dienstleister sind zeitlich befristete, objektbezogene und protokollierte Zugänge mit eingeschränktem Funktionsumfang zu verwenden. Kritische Funktionen wie Massenänderungen, Benutzer- und Rollenpflege, Löschungen, Schnittstellenfreigaben und Stammdatenimporte sind ausschließlich Vier-Augen-fähig freizugeben. Diese Ausgestaltung ist eine aus dem Berechtigungsmanagement und dem Datenschutz abgeleitete Ausschreibungsanforderung.

Datensicherheit ist durch Technikgestaltung und datenschutzfreundliche Voreinstellungen umzusetzen. Soweit im CAFM personenbezogene Daten verarbeitet werden, sind Datenminimierung, Zweckbindung, Speicherbegrenzung, Rollenrestriktion, Verschlüsselung, belastbare Authentisierung und die rasche Wiederherstellbarkeit nach einem Vorfall vorzusehen. Das System muss Vertraulichkeit, Integrität, Verfügbarkeit und Belastbarkeit der Verarbeitungsdienste dauerhaft sicherstellen. Projektdaten, Protokolle, Benutzeraktivitäten, Freigaben und Archivzugriffe sind konfigurierbar, manipulationsgeschützt und auswertbar zu protokollieren. Für die Gebäudeautomation gilt ergänzend, dass mindestens die zentralen Komponenten des GA-Systems in eine zentrale Protokollierung einzubinden sind.

Für revisionsrelevante Unterlagen ist eine langfristige, sichere, unveränderbare und reproduzierbare Archivierung vorzusehen. Archivierte Dokumente und Nachweise müssen im CAFM recherchierbar, über Metadaten klassifiziert und über stabile Referenzen mit Assets, Räumen, Verträgen und Vorgängen verknüpft sein. Zugriffe auf das Archivsystem sind nachvollziehbar zu protokollieren.

Die Integration ist API-first auszuführen. Für ERP-Anbindungen, insbesondere bei Einsatz von ERP/[SAP](https://www.sap.com/index.html?utm_source=chatgpt.com), sind standardisierte Services für Instandhaltungsaufträge, Serviceaufträge, Equipment, Business Partner und Beschaffungsprozesse zu nutzen. Offizielle SAP-Dokumentationen weisen für Maintenance Orders, Service Orders, Equipment, Business Partner und Purchase Orders entsprechende APIs bzw. öffentlich bereitgestellte Integrationsschnittstellen aus. Für Bestellprozesse sind ereignisbasierte Verfahren dort zu nutzen, wo das ERP diese bereitstellt; andernfalls ist ein gesicherter periodischer Abgleich vorzusehen.

Für GLT und Gebäudeautomation sind sichere, standardisierte und herstellerunabhängige Protokolle zu bevorzugen. BACnet ist als globaler Kommunikationsstandard für Gebäudeautomation und -steuerung etabliert und auf Interoperabilität zwischen Geräten und Systemen ausgelegt. OPC UA ist plattformunabhängig, serviceorientiert, unterstützt Informationsmodelle, Verschlüsselung, Authentisierung, Auditierung, Subscriptions und Events. KNX ist als Gebäudeautomationssystem verfügbar; MQTT ist ein leichtgewichtiges Publish/Subscribe-Protokoll für IoT-Nachrichten; Modbus ist im industriellen Umfeld weit verbreitet und für Alt- bzw. Bestandstechnik geeignet. Für neue Integrationen ist BACnet/IP oder OPC UA als Primärweg vorzusehen; Modbus und KNX sind über Gateways oder Integrationsschichten einzubinden; MQTT ist für Sensorik und Edge-Anbindungen vorzusehen.

Die Service-Desk-Kopplung ist bidirektional auszuführen. Eingehende Nutzerstörungen, GLT-Alarme, IoT-Events und Prüffristverletzungen müssen automatisch oder regelbasiert in Tickets bzw. Arbeitsaufträge überführt werden; Rückmeldungen, Statuswechsel, Ursachenklassifikation, Lösungscodes, Eskalationen und Abschlussdaten sind an das CAFM zurückzuschreiben. Die Anforderung ergibt sich aus dem Bedarf nach standardisierten, transparenten und nachvollziehbaren Workflows sowie automatisierten Wartungs- und Alarmprozessen in zentralen Informationsumgebungen.

Für BIM- und Dokumentenübergaben sind offene, herstellerneutrale Austauschformate und standardisierte Metadatenstrukturen vorzusehen. IFC ist hierfür der Primärstandard. Ergänzend sind CDE-Referenzen, Dokumentenstatus, Freigabestände, Versionskennzeichen und Dokumentenklassen im CAFM zu speichern. Für alphanumerische Daten und Dokumente ist eine interoperable Import-/Exportlogik vorzusehen; CAFM-Connect ist hierfür als deutsche Interoperabilitätsinitiative mit einheitlicher Schnittstelle zum Austausch von Raum-, Anlagen- und Dokumentendaten einschlägig.

Die Einführung ist als strukturiertes Migrations- und Rolloutprojekt zu planen. Die Richtlinienlandschaft im CAFM-Umfeld behandelt Einführung, Datenbasis, Systemintegration und Ausschreibung ausdrücklich als zusammenhängendes Vorgehen; zugleich wird die Einführung eines CAFM-Systems als organisationsweites Projekt eingeordnet. Daraus folgt ein gestufter Implementierungspfad mit Fachkonzept, Datenmapping, Datenbereinigung, Mock-Migration, Integrationstest, Pilotbetrieb, Cutover, Hypercare und Verstetigung. Es sind mindestens zwei vollständige Probemigrationen vorzusehen. Eine Freigabe zur Produktivsetzung erfolgt erst nach bestandenen Fach-, Integrations-, Sicherheits- und Restore-Tests.

Der Rollout hat mit einem vorab definierten fachlichen Mindestumfang zu beginnen. Mindestumfang des Go-live sind Anlagenkataster, Flächenstruktur, Störungs- und Auftragsmanagement, Dokumentenverknüpfung, Benutzer- und Rollenmodell, ERP-Stammdatenkopplung sowie mindestens eine produktive GLT- oder Monitoringanbindung. Weitere Module, etwa Reinigungsflächen, Vertragsmanagement, Energiemonitoring oder mobile Rückmeldungen, sind modular nachzuschalten. Für die Hypercare-Phase wird als Ausschreibungsanforderung ein Zeitraum von mindestens acht Wochen empfohlen. Diese Festlegung ist eine abgeleitete Projektvorgabe.

Für Datensicherung und Wiederherstellung ist ein dokumentiertes Backup- und Recovery-Konzept vorzusehen. Datensicherungen sind regelmäßig nach Plan durchzuführen; Wiederherstellungen sind regelmäßig funktional zu testen. Werden Backups nicht getestet, besteht das Risiko, dass gesicherte Daten im Ereignisfall nicht wiederhergestellt werden können. Für kritische Betriebsprozesse sind RTO- und RPO-Werte vorab festzulegen; das BSI führt hierfür die maximal tolerierbare Ausfallzeit, die geforderte Wiederanlaufzeit und die Anforderungen an das Recovery Point Objective als maßgebliche Größen.

Als Ausschreibungsbasis wird empfohlen, für das Produktivsystem

einen monatlichen Verfügbarkeitswert von mindestens 99,5 Prozent,

einen RPO von höchstens 15 Minuten

und einen RTO von höchstens 4 Stunden

festzulegen; die Werte sind im Zuschlag an die tatsächliche Betriebs- und Schichtlogik anzupassen.

Der Betriebs- und Supportansatz ist dreistufig auszuführen. 1st Level übernimmt Annahme, Klassifikation, Benutzerunterstützung, Standardauskünfte und einfache Stammdatenkorrekturen. 2nd Level übernimmt Modulbetreuung, Regelwerks- und Workflowpflege, Fehleranalyse, Schnittstellenmonitoring, Datenqualitätsmanagement und Fachadministration. 3rd Level übernimmt Hersteller-Support, Fehlerbehebungen am Produkt, API-Anpassungen, Patches und Releasewechsel. Releases, Patches und Konfigurationsänderungen dürfen ausschließlich über einen geregelten Test- und Freigabeprozess in die Produktivumgebung überführt werden.

Die Abnahme ist testfallbasiert durchzuführen. Mindestkriterien sind vollständige technische Installation, dokumentierte Systemkonfiguration, vollständige Rollen- und Rechtestruktur, erfolgreiche Migration der freigegebenen Datenobjekte, erfolgreicher End-to-End-Test aller Pflichtschnittstellen, erfolgreiche Alarm-/Ticket-/Auftragsketten, erfolgreiche Protokollierung sicherheitsrelevanter Ereignisse, erfolgreicher Restore-Test, vollständige Dokumentation und formale Freigabe aller Produktivparameter. Für Softwareänderungen sind funktionale Tests, Regressionstests, Auswertung der Testergebnisse und Freigaben verbindlich.

Für die fachliche Abnahme sind zusätzlich Datenqualitätskriterien festzulegen. Mindestanforderungen sind Vollständigkeit aller Pflichtattribute, eindeutige Objekt- und Hierarchieschlüssel, fehlerfreie Dokumentenverknüpfung, eindeutige Zuordnung von GLT-/IoT-Referenzen, konsistente Kostenstellen- und Lieferantenreferenzen, korrekte Historisierung sowie fehlerfreie Rechtevergabe. Als Abnahmeschwelle wird empfohlen, dass 100 Prozent der Pflichtobjekte und Pflichtattribute vorhanden sind und keine kritischen Schnittstellenfehler offen bleiben. Die Grundlage hierfür bildet die Anforderung nach standardisierten Datenstrukturen, belastbarer Datenqualität und dokumentierten Informationsanforderungen.

Das Reporting ist rollenbezogen und dashboardfähig umzusetzen. Mindestens vorzusehen sind ein Betriebsdashboard, ein Instandhaltungsdashboard, ein Störungs- und Eskalationsdashboard, ein Datenqualitätsdashboard, ein Dokumentationsdashboard und ein Managementdashboard. Das Berichtswesen hat offene und überfällige Tickets, SLA-Einhaltung, Wartungsplanerfüllung, Anlagenzustände, wiederkehrende Störungen, Kosten je Anlage/Objekt, offene Prüf- und Nachweislücken, Rückstaus in Schnittstellen, unvollständige Stammdaten und Archivierungsstände auszuweisen. Reporting und KPI-Funktionen sind im CAFM-Leistungsumfeld ausdrücklich verankert und als Pflichtumfang der Ausschreibung vorzusehen.

• Systemgrundlagen und Navigation

• Rollen- und Rechtemodell

• Stammdatenpflege und Freigaberegeln

• Ticket-, Auftrags- und Rückmeldeprozesse

• Schnittstellenmonitoring

• Dokumentenverknüpfung und Archivzugriff

• Reporting und Dashboardnutzung

• Administrations- und Konfigurationsfunktionen

• Datenschutz- und Protokollierungsanforderungen

• Backup-/Restore-Abläufe für verantwortliche Rollen

• On-Premises-,

• Private-Cloud-

• oder SaaS-Vorgabe,

• die servicekritischen Zeiten und Schichtmodelle als Grundlage für verbindliche Verfügbarkeits-, RTO- und RPO-Werte,

• das verbindliche Rollenmodell des Auftraggebers einschließlich externer Dienstleisterrollen,

• die führenden Systeme je Datenobjekt,

• die verbindlichen Objektklassen und Hierarchien des Anlagen- und Flächenmodells,

• der endgültige Pflichtattributkatalog je Objektklasse,

• die zu übernehmenden Datenquellen und Datenqualitätsstände aus Planung, Errichtung und Vorbetrieb,

• die verbindlichen Zielsysteme für ERP/SAP, Service-Desk, GLT, IoT/Monitoring, DMS/CDE und Identity-Management,

• die konkreten Protokolle und Austauschformate je Schnittstelle,

• die Anforderungen an mobile Nutzung und Offline-Fähigkeit,

• die Zahl der Benutzer und Benutzergruppen,

• das Mengengerüst der zu migrierenden Objekte und Dokumente,

• die gewünschte Tiefe von BIM-/IFC-Referenzen einschließlich LOIN,

• die Report- und Dashboardempfänger, die Abnahmegrenzen für Datenqualität und Performance sowie

• die Vorgaben für Hersteller-Support, Patchfenster, Releasezyklen und Exit-/Datenexport-Szenarien.