Lehrstuhl für Informatik 10 (Systemsimulation)

Transkript

1 FRIEDRICH-ALEXANDER-UNIVERSITÄT ERLANGEN-NÜRNBERG TECHNISCHE FAKULTÄT - DEPARTMENT INFORMATIK Lehrstuhl für Informatik 10 (Systemsimulation) Konzeption und Realisierung einer exiblen Datenübernahme von Realdaten aus Automatisierungssystemen in ein Simulationssystem (Branche Schibau) Jens Friedemann Diplomarbeit

2 Konzeption und Realisierung einer exiblen Datenübernahme von Realdaten aus Automatisierungssystemen in ein Simulationssystem (Branche Schibau) Jens Friedemann Diplomarbeit Aufgabensteller: Betreuer: Prof. Dr. Ulrich Rüde Dipl. Ing. Torsten Dreher Bearbeitungszeitraum:

3 Kurzfassung Das Ziel dieser Diplomarbeit war die Entwicklung eines Konzepts, mit dem Daten aus dem Automatisierungssystem einer realen Anlage - speziell einem Schiff - ausgelesen und in eine Simulation dergestalt eingefügt werden können, dass diese in ihren Zuständen und Parametrierungen dem Realsystem gleicht. Sowohl das Realsystem als auch das Trainingssystem sollen dabei mit der gleichen Automatisierungssoftware bestückt sein. Der Unterschied zwischen den beiden Systemen besteht im Wesentlichen darin, dass die Anlagen des Schiffes im Trainingssystem durch die Prozesssimulations-Software SIMIT ersetzt werden. Für das Konzept galten dabei die Anforderungen, dass die Automatisierungs-Software (PCS-7) so wenig wie möglich verändert werden sollte und das der gelesene Datensatz konsistent ist. Die Realisierung auf Seiten von PCS-7 gelang über einen FC-Baustein, der die Daten der Komponenten (z.b. einem Antrieb oder einem Ventil) in Typical-spezifische Schatten- Datenbausteine kopiert. Für einen Lese- bzw. Schreibvorgang kann diese Aktualisierung über einen Handler-DB unterbrochen werden. Das Auslesen wird mit dem frei konfigurierbaren Programm S7-Real2Sim realisiert. Der Zugriff auf die Daten der speicherprogrammierbaren Steuerungen erfolgt dabei via OPC (Ole for Process Control). Nach einem erfolgreichem Lesezugriff können die Daten exportiert und im Trainingssystem wieder importiert werden. Hier übernimmt das Programm die Aufgabe des Mappings. Durch speziell entworfene Zuweisungsmethoden können die importierten Daten in die Snapshotdatei von SIMIT geschrieben werden. Die Übernahme dieser Werte erfolgt beim Starten der Simulation durch ein spezielles Signal. Sobald dieses Signal True ist, werden durch das zyklische Verhalten der SIMIT Typicals die neuen Zustände übernommen. Es ist dabei darauf zu achten, dass auch von den Typicals abhängige Größen der Simulation (z.b. Drücke oder Temperaturen) entsprechend nachgeführt werden müssen. Durch das Schreiben des gelesenen Datensatzes auf die SoftPLCs können Fehler in Folge der Datenkopplung über den Shared Memory umgangen und die Parametrierung des HMI übernommen werden. Je nach Komplexität der Prozessmodelle ist es möglich die Simulation als ein hinreichend genaues Abbild des realen Systems zu initialisieren.

4 Abstract The aim of thesis was to develop a concept to read the data of an automation system, especialy of a ship, and import this data into a simulation in a manner, so that this simulation can be started with the same states, values and parameters. Both the real system and the trainings system shall be provided with the same automation software. The main difference between these two systems exists by simulating the ship with it s components by the simulation software SIMIT in the trainings system. The concept has to be developed in a way, where the automation software is altered as slightly as possible and the dataset has to be consistent. The implementation in PCS-7 was achieved by an FC-block which copies the data of each element into typical-specific Shadow-DBs. This update can be paused by a Handler-DB. The reading of the dataset is realized within the program S7-Real2Sim which can be freely configured. The data access takes place by OPC (Ole for Process Control). After a successful reading operation the data can be exported into a configuration file and lateron reimported to manipulate the values of the simulation. For this manipulation the program provides various methods to assign the values into the snapshot file. The takeover process in SIMIT is triggered by a specific signal. As soon as this signal turns true the cyclic behaviours of the SIMIT typicals take over the new values. It has to be remembered that the model of the simulation can also consist of values which are depending on these typicals (e.g. pressures or temperatures). These values have to be adopted accordingly. Due to the writing of the dataset directly to the SoftPLCs, the states and parameters of the HMI can also be initialized and failures owing to the data-coupling by the Shared- Memory avoided. Depending on the complexity of the simulation models, it is possible to initialize the simulation as an sufficient reflection of the real system.

5 Eidesstattliche Erklärung Eidesstattliche Erklärung Ich versichere, dass ich die Arbeit ohne fremde Hilfe und ohne Benutzung anderer als der angegebenen Quellen angefertigt habe und dass die Arbeit in gleicher oder ähnlicher Form noch keiner anderen Prüfungsbehörde vorgelegen hat und von dieser als Teil einer Prüfungsleistung angenommen wurde. Alle Ausführungen, die wörtlich oder sinngemäß übernommen wurden, sind als solche gekennzeichnet. Erlangen, den 26. Juni 2013 Jens Friedemann I

6 Abkürzungsverzeichnis Abkürzungsverzeichnis AS AWL BUB CFC CP CPU DP EK ES FB FBS FC GPL GUI HMI KOP LBTS LGPL LSB MPI MVC OBTS OPC OS PC PLC PLS PNK PS SCL SFC SPS ST UDT URL VM Ablaufsprache Anweisungsliste Bedien- und Beobachtungsstation Continuous Function Chart Communication Processor Central Processing Unit Dezentrale Peripherie Engineering Komponente Engineering Station Funktionsblöcke Funktionsbausteinsprache Funktionsbausteine General Purpose License Grpahical User Interface Human Machine Interface Kontaktplan Land Based Training Systems Lesser General Public License Least Significant Bit Multi Point Interface Model View Controller On Board Training Systems OLE for Process Control Operator Station Personal Computer Programmable Logic Controller Prozessleitsysteme Prozessnahe Komponente Power Supply Structured Control Language Sequential Function Chart Speicherprogrammierbare Steuerung Strukturierter Text User Defined Type Uniform Resource Locator Virtual Machine II

7 Abkürzungsverzeichnis WPF XML Windows Presentation Foundation Extensible Markup Language III

8 Abbildungsverzeichnis Abbildungsverzeichnis 2.1 Die modularen Steuerungen der SIMATIC S7 Reihe als Beispiele für eine SPS [7] Prinzipielle Darstellung des permanent-zyklischen Programmablaufs [20] Strukturelle Aufteilung eines Prozessleitsysteme (PLS) Beispiel eines CFC-Plans Ansicht des Unterprogramms HW-Config für die Hardwarekonfiguration Beispiel für die Ansicht des Unterprogramms NetPRO in dem die Verbindungen zwischen den einzelnen Stationen projektiert werden Die Oberfläche des Prozessvisualisierungsprogrammss WinCC am Beispiel eines Heeling-Systems Beispiel für ein Faceplate, hier für einen Motor 2D1V Beispielhafte Abbildung für ein SIMIT Modell Fenster für eine SoftPLC der Eumlationsplattform SchEmu Grundlegende Strukur des OPC DA Protokolls [6] Adressierung der PLCs über die eindeutigen Namen der S7-Verbindungen Beispiel für ein Typical MAS_DRV_2D2V (Motor mit zwei Richtungen und zwei Geschwindigkeiten) [10] Der vereinfachte Aufbau eines Prozessleitsystems an Bord eines Schiffes [2][4][1] Der unterschiedliche Aufbau eines realen Systems (links) und einer Trainingsanlage (rechts) Grundlegender Aufbau des Testsystems Prinzip des Datenaustauschs zwischen der Simulation und der SoftPLC s über den Shared Memory Manipulation eines Snapshots durch Änderung der Daten in der Snapshotdatei (SIMIT) und den SoftPLC s Prinzipielle Darstellung der Realisierung der Datenübernahme im Programm S7-Real2Sim[9][8] Adressierung der Variablen über die Eigenschaft ItemName Messergebnisse der Messungen der Zugriffszeiten für verschiedene Zugriffsmethoden und Datengrößen. Dargestellt sind dabei die Mittelwerte mit ihrer dazugehörigen Standardabweichung Erweiterung des bestehenden PCS-7 Projekts für die Datenübernahme (Lesen aus dem Realsystem) IV

9 Abbildungsverzeichnis 5.4 Beispiel für die Definition einer UDT (Typical: MAS_BIN_STD) Aufbau eins Schatten-DBs am Beispiel des Typicals MAS_BIN_STD Beispiel für die Definition eines SpecialDBs Beispiel für einen eingebundenen R2S_FC_PROG in einem PCS-7 Typical Ablaufdiagramm für die Werte des R2S_DB_PROG_HANDLER im Falle eines Lesezugriffs Das Initialisieren des Snapshots stellt den ersten Schritt der Datenübernahme auf einem Trainingssystem dar Beispiel für das Mapping innerhalb von SIMIT (Typical: Val1D) Beispiel für das Übernehmen der neuen Zustände durch das zyklische Verhalten des Typicals (Typical: Val1D) Beispiel für ein Prozessmodell, dargestellt ist ein Teil eines Kühlsystems für Dieselmotoren Beispiel für das Anbinden des SIMIT_start_Impuls Signals an ein Integrierer bzw. PT-n Glied Das Übertragen der Daten auf die SoftPLCs dient der Anpassung der Parametrierung der Typical-Instanzen Erweiterung des bestehenden PCS-7 Projekts für die Datenübernahme (Schreiben auf die SoftPLCs) Ablaufdiagramm für die Werte des R2S_DB_PROG_HANDLER im Falle eines Schreibzugriffs Der CFC-Plan R2S_HANDLER_PCUn Das Programm S7-Real2Sim Das Konzept der MVC-Struktur. Durchgezogene Linien entsprechen dabei einer direkten, gestrichelte einer indirekten Assoziation Umsetzung der Model View Controller (MVC)-Struktur im Programm S7- Real2Sim Anbindung der Kommandos über die Datenbindung von WPF Einbindung der UserControls in das Hauptfenster MainWindow(Rot: Top- MenuControl.xaml, Grün: ReadFromPLCControl.xaml, CreateConfigControl.xaml, WriteToSnapshotControl.xaml, Blau: StatusBarControl.xaml CreateConfigControl.xaml, b) ReadFromPLCControl.xaml, c) WriteToSnapshotControl.xaml Strukturierung der Datenhaltung für die gelesenen Datensenken Ablaufdiagramm für die Werte des R2S_DB_PROG_HANDLER im Falle eines Lesezugriffs Lesen eines bool schen Werts über ein Byte Struktur des Datentyps String Berechnung eines Wertes vom Datentyp Time_Of_Day V

10 Abbildungsverzeichnis 6.12 Berechnung eines Wertes vom Datentyp S5Time Das UserControl WriteToSnapShotControl mit dem die Daten in das Trainingssystem übernommen werden können Ablaufdiagramm für das Lösen geklammerter Ausdrücke Ablaufdiagramm für die Werte des R2S_DB_PROG_HANDLER im Falle eines Schreibzugriffs Das UserControl CreateConfigControl zum Erstellen und Editieren der Konfigurationsdatei HMI-Oberfläche der getesteten Prozesssimulation Fehler durch die vereinfachte Übernahme der Betriebszustände von Motoren 86 VI

11 Tabellenverzeichnis Tabellenverzeichnis 2.1 Die grundlegenden Bausteine der Programmierung von speicherprogrammierbaren Steuerungen OPC Spezifikationen [18] Datentypen einer SIMATIC S Parameter und ihre Bedeutung der Funktion daveconnection.readbytes() Mittelwerte in Sekunden für das Lesen von Daten unterschiedlicher Größe unter Verwendung von Libnodave Mittelwerte in Sekunden für das Lesen von Daten unterschiedlicher Größe unter Verwendung von AcconAGLink Mittelwerte in Sekunden für das Lesen von Daten unterschiedlicher Größe unter Verwendung von OPC DA Aufbau der UDT R2S_UDT_TYPE_HEADER Aufbau des UDT R2S_DB_PROG_HANDLER Die Grundfunktionen für das Mapping in eine Snapshotdatei Mappingfunktionen für die Manipulation typicalunabhängiger Daten Zustände und die entsprechenden Anschlüsse eines Typicals am Beispiel für ein MAS_VAL_1D Wechselbare UserControls für das Programm S7-Real2Sim Übersicht über die Grundknoten der XML-Konfigurationsdatei Attribute des Knotens WinCC_Connection Werte für den Betriebszustand einer PLC (CPUState) Attribute des Knoten RegisterTakeOverDB (siehe auch Kapitel ) Attribute des Knoten RegisterDBType Attribute für einen Knoten vom Typ DBType Attribute für einen Knoten vom Typ DBItem Gültige Datentypen für ein DBItem Verfügbare Operatoren Attribute der Mappingfunktion Assignment Attribute der Mappingfunktion Assignment.Log Attribute der Mappingfunktion Assignment.Log.Set Attribute der Mappingfunktion Assignment.Log.Calculate Attribute der Mappingfunktion Set Attribute der Mappingfunktion Set.Log Attribute der Mappingfunktion Set.Calculate VII

12 Tabellenverzeichnis 6.18 Serverobjekte vom Typ Opc.Da.Server Methoden der Klasse OPCLib für den Lese- bzw. Schreibzugriff Benötigte Headerinformationen der Schatten-DBs Zeitraster des Datentyps S5Time Attribute der XML-Knoten vom Typ S7Connection als Unterknoten von ReadData Attribute der XML-Knoten vom Typ DB (ReadData) Attribute der XML-Knoten vom Typ Instance (ReadData) Attribute der XML-Knoten vom Typ DB_Item (ReadData) Properties der Klasse SnapshotItem Parameter für das Starten via Kommandozeilenargumente A.1 Messwerte für das Lesen von Daten unterschiedlicher Größe unter Verwendung von Libnodave ii A.2 Messwerte für das Lesen von Daten unterschiedlicher Größe unter Verwendung von AcconAGLink iii A.3 Messwerte für das Lesen von Daten unterschiedlicher Größe unter Verwendung von OPC DA iv A.4 Für die Datenübernahme verwendbare Typicals v VIII

13 Inhaltsverzeichnis Inhaltsverzeichnis Eidesstattliche Erklärung Abkürzungsverzeichnis Abbildungsverzeichnis Tabellenverzeichnis I II IV VII 1 Einleitung 1 2 Grundlagen der Automatisierungstechnik Speicherprogrammierbare Steuerungen Prozessleitsysteme Verwendete Software Prozessleitsystem PCS Prozessvisualisierungsprogramm WinCC Prozesssimulationsprogramm SIMIT Emulationsplattform SchEmu OLE for Process Control (OPC) Grundlagen der Datenübernahme aus einem Realsystem in ein Trainingssystem Klärung grundlegender Begriffe Typical Instanzname Snapshot S7-Verbindung Aufbau des Realsystems und seine Unterschiede zum Trainingssystem Grundlegender Aufbau des Testsystems Vorgehensweise bei der Datenübernahme Lesen Exportieren Snapshotmanipulation Schreiben in SoftPLCs IX

14 Inhaltsverzeichnis 5 Realisierung und Konzeption der Datenübernahme Lesen der Daten Auswahl des Zugriffverfahrens Libnodave Accon AGLink OLE for Process Control (OPC) Bewertung und Auswahl Anpassungen in PCS UDTs Schatten-Datenbausteine R2S_FC_PROG R2S_DB_PROG_HANDLER Exportieren der Daten Initialisieren der Simulation Initialisierung von SIMIT Mapping in das Snapshotfile Mapping allgemeiner Daten Übernahme der Daten in SIMIT Initialisieren der SIMIT Prozessmodelle Übertragen der Daten in die SoftPLCs Schatten-Datenbausteine R2S_FC_PROG Nachführen von Motoren Starten der Simulation Realisierung im Programm Programmstruktur Allgemeine Programmstruktur Struktur der gelesenen Daten Konfigurations-Datei Connections OPC-Server WinCC_Connection S7Connection DBStructures Mapping Assignment Assignment.Log Assignment.Log.Set Assignment.Log.Calculate X

15 Inhaltsverzeichnis Set Set.Log Set.Calculate ReadData Programminitialisierung Lesen von Daten aus Realsystemen Verbinden Lesevorgang Exportieren Übernahme der Daten in das Trainingssystem Laden der Snapshot-Datei Anwenden der Mappingfunktionen Abspeichern der Snapshot-Datei Schreiben der Daten auf die SoftPLCs Zusätzliche Programmfunktionen Konfigurationseditor Kommandozeilen-Argumente Bewertung und Verifikation der Simulation Überprüfung der Datenübernahme Abweichungen durch das fehlende Anlaufverhalten Abweichungen bei Fehlverhalten Abweichungen aufgrund komplexer Simulationsmodelle Bewertung der Datenübernahme Zusammenfassung und Ausblick 88 Literaturverzeichnis 89 A Anhang i A.1 Messwerte ii A.2 Verfügbare Typicals v A.3 CD-ROM vi A.4 Beispielkonfiguration vii XI

16 1 Einleitung 1 Einleitung Der moderne Schiffbau zeichnet sich durch einen immer weiter voranschreitenden Einsatz der Automatisierungstechnik aus. So können bereits heute die meisten Prozesse und Anlagen über zentrale Eingabegeräte ferngesteuert werden. In Zeiten in denen immer mehr darauf geachtet wird, die Einsatzzeiten der Schiffe möglichst hoch zu halten, um den maximalen Gewinn zu erzielen, bietet der vermehrte Einsatz der Automatisierungstechnik Möglichkeiten zur Überwachung der Systeme an Bord. So können Fehler bereits frühzeitig erkannt und noch an Bord behoben werden, bevor größere Reperaturen durch Folgeschäden notwendig werden. Ein weiterer Vorteil ist, dass nur noch ein Bruchteil der Mannschaft ausreichend ist, um ein Schiff betreiben zu können. Um die Besatzungen im Umgang mit der Bedienung dieser Systeme schulen zu können, werden zwei grundlegende Ansätze unterschieden. Zum einen existieren sogenannte Land Based Training Systems (LBTS). Dabei handelt es sich um Trainingszentren auf dem Festland, die mit originalgetreuen Nachbildungen der realen Bedienungsanlagen ausgestattet sind. Die Besatzungen können so bereits vor ihrem Einsatz an Bord, an die Anlagen herangeführt und geschult werden. Ein weiterer Ansatz sind die On Board Training Systems (OBTS). Hierbei werden die Anlagen auf dem Schiff selbst zu Trainingszwecken verwendet. Für beide Varianten der Siemens AG gelten folgende Anforderungen: Realsystem und Trainingssystem sind voneinander unabhängig und rückwirkungsfrei Das Trainingssystem basiert auf der originalen Automatisierungssoftware (Systemund Anwendersoftware) des realen Systems Einsatz des originalen oder nachgebildeten Human Machine Interface (HMI) um den Wiedererkennungswert zu steigern Die realen Prozesse werden durch Modelle in einer Simulation ersetzt Die Simulation muss das Verhalten des Schiffes hinreichend genau abbilden Die Trainingssituationen können von einfachen Fahrten bishin zu komplexen Notfallsituationen reichen. Zudem können durch die Trainer verschiedene Fehler bzw. Systemausfälle nachgebildet werden, auf die die Besatzung reagieren muss. Zur Grundlage der Simulation dient ein definierter Initialzustand des Schiffsmodells und seiner Komponenten. Dieser musste bisher durch die Trainer aufwendig erstellt und editiert werden. Um diesen Prozess zu vereinfachen besteht die Forderung, die momentanen 1

17 1 Einleitung Ist-Werte des Schiffes lesen und abspeichern zu können. Im Anschluss soll anhand dieses Datensatzes die Simulation initialisiert werden. Neben den Betriebszuständen der einzelnen Komponenten müssen dazu auch noch deren Parametrierung und weitere Daten erfasst werden. Das Ziel dieser Diplomarbeit ist es, ein Programm zu entwickeln, welches die Daten aus den speicherprogrammierbaren Steuerungen SPS des Schiffes lesen und im Anschluss die Simulation anhand dieser Daten initialisieren kann. Dementsprechend ergeben sich folgende Aufgaben und Anforderungen: Konzeption der Datenübernahme Analyse der Automationssoftware (SIMATIC PCS7) Analyse der Simulation (SIMIT) Analyse möglicher Kommunikationsmechanismen Erstellen eines Programms welches die Daten verwalten kann Lesen der Daten aus den SPS Speichern der Daten als Datensatz Einlesen des Datensatzes Initialisieren der Simulation Schreiben von Parametern in die SPS Es ist dabei zu verifizieren ob eine prinzipielle Datenübernahme dergestalt möglich ist, dass die Simulation hinreichend genau die realen Zustände abbildet. Zudem sind Mechanismen zu erarbeiten, die die prinzipielle Vorgehensweise der Datenübernahme beschreiben. Hierfür werden zunächst in Kapitel 2 die gundlegenden Begriffe der Automatisierungstechnik geklärt. Darauf folgt ein kurzer Überblick über die im Rahmen dieser Diplomarbeit verwendeten Software in Kapitel 3 gefolgt von einem theoretischen Überblick über die Datenübernahme in Kapitel 4. Anschliessend widmen sich die Kapitel 5 und 6 der praktischen Umsetzung und Konzeption. Die Bewertung und Verifikation der entwickelten Methoden erfolgt abschliessend in Kapitel 7. 2

18 2 Grundlagen der Automatisierungstechnik 2 Grundlagen der Automatisierungstechnik Die Automatisierungstechnik ist heute ein fester Bestandteil des Maschinen- und Anlagenbaus. Umgangssprachlich wird darunter das Umstellen fertigungs- und verfahrenstechnischer Prozesse von manueller Arbeit auf selbsttätige Arbeitsvorgänge verstanden. Hierbei wird die aufgabenspezifische Anlage durch standardisierte Automatisierungsgeräte erweitert. Als wichtigste Standardgeräte haben sich die Speicherprogrammierbaren Steuerungen (SPS) und Industrie-PCs etabliert. Die Automatisierungsgeräte folgen dabei selbstständig Programmen und fällen Entscheidungen anhand vorgegebener Führungs- und rückgeführter Prozessgrößen. Der Begriff Automatisierung umfasst dabei als Oberbegriff die Felder der Steuerungs-, Regelungsund Visualisierungsvorgänge. Die Motivation zur zunehmenden Automatisierung ergibt sich unter anderem aus folgenden Gründen: Entlastung des Menschen von gefährlichen bzw. anstrengenden Arbeiten Qualitätsverbesserung höhere Leistungsfähigkeit Senkung von Personalkosten Je nach Automatisierungsgrad wird die menschliche Arbeitskraft nur noch für die Überwachung, den Nachschub und den Abtransport der Fertigteile eingesetzt. Der Automatisierungsgrad ist dabei ein Maß für den Einsatz der Automatisierungstechnik und ergibt sich aus dem Verhältnis automatisierter Fertigungsschritte zu der Gesamtzahl der Fertigungsschritte. Automatisierungsgrad = automatisierte Fertigungsschritte Gesamtzahl der Fertigungsschritte (2.1) Auch in der modernen Schifffahrt werden heute viele Prozesse und Funktionen mittels der Automatisierungstechnik überwacht und gesteuert. Dementsprechend werden in den folgenden Abschnitten die wichtigsten Begriffe und Methoden aus diesem Bereich erläutert.[22] 2.1 Speicherprogrammierbare Steuerungen Die konventionelle Steuerungstechnik beruht auf dem Einsatz von Schützen und Relais, welche durch eine feste Verdrahtung untereinander die Steuerungsaufgabe realisieren. 3

19 2 Grundlagen der Automatisierungstechnik Aufgrund dieser festen Verdrahtung sind spätere Änderungen im Ablauf, oder eine einfache Wartnung nur schwer realisierbar. Im Gegenzug dazu werden bei der Verwendung Speicherprogrammierbarer Steuerungen (SPS) serienmässige Standardgeräte verwendet, die mittels eines Anwenderprogramms die Ausgänge entsprechend der Werte der Eingänge manipulieren. Der englische Begriff für SPS ist Programmable Logic Controller (PLC). Der prinzipielle Aufbau einer Speicherprogrammierbare Steuerung (SPS) ähnelt dem eines Personal Computers (PCs), die eigentliche Funktion wird erst durch das geladene Anwenderprogramm bestimmt. Im einfachsten Fall besteht eine SPS aus folgenden Elementen: einer Spannungsversorgung (PS) einem Prozessor (CPU) digitalen und analogen Ein- und Ausgangsbaugruppen und einem integrierten Bussystem Dieser grundlegende Aufbau kann in den meisten Fällen durch weitere Peripheriebaugruppen erweitert werden. Durch diese zusätzlichen Baugruppen kann der Anwender weitere Ein- und Ausgänge, oder auch weitere Feldbusschnittstellen realisieren. Im Zuge eines immer stärkeren Einsatzes standardisierter Feldbussysteme, müssen die Ein- und Ausgangsbaugruppen nicht mehr zentral an die Steuerung gekoppelt werden. Stattdessen können sie über dezentrale Peripheriebaugruppen (DP) möglichst nahe an den Prozess gebracht gebracht werden. Da die DP über Feldbusleitungen mit der zentralen Steuereinheit verbunden ist, kann der Verkabelungsaufwand drastisch reduziert werden. Abbildung 2.1: Die modularen Steuerungen der SIMATIC S7 Reihe als Beispiele für eine SPS [7] SPSen sind in unterschiedlichen Leistungsklassen und Baugrößen verfügbar. Je nach Anforderung können kleine Kompaktgeräte oder große modulare Einheiten zum Einsatz kommen. 4

20 2 Grundlagen der Automatisierungstechnik In Abbildung 2.1 sind beispielhaft die verschiedenen Geräte der SIMATIC S7 Reihe dargestellt. Im rechten Hintergrund ist eine SIMATIC S7-400 zu sehen. Die S7-400 ist das leistungsstärkste Gerät der Produktpalette und kommt speziell für große Projekte (z.b. Koordination von Gesamtanlagen) in Frage. Davor befindet sich die SIMATIC S7-300, die durch ihren platzsparenden und modularen Aufbau besonders für zentrale Erweiterungen oder dezentrale Strukturen eingesetzt werden kann. [12][19][22] Permanent-Zyklischer Betrieb Im Gegensatz zu einem PC erfolgt die Programmbearbeitung bei SPSen zyklisch. Man spricht hierbei von einem permanent-zyklischem Betrieb. Nach dem Einschalten der Central Processing Unit (CPU) durchläuft diese zunächst das Betriebssystem und eventuell ein Anlaufprogramm. Damit wird sie initialisiert und grundlegende Einstellungen vorgenommen. Erst danach kann mit dem ersten Zyklus begonnen werden. In Abbildung 2.2 ist die prinzipielle Funktionsweise des zyklischen Programmablaufs dargestellt. Jeder Zyklus beginnt mit dem Einlesen der aktuellen Signalzustände der Eingänge in das Prozessabbild der SPS. Danach werden nacheinander die Adressen der einzelnen Speicherzellen des Arbeitsspeichers angewählt. In diesen Speicherzellen befindet sich das geladene Steuerprogramm. Die enthaltene Steueranweisung wird in das Steuerwerk übertragen und abgearbeitet. Danach wird der Addresszähler inkrementiert und die nächste Anweisung wird bearbeitet. Am Ende der Programmbearbeitung werden die errechneten Signalzustände an die Ausgänge übertragen, bevor die Steuerung mit dem Abarbeiten des nächsten Zyklus beginnt. Abbildung 2.2: Prinzipielle Darstellung des permanent-zyklischen Programmablaufs [20] Die Zeit, die für einen Programmdurchlauf benötigt wird, wird als Zykluszeit bezeichnet. Sie muss hinreichend klein sein um auftretende Signaländerungen der Eingänge sicher 5

21 2 Grundlagen der Automatisierungstechnik erfassen und die Ausgänge entsprechend schalten zu können, so dass der Prozess steuerbar bleibt. Man spricht hierbei von der Echtzeitbedingung der Steuerungstechnik. Programmierung Die Programmierung von speicherprogrammierbaren Steuerungen erfolgt durch das Aufrufen von Programmbausteinen. Diese können unabhängig voneinander programmiert werden. In der Regel sind die Bausteine in größeren Bibliotheken abgelegt und können einfach in neuen Programmen aufgerufen werden. Prinzipiell wird dabei in Funktionsbausteine, Datenbausteine und Organisationsbausteine unterschieden. Tabelle 2.1: Die grundlegenden Bausteine der Programmierung von speicherprogrammierbaren Steuerungen Baustein Abkürzung Beschreibung Funktion FC Der Funktion werden Parameter übergeben, diese verarbeitet und einen Rückgabewert zurückliefert. Der Rückgabewert wird dabei nicht gespeichert (= ohne Gedächtnis) Funktionsbaustein FB Dem Funktionsbaustein werden ebenfalls Parameter übergeben, die er entsprechend verarbeitet. Am Ende der Funktion bleiben die Ergebnisse in Form von Parametern z.b. in einem Instanz-Datenbaustein weiter erhalten (= mit Gedächtnis) Datenbaustein DB Dienen dem Abspeichern von Daten Organisationsbaustein OB Organisationsbausteine steuern den zeitlichen Ablauf von Programmen und Funktionen Die Entwicklung der Programmiersprachen begann zunächst herstellerspezifisch, d.h. jeder Hersteller entwickelte i.d.r. eine eigene Programmiersprache für seine Geräte. Eine Kompatibilität zwischen diesen war meistens nicht vorgesehen. Erst mit der Norm IEC wurden einige dieser Programmiersprachen standardisiert, um eine Portabilität der Programm zu erreichen. Zu diesen Programmiersprachen zählen: Anweisungsliste (AWL) Strukturierter Text (ST) Kontaktplan (KOP) Funktionsbausteinsprache (FBS) 6

22 2 Grundlagen der Automatisierungstechnik Ablaufsprache (AS) [20][22][12][19] 2.2 Prozessleitsysteme Prozessleitsysteme (PLS) sind eine Kernkomponente der heutigen Automatisierungslösungen, speziell für größere Anlagen. Da sie im Gegensatz zu herkömmlichen Systemen alle Ebenen vom Prozess bis hin zur Unternehmensebene verknüpfen und damit Informationen - zum Prozess selbst - global verfügbar machen können. PLS werden zum Führen von fertigungs- und verfahrenstechnischen Anlagen verwendet. Sie bestehen aus prozessnahen Komponenten (PNK), Bedien- und Beobachtungstationen (BUB) und Engineering-Komponenten (EK). Der prinzipielle Aufbau eines PLS ist in Abbildung 2.3 dargestellt. Die unterste Ebene, die Feldebene, beinhaltet alle prozessnahen Komponenten wie Aktoren, Sensoren sowie die dezentrale Peripherie. Diese Komponenten stehen im unmittelbaren Kontakt zu dem zu führenden Prozess. Über Feldbusse sind diese mit den Steuerungen der nächsthöheren Steuerungsebene verbunden. Durch sie wird der eigentliche Prozess kontrolliert und überwacht. Abbildung 2.3: Strukturelle Aufteilung eines PLS Um dem Bedienpersonal Einfluss auf die Steuerung des Prozesses zu gewähren, besitzt die oberste Ebene (Leitebene) so genannte Operator Stationen OS. Mittels der Bedienoberflächen, die Human Machine Interface (HMI) genannt werden, kann das Personal die Werte und Parameter des Prozesses überwachen, oder direkt Einfluss darauf nehmen. Zur weiteren Ausstattung gehören in der Regel Server zur Datenarchivierung und eine Engineering Station (ES) zur Projektierung, Änderungsprojektierung und Fehlerbehebung. [17] 7

23 3 Verwendete Software 3 Verwendete Software 3.1 Prozessleitsystem PCS-7 Für die Erstellung von Prozessleitsystemen stellt die Siemens AG mit dem Softwarepaket PCS7 eine umfassende Entwicklungsumgebung bereit. Die Entwicklungsarbeiten an einem solchen System reichen dabei von der Feld- bis zu Leitebene. Dazu zählen die Hardware- und Verbindungsprojektierung, die Visualisierung und das Steuerungsprogramm selbst. Als zentrales Entwicklungsprogramm steht der SIMATIC Manager zu Verfügung. Hier können einzelne oder verknüpfte Projekte (Multi-Projekte) verwaltet und editiert werden. Für ein PCS-7 Projekt existieren im SIMATIC Manager drei Ansichten: Komponentensicht Technologische Sicht Prozessobjektsicht Während die Komponentensicht in erster Linie der Projektierung der Hardware und Verbindungen dient, werden die Pläne des Steuerungsprogramms in der Technologischen Sicht bearbeitet und erstellt. Die Prozessobjektsicht wird in der Regel seltener genutzt, sie dient als eine Art Filter mit dem Bausteine, Anschlüsse, Signale etc. angezeigt und parametriert oder verschaltet werden können. Abbildung 3.1: Beispiel eines CFC-Plans 8

24 3 Verwendete Software Ein Steuerungsprogramm in PCS-7 besteht i.d.r. aus einer Vielzahl an Plänen. Diese können entweder als Sequential Function Chart (SFC) oder als Continuous Function Chart (CFC) angelegt werden, wobei insbesondere für Großanlagen die CFCs von größerer Bedeutung sind. Bei den CFC-Plänen handelt es sich um eine graphische Programmiersprache (siehe Abbildung 3.1). Jeder Plan besitzt zwei Randleisten, die linke für Eingänge und die rechte für Ausgänge. Dazwischen können Bausteine positioniert und mit Verbindungslinien verschaltet werden. Die Bausteine erfüllen dabei in erster Linie den Zweck grundlegender mathematischer und logischer Operationen. Sie können aber auch derartig entwickelt werden, um komplexe Aufgabenstellungen zu bearbeiten. Für diesen Zweck existieren Bibliotheken mit einer Vielzahl an Bausteinen, welche speziell auf das Einsatzgebiet abgestimmt sind. Abbildung 3.2: Ansicht des Unterprogramms HW-Config für die Hardwarekonfiguration Neben der Programmierung der tatsächlichen Steuerungssoftware umfasst PCS7 auch die Werkzeuge zur Projektierung und Programmierung der Hardware. Hierfür wird das Unterprogramm HW-Config benutzt. Mit diesem lassen sich komplette Stationen, bestehend aus CPUs, Communication Processor (CP)s und der dezentralen Peripherie planen, parametrieren und laden. Gleichzeitig wird dieses Programm verwendet um die Vernetzung der einzelnen Hardware-Komponenten untereinander zu realisieren. Die Verbindungen können zusätzlich mit dem Programm NetPro (siehe Abbildung 3.3) graphisch darge- 9

25 3 Verwendete Software stellt und weiter bearbeitet werden. Abbildung 3.3: Beispiel für die Ansicht des Unterprogramms NetPRO in dem die Verbindungen zwischen den einzelnen Stationen projektiert werden Neben diesen Kernbereichen der Projektierung einer Anlage umfasst PCS7 weitere Werkzeuge, auf die hier aber nicht näher eingegangen werden soll. Für weitere Informationen sei in diesem Zusammenhang auf das Literaturverzeichnis verwiesen. 3.2 Prozessvisualisierungsprogramm WinCC Das Prozessvisualisierungstool WinCC dient als Human Machine Interface (HMI) auf den Operator Stations (Operator Station (OS)) und ist damit in der Leitebene eines PLS angesiedelt. Abbildung 3.4: Die Oberfläche des Prozessvisualisierungsprogrammss WinCC am Beispiel eines Heeling-Systems 10

26 3 Verwendete Software Über Skizzen des physikalischen oder logischen Anlagenaufbaus erhält der Anwender einen Überblick über den momentanen Zustand der Anlage. Der aktuelle Zustand der Komponenten wird in diesen Skizzen über sogennannte Block-Icons dargestellt. Dabei handelt es sich um eine symbolische Darstellung der Komponente, wobei deren Zustände durch Farben oder weitere Icons dargestellt werden. Durch einen Mausklick auf ein solches Block-Icon öffnet sich ein dazugehöriges Fenster - das sogenannte Faceplate. Über das Faceplate können weitere Informationen angezeigt bzw. die Komponente gesteuert werden. Der Funktionsumfang des Faceplates richtet sich dabei nach der dazugehörigen Komponente. Abbildung 3.5: Beispiel für ein Faceplate, hier für einen Motor 2D1V Die Projektierung des WinCC-Projekts kann dabei über den SIMATIC-Manager erfolgen. Nachdem hier eine entsprechende WinCC Station projektiert wurde, kann diese übersetzt werden. Durch diesen Vorgang werden automatisch die Block-Icons aus dem aktuellen PCS-7 Programm übernommen und eingefügt. Die Skizzierung der Anlage muss im folgenden durch den Anwender selbst erfolgen. 3.3 Prozesssimulationsprogramm SIMIT Bei dem Programm SIMIT handelt es sich um ein Prozesssimulationsprogramm der Siemens AG. Es dient der modellhaften Nachbildung verfahrenstechnischer Prozesse und mechanischer Anlagenteile. Damit wird in erster Line das Ziel verfolgt neu entwickelte oder veränderte Automatisierungsprogramme in einer sicheren Umgebung zu testen, bevor diese auf einer realen Anlage eingesetzt werden. Um bereits in dieser Phase der Programmentwicklung den Prozess optimieren zu können muss sich das Verhalten der zugrundeliegenden Modelle so nah wie möglich an der Realität orientieren. Da Industrieanlagen i.d.r. aus einer Vielzahl einzelner Komponenten bestehen, die in Variationen immer wieder auftauchen (z.b. Motoren, Ventile, etc.) existieren dafür bereits 11

27 3 Verwendete Software vorgefertigte Modelle (Typicals). Diese müssen anschliessend noch entsprechend parametriert (z.b.: Nennleistung, Drehzahl, maximale Leistung etc.) und verschaltet werden. Das Erstellen dieser Komponenten (Massendaten) erfolgt durch einen sogenannten SMD- Import aus einer Messstellendatenbank. Die einzelnen Messtellen werden in dieser Datenbank entsprechend ihrer realen Äquivalente parametriert. Die dafür notwendigen Informationen können aus dem PCS7-Programm und Datenblättern gewonnen werden. Abbildung 3.6: Beispielhafte Abbildung für ein SIMIT Modell Die Verschaltung der einzelnen Teilkomponenten erfolgt in einem nächsten Schritt ähnlich den bereits erwähnten CFC-Plänen mittels Kontakten und Verbindungen. Komplexere Operationen können dabei in eigene Bausteine ausgelagert werden, die über eine SIMIT-eigene Programmiersprache geschrieben werden. Als Schnittstellen zu den weiteren Komponenten der Simulation dienen Ein- und Ausgänge sowie Parameter und interne Zustände. 3.4 Emulationsplattform SchEmu Bei dem Program SchEmu handelt es sich um eine Emulationsplattform für S7-Steuerungen. Speziell im Falle einer Simulation mit SIMIT stellt die Emulation realer CPUs eine platzsparende und kostengünstigere Alternative. Hierzu wird lediglich ein herkömmlicher PC 12

28 3 Verwendete Software benötigt auf dem die Software installiert ist. In Abhängigkeit der Rechenleistung können so eine oder mehrere Steuerungen emuliert werden (SoftPLCs). Der Funktionsumfang dieser Emulationen entspricht im wesentlichen dem einer realen CPU. Abbildung 3.7: Fenster für eine SoftPLC der Eumlationsplattform SchEmu 3.5 OLE for Process Control (OPC) Zu Beginn der Automatisierung mit Speicherprogrammierbaren Steurungen brachte eine Vielzahl von Hersteller eigene Geräte auf den Markt. Jeder Hersteller verfolgte dabei seine eigene Strategie in den Bereichen Software und Kommunikations-Protokolle. Dementsprechend war eine Kompatibilität der Geräte unterschiedlicher Hersteller nicht gegeben. Um eine Kommunikation zwischen den Geräten herzustellen war es notwendig eigene Treiber zu implementieren, was jedoch mit einem erheblichen Aufwand an Kosten und Zeit verbunden war. In Folge der zunehmenden Entwicklung, speziell in Richtung wiederverwendbarer Softwarekomponenten, kamen Forderungen nach standardisierten Schnittstellen zwischen den Komponenten unterschiedlicher Hersteller auf. Um dies zu ermöglichen, schlossen sich 1995 mehrere Hersteller der Branche zusammen, um einen einheitlichen Standard für den Datenaustausch zu entwickeln. Unter dem Namen OPC Task Force entwickelten Vertreter dieser Firmen einen Standard für den Zugriff auf Echtzeitdaten unter Windows Betriebssystemen. Die Abkürzung OPC steht dabei für OLE for Process Control. Die erste Version - die Opc Specification Version wurde am 29. August 1996 nach nur einem Jahr Entwicklungszeit veröffentlicht. Im Gegensatz zu vorherigen Lösungen, handelt es sich bei dem OPC-Protokoll um einen technologischen Standard und nicht mehr um einen produktbasierten Standard. Dementsprechend lassen sich einfach und komfortabel verschiedene Systeme wie Speicherprogrammierbare Steuerungen, Prozessleitsysteme und Datenbanken mit einander verbinden. Das OPC Projekt wird mittlerweile durch die OPC-Foundation weitergeführt. Neben der OPC DA Spezifikation entstanden so im Laufe der Jahre weitere Spezifikationen (Tabelle 3.1). 13

29 3 Verwendete Software Der Datenaustausch erfolgt dabei über OPC-Server welche über Profibus, MPI, Ethernet o.ä. mit der Datenquelle (z.b. einer SPS) verbunden sind, und OPC Clients, welche auf die Daten zugreifen. Die grundlegende Struktur des OPC DA ist in Abbildung 3.8 dargestellt. Tabelle 3.1: OPC Spezifikationen [18] Spezifikation OPC Overview OPC Common Definitions and Interfaces OPC Data Access Specification OPC Alarms and Events Specifiaction OPC Historical Data Access Specification OPC Batch Specification OPC Security Specification OPC and XML Bedeutung Allgemeine Beschreibung der Einsatzgebiete von OPC-Spezifikationen Festlegung von Sachverhalten, die eine große Anzahl von Spezifikationen betreffen Definition einer Schnittstelle für das Lesen und Schreiben von Echtzeitdaten Definition einer Schnittstelle zur Überwachung von Ereignissen Definition einer Schnittstelle zum Zugriff auf historische Daten Definition einer Schnittstelle zum Zugriff auf Daten, die bei der Batch-Verarbeitung benötigt werden. Diese Spezifikation erweitert die OPC Data Access Specification Definition einer Schnittstelle für das Einstellen und Nutzen von Sicherheitsaspekten Integration von OPC und XML zur Erstellung von Web-Anwendungen Abbildung 3.8: Grundlegende Strukur des OPC DA Protokolls [6] 14

30 3 Verwendete Software Wie in der Abbildung zu sehen, besteht der OPC Server aus zwei verschiedenen Komponenten. Wobei die eine Seite den Clients zugewandt ist und die standartisierte OPC- Schnittstelle für den Datenaustausch mit anderen Geräten ermöglicht. Die zweite Komponente dagegen ist spezifisch auf die Datenquelle ausgerichtet. Sie dient dazu, dass herstellerabhängige Protokoll des Geräts mit der OPC-Schnittstelle zu verbinden. Der OPC Server ist daher in der Regel direkt mit der SPS verbunden. Während sich der OPC-Client dagegen i.d.r. auf den Bedienstationen oder Rechnern der Prozessdatenarchivierung befindet. Die zulesenden Daten werden als Datenpunkte bezeichnet. Jeder Datenpunkt verfügt über ein Objekt Wert, Quality und Timestamp. Über das Qualityobjekt kann der Wert validiert werden. Für den Datenaustausch der Datenpunkte existieren zwei Möglichkeiten, der synchrone und der asynchrone Datenaustausch. Bei einer synchronen Übermittlung der Daten werden stets alle spezifizierten Datenpunkte ausgetauscht, während bei einer asynchronen Anbindung lediglich veränderte Werte übermittelt werden, um das auftretende Datenvolumen zu reduzieren. Die Adressierung der PLCs erfolgt im weiteren über S7-Verbindungen. Im SIMATIC Manager projektiert und auf die OS geladen, definieren diese eindeutig eine Verbindung zwischen zwei Knoten, in diesem Fall zwischem dem OPC-Server und den PLCs (Abbildung 3.9). Abbildung 3.9: Adressierung der PLCs über die eindeutigen Namen der S7-Verbindungen Nachdem die Adressierung einer PLC möglich ist, bedarf es im weiteren Verlauf der Adressierung der Speicherbereiche. Dies wird über die sogenannten ItemIDs realisiert: S7:[S7-Verbindung_1],DB693,Real,54 Das Beispiel zeigt wie ein Real-Wert aus dem DB693 gelesen werden kann, der sich bei der Byte-Adresse 54 befindet. [18][5][6] 15

31 4 Grundlagen der Datenübernahme aus einem Realsystem in ein Trainingssystem 4 Grundlagen der Datenübernahme aus einem Realsystem in ein Trainingssystem Zur besseren Erläuterung der Problemstellungen bei der Datenübernahme von einem realen Schiff sollen zunächst einige grundlegende Begriffe erläutert werden (Abschnitt 4.1). Danach werden die Unterschiede zwischen einem realen System und einer Trainingsanlage geklärt, bevor näher auf die einzelnen Schritte der eigentlichen Datenübernahme eingegangen wird. 4.1 Klärung grundlegender Begriffe Typical Um den Entwicklungsaufwand zu reduzieren existieren im PCS-7 spezielle Bibliotheken die vorgefertigte Bausteine enthalten, welche wiederum einfach in ein neues PCS7-Projekt eingefügt werden können. Je nach Industriezweig gibt es Bibliotheken für den Schiffbau, die Papierindustrie oder die Bergbauindustrie. Die vorgefertigten Bausteine können im folgenden genutzt werden um z.b. die Ansteuerung von Motoren mit den entsprechenden Befehlen und Rückmeldungen in einem Automatisierungsprogramm zu integrieren. Der jeweilige Baustein kann durch Parametrierung an das reale Objekt angepasst werden. Diese Grundbausteine werden auch als Typicals bezeichnet. Davon abgeleitete Elemente, werden im Folgenden als Instanzen bezeichnet. Abbildung 4.1: Beispiel für ein Typical MAS_DRV_2D2V (Motor mit zwei Richtungen und zwei Geschwindigkeiten) [10] Durch die immer wiederkehrende Struktur ergibt sich ein Vorteil für die Datenübernahme, da für jede Instanz eines Typicals die gleichen Daten notwendig sind, um die Simulationsmodelle des Trainingssystems korrekt zu initialisieren. Dementsprechend gelten für 16

32 4 Grundlagen der Datenübernahme aus einem Realsystem in ein Trainingssystem alle Instanzen eines Typicals die gleichen Vorschriften für die spätere Initialisierung der Simulation Instanzname Der Instanzname dient der eineindeutigen Identifikation einer Instanz. Dieser Name ist in einem PCS-7 Projekt daher genau einmal vergeben. Beispiel X120_ Snapshot Für die Simulation des Schiffsverhaltens wird das Simulationsprogramm SIMIT verwendet. Dieses verfügt über die Möglichkeit die laufende Simulation zu unterbrechen und ein Abbild der momentanen Zustände zu erstellen. Dieses Abbild wird als Snapshot bezeichnet. Die internen Zustände der Simulation werden dabei zeilenweise in eine Textdatei geschrieben. Jeder Wert (z.b.: R2Spv) wird dabei mit einer Zuweisung abgespeichert: EM_X120_000/EM_X120_000_ANA_STD/R2Spv= Da in dieser Zuweisung der Instanzname enthalten ist, kann dieser Wert relativ leicht durch ein Programm gefunden und verändert werden S7-Verbindung Die S7-Verbindung ist Teil der S7-Kommunikation, einem geschlossenem Protokoll der Siemens AG. Es ist dabei in allen Produkten SIMATIC S7/M7/C7 integriert und dient der Kommunikation zwischen Siemensgeräten. Die S7-Kommunikation entspricht dabei einem Dienst der Anwendungsschicht (ISO/OSI-7-Schichtenmodell) und ist daher unabhängig vom Subnetz und kann auf allen Verbindungen (Ethernet, MPI, Profibus) genutzt werden. [3] 17

33 4 Grundlagen der Datenübernahme aus einem Realsystem in ein Trainingssystem 4.2 Aufbau des Realsystems und seine Unterschiede zum Trainingssystem Um die Unterschiede zwischen dem realen System und dem Trainingssystem herauszustellen bedarf es zunächst grundlegender Kenntnisse über den Aufbau des realen Systems. Wie bereits erwähnt handelt es sich bei der Automatisierung auf einem Schiff um ein Prozessleitsystem mit Leit- Steuerungs- und Feldebene. Wobei die Leitebene als HMISchnittstelle fungiert. Entsprechende Steuerbefehle und Vorgaben können an einer OS vorgenommen werden. Diese Eingaben werden an die Steuerungen und über deren Steuerungsprogramm entsprechend modifiziert an die Feldebene und damit an die Endgeräte weitergeleitet. Abbildung 4.2: Der vereinfachte Aufbau eines Prozessleitsystems an Bord eines Schiffes [2][4][1] In Abbildung 4.2 ist der prinzipielle Aufbau eines Prozessleitsystems an Bord eines Schiffes vereinfacht dargestellt. In der obersten Ebene, der Leitebene, befinden sich die Operator Stations, die Engineering Station und eventuelle weitere Server Stationen. Sie entsprechen, wie bereits beschrieben, der Schnittstelle zwischen dem Bedienpersonal und der Anlage an sich. Um einen möglichst hohen Wiedererkennungswert bei der Trainingsmannschaft zu erreichen, müssen diese Bedienorte möglichst genau denen der realen Anlage entsprechen. In der darunterliegenden Schicht, der Steuerungsebene, befindet sich die Hardware der Automatisierungstechnik. Dazu zählen die PLCs als zentrale Recheneinheiten, sowie deren Peripherie mit Busverbindungen und Peripheriegeräten. Ein kompletter Nachbau 18

34 4 Grundlagen der Datenübernahme aus einem Realsystem in ein Trainingssystem dieses Systems wäre für eine Trainingseinrichtung zu aufwendig und kostenintensiv. Aus diesem Grund werden die Elemente dieser Ebene durch SoftPLC s (siehe Kapitel 3.4) ersetzt. Diese bilden im Wesentlichen das gleiche Aufgabenspektrum mit geringen Abweichungen ab. Dementsprechend kann das originäre Steuerprogramm der realen Anlage benutzt werden. Die Geräte der Feldebene werden beim Trainingssystem simuliert. Hierbei ist es notwendig das sich das Verhalten jeder einzelner Komponente möglichst nah an der Realität befindet. Hierfür kommen die verschiedenen vorgefertigten Simulationsmodelle in SIMIT zum Einsatz. Abbildung 4.3: Der unterschiedliche Aufbau eines realen Systems (links) und einer Trainingsanlage (rechts) Dementsprechend ergibt sich der unterschiedliche Aufbau des Trainingssystem wie in Abbildung 4.3 zu sehen. 4.3 Grundlegender Aufbau des Testsystems Das verwendete Testsystem muss sowohl das reale System als auch das Trainingssystem darstellen können und dabei möglichst kompakt sein. Daher besteht der verwendete Aufbau aus drei PCs und zwei PLCs vom Typ SIMATIC S H. Zwei der verwendeten Computer sind zusätzlich mit virtuellen Maschinen ausgerüstet, so dass insgesamt fünf logische Computer zur Verfügung stehen (Abbildung 4.4). Das Verhalten des Schiffes - sowohl für das reale System als auch das Trainingssytem - wird mit Hilfe von SIMIT simuliert 1. SIMIT verfügt dabei über zwei getrennte Simulationen. Jeweils eine für das reale System, welches via Profibus an den Rechner gekoppelt ist und für das Trainingssystem, das über die Emulations-Plattform angeschlossen wird. 1 Für das Testsystem wird auch das reale System mit Hilfe von SIMIT dargestellt, da es nicht möglich ist auf ein reales Schiff zurückzugreifen 19

35 4 Grundlagen der Datenübernahme aus einem Realsystem in ein Trainingssystem Abbildung 4.4: Grundlegender Aufbau des Testsystems Als PLCs stehen die beiden SIMATIC S7-400er für das Realsystem zur Verfügung. Während das Trainingssystem mit zwei SoftPLCs betrieben wird. Die Projektierung beider Systeme in PCS-7 erfolgt über die VM ES. Um die verschiedenen Systeme zu laden wird die Programmierschnittstelle im SIMATIC Manager entweder auf ISO Ind. Ethernet für das reale System, bzw. auf TCP/IP für das Trainingssystem gestellt. Als Operator Stations stehen OSS01 (Realsystem) und OSS02 (Trainingssystem) zur Verfügung. 4.4 Vorgehensweise bei der Datenübernahme Das Ziel dieser Diplomarbeit ist es ein Konzept zu entwickeln, um bislang getrennten Bereiche - mit dem Schiff und seinem Automatisierungssystem auf der einen, sowie dem Trainingssystem auf der anderen Seite - miteinander zu verbinden. Da beide Systeme bereits in der Realität existieren, muss ein Weg gefunden werden die Verknüpfung zu realisieren, ohne in die bereits bestehenden Strukturen großartig eingreifen zu müssen. Es besteht also die Forderung nach einem möglichst guten Kompromis zwischen der Realitätstreue auf der einen und dem zu betreibenden Aufwand auf der anderen Seite. Da es sich bei der Simulation um ein Trainingssystem zur Schulung von Schiffsbesatzungen handelt und nicht zur Prozessoptimierung, können in einigen Feldern durchaus leichte Abstriche bei der Exaktheit der Zustände gemacht werden. Das Auslesen der Daten aus den Steuerungen an sich bedarf einiger Überlegungen und Änderungen, stellt in der Gesamtproblematik allerdings nur einen geringen Prozentsatz dar. Deutlich komplexer sind die Problemstellungen auf der Seite des Trainingssystems. Als Basis der Initialisierung dient hier ein Snapshot der vorhandenen Simulation, welcher mit den Daten des realen Systems manipuliert wird. Der eigentliche Snapshot setzt sich dabei aus drei Bereichen zusammen, welche getrennt voneinander gespeichert wer- 20

36 4 Grundlagen der Datenübernahme aus einem Realsystem in ein Trainingssystem den. Diese ergeben sich aus der Kopplung zwischen der Simulation und den dazugehörigen PLCs. Die Kopplung erfolgt dabei über den sogannenten Shared Memory (Abbildung 4.5). Abbildung 4.5: Prinzip des Datenaustauschs zwischen der Simulation und der SoftPLC s über den Shared Memory Der Shared Memory ist eine Datei, in der die Daten binär gespeichert werden. Aufgrund dieser binären Speicherung ist es nicht möglich zu bestimmen, welche Daten an welche Stelle geschrieben sind und geändert werden müssen. Entsprechend muss die Snapshotmanipulation über die Daten in den PLCs und in der Snapshotdatei von SIMIT realisiert werden (Abbildung 4.6). Es ist dabei sicherzustellen, dass diese dort so lange vorliegen, dass sie durch den weiteren Programmablauf automatisch in den Shared Memory übernommen werden. Abbildung 4.6: Manipulation eines Snapshots durch Änderung der Daten in der Snapshotdatei (SIMIT) und den SoftPLC s Der vollständige Vorgang der Datenübernahme ist in Abbildung 4.7 dargestellt. Daraus lassen sich im folgenden Teilbereiche mit ihren spezifischen Problemstellungen und Anforderungen isolieren. In den folgenden Abschnitten werden die einzelnen Teilbereiche der Datenübernahme noch einmal einzeln beschrieben und auf deren spezifischen Probleme 21

37 4 Grundlagen der Datenübernahme aus einem Realsystem in ein Trainingssystem hingewiesen. Abbildung 4.7: Prinzipielle Darstellung der Realisierung der Datenübernahme im Programm S7-Real2Sim[9][8] Lesen Das Lesen der Daten stellt den ersten Schritt der Datenübernahme dar. Es ist dabei essentiell eine geeignete Auswahl zu treffen, welche Daten für das Initialisieren der Simulation tatsächlich notwendig sind. Werden zu wenige Daten gelesen, kann es zu größeren Abweichung der Simulation von der Realität kommen. Im Gegenzug dazu können zuviele Daten das Automatisierungssystem zu stark belasten, da die Daten in extra Speicher kopiert und aktualisiert werden müssen, um einen konsistenten Datensatz lesen zu können. Das Lesen der Daten selbst muss möglichst performant gelöst werden, um das System durch den Eingriff nicht zu stark zu belasten Exportieren Das Exportieren der Daten ist notwendig, um diese an einem teilweise weit entfernten Ort in das Trainingssystem kopieren zu können. Es ist dabei darauf zu achten, dass neben den Daten selbst auch Parameter gespeichert werden, die Aussagen über deren Qualität und Verwendungsfähigkeit treffen können. Als Beispiel sei hier eine CPU im Betriebszustand STOP aufgeführt, ist dies der Fall, können die Daten korrekt gelesen werden ihre Werte wären auch als gültig gekennzeichnet. Allerdings würde sich der Zeitstempel ihres Ursprungs von dem des restlichen Systems unterscheiden. 22

38 4 Grundlagen der Datenübernahme aus einem Realsystem in ein Trainingssystem Snapshotmanipulation Die Manipulation der SIMIT zugrunde liegenden Snapshotdatei ermöglicht es Komponenten wie z.b. Motoren, Ventile, Pumpen u.ä. in den entsprechenden Betriebszustand zu überführen. Hierfür müssen entsprechende Schnittstellen definiert werden, welche die Funktionen ermöglichen. Entsprechende Konnektoren können in der Datei eindeutig über den Instanznamen der jeweiligen Instanz identifiziert werden. Gleichzeitig müssen diese Mappingmethoden für alle Instanzen eines Typicals Gültigkeit besitzen und flexibel anpassbar sein Schreiben in SoftPLCs Wie bereits erwähnt, ist es nicht möglich die Daten im SharedMemory zu modifizieren. Dementsprechend muss diese Modifikation im SIMIT Snapshot und in den Daten der SoftPLCs realisiert werden. Um dabei sicherzustellen das alle notwendigen Daten in den Shared-Memory übernommen werden, wird der komplette, gelesene Datensatz in die SoftPLCs geschrieben. Neben dieser Initialisierung der Simulationdaten, werden gleichzeitig Parameter des HMI geschrieben. Dazu zählen z.b. Zeitverzögerungen für Meldesignale oder Kennlinienparameter. 23

39 5 Realisierung und Konzeption der Datenübernahme 5 Realisierung und Konzeption der Datenübernahme Die folgenden Abschnitte behandeln die theoretische Konzeption und Realisierung der einzelnen Problemstellungen der Datenübernahme, bevor im darauffolgenden Kapitel 6 auf die praktische Umsetzung im Programm eingegangen wird. 5.1 Lesen der Daten Das Lesen der Daten stellt den ersten Schritt einer erfolgreichen Datenübernahme dar. Es ist hierbei darauf zu achten, alle notwendigen Daten zu erfassen um ein späteres Initialisieren ermöglichen zu können. Zu den Bestandteilen des zulesenden Datensatz gehören in erster Linie alle Instanzen der verwendeten Typicals mit ihren jeweiligen Zuständen und Parametrierungen. Daneben müssen weitere Daten aufgenommen werden, die für die Simulationmodelle benötigt werden. Als Beispiele seien hier die Fahrtgeschwinidgkeit, die Abgastemperaturen oder Wassertemperatur angeführt. Für die grundlegende Konzeption des Lesevorgangs war es zunächst notwendig ein Anforderungsprofil zu entwickeln, anhand dessen die weiteren Entwicklungsarbeit vorangetrieben werden konnte. Die wichtigsten Anforderungen für einen Lesevorgang aus einem PCS-7 Programm bei laufendem Betrieb sind der folgenden Aufzählung zu entnehmen: Der gelesene Datensatz muss konsistent sein, d.h. alle Werte gehören zu genau einem Zeitpunkt, auch über mehrere CPUs hinweg Ein Zugriff auf alle Datentypen soll gewährleistet sein Die zulesenden Daten müssen sorgfältig ausgewählt werden (sogenannte Datensenken) Der Eingriff in das bestehende PCS-7 Programm muss möglichst gering sein Der Lesezugriff muss möglichst perfomant sein, um die Eingriffszeit in das laufende System zu senken Eine Einbettung in die PCS-7 Umgebung muss möglich sein, d.h. es müssen möglichst bereits getestete und freigegebene Komponenten verwendet werden Entwicklung in.net 3.5 und C# 24

40 5 Realisierung und Konzeption der Datenübernahme Tabelle 5.1: Datentypen einer SIMATIC S7-400 Datentypen Speicher Wertebreich Bool 1 Bit true oder false Byte 1 Byte 0x00 bis 0xFF Char 1 Byte ASCII Zeichen z.b.: A,B,C,1,2,3 etc. Int 2 Byte bis Word 2 Byte 0x00 bis 0xFFFF Date 2 Byte D# bis D# S5Time 2 Byte S5T#0H_0M_0S_10MS bis S5T#2H_46M_30S_0MS DWord 4 Byte 0x00 bis 0xFFFF FFFF DInt 4 Byte bis Real 4 Byte Dezimalzahlen mit Punkt Time 4 Byte -T#24D_20H_31M_23S_648MS bis T#24D_20H_31M_23S_647MS TimeOfDay 4 Byte TOD#0:0:0.0 bis TOD#23:59: String max 258Byte Zeichenkette Auf die Punkte des konsistenten Datensatzes und der Möglichkeit zur Einbettung in die PCS-7 Umgebung ist dabei besonderes Augenmerk zu legen. Wenn die Daten in ihrem Zeitstempel zu stark divergieren, ist es nicht mehr möglich den Schiffszustand hinreichend genau wiederzugeben. Die Einbettung in die PCS-7 Umgebung dagegen bedarf langwieriger Verträglichkeitstests, um eine reibungsfreie Koexistenz mit allen anderen Softwarekomponenten garantieren zu können. Eine Verwendung bereits freigegebener Komponenten würde diesen Prozess erheblich beschleunigen. Da das bestehende Steuerungsprogramm mit Hilfe der Typicals aus der CIS-CK-Bibliothek aufgebaut wurde, ist es möglich die Daten größtenteils sturkturiert zu lesen. Zunächst muss für jedes Typical entschieden werden, welche Datensenken benötigt werden. Anhand dieser Auswahl kann eine UDT erstellt werden, dabei handelt es sich um einen abstrakten, strukturierten Datentyp. Entscheidend hierbei ist, dass der Lesezugriff nicht auf alle Datensenken gleichermassen möglich ist. Wie bereits in Kapitel 3.1 beschrieben, besteht das PCS-7 Programm für jedes Typical aus mehreren CFC-Plänen. Diese wiederum beinhalten verschiedene Baustein, welche für die letztendliche Logik verantwortlich sind. Der Zugriff auf einzelne Datensenken ist allerdings nur auf FBs bzw. deren Instanzdatenbausteine möglich. Ein Lesen und Zurückschreiben aus bzw. in FCs dagegen ist nicht ohne weitere Eingriffe in das originäre Programm möglich. Stattdessen müssen diese Werte teilweise aus anderen Zuständen interpoliert werden. Für die Datensenken gelten die elementaren Datentypen die im Bereich PCS-7 vorhanden sind ( 5.1). 25

41 5 Realisierung und Konzeption der Datenübernahme Für die weitere Entwicklung musste zunächst ein geeignetes Zugriffsverfahren gefunden werden, dass dem Anforderungsprofil entspricht Auswahl des Zugriffverfahrens Da heutige Automatisierungssysteme viel mehr Aufgaben bewältigen als das alleinige Steuern und Regeln eines Prozesses ist es zunehmend von Bedeutung die Daten aus einer Steuerung zu lesen, um sie für weitere, übergeordnete Prozesse nutzbar zu machen. Demzufolge existiert heute auch eine hohe Vielfalt an verschiedenen Möglichkeiten, welche dieses Lesen von Daten ermöglichen. Nachfolgend sei eine kurze Auswahl verschiedener Methoden dargestellt: Libnodave Accon-AGLink OPC DA 2.0 S7 Programmierschnittstelle Siemens ProDave OpenTCP/BSEND Da das Programm zur Datenübernahme in der Programmiersprache C# entwickelt werden soll, bedarf es einer Schnittstelle zum Lesen der Daten, welche das.net Framework unterstützt. Aus diesem Grund wurden die weiteren Untersuchungen im Wesentlichen auf die ersten drei Varianten beschränkt. Die nachfolgenden Kapitel erläutern kurz die einzelnen Schnittstellen. Zudem werden die Messwerte der Lesegeschwindigkeit für verschiedene Datengrößen dargestellt, um anschliessend die Verfahren miteinander vergleichen und bewerten zu können. Für diese Tests wurde ein eigenes Programm entwickelt, welches Daten unterschiedlicher Größe von einer PLC mittels dieser Zugriffsverfahren lesen kann. Für jedes Verfahren wurde eine Testreihe von 1 bis 30 kb in 1kB Schritten angefertigt. Die Messung wurde dabei für jeden Messpunkt fünfmal durchgeführt, um anschliessend das arithmetische Mittel bestimmen zu können Libnodave Bei Libnodave handelt es sich um ein OpenSource Projekt zum Lesen und Schreiben von Daten von einer PLC, speziell einer SIMATIC S7-400 oder SIMATIC S Das Paket ist auf der Internetseite erhältlich und unter der General Purpose License (GPL), sowie Lesser General Public License (LGPL) lizensiert. 26

42 5 Realisierung und Konzeption der Datenübernahme Die Verbindung von einem PC zur PLC kann dabei via Multi Point Interface (MPI) oder Ethernet erfolgen. Die aktuelle Version ( ) erlaubt die Verwendung der Bibliothek sowohl unter Windows als auch Linux Betriebssystemen. Als unterstützte Programmiersprachen wurden von den Entwicklern folgende angegeben: C C++ C# Delphi Pascal Pearl Visual Basic Für den Lese- bzw. Schreibvorgang muss zunächst ein Objekt daveconnection angelegt, initialisert und parametriert werden. Als Parameter wird unteranderem die IP-Adresse, die Nummer des Racks und des Slots der Steuerung angegeben. Über dieses Objekt kann die Funktion int daveconnection.readbytes(int area, int DBnumber, int start, int length, byte[] buffer) zum Lesen der Daten aufgerufen werden. Die Erklärung zu den einzelnen Parameter befindet sich in Tabelle 5.2. Tabelle 5.2: Parameter und ihre Bedeutung der Funktion daveconnection.readbytes() Parameter area DBnumber start length buffer Erklärung Eine Konstante die den Speicherbereich der SPS spezifiziert Die Nummer des Datenbausteins, aus dem gelesen werden soll Die Addresse des ersten Bytes das gelesen werden soll Die zu lesende Anzahl an Bytes Pointer auf den Speicher, in den das Ergebnis gelesen werden soll Die Mittelwerte der Messungen für der Lesegeschwindigkeit befinden sich in Tabelle 5.3. Diese beruhen auf den in Anhang A.1 dargestellten Messwerten. 27

43 5 Realisierung und Konzeption der Datenübernahme Tabelle 5.3: Mittelwerte in Sekunden für das Lesen von Daten unterschiedlicher Größe unter Verwendung von Libnodave Datengröße [kb] Mittelwert [s] Varianz Standardabweichung 1 0,084 0,0001 0, ,138 0,0002 0, ,194 0,0004 0, ,241 0,0003 0, ,297 0,0004 0, ,344 0,0010 0, ,388 0,0002 0, ,428 0,0001 0, ,481 0,0002 0, ,575 0,0016 0, ,616 0,0008 0, ,669 0,0009 0, ,681 0,0003 0, ,747 0,0012 0, ,825 0,0008 0, ,878 0,0043 0, ,931 0,0003 0, ,966 0,0001 0, ,056 0,0032 0, ,087 0,0002 0, ,197 0,0020 0, ,219 0,0031 0, ,269 0,0009 0, ,278 0,0042 0, ,378 0,0048 0, ,369 0,0028 0, ,500 0,0028 0, ,522 0,0006 0, ,587 0,0028 0, ,672 0,0020 0, Accon AGLink Bei der Kommunikationsbibliothek Accon AGLink handelt es sich um die zweite Möglichkeit, Daten aus einer PLC zu lesen. Die Bibliothek wurde von der Firma Deltalogic entwickelt und ist auf der zugehörigen Internetseite ( in einer Demoversion verfügbar. Mit dem Paket verfügt der Anwender über eine breite Palette an Anwendungsgebieten. Es unterstüzt neben der SIMATIC S7-400er und 300er Reihe noch eine Vielzahl weiterer Geräte, darunter auch ältere SIMATIC-S5 Steuerungen. Zudem ist auch das Spektrum an Verbindungswegen breit gefächert. Neben der hier bevorzugten Methode des Ethernets 28

44 5 Realisierung und Konzeption der Datenübernahme ist der Zugriff auch via MPI, PROFIBUS, PPI, Teleservice und weiteren möglich. Ein weiterer Punkt der diese Bibiliothek für die Verwendung im Rahmen dieser Diplomarbeit interessant macht sind die unterstützten Programmiersprachen. Nachfolgend ist ein kurzer Auszug der Möglichkeiten dargestellt. Borland Delphi, C++ Builder Labview Java Microsoft Visual C/C++, Microsoft Visual Basic, Microsoft C# Verwendung Die wichtigsten Parameter für die Verbindung (IP-Adresse, Rack, Slot etc.) werden in einer Konfigurationsdatei definiert. Diese muss im Programmcode zunächst geladen werden: AGL4.SetParaPath(path); Danach ist es möglich ein neues Objekt für eine Verbindung anzulegen: ag1 = AGL4ConnectionFactory.CreateInstance(devnr, plcnr,timeout); Da es möglich ist mehrere Geräte anzusprechen werden diese über eine ID (devnr) addressiert. Über die Funktion Connect() dieses Objekts kann nun die Verbindung zur Steuerung selbst aufgebaut werden. Nachdem die Verbindung erfolgreich aufgebaut wurde lassen sich Daten über den Aufruf: AGL4.ReadDataBytes(devnr, sdbnr, startadr, len, buffer, timeout); gelesen werden. Die gelesenen Werte werden in einem Buffer vom Typ Byte[] abgelegt. Nachfolgend sind in Tabelle 5.4 die Mittelwerte der Lesegeschwindigkeiten dargestellt. 29

45 5 Realisierung und Konzeption der Datenübernahme Tabelle 5.4: Mittelwerte in Sekunden für das Lesen von Daten unterschiedlicher Größe unter Verwendung von AcconAGLink Datengröße [kb] Mittelwert [s] Varianz Standardabweichung 1 0,078 0,0001 0, ,103 0,0002 0, ,153 0,0002 0, ,172 0,0003 0, ,222 0,0002 0, ,256 0,0003 0, ,297 0,0004 0, ,335 0,0002 0, ,363 0,0005 0, ,409 0,0012 0, ,425 0,0004 0, ,485 0,0009 0, ,494 0,0010 0, ,566 0,0019 0, ,572 0,0013 0, ,616 0,0008 0, ,672 0,0043 0, ,666 0,0014 0, ,750 0,0035 0, ,775 0,0012 0, ,794 0,0004 0, ,841 0,0031 0, ,894 0,0046 0, ,953 0,0020 0, ,956 0,0026 0, ,972 0,0040 0, ,972 0,0016 0, ,094 0,0028 0, ,150 0,0021 0, ,122 0,0016 0, OLE for Process Control (OPC) Im Gegensatz zu den bereits behandelten Verfahren, erfolgt der Datenzugriff bei OPC nicht direkt vom Programm auf die PLC. Wie in Kapitel 3.5 beschrieben, dient OPC in erster Linie dazu den Zugriff auf Systeme unterschiedlicher Hersteller zu ermöglichen. Aus diesem Grund erfolgt die Verbindung vom Programm zu einer PLC über einen zwischengeschalteten OPC-Server. Entsprechend wird im Programmcode zunächst ein Server-Objekt vom Typ Opc.Da.Server benötigt. 30

46 5 Realisierung und Konzeption der Datenübernahme public Opc.Da.Server Server = new Opc.Da.Server(new OpcCom.Factory(), null); Da der OPC-Server nicht zwingend auf dem gleichen Computer betrieben wird auf dem auch der Client installiert ist, muss zusätzlich die Adresse definiert werden. public Opc.URL OPCServerURL = new Opc.URL(opcda://OSS01/OPC.Simatic.NET); Der Verbindungsaufbau erfolgt über den Aufruf: Server.Connect(OPCServerURL, new Opc.ConnectData(new System.Net.NetworkCredential())); Ab diesem Zeitpunkt ist eine Verbindung vom OPC-Client zum OPC-Server aufgebaut. Für den Zugriff auf die Werte der PLC wird ein Array vom Typ OPC.Da.Item[] erstellt. Opc.Da.Item[] item = new Opc.Da.Item[1]; Die Adressierung der Variablen erfolgt über die Eigenschaft ItemName der Array-Elemente (Abbildung 5.1). Abbildung 5.1: Adressierung der Variablen über die Eigenschaft ItemName item[0].itemname = S7:[OSS01_PCU1_OPC],DB693,INT,52,1 Der Aufruf der Leseoperation erfolgt über das Server-Objekt. Wobei der Rückgabewert in ein Array vom Typ Opc.Da.ItemValueResult[] gespeichert wird. result = Server.Read(item); Opc.Da.ItemValueResult[] result = new Opc.Da.ItemValueResult[1]; Die Länge der Arrays item und result muss identisch sein. Der gelesene Wert wird dabei in der Eigenschaft Value hinterlegt. Die Eigenschaft ResultID gibt Auskunft ob die Operation für diesen Wert erfolgreich war. result[0].value, result[0].resultid 31

47 5 Realisierung und Konzeption der Datenübernahme Tabelle 5.5: Mittelwerte in Sekunden für das Lesen von Daten unterschiedlicher Größe unter Verwendung von OPC DA 2.0 Datengröße [kb] Mittelwert [s] Varianz Standardabweichung 1 0,028 0,0002 0, ,044 0,0001 0, ,063 0,0000 0, ,084 0,0001 0, ,115 0,0001 0, ,134 0,0001 0, ,156 0,0001 0, ,169 0,0001 0, ,203 0,0007 0, ,215 0,0002 0, ,250 0,0001 0, ,266 0,0006 0, ,278 0,0002 0, ,295 0,0011 0, ,325 0,0000 0, ,350 0,0003 0, ,362 0,0001 0, ,387 0,0002 0, ,394 0,0013 0, ,431 0,0002 0, ,447 0,0001 0, ,475 0,0001 0, ,481 0,0001 0, ,513 0,0002 0, ,547 0,0007 0, ,516 0,0009 0, ,575 0,0002 0, ,616 0,0011 0, ,625 0,0001 0, ,644 0,0011 0,0337 Für einen erfolgreichen Lesezugriff gilt: ResultID = ResultID.S_OK Die Mittelwerte der Lesegeschwindigkeit für verschiedene Datengrößen sind in Tabelle 5.5 aufgelistet. 32

48 5 Realisierung und Konzeption der Datenübernahme Bewertung und Auswahl Um die drei Methoden besser gegeneinander abzuwägen, wurden wie im vorhergehenden Abschnitt bereits beschrieben Geschwindigkeitstest durchgeführt. Die Ergebnisse dieser Untersuchung sind in der Abbildung 5.2 dargestellt. Abbildung 5.2: Messergebnisse der Messungen der Zugriffszeiten für verschiedene Zugriffsmethoden und Datengrößen. Dargestellt sind dabei die Mittelwerte mit ihrer dazugehörigen Standardabweichung Grundsätzlich ist nach den ersten Erfahrungen mit den drei Varianten davon auszugehen, dass eine Realisierung der Aufgabenstellung mit allen möglich ist. Eine einfache Adressierung und Implementierung ist dabei allen Varianten gemein. Die Auswahl der Zugriffsmethode ist daher anhand anderer Gesichtspunkte zu treffen. Zu allererst wurden daher die Lesegeschwindigkeiten herangezogen. Durch eine Auswertung der Graphen ist ersichtlich, dass der OPC Standard die besten Ergebnisse erzielte. Besonders die Lesegeschwindigkeit von einem realen System besitzt eine immense Bedeutung. Die zusätzliche Belastung in Folge des Lesevorgangs sollte so gering wie möglich gehalten werden, da hier immerhin auf sicherheitsrelevante Systeme zugegriffen wird. Durch den Zugriff kann die Zykluszeit steigen. Eine Erhöhung dieser auf einem realen Schiff kann im allerschlimmsten Fall verherrende Wirkungen haben, sobald die Echtzeitbedingung nicht mehr eingehalten werden kann. Ein weiterer Vorteil des OPC-Standards ist, dass der OPC-Server bereits in dem Paket SIMATIC Net enthalten ist und einfach auf den OS projektiert werden kann. Aus diesen Gründen viel die Entscheidung zu Gunsten des OPC DA Standards. Die Vorteile sollen im folgenden noch einmal kurz aufgeführt werden: 33

49 5 Realisierung und Konzeption der Datenübernahme höhere Lesegeschwindigkeiten beim Lesen einer realen CPU und damit verbunden ein kürzeres Eingreifen in sicherheitsrelevante Systeme bereits im Rahmen von SIMATIC Net verfügbar OPC-Server können einfach und komfortabel über die Hardwarekonfiguration des Projekts projektiert werden gut dokumentierte Schnittstelle Verwendung in Kombination mit.net und C# möglich Anpassungen in PCS-7 Es besteht die Anforderung den Eingriff in das bestehende PCS-7 Projekt so gering wie möglich zu halten. Der volle Funktionsumfang der Datenübernahme ist ohne Änderungen im bestehenden Projekt allerdings nicht möglich. Die notwendigen Erweiterungen sind exemplarisch für eine Instanz in der Abbildung 5.3 dargestellt. Abbildung 5.3: Erweiterung des bestehenden PCS-7 Projekts für die Datenübernahme (Lesen aus dem Realsystem) Auf der linken Seite der Abbildung befinden sich die Instanzdatenbausteine eines PCS-7 Typicals welche die erforderlichen Datensenken enthalten. Die rechte Bildseite enthält die für die Datenübernahme notwendigen Erweiterungen. 34

50 5 Realisierung und Konzeption der Datenübernahme Im normalen Betrieb übernimmt dabei der R2S_FC_PROG die benötigten Daten aus den Instanzdatenbausteinen des Typicals und schreibt diese in einen so genannten Schatten- DB, in diesem Fall der R2S_DB_TYPE_ANA. Die Funktion des FCs wird durch einen weiteren DB (R2S_DB_PROG_HANDLER) gesteuert. In diesem sind spezielle Steuerbits angelegt, über welche das zyklische Schreiben in die Schatten-DBs aktiviert bzw. deaktiviert werden kann. Im normalen Betrieb werden die Daten in jedem Zyklus des Programmablaufs aktualisiert im Schatten-DB abgelegt. Wird ein Lesevorgang von außen gestartet, wird zunächst das entsprechende Bit im R2S_DB_PROG_HANDLER deaktiviert. Der FC aktualisiert daraufhin die Werte nicht mehr, wodurch ein konsistenter Datensatz vorliegt, der im Folgenden durch das Programm gelesen werden kann. In den folgenden Abschnitten wird die Konzeption der einzelnen Komponenten und deren Verwendung näher erläutert UDTs Eine User Defined Type (UDT) ist ein abstrakter Datentyp, der Variablen eines gleichen oder verschiedener Typen zu einem neuen Datentyp zusammenfasst. Für jedes PCS-7 Typical wird eine solche UDT erstellt. Darin werden alle Datensenken mit ihrem jeweiligem Datentyp definiert. Der Einsatz dieser Strukturen ermöglicht ein einfaches Wiederverwenden für alle Instanzen dieses Typicals. Abbildung 5.4: Beispiel für die Definition einer UDT (Typical: MAS_BIN_STD) Die Abbildung 5.4 zeigt beispielhaft die Definition einer UDT für ein PCS-7 Typical. Der erste Eintrag der UDT ist stets der Header. Der Typ des Header ist wiederum eine UDT, welche einen String für den Instanznamen beinhaltet. Der Instanzname, oder auch Tag-Name, ist im PCS-7 Projekt eindeutig, dementsprechend existiert immer nur genau eine Instanz mit diesem Namen und kann über diesen identifiziert werden. 35

51 5 Realisierung und Konzeption der Datenübernahme Nach dem Tag-Name folgen die Datensenken. Da sich diese in unterschiedlichen Instanzdatenbausteinen befinden können, werden die Elemente eines dieser DBs immer zusammengefasst. Zunächst wird der Name des Instanz-DBs (in Abbildung 5.4: INST_DB1) in einer Integer-Variable gespeichert, darauf folgen die dazugehörigen Datensenken. Die Kombination aus dem Namen des Instanz-DBs und seinen zugehörigen Daten wird dabei für jeden weiteren Instanz-DB der UDT wiederholt Schatten-Datenbausteine Die Schatten-DBs, oder auch Shadow-DBs genannt, besitzen die Aufgabe eines Zwischenspeichers für die Daten. Sie werden im normalen Programmablauf mit jedem Zyklus aktualisiert. Die Aktualisierung wird nur im Falle eines Schreib- bzw. Lesezugriffs angehalten. Sobald die Aktualisierung durch den FC unterbrochen ist, kann ein Lesevorgang gestartet werden. Der gelesense Datensatz kann als konsistent angenommen werden, unter der Bedingung dass sich alle PLCs im Betriebszustand RUN befinden und der FC für alle Instanzen fehlerfrei initialisiert wurde. Abbildung 5.5: Aufbau eins Schatten-DBs am Beispiel des Typicals MAS_BIN_STD Tabelle 5.6: Aufbau der UDT R2S_UDT_TYPE_HEADER Variable Datentyp Erklärung CIS_CK_VERSION STRING[16] Verwendete Version von CIS_CK INST_TYPE INT Identifikationsnummer für das Typical INST_COUNTER DINT Anzahl der Instanzen in diesem DB INST_LENGTH DINT Länge einer Instanz in Byte INST_OFFSET DINT Speicheradresse in Byte der ersten Instanz ERROR_IN_DB Byte Byte für Fehlermeldungen Der Aufbau eines Schatten-DBs ist in Abbildung 5.5 beispielhaft für ein Typical vom Typ MAS_BIN_STD dargestellt. Der prinzipielle Aufbau ist für alle DBs identisch. Der Header ist vom Typ R2S_UDT_TYPE_HEADER dessen Struktur in Tabelle 5.6 dargestellt ist. Nach dem Header folgt ein Array mit der Länge n, wobei n gleich der Anzahl der Instanzen und der Typ die UDT des entsprechenden Typicals ist. Für jedes Typical wird dabei ein eigener Schatten-DB mit der dazugehörigen UDT angelegt. Die Auswahl der hier eingefügten Datensenken ist entscheidend für die Qualität und Genauigkeit der Simulation. Allerdings muss an dieser Stelle auch bedacht werden, dass Werte 36

52 5 Realisierung und Konzeption der Datenübernahme teilweile gelesen aber nur eingeschränkt geschrieben werden können. Prinzipiell können nur Datensenken von Funktionsbausteinen (FB) in die Schatten-DBs geschrieben werden 2, handelt es sich dabei um Eingänge so werden diese bedingt durch den normalen Programmablauf aufgrund der vorangestellten Verschaltung überschrieben. Eine Verwendung dieser Datensenken muss daher dringend geprüft werden, eventuell bedarf es hier einen erhöhten Eingriff in die originalen Steuerungsprogramme. Da nicht alle benötigten Daten einer PLC typicalspezifisch sind, bedarf es der Möglichkeit diese restlichen Daten ebenfalls in einen Schatten-DB schreiben zu können. Für diese Anwendung existieren sogenannte Special-DBs. Deren Aufbau ist deutlich einfacher gehalten. Es existieren weder Headerinformationen noch eine eigene UDT. Stattdessen werden die Variablen mit ihren jeweiligen Datentypen manuell eingetragen (Abbildung 5.6). Abbildung 5.6: Beispiel für die Definition eines SpecialDBs R2S_FC_PROG Der R2S_FC_PROG ist ein in SCL geschriebener Funktionsbaustein und das funktionale Zentralelement auf PCS-7 Seite für die Datenübernahme. Er übernimmt verschiedene Aufgaben von der Initialisierung der Anbindung zu dem Schatten-DB, bis hin zu dessen Aktualisierung. In Abbildung 5.7 ist ein solcher FC in einem CFC-Plan eines PCS-7 Typicals dargestellt. Für die Verwendung des FCs müssen zunächst einige der Anschlüsse verbunden werden. Darunter fallen die Anschlüsse ENABLE (Baustein aktiviert oder deaktiviert), IN- IT_EXT (erzwingt eine Initialisierung des Bausteins von außen), HNDL_DB (Verweis auf R2S_DB_PROG_HANDLER), TYPE_DB (Verweis auf den Schatten-DB dieses Typicals) und die ANY-Pointer. Letztere stellen die Verbindung vom FC zu den Instanz- 2 Der FC R2S_FC_PROG greift über ANY-Pointer auf Daten der Instanz-Datenbausteine der FBs zu 37

53 5 Realisierung und Konzeption der Datenübernahme datenbausteinen der FBs her. Abbildung 5.7: Beispiel für einen eingebundenen R2S_FC_PROG in einem PCS-7 Typical R2S_DB_PROG_HANDLER Der R2S_DB_PROG_HANDLER dient als Schnittstelle zur Steuerung des R2S_FC_PROG von aussen. Er enthält spezielle Steuerbits über die Einfluss auf das aktuelle Verhalten des FCs genommen werden kann. Sein Aufbau ist in Tabelle 5.7 dargestellt. Tabelle 5.7: Aufbau des UDT R2S_DB_PROG_HANDLER Variable Datentyp Erklärung CYCLIC_ACTIVE Bool Zyklisches Schreiben der Daten in die Schatten-DBs an/aus READING_ACTIVE Bool Lesender Zugriff auf die Schatten-DBs von aussen WRITING_ACTIVE Bool Schreibender Zugriff auf die Schatten-DBs von aussen TAKEOVER_IMPULSE Bool Kommando zur Übernahme der Daten aus den Schatten-DBs INIT_IMPULSE Bool Initialisiere alle FCs neu LIFECOUNTER Byte Wird CYCLIC_ACTIVE von aussen auf false gesetzt, muss dieses Byte sekündlich inkrementiert werden. Ist dies nicht der Fall, kehrt das PCS-7 Programm nach acht Sekunden automatisch in seinen normalen Betrieb zurück 38

54 5 Realisierung und Konzeption der Datenübernahme Abbildung 5.8: Ablaufdiagramm für die Werte des R2S_DB_PROG_HANDLER im Falle eines Lesezugriffs Für den Fall eines Lesevorgangs muss folgende Reihenfolge eingehalten werden (Abbildung 5.8). Zunächst wird das Bit CYCLIC_ACTIVE auf false gesetzt. Dadurch wird ein weiteres Aktualisieren der Schatten-DBs durch den FC verhindert (konsistenter Datensatz). Daraufhin muss über eine Routine das Byte LIFECOUNTER sekündlich inkrementiert werden. Wird dieser Wert nicht innerhalb von acht Sekunden erhöht, kehrt der FC in seinen Normal-Betrieb zurück und beginnt wieder damit die Werte in den Schatten-DBs mit jedem Zyklus zu Aktualisieren. Sobald die Routine für den LIFECOUNTER gestartet ist, wird das Bit READING_ACTIVE auf true gesetzt. Dem FC wird damit signalisiert, dass ein lesender Zugriff auf die Schatten-DBs stattfindet. Erst jetzt kann der eigentliche Lesevorgang gestartet werden. Nach Beendigung des Lesezugriffs wird zunächst READING_ACTIVE zurück auf false gesetzt. Danach kann die Routine des LIFECOUNTERs beendet werden. Als letzter Schritt folgt das Zurücksetzen des CYCLIC_ACTIVE Bits. Der FC kehrt damit in seinen normalen Betrieb zurück und die Daten in den Schatten-DBs werden wieder aktualisiert. 39

55 5 Realisierung und Konzeption der Datenübernahme 5.2 Exportieren der Daten Das Exportieren der Daten entspricht letztendlich dem Abspeichern in eine Datei, um sie anschliessend an einem entfernten Ort nutzen zu können. Dabei ist darauf zu achten, dass alle nötigen Paramemter mit exportiert werden. Dazu gehören Informationen über die Qualität des Datensatzes, d.h. befanden sich zu diesem Zeitpunkt alle PLCs im Betriebszustand RUN, konnten alle Daten korrekt gelesen werden, etc.. Das Exportieren der Daten erfolgt in die, dem Programm zu Grunde liegenden, Konfigruationsdatei. Dadurch muss lediglich eine einzige Datei an das Trainingssystem übertragen werden. Die exakte Funktionsweise des Datenexports ist in Kapitel beschrieben. 5.3 Initialisieren der Simulation Die Problemstellung der Initialisierung der Simulation lässt sich in zwei Teilbereiche aufteilen (siehe Abbildung 4.6). Zunächst muss das Simulationsprogramm SIMIT mit all seinen Komponenten und Modellen entsprechend initialisiert werden, bevor in einem weiteren Schritt die Datensenken auf den SoftPLCs entsprechend des vorliegenden Datensatzes verändert werden Initialisierung von SIMIT Abbildung 5.9: Das Initialisieren des Snapshots stellt den ersten Schritt der Datenübernahme auf einem Trainingssystem dar Um die Modelle der Simulation entsprechend dem Datensatz zu initialisieren, bedarf es erneut zweier Schritte. Zunächst müssen die Werte in der Snapshot-Datei verändert werden - das sogenannte Mapping - damit die Komponenten der Simulation mit den neuen Prozesswerten und Zuständen arbeiten. Zudem ist es notwendig die Modelle anhand der aktualisierten Prozesswerte zu initialisieren. So existieren in der Regel Prozessgrößen deren Werte anhand von Kennlinien oder Verzögerungsgliedern aus den Zuständen der Typicals berechnet werden. Die entsprechenden Grundlagen werden in den folgenden Kapiteln behandelt. 40

56 5 Realisierung und Konzeption der Datenübernahme Tabelle 5.8: Die Grundfunktionen für das Mapping in eine Snapshotdatei Bezeichnung Parameter Erklärung Assignment description, destination Schreibt den Wert einer Variable (UDT) an eine spezifizierte Stelle im Snapshot Assignment.Log term, destination Wertet einen, unter term definierten, logischen Ausdruck aus und schreibt das Ergebnis an die spezifizierte Stelle im Snapshot Assignment.Log.Set condition, destination, set Unter der Bedingung das der unter condition definierte Ausdruck true ergibt, wird der Wert von set an die spezifizierte Stelle im Snapshot geschrieben. set kann dabei einen logischen Ausdruck enthalten Assignment.Log.Calculate condition, destination, set Ist die Bedingung von condition erfüllt, wird der Wert von set an die spezifizierte Stelle im Snapshot geschrieben. set kann dabei einen mathematischen Ausdruck enthalten Mapping in das Snapshotfile Das sogenannte Mapping bezeichnet das gezielte Verändern einzelner Werte in einer Snapshotdatei. Mit dieser Methode können Prozesswerte und Zustände der Simulation mit den Werten aus dem realen System ersetzt werden. Das Mapping orientiert sich dabei im Wesentlichen an den verschiedenen Typicals. Entsprechend müssen für jedes Typical geeignete Mappingfunktion entworfen werden, um die benötigten Werte in die Snapshotdatei schreiben zu können. Diese Methoden müssen dabei für jede Instanz des jeweiligen Typicals gültig sein. Um dies realisieren zu können, wurden vier Grundfunktionen für das Mapping erstellt. Eine Übersicht über diese ist in Tabelle 5.8 enthalten. Die logischen Ausdrücke können dabei sowohl mit den Variablen der UDTs als auch Werten aus dem Snapshot gebildet werden. 41

57 5 Realisierung und Konzeption der Datenübernahme Tabelle 5.9: Mappingfunktionen für die Manipulation typicalunabhängiger Daten Bezeichnung Parameter Erklärung Set description, destination Schreibt den Wert einer Variable (UDT) an eine spezifizierte Stelle im Snapshot Set.Log condition, destination Ist der unter condition angegebene logische Ausdruck true, wird das Ergebnis eines weiteren, unter set definierten logischen Ausdruck in den Snapshot geschrieben Set.Log.Calculate condition, destination, set Funktioniert analog zu Set.Log mit dem Unterschied das der unter set definierte Ausdruck mathematischer Natur ist Mapping allgemeiner Daten Für das Mapping von Daten die typicalunabhängig sind existieren drei weitere Mappingfunktionen (Tabelle 5.9). Mit diesen lassen sich sowohl konstante Werte, aber auch komplexe Ausdrücke auswerten und an beliebige Stellen in der Snapshot-Datei schreiben. Die Werte für die mathematischen und logischen Ausdrücke können dabei Konstanten, Werte aus dem Snapshot selbst, oder spezifische Werte aus dem gelesenen Datensatz sein. Die Definition Letzterer erfolgt z.b. über [INST_NAME:VAR_NAME] wobei der Instanzname gefolgt von einem Doppelpunkt und dem eigentlichen Variablennamen in eckigen Klammern angegeben wird (siehe auch Kapitel 6.2.3) Übernahme der Daten in SIMIT Für das SIMIT-interne Mapping wurde ein globaler Wert mit dem Namen SIMIT_start_Impuls eingeführt. Dieser Wert wird in jedem manipulierten Snapshot auf 1 gesetzt und signalisiert damit der Simulation das die neuen Werte und Zustände zu übernehmen sind. <Set destination= SIMIT/Startimpuls#1/8/Z_STATE set= 1 comment= /> Dieser Wert wird für zwei Sekunden gehalten, bevor er auf 0 zurückgesetzt wird und die Simulation wieder in ihren normalen Betrieb übergeht. Um die Manipulationsroutinen der Snapshot-Datei zu vereinfachen, wurden einige Mappingfunktionen in SIMIT 42

58 5 Realisierung und Konzeption der Datenübernahme ausgelagert. Dafür wurden die betroffenen SIMIT-Typicals durch weitere Anschlüsse modifiziert (Abbildung 5.10). Diese tragen zur einfacheren Erkennung den Teilstring R2S in ihrem Namen (z.b.: R2S1d1v). Die Grundidee dieser Anschlüsse liegt in der Definition Abbildung 5.10: Beispiel für das Mapping innerhalb von SIMIT (Typical: Val1D) der möglichen Zustände eines Typicals. So hat ein MAS_VAL_1D Typical (einfaches Ventil) z.b. die Zustände AUF und ZU. Für jeden dieser Zustände wird ein eigener bool scher Eingang hinzugefügt (Tabelle 5.10 und Abbildung 5.10). Tabelle 5.10: Zustände und die entsprechenden Anschlüsse eines Typicals am Beispiel für ein MAS_VAL_1D Zustand ZU AUF Lokaler Betrieb Fehler R2Sset Anschluss R2S0d0v R2S1d1v R2Sloc R2Sfault Eingang für den SIMIT_start_Impuls Die Werte dieser Anschlüsse sind in der Snapshot-Datei abgelegt und können dementsprechend über die bereits bekannten Mappingfunktionen manipuliert werden. Das Programm für die Datenübernahme muss der Simulation lediglich den Zustand des jeweiligen Typicals über diese Anschlüsse mitteilen. Die notwendigen Modifikationen der Parameter, Zustände und Feedbackmeldungen erfolgt über das zyklische Verhalten der SIMIT- 43

59 5 Realisierung und Konzeption der Datenübernahme Typicals (Abbildung 5.11). Abbildung 5.11: Beispiel für das Übernehmen der neuen Zustände durch das zyklische Verhalten des Typicals (Typical: Val1D) Sobald der Wert von SIMIT_start_Impuls (Eingang R2Sset) gleich 1 ist, wird das normale Verhalten des Typicals unterbrochen. Stattdessen werden die Parameter für den jeweiligen Zustand angepasst (R2S0d0v oder R2S1d1v). Da sich das zyklische Verhalten des Typicals teilweise an den Werten des vorangegangenen Zyklus orientiert, müssen diese für einige Zyklen gehalten werden bevor die Simulation in ihren normalen Betrieb zurückkehren kann in Abbildung 5.11) Initialisieren der SIMIT Prozessmodelle Die Prozessmodelle der Simulation bestehen zum Einen aus den bisher angesprochenen Typicals, dies können z.b. Pumpen, Ventile und Analogwerte sein. Für die Simulation eines Prozesses werden diese anhand physikalischer Gesetzte miteinander verschaltet (Abbildung 5.12). So können z.b. die Druck- und Temperaturverläufe in einem System simuliert werden. Die Kopplung erfolgt in den Plänen der Prozesssimulation. Allerdings ist hierbei darauf zu achten, dass viele dieser Zwischengrößen mit Hilfe von Verzögerungsgliedern oder Kennlinien berechnet werden. Allein die Typicals in ihren gewünschten Zustand zu versetzten reicht daher für die Datenübernahme nicht aus. Je nach Komplexität des Prozessmodells bedarf es hier weiterer Anpassungen. Diese lassen sich nur schwer verallgemeinern. Eine 44

60 5 Realisierung und Konzeption der Datenübernahme genaue Analyse das verwendeten Modells ist also in jedem Fall erforderlich. Abbildung 5.12: Beispiel für ein Prozessmodell, dargestellt ist ein Teil eines Kühlsystems für Dieselmotoren Prinzipiell steht dem Anwender das Signal SIMIT_start_Impuls zur Verfügung. Dieses kann i.d.r. mit dem SET Eingang der Bausteine wie z.b. einem Integrierer oder einem PT1-Glied verschaltet werden. Durch entsprechende, vorangestellte Berechnungen eines geeigneten SetPoints können bei der Initialisierung der Simulation (SIMIT_start_Impuls = 1 ) die adequaten Werte direkt übernommen werden. Abbildung 5.13: Beispiel für das Anbinden des SIMIT_start_Impuls Signals an ein Integrierer bzw. PT-n Glied Übertragen der Daten in die SoftPLCs Das Schreiben der Daten in die SoftPLCs ist der zweite Schritt einer erfolgreichen Datenübernahme in das Trainingssystem. Hierbei werden alle Daten in die entsprechenden Schatten-DBs der SoftPLCs geschrieben und anschliessend vom FC R2S_FC_PROG in 45

61 5 Realisierung und Konzeption der Datenübernahme die entsprechenden Instanz-DBs übertragen. Das Schreiben erfolgt dabei eins zu eins zu den gelesenen Daten. Es wird also nicht unterschieden welche Daten nach der Übernahme tatsächlich benötigt werden bzw. verfügbar bleiben 3. Während die Snapshotmanipulati- Abbildung 5.14: Das Übertragen der Daten auf die SoftPLCs dient der Anpassung der Parametrierung der Typical-Instanzen on hauptsächlich der Initialisierung der Komponenten dient, werden durch das Schreiben der Daten auf die SoftPLCs in erster Linie die Parameter, die über das HMI eingestellt werden können, gesetzt. Dazu gehören z.b. Schwellenwerte für Alarmmeldungen, Zeitverzögerungen für Alarme oder Ersatzwerte. Der Schreibevorgang orientiert sich dabei im wesentlichen am bereits bekannten Lesevorgang, allein die Richtung des Datenfluß ist umgekehrt Schatten-Datenbausteine Resultierend aus der Tatsache dass die Steuerungsprogramme der realen Anlage und des Trainingssystem in den wesentlichen Teilen identisch sind, existieren in den SoftPLCs der Trainingsanlage die gleichen Schatten-DBs wie auf dem realen System. Auch der Aufbau der Schattendatenbausteine ist dabei identisch (UDT). Entsprechend können die Datensenken des gelesenen Datensatzes eins zu eins auf die Trainingsanlage übertragen werden R2S_FC_PROG Mit dem FC R2S_FC_PROG ist es möglich die Inhalte der Schatten-DBs zurück in die Instanz-Datenbausteine zu schreiben. Auch in diesem Fall wird der FC über die Steuerbits des R2S_DB_PROG_HANDLER gesteuert (Abbildung 5.16). Hierfür muss zunächst das zyklische Aktualisieren der Daten in den Schatten-DBs unterbunden werden. Entsprechend wird das Bit CYCLIC_ACTIVE auf 0 (false) gesetzt. 3 Werden die Werte von Eingangssignalen der FBs verändert, werden diese stets durch die anstehenden Signale wieder überschrieben 46

62 5 Realisierung und Konzeption der Datenübernahme Danach wird dem FC mittels dem WRITING_ACTIVE Bit mitgeteilt das ein Schreibvorgang stattfindet. Das Bit wird dementsprechend auf "1 (true) gesetzt. Ab dieser Konfiguration der Handler-Bits ist es möglich die Daten via OPC auf die SoftPLCs zu schreiben. Abbildung 5.15: Erweiterung des bestehenden PCS-7 Projekts für die Datenübernahme (Schreiben auf die SoftPLCs) Nach dem erfolgreichen Schreibvorgang muss zunächst das WRITING_ACTIVE Bit zurückgesetzt werden. Um dem FC bekanntzumachen, dass er die Daten übernehmen muss wid das TAKEOVER_IMPULSE Bit auf 1 (true) gesetzt. Der FC überträgt daraufhin selbständig die Daten aus den Schattenbausteinen in die Instanz-DBs. Anschliessend setzt er die Handler-Bits auf ihre Standardwerte zurück Nachführen von Motoren Für einige Typicals, darunter befinden sich z.b. die Antriebe, bedarf es auf PCS-7 Seite einer gesonderten Übernahme der Betriebszustände. Durch die abrupte Änderungen der Kommandos und Feedbacks würden diese von einem Hardware-Fehler ausgehen. Um dies zu verhindern, wird nach dem Neustart ein spezielles Bit in einer ihrer FBs für einige Sekunden gesetzt. Dieses Bit bewirkt, dass das PCS-7 Programm die Änderungen der Kommandos ignoriert und stattdessen den Betriebszustand der Instanz nur anhand der Feedbacks ermittelt. Die entpsrechenden Bausteine die dieses Bit für eine gewisse, parametrierte Zeit setzen befinden sich in dem Plan R2S_HANDLER_PCUn, wobei n für die Nummer der PLC steht (Abbildung 5.17). 47

63 5 Realisierung und Konzeption der Datenübernahme Abbildung 5.16: Ablaufdiagramm für die Werte des R2S_DB_PROG_HANDLER im Falle eines Schreibzugriffs Abbildung 5.17: Der CFC-Plan R2S_HANDLER_PCUn Der Ausgang des Bausteins wird bei jedem Motor mit dem Eingang RE_ON_iCMD des Baustein MAS_DRV verschalten. Wird die Simulation durch SIMIT gestartet, wird das dortige Start-Bit (siehe Kapitel ) an die PLCs übertragen und über den Plan R2S_HANDLER_PCUn an die Eingänge der Motoren übertragen. Diese werden daraufhin veranlasst ihren aktuellen Zustand anhand der Feedbacks zu 48

64 5 Realisierung und Konzeption der Datenübernahme ermitteln und die momentanen Kommandos zu ignorieren. Wird dieses Bit wieder zurückgesetzt kann der Motor wie gehabt weiter betrieben werden. 5.4 Starten der Simulation Um eine Simulation mit den Daten aus einem realen System zu starten sind folgende Schritte notwendig. Zunächst muss der gelesene Datensatz in das Programm für die Datenübernahme importiert werden, um die entsprechenden Änderungen vornehmen zu können. Danach wird die bestehende Snapshot-Datei in das Programm geladen um die Manipulation daran vorzunehmen. Sind alle Änderungen in der Snapshot-Datei vollzogen, kann diese wieder gespeichert werden. Die Zustände der Komponenten und die Prozesswerte sind nun bereits in die Simulation integriert. Die Snapshot-Datei kann nun in SIMIT geladen werden. In einem letzten Schritt müssen die Daten in die SoftPLCs geschrieben werden, damit auch die Parametrierung der Komponenten denen der realen Anlage entsprechen. Nachdem diese Schritte erfolgreich durchgeführt wurden, kann die Simulation mit den manipulierten Zuständen gestartet werden. 49

65 6 Realisierung im Programm 6 Realisierung im Programm Das folgende Kapitel umfasst die Beschreibung der Umsetzung der Datenübernahme im Programm S7-Real2Sim. Es baut dabei auf die theoretischen Grundlagen aus dem Kapitel 5 auf. Abbildung 6.1: Das Programm S7-Real2Sim Das Programm umfasst alle Funktionen der Datenübernahme. Mit seiner graphischen Oberfläche bietet es dem Nutzer die Möglichkeit die Daten eines Schiffes zu lesen und zu exportieren. Gleichzeitig kann es, auf dem Trainingssystem eingesetzt, die Daten wieder importieren und anhand dieser eine Snapshot-Datei manipulieren und die Daten in die SoftPLCs schreiben. Zusätzlich ist es möglich das Programm mit Kommandozeilenargumenten zu starten. In diesem Fall werden die Daten automatisch gelesen und exportiert. Statusmeldungen können in diesem Fall direkt an WinCC übertragen und dort dargestellt werden. Das Programm selbst basiert auf dem.net Framework in der Version 3.5 und der Programmiersprache C#. Die Darstellung der Benutzeroberfläche wurde mit Windows Presentation Foundation (WPF) realisiert. 50

66 6 Realisierung im Programm 6.1 Programmstruktur Allgemeine Programmstruktur Die Grundstruktur des Programms ist an das MVC Modell angelehnt. Dementsprechend existiert eine Aufteilung in drei Einheiten. Dazu gehören das Datenmodell (model), die Präsentation (view) und die Programmsteuerung (controller). Abbildung 6.2: Das Konzept der MVC-Struktur. Durchgezogene Linien entsprechen dabei einer direkten, gestrichelte einer indirekten Assoziation Das Ziel dieser Struktur ist es, einen flexiblen Programmentwurf zu ermöglichen durch den eine vereinfachte Erweiter- bzw. Änderbarkeit ermöglicht wird. Die Schnittstelle zwischen Benutzer und Programm wird dabei durch die view bereitgestellt. Deren Inhalte (z.b. Listenelemente, Texte usw.) sind an die Datenhaltung des models gebunden. Die Logik (z.b. Klicks auf eine Schaltfläche) werden von der view an den controller weitergeben und dort entsprechend verarbeitet. Die Umsetzung im Programm erfolgt wie in Abbildung 6.3 dargestellt. Abbildung 6.3: Umsetzung der MVC-Struktur im Programm S7-Real2Sim Das Hauptfenster (MainWindow) entspricht dem Programmeinstieg. Dieses bindet die einzelnen UserControls (View) ein, welche je nach selektiertem Menueintrag ein- bzw. 51

67 6 Realisierung im Programm ausgeblendet werden. Gleichzeitig erstellt MainWindow eine Instanz des MainManagers. Dieser wiederum erstellt für jedes UserControl Instanzen für die dazugehörige Logik (Controller) und Datenhaltung (Model). Der MainManager fungiert dabei als zentrales Bindeglied für den Datenaustausch zwischen all diesen Instanzen. Gleichzeitig werden hier weitere global genutzte Klassen und Methoden instanziert bzw. eingebunden. Dazu zählen unter anderem das Logging, die Datenhaltung der gelesenen Daten, sowie die Klassen für das Lesen und Schreiben der Daten. Die graphische Benutzerschnittelle (GUI) basiert auf der Windows Presentation Foundation (WPF). Die Anbindung der dargestellten Elemente (z.b. Texte oder der Inhalt von Listboxen) an die Datenhaltung erfolgt über das sogenannte Binding. Dabei wird innerhalb geschweifter Klammern das Ziel der Bindung nach dem Schlüsselwort Binding angegeben. Beispiel <TextBlock Text="Binding ConnectionControl.SomeText"/> Die Adressierung erfolgt dabei relativ, wobei der Ausgangspunkt der Datenkontext ist. Dieser wird über den Befehl, DataContext = MainManager für das Hauptfenster auf die Instanz des MainManager festgelegt. Das Weiterleiten der Kommandos (z.b. ein Klick auf eine Schaltfläche) erfolgt im wesentlichen analog dazu. Allerdings ist die Strukturierung der angebundenen Elemente komplexer (siehe Abbildung 6.4). Abbildung 6.4: Anbindung der Kommandos über die Datenbindung von WPF Für jedes Kommando wird ein von BaseCommand abgeleitetes Objekt erstellt und im entsprechenden Namespace abgelegt (z.b. S7Real2Sim.Commands.BeispielUserControl). 52

68 6 Realisierung im Programm In der Logik des entsprechendne UserControls wird diese Klasse instanziert und ein dazugehöriger Eventhandler angelegt. Wird nun im Programmverlauf auf die Schaltfläche geklickt, wird der Eventhandler des Kommandos in der Logikklasse des jeweiligen User- Controls ausgeführt. Wie bereits beschrieben bindet das MainWindow mehrere UserControls ein. In Abbildung 6.5 sind die drei wichtigsten Bereiche dieser UserControls markiert. Abbildung 6.5: Einbindung der UserControls in das Hauptfenster MainWindow(Rot: TopMenuControl.xaml, Grün: ReadFromPLCControl.xaml, CreateConfigControl.xaml, WriteToSnapshotControl.xaml, Blau: StatusBarControl.xaml Die UserControls TopMenuControl (rotes Rechteck) und StatusBarControl (blaues Rechteck) sind dabei zu jeder Zeit für den Benutzer sichtbar. Das TopMenu dient dabei als eine Art Hauptmenu unter anderem dem Umschalten der UserControls die im Bereich des grünen Rechtecks eingebunden sind. Für diesen Bereich sind dabei drei UserControls definiert: Tabelle 6.1: Wechselbare UserControls für das Programm S7-Real2Sim Name Menueintrag Beschreibung CreateConfigControl Edit Config Benutzeroberfläche zum Editieren/Erstellen der Konfigurationsdatei ReadFromPLCControl Read Data Benutzeroberfläche für das Lesen der Daten WriteToSnapshotControl Write Data Benutzeroberfläche für die Snapshotmanipulation und das Schreiben auf die Soft- PLCs Das UserControl StatusBar dient der Darstellung von Informationen für den Benutzer. Hier können verschiedene Meldungen in den Stufen SUCCESS, WARNING und ERROR 53

69 6 Realisierung im Programm Abbildung 6.6: CreateConfigControl.xaml, b) ReadFromPLCControl.xaml, c) WriteToSnapshotControl.xaml dargestellt werden. Durch ein Symbol werden dem Benutzer diese Stufen signalisiert. Für Vorgänge die einige Sekunden in Anspruch nehmen können, existiert hier zudem eine ProgressBar mit der der entsprechende Fortschritt der Operation angezeigt werden kann Struktur der gelesenen Daten Die Struktur für die Datenhaltung der gelesenen Daten orientiert sich am Aufbau des PCS-7 Projekts (Abbildung 6.7). Die Daten werden innerhalb des MainManagers abgelegt. Abbildung 6.7: Strukturierung der Datenhaltung für die gelesenen Datensenken In Abbildung 6.7 ist der prinzipielle Aufbau dieser Struktur beispielhaft dargestellt. Da die Adressierung der einzelnen PLCs bei der OPC-Verbindung über den Namen der projektierten S7-Verbindungen erfolgt, wird für jede der Steuerungen eine Instanz der Klasse S7Connection der Liste MainManager.S7Connections hinzugefügt. Zu jeder PLC gehört im weiteren eine bestimmt Anzahl an Schatten-DBs. Für jeden 54

70 6 Realisierung im Programm dieser DBs wird eine Instanz der Klasse DB in der Liste S7Connection.DB_Collection angelegt. Diese spiegeln im folgenden den Schatten-DB mitsamt seines Inhalts wider. Für jede Instanz des jeweiligen Typicals wird eine Instanz der Klasse Instance in der Liste DB.Instances abgelegt, diese wiederum besitzt eine Liste DB_Items, worin für jede Variable der jeweiligen UDT eine Instanz der Klasse DB_Item erstellt wird. 6.2 Konfigurations-Datei Um ein hohes Maßan Flexibilität gewährleisten zu können, wurde das Programm schon in der Konzeptphase für eine Konfigurationsdatei ausgelegt. Mit Hilfe dieser Konfiguration können die zu lesenden Schattendatenbausteine, Datensenken, OPC-Server und Verbindungen frei konfiguriert werden. Ein Beispiel für solch eine Konfigurationsdatei befindet sich in Anhang A.4. Die Konfigurationsdatei selbst ist als XML-Datei ausgeführt. Dies bietet den Vorteil das ihr Erscheinungsbild dem Nutzer gegenüber übersichtlicher gestaltet ist. Zudem ist das Auslesen und Parsen der Informationen über bereits vorhandene Bibliotheken aus der.net Umgebung deutlich einfacher zu realisieren. Die Gliederung der Konfiguration besteht aus vier Grundknoten: Connections, DBStructures, Mapping und ReadData (siehe Tabelle 6.2). Tabelle 6.2: Übersicht über die Grundknoten der XML-Konfigurationsdatei Name Connections DBStructures Mapping ReadData Beschreibung Dient der Definition der Verbindungen (OPC-Server, S7-Verbindungen und der optionalen WinCC-Anbindung) sowie der Zuweisung der DB- Typen auf die Schatten-DBs Dient der Definition von DB-Typen, deren struktureller Aufbau (Variablen und deren Datentypen) den UDTs und damit dem Typical entsprechen Definiert die Mappingmethoden für die einzelnen Typicals. Die Zuweisung erfolgt über den eindeutigen Namen des DB-Typen Enthält einen kompletten exportierten Datensatz inkl. aller notwendigen Informationen um diesen importieren zu können (optional) Die exakte Reihenfolge dieser Knoten ist dabei unbedingt einzuhalten 4, da die nachfolgenden Knoten auf Informationen der führenden Knoten aufbauen und ein einwandfreier Programmablauf sonst nicht gewährleistet werden kann. 4 Diese Vorgehensweise ist für XML-Dokumente normalerweise nicht üblich 55

71 6 Realisierung im Programm Connections Der Knoten Connections dient der Projektierung der Verbindungen. Dazu zählen in erster Linie die OPC-Server sowie die davon ausgehenden S7-Verbindungen zu den einzelnen PLCs. Zusätzlich ist es möglich eine Anbindung an WinCC herzustellen um Diagnosemeldungen und Fortschrittswerte der Lesevorgänge dem HMI zu übergeben OPC-Server Hierbei muss zwischen drei unterschiedlichen Typen von OPC-Servern unterschieden werden. Während der OPC-Server für die WinCC-Verbindung optional ist, müssen die OPC- Server des Realsystems und des Trainingssystems definiert sein. Die Definition für das Realsystem erfolgt wie folgt: <OPCServer_IN>opcda://OSS01/OPC.SimaticNET</OPCServer_IN> Die Angabe der Adresse erfolgt zwischen dem Start- und End-Tag. Analog dazu wird die Adresse des OPC-Servers für das Trainingssystems definiert. <OPCServer_OUT>opcda://OSS02/OPC.SimaticNET</OPCServer_OUT> Um das Programm von WinCC aus starten zu können, verfügt es über die Möglichkeit via Kommandozeilenparameter gestartet zu werden(kapitel ). In diesem Fall ist es möglich Statusmeldungen an WinCC zu verschicken. Das versenden der Meldungen erfolgt ebenfalls über eine OPC-Verbindung. Um diese Verbindung herstellen zu können muss der WinCC-OPC-Server spezifiziert werden: <OPCServer_WinCC>opcda://OSS01/OPCServer.WinCC</OPCServer_WinCC> WinCC_Connection Die Einbindung der Verbindung zu WinCC ist optional, wird sie nicht benötigt muss dieser Knoten nicht in der Konfiguration definiert werden. Die Definition erfolgt durch den folgenden Aufruf: <WinCC_Connection start= R2S010_STARTED finish= R2S020_FINISHED error= R2S120_ERROR /> 56

72 6 Realisierung im Programm Tabelle 6.3: Attribute des Knotens WinCC_Connection Attribut start finish error Beschreibung WinCC Variable vom Typ Bool, gibt an ob das Programm gestartet ist WinCC Variable vom Typ Bool, gibt an ob der Lesevorgang beendet ist WinCC Variable vom Typ Bool, gibt an ob beim Lesevorgang Fehler aufgetreten sind Dabei müssen die drei Attribute gesetzt werden. Eine Übersicht über diese und deren Erklärung befindet sich in der Tabelle 6.3. Zusätzlich zu diesen grundlegenden Meldungen ist es zudem möglich den Betriebszustand der PLC und den Fortschritt der Leseoperation an WinCC zu übertragen. Hierfür müssen entsprechende Variablen im WinCC Variablenhaushalt angelegt und auf die Oberfläche des HMI verbunden werden. Für den Betriebszustand einer PLC wird ein vorzeichenbehafteter 8-Bit Wert benötigt. Die Entsprechungen der einzelnen Werte sind der Tabelle 6.4 zu entnehmen. Wert Tabelle 6.4: Werte für den Betriebszustand einer PLC (CPUState) Beschreibung -1 unbekannter Betriebszustand 0 Betriebszustand STOP 2 Betriebszustand RUN Die Definition der WinCCVariable erfolgt über einen Unterknoten wie folgt: <CPUState connectionname= OSS01_PCU1_OPC varname= R2S200_CPUSTATE_00 /> Dabei entspricht der Name der Verbindung (Attribut: connectionname) dem Namen der S7-Verbindung zu der jeweiligen PLC im realen System. Der Variablenname innerhalb WinCC wird über das Attribut varname deklariert. Als weitere Information steht der Fortschritt des Lesevorgangs zur Verfügung. Dieser wird an einen vorzeichenlosen 8-Bit Wert in WinCC gesendet. Der Wertebereich erstreckt sich dabei von 0 bis 100 Prozent. <ReadingProgress connectionname= OSS01_PCU1_OPC varname= R2S300_PROGRESS_00 /> Analog zu dem Betriebszustand (CPUState) der PLC erfolgt die Zuweisung des Fortschritts über den Namen der S7-Verbindung der entsprechenden PLC auf dem realen 57

73 6 Realisierung im Programm System. Ebenso wie die Definition des WinCC-Variablennamens. Sowohl die Übermittlung des Betriebszustands als auch des Fortschritts sind optional S7Connection Mittels dieser Knoten werden die Verbindungen zu den PLCs definiert. Da die Namen zwischen dem Realsystem und dem Trainingssystem variieren können müssen diese separat über die Attribute name_in (Realsystem) und name_out (Trainingssystem) definiert werden. <S7Connection name_in= OSS01_PCU2_OPC name_out= OSS02_SPLC2_ISO_OPC > Zusätzlich zu den Verbindungsnamen muss der entsprechende R2S_DB_PROG_HANDLER über den Knoten RegisterTakeOverDB spezifiziert werden: <RegisterTakeOverDB db= DB1100 cyclic_active= 0.0 reading_active= 0.1 writing_active= 0.2 takeover_impulse= 0.3 life_counter= 1 /> Für jede S7-Verbindung darf dieser Knoten nur einmal definiert werden. Die Spezifikation der Attribute ist der Tabelle 6.5 zu entnehmen. Tabelle 6.5: Attribute des Knoten RegisterTakeOverDB (siehe auch Kapitel ) Attribut db cyclic_active reading_active writing_active takeover_impulse life_counter Beschreibung Name des DBs Bitadresse des Cyclic_Active Bits Bitadresse des Reading_Active Bits Bitadresse des Writing_Active Bits Bitadresse des TakeOver_Impulse Bits) Byteadresse für das Life_Counter Byte Als weiterer Schritt müssen die Schatten-Datenbausteine mit ihrer jeweiligen UDT definiert werden. Dies erfolgt über einen XML-Knoten RegisterDBType. Für jeden Schatten- DB aus dem gelesen werden soll muss ein solcher Knoten angelegt werden. <RegisterDBType type= R2S_UDT_INST_BIN dbname= 1102 prefix= EM_%INST_NAME%/EM_%INST_NAME%_BIN_STD/ comment= /> 58

74 6 Realisierung im Programm Tabelle 6.6: Attribute des Knoten RegisterDBType Attribut type dbname prefix Beschreibung Eindeutiger Bezeichner eines DB-Typen, dieser muss unter DBStructures definiert sein Name des DBs in der PLC Prefix für das Mapping im Snapshot Das Attribut Prefix dient dabei der Adressierung in der Snapshot-Datei. Die Daten einer Instanz werden in dieser Datei über eine Art Pfad adressiert (siehe Beispiel für einen RegisterDBType Knoten). Über das Prefix kann dieser Pfad definiert werden, wobei das Schlüsselwort %INST_NAME% als Platzhalter dient. Das Programm ersetzt diesen durch den jeweiligen Instanznamen. Ausgenommen hiervon sind DB-Typen die mit dem Attribut specialdb= true definiert werden. In diesem Fall muss das Ziel im Snapshot bei den Mappingmethoden absolut adressiert werden, das Präfix wird in diesem Fall ignoriert DBStructures Der Knoten DBStructures dient dazu, dem Programm die verschiedenen UDTs der Schatten- DBs bekannt zu machen. Für jede verwendete UDT wird ein Unterknoten mit dem Bezeichner DBType und dem Attribut name angelegt. Der unter name definierte Bezeichner dieses Typs dient der Zuweisung auf Schatten-DBs und der Mappingfunktionen. Daher muss dieser Name eindeutig vergeben werden. <DBType name= R2S_UDT_INST_BIN specialdb= false > Tabelle 6.7: Attribute für einen Knoten vom Typ DBType Attribut name specialdb Beschreibung Eindeutiger Bezeichner für den DB-Typ Deklariert diesen DB-Typen als DB mit CPU-spezifischen Daten (optional) Optional kann ein DB-Typ über das Attribut specialdb= true als sogennanter Special- DB ausgewiesen werden. Diese Art eines Schatten-DBs enthält spezifische Werte für eine PLC (z.b. Fahrgeschwindigkeit, Wassertemperatur etc). Da diese Informationen nicht einem Typical zugewiesen werden können, werden sie in solche Special-DBs ausgelagert und gesondert gelesen bzw. geschrieben. Jedem der DB-Typen können im Folgenden die einzelnen Variablen hinzugefügt werden. 59

75 6 Realisierung im Programm Jedes Element wird dabei über einen neuen Unterknoten vom Typ DBItem hinzugefügt. Die erforderlichen Attribute für ein solches DBItem sind der Tabelle 6.8 zu entnehmen. Die verwendbaren Datentypen sind dabei der Tabelle 6.9 zu entnehmen. Es ist dabei Attribut Tabelle 6.8: Attribute für einen Knoten vom Typ DBItem Beschreibung address Adresse des DBItems in Byte. Erstes Element beginnt bei der Adresse 0 description Eindeutiger Bezeichner der Variable datatype Datentyp der Variable. Verfügbare Datentypen sind in Tabelle 5.1 aufgelistet length Die Länge ist standardmäßig 1. Für Strings muss hier die entsprechende Länge (inkl. Steuerbytes) angegeben werden comment Kann verwendet werden um einen Kommentar für die Variable einzufügen (optional) darauf zu achten, dass im Falle des Datentyps Bool zusätzlich die Bitadresse angegeben werden muss (z.b.: 0.0 ). Tabelle 6.9: Gültige Datentypen für ein DBItem Datentypen Speicher Wertebreich Bool 1 Bit true oder false Byte 1 Byte 0x00 bis 0xFF Char 1 Byte ASCII Zeichen z.b.: A,B,C,1,2,3 etc. Int 2 Byte bis Word 2 Byte 0x00 bis 0xFFFF Date 2 Byte D# bis D# S5Time 2 Byte S5T#0H_0M_0S_10MS bis S5T#2H_46M_30S_0MS DWord 4 Byte 0x00 bis 0xFFFF FFFF DInt 4 Byte bis Real 4 Byte Dezimalzahlen mit Punkt Time 4 Byte -T#24D_20H_31M_23S_648MS bis T#24D_20H_31M_23S_647MS TimeOfDay 4 Byte TOD#0:0:0.0 bis TOD#23:59: String max 258Byte Zeichenkette Mapping Da die Mappingmethoden ebenfalls frei konfigurierbar sein sollen, dient der Knoten Mapping der Definition dieser. Für jeden DB-Typen werden hier Unterknoten erstellt, in denen die Mappingfunktionen definiert werden können. Die Zuweisung zu einem DB-Typ 60

76 6 Realisierung im Programm erfolgt über das Attribut dbtype. <Map dbtype= R2S_UDT_INST_BIN >... </Map> Für das Mapping stehen vier Grundfunktionen zu Verfügung die im Folgenden beschrieben werden. Die für die Mappingfunktionen gültigen Operatoren (logische und mathematische) sind in der Tabelle 6.10 aufgelistet und werden in den folgenden Abschnitten genauer erläutert. Tabelle 6.10: Verfügbare Operatoren logische Operatoren AND, OR, ANDNOT, ORNOT, XOR, XNOR, ==,!= mathematische Operatoren +, -, *, /, % sonstige (,) Die Definition des jeweiligen Ziels in der Snapshotdatei ergibt sich durch Addition der beiden Strings: prefix (Kapitel ) + destination (folgende Abschnitte) Die Funktionsweise soll anhand des Typicals R2S_UDT_INST_BIN beschrieben werden. Als Ausgangspunkt soll dabei der Wert R2Ssig betrachtet werden. Dieser befindet sich für eine Instanz mit dem Namen X110_000 in der Zeile: EM_X110_000/EM_X110_000_BIN_STDR2Ssig/=1 Dementsprechend muss das Prefix für den Schatten-DB wie folgt definiert werden: EM_$INST_NAME$/EM_$INST_NAME$_BIN_STD/ Wobei das Schlüsselwort $INST_NAME$ vom Programm durch den tatsächlichen Instanznamen ersetzt wird. Zusätzlich wird der Wert des Attributs destination als R2Ssig definiert. Durch die Addition dieser Strings ergibt sich die gewünschte Zielzeile in der Snapshotdatei. 61

77 6 Realisierung im Programm Neben dem Schlüsselwort für den Instanznamen existiert ein weiteres für den Instanztypen: $INST_TYPE$. Der entsprechende Wert wird dem Programm vom PCS-7 Programm in dem Header der Schatten-DBs übergeben. Das Schlüsselwort ist ausschliesslich in logischen Ausdrücken zulässig und dient vorallem dazu, Bedingungen für Mappingmethoden typspezifisch zu generieren. So wird z.b. für Motoren und das Typical MAS_VAL_1D die gleiche UDT und damit der gleiche DB-Typ verwendet. Eine Unterscheidung der Mappingmethoden kann durch dieses Schlüsselwort realisiert werden. Neben dem bisher beschriebenen, Typical-spezifischen Mappingmethoden ist es weiterhin möglich typicalunabhängige Werte im Snapshot zu ändern. Hierfür steht dem Anwender folgender Unterknoten zur Verfügung: <SetInSnapshot>... </SetInSnapshot> Die Verwendung dieser Mappingmethoden wird in den Abschnitten , und genauer behandelt Assignment Ein Assignment (Tabelle 6.11) schreibt den gelesenen Wert einer Variable an die spezifizierte Stelle im Snapshot. Tabelle 6.11: Attribute der Mappingfunktion Assignment Attribut description destination comment Beschreibung Eindeutiger Bezeichner einer Variable (muss in dem entsprechenden DB- Typen definiert sein) Ziel in der Snapshotdatei Kommentar (optional) Beispiel: <Assignment description= M_LOCAL destination= R2Sloc comment= /> Assignment.Log Das Assignment.Log (Tabelle 6.12) wertet einen unter term angegebenen logischen Ausdruck aus und schreibt das Ergebnis an die entsprechende, unter destination definierte, Stelle in den Snapshot. Die Operanden des logischen Ausdrucks können dabei entweder Variablen aus dem DB-Typen oder Werte dieser Instanz aus dem Snapshot sein. 62

78 6 Realisierung im Programm Tabelle 6.12: Attribute der Mappingfunktion Assignment.Log Attribut term destination comment Beschreibung Logischer Ausdruck aus mehreren, eindeutigen Bezeichnern Ziel in der Snapshotdatei Kommentar (optional) Beispiel: <Assignment.Log term= CO_1S OR FB_RUN1S ANDNOT CO_OFF destination= R2S1d1v comment= /> Assignment.Log.Set Das Assignment.Log.Set (Tabelle 6.13) wertet zunächst den logischen Ausdruck einer Bedingung (condition) aus. Ist das Ergebnis gleich True, wird der unter set definierte logische Ausdruck evaluiert und dessen Ergebnis in den Snapshot geschrieben. Tabelle 6.13: Attribute der Mappingfunktion Assignment.Log.Set Attribut condition destination set comment Beschreibung Logischer Ausdruck aus mehreren eindeutigen Bezeichnern. Ergibt die Auswertung True wird das Ergebnis von set an die entsprechende Stelle im Snapshot geschrieben Ziel in der Snapshotdatei Logischer Ausdruck, dessen Ergebnis in den Snapshot geschrieben wird Kommentar (optional) Beispiel: <Assignment.Log.Set condition= $INST_TYPE$ == 10 set= CO_2F OR FB_RUN2F ANDNOT CO_OFF destination= R2S2d2v comment= /> Assignment.Log.Calculate Das Assignment.Log.Calculate (Tabelle 6.14) wertet, analog zum vorhergehenden Assignment.Log.Set, das Ergebnis einer Bedingnung aus. Ist das Ergebnis gleich True, wird das Resultat des unter set definierten Terms in den Snapshot geschrieben. Dieser Term muss dabei ein mathematischer Ausdruck sein dessen Operanden sowohl aus dem DB- Typen oder aus instanzspezifischen Werten des Snapshots bestehen können. Zudem sind auch Konstanten zulässig. 63

79 6 Realisierung im Programm Tabelle 6.14: Attribute der Mappingfunktion Assignment.Log.Calculate Attribut condition destination set comment Beschreibung Logischer Ausdruck aus mehreren eindeutigen Bezeichnern. Ergibt die Auswertung True wird das Ergebnis von set an die entsprechende Stelle im Snapshot geschrieben Ziel in der Snapshotdatei Mathematischer Ausdruck, dessen Ergebnis in den Snapshot geschrieben wird Kommentar (optional) Beispiel: <Assignment.Log.Calculate condition= True set= s_nennber_max / (p_sensorrange_max - p_sensorrange_min) * PV destination= R2S2d2v comment= /> Set Eine Mappingfunktion Set (Tabelle 6.15) schreibt einen konstanten Wert an eine spezifizierte Stelle im Snapshot. Das Ziel in der Snapshot-Datei muss dabei absolut angegeben werden, da für diese Methoden kein Präfix existiert. Tabelle 6.15: Attribute der Mappingfunktion Set Attribut destination set comment Beschreibung Ziel in der Snapshotdatei Konstanter Wert der in den Snapshot geschrieben werden soll Kommentar (optional) Beispiel: <Set destination= SIMIT/Startimpuls#1/8/Z_STATE set= 1 comment= /> Set.Log Analog zum Assignment.Log.Set ist die Mappingfunktion Set.Log (Tabelle 6.16) eine Erweiterung der Standardfunktion. Auch hier wird zunächst eine Bedingung ausgewertet, ergibt diese True wird der unter set definierte, logische Ausdruck ausgewertet und in den Snapshot geschrieben. 64

80 6 Realisierung im Programm Tabelle 6.16: Attribute der Mappingfunktion Set.Log Attribut condition destination set comment Beschreibung Logischer Ausdruck der als Bedingung für die Ausführung dieser Mappingmethode dient Ziel in der Snapshotdatei Logischer Ausdruck, der ausgewertet und in den Snapshot geschrieben wird Kommentar (optional) Die Besonderheit an dieser Mappingmethode ist die Möglichkeit bestehende Werte in den logischen Ausdrücken zu verwenden. Die Werte können dabei aus dem Snapshot selbst oder aus dem Pool gelesener Werte stammen. Soll ein Wert aus dem Snapshot verwendet werden, so muss die entsprechende Zeile angegeben werden. Um gelesene Werte verwenden zu können, müssen diese speziell deklariert werden, z.b.: [X120_000:FADEOUT] Dabei wird in eckigen Klammern die entsprechende Instanz durch ihren Instanznamen, gefolgt von einem Doppelpunkt und dem entsprechenden Variablennamen angegeben. Diese Methode gilt sowohl für den Ausdruck unter condition als auch unter set. Beispiel: <Set.Log condition= True destination= [X120_000:FADEOUT] AND EM_ME1_Engine_Data/1/X set= PB_ME1_Data/4/X comment= /> Set.Calculate Ähnlich der Mappingmethode Set.Log verfügt Set.Calculate (Tabelle 6.17) über eine Bedingung die True ergeben muss, damit der entsprechende Wert im Snapshot geändert werden kann. Allerdings muss der unter set definierte Ausdruck mathematischer Natur sein. Auch hier können die Werte sowohl aus dem Snapshot als auch aus dem Bestand der gelesenen Werte stammen. Es gilt dabei die gleiche Zuweisungsfunktion wie bereits in Kapitel beschrieben. Beispiel: <Set.Calculate condition= True destination= EM_ME1_Engine_Data/1/X set= PB_ME1_Data/4/X comment= /> 65

81 6 Realisierung im Programm Tabelle 6.17: Attribute der Mappingfunktion Set.Calculate Attribut condition destination set comment Beschreibung Logischer Ausdruck der als Bedingung für die Ausführung dieser Mappingmethode dient Ziel in der Snapshotdatei mathematischer Ausdruck, der ausgewertet und in den Snapshot geschrieben wird Kommentar (optional) ReadData Der Knoten ReadData dient dem Abspeichern eines gelesenen Datensatzes. Als Attribut timestamp wird der Zeitstempel des Datensatzes abgespeichert. Die enthaltenen Daten unter diesem Knoten sind so abgelegt, dass ein Importieren, unabhängig von den Strukturen die unter den Knoten Connections und DBStructures definiert sind, möglich ist. Entsprechend werden alle Informationen von den S7-Verbindungen bis hin zum Aufbau der DB-Typen gespeichert. Zusätzlich sind weitere Informationen wie z.b. den Betriebsstatus der CPUs, oder ob der Datensatz erfolgreich gelesen wurde abgelegt. Der genaue Aufbau bzw. die Verwendung des Knotens wird im Kapitel beschrieben. 6.3 Programminitialisierung Nachdem das Programm gestartet wird, wird zunächst das Hauptfenster (MainWindow) mit seinen UserControls initialisiert. Zudem wird die Instanz des MainManager angelegt, welcher wiederum alle Instanzen der MVC-Struktur sowie das Logging und die Klasse für den Zugriff auf die OPC-Elemente initialisiert. Als letzter Schritt versucht das Programm eine Konfiguration mit einem festen Pfad zu laden (..\Config\AppConfig.xml). Wenn diese Datei vorhanden ist, wird sie geladen. Ab diesem Moment befindet sich das Programm in einem Zustand, in welchem es vom Nutzer bedient werden kann. Grundlage für das Lesen ist dabei eine erfolgreich geladene Konfigurationsdatei, sollte dies nicht automatisch geschehen sein muss sie händisch über die Schaltfläche Load Config geladen werden. Das Programm führt dazu die Funktion LoadConfig() in der Klasse ConfigLogic (Namespace: S7Real2Sim.Logic.TopMenu) aus. Nachdem die Funktion die XML-Datei in die Variable config (Typ: XmlDocument) geladen hat, arbeitet sie Schritt für Schritt die Hauptknoten der XML-Konfiguration ab indem sie diese den jeweiligen Methoden übergibt. 66

82 6 Realisierung im Programm Wie bereits in Kapitel 6.2 beschrieben ist beim Aufbau der Konfigurations-Datei unbedingt darauf zu achten, dass die Reihenfolge der Knoten korrekt ist (Connections, DBStructures, Mapping, ReadData). Dementsprechend sollte das Programm bei einem korrektem Aufbau mit dem Knoten Connections beginnen und diesen der Methode private void ProcessDBStructuresNode(XmlNode DBStructuresNode) übergeben. Diese wiederum durchsucht den Knoten und parametriert das Programm entsprechend der vorliegenden Informationen. Neben den Adressen der OPC-Server und der WinCC-Anbindung (optional) werden für die angegebenen S7-Verbindungen entsprechende Instanzen in der Liste MainManager.S7Connections angelegt (vergleiche Kapitel 6.1.2). Dies ist wiederum nur dann möglich wenn zu dem Knoten der S7-Verbindung ein gültiger Knoten vom Typ RegisterTakeOverDB existiert, ist dies nicht der Fall, würde es im nachfolgenden Programmablauf Fehler beim Lesen der Daten geben. Daher wird dies als ein Fehler behandelt. Abschliessend dazu werden die Knoten vom Typ RegisterDBType bearbeitet. Diese werden ausgewertet und die Informationen zunächst in einer Liste S7Connection.RegisterDBs vom Typ RegisterDB abgelegt. Nachdem alle Knoten und Unterknoten bearbeitet worden sind, wird die Methode beendet und das Programm ruft die Funktion private void ProcessConnectionNode(XmlNode ConnectionNode) auf und übergibt dieser den XML-Knoten DBStructures. Diese arbeitet die Unterknoten vom Typ DBType Schritt für Schritt ab. Dabei wird zunächst der Name des Typs geparst und anschliessend mit den Elementen der Listen RegisterDBs in den bereits angelegten Instanzen der Klasse S7connection verglichen. Ist ein DB mit diesem Typen dort spezifiziert, wird eine neue Instanz vom Typ DB der Liste S7Connection.DB_Collection hinzugefügt. Wie in Kapitel beschrieben enthalten die Unterknoten von DBType Knoten vom Typ DBItem welche die Variablen der UDT definieren. Diese werden im folgenden geparst und in der Liste DB_Items abgelegt: 67

83 6 Realisierung im Programm DB.DummyInstance.DB_Items.Add(DB_Item); Da zu dem jetztigem Zeitpunkt nicht bekannt ist, wieviele Instanzen sich in dem Schatten- DB befinden bedarf es dieser Zwischenspeicherung. Die eigentliche Liste DB.Instances kann dementsprechend erst erstellt werden nachdem die Informationen des Headers (Kapitel ) gelesen wurden. Nachdem alle DBs den jeweiligen S7-Verbindungen zugeordnet und die Dummy-Instanzen erstellt wurden, wird die Methode beendet und die nächste aufgerufen: private void ProcessMappingNode(XmlNode MappingNode) Diese fügt die in der Konfiguration definierten Mappingmethoden den jeweiligen DBs in den S7-Verbindungen hinzu. Analog zu den DB-Strukturen werden auch hier die nach Typ sortierten Mappingmethoden nacheinander abgearbeitet und den entsprechenden DBs zugeordnet. Für jede Mapping-Methode verfügt eine Instanz der Klasse DB über eine Liste in der die jeweiligen Attribute gesichert werden: public ObservableCollection<Assignment>Assignments public ObservableCollection<AssignmentLog>AssignmentLogs public ObservableCollection<AssignmentLogSet>AssignmentLogSets public ObservableCollection<AssignmentLogCalculate>AssignmentLogCalculates Nachdem die Typical-spezifischen Mappingmethoden eingelesen wurden, folgen die typicalunabhängigen Mappingfunktionen. Diese werden in der Klasse SnapshotControlData in den Listen public ObservableCollection<SetInSnapshot>SetInSnapshotItems public ObservableCollection<SetInSnapshotLog>SetInSnapshotLogItems 68

84 6 Realisierung im Programm public ObservableCollection<SetInSnapshotCalculate>SetInSnapshotCalculateItems gespeichert. Sind diese drei XML-Grundknoten erfolgreich durchlaufen, befindet sich das Programm in einem initialisiertem Zustand. Das heißt, es ist nun möglich eine Verbindung zum OPC-Server herzustellen und anhand der HeaderInforamtionen die komplette Datenstruktur zu erzeugen. 6.4 Lesen von Daten aus Realsystemen Für die Interaktionen mit dem OPC-Server steht die Klasse OPCLib zur Verfügung, diese wird im MainManager instanziert (Namespace: S7Real2Sim.OPC_Lib). Sie bildet die allgemeine Schnittstelle zwischen dem Programm und der OPC-Welt. Entsprechend sind in dieser Klasse die Objekte für die drei OPC-Server (Realsystem, Trainingssystem, WinCC) angelegt (Tabelle 6.18). Daneben existieren Methoden für das Verbinden bzw. Trennen der Verbindung, sowie Methoden für den Lese- und Schreibzugriff verfügbar (Tabelle 6.19). Tabelle 6.18: Serverobjekte vom Typ Opc.Da.Server Serverobjekt Server_RealSystem Server_TrainingsSystem Server_WinCC Beschreibung Server für das realse System Server für das Trainingssystem Server für die WinCC-Anbindung Tabelle 6.19: Methoden der Klasse OPCLib für den Lese- bzw. Schreibzugriff Methode Read(DB_Item DB_Item_in, Opc.Da.Server Server) Read(ObservableCollection<DB_Item>DB_Items_in, Opc.Da.Server Server) Write(ObservableCollection<DB_Item>DB_Items_in, Opc.Da.Server Server) Verbindungen zu den OPC-Servern können über die Methoden Connect() und Disconnect() aufgebaut bzw. getrennt werden. Um welchen Server es sich dabei handelt wird der Methode mit Hilfe des übergebenen Serverobjekts mitgeteilt. Zudem wurden Eventhandler implementiert, die im Falle einer unterbrochenen Verbindung zum OPC-Server ausgeführt werden. 69

85 6 Realisierung im Programm Verbinden Nachdem eine Konfigurationsdatei erfolgreich geladen wurde, ist es möglich eine Verbindung zum OPC-Server herzustellen. Im Falle des Lesens wird die Verbindung zum OPC-Server des realen Systems aufgebaut (Server_RealSystem). Dies geschieht bei der Benutzung der graphischen Oberfläche über das UserControl ReadFromPLCControl (Menueintrag Read Data ). Nachdem der Benutzer auf die Schaltfläche Connect geklickt hat, geschehen prinzipiell zwei Dinge. Zum Einen wird die eigentliche Verbindung zu dem OPC-Server aufgebaut. Zusätzlich werden nach einer erfolgreichen Verbindung die Headerinformationen der Schatten-DBs ausgelesen. Anhand dieser Informationen wird nachfolgend die komplette Datenstruktur mit allen Instanzen, DBItems und deren Adressen erstellt. Das Verbinden zum OPC-Server wird dabei durch die Methode OnConnect() in der Klasse ConnectionControlLogic gestartet. Diese Funktion initialisisert den Aufbau der Verbindung und stößt anschliessen den Aufbau der Datenstruktur an. Der Verbindungsaufbau geschieht dabei über den Aufruf der connect() Methode der OPCLib Klasse: MainManager.OPCLib.Connect(MainManager.ConnectionControlData.ServerURL_UI, MainManager.OPCLib.Server); Als Übergabeparameter werden dabei die URL des Servers und das entsprechende Serverobjekt übergeben. Nachfolgend wird die Verbindung überprüft, ist das Programm mit dem Server verbunden wird die Flag ReadPossible auf true gesetzt. Damit wird die Schaltfläche für das Lesen aktiviert. Im nächsten Schritt wird die Datenstruktur erzeugt, insofern dies noch nicht geschehen ist. Dazu werden zunächst die Headerinformationen gelesen: MainManager.OPCLib.ReadKeyValuesForDBs(); Diese Methode durchläuft alle Elemente der Liste MainManager.S7Connections sowie deren DBs und liest die notwendigen Informationen (Tabelle 6.20). Diese Werte werden in den entsprechenden Properties der Klasse DB gespeichert. Ist dies für alle S7-Verbindungen geschehen, kann nachfolgend die Datenstruktur erstellt werden. Dazu werden erneut alle Elemente der Liste MainManager.S7Connections in einer foreach Schleife durchlaufen. Für jedes Element wird die entsprechende Methode 70

86 6 Realisierung im Programm Tabelle 6.20: Benötigte Headerinformationen der Schatten-DBs Variable Typ Adresse [Byte] Beschreibung INST_TYPE Int 18 ID des Typicals (in PCS-7 festgelegt) INST_COUNTER DInt 20 Anzahl der Instanzen INST_LENGTH DInt 24 Länge einer Instanz in Byte INST_OFFSET DInt 28 Byteadresse der ersten Instanz S7Connection.SetupDBDataStructure(); aufgerufen. Darin werden alle Elemente der Liste DB_Collection durchlaufen. Anhand der gelesenen Headerinformationen können nun alle Instanzen inklusive ihren DBItems mit Hilfe der DummyInstance angelegt werden. Die Byteadressen der DBItems errechnet sich dabei wie folgt: Adresse = Offset + Adresse des DummyItems + Länge einer Instanz * Instanznummer Lesevorgang Nachdem die interne Datenstruktur mit allen Instanzen und DB-Items erstellte wurde ist es möglich den eigentlichen Lesevorgang zu starten. Durch einen Klick auf die Schaltfläche Read Data wird der entsprechende Eventhandler aufgerufen. Um die Bedienbarkeit zu erhalten und die Perfomance zu erhöhen wird der komplette Lesevorgang auf separate Threads aufgeteilt. Jeweils ein Thread für ein Element der Liste MainManager.S7Connections. Die Grundlage für diese Threads bildet die Klasse ReadDataOfS7Connection im Namespace S7Real2Sim.OPC_Lib. Sie beinhaltet neben dem eigentlichen Lesevorgang die Logiken um die Interaktion mit der PCS-7 Seite über den Handler-DB R2S_DB_PROG_HANDLER zu steuern (Kapitel ). Ist der Lesevorgang für einen Thread abgeschlossen wird dies dem Hauptthread über das Event OperationFinishedEvent mitgeteilt. Im entsprechenden Eventhandler (Connection- ControlLogic.ReadingThreadFinished) werden die Threads anschliessend über ein Fehler- Byte ausgewertet und beendet. Der Zugriff auf PLCs via OPC bietet neben den bereits genannten Vorteilen allerdings auch den Nachteil das nicht alle Datentypen der PCS-7 Umgebung gelesen werden können. So ist ein direkter Zugriff auf Variablen mit den Datentypen Bool, String, Time_Of_Day und S5Time nicht möglich. Für diese mussten eigens implementierte Lösungen geschaffen werden. 71

87 6 Realisierung im Programm Abbildung 6.8: Ablaufdiagramm für die Werte des R2S_DB_PROG_HANDLER im Falle eines Lesezugriffs Bool Anstatt einen bool schen Wert direkt zu lesen, wird ein Byte gelesen (a). Dieser Wert Abbildung 6.9: Lesen eines bool schen Werts über ein Byte wird anschliessend um 7 - Bitadresse nach links geshiftet (b). Durch einen weiteren Shift um sieben Stellen nach rechts befindet sich das gewünschte Bit an der Stelle des Least Significant Bit (LSB) (c). Der Wert des Bytes kann also nur noch 1 oder 0 sein, entsprechend dem Wert des gewünschten Bits. 72

88 6 Realisierung im Programm String Ein String wird in PCS-7 in der Struktur, wie in Abbildung 6.10 zu sehen, gespeichert. Es handelt sich dabei um ein Bytearray bei dem die ersten beiden Bytes die maximale und aktuelle Länge des Strings definieren.[13] Dementsprechend wird ein Bytearray gelesen, Abbildung 6.10: Struktur des Datentyps String von dem die ersten beiden Elemente abgeschnitten werden. Das resultierende Array kann nachfolgend in einen String konvertiert werden. string String = System.Text.Encoding.ASCII.GetString(byteArray); Time_Of_Day Der Datentyp Time_Of_Day speichert die Anzahl der Millisekunden seit Tagesbeginn in einem Doppelwort. Die Darstellung erfolgt über das Schema: TOD#HH:mm:ss:fff Um diesen Wert zu lesen wird ein Wert vom Typ DWord gelesen, da dieser den gleichen Speicherplatz belegt. Anschliessend wird wie in Abbildung 6.11 dargestellt der Wert in seiner gewöhnlichen Darstellung gewonnen. [13] S5Time Der Datentyp S5Time belegt ein 16-Bit Wort mit vier Dekaden. Die drei niederwertigen Dekaden stellen den Zeitwert dar, während die höchstwertige Dekade das Zeitraster enthält. Um den Wert zu lesen wird der Datentyp Word verwendet. Für die Konvertierung muss zunächst das Zeitraster bestimmt werden (Tabelle 6.21). Dekade Zeitraster (0000) 10 ms (0001) 100 ms (0010) 1 s (0011) 10 s Tabelle 6.21: Zeitraster des Datentyps S5Time in einem nächsten Schritt wird der gesamte Zeitwert in Millisekunden berechnet (Abbildung 6.12), bevor anschliessend die Darstellung nach der Methode in Abbildung 6.11 erstellt wird. 73

89 6 Realisierung im Programm Abbildung 6.11: Berechnung eines Wertes vom Datentyp Time_Of_Day Exportieren Das Exportieren der Daten ermöglicht es den gelesenen Datensatz in entfernten Trainingssystemen nutzen zu können. Dafür werden die gelesenen Daten in eine Konfigurations- Datei in den XML-Knoten ReadData eingefügt. Die Struktur dieses Knotens und seiner Unterknoten orientiert sich dabei an der bereits bekannten Datenstruktur im Programm S7-Real2Sim. Die Gliederung reicht daher von der S7Verbindung bis hin zu den einzelnen DBItems, da so vorhandene Strukturen mit minimalem Programmieraufwand bestens ausgenutzt werden können. Die Strukturierung des ReadData Knotens ergibt sich dementsprechend wie folgt. In der obersten Ebene befindet sich der ReadData XML-Knoten. Dieser ist zusätzlich mit einem Attribut timestamp versehen, welches als Wert den Zeitstempel des Datensatzes trägt. Darauf folgen Unterknoten für jede spezifizierte S7-Verbindung von der gelesen wurde. Die dazugehörigen Attribute sind in der Tabelle 6.22 dargestellt. Beispiel: <S7Connection name_in= OSS01_PCU1_OPC name_out= OSS01_PCU2_OPC readsucceeded= True cpustate= RUN > Als Unterknoten wird mindestens ein Knoten vom Typ RegisterTakeOverDB angelegt (vergleiche Kapitel ) über den der bereits bekannte TakeOver-DB spezifiziert wird. 74

90 6 Realisierung im Programm Abbildung 6.12: Berechnung eines Wertes vom Datentyp S5Time Tabelle 6.22: Attribute der XML-Knoten vom Typ S7Connection als Unterknoten von ReadData Attribut name_in name_out readsucceeded cpustate Beschreibung Name der S7-Verbindung im realen System äquivalenter Name der S7-Verbindung im Trainingssystem Boolscher Wert der aussagt ob der Datensatz dieser S7-Verbindung erfolgreich (true) gelesen wurde String mit dem CPU-Status zum Zeitpunkt des Lesezugriffs Zusätzlich werden für jeden Schatten-DB der jeweiligen S7-Verbindung ein XML-Unterknoten vom Typ DB hinzugefügt. Die dazugehörigen Attribute können der nachfolgenden Tabelle 6.23 entnommen werden. Beispiel: <DB name= DB1101 readsucceeded= True type= R2S_UDT_INST_ANA prefix= EM_$INST_NAME$/EM_$INST_NAME$_ANA_STD/ specialdb="false"> Entsprechend der vorhandenen Datenstrukturen, folgen für jeden Schatten-DB Unterknoten für die einzelnen Instanzen, die jeweils mit einem Attribut für den Instanz-Namen versehen sind (Tabelle 6.24). Beispiel: <Instance name= 783_1002 > 75

91 6 Realisierung im Programm Tabelle 6.23: Attribute der XML-Knoten vom Typ DB (ReadData) Attribut name readsucceeded type prefix specialdb Beschreibung Name des Schatten-DBs Bool scher Wert der aussagt ob der Datensatz dieses Schatten-DBs erfolgreich (true) gelesen wurde Name des DB-Typen Prefix für das Snapshot-Mapping Bool scher Wert der definiert ob es sich um einen Special-DB handelt (true) Tabelle 6.24: Attribute der XML-Knoten vom Typ Instance (ReadData) Attribut name Beschreibung Name der Instanz In der letzten Hierachriestufe werden den Instanzen die entsprechenden DBItems in eigenen Unterknoten vom Typ DB_Item zugeordnet. Diese verfügen über die in Tabelle 6.25 enthaltenen Attribute. Attribut Tabelle 6.25: Attribute der XML-Knoten vom Typ DB_Item (ReadData) Beschreibung name_in Name der OPC-Variable (Realsystem) name_out Name der OPC-Variable (Trainingssystem) description Variablenname value Gelesener Wert datatype Datentyp quality Wert der Quality-Eigenschaft (String) timestamp Zeitstempel des gelesenen Wertes length Länge. Lediglich entscheidend für Strings, ansonsten ist length = 1 address Byteadresse im Schatten-DB bitaddress Bitadresse im Schatten-DB. Wenn der Datentyp ungleich Bool ist, ist dieser Wert -1 Beispiel: <DB_Item name_in= S7:[OSS01_PCU1_OPC],DB1101,STRING,34,18 name_out= S7:[OSS02_SPLC1_ISO_OPC],DB1101,STRING,34,18 description= INST_NAME value= 783_1002 datatype= STRING quality= S_OK timestamp= :29:38 length= 18 address= 34 bitaddress= -1 /> 76

92 6 Realisierung im Programm Durch die Wiederverwendung der vorhandener Strukturen konnten bereits vorhanden Konstruktoren der jeweiligen Klassen einfach kopiert und durch die zusätzlichen Informationen erweitert werden. Ein Importieren eines Datensatzes ermöglicht es also, das Programm im weiteren Verlauf so zu benutzen, als ob die Daten an Ort und Stelle gelesen wurden. 6.5 Übernahme der Daten in das Trainingssystem Die Übernahme der Daten ins das Trainingssystem umfasst die in Kapitel 4.4 beschriebenen Funktionen. Dazu zählen das Manipulieren der Snapshot-Datei und das Schreiben der Daten in die SoftPLCs. Die entsprechenden Funktionen sind im Programm in das UserControl WriteToSnapShotControl ausgelagert worden (Abbildung 6.13). Abbildung 6.13: Das UserControl WriteToSnapShotControl mit dem die Daten in das Trainingssystem übernommen werden können Laden der Snapshot-Datei Ausgangspunkt ist ein geladener Snapshot. Dieser kann über die Schaltfläche Load Snapshot in das Programm geladen werden. Die Zeilen der Snapshot-Datei werden zunächst in eine List<String>geladen und alphabetisch sortiert. Anschliessend werden die Elemente der sortierten Liste in eine ObservableCollection vom Typ SnapshotItem (Tabelle 6.26) kopiert. 77

93 6 Realisierung im Programm ObservableCollection<SnapshotItem>SnapshotItems Tabelle 6.26: Properties der Klasse SnapshotItem Property Datentyp Beschreibung OriginalLine String Originale Zeile aus der Snapshot-Datei NewLine String Manipulierte Zeile FontColor_UI String String für die Schriftfarbe ValueChanged Bool Bool scher Wert, der angibt ob die Zeile geändert wurde oder nicht Die ObservableCollection SnapshotItems ist an die graphische Oberfläche gebunden und zeigt dort anhand der unter FontColor_UI definierten Schriftfarbe eventuelle Änderungen an. Durch den zusätzlichen Aufwand die Listen alphabetisch zu sortieren ist es im Folgenden möglich, Zeilen in diesen Listen anhand des Binary-Search-Algorithmus zu suchen. Diese Lösung ist deutlich performanter als eine iterative Suchen vom ersten bis zum letzten Element Anwenden der Mappingfunktionen Über einen Klick auf die Schaltfläche Apply Changes arbeitet das Programm die in der Konfiguration definierten Mappingmethoden ab. Hierfür war es zunächst erforderlich einen Algoritmus zu entwickeln, welcher aus einem einzelnen String Operatoren, Operanden und Klammern isolieren kann. Die Vorgehensweise dieser Methode beginnt damit, den String anhand der Leerzeichen aufzuteilen. Das Resultat wird in ein Array vom Datentyp String gespeichert. Beispiel Ausgangspunkt Resultat CO_2S OR FB_RUN2S ANDNOT CO_OFF { CO_2S, OR, FB_RUN2S, ANDNOT, CO_OFF } Für jede folgende Instanz, zu der dieser logischer Ausdruck gehört wird dieses Array kopiert. In dieser Kopie werden die Operanden durch die entsprechenden Werte aus dem gelesenen Datensatz bzw. dem Snapshot ersetzt. Ist dieser Prozess erfolgreich gewesen, erhält man einen logischen Ausdruck aus gültigen Werten und Operatoren, der nachfolgend gelöst werden muss. Die Lösung des Ausdrucks erfolgt iterativ. In einem ersten Schritt werden die vorangestellten drei Elemente des Arrays an eine Methode übergeben, gelöst und das Ergebnis 78

94 6 Realisierung im Programm als Rückgabewert zurückgeliefert. Bei den drei Elementen handelt es sich um einen einfachen logischen Ausdruck (zwei Operanden, ein Operator). Die ersten drei Elemente des urpsrünglichen Arrays werden durch das Ergbnis ersetzt und der nächste Teilausdruck kann gelöst werden. Da diese Methode auch für Ausdrücke mit Klammern gelten soll wurde sie entsprechend Beispiel Ausgangspunkt Übergebene Elemente Neues Array { True, OR, False, ORNOT, False } { True, OR, False } { True, ORNOT, False } erweitert. Diese Funktionsweise dieser Erweiterung ist in Abbildung 6.14 dargestellt. Für mathematische Ausdrücke gelten die oben beschriebenen Methoden analog mit der Abbildung 6.14: Ablaufdiagramm für das Lösen geklammerter Ausdrücke üblichen Operatorenrangfolge (Multiplikation und Division haben Vorrang vor Addition und Substraktion). 79

95 6 Realisierung im Programm Wurde eine Mappingfunktion für eine Instanz erfolgreich ausgewertet, so speichert das Programm das entsprechende Ziel im Snapshot und den neuen Wert in einer Liste ab. Sind alle Mappingmethoden ausgewertet wird diese Liste Element für Element abgearbeitet. Zunächst wird die entsprechende Zielzeile im Snapshot gesucht. Hierfür wird der Methode BinSearch der entsprechende String übergeben. Die Methode sucht diesen String mittels dem Binary-Search-Algorithmus in der Liste SnapshotItemsForBinSearch und liefert den Index des entsprechenden Listenelements zurück. Ist der Rückgabewert -1 konnte kein Element mit der Übereinstimmung gefunden werden. Der zurückgelieferte Index entspricht dem Index des äquivalenten SetInSnapshotItem s. Das Property NewLine wird anhand des neuen Wertes verändert und gespeichert, zudem wird die Flag ValueChanged auf True gesetzt und die Schriftfarbe für die graphische Benutzeroberfläche über das Property FontColor_UI geändert Abspeichern der Snapshot-Datei Für das Abspeichern des modifizierten Snapshots wird ein StreamWriter verwendet. Dafür wird die ObservableCollection SetInSnapshotItems Element für Element durchgearbeitet. Wobei dem StreamWriter jeweils das Property NewLine übergeben wird, welches in die neue Snapshot-Datei geschrieben wird Schreiben der Daten auf die SoftPLCs Das Schreiben des Datensatzes auf die SoftPLCs stellt den letzten Schritt der Datenübernahme dar. Hierfür verbindet sich das Programm analog wie in Kapitel bereits beschrieben zu dem OPC-Server des Trainingssystems. Es ist hierbei darauf zu achten das die Namen der S7-Verbindungen zwischen dem realen System und dem Trainingssystem variieren können. Entsprechend greift das Programm in diesem Fall auf den Namen der projektierten S7-Verbindung des Trainingssystems zurück. S7ConnectionName_OUT Das Schreiben der Daten erfolgt ebenfalls in separaten Threads für jede S7-Verbindung. Die entsprechende Worker-Klasse (WriteDataToPLC) ist im Namespace S7Real2Sim.OPC_Lib zu finden. Sie ist dabei dergestalt entwickelt das der Algorithmus für den Handler_DB (Abbildung 6.15) angewandt wird. 80

96 6 Realisierung im Programm Abbildung 6.15: Ablaufdiagramm für die Werte des R2S_DB_PROG_HANDLER im Falle eines Schreibzugriffs Zusätzliche Programmfunktionen Konfigurationseditor Zusätzlich zu den bereits beschriebenen Funktionen, verfügt das Programm über einen graphischen Editor für das Erstellen und Bearbeiten der Konfigurationsdateien (Abbildung 6.16). Das Programm unterstützt den Anwender damit den Benutzer beim Erstellen der Konfiguration. Durch Hilfetexte und die strukturierte Werkzeugleiste wird er Schritt für Schritt durch den Prozess geleitet. Zudem ist es möglich die UDTs aus PCS-7 zu exportieren und im Editor zu importieren. Das Programm erstellt anhand der aufeinanderfolgenden Variablen mit ihren jeweiligen Typen die DB-Typen mit den entsprechenden Adressen der einzelnen DBItems. 81

97 6 Realisierung im Programm Abbildung 6.16: Das UserControl CreateConfigControl zum Erstellen und Editieren der Konfigurationsdatei Kommandozeilen-Argumente Das Programm S7-Real2Sim kann optional auch mit Hilfe von Kommandozeilenargumenten gestartet werden. Durch die Übergabe der entsprechenden Parameter wird das Programm automatisch gestartet, läd eine angegebene Konfiguration, liest die Daten aus den Steuerungen und exportiert diese anschliessend. Die verfügbaren Kommandozeilenargumente sind in Tabelle 6.27 aufgelistet. Durch diese Tabelle 6.27: Parameter für das Starten via Kommandozeilenargumente Argument config export exportlog silent Beschreibung Gibt den Pfad der Konfigurationsdatei an Spezifiziert den Pfad für die Export-Datei Spezifiziert den Pfad für den export der Log-Datei Wird der Silent-Modus verwendet ( true ), werden keine Fenster des Programms angezeigt Funktion ist es möglich das Programm an eine Schaltfläche im WinCC anzubinden. Der Benutzer der OS kann das Auslesen des realen Systems direkt von seiner Bedienoberfläche aus starten. Ist zudem die WinCC Anbindung in der Konfiguration projektiert, 82

98 6 Realisierung im Programm lassen sich Statusmeldungen über den Fortschritt des Auslesens und den Zustand des Programmes an die WinCC-Oberfläche anbinden (Kapitel ) 83

99 7 Bewertung und Verifikation der Simulation 7 Bewertung und Verifikation der Simulation Mit dem erarbeiteten System in seinem Zustand zum Zeitpunkt der Abgabe dieser Diplomarbeit kann bereits eine Vielzahl an Typicals gelesen und initialisiert werden (Anhang A.2). Abbildung 7.1: HMI-Oberfläche der getesteten Prozesssimulation Für Validierungszwecke wurde das derzeitig bestehende System an einem einfachen Modell eines Kühlungssystems getestet (Abbildung 7.1). Das Modell bildet dabei das Kühlsystem eines Schiffsdiesels nach. Der Diesel (dunkelgraues Rechteck) gibt mit steigender Last mehr Wärme an die angeschlossen Kühlkreisläufe ab. Das Kühlsystem ist dabei in drei Kreisläufe aufgeteilt: dem Seawater-Kreislauf (SW, grün), dem Low-Temperature- Kreislauf (LT, hellblau) und dem High-Temperature-Kreislauf (HT, dunkelblau). Diese sind untereinander mit Wärmetauschern verbunden. Das Ziel der Datenübernahme besteht darin, das reale System mit den erarbeiteten Methoden auszulesen und das Trainingssystem entsprechend zu initialisieren. Gleichzeitig wurde der Kreislauf für das Seewasser auf eine zweite PLC ausgelagert, um zu testen ob 84