# Projektdokumentation: Optimierung der Auftragsverarbeitung eines WCS

**Prüfling:** Kai Kröger  
**Beruf:** Fachinformatiker für Anwendungsentwicklung  
**Betrieb:** Gebhardt Fördertechnik GmbH  
**Zeitraum:** 04.05.2026 - 25.05.2026 (80 Stunden)

---

## 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 Projektumfeld & Schnittstellen
*Einordnung des WCS in die Systemlandschaft (SAP, Host-Systeme). Spezifikation der Schnittstellen (TCP/IP, IDocs).*

---

## 2. Projektplanung (Bewertung: Ressourcen & Ablauf)
### 2.1 Projektphasen & Zeitplanung
*Vergleich von Soll-Planung (Antrag) und grober Zeitübersicht.*

### 2.2 Ressourcenplanung
*Hardware, Software-Stack (C# .NET), Personal.*

### 2.3 Kostenplanung
*Kalkulation der Personalkosten für 80 Stunden und potenzielle Sachkosten.*

---

## 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:

#### 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:** Noch während der Handler-Durchlauf aktiv ist, sendet er ein Start-Telegramm an die SPS. Parallel dazu identifiziert der zyklische Worker `StartInitialOrdersHost` (Teil des Prozesses `ConveyorDispo`) den neuen `Initial`-Eintrag und initiiert seinerseits einen Startvorgang.
* **Folge:** 
  - **Telegramm-Kollision:** Die SPS erhält zeitnah zwei Start-Befehle für dieselbe LE, was zu Fehlsteuerungen führt.
  - **Datenbank-Inkonsistenz:** Beide Prozesse versuchen simultan den Datensatz zu aktualisieren, was zu `DbUpdateConcurrencyExceptions` führt. Der Auftrag verbleibt oft in einem inkonsistenten Status ("Auftragsleiche").

#### 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 dezentrale 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.

**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
*ROI-Analyse: Wie viel kostet der Fehler aktuell? Wie schnell amortisiert sich die Entwicklung?*

---

## 4. Design & Architektur (Bewertung: Durchführung/Entscheidungen)
### 4.1 Technische Entscheidungen
*Begründung der Wahl von C# und spezifischen Entwurfsmustern (z.B. Singleton, Lock-Mechanismen).*

### 4.2 Systemarchitektur
*Darstellung der neuen Prozesssteuerung. Wie wird die Zentralisierung technisch umgesetzt?*

### 4.3 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
*Testplan, Unit-Tests, Integrationstests im WCS-Emulator.*

### 5.3 Abweichungen vom Projektplan
*Dokumentation und Begründung von Änderungen während der Durchführung.*

---

## 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.3 Fazit & Ausblick
*Persönliches Resümee und mögliche Erweiterungen.*

---

## Anhang (Zählt nicht zu den 15 Seiten)
- Kundendokumentation (Bedienungsanleitung/API-Doku)
- Quellcode (Relevante Ausschnitte)
- Abnahmeprotokoll
- Glossar & Quellenverzeichnis
