So erstellen Sie einen digitalen Inbetriebnahme-Testplan

Der Zwilling wirkte in der Demo überzeugend. Dann fragte der Kunde, was tatsächlich verifiziert wurde, und die Antwort war eine Tabelle, drei Erinnerungen und eine Liste von Alarmen, die „sich von selbst legen“. Ein digitaler Inbetriebnahme-Testplan verhindert genau diesen Moment.

Er ist die dokumentierte Grundlage dafür, was Sie in der virtuellen Inbetriebnahme prüfen, wie Sie einen bestandenen Test erkennen und was offen bleibt. Jedes Szenario hat eine Nummer, einen Auslöser, erwartetes Verhalten, Akzeptanzkriterien, einen Verantwortlichen und einen Status. Das ist mehr als Zeilen in Excel: die gemeinsame Sprache von Automatisierung, Mechanik, Projektleitung und Qualität.

Der Plan verbindet drei Ebenen: SPS-Code (oder Soft-SPS), das digitale Modell und die Menschen, die sich auf Ergebnisse einigen müssen. Ohne diese Verbindung werden virtuelle Läufe zu Ad-hoc-Demos, bei denen nur der Automatisierer weiß, was funktioniert.

Das Konzept überschneidet sich mit einem FAT-Protokoll, hat aber eine andere Aufgabe. Der Testplan ist das lebende Arbeitsbuch während der Entwicklung. Das FAT-Protokoll ist oft kundenbezogene Dokumentation für die formelle Abnahme. Viele FAT-Testpunkte beginnen als virtuelle Szenarien, die Wochen zuvor gelaufen und protokolliert wurden.

Ein guter Plan ist lesbar für jemanden, der die SPS nicht geschrieben hat. Auslöser, Schritte, erwartete Ergebnisse und Nachweisanforderungen gehören in Projektsprache, nicht nur als interne Tag-Namen.

Die meisten Teams haben bereits ein Modell und SPS-Simulation. Das Problem beginnt, wenn niemand festlegt, was bewiesen werden muss. Die Demo zeigt Normalbetrieb, aber Not-Halt mitten im Zyklus, Formatwechsel und ein leerer Puffer, weil die vorherige Station stoppt, werden nie zu benannten Testfällen.

Ohne feste Szenarionamen und -nummern hängt die Qualität vom Tagespersonal ab. Ein erfahrener Automatisierer kennt die kritischen Verriegelungen; ein neuer Kollege testet den Happy Path. Bei der physischen FAT findet der Kunde Lücken, die Sie für abgedeckt hielten, weil „wir die Simulation gelaufen sind“.

Offene Punkte verteilen sich auf E-Mail, Chat und Protokolle. Niemand kann sagen, welche SPS-Version Szenario VC-04 belegt hat, ob der Mangel geschlossen ist oder ob der Kunde es an der physischen Maschine erneut sehen muss. Ohne ein zentrales Register wird virtuelle Prüfung nie Teil des Qualitätssystems.

Mechanik und Automatisierung arbeiten oft mit unterschiedlichen mentalen Checklisten. Der Testplan zwingt beide Perspektiven in eine Struktur, damit ein Umrüstvorgang nicht nur „Rezept geladen“ in der SPS, sondern auch im Modell und am HMI nachvollziehbar ist.

Jedes Szenario sollte mindestens fünf Dinge beschreiben: Start (Auslöser), Rollen, zu beobachtendes Verhalten, Bestehens-Kriterien und Nachweis. Ergänzen Sie eine sechste Zeile zu Modellgrenzen, wenn der Zwilling Sensorik, Timing oder Material vereinfacht.

Auslöser müssen konkret sein. „Not-Halt testen“ reicht nicht: Zyklusphase, Station und HMI-Aktion festlegen. „Auto-Start mit Rezept A nach Vollreset“ ist ein wiederholbarer Auslöser.

Akzeptanzkriterien müssen beobachtbar sein. „Sequenz funktioniert“ ist kein Kriterium. „Alle Bewegungen stoppen innerhalb der definierten Zeit; HMI zeigt Sicherheitsstopp; Reset folgt der dokumentierten Sequenz“ ist prüfbar.

Weisen Sie jedem Szenario einen Verantwortlichen zu: Automatisierung, Sicherheit, Mechanik oder Projektleitung. Verantwortung bedeutet Schließen offener Punkte, nicht nur Start in der Simulation.

Versionieren Sie die Testliste mit dem SPS-Projekt. Bei Logikänderungen Szenarien anpassen oder als veraltet markieren. Übernehmen Sie keine grünen Ergebnisse aus einer alten SPS-Version in neue FAT-Dokumentation ohne passende Versionsnummer.

In unserer Fallstudie: Digitaler Testplan vor der Inbetriebnahme zeigen wir, wie ein Linienteam Testliste, Akzeptanzmatrix und Issue-Tracking um einen Unity-Zwilling mit Siemens- und Beckhoff-SPS aufgebaut hat.

Beginnen Sie mit dem, was bei spätem Versagen weh tut: Sicherheitsverriegelungen und Not-Halt-Wiederanlauf, Moduswechsel, Format- oder Rezeptumstellung, Start/Stopp unter Teillast und Signalaustausch mit Anlagen vor und nach Ihrer Maschine, wenn im Scope.

Nutzen Sie Ihre Historie: Welche fünf bis zehn Probleme traten bei den letzten drei FAT-Ereignissen auf? Logik-, HMI- oder Sequenzthemen gehören meist zuerst in die virtuelle Spalte.

Bei kleineren Projekten mit wenigen Sequenzen und kleinem Team reichen oft fünf gut beschriebene Szenarien. Eine Seite mit Name, Start der Prüfung und Bestehens-Kriterium schlägt eine leere Tabelle, und Sie können die Liste jederzeit erweitern, wenn die Struktur sich bewährt.

Priorisieren Sie Negativtests: falsches Rezept, Schutztür mitten im Zyklus, Sensorausfall, MES-Timeout, Förderstörung. Virtuelle Umgebungen machen Wiederholungen ohne Schrott oder Sicherheitsrisiko möglich.

Bedienabläufe werden oft unterschätzt. Korrekte SPS mit verwirrender Alarmfolge scheitert trotzdem in der Produktion.

Eine sinnvolle Aufteilung virtuell vs. physisch finden Sie in unserem Leitfaden virtuelle vs. physische FAT. Markieren Sie jedes neue Szenario als nur virtuell, nur physisch oder beides, bevor Sie die Testliste über die ersten zehn Szenarien hinaus erweitern.

Schreiben Sie Kriterien, die Sie von virtuellen Läufen zur physischen FAT übernehmen können. Basieren Sie auf beobachtbarem Verhalten, nicht auf Implementierungsdetails.

Trennen Sie Must-pass von Nice-to-have. Must-pass blockiert den nächsten Meilenstein bei Fehlschlag. Nice-to-have kann zur SAT verschoben werden, muss aber geloggt bleiben.

Bei Sicherheit: Risikobeurteilung und PLd/SIL referenzieren. Virtuelles Bestehen belegt oft die Verriegelungslogik; physische FAT bestätigt Abstände und gemessene Stopzeiten. Dokumentieren Sie, was virtuell abgedeckt ist und was an der physischen Maschine mit dem Kunden noch bestätigt werden muss.

Nutzen Sie eine einheitliche Schweregradskala für offene Punkte. Ohne Skala wird jeder Mangel zu „später“.

Bei Kunden in virtuellen Vorschauen die Akzeptanzkriterien der gezeigten Szenarien durchgehen.

Starten Sie mit fester Agenda: welche Szenarien (z. B. VC-01 bis VC-05), welche SPS-Version, welche offenen Punkte von zuvor. Ohne Agenda wird es zur freien Demo.

Rollen: Moderation, SPS/Simulation, HMI, Projektleitung, bei Bedarf Mechanik und Sicherheit. Jeder weiß, wer entscheidet.

Szenarien in Prioritätsreihenfolge fahren. Abweichungen mit Szenarionummer, Ist, Soll, Schweregrad und Verantwortlichem loggen. Screenshots bei unklarer Reproduktion.

Mit sichtbarem Status abschließen: grün, gelb, rot pro kritischem Szenario. Protokoll am selben Tag teilen.

Mindestens einen internen Probelauf vor Kundeneinladung einplanen.

Der stärkste Nutzen ist Wiederverwendung. Bestandene Szenarien werden zur FAT-Checkliste. Nach größeren Änderungen am SPS-Programm Regression auf betroffene Fälle.

Drei Spalten in der Testliste: nur virtuell, nur physisch, beides. Das verhindert Überinterpretation virtueller Ergebnisse.

Bedienerschulung kann dieselben Szenarien in langsamerem Tempo nutzen: Alarm, Reset, Umrüstung, Eskalation.

Service profitiert später, wenn Störmeldungen auf Szenarionummern zurückführbar sind.

Zur internen Begründung gegenüber dem Management hilft der ROI-Rechner für virtuelle Inbetriebnahme, Entwicklung, FAT und SAT getrennt mit Ihren Annahmen zu modellieren.

Aktualisieren Sie den Plan nach der FAT. Physische Befunde werden neue Szenarien oder Modellgrenzen.