Funktionsänderungen der GA wie Eingriffe in ein Betriebssystem behandeln
Eine moderne Gebäudeautomation besteht nicht nur aus Hardware. Ein erheblicher Teil ihrer Funktion wird durch Software, Parameter, Makros, Regelalgorithmen, Zeitprogramme und Schnittstellen bestimmt. Eine vermeintlich kleine Änderung kann deshalb Auswirkungen auf Energieverbrauch, Komfort, Verfügbarkeit oder sicherheitsrelevante Funktionsketten besitzen.
Die bestehende Dokumentationsseite nennt Change- und Release-Prozesse bereits ausdrücklich als Instrument zum Schutz der Integrität der Leittechnik. Die Betreiberpflichtenseite fordert zudem keine Funktionsänderung ohne Test, Freigabe, Dokumentation und Rollback-Plan.
GA-Änderungen kontrolliert und nachvollziehbar steuern
Change und Release unterscheiden
Ein Change ist eine konkrete Änderung.
Ein Release bündelt mehrere geprüfte Änderungen zu einem kontrollierten Software- oder Konfigurationsstand.
Diese Unterscheidung wird besonders bei großen GA-Systemen mit vielen Automationsstationen relevant.
Ein Change sollte mindestens beschreiben:
Anlass,
betroffene Anlage,
bisheriger Zustand,
gewünschter Zustand,
erwartete Wirkung,
mögliche Nebenwirkungen,
Verantwortlicher.
Kleine Standardänderungen können vereinfachte Verfahren nutzen.
Kritische Änderungen benötigen eine intensivere Prüfung.
Eine Änderung an einer Regelungsfunktion kann Auswirkungen besitzen auf:
Vor Freigabe ist deshalb zu verstehen, welche Funktionen voneinander abhängig sind.
ISO 16484-1:2024 behandelt ausdrücklich die Projektimplementierung und Integration anderer Systeme in BACS; genau diese Integrationsperspektive bleibt auch bei späteren Änderungen relevant.
Ausgangsstand sichern
Vor jeder relevanten Änderung sollte der aktuelle Software- beziehungsweise Konfigurationsstand gesichert werden.
Dadurch entsteht eine belastbare Rückfallmöglichkeit.
Die Sicherung sollte eindeutig der betroffenen Station und Version zugeordnet sein.
Wo möglich, werden Änderungen zunächst:
offline,
in Testumgebung,
an einem Pilotbereich
Ist dies nicht möglich, sollte zumindest ein geeignetes Wartungsfenster mit klarer Betriebsbeobachtung gewählt werden.
Rollback vorher definieren
Vor Beginn sollte feststehen:
Unter welchen Bedingungen wird abgebrochen und auf den alten Stand zurückgegangen?
Beispiele:
Anlage erreicht Sollfunktion nicht,
unerwartete Alarme,
andere Systeme reagieren fehlerhaft,
Änderung dauert länger als vorgesehen.
Rollback ist damit Teil der Planung und nicht improvisierte Schadensbegrenzung.
Funktion nach Änderung prüfen
Nach dem Change wird nicht nur kontrolliert, ob der Code geladen wurde.
Geprüft wird die reale Anlagenwirkung.
Dazu können gehören:
Sensor-/Aktorfunktion,
Regelverhalten,
Alarmierung,
Trends,
Schnittstellen,
Visualisierung.
Nach erfolgreicher Freigabe sind je nach Änderung anzupassen:
Funktionsbeschreibung,
Datenpunktliste,
Parametersatz,
Quellcode,
Visualisierung,
Revisionshistorie.
Die bestehenden Betriebsseiten fordern zu Recht eine kontinuierliche Fortschreibung der GA-Bestandsunterlagen.
Veränderung ermöglichen, ohne die Systemintegrität zu verlieren
Eine Gebäudeautomation muss veränderbar bleiben.
Professionelles Change Management sorgt jedoch dafür, dass kein Eingriff unkontrolliert erfolgt und jederzeit nachvollziehbar bleibt, welche Funktion wann, warum, von wem und mit welchem Ergebnis verändert wurde.
