Anwendung von Simulatorkopplungen zur Untersuchung hybrider Automatisierungssysteme

Transkript

1 4. GI/GMM/ITG Workshop Multi Nature Systems, Ilmenau, 22. Sept. 2003, S Anwendung von Simulatorkopplungen zur Untersuchung hybrider Automatisierungssysteme Dipl.-Ing. Sven Altmann Fraunhofer-Institut Integrierte Schaltungen, Außenstelle Entwurfsautomatisierung Dresden, Deutschland Kurzfassung Im Beitrag wird eine Variante der Simulatorkopplung vorgestellt, mit der durch die Kombination verschiedener Spezialsimulatoren die Gesamtsystemsimulation eines Automatisierungssystems ermöglicht wird. Diese schliesst die Simulation leittechnischer Komponenten (SPS), der Kommunikation (Feldbus) und des Prozesses (Anlage) ein. Als Simulatoren werden die Siemens Soft-SPS WinAC, der Schaltkreis- und System-Simulator ModelSim und Matlab/Simulink eingesetzt. Ergänzt wird die Toolkombination durch eigene Parametrier- und Analysetools. 1 Motivation Heutige automatisierungstechnische Systeme zeichnen sich durch ihre Komplexität und Heterogenität aus. Mechanische, thermische, elektrische oder chemische Vorgänge stehen miteinander in Wechselwirkung und müssen gemessen, gesteuert und geregelt werden. Dieser Beitrag befaßt sich mit der Modellierung und Simulation hybrider dezentraler Automatisierungssysteme. Hybride Systeme enthalten sowohl kontinuierliche als auch diskrete Subsysteme. In der Regel erfolgt auch die Steuerung kontinuierlicher Prozesse mit diskreter Prozeßleittechnik und komplexer Software verschiedener Hersteller [12]. Der Datenaustausch zwischen den leittechnischen Komponenten und den Sensoren/Aktoren in den räumlich verteilten Systemen wird über serielle Bussysteme, wie z.b. Profibus, CAN oder Interbus, realisiert - Bild 1. Diese Bussysteme werden aufgrund ihrer Positionierung im Feldbereich als Feldbusse bezeichnet [3]. Leittechnik PID Feldbus Prozess Bild 1 Dezentrales Automatisierungssystem [12] Probleme treten durch die räumliche Trennung der Komponenten und die damit verbundene Verteilung der Automatisierungsalgorithmen im System auf. Die Kommunikation der Komponenten über den Feldbus M verändert das Zeit- und Systemverhalten der Auto matisierungsanlage zum Teil erheblich. Die Vorhersage des Anlagenverhaltens wird komplizierter. Mit der wachsenden Komplexität der Automatisierungssysteme wächst auch der Bedarf an wirkungsvoller Projektierungsunterstützung. Eine Möglichkeit der Unterstützung ist die Simulation des verteilten Automatisierungssystems bereits in der Projektierungsphase. Ziel der Simulation ist die erhebliche Verkürzung der Projektierungszeit und die Erhöhung der Entwurfssicherheit, um den hohen Anforderungen an Automatisierungssysteme gerecht zu werden. Kriterien wie Ausfallsicherheit, Verfügbarkeit und Erweiterbarkeit müssen auch bei Anlagenlaufzeiten von mehr als 10 Jahren vom Hersteller garantiert werden. Sicherheitsrelevante Automatisierungsanlagen müssen so konzipiert sein, dass im Betrieb keine Gefahr für Leben und Gesundheit der Bediener besteht. Der Projektant wird durch die Simulation in die Lage versetzt, die Funktion der Anlage vor dem kostenintensiven Feldversuch zu testen und kritische Lastsituationen zu untersuchen. Planungsfehler können erkannt und sofort behoben werden. Am Markt stehen nur wenige Simulatoren für gemischt kontinuierliche und diskrete Modelle zur Verfügung, die einer solchen Aufgabenstellung gerecht werden. Andererseits existieren viele kontinuierliche und diskrete Modelle in speziellen Werkzeugen. Verschiedene SPS-Hersteller bieten komplexe Entwurfswerkzeuge zur Programmierung und Simulation ihrer Steuerungen an [7]. Mit dem seit Jahren etablierten Programmpaket Matlab/Simulink lassen sich kontinuierliche Prozesse modellieren [2]. Feldbusse werden mit Spezialsimulatoren und Modellbibliotheken untersucht [13]. 49

2 Vorhandene Modelle und Werkzeuge können durch eine Simulator-Kopplung kombiniert und gemeinsam simuliert werden. Die gegebene Struktur der Anlage (Bild 1) und die Modelle in den verwendeten Simulatoren sollen dabei weitgehend unverändert in der gewohnten Umgebung vom Projektanten genutzt werden können. Nur so ist eine Akzeptanz der Methode zu erwarten. Um diesem Anspruch gerecht zu werden, wird eine Kopplung über Standardschnittstellen vorgenommen, die von vielen Werkzeugen unterstützt werden. 2 Abbildung der Subsysteme Die Modellierung und Simulation der kontinuierlichen und diskreten Teilsysteme erfolgt mit spezialisierten Werkzeugen. 2.1 Prozessmodellierung Für die Modellierung und Simulation kontinuierlicher Prozesse steht mit Matlab/Simulink ein komfortables Werkzeug zur Verfügung. Die Simulink- Bausteinbibliothek bietet einen umfassenden Fundus an Elementarkomponenten für die Systemmodellierung und ist durch mehrere Toolboxen und eigene Modelle für spezielle Anwendungsfälle erweiterbar. Mit der Simulation in Matlab/Simulink können u.a. Erkenntnisse über den zeitlichen Verlauf von Prozessgrößen gewonnen und Regelkreise abgestimmt werden. Bild 2 zeigt ein Beispiel für eine Prozess-Simulation in Matlab/Simulink. Das Modell beinhaltet die Prozesskomponenten, die Steuerung und das Kommunikationsmodell. 2.2 Simulation Leittechnik Eine führende Stellung in der Prozess-Leittechnik nehmen Speicher Programmierbare Steuerungen (SPS) ein. Verbreitet sind auch numerische Steuerungen und dezentrale Automatisierungscomputer. Für die SPS-Programmierung und die Konfiguration des angeschlossenen Feldbus-Netzwerkes bietet z.b. Siemens die Software-Pakete Step7 und WinAC an. Step7 stellt eine leistungsfähige SPS-Projektierungsumgebung dar, WinAC ist ein SPS-Simulator. Diese s.g. Soft-SPS wird zur Abarbeitung des erstellten SPS-Programmes genutzt und verhält sich nahezu wie eine reale SPS. Die Programmierung der Ablaufsteuerung in der SPS wird mit Sprachen nach IEC vorgenommen (Anweisungsliste AWL, Kontaktplan KOP, Funktionsplan FUP) [5]. Bild 3 zeigt die Bedienoberfläche der Soft-SPS und ein Programmbeispiel in FUP und AWL. Funktionsplan (FUP) #toggle_in #toggle_store Anweisungsliste (AWL) U #toggle_store NOT MCRA = #toggle_store = #toggle MCRD Bild 3 Soft-SPS WinAC Mit diesen Werkzeugen können Steuerungen programmiert und simuliert werden, die in Wechselwirkung mit dem über einen Feldbus angeschlossenen Prozess stehen. Eine Simulation des Prozesses und der Feldbus-Kommunikation ist nicht möglich. XOR #toggle_out = 2.3 Modell Kommunikation Bild 2 Prozess-Simulation mit Matlab Das Modell bildet damit das Automatisierungssystem in seiner Gesamtheit ab. So ist es möglich z.b. die Abtastraten der Sensoren und Messumformer, Zykluszeiten und Reglerparameter abzugleichen. Die Abbildung der Steuerung und der Feldbus- Kommunikation erfolgt mit diesem Modell auf sehr hoher Abstraktionsebene. Detaillierte Erkenntnisse, z.b. über den Speicherinhalt der SPS oder lastabhängige Datenverluste im Bussystem sind nur mit hohem Aufwand zu gewinnen. Zur Modellierung und Simulation von Feldbus- Kommunikationssystemen wird VHDL (VHSIC Hardware Description Language) genutzt. VHDL ist ein weltweit genutzter Standard für den Schaltkreisund Systementwurf [8]. VHDL zeichnet sich durch die Modularität und wählbare Granularität der Modellierung sowie durch verschiedene Möglichkeiten der Zeitbewertung aus. Das Model of Computation basiert auf einem Ereignismechanismus, der eine effektive, von Ereignissen getriebene Berechnungsfolge realisiert. Der benutzte VHDL-Simulator ModelSim [11] stellt ein leistungsfähiges Foreign Language Interface zur Verfügung, das es ermöglicht C- Funktionen zu integrieren. Im betrachteten Automatisierungssystem wird Profibus-DP als Feldbus eingesetzt. Die Profibus- Gerätemodelle werden als Module mit Interface- Beschreibung und generischen Parametern implementiert und in einer Modell-Bibliothek verwaltet. Die 50

3 Profibus-Protokollfunktionen eines Moduls werden als VHDL-Verhaltensbeschreibung implementiert. Grundlage sind hierarchische Automaten, die aus den ISO- / DIN-Standards [6] entnommen bzw. abgeleitet werden - Bild 4. Geräte- Symbol entry init C: dp_bus.da = my_addr Bild 4 Profibus-Gerätemodell Zum Aufbau eines Profibus-Kommunikationsnetzwerkes werden die Geräte-Modelle in einer VHDL-Netzliste miteinander verschalten. Eine komfortable Unterstützung hierfür bietet z.b. das Tool HDL-Designer [10], mit dem Symbole für die Gerätemodelle erstellt und in der Modellbibliothek verwaltet werden können. Der Projektant selektiert mit diesem Werkzeug nur die benötigten Gerätesymbole aus der Bibliothek und konstruiert das Blockdiagramm des DP-Systems grafisch. Die Profibus-Modellierung mit VHDL erlaubt eine schnelle und detaillierte Simulation der Feldbus- Kommunikation. Eine Modellierung der SPS ist mit den VHDL-Sprachkonstrukten ebenfalls möglich. Kontinuierliche Prozess-Modelle sind mit VHDL nur näherungsweise zu beschreiben. Hierzu könnten Werkzeuge eingesetzt werden, die den VHDL-AMS- Standard [4] unterstützen. 2.4 Hardware active idle status update C: gousetoken'event A: tfini := now + ttr C: gostatusupdate 'event C: goactiveidle 'event pass token use token C: gopasstoken 'event Die Simulationsmodelle sollen auch als Hilfsmittel für die Inbetriebnahme von Automatisierungsanlagen eingesetzt werden. Ein Ziel bei der Inbetriebnahme ist es, vorab die komplette Anlage zu simulieren und die simulierten Geräte schrittweise durch reale Geräte zu ersetzen. Die zweite Aufgabe besteht in der Erweiterung bestehender Anlagen mit neuen Geräten. Deren Funktionalität soll erst als Modell im Zusammenspiel mit der realen Anlage getestet werden. Wird eine Kopplung von Software mit Hardware vorgenommen, müssen die Modelle mit der in Echtzeit arbeitenden Hardware synchronisiert werden. Für die Integration der Feldbus-Hardware wurden Profibus-Kommunikationsprozessoren eingebunden, sodass die Modelle direkt an Profibus angeschlossen werden können. Die Anbindung von Prozess-Hardware (Sensoren, Aktoren) wurde exemplarisch mit einer Messwerterfassungskarte von National Instruments durchgeführt. Die Karte steuert eine experimentelle Hardware an. Profibus- Kommunikationsprozessor Bild 5 Hardware Durch die Integration der Hardware im Simulationsmodell können auch Geräte in die Simulation einbezogen werden, für die keine Modelle zur Verfügung stehen. 3 Kopplung Messwerterfassungs- Karte Für die angestrebte Gesamtsystemsimulation muss ein effektives und flexibles Kopplungsprinzip eingesetzt werden, das eine Verbindung der Simulatoren miteinander und mit Hardware ermöglicht Als Basis der Kopplungen wurde daher der etablierte Microsoft- Standard COM/DCOM ((Distributed) Component Object Model) mit unterlagertem TCP/IP ausgewählt. COM/DCOM ist die Basistechnologie für die Standardschnittstelle in der Automatisierungstechnik - für OPC. OPC steht für "OLE for Process Control" und definiert einen Standard für die herstellerunabhängige Vernetzung beliebiger Windows NT-Applikationen auf der Basis von Microsoft's COM/DCOM [1]. OPC wurde von der OPC-Foundation, einem Firmenverbund, speziell für die Anforderungen der Prozess- Automatisierung entwickelt. Die Kommunikation zwischen Automatisierungskomponenten wird ohne speziellen Aufwand wie z.b. durch Treiberentwicklungen oder Integrationsarbeiten realisiert. Bild 6 zeigt die Kommunikationsstruktur mit dem in OPC angewendeten Client-Server-Prinzip. Durch die standardisierte OPC-Schnittstelle können beliebige Applikationen, Protokolle und Geräte miteinander verknüpft werden. Protokoll A OPC Server A OPC Interface Application Client A Netzwerk B OPC Server B COM / DCOM Gerät C OPC Server C OPC Interface Application Client B Bild 6 OPC-Prinzip Inzwischen werden fast alle Geräte bzw. Software mit einer OPC-Server und/oder OPC-Client-Schnittstelle 51

4 ausgeliefert, über die der Datenaustausch mit anderen Komponenten organisiert wird. Der Zugriff eines OPC-Clients auf die Daten eines OPC-Servers erfolgt über sogenannte Server-Tags, denen z.b. von der Prozessperipherie anfallende Daten zugeordnet sind. Dieser Mechanismus funktioniert aufgrund der Basistechnologie DCOM auch netzwerkweit. 3.1 Software -Architektur Bild 7 veranschaulicht eine allgemeine Software- Architektur, die zur effektiven und flexiblen Kopplung von Simulatoren und Hardware entwickelt wurde. Dargestellt sind die funktionalen Schichten innerhalb der Koppelsoftware. Die Schichten sind austauschbar um verschiedene Protokolle zu unterstützen. In der obersten Schicht wird das Timing und die Synchronisation mit dem Koppel-Partner vorgenommen. Es können konservative und optimistische Synchronisationsmechanismen eingesetzt werden. Die Implementation erfolgt als Integration von C-Code im Simulationsmodell über das Application Programming Interface (API) des Simulators bzw. als C-Code, der die API (Firmware) der Hardware nutzt. Die Kommunikation wird anhand eines ausgewählten Kommunikationsprotokolls vollzogen, das in einer weiteren Schicht gekapselt ist. Die Architektur ermöglicht so z.b. auch die Nutzung der COM/DCOM- Technologie, indem in dieser Schicht ein COM/ DCOM- bzw. OPC-Interface implementiert wird. Das Physikalische Protokoll wird in der untersten Schicht abgearbeitet und in der Regel vom Betriebssystem bereitgestellt (z.b. TCP/IP). Simulator API Timing Synchronisation Kommunikationsprotokoll Physikalisches Protokoll Physikalisches Protokoll Kommunikationsprotokoll Synchronisation Timing API Software /Hardware z.b. ModelSim z.b OPC mit COM/DCOM z.b. TCP/IP Bild 7 Architektur Simulatorkopplung 3.2 COM/DCOM-Kopplung Das im vorangegangenen Abschnitt vorgestellte Kopplungsprinzip wird für die Verbindung von ModelSim mit der Soft-SPS, Matlab/Simulink und Hardware eingesetzt - Bild 8. Zur Kopplung des Kommunikationsmodells in ModelSim mit der SPS wird der Siemens-OPC-Server genutzt. Matlab wird über den zugehörigen Matlab Automation Server angebunden, der auf COM basierend Methoden für separate Applikationen bereitstellt. Die Messwerterfassungskarte zum Anschluß der Prozess-Hardware wird ebenfalls über einen OPC-Server in die Simulation integriert. Der OPC-Client für diesen Server kann im Matlab-Prozessmodell oder im ModelSim-Feldbusmodell aufgerufen werden. WinAC SPS-Simulation OPC Server OPC Client Matlab/Simulink Prozess-Simulation Automation Server COM / DCOM Automation Client ModelSim Profibus-Simulation Bild 8 COM/DCOM-Kopplung Hardware Messwerterfassung OPC Server OPC Client 3.3 Kopplung mit Feldbustechnik Die Simulation des Kommunikationssystems wird durch die Kopplung mit realer Feldbustechnik erweitert. Beispielhaft ist ein Siemens-Profibus-Kommunikationsprozessor in das VHDL-Profibus-Modell integriert. Damit wird es möglich, über ein reales Profibus-Segment mit einer angeschlossenen SPS und ggf. weiterer Prozessperipherie zu kommunizieren. Die in Bild 7 gezeigte Architektur ist auch für diese Hardware-Kopplung nutzbar. In die Kommunikationsschicht wurde ein Treiber für den Kommunikationsprozessor eingesetzt. Als physikalisches Protokoll wird jetzt realer Profibus verwendet. Mit dieser Variante der HW-Kopplung können im Feldversuch schrittweise Profibus-Komponenten in Betrieb genommen werden und die korrekte Funktion im Profibus-Netzwerk getestet werden. 4 Gesamtsystemsimulation Die Anwendung der Simulatorkopplung für die Gesamtsystemsimulation wird am Beispiel der Anlage nach Bild 9 illustriert. Dieses verteilte System hat die Aufgabe, eine bestimmte Motor-Drehzahl einzuregeln. Es besteht aus einer Siemens-SPS mit PID-Regler, dem Profibus- Kommunikationsmodell und einem Matlab- Prozessmodell mit angeschlossenem Motor. Die aktuelle Drehzahl des Motors wird im Matlab- Prozessmodell über die Messwerterfassungskarte er- 52

5 mittelt und via Profibus-Modell an die SPS gesendet. Der PID-Regler in der SPS ermittelt einen neuen Stellwert für die Steuerspannung des Motors und ü- berträgt diesen wieder über das Profibus-Modell an das Matlab-Modell zurück. Dort wird der neue Stellwert an den Motor ausgegeben. Die Kopplung der SPS mit ModelSim erfolgt über den Siemens-OPC-Server. Matlab wird über den Matlab Automation Server an ModelSim angeschlossen und die Verbindung zwischen Matlab und dem Motor wird über den National Instruments OPC-Server hergestellt. Die Analyse der Simulationsergebnisse erfolgt mit folgenden Zielstellungen: - Check des Gesamtsystems hinsichtlich Funktionalität, Leistung und Sicherheit, - Verhalten von Teilsystemen in ihrer Wechselwirkung mit der Umgebung, - Bewertung des Anlauf-Verhaltens, - Systemdynamik in zeitkritischen Lastfällen und Fehlersituationen, - Optimierung ausgewählter Betriebsparameter. Es werden z.b. Übertragungszeiten und Telegrammzähler ermittelt, sowie Übertragungsfehler und Pufferüberläufe protokolliert. In Bild 11 ist der Verlauf der Motor-Drehzahl und ein Histogramm der Telegramm-Übertragungszeiten über Profibus für einen Simulationslauf dargestellt. Bild 9 Gesamtsystemsimulation Wahlweise wird über den Kommunikationsprozessor ein reales Profibus-Netz zur Verbindung der SPS mit ModelSim benutzt. Das Kommunikationsnetzwerk besteht dann aus einem realen Profibus-System mit 2 Profibus-Kommunikationsprozessoren und mehreren Profibus-Modellgeräten in ModelSim. Bild 11 Simulationsergebnisse Die Bewertung der Simulation kann auch online mit integrierten Visualisierungstools der verwendeten Simulatoren oder eigenen Applikationen vorgenommen werden. Zur Laufzeit der Simulation werden Diagramme erzeugt, die den zeitlichen Verlauf der Stellund Istwerte von Prozessgrößen zeigen. 5 Simulation Während der Simulation werden von Monitor- Modellkomponenten umfangreiche Log-Daten aufgezeichnet, mit deren Hilfe detaillierte Aussagen über das Verhalten des Kommunikationssystems gewonnen werden können. Dies geschieht in einem Postprocessing-Schritt, in dem die Log-Daten nach wählbaren Kriterien gefiltert, analysiert und visualisiert werden. Zur Parametrierung des Systems und zum Postprocessing wurde das Tool Profibus Fitter & Analyzer entwickelt - Bild 10. Bild 10 Profibus Fitter & Analyzer 6 Zusammenfassung und Ausblick Der im Beitrag vorgestellte Ansatz zur Kopplung von verschiedenen Spezialsimulatoren bietet die Möglichkeit, das Verhalten eines automatisierungstechnischen Gesamtsystems durch Simulation zu validieren. Durch die Nutzung ausgereifter Entwurfswerkzeuge und die umfangreiche Aufzeichnung von Simulationsdaten stehen vielfältige Möglichkeiten zur Verfügung, um das System einer detaillierten Leistungsbewertung zu unterziehen. Die Verbindung der Simulationsumgebung mit realer Prozess-Hardware erlaubt es, die Methode zur simulationsgestützten Inbetriebnahme zu nutzen. Die beschriebene Methode ist auch für die Simulation von Anlagen mit anderen Kommunikationsprotokollen (z.b. CAN, LON, Interbus), Steuerungen und Prozessmodellen geeignet, da die Modelle modular aufgebaut sind und für die Kopplung Standardschnittstellen genutzt werden. Mit einer Detaillierung der Kommunikationsmodelle ist auch eine Busmodellierung mit physikalischen Effekten (z.b. Signallaufzeiten, Übersprechen) möglich. 53

6 7 Literatur [1] Barelmann, D.; Bürger, Ch.; Himstedt, S.; Jamal, R.: OPC in der Praxis VDE Verlag Berlin Offenbach, 1999 [2] Bode, H.: MATLAB in der Regelungstechnik, Analyse linearer Systeme, Teubner, 1998 [3] Bonfig, K. W.: Feldbus-Systeme. 2. aktualisierte und erw. Auflage, expert-verlag, Renningen- Malmsheim, 1995 [4] Christen, E.; Bakalar, K.: VHDL-AMS A Hardware Description Language for Analog and Mixed-Signal Applications. IEEE Transactions on Circuits and Systems II: Analog and Digital Signal Processing. Vol 46, No 10, Oct 1999, pp [5] DIN IEC : Speicherprogrammierbare Steuerungen. Teil 3: Programmiersprachen [6] DIN 19245: PROFIBUS Teil 1: Übertragungstechnik, Buszugriffs- und Übertragungsprotokoll, Dienstschnittstelle zur Anwendungs- Schicht, Management. Beuth-Verlag,Berlin 1991 [7] John, K.-H.; Tiegelkamp, M.: SPS- Programmierung mit IEC , überarbeitete Auflage, Berlin: Springer-Verlag [8] Lehmann, G.; Wunder, B.; Selz, M.: Schaltungsdesign mit VHDL. Francis Verlag, 1994 [9] Mehl, H.: Methoden verteilter Simulation. Vieweg Verlag, Braunschweig, 1994 [10] Mentor Graphics HDL-Designer: [11] Modeltech, ModelSim Reference Manual [12] Polke, M.: Prozeßleittechnik. Oldenbourg Verlag München, 1992 [13] Schwarz, P.; Donath, U.: Simulation-based Performance Analysis of Distributed Systems. 5th Intern. Workshop on Parallel and Distributed Real-Time Systems (WPDRTS 97), Geneva, April 1997, pp