DIPLOMARBEIT

DIPLOMARBEIT
Entwicklung von Softwarekomponenten zur vertikalen Integration
von Maschinen und Anlagen im Produktionsumfeld
der Fischer GmbH
durchgeführt am
Studiengang Telekommunikationstechnik und –systeme
an der
Fachhochschule Salzburg
vorgelegt von
Rainer Itzinger
Leiter des Studiengangs:
Betreuer:
Prof. Dipl.-Ing. Dr. Gerhard Jöchtl
Prof. Dipl.-Ing. Dr. Thomas J. Heistracher
Salzburg, Juni 2006
Danksagung
Seite - I -
Danksagung
Ich möchte mich herzlich bei allen Menschen bedanken, die zum Gelingen dieser
Diplomarbeit beigetragen haben sowie den erfolgreichen Abschluss des Studiums
ermöglichten.
Allen voran danke ich meiner Freundin Gertraud für ihre Unterstützung und ihr
Verständnis während der gesamten Studienzeit. Ihr Rückhalt und Ansporn gab mir stets die
notwendige Kraft und Motivation.
Herrn Prof. Dipl.-Ing. Dr. Thomas J. Heistracher danke ich für seine Bereitschaft die
Diplomarbeitsbetreuung kurzfristig zu übernehmen.
Abschließend möchte ich mich bei allen Mitarbeitern der FH Salzburg bedanken, ohne die
ein Studiengang für Berufstätige erst gar nicht möglich wäre.
Eidesstattliche Erklärung
Seite - II -
Eidesstattliche Erklärung
Hiermit versichere ich, Rainer Itzinger, geboren am 07.02.1978 in Schärding, dass die
vorliegende Diplomarbeit von mir selbstständig verfasst wurde. Zur Erstellung wurden von
mir keine anderen, als die angegebenen Quellen und Hilfsmittel verwendet.
________________________
________________________
Rainer Itzinger
Matrikelnummer
Informationen
Seite - III -
Informationen
Vor- und Zuname:
Rainer Itzinger
Institution:
FH-Salzburg Fachhochschulgesellschaft mbH
Studiengang:
Telekommunikationstechnik und –systeme
Titel der Diplomarbeit:
Entwicklung
von
Softwarekomponenten
zur
vertikalen Integration von Maschinen und Anlagen im
Produktionsumfeld der Fischer GmbH
Betreuer an der FH:
Prof. Dipl.-Ing. Dr. Thomas J. Heistracher
Betreuer in der Firma:
Mag. Dr. Matthias Gruber
Schlagwörter
1. Schlagwort:
Vertikale Integration
2. Schlagwort:
Softwarekomponenten
3. Schlagwort:
OPC (Openess, Productivity and Collaboration)
Abstract
This diploma thesis describes the design and implementation of software components
which are the basis for efficient application development in an industrial environment. The
technical and economical requirements lead to the discussion of possible solutions. A
comparison between J2EE (Java 2 Enterprise Edition) and Microsoft’s .NET component
model results in the selection of an integrated development environment (IDE). The
theoretical background deals with DCOM (distributed component object model) and the
.NET framework as base technologies for software component development on a Microsoft
Windows system. The term “vertical integration” and OPC (openess, productivity and
collaboration), as standard technology for vendor independent PLC (programmable logic
controller) communication, are introduced. The implementation part includes UML
(unified modelling language) and the ER (entity relationship) schemes of the software
components and the database. The development of a component-based real life application
concludes the practical part of the thesis. The thesis closes with an outlook to possible
extensions in the future.
Inhaltsverzeichnis
Seite - IV -
Inhaltsverzeichnis
Danksagung ............................................................................................................................I
Eidesstattliche Erklärung.......................................................................................................II
Informationen ...................................................................................................................... III
Schlagwörter........................................................................................................................ III
Abstract................................................................................................................................ III
Inhaltsverzeichnis ................................................................................................................ IV
Abbildungsverzeichnis ........................................................................................................ VI
Tabellenverzeichnis .......................................................................................................... VIII
Listings ................................................................................................................................ IX
1.
2.
3.
4.
Einleitung ...................................................................................................................... 1
1.1
Projektziele ............................................................................................................ 1
1.2
Motivation zum Thema ......................................................................................... 2
1.3
Inhalte der Diplomarbeit........................................................................................ 2
Systemanforderungen .................................................................................................... 3
2.1
Wirtschaftliche Rahmenbedingungen ................................................................... 4
2.2
Technische Anforderungen.................................................................................... 4
Beschreibung möglicher Lösungswege ......................................................................... 8
3.1
Entwicklungsplattform .......................................................................................... 8
3.2
Entwicklungsumgebung ...................................................................................... 13
3.3
Datenbanksystem................................................................................................. 13
3.4
OPC-Client-Komponenten .................................................................................. 14
Theoretischer Hintergrund........................................................................................... 15
4.1
5.
Softwarekomponenten ......................................................................................... 15
4.1.1
Distributed Component Object Model ........................................................ 17
4.1.2
Microsoft .NET-Framework........................................................................ 24
4.2
Datenbanksysteme ............................................................................................... 30
4.3
Vertikale Integration............................................................................................ 33
4.3.1
IT Infrastruktur der Fischer GmbH ............................................................. 35
4.3.2
Speicherprogrammierbare Steuerungen ...................................................... 35
4.3.3
Openess, Productivity and Collaboration .................................................... 39
Implementierung der Lösung....................................................................................... 45
Inhaltsverzeichnis
Seite - V -
5.1
Eingesetzte Softwareprodukte ............................................................................. 45
5.2
Designaspekte...................................................................................................... 46
5.2.1
Trennung der Funktionalitäten in Komponenten ........................................ 47
5.2.2
Designpatterns ............................................................................................. 50
5.2.3
Unabhängigkeit vom Datenbanksystem ...................................................... 51
5.3
Lokale Anwendungsdatenbank............................................................................ 53
5.3.1
Verwaltung der Produktionsdaten ............................................................... 53
5.3.2
Konfigurations-Tabellen.............................................................................. 55
5.4
Komponente OpcManager................................................................................... 62
5.4.1
Initialisierung............................................................................................... 62
5.4.2
Öffentliche Methoden, Eigenschaften und Ereignisse ................................ 63
5.5
Komponente DataManager.................................................................................. 63
5.5.1
Initialisierung............................................................................................... 64
5.5.2
Öffentliche Methoden, Eigenschaften und Ereignisse ................................ 64
5.6
6.
Komponente MachineManager ........................................................................... 64
5.6.1
Initialisierung............................................................................................... 65
5.6.2
Öffentliche Methoden, Eigenschaften und Ereignisse ................................ 66
Anwendung der Softwarekomponenten ...................................................................... 67
6.1
Aufbau der Demonstrationsanwendung .............................................................. 67
6.2
Test der Leitrechneranwendung .......................................................................... 68
6.3
Zusammenfassung ............................................................................................... 70
7.
Ausblick....................................................................................................................... 71
Literaturverzeichnis ............................................................................................................. 73
Abkürzungsverzeichnis ....................................................................................................... 75
Anhang ................................................................................................................................ 77
A.
Beschreibung der Daten- und Konfigurationstabellen ............................................ 77
B.
Öffentliche Methoden, Eigenschaften und Ereignisse der Komponenten............... 81
C.
Vollständige UML-Klassendiagramme................................................................... 90
D.
Screenshots der Demonstrationsanwendung ........................................................... 93
Abbildungsverzeichnis
Seite - VI -
Abbildungsverzeichnis
Abbildung 2.1: Systemumfeld der Softwarekomponenten ................................................... 3
Abbildung 2.2: Ablauf einer Datenanfrage ........................................................................... 5
Abbildung 4.1: Entwicklungswege von DCOM ................................................................. 17
Abbildung 4.2: Darstellungsarten einer COM Komponente ............................................... 19
Abbildung 4.3: CLSID-Eintrag in der Windows-Registry.................................................. 19
Abbildung 4.4: Schnittstelle IUnknown .............................................................................. 21
Abbildung 4.5: IID-Eintrag von IUnknown in der Windows-Registry............................... 22
Abbildung 4.6: Assemblies als Weitergabeeinheit [Löwy05]............................................. 27
Abbildung 4.7: Client und Server Assemblies [Löwy05] ................................................... 27
Abbildung 4.8: Verschiedene Assembly Kompositionen [Löwy05] .................................. 28
Abbildung 4.9: Datenbanksystem ....................................................................................... 30
Abbildung 4.10: ER-Modell einer Tabellenbeziehung ....................................................... 31
Abbildung 4.11: Data provider in .NET [Hami03] ............................................................ 32
Abbildung 4.12: Automatisierungsebenen in Produktionsbetrieben [Seit03]..................... 33
Abbildung 4.13: Beispielkonfiguration eines SPS-Systems [Bern06] ................................ 36
Abbildung 4.14: Verfügbare und in Arbeit befindliche OPC-Spezifikationen [Iwan05].... 40
Abbildung 4.15: OPC-DA-Server – Namensraum und Objekthierarchie [Iwan05] ........... 42
Abbildung 4.16: Zugriff auf OPC-DCOM-Server mit .NET-Komponenten [Iwan05]....... 44
Abbildung 5.1: Architekturübersicht einer komponentenbasierten Leitrechneranwendung47
Abbildung 5.2: Befüllung, Aktualisierung und Bereinigung der Tabelle MachineData..... 54
Abbildung 5.3: Konfigurationstabellen der Komponente OpcManager ............................. 56
Abbildung 5.4: Beispielkonfiguration der Komponente OpcManager ............................... 57
Abbildung 5.5: Konfigurationstabellen der Komponente DataManager............................. 58
Abbildung 5.6: Beispielkonfiguration der Komponente DataManager............................... 59
Abbildung 5.7: Konfigurationstabellen der Komponente MachineManager ...................... 60
Abbildung 5.8: Beispielkonfiguration der Komponente MachineManager ........................ 61
Abbildung 5.9: UML-Klassendiagramm OpcManager ....................................................... 62
Abbildung 5.10: UML-Klassendiagramm DataManager .................................................... 63
Abbildung 5.11: UML-Klassendiagramm MachineManager.............................................. 65
Abbildung 6.1: Umfeld der entwickelten Leitrechneranwendung ...................................... 67
Abbildung 6.2: Aufzeichnung des Speicherbedarfs der Leitrechneranwendung ................ 70
Abbildungsverzeichnis
Seite - VII -
Abbildung C.1: UML-Klassendiagramm OpcManager ...................................................... 90
Abbildung C.2: UML-Klassendiagramm DataManager ..................................................... 91
Abbildung C.3: UML-Klassendiagramm MachineManager ............................................... 92
Abbildung D.1: Demonstrationsanwendung – Anlagenübersicht ....................................... 93
Abbildung D.2: Demonstrationsanwendung – Übersicht Schwabbelmaschine .................. 94
Abbildung D.3: Demonstrationsanwendung – Übersicht Entgratmaschine........................ 95
Abbildung D.4: Demonstrationsanwendung – Übersicht Schleifmaschine ........................ 96
Abbildung D.5: Demonstrationsanwendung – Auftragsübersicht....................................... 97
Abbildung D.6: Demonstrationsanwendung – Auftragsdetails........................................... 98
Abbildung D.7: Demonstrationsanwendung – Aufträge in Maschinen .............................. 99
Tabellenverzeichnis
Seite - VIII -
Tabellenverzeichnis
Tabelle 1.1: Produktionszahlen der Fischer GmbH............................................................... 1
Tabelle 3.1: Bewertungsmatrix J2EE vs. .NET................................................................... 12
Tabelle 4.1: OPC Spezifikationen – Bedeutung und Freigabestatus (02/2006) [Iwan05] .. 41
Tabelle 5.1: Eingesetzte Softwareprodukte ......................................................................... 46
Tabelle 6.1: Verwendete Hardware im Testaufbau ............................................................. 68
Tabelle A.1: Zwingend erforderliche Felder der Tabelle MachineData ............................. 77
Tabelle A.2: Felder der Tabelle Config_OpcConnections .................................................. 77
Tabelle A.3: Felder der Tabelle Config_OpcGroups .......................................................... 78
Tabelle A.4: Felder der Tabelle Config_OpcItems ............................................................. 78
Tabelle A.5: Felder der Tabelle Config_DataProcedureCalls............................................. 78
Tabelle A.6: Felder der Tabelle Config_DataFileTransfer ................................................. 78
Tabelle A.7: Felder der Tabelle Config_MachineInterfaceItems........................................ 79
Tabelle A.8: Felder der Tabelle Config_MachineDataItems .............................................. 80
Tabelle A.9: Felder der Tabelle Config_MachineFileDownload........................................ 80
Tabelle B.1: Öffentliche Methoden der Komponente OpcManager ................................... 81
Tabelle B.2: Öffentliche Eigenschaften der Komponente OpcManager............................. 82
Tabelle B.3: Öffentliche Ereignisse der Komponente OpcManager................................... 82
Tabelle B.4: Öffentliche Methoden der Komponente DataManager .................................. 84
Tabelle B.5: Öffentliche Eigenschaften der Komponente DataManager ............................ 84
Tabelle B.6: Öffentliche Ereignisse der Komponente DataManager .................................. 85
Tabelle B.7: Öffentliche Methoden der Komponente MachineManager ............................ 87
Tabelle B.8: Öffentliche Eigenschaften der Komponente MachineManager...................... 88
Tabelle B.9: Öffentliche Ereignisse der Komponente MachineManager............................ 89
Listings
Seite - IX -
Listings
Listing 4.1: Beispielcode “Hello World” in C#................................................................... 25
Listing 4.2: Beispielcode “Hello World” in MSIL.............................................................. 25
Listing 4.3: SPS Programmierung im Kontaktplan ............................................................. 38
Listing 4.4: SPS Programmierung mit Automation Basic................................................... 38
Listing 5.1: Singleton Implementierung in C# .................................................................... 50
Listing 5.2: Observer-Pattern – DataManager Klasse ......................................................... 51
Listing 5.3: Observer-Pattern – Client Klasse ..................................................................... 51
Listing 5.4: Verwendung von Providerfactories in ADO.NET 2.0 ..................................... 52
Listing 5.5: Initialisierung der Komponente OpcManager.................................................. 63
Listing 5.6: Initialisierung der Komponente DataManager................................................. 64
Listing 5.7: Initialisierung der Komponente MachineManager .......................................... 66
1. Einleitung
1.
Seite - 1 –
Einleitung
Die Produkte der Fischer GmbH1 unterliegen jährlich kollektionsbedingten Modifikationen
und Variationen. Eine Massenproduktion der unterschiedlichen Artikel mit einer
minimalen
Losgröße von eins erfordert die Übergabe von produktbezogenen
Produktionsparametern an die Maschinen und Anlagen im Fertigungsprozess. Für die
konsistente Datenanbindung der heterogenen Produktionsebene an die Business ITSysteme, in denen die Daten erfasst werden, sind je nach Produktionsbereich eine oder
mehrere
Schnittstellenanwendungen
erforderlich.
Die
Entwicklungskosten
dieser
Anwendungen sollen durch den Einsatz von Softwarekomponenten minimiert werden.
Die Fischer GmbH mit ihrem Hauptsitz in Ried im Innkreis ist weltweit der größte
Produzent von Alpin- und Langlaufskiern. An den Produktionsstandorten Ried und
Mukachevo (Ukraine) wurden im Geschäftsjahr 2005/2006 insgesamt rund 1.800.000 Paar
Alpin- und Langlaufski gefertigt.
Geschäftsjahr 2005/2006 Ziel Geschäftsjahr 2006/2007
Umsatz Alpin
97.400.000 €
104.000.000 €
Umsatz Nordisch
57.000.000 €
61.900.000 €
Stückzahlen Gesamt
1.800.000 Paar
1.850.000 Paar
Tabelle 1.1: Produktionszahlen der Fischer GmbH
1.1
Projektziele
Ziel der Diplomarbeit „Entwicklung von Softwarekomponenten zur vertikalen Integration
von Maschinen und Anlagen im Produktionsumfeld der Fischer GmbH“
ist die
Entwicklung von Softwarebausteinen um Applikationen zur Datenanbindung von
Maschinen und Anlagen effizient erstellen zu können. In weiterer Folge werden diese
Applikationen als Leitrechneranwendungen bezeichnet. Im Rahmen des Projektes sollen
abgeleitet aus den technischen und wirtschaftlichen Anforderungen der Fischer GmbH, die
Basisfunktionalitäten
einer
Leitrechneranwendung
in
verschiedene
Komponenten
gekapselt werden. Die Plattform- sowie Designentscheidungen sind hierbei in Bezug auf
die Anforderungen nachvollziehbar zu dokumentieren. Eine produktiv eingesetzte
1
http://www.fischer-ski.com
1. Einleitung
Seite - 2 –
Leitrechneranwendung soll bei Projektabschluss die Leistungsfähigkeit der entwickelten
Komponenten zeigen.
1.2
Motivation zum Thema
Die 3-Schicht Produktion der Fischer GmbH erfordert eine Verfügbarkeit der
Leitrechneranwendungen bis zu 24 Stunden am Tag 365 Tage im Jahr. Die Entwicklung
von Softwarekomponenten, welche als Basis für diese Anwendungen dienen, stellt eine
große Herausforderung dar. Die Umsetzung der festgelegten Anforderungen erfordert das
Einarbeiten in neue Technologien wie OPC (Openess, Productivity and Collaboration)
sowie das Erlernen der .NET-Programmiersprache C#. Die Kombination der
verschiedenen Technologien in einem produktiven System stellte den stärksten
Motivationsfaktor für den Autor dar.
1.3
Inhalte der Diplomarbeit
Die Arbeit beschreibt das Design und die Implementierung von Softwarebausteinen,
welche als Basis für Leitrechneranwendungen zur Produktionsdatenanbindung von
Maschinen oder Anlagen dienen. Die Anforderungen in wirtschaftlicher sowie technischer
Hinsicht leiten zur Beschreibung der möglichen Lösungswege über. Ein Vergleich der
Komponentenmodelle J2EE (Java 2 Enterprise Edition) und .NET resultiert in der
Auswahl einer entsprechenden Entwicklungsumgebung. Das zu verwendende OPC-ClientToolkit
sowie
das
Datenbanksystem
wurden,
auf
Basis
der
getroffenen
Technologieentscheidung, durch die Fischer GmbH vorgegeben. Der theoretische
Hintergrund beschreibt DCOM (Distributed Component Object Model) und das .NETFramework als Basistechnologien der Komponentenentwicklung unter Microsoft Windows
sowie den Begriff „Vertikale Integration“ und die Technologiestandards zu deren
Umsetzung. Speziell OPC wird in diesem Rahmen als Satz von Spezifikationen zur
herstellerunabhängigen Kommunikation mit verschiedensten Maschinensteuerungen
genauer betrachtet. Im Teil der Implementierung wird das Software- und Datenbankdesign
der einzelnen Komponenten mittels UML-Diagrammen (Unified Modeling Language)
bzw. ER-Modellierung (Entity Relationship) beschrieben. Eine Übersicht über die
Softwarekomponenten sowie deren Anwendung in einer in der Praxis eingesetzten
Leitrechneranwendung schließen den praktischen Teil der Arbeit ab. Der Ausblick zeigt
das Weiterentwicklungspotential der komponentenbasierten Leitrechneranwendungen auf.
2. Systemanforderungen
2.
Seite - 3 –
Systemanforderungen
Zur erfolgreichen Abwicklung eines Softwareprojekts ist die konkrete Definition der
Produktanforderungen erforderlich. Während der Projektstartphase wurden diese mit den
Verantwortlichen der Fischer GmbH besprochen und fixiert. Abbildung 2.1 zeigt das
Systemumfeld, in dem die Softwarekomponenten zum Einsatz kommen. Die Auftrags- und
Artikelstammdaten sowie die Produktionsdaten werden in einem Oracle-Datenbanksystem
verwaltet. Zur Datenerfassung wird überwiegend das ERP-System (Enterprise Ressource
Planning) „JD Edwards EnterpriseOne“1 verwendet. Weitere Datenerfassungsmasken
bzw. Systemschnittstellen ermöglichen die manuelle oder automatische Übergabe
produktionsrelevanter Daten, welche nicht durch das ERP-System verwaltet werden. Als
Beispiel können hier Konstruktionsdaten aus dem CAD-System (Computer Aided Design)
genannt werden.
Abbildung 2.1: Systemumfeld der Softwarekomponenten
Aufgabe einer Leitrechneranwendung ist die Kopplung des Datenbestands der Business ITSysteme mit der heterogenen Hard- und Softwarewelt der Feldebene. Neben dem
Datenaustausch mit den Steuerungssystemen, muss eine Leitrechneranwendung auch
anwendungsspezifische
ermöglichen.
1
Die
Benutzerinteraktionen
Erstellung
der
während
Anwendungen
http://www.oracle.com/applications/jdedwards-enterprise-one.html
soll
des
durch
Produktionsprozesses
den
Einsatz
von
2. Systemanforderungen
Seite - 4 –
Softwarekomponenten vereinfacht und effizient gestaltet werden. Während der Definition
der Anforderungen wurden neben den technischen Ablaufbeschreibungen und Kriterien
auch wirtschaftliche Rahmenbedingungen seitens der Fischer GmbH vorgegeben.
2.1
Wirtschaftliche Rahmenbedingungen
Um die Entwicklung der Softwarekomponenten zu ermöglichen, investiert die Fischer
GmbH
in
neue
Softwareprodukte.
Im
Rahmen
der
Diplomarbeit
soll
eine
Technologieentscheidung zwischen Java 2 Enterprise Edition1 und Microsoft .NET2
getroffen werden. In wirtschaftlicher Hinsicht sind bei der Anschaffung von
Softwareprodukten
minimale
Lizenzkosten
bei
maximaler
Investitionssicherheit
anzustreben. Bei der Auswahl des Komponentenmodells und der Entwicklungsumgebung
sind diese Aspekte zu berücksichtigen. Abgesehen von den Anschaffungskosten und den
laufenden Folgekosten der neuen Softwareprodukte sind auch die Aufwendungen für die
interne bzw. externe Ausbildung der Mitarbeiter der Fischer GmbH zu berücksichtigen.
Der Einsatz von Standardprodukten soll die Verfügbarkeit von Personen mit
entsprechenden Basisqualifikationen am Arbeitsmarkt garantieren.
2.2
Technische Anforderungen
Zur Erläuterung der einzelnen technischen Anforderungen an ein Leitrechnersystem
müssen zuerst die Zielsetzungen der Gesamtanwendung besprochen werden.
Grundlegende
Funktion
einer
Leitrechneranwendung
produktspezifischen
Produktionsparametern
Steuerungssysteme
der
angebundenen
und
ist
Daten
Maschinen
und
auf
der
die
Transfer
von
verschiedenen
Anlagen.
An
eine
Leitrechneranwendung müssen eine oder mehrere Maschinen angebunden werden können.
Der Datentransfer wird durch die Anfrage einer Maschinensteuerung initiiert. Die
einzelnen Maschinen und Anlagen sind hierfür mit Sensoren zur Produkterkennung
ausgestattet. Derzeit werden Barcodelesegeräte eingesetzt, welche über industrielle
Bussysteme angebunden sind. Die Leitrechneranwendungen müssen vom Typ und dem
Hersteller des Steuerungssystems unabhängig sein. Die Art der Anbindung der Sensoren an
das Steuerungssystem darf ebenfalls keine Rolle spielen.
1
http://www.sun.com
2
http://www.microsoft.com
2. Systemanforderungen
Seite - 5 –
Die Leitrechneranwendung muss aus in verschiedenen Oracle-Tabellen verteilten
Produktdaten einen Datensatz mit allen relevanten Produktionsdaten generieren können.
Diese Datensätze sollen lokal am Leitrechner verwaltet werden. Eine Maschinensteuerung
hält mehrere Parametersätze für entsprechende Produktkennungen lokal in einer Art
Pufferspeicher.
Das Flussdiagramm in Abbildung 2.2 zeigt symbolisch den Ablauf einer Datenanfrage. Im
Diagramm steht die Abkürzung SPS für „Speicherprogrammierbare Steuerung“ und
bezeichnet allgemein die Maschinensteuerungssysteme.
Abbildung 2.2: Ablauf einer Datenanfrage
2. Systemanforderungen
Seite - 6 –
Nach der Übergabe des zu bearbeitenden Produkts erfasst die Maschine mit Hilfe der
entsprechenden Sensorik die aufgebrachte Produktkennung. Anschließend wird überprüft,
ob Daten für die Produktkennung bereits auf der Maschine verfügbar sind. Zu diesem
Zweck wird auf der Maschinensteuerung der oben erwähnte Puffer für verschiedene Sätze
von Produktionsparametern durchsucht. Sollte der passende Parametersatz bereits
vorhanden sein, werden die Daten unmittelbar für die Bearbeitung übernommen. Ist dies
nicht der Fall, stellt die Maschinensteuerung eine Anfrage an die Leitrechneranwendung.
Die beschriebene lokale Speicherung mehrerer Parametersätze auf der Maschinensteuerung
hat entscheidende Vorteile. Die Leitrechneranwendung wird entlastet, da nicht für jedes
einzelne Produkt eines Loses die entsprechenden Daten gesucht und zur Steuerung
übertragen werden müssen. Der Leitrechner kann somit auch während der laufenden
Produktion für kurze Zeit, z.B. zur Durchführung von Wartungsarbeiten, deaktiviert
werden. Erhält die Leitrechneranwendung eine Anfrage von einer Maschinensteuerung
wird der lokale Datenspeicher auf dem Leitrechner nach den entsprechenden Parametersatz
durchsucht. Werden Daten gefunden schreibt die Leitrechneranwendung diese in einen
freien Pufferplatz auf der Maschinensteuerung und gibt eine entsprechende Rückmeldung
an die SPS. Sollten keine Daten vorhanden sein, wird ein Fehler an die Steuerung
gemeldet. In diesem Fall muss eine anlagenspezifische Fehlerbehandlung auf der
Maschinensteuerung erfolgen.
Durch die lokale Verwaltung der Produktionsparameter auf dem Leitrechner wird eine
gewisse Unabhängigkeit vom Intranet der Fischer GmbH erreicht. Eine Verbindung zum
Datenbankserver ist nur für das Laden und Aktualisieren der Daten notwendig. Dies
geschieht in der Regel einmal täglich. Wartungsarbeiten am Oracle-Server beinträchtigen
somit die Produktion nicht. Als weiterer Vorteil kann die erhöhte Flexibilität bei der
Inbetriebnahme von Neumaschinen genannt werden. Der Leitrechner kann eigenständig im
Haus des Maschinenbauers verwendet werden, sofern ein erstmaliges Laden der Daten bei
bestehender Netzwerkverbindung im Hausnetz der Fischer GmbH erfolgt ist. Bei der
Konzeption des lokalen Datenspeichers muss die einfache Erweiterbarkeit um zusätzliche
Produktionsparameter berücksichtigt werden.
2. Systemanforderungen
Seite - 7 –
Zusammenfassend können folgende technische Kriterien für die Basiskomponenten einer
Leitrechneranwendung hervorgehoben werden:
Die
•
Unabhängigkeit von der Datenherkunft der Produktionsdaten
•
Lokale Datenspeicherung auf dem Leitrechner
•
Unabhängigkeit vom Hersteller und der Type der Maschinensteuerungssysteme
genannten
Kriterien
komponentenbasierte
untersteichen
die
Leitrechneranwendungen
Zielsetzung
in
der
verschiedensten
Fischer
GmbH
Bereichen
des
Produktionsumfeldes einzusetzen. Neben der effektiveren Anwendungsentwicklung soll
die Verwendung von einheitlichen, jedoch sehr flexibel gestalteten Softwarebausteinen zu
einer gesteigerten Wartbarkeit der einzelnen Anwendungen führen.
3. Beschreibung möglicher Lösungswege
3.
Seite - 8 –
Beschreibung möglicher Lösungswege
Dieser Abschnitt der Diplomarbeit erläutert die getroffenen Technologieentscheidungen
hinsichtlich des Komponentenmodells und der verwendeten Entwicklungsumgebung.
Bezüglich des Datenbanksystems und der zu verwendenden OPC-Client-Komponenten
erfolgten feste Vorgaben durch die Fischer GmbH. Aus diesem Grund werden diese
Punkte nur kurz kommentiert.
3.1
Entwicklungsplattform
Der für die Automatisierungstechnik zuständige Bereich der Fischer GmbH hat bisher zur
Entwicklung von Softwarelösungen vorwiegend die Entwicklungsumgebung Microsoft
Visual Studio 6.0 und die Programmiersprache Microsoft Visual Basic 6.0 verwendet. Als
Basis der komponentenorientierten Softwareentwicklung wurde DCOM eingesetzt. Im
Rahmen
der
Diplomarbeit
soll
die
Leistungsfähigkeit
der
modernen
Entwicklungsplattformen Java 2 Enterprise Edition (J2EE) und Microsoft .NET in
Hinblick auf die Anforderungen der Fischer GmbH kritisch betrachtet werden. Die
Softwarebausteine sollen als erste Referenzentwicklung den Wechsel zu einer neuen
Basistechnologie für die Softwareentwicklungen der Fischer GmbH unterstreichen.
Zur Entscheidungsfindung wurden die Entwicklungsplattformen anhand verschiedener
technischer und kaufmännischer Kriterien verglichen. Die allgemeine Diskussion und
Einzelbewertung der
Punkte Plattformunabhängigkeit,
Entwicklungsumgebung(en),
Programmiersprachen, Datenbankzugriff, OPC Verfügbarkeit, Produktkosten sowie
Schulungskosten leitet zur Produktauswahl über. Die Argumentation der einzelnen
Diskussionspunkte ergibt sich aus den spezifischen Anforderungen der Fischer GmbH.
Plattformunabhängigkeit
Im Desktop- und Automatisierungstechnikbereich setzt die Fischer GmbH auf eine
homogene Microsoft-Umgebung mit Windows-Betriebssystemen in den Versionen 2000
und XP. Zur Anbindung der heterogenen Feldebene, mit Steuerungssystemen
verschiedenster Hersteller, kommen auf OPC basierende Softwareprodukte zum Einsatz.
Da OPC auf den Microsoft Technologien OLE (Object Linking and Embedding) und
DCOM basiert, ist der Einsatz von Windows als Betriebssystem auf den Leitrechnern
3. Beschreibung möglicher Lösungswege
Seite - 9 –
nahezu unumgänglich. Der Gesichtspunkt der Plattformunabhängigkeit spielt somit für die
Fischer GmbH nur eine untergeordnete Rolle.
Objektiv
ist
Java
durch
die
Virtual
Machine
(VM)
Implementierungen
auf
unterschiedlichsten Betriebssystemplattformen der stark an Windows gebundenen .NETTechnologie überlegen. Die oben erwähnten Technologien OLE, DCOM und OPC werden
in Kapitel 4 der Diplomarbeit eingehend behandelt.
Entwicklungsumgebung(en)
Zur
Entwicklung
von
Java-Applikationen
stehen
eine
Vielzahl
von
Entwicklungsumgebungen zur Auswahl. Neben den weit verbreiteten Open-Source
Varianten Eclipse1 und NetBeans2 können auch kommerzielle Produkte wie das Sun Java
Studio3 oder IBMs WebSphere Developer4 zum Einsatz kommen. Die Erweiterbarkeit und
anwenderspezifische Abstimmung der einzelnen Umgebungen wird durch Plugins
ermöglicht.
Die
Entwicklung
grafischer
Benutzeroberflächen
basiert
je
nach
Entwicklungsumgebung auf den unterschiedlichen Java GUI Bibliotheken (Graphical User
Interface) Swing bzw. SWT (Standard Widget Toolkit). Eine Technologieentscheidung für
eine Java-Entwicklungsumgebung ist gemäß den unterschiedlichen Funktionsumfängen
sowie den Kriterien Handhabung und Kosten zu treffen. Für .NET bietet Microsoft mit
Visual Studio .NET 2005 eine integrierte Entwicklungsumgebung zur Erstellung von
Windows- und Webanwendungen. Als Weiterentwicklung von Visual Studio 6.0 ermöglicht
die IDE (Integrated Development Enviroment) eine äußerst komfortable Entwicklung von
.NET basierenden Komponenten und Programmen. Visual Studio .NET 2005 wird von
Microsoft in verschiedenen Editionen vertrieben. Beginnend mit den kostenlosen Express
Editionen der verschiedenen .NET-Programmiersprachen bis hin zum Visual Studio 2005
Team System, welches die teamorientierte Softwareentwicklung unterstützt, kann die
Entwicklungsumgebung entsprechend den Anforderungen eines Unternehmens gewählt
werden. Mit SharpDevelop5 steht neben den kommerziellen Microsoft-Produkten eine
Open-Source-IDE für .NET zur Verfügung. Zur Erstellung grafischer Benutzeroberflächen
1
http://www.eclipse.org
2
http://www.netbeans.org
3
http://www.sun.com
4
http://www.ibm.com
5
http://www.icsharpcode.net
3. Beschreibung möglicher Lösungswege
Seite - 10 –
wird von beiden Produkten einheitlich die Windows.Forms Bibliothek des .NETFrameworks verwendet.
Aus der Betrachtung der Entwicklungsumgebungen geht kein eindeutiger „Sieger“ hervor.
Zusammenfassend kann bemerkt werden, dass sowohl für J2EE als auch für .NET
ausgereifte
und
äußerst
umfangreiche
Umgebungen
zur
Unterstützung
der
Entwicklungsarbeit verfügbar sind.
Programmiersprachen
Die Programmiersprachen beider Plattformen ermöglichen die komponentenbasierte
Softwareentwicklung und sind in vollem Umfang objektorientiert. Die J2EE-Plattform ist
auf die Programmiersprache Java beschränkt. Microsoft bietet im Rahmen von Visual
Studio .NET 2005 ab der Standard Edition die Möglichkeit in den Sprachen C#, C++.NET,
Visual Basic.NET und J#, einem Java Dialekt, zu programmieren. Lediglich die
kostenlosen Express Editionen sind speziell zur Verwendung einer der genannten Sprachen
ausgerichtet.
Für die Fischer GmbH ergeben sich durch die erhöhte Flexibilität von .NET selbst beim
anfänglichen Einsatz einer Express Edition Vorteile in Bezug auf zukünftige
Weiterentwicklungen. Das Kriterium Programmiersprachen entscheidet sich somit zu
Gunsten von Microsoft.
Datenbankzugriff
Mit JDBC (Java Database Connectivity) steht dem Java-Entwickler eine umfangreiche,
universelle Schnittstelle zu Datenbanksystemen verschiedenster Hersteller zur Verfügung.
Über die JDBC API (Application Programming Interface) werden der Verbindungsaufbau,
die Verbindungsverwaltung und das Absetzen von Kommandos an das Datenbanksystem
sowie die Übermittlung von Abfrageergebnissen an die Applikation gesteuert. Als Pendant
bietet das Microsoft .NET-Framework eine mit dem Überbegriff ADO.NET bezeichnete
API. ADO.NET stellt verschiedene data provider für den Zugriff auf einen Großteil der
gängigen Datenbanksysteme bereit. In den Punkt Funktionsumfang und Handhabung kann
sich keine API entscheidend abheben.
3. Beschreibung möglicher Lösungswege
Seite - 11 –
Der Zugriff auf die von der Fischer GmbH eingesetzten Datenbanksysteme Oracle1 und
Microsoft Access ist, bei entsprechender Kenntnis der Klassenbibliotheken, mit beiden
Plattformen in gleichem Maß zufrieden stellend möglich. Wie bereits bei den
Entwicklungsumgebungen kann keine Plattform favorisiert werden.
OPC Verfügbarkeit
Wie bereits bei der Betrachtung der Plattformunabhängigkeit bemerkt wurde, werden zur
Anbindung der Maschinensteuerungssysteme auf OPC basierende Softwareprodukte
verwendet. Die Client/Server Architektur von OPC erfordert die Implementierung von
OPC-Client-Funktionalitäten in den, im Rahmen der Diplomarbeit, zu entwickelnden
Softwarekomponenten. Die Verfügbarkeit von OPC-Client-Toolkits zur einfachen und
effizienten Umsetzung dieser Aufgabenstellung ist für die Fischer GmbH entscheidend.
Der Markt für derartige Client Komponenten ist durch die historische Verflechtung von
OPC mit der Microsoft-Technologie DCOM eindeutig zu Gunsten der .NET-Plattform
ausgerichtet.
Produktkosten
Die
Produktkosten
als
Ganzes
werden
maßgeblich
durch
die
Kosten
der
Entwicklungsumgebung bestimmt. Um den Anforderungen der Fischer GmbH gerecht zu
werden, bestehen bei beiden Plattformen preislich attraktive Möglichkeiten. Java bietet mit
den Open-Source-IDEs solide Entwicklungswerkzeuge. Eine Investition in zusätzliche
Tools ist nicht notwendig. Laufende Kosten fallen nicht an. Mit den Express Editionen von
Visual Studio .NET geht auch Microsoft den Weg kostenlose Entwicklungsumgebungen
zur Verfügung zu stellen. Erst bei Verwendung einer Standard Edition fallen Produkt- und
Lizenzkosten an. Für die Entwicklung der Softwarekomponenten und der darauf
basierenden Leitrechneranwendungen ist der Funktionsumfang der Express Editionen
vollkommen ausreichend. Die Einschränkung hinsichtlich nur einer verfügbaren
Programmiersprache kann von der Fischer GmbH akzeptiert werden.
In Anbetracht der genannten Argumente ergibt sich insgesamt ein Vorteil für die J2EEUmgebungen. Die Investitionssicherheit wurde aufgrund der hohen Marktdurchdringung
beider Technologien als gleichwertig eingestuft.
1
http://www.oracle.com
3. Beschreibung möglicher Lösungswege
Seite - 12 –
Schulungskosten
Wie schon in der Einleitung zu diesem Abschnitt erwähnt wurde sind die
Softwareentwickler der Fischer GmbH mit der Microsoft-Entwicklungsumgebung Visual
Studio 6.0 vertraut. Der Umstieg auf die .NET-Plattform, mit einer sehr ähnlichen IDE,
wird daher tendenziell als einfacher gegenüber dem Wechsel zu J2EE beurteilt. Der
Schulungsaufwand für die J2EE-Plattform ist diesem Grund entscheidend höher
einzuschätzen. Durch die strukturelle Ähnlichkeit der Programmiersprachen Java und C#
kann davon ausgegangen werden, dass ein Java-Entwickler einen Umstieg auf .NET relativ
rasch meistern kann. Bei der Ausschreibung einer Stelle muss daher hinsichtlich der
Qualifikationen keine Einschränkung auf eine bestimmte Entwicklungsplattform in Kauf
genommen werden.
Die .NET-Plattform ist durch die genannten Aspekte als klarer „Sieger“ des Punktes
Schulungskosten zu sehen.
Bewertungsmatrix
Ausgehend von den besprochenen Bewertungskriterien wurde eine Matrix zum Vergleich
der beiden Entwicklungsplattformen erstellt. Die Gewichtung erfolgte gemäß den
Vorgaben der Fischer GmbH. Die Bandbreite für die Gewichtung wurde mit „1“ als „eher
unwichtig“ bis 5 als „sehr wichtig“ festgelegt. Die Plattformen konnten in den einzelnen
Kategorien maximal 5 Punkte erreichen. Zur Ermittlung des Endergebnisses wurden die
Einzelbewertungen mit der entsprechenden Gewichtung multipliziert und aufsummiert.
Kriterium
Gewicht
J2EE
Plattformunabhängigkeit
Entwicklungsumgebung
Programmiersprachen
Datenbankzugriff
OPC Verfügbarkeit
Produktkosten
Schulungskosten
Summe
1
4
4
5
5
3
3
5
4
4
4
3
5
3
J2EE
gewichtet
5
16
16
20
15
15
9
96
.NET
1
4
5
4
5
3
4
.NET
gewichtet
1
16
20
20
25
9
12
103
Tabelle 3.1: Bewertungsmatrix J2EE vs. .NET
Wie in Tabelle 3.1 ersichtlich ist, wurde die .NET-Plattform in der Summe der gewichteten
Kriterien höher als die Java 2 Enterprise Edition bewertet. Auf der Basis dieses Resultats
3. Beschreibung möglicher Lösungswege
Seite - 13 –
wurde die Technologieentscheidung zu Gunsten von Microsoft .NET getroffen. Die
Grundlagen der .NET-Technologie werden in Kapitel 4 der Diplomarbeit besprochen.
3.2
Entwicklungsumgebung
Nachdem die Grundsatzentscheidung für eine .NET basierende Komponentenentwicklung
gefallen war wurde von Seiten der Fischer GmbH C# als neue StandardProgrammiersprache definiert. Die verschiedenen Editionen von Visual Studio .NET
wurden
in
Abschnitt
3.1
im
Rahmen
der
Bewertung
der
verfügbaren
Entwicklungsumgebungen evaluiert. Mit Visual C# Express 2005 wurde die kostenlose
Basisvariante gewählt. Lediglich zur Erstellung der UML-Klassendiagramme in Abschnitt
5 wurde eine 90 Tage Testversion der Professional Edition verwendet.
3.3
Datenbanksystem
Im Rahmen der Systemanforderungen in Abschnitt 2 der Diplomarbeit wird die lokale
Speicherung der Produktionsdaten am Leitrechner gefordert. Die Notwendigkeit eines
Datenbanksystems anstatt einer auf Dateien basierenden Speicherung ergibt sich anhand
der folgenden Kriterien laut [Balz01].
•
Mehrere Benutzer und/oder mehrere Anwendungen müssen parallel mit dem
Datenbestand arbeiten (mehrfachbenutzte Datenbank).
Dieses Kriterium wird durch den parallelen Zugriff der verschiedenen Komponenten auf
den Datenbestand sowie der Notwendigkeit des Entwicklerzugriffs auf die Daten bei
laufender Anwendung erfüllt.
•
Die Datenstrukturen können während der Nutzungsphase aufgrund geänderter
Anforderungen begrenzt angepasst werden (Hinzufügen neuer Spalten zu
vorhandenen Tabellen)
Zusätzliche Produktionsparameter für Maschinen müssen rasch in das bestehende System
eingebunden werden können. Das Kriterium wird somit hinreichend erfüllt.
Der Einsatz von Microsoft Access wurde durch die Fischer GmbH vorgegeben. Die
Implementierung der Komponenten ist jedoch nicht an das vorgegebene Datenbanksystem
gebunden.
3. Beschreibung möglicher Lösungswege
3.4
Seite - 14 –
OPC-Client-Komponenten
Die Auswahl der OPC-Client-Komponenten für die .NET-Plattform wurde durch die
Fischer GmbH getroffen. Die OPC ClientX .NET Komponenten der Firma Metadynamics1
stellen ein .NET kompatibles Interface zum Zugriff auf OPC-Server gemäß dem OPCData-Access-Standard zur Verfügung. In Kapitel 4 werden die Basistechnologien OLE,
COM und DCOM sowie OPC selbst näher erläutert.
1
http://www.metadynamics.com
4. Theoretischer Hintergrund
4.
Seite - 15 –
Theoretischer Hintergrund
Dieses Kapitel vermittelt einen Überblick über die für die Diplomarbeit relevanten
technischen Grundlagen. Zu Beginn werden Softwarekomponenten und die auf MicrosoftSystemen eingesetzten Basistechnologien DCOM sowie Microsoft .NET erläutert. Die
Grundlagen von DCOM sind speziell im Hinblick auf den Einsatz von Openess,
Productivity and Collaboration relevant. Anschließend werden die Grundlagen von
Datenbanksystemen, welche zur Verwaltung der Produktionsdaten verwendet werden,
besprochen. Nachfolgend wird auf den Begriff „Vertikale Integration“ eingegangen. In
diesem Rahmen werden die IT Infrastruktur der Fischer GmbH sowie die Verwaltung der
Produktionsdaten im zentralen Oracle-Datenbanksystem beschrieben. Zur Realisierung
von Maschinensteuerungen gelten speicherprogrammierbare Steuerungen als Standard.
Der theoretische Hintergrund wird mit einem Einblick in SPS-Systeme sowie dem
Industrie-Standard zur herstellerunabhängigen Kommunikation mit diesen, Openess,
Productivity and Collaboration abgeschlossen.
4.1
Softwarekomponenten
Vorgefertigte Softwarekomponenten dienen in der komponentenbasierten SoftwareEntwicklung
als
Bausteine
für
eine
effiziente
Anwendungsentwicklung.
Die
komponentenbasierte Entwicklung von Softwareanwendungen zeichnet sich, bei häufiger
Verwendung vorhandener und entsprechend ausführlich getesteter Softwarebausteine,
durch erhöhte Flexibilität bei geringeren Kosten für Entwicklung und Wartung aus. Die
Halbfabrikate werden vom Anwendungshersteller häufig von Drittanbietern zugekauft. Die
Komponentenhersteller sind spezialisiert auf die Herstellung von Softwarebausteinen mit
Funktionalitäten, welche von vielen Anwendungsherstellern in den Standardbibliotheken
der
Entwicklungsumgebungen
vermisst
werden.
Als
Beispiele
können
hier
Oberflächensteuerelemente wie spezielle Eingabe- oder Ausgabefelder aber auch
erweiterte Datensteuerelemente wie Datentabellen oder Datenanalysekomponenten
genannt werden.
[Balz01] definiert eine Softwarekomponente bzw. ein Halbfabrikat sehr abstrakt als
abgeschlossenen, binären Software-Baustein, der eine anwendungsorientierte, semantisch
zusammengehörende Funktionalität besitzt, die nach außen über Schnittstellen zur
4. Theoretischer Hintergrund
Seite - 16 –
Verfügung gestellt wird. Beim Entwurf solcher Halbfabrikate wird Wert auf eine maximale
Wiederverwendbarkeit gelegt.
Die gewünschten Funktionalitäten werden also in einem eigenständigen Baustein
gekapselt. Durch den binären Charakter des Bausteins kann eine Sprachunabhängigkeit
erreicht
werden.
Sprachunabhängigkeit
bedeutet,
dass
die
Softwarekomponente
unabhängig von der ursprünglichen Entwicklungssprache weitergegeben und verwendet
werden kann. Laut [Balz01] sind neben der Sprachunabhängigkeit auch die
Plattformunabhängigkeit und die Verteilbarkeit wünschenswerte Voraussetzungen um eine
Anwendungsentwicklung mit Halbfabrikaten zu ermöglichen.
Zur Realisierung dieser Voraussetzungen werden Komponentenmodelle eingesetzt, welche
das Design und die Zusammenarbeit von Software-Bausteinen regeln. Laut Definition
stellen die Software-Bausteine ihre Funktionalität über Schnittstellen zur Verfügung. Je
nach Komponenten-Modell müssen die Bausteine spezielle Schnittstellen implementieren,
um als Komponenten innerhalb des Modells verwendet werden zu können. Die
Schnittstellen oder auch Interfaces stellen eine Art „Vertrag“ über die Funktionalität und
das Verhalten der Komponente nach außen hin dar. Komponenten können somit
gegeneinander ausgetauscht werden, sofern die gleichen Schnittstellen implementiert
werden.
Die
oben
erwähnte
Plattformunabhängigkeit
erfordert
eine
Portierung
des
Komponentenmodells auf verschiedene Betriebssysteme. So wurde das von Microsoft
entwickelte Component Object Model (COM) für HP-UX (Hewlett Packard Unix)1 bzw.
für IBM-Mainframes2 verfügbar gemacht. Eine ernstzunehmende Implementierung für die
Nachfolgetechnologie Microsoft .NET wird durch das MONO-Projekt3 von Novell4 auch
auf Unix, Linux und MacOS entwickelt. Die Verteilbarkeit der Komponenten in einem
heterogenen Netzwerk wurde bei COM durch die Weiterentwicklung Distributed
Component Object Model ermöglicht. .NET bietet für die Verteilung Strategien wie
beispielsweise .NET-Remoting an.
1
http://www.hp.com/go/hpux
2
http://www.ibm.com/systems/z/
3
http://www.mono-project.com
4
http://www.novell.com
4. Theoretischer Hintergrund
4.1.1
Seite - 17 –
Distributed Component Object Model
DCOM ist das Ergebnis aus zwei Entwicklungswegen, welche von Microsoft im Jahr 1996
zusammengeführt
wurden.
Abbildung
4.1
zeigt
die
Meilensteine
der
beiden
Entwicklungswege in Anlehnung an [Iwan05].
Abbildung 4.1: Entwicklungswege von DCOM
Der linke Entwicklungsweg, den Microsoft im Jahr 1987 mit dem Windows-Clipboard und
DDE (Dynamic Data Exchange) begründete, beruht auf dem Grundgedanken
Informationen aus verschiedenen Anwendungen zusammenzuführen. Das WindowsClipboard ermöglichte ein Kopieren von Daten einer Anwendung in eine andere. Der
Datentransfer war allerdings einmalig und statisch, das heißt es erfolgte keine automatische
Aktualisierung der Daten bei Veränderung in der Quellanwendung. DDE löste diese
Unzulänglichkeit durch die Kommunikation der beiden Anwendungen. Eine ClientAnwendung
kommuniziert
mit
der
Server-Anwendung
über
ein
einfaches
nachrichtenbasiertes Protokoll. Der Datenaustausch ist in beide Richtungen möglich.
Typischer Anwendungsbereich für DDE ist die Verwendung von zeitlich veränderlichen
Daten aus einer anderen Anwendung. Der Nachteil ist, dass beide Anwendungen aktiv sein
müssen.
Im Jahr 1992 wurde OLE 1 vorgestellt. Object Linking and Embedding ermöglicht das
Verbinden und Einbetten von Objekten, welche mit verschiedensten Anwendungen erzeugt
wurden, in einem zentralen Verbunddokument. Bestes Beispiel hierfür ist sicherlich das
Word-Dokument, in dem eine Excel-Tabelle angezeigt wird. Beim Doppelklicken der
Excel-Tabelle wird automatisch die mit dem Objekt verbundene Anwendung (Microsoft
Excel) gestartet. OLE 1 war somit ein eingeschränktes Komponentenmodell, welches
4. Theoretischer Hintergrund
Seite - 18 –
speziell auf Verbunddokumente zugeschnitten war. Das Verbunddokument stellte den
Container für verschiedene Teildokumente aus anderen Anwendungen dar.
Die logische Erweiterung von OLE 1 war OLE 2, welches erstmals in [Micr94a] und
[Micr94b] publiziert wurde. OLE 2 wurde wenig später in Component Object Model
umbenannt. COM stellte die Verallgemeinerung von OLE 1 auf die Begriffswelt der
Software-Komponenten dar. Der Container wurde nun selbst als Softwarekomponente
betrachtet, der wiederum andere Komponenten einbetten und verlinken konnte. Mit OLE
wurde zu dieser Zeit alles bezeichnet, was auf den COM-Konzepten aufbaute. Im Jahr 1996
wurden mit der Begriffsdefinition ActiveX alle Konzepte von OLE subsumiert und um
zusätzliche Konzepte für so genannte ActiveX-Steuerelemente erweitert. OLE wurde
wieder ausschließlich im Zusammenhang mit Verbunddokumenten verwendet [Balz01].
Die Erweiterung von COM um die Möglichkeit auf COM-Komponeten anderer Systeme
zuzugreifen resultierte im Distributed Component Object Model. Die Basistechnologien für
den Fernzugriff wurden über einen zweiten Entwicklungsweg erarbeitet. Die OSF (Open
Software Foundation) entwickelte in den 80er Jahren einige unter der Bezeichnung DCE
(Distributed Computing Enviroment) zusammengefasste Spezifikationen mit dem Ziel,
verteilte Verarbeitung
in
heterogenen
Umgebungen
zu
verwirklichen.
In den
Spezifikationen wurden Kommunikationsmechanismen zwischen Anwendungen auf
verschiedenen Systemen beschrieben. Im Jahr 1992 wurde OSF DCE RPC (Remote
Procedure Call) als Ergebnis vorgestellt. Microsoft erweiterte für die Entwicklung von
DCOM die Spezifikation um die notwendige Objektorientierung. Es wird daher im
Zusammenhang mit DCOM von ORPC (Object Remote Procedure Call) gesprochen
[Iwan05].
COM und DCOM sind sehr umfangreiche und teilweise auch sehr komplexe Technologien.
Wie [Loos01] bemerkt, setzte sich COM daher auch nicht unmittelbar, sondern erst durch
die tiefe Verankerung in den Windows-Betriebssystemen und die Erweiterung zur verteilten
Verarbeitung (DCOM) endgültig durch.
4. Theoretischer Hintergrund
Seite - 19 –
COM-Komponenten
Der Begriff COM-Komponente bezeichnet einen binären Software-Baustein, welcher eine
oder mehrere Schnittstellen implementieren kann [Balz01].
Abbildung 4.2: Darstellungsarten einer COM Komponente
Die linke Darstellung in Abbildung 4.2 zeigt die in der Literatur übliche Darstellung einer
COM-Komponente. Rechts wurde die UML-Komponentennotation verwendet.
Jede COM-Komponente ist durch einen GUID (Global Unique Identifier) weltweit
eindeutig gekennzeichnet. Die GUID einer Komponente wird als CLSID (Class Identifier)
bezeichnet und ist in der Windows-Registry gemeinsam mit dem Namen der Komponente
unter HKEY_CLASSES_ROOT/CLSID eingetragen. Abbildung 4.3 zeigt den CLSID-Eintrag
einer COM-Komponente.
Abbildung 4.3: CLSID-Eintrag in der Windows-Registry
4. Theoretischer Hintergrund
Seite - 20 –
COM-Server
COM arbeitet nach dem Client/Server-Prinzip. Ein COM-Server erzeugt Objekte aus
COM-Komponenten und stellt diese dem Client zur Verfügung. Client ist jedes Programm,
welches die Funktionalitäten der COM-Objekte nutzt. Ein COM-Server kann auf drei
verschiedene Arten implementiert werden:
In-process Server
Greift ein Client über ein COM-Interface auf eine COM-Komponente in einer DLL
(Dynamic Link Library) zu, so wird die DLL und somit der entsprechende COM-Server
direkt in den Prozessraum des Clients geladen. Die In-process Variante ist sehr schnell, da
zwischen Client und Server nicht über Prozessgrenzen hinweg kommuniziert werden muss.
Dynamic Link Libraries haben unter Windows meist die Dateiendungen .dll oder .ocx. Der
Pfad
zu
dieser
Datei
ist
in
HKEY_CLASSES_ROOT/CLSID/{….}/InprocServer32
der
Windows-Registry
unter
eingetragen.
Local Server
Werden COM-Objekte durch eine eigene Anwendung (.exe) zur Verfügung gestellt, spricht
man von einem Local Server. Bei dieser Variante verfügt sowohl der Client als auch der
Server über einen eigenständigen Prozessraum. Die Kommunikation zwischen Client und
Server erfolgt über ein RPC-Protokoll mit verminderter Funktionalität. Der Zugriff auf die
COM-Objekte wird durch das RPC-Protokoll jedoch verlangsamt. Vorteil gegenüber der
In-process Variante ist der geringere Speicherbedarf bei der Bedienung vieler Clients, da
der Server nur einmal gestartet werden muss. Der Pfad zur Anwendung ist in der WindowsRegistry unter HKEY_CLASSES_ROOT/CLSID/{….}/LocalServer32 eingetragen.
Remote Server
Greift der Client über seine eigenen Systemgrenzen hinweg auf den Server zu, kommt die
volle Funktionalität von DCOM zum Einsatz. Die Geschwindigkeit der Zugriffe liegt unter
jener des Local Servers, da zum Fernzugriff über ein Netwerk ein erweiterter
Protokollstack sowie ein vollständig implementiertes RPC-Protokoll verwendet wird.
4. Theoretischer Hintergrund
Seite - 21 –
Bei den Varianten Local Server und Remote Server muss über Prozessgrenzen hinweg
zwischen Client und Server kommuniziert werden. Dies ist auf direktem Weg nicht
möglich. Die Kommunikation erfolgt daher über Stellvertreter (proxies) und Stummel
(stubs). Der Stellvertreter vertritt die Komponente im Adressraum des Clients. Im
Adressraum des Servers stellt der Stummel die Verbindung zur eigentlichen Komponente
her. Für die Erzeugung von Stellvertreter und Stummel muss die Komponente und deren
Schnittstellen mit der IDL (Interface Definition Language) beschrieben werden. Der
Microsoft-IDL-Compiler
(MIDL-Compiler)
erzeugt
aus
der
IDL-Beschreibung
Stellvertreter und Stummel [Balz01].
COM-Interfaces
Wie in Abbildung 4.2 ersichtlich implementiert die COM-Komponente mehrere
Schnittstellen. Der Namenskonvention entsprechend wird dem Interfacenamen ein „I“
vorangestellt. Eine Sonderstellung wird dem Interface IUnknown einberaumt. Alle
implementierten Schnittstellen sind zwingend von IUnknown abzuleiten.
Abbildung 4.4: Schnittstelle IUnknown
Aus der UML-Darstellung von IUnknown in Abbildung 4.4 ist ersichtlich, dass die
Methoden QueryInterface, Release und AddRef zur Verfügung gestellt werden. Durch
die Ableitung aller Schnittstellen von IUnknown müssen auch alle anderen Schnittstellen
diese Methoden zur Verfügung stellen.
Mit der Methode QueryInterface kann die Unterstützung eines bestimmten Interfaces an
einem COM-Objekt abgefragt werden. Durch die Verfügbarkeit der Methode an jedem
Interface kann somit am Interface ISchnittstelle1 die Unterstützung der Schnittstelle
ISchnittstelle2
abgefragt werden. Die Methode liefert bei Erfolg einen Zeiger auf
ISchnittstelle2
zurück. Falls die Komponente die Schnittstelle nicht unterstützt, wird
ein Fehlerstatus retourniert. Die eindeutige Identifizierung einer Schnittstelle erfolgt jedoch
4. Theoretischer Hintergrund
Seite - 22 –
nicht über den Namen (z.B. „ISchnittstelle2“) sondern über eine GUID. Die weltweit
eindeutige GUID wird als Interface Identifier (IID) bezeichnet und ist in der WindowsRegistry zusammen mit dem Schnittstellennamen unter HKEY_CLASSES_ROOT/Interface
abgelegt. Abbildung 4.5 zeigt den IID-Eintrag der Schnittstelle IUnknown.
Abbildung 4.5: IID-Eintrag von IUnknown in der Windows-Registry
Die Methoden AddRef und Release werden verwendet um den Lebenszyklus von COMObjekten zu kontrollieren. Ein Objekt bleibt aktiv, solange ein Client eine Referenz auf das
Objekt besitzt. Mit der Methode AddRef wird der Referenzzähler des Objektes erhöht,
wenn ein Client eine Referenz auf die Schnittstelle anfordert. Mit der Methode Release
signalisiert der Client, dass die Referenz auf das Objekt nicht mehr benötigt wird und der
Referenzzähler wird dekrementiert. Erreicht der Referenzzähler den Wert Null, wird das
COM-Objekt zerstört.
Objekterzeugung
Um die Funktionalitäten einer COM-Komponente verwenden zu können, muss zuerst ein
COM-Objekt
erzeugt
CoCreateInstance
werden.
Dies
geschieht
durch
Aufruf
der
Methode
aus der COM-Bibliothek. CoCreateInstance wird die CLSID der
gewünschten COM-Komponente und die IID der gewünschten Schnittstelle übergeben. Der
Aufruf bewirkt, dass in der Windows-Registry über die CLSID der entsprechende COMServer lokalisiert und geladen wird. Anschließend wird ein Zeiger auf das gewünschte
Interface zurückgegeben. Mit diesem Zeiger ist es dem Client nun möglich über die
Methode QueryInterface eine Referenz auf jedes der implementierten Interfaces zu holen
und dessen Methoden zu nutzen. Für die Erzeugung beliebig vieler Objekte einer COMKomponente wird im Hintergrund ein ClassFactory Object erzeugt, welches die
eigentliche Instanzierung des COM-Objekts übernimmt.
4. Theoretischer Hintergrund
Seite - 23 –
DLL-Hell
Die zentrale Verwaltung der CLSIDs und der IIDs in der Windows-Registry sowie die
Verwendung von gemeinsam genutzten DLLs in verschiedensten Anwendungen hat einige
unangenehme Nebeneffekte zur Folge. Die Probleme, die sich durch die Verwaltung der
DLLs ergeben, werden mit dem Überbegriff DLL-Hell bzw. DLL-Hölle bezeichnet.
Beispiel 1
Anwendung „A Version 1.0“ wird am System installiert und registriert die DLL „shared.dll
Version 1.0“. Nun wird Anwendung „B Version 1.0“ installiert. Die DLL „shared.dll
Version 1.0“ wird durch die DLL „shared.dll Version 2.0“ überschrieben. Die Version 2.0
wurde um zusätzliche Schnittstellen erweitert, welche von „B Version 1.0“ verwendet
werden. Es sind somit noch beide Anwendungen lauffähig. Eine Neuinstallation der
Anwendung „A Version 1.0“ führt nun zu Problemen. Die DLL „shared.dll Version 2.0“
wird wieder mit Version 1.0 überschrieben. Die Anwendung „B Version 1.0“ ist dadurch
nicht mehr lauffähig.
Beispiel 2
Da Anwendung „B Version 1.0“ nicht mehr lauffähig ist wird sie deinstalliert. Bei der
Deinstallation wird auch die gemeinsam verwendete DLL „shared.dll Version 1.0“
gelöscht. Nun ist auch Anwendung „A Version 1.0“ nicht mehr lauffähig.
Beispiel 3
Der Benutzer hat aus Beispiel B „gelernt“ und verneint bei der Deinstallation von
Programmen generell das Löschen von eventuell gemeinsam genützten Dateien. Im Laufe
der Zeit wird dadurch die Windows-Registry sehr viele, eigentlich nicht mehr notwendige,
Einträge beinhalten. Dies wirkt sich negativ auf die Systemleistung aus, da die Registry
zum Beispiel bei der Objekterzeugung von COM-Komponenten nach der CLSID
durchsucht werden muss.
Bei der Entwicklung des Microsoft .NET-Frameworks wurden diese Aspekte von
gemeinsam genutzten Bibliotheken von Beginn an berücksichtigt.
4. Theoretischer Hintergrund
4.1.2
Seite - 24 –
Microsoft .NET-Framework
Das .NET-Framework stellt die Weiterentwicklung der COM/DCOM-Technologien von
Microsoft dar. Ursprünglich wurde laut [Schw05] COM Version 3.0 als Bezeichnung
verwendet. Durch die gravierenden Änderungen zu den COM-Technologien verwendet
Microsoft seit dem Jahr 2000 die Bezeichnung .NET-Framework. .NET ist auch nicht als
reines Komponentenmodell sondern als komplette Softwareentwicklungsplattform mit
Unterstützung von Objekt-, Komponenten- und Serviceorientierung zu verstehen. Die
Version 1.0 des Frameworks wurde im Jänner 2002 vorgestellt. Bereits im April des
folgenden Jahres wurden mit der Version 1.1 einige Erweiterungen und Fehlerbehebungen
präsentiert. Seither arbeitete Microsoft an der Nachfolgeversion. Im November 2005 wurde
im Rahmen des in Wien veranstalteten „Microsoft Launch Event“ die Version 2.0 des
.NET-Frameworks und die Entwicklungsumgebung Visual Studio .NET 2005 der
österreichischen Entwicklergemeinde vorgestellt. Die Entwicklungsumgebungen zur
Version 1.0 und 1.1 des Frameworks trugen die Bezeichnungen Visual Studio .NET 2002
und 2003.
.NET Übersicht
Durch die Verwendung einer Laufzeitumgebung, welche als CLR (Common Language
Runtime) bezeichnet wird, und der Zwischensprache MSIL (Microsoft Intermediate
Language) wird eine Plattformunabhängigkeit erreicht. Dieses Konzept ist jenem von Java
und dessen JRE (Java Runtime Enviroment) sehr ähnlich. Von Microsoft selbst wird das
.NET-Framework allerdings nur für Windows-Systeme mit 32 oder 64 Bit angeboten. Es
existiert jedoch mit dem bereits in der Einleitung zum Kapitel erwähnten MONO-Projekt
von Novell eine Implementierung der .NET-Runtime für Unix, Linux und MacOS Systeme.
Laut [Schw05] wird mittels der MSIL und dem sprachunabhängigen Typkonzept CTS
(Common Type System) und dessen Spezialisierung CLS (Common Language
Specification) die Sprachunabhängigkeit der .NET-Technologie erreicht. So sind neben den
Microsoft Programmiersprachen C#, C++.NET, Visual Basic.NET und J# bereits Sprachen
wie beispielsweise Fortran von Drittanbietern an das .NET-Framework angepasst worden.
Mit der .NET-Framework-Class-Library (FCL) werden leistungsfähige StandardKlassenbibliotheken
zur
Verfügung
gestellt.
Zur
einfachen
Gestaltung
von
Benutzeroberflächen können sowohl die Windows Forms Steuerelemente für Windows-
4. Theoretischer Hintergrund
Seite - 25 –
Anwendungen als auch die Web Forms Steuerelemente zur Erstellung von WebAnwendungen genutzt werden. Datenzugriffe erfolgen über die Klassen der ADO.NET
Library. Als Technologien für Fernzugriffe werden .NET-Remoting und XML-Webservices
(Extensible Markup Language) angeboten.
Microsoft Intermediate Language (MSIL)
Beim Kompilieren eines .NET-Programms wird kein prozessorspezifischer Maschinencode
sondern ein von der Zielplattform unabhängiger Zwischencode erzeugt. Der Zwischencode
kann mit dem Tool „ildasm.exe“, welches dem .NET-Framework-SDK (Self Development
Kit) beiliegt, betrachtet werden. Mittels einer „HelloWorld“ werden in Listing 4.1 und
Listing 4.2 die Unterschiede zwischen C#-Code und MSIL-Code demonstriert.
using System;
namespace HelloWorld
{
class Program
{
static void Main(string[] args)
{
Console.WriteLine("Hello World");
}
}
}
Listing 4.1: Beispielcode “Hello World” in C#
method private hidebysig static void Main(string[] args) cil managed
{
.entrypoint
// Code size
11 (0xb)
.maxstack 8
IL_0000: ldstr "Hello World"
IL_0005: call void [mscorlib]System.Console::WriteLine(string)
IL_000a: ret
} // end of method Program::Main
Listing 4.2: Beispielcode “Hello World” in MSIL
4. Theoretischer Hintergrund
Seite - 26 –
Just in Time (JIT) Compiler
Die
CLR
als
Laufzeitumgebung
für
.NET-Anwendungen
übernimmt
die
Speicherverwaltung, Sicherheitsfunktionen sowie das Management des Zugriffs auf
Betriebssystemfunktionen und der Hardware. Auch die Umwandlung des MSIL-Codes in
einen prozessorspezifischen Maschinencode (Native Code) erfolgt erst zur Laufzeit. Der
Just-in-Time (JIT) Compiler, als Teil der Common Language Runtime übernimmt bei der
ersten Verwendung eines Codesegments (also Just-in-Time) diese Aufgabe. Negative
Auswirkungen auf die Performance der Anwendungen sind laut [Löwy05] in der Regel
nicht zu erwarten, weil der JIT-Compiler den erzeugten Maschinencode speziell auf den
verwendeten Prozessor optimieren kann. Im Gegensatz dazu kann eine bereits in
Maschinencode ausgelieferte Anwendung nur den kleinsten gemeinsamen Nenner der
Funktionalitäten aller zu unterstützenden Prozessoren verwenden. Wird die Verwendung
des JIT-Compilers nicht gewünscht, kann mit dem Tool „ngen.exe“, welches ebenfalls dem
.NET-Framework-SDK beiliegt, aus der MSIL direkt Native Code generiert werden.
Softwarekomponenten im .NET-Framework
Für den Begriff .NET-Softwarekomponente existieren leider mehrere widersprüchliche
Definitionen. Während [Löwy05] jede .NET-Klasse als Komponente bezeichnet, wird in
[Schw05]
auf
die
unterschiedlichen
Interpretationen
innerhalb
der
Microsoft
Dokumentation hingewiesen. So verwendet Microsoft in [Micr06], Absatz 1 folgende
Definition:
”While the term component has many meanings, In the .NET Framework a
component is a class that implements the System.ComponentModel.IComponent
interface or one that derives directly or indirectly from a class that implements this
interface.”
In [Prat01] hingegen wird eine .NET-Komponente mit einem Assembly gleichgesetzt.
Assemblies
Ein Assembly ist die physikalische Weitergabeeinheit für Anwendungen (Application
Assembly) oder Libraries (Library Assembly). Die Gleichsetzung einer Komponente mit
einem Assembly ist somit nachzuvollziehen, da ein Assembly die Einheit der Weitergabe
und Wiederverwendung darstellt. Nun kann ein Assembly jedoch verschiedenste Klassen
4. Theoretischer Hintergrund
Seite - 27 –
beinhalten, die sowohl intern im Assembly als auch extern verwendet werden können. Die
Erweiterung des Komponentenbegriffs auf einzelne Klassen ist somit ebenfalls sinnvoll.
Die Einschränkung auf Klassen, die das Interface IComponent implementieren ist jedoch
nicht
nachvollziehbar
[Schw05].
In
weiterer
Folge
wird
der
erweiterte
Komponentenbegriff aus [Löwy05] verwendet.
Abbildung 4.6: Assemblies als Weitergabeeinheit [Löwy05]
Wie aus Abbildung 4.6 ersichtlich ist, existieren verschiedene Ausprägungen von
Assemblies. Während Assembly A und C sogenannte Single Module Assemblies (SMA)
darstellen, ist Assembly B ein Multi Module Assembly (MMA). Ein MMA kann mehrere
eigenständige DLLs beinhalten, stellt sich jedoch dem Benutzer gegenüber als einzelne
DLL dar. MMAs können nur mit Kommandozeilentools aus dem .NET-SDK erstellt werden
und haben somit nur eine untergeordnete Bedeutung.
Abbildung 4.7: Client und Server Assemblies [Löwy05]
4. Theoretischer Hintergrund
Seite - 28 –
Abbildung 4.7 zeigt den typischen Aufbau einer komponentenbasierten Anwendung. Das
ausführbare Programm im Application Assembly nutzt Funktionen aus verschiedenen
Library Assemblies. Das Application Assembly ist somit ein Client der Library Assemblies
und aus diesem Grund in Abbildung 4.7 mit Client Assembly bezeichnet. Die Methoden
und Attribute der Komponente A können innerhalb des Application Assembly direkt
angesprochen werden. Zur Nutzung der Komponenten in den Library Assemblies muss
eine Referenz auf das Assembly im Application Assembly gesetzt werden. Der Umweg über
die Windows-Registry wie bei COM ist nicht notwendig. Seit Visual Studio 2005 ist es
.NET-Entwicklern möglich auch Application Assemblies zu referenzieren.
Damit ein Client Assembly durch einfaches Referenzieren die Typen und Methoden eines
anderen
Assemblies
nutzen
kann
muss
jedes
Assembly
die
Möglichkeit
der
Selbstbeschreibung besitzen. Zu diesem Zweck werden beim Kompilieren durch den
MSIL-Compiler Metadaten sowie ein Manifest zusätzlich zum MSIL-Code im Assembly
hinterlegt. In den Metadaten werden die verfügbaren Typen und Methoden des Assemblies
beschrieben. Das Manifest hingegen beschreibt den Inhalt eines Assemblies. Neben Name,
Version und Herstellerinformationen enthält das Manifest eine Auflistung der Typen,
Ressourcen, Module und wiederum referenzierten Assemblies.
Abbildung 4.8: Verschiedene Assembly Kompositionen [Löwy05]
Wie aus Abbildung 4.8 hervorgeht können Assemblies verschieden aufgebaut sein. Die
linke Darstellung ist ein Standard Library Assembly mit MSIL-Code, dem Manifest und
den Metadaten. Im Application Assembly in der Mitte sind zusätzlich Ressourcen wie zum
Beispiel Bilder oder Texte eingebettet. Das Multi Module Assembly rechts besteht aus drei
4. Theoretischer Hintergrund
Seite - 29 –
DLLs, wobei letztere eine reine Resourcen-DLL darstellt. Die beiden andern DLLs mit
MSIL-Code besitzen eigene Metadaten. Beim Erstellen des MMA wurden die Manifeste der
verschiedenen DLLs in ein einziges Manifest zusammengefasst. Laut [Löwy05] ist es auch
durchaus üblich für eine erleichterte Internationalisierung von Anwendungen so genannte
Satelliten-Assemblies zu erzeugen, die nur Ressourcen beinhalten.
Private und Shared Assemblies
Private Assemblies dienen zur Verwendung in einer Anwendung und werden deshalb auch
im Anwendungsverzeichnis abgelegt. Ein Überschreiben durch andere Anwendungen wird
dadurch kategorisch ausgeschlossen. Für die gemeinsame Verwendung von Assemblies in
mehreren Applikationen bietet das .NET-Framework die Möglichkeit an, Shared
Assemblies dem Global Assembly Cache (GAC) hinzuzufügen. Der GAC verfügt über
Mechanismen, die es erlauben verschiedene Versionen eines Assemblies gleichzeitig zu
verwalten. Die beiden genannten Strategien sind ein entscheidender Schritt der DLL-Hell
ein Ende zu setzen.
4. Theoretischer Hintergrund
4.2
Seite - 30 –
Datenbanksysteme
Datenbanksysteme (DBS) sorgen laut [Balz01] für die dauerhafte, zuverlässige und
unabhängige Verwaltung sowie für die komfortable, flexible und geschützte Verwendung
von großen, integrierten und mehrfachbenutzten Datenbanken. Die Datenbestände der
Datenbanken werden durch ein Datenbank-Managementsystem (DBMS) verwaltet, welches
auch die Schnittstelle für Programm- bzw. Benutzerinteraktionen zu den Daten bildet. Das
DBMS koordiniert die Zugriffe und generiert die Rückmeldungen auf die Abfragen der
Benutzer. Die Informationen über den Aufbau und die Strukturierung der Daten in den
Datenbanken werden vom DBMS im Data Dictionary (DD) abgelegt. Ein DBS ist somit
die Gesamtheit aus den Datenbanken, dem Data Dictionary und dem Datenbank
Managementsystem [Balz01]. Abbildung 4.9 stellt die genannten Zusammenhänge in
Anlehnung an [Balz01] anschaulich dar.
Abbildung 4.9: Datenbanksystem
Datenbanksysteme werden nach ihrem zugrunde liegenden Datenbankmodell kategorisiert.
Neben den dominierenden relationalen DBS (RDBS) [Kemp01] finden objektorientierte
(ODBS) bzw. Mischformen wie objektrelationale DBS (ORDBS) Anwendung. Im
Weiteren werden die für die Diplomarbeit relevanten RDBS näher betrachtet.
Bei relationalen Datenbanksystemen werden die Daten in Form von Zeilen und Spalten in
Tabellenform gespeichert. Beziehungen zwischen verschiedenen Tabellen ergeben sich aus
bestimmten Spaltenwerten. Abbildung 4.10 zeigt anhand eines Beispiels aus der
4. Theoretischer Hintergrund
Seite - 31 –
Konfigurationsdatenbank der Softwarekomponenten die Beziehung zwischen zwei
Tabellen mittels eines Entity-Relationship-Modells.
Abbildung 4.10: ER-Modell einer Tabellenbeziehung
Das Attribut MachineId stellt den so genannten Primärschlüssel (Primary Key, PK) der
Tabelle Config_OpcConnections dar. Der PK identifiziert jede Zeile in der Tabelle
eindeutig. Analog hierzu bildet das Feld GroupId den Primärschlüssel der Tabelle
Config_OpcGroups.
Die Beziehung der beiden Tabellen wird durch den Fremdschlüssel
(Foreign Key, FK) MachineId in der Tabelle Config_OpcGroups hergestellt. Der
Fremdschlüssel ist im Gegensatz zum Primärschlüssel nicht eindeutig. Die Beziehung
kann daher in Worten wie folgt beschrieben werden: „Eine OPC-Connection hat keine,
eine oder mehrere OPC-Gruppen“. Umgekehrt gilt: „Eine OPC-Gruppe gehört zu genau
einer OPC-Connection“. Die Mengenangaben „keine, eine oder mehrere“ bzw. „genau
eine“ ergeben sich aus der Krähenfussdarstellung der Tabellenbeziehung. Eine Einführung
in die ER-Modellierung ist in [Balz01] zu finden.
Zur Definition der Tabellen sowie zur Manipulation der Datenbestände hat sich SQL
(Structured Query Language) als Datendefinitionssprache (Data Definition Language,
DDL) und Datenmanipulationssprache (Data Manipulation Language, DML) durchgesetzt
[Balz01]. Die Unterstützung von SQL ist heute der Standard in nahezu jedem
Datenbankmanagementsystem.
4. Theoretischer Hintergrund
Seite - 32 –
Zugriff auf Datenbanksysteme mit .NET
Den Anwendungsentwicklern stehen innerhalb eines Entwicklungssystems spezielle
Standard-Libraries für den Datenbank(system)zugriff zur Verfügung. Im Microsoft .NETFramework werden diese Klassen mit dem Überbegriff ADO.NET bezeichnet. ADO.NET
stellt verschiedene data provider für den Zugriff auf Standard-Datenbanksysteme bereit.
Abbildung 4.11: Data provider in .NET [Hami03]
Wie in Abbildung 4.11 erkennbar ist, existieren spezielle Provider für den Microsofteigenen SQL-Server sowie für Oracle. Andere Datenbanksysteme, wie zum Beispiel
Microsoft Access Datenquellen, können über die Standardschnittstellen ODBC (Open
Database Connectivity) bzw. OLEDB (Object Linking and Embedding - DB) verbunden
werden. Die verschiedenen data provider bereiten die Daten aus den unterschiedlichen
Datenbanken für die Weiterverarbeitung mit übergeordneten Klassen auf bzw. übertragen
modifizierte Daten zurück in die Datenbanken. Im .NET-Framework 2.0 wurde durch so
genannte Providerfactory-Klassen die Abstraktion zusätzlich erhöht. Eine Providerfactory
liefert auf Anforderung das jeweils richtige data provider Objekt zurück und ermöglicht
somit eine vom zugrunde liegenden Datenbanksystem unabhängige Programmierung.
4. Theoretischer Hintergrund
4.3
Seite - 33 –
Vertikale Integration
Die System- und Softwareinfrastruktur moderner Produktionsbetriebe lässt sich laut
[Seit03] in verschiedene Ebenen unterteilen. Abbildung 4.12 zeigt die Ebenenhierarchie in
anschaulicher Form.
Abbildung 4.12: Automatisierungsebenen in Produktionsbetrieben [Seit03]
Die oberste Ebene der Hierarchie wird als Produktionsleitebene bezeichnet. Die
Produktionsleitebene ist geprägt durch den Einsatz von Enterprise Ressource Planning
bzw. Produktionsplanungssystemen wie zum Beispiel SAP1 oder im konkreten Fall der
Fischer GmbH JD Edwards EnterpriseOne. Ein ERP-System unterstützt die betrieblichen
Abläufe einer Unternehmung. Die Kernfunktionalitäten der meisten am Markt etablierten
Systeme liegen in den Bereichen Materialwirtschaft, Einkauf, Vertrieb, Finanz- und
Rechnungswesen, Controlling sowie der Fertigung und der Artikelstammdatenverwaltung.
Vereinfacht
könnte
der
Ablauf
in
der
Fertigung
wie
folgt
aussehen:
Das
Produktionsplanungssystem generiert entsprechend den eingegangenen Kundenaufträgen
interne Produktionsaufträge. Sollten die in den Artikelstammdaten und Stücklisten
definierten Materialen nicht im Lager vorhanden sein, werden diese automatisch
nachbestellt. Die Fertigungsaufträge werden letztendlich in Abhängigkeit von den
gewünschten Lieferterminen und den verfügbaren Produktionsressourcen zur Produktion
eingeplant.
1
http://www.sap.de
4. Theoretischer Hintergrund
Seite - 34 –
Das eigentliche Produktionsumfeld und der Maschinenpark wird in die Prozessleitebene
und die Feldebene unterteilt. In die Feldebene fallen die Sensoren und Aktoren der
Maschinen und Anlagen. Als Verbindung mit den übergeordneten Steuerungsrechnern
kommen industrielle Bussysteme oder konventionelle Verdrahtungstechnologien zum
Einsatz. Als horizontale Integration wird hierbei die Vernetzung von Geräten auf gleicher
Ebene mittels der erwähnten industriellen Bustechnologien bezeichnet.
Die
Steuerung
der
Maschinenabläufe
übernehmen
Steuerungsrechner
in
der
Prozessleitebene. Als Steuerungsrechner kommen zumeist speicherprogrammierbare
Steuerungen zum Einsatz. Zunehmend werden allerdings auch Industrie-PCs mit
Echtzeitbetriebssystemen als SPS-Ersatz eingesetzt. Eine generelle Trennung von Bedienund Beobachtungssystem und dem eigentlichen Maschinensteuerungssystem ist in vielen
Fällen nicht möglich, da speziell bei kleineren Maschinen die Kosten einer getrennten
Ausführung nicht argumentierbar wären. Oftmals wird jedoch mehreren Maschinen ein
einzelnes Beobachtungssystem übergeordnet.
Die im Rahmen dieser Diplomarbeit entwickelten Softwarekomponenten dienen als Basis
für Anwendungen, welche der Prozessleitebene im Bereich „Bedienen und Beobachten“
sowie der Betriebsleitebene im Bereich „Rezeptsteuerung“ zuzuordnen sind. Die
Betriebsleitebene bildet die Schnittstelle zwischen der Produktionsleitebene und den
Maschinensteuerungen in der Prozessleitebene. Viele der für die Produktion relevanten
Stammdaten
werden
beispielsweise
Produktionsplanungssystem
erfasst.
durch
Die
die
direkte
Produktentwicklung
Nutzung
dieser
bereits
im
Daten
im
Produktionsprozess ist erstrebenswert, um die fehlerbehaftete Mehrfacherfassung der
Daten zu vermeiden.
Das Schaffen eines konsistenten Datenflusses über die Ebenenhierarchie hinweg wird als
vertikale Integration bezeichnet. Neben Kosteneinsparungen bei der Datenerfassung
ermöglicht die vertikale Integration die Flexibilisierung der Produktionsprozesse sowie die
Aussicht in kleineren Losgrößen produzieren zu können. Neben der Übergabe von
produktspezifischen Parametersätzen, welche in der Automatisierungstechnik oftmals als
Rezepte bezeichnet werden, an die Steuerungsrechner kann in umgekehrter Richtung die
Erfassung von Betriebsdaten zur Qualitätssicherung einen hohen Zusatznutzen für eine
Unternehmung darstellen. Das Betriebsdatenmanagement wird allerdings im Rahmen der
4. Theoretischer Hintergrund
Seite - 35 –
Diplomarbeit nicht behandelt. Mit einer zukünftigen Erweiterung der erstellten
Softwarekomponenten bzw. der Entwicklung zusätzlicher Komponenten könnte jedoch
auch die Behandlung von Betriebsdaten realisiert werden.
4.3.1
IT Infrastruktur der Fischer GmbH
Das konkrete Projektumfeld der Fischer GmbH entspricht der in Abschnitt 4.3 erläuterten
Ebenenhierarchie. Das ERP-System JD Edwards EnterpriseOne verwaltet die Auftragsund Artikelstammdaten. Weitere produktionsspezifische Daten werden mit Hilfe vom
ERP-System unabhängigen Eingabemasken erfasst. Eine zukünftige Integration dieser
meist mit Microsoft Access realisierten Eingabemasken in EnterpriseOne steht zur
Diskussion. Sämtliche in der Produktionsleitebene erfassten Daten werden in einem
Oracle-Datenbanksystem verwaltet. Die Prozessleitebene ist ein heterogenes Umfeld aus
Steuerungen und Industrie-PCs verschiedenster Hersteller. Die am häufigsten eingesetzten
Geräte kommen von den führenden Herstellern Bernecker&Rainer1 und Siemens2. Die
während der Diplomarbeit entwickelten Softwarekomponenten dienen zur vereinfachten
Erweiterung der Betriebsleitebene. Die Komponenten kapseln Zugriff auf die
Produktionsdaten sowie die Kommunikation zu den Steuerungssystemen.
4.3.2
Speicherprogrammierbare Steuerungen
In Maschinen und Anlagen kommen Aktoren wie Pneumatikzylinder oder verschiedenste
Arten von elektrischen Antriebssystemen zum Einsatz. Zur Erfassung von aktuellen
Prozesszuständen dienen Sensoren wie Initiatoren, Lichtschranken oder Wegmesssysteme.
Die Logik für die Ansteuerung der Aktoren in Abhängigkeit von den Signalzuständen der
Sensoren ist durch den gewünschten Maschinenablauf definiert und kann durch den
Einsatz von fest verdrahteten Hardwarekomponenten realisiert werden. In diesem Fall
werden meist Relais und Zeitrelais durch die Verdrahtung fest verbunden. Aus diesem
Grund
spricht
man
bei
dieser
Art
des
Steuerungsaufbaus
von
einer
verbindungsprogrammierten Steuerung (VPS). Die Hauptnachteile der VPS sind die
fehlende Flexibilität gegenüber Ablaufänderungen sowie die sehr hohen Kosten bei
steigender Komplexität der Steuerungsaufgabe. Die vertikale Integration einer VPS ist in
1
http://www.br-automation.com
2
http://www.siemens.de
4. Theoretischer Hintergrund
den
meisten
Fällen
nicht
Seite - 36 –
möglich.
Aus
diesen
Gründen
haben
sich
speicherprogrammierbare Steuerungen in der Automatisierungstechnik durchgesetzt.
Aufbau
SPS-Systeme sind in der Regel modular aufgebaut. Neben einem CPU- oder
Prozessormodul auf dem die Logik des Maschinenablaufs programmiert wird, werden
verschiedenste Arten von Ein- und Ausgangsmodulen verwendet um die Sensoren und
Aktoren einer Maschine anzubinden. Displaymodule ermöglichen die Visualisierung der
aktuellen Prozesszustände und die gewünschten Benutzerinteraktionen laut dem
Bedienkonzept. Zur Kommunikation mit Fremdgeräten kann eine Steuerung mit RS232,
RS422/485 oder Feldbusschnittstellen erweitert werden. Auch eine Ethernet Schnittstelle
zur Anbindung der Steuerung an das Firmennetzwerk zählt vielfach bereits zum Standard.
Abbildung 4.13: Beispielkonfiguration eines SPS-Systems [Bern06]
Obige Darstellung (Abbildung 4.13) zeigt
eine Beispielkonfiguration der Fa.
Bernecker&Rainer. Wie ersichtlich ist, können Displaymodule aber auch Ein- und
Ausgangsmodule abgesetzt von der zentralen Steuerungseinheit verbaut werden. Die
4. Theoretischer Hintergrund
Seite - 37 –
Kopplung erfolgt in diesem Fall über genormte Feldbussysteme wie CAN1 oder Profibus2.
Antriebstechnische Komponenten werden in der Regel ebenfalls über ein Feldbussystem
an die Steuerung angebunden. Ein dezentraler Aufbau der Steuerungskomponenten kann in
vielen Fällen Kosten für die Verdrahtung und Installation einsparen.
Programmierung
Die Mikroprozessor-Architektur aktueller Steuerungssysteme entspricht in weiten Zügen
jener von Standard Computern. Bei den Steuerungssystemen der Systemgeneration 4
(SG4) von Bernecker&Rainer werden beispielsweise Intel3 Pentium Prozessoren
eingesetzt. Um deterministisch auf die Änderung eines Eingangssignals reagieren zu
können, kommen Echtzeitbetriebssysteme zum Einsatz. Die erstellten Programme werden
zyklisch abgearbeitet. Das Intervall der Abarbeitung kann meist durch den Programmierer
festgelegt werden. Die maximale Verzögerungszeit, nach der ein Eingangssignal sicher
verarbeitet wird, ist somit eindeutig vorhersagbar.
Der Programmierer einer SPS hat bei der Programmerstellung die Auswahl zwischen
mehreren unterschiedlichen Programmiersprachen. Während komplexe Programmteile
vorzugsweise in einer Hochsprache implementiert werden, können einfache logische
Verknüpfungen sehr übersichtlich im so genannten Kontaktplan realisiert werden. Die
verwendete Programmiersprache hat keinen Einfluss auf den Determinismus. Folgende
Programmausschnitte wurden für eine Bernecker&Rainer Steuerung erstellt und weichen
daher von der Darstellung anderer Hersteller ab.
1
http://www.can-cia.org
2
http://www.profibus.com
3
http://www.intel.com
4. Theoretischer Hintergrund
Seite - 38 –
Listing 4.3: SPS Programmierung im Kontaktplan
Das einfache Kontaktplanbeispiel in Listing 4.3 zeigt wie Eingänge und Ausgänge mit der
Hilfe von lokalen Merkervariablen verknüpft werden können. Die Verwendung von
Funktionsblöcken erweitert die Leistungsfähigkeit der Kontaktplanprogrammierung.
Funktionsblöcke werden in Libraries verwaltet und können in einer beliebigen Sprache
erstellt werden.
if (g_R364.HomeAxis.Senden=TRUE)then
case l_sk_HomeAxis of
(*** Befehle Senden ***)
action 0:
memset(adr(sende_daten),0,sizeof(sende_daten))
strcpy(adr(sende_daten),"#AHA")
port_schreiben=1
port_lesen=0
l_sk_HomeAxis=10
endaction
(*** Auf Antwort warten ***)
action 10:
..
Listing 4.4: SPS Programmierung mit Automation Basic
4. Theoretischer Hintergrund
Seite - 39 –
Das Programmfragment in Listing 4.4 wurde in der Bernecker&Rainer-eigenen Sprache
Automation Basic erstellt. Schrittschaltwerke für Ablaufketten lassen sich wie gezeigt sehr
elegant verwirklichen. String- und Speichermanipulationsfunktionen ermöglichen eine sehr
flexible und effiziente Programmerstellung.
Kommunikation mit SPS-Systemen
Um von der Programmierumgebung oder weiterführend von übergeordneten Systemen auf
die aktuellen Prozesszustände und Variablen einer SPS zugreifen zu können, wurden von
den Herstellern proprietäre Kommunikationsprotokolle entwickelt. Die physikalische
Verbindung kann seriell oder wiederum über unterschiedlichste Bussysteme realisiert
werden. Die Fischer GmbH koppelt SPS-Systeme überwiegend mittels Ethernet an
Betriebsdatenerfassungs- oder Rezeptsteuerungssysteme. Damit in den Leitsystemen nicht
alle herstellerspezifischen Kommunikationsprotokolle implementiert werden müssen,
kommt Openess, Productivity and Collaboration als Abstraktionsschicht zum Einsatz.
OPC wird von allen namhaften Steuerungsherstellern unterstützt. Das Leitsystem kann
somit
transparent
mit
den
Steuerungssystemen
unterschiedlicher
Hersteller
kommunizieren.
4.3.3
Openess, Productivity and Collaboration
In den 90er Jahren stellte die zeit- und somit auch kostenintensive Implementierung und
Wartung
von
Kommunikationstreibern
zur
Unterstützung
möglichst
vieler
Hardwarekomponenten ein großes Problem für die Softwarehersteller von HMI (Human
Machine Interface) Produkten dar. Aus diesem Grund wurde 1995 die OPC Task Force ins
Leben gerufen. Neben führenden Automatisierungstechnikfirmen aus dem Soft- und
Hardwarebereich beteiligte sich auch Microsoft. Ziel der Task Force war es, einen
Standard zum Zugriff auf Echtzeitdaten unter Windows-Betriebssystemen, welcher auf
Microsofts (OLE/)DCOM-Technologie basiert, zu erarbeiten [Iwan05]. So stand die
Abkürzung OPC ursprünglich für OLE for Process Control. Die Bezeichnung wurde
allerdings mit der Verwendung von DCOM als Basis für OPC in Openess, Productivity
and Collaboration geändert. Nichts desto trotz ist OLE for Process Control auch heute
noch überaus gebräuchlich. Bereits im August 1996 lag die OPC Specification Version 1.0
4. Theoretischer Hintergrund
Seite - 40 –
vor. Nahezu zeitgleich wurde die OPC Foundation1 zur Koordinierung der Spezifikationsund Marketingarbeiten gegründet. Ein Jahr später erfolgte die erste Aktualisierung der
OPC Specification unter der Bezeichnung Data Access Specification (OPC-DA). Seither
erarbeitete die OPC Foundation eine Reihe von Spezifikationen, die als Basis für aktuelle
OPC-Implementierungen dienen. Abbildung 4.14 zeigt eine Aufstellung der verschiedenen
Spezifikationen.
Abbildung 4.14: Verfügbare und in Arbeit befindliche OPC-Spezifikationen [Iwan05]
Bei der Entwicklung wurde großer Wert auf die Kompatibilität der einzelnen Standards
gelegt. Aus diesem Grund wurden allgemein gültige Teile in eigene Dokumente
ausgelagert. Die Spezifikationen sind frei verfügbar und stehen auf der Internetseite der
OPC Foundation zum Download bereit. Tabelle 4.1 beschreibt stichwortartig die
Bedeutung der verschiedenen Standards.
Spezifikation
OPC Overview
OPC Common
Definitions and
Interfaces
OPC Data Access
Specification
1
http://www.opcfoundation.org
Bedeutung
Allgemeine
Beschreibung
der
Einsatzgebiete von OPC Spezifikationen
Festlegung von Sachverhalten, die eine
große Anzahl von Spezifikationen
betreffen
Definition einer Schnittstelle für das Lesen
und Schreiben von Echtzeitdaten
Freigabestatus
Release 1.00
Release 1.10
Release 3.00
4. Theoretischer Hintergrund
OPC Alarms and Events
Specification
OPC Historical Data
Access Specification
OPC Batch Specification
OPC Security
Specification
OPC XML-DA
OPC Data eXchange
(DX)
OPC Commands
OPC Complex Data
OPC Unified
Architecture
Seite - 41 –
Definition
einer
Schnittstelle
zur
Überwachung von Ereignissen
Definition einer Schnittstelle zum Zugriff
auf historische Daten
Definition einer Schnittstelle zum Zugriff
auf Daten, die bei der Batchverarbeitung
benötigt werden. Diese Spezifikation
erweitert die Data Access Specification
Definition einer Schnittstelle für das
Erstellen und Nutzen von Sicherheitsaspekten
Integration von OPC und XML zur
Erstellung von Webanwendungen
Kommunikation zwischen Server und
Server
Definition einer Schnittstelle für das
Übergeben von Kommandos und das
Überwachen ihrer Abarbeitung
Definition
einer
Schnittstelle
zum
Beschreiben der Struktur komplexer Daten
und zum Zugriff auf solche Daten
Definition
einer
Interoperabilitätsplattform, die basierend auf Web Services
einen einheitlichen Zugriff auf Daten in
DA-, AE-, HDA-Servern ermöglichte.
Release 1.10
Release 1.20
Release 2.00
Release 1.00
Release 1.01
Release 1.00
Release 1.00
Release 1.00
Draft
Tabelle 4.1: OPC Spezifikationen – Bedeutung und Freigabestatus (02/2006) [Iwan05]
Wie aus der Auflistung der verfügbaren Spezifikationen hervorgeht, folgt auch die OPC
Foundation dem allgemeinen Trend Web Services und XML als Basistechnologien für ihre
Standards zu verwenden. Die enge Kopplung mit Microsofts DCOM wird somit in naher
Zukunft stark gelockert werden. Eine Portierung der OPC-Funktionalitäten auf
verschiedenste Betriebssysteme ist somit vorstellbar. Für die im Rahmen dieser
Diplomarbeit entwickelten Softwarekomponenten ist die Data Access Specification in der
Version 2.05 relevant, da die Version 3.00 derzeit nur in wenigen Produkten implementiert
ist. Ein möglichst breiter Einsatzbereich der Softwarekomponenten kann somit
gewährleistet werden. Es folgt eine kurze Einführung in die Grundkonzepte dieser
Spezifikation.
4. Theoretischer Hintergrund
Seite - 42 –
OPC Data Access Specification
OPC basiert auf einer Client/Server-Architektur. Ein OPC Data Access Server stellt
Schnittstellen für den Lese- und Schreibzugriff auf Echtzeitdaten von einem oder mehreren
Geräten der Prozessleit- oder Feldebene zur Verfügung. Ein oder mehrere OPC-Clients
greifen auf den OPC-Server zu und können dessen Funktionalitäten nutzen. Der Zugriff
auf den Server erfolgt dabei gemäß der OPC Data Access Specification immer in der
gleichen Art und Weise. Der Server übernimmt die proprietäre Kommunikation mit den
Geräten der Prozessleit- oder Feldebene. Die Data Access Specification definiert zwei
unterschiedliche Konzepte, die ein Data Access Server implementieren und ein Data
Access Client nutzen kann – den Namensraum (Namespace) und die OPCObjekthierarchie [Iwan05].
Abbildung 4.15: OPC-DA-Server – Namensraum und Objekthierarchie [Iwan05]
Ein Namensraum enthält alle Prozessgrößen, auf die der Client zugreifen kann. In einem
hierarchischen Namensraum werden zur Gliederung der Prozessgrößen Baumstrukturen
verwendet. Eine Wurzel besitzt, wie im Beispiel von Abbildung 4.15 mehrere Knoten,
welche wiederum mehrere Knoten oder Items besitzen können. In einem flachen
Namensraum sind alle Items in einer Ebene angeordnet. Ein Client kann zur Ermittlung der
vorhandenen Prozessgrößen diesen Namensraum durchsuchen.
4. Theoretischer Hintergrund
Seite - 43 –
Mittels der OPC-Objekthierarchie kann der Client seine eigene Sicht auf den Prozess
festlegen. Der Client erzeugt hierfür innerhalb der Server-Komponente verschiedene
Objekte. Das OPC-Server-Objekt stellt hierbei das am höchsten in der Hierarchie
angesiedelte Objekt dar. Das Server-Objekt verwaltet die OPC-Group-Objekte. Den
Gruppen-Objekten sind wiederum ein oder mehrere Item-Objekte zugeordnet. Die Anzahl
und Zuordnung der Gruppen- sowie Item-Objekte ist dabei unabhängig vom Aufbau des
Namensraums im Server.
Die Objekte innerhalb der Server-Komponente stellen über Schnittstellen ihre
Funktionalitäten zur Verfügung. Ein Item-Objekt muss laut Spezifikation beispielsweise
Methoden zum Lesen und Schreiben der Prozessgröße implementieren. Über das OPCGroup-Objekt können alle untergeordneten Item-Objekte gelesen oder geschrieben werden.
Beim Lesen muss jeweils festgelegt werden, ob der Wert direkt vom Gerät (Device) oder
vom internen Speicher der Server-Komponente (Cache) gelesen werden soll. Neben dem
Wert der Prozessgröße liefern Leseoperationen immer einen Zeitstempel und
Informationen zur Verbindungsqualität. Schreiboperationen werden immer direkt am Gerät
ausgeführt.
Lese- und Schreiboperationen können synchron oder asynchron erfolgen. Bei der
asynchronen Variante wird der Client über Callback-Mechanismen über die Fertigstellung
der Anfrage benachrichtigt. Um ein zyklisches Lesen der Prozessgrößen vermeiden zu
können, werden Callbacks häufig zur Benachrichtigung bei Wertänderungen verwendet.
Mit Refresh-Operationen können die Werte aller Prozessgrößen einer Gruppe aktualisiert
werden. Es gibt beim Refresh ebenfalls die Wahlmöglichkeit zwischen einer synchronen
und asynchronen Variante.
4. Theoretischer Hintergrund
Seite - 44 –
OPC und .NET
Die für die Fischer GmbH entwickelten Softwarekomponenten basieren auf Microsofts
.NET-Technologie. Zum Zugriff auf DCOM-OPC-Server wurden zur Implementierung der
Softwarekomponenten OPC-Client-Komponenten der Firma Metadynamics verwendet.
Abbildung 4.16: Zugriff auf OPC-DCOM-Server mit .NET-Komponenten [Iwan05]
Die Komponenten stellen ein .NET kompatibles Interface zur Verfügung und kapseln den
DCOM-Zugriff auf den Server. Die Anwendungsentwicklung wird dadurch maßgeblich
vereinfacht, da detaillierte Kenntnisse der teilweise sehr komplexen DCOM-Mechanismen
nicht notwendig sind. Abbildung 4.16 zeigt, wie der Zugriff auf einen DCOM-Server aus
.NET abläuft.
5. Implementierung der Lösung
5.
Dieses
Seite - 45 –
Implementierung der Lösung
Kapitel
dokumentiert
die
im
Rahmen
der
Diplomarbeit
erstellten
Softwarekomponenten. Beginnend mit einer Übersicht über die im Zuge der
Implementierung
eingesetzten
Softwarepakete
und
den
zu
Grunde
liegenden
Designaspekten werden die lokale Anwendungsdatenbank am Leitrechner und die
Softwarekomponenten detailliert beschrieben. Zur Erläuterung des Aufbaus der Datenbank
werden Entity-Relationship-Diagramme verwendet. UML-Klassendiagramme dienen als
Basis für die Beschreibung der öffentlichen Methoden und Attribute der Komponenten.
Der Umfang des Kapitels orientiert sich an der Zielsetzung einem Anwendungsentwickler
den Einsatz der Softwarekomponenten und deren Konfiguration zu ermöglichen.
5.1
Eingesetzte Softwareprodukte
Mit der in Kapitel 3 der Diplomarbeit getroffenen Technologieentscheidung zu Gunsten
der
Microsoft
.NET-Plattform
und
der
Auswahl
der
Microsoft-eigenen
Entwicklungsumgebung Visual C# 2005 Express waren die Rahmenbedingungen für die
Implementierung zum überwiegenden Teil definiert. Seitens der Fischer GmbH wurde
Microsoft Access als lokales Datenbanksystem am Leitrechner festgelegt. Eine zukünftige
Umstellung auf die Express Edition des Microsoft SQL Servers wird derzeit von der
Fischer GmbH angedacht. Durch die offen gehaltene Datenbankschnittstelle der
Komponenten sind in diesem Fall jedoch keine Softwareänderungen notwendig. Die
Verwendung der OPC-Client-Komponenten für .NET von Metadynamics wurde ebenfalls
durch die Fischer GmbH vorgegeben. Die Softwarekomponenten wurden mit
verschiedenen Maschinensteuerungssystemen der Firma Bernecker&Rainer getestet. Die
entsprechenden Versionen der Kommunikationstreiber und SPS-Betriebssysteme sind in
Tabelle 5.1 zusammen mit den restlichen Softwarepaketen aufgelistet.
Einsatzbereich
Betriebssystem
Framework
Entwicklungsumgebung
Applikationstest
ERP-System
Business Datenbank
Applikationsdatenbank
Hersteller/Produkt
Microsoft Windows 2000 Professional
Microsoft Windows XP Professional
Microsoft .NET-Framework
Microsoft Visual C# Express Edition
SciTech .NET Memory Profiler
JD Edwards EnterpriseOne
Oracle
Microsoft Access 2002
Version(en)
SP4
SP2
2.0.50727
8.0.50727.42
2.6
8.11
9.2.0.1
10.6771.6735
5. Implementierung der Lösung
OPC-Client-Komponenten
OPC-Server/SPS- Anbindung
SPS Betriebssysteme
Seite - 46 –
Metadynamics OPC ClientX.NET
Bernecker & Rainer PVI OPC-Server
Bernecker & Rainer
1.5.0.39
2.5.2.3003
SG3 ab 2.24
SG4 ab 2.82
Tabelle 5.1: Eingesetzte Softwareprodukte
5.2
Designaspekte
Abgeleitet aus den Systemanforderungen der Fischer GmbH wurde das Design der
Softwarekomponenten und des entsprechenden Umfeldes einer Leitrechneranwendung
entwickelt.
Am
Leitrechner
laufen
neben
der
komponentenbasierten
Leitrechneranwendung die herstellerspezifischen OPC Data Access Server der
angebundenen Maschinensteuerungssysteme. Der Zugriff auf die verschiedenen OPCServer erfolgt unabhängig von diesen mittels den OPC ClientX .NET Komponenten der
Firma Metadynamics. Die OPC-Server bilden somit eine Abstraktionsschicht für die
proprietären Kommunikationsprotokolle der Steuerungshersteller.
Zur Anbindung an das Oracle-Datenbanksystem der Fischer GmbH wird eine Microsoft
Access Datenbank verwendet. In der lokalen Datenbank sind die relevanten Tabellen des
Oracle-Datenbanksystems der Fischer GmbH verknüpft. Der Datenbankzugriff der
Anwendung beschränkt sich daher auf die lokale Datenbank und die Notwendigkeit eines
direkten Zugriffs auf die Tabellen der Oracle-Datenbank wird vermieden. Die
Produktionsdaten werden in einer speziellen Tabelle innerhalb der Access-Datenbank
gehalten. Zur Aktualisierung der Produktionsdatentabelle werden in der Datenbank
hinterlegte Stored Procedures von der Leitrechneranwendung aufgerufen.
Besonderes Augenmerk wurde auf die Kapselung der einzelnen Funktionalitäten einer
Leitrechneranwendung in eigenständig verwendbare Softwarekomponenten gelegt. Das
Laufzeitverhalten der Instanzen der einzelnen Komponenten wird über spezielle Tabellen
der lokalen Access-Datenbank konfiguriert.
Durch die Gestaltung des Umfeldes in der beschriebenen Art und Weise wurde ein
Maximum an Flexibilität für die Leitrechneranwendungen erreicht. Erweiterungen können
in einer Vielzahl der Fälle konfiguriert anstatt programmiert werden.
5. Implementierung der Lösung
5.2.1
Seite - 47 –
Trennung der Funktionalitäten in Komponenten
Zur effizienten Erstellung von Leitrechneranwendungen wurden im Rahmen der
Diplomarbeit die Hauptaufgaben der Applikationen in drei Softwarekomponenten
gekapselt.
Abbildung
5.1
zeigt
den
Aufbau
einer
komponentenbasierten
Leitrechneranwendung und deren Umfeld.
Die drei Komponenten OpcManager, DataManager und MachineManager bilden den
Kern der Applikation. Mit der Kommunikation zu den Steuerungssystemen, der
Datenbankanbindung und der Logik für den Datenaustausch mit den Steuerungen werden
die Anforderungen an ein Leitrechnersystem zum Großteil erfüllt. Das grafische User
Interface wird vom Programmierer anwendungsspezifisch erstellt.
Abbildung 5.1: Architekturübersicht einer komponentenbasierten Leitrechneranwendung
5. Implementierung der Lösung
Seite - 48 –
Komponente „OpcManager“
Die Komponente OpcManager ist für die Initialisierung der Kommunikation mit den
Maschinensteuerungssystemen zuständig. Der OpcManager stellt den Zugriff auf ein
OPC-Server-Objekt je angebundener Maschine zur Verfügung. Die OPC-Server, deren
Gruppen und Items, werden in den Konfigurationstabellen der Komponente definiert.
Mit der Komponente OpcManager können Applikationen, welche ausschließlich zur
Visualisierung von Prozess- bzw. Maschinenzuständen dienen, sehr einfach erstellt
werden. Die Darstellung der einzelnen Variablenwerte sowie die Gestaltung der grafischen
Benutzeroberfläche bleiben in diesem Fall wiederum dem Anwendungsentwickler
überlassen.
Ein einzelnes Objekt der Komponente initialisiert die Kommunikation mit allen
angebundenen Maschinensteuerungssystemen. Eine mehrfache Instanzierung der Klasse ist
somit nicht notwendig und wird unter zu Hilfenahme des Singleton-Designpatterns gemäß
[Gamm97] verhindert. Das Singleton-Pattern wird in Abschnitt 5.2.2 näher betrachtet.
Komponente „DataManager“
Als zweite Komponente wurde der so genannte DataManager implementiert. Der
DataManager übernimmt die Datenbankanbindung und die Aktualisierung der
Produktionsdaten in der lokalen Anwendungsdatenbank am Leitrechner. Die aktuellen
Produktionsdaten werden in einem DataTable-Objekt für die Verwendung durch die
Applikation zur Verfügung gestellt. Die Aktualisierung der Daten erfolgt durch den Aufruf
von Stored Procedures. In einer der Konfigurationstabellen werden hierfür die Namen der
aufzurufenden Prozeduren eingetragen. Neben der reinen Datenaktualisierung kann das
Kopieren von Dateien von einem Netzlaufwerk, in Abhängigkeit von den Werten einer
Spalte der Produktionsdatentabelle, konfiguriert werden. Dies kann notwendig sein, um
beispielsweise NC-Programme (Numeric Control), welche direkt durch das CAD-System
erstellt werden, auf den Leitrechner zu kopieren.
Die Komponente DataManager kann eigenständig verwendet werden. Als Beispiel ist eine
Anwendung zum Drucken von artikelspezifischen Produktetiketten denkbar. Die
Komponente dient zur Anbindung an die übergeordnete Datenbank und stellt die
5. Implementierung der Lösung
Seite - 49 –
Artikeldaten zur weiteren Verwendung zur Verfügung. Das Etikett mit den entsprechenden
Produktdaten kann dann durch die Anwendung auf einem Tischdrucker gedruckt werden.
Wie die Komponente OpcManager ist auch der DataManager als Singleton implementiert,
um eine mehrfache Instanzierung zu verhindern. Ein Objekt der Komponente verwaltet den
gesamten Datenbestand für die gesamte Leitrechneranwendung.
Komponente „MachineManager“
Mit dem Einsatz der beiden oben erwähnten Komponenten stehen sowohl die aktuellen
Variablenwerte der einzelnen Maschinensteuerungssysteme als auch die aktuellen
Produktionsdaten zur Verfügung. Die Logik zur Anfragebehandlung gemäß dem
Flussdiagramm aus den Systemanforderungen in Kapitel 2 wurde in der Komponente
MachineManager implementiert.
Um
die
Komponente
möglichst
flexibel
zu
halten,
wurden
umfangreiche
Konfigurationsmöglichkeiten vorgesehen. So wird in den Konfigurationstabellen die
Bedeutung der einzelnen OPC-Gruppen und Items definiert. Für das Schreiben der
Produktionsdaten auf die Maschinensteuerungen werden die Querverbindungen zwischen
den OPC-Items bzw. den Variablen auf den Steuerungen und den entsprechenden
Spaltennamen der Produktionsdatentabelle festgelegt. Downloads von Dateien und deren
Konvertierung in ein für das Steuerungssystem verständliches Format werden ebenfalls in
einer eigenständigen Konfigurationstabelle eingetragen.
Der MachineManager basiert auf Objekten, welche durch die beiden zuvor vorgestellten
Komponenten zur Verfügung gestellt werden. Eine Verwendung im Zusammenspiel mit
dem OpcManager und dem DataManager ist daher zielführend. Der MachineManager ist
im Gegensatz zu den beiden anderen Komponenten nicht als Singleton implementiert. Für
jede angebundene Maschine wird ein eigenständiges Objekt instanziert.
5. Implementierung der Lösung
5.2.2
Seite - 50 –
Designpatterns
Bei der Erstellung der Komponenten wurden wie bereits erwähnt Designpatterns
berücksichtigt. Im Folgenden werden das Singleton- und das Observer-Pattern vorgestellt
und die entsprechenden Implementierungen in C# beschrieben.
Singleton - Pattern
Das Singleton ist laut [Klei03] ein objektbasiertes Erzeugungsmuster mit dem Zweck, dass
eine Klasse mit genau einer Instanz existiert und genau ein Zugriffspunkt auf das Kreieren
der Instanz ermöglicht wird.
Die Implementierung in C# kann wie folgt sehr einfach realisiert werden
public sealed class OpcManager : IDisposable
{
public static readonly OpcManager Instance = new OpcManager();
private OpcManager()
{
}
}
Listing 5.1: Singleton Implementierung in C#
Das Schlüsselwort sealed in der Deklaration der Klasse verhindert die Ableitung der
Klasse. Das public Attribut Instance ist als static readonly gekennzeichnet. Mit dem
Zugriff auf das Attribut wird eine Instanz der Klasse erzeugt. Bei jedem weiteren Zugriff
wird wiederum die Referenz auf das nur einmal erzeugte Objekt geliefert. Die private
Kennzeichnung des Konstruktors verhindert eine Instanzierung über diesen.
Observer - Pattern
Das Observer-Pattern definiert eine Abhängigkeit von 1:n zwischen Objekten, sodass bei
einer Zustandsänderung alle registrierten Objekte benachrichtigt werden und sich dann
automatisch
oder
zu
gegebener
Zeit
aktualisieren
können
[Klei03].
Die
Programmiersprache C# bietet mit Events eine Möglichkeit zur Realisierung. In den im
Rahmen der Diplomarbeit erstellten Softwarekomponenten wurde die EventsHelper
Klasse aus [Löwy05] eingesetzt. Die Klasse bietet Methoden zum typsicheren Absetzen
synchroner und asynchroner Events. Folgendes Beispiel in Listing 5.2 und Listing 5.3 zeigt
5. Implementierung der Lösung
Seite - 51 –
anhand des Events DataUpdateComplete das Absetzen des Events in der DataManager
Klasse sowie die Registrierung des Empfangs in einer Client Klasse.
Auszug aus der Klasse DataManager:
public sealed class DataManager
{
..
public event GenericEventHandler EventDataUpdateComplete;
private void LoadMachineData()
{
..
EventsHelper.Fire(EventDataUpdateComplete);
}
}
Listing 5.2: Observer-Pattern – DataManager Klasse
public class ClientClass
{
..
private void Init()
{
// Initialisierung des DataHandlers über Singleton
dataMgr = DataManager.Instance;
dataMgr.EventDataUpdateComplete +=
new GenericEventHandler(dataMgr_DataUpdateComplete);
}
void dataMgr_DataUpdateComplete()
{
..
}
}
Listing 5.3: Observer-Pattern – Client Klasse
Die Client-Klasse registriert sich mit dem += Operator für die Benachrichtigung. Tritt das
Ereignis
EventDataUpdateComplete
dataMgr_DataUpdateComplete
5.2.3
Die
ein,
so
wird
die
Methode
der Client Klasse aufgerufen.
Unabhängigkeit vom Datenbanksystem
Anforderung,
die
Komponenten
unabhängig
von
der
Datenherkunft
der
Produktionsdaten zu gestalten, ergibt die Notwendigkeit bereits den Code für den
Datenzugriff unabhängig von der Datenquelle zu gestalten. ADO.NET 2.0 und dessen
Providerfactories erleichtern die Umsetzung der Anforderung deutlich. Das folgende
Listing 5.4 zeigt die Methoden Init, OpenDbConnection und CloseDbConnection, wie
sie in ähnlicher Form in allen Komponenten zum Einsatz kommen. Aus Gründen der
5. Implementierung der Lösung
Seite - 52 –
Anschaulichkeit wurden die try und catch Anweisungen der Ausnahmebehandlung
entfernt.
// Private
private string m_ProviderName;
private string m_ConnectionString;
private DbProviderFactory m_DataProvider;
private DbConnection m_DataConnection;
public void Init(string dbProviderName, string dbConnectionString)
{
// Setzen der lokalen Membervariablen
m_ProviderName = dbProviderName;
m_ConnectionString = dbConnectionString;
OpenDbConnection();
// Klassenspezifische Initialisierung
..
CloseDbConnection();
}
private void OpenDbConnection()
{
// Instanz der DbProviderFactory mit dem Providernamen erzeugen
m_DataProvider= DbProviderFactories.GetFactory(m_ProviderName);
// Erzeugen eines Connection Objekts über die DbProviderFactory
m_DataConnection = m_DataProvider.CreateConnection();
// Setzen des ConnectionStrings der Verbindung
m_DataConnection.ConnectionString = m_ConnectionString;
if (m_DataConnection.State==System.Data.ConnectionState.Closed)
{
m_DataConnection.Open(); // Öffnen der Datenbankverbindung
}
}
private void CloseDbConnection()
{
if (m_DataConnection.State==System.Data.ConnectionState.Open)
{
m_DataConnection.Close();
// Schließen der Datenbankverb.
}
}
Listing 5.4: Verwendung von Providerfactories in ADO.NET 2.0
Die
public
verfügbare
anwendungsspezifischen
Methode
Init
Providernamen
erhält
und
als
Übergabeparameter
Connection-String
den
der
Konfigurationsdatenbank. Mit Hilfe des dem Providernamens wird durch einen vom data
provider unabhängigen Methodenaufruf ein DbProviderFactory Objekt erstellt. Zum
Zugriff auf Microsoft Access Datenbanken wird als Providername System.Data.OleDb
verwendet. Microsoft SQL Server werden mit System.Data.SqlClient verbunden. Mit
dem providerspezifischen DbProviderFactory Objekt lässt sich anschließend ein
5. Implementierung der Lösung
DbConnection
Seite - 53 –
Objekt erzeugen. Mit der Eigenschaft ConnectionString wird die
Verbindungszeichenfolge zur Datenbank definiert.
5.3
Lokale Anwendungsdatenbank
In der Access-Datenbank am Leitrechner erfolgt die Verwaltung der Produktionsdaten
sowie die Konfiguration der einzelnen Softwarekomponenten. Für beide Aufgaben müssen
verschiedene Tabellen in definierter Form zwingend vorhanden sein. In Abschnitt 5.3.1
werden Aufbau und Aktualisierung der Produktionsdatentabelle beschrieben. Abschnitt
5.3.2 zeigt die Anforderungen an die Konfigurationstabellen der verschiedenen
Softwarekomponenten.
5.3.1
Verwaltung der Produktionsdaten
Die Produktions- bzw. Maschinendaten werden in einer Tabelle mit dem fest
vorgegebenen Namen MachineData gehalten. Der Aufbau der Tabelle unterscheidet sich je
nach dem Einsatzgebiet des Leitrechnersystems. In gewissen Produktionsbereichen kann
eine Unterscheidung hinsichtlich des zu produzierenden Artikels mit der Artikelnummer
als Primärschlüssel ausreichend sein. In anderen Bereichen müssen hingegen die einzelnen
Kundenaufträge mit der Auftragsnummer als Schlüsselfeld unterschieden werden. Aus
diesem Grund gibt es nur wenige Vorschriften beim Anlegen der Tabelle zu beachten.
Einige Spalten sind zwingend erforderlich. Die Tabelle A.1 im Anhang A des Dokuments
gibt eine Übersicht über diese „Muss-Felder“.
Die Anzahl der effektiven Felder für Produktionsparameter ist ebenso unerheblich wie die
Namen der entsprechenden Felder. In der Praxis wird es sich als Ziel führend erweisen,
eine vorhandene Anwendungsdatenbank an die Gegebenheiten einer neuen Applikation
anzupassen.
Befüllung, Aktualisierung und Bereinigung der Tabelle
Aufgrund der hohen Flexibilitätsanforderungen an die Tabelle wird das Befüllen, die
Aktualisierung und die Bereinigung der Datensätze über in der Datenbank hinterlegte
Stored Procedures vorgenommen. Zu diesem Zweck werden die Oracle-Tabellen mit den
benötigten Quelldaten in der Access-Datenbank verknüpft. Für die im Sprachgebrauch von
Microsoft Access als Abfragen bezeichneten Stored Procedures besteht kein Unterschied
hinsichtlich des Zugriffs auf lokale und verknüpfte Tabellen. Die Abfragen können nach
5. Implementierung der Lösung
Seite - 54 –
der Erstellung direkt in Access ausgeführt und getestet werden. In der Regel sind für eine
konsistente Datenverwaltung mindestens drei Abfragen notwendig. Die erste Abfrage
befüllt die Tabelle. Eine zweite Abfrage aktualisiert bereits vorhandene Datensätze. Die
dritte Abfrage entfernt Datensätze, welche über längere Zeit nicht mehr aktualisiert wurden
und somit nicht mehr relevant sind. Als Zeitspanne hierfür werden derzeit 30 Tage
verwendet. Je nach Anzahl der Quelltabellen können wie aus Abbildung 5.2 hervorgeht
mehrere Aktualisierungsabfragen erforderlich sein.
Abbildung 5.2: Befüllung, Aktualisierung und Bereinigung der Tabelle MachineData
Der eindeutige Wert des Feldes MACHINEKEY wird beim Eintragen des Datensatzes in die
Tabelle MachineData generiert. Die Inhalte der Felder CODE1, CODE2 und DATAVALID
ergeben sich entweder direkt aus anderen Feldwerten oder aus einer bedingten
Kombination der Inhalte verschiedener Datenfelder. Die Felder werden im Zuge einer
Aktualisierungsanfrage befüllt.
Das Ausführen aller notwendigen Abfragen wird im weiteren Dokument kurz als „Daten
laden“ bezeichnet. Die Komponente DataManager bietet Methoden um das Laden der
Daten unmittelbar bzw. in einem täglichen Intervall zu starten.
5. Implementierung der Lösung
5.3.2
Seite - 55 –
Konfigurations-Tabellen
Um ein möglichst breites Anwendungsspektrum mit den Softwarekomponenten abdecken
zu können, wurden
umfangreiche Konfigurationsmöglichkeiten vorgesehen.
Die
Konfigurationstabellen ermöglichen die Definition folgender Einstellungen für die
einzelnen Komponenten:
OpcManager
•
Welche Maschinen müssen über welche OPC-Server angebunden werden
•
Welche OPC-Gruppen müssen für welche Maschinen angelegt werden
•
Welche OPC-Items gehören zu welcher OPC-Gruppe
DataManager
•
Welche Abfragen müssen zum Laden der Daten ausgeführt werden
•
Welche
Dateien
MachineData
müssen
in
Abhängigkeit
welcher
Felder
der
Tabelle
von welchem Speicherort zu welchem Speicherort kopiert werden
MachineManager
•
Welche OPC-Gruppe stellt die Schnittstellengruppe zur Anfrageverwaltung dar
•
Welche OPC-Items der Schnittstellengruppe erfüllen welchen Zweck
•
Welche OPC-Gruppen werden für die verschiedenen Aufträge auf der Maschine
verwendet
•
Welche Felder der Tabelle MachineData müssen beim Übertragen der Daten auf
die Steuerung auf welche OPC-Items geschrieben werden
•
Welche Dateien von welchem Speicherort müssen vor der Übertragung zur
Steuerung wie konvertiert werden
5. Implementierung der Lösung
Seite - 56 –
Konfiguration der Komponente OpcManager
Die Komponente OpcManager wird mittels drei, zueinander in Beziehung stehenden,
Tabellen
konfiguriert.
Die
Config_OpcConnections,
Tabellen
haben
Config_OpcGroups
die
und
fest
vorgegebenen
Config_OpcItems.
Namen
Das
ER-
Diagramm in Abbildung 5.3 zeigt den Aufbau der Tabellen und deren Relationen
zueinander.
Abbildung 5.3: Konfigurationstabellen der Komponente OpcManager
Tabelle Config_OpcConnections
Die Tabelle Config_OpcConnections definiert die OPC-Server-Verbindungen für die
einzelnen Maschinen. Als Primärschlüssel wird eine eindeutige MachineId verwendet, der
auch bei der Konfiguration der Komponente MachineManager große Bedeutung zukommt.
Die Tabelle A.2 im Anhang A des Dokuments beschreibt die Felder der
Konfigurationstabelle Config_OpcConnections.
Tabelle Config_OpcGroups
Für jede MachineId werden in der Tabelle Config_OpcGroups die zugehörigen OPCGruppen mit entsprechenden Verbindungsparametern eingetragen. Als Primärschlüssel
dient eine eindeutige GroupId. Die Tabelle A.3 im Anhang A des Dokuments beschreibt
die Felder der Konfigurationstabelle Config_OpcGroups.
Tabelle Config_OpcItems
Die Tabelle Config_OpcItems enthält die OPC-Items, welche durch den OpcManager
verbunden werden sollen. Die OPC-Items können durch die GroupId eindeutig einer
Maschine zugeordnet werden. Die GroupId bildet zusammen mit der ItemId den
5. Implementierung der Lösung
Seite - 57 –
Primärschlüssel der Tabelle. Die Tabelle A.4 im Anhang A des Dokuments beschreibt die
Felder der Konfigurationstabelle Config_OpcItems.
Zur anschaulichen Erklärung der Konfigurationstabellen zeigt Abbildung 5.4 eine
Beispielkonfiguration für eine Leitrechneranwendung zur Anbindung von drei Maschinen
mit jeweils fünf Datenbereichen. Die Relationen werden von Microsoft Access als
erweiterbare Unterdatenblätter dargestellt.
Abbildung 5.4: Beispielkonfiguration der Komponente OpcManager
5. Implementierung der Lösung
Seite - 58 –
Konfiguration der Komponente DataManager
Die Komponente DataManager wird über zwei, voneinander unabhängige Tabellen
konfiguriert.
Die
Tabellen
Config_DataProcedureCalls
haben
die
fest
vorgegebenen
Namen
und Config_DataFileTransfer. Da alle Maschinen aus
dem gleichen Datenbestand bedient werden, hat die MachineId keine Bedeutung. Das ERDiagramm in Abbildung 5.5 zeigt den Aufbau der Tabellen.
Abbildung 5.5: Konfigurationstabellen der Komponente DataManager
Tabelle Config_DataProcedureCalls
In der Tabelle Config_DataProcedureCalls werden die Namen der Abfragen
eingetragen, die beim Laden der Daten von der Komponente DataManager aufgerufen
werden sollen. Die Tabelle A.5 im Anhang A des Dokuments beschreibt die Felder der
Konfigurationstabelle Config_DataProcedureCalls.
Tabelle Config_DataFileTransfer
Sollen neben den Daten aus der Produktionsdatentabelle MachineData auch Dateien auf
die Maschinensteuerungen übertragen werden, so müssen diese zuerst auf den Leitrechner
kopiert werden. In der Tabelle Config_DataFileTransfer werden die Vorgaben für das
Kopieren der Dateien eingetragen. Ist kein Dateitransfer erwünscht, müssen alle Einträge
in der Tabelle entfernt werden. Die Tabelle A.6 im Anhang A des Dokuments beschreibt
die Felder der Konfigurationstabelle Config_DataFileTransfer.
Abbildung 5.6 zeigt eine Beispielkonfiguration für eine Leitrechneranwendung mit sechs
Abfragen zur Datenaktualisierung und einem Dateitransfer von Laufwerk W: nach
Laufwerk C:. Die Namen der zu kopierenden Dateien setzen sich bei gezeigter
Konfiguration aus den Werten des Feldes NC_FILE_SWS und der Dateinamenerweiterung
.nc
zusammen.
5. Implementierung der Lösung
Abbildung 5.6: Beispielkonfiguration der Komponente DataManager
Seite - 59 –
5. Implementierung der Lösung
Seite - 60 –
Konfiguration der Komponente MachineManager
Für die Logik der Anfragebehandlung ist die Komponente MachineManager zuständig.
Die Konfiguration erfolgt mittels drei, voneinander unabhängige Tabellen. Die MachineId
aus der Konfiguration der Komponente OpcManager wird in allen Tabellen zur Zuordnung
zu einer bestimmten Maschinenverbindung verwendet. Die Tabellennamen sind fest
vorgegeben und lauten Config_MachineInterfaceItems, Config_MachineDataItems
sowie Config_MachineFileDownload. Das ER-Diagramm in Abbildung 5.7 zeigt den
Aufbau der Tabellen.
Abbildung 5.7: Konfigurationstabellen der Komponente MachineManager
Tabelle Config_MachineInterfaceItems
In der Tabelle Config_MachineInterfaceItems werden die Querverweise zwischen den
einzelnen Funktionen der Anfrageschnittstelle und den OPC-Items der bereits in der
Konfigurationstabelle Config_OpcGroups der Komponente OpcManager definierten
Interfacegruppe festgelegt. Die Funktionstexte müssen für jede angebundene Maschine
eingetragen werden. Die Tabelle A.7 im Anhang A des Dokuments beschreibt die Felder
der Konfigurationstabelle Config_MachineInterfaceItems.
Tabelle Config_MachineDataItems
In der Tabelle Config_MachineDataItems werden die Querverweise zwischen den
einzelnen OPC-Items der Datengruppen und den Feldnamen der Tabelle MachineData
festgelegt. Die Querverweise müssen durch den identischen Aufbau aller Datengruppen
einer Maschine je MachineId nur einmalig eingetragen werden. Die Tabelle A.8 im
Anhang
A
des
Dokuments
Config_MachineDataItems.
beschreibt
die
Felder
der
Konfigurationstabelle
5. Implementierung der Lösung
Seite - 61 –
Tabelle Config_MachineFileDownload
Zur Übertragung einer oder mehrerer Dateien zum Maschinensteuerungssystem müssen
diese zuerst in ein für die Steuerung lesbares Format konvertiert werden. Über die Tabelle
Config_MachineFileDownload
können die Auswahl der Datei und die entsprechende
Konvertierung parametriert werden. Wenn keine Dateiübertragungen notwendig sind,
bleibt die Tabelle leer. Die Tabelle A.9 im Anhang A des Dokuments beschreibt die Felder
der Konfigurationstabelle Config_MachineFileDownload.
Die Beispielkonfiguration in Abbildung 5.8 zeigt die oben beschrieben Tabellen in der
Darstellung von Microsoft Access. Es wurde die Anbindung von drei Maschinen
konfiguriert. Für die Maschine mit der MachineId 3 ist ein Dateidownload in der Tabelle
Config_MachineFileDownload
eingetragen.
Abbildung 5.8: Beispielkonfiguration der Komponente MachineManager
5. Implementierung der Lösung
5.4
Seite - 62 –
Komponente OpcManager
Das UML-Klassendiagramm in Abbildung 5.9 gibt einen Überblick über die Komponente
OpcManager. Leider bietet die Express Edition von Microsoft Visual C# 2005 keine
Möglichkeit zur Generierung von UML-Klassendiagrammen. Aus diesem Grund wurden
die
UML-Diagramme
der
einzelnen
Komponenten
während
der
90-tägigen
Evaluierungsphase von Microsoft Visual Studio 2005 Professional erstellt. Die Darstellung
der mittels Visual Studio generierten Klassendiagramme ist nicht konform zur UMLSpezifikation wie sie in [Pilo04] verwendet wird. Es werden für die Beschreibung der
einzelnen Komponenten in den Abschnitten 5.4, 5.5 und 5.6 nur die öffentlichen
Methoden, Attribute, Eigenschaften und Ereignisse dargestellt. Die Abbildungen
Abbildung C.1, Abbildung C.2 und Abbildung C.3 in Anhang C des Dokuments zeigen die
vollständigen Klassendiagramme der Komponenten.
Abbildung 5.9: UML-Klassendiagramm OpcManager
Wie aus dem Klassendiagramm hervorgeht implementiert die Komponente OpcManager,
wie auch alle weiteren Komponenten, das Interface IDisposable mit dessen public
Methode Dispose(). Die Funktionalität der Methode wird im Rahmen der allgemeinen
Beschreibung der öffentlichen Methoden in Anhang B, Tabelle B.1 erläutert.
5.4.1
Initialisierung
Listing 5.5 zeigt die Initialisierung der Komponente durch die Anwendung. Die
Komponente wurde wie bereits in Abschnitt 5.2.2 gezeigt mit Hilfe des Entwurfsmusters
Singleton implementiert. Das Attribut Instance liefert die Referenz auf die einzige Instanz
der Klasse zurück. Mit der öffentlichen Methode Init() wird die eigentliche
Initialisierung über die zugrunde liegenden Konfigurationstabellen gestartet. Der
5. Implementierung der Lösung
Seite - 63 –
Providername und die Verbindungszeichenfolge werden in diesem Beispiel mit der Klasse
ConfigurationManager
aus dem XML-Konfigurationsfile der Anwendung gelesen. Die
Vorteile der Unabhängigkeit vom Datenbanksystem der Konfigurationsdatenbank wurden
bereits in Abschnitt 5.2.3 anhand der Methode Init() demonstriert.
string dbProviderName
= ConfigurationManager.ConnectionStrings
["Leitrechner"].ProviderName;
string dbConnectionString = ConfigurationManager.ConnectionStrings
["Leitrechner"].ConnectionString;
// Initialisierung des OpcManagers für alle Maschinen
OpcManager opcMgr = OpcManager.Instance;
opcMgr.Init(dbProviderName, dbConnectionString);
Listing 5.5: Initialisierung der Komponente OpcManager
5.4.2
Öffentliche Methoden, Eigenschaften und Ereignisse
Die detaillierte Beschreibung der öffentlichen Methoden, Eigenschaften und Ereignisse der
Komponente OpcManager kann den Tabellen Tabelle B.1, Tabelle B.2 und Tabelle B.3 in
Anhang B des Dokuments entnommen werden.
5.5
Komponente DataManager
Die Komponente DataManager ist in ihrer Grundkonzeption dem OpcManager sehr
ähnlich. In Abbildung 5.10 ist die bereits bekannte Implementierung des Interface
IDisposable
und die Ausführung als Singleton durch das Attribut Instance ersichtlich.
Abbildung 5.10: UML-Klassendiagramm DataManager
5. Implementierung der Lösung
5.5.1
Seite - 64 –
Initialisierung
Durch die identische Konzeption der Komponente unterscheidet sich die Initialisierung in
Listing 5.6 nicht von jener der Komponente OpcManager in Listing 5.5. Zum Abschluss
wird der Client zur Benachrichtigung über das Ereignis EventDataUpdateComplete, wie
schon in Abschnitt 5.2.2 gezeigt, registriert.
string dbProviderName
= ConfigurationManager.ConnectionStrings
["Leitrechner"].ProviderName;
string dbConnectionString = ConfigurationManager.ConnectionStrings
["Leitrechner"].ConnectionString;
// Initialisierung des DataManagers für alle Maschinen
DataManager dataMgr = DataManager.Instance;
dataMgr.Init(dbProviderName, dbConnectionString);
dataMgr.StartDailyUpdate(10, 00);
// Tägliches Laden um 10:00 Uhr
dataMgr.EventDataUpdateComplete +=
new GenericEventHandler(dataMgr_DataUpdateComplete);
Listing 5.6: Initialisierung der Komponente DataManager
5.5.2
Öffentliche Methoden, Eigenschaften und Ereignisse
Die detaillierte Beschreibung der öffentlichen Methoden, Eigenschaften und Ereignisse der
Komponente DataManager kann den Tabellen Tabelle B.4, Tabelle B.5 und Tabelle B.6 in
Anhang B des Dokuments entnommen werden.
5.6
Komponente MachineManager
Die Komponente MachineManager wurde im Gegensatz zu den anderen Komponenten
nicht als Singleton implementiert. Das UML-Klassendiagramm in Abbildung 5.11 gibt
einen Überblick über die öffentlichen Methoden, Eigenschaften und Ereignisse der
Komponente. Wie erkennbar ist, verfügt die Komponente nicht über das Attribut
Instance.
Die Instanzierung erfolgt über den Konstruktor MachineManager(). Für jede
der angebundenen Maschinen übernimmt eine eigene Instanz der Komponente die Logik
der Anfragebehandlung.
5. Implementierung der Lösung
Seite - 65 –
Abbildung 5.11: UML-Klassendiagramm MachineManager
5.6.1
Initialisierung
Die Komponente MachineManager baut auf den Komponenten OpcManager und
DataManager auf. In Listing 5.7 werden zuerst die Basiskomponenten initialisiert.
Anschließend wird das über die Eigenschaft MachineData verfügbare Abbild der
Produktionsdatentabelle MachineData in zwei unterschiedlichen BindingSource Objekten
gekapselt. Die Klasse BindingSource ist eine Neuheit von ADO.NET 2.0 und ermöglicht
das Binden der über die Eigenschaft DataSource verbundenen Datenquelle an
Steuerelemente der grafischen Benutzeroberfläche. Das Durchsuchen, Filtern und Sortieren
der Datenquelle ist durch bereitgestellte Methoden sehr einfach möglich. Mit dem Objekt
machineDataBindingManuell
kann die manuelle Auswahl eines Datensatzes über ein
Steuerelement erfolgen. Der gewählte Datensatz kann anschließend mit der Methode
FixData()
fest auf der Steuerung vorgegeben werden. Die feste Vorgabe wird im Rahmen
dieses Dokumentes auch als „Fixierung“ bezeichnet. Die Maschinensteuerung wird dann
unabhängig von der Produktkennung die fixierten Daten verwenden. Das Objekt
machineDataBindingAuto
ermöglicht es dem MachineManager unabhängig von einer
möglichen manuellen Vorwahl die Tabelle nach dem Kriterium der Anfrage zu
durchsuchen. Über den Konstruktor werden am Ende des Codebeispiels die einzelnen
Objekte der Komponente MachineManager erzeugt und mit der Eigenschaft Enabled
aktiviert.
5. Implementierung der Lösung
string dbProviderName
Seite - 66 –
= ConfigurationManager.ConnectionStrings
["Leitrechner"].ProviderName;
string dbConnectionString = ConfigurationManager.ConnectionStrings
["Leitrechner"].ConnectionString;
// Initialisierung des OpcManagers für alle Maschinen
OpcManager opcMgr = OpcManager.Instance;
opcMgr.Init(dbProviderName, dbConnectionString);
// Initialisierung des DataManagers für alle Maschinen
DataManager dataMgr = DataManager.Instance;
dataMgr.Init(dbProviderName, dbConnectionString);
dataMgr.EventDataUpdateComplete +=
new GenericEventHandler(dataMgr_DataUpdateComplete);
dataMgr.StartDailyUpdate(10, 00);
// Tägliches Laden um 10:00 Uhr
// BindingSource für die manuelle Auswahl der Daten
machineDataBindingManuell = new BindingSource();
machineDataBindingManuell.DataSource = dataMgr.MachineData;
machineDataBindingManuell.MoveFirst();
// BindingSource für die automatische Auswahl der Daten durch den
// MachineManager selbst
machineDataBindingAuto = new BindingSource();
machineDataBindingAuto.DataSource = dataMgr.MachineData;
machineDataBindingAuto.MoveFirst();
// Initialisierung des MachineManager für Maschine 1
machineMgr[1] = new MachineManager(
dbProviderName,
dbConnectionString,
1,
opcMgr,
machineDataBindingManuell,
machineDataBindingAuto
);
machineMgr[1].Enabled = true; // Aktivierung der Automatikfunktion
// Initialisierung des MachineManager für Maschine 2
..
Listing 5.7: Initialisierung der Komponente MachineManager
5.6.2
Öffentliche Methoden, Eigenschaften und Ereignisse
Die detaillierte Beschreibung der öffentlichen Methoden, Eigenschaften und Ereignisse der
Komponente MachineManager kann den Tabellen Tabelle B.7, Tabelle B.8 und Tabelle
B.9 in Anhang B des Dokuments entnommen werden.
6. Anwendung der Softwarekomponenten
6.
Seite - 67 –
Anwendung der Softwarekomponenten
Zur Demonstration der Leistungsfähigkeit der im Rahmen der Diplomarbeit entwickelten
Softwarekomponenten
wurde
eine
Leitrechneranwendung
für
den
Einsatz
im
Produktionsumfeld der Fischer GmbH erstellt. Die Anwendung nutzt sämtliche
Funktionalitäten der Komponenten und wurde hinsichtlich ihrer Zuverlässigkeit eingehend
getestet.
6.1
Aufbau der Demonstrationsanwendung
Die Leitrechneranwendung wurde für die Anbindung von drei Produktionsmaschinen
konzipiert. Wie aus Abbildung 6.1 hervorgeht erfolgt die Kommunikation mit den
Maschinensteuerungssystemen bei zwei Maschinen über eine serielle RS232 Verbindung.
Eine Maschine ist via Ethernet an den Leitrechner angebunden. Die Anlagen sind mit
Steuerungssystemen der Familie 2003 und 2005 der Firma Bernecker&Rainer ausgestattet.
Der verwendete OPC-Server stammt ebenfalls von Bernecker&Rainer.
Abbildung 6.1: Umfeld der entwickelten Leitrechneranwendung
Die Leitrechneranwendung überträgt je Maschine unterschiedliche Produktionsdaten. Die
Schwabbelmaschine und die Entgratmaschine erhalten ausschließlich Parameter aus der
lokalen Anwendungsdatenbank. Für die Seitenwangenschleifmaschine werden durch die
Komponente DataManager beim Laden der Daten NC-Programme von einem
6. Anwendung der Softwarekomponenten
Seite - 68 –
Netzlaufwerk auf den Leitrechner kopiert. Die Dateien werden bei einer Anfrage durch die
Maschine konvertiert und zusätzlich zu den Produktionsparametern aus der Datenbank zur
Steuerung übertragen. Für jede Maschine wurde die Möglichkeit der Fixierung eines
bestimmten Parametersatzes realisiert. Weiters können die Daten jeder Maschine
ausgelesen und gelöscht werden. Anhang D des Dokuments enthält Screenshots der
aktiven Anwendung.
6.2
Test der Leitrechneranwendung
Um die Anwendung hinsichtlich ihrer Leistungsfähigkeit und Zuverlässigkeit testen zu
können,
wurde
eine
Testkonfiguration
mit
dem
Leitrechner
und
den
drei
Steuerungssystemen aufgebaut. Während eines Stresstests wurde mit dem .NET Memory
Profiler der Firma SciTech der Speicherbedarf der Anwendung aufgezeichnet.
Im Testaufbau verwendete Hardwarekomponenten
Industrie PC
Bernecker&Rainer Provit 5000
Schwabbelmaschine
Prozessor:
Pentium III – 850 Mhz
Arbeitsspeicher:
512 MB
Betriebssystem:
Windows 2000 Professional SP4
Bernecker&Rainer System 2003
Entgratmaschine
CPU: CP476.60-1
Bernecker&Rainer System 2003
Seitenwangenschleifmaschine
CPU: CP476.60-1
Bernecker&Rainer System 2003
CPU: CP260.60-1
Tabelle 6.1: Verwendete Hardware im Testaufbau
Ergebnisse des Stresstests
Die Software der Steuerungssysteme wurde derart modifiziert, dass jede Steuerung in
einem Intervall von 3 Sekunden eine Anfrage an den Leitrechner generiert. Die
unterschiedlichen Zeiten der Datenübertragung sind in diesem Intervall nicht enthalten.
Aus diesem Grund ergeben sich Verschiebungen der Anfragezeitpunkte der einzelnen
Steuerungen zueinander. Die theoretische Gleichzeitigkeit von zwei oder mehreren
Anfragen wurde somit durch die Testkonfiguration berücksichtigt. Während des Stresstests
wurden in einem Zeitraum von ca. 23 Stunden insgesamt 55372 Anfragen erfolgreich
6. Anwendung der Softwarekomponenten
Seite - 69 –
abgearbeitet. Dies entspricht mehr als der kalkulierten Jahresleistung von ca. 55000
Anfragen1. Parallel zur Bedienung der Anfragen wurden alle 10 Minuten die
Produktionsdaten durch die Anwendung neu geladen.
Provozierte Fehlersituationen
Zur Bewertung der Zuverlässigkeit der Leitrechneranwendung wurden während des
Stresstests einige Fehlersituationen provoziert. Das Unterbrechen der Netzwerkverbindung
hatte den Ausfall der Kommunikation mit der über Ethernet angebundenen Maschine zur
Folge. Ein Zugriff auf den Datenbankserver sowie auf das Netzlaufwerk mit den NCProgrammen war ebenfalls nicht mehr möglich. Die Anwendung bediente in diesem
Zustand die Anfragen der beiden seriell angebundenen Maschinen erfolgreich weiter. Das
Fehlschlagen des Ladens der Daten beeinträchtigte die Anwendung nicht. Nach dem
Wiederherstellen
der
Netzwerkverbindung
wurde
die
Kommunikation
zur
Seitenwangenschleifmaschine wieder aufgebaut und die Anfragebearbeitung fortgesetzt.
In Einzeltests wurden spezielle Datenfehler simuliert. Es wurden beispielsweise Anfragen
nach nicht vorhandenen Datensätzen abgesetzt. Zusätzlich wurden Null-Werte in die
Datenfelder der Datensätze eingetragen. Die Anwendung zeigte auch in diesen Tests die
geforderte Fehlertoleranz.
1
365 Tage x 50 Lose/Tag x 3 Maschinen = 54750 Anfragen / Jahr
6. Anwendung der Softwarekomponenten
Seite - 70 –
Aufzeichnung der Speichernutzung
Aus der Aufzeichnung des Speicherbedarfs der Anwendung ist ersichtlich, dass die
Speichernutzung während des Testlaufs konstant blieb. Temporäre Spitzen, die durch das
Laden der Auftragsdaten bedingt sind, werden beim Lauf des .NET-Garbage-Collectors
wieder freigegeben. Abbildung 6.2 zeigt den Speicherverbrauch in der Darstellungsweise
des SciTech .NET Memory Profiler.
Abbildung 6.2: Aufzeichnung des Speicherbedarfs der Leitrechneranwendung
6.3
Zusammenfassung
Die Leitrechneranwendung und ihre Basiskomponenten haben in den Punkten
Zuverlässigkeit und Performance die Anforderungen der Fischer GmbH zur vollsten
Zufriedenheit erfüllt. Die Komponenten wurden durch die Fischer GmbH zur Verwendung
in zukünftigen Projekten freigegeben und vorgeschrieben.
7. Ausblick
7.
Seite - 71 –
Ausblick
Mit der Anwendung der Softwarekomponenten als Basis einer produktiv eingesetzten
Leitrechneranwendung wurden die von der Fischer GmbH gesetzten Projektziele in vollen
Umfang erreicht. Während der Erstellung der Demonstrationsanwendung hatten die
Softwareentwickler der Fischer GmbH Gelegenheit die erstellten Komponenten und deren
Handhabung
kennen
zu
lernen.
In
einer
kritischen
Diskussion
wurden
das
Weiterentwicklungspotential der bestehenden Komponenten sowie die Erstellung neuer
Softwarebausteine besprochen. Zusammenfassend können folgende Punkte aus der
Ergebnisbesprechung als konkrete Ansatzpunkte für gezielte Verbesserungen und
Erweiterungen genannt werden.
Reduzierung des Konfigurationsaufwandes durch (Teil-)Automatisierung
Der Arbeitsaufwand für die Konfigurationserstellung kann bei mehreren angebundenen
Maschinen nicht mehr unerheblich sein. Ein Großteil der Arbeitsleistung ist hierbei für die
Konfiguration der Komponente OpcManager zu erbringen. Aus diesem Grund wurden
Möglichkeiten
zur
weitgehend
automatisierten
Config_OpcConnections, Config_OpcGroups
Befüllung
der
Tabellen
und Config_OpcItems besprochen. Die
angestrebte Lösung sieht vor, ausgehend von der Konfiguration des OPC-Servers, die
Konfigurationstabellen
mit
Daten
zu
füllen.
Eine
weitere
Detaillierung
der
Aufgabenstellung ist noch nicht erfolgt. Leider verfügen OPC-Server verschiedener
Hersteller in der Regel über kein einheitliches Exportformat. Somit ist eine Anpassung der
Applikation oder Routine zur Konfigurationsunterstützung an jeden der häufig
verwendeten Server notwendig. Durch die überwiegende Nutzung des OPC-Servers der
Firma Bernecker&Rainer stellt diese Gegebenheit kein Problem für die Fischer GmbH dar.
In Einzelfällen kann die Konfiguration der Anbindung der vom Standard abweichenden
Server auch in Zukunft manuell erfolgen.
Erstellung von GUI Komponenten
Trotz der spezifischen Ausrichtung der Leitrechneranwendungen auf eine bestimmte
Anlagenkombination werden in den grafischen Benutzeroberflächen häufig sehr ähnliche
Elemente verwendet. Als Beispiel können verschiedenste Statusanzeigen genannt werden.
7. Ausblick
Seite - 72 –
Die zukünftige Entwicklung von standardisierten grafischen Komponenten stellt einen
weiteren Schritt zur Effizienzsteigerung der Anwendungsentwicklung dar.
Internationalisierung
Die Fischer GmbH verfügt über einen zweiten Produktionsstandort in der Ukraine. Eine
Leitrechneranwendung muss für den Einsatz an diesem Standort die Möglichkeit zur
Sprachumschaltung besitzen. Derzeit steht noch nicht fest, ob zu diesem Zweck eine neue
Komponente entwickelt werden muss. Die Thematik wird im Rahmen des ersten,
konkreten Anwendungsfalles näher betrachtet.
Schlussbemerkung
Es kann festgestellt werden, dass an den im Rahmen der Diplomarbeit entwickelten
Softwarekomponenten mit dem Auftreten bisher noch unbekannter Anforderungen
Modifikationen notwendig sein können. Durch die Akzeptanz der entwickelten
Komponenten auf Seiten der Fischer GmbH wird der Fokus für weiterführende
Optimierungen auf das Umfeld der Komponenten bzw. die Leitrechneranwendungen selbst
gelegt.
Literaturverzeichnis
Seite - 73 –
Literaturverzeichnis
[Balz01]
Helmut Balzert (2001), Lehrbuch der Software-Technik, 2. Auflage,
Spektrum Akademischer Verlag, Heidelberg-Berlin
[Bern06]
Bernecker & Rainer GmbH (2006), Produktkatalog 2006, Eggelsberg
[Gamm97]
Erich Gamma et al. (1997), Design Patterns. Elements of Reusable ObjectOriented Software, Addison-Wesley Professional, Boston
[Hami03]
Bill Hamilton, Matthew MacDonald (2003), ADO.NET in a NutShell, First
Edition, O’Reilly Media, Sebastopol
[Iwan05]
Frank Iwanitz (2005), OPC, 3. Auflage, Hüthig Verlag, Heidelberg
[Kemp01]
Alfons Kemper, André Eickler (2001), Datenbanksysteme – Eine Einführung,
4. Auflage, Oldenbourg Verlag, München
[Klei03]
Max Kleiner et al. (2003), Patterns Konkret, Software & Support Verlag,
Frankfurt
[Loos01]
Peter Loos (2001), Go to COM, 1. Auflage, Addison-Wesley Verlag,
München
[Löwy05]
Juval Löwy (2005), Programming .NET Components, Second Edition,
O’Reilly Media, Sebastopol
[Micr94a]
Microsoft Corporation (1994), OLE 2 Programmer’s Reference, Volume 1,
Microsoft Press International, Redmond
[Micr94b]
Microsoft Corporation (1994), OLE 2 Programmer’s Reference, Volume 2,
Microsoft Press International, Redmond
[Micr06]
Microsoft Corporation (2006), .NET Framework Developer’s Guide Developing Components,
http://msdn.microsoft.com/library/default.asp?url=/library/enus/cpguide/html/cpconcomponentprogrammingessentials.asp (08.05.2006)
[Pilo04]
Dan Pilone (2004), UML kurz & gut, 1. Auflage, O’Reilly Verlag, Köln
[Prat01]
Steven Pratschner (2001), Simplifying Deployment and Solving DLL Hell
with the .NET Framework,
http://msdn.microsoft.com/library/default.asp?url=/library/enus/dndotnet/html/dplywithnet.asp (08.05.2006)
[Schw05]
Holger Schwichtenberg (2005), Microsoft .NET 2.0 Crashkurs, Microsoft
Press Deutschland, Unterschleissheim
Literaturverzeichnis
[Seit03]
Seite - 74 –
Matthias Seitz (2003), Speicherprogrammierbare Steuerungen, Hanser
Fachbuchverlag, München
Abkürzungsverzeichnis
Abkürzungsverzeichnis
API
Application Programming Interface
CAD
Computer Aided Design
CLR
Common Language Runtime
CLS
Common Language Specification
CLSID
Class Identifier
COM
Component Object Model
CTS
Common Type System
DB
Datenbank
DBMS
Datenbankmanagement
DBS
Datenbanksysteme
DCE
Distributed Computing Enviroment
DCOM
Distributed Component Object Model
DD
Data Dictionary
DDE
Dynamic Data Exchange
DDL
Data Definition Language
DLL
Dynamic Link Library
DML
Data Manipulation Language
ER
Entity Relationship
ERP
Enterprise Ressource Planning
FCL
.NET Framework Class Library
FK
Foreign Key (Fremdschlüssel)
GUI
Graphical User Interface
GUID
Global Unique Identifier
HMI
Human Machine Interface
HP-UX
Hewlett Packard UNIX
IDE
Integrated Development Enviroment
IDL
Interface Definition Language
IID
Interface Identifier
J2EE
Java 2 Enterprise Edition
JDBC
Java Database Connectivity
JIT
Just-in-Time Compiler
Seite - 75 –
Abkürzungsverzeichnis
JRE
Java Runtime Enviroment
MMA
Multi Module Assembly (.NET)
MSIL
Microsoft Intermediate Language
NC
Numeric Control
ODBS
Objektorientierte Datenbanksysteme
OLE
Object Linking and Embedding
OPC
Openess, Productivity and Collaboration
OLE for Process Control
ORDBS
Objektrelationale Datenbanksysteme
ORPC
Object Remote Procedure Call
OSF
Open Software Foundation
PK
Primary Key (Primärschlüssel)
PLC
Programmable Logic Controller
RDBS
Relationale Datenbanksysteme
RPC
Remote Procedure Call
SMA
Single Module Assembly (.NET)
SPS
Speicherprogrammierbare Steuerung
SQL
Structured Query Language
SWT
Standard Widget Toolkit
UML
Unified Modeling Language
VM
Virtual Machine (Java)
VPS
Verbindungsprogrammierte Steuerung
XML
eXtensible Markup Language
Seite - 76 –
Anhang
Seite - 77 –
Anhang
A.
Beschreibung der Daten- und Konfigurationstabellen
Datentabelle MachineData
Feldname
CODE1
Typ
Text
Bedeutung
Erstes Suchfeld für die Produktkennung nach der
Datenanfrage eines Maschinensteuerungssystems
CODE2
Text
Zweites Suchfeld für die Produktkennung nach der
Datenanfrage eines Maschinensteuerungssystems
MACHINEKEY Zahl
Eindeutige ID des Datensatzes innerhalb der Tabelle
(Autowert)
DATAVALID
Ja/Nein
Kennzeichnung eines vollständigen und gültigen Datensatzes
LAST_UPDATE Datum/Zeit Zeitpunkt der letzten Aktualisierung.
(Löschkriterium für die Bereinigung der Tabelle)
Tabelle A.1: Zwingend erforderliche Felder der Tabelle MachineData
Konfigurationstabellen der Komponente OpcManager
Feldname
MachineId
OpcProgId
Typ
Zahl
Text
Remark
Text
Bedeutung
Eindeutiger Identifier der Maschinenverbindung
Program Identifier des zu verwendenden OPC-Servers.
Die OpcProgId ist für jeden Server eindeutig und kann aus
der Dokumentation des Herstellers entnommen werden.
Beispiel für B&R PVI OPC-Server: „B&R.PviOPC.2“
Kommentar (Für die Komponente nicht relevant)
Tabelle A.2: Felder der Tabelle Config_OpcConnections
Feldname
GroupId
MachineId
Typ
Zahl
Zahl
Name
UpdateRate
Text
Zahl
DeadBand
Zahl
InterfaceGroup
Ja/Nein
Bedeutung
Eindeutiger Identifier der OPC-Gruppe
Fremdschlüssel für die eindeutige Zuordnung der Gruppe
zu einer Maschine
Beliebiger Text als Name der Gruppe
Interner Aktualisierungsintervall der Gruppe im OPCServer in Millisekunden
Mindestabweichung vom aktuellen Wert in Prozent, damit
eine Wertänderung vom OPC-Server gemeldet wird.
Legt fest, ob die Gruppe von der Komponente
MachineManager als Schnittstellengruppe der Maschine
verwendet werden soll. Es kann je Maschine nur eine
Schnittstellengruppe definiert werden
Anhang
Seite - 78 –
DataGroup
Ja/Nein
DataGroupIx
Remark
Zahl
Text
Legt fest, ob die Gruppe von der Komponente
MachineManager als Datengruppe der Maschine verwendet
werden soll. Es können je Maschine beliebig viele
Datengruppen definiert werden
Eindeutiger Index der Datengruppe
Kommentar (Für die Komponente nicht relevant)
Tabelle A.3: Felder der Tabelle Config_OpcGroups
Feldname
ItemId
Typ
Zahl
GroupId
Name
Text
Text
Remark
Text
Bedeutung
Eindeutiger Identifier des OPC-Items innerhalb der OPCGruppe.
Innerhalb der verschiedenen Datengruppen müssen die
Item-Identifier für gleichwertige Datenvariablen identisch
sein.
Identifier der OPC-Gruppe
Name der Steuerungsvariable im Namensraum des OPCServers
Kommentar (Für die Komponente nicht relevant)
Tabelle A.4: Felder der Tabelle Config_OpcItems
Konfigurationstabellen der Komponente DataManager
Feldname
ProcedureId
ProcedureName
Typ
Zahl
Bedeutung
Eindeutiger Identifier der Stored Procedure
Text
Die Abfragen werden in aufsteigender Reihenfolge der ID
verarbeitet.
Name der Abfrage
Tabelle A.5: Felder der Tabelle Config_DataProcedureCalls
Feldname
TransferId
FileDataField
Typ
Zahl
Text
Extension
SourceDir
TargetDir
Remark
Text
Text
Text
Text
Bedeutung
Eindeutiger Identifier des Filetransfers
Feldname der Produktionstabelle MachineData in dem die
Namen der zu kopierenden Dateien eingetragen sind.
Dateinamenerweiterung der Dateien
Quellverzeichnis der Dateien
Zielverzeichnis für die Kopien der Dateien
Kommentar (Für die Komponente nicht relevant)
Tabelle A.6: Felder der Tabelle Config_DataFileTransfer
Anhang
Seite - 79 –
Konfigurationstabellen der Komponente MachineManager
Feldname
MachineId
Function
Typ
Zahl
Text
Bedeutung
Eindeutiger Identifier der Maschine
Funktion
der
Schnittstellenvariablen
für
die
Anfragebehandlung. Die Namen der einzelnen Funktionen
sind vorgegeben.
PLC_REQUEST (SPS->PC)
Variable zur Signalisierung der Anfrage von der Steuerung
PLC_CODE (SPS->PC)
Suchkriterium der Anfrage
PLC_USED_DATA_INDEX (SPS->PC)
Aktuell
belegte
und
somit
nicht
Datengruppenindizes.
verfügbare
IPC_LOCK_DATA (PC->SPS)
Variable zum Sperren der Daten auf der Steuerung während
des Schreibvorganges der Daten
IPC_NO_DATA (PC->SPS)
Meldevariable an die Steuerung, dass keine Daten für das
Suchkriterium am Leitrechner verfügbar sind.
IPC_FIX_DATA (PC->SPS)
Variable zur festen Vorgabe einer Datengruppe auf der
Steuerung. Die Maschine verwendet bei einer Fixierung
immer die vorgegeben Daten und stellt keine Anfragen an
die Leitrechneranwendung.
IPC_FIX_DATA_INDEX (PC->SPS)
Index der fixierten Datengruppe
OPC_DOWNLOAD
OPC-Server internes Item zur Übertragung von Dateien auf
die Steuerung. Ein Eintrag ist nur notwendig, wenn in der
Tabelle Config_MachineFileDownload ein Dateidownload
konfiguriert ist.
ItemId
Zahl
Remark
Text
Item-Identifier des zugeordneten OPC-Items innerhalb der
Schnittstellengruppe der Maschine
Kommentar (Für die Komponente nicht relevant)
Tabelle A.7: Felder der Tabelle Config_MachineInterfaceItems
Anhang
Seite - 80 –
Feldname
MachineId
ItemId
Typ
Zahl
Zahl
DataField
Text
Remark
Text
Bedeutung
Eindeutiger Identifier der Maschine.
Item-Identifier des entsprechenden OPC-Items innerhalb
der Datengruppe
Name des Datenfeldes der Tabelle MachineData, deren
Wert übertragen werden soll
Kommentar (Für die Komponente nicht relevant)
Tabelle A.8: Felder der Tabelle Config_MachineDataItems
Feldname
MachineId
FileDataField
Typ
Zahl
Text
SourceDir
ConversionTool
FileExtension
PlcExtension
Remark
Text
Text
Text
Text
Text
Bedeutung
Eindeutiger Identifier der Maschine.
Name des Datenfeldes der Tabelle MachineData, deren
Wert den Dateinamen enthält
Quellverzeichnis der ursprünglichen Datei
Kommando zum Aufruf des Konvertierungstools
Dateinamenerweiterung der ursprünglichen Datei
Dateinamenerweiterung der konvertierten Datei
Kommentar (Für die Komponente nicht relevant)
Tabelle A.9: Felder der Tabelle Config_MachineFileDownload
Anhang
B.
Seite - 81 –
Öffentliche Methoden, Eigenschaften und Ereignisse der Komponenten
Komponente OpcManager
Init()
Funktion Mit der Methode Init() werden die Konfigurationstabellen der
Komponente ausgelesen und die entsprechenden OPC-Server,
OPC-Gruppen und OPC-Item-Objekte erzeugt.
Übergabeparameter string dbProviderName
Providername der Konfigurationsdatenbank
string dbConnectionString
Verbindungszeichenfolge der Konfigurationsdatenbank
Rückgabewert GetOPCServer()
Funktion Die Methode GetOPCServer() liefert das OPC-Server-Objekt
für eine bestimmte MachineId zurück. Über das Server-Objekt
kann in der Anwendung auf alle Gruppen und Item-Objekte
zugegriffen werden.
Übergabeparameter int machineIndex
Identifier der gewüschten Maschinenverbindung
Rückgabetyp Metadynamics OPCServer
Dispose()
Funktion Da durch die OPC-Client-Komponenten im Hintergrund COM
zum Zugriff auf den OPC-Server verwendet wird, kann der
.NET-Garbage-Collector
die
Verwaltung
sämtlicher
Speicherressourcen nicht übernehmen. Die Methode Dispose()
gibt den Speicher aller verwendeten Ressourcen explizit frei. Die
Methode sollte vor dem Beenden der Anwendung aufgerufen
werden.
Übergabeparameter Rückgabewert Tabelle B.1: Öffentliche Methoden der Komponente OpcManager
Anhang
Seite - 82 –
IsInitialized
Funktion Nachdem mit der Methode Init() die Initialisierung der
Komponente durchgeführt wurde, wird die Eigenschaft
IsInitialized
auf true gesetzt. Eine neuerliche
Initialisierung über die Init() Methode wird durch
IsInitialized==true verhindert.
Datentyp bool
Zugriff Lesezugriff
Tabelle B.2: Öffentliche Eigenschaften der Komponente OpcManager
EventInitComplete
Funktion Zusätzlich zum Setzen der IsInitialized Eigenschaft wird
nach der Initialisierung der Komponente mit der Methode
Init() das Ereignis EventInitComplete abgesetzt. Die
Methode Init() kann somit auch asynchron aufgerufen
werden.
Rückgabewerte bool IsInitalized
Tabelle B.3: Öffentliche Ereignisse der Komponente OpcManager
Anhang
Seite - 83 –
Komponente DataManager
Init()
Funktion Mit der Methode Init() wird der Inhalt der Tabelle
MachineData in ein DataTable Objekt eingelesen. Die Daten
sind über die Eigenschaft MachineData verfügbar.
Übergabeparameter string dbProviderName
Providername der Konfigurationsdatenbank
string dbConnectionString
Verbindungszeichenfolge der Konfigurationsdatenbank
Rückgabetyp LoadData()
Funktion Mit dem Aufruf der Methode LoadData() wird das Laden der
Daten gestartet. Es werden zuerst die Abfragen aus der Tabelle
Config_DataProcedureCalls
gestartet. Nachdem alle
Prozeduren ausgeführt wurden, sind die Einträge der Tabelle
MachineData aktuell und das Kopieren von Dateien laut der
Konfiguration in der Tabelle Config_DataFileTransfer wird
gestartet.
Je nach Komplexität der Abfragen und der Anzahl der zu
kopierenden Dateien kann das Laden der Daten längere Zeit in
Anspruch nehmen. Aus diesem Grund wird beim Aufruf der
Methode ein eigener Thread für die Abarbeitung gestartet. Nach
Abschluss
der
Operation
wird
das
Ereignis
EventDataUpdateComplete abgesetzt.
Übergabeparameter Rückgabetyp StartDailyUpdate()
Funktion In manchen Anwendungsfällen soll das Laden der Daten täglich
zu einer bestimmten Zeit automatisch erfolgen. Mit der Methode
StartDailyUpdate() wird diese Funktion aktiviert. Intern wird
die Methode LoadData() zum definierten Zeitpunkt aufgerufen.
Übergabeparameter int hour
Stunde für automatisches Laden der Daten
int minute
Minute für automatisches Laden der Daten
Rückgabetyp -
Anhang
Seite - 84 –
StopDailyUpdate()
Funktion Die Methode StopDailyUpdate() deaktiviert das automatische
Laden der Daten.
Übergabeparameter Rückgabetyp Dispose()
Funktion Die Methode Dispose() gibt den Speicher aller verwendeten
Ressourcen explizit frei. Die Methode sollte vor dem Beenden
der Anwendung aufgerufen werden.
Übergabeparameter Rückgabetyp Tabelle B.4: Öffentliche Methoden der Komponente DataManager
IsInitialized
Funktion Nachdem mit der Methode Init() die Initialisierung der
Komponente durchgeführt wurde, wird die Eigenschaft
IsInitialized
auf true gesetzt. Eine neuerliche
Initialisierung über die Init() Methode wird durch
IsInitialized==true verhindert.
Datentyp bool
Zugriff Lesezugriff
MachineData
Funktion Über die Eigenschaft MachineData wird ein DataTable Objekt,
welches den Inhalt der Tabelle MachineData der
Anwendungsdatenbank darstellt zur Verfügung gestellt.
Datentyp Datatable
Zugriff Lesezugriff
Tabelle B.5: Öffentliche Eigenschaften der Komponente DataManager
Anhang
Seite - 85 –
EventInitComplete
Funktion Zusätzlich zum Setzen der IsInitialized Eigenschaft
wird nach der Initialisierung der Komponente mit der
Methode Init() das Ereignis EventInitComplete
abgesetzt. Die Methode Init() kann somit auch
asynchron aufgerufen werden.
Rückgabewerte bool IsInitalized
EventDataUpdateComplete
Funktion Das Laden der Daten wird in einem eigenen Thread
durchgeführt. Das Ereignis EventDataUpdateComplete
benachrichtigt die Anwendung über den Abschluss der
LoadData() Methode.
Rückgabewerte Tabelle B.6: Öffentliche Ereignisse der Komponente DataManager
Anhang
Seite - 86 –
Komponente MachineManager
MachineManager()
Funktion Der Konstruktor der Komponente MachineManager instanziert
ein Objekt der Klasse und übernimmt die Initialisierung gemäß
den Konfigurationstabellen.
Übergabeparameter string dbProviderName
Providername der Konfigurationsdatenbank
string dbConnectionString
Verbindungszeichenfolge der Konfigurationsdatenbank
int machineId
Eindeutiger Identifier der Maschine
OpcManager opcMgr
Objekt der Komponente OpcManager
BindingSource bindingManual
Gekapselte Produktionsdatentabelle für die Weitergabe
einer manuellen Datenauswahl an das Objekt.
BindingSource bindingAuto
Gekapselte Produktionsdatentabelle zur automatischen
Suche nach den Anfragekriterien.
FixData()
Funktion Mit der Methode FixData() kann der über bindingManual
gewählte Datensatz auf der Steuerung fixiert werden. Die Daten
werden zur Steuerung geschrieben und mittels den
Interfacevariablen IPC_FIX_DATA und IPC_FIX_DATA_INDEX
fest vorgegeben.
Übergabeparameter string infoDataField
Nach dem Aufruf der Methode FixData() wird ein
Bestätigungsdialog angezeigt. Mit dem Parameter
infoDataField
kann das Feld der Tabelle
MachineData,
welches im Dialog angezeigt
werden soll, vorgegeben werden.
Rückgabetyp -
Anhang
Seite - 87 –
UnFixData()
Funktion Die Methode UnFixData() hebt die Fixierung auf
Übergabeparameter string infoDataField
Nach dem Aufruf der Methode UnFixData() wird ein
Bestätigungsdialog angezeigt. Mit dem Parameter
infoDataField
kann das Feld der Tabelle
MachineData,
welches im Dialog angezeigt
werden soll, vorgegeben werden.
Rückgabetyp GetPlcData()
Funktion Auf der Maschinensteuerung werden mehrere Sätze von
Produktionsdaten gehalten. Die Methode GetPlcData() liest
diese von der Steuerung und trägt die entsprechenden Datensätze
in die Tabelle der Eigenschaft DataInMachine ein.
Übergabeparameter Rückgabetyp ClearPlcData()
Funktion Die Methode ClearPlcData() löscht die Datensätze auf der
Steuerung.
Übergabeparameter Rückgabetyp Dispose()
Funktion Die Methode Dispose() gibt den Speicher aller verwendeten
Ressourcen explizit frei. Die Methode sollte vor dem Beenden
der Anwendung aufgerufen werden.
Übergabeparameter Rückgabetyp Tabelle B.7: Öffentliche Methoden der Komponente MachineManager
Anhang
Seite - 88 –
Enabled
Funktion Die automatische Anfragebehandlung des MachineManager
kann über die Eigenschaft Enabled aktiviert bzw. deaktiviert
werden.
Datentyp bool
Zugriff Lese- und Schreibzugriff
FixedData
Funktion Sollte ein Datensatz fixiert worden sein, steht dieser über die
Eigenschaft FixedData zur Verfügung.
Datentyp DataRow
Zugriff Lesezugriff
DataInMachine
Funktion Nach dem Aufruf der Methode GetPlcData() sind die
Datensätze, für welche Daten auf der Steuerung vorhanden sind,
über diese Eigenschaft verfügbar.
Datentyp DataTable
Zugriff Lesezugriff
Tabelle B.8: Öffentliche Eigenschaften der Komponente MachineManager
Anhang
Seite - 89 –
EventBeforeWrite
Funktion Das Event EventBeforeWrite wird abgesetzt, bevor die Daten
zur Steuerung geschrieben werden.
Rückgabewerte int MachineId
Eindeutiger Identifier der Maschine
DataRow Datensatz
Datensatz, der für das Schreiben der Daten verwendet
wird
EventAfterWrite
Funktion Das Event EventAfterWrite wird abgesetzt, nachdem die
Daten zur Steuerung geschrieben wurden.
Rückgabewerte int MachineId
Eindeutiger Identifier der Maschine
DataRow Datensatz
Datensatz, der für das Schreiben der Daten verwendet
wurde
Tabelle B.9: Öffentliche Ereignisse der Komponente MachineManager
Anhang
C.
Seite - 90 –
Vollständige UML-Klassendiagramme
OpcManager
Abbildung C.1: UML-Klassendiagramm OpcManager
Anhang
Seite - 91 –
DataManager
Abbildung C.2: UML-Klassendiagramm DataManager
Anhang
Seite - 92 –
MachineManager
Abbildung C.3: UML-Klassendiagramm MachineManager
Anhang
D.
Seite - 93 –
Screenshots der Demonstrationsanwendung
Anlagenübersicht
Abbildung D.1: Demonstrationsanwendung – Anlagenübersicht
In der Anlagenübersicht werden die aktuellen Betriebszustände der angebundenen
Maschinen anschaulich dargestellt. Der aktuelle Barcode sowie die Auftragsnummer des
aktuell bearbeiteten Auftrages sind im unteren Teil des Dialogs ersichtlich.
Anhang
Seite - 94 –
Übersicht Schwabbelmaschine
Abbildung D.2: Demonstrationsanwendung – Übersicht Schwabbelmaschine
In den Übersichtsdialogen der einzelnen Maschinen werden die aus der Anlagenübersicht
bekannten Maschinenzustände nochmals dargestellt. Zusätzlich werden detaillierte
Informationen zum aktuell von der Maschine verwendeten Auftrag angezeigt. Die
Fixierung eines Auftrags ist über Buttons in den entsprechenden Maschinenübersichten
möglich.
Anhang
Seite - 95 –
Maschinenübersicht „Entgraten“
Abbildung D.3: Demonstrationsanwendung – Übersicht Entgratmaschine
Die Maschinenübersicht der Entgratmaschine ist analog zu jener der Schwabbelmaschine
aufgebaut.
Anhang
Seite - 96 –
Maschinenübersicht „Seitenwangenschleifen“
Abbildung D.4: Demonstrationsanwendung – Übersicht Schleifmaschine
Die Maschinenübersicht der Schleifmaschine ist analog zu jener der Schwabbelmaschine
aufgebaut.
Anhang
Seite - 97 –
Auftragsübersicht
Abbildung D.5: Demonstrationsanwendung – Auftragsübersicht
Die Auftragsübersicht ermöglicht die Vorwahl eines Auftrages zur Fixierung auf den
Maschinen. Mittels Filterfunktionen kann der Bediener die Auswahl einschränken und
rasch zum gewünschten Auftrag gelangen.
Anhang
Seite - 98 –
Auftragsdetails
Abbildung D.6: Demonstrationsanwendung – Auftragsdetails
Im Dialog Auftragsdetails werden die für die Maschinen relevanten Daten, des in der
Auftragsübersicht selektierten Datensatzes, angezeigt. Die Anschaulichkeit wird gegenüber
der Tabellendarstellung deutlich gesteigert.
Anhang
Seite - 99 –
Aufträge in Maschinen
Abbildung D.7: Demonstrationsanwendung – Aufträge in Maschinen
Im oben gezeigten Dialog können die aktuell auf den Maschinen vorhandenen Aufträge
ausgelesen und angezeigt werden. Zusätzlich besteht die Möglichkeit die Datenbereiche
der einzelnen Steuerungssysteme zu initialisieren.