Hardware-in-the-Loop (HIL) Simulation – auch bekannt als Emulation – wird immer bedeutsamer bei der Gewährleistung von guter Softwarequalität und kurzen Entwicklungszyklen bei komplexen Automationslösungen. In dem Forschungsprojekt OMSIS - On-the-fly-Migration und Sofort-Inbetriebnahme von automatisierten Systemen - (http://iai8292.inf.tu-dresden.de/omsis) arbeiten die Technische Universität Dresden und INCONTROL Simulation Solutions als Kooperationspartner daran, die Software ENTERPRISE DYNAMICS für HIL Simulation auszubauen.

Wenn komplexe mechatronische Systeme herkömmlich aufgebaut werden, ist das Software Engineering der letzte Entwicklungsschritt, der nicht vor dem Zusammenbau der mechanischen Teile erfolgen kann. Bedeutende Teile des Software-Engineering-Prozesses werden typischerweise während der Kommissionierphase bei Produktionsstart durchgeführt, was zu Zeit- und Qualitätsverlust führt. Ein Ansatz, der unter Hardware-in-the-loop (HIL) Simulation bekannt geworden ist, versucht diese Situation zu bewältigen: Durch Emulation (Nachbildung) des Verhaltens der noch zu erstellenden Automationshardware kann das Engineering und die Validierung der Steuerungssoftware oder des HMI (Human-Machine-Interface) wesentlich früher erfolgen, was wiederum zu höherer Qualität und kürzeren Produktentwicklungszyklen führt. Darüber hinaus können Fehler während der Programmierung weder die Anlagen noch das Personal gefährden.

Damit dieser Ansatz angewendet werden kann, muss eine effiziente I-/O-Kopplung zwischen Simulation und Echtzeitsteuerung eingerichtet werden, die einerseits (virtuelle) Sensordaten an die Steuerung sendet und andererseits Steuerungsdaten für das (virtuelle) Bedienteil akzeptiert. Einige hundert Signale werden dabei innerhalb von Millisekunden ausgetauscht. Das hört sich auf den ersten Blick aufwendig für die Verdrahtung an. Aber die weit verbreitete Struktur der meisten modernen Automationsinstallationen erlaubt eine elegante Lösung: Die I-/O-Module, die mit Sensoren und Aktoren (Bedienteilen) arbeiten, sind üblicherweise neben den mechanischen Komponenten installiert (oder sogar integriert); Datenkommunikation mit Programmable Logic Controller (PLC) wird über PROFIBUS DP (Decentralized Peripherals) realisiert – eine standardisierte und weit verbreitete Feldbuslösung.

Beim Arbeiten mit Simulation anstelle der realen Anlage ist es sinnvoll, den PROFIBUS als Schnittstelle zur virtuellen Anlage zu nutzen, anstatt Hunderte I-/O-Linien zu “schneiden”. Dies kann mit Hilfe von so genannter Multi-Slave-Emulation erreicht werden: Die Emulationshardware (z.B. eine PCI-Karte) ersetzt zahlreiche DP Slaves und erzeugt Zugang zu allen Eingangs- und Ausgangsvariablen mittels einer Software API, wobei die PLC dabei keinen Unterschied feststellt. Die gängigste Multi-Slave-Emulationssoftware ist SIMBApro, die - obwohl ein Siemens Produkt - nicht an Siemens Hardware gebunden ist, sondern mit jeder PROFIBUS kompatiblen Steuerung und DP Slave genutzt werden kann.

Um ENTERPRISE DYNAMICS für den Fertigungssimulationspart nutzen zu können, wurde eine Schnittstelle zur SIMBApro Suite innerhalb des OMSIS Projekts eingerichtet. Aus Anwendersicht besteht diese Schnittstelle aus drei neuen Atomen im Library Tree von ENTERPRISE DYNAMICS:

• Das SimbaProCtrl Atom, welches nur einmal pro Simulationsmodel verwendet werden soll, enthält grundsätzliche Einstellungen für die HIL Simulation, wie z.B. das Set der DP Slaves, das nachgebildet werden soll, oder die Aktualisierungsrate für alle I-/O-Variablen.
  
  
• Das FromPlc Atom stellt eine PLC Ausgabe dar, der auf Modellseite eine Eingabe ist und bspw. zur Steuerung eines Förderbandantriebs dienen kann. Das Atom gestattet die Ausführung von 4DScript Befehlen, wenn das betreffende PLC Signal sich ändert, wobei der Anwender volle Handlungsfreiheit darüber behält, was das Signal im Modell auslöst.
  
  
• Das ToPlc Atom wiederum repräsentiert eine PLC Eingabe ausgehend vom (virtuellen) Sensor im Modell - wie eine Lichtschranke. Dieses Atom ist dafür vorgesehen, an das Modellelement mit den Abtastwerten angeschlossen zu werden. Auch hier sorgen 4DScript Befehle dafür, dass die Ausgabewerte vom Modell geeignet evaluiert werden. Zusätzlich kann der Anwender in den Voreinstellungen des GUI Änderungen vornehmen, wie z. B. die Anzahl der untergeordneten Elemente oder der jeweilige Status (ungenutzt, beschäftigt, leer, voll, fördernd, etc.).

Um die HIL Schnittstelle zu validieren, wurde das Lehrmodell in ENTERPRISE DYNAMICS aufgebaut. Das Modell besteht aus einer U-förmigen, einbahnigen Förderbandlinie mit zwei angeschlossenen Maschinen und einem Roboter, welcher die bearbeiteten Werkstücke aufnimmt und auf das vordere Förderband legt. 24 digitale PLC-Ausgänge steuern die Roboterachsen, Förderbänder und Maschinenoperationen. 21 digitale Eingänge geben den Status der Lichtschranken, Grenzschalter und Frontplattensteuerungsknöpfe an. In ENTERPRISE DYNAMICS wurde das gesamte System basierend auf einigen Atomen aufgebaut, welche die mechanischen Gegebenheiten wie die Förderbänder oder Maschinen verdeutlichen. Alle Atome verarbeiten dieselben Eingangssignale und erstellen dieselben Ausgangssignale wie das mechanische Modell. Darüber hinaus werden alle Werkstücke so programmiert, dass sie einen Bericht erstellen, sofern sie in der realen Welt Schaden genommen hätten, z. B. Werkstücke, die auf den Boden fallen oder die vom Roboter über die Grenzen seiner Bewegungsachsen hinaus bewegt werden. Auf diese Weise war es möglich, die steuernde PLC-Applikation in Kombination mit dem virtuellen Modell vollständig zu entwickeln und zu testen, um anschließend sofort zum physikalischen Modell überzuleiten; ohne weitere Anstrengungen als das Umstecken des PROFIBUS Kabels vom Simulations-PC an die PROFIBUS-DP I-/O-Module.

Experimente mit dem beschriebenen Modell haben gezeigt, dass ENTERPRISE DYNAMICS HIL Szenarien ausführen kann. Performancetests ergaben weiterhin, dass die Anzahl von I-/O-Signalen, die im Beispiel genannt wurde, bei weitem nicht an eine Obergrenze heranreicht, so dass Projekte mit realen Datenmengen problemlos umgesetzt werden können. Außerdem wurde anhand der Experimente ermittelt, dass für die HIL Simulation ein vollständig neues Set von Bibliotheksatomen benötigt wird, das momentan verglichen mit ihren bereits in der ENTERPRISE DYNAMICS Logistics Library bestehenden Gegenstücken noch weniger geeignet ist. Alle Transport-, Handhabungs- oder Prozessatome müssen ihr Arbeitsevent nicht starten, da sie einer vorkonfigurierten Strategie folgen, wenn ein Werkstück bearbeitet werden soll. Die Atome müssen ihre Befehle direkt vom PLC erhalten, auch wenn diese Befehle keinen Sinn ergeben und – in der Realität – zur Zerstörung der Anlage beitragen würden. Obwohl die Erstellung der Atome Arbeitsaufwand bedeutet, rechnet sich dies sofort, da die Automationsbranche typischerweise viele verschiedene Einrichtungen mit ähnlichen mechanischen Komponenten ausstattet, z. B. mit Handhabungstechnologie, und die Atome somit in jedem neuen Projekt erneut eingesetzt werden können.

Lehrmodell aus Fischertechnik und INCONTROL ENTERPRISE DYNAMICS Modell mit einer Komponente, die einen Schaden meldet