Für jede Prüfaussage die richtige Nachweisebene wählen
Ein geprüfter Plan, eine erfolgreiche Softwaresimulation und eine tatsächlich erreichte Raumkondition sind unterschiedliche Nachweise. Wir halten diese Ebenen getrennt. Vor der Ausführung lässt sich bewerten, ob Abläufe vollständig und widerspruchsfrei beschrieben sind. In einer geeigneten Testumgebung lässt sich anschließend die Reaktion des Programms auf definierte Eingangszustände untersuchen.
Erst am errichteten System werden tatsächliche Signalwege und Anlagenwirkungen bestätigt. Eine simulierte Luftstromrückmeldung beweist keine Luftmenge im Kanal. Der Prüfbericht benennt deshalb für jedes Ergebnis, welche Ebene untersucht wurde und welche Voraussetzungen noch offen sind. So entsteht kein verfrühter Eindruck einer vollständig betriebsbereiten Anlage.
MSR-Funktionsketten systematisch mit Testfällen prüfen
Prüffälle aus Funktionsanforderungen ableiten
Ein Testfall erhält Ausgangszustand, auslösendes Ereignis, erwartete Reaktion, zulässige Zeit und eindeutige Ergebniskriterien. Die beteiligten Signale und der verwendete Programmstand sind benannt. Ein erwartetes Ergebnis darf nicht erst nach Beobachtung des tatsächlichen Verhaltens formuliert werden.
Wir beginnen mit repräsentativen Fällen und erweitern sie um kritische Grenzen: gleichzeitige Bedienbefehle, fehlende Rückmeldung, kurzzeitige Zielerreichung oder Rückgabe einer Handvorgabe. Dabei wird geprüft, ob sowohl erlaubte Übergänge funktionieren als auch unerlaubte Übergänge verhindert werden. Die Tabelle enthält Beispiele für solche gezielten Prüfungen.
|
| Zwei widersprüchliche Befehle | Die bestätigte Auswahlregel liefert ein eindeutiges Ergebnis. | Noch kein Nachweis einer realen Stellwirkung. |
| Start ohne benötigte Rückmeldung | Keine unzulässige Freigabe; Ursache und Zeitüberschreitung sichtbar. | Eine simulierte Rückmeldung beweist nicht den Sensoranschluss. |
| Nur kurz im Zielbereich | Bereitschaft folgt der bestätigten Haltezeitlogik. | Reale Raumstabilität bleibt gesondert nachzuweisen. |
| GA-Verbindung geht verloren | Lokale Funktion und Fernstatus reagieren wie vereinbart. | Nicht automatisch ein vollständiger OT-Sicherheitstest. |
| Parameter wurde korrigiert | Betroffener Fall und relevante Nachbarfunktionen bestehen erneut. | Keine pauschale Neubewertung aller unveränderten Fachplanungen. |
Softwaretests abgrenzen und Wiederholbarkeit herstellen
Simulationen werden in einer geeigneten, vom produktiven Betrieb getrennten Umgebung durchgeführt oder über ein ausdrücklich freigegebenes, fachgerecht abgesichertes Verfahren. Das Testen rechtfertigt keine unkontrollierte Überbrückung von Schutzfunktionen. Änderungen und erzwungene Werte werden vollständig erfasst und vor Übergabe nachweislich zurückgenommen.
Die Sollreaktion wird unabhängig vom getesteten Programm beschrieben. Eine aus demselben fehlerhaften Programm erzeugte Erwartung liefert keinen belastbaren Gegencheck. Testdaten, Ablauf und Ergebnis werden so gesichert, dass nach einer Korrektur derselbe Fall erneut geprüft werden kann. Wiederholte Testläufe gehören jeweils zu einem eindeutig identifizierten Funktionsstand.
Am Objekt die vollständige Wirkkette verfolgen
Die Prüfung verfolgt den Anwenderbefehl über Auswahl- und Freigabelogik, Regler, Ausgang und Aktor bis zur benötigten Rückmeldung. Bei einer optionalen GA-Anbindung kommen Übertragung, Darstellung und gegebenenfalls Rückgabe der Fernsteuerung hinzu. Sichtbare Bedienwerte ersetzen keine Prüfung der tatsächlich angeschlossenen Komponenten.
AMEV Gebäudeautomation 2023 behandelt die Funktionsprüfung in Verbindung mit den Bedienplätzen und ihre Dokumentation. Unser Verfahren konkretisiert diese Perspektive für abgegrenzte RLT-Funktionsketten. Umfang, Personal, Messmittel und betriebliche Freigaben werden projektspezifisch vereinbart; ein Softwaretestpaket beinhaltet nicht automatisch vollständige Inbetriebnahmeleistungen.
Fehler schließen und betroffene Funktionen erneut bewerten
Ein Befund ist erst geschlossen, wenn die Korrektur nachgewiesen wurde. Zusätzlich werden die von der Änderung möglicherweise betroffenen Nachbarfunktionen geprüft. Eine geänderte Startfreigabe kann beispielsweise Bereitschaft, Nachlauf und übergeordnete Anzeige beeinflussen. Die Wiederholungsprüfung richtet sich daher nach den Abhängigkeiten und nicht nur nach der bearbeiteten Bildschirmmaske.
VDI 3814 Blatt 4.3 stellt die Beschreibung der Automationsaufgaben in einen durchgängigen Dokumentationszusammenhang. Wir verbinden damit eine nachvollziehbare Zuordnung von Anforderung, Funktionskennung und Test. Offene saisonale oder thermische Nachweise bleiben ausdrücklich offen; ein bestandenes Softwareprotokoll schließt sie nicht stellvertretend.
