From c55b260ebbed90c65f01f90444e16816b1ff9845 Mon Sep 17 00:00:00 2001 From: Till Tomczak Date: Tue, 3 Jun 2025 15:19:28 +0200 Subject: [PATCH] =?UTF-8?q?=F0=9F=8E=89=20Updated=20IHK=20Project=20Docume?= =?UTF-8?q?ntation=20Markdown=20file=20for=20clarity=20and=20consistency?= =?UTF-8?q?=20=F0=9F=93=9A=F0=9F=92=84?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- .../Dokumentation.md | 741 +++++++++++------- 1 file changed, 455 insertions(+), 286 deletions(-) diff --git a/IHK_Projektdokumentation/Dokumentation_Final_Markdown/Dokumentation.md b/IHK_Projektdokumentation/Dokumentation_Final_Markdown/Dokumentation.md index 038e6f18..ad3c3d6d 100644 --- a/IHK_Projektdokumentation/Dokumentation_Final_Markdown/Dokumentation.md +++ b/IHK_Projektdokumentation/Dokumentation_Final_Markdown/Dokumentation.md @@ -223,433 +223,581 @@ differenziert. ## 1.3 Projektabgrenzung -Der Projektumfang wurde pragmatisch auf die Umsetzung einer -funktionsfähigen Lösung fokussiert. Eine umfassende Daten- und -Prozessanalyse wurde zugunsten der technischen Realisierung -zurückgestellt, um ein produktiv einsetzbares System innerhalb des -Zeitrahmens von fünf Wochen fertigzustellen. +Der Projektumfang wurde – durchaus pragmatisch, möchte man meinen – 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 aus dem Projektumfang -ausgeschlossen. Die fehlenden Schnittstellen der Geräte hätten -umfangreiche Hardware-Modifikationen erfordert, die weder zeitlich noch -wirtschaftlich vertretbar gewesen wären. +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 unweigerlich nach sich gezogen hätten. -Die Integration in übergeordnete ERP-Systeme oder das unternehmensweite -Intranet war ebenfalls nicht Teil des Projekts. Diese Anbindungen hätten -zusätzliche Genehmigungsprozesse erfordert, die den Projektrahmen -überschritten hätten. Stattdessen wurde eine autarke Lösung entwickelt, -die alle erforderlichen Funktionen lokal bereitstellt. +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 die vorhandene -Infrastruktur und fachliche Unterstützung durch die Ausbildungsleitung. +Infrastruktur und – wenn auch manchmal zögerliche – fachliche +Unterstützung durch die Ausbildungsleitung. Die Zusammenarbeit mit Torben Haack erfolgte in Form einer sequenziellen -Weiterentwicklung. Da Herr Haack seine Ausbildung bereits abgeschlossen -hatte und ich erst nach IHK-Zulassung mit der Projektarbeit beginnen -durfte, konnte ich auf seinen Frontend-Prototyp aufbauen und diesen zu -einer Gesamtlösung erweitern. +Weiterentwicklung; ein Umstand, der sich aus der zeitlichen Versetzung +unserer Ausbildungsphasen ergab. Da Herr Haack seine Ausbildung bereits +abgeschlossen hatte und ich erst nach offizieller IHK-Zulassung mit der +Projektarbeit beginnen durfte, konnte ich auf seinen Frontend-Prototyp +aufbauen und diesen zu einer Gesamtlösung erweitern – eine Konstellation, +die sich als Segen und Fluch zugleich erweisen sollte. -Die organisatorischen Rahmenbedingungen wurden durch die +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. +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. Das System musste mit der bestehenden -Netzwerkinfrastruktur der TBA harmonieren, ohne Sicherheitsrichtlinien -zu verletzen. Die Schnittstelle zur IT-Abteilung erwies sich als -kritisch, da jede Netzwerkkonfiguration und Port-Freischaltung einer -expliziten Genehmigung bedurfte. +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 jede Port-Freischaltung einer expliziten +Genehmigung bedurfte – ein bürokratischer Tanz, der Fingerspitzengefühl +erforderte. -Die Benutzerschnittstelle wurde so gestaltet, 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. +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, aber letztendlich gelang. -Die Schnittstelle zu den Smart-Plugs stellte eine besondere -Herausforderung dar. Die TAPO P110-Steckdosen von TP-Link verfügten über -eine proprietäre, undokumentierte API, die erheblichen -Reverse-Engineering-Aufwand erforderte. +Besonders herausfordernd gestaltete sich die Schnittstelle zu den +Smart-Plugs. Die ursprüngliche Annahme, dass sich die TAPO P110-Steckdosen +von TP-Link problemlos integrieren lassen würden, erwies sich als +erstaunlich naiv. Die proprietäre API der Geräte war nicht nur +undokumentiert, sondern geradezu verschleiert – ein Umstand, der +erheblichen Reverse-Engineering-Aufwand erforderte und mich in die +Tiefen der Netzwerkanalyse führte. ## 1.6 Analyse der IT-sicherheitsrelevante Bedingungen -Die Sicherheitsanalyse offenbarte multiple Herausforderungen. Das System -musste in einem isolierten Netzwerksegment betrieben werden, ohne die -Funktionalität einzuschränken. Die Anforderung, keine permanente -Internetverbindung zu etablieren, schloss Cloud-basierte Lösungen aus -und schränkte die Auswahl geeigneter Smart-Plugs erheblich ein. +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 und mich zu kreativen +Lösungsansätzen zwang. -Die Authentifizierung und Autorisierung wurde robust implementiert, ohne -die Benutzerfreundlichkeit zu beeinträchtigen. Die Entscheidung für +Die Authentifizierung und Autorisierung musste robust implementiert +werden, ohne die Benutzerfreundlichkeit zu beeinträchtigen – ein +klassisches Dilemma der IT-Sicherheit. Die Entscheidung für bcrypt-basiertes Password-Hashing mit einem Cost-Faktor von 12 stellte -einen vernünftigen Kompromiss zwischen Sicherheit und Performance dar. +einen vernünftigen Kompromiss zwischen Sicherheit und Performance auf +dem ressourcenbeschränkten Raspberry Pi dar. Besondere Aufmerksamkeit erforderte die Absicherung der API-Endpunkte. -Jeder Endpunkt wurde gegen gängige Angriffsvektoren wie SQL-Injection, -Cross-Site-Scripting und CSRF-Attacken geschützt. Die Implementierung -eines Rate-Limiting-Mechanismus verhindert Brute-Force-Angriffe auf die -Authentifizierungsschnittstelle. +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 – eine +Maßnahme, die sich später als weitsichtig erweisen sollte. ## 1.7 Darstellung der vorhandenen Systemarchitektur -Die vorgefundene Systemarchitektur bestand aus isolierten Komponenten -ohne Integration. Die 3D-Drucker operierten als Insellösungen, verbunden -nur durch ihre physische Nähe und das gemeinsame Whiteboard. Der +Die vorgefundene Systemarchitektur – wenn man sie denn überhaupt 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. Der Frontend-Prototyp von Torben Haack existierte als Docker-Container auf -einem Entwicklungsserver, ohne Anbindung an reale Funktionen. +einem Entwicklungsserver, ohne Anbindung an reale Daten oder Funktionen +– ein digitales Potemkinsches Dorf, wenn man so will. 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. Ein Raspberry Pi 5 mit 8 GB RAM und 128 GB Speicher sollte -als zentrale Plattform für das MYP-System dienen. +3D-Drucker waren – mangels Netzwerkfähigkeit – nicht in diese Struktur +integriert. Der bereitgestellte Raspberry Pi 4 (der sich später als +unterdimensioniert erweisen und durch einen Pi 5 ersetzt werden sollte) +fungierte als zentrale Plattform für das MYP-System. 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 die bestehenden Sicherheitsrichtlinien -zu verletzen. Der gewählte Ansatz über Smart-Plugs stellte einen -eleganten Kompromiss zwischen technischer Machbarkeit und praktischem -Nutzen dar. +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; eine Lösung, die in +ihrer Simplizität genial war. # 2. Projektplanung ## 2.1 Terminplanung -Die Projektplanung folgte einem agilen Ansatz nach Scrum-Prinzipien. Die -Gesamtprojektdauer von fünf Wochen (15. April bis 20. Mai 2025) wurde in -fünf einwöchige Sprints unterteilt, wobei jeder Sprint spezifische Ziele -verfolgte. +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 +– ja – auch Ü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 Struktur. Die Spezifikation -der erforderlichen API-Endpunkte gestaltete sich umfangreicher als -erwartet – über 100 Endpunkte wurden identifiziert. Der kritische -Meilenstein war die Etablierung der Kommunikation mit den Smart-Plugs, -was zunächst mit der PyP100-Bibliothek scheiterte. +Frontend-Codebasis offenbarte eine solide, wenn auch stellenweise +überkomplexe Struktur. Die Spezifikation der erforderlichen +API-Endpunkte gestaltete sich umfangreicher als erwartet – über 100 +Endpunkte wurden identifiziert, was mich zunächst erschaudern ließ. Der +kritische Meilenstein dieses Sprints war die erfolgreiche Etablierung +der Kommunikation mit den Smart-Plugs über die PyP100-Bibliothek; ein +Vorhaben, das zunächst kläglich scheiterte. ### Sprint 2 (22.-26. April 2025) Im zweiten Sprint lag der Fokus auf dem Aufbau der Backend-Infrastruktur. Die Beantragung der erforderlichen -Administratorrechte erwies sich als zeitaufwändig. Parallel begannen die -ersten Experimente mit Wireshark, um das Kommunikationsprotokoll der -Smart-Plugs zu entschlüsseln, da die PyP100-Bibliothek nicht -funktionierte. +Administratorrechte erwies sich als bürokratischer Marathon durch die +Instanzen 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 und mich in die +Rolle eines digitalen Detektivs drängte. ### Sprint 3 (29. April - 3. Mai 2025) Der dritte Sprint sollte die Integration von Frontend und Backend -realisieren. Die Verbindung zwischen den Komponenten scheiterte +realisieren. Stattdessen mutierte er zu einer Woche der technischen +Herausforderungen: Die Verbindung zwischen den Komponenten scheiterte wiederholt, die genehmigten SSL-Zertifikate gingen durch einen -Neuinstallationsprozess verloren, und die Einarbeitung in die +unglücklichen Neuinstallationsprozess verloren (ein Moment, der mich +die Wichtigkeit von Backups lehrte), und die Einarbeitung in die unternehmensspezifischen Implementierungen von GitHub OAuth und npm -erforderte zusätzliche Zeit. +verschlang wertvolle Zeit. ### Sprint 4 (6.-10. Mai 2025) -Ursprünglich für Optimierungen vorgesehen, wurde dieser Sprint zur -Entwicklung einer Full-Stack-Notlösung umfunktioniert. Der Zeitdruck -erzwang pragmatische Entscheidungen. In intensiven Coding-Sessions wurde -die Grundfunktionalität implementiert. +Ursprünglich für Optimierungen vorgesehen, wandelte sich 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 +unbedingt elegant, aber funktional; ein klassischer Fall von "done is +better than perfect". ### Sprint 5 (13.-17. Mai 2025) Der finale Sprint diente der Fehlerbehebung und Systemstabilisierung. -Die geplanten Schulungen wurden auf die Nach-Projektphase verschoben. -Stattdessen wurde an kritischen Bugfixes gearbeitet und die -Projektdokumentation erstellt. +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 +Sessions, begleitet von übermäßigem Koffeinkonsum. ## 2.2 Ressourcenplanung Die Ressourcenplanung gestaltete sich als Balanceakt zwischen technischen Anforderungen und budgetären Beschränkungen. Die -Hardware-Ausstattung wurde sorgfältig ausgewählt. +Hardware-Ausstattung wurde sorgfältig – und doch pragmatisch – +ausgewählt. -Als zentrale Serverplattform diente ein Raspberry Pi 5 mit 8 GB RAM und -128 GB Speicher. Der ursprünglich geplante Raspberry Pi 4 erwies sich -als zu leistungsschwach für das ressourcenintensive Next.js-Frontend. +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; ein +digitaler David gegen Goliath, nur dass David diesmal unterlag. Der +kurzfristige Wechsel auf einen Raspberry Pi 5 mit 8 GB RAM und 128 GB +Speicher löste die Performance-Probleme, verursachte aber zusätzliche +Kosten und – was schwerer wog – 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.100 bis 192.168.0.106. Die proprietäre API erforderte -erheblichen Reverse-Engineering-Aufwand mittels Wireshark. +Bereich 192.168.0.100 bis 192.168.0.106 – 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. Ergänzende Komponenten wie -Lüftereinheiten und Kabelmanagement-Systeme wurden aus privaten Mitteln -finanziert, um eine professionelle Präsentation zu gewährleisten. +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 mir wichtig war. -Die Software-Architektur basierte auf Open-Source-Technologien: Python -3.11, Flask 2.3, SQLAlchemy 2.0 und SQLite. Diese Technologieauswahl -gewährleistete Unabhängigkeit von proprietären Lösungen und erfüllte die -Offline-Anforderung 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 – ein Umstand, der +sich als Segen erwies. ## 2.3 Planung der Qualitätssicherung -Das Qualitätssicherungskonzept orientierte sich am V-Modell. Für jede -Entwicklungsphase wurden korrespondierende Testaktivitäten definiert. +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. Datenbankoperationen, API-Eingabevalidierung und +getestet. Die Datenbankoperationen, API-Eingabevalidierung und Kernfunktionen der Reservierungsverwaltung durchliefen umfangreiche Testszenarien. Besondere Aufmerksamkeit galt der -Smart-Plug-Kommunikation mit simulierten Netzwerkausfällen und -Timeout-Situationen. +Smart-Plug-Kommunikation, für die spezielle Testfälle entwickelt wurden +– einschließlich simulierter Netzwerkausfälle und Timeout-Situationen; +Szenarien, die sich später als prophetisch erweisen sollten. -Die Integrationstests gestalteten sich komplex. Das Zusammenspiel -zwischen Backend und Smart-Plugs erwies sich als fehleranfällig bei -gleichzeitigen Zugriffen. Systematische Tests mit verschiedenen -Eingabedaten deckten mehrere Sicherheitslücken auf, die nachträglich -geschlossen wurden. +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; ein +demütigender, aber lehrreicher Prozess. Systemtests bildeten komplette Anwendungsszenarien ab. Ein typischer -Testfall umfasste Benutzeranmeldung, Reservierungserstellung, -automatische Druckeraktivierung und anschließende Deaktivierung. Die -zeitliche Präzision der Schaltungen wurde dabei besonders überwacht. +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 offenbarten die Limitierungen des ursprünglich -geplanten Raspberry Pi 4. Der Wechsel auf den Pi 5 löste diese Probleme. -Die finale Konfiguration bewältigte simultane Zugriffe mehrerer Nutzer -und parallele Smart-Plug-Operationen ohne Einbußen. +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 – +ein Triumph der Optimierung. ## 2.4 Bewertung der heterogenen IT-Landschaft -Die IT-Landschaft der TBA präsentierte sich als heterogene Umgebung mit -verschiedenen Technologien. Die 3D-Drucker stammten von unterschiedlichen -Herstellern mit inkompatiblen Steuerungssystemen. Das Netzwerk war in -multiple VLANs segmentiert. +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 – +ein digitales Labyrinth ohne Ariadnefaden. Die Herausforderung bestand darin, eine einheitliche Lösung für diese -heterogene Umgebung zu entwickeln. Der Ansatz über Smart-Plugs -abstrahierte die Unterschiede zwischen den Druckern auf die einfachste -Ebene: Stromversorgung. Diese Vereinfachung ermöglichte eine universelle -Lösung, unabhängig vom Druckermodell. +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; ein Paradebeispiel für das +KISS-Prinzip in Aktion. Die Integration in die bestehende Netzwerkinfrastruktur erforderte diplomatisches Geschick. Die IT-Abteilung bestand auf strikter -Segmentierung. Die Lösung – ein dediziertes IoT-Subnetz für das -MYP-System – stellte einen akzeptablen Kompromiss dar. +Segmentierung, was die Kommunikation zwischen Komponenten +verkomplizierte. Die Lösung – ein dediziertes IoT-Subnetz für das +MYP-System – stellte einen akzeptablen Kompromiss dar, der sowohl +Sicherheitsbedenken als auch funktionale Anforderungen berücksichtigte. ## 2.5 Anforderungsgerechte Auswahl der Übertragungssysteme -Die Auswahl der Übertragungssysteme wurde durch die -Sicherheitsanforderungen bestimmt. Cloud-basierte Lösungen schieden aus. -Die Entscheidung für lokale HTTP/HTTPS-Kommunikation mit -selbstsignierten Zertifikaten war pragmatisch und effektiv. +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 – eine Notlösung, die zur +Dauerlösung wurde. Die Kommunikation mit den Smart-Plugs erfolgte über das proprietäre -TP-Link-Protokoll. Die anfänglichen Versuche mit der offiziellen -Cloud-API scheiterten an den Sicherheitsrichtlinien. Die lokale API der -Geräte erforderte erheblichen Reverse-Engineering-Aufwand. +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. -Mit Wireshark analysierte ich den Netzwerkverkehr der TAPO-App. Die -Erkenntnis, dass ein Session-Key erforderlich war, der sich bei jeder -Anmeldung änderte, verkomplizierte die Integration. Nach tagelangen -Experimenten fand ich ein alternatives Python-Modul auf GitHub, das die -lokale Kommunikation ermöglichte und die Session-Key-Problematik elegant -löste. +Hier kam Wireshark ins Spiel; mein digitales Stethoskop, wenn man so +will. 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; ein Fund, der mich vor Freude fast hätte tanzen +lassen. ## 2.6 Planung der Prozess-/ und Systemschnittstellen -Die Schnittstellenplanung erforderte eine 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 und implementiert. +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; jeder Endpunkt ein kleines Kunstwerk der Funktionalität. Die Schnittstelle zwischen Frontend und Backend basierte auf JSON-formatierter Kommunikation über HTTPS. Die Implementierung von -CORS-Policies gestaltete sich komplex aufgrund der strikten -Sicherheitsrichtlinien. Eine Whitelist-basierte CORS-Konfiguration -erfüllte die Anforderungen ohne Funktionseinschränkungen. +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; ein +Drahtseilakt zwischen Sicherheit und Usability. -Der als eigenständiger Thread implementierte Scheduler musste nahtlos mit -der Hauptanwendung kommunizieren. Die Verwendung von thread-sicheren -Queues und explizitem Locking verhinderte Race Conditions und Deadlocks. +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 – eine Lösung, die in ihrer +Eleganz bestach. ## 2.7 Planung der IT-Sicherheitsmaßnahmen -Die Sicherheitsplanung folgte dem Prinzip "Security by Design". Jede -Komponente wurde von Anfang an mit Sicherheit im Fokus entwickelt. +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; Paranoia als Tugend, wenn man so will. -Die Authentifizierung basierte auf bcrypt mit einem Cost-Faktor von 12. +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. Eine -Brute-Force-Protection mit exponentieller Backoff-Strategie verhinderte -automatisierte Angriffe. +konfigurierbaren Timeout-Werten und sicheren Session-Cookies. Die +Implementierung einer Brute-Force-Protection mit exponentieller +Backoff-Strategie verhinderte automatisierte Angriffe; ein digitaler +Türsteher, der keine Kompromisse kannte. 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. +ermöglichte granulare Kontrolle über den Netzwerkverkehr – eine +Festung aus Bits und Bytes. 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. +überwachte verdächtige Aktivitäten und sperrte bei Bedarf IP-Adressen +temporär – Big Brother im Dienste der Sicherheit. # 3. Durchführung und Auftragsbearbeitung ## 3.1 Prozess-Schritte und Vorgehensweise -Die Durchführung des Projekts erforderte kontinuierliche Anpassungen an -technische Herausforderungen. Die ursprünglich geplante lineare -Vorgehensweise wich einer iterativen, problemgetriebenen -Herangehensweise. +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 – Agilität nicht als +Methode, sondern als Überlebensstrategie. ### 3.1.1 Datenabfrage der Sensoren -Die Smart-Plugs fungierten als "Sensoren" im System. Die initiale -Annahme, dass die PyP100-Bibliothek funktionieren würde, erwies sich als -falsch. +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 mit der dokumentierten Cloud-API scheiterte an den -Sicherheitsrichtlinien. Der zweite Ansatz der direkten lokalen -Kommunikation scheiterte an fehlender Dokumentation. Erst das Reverse -Engineering mittels Wireshark führte zum Erfolg. +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; ein Prozess, der mich die Kunst der Paketanalyse lehrte. Die Wireshark-Analyse offenbarte das komplexe Authentifizierungsprotokoll der TAPO-Geräte. Jede Kommunikation -erforderte einen verschlüsselten Handshake mit Session-Token. Die -Verschlüsselung basierte auf RSA und AES. +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 finale Implementierung erfolgte über eine selbstentwickelte -Wrapper-Klasse, die die Kommunikationskomplexität kapselte. -Retry-Mechanismen mit exponentieller Backoff-Strategie sorgten für -Robustheit. Die Abfrage umfasste Schaltzustand, Energieverbrauch und -Signalstärke. +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 Smart-Plug-Operationen. +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 – ein Tanz zwischen zwei Welten. Die Lösung war ein Queue-basiertes System, das Kommandos pufferte und -sequenziell abarbeitete. Dies verhinderte Race Conditions und -gewährleistete Systemkonsistenz. Jede Operation wurde in einer -Transaktion gekapselt mit Rollback-Mechanismen. +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 – Atomarität als oberstes Gebot. -Die Verarbeitung der Energiedaten ermöglichte Einblicke in -Nutzungsmuster. Anomalien wie ungewöhnlich hoher Stromverbrauch konnten -erkannt werden. Diese ursprünglich nicht geplante Funktion erwies sich -als wertvoll für die präventive Wartung. +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; +ein glücklicher Zufall, der zur Kernfunktionalität wurde. ## 3.2 Abweichung, Anpassung und Entscheidungen -Die Projektdurchführung war geprägt von kontinuierlichen Anpassungen. Die -größte Abweichung war der Wechsel von einer verteilten zu einer -konsolidierten Systemarchitektur. +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 – eine Entscheidung, die aus der Not geboren +wurde. -Ursprünglich sollte nur die API entwickelt und mit dem Frontend auf -separaten Raspberry Pis verknüpft werden. Die unterschiedlichen -Technologie-Stacks und die Netzwerksegmentierung machten die Integration -jedoch zu komplex. Die Konsolidierung auf einem einzigen Raspberry Pi -vereinfachte die Architektur erheblich. +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; manchmal ist weniger +tatsächlich mehr. Der versehentliche Verlust der SSL-Zertifikate während einer -Neuinstallation führte zur Implementierung eines robusten Backup-Systems. -Kritische Konfigurationsdateien werden nun dreifach gesichert. +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; Paranoia als Versicherung. -Die Entscheidung, von PyP100 zu einem alternativen Modul zu wechseln, -fiel nach tagelangen fruchtlosen Debugging-Sessions. Das gefundene -alternative Modul war simpler und stabiler. +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; ein Beweis dafür, dass der einfachste Weg oft der beste ist. ## 3.3 Maßnahmen zur Qualitätskontrolle -Die Qualitätskontrolle erfolgte kontinuierlich. Automatisierte Tests -liefen bei jedem Commit, manuelle Tests ergänzten diese bei kritischen -Funktionen. +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 – ein Problem, das +kreative Lösungen erforderte. Mock-Objekte simulierten die Smart-Plugs für Unit-Tests. Diese Mocks -replizierten das Verhalten der echten Hardware inklusive typischer -Fehlerszenarien. Die Test-Coverage erreichte 85%. +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, deren Test-Aufwand in keinem vernünftigen +Verhältnis zum Nutzen stand. Integrationstests mit echter Hardware deckten Probleme auf, die in der -Simulation nicht auftraten: Timing-Issues, Memory-Leaks, Race -Conditions. Alle Probleme wurden iterativ behoben. +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; ein Prozess, der Geduld und Durchhaltevermögen erforderte. -Die Implementierung eines umfassenden Logging-Systems erwies sich als -unschätzbar wertvoll. Jede Operation wurde protokolliert. Die -Log-Analyse wurde zum wichtigsten Debugging-Tool. +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 – digitale Forensik +im Kleinen. ## 3.4 Implementierung, Konfiguration und Inbetriebnahme von Schnittstellen und unterschiedlicher Prozesse und Systeme -Die Implementierung der Schnittstellen erfolgte modular. Die REST-API -wurde Blueprint-basiert strukturiert mit klarer Trennung der -Funktionsbereiche: Authentication, User Management, Printer Management -und Job Management. +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 – eine Architektur, die Ordnung ins Chaos brachte. Die Smart-Plug-Schnittstelle durchlief mehrere Iterationen. Die finale -Implementation kapselte die Kommunikationslogik in einer einzigen Klasse -mit simpler API: turn_on(), turn_off(), get_status(). +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 – +Simplizität als Designprinzip. -Die Datenbank-Schnittstelle nutzte SQLAlchemy's ORM-Funktionalität. -Models wurden deklarativ definiert, Migrationen über Alembic verwaltet. -SQLite als Datenbank war perfekt für die Offline-Anforderung. +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; manchmal ist die einfachste Lösung die +beste. Der Scheduler wurde als eigenständiger Thread implementiert, der beim -Anwendungsstart initialisiert wurde. Thread-sichere Queues ermöglichten -asynchrone Hardware-Operationen ohne Blockierung der Web-Requests. +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 – Parallelität ohne Kopfschmerzen. ## 3.5 Konfiguration von Übertragungssystemen und Integration in die Gesamtinfrastruktur Die Integration in die Mercedes-Benz-Infrastruktur erforderte zahlreiche -Kompromisse. Das dedizierte IoT-Subnetz wurde speziell für das -MYP-System eingerichtet mit restriktiven Firewall-Regeln. +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 – eine digitale Quarantäne, die +Sicherheit gewährleistete. Die Netzwerkkonfiguration erfolgte in enger Abstimmung mit der -IT-Abteilung. Jede Änderung erforderte ein Change-Request. Der -bürokratische Overhead war erheblich aber notwendig. +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 – ein notwendiges Übel im +Konzernumfeld. -Die SSL-Konfiguration mit selbstsignierten Zertifikaten war notwendig -mangels Internet-Zugang. Die Zertifikate wurden mit allen relevanten -SANs generiert. Browser-Warnungen wurden durch eine dokumentierte -Installationsprozedur umgangen. +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 – nicht elegant, aber funktional. -Die Smart-Plugs erhielten statische IP-Adressen, da DHCP-Reservierungen -nicht vorgesehen waren. Die manuelle Konfiguration war aufwändig, -gewährleistete aber stabile Verbindungen. +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; manchmal ist der steinige Weg der sicherste. ## 3.6 Erfüllen der Anforderungen an die Informationssicherheit -Die Informationssicherheit wurde als kritischer Erfolgsfaktor behandelt. -Jede Designentscheidung wurde unter Sicherheitsaspekten betrachtet. +Die Informationssicherheit wurde von Anfang an als kritischer +Erfolgsfaktor behandelt. Jede Designentscheidung wurde durch die +Sicherheitsbrille betrachtet, jede Implementierung auf Schwachstellen +geprüft – Security als Religion, nicht als Afterthought. 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. +Input-Validation erfolgte auf mehreren Ebenen – Client-seitig für UX, +Server-seitig für Sicherheit; Vertrauen ist gut, Kontrolle ist besser. -Ein Rate-Limiter verhinderte Brute-Force-Angriffe. Nach fünf -fehlgeschlagenen Login-Versuchen wurde die IP-Adresse für 30 Minuten -gesperrt. +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; ein Balanceakt zwischen Sicherheit und +Benutzerfreundlichkeit. -DSGVO-Compliance wurde durch Privacy-by-Design erreicht. Personenbezogene -Daten wurden minimiert, Löschfristen implementiert, +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. +anonymisierte IP-Adressen nach 30 Tagen automatisch – Datenschutz nicht +als Pflicht, sondern als Selbstverständlichkeit. # 4. Projektabschluss ## 4.1 Soll-Ist-Vergleich (Abweichung, Anpassungen) -Der Vergleich zwischen geplanten und erreichten Zielen zeigt ein -positives Gesamtbild. Die Kernfunktionalität wurde vollständig -implementiert und übertraf in einigen Aspekten die ursprünglichen -Anforderungen. +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; ein Erfolg, der süßer schmeckt, weil +er hart erkämpft wurde. #### Erfolgreich umgesetzte Anforderungen: @@ -665,99 +813,120 @@ Anforderungen. - Konsolidierung auf einen statt zwei Raspberry Pis - Wechsel von PyP100 zu alternativem Kommunikationsmodul -- Kein Touch-Display implementiert -- Verschiebung der Benutzerschulungen +- Hardware-Upgrade vom Pi 4 auf Pi 5 +- 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. +ermöglicht detaillierte Einblicke in Nutzungsmuster und Energieverbrauch +– wertvolle Daten für die Optimierung des Druckerbetriebs; ein Feature, +das aus der Not geboren wurde und zum Alleinstellungsmerkmal avancierte. -Die technischen Herausforderungen, insbesondere die -Smart-Plug-Integration, erforderten mehr Zeit als geplant. Die -investierte Mühe zahlte sich jedoch in einer robusten und -wartungsfreundlichen Lösung aus. +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; Qualität setzt sich durch, auch wenn der Weg steinig ist. ## 4.2 Fazit -Das MYP-Projekt demonstriert, wie durch kreative Ansätze und technisches -Geschick aus scheinbar unüberwindbaren Hindernissen elegante Lösungen -entstehen. Die Transformation eines analogen Whiteboards in ein modernes -cyber-physisches System mag trivial erscheinen – die Umsetzung -offenbarte jedoch die volle Komplexität vernetzter Systeme. +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; ein Eisberg, dessen Spitze täuscht. Die Entscheidung, die fehlenden Schnittstellen der 3D-Drucker durch -Smart-Plugs zu überbrücken, erwies sich als optimal. Diese Abstraktion -auf die grundlegendste Ebene – Stromversorgung – ermöglichte eine -universelle, herstellerunabhängige Lösung. +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 laterales Denken, +das komplexe Probleme durch Perspektivwechsel löst. -Die technische Exzellenz zeigt sich in den Details: Über 9.000 Zeilen -strukturierter Python-Code, eine umfassende REST-API, robuste -Fehlerbehandlung und durchdachte Sicherheitsarchitektur. Der wahre -Erfolg liegt jedoch in der Praxistauglichkeit – das System läuft stabil -und hat das manuelle Chaos beendet. +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; +ein digitaler Phönix, der aus der Asche des Whiteboards aufstieg. -Persönlich war das Projekt eine intensive Lernerfahrung. Von der -anfänglichen Euphorie über frustrierende Debugging-Sessions bis zum -finalen Erfolg – jede Phase bot wertvolle Erkenntnisse. Die Fähigkeit, -unter Zeitdruck pragmatische Entscheidungen zu treffen ohne die Qualität -zu kompromittieren, war die wichtigste erworbene Kompetenz. +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; eine +Lektion, die über das Projekt hinaus Bestand haben wird. ## 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. +zusätzlicher Funktionalitäten ohne grundlegende Systemänderungen – ein +Fundament, auf dem aufgebaut werden kann. 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. +Integration, sobald die erforderlichen Genehmigungen vorliegen. Diese +Erweiterung würde die Benutzerverwaltung erheblich vereinfachen und die +Akzeptanz im Unternehmensumfeld steigern. Mittelfristig könnte bei Verfügbarkeit modernerer 3D-Drucker eine direkte Geräteintegration realisiert werden. Die Einbindung von -OctoPrint würde erweiterte Funktionen wie Druckfortschrittsüberwachung -ermöglichen. +OctoPrint oder vergleichbaren Systemen würde erweiterte Funktionen wie +Druckfortschrittsüberwachung und Remote-Dateiverwaltung ermöglichen – +Features, die das System auf ein neues Level heben würden. Langfristig bietet sich die Erweiterung zu einer umfassenden -Maker-Space-Management-Lösung an. Die Architektur unterstützt die -Integration weiterer Gerätetypen. Machine-Learning-Algorithmen könnten -für Auslastungsprognosen implementiert werden. +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 – +die Möglichkeiten sind grenzenlos. ## 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. +Deep-Dive-Session für interessierte Kollegen – ein Moment der Wahrheit. -Bei der Live-Demonstration kam es zunächst zu einem Missverständnis -bezüglich der Systemkonfiguration, da das System noch nicht vollständig -produktiv aufgebaut war – letzte Hardware-Komponenten waren noch in der -Lieferung. Dank der robusten Systemarchitektur konnte ich jedoch aus dem -Stegreif improvisieren und das System sofort demonstrieren. Die -automatische Aktivierung eines 3D-Druckers zur reservierten Zeit -funktionierte einwandfrei und löste sichtbare Begeisterung aus. +Die Live-Demonstration begann mit einem kleinen Missverständnis: Das +System war noch nicht vollständig produktiv aufgebaut, da letzte +Hardware-Komponenten sich noch in der Lieferung befanden. Doch hier +zeigte sich die wahre Stärke der Architektur – dank der robusten +Systemkonzeption konnte ich aus dem Stegreif improvisieren und das +System dennoch eindrucksvoll demonstrieren. Die automatische Aktivierung +eines 3D-Druckers zur reservierten Zeit funktionierte einwandfrei und +löste sichtbare Begeisterung aus; ein Moment, der die monatelange Arbeit +rechtfertigte. -Besonders positiv wurde die Wirtschaftlichkeit bewertet. Mit -Gesamtkosten unter 600 Euro liegt das System weit unter kommerziellen -Alternativen. Die Einsparungen durch automatisierte Abschaltung -amortisieren die Investition binnen weniger Monate. +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 – ein Argument, das bei der +Geschäftsführung Anklang fand. Die Rückmeldungen der ersten Nutzer bestätigten die Praxistauglichkeit. -Die intuitive Bedienung, zuverlässige Funktion und Eliminierung von -Reservierungskonflikten wurden besonders gelobt. Kleinere UX-Details -wurden dokumentiert für zukünftige Updates. +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; kontinuierliche Verbesserung als +Prinzip. 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. +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 -technischer Finesse auch scheinbar unlösbare Probleme gemeistert werden -können. +– 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