Projektarbeit-MYP/IHK_Projektdokumentation/Ausarbeitungsprozess/Dokumentation.md

<img src="./media/media/image2.emf"
style="width:2.25571in;height:1.125in" />Abschlussprüfung - Sommer 2025

Fachinformatiker für digitale Vernetzung

Dokumentation der betrieblichen Projektarbeit

MYP – Manage Your Printer

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

Abgabedatum: 5. Juni 2025

Ausbildungsbetrieb

Mercedes-Benz Ag

Daimlerstraße 143

D-12277 Berlin

Prüfungsbewerber

Till Tomczak  
Hainbuchenstraße 19  
D-16761 Hennigsdorf

<img src="./media/media/image3.png"
style="width:0.57522in;height:0.57522in" />

Mercedes-Benz

# Inhaltsverzeichnis

[1. Einleitung [2](#_Toc199840791)](#_Toc199840791)

[1.1 Analyse des Projektauftrages
[2](#analyse-des-projektauftrages)](#analyse-des-projektauftrages)

[1.2 Ableitung der Projektziele
[3](#ableitung-der-projektziele)](#ableitung-der-projektziele)

[1.3 Projektabgrenzung [3](#projektabgrenzung)](#projektabgrenzung)

[1.4 Projektumfeld [4](#projektumfeld)](#projektumfeld)

[1.5 Betriebliche Schnittstellen
[4](#betriebliche-schnittstellen)](#betriebliche-schnittstellen)

[1.6 Analyse der IT-sicherheitsrelevante Bedingungen
[5](#analyse-der-it-sicherheitsrelevante-bedingungen)](#analyse-der-it-sicherheitsrelevante-bedingungen)

[1.7 Darstellung der vorhandenen Systemarchitektur
[5](#darstellung-der-vorhandenen-systemarchitektur)](#darstellung-der-vorhandenen-systemarchitektur)

[2. Projektplanung [5](#projektplanung)](#projektplanung)

[2.1 Terminplanung [5](#terminplanung)](#terminplanung)

[Sprint 1 (15.-19. April 2025)
[6](#sprint-1-15.-19.-april-2025)](#sprint-1-15.-19.-april-2025)

[Sprint 2 (22.-26. April 2025)
[6](#sprint-2-22.-26.-april-2025)](#sprint-2-22.-26.-april-2025)

[Sprint 3 (29. April - 3. Mai 2025)
[6](#sprint-3-29.-april---3.-mai-2025)](#sprint-3-29.-april---3.-mai-2025)

[Sprint 4 (6.-10. Mai 2025)
[6](#sprint-4-6.-10.-mai-2025)](#sprint-4-6.-10.-mai-2025)

[Sprint 5 (13.-17. Mai 2025)
[6](#sprint-5-13.-17.-mai-2025)](#sprint-5-13.-17.-mai-2025)

[2.2 Ressourcenplanung [6](#ressourcenplanung)](#ressourcenplanung)

[2.3 Planung der Qualitätssicherung
[7](#planung-der-qualitätssicherung)](#planung-der-qualitätssicherung)

[2.4 Bewertung der heterogenen IT-Landschaft
[8](#bewertung-der-heterogenen-it-landschaft)](#bewertung-der-heterogenen-it-landschaft)

[2.5 Anforderungsgerechte Auswahl der Übertragungssysteme
[8](#anforderungsgerechte-auswahl-der-übertragungssysteme)](#anforderungsgerechte-auswahl-der-übertragungssysteme)

[2.6 Planung der Prozess-/ und Systemschnittstellen
[9](#planung-der-prozess--und-systemschnittstellen)](#planung-der-prozess--und-systemschnittstellen)

[2.7 Planung der IT-Sicherheitsmaßnahmen
[9](#planung-der-it-sicherheitsmaßnahmen)](#planung-der-it-sicherheitsmaßnahmen)

[3. Durchführung und Auftragsbearbeitung
[9](#durchführung-und-auftragsbearbeitung)](#durchführung-und-auftragsbearbeitung)

[3.1 Prozess-Schritte und Vorgehensweise
[10](#prozess-schritte-und-vorgehensweise)](#prozess-schritte-und-vorgehensweise)

[3.1.1 Datenabfrage der Sensoren
[10](#datenabfrage-der-sensoren)](#datenabfrage-der-sensoren)

[3.1.2 Verarbeiten der Daten
[10](#verarbeiten-der-daten)](#verarbeiten-der-daten)

[3.2 Abweichung, Anpassung und Entscheidungen
[11](#abweichung-anpassung-und-entscheidungen)](#abweichung-anpassung-und-entscheidungen)

[3.3 Maßnahmen zur Qualitätskontrolle
[11](#maßnahmen-zur-qualitätskontrolle)](#maßnahmen-zur-qualitätskontrolle)

[3.4 Implementierung, Konfiguration und Inbetriebnahme von
Schnittstellen und unterschiedlicher Prozesse und Systeme
[12](#implementierung-konfiguration-und-inbetriebnahme-von-schnittstellen-und-unterschiedlicher-prozesse-und-systeme)](#implementierung-konfiguration-und-inbetriebnahme-von-schnittstellen-und-unterschiedlicher-prozesse-und-systeme)

[3.5 Konfiguration von Übertragungssystemen und Integration in die
Gesamtinfrastruktur
[12](#konfiguration-von-übertragungssystemen-und-integration-in-die-gesamtinfrastruktur)](#konfiguration-von-übertragungssystemen-und-integration-in-die-gesamtinfrastruktur)

[3.6 Erfüllen der Anforderungen an die Informationssicherheit
[13](#erfüllen-der-anforderungen-an-die-informationssicherheit)](#erfüllen-der-anforderungen-an-die-informationssicherheit)

[4. Projektabschluss [13](#projektabschluss)](#projektabschluss)

[4.1 Soll-Ist-Vergleich (Abweichung, Anpassungen)
[13](#soll-ist-vergleich-abweichung-anpassungen)](#soll-ist-vergleich-abweichung-anpassungen)

[4.2 Fazit [14](#fazit)](#fazit)

[4.3 Optimierungsmöglichkeiten
[14](#optimierungsmöglichkeiten)](#optimierungsmöglichkeiten)

[4.4 Abnahme [15](#abnahme)](#abnahme)

[Anlagen [15](#anlagen)](#anlagen)

[Netzwerkdiagramme und Systemarchitektur
[15](#netzwerkdiagramme-und-systemarchitektur)](#netzwerkdiagramme-und-systemarchitektur)

[API-Dokumentation [15](#api-dokumentation)](#api-dokumentation)

[Benutzerhandbuch [16](#benutzerhandbuch)](#benutzerhandbuch)

[Testprotokolle [16](#testprotokolle)](#testprotokolle)

[Screenshots der Benutzeroberfläche
[16](#screenshots-der-benutzeroberfläche)](#screenshots-der-benutzeroberfläche)

[Konfigurationsdateien und Deployment-Skripte
[16](#konfigurationsdateien-und-deployment-skripte)](#konfigurationsdateien-und-deployment-skripte)

# 1. Einleitung

## 1.1 Analyse des Projektauftrages

Die Technische Berufsausbildungsstätte (TBA) der Mercedes-Benz AG am
Standort Berlin verfügt über sechs 3D-Drucker verschiedener Hersteller
(Prusa, Anycubic; B-Ware im Vergleich zu 3D-Druckern von Kostenstellen
höherer Prioriät sozusagen). Diese Geräte stellen eine wichtige
Ressource für die praktische Ausbildung dar, weisen jedoch erhebliche
technische Limitierungen auf; beispielsweise verfügen die Drucker weder
über Funk- noch Netzwerkschnittstellen oder andere gesamteinheitliche
Steuerungsmöglichkeiten. Diese technischen Einschränkungen verhinderten
bislang eine koordinierte digitale Verwaltung und eine damit
einhergehende Übersicht von Reservierungen und Nutzungsplänen der
Azubis.

Das bestehende 'Reservierungssystem' - wenn man es nun so nennen kann -
basierte auf einem analogen Whiteboard, welches neben den Druckern
positioniert war. Dies führte zu systematischen Problemen:
Doppelbuchungen traten regelmäßig auf, wenn mehrere Nutzer zeitgleich
Reservierungen vornahmen, die manuelle Aktivierung und Deaktivierung der
Geräte wurde häufig versäumt - was zu unnötigem Energieverbrauch und
erhöhtem Verschleiß führte - und eine verlässliche Dokumentation der
tatsächlichen Nutzungszeiten existierte nicht, wodurch weder
aussagekräftige Betätigungs- und Verantwortungszuordnung (bspw. für
Aufräumarbeiten), noch eine verursachungsgerechte Kostenzuordnung
möglich waren.

Ein erstmaliger Lösungsansatz durch den ehemaligen Auszubildenden Torben
Haack hatte einen vielversprechenden Frontend-Prototyp auf Basis von
Next.js hervorgebracht. Der Prototyp verfügte über eine moderne
Benutzeroberfläche und gute Analysefunktionen, allerdings jedoch fehlte
ganz fundamental die essentielle Backend-Funktionalität; ohne dies blieb
die auf Prototypen-basierende Projektarbeit des Torben Haacks in der
praktischen Anwendung ohne jegliche Funktion. Ich sah für mich also die
Chance, die Idee hinter dem Prototypen aufzugreifen und mich ihrer im
Rahmen meiner hier dargelegten Projektarbeit anzunehmen, da ich sofort
mehrere Möglichkeiten zur Einbringung meiner Fachrichtung identifizieren
konnte und ich keine notwendige Obligation - wie bei anderen
Projektmöglichkeiten die sich mir boten - verspürte, sondern einen
Anflug von Ideen, Tatendrang und intrinsischer Motivation; sprich: es
kitzelte meine Leidenschaft.

## 1.2 Ableitung der Projektziele

Nach erfolgter Zulassung des Abschlussprojekts durch die IHK
kristallisierten sich die Projektziele in ihrer ganzen Komplexität
heraus. Das zu entwickelnde System sollte unter dem prägnanten Namen
"MYP - Manage Your Printer" nicht nur die digitale Verwaltung der
Reservierungen ermöglichen, sondern – und hier liegt die besondere
Herausforderung für einen Fachinformatiker der digitalen Vernetzung –
auch die automatisierte Steuerung der physischen Geräte realisieren.

Die zentrale technische Herausforderung bestand in der Überbrückung der
technischen Limitierungen der vorhandenen 3D-Drucker. Da eine direkte
Kommunikation mit den Geräten aufgrund fehlender Schnittstellen nicht
möglich war, musste ein alternativer, kreativer Ansatz zur
Hardware-Steuerung entwickelt werden. Gleichzeitig waren die strengen
Sicherheitsrichtlinien der Mercedes-Benz AG zu berücksichtigen, die
keine direkten, geschweige denn permanenten Internetverbindungen in der
Produktionsumgebung gestatten – eine Anforderung, die das Projekt
zusätzlich verkomplizierte.

Ein weiteres, nicht zu unterschätzendes Projektziel war die
Gewährleistung der Herstellerunabhängigkeit. Die heterogene und
schnittstellenarme Druckerlandschaft der sechs 3D-Drucker erforderte
eine universell einsetzbare Lösung, die sich zugleich auch leicht an
zukünftige Upgrades – sowohl der 3D-Drucker als auch der entstehenden
Lösung selbst – anpassen lassen würde. Das System sollte zudem eine
rudimentäre, aber effektive Rechteverwaltung implementieren, die
zwischen administrativen Funktionen und regulären Nutzerrechten
differenziert.

## 1.3 Projektabgrenzung

Der Projektumfang wurde – durchaus pragmatisch – auf die praktische
Umsetzung einer funktionsfähigen Lösung fokussiert. Eine umfassende
Daten- und Prozessanalyse wurde bewusst zugunsten der technischen
Realisierung zurückgestellt; diese Priorisierung ermöglichte die
Fertigstellung eines produktiv einsetzbaren Systems innerhalb des knapp
bemessenen Zeitrahmens von fünf Wochen.

Eine direkte Kommunikation mit den 3D-Druckern zur Übertragung von
Druckdaten oder zur Statusüberwachung wurde kategorisch aus dem
Projektumfang ausgeschlossen. Die fehlenden technischen Schnittstellen
der vorhandenen Geräte hätten umfangreiche Hardware-Modifikationen
erfordert, die weder zeitlich noch wirtschaftlich vertretbar gewesen
wären – ganz zu schweigen von den Garantieverlusten, die solche
Eingriffe nach sich gezogen hätten.

Ebenfalls nicht Teil des Projekts war die Integration in übergeordnete
ERP-Systeme oder das unternehmensweite Intranet. Diese Anbindungen
hätten zusätzliche Genehmigungsprozesse und Sicherheitsprüfungen
erfordert, die den Projektrahmen bei weitem überschritten hätten.
Stattdessen wurde eine autarke Lösung entwickelt, die alle
erforderlichen Funktionen lokal bereitstellt – ein Ansatz, der sich im
Nachhinein als goldrichtig erweisen sollte.

## 1.4 Projektumfeld

Das Projekt wurde im Rahmen meiner Ausbildung zum Fachinformatiker für
digitale Vernetzung bei der Mercedes-Benz AG durchgeführt. Die
Technische Berufsausbildungsstätte bot dabei optimale Voraussetzungen
durch die vorhandene Infrastruktur und die – wenn auch manchmal
zögerliche – fachliche Unterstützung der Ausbildungsleitung.

Die Zusammenarbeit mit dem Entwickler des Frontend-Prototyps, Torben
Haack, erfolgte in Form einer sequenziellen Weiterentwicklung. Da Herr
Haack seine Ausbildung bereits abgeschlossen hatte und ich erst nach
offizieller IHK-Zulassung mit der Projektarbeit beginnen durfte, konnte
ich auf seinen Vorarbeiten aufbauen und diese zu einer Gesamtlösung
erweitern – ein Umstand, der sich als Segen und Fluch zugleich erweisen
sollte.

Die organisatorischen Rahmenbedingungen wurden maßgeblich durch die
Sicherheitsrichtlinien und IT-Governance der Mercedes-Benz AG geprägt.
Jede technische Entscheidung musste die Vorgaben bezüglich
Netzwerksicherheit, Datenschutz und Compliance berücksichtigen. Die
Beantragung notwendiger Administratorrechte und die Genehmigung
selbstsignierter SSL-Zertifikate erforderten umfangreiche
Abstimmungsprozesse mit der IT-Abteilung – Prozesse, die sich teilweise
über Wochen hinzogen und meine Geduld auf eine harte Probe stellten.

## 1.5 Betriebliche Schnittstellen

Die Analyse der betrieblichen Schnittstellen offenbarte ein komplexes
Geflecht von Abhängigkeiten und Anforderungen. Primär musste das System
mit der bestehenden Netzwerkinfrastruktur der TBA harmonieren, ohne
dabei Sicherheitsrichtlinien zu verletzen. Die Schnittstelle zur
IT-Abteilung erwies sich als besonders kritisch, da jede
Netzwerkkonfiguration und jeder Port-Freischaltung einer expliziten
Genehmigung bedurfte.

Die Benutzerschnittstelle musste so gestaltet werden, dass sowohl
technisch versierte Auszubildende als auch weniger IT-affine Nutzer das
System intuitiv bedienen können. Dies erforderte eine Balance zwischen
Funktionsumfang und Benutzerfreundlichkeit – eine Balance, die nicht
immer leicht zu finden war.

Besonders herausfordernd gestaltete sich die Schnittstelle zu den
Smart-Plugs. Die ursprüngliche Annahme, dass sich die TAPO-Steckdosen
des chinesischen Herstellers TP-Link problemlos integrieren lassen
würden, erwies sich als naiv. Die proprietäre API der Geräte war
undokumentiert und erforderte erheblichen Reverse-Engineering-Aufwand –
aber dazu später mehr.

## 1.6 Analyse der IT-sicherheitsrelevante Bedingungen

Die Sicherheitsanalyse offenbarte multiple Herausforderungen, die es zu
bewältigen galt. Das System musste in einem isolierten Netzwerksegment
betrieben werden, ohne dabei die Funktionalität einzuschränken. Die
Anforderung, keine permanente Internetverbindung zu etablieren, schloss
Cloud-basierte Lösungen kategorisch aus – ein Umstand, der die Auswahl
geeigneter Smart-Plugs erheblich einschränkte.

Die Authentifizierung und Autorisierung musste robust implementiert
werden, um unbefugten Zugriff zu verhindern. Gleichzeitig durfte die
Sicherheit nicht zu Lasten der Benutzerfreundlichkeit gehen – ein
klassisches Dilemma der IT-Sicherheit. Die Entscheidung für
bcrypt-basiertes Password-Hashing mit angemessenem Cost-Faktor stellte
einen vernünftigen Kompromiss dar.

Besondere Aufmerksamkeit erforderte die Absicherung der API-Endpunkte.
Jeder Endpunkt musste gegen gängige Angriffsvektoren wie SQL-Injection,
Cross-Site-Scripting und CSRF-Attacken geschützt werden. Die
Implementierung eines Rate-Limiting-Mechanismus verhindert zudem
Brute-Force-Angriffe auf die Authentifizierungsschnittstelle.

## 1.7 Darstellung der vorhandenen Systemarchitektur

Die vorgefundene Systemarchitektur – wenn man sie denn so nennen möchte
– bestand aus isolierten Komponenten ohne jegliche Integration. Die
3D-Drucker operierten als Insellösungen, verbunden lediglich durch ihre
physische Nähe und das gemeinsame Whiteboard. Das von Torben Haack
entwickelte Frontend existierte als Docker-Container auf einem
Entwicklungsserver, ohne Anbindung an reale Daten oder Funktionen.

Die Netzwerkinfrastruktur der TBA basierte auf einem segmentierten
Ansatz mit verschiedenen VLANs für unterschiedliche Geräteklassen. Die
3D-Drucker waren – mangels Netzwerkfähigkeit – nicht in diese Struktur
integriert. Der bereitgestellte Raspberry Pi 4 (später aufgerüstet auf
einen Pi 5) sollte als zentrale Plattform für das MYP-System dienen.

Die Analyse ergab, dass eine grundlegende Neukonzeption der Architektur
erforderlich war. Die Lösung musste die isolierten Komponenten zu einem
kohärenten System verbinden, ohne dabei die bestehenden
Sicherheitsrichtlinien zu verletzen. Der gewählte Ansatz – die Steuerung
über Smart-Plugs – stellte einen eleganten Kompromiss zwischen
technischer Machbarkeit und praktischem Nutzen dar.

# 2. Projektplanung

## 2.1 Terminplanung

Die Projektplanung folgte einem agilen Ansatz nach Scrum-Prinzipien –
eine Entscheidung, die sich angesichts der zahlreichen Unwägbarkeiten
als goldrichtig erweisen sollte. Die Gesamtprojektdauer von fünf Wochen
(15. April bis 20. Mai 2025) wurde in fünf einwöchige Sprints
unterteilt, wobei jeder Sprint seine eigenen Herausforderungen und
Überraschungen bereithielt.

### Sprint 1 (15.-19. April 2025) 

Der erste Sprint widmete sich der Analyse des bestehenden Prototyps und
der Definition der Erweiterungspunkte. Die Evaluierung der
Frontend-Codebasis offenbarte eine solide, wenn auch überkomplexe
Struktur. Die Spezifikation der erforderlichen API-Endpunkte gestaltete
sich umfangreicher als erwartet – über 100 Endpunkte wurden
identifiziert. Der kritische Meilenstein dieses Sprints war die
erfolgreiche Etablierung der Kommunikation mit den Smart-Plugs über die
PyP100-Bibliothek, was zunächst scheiterte.

### Sprint 2 (22.-26. April 2025)

Im zweiten Sprint lag der Fokus auf dem Aufbau der
Backend-Infrastruktur. Die Beantragung und Erlangung der erforderlichen
Administratorrechte erwies sich als kafkaeske Odyssee durch die
Bürokratie der Mercedes-Benz AG. Parallel dazu begannen die ersten
Experimente mit Wireshark, um das Kommunikationsprotokoll der
Smart-Plugs zu entschlüsseln – eine Notwendigkeit, die sich aus der
mangelhaften Dokumentation der PyP100-Bibliothek ergab.

### Sprint 3 (29. April - 3. Mai 2025)

Der dritte Sprint sollte die Integration von Frontend und Backend
realisieren. Stattdessen wurde er zu einer Woche der technischen
Katastrophen: Die Verbindung zwischen den Komponenten scheiterte
wiederholt, die genehmigten SSL-Zertifikate gingen durch einen
unglücklichen Neuinstallationsprozess verloren, und die Einarbeitung in
die unternehmensspezifischen Implementierungen von GitHub OAuth und npm
verschlang wertvolle Zeit.

### Sprint 4 (6.-10. Mai 2025) 

Ursprünglich für Optimierungen vorgesehen, mutierte dieser Sprint zur
Rettungsmission. Der Zeitdruck erzwang pragmatische Entscheidungen und
die Konzentration auf essenzielle Funktionen. In marathonartigen
Coding-Sessions wurde die Grundfunktionalität implementiert – nicht
schön, aber funktional.

### Sprint 5 (13.-17. Mai 2025)

Der finale Sprint diente der Fehlerbehebung und Systemstabilisierung.
Die ursprünglich geplanten Schulungen fielen dem Zeitdruck zum Opfer.
Stattdessen wurde fieberhaft an kritischen Bugfixes gearbeitet und die
Projektdokumentation erstellt – letztere teilweise in nächtlichen
Schreibsessions.

## 2.2 Ressourcenplanung

Die Ressourcenplanung gestaltete sich als Balanceakt zwischen
technischen Anforderungen und budgetären Beschränkungen. Die
Hardware-Ausstattung wurde sorgfältig, aber auch pragmatisch ausgewählt.

Als zentrale Serverplattform diente zunächst ein Raspberry Pi 4 mit 4 GB
RAM – eine Entscheidung, die sich schnell als Fehlkalkulation
herausstellte. Performance-Tests zeigten, dass das ressourcenhungrige
Next.js-Frontend die kleine Platine an ihre Grenzen brachte. Der
kurzfristige Wechsel auf einen Raspberry Pi 5 mit 8 GB RAM löste die
Performance-Probleme, verursachte aber zusätzliche Kosten und
Zeitverzug.

Die sechs TP-Link Tapo P110 Smart-Plugs bildeten das Herzstück der
Hardware-Lösung. Jedes Gerät erhielt eine statische IP-Adresse im
Bereich 192.168.0.151 bis 192.168.0.156 – eine scheinbar triviale
Konfiguration, die sich später als entscheidend für die Systemstabilität
erweisen sollte. Die ursprüngliche Annahme, dass sich diese Geräte
problemlos integrieren lassen würden, erwies sich als optimistisch. Die
proprietäre API erforderte erheblichen Reverse-Engineering-Aufwand
mittels Wireshark.

Zur professionellen Unterbringung der Hardware wurde ein
19-Zoll-Serverschrank beschafft. Die internen Beschaffungsprozesse der
Mercedes-Benz AG erwiesen sich jedoch als so langwierig, dass ergänzende
Komponenten wie Lüftereinheiten und Kabelmanagement-Systeme aus eigener
Tasche finanziert wurden – eine Investition in die professionelle
Präsentation des Projekts.

Die Software-Architektur basierte vollständig auf
Open-Source-Technologien: Python 3.11 als Programmiersprache, Flask 2.3
als Web-Framework, SQLAlchemy 2.0 für die Datenbankabstraktion und
SQLite als Datenbanksystem. Diese Technologieauswahl gewährleistete
nicht nur Unabhängigkeit von proprietären Lösungen, sondern erfüllte
auch die strikte Offline-Anforderung des Projekts.

## 2.3 Planung der Qualitätssicherung

Das Qualitätssicherungskonzept orientierte sich am V-Modell – eine
klassische, aber bewährte Herangehensweise. Für jede Entwicklungsphase
wurden korrespondierende Testaktivitäten definiert, wobei die Realität
diese saubere Trennung oft genug konterkarierte.

Auf Unit-Test-Ebene wurden alle kritischen Komponenten isoliert
getestet. Die Datenbankoperationen, API-Eingabevalidierung und
Kernfunktionen der Reservierungsverwaltung durchliefen umfangreiche
Testszenarien. Besondere Aufmerksamkeit galt der
Smart-Plug-Kommunikation, für die spezielle Testfälle entwickelt wurden
– einschließlich simulierter Netzwerkausfälle und Timeout-Situationen.

Die Integrationstests gestalteten sich komplexer als erwartet. Das
Zusammenspiel zwischen Backend und Smart-Plugs erwies sich als
fehleranfällig, insbesondere bei gleichzeitigen Zugriffen. Die
systematischen Tests mit verschiedenen Eingabedaten – einschließlich
bewusst invalider und potenziell schädlicher Inputs – deckten mehrere
Sicherheitslücken auf, die nachträglich geschlossen werden mussten.

Systemtests bildeten komplette Anwendungsszenarien ab. Ein typischer
Testfall umfasste die Benutzeranmeldung, Reservierungserstellung,
automatische Druckeraktivierung zur geplanten Zeit und die anschließende
Deaktivierung. Die zeitliche Präzision der Schaltungen – kritisch für
die Benutzerzufriedenheit – wurde dabei besonders überwacht.

Performance-Tests auf der Zielplattform offenbarten die bereits
erwähnten Limitierungen des Raspberry Pi 4. Der Wechsel auf den Pi 5
löste diese Probleme, erforderte aber eine Wiederholung aller Tests. Die
finale Konfiguration bewältigte selbst simultane Zugriffe mehrerer
Nutzer und parallele Smart-Plug-Operationen ohne nennenswerte Einbußen.

## 2.4 Bewertung der heterogenen IT-Landschaft

Die IT-Landschaft der TBA präsentierte sich als bunter Flickenteppich
verschiedenster Technologien und Standards. Die 3D-Drucker stammten von
unterschiedlichen Herstellern mit inkompatiblen Steuerungssystemen. Das
Netzwerk war in multiple VLANs segmentiert, wobei die Dokumentation
dieser Struktur bestenfalls als lückenhaft bezeichnet werden konnte.

Die Herausforderung bestand darin, eine einheitliche Lösung für diese
heterogene Umgebung zu entwickeln. Der Ansatz über Smart-Plugs erwies
sich hier als Glücksgriff – er abstrahierte die Unterschiede zwischen
den Druckern auf die simpelste mögliche Ebene: Strom an oder aus. Diese
radikale Vereinfachung ermöglichte eine universelle Lösung, die
unabhängig vom Druckermodell funktionierte.

Die Integration in die bestehende Netzwerkinfrastruktur erforderte
diplomatisches Geschick. Die IT-Abteilung bestand auf strikter
Segmentierung, was die Kommunikation zwischen Komponenten
verkomplizierte. Die Lösung – ein dediziertes IoT-Subnetz für das
MYP-System – stellte einen akzeptablen Kompromiss dar.

## 2.5 Anforderungsgerechte Auswahl der Übertragungssysteme

Die Auswahl der Übertragungssysteme wurde maßgeblich durch die
Sicherheitsanforderungen bestimmt. Cloud-basierte Lösungen schieden
kategorisch aus, was die Optionen erheblich einschränkte. Die
Entscheidung für lokale HTTP/HTTPS-Kommunikation mit selbstsignierten
Zertifikaten war pragmatisch, aber effektiv.

Die Kommunikation mit den Smart-Plugs erfolgte über das proprietäre
TP-Link-Protokoll, das auf HTTP basiert. Die anfänglichen Versuche, die
offizielle Cloud-API zu nutzen, scheiterten an den
Sicherheitsrichtlinien. Die Entdeckung, dass die Geräte auch eine lokale
API anboten, war ein Durchbruch – allerdings einer, der erheblichen
Reverse-Engineering-Aufwand erforderte.

Hier kam Wireshark ins Spiel. Zusammen mit der TAPO-App analysierte ich
den Netzwerkverkehr, um das Kommunikationsprotokoll zu entschlüsseln.
Die Erkenntnis, dass ein Session-Key erforderlich war, der sich bei
jeder Anmeldung änderte, verkomplizierte die Integration erheblich.
Zunächst versuchte ich, diesen Key manuell abzufangen und in meine
Anwendung zu integrieren – ein Ansatz, der funktionierte, aber
offensichtlich nicht praxistauglich war.

Nach tagelangen Experimenten und zahllosen Fehlversuchen stieß ich auf
ein alternatives Python-Modul, das die lokale Kommunikation mit den
TAPO-Geräten ermöglichte. Dieses Modul – versteckt in den Tiefen von
GitHub – löste die Session-Key-Problematik elegant und ermöglichte eine
stabile Integration.

## 2.6 Planung der Prozess-/ und Systemschnittstellen

Die Schnittstellenplanung erforderte eine sorgfältige Balance zwischen
Funktionalität und Sicherheit. Die REST-API wurde nach modernen
Standards entworfen, mit klarer Trennung zwischen öffentlichen und
authentifizierten Endpunkten. Über 100 Endpunkte wurden spezifiziert –
eine Zahl, die zunächst übertrieben erschien, sich aber als notwendig
erwies.

Die Schnittstelle zwischen Frontend und Backend basierte auf
JSON-formatierter Kommunikation über HTTPS. Die Implementierung von
CORS-Policies gestaltete sich komplexer als erwartet, da die
Sicherheitsrichtlinien strikte Einschränkungen vorgaben. Die Lösung –
eine Whitelist-basierte CORS-Konfiguration – erfüllte die
Sicherheitsanforderungen ohne die Funktionalität einzuschränken.

Besondere Aufmerksamkeit erforderte die Scheduler-Schnittstelle. Der als
eigenständiger Thread implementierte Scheduler musste nahtlos mit der
Hauptanwendung kommunizieren, ohne dabei Race Conditions oder Deadlocks
zu verursachen. Die Verwendung von Thread-sicheren Queues und explizitem
Locking löste diese Herausforderung.

## 2.7 Planung der IT-Sicherheitsmaßnahmen

Die Sicherheitsplanung folgte dem Prinzip "Security by Design" – ein
Ansatz, der sich angesichts der sensiblen Umgebung als unerlässlich
erwies. Jede Komponente wurde von Anfang an mit Sicherheit im Hinterkopf
entwickelt.

Die Authentifizierung basierte auf bcrypt mit einem Cost-Faktor von 12 –
ein Kompromiss zwischen Sicherheit und Performance auf dem Raspberry Pi.
Session-Management wurde über Flask-Login realisiert, mit
konfigurierbaren Timeout-Werten und sicheren Session-Cookies. Die
Implementierung einer Brute-Force-Protection mit exponentieller
Backoff-Strategie verhinderte automatisierte Angriffe.

Auf Netzwerkebene wurden restriktive Firewall-Regeln implementiert. Nur
essenzielle Ports wurden geöffnet, ausgehende Verbindungen auf die
IP-Adressen der Smart-Plugs beschränkt. Die Verwendung von iptables
ermöglichte granulare Kontrolle über den Netzwerkverkehr.

Die API-Sicherheit umfasste Input-Validation, Output-Encoding und
CSRF-Protection. Jeder Endpunkt wurde gegen die OWASP Top 10
abgesichert. Ein selbstentwickeltes Intrusion Detection System
überwachte verdächtige Aktivitäten und sperrte bei Bedarf IP-Adressen
temporär.

# 3. Durchführung und Auftragsbearbeitung

In diesem Kapitel wird die konkrete Umsetzung beschrieben.

## 3.1 Prozess-Schritte und Vorgehensweise

Die Durchführung des Projekts glich einer technischen Odyssee, gespickt
mit unerwarteten Wendungen und kreativen Lösungsansätzen. Die
ursprünglich geplante lineare Vorgehensweise wich schnell einer
iterativen, problemgetriebenen Herangehensweise.

### 3.1.1 Datenabfrage der Sensoren

Die "Sensoren" in diesem Kontext waren die Smart-Plugs – eine
euphemistische Bezeichnung für Geräte, die sich als erstaunlich
widerspenstig erwiesen. Die initiale Annahme, dass die PyP100-Bibliothek
out-of-the-box funktionieren würde, zerschlug sich an der Realität der
proprietären TP-Link-Implementation.

Der erste Ansatz – die Nutzung der dokumentierten Cloud-API – scheiterte
an den Sicherheitsrichtlinien. Der zweite Ansatz – die direkte lokale
Kommunikation – scheiterte an der fehlenden Dokumentation. Erst der
dritte Ansatz – Reverse Engineering mittels Wireshark – führte zum
Durchbruch.

Die Wireshark-Analyse offenbarte das komplexe
Authentifizierungsprotokoll der TAPO-Geräte. Jede Kommunikation
erforderte einen verschlüsselten Handshake, gefolgt von einem
Session-Token, der für alle weiteren Operationen benötigt wurde. Die
Verschlüsselung basierte auf einer Kombination aus RSA und AES –
durchaus respektabel für Consumer-Hardware.

Die Implementierung der Datenabfrage erfolgte schließlich über eine
selbstentwickelte Wrapper-Klasse, die die Komplexität der Kommunikation
kapselte. Retry-Mechanismen mit exponentieller Backoff-Strategie sorgten
für Robustheit bei Netzwerkproblemen. Die Abfrage umfasste nicht nur den
Schaltzustand, sondern auch Metadaten wie Energieverbrauch und
Signalstärke – Informationen, die sich später als wertvoll für das
Monitoring erwiesen.

### 3.1.2 Verarbeiten der Daten

Die Datenverarbeitung folgte einem ereignisgesteuerten Ansatz. Der
Scheduler-Thread prüfte im Minutentakt die Datenbank auf anstehende
Aktionen und triggerte entsprechende Smart-Plug-Operationen. Die
Herausforderung bestand darin, die Asynchronität der
Hardware-Operationen mit der Synchronität der Datenbankzugriffe zu
vereinen.

Die Lösung war ein Queue-basiertes System, das Kommandos pufferte und
sequenziell abarbeitete. Dies verhinderte Race Conditions bei simultanen
Zugriffen und gewährleistete die Konsistenz der Systemzustände. Jede
Operation wurde in einer Transaktion gekapselt, mit Rollback-Mechanismen
bei Fehlern.

Die Verarbeitung der Energiedaten ermöglichte interessante Einblicke in
die Nutzungsmuster. Anomalien – wie ungewöhnlich hoher Stromverbrauch –
konnten erkannt und gemeldet werden. Diese Funktion, ursprünglich nicht
geplant, erwies sich als wertvolles Feature für die präventive Wartung.

## 3.2 Abweichung, Anpassung und Entscheidungen

Die Projektdurchführung war geprägt von kontinuierlichen Anpassungen an
die Realität. Die größte Abweichung vom ursprünglichen Plan war der
Wechsel der Systemarchitektur von einer verteilten zu einer
konsolidierten Lösung.

Ursprünglich war geplant, dass ich nur die API entwickle und diese mit
Torbens Frontend auf einem separaten Raspberry Pi verknüpfe. Diese
Architektur erwies sich als zu komplex – die unterschiedlichen
Technologie-Stacks (Next.js vs. Python/Flask) und die
Netzwerksegmentierung machten die Integration zum Albtraum. Die
Entscheidung, beide Komponenten auf einem einzigen Raspberry Pi zu
konsolidieren, vereinfachte nicht nur die Architektur, sondern
reduzierte auch Kosten und Stromverbrauch.

Der versehentliche Verlust der SSL-Zertifikate während einer
Neuinstallation – ein Moment des Schreckens – führte zur Implementierung
eines robusten Backup-Systems. Die Lektion war schmerzhaft, aber
lehrreich: Kritische Konfigurationsdateien werden nun dreifach
gesichert.

Die Entscheidung, von der komplexen PyP100-Integration zu einem
alternativen Modul zu wechseln, fiel nach tagelangen frustrierenden
Debugging-Sessions. Der Stolz, es "richtig" machen zu wollen, wich dem
Pragmatismus, eine funktionierende Lösung zu liefern. Das gefundene
Alternative Modul – ironischerweise simpler und stabiler – rettete das
Projekt.

## 3.3 Maßnahmen zur Qualitätskontrolle

Die Qualitätskontrolle erfolgte kontinuierlich und vielschichtig.
Automatisierte Tests liefen bei jedem Commit, manuelle Tests ergänzten
diese bei kritischen Funktionen. Die Herausforderung bestand darin, die
Hardware-abhängigen Komponenten testbar zu machen.

Mock-Objekte simulierten die Smart-Plugs für Unit-Tests. Diese Mocks
replizierten das Verhalten der echten Hardware, einschließlich typischer
Fehlerszenarien wie Timeouts oder Verbindungsabbrüche. Die Test-Coverage
erreichte respektable 85% – die fehlenden 15% waren hauptsächlich
UI-Code und Error-Handler.

Integrationstests mit echter Hardware deckten Probleme auf, die in der
Simulation nicht auftraten. Timing-Issues bei simultanen Zugriffen,
Memory-Leaks bei lang laufenden Operationen, Race Conditions im
Scheduler – all diese Probleme wurden iterativ identifiziert und
behoben.

Die Implementierung eines Logging-Systems erwies sich als unschätzbar
wertvoll. Jede Operation, jeder Fehler, jede Anomalie wurde
protokolliert. Die Log-Analyse wurde zum wichtigsten Debugging-Tool,
insbesondere bei sporadisch auftretenden Problemen.

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

Die Implementierung der verschiedenen Schnittstellen erfolgte modular
und iterativ. Die REST-API wurde Blueprint-basiert strukturiert, was
eine klare Trennung der Funktionsbereiche ermöglichte. Authentication,
User Management, Printer Management und Job Management erhielten jeweils
eigene Blueprints.

Die Smart-Plug-Schnittstelle durchlief mehrere Iterationen. Die finale
Implementation kapselte die gesamte Kommunikationslogik in einer
einzigen Klasse, die eine simple API bot: turn_on(), turn_off(),
get_status(). Diese Abstraktion verbarg die Komplexität des
darunterliegenden Protokolls und ermöglichte einfache Erweiterungen.

Die Datenbank-Schnittstelle nutzte SQLAlchemy's ORM-Funktionalität. Die
Definition der Models erfolgte deklarativ, Migrationen wurden über
Alembic verwaltet. Die Entscheidung für SQLite als Datenbank war
pragmatisch – keine zusätzlichen Services, keine Konfiguration, perfekt
für die Offline-Anforderung.

Der Scheduler wurde als eigenständiger Thread implementiert, der beim
Anwendungsstart initialisiert wurde. Die Kommunikation mit dem
Hauptthread erfolgte über thread-sichere Queues. Diese Architektur
ermöglichte asynchrone Hardware-Operationen ohne Blockierung der
Web-Requests.

## 3.5 Konfiguration von Übertragungssystemen und Integration in die Gesamtinfrastruktur

Die Integration in die Mercedes-Benz-Infrastruktur erforderte zahlreiche
Kompromisse und kreative Lösungen. Das dedizierte IoT-Subnetz wurde
speziell für das MYP-System eingerichtet, mit restriktiven
Firewall-Regeln und ohne Internet-Zugang.

Die Netzwerkkonfiguration erfolgte in enger Abstimmung mit der
IT-Abteilung. Jede Änderung erforderte ein Change-Request, jede
Port-Öffnung eine Security-Review. Der bürokratische Overhead war
erheblich, aber notwendig für die Compliance.

Die SSL-Konfiguration mit selbstsignierten Zertifikaten war ein
notwendiges Übel. Ohne Internet-Zugang war Let's Encrypt keine Option.
Die Zertifikate wurden mit allen relevanten SANs (Subject Alternative
Names) generiert, um Kompatibilitätsprobleme zu vermeiden. Die
Browser-Warnungen wurden durch eine dokumentierte Prozedur zur
Zertifikats-Installation umgangen.

Die Integration der Smart-Plugs erforderte statische IP-Adressen –
DHCP-Reservierungen waren in der Netzwerk-Policy nicht vorgesehen. Die
manuelle Konfiguration jedes Geräts war mühsam, gewährleistete aber
stabile Verbindungen.

## 3.6 Erfüllen der Anforderungen an die Informationssicherheit

Die Informationssicherheit wurde von Anfang an als kritischer
Erfolgsfaktor behandelt. Jede Designentscheidung wurde durch die
Sicherheitsbrille betrachtet, jede Implementierung auf Schwachstellen
geprüft.

Die Authentifizierung implementierte moderne Best Practices:
bcrypt-Hashing, sichere Session-Verwaltung, CSRF-Protection. Die
API-Endpunkte wurden systematisch gegen die OWASP Top 10 abgesichert.
Input-Validation erfolgte auf mehreren Ebenen – Client-seitig für UX,
Server-seitig für Sicherheit.

Die Implementierung eines Rate-Limiters verhinderte
Brute-Force-Angriffe. Nach fünf fehlgeschlagenen Login-Versuchen wurde
die IP-Adresse für 30 Minuten gesperrt – lang genug, um Angriffe
unwirtschaftlich zu machen, kurz genug, um legitime Nutzer nicht
übermäßig zu frustrieren.

DSGVO-Compliance wurde durch Privacy-by-Design erreicht.
Personenbezogene Daten wurden minimiert, Löschfristen implementiert,
Datenexport-Funktionen bereitgestellt. Die Logging-Funktionalität
anonymisierte IP-Adressen nach 30 Tagen automatisch.

# 4. Projektabschluss

Dieses Kapitel beschreibt das Ergebnis, die Bewertung sowie das Fazit.

## 4.1 Soll-Ist-Vergleich (Abweichung, Anpassungen)

Der Vergleich zwischen geplanten und erreichten Zielen offenbart ein
gemischtes, aber letztendlich positives Bild. Die Kernfunktionalität –
digitale Reservierungsverwaltung mit automatischer Hardware-Steuerung –
wurde vollständig implementiert und übertraf in einigen Aspekten sogar
die ursprünglichen Anforderungen.

#### Erfolgreich umgesetzte Anforderungen:

- Vollständige Digitalisierung des Reservierungsprozesses

- Automatische Steuerung der 3D-Drucker via Smart-Plugs

- Robuste Benutzerauthentifizierung und -autorisierung

- Umfassende REST-API mit über 100 Endpunkten

- Offline-fähige Architektur ohne Cloud-Abhängigkeiten

- DSGVO-konforme Datenhaltung

- Energiemonitoring und Nutzungsstatistiken

#### Abweichungen vom ursprünglichen Plan:

- Konsolidierung auf einen statt zwei Raspberry Pis

- Wechsel von PyP100 zu alternativem Kommunikationsmodul

- Verzicht auf Touch-Display zugunsten konventioneller Eingabe

- Verschiebung der Benutzerschulungen auf Nach-Projektphase

Die größte positive Überraschung war die erfolgreiche Integration des
Energiemonitorings. Diese ursprünglich nicht geplante Funktion
ermöglicht detaillierte Einblicke in Nutzungsmuster und Energieverbrauch
– wertvolle Daten für die Optimierung des Druckerbetriebs.

Die technischen Herausforderungen – insbesondere die
Smart-Plug-Integration – erforderten mehr Zeit als geplant. Die
investierte Mühe zahlte sich jedoch aus: Die finale Lösung ist robuster
und wartungsfreundlicher als eine Quick-and-Dirty-Implementation gewesen
wäre.

## 4.2 Fazit

Das MYP-Projekt demonstriert eindrucksvoll, wie durch kreative Ansätze
und technisches Geschick aus scheinbar unüberwindbaren Hindernissen
elegante Lösungen entstehen können. Die Transformation eines analogen
Whiteboards in ein modernes cyber-physisches System mag auf den ersten
Blick trivial erscheinen – die Umsetzung offenbarte jedoch die volle
Komplexität vernetzter Systeme.

Die Entscheidung, die fehlenden Schnittstellen der 3D-Drucker durch
Smart-Plugs zu überbrücken, erwies sich als Glücksgriff. Diese
Abstraktion auf die grundlegendste Ebene – Stromversorgung – ermöglichte
eine universelle Lösung, die unabhängig von Druckermodell oder
Hersteller funktioniert. Ein klassisches Beispiel für das KISS-Prinzip
(Keep It Simple, Stupid) in Aktion.

Die technische Exzellenz des Systems zeigt sich in den Details: Über
9.000 Zeilen sauber strukturierter Python-Code, eine umfassende
REST-API, robuste Fehlerbehandlung, durchdachte Sicherheitsarchitektur.
Doch der wahre Erfolg liegt in der Praxistauglichkeit – das System läuft
stabil, wird aktiv genutzt und hat das manuelle Chaos endgültig beendet.

Persönlich war das Projekt eine Achterbahnfahrt der Emotionen. Von der
anfänglichen Euphorie über die frustrierenden Debugging-Sessions bis zum
finalen Triumph – jede Phase bot Lernerfahrungen. Die Fähigkeit, unter
Zeitdruck pragmatische Entscheidungen zu treffen, ohne dabei die
Qualität zu kompromittieren, war die wichtigste erworbene Kompetenz.

## 4.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 Active Directory der Mercedes-Benz
AG geplant. Die vorbereiteten Schnittstellen ermöglichen eine nahtlose
Integration, sobald die erforderlichen Genehmigungen vorliegen. Diese
Erweiterung würde die Benutzerverwaltung erheblich vereinfachen.

Mittelfristig könnte bei Verfügbarkeit modernerer 3D-Drucker eine
direkte Geräteintegration realisiert werden. Die Einbindung von
OctoPrint oder vergleichbaren Systemen würde erweiterte Funktionen wie
Druckfortschrittsüberwachung und Remote-Dateiverwaltung ermöglichen.

Langfristig bietet sich die Erweiterung zu einer umfassenden
Maker-Space-Management-Lösung an. Die grundlegende Architektur
unterstützt die Integration weiterer Gerätetypen wie Lasercutter oder
CNC-Fräsen. Machine-Learning-Algorithmen könnten perspektivisch für
Auslastungsprognosen und Optimierungsvorschläge implementiert werden.

## 4.4 Abnahme

Die formale Projektabnahme erfolgte am 2. 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 Murphy's Law – reibungslos. Die
automatische Aktivierung eines 3D-Druckers zur reservierten Zeit löste
sichtbare Begeisterung aus. Die anschließende Erläuterung der
technischen Herausforderungen und deren Lösungen unterstrich die
Komplexität des scheinbar simplen Systems.

Besonders positiv wurde die Wirtschaftlichkeit der Lösung bewertet. Mit
Gesamtkosten unter 600 Euro (inklusive privat finanzierter Komponenten)
liegt das System weit unter kommerziellen Alternativen. Die Einsparungen
durch automatisierte Abschaltung und optimierte Nutzung amortisieren die
Investition binnen weniger Monate.

Die Rückmeldungen der ersten Nutzer bestätigten die Praxistauglichkeit.
Die intuitive Bedienung, die zuverlässige Funktion und die Eliminierung
von Reservierungskonflikten wurden besonders gelobt. Kritikpunkte –
hauptsächlich bezüglich kleiner UX-Details – wurden dokumentiert und
fließen in zukünftige Updates ein.

Mit der erfolgreichen Abnahme und Inbetriebnahme schließt das Projekt
formal ab. Das MYP-System ist jedoch kein statisches Produkt, sondern
der Beginn einer kontinuierlichen Evolution. Die geschaffene Basis
ermöglicht iterative Verbesserungen und Erweiterungen – ganz im Sinne
moderner Software-Entwicklung.

Die Transformation der 3D-Drucker-Verwaltung von analog zu digital, von
chaotisch zu strukturiert, von manuell zu automatisiert ist vollbracht.
Was als technische Herausforderung begann, endete als Erfolgsgeschichte
– ein Beweis dafür, dass mit Kreativität, Durchhaltevermögen und einer
Prise technischer Finesse auch scheinbar unlösbare Probleme gemeistert
werden können.

# Anlagen

## Netzwerkdiagramme und Systemarchitektur

## API-Dokumentation

## Benutzerhandbuch

## Testprotokolle

## Screenshots der Benutzeroberfläche

## Konfigurationsdateien und Deployment-Skripte