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 verfügt über sechs 3D-Drucker verschiedener Hersteller (Prusa, Anycubic; B-Ware im Vergleich zu 3D-Druckern von Kostenstellen höherer Prioriät sozusagen). Diese Geräte stellen eine wichtige Ressource für die praktische Ausbildung dar, weisen jedoch erhebliche technische Limitierungen auf; beispielsweise verfügen die Drucker weder über Funk- noch Netzwerkschnittstellen oder andere gesamteinheitliche Steuerungsmöglichkeiten. Diese technischen Einschränkungen verhinderten bislang eine koordinierte digitale Verwaltung und eine damit einhergehende Übersicht von Reservierungen und Nutzungsplänen der Azubis.
Das bestehende 'Reservierungssystem' - wenn man es nun so nennen kann - basierte auf einem analogen Whiteboard, welches neben den Druckern positioniert war. Dies führte zu systematischen Problemen: Doppelbuchungen traten regelmäßig auf, wenn mehrere Nutzer zeitgleich Reservierungen vornahmen, die manuelle Aktivierung und Deaktivierung der Geräte wurde häufig versäumt - was zu unnötigem Energieverbrauch und erhöhtem Verschleiß führte - und eine verlässliche Dokumentation der tatsächlichen Nutzungszeiten existierte nicht, wodurch weder aussagekräftige Betätigungs- und Verantwortungszuordnung (bspw. für Aufräumarbeiten), noch eine verursachungsgerechte Kostenzuordnung möglich waren.
Ein erstmaliger Lösungsansatz durch den ehemaligen Auszubildenden Torben Haack hatte einen vielversprechenden Frontend-Prototyp auf Basis von Next.js hervorgebracht. Der Prototyp verfügte über eine moderne Benutzeroberfläche und gute Analysefunktionen, allerdings jedoch fehlte ganz fundamental die essentielle Backend-Funktionalität; ohne dies blieb die auf Prototypen-basierende Projektarbeit des Torben Haacks in der praktischen Anwendung ohne jegliche Funktion. Ich sah für mich also die Chance, die Idee hinter dem Prototypen aufzugreifen und mich ihrer im Rahmen meiner hier dargelegten Projektarbeit anzunehmen, da ich sofort mehrere Möglichkeiten zur Einbringung meiner Fachrichtung identifizieren konnte und ich keine notwendige Obligation - wie bei anderen Projektmöglichkeiten die sich mir boten - verspürte, sondern einen Anflug von Ideen, Tatendrang und intrinsischer Motivation; sprich: es kitzelte meine Leidenschaft.
1.2 Projektauftrag und Zielsetzung
Nach erfolgter Zulassung des Abschlussprojekts durch die IHK erhielt ich den Auftrag, den bestehenden Prototyp zu einer vollständigen cyber-physischen Lösung weiterzuentwickeln. Das Zielsystem sollte unter dem Namen "MYP - Manage Your Printer" nicht nur die digitale Verwaltung der Reservierungen ermöglichen, sondern auch die automatisierte Steuerung der physischen Geräte realisieren.
Die zentrale Herausforderung bestand in der Überbrückung der technischen Limitierungen der vorhandenen 3D-Drucker. Da eine direkte Kommunikation mit den Geräten aufgrund fehlender Schnittstellen nicht möglich war, musste ein alternativer Ansatz zur Hardware-Steuerung entwickelt werden. Gleichzeitig waren die strengen Sicherheitsrichtlinien der Mercedes-Benz AG zu berücksichtigen, die keine direkten, geschweige denn permanenten, Internetverbindungen in der Produktionsumgebung gestatten.
Ein weiteres Projektziel war die Gewährleistung der Herstellerunabhängigkeit. Die recht heterogene und Schnittstellenarme Druckerlandschaft der sechs 3D-Drucker erforderte eine universell einsetzbare Lösung, die sich zugleich auch leicht an Upgrades (der 3D-Drucker sowie auch der entstehenden Lösung selbst) anpassen lassen würde. Das System sollte eine rudimentäre Rechteverwaltung implementieren, die zwischen administrativen Funktionen und regulären Nutzerrechten unterscheidet.
1.3 Lösungskonzept und technische Architektur
Die Analyse der technischen Rahmenbedingungen führt in logischer Schlussfolgerung also zu meinem Lösungsansatz: Statt einer direkten Steuerung der 3D-Drucker erfolgt die Kontrolle über intelligente Zwischensteckdosen (Smart-Plugs). Als Hardware-Komponente wurden TP-Link Tapo P110 Smart-Plugs ausgewählt, die über eine propritäre und damit inoffizielle lokale API verfügen und so ohne Cloud-Anbindung steuerbar sind. Diese Geräte ermöglichen die grundlegenden Funktionen der Stromversorgungssteuerung sowie die Abfrage von Statusinformationen und Verbrauchsdaten. Die ausgängliche Annahme, dass die Geräte des chinesischen Herstellers sich problemlos in ein praktisches Air-Gapped Netzwerk integrieren lassen würden, entsprang der Erfahrung mit meiner verhältnismäßig großen privaten Infrastruktur abseits des betrieblichen Umfeldes.
Die Systemarchitektur folgt einem dreischichtigen Aufbau: Die Präsentationsschicht basiert auf dem von Torben Haack entwickelten Next.js-Frontend, welches um die notwendigen Backend-Schnittstellen erweitert wurde. Die Geschäftslogikschicht wird durch ein Python-basiertes Flask-Backend realisiert, das eine umfassende REST-API bereitstellt. Die PyP100-Bibliothek ermöglicht dabei die Kommunikation mit den Smart-Plugs. Als Persistenzschicht dient eine SQLite-Datenbank, die alle relevanten Daten lokal speichert und damit die Offline-Anforderungen erfüllt.
Ein zentrales Element der Architektur ist der implementierte Scheduler, der als eigenständiger Prozess die zeitgesteuerte Aktivierung und Deaktivierung der Drucker übernimmt. Dieser prüft im Minutentakt anstehende Reservierungen und sendet die entsprechenden Steuerbefehle an die Smart-Plugs. Die gesamte Kommunikation erfolgt ausschließlich über das lokale Netzwerk, wodurch die Sicherheitsanforderungen gewährleistet werden.
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 bot dabei optimale Voraussetzungen durch die vorhandene Infrastruktur und die fachliche Unterstützung der Ausbildungsleitung.
Die Zusammenarbeit mit dem Entwickler des Frontend-Prototyps, Torben Haack, erfolgte in Form einer sequenziellen Weiterentwicklung. Da Herr Haack seine Ausbildung bereits abgeschlossen hatte und ich erst nach offizieller IHK-Zulassung mit der Projektarbeit beginnen durfte, konnte ich auf seinen Vorarbeiten aufbauen und diese zu einer Gesamtlösung erweitern.
Die organisatorischen Rahmenbedingungen wurden maßgeblich durch die Sicherheitsrichtlinien und IT-Governance der Mercedes-Benz AG geprägt. Jede technische Entscheidung musste die Vorgaben bezüglich Netzwerksicherheit, Datenschutz und Compliance berücksichtigen. Die Beantragung notwendiger Administratorrechte und die Genehmigung selbstsignierter SSL-Zertifikate erforderten umfangreiche Abstimmungsprozesse mit der IT-Abteilung.
1.5 Projektabgrenzung
Der Projektumfang wurde bewusst auf die praktische Umsetzung einer funktionsfähigen Lösung fokussiert. Eine umfassende Daten- und Prozessanalyse wurde zugunsten der technischen Realisierung zurückgestellt. Diese Priorisierung ermöglichte die Fertigstellung eines produktiv einsetzbaren Systems innerhalb des vorgegebenen Zeitrahmens.
Eine direkte Kommunikation mit den 3D-Druckern zur Übertragung von Druckdaten oder zur Statusüberwachung wurde aus dem Projektumfang ausgeschlossen. Die fehlenden technischen Schnittstellen der vorhandenen Geräte hätten umfangreiche Hardware-Modifikationen erfordert, die weder zeitlich noch wirtschaftlich vertretbar gewesen wären. Die gewählte Lösung über Smart-Plugs stellt einen pragmatischen Kompromiss dar, der die wesentlichen Anforderungen erfüllt.
Ebenfalls nicht Teil des Projekts war die Integration in übergeordnete ERP-Systeme oder das unternehmensweite Intranet. Diese Anbindungen hätten zusätzliche Genehmigungsprozesse und Sicherheitsprüfungen erfordert, die den Projektrahmen überschritten hätten. Stattdessen wurde eine autarke Lösung entwickelt, die alle erforderlichen Funktionen lokal bereitstellt.
2. Projektplanung und Ressourcenmanagement
2.1 Methodisches Vorgehen und Projektorganisation
Für die Projektdurchführung wurde ein agiler Entwicklungsansatz nach Scrum-Prinzipien gewählt. Die Gesamtprojektdauer von fünf Wochen (15. April bis 20. Mai 2025) wurde in fünf einwöchige Sprints unterteilt. Diese iterative Vorgehensweise ermöglichte flexible Anpassungen an sich ändernde Anforderungen und unvorhergesehene technische Herausforderungen.
Sprint 1 (15.-19. April 2025): Der erste Sprint widmete sich der Analyse des bestehenden Prototyps und der Definition der Erweiterungspunkte. Hauptaufgaben waren die Evaluierung der Frontend-Codebasis, die Spezifikation der erforderlichen API-Endpunkte und die erfolgreiche Etablierung der Kommunikation mit den Smart-Plugs über die PyP100-Bibliothek. Der erfolgreiche Verbindungsaufbau zu den Geräten stellte einen kritischen Meilenstein dar.
Sprint 2 (22.-26. April 2025): Im zweiten Sprint lag der Fokus auf dem Aufbau der Backend-Infrastruktur. Die Beantragung und Erlangung der erforderlichen Administratorrechte erwies sich als zeitintensiver Prozess. Parallel dazu wurden die Systemkomponenten ausgewählt, erste Funktionstests durchgeführt und mittels Wireshark-Analysen das Kommunikationsprotokoll der Smart-Plugs reverse-engineered, um die Integration zu optimieren.
Sprint 3 (29. April - 3. Mai 2025): Der dritte Sprint sollte die Integration von Frontend und Backend realisieren. Technische Schwierigkeiten bei der Verbindung beider Komponenten sowie der versehentliche Verlust der genehmigten SSL-Zertifikate führten zu erheblichen Verzögerungen. Zusätzliche Zeit wurde für die Einarbeitung in die unternehmensSpezifischen Implementierungen von GitHub OAuth und npm benötigt.
Sprint 4 (6.-10. Mai 2025): Ursprünglich für Optimierungen vorgesehen, wurde dieser Sprint zur Entwicklung einer funktionsfähigen Gesamtlösung umgewidmet. Der Zeitdruck erforderte pragmatische Entscheidungen und die Konzentration auf essenzielle Funktionen. Die Implementierung erfolgte in intensiven Entwicklungssessions mit dem Ziel, ein lauffähiges System zu erstellen.
Sprint 5 (13.-17. Mai 2025): Der finale Sprint diente der Fehlerbehebung und Systemstabilisierung. Die ursprünglich geplanten Schulungen wurden zugunsten der technischen Fertigstellung zurückgestellt. Die verbleibende Zeit wurde für kritische Bugfixes und die Erstellung der Projektdokumentation genutzt.
2.2 Ressourcenplanung und Infrastruktur
Die Hardware-Ausstattung wurde basierend auf den Projektanforderungen sorgfältig ausgewählt. Als zentrale Serverplattform kam ein Raspberry Pi 5 mit 8 GB RAM zum Einsatz. Die Entscheidung gegen den ursprünglich geplanten Raspberry Pi 4 basierte auf Performance-Tests, die zeigten, dass das Next.js-Frontend höhere Rechenleistung erforderte als initial angenommen. Die Speicherausstattung wurde auf 128 GB erweitert, um ausreichend Kapazität für die Offline-Installation des Frontends, Datenbankwachstum und regelmäßige Backups zu gewährleisten.
Die sechs TP-Link Tapo P110 Smart-Plugs bildeten die zentrale Hardware-Schnittstelle zu den 3D-Druckern. Jedes Gerät erhielt eine statische IP-Adresse im Bereich 192.168.0.151 bis 192.168.0.156, was die Verwaltung und Fehlerdiagnose erheblich vereinfachte. Die Konfiguration erfolgte so, dass die Geräte ausschließlich im lokalen Netzwerk erreichbar sind und keine Verbindung zu Cloud-Diensten aufbauen.
Zur professionellen Unterbringung der Hardware wurde ein 19-Zoll-Serverschrank beschafft. Aufgrund langwieriger interner Beschaffungsprozesse wurden ergänzende Komponenten wie Lüftereinheiten und Kabelmanagement-Systeme privat finanziert. Diese Investition diente der professionellen Präsentation und optimalen Betriebsbedingungen des Systems.
Die Software-Architektur basiert vollständig auf Open-Source-Technologien: Python 3.11 als Programmiersprache, Flask 2.3 als Web-Framework, SQLAlchemy 2.0 für die Datenbankabstraktion und SQLite als Datenbanksystem. Diese Technologieauswahl gewährleistet Unabhängigkeit von proprietären Lösungen und erfüllt die Offline-Anforderungen des Projekts.
2.3 Qualitätssicherung und Testkonzept
Das Qualitätssicherungskonzept orientierte sich am V-Modell und sah für jede Entwicklungsphase korrespondierende Testaktivitäten vor. Die systematische Testdurchführung gewährleistete die Funktionsfähigkeit und Robustheit des Systems.
Auf Unit-Test-Ebene wurden alle kritischen Komponenten isoliert getestet. Dies umfasste Datenbankoperationen, API-Eingabevalidierung und die Kernfunktionen der Reservierungsverwaltung. Besondere Aufmerksamkeit galt der Smart-Plug-Kommunikation, für die umfangreiche Testszenarien entwickelt wurden, einschließlich Netzwerkausfällen und Timeout-Situationen.
Die Integrationstests validierten das Zusammenspiel der Systemkomponenten. Schwerpunkte waren die Backend-Smart-Plug-Schnittstelle und die API-Kommunikation. Systematische Tests mit verschiedenen Eingabedaten, einschließlich invalider und potenziell schädlicher Inputs, stellten die Robustheit der Schnittstellen sicher.
Systemtests bildeten komplette Anwendungsszenarien ab. Ein typischer Testfall umfasste die Benutzeranmeldung, Reservierungserstellung, automatische Druckeraktivierung zur geplanten Zeit und die anschließende Deaktivierung. Die zeitliche Präzision der Schaltungen wurde dabei besonders überwacht.
Performance-Tests auf der Zielplattform bestätigten die ausreichende Leistungsfähigkeit des Raspberry Pi 5. Selbst bei simultanen Zugriffen mehrerer Nutzer und parallelen Smart-Plug-Operationen blieb die Systemperformance im akzeptablen Bereich.
2.4 Netzwerkarchitektur und Sicherheitskonzept
Die Integration in die Netzwerkinfrastruktur der Mercedes-Benz AG erforderte detaillierte Abstimmungen 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 gewährleistet erhöhte Sicherheit und verhindert unautorisierten Zugriff auf kritische Systeme.
Der Raspberry Pi Server erhielt die statische IP-Adresse 192.168.0.105. Die Firewall-Konfiguration wurde restriktiv gestaltet: Port 5000 für die Flask-Anwendung, Port 22 für SSH-Zugriffe (ausschließlich aus dem lokalen Subnetz) und Port 5443 für HTTPS-Verbindungen. Ausgehende Verbindungen wurden strikt auf die IP-Adressen der Smart-Plugs limitiert.
Für die verschlüsselte Kommunikation wurde ein selbstsigniertes SSL-Zertifikat implementiert. Trotz der Einschränkungen selbstsignierter Zertifikate stellen diese für isolierte Netzwerke ohne Internetzugang eine adäquate Lösung dar. Das Zertifikat wurde mit einjähriger Gültigkeit ausgestellt und enthält alle relevanten Hostnamen und IP-Adressen als Subject Alternative Names. Nach dem versehentlichen Verlust der ersten Zertifikatsgeneration wurde ein robustes Backup-Konzept implementiert.
Die Authentifizierung basiert auf bcrypt-Hashing mit angemessenem Cost-Faktor. Nach fünf fehlgeschlagenen Anmeldeversuchen erfolgt eine 30-minütige Kontosperrung. Alle sicherheitsrelevanten Ereignisse werden in dedizierten Logdateien protokolliert und können für Sicherheitsaudits herangezogen werden.
3. Durchführung und technische Implementierung
3.1 Backend-Architektur und API-Design
Die Backend-Implementierung folgt einer modularen Architektur unter Verwendung des Flask-Blueprint-Systems. Diese Strukturierung ermöglicht eine klare Trennung der funktionalen Bereiche und erleichtert die Wartbarkeit des Systems. Die API wurde in vier Hauptmodule unterteilt: Authentication, User Management, Printer Management und Job Management.
Das Authentication-Modul implementiert die vollständige Benutzerverwaltung einschließlich Registrierung, Anmeldung und Session-Management. Passwörter werden mittels bcrypt gehasht und mit individuellem Salt gespeichert. Die Session-Verwaltung nutzt Flask-Login mit einer konfigurierten Ablaufzeit von acht Stunden. Zusätzliche Sicherheitsmaßnahmen umfassen CSRF-Protection und die Konfiguration sicherer Session-Cookies mit den Attributen Secure, HttpOnly und SameSite.
Das Job-Management-Modul bildet den funktionalen Kern des Systems. Der primäre Endpunkt POST /api/v1/jobs implementiert umfassende Validierungslogik, die Überschneidungen mit bestehenden Reservierungen verhindert und Berechtigungen prüft. Die Implementierung unterstützt erweiterte Funktionen wie die nachträgliche Modifikation von Reservierungen und vorzeitige Beendigung von Druckaufträgen. Diese Flexibilität erwies sich als essentiell für den praktischen Betrieb.
Das Printer-Management-Modul verwaltet die Konfiguration der 3D-Drucker und ihrer zugeordneten Smart-Plugs. Neben grundlegenden Attributen wie Name und Standort werden die Netzwerkinformationen der Smart-Plugs (IP- und MAC-Adresse) gespeichert. Ein Status-Flag ermöglicht die temporäre Deaktivierung von Druckern für Wartungszwecke.
Das API-Design orientiert sich an REST-Prinzipien und implementiert über 100 spezifische Endpunkte. Diese umfassende API-Oberfläche gewährleistet die Abdeckung aller identifizierten Use-Cases und bietet Erweiterungsmöglichkeiten für zukünftige Anforderungen.
3.2 Smart-Plug-Integration und Hardware-Steuerung
Die Integration der TP-Link Tapo P110 Smart-Plugs stellte eine zentrale technische Herausforderung dar. Die PyP100-Bibliothek bot zwar grundlegende Funktionalität, erforderte jedoch erhebliche Anpassungen für den produktiven Einsatz. Durch Analyse des Netzwerkverkehrs mittels Wireshark konnten die Kommunikationsprotokolle verstanden und optimiert werden.
Die entwickelte SmartPlugController-Klasse kapselt die Hardware-Kommunikation und implementiert robuste Fehlerbehandlung. Ein Retry-Mechanismus mit exponentiellem Backoff gewährleistet zuverlässige Kommunikation auch bei temporären Netzwerkproblemen. Nach drei erfolglosen Verbindungsversuchen wird der Fehler protokolliert und zur späteren Analyse gespeichert.
Das proprietäre Authentifizierungsprotokoll der Smart-Plugs erforderte besondere Aufmerksamkeit. Die Implementierung etabliert für jede Operation eine neue Verbindung, um Probleme mit Session-Timeouts zu vermeiden. Die Zugangsdaten werden verschlüsselt in der Systemkonfiguration gespeichert und nur bei Bedarf entschlüsselt.
Die Implementierung unterstützt drei Kernoperationen: Aktivierung, Deaktivierung und Statusabfrage. Die Statusabfrage liefert neben dem Schaltzustand zusätzliche Informationen wie Stromverbrauch, Betriebsstunden und WLAN-Signalqualität. Diese Metadaten werden für Monitoring- und Analysezwecke persistiert.
3.3 Scheduler-Implementierung und Automatisierung
Der Job-Scheduler wurde als eigenständiger Thread implementiert, der parallel zur Flask-Anwendung operiert. Diese Architekturentscheidung gewährleistet, dass Scheduler-Operationen die Responsivität der Web-API nicht beeinträchtigen.
Der Scheduler-Thread initialisiert beim Systemstart und arbeitet in einer kontinuierlichen Schleife mit 60-sekündigem Prüfintervall. Bei jeder Iteration werden anstehende Reservierungen identifiziert und entsprechende Schaltaktionen ausgeführt. Die Implementierung berücksichtigt einen fünfminütigen Sicherheitspuffer nach dem geplanten Ende einer Reservierung, um laufende Druckvorgänge nicht vorzeitig zu unterbrechen.
Die Verarbeitung von Scheduler-Events folgt einem definierten Ablauf: Statusänderung in der Datenbank, Ausführung der Hardware-Operation über den SmartPlugController, Protokollierung des Ergebnisses. Bei Fehlern werden bis zu drei Wiederholungsversuche unternommen, bevor eine Fehlerbehandlung erfolgt.
Thread-Sicherheit wurde durch explizite Datenbankisolation und Transaktionsmanagement gewährleistet. Jeder Datenbankzugriff aus dem Scheduler-Thread erhält einen eigenen Application Context, wodurch Konflikte mit concurrent Web-Requests vermieden werden.
3.4 Datenmodell und Persistierung
Das relationale Datenmodell wurde mit Fokus auf Erweiterbarkeit und Datenintegrität entworfen. Die vier Kernentitäten User, Printer, Job und verschiedene Log-Tabellen bilden die Grundlage der Datenhaltung.
Die User-Entität speichert neben Authentifizierungsdaten auch sicherheitsrelevante Metainformationen wie fehlgeschlagene Anmeldeversuche und temporäre Sperrzeitstempel. Das implementierte Rollenmodell differenziert zwischen Standard-Nutzern und Administratoren. Die Struktur ist bereits für zukünftige Erweiterungen wie Zwei-Faktor-Authentifizierung vorbereitet.
Die Printer-Entität bildet die physischen Geräte mit allen relevanten Attributen ab. Neben deskriptiven Informationen werden die kritischen Netzwerkkonfigurationen der zugeordneten Smart-Plugs gespeichert. Ein Aktivitätsflag ermöglicht die temporäre Deaktivierung ohne Konfigurationsverlust.
Die Job-Entität verwaltet den vollständigen Lebenszyklus von Reservierungen. Der Status durchläuft die Phasen "scheduled", "running", "finished" oder "aborted". Sowohl geplante als auch tatsächliche Start- und Endzeiten werden erfasst, um Abweichungsanalysen zu ermöglichen.
Spezialisierte Log-Tabellen dienen der Systemüberwachung und Analyse. PlugStatusLog protokolliert alle Hardware-Interaktionen, EnergyUsageLog erfasst Verbrauchsdaten, SystemPerformanceLog zeichnet Systemmetriken auf. Diese umfassende Datensammlung ermöglicht detaillierte Auswertungen und proaktive Wartung.
3.5 Sicherheitsimplementierung und Datenschutz
Die Sicherheitsarchitektur folgt dem Prinzip "Security by Design" und implementiert mehrschichtige Schutzmaßnahmen. Die Umsetzung berücksichtigt sowohl die spezifischen Anforderungen der Mercedes-Benz AG als auch gesetzliche Vorgaben wie die DSGVO.
Auf Netzwerkebene wurden restriktive Firewall-Regeln mittels iptables implementiert. Die Konfiguration erlaubt ausschließlich essenzielle Dienste und limitiert ausgehende Verbindungen auf die definierten Smart-Plug-Adressen. Diese Maßnahmen verhindern effektiv die Nutzung des Systems als Ausgangspunkt für Angriffe auf andere Netzwerkressourcen.
Die Anwendungsebene implementiert umfassende Eingabevalidierung für alle API-Endpunkte. Ein integriertes Intrusion Detection System erkennt typische Angriffsmuster wie SQL-Injection, Cross-Site-Scripting und Path-Traversal. Bei Erkennung verdächtiger Aktivitäten erfolgt eine temporäre IP-Sperrung.
Für DSGVO-Compliance wurden automatisierte Datenlebenszyklen implementiert. Session-Daten werden nach 30 Tagen gelöscht, Job-Daten nach zwei Jahren anonymisiert. Die Anonymisierung erhält statistische Informationen bei gleichzeitiger Entfernung personenbezogener Daten. Ein Datenexport gemäß Artikel 20 DSGVO wurde implementiert.
3.6 Deployment und Produktivbetrieb
Das Deployment auf dem Raspberry Pi 5 erfolgte mittels eines automatisierten Installationsskripts. Die Flask-Anwendung wurde als systemd-Service konfiguriert, was automatischen Start beim Systemboot und Neustart bei Fehlern gewährleistet. Die Service-Konfiguration implementiert zusätzliche Sicherheitsmaßnahmen wie Rechtebeschränkungen und Dateisystemisolation.
Für die lokale Nutzung wurde ein Kiosk-Modus eingerichtet, der die Webanwendung im Vollbildmodus präsentiert. Der Chromium-Browser startet automatisch beim Systemstart und ist für fehlertoleranten Betrieb konfiguriert. Entgegen der ursprünglichen Planung wurde auf ein Touch-Display verzichtet, die Bedienung erfolgt über konventionelle Eingabegeräte.
Die Backup-Strategie implementiert tägliche Datenbanksicherungen mit automatischer Rotation nach 30 Tagen. Wöchentliche Systembackups sichern die Gesamtkonfiguration. Alle Backup-Prozesse sind über Cron-Jobs automatisiert und werden überwacht.
4. Projektabschluss und Bewertung
4.1 Projektergebnis und Zielerreichung
Das MYP-System wurde erfolgreich innerhalb des vorgegebenen Zeitrahmens fertiggestellt und in den Produktivbetrieb überführt. Die implementierte Lösung erfüllt alle definierten Anforderungen und bietet darüber hinaus zusätzliche Funktionalitäten, die sich während der Entwicklung als sinnvoll erwiesen.
Die technische Umsetzung umfasst über 9.000 Zeilen strukturierten Python-Code mit umfassender Dokumentation. Die REST-API stellt mehr als 100 Endpunkte bereit und gewährleistet damit die vollständige Abdeckung aller identifizierten Anwendungsfälle. Der implementierte Scheduler arbeitet seit Inbetriebnahme zuverlässig und hat keine Schaltung versäumt.
Die Integration des bestehenden Frontend-Prototyps mit dem neu entwickelten Backend verlief erfolgreich. Die nahtlose Zusammenarbeit beider Komponenten demonstriert die Effektivität des gewählten Architekturansatzes. Die automatische Steuerung der 3D-Drucker über Smart-Plugs funktioniert präzise und zuverlässig. Der implementierte Sicherheitspuffer verhindert effektiv die vorzeitige Unterbrechung laufender Druckvorgänge.
Das System wird von den Nutzern gut angenommen. Die digitale Reservierungsverwaltung hat das manuelle Whiteboard-System vollständig abgelöst. Erste Rückmeldungen bestätigen die verbesserte Effizienz und Transparenz bei der Druckernutzung.
4.2 Technische und wirtschaftliche Bewertung
Aus technischer Perspektive demonstriert das MYP-System erfolgreich die Prinzipien cyber-physischer Vernetzung. Die Überbrückung zwischen digitaler Verwaltungsebene und physischer Hardware-Steuerung wurde elegant durch den Einsatz von Smart-Plugs gelöst. Diese Architekturentscheidung erwies sich als robust und wartungsarm.
Die wirtschaftliche Bewertung fällt äußerst positiv aus. Die Gesamtinvestition von unter 600 Euro (inklusive privat finanzierter Komponenten) steht in einem exzellenten Verhältnis zum erzielten Nutzen. Kommerzielle Lösungen mit vergleichbarem Funktionsumfang liegen typischerweise im fünfstelligen Bereich.
Der operative Nutzen manifestiert sich in mehreren Dimensionen: Die Eliminierung von Reservierungskonflikten, die automatisierte Energieverwaltung durch zeitgesteuerte Abschaltung und die erstmalige Verfügbarkeit belastbarer Nutzungsstatistiken. Diese Daten bilden die Grundlage für fundierte Entscheidungen bezüglich Kapazitätserweiterungen oder Ressourcenallokation.
Die Sicherheitsarchitektur erfüllt alle relevanten Anforderungen der Mercedes-Benz AG. Die implementierten Maßnahmen gewährleisten Datenschutz, Systemintegrität und Compliance mit geltenden Regularien.
4.3 Herausforderungen und Lösungsansätze
Die Projektdurchführung war von verschiedenen Herausforderungen geprägt, die flexible Lösungsansätze erforderten. Die administrativen Prozesse zur Erlangung notwendiger Berechtigungen und Genehmigungen erwiesen sich als zeitintensiver als geplant. Diese Erfahrung unterstreicht die Bedeutung ausreichender Zeitpuffer für organisatorische Aspekte in Unternehmensprojekten.
Die technische Integration der Smart-Plugs erforderte aufgrund mangelhafter Dokumentation der PyP100-Bibliothek erheblichen Reverse-Engineering-Aufwand. Die systematische Analyse des Kommunikationsprotokolls mittels Wireshark führte letztendlich zu einer stabilen Implementierung.
Der Verlust der SSL-Zertifikate in Sprint 3 verdeutlichte die Wichtigkeit robuster Backup-Strategien. Die implementierte dreifache Sicherung kritischer Konfigurationsdateien verhindert zukünftige Datenverluste.
Die Performance-Anforderungen des Next.js-Frontends führten zur Anpassung der Hardware-Spezifikation. Der Wechsel zum leistungsfähigeren Raspberry Pi 5 gewährleistete ausreichende Systemressourcen für einen flüssigen Betrieb.
4.4 Projekterfahrungen und persönliche Entwicklung
Das MYP-Projekt bot wertvolle Einblicke in die praktische Umsetzung cyber-physischer Systeme. Die Integration von Software- und Hardware-Komponenten zu einer funktionierenden Gesamtlösung entspricht dem Kernprofil des Fachinformatikers für digitale Vernetzung.
Die Arbeit mit IoT-Geräten und die Entwicklung robuster Kommunikationsprotokolle erweiterten das technische Kompetenzspektrum erheblich. Die Notwendigkeit, Ausfallszenarien zu antizipieren und entsprechende Fehlerbehandlungen zu implementieren, führte zu einem vertieften Verständnis für zuverlässige Systemarchitekturen.
Die Interaktion mit verschiedenen Stakeholdern – von der technischen Weiterentwicklung des Prototyps über Abstimmungen mit der IT-Abteilung bis zur Berücksichtigung der Nutzeranforderungen – verbesserte die kommunikativen und organisatorischen Fähigkeiten nachhaltig.
Der Projektverlauf, insbesondere die Herausforderungen der letzten Sprints, verdeutlichte die Bedeutung von Priorisierung und pragmatischen Entscheidungen. Die Fokussierung auf essenzielle Funktionen ermöglichte die erfolgreiche Fertigstellung trotz unvorhergesehener Hindernisse.
4.5 Ausblick und Weiterentwicklung
Das MYP-System bietet eine solide Basis für zukünftige Erweiterungen. Die modulare Architektur und umfassende API ermöglichen die Integration zusätzlicher Funktionalitäten ohne grundlegende Systemänderungen.
Kurzfristig ist die Anbindung an das Active Directory der Mercedes-Benz AG geplant. Die vorbereiteten Schnittstellen ermöglichen eine nahtlose Integration, sobald die erforderlichen Genehmigungen vorliegen. Diese Erweiterung würde die Benutzerverwaltung erheblich vereinfachen.
Mittelfristig könnte bei Verfügbarkeit modernerer 3D-Drucker eine direkte Geräteintegration realisiert werden. Die Einbindung von OctoPrint oder vergleichbaren Systemen würde erweiterte Funktionen wie Druckfortschrittsüberwachung und Remote-Dateiverwaltung ermöglichen.
Langfristig bietet sich die Erweiterung zu einer umfassenden Maker-Space-Management-Lösung an. Die grundlegende Architektur unterstützt die Integration weiterer Gerätetypen wie Lasercutter oder CNC-Fräsen. Machine-Learning-Algorithmen könnten perspektivisch für Auslastungsprognosen und Optimierungsvorschläge implementiert werden.
4.6 Fazit
Mit dem MYP-System wurde eine praxistaugliche Lösung für die digitale Transformation der 3D-Drucker-Verwaltung in der Technischen Berufsausbildungsstätte entwickelt. Das Projekt demonstriert erfolgreich, wie durch innovative Ansätze technische Limitierungen überwunden und moderne cyber-physische Systeme realisiert werden können.
Die Kombination aus fundierter technischer Implementierung, durchdachter Systemarchitektur und pragmatischen Lösungsansätzen resultierte in einem System, das die gestellten Anforderungen vollständig erfüllt. Die erfolgreiche Integration bestehender Komponenten mit neu entwickelten Funktionalitäten unterstreicht die während der Ausbildung erworbenen Kompetenzen.
Das positive Feedback der Nutzer und die stabile Funktionsweise im Produktivbetrieb bestätigen die Qualität der entwickelten Lösung. Das MYP-System hat sich als wertvolles Werkzeug für die effiziente Ressourcenverwaltung etabliert und trägt zur Modernisierung der Ausbildungsinfrastruktur bei.
Die Projekterfahrungen bilden eine solide Grundlage für die weitere berufliche Entwicklung als Fachinformatiker für digitale Vernetzung. Die erfolgreiche Verbindung digitaler und physischer Systeme zu einer funktionierenden Gesamtlösung demonstriert die praktische Anwendung des erworbenen Fachwissens.
Anlagen:
- Screenshots der Benutzeroberfläche und Systemarchitektur
- Relevanter E-Mail-Verkehr und Genehmigungen
- Technische Spezifikationen und Konfigurationsdateien