# MYP – Manage Your Printer
## Vernetzte 3D-Druck-Reservierungsplattform mit IoT-Anbindung und zentraler Verwaltungsoberfläche

**Dokumentation der betrieblichen Projektarbeit**

**Fachinformatiker für digitale Vernetzung**

---

**Prüfungsbewerber:** Till Tomczak  
**Ausbildungsbetrieb:** Mercedes-Benz AG  
**Prüfungstermin:** Sommer 2025  
**Bearbeitungszeitraum:** 15. April – 20. Mai 2025  
**Projektumfang:** 35 Stunden

---

## Inhaltsverzeichnis

1. [Einleitung](#1-einleitung)
   1.1 [Ausgangssituation und Problemstellung](#11-ausgangssituation-und-problemstellung)
   1.2 [Projektziele](#12-projektziele)
   1.3 [Projektabgrenzung](#13-projektabgrenzung)
   1.4 [Projektumfeld und betriebliche Schnittstellen](#14-projektumfeld-und-betriebliche-schnittstellen)
2. [Projektplanung](#2-projektplanung)
   2.1 [Zeitplanung nach V-Modell](#21-zeitplanung-nach-v-modell)
   2.2 [Ressourcenplanung](#22-ressourcenplanung)
   2.3 [Qualitätssicherungsplanung](#23-qualitätssicherungsplanung)
3. [Analyse und Bewertung](#3-analyse-und-bewertung)
   3.1 [Bewertung der vorhandenen Systemarchitektur](#31-bewertung-der-vorhandenen-systemarchitektur)
   3.2 [Bewertung der heterogenen IT-Landschaft](#32-bewertung-der-heterogenen-it-landschaft)
   3.3 [Analyse der IT-sicherheitsrelevanten Bedingungen](#33-analyse-der-it-sicherheitsrelevanten-bedingungen)
   3.4 [Anforderungsgerechte Auswahl der Übertragungssysteme](#34-anforderungsgerechte-auswahl-der-übertragungssysteme)
4. [Systemarchitektur und Schnittstellenkonzeption](#4-systemarchitektur-und-schnittstellenkonzeption)
   4.1 [Gesamtsystemarchitektur](#41-gesamtsystemarchitektur)
   4.2 [Technische Systemarchitektur](#42-technische-systemarchitektur)
   4.3 [Schnittstellenkonzeption](#43-schnittstellenkonzeption)
   4.4 [Datenmodell](#44-datenmodell)
5. [Umsetzung](#5-umsetzung)
   5.1 [Implementierung der Backend-Infrastruktur](#51-implementierung-der-backend-infrastruktur)
   5.2 [IoT-Integration und Hardware-Steuerung](#52-iot-integration-und-hardware-steuerung)
   5.3 [Sicherheitsimplementierung](#53-sicherheitsimplementierung)
   5.4 [Systemkonfiguration und Deployment](#54-systemkonfiguration-und-deployment)
6. [Test und Optimierung](#6-test-und-optimierung)
   6.1 [Testdurchführung und -ergebnisse](#61-testdurchführung-und-ergebnisse)
   6.2 [Sicherheitstests](#62-sicherheitstests)
   6.3 [Systemstabilität und Monitoring](#63-systemstabilität-und-monitoring)
7. [Projektabschluss](#7-projektabschluss)
   7.1 [Soll-Ist-Vergleich](#71-soll-ist-vergleich)
   7.2 [Projektergebnisse und Erkenntnisse](#72-projektergebnisse-und-erkenntnisse)
   7.3 [Optimierungsmöglichkeiten](#73-optimierungsmöglichkeiten)
   7.4 [Formale Projektabnahme](#74-formale-projektabnahme)
8. [Anlagen](#anlagen)
9. [Glossar](#glossar)

---

## 1. Einleitung

### 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.

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.

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.

### 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.

### 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.

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.

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.

### 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.

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.

---

## 2. Projektplanung

### 2.1 Zeitplanung nach V-Modell

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.

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.

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.

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.

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.

### 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.

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.

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.

### 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.

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.

---

## 3. Analyse und Bewertung

### 3.1 Bewertung der vorhandenen Systemarchitektur

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.

### 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.

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.

### 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 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.

### 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 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.

---

## 4. Systemarchitektur und Schnittstellenkonzeption

### 4.1 Gesamtsystemarchitektur

Die Architektur folgt einem dreischichtigen Aufbau mit klarer Trennung der Verantwortlichkeiten:

```
┌─────────────────┐    HTTPS    ┌─────────────────┐    WLAN    ┌─────────────────┐
│   Web-Client    │◄────────────►│  Raspberry Pi   │◄───────────►│   Smart-Plugs   │
│   (Browser)     │              │   MYP-Server    │             │   (IoT-Layer)   │
└─────────────────┘              └─────────────────┘             └─────────────────┘
                                         │                               │
                                    ┌────▼────┐                     ┌────▼────┐
                                    │ SQLite  │                     │3D-Drucker│
                                    │Database │                     │(6 Geräte)│
                                    └─────────┘                     └─────────┘
```

### 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.

### 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.

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.

### 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.

---

## 5. Umsetzung

### 5.1 Implementierung der Backend-Infrastruktur

Die Flask-Anwendungsstruktur folgt einer modularen Blueprint-Architektur:

```python
├── app.py                  # Hauptanwendung mit HTTPS-Konfiguration
├── models.py              # SQLAlchemy-Datenmodelle
├── blueprints/            # Funktionale Module
│   ├── auth.py           # Authentifizierung
│   ├── users.py          # Benutzerverwaltung
│   ├── printers.py       # Druckerverwaltung
│   └── jobs.py           # Reservierungslogik
└── utils/                 # Hilfsfunktionen
    ├── scheduler.py      # Zeitgesteuerte Operationen
    └── 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:

```python
class SmartPlugScheduler:
    def __init__(self):
        self.scheduler = BackgroundScheduler()
        self.lock = threading.Lock()
    
    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 Kommunikation wurde in einer Manager-Klasse gekapselt:

```python
class SmartPlugManager:
    def __init__(self, plug_configs):
        self.plugs = {id: Tapo(ip, user, pass) for id, ip in plug_configs.items()}
    
    async def control_printer(self, printer_id, action):
        plug = self.plugs[printer_id]
        return await plug.on() if action == 'start' else await plug.off()
```

### 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.

### 5.4 Systemkonfiguration und Deployment

Die Systemd-Service-Konfiguration gewährleistet automatischen Start und Überwachung:

```ini
[Unit]
Description=MYP HTTPS Backend Service
After=network.target

[Service]
Type=simple
User=myp
WorkingDirectory=/opt/myp
ExecStart=/usr/bin/python3 app.py --production
Restart=always
RestartSec=10

[Install]
WantedBy=multi-user.target
```

Das SSL-Zertifikat-Management erfolgt über selbstsignierte Zertifikate für den Offline-Betrieb. Die HTTPS-Implementierung auch im Kiosk-Modus gewährleistet verschlüsselte Passwortübertragung.

---

## 6. Test und Optimierung

### 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.

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.

### 6.3 Systemstabilität und Monitoring

Das implementierte Monitoring nutzt strukturiertes Logging mit Rotation:

```python
import logging
from logging.handlers import RotatingFileHandler

logging.basicConfig(
    handlers=[RotatingFileHandler('app.log', maxBytes=10000000, backupCount=10)],
    level=logging.INFO,
    format='%(asctime)s %(levelname)s %(name)s %(message)s'
)
```

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

### 7.1 Soll-Ist-Vergleich

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.

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.

### 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.

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.

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.

### 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.

### 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.

---

## 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

---

## 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 |

---

**Projektstatistiken:**
- **Codezeilen:** 9.000+ (Python/JavaScript)
- **API-Endpunkte:** 100+
- **Codeabdeckung:** 85%
- **Gesamtkosten:** < 200 Euro
- **Zeitverzug:** 10 Stunden vom ursprünglichen Zeitplan
- **Systemlaufzeit:** In aktiver Beobachtung seit 3. Juni 2025