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). Diese Geräte stellen eine wichtige Ressource für die praktische Ausbildung dar, weisen jedoch erhebliche technische Limitierungen auf. Die Drucker verfügen weder über Netzwerkschnittstellen noch über andere Möglichkeiten zur zentralen Steuerung. Diese technischen Einschränkungen verhinderten bislang eine koordinierte digitale Verwaltung der Geräte. Das bestehende Reservierungssystem basierte auf einem analogen Whiteboard neben den Druckern. Dies führte zu systematischen Problemen: Doppelbuchungen traten regelmäßig auf, die manuelle Aktivierung und Deaktivierung der Geräte wurde häufig versäumt, was zu unnötigem Energieverbrauch führte. Eine verlässliche Dokumentation der Nutzungszeiten existierte nicht, wodurch weder eine Zuordnung von Verantwortlichkeiten noch eine verursachungsgerechte Kostenzuordnung möglich waren. Ein Prototyp des ehemaligen Auszubildenden Torben Haack auf Basis von Next.js zeigte bereits eine moderne Benutzeroberfläche, allerdings fehlte die Backend-Funktionalität vollständig. Dieser Prototyp diente als Ausgangspunkt für meine Projektarbeit, in der ich die fehlende Backend-Infrastruktur entwickelte und das System produktionsreif machte. ## 1.2 Ableitung der Projektziele Nach der Zulassung des Abschlussprojekts durch die IHK kristallisierten sich folgende Projektziele heraus. Das System "MYP - Manage Your Printer" sollte nicht nur die digitale Verwaltung der Reservierungen ermöglichen, sondern auch die automatisierte Steuerung der Geräte realisieren. Die zentrale technische Herausforderung bestand in der Überbrückung der fehlenden Schnittstellen der 3D-Drucker. Da eine direkte Kommunikation mit den Geräten nicht möglich war, entwickelte ich einen alternativen Ansatz über Smart-Plugs zur Hardware-Steuerung. Gleichzeitig mussten die strengen Sicherheitsrichtlinien der Mercedes-Benz AG berücksichtigt werden, die keine permanenten Internetverbindungen in der Produktionsumgebung gestatten. Ein weiteres Projektziel war die Gewährleistung der Herstellerunabhängigkeit. Die heterogene Druckerlandschaft erforderte eine universell einsetzbare Lösung, die sich leicht an zukünftige Hardware-Änderungen anpassen lässt. Das System implementiert zudem eine effektive Rechteverwaltung mit Differenzierung zwischen administrativen und regulären Nutzerrechten. ## 1.3 Projektabgrenzung Der Projektumfang wurde pragmatisch auf die Umsetzung einer funktionsfähigen Lösung fokussiert. Eine umfassende Daten- und Prozessanalyse wurde zugunsten der technischen Realisierung zurückgestellt, um ein produktiv einsetzbares System innerhalb des Zeitrahmens von fünf Wochen fertigzustellen. Eine direkte Kommunikation mit den 3D-Druckern zur Übertragung von Druckdaten oder zur Statusüberwachung wurde aus dem Projektumfang ausgeschlossen. Die fehlenden Schnittstellen der Geräte hätten umfangreiche Hardware-Modifikationen erfordert, die weder zeitlich noch wirtschaftlich vertretbar gewesen wären. Die Integration in übergeordnete ERP-Systeme oder das unternehmensweite Intranet war ebenfalls nicht Teil des Projekts. Diese Anbindungen hätten zusätzliche Genehmigungsprozesse erfordert, die den Projektrahmen überschritten hätten. Stattdessen wurde eine autarke Lösung entwickelt, die alle erforderlichen Funktionen lokal bereitstellt. ## 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 die vorhandene Infrastruktur und fachliche Unterstützung durch die Ausbildungsleitung. Die Zusammenarbeit mit Torben Haack erfolgte in Form einer sequenziellen Weiterentwicklung. Da Herr Haack seine Ausbildung bereits abgeschlossen hatte und ich erst nach IHK-Zulassung mit der Projektarbeit beginnen durfte, konnte ich auf seinen Frontend-Prototyp aufbauen und diesen zu einer Gesamtlösung erweitern. Die organisatorischen Rahmenbedingungen wurden 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. ## 1.5 Betriebliche Schnittstellen Die Analyse der betrieblichen Schnittstellen offenbarte ein komplexes Geflecht von Abhängigkeiten. Das System musste mit der bestehenden Netzwerkinfrastruktur der TBA harmonieren, ohne Sicherheitsrichtlinien zu verletzen. Die Schnittstelle zur IT-Abteilung erwies sich als kritisch, da jede Netzwerkkonfiguration und Port-Freischaltung einer expliziten Genehmigung bedurfte. Die Benutzerschnittstelle wurde so gestaltet, 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. Die Schnittstelle zu den Smart-Plugs stellte eine besondere Herausforderung dar. Die TAPO P110-Steckdosen von TP-Link verfügten über eine proprietäre, undokumentierte API, die erheblichen Reverse-Engineering-Aufwand erforderte. ## 1.6 Analyse der IT-sicherheitsrelevante Bedingungen Die Sicherheitsanalyse offenbarte multiple Herausforderungen. Das System musste in einem isolierten Netzwerksegment betrieben werden, ohne die Funktionalität einzuschränken. Die Anforderung, keine permanente Internetverbindung zu etablieren, schloss Cloud-basierte Lösungen aus und schränkte die Auswahl geeigneter Smart-Plugs erheblich ein. Die Authentifizierung und Autorisierung wurde robust implementiert, ohne die Benutzerfreundlichkeit zu beeinträchtigen. Die Entscheidung für bcrypt-basiertes Password-Hashing mit einem Cost-Faktor von 12 stellte einen vernünftigen Kompromiss zwischen Sicherheit und Performance dar. Besondere Aufmerksamkeit erforderte die Absicherung der API-Endpunkte. Jeder Endpunkt wurde gegen gängige Angriffsvektoren wie SQL-Injection, Cross-Site-Scripting und CSRF-Attacken geschützt. Die Implementierung eines Rate-Limiting-Mechanismus verhindert Brute-Force-Angriffe auf die Authentifizierungsschnittstelle. ## 1.7 Darstellung der vorhandenen Systemarchitektur Die vorgefundene Systemarchitektur bestand aus isolierten Komponenten ohne Integration. Die 3D-Drucker operierten als Insellösungen, verbunden nur durch ihre physische Nähe und das gemeinsame Whiteboard. Der Frontend-Prototyp von Torben Haack existierte als Docker-Container auf einem Entwicklungsserver, ohne Anbindung an reale 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. Ein Raspberry Pi 5 mit 8 GB RAM und 128 GB Speicher 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 die bestehenden Sicherheitsrichtlinien zu verletzen. Der gewählte Ansatz ü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. Die Gesamtprojektdauer von fünf Wochen (15. April bis 20. Mai 2025) wurde in fünf einwöchige Sprints unterteilt, wobei jeder Sprint spezifische Ziele verfolgte. ### 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 Struktur. Die Spezifikation der erforderlichen API-Endpunkte gestaltete sich umfangreicher als erwartet – über 100 Endpunkte wurden identifiziert. Der kritische Meilenstein war die Etablierung der Kommunikation mit den Smart-Plugs, was zunächst mit der PyP100-Bibliothek scheiterte. ### Sprint 2 (22.-26. April 2025) Im zweiten Sprint lag der Fokus auf dem Aufbau der Backend-Infrastruktur. Die Beantragung der erforderlichen Administratorrechte erwies sich als zeitaufwändig. Parallel begannen die ersten Experimente mit Wireshark, um das Kommunikationsprotokoll der Smart-Plugs zu entschlüsseln, da die PyP100-Bibliothek nicht funktionierte. ### Sprint 3 (29. April - 3. Mai 2025) Der dritte Sprint sollte die Integration von Frontend und Backend realisieren. Die Verbindung zwischen den Komponenten scheiterte wiederholt, die genehmigten SSL-Zertifikate gingen durch einen Neuinstallationsprozess verloren, und die Einarbeitung in die unternehmensspezifischen Implementierungen von GitHub OAuth und npm erforderte zusätzliche Zeit. ### Sprint 4 (6.-10. Mai 2025) Ursprünglich für Optimierungen vorgesehen, wurde dieser Sprint zur Entwicklung einer Full-Stack-Notlösung umfunktioniert. Der Zeitdruck erzwang pragmatische Entscheidungen. In intensiven Coding-Sessions wurde die Grundfunktionalität implementiert. ### Sprint 5 (13.-17. Mai 2025) Der finale Sprint diente der Fehlerbehebung und Systemstabilisierung. Die geplanten Schulungen wurden auf die Nach-Projektphase verschoben. Stattdessen wurde an kritischen Bugfixes gearbeitet und die Projektdokumentation erstellt. ## 2.2 Ressourcenplanung Die Ressourcenplanung gestaltete sich als Balanceakt zwischen technischen Anforderungen und budgetären Beschränkungen. Die Hardware-Ausstattung wurde sorgfältig ausgewählt. Als zentrale Serverplattform diente ein Raspberry Pi 5 mit 8 GB RAM und 128 GB Speicher. Der ursprünglich geplante Raspberry Pi 4 erwies sich als zu leistungsschwach für das ressourcenintensive Next.js-Frontend. 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.100 bis 192.168.0.106. Die proprietäre API erforderte erheblichen Reverse-Engineering-Aufwand mittels Wireshark. Zur professionellen Unterbringung der Hardware wurde ein 19-Zoll-Serverschrank beschafft. Ergänzende Komponenten wie Lüftereinheiten und Kabelmanagement-Systeme wurden aus privaten Mitteln finanziert, um eine professionelle Präsentation zu gewährleisten. Die Software-Architektur basierte auf Open-Source-Technologien: Python 3.11, Flask 2.3, SQLAlchemy 2.0 und SQLite. Diese Technologieauswahl gewährleistete Unabhängigkeit von proprietären Lösungen und erfüllte die Offline-Anforderung des Projekts. ## 2.3 Planung der Qualitätssicherung Das Qualitätssicherungskonzept orientierte sich am V-Modell. Für jede Entwicklungsphase wurden korrespondierende Testaktivitäten definiert. Auf Unit-Test-Ebene wurden alle kritischen Komponenten isoliert getestet. Datenbankoperationen, API-Eingabevalidierung und Kernfunktionen der Reservierungsverwaltung durchliefen umfangreiche Testszenarien. Besondere Aufmerksamkeit galt der Smart-Plug-Kommunikation mit simulierten Netzwerkausfällen und Timeout-Situationen. Die Integrationstests gestalteten sich komplex. Das Zusammenspiel zwischen Backend und Smart-Plugs erwies sich als fehleranfällig bei gleichzeitigen Zugriffen. Systematische Tests mit verschiedenen Eingabedaten deckten mehrere Sicherheitslücken auf, die nachträglich geschlossen wurden. Systemtests bildeten komplette Anwendungsszenarien ab. Ein typischer Testfall umfasste Benutzeranmeldung, Reservierungserstellung, automatische Druckeraktivierung und anschließende Deaktivierung. Die zeitliche Präzision der Schaltungen wurde dabei besonders überwacht. Performance-Tests offenbarten die Limitierungen des ursprünglich geplanten Raspberry Pi 4. Der Wechsel auf den Pi 5 löste diese Probleme. Die finale Konfiguration bewältigte simultane Zugriffe mehrerer Nutzer und parallele Smart-Plug-Operationen ohne Einbußen. ## 2.4 Bewertung der heterogenen IT-Landschaft Die IT-Landschaft der TBA präsentierte sich als heterogene Umgebung mit verschiedenen Technologien. Die 3D-Drucker stammten von unterschiedlichen Herstellern mit inkompatiblen Steuerungssystemen. Das Netzwerk war in multiple VLANs segmentiert. Die Herausforderung bestand darin, eine einheitliche Lösung für diese heterogene Umgebung zu entwickeln. Der Ansatz über Smart-Plugs abstrahierte die Unterschiede zwischen den Druckern auf die einfachste Ebene: Stromversorgung. Diese Vereinfachung ermöglichte eine universelle Lösung, unabhängig vom Druckermodell. Die Integration in die bestehende Netzwerkinfrastruktur erforderte diplomatisches Geschick. Die IT-Abteilung bestand auf strikter Segmentierung. 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 durch die Sicherheitsanforderungen bestimmt. Cloud-basierte Lösungen schieden aus. Die Entscheidung für lokale HTTP/HTTPS-Kommunikation mit selbstsignierten Zertifikaten war pragmatisch und effektiv. Die Kommunikation mit den Smart-Plugs erfolgte über das proprietäre TP-Link-Protokoll. Die anfänglichen Versuche mit der offiziellen Cloud-API scheiterten an den Sicherheitsrichtlinien. Die lokale API der Geräte erforderte erheblichen Reverse-Engineering-Aufwand. Mit Wireshark analysierte ich den Netzwerkverkehr der TAPO-App. Die Erkenntnis, dass ein Session-Key erforderlich war, der sich bei jeder Anmeldung änderte, verkomplizierte die Integration. Nach tagelangen Experimenten fand ich ein alternatives Python-Modul auf GitHub, das die lokale Kommunikation ermöglichte und die Session-Key-Problematik elegant löste. ## 2.6 Planung der Prozess-/ und Systemschnittstellen Die Schnittstellenplanung erforderte eine 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 und implementiert. Die Schnittstelle zwischen Frontend und Backend basierte auf JSON-formatierter Kommunikation über HTTPS. Die Implementierung von CORS-Policies gestaltete sich komplex aufgrund der strikten Sicherheitsrichtlinien. Eine Whitelist-basierte CORS-Konfiguration erfüllte die Anforderungen ohne Funktionseinschränkungen. Der als eigenständiger Thread implementierte Scheduler musste nahtlos mit der Hauptanwendung kommunizieren. Die Verwendung von thread-sicheren Queues und explizitem Locking verhinderte Race Conditions und Deadlocks. ## 2.7 Planung der IT-Sicherheitsmaßnahmen Die Sicherheitsplanung folgte dem Prinzip "Security by Design". Jede Komponente wurde von Anfang an mit Sicherheit im Fokus entwickelt. Die Authentifizierung basierte auf bcrypt mit einem Cost-Faktor von 12. Session-Management wurde über Flask-Login realisiert, mit konfigurierbaren Timeout-Werten und sicheren Session-Cookies. Eine 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. # 3. Durchführung und Auftragsbearbeitung ## 3.1 Prozess-Schritte und Vorgehensweise Die Durchführung des Projekts erforderte kontinuierliche Anpassungen an technische Herausforderungen. Die ursprünglich geplante lineare Vorgehensweise wich einer iterativen, problemgetriebenen Herangehensweise. ### 3.1.1 Datenabfrage der Sensoren Die Smart-Plugs fungierten als "Sensoren" im System. Die initiale Annahme, dass die PyP100-Bibliothek funktionieren würde, erwies sich als falsch. Der erste Ansatz mit der dokumentierten Cloud-API scheiterte an den Sicherheitsrichtlinien. Der zweite Ansatz der direkten lokalen Kommunikation scheiterte an fehlender Dokumentation. Erst das Reverse Engineering mittels Wireshark führte zum Erfolg. Die Wireshark-Analyse offenbarte das komplexe Authentifizierungsprotokoll der TAPO-Geräte. Jede Kommunikation erforderte einen verschlüsselten Handshake mit Session-Token. Die Verschlüsselung basierte auf RSA und AES. Die finale Implementierung erfolgte über eine selbstentwickelte Wrapper-Klasse, die die Kommunikationskomplexität kapselte. Retry-Mechanismen mit exponentieller Backoff-Strategie sorgten für Robustheit. Die Abfrage umfasste Schaltzustand, Energieverbrauch und Signalstärke. ### 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 Smart-Plug-Operationen. Die Lösung war ein Queue-basiertes System, das Kommandos pufferte und sequenziell abarbeitete. Dies verhinderte Race Conditions und gewährleistete Systemkonsistenz. Jede Operation wurde in einer Transaktion gekapselt mit Rollback-Mechanismen. Die Verarbeitung der Energiedaten ermöglichte Einblicke in Nutzungsmuster. Anomalien wie ungewöhnlich hoher Stromverbrauch konnten erkannt werden. Diese ursprünglich nicht geplante Funktion erwies sich als wertvoll für die präventive Wartung. ## 3.2 Abweichung, Anpassung und Entscheidungen Die Projektdurchführung war geprägt von kontinuierlichen Anpassungen. Die größte Abweichung war der Wechsel von einer verteilten zu einer konsolidierten Systemarchitektur. Ursprünglich sollte nur die API entwickelt und mit dem Frontend auf separaten Raspberry Pis verknüpft werden. Die unterschiedlichen Technologie-Stacks und die Netzwerksegmentierung machten die Integration jedoch zu komplex. Die Konsolidierung auf einem einzigen Raspberry Pi vereinfachte die Architektur erheblich. Der versehentliche Verlust der SSL-Zertifikate während einer Neuinstallation führte zur Implementierung eines robusten Backup-Systems. Kritische Konfigurationsdateien werden nun dreifach gesichert. Die Entscheidung, von PyP100 zu einem alternativen Modul zu wechseln, fiel nach tagelangen fruchtlosen Debugging-Sessions. Das gefundene alternative Modul war simpler und stabiler. ## 3.3 Maßnahmen zur Qualitätskontrolle Die Qualitätskontrolle erfolgte kontinuierlich. Automatisierte Tests liefen bei jedem Commit, manuelle Tests ergänzten diese bei kritischen Funktionen. Mock-Objekte simulierten die Smart-Plugs für Unit-Tests. Diese Mocks replizierten das Verhalten der echten Hardware inklusive typischer Fehlerszenarien. Die Test-Coverage erreichte 85%. Integrationstests mit echter Hardware deckten Probleme auf, die in der Simulation nicht auftraten: Timing-Issues, Memory-Leaks, Race Conditions. Alle Probleme wurden iterativ behoben. Die Implementierung eines umfassenden Logging-Systems erwies sich als unschätzbar wertvoll. Jede Operation wurde protokolliert. Die Log-Analyse wurde zum wichtigsten Debugging-Tool. ## 3.4 Implementierung, Konfiguration und Inbetriebnahme von Schnittstellen und unterschiedlicher Prozesse und Systeme Die Implementierung der Schnittstellen erfolgte modular. Die REST-API wurde Blueprint-basiert strukturiert mit klarer Trennung der Funktionsbereiche: Authentication, User Management, Printer Management und Job Management. Die Smart-Plug-Schnittstelle durchlief mehrere Iterationen. Die finale Implementation kapselte die Kommunikationslogik in einer einzigen Klasse mit simpler API: turn_on(), turn_off(), get_status(). Die Datenbank-Schnittstelle nutzte SQLAlchemy's ORM-Funktionalität. Models wurden deklarativ definiert, Migrationen über Alembic verwaltet. SQLite als Datenbank war perfekt für die Offline-Anforderung. Der Scheduler wurde als eigenständiger Thread implementiert, der beim Anwendungsstart initialisiert wurde. Thread-sichere Queues ermöglichten 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. Das dedizierte IoT-Subnetz wurde speziell für das MYP-System eingerichtet mit restriktiven Firewall-Regeln. Die Netzwerkkonfiguration erfolgte in enger Abstimmung mit der IT-Abteilung. Jede Änderung erforderte ein Change-Request. Der bürokratische Overhead war erheblich aber notwendig. Die SSL-Konfiguration mit selbstsignierten Zertifikaten war notwendig mangels Internet-Zugang. Die Zertifikate wurden mit allen relevanten SANs generiert. Browser-Warnungen wurden durch eine dokumentierte Installationsprozedur umgangen. Die Smart-Plugs erhielten statische IP-Adressen, da DHCP-Reservierungen nicht vorgesehen waren. Die manuelle Konfiguration war aufwändig, gewährleistete aber stabile Verbindungen. ## 3.6 Erfüllen der Anforderungen an die Informationssicherheit Die Informationssicherheit wurde als kritischer Erfolgsfaktor behandelt. Jede Designentscheidung wurde unter Sicherheitsaspekten betrachtet. 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. Ein Rate-Limiter verhinderte Brute-Force-Angriffe. Nach fünf fehlgeschlagenen Login-Versuchen wurde die IP-Adresse für 30 Minuten gesperrt. 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 ## 4.1 Soll-Ist-Vergleich (Abweichung, Anpassungen) Der Vergleich zwischen geplanten und erreichten Zielen zeigt ein positives Gesamtbild. Die Kernfunktionalität wurde vollständig implementiert und übertraf in einigen Aspekten 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 - Kein Touch-Display implementiert - Verschiebung der Benutzerschulungen 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. Die technischen Herausforderungen, insbesondere die Smart-Plug-Integration, erforderten mehr Zeit als geplant. Die investierte Mühe zahlte sich jedoch in einer robusten und wartungsfreundlichen Lösung aus. ## 4.2 Fazit Das MYP-Projekt demonstriert, wie durch kreative Ansätze und technisches Geschick aus scheinbar unüberwindbaren Hindernissen elegante Lösungen entstehen. Die Transformation eines analogen Whiteboards in ein modernes cyber-physisches System mag 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 optimal. Diese Abstraktion auf die grundlegendste Ebene – Stromversorgung – ermöglichte eine universelle, herstellerunabhängige Lösung. Die technische Exzellenz zeigt sich in den Details: Über 9.000 Zeilen strukturierter Python-Code, eine umfassende REST-API, robuste Fehlerbehandlung und durchdachte Sicherheitsarchitektur. Der wahre Erfolg liegt jedoch in der Praxistauglichkeit – das System läuft stabil und hat das manuelle Chaos beendet. Persönlich war das Projekt eine intensive Lernerfahrung. Von der anfänglichen Euphorie über frustrierende Debugging-Sessions bis zum finalen Erfolg – jede Phase bot wertvolle Erkenntnisse. Die Fähigkeit, unter Zeitdruck pragmatische Entscheidungen zu treffen ohne 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. Mittelfristig könnte bei Verfügbarkeit modernerer 3D-Drucker eine direkte Geräteintegration realisiert werden. Die Einbindung von OctoPrint würde erweiterte Funktionen wie Druckfortschrittsüberwachung ermöglichen. Langfristig bietet sich die Erweiterung zu einer umfassenden Maker-Space-Management-Lösung an. Die Architektur unterstützt die Integration weiterer Gerätetypen. Machine-Learning-Algorithmen könnten für Auslastungsprognosen 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. Bei der Live-Demonstration kam es zunächst zu einem Missverständnis bezüglich der Systemkonfiguration, da das System noch nicht vollständig produktiv aufgebaut war – letzte Hardware-Komponenten waren noch in der Lieferung. Dank der robusten Systemarchitektur konnte ich jedoch aus dem Stegreif improvisieren und das System sofort demonstrieren. Die automatische Aktivierung eines 3D-Druckers zur reservierten Zeit funktionierte einwandfrei und löste sichtbare Begeisterung aus. Besonders positiv wurde die Wirtschaftlichkeit bewertet. Mit Gesamtkosten unter 600 Euro liegt das System weit unter kommerziellen Alternativen. Die Einsparungen durch automatisierte Abschaltung amortisieren die Investition binnen weniger Monate. Die Rückmeldungen der ersten Nutzer bestätigten die Praxistauglichkeit. Die intuitive Bedienung, zuverlässige Funktion und Eliminierung von Reservierungskonflikten wurden besonders gelobt. Kleinere UX-Details wurden dokumentiert für zukünftige Updates. 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. 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 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