Files

Kai 24c0593f15 refactor: migrate project structure by reorganizing realization code snippets into documentation and analysis categories.

2026-05-27 10:48:45 +02:00

38 KiB

Raw Permalink Blame History

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:

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

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

38 KiB Raw Permalink Blame History Unescape Escape