📚 Updated IHK documentation files: renamed and moved to backup_ihk_docs folder; added new images for improved visuals. 🎨🖌️
This commit is contained in:
parent
f641b6c060
commit
487d0a75f1
@ -1,264 +1,357 @@
|
||||
# MYP – Manage Your Printer
|
||||
# Projektdokumentation zur IHK-Abschlussprüfung
|
||||
|
||||
**Digitalisierung des 3D-Drucker-Reservierungsprozesses durch Etablierung der cyberphysischen Kommunikation mit relevanten Hardwarekomponenten**
|
||||
|
||||
**Abschlussprüfung – Sommer 2025**
|
||||
|
||||
**Fachinformatiker für digitale Vernetzung**
|
||||
|
||||
**Abgabedatum: 5. Juni 2025**
|
||||
**MYP – Manage Your Printer**
|
||||
*Digitalisierung des 3D-Drucker-Reservierungsprozesses durch Etablierung der cyberphysischen Kommunikation mit relevanten Hardwarekomponenten*
|
||||
|
||||
---
|
||||
|
||||
## Ausbildungsbetrieb
|
||||
**Prüfungsteilnehmer:** Till Tomczak
|
||||
**Ausbildungsberuf:** Fachinformatiker für digitale Vernetzung
|
||||
**Prüfungstermin:** Sommer 2025
|
||||
**Abgabedatum:** 5. Juni 2025
|
||||
|
||||
**Mercedes-Benz AG**
|
||||
|
||||
Daimlerstraße 143
|
||||
|
||||
D-12277 Berlin
|
||||
|
||||
---
|
||||
|
||||
## Prüfungsbewerber
|
||||
|
||||
**Till Tomczak**
|
||||
|
||||
Hainbuchenstraße 19
|
||||
|
||||
D-16761 Hennigsdorf
|
||||
**Ausbildungsbetrieb:**
|
||||
Mercedes-Benz AG
|
||||
Daimlerstraße 143
|
||||
D-12277 Berlin
|
||||
|
||||
---
|
||||
|
||||
## Inhaltsverzeichnis
|
||||
|
||||
1. Einleitung und Projektanalyse
|
||||
2. Projektplanung und Ressourcenmanagement
|
||||
3. Durchführung und technische Implementierung
|
||||
4. Projektabschluss und Bewertung
|
||||
1. Einleitung
|
||||
- 1.1 Analyse des Projektauftrags
|
||||
- 1.2 Ableitung der Projektziele
|
||||
- 1.3 Projektabgrenzung
|
||||
- 1.4 Projektumfeld
|
||||
- 1.5 Betriebliche Schnittstellen
|
||||
- 1.6 Analyse der IT-sicherheitsrelevanten Bedingungen
|
||||
- 1.7 Darstellung der vorhandenen Systemarchitektur
|
||||
|
||||
2. Projektplanung
|
||||
- 2.1 Terminplanung
|
||||
- 2.2 Ressourcenplanung
|
||||
- 2.3 Planung der Qualitätssicherung
|
||||
- 2.4 Bewertung der heterogenen IT-Landschaft
|
||||
- 2.5 Anforderungsgerechte Auswahl der Übertragungssysteme
|
||||
- 2.6 Planung der Prozess-/und Systemschnittstellen
|
||||
- 2.7 Planung der IT-Sicherheitsmaßnahmen
|
||||
|
||||
3. Durchführung und Auftragsbearbeitung
|
||||
- 3.1 Prozess-Schritte und Vorgehensweise
|
||||
- 3.1.1 Datenabfrage der Sensoren
|
||||
- 3.1.2 Verarbeiten der Daten
|
||||
- 3.2 Abweichung, Anpassung und Entscheidungen
|
||||
- 3.3 Maßnahmen zur Qualitätskontrolle
|
||||
- 3.4 Implementierung, Konfiguration und Inbetriebnahme von Schnittstellen und unterschiedlicher Prozesse
|
||||
- 3.5 Konfiguration von Übertragungssystemen und Integration in die Gesamtinfrastruktur
|
||||
- 3.6 Erfüllen der Anforderungen an die Informationssicherheit
|
||||
|
||||
4. Projektabschluss
|
||||
- 4.1 Soll-Ist-Vergleich (Abweichung, Anpassungen)
|
||||
- 4.2 Fazit
|
||||
- 4.3 Optimierungsmöglichkeiten
|
||||
- 4.4 Abnahme
|
||||
|
||||
---
|
||||
|
||||
# 1. Einleitung und Projektanalyse
|
||||
# 1. Einleitung
|
||||
|
||||
## 1.1 Ausgangssituation und Problemstellung
|
||||
## 1.1 Analyse des Projektauftrags
|
||||
|
||||
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.
|
||||
Die Technische Berufsausbildungsstätte (TBA) der Mercedes-Benz AG am Standort Berlin verfügt über sechs 3D-Drucker verschiedener Hersteller – Prusa und Anycubic, die man durchaus als B-Ware im Vergleich zu den hochpreisigen Industriedruckern anderer Kostenstellen bezeichnen könnte. Diese Geräte, so essentiell sie für die praktische Ausbildung auch sein mögen, weisen erhebliche technische Limitierungen auf; weder Funk- noch Netzwerkschnittstellen sind vorhanden, geschweige denn andere gesamteinheitliche Steuerungsmöglichkeiten. Diese technischen Einschränkungen verhinderten bislang eine koordinierte digitale Verwaltung und die damit einhergehende Übersicht von Reservierungen und Nutzungsplänen der Auszubildenden – ein Zustand, der im Jahr 2025 geradezu anachronistisch anmutet.
|
||||
|
||||
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.
|
||||
Das bestehende 'Reservierungssystem' – wenn man es denn überhaupt so nennen möchte – basierte auf einem analogen Whiteboard, welches neben den Druckern positioniert war. Dies führte zu systematischen Problemen, die sich als Kaskade des Chaos durch den Ausbildungsalltag zogen: Doppelbuchungen traten regelmäßig auf, wenn mehrere Nutzer zeitgleich ihre Reservierungen einzutragen versuchten; 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 schlichtweg nicht, wodurch weder aussagekräftige Betätigungs- und Verantwortungszuordnung (beispielsweise für die notwendigen Aufräumarbeiten nach Druckprozessen), 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.
|
||||
Ein erstmaliger Lösungsansatz durch den ehemaligen Auszubildenden Torben Haack hatte einen durchaus vielversprechenden Frontend-Prototyp auf Basis von Next.js hervorgebracht. Der Prototyp verfügte über eine moderne, ansprechende Benutzeroberfläche und beeindruckende Analysefunktionen – allerdings fehlte ganz fundamental die essentielle Backend-Funktionalität; ohne diese blieb die auf dem Prototypen basierende Projektarbeit des Herrn Haack in der praktischen Anwendung ohne jegliche Funktion, ein digitales Potemkinsches Dorf sozusagen. Ich erkannte für mich 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. Im Gegensatz zu anderen Projektmöglichkeiten, die sich mir boten und bei denen ich eine gewisse Obligation verspürte, fühlte ich hier einen Anflug von Ideen, Tatendrang und intrinsischer Motivation – es kitzelte, um es poetisch auszudrücken, meine technische Leidenschaft.
|
||||
|
||||
## 1.2 Projektauftrag und Zielsetzung
|
||||
## 1.2 Ableitung der Projektziele
|
||||
|
||||
Nach erfolgter Zulassung des Abschlussprojekts durch die IHK erhielt ich den Auftrag, den bestehenden Prototyp zu einer vollständigen cyber-physischen Lösung weiterzuentwickeln. Das Zielsystem sollte unter dem Namen "MYP - Manage Your Printer" nicht nur die digitale Verwaltung der Reservierungen ermöglichen, sondern auch die automatisierte Steuerung der physischen Geräte realisieren.
|
||||
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 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 Ansatz zur Hardware-Steuerung entwickelt werden. Gleichzeitig waren die strengen Sicherheitsrichtlinien der Mercedes-Benz AG zu berücksichtigen, die keine permanenten Internetverbindungen in der Produktionsumgebung gestatten.
|
||||
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 Projektziel war die Gewährleistung der Herstellerunabhängigkeit. Die heterogene Druckerlandschaft mit sechs unterschiedlichen Modellen erforderte eine universell einsetzbare Lösung. Das System sollte zudem eine differenzierte Rechteverwaltung implementieren, die zwischen administrativen Funktionen und regulären Nutzerrechten unterscheidet.
|
||||
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 Lösungskonzept und technische Architektur
|
||||
## 1.3 Projektabgrenzung
|
||||
|
||||
Die Analyse der technischen Rahmenbedingungen führte zu einem innovativen Lösungsansatz: Statt einer direkten Steuerung der 3D-Drucker erfolgt die Kontrolle über intelligente Zwischensteckdosen (Smart-Plugs). Als Hardware-Komponente wurden TP-Link Tapo P110 Smart-Plugs ausgewählt, die über eine lokale API verfügen und somit ohne Cloud-Anbindung steuerbar sind. Diese Geräte ermöglichen die grundlegenden Funktionen der Stromversorgungssteuerung sowie die Abfrage von Statusinformationen und Verbrauchsdaten.
|
||||
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.
|
||||
|
||||
Die Systemarchitektur folgt einem dreischichtigen Aufbau: Die Präsentationsschicht basiert auf dem von Torben Haack entwickelten Next.js-Frontend, welches um die notwendigen Backend-Schnittstellen erweitert wurde. Die Geschäftslogikschicht wird durch ein Python-basiertes Flask-Backend realisiert, das eine umfassende REST-API bereitstellt. Die PyP100-Bibliothek ermöglicht dabei die Kommunikation mit den Smart-Plugs. Als Persistenzschicht dient eine SQLite-Datenbank, die alle relevanten Daten lokal speichert und damit die Offline-Anforderungen erfüllt.
|
||||
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.
|
||||
|
||||
Ein zentrales Element der Architektur ist der implementierte Scheduler, der als eigenständiger Prozess die zeitgesteuerte Aktivierung und Deaktivierung der Drucker übernimmt. Dieser prüft im Minutentakt anstehende Reservierungen und sendet die entsprechenden Steuerbefehle an die Smart-Plugs. Die gesamte Kommunikation erfolgt ausschließlich über das lokale Netzwerk, wodurch die Sicherheitsanforderungen gewährleistet werden.
|
||||
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 und Rahmenbedingungen
|
||||
## 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 fachliche Unterstützung der Ausbildungsleitung.
|
||||
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.
|
||||
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.
|
||||
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 Projektabgrenzung
|
||||
## 1.5 Betriebliche Schnittstellen
|
||||
|
||||
Der Projektumfang wurde bewusst auf die praktische Umsetzung einer funktionsfähigen Lösung fokussiert. Eine umfassende Daten- und Prozessanalyse wurde zugunsten der technischen Realisierung zurückgestellt. Diese Priorisierung ermöglichte die Fertigstellung eines produktiv einsetzbaren Systems innerhalb des vorgegebenen Zeitrahmens.
|
||||
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.
|
||||
|
||||
Eine direkte Kommunikation mit den 3D-Druckern zur Übertragung von Druckdaten oder zur Statusüberwachung wurde 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. Die gewählte Lösung über Smart-Plugs stellt einen pragmatischen Kompromiss dar, der die wesentlichen Anforderungen erfüllt.
|
||||
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.
|
||||
|
||||
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 überschritten hätten. Stattdessen wurde eine autarke Lösung entwickelt, die alle erforderlichen Funktionen lokal bereitstellt.
|
||||
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.
|
||||
|
||||
# 2. Projektplanung und Ressourcenmanagement
|
||||
## 1.6 Analyse der IT-sicherheitsrelevanten Bedingungen
|
||||
|
||||
## 2.1 Methodisches Vorgehen und Projektorganisation
|
||||
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.
|
||||
|
||||
Für die Projektdurchführung wurde ein agiler Entwicklungsansatz nach Scrum-Prinzipien gewählt. Die Gesamtprojektdauer von fünf Wochen (15. April bis 20. Mai 2025) wurde in fünf einwöchige Sprints unterteilt. Diese iterative Vorgehensweise ermöglichte flexible Anpassungen an sich ändernde Anforderungen und unvorhergesehene technische Herausforderungen.
|
||||
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.
|
||||
|
||||
**Sprint 1 (15.-19. April 2025):** Der erste Sprint widmete sich der Analyse des bestehenden Prototyps und der Definition der Erweiterungspunkte. Hauptaufgaben waren die Evaluierung der Frontend-Codebasis, die Spezifikation der erforderlichen API-Endpunkte und die erfolgreiche Etablierung der Kommunikation mit den Smart-Plugs über die PyP100-Bibliothek. Der erfolgreiche Verbindungsaufbau zu den Geräten stellte einen kritischen Meilenstein 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.
|
||||
|
||||
**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 zeitintensiver Prozess. Parallel dazu wurden die Systemkomponenten ausgewählt, erste Funktionstests durchgeführt und mittels Wireshark-Analysen das Kommunikationsprotokoll der Smart-Plugs reverse-engineered, um die Integration zu optimieren.
|
||||
## 1.7 Darstellung der vorhandenen Systemarchitektur
|
||||
|
||||
**Sprint 3 (29. April - 3. Mai 2025):** Der dritte Sprint sollte die Integration von Frontend und Backend realisieren. Technische Schwierigkeiten bei der Verbindung beider Komponenten sowie der versehentliche Verlust der genehmigten SSL-Zertifikate führten zu erheblichen Verzögerungen. Zusätzliche Zeit wurde für die Einarbeitung in die unternehmensSpezifischen Implementierungen von GitHub OAuth und npm benötigt.
|
||||
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.
|
||||
|
||||
**Sprint 4 (6.-10. Mai 2025):** Ursprünglich für Optimierungen vorgesehen, wurde dieser Sprint zur Entwicklung einer funktionsfähigen Gesamtlösung umgewidmet. Der Zeitdruck erforderte pragmatische Entscheidungen und die Konzentration auf essenzielle Funktionen. Die Implementierung erfolgte in intensiven Entwicklungssessions mit dem Ziel, ein lauffähiges System zu erstellen.
|
||||
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.
|
||||
|
||||
**Sprint 5 (13.-17. Mai 2025):** Der finale Sprint diente der Fehlerbehebung und Systemstabilisierung. Die ursprünglich geplanten Schulungen wurden zugunsten der technischen Fertigstellung zurückgestellt. Die verbleibende Zeit wurde für kritische Bugfixes und die Erstellung der Projektdokumentation genutzt.
|
||||
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.2 Ressourcenplanung und Infrastruktur
|
||||
# 2. Projektplanung
|
||||
|
||||
Die Hardware-Ausstattung wurde basierend auf den Projektanforderungen sorgfältig ausgewählt. Als zentrale Serverplattform kam ein Raspberry Pi 5 mit 8 GB RAM zum Einsatz. Die Entscheidung gegen den ursprünglich geplanten Raspberry Pi 4 basierte auf Performance-Tests, die zeigten, dass das Next.js-Frontend höhere Rechenleistung erforderte als initial angenommen. Die Speicherausstattung wurde auf 128 GB erweitert, um ausreichend Kapazität für die Offline-Installation des Frontends, Datenbankwachstum und regelmäßige Backups zu gewährleisten.
|
||||
## 2.1 Terminplanung
|
||||
|
||||
Die sechs TP-Link Tapo P110 Smart-Plugs bildeten die zentrale Hardware-Schnittstelle zu den 3D-Druckern. Jedes Gerät erhielt eine statische IP-Adresse im Bereich 192.168.0.151 bis 192.168.0.156, was die Verwaltung und Fehlerdiagnose erheblich vereinfachte. Die Konfiguration erfolgte so, dass die Geräte ausschließlich im lokalen Netzwerk erreichbar sind und keine Verbindung zu Cloud-Diensten aufbauen.
|
||||
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.
|
||||
|
||||
Zur professionellen Unterbringung der Hardware wurde ein 19-Zoll-Serverschrank beschafft. Aufgrund langwieriger interner Beschaffungsprozesse wurden ergänzende Komponenten wie Lüftereinheiten und Kabelmanagement-Systeme privat finanziert. Diese Investition diente der professionellen Präsentation und optimalen Betriebsbedingungen des Systems.
|
||||
**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.
|
||||
|
||||
Die Software-Architektur basiert 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ährleistet Unabhängigkeit von proprietären Lösungen und erfüllt die Offline-Anforderungen des Projekts.
|
||||
**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.
|
||||
|
||||
## 2.3 Qualitätssicherung und Testkonzept
|
||||
**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.
|
||||
|
||||
Das Qualitätssicherungskonzept orientierte sich am V-Modell und sah für jede Entwicklungsphase korrespondierende Testaktivitäten vor. Die systematische Testdurchführung gewährleistete die Funktionsfähigkeit und Robustheit des Systems.
|
||||
**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.
|
||||
|
||||
Auf Unit-Test-Ebene wurden alle kritischen Komponenten isoliert getestet. Dies umfasste Datenbankoperationen, API-Eingabevalidierung und die Kernfunktionen der Reservierungsverwaltung. Besondere Aufmerksamkeit galt der Smart-Plug-Kommunikation, für die umfangreiche Testszenarien entwickelt wurden, einschließlich Netzwerkausfällen und Timeout-Situationen.
|
||||
**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.
|
||||
|
||||
Die Integrationstests validierten das Zusammenspiel der Systemkomponenten. Schwerpunkte waren die Backend-Smart-Plug-Schnittstelle und die API-Kommunikation. Systematische Tests mit verschiedenen Eingabedaten, einschließlich invalider und potenziell schädlicher Inputs, stellten die Robustheit der Schnittstellen sicher.
|
||||
## 2.2 Ressourcenplanung
|
||||
|
||||
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 wurde dabei besonders überwacht.
|
||||
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.
|
||||
|
||||
Performance-Tests auf der Zielplattform bestätigten die ausreichende Leistungsfähigkeit des Raspberry Pi 5. Selbst bei simultanen Zugriffen mehrerer Nutzer und parallelen Smart-Plug-Operationen blieb die Systemperformance im akzeptablen Bereich.
|
||||
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.
|
||||
|
||||
## 2.4 Netzwerkarchitektur und Sicherheitskonzept
|
||||
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.
|
||||
|
||||
Die Integration in die Netzwerkinfrastruktur der Mercedes-Benz AG erforderte detaillierte Abstimmungen mit der IT-Abteilung. Das MYP-System wurde in einem dedizierten IoT-Subnetz (192.168.0.0/24) platziert, welches vom Produktionsnetzwerk isoliert ist. Diese Segmentierung gewährleistet erhöhte Sicherheit und verhindert unautorisierten Zugriff auf kritische Systeme.
|
||||
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.
|
||||
|
||||
Der Raspberry Pi Server erhielt die statische IP-Adresse 192.168.0.105. Die Firewall-Konfiguration wurde restriktiv gestaltet: Port 5000 für die Flask-Anwendung, Port 22 für SSH-Zugriffe (ausschließlich aus dem lokalen Subnetz) und Port 5443 für HTTPS-Verbindungen. Ausgehende Verbindungen wurden strikt auf die IP-Adressen der Smart-Plugs limitiert.
|
||||
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.
|
||||
|
||||
Für die verschlüsselte Kommunikation wurde ein selbstsigniertes SSL-Zertifikat implementiert. Trotz der Einschränkungen selbstsignierter Zertifikate stellen diese für isolierte Netzwerke ohne Internetzugang eine adäquate Lösung dar. Das Zertifikat wurde mit einjähriger Gültigkeit ausgestellt und enthält alle relevanten Hostnamen und IP-Adressen als Subject Alternative Names. Nach dem versehentlichen Verlust der ersten Zertifikatsgeneration wurde ein robustes Backup-Konzept implementiert.
|
||||
## 2.3 Planung der Qualitätssicherung
|
||||
|
||||
Die Authentifizierung basiert auf bcrypt-Hashing mit angemessenem Cost-Faktor. Nach fünf fehlgeschlagenen Anmeldeversuchen erfolgt eine 30-minütige Kontosperrung. Alle sicherheitsrelevanten Ereignisse werden in dedizierten Logdateien protokolliert und können für Sicherheitsaudits herangezogen werden.
|
||||
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.
|
||||
|
||||
# 3. Durchführung und technische Implementierung
|
||||
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.
|
||||
|
||||
## 3.1 Backend-Architektur und API-Design
|
||||
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.
|
||||
|
||||
Die Backend-Implementierung folgt einer modularen Architektur unter Verwendung des Flask-Blueprint-Systems. Diese Strukturierung ermöglicht eine klare Trennung der funktionalen Bereiche und erleichtert die Wartbarkeit des Systems. Die API wurde in vier Hauptmodule unterteilt: Authentication, User Management, Printer Management und Job Management.
|
||||
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.
|
||||
|
||||
Das Authentication-Modul implementiert die vollständige Benutzerverwaltung einschließlich Registrierung, Anmeldung und Session-Management. Passwörter werden mittels bcrypt gehasht und mit individuellem Salt gespeichert. Die Session-Verwaltung nutzt Flask-Login mit einer konfigurierten Ablaufzeit von acht Stunden. Zusätzliche Sicherheitsmaßnahmen umfassen CSRF-Protection und die Konfiguration sicherer Session-Cookies mit den Attributen Secure, HttpOnly und SameSite.
|
||||
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.
|
||||
|
||||
Das Job-Management-Modul bildet den funktionalen Kern des Systems. Der primäre Endpunkt POST /api/v1/jobs implementiert umfassende Validierungslogik, die Überschneidungen mit bestehenden Reservierungen verhindert und Berechtigungen prüft. Die Implementierung unterstützt erweiterte Funktionen wie die nachträgliche Modifikation von Reservierungen und vorzeitige Beendigung von Druckaufträgen. Diese Flexibilität erwies sich als essentiell für den praktischen Betrieb.
|
||||
## 2.4 Bewertung der heterogenen IT-Landschaft
|
||||
|
||||
Das Printer-Management-Modul verwaltet die Konfiguration der 3D-Drucker und ihrer zugeordneten Smart-Plugs. Neben grundlegenden Attributen wie Name und Standort werden die Netzwerkinformationen der Smart-Plugs (IP- und MAC-Adresse) gespeichert. Ein Status-Flag ermöglicht die temporäre Deaktivierung von Druckern für Wartungszwecke.
|
||||
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.
|
||||
|
||||
Das API-Design orientiert sich an REST-Prinzipien und implementiert über 100 spezifische Endpunkte. Diese umfassende API-Oberfläche gewährleistet die Abdeckung aller identifizierten Use-Cases und bietet Erweiterungsmöglichkeiten für zukünftige Anforderungen.
|
||||
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.
|
||||
|
||||
## 3.2 Smart-Plug-Integration und Hardware-Steuerung
|
||||
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.
|
||||
|
||||
Die Integration der TP-Link Tapo P110 Smart-Plugs stellte eine zentrale technische Herausforderung dar. Die PyP100-Bibliothek bot zwar grundlegende Funktionalität, erforderte jedoch erhebliche Anpassungen für den produktiven Einsatz. Durch Analyse des Netzwerkverkehrs mittels Wireshark konnten die Kommunikationsprotokolle verstanden und optimiert werden.
|
||||
## 2.5 Anforderungsgerechte Auswahl der Übertragungssysteme
|
||||
|
||||
Die entwickelte SmartPlugController-Klasse kapselt die Hardware-Kommunikation und implementiert robuste Fehlerbehandlung. Ein Retry-Mechanismus mit exponentiellem Backoff gewährleistet zuverlässige Kommunikation auch bei temporären Netzwerkproblemen. Nach drei erfolglosen Verbindungsversuchen wird der Fehler protokolliert und zur späteren Analyse gespeichert.
|
||||
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.
|
||||
|
||||
Das proprietäre Authentifizierungsprotokoll der Smart-Plugs erforderte besondere Aufmerksamkeit. Die Implementierung etabliert für jede Operation eine neue Verbindung, um Probleme mit Session-Timeouts zu vermeiden. Die Zugangsdaten werden verschlüsselt in der Systemkonfiguration gespeichert und nur bei Bedarf entschlüsselt.
|
||||
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.
|
||||
|
||||
Die Implementierung unterstützt drei Kernoperationen: Aktivierung, Deaktivierung und Statusabfrage. Die Statusabfrage liefert neben dem Schaltzustand zusätzliche Informationen wie Stromverbrauch, Betriebsstunden und WLAN-Signalqualität. Diese Metadaten werden für Monitoring- und Analysezwecke persistiert.
|
||||
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.
|
||||
|
||||
## 3.3 Scheduler-Implementierung und Automatisierung
|
||||
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.
|
||||
|
||||
Der Job-Scheduler wurde als eigenständiger Thread implementiert, der parallel zur Flask-Anwendung operiert. Diese Architekturentscheidung gewährleistet, dass Scheduler-Operationen die Responsivität der Web-API nicht beeinträchtigen.
|
||||
## 2.6 Planung der Prozess-/und Systemschnittstellen
|
||||
|
||||
Der Scheduler-Thread initialisiert beim Systemstart und arbeitet in einer kontinuierlichen Schleife mit 60-sekündigem Prüfintervall. Bei jeder Iteration werden anstehende Reservierungen identifiziert und entsprechende Schaltaktionen ausgeführt. Die Implementierung berücksichtigt einen fünfminütigen Sicherheitspuffer nach dem geplanten Ende einer Reservierung, um laufende Druckvorgänge nicht vorzeitig zu unterbrechen.
|
||||
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 Verarbeitung von Scheduler-Events folgt einem definierten Ablauf: Statusänderung in der Datenbank, Ausführung der Hardware-Operation über den SmartPlugController, Protokollierung des Ergebnisses. Bei Fehlern werden bis zu drei Wiederholungsversuche unternommen, bevor eine Fehlerbehandlung erfolgt.
|
||||
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.
|
||||
|
||||
Thread-Sicherheit wurde durch explizite Datenbankisolation und Transaktionsmanagement gewährleistet. Jeder Datenbankzugriff aus dem Scheduler-Thread erhält einen eigenen Application Context, wodurch Konflikte mit concurrent Web-Requests vermieden werden.
|
||||
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.
|
||||
|
||||
## 3.4 Datenmodell und Persistierung
|
||||
## 2.7 Planung der IT-Sicherheitsmaßnahmen
|
||||
|
||||
Das relationale Datenmodell wurde mit Fokus auf Erweiterbarkeit und Datenintegrität entworfen. Die vier Kernentitäten User, Printer, Job und verschiedene Log-Tabellen bilden die Grundlage der Datenhaltung.
|
||||
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 User-Entität speichert neben Authentifizierungsdaten auch sicherheitsrelevante Metainformationen wie fehlgeschlagene Anmeldeversuche und temporäre Sperrzeitstempel. Das implementierte Rollenmodell differenziert zwischen Standard-Nutzern und Administratoren. Die Struktur ist bereits für zukünftige Erweiterungen wie Zwei-Faktor-Authentifizierung vorbereitet.
|
||||
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.
|
||||
|
||||
Die Printer-Entität bildet die physischen Geräte mit allen relevanten Attributen ab. Neben deskriptiven Informationen werden die kritischen Netzwerkkonfigurationen der zugeordneten Smart-Plugs gespeichert. Ein Aktivitätsflag ermöglicht die temporäre Deaktivierung ohne Konfigurationsverlust.
|
||||
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 Job-Entität verwaltet den vollständigen Lebenszyklus von Reservierungen. Der Status durchläuft die Phasen "scheduled", "running", "finished" oder "aborted". Sowohl geplante als auch tatsächliche Start- und Endzeiten werden erfasst, um Abweichungsanalysen zu ermöglichen.
|
||||
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.
|
||||
|
||||
Spezialisierte Log-Tabellen dienen der Systemüberwachung und Analyse. PlugStatusLog protokolliert alle Hardware-Interaktionen, EnergyUsageLog erfasst Verbrauchsdaten, SystemPerformanceLog zeichnet Systemmetriken auf. Diese umfassende Datensammlung ermöglicht detaillierte Auswertungen und proaktive Wartung.
|
||||
# 3. Durchführung und Auftragsbearbeitung
|
||||
|
||||
## 3.5 Sicherheitsimplementierung und Datenschutz
|
||||
## 3.1 Prozess-Schritte und Vorgehensweise
|
||||
|
||||
Die Sicherheitsarchitektur folgt dem Prinzip "Security by Design" und implementiert mehrschichtige Schutzmaßnahmen. Die Umsetzung berücksichtigt sowohl die spezifischen Anforderungen der Mercedes-Benz AG als auch gesetzliche Vorgaben wie die DSGVO.
|
||||
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.
|
||||
|
||||
Auf Netzwerkebene wurden restriktive Firewall-Regeln mittels iptables implementiert. Die Konfiguration erlaubt ausschließlich essenzielle Dienste und limitiert ausgehende Verbindungen auf die definierten Smart-Plug-Adressen. Diese Maßnahmen verhindern effektiv die Nutzung des Systems als Ausgangspunkt für Angriffe auf andere Netzwerkressourcen.
|
||||
### 3.1.1 Datenabfrage der Sensoren
|
||||
|
||||
Die Anwendungsebene implementiert umfassende Eingabevalidierung für alle API-Endpunkte. Ein integriertes Intrusion Detection System erkennt typische Angriffsmuster wie SQL-Injection, Cross-Site-Scripting und Path-Traversal. Bei Erkennung verdächtiger Aktivitäten erfolgt eine temporäre IP-Sperrung.
|
||||
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.
|
||||
|
||||
Für DSGVO-Compliance wurden automatisierte Datenlebenszyklen implementiert. Session-Daten werden nach 30 Tagen gelöscht, Job-Daten nach zwei Jahren anonymisiert. Die Anonymisierung erhält statistische Informationen bei gleichzeitiger Entfernung personenbezogener Daten. Ein Datenexport gemäß Artikel 20 DSGVO wurde implementiert.
|
||||
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.
|
||||
|
||||
## 3.6 Deployment und Produktivbetrieb
|
||||
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.
|
||||
|
||||
Das Deployment auf dem Raspberry Pi 5 erfolgte mittels eines automatisierten Installationsskripts. Die Flask-Anwendung wurde als systemd-Service konfiguriert, was automatischen Start beim Systemboot und Neustart bei Fehlern gewährleistet. Die Service-Konfiguration implementiert zusätzliche Sicherheitsmaßnahmen wie Rechtebeschränkungen und Dateisystemisolation.
|
||||
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.
|
||||
|
||||
Für die lokale Nutzung wurde ein Kiosk-Modus eingerichtet, der die Webanwendung im Vollbildmodus präsentiert. Der Chromium-Browser startet automatisch beim Systemstart und ist für fehlertoleranten Betrieb konfiguriert. Entgegen der ursprünglichen Planung wurde auf ein Touch-Display verzichtet, die Bedienung erfolgt über konventionelle Eingabegeräte.
|
||||
### 3.1.2 Verarbeiten der Daten
|
||||
|
||||
Die Backup-Strategie implementiert tägliche Datenbanksicherungen mit automatischer Rotation nach 30 Tagen. Wöchentliche Systembackups sichern die Gesamtkonfiguration. Alle Backup-Prozesse sind über Cron-Jobs automatisiert und werden überwacht.
|
||||
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.
|
||||
|
||||
# 4. Projektabschluss und Bewertung
|
||||
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.
|
||||
|
||||
## 4.1 Projektergebnis und Zielerreichung
|
||||
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.
|
||||
|
||||
Das MYP-System wurde erfolgreich innerhalb des vorgegebenen Zeitrahmens fertiggestellt und in den Produktivbetrieb überführt. Die implementierte Lösung erfüllt alle definierten Anforderungen und bietet darüber hinaus zusätzliche Funktionalitäten, die sich während der Entwicklung als sinnvoll erwiesen.
|
||||
## 3.2 Abweichung, Anpassung und Entscheidungen
|
||||
|
||||
Die technische Umsetzung umfasst über 9.000 Zeilen strukturierten Python-Code mit umfassender Dokumentation. Die REST-API stellt mehr als 100 Endpunkte bereit und gewährleistet damit die vollständige Abdeckung aller identifizierten Anwendungsfälle. Der implementierte Scheduler arbeitet seit Inbetriebnahme zuverlässig und hat keine Schaltung versäumt.
|
||||
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.
|
||||
|
||||
Die Integration des bestehenden Frontend-Prototyps mit dem neu entwickelten Backend verlief erfolgreich. Die nahtlose Zusammenarbeit beider Komponenten demonstriert die Effektivität des gewählten Architekturansatzes. Die automatische Steuerung der 3D-Drucker über Smart-Plugs funktioniert präzise und zuverlässig. Der implementierte Sicherheitspuffer verhindert effektiv die vorzeitige Unterbrechung laufender Druckvorgänge.
|
||||
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.
|
||||
|
||||
Das System wird von den Nutzern gut angenommen. Die digitale Reservierungsverwaltung hat das manuelle Whiteboard-System vollständig abgelöst. Erste Rückmeldungen bestätigen die verbesserte Effizienz und Transparenz bei der Druckernutzung.
|
||||
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.
|
||||
|
||||
## 4.2 Technische und wirtschaftliche Bewertung
|
||||
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.
|
||||
|
||||
Aus technischer Perspektive demonstriert das MYP-System erfolgreich die Prinzipien cyber-physischer Vernetzung. Die Überbrückung zwischen digitaler Verwaltungsebene und physischer Hardware-Steuerung wurde elegant durch den Einsatz von Smart-Plugs gelöst. Diese Architekturentscheidung erwies sich als robust und wartungsarm.
|
||||
## 3.3 Maßnahmen zur Qualitätskontrolle
|
||||
|
||||
Die wirtschaftliche Bewertung fällt äußerst positiv aus. Die Gesamtinvestition von unter 600 Euro (inklusive privat finanzierter Komponenten) steht in einem exzellenten Verhältnis zum erzielten Nutzen. Kommerzielle Lösungen mit vergleichbarem Funktionsumfang liegen typischerweise im fünfstelligen Bereich.
|
||||
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.
|
||||
|
||||
Der operative Nutzen manifestiert sich in mehreren Dimensionen: Die Eliminierung von Reservierungskonflikten, die automatisierte Energieverwaltung durch zeitgesteuerte Abschaltung und die erstmalige Verfügbarkeit belastbarer Nutzungsstatistiken. Diese Daten bilden die Grundlage für fundierte Entscheidungen bezüglich Kapazitätserweiterungen oder Ressourcenallokation.
|
||||
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.
|
||||
|
||||
Die Sicherheitsarchitektur erfüllt alle relevanten Anforderungen der Mercedes-Benz AG. Die implementierten Maßnahmen gewährleisten Datenschutz, Systemintegrität und Compliance mit geltenden Regularien.
|
||||
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.
|
||||
|
||||
## 4.3 Herausforderungen und Lösungsansätze
|
||||
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.
|
||||
|
||||
Die Projektdurchführung war von verschiedenen Herausforderungen geprägt, die flexible Lösungsansätze erforderten. Die administrativen Prozesse zur Erlangung notwendiger Berechtigungen und Genehmigungen erwiesen sich als zeitintensiver als geplant. Diese Erfahrung unterstreicht die Bedeutung ausreichender Zeitpuffer für organisatorische Aspekte in Unternehmensprojekten.
|
||||
## 3.4 Implementierung, Konfiguration und Inbetriebnahme von Schnittstellen und unterschiedlicher Prozesse
|
||||
|
||||
Die technische Integration der Smart-Plugs erforderte aufgrund mangelhafter Dokumentation der PyP100-Bibliothek erheblichen Reverse-Engineering-Aufwand. Die systematische Analyse des Kommunikationsprotokolls mittels Wireshark führte letztendlich zu einer stabilen Implementierung.
|
||||
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.
|
||||
|
||||
Der Verlust der SSL-Zertifikate in Sprint 3 verdeutlichte die Wichtigkeit robuster Backup-Strategien. Die implementierte dreifache Sicherung kritischer Konfigurationsdateien verhindert zukünftige Datenverluste.
|
||||
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 Performance-Anforderungen des Next.js-Frontends führten zur Anpassung der Hardware-Spezifikation. Der Wechsel zum leistungsfähigeren Raspberry Pi 5 gewährleistete ausreichende Systemressourcen für einen flüssigen Betrieb.
|
||||
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.
|
||||
|
||||
## 4.4 Projekterfahrungen und persönliche Entwicklung
|
||||
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.
|
||||
|
||||
Das MYP-Projekt bot wertvolle Einblicke in die praktische Umsetzung cyber-physischer Systeme. Die Integration von Software- und Hardware-Komponenten zu einer funktionierenden Gesamtlösung entspricht dem Kernprofil des Fachinformatikers für digitale Vernetzung.
|
||||
## 3.5 Konfiguration von Übertragungssystemen und Integration in die Gesamtinfrastruktur
|
||||
|
||||
Die Arbeit mit IoT-Geräten und die Entwicklung robuster Kommunikationsprotokolle erweiterten das technische Kompetenzspektrum erheblich. Die Notwendigkeit, Ausfallszenarien zu antizipieren und entsprechende Fehlerbehandlungen zu implementieren, führte zu einem vertieften Verständnis für zuverlässige Systemarchitekturen.
|
||||
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 Interaktion mit verschiedenen Stakeholdern – von der technischen Weiterentwicklung des Prototyps über Abstimmungen mit der IT-Abteilung bis zur Berücksichtigung der Nutzeranforderungen – verbesserte die kommunikativen und organisatorischen Fähigkeiten nachhaltig.
|
||||
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.
|
||||
|
||||
Der Projektverlauf, insbesondere die Herausforderungen der letzten Sprints, verdeutlichte die Bedeutung von Priorisierung und pragmatischen Entscheidungen. Die Fokussierung auf essenzielle Funktionen ermöglichte die erfolgreiche Fertigstellung trotz unvorhergesehener Hindernisse.
|
||||
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.
|
||||
|
||||
## 4.5 Ausblick und Weiterentwicklung
|
||||
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.
|
||||
|
||||
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.
|
||||
## 3.6 Erfüllen der Anforderungen an die Informationssicherheit
|
||||
|
||||
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.
|
||||
Die Informationssicherheit wurde von Anfang an als kritischer Erfolgsfaktor behandelt. Jede Designentscheidung wurde durch die Sicherheitsbrille betrachtet, jede Implementierung auf Schwachstellen geprüft.
|
||||
|
||||
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.
|
||||
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.
|
||||
|
||||
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.
|
||||
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.
|
||||
|
||||
## 4.6 Fazit
|
||||
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.
|
||||
|
||||
Mit dem MYP-System wurde eine praxistaugliche Lösung für die digitale Transformation der 3D-Drucker-Verwaltung in der Technischen Berufsausbildungsstätte entwickelt. Das Projekt demonstriert erfolgreich, wie durch innovative Ansätze technische Limitierungen überwunden und moderne cyber-physische Systeme realisiert werden können.
|
||||
# 4. Projektabschluss
|
||||
|
||||
Die Kombination aus fundierter technischer Implementierung, durchdachter Systemarchitektur und pragmatischen Lösungsansätzen resultierte in einem System, das die gestellten Anforderungen vollständig erfüllt. Die erfolgreiche Integration bestehender Komponenten mit neu entwickelten Funktionalitäten unterstreicht die während der Ausbildung erworbenen Kompetenzen.
|
||||
## 4.1 Soll-Ist-Vergleich (Abweichung, Anpassungen)
|
||||
|
||||
Das positive Feedback der Nutzer und die stabile Funktionsweise im Produktivbetrieb bestätigen die Qualität der entwickelten Lösung. Das MYP-System hat sich als wertvolles Werkzeug für die effiziente Ressourcenverwaltung etabliert und trägt zur Modernisierung der Ausbildungsinfrastruktur bei.
|
||||
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.
|
||||
|
||||
Die Projekterfahrungen bilden eine solide Grundlage für die weitere berufliche Entwicklung als Fachinformatiker für digitale Vernetzung. Die erfolgreiche Verbindung digitaler und physischer Systeme zu einer funktionierenden Gesamtlösung demonstriert die praktische Anwendung des erworbenen Fachwissens.
|
||||
**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
|
||||
|
||||
Trotz des erfolgreichen Projektabschlusses existieren zahlreiche Optimierungspotenziale, die in zukünftigen Iterationen adressiert werden könnten:
|
||||
|
||||
**Technische Optimierungen:**
|
||||
- Migration von SQLite zu PostgreSQL für bessere Concurrent-Access-Performance
|
||||
- Implementierung von WebSocket-Verbindungen für Echtzeit-Updates
|
||||
- Erweiterung der API um GraphQL-Endpunkte für flexiblere Datenabfragen
|
||||
- Integration von Machine Learning für Nutzungsprognosen
|
||||
- Entwicklung nativer Mobile Apps für iOS und Android
|
||||
|
||||
**Funktionale Erweiterungen:**
|
||||
- Direkte Integration mit 3D-Druckern der neuesten Generation via OctoPrint
|
||||
- Implementierung eines Wartungskalenders mit automatischen Erinnerungen
|
||||
- Erweiterung auf andere Maker-Space-Geräte (Lasercutter, CNC-Fräsen)
|
||||
- Integration mit dem Active Directory der Mercedes-Benz AG
|
||||
- Implementierung von Benachrichtigungen via E-Mail oder Teams
|
||||
|
||||
**Prozessuale Verbesserungen:**
|
||||
- Automatisierte Deployment-Pipeline mit CI/CD
|
||||
- Erweiterung der Test-Coverage auf 95%+
|
||||
- Implementierung von A/B-Testing für UX-Optimierungen
|
||||
- Aufbau eines strukturierten Feedback-Systems
|
||||
|
||||
Die modulare Architektur des Systems ermöglicht diese Erweiterungen ohne grundlegende Änderungen. Die klare Trennung von Frontend, Backend und Hardware-Abstraction-Layer gewährleistet, dass zukünftige Entwicklungen isoliert und risikoarm durchgeführt werden können.
|
||||
|
||||
## 4.4 Abnahme
|
||||
|
||||
Die formale Projektabnahme erfolgte am 20. Mai 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.
|
||||
|
||||
**Abnahmekriterien und deren Erfüllung:**
|
||||
- ✓ Digitale Reservierungsverwaltung funktionsfähig
|
||||
- ✓ Automatische Druckersteuerung implementiert
|
||||
- ✓ Benutzerauthentifizierung sicher umgesetzt
|
||||
- ✓ System läuft stabil auf Raspberry Pi
|
||||
- ✓ Dokumentation vollständig
|
||||
- ✓ Sicherheitsanforderungen erfüllt
|
||||
|
||||
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:**
|
||||
|
||||
- Screenshots der Benutzeroberfläche und Systemarchitektur
|
||||
- Relevanter E-Mail-Verkehr und Genehmigungen
|
||||
- Technische Spezifikationen und Konfigurationsdateien
|
||||
- Netzwerkdiagramme und Systemarchitektur
|
||||
- API-Dokumentation
|
||||
- Benutzerhandbuch
|
||||
- Testprotokolle
|
||||
- Screenshots der Benutzeroberfläche
|
||||
- Konfigurationsdateien und Deployment-Skripte
|
||||
264
backup_ihk_docs/IHK_DOKUMENTATION_backup.md
Normal file
264
backup_ihk_docs/IHK_DOKUMENTATION_backup.md
Normal file
@ -0,0 +1,264 @@
|
||||
# MYP – Manage Your Printer
|
||||
|
||||
**Digitalisierung des 3D-Drucker-Reservierungsprozesses durch Etablierung der cyberphysischen Kommunikation mit relevanten Hardwarekomponenten**
|
||||
|
||||
**Abschlussprüfung – Sommer 2025**
|
||||
|
||||
**Fachinformatiker für digitale Vernetzung**
|
||||
|
||||
**Abgabedatum: 5. Juni 2025**
|
||||
|
||||
---
|
||||
|
||||
## Ausbildungsbetrieb
|
||||
|
||||
**Mercedes-Benz AG**
|
||||
|
||||
Daimlerstraße 143
|
||||
|
||||
D-12277 Berlin
|
||||
|
||||
---
|
||||
|
||||
## Prüfungsbewerber
|
||||
|
||||
**Till Tomczak**
|
||||
|
||||
Hainbuchenstraße 19
|
||||
|
||||
D-16761 Hennigsdorf
|
||||
|
||||
---
|
||||
|
||||
## Inhaltsverzeichnis
|
||||
|
||||
1. Einleitung und Projektanalyse
|
||||
2. Projektplanung und Ressourcenmanagement
|
||||
3. Durchführung und technische Implementierung
|
||||
4. Projektabschluss und Bewertung
|
||||
|
||||
---
|
||||
|
||||
# 1. Einleitung und Projektanalyse
|
||||
|
||||
## 1.1 Ausgangssituation und Problemstellung
|
||||
|
||||
Die Technische Berufsausbildungsstätte (TBA) der Mercedes-Benz AG am Standort Berlin verfügt über sechs 3D-Drucker verschiedener Hersteller (Prusa, Anycubic; 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 Projektauftrag und Zielsetzung
|
||||
|
||||
Nach erfolgter Zulassung des Abschlussprojekts durch die IHK erhielt ich den Auftrag, den bestehenden Prototyp zu einer vollständigen cyber-physischen Lösung weiterzuentwickeln. Das Zielsystem sollte unter dem Namen "MYP - Manage Your Printer" nicht nur die digitale Verwaltung der Reservierungen ermöglichen, sondern auch die automatisierte Steuerung der physischen Geräte realisieren.
|
||||
|
||||
Die zentrale 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 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.
|
||||
|
||||
Ein weiteres Projektziel war die Gewährleistung der Herstellerunabhängigkeit. Die recht heterogene und Schnittstellenarme Druckerlandschaft der sechs 3D-Drucker erforderte eine universell einsetzbare Lösung, die sich zugleich auch leicht an Upgrades (der 3D-Drucker sowie auch der entstehenden Lösung selbst) anpassen lassen würde. Das System sollte eine rudimentäre Rechteverwaltung implementieren, die zwischen administrativen Funktionen und regulären Nutzerrechten unterscheidet.
|
||||
|
||||
## 1.3 Lösungskonzept und technische Architektur
|
||||
|
||||
Die Analyse der technischen Rahmenbedingungen führt in logischer Schlussfolgerung also zu meinem Lösungsansatz: Statt einer direkten Steuerung der 3D-Drucker erfolgt die Kontrolle über intelligente Zwischensteckdosen (Smart-Plugs). Als Hardware-Komponente wurden TP-Link Tapo P110 Smart-Plugs ausgewählt, die über eine propritäre und damit inoffizielle lokale API verfügen und so ohne Cloud-Anbindung steuerbar sind. Diese Geräte ermöglichen die grundlegenden Funktionen der Stromversorgungssteuerung sowie die Abfrage von Statusinformationen und Verbrauchsdaten. Die ausgängliche Annahme, dass die Geräte des chinesischen Herstellers sich problemlos in ein praktisches Air-Gapped Netzwerk integrieren lassen würden, entsprang der Erfahrung mit meiner verhältnismäßig großen privaten Infrastruktur abseits des betrieblichen Umfeldes.
|
||||
|
||||
Die Systemarchitektur folgt einem dreischichtigen Aufbau: Die Präsentationsschicht basiert auf dem von Torben Haack entwickelten Next.js-Frontend, welches um die notwendigen Backend-Schnittstellen erweitert wurde. Die Geschäftslogikschicht wird durch ein Python-basiertes Flask-Backend realisiert, das eine umfassende REST-API bereitstellt. Die PyP100-Bibliothek ermöglicht dabei die Kommunikation mit den Smart-Plugs. Als Persistenzschicht dient eine SQLite-Datenbank, die alle relevanten Daten lokal speichert und damit die Offline-Anforderungen erfüllt.
|
||||
|
||||
Ein zentrales Element der Architektur ist der implementierte Scheduler, der als eigenständiger Prozess die zeitgesteuerte Aktivierung und Deaktivierung der Drucker übernimmt. Dieser prüft im Minutentakt anstehende Reservierungen und sendet die entsprechenden Steuerbefehle an die Smart-Plugs. Die gesamte Kommunikation erfolgt ausschließlich über das lokale Netzwerk, wodurch die Sicherheitsanforderungen gewährleistet werden.
|
||||
|
||||
## 1.4 Projektumfeld und Rahmenbedingungen
|
||||
|
||||
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 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.
|
||||
|
||||
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.
|
||||
|
||||
## 1.5 Projektabgrenzung
|
||||
|
||||
Der Projektumfang wurde bewusst auf die praktische Umsetzung einer funktionsfähigen Lösung fokussiert. Eine umfassende Daten- und Prozessanalyse wurde zugunsten der technischen Realisierung zurückgestellt. Diese Priorisierung ermöglichte die Fertigstellung eines produktiv einsetzbaren Systems innerhalb des vorgegebenen Zeitrahmens.
|
||||
|
||||
Eine direkte Kommunikation mit den 3D-Druckern zur Übertragung von Druckdaten oder zur Statusüberwachung wurde 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. Die gewählte Lösung über Smart-Plugs stellt einen pragmatischen Kompromiss dar, der die wesentlichen Anforderungen erfüllt.
|
||||
|
||||
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 überschritten hätten. Stattdessen wurde eine autarke Lösung entwickelt, die alle erforderlichen Funktionen lokal bereitstellt.
|
||||
|
||||
# 2. Projektplanung und Ressourcenmanagement
|
||||
|
||||
## 2.1 Methodisches Vorgehen und Projektorganisation
|
||||
|
||||
Für die Projektdurchführung wurde ein agiler Entwicklungsansatz nach Scrum-Prinzipien gewählt. Die Gesamtprojektdauer von fünf Wochen (15. April bis 20. Mai 2025) wurde in fünf einwöchige Sprints unterteilt. Diese iterative Vorgehensweise ermöglichte flexible Anpassungen an sich ändernde Anforderungen und unvorhergesehene technische Herausforderungen.
|
||||
|
||||
**Sprint 1 (15.-19. April 2025):** Der erste Sprint widmete sich der Analyse des bestehenden Prototyps und der Definition der Erweiterungspunkte. Hauptaufgaben waren die Evaluierung der Frontend-Codebasis, die Spezifikation der erforderlichen API-Endpunkte und die erfolgreiche Etablierung der Kommunikation mit den Smart-Plugs über die PyP100-Bibliothek. Der erfolgreiche Verbindungsaufbau zu den Geräten stellte einen kritischen Meilenstein dar.
|
||||
|
||||
**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 zeitintensiver Prozess. Parallel dazu wurden die Systemkomponenten ausgewählt, erste Funktionstests durchgeführt und mittels Wireshark-Analysen das Kommunikationsprotokoll der Smart-Plugs reverse-engineered, um die Integration zu optimieren.
|
||||
|
||||
**Sprint 3 (29. April - 3. Mai 2025):** Der dritte Sprint sollte die Integration von Frontend und Backend realisieren. Technische Schwierigkeiten bei der Verbindung beider Komponenten sowie der versehentliche Verlust der genehmigten SSL-Zertifikate führten zu erheblichen Verzögerungen. Zusätzliche Zeit wurde für die Einarbeitung in die unternehmensSpezifischen Implementierungen von GitHub OAuth und npm benötigt.
|
||||
|
||||
**Sprint 4 (6.-10. Mai 2025):** Ursprünglich für Optimierungen vorgesehen, wurde dieser Sprint zur Entwicklung einer funktionsfähigen Gesamtlösung umgewidmet. Der Zeitdruck erforderte pragmatische Entscheidungen und die Konzentration auf essenzielle Funktionen. Die Implementierung erfolgte in intensiven Entwicklungssessions mit dem Ziel, ein lauffähiges System zu erstellen.
|
||||
|
||||
**Sprint 5 (13.-17. Mai 2025):** Der finale Sprint diente der Fehlerbehebung und Systemstabilisierung. Die ursprünglich geplanten Schulungen wurden zugunsten der technischen Fertigstellung zurückgestellt. Die verbleibende Zeit wurde für kritische Bugfixes und die Erstellung der Projektdokumentation genutzt.
|
||||
|
||||
## 2.2 Ressourcenplanung und Infrastruktur
|
||||
|
||||
Die Hardware-Ausstattung wurde basierend auf den Projektanforderungen sorgfältig ausgewählt. Als zentrale Serverplattform kam ein Raspberry Pi 5 mit 8 GB RAM zum Einsatz. Die Entscheidung gegen den ursprünglich geplanten Raspberry Pi 4 basierte auf Performance-Tests, die zeigten, dass das Next.js-Frontend höhere Rechenleistung erforderte als initial angenommen. Die Speicherausstattung wurde auf 128 GB erweitert, um ausreichend Kapazität für die Offline-Installation des Frontends, Datenbankwachstum und regelmäßige Backups zu gewährleisten.
|
||||
|
||||
Die sechs TP-Link Tapo P110 Smart-Plugs bildeten die zentrale Hardware-Schnittstelle zu den 3D-Druckern. Jedes Gerät erhielt eine statische IP-Adresse im Bereich 192.168.0.151 bis 192.168.0.156, was die Verwaltung und Fehlerdiagnose erheblich vereinfachte. Die Konfiguration erfolgte so, dass die Geräte ausschließlich im lokalen Netzwerk erreichbar sind und keine Verbindung zu Cloud-Diensten aufbauen.
|
||||
|
||||
Zur professionellen Unterbringung der Hardware wurde ein 19-Zoll-Serverschrank beschafft. Aufgrund langwieriger interner Beschaffungsprozesse wurden ergänzende Komponenten wie Lüftereinheiten und Kabelmanagement-Systeme privat finanziert. Diese Investition diente der professionellen Präsentation und optimalen Betriebsbedingungen des Systems.
|
||||
|
||||
Die Software-Architektur basiert 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ährleistet Unabhängigkeit von proprietären Lösungen und erfüllt die Offline-Anforderungen des Projekts.
|
||||
|
||||
## 2.3 Qualitätssicherung und Testkonzept
|
||||
|
||||
Das Qualitätssicherungskonzept orientierte sich am V-Modell und sah für jede Entwicklungsphase korrespondierende Testaktivitäten vor. Die systematische Testdurchführung gewährleistete die Funktionsfähigkeit und Robustheit des Systems.
|
||||
|
||||
Auf Unit-Test-Ebene wurden alle kritischen Komponenten isoliert getestet. Dies umfasste Datenbankoperationen, API-Eingabevalidierung und die Kernfunktionen der Reservierungsverwaltung. Besondere Aufmerksamkeit galt der Smart-Plug-Kommunikation, für die umfangreiche Testszenarien entwickelt wurden, einschließlich Netzwerkausfällen und Timeout-Situationen.
|
||||
|
||||
Die Integrationstests validierten das Zusammenspiel der Systemkomponenten. Schwerpunkte waren die Backend-Smart-Plug-Schnittstelle und die API-Kommunikation. Systematische Tests mit verschiedenen Eingabedaten, einschließlich invalider und potenziell schädlicher Inputs, stellten die Robustheit der Schnittstellen sicher.
|
||||
|
||||
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 wurde dabei besonders überwacht.
|
||||
|
||||
Performance-Tests auf der Zielplattform bestätigten die ausreichende Leistungsfähigkeit des Raspberry Pi 5. Selbst bei simultanen Zugriffen mehrerer Nutzer und parallelen Smart-Plug-Operationen blieb die Systemperformance im akzeptablen Bereich.
|
||||
|
||||
## 2.4 Netzwerkarchitektur und Sicherheitskonzept
|
||||
|
||||
Die Integration in die Netzwerkinfrastruktur der Mercedes-Benz AG erforderte detaillierte Abstimmungen mit der IT-Abteilung. Das MYP-System wurde in einem dedizierten IoT-Subnetz (192.168.0.0/24) platziert, welches vom Produktionsnetzwerk isoliert ist. Diese Segmentierung gewährleistet erhöhte Sicherheit und verhindert unautorisierten Zugriff auf kritische Systeme.
|
||||
|
||||
Der Raspberry Pi Server erhielt die statische IP-Adresse 192.168.0.105. Die Firewall-Konfiguration wurde restriktiv gestaltet: Port 5000 für die Flask-Anwendung, Port 22 für SSH-Zugriffe (ausschließlich aus dem lokalen Subnetz) und Port 5443 für HTTPS-Verbindungen. Ausgehende Verbindungen wurden strikt auf die IP-Adressen der Smart-Plugs limitiert.
|
||||
|
||||
Für die verschlüsselte Kommunikation wurde ein selbstsigniertes SSL-Zertifikat implementiert. Trotz der Einschränkungen selbstsignierter Zertifikate stellen diese für isolierte Netzwerke ohne Internetzugang eine adäquate Lösung dar. Das Zertifikat wurde mit einjähriger Gültigkeit ausgestellt und enthält alle relevanten Hostnamen und IP-Adressen als Subject Alternative Names. Nach dem versehentlichen Verlust der ersten Zertifikatsgeneration wurde ein robustes Backup-Konzept implementiert.
|
||||
|
||||
Die Authentifizierung basiert auf bcrypt-Hashing mit angemessenem Cost-Faktor. Nach fünf fehlgeschlagenen Anmeldeversuchen erfolgt eine 30-minütige Kontosperrung. Alle sicherheitsrelevanten Ereignisse werden in dedizierten Logdateien protokolliert und können für Sicherheitsaudits herangezogen werden.
|
||||
|
||||
# 3. Durchführung und technische Implementierung
|
||||
|
||||
## 3.1 Backend-Architektur und API-Design
|
||||
|
||||
Die Backend-Implementierung folgt einer modularen Architektur unter Verwendung des Flask-Blueprint-Systems. Diese Strukturierung ermöglicht eine klare Trennung der funktionalen Bereiche und erleichtert die Wartbarkeit des Systems. Die API wurde in vier Hauptmodule unterteilt: Authentication, User Management, Printer Management und Job Management.
|
||||
|
||||
Das Authentication-Modul implementiert die vollständige Benutzerverwaltung einschließlich Registrierung, Anmeldung und Session-Management. Passwörter werden mittels bcrypt gehasht und mit individuellem Salt gespeichert. Die Session-Verwaltung nutzt Flask-Login mit einer konfigurierten Ablaufzeit von acht Stunden. Zusätzliche Sicherheitsmaßnahmen umfassen CSRF-Protection und die Konfiguration sicherer Session-Cookies mit den Attributen Secure, HttpOnly und SameSite.
|
||||
|
||||
Das Job-Management-Modul bildet den funktionalen Kern des Systems. Der primäre Endpunkt POST /api/v1/jobs implementiert umfassende Validierungslogik, die Überschneidungen mit bestehenden Reservierungen verhindert und Berechtigungen prüft. Die Implementierung unterstützt erweiterte Funktionen wie die nachträgliche Modifikation von Reservierungen und vorzeitige Beendigung von Druckaufträgen. Diese Flexibilität erwies sich als essentiell für den praktischen Betrieb.
|
||||
|
||||
Das Printer-Management-Modul verwaltet die Konfiguration der 3D-Drucker und ihrer zugeordneten Smart-Plugs. Neben grundlegenden Attributen wie Name und Standort werden die Netzwerkinformationen der Smart-Plugs (IP- und MAC-Adresse) gespeichert. Ein Status-Flag ermöglicht die temporäre Deaktivierung von Druckern für Wartungszwecke.
|
||||
|
||||
Das API-Design orientiert sich an REST-Prinzipien und implementiert über 100 spezifische Endpunkte. Diese umfassende API-Oberfläche gewährleistet die Abdeckung aller identifizierten Use-Cases und bietet Erweiterungsmöglichkeiten für zukünftige Anforderungen.
|
||||
|
||||
## 3.2 Smart-Plug-Integration und Hardware-Steuerung
|
||||
|
||||
Die Integration der TP-Link Tapo P110 Smart-Plugs stellte eine zentrale technische Herausforderung dar. Die PyP100-Bibliothek bot zwar grundlegende Funktionalität, erforderte jedoch erhebliche Anpassungen für den produktiven Einsatz. Durch Analyse des Netzwerkverkehrs mittels Wireshark konnten die Kommunikationsprotokolle verstanden und optimiert werden.
|
||||
|
||||
Die entwickelte SmartPlugController-Klasse kapselt die Hardware-Kommunikation und implementiert robuste Fehlerbehandlung. Ein Retry-Mechanismus mit exponentiellem Backoff gewährleistet zuverlässige Kommunikation auch bei temporären Netzwerkproblemen. Nach drei erfolglosen Verbindungsversuchen wird der Fehler protokolliert und zur späteren Analyse gespeichert.
|
||||
|
||||
Das proprietäre Authentifizierungsprotokoll der Smart-Plugs erforderte besondere Aufmerksamkeit. Die Implementierung etabliert für jede Operation eine neue Verbindung, um Probleme mit Session-Timeouts zu vermeiden. Die Zugangsdaten werden verschlüsselt in der Systemkonfiguration gespeichert und nur bei Bedarf entschlüsselt.
|
||||
|
||||
Die Implementierung unterstützt drei Kernoperationen: Aktivierung, Deaktivierung und Statusabfrage. Die Statusabfrage liefert neben dem Schaltzustand zusätzliche Informationen wie Stromverbrauch, Betriebsstunden und WLAN-Signalqualität. Diese Metadaten werden für Monitoring- und Analysezwecke persistiert.
|
||||
|
||||
## 3.3 Scheduler-Implementierung und Automatisierung
|
||||
|
||||
Der Job-Scheduler wurde als eigenständiger Thread implementiert, der parallel zur Flask-Anwendung operiert. Diese Architekturentscheidung gewährleistet, dass Scheduler-Operationen die Responsivität der Web-API nicht beeinträchtigen.
|
||||
|
||||
Der Scheduler-Thread initialisiert beim Systemstart und arbeitet in einer kontinuierlichen Schleife mit 60-sekündigem Prüfintervall. Bei jeder Iteration werden anstehende Reservierungen identifiziert und entsprechende Schaltaktionen ausgeführt. Die Implementierung berücksichtigt einen fünfminütigen Sicherheitspuffer nach dem geplanten Ende einer Reservierung, um laufende Druckvorgänge nicht vorzeitig zu unterbrechen.
|
||||
|
||||
Die Verarbeitung von Scheduler-Events folgt einem definierten Ablauf: Statusänderung in der Datenbank, Ausführung der Hardware-Operation über den SmartPlugController, Protokollierung des Ergebnisses. Bei Fehlern werden bis zu drei Wiederholungsversuche unternommen, bevor eine Fehlerbehandlung erfolgt.
|
||||
|
||||
Thread-Sicherheit wurde durch explizite Datenbankisolation und Transaktionsmanagement gewährleistet. Jeder Datenbankzugriff aus dem Scheduler-Thread erhält einen eigenen Application Context, wodurch Konflikte mit concurrent Web-Requests vermieden werden.
|
||||
|
||||
## 3.4 Datenmodell und Persistierung
|
||||
|
||||
Das relationale Datenmodell wurde mit Fokus auf Erweiterbarkeit und Datenintegrität entworfen. Die vier Kernentitäten User, Printer, Job und verschiedene Log-Tabellen bilden die Grundlage der Datenhaltung.
|
||||
|
||||
Die User-Entität speichert neben Authentifizierungsdaten auch sicherheitsrelevante Metainformationen wie fehlgeschlagene Anmeldeversuche und temporäre Sperrzeitstempel. Das implementierte Rollenmodell differenziert zwischen Standard-Nutzern und Administratoren. Die Struktur ist bereits für zukünftige Erweiterungen wie Zwei-Faktor-Authentifizierung vorbereitet.
|
||||
|
||||
Die Printer-Entität bildet die physischen Geräte mit allen relevanten Attributen ab. Neben deskriptiven Informationen werden die kritischen Netzwerkkonfigurationen der zugeordneten Smart-Plugs gespeichert. Ein Aktivitätsflag ermöglicht die temporäre Deaktivierung ohne Konfigurationsverlust.
|
||||
|
||||
Die Job-Entität verwaltet den vollständigen Lebenszyklus von Reservierungen. Der Status durchläuft die Phasen "scheduled", "running", "finished" oder "aborted". Sowohl geplante als auch tatsächliche Start- und Endzeiten werden erfasst, um Abweichungsanalysen zu ermöglichen.
|
||||
|
||||
Spezialisierte Log-Tabellen dienen der Systemüberwachung und Analyse. PlugStatusLog protokolliert alle Hardware-Interaktionen, EnergyUsageLog erfasst Verbrauchsdaten, SystemPerformanceLog zeichnet Systemmetriken auf. Diese umfassende Datensammlung ermöglicht detaillierte Auswertungen und proaktive Wartung.
|
||||
|
||||
## 3.5 Sicherheitsimplementierung und Datenschutz
|
||||
|
||||
Die Sicherheitsarchitektur folgt dem Prinzip "Security by Design" und implementiert mehrschichtige Schutzmaßnahmen. Die Umsetzung berücksichtigt sowohl die spezifischen Anforderungen der Mercedes-Benz AG als auch gesetzliche Vorgaben wie die DSGVO.
|
||||
|
||||
Auf Netzwerkebene wurden restriktive Firewall-Regeln mittels iptables implementiert. Die Konfiguration erlaubt ausschließlich essenzielle Dienste und limitiert ausgehende Verbindungen auf die definierten Smart-Plug-Adressen. Diese Maßnahmen verhindern effektiv die Nutzung des Systems als Ausgangspunkt für Angriffe auf andere Netzwerkressourcen.
|
||||
|
||||
Die Anwendungsebene implementiert umfassende Eingabevalidierung für alle API-Endpunkte. Ein integriertes Intrusion Detection System erkennt typische Angriffsmuster wie SQL-Injection, Cross-Site-Scripting und Path-Traversal. Bei Erkennung verdächtiger Aktivitäten erfolgt eine temporäre IP-Sperrung.
|
||||
|
||||
Für DSGVO-Compliance wurden automatisierte Datenlebenszyklen implementiert. Session-Daten werden nach 30 Tagen gelöscht, Job-Daten nach zwei Jahren anonymisiert. Die Anonymisierung erhält statistische Informationen bei gleichzeitiger Entfernung personenbezogener Daten. Ein Datenexport gemäß Artikel 20 DSGVO wurde implementiert.
|
||||
|
||||
## 3.6 Deployment und Produktivbetrieb
|
||||
|
||||
Das Deployment auf dem Raspberry Pi 5 erfolgte mittels eines automatisierten Installationsskripts. Die Flask-Anwendung wurde als systemd-Service konfiguriert, was automatischen Start beim Systemboot und Neustart bei Fehlern gewährleistet. Die Service-Konfiguration implementiert zusätzliche Sicherheitsmaßnahmen wie Rechtebeschränkungen und Dateisystemisolation.
|
||||
|
||||
Für die lokale Nutzung wurde ein Kiosk-Modus eingerichtet, der die Webanwendung im Vollbildmodus präsentiert. Der Chromium-Browser startet automatisch beim Systemstart und ist für fehlertoleranten Betrieb konfiguriert. Entgegen der ursprünglichen Planung wurde auf ein Touch-Display verzichtet, die Bedienung erfolgt über konventionelle Eingabegeräte.
|
||||
|
||||
Die Backup-Strategie implementiert tägliche Datenbanksicherungen mit automatischer Rotation nach 30 Tagen. Wöchentliche Systembackups sichern die Gesamtkonfiguration. Alle Backup-Prozesse sind über Cron-Jobs automatisiert und werden überwacht.
|
||||
|
||||
# 4. Projektabschluss und Bewertung
|
||||
|
||||
## 4.1 Projektergebnis und Zielerreichung
|
||||
|
||||
Das MYP-System wurde erfolgreich innerhalb des vorgegebenen Zeitrahmens fertiggestellt und in den Produktivbetrieb überführt. Die implementierte Lösung erfüllt alle definierten Anforderungen und bietet darüber hinaus zusätzliche Funktionalitäten, die sich während der Entwicklung als sinnvoll erwiesen.
|
||||
|
||||
Die technische Umsetzung umfasst über 9.000 Zeilen strukturierten Python-Code mit umfassender Dokumentation. Die REST-API stellt mehr als 100 Endpunkte bereit und gewährleistet damit die vollständige Abdeckung aller identifizierten Anwendungsfälle. Der implementierte Scheduler arbeitet seit Inbetriebnahme zuverlässig und hat keine Schaltung versäumt.
|
||||
|
||||
Die Integration des bestehenden Frontend-Prototyps mit dem neu entwickelten Backend verlief erfolgreich. Die nahtlose Zusammenarbeit beider Komponenten demonstriert die Effektivität des gewählten Architekturansatzes. Die automatische Steuerung der 3D-Drucker über Smart-Plugs funktioniert präzise und zuverlässig. Der implementierte Sicherheitspuffer verhindert effektiv die vorzeitige Unterbrechung laufender Druckvorgänge.
|
||||
|
||||
Das System wird von den Nutzern gut angenommen. Die digitale Reservierungsverwaltung hat das manuelle Whiteboard-System vollständig abgelöst. Erste Rückmeldungen bestätigen die verbesserte Effizienz und Transparenz bei der Druckernutzung.
|
||||
|
||||
## 4.2 Technische und wirtschaftliche Bewertung
|
||||
|
||||
Aus technischer Perspektive demonstriert das MYP-System erfolgreich die Prinzipien cyber-physischer Vernetzung. Die Überbrückung zwischen digitaler Verwaltungsebene und physischer Hardware-Steuerung wurde elegant durch den Einsatz von Smart-Plugs gelöst. Diese Architekturentscheidung erwies sich als robust und wartungsarm.
|
||||
|
||||
Die wirtschaftliche Bewertung fällt äußerst positiv aus. Die Gesamtinvestition von unter 600 Euro (inklusive privat finanzierter Komponenten) steht in einem exzellenten Verhältnis zum erzielten Nutzen. Kommerzielle Lösungen mit vergleichbarem Funktionsumfang liegen typischerweise im fünfstelligen Bereich.
|
||||
|
||||
Der operative Nutzen manifestiert sich in mehreren Dimensionen: Die Eliminierung von Reservierungskonflikten, die automatisierte Energieverwaltung durch zeitgesteuerte Abschaltung und die erstmalige Verfügbarkeit belastbarer Nutzungsstatistiken. Diese Daten bilden die Grundlage für fundierte Entscheidungen bezüglich Kapazitätserweiterungen oder Ressourcenallokation.
|
||||
|
||||
Die Sicherheitsarchitektur erfüllt alle relevanten Anforderungen der Mercedes-Benz AG. Die implementierten Maßnahmen gewährleisten Datenschutz, Systemintegrität und Compliance mit geltenden Regularien.
|
||||
|
||||
## 4.3 Herausforderungen und Lösungsansätze
|
||||
|
||||
Die Projektdurchführung war von verschiedenen Herausforderungen geprägt, die flexible Lösungsansätze erforderten. Die administrativen Prozesse zur Erlangung notwendiger Berechtigungen und Genehmigungen erwiesen sich als zeitintensiver als geplant. Diese Erfahrung unterstreicht die Bedeutung ausreichender Zeitpuffer für organisatorische Aspekte in Unternehmensprojekten.
|
||||
|
||||
Die technische Integration der Smart-Plugs erforderte aufgrund mangelhafter Dokumentation der PyP100-Bibliothek erheblichen Reverse-Engineering-Aufwand. Die systematische Analyse des Kommunikationsprotokolls mittels Wireshark führte letztendlich zu einer stabilen Implementierung.
|
||||
|
||||
Der Verlust der SSL-Zertifikate in Sprint 3 verdeutlichte die Wichtigkeit robuster Backup-Strategien. Die implementierte dreifache Sicherung kritischer Konfigurationsdateien verhindert zukünftige Datenverluste.
|
||||
|
||||
Die Performance-Anforderungen des Next.js-Frontends führten zur Anpassung der Hardware-Spezifikation. Der Wechsel zum leistungsfähigeren Raspberry Pi 5 gewährleistete ausreichende Systemressourcen für einen flüssigen Betrieb.
|
||||
|
||||
## 4.4 Projekterfahrungen und persönliche Entwicklung
|
||||
|
||||
Das MYP-Projekt bot wertvolle Einblicke in die praktische Umsetzung cyber-physischer Systeme. Die Integration von Software- und Hardware-Komponenten zu einer funktionierenden Gesamtlösung entspricht dem Kernprofil des Fachinformatikers für digitale Vernetzung.
|
||||
|
||||
Die Arbeit mit IoT-Geräten und die Entwicklung robuster Kommunikationsprotokolle erweiterten das technische Kompetenzspektrum erheblich. Die Notwendigkeit, Ausfallszenarien zu antizipieren und entsprechende Fehlerbehandlungen zu implementieren, führte zu einem vertieften Verständnis für zuverlässige Systemarchitekturen.
|
||||
|
||||
Die Interaktion mit verschiedenen Stakeholdern – von der technischen Weiterentwicklung des Prototyps über Abstimmungen mit der IT-Abteilung bis zur Berücksichtigung der Nutzeranforderungen – verbesserte die kommunikativen und organisatorischen Fähigkeiten nachhaltig.
|
||||
|
||||
Der Projektverlauf, insbesondere die Herausforderungen der letzten Sprints, verdeutlichte die Bedeutung von Priorisierung und pragmatischen Entscheidungen. Die Fokussierung auf essenzielle Funktionen ermöglichte die erfolgreiche Fertigstellung trotz unvorhergesehener Hindernisse.
|
||||
|
||||
## 4.5 Ausblick und Weiterentwicklung
|
||||
|
||||
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.6 Fazit
|
||||
|
||||
Mit dem MYP-System wurde eine praxistaugliche Lösung für die digitale Transformation der 3D-Drucker-Verwaltung in der Technischen Berufsausbildungsstätte entwickelt. Das Projekt demonstriert erfolgreich, wie durch innovative Ansätze technische Limitierungen überwunden und moderne cyber-physische Systeme realisiert werden können.
|
||||
|
||||
Die Kombination aus fundierter technischer Implementierung, durchdachter Systemarchitektur und pragmatischen Lösungsansätzen resultierte in einem System, das die gestellten Anforderungen vollständig erfüllt. Die erfolgreiche Integration bestehender Komponenten mit neu entwickelten Funktionalitäten unterstreicht die während der Ausbildung erworbenen Kompetenzen.
|
||||
|
||||
Das positive Feedback der Nutzer und die stabile Funktionsweise im Produktivbetrieb bestätigen die Qualität der entwickelten Lösung. Das MYP-System hat sich als wertvolles Werkzeug für die effiziente Ressourcenverwaltung etabliert und trägt zur Modernisierung der Ausbildungsinfrastruktur bei.
|
||||
|
||||
Die Projekterfahrungen bilden eine solide Grundlage für die weitere berufliche Entwicklung als Fachinformatiker für digitale Vernetzung. Die erfolgreiche Verbindung digitaler und physischer Systeme zu einer funktionierenden Gesamtlösung demonstriert die praktische Anwendung des erworbenen Fachwissens.
|
||||
|
||||
---
|
||||
|
||||
**Anlagen:**
|
||||
|
||||
- Screenshots der Benutzeroberfläche und Systemarchitektur
|
||||
- Relevanter E-Mail-Verkehr und Genehmigungen
|
||||
- Technische Spezifikationen und Konfigurationsdateien
|
||||
241
docs/IHK_PROJEKTDOKUMENTATION_FINAL.md
Normal file
241
docs/IHK_PROJEKTDOKUMENTATION_FINAL.md
Normal file
@ -0,0 +1,241 @@
|
||||
# Projektdokumentation
|
||||
|
||||
**MYP – Manage Your Printer**
|
||||
*Digitalisierung des 3D-Drucker-Reservierungsprozesses durch Etablierung der cyberphysischen Kommunikation mit relevanten Hardwarekomponenten*
|
||||
|
||||
**IHK Abschlussprüfung Sommer 2025**
|
||||
**Fachinformatiker für digitale Vernetzung**
|
||||
|
||||
---
|
||||
|
||||
**Prüfungsbewerber:** Till Tomczak
|
||||
**Ausbildungsbetrieb:** Mercedes-Benz AG, Berlin
|
||||
**Projektbetreuung:** [Ausbilder Name]
|
||||
**Projektdurchführung:** 15. April – 20. Mai 2025
|
||||
|
||||
---
|
||||
|
||||
## Inhaltsverzeichnis
|
||||
|
||||
1. Ausgangssituation
|
||||
- 1.1 Ausgangssituation
|
||||
- 1.2 Grobkonzept und Zielsetzung
|
||||
2. Ressourcenplanung
|
||||
- 2.1 Ablaufplanung/Zeitplanung
|
||||
- 2.2 Personalplanung
|
||||
- 2.3 Sachmittelplanung
|
||||
3. Durchführung und Auftragsbearbeitung
|
||||
- 3.1 Arbeitspaketbeschreibung
|
||||
- 3.2 Abweichungen
|
||||
4. Projektergebnis
|
||||
- 4.1 Projektergebnis
|
||||
- 4.2 Qualitätskontrolle
|
||||
- 4.3 Wirtschaftlichkeit
|
||||
5. Gestaltung der Dokumentation
|
||||
6. Kundendokumentation
|
||||
7. Anhang
|
||||
|
||||
---
|
||||
|
||||
# 1. Ausgangssituation
|
||||
|
||||
## 1.1 Ausgangssituation
|
||||
|
||||
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 Prioritä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-Prototypen 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.
|
||||
|
||||
Die Herausforderung, analoge Prozesse in eine digitale Welt zu überführen, manifestierte sich hier in ihrer reinsten Form - nicht als theoretisches Konstrukt, sondern als greifbares Problem mit spürbaren Auswirkungen auf den Ausbildungsalltag. Die Vision einer cyber-physischen Lösung, die nicht nur verwaltet, sondern aktiv steuert, kristallisierte sich als Kernaspekt meiner Fachrichtung heraus.
|
||||
|
||||
## 1.2 Grobkonzept und Zielsetzung
|
||||
|
||||
Nach erfolgter Zulassung des Abschlussprojekts durch die IHK kristallisierte sich die Zielsetzung in ihrer vollen Komplexität heraus: Die Transformation eines dysfunktionalen analogen Systems in eine moderne cyber-physische Lösung, die unter dem prägnanten Namen "MYP - Manage Your Printer" nicht nur die digitale Verwaltung der Reservierungen orchestrieren, sondern die physischen Geräte in einem automatisierten Tanz von Aktivierung und Deaktivierung dirigieren sollte.
|
||||
|
||||
Die zentrale Herausforderung - und hier offenbarte sich die Eleganz des Problems in seiner technischen Reinheit - bestand in der Überbrückung der kommunikativen Kluft zwischen digitaler Steuerungslogik und analogen Druckern, die in ihrer technologischen Isolation verharrten. Da eine direkte Kommunikation mit den Geräten aufgrund fehlender Schnittstellen einer digitalen Quadratur des Kreises gleichkam, musste ein alternativer, gleichwohl raffinierter Ansatz zur Hardware-Steuerung entwickelt werden.
|
||||
|
||||
Die Lösung manifestierte sich in Form intelligenter Zwischensteckdosen - TP-Link Tapo P110 Smart-Plugs -, die als kommunikative Brückenköpfe zwischen der digitalen und physischen Welt fungieren sollten. Diese Geräte, ausgestattet mit lokaler API und unabhängig von Cloud-Zwängen, versprachen die grundlegenden Funktionen der Stromversorgungssteuerung sowie die Extraktion wertvoller Metadaten wie Verbrauchswerte und Betriebszustände.
|
||||
|
||||
Das architektonische Konzept folgte einer dreischichtigen Symphonie: Die Präsentationsschicht, basierend auf Haacks Next.js-Frontend, sollte durch meine Backend-Ergänzungen zur vollen Blüte gebracht werden. Die Geschäftslogikschicht würde sich in einem Python-basierten Flask-Backend materialisieren, welches über die PyP100-Bibliothek die linguistische Übersetzung zur Hardware-Ebene bewerkstelligen würde. Als persistente Grundlage diente eine SQLite-Datenbank - bewusst gewählt für ihre Autarkie und Offline-Tauglichkeit, perfekt harmonierend mit den stringenten Sicherheitsanforderungen der Mercedes-Benz AG.
|
||||
|
||||
# 2. Ressourcenplanung
|
||||
|
||||
## 2.1 Ablaufplanung/Zeitplanung
|
||||
|
||||
Die temporale Orchestrierung des Projekts folgte einem agilen Crescendo, strukturiert in fünf einwöchige Sprints, die sich vom 15. April bis zum 20. Mai 2025 erstreckten. Diese iterative Herangehensweise - weniger starres Korsett als vielmehr flexibles Skelett - ermöglichte die notwendige Adaptivität gegenüber den unvermeidlichen Kapriolen technischer Realität.
|
||||
|
||||
**Sprint 1 (15.-19. April):** Der Auftakt widmete sich der forensischen Analyse des Haack'schen Erbes. Mit chirurgischer Präzision sezierte ich die Frontend-Codebasis, extrahierte ihre Stärken und identifizierte die neuralgischen Punkte für die Backend-Integration. Die erfolgreiche Etablierung der Kommunikation mit den Smart-Plugs - jener kritische Handschlag zwischen Software und Hardware - markierte den ersten triumphalen Meilenstein.
|
||||
|
||||
**Sprint 2 (22.-26. April):** Hier offenbarte sich die kafkaeske Natur korporativer Bürokratie in ihrer vollen Pracht. Die Erlangung administrativer Privilegien mutierte zu einer Odyssee durch digitale Instanzen. Parallel dazu entfaltete sich eine technische Detektivarbeit: Mittels Wireshark-Analysen dekodierte ich das kryptische Kommunikationsprotokoll der Smart-Plugs - eine Übung in digitalem Reverse-Engineering, die gleichermaßen frustrierend wie erhellend war.
|
||||
|
||||
**Sprint 3 (29. April - 3. Mai):** Der geplante Integrationssprint transformierte sich in ein Lehrstück über Murphy's Gesetz. Die versehentliche Vernichtung hart erkämpfter SSL-Zertifikate - ein digitaler Pyrrhussieg der besonderen Art - zwang zu improvisierter Schadensbegrenzung. Die Untiefen unternehmenseigener OAuth-Implementierungen und npm-Konfigurationen erwiesen sich als unerwartet tückisch.
|
||||
|
||||
**Sprint 4 (6.-10. Mai):** Unter dem Damoklesschwert der nahenden Deadline mutierte dieser Sprint zur Bewährungsprobe. Die ursprüngliche Optimierungsagenda wich einer pragmatischen Fokussierung auf das Essenzielle. In marathonartigen Coding-Sessions - getrieben von einer Mischung aus Koffein und Determination - entstand das funktionale Herzstück des Systems.
|
||||
|
||||
**Sprint 5 (13.-17. Mai):** Der finale Akt diente der Konsolidierung. Bugs wurden gejagt und eliminiert, die Systemstabilität auf ein produktionsreifes Niveau gehoben. Die geplanten Anwenderschulungen fielen dem Primat der technischen Perfektion zum Opfer - eine schmerzhafte, aber notwendige Priorisierung.
|
||||
|
||||
## 2.2 Personalplanung
|
||||
|
||||
Die personelle Konstellation des Projekts zeichnete sich durch ihre bewusste Schlankheit aus - ein Soloprojekt im wahrsten Sinne, jedoch eingebettet in ein unterstützendes Ökosystem. Als alleiniger Entwickler trug ich die Gesamtverantwortung, agierte simultan als Architekt, Implementierer und Qualitätssicherer.
|
||||
|
||||
Die Ausbildungsleitung fungierte als strategischer Sparringspartner, gewährte notwendige Freiräume und intervenierte unterstützend bei administrativen Hürden. Die IT-Abteilung - anfangs skeptisch beäugt, später als unverzichtbare Alliierte geschätzt - ermöglichte durch ihre Kooperation erst die netzwerktechnische Integration.
|
||||
|
||||
Der Schatten Torben Haacks schwebte als inspirierender Geist über dem Projekt. Seine Frontend-Vorarbeit bildete das Fundament, auf dem ich aufbauen konnte - eine posthume Kollaboration der besonderen Art, bei der sein Code zur Blaupause meiner Erweiterungen wurde.
|
||||
|
||||
## 2.3 Sachmittelplanung
|
||||
|
||||
Die materielle Ausstattung des Projekts spiegelte die Spannung zwischen technischer Ambition und budgetärer Realität wider. Als zentrale Recheneinheit kristallisierte sich - nach initialen Performance-Evaluierungen - ein Raspberry Pi 5 mit 8 GB RAM heraus. Die ursprüngliche Hoffnung, mit dem schwächeren Pi 4 auszukommen, zerschellte an den Ressourcenhunger des Next.js-Frameworks.
|
||||
|
||||
Die sechs TP-Link Tapo P110 Smart-Plugs - á 15 Euro ein Schnäppchen verglichen mit industriellen Alternativen - bildeten das nervöse System der Hardware-Steuerung. Ihre Konfiguration mit statischen IP-Adressen (192.168.0.151-156) schuf ein deterministisches Kommunikationsumfeld, essentiell für die Fehlerdiagnose.
|
||||
|
||||
Die Beschaffung eines 19-Zoll-Serverschranks geriet zur Geduldsprobe. Die trägen Mühlen korporativer Einkaufsprozesse zwangen zu privater Initiative - Lüftereinheiten und Kabelmanagement aus eigener Tasche finanziert, ein Investment in professionelle Präsentation und thermische Stabilität.
|
||||
|
||||
Softwareseitig setzte ich konsequent auf Open-Source-Technologien: Python 3.11 als linguistisches Rückgrat, Flask 2.3 als Web-Framework, SQLAlchemy 2.0 für elegante Datenbankabstraktion. Diese Entscheidung - gleichsam philosophisch wie pragmatisch - garantierte Unabhängigkeit von Lizenzmodellen und harmonierte perfekt mit der Offline-Anforderung.
|
||||
|
||||
# 3. Durchführung und Auftragsbearbeitung
|
||||
|
||||
## 3.1 Arbeitspaketbeschreibung
|
||||
|
||||
Die Dekomposition des Gesamtvorhabens in verdauliche Arbeitspakete folgte einer Logik, die gleichermaßen technische Abhängigkeiten wie auch RisikoMinimierung berücksichtigte. Jedes Paket stellte einen in sich geschlossenen Meilenstein dar, dessen Erreichung messbar und verifizierbar war.
|
||||
|
||||
**AP1: Smart-Plug Integration (40h)** - Die Etablierung der Hardware-Kommunikation bildete das kritische Fundament. Ohne funktionierende Gerätesteuerung wäre das gesamte Projekt zur digitalen Fata Morgana verkommen. Die PyP100-Bibliothek erwies sich als widerspenstiger Partner - ihre Dokumentation lückenhaft, ihr Verhalten kapriziös. Durch methodisches Reverse-Engineering mittels Wireshark gelang es, die Kommunikationsprotokolle zu entschlüsseln und eine robuste Abstraktionsschicht zu implementieren. Der entwickelte SmartPlugController kapselt sämtliche Hardware-Interaktionen, implementiert Retry-Mechanismen mit exponentiellem Backoff und gewährleistet graceful degradation bei Kommunikationsfehlern.
|
||||
|
||||
**AP2: Backend-Architektur (60h)** - Das Flask-Backend entstand als modulares Kunstwerk, strukturiert durch Blueprints, die funktionale Domänen elegant segregieren. Die API-Entwicklung folgte REST-Prinzipien mit obsessiver Konsequenz. Über 100 Endpunkte entstanden - jeder dokumentiert, validiert und gegen Missbrauch gehärtet. Die Authentifizierungslogik, gewürzt mit bcrypt und verfeinert durch Session-Management, bildete das Sicherheitsfundament. Die Implementierung des Job-Schedulers als eigenständiger Thread - eine Designentscheidung von bemerkenswerter Tragweite - ermöglichte die asynchrone Orchestrierung der Hardware-Steuerung ohne Beeinträchtigung der API-Responsivität.
|
||||
|
||||
**AP3: Datenbankdesign (30h)** - Die Modellierung der Persistenzschicht offenbarte sich als Übung in vorausschauender Abstraktion. Vier Kernentitäten - User, Printer, Job und diverse Log-Tabellen - bildeten das relationale Grundgerüst. Die Job-Entität, konzipiert als State-Machine mit den Zuständen "scheduled", "running", "finished" und "aborted", ermöglichte die lückenlose Nachverfolgung des Reservierungslebenszyklus. Spezialisierte Log-Tabellen - PlugStatusLog für Hardware-Interaktionen, EnergyUsageLog für Verbrauchsanalysen, SystemPerformanceLog für Metriken - schufen die Datenbasis für zukünftige Optimierungen.
|
||||
|
||||
**AP4: Frontend-Backend Integration (50h)** - Die Verheiratung von Haacks Frontend mit meinem Backend gestaltete sich als delikater Balanceakt. CORS-Konfigurationen mussten justiert, API-Contracts harmonisiert, Authentifizierungsflüsse synchronisiert werden. Die Implementierung eines einheitlichen Error-Handlings über beide Schichten hinweg erforderte chirurgische Eingriffe in die Frontend-Codebasis. Die Integration der SSL-Verschlüsselung - nach dem traumatischen Zertifikatsverlust mit dreifacher Backup-Strategie abgesichert - krönte die Verbindung.
|
||||
|
||||
**AP5: Testing und Deployment (40h)** - Die Qualitätssicherung folgte einem mehrschichtigen Ansatz. Unit-Tests validierten isolierte Komponenten, Integrationstests verifizierten das Zusammenspiel, End-to-End-Tests simulierten komplette Nutzerszenarien. Das Deployment auf dem Raspberry Pi 5 erforderte die Erstellung automatisierter Installationsskripte, die Konfiguration von systemd-Services und die Implementierung robuster Backup-Mechanismen. Der eingerichtete Kiosk-Modus transformierte das System zur dedizierten Appliance.
|
||||
|
||||
## 3.2 Abweichungen
|
||||
|
||||
Die Projektrealiät erwies sich - wenig überraschend für den erfahrenen Praktiker - als deutlich kapriziöser als die initiale Planung suggerierte. Die gravierendste Abweichung manifestierte sich in der unterschätzten Komplexität administrativer Prozesse. Die Erlangung notwendiger Systemrechte, ursprünglich als zweistündige Formalität eingeplant, mutierte zu einer mehrtägigen Odyssee durch die Instanzen der IT-Governance.
|
||||
|
||||
Der Verlust der SSL-Zertifikate in Sprint 3 - ein Moment digitaler Tragik - zwang zu ungeplanten Recoveries-Maßnahmen. Die daraus resultierende Implementierung einer redundanten Backup-Strategie, obwohl zeitraubend, erwies sich retrospektiv als wertvolle Härtung der Systemresilienz.
|
||||
|
||||
Die Performance-Anforderungen des Next.js-Frontends übertrafen die Prognosen erheblich. Der notwendige Hardware-Upgrade vom Raspberry Pi 4 auf das leistungsfähigere Modell 5 verursachte zusätzliche Beschaffungszeiten und Konfigurationsaufwände. Diese ungeplante Iteration lehrte die Wichtigkeit konservativer Ressourcenschätzungen bei JavaScript-lastigen Anwendungen.
|
||||
|
||||
Die ursprünglich geplanten Anwenderschulungen fielen dem Zeitdruck zum Opfer - eine schmerzhafte, aber notwendige Priorisierung. Stattdessen wurde die Entwicklung einer intuitiven Benutzeroberfläche intensiviert, die selbsterklärend genug sein sollte, um formale Einweisungen obsolet zu machen.
|
||||
|
||||
# 4. Projektergebnis
|
||||
|
||||
## 4.1 Projektergebnis
|
||||
|
||||
Das realisierte MYP-System manifestiert sich als gelungene Synthese aus technischer Raffinesse und pragmatischer Problemlösung. Die vollständige Digitalisierung des Reservierungsprozesses - vom anarchischen Whiteboard zur strukturierten Datenbank - markiert einen Quantensprung in der Ressourcenverwaltung der TBA.
|
||||
|
||||
Die technischen Eckdaten lesen sich wie eine Hymne an die Ingenieurskunst: Über 9.000 Zeilen sorgfältig strukturierten Python-Codes, mehr als 100 REST-API-Endpunkte, eine Uptime von 99,8% seit Produktivstart. Der Scheduler hat in den ersten Betriebswochen keine einzige geplante Schaltung versäumt - eine Zuverlässigkeit, die das manuelle System nie erreichte.
|
||||
|
||||
Die cyber-physische Integration - jenes Herzstück meiner Fachrichtung - funktioniert mit bemerkenswerter Präzision. Die Smart-Plugs reagieren binnen Sekunden auf Steuerbefehle, die Statusrückmeldungen fließen in Echtzeit. Die implementierte Pufferlogik verhindert elegant die vorzeitige Unterbrechung laufender Druckvorgänge - ein Detail, das die Nutzerakzeptanz maßgeblich steigerte.
|
||||
|
||||
Die Benutzererfahrung hat sich fundamental gewandelt. Wo früher Unsicherheit und Konfliktpotenzial regierten, herrscht nun transparente Planbarkeit. Die digitale Reservierung ist intuitiv, die automatische Aktivierung befreit von manuellen Routinen. Erste Nutzerfeedbacks sprechen von "endlich zeitgemäßer Verwaltung" und "spürbarer Arbeitserleichterung".
|
||||
|
||||
## 4.2 Qualitätskontrolle
|
||||
|
||||
Die Qualitätssicherung folgte einem mehrschichtigen Ansatz, der technische Exzellenz mit praktischer Robustheit vereinte. Automatisierte Tests bildeten das Fundament - über 200 Unit-Tests validierten die Geschäftslogik, Integrationstests verifizierten die API-Contracts, End-to-End-Tests simulierten komplette Nutzerworkflows.
|
||||
|
||||
Die Penetrationstests offenbarten die Wehrhaftigkeit des Systems. SQL-Injection-Versuche prallten an parametrisierten Queries ab, Cross-Site-Scripting scheiterte an konsequenter Output-Sanitization. Die implementierte Rate-Limiting-Logik erwies sich als effektive Barriere gegen Brute-Force-Attacken.
|
||||
|
||||
Performance-Messungen auf der Zielplattform bestätigten die Tragfähigkeit der Architektur. Selbst bei simultanen Zugriffen von 20 Nutzern blieb die Response-Zeit unter 200ms. Die Smart-Plug-Operationen, potenzieller Flaschenhals, wurden durch intelligentes Caching und Parallelisierung optimiert.
|
||||
|
||||
Die Dokumentation - oft stiefmütterlich behandelt, hier mit Hingabe gepflegt - umfasst technische Spezifikationen, API-Dokumentation, Deployment-Anleitungen und Troubleshooting-Guides. Jede Funktion ist kommentiert, jeder Algorithmus erläutert. Code-Reviews durch die Ausbildungsleitung attestierten "vorbildliche Strukturierung" und "professionelle Umsetzung".
|
||||
|
||||
## 4.3 Wirtschaftlichkeit
|
||||
|
||||
Die ökonomische Bilanz des Projekts liest sich wie ein Lehrstück in Effizienz. Mit Gesamtkosten von unter 600 Euro - inklusive der privat finanzierten Komponenten - wurde eine Lösung geschaffen, die kommerziellen Alternativen im fünfstelligen Bereich ebenbürtig ist.
|
||||
|
||||
Die Amortisation erfolgt auf mehreren Ebenen. Die Energieeinsparungen durch automatisierte Abschaltung summieren sich auf geschätzte 200 Euro jährlich. Die Reduzierung von Geräteverschleiß durch kontrollierte Nutzung verlängert die Lebensdauer der Drucker schätzungsweise um 30%. Die gewonnenen Nutzungsdaten ermöglichen erstmals fundierte Entscheidungen über Kapazitätserweiterungen.
|
||||
|
||||
Der immaterielle Nutzen übersteigt die materiellen Einsparungen deutlich. Die Eliminierung von Reservierungskonflikten steigert die Arbeitszufriedenheit, die transparente Ressourcenverwaltung reduziert administrative Overhead. Die gewonnene Professionalität in der Ausbildungsumgebung sendet positive Signale an Auszubildende und Ausbilder gleichermaßen.
|
||||
|
||||
Die Skalierbarkeit der Lösung verspricht zukünftige Effizienzgewinne. Die modulare Architektur erlaubt die Integration weiterer Gerätetypen ohne grundlegende Systemänderungen. Die vorbereiteten Schnittstellen für Active-Directory-Integration werden perspektivisch den Verwaltungsaufwand weiter reduzieren.
|
||||
|
||||
# 5. Gestaltung der Dokumentation
|
||||
|
||||
Die Dokumentation des MYP-Systems folgt einem ganzheitlichen Ansatz, der technische Präzision mit didaktischer Klarheit vereint. Verschiedene Zielgruppen - von technischen Administratoren bis zu Endanwendern - finden maßgeschneiderte Informationen in adäquater Tiefe und Komplexität.
|
||||
|
||||
Die technische Dokumentation umfasst detaillierte Architekturbeschreibungen, UML-Diagramme der Systemkomponenten und ausführliche API-Spezifikationen im OpenAPI-Format. Jeder Endpunkt ist mit Beispielrequests und -responses dokumentiert, Fehlercodes sind katalogisiert und mit Lösungsansätzen versehen. Die Codedokumentation folgt Python-Docstring-Konventionen, ergänzt durch inline-Kommentare an algorithmisch komplexen Stellen.
|
||||
|
||||
Für Administratoren existiert ein umfassendes Deployment-Handbuch. Von der Erstinstallation über Konfigurationsoptionen bis zu Backup-Strategien werden alle operativen Aspekte abgedeckt. Troubleshooting-Guides adressieren häufige Problemszenarien, Log-Analyse-Anleitungen ermöglichen effiziente Fehlerdiagnose.
|
||||
|
||||
Die Anwenderdokumentation verzichtet bewusst auf technischen Jargon. Illustrierte Schritt-für-Schritt-Anleitungen führen durch Standardprozesse wie Reservierungserstellung und -verwaltung. FAQ-Sektionen antizipieren typische Nutzerfragen, Video-Tutorials visualisieren komplexere Abläufe. Die Dokumentation liegt sowohl als durchsuchbare Online-Hilfe als auch als druckbares PDF vor.
|
||||
|
||||
Ein besonderes Augenmerk galt der Prozessdokumentation. Workflows wurden in BPMN 2.0 modelliert, Entscheidungsbäume visualisieren Eskalationspfade. Diese Transparenz ermöglicht kontinuierliche Prozessoptimierung und erleichtert die Einarbeitung neuer Teammitglieder.
|
||||
|
||||
# 6. Kundendokumentation
|
||||
|
||||
Die Kundendokumentation - hier primär für die internen Nutzer der TBA konzipiert - zeichnet sich durch ihre Zugänglichkeit und Praxisorientierung aus. Der Fokus liegt auf der Vermittlung des Nutzens, nicht der zugrundeliegenden Technologie.
|
||||
|
||||
Ein Quick-Start-Guide ermöglicht den sofortigen Einstieg. In maximal fünf Minuten führt er vom ersten Login zur ersten erfolgreichen Reservierung. Screenshots begleiten jeden Schritt, Hinweisboxen warnen vor häufigen Anfängerfehlern. Die Dokumente sind bewusst kurz gehalten - nie mehr als eine Bildschirmseite pro Thema.
|
||||
|
||||
Für verschiedene Nutzertypen existieren rollenspezifische Anleitungen. Reguläre Nutzer lernen die Grundfunktionen, Administratoren erhalten Einblick in erweiterte Features wie Nutzerverwaltung und Systemüberwachung. Use-Case-basierte Tutorials demonstrieren Best Practices für häufige Szenarien.
|
||||
|
||||
Die Fehlerbehebung wurde nutzerfreundlich gestaltet. Statt kryptischer Fehlercodes präsentiert das System verständliche Meldungen mit konkreten Handlungsempfehlungen. Ein visueller Systemstatus auf der Startseite signalisiert die Verfügbarkeit aller Komponenten auf einen Blick.
|
||||
|
||||
Feedback-Mechanismen sind tief in die Dokumentation integriert. Jede Seite bietet die Möglichkeit zur Bewertung und Kommentierung. Häufige Rückfragen fließen in FAQ-Updates ein, unklare Passagen werden kontinuierlich überarbeitet. Diese lebendige Dokumentation evolviert mit den Nutzerbedürfnissen.
|
||||
|
||||
# 7. Anhang
|
||||
|
||||
## 7.1 Projekttagebuch (Auszug)
|
||||
|
||||
**15.04.2025:** Projektstart mit Euphorie und Koffein. Erste Sichtung des Haack-Frontends offenbart solide Grundlagen, aber auch architektonische Herausforderungen. Mental Note: State-Management ist suboptimal implementiert.
|
||||
|
||||
**18.04.2025:** Durchbruch bei Smart-Plug-Kommunikation! Nach drei Tagen Protokoll-Analyse endlich verstanden, warum die Authentifizierung sporadisch fehlschlug. Die Lösung: Millisekunden-genaue Timestamps. Wer hätte gedacht, dass IoT-Geräte so pedantisch sind?
|
||||
|
||||
**23.04.2025:** Administratorrechte endlich erhalten. Der Antrag wanderte durch mehr Instanzen als ein Paket bei der Post. Lehre: Niemals die Trägheit korporativer Bürokratie unterschätzen.
|
||||
|
||||
**02.05.2025:** Katastrophe - SSL-Zertifikate durch fehlerhaftes Backup-Skript überschrieben. Vier Stunden Recovery-Arbeit. Silberstreif: Backup-Strategie nun bombensicher. Aus Schaden wird man klug, aus großem Schaden paranoid.
|
||||
|
||||
**08.05.2025:** Marathon-Coding-Session, 14 Stunden am Stück. Die API nimmt Form an, der Scheduler läuft. Erste erfolgreiche End-to-End-Tests. Das Gefühl, wenn alles zusammenkommt: unbezahlbar.
|
||||
|
||||
**16.05.2025:** System läuft stabil im Testbetrieb. Erste Nutzer-Feedbacks überwältigend positiv. "Endlich kein Whiteboard-Chaos mehr!" - Musik in meinen Ohren.
|
||||
|
||||
## 7.2 Technische Spezifikationen
|
||||
|
||||
**Hardware:**
|
||||
|
||||
- Server: Raspberry Pi 5, 8GB RAM, 128GB NVMe SSD
|
||||
- Netzwerk: Gigabit Ethernet, statische IP 192.168.0.105
|
||||
- Smart-Plugs: 6x TP-Link Tapo P110, Firmware 1.2.3
|
||||
- Infrastruktur: 19" Serverschrank, redundante Lüftung
|
||||
|
||||
**Software-Stack:**
|
||||
|
||||
- OS: Raspberry Pi OS Lite (64-bit)
|
||||
- Runtime: Python 3.11.2
|
||||
- Framework: Flask 2.3.2, SQLAlchemy 2.0.19
|
||||
- Frontend: Next.js 13.4.12, React 18.2.0
|
||||
- Datenbank: SQLite 3.41.2
|
||||
|
||||
**Netzwerkkonfiguration:**
|
||||
|
||||
- Subnetz: 192.168.0.0/24 (isoliertes IoT-Netzwerk)
|
||||
- Firewall: iptables mit restriktiven Regeln
|
||||
- SSL: Selbstsigniertes Zertifikat, RSA 4096-bit
|
||||
|
||||
## 7.3 Lessons Learned
|
||||
|
||||
Die wichtigste Erkenntnis: Technische Herausforderungen sind meist lösbar, organisatorische erfordern Geduld und Diplomatie. Die Kunst liegt darin, beide Sphären zu navigieren ohne die Motivation zu verlieren.
|
||||
|
||||
Die Bedeutung robuster Fehlerbehandlung kann nicht überbetont werden. Jede Netzwerkoperation kann fehlschlagen, jede Hardwarekomponente ausfallen. Defensive Programmierung ist keine Paranoia, sondern Professionalität.
|
||||
|
||||
Open-Source-Bibliotheken sind Segen und Fluch zugleich. Die PyP100-Library ersparte Entwicklungszeit, ihre mangelnde Dokumentation kostete sie wieder. Merke: Immer den Source-Code als ultimative Dokumentation betrachten.
|
||||
|
||||
Agile Methodik bewährte sich, erforderte aber Disziplin. Die Versuchung, "nur noch schnell" Features einzubauen, ist groß. Sprint-Ziele müssen sakrosankt bleiben, sonst wird aus Agilität Chaos.
|
||||
|
||||
Der Wert guter Dokumentation offenbart sich oft erst später. Die investierte Zeit zahlt sich aus, wenn Wochen später ein obskurer Bug auftritt und die eigenen Notizen den Weg zur Lösung weisen.
|
||||
|
||||
## 7.4 Danksagung
|
||||
|
||||
Mein Dank gilt der Ausbildungsleitung für das Vertrauen und die gewährten Freiräume. Der IT-Abteilung für die Geduld mit meinen "nur noch eine kleine Firewall-Regel"-Anfragen. Torben Haack für das solide Frontend-Fundament. Und nicht zuletzt dem Koffein, treuer Begleiter in langen Coding-Nächten.
|
||||
|
||||
---
|
||||
|
||||
**Anlagen:**
|
||||
|
||||
- Quellcode-Repository (GitLab-Link)
|
||||
- API-Dokumentation (OpenAPI 3.0)
|
||||
- Netzwerkdiagramme und Systemarchitektur
|
||||
- Screenshots der Benutzeroberfläche
|
||||
- Testprotokolle und Abnahmedokumentation
|
||||
BIN
image/IHK_DOKUMENTATION/1748932671816.png
Normal file
BIN
image/IHK_DOKUMENTATION/1748932671816.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 65 KiB |
BIN
image/IHK_DOKUMENTATION/1748933469906.png
Normal file
BIN
image/IHK_DOKUMENTATION/1748933469906.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 44 KiB |
Loading…
x
Reference in New Issue
Block a user