Virtuelle Inbetriebnahme bezeichnet das Testen und Abstimmen der Steuerungssoftware einer Anlage an einem digitalen Anlagenmodell, bevor die reale Maschine aufgebaut oder verfügbar ist. Statt Fehler in der SPS-Logik erst in der Montagehalle oder beim Kunden zu finden, wird das Steuerungsprogramm gegen eine Simulation der Mechanik, der Sensorik und der Antriebe betrieben. Fehlerhafte Interlocks, falsche Sequenzen oder unklare Betriebsartenwechsel treten dann an einem Arbeitsplatz auf, an dem sie nichts beschädigen können.
Für Geschäftsführer und Fachverantwortliche stellt sich dabei weniger die Frage, ob die Methode funktioniert, sondern ob sie sich für das eigene Projekt rechnet und welche Voraussetzungen erfüllt sein müssen. Entscheidend sind die Qualität des Modells, die Wahl zwischen Software-in-the-Loop und Hardware-in-the-Loop sowie die saubere Definition der Schnittstellen zwischen Modell und Steuerung. Der Beitrag ordnet das Verfahren ein, grenzt es vom Digitalen Zwilling im Betrieb ab und beschreibt ein Vorgehen, das sich auch in mittelständischen Projekten mit überschaubarem Budget umsetzen lässt.
Titelbild: Foto von iSawRed auf Unsplash.
Was Virtuelle Inbetriebnahme ist und was sie nicht ist
Im Kern besteht die Methode aus zwei gekoppelten Teilen: der realen oder emulierten Steuerung mit dem SPS-Programm und einem Simulationsmodell, das die Anlage nachbildet. Das Modell liefert der Steuerung Sensorsignale, etwa Endlagen, Lichtschranken oder Füllstände, und nimmt deren Ausgänge entgegen, etwa Ventilansteuerungen oder Antriebsfreigaben. Die Steuerung „glaubt“ damit, an einer echten Anlage zu arbeiten, obwohl sich alles im Rechner abspielt.
Wichtig ist die Abgrenzung zu verwandten Begriffen. Die Virtuelle Inbetriebnahme ist ein Verfahren der Entwicklungs- und Aufbauphase mit einem klar begrenzten Zweck: Das Steuerungsprogramm soll vor der physischen Inbetriebnahme auf Funktion und Robustheit geprüft werden. Sie endet, sobald die reale Anlage in Betrieb geht. Ein Modell, das dafür gebaut wurde, ist zunächst ein Testwerkzeug und kein Betriebsabbild.
Abgrenzung zum Digitalen Zwilling
Ein Digitaler Zwilling im laufenden Betrieb wird mit realen Anlagendaten gespeist und begleitet die Anlage über ihren Lebenszyklus, etwa für Zustandsüberwachung oder Optimierung. Die Virtuelle Inbetriebnahme arbeitet dagegen mit einem Modell, das Sollverhalten nachbildet, und sie dient der Absicherung vor dem Start. Das Anlagenmodell kann später zu einem Digitalen Zwilling weiterentwickelt werden, zwingend ist das nicht. Umgekehrt ist ein Digitaler Zwilling im Betrieb nicht automatisch für Steuerungstests geeignet, weil ihm oft die dafür nötige Detailtiefe der Signalebene fehlt.
Typische Einsatzfelder
Besonders lohnend ist das Verfahren bei Anlagen mit hoher Steuerungskomplexität und hohen Stillstandskosten. Dazu zählen verkettete Montagelinien, Förder- und Sortieranlagen, Verpackungslinien, Roboterzellen mit mehreren Stationen sowie Sondermaschinen, die nur einmal gebaut werden und deshalb keine Erprobung an einer Vorgängerversion erlauben. Bei einfachen Einzelmaschinen mit bewährter Standardlogik ist der Zusatzaufwand dagegen häufig nicht gerechtfertigt.
Anlagenmodell und SPS-Programm: Wie die Kopplung funktioniert
Das SPS-Programm wird in der Regel nach IEC 61131-3 erstellt, also in Sprachen wie Strukturiertem Text, Funktionsbausteinplan oder Ablaufsprache. Für die Virtuelle Inbetriebnahme bleibt es unverändert, es darf nicht für den Test umgeschrieben werden. Andernfalls wird nicht das spätere Programm getestet, sondern eine Variante. Das Modell wird an die Prozessabbildung der Steuerung angebunden, also an die Ein- und Ausgänge sowie an Datenbausteine oder Variablen.
Die Kopplung erfolgt je nach Plattform über unterschiedliche Wege: über einen Feldbus oder Ethernet-basierte Protokolle, über eine herstellerspezifische Simulationsschnittstelle der Steuerung, über OPC UA oder über Shared Memory bei emulierten Steuerungen. Maßgeblich ist, dass Zykluszeit und Signalaustausch so synchronisiert werden, dass das Zeitverhalten für den Test aussagekräftig bleibt. Wird das Modell deutlich langsamer oder schneller als die Steuerung getaktet, sind Timing-abhängige Fehler nicht belastbar prüfbar.
Detaillierungsgrad des Modells
Ein Modell muss nicht jedes physikalische Detail abbilden. Entscheidend ist, dass es alle Signale und Zustände liefert, die das Steuerungsprogramm auswertet. Für viele Aufgaben genügt ein Verhaltensmodell, das Bewegungen mit definierten Laufzeiten und Endlagen nachbildet. Erst wenn Regelverhalten, Massenträgheit, Schlupf oder Materialfluss das Programm beeinflussen, ist ein physikalisch genaueres Modell erforderlich. Je höher die Detailtiefe, desto größer der Aufwand für Erstellung und Pflege.
| Modellebene | Abgebildet wird | Typischer Zweck |
|---|---|---|
| Signalmodell | Ein- und Ausgänge mit einfacher Logik | Verdrahtungs- und Zuordnungstest der Signalliste |
| Verhaltensmodell | Bewegungen mit Laufzeiten, Endlagen, Sensorreaktion | Test von Ablaufsteuerung, Interlocks und Betriebsarten |
| Kinematisches Modell | Geometrie, Achsbewegung, Kollisionsräume | Roboter- und Handlingabläufe, Kollisionsprüfung |
| Physikalisches Modell | Dynamik, Regelstrecken, Materialverhalten | Regelungsparameter, Prozessverhalten |
Software-in-the-Loop und Hardware-in-the-Loop im Vergleich
Bei der Software-in-the-Loop-Variante (SIL) läuft die Steuerung als emulierte Soft-SPS oder Simulationsinstanz auf einem Rechner. Bei der Hardware-in-the-Loop-Variante (HIL) kommt die reale Steuerungshardware zum Einsatz, die über Ein- und Ausgabekarten oder Netzwerkschnittstellen mit dem Simulationsrechner verbunden ist. Beide Ansätze haben ihre Berechtigung, und in größeren Projekten werden sie häufig nacheinander genutzt.
SIL ist schnell verfügbar, günstig und lässt sich parallelisieren, sodass mehrere Entwickler gleichzeitig testen können. Die Grenze liegt im Zeitverhalten und in Hardwareeigenheiten: Zykluszeiten, Taskprioritäten, Remanenz oder herstellerspezifisches Verhalten der Peripherie sind in der Emulation nur eingeschränkt echt. HIL bildet diese Eigenschaften realitätsnäher ab und ist auch für Tests der Netzwerkkonfiguration oder der Diagnosefunktionen geeignet. Dafür sind Hardware, Verkabelungsaufwand und ein dedizierter Prüfplatz erforderlich.
| Kriterium | Software-in-the-Loop | Hardware-in-the-Loop |
|---|---|---|
| Steuerung | Emulierte Soft-SPS | Reale Steuerungshardware |
| Verfügbarkeit | Früh, ohne Hardwarebeschaffung | Erst nach Hardwarelieferung |
| Kosten und Aufwand | Geringer | Höher (Prüfplatz, Verdrahtung) |
| Zeitverhalten | Näherung | Realitätsnah |
| Parallele Nutzung | Gut möglich | Durch Hardware begrenzt |
| Eignung | Logik, Ablauf, Betriebsarten | Zeitkritische Funktionen, Netzwerk, Diagnose |
Welche Variante wann passt
Als Faustregel eignet sich SIL für die frühe Entwicklungsphase, in der Logik und Abläufe reifen. HIL lohnt, wenn die Steuerungsplattform spezielle Eigenschaften hat, wenn Sicherheits- und Diagnosefunktionen geprüft werden sollen oder wenn zeitkritische Abläufe im Vordergrund stehen. Wer nur eine der beiden Varianten einplant, sollte bewusst festhalten, welche Aussagen daraus nicht abgeleitet werden dürfen.
Nutzen, Aufwand und Wirtschaftlichkeit
Der wichtigste Effekt liegt in der Verlagerung der Fehlersuche. Programmierfehler, die in der Montagehalle oder beim Anlaufen beim Kunden gefunden werden, verursachen Stillstand, Reisekosten und Termindruck. Am Simulationsmodell sind dieselben Fehler mit Haltepunkten, Aufzeichnungen und beliebigen Wiederholungen leichter zu analysieren. Hinzu kommt die Parallelisierung: Die Steuerungsentwicklung muss nicht mehr auf die fertiggestellte Mechanik warten, was den Projektpfad verkürzen kann.
Der Aufwand besteht aus der Erstellung des Modells, der Kopplung, der Testfallentwicklung und der Pflege bei Änderungen. Dieser Aufwand fällt vor allem früh im Projekt an, während der Nutzen später eintritt. Eine Beispielrechnung verdeutlicht die Logik, ohne Branchenwerte zu behaupten: Angenommen, die Modellierung bindet drei Personenwochen, und dadurch verkürzt sich die Inbetriebnahme an der realen Anlage um eine Woche mit mehreren Beteiligten und einer Produktionslinie, die in dieser Zeit nicht läuft. Dann hängt die Wirtschaftlichkeit davon ab, wie teuer eine Woche Inbetriebnahmezeit tatsächlich ist. Je höher die Stillstands- und Anlaufkosten, desto eher rechnet sich der Ansatz.
Eine Simulation ersetzt die Inbetriebnahme nicht, sie verschiebt einen großen Teil der Fehlersuche an einen Ort, an dem Fehler nichts kosten.
Für die Bewertung im Gesamtprojekt bietet sich die Einordnung in die Wirtschaftlichkeitsbetrachtung an. Sinnvoll ist, den Aufwand für Modell und Tests als eigene Position im Projektbudget auszuweisen und den erwarteten Effekt auf Inbetriebnahmedauer und Anlaufverluste konservativ zu schätzen. Fehlt jede Erfahrung, lässt sich zunächst ein abgegrenzter Anlagenteil als Pilot modellieren, um eigene Kennwerte zu gewinnen.
Voraussetzungen, Modellqualität und Schnittstellen
Die wichtigste organisatorische Voraussetzung ist ein früher, eingefrorener Stand der Projektunterlagen. Das Modell wird aus der Funktionsbeschreibung, dem Mechanikkonzept, der Signalliste und dem Ablaufplan abgeleitet. Ändern sich diese Unterlagen laufend, ohne dass das Modell nachgezogen wird, testet das Team gegen einen veralteten Stand. Ein sauber geführtes Lastenheft mit eindeutigen Anforderungen an Betriebsarten, Störverhalten und Schnittstellen erleichtert den Einstieg erheblich, weil daraus Testfälle direkt ableitbar sind.
Technisch braucht es eine Simulationsumgebung, eine zur Steuerung passende Kopplung, ausreichend Rechenleistung und Personal, das sowohl die Steuerungslogik als auch die Mechanik versteht. Häufig scheitert der Ansatz nicht an der Software, sondern an der fehlenden Rolle des Modellverantwortlichen. Es sollte klar benannt sein, wer das Modell erstellt, wer es freigibt und wer Änderungen einpflegt, sei es im eigenen Haus oder beim Anlagenbauer.
Modellqualität belastbar machen
Ein Modell ist nur so gut wie seine Prüfung gegen die Realität. Deshalb gehört eine Validierung dazu: Laufzeiten der Antriebe, Reaktionszeiten der Sensoren, Verhalten bei Fehlern und die Zuordnung jedes Signals werden mit den Herstellerangaben und später mit der realen Anlage verglichen. Abweichungen werden dokumentiert und im Modell nachgeführt. Wichtig ist auch, das Fehlerverhalten abzubilden, etwa einen hängenden Sensor, einen ausbleibenden Endlagenmelder oder eine blockierte Bewegung. Genau dort zeigt sich, ob die Steuerung robust reagiert, und genau diese Fälle lassen sich an der realen Anlage nur schwer provozieren.
Schnittstellen sauber definieren
An der Grenze zwischen Modell und Steuerung entstehen die häufigsten Reibungsverluste. Eine eindeutige Signalliste mit Adressen, Datentypen, Einheiten, Skalierungen und Signalrichtung ist die Grundlage. Für Daten, die zwischen Steuerung und übergeordneten Systemen fließen, etwa zum Leitsystem oder zum MES, sollten die Schnittstellen ebenfalls festgelegt und, wo sinnvoll, im Modell nachgebildet werden. Wo Anlagenteile mehrerer Lieferanten zusammenkommen, hilft ein einheitliches Datenmodell, wie es etwa OPC UA ermöglicht, die Kopplung herstellerübergreifend zu vereinfachen. Hinweise zur Standardisierung im Umfeld Industrie 4.0 bietet die Plattform Industrie 4.0.
Virtuelle Inbetriebnahme Schritt für Schritt
Ein strukturiertes Vorgehen verhindert, dass das Modell zum Selbstzweck wird. Die folgende Reihenfolge hat sich in der Praxis bewährt und lässt sich an die Projektgröße anpassen.
- Ziel und Umfang festlegen: Welche Anlagenteile und welche Funktionen werden geprüft, und welche Aussagen sollen am Ende belastbar sein?
- Unterlagen einfrieren: Funktionsbeschreibung, Signalliste, Mechanikkonzept und Ablaufplan auf einen definierten Stand bringen.
- Modellebene wählen: Signal-, Verhaltens-, kinematisches oder physikalisches Modell entsprechend dem Prüfziel bestimmen.
- Modell erstellen und validieren: Laufzeiten, Sensorik und Fehlerverhalten gegen Herstellerangaben prüfen.
- Kopplung aufbauen: Steuerung (SIL oder HIL) mit dem Modell verbinden und Signalzuordnung testen.
- Testfälle ableiten: Normalbetrieb, Betriebsartenwechsel, Notaus-Verhalten, Störungen und Wiederanlauf systematisch festlegen.
- Tests durchführen und dokumentieren: Abweichungen erfassen, Fehler im SPS-Programm beheben, Regressionstests nach jeder Änderung wiederholen.
- Übergabe an die reale Inbetriebnahme: Testprotokolle, offene Punkte und Modellstand mitgeben, damit die Erkenntnisse vor Ort genutzt werden können.
Die Testergebnisse sollten nachvollziehbar abgelegt werden, weil sie später bei der Abnahme als Nachweis dienen können. Eine virtuelle Prüfung ersetzt dabei weder die Werksabnahme noch die Abnahme am Aufstellort, sie kann aber den Umfang der dort nötigen Fehlersuche deutlich reduzieren. Auch Anforderungen aus der CE-Konformität und der Risikobeurteilung bleiben an der realen Maschine zu erfüllen, denn Sicherheitsfunktionen müssen letztlich am realen Aufbau nachgewiesen werden. Allgemeine Informationen zu Normen und Regelwerken stellt die DKE bereit.
Typische Stolperfallen
Aus der Projektpraxis lassen sich wiederkehrende Fehlerbilder ableiten, die sich mit etwas Vorbereitung vermeiden lassen.
- Das Modell wird zu detailliert gebaut und verbraucht Budget, das für Tests fehlt.
- Das Modell wird zu grob gebaut, sodass entscheidende Signale und Zeitverhalten fehlen.
- Änderungen am SPS-Programm oder an der Mechanik werden nicht ins Modell übernommen.
- Das Steuerungsprogramm wird für den Test angepasst, statt den Originalstand zu prüfen.
- Gutes Testergebnis wird mit Freigabe der Anlage verwechselt, obwohl Modellgrenzen nicht dokumentiert sind.
- Fehlerfälle werden nicht simuliert, weil der Normalablauf bereits „läuft“.
Ein Praxisbeispiel: Eine Verpackungslinie mit mehreren Förderabschnitten wird im Modell mit Laufzeiten und Lichtschranken abgebildet. Beim Test des Wiederanlaufs nach Notaus zeigt sich, dass ein Zwischenspeicher im Programm mit falschem Zustand startet und Produkte doppelt zählt. Dieser Fehler wäre an der realen Linie erst bei Produktivlast aufgefallen und hätte mehrere Chargen betroffen. Am Modell genügte eine Anpassung der Initialisierung und ein Regressionstest.
Checkliste vor dem Start
Vor dem Projektstart sollten sich einige Fragen klar beantworten lassen: Ist das Prüfziel schriftlich definiert? Existiert ein eingefrorener Unterlagenstand? Ist die Modellebene begründet? Sind Verantwortliche für Modell, Kopplung und Tests benannt? Ist festgelegt, ob SIL, HIL oder beides eingesetzt wird? Gibt es eine Regelung, wie Änderungen ins Modell zurückfließen? Und wurde mit dem Anlagenbauer vereinbart, welche Testprotokolle zur Abnahme gehören? Wer diese Fragen nicht beantworten kann, sollte zunächst den Umfang klein halten.
FAQ
Für welche Anlagen lohnt sich Virtuelle Inbetriebnahme?
Sie lohnt sich vor allem bei komplexen Steuerungsabläufen, hohen Stillstandskosten, mehreren verketteten Stationen oder Sondermaschinen ohne Vorgängerversion. Bei einfachen Standardmaschinen ist der Modellierungsaufwand oft höher als der Nutzen.
Was ist der Unterschied zwischen SIL und HIL?
Bei SIL läuft die Steuerung als Emulation auf einem Rechner, bei HIL kommt die reale Steuerungshardware zum Einsatz. SIL ist früher und günstiger verfügbar, HIL bildet Zeitverhalten und Hardwareeigenschaften realitätsnäher ab.
Ersetzt die Anlagensimulation die reale Inbetriebnahme?
Nein. Sie reduziert die Fehlersuche an der realen Anlage, ersetzt aber weder Funktions- und Sicherheitsnachweise am Aufbau noch die Abnahme. Offene Modellgrenzen sollten dokumentiert werden.
Worin unterscheidet sich das Verfahren vom Digitalen Zwilling?
Die Virtuelle Inbetriebnahme sichert die Steuerungssoftware vor dem Start ab und endet mit der realen Inbetriebnahme. Ein Digitaler Zwilling begleitet die Anlage im Betrieb und wird mit realen Daten gespeist.
Muss das SPS-Programm für den Test angepasst werden?
Nein, das Programm sollte unverändert bleiben, damit der spätere Stand getestet wird. Angepasst wird das Modell, nicht die Steuerungslogik.
Wer erstellt das Anlagenmodell?
Das kann der Anlagenbauer, ein Simulationsdienstleister oder das eigene Team sein. Entscheidend ist, dass Modell, Pflege und Freigabe vertraglich und organisatorisch eindeutig zugeordnet sind.
