BACnet/SC Infrastruktur: Was brauche ich, und was nicht?

In Teil 1 haben wir geklärt, was BACnet/SC ist und warum es ein Paradigmenwechsel ist: verschlüsselte, zertifikatsbasierte Kommunikation über WebSocket und TLS 1.3 statt Klartext-Broadcast. Jetzt wird es konkret und praktisch. Denn sobald die Entscheidung für BACnet/SC gefallen ist, kommt die entscheidende Frage: Was brauche ich dafür eigentlich, an Geräten, an Netzwerk, an Organisation? Und mindestens ebenso wichtig: Was brauche ich nicht?

Diese Frage entscheidet über Aufwand, Kosten und Betriebssicherheit, und sie lässt sich mit etwas Struktur klar beantworten. Wer die Infrastruktur überdimensioniert, zahlt für Komplexität, die niemand braucht. Wer sie unterschätzt, steht nach der Migration mit Geräten da, die sich nicht verbinden, oder mit Zertifikaten, um die sich niemand kümmert. Dieser Teil ordnet die Infrastruktur in drei Bausteine und zieht eine klare Linie zwischen dem, was die Gebäudeautomation liefert, und dem, was die IT bereitstellen muss.

Baustein 1: Die Hub-Architektur

BACnet/SC ersetzt das flache Broadcast-Netz durch eine sternförmige Struktur. Im Zentrum steht der Primary Hub, die Vermittlungsstelle, über die alle Knoten ihre Verbindungen aufbauen. Anders als ein klassischer Router leitet der Hub keine Broadcasts weiter, sondern verwaltet stehende, gesicherte WebSocket-Verbindungen zu jedem angemeldeten Gerät.

Drei Punkte sind bei der Auslegung entscheidend.

Genau ein Primary Hub pro Netz. Der Primary Hub ist die zentrale Rolle. Er kann als eigenständiges Gerät, als Funktion in einer leistungsfähigen Automationsstation oder als Software auf einem Server realisiert sein. Wichtig ist, dass er ausreichend dimensioniert ist: Jede Verbindung kostet Ressourcen, und bei mehreren Hundert Knoten wird der Hub zum kritischen Element.

Ein Failover Hub für die Verfügbarkeit. Fällt der Primary Hub aus, steht ohne Vorkehrung die gesamte Kommunikation still. Der optionale Failover Hub übernimmt in diesem Fall automatisch. Für jede Anlage, die mehr als reine Komfortfunktionen steuert, ist ein Failover Hub deshalb nicht Luxus, sondern Pflicht. Die Knoten kennen beide Hubs und wechseln selbstständig.

Direct Connections gezielt einsetzen. Zwei Knoten mit hohem, dauerhaftem Datenaustausch, etwa eine Automationsstation und ihr Leitsystem, können eine direkte Verbindung aufbauen, ohne den Hub zu belasten. Das ist ein nützliches Werkzeug, aber kein Ersatz für die Hub-Architektur. Wer alles über Direct Connections lösen will, baut sich ein unübersichtliches Geflecht und verliert den zentralen Überblick.

Ein wichtiger Gewinn: BBMDs entfallen vollständig. Die gesamte Broadcast-Verwaltung, die in klassischen BACnet/IP-Netzen für Aufwand und Fehler sorgt, wird durch die Hub-Logik ersetzt. Das vereinfacht die Netzplanung spürbar.

Ein praktischer Hinweis zur Dimensionierung: Die Anzahl gleichzeitiger Verbindungen und der zu erwartende Datenverkehr bestimmen, wie leistungsfähig der Hub sein muss. Für eine kleine Anlage mit wenigen Dutzend Knoten genügt oft eine Hub-Funktion in einer vorhandenen Automationsstation. Bei mehreren Hundert Knoten oder verteilten Liegenschaften lohnt sich ein dedizierter Hub oder eine Server-basierte Lösung. Wer hier zu knapp plant, riskiert Engpässe, die im Betrieb schwer nachzurüsten sind; wer massiv überdimensioniert, zahlt für Reserven, die nie gebraucht werden. Die realistische Abschätzung der Knotenzahl über die gesamte Lebensdauer der Anlage ist deshalb ein Planungsschritt, den man nicht überspringen sollte.

Baustein 2: Die PKI, Zertifikate als Fundament

Der sicherheitskritischste und zugleich am meisten unterschätzte Baustein ist die Public-Key-Infrastruktur (PKI). BACnet/SC vertraut nicht der Netzwerkadresse, sondern dem Zertifikat. Jeder Knoten, jeder Hub, jede Station, jedes Gateway, braucht einen privaten Schlüssel und ein signiertes Betriebszertifikat (Operational Certificate).

Die Kette funktioniert so: Eine vertrauenswürdige Stelle, die Certificate Authority (CA), signiert die Zertifikate der Geräte. Zwei Knoten vertrauen einander, weil beide ein Zertifikat derselben CA vorweisen können. Damit ist die Identität kryptografisch nachgewiesen, nicht bloss behauptet.

Für die Praxis ergeben sich daraus konkrete Anforderungen:

• Eine CA muss existieren. Das kann eine unternehmenseigene CA sein, eine von der IT betriebene interne PKI oder ein spezialisierter Dienst. Für abgeschlossene GA-Netze reicht oft eine dedizierte interne CA.
• Zertifikate haben eine Laufzeit. Sie müssen vor Ablauf erneuert werden. Läuft ein Zertifikat unbemerkt ab, fällt der betroffene Knoten aus der Kommunikation: ein Ausfall, der ohne Zertifikatsverwaltung schwer zu diagnostizieren ist.
• Es braucht einen Prozess, keine Einmalaktion. Ausrollen, Erneuern, Widerrufen (Revocation) und das Ersetzen bei Gerätetausch müssen organisatorisch geregelt sein. Zertifikatsverwaltung ist eine Daueraufgabe des Betriebs.

Wer diesen Baustein ignoriert, hat am Ende eine technisch sichere Anlage, die nach 24 oder 36 Monaten reihenweise ausfällt, weil niemand die Zertifikate erneuert hat. Das Zertifikatskonzept gehört deshalb bereits in die Planung, nicht erst in den Betrieb.

Eine häufige Frage lautet: selbstsignierte Zertifikate oder eine echte CA? Selbstsignierte Zertifikate sind schnell erstellt und für einen ersten Test verlockend. Für den produktiven Betrieb sind sie aber problematisch, weil jedes Gerät jedem anderen einzeln vertrauen müsste, das skaliert nicht und wird schnell unübersichtlich. Eine gemeinsame CA löst das elegant: Alle Knoten vertrauen einer Stelle, und neue Geräte lassen sich einfach in die bestehende Vertrauenskette aufnehmen. Für eine ernsthafte BACnet/SC-Anlage führt an einer CA-basierten Lösung deshalb kaum ein Weg vorbei. Ob diese CA von der IT betrieben oder als Dienst bezogen wird, ist eine organisatorische Entscheidung, keine technische Hürde.

Baustein 3: Die Netzwerkanforderungen

Der dritte Baustein ist das Netzwerk selbst. Hier liegt die gute Nachricht: BACnet/SC passt sauber in moderne IT-Netze, weil es sich wie ein normaler, verschlüsselter Dienst verhält.

Ein definierter Port. BACnet/SC nutzt gesicherte WebSocket-Verbindungen. Typisch ist der Betrieb über einen definierten TCP-Port (häufig 443, der Standard-Port für gesicherte Verbindungen, oder ein dediziert festgelegter Port). Statt eines breiten Spektrums an Broadcast- und Unicast-Verkehr gibt es einen klar umrissenen, kontrollierbaren Kommunikationsweg.

Namensauflösung und Erreichbarkeit. Knoten müssen ihren Hub finden. In der Praxis geschieht das über feste Adressen oder über DNS. Eine saubere, dokumentierte Namensauflösung erspart im Betrieb viel Fehlersuche.

Zeitsynchronisation. Zertifikate haben Gültigkeitszeiträume. Weicht die Uhr eines Geräts stark ab, kann es ein eigentlich gültiges Zertifikat als abgelaufen oder noch nicht gültig ablehnen. Eine verlässliche Zeitquelle (NTP) im Netz ist deshalb keine Nebensache, sondern eine Voraussetzung.

Firewall-Regeln. Weil der Verkehr auf einen Port konzentriert ist, lässt sich die Firewall sauber konfigurieren. Das ist ein echter Vorteil gegenüber BACnet/IP mit seinen schwer durch Firewalls zu führenden Broadcasts.

Segmentierung bleibt sinnvoll. BACnet/SC verschlüsselt zwar den Verkehr, doch das ersetzt keine vernünftige Netzarchitektur. Die Gebäudeautomation gehört weiterhin in ein eigenes Segment (etwa ein VLAN), das kontrolliert mit der übrigen IT verbunden ist. Verschlüsselung und Segmentierung ergänzen sich: Die eine schützt den Inhalt der Kommunikation, die andere begrenzt, wer überhaupt in die Nähe der Geräte kommt. Erst zusammen ergeben sie eine belastbare Sicherheitsarchitektur.

Wer liefert was? GA und IT im Zusammenspiel

BACnet/SC zwingt zwei Welten an einen Tisch, die früher getrennt gearbeitet haben. Ohne klare Zuständigkeiten entstehen Lücken, in denen niemand verantwortlich ist. Eine praxisbewährte Aufteilung sieht so aus.

Die Gebäudeautomation liefert: die BACnet/SC-fähigen Geräte, die Hub-Funktion (als Gerät oder Software), das Objektmodell und die Datenpunkte sowie das fachliche Zertifikatskonzept, also welches Gerät welches Zertifikat braucht.

Die IT stellt bereit: die CA oder deren Anbindung, die Netzwerkinfrastruktur (Segmentierung, Ports, Firewall-Regeln), die Namensauflösung (DNS), die Zeitsynchronisation (NTP) und das Monitoring des Netzwerkverkehrs.

Gemeinsam verantwortet werden: der Zertifikats-Lebenszyklus (wer erneuert wann?), die Notfallprozesse (was passiert bei Hub-Ausfall oder Zertifikatsproblem?) und die Dokumentation. Genau an dieser Schnittstelle entscheidet sich, ob eine BACnet/SC-Anlage im Betrieb stabil läuft oder zur Dauerbaustelle wird.

Kurz erklärt: Eine BACnet/SC-Infrastruktur besteht aus drei Bausteinen: der Hub-Architektur (Primary plus Failover), der PKI mit CA und Betriebszertifikaten sowie den Netzwerkanforderungen (definierter Port, DNS, NTP, Firewall). Die GA liefert Geräte und Hub, die IT stellt CA, Netz und Zeit bereit, der Zertifikats-Lebenszyklus wird gemeinsam getragen.

Was Sie nicht brauchen

Genauso wichtig wie die Liste des Notwendigen ist die Entwarnung bei verbreiteten Fehlannahmen. Vieles, was BACnet/SC angeblich verlangt, ist gar nicht nötig.

Kein komplett neues Netzwerk. BACnet/SC läuft im bestehenden IP-Netz. Es braucht kein physisch getrenntes Parallelnetz, sondern eine saubere Segmentierung, die man ohnehin haben sollte.

Keine teure externe PKI-Suite als Pflicht. Für ein abgeschlossenes GA-Netz genügt in vielen Fällen eine dedizierte interne CA. Grosse, unternehmensweite PKI-Produkte sind möglich, aber nicht zwingend.

Kein Komplettaustausch aller Geräte am ersten Tag. BACnet/SC und BACnet/IP können parallel betrieben werden. Wie diese Koexistenz konkret aussieht und in welcher Reihenfolge migriert wird, ist das Thema von Teil 3.

Keine Broadcast-Verwaltung mehr. BBMDs, die in BACnet/IP-Netzen viel Aufwand verursachen, entfallen. Das ist eine Vereinfachung, kein Zusatzaufwand.

Kein Spezial-Know-how für Kryptografie im Alltag. Die kryptografischen Details, welche Cipher Suite, welcher Schlüsselaustausch, sind im Standard festgelegt und von den Geräten umgesetzt. Betreiber und Planer müssen keine Verschlüsselungsexperten werden. Wichtig ist das Verständnis der Zusammenhänge und ein gepflegter Zertifikatsprozess, nicht die Beherrschung mathematischer Feinheiten. Genau das ist die Stärke eines standardisierten Ansatzes: Die Komplexität steckt im Protokoll, nicht im täglichen Betrieb.

Typische Integrationshürden

Aus der Projekterfahrung lassen sich einige wiederkehrende Stolpersteine benennen. Wer sie kennt, plant sie ein.

Die erste Hürde ist organisatorisch: GA und IT sprechen unterschiedliche Sprachen. Der GA-Fachmann denkt in Datenpunkten, der IT-Verantwortliche in Ports und Zertifikaten. Ein gemeinsames Vokabular und ein früher Termin zwischen beiden Seiten lösen die meisten Probleme, bevor sie entstehen.

Die zweite Hürde ist die Zertifikatsverwaltung. Sie ist neu für die GA und wird gern unterschätzt. Wer hier von Anfang an einen Prozess und eine verantwortliche Person definiert, erspart sich spätere Ausfälle.

Die dritte Hürde ist die Gerätevielfalt. Nicht jedes Feld- oder Bestandsgerät unterstützt BACnet/SC, und ältere Geräte haben oft nicht die Rechenleistung für TLS. Hier kommen Gateways und Router ins Spiel, die als Übergang zwischen den Welten vermitteln, ein Thema, das wir in Teil 3 zur Migration vertiefen.

Eine vierte, oft übersehene Hürde ist die Firmware. BACnet/SC-Fähigkeit setzt einen aktuellen Geräte- und Firmware-Stand voraus. Bevor ein Bestandsgerät als BACnet/SC-tauglich gilt, muss geprüft werden, ob der Hersteller die Funktion überhaupt freigegeben hat und ob ein Update verfügbar ist. Eine Support-Matrix des jeweiligen Herstellers ist hier das wichtigste Planungsdokument. Wer diese Prüfung früh macht, vermeidet die unangenehme Überraschung, dass ein zentrales Gerät erst nach einem kostenpflichtigen Austausch mitspielt.

Die fünfte Hürde ist schliesslich die Erwartungshaltung. BACnet/SC wird gelegentlich als Selbstläufer verkauft, der Sicherheit auf Knopfdruck bringt. In Wahrheit ist es ein solides Werkzeug, das eine saubere Planung und einen gelebten Betriebsprozess voraussetzt. Diese Ehrlichkeit von Anfang an erspart allen Beteiligten Enttäuschungen, und ist letztlich der beste Schutz für die Investition.

Fazit

Eine BACnet/SC-Infrastruktur ist überschaubar, wenn man sie strukturiert angeht. Drei Bausteine tragen das Ganze: eine Hub-Architektur mit Failover, eine PKI mit gepflegten Zertifikaten und ein Netzwerk, das definierte Ports, Namensauflösung und Zeitsynchronisation bereitstellt. Der eigentliche Erfolgsfaktor ist aber nicht die Technik, sondern die klare Aufteilung zwischen GA und IT, und ein Prozess für den Zertifikats-Lebenszyklus.

Wer diese Punkte in der Planung berücksichtigt, vermeidet die beiden häufigsten Fehler: die überdimensionierte Infrastruktur, die niemand braucht, und die unterschätzte Zertifikatsverwaltung, die nach zwei Jahren zu Ausfällen führt. Damit ist das Fundament gelegt. Und die gute Nachricht bleibt: Vieles, was der Umstieg angeblich verlangt, ein neues Netz, ein Komplettaustausch, tiefes Krypto-Wissen, ist gar nicht nötig. Was zählt, ist die richtige Struktur und eine klare Verantwortung.

Diese Serie ergänzt «BACnet Objekte verstehen» (Mechanik der Objekttypen) und «BACnet Planung: Das Fundament» (Planungsprozess). Der nächste Teil zeigt, wie aus dem Wissen um Grundlagen und Infrastruktur ein konkreter Migrationsweg wird: Teil 3 beschreibt Schritt für Schritt, wie eine bestehende BACnet/IP-Anlage auf BACnet/SC umgestellt wird, inklusive Koexistenz, Reihenfolge und Rückfallebene.

Sie haben Fragen dazu?

Sprechen Sie uns an, wir unterstützen Betreiber, Planer und IT-Verantwortliche bei Konzeption, Migration und Abnahme sicherer BACnet/SC-Infrastrukturen.

WENGET GmbH E-Mail: info@wenget.ch Telefon: +41 44 552 34 88

Quellenverzeichnis

• ASHRAE, «Standard 135, Annex zur gesicherten Datenverbindungsschicht (BACnet/SC)», ASHRAE
• BACnet International, «BACnet Secure Connect: Implementation Guide»
• NIST, «SP 800-82, Guide to Operational Technology (OT) Security»
• IETF RFC 8446, «The Transport Layer Security (TLS) Protocol Version 1.3»
• IETF RFC 6455, «The WebSocket Protocol»
• ISO 16484-5, «Building automation and control systems: Part 5: Data communication protocol (BACnet)»