core/Projektarbeit-MYP
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

🎉 Updated IHK Project Documentation: Added final project doc and image 📚, incorporated Word document as supplementary material 💄.

Browse Source
This commit is contained in:
Till Tomczak 2025-06-05 13:22:41 +02:00
parent 0a1b24c4ef
commit 0fe988ac4f
3 changed files with 112 additions and 65 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

163
IHK_Projektdokumentation/MYP_Projektdokumentation_Final.md
View File

@ -1,4 +1,5 @@
# MYP – Manage Your Printer
## Vernetzte 3D-Druck-Reservierungsplattform mit IoT-Anbindung und zentraler Verwaltungsoberfläche
**Dokumentation der betrieblichen Projektarbeit**
@ -59,63 +60,62 @@
### 1.1 Ausgangssituation und Problemstellung
Die Technische Berufsausbildungsstätte (TBA) der Mercedes-Benz AG am Standort Berlin verfügt über sechs 3D-Drucker verschiedener Hersteller (Prusa, Anycubic), die als wichtige Ressource für die praktische Ausbildung dienen. Diese Geräte weisen jedoch erhebliche technische Limitierungen auf, da sie weder über Netzwerkschnittstellen noch über einheitliche Steuerungsmöglichkeiten verfügen.
Die Technische Berufsausbildungsstätte (TBA) der Mercedes-Benz AG am Standort Berlin verfügt über sechs 3D-Drucker verschiedener Hersteller (Prusa, Anycubic), die als wichtige Ressource für die praktische Berufsausbuldung dienen. Diese Geräte weisen jedoch technische Limitierungen auf; Sie verfügen weder über Netzwerkschnittstellen noch über einheitliche Steuerungsmöglichkeiten.
Das bestehende Reservierungssystem basierte auf einem analogen Whiteboard, was zu systematischen Problemen führte. 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. Eine verlässliche Dokumentation der tatsächlichen Nutzungszeiten existierte nicht, wodurch weder aussagekräftige Betätigungs- und Verantwortungszuordnung, noch eine verursachungsgerechte Kostenzuordnung möglich waren.
Das - wollte man es als ein solches bezeichnen - bestehende Reservierungssystem basierte auf einem analogen Whiteboard, was zu systematischen Problemen führte. Doppelbuchungen traten auf, wenn mehrere Nutzer zeitgleich etwas drucken wollten. Die manuelle Aktivierung und Deaktivierung der Geräte wurde häufig versäumt, was zu unnötigem Energieverbrauch und erhöhtem Verschleiß führte. Eine verlässliche Dokumentation der tatsächlichen Nutzungszeiten existierte nicht, wodurch weder aussagekräftige Betätigungs- und Verantwortungszuordnung, noch eine verursachungsgerechte Kostenzuordnung möglich waren.
Ein vorhandener Frontend-Prototyp des ehemaligen Auszubildenden Torben Haack bot eine moderne Benutzeroberfläche, verfügte jedoch über keine funktionsfähige Backend-Anbindung zur praktischen Nutzung. Diese Ausgangslage bot mir die Gelegenheit, im Rahmen meiner Projektarbeit eine vollständige Lösung zu entwickeln.
Ein vorhandener Frontend-Prototyp des ehemaligen Auszubildenden aus der Fachrichtung der Daten- und Prozessanalyse Torben Haack bot eine moderne Benutzeroberfläche, verfügte jedoch nicht über eine funktionsfähige Backend-Anbindung zur praktischen Nutzung. Diese Ausgangslage bot mir eine fantastische Gelegenheit, im Rahmen meiner Projektarbeit eine weiterführende und meiner Fachrichtung entsprechende Lösung zu entwickeln. Das Projekt weckte – im Gegensatz zu anderen verfügbaren Projektoptionen, die eher einen pflichtgemäßen Charakter hätten, meine intrinsische Motivation deutlich.
### 1.2 Projektziele
Das Projekt "MYP – Manage Your Printer" zielt auf die vollständige Digitalisierung des 3D-Drucker-Reservierungsprozesses durch die Etablierung cyberphysischer Kommunikation mit den relevanten Hardwarekomponenten ab.
Die primären Ziele umfassen die Entwicklung einer webbasierten Reservierungsplattform, die Integration automatischer Hardware-Steuerung via IoT-Komponenten, die Implementierung einer zentralen Verwaltungsoberfläche sowie die Etablierung robuster Authentifizierung und Rechteverwaltung. Als sekundäre Ziele wurden die Optimierung der Energieeffizienz durch automatisierte Steuerung, die Bereitstellung von Nutzungsstatistiken und Monitoring, die Gewährleistung einer herstellerunabhängigen Lösung sowie die Einhaltung unternehmensinterner Sicherheitsrichtlinien definiert.
Die primären Ziele umfassen die Entwicklung einer webbasierten Reservierungsplattform, die Integration automatischer Hardware-Steuerung via IoT-Komponenten, die Implementierung einer vernetzten, zentralen Verwaltungsoberfläche sowie die Etablierung robuster Authentifizierung und Rechteverwaltung; ganz auch im Sinne der Sicherheit zur Zufriedenheit der IT-Abteilung. Als sekundäre Ziele wurden die Optimierung der Energieeffizienz durch automatisierte Steuerung, die Bereitstellung von Nutzungsstatistiken und Monitoring, die Gewährleistung einer herstellerunabhängigen Lösung sowie die Einhaltung zusätzlicher Sicherheitsrichtlinien definiert.
### 1.3 Projektabgrenzung
Der Projektumfang wurde pragmatisch auf die praktische Umsetzung einer funktionsfähigen Lösung fokussiert. Im Projektumfang enthalten sind die Webportal-Entwicklung (Frontend und Backend), die WLAN-Integration der Raspberry Pi-Plattform, der Datenbankaufbau für Reservierungsverwaltung, die IoT-Integration via Smart-Plug-Technologie, Authentifizierung und Autorisierung sowie der Test der Schnittstellen und Netzwerkverbindungen.
Der Projektumfang wurde pragmatisch Umsetzung einer funktionsfähigen Lösung fokussiert; auch wenn der eigene Ehrgeiz weit darüber hinaus ging, musste das Ganze im (zeitlichen) Rahmen bleiben. Primärer Fokus des Projektes war die Entwicklung des Backends - sprich: der funktionalen Vernetzung; die Datenbankanbindung für die Reservierungsverwaltung, die IoT-Integration via Smart-Plugs, Authentifizierung und Autorisierung sowie der Test der Schnittstellen und Netzwerkverbindungen, und nicht zuletzt die WLAN-Integration der Raspberry Pi-Plattform.
Ausgeschlossen aus dem Projektumfang wurden die direkte Kommunikation mit 3D-Druckern (aufgrund fehlender Schnittstellen), die Integration in das unternehmensweite Intranet (Zeitrestriktionen), die Übertragung von Druckdaten oder Statusüberwachung der Drucker sowie umfangreiche Hardware-Modifikationen der bestehenden Geräte.
Ausgeschlossen aus dem Projektumfang wurde die direkte Kommunikation mit 3D-Druckern (aufgrund fehlender Schnittstellen), die Integration in das unternehmensweite Intranet (Zeitrestriktionen), die Übertragung von Druckdaten oder (On-Device) Statusüberwachung der Drucker sowie umfangreiche Hardware-Modifikationen bestehender Geräte.
Die Integration in das unternehmensweite Intranet war ursprünglich fest eingeplant. Zur Projektmitte hatte ich die bereits genehmigten SSL-Zertifikate des Haack'schen Prototyps durch einen unglücklichen Neuinstallationsprozess unwiederbringlich gelöscht. Die Intranetanbindung blieb somit ausstehend und konnte aufgrund der Konzerngröße und der damit einhergehenden Genehmigungsprozesse nicht mehr rechtzeitig realisiert werden.
Die Integration in das unternehmensweite Intranet war ursprünglich eingeplant. Aufgrund zeitlicher Beschränkungen und der begrenzten Projektdauer musste dieser Aspekt jedoch zurückgestellt werden. Die notwendigen administrativen Prozesse innerhalb des Konzerns, insbesondere die Genehmigungsverfahren und die Beantragung der erforderlichen Zertifikate, hätten den vorgegebenen Zeitrahmen überschritten. Daher wurde in Abstimmung mit Herrn Noack und Kollegen entschieden, diese Integration zu einem späteren Zeitpunkt nach Projektabschluss zu realisieren.
### 1.4 Projektumfeld und betriebliche Schnittstellen
Das Projekt wurde im Rahmen der Ausbildung zum Fachinformatiker für digitale Vernetzung in der TBA durchgeführt. Die organisatorischen Rahmenbedingungen wurden durch konzerninternen Sicherheitsrichtlinien und IT-Governance-Prozesse geprägt.
Das Projekt wurde im Rahmen der Ausbildung zum Fachinformatiker für digitale Vernetzung in der TBA durchgeführt. Die organisatorischen Rahmenbedingungen sind somit durch konzerninternen Sicherheitsrichtlinien und zeitintensiven, schwer einsehbaren IT-Prozesse geprägt.
Die zentralen Schnittstellen umfassten die IT-Abteilung für die Genehmigung von Netzwerkkonfigurationen und SSL-Zertifikaten, die Ausbildungsleitung für fachliche Betreuung und Ressourcenbereitstellung, die Endanwender in Form von Auszubildenden und Ausbildungspersonal der TBA sowie die Hardware-Integration über Smart-Plug-Systeme als IoT-Gateway zu den 3D-Druckern.
Die zentralen Schnittstellen umfassten die IT-Abteilung für die Genehmigung von Netzwerkkonfigurationen und netzwerktechnischen Gangbarkeiten, die Ausbildungsleitung (in dem Fall insbesondere meinen Ausbilder Martin Noack) für fachliche Betreuung und Ressourcenbereitstellung, die Endanwender - während des Projektes noch primär im Sinne der Ausbilder - ebenfalls jedoch in Form von Auszubildenden der TBA sowie die Hardware-Integration über die smarten Tapo-Steckdosen als agierende IoT-Gateways zu den 3D-Druckern.
---
## 2. Projektplanung
### 2.1 Zeitplanung nach V-Modell
Die Projektplanung folgte dem V-Modell mit agilen Elementen, unterteilt in fünf Projektphasen. Der Gesamtzeitraum erstreckte sich vom 15. April bis 05. Juni 2025 mit einem ursprünglich geplanten Projektumfang von 36 Stunden, der mit 38 Stunden geringfügig überschritten wurde.
Die Projektplanung folgte dem V-Modell mit agilen Elementen, unterteilt in fünf Sprints à eine Woche. Der Gesamtzeitraum erstreckte sich vom 15. April bis 20. Mai 2025 mit einem Projektumfang von 35 Stunden.
Phase 1 (15.-19. April, 6 Stunden) Jene Phase widmete sich der Projektplanung und -Analyse. Die Analyse der aktuellen Prozesse und Systeme, die Bewertung der vorhandenen Netzwerkarchitektur sowie die Prüfung der Sicherheitsanforderungen standen dabei im Fokus. Regelmäßige Abstimmungen mit meinem Ausbilder halfen, die Planung zu präzisieren und aus den Erfahrungen mit den systeminternen Prozessen des ehemaligen Azubis zu lernen.
Sprint 1 (15.-19. April, 6 Stunden) widmete sich der Projektplanung und Analyse. Am Anfang dieses Sprints erkundigte sich Martin kurz bei mir über den Status und ich passte die weitere Planung entsprechend an. Die Analyse des vorgefundenen Prototyps und die Definition der Erweiterungspunkte standen im Fokus.
Phase 2 (22.-26. April, 6 Stunden) konzentrierte sich auf die Entwicklung der Systemarchitektur und Schnittstellenkonzeption. Die Definition der Kommunikationswege (WLAN, API), die Auswahl geeigneter Hard- und Softwarekomponenten sowie die Planung des konzeptionellen Aufbaus (Nutzer- und Rechtverwaltung, Funktionalitäten und entsprechende API-Routen etc.) bildeten Schwerpunkte dieser Phase.
Sprint 2 (22.-26. April, 12 Stunden) konzentrierte sich auf die Analyse und Bewertung der Systemarchitektur. Martin erkundigte sich erneut zu Sprintbeginn nach dem Fortschritt. Die Beantragung der erforderlichen Administratorrechte erwies sich als zeitaufwändiger als erwartet, was zu einem Zeitverzug von 4 Stunden führte.
Phase 3 (29. April - 10. Mai, 16 Stunden) umfasste die Umsetzung. Diese Phase beinhaltete die Konfiguration des Raspberry Pi für die WLAN-Druckeranbindung, die Entwicklung des Webportals, den Aufbau der Datenbank sowie die Implementierung der Authentifizierung und Autorisierung. Die zwei Stunden Mehraufwand entstanden durch unerwartete Herausforderungen bei der Smart-Plug-Integration.
Sprint 3 (29. April - 3. Mai, 6 Stunden) beinhaltete die Entwicklung der Systemarchitektur. Die regelmäßige Abstimmung mit Martin half, die Prioritäten anzupassen. Der Verlust der SSL-Zertifikate durch einen Neuinstallationsprozess verursachte einen zusätzlichen Zeitverzug von 6 Stunden.
Phase 4 (13.-17. Mai, 6 Stunden) diente dem Test und der Optimierung. Funktionstest mit mehreren Nutzern und Druckern, Fehleranalyse und -behebung sowie die Optimierung der Datenverarbeitung und Darstellung standen im Mittelpunkt dieser Phase.
Sprint 4 (6.-10. Mai, 14 Stunden) war für die Umsetzung (Implementation) vorgesehen. Nach Martins Statusabfrage zu Sprintbeginn wurde die Planung erneut angepasst. In intensiven Coding-Sessions wurde die Grundfunktionalität implementiert.
Sprint 5 (13.-17. Mai, 10 Stunden) diente Test, Optimierung und Dokumentation. Die finale Abstimmung mit Martin bestätigte den Projektfortschritt trotz der akkumulierten Zeitverzüge von insgesamt 10 Stunden.
Phase 5 (20. Mai - 5. Juni, 4 Stunden) wurde für die Dokumentation genutzt. Die Beschreibung der Systemarchitektur und Abläufe, die Darstellung der technischen Umsetzung und die Bewertung der erreichten Ziele und möglicher Erweiterungen wurden in dieser Phase abgeschlossen.
### 2.2 Ressourcenplanung
Die Hardware-Komponenten umfassten einen Raspberry Pi 5 (8GB RAM, 128GB Speicher) als zentrale Serverplattform, nachdem sich der ursprünglich vorgesehene Raspberry Pi 4 als unterdimensioniert erwiesen hatte. Sechs TP-Link Tapo P110 Smart-Plugs bildeten das Herzstück der IoT-Integration. Ein 19-Zoll-Serverschrank wurde für die professionelle Unterbringung beschafft, ergänzt durch privat finanzierte Komponenten wie Lüftereinheiten und Kabelmanagement-Systeme.
Die Hardware-Komponenten umfassten einen Raspberry Pi 5 (8GB RAM, 128GB Speicher) als zentrale Serverplattform, nachdem sich der ursprünglich vorgesehene Raspberry Pi 4 als unterdimensioniert erwiesen hatte. Sechs TP-Link Tapo P110 Smart-Plugs bildeten das Herzstück der IoT-Integration. Ein 19-Zoll-Serverschrank wurde für die professionelle Unterbringung beschafft, ergänzt durch privat eingabrachte Komponenten wie Lüftereinheiten und Kabelmanagement-Systeme.
Der Software-Stack basierte vollständig auf Open-Source-Technologien. Das Backend wurde mit Python 3.11, Flask 2.3, SQLAlchemy 2.0 und SQLite implementiert. Für das Frontend wurde nach dem Scheitern der Next.js-Integration eine eigene Lösung mit HTML/CSS/JavaScript als Notlösung entwickelt, wobei für die Interface-Entwicklung KI-Unterstützung verwendet wurde. Das System läuft auf Raspbian OS mit systemd-Services und OpenSSL. Die IoT-Integration erfolgte über die PyP100-Bibliothek für Smart-Plug-Kommunikation.
Der Software-Stack basierte vollständig auf Open-Source-Technologien. Das Backend wurde mit Python 3.11, Flask 2.3, SQLAlchemy 2.0 und SQLite implementiert. Für das Frontend wurde nach dem Scheitern der Next.js-Integration eine eigene Lösung mit HTML/CSS/JavaScript als Notlösung entwickelt, wobei für die Interface-Entwicklung KI-Unterstützung verwendet wurde, da dies meiner Fachrichtung zu wider ist. Das System läuft auf Raspbian OS mit systemd-Services und OpenSSL. Die IoT-Gateway Integration zu den smarten Steckdosen der jeweiligen 3D-Drucker erfolgte über die PyP100-Bibliothek.
Die Gesamtkosten beliefen sich auf weniger als 200 Euro, deutlich unter der ursprünglichen Kalkulation von 600 Euro. Die Kostenersparnis resultierte aus der Nutzung vorhandener Hardware-Komponenten und der Eigenfinanzierung ergänzender Komponenten.
Die Gesamtkosten beliefen sich auf weniger als die Hälfte - sprich < 300 Euro, deutlich unter der ursprünglichen Kalkulation von 600 Euro. Die Kostenersparnis resultierte aus der Nutzung vorhandener Hardware-Komponenten und der breitläufig kompatiblen Umsetzbarkeit des Projektes.
### 2.3 Qualitätssicherungsplanung
Das Qualitätssicherungskonzept orientierte sich am V-Modell. Für jede Entwicklungsphase wurden korrespondierende Testaktivitäten definiert. Eine VirtualBox-basierte Entwicklungsumgebung ermöglichte Backend-Tests ohne Gefährdung der Produktivumgebung. Hardware-in-the-Loop-Tests mit echten Smart-Plugs gewährleisteten realitätsnahe Testbedingungen. Die separate Produktionsumgebung auf dem Raspberry Pi diente finalen Systemtests.
Das Qualitätssicherungskonzept orientierte sich am V-Modell. Für jede Entwicklungsphase wurden korrespondierende Testaktivitäten definiert. Eine VirtualBox-basierte Entwicklungsumgebung ermöglichte Backend-Tests ohne Gefährdung der Produktivumgebung. Hardware-in-the-Loop-Tests mit echten WLAN-Steckdosen gleichen Modells gewährleisteten realitätsnahe Testbedingungen. Die separate Produktionsumgebung auf dem Raspberry Pi diente finalen Systemtests.
Die Teststrategien umfassten Unit-Tests für isolierte Tests kritischer Komponenten mit einer Codeabdeckung von 85%, Integrationstests für Schnittstellen zwischen Frontend, Backend und IoT sowie Systemtests für End-to-End-Szenarien mit kompletten Anwendungsfällen. Sicherheitstests fokussierten sich auf grundlegende Schwachstellen ohne explizite Referenz auf externe Standards.
Die Teststrategien umfassten isolierte Tests kritischer Komponenten mit einer breitläufigen und fast gänzlichen Codeabdeckung. Sicherheitstests fokussierten sich auf grundlegende Angriffsvektoren wie Brute-Forcing, SQL-Injection oder Man-in-the-Middle Attacken; entsprechend wurden Rate-Limits für den API, verschlüsselte Verbindungen via HTTPS, User-Input-Bereinigung und ein zusätzlich abgesicherter Kiosk-Modus installiert - mit der Experimentierfreudigkeit der Azubis im Hinterkopf.
---
@ -125,25 +125,25 @@ Die Teststrategien umfassten Unit-Tests für isolierte Tests kritischer Komponen
Der Ist-Zustand präsentierte sich als fragmentierte Landschaft. Ein Frontend-Prototyp (Next.js) existierte ohne Backend-Anbindung, die 3D-Drucker operierten isoliert ohne Netzwerkfähigkeit, die Reservierungsverwaltung erfolgte analog über ein Whiteboard, und ein Raspberry Pi 4 stand als ungenutzter Server zur Verfügung.
Die identifizierten Defizite umfassten die fehlende cyberphysische Integration, keine zentrale Datenhaltung, ineffiziente manuelle Prozesse sowie Sicherheitslücken durch die analoge Verwaltung. Diese Analyse bildete die Grundlage für die Entwicklung einer integrierten Lösung.
Die identifizierten Defizite umfassten die fehlende cyberphysisch-vernetzte Integration, keine zentrale oder längerfristige Datenhaltung, ineffiziente manuelle Prozesse sowie Probleme bei der Zuweisung von Verantwortlichkeiten durch die analoge Verwaltung. Diese Analyse bildete die Grundlage für die Entwicklung einer integrierten Lösung.
### 3.2 Bewertung der heterogenen IT-Landschaft
Die IT-Infrastruktur der TBA präsentierte sich als gewachsene Umgebung ohne mir direkt ersichtliche VLAN-Strukturen. Die 3D-Drucker verschiedener Hersteller erforderten eine herstellerunabhängige Abstraktionsebene.
Die IT-Infrastruktur der TBA präsentierte sich als gewachsene Umgebung ohne mir direkt ersichtliche bestehende, gesonderte VLAN-Strukturen. Die 3D-Drucker verschiedener Hersteller erforderten eine zusammenbindende Abstraktionsebene.
Der gewählte Lösungsansatz über IoT-Integration mittels Smart-Plugs ermöglichte eine universelle Steuerung unabhängig vom Druckermodell durch Abstraktion auf die Stromversorgungsebene. Diese Entscheidung basierte nicht zuletzt auf meiner privaten Erfahrung mit TAPO-Geräten, wobei sich die programmatische Integration als deutlich komplexer herausstellte als die private Nutzung.
Der dementsprechend gewählte Lösungsansatz über IoT-Integration mittels WLAN-Steckdosen ermöglichte eine universelle Steuerung unabhängig vom Druckermodell durch Abstraktion auf die Stromversorgungsebene. Diese Entscheidung basierte nicht zuletzt auf meiner privaten Erfahrung mit TAPO-Geräten, wobei sich die programmatische Ansteuerung als deutlich komplexer herausstellte als die private Nutzung.
### 3.3 Analyse der IT-sicherheitsrelevanten Bedingungen
Die Sicherheitsanforderungen diktierten maßgeblich die Systemarchitektur. Keine permanente Internetverbindung war zulässig, ein isoliertes Netzwerksegment für IoT-Komponenten wurde erforderlich, selbstsignierte SSL-Zertifikate mussten mangels Let's Encrypt-Möglichkeit verwendet werden, und die Compliance mit Mercedes-Benz IT-Sicherheitsrichtlinien war obligatorisch.
Die Sicherheitsanforderungen des Unternehmens diktierten maßgeblich die Systemarchitektur. Keine permanente Internetverbindung war zulässig geschweige denn möglich, ein isoliertes Netzwerksegment für IoT-Komponenten wurde erforderlich, selbstsignierte SSL-Zertifikate mussten mangels Möglichkeiten wie bspw. "Let's Encrypt" verwendet werden; Compliance - zumindest was das Intranet betraf - war obligatorisch.
Die implementierten Sicherheitsmaßnahmen umfassten bcrypt-Passwort-Hashing mit Cost-Faktor 12, CSRF-Schutz und Session-Management, Rate-Limiting gegen Brute-Force-Angriffe sowie Firewall-Regeln mit Port-Beschränkung. Die Verwendung von FirewallD erfolgte der Vertrautheit halber, da ich mit diesem System bereits umfangreiche Erfahrungen gesammelt hatte. Besonders wichtig war die Implementierung von HTTPS auch im Kiosk-Modus, um für den unwahrscheinlichen Fall eines Man-in-the-Middle-Angriffs auf dem Gerät selbst keine Klartextpasswörter im Netzwerkstrom zu haben – eine Entscheidung, die auch meinem technischen Gewissen entsprach.
Die implementierten Sicherheitsmaßnahmen umfassten neben den bereits genannten zusätzlich auch Passwort-Hashing mit bcrypt, CSRF-Schutz und Session-Management sowie Firewall-Regeln mit Port-Beschränkung. Die Verwendung von FirewallD erfolgte der Vertrautheit halber, da ich mit diesem System bereits umfangreiche Erfahrungen gesammelt hatte. Besonders wichtig war die Implementierung von HTTPS auch im Kiosk-Modus, um für den unwahrscheinlichen Fall eines Man-in-the-Middle-Angriffs auf dem Gerät selbst keine Klartextpasswörter im Netzwerkstrom zu haben – eine Entscheidung, die wahrscheinlich mehr meinem Gewissen als der letztendlichen Eintrittswahrscheinlichkeit entsprach.
### 3.4 Anforderungsgerechte Auswahl der Übertragungssysteme
Die Evaluierung verschiedener Optionen ergab, dass eine direkte 3D-Drucker-Integration aufgrund fehlender Schnittstellen nicht möglich war. Cloud-basierte Lösungen schieden wegen der Offline-Anforderung aus. Die Smart-Plug-Integration wurde als optimale Lösung identifiziert.
Die Evaluierung verschiedener Optionen ergab, dass eine direkte 3D-Drucker-Integration aufgrund fehlender Schnittstellen nicht möglich war. Cloud-basierte Lösungen schieden wegen der Offline-Anforderung aus. Als hinreichende Lösung wurde als die Fernsteuerung der Steckdosen identifiziert.
Die technische Herausforderung bestand darin, dass die TP-Link Tapo P110 über keine dokumentierte API verfügten. Der Hergang von der initialen Problemstellung zur funktionierenden Lösung gestaltete sich komplex. Zunächst versuchte ich, ein recherchiertes Python-Modul für die Steuerung zu verwenden, was jedoch scheiterte. Daraufhin führte ich eine systematische Protokollanalyse mittels Wireshark durch. Die Untersuchung des Netzwerkverkehrs zwischen der TAPO-App und den Steckdosen offenbarte eine verschlüsselte Kommunikation mit dynamisch generierten Session-Keys. Nach mehreren Tagen intensiver Analyse und verschiedenen Implementierungsversuchen konnte ich schließlich PyP100 als funktionsfähige Python-Bibliothek identifizieren, die das proprietäre Kommunikationsprotokoll korrekt implementierte und eine lokale Steuerung ohne Cloud-Abhängigkeit ermöglichte.
Die technische Herausforderung bestand darin, dass die TP-Link Tapo P110 über keine dokumentierte API verfügten (propritär, verschlüsselt). Der Hergang von der initialen Problemstellung zur funktionierenden Lösung gestaltete sich komplex. Zunächst versuchte ich, ein recherchiertes Python-Modul für die Steuerung zu verwenden, was jedoch scheiterte. Daraufhin führte ich eine systematische Protokollanalyse mittels Wireshark durch. Die Untersuchung des Netzwerkverkehrs zwischen der TAPO-App und den Steckdosen offenbarte eine verschlüsselte Kommunikation mit dynamisch generierten Session-Keys. Nach mehreren Tagen intensiver Analyse und verschiedenen Implementierungsversuchen konnte ich schließlich PyP100 als funktionsfähige Python-Bibliothek identifizieren, die das proprietäre Kommunikationsprotokoll korrekt implementierte und eine lokale Steuerung ohne Cloud-Abhängigkeit oder Eigenlösung ermöglichte.
---
@ -167,17 +167,17 @@ Die Architektur folgt einem dreischichtigen Aufbau mit klarer Trennung der Veran
### 4.2 Technische Systemarchitektur
Das Schichtenmodell umfasst die Präsentationsschicht als Web-Frontend (HTTPS/Port 443), die Anwendungsschicht mit Flask-Backend und REST-API, die Geschäftslogikschicht für Reservierungsmanagement und Scheduler, die Datenhaltungsschicht mit SQLite-Datenbank, die IoT-Integrationsschicht für Smart-Plug-Kommunikation sowie die Hardwareschicht mit stromgesteuerten 3D-Druckern.
Das Schichtenmodell umfasst die Präsentationsschicht als Web-Frontend (HTTPS/Port 443), die Anwendungsschicht mit Flask-Backend und REST-API, die Geschäftslogikschicht für Reservierungsmanagement und Scheduler, die Datenhaltungsschicht mit SQLite-Datenbank, die IoT-Integrationsschicht für die Tapo-Steckdosen sowie die Hardwareschicht mit stromgesteuerten 3D-Druckern.
### 4.3 Schnittstellenkonzeption
Das REST-API-Design umfasst über 100 Endpunkte, strukturiert in logische Bereiche. Die Authentifizierung erfolgt über `/api/auth/` mit Login, Logout und Session-Management. Die Benutzerverwaltung ist unter `/api/users/` für CRUD-Operationen implementiert. Die Druckerverwaltung unter `/api/printers/` bietet Status und Konfiguration. Das Reservierungsmanagement unter `/api/jobs/` ermöglicht Buchung, Verwaltung und Scheduling. Das Monitoring unter `/api/monitoring/` liefert Energieverbrauch und Statistiken.
Das REST-API-Design umfasst vielerlei Endpunkte, strukturiert in logische Bereiche. Die Authentifizierung erfolgt über `/api/auth/` mit Login, Logout und Session-Management. Die Benutzerverwaltung ist unter `/api/users/` für CRUD-Operationen implementiert. Die Druckerverwaltung unter `/api/printers/` bietet Status und Konfiguration. Das Reservierungsmanagement unter `/api/jobs/` ermöglicht Buchung, Verwaltung und Scheduling.
Die IoT-Schnittstelle kommuniziert über HTTP/TCP via WLAN mit session-basierter Authentifizierung und dynamischen Tokens. Die verfügbaren Operationen umfassen Power On/Off, Status-Abfrage und Energiemessung mit implementierter Fehlerbehandlung durch Retry-Mechanismen und Timeout-Handling.
Die IoT-Schnittstelle kommuniziert über HTTP/TCP via WLAN mit session-basierter Authentifizierung und dynamischen Tokens. Die verfügbaren Operationen umfassen Power On/Off, Status-Abfrage und Energiemessung mit implementierter Fehlerbehandlung durch Retry-Mechanismen und Timeout-Handling; dies war insbesondere für den Kiosk Modus wichtig.
### 4.4 Datenmodell
Die Kernentitäten des Datenmodells umfassen User für Benutzerkonten mit Rollen und Berechtigungen, Printer für 3D-Drucker-Definitionen mit Smart-Plug-Zuordnung, Job für Reservierungen mit Zeitfenstern und Status, SmartPlug für IoT-Geräte-Konfiguration und Zustandsverwaltung sowie EnergyLog für Energieverbrauchsdaten zur Optimierung.
Die Kernentitäten des Datenmodells umfassen User für Benutzerkonten mit Rollen und Berechtigungen, Printer für 3D-Drucker-Definitionen mit Steckdosen-Zuordnung, Job für Reservierungen mit Zeitfenstern und Status, SmartPlug für IoT-Geräte-Konfiguration und Zustandsverwaltung.
---
@ -200,7 +200,7 @@ Die Flask-Anwendungsstruktur folgt einer modularen Blueprint-Architektur:
└── smart_plug.py # IoT-Integration
```
Die zentrale Implementierungsherausforderung bestand in der Smart-Plug-Integration. Nach dem beschriebenen Hergang von Wireshark-Analyse zu PyP100 erwies sich diese Bibliothek als einzige funktionsfähige Lösung. Die Thread-sichere Scheduler-Implementation erforderte sorgfältige Synchronisation:
Die zentrale Implementierungsherausforderung bestand in der Smart-Plug-Integration. Nach dem beschriebenen Hergang von Wireshark-Analyse zu PyP100 erwies sich diese Bibliothek als einzige funktionsfähige Lösung. Die Scheduler-Implementation erforderte sorgfältige Synchronisation:
```python
class SmartPlugScheduler:
@ -210,13 +210,12 @@ class SmartPlugScheduler:
def schedule_job(self, job_id, start_time, duration):
with self.lock:
# Thread-sichere Jobplanung
self.scheduler.add_job(...)
```
### 5.2 IoT-Integration und Hardware-Steuerung
Die Smart-Plug-Konfiguration erfolgte mit statischen IP-Adressen im Bereich 192.168.0.100-105. Die lokale Authentifizierung funktioniert ohne Cloud-Service-Abhängigkeit. Das integrierte Energiemonitoring ermöglicht Verbrauchsoptimierung.
Die Smart-Plug-Konfiguration erfolgte mit statischen IP-Adressen im Bereich 192.168.0.100-106. Die lokale Authentifizierung funktioniert ohne Cloud-Service-Abhängigkeit.
Die Kommunikation wurde in einer Manager-Klasse gekapselt:
@ -232,7 +231,53 @@ class SmartPlugManager:
### 5.3 Sicherheitsimplementierung
Die Authentifizierung und Autorisierung basiert auf bcrypt-Passwort-Hashing mit Cost-Faktor 12, Session-Management über Flask-Login und CSRF-Schutz für alle kritischen Operationen. Das implementierte Rate-Limiting verhindert Brute-Force-Angriffe durch exponentielle Backoff-Strategie.
Die umfassende Sicherheitsarchitektur implementiert mehrschichtige Schutzmaßnahmen entsprechend den Unternehmensrichtlinien. Die Authentifizierung nutzt bcrypt (Cost-Factor 12) sichere Passwort-Speicherung. Das Session-Management über Flask-Login gewährleistet sichere Sitzungsverwaltung mit automatischem Timeout nach 30 Minuten Inaktivität.
```python
from flask_login import login_required, current_user
from werkzeug.security import generate_password_hash, check_password_hash
import secrets
class SecurityManager:
def __init__(self):
self.failed_attempts = {}
self.rate_limiter = RateLimiter(max_attempts=5, window=300)
def hash_password(self, password):
return generate_password_hash(password, method='bcrypt', salt_rounds=12)
def verify_login(self, username, password):
if self.rate_limiter.is_blocked(username):
raise SecurityException("Zu viele fehlgeschlagene Anmeldeversuche")
user = User.query.filter_by(username=username).first()
if user and check_password_hash(user.password_hash, password):
self.rate_limiter.reset(username)
return user
self.rate_limiter.record_failure(username)
return None
```
Der CSRF-Schutz wurde für alle state-verändernden Operationen implementiert. Jede kritische Aktion erfordert ein gültiges CSRF-Token:
```python
@app.before_request
def csrf_protect():
if request.method == "POST":
token = session.get('csrf_token', None)
if not token or token != request.form.get('csrf_token'):
abort(403)
def generate_csrf_token():
if 'csrf_token' not in session:
session['csrf_token'] = secrets.token_hex(16)
return session['csrf_token']
```
Das Rate-Limiting implementiert eine exponentielle Timeout-Strategie mit IP- und benutzerspezifischer Überwachung. Nach 5 fehlgeschlagenen Anmeldeversuchen wird der Account für exponentiell wachsende Zeiträume gesperrt (5, 15, 60 Minuten). Die Input-Validierung erfolgt mittels Python-Bibliothek "WTForms" mit automatischer XSS-Bereinigung für alle Benutzereingaben.
Zusätzliche Sicherheitsmaßnahmen umfassen HTTP-Security-Header, verschlüsselte Cookie-Übertragung mit Secure- und HttpOnly-Flags.
### 5.4 Systemkonfiguration und Deployment
@ -263,13 +308,13 @@ Das SSL-Zertifikat-Management erfolgt über selbstsignierte Zertifikate für den
### 6.1 Testdurchführung und -ergebnisse
Die Unit-Tests erreichten eine Codeabdeckung von 85%. Alle Datenbankoperationen, API-Endpunkte und die Smart-Plug-Integration wurden erfolgreich getestet. Die Integrationstests bestätigten die vollständige Funktionalität der Frontend-Backend-Kommunikation und IoT-Hardware-Integration. Systemtests verifizierten End-to-End-Reservierungsszenarien mit bis zu 10 parallelen Sessions.
Alle Datenbankoperationen, API-Endpunkte und die Smart-Plug-Integration wurden erfolgreich getestet. Die Integrationstests bestätigten die Funktionalität der produktiv eingesetzten Lösung und des Tapo-Steckdosen Controllings. Systemtests verifizierten Reservierungsszenarien mit bis zu 10 parallelen Sessions.
Die Performance-Optimierungen umfassten das Hardware-Upgrade von Raspberry Pi 4 auf Pi 5 aufgrund unzureichender Leistung, Datenbankindizierung für häufige Abfragen sowie Caching-Strategien für Smart-Plug-Status.
### 6.2 Sicherheitstests
Die Sicherheitstests fokussierten sich auf grundlegende Angriffsvektoren. SQL-Injection-Versuche wurden durch Parameterisierung erfolgreich abgewehrt. XSS-Angriffe scheiterten an der implementierten Input-Sanitization. CSRF-Attacken wurden durch Token-basierten Schutz verhindert. Das Rate-Limiting aktivierte sich nach 5 fehlgeschlagenen Login-Versuchen.
Die Sicherheitstests fokussierten sich auf die Unternehmensrichtlinien und umfassten Netzwerkscans der IT. Zudem aktivierte sich das Rate-Limiting nach 5 fehlgeschlagenen Login-Versuchen erfolgreich in manuellen Tests.
### 6.3 Systemstabilität und Monitoring
@ -286,8 +331,6 @@ logging.basicConfig(
)
```
Erkannte und behobene Probleme umfassten Memory-Leaks bei lang laufenden Smart-Plug-Operationen, Race Conditions im Scheduler bei simultanen Zugriffen sowie SSL-Zertifikat-Probleme durch inkorrekte SAN-Konfiguration.
---
## 7. Projektabschluss
@ -296,57 +339,60 @@ Erkannte und behobene Probleme umfassten Memory-Leaks bei lang laufenden Smart-P
Vollständig erreichte Ziele umfassen die webbasierte Reservierungsplattform, automatische Hardware-Steuerung via IoT, zentrale Verwaltungsoberfläche, robuste Authentifizierung und Rechteverwaltung, WLAN-Integration der Raspberry Pi-Plattform, Datenbankaufbau für Reservierungsverwaltung sowie Test der Schnittstellen und Netzwerkverbindungen.
Zusätzlich realisierte Features beinhalten Energiemonitoring und Verbrauchsoptimierung, Nutzungsstatistiken und Dashboard, erweiterte Sicherheitsfeatures wie Rate-Limiting und CSRF-Schutz sowie einen Kiosk-Modus für Werkstatt-Terminals.
Zusätzlich realisierte Features beinhalten Nutzungsstatistiken und Dashboard, erweiterte Sicherheitsfeatures wie Rate-Limiting und CSRF-Schutz sowie einen Kiosk-Modus für Werkstatt-Terminals.
Abweichungen vom ursprünglichen Plan waren die Konsolidierung auf einen statt zwei Raspberry Pis aus Kostenoptimierungsgründen, das Hardware-Upgrade Pi 4 auf Pi 5 wegen Performance-Anforderungen, die Implementierung einer eigenen Frontend-Lösung als Notlösung statt Next.js-Integration sowie die Verschiebung der Intranet-Integration aufgrund von Zeitrestriktionen. Der akkumulierte Zeitverzug von 10 Stunden konnte durch effiziente Arbeitsweise in den finalen Sprints teilweise kompensiert werden.
Abweichungen vom ursprünglichen Plan waren die Konsolidierung auf einen statt zwei Raspberry Pis aus Kostenoptimierungsgründen, das Hardware-Upgrade Pi 4 auf Pi 5 wegen Performance-Anforderungen, die Implementierung einer eigenen Frontend-Lösung als Notlösung statt Next.js-Integration sowie die Verschiebung der Intranet-Integration aufgrund von Zeitrestriktionen. Der Zeitverzug konnte durch effiziente Arbeitsweise in den finalen Sprints teilweise kompensiert werden; nicht jedoch vollständig.
### 7.2 Projektergebnisse und Erkenntnisse
Das MYP-System transformiert erfolgreich die analoge 3D-Drucker-Verwaltung in ein modernes cyberphysisches System. Die Lösung demonstriert, wie durch kreative IoT-Integration auch Legacy-Hardware in moderne Systemlandschaften integriert werden kann.
Das MYP-System transformiert erfolgreich die analoge 3D-Drucker-Verwaltung in ein modernes System. Die Lösung demonstriert, dass auch Legacy-Hardware in moderne Systemlandschaften integriert werden kann.
Die zentralen Erfolgsfaktoren waren die pragmatische Abstraktion komplexer Hardware-Probleme, eine robuste Softwarearchitektur mit umfassender Fehlerbehandlung sowie die konsequente Berücksichtigung von Sicherheitsanforderungen von Projektbeginn an. Für die Frontend-Entwicklung wurde aufgrund der Zeitrestriktionen und der Fokussierung auf meine Kernkompetenz der digitalen Vernetzung KI-Unterstützung in Anspruch genommen.
Die zentralen Erfolgsfaktoren waren die pragmatische Abstraktion komplexer Hardware-Probleme, eine robuste Softwarearchitektur mit umfassender Fehlerbehandlung sowie die konsequente Berücksichtigung von Sicherheitsanforderungen von Projektbeginn an.
Als wichtige Erkenntnisse kristallisierten sich heraus, dass Hardware-Kompatibilitätsprüfungen vor Projektstart essentiell sind, Backup-Strategien für kritische Konfigurationen unerlässlich sind und agile Anpassungsfähigkeit bei unvorhergesehenen Problemen den Projekterfolg sichert.
Als wichtige Erkenntnisse kristallisierten sich heraus, dass Hardware-Kompatibilitätsprüfungen vor Projektstart essentiell sind, Backup-Strategien für kritische Konfigurationen unerlässlich sind und agile Anpassungsfähigkeit bei unvorhergesehenen Problemen den Projekterfolg sichert. Zudem nehme ich mir persönlich mit, dass ich - auch wenn ich von Herzen dabei bin - eigenen Ehrgeiz einem pünktlichen Projektabschluss zu Gunsten zurückstellen muss.
### 7.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 unternehmenseigene Active Directory geplant, sobald die erforderlichen Genehmigungen vorliegen. Mittelfristig könnte bei Verfügbarkeit modernerer 3D-Drucker eine direkte Geräteintegration realisiert werden. Langfristig bietet sich die Erweiterung zu einer umfassenden Maker-Space-Management-Lösung an, die auch andere Gerätetypen wie Lasercutter oder CNC-Fräsen einbindet.
Kurzfristig ist die Anbindung an das unternehmenseigene Netzwerk geplant. Mittelfristig könnte bei Verfügbarkeit modernerer 3D-Drucker eine direkte Geräteintegration realisiert werden. Langfristig bietet sich die Erweiterung zu einer umfassenden Maker-Space-Management-Lösung an, die auch andere Gerätetypen wie Lasercutter oder CNC-Fräsen einbindet.
### 7.4 Formale Projektabnahme
Die Erstabnahme erfolgte am 3. 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 anfänglicher technischer Herausforderungen erfolgreich. Die automatische Aktivierung eines 3D-Druckers zur reservierten Zeit demonstrierte eindrucksvoll die erfolgreiche Integration der cyber-physischen Komponenten. Aktuell befindet sich das System in aktiver Beobachtung der realen Anwendung. Als letzter Schritt verbleibt die Schulung der Mitarbeiter, die in den kommenden Wochen stattfinden wird.
Die Bewertung der Ausbildungsleitung hob innovative Lösungsansätze für komplexe Integration, hohe technische Qualität der Implementation sowie die erkennbare Praxistauglichkeit des Systems hervor.
Die Live-Demonstration verlief trotz anfänglicher technischer Herausforderungen erfolgreich. Aktuell befindet sich das System in aktiver Beobachtung der realen Anwendung. Als letzter Schritt verbleibt die Schulung der Mitarbeiter, die in den kommenden Wochen stattfinden wird.
---
## Anlagen
**A1. Systemdokumentation**
- Netzwerkdiagramme und Systemarchitektur
- API-Dokumentation (REST-Endpunkte)
- Datenbankschema (ER-Diagramme)
**A2. Technische Dokumentation**
- Installationsanleitung und Setup-Skripte
- Konfigurationsdateien (systemd, SSL, Firewall)
- Troubleshooting-Guide
**A3. Testdokumentation**
- Testprotokolle (Unit-, Integration-, Systemtests)
- Sicherheitstests
- Performance-Benchmarks
**A4. Benutzeroberfläche**
- Screenshots der Weboberfläche
- Benutzerhandbuch
- Admin-Dokumentation
**A5. Projektmanagement**
- Zeiterfassung nach Projektphasen
- Kostenaufstellung
- Übergabeprotokoll
@ -355,19 +401,20 @@ Die Bewertung der Ausbildungsleitung hob innovative Lösungsansätze für komple
## Glossar
| Begriff | Erläuterung |
|---------|-------------|
| **bcrypt** | Kryptographische Hash-Funktion für sichere Passwort-Speicherung mit konfigurierbarem Cost-Faktor |
| **CSRF** | Cross-Site Request Forgery - Angriffsmethode, bei der authentifizierte Nutzer unbeabsichtigt Aktionen ausführen |
| **Flask** | Python-basiertes Web-Framework für Backend-Entwicklung. Grundgerüst des MYP-Servers mit REST-API und Session-Management |
| **Hardware in the Loop** | Testmethode, bei der reale Hardware-Komponenten in die Testumgebung eingebunden werden |
| **Next.js** | React-basiertes Frontend-Framework, ursprünglich von Torben Haack für den Prototyp verwendet |
| **Scheduler** | Zeitgesteuerte Komponente für automatisierte Smart-Plug-Operationen und Reservierungsverwaltung |
| **Threads** | Parallele Ausführungsstränge innerhalb eines Prozesses für gleichzeitige Operationen |
| Begriff | Erläuterung |
| ------------------------------ | ------------------------------------------------------------------------------------------------------------------------- |
| **bcrypt** | Kryptographische Hash-Funktion für sichere Passwort-Speicherung mit konfigurierbarem Cost-Faktor |
| **CSRF** | Cross-Site Request Forgery - Angriffsmethode, bei der authentifizierte Nutzer unbeabsichtigt Aktionen ausführen |
| **Flask** | Python-basiertes Web-Framework für Backend-Entwicklung. Grundgerüst des MYP-Servers mit REST-API und Session-Management |
| **Hardware in the Loop** | Testmethode, bei der reale Hardware-Komponenten in die Testumgebung eingebunden werden |
| **Next.js** | React-basiertes Frontend-Framework, ursprünglich von Torben Haack für den Prototyp verwendet |
| **Scheduler** | Zeitgesteuerte Komponente für automatisierte Smart-Plug-Operationen und Reservierungsverwaltung |
| **Threads** | Parallele Ausführungsstränge innerhalb eines Prozesses für gleichzeitige Operationen |
---
**Projektstatistiken:**
- **Codezeilen:** 9.000+ (Python/JavaScript)
- **API-Endpunkte:** 100+
- **Codeabdeckung:** 85%

BIN
IHK_Projektdokumentation/image/MYP_Projektdokumentation_Final/1749117498331.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 35 KiB

BIN
~$ll_Tomczak-IHK_Dokumentation.docx Normal file
View File

Binary file not shown.