Anbindung eines WAGO IO Moduls in eine Client/Server-Umgebung

Transkript

1 Kleine Studienarbeit Anbindung eines WAGO IO Moduls in eine Client/Server-Umgebung eingereicht von Andreas Grumbach geboren am 6. März 1980 in Merseburg Matrikel Erstprüfer: Prof. Dr. Uwe Heuert Merseburg,

2 Inhaltsverzeichnis 1 Einführung Verwendete Hardware und Software Feldbus-Koppler Verfügbare IO-Klemmen von WAGO Verfügbare SCADA-Systeme Software-Entwicklungsumgebung Visual-Studio C-# Webservice Motivation und Ziel der Arbeit Automatisierung im Fokus Entwurf des verteilten Systems Anordnung der Hardwarekomponenten Anordnung der Softwarekomponenten Softwarekomponenten Webservice Client Implementierung 16 4 Ausblick 18 5 Zusammenfassung 20 2

3 1 Einführung 1.1 Verwendete Hardware und Software Feldbus-Koppler Der Feldbus-Koppler Wago verbindet das WAGO-SYSTEM über ETHERNET mit weiteren Netzwerkteilnehmern. Nach der Inbetriebnahme erkennt der Feldbus-Koppler die gesteckten I/O-Klemmen und erstellt daraus ein lokales Prozessabbild. Hierbei kann es sich um eine gemischte Anordnung von analogen (Datenaustausch wortweise) und digitalen (Datenaustausch bitweise) Klemmen handeln. Er eignet sich für Datenübertragungen von 10 MBit /s und 100 MBit /s. Der Koppler bietet mit einer Vielzahl unterschiedlicher Anwendungsprotokolle Abbildung 1.1: Wago Feldbuskoppler genügend Flexibilität zur Steuerung von Klemmendaten (Modbus oder ETHERNET/IP) oder für die Verwaltung und Diagnose des Systems (HTTP, BootP, DHCP, DNS, SNTP, FTP und SNMP). Die Konfiguration ist auf dem Koppler über eine Webseite vorzunehmen, wodurch 3

4 KAPITEL 1. EINFÜHRUNG spätere Änderungen durch unauthorisierte Personen vermieden werden. Für Web-basierte Anwendungen steht ein interner Server zur Verfügung, auf dem sich auch HTML Seiten hinterlegen lassen. Dieser Ansatz wird mit dieser Arbeit nicht verfolgt, da die Anwendungslogik auf dem Steuer-PC ausgeführt wird Verfügbare IO-Klemmen von WAGO Die Vielfalt der Wago-Funktionsmodule ist mit über dreihundert ein- bis 8-kanaligen Modulen auf die Bedürfnisse der Prozessautomatisierung, Gebäudetechnik, Messplatzautomatisierung und andere Anwendungsgebiete abgestimmt. Hier sollen beispielhaft fünf unterschiedliche Module verwendet werden, um einerseits analoge und digitale Eingänge sowie Ausgänge abzudecken. Dabei stehen folgende Klemmen zur Verfügung: Analoge Ausgangsklemme : Das Funktionsmodul 2 AO DC 0-10V verfügt über zwei analoge Ausgänge mit dem normierten Signal 0-10V. Beide Kanäle sind kurzschlussfest und werden in Zweidrahttechnik verbunden. Die Auflösung beträgt 12 Bit und entspricht in etwa 2,44mV. Analoge Eingangsklemme : Mit vier analogen Eingängen ist das Modul 4 AI DC 0-10V, Single Ended ausgestattet, wobei jeder Kanal mit 12 Bit aufgelöst ist. Diese Auflösung beziehtsich ebenfalls auf einen Gleichspannungbereich von 0 bis 10 V. Die Abtastung erfolgt im 10ms Takt. Analoge Eingangsklemme : Die zweite Analogeingangsklemme 2 AI DC 0-10V, Single Ended hat zwei Kanäle, welche bei einer Auflösung von 12 Bit mit 2ms abgetastet werden. Digitale Ausgangsklemme : Das Ausgangsmodul 2 DO DC 24V 0,5A, positiv schaltend besitzt zwei digitale Ausgänge, die mit steigender Flanke geschalten werden. Für jeden Kanal wird ein Bit verwendet, wobei die eindeutige Zuordnung der Bits aus der Klemmenanordnung resultiert. Digitale Eingangsklemme : Mit der digitalen Eingangsklemme 2 DI DC 24V 3,0ms, positiv schaltend können zwei Kanäle mit 3ms abgetastet werden Verfügbare SCADA-Systeme Die Abkürzung SCADA steht für Supervisory Control and Data Aquisition und umfasst Konzepte zur Steuerung industrieller Prozesse durch Kombination automatischer und menschlicher Eingriffe. Ähnlich dem Window-Konzept vieler PC-Programme sind die Benutzerschnittstellen kommerzieller SCADA-Systeme aufgebaut. Der verwendete Feldbuskoppler wird mit dem offenen Protokoll Modbus/TCP betrieben, was den entscheidenden Vorteil bringt, dass verschiedene 4

5 KAPITEL 1. EINFÜHRUNG SCADA-Anbieter zur Verfügung stehen. Dabei existieren neben kommerziellen Produkten auch OpenSource-Lösungen. Die Firmen Wonderware, Siemens (WinCC) [Win] und National Instruments (LabView) sollen beispielhaft genannt sein und stehen stellvertretend für industriellund laborerprobte Softwareprodukte mit umfangreichen Steuerungs- und Diagnosefähigkeiten. Zur Erzeugung von Benutzeroberflächen für das Wago-System sind die Programme Lintouch [LIN], JVisu [JVI] und VISUAL aus dem OpenSource-Bereich denkbar. Die Programmierung der grafischen Benutzerschnittstellen (englisch Human Machine Interface - HMI) mit den genannten SCADA-Systemen erfolgt teils mit der genormten Sprache Strukturierter Text (DIN EN ) und teils mit Hochsprachen(Java und C++) Software-Entwicklungsumgebung Visual-Studio 2005 Die von der Firma Microsoft angebotene integrierte Entwicklungsumgebung Visual-Studio 2005 Professionel Editon wird hier zur Erzeugung des Codes in der Sprache C-# verwendet. Neben dem Editor zur Entwicklung des Quellcodes ist ein grafischer Editor integriert, der zur Gestaltung von Benutzeroberflächen verwendet wird. In dieser Arbeit werden WindowsForms erzeugt, wobei umfangreiche Bibliotheken eine Spezialisierung der gewünschten Oberfläche bis hin zum industrietauglichen Design anbieten. Der mit der IDE (Integrated Developement Environment) zur Verfügung stehende Server (ASP.Net Developement Server) stellt zum Testen der Client- Server-Applikation die serverseitige Unterstützung dar. Das Testen und Debuggen der verteilten Anwendung wird erleichtert, weil beide Programmteile von der IDE ausgeführt werden C-# Die Sprache C-# (C-Sharp) ist von Microsoft entwickelt und 2001 von der ECMA (Europäische Normungsorganisation der Computer Hersteller) als Norm ECMA-334 C# veröffentlicht worden. Obwohl meist das propritäre.net-framwork im Zusammenhang mit C-# genutzt wird, ist C-# prinzipiell plattformunabhängig. Das Projekt Mono dient der C-#-Entwicklung auf Linux- Systemen. Neben Microsoft Visual Studio.Net gibt es mehrere OpenSource-IDE mit Erweiterungen für C-#. Basierend auf Elementen der Sprachen Java, C++, SQL, C und Delphi vereint C-# die Vorteile der aufgezählten Sprachen Webservice Ein Webservice ist eine Software-Anwendung, die über einen URI (Uniform Resource Identifier) eindeutig identifizierbar ist. Die Schnittstellen sind als XML-Artefakte definiert und beschrieben. Zur direkten Interaktion mit anderer Software werden XML-basierte Nachrichten verwendet, welche über Internetprotokolle ausgetauscht werden. Webservices sind an die Serviceorientierte Architektur (SOA) angelehnt und vereinen verteilte und objektorientierte Programmierstandards und sind in die Instanzen Konsument, Anbieter und Verzeichnis gegliedert. 5

6 KAPITEL 1. EINFÜHRUNG Abbildung 1.2: Funktionsweise eines Webservice (Quelle: Wikipedia) Hierbei stellt der Anbieter eine Veröffentlichung seiner Dienste in einem Verzeichnis bereit, welches vom Konsumenten durchsucht wird. Nach der Auswahl eines Dienstes und dem Austausch von Protokolldetails werden Anbieter und Konsument dynamisch verbunden, sodass der Konsument auf Methoden zurückgreifen kann. Es sind drei Standards zu nennen, welche den XML-basierten Datenaustausch beschreiben: UDDI UDDI ist ein Verzeichnisdienst zur Registrierung von Webservices und bedeutet Universal Description, Discovery and Integration. Der Dienst enthält Informationen zu Unternehmen, deren Daten und deren angebotene Services, wobei die Informationen hierarchisch verteilt sind auf White Pages, Yellow Pages und Green Pages. Bereits in 2005 wurde die Abschaltung der UDDI Business Registry durch IBM, Microsoft und SAP verkündet. WSDL Web Service Description Language ist die Bezeichnung für eine plattform- programmiersprachen und protokollunabhängige Meta-Sprache. Die XML-Spezifikation enthält Informationen zur Beschreibung von Funktionen, Daten, Datentypen und Austauschprotokollen eines Webservice. Die Web Service Description Language (WSDL) ist demnach ein Modell, in welchem XML Nachrichten ausgetauscht werden, sodass die Interpretation der abstrakten SOAP-Nachrichten durch eine spracheigene WSDL-Implementierung stattfindet. Das W3C [W3C03] spezifiziert WSDL-Bindings als Beschreibung für SOAP- Nachrichten, wobei ein Webservice aus einer Sammlung von Port-Typen besteht, welche die Details zur Interaktion beinhalten. Die Beschreibung einer Operation, deren Parameter und die Rückgabewerte der Operation sind im WSDL-Dokument enthalten: Angaben zur Schnittstelle Zugangsprotokoll und Details zur Verteilung 6

7 KAPITEL 1. EINFÜHRUNG Zugriffbezogene, maschinenlesbare Informationen Dabei werden die Services durch sechs XML-Hauptelemente definiert: Datentypen werden zum Austausch der Nachrichten benutzt. Nachrichten bestehen aus mehreren logischen Teilen, deren enthaltene Daten innerhalb eines Datentypsystems abstrakt definiert werden. Porttypen stellen eine Menge abstrakter Arbeitsschritte dar, welche in vier Typen zum Nachrichtenaustausch formuliert sind. Neben One-Way und Request-Response gibt es weiterhin die Typen Solicit-Response und Notification. Bindung ist die Festlegung eines Protokolls und eines Datenformats für Arbeitsschritte und Nachrichten des zugewiesenen Porttyps. Port spezifiziert eine Kommunikationsschnittstelle in Form einer URI. Services sind die Obermenge verwandter Ports. Die genannten sechs Hauptelemente werden wiederum in Abstrakte und Konkrete Definitionen unterteilt. Erstere sind Types, Messages und Porttypes. Zu den konkreten Definitionen zählen Bindings und Services. SOAP oder XML-RPC Das Simple Object Access Protocol ist ein Netzwerkprotokoll zum Austausch von Daten zwischen Systemen und zur Durchführung von Remote Procedure Calls (RPC). Das Protkoll setzt auf andere Protokolle der Transport- und Anwendungsschicht auf. Eine übliche Kombination ist SOAP auf HTTP und TCP. Die Regeln zum Nachrichtendesign enthalten die Abbildung von Daten und deren Interpretation innerhalb der Nachricht und die Konvention für entfernte Prozeduraufrufe mittels SOAP-Nachricht. Eine gebräuchliche Anwendung findet dann statt, wenn der direkte Zugang fremder Systeme zu einer Informationsquelle nicht sinnvoll erscheint. Das Protokoll fungiert in diesem Fall als Schnittstelle zwischen inkompatiblen Architekturen oder zur Entkopplung aus Security-Gründen. Durch eine Regelement der ausführbaren Methoden können Nutzungsbeschränkungen oder partieller Datenbankzugriff realisiert werden. Ein großer Nachteil des Protokolls sind die zu übertragenden Datenraten, welche einen einfachen boolschen Ausdruck der größe 1 Bit in ein Datenvolumen mehrerer hundert Kilobytes verwandelt. 1.2 Motivation und Ziel der Arbeit Eine Projektarbeit mit den Herren Alexander Gluschke, Andre Rosonsky und Christian Ulbrich (siehe [Ulb05] sowie [Glu05] und [Ros05]) hatte die Konzeption und Umsetzung einer Automatisierung für eine Spritzgussmaschine zum Gegenstand. Um die vorhandene Steuerungstechnik zum Zweck der Erweiterung nicht zu verändern, wurde sie konsequent durch geeignete Technologie ersetzt. Diese Technologie bestand unter anderem aus einem Feldbuskoppler

8 KAPITEL 1. EINFÜHRUNG der Firma Wago, der sich bereits in dieser Anwendung durch hohes Potenzial auszeichnete. Die gewünschte Automatisierung durch Kombination der Feldebene mit einem echtzeitfähigem Steuer-PC und der dezentralen Anbindung einer clientseitigen grafischen Bedienoberfläche konnte nicht funktionstüchtig umgesetzt werden. Mit dieser Arbeit werden weitere Technologien verwendet, um die gewünschte dezentrale Steuerung der Wago-Module zu realisieren. Durch Nutzung einer bereitgestellten Dynamic Link Library (DLL-Datei) dient das implementierte Protokoll Modbus-TCP mit seinen Funktionalitäten als Basis für die Entwicklung einer Benutzeroberfläche. Um besonders die Clientseite plattformunabhängig zu halten, fiel die Wahl auf Webservices, da die Konsumenten der angebotenen Services mit vielen unterstützten Sprachen umgesetzbar sind. Zusammengefasst hat die Kombination der hier verwendeten Hardware- und Softwarekomponenten genügend Freiheitsgrade zur Umsetzung anspruchsvoller Prozessautomatisierung bei gleichzeitig günstigem Preis-Leistungsverhältnis. 1.3 Automatisierung im Fokus Die Automatisierung technischer Prozesse begann vor mehreren tausend Jahren mit der Nutzung von Energie aus Wasser und Wind. Die Fortschritte auf den Gebieten der Physik, Mechanik und Antriebstechnik führten zur Industrialisierung. Das Ersetzen menschlicher und tierischer Energie durch Maschinen ermöglichte die Massenproduktion verschiedenster Güter in Fabriken. Die Steigerung der Produktion hing wesentlich von der Optimierung der Dauer einzelner Arbeitsschritte ab. Dabei standen mehrere Arbeitsschritte miteinander in Verbindung und beeinflussten sich gegenseitig. Zur Handhabung der Prozesskomplexität und der Prozessgeschwindigkeit waren neben Mess- und Steueraufgaben immer mehr Regelungen notwendig. Die Steuerungstechnik und die Regelungstechnik umfassen Verfahren zur Beschreibung von physikalischen Zusammenhängen mehrerer Größen eines Prozesses. Der Einfluss auf den Prozess durch Änderung von Eingangsgrößen mit entsprechender Aktorik kann als Grad der Automatisierung angesehen werden. In einem vollautomatisierten Prozess werden alle Eingangsgrößen durch Aktorik und alle Ausgangsgrößen durch Sensorik abgedeckt, sodass keine manuelle Korrektur notwendig ist. Die Ansteuerung der Sensoren und Aktoren auf der Feldebene dient der Entkopplung von Daten und Energie. Die Übertragung der Daten zwischen Prozessleitebene und Feldebene wird über unterschiedliche Busse abgewickelt, wobei die Anforderungen meist ähnlich sind. Das hier verwendete Wago I/O-Modul weist die beschriebenen Merkmale auf. Während die Datenübertragung über eine Ethernet-Verbindung als energiearm bezeichnet werden kann, stehen auf der Feldseite leistungsübertragende Module zur Wahl. Der Umfang verfügbarer Module erlaubt durch ein kaskadierbares Design die Automatisierung komplexer Prozesse. Als Bindeglied zum Bediener sind die Anforderungen an eine Benutzerschnittstelle stark variierend. Eine grafische Schnittstelle zwischen System und Benutzer bietet die Möglichkeit, visuelle Eindrücke zur Darstellung von Zuständen zu verwenden. Eine intuitive Schnittstelle lenkt den Bediener 8

9 KAPITEL 1. EINFÜHRUNG durch geeignete Stimulanzen, wie zum Beispiel Signal- oder Kontrastfarbgebung. Die Kunst am Produkt ist bei der GUI-Entwicklung darin zu sehen, alle relevanten Daten zur Verfügung zu stellen und trotzdem den Bediener nicht durch zu hohe Informationsdichte zu überfordern. Gängige Window-Systeme sind derart weit verbreitet, dass die Nutzung von Office-Produkten bis hin zu Entwickler-Software ähnliche Anforderungen an den Nutzer stellen, weil der grundlegende Aufbau sich gleicht. Nutzt man standardisierte Elemente zum Aufbau eines grafischen Frontend, so verbessert man die Bedienbarkeit und vermeidet möglicherweise Fehlbedienung. Pauschal kann festgehalten werden, dass eine gut bedienbare grafische Oberfläche die Aufmerksamkeit des Benutzers mit der Automatisierung im Fokus unterstützt. 9

10 2 Entwurf des verteilten Systems Im folgenden Kapitel wird der Aufbau des verteilten Systems beschrieben, welcher sich aus einer grundlegenden Idee heraus ergibt. Diese Idee war Teil des bereits beschriebenen Projektes Spritzguss und umfasste die Verwendung des Feldbuskopplers Wago und der Anbindung an einen Echtzeitrechner. Letzterer beherbergte das Echtzeit-Betriebssystems RTAI-Linux und band die Feldbusebene in das lokale Netzwerk ein. Ein weiterer Netzwerkteilnehmer sollte ein Bediener-PC sein, auf welchem eine grafische Benutzeroberfläche die Bedienung der Spritzgussmaschine realisierte. In diesem Projekt wurde die grafische Oberfläche mit dem OpenSource- Produkt JVisu entwickelt. Die gewünschte Kommuniktaion mit dem Feldbuskoppler wurde nicht erreicht. An dieser Stelle wird diese Problematik erneut thematisiert. Eine geeignete Technologie zur Kommunikation mit der gegebenen Hardware soll Plattform- und Sprachenunabhängigkeit als auszeichnende Eigenschaft aufweisen. Um den Entwicklungsaufwand gering zu halten und um vorhandene Implementierungen zu nutzen, wird eine von Wago bereitgestellte Treiber- DLL (Dynamic Link Library) verwendet, die das Modbus/TCP-Protokoll verfügbar macht. DLL-Dateien sind Windows-Dateien und enthalten Programmcode, Daten oder Ressourcen in beliebiger Kombination. Die besagte DLL beinhalte Elemente der Modbusfunktionalität und überträgt diese durch Einbinden der Datei MBTDLL.cs in den Quellcode. Die Grundfunktionen dienen der Verbindung mit dem Felbuskoppler und der Verbindungstrennung, dem Lesen und Schreiben einzelner Bits, Bytes und Strings, sowie dem Fehlermanagement. Die anschließende Liste ist ein Auszug der C-#-Datei MBTDLL.cs und enthält neben den Funktionen deren zu übergebende Parameter. Konstruktor MBTDLL() initialisiert die DLL Destruktor Destroy() löst die DLL Connect(string IpAddress, ushort Port, bool UseTCP,ushort TimeOut) verbindet zum Koppler mit der IP-Adresse Disconnect() trennt die Verbindung zum Koppler Read(ushort DataAddress, ref bool[] BoolData, bool Output) liest ein Bits aus (Read Coils) Read(ushort DataAddress, ref ushort[] WordData, bool Output) liest ein Wort(entspricht 2 Byte) aus (Read Words) 10

11 KAPITEL 2. ENTWURF DES VERTEILTEN SYSTEMS Read(ushort DataAddress, ushort Quantity, ref string TheString, bool Output) liest einen String aus (Read Strings) Write(ushort DataAddress, bool[] BoolData) schreibt ein Bit (Write Coils) Write(ushort DataAddress, ushort[] WordData) schreibt ein Wort (Write Words) Write(ushort DataAddress, string TheString) schreibt einen String (Write Strings) GetErrorMsg(int ErrorCode) gibt den Error-Code wieder GetErrorDesc(int ErrorCode) gibt die Beschreibung zum ErrorCode wieder Die geplante Benutzerschnittstelle soll es ermöglichen, ohne spezielle Vorkenntnisse einen dezentralisierten Datenaustausch durchzuführen. Dabei soll der Anwender von internen Strukturen entkoppelt sein und gewünschte Werte innerhalb fester Bereiche verändern dürfen. Die Interprozesskommunikation mit bestimmten Speicherbereichen wird im Hintergrund abgearbeitet, sodass die Arbeit mit einem bestimmten Modul durch einfache Auswahl der Position möglich wird. 2.1 Anordnung der Hardwarekomponenten Die in der Einführung erwähnten Komponenten sollen an dieser Stelle im Zusammenhang betrachtet werden. Der Feldbuskoppler verbindet die Feldebene (IO-Module) mit dem Netzwerk und somit mit einem Steuer-PC. Der Steuer-PC ist wiederum die Schnittstelle zwischen LAN und WAN (Wide Area Network). Die Aufgabenteilung ist dementsprechend durch den Aufbau der Hardware zu erkennen. Die prozessnahen IO-Module wandeln Daten in elektrische Größen und nehmen physikalische Größen auf. Die erwähnte Vielfalt möglicher Klemmen führt zu optimierten Kombinationen und lässt die Möglichkeit der individuellen Anordnung der Klemmen offen. Dies soll auch bei der Initialisierung der IO-Module beibehalten werden. Die frei anzuordnenden Module werden von der Software erkannt und die Reihenfolge per Index wiedergegeben. Der Feldbuskoppler stellt die Ethernet-Schnittstelle bereit und erzeugt ein Prozessabbild der vorhandenen Module. Das Prozessabbild enthält die Informationen über die Zuordnung der Module zu definierten Speicheradressbereichen. Die Anordnung digitaler und analoger Klemmen ist durch mechanische Sperren konstruktiv eingeschränkt. Die Distanz zwischen Koppler und Steuer-PC hängt vom Übertragungsmedium Ethernet ab (mit nicht industrietauglicher Hardware bewegt sich die maximale Entfernung im 100 Meter-Bereich). Der Steuer-PC ist mit einer weiteren Netzwerkschnittstelle ausgerüstet, welche die Verbindung zu einem weiteren Netzwerkknoten ermöglicht. Zur Entwicklung der Software sind der Steuer-PC als auch der Feldbuskoppler mit einem handelsüblichen Router (Asus Giga 1108N) verbunden, welcher auch die IP-Adressen vergibt und mit dem Campus-LAN verbunden ist. 11

12 KAPITEL 2. ENTWURF DES VERTEILTEN SYSTEMS 2.2 Anordnung der Softwarekomponenten Die Elemente dieser Softwarelösung werden als verteiltes System bezeichnet und sind in einer Client-Server-Architektur angeordnet. Der Feldbuskoppler stellt einen Modbus-Slave dar, welcher intern das Modbus-Protokoll implementiert und als Gegenstelle einen Modbus-Master erwartet. Die Datenübertragung basiert auf den Protokollen TCP/IP und erfolgt über den für Modbus reservierten Port 502. Der Slave spricht nur auf entsprechende Masterbefehle an, wobei man Datenkollisionen vermeiden kann, indem nur ein Master zugelassen wird. Die Möglichkeiten zur Beschränkung ergeben sich bei der Verwendung eines Steuer-PC durch Systemkomponenten oder Mittel der Programmiersprache. Die entwickelte Software ist in erster Linie Multiuser-fähig und müsste für eine Beschränkung erweitert werden. Der Modbus-Master ist der Steuer-PC, welcher unter Zuhilfenahme der Treiber-Datei MBT.dll die Kommunikation mit dem Koppler realisiert. Die oben beschriebenen Funktionen sind Bestandteil der DLL und werden über die C-#-Datei importiert. Eine weitere C-#-Datei verweist auf die MBTDLL.cs und stellt die Funktionen als Webservice bereit. Ein Server stellt den Webservice bereit und erlaubt einem Client-Programm eine verteilte Anwendung durch Konsumieren des Webservices. Das Client- Programm ist für zweierlei Aufgaben zuständig. Erstens ist es für die Weiterverarbeitung der Grundfunktionen zuständig und kann diese zu komplexen Funktionen kombinieren. Zweitens wartet das Client-Programm zur Datenpräsentation mit einer GUI auf. 2.3 Softwarekomponenten Webservice Der vom Server deployte Webservice kann als unabhängige Schnittstelle verstanden werden, welche unterschiedliche Sprachen und auch unterschiedliche Hardware miteinander verbindet. Die Sprache, mit welcher der Service selbst geschrieben ist, muss nicht unbedingt die Sprache des Clienten sein. Man erreicht diese Flexibilität durch die Verwendung der Beschreibungssprache XML. Die Datei Service1.asmx.cs beinhaltet den Webservice in Form der Programmiersprache C-# und ist auf der beigelegten CD zu finden. Die einzelnen Funktionen werden einleitend gekennzeichnet durch [WebMethod] und haben den Aufbau einer Methode. Der puplic-modifikator hebt alle Zugriffsbeschränkungen der Methode auf. Der Inhalt des Webservice ist auf die Funktionen der Treiber-Datei beschränkt. Es bietet sich an dieser Stelle an, weitere Funktionalitäten in der Webservice-Datei zu implementieren, welche wiederum auf den Grundfunktionen aufbauen, um die Funktionen des Clients gering zu halten. Eine Entscheidung, ob die Anwendung serverseitig oder clientseitig verarbeitet werden soll, kann von mehreren Faktoren abhängen. Ein wichtiges Kriterium ist es, einerseits den Datentransfer gering zu halten und andererseits die deterministische Abarbeitung eines Task zu gewährleisten. Indem die serverseitig vertriebenen Webservices auf die Grundfunktionen reduziert sind, wird zumindest der Transfer zwischen 12

13 KAPITEL 2. ENTWURF DES VERTEILTEN SYSTEMS Server und entfernten Client niedrig gehalten. Der Client dient dann aber nicht nur zur Visualisierung sondern auch zur Datenverarbeitung. Webservices können mit der Funktionalität einer nicht deployten Funktion ausgestattet werden. Deshalb ist ein anderer Ansatz zur Entwicklung eines verteilten Systems, mit dem Webservice die komplette Funktion anzubieten, sodass der Konsument des Webservices möglichst wenig Parameter zu konfigurieren hat. Am gegebenen Beispiel ist aus dieser Sicht zu diskutieren, wie ein Programmierer (welcher den Webservice konsumierenden Code schreibt) von der Konfiguration der Hardware (Feldbuskoppler mit Modulen) nur die aktuelle Konfiguration zur Verfügung gestellt bekommt. Der Client fordert somit die Daten eines bestimmten Kanals (z.b. Analog Output 1 ) an und bekommt die verfügbaren Parameter als Attribute der gewünschten Methode (z.b. Methode Ausgang schreiben, Modul AO1, Kanal 1, Wertebereich 0-10V DC) Client Der Client ist für den Anwender in erster Linie als Schnittstelle zur Wago-Einheit zu sehen. Mithilfe einer grafischen Oberfläche kann sich der Anwender mit dem IO-Modul verbinden und Daten austauschen. Diese Daten sind zuerst Informationen über den Aufbau und die Anordnung der Module. Es werden die in der Einführung beschriebenen Module von der Software erkannt, gezählt und zur Kommunikation interpretiert. Durch hartcodierte Daten kann einem Modultyp die Anzahl der Module und der Kanäle sowie der Wertebereich zugeordnet werden. Um die Übesichtlichkeit zu erhalten, wurden die Moduleigenschaften in eine Klasse Modul gepackt, welche in der Datei Modul.cs enthalten ist. Eine weitere Klasse der Clientsoftware ist DrawPanel.cs, wobei hier speziell zwischen boolschen und analogen Daten unterschieden wird. Die von Form abgeleitete Klasse Form2 ist die grafische Benutzeroberfläche für den Anwender. Da nur beispielhaft Module zur Verfügung stehen, konnte die Anordnung der einzlnen Bereiche zur Interaktion mit einem Modultyp statisch erfolgen. Man unterscheidet nach Ein- und Ausgängen sowie nach den Typen Digital- oder Analogklemme. Mit dem Start einer Verbindung wird der Webservice kontaktiert und eine Verbindung hergestellt. Teil des Verbindens ist auch die Anforderung des Prozessabbildes. Als Wiedergabewert wird eine Liste mit den vorhandenen Hardware-Komponenten des Koppler-Knotens an den Clienten weitergereicht. Alle Module werden in ihrer Reihenfolge im Fenster Module gelistet (Liste von oben nach unten entspricht HW von links nach rechts). Durch einen Vergleich wird die Anzahl der Klemmen ermittelt und im Fenster Vorhandene Klemmen im Knoten zugeordnet. Die Anzahl der Module wird als Eingangsparameter der Listenelemente genutzt, sodass die Auswahl der bestimmten Module zumindest im Bereich der tatsächlich vorhandenen Module liegen muss. Die gleiche Verfahrensweise führt zur Begrenzung der Kanäle pro Modul. Die Werte der Digitalklemmen werden in Wortform entweder als true oder false angezeigt. Analogwerte werden als Spannungen von 0 bis 10V dargestellt und auf zwei Nachkommastellen gerundet. Die Oberfläche enthält ein Fenster zur Darstellung von Graphen. Mit Delaytime kann die Abtastung getriggert werden, sodass 13

14 KAPITEL 2. ENTWURF DES VERTEILTEN SYSTEMS Abbildung 2.1: Grafische Benutzerschnittstelle Anwender auf die Eigenheiten verschiedener Module eingegangen wird. Nach Betätigen des Buttons Start Loop läuft eine Schleife, welche entsprechend der Delaytime die Werte des Moduls des gewählten Teilfensters grafisch anzeigt. Vor der Konzeption der User-Oberfläche wurden Möglichkeiten der Webservices und der Treiber-DLL getestet. Auf einer Lösung der Firma Wago aufbauend, welche das Modbusprotokoll in C-#-Code implementierte, wurde ebenfalls in C-# der Webservice geschrieben. Da alle Webmethoden im Namespace WagoInit enthalten sind, muss die Datei Service1.asmx.cs vom Server deployt werden. Die Benutzeroberfläche von Wago konnte weitestgehend übernommen werden. Während die GUI für den Anwender teils hart codiert ist, um eindeutige Bedienung zu gewährleisten, sind die Freiheitsgrade der GUI für den Administrator größer. Weiterhin werden die Eingaben unformatiert eingegeben, wodurch die Möglichkeiten des Clients unterstrichen werden. Beispielsweise werden Analogwerte mit 15 Bit-Auflösung (0x0000 bis 0x7ff9) auf einen Wertebereich von Teilern skaliert, was ungefähr 2,44mV pro Schritt entspricht. Die möglichen Funktionen sind an die Grundfunktionen angelehnt, sodass man die drei Typen Bool, Word und String sowohl lesen als auch schreiben kann. Der Zugriff auf sämtliche Speicherbereiche des Feldbuskopplers, beziehungsweise auf das Prozessabbild ist erlaubt. In der Spezifikation des Felbuskopplers sind Tabellen zur Adressierung der Modbus-Register für das Prozessabbild enthalten. Ebenso existieren Variablen zur Beschreibung der Konfiguration sowie Diagnosefunktionen, der Watchdog-Eigenschaften und interner Variablen. Außerdem sind ein Konstantenregister und Firmwareinformationen gespeichert. Dem Administrator wird 14

15 KAPITEL 2. ENTWURF DES VERTEILTEN SYSTEMS Abbildung 2.2: Grafische Benutzerschnittstelle Administrator mit der uneingeschränkten GUI ein Werkzeug zur ausführlichen Erforschung des Wago-Systems gereicht. Für weitere Programmierarbeiten wird vorgeschlagen, die zu implementierenden Funktionen mit der Admin-GUI zu testen. Die Konfiguration des Feldbuskopplers kann über Schreibund Lesezugriffe auf Register erfolgen oder über die von Wago auf dem Koppler hinterlegte Webseite. Diese erreicht man durch Aufruf der IP-Adresse des Kopplers. Zur Änderung benötigt man das Passwort Benutzer admin und das Kennwort wago. Hintergrund der Erläuterung an dieser Stelle ist die Vergabe der IP-Adresse des Kopplers, welche entweder statisch hinterlegt ist oder per DHCP von einem DHCP-Server angefordert wird. Mit dem Tool IP-Scan [Sof08] kann man die per DHCP empfangene IP-Adresse des Kopplers herausfinden, sodass der eigentliche Zugriff ermöglicht wird. 15

16 3 Implementierung Das Ziel dieser Kleinen Studienarbeit ist die Implementierung einer Schnittstelle zur dezentralen Kommunikation mit dem Wago-Feldbuskoppler über ein Netzwerk. Die Möglichkeiten zur Interprozesskommunikation via Ethernet sind vielfältig und werden durch das Anwendungsgebiet einer Software begrenzt. Neben der Programmierung von Sockets zeichneten sich Webservices durch viele, bereits angedeutete, Faktoren aus. Mit Visual Studio wird eine professionelle Entwicklungsumgebung genutzt, um die formulierten Webservices zu deployen und zu konsumieren. Alternativ zur praktizierten Variante ist die Kombination Java mit einer der Entwicklungsumgebungen Eclipse oder Netbeans denkbar. Für diese Arbeit ist jedoch die Verwendung der vorhandenen Modbus-Treiber-Datei entscheidend, welche erstens ein Windows-System verlangt und zweitens C-# bevorzugt. Der Grund hierfür ist die Datei MBTDLL.cs, deren Funktionalität somit ausgenutzt werden kann. Der Webservice soll an dieser Stelle nicht mehr betrachtet werden, da seine Funktionen sich aus dem Quelltext erschließen lassen. Der Aufbau des Clients GUI-Anwender wurde mit Bezug auf die Funktionen und die grafischen Elemente grob beschrieben. Die Besonderheiten sind im Detail zu finden. Folgendes Szenario gibt Einblick in den Client: 1. Mausklick auf Button Start Connection 2. per Fallentscheidung werden die bekannten Modultypen gezählt 3. Anzeige der Modulreihenfolge und der Anzahl jeden Typs, Beschränkung der Steuerelemente auf die tatsächliche Anzahl 4. Wahl eines analogen/digitalen Ausgangs/Eingangs durch Modul- und Kanalwahl 5. Wert ausgeben durch Mausklick auf Lesen 6. Wert eingeben durch Zahleneingabe und Mausklick auf Schreiben 7. Anzeige des aktuellen Wertes des gewählten Kanals 8. Anzeige des zum Kanal zugehörigen Graphen im Plot-Fenster Neben der Möglichkeit, Werte eines bestimmten Kanals zu lesen oder zu schreiben, ist die Oberfläche mit einem Plotfenster ausgestattet, welches pro Modul eine neue Tabpage öffnet. Die Reihenfolge der Tabs entspricht der Modulfolge. Es sind momentan Tabs für Digitalsignale 16

17 KAPITEL 3. IMPLEMENTIERUNG und Tabs für Analogsignale implementiert. Der jeweils ausgewählte Tab wird als einziger Plot gezeichnet, wodurch Systemressourcen geschont werden. Wechselt man nach dem Betätigen von Start Loop in einen anderen Tab, so wird dessen Plot im selben Zeitintervall dargestellt. Die parallele Abarbeitung mehrerer Kanäle wird durch eine Container erreicht, welcher eine Liste von Listen enthält. Letztere Listen enthalten die zugehörigen Wertepaare je einen Kanals, wobei der zeitliche Abstand zweier Werte durch die Delaytime bestimmt ist. Die Übersicht der Systemkomponenten zeigt neben der Anordnung der verteilten Systeme auch das Grundgerüst für weiterführende Programmieraufgaben. Abbildung 3.1: Übersicht der Komponenten des verteilten Systems 17

18 4 Ausblick Der mit dieser Arbeit entwickelte Code hat das Potenzial von Webservices genügend bewiesen. Es zeigt sich, dass mit der Hardware der Firma Wago (stellvertretend für ähnliche netzfähige Produkte) eine verteilte Anwendung über die dezentrale Automatisierung hinaus möglch ist. Nachdem der Webservice mit dem Client interagieren kann, sind die Möglichkeiten der Konfiguration zu testen. Es wurde bereits angedeutet, dass der Webservice mehr Funktionalität beherbergen kann. Über die Grundfunktionen hinaus ist anwendungsspezifisch festzuhalten, welche Aufgaben das verteilte System erfüllen soll. Anschließend ist zu entscheiden, ob der Task auf dem Client oder auf dem Server abgearbeitet wird. Für einen Ausbau der Software ist der Umfang zu erwerbender Klemmtypen zu beachten. Es ist zu prüfen, ob die Klemmtypen nach einem reproduzierbaren System bezeichnet werden. Der Vorteil eines solchen Systems wäre die einfache Integrierbarkeit weiterer Klemmen, ohne diese hart zu implementieren. Zur besseren Darstellbarkeit vieler Klemmen sind weitere Änderungen der Oberfläche nötig. Es ist denkbar, das Konzept der R&I-Fließbilder in due GUI zu integrieren, sodass ein bestimmter Prozess gehandelt werden kann. Für das Projekt Spritzguss scheint die Anwendung der Webservices geeignet, wenngleich sich verschiedene Probleme ergeben. Die Anbindung in ein Echtzeitbetriebssystem konnte nicht getestet werden. Da der Spritzgussprozess mit ca. 15s relativ kurz ist und keinerlei Eingaben seitens des Anwenders während des Spritzvorgangs erfolgen, bietet es sich an, das Client-Design zu ändern. Auf dem Steuer-PC sollten sich neben dem Webservice auch Möglichkeiten zur Archivierung der Messwerte bieten. Der Webservice selbst benötigt diverse Parameter, welche in endlicher Zeit von der GUI übermittelt werden. Ab der Initialisierung über einen Startbutton könnte der Prozess in Echtzeit ausgeführt werden, wenn der entsprechende Code vom Webservice entkoppelt ist. Mit Beendigung des Vorgangs werden die Daten über den Webservice dem Client übermittelt. Der Aufwand der Programmierung und die vorhandene Anfälligkeit gegen Programmierfehler wirken sich nachteilig auf die Verwendung propritärer Software aus. Für professionelle Projekte ist besonders aus Zeitgründen die Arbeit mit vorgefertigten GUI-Buildern zu bevorzugen. Virtuelle Instrumente können nur fehlerfrei eingesetzt werden, wenn das Instrument selbst fehlerfrei ist. Im Vorfeld dieser Arbeit wurde eine Lösung auf Basis der Hochsprache Java angestrebt. Die Technologie Webservices bietet sich als unabhängige Schnittstelle an, mehrere Lösungen miteinander zu vergleichen. Der größte Vorteil von Java dürfte in der Vielfalt der Hardware liegen, für welche eine Java Virtual Machine existiert. Als populärer Vertreter objektorientierter 18

19 KAPITEL 4. AUSBLICK Programmiersprachen ist Java nicht nur aufgrund seiner Portabilität für die Kommunikation in verteilten Systemen geeignet. Die Kombination industriell erprobter Hardware und freier Software offeriert besondere Reize und trägt durch eine wachsende Community zur Vielfalt der Anwendungen bei. 19

20 5 Zusammenfassung Mit dieser Arbeit wird die Implementierung eines IO-Moduls in eine Client-Server-Architektur beschrieben. Unter Berücksichtigung der Zielsetzung, kostengünstig und modularisiert zu entwickeln, wird das Baukastensystem 750 der Firma Wago verwendet. Auf Basis der von Wago zur Verfügung gestellten Modbus-Treiber werden Funktionen als Webservice bereitgestellt, wodurch ein dezentralisierter Zugriff und Plattformunabhängigkeit des Clients erzielt werden. Die Grundfunktionen des Modbus-Protokolls sind weiterhin die Grundlage für eine benutzerfreundliche Oberfläche. Zur Realisierung wird die Programmiersprache C-#verwendet. Das Ergebnis dieser Arbeit sind zwei funktionale grafische Oberflächen, die zur Bedienung verschiedener Ein- und Ausgabemodule dienen. Die erste Oberfläche lässt Schreib- und Lesezugriffe auf alle Speicherbereiche des Feldbuskopplers zu. Die zweite Oberfläche bietet mittels koordiniertem Zugriff auf die vorhandenen Module besseren Schutz vor Fehlbedienung und Fehlinterpretation der Einund Ausgabe. 20