Entwicklung einer Schnittstellensoftware für die Erfassung und

Transcription

Fachhochschul-Diplomstudiengang
SOFTWARE ENGINEERING
A-4232 Hagenberg, Austria
RM-Gateway:
Entwicklung einer Schnittstellensoftware für die
Erfassung und Auswertung von Prozessdaten einer
Bandverzinkungsanlage
Diplomarbeit
zur Erlangung des akademischen Grades
Diplom-Ingenieur (Fachhochschule)
Eingereicht von
Ing. Johannes Oppitz
Betreuer:
Begutachter:
Dipl.-Ing. Gerwich Emerstorfer, Tensor GmbH, Linz
FH-Prof. Dipl.-Ing. Dr. Herwig Mayr
Juni 2004
i
Eidesstattliche Erklärung
Ich erkläre an Eides statt, dass ich die Diplomarbeit selbstständig verfasst, keine anderen als die
angegebenen Quellen und Hilfsmittel verwendet und mich auch sonst keiner unerlaubten Hilfe
bedient habe. Ich versichere, dass ich diese Diplomarbeit bisher weder im In- noch im Ausland in
irgendeiner Form als Prüfungsarbeit vorgelegt habe.
Hagenberg, im Juni 2004
Johannes Oppitz
ii
Kurzfassung
Die Forderung nach lückenloser Aufzeichnung qualitätsrelevanter Daten von automatisierten
Produktionsanlagen erfordert die Integration der Prozessautomatisierung in die moderne Computertechnologie. Die besondere Herausforderung für die Integration dieser Systeme ergibt sich
durch die historische Entwicklung der Automatisierungstechnik und der teilweisen Verwendung
proprietärer Technik. Die Nutzungsdauer von Automatisierungskomponenten ist im Vergleich
zur Informationstechnologie um ein Vielfaches länger. Aus diesem Grund muss in vielen Fällen
vorhandene veraltete Automatisierungstechnik an neue Prozessdatenerfassungssysteme angebunden werden.
Das Unternehmen Tensor GmbH, Technisches Büro für Elektrotechnik und Informatik aus
Linz, ist seit 1992 im Bereich der Automatisierungs- und Prozessleittechnik für die Stahl- und
Aluminiumindustrie tätig und entwickelt seit 2003 ein Gateway-Konzept, das die Integration von
Automatisierungskomponenten erleichtert.
Die in der vorliegenden Diplomschrift beschriebene Arbeit beschäftigt sich mit der Entwicklung
einer speziellen Schnittstellensoftware, die in Zusammenarbeit mit der Firma Tensor entstanden
ist und bei einer Bandverzinkungsanlage der Firma Wuppermann Bandstahl GmbH eingesetzt
wird. Die Software wird als RM-Gateway bezeichnet und hat die Aufgabe, ein in der Anlage eingebautes radiometrisches Banddickenmessgerät des Herstellers Radiometrie/Thermo Electron
Corporation in die Automatisierungs- und IT-Struktur des Unternehmens zu integrieren. Bei der
entwickelten Lösung ist TCP/IP-Kommunikation mit dem Banddickenmessgerät und NetDDEKommunikation mit dem Prozessvisualisierungssystem Intouch realisiert. Weiters archiviert das
RM-Gateway die Informationen über das Längs- und Querprofil des verzinkten Stahlbandes in
der SQL-Datenbank des Betriebsdatenarchivs. Diese Daten werden mit dem Produktionsplanungssystem Sidero, das vom Wuppermann Datenservice GmbH entwickelt wurde, ausgewertet.
Mit der Installation des RM-Gateway konnte die Qualitätsdatenaufzeichnung der Bandverzinkungsanlage optimiert werden. Durch die Integration des Banddickenmessgerätes entfielen manuelle Dateneingaben durch das Bedienpersonal.
Die der Arbeit zu Grunde liegenden Technologien sind Microsoft .NET, C#.NET, ADO.NET,
asynchrone Socket-Kommunikation und eine eigenentwickelte COM-Komponente für die DDEKommunikation.
In Zukunft wird die Technologie der Prozessautomatisierung mit der Informationstechnologie
verschmelzen und damit auch Methoden und Systeme der Informationstechnologie verstärkt im
Bereich der Automatisierungstechnik Anwendung finden.
iii
Abstract
The demand for recording quality relevant data of automated manufacturing plants requires the
integration of process automation into modern information technology. Because of the historical
evolution of the automation and process control and the partial use of proprietary technique, the
integration of these systems is complex. The product cycle of automation components is considerably longer than the product cycle of the information technology. From this basis, available
obsolete automation equipment has to be connected in many cases to new process data acquisition systems.
The company Tensor GmbH, Technical Office for Electrical Engineering and Computer Science, located in Linz, has been active since 1992 in the area of automation and process control
for the steel and aluminum industry. The company has been developing a gateway concept for
facilitates integration of automation components since 2003.
The project described in this thesis deals with the development of specific interface software,
named RM-Gateway, in cooperation with Tensor GmbH. The task of the RM-Gateway is to integrate a radiometric strip thickness gauge of the manufacturer Radiometry/Thermo Electron
Corporation in the automation and IT structure of the galvanizing line. The system is used by the
company Wuppermann Bandstahl GmbH. This company supports a continuous galvanizing line
in the area of the Voest Alpine Stahl GmbH in Linz. The RM-Gateway uses TCP/IP to communicate to the strip thickness gauge and NetDDE to communicate to the process visualization
system Intouch. The RM-Gateway stores the length and cross profile data of the galvanized steel
strip in the SQL database of the process data archive. The data can be analyzed with the production planning system Sidero. This system has been developed by the company Wuppermann Datenservice GmbH.
The installation of the RM-Gateway has optimized the quality data recording of the galvanizing
line and has reduced manual data inputs.
The basic technologies used in this thesis project are Microsoft. NET Framework, C#.NET,
ADO.NET, Asynchronous Socket Communication, and a special COM component for the
DDE communication.
In future, the technology of the process automation will merge with the information technology.
For this reason methods and systems of the information technology will be intensely applied in
the field of the automation technology.
iv
Dank
Zuerst möchte ich mich bei meinen Eltern bedanken, die mich während meiner Ausbildung und
Studienzeit ständig unterstützt und damit die Basis für diese Arbeit und meine weitere Zukunft
geschaffen haben.
Meiner Frau Bianca und meiner Tochter Lena möchte ich für ihr Verständnis und ihre Geduld
danken, da während der Studienzeit unser Familienleben oft zu kurz gekommen ist.
Ein besonderes Dankeschön auch an die Mitarbeiter der Firma Wuppermann Bandstahl GmbH
und Wuppermann Engineering GmbH, insbesondere den Herrn Siegfried Killinger, Karl
Senegacnik und Wolfgang Nikodim, die diese Arbeit ermöglicht haben.
Weiters möchte ich den Betreuern dieser Arbeit, im Speziellen Herrn Gerwich Emerstorfer von
der Firma TENSOR Industrielle Elektrotechnik GmbH und Herrn Herwig Mayr von Seiten der
FH-Hagenberg einen herzlichen Dank für die Unterstützung und die Ratschläge bei der Erstellung dieser Diplomarbeit aussprechen.
Ebenfalls danke ich allen Mitarbeitern der Fachhochschule Hagenberg. Erst durch ihre Mithilfe
und ihren Einsatz wird die hervorragende Ausbildung an dieser Hochschule ermöglicht. Danken
möchte ich auch allen Studienkollegen für die gute Kameradschaft und die schöne Zeit an der
FH-Hagenberg.
An dieser Stelle möchte ich auch die Gelegenheit wahrnehmen, mich bei all meinen Freunden zu
bedanken, die mir in allen Lebenslagen stets hilfsbereit zur Seite gestanden sind.
Herzlichen Dank,
Johannes
v
Inhaltsverzeichnis
1 Einführung....................................................................................................................... 1
1.1
1.2
1.3
Motivation und Ziel des Projektes RM-Gateway ................................................................... 1
1.1.1
Projektanlass und Problemstellung ................................................................................. 1
1.1.2
Ziel des Projektes............................................................................................................... 1
Das Arbeitsumfeld ...................................................................................................................... 2
1.2.1
Das Unternehmen Wuppermann Bandstahl GmbH ................................................... 2
1.2.2
Das Unternehmen Tensor Industrielle Elektrotechnik GmbH.................................. 3
Kapitelübersicht........................................................................................................................... 3
2 Allgemeine Grundlagen ................................................................................................... 4
2.1
Technologie der Bandbehandlungsanlagen ............................................................................. 4
2.1.1
Aufgaben der Anlagen ...................................................................................................... 4
2.1.2
Grundlegender Aufbau ..................................................................................................... 4
2.1.3
Arten von Bandbehandlungsanlagen .............................................................................. 6
2.1.4
Spezielle Messgeräte in Bandbehandlungsanlagen........................................................ 6
2.2
Die Bandverzinkungsanlage II der Firma Wuppermann ...................................................... 8
2.3
Prozessautomatisierung ............................................................................................................ 10
2.3.1
Grundlagen der Prozessautomatisierung ..................................................................... 10
2.3.2
Entwicklung der Prozessautomatisierung .................................................................... 11
2.3.3
Zukunft der Automatisierungstechnik ......................................................................... 12
2.3.4
Automatisierungskonzepte............................................................................................. 12
2.3.5
Typisches Automatisierungskonzept einer Bandverzinkungsanlage........................ 14
2.3.6
Spezielle Anforderungen in der Stahlindustrie ............................................................ 14
2.4
Prozessvisualisierung ................................................................................................................ 14
2.5
Prozessdaten .............................................................................................................................. 16
2.6
Prozessdatenerfassung.............................................................................................................. 16
2.7
Prozessdatenanalyse.................................................................................................................. 17
3 Anforderungen an das RM-Gateway ..............................................................................18
3.1
Istzustand ................................................................................................................................... 18
3.1.1
Banddickenmessgerät...................................................................................................... 18
vi
3.1.2
Prozessvisualisierungssystem ......................................................................................... 18
3.1.3
Betriebsdatenarchiv ......................................................................................................... 19
3.1.4
Warenwirtschaftssystem ................................................................................................. 19
3.2
Automatisierungsumfeld .......................................................................................................... 19
3.3
Aufgabe des RM-Gateway ....................................................................................................... 19
3.4
Schnittstellen des RM-Gateway............................................................................................... 20
3.5
3.4.1
TCP/IP-Schnittstelle zum Banddickenmessgerät....................................................... 20
3.4.2
NetDDE-Schnittstelle zum Prozessvisualisierungssystem........................................ 23
3.4.3
SQL-Datenbankschnittstelle-Betriebsdatenarchiv...................................................... 23
Funktionen des RM-Gateway.................................................................................................. 24
3.5.1
Erfassung des Längsprofils ............................................................................................ 24
3.5.2
Erfassung des Querprofils.............................................................................................. 24
3.5.3
Parametrierung des Banddickenmessgerätes ............................................................... 24
3.5.4
Datenaustausch mit der Prozessvisualisierung............................................................ 25
3.5.5
Automatischer Verbindungsaufbau .............................................................................. 25
3.5.6
Historische Speicherung der Betriebszustände ........................................................... 25
4 Grundlegende Techniken .............................................................................................. 26
4.1
Microsoft .NET Framework ................................................................................................... 26
4.1.1
4.2
4.3
Datenbankschnittstelle ADO.NET .............................................................................. 27
TCP/IP-Kommunikation ........................................................................................................ 27
4.2.1
Grundlagen ....................................................................................................................... 27
4.2.2
Die Socket-Netzwerkschnittstelle ................................................................................. 28
4.2.3
Asynchrone Socket-Kommunikation mit C# ............................................................. 29
Windows DDE-Kommunikation ........................................................................................... 30
4.3.1
Interprozesskommunikation .......................................................................................... 30
4.3.2
Historische Entwicklung ................................................................................................ 31
4.3.3
Grundlegende Funktionen ............................................................................................. 31
4.3.4
Einsatz von DDE in der Automatisierungstechnik ................................................... 32
4.3.5
DDE-Kommunikation mit C# ..................................................................................... 33
5 Konzeption und Design................................................................................................. 34
5.1
Systemdesign .............................................................................................................................. 34
vii
5.2
5.3
5.1.1
Architektur........................................................................................................................ 34
5.1.2
Schnittstellen .................................................................................................................... 36
5.1.3
Datenhaltung .................................................................................................................... 37
Komponentendesign................................................................................................................. 38
5.2.1
Übersicht........................................................................................................................... 38
5.2.2
Die Klasse ConnectionManager.................................................................................... 39
5.2.3
Die Klasse GaugeInterface............................................................................................. 39
5.2.4
Die Klasse HMIInterface ............................................................................................... 39
Benutzerschnittstellen-Design................................................................................................. 41
5.3.1
Konfigurations- und Diagnosetool ............................................................................... 41
5.3.2
Prozessvisualisierungssystem ......................................................................................... 41
6 Implementierung ........................................................................................................... 44
6.1
Verwendete Entwicklungsumgebung..................................................................................... 44
6.2
Allgemeine Vorgehensweise .................................................................................................... 45
6.3
6.2.1
Auswahl des Betriebssystems für das RM-Gateway................................................... 45
6.2.2
Auswahl der Entwicklungsumgebung und der Programmiersprache...................... 45
6.2.3
Vorgehensmodell für die Entwicklung des RM-Gateway ......................................... 45
Komponentenentwicklung ...................................................................................................... 46
6.3.1
Die Klasse InterfaceManager......................................................................................... 46
6.3.2
Die Klasse UserInterface................................................................................................ 46
6.3.3
Die Klasse ConfigurationManager................................................................................ 46
6.3.4
Die Klasse ConfigFileInterface ..................................................................................... 47
6.3.5
Die Klasse ConnectionManager.................................................................................... 47
6.3.6
Die Klasse GaugeInterface............................................................................................. 47
6.3.7
Die Klasse GaugeRawTelegram .................................................................................... 48
6.3.8
Die Klasse HMIInterface ............................................................................................... 49
6.3.9
Die Klasse DDELib........................................................................................................ 50
6.3.10
Die Klasse DBInterface.................................................................................................. 51
7 Test und Inbetriebnahme.............................................................................................. 53
7.1.1
Das Testen im Umfeld der Prozessautomatisierung .................................................. 53
7.1.2
Die Inbetriebnahme im Umfeld der Prozessautomatisierung .................................. 53
viii
7.2
Integrationstest der Schnittstelle zum Banddickenmessgerät ............................................. 54
7.3
Integrationstest der Schnittstelle zur Prozessvisualisierung................................................ 55
7.4
Integrationstest der Datenbankanbindung ............................................................................ 55
7.5
Inbetriebnahme und Installation............................................................................................. 55
7.6
Erfahrungen ............................................................................................................................... 56
8 Zusammenfassung......................................................................................................... 57
8.1
Erreichte Ziele ........................................................................................................................... 57
8.2
Offene Punkte ........................................................................................................................... 57
8.3
Resümee und Ausblick ............................................................................................................. 57
ix
Abbildungsverzeichnis
Abbildung 1.1: RM-Gateway Schnittstellenübersicht................................................................2
Abbildung 1.2: Die Wuppermann Gruppe (Quelle: [Wuppermann, 2004]) ..............................2
Abbildung 2.1: Typische Bandbehandlungsanlage (Quelle: [VAI, 2004]) ................................5
Abbildung 2.2: Banddickenmessgerät (Quelle: [Volmer, 2004])...............................................7
Abbildung 2.3: Banddickenmessung - Radioaktive Messmethode (Quelle: [Volmer, 2004])...7
Abbildung 2.4: Bandverzinkungsanlage II - Wuppermann Bandstahl (Quelle: [VAI, 2004])...9
Abbildung 2.5: Bandlaufschema der Bandverzinkungsanlage II (Quelle: [VAI, 2004])...........9
Abbildung 2.6: Technischer Prozess - Prozessrechensystem (Quelle: [Bolch, 2004]..............10
Abbildung 2.7: Entwicklung der Prozessautomatisierung (Quelle: [Schröder, 2003])............13
Abbildung 2.8: Typisches Automatisierungskonzept einer Anlage (Quelle: [Bolch, 2004]) ..13
Abbildung 2.9: Automatisierungskonzept einer Verzinkungsanlage (Quelle: [VAI, 2004])...15
Abbildung 2.10: Bedienoberfläche einer Prozessvisualisierung (Quelle [VAI, 2004]) ...........16
Abbildung 3.1: Schnittstellen des RM-Gateway ......................................................................20
Abbildung 4.1: .NET Frameworkarchitektur (Quelle: [Heinzelreiter, 2003]) .........................26
Abbildung 4.2: .Architektur von ADO.NET (Quelle: [Heinzelreiter, 2003]) ..........................27
Abbildung 4.3: Gegenüberstellung TCP/IP-OSI (Quelle: [Plate, 2004a]) ...............................28
Abbildung 4.4: Datenaustausch Client-Server (Quelle: [Plate, 2004b]) ..................................29
Abbildung 4.5: Eigenschaftsdialog der DDE-Freigabe............................................................32
Abbildung 5.1: Architektur der RM-Gateway-Schnittstellensoftware.....................................34
Abbildung 5.2: Betriebsdatenarchiv – relevante Tabellen für das RM-Gateway.....................37
Abbildung 5.3: Übersichts-Klassendiagramm RM-Gateway...................................................38
Abbildung 5.4: Zustandsdiagramm der externen Schnittstellen...............................................39
Abbildung 5.5: Klassendiagramm GaugeInterface ..................................................................40
Abbildung 5.6: Klassendiagramm HMIInterface .....................................................................40
Abbildung 5.7: Benutzerschnittstelle Konfigurationstool ........................................................41
Abbildung 5.8: Benutzerschnittstelle Diagnosetool: General ..................................................42
Abbildung 5.9: Benutzerschnittstelle Diagnosetool: Log.........................................................42
Abbildung 5.10: Benutzerschnittstelle des Banddickenmessgerätes........................................43
Abbildung 5.11: Benutzerschnittstelle des Banddickenmessgerätes: Trend ............................43
x
Abbildung 6.1: RM-Gateway: Integrierte Test- und Entwicklungsumgebung ........................44
Abbildung 7.1: Testsoftware für TCP/IP-Schnittstelle Banddickenmessgerät ........................54
xi
Tabellenverzeichnis
Tabelle 2.1: Beispiele für Hersteller von Prozessvisualisierungssystemen..............................15
Tabelle 3.1: Daten des Banddickenmessgerätes.......................................................................18
Tabelle 3.2: Daten des Prozessvisualisierungssystems ............................................................19
Tabelle 3.3: Aufbau der Telegramme.......................................................................................21
Tabelle 3.4: Telegrammtypen...................................................................................................22
Tabelle 3.5: DDE-Daten an RM-Gateway ...............................................................................22
Tabelle 3.6: DDE-Daten von RM-Gateway .............................................................................22
Tabelle 3.7: DDE-Daten bidirektional......................................................................................23
Tabelle 4.1: Asynchrone .NET Socket-Methoden....................................................................30
1 Einführung
1
1.1
1.1.1
1
Einführung
Motivation und Ziel des Projektes RM-Gateway
Projektanlass und Problemstellung
Die Firma Wuppermann Bandstahl GmbH betreibt in Linz eine Bandverzinkungsanlage und
stellt mit dieser Anlage verzinktes Stahlband her. Die Anlage befindet sich im Gelände der Voest
Alpine Stahl GmbH.
In dieser Anlage ist ein radiometrisches Banddickenmessgerät installiert, welches kontinuierlich
das Längs- und Querprofil der Banddicke des produzierten verzinkten Stahlbandes misst. Diese
Messdaten können nicht automatisiert im Betriebsdatenerfassungssystem archiviert werden, da
die proprietäre TCP/IP-Schnittstelle des Banddickenmessgeräts nicht in die Automatisierungsstruktur der Anlage eingebunden ist. Die Bedienung und Parametrierung des Banddickenmessgerätes erfolgt manuell.
1.1.2
Ziel des Projektes
Ziel des Projektes war es, das Banddickenmessgerät in die Automatisierungs- und IT-Struktur der
Anlage einzubinden. Damit wurde die Qualitätsdatenaufzeichnung der Anlage optimiert und aus
der Analyse dieser Daten eine Verbesserung der Prozessführung ermöglicht.
Für diese Aufgabe war es notwendig eine spezielle Schnittstellensoftware, die als RM-Gateway
bezeichnet wird, zu entwickeln. Das RM-Gateway kommuniziert mit dem Banddickenmessgerät
über die vorhandene TCP/IP-Schnittstelle und berechnet aus den Messwerten statistische Daten,
die in der Datenbank des Betriebsdatenerfassungssystems gespeichert werden (siehe Abbildung
1.1).
Weiters besitzt das RM-Gateway eine NetDDE-Schnittstelle zur Kommunikation mit dem vorhandenen Prozessvisualisierungssystem. Über diese Schnittstelle werden aktuelle Messwerte, Sollwerte, Parameter und Befehle übertragen. Mit diesen Daten können die aktuellen Messwerte des
Banddickenmessgerätes den richtigen Produktdaten zugeordnet werden. Zusätzlich besteht die
Möglichkeit der automatischen Parametrierung des Banddickenmessgerätes.
Mit dieser Schnittstellensoftware ist es auch möglich, den aktuellen Zustand des Banddickenmessgerätes im Prozessvisualisierungssystem der Anlage zu visualisieren und das Messgerät im
Anlagenleitstand zu bedienen.
1 Einführung
2
Messrahmen
Stahlband
Prozessvisualisierung
(Intouch 7.1)
Prozessdaten
Setupdaten
Istwerte
Banddickemessgerät
(M100 Radiometrie)
Istwerte
Setupdaten
Produktdaten
Betriebsdatenarchiv
(MS SQL Server)
RM-Gateway-Schnittstellenrechner
mit Schnittstellensoftware
Abbildung 1.1: RM-Gateway Schnittstellenübersicht
1.2
1.2.1
Das Arbeitsumfeld
Das Unternehmen Wuppermann Bandstahl GmbH
Das Unternehmen Wuppermann Bandstahl GmbH ist Teil der Wuppermann Gruppe. Diese
wird geleitet und verwaltet von der Wuppermann AG als Unternehmensholding. Produktion und
Vertrieb erfolgen durch zehn rechtlich selbstständige Unternehmen (vgl. Abbildung 1.2). In den
drei Geschäftsbereichen Stahlflachprodukte, Technische Produkte sowie Engineering und Beratung wird eine breite Palette von Erzeugnissen und Leistungen auf der Basis von Stahl für viele
Branchen angeboten. Mit Produktionsstandorten in Europa sowie Vertriebsstützpunkten in Europa und den USA folgt Wuppermann seinen Kunden im stetig wachsenden Weltmarkt (vgl.
[Wuppermann, 2004]).
Abbildung 1.2: Die Wuppermann Gruppe (Quelle: [Wuppermann, 2004])
1 Einführung
1.2.2
3
Das Unternehmen Tensor Industrielle Elektrotechnik GmbH
Die Forderung nach immer besseren Qualitätssicherungsmaßnahmen, besonders seitens der Automobilindustrie, bedarf einer lückenlosen Archivierung der Produkt- und Betriebsdaten der Anlagen, welche durch dieses Projekt verbessert werden konnten. Als Projektpartner wurde das
Technische Büro Tensor Industrielle Elektrotechnik gewählt, das bereits seit langer Zeit mit der Firma
Wuppermann bei der Optimierung und Weiterentwicklung ihrer Produktionsanlagen zusammenarbeitet und auch diese Diplomarbeit betreute.
Die Firma Tensor beschäftigt sich seit mehr als 10 Jahren mit der Automatisierungs- und Prozessleittechnik im Bereich der Stahl- und Aluminiumindustrie. Hauptschwerpunkte sind die
Softwareentwicklung für Systeme der Antriebstechnik, Industrielle Regelungstechnik, Steuerungstechnik und Prozessleittechnik sowie das Engineering und Projektmanagement (vgl. [Tensor,
2004]).
1.3
Kapitelübersicht
Kapitel 1 gibt dem Leser einen kurzen Einblick in das Ziel und die Motivation des Projektes RMGateway. Weiters werden die am Projekt beteiligten Unternehmen vorgestellt.
Kapitel 2 beinhaltet Allgemeines zum Thema Bandbehandlung, Prozessautomatisierung und Prozessdatenanalyse. In diesem Zusammenhang werden wichtige Begriffe näher erläutert.
Kapitel 3 behandelt den Istzustand, die Ziele sowie die gestellten Anforderungen an das RMGateway. Weiters werden die Schnittstellen der Software detailliert spezifiziert.
Kapitel 4 vermittelt die Grundlagen der bei diesem Projekt eingesetzten Technologien im Bereich
der Softwareentwicklung. Hierzu zählen TCP/IP-Kommunikation und DDE-Kommunikation.
Kapitel 5 setzt sich mit dem Design und dem Konzept der erstellten Schnittstellensoftware auseinander. Klassendiagramme geben Einblick in das Design des Systems, die Realisierung der Benutzerschnittstellen wird ebenfalls gezeigt.
Kapitel 6 beschäftigt sich mit der Implementierung der entwickelten Software. Es werden allgemeine Punkte zur Realisierung behandelt und implementierungsspezifische Besonderheiten vorgestellt.
Kapitel 7 beinhaltet Erkenntnisse und Erfahrungen mit dem Test und der Inbetriebnahme der
Software und behandelt dabei die Besonderheiten in der Stahlindustrie.
Kapitel 8 stellt erreichte Ziele und ungelöste Probleme gegenüber. Hier wird auf den Stand der
Entwicklung und auf zukünftige Erweiterungen eingegangen.
2 Allgemeine Grundlagen
2
4
Allgemeine Grundlagen
2.1
Technologie der Bandbehandlungsanlagen
2.1.1
Aufgaben der Anlagen
Bandbehandlungsanlagen (engl. Strip Processing Lines) dienen dazu, warm oder kalt gewalztes Stahlband (engl. Strip) weiter zu verarbeiten, indem es gebeizt, geglüht, verzinkt oder beschichtet wird.
Das Vormaterial kommt normalerweise in Form von Blechrollen (engl. Coils) zu den Anlagen.
2.1.2
Grundlegender Aufbau
Der Transport des Bandes in den Anlagen erfolgt mittels speziell angeordneter, angetriebener
Rollen die als S-Block bezeichnet werden. Dazu kommen eine meist hohe Anzahl an Umlenk- und
Unterstützungsrollen. Für das Auf- und Abwickeln des Stahlbandes werden angetriebene Dorne,
die als Haspeln bezeichnet werden, verwendet. Das gesamte Band in der Anlage steht unter Spannung, dem so genannten Bandzug.
Bandbehandlungsanlagen werden in folgende grundlegende Abschnitte unterteilt:
•
Einlauf (engl. Entry Section),
•
Einlaufspeicher (engl. Entry Looper),
•
Prozessteil (engl. Process Section),
•
Auslaufspeicher (engl. Exit Looper),
•
Auslauf (engl. Exit Section).
Im Einlaufteil einer Anlage werden die Coils abgewickelt, das Band durchläuft den Prozessteil und
verlässt nach dem Aufhaspeln im Auslaufteil die Anlage wieder in Form von Coils. Der Prozessteil der Anlagen wird kontinuierlich betrieben und ist durch Bandspeicher vom Einlauf und Auslaufteil der Anlagen entkoppelt.
Ist im Einlauf ein Coil vollständig abgewickelt, stoppt der Einlauf und wechselt auf einen neuen
Coil. Dabei wird das Band des alten Coils mit dem Band des neuen Coils verschweißt. Während
dieser Zeit wird der Prozessteil vom Einlaufspeicher versorgt. Nachdem der Einlauf wieder gestartet hat, transportiert er das Band schneller in den Einlaufspeicher als der Prozessteil das Band
entnimmt. Dadurch wird der Speicher gefüllt. Der Auslaufspeicher hat im Prinzip die gleiche
Aufgabe wie der Einlaufspeicher. Im Auslauf werden die Coils aufgewickelt. Nachdem ein Coil
die erforderliche Bandlänge erreicht hat, stoppt der Auslauf und startet nach dem Abziehen des
Bundes vom Aufhaspel erneut.
5
Der Prozessteil der Anlagen unterscheidet sich nach der Behandlungsart des Bandes. Weiters
befinden sich noch spezielle Maschinen und Aggregate in der Anlage, die das Band beispielsweise
reinigen, erwärmen, kühlen oder walzen.
In Abbildung 2.1 ist schematisch die Feuerverzinkungsanlage 3 der Voest Alpine Stahl GmbH
dargestellt: Im Einlaufbereich (engl. Entry Section) der Anlage wird das Stahlband alternierend von
zwei Abhaspeln abgewickelt und mit einer automatischen Schweißmaschine (engl. Welder) verschweißt. Dann durchläuft das Band den Reinigungsbereich (engl. Cleaning) in dem die Oberfläche gereinigt wird. Es folgt der Einlaufspeicher (engl. Entry Looper) bei dem es sich bei der Beispielanlage um einen vertikalen Schlingenspeicher handelt. Im Ofen (engl. Furnace) wird das Band
auf ca. 500 - 800ºC mit Gasbrennern und elektrischer Induktionserwärmung erhitzt. Im Ofen
befindet sich eine Schutzatmosphäre aus Stickstoff und Wasserstoff damit das Band bei den hohen Temperaturen nicht oxidiert. Direkt vom Ofen gelangt es in den Beschichtungsteil (engl.
Coating Section). Dort durchläuft es den Zinkpot, der mit flüssigem Zink gefüllt ist. Auf der Oberfläche des Bandes bildet hat sich dadurch eine Zinkschicht die mit Lüftdüsen auf die geforderte
Schichtdicke reduziert wird. Nun wird das Band im Kühlturm (engl. Cooling Tower) abgekühlt.
Dann durchläuft es das Dressiergerüst (engl. Skin Pass Mill) und den Streckrichter (engl. Tension
Leveller) in denen die Oberfläche und die mechanischen Eigenschaften des Bandes verbessert
werden. In der Chromatierung (engl. Chromating) wird das Band mittels einer Chrom-Lösung vollständig vor Oxidation geschützt. Nach dem Auslaufspeicher (engl. Exit Looper) wird das Band im
Auslaufbereich (engl. Exit Section) abwechselnd von zwei Aufhaspeln aufgewickelt.
Abbildung 2.1: Typische Bandbehandlungsanlage (Quelle: [VAI, 2004])
2.1.3
6
Arten von Bandbehandlungsanlagen
Im folgenden Abschnitt werden wichtige Arten von kontinuierlichen Bandbehandlungsanlagen
kurz erklärt. Diese verschiedenen Anlagen werden bei Bedarf auch zu einer Gesamtanlage kombiniert und verarbeiten je nach Anlagentyp zwischen 200.000 – 2,000.000 Tonnen Stahlblech pro
Jahr.
Beizanlagen (engl. Continuous Pickling Lines)
In Beizanlangen wird warm gewalztes Stahlband mechanisch und mit Säuren von der Oxydschicht auf der Oberfläche (Zunder) befreit.
Verzinkungsanlagen (engl. Hot Dip Galvanizing Lines)
Verzinkungsanlagen dienen zum Beschichten von Stahlbändern mit Zink. Die Beschichtung erfolgt entweder mittels flüssigen Zinks oder durch elektrische Galvanisierung.
Bandbeschichtungsanlagen (engl. Colour Coating Lines)
Mit diesen Anlagen wird das Stahlband gereinigt, grundiert und lackiert.
Glühanlagen (engl. Continuous Annealing Lines)
Kontinuierliche Glühlinien dienen zum Glühen des Stahlbandes nach dem Kaltwalzen um die
mechanischen Eigenschaften des Bandes zu verändern.
2.1.4
Spezielle Messgeräte in Bandbehandlungsanlagen
Für die Stahlindustrie wurde eine Vielzahl von speziellen Messgeräten entwickelt um den Herstellungsprozess kontrollieren und analysieren zu können. Für besondere Einsatzfälle sind diese Geräte auch geeignet, in sehr rauer Umgebung oder bei sehr hohen Temperaturen zu arbeiten.
Folgende spezielle Messgeräte werden typischerweise in Bandbehandlungsanlagen eingesetzt:
Schichtdickenmessgeräte
Schichtdickenmessgeräte messen die Zink- oder Lackschichtdicke der Beschichtung von Stahlband. Das in der Stahlindustrie eingesetzte Messprinzip basiert auf radioaktiver Strahlung.
Banddickenmessgeräte
Diese Messgeräte messen, meist mittels einer radioaktiven Messmethode, die Banddicke kontinuierlich in der laufenden Anlage. In Abbildung 2.2 ist ein für Bandbehandlungsanlagen typischer
Messrahmen eines Banddickenmessgeräts dargestellt.
7
Abbildung 2.2: Banddickenmessgerät (Quelle: [Volmer, 2004])
Da bei dem Projekt RM-Gateway ein Banddickenmessgerät als Kommunikationspartner vorhanden ist, wird nun kurz auf die verwendete radioaktive Messmethoden eingegangen.
Wie in Abbildung 2.3 dargestellt, wird unter dem Stahlband eine radioaktive Strahlungsquelle
(engl. Radiation Source) angebracht, die das Stahlband durchstrahlt. Das Stahlband absorbiert einen
Teil der radioaktiven Strahlung. Auf der Oberseite des Bandes befindet sich ein Strahlungsmessgerät (engl. Detector), das die eintreffende radioaktive Strahlung misst. Aus der Intensität der gemessenen Strahlung wird die Banddicke berechnet (vgl. [Volmer, 2004]).
Abbildung 2.3: Banddickenmessung - Radioaktive Messmethode (Quelle: [Volmer, 2004])
Abgesehen von der sehr robusten radioaktiven Messmethode kommen bei verschiedenen Anwendungen auch Messprinzipien wie die Laser-Dickenmessung (siehe [Tensor, 2004]) oder die
Banddickenmessung mit elektrischen Wirbelströmen (siehe [ABB, 2004]) zum Einsatz.
8
Planheitsmessrollen
Mit Planheitsmessrollen kann die Spannungsverteilung des Stahlbandes in Querrichtung (Planheit)
kontinuierlich während des Produktionsprozesses gemessen werden.
Bandbreitenmessgeräte
Bandbreitenmessgeräte messen die Bandbreite des Stahlbandes in der laufenden Anlage. Es werden Laserscanner oder CCD-Zeilenkameras eingesetzt, die die Bandbreite unabhängig von der
Bandlage erfassen.
Bandlagemessgeräte
Bei Bandbehandlungsanlagen wird das Band mittels Lenkrollen und Bandlaufregelungen mittig in der
Anlage gehalten. Zur Erfassung der aktuellen Bandlage werden induktive, kapazitive oder optische Bandlagemessgeräte eingesetzt.
Bandzugmessgeräte
Für den Transport des Bandes in der Anlage ist ein definierter Bandzug zwischen den Rollen
erforderlich. Der Bandzug wird von angetrieben Rollen, die das Band transportieren, aufgebracht
und geregelt. Zur Messung des genauen Bandzuges werden Bandzugmessgeräte eingesetzt, die
meist mit Hilfe von Dehnungsmessstreifen die Messung des Bandzuges durchführen.
Temperaturmessgeräte
Diese Messgeräte messen die Temperatur des Bandes, in vielen Anwendungsfällen auch im Inneren von Öfen. Es werden Strahlungspyrometer eingesetzt, die mit Hilfe der Wellenlänge der emittierten Infrarotstrahlung des Stahlbandes die Temperatur berechnen.
2.2
Die Bandverzinkungsanlage II der Firma Wuppermann
Bei der in Abbildung 2.4 dargestellten Bandverzinkungsanlage II der Firma Wuppermann Bandstahl GmbH handelt es sich um eine spezielle Art einer Verzinkungsanlage. Üblicherweise verarbeiten Verzinkungsanlagen kalt gewalztes Stahlband. In dieser Anlage wird warm gewalztes, längs
geteiltes Stahlband verarbeitet. Damit kann in der Produktionskette das Kaltwalzen und Glühen
des Bandes entfallen. Eine weitere Besonderheit ist die Möglichkeit der Produktion von schmäleren Bändern deren Bandkanten auch verzinkt und damit korrosionsgeschützt sind.
Im Gegensatz zu den mit Gasbrennern beheizten Öfen erfolgt bei dieser Anlage die Erwärmung
des Bandes induktiv in einem sehr kompakten Ofen mit leistungsfähigen wassergekühlten Induktionsspulen. Damit kann der Dimensionswechsel des produzierten Stahlbandes sehr flexibel erfolgen, da die abgegebene Heizleistung bei der induktiven Erwärmung wesentlich rascher verändert werden kann als bei gasbeheizten Öfen.
9
Abbildung 2.4: Bandverzinkungsanlage II - Wuppermann Bandstahl (Quelle: [VAI, 2004])
In Abbildung 2.5 ist das Bandlaufschema der Bandverzinkungsanlage II der Firma Wuppermann
dargestellt (vgl. Abbildung 2.1). Im Einlaufbereich (engl. Entry Section) der Anlage wird das Stahlband mit einem Abhaspel abgewickelt. Es folgt der Einlaufspeicher, der bei dieser Anlage als
Spiralspeicher (engl. Spiral Accumulator) ausgeführt ist.
Abbildung 2.5: Bandlaufschema der Bandverzinkungsanlage II (Quelle: [VAI, 2004])
10
Die Vorteile des Spiralspeichers liegen in den geringen Abmessungen, der hohen Bandkapazität
und der besonderen Eignung für schmälere Bänder. Nach dem Speicher gelangt das Band in den
Reinigungs- bzw. Beizteil (engl. Pickling). Das Band wird danach im Ofen mittels elektrischer Induktionserwärmung (engl. Induction Heating) erhitzt und durchläuft dann den Zinkpot (engl. Zinc
Pot). Auf der Oberfläche des Bandes bildet sich eine Zinkschicht, die mit Lüftdüsen (engl. Air
Knife) auf die geforderte Zinkschichtdicke reduziert wird. Nun wird das Band mit Luftkühlung
(engl. Air Cooling) und in einem Wasserbecken (engl. Water Quench) abgekühlt. Dann durchläuft es
den Streckrichter (engl. Tension Leveller) und gelangt nach einer chemischen Passivierung (engl.
Passivation) in den horizontalen Auslaufspeicher (engl. Hoziontal Looper). Im Auslaufbereich (engl.
Exit/Delivery Section) wird das Band bei Bedarf geölt und von einem Aufhaspel aufgewickelt.
2.3
2.3.1
Prozessautomatisierung
Grundlagen der Prozessautomatisierung
Prozessautomatisierung ist jenes Teilgebiet der Informatik, das sich mit dem Einsatz von Rechensystemen für das Messen, Überwachen, Steuern, Regeln und auch Optimieren technischer Prozesse
befasst. Wie in Abbildung 2.6 dargestellt, ist die Hauptaufgabe der Prozessautomatisierung aus
Kenntnis der Istwerte von Messgrößen und vorgegebener Sollwerte auf Stellgeräte so einzuwirken und etwaiges Bedienpersonal so über Betriebszustände zu informieren, dass der technische
Prozess in der gewünschten Weise abläuft (vgl. [Bolch, 2004]).
Abbildung 2.6: Technischer Prozess - Prozessrechensystem (Quelle: [Bolch, 2004]
Ein technischer Prozess ist ein Prozess, dessen Zustandsgrößen mit technischen Mitteln gemessen,
gesteuert und geregelt werden können (vgl. [DIN, 1981]). Um die Automatisierung eines techni-
11
schen Prozesses durchführen zu können, werden seine Ausgangsgrößen durch Sensoren (Messgrößen) gemessen und seine Eingangsgrößen mittels Aktoren (Stellgrößen) beeinflusst.
Ein Prozessrechensystem ist eine Datenverarbeitungsanlage, die direkt mit dem technischen Prozess
gekoppelt ist und die Steuerungs- und Regelungsaufgaben in Abhängigkeit der Messgrößen, den
Vorgaben des Bedienpersonals und den Vorgaben von anderen Rechensystemen durchführt.
Störungen können den Zustand eines Prozesses beeinflussen und werden im Normalfall vom Prozessrechensystem kompensiert (siehe Abbildung 2.6).
Bei einfacheren Anlagen werden als Prozessrechensysteme meistens Speicherprogrammierbare Steuerung (SPS), im englischen als Programmable Logic Controller (PLC) bezeichnet, eingesetzt. Dabei
handelt es sich um spezielle programmierbare Mikrorechner, die Automatisierungsaufgaben ausführen.
Die Prozessautomatisierung umfasst folgende Aufgaben:
•
Datenerfassung (Messwerte werden erfasst),
•
Auswertung der erfassten Messwerte,
•
Steuerung,
•
Regelung,
•
Überwachung (Protokolle, Störungen),
•
Führung (Eingriff in den Prozess, damit er in der gewünschten Weise abläuft),
•
Optimierung (Eingriff in den Prozess, damit er in optimaler Weise abläuft).
Nach [Bolch, 2004] wird die Prozessautomatisierung in folgende zwei Gruppen unterteilt:
1. Produktautomatisierung: Prozessautomatisierungssysteme, bei denen der technische Prozess in
einem Gerät oder einer einzelnen Maschine, meist zur Produktion von hohen Stückzahlen, abläuft.
2. Anlagenautomatisierung: Prozessautomatisierungssysteme, bei denen der technische Prozess aus
einzelnen Teilvorgängen (Teilprozessen) besteht, die auf größeren, zum Teil auch räumlich ausgedehnten technischen Anlagen ablaufen.
2.3.2
Entwicklung der Prozessautomatisierung
Die Entwicklung der Prozessautomatisierung wird in acht Stufen unterteilt (vgl. [Wilson, 1999],
[Bolch und Vollath, 1993]):
•
bis 1940: keine Automatisierung (die Betätigung der Stellorgane erfolgt per Hand),
•
1940-1950: Vorstufe der Automatisierung (einfacher Leitstand, mechanische Bedienung),
•
1950-1960: erste Stufe der Automatisierung (fernbedienbare Stellglieder und Messfühler),
•
1950-1960: zweite Stufe der Automatisierung (Regler werden eingeführt),
•
1950-1960: dritte Stufe der Automatisierung (Einführung modularer Hardwarebausteine),
•
1950-1960: vierte Stufe der Automatisierung (Verknüpfung der modularen Bausteine),
•
ab 1960: fünfte Stufe der Automatisierung (Prozessrechner),
•
ab 1975: sechste Stufe der Automatisierung (Mikrorechner, SPS),
•
ab 1980: siebte Stufe der Automatisierung (Vernetzung der Mikrorechner, Bussysteme),
•
ab 1990: achte Stufe der Automatisierung (Embedded Systems, Ubiquitous Computing).
12
Die Vorläufer der heutigen Steuerungen waren Steuerungen, die aus den herkömmlichen Schützsteuerungen entstanden sind. Das erste Konzept einer SPS wurde 1968 von einer IngenieurGruppe der Hydromatik-Abteilung bei General Motors konzipiert (vgl. [Wilson, 1999]). Ihre Anwendung beschränkte sich anfangs auf großtechnische Anlagen wie Walzwerke, komplexe Förderanlagen oder chemische und petrochemische Produktionsprozesse. In der Folge wurden zunehmend kleinere Steuereinheiten angeboten, deren Einsatz auch für einfachere Maschinen technische und wirtschaftliche Vorteile brachte.
Ursprünglich noch in konventioneller Halbleiter-Technologie aufgebaut, führte der wachsende
Einsatz von Mikroprozessoren zum Durchbruch der SPS auf allen Gebieten der Automatisierungstechnik. Die Systeme wurden flexibler, leistungsfähiger, kostengünstiger und konnten somit
mehr und mehr die konventionellen Steuerungen der Relais- und Schütztechnik verdrängen.
2.3.3
Zukunft der Automatisierungstechnik
Auf Grund der kostengünstigen Computer- und Kommunikationshardware sowie der Möglichkeit der offenen Kommunikation werden die Automatisierungstechnik und Informationstechnologie immer weiter verschmelzen und Methoden wie beispielsweise Mobile-Computing, Webbasierte Systeme, Data-Warehouse, Data-Mining verstärkt in der Automatisierungstechnik eingesetzt.
In Zukunft wird Software eine zentrale Stelle in der Automatisierungstechnik übernehmen. Auch
die Forderung nach ausgereiften Manufacturing-Execution-Systems (MES), die das Interface zwischen
der Produktion und dem Management bilden, wird die Innovation in der Automatisierungstechnik vorantreiben (vgl. [Schröder, 2003]).
Die Prozessautomatisierung stellt einen wichtigen Wachstumsmarkt dar. Ein Überblick über den
prognostizierten Umsatz der Branche im Jahr 2010 ist in Abbildung 2.7 dargestellt.
2.3.4
Automatisierungskonzepte
Ein Automatisierungskonzept definiert, wie ein Prozessrechensystem aufgebaut ist, um damit
einen konkreten technischen Prozess zu kontrollieren
13
Abbildung 2.7: Entwicklung der Prozessautomatisierung (Quelle: [Schröder, 2003])
Dabei wird das Prozessrechensystem in drei Kommunikationsebenen aufgeteilt (siehe Abbildung
2.8):
•
Ebene 1 - Feldebene: Prozessnahe Feldbussystem (Kommunikation SPS-Sensoren, -Aktoren),
•
Ebene 2 - Prozessebene: Anlagenbus (Kommunikation SPS-SPS, SPS-PC, SPS-Leitrechner),
•
Ebene 3 - Betriebsebene: Fabrikbus (Kommunikation Leitrechner-Produktionsplanung).
Abbildung 2.8: Typisches Automatisierungskonzept einer Anlage (Quelle: [Bolch, 2004])
In diesem Zusammenhang wird auch von Level 1-3 der Automation gesprochen:
•
Level 1 Automation: Automatisierung auf SPS Ebene (Steuerung, Regelung),
•
Level 2 Automation: Prozessvisualisierung (Beobachten, Bedienen, Protokollieren),
•
Level 3 Automation: Produktionsplanungssysteme (Statistik, komplexe Modelle).
2.3.5
14
Typisches Automatisierungskonzept einer Bandverzinkungsanlage
Das Automatisierungskonzept einer größeren Anlage stellt ein verteiltes System dar, das aus verschiedenen, mit unterschiedlichen Bussystemen vernetzten Teilsystemen und Komponenten besteht.
In Abbildung 2.9 ist das vereinfache Automatisierungskonzept einer Feuerverzinkungsanlage
dargestellt. In der unteren Ebene befinden sich die Automationssysteme, Antriebssystem und
Feldbuskomponenten. In der oberen Ebene sieht man die Prozessvisualisierungs- und Produktionsplanungssysteme sowie die Engineering Stationen, die für die Instandhaltung und Programmierung der Anlagen verwendet werden. Die Vernetzung der einzelnen Komponenten erfolgt mit
Ethernet TCP/IP sowie mit speziellen Feldbus-Systemen wie dem Profibus [Profibus, 2004]. Auf
Grund der großen zu überbrückenden Entfernungen erfolgt die Übertragung der Daten auch mit
Lichtwellenleiter.
2.3.6
Spezielle Anforderungen in der Stahlindustrie
Bei Prozessen in der Stahlindustrie handelt es sich meist um sicherheitsrelevante technische Prozesse.
Automationssysteme in der Stahlindustrie haben spezielle Anforderungen in Bezug auf Verfügbarkeit, Sicherheit, Ausfallsicherheit und Geschwindigkeit, da die kontrollierten technischen Prozesse technologische Gefahren beinhalten. Das Automationssystem muss so konzipiert sein, dass
der Prozess mit hoher Wahrscheinlichkeit auch bei Störungen und Systemausfällen in einem sicheren Zustand bleibt oder übergeführt werden kann. Ansonsten kann eine Gefährdung von
Menschen und Umwelt oder die Zerstörung der Anlagen die Folge sein.
Für diese Anforderungen kommen spezielle Konzepte zum Einsatz, die auf redundanter Hardware
und Software basieren und in der Lage sind, Störungen von Teilsystemen zu egalisieren.
2.4
Prozessvisualisierungssysteme, auch als Human-Machine-Interface (HMI) bezeichnet, bilden die
Schnittstelle zwischen dem Automatisierungssystem und dem Bedienpersonal. In Abbildung 2.10
ist eine typische Bedienoberfläche eines Prozessvisualisierungssystems für eine Bandverzinkungsanlage dargestellt.
15
Abbildung 2.9: Automatisierungskonzept einer Verzinkungsanlage (Quelle: [VAI, 2004])
Moderne Prozessvisualisierungssysteme arbeiten auf einem Standard-PC mit einer speziellen Visualisierungssoftware. Für die Kommunikation mit den SPS-Systemen hat sich TCP/IP durchgesetzt. In Tabelle 2.1 sind einige Beispiele für Hersteller von Prozessvisualisierungssystemen aufgelistet.
Produkt
Hersteller
Verweis
Intouch
Wonderware
[Wonderware, 2004]
Factory Link
Technomatrix
[Technomatrix, 2004]
zenON
Copa-Data
[Copadata, 2004]
WinCC
Siemens
[Siemens, 2004]
Tabelle 2.1: Beispiele für Hersteller von Prozessvisualisierungssystemen
16
Abbildung 2.10: Bedienoberfläche einer Prozessvisualisierung (Quelle [VAI, 2004])
2.5
Prozessdaten
Prozessdaten sind während der Produktion anfallende physikalische, gemessene Istwerte.
Es erfolgt eine Unterscheidung in:
•
direkt am Produkt gemessene Größen, so genannte Produktdaten (nach Produktionsende
noch am Produkt messbar),
•
der Produktionsanlage zugeordnete Daten, d.h. allgemein im Prozess anfallende Daten, die
nicht direkt einem Produkt zugeordnet werden können.
2.6
Prozessdatenerfassung
Bei der Prozessdatenerfassung werden die Soll- und Istwerte eines technischen Prozesses sowie
die Daten des Automatisierungssystems in einer Datenbank gespeichert. Für diese Aufgabe ist
eine Schnittstelle zum Automatisierungssystem der Anlage erforderlich.
17
Auch Prozessvisualisierungssysteme wie in Tabelle 2.1 angeführt, können für diese Aufgaben
eingesetzt werden, da die Systeme bereits Schnittstellen zu Automatisierungssystemen besitzen
und zusätzlich die Möglichkeit bereitstellen, Daten zyklisch oder ereignisgesteuert in einer SQLDatenbank zu speichern.
2.7
Prozessdatenanalyse
Die Prozessdatenanalyse beschäftigt sich mit der Analyse der historischen Prozessdaten, die mittels Prozessdatenerfassung (siehe Kapitel 2.6 ) in einer Datenbank archiviert wurden.
Ziel ist es, einerseits qualitätsrelevante Daten für einen späteren Nachweis strukturiert zu speichern und andererseits aus der Analyse der Daten Erkenntnisse zu gewinnen, mit denen der Betrieb der Anlagen optimiert werden kann (Beispiele: vorbeugende Wartung der Anlage, Schwachstellenanalyse). Als Werkzeug wird unter anderem Data-Mining verwendet.
3 Anforderungen an das RM-Gateway
3
18
Anforderungen an das RM-Gateway
3.1
Istzustand
3.1.1
Banddickenmessgerät
Das in der Bandverzinkungsanlage installierte radiometrische Banddickenmessgerät besitzt eine
eingeschränkte Schnittstelle zum Prozessleitsystem bzw. Automatisierungssystem der Anlage.
Dabei werden folgende digitale Signale ausgetauscht:
•
der Längenimpuls, aus dem die Bandlänge und die Bandgeschwindigkeit abgeleitet werden
und
•
die Signalisierung des Bandwechsels (Schweißnaht).
Abgesehen von diesen digitalen Signalen ist der Betrieb des Gerätes autonom. Die aktuellen
Banddaten werden manuell über die Bedienkonsole des Banddickenmessgerätes eingegeben und
die qualitätsrelevanten Daten werden über einen Drucker, der direkt mit dem Banddickenmessgerät verbunden ist, ausgedruckt.
Bei dem Messgerät ist eine Ethernet TCP/IP-Schnittstelle für den Datenaustausch vorgesehen.
Die Schnittstelle wird aber derzeit nicht verwendet. Über diese Schnittstelle sollen in Zukunft
Setupdaten, Sollwerte, Istwerte und Befehle mit dem Gerät ausgetauscht werden. Das proprietäre
TCP/IP-Kommunikationsprotokoll ist vom Hersteller ausführlich dokumentiert. Die Details der
Kommunikation sind in [Radiometrie, 1999] spezifiziert.
Der Hersteller des Banddickenmessgerätes hat keine Softwarekomponente für die beschriebenen
Kommunikationsaufgaben im Lieferumfang, die in eine gängige Programmiersprache eingebunden werden kann. Allgemeine Daten des Banddickenmessgerätes sind in Tabelle 3.1 zusammengestellt.
Hersteller
Radiometrie Erlangen
Type
Dicken- und Flächenmess-System M100
Baujahr
1999
Tabelle 3.1: Daten des Banddickenmessgerätes
3.1.2
Prozessvisualisierungssystem
Das in der Anlage eingesetzte Prozessvisualisierungssystem wird für die Visualisierung, Bedienung und Diagnose der gesamten Bandverzinkungsanlage verwendet. Das System kommuniziert
19
mit dem Automatisierungssystem der Anlage (Reliance-Automax), mit dem Betriebsdatenarchiv
und mit dem Warenwirtschaftssystem (Sidero). Allgemeine Daten des Prozessvisualisierungssystems sind in Tabelle 3.2 zusammengestellt.
Hersteller
Wonderware
Type
Intouch Version 7.1
Tabelle 3.2: Daten des Prozessvisualisierungssystems
3.1.3
Betriebsdatenarchiv
Für die Produktionsdatenerfassung ist eine Microsoft SQL-Datenbank installiert. Vom Prozessvisualisierungssystem und vom RM-Gateway werden in dieser Datenbank die aktuellen Produktionsdaten archiviert.
3.1.4
Warenwirtschaftssystem
Das Warenwirtschafts- und Produktionsplanungssystem Sidero, bei dem es sich um eine Eigenentwicklung der Wuppermann Datenservice GmbH handelt, verwaltet alle produktionsrelevanten
Daten und stellt den Produktionsanlagen Sollwerte zur Verfügung. Eine weitere Aufgabe ist die
Verwaltung, Analyse und Präsentation der Produktionsdaten.
3.2
Automatisierungsumfeld
Das Automatisierungs- und Antriebssystem der Anlage basiert auf einem Reliance-Automax System (vgl. [Reliance, 2004]) das über ein Netzwerk mit dem Prozessvisualisierungssystem kommuniziert (siehe Kapitel 3.1.2). Die Signale der Sensoren und Aktoren werden zum Großteil über
dezentrale Ein-/Ausgangsmodule verarbeitet und sind über einen Feldbus an das RelianceAutomax System angebunden.
3.3
Aufgabe des RM-Gateway
Die Hauptaufgabe des RM-Gateway ist die Integration des Banddickenmessgerätes in die Automatisierungsstruktur der Anlage. Um das zu erreichen, muss das RM-Gateway mit dem Banddickenmessgerät, dem Prozessvisualisierungssystem und dem Betriebsdatenarchiv der
Bandverzinkungsanlage kommunizieren. Eine Schnittstellenübersicht ist in Abbildung 3.1 dargestellt. Die Details dieser Schnittstellen sind in Kapitel 3.4 spezifiziert. Zusätzlich besitzt das RMGateway spezielle Funktionen, die in Kapitel 3.5 definiert sind.
3.4
20
Schnittstellen des RM-Gateway
In Abbildung 3.1 sind die Schnittstellen des RM-Gateway dargestellt. Die Pfeile 1-4 stellen den
Datenaustausch dar.
Ethernet TCP/IP
Messrahmen
2
1
Stahlband
(Intouch 7.1)
RM-GatewaySchnittstellenrechner
4
(M100 Radiometrie)
3
Konfigurations- und
Diagnosetool
Betriebsdatenarchiv
(MS SQL Server)
Legende:
1 TCP/IP Schnittstelle Banddickenmessgerät
2 NetDDE Schnittstelle Prozessvisualisierung
3 ADO.NET SQL-Datenbankschnittstelle
4 TCP/IP Schnittstelle Konfigurations- und Diagnosetool
Abbildung 3.1: Schnittstellen des RM-Gateway
3.4.1
TCP/IP-Schnittstelle zum Banddickenmessgerät
Wie bereits in Kapitel 3.1.1 erwähnt, besitzt das Banddickenmessgerät eine Ethernet TCP/IPSchnittstelle. Dieses Kapitel betrachtet die für das RM-Gateway relevanten Telegramme. Die
vollständige Definition aller definierten Telegramme ist in [Radiometrie, 1999] spezifiziert. Weiterführende Informationen zur TCP/IP-Kommunikation sind in Kapitel 4.2 zu finden.
Grundlegender Aufbau der Telegramme
Der Aufbau der Telegramme ist in Tabelle 2.1 definiert.
Besonderheiten der Codierung
Für die Übertragung werden nur folgende ASCII Codes verwendet:
•
A-Z (0x41 – 0x5A)
für den Message Type,
•
0-9, A-F (0x30-0x39, 0x41-0x46)
für alle numerischen Werte (hexadezimal Code),
•
CR + LF
für Header und Trailer.
21
Die Integerwerte (2 Byte) werden als vier ASCII-Werte übertragen, die hexadezimal interpretiert
werden. Jedes einzelne ASCII-Zeichen (0-9, A-F) repräsentiert hexadezimal 4 Bit des Integerwertes. Die Floatwerte (4 Byte) werden als acht ASCII-Werte übertragen, die hexadezimal interpretiert werden, wobei die Darstellung der Floatwerte nach dem IEEE Standard 754 [IEEE, 2004]
erfolgt. Jedes einzelne ASCII-Zeichen (0-9, A-F) repräsentiert hexadezimal 4 Bit des Floatwertes.
Name
Charaters
Meaning
Value Range
Decoding
LF
x
Header
LF = 0x0A
1 Character
length
xxxxx
Data length
ASCII 0x30-0x39
5 digits
ASCII Number
Location
(Machine internal name)
ASCII 0x30-0x39
2 digits
ASCII Number
Range 0-99d
(set inside .MTX)
(0 = Broadcast)
loc
xx
Range 12-99999d
Length of data
overall excluding
Header, Trailer, and
Length
unit
xxxx
Unit
ASCII 4 digits
for M100 defined
as “M100”
4 Characters
(dummy Byte)
type
x
Message Type
ASCII 0x41-0x5F
capital letter
1 digit
1 Character
Range ‘A’ to ‘Z’
id
xxxx
Message ID
ASCII 0x30-0x39
and
0x41-0x46
4 digits
1 Integer (2 Byte)
Range 1 – 32767
Message identification number
gauge
x
Gauge #
ASCII 0x31
1 digit
for M100 defined
as “1”
1 Character
values
xxxx xxxx
(xxxx
xxxx,.)
Data Value(s)
ASCII 0x30-0x39
and
0x41-0x46
8 digits or x * 8
digits
1 – x Float (4 Byte)
or
1 – x Long (4 Byte)
refer to documentation
CR
x
Trailer
CR = 0x0d
1 Character
Tabelle 3.3: Aufbau der Telegramme
Telegrammtypen
Der Telegrammtyp wird mit dem Feld Message Type festgelegt. In Tabelle 3.4 sind alle verwendeten Telegrammtypen und deren Bedeutung definiert.
22
Message
Type
Bezeichnung
Bemerkung
A
Aktueller Parameter
Aktuell verwendete Parameter
N
Nächster Parameter
Vorbereitete Parameter für das nächste Band
M
Messwerte
Aktuelle Istwerte bzw. Messwerte
S
Status
Statusinformation über den aktuellen Betriebszustand
P
Profil
Quer- oder Längsprofil des Bandes
I
Befehl
Befehl an das Messgerät
W
Watchdog
Überwachung der Verbindung
Tabelle 3.4: Telegrammtypen
Daten vom Prozessvisualisierungssystem an das RM-Gateway
Bezeichnung
Format
Tag Name
Next auf Act.
Bool
BDM_CMD_NextAufAkt
Start Messung u. Quelle öffnen
Bool
BDM_CMD_Start
Stopp Messung u. Quelle
schließen
Bool
BDM_CMD_Stop
Ausblendung Bd. Anfang
INT
BDM_SOLL_AusblBdAnf
Störung Quit.
Bool
BDM_CMD_Quittieren
Tabelle 3.5: DDE-Daten an RM-Gateway
Daten vom RM-Gateway an das Prozessvisualisierungssystem
Bezeichnung
Format
Tag Name
Ist Dicke
INT 1/1000
BDM_IST_Dicke
Ist Länge
INT in Meter
BDM_IST_Laenge
Status Wort Frame
DINT
BDM_IST_StatusWort
Status Gauge
DINT
BDM_IST_StatusGauge
Dicke min
INT 1/1000 mm
BDM_IST_DickeMin
Dicke mittel
INT 1/1000 mm
BDM_IST_DickeMittel
Dicke max
INT 1/1000 mm
BDM_IST_DickeMax
Länge in 10er Schritten
INT
BDM_IST_LaengeTrig
Kom. TCP Radiometrie OK
Bool
BDM_STA_TcpOk
Kom. Visu - Schnittstellen PC
OK
Counter (INT) 010 in 100ms
BDM_SOLL_SsrOk
Tabelle 3.6: DDE-Daten von RM-Gateway
23
Bidirektionale Daten
Bezeichnung
Format
Tag Name in der Visu
Akt. Kennung ( AuftragsNr.)
DINT
BDM_AKT_Kennung
Akt. Rollennummer
DINT
BDM_AKT_RollenNr
Akt. Sollwert Dicke
INT 1/100 mm
BDM_AKT_SollDicke
Akt. Sorte
INT 1/1000
BDM_AKT_Sorte
Akt. + Tol
INT 1/100 mm
BDM_AKT_TolPlus
Akt. - Tol
INT 1/100 mm
BDM_AKT_TolMin
Akt. Schichtdicke
INT g/m²
BDM_AKT_Schichtdicke
Akt. Beschichtungsart
INT
BDM_AKT_BeschichtArt
Akt. Traversierprogramm
INT
BDM_AKT_TravProg
Next Kennung (AuftragsNr.)
DINT
BDM_NEXT_Kennung
Next Rollennummer
DINT
BDM_NEXT_RollenNr
Next Sollwert Dicke
INT 1/100 mm
BDM_NEXT_SollDicke
Next Sorte
INT 1/1000 mm
BDM_NEXT_Sorte
Next + Tol
INT 1/100 mm
BDM_NEXT_TolPlus
Next - Tol
INT 1/100 mm
BDM_NEXT_TolMin
Next Schichtdicke
INT g/m²
BDM_NEXT_Schichtdicke
Next Beschichtungsart
INT
BDM_NEXT_BeschichtArt
Next Traversierprogramm
INT
BDM_NEXT_TravProg
Tabelle 3.7: DDE-Daten bidirektional
3.4.2
NetDDE-Schnittstelle zum Prozessvisualisierungssystem
Das RM-Gateway kommuniziert über NetDDE mit dem Prozessvisualisierungssystem (Intouch).
Details zu Kommunikation mit NetDDE sind in Kapitel 4.3 zu finden.
Der Umfang des Datenaustausches ist in Tabelle 3.5, Tabelle 3.6 und Tabelle 3.7 definiert.
3.4.3
SQL-Datenbankschnittstelle-Betriebsdatenarchiv
Das RM-Gateway verbindet sich mittels ADO.NET (siehe Kapitel 4.1.1) mit der SQLDatenbank des Betriebsdatenarchivs und speichert dort statistisch Daten, die aus den vom Banddickenmessgerät empfangenen Prozessdaten berechnet werden (Details siehe Kapitel 3.5)
3.5
3.5.1
24
Funktionen des RM-Gateway
Erfassung des Längsprofils
Ziel dieser Funktion ist es, je 10 m Band einen Eintrag in die Datenbank des Betriebsdatenarchivs (Tabelle tDickeAuslaufEin) mit den aktuellen Minimum-, Maximum- und Mittelwerten aus
der Banddicke zu erstellen. Das Dickenmessgerät sendet bei jeder Änderung der gemessenen
Banddicken das Telegramm „M14“ und bei jeder Änderung der Bandlänge das Telegramm „M2“.
Ausblendung der Messungen von Bandanfang und Bandende
Der Bandanfang und das Bandende werden bei der Berechnung der Telgramme ausgeblendet.
Die Sollwerte dafür werden vom Prozessvisualisierungssystem zur Verfügung gestellt. Gemäß
Definition werden beim Ausblenden der Messwerte 0-Werte in die Datenbank für Minimum-,
Maximum- und Mittelwerte eingetragen.
Ausblenden von Messfehlern
Das Ausblenden von einzelnen Messwerten ist notwendig, um den negativen Einfluss der bei der
eingesetzten radiometrischen Messmethode auftretenden Messfehler zu minimieren. Messwerte
werden dann ausgeblendet, wenn die Abweichung vom Sollwert +/- 0.3 mm übersteigt. Der
Schwellwerte „Messwert Ausblendung“ kann konfiguriert werden.
3.5.2
Erfassung des Querprofils
Die Querprofilmessung wird vom Banddickenmessgerät selbstständig durchgeführt. Es sendet
bei einem Produktwechsel das Telegramm „P6“. Das Telegramm enthält das aufsummierte
Querprofil eines Bandes mit 50 Messwerten. Je nach Bandbreite sind nicht alle 50 Messwerte mit
gültigen Werten belegt.
Der Inhalt dieses Telegramms wird in die Datenbank des Betriebsdatenarchivs (Tabelle tDickeAuslaufQuerProfil) eingetragen.
3.5.3
Parametrierung des Banddickenmessgerätes
Durch die automatische Parametrierung des Messgerätes soll die manuelle Bedienung des Dickenmessgerätes entfallen. Dazu werden vom Prozessvisualisierungssystem die Banddaten für
den nächsten Bund bzw. den aktuellen Bund als DDE-Variablen übertragen und bei Änderung
als Telegramm an das Dickenmessgerät gesendet.
3.5.4
25
Datenaustausch mit der Prozessvisualisierung
Mit Hilfe des RM-Gateway werden alle benötigten Daten des Banddickenmessgerätes an die Prozessvisualisierung gesendet. Der Messvorgang des Dickenmessgerätes kann über die Prozessvisualisierung gestartet und gestoppt werden.
3.5.5
Automatischer Verbindungsaufbau
Das RM-Gateway überwacht den Zustand aller Verbindungen der Schnittstellen. Fällt eine Verbindung aus, versucht es zyklisch die Verbindung wieder aufzubauen. Damit ist bei Ausfall eines
Kommunikationspartners (z.B. bei einem Rechnerneustart oder einem Netzwerkfehler) gewährleistet, dass das RM-Gateway seine Aufgaben ohne manuellen Eingriff wieder aufnimmt.
3.5.6
Historische Speicherung der Betriebszustände
In einer Logdatei werden alle relevanten Betriebszustände des RM-Gateway, wie beispielsweise
ein Verbindungsaufbau oder ein Neustart, für Diagnosezwecke gespeichert.
4 Grundlegende Techniken
4
4.1
26
Grundlegende Techniken
Microsoft .NET Framework
Das .NET Framework ist eine Programmierplattform zum Erstellen, Bereitstellen und Ausführen
von Windows-Programmen, Webanwendungen, Smart Client-Anwendungen und XML-Webdiensten.
(vgl. [Microsoft, 2004c]).
Motiviert durch die starke Konkurrenz von Java führte Microsoft im Jänner 2002 mit .NET ein
neuartiges Konzept der Windows Programmierung ein. Dazu wurden eine neue Laufzeitumgebung Common Language Runtime (CLR), ein einheitliches Typsystem, das Common Type System (CTS)
und neue Bibliotheken entwickelt (siehe Abbildung 4.1). Gleichzeitig entwarf Microsoft die Programmiersprache C#, die Merkmale von Java und C++ vereint und neue Möglichkeiten wie zum
Beispiel Atttribute und Properties zur Verfügung stellt.
VB
C++
C#
….
JScript
Common Type System
ASP.NET
Windows Forms
Web Services
ADO.Net and XML
Base Class Library
Common Language Runtime
Windows
Abbildung 4.1: .NET Frameworkarchitektur (Quelle: [Heinzelreiter, 2003])
Im Gegensatz zu Java, bei der eine Programmiersprache auf verschiedenen Betriebssystemen
läuft, bietet .NET die Möglichkeit mit verschiedenen Programmiersprachen zu entwickeln, die
aber nur auf Windows-Betriebssystemen ausgeführt werden können. In Zukunft wird es auch
möglich sein, Anwendungen mit .NET zu erstellen, die auf anderen Plattformen und Betriebssystemen lauffähig sind. Die Firma Novell sponsert das Open Source-Projekt Mono, das sich die Entwicklung einer freien Implementierung des .NET Frameworks zum Ziel gesetzt hat (siehe
[Mono, 2004]).
Das .NET Framework kann von Microsoft kostenlos bezogen werden und enthält bereits einfache Werkzeuge zur Erstellung von Applikationen. Zur professionellen Softwareentwicklung bietet Microsoft die Entwicklungsumgebung Visual Studio .NET an.
4.1.1
27
Datenbankschnittstelle ADO.NET
Wie in Abbildung 4.2 dargestellt, ist ADO.NET ein Bestandteil des .NET Frameworks.
ADO.NET ist der Nachfolger von ActiveX Data Objects (ADO) und wird für den Datenaustausch
zwischen .NET Programmen und Datenbanken verwendet. In Abbildung 4.2 ist die Architektur
von ADO.NET dargestellt.
DataSet
Data Provider
DataTableCollection
Connection
DataAdapter
SelectCommand
Command
InsertCommand
UpdateCommand
DataReader
DeleteCommand
DataTable
DataRowCollection
DataColumnCollection
ConstraintCollection
DataRelationCollection
DB
XML
Abbildung 4.2: .Architektur von ADO.NET (Quelle: [Heinzelreiter, 2003])
Die Vorteile von ADO.NET liegen in der Integration der Extensible Markup Language (XML), der
hohen Performance, der ausgereiften Klassenbibliothek und der ausgezeichneten Integration in
die Entwicklungsumgebung Visual Studio .NET. Damit ist es mit sehr geringem Aufwand möglich, eine leistungsfähige Datenbankverbindung zu implementieren, da Visual Studio .NET den
erforderlichen Programmcode großteils toolunterstützt generiert.
4.2
4.2.1
TCP/IP-Kommunikation
Grundlagen
Die TCP/IP-Protokolle, auf denen auch das Internet basiert, wurden in den 70-er Jahren für den
Datenaustausch in heterogenen Rechnernetzen entwickelt.
In Abbildung 4.3 ist eine Gegenüberstellung von TCP/IP mit den Kommunikationsschichten
nach dem ISO-OSI-Referenzmodell dargestellt (vgl. [Tanenbaum, 2000]).
Die Schichten 5 - 7 des OSI-Modells werden bei TCP/IP in eine Anwendungsschicht zusammengefasst, die direkt mit der Transportschicht kommuniziert. In Schicht 4 befindet sich das
28
Transmission Control Protocol (TCP) das einen verbindungsorientierten, gesicherten Datentransport
mit Flusskontrolle realisiert, sowie das User Datagram Protocol (UDP), in welchem ein verbindungsloser und ungesicherter Transport erfolgt. In Schicht 3 ist das verbindungslose Internet-Protokoll
(IP) angesiedelt. Die Schichten 1 und 2 sind gegenüber Schicht 3 protokolltransparent. Sie werden
durch standardisierte Protokolle wie beispielsweise Ethernet realisiert.
Abbildung 4.3: Gegenüberstellung TCP/IP-OSI (Quelle: [Plate, 2004a])
4.2.2
Die Socket-Netzwerkschnittstelle
Anfang der 80er Jahre wurde in UNIX-Systemen die so genannte Socket-Schnittstelle, welche eine
Schnittstelle zum Betriebssystem darstellt, für die Kommunikation zwischen Prozessen eingeführt (Interprozesskommunikation, vgl. Kapitel 4.3.1). Ein Socket ist dabei der Name für einen Endpunkt einer Kommunikationsverbindung (vgl. [Plate, 2004b]). Die Socket-Schnittstelle ist im wesentlichem konzipiert für:
•
verbindungsorientierte Kommunikation, aufsetzend auf TCP,
•
verbindungslose Kommunikation, aufsetzend auf UDP,
•
direkten Zugriff auf die IP-Schicht,
•
Kommunikation zwischen lokalen Prozessen,
•
Kommunikation zwischen in TCP/IP-Netzwerken verteilten Prozessen.
Dabei nehmen Server-Programme (Socket-Server) Anfragen von anderen Programmen (SocketClients) entgegen und beantworten diese. Dieses Konzept ist auch als Client-ServerProgrammierung bekannt und wird bei Webserver bzw. Webbrowser eingesetzt (siehe Abbildung
4.4).
29
Die Socket-Schnittstelle ist von keiner Institution genormt, stellt aber den Industriestandard dar.
Es handelt sich um ein gut verständliches, leicht handhab- und programmierbares Konzept, das
in den meisten Betriebssystemen verfügbar ist (vgl. [Plate, 2004b]).
In Abbildung 4.4 sind die wesentlichen Methoden einer Socket-Schnittstelle am Beispiel der
Client-Server Kommunikation dargestellt.
Abbildung 4.4: Datenaustausch Client-Server (Quelle: [Plate, 2004b])
4.2.3
Asynchrone Socket-Kommunikation mit C#
Bei der synchronen Kommunikation wird der Sender einer Nachricht bis zur Auslieferung blockiert, bei der asynchronen Kommunikation kann der Sender sofort weiterarbeiten. Die klassische
Socket-Kommunikation, wie in Abbildung 4.4 dargestellt, arbeitet synchron, d.h. mit teilweise
blockierenden Methodenaufrufen. Dieses blockierende Verhalten ist in der Regel unerwünscht
und wird mit mehreren Threads bzw. Prozessen oder mit speziellen nicht blockierenden SocketMethoden wie poll und select gelöst.
Das .NET Framework stellt zwei Namensbereiche für die Netzwerkprogrammierung zur Verfügung:
•
System.Net,
•
System.Net.Sockets.
Es werden synchrone und asynchrone Kommunikation unterstützt. Bei der asynchronen Kommunikation werden die Methodenaufrufe sofort beendet, auch wenn die gewünschte Funktion
30
noch nicht durchgeführt wurde. Der Methodenaufrufer wird durch Callback-Methoden benachrichtigt wenn die gewünschte Funktion abgeschlossen ist. Das .NET Framework erstellt dafür
automatisch im Hintergrund Threads, die nach dem Aufruf der Callback-Methode terminieren.
In Tabelle 4.1 sind die wichtigsten asynchronen Socket-Methoden aufgelistet. Für weiterführende
Informationen zur Netzwerkprogrammierung mit C#.NET sei auf [Blum, 2003] verwiesen.
Beschreibung
Methode
Callback
Verarbeiten einer eintreffenden Verbindung
BeginAccept()
EndAccept()
Verbindung herstellen
BeginConnect()
EndConnect()
Empfang von Daten
BeginReceive()
EndReceive()
Empfang von Daten einer definierten Quelle
BeginReceiveFrom()
EndReceiveFrom()
Senden von Daten
BeginSend()
EndSend()
Senden von Daten an ein definiertes Ziel
BeginSendTo()
EndSendTo()
Tabelle 4.1: Asynchrone .NET Socket-Methoden
4.3
Windows DDE-Kommunikation
Dynamic Data Exchange (DDE) wird primär in Windows-Systemen zur einfachen Kommunikation
zwischen unterschiedlichen Anwendungen verwendet. Auch im Unix/Linux Bereich ist DDEKommunikation umgesetzt, wie die Office-Suite OpenOffice zeigt [OpenOffice, 2004].
DDE-Kommunikation kann auch für verteilte Anwendungen verwendet werden. In diesem Fall
spricht man von Network Dynamic Data Exchange (NetDDE), bei dem es sich um eine Erweiterung
des DDE-Mechanismus handelt.
DDE und NetDDE haben heute nur mehr geringe Bedeutung, da sie durch weiter reichende
Kommunikationsmechanismen wie Object Linking and Embedding (OLE) ersetzt wurden.
4.3.1
Interprozesskommunikation
Interprozesskommunikation bezeichnet die Kommunikation zwischen unterschiedlichen Prozessen bzw. Threads. Dabei werden definierte Nachrichten bzw. Informationen ausgetauscht (vgl.
[Rechenberg und Pomberger, 1999]). Die Art der Kommunikation kann wie folgt klassifiziert
werden:
•
Bei der synchronen Kommunikation wird der Sender einer Nachricht bis zur Auslieferung blockiert, bei der asynchronen Kommunikation kann der Sender sofort weiterarbeiten.
•
Im Gegensatz zur verbindungslosen Kommunikation ist bei der verbindungsorientierten Kommunikation ein expliziter Verbindungsaufbau vor der eigentlichen Kommunikation erforderlich.
•
31
Die Kommunikationsart kann nachrichtenbasiert (Beispiele: Signale, DDE, Socket, RPC, RMI,
Corba, COM) oder speicherbasiert (Beispiel: Shared Memory) sein.
4.3.2
Historische Entwicklung
Die Konzepte der DDE-Kommunikation entstanden im Laufe der historischen Entwicklung von
Microsoft-Windows (vgl. [Rathjen, 2004]).
In Windows 1.0 konnten Daten über die Zwischenablage („Cut and Paste“) transferiert werden.
Seit Windows 2.0 und 3.0 besteht die Möglichkeit, Daten nicht nur statisch über die Zwischenablage, sondern auch über eine dynamische Verbindung zwischen zwei oder mehreren Anwendungen über DDE auszutauschen.
Das DDE-Protokoll ist seit der Entwicklung um 1990 unverändert und wird auch von den aktuellen Versionen der Windows-Betriebssysteme und von Microsoft Office-Produkten unterstützt.
Insbesondere bietet Excel eine sehr einfache Möglichkeit über DDE bzw. NetDDE dynamische
Daten einzubinden (siehe [Microsoft, 2004a]).
Mit Visual Basic bis zur Version 6.0 kann DDE-Kommunikation sehr einfach anwendet werden,
da es vollständig integriert ist. Mit der Entwicklung der Microsoft .NET Plattform wurde die
Unterstützung für DDE eingestellt (vgl. [Microsoft, 2004b]). Daher ist es beispielsweise in den
Programmiersprachen C#.net oder VB.NET schwierig, diese Art der Kommunikation zu verwenden. Eine mögliche Lösung dieses Problems ist die Verwendung von externen DDEKommunikationskomponenten (siehe auch Kapitel 4.3.5).
4.3.3
Grundlegende Funktionen
Bei einer DDE-Kommunikation sind zwei Programme beteiligt, die als Quellanwendung (von dort
kommen die Daten) und als Zielanwendung (dort wandern die Daten hin) bezeichnet werden.
Quellanwendungen werden oft auch als DDE-Client und Zielanwendungen als DDE-Server bezeichnet. Ein Programm kann gleichzeitig mit mehreren Programmen DDE-Verbindungen herstellen und dabei die Rolle einer Quell- als auch einer Zielanwendung besitzen (vgl. [Monadjemi,
1993]).
Für die Namensauflösung verwendet DDE eine Hierarchie von drei Namensebenen:
•
Service,
•
Topic,
•
Item.
Für den Verbindungsaufbau werden Service und Topic gemeinsam zur Identifikation des Kommunikationspartners verwendet. Das Item definiert die konkreten Daten oder einen Befehl. Der Verbindungsaufbau erfolgt immer durch einen DDE-Client, der nach dem Verbindungsaufbau folgende Aktionen ausführen kann:
•
Request (Daten anfordern),
•
Execute (Befehl senden),
•
Poke (Daten senden).
32
Weiters besteht die Möglichkeit, dass ein DDE-Client automatisch über geänderte Daten des
DDE-Servers benachrichtigt wird. Diese Datenaktualisierung erfolgt durch Notify-Ereignisse, die
der Server an registrierte Clients versendet.
Mit NetDDE kann die DDE-Kommunikation auch bei verteilten Systemen verwendet werden.
Für den Verbindungsaufbau werden Service und Topic mit dem Rechnernamen ergänzt. NetDDE
verwendet für die Kommunikation das NETBIOS-Protokoll, das über TCP/IP transportiert
werden kann. Damit eine solche Verbindung aufgebaut werden kann, muss auf beiden Kommunikationspartnern der NETDDE.EXE-Service laufen, der ab Windows NT automatisch bei Bedarf
gestartet wird. Die Vergabe von DDE-Zugriffsrechten kann mit dem Programm DDESHARE.EXE definiert werden, welches bereits in den Windows-Betriebssystemen inkludiert ist (siehe
Abbildung 4.5)
Abbildung 4.5: Eigenschaftsdialog der DDE-Freigabe
4.3.4
Einsatz von DDE in der Automatisierungstechnik
Bedingt durch die historische Entwicklung und der einfachen Anwendbarkeit hat sich DDE in
der Automatisierungstechnik etabliert. DDE stellt ein Gateway zwischen sich dynamisch ändernden Prozessdaten und der Office-Welt dar. Prozessvisualisierungssysteme wie zum Beispiel Intouch der Firma Wonderware [Wonderware, 2004] verwenden DDE-Kommunikation als externe
Schnittstelle. Auch im Bereich der Prozessdatenerfassung und -analyse wird DDE verwendet. So
33
bietet National Instrumens für das Produkt LabView [Labview, 2004] eine DDE-Schnittstelle an,
um mit anderen Programmen oder auch Messgeräten Daten auszutauschen.
Ein großer Vorteil von DDE für die Automatisierungstechnik ist die Möglichkeit, dass Daten nur
bei einer Änderung übertragen werden. Im Gegensatz zum zyklischen Datenaustausch (Polling)
werden die Datenmengen über die Kommunikationskanäle reduziert und kurze Reaktionszeiten
bleiben gewährleistet.
4.3.5
DDE-Kommunikation mit C#
Wie bereits in Kapitel 4.3.2 erwähnt, wird im Microsoft .NET Framework die DDEKommunikation nicht mehr unterstützt. Da das Projekt RM-Gateway mit C#.NET entwickelt
wurde, war es erforderlich, eine Lösung für dieses Problem zu finden.
Aus diesem Grund wurde vom Autor die COM-Komponente DDELib in C++ entwickelt. Diese
Komponente kapselt die DDE-Kommunikationsaufrufe und stellt nach außen Zugriffsfunktionen zur Verfügung. COM-Komponenten können in C# sehr einfach eingebunden werden, da es
mit Hilfe des Utility tlbimp möglich ist, automatisch eine .NET Hüllenklasse zu generieren (siehe
[Moses und Novak, 2002], [Lau, 2004]).
5 Konzeption und Design
5
5.1
34
Konzeption und Design
Systemdesign
Das Systemdesign gibt einen Überblick über die Softwarearchitektur, das Design der Schnittstellen und der Datenhaltung (vgl. [Mayr, 2001]). Eine detaillierte Beschreibung der Komponenten
folgt in Kapitel 5.1.1.
5.1.1
Architektur
In Abbildung 5.1 ist die Architektur der RM-Gateway-Schnittstellensoftware dargestellt. Das System besteht übergeordnet aus zwei Komponenten, dem InterfaceManager und dem UserInterface.
Diese konzeptionelle Trennung erfolgt, um die Schnittstellensoftware auch komplett ohne Benutzerinterface als Service betreiben zu können, der im Hintergrund läuft. Das Benutzerinterface
dient nur zur Konfiguration bzw. Diagnose und kann optional weggelassen werden. Für den laufenden Betrieb der Schnittstellensoftware ist keine Benutzerinteraktion erforderlich.
InterfaceManager
UserInterface
ConfigurationManager
ConfigFileInterface
ConnectionManager
GaugeInterface
HMIInterface
GaugeRaw
Telegram
DDELib
Ethernet TCP/IP
(M100 Radiometrie)
DBInterface
ADO.NET
NetDDE
(Intouch 7.1)
Betriebsdatenarchiv
(MS SQL Server)
Abbildung 5.1: Architektur der RM-Gateway-Schnittstellensoftware
35
Im folgenden Abschnitt werden die Aufgaben der modellierten Komponenten übersichtsweise
erklärt.
InterfaceManager
Die Komponente InterfaceManager kapselt die gesamte Schnittstellensoftware mit den erforderlichen Komponenten und ist für übergeordnete Aufgaben vorgesehen. Die Komponente ist auch
für die Erstellung der Logdatei zuständig, in der relevante Zustandsänderungen des Gesamtsystems protokolliert werden.
UserInterface
Wie bereits erwähnt, realisiert das UserInterface eine grafische Oberfläche, die zur Konfiguration
und Diagnose der Schnittstellensoftware verwendet wird und tauscht dazu mit dem InferfaceManager die erforderlichen Daten aus (siehe Kapitel 5.3).
ConfigurationManager
Der ConfigurationManager ist für die gesamte Konfiguration der Schnittstellensoftware zuständig.
Die Komponente bezieht die Konfigurationsdaten von ConfigFileInterface und UserInterface und
sendet die Daten an die zu konfigurierenden Schnittstellen-Komponenten weiter.
ConfigFileInterface
Diese Komponente kapselt den Dateizugriff auf die Konfigurationsdateien.
ConnectionManager
Der ConnectionManager ist für den Auf- und Abbau sowie die Überwachung der externen Datenverbindungen zuständig. Er koordiniert dabei die Schnittstellen-Komponenten GaugeInterface, HMIInterface und DBInterface. Im Falle einer Verbindungsunterbrechung werden die beteiligten Komponenten benachrichtigt. Der ConnectionManger versucht laufend die Verbindung wieder herzustellen. Aus Sicht des RM-Gateway kann es betriebsmäßig vorkommen, dass ein externes System neu gestartet wird oder kurz ausfällt. In diesem Fall müssen sämtliche Komponenten
des RM-Gateway ohne Benutzerinteraktion ihre Tätigkeit so rasch wie möglich wieder aufnehmen.
GaugeInterface
Das GaugeInterface realisiert mit Hilfe der asynchronen Socket-Kommunikation (siehe Kapitel
4.2.3) die Ethernet TCP/IP-Schnittstelle mit dem Banddickenmessgerät. Die empfangenen Telegramm-Rohdaten werden der Komponente GaugeRawTelegram zur Weiterverarbeitung übergeben.
36
GaugeRawTelegram
Diese Komponente wandelt einerseits die Telegramm-Rohdaten (Byte-Array) in typisierte Datenstrukturen um und prüft dabei die Konsistenz der Daten. Andererseits generiert die Komponente
auch neue Telegramme, die in Form von Telegramm-Rohdaten an das GaugeInterface zum Versand an das Banddickenmessgerät übergeben werden.
HMIInterface
Das HMIInterface koordiniert die NetDDE-Kommunikation mit dem Prozessvisualisierungssystem. Die Kommunikation selbst wird von der Komponente DDELib durchgeführt.
DDELib
Diese Komponente realisiert die NetDDE-Kommunikation. DDELib erstellt lokal ein aktuelles
Abbild der DDE-Kommunikationsvariablen und versendet bei Bedarf Änderungstelegramme an
den Kommunikationspartner. Da das .NET-Framework die DDE-Kommunikation nicht direkt
unterstützt, erfolgte die Realisierung als COM-Objekt in C++ (siehe auch Kapitel 4.3.5).
DBInterface
DBInterface ist für den Datenaustausch mit der Datenbank des Betriebsdatenarchivs zuständig.
Dabei kommt ADO.NET zum Einsatz (siehe Kapitel 4.1.1).
5.1.2
Schnittstellen
Interne Schnittstellen
Die internen Schnittstellen werden im Kaptitel 6 ausführlich behandelt.
Externe Schnittstellen
Das System besitzt drei externe Schnittstellen:
•
TCP/IP-Schnittstelle zum Banddickenmessgerät (GaugeInterface),
•
NetDDE-Schnittstelle zum Prozessvisualisierungssystem (HMIInterface),
•
SQL-Datenbank-Schnittstelle – Betriebsdatenarchiv (DBInterface).
Die genaue Spezifikation der externen Schnittstellen wurde bereits in Kapitel 3.4 bei den Anforderungen an das RM-Gateway festgelegt.
5.1.3
37
Datenhaltung
Qualitätsdaten
Die Persistierung von Qualitätsdaten erfolgt über die externe Schnittstelle zur Datenbank des
Betriebsdatenarchivs. Bandlängengetriggert werden neue Datensätze in die, in Abbildung 5.2
dargestellten, Tabellen eingetragen.
tDickeAuslaufEin
PK
ID
CoilNr
Bandposition
DickeAuslaufMin
DickeAuslaufMax
DickeAuslaufMittel
tDickeAuslaufQuerProfil
PK
ID
CoilNr
Bandposition
DickeAuslaufProfil_1
....
Abbildung 5.2: Betriebsdatenarchiv – relevante Tabellen für das RM-Gateway
Konfigurationsdaten
Die Konfigurationsdaten des RM-Gateway werden in lokalen Konfigurationsdateien persistiert.
Als Beispiel ist das Konfigurationsfile hmi.config aufgelistet, mit dem die NetDDE-Schnittstelle
zum Prozessvisualisierungssystem konfiguriert werden kann. Hervorzuheben ist, dass nicht nur
die allgemeinen Kommunikationsparameter sondern auch sämtliche Namen der Kommunikationsvariablen definiert werden können (tag1 – tagxx).
App = \\Acerbook\VIEW
Topic = TAGNAME
refreshTime = 1000
numberOfTags = 34
tag1 = BDM_AKT_Kennung
tag2 = BDM_AKT_RollenNr
tag30 = BDM_IST_DickeMittel
……..
tag32 = BDM_IST_LaengeTrig
tag33 = BDM_STA_TcpOk
tag34 = BDM_SOLL_SsrOk
38
Betriebszustand
Für die Diagnose wichtiger Daten werden vom System in einer Logdatei fortlaufende Daten mit
einem Zeitstempel gespeichert:
•
Zustand des Gesamtsystems,
•
Zustand der Schnittstellen und der Information über den Verbindungsstatus.
Optional besteht auch die Möglichkeit erweiterte Informationen über den Datenaustausch in der
Logdatei zu archivieren. Diese Daten können bei Bedarf zur genauen Analyse des Systems verwendet werden.
5.2
5.2.1
Komponentendesign
Übersicht
Eine einleitende Übersicht über die Komponenten erfolgte bereits in Kapitel 5.1. Im folgenden
Abschnitt werden die Funktionen und die Interaktionen ausgewählter Komponenten genauer
definiert. In Abbildung 5.3 ist das Übersichts-Klassendiagramm mit eingetragenen Beziehungen
zwischen den Klassen dargestellt.
Abbildung 5.3: Übersichts-Klassendiagramm RM-Gateway
5.2.2
39
Die Klasse ConnectionManager
Wie bereits in Kapitel 5.1 erwähnt, koordiniert der ConnectionManager den Verbindungszustand
der drei externen Schnittstellen. Die möglichen Zustände einer Verbindung sind in Abbildung 5.4
dargestellt. Für den ordnungsgemäßen Betrieb des Gesamtsystems ist es erforderlich, dass sich
alle drei externen Schnittstellen im Zustand „Verbunden“ befinden.
Damit der Zustand der Schnittstellen zuverlässig festgestellt werden kann, erfolgt unabhängig
von den übertragenen Telegrammen zeitgetriggert ein definierter Datenaustausch in Form von
Watchdog-Telegrammen bei der TCP/IP-Verbindung und in Form einer zyklisch inkrementierten
Variablen bei der DDE-Kommunikation. Die Prüfung der Verbindung mit der Datenbank erfolgt beim Systemstart sowie beim jedem Zugriff auf die Datenbank.
Nicht Verbunden
Verbindungsaufbau
Verbunden
Verbindungsfehler
Verbindungsabbau
Abbildung 5.4: Zustandsdiagramm der externen Schnittstellen
5.2.3
Die Klasse GaugeInterface
Die Klassen GaugeInterface und GaugeRawTelegram sind für die TCP/IP-Kommunikation mit
dem Banddickenmessgerät verantwortlich. Das in Abbildung 5.5 dargestellte Klassendiagramm
gibt einen Überblick über die realisierten Methoden und Properties.
5.2.4
Die Klasse HMIInterface
Das HMIInterface realisiert die NetDDE-Kommunikation mit dem Prozessvisualisierungssystem
mit Hilfe der Klassen DDELIb und PokeThread (siehe Kaptile 5.1.1). Die Klasse PokeTread ist für
die Pufferung von Änderungsdaten verantwortlich, da die DDE-Kommunikation nicht synchron
mit dem Empfang der Daten vom Banddickenmessgerät erfolgen kann. Das in Abbildung 5.6
dargestellte Klassendiagramm stellt die drei beteiligen Klassen mit den öffentlichen Methoden
dar.
Abbildung 5.5: Klassendiagramm GaugeInterface
Abbildung 5.6: Klassendiagramm HMIInterface
40
5.3
41
Benutzerschnittstellen-Design
Bei dem Konzept der RM-Gateway-Schnittstellensoftware besitzt die Benutzerschnittstelle eine
untergeordnete Rolle und hat zum Teil rudimentären Charakter (vgl. Kapitel 5.1.1).
5.3.1
Konfigurations- und Diagnosetool
Primär wird das Konfigurations- und Diagnosetool von der Klasse UserInterface realisiert.
Das Konfigurationstool dient dazu, die Schnittstellensoftware zu konfigurieren. Folgende Konfigurationsmöglichkeiten sind vorgesehen:
•
Banddickenmessgerät: IP Adresse, Port und Kommunikationsparameter,
•
Datenbank: Datenbankname, User und Passwort,
•
Prozessvisualisierung: Rechnername, Kommunikationsparameter.
In Abbildung 5.7 ist die prototypische Bedienoberfläche des Konfigurationstools dargestellt.
Abbildung 5.7: Benutzerschnittstelle Konfigurationstool
Das in Abbildung 5.8 und Abbildung 5.9 dargestellte Diagnosetool dient in erster Linie zur Inbetriebnahme der Schnittstellensoftware und zur Fehlersuche. Das Diagnosetool verbindet sich mit
der Schnittstellensoftware und kann so den aktuellen Status der Systems abfragen.
5.3.2
Prozessvisualisierungssystem
In Abbildung 5.10 und Abbildung 5.11 ist die Benutzerschnittstelle des Banddickenmessgerätes
im Prozessvisualisierungssystem Intouch dargestellt, die über das RM-Gateway mit Daten versorgt wird.
Abbildung 5.8: Benutzerschnittstelle Diagnosetool: General
Abbildung 5.9: Benutzerschnittstelle Diagnosetool: Log
42
Abbildung 5.10: Benutzerschnittstelle des Banddickenmessgerätes
Abbildung 5.11: Benutzerschnittstelle des Banddickenmessgerätes: Trend
43
6 Implementierung
6
44
Implementierung
Dieses Kapitel stellt wesentliche Faktoren der Realisierung vor. Es folgt eine Beschreibung der
Entwicklungsumgebung, die Erläuterungen von allgemeinen Punkten und von implementierungsspezifischen Details der Komponentenentwicklung.
6.1
Verwendete Entwicklungsumgebung
Für die Implementierung der RM-Gateway-Schnittstellensoftware wurde eine integrierte Testund Entwicklungsumgebung, wie in Abbildung 6.1 dargestellt, verwendet. Damit ist es möglich,
die Software im Zuge der Implementierung effizient zu testen (Whitebox -Testen des Implementierers, [Mayr, 2001]).
Ethernet TCP/IP
3
Testinstallation
(Intouch)
2
Simulationssoftware
(TCP-Server)
+
Testinstallation
Betriebsdatenarchiv
(MS-SQL-Server)
4
1
Entwicklungsumgebung
(MS-Visual-Studio.NET)
Protokollanalysator
Ethereal
Abbildung 6.1: RM-Gateway: Integrierte Test- und Entwicklungsumgebung
Alle in Abbildung 6.1 dargestellten Rechner weisen folgende gemeinsame Charakteristiken auf:
•
Prozessor Pentium/Athlon >= 1400 MHz, >= 512 MB RAM,
•
Betriebssystem Microsoft Windows XP Professional.
Der Rechner Nr. 1 stellt den eigentlichen Entwicklungsrechner dar, auf dem die Software implementiert und getestet wird. Als Entwicklungsumgebung kommt Microsoft Visual Studio .NET
2003 zum Einsatz. Auf dem Rechner Nr. 2 ist eine vom Autor selbst implementierte Simulationssoftware installiert, die sich wie das Banddickenmessgerät als TCP-Server verhält, sowie eine
Testinstallation des MS-SQL-Servers für das Betriebsdatenarchiv. Auf dem Rechner Nr. 3 befindet sicht eine Testinstallation des Prozessvisualisierungssystems Intouch mit einer für diesen
Zweck von Wuppermann Bandstahl erstellten Applikation (siehe Abbildung 5.10). Der Rechner
Nr. 4 ist für die Analyse der TCP/IP-Telegramme zuständig. Für diese Aufgabe kommt der Ethernet-Protokollanalysator Ethereal [Ethereal, 2004] zum Einsatz.
6 Implementierung
6.2
45
Allgemeine Vorgehensweise
6.2.1
Auswahl des Betriebssystems für das RM-Gateway
Die RM-Gateway-Schnittstellensoftware wurde nur für den Einsatz in Windows Betriebssystemen ausgelegt, da die IT-Infrastruktur beim Auftraggeber von Microsoft geprägt ist und die gewählte Entwicklungsumgebung derzeit kein anderes Betriebssystem unterstützt (siehe Kapitel
4.1).
6.2.2
Auswahl der Entwicklungsumgebung und der Programmiersprache
Auf Grund der Zukunftssicherheit und der technischen Möglichkeiten wurde das .NETFramework mit Microsoft Visual Studio .NET 2003 als Entwicklungswerkzeug gewählt. Die
Implementierung erfolgte in der Programmiersprache C#. Einzig die Implementierung der COMKomponente DDELib erfolgte in C++ mit Hilfe der ATL-Template-Library (siehe Kapitel 4.3.5).
Wesentliche Vorteile von C#.NET für die Realisierung des RM-Gateway sind:
•
effiziente und einfache Möglichkeit der Netzwerkprogrammierung,
•
toolunterstützter und leistungsfähiger Datenbankzugriff,
•
der Garbage-Collektor der .NET Laufzeitumgebung minimiert das Risiko von Memoryleaks und erleichtert damit den Dauerbetrieb des RM-Gateway ohne Rechnerneustart,
•
zukunftssicheres Konzept,
•
einfache Installation der Software,
•
hohe Geschwindigkeit der .NET Laufzeitumgebung.
Als Nachteil von C#.NET für die Realisierung des RM-Gateway kann die fehlende Unterstützung der DDE-Kommunikation angesehen werden.
6.2.3
Vorgehensmodell für die Entwicklung des RM-Gateway
Als Vorgehensmodell für das Projekt wurde das Spiralmodell gewählt. Der Spiralzyklus beginnt
mit der Definition der Anforderungen und Ziele des Projektes. Das Spiralmodell arbeitet mit
einem evolutionären Prototyp, der mehrmals der Validierung und Risikoanalyse unterzogen wird,
bis das Design vollständig ist und die ordentliche Implementierung erfolgen kann (vgl. [Mayr,
2001]).
Der Grund für das gewählte Vorgehensmodell liegt in den technischen Risiken des Projektes, die
teilweise auch in der Verantwortung der Betreiber und Hersteller der in diesem Projekt beteiligten Kommunikationspartner liegt. Durch dieses Vorgehensmodell werden die Risiken minimiert,
da mögliche technische Schwierigkeiten schon in der Projektanfangsphase festgestellt werden
6 Implementierung
46
können und dadurch ausreichend Zeit für eine Fehlerbehebung oder Designänderung vorhanden
ist.
Bei diesem Projekt wurden schon in der Projektanfangsphase die Kommunikationskomponenten
erstellt und getestet. Damit konnte die Realisierbarkeit überprüft und das technische Risiko minimiert werden (siehe Kapitel 7).
6.3
Komponentenentwicklung
In diesem Kapitel werden wichtige Klassen und daraus wesentliche Teile des Source-Codes erläutert. Dabei ist zu beachten, dass keine Fehlerbehandlung dargestellt wird und nur kurze Ausschnitte aus Methoden gezeigt werden.
6.3.1
Die Klasse InterfaceManager
Die Klasse InterfaceManager ist die Hauptklasse der Schnittstellensoftware. Diese Klasse entspricht dem Entwurfsmuster Singleton und wird nur einmal durch das Hauptprogramm, einem
Windows-Service, instanziert. Dabei erzeugt das InterfaceManager Objekt alle erforderlichen Instanzen der Klassen ConfigurationManager, ConnectionManager, GaugeInterface, HMIInterface und
DBInterface.
Eine weitere Aufgabe des InterfaceManager ist es, bei Bedarf ein Objekt der Klasse UserInterface
zu instanzieren und darzustellen und mit diesem Daten über eine definierte Schnittstelle auszutauschen.
6.3.2
Die Klasse UserInterface
Die Klasse UserInterface ist von der Basisklasse System.Windows.Forms.Form abgeleitet und
dient zur grafischen Darstellung der Benutzeroberfläche, die für die Konfiguration und Diagnose
des Systems verwendet wird.
6.3.3
Die Klasse ConfigurationManager
Der ConfigurationManager ist eine Klasse, die für die Konfiguration der Schnittstellensoftware
zuständig ist. Die Konfigurationsdaten werden an die Instanzen der Klassen GaugeInterface,
HMIInterface und DBInterface gesendet und enthalten die Schnittstellen und Verbindungsdaten
sowie Daten, die das Verhalten der Schnittstellen definieren. Für den Zugriff auf die Konfigurationsdateien wird eine Instanz der Klasse ConfigFileInterface verwendet.
6 Implementierung
6.3.4
47
Die Klasse ConfigFileInterface
Diese Hilfsklasse ist für den Dateizugriff auf die Konfigurationsdateien zuständig und wird von
der Klasse ConfigurationManager verwendet.
6.3.5
Die Klasse ConnectionManager
Die Klasse ConnectionManager koordiniert die Verbindungen der externen Schnittstellen, die von
den Klassen GaugeInterface, HMIInterface und DBInterface realisiert werden. Wesentlich dabei
sind die definierte Reihenfolge des Verbindungsaufbaus sowie die zyklische Überwachung des
Status der Verbindung und das Verhalten im Fehlerfall.
6.3.6
Die Klasse GaugeInterface
Das Klasse GaugeInterface ist für die TCP/IP-Verbindung mit dem Banddickenmessgerät zuständig. Dabei verhält sie sich als TCP-Client (siehe Kapitel 4.2.3). Eine Instanz der Klasse GaugeRawTelegram analysiert die empfangenen Daten und generiert die zu sendenden Telegramme.
Das folgende Listing enthält die wesentlichen Methodenaufrufe der asynchronen SocketKommunikation:
// Connect to the TCP Server
public void Connect()
{
Socket newsock = new Socket(AddressFamily.InterNetwork, SocketType.Stream,
ProtocolType.Tcp);
IPEndPoint iep = new IPEndPoint(IPAddress.Parse(ip), int.Parse(port));
newsock.BeginConnect(iep, new AsyncCallback(Connected), newsock);
}
// Callback method - called if connect ended
private void Connected(IAsyncResult iar)
{
client = (Socket)iar.AsyncState;
client.EndConnect(iar);
client.BeginReceive(data, 0, size, SocketFlags.None,
new AsyncCallback(ReceiveData), client);
}
// Callback method - called if data received
private void ReceiveData(IAsyncResult iar)
{
Socket remote = (Socket)iar.AsyncState;
recv = remote.EndReceive(iar);
AnalyseReceivedData(data);
remote.BeginReceive(data, 0, size, SocketFlags.None,
new AsyncCallback(ReceiveData), remote);
}
// Send new telegram
private void sendNewTel (IAsyncResult iar)
{
6 Implementierung
48
byte[] message = gtSend.convertToByte();
client.BeginSend(message, 0, message.Length, SocketFlags.None,
new AsyncCallback(SendData), client);
}
// Callback Method - called if data sent
private void SendData(IAsyncResult iar)
{
Socket remote = (Socket)iar.AsyncState;
int sent = remote.EndSend(iar);
remote.BeginReceive(data, 0, size, SocketFlags.None,
new AsyncCallback(ReceiveData), remote);
}
Die Methode AnalyseReceivedData übergibt die empfangen Daten einer Instanz der Klasse GaugeRawTelegram zur Analyse.
6.3.7
Die Klasse GaugeRawTelegram
Diese Klasse analysiert die empfangen Daten in Form eines Byte-Arrays und führt die erforderlichen Typkonvertierungen durch. Die konvertierten Daten stehen über Zugriffsmethoden zur
Verfügung.
Im folgenden Listing wird ein Ausschnitt aus dem Programm der Klasse GaugeRawTelegramg
gezeigt, das den empfangenen Bytestrom in Stringkomponenten zerlegt:
// Reads the raw byte stream and transfers it to the telegram structure
public void readByteStream(byte[] bytes)
{
//bytes convert to string
char[] c = new char[bytes.Length];
System.Text.Decoder d = System.Text.Encoding.UTF8.GetDecoder();
int charLen = d.GetChars(bytes, 0, bytes.Length, c, 0);
string s = new string(c);
int lenDataValues;
lenDataValues = charLen - 12 - 7;
//string divide to telegram
Header = s.Substring(0,1);
DataLength =s.Substring(1,5);
Location = s.Substring(6,2);
Unit = s.Substring(8,4);
MessageType = s.Substring(12,1);
MessageID = s.Substring(13,4);
Gauge = s.Substring(17,1);
DataValues = s.Substring(18,lenDataValues);
Trailer = s.Substring(18+lenDataValues,1);
}
Die relativ komplexe Codierung der Telegramme erfordert viele Hilfsmethoden zur Typkonvertierung, die auszugsweise in den folgenden Listings ersichtlich sind:
//Auxiliary method – Convert a byte array to hex string
private string ToHexString(byte[] bytes)
{
6 Implementierung
49
char[] chars = new char[bytes.Length * 2];
for (int i = 0; i < bytes.Length; i++)
{
int b = bytes[i];
chars[i * 2 + 0] = hexDigits[b >> 4];
chars[i * 2 + 1] = hexDigits[b & 0xF];
}
return new string(chars);
}
//Auxiliary method - Convert 2 Chars in hex code to a byte
private byte ToByte(char h, char l)
{
int ih = System.Array.IndexOf(hexDigits,h);
int il = System.Array.IndexOf(hexDigits,l);
int ib = il + 16 * ih;
System.Convert.ToByte(ib);
return System.Convert.ToByte(ib);
}
//Auxiliary method - Convert a string in hex code to a float
private float convertStringToFloatSingle(string s)
{
if(s.Length == 8)
{
char[] ca = new char[8];
ca = s.ToCharArray();
byte[] ba = new byte[4];
ba[0] = ToByte(ca[6], ca[7]);
float f = BitConverter.ToSingle(ba,0);
return f;
}
}
6.3.8
Die Klasse HMIInterface
Das Klasse HMIInterface ist für die NetDDE-Kommunikation mit dem Prozessvisualisierungssystem zuständig und verwendet dafür eine Instanz der Klasse DDELib. Das HMIInterface registriert
die erforderlichen DDE-Varibalen beim DDELib-Objekt und erhält die aktuellen Werte der
Variablen mittels Polling.
Da der Versand der Daten an den DDE-Kommunikationspartner nicht synchron mit dem Empfang der zu sendenden Daten erfolgen kann, wurde ein Sendepuffer mittels Threads realisiert, der
die Daten mit der Methode dde.Poke über das DDELib-Objekt versendet. Eine Semaphore (readyForPoke) ist für die Koordination der PokeThreads zuständig und garantiert, dass die Methode
dde.Poke zur gleichen Zeit nur von einem Thread aufgerufen wird.
6 Implementierung
50
// Poke thread for buffering the dde.poke method calls
class PokeThread
{
private HMIInterface hmi;
private DDELib.CDDEClass dde;
private string Item;
private string val;
public PokeThread(HMIInterface hmi, DDELib.CDDEClass dde, string
Item, string val)
{
this.dde = dde;
this.Item = Item;
this.val = val;
this.hmi = hmi;
}
public void poke()
{
//Waiting for free poke method
while(!hmi.readyForPoke)
{
Thread.Sleep(100);
}
hmi.readyForPoke = false;
dde.Poke(ref Item, ref val);
hmi.threadCount--;
hmi.readyForPoke = true;
}
}
}
6.3.9
Die Klasse DDELib
Diese Klasse wurde als allgemein verwendbare Klasse für die NetDDE-Kommunikation entwickelt. Da das .NET-Framework die DDE-Kommunikation direkt nicht unterstützt und die Implementierung in C# über die Windows-API zu komplex ist, erfolgte die Implementierung als
COM-Objekt in C++ unter Verwendung der ATL-Template-Library und der DDE-ManagementLibrary ddeml.dll.
Als Beispiel ist die Methode Request aufgelistet, die den aktuellen Wert einer Variablen vom
Kommunikationspartner anfordert.
// Request for Data "Item"
STDMETHODIMP CDDE::Request(BSTR* Item, BSTR* Result)
{
_bstr_t i = _bstr_t(*Item);
char szItem1[32];
strcpy(szItem1,i);
HSZ hszItem = DdeCreateStringHandle(idInst, szItem1, 0);
HDDEDATA hData = DdeClientTransaction(NULL,0,hConv,
hszItem,CF_TEXT,XTYP_REQUEST ,TIMEOUT_ASYNC, NULL);
DdeFreeStringHandle(idInst, hszItem);
DdeGetData(hData, (unsigned char *)szResult, 32, 0);
_bstr_t s = _bstr_t(szResult);
*Result = s.copy();
return S_OK;
6 Implementierung
51
}
Eine weitere Möglichkeit ist die Registrierung von Variablen nach dem Observer-Designpattern. Die
Methode AdvStart registriert Variablen beim Kommunikationspartner, der bei Änderungen der
Variablen Telegramme sendet, die durch den Aufruf der Callback-Methode DdeCallback empfangen
werden.
//Register a DDE item on the server to receive the changes (Listener)
STDMETHODIMP CDDE::AdvStart(BSTR* Item)
{
_bstr_t i = _bstr_t(*Item);
char szItem1[32];
strcpy(szItem1,i);
hszItem1 = DdeCreateStringHandle(idInst, szItem1, 0);
HDDEDATA hData = DdeClientTransaction(NULL,0,hConv,
hszItem1, CF_TEXT,XTYP_ADVSTART ,TIMEOUT_ASYNC, NULL);
hszMap[hszItem1] = szItem1;
itemMap[szItem1] = hszItem1;
}
// DDECallback – called if new DDE messages (data) received
HDDEDATA CALLBACK DdeCallback(
UINT uType, // Transaction type
UINT uFmt, // Clipboard data format
HCONV hconv, // Handle to the conversation
HSZ hsz1, // Handle to a string
HSZ hsz2, // Handle to a string
HDDEDATA hdata, // Handle to a global memory object
DWORD dwData1, // Transaction-specific data
DWORD dwData2 // Transaction-specific data
){
switch (uType)
{
case XTYP_ADVDATA:
ihsz = hszMap.find(hsz2);
DdeGetData(hdata, (unsigned char *)szReceived, 32, 0);
valueMap[hsz2] = szReceived;
return (HDDEDATA) DDE_FACK;
default:
return (HDDEDATA) NULL;
}
}
6.3.10
Die Klasse DBInterface
Die Klasse DBInterface realisiert den Datenaustausch mit der Datenbank mittels ADO.NET. Im
Folgenden ist die Methode AddLengthProfile aufgelistet, die in die Tabelle tAuslaufDicke einen
neuen Datensatz einfügt. Es werden der SQL-Datenadapter sqlDataAdapter1 und das Dataset stripProfile1 verwendet.
private System.Data.SqlClient.SqlDataAdapter sqlDataAdapter1;
private DBInterface.StripProfile stripProfile1;
// Add a new LengthProfile entry in the table tDickeAuslaufEin
6 Implementierung
52
private void AddLengthProfile(string id, string coilNumber, int stripPos,int ThicknessMin,
int ThicknessMax, int ThicknessAvg)
{
DataRow row = stripProfile1.tDickeAuslaufEin.NewRow();
row["ID"] = id;
row["COILNR"] =coilNumber;
row["BANDPOSITION"] = stripPos.ToString();
row["DICKEAUSLAUFMIN"] = ThicknessMin.ToString();
row["DICKEAUSLAUFMAX"] = ThicknessMax.ToString();
row["DICKEAUSLAUFMITTEL"] = ThicknessAvg.ToString();
stripProfile1.tDickeAuslaufEin.Rows.Add(row);
sqlDataAdapter1.Update(stripProfile1);
stripProfile1.tDickeAuslaufEin.Rows.Clear();
}
Die erforderlichen parametrisierten SQL-Aufrufe werden von der Microsoft Visual Studio .NET
Entwicklungsumgebung automatisch generiert und können über Dialoge konfiguriert werden:
sqlInsertCommand1.CommandText = @"INSERT INTO tDickeAuslaufEin(ID, CoilNr, Band
position, DickeAuslaufMin, DickeAuslaufMax, DickeAuslaufMittel) VALUES (@ID,
@CoilNr, @Bandposition, @DickeAuslaufMin, @DickeAuslaufMax,
@DickeAuslaufMittel); SELECT ID, CoilNr, Bandposition, DickeAuslaufMin, DickeAus
laufMax, DickeAuslaufMittel FROM tDickeAuslaufEin";
sqlInsertCommand1.Connection = sqlConnection1;
sqlInsertCommand1.Parameters.Add(new System.Data.SqlClient.SqlParameter("@ID",
System.Data.SqlDbType.Int, 4, "ID"));
sqlInsertCommand1.Parameters.Add(new System.Data.SqlClient.SqlParameter("@CoilNr",
System.Data.SqlDbType.VarChar, 8, "CoilNr"));
sqlInsertCommand1.Parameters.Add(new System.Data.SqlClient.SqlParameter
("@Bandposition",System.Data.SqlDbType.Int, 4, "Bandposition"));
("@DickeAuslaufMin", System.Data.SqlDbType.Real, 4, "DickeAuslaufMin"));
("@DickeAuslaufMax", System.Data.SqlDbType.Real, 4, "DickeAuslaufMax"));
("@DickeAuslaufMittel", System.Data.SqlDbType.Real, 4, "DickeAuslaufMittel"));
sqlConnection1.ConnectionString = "workstation id=BIG;packet size=4096;integrated
security=SSPI;data source=oppix;pe" +"rsist security info=False;initial catalog=plant";
Bei ADO.NET ist zusammenfassend festzuhalten, dass der Datenaustausch mit Datenbanken
sehr einfach zu implementieren ist. Auf Grund der guten Unterstützung durch die Entwicklungsumgebung ist der Umfang des selbst zu implementierenden Programmcodes sehr gering.
7 Test und Inbetriebnahme
7
7.1.1
53
Test und Inbetriebnahme
Das Testen im Umfeld der Prozessautomatisierung
Das Ziel des Testens eines Softwaresystems besteht darin, die Wechselwirkungen der Systemkomponenten unter realen Bedingungen zu prüfen, möglichst viele Fehler aufzudecken und so
sicherzustellen, dass die Systemimplementierung die Systemspezifikation erfüllt, oder kurz, das
Finden von möglichst vielen Design- und Implementierungsfehlern am Gesamtsystem
([Pomberger und Blaschek, 1996], [Mayr, 2001]).
Bei kontinuierlichen Prozessen wie bei einer Bandverzinkungsanlage, die in der Regel rund um
die Uhr betrieben werden, müssen viele Arbeiten während der laufenden Produktion durchgeführt werden. Nur für größere Wartungs- und Instandhaltungsarbeiten werden so genannte Wartungsschichten eingelegt und die Produktion gestoppt. In machen technischen Prozessen kann der
Prozess bzw. die Produktion nur mit sehr hohem Aufwand gestoppt werden (z.B.: bei Hochöfen
zur Stahlerzeugung oder bei Kraftwerken).
Aus diesen Gründen hat das Testen in der Prozessautomatisierung einen besonders hohen Stellenwert. Oft wird der Softwaretest auch direkt in oder mit der produzierenden Anlage durchgeführt um möglichst reale Bedingungen zu erreichen. Dabei wird eine neue Software oder ein neues System mit echten Daten versorgt, die Ausgänge des Systems wirken aber nicht auf den Prozess sondern werden nur validiert. In SPS-Systemen gibt es dafür auch besondere Vorkehrungen,
die es erlauben, das Steuerungsprogramm online, d.h. während des laufenden Betriebes, zu verändern.
7.1.2
Die Inbetriebnahme im Umfeld der Prozessautomatisierung
Inbetriebnahmen von Softwarepaketen im Bereich der Prozessautomatisierung, insbesondere von
SPS-Steuerungssoftware, stellen eine Herausforderung an das Projektmanagement dar, da bei
größeren Anlagen viele Gewerke beteiligt sind, die untereinander koordiniert werden müssen.
Solche Gewerke sind unter anderem der Maschinenbau, die Medientechnik (z.B.: Hydraulik,
Kühlung), Elektrotechnik sowie die Betriebstechnik.
Ebenfalls schwierig gestaltet sich der Nachweis von Fehlern, da die Software meist erst in Verbindung mit der Anlage ihre volle Funktionalität entfaltet und der Grund eines Fehler oft nicht in
der Software sondern in den nachgeschalteten Sensoren und Aktoren zu finden ist. In der Praxis
muss der Inbetriebnahmetechniker der Automatisierungssysteme die Fehler der anderen Gewerke nachweisen und deren Behebung veranlassen. Das erfordert ein Gesamtverständnis der Anlage sowie Kenntnisse in mehreren Fachbereichen. Dieser Anforderungen werden durch die
Mechatronik abgedeckt.
Die Mechatronik ist eine interdisziplinäre Ingenieurwissenschaft, die mechanische, elektronische
und Daten verarbeitende Komponenten verknüpft, um die Leistungsfähigkeit klassischer Systeme zu verbessern und vollständig neue Funktionen zu realisieren. Neben den klassischen Ingeni-
54
eursdisziplinen rückt die Informationstechnologie in den Vordergrund, ohne die viele technische
Systeme heute nicht mehr realisierbar wären (vgl. [Mechatronik, 2004]).
7.2
Integrationstest der Schnittstelle zum Banddickenmessgerät
Schon in der Anfangsphase des Projektes wurde der Integrationstest der Schnittstelle mit dem
Banddickenmessgerät durchgeführt, da diese Schnittstelle das größte technische Risiko im Projekt
RM-Gateway darstellte.
Für diesen Test wurde der Teil der RM-Gateway Schnittstellensoftware implementiert, der die
TCP/IP-Kommunikation realisiert, kombiniert mit einer GUI für die Datenanalyse und der Möglichkeit manuell Telegramme zu versenden (siehe Abbildung 7.1). Diese Software war als TestKommunikationspartner des Banddickenmessgerätes im Einsatz.
Das Banddickenmessgerät verwendet für die interne Steuerung einen Industrie-PC auf DOSEbene mit einer speziellen Anwendersoftware. Zur Konfiguration des Messgerätes und der externen Schnittstellen werden komplexe Konfigurationsdateien verwendet, deren Dokumentation
vom Hersteller aber nicht veröffentlicht wird. Aus diesem Grund war es erforderlich, die Konfiguration der TCP/IP-Schnittstelle des Banddickenmessgerätes gemeinsam mit einem Servicetechniker der Herstellerfirma aus Erlagen durchzuführen. Die Konfiguration, Inbetriebnahme
und der Integrationstest der Schnittstelle wurde nach zwei Tagen erfolgreich abgeschlossen.
Abbildung 7.1: Testsoftware für TCP/IP-Schnittstelle Banddickenmessgerät
7.3
55
Integrationstest der Schnittstelle zur Prozessvisualisierung
Wie bereits in Kapitel 5 beschrieben, stellte die Realisierung einer DDE-Schnittstelle mit C#.NET
eine besondere Herausforderung dar. Insbesondere ist auch die Geschwindigkeit dieser Schnittstelle ein wichtiges Kriterium.
Der Integrationstest erfolgte mit einer Testinstallation des Prozessvisualisierungssystems Intouch
7.1 und einer für diesen Test vorbereiteten Version der RM-Gateway-Schnittstellensoftware.
Beim ersten Integrationstest konnte die ordnungsgemäße Funktion der Schnittstelle nachgewiesen werden, jedoch traten schwerwiegende Geschwindigkeitsprobleme auf. Bei einem
Belastungstest der DDE-Schnittstelle wurde festgestellt, dass die Übertragung einer Variablen
vom RM-Gateway zum Prozessvisualisierungssystem statt den geplanten 10 ms bis zu einer Sekunde dauerte. Eine Analyse bestätige, dass das Verschulden auf der Seite des RM-Gateway lag.
Die genaue Fehlersuche ergab, dass die Parameter von Methodenaufrufen für die DDEKommunikation im RM-Gateway nicht korrekt waren. Beim zweiten Termin des Integrationstests konnte auch die erforderliche Geschwindigkeit der Schnittstellensoftware nachgewiesen
werden. Erstmals wurden auch aktuelle Daten des Banddickenmessgerätes an das Prozessvisualisierungssystem gesendet und Daten an das Messgerät vorgegeben. Bei diesem Test wurde ein
Designfehler der Schnittstellendefinition der DDE-Schnittstelle (siehe Kapitel 3.4.2) entdeckt.
Durch DDE-Kommunikaionsvariablen, die bidirektional verwendet wurden, entstanden unter
gewissen Umständen endlose Telegrammschleifen (zyklische Telegramme) zwischen Banddickenmessgerät und Prozessvisualisierungssystem, die den Zweck der Aktualisierung von Daten
haben sollten. Durch Auftrennung der Kommunikationsvariablen in jede Kommunikationsrichtung konnte das Problem behoben werden.
7.4
Integrationstest der Datenbankanbindung
Wie in Kapitel 3.4.3 spezifiziert, ist für das Betriebsdatenarchiv eine Microsoft SQL-Datenbank
im Einsatz. Auf Grund der guten Unterstützung durch das Microsoft Visual Studio .NET Entwicklungswerkzeug konnte der Test sehr rasch abgeschlossen werden.
7.5
Inbetriebnahme und Installation
Da die Funktion der einzelnen Schnittstellen und zum Teil deren Zusammenspiel bereits bei den
Integrationstests überprüft wurde, traten bei der Inbetriebnahme der Gesamtsoftware keine besonderen Schwierigkeiten auf.
7.6
56
Erfahrungen
Der Einsatz von C#.NET für die Implementierung der RM-Gateway-Schnittstellensoftware hat
sich bewährt. Üblicherweise werden solche Systeme in C oder C++ implementiert und auf Embedded-Systemen betrieben.
Das Projektumfeld war für den Autor bereits gut bekannt, da er im Rahmen seiner langjährigen
Tätigkeit bei der Firma VOEST-ALPINE Industrieanlagenbau ([VAI, 2004]) im Bereich der Prozessautomatisierung beschäftigt war und auch bei der Planung und Inbetriebnahme von Bandverzinkungsanlagen mitarbeitete. Aus diesem Grund erfolgte die Zusammenarbeit mit den Projektpartnern effizient und ohne besondere Schwierigkeiten.
Wie in vielen Softwareprojekten wurde der Aufwand für die Erstellung der RM-Gateway Schnittstellensoftware unterschätzt. Das lag unter anderem an der Konzeption, Implementierung und
Test der DDE-Kommunikation, die von Microsoft .NET nicht mehr unterstützt wird und den
dafür erforderlichen Work-Around sowie an den erhöhten Anforderungen, die während der Projektphase entstanden sind. Ebenfalls unterschätzt wurde der Aufwand für die Einarbeitung in die
Netzwerkprogrammierung mit C# sowie die Erstellung von Testsoftware für die Simulation der
Kommunikationspartner, damit Tests während der Implementierung durchgeführt werden konnten.
Die Entwicklung der Schnittstellensoftware erfolgte hauptsächliche im Home-Office der familiären
Umgebung. Die damit verbundenen Vor- und Nachteile waren für den Implementierer eine
wertvolle Erfahrung, besonders in Bezug auf Disziplin und Zeiteinteilung. Die örtliche Entfernung zu den Projektpartnern stellte kein Problem dar, da mit modernen Kommunikationsmedien
und den regelmäßigen stattfindenden Besprechungen der Informationsaustausch problemlos
funktionierte.
8 Zusammenfassung
8
57
Zusammenfassung
Durch die Einführung dieses Systems erreicht man einerseits die geforderte Aufzeichnung qualitätsrelevanter Daten im Betriebsdatenarchiv, andererseits die Integration des Banddickenmessgerätes in die Automationsstruktur der Anlage und die Einsparung von manuellen Dateneingaben
durch das Bedienpersonal.
8.1
Erreichte Ziele
Die Implementierung der RM-Gateway-Schnittstellensoftware ist abgeschlossen und das System
ist in der Bandverzinkungsanlage im Einsatz. Die gestellten Anforderungen konnten mit den
eingesetzten Technologien erfüllt werden.
Folgende Ziele konnten erreicht werden:
•
Konzeption und Design des Systems,
•
Realisierung einer lauffähigen Software,
•
Schaffung einer fundierten Basis für die Entwicklung vergleichbarer Systeme.
8.2
Offene Punkte
Wie oben erwähnt, ist die Implementierung des RM-Gateway grundsätzlich abgeschlossen und
entspricht den in Kapitel 3 spezifizierten Anforderungen. In folgenden Punkten kann das System
im Fall der Erstellung einer neuen Version verbessert werden:
8.3
•
Konfigurationsmöglichkeiten: Der Konfigurationsmöglichkeiten sollen wesentlich erhöht
werden.
•
Benutzerschnittstelle: Das Diagnose- und Konfigurationstool besitzt nur minimale Funktionalität und soll erweitert werden.
•
Webbasierte Benutzerschnittstelle: Die Entwicklung eines webbasierten Diagnose- und Konfigurationssystems soll durchgeführt werden.
•
Schnittstellen: Zusätzliche externe Schnittstellen sollen vorgesehen werden.
Resümee und Ausblick
Es ist geplant, das RM-Gateway auch bei anderen Anlagen zu verwenden, die ebenfalls Banddickenmessgeräte der Fa. Radiometrie im Einsatz haben. Da es sich um andere Gerätetypen handelt, ist die Telegrammstruktur der TCP/IP-Schnittstelle unterschiedlich. Das Konzept der
8 Zusammenfassung
58
Schnittstellensoftware erlaubt es mit geringem Programmieraufwand Anpassungen bei der Telegrammstruktur des Banddickenmessgerätes sowie Änderungen bei den anderen Kommunikationsschnittstellen durchzuführen.
Weiters ist vorgesehen, die RM-Gateway-Schnittstellensoftware mit einer webbasierten Konfigurations- und Diagnosemöglichkeit zu versehen, die ähnlich der von handelsüblichen Netzwerkkomponenten aufgebaut ist. Damit kann die Inbetriebnahme und Wartung des Systems flexibel
und ortunabhängig erfolgen. Die Firma Tensor arbeitet auch an einer modularen industrietauglichen Hardwareplattform, auf der das RM-Gateway kostengünstig betrieben werden kann.
Die Aufgabe, Prozessdaten in einer Datenbank zu speichern, erfordert normalerweise einen hohen Aufwand an Individualprogrammierung. Das bei diesem Projekt entwickelte Konzept kann
erweitert und flexibel für diese Aufgaben eingesetzt werden, indem es Daten von verschiedenen
Quellen über Bussysteme bezieht und konfigurierbar in eine Datenbank speichert.
Auch in anderen Disziplinen der Automatisierungstechnik wie beispielsweise in der Gebäudeautomation besteht vermehrt der Wunsch, Gebäudedaten zu erfassen und in Datenbanken zur weitern Analyse, beispielsweise zur Energieoptimierung, zu archivieren. Auch für diese Anwendung
ist der Einsatz eines ähnlichen Konzeptes wie in diesem Projekt erarbeiteten denkbar.
59
Literaturverzeichnis
[ABB, 2004]
ABB. Pulsed Eddy Current Technology. http://www.abb.com/global/abbzh/
abbzh251.nsf!OpenDatabase&db=/global/seapr/seapr035.nsf&v=6312A&e=us&m
=9F2&c=5A9849F2669EAC5CC1256AB5004038BE, Zugriff: 22.04.2004.
[Andritz, 2004]
Andritz. Strip Processing Lines. http://www.andritz.com/de/ANONIDZ64C22099
A91CAD28/rmsp/rmsp-products/rmsp-process-lines.htm, Zugriff: 22.04.2004.
[Beckhoff, 2004]
Beckhoff. New Automation Technology. http://www.beckhoff.at/, Zugriff: 04.05.2004.
[Bolch, 2004]
Gunther Bolch. Universität Erlangen-Nürnberg, Skript zur Prozessautomatisierung.
http://www4.informatik.uni-erlangen.de/Lehre/SS02/V_PA/skript/,
Zugriff:
04.05.2004.
[Bolch und Vollath, 1993]
Bolch, Gunter und Vollath, Martina-Maria. Prozessautomatisierung. 2., überarbeitete und
erweiterte Auflage, B.G. Teubner Stuttgart, Deutschland, 1993.
[Blum, 2003]
Richard Blum. C# Network Programming, Sybex Verlag , Köln, Deutschland, 2003.
[Copadata, 2004]
Copadata. Software for industrial Application. http://www.copadata.de/, Zugriff:
18.05.2004.
[DIN, 1972]
Norm DIN 19233. Automat, Begriffe, Deutsches Institut für Normung e.V., Berlin,
Deutschland, 1972.
[DIN, 1981]
Norm DIN 66201. Prozessrechensysteme, Begriffe, Deutsches Institut für Normung e.V.,
Berlin, Deutschland, 1981.
[Ethereal, 2004]
Ethereal Homepage. http://www.ethereal.com/, Zugriff: 17.05.2004.
60
[Heinzelreiter, 2003]
Johann Heinzelreiter. .NET Architektur. Vorlesungsskriptum, Fachhochschule
Hagenberg, Studiengang "Software Engineering", Hagenberg, Österreich, 2003.
[IEEE, 2004]
IEEE. IEEE Std 754-1985 IEEE Standard for Binary Floating-Point Arithmetic –
Description. http://standards.ieee.org/reading/ieee/std_public/description/busarch/
754-1985_desc.html, Zugriff: 03.06.2004.
[Labview, 2004]
National Instruments. LabView, http://www.labview.net/, Zugriff: 03.06.2004.
[Lau, 2004]
Oliver Lau. Rückwärtsgang COM-Interop-COM aus der .NET-Perspektive. c’t Magazin für
Computertechnik, pp. 208-211, Nr. 10, 2004.
[Mayr, 2001]
Herwig Mayr. Projekt Engineering – Ingenieurmäßige Softwareentwicklung in Projektgruppen,
Carl Hanser Verlag, München Wien, Deutschland, 2001.
[Mechatronik, 2004]
Mechatronik Portal. http://www.mechatronik-portal.de/ Zugriff: 10.05.2004.
[Microsoft, 2004a]
Microsoft. Creating a NetDDE Link in Excel on Windows NT. http://support.microsoft
.com/default.aspx?scid=http://support.microsoft.com:80/support/kb/articles/q12
8/4/91.asp&NoWebContent=1, Zugriff: 22.04.2004.
[Microsoft, 2004b]
Microsoft. Dynamic Data Exchange Changes in Visual Basic .NET. http://msdn.
microsoft.com/library/default.asp?url=/library/en-us/vbcon/html/vbcondynamic
dataexchangechangesinvisualbasicnet.asp, Zugriff: 22.04.2004.
[Microsoft, 2004c]
Microsoft. Das .Windows .NET Framework, http://net.microsoft.at/story.aspx
?id=6775, Zugriff: 06.05.2004.
[Monadjemi, 1993]
Peter Monadjemi. Visual Basic 3.0 für Windows. Markt&Technik Verlag, München,
Deutschland, 1993.
61
[Mono, 2004]
Mono Homepage. http://www.go-mono.com/, Zugriff: 06.05.2004.
[Moses und Novak, 2002]
Daniel Moses und Johannes Novak. C# Programmieren unter .NET. Franzis Verlag,
München, Deutschland, 2002.
[OpenOffice, 2004]
OpenOffice Homepage. http://de.openoffice.org/, Zugriff: 01.06.2004.
[Plate, 2004a]
Jürgen Plate. Grundlagen Computernetze.
netze/netz8.html, Zugriff: 06.05.2004.
http://www.netzmafia.de/skripten/
[Plate, 2004b]
Jürgen
Plate.
Netzwerkprogrammierung,
server/server3.html, Zugriff: 06.05.2004.
http://www.netzmafia.de/skripten/
[Pomberger und Blaschek, 1996]
Pomberger Gustav und Blaschek Günther. Software Engineering. Carl Hanser Verlag
München Wien, Deutschland, 1996.
[Profibus, 2004]
Pofibus Nutzerorganisation. http://www.profibus.com/, Zugriff: 03.06.2004.
[Radiometrie, 1999]
Radiometrie. M100k Connecting. Internes Dokument, Erlangen, Deuschland 1999.
[Rathjen, 2004]
Gerald Rathjen. Austausch von Daten mit DDE und OLE. http://members.aol.com/
gerrathjen/EDV-Verlag/DDEundOLE.htm#Geschichte, Zugriff: 22.04.2004.
[Rechenberg und Pomberger, 1999]
Rechenberg Peter und Pomberger Gustav. Informatik-Handbuch. Carl Hanser Verlag
München Wien, Deutschland, 1999.
[Reliance, 2004]
Reliance Electric Hompage. http://www.reliance.com/, Zugriff: 22.04.2004.
62
[Schröder, 2003]
Norbert Schröder, Intechno Consulting. Process Automation Market 2010,
http://www.intechnoconsulting.com/pdfs/E%20PA2010%20Presse.pdf,
Basel,
Schweiz, 2003
[Siemens, 2004]
Siemens Automation and Drives. http://www.ad.siemens.de/, Zugriff: 18.05.2004.
[Tanenbaum, 2000]
Andrew S. Tanenbaum. Computernetzwerke. Prentice Hall, München, Deutschland,
2000.
[Technomatrix, 2004]
Technomatrix Homepage. http://www.tecnomatix.com/, Zugriff: 18.05.2004.
[Tensor, 2004]
Tensor. Industrielle Elektrotechnik. http://www.tensor.at/, Zugriff: 22.04.2004.
[VAI, 2004]
VOEST-ALPINE Industrieanlagenbau Homepage. http://www.vai.at/, Zugriff:
10.05.2004.
[Volmer, 2004]
Volmer Gauge Homepage. http://www.vollmer-gauge.com/brochures/brochures/Xray%20Gauge%20Brochure-u10.pdf, Zugriff: 11.05.2004.
[Wilson, 1999]
Tom Wilson. PLC based substation automation and SCADA Systems, and selecting a control
system integrator. http://www.pcsutilidata.com/White%20Papers/WEPI%201999
%20Paper.pdf, Zugriff: 22.04.2004.
[Wonderware, 2004]
Invensys-Wonderware Homepage. http://www.wonderware.at/, Zugriff: 18.05.2004.
[Wuppermann, 2004]
Wuppermann. Die Gruppe. http://www.wuppermann.at/gruppe.html, Zugriff:
22.04.2004.

Entwicklung einer Schnittstellensoftware für die Erfassung und

Transcription

Similar documents

Viren, Würmer, Trojaner und Malware

Dr. MAHALINGAM COLLEGE OF ENGINEERING AND

geschäftsbericht 2014

geschäftsbericht 2012

SMS Siemag AG - ALU

VIP 08 – Optische Planheitsmessung VIP 08 – Optische