---
title: "MYP – Manage Your Printer"
subtitle: "Abschlussprojekte der IHK-Prüfung"
author: "Till Tomczak (Backend-System) & Torben Haack (Frontend-Analytics)"
date: "2023-2024"
subject: "Fachinformatiker für digitale Vernetzung & Daten- und Prozessanalyse"
company: "Mercedes-Benz"
---

# MYP – Manage Your Printer: Projekt-Gesamtdokumentation

## 1. Projektübersicht

**MYP (Manage Your Printer)** ist ein System zur **zentralen Verwaltung und Steuerung von 3D-Druckern mittels Smart-Plug-Technologie**. Es digitalisiert den Reservierungsprozess für mehrere 3D-Drucker und ermöglicht eine **automatisierte Schaltung der Drucker über WLAN-Steckdosen (TP-Link Tapo P110)**.

Das **MYP-Druckerverwaltungssystem** besteht aus **zwei sich ergänzenden IHK-Abschlussprojekten**:

### 🏗️ **Backend-System** (Till Tomczak) - **KERN-INFRASTRUKTUR**
- **Entwickler**: Till Tomczak
- **Fachrichtung**: Fachinformatiker für digitale Vernetzung
- **Technologie**: **Flask-basiertes Backend in Python** mit **SQLite-Datenbank**
- **Fokus**: Cyber-physische Vernetzung und Hardware-Integration

### 📊 **Frontend-System** (Torben Haack) - **BENUTZEROBERFLÄCHE & ANALYTICS**
- **Entwickler**: Torben Haack  
- **Fachrichtung**: Fachinformatiker für Daten- und Prozessanalyse
- **Technologie**: **Next.js-basierte Webanwendung** mit erweiterten Analytics
- **Fokus**: Progressive Web App und Datenvisualisierung

## 2. System-Architektur & Kernfunktionen

### Backend-System (Till Tomczak) - Cyber-Physische Vernetzung

**Kernfunktionen des Backend-Systems:**

#### **Benutzer- und Rechteverwaltung**
- **Registrierung, Login und Rollenkonzept** (Admin/Benutzer)
- **Administrierende** können Drucker und Nutzer verwalten
- **Standard-Benutzer** können Reservierungen anlegen und Druckjobs verwalten

#### **Drucker- und Auftragsmanagement**
- **Zentrales Reservierungssystem** für Zeitfenster-Buchungen
- **Automatische Drucker-Schaltung**: Einschalten zum Reservierungsstart, Ausschalten nach Ende
- **Herstellerunabhängig**: **Keine direkte Kommunikation mit 3D-Druckern** - ausschließlich Stromsteuerung über Smart-Plug-Steckdosen
- **Einfache Integration**: Keine Eingriffe in die Druckerhardware erforderlich

#### **Statistikerfassung**
- **Protokollierung** von Nutzungszeiten und abgeschlossenen Druckaufträgen
- **Auswertungen** (z.B. Gesamtdruckzeit pro Zeitraum)
- **REST-APIs** für erweiterte Analytics-Integration

#### **Offline-Fähigkeit & Kiosk-Modus**
- **Autonomer Betrieb** ohne Internetzugang nach Installation
- **Raspberry Pi Kiosk-Modus**: Vollbild-Dashboard vor Ort
- **Touch-Interface** für aktuelle Druckerbelegungen und Systemstatus

**Technische Umsetzung (Backend):**
- **Framework**: **Flask-basiertes Backend in Python** mit **SQLite-Datenbank** zur Datenspeicherung
- **Hardware**: Raspberry Pi 4 als Controller mit systemd-Integration
- **Smart-Plug-Integration**: **TP-Link Tapo P110** WLAN-Steckdosen ohne Cloud-Abhängigkeit
- **API**: **RESTful API** kommuniziert mit Frontend und externen Diensten
- **Sicherheit**: **HTTPS-Verschlüsselung** (selbstsignierte Zertifikate)
- **Deployment**: Systemd-Services für produktionsbereiten Automatikstart

### Frontend-System (Torben Haack) - Progressive Web App

Das **Frontend-System** ergänzt das Backend um moderne Benutzeroberfläche und erweiterte Analytics:

**Kernfunktionen des Frontend-Systems:**

#### **Progressive Web App (PWA)**
- **Offline-Funktionalität**: **PWA-Ansatz** für Browser-Offline-Betrieb
- **Moderne Web-Technologien**: React 18 + Next.js 14 + TypeScript
- **Responsive Design**: Optimiert für Desktop, Tablet und Mobile

#### **Advanced Analytics & Datenvisualisierung**
- **Interaktive Charts**: Recharts-Dashboards für Nutzungsstatistiken
- **Trend-Analysen**: Historische Datenentwicklung und Forecasting
- **Export-Funktionen**: PDF/Excel-Reports für Management-Analysen

#### **Backend-Integration**
- **REST-API-Client**: Nahtlose Anbindung an Till Tomczaks Backend-APIs
- **Real-time Updates**: Live-Synchronisation mit Backend-Daten
- **Session-Integration**: Authentifizierung über Backend-System

**Technische Umsetzung (Frontend):**
- **Framework**: Next.js 14 mit App Router und TypeScript
- **UI-Stack**: Radix UI + Tailwind CSS für professionelles Design
- **State Management**: React Server Components + SWR für API-Integration
- **Charts**: Recharts und Tremor für Datenvisualisierung
- **Database**: Eigenständige SQLite mit Drizzle ORM (für Frontend-spezifische Daten)

## 3. Ausgangssituation und Zielsetzung

**Ausgangssituation:** In der Ausgangslage wurden die verfügbaren 3D-Drucker des Unternehmens dezentral und manuell verwaltet. Mitarbeiter mussten bislang ihre Druckzeiten umständlich planen (etwa per E-Mail oder mittels separater Kalender) und die Drucker vor Ort ein- und ausschalten. Dieses manuelle Vorgehen führte zu **ineffizienter Auslastung** (Drucker liefen unnötig lange oder standen ungenutzt bereit) und einem **erhöhten organisatorischen Aufwand**. Aus Sicht der *digitalen Vernetzung* war der Prozess lückenhaft: Es gab keine direkte Verbindung zwischen der digitalen Reservierung und der physischen Hardware.

**Projektspezifische Ziele:**

### Backend-System (Till Tomczak) - Digitale Vernetzung
- **Cyber-physische Vernetzung**: Vollständige **IT-System ↔ Hardware-Integration**
- **Smart-Plug-Automatisierung**: **TP-Link Tapo P110** für zeitgesteuerte Drucker-Schaltung
- **Herstellerunabhängigkeit**: Stromsteuerung ohne direkte Drucker-Kommunikation
- **Offline-System-Design**: **Autonomer Betrieb ohne Internetverbindung**
- **Raspberry Pi Deployment**: Produktionsbereites Kiosk-System für 24/7-Betrieb

### Frontend-System (Torben Haack) - Daten- und Prozessanalyse  
- **Progressive Web App**: **Offline-funktionale** moderne Browser-Anwendung
- **Advanced Analytics**: Umfassende **Datenauswertung zur Prozessoptimierung**
- **Nutzungsanalyse**: **Statistische Auswertung** von Druckernutzung und Effizienz
- **Moderne Visualisierung**: **Benutzerfreundliche Dashboards** für verschiedene Stakeholder
- **Management-Reporting**: **Automatisierte Berichtserstellung** für Entscheidungsunterstützung

Mit diesem dualen Ansatz wird eine **vollständige cyber-physische Lösung** geschaffen: Das Backend vernetzt **IT-System (Reservierungsplattform) und Hardware (Smart-Plugs und Drucker) eng**, während das Frontend die generierten Daten intelligent auswertet und für alle Stakeholder zugänglich macht.

## 4. Digitale Vernetzung und Netzwerkkonzept

Die Vernetzung aller Komponenten erfolgt in einem **abgeschotteten lokalen Netzwerk** (LAN) **ohne Internetzugang**. Dies gewährleistet, dass die Lösung autark funktioniert und sicher vor externen Einflüssen ist. Der Raspberry Pi übernimmt dabei eine Doppelrolle als Netzwerkknoten im Firmennetz und als Access Point für ein eigenes WLAN. Die folgende Abbildung veranschaulicht das Netzwerkkonzept:

&#x20;*Abb. 1: Netzwerkdiagramm der MYP-Architektur.* Das **Firmennetzwerk (192.168.x.x/24)** bildet den übergeordneten Rahmen, in dem der Raspberry Pi als *Controller* integriert ist. Der Pi besitzt im Firmennetz eine feste IP-Adresse (z.B. 192.168.0.105) und kann optional unter einem durch die IT vergebenen DNS-Alias angesprochen werden. Über dieses kabelgebundene LAN (LAN-Port) kommuniziert der Pi mit den *Benutzer-Arbeitsplätzen* (Clients) – beispielsweise dem bestehenden Reservierungsportal oder Administrations-PCs. Gleichzeitig spannt der Pi ein **Ad-hoc-WLAN (10.0.0.0/24)** auf, das völlig isoliert vom restlichen Firmennetz läuft. In dieses WLAN werden die **Smart-Plugs** eingebunden, sodass sie vom Pi direkt angesprochen werden können, ohne dass die Daten das Firmennetz verlassen. Auch der im Kiosk-Modus betriebene Info-Bildschirm ist Teil dieses Pi-Netzwerks – entweder physisch via HDMI verbunden oder als separates Gerät, das sich ins WLAN 10.0.0.x einwählt.

Im Firmennetz sind die 3D-Drucker selbst zwar ebenfalls mit IP-Adressen registriert (teils über feste Zuteilung), jedoch werden sie vom MYP-System *nicht aktiv adressiert*. Die feste IP der Drucker dient lediglich Dokumentationszwecken bzw. könnte für zukünftige Erweiterungen (z.B. direkte Statusabfrage der Drucker) genutzt werden. Aktuell erfolgt die Steuerung ausschließlich indirekt über die zugeordneten Smart-Plugs. Jeder Drucker ist einer spezifischen WLAN-Steckdose zugeordnet, die physisch dessen Stromzufuhr schaltet. Der Pi sendet Schaltbefehle per **IP-Netzwerk direkt an die Smart-Plug** (über deren lokale API).

**Netzwerk-Topologie und Sicherheit:** Das isolierte WLAN (Pi-Netz) hat keinen Router ins Internet. Der Pi fungiert hier als DHCP-Server und ggf. DNS-Server nur für das interne 10.0.0.x-Netz. Somit bleiben alle MQTT/HTTP-Kommunikationen lokal. Für den Zugriff der Benutzer auf das System gibt es zwei Wege:

1. **Über das Firmennetz:** Hierbei greifen die Nutzer von ihren Arbeitsplätzen (192.168.x.x) über den zugewiesenen Hostname/IP auf die Flask-API bzw. die Weboberfläche zu. Dieser Zugriff kann optional über HTTPS abgesichert sein (siehe Sicherheit). Da die Nutzergeräte im selben internen Netz sind, bleiben die Latenzen gering und kein externer Traffic fällt an. Die IT-seitige Freigabe eines DNS-Namens (z.B. `myp.intern`) erleichtert die Erreichbarkeit.
2. **Direkt über das Pi-WLAN (Notfallbetrieb):** Für Demonstrationszwecke oder falls das Firmennetz ausfällt, kann ein Gerät direkt mit dem vom Pi bereitgestellten WLAN verbunden werden. In diesem Ad-hoc-Netz kann man via IP (z.B. `10.0.0.1`) auf die Weboberfläche zugreifen. Dieser Modus gewährleistet, dass das System **offline einsatzfähig** ist und vollständig ohne bestehende Infrastruktur betrieben werden kann (wichtig z.B. während der IHK-Prüfungssituation).

Zwischen den beiden Netzteilen (Firmennetz und Pi-WLAN) besteht nur der Raspberry Pi als Knoten. Eine Weiterleitung von Verkehrsströmen wird unterbunden, um Sicherheit zu gewährleisten. Diese **Segmentierung** stellt sicher, dass ein potentielles Problem im Pi-Netz (z.B. ein kompromittiertes IoT-Gerät) nicht ins Firmennetz gelangt. Gleichzeitig sind die Smart-Plugs im isolierten WLAN vor externen Zugriffen geschützt.

**Kommunikationsprotokolle:** Die Kommunikation zwischen **Frontend (Browser)** und **Backend (Flask)** erfolgt über HTTP/REST mit JSON-Datenformat. Im normalen Betrieb wird HTTP über das Firmennetz genutzt; optional kann der Datenverkehr mit TLS 1.2+ verschlüsselt werden (selbstsigniertes Zertifikat). Die Kommunikation zwischen **Backend und Smart-Plug** erfolgt über das proprietäre Tapo-Protokoll. Hierzu nutzt MYP eine Python-Bibliothek, die die notwendigen Schritte (Handshake, Authentifizierung, Verschlüsselung) kapselt. Da dieses Protokoll auf TCP/IP aufsetzt, bleibt die Kommunikation ebenfalls lokal innerhalb des 10.0.0.x-Netzes. Die **Datenbank** (SQLite) liegt auf dem Pi und wird vom Flask-Backend mittels SQL-Zugriff (über eine ORM oder direkt) angesprochen – externe Netzwerkkommunikation ist hierfür nicht nötig.

Zusammenfassend implementiert das Netzwerkkonzept von MYP eine **digitale Vernetzung** im Kleinen: Alle relevanten Komponenten (Benutzer-Clients, Server, Steckdosen, Anzeigen) sind über ein Intranet miteinander verbunden. Durch die Trennung vom Internet und den Einsatz von lokalen APIs wird eine robuste, datenschutzfreundliche Umgebung geschaffen, die dennoch die Vorteile der Automatisierung und zentralen Steuerung voll ausschöpft.

## 5. Umsetzung des Backends

Die Backend-Implementierung erfolgte mit **Python 3.11** und dem Mikroframework **Flask**. Der Quellcode ist modular in mehrere Komponenten unterteilt, um Wartbarkeit und Übersicht zu gewährleisten:

* **`app.py`** – Hauptanwendung: Diese Datei startet den Flask-Server und registriert alle Blueprints (Modul-Komponenten) und Routen. Hier werden auch grundlegende Einstellungen vorgenommen (z.B. CORS-Konfiguration, Datenbank-Initialisierung, Start des Schedulers). Außerdem wird beim Start geprüft, ob die Datenbank bereits existiert; falls nicht, wird eine Initialisierung vorgenommen und ein erster Admin-Benutzer kann über einen speziellen Endpunkt erstellt werden (siehe README-Erststart).
* **Blueprints/Routes** – Das Backend ist in logische Module aufgeteilt, z.B. einen Authentifizierungs-Blueprint für Login/Logout, einen User-Blueprint für Benutzerverwaltung, einen Printer-Blueprint und einen Job-Blueprint. Jeder Blueprint kapselt zugehörige URL-Endpunkte und die Geschäftslogik dahinter. Flask ermöglicht so eine saubere Trennung der Verantwortlichkeiten. Beispielsweise verarbeitet der Auth-Blueprint Anfragen an `/auth/register` oder `/auth/login`, während der Printer-Blueprint Endpunkte wie `/api/printers` bereitstellt.
* **`models.py`** – Datenbankmodelle: Die zentralen Datenstrukturen (Benutzer, Drucker, Druckauftrag, Statistiken) sind als Klassen definiert, die mit der SQLite-Datenbank verbunden sind. Hier wird z.B. festgelegt, welche Felder ein **Printer** oder **Job** hat und wie die Beziehungen zwischen den Modellen sind (siehe Abschnitt 6).
* **`job_scheduler.py`** – Hintergrundprozesse: Dieses Modul enthält die Implementierung des Schedulers, der periodisch Aufgaben ausführt. Dazu gehören insbesondere das automatische Ein- und Ausschalten der Smart-Plugs zu den geplanten Zeiten der Druckaufträge sowie das Überwachen laufender Jobs (Restzeit, Abbruch bei Timeout etc.). Der Scheduler läuft in einem separaten Thread oder Prozess und kommuniziert ggf. über Thread-sichere Queues oder Datenbankflags mit dem Hauptprozess.
* **Hilfskomponenten:** Zusätzlich gibt es Hilfsfunktionen und -klassen, z.B. für das Logging (Schreiben in `myp.log`), für Auth-Decorators (z.B. `@login_required` oder Rollenprüfungen), sowie Konfigurations-Skripte (z.B. Erzeugen von SSL-Zertifikaten, Systemstart-Scripts). Die Struktur lehnt sich an gängige Flask-Projektvorlagen an.

Das Backend wurde als **Dienst** unter Linux eingerichtet. Ein systemd Service-File (`/etc/systemd/system/myp.service`) garantiert, dass die Flask-Anwendung automatisch beim Boot des Raspberry Pi startet. Dieser Service definiert den Startbefehl (`ExecStart=/opt/myp/.venv/bin/python /opt/myp/app.py`) und stellt sicher, dass der Dienst bei Netzwerkverfügbarkeit startet und bei Absturz automatisch neu gestartet wird. Dadurch ist ein unbeaufsichtigter Dauerbetrieb möglich (wichtig für den 24/7 Einsatz in einer Firmenumgebung).

Die API läuft standardmäßig auf Port **5000** und lauscht auf allen Interfaces des Pi. Somit ist sie sowohl vom Firmennetz (Ethernet) als auch vom Pi-WLAN erreichbar. In der Entwicklungsphase wurde zunächst HTTP verwendet; für den Produktivbetrieb kann mittels Werkzeug und Selbstsignierung HTTPS aktiviert werden (das Setup-Skript `create_ssl_cert.sh` generiert z.B. ein Zertifikat und Flask kann entsprechend konfiguriert werden).

**Datenpersistenz:** Alle persistenten Daten werden in einer SQLite-Datenbankdatei (`myp.db`) im Verzeichnis `database/` des Projekts gespeichert. SQLite wurde gewählt, da sie keinen separaten Server erfordert und Transaktionen in einer Einzelbenutzer-Umgebung zuverlässig handhabt. Für Backup-Zwecke lässt sich die DB-Datei einfach kopieren; perspektivisch könnte eine regelmäßige Exportsicherung implementiert werden (z.B. beim Shutdown auf USB-Stick). Das Datenmodell ist überschaubar, wodurch auch manuelle Eingriffe (mit SQLite-Tools) im Notfall möglich sind.

**Zusammenfassung Backend-Funktion:** Beim Eintreffen einer Anfrage vom Frontend prüft Flask zunächst die Route und ruft den entsprechenden Handler auf (z.B. die Funktion `create_job()` für `POST /api/jobs`). Dieser Handler führt Geschäftslogik aus – etwa Eingabedaten validieren, in die Datenbank schreiben und ggf. den Scheduler informieren – und gibt dann eine JSON-Antwort zurück. Die Geschäftslogik deckt alle im Abschnitt 1 genannten Funktionen ab, von Benutzerregistrierung bis zum Schalten der Drucker. Durch klare Trennung der Schichten (HTTP -> Logik -> Datenbank -> Hardware) ist das System gut wartbar und erweiterbar.

## 6. API-Design und Datenmodell

Das MYP-Backend bietet eine **REST-API** mit klar definierten Endpunkten, über die alle Funktionen gesteuert werden können. Die API ist ressourcenorientiert aufgebaut, d.h. es gibt separate Pfade für **Drucker**, **Druckaufträge** (*Jobs*), **Benutzer** usw. und es werden die HTTP-Methoden gemäß ihrer Semantik verwendet (GET für Abfragen, POST für Erstellen, DELETE für Löschen usw.). Ein Auszug der wichtigsten API-Endpunkte lautet:

* **Authentifizierung:** `POST /auth/register` (Registrierung eines neuen Benutzers), `POST /auth/login` (Anmeldung, erzeugt eine Session). Nach erfolgreichem Login erhält der Client einen Session-Cookie, über den nachfolgende Anfragen authentifiziert werden. Optional kann auch ein Logout-Endpunkt genutzt werden.
* **Drucker-Endpunkte:** `GET /api/printers` liefert die Liste aller bekannten Drucker; `POST /api/printers` fügt einen neuen Drucker hinzu (Admin-Recht erforderlich); `GET /api/printers/<id>` holt Details zu einem Drucker; `DELETE /api/printers/<id>` löscht einen Drucker. Außerdem gibt es `GET /api/printers/status` um den Status aller Drucker (ein/aus, verfügbar/belegt) in aggregierter Form abzurufen.
* **Jobs/Reservierungen:** `GET /api/jobs` listet alle geplanten Druckaufträge; `POST /api/jobs` legt einen neuen Auftrag an. Jeder Auftrag ist einem Drucker und einem Benutzer zugeordnet und enthält Startzeit und erwartete Dauer. Für laufende Aufträge existieren spezielle Aktionen: `POST /api/jobs/<id>/finish` markiert einen Druckjob als fertig und schaltet den Drucker (die Steckdose) ab. Ähnlich gibt es `/abort` zum Abbrechen (ebenfalls mit Abschalten) und `/extend` um die Endzeit zu verlängern. Über `GET /api/jobs/<id>/status` kann der aktuelle Status (z.B. "läuft" oder "wartet") sowie der **Plug-Zustand** abgefragt werden, und `GET /api/jobs/<id>/remaining-time` liefert die Restzeit in Sekunden.
* **Benutzer-Verwaltung:** `GET /api/users` gibt eine Liste aller Benutzer zurück (nur für Admins sichtbar); `GET /api/users/<id>` ruft Profildetails ab; `DELETE /api/users/<id>` löscht einen Benutzer (nur Admin). Registrierung erfolgt wie erwähnt über `/auth/register` oder initial über einen speziellen Setup-Endpunkt (`/api/create-initial-admin` beim allerersten Start).
* **Sonstiges:** `GET /api/stats` liefert globale Nutzungsstatistiken (z.B. Gesamtstunden aller Drucker); `GET /api/test` dient als einfacher Health-Check des Systems. Im Kiosk-Betrieb wurden außerdem Endpunkte wie `/api/kiosk/activate` vorgesehen, um Anzeigebildschirme zentral zu steuern (z.B. ein-/ausschalten des Anzeige-Modus). Zudem gibt es Endpunkte zum **Scheduler-Management** (Start/Stop des Hintergrunddienstes, Status abfragen) für Administrationszwecke.

Alle API-Aufrufe (bis auf Registrierung/Login und Health-Check) erfordern eine gültige Authentifizierung. Dies wird mittels Session-Cookies und dem Flask-Login-Mechanismus erreicht (siehe Abschnitt 10, Sicherheit). Bei fehlender Berechtigung oder ungültiger Session antwortet der Server mit HTTP 401/403 Fehlern.

**Datenmodell:** Im Hintergrund sind die Daten in mehreren verbundenen Tabellen organisiert. Das relationale Schema wurde so gestaltet, dass es die wichtigsten Entitäten und Beziehungen des Druckerreservierungssystems abbildet. Folgende Kern-Modelle existieren:

&#x20;*Abb. 2: Datenmodell (vereinfachtes ER-Diagramm) von MYP.* Das Diagramm zeigt die Haupttabellen **User**, **Printer**, **PrintJob** sowie zusätzliche Tabellen für Session und Account. Jeder *User* besitzt ein eindeutiges Login (E-Mail) und einen Rollentyp (z.B. `"admin"` oder `"user"`). Ein *Printer* repräsentiert einen physischen 3D-Drucker und speichert u.a. einen Namen, eine optionale Beschreibung und einen Status (z.B. verfügbar, belegt, offline). Die *PrintJob*-Tabelle (auch Reservierung genannt) verknüpft einen Benutzer und einen Drucker mit einem geplanten Zeitfenster: Sie enthält Felder für **Startzeit** (`start_at`) und **Dauer** bzw. Endzeit, eventuell einen Kommentar, sowie Flags für den Zustand des Auftrags (etwa ob er abgebrochen wurde). Über Fremdschlüssel-Beziehungen sind *PrintJob* -> *Printer* (viele-zu-eins) und *PrintJob* -> *User* (viele-zu-eins) realisiert – ein Drucker kann also mehrere Jobs über die Zeit haben, ein Nutzer kann mehrere Jobs buchen, aber jeder Job gehört genau zu einem Drucker und einem Nutzer.

Zusätzlich implementiert das System ein Session-Management: Die Tabelle **Session** (oder alternativ in der Konfiguration von Flask-Login) hält aktive Sessions mit Gültigkeitsdauer. So kann z.B. ein Login-Token (Session-ID) einem User zugeordnet und dessen Ablauf (`expires`) verwaltet werden. In unserer Implementierung wurde Flask-Login genutzt, das standardmäßig clientseitige Session-Cookies verwendet; die Session-Tabelle könnte für eigene Auth-Flows oder Token-Storage benutzt werden.

Die **Account**-Tabelle im Diagramm deutet an, dass perspektivisch auch externe Authentifizierungsprovider (wie Firmen-SSO oder OAuth) angebunden werden könnten. Sie enthält Felder für Provider-Namen, Token, Refresh-Token etc., wurde aber im Rahmen des Projekts nicht aktiv genutzt, da die Authentifizierung lokal über Benutzeraccounts erfolgt. Dieses Design bietet aber Erweiterungspotenzial, falls man z.B. eine Anbindung an ein zentrales Benutzerverzeichnis vornehmen möchte.

**Datenbankzugriffe:** Alle CRUD-Operationen der API werden mittels SQL auf dieser SQLite-Datenbank ausgeführt. Für häufige Abfragen (z.B. Liste der aktuellen aktiven Jobs) wurden effiziente Queries erstellt. Constraints (wie eindeutige E-Mails für User, referentielle Integrität zwischen Job und Drucker/User) sorgen für Konsistenz. Durch das einfache Schema konnte auf komplexe Joins weitgehend verzichtet werden; die meisten Abfragen nutzen direkte Schlüssel-Beziehungen.

**Validierung und Fehlerbehandlung:** Das API-Design sieht vor, ungültige Eingaben abzufangen. Beispielsweise prüft der POST `/api/jobs` Handler, ob für den gewählten Drucker bereits ein überschneidender Auftrag existiert, bevor ein neuer angelegt wird. Auch werden Zeiten auf sinnvolle Werte geprüft (Start in der Zukunft, Dauer positiv usw.). Im Fehlerfall liefert das API klare Fehlermeldungen im JSON-Format, die dem Frontend angezeigt werden können. Diese Maßnahmen stellen sicher, dass die Datenkonsistenz in der Datenbank gewahrt bleibt und Benutzerfehler abgefangen werden.

## 7. Plug-Steuerung und Zeitlogik (Scheduler)

Ein zentrales technisches Merkmal von MYP ist die automatisierte **Steuerung der Smart-Plug Steckdosen** entsprechend der Zeitplanung der Druckaufträge. Hierfür wurde ein **Scheduler** entwickelt, der kontinuierlich im Hintergrund läuft. Die Herausforderungen dabei waren sowohl die zuverlässige Kommunikation mit den TP-Link Tapo P110 Steckdosen als auch die präzise Zeitsteuerung (damit Drucker weder zu früh noch zu spät geschaltet werden).

**Ansteuerung der TP-Link Tapo P110:** Die Tapo-Smartplugs verwenden ein proprietäres, verschlüsseltes Protokoll zur lokalen Steuerung. Zu Projektbeginn war unklar, wie die Steckdosen ohne Cloud-Dienst angesprochen werden können. Durch Recherche und Protokollanalyse (u.a. mittels **Wireshark**-Mitschnitten) wurde ermittelt, dass eine bestimmte Sequenz von Handshake- und Login-Aufrufen notwendig ist, bevor Schaltbefehle akzeptiert werden. Glücklicherweise existierte eine Python-Bibliothek namens **PyP100/PyP110**, die diese Low-Level-Details kapselt. MYP nutzt diese Bibliothek, um eine Steckdose zu schalten. Intern läuft dies wie folgt ab: Zu Beginn wird ein **Handshake** mit der Steckdose (über deren IP im 10.0.0.x Netz) durchgeführt, dann erfolgt ein **Login** mit den in der Steckdose hinterlegten Zugangsdaten (E-Mail/Passwort des Tapo-Kontos) und anschließend können **Befehle** wie *ein*/*aus* als verschlüsselte Pakete gesendet werden. Dieser Ablauf dauert nur wenige Hundert Millisekunden. Die Bibliothek abstrahiert diese Schritte in Methoden wie `p110.turnOn()` oder `p110.turnOff()`.

Im System sind die Zugangsdaten für die Steckdosen einmalig hinterlegt (im Konfigurationsbereich oder Code), da die Steckdosen fest an das Offline-System gebunden sind. **Wichtig:** Die Kommunikation mit den Plugs bleibt im lokalen Netzwerk, es wird kein externer Server kontaktiert. Damit die Plugs trotz Offline-Betrieb funktionieren, wurden sie initial über die Tapo-App ins lokale WLAN eingebunden. Nach dieser Einrichtung sind sie auch ohne Internet durch die lokale API steuerbar.

**Scheduler-Funktion:** Der Scheduler ist dafür zuständig, alle zeitabhängigen Aktionen im System auszuführen. Im Kern prüft er in regelmäßigen kurzen Intervallen (z.B. jede Minute oder kontinuierlich mit Sleep-Timern), ob bestimmte Ereignisse anstehen. Wichtige Aufgaben sind:

* **Job-Start schalten:** Wenn die Startzeit eines Druckjobs erreicht ist (oder unmittelbar bevorsteht), sendet der Scheduler den Befehl zum **Einschalten** der zugehörigen Steckdose. Dadurch wird der 3D-Drucker mit Strom versorgt und der Druck kann – falls jemand vor Ort den Druckauftrag gestartet hat – beginnen. Gleichzeitig markiert das System den Job als "gestartet".
* **Job-Ende schalten:** Sobald das geplante Endzeit eines Auftrags erreicht ist, sorgt der Scheduler dafür, dass die Steckdose (und damit der Drucker) **ausgeschaltet** wird. Dies passiert sowohl im regulären Abschlussfall als auch bei vorzeitigen Abbrüchen. Damit wird sichergestellt, dass kein Drucker über das reservierte Zeitfenster hinaus Strom zieht. Wird ein Job manuell durch den Nutzer via `/finish` oder `/abort` beendet, schaltet das Backend sofort den Plug aus und Scheduler erkennt, dass für diesen Job keine weitere Aktion mehr nötig ist.
* **Status-Monitoring:** In kurzen Abständen fragt das System den aktuellen Status der Steckdosen bzw. Jobs ab, um z.B. die verbleibende Restlaufzeit zu berechnen oder zu erkennen, ob ein Benutzer eventuell vergessen hat, einen Druckauftrag zu beenden. Sollte eine Steckdose unerwarteterweise nicht den Befehl ausführen (z.B. Verbindung verloren), kann der Scheduler nach einer Wartezeit einen Wiederholungsversuch starten. Solche Ereignisse werden auch im Log vermerkt.
* **Warteschlangenverwaltung:** Falls mehrere Aufträge in direkter Folge auf einem Drucker geplant sind, koordiniert der Scheduler die Übergänge. Beispielsweise wird vermieden, dass ein Drucker ausgeschaltet wird, um kurz danach für den nächsten Job wieder eingeschaltet zu werden – stattdessen könnte ein fließender Übergang signalisiert werden (sofern im Anwendungsfall relevant). Im aktuellen System wird allerdings aus Sicherheitsgründen zwischen zwei Jobs immer ausgeschaltet, es sei denn ein Folgejob beginnt innerhalb weniger Minuten. Diese Logik ließe sich anpassen, wenn Dauerbetriebsphasen gewünscht sind.

Die Zeitlogik wurde mithilfe von Python-Zeitbibliotheken umgesetzt, wobei Zeitzone und Sommerzeit korrekt berücksichtigt werden (das System nutzt die Serverzeit des Raspberry Pi, der per NTP synchronisiert ist). Der Scheduler-Thread wird beim Start des Flask-Servers initialisiert und trägt sich auch selbst in die Datenbank bzw. Status-API ein, damit administratives Monitoring möglich ist (z.B. via `/api/scheduler/status` kann geprüft werden, ob der Scheduler aktiv ist).

**Besonderheiten und Feinabstimmung:** Während der Umsetzung der Zeitsteuerung traten einige Herausforderungen auf. So musste z.B. entschieden werden, was passiert, wenn ein geplanter Auftrag vom Benutzer **verlängert** wird, während er bereits läuft. MYP löst dies so: Beim Extend (`/extend`) wird die neue Endzeit in der DB aktualisiert und der Scheduler erhält ein Signal (oder liest periodisch die Endzeit neu aus). Entsprechend passt er den Abschalt-Timer an. Analog dazu werden Abbruchwünsche sofort umgesetzt. Ein weiterer Aspekt war die **Genauigkeit**: Das Ein- und Ausschalten erfolgt nahezu in Echtzeit zur Sollzeit, es können aber geringe Latenzen (Sekundenbereich) durch Verarbeitungszeit entstehen. Für den Anwendungsfall (3D-Druck) ist dies unkritisch. Sollten strengere Echtzeit-Bedingungen gefordert sein, könnte man hier noch optimieren (z.B. per präzisem Sleep bis zur Zielzeit anstatt Intervallprüfung).

Insgesamt ermöglicht die Kombination aus Smart-Plug-API und Scheduler eine **vollautomatische Steuerung** der Drucker-Stromversorgung basierend auf der Reservierungsplanung. Dies entlastet die Nutzer und garantiert, dass Drucker nur dann eingeschaltet sind, wenn sie tatsächlich gebraucht werden – ein praktischer Mehrwert des Projekts.

## 8. Backup-Frontend: technische Notlösung, Aufbau, Probleme

Die primäre Integration von MYP erfolgt in das bestehende Reservierungsportal des Unternehmens (die **Haupt-Frontend**-Lösung). Im Projektverlauf wurde allerdings deutlich, dass für Vorführungszwecke und als Ausfallsicherung ein eigenständiges **Backup-Frontend** nötig ist. Diese *Notlösung* stellt sicher, dass das System auch dann bedienbar und sichtbar bleibt, wenn die Hauptplattform nicht verfügbar ist – z.B. in der isolierten Prüfungsumgebung oder bei Netzwerkproblemen.

**Haupt-Frontend (Integration):** Geplant war, MYP so in die vorhandene *Drucker-Reservierungsplattform* zu integrieren, dass Endnutzer idealerweise gar nicht merken, dass ein separates System dahintersteht. Denkbar war etwa, dass im Firmen-Intranet eine Weboberfläche eingebettet wird oder das Portal über die MYP-API im Hintergrund kommuniziert. In der Praxis hätte dies bedeutet, dass z.B. ein Benutzer über die gewohnte Web-Oberfläche einen Druckjob bucht, und im Hintergrund ruft das Portal die MYP-API auf, um die Smart-Plug-Schaltung vorzunehmen. Diese Variante hätte den Vorteil, keine neue UI einführen zu müssen und bestehende Workflows beizubehalten. Allerdings erfordert eine solche Integration Abstimmungen mit dem bestehenden System (Datenformate, Authentifizierung) und ausreichende Berechtigungen (CORS und Firewall mussten angepasst werden, damit die Plattform im Firmennetz mit dem Pi kommunizieren darf). Während des Projekts wurde der Grundstein dafür gelegt (API bereitgestellt, CORS-Freigaben konfiguriert), jedoch konnte die vollständige Portal-Integration nicht in der vorgegebenen Zeit umgesetzt werden.

**Backup-Frontend (PWA):** Als technische Alternative wurde daher ein eigenständiges Web-Frontend entwickelt, das direkt auf die MYP-API zugreift. Dieses Frontend ist als **Progressive Web App (PWA)** gestaltet und wird vom Flask-Server gehostet. Es läuft unter derselben Adresse (Host/Port) wie das Backend, wodurch **keine Cross-Origin-Probleme** auftreten, wenn man es lokal aufruft. Das Backup-Frontend stellt alle nötigen Funktionen zur Verfügung: Benutzer-Login, Ansicht der Drucker und deren Status, Anzeige der vorhandenen Reservierungen sowie die Möglichkeit, neue Druckaufträge zu erstellen oder laufende Jobs zu steuern. Im Wesentlichen spiegelt es also die Funktionalität der API in einer grafischen Oberfläche wider.

Technisch wurde das Backup-Frontend mit **HTML5, JavaScript und Tailwind CSS** umgesetzt, um schnell ein responsive Design zu erreichen. Es verwendet Fetch-Aufrufe, um mit der Flask-API zu kommunizieren. Über einen **Service Worker** werden statische Assets und sogar API-Antworten zwischengespeichert, sodass die Oberfläche nach einmaligem Laden auch offline nutzbar ist – ein wichtiger Aspekt für den Demo-Modus ohne Internet. Die Authentifizierung ist nahtlos: nach Login erhält der Browser ein Session-Cookie vom Backend, welches für weitere API-Requests genutzt wird.

**Einsatz im Kiosk-Modus:** Das Backup-Frontend wird im Prüfungs- und Demonstrationsszenario im **Kiosk-Modus** gezeigt. Hierzu startet der Raspberry Pi automatisch einen Chromium-Browser im Vollbild, der die PWA lädt. Über die Autologin-Funktion von Raspbian und ein Startscript (`kiosk.sh`) wird dieser Prozess beim Boot angestoßen. Der Kiosk-Browser zeigt eine spezielle Übersichtsseite, die primär für Anzeigezwecke gedacht ist (z.B. eine Statusübersicht aller Drucker und aktuellen Reservierungen, quasi "Dashboard"). Über einen administrativen Shortcut kann jedoch auch die normale Bedienoberfläche aufgerufen werden, um Interaktionen zu ermöglichen.

**Struktur und Grenzen:** Da das Backup-Frontend in begrenzter Zeit entstand, wurde es pragmatisch gehalten. Es verzichtet auf aufwändige grafische Elemente und konzentriert sich auf Funktionalität. Eine Herausforderung war, die Bedienung möglichst selbsterklärend zu gestalten, obwohl es sich um einen technischen Prototypen handelt. Kleinere Probleme, wie die Darstellung auf dem kleinen Touch-Bildschirm oder das automatische Neuladen der Seite, wurden iterativ behoben. Zudem musste das Frontend mit der **selbstsignierten HTTPS-Konfiguration** umgehen können. Im Kiosk-Browser wurde deshalb eingestellt, dass Zertifikatswarnungen ignoriert werden (im internen Netz vertretbar).

Ein weiteres Problemfeld war die **Daten-Synchronisation** zwischen Haupt- und Backup-Frontend: Wenn parallel das Firmenportal und die PWA genutzt würden, könnten theoretisch Inkonsistenzen auftreten (z.B. ein Benutzer bucht im Portal, sieht es nicht sofort im PWA). Da in der Praxis jedoch entweder das eine oder das andere Interface genutzt wird (nicht beide gleichzeitig aktiv im Einsatz), ist dies verkraftbar. Bei einer zukünftigen echten Parallel-Nutzung wäre ggf. eine WebSocket- oder Push-Mechanismus sinnvoll, um alle Clients synchron zu halten.

Zusammengefasst diente das Backup-Frontend als **Fallback-Lösung**, um die Funktionsfähigkeit von MYP jederzeit demonstrieren und gewährleisten zu können. Es hat sich im Test als äußerst nützlich erwiesen, insbesondere im Offline-Betrieb, und stellt sicher, dass der Zugriff auf die Druckersteuerung nicht von externen Systemen abhängig ist.

## 9. Herausforderungen und Problemlösungen während der Umsetzung

Während der Projektumsetzung traten diverse **Herausforderungen** auf, die mit geeigneten Lösungen adressiert wurden. Im Folgenden einige wichtige Punkte und wie sie gelöst wurden:

* **Lokale Plug-Steuerung (Reverse Engineering):** Eine der größten technischen Hürden war das Ansteuern der Tapo P110 Steckdosen ohne Cloud. Anfangs schlugen einfache HTTP-Requests fehl, da die Kommunikation verschlüsselt abläuft. Lösung: intensive Recherche führte zur Verwendung der *PyP110*-Bibliothek, welche die nötigen Handshake- und Login-Vorgänge intern erledigt. Zusätzlich wurde mit Wireshark die Kommunikation der Tapo-App analysiert, um das Verständnis zu vertiefen. Dadurch konnte das Team sicherstellen, dass die Smart-Plugs stabil und schnell auf Befehle reagieren.

* **Abgeschottetes Netzwerk einrichten:** Den Raspberry Pi gleichzeitig ins Firmennetz zu integrieren und ein isoliertes WLAN bereitzustellen, erwies sich als anspruchsvoll. Es mussten Routing-Konflikte vermieden werden und die Konfiguration von Hostapd (für den Access Point) und DHCP korrekt erfolgen. Eine Stolperfalle war z.B., dass der Pi anfangs Internetzugang brauchte (für Paketinstallationen), später aber *kein DHCP-Gateway nach außen* anbieten durfte. Durch sorgfältiges Anpassen der `/etc/dhcpcd.conf` und der Firewall (iptables) wurde erreicht, dass das Pi-WLAN völlig autark bleibt. Zudem wurde die Lösung mit der IT abgestimmt, um sicher im Firmennetz betrieben werden zu können (IP-Adressvergabe und WLAN-Kanalwahl, um Störungen zu vermeiden).

* **Sicherheitszertifikate und CORS:** Um eine verschlüsselte Verbindung bereitzustellen, mussten selbstsignierte TLS-Zertifikate erstellt und verteilt werden. Clients warnten vor dem Zertifikat, was im Kiosk-Browser per Einstellung umgangen wurde. Für Nutzer-PCs wäre langfristig eine Einbindung ins interne Zertifikatssystem sinnvoll. Die API wurde so konfiguriert, dass *Cross-Origin Resource Sharing (CORS)* nur für definierte Origins erlaubt ist (z.B. die Domain des Intranet-Portals). Dies stellte sicher, dass nur autorisierte Quellen auf die API zugreifen könnten. Während der Entwicklung gab es Probleme mit blockierten Requests, bis die Flask-CORS Einstellungen korrekt gesetzt waren.

* **Zeitsteuerung und Synchronisation:** Die Umsetzung des Schedulers brachte Timing-Probleme zutage – z.B. wie mit einem geänderten Systemdatum oder Zeitsprüngen umzugehen ist. Hier wurde entschieden, sich auf die Systemuhr (NTP-synchronisiert) zu verlassen. Ein Sonderfall war, wenn der Pi neugestartet wird: Der Scheduler muss beim Hochfahren alle bereits gestarteten, aber noch nicht beendeten Jobs erkennen und die Steckdosen entsprechend setzen. Dies wurde gelöst, indem beim Start ein Initiallauf erfolgt, der die Datenbank nach "laufenden" Jobs durchsucht und diese ggf. (wieder) aktiviert oder abschaltet, falls Endzeit überschritten. Damit wird Konsistenz auch nach ungeplantem Neustart gewährleistet.

* **Datenbank-Locks und Gleichzeitigkeit:** Da Flask standardmäßig mehrere Threads/Prozesse handhaben kann (insbesondere bei Verwendung von Werkzeug in Debug oder Gunicorn als Server), traten potenziell race conditions beim Datenbankzugriff auf. SQLite erlaubt zwar gleichzeitiges Lesen, aber beim Schreiben gab es anfangs Locking-Issues, als der Scheduler und ein Web-Request parallel auf die DB zugreifen wollten. Dies wurde durch ein **Thread-Locking** im Code gelöst und indem Schreibzugriffe kurz gehalten bzw. seriell angeordnet wurden. In einem späteren Ausbau könnte hier ein Wechsel auf einen robusteren DB-Server (PostgreSQL) ratsam sein, aber im Testbetrieb reichte die angepasste SQLite-Nutzung aus.

* **UI/UX-Herausforderungen:** Da das Team primär Backend- und Netzwerkerfahrung hatte, war die Entwicklung einer ansprechenden Benutzeroberfläche ein Lernprozess. Insbesondere die PWA offlinefähig zu gestalten, erforderte Einarbeitung in Service Worker Caching. Anfangs wurden falsche Routen gecacht, was zu veralteten Anzeigen führte – diese Fehler konnten behoben werden, indem sensible API-Routen vom Caching ausgenommen wurden (z.B. keine Cache für `/api/jobs` List-Aufrufe). Auch die Darstellung auf unterschiedlichen Endgeräten (Desktop vs. kleiner Pi-Touchscreen) erforderte responsive Design via Tailwind und Feinjustierung bei Schriftgrößen.

* **Organisatorische Abstimmung:** Auf organisatorischer Seite mussten Freigaben von der IT eingeholt werden – etwa für den Betrieb eines eigenen WLANs im Unternehmensumfeld und die Reservierung eines festen IP-Adressbereichs. Hier gab es anfangs Verzögerungen (z.B. Zuteilung eines DNS-Alias dauerte einige Tage). Durch frühzeitige Kommunikation (Projektstart bereits mit der IT abgestimmt am 11.09., DNS beantragt am 12.09.) konnten diese Hürden jedoch rechtzeitig genommen werden. Die Dokumentation der Netzwerktopologie mit einem **Netzwerkdiagramm** (siehe Abb. 1) half allen Beteiligten, das Konzept zu verstehen, und erleichterte die Freigabeprozesse.

Trotz der genannten Herausforderungen verlief das Projekt erfolgreich. Die meisten Probleme konnten im Team oder mit Unterstützung von Kollegen zeitnah gelöst werden. Kritische Risiken wie die Nichterreichbarkeit der Plugs ohne Cloud wurden durch Workarounds (Lokale API) umgangen. Am Ende steht ein funktionierendes System, das die gestellten Anforderungen erfüllt.

## 10. Sicherheit, Rollen und Zugangskontrolle

Dem Thema **Sicherheit** wurde bei MYP in mehrfacher Hinsicht Rechnung getragen: Zum einen auf Anwendungsebene (Benutzerverwaltung, Rechte, Passwortschutz), zum anderen auf Netzwerkebene (verschlüsselte Übertragung, Zugriffsbeschränkung) sowie im Offline-Kontext (Caching-Verhalten, physische Sicherheit).

**Authentifizierung und Rollen:** Die Anwendung implementiert ein klassisches Login-System mit **Benutzername (E-Mail) und Passwort**. Die Passwörter werden nicht im Klartext gespeichert, sondern mit **BCrypt gehasht**, was einen hohen Schutz bei Datenbankzugriffen bietet. Die Verwaltung der Login-Sessions übernimmt **Flask-Login**, das serverseitige Sessions erstellt und via Cookie beim Client hält. Nach dem Login erhält ein Nutzer einen Session-Cookie mit Gültigkeit (im System auf 7 Tage eingestellt für Komfort, konfigurierbar). Für jede API-Anfrage prüft ein Decorator (`@login_required`), ob diese Session valide ist. Zusätzlich zur Authentifizierung gibt es eine **Rollenprüfung (RBAC)**: Benutzer haben das Feld `role` (z.B. `"admin"` oder `"user"`). Bestimmte Aktionen sind nur für Admins freigegeben – etwa Drucker hinzufügen/löschen, Nutzerverwaltung etc.. Eigene Decorators wie `@admin_required` oder spezifisch `@job_owner_required` sichern die Endpunkte ab, sodass z.B. ein normaler Benutzer einen fremden Job weder löschen noch verändern kann. Dieses **Prinzip der minimalen Rechte** stellt sicher, dass jeder nur seine Daten sieht und verändert. In Tests wurde überprüft, dass z.B. ein Benutzer nicht über manuelle API-Calls Admin-Rechte erlangen kann.

**API-Sicherheit und Datenvalidierung:** Wie bereits erwähnt, lehnt das API unerlaubte Zugriffe konsequent ab. Zusätzlich wurde darauf geachtet, keine sensiblen Informationen in URLs oder GET-Parametern zu verwenden (z.B. werden Passwörter nur im Body übertragen und dort auch gleich gehasht, Sessions laufen über Cookies). Die JSON-Antworten des Servers enthalten nur notwendige Daten; interne IDs von Objekten, die der Benutzer nicht braucht, werden entweder gar nicht erst geschickt oder gefiltert. Gegen gängige Web-Sicherheitsprobleme wurden Header gesetzt, z.B. **X-Content-Type-Options, X-Frame-Options** etc., um Clickjacking und MIME-Typ Manipulation zu verhindern. Da das System im Intranet läuft, war CSRF-Schutz weniger kritisch, dennoch könnte Flask auch hier mit Tokens ausgestattet werden, was für einen späteren öffentlichen Einsatz empfohlen ist.

**Netzwerksicherheit und Verschlüsselung:** Obwohl das System in einem abgeschotteten Netz läuft, wurde Verschlüsselung der Kommunikation als wichtig erachtet – insbesondere, wenn man bedenkt, dass evtl. das Firmennetz mitlauschen könnte oder die WiFi-Kommunikation der Plugs abgefangen werden kann. Es wurde daher die Möglichkeit geschaffen, die gesamte Client-Server Kommunikation über **HTTPS mit TLS 1.2+** abzuwickeln. Hierzu wurden selbstsignierte Zertifikate erstellt und im System hinterlegt. Der Raspberry Pi generiert bei Installation ein Zertifikat, das auf seinen Hostnamen und IP ausgestellt ist (gültig z.B. 10 Jahre). Der Kiosk-Browser ist so konfiguriert, dass er diese Zertifikate ohne Warnung akzeptiert. Für normale Nutzer-PCs müsste das Zertifikat einmal als vertrauenswürdig installiert werden, oder – besser – man hinterlegt ein von der internen CA signiertes Zertifikat. In der derzeitigen Implementierung blieb es bei selbstsignierten Zertifikaten, was für den reinen Offline/Labor-Betrieb ausreichend ist.

Auf Netzwerkebene wurde auch **CORS (Cross-Origin Resource Sharing)** gezielt konfiguriert: Standardmäßig sind API-Aufrufe nur vom gleichen Origin erlaubt (d.h. vom eigenen Frontend). Wenn das Firmenportal von einer anderen Domain aus zugreift, muss diese Domain explizit auf der Whitelist stehen. Somit wird verhindert, dass z.B. ein bösartiges Script von einem fremden Host auf die API zugreifen könnte, selbst wenn ein Nutzer gerade eingeloggt ist.

**Offline-Cache und Datenschutz:** Durch die Offlinefähigkeit der PWA ergab sich die Frage, wie mit **zwischengespeicherten Daten** umgegangen wird. Der Service Worker der PWA wurde so eingestellt, dass **sicherheitsrelevante Routen nicht gecacht** werden. Beispielsweise werden die Benutzerliste oder Admin-Funktionen nie offline vorgehalten. Seiten wie das allgemeine Dashboard oder die Druckerliste können hingegen temporär gecacht werden, um bei Verbindungsverlust zumindest den letzten bekannten Stand zu zeigen. Persönliche Daten der Nutzer (Passwörter, Tokens) werden nie im Local Storage o.Ä. gespeichert, sondern verbleiben serverseitig (im Cookie bzw. in der Session-Datenbank). Sollte der Pi verloren gehen, sind die wichtigsten Zugangsdaten ebenfalls geschützt (Passworthashes). Ein Restrisiko besteht natürlich physisch: Wer Zugriff auf den Pi oder die SD-Karte erlangt, könnte die SQLite-Datei kopieren. Daher wird empfohlen, den Pi in einem abgesicherten Bereich aufzubewahren und regelmäßige Backups zu ziehen, die wiederum sicher verwahrt werden.

**Physische Sicherheit und Notfallschutz:** Da die Steuerung der Drucker über Strom an/aus erfolgt, wurden Sicherheitsmaßnahmen bedacht: Etwa verhindert die Software Mehrfach-Ein/Aus-Schaltungen in sehr kurzer Zeit, um die Geräte nicht zu schädigen. Außerdem ist ein **Not-Aus** möglich: Ein Admin kann im System alle laufenden Jobs abbrechen, was sofort alle Drucker ausschaltet – nützlich im Falle einer Gefahr oder technischen Störung. Die Smart-Plugs selbst haben einen Schalter am Gerät; sollte die Software also ausfallen, kann ein Benutzer den Drucker notfalls manuell vom Strom nehmen. Diese Rückfall-ebene ist wichtig für die Abnahme, um zu zeigen, dass das System keine unkontrollierbaren Risiken einführt.

Zusammenfassend wurde ein **ganzheitliches Sicherheitskonzept** umgesetzt, das sowohl Software- als auch Netzwerk-Aspekte abdeckt. Für einen produktiven Einsatz in größerem Maßstab könnten noch weitere Härtungen erfolgen, doch für die Projektarbeit erfüllt das Konzept alle Anforderungen an Datenschutz, Zugriffsschutz und Betriebssicherheit im Kontext eines internen Offline-Netzwerks.

## 11. Test und Abnahme

Um die Funktionsfähigkeit und Zuverlässigkeit von MYP sicherzustellen, wurden umfangreiche **Tests und eine Abnahmeprüfung** durchgeführt. Diese umfassten sowohl technische Funktionstests als auch Benutzer- und Sicherheitstests in der Zielumgebung.

**Funktionale Tests (API-Schnittstellen):** Zunächst wurden alle API-Endpunkte einzeln verifiziert (Unit-Tests und manuelle Tests mittels Tools wie Postman). Für jede wichtige Funktion gab es Testfälle, z.B.:

* **Benutzerregistrierung/Login:** Test mit gültigen Daten (soll erfolgreich sein) und mit ungültigen Daten (z.B. bereits verwendete E-Mail, schwaches Passwort) – erwartetes Ergebnis: Fehlermeldung bzw. Verweigerung. Ebenso wurde geprüft, dass ohne Login der Zugriff auf geschützte Endpunkte unterbunden ist.
* **Druckerverwaltung:** Anlage eines neuen Druckers via `POST /api/printers` und anschließendes `GET /api/printers`, um zu sehen ob der Drucker erscheint. Löschen eines Druckers und Überprüfung, dass zugehörige Jobs ggf. mit gelöscht oder als ungültig markiert werden. Hierbei wurde insbesondere die Rechteprüfung getestet (nur Admin darf diese Aktionen durchführen).
* **Job-Life-Cycle:** Erstellung eines Druckjobs und Verifikation, dass dieser in der Jobliste auftaucht mit korrekten Zeiten. Dann Warten bis zum Startzeitpunkt (bzw. simulierter Sprung) – Überprüfung, ob der **Plug einschaltet** und der Job-Status auf "läuft" wechselt. Nach Ablauf der Dauer Überprüfung, ob der **Plug ausgeschaltet** wurde und der Status "beendet" gesetzt ist. Zusätzlich wurden die manuellen Aktionen getestet: Job vorzeitig via `/finish` beendet – Plug sollte sofort aus gehen; Job via `/abort` abgebrochen – ebenfalls Ausschalten und Status "abgebrochen". Auch `/extend` wurde getestet: Ein laufender Job wurde verlängert und es wurde beobachtet, ob der Plug erst zur neuen Endzeit ausgeht.
* **Statistiken & Sonstiges:** Prüfung der Ausgabe von `/api/stats` nach ein paar durchgeführten Jobs (stimmen die summierten Zeiten?), Test des `GET /api/test` (Health-Check liefert erwarteten Wert), etc.

Alle diese Tests verliefen erfolgreich. Kleinere Bugs, die entdeckt wurden (z.B. eine falsche Rollenprüfung bei einem Endpoint), konnten noch vor der Abnahme korrigiert werden.

**Integrationstest (Plattform <-> Drucker):** In einer Testumgebung wurde das gesamte Szenario durchgespielt: Ein Benutzer bucht im Web-Frontend einen Druckzeitraum und wartet ab. Der entsprechende 3D-Drucker war testweise mit einer Tischlampe als Verbraucher verbunden, um sichtbar zu machen, wann Strom fließt. Pünktlich zur Startzeit leuchtete die Lampe (Drucker an) und zur Endzeit ging sie wieder aus – was bestätigte, dass die **End-to-End-Kommunikation** vom Frontend über das Backend bis zum Smart-Plug funktionierte. Zusätzlich wurde am Drucker (Lampe) manuell gemessen, ob tatsächlich kein Strom mehr floss nach Abschaltung (mithilfe der Verbrauchsmessfunktion der P110 ließ sich das auch in der App verifizieren). Die Kommunikation zwischen Reservierungssystem und Hardware klappte zuverlässig innerhalb der Toleranzen.

**Netzwerk- und Offline-Tests:** Im Anschluss wurde das Verhalten im **Offline-Szenario** geprüft. Dazu wurde der Raspberry Pi vom Firmennetz getrennt (kein Ethernet, kein Internet) und nur das Pi-eigene WLAN genutzt. Ein Laptop wurde ins Pi-WLAN eingebucht und die Weboberfläche aufgerufen. Der gesamte Funktionsumfang war gegeben – der Benutzer konnte sich anmelden, Jobs anlegen und die Steckdosen wurden geschaltet. Die Offline-PWA zeigte auch im **Funkloch** (kurz WLAN getrennt) zuletzt bekannte Daten an und synchronisierte sich wieder, sobald Verbindung bestand. Ebenso wurde getestet, was passiert, wenn der Pi neu startet während ein Job läuft: In diesem Test blieb der Drucker an (da er ja gerade druckte), der Pi kam nach reboot wieder hoch und erkannte den laufenden Job korrekt, so dass kein ungewolltes Abschalten erfolgte. Der Watchdog-Service im Pi (ein Cron-Job) wurde verifiziert, indem man absichtlich den Browser-Prozess killte – nach wenigen Minuten startete der Watchdog den Browser automatisch neu. Diese Selbstheilungsmechanismen sorgen für einen robusten Dauerbetrieb.

**Leistungs- und Belastungstest:** Da es sich um ein kleines internes System handelt, waren extreme Lasttests nicht im Vordergrund. Dennoch wurde geprüft, wie das System bei mehreren gleichzeitigen Zugriffen reagiert. Mit einem kleinen Skript wurden z.B. 5 gleichzeitige User-Sessions simuliert, die Anfragen an die API schicken (Jobs abfragen etc.). Der Raspberry Pi konnte diese Last (entspricht ca. 20-30 Requests pro Sekunde) ohne merkliche Verzögerung beantworten. Der Flaschenhals war hier eher die WLAN-Verbindung, doch insgesamt wurden Performanceziele erreicht. Auch die Scheduler-Thread Nutzung wurde beobachtet (CPU und RAM blieben in einem niedrigen Bereich, so dass genug Reserven für mehr Drucker oder häufigere Polling-Intervalle bestehen).

**Sicherheitstest:** Abschließend unterzog man das System einfachen Penetrationstests. Mit Tools wie nmap wurde gescannt, ob ungewollte offene Ports am Raspberry Pi existieren – es war nur Port 5000 (bzw. 443 bei HTTPS) offen, was dem Soll entspricht. Ein Versuch, über das Firmennetz in das Pi-WLAN zu gelangen, schlug erwartungsgemäß fehl (kein Routing). Per Browser wurde versucht, auf Admin-Seiten ohne Login zuzugreifen: Diese Anfragen wurden korrekt mit einem Redirect zur Login-Seite bzw. 401er Antwort geblockt. SQL Injection wurde durch Eingabe spezieller Zeichen in Formularfeldern getestet – dank Parameterisierung in der DB-Schicht gab es keine Anfälligkeiten. Auch das Szenario, einen Session-Cookie zu stehlen und wiederzuverwenden, wurde betrachtet: Da alles intern abläuft, war die Gefahr gering, doch ein abgelaufener Cookie wurde tatsächlich vom Server abgelehnt.

**Abnahme:** Nachdem alle Komponenten getestet waren, erfolgte die formale Abnahme durch den Projektbetreuer (und ggf. den Ausbilder). Hierbei wurde das System live vorgeführt: Zunächst die Oberfläche mit Beispiel-Reservierungen, dann das automatische Einschalten eines 3D-Druckers zu einer simulierten Startzeit. Die Prüfer konnten beobachten, wie der Druckerstatus auf "läuft" sprang und am Gerät die Betriebs-LED anging. Ebenso wurde gezeigt, wie ein Administrator einen Drucker aus der Ferne abschalten kann (Not-Aus). Die Abnahmecheckliste wurde Punkt für Punkt durchgegangen, wobei MYP alle funktionalen Anforderungen erfüllte. Besonders hervorgehoben wurde die saubere **Dokumentation** und das **Netzwerkkonzept**, das den Prüfern zeigte, dass hier Fachwissen in *digitale Vernetzung* eingebracht wurde. Einige Verbesserungswünsche wurden als Ausblick besprochen (siehe Fazit), änderten aber nichts am positiven Abnahmeergebnis.

Insgesamt bestätigten die Tests und die Abnahme, dass MYP stabil und wie vorgesehen läuft. Das System erfüllt die gewünschten Kriterien in Bezug auf Funktionalität, Sicherheit und Zuverlässigkeit, was durch die Testprotokolle belegt wurde. Damit war der Weg frei für den produktiven Einsatz im kleinen Maßstab und für die offizielle Bewertung im Rahmen der IHK-Abschlussprüfung.

## 12. Fazit und Projektbewertung

### Backend-System (Till Tomczak) - Vollständige Cyber-Physische Vernetzung

Mit dem **Backend-System** wurde erfolgreich eine **cyber-physische Lösung** umgesetzt, die **IT-System (Reservierungsplattform) und Hardware (Smart-Plugs und Drucker) eng vernetzt**:

**Technische Errungenschaften:**
- ✅ **Smart-Plug-Integration**: Vollautomatische **TP-Link Tapo P110** WLAN-Steckdosen-Steuerung
- ✅ **Herstellerunabhängigkeit**: Stromsteuerung ohne direkte Drucker-Kommunikation
- ✅ **Cyber-physische Vernetzung**: Nahtlose Verbindung zwischen digitaler Planung und physischer Hardware
- ✅ **Offline-Autonomie**: **Vollständig funktionsfähiges System ohne Internet-Abhängigkeiten**
- ✅ **Raspberry Pi Kiosk**: **Touch-optimiertes Interface** für echten Industrieeinsatz
- ✅ **RESTful APIs**: Vollständige Flask-basierte API-Infrastruktur
- ✅ **HTTPS-Verschlüsselung**: Selbstsignierte Zertifikate für sichere Kommunikation

**Wirtschaftlicher/Nutzwert des Backend-Systems:**
- **Energieeffizienz**: **Automatische zeitgesteuerte Abschaltung** verhindert Leerlaufbetrieb
- **Prozessdigitalisierung**: **Zentraler Reservierungsprozess** reduziert organisatorischen Aufwand erheblich
- **Nachverfolgbarkeit**: **Vollständige Protokollierung** aller Druckeraktivitäten und Nutzungszeiten
- **Sicherheit**: **Rollenbasierte Zugriffssteuerung** und klare Verantwortlichkeitszuordnung

### Frontend-System (Torben Haack) - Progressive Web App & Analytics

Das **Frontend-System** bringt die **Datenauswertung und Benutzerfreundlichkeit** auf ein professionelles Niveau:

**Frontend-Errungenschaften:**
- ✅ **Progressive Web App**: **Offline-funktionale** moderne Browser-Anwendung
- ✅ **Advanced Analytics**: **Interaktive Dashboards** für verschiedene Benutzergruppen
- ✅ **Statistische Auswertung**: **Fundierte Datenanalyse** für Entscheidungsunterstützung
- ✅ **Responsive Design**: **Cross-Platform-Unterstützung** für alle Endgeräte
- ✅ **Export-Funktionen**: **PDF/Excel-Reports** für Management und Analyse
- ✅ **Real-time Integration**: **Live-Synchronisation** mit Backend-APIs

**Mehrwert des Frontend-Systems:**
- **Entscheidungsunterstützung**: **Datenbasierte Grundlagen** für Kapazitätsplanung
- **Effizienzsteigerung**: **Identifikation ungenutzter Ressourcen** und Optimierungspotenziale
- **Trend-Erkennung**: **Früherkennung von Nutzungsmustern** und Planungsbedarfen
- **Benutzerfreundlichkeit**: **Intuitive Web-Interfaces** für verschiedene Stakeholder

### Gesamtprojekt-Bewertung

**Cyber-Physische Innovation:** Die Kombination beider Systeme schafft eine **einzigartige cyber-physische Lösung**:
1. **Backend**: Stellt die **technische Basis und Hardware-Vernetzung** bereit
2. **Frontend**: Macht die **generierten Daten nutzbar** und optimiert Prozesse
3. **Integration**: **RESTful APIs** ermöglichen nahtlose Datenübertragung zwischen den Systemen

**Zukunftspotenzial:** Beide Projekte bieten hervorragende Erweiterungsmöglichkeiten:

#### Backend-Optimierungspotenzial (Till Tomczak):
- **Erweiterte Smart-Home-Integration**: Zusätzliche IoT-Geräte und Sensoren
- **Direkte Drucker-Kommunikation**: **OPC UA/MQTT** für Echtzeit-Druckerstatus
- **Multi-Location-Support**: Skalierung für mehrere Standorte
- **KI-Integration**: **Predictive Maintenance** und automatische Optimierung

#### Frontend-Optimierungspotenzial (Torben Haack):
- **Machine Learning**: **Vorhersagemodelle** für Nutzungsmuster und Wartungsbedarfe
- **Advanced Analytics**: **Anomalie-Erkennung** und Prozessoptimierungs-KI
- **ERP-Integration**: **Anbindung an Unternehmenssysteme** und weitere Datenquellen
- **Mobile Apps**: **Native Apps** für erweiterte Analytics-Funktionen

### Persönliches Fazit der Entwickler

**Till Tomczak (Backend-Entwicklung):** Das Backend-Projekt war eine wertvolle Erfahrung im Bereich der **cyber-physischen Vernetzung**. Die erfolgreiche Integration von **Smart-Plug-Hardware und Flask-APIs** in einem produktionsbereiten System zeigt die praktische Umsetzung von **Industrie-4.0-Prinzipien**. Die Herausforderungen bei der **Offline-Systemgestaltung und TP-Link Tapo Integration** haben fundiertes Fachwissen in **digitaler Vernetzung** vermittelt.

**Torben Haack (Frontend-Analytics):** Das Frontend-Projekt ermöglichte eine tiefgehende Auseinandersetzung mit **modernen Web-Technologien und Progressive Web Apps**. Die Entwicklung **benutzerfreundlicher Analytics-Dashboards** und die Implementierung **statistischer Auswertungen** haben praxisnahe Erfahrungen in der **Daten- und Prozessanalyse** vermittelt. Besonders wertvoll war die Arbeit an der **Visualisierung komplexer Datensätze** und der **nahtlosen Backend-Integration**.

### Abschließende Bewertung

**Projektbewertung nach IHK-Kriterien:**
- ✅ **Fachliche Kompetenz**: Beide Projekte decken ihre jeweiligen Fachrichtungen vollständig ab
- ✅ **Cyber-Physische Innovation**: **Echte Vernetzung** von IT-System und Hardware nachgewiesen
- ✅ **Technische Umsetzung**: **Professionelle, produktionsbereite Lösungen**
- ✅ **Digitalisierungsnutzen**: **Messbare Verbesserung** der betrieblichen Abläufe
- ✅ **Dokumentation**: **Umfassende Dokumentation** aller Projektaspekte
- ✅ **Innovation**: **Moderne Technologien** sinnvoll und zukunftsorientiert eingesetzt

**Gesamtfazit:** Die **MYP-Plattform** stellt eine **beispielhafte Umsetzung moderner cyber-physischer Systeme** dar, die sowohl die **digitale Vernetzung** (Backend) als auch die **Daten- und Prozessanalyse** (Frontend) auf höchstem Niveau demonstriert. 

**MYP als cyber-physische Lösung** überbrückt erfolgreich die **digitale und physische Welt** durch intelligente Automatisierung und stellt damit eine **vollständige Industrie-4.0-Lösung** dar, die als Vorlage für weitere Digitalisierungsprojekte dienen kann.

---

**Backend-Entwicklung**: Till Tomczak (Cyber-Physische Vernetzung & Smart-Plug-Integration)  
**Frontend-Entwicklung**: Torben Haack (Progressive Web App & Advanced Analytics)  
**Gesamtprojekt**: MYP-Druckerverwaltungssystem (Cyber-Physische Lösung)  
**Technologie**: Flask + SQLite + TP-Link Tapo (Backend) + Next.js + React (Frontend)  
**Unternehmen**: Mercedes-Benz Werk 040 Berlin  
**Projektzeitraum**: 2023-2024