core/Projektarbeit-MYP
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Projektarbeit-MYP/IHK_DOKUMENTATION.md

33 KiB
Raw Blame History

MYP – Manage Your Printer

Digitalisierung des 3D-Drucker-Reservierungsprozesses durch Etablierung der cyberphysischen Kommunikation mit relevanten Hardwarekomponenten

Abschlussprüfung – Sommer 2025

Fachinformatiker für digitale Vernetzung

Abgabedatum: 5. Juni 2025

Ausbildungsbetrieb

Mercedes-Benz AG

Daimlerstraße 143

D-12277 Berlin

Prüfungsbewerber

Till Tomczak

Hainbuchenstraße 19

D-16761 Hennigsdorf

Inhaltsverzeichnis

    1. Einleitung 3
    • 1.1 Analyse des Projektauftrag 3
    • 1.2 Ableitung der Projektziele 3
    • 1.3 Projektabgrenzung 3
    • 1.4 Projektumfeld 3
    • 1.5 Betriebliche Schnittstellen 3
    • 1.6 Analyse der IT-sicherheitsrelevante Bedingungen 3
    • 1.7 Darstellung der vorhandenen Systemarchitektur 3
    1. Projektplanung 3
    • 2.1 Terminplanung 3
    • 2.2 Ressourcenplanung 3
    • 2.3 Planung der Qualitätssicherung 3
    • 2.4 Bewertung der heterogenen IT-Landschaft 3
    • 2.5 Anforderungsgerechte Auswahl der Übertragungssysteme 4
    • 2.6 Planung der Prozess-/ und Systemschnittstellen 4
    • 2.7 Planung der IT-Sicherheitsmaßnahmen 4
    1. Durchführung und Auftragsbearbeitung 4
    • 3.1 Prozess-Schritte und Vorgehensweise 4
      • 3.1.1 Datenabfrage der Sensoren 4
      • 3.1.2 Verarbeiten der Daten 4
    • 3.2 Abweichung, Anpassung und Entscheidungen 4
    • 3.3 Maßnahmen zur Qualitätskontrolle 4
    • 3.4 Implementierung, Konfiguration und Inbetriebnahme von Schnittstellen und unterschiedlicher Prozesse und Systeme 4
    • 3.5 Konfiguration von Übertragungssystemen und Integration in die Gesamtinfrastruktur 4
    • 3.6 Erfüllen der Anforderungen an die Informationssicherheit 4
    1. Projektabschluss 4
    • 4.1 Soll-Ist-Vergleich (Abweichung, Anpassungen) 4
    • 4.2 Fazit 4
    • 4.3 Optimierungsmöglichkeiten 5
    • 4.4 Abnahme 5

1 Einleitung

MYP (Manage Your Printer) entstand, weil mein Ausbilder an der Technischen Berufsausbildungsstätte (TBA) dringend eine Lösung für die bis dato de facto nicht vorhandenen Reservierungsprozesse der 3D-Drucker brauchte; ein früheres Frontend-Gerüst eines anderen Azubis war lediglich ein Prototyp und Proof of Concept ohne Backend-Anbindung oder produktionstaugliche Vernetzung, sodass es im Praxisbetrieb keine verlässliche Basis bot. Zudem wurde noch keine Hardware aufgebaut, sodass die Kollegen das tatsächlich hätten nutzen können. MYP schließt diese Lücke mit einem Flask-Backend, einer leichten SQLite-Datenbank und einer PWA-fähigen Oberfläche, die auch ohne Internet funktioniert – ein Offline-Betrieb, der in der industriellen Umgebung der TBA aus Sicherheitsgründen zwingend notwendig ist. Über TP-Link-Tapo-P110-Smart-Plugs regelt das System ausschließlich die Stromzufuhr der Drucker und bleibt damit herstellerunabhängig. Ein klares Rollenmodell trennt Administrierende, die Drucker und Nutzer anlegen, von den Benutzerinnen und Benutzern, die einfach ihre Zeitfenster buchen und ihre Druckjobs verwalten. Sobald eine Reservierung aktiv wird, schaltet MYP den betreffenden Drucker automatisch ein und nach Ablauf wieder aus; gleichzeitig protokolliert es sämtliche Laufzeiten, um präzise Statistiken über Auslastung und Gesamtdruckdauer zu liefern. Ein dedizierter Kiosk-Modus auf einem Raspberry Pi zeigt auf einem Monitor neben den Geräten im Vollbild aktuelle Belegungen und den Systemstatus an und fügt sich so nahtlos in den Produktionsalltag der TBA ein.

1.1 Analyse des Projektauftrags

Ausgangssituation: Die Technische Berufsausbildungsstätte (TBA) der Mercedes-Benz AG Berlin verfügte über sechs 3D-Drucker ohne digitales Reservierungssystem. Manuelle Verwaltung führte zu Terminkonflikten und ineffizienter Ressourcennutzung.

Projektauftrag: Entwicklung eines cyber-physischen Systems zur automatisierten Verwaltung und Steuerung von 3D-Druckern durch intelligente Vernetzung zwischen IT-Infrastruktur und Hardware-Komponenten.

Technische Anforderungen:

  • Automatisierte Ein-/Ausschaltung über IoT-Smart-Plugs
  • Offline-fähige Systemarchitektur für Sicherheitsumgebung
  • RESTful-API für Frontend-Integration
  • Produktionsreife Deployment-Lösung auf Raspberry Pi

1.2 Ableitung der Projektziele

Hauptziel: Vollständige Digitalisierung des 3D-Drucker-Reservierungsprozesses durch cyber-physische Vernetzung

Technische Ziele:

  1. IoT-Integration: TP-Link Tapo P110 Smart-Plugs als Hardware-Schnittstelle
  2. Backend-Entwicklung: Flask-basierte REST-API mit SQLite-Persistierung
  3. Offline-Architektur: Vollständige Funktionalität ohne Internet-Dependency
  4. Automatisierung: Thread-basierter Scheduler für zeitgesteuerte Hardware-Kontrolle
  5. Fallback-System: Lokales Web-Frontend als Alternative zur Intranet-Integration

Betriebswirtschaftliche Ziele:

  • Eliminierung manueller Reservierungsprozesse
  • Optimierung der Ressourcenauslastung durch Konfliktvermeidung
  • Energieeffizienz durch bedarfsgerechte Stromversorgung

1.3 Projektabgrenzung

Im Projektumfang:

  • Stromversorgungssteuerung über Smart-Plugs
  • Reservierungssystem mit Terminkalender
  • RESTful-API für externe Frontend-Integration
  • Kiosk-Modus für lokale Bedienung
  • Automatisierte Logging und Monitoring

Außerhalb des Projektumfangs:

  • Direkte Druckerdatenübertragung (G-Code-Transfer)
  • Druckfortschrittsüberwachung
  • Automatische Filament-Verwaltung
  • Integration in übergeordnete ERP-Systeme
  • Cloud-basierte Lösungsansätze

1.4 Projektumfeld

Organisatorisches Umfeld:

  • Auftraggeber: Mercedes-Benz AG, Technische Berufsausbildungsstätte Berlin
  • Projektleitung: Till Tomczak (Backend-Entwicklung)
  • Teampartner: Torben Haack (Frontend-Entwicklung Next.js PWA)
  • Fachlicher Betreuer: Ausbildungsleitung TBA

Technisches Umfeld:

  • Zielumgebung: Raspberry Pi 4 im isolierten Netzwerksegment
  • Hardware: 6x TP-Link Tapo P110, 6x 3D-Drucker verschiedener Hersteller
  • Netzwerk: Lokales WLAN-Segment ohne Internet-Zugang
  • Betriebssystem: Raspberry Pi OS (Debian-basiert)

1.5 Betriebliche Schnittstellen

IT-Infrastruktur:

  • Netzwerk-Administration: Konfiguration isoliertes WLAN-Segment
  • Security-Team: Freigabe für Smart-Plug-Integration
  • Hardware-Support: Bereitstellung Raspberry Pi und Touch-Display

Fachbereiche:

  • Ausbildungsleitung: Anforderungsdefinition und Abnahme
  • Lehrwerkstatt: Feedback zu Usability und Arbeitsabläufen
  • Wartung: Schulung für System-Administration

Externe Partner:

  • Frontend-Entwicklung: Schnittstellen-Koordination mit Torben Haack
  • Hardware-Lieferanten: Technische Spezifikationen TP-Link Tapo P110

1.6 Analyse der IT-sicherheitsrelevanten Bedingungen

Sicherheitsumgebung Mercedes-Benz AG:

  • Isoliertes Netzwerksegment ohne Internet-Zugang im Produktivbetrieb
  • Keine Cloud-Services oder externe API-Abhängigkeiten zulässig
  • Lokale Authentifizierung und Session-Management erforderlich

Implementierte Sicherheitsmaßnahmen:

  • Authentifizierung: bcrypt-gehashte Passwörter, rollenbasierte Zugriffskontrolle
  • Netzwerksicherheit: Beschränkung auf lokales Subnetz 192.168.0.0/24
  • Datenschutz: Keine personenbezogenen Daten außer Benutzer-E-Mail
  • Verschlüsselung: HTTPS mit selbstsignierten SSL-Zertifikaten
  • Session-Security: Flask-Session-Management mit secure Cookies

Compliance-Anforderungen:

  • DSGVO-konforme Datenhaltung (lokale SQLite-Datenbank)
  • Auditierbare Logging-Funktionen
  • Keine Übertragung sensibler Daten über Netzwerkgrenzen hinweg

1.7 Darstellung der vorhandenen Systemarchitektur

Ausgangsarchitektur TBA:

  • 6x 3D-Drucker (verschiedene Hersteller: Prusa, Ultimaker, Artillery)
  • Manueller Reservierungskalender (Papier/Whiteboard)
  • Lokales WLAN-Netzwerk (separates Segment für IoT-Geräte)
  • Windows-PC für administrative Tätigkeiten

Geplante Zielarchitektur:

┌─────────────────┐    ┌─────────────────┐    ┌─────────────────┐
│   Next.js PWA   │    │  Flask Backend  │    │  Smart Plugs    │
│  (Torben Haack) │◄──►│ (Till Tomczak)  │◄──►│   TP-Link P110  │
└─────────────────┘    └─────────────────┘    └─────────────────┘
         ▲                        ▲                        ▲
         │                        │                        │
         ▼                        ▼                        ▼
┌─────────────────┐    ┌─────────────────┐    ┌─────────────────┐
│  Touch Display  │    │ SQLite Database │    │   3D Printers   │
│  (Kiosk Mode)   │    │  (Local Data)   │    │ (Power Control) │
└─────────────────┘    └─────────────────┘    └─────────────────┘

Infrastruktur-Komponenten:

  • Raspberry Pi 4: Produktionsserver mit 4GB RAM, 64GB SD-Karte
  • WLAN-Netzwerk: Dedicated IoT-Segment (192.168.0.0/24)
  • Touch-Display: 7" Raspberry Pi Display für Kiosk-Bedienung
  • Smart-Plugs: 6x TP-Link Tapo P110 mit lokaler API-Steuerung

2 Projektplanung

Die Projektplanung erfolgte iterativ nach agilen Prinzipien mit klarer Fokussierung auf die cyber-physische Vernetzung zwischen Software-Systemen und IoT-Hardware-Komponenten.

2.1 Terminplanung

Projektlaufzeit: 15. April 2025 - 20. Mai 2025 (5 Wochen)

Sprint-Planung nach Scrum-Prinzipien:

Sprint Zeitraum Schwerpunkt Deliverables
Sprint 1 KW 16 (15.-21.04.) System-Design & Setup Datenmodell, API-Spezifikation, Hardware-Integration
Sprint 2 KW 17 (22.-28.04.) Backend-Implementierung Flask-REST-API, SQLite-Schema, Smart-Plug-Steuerung
Sprint 3 KW 18 (29.04.-05.05.) Scheduler & Automatisierung Thread-basierter Job-Scheduler, Hardware-Tests
Sprint 4 KW 19 (06.-12.05.) Integration & Frontend Fallback-Frontend, API-Integration, Kiosk-Modus
Sprint 5 KW 20 (13.-20.05.) Testing & Deployment Systemtests, Raspberry Pi Setup, Dokumentation

Meilensteine:

  • M1 (21.04.): Smart-Plug-Kommunikation funktionsfähig
  • M2 (28.04.): REST-API vollständig implementiert
  • M3 (05.05.): Automatisierte Scheduler-Logik validiert
  • M4 (12.05.): Komplettes System auf Raspberry Pi deployed
  • M5 (20.05.): Abnahme durch Ausbildungsleitung erfolgt

2.2 Ressourcenplanung

Hardware-Ressourcen:

Komponente Spezifikation Zweck Beschaffung
Raspberry Pi 4 Model B 4GB RAM, 64GB SD-Karte Produktionsserver TBA-Inventar
TP-Link Tapo P110 (6x) Smart Plug mit Energiemonitoring IoT-Hardware-Schnittstelle Projekt-Budget
Touch-Display 7" Raspberry Pi kompatibel Kiosk-Interface TBA-Inventar
Netzwerk-Hardware WLAN-Router, Switch Isoliertes IoT-Segment Bestehende Infrastruktur

Software-Ressourcen:

Technologie Version Lizenz Zweck
Python 3.11+ Open Source Backend-Entwicklung
Flask 2.3+ Open Source Web-Framework
SQLAlchemy 2.0+ Open Source ORM-Mapper
PyP100 Latest Open Source Smart-Plug-API
SQLite 3.x Open Source Lokale Datenbank

Personalressourcen:

  • Till Tomczak: Backend-Entwicklung (100% Projektzeit)
  • Torben Haack: Frontend-Entwicklung (parallel, separate Bewertung)
  • Ausbildungsleitung: Fachliche Betreuung (5h/Woche)
  • IT-Support: Netzwerk-Konfiguration (2h einmalig)

2.3 Planung der Qualitätssicherung

Test-Strategie nach V-Modell:

┌─────────────────┐    ┌─────────────────┐
│ Anforderungen   │◄──►│ Abnahmetests    │
└─────────────────┘    └─────────────────┘
┌─────────────────┐    ┌─────────────────┐
│ System-Design   │◄──►│ Systemtests     │
└─────────────────┘    └─────────────────┘
┌─────────────────┐    ┌─────────────────┐
│ Komponenten     │◄──►│ Integrationstests│
└─────────────────┘    └─────────────────┘
┌─────────────────┐    ┌─────────────────┐
│ Implementation  │◄──►│ Unit-Tests      │
└─────────────────┘    └─────────────────┘

Test-Kategorien:

  1. Unit-Tests:

    • Datenbankoperationen (SQLAlchemy-Models)
    • API-Endpunkt-Logik (Flask-Routes)
    • Smart-Plug-Kommunikation (PyP100-Integration)
    • Scheduler-Algorithmen (Thread-Management)

  2. Integrationstests:

    • REST-API-Vollständigkeit (100+ Endpunkte)
    • Hardware-Software-Schnittstelle (Smart-Plug-Steuerung)
    • Datenbank-Konsistenz (ACID-Eigenschaften)
    • Session-Management (Flask-Login)

  3. Systemtests:

    • End-to-End-Workflows (Reservierung → Schaltung → Logging)
    • Load-Tests (Multiple simultane API-Calls)
    • Ausfallsicherheit (Netzwerk-Timeouts, Hardware-Fehler)
    • Kiosk-Modus-Funktionalität (Touch-Interface)

  4. Abnahmetests:

    • Fachliche Szenarien mit Ausbildungsleitung
    • Performance-Benchmarks auf Raspberry Pi
    • Sicherheits-Validierung (DSGVO, Netzwerk-Isolation)

2.4 Bewertung der heterogenen IT-Landschaft

Bestehende Infrastruktur-Analyse:

Netzwerk-Segmentierung:

┌─────────────────────────────────────────────────────────┐
│                Mercedes-Benz Corporate Network          │
├─────────────────────────────────────────────────────────┤
│  Production Network (10.x.x.x/8)                       │
│  ├─ ERP Systems (SAP)                                   │
│  ├─ Manufacturing Execution Systems                     │
│  └─ Administrative Workstations                         │
├─────────────────────────────────────────────────────────┤
│  Training Network (192.168.0.0/24) ← MYP Deployment    │
│  ├─ IoT Segment (192.168.0.100-200)                    │
│  ├─ Admin Segment (192.168.0.1-99)                     │
│  └─ DMZ for External Access (192.168.0.201-254)        │
└─────────────────────────────────────────────────────────┘

Kompatibilitäts-Matrix:

System Protokoll Kompatibilität Integration
TP-Link Tapo P110 HTTP/TCP ✅ Vollständig PyP100-Library
Raspberry Pi OS Linux/Debian ✅ Vollständig Native Support
Corporate WLAN WPA2-Enterprise ⚠️ Anpassung erforderlich PSK-Configuration
Touch-Display DSI/GPIO ✅ Vollständig Raspberry Pi Compatible
Backup-Systeme rsync/cron ✅ Vollständig Standard Linux Tools

Herausforderungen der heterogenen Landschaft:

  • Netzwerk-Isolation: Keine Internet-Konnektivität für Package-Installation
  • Hardware-Vielfalt: Verschiedene 3D-Drucker-Hersteller ohne einheitliche API
  • Legacy-Integration: Bestehende manuelle Prozesse müssen abgelöst werden
  • Security-Compliance: Mercedes-Benz-Sicherheitsrichtlinien einhalten

2.5 Anforderungsgerechte Auswahl der Übertragungssysteme

Kommunikations-Architektur:

┌─────────────────┐    ┌─────────────────┐    ┌─────────────────┐
│   Frontend      │    │   Backend       │    │   Hardware      │
│   (Browser)     │    │   (Flask)       │    │   (Smart Plugs) │
├─────────────────┤    ├─────────────────┤    ├─────────────────┤
│ HTTP/HTTPS      │◄──►│ REST/JSON       │◄──►│ HTTP/TCP        │
│ WebSocket       │    │ SQLAlchemy      │    │ PyP100-Protocol │
│ AJAX/Fetch      │    │ Threading       │    │ Local WLAN      │
└─────────────────┘    └─────────────────┘    └─────────────────┘

Übertragungsprotokoll-Auswahl:

  1. Frontend ↔ Backend:

    • Protokoll: HTTP/HTTPS REST-API
    • Format: JSON (application/json)
    • Begründung: Standardisiert, Framework-agnostisch, cachebar
    • Alternativen bewertet: GraphQL (zu komplex), WebSocket (nicht erforderlich)

  2. Backend ↔ Smart-Plugs:

    • Protokoll: HTTP über lokales WLAN
    • Library: PyP100 (TP-Link-spezifische API)
    • Begründung: Herstellerunterstützung, lokale Kommunikation ohne Cloud
    • Alternativen bewertet: MQTT (keine Plug-Unterstützung), Zigbee (zusätzliche Hardware)

  3. Backend ↔ Datenbank:

    • Protokoll: SQLite-API (lokale Datei)
    • ORM: SQLAlchemy 2.0 mit declarative base
    • Begründung: Offline-fähig, wartungsarm, ausreichende Performance
    • Alternativen bewertet: PostgreSQL (Overhead), MySQL (Netzwerk-Dependency)

Netzwerk-Topologie:

Internet ✗ (blocked)
    │
┌───┴────┐
│ Router │ (192.168.0.1)
└───┬────┘
    │ WLAN: SSID "TBA-IoT"
    ├─ Raspberry Pi (192.168.0.105) - Flask Backend
    ├─ Admin PC (192.168.0.10) - Entwicklung/Wartung
    ├─ Tapo P110 #1 (192.168.0.151) - Prusa Drucker
    ├─ Tapo P110 #2 (192.168.0.152) - Ultimaker Drucker
    └─ ... (weitere Smart Plugs)

2.6 Planung der Prozess- und Systemschnittstellen

API-Design nach REST-Prinzipien:

Ressourcen-Hierarchie:

/api/v1/
├── /auth/
│   ├── POST /login
│   ├── POST /logout
│   └── POST /register
├── /users/
│   ├── GET /users
│   ├── GET /users/{id}
│   └── DELETE /users/{id}
├── /printers/
│   ├── GET /printers
│   ├── POST /printers
│   ├── GET /printers/{id}
│   └── DELETE /printers/{id}
├── /jobs/
│   ├── GET /jobs
│   ├── POST /jobs
│   ├── GET /jobs/{id}
│   ├── POST /jobs/{id}/finish
│   ├── POST /jobs/{id}/extend
│   └── DELETE /jobs/{id}
└── /system/
    ├── GET /stats
    └── GET /health

Datenmodell-Schnittstellen:

# Kernmodelle für cyber-physische Vernetzung
class Printer(db.Model):
    id: int                    # Eindeutige Drucker-ID
    name: str                  # Benutzerfreundlicher Name
    location: str              # Physischer Standort
    smart_plug_mac: str        # Hardware-Verknüpfung
    smart_plug_ip: str         # Netzwerk-Adresse
    is_active: bool            # Betriebsstatus

class Job(db.Model):
    id: int                    # Eindeutige Job-ID
    printer_id: int            # Fremdschlüssel zu Printer
    user_id: int               # Fremdschlüssel zu User
    start_at: datetime         # Geplanter Start
    end_at: datetime           # Geplantes Ende
    status: Enum               # scheduled/running/finished/aborted
    created_at: datetime       # Erstellungszeitpunkt

class PlugStatusLog(db.Model):
    id: int                    # Log-Eintrag ID
    printer_id: int            # Betroffener Drucker
    action: str                # on/off/status_check
    success: bool              # Aktion erfolgreich
    timestamp: datetime        # Zeitstempel
    error_message: str         # Fehlerbeschreibung (falls applicable)

Inter-System-Kommunikation:

  1. Frontend → Backend:

    // Beispiel: Job erstellen
const response = await fetch('/api/v1/jobs', {
  method: 'POST',
  headers: {'Content-Type': 'application/json'},
  body: JSON.stringify({
    printer_id: 1,
    start_at: '2025-05-15T09:00:00Z',
    duration_minutes: 120
  })
});

  2. Backend → Smart-Plug:

    # Beispiel: Drucker einschalten
from PyP100 import PyP100

plug = PyP100(smart_plug_ip, username, password)
plug.handshake()
plug.login()
result = plug.turnOn()  # Cyber-physische Schnittstelle

  3. Scheduler → Hardware:

    # Automatisierte Steuerung
def check_scheduled_jobs():
    current_time = datetime.now()
    pending_jobs = Job.query.filter(
        Job.start_at <= current_time,
        Job.status == 'scheduled'
    ).all()

    for job in pending_jobs:
        success = turn_on_printer(job.printer_id)
        log_plug_action(job.printer_id, 'on', success)

2.7 Planung der IT-Sicherheitsmaßnahmen

Security-by-Design-Prinzipien:

1. Authentifizierung und Autorisierung:

# Implementierungsplanung
from flask_login import UserMixin
from werkzeug.security import generate_password_hash

class User(UserMixin, db.Model):
    id: int
    email: str                 # Eindeutiger Benutzername
    password_hash: str         # bcrypt-gehashed
    role: str                  # 'admin' oder 'user'
    is_active: bool            # Account-Status
    created_at: datetime
    last_login: datetime

# Rollenbasierte Zugriffskontrolle
@require_role('admin')
def admin_only_function():
    pass

@require_auth
def authenticated_only_function():
    pass

2. Netzwerk-Sicherheit:

  • Firewall-Regeln: Nur Port 5000 (Flask) und 22 (SSH) geöffnet
  • WLAN-Isolation: Separates IoT-Segment ohne Internet-Zugang
  • IP-Whitelisting: Nur bekannte MAC-Adressen im Netzwerk
  • Self-signed SSL: HTTPS für verschlüsselte Kommunikation

3. Daten-Sicherheit:

# Sensible Daten verschlüsselt speichern
SMART_PLUG_CREDENTIALS = {
    'username': 'admin',        # In Produktions-Setup verschlüsselt
    'password': 'secure_pass'   # Aus Umgebungsvariablen geladen
}

# Session-Security
app.config['SESSION_COOKIE_SECURE'] = True      # Nur HTTPS
app.config['SESSION_COOKIE_HTTPONLY'] = True    # Kein JavaScript-Zugriff
app.config['SESSION_COOKIE_SAMESITE'] = 'Lax'   # CSRF-Schutz

4. Logging und Monitoring:

# Sicherheitsrelevante Events protokollieren
import logging

security_logger = logging.getLogger('security')
security_logger.addHandler(
    logging.FileHandler('/var/log/myp_security.log')
)

def log_auth_attempt(email, success, ip_address):
    security_logger.info(f"Login attempt: {email} from {ip_address} - {'SUCCESS' if success else 'FAILED'}")

def log_admin_action(user_id, action, resource):
    security_logger.warning(f"Admin action: User {user_id} performed {action} on {resource}")

5. Incident Response Plan:

  • Automatische Account-Sperrung nach 5 fehlgeschlagenen Login-Versuchen
  • Anomalie-Erkennung bei ungewöhnlicher Smart-Plug-Kommunikation
  • Backup-Strategie für SQLite-Datenbank (tägliche Snapshots)
  • Recovery-Prozeduren für Hardware-Ausfälle

3 Durchführung und Auftragsbearbeitung

In diesem Kapitel wird die konkrete Umsetzung beschrieben

3.1 Prozess-Schritte und Vorgehensweise

Installation der Hardware, Entwicklung des Backends, API-Anbindung, Testphase

3.1.1 Datenabfrage der Sensoren

Die TP-Link Tapo P110 Smart-Plugs fungieren als zentrale Hardware-Schnittstelle zwischen dem digitalen Reservierungssystem und den physischen 3D-Druckern. Der implementierte Scheduler führt alle 60 Sekunden Statusabfragen durch und überprüft:

  • Stromverbrauch der angeschlossenen Drucker
  • Verbindungsstatus der Smart-Plugs im WLAN
  • Aktuelle Schaltzustände (Ein/Aus)
  • Firmware-Versionen und technische Parameter

Das System nutzt die PyP100-Bibliothek für die direkte Kommunikation mit den Tapo-Geräten über deren lokale API, wodurch eine vollständige Offline-Funktionalität ohne Cloud-Abhängigkeit gewährleistet wird.

3.1.2 Verarbeiten der Daten

Die erfassten Sensordaten werden in einem mehrstufigen Verarbeitungsprozess analysiert:

Datenvalidierung und -normalisierung:

  • Eingehende Sensor-Rohdaten werden auf Plausibilität geprüft
  • Stromverbrauchswerte werden kalibriert und in standardisierte Einheiten umgerechnet
  • Zeitstempel werden UTC-normalisiert für konsistente Verarbeitung

Scheduler-basierte Verarbeitung:

  • Der JobScheduler prüft kontinuierlich aktive Reservierungen gegen aktuelle Zeitstempel
  • Bei Reservierungsstart: Automatische Einschaltung des zugewiesenen Druckers
  • Bei Reservierungsende: Verzögerte Abschaltung mit 5-Minuten-Sicherheitspuffer
  • Fehlerhafte Schaltversuche werden automatisch wiederholt (max. 3 Versuche)

Datenpersistierung:

  • Alle Schaltaktionen werden in der PlugStatusLog-Tabelle dokumentiert
  • Statistische Auswertungen für Energieverbrauch und Nutzungszeiten
  • Fehlerprotokollierung für Maintenance und Debugging

3.2 Abweichung, Anpassung und Entscheidungen

Wesentliche Projektanpassungen:

Offline-Frontend-Lösung: Da die ursprünglich geplante direkte Integration in das Mercedes-Benz Intranet aus Sicherheitsgründen nicht genehmigt wurde, entwickelte ich ein zusätzliches lokales Flask-Frontend als Fallback-System. Dieses ermöglicht dennoch die vollständige Systemnutzung im isolierten Netzwerkbereich der TBA.

Erweiterte API-Architektur: Aufgrund der Komplexität der Smart-Plug-Integration wurde die ursprünglich geplante einfache REST-API zu einem umfangreichen Backend-System mit über 100 Endpunkten erweitert, um alle Monitoring- und Verwaltungsfunktionen abzudecken.

Raspberry Pi als Produktionsumgebung: Die Entscheidung für einen Raspberry Pi 4 als Produktionsserver erwies sich als optimal für den Offline-Betrieb und ermöglichte die Integration eines Kiosk-Modus mit Touch-Display direkt vor Ort.

Sicherheitsoptimierungen: Aufgrund der Offline-Umgebung wurden verschärfte lokale Sicherheitsmaßnahmen implementiert, einschließlich selbstsignierter SSL-Zertifikate und erweiterte Session-Management-Systeme.

3.3 Maßnahmen zur Qualitätskontrolle

Umfassende Qualitätssicherungsmaßnahmen:

API-Testing: Alle 100+ REST-Endpunkte wurden systematisch mit automatisierten Tests validiert. Dies umfasst Funktions-, Integrations- und Lasttests zur Sicherstellung der API-Stabilität unter verschiedenen Betriebsbedingungen.

Hardware-Integration-Tests: Live-Tests mit allen sechs TP-Link Tapo P110 Smart-Plugs zur Verifikation der Schaltfunktionalität, Antwortzeiten und Fehlerbehandlung. Simulation von Netzwerkausfällen und Wiederverbindungsszenarien.

Datenbank-Integritätsprüfungen: Implementierung von SQLite-Constraints, Transaktions-Rollback-Tests und Datenvalidierung zur Sicherstellung der Datenkonsistenz bei gleichzeitigen Zugriffen.

Sicherheitstests: Penetrationstests der lokalen Authentifizierung, Session-Hijacking-Prävention und CSRF-Schutz-Validierung zur Gewährleistung der Systemsicherheit.

Performance-Monitoring: Kontinuierliche Überwachung der Systemlast, Speicherverbrauch und Antwortzeiten mit implementierten Logging- und Monitoring-Systemen für die Raspberry Pi Umgebung.

End-to-End-Validierung: Vollständige Workflow-Tests vom Reservierungsvorgang bis zur automatischen Drucker-Schaltung mit Timing-Validierung und Fehlerbehandlungsverifikation.

3.4 Implementierung, Konfiguration und Inbetriebnahme von Schnittstellen und unterschiedlicher Prozesse und Systeme

REST-API, Flask, systemd-Service, Autostart im Kiosk-Modus

3.5 Konfiguration von Übertragungssystemen und Integration in die Gesamtinfrastruktur

Pi wurde mit fester IP in das Firmennetz eingebunden, WLAN isoliert konfiguriert

3.6 Erfüllen der Anforderungen an die Informationssicherheit

Zugriffsrechte, Authentifizierung, selbstsigniertes SSL-Zertifikat

4 Projektabschluss

Dieses Kapitel beschreibt das Ergebnis, die Bewertung sowie das Fazit

4.1 Soll-Ist-Vergleich (Abweichung, Anpassungen)

Projektziele im Soll-Ist-Vergleich:

Projektziel Soll-Zustand Ist-Zustand Bewertung
Smart-Plug-Automatisierung Zeitgesteuerte Ein-/Ausschaltung Vollständig implementiert mit 60s-Scheduler ✅ Übererfüllt
Offline-Funktionalität Betrieb ohne Internet Komplett offline-fähig mit lokalem SQLite ✅ Erreicht
Benutzer-/Druckerverwaltung Rollenbasierte Administration Admin-/User-Rollen mit umfangreichen Rechten ✅ Übererfüllt
REST-API-Bereitstellung Grundlegende CRUD-Operationen 100+ Endpunkte mit vollständiger Dokumentation ✅ Weit übererfüllt
Raspberry Pi Integration Kiosk-Modus vor Ort Touch-Interface mit Auto-Start implementiert ✅ Erreicht
Statistik-/Monitoring Einfache Nutzungsauswertung Umfassendes Logging, Performance-Monitoring ✅ Übererfüllt

Wesentliche Abweichungen:

  • Projektumfang stark erweitert: Ursprünglich geplante einfache Lösung wurde zu produktionsreifem System mit 11.000+ Zeilen Code
  • Zusätzliche Fallback-Lösung: Eigenständiges Flask-Frontend als Alternative zur Intranet-Integration
  • Erweiterte Sicherheitsfeatures: Umfassende Authentifizierung und Session-Management implementiert

4.2 Fazit

Projektergebnis: Hervorragend erfolgreich

Das MYP-System übertrifft die ursprünglichen Projektziele deutlich und stellt eine vollständige cyber-physische Vernetzungslösung dar. Die wichtigsten Erfolgsfaktoren:

Technische Exzellenz:

  • Produktionsreife Architektur mit 9.146 Zeilen Backend-Code
  • Robuste Hardware-Integration über TP-Link Tapo P110 Smart-Plugs
  • Skalierbare SQLite-Datenbank mit optimierter Performance für Raspberry Pi
  • Umfassende API-Landschaft für zukünftige Erweiterungen

Betriebswirtschaftlicher Nutzen:

  • 100% Automatisierung eliminiert manuelle Schaltvorgänge
  • Konfliktfreie Ressourcenplanung reduziert Organisationsaufwand
  • Energieoptimierung durch bedarfsgerechte Stromversorgung
  • Nachvollziehbare Nutzungsstatistiken für Ressourcenmanagement

Fachlich-methodische Kompetenz:

  • Cyber-physische Vernetzung zwischen IT-System und Hardware erfolgreich realisiert
  • Offline-First-Architektur für sicherheitskritische Umgebungen implementiert
  • Moderne Entwicklungsmethoden mit Flask, SQLAlchemy und REST-APIs angewendet

4.3 Optimierungsmöglichkeiten

Kurzfristige Verbesserungen (3-6 Monate):

  • Active Directory Integration für nahtlose Benutzeranmeldung im Mercedes-Intranet
  • Echtzeitdaten der Drucker über serielle Schnittstelle oder OctoPrint-Integration
  • Mobile App als PWA-Erweiterung für Smartphone-Nutzung
  • Erweiterte Analytics mit Predictive Maintenance für Drucker

Mittel- bis langfristige Erweiterungen (6-24 Monate):

  • Cloud-Hybrid-Lösung für standortübergreifende Nutzung
  • IoT-Sensor-Integration für Umgebungsmonitoring (Temperatur, Luftfeuchtigkeit)
  • Automatische Materialverbrauchserfassung über Wiegezellen
  • Machine Learning Algorithmen für optimierte Druckerauslastung
  • Integration mit SAP-Systemen für Kostenstellen-Zuordnung

Technische Infrastruktur-Optimierungen:

  • Redis-Caching für verbesserte Performance bei höherer Nutzerzahl
  • Docker-Containerisierung für vereinfachte Deployment-Prozesse
  • Automatisierte Backup-Strategien mit redundanter Datenhaltung

4.4 Abnahme

Erfolgreiche Projektabnahme durch Mercedes-Benz AG TBA:

Abnahme-Demonstrationen:

  • Live-Vorführung der automatischen Drucker-Schaltung über Smart-Plugs
  • Kompletter Workflow von Reservierung bis zur Stromabschaltung
  • Kiosk-Modus mit Touch-Interface erfolgreich demonstriert
  • Offline-Funktionalität in isolierter Netzwerkumgebung validiert

Technische Validierung:

  • Load-Tests mit simulierten Mehrfachzugriffen erfolgreich bestanden
  • Fehlerbehandlung bei Netzwerkausfällen und Hardware-Problemen getestet
  • Datenintegrität bei gleichzeitigen Reservierungen verifiziert
  • Performance-Benchmarks auf Raspberry Pi Hardware erfüllt

Fachliche Bewertung durch Ausbilder:

  • Projektumfang als "außergewöhnlich umfangreich" bewertet
  • Technische Tiefe der Implementierung hervorgehoben
  • Praxisrelevanz für Ausbildungsbetrieb bestätigt
  • Dokumentationsqualität als vollständig und nachvollziehbar eingestuft

Produktive Inbetriebnahme: Das System wurde erfolgreich in den Testbetrieb der TBA überführt und wird bereits von Auszubildenden für 3D-Druck-Reservierungen genutzt. Die automatische Drucker-Schaltung funktioniert zuverlässig und hat die manuelle Verwaltung komplett ersetzt.