Schnittstellenbeschreibung: System- und Prozessschnittstellen

Die relevante Systemlandschaft umfasst CAFM, GLT/GLT-Server, BMS, Service-Desk/Ticketing, ERP-System, Gebäudeautomation im engeren Sinn mit Automations- und Feldebene, Energiemanagement, Zutrittskontrolle, Brandschutz- und Alarmanlagen, Sicherheits- und Videoüberwachung, IoT-/Edge-Geräte sowie externe Dienstleistersysteme. Zwischen GLT/GLT-Server und BMS ist logisch zu unterscheiden: Der GLT-Server bildet die Management-, Visualisierungs- und Bedienebene der Gebäudeautomation; das BMS bildet die gewerkeübergreifende Orchestrierungs- und Integrationsschicht für normalisierte Betriebsdaten, Ereignisse und northbound Exporte. Soweit Herstellerarchitekturen beides auf derselben Plattform realisieren, bleibt die funktionale Trennung dennoch verbindlich. BACnet ist für Anwendungen der Gebäudeautomation einschließlich HVAC, Brand- und Life-Safety, Security, Energie- und Zutrittsmanagement ausgelegt; AMEV adressiert die Empfehlung Gebäudeautomation ausdrücklich auch an Betreiber.

CAFM ist für Stammdaten, Anlagenbeziehungen, Raum- und Flächenbezug, Auftragssteuerung, Dokumentenreferenzen und Leistungsnachweise führend. Für den standardisierten Austausch von Raum-, Anlagen- und Dokumentdaten ist CAFM-Connect zu verwenden, da dieser Ansatz im deutschsprachigen Markt als einheitliche Import-/Export-Schnittstelle auf IFC-Basis für alphanumerische Daten und Dokumente beschrieben ist. Die TGM-Hinweise des BSI ordnen CAFM ausdrücklich als Werkzeug im technischen Gebäudemanagement ein. Das ERP-System führt kaufmännische Objekte wie Kreditoren, Kostenstellen, Bestellungen, Wareneingänge, Budgets und Zahlungsauslösung. Service-Desk/Ticketing führt Incident-, Request-, Eskalations- und Kommunikationsobjekte. GLT/BMS führt Alarme, Quittierungen, Soll-/Ist-Werte, Trends, Betriebszustände und Automationsreferenzen.

Die Prozessschnittstellen sind in fünf Ketten zu gliedern. Erstens der Stammdatenprozess mit Übergabe von Standort-, Raum-, Asset-, Messpunkt-, Inventar- und Dokumentenreferenzen aus Projekt- und Bestandsunterlagen in das CAFM und von dort in angebundene Systeme. Zweitens der Alarm- und Incident-Prozess mit Ereignisaufnahme aus GLT/BMS, Sicherheit, Brandschutz, Zutritt, IoT/Edge und deren Übergabe an den Service Desk. Drittens der Auftrags- und Leistungsprozess mit Ticketanlage, Auftragsbildung im CAFM, Rückmeldung aus externen Dienstleistersystemen und kaufmännischer Verarbeitung im ERP. Viertens der Prüf- und Nachweisprozess mit Prüfberichten, Protokollen, Checklisten und Abnahmeunterlagen in CAFM und Dokumentationsumgebung. Fünftens der Änderungsprozess mit versionierter Übernahme von Parametern, Endpunkten, Datenmodellen, Mappings und Zertifikaten in ein zentrales Schnittstellen-Repository. Schnittstellen zwischen klassischer Werkleistung, Monitoring und erster Nutzungsphase sind nach AMEV explizit zu präzisieren; im TGM fordert BSI dafür unter anderem Monitoring, Alarmierung, Protokollierung, Ereignismanagement, Systemtests und eine Testumgebung.

Die Protokollzuordnung ist verbindlich nach Funktionsdomänen festzulegen. API/REST und OData sind primär für CAFM, Service-Desk, ERP, Energiemanagement und externe Dienstleistersysteme einzusetzen. SOAP bleibt für Legacy- und Hersteller-APIs, insbesondere im ERP-Umfeld, zulässig. OPC UA ist als primäres semantisches Maschinen- und Anlagendatenprotokoll für industrialisierte OT-/IoT-Schnittstellen zu verwenden, da es Plattformunabhängigkeit, hierarchische Adressräume, Subscriptions, Events sowie Verschlüsselung, Authentifizierung und Auditing bereitstellt. BACnet beziehungsweise BACnet/SC ist primär für gewerkeübergreifende Gebäudeautomation, BMS-Kopplung und standardisierte objekthafte Gerätezustände einzusetzen. Modbus TCP/Security ist auf Zähler, Utility-, Feld- und Altgeräteintegration zu beschränken; Modbus Serial ist bei Neuimplementierungen auszuschließen. MQTT 5.0 ist für Edge-, IoT- und Event-Bus-Szenarien mit entkoppelter Publish-/Subscribe-Logik einzusetzen.

Datenflüsse und Datentypen sind systematisch zu trennen. Ereignisse und Alarme werden ereignisgetrieben übernommen und enthalten mindestens Ereignis-ID, Zeitstempel, Quellsystem, Anlagen- oder Objektbezug, Severity, Status, Bestätigungsstatus und technische Rohmeldung. Messwerte werden als Zeitreihen mit Messpunkt-ID, Wert, Einheit, Qualität, Zeitstempel und optionalem Verdichtungsgrad übernommen. Stammdaten enthalten eindeutige System- und Objekt-IDs, Bezeichnungen, Hierarchiebezug, Raum- und Anlagenreferenz, Kritikalität, Lifecycle-Status und Verantwortungsbezug. Auftragsdaten enthalten Ticket-ID, Auftrags-ID, Priorität, Gewerk, Asset-ID, SLA-Klasse, Bearbeitungsstatus, Leistungszeiten, Kostenbezug und Dokumentenreferenzen. Inventardaten enthalten Geräte-ID, Seriennummer, Hersteller, Firmware-/Softwarestand, Gewährleistungs- und Wartungsstatus. Prüfprotokolle werden als strukturierte Datensätze mit Metadaten und Dokumentenlink oder als XML/PDF/A mit referenzierbaren Indexfeldern übernommen. Für das CA FM-Umfeld sind Raum-, Anlagendaten und Dokumente auf CAFM-Connect-/IFC-Basis austauschbar; für das ERP-Umfeld sind OData/REST und SOAP im Standardrepertoire des Herstellers dokumentiert.

Authentifizierung und Autorisierung sind pro Schnittstellenklasse verbindlich festzulegen. REST-, OData- und Webhook-Schnittstellen werden ausschließlich über TLS 1.2 oder höher betrieben und mit dienstkontobezogener Authentisierung, OAuth2-/Client-Credentials, SAML oder Mutual TLS abgesichert. Für das ERP-Integrationsumfeld sind SSL-Verbindungen sowie Zertifikate und Credentials auf Middleware- beziehungsweise Integration-Suite-Ebene verbindlich. BACnet/SC verwendet TLS und Peer-Authentifizierung; Modbus Security verwendet TLS mit X.509v3-Zertifikaten; OPC UA deckt Verschlüsselung, Authentifizierung und Auditing innerhalb des Protokolls ab. Für standortübergreifende Kopplungen von GA-Netzen über öffentliche Netze ist die Trennung der GA-Netze mittels VPN oder gleichwertiger Technik sicherzustellen. Schreibrechte in sicherheitskritische Systeme bleiben auf freigegebene, herstellerkonforme Wartungs- und Bedienrollen beschränkt; die Integration in CAFM, Service Desk oder ERP erfolgt dort grundsätzlich read only oder statusbezogen.

Datenformate und Frequenzen sind in drei Übertragungsklassen zu ordnen. Klasse Echtzeit umfasst sicherheits- und betriebskritische Alarme, Schaltzustände und Incident-Trigger; sie ist ereignisgesteuert mit einer maximalen Fachlatenz von fünf Sekunden bis zur Aufnahme im BMS oder Service-Desk zu führen. Klasse Nah-Echtzeit umfasst Betriebszustände, Zählerstände, Energie- und Trendwerte sowie Ticketstatus; sie ist ereignisgesteuert oder in Intervallen von einer bis sechzig Sekunden in die Integrationsschicht und verdichtet im Intervall von fünf bis fünfzehn Minuten in CAFM- und Energiesysteme zu überführen. Klasse Batch umfasst Stammdaten, Inventar, Buchungsdaten, Prüfprotokolle, Abschlussdokumente und Reports; sie ist deltafähig mehrmals täglich und mit einem täglichen Vollabgleich zu führen. Verfügbarkeitsanforderungen sind ebenfalls klassenbezogen festzulegen: Echtzeit 99,95 Prozent, Nah-Echtzeit 99,9 Prozent, Batch 99,5 Prozent je Monatswert. Die BSI-Hinweise zu Monitoring, Alarmierung und Schwellwerten sowie die SAP-, OPC-UA-, BACnet-, Modbus- und MQTT-Dokumentation stützen diese Differenzierung nach Kommunikationsart und Kritikalität.

Die Fehlerbehandlung ist pro Schnittstellentyp verbindlich umzusetzen. Synchrone Schnittstellen verwenden fachliche ACK-/NACK-Rückmeldungen mit idempotenter Wiederholung. Asynchrone Schnittstellen werden über Queueing, Zustellversuche mit exponentiellem Backoff, Dublettenprüfung, Dead-Letter-Queues und Replay-Funktion abgesichert. Jeder Fehlerdatensatz enthält Schnittstellen-ID, Payload-Hash, Zeitstempel, Endpoint, Fehlercode, Fehlertyp, Wiederholstatus und Eskalationsstufe. Für Echtzeit- und Alarmketten ist ein paralleler Fallbackweg über Service Desk und E-Mail vorzusehen; bei anhaltender Störung wird nach einer definierten Wartezeit auf die manuelle Disposition umgeschaltet. Stufe eins der Eskalation liegt beim Service Desk oder Interface-Operator, Stufe zwei beim Integrationsmanagement beziehungsweise Systemadministrator, Stufe drei bei Systemeigner, Informationssicherheit und retained Organisation. BSI fordert für TGM und GA Meldeketten, Monitoring, Alarmierung, Ereignisprotokollierung und Security Monitoring der zentralen Komponenten.

Jede Schnittstelle erhält einen eindeutigen Eigentümer auf Auftraggeberseite und eine ausführende Betriebsverantwortung auf Auftragnehmerseite. Die Systemverantwortung verbleibt beim jeweiligen Systemeigner des führenden Systems; die technische Betriebs- und Releaseverantwortung der Schnittstellen liegt beim Integrationsmanager des Auftragnehmers. Konsultationspflichtig sind jeweils die betroffenen Fachsystemeigner, die Informationssicherheit sowie die fachlich zuständigen Betreiberrollen. Externe Dienstleistersysteme erhalten ausschließlich definierte Rollen mit Bedarfsträger- und Mindestdatenzugriff; ein direkter Zugriff externer Systeme auf OT-/GA-Komponenten ist ausgeschlossen. Änderungen im TGM sind nach BSI immer angekündigt und mit beteiligten Gewerken abgestimmt durchzuführen; die Sicherheitsziele in TGM und GA sind dauerhaft mitzudenken.

Test- und Abnahmeverfahren sind für jede Schnittstelle in einer standardisierten Prüfsequenz durchzuführen. Mindestbestandteile sind Connectivity-Test, Authentisierungs- und Zertifikatstest, Schema- und Mappingtest, Rollen-/Rechteprüfung, Funktions- und Ereignistest, Last- und Latenztest, Fehler- und Wiederanlauftest, Zeitstempel-/Zeitsynchronisationsprüfung, Redundanz- beziehungsweise Failovertest sowie Dokumentationsabgleich. Für Alarmketten ist zusätzlich ein End-to-End-Test vom technischen Ereignis bis zum Ticket, zur Eskalationsmeldung und zur Rückmeldung an CAFM oder Berichtswesen durchzuführen. Die Abnahme setzt vollständige Mappingspezifikation, Testprotokoll, Endpunktinventar, Zertifikatsinventar, Freigabeliste und belastbaren Rollback-Nachweis voraus. BSI ordnet Systemtests und den Aufbau einer Testumgebung ausdrücklich dem TGM zu; AMEV betont in Monitoring und früher Nutzungsphase die saubere Klärung von Schnittstellen zwischen Werkleistungen und Qualitätssicherung.

Monitoring und Alarmierung sind zentral aufzubauen. Zentrale Komponenten der GA- und Integrationslandschaft sind in Netz-, System- und Security-Monitoring einzubinden. Für jeden Systemtyp sind überwachte Parameter, Grenzwerte, Schwellwertlogik, Meldungsempfänger, Eskalationszeiten und Wartungsfenster festzulegen. Zu protokollieren sind mindestens Verbindungsaufbau und -abbruch, Authentisierung, Zertifikatswechsel, Konfigurationsänderungen, Versionswechsel, Fehler, Zustellversuche, Nachrichtenverluste, Quittierungen, Webhook-Callbacks, API-Rate-Limits und administrative Zugriffe. Die BSI-Umsetzungshinweise benennen genau diese Elemente als Kern der Betriebs- und Sicherheitsüberwachung in TGM und GA.

Backup und Recovery erfassen nicht nur Datenbestände, sondern die gesamte Integrationsfähigkeit. Zu sichern sind Schnittstellenkonfigurationen, Mappingdefinitionen, Topic- und Queue-Definitionen, Connector-Parameter, Zertifikate, Vault- oder Secret-Referenzen, API-Spezifikationen, Rollen- und Rechtezuordnungen, Zustellprotokolle, Fehlerqueues und Abnahmeunterlagen. Für kritische Schnittstellen sind Recovery-Runbooks, Ersatzendpunkte, Zertifikatswechselverfahren und Wiederanlaufszenarien vorzuhalten. Restore-Tests sind vor Produktivsetzung, nach Major Changes und anschließend in regelmäßigen Abständen durchzuführen. Das BSI verlangt, dass Datensicherung die kurzfristige Wiederaufnahme des Betriebs ermöglicht, und weist ausdrücklich darauf hin, dass regelmäßige Sicherungen ohne regelmäßige Wiederherstellungstests nicht ausreichen.

Änderungsmanagement und Versionierung sind als eigener Lebenszyklus der Schnittstellen zu führen. Jede Schnittstelle erhält eine eindeutige Schnittstellen-ID, Quell- und Zielsystem, Vertragsstand, Payloadschema, Mappingversion, Teststand, Betriebsstatus, Release-Datum, Major-/Minor-/Patch-Version und Freigabestatus. Schemaänderungen, Endpunktwechsel, Protokollwechsel, Zertifikatswechsel, Rollenänderungen und neue Datenfelder unterliegen dem Change-Request-Prozess; Major Changes mit fachlicher Wirkung sind nur mit Testumgebung, Parallelbetrieb oder Rückfalloption zulässig. Das Schnittstellen-Repository ist revisionssicher in der zentralen Dokumentationsumgebung zu führen und enthält zusätzlich Beispielpayloads, Fehlerkataloge, Kommunikationsdiagramme, Ansprechpartner, Wartungsfenster, Verfügbarkeitsklasse und Verweise auf Abnahme- und Monitoringprotokolle. BSI fordert für TGM einen Änderungsprozess, die regelmäßige Prüfung des TGM-Konzepts und bei erhöhtem Schutzbedarf auch eine Testumgebung.

Die folgenden Matrizen verdichten die verbindliche System- und Schnittstellenlogik. Grundlage sind die in den Protokoll- und Herstellerdokumentationen beschriebenen Fähigkeiten von OData/REST, SOAP, OPC UA, BACnet/SC, Modbus Security, MQTT 5.0 sowie die CAFM-Connect-, BSI- und AMEV-Vorgaben zu Interoperabilität, Gateway-/Kopplerfunktionen, Monitoring, Logging und Sicherheitsintegration.

Direkte Punkt-zu-Punkt-Verbindungen zwischen externen Dienstleistersystemen und OT-/GA-Sicherheitssystemen sind ausgeschlossen. Schreibzugriffe in Brandschutz-, Zutritts-, Sicherheits- und Videoanlagen erfolgen nicht aus CAFM, Service Desk oder ERP, sondern ausschließlich über freigegebene Primärsysteme und autorisierte Rollen. Für Neuimplementierungen im Feldbereich ist Modbus Serial nicht vorzusehen; BACnet/SC, Modbus Security, OPC UA und TLS-gesicherte IT-Schnittstellen sind bevorzugt einzusetzen.

• die endgültige Systemliste mit verbindlicher Hersteller-, Produkt- und Versionsfestlegung je Fachsystem

• die Entscheidung, ob BMS und GLT/GLT-Server physisch getrennt oder auf einer Plattform konsolidiert betrieben werden

• die endgültige System-of-Record-Matrix je Datenobjekt und Attributgruppe

• die verbindliche Festlegung, welche Schnittstellen lesend, schreibend oder bidirektional auszuführen sind

• die endgültigen Feldkataloge für Stammdaten, Ereignisse, Messwerte, Auftragsdaten, Inventar und Prüfprotokolle

• die konkrete Netzarchitektur mit Segmentierung, DMZ, VPN-Zonen, Proxy-/Broker-Standorten und Redundanzkonzept

• die endgültigen Authentisierungsverfahren, Zertifikatsaussteller, Laufzeiten, Rotationszyklen und Secret-Management-Verfahren

• die verbindlichen Latenz-, Verfügbarkeits-, RPO- und RTO-Werte je Schnittstellenklasse und je kritischer Prozesskette

• die genaue Alarm- und Eskalationsmatrix einschließlich Empfängerkreise, Bereitschaftslogik und Fallback-Kommunikationswege

• die Prioritätsabbildung von technischen Alarmen auf Ticketklassen und SLA-Klassen

• die endgültigen Vorgaben zur Zeitstempelsynchronisation, Protokollaufbewahrung und Nachweisfristen

• die Beschränkungen für Sicherheits-, Video-, Zutritts- und Brandschutzsysteme hinsichtlich read only, Wartungsmodus und Freigabeworkflow

• die konkrete Anbindung externer Dienstleistersysteme einschließlich Format, Frequenz, Rollenmodell und Mandantentrennung

• die endgültigen Anforderungen an Testumgebung, Parallelbetrieb, Cutover-Fenster, Abnahmestichproben und Lasttests

• die Struktur des zentralen Schnittstellen-Repositorys einschließlich Namenskonventionen, Versionslogik, Pflichtmetadaten und Freigabestatus

• die endgültigen Dokumentationsvorgaben für Payload-Beispiele, Fehlerkataloge, Mappingtabellen, Zertifikatslisten, Release Notes und Abnahmeprotokolle