Das zentrale Stylesheet fehlt. Der Inhalt von dist/srq.css muss in WordPress hinterlegt sein — im Customizer unter „Zusätzliches CSS“ oder als Datei im Theme.
Use Case 04 · Engineering
SPS-Code testen, während die Mechanik noch gebaut wird
Sie verantworten den Code, der die Anlage später führt: Schrittketten, Verriegelungen, Betriebsarten, Störfallbehandlung und die Bahnen der Roboter. Ihre Programmierer schreiben ihn, während die Mechanik noch gebaut wird. Konventionell prüfen sie ihn allerdings erst danach, an der fertig aufgebauten Linie. Also genau dort, wo Fehler am teuersten sind.
Damit liegt der Steuerungstest am Ende der Kette, dort wo der Puffer längst aufgebraucht ist. Ein Fehler, den Sie dort noch finden, kostet Anreise, Stillstandsfenster und eine verschobene Abnahme. Und was niemand findet, taucht später im Betrieb auf.
Test erst am Ende
Prüfen können Sie den Code erst, wenn die Linie physisch steht. Jeder Fehler, der sich dann zeigt, verschiebt den kompletten Zeitplan.
Debugging vor Ort
Ein Mausklick im Modell wird auf der Baustelle zur Eskalation: Anreise, Hotel, offene Abnahme, verschobener Produktionsstart.
Sonderfälle bleiben ungetestet
Störfälle, Wiederanlauf und Sicherheitsketten können Sie an der realen Linie in der Regel nur eingeschränkt provozieren. Bemerkbar machen sie sich dann erst im Betrieb.
Aus der Praxis
Neuplanung, während die Steuerungen nicht lieferbar sind
Ein Hersteller im Turbinenbau plant mehrere Fertigungsanlagen neu: eine Rüstzelle und eine Fräszelle mit Dichtprüfung. Mehrere Steuerungen sind wegen Lieferengpässen nicht verfügbar. Konventionell hätte die Softwarephase auf die Hardware gewartet, und mit ihr der gesamte nachgelagerte Terminplan.
Stattdessen entstand der Steuerungscode gegen das Modell. Emulierte Steuerungen führten denselben Code aus, der später auf der realen Hardware laufen sollte. Bauteiltests zogen die Programmierer vor, Abläufe und Verriegelungen sicherten sie am Modell ab.
Ergebnis
Die Inbetriebnahme begann gemäß Projektplan, obwohl die Steuerungshardware noch fehlte. Der Verzug in der Lieferkette schlug nicht auf den Serienstart durch, weil ihn die Entwicklungsphase auffing, in der das Team ohnehin am Code arbeitete. Übrig blieben der Einbau der Hardware und der I/O-Check.
Der Hebel
Realer Code gegen nahezu reales Geräteverhalten
Antriebe, Sensoren, Sicherheitsschalter und Robotersteuerungen laufen als Verhaltensmodelle, gekoppelt über PROFINET, EtherCAT oder OPC UA. Die Integrationsphase verkürzt sich dabei um 66 Prozent. Welche Module das verlangt, steht bei jedem Punkt dabei.
Signalebene, nicht Näherung
Reale SPS oder emulierte Steuerung: dieselbe Modellseite, dieselben Signale.
Module: Steuerungs- und Robotermodul je Fabrikat, dazu die Feldbusse PROFINET und EtherCAT.
Störfall auf Knopfdruck
Not-Halt, Materialstau, Sensorausfall: reproduzierbar auslösen, statt darauf zu warten.
Module: Basis-Plugin mit den Verhaltensmodellen der Geräte; als Software-in-the-Loop ohne Schaltschrank.
Über Standorte hinweg
Maschinenbau an einem Ort, Programmierung an einem zweiten, Kunde an einem dritten: alle arbeiten gegen denselben Modellstand, ohne zu reisen.
Module: VCaaS-Bundle mit zentraler Umgebung, Rechnern im verwalteten Netz und allen benötigten Lizenzen.
Ihre Programmierer testen gegen den Modellstand aus der Simulationsphase. Kein Import, kein Nachziehen von Kinematik, kein zweites Werkzeug: Änderungen am Engineering fließen in dieselbe Datei, die anschließend die virtuelle Werksabnahme trägt. Damit gibt es zu jedem Zeitpunkt genau einen Stand, auf den sich ein Protokoll berufen kann.
Ergebnisse
Der Steuerungstest wandert von hinten nach vorn
Der Aufwand bleibt, der Zeitpunkt verschiebt sich. Mit dem Zeitpunkt ändert sich die Qualität der Prüfung.
| Phase | Konventionell | Mit SimReQs |
|---|---|---|
| Erster Steuerungstest | nach dem Aufbau | in der Softwarephase |
| Störfalltests | stichprobenhaft | vollständig, reproduzierbar |
| Standortübergreifende Arbeit | Reise oder Wartezeit | gemeinsamer Modellstand |
| Integrationszeit | Referenz | −66 % |
Der Weg dorthin
Wie ein Projekt bei Ihnen anfängt
Wir brauchen von Ihnen die Signalliste aus dem E-Plan, CAD-Geometrie mit erhaltener Baugruppenstruktur und die Steuerungssoftware in dem Stand, den es gerade gibt. Unfertige Stände sind in dieser Phase der Normalfall, denn genau dafür ist sie gedacht.
Über den Nutzen entscheidet der Zeitpunkt: parallel zur Montage, nicht danach. Wer erst startet, wenn die Linie steht, hat den Vorteil bereits verschenkt. Sie fangen mit einer eng geschnittenen Konzeptstudie zum festen Preis an, nicht mit dem vollen Projekt.
Grenzen
Was dieser Use Case nicht leistet
Wer diese Grenzen einplant, erlebt an der Anlage jedenfalls keine Überraschung.
Verdrahtung bleibt real
Klemmstellen und der I/O-Check bleiben an der Anlage. Das Modell prüft, ob ein Signal die richtige Wirkung auslöst. Ob die Ader auf der richtigen Klemme sitzt, sieht es nicht.
Diagnose braucht Hardware
Diagnosefunktionen von Baugruppen prüfen Sie nur mit realer Hardware. Wer sie testen muss, koppelt die reale Steuerung als Hardware-in-the-Loop an das Modell.
Verhalten, nicht Struktur
Die Simulation prüft zwar, wie sich der Code verhält. Über Struktur und Wartbarkeit sagt sie aber nichts: Ein Programm kann sich am Modell einwandfrei verhalten und trotzdem schwer zu pflegen sein.
Nächster Schritt
Wo Ihr Steuerungstest heute im Projekt liegt
Beginnt er erst, wenn die Linie steht, liegt er auf dem kritischen Pfad. Im kostenlosen Erstgespräch von rund einer Stunde sehen wir uns vor allem Ihre Steuerungslandschaft und Ihre Datenlage an und sagen, welche Kopplungstiefe Ihr Vorhaben braucht.