BMS und EPMS trennen und trotzdem verbinden

Wer ein Rechenzentrum plant oder betreibt, kennt die Frage früher oder später: Brauchen wir ein System oder zwei? Das Building Management System überwacht Kühlung, Lüftung und Brandschutz. Das Energy and Power Monitoring System erfasst Lasten, Zähler und Versorgungspfade. Beide Systeme haben unterschiedliche Anforderungen an Verfügbarkeit, Sicherheit und Datenstruktur. Und doch braucht der Betrieb im Störfall ein vollständiges Bild, das beide Welten zusammenführt.

Dieser fünfte Teil der Serie zeigt, wie man die Trennung sauber plant, welche Schnittstelle die beiden Systeme verbindet und was im Lastenheft stehen muss, damit die Lösung im Betrieb funktioniert. Wir stützen uns dabei auf unsere Projekterfahrung und auf die Anforderungen der EN 50600-2-6, die Managementsysteme für Rechenzentren beschreibt.

Warum die Trennung sinnvoll ist

Die Idee, alles in einem einzigen System zu vereinen, klingt verlockend. Weniger Schnittstellen, weniger Abstimmungsaufwand, ein einziger Lieferant. In der Praxis zeigt sich jedoch, dass diese Vereinfachung an der falschen Stelle spart.

Ein BMS für ein Rechenzentrum muss hochverfügbar sein. Es steuert Kühlkreise, überwacht Temperaturen und löst Alarme aus, wenn Schwellwerte überschritten werden. Ein Ausfall des BMS kann direkt die Verfügbarkeit der IT-Infrastruktur gefährden. Deshalb wird das BMS in der Regel redundant ausgelegt, mit eigenen Controllern, eigenen Netzwerksegmenten und klaren Rückfallebenen.

Ein EPMS hat andere Aufgaben. Es erfasst Leistungswerte an Transformatoren, USV-Anlagen, Verteilern und Verbrauchern, berechnet den PUE-Wert und stellt Lastverläufe dar. Es ist ein Informations- und Analysesystem. Ein kurzer Ausfall des EPMS ist unangenehm, aber er gefährdet nicht unmittelbar die IT-Last. Die Anforderungen an Verfügbarkeit, Redundanz und Reaktionszeit sind deshalb andere als beim BMS.

Wenn man beide Funktionen in ein einziges System presst, muss dieses System die höchsten Anforderungen beider Welten erfüllen. Das treibt die Kosten, erhöht die Komplexität und schafft ein System, das für keine der beiden Aufgaben wirklich optimiert ist. Ausserdem entsteht ein einziger Angriffspunkt: Wer das System kennt, kennt beide Welten. Wer es stört, stört beide Welten gleichzeitig.

Die EN 50600-2-6 beschreibt Managementsysteme für Rechenzentren und unterscheidet zwischen verschiedenen Funktionsbereichen. Sie fordert keine bestimmte Systemarchitektur, gibt aber klare Hinweise darauf, welche Funktionen in welchen Bereichen zusammengehören und welche Informationen systemübergreifend verfügbar sein müssen. Aus dieser Logik heraus ergibt sich die Trennung von BMS und EPMS als naheliegende und gut begründbare Entscheidung.

Was ins BMS gehört und was ins EPMS

Die Abgrenzung ist nicht immer trivial, weil es Datenpunkte gibt, die für beide Systeme relevant sind. Trotzdem lässt sich eine klare Grundregel formulieren: Das BMS steuert und regelt, das EPMS misst und analysiert.

Zum BMS gehören alle Funktionen, die direkt in den Betrieb der Gebäudetechnik eingreifen. Dazu zählen die Regelung der Kühlaggregate, die Steuerung von Pumpen und Ventilatoren, die Überwachung von Temperaturen und Drücken in den Kühlkreisen, die Ansteuerung von Brandschutzklappen und die Integration von Brandmeldeanlagen. Auch die Alarmierung bei kritischen Zuständen und die Visualisierung des Anlagenzustands für den Betrieb gehören ins BMS. Das BMS ist das operative System. Es muss im Störfall funktionieren, auch wenn das Netzwerk teilweise ausgefallen ist.

Zum EPMS gehören alle Funktionen, die mit der Erfassung und Auswertung von Energiedaten zu tun haben. Dazu zählen die Messung von Wirkleistung, Scheinleistung und Energiemengen an Transformatoren, USV-Anlagen, Schaltfeldern und Verbrauchern, die Berechnung des PUE-Werts nach EN 50600-4-2 und ISO/IEC 30134-2, die Darstellung von Lastverläufen und Lastspitzen, die Überwachung von Versorgungspfaden und die Erkennung von Ungleichgewichten in der Lastverteilung. Das EPMS ist das analytische System. Es liefert die Grundlage für Entscheide, aber es greift nicht direkt in den Betrieb ein.

Es gibt Datenpunkte, die in beiden Systemen erscheinen. Die Vorlauftemperatur eines Kühlkreises ist ein Regelgrösse im BMS und gleichzeitig eine Eingangsgrösse für die Effizienzberechnung im EPMS. Die Leistungsaufnahme einer Kältemaschine ist ein Messwert im EPMS und gleichzeitig ein Indikator für den Betriebszustand im BMS. Diese Überschneidungen sind normal. Sie sind kein Argument gegen die Trennung, sondern ein Argument für eine sauber definierte Datenschnittstelle.

Die Datenschnittstelle als Kernstück der Architektur

Die Schnittstelle zwischen BMS und EPMS ist das Herzstück der Gesamtarchitektur. Sie entscheidet darüber, ob der Betrieb im Störfall ein vollständiges Bild hat oder ob Informationen fehlen.

Eine gute Datenschnittstelle hat drei Eigenschaften. Erstens ist sie klar definiert: Es gibt eine Liste der Datenpunkte, die vom BMS ans EPMS übertragen werden, und eine Liste der Datenpunkte, die in die andere Richtung fliessen. Diese Listen sind Teil des Lastenhefts und werden im Ausführungsplan festgehalten. Zweitens ist sie robust: Die Schnittstelle funktioniert auch dann, wenn eines der beiden Systeme teilweise ausgefallen ist. Das bedeutet, dass das BMS nicht auf Daten vom EPMS angewiesen ist, um seine Kernfunktionen zu erfüllen. Drittens ist sie protokollkonform: Beide Systeme sprechen eine gemeinsame Sprache, idealerweise BACnet nach SN EN ISO 16484-5, damit kein proprietärer Konverter als zusätzliche Fehlerquelle eingebaut werden muss.

In der Praxis sehen wir häufig Schnittstellen, die keines dieser drei Kriterien erfüllen. Die Datenpunktliste fehlt oder ist veraltet. Die Schnittstelle ist so eng gekoppelt, dass ein Ausfall des EPMS auch das BMS beeinträchtigt. Und der Datenaustausch läuft über einen proprietären Konverter, der weder dokumentiert noch wartbar ist. Das sind keine Einzelfälle, sondern ein Muster, das wir in vielen Bestandsanlagen antreffen.

Was konkret über die Schnittstelle übertragen werden soll, hängt vom Projekt ab. Als Ausgangspunkt hat sich in unserer Praxis eine Gliederung in drei Kategorien bewährt. Die erste Kategorie umfasst Betriebszustände: Ist eine Kältemaschine in Betrieb? Läuft eine Pumpe? Ist ein Ventil offen oder geschlossen? Diese Informationen braucht das EPMS, um Lastverläufe korrekt zu interpretieren. Die zweite Kategorie umfasst Messgrössen: Temperaturen, Drücke, Volumenströme und Leistungswerte, die für die Effizienzberechnung relevant sind. Die dritte Kategorie umfasst Alarme und Statusmeldungen: Welche Anlagen sind gestört? Welche Grenzwerte wurden überschritten? Diese Informationen braucht das EPMS, um Effizienzeinbrüche korrekt einzuordnen.

In die andere Richtung, also vom EPMS ins BMS, fliesst in der Regel weniger. Typisch sind Summenwerte der IT-Last, die das BMS für die Regelung der Kühlung verwenden kann, sowie Alarme bei Überschreitung von Leistungsgrenzen in der Versorgung.

Was im Lastenheft stehen muss

Das Lastenheft ist der Ort, an dem die Architekturentscheidung verbindlich festgehalten wird. Wer BMS und EPMS als getrennte Systeme plant, muss das Lastenheft so formulieren, dass beide Systeme unabhängig ausgeschrieben, bewertet und abgenommen werden können, ohne dass die Schnittstelle dabei vergessen geht.

In unserer Erfahrung fehlen im Lastenheft für Rechenzentren am häufigsten vier Dinge. Erstens die explizite Aussage, dass BMS und EPMS getrennte Systeme sind und welche Systemgrenzen gelten. Ohne diese Aussage interpretiert jeder Anbieter die Aufgabenstellung anders, und die Offerten sind nicht vergleichbar. Zweitens die Datenpunktliste für die Schnittstelle, mindestens als Mindestanforderung mit Kategorien und Mengengerüst. Drittens die Anforderungen an das Protokoll und die Übergabepunkte: Wo genau findet der Datenaustausch statt? Auf welcher Netzwerkebene? Mit welchem Protokoll? Viertens die Anforderungen an das Verhalten bei Schnittstellen-Ausfall: Was passiert, wenn die Verbindung zwischen BMS und EPMS unterbrochen wird? Welche Funktionen müssen trotzdem weiter funktionieren?

Diese vier Punkte sind keine Detailfragen. Sie sind Grundlage für die Ausschreibung und für die spätere Abnahme. Wer sie im Lastenheft weglässt, wird sie in der Ausführungsphase als Streitpunkte wiederfinden.

Für die Ausschreibung selbst empfehlen wir, BMS und EPMS als separate Lose zu behandeln, mit einem gemeinsamen Schnittstellenblatt, das beide Lose verbindet. Das Schnittstellenblatt beschreibt die Datenpunkte, das Protokoll, die Übergabepunkte und die Anforderungen an den Integrationstest. Es ist Teil beider Ausschreibungen und wird von beiden Anbietern verbindlich akzeptiert.

Wie ein solches Lastenheft aufgebaut ist und was es im Detail enthalten muss, haben wir in unserem Artikel «Das GA-Lastenheft: Was wirklich drinstehen muss» ausführlich beschrieben. Die Grundprinzipien gelten auch für Rechenzentren, mit den zusätzlichen Anforderungen, die sich aus der Verfügbarkeitsanforderung und der Systemtrennung ergeben.

Prüfung und Abnahme der Schnittstelle

Eine Schnittstelle, die im Lastenheft beschrieben, aber nie geprüft wurde, ist keine Schnittstelle. Sie ist eine Hoffnung. Die Abnahme der Schnittstelle zwischen BMS und EPMS ist deshalb ein eigenständiger Prüfschritt, der weder im BMS-Abnahmeprotokoll noch im EPMS-Abnahmeprotokoll verschwinden darf.

Was bei der Schnittstellenprüfung getestet werden muss, ergibt sich direkt aus dem Schnittstellenblatt. Für jeden Datenpunkt wird geprüft, ob er korrekt übertragen wird, ob der Wert mit dem Quellwert übereinstimmt, ob die Aktualisierungsrate den Anforderungen entspricht und ob der Datenpunkt im Empfangssystem korrekt beschriftet und zugeordnet ist. Zusätzlich wird das Verhalten bei Schnittstellen-Ausfall geprüft: Wird der Ausfall erkannt und alarmiert? Welche Funktionen laufen weiter, welche fallen weg?

In der Praxis stellen wir fest, dass die Schnittstellenprüfung häufig zu spät oder gar nicht stattfindet. Oft wird die Schnittstelle erst kurz vor der Inbetriebnahme konfiguriert, weil die Koordination zwischen den beiden Systemlieferanten nicht früh genug gestartet wurde. Dann fehlt die Zeit für eine sorgfältige Prüfung, und der Betrieb startet mit einer Schnittstelle, die niemand wirklich getestet hat.

Wir empfehlen deshalb, die Schnittstellenprüfung als eigenen Meilenstein in den Inbetriebnahmeplan aufzunehmen, mit einem klaren Datum und einer klaren Verantwortung. Wer für die Koordination zwischen den beiden Systemlieferanten zuständig ist, muss im Lastenheft festgelegt sein. In der Regel ist das die Gesamtprojektleitung oder ein beauftragter Inbetriebnahmespezialist. Wie Commissioning-Stufen im Rechenzentrum grundsätzlich aufgebaut sind, haben wir in Teil 1 dieser Serie, «Commissioning L1 bis L5 im Rechenzentrum einfach erklärt», beschrieben.

Sicherheit und Netzwerksegmentierung

Die Trennung von BMS und EPMS hat auch eine Sicherheitsdimension. Beide Systeme haben unterschiedliche Anforderungen an den Netzwerkzugang und unterschiedliche Risikoprofile.

Das BMS steuert physische Anlagen. Ein unbefugter Zugriff auf das BMS kann direkte Auswirkungen auf den Betrieb haben. Deshalb muss das BMS in einem eigenen, streng gesicherten Netzwerksegment betrieben werden. Der Zugang ist auf wenige, namentlich bekannte Personen beschränkt. Fernzugänge sind besonders gesichert und werden protokolliert.

Das EPMS ist ein Informationssystem. Es hat in der Regel mehr Benutzer, weil Energiedaten für verschiedene Rollen relevant sind: Betrieb, Energiemanagement, Reporting, Compliance. Das EPMS kann deshalb in einem weniger restriktiven Segment betrieben werden, muss aber trotzdem von der IT-Infrastruktur und vom Internet getrennt sein.

Die Schnittstelle zwischen BMS und EPMS überquert die Segmentgrenze. Das ist ein sensibler Punkt. Wir empfehlen, diese Verbindung über einen dedizierten, protokollkonformen Übergabepunkt zu führen, der nur die definierten Datenpunkte durchlässt und keine direkte Verbindung zwischen den Segmenten öffnet. BACnet/SC bietet hier Vorteile, weil es auf TLS-gesicherten Verbindungen basiert und keine offenen UDP-Ports benötigt. Wir haben das in Teil 2 dieser Serie, «BACnet/SC als Schutz für die Kühlung», ausführlich erläutert.

Für Bestandsanlagen, in denen BMS und EPMS noch nicht klar getrennt sind, empfehlen wir eine Analyse der bestehenden Systemgrenzen und Netzwerkverbindungen als ersten Schritt. Wie eine solche Analyse aufgebaut ist, beschreibt unsere Serie «Rechenzentrum im Bestand: Analyse, Optimierung, Sicherheit», insbesondere Teil 6, «Security-Analyse der Leittechnik im Bestand».

Betrieb: Was der Leitstand braucht

Die Trennung von BMS und EPMS darf nicht dazu führen, dass der Betrieb im Störfall zwischen zwei Systemen hin- und herspringen muss, um ein vollständiges Bild zu bekommen. Das wäre der grösste Fehler, den man bei der Umsetzung machen kann.

Was der Leitstand braucht, ist eine konsolidierte Sicht. Diese Sicht muss nicht in einem einzigen System entstehen. Sie kann durch eine übergeordnete Visualisierungsebene realisiert werden, die Daten aus BMS und EPMS zusammenführt und dem Betrieb in einer einheitlichen Oberfläche darstellt. Entscheidend ist, dass diese Ebene klar von den operativen Systemen getrennt ist: Sie liest Daten, sie schreibt keine Steuerbefehle. Steuerbefehle gehen immer direkt ans BMS.

Im Störfall braucht der Betrieb vor allem drei Informationen schnell: Welche Anlage ist betroffen? Wie ist der aktuelle Betriebszustand der Kühlung? Wie ist die aktuelle Lastverteilung in der Stromversorgung? Die ersten beiden Informationen kommen aus dem BMS, die dritte aus dem EPMS. Wenn die Datenschnittstelle funktioniert und die Visualisierungsebene korrekt konfiguriert ist, sind alle drei Informationen an einem Ort verfügbar.

Wir empfehlen, die Anforderungen an die konsolidierte Betriebssicht bereits im Lastenheft zu beschreiben. Welche Informationen müssen im Störfall sofort sichtbar sein? Welche Alarme müssen priorisiert dargestellt werden? Wie lange darf die Aktualisierungszeit für kritische Datenpunkte sein? Diese Fragen sind keine Detailfragen der Visualisierung. Sie sind Betriebsanforderungen, die die gesamte Systemarchitektur beeinflussen.

Wie Alarmmanagement im Rechenzentrum grundsätzlich aufgebaut werden sollte, damit der Betrieb im Störfall handlungsfähig bleibt, beschreibt Teil 5 der Serie «Rechenzentrum im Bestand: Analyse, Optimierung, Sicherheit», «Alarmflut im Leitstand: Alarmmanagement im Rechenzentrum».

Der rote Faden zu unseren Fachbeiträgen

Dieser Artikel ist Teil 5 der Serie «Leittechnik im Rechenzentrum». Teil 1, «Commissioning L1 bis L5 im Rechenzentrum einfach erklärt», beschreibt, wie Inbetriebnahme-Stufen im Rechenzentrum aufgebaut sind und warum die Schnittstelle zwischen BMS und EPMS ein eigenständiger Commissioning-Schritt ist. Teil 2, «BACnet/SC als Schutz für die Kühlung», erläutert, warum BACnet/SC als Protokoll für die Schnittstelle zwischen den Systemen besonders geeignet ist. Teil 3, «PUE richtig messen nach EN 50600», zeigt, welche Messdaten das EPMS liefern muss, damit der PUE-Wert normkonform berechnet werden kann. Teil 4, «Abwärme aus dem Rechenzentrum nach MuKEn Art. 1.18», beschreibt, welche Daten aus BMS und EPMS für die Abwärmenutzung relevant sind. Teil 6, «Flüssigkühlung und Gebäudeautomation», greift die Systemarchitektur erneut auf und zeigt, wie sich Flüssigkühlsysteme in die bestehende BMS-Struktur integrieren lassen.

Für Bestandsanlagen empfehlen wir den Einstieg über Teil 1 der Serie «Rechenzentrum im Bestand: Analyse, Optimierung, Sicherheit», «Leittechnik-Check im bestehenden Rechenzentrum». Wer das Thema Lastenheft vertiefen möchte, findet in unserem Artikel «Das GA-Lastenheft: Was wirklich drinstehen muss» eine ausführliche Grundlage. Und wer die Ausschreibung und Abnahme von BACnet-Systemen verstehen möchte, findet in «Vom Lastenheft zur Abnahme: Der BACnet-Planungsprozess in der Praxis» einen praxisnahen Überblick.

Fazit

BMS und EPMS sind zwei Systeme mit unterschiedlichen Aufgaben, unterschiedlichen Verfügbarkeitsanforderungen und unterschiedlichen Sicherheitsprofilen. Die Trennung ist keine Sparübung und kein Kompromiss. Sie ist die richtige Architekturentscheidung für ein Rechenzentrum, das im Störfall handlungsfähig bleiben muss.

Die Trennung funktioniert nur, wenn die Datenschnittstelle sauber definiert, protokollkonform umgesetzt und vollständig geprüft ist. Eine Schnittstelle, die im Lastenheft fehlt, wird in der Ausführung zum Streitpunkt. Eine Schnittstelle, die nie getestet wurde, wird im Störfall zur Lücke. Und eine Visualisierungsebene, die Daten aus beiden Systemen zusammenführt, ohne in den Betrieb einzugreifen, gibt dem Leitstand das vollständige Bild, das er im Störfall braucht.

Die Grundlage dafür wird im Lastenheft gelegt. Wer dort die Systemgrenzen, die Datenpunktliste, das Protokoll und die Anforderungen an den Schnittstellentest klar beschreibt, spart sich in der Ausführung viel Koordinationsaufwand und in der Abnahme viel Diskussion.

Sie haben Fragen dazu?

Sie planen ein neues Rechenzentrum oder überprüfen die Systemarchitektur einer Bestandsanlage? Wir unterstützen Sie bei der Abgrenzung von BMS und EPMS, bei der Formulierung des Lastenhefts und bei der Prüfung der Schnittstelle. Nehmen Sie Kontakt auf über wenget.ch oder info@wenget.ch.

Quellenverzeichnis

• EN 50600-2-6: Informationstechnik, Einrichtungen und Infrastrukturen von Rechenzentren, Teil 2-6: Managementsysteme für Rechenzentren
• EN 50600-4-2: Informationstechnik, Einrichtungen und Infrastrukturen von Rechenzentren, Teil 4-2: Power Usage Effectiveness (PUE)
• ISO/IEC 30134-2: Information technology, Data centres key performance indicators, Part 2: Power Usage Effectiveness (PUE)
• SN EN ISO 16484-5 (SIA 386.155): Datenkommunikationsprotokoll BACnet
• SN EN ISO 52120-1 (SIA 386.111): Energieeffizienz von Gebäuden, Beitrag der Gebäudeautomation und Gebäudemanagement
• Eigene Projekterfahrung der WENGET GmbH aus GA-Planung, Lastenhefterstellung, Schnittstellenprüfung und Inbetriebnahmebegleitung in Rechenzentren