Projekt Dokumentation - Übersicht Projekte

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

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 SPS-
Steuerungen 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 Produktivumgebung
1.3.1 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
sein. Diese können aber nebeneinander auf einer Palette angeordnet
werden.
Abbildung 6: Eine Palette
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 CLagerverwaltung und CAuftragsverwaltung haben Zugriff auf die
Datenbankschnittstelle.
Seite 16 von 49

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
Lagerverwaltung
Auftragsverwaltung
RGB - Steuerung
Portalkran 1 -
Steuerung
Produktion -
Steuerung
Kommisionier -
Steuerung
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 (Datenbank-
Management-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, EinlagerungsauftragSet,
AuslagerungsauftragSet, FertigungsauftragSet, ArbeitsgangSet) generiert.
Seite 18 von 49

3 Modellierung und Realisierung
3.1.1 ER-Diagramm
Material
PK,I1
matId
bez
Arbeitsgang
LHMContainer
PK,I1
arbgId
PK,I1
lhmContainerId
FK1,I2
I3
beschreibung
maschParam
quellMatId
zielMatId
FK1,I2
matId
mengeMat
mischContainer
virtuell
Auslagerungsauftrag
PK,I1
ausAufId
Produktionsauftrag
PK,I2
prodAufId
Einlagerungsauftrag
PK,I1
einAufId
FK2,I3
FK1,I2
zielTermin
matId
menge
lhmContainerId
erfasst
FK1,I1
arbgId
anzTeile
anzGefTeile
zieltermin
erfasst
I2
FK1,I3
FK2,I4
lhmId
lhmContainerId
matId
Kommisionierauftrag
PK,I1
FK2
FK1,I2
kommAuftrId
mat1Id
mengeMat 1
tatMengeMat 1
mat2Id
mengeMat 2
tatMengeMat 2
lhmContainerId
zielTermin
erfasst
Lager
PK,I2
Fertigungsauftrag
fertAufId
PK,I1
I2
lagerId
yposition
zposition
xposition
lhmId
MaterialAbfrage
matId
bez
Abbildung 11: ER-Diagramm
termin
FK4,I6 prodAufId
I5 lhmId
sollAnzQuelleTeile
FK2,I3 kommAuftrId
FK3 lhmContainerIdMat 1
lhmContainerIdMat 2
lhmContainerIdLeer
lhmIdMat1
lhmIdMat2
lhmIdLeer
FK1,I1 ausAufId
I4 lhmContainerId
LHM_ft
FK1,FK2,FK2,FK2,FK2,FK3,I1
FK4
lhmId
lhmContainerIdL
lhmContainerIdR
Seite 19 von 49

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
CJobFactory
CSPS1Job
CSPS3KomJob
CSPS4Job
CClearJob
CSPS2Job
CSPS3ProdJob
Abbildung 12: JobManagement Klassenausschnitt
CSPS4RejJob
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 wird eine Instanz des
JobManagers angelegt. Der folgende Aufruf von der
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
main() Aufruf
JobManager
Instance()
&CJobManager
Control()
Seite 25 von 49

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

3 Modellierung und Realisierung
die noch nicht angefangen worden sind werden keine neuen Aufträge beantragt. Sollte die Auftragsliste leer
sein, wird über die Auftragsverwaltung nach neuen Aufträgen gefragt. Diese werden dann in die Auftragsliste
übernommen. Die Auftragsliste selbst ist vom Typ std::deque und hat als Elemente Zeiger auf Objekte vom
Typ CAuftrag, weshalb auch Spezialisierte Objekte vom Typ CAuslagerungsauftrag, CProduktionsauftrag,
CEinlagerungsauftrag und CPendingAuftrag an diesem Pointer hängen können.
Für jeden Auftrag in der Liste wird nun an die JobFactory übergeben, diese prüft ob der Auftrag momentan
verarbeitet werden kann, falls ja liefert diese eine Verkettung von AJob Objekte zurück. Darauf untersucht
der JobManager den ersten Job der Verkettung und sortiert diesen in die jeweilige Queue der SPS ein,
vorausgesetzt der Auftrag kann durchgeführt werden. Konnte der Auftrag zum momentanen Zeitpunkt nicht
bearbeitet werden (in der Regel liegen Ressourcen Defizite vor), wird der Auftrag an das hintere Ende der
Queue gestellt, und an einem späteren Zeitpunkt geprüft ob er nun abgearbeitet werden kann.
Sobald ein Job in eine Queue gesetzt wird, wird das korrespondierende Event gesetzt, um der
entsprechenden SPS zu signalisieren dass ein neuer Job für sie bereit steht.
3.5.1.3 RequestJob
Diese Methode wird von den SPS' aufgerufen falls sie sich in dem Zustand befinden, einen neuen Job
entgegen nehmen zu können.
Anhand des aufrufenden Objektes wird entschieden welche Spezialisierte Methode von RequestJob
verwendet werden muss. Der Ablauf in den spezialisierten Methoden hingegen ist immer der selbe, nur die
korrespondierende Liste ist eine andere.
Abbildung 13 sollte dies näher erläutern.
[Event signalisiert ]
KA verlassen
blockieren
[Liste leer]
Nächsten Job aus Liste entnehmen
[Event nicht signalisiert ]
[Liste hat Elemente]
[KA frei]
KA betreten
[KA vergeben]
blockieren
[KA frei]
Abbildung 13: RequestJob
Seite 28 von 49

3 Modellierung und Realisierung
3.5.1.4 ReportJob
Diese Methode wird von den SPS' verwendet um einen abgearbeiteten oder fehlerhaften Job zu berichten.
Ein JobReport hat folgenden Aufbau:
CJobReport
Errorcode
Message
AJob
Konkreter Job
Abbildung 14: CJobReport
Zuerst wird ermittelt welche konkrete Ausprägung von ReportJob die Weiterverarbeitung übernimmt. Für
jede Art Job existiert eine eigene Methode welche diesen Job verarbeitet. Anhand der Laufzeitklasse des
Jobs welcher an den Report gebunden ist wird die entsprechende Methode in einer Case Anweisung
aufgerufen.
Im Gegensatz zu den RequestJob Methoden ist der Workflow der Reportklassen von Job zu Job
unterschiedlich, da diese auch die Fehlerbehandlung übernehmen und die von Job zu Job unterschiedlich
sind.
Die nächsten Abschnitte befassen sich mit dem genaueren Reporting und haben die Struktur:
Fehlersituation - Reaktion
ReportSPS1Job
Kein Fehler:
Den folgenden Job in die entsprechende Liste einsortieren.
Falls die Palette, welche befördert wurde, sich im Lager befindet wird
sie wieder eingecheckt.
Quelle ist leer:
Ziel ist belegt:
Den Auftrag löschen und belegte Resourcen löschen.
Die Palette auf der Gabel wird zu einer speziellen Lager Position
gefahren, und der Auftrag gelöscht.
ReportSPS2Job
Kein Fehler:
Kran2 geparkt:
Den folgenden Job in die entsprechende Liste einsortieren.
Es werden alle Jobs die für den Portalkran 2 bestimmt waren in die
JobListe für den Portalkran 1 umgelagert, weiterhin werden keine
weiteren Jobs in die Liste des Portalkrans 2 einsortiert.
Seite 29 von 49

3 Modellierung und Realisierung
Kran2 bereit:
Palette voll:
Es werden Jobs für den Portalkran 2 in die entsprechende Liste
einsortiert.
Gruppe 2 legt Material im Blocklager ab.
ReportSPS3ProdJob
Die Palette auf der Gabel wird zu einer speziellen Lager Position
gefahren, und der Auftrag gelöscht.
Kein Fehler:
Den folgenden Job in die entsprechende Liste einsortieren
ReportSPS3KomJob
Kein Fehler:
Paket verloren:
Den folgenden Job in die entsprechende Liste einsortieren.
Den Auftrag löschen. Falls das Paket bei Gruppe 4 auftauchen sollte
wird dieses Eingelagert solange kein Auslagerungsauftrag für dieses
Paket vorhanden ist.
ReportSPS4Job
Kein Fehler:
Analhand der Information auf welchem Band das Material liegt werden
alle nötigen Jobs zur Einlagerung geplant. Sollte die Einlagerung
momentan nicht durchgeführt werden können wird ein
CPendingAuftrag generiert welcher in die Auftragsliste eingefügt wird
und eine Referenz auf die zu generierende Methode beinhaltet.
In dem nächsten Release wäre geplant gewesen das Löschen der Aufträge durch Neugenerierung der Jobs
aus dem Auftrag zu ersetzten.
Diese Methoden könnte man beliebig komplizieren, jedoch mussten wir uns aus zeitlichen Gründen auf
simplere Lösungen konzentrieren.
Job Beschreibung
3.5.2 Job Beschreibung
Ein Job ist eine Businessobjekt welches lediglich Daten enthält, welche eine SPS zur Durchführung eines
Auftrages benötigt. Weiterhin besitzt jeder Job einen Zeiger auf einen Job welcher nach der Abarbeitung des
momentan Jobs durchgeführt werden soll. Der folgende Job kann sich jedoch von dem momentan
unterscheiden.
Seite 30 von 49

3 Modellierung und Realisierung
Die Basisklasse AJob dient als Oberklasse aller Jobs und implementiert die Methoden zur Verkettung.
Die nun folgenden Unterklassen von AJob ergänzen die Klasse lediglich um weiter Attribute.
CSPS1Job
+m_Palette : CLHM_Palette &
+m_TargetPos : Position
Dieser Job beinhaltet die Informationen für zur Steuerung des
Regalbediengerätes. Dar ein Objekt vom Typ CLHM_Palette zu jeder Zeit
seine Position weiß,
AJob
+m_ErrorCode : int
+m_Auftrag : CAuftrag &
-m_NextJob : AJob *
+classAJob : CRuntimeClass
+AJob(ein aAuftrag : CAuftrag &)
+AJob(ein aJob : const AJob &)
+~AJob()
+operator =(ein aJob : const AJob &)
+DeleteFollowingJobs()
+Next() : AJob *
+Next(ein aJob : AJob*)
+Last() : AJob *
+Last(ein aJob : AJob*)
+Auftrag() : CAuftrag &
+Print(ein out : ostream &) : ostream &
genügen als Attribute eine Referenz auf die zu
befördernde Palette sowie eine Positionsangabe zu welcher das Lagerhilfsmittel befördert werden soll.
Ein CSPS2Job Objekt, wird benötigt um einen Portalkran zu steuern.
Dieses beinhaltet zum einen die Palette in welche etwas hinzugefügt oder
entfernt werden soll sowie eine Richtungskodierung in Form eines Flags.
CSPS2Job
+CAuftrag : CSPS2Job
+m_Palette : CLHM_Palette &
+m_TargetPos : Position
+m_MatIsLeft : bool
+m_FromPaletteToPos : bool
CSPS3KomJob Für die Kommisionierung steht links stehendes Klassenkonstrukt zur
+m_bIsKommAuftrag3 : bool Verfügung. Es beinhaltet lediglich ein Attribut welches kodiert ob es sich um
eine Kommisionierung mit zwei oder drei Containern handelt.
Ein CSPS3Objekt dient zur Bohrmusteränderung an der SPS3 Steuerung. Jedes
Bohrmuster entspricht einer Integer Zahl.
CSPS3ProdJob
+m_iPattern : int
CSPS4RejJob
+m_iId : int
+m_bIsContainer : bool
+m_bIsStorno : bool
Mittels des CSPS4RejJobs werden Auslagerungsaufträge an die SPS4 Steuerung
weitergegeben, bzw. Auslagerungsaufträge können damit storniert werden.
Der rechts stehende Job dient Ausschließlich dem Reporting eines
Einlagerungsauftrag. Er wird in einer SPS Klasse generiert und dem JobManager
berichtet, aus der Id und der Band Nummer kann darauf hin die Einlagerung
geplant werden.
CSPS4Job
+m_iMaterialID : int
+m_iContainerID : int
+m_bIsStorno : bool
+m_iBandNr : int
Seite 31 von 49

3 Modellierung und Realisierung
3.5.3 CJobFactory
Die JobFactory übernimmt die Aufgabe aus einem Auftrag eine Verkettung von Jobs zu generieren welche
den SPS Klassen übermittelt werden können. Weiterhin bietet sie Methoden zur Erzeugung von einzelnen
Jobs. Zu jedem Zeitpunkt kann in dem System nur eine Instanz dieser Klasse existieren weshalb diese als
Singelton implementiert wurde. Ausschließlich der JobManager kommuniziert mit dieser Klasse.
CJobFactory
+~CJobFactory()
+Instance()
+CreateJobs()
+CreateStocking()
+CreateSPS1Job()
+CreateSPS2Job()
+CreateSPS3KomJob()
+CreateSPS3ProdJob()
+CreateSPS4Job()
+CreateSPS4RejJob()
+CreateClearJob()
+CreateStocking()
+CreateSPS1JobToSavePos()
-CJobFactory()
-CreateProductionJobs()
-CreateRejectionJobs()
-CreatePickingJobs()
Durch die Auslagerung der Job Generierung in eine separate Klasse ist es möglich diese Geschäftslogistik
an einer zentralen Stelle zu pflegen oder sogar auszutauschen. In dem nächsten Release wäre auch noch
eine Auslagerung der einzelnen Algorithmen zur Erzeugung der Jobs in eigene Klassen sinnvoll gewesen.
Im Folgenden werden kurz die wichtigstes Schnittstellen besprochen.
3.5.3.1 CreateJobs
Dieser Methode wird eine Referenz auf einen Auftrag übergeben. An Hand des Auftrages wird dann
entschieden welche der gelisteten Methoden die Weiterverarbeitung übernimmt.
– CreateProductionJobs()
– CreateRejectionJobs()
– CreatePickingJobs()
Die Differenzierung wird abermals über die Laufzeitklasse des Objektes ermittelt.
3.5.3.2 CreateProductionJobs
Soll ein Produktionsauftrag durchgeführt werden generiert diese Methode alle benötigten Jobs und verkettet
diese miteinander. Folgendes Aktivitätsdiagramm beschreibt die Generierung genauer.
Das Sequenzdiagramm (siehe Abbildung 15) zeigt den strukturellen Ablauf bei der Generierung der
Seite 32 von 49

3 Modellierung und Realisierung
benötigten Jobs. Die Anzahl der benötigten Objekte kann natürlich in Abhängigkeit von der Menge des zu
produzierenden Materials variieren.
3.5.3.3 CreateRejectionJobs
Diese Methode generiert die benötigten Jobs zur Auslagerung. Eine Auslagerung entspricht in etwa einer
Produktion mit dem Unterschied dass das spezielle Bohrmuster 0 an die SPS3 übergeben wird.
Nach erfolgreicher Generierung könnte folgende Objektverkettung auf dem Heap vorliegen:
CSPS 1Job CSPS3ProdJob CSPS2Job CSPS1Job CClearJob
«bind»
«bind»
Die Einzelnen Schritte wären demzufolge:
1. Palette mit dem RGB aus dem Lager auf einen Kettenförderer stellen.
2. Der Produktionsstraße das Bohrmuster 0 übermitteln.
3. Mit dem Portalkran das Material aus der Palette auf das Förderband der Produktion ablegen.
4. Palette wieder zurück in das Lager zu ihrer Ausgangsposition.
5. Den genutzten Kettenförderer für weitere Jobs freigeben.
3.5.3.4 CreatePickingJobs
CreatePickingJobs generiert aus einem Kommisionierauftrag die benötigten Jobs, und liefert diese als
verkettete Objekte zurück.
Nach der erfolgreichen Generierung eines Kommisionierauftrags mit 3 Containern, könnte die mögliche
Objektverkettung wie folgt aussehen.
Seite 33 von 49

3 Modellierung und Realisierung
CSPS 1Job CSPS3KomJob CSPS2Job CSPS1Job
«bind» «bind» «bind»
«bind»
CSPS1Job
CSPS1Job
CSPS2Job
CSPS1Job
CSPS2Job CSPS1Job CClearJob
Die Einzelnen Schritte wären demzufolge:
1. Palette mit einem Container aus dem Lager auf einen Kettenförderer befördern.
2. Der Kommisionierstraße einen 3er Kommisionierauftrag erteilen.
3. Den entsprechenden Container aus der Palette auf das Förderband stellen.
4. Die Palette zurück in das Lager stellen.
5. Palette mit einem leeren Container aus dem Lager holen.
6. Mit dem Portalkran den Container auf das Förderband stellen.
7. Die Palette zurück in das Lager räumen.
8. Palette mit dem Container für das 3. Material besorgen und auf den Kettenförderer stellen.
9. Den letzten Container auf das Kommisionierband abstellen.
10. Die Palette zurück in das Lager befördern.
11. Den genutzten Kettenförderer freigeben.
Die JobFactory bietet noch eine Menge Potenzial an Optimierungen, die leider aus Zeitgründen nicht näher
betrachtet wurden.
Seite 34 von 49

3 Modellierung und Realisierung
Abbildung 15: CreateProductionJobs()
Seite 35 von 49

3 Modellierung und Realisierung
3.6 SPS Kommunikation
Als Schnittstelle zwischen den einzelnen Speicherprogrammierbaren Steuergeräten (nachfolgend SPSG
genannt) und der Steuersoftware auf dem PC dienen die SPS-Klassen (nachfolgend SPSK bezeichnet). Auf
PC-Seite wurde die Schnittstelle sehr schmal gehalten. Lediglich der JobManager ist über das IJobService-
Interface mit der ASPSBase-Klasse gekoppelt.
Die SPSK kapseln die komplette Kommunikation über den Feldbus. Des weiteren repräsentieren sie als
Zustandsautomaten die jeweiligen Zustände der SPSG. Die SPSK überwachen die SPSG und reagieren
entsprechend auf jede Zustandsänderung.
Im wesentlichen besteht die Aufgabe der SPSK darin, einen Job vom Jobmanager abzuholen, diesen Job
über den Feldbus an das entsprechende SPSG zu senden, sodann die Arbeit der SPSG zu überwachen und
schließlich dem Jobmanager das Ergebnis des Jobs zurückzumelden. Während der Lebensdauer einer
SPSK wiederholt sich dieser Zyklus immer wieder.
Um einen Job vom Jobmanager abzuholen muss sich die SPS (wird als zusammenfassender Begriff für
SPSG und die korrespondierende SPSK verwendet) im Zustand BEREIT befinden. Nun muss unterschieden
werden, ob der Zustand BEREIT nach der Initialisierung folgt, oder ob zuvor gerade ein Job bearbeitet
wurde. Ist dies der Fall, so muss zuerst der zuletzt bearbeitete Job an den Jobmanager zurückgemeldet
werden. Sofort nachdem der Job zurückgemeldet wurde, kann vom Jobmanager ein neuer Job abgeholt
werden. Sollte der Jobmanager gerade keinen Job für die entsprechende SPS in seiner Queue haben,
blockiert die SPSK solange bis ein Job vorhanden ist. Erst danach kehrt der Job-Request vom Jobmanager
zurück.
Da sich das SPSG zwangsläufig immer noch im Zustand BEREIT befindet (von Fehlersituationen einmal
abgesehen) wartet es auf einen neuen Job der von der SPSK nun gesendet werden kann. Je nach Aufgabe
der SPS wird nun ein entsprechender Job über den Feldbus gesendet. Das SPSG beginnt sofort nach Erhalt
des Jobs diesen zu bearbeiten. Ggf. werden weitere Zustände vom SPSG gemeldet. Im Regelfall kehrt das
SPSG in den Zustand BEREIT zurück, was mit einer erfolgreichen Bearbeitung des Jobs einhergeht. Sollte
ein Fehler während der Bearbeitung aufgetreten sein, so wird dieser von der SPSK entsprechend im Job-
Report vermerkt. Der Job-Report dient dazu einen Job als bearbeitet an den Jobmanager zurückzumelden.
Der Jobreport besteht aus dem bearbeiteten Job selbst, einem definierten Fehlercode, sowie einem
Container für zusätzliche (beliebige) Daten. Nachdem der Job-Report an den Jobmanager gemeldet wurde
beginnt der Zyklus erneut. Dieses Verhalten läuft in einer Endlosschleife während der gesamten Laufzeit des
Steuer-Programms.
3.6.1 Kommunikation über den Feldbus via Handshakeprotokoll
Um die Kommunikation zwischen SPSG und SPSK (PC) über den Feldbus zu regeln wird ein einfaches
Handshakeprotokoll verwendet. Das Protokoll war vorgegeben und wird hier nur der Vollständigkeit wegen
kurz erläutert. Benutzt werden zusätzlich zu den eigentlichen Datensignalen noch zwei weitere Signale: DS
Seite 36 von 49

3 Modellierung und Realisierung
und ACK.
Um dem Empfänger zu signalisieren dass momentan gültige Daten anliegen wird vom Sender das DS
aktiviert. Der Empfänger lässt solange DS und die Daten anliegen, bis vom Empfänger nach erfolgreichem
Lesen der Daten das ACK kommt. Nun setzt der Sender das DS zurück, der Empfänger weiß dass jetzt
keine gültigen Daten mehr anliegen und nimmt sein ACK ebenfalls zurück. Beide befinden sich schließlich
wieder in der Ausgangssituation. Die Sender, Empfänger-Rollen können nun getauscht oder beibehalten
werden.
3.6.2 Kapselung des Feldbus durch CAktor und CSensor
Für die Kommunikation über den Feldbus wurde von der Firma PHOENIX CONTACT diverse Funktionen zur
Verfügung gestellt. Darüber hinaus standen zwei Klassen zum Lesen (CSensor) bzw. Schreiben (CAktor)
eines einzelnen Bits zur Verfügung.
CSensor wurde um eine Methode erweitert die es ermöglicht ein komplettes Byte mit Hilfe der PHOENIX
CONTACT-Funktionen zu lesen, CAktor wurde ebenfalls um eine Methode erweitert und kann nun ein
komplettes Byte schreiben. Dies vereinfacht das Handling des Buses erheblich. Prinzipiell können die
Methoden auch benutzt werden um Wörter, Doppel-Wörter oder beliebig viele Bits in einem Rutsch zu
verwalten.
3.6.3 Die SPS-Klassen
Insgesamt existieren zur Laufzeit sechs SPSK-Instanzen in je einem eigenen Thread. Die SPSK werden
beim Programmstart vom Jobmanager erzeugt und dieser startet dann auch die Threads.
Die SPSK lassen sich in 5 Kategorien unterteilen. Zum einen die Basis-Klasse, zum anderen die Klassen für
die vier zu steuernden SPSG.
Die einzelnen Abläufe innerhalb der SPSK werden nur kurz erläutert und sind den Aktivitätsdiagrammen zu
entnehmen.
3.6.3.1 SPS-Basisklasse (ASPSBase)
Die abstrakte Vaterklasse aller weiteren SPS-Klassen stellt die Schnittstelle nach außen zur Verfügung.
Sowohl für die restlichen PC-Steuerprogramm-Komponenten, als auch über den Feldbus zu den SPSG. Die
Schnittstelle zum PC-Steuerprogramm, beschränkt sich auf die Erzeugung der SPSK durch den
Jobmanager, sowie das Erbitten (request) und das Zurückmelden (report) eines Jobs.
Für die Kommunikation mit den SPSG steht eine virtuelle Methode bereit, die einen Job an das SPSG
sendet. Diese wird von den von ASPSBase abgeleiteten Klassen implementiert, da für jedes SPSG
entsprechend unterschiedliche Jobs gesendet werden.
Seite 37 von 49

3 Modellierung und Realisierung
3.6.3.1.1 Handshakeimplementierung
Die Kommunikation zwischen PC und SPSG wird über das weiter oben erwähnte Handshakeprotokoll
geregelt. Dazu bietet die ASPSBase für jede Kommunikationsrichtung (von PC zu SPS und umgekehrt) je
drei Methoden.
Vom PC zur SPS, also zum Senden sind das: hsPC2SPSInit(), hsPC2SPSTransferBegin()
hsPC2SPSTransferComplete()
●
●
●
hsPC2SPSInit() wartet solange bis das SPSG
empfangsbereit ist, d.h. bis SPS.DS == SPS.ACK
== false.
hsPC2SPSTransferBegin() signalisiert dem
SPSG dass Daten anliegen, d.h. PC.DS = true
hsPC2SPSTransferComplete) wartet solange bis
das SPSG das Lesen der Daten bestätigt, d.h. bis
SPS.ACK == true danach PC.DS = false
Für die umgekehrte Richtung, also zum Empfang
existieren die drei Methoden:
●
hsSPS2PCInit() wartet bis vom SPSG Daten
gesendet werden, d.h. bis SPS.DS == true
Abbildung 16: Handshake PC -> 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 den
momentanen Zustand
der Datenbank, also des
Lagers besitzt, kann
innerhalb der CSPS1-
Klasse nicht sinnvoll auf
Fehler die vom RBG
Abbildung 18: Aktivitätsdiagramm zu CSPS1
gemeldet werden
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 Park-Flag, zurückgemeldet.
Sobald der 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 Optimierungspotential in
Hinsicht auf die Gesamtsystemgeschwindigkeit
besteht. Zusätzlich hat
dieses zentrale Design rund um den
Jobmanager eine asynchrone
Kommunikation, der in getrennten
Threads laufenden SPSK, erübrigt.
Da das SPSG, welches die beiden
Portalkräne steuert, die Koordinaten
Abbildung 19: Aktivitätsdiagramm zu CSPS2PK1
der Kettenförderer anders interpretiert
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 CSPS3KomNoIBS CSPS3ProdNoIBS CSPS4NoIBS
«uses» «uses» «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
Tabelle 1: Schnittstelle SPS-1 / PC
Schnittstelle SPS-1 / PC
Binärstelle
Zustand 64 32 16 8 4 2 1
Name Nummer online bereit gabel qFehler zFehler initFehler autftragsFehler Binäräquvalent
init 1 0 0 X 0 0 0 0 0; 16
bereit 2 1 1 0 0 0 0 0 96
paletteHolen 3 1 0 0 0 0 0 0 64
paletteBringen 4 1 0 1 0 0 0 0 80
rbgStoerungsStop 5 0 0 X 0 0 1 0 18; 2
fehlerQuellplatzLeer 6 1 0 0 1 0 0 0 72
fehlerZielplatzVoll 7 1 0 1 0 1 0 0 84
bereitFuerEntladung 8 1 1 1 0 1 0 0 116
auftragsdatenFehlerhaft1 10 1 0 0 0 0 0 1 65
auftragsdatenFehlerhaft2 11 1 0 1 0 1 0 1 85
Tabelle 2: Schnittstelle SPS-2 / PC
Schnittstelle SPS-2 / PC
LK 1
Binärstelle
Zustand 4 2 1
Name Nummer lk1Online lk1Bereit lk1Fehler Binäräquvalent
lk1Init 1 0 0 0 0
lk1Bereit 2 1 1 0 6
lk1AuftragBearbeiten 3 1 0 0 4
lk1MaterialVerlohren 4 1 0 1 5
LK 2
Binärstelle
Zustand 16 8 4 2 1
Name Nummer lk1Online lk1Bereit lk2MFehler lk2Wechsel lk2Geparkt Binäräquvalent
lk2Init 5 0 0 0 0 0 0
lk2Bereit 6 1 1 0 0 0 24
lk2AuftragBearbeiten 7 1 0 0 0 0 16
lk2Parken 8 0 0 0 1 0 2
lk2Geparkt 9 0 0 0 0 1 1
lk2Starten 10 0 0 0 1 1 3
lk2MaterialVerlohren 11 1 0 1 0 0 20
Seite 47 von 49

8 Anhänge
Tabelle 3: Schnittstelle SPS-3 / PC
Schnittstelle SPS-3 / PC
Kommissionierung
Binärstelle
Zustand 4 2 1
Name Nummer lk1Online lk1Bereit lk1Fehler Binäräquvalent
komInit 1 0 0 0 0
komBereit 2 1 1 0 6
kom3Bearbeten 3 1 0 0 4*
kom2Bearbeten 4 1 0 0 4*
komCaseLost 5 1 0 1 5
*Zustände nach aussen identisch
Fertigung
Binärstelle
Zustand 2 1
Name Nummer lk2Online lk2Bereit Binäräquvalent
fertInit 6 0 0 0
fertBereit 7 1 1 3
fertAuftragBearbeiten 8 1 0 2
Tabelle 4: Schnittstelle SPS-4 / PC
Schnittstelle SPS-4 / PC
Auslagerung
Binärstelle
Zustand 4 2 1
Name Nummer online bereit storno Binäräquvalent
auslagerInit 1 0 0 0 0
auslagerBereit 2 1 1 0 6
auslagerAuftragBearbeiten 3 1 0 0 4
auslagerStornoMelden 4 1 0 1 5
Sorter Rückmeldungen
Binärstelle
Zustand 1
Name Nummer dataValid Binäräquvalent
sorterWait 5 0 0
sorterSignal 6 1 1
Seite 48 von 49

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 ACK Beschreibung
0 0 Sender darf senden
1 0 Daten valide vom Sender angelegt
1 1 Empfänger hat Daten gelesen: Sender darf Reset einleiten
0 1 Reset-Bedingung: Empfänger muss ACK auf 0 setzen
Abbildung 23: Drei Wege Handshake-Protokoll
Seite 49 von 49