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
+
+
+
+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
diff --git a/IHK_Projektdokumentation/Ausarbeitungsprozess/media/media/image2.emf b/IHK_Projektdokumentation/Ausarbeitungsprozess/media/media/image2.emf
new file mode 100644
index 00000000..114912a0
Binary files /dev/null and b/IHK_Projektdokumentation/Ausarbeitungsprozess/media/media/image2.emf differ
diff --git a/IHK_Projektdokumentation/Ausarbeitungsprozess/media/media/image3.png b/IHK_Projektdokumentation/Ausarbeitungsprozess/media/media/image3.png
new file mode 100644
index 00000000..b1b8d933
Binary files /dev/null and b/IHK_Projektdokumentation/Ausarbeitungsprozess/media/media/image3.png differ
diff --git a/IHK_Projektdokumentation/Dokumentation.docx b/IHK_Projektdokumentation/Dokumentation.docx
new file mode 100644
index 00000000..e99c3581
Binary files /dev/null and b/IHK_Projektdokumentation/Dokumentation.docx differ
diff --git a/IHK_Projektdokumentation/METADATENSAMMLUNG_CHATGPT-Konversation.html b/IHK_Projektdokumentation/METADATENSAMMLUNG_CHATGPT-Konversation.html
index bf616d41..01ac092b 100644
--- a/IHK_Projektdokumentation/METADATENSAMMLUNG_CHATGPT-Konversation.html
+++ b/IHK_Projektdokumentation/METADATENSAMMLUNG_CHATGPT-Konversation.html
@@ -1,71 +1,4 @@
Folgendes, ich muss meine IHK-Projektarbeit machen und dafür sollte ich eine Administrationsoberfläche schreiben mit Python Flask und mit SQLite Backend, weil das Ganze in einem Offline-Netzwerk stattfindet, also mit einem Switch, mit einem Router, aber selbes Subnetz alles und halt keine richtige Internetverbindung. Eine Internetverbindung habe ich nur zum Installieren, das Ganze auf einem Raspberry Pi, ich glaube Raspberry Pi Version 4 und in dem Offline-Netzwerk sind also, ich glaube, sechs Steckdosen P110 von TAPO und diese sollen also an Steckdosenplätze angeschlossen werden und damit sollen dann praktisch 3D-Drucker reserviert werden, indem man dann halt die Steckdosen entweder ein- oder aufschaltet und das muss jetzt implementiert werden. Das Ganze nennt sich MIP, also M-Y-P, Manager Printer und genau, am besten auch mit API und ich brauche dafür einen Prompt und es gibt bestimmte API-Richtlinien und so, die gebe ich dir im Nachhinein noch.ChatGPT:
Vorschlag für deinen KI-Prompt
-(Zum direkten Einfügen in ChatGPT / Cursor AI, damit dir ein lauffähiges Grundgerüst erzeugt wird)
-Nächste Schritte für dich
--
-
-
-
Virtuelle Umgebung auf dem Pi anlegen
-
- -
-
-sudo apt update && sudo apt install sqlite3 python3-venv
- -
-
-pip install pyTapo flask flask_sqlalchemy flask_httpauth apscheduler python-dotenv
- -
-
Den obigen Prompt an ChatGPT / Cursor AI senden
-
- -
-
Ergebnis testen, dann deine individuellen API-Richtlinien einarbeiten
-
- -
-
Abschließend IHK-Dokumentation schreiben (Lasten-, Pflichtenheft, Zeitplan, Sourcecode-Auszug)
-
-
Gib Bescheid, sobald du deine API-Richtlinien hast, dann passe ich den Prompt gezielt an 👌