IHK-Projekt/04_Dokumentation/DOKUMENTATIONS GERUEST.md

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