Simulationsgestützte Analyse von Profibus-Konfigurationen. Simulation-based Analysis of Profibus Configurations

Transkript

1 340E&i, ÖVE Verbandszeitschrift Elektrotechnik und Informationstechnik 117(2000)5,340 ff. Simulationsgestützte Analyse von Profibus-Konfigurationen Simulation-based Analysis of Profibus Configurations Sven Altmann 1, Ulrich Donath 2, Luc Hohwiller 3 Zusammenfassung. Vorgestellt wird eine Methode für die Modellierung und Simulation von Automatisierungssystemen. Die Simulation soll die Validation diverser Implementierungen einer Automatisierungseinrichtung unterstützen. Die Methode basiert auf der formalen Beschreibung der Geräte mit VHDL. Die einzelnen Gerätemodelle sind an Blocksymbole geknüpft. Mit einem Blockdiagramm-Editor wird durch Verschaltung der Blocksymbole die reale Struktur der Automatisierungseinrichtung abgebildet. Signalgeneratoren erzeugen prozeßspezifische Lastszenarien. Modellierung, Parametrierung und Validation der Simulationsergebnisse werden an einem Profibus-DP-System demonstriert. Schlüsselwörter: Profibus, Modell, Verhalten, Validation, Reaktionszeit Abstract. A method is presented to model and simulate automation systems. The simulation is aimed at the validation of various implementations of an automation equipment. The method is based on VHDL formal device descriptions. All device models are represented by block symbols. A block diagram editor is used to model the automation equipment in the real structure by combining the block symbols. Signal generators produce specific loads derived from process controlled. Modelling, fitting of parameters and validation of simulation results are demonstrated by a Profibus DP System. Key Words: Profibus, model, behaviour, validation, response time 1. Einführung Die funktionale Spezifikation von Automatisierungseinrichtungen erfolgt im ersten Schritt unabhängig von der Gerätetechnik. Dieser Schritt besteht im besonderen in der Auswahl und Verschaltung von Funktionsblöcken und der simulationsgestützten Validation ihres Zusammenwirkens [2]. Die Spezifik der Bus-Topologie und der seriellen Kommunikation steht dabei nicht im Vordergrund. 1 Dipl.-Ing. SVEN ALTMANN, FhG Institut für Integrierte Schaltungen, Zeunerstr. 38, D Dresden 2 Dr.-Ing. ULRICH DONATH, FhG Institut für Integrierte Schaltungen, Zeunerstr. 38, D Dresden 3 Dipl-Ing. LUC HOHWILLER, Université de Haute-Alsace Mulhouse Laboratoire MAGE, 4, rue des frères Lumière, F Mulhouse Cedex 340

2 Die im folgenden vorgestellte Methode verfolgt das Ziel, den Projektanten bei der Validation verschiedener Implementierungen der Automatisierungseinrichtung zu unterstützen. Basis ist die formale Abbildung der Automatisierungseinrichtung. Bei dieser Abbildung werden zusätzlich, über die o.g. Funktionsblock-Methode hinausgehend, die Struktur der Einrichtung und die Kommunikationsbeziehungen der einzelnen Komponenten via den Bus erfaßt. Funktionen und Kommunikation sind zeitlich parametriert. Die formale Abbildung ist so weit modularisiert und gekapselt, daß die Automatisierungseinrichtung als Blockdiagramm modelliert werden kann. Dieses Blockdiagramm und die formalen Beschreibungen der einzelnen Geräte sind Input eines Simulators. Prozeßspezifische Lastszenarien werden durch Signalgeneratoren erzeugt. Die Methode wird am Beispiel eines Profibus-DP-Systems demonstriert. Für ausgewählte Gerätekomponenten werden funktionale Modelle bereitgestellt, die mit einem Blockdiagramm-Editor zum Gesamtmodell der Automatisierungseinrichtung verknüpft werden. Die Gerätemodelle wurden als Flowcharts und Statecharts definiert und auf VHDL abgebildet. Die Festlegung der Zeitparameter und die Vorgabe charakteristischer Nachrichtenpattern erfolgt dialoggeführt. Die Simulation kann mit jedem kommerziellen VHDL-Simulator ausgeführt werden. Ausgewählte Komponenten protokollieren den Nachrichtentransfer. Ergänzt ist ein Postprocessing, das u.a. die Auslastung der Übertragungskapazität zeigt und die Minima und Maxima von Reaktionszeiten bestimmt. Mit VHDL (VHSIC Hardware Description Language, VHSIC = Very High Speed Integrated Circuit) wird ein weltweit anerkannter Standard genutzt, der den Entwurf digitaler Schaltkreise (Spezifikation, Simulation, Synthese, Dokumentation) unterstützt [5]. Insbesondere die VHDL-Features diskretes Zeitmodell, Ereignisorientierung, quasi parallele Ausführung der Prozeßanweisungen und Modularität sowie die Verfügbarkeit leistungsfähiger Simulatoren initiierten die Anwendung bezüglich der umrissenen Aufgabenstellung [1], [4], [6]. Die Analog-Erweiterung VHDL-AMS (AMS = Analog and Mixed-Signal Extension) [3] wurde 1999 als Standard verabschiedet. Damit können nach Erweiterung der Simulatoren kontinuierliche Prozeßmodelle in die Verhaltensanalyse der Automatisierungseinrichtung bzw. des Gesamtsystems einbezogen werden [7]. 2. Systemmodellierung Für die Modellierung von Profibus-DP-Systemen werden folgende Bausteine bereitgestellt: DP_Master_MAC (DP_Master_Medium_Access_Control) DP_Master_App (DP_Master_Application) DP_Slave_MAC (DP_Slave_Medium_Access_Control) DP_Slave_App (DP_Slave_Application) DP_Bus (Übertragungsmedium) DP_Monitor Requester, Responder. Die Komponenten DP_Master_MAC und DP_Slave_MAC modellieren den Buszugriff nach dem Master-Slave-Prinzip. Die applikationsspezifischen Funktionen der Geräte sind 341

3 Inhalt der Komponenten DP_Master_App und DP_Slave_App. DP_Bus ist eine Verbindung, der eine Funktion zugeordnet ist. Diese Funktion bestimmt aus der Menge aller angeschlossenen Sender den aktiven Sender und wählt dessen Signal als resultierendes Signal. DP_Monitor protokolliert den Nachrichtentransfer. Requester und Responder sind Signalgeneratoren, die verschiedene Lastszenarien erzeugen. Der Requester, mit der Master-Applikation verkoppelt, gibt die Outputs an die Slaves vor. Die mit den Slaves verbundenen Responder bilden die Reaktionen des Prozesses nach. Sie können direkt oder im zeitlich konstanten Abstand oder zufällig mit Exponentialverteilung erfolgen. Parametrierung Blockdiagramm-Editor VHDL-Simulator Postprocessing Abb. 1. Design-Umgebung Die Design-Umgebung (Abb. 1) umfaßt den Blockdiagramm-Editor Renoir Block (Mentor Graphics), den VHDL-Simulator ModelSim (Mentor Graphics) und das Profibus Fitter & Analyzer Tool (Eigenentwicklung) zur Parametrierung des Systems und zum Postprocessing. Die Datenbasis des Blockdiagramm-Editor enthält die Blocksymbole der o.g. Bausteine. Die Symbole sind Abbilder der korrespondierenden VHDL Entities (generische Parameter und Interface-Beschreibung mit Port-Namen, Signalflußrichtungen und Signaltypen). 342

4 Requester DP_Master_App DP_Master_MAC Par_File Telegram DP_Monitor Bus_File SD SA DA FC LE Data DP_Bus DP_Slave_MAC 1 DP_Slave_MAC 2 DP_Slave_MAC 125 DP_Slave_App 1 DP_Slave_App 2 DP_Slave_App 125 Responder 1 Responder 2 Process Responder 125 Abb. 2. Blockdiagramm eines DP-Systems Der Projektant selektiert das benötigte Symbol in der Entwurfsdatenbasis und konstruiert schrittweise das Blockdiagramm des DP_Systems (analog Abb. 2). Häufig verwendete Kombinationen von Komponenten, z.b. von DP_Slave_MAC und DP_Slave_App, können als eigenständiges Blocksymbol ergänzt und zum weiteren Aufbau des Blockdiagramms verwendet werden. Jedes Blocksymbol ist neben der VHDL Entity mit dem VHDL Behavioural Model verknüpft. Alternative Behavioural Models werden mit dem Design Browser selektiert. Zur Simulation wird das Blockdiagramm in eine VHDL-Netzliste übersetzt. Vor der Simulation ist diese Netzliste Input des Fitter & Analyzer Tool mit dem der Projektant dialoggeführt die Geräte- und Prozeßparameter definiert (siehe Abschnitt 4). Ergebnis der Parametrierung sind Parameter-Files, die im Simulationslauf von den instantiierten Gerätemodellen ausgewertet werden. Die Simulation wird aus dem Main-Menü des Blockdiagramm-Editor per Knopfdruck gestartet. 3. Gerätemodellierung Die Modelle der einzelnen Geräte bzw. Gerätebausteine sind ein oder mehrere parallele Prozesse, die zunächst mit Flowcharts oder Statecharts definiert werden. Als Beispiel wird das Master-MAC-Modell betrachtet (Abb. 3). Dieses Modell ist in die Prozesse "request execution", "poll data exchange" und "protocol actions" gegliedert. "request execution" wird ausschließlich durch Requests aktiviert, die von der Master- Applikation ausgelöst werden. Entsprechend der Write- oder Read-Forderung wird ent- 343

5 weder ein Element des Ausgangsdatenfeldes geschrieben oder ein Element des Eingangsdatenfeldes gelesen. "poll data exchange" wird periodisch aktiviert; kopiert das Ausgangsdatenfeld in die Poll-Liste und liest die Eingangsdaten aus der Poll-Liste. Der unmittelbare Datenaustausch mit den Slaves wird im Prozeß "protocol actions" beschrieben. DP Master MAC resp conf requ init protocol actions C: go_use_token event A: tfini := now + ttr ; request execution C: dp_bus.da = my_addr status update use token poll data exchange C: go_status_update event protocol actions active idle C: go_active_idle event pass token C: go_pass_token event dp_bus Abb. 3. Modellstruktur der Komponente DP_Master_MAC "protocol actions" ist ein asynchroner hierarchischer Automat, der die Zustände "init", "status update", "use token", "pass token" und "active idle" unterscheidet, wobei "status update", "use token" und "pass token" durch untergeordnete Automaten detailliert sind. Die Zustandsübergänge sind ereignisgetriggert. Die Ereignisse sind entweder Änderungen interner Signale oder des Busses. Im Zustand "use token" werden die Slaves in der Reihenfolge der Poll-Liste abgefragt. Der Master wartet eine vorgegebene Zeit Tslot auf die Slave-Antwort und setzt nach Empfang dieser Antwort oder nach dem Ablauf der Wartezeit Tslot die Bearbeitung der Poll-Liste fort. Im Automaten wird die Idle-Zeit des Busses und die Übertragungszeit des Telegramms berechnet. Nach Ablauf dieser Zeiten wird das Telegramm als Einheit (Record) auf die Verbindung DP_Bus geschrieben. DP_Bus überträgt das Telegramm mit Null-Verzögerung an alle angeschlossenen Slaves. Die Flowcharts oder Statecharts werden in separate VHDL-Prozesse übersetzt. Hervorzuheben ist die Abbildung des Zeitfortschritts mittels Timer und Wait-Anweisungen. Jeder Timer ist ein Toggle Switch, der durch eine Anweisung der Form send_timeout <= NOT send_timeout After tsend; gestellt wird. Die korrespondierende Wait-Anweisung Wait On send_timeout; suspendiert den Prozeß bis zum Toggle Event. 4. Parametrierung Das Profibus Fitter & Analyzer Tool ist eine Windows-Applikation zur Parametrierung der Modelle und zum Postprocessing der Simulationsergebnisse von Profibus-DP- Systemen. Mit diesem Werkzeug wird der Projektant bei der Einstellung der Vielzahl der 344

6 Parameter und der schnellen Aufbereitung der Simulationsergebnisse wirksam unterstützt. Mit dem Profibus Fitter (Abb. 4) definiert der Projektant dialoggeführt die kommunikationsspezifischen Geräte- und Prozeßparameter, die in Files abgelegt werden. Außerdem kann das Tool existierende Parameter-Files einlesen und, konsistent zur entsprechenden VHDL-Netzliste, neue Files erzeugen. Dem Projektanten werden die Master- und Slave- Parameter mit aufsteigender Adresse angeboten. Für die selektierte Station wird der komplette Parametersatz angezeigt. Falls vorhanden, werden die Parameter des angekoppelten Responder oder Requester ergänzt. Abb. 4. Parametrier-Windows des Profibus Fitter & Analyzer Tool Für den Master werden u.a. Target Rotation Time (TTR), Slot Time (TSlot) und Idle Time (TId1) definiert. Station Delay Responder (TSDR), Sample/Update Periods, In/Output Delays, Datenlänge und Initial-Daten sind verfügbare Slave-Parameter. Die Poll-Reihenfolge kann zufällig, aufsteigend sortiert oder nutzerdefiniert festgelegt werden. Die Parametersätze der Slaves sind untereinander kopierbar. Interne Check- Routinen verhindern typische Parametrierfehler wie doppelte oder falsche Adreßvergabe und ungültige Einträge in die Poll-Liste. 5. Validation Während der Simulation wird die Daten- bzw. Nachrichtenübertragung von mehreren Komponenten protokolliert. DP_Monitor protokolliert die Telegramme auf dem Bus, deren Dauer und Abstände. DP_Master_Application zeichnet die gesendeten Requests und empfangenen Responses auf und umgekehrt registrieren die instantiierten Komponenten DP_Slave_Application die empfangenen Requests und gesendeten Responses. Das Postprocessing Tool analysiert im Anschluß an die Simulation die erzeugten Protokolle und bestimmt globale und stationsspezifische Kenngrößen. 345

7 Anhand des DP_Monitor-Protokolls werden die Bus-Auslastung, die Bus-Idle-Zeit und unbeantwortete Status-Abfragen ermittelt. Für jede Station werden die gesendeten Telegramme gezählt und die mittlere Telegrammlänge berechnet. Dabei wird zwischen den verschiedenen Telegrammtypen unterschieden. Diese Ergebnisse werden auch für das Gesamtsystem durch Summierung über alle Stationen angegeben und vom Tool grafisch dargestellt. Für einzelne Übertragungen werden aus den Stationsprotokollen Reaktionszeiten wie Bus-Zugriffszeit, Antwortzeit und Zykluszeit bestimmt. Das Tool berechnet für alle Übertragungen des Masters zu einem selektierten Slave die Mittelwerte sowie die Minima und Maxima dieser Reaktionszeiten. Die Ergebnisse werden vom Tool grafisch dargestellt (Abb. 1) und als Liste in ASCII-Files ausgegeben. Diese Files können mit Microsoft Excel bearbeitet werden. Zeit [sec] Req2MAC Req2Bus MAC2Bus Bus2Resp Req2Resp Req2Rec Abb. 5. Reaktionszeiten im DP-System Das Excel-Diagramm (Abb. 5) zeigt die aufgenommenen Reaktionszeiten für die Master- Slave-Master-Übertragungen für einen selektierten Slave. Ermittelt wurden u.a. die Verweilzeiten des Telegramms im Master (Req2Bus), der Zeitraum der Übertragung über den Bus bis zum Update des Slave-Output (Bus2Resp) und die Gesamtzykluszeit vom Erzeugen des Telegramms bis zum Empfang der Antwort in der Master-Applikation (Req2Rec). Zur Ermittlung dieser Reaktionszeiten wurden die Data Units der Telegramme vom Requester mit verschiedenen Pattern belegt. Die Funktion des an den Slave angeschlossenen Responder beschränkte sich bei diesen Untersuchungen auf die Rückgabe der empfangenen Pattern. 6. Fazit Die Design-Umgebung für Profibus-DP-Systeme besitzt den Charakter eines Prototyps. Erste Tests zeigen, daß der Projektant effektiv bei der Validation von diversen Implementierungen einer Automatisierungseinrichtung unterstützt werden kann. Die Aufwendungen liegen hauptsächlich in der grafischen Konstruktion des Systemmodells 346

8 und dessen Parametrierung. Zum Aufbau des Systemmodells stehen dem Projektanten grafische Bausteine zur Verfügung, an die vorgefertigte Gerätemodelle gekoppelt sind, so daß keine Kenntnis der formalen VHDL-Beschreibung erforderlich ist. Die Einstellungen der Modellparameter erfolgen mit Tool-Unterstützung. Die Simulationspattern werden ebenfalls mit Tool-Unterstützung definiert. Erste Untersuchungen können mit zufälligen Patternfolgen ausgeführt werden. Zur Untersuchung kritischer Lastfälle obliegt es dem Projektanten, die Patternfolge als Trace zu definieren, wobei der zeitliche Abstand und die Daten festgelegt werden. Die Effizienz der Simulation zeigt die Rechenzeit der oben angeführten Reaktionszeitmessungen (Abb. 5) eines DP-Systems. In diesem System organisiert der Master den Datenaustausch mit 10 Slaves. Außerdem erfolgt vom Master die Statusabfrage von weiteren 10 optionalen Slaves. Für den Nachrichtentransfer wurde eine Bit Rate = 1.5 MBit/s vorgegeben. Für die Systemsimulation von 10 sec Echtzeit benötigt der Simulator 56 sec Wallclock (PC mit AMD K MHz CPU und ModelSim 5.2 EE). In dieser Zeit wurden Telegramme übertragen und protokolliert. Der Zeitbedarf für das Postprocessing liegt bei diesem Beispiel im Sekundenbereich. Untersuchungen der geschilderten Art wurden bisher auf Systeme mit 60 Slaves ausgedehnt. Die weiteren Arbeiten zielen auf die Simulation und Validation realer Profibus- Applikationen. Schrifttum [1] ALTMANN, S.; DONATH, U.: Methodical Aspects of VHDL-based Field Bus Modelling with a Controller Area Network. SIG-VHDL Spring 96 Working Conference, Dresden, 1996, pp [2] BROWNLIE, I. et al: ACORN Design Tools for Fieldbus. Feldbustechnik in Forschung, Entwicklung und Anwendung. Beiträge zur FeT 97, Springer Wien, 1997, S [3] 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 [4] HALE, K.: Automotive Databus Simulation using VHDL. Proc. Euro-DAC 94, Grenoble,1994, pp [5] LEHMANN, G.; WUNDER, B.; SELZ, M.: Schaltungsdesign mit VHDL. Franzis- Verlag, Poing, 1994 [6] SCHOEN, J.M. (Ed): Performance and Fault Modeling with VHDL. Prentice-Hall, Englewood Cliffs, 1992 [7] 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