hauptbeitrag Simulationsbasierte Steuerungsfunktionstests Generierung von Anlagenmodellen aus CAE-Planungsdaten Sicherzustellen, dass Steuerungsprogramme in Prozessleitsystemen (PLS) entsprechend der Kundenanforderungen implementiert wurden, ist eine wesentliche Aufgabe im Engineering von Automatisierungssystemen. Da diese Anforderungen nicht formalisiert vorliegen, werden dazu umfangreiche Tests durchgeführt. Dieser Beitrag stellt eine Methode vor, mit der das Test-Engineering durch den Einsatz von automatisch generierten Simulationsmodellen unterstützt und verkürzt wird. Mit dem generierten Anlagenmodell wird es möglich, rein virtuelle Steuerungstests und Hardware-in-the-Loop (HIL)-Prüfungen durchzuführen. So lassen sich Funktionsblöcke, Verriegelungen und Schrittketten sowie die für die Werksabnahme des Leitsystems (Factory Acceptance Test, FAT) notwendigen Kommunikationsparameter (zum Beispiel Feldbusadressen) testen. SCHLAGWÖRTER Factory Acceptance Test / automatische Modellgenerierung / Simulation / Modelica / CAEX / Objektorientierung / PLS-Test-Engineering Simulation based control logic tests Automated generation of simulation models based on CAE data To validate that control functions have been implemented correctly (according to specification) in process control systems is a crucial task in the engineering of automation systems. Because these specifications are usually only given informally, numerous test runs are carried out to detect possible design or implementation faults in the control software. Within this paper, a method is presented which supports the tests by means of automatically generated simulation models. Starting point is the hypothesis that it should be feasible to derive a simulation model from the CAE planning data of the process plant, and that this simulation model should be detailed and accurate enough to generate valid test results. This approach has been developed and implemented, which allows to run both purely virtual system simulations and Hardware-in-the-loop (HIL) tests. Thus, control function blocks, interlocks, sequences and communication parameters (such as field bus addresses) relevant for Factory Acceptance Test can be carried out with significantly reduced time and costs. KEYWORDS Factory Acceptance Test / automated model generation / simulation / Modelica / CAEX / object orientation 54
MiKE BARTH, Abb Forschungszentrum ALExanDER FAY, Helmut-Schmidt-Universität, JüRGEn GREifeneder, PETER WEBER, Abb Forschungszentrum Das Engineering von Prozessleitsystemen (PLS) stellt zunehmende Herausforderungen an Ingenieure. Zum einen haben sich Prozessleitsysteme zu einem Produkt mit hoher Funktionsintegration entwickelt, welche der Steuerung/ Regelung immer komplexerer Anlagen dienen. Andererseits sinkt die zur Verfügung stehende Projektdauer (seit 1970 um 25 %). Beide Entwicklungen erschweren es, eine konstant hohe Qualität der Automatisierungslösung beizubehalten. Verfahrenstechnische Anlagen operieren mit hohen Druck- und Temperaturniveaus und beinhalten teilweise gefährliche Medien. Aus diesem Grund können Fehler im Steuerungscode nicht ausschließlich für die Anlage gefährlich werden, sondern auch für Mensch und Umwelt schädlich sein. Die Konfiguration der Steuerungs- und Regelalgorithmen für Prozessleitsysteme zeichnet sich als eine der Aktivitäten aus, welche in mehrfacher Hinsicht als fehleranfällig kategorisiert werden muss. In NA 35 wird diese als Software Konfiguration bezeichnete Aktivität dadurch gekennzeichnet, dass vielfältige Fehlermöglichkeiten bestehen. Die Fehler werden meist erst in späteren Phasen, das heißt während der Inbetriebnahme auf der Baustelle erkannt, wodurch die Folgen monetärer und zeitlicher Natur sind [1]. Vor diesem Hintergrund kommt dem Testen der Steuerungskonfiguration eine entscheidende Rolle zu. In Teil 1 dieses Beitrages [2] wurde eine Methode zur semi-automatischen Überführung von Leitsystem-Typicals in Simulationsmodellobjekte vorgestellt. Der Fokus dieser Methode liegt auf der Generierung von Einzelelementinstanzen, welche sich für simulationsbasierte Tests von Funktionsbausteinen einsetzen lassen. Um jedoch Ablaufsteuerungen, Verriegelungen und Grenzwerte für größere Anlagenabschnitte testen zu können, muss es möglich sein, ein Simulationsmodell mit entsprechend instanziierten und verschalteten Modellobjekten des gesamten Anlagenabschnittes zu generieren. In diesem Beitrag werden dahingehend folgende Punkte als Bestandteil einer Generierung von Simulationsmodellen betrachtet [3]: a Instanziierung aller Modellobjekte (zum Beispiel Tanks, Ventile, Pumpen, Rohrleitungen) b Parametrierung aller Modellobjekte (wie Zuweisung von Durchmesser und Höhe eines Behälters) c Verschaltung aller Modellobjekte (Materialfluss, Energiefluss) d Generierung einer visuellen Repräsentation des Simulationsmodells e Definition der Kommunikation zwischen Simulationswerkzeug und Steuerung Die in Teil 1 dieses Beitrages erläuterte Generierung von Simulationsmodellen auf Basis des PLS-Engineering-Systems ermöglichte die Instanziierung (a) der Modellobjekte sowie die Ableitung der Kommunikationseinstellungen (e). Um eine vollständig automatische Modellgenerierung erreichen zu können, wird an dieser Stelle eine weitere, dem PLS-Engineering vorliegende Datenquelle für die automatische Modellgenerierung herangezogen: das CAE-System. 1. Datenquelle für die Modellgenerierung Die Nutzung von Planungsdokumenten, um Simulationsmodelle zu generieren, hängt von der dem Planungswerkzeug hinterlegten Datenmodellierung ab. Als Beispiel wird in [4] die Generierung von Verhaltensmodellen von Werkzeugmaschinen aus Stromlaufplänen beschrieben. Voraussetzung ist, dass die stromführenden Leiter im Stromlaufplan nicht ausschließlich als Linien gezeichnet, sondern als Leiterobjekte mit entsprechend instanziierten Verbindungen angelegt werden. Im Gegensatz zu konventionellen CAE-Systemen vermeiden objektorientierte CAE-Systeme die getrennte Datenhaltung von Grafikdateien, abgelegt in einem Dateisystem, und alphanumerischen Daten. Grafische und alphanumerische Informationen werden zusammen in einem Datenbankobjekt gespeichert. Die grafischen Editoren arbeiten unmittelbar auf den Datenbanken und nicht wie bei den konventionellen Systemen in Grafikdateien. Die Bezeichnung objektorientiert bezieht sich 55
HauPTbeitrag nicht auf die eingesetzte Datenbank, da diese in den meisten Werkzeugen eine relationale Standarddatenbank ist. Objektorientiert bedeutet, dass für jedes Objekt im PLT-Engineering-Zyklus alle Daten nur einmal eingegeben werden müssen und in allen anderen unterstützten Engineering-Phasen inklusive ihrer syntaktischen Zusammenhänge zur Verfügung stehen [5]. Derartige CAE- Systeme werden zunehmend eingesetzt. Vertreter sind Comos PT, PLANEDS und SmartPlant P&ID. Der Hauptvorteil ist, dass ein real vorhandenes Objekt, beispielsweise ein Elektromotor, als zentraler dokumentenübergreifender Träger von Planungsinformationen betrachtet wird. Einem solchen Objekt werden Attribute zugeordnet, die sich beispielsweise für die Generierung und Parametrierung eines Simulationsmodells nutzen lassen. Dies wurde bereits im Projekt Aubios (Automatisierung umwelt- und bioverfahrenstechnischer Prozesse und Systeme) erfolgreich genutzt, indem Bibliothekselemente des CAE-Systems Comos PT um Simulationsaspekte aus der Verfahrenstechnik erweitert wurden [6]. Die Auswirkungen der Objektorientierung auf eines der wichtigsten Planungsdokumente der PLT-Planung, das Rohrleitungs- und Instrumentenfließbild, werden im folgenden Abschnitt erläutert. 1.1 Rohrleitungs- und Instrumentenfließbild Auf dem Grund- und Verfahrensfließbild aufbauend gibt das Rohrleitungs- und Instrumentenfließbild (R&I-Fließbild) einen Überblick der leittechnischen Planung in Form von Elektro-, Mess-, Steuerungs- und Regelungstechnik- Funktionen (EMSR). In [7] wird es als Schlüsseldokument für ein angestrebtes durchgängiges Engineering definiert. Die datentechnisch dahinterliegenden Objektstrukturen bilden bereits heute die Grundlage für eine Vielzahl von Automatismen. Beispielhaft kann die Generierung von PLT-Stellenverzeichnissen genannt werden [5]. In einem objektorientierten CAE-System werden bei der Erstellung des R&I-Fließbildes vorhandene Bibliotheksobjekte oder Module instanziiert und, sofern möglich, spezifiziert. Bild 1 zeigt ein Beispiel, in dem die Geometriedaten (zum Beispiel Höhe, Innendurchmesser, Volumen) eines Behälters über eine Parametermaske eingegeben werden. Die Bedeutung des R&I-Fließbildes für das PLT-Engineering wird in [8] bestärkt, in dem das R&I-Fließbild als Ausgangspunkt für die Automatisierung von Engineering-Tätigkeiten benannt wird. Vor dem Hintergrund der im R&I-Fließbild enthaltenen Planungsobjekte, deren mögliche Parametrierung sowie deren Verbindung wird dieses CAE-Dokument als Datenquelle für die im Folgenden erläuterte Modellgenerierung benutzt. 1.2 Überführung in ein neutrales Datenaustauschformat Für eine automatische Generierung der Simulationsmodelle werden die Daten des R&I-Fließbildes in einem rechnergestützt auswertbaren Format benötigt. Die damit verbundene Thematik eines rechnergestützten Austausches von Engineering-Daten ist seit den frühen Einsätzen von CAE- Werkzeugen bekannt. Heute gilt die durch den Einsatz offener Datenaustauschformate ermöglichte Interoperabilität, welche die Fähigkeit zur Zusammenarbeit von Software-Systemen umschreibt, als wichtige Voraussetzung für effizientes Engineering: Die Vernetzung der Werkzeuge über offene Schnittstellen offeriert die Möglichkeit eines durchgängigen Engineerings entlang des Engineering- Workflows, gewerke- und unternehmensübergreifend [9]. Als Sprache für Datenaustauschformate hat sich die extensible Markup Language (XML) durchgesetzt [10]. Beispiele für Formate, die in der Prozessautomatisierung eingesetzt werden, sind: BatchML (IEC 61512: Batch Control Part 1: Models and Terminology) CAEX (DIN EN ISO 62424: Darstellung von Aufgaben der Prozessleittechnik Fließbilder und Datenaustausch zwischen EDV-Werkzeugen zur Fließbilderstellung und CAE-Systemen) Degussa PlantXML [11] PandIX (PandIX Spezifikation V. 4.0) PLCopen XML (PLCopen XML TC6) NE 100 (Merkmalleisten zur Erstellung von PLT- Gerätespezifikationen) XMpLant (ISO 15926: Industrial Automation Systems and Integration Oil and Gas Part 1: Overview and Fundamental Principles, 2003/Part 2: Data model) BiLD 1: R&I-Darstellung eines Tanks mit korrespondierender Parametermaske 56
Darüber hinaus existieren weitere XML-basierte Formate, die im PLT-Engineering eingesetzt werden. Hierzu zählen zum Beispiel GSDML oder EDDL [12], die, ähnlich wie FDT XML, für den spezifischen Austausch von Gerätekonfigurationsdaten verwendet werden. Von den genannten Formaten eignen sich ausschließlich CAEX, XMpLant und PandIX für die Modellierung der in der PLT-Planung im R&I-Fließbild projektierten Daten. Insbesondere CAEX diente in den vergangenen Jahren immer wieder als Ausgangspunkt für unterschiedliche Ansätze im Rahmen der Automatisierung der Automatisierung. Beispiele sind die automatische Generierung von Asset Management Funktionen [13] und die automatische Generierung von Verriegelungen [14]. Alle anderen Formate sind entweder durch ihren Modellierungsansatz nicht geeignet (zum Beispiel NE 100 keine Modellierung von Aggregationen oder Assoziationen) oder erweisen sich als proprietäres Format. Das Format PandIX befindet sich derzeit noch im Status einer hochschulinternen Empfehlung. Weil es sich jedoch um einen CAEX-Dialekt handelt, lassen sich die Aussagen zur Anwendbarkeit mit denen von CAEX gleichsetzen. Für die Übertragung aller Planungsaspekte müssen die für die CAE-basierte Modellgenerierung identifizierten Datenaustauschformate eine objektorientierte Modellierung ermöglichen. Dies erfordert die Referenz einer Instanz auf das entsprechende Bibliotheksobjekt und die Zuordnung von Attributen zu deren Objekten. Um der ebenfalls aus der objektorientierten Programmierung stammenden Forderung nach eindeutigen Identifikationen aller Elemente nachzukommen, wird jeder Instanz ein Schlüssel zugewiesen. Hierfür wird oft auf den von Programmierumgebungen erzeugten 128 Bit (16 Bytes) Globally Unique Identifier (GUID) zurückgegriffen. Die Interpretation des Anlagenaufbaus erfolgt durch die Kombination der Assoziationen und Aggregationen. 2. Modellgenerierung In der Modellierung technischer Systeme haben sich zwei Ansätze durchgesetzt [15]: die signalflussbasierte (kausale, explizite) Modellierung und die objektorientierte (a-kausale, implizite) Modellierung Bei der signalflussbasierten Modellierung wird das System in Form eines Blockschaltbildes modelliert. Dabei werden Blöcke, in denen eine Verarbeitung der eingehenden Signalwerte erfolgt, mittels in ihrer Übertragungsrichtung festgelegten Wirklinien verbunden. Dies bedeutet, dass eine Signalschnittstelle explizit als Signalausgang oder -eingang definiert ist. Ein Block ist gekennzeichnet durch die Ermittlung eines (Single Output SO) oder mehrerer (Multiple Output MO) Ausgangssignale in Abhängigkeit eines (Single Input SI) oder mehrerer (Multiple Input MI) Eingangssignale. Aufgrund der gerichteten Wirklinien besteht ein eindeutiger Ursache-Wirkungs-Zusammenhang (kausal). Die Vorteile dieses Modellierungsansatzes liegen in der Darstellung von kausalen Systemen zum Beispiel Regelkreisen. Dementgegen stehen die Nachteile der bei größeren Modellen schnell unübersichtlich werdenden Strukturen. Nachträgliche Änderungen erfordern eine genaue Kenntnis aller mathematischen Zusammenhänge sowie den Zugang zu den realisierten Subsystemen. Die aufgrund ihrer Fokussierung auf physikalische Objekte auch als physikalische Modellierung bezeichnete objektorientierte Modellierung kennzeichnet sich durch ihre a-kausale Schnittstellendefinition. Hierbei wird nicht zwischen Ein- und Ausgang unterschieden. Im Gegensatz zum signalflussbasierten Ansatz kommt den Schnittstellen eine multiple physikalische Bedeutung zu. So entspricht eine Verbindung am Beispiel verfahrenstechnischer Anlagen etwa einem Stutzen (Materialfluss), einer Kabelklemme (Signalfluss) oder einer beheizten Fläche (Energiefluss). Die übertragenen Variablen lassen sich aufteilen in: Flussgrößen, die unter Beachtung ihres Vorzeichens addiert werden: Am Beispiel verfahrenstechnischer Anlagen können so der Massen- und/oder Wärmestrom (falls modelliert) in Rohrsegmenten benannt werden. Potenzialgrößen, die an den Verbindungspunkten gleichgesetzt werden: Am Beispiel verfahrenstechnischer Anlagen, insbesondere Druck und Temperatur. Energieflüsse entstehen durch Potenzialunterschiede zum Beispiel stellt sich der Wärmefluss von einem im Rohr fließenden Medium durch die Rohrwandung nur bei geringerer Umgebungstemperatur ein. Des Weiteren beinhaltet die objektorientierte Modellierung wichtige Merkmale der objektorientierten Programmierung. So wird die Klassenbibliothek in Form einer Modellbibliothek umgesetzt. Durch die Instanziierung, Parametrierung und Verbindung der in ihr beinhalteten Modelle entsteht ein Gesamtmodell. Die Datenquelle CAE-System stellt in Verbindung mit einem offenen Datenaustauschformat eine Möglichkeit für ein durchgehend objektorientiertes Konzept dar. Den Anlagenelementen sind geometrische (beispielsweise Höhe, Durchmesser) und physikalische (zum Beispiel KV-Wert) Parameter zugewiesen. Von den erläuterten Modellierungsansätzen kann aufgrund der bestehenden Merkmalsüberschneidungen die objektorientierte Modellierung eingesetzt werden. 2.1 Modellierungssprache und Zielsystem Um die geforderte objektorientierte Struktur zu gewährleisten, wird die Modellierungssprache Modelica angewendet. Modelica wurde 1996 als Weiterführung der gleichungsbasierten Sprachen ObjectMath und Mathematica entwickelt. Die deklarative gleichungsbasierte Sprache eignet sich für die gleichzeitige Modellierung mehrerer physikalischer Effekte [16], wie sie in verfahrenstechnischen Anlagen auftreten (wie Drücke, Temperaturen, Materialfluss). Als Simulationsumgebung wird stellvertretend die Umsetzung mit dem am häufigsten eingesetzten Werkzeug Dymola erläutert. Modelica bietet die Möglichkeit einer Modellierung in Form von gewöhnlichen Differenzialgleichungen (ODE), differenzial algebraischen Gleichungen (DAE) sowie Bedingungs-Operatoren (zum Beispiel 57
HauPTbeitrag Wenn-Dann ) für die hybride Modellierung. Weitere für die Umsetzung relevante Aspekte von Modelica sind: Direkte Integration von externen Funktionen Der Zugriff auf außerhalb von Modelica implementierte Funktionen ermöglicht die Kommunikation mit beispielsweise OPC-Servern oder Feldbuskarten. Geringer Abstraktionsgrad bei der Modellierung und Parametrierung Die Übernahme von Parametern aus der Datenquelle CAE-System (zum Beispiel Tankdurchmesser) wird damit unmittelbar möglich. Die textbasierte Modellierung gestattet die externe Manipulation. Der Modellgeneratoralgorithmus kann ASCII- Zeichenfolgen ausgeben. Der Aufbau eines Modelica-Modells gliedert sich in diese Bereiche: Objektinstanziierung (Bildung von Instanzen der Bibliotheksobjekte zum Beispiel Tank) Gleichungen/Schnittstellen (Verbindung der Instanzen untereinander beispielsweise Tank mit Rohrleitung verbinden) Funktions- beziehungsweise Algorithmen-Implementierung (Aufruf von externen Funktionen zum Beispiel Initialisierung der OPC-Übertragung) Die Anwendung dieser drei Bereiche wird im Folgenden erläutert. 2.2 Automatische Modellgenerierung Bild 2 stellt in schematischer Form die Arbeitsweise des implementierten Modellgenerators dar. Zunächst werden die Daten aus dem CAE-System in ein Datenaustauschformat (hier: CAEX) überführt und für die Generierung des Simulationsmodells in Modelica-Syntax verwendet. Hierfür werden, ähnlich der objektorientierten Programmierung, Bibliotheksmodelle (zum Beispiel OpenTank) instanziiert. Der Instanz werden anschließend der Name sowie die Parameter des korrespondierenden CAE-Planungsobjektes übergeben. Die für die Generierung des Simulationsmodells verwendeten Bibliotheksmodelle entstammen der Modelica-Fluid-Bibliothek [17]. Diese wurde 2010 als ergänzendes Modul in die Standard-Modellbibliothek der Modelica Association (www.modelica.org) übernommen und steht als Open-Source-Komponente zur Verfügung. Eine detailliertere Beschreibung der in der Modelica-Fluid-Bibliothek umgesetzten Modellierungstiefe findet sich unter [18]. Eine vollständige Generierung des Simulationsmodells erfordert zusätzlich die Definition der Verbindungen zwischen den Simulationsmodellen. Dies ist in Bild 3 beispielhaft für das Ventil Y204 dargestellt, welches an den Behälter B990 angeschlossen wird. 2.3 Visualisierung und Kommunikation Die eingangs als Anforderung (d) definierte Visualisierung der Simulationsmodelle in Form eines Simulations- Fließbildes wird vom Modellgenerator durch die Ergänzung der Modelica-Syntax um Modelica annotation tags umgesetzt. Dies erlaubt die Positionierung von HTML-Elementen für die instanziierten Elemente mit XY-Koordinaten und einer an die Fließbilddarstellung angepassten Skalierung, zum Beispiel: annotation(documentation (info= <HTML><IMG /></HTML> ), Placement(Transformation (x=80, y=20, scale=0.1)). Bild 4 zeigt hierzu ein automatisch generiertes Simulationsmodell, nachdem es in Dymola eingeladen wurde. Alle Objekte wurden dabei automatisch, entsprechend der Anordnung im R&I-Fließbild, platziert. Letzteres lässt sich optional durch den Modellgenerator als Hintergrundbild einbinden. Hierdurch ist es möglich, das generierte Simulationsmodell mit den Planungsdaten zu vergleichen. Weiterer Vorteil: Das Vertrauen der Ingenieure in die Korrektheit des generierten Modells steigt damit. Ein ebenfalls wichtiger Aspekt, welcher aus der Generierung der Visualisierung hervorgeht, ist die Interaktionsmöglichkeit während des Testens. So ist es dem Ingenieur möglich, auf Basis der dargestellten Objekte (zum Beispiel Pumpe), online Werte zu setzen, beziehungsweise zu fixieren. Hierdurch können Fehler in der Aktorik (zum Beispiel Verklemmen eines Ventils, Abriss einer Signalleitung, Ausfall einer Pumpe) oder Sensordefekte vorgetäuscht und die Reaktion der Steuerung überprüft werden. Derartige Testszenarien sind insbesondere für Verriegelungen wichtig. Um die automatische Simulationsmodellgenerierung im Sinne der genannten Kriterien zu vervollständigen, bildet die Definition der Kommunikationsperipherie ein zusätzliches Merkmal. Ziel des vorgestellten Ansatzes ist es, den Steuerungscode in kompilierter Form zu testen, wodurch entweder eine Soft-SPS (emuliert Steuerung in Verbindung mit einem OPC-Server) oder die reale Steuerung eingesetzt werden muss. Bei Verwendung einer Soft-SPS wird eine rein virtuelle Testumgebung geschaffen, welche auch als Systemsimulation definiert ist. In Bezug auf die Implementierung von OPC für das Simulationssystem Dymola wurden die für Modelica standardmäßig existierenden Kommunikationstechniken DDE und Named Pipes um einen OPC-Client erweitert, welcher mit den Server-Applikationen gängiger Soft-Steuerungen kommuniziert [19]. Mithilfe der Einbindung externer Funktionen in Modelica ließ sich die in Bild 5 links dargestellte OPC-Bibliothek entwickeln, deren Modelle auf den in Bild 5 rechts als C#-Klasse dargestellten OPC-Client zugreifen. Durch den Einsatz des CAE-Systems als Datenquelle für die automatische Modellgenerierung können die definierten Kriterien (a) bis (d) bereits erfüllt werden. Dies beinhaltet die Instanziierung, Parametrierung und Verschaltung der Simulationsobjekte sowie die Generierung einer visuellen Repräsentation des Modells. Darüber hinaus kann die Initialisierung des OPC-Clients durch das Einlesen von PLCopen XML Dateien automatisiert werden. Hierfür muss die CAE-basierte Generierung des Simulationsmodells um Daten aus der Engineering-Umgebung des Leitsystems angereichert werden. Dies ist im Prototyp bereits umgesetzt, wodurch das bis dahin noch unerfüllte Kriterium (e) durch automatische Kommunikationsinstanziierung erfüllt wird. 58
BiLD 3: Generierung von Verbindungen in Modelica BiLD 2: Modellinstanziierung und Parameterübergabe vom CAE-System zu Modelica BiLD 5: OPC-Bibliothek für Modelica [20] BiLD 4: Automatisch generiertes Simulationsmodell Neben dem Test des Steuerungscodes beinhaltet der FAT zusätzliche Prüfungen der Feldbusadressen sowie weiterer, für die Initialisierung der Kommunikation notwendiger Busparameter (Feldbustyp, Konfigurationsdatei, FB-Knotentyp, FB-Knotenversion, FB-Baudrate, FB- Knoten, FB-Knotenadresse). Diese Testart erfordert eine Hardware-in-the-Loop-Simulation und dadurch die Einbeziehung der realen Steuerung in Kombination mit Teilen der realen Peripherie. Dabei werden die prozessnahen Komponenten (Feldgeräte und Remote IO) weiterhin im Simulationsmodell modelliert. Dies bedeutet, dass der Simulationsrechner eine oder mehrere Remote-IO- Komponente(n) gegenüber der Steuerung emuliert. Dazu wird der Simulationsrechner mit einer Profibus-PCI-Karte ausgerüstet, welche über eine RS482-Verkabelung mit der Steuerung verbunden wird. Bild 6 stellt die für diese Arbeit realisierte HIL-Testkonfiguration in Kombination mit der Simulationsumgebung Dymola dar. Als Steuerung wurde eine reale SPS mit einer Profibus-DP-Schnittstelle eingesetzt. Diese ist mit einer realen Remote-IO-Baugruppe und mit dem Simulationsrechner verbunden. Im Engineering-System der SPS wird der Simulationsrechner als normale Remote-IO-Komponente mit Hilfe einer Gerätespezifikationsdatei (*.gsd) eingebunden. In den Funktionsmustern wird die HIL-Variante durchgehend als Remote-IO-Konfiguration umgesetzt. Dies bedeutet, dass alle im Simulationssystem instanziierten Sensoren und Aktoren zunächst mit einer modellierten Remote-IO kommunizieren, welche alle Werte über Feldbus an die reale Steuerung überträgt beziehungsweise von ihr empfängt. Im Gegensatz zur Systemsimulation mit OPC erfordert die HIL-Simulation deutlich mehr Parameter für die In- 59
HauPTbeitrag itialisierung der Kommunikation. Hierzu zählen Feldbusadressen oder Baudraten. Aus diesem Grund ist die HIL-Variante in Kombination mit den generierten Simulationsmodellen möglich, jedoch nicht im gleichen Maße automatisiert wie die OPC-Variante. ZusaMMenfassung und Ausblick In diesem Beitrag wurde eine Methode zur automatischen Generierung von Simulationsmodellen auf Basis von CAE-Planungsdaten vorgestellt. Hierzu wurden Rohrleitungs- und Instrumentenfließbilder in das neutrale Datenaustauschformat CAEX überführt. Als Modellierungssprache wurde die objektorientierte gleichungsbasierte Modelica-Syntax angewendet. Zusätzlich zur Generierung des physikalischen Modells ließ sich die Parametrierung der Simulationsobjekte sowie die Generierung eines Simulations-HMI erreichen. Sowohl Hardware-in-the-Loop- als auch Systemsimulation mittels OPC-Kommunikation sind möglich. Erste Einsätze wiesen die Tauglichkeit der generierten Simulationsmodelle für folgende Bereiche nach: Tests von Verriegelungen, Tests von Ablaufsteuerungen, Tests der Wirkrichtung von Reglern, Tests von Grenzwerten für Alarme und Meldungen. Dieser Auflistung folgend, werden die generierten Simulationsmodelle im Wesentlichen für funktionale Tests des Steuerungscodes eingesetzt. Dadurch lassen sich frühzeitig Fehler, wie beispielsweise eine falsch gesetzte Übergangsbedingung in einer Ablaufsteuerung beziehungsweise damit verbundene falsch gesetzte Grenzwerte, identifizieren und beheben. Die Anwendung der Simulation bedeutet gleichzeitig eine natürliche Grenze der Testmöglichkeiten: Da die reale Hardware simuliert wird, können Fehler in der Konfiguration der realen Hardware, wie zum Beispiel das falsche Setzen von IP- Adressen, Baud-Raten, Timeouts oder das Vertauschen von Anschlussklemmen am Schaltschrank, nur bedingt oder nicht gefunden werden. Diese Einschränkung wurde in der Zielstellung dieser Arbeit berücksichtigt, indem auf eine Unterstützung der vor und während des FAT stattfindenden funktionalen Tests fokussiert wurde. Einen Site Acceptance Test (SAT) kann das vorgestellte Konzept nicht ersetzen, wohl aber verkürzen. Weitere Entwicklungsstufen sehen die zusätzliche Generierung von Simulationsskripten für die automatische Konfiguration des Simulationslaufes sowie für die Vorabauswahl von Simulationsvariablen für die Testdokumentation vor. Hierbei werden die PLT-Stellen des R&I-Fließbildes ausgewertet, um dem Modellgenerator ausschließlich die für die Prozessleittechnik relevanten Prozessinformationen über von Sensoren erfasste Drücke, Füllstände, Durchflüsse oder Temperaturen zu übergeben. Darauf basierend kann eine Vorabdefinition der entsprechenden Simulationsvariablen erfolgen. ManuSKriPTEingang 06.11.2011 Im Peer-Review-Verfahren begutachtet Referenzen BiLD 6: Hardware-in-the-Loop- Testkonfiguration für Modelica [1] Krause, K.; Frick, A.; Schiefloe, T.: Life Cycle Support mit Simulator. Automatisierungstechnische Praxis 53(9), S. 32-38, 2011. [2] greifeneder, J.; Weber, P.; Barth, M.; Fay, A.: Generierung von Simulationsmodellen auf Basis von PLS-Engineering- Systemen. Automatisierungstechnische Praxis 54(4), S. 34-41, 2012 [3] barth, M.: Automatisch generierte Simulationsmodelle verfahrenstechnischer Anlagen für den Steuerungstest. Dissertation an der Helmut-Schmidt-Universität / Universität der Bundeswehr Hamburg, Institut für Automatisierungstechnik, Fortschritt-Berichte VDI, Reihe 20, 2011 [4] Kufner, A.; Dreiss, P.; Klemm, P.: Fortschritt bei Simulation von Montagemaschinen. Automatisierungstechnische Praxis 53(9), S. 24-31, 2011. [5] rauprich, G.; Haus, C.; Ahrens, W.: PLT-CAE Integration in Gewerke-übergreifendes Engineering und Plant-Maintenance. atp - Automatisierungstechnische Praxis 44(2), S. 50-62, 2002. [6] hoyer, M.: Catalogue based computer aided engineering (CAE) of process models. Dissertation an der University of Glamorgan, erarbeitet an der University of Applied Sciences and Arts Hannover, Faculty of Advanced Technology, 2007 60
Autoren Dr.-Ing. MiKE BARTH (geb. 1981) war von 2008 bis 2011 wissenschaftlicher Mitarbeiter von Prof. Fay an der Helmut-Schmidt-Universität/Universität der Bundeswehr Hamburg. Seit März 2011 ist er Mitarbeiter am ABB AG Forschungszentrum. Seine Arbeitsgebiete umfassen das Engineering und die Kollaboration von Automatisierungssystemen. ABB AG Forschungszentrum, Wallstadter Straße 59, D-68526 Ladenburg, Tel. +49 (0) 6203 71 64 61, E-Mail: mike.barth@de.abb.com Prof. Dr.-Ing. ALExanDER FAY (geb. 1970) ist Professor für Automatisierungstechnik an der Fakultät für Maschinenbau der Helmut-Schmidt-Universität/ Universität der Bundeswehr Hamburg. Sein Forschungsschwerpunkt sind Beschreibungmittel, Methoden und Werkzeuge für einen effizienten Entwurf von Automatisierungssystemen. Institut für Automatisierungstechnik, Helmut-Schmidt-Universität/ Universität der Bundeswehr Hamburg, Holstenhofweg 85, D-22043 Hamburg, Tel. +49 (0) 40 65 41 27 19, E-mail: alexander.fay@hsu-hh.de Dr.-Ing. JüRGEn GREiFEneder (geb. 1975) ist seit 2008 Wissenschaftler am ABB Forschungszentrum. Er studierte Technische Kybernetik in Stuttgart und promovierte über formale Antwortzeitanalyse netzbasierter Automatisierungssysteme in Kaiserslautern. Seine wissenschaftlichen Schwerpunkte liegen auf Systemmodellierung und effizientem Engineering. ABB Forschungszentrum Deutschland, Wallstadter Str 59, D-68526 Ladenburg, Tel. +49 (0) 6203 71 62 22, E-Mail: juergen.greifeneder@de.abb.com Dipl.-Phys. PETER WEBER (geb. 1956) ist Principal Scientist am ABB Forschungszentrum. Seine Forschungsschwerpunkte liegen im Bereich Virtuelle Inbetriebnahme und Advanced Engineering Methods. ABB Foschungszentrum Deutschland, Wallstadter Str. 59, D-68526 Ladenburg, Tel. +49 (0) 6203 71 62 74, E-Mail: peter.weber@de.abb.com [7] rodies, H.-J.: Planungswerkzeuge aus Sicht des Anlagenbaus. atp - Automatisierungstechnische Praxis 44(1), S. 40-44, 2002 [8] Schlütter, M.; Schmitz, S.: Automatische Datenübernahme aus dem R&I-Fließbild in CAE-Werkzeuge. Chemie Technik 37(11), S. 18-20, 2008. [9] Fay, A.: Engineering in vernetzten, offenen, durchgängigen Systemen. at Automatisierungstechnik 53(4-5), S. 205-210, 2005. [10] Epple, U.: Austausch von Anlagenplanungsdaten auf der Grundlage von Metamodellen. atp - Automatisierungstechnische Praxis 45(7), S. 61-70, 2003 [11] Anhäuser, F.; Richert, H.; Temmen, H.: Degussa PlantXML integrierter Planungsprozess mit flexiblen Bausteinen. atp - Automatisierungstechnische Praxis 46(10), S. 61-71, 2004. [12] Weidemann, D.; Drath, R.: Einleitung in AutomationML. In: Drath (Hrsg.) Datenaustausch in der Anlagenplanung mit AutomationML Integration von CAEX, PLCopen XML, und COLLADA. S. 26, Springer-Verlag Berlin Heidelberg, 2009. [13] Schmidberger, T.; Fay, A.; Drath, R.; Horch, A.: Von Anlagenstrukturinformationen automatisch zum Asset-Management. atp Automatisierungstechnische Praxis 48(6), S. 54-61, 2006 [14] Schmidberger, T.; Fay, A.; Drath, R.: Automatisiertes Engineering von Prozessleitsystem-Funktionen. atp Automatisierungstechnische Praxis 47(2), S. 46-51, 2005. [15] Breitenecker, F.; Popper, N.: Classification and evaluation of features in advanced simulators. In: Tagungsband MATHMOD 2009-6th Vienna International Conference on Mathematical Modeling, S. 1445-1467. Wien:ArgESIM-Reports 35,,2009. [16] Elmqvist, H.; Mattsson, S.E.; Otter, M.: Modelica A Language for Physical System Modeling, Visualization and Interaction. In: Tagungsband IEEE Symposium on Computer- Aided Control System Design. S. 630-639, 1999 [17] Casella, F.; Otter, M.; Proelss, K.; Richter, C.; Tummescheit, H.: The Modelica Fluid and Media library for modeling of incompressible and compressible thermo-fluid pipe networks. In: Proceedings of the 5th Modelica Conference, S. 631-639, 2006. [18] barth, M.; Fay, A.: Erfahrungen im Umgang mit der Modelica-Fluid-Bibliothek auf dem Gebiet der Prozessautomatisierung. In: Tagungsband "ASIM-Treffen 2010 - Simulation technischer Systeme - Grundlagen und Methoden in Modellbildung und Simulation, S. 60-67, 2010 [19] Wagner, F.; Frey, G.: Hardware-in-the-Loop-Simulation bei kurzfristig zu langsamen Simulations-Modellen. Automation im gesamten Lebenszyklus. In Tagungsband: GMA-Kongress 2007,, S. 151-161, VDI-Berichte, 2007. [20] barth, M.; Fay, A; Wagner F.; Frey, G.: Effizienter Einsatz Simuations-basierter Tests in der Entwicklung automatisierungstechnischer Systeme. In: Tagungsband "Automation 2010", S. 47-50, VDI-Berichte, 2010. 61