330 lines
38 KiB
Markdown
330 lines
38 KiB
Markdown
# Projektdokumentation: Optimierung der Auftragsverarbeitung eines WCS
|
||
|
||
**Prüfling:** Kai Kröger
|
||
**Prüfungsnummer:** [Deine Prüfungsnummer]
|
||
**Beruf:** Fachinformatiker
|
||
**Fachrichtung:** Anwendungsentwicklung
|
||
**Betrieb:** Gebhardt Fördertechnik GmbH
|
||
**Fachbetreuer:** Sebastian Badour & Jesper Larsson
|
||
**IHK:** IHK Rhein-Neckar
|
||
**Zeitraum:** 04.05.2026 - 25.05.2026 (80 Stunden)
|
||
|
||
---
|
||
|
||
## Verzeichnisse (zählen nicht zur 15-Seiten-Begrenzung)
|
||
* **Inhaltsverzeichnis** (mit Seitennummerierung)
|
||
* **Abbildungsverzeichnis**
|
||
* **Tabellenverzeichnis**
|
||
* **Abkürzungsverzeichnis**
|
||
|
||
---
|
||
|
||
## 1. Einleitung
|
||
### 1.1 Das Unternehmen
|
||
Die Gebhardt Fördertechnik GmbH ist ein international agierendes Familienunternehmen mit Sitz in Sinsheim, das sich auf die Entwicklung und Herstellung modularer Intralogistiksysteme spezialisiert hat. Mit über 70 Jahren Erfahrung bietet Gebhardt ein breites Spektrum an Lösungen – von der Förder- und Lagertechnik bis hin zu komplexen Warehouse Control Systemen (WCS). Ein zentraler Baustein des Portfolios ist die Softwareplattform GEBHARDT StoreWare, die Materialfluss- (MFS), Lagerverwaltungs- (LVS) und Visualisierungssysteme integriert, um eine effiziente Steuerung und Kontrolle der Warenströme in automatisierten Lagern zu ermöglichen.
|
||
|
||
### 1.2 Projektziel
|
||
Das Ziel des Projekts ist die Optimierung und Stabilisierung der Auftragsverarbeitung innerhalb des WCS. Aktuell führt die dezentrale Logik beim Starten von Transportaufträgen (OrdersHost) zu Race Conditions, da mehrere parallel laufende Prozesse simultan versuchen, denselben Auftrag zu initiieren. Dies resultiert in inkonsistenten Datenbeständen und nicht abschließbaren Auftragsleichen. Im Rahmen dieser Arbeit wird die Start-Logik im Prozess ConveyorDispo zentralisiert. Durch gezieltes Refactoring und die Implementierung thread-sicherer Mechanismen wird sichergestellt, dass Aufträge exklusiv und prozesssicher verarbeitet werden, was die Fehleranfälligkeit der Anlage signifikant reduziert.
|
||
|
||
### 1.3 Projektabgrenzung
|
||
Um den strengen zeitlichen Rahmen der IHK-Vorgabe von **exakt 80 Arbeitsstunden** einzuhalten und eine maximale Tiefe bei der architektonischen Qualitätssicherung zu gewährleisten, wurde eine präzise Abgrenzung des Leistungsumfangs vorgenommen. Dies schützt das Projekt vor "Scope Creep" (unkontrollierter Ausweitung) und fokussiert die Eigenleistung auf die softwareseitigen Kernherausforderungen (Thread-Safety und Logik-Zentralisierung).
|
||
|
||
#### 1.3.1 Kernkomponenten der Eigenleistung (In Scope)
|
||
Die eigene Entwicklungs- und Ingenieursleistung konzentriert sich auf folgende Schwerpunkte:
|
||
* **Architekturanalyse & Konzeptentwurf:** Detaillierte Code-Analyse der historisch gewachsenen Dezentralität in `HostBooking` und Konzeptionierung einer zustandsorientierten, zentralen Prozesssteuerung im `ConveyorDispo`.
|
||
* **Datenmodellerweiterung:** Anpassung des EF-Core-Modells (`OrdersHost.cs`) und der Fluent-API-Mappings (`OrdersHostEntityConfiguration.cs`) um das Übergabeflag `DepartureFlag`.
|
||
* **Zentralisierung der Startlogik (Refactoring):** Umbau von `DepartureNotificationHandler.cs` (Entzug der Sendebefugnis für Starttelegramme, reine Flag-basiere Ereignisregistrierung) sowie Erweiterung des zyklischen Workers `OrderManager.cs` im `ConveyorDispo` zur Auswertung und zentralen Kapazitätsprüfung.
|
||
* **Integrationstest & Lastsimulation:** Aufbau, Durchführung und Dokumentation einer strukturierten Testmatrix (TC-01 bis TC-05) im Emulator unter Nenn-, Spitzen- und Burst-Last zur Verifizierung der Thread-Safety.
|
||
|
||
#### 1.3.2 Bewusste Ausschlüsse aus dem Projektumfang (Out of Scope)
|
||
Die folgenden angrenzenden Themengebiete wurden nach fachlicher Prüfung aus dem Projektrahmen ausgeschlossen:
|
||
* **Ausschluss der Altsystem-Logik für EtraBoxen (Präfix 'B') & PTL-Sonderfunktionen:** Behälter vom Typ EtraBox (Präfix 'B') und manuelle Bestätigungen an "Pick-to-Light" (PTL)-Plätzen verbleiben in der dezentralen Logik. Diese erfordern manuelle Sonderbehandlungen durch das Personal (da oft kein physisches TransportCompleted-Signal der Hardware vorliegt) und wurden bewusst ausgegrenzt, um das Zeitbudget zu schonen.
|
||
* **Keine Modifikationen der WMS-Schnittstelle:** Die Schnittstellen zum übergeordneten Lagerverwaltungssystem (SAP IDoc, Datenbanktabellen `Wcs.FromWms` / `ToWms` und REST-API) werden als gegeben und stabil betrachtet. Es werden keine Anpassungen auf WMS-Ebene vorgenommen.
|
||
* **Keine Änderungen an der SPS-Firmware:** Die untergelagerten speicherprogrammierbaren Steuerungen (SPS/PLC) auf der Feldebene und deren TCP/IP-Telegramm-Strukturen sind unveränderlich. Es findet keine Softwareentwicklung in TIA-Portal/S7 statt.
|
||
* **Keine physische Inbetriebnahme vor Ort:** Die Inbetriebnahme und Abnahme erfolgen ausschließlich in der realitätsgetreuen Simulationsumgebung (Digitaler Zwilling mit Emulate3D). Eine physische Inbetriebnahme an einer realen Kundenanlage ist aufgrund des Risikos von Anlagenschäden und der zeitlichen Limitierung ausgeschlossen.
|
||
|
||
### 1.4 Projektumfeld & Schnittstellen
|
||
Das Warehouse Control System (WCS) fungiert innerhalb der Logistikkette als entscheidende Middleware. Es bildet die Brücke zwischen der administrativen Ebene (WMS) und der physischen Ausführungsebene (SPS).
|
||
|
||
#### 1.4.1 Administrative Schnittstelle (WMS/Host)
|
||
Die Anbindung an übergeordnete Lagerverwaltungssysteme (WMS) ist konfigurierbar und unterstützt zwei Kommunikationswege:
|
||
* **Datenbankgestützter Datenaustausch:** In Standard-Szenarien erfolgt der Austausch über dedizierte Schnittstellentabellen (`Wcs.FromWms` für eingehende Nachrichten und `Wcs.ToWms` für ausgehende Rückmeldungen). Die Kommunikation verläuft asynchron: Ein WMS-Prozess schreibt Auftragsdaten in die Datenbank, die vom WCS-Prozess zyklisch gepollt und in interne initiale Transportaufträge (`OrdersHost`) transformiert werden.
|
||
* **Service-orientierte Architektur (REST-API):** Für die Anbindung externer WMS-Anbieter oder Cloud-Systeme stellt das WCS einen **REST-Server** bereit. Hierbei erfolgt der Datenaustausch via HTTP/JSON-Requests, was eine nahtlose Integration in moderne IT-Infrastrukturen ermöglicht.
|
||
|
||
#### 1.4.2 Ausführungsebene (SPS/PLC)
|
||
Die unterlagerte Kommunikation mit der Fördertechnik-Hardware erfolgt über **unverschlüsselte TCP/IP-Telegramme** in Echtzeit. Dieser Bereich ist für die physische Sicherheit und den Durchsatz der Anlage kritisch:
|
||
* **Event-Handling:** Sobald eine Ladeeinheit (LE) einen Sensor passiert, sendet die SPS eine **`DepartureNotification`**. Dieses Telegramm enthält die Identifikationsnummer der LE sowie die aktuelle Position.
|
||
* **Handshake-Verfahren:** Das WCS antwortet mit einem **`Departure`**-Telegramm. Dieser Fahrbefehl ist die notwendige logische Freigabe für die SPS, um die LE physisch vom Platz wegzubewegen. Ohne dieses Telegramm verbleibt das Transportgut im Stillstand.
|
||
|
||
#### 1.4.3 Interne Persistenz und Technologie-Stack
|
||
Die prozessübergreifende Datenhaltung und Synchronisation innerhalb des WCS-Knotens basiert auf einem **Microsoft SQL Server**. Der Datenzugriff wird über das **Entity Framework Core** abstrahiert, um eine objektorientierte Verarbeitung der Materialflussdaten in C# zu ermöglichen.
|
||
|
||
#### 1.4.4 Test- und Simulationsumgebung
|
||
Zur Absicherung der Implementierung wird eine hochperformante **Emulation** der Fördertechnik innerhalb von Emulate3D eingesetzt. Diese umfasst die Förderanlage selbst, die Telegrammkommunikation zwischen WCS und der Fördertechnik, die WCS-Prozesse und eine Testdatenbank. Diese fungiert als "Digitaler Zwilling" der physischen Anlage und ermöglicht die Simulation von praxisnahen Szenarien. Dies ist insbesondere für die Reproduktion und Behebung von Race Conditions unter Hochlast-Szenarien unerlässlich.
|
||
|
||
#### 1.4.5 Relevante Prozesse (Erfüllung der IHK-Projektauflagen)
|
||
Zur präzisen Einordnung der Systemarchitektur werden nachfolgend die im Fokus der Arbeit stehenden Kernprozesse des WCS im Detail beschrieben, wodurch die formalen Projektauflagen der IHK vollumfänglich erfüllt werden:
|
||
|
||
* **Der `HostBooking`-Prozess:**
|
||
* *Beschreibung & Ziel:* Dieser asynchrone Prozess verarbeitet alle eingehenden Nachrichten und Transportaufträge des übergeordneten WMS. Seine Hauptaufgabe ist das Einlesen der WMS-Telegramme, das Anlegen interner Transportaufträge in der Tabelle `OrdersHost` und die Pflege der Ladeeinheiten-Stammdaten. Im Legacy-Zustand (IST) ist der Prozess zudem dafür verantwortlich, in bestimmten Grenzszenarien (z. B. bei der Abmeldung leerer Behälter an Kommissionierstationen) Transportaufträge direkt selbst zu starten und Freigabetelegramme an die Fördertechnik abzusenden.
|
||
* *Schnittstellen:* Der Prozess greift asynchron auf die relationalen Datenbanktabellen (z. B. `Wcs.FromWms` / `ToWms`) zu, welche wiederum durch Schnittstellen wie SAP IDoc, Webservices oder Dateitransfers vom Host-System befüllt werden.
|
||
* *Startverhalten:* `HostBooking` läuft permanent als Windows-Hintergrunddienst (Service). Er wird durch den Eingang neuer Host-Nachrichten (Polling-Verfahren der Schnittstellentabellen) getriggert.
|
||
|
||
* **Der `ConveyorDispo`-Prozess (Zentraler Materialflussrechner):**
|
||
* *Beschreibung & Ziel:* Dies ist das mathematische und logische Herzstück des Materialflussrechners. Seine primäre Aufgabe ist die Disposition und Durchführung aller physischen Transporte auf der Fördertechnik. Er koordiniert das zeitliche und räumliche Scheduling mehrerer Transporte für dieselbe Ladeeinheit (Vermeidung von Doppelstarts), führt zyklische Ressourcen- und Kapazitätsprüfungen durch (z. B. Überlastschutz an Sequenzern) und erteilt die finalen Fahrbefehle.
|
||
* *Schnittstellen:* Der Prozess kommuniziert über TCP/IP-Schnittstellensockets mit der untergelagerten SPS-Ebene (Senden von `Departure`-Fahrbefehlen) und liest/schreibt Zustandsdaten direkt in die MSSQL-Systemdatenbank.
|
||
* *Startverhalten:* Auch dieser Prozess ist als permanenter Windows-Hintergrunddienst implementiert. Er arbeitet zyklisch in Echtzeit (z. B. in festen Taktintervallen von 200 Millisekunden), um kontinuierlich den physikalischen und logischen Zustand der Anlage abzugleichen.
|
||
|
||
---
|
||
|
||
## 2. Projektplanung (Bewertung: Ressourcen & Ablauf)
|
||
### 2.1 Projektphasen & Zeitplanung
|
||
*Vergleich von Soll-Planung (Antrag) und grober Zeitübersicht.*
|
||
|
||
#### 2.1.1 Vorgehensmodell
|
||
Für die Durchführung des Projekts wird ein **hybrides Vorgehensmodell** gewählt. Dieses kombiniert die Strukturierungsstärke des klassischen, sequentiellen Phasenmodells (**Wasserfallmodell**) mit der Flexibilität und Transparenz agiler Methoden (**Kanban-Tasktracking via Azure DevOps**).
|
||
|
||
**Begründung der Modellwahl:**
|
||
* **Strikte zeitliche und inhaltliche Rahmenbedingungen:** Der IHK-Projektzeitraum ist unverhandelbar auf genau 80 Arbeitsstunden begrenzt. Um eine termingerechte Fertigstellung aller Projektphasen (von der Analyse über die Implementierung bis zur Qualitätssicherung und Dokumentation) zu garantieren, ist eine sequentielle Phasentrennung (Wasserfall) ideal. Jede Phase baut logisch auf den Ergebnissen der vorherigen auf.
|
||
* **Kontrollierte Fortschrittssteuerung (Gatekeeper-Prinzip):** Um Risiken wie "Scope Creep" (ungesteuerte Ausweitung des Projektumfangs) zu minimieren, wird ein digitales Taskboard in **Azure DevOps** eingesetzt. Das Projekt wurde in sechs Hauptphasen unterteilt:
|
||
1. *Vorbereitung* (Infrastruktur bereitstellen, Repository aufsetzen)
|
||
2. *Analyse* (IST-Zustand untersuchen, Fehlerquellen lokalisieren)
|
||
3. *Konzeptionierung* (SOLL-Logik entwerfen, UML-Modellierung)
|
||
4. *Implementierung* (Refactoring der C#-Klassen und DB-Anpassungen)
|
||
5. *Testung* (Integrationstests im Emulator)
|
||
6. *Dokumentation* (Schriftliche Ausarbeitung der IHK-Arbeit)
|
||
|
||
Für jede dieser Phasen wurde ein übergeordnetes Epic/Issue in Azure DevOps angelegt und in detaillierte Teilaufgaben (Sub-Tasks) heruntergebrochen. Gemäß dem sequentiellen Prinzip wurde die jeweils nächste Phase erst dann aktiv begonnen, wenn **alle** Issues und Bedingungen (Definition of Done) der vorherigen Phase erfolgreich abgeschlossen und im Board auf "Done" gesetzt worden waren. Dies verhinderte unkontrollierte parallele Arbeitsschritte und sicherte die hohe Qualität der Einzelergebnisse ab. Der aktuelle Projektfortschritt und der Zustand des Taskboards wurden dabei kontinuierlich visuell überwacht (siehe **Abbildung 2.1: Digitales Taskboard in Azure DevOps zur Phasensteuerung**).
|
||
|
||
#### 2.1.2 Tabellarischer Projektablaufplan (Soll-Stunden)
|
||
*Tabelle der Projektphasen mit geplanten Zeiten, die exakt der 80-Stunden-Vorgabe entsprechen (Soll-Zeitplanung).*
|
||
|
||
### 2.2 Ressourcenplanung
|
||
#### 2.2.1 Hardware
|
||
**Entwicklungs-Workstation:** Entwicklungs-PC zur Softwareerstellung und Dokumentation.
|
||
**SQL-Server:** Server zum Hosten der MSSQL Test-Datenbank der Förderanlage.
|
||
**Application-Server:** Server zum Hosten der GEBHARDT StoreWare und WCS Dienste.
|
||
**Emulations-Rechner:** Ein dedizierter Server, auf dem der „Digitale Zwilling“ der Fördertechnik läuft, um die SPS-Kommunikation (TCP/IP-Telegramme) realitätsgetreu zu simulieren.
|
||
|
||
#### 2.2.2 Software
|
||
**IDE:** Microsoft Visual Studio 2022 als primäre Entwicklungsumgebung.
|
||
**Datenbank**: Microsoft SQL Server 2019/2022 inklusive SQL Server Management Studio (SSMS) zur Datenanalyse und Schema-Anpassung.
|
||
**Frameworks**: .NET Framework / .NET Core unter Verwendung von Entity Framework Core als Object-Relational Mapper (ORM).
|
||
**Versionsverwaltung**: Git (GitLab) zur Quellcode-Verwaltung und Dokumentation der Entwicklungsschritte.
|
||
**Analyse-Tools**: InternerTelegramm-Logger zur Analyse der TCP/IP-Kommunikation zwischen WCS und Emulation.
|
||
**Dokumentation**: Microsoft Word zum Erstellen der Dokumentation und Creately zum Erstellen der UML- & Entity-Relationship-Diagramme.
|
||
|
||
#### 2.2.3 Personal
|
||
**Prüfling (Kai Kröger):** Verantwortlich für die Analyse, Konzeption, Implementierung und Qualitätssicherung des Projekts.
|
||
**Fachbetreuer (Sebastian Badour & Jesper Larrson):** Ansprechpartner für domänenspezifische Rückfragen zur WCS-Architektur und Abnahme der Projektergebnisse.
|
||
|
||
### 2.3 Kostenplanung
|
||
Die Kostenplanung basiert auf dem Personalaufwand für die Projektdauer von 80 Stunden. Da die benötigte Infrastruktur (Hardware, Lizenzen) bereits im Unternehmen vorhanden ist, fallen keine zusätzlichen Investitionskosten an.
|
||
|
||
Für die Kalkulation wird ein **kalkulatorischer Stundensatz von 65,00 €** angesetzt. Dieser setzt sich aus dem Brutto-Arbeitslohn, den Lohnnebenkosten sowie einem Gemeinkostenaufschlag für den Arbeitsplatz und die IT-Infrastruktur zusammen.
|
||
|
||
**Kostenberechnung:**
|
||
* **Gesamtkosten:** 80 Stunden × 65,00 €/Stunde = **5.200,00 €**
|
||
|
||
|
||
## 3. Analyse & Konzept (Bewertung: Ausgangssituation)
|
||
### 3.1 Ist-Analyse
|
||
Die technische Ist-Analyse der Quellcode-Basis von GEBHARDT StoreWare identifizierte zwei Haupttypen von Race Conditions, die durch die dezentrale Logik-Hoheit verursacht werden:
|
||
|
||
#### Ursachenanalyse der bestehenden Architektur
|
||
Die dezentrale Logikverteilung ist primär auf historisch gewachsene Systemerweiterungen zurückzuführen. Um Latenzzeiten bei Hardware-Antworten zu minimieren, wurden zeitkritische Telegramm-Antworten (Handshakes) direkt in den Empfangs-Handlern implementiert. Diese kurzfristige Performance-Optimierung führt jedoch zu einer Erosion der "Single Source of Truth", da prozessübergreifende Ressourcenprüfungen des `ConveyorDispo` umgangen werden.
|
||
|
||
#### A. Technische Race Condition (Status-Konflikt bei Neuanlage)
|
||
Trifft eine `DepartureNotification` für eine unbekannte Ladeeinheit (LE) ein, erzeugt der `DepartureNotificationHandler` im Prozess `HostBooking` einen neuen `OrdersHost`-Eintrag im Status `Initial`.
|
||
* **Fehlerablauf:** Der Handler speichert den neuen Eintrag ab. Fast zeitgleich greift der zyklische Worker `StartInitialOrdersHost` (Teil des Prozesses `ConveyorDispo`) auf diesen neuen `Initial`-Eintrag zu, um ihn einzuplanen und den Startvorgang einzuleiten. Wenn beide Prozesse (der asynchrone Handler und der zyklische Worker) zeitgleich versuchen, denselben Datenbank-Datensatz oder den Status der zugehörigen Ladeeinheit zu modifizieren, kommt es zu einem Konflikt.
|
||
* **Folge:**
|
||
- **Datenbank-Inkonsistenz:** Beide Prozesse konkurrieren auf Datenbankebene. Dies führt zu einer `DbUpdateConcurrencyException` (Optimistic Concurrency Conflict) im Entity Framework Core. Ein Prozess scheitert beim Speichern.
|
||
- **Auftragsleichen:** Da das Freigabetelegramm (`Departure`) zwar abgesetzt wird, der zugehörige Statusübergang in der Datenbank jedoch durch die Exception fehlschlägt, verbleibt der Auftrag in einem inkonsistenten Zwischenzustand (z. B. dauerhaft in `Initial` oder `InDestinationZone`), obwohl sich die Kiste physisch weiterbewegt hat. Diese nicht abschließbaren Einträge stauen sich als "Auftragsleichen" in der Datenbank an und müssen manuell bereinigt werden.
|
||
|
||
#### B. Architektonische Race Condition (Umgehung der Ressourcenprüfung)
|
||
Befindet sich ein Behälter im Status `InDestinationZone` (kurz vor dem Ziel), greift eine Sonderlogik für Sequencer-Anbindungen.
|
||
* **Fehlerablauf:** Der Handler im `HostBooking` ändert eigenmächtig das Ziel auf den `ConnectedSequencer` und erzwingt mittels `ForceSetStatusInProgress` den physischen Start.
|
||
* **Folge:**
|
||
- **Kapazitäts-Blindheit:** Da dieser Start am zentralen `ConveyorDispo` vorbeigeschleust wird, findet keine Prüfung der Sequencer-Auslastung (Throttling) statt. Die physische Kapazität des Sequencers wird überschritten, was zu Anlagenstaus und Deadlocks im Materialfluss führt.
|
||
|
||
### 3.2 Soll-Konzept
|
||
Das Ziel des Soll-Konzepts ist die Überführung der dezentralen Start-Logik in eine monolithische Architektur innerhalb des `ConveyorDispo`.
|
||
|
||
**Funktionale Anforderungen:**
|
||
- **Exklusivität:** Nur der Prozess `ConveyorDispo` darf den Status eines `OrdersHost`-Auftrags von `Initial` (oder einem neuen Zwischenstatus wie `ReadyToStart`) auf `InProgress` ändern und das entsprechende Start-Telegramm senden.
|
||
- **Entkopplung:** Der `DepartureNotificationHandler` wird zum reinen "Event-Melder" refactored. Er aktualisiert den physischen Ort der LE und setzt den Auftragsstatus lediglich auf `Initial`, um den Startwunsch für den `ConveyorDispo` zu signalisieren.
|
||
- **Zentralisierung:** Alle Start-Entscheidungen (inkl. Sequencer-Anbindung und Ressourcenprüfung) werden im `OrderManager` des `ConveyorDispo` konsolidiert.
|
||
- **Harmonisierung von Sonderfällen (NIO/Reject):** Bisherige "Sonderlocken" für Fehlerplätze (NIO) werden aufgelöst. NIO-Transporte werden zukünftig über den Standard-Prozesspfad abgewickelt. Dies stellt sicher, dass auch Fehler-Behälter die zentrale Ressourcenprüfung durchlaufen und nicht ungesteuert in bereits belegte oder gestörte Zielbereiche einfahren.
|
||
|
||
**Nicht-funktionale Anforderungen:**
|
||
- **Datenintegrität:** Eliminierung von `ConcurrencyExceptions` durch klare Zuständigkeitstrennung.
|
||
- **Wartbarkeit:** Reduzierung von redundantem Code (DRY) und Beseitigung von "Sonderlocken" in den Handlern.
|
||
|
||
### 3.3 Wirtschaftlichkeitsbetrachtung
|
||
Für die Bewertung des Projekts ist eine ökonomische Analyse zwingend erforderlich. Da es sich bei der Fehlerbehebung um ein präventives Refactoring handelt, basiert die kaufmännische Kalkulation auf repräsentativen Erfahrungswerten und plausiblen Annahmen aus dem Support-Alltag von GEBHARDT-Kundenanlagen. Eine absolute, historische Nachweisbarkeit einzelner Ticket-Zahlen ist für die IHK-Wirtschaftlichkeitsbetrachtung nicht gefordert; maßgeblich ist die logische Herleitung der Fehlerfolgekosten.
|
||
|
||
#### 3.3.1 Kosten des IST-Zustandes (Fehlerfolgekosten)
|
||
Im IST-Zustand verursacht die dezentrale, ungeprüfte Auftragssteuerung zwei primäre Kostenblöcke auf Kundenanlagen:
|
||
|
||
1. **Manueller Supportaufwand zur Bereinigung von "Auftragsleichen" (Technische Race Condition):**
|
||
* *Szenario:* Tritt eine technische Race Condition (Optimistic Concurrency Conflict) auf, bricht einer der Schreibvorgänge im Entity Framework Core mit einer `DbUpdateConcurrencyException` ab. Der physische Transport wird zwar ausgeführt, aber der dazugehörige Statusübergang in der Datenbank scheitert. Der Transportauftrag bleibt dauerhaft in einem inkonsistenten Status (z. B. `Initial` oder `InDestinationZone`) stecken und kann nie automatisch auf `Finished` gesetzt werden. Es entsteht eine "Auftragsleiche". Da die Rückmeldung an das übergeordnete WMS ausbleibt, kommt es zu Synchronisationskonflikten zwischen WMS und WCS (Bestandsdiskrepanzen).
|
||
* *Behebung:* Ein Support-Mitarbeiter (Hotline oder Inbetriebnehmer) muss gerufen werden. Dieser muss sich per VPN aufschalten, die Datenbank-Logs analysieren, die inkonsistenten Datensätze mittels SQL Server Management Studio (SSMS) manuell korrigieren/löschen und den Status mit dem WMS synchronisieren.
|
||
* *Kalkulationsbasis:* Es wird von durchschnittlich **zwei Vorfällen pro Woche** (vereinfacht gerechnet mit **8 Vorfällen pro Monat**) ausgegangen. Der durchschnittliche Zeitaufwand für Analyse, Behebung und Dokumentation beträgt **30 Minuten (0,5 Stunden)** pro Fall.
|
||
* *Stundensatz Support:* Angesetzt werden **80,00 € / Stunde** (vollkostenbasierter interner Verrechnungssatz).
|
||
* *Berechnung:*
|
||
$$\text{Frequenz} = 8\ \text{Fälle/Monat}$$
|
||
$$\text{Support-Kosten} = 8\ \text{Fälle/Monat} \times 0{,}5\ \text{Stunden} \times 80{,}00\ \text{€/Stunde} = \mathbf{320{,}00\ \text{€/Monat}}$$
|
||
|
||
2. **Performance-Verluste und Stauungen durch ungeprüfte Starts (Architektonische Race Condition):**
|
||
* *Szenario:* `HostBooking` startet `Initial`-Aufträge direkt, ohne die im `ConveyorDispo` zentralisierten Ressourcen- und Kapazitätsprüfungen (z. B. Throttling an den Sequenzern) zu durchlaufen. Kurzfristig wirkt dieser Sofortstart zwar schneller, da die Prüfzyklen entfallen. Auf mittlere und lange Sicht führt dies jedoch zu einer "Kapazitätsblindheit" des Systems. In Hochlastphasen werden Zonen wie Sequenzer-Vorplätze unkontrolliert überflutet.
|
||
* *Behebung / Auswirkung:* Sobald die physischen Kapazitätsgrenzen eines Sequenzers überschritten sind, stauen sich die Behälter bis auf den Hauptmaterialfluss (die Hauptförderstrecke) zurück. Dies zwingt nachfolgende Behälter für andere Zonen zu unnötigen Leerrunden (Re-Zirkulationen) auf dem Hauptloop oder führt zu temporären Blockaden der gesamten Linie. Die Gesamt-Anlagenperformance (Durchsatz) sinkt spürbar. Zur Behebung müssen Hallenmitarbeiter die Behälter manuell umsetzen.
|
||
* *Kalkulationsbasis:* Es wird von durchschnittlich **einem Vorfall pro Monat** auf einer typischen Anlage ausgegangen, der zu einer temporären Durchsatzeinbuße oder einem kurzen Linienstopp führt. Die durchschnittliche Behebungs- und Einregelzeit beträgt **15 Minuten (0,25 Stunden)**.
|
||
* *Ausfall-/Durchsatzverlustkosten:* Konservativ geschätzt mit **1.000,00 € / Stunde** für die betroffene Kommissionierlinie.
|
||
* *Berechnung:*
|
||
$$\text{Kosten durch Performance-Einbußen} = 1\ \text{Fall/Monat} \times 0{,}25\ \text{Stunden} \times 1.000{,}00\ \text{€/Stunde} = \mathbf{250{,}00\ \text{€/Monat}}$$
|
||
|
||
3. **Gesamte monatliche Fehlerfolgekosten (IST):**
|
||
$$\text{Gesamtkosten (IST)} = 320{,}00\ \text{€} + 250{,}00\ \text{€} = \mathbf{570{,}00\ \text{€/Monat}}$$
|
||
|
||
#### 3.3.2 Amortisationsrechnung (Break-Even-Analyse / Return on Investment)
|
||
Die einmaligen Projektkosten (Investitionskosten) setzen sich aus dem Personalaufwand des Prüflings für die 80-stündige Projektlaufzeit zusammen. Lizenzen und Hardware-Infrastruktur sind als Betriebskosten (Overhead) bereits im Unternehmen vorhanden.
|
||
|
||
* **Einmalige Projektentwicklungskosten (SOLL):**
|
||
$$\text{Projektkosten} = 80\ \text{Stunden} \times 65{,}00\ \text{€/Stunde} = \mathbf{5.200{,}00\ \text{€}}$$
|
||
|
||
* **Monatliche Einsparung durch das Refactoring:**
|
||
Durch die Zentralisierung der Startlogik im `ConveyorDispo` und die Einführung des thread-sicheren `DepartureFlag` werden die technischen und architektonischen Race Conditions vollständig eliminiert. Die monatliche Einsparung beträgt somit **570,00 €**.
|
||
|
||
* **Amortisationszeitraum (Break-Even):**
|
||
$$\text{Amortisationszeit} = \frac{\text{Einmalige Projektkosten}}{\text{Monatliche Einsparung}} = \frac{5.200{,}00\ \text{€}}{570{,}00\ \text{€/Monat}} \approx \mathbf{9{,}12\ \text{Monate}}$$
|
||
|
||
**Wirtschaftliches Fazit:**
|
||
Das durchgeführte Software-Refactoring amortisiert sich bereits nach **ca. 9,1 Monaten** (entspricht 9 Monaten und 4 Tagen). Ab dem 10. Monat nach dem Deployment führt das Projekt auf Kundenseite sowie in der internen Supportabteilung zu direkten Kosteneinsparungen von rund 570,00 € pro Monat. Das Projekt ist somit nicht nur technisch, sondern auch wirtschaftlich vollkommen rentabel.
|
||
|
||
---
|
||
|
||
## 4. Design & Architektur (Bewertung: Durchführung/Entscheidungen)
|
||
### 4.1 Technische Entscheidungen
|
||
* **Wahl des Synchronisationsmechanismus:** Anstatt den globalen Auftragsstatus (`TransportOrderStatus`) für die Prozessübergabe zu missbrauchen, wird ein dediziertes Handover-Flag (`DepartureFlag`) in der Tabelle `OrdersHost` eingeführt.
|
||
* **Begründung:** Dies erlaubt eine atomare Übergabe zwischen dem asynchronen Nachrichtenempfang (`HostBooking`) und der zyklischen Logikverarbeitung (`ConveyorDispo`), ohne den fachlichen Status des Auftrags zu korrumpieren. Es ermöglicht zudem die notwendige Fallunterscheidung zwischen Tracking (nur Abmeldung) und Routing (voller Startprozess).
|
||
|
||
### 4.2 Systemarchitektur
|
||
* **Zentralisierung im ConveyorDispo:** Der `StartInitialOrdersHost`-Worker wird zum zentralen Einstiegspunkt für alle Abmelde-Events.
|
||
* **Entwurfsmuster:** Einsatz des *Service-Layer-Patterns*. Die Logik für den physischen Start (Telegramm + Platz-Abmeldung) wird in den `TransportOrderService` extrahiert, um Redundanz zu vermeiden (DRY-Prinzip).
|
||
|
||
#### 4.2.1 UML-Entwurfsdiagramme
|
||
* **Soll-Aktivitätsdiagramme:** Zur Darstellung der neuen, zentralisierten Steuerungslogik im `ConveyorDispo` im Vergleich zur reduzierten Handler-Logik.
|
||
* **Sequenzdiagramm:** Visualisierung der Interaktionen und des Telegramm-Handshakes zwischen SPS, HostBooking (Empfänger), der Datenbank und ConveyorDispo (Zentrale).
|
||
|
||
### 4.3 Datenmodell-Erweiterung
|
||
* **Tabelle OrdersHost:** Ergänzung um das Feld `DepartureFlag` (Boolean, Default: false).
|
||
* **Indizierung:** Das neue Feld wird indiziert, um die Performance der zyklischen Abfragen im `ConveyorDispo` sicherzustellen.
|
||
|
||
#### 4.3.1 Entity-Relationship-Modell (ERM)
|
||
* **SOLL-ERM:** Gegenüberstellung zum IST-ERM zur grafischen Dokumentation der Anpassungen im DB-Schema.
|
||
|
||
### 4.4 Schnittstellen-Design
|
||
*Detaillierte Beschreibung der Kommunikationsprotokolle (Auflagen-Erfüllung).*
|
||
|
||
---
|
||
|
||
## 5. Realisierung (Bewertung: Durchführung/Auftragsbearbeitung)
|
||
### 5.1 Implementierung
|
||
*Wichtige Code-Ausschnitte (Fokus auf Thread-Safety und Logik-Zentralisierung).*
|
||
|
||
### 5.2 Qualitätssicherung & Testen
|
||
Die Qualitätssicherung des Refactorings erfolgt über ein mehrstufiges Testverfahren in einer realitätsgetreuen Simulationsumgebung. Da Concurrency-Probleme und Race Conditions auf einer physischen Anlage nur schwer reproduzierbar sind, wurde ein „Digitaler Zwilling“ der Fördertechnik aufgebaut.
|
||
|
||
#### 5.2.1 Testumgebung (Der Digitale Zwilling)
|
||
Die Testumgebung setzt sich aus folgenden aufeinander abgestimmten Systemkomponenten zusammen:
|
||
* **Emulate3D:** Visualisiert und berechnet das physikalische Verhalten der Förderanlage (Rollenbahnen, Lichttaster, Weichen) in Echtzeit.
|
||
* **EMC Runner (Equipment Management Controller Simulator):** Ein hochspezialisiertes In-House-Werkzeug zur Telegramm-Simulation auf TCP/IP-Ebene. Er fungiert als Emulator für die untergelagerten SPS-Steuerungen, sendet standardisierte ASCII-Ereignistelegramme (z. B. `/Function:Pick/HU:10000005/Src:.../...`) und prüft die vom WCS zurückgesendeten Freigabetelegramme (`Departure`) auf logische Korrektheit und Latenz.
|
||
* **WCS-Knoten (GEBHARDT StoreWare®):** Die modifizierten Prozesse `HostBooking` und `ConveyorDispo` laufen in einer lokalen Testinstanz und kommunizieren über unverschlüsselte TCP/IP-Sockets mit dem EMC Runner.
|
||
* **Testdatenbank:** Eine dedizierte Microsoft SQL Server-Instanz, die das relationale Schema inklusive der neuen `DepartureFlag`-Spalte abbildet.
|
||
|
||
#### 5.2.2 Strukturierte Testmatrix (Szenarien)
|
||
Die Auswahl der Testszenarien basiert auf den offiziellen Abnahmekriterien der Fachabteilung (siehe Projektauftrag / Taskboard). Dies stellt sicher, dass alle geschäftskritischen Betriebszustände und potenziellen Fehlerquellen abgedeckt sind. Die folgende Testmatrix dokumentiert die Verifizierung der funktionalen und nicht-funktionalen Anforderungen anhand dieser Abnahmevorgaben sowie einer ergänzenden Concurrency-Prüfung:
|
||
|
||
| Test-ID | Szenario / Name | Testfokus / Ziel | Eingabe / Vorbedingung | Erwartetes Ergebnis (SOLL) | Ist-Ergebnis (nach Refactoring) | Status |
|
||
| :--- | :--- | :--- | :--- | :--- | :--- | :--- |
|
||
| **TC-01** | **Normale Auslagerung (Kiste steht im Lager)** | Nachweis der korrekten Standard-Prozessabwicklung. | Ladeeinheit (LE) befindet sich im statischen Lager. Ein neuer Transportauftrag (`OrdersHost`) wird mit Status `Initial` angelegt. | `ConveyorDispo` identifiziert den neuen `Initial`-Eintrag zyklisch über `StartInitialOrdersHost`. Der Transport wird gestartet (`InProgress`), das Freigabetelegramm (`Departure`) an den EMC Runner gesendet und die LE physisch ausgelagert. | Erfolgreich durchgeführt. LE wurde ohne Latenz oder Fehler ausgelernt und transportiert. | **Pass** |
|
||
| **TC-02** | **Mehrfach-Auftrag (Kiste fährt zu Arbeitsplatz)** | Nachweis der korrekten Zustandskoordination bei Folgeaufträgen während der Fahrt. | LE befindet sich auf dem Weg zu Arbeitsplatz A (`InProgress`). WMS sendet über die Schnittstelle einen Folgeauftrag für dieselbe LE im Status `Initial`/`Pending`. | `HostBooking` fängt den neuen Auftrag ab. Da bereits ein aktiver Transport für diese LE läuft, verbleibt der neue Auftrag kontrolliert im Status `Initial`/`Pending`. Es werden keine Concurrency-Ausnahmen oder Statuskonflikte erzeugt, was die Entstehung von Datenbankleichen verhindert. | Erfolgreich. Der Folgeauftrag verbleibt im Ruhezustand, bis der aktive Transport beendet ist. | **Pass** |
|
||
| **TC-03** | **Sofortiger Folgeauftrag (Rückfahrt vom Arbeitsplatz)** | Nachweis der prozesssicheren Übergabe via `DepartureFlag` zur Verhinderung von Race Conditions bei Platzabmeldungen. | LE fährt vom Arbeitsplatz zurück ins Lager. Bei der Abmeldung am Arbeitsplatz-Sensor (`DepartureNotification`) sendet das WMS zeitgleich einen neuen Transportauftrag. | Der Handler in `HostBooking` erzwingt keinen ungesteuerten Sofortstart mehr. Er setzt stattdessen `DepartureFlag = true`. `ConveyorDispo` liest das Flag im nächsten Arbeitszyklus aus, führt alle Ressourcen- und Kapazitätsprüfungen zentral durch und startet den Transport kontrolliert. | Erfolgreich. Keine Statuskonflikte im Log. Die Startlogik verbleibt exklusiv beim `ConveyorDispo`. | **Pass** |
|
||
| **TC-04** | **Leerbehälter-Wechsel (HuChange-Simulation)** | Nachweis der korrekten Daten- und Auftragsbereinigung am Arbeitsplatz. | LE wird am Arbeitsplatz leer. Über die `FromWms`-Schnittstelle wird eine `HuChange`-Nachricht (Wechsel der HU-Nummer) simuliert. | Das WCS verarbeitet die `HuChange`-Meldung, aktualisiert die Ladeeinheiten-Stammdaten in der Datenbank, schließt den alten Transportauftrag ordnungsgemäß ab (`Finished`) und bereitet den Transport des neuen Leerbehälters fehlerfrei vor. | Erfolgreich. Alter Auftrag wurde beendet, neuer Leerbehälter-Auftrag wurde korrekt initialisiert. | **Pass** |
|
||
| **TC-05** | **Sequenzer-Einschleusung & Kapazitätsprüfung** | Nachweis der gesteuerten Freigabe und Kapazitätsprüfung beim Übergang von der Vorzone in den Sequenzer (Arbeitsplatz). | LE befindet sich in der Vorzone vor `PIC10` im Status `InDestinationZone`. Ein Abmeldesignal (`DepartureNotification`) von der Vorzone wird über das Testtool simuliert. | `HostBooking` schreibt das physische Ziel auf `SEQ10` um und setzt `DepartureFlag = true`. Der `OrderManager` im `ConveyorDispo` prüft die Sequenzer-Kapazität (< 50%). Bei freier Kapazität wird der Status auf `InProgress` gesetzt, das Freigabetelegramm gesendet und `DepartureFlag = false` gesetzt. | Erfolgreich durchgeführt. Kiste wurde kontrolliert in den Sequenzer überführt, Kapazitätsprüfung griff fehlerfrei. | **Pass** |
|
||
|
||
#### 5.2.3 Last- und Concurrency-Tests (Load Targets)
|
||
Um die Zuverlässigkeit unter realen Betriebsbedingungen zu demonstrieren, wurde das System im Emulator drei definierten Belastungsstufen ausgesetzt:
|
||
|
||
1. **Stufe 1: Nennlast (Baseline-Test)**
|
||
* **Ziel:** Nachweis der Stabilität im Normalbetrieb.
|
||
* **Lastprofil:** 1.200 Behälterbewegungen pro Stunde (ca. 1 Telegramm alle 3 Sekunden).
|
||
* **Ergebnis:** Das System lief über einen Testzeitraum von 2 Stunden absolut stabil. Alle Übergaben via `DepartureFlag` wurden latenzfrei abgearbeitet.
|
||
2. **Stufe 2: Spitzenlast (Peak-Load-Test)**
|
||
* **Ziel:** Simulation von Maximaldurchsatz (z. B. Saisongeschäft).
|
||
* **Lastprofil:** 3.600 Behälterbewegungen pro Stunde (1 Telegramm pro Sekunde).
|
||
* **Ergebnis:** Das Ressourcen-Throttling an den Sequenzern regelte die Materialflüsse fehlerfrei herunter. Es kam zu keinem physikalischen Stau oder Systemstillstand.
|
||
3. **Stufe 3: Burst-Last (Concurrency-Test)**
|
||
* **Ziel:** Gezieltes Erzeugen von Parallelzugriffen zur Verifizierung der Thread-Safety.
|
||
* **Lastprofil:** Ein Burst von 10 identischen `DepartureNotification`-Telegrammen innerhalb von 100 Millisekunden für dieselbe LE an derselben Position.
|
||
* **Ergebnis:** Während dieser Test im IST-Zustand zuverlässig zu `DbUpdateConcurrencyExceptions` im `HostBooking`-Prozess und somit zu nicht abschließbaren Datenbank-Auftragsleichen führte, blockierte die neue Flag-basierte Implementierung im SOLL-Zustand jegliche Concurrency-Konflikte. Der SQL Server verbuchte eine saubere, atomare Aktualisierung; an den EMC Runner wurde exakt ein einziges Freigabetelegramm gesendet. Die restlichen Anfragen wurden ohne Seiteneffekte verworfen.
|
||
|
||
### 5.3 Abweichungen vom Projektplan
|
||
Während der Durchführung des Projekts traten im Zuge der Qualitätssicherungs- und Testphase geringfügige Abweichungen auf, die jedoch erfolgreich kompensiert werden konnten und das Projektziel zu keinem Zeitpunkt gefährdeten.
|
||
|
||
#### 5.3.1 Technische Abweichung (Datenbank-Modellkonflikt)
|
||
Bei den Integrationstests gegen das simulierte System (Emulator) im Rahmen von **TC-03** kam es zu einem Laufzeitfehler im Entity Framework Core. Das neue Datenfeld `DepartureFlag` wurde zwar im C#-Datenmodell (`OrdersHost.cs`) und der Fluent-API-Konfiguration (`OrdersHostEntityConfiguration.cs`) vollständig implementiert, war jedoch in der physischen Microsoft SQL Server-Testdatenbank noch nicht vorhanden, da keine automatisierten Migrationen aktiviert waren. Dies führte beim Schreibzugriff zu einer `SqlException` („Ungültiger Spaltenname 'DepartureFlag'“).
|
||
|
||
**Maßnahme zur Behebung:**
|
||
Der Fehler wurde durch eine strukturelle Ursachenanalyse (Gegenüberstellung von Klassenmodell und DB-Metadaten) lokalisiert. Die Spalte wurde über ein manuelles Migrationsskript direkt auf dem SQL Server nachgezogen (`ALTER TABLE Wcs.OrdersHost ADD DepartureFlag bit NULL;`). Dieses Vorkommnis bewies den hohen Wert der Simulationsumgebung, da ein solcher Schema-Konflikt im Live-Betrieb erhebliche Ausfälle verursacht hätte.
|
||
|
||
#### 5.3.2 Soll-Ist-Vergleich der Arbeitsstunden & zeitliche Kompensation
|
||
Die Fehlersuche, Ursachenanalyse und die manuelle Behebung des Datenbankkonflikts erforderten einen unvorhergesehenen Mehraufwand von **2 Stunden** im Bereich der Qualitätssicherung.
|
||
|
||
Um die offizielle IHK-Vorgabe von **exakt 80 Stunden** Gesamtprojektdauer nicht zu überschreiten, wurde dieser Mehraufwand durch eine gezielte zeitliche Straffung der darauffolgenden Dokumentationsphase (speziell beim Strukturieren des Anhangs und des Glossars) kompensiert. Der Soll-Ist-Vergleich der Arbeitsstunden stellt sich somit wie folgt dar:
|
||
|
||
| Phase / Aktivität | Geplante Stunden (Soll) | Tatsächliche Stunden (Ist) | Abweichung | Begründung & Kompensation |
|
||
| :--- | :---: | :---: | :---: | :--- |
|
||
| **1. Projektinitiierung & Analyse** | 15h | 15h | ±0h | Planmäßig durchgeführt. |
|
||
| **2. Konzeptentwurf** | 15h | 15h | ±0h | Planmäßig durchgeführt. |
|
||
| **3. Realisierung / Refactoring** | 20h | 20h | ±0h | Planmäßig durchgeführt. |
|
||
| **4. Qualitätssicherung & Test** | 15h | **17h** | **+2h** | Mehraufwand durch EF-Core/Datenbank-Schemafehler bei TC-03. |
|
||
| **5. Projektabschluss & Dokumentation** | 15h | **13h** | **-2h** | Kompensation durch Streamlining bei Anhangs- und Glossarerstellung. |
|
||
| **Gesamtprojektdauer** | **80h** | **80h** | **±0h** | **Der vorgegebene 80-Stunden-Rahmen wurde exakt eingehalten.** |
|
||
|
||
---
|
||
|
||
## 6. Projektabschluss (Bewertung: Auftragsergebnisse)
|
||
### 6.1 Soll-Ist-Vergleich
|
||
*Überprüfung, ob alle Ziele des Soll-Konzepts erreicht wurden.*
|
||
|
||
### 6.2 Abnahme & Übergabe
|
||
*Protokoll der Übergabe an die Fachabteilung/QS.*
|
||
|
||
#### 6.2.1 Übergabe- und Abnahmeprotokoll
|
||
*Referenz auf das vom Fachbetreuer unterzeichnete Abnahmedokument im Anhang.*
|
||
|
||
### 6.3 Fazit & Ausblick
|
||
*Persönliches Resümee und mögliche Erweiterungen.*
|
||
|
||
---
|
||
|
||
## Anhang (Zählt nicht zu den 15 Seiten)
|
||
### Anhang A: System- und Entwicklerdokumentation (Wartungshandbuch)
|
||
*Technische Dokumentation für das Entwickler- und Support-Team zur Wartung, Diagnose und Fehlersuche (inkl. SQL-Leitfaden).*
|
||
|
||
### Anhang B: Prozess- und Ablaufdiagramme (UML)
|
||
* **Anhang B.1:** UML-Aktivitätsdiagramm — IST-Zustand `HostBooking` (Dezentrale, fehleranfällige Startlogik)
|
||
* **Anhang B.2:** UML-Aktivitätsdiagramm — SOLL-Zustand `HostBooking` (Zentralisierte Ereignisregistrierung)
|
||
* **Anhang B.3:** UML-Aktivitätsdiagramm — SOLL-Zustand `ConveyorDispo` (Zentraler, kapazitätsgeschützter Auftragsstart)
|
||
|
||
### Anhang C: Quellcode-Dokumentation (Refactoring-Ausschnitte)
|
||
*Gegenüberstellung und Kommentierung der geänderten C#-Klassen (`DepartureNotificationHandler.cs`, `OrderManager.cs`, `StartInitialOrdersHost.cs`).*
|
||
|
||
### Anhang D: Übergabe- und Abnahmeprotokoll
|
||
*Das offizielle, vom Fachbetreuer unterzeichnete Abnahme- und Übergabeprotokoll der QS-Abteilung.*
|
||
|
||
---
|
||
|
||
## Glossar & Quellenverzeichnis (Zählt nicht zu den 15 Seiten)
|