# 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 Berufsausbuldung dienen. Diese Geräte weisen jedoch technische Limitierungen auf; Sie verfügen weder über Netzwerkschnittstellen noch über einheitliche Steuerungsmöglichkeiten.

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

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.

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.

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.

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.

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 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, 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 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 WLAN-Steckdosen gleichen Modells gewährleisteten realitätsnahe Testbedingungen. Die separate Produktionsumgebung auf dem Raspberry Pi diente finalen Systemtests.

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.

---

## 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 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 bestehende, gesonderte VLAN-Strukturen. Die 3D-Drucker verschiedener Hersteller erforderten eine zusammenbindende Abstraktionsebene.

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

---

## 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 die Tapo-Steckdosen sowie die Hardwareschicht mit stromgesteuerten 3D-Druckern.

### 4.3 Schnittstellenkonzeption

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; 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 Steckdosen-Zuordnung, Job für Reservierungen mit Zeitfenstern und Status, SmartPlug für IoT-Geräte-Konfiguration und Zustandsverwaltung.

---

## 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 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:
            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-106. Die lokale Authentifizierung funktioniert ohne Cloud-Service-Abhängigkeit.

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

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

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

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'
)
```

---

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

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

---

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