Virtuelle Inbetriebnahme wird wertvoll, wenn sich die simulierte Szene wie eine gesteuerte Maschine und nicht wie eine losgelöste Animation verhält. Bei einem Mitsubishi-SPS-Projekt erfordert das einen nachvollziehbaren Datenpfad vom GX-Engineering-Simulator über einen kompatiblen OPC-Server bis zu den Factory-I/O-Tags.

Das Ziel besteht nicht lediglich darin, ein Förderband in Bewegung zu setzen. Eine sinnvolle Einrichtung weist Adresszuordnung, Signalrichtung, Ablaufverhalten, Verriegelungen, Timing, Reaktion auf Kommunikationsverlust und Wiederanlauf-Logik nach, bevor physische I/Os verfügbar sind.

Ein kleines virtuelles Förderband kann Fehler bei Zuordnung, Timing und Wiederherstellung aufdecken, bevor sie eine echte Steuerung erreichen.

Softwarekompatibilität vor der Zuordnung der Tags bestätigen

„GX Simulator“ kann sich auf Simulationsfunktionen beziehen, die verschiedenen GX-Works-Generationen und MELSEC-CPU-Familien zugeordnet sind. Auch OPC-Produkte unterscheiden sich je nach Version und danach, ob sie OPC DA oder OPC UA bereitstellen. Factory I/O bietet Treiberauswahlen, die möglicherweise nicht jede Kombination auf dieselbe Weise unterstützen.

Halten Sie die genaue SPS-Familie, die GX-Works-Version, die Simulationskomponente, das OPC-Server-Produkt und seine Version, den Schnittstellentyp sowie die Factory-I/O-Version fest. Prüfen Sie anschließend, ob der OPC-Server eine Verbindung zu dieser simulierten CPU herstellen kann. Gehen Sie nicht davon aus, dass eine Verbindungsmethode, die mit einem physischen Ethernet-Modul funktioniert, automatisch auch mit einem Software-Simulator funktioniert.

Mitsubishi beschreibt MX OPC als Software, die MELSEC-Daten von speicherprogrammierbaren Steuerungen über OPC bereitstellt. Neuere MELSEC-iQ-R-Hardware kann außerdem ein integriertes OPC-UA-Servermodul verwenden. Diese Architektur unterscheidet sich jedoch von einem auf einem PC gehosteten Server, der mit einer simulierten Steuerung verbunden ist. Halten Sie diese Pfade in Konstruktionsnotizen und bei der Fehlersuche getrennt.

Datenvertrag vor der Softwarekonfiguration erstellen

Erstellen Sie eine I/O-Liste mit einer Zeile für jedes Signal. Nehmen Sie das Factory-I/O-Tag, die Mitsubishi-Geräteadresse, den Datentyp, die Richtung, die technische Bedeutung, den Standardzustand, den sicheren Zustand, die Aktualisierungsanforderung und den Zuständigen auf. Normalerweise sollte die Simulation die Zustände der Feldeingänge besitzen, während die SPS-Logik die Aktuatorbefehle besitzt.

Diese Besitzregel verhindert, dass zwei Anwendungen denselben Punkt beschreiben. Ein simuliertes Lichtsignal kann beispielsweise ein SPS-Eingangsgerät beschreiben, während die SPS einen Motorbefehl schreibt, den Factory I/O liest. Wenn beide Seiten dasselbe Tag beschreiben, kann die Anzeige flackern oder zufällig wirken, obwohl jede einzelne Verbindung technisch aktiv ist.

Bit-Geräte, Wörter, vorzeichenbehaftete Ganzzahlen, Gleitkommawerte und Arrays erfordern eine eindeutige Typbehandlung. Ein OPC-Client kann einen Wert erfolgreich anzeigen, während Factory I/O den falschen Typ oder die falsche Bit-Reihenfolge interpretiert. Beginnen Sie mit einem booleschen Punkt und einem Wort, deren sich ändernde Werte eindeutig erkennbar sind. Erweitern Sie die Konfiguration erst, nachdem Richtung und Skalierung nachgewiesen wurden.

Verbindung schrittweise aufbauen und testen

Erstellen Sie zunächst ein minimales SPS-Programm und führen Sie es im unterstützten GX-Simulator aus. Setzen oder ändern Sie ein bekanntes internes Gerät und bestätigen Sie, dass der Leiterplan-Monitor den erwarteten Zustand anzeigt. Damit wird nachgewiesen, dass Programm, ausgewählte CPU und Simulator ordnungsgemäß arbeiten.

Konfigurieren Sie anschließend den OPC-Server für diese simulierte Steuerung. Legen Sie zunächst nur einige Test-Tags an. Bestätigen Sie mit dem eigenen Client oder der Diagnoseansicht des Servers Datenqualität, Zeitstempel, Wert und Schreibfähigkeit. Ein als „schlecht“ oder „unsicher“ gekennzeichneter Wert sollte auf dieser Ebene korrigiert werden, bevor Factory I/O geöffnet wird.

Konfigurieren Sie danach den OPC-Client von Factory I/O und durchsuchen Sie die nachgewiesenen Tags oder geben Sie sie ein. Ordnen Sie einen simulierten Sensor und einen Aktuatorbefehl zu. Bestätigen Sie beide Richtungen unabhängig voneinander: Ändern Sie den Szeneneingang und beobachten Sie den SPS-Speicher; ändern Sie anschließend den SPS-Ausgang und beobachten Sie die Szene.

Diese schrittweise Methode trennt die Fehlerquellen. Wenn sich der GX-Speicher nicht ändert, liegt das Problem in der SPS-Simulation. Wenn sich GX ändert, der OPC-Client jedoch nicht, prüfen Sie die Serverkonfiguration und die Geräteadressierung. Wenn der OPC-Server fehlerfrei arbeitet, Factory I/O aber unverändert bleibt, prüfen Sie Clientverbindung, Elementnamen, Zugriffsrechte und Tag-Zuordnung.

Die schrittweise Prüfung grenzt Fehler in der SPS-, OPC-Server- und Factory-I/O-Konfiguration ein.

Timing über drei unabhängige Systeme hinweg berücksichtigen

SPS-Zyklus, OPC-Server-Abfrage, Client-Subscription und Physikaktualisierung von Factory I/O erfolgen nicht zum selben Zeitpunkt. Ein Sensorimpuls, der kürzer als das kombinierte Abtastintervall ist, kann verschwinden, bevor die SPS ihn erfasst. Auch auf einer lokalen Workstation können Netzwerk- oder PC-Auslastung Jitter verursachen.

Wichtige Ereignisse sollten so ausgelegt sein, dass sie die Abtastung überstehen. Ein simuliertes Gerät kann einen Zustand halten, bis er bestätigt wird, oder die SPS-Logik kann eine erkannte Flanke speichern, bis der Ablauf sie verarbeitet. Jeden Impuls für Demonstrationszwecke zu verlängern, ist zwar bequem, kann aber Fehler bei der Flankenauswertung verdecken. Stimmen Sie das Testverhalten auf den erwarteten physischen Sensor und die Produktionsgeschwindigkeit ab.

Messen Sie die effektive Ende-zu-Ende-Verzögerung, anstatt davon auszugehen, dass die konfigurierte OPC-Aktualisierungsrate die gesamte Latenz darstellt. Protokollieren Sie bei zeitkritischen Abläufen den Szenenübergang, den OPC-Zeitstempel, die SPS-Erfassung, die Ausgangsentscheidung und die daraus resultierende Szenenaktion.

OPC DA und Einschränkungen der Workstation berücksichtigen

Das klassische OPC DA verwendet die Microsoft-COM-Technologie. Wenn alle Anwendungen unter einem Windows-Konto auf einem Computer ausgeführt werden, ist die Einrichtung normalerweise einfacher. Verteilte Konfigurationen bringen Probleme mit DCOM-Identität, Berechtigungen, Firewall und Dienstkonten mit sich. Eine interaktiv funktionierende Verbindung kann nach einem Neustart ausfallen, wenn der OPC-Server unter einem anderen Konto gestartet wird.

OPC UA verwendet ein anderes Sicherheitsmodell mit Endpunkten, Zertifikaten und Richtlinien. Es vermeidet DCOM, erfordert aber weiterhin Zertifikatsvertrauen, Benutzerberechtigungen und kompatible Datenmodelle. Verwenden Sie die von der ausgewählten Software tatsächlich unterstützte Schnittstelle, statt DA und UA als austauschbare Bezeichnungen zu behandeln.

Fehler- und Wiederanlaufzustände gezielt testen

Trennen Sie den OPC-Client, während das Förderband aktiv ist. Stoppen Sie den SPS-Simulator. Starten Sie den OPC-Server neu. Öffnen Sie Factory I/O erneut, während zuvor Ausgänge eingeschaltet waren. Die Maschine darf keine gefährliche Bewegung allein deshalb wieder aufnehmen, weil veraltete Werte erneut erscheinen oder ein Client die Verbindung wiederherstellt.

Definieren Sie die Reaktion auf schlechte Datenqualität, Kommunikationsverlust und Startwerte. Befehle können abhängig vom Prozess zwangsweise ausgeschaltet, gehalten oder über einen kontrollierten Stopp behandelt werden. Eingänge benötigen möglicherweise ein ausdrückliches Kommunikationsstatus-Bit, damit die SPS einen echten Falschzustand von nicht verfügbaren Daten unterscheiden kann.

Testen Sie außerdem Kaltstart, Warmstart, Zählererhalt, Rezeptabweichung, blockierte Sensoren, gleichzeitige Ankünfte und Bediener-Reset. Dokumentieren Sie den Anfangszustand jedes beschreibbaren Tags sowie die erforderliche Abfolge zum Wechsel in den Automatikbetrieb.

Die virtuelle Zelle in eine Testumgebung verwandeln

Verwenden Sie wiederholbare Abnahmetests: kein Aktuator vor erfüllten Startfreigaben; genau eine Zählung pro Produkt; kontrollierter Stopp am Ziel; Timeout bei einem blockierten Sensor; Fehler bei Kommunikationsverlust; und vorhersehbare Wiederherstellung nach der Wiederverbindung. Tag-Trends und Bestehens-/Nichtbestehensprotokolle liefern aussagekräftigere Nachweise als Screenshots einer bewegten Szene.

Mitsubishi-Steuerungsoptionen können in der Sammlung Mitsubishi Electric geprüft werden; weitere Steuerungshardware finden Sie unter SPS- und PAC-Systeme.

OPC ist lediglich die Transportschicht. Der technische Nutzen entsteht, wenn die virtuelle Zelle zu einer wiederholbaren Testumgebung für SPS-Verhalten, Signalbesitz, Timing-Annahmen, Fehlerreaktion und Wiederanlauf-Logik wird, die auf die physische Maschine übertragbar sind.