Effizienter Einsatz Simulations-basierter Tests in der Entwicklung automatisierungstechnischer Systeme

Transkript

1 Effizienter Einsatz Simulations-basierter Tests in der Entwicklung automatisierungstechnischer Systeme M.Sc. Mike Barth, Helmut-Schmidt-Universität, Hamburg, Dipl.-Ing. Florian Wagner, Universität des Saarlandes, Prof. Dr.-Ing. Georg Frey, Universität des Saarlandes, Prof. Dr.-Ing. Alexander Fay, Helmut-Schmidt-Universität, Hamburg. Kurzfassung Simulation hat sich Gewerke-übergreifend zu einem wichtigen Bestandteil des Testens entwickelt. Unabhängig vom Fortschritt der Fertigstellung von Produkt-, Anlagen- oder Softwarekomponenten bietet die Modellierung der fehlenden Teilsysteme die Möglichkeit, entwicklungsbegleitende Tests durchführen zu können. In diesem Beitrag werden Anforderungen und Voraussetzungen beschrieben, welche erfüllt sein müssen, um Simulation im Rahmen von Tests der Automatisierungstechnik effizient einsetzen zu können. In diesem Zusammenhang wird eine Methode vorgestellt, mithilfe der die auf C basierende Simulationsumgebung Dymola mit Funktionen der Hochsprache C# gekoppelt werden kann. Neben den Aspekten der Umsetzung werden insbesondere die sich aus der Verknüpfung beider Systeme ergebenden Vorteile anhand von zwei Beispielen erläutert. 1. Einleitung 1.1 Testen in der Entwicklung automatisierungstechnischer Systeme Die Qualitätsanforderungen an automatisierungstechnische Systeme steigen stetig an. Einerseits nimmt die Automatisierungstechnik (AT) eine immer prominenter werdende Rolle in der Wertschöpfungskette ein, wodurch in ihr vorhandene Mängel in immer höherem Maße geschäftskritisch sind [1]. Andererseits werden die sicherheitstechnischen Anforderungen für den Betrieb technischer Systeme stetig überarbeitet, wobei die zur Einhaltung von Gesetzen, Normen und Richtlinien notwendigen Funktionalitäten in hohem Maße auf AT-Komponenten basieren. Um die Qualitätsanforderungen zu erfüllen, kommt dem Nachweis des korrekten Verhaltens eine bedeutende Rolle zu, die es bereits in frühen Projektphasen zu validieren gilt. Im industriellen Umfeld hat sich Testen als Mittel zur Fehleridentifikation etabliert. Als problematisch erweist sich jedoch häufig, dass der zu steuernde Prozess erst in späten Projekt-

2 phasen, manchmal erst während der Inbetriebnahme, für Tests der AT-Infrastruktur zur Verfügung steht. Dies führt zu erhöhten Entwicklungskosten. Eine Alternative zum Testen am real zu steuernden Prozess bietet das Testen an einem Simulationsmodell. 1.2 Simulation im Test-Engineering Einsatzmöglichkeiten Es existieren verschiedene Varianten für den Einsatz von Simulation beim Test automatisierungstechnischer Systeme. Bild 1 gibt hierzu einen Überblick: Bild 1: Einsatzvarianten von Simulation beim Test automatisierungstechnischer Systeme Die Ausprägungen unterscheiden sich dadurch, welche Komponenten beim Testlauf simuliert werden. Wird ein Test ausschließlich mit realen Komponenten durchgeführt, also auf Simulation verzichtet wird, handelt es sich um einen klassischen Testbetrieb. Das Gegenteil des Testbetriebs ist die reine Simulation (Systemsimulation). Hierbei werden sowohl der zu steuernde Prozess als auch die AT-Hardware simuliert. Die Systemsimulation eignet sich insbesondere für schnell umzusetzende Untersuchungen zu Beginn eines Projekts und erlaubt so, falsche Lösungsansätze frühzeitig auszuschließen oder verschiedene Lösungsansätze bzgl. ihrer jeweiligen Performanz miteinander zu vergleichen. Das Testen der simulierten (man spricht auch von emulierten) AT-Komponenten am realen Prozess durch Software-In-The-Loop (SIL) -Simulation ist weniger für den System-Integrator als vielmehr für den Komponenten-Hersteller von Bedeutung. Mit SIL-Simulation ist es möglich, nicht-funktionale Anforderungen, wie z.b. die Echtzeitanforderungen der zu entwickelnden Steuerungshardware, am echten Prozess auszuloten. In der Praxis besitzt das Testen

3 durch Hardware-In-The-Loop (HIL) -Simulation die größte Bedeutung für den Systemintegrator. Die zu liefernde, bereits erstellte AT-Infrastruktur wird hierbei mit einem Simulations- Modell des zu steuernden Prozesses gekoppelt. Ist dabei eine geeignete Simulations- Infrastruktur vorhanden, können Testläufe mit verhältnismäßig geringem Ressourceneinsatz durchgeführt werden. Entscheidungen und Entwicklungsschritte im Projektverlauf können iterativ durch Tests am simulierten Prozess validiert und gegebenenfalls korrigiert werden. Der Validierungsnutzen kann insbesondere dadurch maximiert werden, dass die Testläufe automatisiert durchgeführt werden. HIL-Simulation bietet Automatisierungspotenziale, die mit Tests am realen Prozess nicht gegeben sind. Nur in der Simulation kann der Defekt einer Prozess-Komponente (z.b. eines Sensors) von einem Moment auf den anderen aktiviert o- der deaktiviert werden. Ebenfalls nur mithilfe der Simulation wird es möglich, den zu steuernden Prozess durch sofortiges Reinitialisieren für den nächsten Testlauf vorzubereiten. Bei Tests am realen Prozess wird zwischen zwei Testläufen Zeit für die Überführung der Anlage in den Initialzustand notwendig. Somit können im gleichen Zeitraum mehr Tests durchgeführt werden. Ebenfalls in die Betrachtungen mit einzubeziehen ist der Ressourcenaufwand, der durch die Simulation des zu steuernden Prozesses eingespart werden kann. Der simulierte Prozess verbraucht, außer für den Simulationsrechner, keine Energie und kein Material. Für Überwachung und Wartung des simulierten Prozesses wird kein Personal benötigt. Ebenso verringert sich der Aufwand für die Erstellung von Prozess-Prototypen, wie sie beispielsweise bei Grenzbelastungstests notwendig sind. Ein weiterer Punkt ist die nicht mehr vorhandene Notwendigkeit von Hardware zur Messwertaufnahme. In einer Simulation geschieht die Messwertaufnahme implizit im Rahmen der Berechnung der zu messenden Größe. Somit ist das Messergebnis Bestandteil der Simulationsresultate und liegt direkt in einem maschinenlesbaren und automatisiert auswertbaren Format vor. Der Einsatz eines simulierten Prozesses bietet zusätzlich sicherheitstechnische Vorteile. Wenn die AT-Infrastruktur versagt, was in frühen Phasen des Entwicklungs-Projekts nicht auszuschließen ist, kann es im simulierten Prozess nicht zu Schäden von Mensch oder Maschine kommen. Umgekehrt bietet die Simulation des Prozesses die Möglichkeit, den Schaden bei Versagen der AT-Infrastruktur gefahrlos zu ermitteln, z.b. um die notwendigen Ressourcen für die Sicherheitstechnik zu planen. Der Nutzen durch HIL-Simulation kann in Ergänzung dadurch gesteigert werden, dass die Durchführung auf effiziente Weise erfolgt. Die hierfür notwendigen Voraussetzungen und

4 Lösungsansätze werden in den folgenden Kapiteln erläutert und an mehreren Beispielen demonstriert. 2. Anforderungen und Voraussetzungen für den effizienten Einsatz von Simulation Zunächst werden Anforderungen und Voraussetzung definiert, die erfüllt sein müssen, um Simulation als Werkzeug zur Unterstützung der in Kapitel 1 dargelegten Testmethoden Hardware-in-the-Loop- und Systemsimulation effizient einsetzen zu können: a) Grundlage der Simulation bildet das Simulationsmodell. Um den Modell- Erstellungsaufwand so gering wie möglich zu halten, sollte angestrebt werden, das Simulationsmodell des gegebenenfalls komplexen Gesamtsystems durch die Verknüpfung einfacherer Komponentenmodelle zu erstellen (auch Aggregation genannt). Für die weit verbreiteten Multi-Domänen-Simulationswerkzeuge (wie z.b. Matlab/Simulink oder Dymola) gibt es zahlreiche freie und kostenpflichtige Modell-Bibliotheken. Im Sinne der Effizienz ist es von Bedeutung, bei der Wahl des Simulationswerkzeuges und der Komponenten-Bibliotheken darauf zu achten, dass die notwendigen Modelle bereits vorhanden sind oder mit für den Einzelfall akzeptablem Aufwand an die eigenen Bedürfnisse angepasst werden können. b) Nicht zu unterschätzen ist der Aufwand für die Parametrierung der Simulationsmodelle. Selbst wenn ein Modell prinzipiell die Eigenschaften nachbildet, die für den Test benötigt werden, muss es stets auf die konkreten Bedingungen des realen Prozesses eingestellt werden. Dies geschieht im Allgemeinen durch Parametrierung der einzelnen Komponentenmodelle. Hierbei ist bei der Wahl der Komponenten-Bibliotheken darauf zu achten, dass die für die Modell-Parametrierung notwendigen Daten mit der vorhandenen Daten- Basis (z.b. Datenblätter) kompatibel sind [2]. Es kann sehr aufwendig sein, Parameter für ein Komponenten-Modell zu beschaffen, wenn die notwendigen Daten in prinzipiell zugänglichen Datenblättern nicht enthalten sind. Das bedeutet auch, bei der Bibliotheksauswahl darauf zu achten, dass die Modelle nicht unnötig viel Funktionalität abbilden. c) In einigen Fällen wird Simulation beim Testen nicht eingesetzt, da der finanzielle Aufwand für die Errichtung der Simulations-Infrastruktur als zu hoch eingeschätzt wird. Oftmals lauten die Aussagen, dass insbesondere für die Durchführung von HIL- Simulationen sogenannte Echtzeit-Hardware notwendig ist [3]. Für einige Gebiete der Automatisierungstechnik ist das zutreffend (z.b. motion control). Ebenso gibt es aber auch Anwendungsbereiche, in denen Standard-Büro-Rechner einen mehr als ausreichenden Determinismus für HIL-Simulationen bieten. Im Sinne der Effizienz sollte dem-

5 nach geprüft werden, welche Echtzeitanforderungen an das Simulations-Modell tatsächlich bestehen. Durch den Einsatz von Standard-Computertechnik lässt sich der Investitions- und Inbetriebnahme-Aufwand für die Simulations-Infrastruktur stark senken. d) Beim Einsatz von HIL-Simulationen stellt die Kopplung der AT-Komponenten mit dem Simulations-Modell eine häufig auftretende Herausforderung dar. Bisher hat sich hierfür keine Standard-Technologie etabliert. Zwar sind zahlreiche Möglichkeiten zur Kopplung von IT-Komponenten mit Simulations-Modellen publiziert (Shared Memory, Named Pipes, TCP-IP-Kopplung) [4], eine konkrete Anleitung zur Implementierung oder Umsetzung wird jedoch meist nicht angegeben. Zusätzlich besteht das Problem, dass die AT- Komponenten meist nur über eingeschränkte Möglichkeiten zur Anpassung an proprietäre Schnittstellen bieten, wie sie die zuvor genannten Kopplungs-Mechanismen jedoch voraussetzen. Falls dennoch Anpassungsoptionen bestehen, sind hierfür spezielle Werkzeuge notwendig bzw. der Komponenten-Hersteller muss eine (kostenpflichtige) kundenspezifische Anpassung vornehmen. Aus Effizienzgründen bietet es sich daher an, für die Kopplung von AT-Infrastruktur und Simulations-Modell auf eine Standard- Schnittstelle zu setzen, und die notwendigen Anpassungen hierfür ausschließlich im Simulationsmodell bzw. im Simulationswerkzeug durchzuführen. Bei der Wahl des Simulationswerkzeugs sollte darauf geachtet werden, dass solche Anpassungen möglich sind, die Anpassungsmöglichkeiten dokumentiert sind und der Anpassungsaufwand überschaubar ist. Die unter a) geforderte frühzeitige Bereitstellung oder Entwicklung von auf den Einsatzzweck abgestimmten Modellbibliotheken wird meist unternehmensintern gelöst. Hierbei werden auf die eigenen Produkte und Dienstleistungen abgestimmte Modelle in den vorhandenen, meist käuflich erworbenen Simulationsumgebungen entwickelt oder ebenfalls zugekauft. Die für die Beispiele in Kapitel 4 verwendeten Komponenten (Tank, Ventil) entstammen Open-Sourcebzw. Open-Innovation-Projekten, die ihre Entwicklungs-Ergebnisse kostenfrei zur Verfügung stellen. Vor allem die hinter der in diesem Beitrag thematisierten Modellierungssprache Modelica stehende Entwicklungsgemeinschaft Modelica Association basiert auf der Mitarbeit zahlreicher Unternehmen und Hochschuleinrichtungen. Die jeweiligen Fachrichtungen der Mitglieder resultieren in Modellbibliotheken der unterschiedlichsten Gewerke, deren Kopplung auf viele technische Problemstellungen anwendbar ist. Anforderung b) lässt sich durch die funktionale Einbindung von vorhandenen Planungsdaten lösen. Viele der Parameter, welche in den Modellen gesetzt werden müssen, sind bereits in rechnergestützt auswertbarer Form beispielsweise in einem Planungs- oder Konstrukti-

6 onswerkzeug vorhanden. Mithilfe der Einbindung moderner Datenaustauschformate können diese, wie in Kapitel 4.2 gezeigt wird, effektiv in die Simulation eingebunden werden. Dass für einige Anwendungen der HIL-Simulation, wie unter c) erläutert, nicht zwingend zusätzliche Systeme für Echtzeitanwendungen einbezogen werden müssen, trifft auch für die im Folgenden vorgestellten Umsetzungen zu. So können, je nach Anwendung, Echtzeitanforderungen im Bereich von 100 ms oder höher vorliegen, die zumeist mit einem Standard- PC erfüllbar sind. Für die Umsetzung der unter a) bis d) genannten Anforderungen in Bezug auf die Kopplung der Simulationsumgebung mit dem AT-System werden im Folgenden das Simulationswerkzeug Dymola in Verbindung mit der objektorientierten Sprache Modelica sowie die Standard- Methoden moderner Hochsprachen in Verbindung mit der Kommunikationsschnittstelle OPC verwendet. 3. Einbindung externer Funktionalitäten in die Simulationsumgebung Dymola Simulationsumgebungen besitzen bereits heute umfassende Schnittstellen zu anderen Softwarewerkzeugen. Selbst komplexe Berechnungen im Bereich der FEM oder CFD beinhalten bereits Möglichkeiten zur Datenübernahme aus beispielsweise 3D-CAD-Umgebungen. Auch in der Automatisierungstechnik werden die unterschiedlich eingesetzten Werkzeuge in den Engineering-Ablauf integriert und dafür notwendige Schnittstellen geschaffen. Ein Beispiel hierfür ist die Übernahme von Daten der verfahrenstechnischen Simulation in die CAE- Planung innerhalb der Prozessindustrie [5], [6]. Das in dieser Arbeit verwendete Werkzeug Dymola [7] basiert auf der Modellierungssprache Modelica [8], welche mit ihrem gleichungsbasierten objektorientierten Aufbau gut für die Simulation physikalisch-technischer Prozesse geeignet ist. Der Tatsache geschuldet, dass die Modelle schnell, kompakt und unabhängig von weiterhin installierter Software ausgeführt werden sollen, findet vor Beginn der Simulation eine Kompilierung in C statt. Dabei wird eine ausführbare (*.exe) Datei des Modells erzeugt. Dementsprechend einfach gestaltet sich die Einbindung externer, in der Programmiersprache C entwickelter Funktionen in den Modelica- Code. Ein Beispiel hierfür ist die JPAA Realtime Bibliothek [9], welche C-basiert auf die Rechnerzeit zugreift, um die Simulations-interne Zeit damit zu synchronisieren. Das Engineering im Bereich der Automatisierungstechnik bedient sich häufig moderner Umsetzungen der Informatik. Gerade für die zunehmend in XML verfassten Datenaustauschformate und deren rechnergestützte Anwendung innerhalb der AT z.b. PLCopen XML oder CAEX [10] sind effizient zu implementierende Abfragen notwendig. Die in diesem Zusammenhang notwendigen Bibliotheken und darin beinhaltete Methoden werden jedoch zuneh-

7 mend in die objektorientierten Hochsprachen C# und Java integriert. Ein Beispiel hierfür ist die seit 2008 als DLL verfügbare LinQ-Library [11] für die Entwicklungsumgebung Visual Studio. Vor diesem Hintergrund wird ein Ansatz benötigt, um die auf C basierenden Simulationsumgebungen mit modernen Programmierumgebungen zu verbinden. Bezogen auf C# liegt die Komplexität darin, einen nicht verwalteten ( unmanaged ) C- oder C++-Code mit den durch die Speicherverwaltung von Microsofts Common Language Runtime verwalteten ( managed ) C#-Applikationen zu koppeln. Hierfür wird die sogenannte COM-Operabilität des.net-frameworks eingesetzt, welche ursprünglich dafür entwickelt wurde, ältere Windows-Applikationen mit.net kommunizieren zu lassen. Hiermit können C#- Funktionen COM-Elemente aufrufen und umgekehrt, was einen bidirektional initiierten Datenaustausch ermöglicht. Um weiterhin uneingeschränkt Klassenstrukturen, deren Methoden und Attribute in C# definieren zu können, bietet es sich an, eine separate Klasse für die Kommunikation zu erstellen, welche alle Funktionsaufrufe beinhaltet, die für die Schnittstelle zur Simulationsumgebung benötigt werden. Mit dieser Vorgehensweise muss lediglich eine Klasse als Schnittstelle definiert werden [ClassInterface(ClassInterfaceType.AutoDual)]. Weiterhin muss in der Projektinformationsklasse Assemblyinfo.cs das.net Projekt für COM Applikationen sichtbar gemacht und eine GUID (Globally Unique Identifier z.b.: assembly: Guid "6bd2ea55-e4aa-47bb-9cc3-61fda38a7a55") erstellt werden. Letztere dient durch ihren 128-bit Integer Wert als eindeutige Kennung der Applikation unter Windows. Um die nichtverwalteten ( unmanaged ) C++ oder C-Applikationen auf Typen von C# zugreifen zu lassen, wird aus dem kompletten Projekt eine TypeLibrary (*.tlb) erzeugt, welche in die COM Anwendungen eingebunden wird. Abschließend muss das C#-Programm in eine Dynamic Link Library (*.dll) transformiert werden, auf welche später zugegriffen wird. In einem nächsten Schritt müssen diejenigen Funktionen, welche als Schnittstelle definiert sind und auf die Dymola während der Simulation Zugriff haben soll, in ein C oder C++ Projekt eingebunden werden. Da die COM-Applikation ausschließlich zur Weitergabe der Speichercontainer (z.b. Variable oder Array) notwendig ist, bietet es sich an, dieselbe Funktionsstruktur wie im verwalteten.net-programm zu wählen. Wie bereits erläutert, bindet Dymola die hier definierten Methoden als externe C-Funktionen in den Modelica-Code ein. Um alle hierfür notwendigen Definitionen und Deklarationen zu treffen, muss eine Header-Datei (*.h) eingebunden werden. Diese kann jedoch auf die Angabe der Funktionsnamen, der Kommunikationsvariablen und deren Datentypen begrenzt werden. Bild 2 zeigt die bislang beschriebene Vorgehensweise, erweitert um die Kompilierung zu einem ausführbaren und simulationsfähigen Programm in Dymola. Hierbei werden die vorbereitenden (offline) Tätigkeiten, d.h. die Entwicklung der verwalteten und nicht-verwalteten Projekte sowie deren Einbindung

8 in den Modelica Code, getrennt von den online-abläufen zur Simulation des Modells dargestellt. Bild 2: Schnittstellen zwischen Dymola und.net Das durch die Simulationsumgebung erzeugte Modell initialisiert die Kommunikation je nach Art der definierten Funktionsaufrufe. So können Variablen zyklisch, innerhalb von bestimmten Intervallen, oder bei Eintritt eines Ereignisses übertragen werden. Bild 3 zeigt das Kommunikationsmodell während der laufenden Simulation.

9 Bild 3: Kommunikation des ausführbaren Simulationsmodells Mithilfe von Echtzeit-Bibliotheken, wie der zu Beginn des 3. Kapitels aufgeführten JPAA- Bibliothek in Kombination mit Benutzer-Interaktionsblöcken [12], wird es möglich, während der laufenden Simulation Variablen zu definieren oder aus der.net-umgebung zu empfangen. 4. Umsetzungsbeispiele In den folgenden Kapiteln werden die bislang gelegten Grundlagen anhand von Anwendungsbeispielen verdeutlicht. Dabei stehen insbesondere die Vorteile einer Verbindung der für C-Compiler entwickelten Simulationsumgebung Dymola mit den objektorientierten Applikationen in.net im Vordergrund. 4.1 Kopplung AT und Prozess durch Einsatz der Standardtechnologie OPC Um Simulationsmodelle effektiv in den Entwicklungsprozess einbinden zu können, stellen die in Kapitel 1 beschriebenen Echtzeitanwendungen in Kombination mit Standard-PC- Werkzeugen eine wirksame Methode dar. Dies setzt jedoch eine Schnittstelle voraus, welche von den meisten Programmen unterstützt wird. In den unterschiedlichen Anwendungsfeldern der Automatisierungstechnik hat sich hierfür der OPC-Standard durchgesetzt. Auch Simulationsmodelle müssen eine entsprechende Anbindung vorsehen. Moderne OPC-Clients werden zunehmend als DLL in.net und damit offen für programmiertechnische Erweiterungen und die Einbindung in unternehmenseigene Entwicklungen am Markt angeboten. In diesem Zusammenhang ist es möglich, die in Kapitel 3 vorgestellten Umsetzungen zu nutzen, um die mit Dymola implementierten Simulationsmodelle mit den OPC-Clients in.net zu verbin-

10 den. Bild 4 zeigt die hierfür in Dymola erstellte Bibliothek mit den unterschiedlichen Funktionen zur Übertragung der möglichen Variablentypen (Real, Boolean, String und Integer). Diese können entweder direkt in den Modelica-Code eingebunden oder im Sinne einer blockbasierten (grafischen) Modellierung mit den Signal-Ein- und -Ausgängen des Simulationsmodells verbunden werden. Die Abbildung zeigt beispielhaft eine Kopplung mit Elementen der Modelica-Fluid Bibliothek, welche zur Modellierung von Fluidnetzwerken eingesetzt wird. Ein Ventil kann dadurch mit einem OPC-Input-Block grafisch verbunden werden, um ein Öffnungssignal von außerhalb der Simulation zu empfangen. Umgekehrt kann der dargestellte Flüssigkeitsbehälter beispielsweise seinen aktuellen Füllstand, seine Medientemperatur, den Innendruck, oder weitere modellierte Variablen an den OPC-Output-Block übergeben. Im Beispiel konnte hiermit ein komplettes Modelica-Simulationsmodell einer Forschungsanlage für Prozessleittechnikapplikationen erstellt und mit den existierenden Steuerungsprogrammen verbunden werden. Als Systemsimulation ausgelegt, konnten sowohl das Simulationsmodell als auch das eingesetzte Soft-PLS auf demselben PC ausgeführt werden. Es ist jedoch ebenso möglich, Simulationsmodell und Steuerungscode auf verschiedener, über ein Netzwerk verbundener Hardware ausführen zu lassen. Bild 4: OPC-Kommunikation zwischen Dymola und.net 4.2 Nutzung von PLCopen XML für die Definition von OPC-Variablen in Dymola Für die in Kapitel 4.1 erläuterte OPC-Kommunikation kann mithilfe der im folgenden Beispiel gezeigten Funktionen ein weiterer Automatisierungsgrad erreicht werden: Durch die Einbindung von PLCopen XML-Spezifikationen können in den Sprachen der IEC entwi-

11 ckelte Steuerungsprogramme gänzlich in ein rechnergestützt anwendbares XML-Format transformiert werden. Dies beinhaltet unter anderem die Definition der in den jeweiligen Applikationen eingebundenen globalen und lokalen Variablen. Bild 5 links zeigt hierzu ein Beispiel für eine Variablendeklaration im PLCopen XML Format. Um dies effektiv einladen zu können, stellt.net seit der Version 2008 eine neue Bibliothek LinQtoXML zur Verfügung. Hierin beinhaltet sind an SQL-Datenbankabfragen angelehnte Funktionen, mithilfe derer große und komplex strukturierte XML-Dateien in C# eingebunden oder erstellt werden. Im vorliegenden Beispiel werden in einem ersten Schritt aus Steuerungsprogrammen abgeleitete Variablendeklarationen im PLCopen XML-Format dazu verwendet, um die Kommunikationsvariablen für OPC in Dymola (Bild 5 rechts) zu definieren. Hierbei wird in.net eine Modelica-Enumeration erzeugt, welche dem Anwender zur Modell-Parametrierung eine Auswahlmöglichkeit der verfügbaren OPC-Variablen während der laufenden Simulation bietet. Diese aufgrund der manuellen Auswahl zunächst teilweise automatisierte Lösung könnte in Kombination mit Algorithmen zur Simulationsmodellgenerierung und Regeln zur Namensgebung der Steuerungsvariablen (Mappings) hin zu einer vollautomatisierten Umsetzung entwickelt werden. Bild 5: Überführung von PLCopen XML Variablen nach Dymola Die so in.net eingelesenen OPC-Variablennamen können über die in Kapitel 3 beschriebenen Schnittstellen an Dymola übertragen werden, wo sie als Auswahlhilfe bei der Parametrierung der OPC-Kommunikationsblöcke dienen.

12 5. Zusammenfassung und Ausblick Der Beitrag hat Voraussetzungen und Möglichkeiten aufgezeigt, um Simulation als Testwerkzeug effizient in den Entwicklungsprozess automatisierungstechnischer Systeme einzubinden. Anhand der entwickelten Schnittstelle zwischen der auf C-Compiler abgestimmten Simulationsumgebung Dymola und den in Hochsprachen programmierten.net Applikationen wurden Beispiele aufgeführt, wie Methoden unterschiedlicher Werkzeuge im Zusammenspiel genutzt werden können. In diesem Zusammenhang können moderne XML-Datenformate effizient genutzt und die Verbindung zu beispielsweise Steuerungen hergestellt werden. Unter Berücksichtigung der sich stetig ausbauenden Methoden der.net-welt auf der einen und den wechselnden Kommunikationsstandards auf der anderen Seite wird durch die entwickelte Schnittstelle sichergestellt, dass bestehende Simulationsmodelle auch zukünftig mit modernen Entwicklungswerkzeugen und Formaten der Automatisierungstechnik verknüpft werden können. Literatur [1] VDI/VDE Gesellschaft: Automation Bedeutung und Entwicklung der Automation bis zum Jahr Thesen und Handlungsfelder. Thesenpapier zur Automation 2009 Baden Baden. [2] Barth, M.; Strube, M.; Fay, A.; Weber, P.; Greifeneder, J.: Object-oriented engineering data exchange as a base for automatic generation of simulation models; In: Proceedings of the "IEEE IECON 2009", Porto, Portugal, November 2009, pp [3] VDI-Richtlinie 3633 Blatt 8: Simulation von Logistik-, Materialfluss und Produktionssystemen - Maschinennahe Simulation, [4] Ebner, A.; Haumer, A.; Dragan, S.; Pirker, F.: Interacting Modelica using a Named Pipe for Hardware-in-the-loop Simulation; In: Proceedings of the 5 th Modelica Conference, Vienna, 2006, pp [5] Barth, M.; Fay, A.: Nutzung verfahrenstechnischer Planungsdaten für die Parametrierung von Simulationsmodellen der Automatisierungstechnik, 7. Symposium Informationstechnologien für Entwicklung und Produktion in der Verfahrenstechnik, Aachen, [6] Anhäuser, F.; Richert, H.; Temmen, H.: Degussa PlantXML integrierter Planungsprozess mit flexiblen Bausteinen. Automatisierungstechnische Praxis (atp); Heft 10/2004, S [7] Dymola, Dassault Systems [letzter Aufruf: ].

13 [8] Otter M., Elmqvist H., Mattsson S. E.: Multidomain Modeling with Modelica. Handbook of Dynamic System Modelling. Fishwick, Chapman & Hall, pp , [9] Wagner, F.; Frey, G.: Hardware-in-the-Loop-Simulation bei kurzfristig zu langsamen Simulations-Modellen. Automation im gesamten Lebenszyklus, In Tagungsband: GMA- Kongress 2007, VDI-Berichte 1980, Baden-Baden, S , [10] Drath, R (Hrsg.).: Datenaustausch in der Anlagenplanung mit AutomationML: Integration von CAEX, PLCopen XML und COLLADA, Springer, Berlin, [11] Language-Integrated Query (LINQ) - Microsoft.Net Framework 4, [letzter Aufruf: ]. [12] The Modelica Association Chairman Prof. Martin Otter: Modelica Standard Library 3.1 build 5 (released on 2009/12/18) [letzter Aufruf: ].