32 KiB
MYP – Manage Your Printer
Digitalisierung des 3D-Drucker-Reservierungsprozesses durch Etablierung der cyberphysischen Kommunikation mit relevanten Hardwarekomponenten
Abschlussprüfung – Sommer 2025
Fachinformatiker für digitale Vernetzung
Abgabedatum: 5. Juni 2025
Ausbildungsbetrieb
Mercedes-Benz AG
Daimlerstraße 143
D-12277 Berlin
Prüfungsbewerber
Till Tomczak
Hainbuchenstraße 19
D-16761 Hennigsdorf
Inhaltsverzeichnis
- Einleitung und Projektanalyse
- Projektplanung und Ressourcenmanagement
- Durchführung und technische Implementierung
- Projektabschluss und Bewertung
1. Einleitung und Projektanalyse
1.1 Ausgangssituation und Problemstellung
Die Technische Berufsausbildungsstätte (TBA) der Mercedes-Benz AG am Standort Berlin steht vor einer zunehmenden Herausforderung in der effizienten Nutzung ihrer Ressourcen. Mit sechs hochwertigen 3D-Druckern verschiedener Hersteller, darunter Modelle von Prusa, Ultimaker und Artillery, verfügt die Einrichtung über eine beachtliche Produktionskapazität für die praktische Ausbildung. Jedoch offenbarte sich im täglichen Betrieb ein gravierendes Problem: Das vollständige Fehlen eines digitalen Reservierungs- und Verwaltungssystems führte zu erheblichen Ineffizienzen und Konflikten.
Die bisherige Praxis basierte auf einem manuellen Reservierungskalender in Form eines Whiteboards, welches neben den Druckern angebracht war. Diese analoge Lösung führte regelmäßig zu Doppelbuchungen, wenn mehrere Auszubildende gleichzeitig dasselbe Zeitfenster reservierten. Darüber hinaus mussten die Drucker manuell ein- und ausgeschaltet werden, was häufig vergessen wurde und zu unnötigem Stromverbrauch führte. Die fehlende Dokumentation der tatsächlichen Nutzungszeiten machte es unmöglich, valide Statistiken über die Auslastung der Geräte zu erstellen oder eine faire Kostenverteilung vorzunehmen.
Mein Ausbilder erkannte die Dringlichkeit einer digitalen Lösung, insbesondere nachdem ein früherer Versuch eines Auszubildenden, ein Frontend-System zu entwickeln, gescheitert war. Dieses vorherige Projekt hatte zwar eine ansprechende Benutzeroberfläche hervorgebracht, jedoch fehlte jegliche Backend-Funktionalität und Hardware-Integration, wodurch es in der Praxis nicht einsetzbar war.
1.2 Projektauftrag und Zielsetzung
Vor diesem Hintergrund erhielt ich den Auftrag, ein vollständiges cyber-physisches System zu entwickeln, welches die digitale Verwaltung der 3D-Drucker mit deren physischer Steuerung verbindet. Das System sollte dabei den Namen "MYP - Manage Your Printer" tragen und eine umfassende Lösung für alle identifizierten Probleme bieten.
Die Kernzielsetzung des Projekts umfasste die Entwicklung einer Plattform, die nicht nur die Reservierung der Drucker digital abbildet, sondern auch deren automatische Steuerung übernimmt. Dabei war es von zentraler Bedeutung, dass das System vollständig offline-fähig ist, da die Sicherheitsrichtlinien der Mercedes-Benz AG keine dauerhafte Internetverbindung in der Produktionsumgebung erlauben. Diese Anforderung stellte eine besondere technische Herausforderung dar, da moderne Webapplikationen häufig auf Cloud-Services und externe APIs angewiesen sind.
Ein weiteres wichtiges Projektziel war die Herstellerunabhängigkeit der Lösung. Da die vorhandenen 3D-Drucker von verschiedenen Herstellern stammen und keine einheitliche Schnittstelle bieten, musste ein Ansatz gefunden werden, der universell einsetzbar ist. Die Lösung sollte zudem eine klare Rollentrennung zwischen administrativen Nutzern, die das System verwalten, und regulären Nutzern, die lediglich Reservierungen vornehmen, implementieren.
1.3 Lösungskonzept und technische Architektur
Nach eingehender Analyse der Anforderungen entwickelte ich ein innovatives Lösungskonzept, welches auf der Integration von TP-Link Tapo P110 Smart-Plugs basiert. Diese intelligenten Steckdosen fungieren als universelle Hardware-Schnittstelle zwischen dem digitalen System und den physischen 3D-Druckern. Durch die Kontrolle der Stromzufuhr können die Drucker unabhängig von Hersteller und Modell gesteuert werden, ohne dass direkte Eingriffe in deren Firmware oder Steuerungssysteme notwendig sind.
Das technische Konzept sieht eine dreischichtige Architektur vor: Die Präsentationsschicht besteht aus einer Progressive Web App (PWA), die sowohl auf Desktop-Computern als auch auf mobilen Geräten funktioniert. Die Geschäftslogik wird durch ein Flask-basiertes Backend realisiert, welches eine umfangreiche REST-API zur Verfügung stellt. Als Datenhaltungsschicht dient eine SQLite-Datenbank, die alle Reservierungen, Nutzerdaten und Systemkonfigurationen lokal speichert.
Die Kommunikation zwischen den Komponenten erfolgt ausschließlich über das lokale Netzwerk. Das Backend kommuniziert über die PyP100-Bibliothek direkt mit den Smart-Plugs, welche sich im selben WLAN-Segment befinden. Ein besonderes Augenmerk lag auf der Implementierung eines robusten Schedulers, der im 60-Sekunden-Intervall die anstehenden Reservierungen überprüft und die entsprechenden Schaltbefehle an die Smart-Plugs sendet.
1.4 Projektumfeld und Rahmenbedingungen
Das Projekt wurde im Rahmen meiner Ausbildung zum Fachinformatiker für digitale Vernetzung bei der Mercedes-Benz AG durchgeführt. Die technische Berufsausbildungsstätte bietet ideale Bedingungen für die Umsetzung eines solchen Projekts, da hier sowohl die notwendige Hardware-Infrastruktur als auch die fachliche Expertise vorhanden sind.
Die organisatorischen Rahmenbedingungen sahen eine enge Zusammenarbeit mit meinem Teamkollegen Torben Haack vor, der parallel die Entwicklung eines modernen Next.js-Frontends übernahm. Diese Arbeitsteilung ermöglichte es mir, mich vollständig auf die Backend-Entwicklung und Hardware-Integration zu konzentrieren. Regelmäßige Abstimmungen mit der Ausbildungsleitung stellten sicher, dass das System den praktischen Anforderungen des Ausbildungsbetriebs entspricht.
Besondere Herausforderungen ergaben sich aus den strengen Sicherheitsrichtlinien der Mercedes-Benz AG. Das System musste so konzipiert werden, dass es keinerlei Verbindung zum Internet benötigt und alle Daten lokal verarbeitet werden. Gleichzeitig sollte es den Compliance-Anforderungen hinsichtlich Datenschutz und IT-Sicherheit genügen. Diese Vorgaben beeinflussten maßgeblich die Architekturentscheidungen und führten zur Implementierung umfangreicher Sicherheitsmaßnahmen.
1.5 Projektabgrenzung
Für eine erfolgreiche Projektumsetzung war es essentiell, den Projektumfang klar zu definieren und abzugrenzen. Das MYP-System fokussiert sich ausschließlich auf die Verwaltung der Stromversorgung und die Reservierungslogik. Eine direkte Kommunikation mit den 3D-Druckern, etwa zur Übertragung von Druckdaten oder zur Überwachung des Druckfortschritts, wurde bewusst ausgeklammert. Diese Entscheidung basierte auf der Heterogenität der vorhandenen Druckermodelle und dem unverhältnismäßig hohen Implementierungsaufwand für herstellerspezifische Schnittstellen.
Ebenfalls außerhalb des Projektumfangs lag die Integration in übergeordnete ERP-Systeme oder die Anbindung an das Mercedes-Benz Intranet. Obwohl eine solche Integration perspektivisch wünschenswert wäre, hätte sie den zeitlichen Rahmen des Projekts gesprengt und zusätzliche Genehmigungsprozesse erfordert. Stattdessen wurde eine autarke Lösung entwickelt, die alle notwendigen Funktionen lokal bereitstellt.
2. Projektplanung und Ressourcenmanagement
2.1 Methodisches Vorgehen und Projektorganisation
Für die Umsetzung des MYP-Projekts wählte ich einen agilen Entwicklungsansatz nach Scrum-Prinzipien. Diese Methodik erwies sich als ideal für ein Projekt dieser Größenordnung, da sie iterative Entwicklung mit regelmäßigem Feedback kombiniert. Die Gesamtprojektlaufzeit wurde auf fünf Wochen festgelegt, vom 15. April bis zum 20. Mai 2025, und in fünf einwöchige Sprints unterteilt.
Der erste Sprint fokussierte sich auf das System-Design und die Grundlagenarbeit. In dieser Phase erarbeitete ich das detaillierte Datenmodell, spezifizierte die API-Endpunkte und etablierte die erste Kommunikation mit den Smart-Plugs. Die erfolgreiche Ansteuerung der TP-Link Tapo P110 Geräte über die PyP100-Bibliothek war ein kritischer Meilenstein, der die technische Machbarkeit des Gesamtkonzepts bestätigte.
Im zweiten Sprint lag der Schwerpunkt auf der Backend-Implementierung. Ich entwickelte die Flask-Applikation mit ihrer modularen Blueprint-Struktur, implementierte das SQLAlchemy-basierte Datenbankschema und schuf die Grundlagen für die REST-API. Besondere Aufmerksamkeit widmete ich der Fehlerbehandlung und der Implementierung von Retry-Mechanismen für die Hardware-Kommunikation, da Netzwerkverbindungen zu IoT-Geräten erfahrungsgemäß nicht immer stabil sind.
Der dritte Sprint war der Entwicklung des automatisierten Schedulers gewidmet. Diese Komponente stellt das Herzstück des Systems dar, da sie die Verbindung zwischen den digitalen Reservierungen und der physischen Hardware herstellt. Die Implementierung erfolgte mittels Python-Threading, wobei besonderer Wert auf Robustheit und Fehlertoleranz gelegt wurde. Der Scheduler prüft im Minutentakt alle anstehenden Reservierungen und führt die entsprechenden Schaltaktionen durch.
2.2 Ressourcenplanung und Infrastruktur
Die Hardwareausstattung für das Projekt umfasste einen Raspberry Pi 4 Model B mit 4 GB RAM als zentralen Server. Diese Wahl war bewusst getroffen worden, da der Raspberry Pi eine kostengünstige, energieeffiziente und dennoch leistungsfähige Plattform für das Backend-System darstellt. Ausgestattet mit einer 64 GB SD-Karte bietet er ausreichend Speicherplatz für die Datenbank und Logdateien.
Als Kernelement der Hardware-Integration kamen sechs TP-Link Tapo P110 Smart-Plugs zum Einsatz. Diese intelligenten Steckdosen verfügen über eine WLAN-Schnittstelle und eine lokale API, die eine Steuerung ohne Cloud-Anbindung ermöglicht. Jeder Smart-Plug wurde einem 3D-Drucker zugeordnet und erhielt eine feste IP-Adresse im Netzwerk. Die Konfiguration erfolgte so, dass die Geräte ausschließlich im lokalen Netzwerksegment erreichbar sind.
Für die Benutzerinteraktion vor Ort wurde ein 7-Zoll-Touch-Display an den Raspberry Pi angeschlossen. Dieses Display zeigt im Kiosk-Modus eine speziell optimierte Ansicht der Webanwendung, die aktuelle Reservierungen und den Systemstatus visualisiert. Die Touch-Funktionalität ermöglicht es den Nutzern, auch ohne Tastatur und Maus grundlegende Interaktionen durchzuführen.
Auf der Softwareseite setzte ich konsequent auf Open-Source-Technologien. Python 3.11 bildete die Basis für die Backend-Entwicklung, ergänzt durch das Flask-Framework in Version 2.3. Für die Datenbankabstraktion kam SQLAlchemy 2.0 zum Einsatz, welches eine elegante und pythonische Art der Datenbankinteraktion ermöglicht. Die Wahl von SQLite als Datenbanksystem war durch die Offline-Anforderung motiviert - es benötigt keinen separaten Datenbankserver und speichert alle Daten in einer lokalen Datei.
2.3 Qualitätssicherung und Testkonzept
Die Qualitätssicherung folgte dem bewährten V-Modell, welches für jede Entwicklungsphase entsprechende Testaktivitäten vorsieht. Auf der untersten Ebene implementierte ich umfangreiche Unit-Tests für alle kritischen Funktionen. Diese Tests überprüften isoliert die Korrektheit der Datenbankoperationen, die Validierung von API-Eingaben und die Geschäftslogik der Reservierungsverwaltung.
Die Integrationstests stellten sicher, dass die verschiedenen Systemkomponenten korrekt zusammenarbeiten. Besondere Aufmerksamkeit galt dabei der Schnittstelle zwischen Backend und Smart-Plugs. Ich simulierte verschiedene Szenarien wie Netzwerkausfälle, nicht erreichbare Geräte und gleichzeitige Zugriffe, um die Robustheit des Systems zu gewährleisten. Die API-Endpunkte wurden systematisch mit verschiedenen Eingabedaten getestet, einschließlich ungültiger und potenziell schädlicher Eingaben.
Auf Systemebene führte ich End-to-End-Tests durch, die komplette Arbeitsabläufe abbildeten. Ein typischer Testfall umfasste die Anmeldung eines Benutzers, die Erstellung einer Reservierung, die automatische Einschaltung des Druckers zur geplanten Zeit und die anschließende Abschaltung nach Ablauf der Reservierung. Diese Tests wurden sowohl manuell als auch automatisiert durchgeführt, wobei besonderer Wert auf die Überprüfung der zeitlichen Präzision gelegt wurde.
Performance-Tests auf der Raspberry Pi Hardware stellten sicher, dass das System auch unter Last zuverlässig funktioniert. Ich simulierte gleichzeitige Zugriffe von mehreren Nutzern, umfangreiche Datenbankabfragen und die parallele Steuerung aller sechs Smart-Plugs. Die Ergebnisse zeigten, dass der Raspberry Pi 4 mehr als ausreichend Leistungsreserven für den geplanten Einsatzzweck bietet.
2.4 Netzwerkarchitektur und Sicherheitskonzept
Die Integration in die bestehende Netzwerkinfrastruktur der Mercedes-Benz TBA erforderte sorgfältige Planung und Abstimmung mit der IT-Abteilung. Das MYP-System wurde in einem dedizierten IoT-Subnetz (192.168.0.0/24) platziert, welches vom Produktionsnetzwerk isoliert ist. Diese Segmentierung erhöht die Sicherheit und verhindert unautorisierten Zugriff auf kritische Systeme.
Der Raspberry Pi erhielt die statische IP-Adresse 192.168.0.105, während die Smart-Plugs im Bereich 192.168.0.151 bis 192.168.0.156 konfiguriert wurden. Die Firewall-Regeln wurden so eingerichtet, dass nur die notwendigen Ports geöffnet sind: Port 5000 für die Flask-Anwendung, Port 22 für administrative SSH-Zugriffe und Port 5443 für verschlüsselte HTTPS-Verbindungen. Ausgehende Verbindungen wurden strikt auf die IP-Adressen der Smart-Plugs beschränkt.
Für die verschlüsselte Kommunikation implementierte ich ein selbstsigniertes SSL-Zertifikat. Obwohl selbstsignierte Zertifikate in Produktionsumgebungen oft kritisch gesehen werden, sind sie für isolierte Netzwerke ohne Internetzugang die pragmatische Lösung. Das Zertifikat wurde mit einer Gültigkeit von einem Jahr ausgestellt und enthält alle relevanten Hostnamen und IP-Adressen als Subject Alternative Names.
Die Authentifizierung basiert auf einem robusten System mit gehashten Passwörtern. Ich verwendete bcrypt mit einem angemessenen Cost-Faktor, um Brute-Force-Angriffe zu erschweren. Nach fünf fehlgeschlagenen Anmeldeversuchen wird ein Benutzerkonto für 30 Minuten gesperrt. Alle sicherheitsrelevanten Ereignisse werden in separaten Logdateien protokolliert, die regelmäßig ausgewertet werden können.
3. Durchführung und technische Implementierung
3.1 Backend-Architektur und API-Design
Die Implementierung des MYP-Backends folgte einer modularen Architektur, die Wartbarkeit und Erweiterbarkeit in den Vordergrund stellt. Das Flask-Framework bietet mit seinem Blueprint-System eine elegante Möglichkeit, die Anwendung in logische Module zu unterteilen. Ich strukturierte die API in vier Hauptbereiche: Authentifizierung, Benutzerverwaltung, Druckerverwaltung und Job-Management.
Die Authentifizierungs-Blueprint implementiert die vollständige Benutzerverwaltung mit Registrierung, Anmeldung und Session-Management. Bei der Registrierung werden Passwörter mit bcrypt gehasht und zusammen mit einem Salt in der Datenbank gespeichert. Die Session-Verwaltung nutzt Flask-Login, wobei Sessions nach acht Stunden automatisch ablaufen. Für zusätzliche Sicherheit implementierte ich CSRF-Schutz und konfigurierte die Session-Cookies mit den Attributen Secure, HttpOnly und SameSite.
Das Herzstück der API bildet die Job-Management-Blueprint, die alle Funktionen rund um Reservierungen bereitstellt. Nutzer können über den POST /api/v1/jobs Endpunkt neue Reservierungen erstellen, wobei die Eingabedaten umfassend validiert werden. Das System prüft automatisch auf Überschneidungen mit bestehenden Reservierungen und verhindert Doppelbuchungen. Die Implementierung unterstützt auch erweiterte Funktionen wie das nachträgliche Verlängern von Reservierungen oder das vorzeitige Beenden von Jobs.
Die Drucker-Blueprint verwaltet die Konfiguration der 3D-Drucker und ihrer zugeordneten Smart-Plugs. Administratoren können neue Drucker hinzufügen, bestehende Konfigurationen anpassen oder Drucker temporär deaktivieren. Jeder Drucker-Eintrag speichert neben den Grunddaten wie Name und Standort auch die IP-Adresse und MAC-Adresse des zugehörigen Smart-Plugs. Diese Informationen sind essentiell für die automatische Steuerung.
3.2 Smart-Plug-Integration und Hardware-Steuerung
Die Integration der TP-Link Tapo P110 Smart-Plugs stellte eine der zentralen technischen Herausforderungen des Projekts dar. Die PyP100-Bibliothek bietet zwar eine Python-Schnittstelle zu den Geräten, jedoch mussten zahlreiche Anpassungen vorgenommen werden, um eine zuverlässige Kommunikation zu gewährleisten.
Ich entwickelte eine SmartPlugController-Klasse, die als Abstraktionsschicht zwischen der Geschäftslogik und der Hardware fungiert. Diese Klasse implementiert robuste Fehlerbehandlung mit automatischen Wiederholungsversuchen bei Verbindungsfehlern. Die Retry-Logik nutzt exponentielles Backoff, um das Netzwerk nicht zu überlasten. Nach drei erfolglosen Versuchen wird der Fehler protokolliert und eine Benachrichtigung generiert.
Ein kritischer Aspekt war die Authentifizierung bei den Smart-Plugs. Die Geräte verwenden ein proprietäres Protokoll mit Verschlüsselung, welches eine Handshake-Prozedur erfordert. Die Zugangsdaten werden verschlüsselt in der Systemkonfiguration gespeichert und nur bei Bedarf entschlüsselt. Für jede Aktion wird eine neue Verbindung aufgebaut, um Probleme mit langlebigen Verbindungen zu vermeiden.
Die Implementierung unterstützt drei Hauptaktionen: Einschalten, Ausschalten und Statusabfrage. Die Statusabfrage liefert neben dem Schaltzustand auch Informationen über den aktuellen Stromverbrauch, die Gesamtlaufzeit und die Signalstärke der WLAN-Verbindung. Diese Daten werden für Monitoring-Zwecke in der Datenbank gespeichert und können für spätere Analysen herangezogen werden.
3.3 Scheduler-Implementierung und Automatisierung
Der Job-Scheduler bildet das Kernstück der Automatisierung und wurde als eigenständiger Thread implementiert, der parallel zur Flask-Anwendung läuft. Diese Architektur gewährleistet, dass die Scheduler-Aktivitäten die Reaktionsfähigkeit der Web-API nicht beeinträchtigen.
Der Scheduler-Thread wird beim Start der Anwendung initialisiert und läuft kontinuierlich im Hintergrund. In einer Endlosschleife prüft er im 60-Sekunden-Intervall alle anstehenden Aufgaben. Diese Prüfung umfasst sowohl das Starten von Reservierungen, deren Startzeit erreicht wurde, als auch das Beenden von abgelaufenen Reservierungen. Die Implementierung berücksichtigt dabei einen Sicherheitspuffer von fünf Minuten nach dem geplanten Ende, um sicherzustellen, dass laufende Druckvorgänge nicht vorzeitig unterbrochen werden.
Bei der Verarbeitung von Start-Events ändert der Scheduler zunächst den Status der Reservierung in der Datenbank von "scheduled" auf "running". Anschließend wird über den SmartPlugController der entsprechende Drucker eingeschaltet. War die Aktion erfolgreich, wird ein Erfolgseintrag im System-Log erstellt. Bei Fehlern wird der Vorgang bis zu dreimal wiederholt, bevor eine Fehlerbenachrichtigung generiert wird.
Die Thread-Sicherheit war ein wichtiger Aspekt der Implementierung. Da der Scheduler-Thread auf dieselbe Datenbank zugreift wie die Web-Requests, musste sichergestellt werden, dass keine Race Conditions auftreten. Ich löste dies durch die Verwendung von Datenbank-Transaktionen und expliziten Locks für kritische Operationen. Zudem wird für jeden Datenbankzugriff aus dem Scheduler-Thread ein eigener Application Context erstellt.
3.4 Datenmodell und Persistierung
Das Datenmodell wurde sorgfältig entworfen, um alle Anforderungen des Systems abzubilden und gleichzeitig Erweiterbarkeit für zukünftige Features zu gewährleisten. Die Kern-Entitäten sind User, Printer, Job und verschiedene Log-Tabellen für Audit- und Monitoring-Zwecke.
Die User-Tabelle speichert neben den Anmeldedaten auch Metainformationen wie die Anzahl fehlgeschlagener Login-Versuche und Zeitstempel für Sicherheitssperren. Das Rollenmodell unterscheidet zwischen normalen Nutzern und Administratoren, wobei die Rechteverwaltung über Decorators in den API-Endpunkten implementiert ist. Für zukünftige Erweiterungen ist bereits die Struktur für Zwei-Faktor-Authentifizierung vorbereitet.
Die Printer-Tabelle bildet die physischen 3D-Drucker mit ihren Eigenschaften ab. Neben beschreibenden Attributen wie Name und Standort sind hier die kritischen Netzwerkinformationen der zugeordneten Smart-Plugs hinterlegt. Ein Boolean-Flag ermöglicht es, Drucker temporär zu deaktivieren, ohne die Konfiguration zu löschen. Dies ist nützlich für Wartungsarbeiten oder bei Defekten.
Die Job-Tabelle ist das Herzstück des Datenmodells und speichert alle Reservierungen. Jeder Job hat einen definierten Start- und Endzeitpunkt sowie einen Status, der den Lebenszyklus der Reservierung abbildet. Die möglichen Status-Werte sind "scheduled" für geplante, "running" für aktive, "finished" für abgeschlossene und "aborted" für vorzeitig beendete Reservierungen. Zusätzlich werden die tatsächlichen Start- und Endzeiten gespeichert, um Abweichungen vom Plan nachvollziehen zu können.
Für Audit- und Monitoring-Zwecke implementierte ich mehrere spezialisierte Log-Tabellen. Die PlugStatusLog-Tabelle protokolliert jede Interaktion mit den Smart-Plugs, einschließlich Erfolg oder Misserfolg und Antwortzeiten. Die EnergyUsageLog-Tabelle sammelt Stromverbrauchsdaten für spätere Auswertungen. Die SystemPerformanceLog-Tabelle zeichnet Metriken wie CPU-Auslastung und Speicherverbrauch auf, um die Systemgesundheit zu überwachen.
3.5 Sicherheitsimplementierung und Datenschutz
Die Implementierung der Sicherheitsmaßnahmen folgte dem Prinzip "Security by Design" und berücksichtigte die spezifischen Anforderungen der Mercedes-Benz AG sowie die DSGVO-Vorgaben. Ein mehrschichtiger Sicherheitsansatz gewährleistet den Schutz vor verschiedenen Bedrohungsszenarien.
Auf Netzwerkebene implementierte ich strenge Firewall-Regeln mittels iptables. Eingehende Verbindungen werden nur für die essentiellen Dienste akzeptiert, wobei SSH-Zugriffe auf das lokale Subnetz beschränkt sind. Ausgehende Verbindungen sind ausschließlich zu den IP-Adressen der Smart-Plugs erlaubt. Diese Konfiguration verhindert effektiv, dass das System als Ausgangspunkt für Angriffe auf andere Netzwerkressourcen missbraucht werden kann.
Die Anwendungsebene implementiert umfassende Eingabevalidierung für alle API-Endpunkte. Ich entwickelte ein einfaches Intrusion Detection System, das verdächtige Muster in den Anfragen erkennt. Typische Angriffsvektoren wie SQL-Injection, Cross-Site-Scripting oder Path-Traversal werden erkannt und blockiert. Bei der Erkennung kritischer Angriffsmuster wird die IP-Adresse des Angreifers temporär gesperrt.
Für die DSGVO-Compliance implementierte ich automatische Datenbereinigungsroutinen. Personenbezogene Daten werden nur so lange gespeichert, wie es für den Betrieb notwendig ist. Session-Daten werden nach 30 Tagen gelöscht, während Job-Daten nach zwei Jahren anonymisiert werden. Die Anonymisierung entfernt die Benutzer-Zuordnung, behält aber die technischen Daten für statistische Auswertungen. Nutzer haben zudem die Möglichkeit, ihre Daten gemäß Artikel 20 DSGVO zu exportieren.
3.6 Deployment und Produktivbetrieb
Die Inbetriebnahme des Systems auf dem Raspberry Pi erforderte sorgfältige Konfiguration, um einen stabilen und wartungsarmen Betrieb zu gewährleisten. Ich erstellte ein umfassendes Deployment-Skript, das alle notwendigen Schritte automatisiert durchführt.
Die Flask-Anwendung wird als systemd-Service konfiguriert, wodurch sie automatisch beim Systemstart gestartet wird und bei Abstürzen automatisch neu gestartet wird. Die Service-Konfiguration implementiert zusätzliche Sicherheitsmaßnahmen wie die Ausführung mit eingeschränkten Rechten und die Isolation des Dateisystems. Logs werden über das systemd-Journal verwaltet und automatisch rotiert.
Für die Benutzerschnittstelle vor Ort konfigurierte ich einen Kiosk-Modus, der beim Start des Raspberry Pi automatisch aktiviert wird. Ein Chromium-Browser im Vollbildmodus zeigt die speziell optimierte Kiosk-Ansicht der Anwendung. Der Browser ist so konfiguriert, dass Fehlermeldungen unterdrückt werden und bei Abstürzen automatisch neu gestartet wird. Die Touch-Funktionalität des Displays wurde aktiviert und kalibriert.
Die Backup-Strategie sieht tägliche Snapshots der SQLite-Datenbank vor, die auf einer separaten Partition gespeichert werden. Ein Cron-Job führt diese Backups automatisch durch und entfernt Backups, die älter als 30 Tage sind. Zusätzlich wird die gesamte Systemkonfiguration wöchentlich gesichert, um im Fehlerfall eine schnelle Wiederherstellung zu ermöglichen.
4. Projektabschluss und Bewertung
4.1 Projektergebnis und Zielerreichung
Nach fünf intensiven Entwicklungswochen konnte das MYP-System erfolgreich fertiggestellt und in Betrieb genommen werden. Das Endergebnis übertrifft die ursprünglichen Projektanforderungen in mehreren Aspekten deutlich und stellt eine vollwertige Produktionslösung für die 3D-Drucker-Verwaltung der TBA dar.
Die implementierte Lösung umfasst über 9.000 Zeilen sorgfältig strukturierten Python-Code, der eine robuste und wartbare Basis für den langfristigen Betrieb bildet. Die REST-API bietet mehr als 100 Endpunkte, die alle Aspekte der Drucker- und Reservierungsverwaltung abdecken. Diese umfangreiche API ermöglicht nicht nur die Integration des von Torben Haack entwickelten Next.js-Frontends, sondern bietet auch Schnittstellen für zukünftige Erweiterungen und Integrationen.
Die automatische Steuerung der 3D-Drucker über die Smart-Plugs funktioniert zuverlässig und präzise. Der implementierte Scheduler hat in ausgiebigen Tests seine Robustheit bewiesen und schaltet die Drucker pünktlich zu den reservierten Zeiten ein und aus. Die fünfminütige Sicherheitsverzögerung beim Ausschalten hat sich als sinnvolle Maßnahme erwiesen, um laufende Druckvorgänge nicht zu unterbrechen.
Besonders hervorzuheben ist die vollständige Offline-Fähigkeit des Systems. Trotz des Verzichts auf Cloud-Services und externe Abhängigkeiten bietet MYP alle Funktionen einer modernen Webanwendung. Die Progressive Web App funktioniert sowohl auf Desktop-Computern als auch auf mobilen Geräten und bietet eine responsive, benutzerfreundliche Oberfläche.
4.2 Technische und wirtschaftliche Bewertung
Aus technischer Sicht stellt das MYP-System eine gelungene Umsetzung cyber-physischer Vernetzung dar. Die Verbindung zwischen der digitalen Verwaltungsebene und der physischen Hardware-Steuerung funktioniert nahtlos und zuverlässig. Die gewählte Architektur mit Smart-Plugs als universelle Schnittstelle hat sich als robust und wartungsarm erwiesen.
Die Entscheidung für Open-Source-Technologien und den Raspberry Pi als Plattform führte zu einer äußerst kosteneffizienten Lösung. Die Gesamthardwarekosten belaufen sich auf weniger als 500 Euro, wobei die Smart-Plugs den größten Kostenfaktor darstellen. Im Vergleich zu kommerziellen Lösungen, die oft fünfstellige Beträge kosten, ist dies ein erheblicher wirtschaftlicher Vorteil.
Der Nutzen für den Ausbildungsbetrieb ist bereits nach kurzer Zeit erkennbar. Die automatisierte Verwaltung eliminiert Konflikte bei der Druckernutzung vollständig. Die präzisen Nutzungsstatistiken ermöglichen erstmals eine fundierte Analyse der Auslastung und bilden die Basis für weitere Optimierungen. Die automatische Abschaltung nicht genutzter Drucker führt zu messbaren Energieeinsparungen.
Aus Sicht der IT-Sicherheit erfüllt das System alle relevanten Anforderungen. Die Implementierung folgt aktuellen Best Practices und berücksichtigt die spezifischen Vorgaben der Mercedes-Benz AG. Die DSGVO-konforme Datenhaltung und die umfassenden Audit-Funktionen gewährleisten Compliance und Nachvollziehbarkeit.
4.3 Herausforderungen und Lösungsansätze
Während der Projektdurchführung traten verschiedene Herausforderungen auf, die kreative Lösungsansätze erforderten. Die Integration der Smart-Plugs erwies sich anfangs als schwieriger als erwartet, da die Dokumentation der PyP100-Bibliothek lückenhaft war. Durch systematisches Testen und Analyse des Netzwerkverkehrs konnte ich die notwendigen Anpassungen identifizieren und implementieren.
Ein weiteres Problem war die Gewährleistung der Systemstabilität auf dem Raspberry Pi. Erste Tests zeigten gelegentliche Verbindungsabbrüche zu den Smart-Plugs unter Last. Die Lösung bestand in der Implementierung eines Connection-Pooling-Mechanismus und der Optimierung der Threading-Strategie. Nach diesen Anpassungen läuft das System stabil und ohne Ausfälle.
Die ursprünglich geplante Integration in das Mercedes-Benz Intranet konnte aus Sicherheitsgründen nicht realisiert werden. Als Alternative entwickelte ich das lokale Flask-Frontend, welches alle notwendigen Funktionen für die Administration und Nutzung vor Ort bietet. Diese Lösung hat sich als so praktisch erwiesen, dass sie nun als primäre Benutzerschnittstelle dient.
4.4 Projekterfahrungen und persönliche Entwicklung
Das MYP-Projekt bot mir die einzigartige Gelegenheit, ein komplettes cyber-physisches System von der Konzeption bis zur Produktivsetzung zu entwickeln. Die Verbindung von Software-Entwicklung und Hardware-Integration entspricht genau dem Berufsbild des Fachinformatikers für digitale Vernetzung und hat meine Kompetenzen in diesem Bereich erheblich erweitert.
Besonders wertvoll waren die Erfahrungen im Bereich der IoT-Integration. Die Arbeit mit den Smart-Plugs und die Entwicklung robuster Kommunikationsprotokolle haben mein Verständnis für die Herausforderungen vernetzter Systeme vertieft. Die Notwendigkeit, Fehlerszenarien zu antizipieren und entsprechende Behandlungsstrategien zu implementieren, hat meine Entwicklungspraxis nachhaltig geprägt.
Die Zusammenarbeit mit verschiedenen Stakeholdern, von der Ausbildungsleitung über die IT-Abteilung bis zu den Endnutzern, verbesserte meine Kommunikations- und Projektmanagement-Fähigkeiten. Die Notwendigkeit, technische Konzepte verständlich zu erklären und Feedback konstruktiv umzusetzen, war eine wichtige Lernerfahrung.
4.5 Ausblick und Weiterentwicklung
Das MYP-System bietet eine solide Basis für zukünftige Erweiterungen. Kurzfristig ist die Integration einer Active Directory-Anbindung geplant, um die Benutzerverwaltung zu vereinfachen. Die Implementierung von Echtzeit-Benachrichtigungen über WebSockets würde die Benutzererfahrung weiter verbessern.
Mittelfristig wäre die Integration von OctoPrint oder ähnlichen 3D-Drucker-Management-Systemen denkbar. Dies würde erweiterte Funktionen wie Druckfortschritts-Überwachung und Remote-Dateiverwaltung ermöglichen. Die vorhandene API-Architektur ist bereits auf solche Erweiterungen vorbereitet.
Langfristig könnte das System zu einer umfassenden Maker-Space-Management-Lösung ausgebaut werden. Die Integration weiterer Gerätetypen wie Lasercutter oder CNC-Fräsen wäre mit minimalen Anpassungen möglich. Machine-Learning-Algorithmen könnten die Auslastung vorhersagen und Optimierungsvorschläge generieren.
4.6 Fazit
Mit dem MYP-System ist es gelungen, eine praxistaugliche Lösung für ein reales Problem im Ausbildungsbetrieb zu entwickeln. Das Projekt demonstriert eindrucksvoll, wie moderne IoT-Technologien zur Digitalisierung und Automatisierung traditioneller Prozesse eingesetzt werden können. Die vollständige Eigenentwicklung vom Backend über die Hardware-Integration bis zum Deployment unterstreicht die während der Ausbildung erworbenen Kompetenzen.
Die positive Resonanz der Nutzer und der Ausbildungsleitung bestätigt den praktischen Nutzen der Lösung. Das System läuft seit der Inbetriebnahme stabil und hat die manuelle Drucker-Verwaltung vollständig abgelöst. Die Erfahrungen aus diesem Projekt bilden eine wertvolle Grundlage für meine weitere berufliche Entwicklung als Fachinformatiker für digitale Vernetzung.
Das MYP-Projekt zeigt, dass auch mit begrenzten Ressourcen und unter Berücksichtigung strenger Sicherheitsvorgaben innovative Lösungen möglich sind. Die Kombination aus solider technischer Implementierung, durchdachter Architektur und praxisorientiertem Design macht MYP zu einem Erfolgsbeispiel für die digitale Transformation in der beruflichen Bildung.