Inbetriebnahme & SAT — Wo Architektur auf die Realität trifft

Sie haben eine Architektur entworfen. Die Diagramme stimmen, die Protokolle sind gewählt, die Netzwerksegmentierung liegt auf dem Papier. Alle haben unterschrieben. Und dann stehen Sie in der Fabrikhalle — es sind 7 Grad, die SPS kommuniziert nicht mit Ihrem Broker, und der Techniker, der das Panel verdrahtet hat, hat die RS-485 A- und B-Leitungen vertauscht.

Willkommen bei der Inbetriebnahme :)

Ich muss ehrlich sein: Für die großen Maschinenbauer ist das keine Überraschung mehr. Ein Siemens, ein Rockwell, ein ABB — sie haben ihre FAT- und SAT-Prozesse so weit standardisiert, dass Inbetriebnahme vertrautes Terrain ist. Hunderte von Projekten, Hunderte von Ingenieuren, Hunderte von Malen dieselben Fehler gemacht und in Verfahren festgehalten.

Aber die meisten Projekte, die schiefgehen, sind keine Standard-Maschinenbau-Projekte. Es sind Startups, die ihre erste Produktionslinie aufbauen und noch nicht wissen, was eine SAT beinhaltet. Es sind einzigartige Trajektorien: ein Steuerungssystem für einen spezifischen Prozess, eine Integration zwischen einer Legacy-SPS und einer neuen SCADA-Plattform, oder ein Monitoring-System, das drei Hersteller und zwei Protokolle überbrücken muss.

Dafür gibt es keine ausgereifte SAT-Vorlage, die man einfach aus dem Regal nehmen kann. Man muss Risiken, Voraussetzungen, Abhängigkeiten und Fallbacks selbst durchdenken. Und genau da läuft es oft schief.

Inbetriebnahme ist der Moment, in dem man herausfindet, ob man dieses Puzzle richtig gelöst hat.

Der ehrlichste Moment in jedem Projekt

Inbetriebnahme und Site Acceptance Testing (SAT) sind die ehrlichsten Phasen in einem technischen Projekt. Nicht weil sie zeigen, wie schön Ihr Design ist — sondern weil sie gnadenlos enthüllen, was Sie angenommen haben.

Jedes Architekturdiagramm ist ein Modell der Realität. Und jedes Modell lässt Dinge aus. Das ist kein Fehler, das ist die Funktion eines Modells. Aber während der Inbetriebnahme bezahlt man die Rechnung für alles, was man ausgelassen hat.

Die Kabellänge, die auf dem Papier kein Problem war, sich aber in der Praxis als gerade zu lang für zuverlässige Signalintegrität herausstellt. Das 24V-Netzteil, das nach vierzig Metern Kabelstrecke nur 22,3V liefert. Der Sensor, der laut Datenblatt bis 85°C funktioniert, dessen Gehäuse aber die wöchentliche Druckwäsche des Kunden nicht aushält.

Es sind selten die großen Designentscheidungen, die einen überraschen. Es sind die Voraussetzungen, die niemand formuliert hat, weil sie “offensichtlich” waren.

Zwei Welten, ein Kabel

Das Kernproblem bei der Inbetriebnahme von OT/IT-Systemen ist, dass man zwei Welten verbindet, die fundamental unterschiedlich über Zeit, Fehler und Verantwortung nachdenken.

In der IT-Welt ist eine Verbindung entweder oben oder unten. Wenn sie unten ist, hat man Redundanz, einen Fallback oder einen Retry. Deployment ist normalerweise umkehrbar. Man kann ein Rollback machen.

In der OT-Welt ist ein Ventil offen oder geschlossen. Eine Pumpe läuft oder steht still. Eine Heizung schaltet ein oder nicht. Und wenn man die falsche Entscheidung trifft, entweicht Dampf, ein Rohr friert ein oder ein Prozess stoppt. Dafür gibt es kein Rollback.

Bei der Inbetriebnahme steht man genau an diesem Schnittpunkt. Man testet nicht nur, ob Systeme funktionieren — man testet, ob sie zusammen funktionieren, unter Bedingungen, die keine der beiden Welten vollständig spezifiziert hat.

Das erlebte ich buchstäblich bei der Inbetriebnahme eines Enteisungs-Steuerungssystems für den Lufteinlass eines Kraftwerks. Das System musste die Heizung automatisch basierend auf Außentemperatur und Luftfeuchtigkeit steuern, damit Eisbildung am Einlassgitter die Anlage nicht abschalten würde.

Auf dem Papier war es einfach: Sensor liest Bedingungen, Controller berechnet Risiko, Aktuator schaltet.

In der Praxis stieß ich auf etwas, das kein Architekturdiagramm erfasst hatte: den Unterschied zwischen der Dynamik des Steuerungssystems und der Physik der Eisbildung.

Der Sensor reagierte in Millisekunden. Eisbildung spielte sich über Minuten ab. Aber die Konsequenzen eines zu späten Schaltens ließen sich nicht in Minuten beheben.

Sobald Eis am Gitter war, war es zu spät. Die Heizung musste daher einschalten, bevor die Bedingungen kritisch wurden, basierend auf einem Trend, den man in den Sensordaten erkennen musste.

Diese Erkenntnis stand nicht im Diagramm. Sie wurde nur sichtbar, als ich mit einem Feuchtigkeitsmessgerät neben dem Einlassgitter stand.

SAT ist keine Checkliste, es ist eine Verhandlung

Die meisten SAT-Dokumente, denen ich begegne, sind als aufwändige Tick-Liste strukturiert.

Punkt 4.3.2: “Überprüfen, dass das System bei Sensorausfall einen Alarm erzeugt.”

Haken. Weiter zu 4.3.3.

Das ist nicht das, was SAT sein sollte.

SAT ist der Moment, in dem man dem Kunden als Ingenieur zeigt: Das haben Sie gekauft, und so verhält es sich in Ihrer Umgebung, unter Ihren Bedingungen.

Das ist fundamental anders als eine Checkliste abzuarbeiten. Es ist eine Demonstration des Verständnisses.

Und es geht bei weitem nicht immer um die Technologie. Die schwierigsten SAT-Momente, die ich erlebt habe, waren nicht bei Systemen, die nicht funktionierten, sondern bei Operatoren, die dem System nicht vertrauten.

Technisch war alles in Ordnung. Daten kamen durch. Alarme lösten bei den richtigen Schwellenwerten aus. Die Integrationen taten, was sie sollten.

Aber die Menschen, die damit arbeiten mussten, waren an ihre eigene Art zu schauen, ihren eigenen Rhythmus, ihre eigenen Informationsquellen gewöhnt. Ein neues System, das technisch identische Daten zeigte, sie aber anders präsentierte, war für sie eine operativ völlig andere Erfahrung.

An diesem Punkt verschiebt sich die SAT von “funktioniert es?” zu:

Vertrauen die Benutzer ihm genug, um darauf zu handeln?

Das ist eine Frage, die man nicht mit einem Testprotokoll beantwortet. Man beantwortet sie, indem man neben dem Operator steht, zuhört und das System anpasst, bis es zu seiner Arbeitsweise passt.

Was kein Architekturdiagramm einem sagt

Nach genug Projekten mit Laptop und Multimeter vor Ort kommen immer wieder einige Muster zurück.

Dokumentation lügt, aber nicht absichtlich. Alle dokumentieren mit besten Absichten. Aber Dokumentation beschreibt das System wie designed, nicht wie gebaut.

Bei der Inbetriebnahme entdeckt man jede Abweichung: den Techniker, der eine Kabeltrasse anders verlegt hat, weil die ursprüngliche Route durch ein Rohr blockiert war, das nicht auf der Bauzeichnung stand. Die SPS mit einer anderen Firmware-Version als spezifiziert, weil diese Version nicht mehr erhältlich war. Den Sensor, der an einer anderen Stelle montiert ist, weil die ursprüngliche Position sich in der Praxis als unzugänglich herausstellte.

Keine dieser Abweichungen ist notwendigerweise falsch. Aber jede von ihnen kann die Inbetriebnahme verzögern.

Teste nicht das System, teste die Integration. Jede einzelne Komponente wurde wahrscheinlich schon vom Hersteller getestet. Ihre Aufgabe bei der Inbetriebnahme besteht nicht darin, zu überprüfen, dass ein Sensor misst oder ein Ventil schaltet.

Ihre Aufgabe besteht darin, zu überprüfen, dass die gesamte Kette funktioniert:

Sensor → Signal → Controller → Logik → Aktuator → physikalischer Effekt → Rückkopplung

Jeder Übergang zwischen Komponenten ist ein potenzielles Fehlerszenario. Das ist es, worauf man seine Testszenarien konzentriert.

Bring einen Rückzugsplan mit. Jedes Inbetriebnahmeprotokoll sollte einen “Fallback”-Abschnitt haben.

Wenn das neue System nicht tut, was es soll, wie kehrt man zur vorherigen Situation zurück?

In der IT ist das ein Rollback. In der OT ist das manchmal wörtlich: Kabel trennen, altes System wieder anschließen, manuell betreiben, bis man das Problem gelöst hat.

Dieser Plan muss fertig sein, bevor man mit dem Testen beginnt.

Der Kunde testet mit einem, oder man scheitert. Inbetriebnahme ohne den anwesenden Operator ist sinnlos. Nicht weil man seine Genehmigung braucht — die kommt beim SAT — sondern weil er die Voraussetzungen kennt, die nicht in der Spezifikation stehen.

“Dieses Ventil vibriert immer ein bisschen, wenn der Druck über 6 bar geht.”

“Im Winter bildet sich Kondensat am Sensorgehäuse.”

“Nach einem Stromausfall muss man diese Pumpe manuell entlüften.”

Diese Informationen stehen nicht im P&ID. Sie stecken im Operator.

Der Wert, den niemand sieht

Inbetriebnahme und SAT sind Phasen, die in der Projektplanung oft unterschätzt werden. Sie werden als “zwei Wochen Tests” am Ende eines Projekts eingeplant, als Puffer, der verkürzt werden kann, wenn der Bau in Verzug gerät.

Das ist genau falsch herum.

Inbetriebnahme ist kein Restposten. Es ist die Phase, in der Ihre Designannahmen auf die physische Realität treffen. Und diese Realität ist immer reicher, unordentlicher und spezifischer als Ihr Modell.

Ja, das macht Projekte teuer. Besonders bei Startups und Erstkunden sieht man manchmal, wie das Angebot einen Schock auslöst.

Warum zahle ich dreimal so viel für einen Sensor, den ich für zehn Euro in einem Elektronikfachgeschäft kaufen kann? Warum zeigt die Planung drei Tage Inbetriebnahme für ein System mit acht Sensoren? Warum muss ein Ingenieur dabei sein, wenn bereits alles getestet wurde?

Ich habe ein Boot, und man lernt die Antwort darauf schnell.

Jede Komponente auf einem Boot scheint drei- bis fünfmal so viel zu kosten wie das Äquivalent in einem Baumarkt. Eine Schlauchklemme. Ein Schalter. Ein Stück Leine.

Aber wenn man auf See bei schlechtem Wetter ist, zwei Meter Wellen und einem Motor, der einen zurück in den Hafen bringen muss, will man nicht die günstige Schlauchklemme, die sich nach sechs Monaten Salzwasser löst. Man will die Komponente, die spezifiziert, getestet und für diese Bedingungen geeignet ist.

Bei industriellen Systemen ist es nicht anders.

Der Sensor, der dreimal so viel kostet, ist nicht einfach dreimal so teuer, weil er einen Markennamen hat. Er ist teurer, weil er kalibriert geliefert wird. Weil die Messunsicherheit dokumentiert ist. Weil er mit einem rückverfolgbaren Kalibrierzertifikat geliefert wird. Weil der Hersteller garantiert, dass er das tut, was das Datenblatt sagt — auch nach Jahren in einer Umgebung mit Vibration, Staub, Feuchtigkeit und Temperaturschwankungen.

Diese zusätzlichen Kosten stecken nicht nur in der Komponente. Sie stecken in der Gewissheit, dass die Inbetriebnahme nicht entgleist, weil Hardware sich anders verhält als spezifiziert.

Und dasselbe gilt für Zeit.

Diese drei Tage Inbetriebnahme werden nicht damit verbracht, Knöpfe zu drücken. Sie werden damit verbracht, die Kette durchzugehen. Abweichungen zu finden, bevor sie zu Produktionsproblemen werden. Annahmen zu erkennen, die auf dem Papier logisch waren, aber vor Ort nicht zutreffen. Operatoren, Hersteller und Kunden in eine gemeinsame Arbeitsrealität zu bringen.

Inbetriebnahme kostet Zeit — nicht weil man schlecht designed hat, sondern weil die Realität immer mehr Dimensionen hat als das Modell.

Und Inbetriebnahme kostet Geld — nicht weil Ingenieure teuer sind, sondern weil man Gewissheit bezahlt in dem Moment, in dem das System funktionieren muss.

Die Ingenieure, die darin gut sind, sind nicht unbedingt die besten Architekten oder die besten Programmierer. Es sind Menschen, die mit Mehrdeutigkeit umgehen können. Die eine Fehlermeldung auf einem HMI-Bildschirm lesen und gleichzeitig auf das Geräusch hören können, das eine Pumpe macht. Die wissen, wann eine Abweichung ein Bug ist, und wann es eine Eigenschaft der Anlage ist, die man respektieren muss.

Es ist der am wenigsten glamouröse Teil des Handwerks.

Keine Whiteboards. Keine Architekturdiagramme. Kein sauberer Code.

Nur man selbst, ein System, und die Frage:

Funktioniert das hier, jetzt, für diese Menschen?

Das ist die Frage, die zählt.