Migration auf BACnet/SC: Schritt für Schritt

Eine bestehende BACnet/IP-Anlage auf BACnet/SC umzustellen, ist kein Knopfdruck und kein Wochenendprojekt. Es ist ein geplanter Umbau am laufenden Betrieb, vergleichbar mit dem Austausch der Verkabelung in einem Gebäude, in dem weiterhin geheizt, gelüftet und gearbeitet wird. Wer das unterschätzt, riskiert Ausfälle bei Heizung, Lüftung und Kälte, verlorene Trenddaten und frustrierte Betreiber. Wer es richtig plant, migriert Etappe für Etappe, ohne dass jemand im Gebäude etwas davon merkt. Dieser Teil zeigt, wie eine saubere Migration von der ersten Bestandsaufnahme bis zur schrittweisen Umschaltung abläuft.

Warum Migration kein «Big Bang» ist

Die Versuchung ist gross, an einem Stichtag alles umzustellen: alte Anlage aus, neue Anlage ein. In der Praxis funktioniert das fast nie. Eine gewachsene Gebäudeautomation besteht aus Geräten unterschiedlicher Hersteller, unterschiedlicher Baujahre und unterschiedlicher Firmware-Stände. Nicht jedes Gerät versteht BACnet/SC, und nicht jedes Gerät lässt sich gleichzeitig umstellen. Ein harter Schnitt würde bedeuten, dass ein einziger Fehler die gesamte Liegenschaft lahmlegt.

Die realistische Antwort heisst schrittweise Migration mit Coexistence. BACnet/IP und BACnet/SC laufen dabei eine Zeit lang parallel, verbunden über Router oder Gateways. So lässt sich Gerät für Gerät, Anlage für Anlage oder Etage für Etage umstellen, mit einem klaren Rückweg, falls etwas nicht wie erwartet funktioniert. Migration wird damit zu einem kontrollierten Prozess statt zu einem Risiko.

Schritt 1: Bestandsanalyse

Jede Migration beginnt mit einer ehrlichen Bestandsaufnahme. Man kann nur migrieren, was man kennt. In dieser Phase wird die bestehende BACnet/IP-Anlage vollständig dokumentiert: Welche Geräte sind im Netz? Welche Controller, welche Bedienstationen, welche Router, welche BBMDs? Welche Firmware-Stände sind installiert, und von welchem Hersteller stammen die Komponenten?

Ebenso wichtig ist die Netzwerksicht. Welche Subnetze existieren, wie sind sie verbunden, wo sitzen die Broadcast-Grenzen? Wie viele Datenpunkte werden ausgetauscht, und welche davon sind zeitkritisch, etwa Alarme oder Regelgrössen? Am Ende dieser Phase steht eine Inventarliste, die jedes Gerät mit Typ, Firmware, Standort und Funktion erfasst. Diese Liste ist das Fundament für alle weiteren Entscheidungen.

Ein häufiger Fehler ist, diese Phase abzukürzen. «Wir wissen doch, was wir haben» ist selten wahr. Gerade in Bestandsanlagen tauchen bei genauem Hinsehen vergessene Geräte, undokumentierte Sonderlösungen und längst abgekündigte Controller auf. Genau diese Überraschungen sind es, die eine schlecht geplante Migration zum Stillstand bringen. Eine Stunde mehr in der Analyse spart Tage im Projekt.

Schritt 2: Firmware- und Kompatibilitätsprüfung

BACnet/SC ist nicht rückwirkend für jedes Gerät verfügbar. Ob ein Controller BACnet/SC beherrscht, hängt von seiner Hardware und vor allem von seiner Firmware ab. Viele ältere Geräte besitzen schlicht nicht die Rechenleistung, um die TLS-Verschlüsselung in Echtzeit zu verarbeiten. Andere unterstützen BACnet/SC erst ab einer bestimmten Firmware-Version, die per Update nachgerüstet werden muss.

In dieser Phase wird jedes Gerät aus der Inventarliste einer von drei Kategorien zugeordnet. Erstens: Geräte, die BACnet/SC direkt unterstützen oder per Firmware-Update dorthin gebracht werden können. Zweitens: Geräte, die kein BACnet/SC können, aber über ein Gateway angebunden werden. Drittens: Geräte am Ende ihres Lebenszyklus, die im Rahmen der Migration ohnehin ersetzt werden sollten. Diese Einteilung entscheidet später über Aufwand, Kosten und Reihenfolge.

Wichtig ist, dass Gateways und Router selbst auf einem aktuellen Stand sind. Ein Universal-BACnet-Router, der zwischen BACnet/IP und BACnet/SC vermitteln soll, muss den aktuellen BACnet-Revisionsstand beherrschen. Ein veraltetes Gateway wird sonst zum Flaschenhals, der die ganze Migration ausbremst. Es lohnt sich, die Kompatibilitätsmatrix der Hersteller genau zu lesen, statt sich auf Marketingversprechen zu verlassen.

Schritt 3: Der Coexistence-Modus

Das Herzstück jeder schrittweisen Migration ist die Koexistenz. BACnet/IP und BACnet/SC sind auf Protokollebene unterschiedlich, das eine sendet ungeschützte Broadcasts, das andere gesicherte Punkt-zu-Punkt-Verbindungen über einen Hub. Trotzdem können beide Welten miteinander sprechen, wenn ein Router oder Gateway dazwischensteht, der die Nachrichten übersetzt und weiterleitet.

In der Praxis bedeutet das: Der neue BACnet/SC-Hub wird aufgebaut und in Betrieb genommen, während die alte BACnet/IP-Anlage weiterläuft. Ein Router verbindet beide Netze. Geräte, die bereits umgestellt sind, kommunizieren gesichert über den Hub. Geräte, die noch nicht umgestellt sind, kommunizieren weiterhin über BACnet/IP. Der Router sorgt dafür, dass beide Gruppen sich weiterhin gegenseitig sehen und Daten austauschen können.

Diese Brücke ist der Schlüssel dazu, dass die Anlage während der gesamten Migration funktionsfähig bleibt. Regelkreise über die Netzgrenze hinweg funktionieren weiter, Alarme werden weitergeleitet, und die Bedienstation sieht nach wie vor alle Datenpunkte. Die Koexistenz ist kein Dauerzustand, sondern ein Übergang, aber ein Übergang, der Wochen oder Monate dauern darf, ohne den Betrieb zu stören.

Schritt 4: Die Migrationsreihenfolge festlegen

Sobald die Brücke steht, stellt sich die Frage: Womit anfangen? Die Reihenfolge ist keine Geschmacksfrage, sondern folgt einer klaren Logik. Bewährt hat sich, mit einem unkritischen, gut überschaubaren Bereich zu starten, etwa einer einzelnen Lüftungsanlage oder einer Etage mit wenigen Geräten. Dort lässt sich der Prozess erproben, ohne dass ein Fehler grosse Folgen hätte.

Erst wenn dieser Pilotbereich stabil läuft, folgen die nächsten Abschnitte. Zeitkritische und sicherheitsrelevante Anlagen, etwa die Kälteversorgung eines Rechenzentrums oder die Entrauchung, werden bewusst spät migriert, wenn der Prozess eingespielt ist. Geräte, die ohnehin ersetzt werden, kommen gleich als BACnet/SC-fähige Neugeräte ins Netz und überspringen den Umweg über das Gateway.

Eine gute Migrationsreihenfolge berücksichtigt auch den Betrieb. Manche Anlagen lassen sich nur in Randzeiten oder in der Übergangszeit umstellen, etwa eine Heizung, die man sinnvollerweise nicht mitten im Winter anfasst. Die Reihenfolge ist damit immer ein Zusammenspiel aus technischer Abhängigkeit und betrieblicher Realität. Sie gehört schriftlich festgehalten und mit dem Betreiber abgestimmt.

Geräte ohne BACnet/SC: Gateways und Konverter

Eine der häufigsten Fragen lautet: Was passiert mit Geräten, die kein BACnet/SC können und auch kein Update bekommen? Die Antwort ist ein Gateway. Ein solches Gerät spricht auf der einen Seite gesichertes BACnet/SC mit dem Hub und auf der anderen Seite klassisches BACnet/IP oder sogar BACnet MS/TP mit den alten Geräten. Es kapselt die unsichere Insel und bindet sie kontrolliert an die neue, gesicherte Welt an.

Damit lassen sich auch Anlagen weiterbetreiben, deren Ersatz sich kurzfristig nicht lohnt. Wichtig ist allerdings, ehrlich zu bleiben: Ein Gateway macht ein altes Gerät nicht sicher. Der Verkehr hinter dem Gateway bleibt unverschlüsselt. Das Gateway schützt lediglich den Weg vom Gateway zum Hub. Deshalb gehören solche unsicheren Inseln in ein streng abgetrenntes Netzsegment, damit ein kompromittiertes Altgerät nicht zum Einfallstor für die ganze Anlage wird.

Gateways sind also ein legitimes Übergangswerkzeug, aber kein Dauerersatz für eine echte Modernisierung. Ein guter Migrationsplan hält fest, welche Gateways nur temporär gedacht sind und wann die dahinterliegenden Geräte endgültig ersetzt werden. So wird aus der Übergangslösung kein Dauerprovisorium, das in fünf Jahren niemand mehr versteht.

Die Rolle der IT während der Migration

Eine BACnet/SC-Migration ist nicht allein Sache der Gebäudeautomation. Sobald Zertifikate, Firewall-Regeln und Netzsegmente ins Spiel kommen, wird die IT-Abteilung zum unverzichtbaren Partner. Genau hier scheitern viele Projekte nicht an der Technik, sondern an der Organisation: Die GA plant die Umstellung, doch niemand hat die IT rechtzeitig eingebunden, um den benötigten Port freizuschalten oder die Zertifikatsstelle bereitzustellen.

Deshalb gehört die IT von der ersten Planungssitzung an mit an den Tisch. Sie muss wissen, welcher Port für den Hub geöffnet werden soll, in welchem Segment die Anlage liegt, wer die Zertifikate ausstellt und wer sie erneuert. Diese Punkte lassen sich nicht in der Umschaltnacht klären, sondern müssen Wochen vorher vereinbart sein. Eine klare Verantwortungsmatrix, wer liefert was, wer entscheidet was, verhindert, dass die Migration an einer fehlenden Freigabe hängen bleibt.

In der Praxis bewährt sich ein kurzes gemeinsames Protokoll, das GA und IT vor jedem Migrationsschritt abhaken: Port offen, Zertifikat gültig, Segment vorbereitet, Rollback bereit. Solche Checklisten wirken banal, aber sie sind der Unterschied zwischen einer ruhigen Umschaltung und einer hektischen Fehlersuche mitten in der Nacht.

Typische Stolpersteine, und wie man sie vermeidet

Einige Fehler tauchen in Migrationsprojekten immer wieder auf. Der erste ist die unterschätzte Zeit für Firmware-Updates: Ein Update pro Gerät klingt harmlos, doch bei einhundert Geräten summiert sich das schnell, und nicht jedes Update läuft reibungslos. Wer hier keinen Puffer einplant, gerät unter Druck. Der zweite Stolperstein sind vergessene Abhängigkeiten zwischen Anlagen, ein Regelkreis, der über zwei noch nicht gemeinsam migrierte Geräte läuft, kann während der Umstellung kurz aussetzen, wenn die Reihenfolge nicht stimmt.

Ein dritter, oft schmerzhafter Punkt ist die Zeitsynchronisation. TLS-Zertifikate haben ein Gültigkeitsfenster, und ein Gerät mit falsch gestellter Uhr kann ein völlig gültiges Zertifikat ablehnen, weil es meint, es sei noch nicht gültig oder bereits abgelaufen. Eine zuverlässige NTP-Zeitquelle ist deshalb keine Kür, sondern Voraussetzung. Wer diese drei Punkte, Zeitpuffer, Abhängigkeiten, Zeitsynchronisation, von Anfang an mitdenkt, umgeht die häufigsten Ursachen für Migrationsstress.

Schritt 5: Testszenario und Rollback-Planung

Kein Migrationsschritt ohne Testplan und ohne Rückweg. Bevor ein Bereich produktiv umgestellt wird, gehört definiert, was «erfolgreich» konkret bedeutet: Bauen alle Geräte die gesicherte Verbindung zum Hub auf? Werden alle Datenpunkte korrekt gelesen und geschrieben? Kommen Alarme rechtzeitig an, und laufen die Trendaufzeichnungen ohne Lücke weiter?

Genauso wichtig ist der Rollback. Für jeden Schritt muss klar sein, wie man im Fehlerfall zum vorherigen Zustand zurückkehrt, idealerweise per gesichertem Konfigurationsstand, der sich in Minuten wiederherstellen lässt. Die Koexistenz-Architektur hilft hier enorm: Weil die alte Anlage während der Migration weiterläuft, ist der Rückweg meist nur eine Frage der Umkonfiguration, nicht eines kompletten Wiederaufbaus. Ein dokumentierter, geprobter Rollback nimmt dem Projekt den Druck und der Migration den Schrecken.

Ein Beispiel aus der Praxis

Ein Betreiber eines grösseren Verwaltungsgebäudes wollte seine über Jahre gewachsene BACnet/IP-Anlage absichern, ohne den Betrieb zu unterbrechen. Die Bestandsanalyse zeigte rund einhundertzwanzig Geräte von drei Herstellern. Etwa die Hälfte konnte per Firmware-Update auf BACnet/SC gehoben werden, ein Viertel wurde über Gateways angebunden, der Rest stand ohnehin zur Erneuerung an.

Die Migration begann mit einer einzelnen Lüftungsanlage im Erdgeschoss als Pilot. Nachdem diese zwei Wochen stabil lief, folgten Etage um Etage. Der neue Hub und die alte Anlage liefen über einen Router parallel, sodass zu keinem Zeitpunkt Datenpunkte fehlten. Die Kälteversorgung wurde bewusst als Letztes umgestellt, in einer verkehrsarmen Randzeit und mit vorbereitetem Rollback. Nach rund drei Monaten war die gesamte Liegenschaft migriert, ohne einen einzigen ungeplanten Ausfall.

Entscheidend war rückblickend nicht ein besonders cleverer technischer Kniff, sondern die Konsequenz in der Vorbereitung. Die Inventarliste war vollständig, die Reihenfolge stand schriftlich fest, IT und GA hatten ihre Aufgaben klar verteilt, und für jeden Schritt lag ein geprobter Rollback bereit. Genau diese Nüchternheit, kein Heldentum, sondern saubere Planung, ist es, die eine Migration erfolgreich macht. Der Betreiber bemerkte von der gesamten Umstellung im Alltag praktisch nichts, und genau das war das Ziel.

Der rote Faden zu den Nachbarserien

Migration ist kein isoliertes Thema. Wer sauber migrieren will, muss die Anlage verstehen, die er migriert. Unsere Serie «BACnet Objekte verstehen» erklärt das Objektmodell und die Datenpunkte, die bei der Bestandsanalyse erfasst werden, ohne dieses Verständnis bleibt jede Inventarliste oberflächlich. Die Serie «BACnet Planung: Das Fundament» wiederum zeigt, wie eine Anlage von Grund auf richtig strukturiert wird. Beide Serien liefern das Fundament, auf dem eine gelungene Migration aufbaut. Und die vorherigen Teile dieser Serie haben erklärt, was BACnet/SC überhaupt ist und welche Infrastruktur es braucht, Wissen, das Sie in jeder Migrationsphase einsetzen.

Fazit

Eine Migration auf BACnet/SC gelingt nicht durch Mut zum grossen Schnitt, sondern durch Disziplin in kleinen Schritten. Bestandsanalyse, Kompatibilitätsprüfung, Koexistenz, durchdachte Reihenfolge und ein geprobter Rollback verwandeln ein riskantes Grossprojekt in eine Serie beherrschbarer Etappen. Gateways überbrücken die Lücke zu Altgeräten, ohne dass Sicherheit vorgegaukelt wird. Am Ende steht eine Anlage, die genauso zuverlässig läuft wie zuvor, nur eben gesichert. Wer so vorgeht, migriert nicht gegen den Betrieb, sondern mit ihm.

Sie haben Fragen dazu?

Sie planen die Migration Ihrer BACnet/IP-Anlage auf BACnet/SC und wollen sie ohne Betriebsunterbruch durchziehen? Wir begleiten Sie von der Bestandsanalyse bis zur Abnahme.

WENGET GmbH info@wenget.ch +41 44 552 34 88

Quellenverzeichnis

• ASHRAE 135: BACnet, Coexistence BACnet/IP und BACnet/SC
• BACnet International: Migration Guidance
• Herstellerinformationen zu Firmware-Updates und Kompatibilitätslisten (Siemens, Sauter, Distech)
• BSI: Empfehlungen zur Migration von OT-Netzen
• NIST SP 800-82: Guide to Operational Technology Security
• Eigene Migrationsprojekte WENGET GmbH