Was ist virtuelle Inbetriebnahme?

Inbetriebnahmerisiken zeigen sich spät. Eine Sequenz, die im SPS-Editor richtig aussieht, kann scheitern, wenn Sensoren, Aktoren, HMI und Mechanik an der montierten Maschine zusammenkommen. Werden solche Fehler erst während der FAT gefunden, wird aus geplanter Abnahme schnell Fehlersuche unter Zeitdruck. Virtuelle Inbetriebnahme verschiebt einen Teil dieser Integrationsarbeit nach vorn, solange Änderungen noch ohne Blockierung der physischen Maschine möglich sind.

Typische Treiber sind ein kurzes Lieferfenster, Maschinen mit vielen Varianten und ein Käufer, der vor der Hardware-Freigabe Evidenz will. Läuft die Logik gegen ein repräsentatives Modell, kann ein Projektmeeting Verhalten zeigen statt über Screenshots zu streiten.

Auf einer Verpackungslinie mit häufigem Rezeptwechsel oder in einer Sondermaschine, in der Mechanik und Software parallel iterieren, wird eine späte Verriegelungsstörung zu Überstunden und einem verschobenen Versand. Aufgezeichnete virtuelle Läufe können in ein technisches Review, ohne als Abnahme zu gelten.

Für die Projektleitung liegt der Wert vor allem in Planbarkeit: weniger unerwartete Korrekturen kurz vor dem Versand und ein Abnahmeverlauf mit bekannten offenen Punkten. Für die Automatisierung entsteht ein Umfeld, in dem Sequenzen und Fehlerzustände wiederholt werden können, ohne auf Hallenzeit zu warten.

Dafür müssen die Testszenarien aktuell bleiben, wenn sich SPS-Logik, HMI oder Mechanik ändern. Benannte Testfälle, Versionskontrolle und eine klare Verantwortung unterscheiden virtuelle Inbetriebnahme als Demo von tatsächlicher Risikoreduktion.

Ein typisches Setup koppelt drei Schichten: das Steuerprogramm, ein Maschinenmodell und einen Testplan. Der SPS-Code oder eine Soft-SPS-Runtime läuft wie auf der Zielsteuerung. Das Modell reagiert auf Ausgänge und speist Eingänge zurück: Endlagen, Verzögerungen, Fehlerzustände und Bewegung, wo relevant. Testfälle beschreiben, was für jeden Modus, Alarm und Wiederanlauf als gut gilt.

Ingenieure beginnen mit dem Umfang. Nicht jede Achse braucht am ersten Tag fotoreale Grafik. Viele Projekte starten mit kritischen Sequenzen: Sicherheitskreise, Moduswechsel, Rezeptbehandlung und HMI-Navigation. Mit wachsender Sicherheit erweitern Teams die Abdeckung auf Randfälle, die an Hardware teuer zu reproduzieren sind, etwa Doppelbogen, Stau-Recovery oder Unterversorgung von Upstream-Anlagen.

Die Signalzuordnung ist die stille Arbeit, an der das Setup steht oder fällt. Jede physische I/O-Adresse braucht ein Zwilling-Äquivalent: digitale Eingänge aus simulierten Sensoren, analoge Werte in realistischen Bereichen und Handshake-Bits zu Up- und Downstream. Legen Sie die Map in dasselbe Revisionssystem wie das SPS-Projekt, damit Drift sichtbar bleibt.

Sitzungen sehen aus wie strukturierte FAT-Proben. Ein Ingenieur fährt die SPS, ein zweiter bedient das HMI, ein dritter protokolliert Abweichungen. Befunde werden Tickets mit Reproduktionsschritten: dieselbe Gewohnheit, die Sie an der physischen Linie wollen. Sind Modell und Logik abgestimmt, können Sie die Suite nach jedem Software-Drop in Minuten statt Stunden erneut fahren.

Die Anbindung an Ihre bestehende Toolchain zählt. Exportieren Sie I/O-Listen aus dem SPS-Projekt, stimmen Sie Tagnamen mit dem Zwilling ab und knüpfen Sie Testfälle an Funktionsanforderungen oder User Stories, falls das Projekt sie nutzt. Diese Rückverfolgbarkeit hilft, wenn ein Kunde fragt, warum eine bestimmte Verriegelung geprüft wurde und welcher Build das bewiesen hat.

Die Begriffe überlappen auf Marketingfolien, erfüllen in der Lieferung aber unterschiedliche Jobs. Ein digitaler Zwilling ist eine lebende Repräsentation der Maschine: Geometrie, Kinematik, Signale und oft Dokumentationslinks. Er kann für Vertrieb, Schulung oder Service existieren, ohne an einen Inbetriebnahme-Meilenstein gebunden zu sein.

Virtuelle Inbetriebnahme ist die Tätigkeit: nachweisen, dass Steuerungssoftware und Zwilling (oder eine leichtere Simulation) gemeinsam gegen definierte Tests korrekt verhalten. Sie können mit einem groben Modell inbetriebnehmen, wenn das Ziel Logikvalidierung ist. Sie brauchen einen reicheren Zwilling, wenn Bediener realistische Abläufe üben oder Konfiguratordaten dem Hallenverhalten entsprechen sollen.

Ein Zwilling ohne Tests ist ein visuelles Asset. Inbetriebnahme ohne gepflegtes Modell ist eine Einmalübung, die schlecht altert. Der belastbare Weg verbindet beides: der Zwilling liefert Physik und Kontext; die Inbetriebnahme-Schicht liefert Pass/Fail-Kriterien, Regressionsläufe und Rückverfolgbarkeit zu Vertragsspezifikationen.

In der Praxis profitieren Maschinenbauer, wenn dasselbe Asset mehrere Nutzungen trägt. Ein Zwilling, der für virtuelle Inbetriebnahme gebaut wurde, kann später interaktive Handbücher oder Serviceschulung stützen, sofern jemand Updates besitzt, wenn Engineering die Konstruktion ändert.

Die meisten großen Automatisierungsstacks unterstützen irgendeine Form virtuellen Tests. Siemens bietet PLCSIM Advanced und integrierte Abläufe mit TIA Portal. Rockwell-Anwender arbeiten mit Emulate und Studio 5000. Beckhoff, B&R und CODESYS-basierte Systeme stellen Soft-SPS oder Hardware-in-the-Loop bereit, abhängig von Runtime und I/O-Kopplung.

Sie wählen zwischen SPS-zentrierter Simulation und gekoppeltem 3D plus SPS. SPS-only-Werkzeuge sind schnell für Logik, Timer und Alarmwege; sie stoßen an, wenn räumliches Verhalten, Bediener-Sichtlinien oder mechanische Freigänge zählen. Volles 3D plus SPS kostet mehr im Aufbau, zeigt aber Kollisionen, die reine Logiksimulation verfehlt, etwa eine Armbahn, die im Modell einen Lichtvorhang auslöst, in einem tabellengetriebenen Stub aber nicht.

Hardware-in-the-Loop (HIL) liegt dazwischen: echte Steuerungen mit simulierten I/O für Timing mit hoher Treue. CAD-lastige Teams importieren mechanische Daten oft in Unity oder ähnliche Runtimes für Bewegung und Bedienerkontext. Feldbus-Verhalten und Scan-Cycle-Effekte erscheinen manchmal erst auf dieser Ebene.

Bei neexo koppeln wir typischerweise einen Unity-basierten 3D-Ablauf mit Live- oder Soft-SPS-Code, damit Sequenzen, HMI-Bilder und räumliche Grenzen gemeinsam geübt werden, nicht als getrennte Checklisten. Die Plattformwahl folgt Ihren FAT-Risiken, nicht umgekehrt.

Der Business Case ist am stärksten, wenn das FAT-Risiko hoch ist relativ zu den Modellkosten. Sondermaschinen mit vielen Varianten, engen Abnahmeterminen oder verteilten Teams sehen den Nutzen meist schnell. Kostet ein einzelner FAT-Überzug mehr als ein fokussierter Zwilling, ist die Rechnung klar.

Vergleichen Sie Szenarien mit Ihren eigenen Sätzen: tägliche Standby-Kosten des Kunden, Nacharbeitslohn und Opportunitätskosten eines verschobenen Versands. Schon moderate Einsparungen an FAT-Nacharbeitstagen können Simulation rechtfertigen, wenn mehrere Beteiligte zur Abnahme reisen.

Schwerer zu rechtfertigen ist das bei einfachen Einmalzellen mit stabiler Logik und lokaler Abnahme; auch dann kann eine schlanke Simulation sich rechnen, wenn Reise oder Nacharbeit wahrscheinlich sind. Beginnen Sie mit den zehn Fehlermodi der letzten drei Projekte. Konnten diese Fehler in Software ausgelöst werden, haben Sie einen Umfang.

Budgetieren Sie Pflege. Ein Zwilling, der von der as-built-Maschine driftet, frisst Vertrauen. Benennen Sie einen Verantwortlichen, der das Modell nachzieht, wenn Stücklisten, Sensoren oder HMI-Abläufe sich ändern. Teams, die den Zwilling als Projektliefergegenstand behandeln, nicht als Demo, halten ihn durch FAT und in den Service nutzbar.

Bei Mehrmaschinenprogrammen standardisieren Sie virtuelle FAT-Vorlagen je Produktfamilie. Gemeinsame Fallbibliotheken senken den Setup-Aufwand bei Variante drei und vier, wo Kunden dieselbe Strenge erwarten wie beim ersten Gerät.

Unser Leistungsangebot zur virtuellen Inbetriebnahme zeigt, wie Modellaufbau und Testplan in den Projektzeitplan gehören, statt nachträglich anzukommen.

Erwarten Sie weniger Logikfehler beim physischen Start, nicht null Arbeit in der Halle. Virtuelle Inbetriebnahme findet falsche Verriegelungsreihenfolgen, fehlende Alarmquittierungen, HMI-Zustände, die nicht zu SPS-Modi passen, und Rezeptparameter, die nie durchverdrahtet wurden. Mechanische und elektrische Punkte bleiben, wo das Modell vereinfacht ist.

Frühe Projekte brauchen Zeit für das Modell. Spätere Projekte nutzen Vorlagen, Testbibliotheken und Signallisten wieder. Die FAT öffnet dann mit bereits gezeigten Fällen, sodass die Hallenzeit an Sensoren, Medien und Timing geht, die der Zwilling nicht beweisen kann.

Protokollieren Sie Läufe gegen Softwarestände: Build, ausgeführte Fälle, Fehler, Korrekturen, Wiederholungen. Diese Liste beendet die Debatte, was getestet wurde, und ist die Grundlage für eine Nachbetrachtung, wenn doch etwas durchrutscht.

Messen Sie Fehler vor dem Versand, FAT-Tage in Nacharbeit und Wiederholungsreisen. Legen Sie Bedienerfeedback neben die Zahlen aus dem Ticketsystem. Das sind die Zahlen für die nächste Maschine, kein branchenweiter Prozentsatz.

Sagen Sie Vertrieb und Projektleitung dasselbe von Anfang an: virtuelle Inbetriebnahme verbessert die Chancen. Sie zertifiziert keinen Liefertermin von allein.