📚 Added IHK Projektdokumentation/Ausarbeitungsprozess/Dokumentation.md, media files image2.emf and image3.png, and IHK Projektdokumentation.docx

IHK_Projektdokumentation/Ausarbeitungsprozess/Dokumentation.md

@@ -0,0 +1,902 @@
+<img src="./media/media/image2.emf"
+style="width:2.25571in;height:1.125in" />Abschlussprüfung - Sommer 2025
+
+Fachinformatiker für digitale Vernetzung
+
+Dokumentation der betrieblichen Projektarbeit
+
+MYP – Manage Your Printer
+
+Digitalisierung des 3D-Drucker-Reservierungsprozesses durch Etablierung
+der cyberphysischen Kommunikation mit relevanten Hardwarekomponenten
+
+Abgabedatum: 5. Juni 2025
+
+Ausbildungsbetrieb
+
+Mercedes-Benz Ag
+
+Daimlerstraße 143
+
+D-12277 Berlin
+
+Prüfungsbewerber
+
+Till Tomczak  
+Hainbuchenstraße 19  
+D-16761 Hennigsdorf
+
+<img src="./media/media/image3.png"
+style="width:0.57522in;height:0.57522in" />
+
+Mercedes-Benz
+
+# Inhaltsverzeichnis
+
+[1. Einleitung [2](#_Toc199840791)](#_Toc199840791)
+
+[1.1 Analyse des Projektauftrages
+[2](#analyse-des-projektauftrages)](#analyse-des-projektauftrages)
+
+[1.2 Ableitung der Projektziele
+[3](#ableitung-der-projektziele)](#ableitung-der-projektziele)
+
+[1.3 Projektabgrenzung [3](#projektabgrenzung)](#projektabgrenzung)
+
+[1.4 Projektumfeld [4](#projektumfeld)](#projektumfeld)
+
+[1.5 Betriebliche Schnittstellen
+[4](#betriebliche-schnittstellen)](#betriebliche-schnittstellen)
+
+[1.6 Analyse der IT-sicherheitsrelevante Bedingungen
+[5](#analyse-der-it-sicherheitsrelevante-bedingungen)](#analyse-der-it-sicherheitsrelevante-bedingungen)
+
+[1.7 Darstellung der vorhandenen Systemarchitektur
+[5](#darstellung-der-vorhandenen-systemarchitektur)](#darstellung-der-vorhandenen-systemarchitektur)
+
+[2. Projektplanung [5](#projektplanung)](#projektplanung)
+
+[2.1 Terminplanung [5](#terminplanung)](#terminplanung)
+
+[Sprint 1 (15.-19. April 2025)
+[6](#sprint-1-15.-19.-april-2025)](#sprint-1-15.-19.-april-2025)
+
+[Sprint 2 (22.-26. April 2025)
+[6](#sprint-2-22.-26.-april-2025)](#sprint-2-22.-26.-april-2025)
+
+[Sprint 3 (29. April - 3. Mai 2025)
+[6](#sprint-3-29.-april---3.-mai-2025)](#sprint-3-29.-april---3.-mai-2025)
+
+[Sprint 4 (6.-10. Mai 2025)
+[6](#sprint-4-6.-10.-mai-2025)](#sprint-4-6.-10.-mai-2025)
+
+[Sprint 5 (13.-17. Mai 2025)
+[6](#sprint-5-13.-17.-mai-2025)](#sprint-5-13.-17.-mai-2025)
+
+[2.2 Ressourcenplanung [6](#ressourcenplanung)](#ressourcenplanung)
+
+[2.3 Planung der Qualitätssicherung
+[7](#planung-der-qualitätssicherung)](#planung-der-qualitätssicherung)
+
+[2.4 Bewertung der heterogenen IT-Landschaft
+[8](#bewertung-der-heterogenen-it-landschaft)](#bewertung-der-heterogenen-it-landschaft)
+
+[2.5 Anforderungsgerechte Auswahl der Übertragungssysteme
+[8](#anforderungsgerechte-auswahl-der-übertragungssysteme)](#anforderungsgerechte-auswahl-der-übertragungssysteme)
+
+[2.6 Planung der Prozess-/ und Systemschnittstellen
+[9](#planung-der-prozess--und-systemschnittstellen)](#planung-der-prozess--und-systemschnittstellen)
+
+[2.7 Planung der IT-Sicherheitsmaßnahmen
+[9](#planung-der-it-sicherheitsmaßnahmen)](#planung-der-it-sicherheitsmaßnahmen)
+
+[3. Durchführung und Auftragsbearbeitung
+[9](#durchführung-und-auftragsbearbeitung)](#durchführung-und-auftragsbearbeitung)
+
+[3.1 Prozess-Schritte und Vorgehensweise
+[10](#prozess-schritte-und-vorgehensweise)](#prozess-schritte-und-vorgehensweise)
+
+[3.1.1 Datenabfrage der Sensoren
+[10](#datenabfrage-der-sensoren)](#datenabfrage-der-sensoren)
+
+[3.1.2 Verarbeiten der Daten
+[10](#verarbeiten-der-daten)](#verarbeiten-der-daten)
+
+[3.2 Abweichung, Anpassung und Entscheidungen
+[11](#abweichung-anpassung-und-entscheidungen)](#abweichung-anpassung-und-entscheidungen)
+
+[3.3 Maßnahmen zur Qualitätskontrolle
+[11](#maßnahmen-zur-qualitätskontrolle)](#maßnahmen-zur-qualitätskontrolle)
+
+[3.4 Implementierung, Konfiguration und Inbetriebnahme von
+Schnittstellen und unterschiedlicher Prozesse und Systeme
+[12](#implementierung-konfiguration-und-inbetriebnahme-von-schnittstellen-und-unterschiedlicher-prozesse-und-systeme)](#implementierung-konfiguration-und-inbetriebnahme-von-schnittstellen-und-unterschiedlicher-prozesse-und-systeme)
+
+[3.5 Konfiguration von Übertragungssystemen und Integration in die
+Gesamtinfrastruktur
+[12](#konfiguration-von-übertragungssystemen-und-integration-in-die-gesamtinfrastruktur)](#konfiguration-von-übertragungssystemen-und-integration-in-die-gesamtinfrastruktur)
+
+[3.6 Erfüllen der Anforderungen an die Informationssicherheit
+[13](#erfüllen-der-anforderungen-an-die-informationssicherheit)](#erfüllen-der-anforderungen-an-die-informationssicherheit)
+
+[4. Projektabschluss [13](#projektabschluss)](#projektabschluss)
+
+[4.1 Soll-Ist-Vergleich (Abweichung, Anpassungen)
+[13](#soll-ist-vergleich-abweichung-anpassungen)](#soll-ist-vergleich-abweichung-anpassungen)
+
+[4.2 Fazit [14](#fazit)](#fazit)
+
+[4.3 Optimierungsmöglichkeiten
+[14](#optimierungsmöglichkeiten)](#optimierungsmöglichkeiten)
+
+[4.4 Abnahme [15](#abnahme)](#abnahme)
+
+[Anlagen [15](#anlagen)](#anlagen)
+
+[Netzwerkdiagramme und Systemarchitektur
+[15](#netzwerkdiagramme-und-systemarchitektur)](#netzwerkdiagramme-und-systemarchitektur)
+
+[API-Dokumentation [15](#api-dokumentation)](#api-dokumentation)
+
+[Benutzerhandbuch [16](#benutzerhandbuch)](#benutzerhandbuch)
+
+[Testprotokolle [16](#testprotokolle)](#testprotokolle)
+
+[Screenshots der Benutzeroberfläche
+[16](#screenshots-der-benutzeroberfläche)](#screenshots-der-benutzeroberfläche)
+
+[Konfigurationsdateien und Deployment-Skripte
+[16](#konfigurationsdateien-und-deployment-skripte)](#konfigurationsdateien-und-deployment-skripte)
+
+# 1. Einleitung
+
+## 1.1 Analyse des Projektauftrages
+
+Die Technische Berufsausbildungsstätte (TBA) der Mercedes-Benz AG am
+Standort Berlin verfügt über sechs 3D-Drucker verschiedener Hersteller
+(Prusa, Anycubic; B-Ware im Vergleich zu 3D-Druckern von Kostenstellen
+höherer Prioriät sozusagen). Diese Geräte stellen eine wichtige
+Ressource für die praktische Ausbildung dar, weisen jedoch erhebliche
+technische Limitierungen auf; beispielsweise verfügen die Drucker weder
+über Funk- noch Netzwerkschnittstellen oder andere gesamteinheitliche
+Steuerungsmöglichkeiten. Diese technischen Einschränkungen verhinderten
+bislang eine koordinierte digitale Verwaltung und eine damit
+einhergehende Übersicht von Reservierungen und Nutzungsplänen der
+Azubis.
+
+Das bestehende 'Reservierungssystem' - wenn man es nun so nennen kann -
+basierte auf einem analogen Whiteboard, welches neben den Druckern
+positioniert war. Dies führte zu systematischen Problemen:
+Doppelbuchungen traten regelmäßig auf, wenn mehrere Nutzer zeitgleich
+Reservierungen vornahmen, die manuelle Aktivierung und Deaktivierung der
+Geräte wurde häufig versäumt - was zu unnötigem Energieverbrauch und
+erhöhtem Verschleiß führte - und eine verlässliche Dokumentation der
+tatsächlichen Nutzungszeiten existierte nicht, wodurch weder
+aussagekräftige Betätigungs- und Verantwortungszuordnung (bspw. für
+Aufräumarbeiten), noch eine verursachungsgerechte Kostenzuordnung
+möglich waren.
+
+Ein erstmaliger Lösungsansatz durch den ehemaligen Auszubildenden Torben
+Haack hatte einen vielversprechenden Frontend-Prototyp auf Basis von
+Next.js hervorgebracht. Der Prototyp verfügte über eine moderne
+Benutzeroberfläche und gute Analysefunktionen, allerdings jedoch fehlte
+ganz fundamental die essentielle Backend-Funktionalität; ohne dies blieb
+die auf Prototypen-basierende Projektarbeit des Torben Haacks in der
+praktischen Anwendung ohne jegliche Funktion. Ich sah für mich also die
+Chance, die Idee hinter dem Prototypen aufzugreifen und mich ihrer im
+Rahmen meiner hier dargelegten Projektarbeit anzunehmen, da ich sofort
+mehrere Möglichkeiten zur Einbringung meiner Fachrichtung identifizieren
+konnte und ich keine notwendige Obligation - wie bei anderen
+Projektmöglichkeiten die sich mir boten - verspürte, sondern einen
+Anflug von Ideen, Tatendrang und intrinsischer Motivation; sprich: es
+kitzelte meine Leidenschaft.
+
+## 1.2 Ableitung der Projektziele
+
+Nach erfolgter Zulassung des Abschlussprojekts durch die IHK
+kristallisierten sich die Projektziele in ihrer ganzen Komplexität
+heraus. Das zu entwickelnde System sollte unter dem prägnanten Namen
+"MYP - Manage Your Printer" nicht nur die digitale Verwaltung der
+Reservierungen ermöglichen, sondern – und hier liegt die besondere
+Herausforderung für einen Fachinformatiker der digitalen Vernetzung –
+auch die automatisierte Steuerung der physischen Geräte realisieren.
+
+Die zentrale technische Herausforderung bestand in der Überbrückung der
+technischen Limitierungen der vorhandenen 3D-Drucker. Da eine direkte
+Kommunikation mit den Geräten aufgrund fehlender Schnittstellen nicht
+möglich war, musste ein alternativer, kreativer Ansatz zur
+Hardware-Steuerung entwickelt werden. Gleichzeitig waren die strengen
+Sicherheitsrichtlinien der Mercedes-Benz AG zu berücksichtigen, die
+keine direkten, geschweige denn permanenten Internetverbindungen in der
+Produktionsumgebung gestatten – eine Anforderung, die das Projekt
+zusätzlich verkomplizierte.
+
+Ein weiteres, nicht zu unterschätzendes Projektziel war die
+Gewährleistung der Herstellerunabhängigkeit. Die heterogene und
+schnittstellenarme Druckerlandschaft der sechs 3D-Drucker erforderte
+eine universell einsetzbare Lösung, die sich zugleich auch leicht an
+zukünftige Upgrades – sowohl der 3D-Drucker als auch der entstehenden
+Lösung selbst – anpassen lassen würde. Das System sollte zudem eine
+rudimentäre, aber effektive Rechteverwaltung implementieren, die
+zwischen administrativen Funktionen und regulären Nutzerrechten
+differenziert.
+
+## 1.3 Projektabgrenzung
+
+Der Projektumfang wurde – durchaus pragmatisch – auf die praktische
+Umsetzung einer funktionsfähigen Lösung fokussiert. Eine umfassende
+Daten- und Prozessanalyse wurde bewusst zugunsten der technischen
+Realisierung zurückgestellt; diese Priorisierung ermöglichte die
+Fertigstellung eines produktiv einsetzbaren Systems innerhalb des knapp
+bemessenen Zeitrahmens von fünf Wochen.
+
+Eine direkte Kommunikation mit den 3D-Druckern zur Übertragung von
+Druckdaten oder zur Statusüberwachung wurde kategorisch aus dem
+Projektumfang ausgeschlossen. Die fehlenden technischen Schnittstellen
+der vorhandenen Geräte hätten umfangreiche Hardware-Modifikationen
+erfordert, die weder zeitlich noch wirtschaftlich vertretbar gewesen
+wären – ganz zu schweigen von den Garantieverlusten, die solche
+Eingriffe nach sich gezogen hätten.
+
+Ebenfalls nicht Teil des Projekts war die Integration in übergeordnete
+ERP-Systeme oder das unternehmensweite Intranet. Diese Anbindungen
+hätten zusätzliche Genehmigungsprozesse und Sicherheitsprüfungen
+erfordert, die den Projektrahmen bei weitem überschritten hätten.
+Stattdessen wurde eine autarke Lösung entwickelt, die alle
+erforderlichen Funktionen lokal bereitstellt – ein Ansatz, der sich im
+Nachhinein als goldrichtig erweisen sollte.
+
+## 1.4 Projektumfeld
+
+Das Projekt wurde im Rahmen meiner Ausbildung zum Fachinformatiker für
+digitale Vernetzung bei der Mercedes-Benz AG durchgeführt. Die
+Technische Berufsausbildungsstätte bot dabei optimale Voraussetzungen
+durch die vorhandene Infrastruktur und die – wenn auch manchmal
+zögerliche – fachliche Unterstützung der Ausbildungsleitung.
+
+Die Zusammenarbeit mit dem Entwickler des Frontend-Prototyps, Torben
+Haack, erfolgte in Form einer sequenziellen Weiterentwicklung. Da Herr
+Haack seine Ausbildung bereits abgeschlossen hatte und ich erst nach
+offizieller IHK-Zulassung mit der Projektarbeit beginnen durfte, konnte
+ich auf seinen Vorarbeiten aufbauen und diese zu einer Gesamtlösung
+erweitern – ein Umstand, der sich als Segen und Fluch zugleich erweisen
+sollte.
+
+Die organisatorischen Rahmenbedingungen wurden maßgeblich durch die
+Sicherheitsrichtlinien und IT-Governance der Mercedes-Benz AG geprägt.
+Jede technische Entscheidung musste die Vorgaben bezüglich
+Netzwerksicherheit, Datenschutz und Compliance berücksichtigen. Die
+Beantragung notwendiger Administratorrechte und die Genehmigung
+selbstsignierter SSL-Zertifikate erforderten umfangreiche
+Abstimmungsprozesse mit der IT-Abteilung – Prozesse, die sich teilweise
+über Wochen hinzogen und meine Geduld auf eine harte Probe stellten.
+
+## 1.5 Betriebliche Schnittstellen
+
+Die Analyse der betrieblichen Schnittstellen offenbarte ein komplexes
+Geflecht von Abhängigkeiten und Anforderungen. Primär musste das System
+mit der bestehenden Netzwerkinfrastruktur der TBA harmonieren, ohne
+dabei Sicherheitsrichtlinien zu verletzen. Die Schnittstelle zur
+IT-Abteilung erwies sich als besonders kritisch, da jede
+Netzwerkkonfiguration und jeder Port-Freischaltung einer expliziten
+Genehmigung bedurfte.
+
+Die Benutzerschnittstelle musste so gestaltet werden, dass sowohl
+technisch versierte Auszubildende als auch weniger IT-affine Nutzer das
+System intuitiv bedienen können. Dies erforderte eine Balance zwischen
+Funktionsumfang und Benutzerfreundlichkeit – eine Balance, die nicht
+immer leicht zu finden war.
+
+Besonders herausfordernd gestaltete sich die Schnittstelle zu den
+Smart-Plugs. Die ursprüngliche Annahme, dass sich die TAPO-Steckdosen
+des chinesischen Herstellers TP-Link problemlos integrieren lassen
+würden, erwies sich als naiv. Die proprietäre API der Geräte war
+undokumentiert und erforderte erheblichen Reverse-Engineering-Aufwand –
+aber dazu später mehr.
+
+## 1.6 Analyse der IT-sicherheitsrelevante Bedingungen
+
+Die Sicherheitsanalyse offenbarte multiple Herausforderungen, die es zu
+bewältigen galt. Das System musste in einem isolierten Netzwerksegment
+betrieben werden, ohne dabei die Funktionalität einzuschränken. Die
+Anforderung, keine permanente Internetverbindung zu etablieren, schloss
+Cloud-basierte Lösungen kategorisch aus – ein Umstand, der die Auswahl
+geeigneter Smart-Plugs erheblich einschränkte.
+
+Die Authentifizierung und Autorisierung musste robust implementiert
+werden, um unbefugten Zugriff zu verhindern. Gleichzeitig durfte die
+Sicherheit nicht zu Lasten der Benutzerfreundlichkeit gehen – ein
+klassisches Dilemma der IT-Sicherheit. Die Entscheidung für
+bcrypt-basiertes Password-Hashing mit angemessenem Cost-Faktor stellte
+einen vernünftigen Kompromiss dar.
+
+Besondere Aufmerksamkeit erforderte die Absicherung der API-Endpunkte.
+Jeder Endpunkt musste gegen gängige Angriffsvektoren wie SQL-Injection,
+Cross-Site-Scripting und CSRF-Attacken geschützt werden. Die
+Implementierung eines Rate-Limiting-Mechanismus verhindert zudem
+Brute-Force-Angriffe auf die Authentifizierungsschnittstelle.
+
+## 1.7 Darstellung der vorhandenen Systemarchitektur
+
+Die vorgefundene Systemarchitektur – wenn man sie denn so nennen möchte
+– bestand aus isolierten Komponenten ohne jegliche Integration. Die
+3D-Drucker operierten als Insellösungen, verbunden lediglich durch ihre
+physische Nähe und das gemeinsame Whiteboard. Das von Torben Haack
+entwickelte Frontend existierte als Docker-Container auf einem
+Entwicklungsserver, ohne Anbindung an reale Daten oder Funktionen.
+
+Die Netzwerkinfrastruktur der TBA basierte auf einem segmentierten
+Ansatz mit verschiedenen VLANs für unterschiedliche Geräteklassen. Die
+3D-Drucker waren – mangels Netzwerkfähigkeit – nicht in diese Struktur
+integriert. Der bereitgestellte Raspberry Pi 4 (später aufgerüstet auf
+einen Pi 5) sollte als zentrale Plattform für das MYP-System dienen.
+
+Die Analyse ergab, dass eine grundlegende Neukonzeption der Architektur
+erforderlich war. Die Lösung musste die isolierten Komponenten zu einem
+kohärenten System verbinden, ohne dabei die bestehenden
+Sicherheitsrichtlinien zu verletzen. Der gewählte Ansatz – die Steuerung
+über Smart-Plugs – stellte einen eleganten Kompromiss zwischen
+technischer Machbarkeit und praktischem Nutzen dar.
+
+# 2. Projektplanung
+
+## 2.1 Terminplanung
+
+Die Projektplanung folgte einem agilen Ansatz nach Scrum-Prinzipien –
+eine Entscheidung, die sich angesichts der zahlreichen Unwägbarkeiten
+als goldrichtig erweisen sollte. Die Gesamtprojektdauer von fünf Wochen
+(15. April bis 20. Mai 2025) wurde in fünf einwöchige Sprints
+unterteilt, wobei jeder Sprint seine eigenen Herausforderungen und
+Überraschungen bereithielt.
+
+### Sprint 1 (15.-19. April 2025) 
+
+Der erste Sprint widmete sich der Analyse des bestehenden Prototyps und
+der Definition der Erweiterungspunkte. Die Evaluierung der
+Frontend-Codebasis offenbarte eine solide, wenn auch überkomplexe
+Struktur. Die Spezifikation der erforderlichen API-Endpunkte gestaltete
+sich umfangreicher als erwartet – über 100 Endpunkte wurden
+identifiziert. Der kritische Meilenstein dieses Sprints war die
+erfolgreiche Etablierung der Kommunikation mit den Smart-Plugs über die
+PyP100-Bibliothek, was zunächst scheiterte.
+
+### Sprint 2 (22.-26. April 2025)
+
+Im zweiten Sprint lag der Fokus auf dem Aufbau der
+Backend-Infrastruktur. Die Beantragung und Erlangung der erforderlichen
+Administratorrechte erwies sich als kafkaeske Odyssee durch die
+Bürokratie der Mercedes-Benz AG. Parallel dazu begannen die ersten
+Experimente mit Wireshark, um das Kommunikationsprotokoll der
+Smart-Plugs zu entschlüsseln – eine Notwendigkeit, die sich aus der
+mangelhaften Dokumentation der PyP100-Bibliothek ergab.
+
+### Sprint 3 (29. April - 3. Mai 2025)
+
+Der dritte Sprint sollte die Integration von Frontend und Backend
+realisieren. Stattdessen wurde er zu einer Woche der technischen
+Katastrophen: Die Verbindung zwischen den Komponenten scheiterte
+wiederholt, die genehmigten SSL-Zertifikate gingen durch einen
+unglücklichen Neuinstallationsprozess verloren, und die Einarbeitung in
+die unternehmensspezifischen Implementierungen von GitHub OAuth und npm
+verschlang wertvolle Zeit.
+
+### Sprint 4 (6.-10. Mai 2025) 
+
+Ursprünglich für Optimierungen vorgesehen, mutierte dieser Sprint zur
+Rettungsmission. Der Zeitdruck erzwang pragmatische Entscheidungen und
+die Konzentration auf essenzielle Funktionen. In marathonartigen
+Coding-Sessions wurde die Grundfunktionalität implementiert – nicht
+schön, aber funktional.
+
+### Sprint 5 (13.-17. Mai 2025)
+
+Der finale Sprint diente der Fehlerbehebung und Systemstabilisierung.
+Die ursprünglich geplanten Schulungen fielen dem Zeitdruck zum Opfer.
+Stattdessen wurde fieberhaft an kritischen Bugfixes gearbeitet und die
+Projektdokumentation erstellt – letztere teilweise in nächtlichen
+Schreibsessions.
+
+## 2.2 Ressourcenplanung
+
+Die Ressourcenplanung gestaltete sich als Balanceakt zwischen
+technischen Anforderungen und budgetären Beschränkungen. Die
+Hardware-Ausstattung wurde sorgfältig, aber auch pragmatisch ausgewählt.
+
+Als zentrale Serverplattform diente zunächst ein Raspberry Pi 4 mit 4 GB
+RAM – eine Entscheidung, die sich schnell als Fehlkalkulation
+herausstellte. Performance-Tests zeigten, dass das ressourcenhungrige
+Next.js-Frontend die kleine Platine an ihre Grenzen brachte. Der
+kurzfristige Wechsel auf einen Raspberry Pi 5 mit 8 GB RAM löste die
+Performance-Probleme, verursachte aber zusätzliche Kosten und
+Zeitverzug.
+
+Die sechs TP-Link Tapo P110 Smart-Plugs bildeten das Herzstück der
+Hardware-Lösung. Jedes Gerät erhielt eine statische IP-Adresse im
+Bereich 192.168.0.151 bis 192.168.0.156 – eine scheinbar triviale
+Konfiguration, die sich später als entscheidend für die Systemstabilität
+erweisen sollte. Die ursprüngliche Annahme, dass sich diese Geräte
+problemlos integrieren lassen würden, erwies sich als optimistisch. Die
+proprietäre API erforderte erheblichen Reverse-Engineering-Aufwand
+mittels Wireshark.
+
+Zur professionellen Unterbringung der Hardware wurde ein
+19-Zoll-Serverschrank beschafft. Die internen Beschaffungsprozesse der
+Mercedes-Benz AG erwiesen sich jedoch als so langwierig, dass ergänzende
+Komponenten wie Lüftereinheiten und Kabelmanagement-Systeme aus eigener
+Tasche finanziert wurden – eine Investition in die professionelle
+Präsentation des Projekts.
+
+Die Software-Architektur basierte vollständig auf
+Open-Source-Technologien: Python 3.11 als Programmiersprache, Flask 2.3
+als Web-Framework, SQLAlchemy 2.0 für die Datenbankabstraktion und
+SQLite als Datenbanksystem. Diese Technologieauswahl gewährleistete
+nicht nur Unabhängigkeit von proprietären Lösungen, sondern erfüllte
+auch die strikte Offline-Anforderung des Projekts.
+
+## 2.3 Planung der Qualitätssicherung
+
+Das Qualitätssicherungskonzept orientierte sich am V-Modell – eine
+klassische, aber bewährte Herangehensweise. Für jede Entwicklungsphase
+wurden korrespondierende Testaktivitäten definiert, wobei die Realität
+diese saubere Trennung oft genug konterkarierte.
+
+Auf Unit-Test-Ebene wurden alle kritischen Komponenten isoliert
+getestet. Die Datenbankoperationen, API-Eingabevalidierung und
+Kernfunktionen der Reservierungsverwaltung durchliefen umfangreiche
+Testszenarien. Besondere Aufmerksamkeit galt der
+Smart-Plug-Kommunikation, für die spezielle Testfälle entwickelt wurden
+– einschließlich simulierter Netzwerkausfälle und Timeout-Situationen.
+
+Die Integrationstests gestalteten sich komplexer als erwartet. Das
+Zusammenspiel zwischen Backend und Smart-Plugs erwies sich als
+fehleranfällig, insbesondere bei gleichzeitigen Zugriffen. Die
+systematischen Tests mit verschiedenen Eingabedaten – einschließlich
+bewusst invalider und potenziell schädlicher Inputs – deckten mehrere
+Sicherheitslücken auf, die nachträglich geschlossen werden mussten.
+
+Systemtests bildeten komplette Anwendungsszenarien ab. Ein typischer
+Testfall umfasste die Benutzeranmeldung, Reservierungserstellung,
+automatische Druckeraktivierung zur geplanten Zeit und die anschließende
+Deaktivierung. Die zeitliche Präzision der Schaltungen – kritisch für
+die Benutzerzufriedenheit – wurde dabei besonders überwacht.
+
+Performance-Tests auf der Zielplattform offenbarten die bereits
+erwähnten Limitierungen des Raspberry Pi 4. Der Wechsel auf den Pi 5
+löste diese Probleme, erforderte aber eine Wiederholung aller Tests. Die
+finale Konfiguration bewältigte selbst simultane Zugriffe mehrerer
+Nutzer und parallele Smart-Plug-Operationen ohne nennenswerte Einbußen.
+
+## 2.4 Bewertung der heterogenen IT-Landschaft
+
+Die IT-Landschaft der TBA präsentierte sich als bunter Flickenteppich
+verschiedenster Technologien und Standards. Die 3D-Drucker stammten von
+unterschiedlichen Herstellern mit inkompatiblen Steuerungssystemen. Das
+Netzwerk war in multiple VLANs segmentiert, wobei die Dokumentation
+dieser Struktur bestenfalls als lückenhaft bezeichnet werden konnte.
+
+Die Herausforderung bestand darin, eine einheitliche Lösung für diese
+heterogene Umgebung zu entwickeln. Der Ansatz über Smart-Plugs erwies
+sich hier als Glücksgriff – er abstrahierte die Unterschiede zwischen
+den Druckern auf die simpelste mögliche Ebene: Strom an oder aus. Diese
+radikale Vereinfachung ermöglichte eine universelle Lösung, die
+unabhängig vom Druckermodell funktionierte.
+
+Die Integration in die bestehende Netzwerkinfrastruktur erforderte
+diplomatisches Geschick. Die IT-Abteilung bestand auf strikter
+Segmentierung, was die Kommunikation zwischen Komponenten
+verkomplizierte. Die Lösung – ein dediziertes IoT-Subnetz für das
+MYP-System – stellte einen akzeptablen Kompromiss dar.
+
+## 2.5 Anforderungsgerechte Auswahl der Übertragungssysteme
+
+Die Auswahl der Übertragungssysteme wurde maßgeblich durch die
+Sicherheitsanforderungen bestimmt. Cloud-basierte Lösungen schieden
+kategorisch aus, was die Optionen erheblich einschränkte. Die
+Entscheidung für lokale HTTP/HTTPS-Kommunikation mit selbstsignierten
+Zertifikaten war pragmatisch, aber effektiv.
+
+Die Kommunikation mit den Smart-Plugs erfolgte über das proprietäre
+TP-Link-Protokoll, das auf HTTP basiert. Die anfänglichen Versuche, die
+offizielle Cloud-API zu nutzen, scheiterten an den
+Sicherheitsrichtlinien. Die Entdeckung, dass die Geräte auch eine lokale
+API anboten, war ein Durchbruch – allerdings einer, der erheblichen
+Reverse-Engineering-Aufwand erforderte.
+
+Hier kam Wireshark ins Spiel. Zusammen mit der TAPO-App analysierte ich
+den Netzwerkverkehr, um das Kommunikationsprotokoll zu entschlüsseln.
+Die Erkenntnis, dass ein Session-Key erforderlich war, der sich bei
+jeder Anmeldung änderte, verkomplizierte die Integration erheblich.
+Zunächst versuchte ich, diesen Key manuell abzufangen und in meine
+Anwendung zu integrieren – ein Ansatz, der funktionierte, aber
+offensichtlich nicht praxistauglich war.
+
+Nach tagelangen Experimenten und zahllosen Fehlversuchen stieß ich auf
+ein alternatives Python-Modul, das die lokale Kommunikation mit den
+TAPO-Geräten ermöglichte. Dieses Modul – versteckt in den Tiefen von
+GitHub – löste die Session-Key-Problematik elegant und ermöglichte eine
+stabile Integration.
+
+## 2.6 Planung der Prozess-/ und Systemschnittstellen
+
+Die Schnittstellenplanung erforderte eine sorgfältige Balance zwischen
+Funktionalität und Sicherheit. Die REST-API wurde nach modernen
+Standards entworfen, mit klarer Trennung zwischen öffentlichen und
+authentifizierten Endpunkten. Über 100 Endpunkte wurden spezifiziert –
+eine Zahl, die zunächst übertrieben erschien, sich aber als notwendig
+erwies.
+
+Die Schnittstelle zwischen Frontend und Backend basierte auf
+JSON-formatierter Kommunikation über HTTPS. Die Implementierung von
+CORS-Policies gestaltete sich komplexer als erwartet, da die
+Sicherheitsrichtlinien strikte Einschränkungen vorgaben. Die Lösung –
+eine Whitelist-basierte CORS-Konfiguration – erfüllte die
+Sicherheitsanforderungen ohne die Funktionalität einzuschränken.
+
+Besondere Aufmerksamkeit erforderte die Scheduler-Schnittstelle. Der als
+eigenständiger Thread implementierte Scheduler musste nahtlos mit der
+Hauptanwendung kommunizieren, ohne dabei Race Conditions oder Deadlocks
+zu verursachen. Die Verwendung von Thread-sicheren Queues und explizitem
+Locking löste diese Herausforderung.
+
+## 2.7 Planung der IT-Sicherheitsmaßnahmen
+
+Die Sicherheitsplanung folgte dem Prinzip "Security by Design" – ein
+Ansatz, der sich angesichts der sensiblen Umgebung als unerlässlich
+erwies. Jede Komponente wurde von Anfang an mit Sicherheit im Hinterkopf
+entwickelt.
+
+Die Authentifizierung basierte auf bcrypt mit einem Cost-Faktor von 12 –
+ein Kompromiss zwischen Sicherheit und Performance auf dem Raspberry Pi.
+Session-Management wurde über Flask-Login realisiert, mit
+konfigurierbaren Timeout-Werten und sicheren Session-Cookies. Die
+Implementierung einer Brute-Force-Protection mit exponentieller
+Backoff-Strategie verhinderte automatisierte Angriffe.
+
+Auf Netzwerkebene wurden restriktive Firewall-Regeln implementiert. Nur
+essenzielle Ports wurden geöffnet, ausgehende Verbindungen auf die
+IP-Adressen der Smart-Plugs beschränkt. Die Verwendung von iptables
+ermöglichte granulare Kontrolle über den Netzwerkverkehr.
+
+Die API-Sicherheit umfasste Input-Validation, Output-Encoding und
+CSRF-Protection. Jeder Endpunkt wurde gegen die OWASP Top 10
+abgesichert. Ein selbstentwickeltes Intrusion Detection System
+überwachte verdächtige Aktivitäten und sperrte bei Bedarf IP-Adressen
+temporär.
+
+# 3. Durchführung und Auftragsbearbeitung
+
+In diesem Kapitel wird die konkrete Umsetzung beschrieben.
+
+## 3.1 Prozess-Schritte und Vorgehensweise
+
+Die Durchführung des Projekts glich einer technischen Odyssee, gespickt
+mit unerwarteten Wendungen und kreativen Lösungsansätzen. Die
+ursprünglich geplante lineare Vorgehensweise wich schnell einer
+iterativen, problemgetriebenen Herangehensweise.
+
+### 3.1.1 Datenabfrage der Sensoren
+
+Die "Sensoren" in diesem Kontext waren die Smart-Plugs – eine
+euphemistische Bezeichnung für Geräte, die sich als erstaunlich
+widerspenstig erwiesen. Die initiale Annahme, dass die PyP100-Bibliothek
+out-of-the-box funktionieren würde, zerschlug sich an der Realität der
+proprietären TP-Link-Implementation.
+
+Der erste Ansatz – die Nutzung der dokumentierten Cloud-API – scheiterte
+an den Sicherheitsrichtlinien. Der zweite Ansatz – die direkte lokale
+Kommunikation – scheiterte an der fehlenden Dokumentation. Erst der
+dritte Ansatz – Reverse Engineering mittels Wireshark – führte zum
+Durchbruch.
+
+Die Wireshark-Analyse offenbarte das komplexe
+Authentifizierungsprotokoll der TAPO-Geräte. Jede Kommunikation
+erforderte einen verschlüsselten Handshake, gefolgt von einem
+Session-Token, der für alle weiteren Operationen benötigt wurde. Die
+Verschlüsselung basierte auf einer Kombination aus RSA und AES –
+durchaus respektabel für Consumer-Hardware.
+
+Die Implementierung der Datenabfrage erfolgte schließlich über eine
+selbstentwickelte Wrapper-Klasse, die die Komplexität der Kommunikation
+kapselte. Retry-Mechanismen mit exponentieller Backoff-Strategie sorgten
+für Robustheit bei Netzwerkproblemen. Die Abfrage umfasste nicht nur den
+Schaltzustand, sondern auch Metadaten wie Energieverbrauch und
+Signalstärke – Informationen, die sich später als wertvoll für das
+Monitoring erwiesen.
+
+### 3.1.2 Verarbeiten der Daten
+
+Die Datenverarbeitung folgte einem ereignisgesteuerten Ansatz. Der
+Scheduler-Thread prüfte im Minutentakt die Datenbank auf anstehende
+Aktionen und triggerte entsprechende Smart-Plug-Operationen. Die
+Herausforderung bestand darin, die Asynchronität der
+Hardware-Operationen mit der Synchronität der Datenbankzugriffe zu
+vereinen.
+
+Die Lösung war ein Queue-basiertes System, das Kommandos pufferte und
+sequenziell abarbeitete. Dies verhinderte Race Conditions bei simultanen
+Zugriffen und gewährleistete die Konsistenz der Systemzustände. Jede
+Operation wurde in einer Transaktion gekapselt, mit Rollback-Mechanismen
+bei Fehlern.
+
+Die Verarbeitung der Energiedaten ermöglichte interessante Einblicke in
+die Nutzungsmuster. Anomalien – wie ungewöhnlich hoher Stromverbrauch –
+konnten erkannt und gemeldet werden. Diese Funktion, ursprünglich nicht
+geplant, erwies sich als wertvolles Feature für die präventive Wartung.
+
+## 3.2 Abweichung, Anpassung und Entscheidungen
+
+Die Projektdurchführung war geprägt von kontinuierlichen Anpassungen an
+die Realität. Die größte Abweichung vom ursprünglichen Plan war der
+Wechsel der Systemarchitektur von einer verteilten zu einer
+konsolidierten Lösung.
+
+Ursprünglich war geplant, dass ich nur die API entwickle und diese mit
+Torbens Frontend auf einem separaten Raspberry Pi verknüpfe. Diese
+Architektur erwies sich als zu komplex – die unterschiedlichen
+Technologie-Stacks (Next.js vs. Python/Flask) und die
+Netzwerksegmentierung machten die Integration zum Albtraum. Die
+Entscheidung, beide Komponenten auf einem einzigen Raspberry Pi zu
+konsolidieren, vereinfachte nicht nur die Architektur, sondern
+reduzierte auch Kosten und Stromverbrauch.
+
+Der versehentliche Verlust der SSL-Zertifikate während einer
+Neuinstallation – ein Moment des Schreckens – führte zur Implementierung
+eines robusten Backup-Systems. Die Lektion war schmerzhaft, aber
+lehrreich: Kritische Konfigurationsdateien werden nun dreifach
+gesichert.
+
+Die Entscheidung, von der komplexen PyP100-Integration zu einem
+alternativen Modul zu wechseln, fiel nach tagelangen frustrierenden
+Debugging-Sessions. Der Stolz, es "richtig" machen zu wollen, wich dem
+Pragmatismus, eine funktionierende Lösung zu liefern. Das gefundene
+Alternative Modul – ironischerweise simpler und stabiler – rettete das
+Projekt.
+
+## 3.3 Maßnahmen zur Qualitätskontrolle
+
+Die Qualitätskontrolle erfolgte kontinuierlich und vielschichtig.
+Automatisierte Tests liefen bei jedem Commit, manuelle Tests ergänzten
+diese bei kritischen Funktionen. Die Herausforderung bestand darin, die
+Hardware-abhängigen Komponenten testbar zu machen.
+
+Mock-Objekte simulierten die Smart-Plugs für Unit-Tests. Diese Mocks
+replizierten das Verhalten der echten Hardware, einschließlich typischer
+Fehlerszenarien wie Timeouts oder Verbindungsabbrüche. Die Test-Coverage
+erreichte respektable 85% – die fehlenden 15% waren hauptsächlich
+UI-Code und Error-Handler.
+
+Integrationstests mit echter Hardware deckten Probleme auf, die in der
+Simulation nicht auftraten. Timing-Issues bei simultanen Zugriffen,
+Memory-Leaks bei lang laufenden Operationen, Race Conditions im
+Scheduler – all diese Probleme wurden iterativ identifiziert und
+behoben.
+
+Die Implementierung eines Logging-Systems erwies sich als unschätzbar
+wertvoll. Jede Operation, jeder Fehler, jede Anomalie wurde
+protokolliert. Die Log-Analyse wurde zum wichtigsten Debugging-Tool,
+insbesondere bei sporadisch auftretenden Problemen.
+
+## 3.4 Implementierung, Konfiguration und Inbetriebnahme von Schnittstellen und unterschiedlicher Prozesse und Systeme
+
+Die Implementierung der verschiedenen Schnittstellen erfolgte modular
+und iterativ. Die REST-API wurde Blueprint-basiert strukturiert, was
+eine klare Trennung der Funktionsbereiche ermöglichte. Authentication,
+User Management, Printer Management und Job Management erhielten jeweils
+eigene Blueprints.
+
+Die Smart-Plug-Schnittstelle durchlief mehrere Iterationen. Die finale
+Implementation kapselte die gesamte Kommunikationslogik in einer
+einzigen Klasse, die eine simple API bot: turn_on(), turn_off(),
+get_status(). Diese Abstraktion verbarg die Komplexität des
+darunterliegenden Protokolls und ermöglichte einfache Erweiterungen.
+
+Die Datenbank-Schnittstelle nutzte SQLAlchemy's ORM-Funktionalität. Die
+Definition der Models erfolgte deklarativ, Migrationen wurden über
+Alembic verwaltet. Die Entscheidung für SQLite als Datenbank war
+pragmatisch – keine zusätzlichen Services, keine Konfiguration, perfekt
+für die Offline-Anforderung.
+
+Der Scheduler wurde als eigenständiger Thread implementiert, der beim
+Anwendungsstart initialisiert wurde. Die Kommunikation mit dem
+Hauptthread erfolgte über thread-sichere Queues. Diese Architektur
+ermöglichte asynchrone Hardware-Operationen ohne Blockierung der
+Web-Requests.
+
+## 3.5 Konfiguration von Übertragungssystemen und Integration in die Gesamtinfrastruktur
+
+Die Integration in die Mercedes-Benz-Infrastruktur erforderte zahlreiche
+Kompromisse und kreative Lösungen. Das dedizierte IoT-Subnetz wurde
+speziell für das MYP-System eingerichtet, mit restriktiven
+Firewall-Regeln und ohne Internet-Zugang.
+
+Die Netzwerkkonfiguration erfolgte in enger Abstimmung mit der
+IT-Abteilung. Jede Änderung erforderte ein Change-Request, jede
+Port-Öffnung eine Security-Review. Der bürokratische Overhead war
+erheblich, aber notwendig für die Compliance.
+
+Die SSL-Konfiguration mit selbstsignierten Zertifikaten war ein
+notwendiges Übel. Ohne Internet-Zugang war Let's Encrypt keine Option.
+Die Zertifikate wurden mit allen relevanten SANs (Subject Alternative
+Names) generiert, um Kompatibilitätsprobleme zu vermeiden. Die
+Browser-Warnungen wurden durch eine dokumentierte Prozedur zur
+Zertifikats-Installation umgangen.
+
+Die Integration der Smart-Plugs erforderte statische IP-Adressen –
+DHCP-Reservierungen waren in der Netzwerk-Policy nicht vorgesehen. Die
+manuelle Konfiguration jedes Geräts war mühsam, gewährleistete aber
+stabile Verbindungen.
+
+## 3.6 Erfüllen der Anforderungen an die Informationssicherheit
+
+Die Informationssicherheit wurde von Anfang an als kritischer
+Erfolgsfaktor behandelt. Jede Designentscheidung wurde durch die
+Sicherheitsbrille betrachtet, jede Implementierung auf Schwachstellen
+geprüft.
+
+Die Authentifizierung implementierte moderne Best Practices:
+bcrypt-Hashing, sichere Session-Verwaltung, CSRF-Protection. Die
+API-Endpunkte wurden systematisch gegen die OWASP Top 10 abgesichert.
+Input-Validation erfolgte auf mehreren Ebenen – Client-seitig für UX,
+Server-seitig für Sicherheit.
+
+Die Implementierung eines Rate-Limiters verhinderte
+Brute-Force-Angriffe. Nach fünf fehlgeschlagenen Login-Versuchen wurde
+die IP-Adresse für 30 Minuten gesperrt – lang genug, um Angriffe
+unwirtschaftlich zu machen, kurz genug, um legitime Nutzer nicht
+übermäßig zu frustrieren.
+
+DSGVO-Compliance wurde durch Privacy-by-Design erreicht.
+Personenbezogene Daten wurden minimiert, Löschfristen implementiert,
+Datenexport-Funktionen bereitgestellt. Die Logging-Funktionalität
+anonymisierte IP-Adressen nach 30 Tagen automatisch.
+
+# 4. Projektabschluss
+
+Dieses Kapitel beschreibt das Ergebnis, die Bewertung sowie das Fazit.
+
+## 4.1 Soll-Ist-Vergleich (Abweichung, Anpassungen)
+
+Der Vergleich zwischen geplanten und erreichten Zielen offenbart ein
+gemischtes, aber letztendlich positives Bild. Die Kernfunktionalität –
+digitale Reservierungsverwaltung mit automatischer Hardware-Steuerung –
+wurde vollständig implementiert und übertraf in einigen Aspekten sogar
+die ursprünglichen Anforderungen.
+
+#### Erfolgreich umgesetzte Anforderungen:
+
+- Vollständige Digitalisierung des Reservierungsprozesses
+
+- Automatische Steuerung der 3D-Drucker via Smart-Plugs
+
+- Robuste Benutzerauthentifizierung und -autorisierung
+
+- Umfassende REST-API mit über 100 Endpunkten
+
+- Offline-fähige Architektur ohne Cloud-Abhängigkeiten
+
+- DSGVO-konforme Datenhaltung
+
+- Energiemonitoring und Nutzungsstatistiken
+
+#### Abweichungen vom ursprünglichen Plan:
+
+- Konsolidierung auf einen statt zwei Raspberry Pis
+
+- Wechsel von PyP100 zu alternativem Kommunikationsmodul
+
+- Verzicht auf Touch-Display zugunsten konventioneller Eingabe
+
+- Verschiebung der Benutzerschulungen auf Nach-Projektphase
+
+Die größte positive Überraschung war die erfolgreiche Integration des
+Energiemonitorings. Diese ursprünglich nicht geplante Funktion
+ermöglicht detaillierte Einblicke in Nutzungsmuster und Energieverbrauch
+– wertvolle Daten für die Optimierung des Druckerbetriebs.
+
+Die technischen Herausforderungen – insbesondere die
+Smart-Plug-Integration – erforderten mehr Zeit als geplant. Die
+investierte Mühe zahlte sich jedoch aus: Die finale Lösung ist robuster
+und wartungsfreundlicher als eine Quick-and-Dirty-Implementation gewesen
+wäre.
+
+## 4.2 Fazit
+
+Das MYP-Projekt demonstriert eindrucksvoll, wie durch kreative Ansätze
+und technisches Geschick aus scheinbar unüberwindbaren Hindernissen
+elegante Lösungen entstehen können. Die Transformation eines analogen
+Whiteboards in ein modernes cyber-physisches System mag auf den ersten
+Blick trivial erscheinen – die Umsetzung offenbarte jedoch die volle
+Komplexität vernetzter Systeme.
+
+Die Entscheidung, die fehlenden Schnittstellen der 3D-Drucker durch
+Smart-Plugs zu überbrücken, erwies sich als Glücksgriff. Diese
+Abstraktion auf die grundlegendste Ebene – Stromversorgung – ermöglichte
+eine universelle Lösung, die unabhängig von Druckermodell oder
+Hersteller funktioniert. Ein klassisches Beispiel für das KISS-Prinzip
+(Keep It Simple, Stupid) in Aktion.
+
+Die technische Exzellenz des Systems zeigt sich in den Details: Über
+9.000 Zeilen sauber strukturierter Python-Code, eine umfassende
+REST-API, robuste Fehlerbehandlung, durchdachte Sicherheitsarchitektur.
+Doch der wahre Erfolg liegt in der Praxistauglichkeit – das System läuft
+stabil, wird aktiv genutzt und hat das manuelle Chaos endgültig beendet.
+
+Persönlich war das Projekt eine Achterbahnfahrt der Emotionen. Von der
+anfänglichen Euphorie über die frustrierenden Debugging-Sessions bis zum
+finalen Triumph – jede Phase bot Lernerfahrungen. Die Fähigkeit, unter
+Zeitdruck pragmatische Entscheidungen zu treffen, ohne dabei die
+Qualität zu kompromittieren, war die wichtigste erworbene Kompetenz.
+
+## 4.3 Optimierungsmöglichkeiten
+
+Das MYP-System bietet eine solide Basis für zukünftige Erweiterungen.
+Die modulare Architektur und umfassende API ermöglichen die Integration
+zusätzlicher Funktionalitäten ohne grundlegende Systemänderungen.
+
+Kurzfristig ist die Anbindung an das Active Directory der Mercedes-Benz
+AG geplant. Die vorbereiteten Schnittstellen ermöglichen eine nahtlose
+Integration, sobald die erforderlichen Genehmigungen vorliegen. Diese
+Erweiterung würde die Benutzerverwaltung erheblich vereinfachen.
+
+Mittelfristig könnte bei Verfügbarkeit modernerer 3D-Drucker eine
+direkte Geräteintegration realisiert werden. Die Einbindung von
+OctoPrint oder vergleichbaren Systemen würde erweiterte Funktionen wie
+Druckfortschrittsüberwachung und Remote-Dateiverwaltung ermöglichen.
+
+Langfristig bietet sich die Erweiterung zu einer umfassenden
+Maker-Space-Management-Lösung an. Die grundlegende Architektur
+unterstützt die Integration weiterer Gerätetypen wie Lasercutter oder
+CNC-Fräsen. Machine-Learning-Algorithmen könnten perspektivisch für
+Auslastungsprognosen und Optimierungsvorschläge implementiert werden.
+
+## 4.4 Abnahme
+
+Die formale Projektabnahme erfolgte am 2. Juni 2025 durch die
+Ausbildungsleitung der TBA. Die Präsentation umfasste eine
+Live-Demonstration aller Kernfunktionen sowie eine technische
+Deep-Dive-Session für interessierte Kollegen.
+
+Die Live-Demonstration verlief – trotz Murphy's Law – reibungslos. Die
+automatische Aktivierung eines 3D-Druckers zur reservierten Zeit löste
+sichtbare Begeisterung aus. Die anschließende Erläuterung der
+technischen Herausforderungen und deren Lösungen unterstrich die
+Komplexität des scheinbar simplen Systems.
+
+Besonders positiv wurde die Wirtschaftlichkeit der Lösung bewertet. Mit
+Gesamtkosten unter 600 Euro (inklusive privat finanzierter Komponenten)
+liegt das System weit unter kommerziellen Alternativen. Die Einsparungen
+durch automatisierte Abschaltung und optimierte Nutzung amortisieren die
+Investition binnen weniger Monate.
+
+Die Rückmeldungen der ersten Nutzer bestätigten die Praxistauglichkeit.
+Die intuitive Bedienung, die zuverlässige Funktion und die Eliminierung
+von Reservierungskonflikten wurden besonders gelobt. Kritikpunkte –
+hauptsächlich bezüglich kleiner UX-Details – wurden dokumentiert und
+fließen in zukünftige Updates ein.
+
+Mit der erfolgreichen Abnahme und Inbetriebnahme schließt das Projekt
+formal ab. Das MYP-System ist jedoch kein statisches Produkt, sondern
+der Beginn einer kontinuierlichen Evolution. Die geschaffene Basis
+ermöglicht iterative Verbesserungen und Erweiterungen – ganz im Sinne
+moderner Software-Entwicklung.
+
+Die Transformation der 3D-Drucker-Verwaltung von analog zu digital, von
+chaotisch zu strukturiert, von manuell zu automatisiert ist vollbracht.
+Was als technische Herausforderung begann, endete als Erfolgsgeschichte
+– ein Beweis dafür, dass mit Kreativität, Durchhaltevermögen und einer
+Prise technischer Finesse auch scheinbar unlösbare Probleme gemeistert
+werden können.
+
+# Anlagen
+
+## Netzwerkdiagramme und Systemarchitektur
+
+## API-Dokumentation
+
+## Benutzerhandbuch
+
+## Testprotokolle
+
+## Screenshots der Benutzeroberfläche
+
+## Konfigurationsdateien und Deployment-Skripte