Fachhochschule Kaiserslautern Fachbereich Informatik und Mikrosystemtechnik Studiengang „Angewandte Informatik“

Dokumentation Prozesssteuerungs- und Automatisierungssysteme von

Buchholz Matthias (854859) Federau Benjamin (854627) Molter Christian (854436) Platz Thorsten (853143) 25.01.2007

Betreuer: Prof. Dr. Uwe Tronnier

Seite 2 von 49

Ehrenwörtliche Erklärung Hiermit erklären wir, Buchholz Matthias, Federau Benjamin, Molter Christian und Platz Thorsten, Ehrenwörtlich, dass wir diese Arbeit mit dem Titel: „Dokumentation Prozesssteuerungs- und Automatisierungssysteme“ selbstständig und ohne fremde Hilfe angefertigt haben und keine anderen als in der Abhandlung angegebenen Hilfen benutzt haben, dass wir die Übernahme wörtlicher Zitate aus der Literatur sowie die Verwendung der Gedanken anderer Autoren an den entsprechenden Stellen innerhalb der Arbeit gekennzeichnet haben. Uns ist bewusst, dass eine falsche Erklärung rechtliche Folgen haben kann.

Zweibrücken, 25.01.2007

Seite 3 von 49

[ausgeschriebene Unterschriften]

Seite 4 von 49

Inhaltsverzeichnis 1 Einleitung.......................................................................................................................... 9 1.1 Motivation.................................................................................................................. 9 1.2 Aufgabenstellung im Detail........................................................................................ 9 1.3 Produktivumgebung.................................................................................................. 9 1.3.1 Das Modell......................................................................................................... 9 1.3.2 Zielsystem........................................................................................................ 11 1.3.3 Materialtypen.................................................................................................. 11 1.3.3.1 Holzblöcke................................................................................................ 11 1.3.3.2 Container.................................................................................................. 11 1.3.4 Lagerplätze...................................................................................................... 11 1.3.4.1 Hochregallager......................................................................................... 12 1.3.4.2 Paletten..................................................................................................... 12 1.3.4.3 Kettenförderer........................................................................................... 13 1.3.4.4 Blocklager................................................................................................. 13 1.3.4.5 Förderbänder............................................................................................ 13 1.4 Gliederung der Arbeit.............................................................................................. 14 1.5 Zeitlicher Ablauf...................................................................................................... 14 2 Grob-Design der gewählten Lösung............................................................................... 16 3 Modellierung und Realisierung....................................................................................... 18 3.1 Datenbank............................................................................................................... 18 3.1.1 ER-Diagramm.................................................................................................. 19 3.2 Klassendiagramm................................................................................................... 20 3.3 Lagerverwaltung...................................................................................................... 20 3.3.1 Klasse CLagerverwaltung................................................................................ 20 3.3.2 Klasse CLager................................................................................................. 21 3.3.3 Klasse CLHM_Palette...................................................................................... 21 3.3.4 Klasse CLHM_Container.................................................................................. 22 3.3.5 Klasse CMaterial.............................................................................................. 22 3.3.6 Lagerschnittstellen........................................................................................... 22 3.3.6.1 Jobmanager.............................................................................................. 22 3.3.6.2 Auftragsverwaltung................................................................................... 23 3.4 Auftragsverwaltung................................................................................................. 23 3.4.1 Auftragsklassen............................................................................................... 24 3.4.1.1 CProduktionsAuftrag, CKommisionierauftrag, CAuslagerungsauftrag......24 3.4.1.2 CFertigungsauftrag................................................................................... 24 3.5 Jobverwaltung und Generierung............................................................................. 24 3.5.1 CJobManager.................................................................................................. 25 3.5.1.1 Shared Resources.................................................................................... 27 3.5.1.2 ManageJobs............................................................................................. 27 3.5.1.3 RequestJob............................................................................................... 28 3.5.1.4 ReportJob................................................................................................. 29 3.5.2 Job Beschreibung............................................................................................ 30 3.5.3 CJobFactory..................................................................................................... 32 3.5.3.1 CreateJobs............................................................................................... 32 3.5.3.2 CreateProductionJobs.............................................................................. 32 3.5.3.3 CreateRejectionJobs................................................................................ 33 Seite 5 von 49

3.5.3.4 CreatePickingJobs.................................................................................... 33 3.6 SPS Kommunikation............................................................................................... 36 3.6.1 Kommunikation über den Feldbus via Handshakeprotokoll............................. 36 3.6.2 Kapselung des Feldbus durch CAktor und CSensor........................................ 37 3.6.3 Die SPS-Klassen............................................................................................. 37 3.6.3.1 SPS-Basisklasse (ASPSBase)................................................................. 37 3.6.3.1.1 Handshakeimplementierung.............................................................. 38 3.6.3.1.2 Bus-Polling........................................................................................ 39 3.6.3.2 CSPS1 - Die Klasse für das Regalbediengerät........................................ 39 3.6.3.3 ASPS2, CSPS2PK1 und CSPS2PK2 - Die Klassen für die Portalkräne...40 3.6.3.4 ASPS3, CSPS3Prod und CSPS3Kom - Die Klassen zur Produktion und Kommisionierung................................................................................................... 40 3.6.3.5 CSPS4 - Einlagerung und Auslagerung.................................................... 41 4 Portierung auf das Zielsystem........................................................................................ 43 5 Testdurchführung........................................................................................................... 44 6 Zusammenfassung/Ausblick........................................................................................... 45 7 Literaturverzeichnis........................................................................................................ 46 8 Anhänge......................................................................................................................... 47

Seite 6 von 49

Abbildungsverzeichnis Abbildung 1: Das Modell..................................................................................................... 10 Abbildung 2: Die SPS Anlage............................................................................................. 10 Abbildung 3: Holzblock....................................................................................................... 11 Abbildung 4: Container mit Brause..................................................................................... 11 Abbildung 5: Das Hochregallager....................................................................................... 12 Abbildung 6: Eine Palette................................................................................................... 12 Abbildung 7: Kettenförderer................................................................................................ 13 Abbildung 8: Das Blocklager.............................................................................................. 13 Abbildung 9: Die Förderbänder.......................................................................................... 13 Abbildung 10: Threadmodell............................................................................................... 17 Abbildung 11: ER-Diagramm.............................................................................................. 19 Abbildung 12: JobManagement Klassenausschnitt............................................................ 25 Abbildung 13: RequestJob................................................................................................. 28 Abbildung 14: CJobReport................................................................................................. 29 Abbildung 15: CreateProductionJobs()............................................................................... 35 Abbildung 16: Handshake PC -> SPS................................................................................ 38 Abbildung 17: Handshake SPS -> PC................................................................................ 38 Abbildung 18: Aktivitätsdiagramm zu CSPS1..................................................................... 39 Abbildung 19: Aktivitätsdiagramm zu CSPS2PK1.............................................................. 40 Abbildung 20: Aktivitätsdiagramm zu CSPS3Prod............................................................. 41 Abbildung 21: Aktivitätsdiagramm zu CSPS3Kom............................................................. 41 Abbildung 22: Aktivitätsdiagramm zu CSPS4..................................................................... 42 Abbildung 23: Drei Wege Handshake-Protokoll................................................................. 49

Seite 7 von 49

Seite 8 von 49

1 Einleitung

1 Einleitung 1.1

Motivation

Es galt eine Prozesssteuerung für das Fischertechnikmodell zu entwickeln, welche mit den vier Speicherprogrammierbaren Steuerungen kommuniziert. Die SPS wurden dabei von vier weiteren Gruppen realisiert. Dies hatte zur Folge, dass genaue Schnittstellendefinitionen mit den einzelnen Gruppen ausgearbeitet wurden, um die Synchronisation untereinander zu gewährleisten. Des weiteren hat die Prozesssteuerung eine Datenbankanbindung, die in der Lage ist über Formulare das Lager, Materialien, Produktions-, Kommisionierungs- und Auslagerungsaufträge zu verwalten.

1.2

Aufgabenstellung im Detail

Die Aufgabenstellung bestand in der „Prozessüberwachung“. Da es keine genauere Aufgabenbeschreibung gab, standen wir zuerst einmal vor dem Problem herauszufinden, was eigentlich von uns und unserem System verlangt wird. Dazu war ein Dialog mit den anderen beteiligten Gruppen, welche für die SPSSteuerungen zuständig waren, notwendig. Zuerst mussten wir deren Aufgabenstellung verstehen, danach erst konnten wir uns Gedanken zur Integration der einzelnen Module und Sub-Module in ein Gesamtsystem machen. Schließlich mussten unsere Überlegungen zu einem Modell zusammengetragen werden, das wir dann implementieren konnten. Aufgabe unseres Software-Systems ist es eine Reihe von Aufträgen (Produktions-, Kommisionier-, Auslagerungsaufträge) zu bearbeiten. Dazu ist es notwendig benötigte Materialien und deren Stellplätze im Lager zu verwalten. Die Materialien müssen durch das gesamte Fischertechnikmodell zu den entsprechenden Positionen, wie etwa Produktionsstraße oder Auslagerungsband geschleust werden. Dabei hatten wir keine Entscheidungsfreiheit im Vorgehen, sondern mussten uns an die Vorgaben die die einzelnen SPS-Gruppen hatten, halten.

1.3 1.3.1

Produktivumgebung Das Modell

Das gesamte Modell (siehe Abbildung 1) wird durch vier Speicherprogrammierbare Steuerungen (siehe Abbildung 2) betrieben. Jede SPS hat für sich ein eigenes Aufgabengebiet mit festen definierten Schnittstellen zu den anderen SPS sowie zu dem Zielsystem, auf dem später die Anwendung installiert wird. Dort werden die Aufträge angenommen, verarbeitet und koordiniert.

Seite 9 von 49

1 Einleitung

Abbildung 1: Das Modell

Abbildung 2: Die SPS Anlage Seite 10 von 49

1 Einleitung

1.3.2

Zielsystem

Das Zielsystem auf dem die Prozesssteuerung später betrieben wird, ist ein PC mit einer eingebauten Controller-Karte die an den Phoenix Contact Interbus-S angeschlossen ist. Dieser Interbus verbindet die vier Siemens

Simatic

S5-100U

Speicherprogrammierbaren

Steuerungen

miteinander.

Das

eingesetzt

Betriebssystem ist Windows 2000 Professional.

1.3.3

Materialtypen

In der ganzen Produktivumgebung kommen insgesamt 2 Materialtypen vor: ●

kleine quadratförmige Holzblöcke, die symbolisch große, schwere Materialien darstellen (siehe Abbildung 3)

●

Container, die symbolisch kleine, handhabbare Materialien darstellen (siehe Abbildung 4).

1.3.3.1

Holzblöcke

Holzblöcke haben verschiedene Materialarten und unterscheiden sich an den silbern farbigen Markierungen an der Seite eines Blocks. Insgesamt gibt es 5 verschiedene Materialarten. In Abbildung 3 handelt es sich z.B. um die Materialart 2. Alle Materialarten werden über die Produktionsstraße be- und verarbeitet, vorher wird dazu über die Formulare in der Datenbank ein Produktionsauftrag erstellt. Abbildung 3: Holzblock

1.3.3.2

Container

Die Container (siehe Abbildung 4) können sozusagen verschiedene „kleine“ Materialien enthalten. Im Versuch kommen hier verschiedene Sorten von Brause zum Einsatz (falls diese nicht durch die Studenten vernichtet wurde ;-) ). Über Kommisionierungsaufträge können die Container be- und verarbeitet werden. Abbildung 4: Container mit Brause

1.3.4

Lagerplätze

Die Orientierung und Positionierung aller Lagerplätze ist durch die Achsen X, Y und Z realisiert. Die X-Achse zeigt im ganzen Modell in die Tiefe, die Y-Achse zeigt Richtung Modell und die Z-Achse zeigt in die Höhe. Einzelne Lagerplätze, wie das Hochregallager, die Kettenförderer, das Blocklager und die Förderbänder Seite 11 von 49

1 Einleitung können über die X-Achse angesprochen und unterschieden werden.

1.3.4.1

Hochregallager

Das Hochregallager (siehe

Abbildung 5) setzt sich aus 21 Stellplätzen zusammen und teilt sich in 7

horizontale Stellplätze und 3 vertikal Reihen auf. Die rechte Spalte bleibt im Initial-Zustand leer. Jeder einzelne Stellplatz kann eine Palette enthalten.

Abbildung 5: Das Hochregallager

1.3.4.2

Paletten

Eine Palette (siehe Abbildung 6) hat zwei Stellplätze, einen linken und einen rechten Stellplatz. In einem Stellplatz muss immer Material der selben Materialart gelagert werden. Z.B. kann in einem linken Stellplatz in einer Palette ein Holzblock des Materialtyps 2 maximal dreimal übereinander gestapelt werden. Eine Mischung verschiedener Materialarten, so dass Materialart 2 und Materialart 3 in einem Stellplatz vorhanden ist, ist nicht vorgesehen. Ebenso muss der Materialtyp immer der gleiche sein. In einem Stellplatz kann nicht gleichzeitig, z.B. ein Holzblock und ein Container

Abbildung 6: Eine Palette

sein. Diese können aber nebeneinander auf einer Palette angeordnet werden. Holzblöcke können 3-fach in einem Palettenstellplatz gestapelt werden. Container können nicht gestapelt werden.

Seite 12 von 49

1 Einleitung

1.3.4.3

Kettenförderer

Die Kettenförderer (siehe Abbildung 7) dienen zum Abstellen

der

Paletten,

wenn

diese

aus

dem

Hochregallager entnommen wurden. Insgesamt gibt es vier Kettenförderer

im

Modell.

Zwei

befinden

sich

im

Produktions- und Kommisionierungsabschnitt, die anderen zwei Kettenförderer sind bei der Einlagerung vorzufinden.

1.3.4.4

Blocklager

Abbildung 7: Kettenförderer

Das Blocklager (siehe Abbildung 8) dient zur Zwischenlagerung der Holzblöcke.

Abbildung 8: Das Blocklager

1.3.4.5

Förderbänder

Im Modell gibt es insgesamt sechs Förderbänder. Ein Förderband wird zum Anliefern der Container für die Kommisionierungsstrecke das zweite wird zum Materialtransport für die Produktionsstraße verwendet . Die restlichen vier Förderbänder (siehe Abbildung 9) werden bei der Einlagerung genutzt.

Abbildung 9: Die Förderbänder Seite 13 von 49

1 Einleitung

1.4

Gliederung der Arbeit

Diese Dokumentation ist in sechs Kapitel eingeteilt, die die Projektarbeit beschreiben und dokumentieren sollen. 1. Einleitung Die Einleitung gibt einen kurzen Überblick über das Projekt und die Produktivumgebung. 2. Grob-Design der gewählten Lösung Dieses Kapitel gibt eine groben Überblick über den Aufbau der Software und deren Grundkonzept. 3. Modellierung und Realisierung Das wichtigste Kapitel dieser Dokumentation, denn hier wird die Modellierung und die Realisierung der Software erläutert. 4. Portierung auf das Zielsystem Es wird kurz auf die Portierung auf das Zielsystem eingegangen. 5. Testdurchführung Da die Software auch getestet werden muss, wird in diesem Kapitel die Durchführung von Tests beschrieben. 6. Zusammenfassung/Ausblick Das letzte Kapitel liefert noch einmal eine Zusammenfassung der erledigten Arbeiten an diesem Projekt.

1.5

Zeitlicher Ablauf

Die ersten Wochen wurde eine theoretische Vorlesung gehalten, um das benötigte Wissen an die Studenten zu vermitteln. Das eigentliche Projekt begann mit der Einteilung der Gruppen, die durch Herrn Prof. Dr. Uwe Tronnier und die Studenten erfolgte. Innerhalb der ersten Wochen fanden immer wieder treffen mit den einzelnen Gruppen und mit Herrn Prof. Dr. Tronnier statt, um Schnittstellen zu definieren und bei bestehenden Fragen in der Thematik und im ganzen Zusammenhang der einzelnen Teilbereiche Klarheit zu verschaffen. Danach wurden die Aufgaben der Entwicklung in einzelne Bereiche unterteilt, interne Schnittstellen definiert und die Bereiche an einzelne Gruppenmitglieder zugeordnet. In der Anfangszeit wurde ausgiebig über das Vorhandene Datenbankmodell diskutiert, Verbesserungen vorgeschlagen und Ansätze der Entwicklung entworfen. Schnell kristallisierten sich die Schwerpunkte der Anwendung heraus. Bereiche wurden zusammengefasst und intern unter den Gruppenmitgliedern verteilt. Die Hauptphase des Projektes bestand in der Entwicklung der einzelnen Bereiche und der Koordination untereinander in der Gruppe. In den Endphase des Projektes wurde die Portierung auf das Zielsystem sowie die Dokumentation vorgenommen. Hier wurden natürlich auch ausgiebige Tests mit den anderen Gruppe durchgeführt. Seite 14 von 49

1 Einleitung Die Übergänge zwischen den einzelnen Phasen des Projektes fanden natürlich nicht von heute auf morgen statt. Vielmehr war es ein kontinuierlicher Übergang, so dass auch während der Phase Testphase auch an der Entwicklungsphase eventuelle Anpassungen vorgenommen wurden.

Seite 15 von 49

2 Grob-Design der gewählten Lösung

2 Grob-Design der gewählten Lösung Das Prozesssteuerungs- und Überwachungssystem wurde in mehrere Komponenten zerlegt, welche untereinander miteinander kommunizieren. Die einzelnen identifizierten Komponenten sind: –

SPS Kommunikation

–

Lagerverwaltung

–

Auftragsverwaltung

–

Jobverwaltung

Im Folgenden werden kurz die einzelnen Komponenten vorgestellt. Genaueres zu ihrer Funktionsweise kann in den jeweiligen Kapiteln nachgelesen werden. Die SPS Kommunikation abstrahiert die von den Gruppen 1-4 realisierten Speicherprogrammierbaren Steuerungen und übernimmt alle Kommunikationsaufgaben über den Feldbus. Die Lagerverwaltung verwaltet alle Lagerhilfsmittel, Positionen sowie Materialien, welche im Produktivsystem vorkommen. Die Auftragsverwaltung generiert aus Auftragsdaten Fertigungsaufträge, welche dann automatisiert weiterverarbeitet werden. Die Jobverwaltung plant und generiert die einzelnen Jobs, welche an die SPS Kommunikation weitergegeben werden. Um eine parallele Ausführung der einzelnen Komponenten zu gewährleisten, wurde das System in mehrere Threads aufgeteilt. Die Verwaltung der Prozesssteuerung läuft in dem Hauptthread, während die einzelnen SPS Abstraktionen in eigenen Aktivitätsträgern laufen (siehe Abbildung 10).

Die Kommunikation der einzelnen Threads untereinander geschieht über eine Zentrale Klasse, den CJobManager (siehe Kapitel 4.6). Diese Klasse ist Threadsave, sodass mehrere Aktivitäts-träger gleichzeitig auf

diese

Einheit

zugreifen

kann

ohne

zu

einem

inkonsistenten

Zustand

zu

führen.

Als

Synchronisationsmittel wurden MFC – Selektionsmechanismen genutzt. Ausschließlich

die

Klassen

Datenbankschnittstelle.

Seite 16 von 49

CLagerverwaltung

und

CAuftragsverwaltung

haben

Zugriff

auf

die

2 Grob-Design der gewählten Lösung Die Datenbankschnittstellen wurden mittels MFC – Datenbankklassen realisiert, da man diese mittels Visual Studio Wizards erstellen lassen kann.

Mainthread

Jobverwaltung

RGB - Steuerung

Produktion Steuerung

Portalkran 1 Steuerung

Kommisionier Steuerung

Lagerverwaltung Auftragsverwaltung

Portalkran 2 Steuerung

Auslagerung Steuerung

Einlagerung Steuerung

Abbildung 10: Threadmodell

Seite 17 von 49

3 Modellierung und Realisierung

3 Modellierung und Realisierung 3.1

Datenbank

Das benutze Datenbank Management System, Microsoft Access 2003, wurde ausgewählt wegen der leichten

Handhabung

und

der

Möglichkeit

schnell

Formulare

zur

Eingabe

von

Lager-

und

Auftragsinformationen zu erstellen. Außerdem besitzt MS Access standardmäßig eine ODBC (Open DataBase Connectivity zu deutsch „Offene Datenbank -Verbindungsfähigkeit“) Schnittstelle. ODBC bietet eine standardisierte Datenbankschnittstelle, die es ermöglichte relativ unabhängig vom DBMS (DatenbankManagement-System) die Anwendung zu entwickeln. Eine eigene Modellierung des Datenbankentwurfs war nicht nötig, da schon ein adäquater Datenbankentwurf von Prof. Tronnier vorgeschlagen wurde. Es wurden nur kleine Änderungen an der Tabelle LHMft vorgenommen und zwar wurde die Speicherung der Holzblöcke von der Tabelle LHMft in die Tabelle LHMContainer verschoben. Dies vereinfachte das Updaten der Lageriiformationen in Bezug auf die Materialien. (siehe Abbildung 11) Um

programmiertechnisch

eine

Datenbankverbindung

herzustellen,

wurde

keine

eigene

Datenbankschnittstelle geschrieben. Dazu wurde die MFC ODBC Datenbankschnittstelle von Visual Studio verwendet. Visual Studio generiert zu einer oder mehreren Tabellen eine Datenabstraktionsklasse. Das bedeutet, für jedes Attribut einer ausgewählten Tabelle werden dazugehörige Membervariablen angelegt, in denen jeweils ein Datensatz abgelegt wird. Diese sogenannten RecordSet Klassen bieten dann verschiedene Methoden, um entweder Daten aus der Datenbank auszulesen, sie zu bearbeiten, sie zu suchen oder sie in die Datenbank zu schreiben. So ist es möglich auf SQL Statements zu verzichten. Es wurden RecordSet Klassen für die Lagerverwaltung (LagerSet, LHMSet, ContainerSet, MaterialSet) und für die

Auftragsverwaltung

(ProduktionsauftragSet,

KommisionierauftragSet,

AuslagerungsauftragSet, FertigungsauftragSet, ArbeitsgangSet) generiert.

Seite 18 von 49

EinlagerungsauftragSet,

3 Modellierung und Realisierung

3.1.1

ER-Diagramm Material PK,I1

matId bez

Arbeitsgang PK,I1

arbgId

PK,I1

lhmContainerId

FK1,I2

FK1,I2 I3

beschreibung maschParam quellMatId zielMatId

matId mengeMat mischContainer virtuell

Auslagerungsauftrag PK,I1

FK2,I3 FK1,I2

LHMContainer

Einlagerungsauftrag

Produktionsauftrag

ausAufId

PK,I2

prodAufId

PK,I1

einAufId

zielTermin matId menge lhmContainerId erfasst

FK1,I1

arbgId anzTeile anzGefTeile zieltermin erfasst

I2 FK1,I3 FK2,I4

lhmId lhmContainerId matId

Kommisionierauftrag PK,I1

kommAuftrId

FK2

mat1Id mengeMat 1 tatMengeMat 1 mat2Id mengeMat 2 tatMengeMat 2 lhmContainerId zielTermin erfasst

FK1,I2

Lager PK,I1

lagerId

I2

yposition zposition xposition lhmId

Fertigungsauftrag PK,I2

FK4,I6 I5 MaterialAbfrage

FK2,I3 FK3

matId bez

FK1,I1 I4

Abbildung 11: ER-Diagramm Seite 19 von 49

fertAufId termin prodAufId lhmId sollAnzQuelleTeile kommAuftrId lhmContainerIdMat 1 lhmContainerIdMat 2 lhmContainerIdLeer lhmIdMat1 lhmIdMat2 lhmIdLeer ausAufId lhmContainerId

LHM_ft

FK1,FK2,FK2,FK2,FK2,FK3,I1 lhmId FK4 lhmContainerIdL lhmContainerIdR

3 Modellierung und Realisierung

3.2

Klassendiagramm

siehe Anhang.

3.3

Lagerverwaltung

Die Lagerverwaltung beinhaltet ein komplettes Abbild des Fischertechnik-Hochregallagers bzw. den Inhalt, der in der Datenbank dafür gespeichert wurde. Das Abbild besteht aus Lager-, Paletten-, Container- und Material-Objekten, die durch die einzelnen Klassendefinitionen gekapselt, in einem Array in der Lagerverwaltung hinterlegt werden. Die Lagerverwaltung stellt Schnittstellen für das Lager, dem Jobmanager und der Auftragsverwaltung zur Verfügung, wobei die Auftragsverwaltung lediglich Informationen über die vorhandenen Paletten, Container und Materialien von der Lagerverwaltung benötigt. Der Jobmanager hingegen, verändert die Inhalte der Objekte, die ihm über die Schnittstellen der Lagerverwaltung bereit gestellt werden. Das bedeutet, dass nach dem Objekte vom Jobmanager verändert wurden und somit sich der Lagerinhalt nach einem Auftrag geändert hat, die Lagerverwaltung die Lager-Datenbank auf den neusten Stand bringen muss. Im folgenden wird auf die Erstellung des Lagerabbildes und auf die Schnittstellen für Jobmanager und Auftragsverwaltung näher eingegangen. Das Hochregallager wurde auf Programmierebene mit den folgenden Klassen abgebildet.

3.3.1

Klasse CLagerverwaltung

Das ist die Klasse in der in einem CArray die einzelnen Lagerplätze vom Typ CLager und deren Inhalt abgelegt werden. Von dieser Klasse kann auch nur eine Instanz erzeugt werden. So ist gewährleistet, dass auch nur einmal das Lager erzeugt werden kann und zwar beim ersten Aufruf der Klasseninstanz. Dieses Pattern nennt man Singleton. Sobald über die Singleton-Methode getInstance() ein zweites Mal diese Klasse erzeugt werden soll, wird nicht eine neue, sondern die zuvor erzeugt Instanz zurückgeliefert. So kann sichergestellt werden, dass die benutzten Objekte immer noch die sind, die zuvor benutzt worden sind. Des weitern beinhaltet die Klasse die Schnittstellen/Methoden, für den Jobmanager und die Auftragsverwaltung. Die Schnittstellen werden im weiteren Verlauf der Dokumentation noch etwas näher erläutert. Außerdem werden beim Erzeugen der Instanz die Positionen für die Kettenförder und die Förderbänder initialisiert und in einem Array hinterlegt, so können die Positionen über die definierten Makros (z.B.: POS_KOM_FB, POS_PROD_FB, POS_SORT1_FB, ...) recht schnell ausgewählt werden. Um nun das Lagerabbild aufzubauen, wird beim Instanzieren der Klassen die private Methode getLagerFromDB() aufgerufen. Damit werden alle, in der Datenbanktabelle Lager, vorhanden Lagerplätze ausgelesen und für jeden Eintrag ein neues Objekt vom Typ CLager erzeugt. Zu den Konstruktorparametern der Klasse CLager gehören, die Lager-Id, die x,y,z Koordinaten des Stellplatzes und die Paletten-Id. Diese Objekte werden dann in dem CArray cLagerArray als Zeiger hinterlegt. Seite 20 von 49

3 Modellierung und Realisierung

3.3.2

Klasse CLager

Wenn ein neues Objekt vom Typ CLager erzeugt wird, werden zuerst die übergebenen Parameter in den Membervariablen gespeichert. Nur die Paletten-Id wird nicht gespeichert, weil die wird geprüft, ob sie größer Null ist, denn ist das nicht der Fall wird auch kein neues Objekt vom Typ CLHM_Palette angelegt. Das heißt es steht keine Palette in diesem Stellplatz. Falls die Paletten-Id doch größer Null ist, also eine Palette vorhanden ist wird ein neues CLHM_Paletten Objekt erzeugt mit den Parametern der x,y,z Koordinaten und der Paletten-Id. Nachdem das Objekt erzeugt worden ist, wird es in der dafür vorgesehenen Membervariable hinterlegt. Als Methoden stehen die standardmäßigen Getter- und Setter-Methoden zur Verfügung, eine Methode isEmpty() und eine Methode updateLager(). Die Methode isEmpty() prüft lediglich nach, ob der Stellplatz leer ist oder nicht. Die Methode updateLager() schreibt die Änderungen an einem Stellplatz zurück in die Datenbank.

3.3.3

Klasse CLHM_Palette

Sobald eine neue Palette angelegt wird, werden wie auch schon in der Klasse CLager die übergebenen Parameter in den Membervariablen gespeichert und zwar werden die x,y,z Koordinaten dafür benutzt die momentane Position der Palette zu initialisieren. Die Klasse CLHM_Palette besitzt nämlich ein Attribut currentPosition vom Typ Position, die die momentane Position beinhaltet, so kann herausgefunden werden, wo sich die Palette befindet. Diese Koordinaten werden durch ein Struct vom Typ Position angegeben. Auch die Klasse CLager und CLagerverwaltung benutzen dieses Struct um die Positionen bzw. Koordinaten zu händeln. Die Paletten-Id hingegen wird nicht nur gespeichert, sondern noch an die private Methode getLHMFromDB(UINT) übergeben, die im Konstruktor aufgerufen wird. Die Methode getLHMFromDB(UINT) stellt eine Verbindung zur Datenbank her und filtert an Hand der Paletten-Id den zugehörigen Datensatz aus der Tabelle LHMft. Diese Daten, nämlich die Container-Id für den linken, sowie für den rechten Container auf der Palette, werden benötigt um ein neues Objekt bzw. zwei neue Objekte vom Typ CLHM_Container zu erstellen. Auch hier wird zuvor noch geprüft, ob die Container-Ids größer Null sind, um dann neue Container Objekte anzulegen. Ist die Container-Id kleiner oder gleich Null, ist kein Container auf der Palette links oder rechts vorhanden. Als Übergabeparameter an den Konstruktor der Klasse CLHM_Container wird die jeweilige Container-Id benutzt. Auch hier werden nach der Erzeugung des linken und rechten Containers, die Objekte in den passenden Membervariablen gesichert. Die Klasse enthält Getter- und Setter-Methoden, eine isEmpty(BOOL links, BOOL rechts) Methode und eine updateLHM() Methode. Ebenfalls, wie in der Klasse CLager, wird die isEmpty(...) Methode benutzt, um zu prüfen, ob die Palette entweder links oder rechts oder auf beiden Seiten leer ist. Die update Methode, die auch in den folgenden Klassen vorhanden ist und deren Funktion im Prinzip jedes mal die selbe ist, schreibt die Änderungen, die an der Palette vorgenommen wurden in die Datenbank.

Seite 21 von 49

3 Modellierung und Realisierung

3.3.4

Klasse CLHM_Container

Ein neues Container Objekt bekommt die Container-Id übermittelt, die wird in der Membervariable gespeichert und danach an die private Methode getContainerFromDB(UINT) übergeben. Die private Methode getContainerFromDB(UINT) liest mit Hilfe der Container-Id den passenden Datensatz aus und speichert die Daten in den passenden Membervariablen. Die Klasse hat zwei Flags, die aus der Datenbank gelesen werden. Das Flag mischContainer wird gesetzt, wenn ein Plastikcontainer mit Brause wieder eingelagert wird, denn nach dem Kommisionieren kann nicht mehr nachvollzogen werden, was und wieviel in einem Plastikcontainer enthalten ist. Das Flag virtuell gibt nur an, ob es sich um einen Containerplatz mit Blöcken oder mit einem Plastikcontainer handelt. Nur die Material-Id wird nicht gespeichert, sondern auf größer Null geprüft und je nachdem ein Objekt vom Typ CMaterial erzeugt und in der Membervariable gespeichert. Auch diese Klasse besitzt wieder ihre Getter- und Setter-Methoden, sowie die isEmpty() und updateContainer Methoden. Die beiden zuletzt genannten Methoden erfüllen den selben Zweck, wie die der Methoden in den vorangegangenen Klassen und zwar eine Überprüfung, ob Material vorhanden ist oder nicht, sowie die Datenbank mit den veränderten Werten der Klasse auf den neusten Stand bringen.

3.3.5

Klasse CMaterial

Wird ein neues Material Objekt erzeugt, wird die übergebene Material-Id in der Membervariable gespeichert. Als nächstes wird die private Methode getMaterialFromDB(UINT) und ihr die Material-Id übergeben. Mit der Material-Id kann dann die Materialbezeichnung aus Tabelle Material geholt werden und in der passenden Membervariable gespeichert werden. Die Getter- und Setter-Methoden sind vorhanden, wie auch die updateMaterial() Methode. Nur die isEmpty() Methode wird an dieser Stelle nicht mehr gebraucht. Die Klasse CMaterial steht sozusagen am Ende dieser Kette. So wird für jeden Lagerplatz, der in der Datenbank hinterlegt worden ist, die einzelnen Objekte angelegt bis hin zu der Klasse CMaterial und immer in den dazugehörigen Membervariablen der Klassen gespeichert.

3.3.6

Lagerschnittstellen

Die Lagerschnittstellen sind Methoden, die die Klasse CLagerverwaltung bereit stellt. Diese Schnittstellen nutzen der Jobmanager und die Auftragsverwaltung. Die wichtigsten Schnittstellen werden hier kurz erläutert.

3.3.6.1 ●

Jobmanager

getMaterial(materialID, menge) Sucht angegebenes Material mit einer gewissen Menge im Lager und gibt die Palette zurück auf der das Material zu finden ist. Bei Material mit der Id und einer Menge gleich Null, wird eine Palette mit einem leeren Plastikcontainer zurückgegeben. Wird kein passendes Material mit der angegebenen Menge gefunden liefert die Methode NULL zurück.

Seite 22 von 49

3 Modellierung und Realisierung

●

getFreeContainer(materialId, freeContainer) Sucht eine Palette zum Einlagern eines Blocks oder eines Plastikcontainers und gibt diese zurück, wenn eine passende gefunden worden ist, ansonsten NULL. Für einen Plastikcontainer muss explizit ein komplett leerer Platz auf der Palette gesucht werden deshalb das Flag freeContainer.

●

updateAll() Schreibt alle Änderungen in den Lagerobjekten (Lagerplatz, Palette, Container, Material) in die Datenbank.

●

update(Palette) Schreibt die Änderungen einer bestimmten Palette zurück in die Datenbank. Wird eine Palette per update in die Datenbank geschrieben, so werden auch die Änderungen an Container und Material der jeweiligen Palette in die Datenbank geschrieben.

●

getFreePortalPosition() Liefert eine freie Kettenfördererposition zurück. Ist keine frei, wird NULL zurückgegeben.

●

getSavePosition() Liefert einen freien, temporären Lagerplatz. Dies wird benötigt, falls beim Einlagern der eigentliche Lagerplatz belegt ist.

●

getKFPosition(positionsnummer) Liefert eine bestimmte Kettenfördererposition zurück.

●

getFBPosition(positionsnummer) Liefert eine bestimmte Förderbandposition zurück.

●

releasePortalPosition(Position) Gibt eine belegten Kettenförderer wieder frei.

●

checkIn(Palette) Signalisiert, dass die angegebene Palette wieder im Lager verfügbar ist.

●

isLagerPosition(Palette) Prüft, ob sich die Palette momentan im Lager befindet oder nicht.

●

isKF(Position) Prüft, ob die angegebene Position einer Palette eine Kettenfördererposition ist oder nicht.

3.3.6.2

Auftragsverwaltung

●

getMaterialPalett(materialID, menge) Sucht eine Palette, die ein bestimmtes Material mit einer bestimmten Menge besitzt. Zurückgegeben wird eine Palette. Die Auftragsverwaltung braucht diese Palette, um die Paletten-Id und die Container-Id für einen Auftrag zu bekommen.

●

getEmptyContainer() Sucht einen leeren Plastikconatiner für die Kommisionierung. Auch hier braucht die Auftragsverwaltung die Palette, um die Ids für einen Auftrag zu bekommen.

3.4

Auftragsverwaltung

Die Auftragsverwaltung wird in der Klasse CFertigungsauftragsverwaltung realisiert und ist gleichzeitig die Schnittstelle zum Jobmanager. Von der Klasse kann nur eine Instanz erzeugt werden, die gleichzeitig eine leere Auftragsliste für neue Aufträge initialisiert.

Seite 23 von 49

3 Modellierung und Realisierung Der Jobmanager kann über die Funktion NewJobs, bisher unerfasste Aufträge anfordern. Hierbei werden nacheinander die einzelnen Auftragsarten (Produktionsauftrag, Kommisionierauftrag, Auslagerungsauftrag) aus der Datenbank ausgelesen und in die Auftragsliste übernommen. Außerdem kann der Jobmanager über die Funktion UpdateJob einen Auftrag aktualisieren, die Änderungen werden dann abgespeichert.

3.4.1

Auftragsklassen

Alle Aufträge sind von der abstrakten Klasse CAuftrag abgeleitet. Diese beinhaltet die gemeinsamen Attribute, die in jedem Auftrag vorhanden sind.

3.4.1.1

CProduktionsAuftrag, CKommisionierauftrag, CAuslagerungsauftrag

Die einzelnen Klassen sind nur für Ihre jeweiligen genannten Aufträge zuständig. Jeder, nicht erfasste Auftrag wird beim Aufruf der Funktion NewJobs aus der Datenbank ausgelesen, diese können an einem Flag „erfasst“ identifiziert werden, und sofort ein neues Objekt je Auftrag erstellt werden. Die Daten aus der Datenbank werden in das Objekt übernommen. Die neuen Aufträge werden nun von der Auftragsverwaltung der Auftragsliste hinzugefügt.

3.4.1.2

CFertigungsauftrag

Die Klasse CFertigungsauftrag generiert aus jedem neuen Auftrag einen Fertigungsauftrag und speichert diesen in der Datenbank ab.

3.5

Jobverwaltung und Generierung

Dieser Abschnitt befasst sich mit der Realisierung der Jobgenerierung und deren Verwaltung. Die zentralen Klassen dieses Moduls sind CJobManager und CJobFactory. Wobei der JobManager die Verwaltung und die JobFactory die Generierung übernimmt. Folgender Ausschnitt aus dem Klassendiagramm liefert einen Überblick über die benötigten Klassen sowie deren Vererbungsstruktur.

Seite 24 von 49

3 Modellierung und Realisierung IJobService

CJobManager «uses»

AJob

CSPS1Job

CJobFactory

CSPS3KomJob

CSPS2Job

CSPS4Job

CSPS3ProdJob

CClearJob CSPS4RejJob

Abbildung 12: JobManagement Klassenausschnitt

Im Weiteren wird auf die einzelnen Bestandteile genauer eingegangen.

3.5.1

CJobManager

Die Klasse CJobManager, im folgenden JobManager genannt, befasst sich mit der Logistik der einzelnen Jobs sowie der Auswertung von abgearbeiteten Jobs. Außerdem bietet diese Klasse die Schnittstellen zu den SPS Kommunikationsklassen ( im folgenden SPS genannt ). Der JobManager ist das Zentralste Element des ganzen Systems. Deshalb darf auch zu jeder Zeit nur eine Instanz der Klasse existieren. Aus diesem Grund wurde die der JobManager als Singelton implementiert mit einem privaten Konstruktor. Mittels der statischen Methode CJobManager::Instance() wird eine Referenz auf den einzigen existierenden JobManager zurückgegeben. Existiert zu diesem Zeitpunkt noch keine Instanz der Klasse wird eine Instanz angelegt und die Referenz darauf zurückgegeben. Bei

dem

Programmstart

JobManagers angelegt.

wird

eine

Instanz

des

Der folgende Aufruf von der

JobManager

Membermethode Control() startet dann alle Komponenten und die Verarbeitung der Aufträge beginnt. Der Aufruf kehrt erst nach Beenden des Programms zurück, dar der JobManager in einer Endlosschleife auf Jobs und Aufträge wartet. Sobald der Konstruktor aufgerufen wird werden alle weiteren benötigten Objekte erzeugt, darunter alle SPS Klassen, die Lagerverwaltung, die Auftragsverwaltung Seite 25 von 49

main() Aufruf Instance() &CJobManager Control()

3 Modellierung und Realisierung sowie mehrere Loggerinstanzen. Des weiteren werden die MFC Objekte vom Typ CEvent initialisiert. Kehrt der Konstruktor erfolgreich zurück, kann das System anlaufen. Nachdem Control() aufgerufen wurde. Werden die bereits erzeugten SPS Instanzen in jeweils eigenen Threads gestartet. Dies wurde abermals mit MFC – Mitteln realisiert. Die entsprechende Funktionssignatur lautet (entnommen aus [MSDN]): CWinThread* AfxBeginThread( AFX_THREADPROC pfnThreadProc, LPVOID pParam, int nPriority = THREAD_PRIORITY_NORMAL, UINT nStackSize = 0, DWORD dwCreateFlags = 0, LPSECURITY_ATTRIBUTES lpSecurityAttrs = NULL ); Wobei der Parameter pParam in diesem Fall ein Pointer auf ein Objekt einer SPS Klasse darstellt und der Parameter

pfnThreadProc

als

Wert

die

Klassenmethode

StartSPSThread

beinhaltet.

In

der

StartSPSThread-Methode wird dann der Void Pointer auf das Markerinterface ASPSMarker gecastet und deren Methode run() aufgerufen, welche in einer Endlosschleife laufen und nie zurückkehren sollten. Sind alle Threads am laufen beginnt der JobManager seine eigentliche Aufgabe. Dem Verwalten von Jobs für die unterschiedlichen SPS Klassen. Um die Kommunikation zwischen JobManager und den SPS Threads sehr schlank zu halten, wird in dem Interface IJobService lediglich 2 Methoden zum Datenaustausch definiert. Der JobManager implementiert seinerseits diese rein virtuellen Methoden und stellt sich gegenüber den SPS lediglich als IJobService dar. Dies ermöglicht ein einfaches Austauschen der eigentlichen Verteilungslogik durch eine neue Klasse die nur das Interface zu implementieren hat. IJobService +RequestJob(ein Parameter1 : ASPSMarker &) : AJob & +ReportJob(ein Parameter1 : CJobReport &) : bool

Um herauszufinden was bei einem RequestJob oder ReportJob verarbeitet werden muss

, wird eine

Typprüfung der Parameter zur Laufzeit vorgenommen. Dies wird mittels der MFC – Makros DECLARE_DYNAMIC im Header sowie IMPLEMENT_DYNAMIC in der Implementationsdatei erreicht. Um die Makros nutzen zu können muss allerdings die Klasse direkt oder indirekt von CObject erben. Sind die Makros korrekt in die Klasse eingefügt steht die Methode isKindOf() zur Verfügung. Mittels dieser Methode kann man auf die Laufzeitklasse eines Objektes prüfen und somit kann der JobManager unterscheiden welche SPS anfragt oder was für ein Job in einem CJobReport steckt. MFC bietet Steigerungen des Makros, welche weitere Methoden zur Verfügung stellen, allerdings wurden diese im Rahmen des Projektes nicht benötigt. Folgende Tabelle [MSDN] zeigt die Mächtigkeit der

Seite 26 von 49

3 Modellierung und Realisierung verfügbaren Makros.

Macro used

CObject::IsKindOf

CRuntimeClass:: CreateObject

CArchive::operator>> CArchive::operator
SPS

●

hsSPS2PCTransferBegin() macht nichts, wird nur wegen Konsistenz zum Senden verwendet

●

hsSPS2PCTransferComplete() signalisiert dem SPSG, dass die Daten gelesen wurden und wartet schließlich darauf, dass das SPSG sein DS zurücknimmt um wieder im Ausgangszustand zu sein, d.h. bis PC.ACK = true, warten bis SPS.DS == false, danach PC.ACK = false.

Abbildung 17: Handshake SPS -> PC Seite 38 von 49

3 Modellierung und Realisierung

3.6.3.1.2

Bus-Polling

Da es keine Callback-Mechanismen gibt die dem PC mitteilen dass sich etwas auf dem Bus geändert hat, muss der Feldbus ständig gepollt werden. Das Polling findet in jedem der SPSK-Threads unabhängig voneinander statt, so dass die eigentlichen Bus-Zugriffe als sichere Bereiche behandelt werden müssen. Dazu wurde das die Klasse CCriticalSection, die von der Microsoft Foundation Classes zur Verfügung gestellt wird, benutzt. Aufgrund dessen dass ein SPSG eine gewisse Zeit benötigt um ihre Aufgaben auszuführen ist es unsinnig den Bus beliebig schnell (quasi nur durch die CPU-Geschwindigkeit begrenzt) zu pollen. Daher wurde eine wait()-Methode implementiert, die den Thread nach einem Poll-Vorgang einige Zeit inaktiv setzt, so dass Rechenzeit freigegeben wird. Momentan ist diese Zeit auf 100ms gesetzt. Kann aber leicht geändert werden, sofern sich diese Zeit als unpassend erweist.

3.6.3.2

CSPS1 - Die Klasse für das Regalbediengerät

CSPS1 ist für das Regalbediengerät (RBG) zuständig. Dazu holt sie vom Jobmanager einen CSPS1Job ab. Darin stehen Quelle und Ziel für das RBG. Diese Daten werden in der sendJob2SPS()-Methode so zerlegt dass sie entsprechend der Schnittstellendefinition über den Bus an das SPSG geschickt werden können. Sollte

während

der

Bearbeitung des Jobs ein Fehler vom RBG gemeldet werden, wird dieser

durch

einen

entsprechenden Fehlercode

im

JobReport vermerkt. Da die lose Kopplung der SPSK

zum

restlichen

System zur Folge hat, dass die SPSK keine Kenntnis

über

momentanen

den

Zustand

der Datenbank, also des Lagers

besitzt,

kann

innerhalb der CSPS1Klasse nicht sinnvoll auf Fehler die vom RBG gemeldet

werden

Abbildung 18: Aktivitätsdiagramm zu CSPS1

reagiert werden. Daher werden alle Fehler an den Jobmanager gemeldet, der dann weitere Entscheidungen trifft um auf den jeweiligen Fehler angemessen zu reagieren.

Seite 39 von 49

3 Modellierung und Realisierung

3.6.3.3

ASPS2, CSPS2PK1 und CSPS2PK2 - Die Klassen für die Portalkräne

Für die beiden vorhandenen Portalkräne wurden je

eine eigene Klasse geschrieben. Deren

Gemeinsamkeiten wurden in deren Vaterklasse ASPS2 zusammengefasst. Im wesentlichen unterscheidet sich CSPS2PK1 dadurch von CSPS2PK2, dass der Portalkran1 zusätzlich noch geparkt werden kann. Dadurch sind zusätzliche Automatenzustände hinzugekommen die überwacht werden müssen. Auch hier werden auftretende Fehler direkt an den Jobmanager weitergeleitet, da dieser die Übersicht über das System besitzt. Sollte der Portalkran1 geparkt werden, wird dies sofort an den Jobmanager gemeldet. Dazu wird ein leerer Job, mit dem Sobald

Park-Flag, der

zurückgemeldet.

Portalkran

wieder

vollständig einsatzbereit ist, wird dies dem Jobmanager auf die gleiche Weise mitgeteilt. Dieses Verhalten hat zur Folge, dass die Entscheidung welcher Portalkran einen Job bearbeitet vom Jobmanager getroffen werden kann, wodurch Hinsicht

Optimierungspotential auf

die

in

Gesamtsystem-

geschwindigkeit besteht. Zusätzlich hat dieses zentrale Design rund um den Jobmanager

eine

Kommunikation,

der

asynchrone in

getrennten

Threads laufenden SPSK, erübrigt. Da das SPSG, welches die beiden Portalkräne steuert, die Koordinaten der Kettenförderer anders interpretiert

Abbildung 19: Aktivitätsdiagramm zu CSPS2PK1

als die Lagerverwaltung und das RBG-SPSG, muss vor dem Senden des Jobs noch ein Mapping der Koordinaten durchgeführt werden.

3.6.3.4 ASPS3, CSPS3Prod und CSPS3Kom - Die Klassen zur Produktion und Kommisionierung Ebenso wie bei den beiden Portalkränen wurden für die Produktion und die Kommisionierung jeweils eine eigene Klasse spendiert. Gemeinsamkeiten wurden in der abstrakten Vaterklasse ASPS3 gebündelt. CSPS3Prod ist für die Produktion zuständig. Sie nimmt einen CSPS3ProdJob der im wesentlichen ein Bohrmuster enthält und reicht dies an das SPSG weiter.

Seite 40 von 49

3 Modellierung und Realisierung Fehlersituationen sind nicht vorgesehen, evtl. auftretende Fehler werden direkt vom SPSG behandelt und nicht an den PC weitergemeldet. CSPS3Kom steuert die Kommisionierung. Hierbei muss dem SPSG lediglich mitgeteilt werden, ob es sich um eine Kommisionierung mit zwei oder drei beteiligten Containern handelt.

Abbildung 21: Aktivitätsdiagramm zu CSPS3Kom

Abbildung 20: Aktivitätsdiagramm zu CSPS3Prod

Die Übergabe der Container vom Portalkran zur Kommisionierstrecke bzw. Produktionsstrecke handeln die SPSG autonom untereinander aus, so dass hier keine Notwendigkeit der Intervenierung für die CSPS3Kom besteht. Als Fehlersituation kann es vorkommen, dass ein Container verloren geht. Dies wird dem Jobmanager gemeldet, der daraufhin adäquat reagiert.

3.6.3.5

CSPS4 - Einlagerung und Auslagerung

Da das Design des SPS4G und somit auch die Schnittstelle dort hin etwas unglücklich ist, was leider durch mangelnde Spezifikation erst spät bekannt wurde musste hier ein etwas abweichendes Design verfolgt werden. Das SPS4G ist zum einen für das Einsortieren der Materialien in die vier Warteschlangen vor dem Portalkran auf der Einlagerungsseite verantwortlich, zum anderen auch für das Auslagern bestimmter Materialien aus dem System heraus. Die Vorgabe sieht es so vor, dass ein Material zur Auslagerung an das SPSG gemeldet wird. Daraufhin schleust das SPSG alle Materialien zur Einlagerung durch bis irgendwann das gesuchte Zielmaterial ausgeschleust wird. Dieses Ausschleusen wird vom SPSG gemeldet. Gleichzeitig werden alle Materialien die an den vier Einschleusebändern ankommen ebenfalls gemeldet.

Seite 41 von 49

3 Modellierung und Realisierung Dadurch musste ein Satelliten-Thread zur Überwachung der asynchronen Rückmeldungen die von den Einlagerungsbändern kommen hinzugefügt werden, während der normale SPSK-Ablauf das Ausschleusen überwacht. Leider ist es nicht möglich, dem SPSG mehrere auszuschleusende Materialien zu übermitteln. Besser wäre in diesem Falle - aus PC-Steuerungssicht - entweder eine Queue-Verwaltung im SPSG oder ein Callback sobald ein Material am Ausschleuse-Sensor vorbeikommt, so dass für jedes Material mitgeteilt werden kann ob es ausgeschleust oder eingelagert werden soll. Dadurch könnte die Entscheidung dynamisch getroffen werden, in Abhängigkeit der Auslagerungsqueue die sowieso vom Jobmanager verwaltet wird. Der zusätzliche Satelliten-Thread hätte sich dadurch ebenfalls erübrigt.

Abbildung 22: Aktivitätsdiagramm zu CSPS4

Seite 42 von 49

4 Portierung auf das Zielsystem

4 Portierung auf das Zielsystem Die Entwicklung der Anwendung fand unter Microsoft Windows XP mit Microsoft Visual Studio 2005 statt. Die erste Portierung auf das Zielsystem schlug nach vielen Versuchen fehl. Unter anderem ist auf dem Zielsystem ein anderes Betriebssystem installiert, als auf den Entwicklungsplattformen. Des Weiteren ist auf der Zielplattform nur Microsoft Visual Studio 6 verfügbar, was zu weiteren Portierungsproblemen, wegen diversen verschiedenen Versionen der einzelnen Komponenten (MFC, andere Libraries), führte. Mit einem Assistenten von Microsoft Visual Studio 2005 wurde ein Installationsassistent geschrieben, der automatisch, alle benötigten Ressourcen bereitstellt und auf der Zielsystem mitnimmt. Nach der Portierung wurden Tests durchgeführt, um die Kompatibilität der einzelnen Gruppen zu gewährleisten.

Seite 43 von 49

5 Testdurchführung

5 Testdurchführung Durch den nötigen umständlichen Installationsvorgang auf der Zielplatform entfiel die Möglichkeit unseren Code direkt zu debuggen. Unser Logging jedoch erlaubte es uns trotzdem Fehler zu lokalisieren. Diese Fehlersuche ist allerdings zur klassischen Variante extrem Zeit intensiv. Der Code musste auf einer Entwicklungsmaschine geändert, neu kompiliert, gelinkt und zuletzt wieder auf dem Zielsystem installiert werden, was eine Deinstallation voraussetzte. Weiterhin mussten auch die SPS – Gruppen anwesend sein um das ganze System zu testen. Aus diesem Grund wurden die Abstrakten Test SPS Klassen geschrieben. Diese ermöglichen das System ganz ohne IBS Steuerung zu betreiben. So konnten bereits etliche Speicherzugriffsfehler im vorab behoben werden. Sobald das Flag NOIBS in der stdafx.h definiert wird stellt das System auf Testbetrieb um, und es wird keine SPS mehr benötigt. ASPSMarker

CSPS1NoIBS

CSPS2PK1NoIBS

CSPS2PK2NoIBS «uses»

CSPS3KomNoIBS

«uses»

CSPS3ProdNoIBS CSPS4NoIBS «uses»

SharedResourceManager

Das Verhalten der einzelnen Test SPS Klassen bietet für dieses Release nur die Möglichkeit den fehlerfreien Fall zu simulieren. Weiterhin ist eine Auslagerung noch nicht möglich. Um eine Einlagerung zu simulieren mussten die SPS2 mit der SPS4 Daten austauschen, weshalb ein SharedResourceManager implementiert wurde. Dieser synchronisiert den Zugriff auf eine Liste in welche MaterialIDs eingefügt werden können. Die SPS4 entnimmt diese und meldet dem JobManager ein Material auf einem Band. In dem nächsten Release sollte das Verhalten der einzelnen Test SPS durch zufällige Fehlermeldungen erweitert werden.

Seite 44 von 49

6 Zusammenfassung/Ausblick

6 Zusammenfassung/Ausblick Unser Softwaresystem ist in der Lage Kommisionieraufträge und Produktionsaufträge zu bearbeiten. Dies schließt eine erfolgreiches Zusammenspiel mit dem RBG und dem Portalkran mit ein. Zum Testen der Einlagerung / Auslagerung fehlte uns die Zeit, so dass wir hier noch mit erheblichen Bugs rechnen müssen, die eine erfolgreiche Kooperation mit der SPS4 möglicherweise verhindern. Alles in allem war das Projekt sehr interessant und durchaus anspruchsvoll. Leider war es frustrierend, dass es kaum verwertbaren Vorgaben oder Spezifikationen für unsere Gruppe gab. Dies führte dazu, dass wir erst sehr spät - nachdem alle SPS-Gruppen ihre Automatenmodelle fertig gestellt hatten - unsere Aufgabenstellung erfassen konnten. Bei der Vorstellung der Automatenmodelle kam es zudem immer wieder zu Verzögerungen, so dass sich alleine dieser Prozess über drei Wochen hinzog. Durch diese Verspätung hatten wir gegen Ende zu wenig Zeit zum Implementieren und Testen. Während man die Implementierung, durch geschicktes Aufteilen in einzelne Aufgabenbereiche, größten Teils unabhängig von den anderen Teammitgliedern, mit Überstunden voran bringen konnte, war dies beim Testen am Modell nicht möglich, da hier stets alle SPS-Gruppen anwesend sein mussten, was verständlicherweise nur zum regulären Termin organisatorisch machbar war. Aufgrund dessen, dass wir erst sehr spät mit der Entwicklung anfangen konnten, blieb nicht genug Zeit eine brauchbare Testumgebung aufzubauen, so dass große Teile des Codes erst am Modell direkt getestet werden konnten. Dies erwies sich als sehr unpraktisch, da der betagte Zielrechner sowohl Hardware als auch softwareseitig für heute Verhältnisse sehr schlecht ausgestattet ist. Daher mussten wir bei jeder Änderung am Quellcode auf unseren Entwicklungsrechnern neu kompilieren und linken, eine Setup-Datei erstellen und diese dann über den Umweg eines Netzlaufwerks installieren, wobei der sehr knappe freie Speicherplatz auf der Festplatte zu einem Problem wurde. Ähnlich umständlich erwies sich das Handling mit der Datenbank, da auf dem Zielrechner kein Access verfügbar ist, musste auch hier jede Änderung durch Umkopieren über ein Netzlaufwerk auf den Ziel-PC übertragen werden. Zusammenfassend lässt sich sagen, dass das Projekt sehr interessant und anspruchsvoll war. Mit etwas mehr Zeit bzw. einer gründlichen Einführung und ggf. Vorführung des Modells hätten wir nicht so sehr unter Zeitdruck gestanden und auch einige Variationen und Optimierungen ausprobieren können.

Seite 45 von 49

7 Literaturverzeichnis

7 Literaturverzeichnis [MSDN] – Microsoft Developer Network Library [MFC] – MFC mit Visual C++ 6.0; Verlag: mitp; Autoren: Schmidberger(Hrsg.), Schippert, Kölle, Urban, Haberbosch, Thülly [VC6] – Visual C++ 6 in 21 Tagen; Verlag: Markt und Technik; Autoren: Davis, Chapman [ACC00] – Access 2000; Verlag: Markt und Technik; Autoren: Swillus, Rex-Vogel [ACC03] – Das Access 2003 Entwicklerbuch; Verlag: Addison-Wesley; Autor: Minhorst

Seite 46 von 49

8 Anhänge

8 Anhänge Schnittstelle SPS-1 / PC Zustand Name init bereit paletteHolen paletteBringen rbgStoerungsStop fehlerQuellplatzLeer fehlerZielplatzVoll bereitFuerEntladung auftragsdatenFehlerhaft1 auftragsdatenFehlerhaft2

Binärstelle 64 32 16 8 4 2 1 Nummer online bereit gabel qFehler zFehler initFehler autftragsFehler Binäräquvalent 1 0 0 X 0 0 0 0 0; 16 2 1 1 0 0 0 0 0 96 3 1 0 0 0 0 0 0 64 4 1 0 1 0 0 0 0 80 5 0 0 X 0 0 1 0 18; 2 6 1 0 0 1 0 0 0 72 7 1 0 1 0 1 0 0 84 8 1 1 1 0 1 0 0 116 10 1 0 0 0 0 0 1 65 11 1 0 1 0 1 0 1 85

Tabelle 1: Schnittstelle SPS-1 / PC

Schnittstelle SPS-2 / PC LK 1 Zustand Name lk1Init lk1Bereit lk1AuftragBearbeiten lk1MaterialVerlohren

Binärstelle 4 2 1 Nummer lk1Online lk1Bereit lk1Fehler 1 0 0 0 2 1 1 0 3 1 0 0 4 1 0 1

Binäräquvalent 0 6 4 5

LK 2 Zustand Name lk2Init lk2Bereit lk2AuftragBearbeiten lk2Parken lk2Geparkt lk2Starten lk2MaterialVerlohren

Binärstelle 16 8 4 2 Nummer lk1Online lk1Bereit lk2MFehler lk2Wechsel 5 0 0 0 0 6 1 1 0 0 7 1 0 0 0 8 0 0 0 1 9 0 0 0 0 10 0 0 0 1 11 1 0 1 0

Tabelle 2: Schnittstelle SPS-2 / PC

Seite 47 von 49

1 lk2Geparkt Binäräquvalent 0 0 0 24 0 16 0 2 1 1 1 3 0 20

8 Anhänge

Schnittstelle SPS-3 / PC

Zustand Name komInit komBereit kom3Bearbeten kom2Bearbeten komCaseLost

Zustand Name fertInit fertBereit fertAuftragBearbeiten

Kommissionierung Binärstelle 4 2 1 Nummer lk1Online lk1Bereit lk1Fehler Binäräquvalent 1 0 0 0 0 2 1 1 0 6 3 1 0 0 4* 4 1 0 0 4* 5 1 0 1 5 *Zustände nach aussen identisch Fertigung Binärstelle 2 1 Nummer lk2Online lk2Bereit Binäräquvalent 6 0 0 0 7 1 1 3 8 1 0 2

Tabelle 3: Schnittstelle SPS-3 / PC

Schnittstelle SPS-4 / PC

Zustand Name auslagerInit auslagerBereit auslagerAuftragBearbeiten auslagerStornoMelden

Auslagerung Binärstelle 4 2 Nummer online bereit 1 0 0 2 1 1 3 1 0 4 1 0

Sorter Rückmeldungen Binärstelle Zustand 1 Name Nummer dataValid Binäräquvalent sorterWait 5 0 0 sorterSignal 6 1 1

Tabelle 4: Schnittstelle SPS-4 / PC

Seite 48 von 49

1 storno Binäräquvalent 0 0 0 6 0 4 1 5

8 Anhänge

Drei Wege Handshake-Protokol zur Absicherung der Kommando- und Meldungsübertragung Data

Data Strobe Vom Sender zum Empfänger

ACK Vom Empfänger zum Sender

DS 0 1 1 0

ACK 0 0 1 1

Beschreibung Sender darf senden Daten valide vom Sender angelegt Empfänger hat Daten gelesen: Sender darf Reset einleiten Reset-Bedingung: Empfänger muss ACK auf 0 setzen

Abbildung 23: Drei Wege Handshake-Protokoll

Seite 49 von 49