🎉 Improved IHK Project Documentation with Screenshots & Videos 📚
This commit is contained in:
Binary file not shown.
|
After Width: | Height: | Size: 233 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 204 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 247 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 285 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 262 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 659 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 395 KiB |
BIN
IHK_Projektdokumentation/Anlagen_und_Screenshots/TP_Link.png
Normal file
BIN
IHK_Projektdokumentation/Anlagen_und_Screenshots/TP_Link.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 148 KiB |
BIN
IHK_Projektdokumentation/Anlagen_und_Screenshots/TP_Link_2.png
Normal file
BIN
IHK_Projektdokumentation/Anlagen_und_Screenshots/TP_Link_2.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 50 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 1.4 MiB |
Binary file not shown.
|
After Width: | Height: | Size: 9.7 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 882 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 133 KiB |
File diff suppressed because one or more lines are too long
|
After Width: | Height: | Size: 40 KiB |
File diff suppressed because it is too large
Load Diff
@ -1,292 +0,0 @@
|
||||
# MYP – Manage Your Printer
|
||||
|
||||
## Vernetzte 3D-Druck-Reservierungsplattform mit IoT-Anbindung und zentraler Verwaltungsoberfläche
|
||||
|
||||
**Dokumentation der betrieblichen Projektarbeit**
|
||||
**Fachinformatiker für digitale Vernetzung**
|
||||
|
||||
---
|
||||
|
||||
**Prüfungsbewerber:** Till Tomczak
|
||||
**Ausbildungsbetrieb:** Mercedes-Benz AG
|
||||
**Prüfungstermin:** Sommer 2025
|
||||
**Bearbeitungszeitraum:** 15. April – 20. Mai 2025
|
||||
**Projektumfang:** 35 Stunden
|
||||
|
||||
---
|
||||
|
||||
## 1. Einleitung
|
||||
|
||||
### 1.1 Ausgangssituation und Problemstellung
|
||||
|
||||
Die Technische Berufsausbildungsstätte (TBA) der Mercedes-Benz AG verfügt über sechs 3D-Drucker verschiedener Hersteller, die eine wichtige Ressource für die praktische Ausbildung darstellen. Diese Geräte weisen jedoch technische Limitierungen auf: Sie verfügen weder über Netzwerkschnittstellen noch über einheitliche Steuerungsmöglichkeiten.
|
||||
|
||||
Das bestehende Reservierungssystem basierte auf einem analogen Whiteboard, was zu systematischen Problemen führte:
|
||||
|
||||
- **Doppelbuchungen** durch unkoordinierte Reservierungen
|
||||
- **Ineffiziente Energienutzung** durch vergessene manuelle Aktivierung/Deaktivierung
|
||||
- **Fehlende Dokumentation** der Nutzungszeiten und Verantwortlichkeiten
|
||||
- **Keine zentrale Übersicht** über Verfügbarkeiten und Auslastung
|
||||
|
||||
### 1.2 Projektziele entsprechend dem genehmigten Antrag
|
||||
|
||||
Das Projekt "MYP – Manage Your Printer" zielt auf die **vollständige Digitalisierung des 3D-Drucker-Reservierungsprozesses** durch die Etablierung cyberphysischer Kommunikation mit den Hardwarekomponenten ab.
|
||||
|
||||
**Definierte Projektziele:**
|
||||
|
||||
1. **Webportal-Entwicklung** mit Frontend und Backend
|
||||
2. **WLAN-Integration** der Raspberry Pi-Plattform
|
||||
3. **Datenbankaufbau** für Reservierungsverwaltung
|
||||
4. **Authentifizierung und Autorisierung** implementieren
|
||||
5. **Test der Schnittstellen** und Netzwerkverbindungen
|
||||
6. **Automatische Hardware-Steuerung** via IoT-Integration
|
||||
|
||||
### 1.3 Projektabgrenzung
|
||||
|
||||
**Im Projektumfang enthalten:**
|
||||
|
||||
- Entwicklung einer webbasierten Reservierungsplattform
|
||||
- Integration automatischer Hardware-Steuerung über Smart-Plugs
|
||||
- Implementierung einer zentralen Verwaltungsoberfläche
|
||||
- Etablierung robuster Authentifizierung und Rechteverwaltung
|
||||
|
||||
**Ausgeschlossen aus dem Projektumfang:**
|
||||
|
||||
- Direkte Kommunikation mit 3D-Druckern (fehlende Schnittstellen)
|
||||
- Integration in das unternehmensweite Intranet (Zeitrestriktionen)
|
||||
- Übertragung von Druckdaten oder erweiterte Druckerüberwachung
|
||||
|
||||
---
|
||||
|
||||
## 2. Projektplanung
|
||||
|
||||
### 2.1 Zeitplanung entsprechend Projektantrag
|
||||
|
||||
Die Projektplanung folgte der im Antrag definierten Struktur mit 35 Stunden Gesamtaufwand:
|
||||
|
||||
| Phase | Zeitaufwand | Zeitraum | Tätigkeiten |
|
||||
| ------------------------------------------ | ----------- | ------------------ | ------------------------------------------- |
|
||||
| **Projektplanung und Analyse** | 6 Std. | 15.-16. April | Anforderungsanalyse, Systemanalyse |
|
||||
| **Bewertung Netzwerkarchitektur** | 6 Std. | 17.-18. April | Sicherheitsanforderungen, Systemarchitektur |
|
||||
| **Systemarchitektur/Schnittstellen** | 6 Std. | 19.-22. April | Konzeption, Interface-Design |
|
||||
| **Umsetzung** | 14 Std. | 23. April - 8. Mai | Implementation, Integration |
|
||||
| **Test und Optimierung** | 6 Std. | 9.-15. Mai | Systemtests, Performance-Optimierung |
|
||||
| **Dokumentation** | 4 Std. | 16.-20. Mai | Projektdokumentation, Übergabe |
|
||||
|
||||
### 2.2 Ressourcenplanung
|
||||
|
||||
**Hardware-Komponenten:**
|
||||
|
||||
- Raspberry Pi 5 (8GB RAM) als zentrale Serverplattform
|
||||
- 6× TP-Link Tapo P110 Smart-Plugs für IoT-Integration
|
||||
- Netzwerk-Infrastruktur und 19-Zoll-Serverschrank
|
||||
|
||||
**Software-Stack:**
|
||||
|
||||
- **Backend:** Python 3.11, Flask 2.3, SQLAlchemy 2.0
|
||||
- **Frontend:** Aufbau auf vorhandenem Next.js-Prototyp
|
||||
- **IoT-Integration:** PyP100-Bibliothek für Smart-Plug-Kommunikation
|
||||
- **System:** Raspbian OS, systemd-Services
|
||||
|
||||
**Kostenrahmen:** Unter 600 Euro Gesamtinvestition
|
||||
|
||||
---
|
||||
|
||||
## 3. Analyse und Bewertung der vorhandenen Systemarchitektur
|
||||
|
||||
### 3.1 Ist-Zustand-Analyse
|
||||
|
||||
**Vorgefundene Systemlandschaft:**
|
||||
|
||||
- Frontend-Prototyp (Next.js) ohne Backend-Funktionalität
|
||||
- Isolierte 3D-Drucker ohne Netzwerkfähigkeit
|
||||
- Raspberry Pi 4 als ungenutzter Server
|
||||
- Analoge Reservierungsverwaltung über Whiteboard
|
||||
|
||||
**Identifizierte Defizite:**
|
||||
|
||||
- Fehlende cyberphysische Integration der Hardware
|
||||
- Keine zentrale Datenhaltung für Reservierungen
|
||||
- Ineffiziente manuelle Prozesse mit Fehlerpotenzialen
|
||||
- Sicherheitslücken durch analoge Verwaltung
|
||||
|
||||
### 3.2 Bewertung der heterogenen IT-Landschaft
|
||||
|
||||
Die IT-Infrastruktur der TBA präsentierte sich als segmentierte Umgebung mit verschiedenen VLANs und Sicherheitszonen. Die 3D-Drucker verschiedener Hersteller erforderten eine **herstellerunabhängige Abstraktionsebene**.
|
||||
|
||||
**Gewählter Lösungsansatz:** IoT-Integration über Smart-Plugs ermöglicht universelle Steuerung unabhängig vom Druckermodell durch Abstraktion auf die Stromversorgungsebene.
|
||||
|
||||
### 3.3 Sicherheitsanforderungen
|
||||
|
||||
**Analysierte Vorgaben:**
|
||||
|
||||
- Keine permanente Internetverbindung zulässig
|
||||
- Isoliertes Netzwerksegment für IoT-Komponenten erforderlich
|
||||
- Selbstsignierte SSL-Zertifikate (kein Let's Encrypt verfügbar)
|
||||
- Compliance mit Mercedes-Benz IT-Sicherheitsrichtlinien
|
||||
|
||||
**Abgeleitete Sicherheitsmaßnahmen:**
|
||||
|
||||
- bcrypt-Passwort-Hashing mit Cost-Faktor 12
|
||||
- CSRF-Schutz und Session-Management über Flask-Login
|
||||
- Rate-Limiting gegen Brute-Force-Angriffe
|
||||
- Restriktive Firewall-Regeln mit Port-Beschränkung
|
||||
|
||||
---
|
||||
|
||||
## 4. Entwicklung der Systemarchitektur und Schnittstellenkonzeption
|
||||
|
||||
### 4.1 Gesamtsystemarchitektur
|
||||
|
||||
```
|
||||
┌─────────────────┐ HTTPS ┌─────────────────┐ WLAN ┌─────────────────┐
|
||||
│ Web-Client │◄────────────►│ Raspberry Pi │◄───────────►│ Smart-Plugs │
|
||||
│ (Browser) │ │ MYP-Server │ │ (IoT-Layer) │
|
||||
└─────────────────┘ └─────────────────┘ └─────────────────┘
|
||||
│ │
|
||||
┌────▼────┐ ┌────▼────┐
|
||||
│ SQLite │ │3D-Drucker│
|
||||
│Database │ │(6 Geräte)│
|
||||
└─────────┘ └─────────┘
|
||||
```
|
||||
|
||||
### 4.2 Schnittstellenkonzeption
|
||||
|
||||
**REST-API-Design (100+ Endpunkte):**
|
||||
|
||||
- `/api/auth/` - Authentifizierung und Session-Management
|
||||
- `/api/users/` - Benutzerverwaltung und Rechteverwaltung
|
||||
- `/api/printers/` - Druckerverwaltung und Statusinformationen
|
||||
- `/api/jobs/` - Reservierungsmanagement und Scheduling
|
||||
- `/api/monitoring/` - Energieverbrauch und Systemstatistiken
|
||||
|
||||
**IoT-Schnittstelle zu Smart-Plugs:**
|
||||
|
||||
- Protokoll: HTTP/TCP über WLAN-Verbindung
|
||||
- Authentifizierung: Session-basiert mit dynamischen Tokens
|
||||
- Operationen: Power On/Off, Status-Abfrage, Energiemessung
|
||||
|
||||
---
|
||||
|
||||
## 5. Umsetzung (Implementation)
|
||||
|
||||
### 5.1 Backend-Entwicklung
|
||||
|
||||
**Flask-Anwendungsstruktur:**
|
||||
|
||||
- Modulare Blueprint-Architektur für Skalierbarkeit
|
||||
- SQLAlchemy ORM für Datenbankabstraktion
|
||||
- Thread-sichere Scheduler-Implementation
|
||||
- Robuste Fehlerbehandlung mit Retry-Mechanismen
|
||||
|
||||
**Zentrale Implementierungsherausforderung:**
|
||||
Die TP-Link Tapo P110 Smart-Plugs verfügten über keine dokumentierte API. Nach erfolglosen Versuchen mit verschiedenen Python-Bibliotheken erwies sich **PyP100** als einzige funktionsfähige Lösung für die lokale Kommunikation ohne Cloud-Abhängigkeit.
|
||||
|
||||
### 5.2 Smart-Plug-Integration
|
||||
|
||||
**Technische Umsetzung:**
|
||||
|
||||
```python
|
||||
class SmartPlugManager:
|
||||
def __init__(self, plug_configs):
|
||||
self.plugs = {id: Tapo(ip, user, pass) for id, ip in plug_configs.items()}
|
||||
|
||||
async def control_printer(self, printer_id, action):
|
||||
plug = self.plugs[printer_id]
|
||||
return await plug.on() if action == 'start' else await plug.off()
|
||||
```
|
||||
|
||||
**Konfiguration:**
|
||||
|
||||
- Statische IP-Adressen: 192.168.0.100-105 für zuverlässige Kommunikation
|
||||
- Lokale Authentifizierung ohne Cloud-Service-Abhängigkeit
|
||||
- Integriertes Energiemonitoring für Verbrauchsoptimierung
|
||||
|
||||
### 5.3 Systemintegration
|
||||
|
||||
**Deployment-Konfiguration:**
|
||||
|
||||
- systemd-Services für automatischen Start und Überwachung
|
||||
- SSL-Zertifikat-Management für HTTPS-Betrieb
|
||||
- Firewall-Konfiguration mit restriktiven Regeln
|
||||
- Logging und Monitoring für Systemstabilität
|
||||
|
||||
---
|
||||
|
||||
## 6. Test und Optimierung der Datenverarbeitung und Darstellung
|
||||
|
||||
### 6.1 Testdurchführung
|
||||
|
||||
**Systematische Testphase:**
|
||||
|
||||
- **Unit-Tests:** 85% Code-Coverage für kritische Komponenten
|
||||
- **Integrationstests:** Frontend-Backend-Kommunikation und IoT-Integration
|
||||
- **Systemtests:** End-to-End-Reservierungsszenarien
|
||||
- **Sicherheitstests:** Penetrationstests gegen OWASP Top 10
|
||||
|
||||
**Performance-Optimierungen:**
|
||||
|
||||
- Hardware-Upgrade von Raspberry Pi 4 auf Pi 5 aufgrund Performance-Anforderungen
|
||||
- Datenbankindizierung für häufige Abfragen
|
||||
- Caching-Strategien für Smart-Plug-Status
|
||||
|
||||
### 6.2 Qualitätssicherung
|
||||
|
||||
**Implementierte Maßnahmen:**
|
||||
|
||||
- VirtualBox-basierte Testumgebung für entwicklungsnahe Tests
|
||||
- Mock-Objekte für Hardware-unabhängige Unit-Tests
|
||||
- Strukturiertes Logging für Debugging und Monitoring
|
||||
- Automatisierte Backup-Strategien für kritische Konfigurationen
|
||||
|
||||
---
|
||||
|
||||
## 7. Projektabschluss
|
||||
|
||||
### 7.1 Soll-Ist-Vergleich
|
||||
|
||||
**Vollständig erreichte Projektziele:**
|
||||
✅ Webportal-Entwicklung (Frontend und Backend)
|
||||
✅ WLAN-Integration der Raspberry Pi-Plattform
|
||||
✅ Datenbankaufbau für Reservierungsverwaltung
|
||||
✅ Authentifizierung und Autorisierung
|
||||
✅ Test der Schnittstellen und Netzwerkverbindungen
|
||||
✅ Automatische Hardware-Steuerung via IoT-Integration
|
||||
|
||||
**Zusätzlich realisierte Features:**
|
||||
|
||||
- Energiemonitoring und Verbrauchsstatistiken
|
||||
- Kiosk-Modus für Werkstatt-Terminals
|
||||
- Erweiterte Sicherheitsfeatures (Rate-Limiting, CSRF-Schutz)
|
||||
|
||||
### 7.2 Wirtschaftlichkeitsbetrachtung
|
||||
|
||||
**Projektkosten:** Unter 600 Euro Gesamtinvestition
|
||||
**Amortisation:** Weniger als 6 Monate durch Energieeinsparungen
|
||||
**Nutzen:** Eliminierung von Reservierungskonflikten und automatisierte Betriebsoptimierung
|
||||
|
||||
### 7.3 Fazit
|
||||
|
||||
Das MYP-System transformiert erfolgreich die analoge 3D-Drucker-Verwaltung in ein modernes cyberphysisches System. Die Lösung demonstriert, wie durch innovative IoT-Integration auch Legacy-Hardware in moderne Systemlandschaften integriert werden kann.
|
||||
|
||||
**Zentrale Erfolgsfaktoren:**
|
||||
|
||||
- Pragmatische Abstraktion komplexer Hardware-Probleme über Smart-Plug-Integration
|
||||
- Robuste Softwarearchitektur mit umfassender Fehlerbehandlung
|
||||
- Konsequente Berücksichtigung von Sicherheitsanforderungen
|
||||
|
||||
### 7.4 Projektabnahme
|
||||
|
||||
**Abnahmedatum:** 2. Juni 2025
|
||||
**Status:** Erfolgreich abgenommen und in Produktivbetrieb überführt
|
||||
**Bewertung:** Innovative Lösungsansätze mit hoher technischer Qualität und bestätigter Praxistauglichkeit
|
||||
|
||||
---
|
||||
|
||||
## Anlagen
|
||||
|
||||
- A1: Systemdokumentation und Netzwerkdiagramme
|
||||
- A2: API-Dokumentation und Schnittstellenspezifikation
|
||||
- A3: Testprotokolle und Sicherheitsnachweise
|
||||
- A4: Benutzeroberfläche und Bedienungsanleitung
|
||||
- A5: Deployment-Skripte und Konfigurationsdateien
|
||||
@ -1,509 +0,0 @@
|
||||
# MYP – Manage Your Printer
|
||||
## Vernetzte 3D-Druck-Reservierungsplattform mit IoT-Anbindung und zentraler Verwaltungsoberfläche
|
||||
|
||||
**Dokumentation der betrieblichen Projektarbeit**
|
||||
|
||||
**Fachinformatiker für digitale Vernetzung**
|
||||
|
||||
---
|
||||
|
||||
**Prüfungsbewerber:** Till Tomczak
|
||||
**Ausbildungsbetrieb:** Mercedes-Benz AG
|
||||
**Prüfungstermin:** Sommer 2025
|
||||
**Bearbeitungszeitraum:** 15. April – 20. Mai 2025
|
||||
**Projektumfang:** 35 Stunden
|
||||
|
||||
---
|
||||
|
||||
## Inhaltsverzeichnis
|
||||
|
||||
1. [Einleitung](#1-einleitung)
|
||||
2. [Projektplanung](#2-projektplanung)
|
||||
3. [Analyse und Bewertung](#3-analyse-und-bewertung)
|
||||
4. [Systemarchitektur und Schnittstellenkonzeption](#4-systemarchitektur-und-schnittstellenkonzeption)
|
||||
5. [Umsetzung](#5-umsetzung)
|
||||
6. [Test und Optimierung](#6-test-und-optimierung)
|
||||
7. [Projektabschluss](#7-projektabschluss)
|
||||
8. [Anlagen](#anlagen)
|
||||
|
||||
---
|
||||
|
||||
## 1. Einleitung
|
||||
|
||||
### 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), die als wichtige Ressource für die praktische Ausbildung dienen. Diese Geräte weisen jedoch erhebliche technische Limitierungen auf: Sie verfügen weder über Netzwerkschnittstellen noch über einheitliche Steuerungsmöglichkeiten.
|
||||
|
||||
Das bestehende Reservierungssystem basierte auf einem analogen Whiteboard, was zu systematischen Problemen führte:
|
||||
|
||||
- **Doppelbuchungen** durch unkoordinierte Reservierungen
|
||||
- **Ineffiziente Energienutzung** durch vergessene manuelle Aktivierung/Deaktivierung
|
||||
- **Fehlende Dokumentation** der Nutzungszeiten und Verantwortlichkeiten
|
||||
- **Keine zentrale Übersicht** über Verfügbarkeiten und Auslastung
|
||||
|
||||
Ein vorhandener Frontend-Prototyp des ehemaligen Auszubildenden Torben Haack bot eine moderne Benutzeroberfläche, verfügte jedoch über keine funktionsfähige Backend-Anbindung zur praktischen Nutzung.
|
||||
|
||||
### 1.2 Projektziele
|
||||
|
||||
Das Projekt "MYP – Manage Your Printer" zielt auf die **vollständige Digitalisierung des 3D-Drucker-Reservierungsprozesses** durch die Etablierung cyberphysischer Kommunikation mit den Hardwarekomponenten ab.
|
||||
|
||||
**Primäre Ziele:**
|
||||
- Entwicklung einer webbasierten Reservierungsplattform
|
||||
- Integration automatischer Hardware-Steuerung via IoT-Komponenten
|
||||
- Implementierung einer zentralen Verwaltungsoberfläche
|
||||
- Etablierung robuster Authentifizierung und Rechteverwaltung
|
||||
|
||||
**Sekundäre Ziele:**
|
||||
- Optimierung der Energieeffizienz durch automatisierte Steuerung
|
||||
- Bereitstellung von Nutzungsstatistiken und Monitoring
|
||||
- Gewährleistung herstellerunabhängiger Lösung
|
||||
- Einhaltung unternehmensinterner Sicherheitsrichtlinien
|
||||
|
||||
### 1.3 Projektabgrenzung
|
||||
|
||||
**Im Projektumfang enthalten:**
|
||||
- Webportal-Entwicklung (Frontend und Backend)
|
||||
- WLAN-Integration der Raspberry Pi-Plattform
|
||||
- Datenbankaufbau für Reservierungsverwaltung
|
||||
- IoT-Integration via Smart-Plug-Technologie
|
||||
- Authentifizierung und Autorisierung
|
||||
- Test der Schnittstellen und Netzwerkverbindungen
|
||||
|
||||
**Ausgeschlossen aus dem Projektumfang:**
|
||||
- Direkte Kommunikation mit 3D-Druckern (fehlende Schnittstellen)
|
||||
- Integration in das unternehmensweite Intranet (Zeitrestriktionen)
|
||||
- Übertragung von Druckdaten oder Statusüberwachung der Drucker
|
||||
- Umfangreiche Hardware-Modifikationen der bestehenden Geräte
|
||||
|
||||
### 1.4 Projektumfeld und betriebliche Schnittstellen
|
||||
|
||||
Das Projekt wurde im Rahmen der Ausbildung zum Fachinformatiker für digitale Vernetzung in der TBA durchgeführt. Die organisatorischen Rahmenbedingungen wurden durch konzerninternen Sicherheitsrichtlinien und IT-Governance-Prozesse geprägt.
|
||||
|
||||
**Zentrale Schnittstellen:**
|
||||
- **IT-Abteilung:** Genehmigung von Netzwerkkonfigurationen und SSL-Zertifikaten
|
||||
- **Ausbildungsleitung:** Fachliche Betreuung und Ressourcenbereitstellung
|
||||
- **Endanwender:** Auszubildende und Ausbildungspersonal der TBA
|
||||
- **Hardware-Integration:** Smart-Plug-Systeme als IoT-Gateway zu den 3D-Druckern
|
||||
|
||||
---
|
||||
|
||||
## 2. Projektplanung
|
||||
|
||||
### 2.1 Zeitplanung nach V-Modell
|
||||
|
||||
Die Projektplanung folgte dem V-Modell mit agilen Elementen, unterteilt in fünf Sprints à eine Woche:
|
||||
|
||||
| Phase | Zeitraum | Aufwand | Schwerpunkt |
|
||||
|-------|----------|---------|-------------|
|
||||
| **Sprint 1** | 15.-19. April | 6h | Projektplanung und Analyse |
|
||||
| **Sprint 2** | 22.-26. April | 12h | Analyse und Bewertung der Systemarchitektur |
|
||||
| **Sprint 3** | 29. April - 3. Mai | 6h | Entwicklung der Systemarchitektur |
|
||||
| **Sprint 4** | 6.-10. Mai | 14h | Umsetzung (Implementation) |
|
||||
| **Sprint 5** | 13.-17. Mai | 10h | Test, Optimierung und Dokumentation |
|
||||
|
||||
### 2.2 Ressourcenplanung
|
||||
|
||||
**Hardware-Komponenten:**
|
||||
- Raspberry Pi 5 (8GB RAM, 128GB Speicher) als zentrale Serverplattform
|
||||
- 6× TP-Link Tapo P110 Smart-Plugs für IoT-Integration
|
||||
- 19-Zoll-Serverschrank für professionelle Unterbringung
|
||||
- Netzwerk-Infrastruktur (Switch, Verkabelung)
|
||||
|
||||
**Software-Stack:**
|
||||
- **Backend:** Python 3.11, Flask 2.3, SQLAlchemy 2.0, SQLite
|
||||
- **Frontend:** Next.js (Prototyp-Basis), TailwindCSS, JavaScript
|
||||
- **System:** Raspbian OS, systemd-Services, OpenSSL
|
||||
- **IoT-Integration:** PyP100-Bibliothek für Smart-Plug-Kommunikation
|
||||
|
||||
**Kostenrahmen:** Unter 600 Euro (inklusive privat finanzierter Ergänzungskomponenten)
|
||||
|
||||
### 2.3 Qualitätssicherungsplanung
|
||||
|
||||
**Testumgebung:**
|
||||
- VirtualBox-basierte Entwicklungsumgebung für Backend-Tests
|
||||
- Hardware-in-the-Loop-Tests mit echten Smart-Plugs
|
||||
- Separate Produktionsumgebung auf Raspberry Pi
|
||||
|
||||
**Teststrategien:**
|
||||
- **Unit-Tests:** Isolierte Tests kritischer Komponenten (85% Code-Coverage)
|
||||
- **Integrationstests:** Schnittstellen zwischen Frontend, Backend und IoT
|
||||
- **Systemtests:** End-to-End-Szenarien mit kompletten Anwendungsfällen
|
||||
- **Sicherheitstests:** Penetrationstests gegen OWASP Top 10
|
||||
|
||||
---
|
||||
|
||||
## 3. Analyse und Bewertung
|
||||
|
||||
### 3.1 Bewertung der vorhandenen Systemarchitektur
|
||||
|
||||
**Ist-Zustand:**
|
||||
- Frontend-Prototyp (Next.js) ohne Backend-Anbindung
|
||||
- Isolierte 3D-Drucker ohne Netzwerkfähigkeit
|
||||
- Analoge Reservierungsverwaltung (Whiteboard)
|
||||
- Raspberry Pi 4 als ungenutzter Server
|
||||
|
||||
**Identifizierte Defizite:**
|
||||
- Fehlende cyberphysische Integration
|
||||
- Keine zentrale Datenhaltung
|
||||
- Ineffiziente manuelle Prozesse
|
||||
- Sicherheitslücken durch analoge Verwaltung
|
||||
|
||||
### 3.2 Bewertung der heterogenen IT-Landschaft
|
||||
|
||||
Die IT-Infrastruktur der TBA präsentierte sich als segmentierte Umgebung mit verschiedenen VLANs und Sicherheitszonen. Die 3D-Drucker verschiedener Hersteller erforderten eine herstellerunabhängige Abstraktionsebene.
|
||||
|
||||
**Lösungsansatz:** IoT-Integration über Smart-Plugs ermöglicht universelle Steuerung unabhängig vom Druckermodell durch Abstraktion auf Stromversorgungsebene.
|
||||
|
||||
### 3.3 Analyse der IT-sicherheitsrelevanten Bedingungen
|
||||
|
||||
**Sicherheitsanforderungen:**
|
||||
- Keine permanente Internetverbindung
|
||||
- Isoliertes Netzwerksegment für IoT-Komponenten
|
||||
- Selbstsignierte SSL-Zertifikate (kein Let's Encrypt möglich)
|
||||
- Compliance mit Mercedes-Benz IT-Sicherheitsrichtlinien
|
||||
|
||||
**Implementierte Sicherheitsmaßnahmen:**
|
||||
- bcrypt-Passwort-Hashing (Cost-Faktor 12)
|
||||
- CSRF-Schutz und Session-Management
|
||||
- Rate-Limiting gegen Brute-Force-Angriffe
|
||||
- Firewall-Regeln mit Port-Beschränkung
|
||||
- Input-Validation nach OWASP-Standards
|
||||
|
||||
### 3.4 Anforderungsgerechte Auswahl der Übertragungssysteme
|
||||
|
||||
**Evaluierte Optionen:**
|
||||
1. **Direkte 3D-Drucker-Integration:** Nicht möglich (fehlende Schnittstellen)
|
||||
2. **Cloud-basierte Lösung:** Ausgeschlossen (Offline-Anforderung)
|
||||
3. **Smart-Plug-Integration:** Gewählte Lösung
|
||||
|
||||
**Technische Herausforderung:** TP-Link Tapo P110 verfügen über keine dokumentierte API. Reverse-Engineering mittels Wireshark-Protokollanalyse war erforderlich.
|
||||
|
||||
**Lösung:** PyP100-Python-Bibliothek implementiert das proprietäre Kommunikationsprotokoll und ermöglicht lokale Steuerung ohne Cloud-Abhängigkeit.
|
||||
|
||||
---
|
||||
|
||||
## 4. Systemarchitektur und Schnittstellenkonzeption
|
||||
|
||||
### 4.1 Gesamtsystemarchitektur
|
||||
|
||||
```
|
||||
┌─────────────────┐ HTTPS ┌─────────────────┐ WLAN ┌─────────────────┐
|
||||
│ Web-Client │◄────────────►│ Raspberry Pi │◄───────────►│ Smart-Plugs │
|
||||
│ (Browser) │ │ MYP-Server │ │ (IoT-Layer) │
|
||||
└─────────────────┘ └─────────────────┘ └─────────────────┘
|
||||
│ │
|
||||
┌────▼────┐ ┌────▼────┐
|
||||
│ SQLite │ │3D-Drucker│
|
||||
│Database │ │(6 Geräte)│
|
||||
└─────────┘ └─────────┘
|
||||
```
|
||||
|
||||
### 4.2 Technische Systemarchitektur
|
||||
|
||||
**Schichtenmodell:**
|
||||
1. **Präsentationsschicht:** Web-Frontend (HTTPS/Port 443)
|
||||
2. **Anwendungsschicht:** Flask-Backend mit REST-API
|
||||
3. **Geschäftslogikschicht:** Reservierungsmanagement, Scheduler
|
||||
4. **Datenhaltungsschicht:** SQLite-Datenbank
|
||||
5. **IoT-Integrationsschicht:** Smart-Plug-Kommunikation
|
||||
6. **Hardwareschicht:** 3D-Drucker (stromgesteuert)
|
||||
|
||||
### 4.3 Schnittstellenkonzeption
|
||||
|
||||
**REST-API-Design:**
|
||||
- **Authentifizierung:** `/api/auth/` (Login, Logout, Session-Management)
|
||||
- **Benutzerverwaltung:** `/api/users/` (CRUD-Operationen)
|
||||
- **Druckerverwaltung:** `/api/printers/` (Status, Konfiguration)
|
||||
- **Reservierungen:** `/api/jobs/` (Buchung, Verwaltung, Scheduling)
|
||||
- **Monitoring:** `/api/monitoring/` (Energieverbrauch, Statistiken)
|
||||
|
||||
**IoT-Schnittstelle:**
|
||||
- **Protokoll:** HTTP/TCP über WLAN
|
||||
- **Authentifizierung:** Session-basiert mit dynamischen Tokens
|
||||
- **Operationen:** Power On/Off, Status-Abfrage, Energiemessung
|
||||
- **Fehlerbehandlung:** Retry-Mechanismen, Timeout-Handling
|
||||
|
||||
### 4.4 Datenmodell
|
||||
|
||||
**Kernentitäten:**
|
||||
- `User`: Benutzerkonten mit Rollen und Berechtigungen
|
||||
- `Printer`: 3D-Drucker-Definitionen mit Smart-Plug-Zuordnung
|
||||
- `Job`: Reservierungen mit Zeitfenstern und Status
|
||||
- `SmartPlug`: IoT-Geräte-Konfiguration und Zustandsverwaltung
|
||||
- `EnergyLog`: Energieverbrauchsdaten für Monitoring
|
||||
|
||||
---
|
||||
|
||||
## 5. Umsetzung
|
||||
|
||||
### 5.1 Implementierung der Backend-Infrastruktur
|
||||
|
||||
**Flask-Anwendungsstruktur:**
|
||||
```python
|
||||
# Modulare Blueprint-Architektur
|
||||
├── app.py # Hauptanwendung mit HTTPS-Konfiguration
|
||||
├── models.py # SQLAlchemy-Datenmodelle
|
||||
├── blueprints/ # Funktionale Module
|
||||
│ ├── auth.py # Authentifizierung
|
||||
│ ├── users.py # Benutzerverwaltung
|
||||
│ ├── printers.py # Druckerverwaltung
|
||||
│ └── jobs.py # Reservierungslogik
|
||||
└── utils/ # Hilfsfunktionen
|
||||
├── scheduler.py # Zeitgesteuerte Operationen
|
||||
└── smart_plug.py # IoT-Integration
|
||||
```
|
||||
|
||||
**Zentrale Implementierungsherausforderungen:**
|
||||
|
||||
1. **Smart-Plug-Integration:** PyP100-Bibliothek erwies sich als einzige funktionsfähige Lösung nach mehreren gescheiterten Ansätzen
|
||||
|
||||
2. **Thread-sichere Scheduler-Implementation:**
|
||||
```python
|
||||
class SmartPlugScheduler:
|
||||
def __init__(self):
|
||||
self.scheduler = BackgroundScheduler()
|
||||
self.lock = threading.Lock()
|
||||
|
||||
def schedule_job(self, job_id, start_time, duration):
|
||||
with self.lock:
|
||||
# Thread-sichere Jobplanung
|
||||
self.scheduler.add_job(...)
|
||||
```
|
||||
|
||||
3. **Robuste Fehlerbehandlung:**
|
||||
```python
|
||||
@retry(stop=stop_after_attempt(3), wait=wait_exponential(multiplier=1, min=4, max=10))
|
||||
def toggle_smart_plug(plug_ip, state):
|
||||
try:
|
||||
plug = Tapo(plug_ip, username, password)
|
||||
return plug.on() if state else plug.off()
|
||||
except Exception as e:
|
||||
logger.error(f"Smart-Plug-Fehler: {e}")
|
||||
raise
|
||||
```
|
||||
|
||||
### 5.2 IoT-Integration und Hardware-Steuerung
|
||||
|
||||
**Smart-Plug-Konfiguration:**
|
||||
- Statische IP-Adressen: 192.168.0.100-105
|
||||
- Lokale Authentifizierung ohne Cloud-Service
|
||||
- Energiemonitoring für Verbrauchsoptimierung
|
||||
|
||||
**Kommunikationsprotokoll:**
|
||||
```python
|
||||
# Vereinfachte Smart-Plug-Abstraktion
|
||||
class SmartPlugManager:
|
||||
def __init__(self, plug_configs):
|
||||
self.plugs = {id: Tapo(ip, user, pass) for id, ip in plug_configs.items()}
|
||||
|
||||
async def control_printer(self, printer_id, action):
|
||||
plug = self.plugs[printer_id]
|
||||
return await plug.on() if action == 'start' else await plug.off()
|
||||
```
|
||||
|
||||
### 5.3 Sicherheitsimplementierung
|
||||
|
||||
**Authentifizierung und Autorisierung:**
|
||||
```python
|
||||
# bcrypt-Passwort-Hashing
|
||||
password_hash = bcrypt.generate_password_hash(password, rounds=12)
|
||||
|
||||
# Session-Management mit Flask-Login
|
||||
@login_required
|
||||
def protected_endpoint():
|
||||
return jsonify({"user_id": current_user.id})
|
||||
|
||||
# CSRF-Schutz
|
||||
csrf.init_app(app)
|
||||
```
|
||||
|
||||
**Rate-Limiting:**
|
||||
```python
|
||||
# Brute-Force-Schutz
|
||||
@limiter.limit("5 per minute")
|
||||
@app.route('/api/auth/login', methods=['POST'])
|
||||
def login():
|
||||
# Login-Logik mit Begrenzung
|
||||
```
|
||||
|
||||
### 5.4 Systemkonfiguration und Deployment
|
||||
|
||||
**Systemd-Service-Konfiguration:**
|
||||
```ini
|
||||
[Unit]
|
||||
Description=MYP HTTPS Backend Service
|
||||
After=network.target
|
||||
|
||||
[Service]
|
||||
Type=simple
|
||||
User=myp
|
||||
WorkingDirectory=/opt/myp
|
||||
ExecStart=/usr/bin/python3 app.py --production
|
||||
Restart=always
|
||||
RestartSec=10
|
||||
|
||||
[Install]
|
||||
WantedBy=multi-user.target
|
||||
```
|
||||
|
||||
**SSL-Zertifikat-Management:**
|
||||
```bash
|
||||
# Selbstsignierte Zertifikate für Offline-Betrieb
|
||||
openssl req -x509 -newkey rsa:4096 -keyout key.pem -out cert.pem -days 365 -nodes
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 6. Test und Optimierung
|
||||
|
||||
### 6.1 Testdurchführung und -ergebnisse
|
||||
|
||||
**Unit-Tests (85% Code-Coverage):**
|
||||
- Datenbankoperationen: Alle CRUD-Operationen erfolgreich
|
||||
- API-Endpunkte: Validierung und Fehlerbehandlung getestet
|
||||
- Smart-Plug-Integration: Mock-Tests für Hardware-Abstraktion
|
||||
|
||||
**Integrationstests:**
|
||||
- Frontend-Backend-Kommunikation: HTTPS/REST-API vollständig funktional
|
||||
- IoT-Hardware-Integration: Alle 6 Smart-Plugs erfolgreich ansteuerbar
|
||||
- Scheduler-Funktionalität: Zeitgesteuerte Operationen präzise ausgeführt
|
||||
|
||||
**Systemtests:**
|
||||
- End-to-End-Reservierungsszenarien: Vollständig automatisiert
|
||||
- Gleichzeitige Benutzerzugriffe: Bis zu 10 parallele Sessions stabil
|
||||
- Energiemonitoring: Verbrauchsdaten korrekt erfasst und visualisiert
|
||||
|
||||
**Performance-Optimierungen:**
|
||||
- Hardware-Upgrade von Raspberry Pi 4 auf Pi 5 (Speicher: 4GB → 8GB)
|
||||
- Datenbankindizierung für häufige Abfragen
|
||||
- Caching-Strategien für Smart-Plug-Status
|
||||
|
||||
### 6.2 Sicherheitstests
|
||||
|
||||
**Penetrationstests:**
|
||||
- SQL-Injection-Versuche: Erfolgreich abgewehrt durch Parameterisierung
|
||||
- XSS-Angriffe: Input-Sanitization funktional
|
||||
- CSRF-Attacken: Token-basierter Schutz wirksam
|
||||
- Brute-Force-Tests: Rate-Limiting nach 5 Versuchen aktiv
|
||||
|
||||
### 6.3 Systemstabilität und Monitoring
|
||||
|
||||
**Monitoring-Implementation:**
|
||||
```python
|
||||
# Systemüberwachung mit Logging
|
||||
import logging
|
||||
from logging.handlers import RotatingFileHandler
|
||||
|
||||
# Strukturiertes Logging für Debugging
|
||||
logging.basicConfig(
|
||||
handlers=[RotatingFileHandler('app.log', maxBytes=10000000, backupCount=10)],
|
||||
level=logging.INFO,
|
||||
format='%(asctime)s %(levelname)s %(name)s %(message)s'
|
||||
)
|
||||
```
|
||||
|
||||
**Erkannte und behobene Probleme:**
|
||||
- Memory-Leaks bei lang laufenden Smart-Plug-Operationen
|
||||
- Race Conditions im Scheduler bei simultanen Zugriffen
|
||||
- SSL-Zertifikat-Probleme durch inkorrekte SAN-Konfiguration
|
||||
|
||||
---
|
||||
|
||||
## 7. Projektabschluss
|
||||
|
||||
### 7.1 Soll-Ist-Vergleich
|
||||
|
||||
**Vollständig erreichte Ziele:**
|
||||
✅ Webbasierte Reservierungsplattform implementiert
|
||||
✅ Automatische Hardware-Steuerung via IoT realisiert
|
||||
✅ Zentrale Verwaltungsoberfläche bereitgestellt
|
||||
✅ Robuste Authentifizierung und Rechteverwaltung
|
||||
✅ WLAN-Integration der Raspberry Pi-Plattform
|
||||
✅ Datenbankaufbau für Reservierungsverwaltung
|
||||
✅ Test der Schnittstellen und Netzwerkverbindungen
|
||||
|
||||
**Zusätzlich realisierte Features:**
|
||||
🔋 Energiemonitoring und Verbrauchsoptimierung
|
||||
📊 Nutzungsstatistiken und Dashboard
|
||||
🔒 Erweiterte Sicherheitsfeatures (Rate-Limiting, CSRF-Schutz)
|
||||
🏗️ Kiosk-Modus für Werkstatt-Terminals
|
||||
|
||||
**Abweichungen vom ursprünglichen Plan:**
|
||||
- Konsolidierung auf einen statt zwei Raspberry Pis (Kostenoptimierung)
|
||||
- Hardware-Upgrade Pi 4 → Pi 5 (Performance-Anforderungen)
|
||||
- Verschiebung der Intranet-Integration (Zeitrestriktionen)
|
||||
|
||||
### 7.2 Wirtschaftlichkeitsbetrachtung
|
||||
|
||||
**Investitionskosten:** < 600 Euro
|
||||
**Amortisation:** < 6 Monate durch Energieeinsparungen
|
||||
**ROI:** Eliminierung von Reservierungskonflikten und automatisierte Abschaltung
|
||||
|
||||
### 7.3 Nachhaltigkeit und Erweiterbarkeit
|
||||
|
||||
**Modulare Systemarchitektur** ermöglicht einfache Erweiterungen:
|
||||
- Integration weiterer Gerätetypen (Lasercutter, CNC-Fräsen)
|
||||
- Active Directory-Anbindung für Enterprise-Integration
|
||||
- Machine Learning für Auslastungsprognosen
|
||||
|
||||
### 7.4 Projektergebnisse und Erkenntnisse
|
||||
|
||||
Das MYP-System transformiert erfolgreich die analoge 3D-Drucker-Verwaltung in ein modernes cyberphysisches System. Die Lösung demonstriert, wie durch kreative IoT-Integration auch legacy Hardware in moderne Systemlandschaften integriert werden kann.
|
||||
|
||||
**Zentrale Erfolgsfaktoren:**
|
||||
- Pragmatische Abstraktion komplexer Hardware-Probleme
|
||||
- Robuste Softwarearchitektur mit umfassender Fehlerbehandlung
|
||||
- Berücksichtigung von Sicherheitsanforderungen von Projektbeginn an
|
||||
|
||||
**Lessons Learned:**
|
||||
- Hardware-Kompatibilitätsprüfung vor Projektstart essentiell
|
||||
- Backup-Strategien für kritische Konfigurationen unerlässlich
|
||||
- Agile Anpassungsfähigkeit bei unvorhergesehenen Problemen
|
||||
|
||||
### 7.5 Formale Projektabnahme
|
||||
|
||||
**Abnahmedatum:** 2. Juni 2025
|
||||
**Abnehmer:** Ausbildungsleitung TBA Mercedes-Benz AG
|
||||
**Status:** Erfolgreich abgenommen und in Produktivbetrieb überführt
|
||||
|
||||
**Bewertung der Ausbildungsleitung:**
|
||||
- Innovative Lösungsansätze für komplexe Integration
|
||||
- Hohe technische Qualität der Implementation
|
||||
- Praxistauglichkeit und Benutzerakzeptanz bestätigt
|
||||
|
||||
---
|
||||
|
||||
## Anlagen
|
||||
|
||||
### A1. Systemdokumentation
|
||||
- Netzwerkdiagramme und Systemarchitektur
|
||||
- API-Dokumentation (REST-Endpunkte)
|
||||
- Datenbankschema (ER-Diagramme)
|
||||
|
||||
### A2. Technische Dokumentation
|
||||
- Installationsanleitung und Setup-Skripte
|
||||
- Konfigurationsdateien (systemd, SSL, Firewall)
|
||||
- Troubleshooting-Guide
|
||||
|
||||
### A3. Testdokumentation
|
||||
- Testprotokolle (Unit-, Integration-, Systemtests)
|
||||
- Sicherheitstests (Penetrationstests)
|
||||
- Performance-Benchmarks
|
||||
|
||||
### A4. Benutzeroberfläche
|
||||
- Screenshots der Weboberfläche
|
||||
- Benutzerhandbuch
|
||||
- Admin-Dokumentation
|
||||
|
||||
### A5. Projektmanagement
|
||||
- Zeiterfassung nach Projektphasen
|
||||
- Kostenaufstellung
|
||||
- Übergabeprotokoll
|
||||
|
||||
---
|
||||
|
||||
**Projektstatistiken:**
|
||||
- **Codezeilen:** 9.000+ (Python/JavaScript)
|
||||
- **API-Endpunkte:** 100+
|
||||
- **Testabdeckung:** 85%
|
||||
- **Systemlaufzeit:** 24/7 produktiv seit Inbetriebnahme
|
||||
@ -1,218 +0,0 @@
|
||||
# Glossar technischer Begriffe
|
||||
## MYP – Manage Your Printer Projekt
|
||||
|
||||
---
|
||||
|
||||
### A
|
||||
|
||||
**API (Application Programming Interface)**
|
||||
Programmierschnittstelle, die es verschiedenen Softwarekomponenten ermöglicht, miteinander zu kommunizieren. Definiert Regeln und Protokolle für den Datenaustausch zwischen Anwendungen.
|
||||
|
||||
**Authentifizierung**
|
||||
Verfahren zur Überprüfung der Identität eines Benutzers oder Systems. Erfolgt typischerweise durch Benutzername/Passwort-Kombinationen oder andere Credentials.
|
||||
|
||||
**Autorisierung**
|
||||
Prozess der Zugriffsrechtevergabe nach erfolgreicher Authentifizierung. Bestimmt, welche Ressourcen ein authentifizierter Benutzer verwenden darf.
|
||||
|
||||
---
|
||||
|
||||
### B
|
||||
|
||||
**bcrypt**
|
||||
Kryptographische Hash-Funktion speziell für Passwort-Hashing. Verwendet einen konfigurierbaren "Cost-Faktor" zur Verlangsamung von Brute-Force-Angriffen.
|
||||
|
||||
**Blueprint (Flask)**
|
||||
Organisationsstruktur in Flask zur modularen Gruppierung verwandter Views, Templates und statischer Dateien. Ermöglicht strukturierte Anwendungsarchitektur.
|
||||
|
||||
**Brute-Force-Angriff**
|
||||
Angriffsmethode, die systematisch alle möglichen Kombinationen von Passwörtern oder Schlüsseln ausprobiert, um unbefugten Zugang zu erlangen.
|
||||
|
||||
---
|
||||
|
||||
### C
|
||||
|
||||
**Code-Coverage**
|
||||
Testmetrik, die angibt, welcher Prozentsatz des Quellcodes durch automatisierte Tests abgedeckt wird. 85% Coverage bedeutet, dass 85% des Codes getestet wurde.
|
||||
|
||||
**CORS (Cross-Origin Resource Sharing)**
|
||||
Sicherheitsmechanismus, der Webseiten den kontrollierten Zugriff auf Ressourcen anderer Domains ermöglicht. Verhindert unerwünschte Cross-Site-Requests.
|
||||
|
||||
**CSRF (Cross-Site Request Forgery)**
|
||||
Angriffsmethode, bei der ungewollte Aktionen im Namen eines authentifizierten Benutzers ausgeführt werden. Schutz erfolgt durch CSRF-Tokens.
|
||||
|
||||
**Cyberphysische Systeme**
|
||||
Integrierte Systeme aus Software, Hardware und Netzwerken, die physische Prozesse überwachen und steuern. Verbinden digitale und physische Welt.
|
||||
|
||||
---
|
||||
|
||||
### F
|
||||
|
||||
**Flask**
|
||||
Leichtgewichtiges Python-Web-Framework für die Entwicklung von Webanwendungen. Bietet grundlegende Funktionen und ist durch Extensions erweiterbar.
|
||||
|
||||
**FQDN (Fully Qualified Domain Name)**
|
||||
Vollständiger Domainname, der die exakte Position eines Hosts im DNS-Namensraum angibt (z.B. server.beispiel.com).
|
||||
|
||||
---
|
||||
|
||||
### I
|
||||
|
||||
**IoT (Internet of Things)**
|
||||
Netzwerk physischer Geräte mit eingebetteter Software, Sensoren und Netzwerkverbindung zur Datensammlung und -austausch.
|
||||
|
||||
**IP-Spoofing**
|
||||
Angriffstechnik, bei der die Absender-IP-Adresse in Netzwerkpaketen gefälscht wird, um die wahre Identität zu verschleiern.
|
||||
|
||||
---
|
||||
|
||||
### J
|
||||
|
||||
**JSON (JavaScript Object Notation)**
|
||||
Leichtgewichtiges, textbasiertes Datenformat für den Austausch zwischen Anwendungen. Verwendet schlüssel-wert-basierte Struktur.
|
||||
|
||||
---
|
||||
|
||||
### M
|
||||
|
||||
**Mock-Objekte**
|
||||
Simulierte Objekte in Unit-Tests, die das Verhalten echter Komponenten nachahmen. Ermöglichen isolierte Tests ohne externe Abhängigkeiten.
|
||||
|
||||
---
|
||||
|
||||
### O
|
||||
|
||||
**ORM (Object-Relational Mapping)**
|
||||
Programmierverfahren zur Abbildung objektorientierter Datenstrukturen auf relationale Datenbankstrukturen. SQLAlchemy ist ein Python-ORM.
|
||||
|
||||
**OWASP Top 10**
|
||||
Jährlich aktualisierte Liste der kritischsten Websicherheitsrisiken, herausgegeben von der Open Web Application Security Project (OWASP).
|
||||
|
||||
---
|
||||
|
||||
### P
|
||||
|
||||
**Penetrationstest**
|
||||
Systematische Sicherheitsüberprüfung von IT-Systemen durch simulierte Angriffe zur Identifikation von Schwachstellen.
|
||||
|
||||
**PyP100**
|
||||
Python-Bibliothek zur Steuerung von TP-Link Tapo Smart-Plugs über lokale Netzwerkverbindung ohne Cloud-Abhängigkeit.
|
||||
|
||||
**Python**
|
||||
Interpretierte, höhere Programmiersprache mit Fokus auf Lesbarkeit und einfache Syntax. Weit verbreitet für Web-Entwicklung und Automatisierung.
|
||||
|
||||
---
|
||||
|
||||
### R
|
||||
|
||||
**Race Condition**
|
||||
Fehlerhafte Systemsituation, bei der das Ergebnis von der unvorhersagbaren Reihenfolge paralleler Operationen abhängt.
|
||||
|
||||
**Rate-Limiting**
|
||||
Sicherheitsmechanismus zur Begrenzung der Anzahl von Anfragen pro Zeiteinheit, um DoS-Angriffe und Ressourcenüberlastung zu verhindern.
|
||||
|
||||
**Raspberry Pi**
|
||||
Einplatinencomputer mit ARM-Prozessor, entwickelt für Bildungszwecke und IoT-Projekte. Läuft unter Linux-basierten Betriebssystemen.
|
||||
|
||||
**REST (Representational State Transfer)**
|
||||
Architekturstil für verteilte Hypermedia-Systeme. REST-APIs verwenden HTTP-Methoden (GET, POST, PUT, DELETE) für standardisierte Kommunikation.
|
||||
|
||||
**Retry-Mechanismus**
|
||||
Programmierverfahren zur automatischen Wiederholung fehlgeschlagener Operationen mit konfigurierbaren Wartezeiten und Maximalversuchen.
|
||||
|
||||
---
|
||||
|
||||
### S
|
||||
|
||||
**Session-Management**
|
||||
Verwaltung von Benutzersitzungen in Webanwendungen zur Aufrechterhaltung des Anmeldestatus zwischen HTTP-Requests.
|
||||
|
||||
**Smart-Plug**
|
||||
Netzwerkfähige Steckdose mit WLAN-Verbindung, die ferngesteuert ein-/ausgeschaltet werden kann. Oft mit Energiemessungs-Features.
|
||||
|
||||
**SQLAlchemy**
|
||||
Python-SQL-Toolkit und Object-Relational Mapping (ORM) Bibliothek für Datenbankzugriff mit objektorientierten Programmiermethoden.
|
||||
|
||||
**SQLite**
|
||||
Serverlose, dateibasierte SQL-Datenbank-Engine. Ideal für eingebettete Systeme und Anwendungen mit geringen bis mittleren Datenmengen.
|
||||
|
||||
**SSL/TLS (Secure Sockets Layer/Transport Layer Security)**
|
||||
Kryptographische Protokolle zur sicheren Übertragung von Daten über Netzwerke. TLS ist der Nachfolger von SSL.
|
||||
|
||||
**systemd**
|
||||
System- und Service-Manager für Linux-Betriebssysteme. Verwaltet Systemdienste, Bootvorgang und Ressourcen.
|
||||
|
||||
---
|
||||
|
||||
### T
|
||||
|
||||
**TAPO**
|
||||
Smart-Home-Produktlinie der Firma TP-Link, umfasst WLAN-fähige Steckdosen, Kameras und andere IoT-Geräte.
|
||||
|
||||
**Thread-Safety**
|
||||
Eigenschaft von Code, der sicher in multi-threaded Umgebungen ausgeführt werden kann ohne Race Conditions oder Datenkonflikte.
|
||||
|
||||
**TP-Link**
|
||||
Chinesischer Hersteller von Netzwerk- und Smart-Home-Produkten. Bekannt für Router, Switches und IoT-Geräte.
|
||||
|
||||
---
|
||||
|
||||
### U
|
||||
|
||||
**Unit-Test**
|
||||
Automatisierter Test, der einzelne Komponenten (Units) einer Software isoliert auf korrekte Funktionsweise prüft.
|
||||
|
||||
---
|
||||
|
||||
### V
|
||||
|
||||
**V-Modell**
|
||||
Vorgehensmodell der Softwareentwicklung mit sequenziellen Entwicklungsphasen und entsprechenden Testebenen. Jeder Entwicklungsphase ist eine Testphase zugeordnet.
|
||||
|
||||
**VirtualBox**
|
||||
Open-Source-Virtualisierungssoftware zur Ausführung mehrerer Betriebssysteme auf einem physischen Rechner in isolierten virtuellen Maschinen.
|
||||
|
||||
**VLAN (Virtual Local Area Network)**
|
||||
Logische Segmentierung physischer Netzwerke zur Trennung von Datenverkehr und Erhöhung der Sicherheit.
|
||||
|
||||
---
|
||||
|
||||
### W
|
||||
|
||||
**Wireshark**
|
||||
Open-Source-Netzwerkprotokoll-Analyzer zur Aufzeichnung und Analyse von Netzwerkverkehr. Ermöglicht detaillierte Paketinspektion für Debugging und Sicherheitsanalyse.
|
||||
|
||||
**WSGI (Web Server Gateway Interface)**
|
||||
Python-Standard für die Schnittstelle zwischen Webservern und Web-Frameworks. Gunicorn ist ein WSGI-Server.
|
||||
|
||||
---
|
||||
|
||||
### Z
|
||||
|
||||
**Zenmap**
|
||||
Grafische Benutzeroberfläche für Nmap (Network Mapper). Tool für Netzwerk-Discovery, Port-Scanning und Sicherheitsauditierung.
|
||||
|
||||
---
|
||||
|
||||
## Abkürzungsverzeichnis
|
||||
|
||||
| Abkürzung | Bedeutung |
|
||||
|-----------|-----------|
|
||||
| **API** | Application Programming Interface |
|
||||
| **CORS** | Cross-Origin Resource Sharing |
|
||||
| **CSRF** | Cross-Site Request Forgery |
|
||||
| **FQDN** | Fully Qualified Domain Name |
|
||||
| **HTTP** | Hypertext Transfer Protocol |
|
||||
| **HTTPS** | HTTP Secure |
|
||||
| **IoT** | Internet of Things |
|
||||
| **JSON** | JavaScript Object Notation |
|
||||
| **ORM** | Object-Relational Mapping |
|
||||
| **REST** | Representational State Transfer |
|
||||
| **SSL** | Secure Sockets Layer |
|
||||
| **TLS** | Transport Layer Security |
|
||||
| **VLAN** | Virtual Local Area Network |
|
||||
| **WSGI** | Web Server Gateway Interface |
|
||||
|
||||
---
|
||||
|
||||
*Glossar erstellt für: IHK-Projektdokumentation "MYP – Manage Your Printer"*
|
||||
*Stand: Januar 2025*
|
||||
376
IHK_Projektdokumentation/MYP_Projektdokumentation_Final.md
Normal file
376
IHK_Projektdokumentation/MYP_Projektdokumentation_Final.md
Normal file
@ -0,0 +1,376 @@
|
||||
# MYP – Manage Your Printer
|
||||
## Vernetzte 3D-Druck-Reservierungsplattform mit IoT-Anbindung und zentraler Verwaltungsoberfläche
|
||||
|
||||
**Dokumentation der betrieblichen Projektarbeit**
|
||||
|
||||
**Fachinformatiker für digitale Vernetzung**
|
||||
|
||||
---
|
||||
|
||||
**Prüfungsbewerber:** Till Tomczak
|
||||
**Ausbildungsbetrieb:** Mercedes-Benz AG
|
||||
**Prüfungstermin:** Sommer 2025
|
||||
**Bearbeitungszeitraum:** 15. April – 20. Mai 2025
|
||||
**Projektumfang:** 35 Stunden
|
||||
|
||||
---
|
||||
|
||||
## Inhaltsverzeichnis
|
||||
|
||||
1. [Einleitung](#1-einleitung)
|
||||
1.1 [Ausgangssituation und Problemstellung](#11-ausgangssituation-und-problemstellung)
|
||||
1.2 [Projektziele](#12-projektziele)
|
||||
1.3 [Projektabgrenzung](#13-projektabgrenzung)
|
||||
1.4 [Projektumfeld und betriebliche Schnittstellen](#14-projektumfeld-und-betriebliche-schnittstellen)
|
||||
2. [Projektplanung](#2-projektplanung)
|
||||
2.1 [Zeitplanung nach V-Modell](#21-zeitplanung-nach-v-modell)
|
||||
2.2 [Ressourcenplanung](#22-ressourcenplanung)
|
||||
2.3 [Qualitätssicherungsplanung](#23-qualitätssicherungsplanung)
|
||||
3. [Analyse und Bewertung](#3-analyse-und-bewertung)
|
||||
3.1 [Bewertung der vorhandenen Systemarchitektur](#31-bewertung-der-vorhandenen-systemarchitektur)
|
||||
3.2 [Bewertung der heterogenen IT-Landschaft](#32-bewertung-der-heterogenen-it-landschaft)
|
||||
3.3 [Analyse der IT-sicherheitsrelevanten Bedingungen](#33-analyse-der-it-sicherheitsrelevanten-bedingungen)
|
||||
3.4 [Anforderungsgerechte Auswahl der Übertragungssysteme](#34-anforderungsgerechte-auswahl-der-übertragungssysteme)
|
||||
4. [Systemarchitektur und Schnittstellenkonzeption](#4-systemarchitektur-und-schnittstellenkonzeption)
|
||||
4.1 [Gesamtsystemarchitektur](#41-gesamtsystemarchitektur)
|
||||
4.2 [Technische Systemarchitektur](#42-technische-systemarchitektur)
|
||||
4.3 [Schnittstellenkonzeption](#43-schnittstellenkonzeption)
|
||||
4.4 [Datenmodell](#44-datenmodell)
|
||||
5. [Umsetzung](#5-umsetzung)
|
||||
5.1 [Implementierung der Backend-Infrastruktur](#51-implementierung-der-backend-infrastruktur)
|
||||
5.2 [IoT-Integration und Hardware-Steuerung](#52-iot-integration-und-hardware-steuerung)
|
||||
5.3 [Sicherheitsimplementierung](#53-sicherheitsimplementierung)
|
||||
5.4 [Systemkonfiguration und Deployment](#54-systemkonfiguration-und-deployment)
|
||||
6. [Test und Optimierung](#6-test-und-optimierung)
|
||||
6.1 [Testdurchführung und -ergebnisse](#61-testdurchführung-und-ergebnisse)
|
||||
6.2 [Sicherheitstests](#62-sicherheitstests)
|
||||
6.3 [Systemstabilität und Monitoring](#63-systemstabilität-und-monitoring)
|
||||
7. [Projektabschluss](#7-projektabschluss)
|
||||
7.1 [Soll-Ist-Vergleich](#71-soll-ist-vergleich)
|
||||
7.2 [Projektergebnisse und Erkenntnisse](#72-projektergebnisse-und-erkenntnisse)
|
||||
7.3 [Optimierungsmöglichkeiten](#73-optimierungsmöglichkeiten)
|
||||
7.4 [Formale Projektabnahme](#74-formale-projektabnahme)
|
||||
8. [Anlagen](#anlagen)
|
||||
9. [Glossar](#glossar)
|
||||
|
||||
---
|
||||
|
||||
## 1. Einleitung
|
||||
|
||||
### 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), die als wichtige Ressource für die praktische Ausbildung dienen. Diese Geräte weisen jedoch erhebliche technische Limitierungen auf, da sie weder über Netzwerkschnittstellen noch über einheitliche Steuerungsmöglichkeiten verfügen.
|
||||
|
||||
Das bestehende Reservierungssystem basierte auf einem analogen Whiteboard, was zu systematischen Problemen führte. 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. Eine verlässliche Dokumentation der tatsächlichen Nutzungszeiten existierte nicht, wodurch weder aussagekräftige Betätigungs- und Verantwortungszuordnung, noch eine verursachungsgerechte Kostenzuordnung möglich waren.
|
||||
|
||||
Ein vorhandener Frontend-Prototyp des ehemaligen Auszubildenden Torben Haack bot eine moderne Benutzeroberfläche, verfügte jedoch über keine funktionsfähige Backend-Anbindung zur praktischen Nutzung. Diese Ausgangslage bot mir die Gelegenheit, im Rahmen meiner Projektarbeit eine vollständige Lösung zu entwickeln.
|
||||
|
||||
### 1.2 Projektziele
|
||||
|
||||
Das Projekt "MYP – Manage Your Printer" zielt auf die vollständige Digitalisierung des 3D-Drucker-Reservierungsprozesses durch die Etablierung cyberphysischer Kommunikation mit den relevanten Hardwarekomponenten ab.
|
||||
|
||||
Die primären Ziele umfassen die Entwicklung einer webbasierten Reservierungsplattform, die Integration automatischer Hardware-Steuerung via IoT-Komponenten, die Implementierung einer zentralen Verwaltungsoberfläche sowie die Etablierung robuster Authentifizierung und Rechteverwaltung. Als sekundäre Ziele wurden die Optimierung der Energieeffizienz durch automatisierte Steuerung, die Bereitstellung von Nutzungsstatistiken und Monitoring, die Gewährleistung einer herstellerunabhängigen Lösung sowie die Einhaltung unternehmensinterner Sicherheitsrichtlinien definiert.
|
||||
|
||||
### 1.3 Projektabgrenzung
|
||||
|
||||
Der Projektumfang wurde pragmatisch auf die praktische Umsetzung einer funktionsfähigen Lösung fokussiert. Im Projektumfang enthalten sind die Webportal-Entwicklung (Frontend und Backend), die WLAN-Integration der Raspberry Pi-Plattform, der Datenbankaufbau für Reservierungsverwaltung, die IoT-Integration via Smart-Plug-Technologie, Authentifizierung und Autorisierung sowie der Test der Schnittstellen und Netzwerkverbindungen.
|
||||
|
||||
Ausgeschlossen aus dem Projektumfang wurden die direkte Kommunikation mit 3D-Druckern (aufgrund fehlender Schnittstellen), die Integration in das unternehmensweite Intranet (Zeitrestriktionen), die Übertragung von Druckdaten oder Statusüberwachung der Drucker sowie umfangreiche Hardware-Modifikationen der bestehenden Geräte.
|
||||
|
||||
Die Integration in das unternehmensweite Intranet war ursprünglich fest eingeplant. Zur Projektmitte hatte ich die bereits genehmigten SSL-Zertifikate des Haack'schen Prototyps durch einen unglücklichen Neuinstallationsprozess unwiederbringlich gelöscht. Die Intranetanbindung blieb somit ausstehend und konnte aufgrund der Konzerngröße und der damit einhergehenden Genehmigungsprozesse nicht mehr rechtzeitig realisiert werden.
|
||||
|
||||
### 1.4 Projektumfeld und betriebliche Schnittstellen
|
||||
|
||||
Das Projekt wurde im Rahmen der Ausbildung zum Fachinformatiker für digitale Vernetzung in der TBA durchgeführt. Die organisatorischen Rahmenbedingungen wurden durch konzerninternen Sicherheitsrichtlinien und IT-Governance-Prozesse geprägt.
|
||||
|
||||
Die zentralen Schnittstellen umfassten die IT-Abteilung für die Genehmigung von Netzwerkkonfigurationen und SSL-Zertifikaten, die Ausbildungsleitung für fachliche Betreuung und Ressourcenbereitstellung, die Endanwender in Form von Auszubildenden und Ausbildungspersonal der TBA sowie die Hardware-Integration über Smart-Plug-Systeme als IoT-Gateway zu den 3D-Druckern.
|
||||
|
||||
---
|
||||
|
||||
## 2. Projektplanung
|
||||
|
||||
### 2.1 Zeitplanung nach V-Modell
|
||||
|
||||
Die Projektplanung folgte dem V-Modell mit agilen Elementen, unterteilt in fünf Sprints à eine Woche. Der Gesamtzeitraum erstreckte sich vom 15. April bis 20. Mai 2025 mit einem Projektumfang von 35 Stunden.
|
||||
|
||||
Sprint 1 (15.-19. April, 6 Stunden) widmete sich der Projektplanung und Analyse. Am Anfang dieses Sprints erkundigte sich Martin kurz bei mir über den Status und ich passte die weitere Planung entsprechend an. Die Analyse des vorgefundenen Prototyps und die Definition der Erweiterungspunkte standen im Fokus.
|
||||
|
||||
Sprint 2 (22.-26. April, 12 Stunden) konzentrierte sich auf die Analyse und Bewertung der Systemarchitektur. Martin erkundigte sich erneut zu Sprintbeginn nach dem Fortschritt. Die Beantragung der erforderlichen Administratorrechte erwies sich als zeitaufwändiger als erwartet, was zu einem Zeitverzug von 4 Stunden führte.
|
||||
|
||||
Sprint 3 (29. April - 3. Mai, 6 Stunden) beinhaltete die Entwicklung der Systemarchitektur. Die regelmäßige Abstimmung mit Martin half, die Prioritäten anzupassen. Der Verlust der SSL-Zertifikate durch einen Neuinstallationsprozess verursachte einen zusätzlichen Zeitverzug von 6 Stunden.
|
||||
|
||||
Sprint 4 (6.-10. Mai, 14 Stunden) war für die Umsetzung (Implementation) vorgesehen. Nach Martins Statusabfrage zu Sprintbeginn wurde die Planung erneut angepasst. In intensiven Coding-Sessions wurde die Grundfunktionalität implementiert.
|
||||
|
||||
Sprint 5 (13.-17. Mai, 10 Stunden) diente Test, Optimierung und Dokumentation. Die finale Abstimmung mit Martin bestätigte den Projektfortschritt trotz der akkumulierten Zeitverzüge von insgesamt 10 Stunden.
|
||||
|
||||
### 2.2 Ressourcenplanung
|
||||
|
||||
Die Hardware-Komponenten umfassten einen Raspberry Pi 5 (8GB RAM, 128GB Speicher) als zentrale Serverplattform, nachdem sich der ursprünglich vorgesehene Raspberry Pi 4 als unterdimensioniert erwiesen hatte. Sechs TP-Link Tapo P110 Smart-Plugs bildeten das Herzstück der IoT-Integration. Ein 19-Zoll-Serverschrank wurde für die professionelle Unterbringung beschafft, ergänzt durch privat finanzierte Komponenten wie Lüftereinheiten und Kabelmanagement-Systeme.
|
||||
|
||||
Der Software-Stack basierte vollständig auf Open-Source-Technologien. Das Backend wurde mit Python 3.11, Flask 2.3, SQLAlchemy 2.0 und SQLite implementiert. Für das Frontend wurde nach dem Scheitern der Next.js-Integration eine eigene Lösung mit HTML/CSS/JavaScript als Notlösung entwickelt, wobei für die Interface-Entwicklung KI-Unterstützung verwendet wurde. Das System läuft auf Raspbian OS mit systemd-Services und OpenSSL. Die IoT-Integration erfolgte über die PyP100-Bibliothek für Smart-Plug-Kommunikation.
|
||||
|
||||
Die Gesamtkosten beliefen sich auf weniger als 200 Euro, deutlich unter der ursprünglichen Kalkulation von 600 Euro. Die Kostenersparnis resultierte aus der Nutzung vorhandener Hardware-Komponenten und der Eigenfinanzierung ergänzender Komponenten.
|
||||
|
||||
### 2.3 Qualitätssicherungsplanung
|
||||
|
||||
Das Qualitätssicherungskonzept orientierte sich am V-Modell. Für jede Entwicklungsphase wurden korrespondierende Testaktivitäten definiert. Eine VirtualBox-basierte Entwicklungsumgebung ermöglichte Backend-Tests ohne Gefährdung der Produktivumgebung. Hardware-in-the-Loop-Tests mit echten Smart-Plugs gewährleisteten realitätsnahe Testbedingungen. Die separate Produktionsumgebung auf dem Raspberry Pi diente finalen Systemtests.
|
||||
|
||||
Die Teststrategien umfassten Unit-Tests für isolierte Tests kritischer Komponenten mit einer Codeabdeckung von 85%, Integrationstests für Schnittstellen zwischen Frontend, Backend und IoT sowie Systemtests für End-to-End-Szenarien mit kompletten Anwendungsfällen. Sicherheitstests fokussierten sich auf grundlegende Schwachstellen ohne explizite Referenz auf externe Standards.
|
||||
|
||||
---
|
||||
|
||||
## 3. Analyse und Bewertung
|
||||
|
||||
### 3.1 Bewertung der vorhandenen Systemarchitektur
|
||||
|
||||
Der Ist-Zustand präsentierte sich als fragmentierte Landschaft. Ein Frontend-Prototyp (Next.js) existierte ohne Backend-Anbindung, die 3D-Drucker operierten isoliert ohne Netzwerkfähigkeit, die Reservierungsverwaltung erfolgte analog über ein Whiteboard, und ein Raspberry Pi 4 stand als ungenutzter Server zur Verfügung.
|
||||
|
||||
Die identifizierten Defizite umfassten die fehlende cyberphysische Integration, keine zentrale Datenhaltung, ineffiziente manuelle Prozesse sowie Sicherheitslücken durch die analoge Verwaltung. Diese Analyse bildete die Grundlage für die Entwicklung einer integrierten Lösung.
|
||||
|
||||
### 3.2 Bewertung der heterogenen IT-Landschaft
|
||||
|
||||
Die IT-Infrastruktur der TBA präsentierte sich als gewachsene Umgebung ohne mir direkt ersichtliche VLAN-Strukturen. Die 3D-Drucker verschiedener Hersteller erforderten eine herstellerunabhängige Abstraktionsebene.
|
||||
|
||||
Der gewählte Lösungsansatz über IoT-Integration mittels Smart-Plugs ermöglichte eine universelle Steuerung unabhängig vom Druckermodell durch Abstraktion auf die Stromversorgungsebene. Diese Entscheidung basierte nicht zuletzt auf meiner privaten Erfahrung mit TAPO-Geräten, wobei sich die programmatische Integration als deutlich komplexer herausstellte als die private Nutzung.
|
||||
|
||||
### 3.3 Analyse der IT-sicherheitsrelevanten Bedingungen
|
||||
|
||||
Die Sicherheitsanforderungen diktierten maßgeblich die Systemarchitektur. Keine permanente Internetverbindung war zulässig, ein isoliertes Netzwerksegment für IoT-Komponenten wurde erforderlich, selbstsignierte SSL-Zertifikate mussten mangels Let's Encrypt-Möglichkeit verwendet werden, und die Compliance mit Mercedes-Benz IT-Sicherheitsrichtlinien war obligatorisch.
|
||||
|
||||
Die implementierten Sicherheitsmaßnahmen umfassten bcrypt-Passwort-Hashing mit Cost-Faktor 12, CSRF-Schutz und Session-Management, Rate-Limiting gegen Brute-Force-Angriffe sowie Firewall-Regeln mit Port-Beschränkung. Die Verwendung von FirewallD erfolgte der Vertrautheit halber, da ich mit diesem System bereits umfangreiche Erfahrungen gesammelt hatte. Besonders wichtig war die Implementierung von HTTPS auch im Kiosk-Modus, um für den unwahrscheinlichen Fall eines Man-in-the-Middle-Angriffs auf dem Gerät selbst keine Klartextpasswörter im Netzwerkstrom zu haben – eine Entscheidung, die auch meinem technischen Gewissen entsprach.
|
||||
|
||||
### 3.4 Anforderungsgerechte Auswahl der Übertragungssysteme
|
||||
|
||||
Die Evaluierung verschiedener Optionen ergab, dass eine direkte 3D-Drucker-Integration aufgrund fehlender Schnittstellen nicht möglich war. Cloud-basierte Lösungen schieden wegen der Offline-Anforderung aus. Die Smart-Plug-Integration wurde als optimale Lösung identifiziert.
|
||||
|
||||
Die technische Herausforderung bestand darin, dass die TP-Link Tapo P110 über keine dokumentierte API verfügten. Der Hergang von der initialen Problemstellung zur funktionierenden Lösung gestaltete sich komplex. Zunächst versuchte ich, ein recherchiertes Python-Modul für die Steuerung zu verwenden, was jedoch scheiterte. Daraufhin führte ich eine systematische Protokollanalyse mittels Wireshark durch. Die Untersuchung des Netzwerkverkehrs zwischen der TAPO-App und den Steckdosen offenbarte eine verschlüsselte Kommunikation mit dynamisch generierten Session-Keys. Nach mehreren Tagen intensiver Analyse und verschiedenen Implementierungsversuchen konnte ich schließlich PyP100 als funktionsfähige Python-Bibliothek identifizieren, die das proprietäre Kommunikationsprotokoll korrekt implementierte und eine lokale Steuerung ohne Cloud-Abhängigkeit ermöglichte.
|
||||
|
||||
---
|
||||
|
||||
## 4. Systemarchitektur und Schnittstellenkonzeption
|
||||
|
||||
### 4.1 Gesamtsystemarchitektur
|
||||
|
||||
Die Architektur folgt einem dreischichtigen Aufbau mit klarer Trennung der Verantwortlichkeiten:
|
||||
|
||||
```
|
||||
┌─────────────────┐ HTTPS ┌─────────────────┐ WLAN ┌─────────────────┐
|
||||
│ Web-Client │◄────────────►│ Raspberry Pi │◄───────────►│ Smart-Plugs │
|
||||
│ (Browser) │ │ MYP-Server │ │ (IoT-Layer) │
|
||||
└─────────────────┘ └─────────────────┘ └─────────────────┘
|
||||
│ │
|
||||
┌────▼────┐ ┌────▼────┐
|
||||
│ SQLite │ │3D-Drucker│
|
||||
│Database │ │(6 Geräte)│
|
||||
└─────────┘ └─────────┘
|
||||
```
|
||||
|
||||
### 4.2 Technische Systemarchitektur
|
||||
|
||||
Das Schichtenmodell umfasst die Präsentationsschicht als Web-Frontend (HTTPS/Port 443), die Anwendungsschicht mit Flask-Backend und REST-API, die Geschäftslogikschicht für Reservierungsmanagement und Scheduler, die Datenhaltungsschicht mit SQLite-Datenbank, die IoT-Integrationsschicht für Smart-Plug-Kommunikation sowie die Hardwareschicht mit stromgesteuerten 3D-Druckern.
|
||||
|
||||
### 4.3 Schnittstellenkonzeption
|
||||
|
||||
Das REST-API-Design umfasst über 100 Endpunkte, strukturiert in logische Bereiche. Die Authentifizierung erfolgt über `/api/auth/` mit Login, Logout und Session-Management. Die Benutzerverwaltung ist unter `/api/users/` für CRUD-Operationen implementiert. Die Druckerverwaltung unter `/api/printers/` bietet Status und Konfiguration. Das Reservierungsmanagement unter `/api/jobs/` ermöglicht Buchung, Verwaltung und Scheduling. Das Monitoring unter `/api/monitoring/` liefert Energieverbrauch und Statistiken.
|
||||
|
||||
Die IoT-Schnittstelle kommuniziert über HTTP/TCP via WLAN mit session-basierter Authentifizierung und dynamischen Tokens. Die verfügbaren Operationen umfassen Power On/Off, Status-Abfrage und Energiemessung mit implementierter Fehlerbehandlung durch Retry-Mechanismen und Timeout-Handling.
|
||||
|
||||
### 4.4 Datenmodell
|
||||
|
||||
Die Kernentitäten des Datenmodells umfassen User für Benutzerkonten mit Rollen und Berechtigungen, Printer für 3D-Drucker-Definitionen mit Smart-Plug-Zuordnung, Job für Reservierungen mit Zeitfenstern und Status, SmartPlug für IoT-Geräte-Konfiguration und Zustandsverwaltung sowie EnergyLog für Energieverbrauchsdaten zur Optimierung.
|
||||
|
||||
---
|
||||
|
||||
## 5. Umsetzung
|
||||
|
||||
### 5.1 Implementierung der Backend-Infrastruktur
|
||||
|
||||
Die Flask-Anwendungsstruktur folgt einer modularen Blueprint-Architektur:
|
||||
|
||||
```python
|
||||
├── app.py # Hauptanwendung mit HTTPS-Konfiguration
|
||||
├── models.py # SQLAlchemy-Datenmodelle
|
||||
├── blueprints/ # Funktionale Module
|
||||
│ ├── auth.py # Authentifizierung
|
||||
│ ├── users.py # Benutzerverwaltung
|
||||
│ ├── printers.py # Druckerverwaltung
|
||||
│ └── jobs.py # Reservierungslogik
|
||||
└── utils/ # Hilfsfunktionen
|
||||
├── scheduler.py # Zeitgesteuerte Operationen
|
||||
└── smart_plug.py # IoT-Integration
|
||||
```
|
||||
|
||||
Die zentrale Implementierungsherausforderung bestand in der Smart-Plug-Integration. Nach dem beschriebenen Hergang von Wireshark-Analyse zu PyP100 erwies sich diese Bibliothek als einzige funktionsfähige Lösung. Die Thread-sichere Scheduler-Implementation erforderte sorgfältige Synchronisation:
|
||||
|
||||
```python
|
||||
class SmartPlugScheduler:
|
||||
def __init__(self):
|
||||
self.scheduler = BackgroundScheduler()
|
||||
self.lock = threading.Lock()
|
||||
|
||||
def schedule_job(self, job_id, start_time, duration):
|
||||
with self.lock:
|
||||
# Thread-sichere Jobplanung
|
||||
self.scheduler.add_job(...)
|
||||
```
|
||||
|
||||
### 5.2 IoT-Integration und Hardware-Steuerung
|
||||
|
||||
Die Smart-Plug-Konfiguration erfolgte mit statischen IP-Adressen im Bereich 192.168.0.100-105. Die lokale Authentifizierung funktioniert ohne Cloud-Service-Abhängigkeit. Das integrierte Energiemonitoring ermöglicht Verbrauchsoptimierung.
|
||||
|
||||
Die Kommunikation wurde in einer Manager-Klasse gekapselt:
|
||||
|
||||
```python
|
||||
class SmartPlugManager:
|
||||
def __init__(self, plug_configs):
|
||||
self.plugs = {id: Tapo(ip, user, pass) for id, ip in plug_configs.items()}
|
||||
|
||||
async def control_printer(self, printer_id, action):
|
||||
plug = self.plugs[printer_id]
|
||||
return await plug.on() if action == 'start' else await plug.off()
|
||||
```
|
||||
|
||||
### 5.3 Sicherheitsimplementierung
|
||||
|
||||
Die Authentifizierung und Autorisierung basiert auf bcrypt-Passwort-Hashing mit Cost-Faktor 12, Session-Management über Flask-Login und CSRF-Schutz für alle kritischen Operationen. Das implementierte Rate-Limiting verhindert Brute-Force-Angriffe durch exponentielle Backoff-Strategie.
|
||||
|
||||
### 5.4 Systemkonfiguration und Deployment
|
||||
|
||||
Die Systemd-Service-Konfiguration gewährleistet automatischen Start und Überwachung:
|
||||
|
||||
```ini
|
||||
[Unit]
|
||||
Description=MYP HTTPS Backend Service
|
||||
After=network.target
|
||||
|
||||
[Service]
|
||||
Type=simple
|
||||
User=myp
|
||||
WorkingDirectory=/opt/myp
|
||||
ExecStart=/usr/bin/python3 app.py --production
|
||||
Restart=always
|
||||
RestartSec=10
|
||||
|
||||
[Install]
|
||||
WantedBy=multi-user.target
|
||||
```
|
||||
|
||||
Das SSL-Zertifikat-Management erfolgt über selbstsignierte Zertifikate für den Offline-Betrieb. Die HTTPS-Implementierung auch im Kiosk-Modus gewährleistet verschlüsselte Passwortübertragung.
|
||||
|
||||
---
|
||||
|
||||
## 6. Test und Optimierung
|
||||
|
||||
### 6.1 Testdurchführung und -ergebnisse
|
||||
|
||||
Die Unit-Tests erreichten eine Codeabdeckung von 85%. Alle Datenbankoperationen, API-Endpunkte und die Smart-Plug-Integration wurden erfolgreich getestet. Die Integrationstests bestätigten die vollständige Funktionalität der Frontend-Backend-Kommunikation und IoT-Hardware-Integration. Systemtests verifizierten End-to-End-Reservierungsszenarien mit bis zu 10 parallelen Sessions.
|
||||
|
||||
Die Performance-Optimierungen umfassten das Hardware-Upgrade von Raspberry Pi 4 auf Pi 5 aufgrund unzureichender Leistung, Datenbankindizierung für häufige Abfragen sowie Caching-Strategien für Smart-Plug-Status.
|
||||
|
||||
### 6.2 Sicherheitstests
|
||||
|
||||
Die Sicherheitstests fokussierten sich auf grundlegende Angriffsvektoren. SQL-Injection-Versuche wurden durch Parameterisierung erfolgreich abgewehrt. XSS-Angriffe scheiterten an der implementierten Input-Sanitization. CSRF-Attacken wurden durch Token-basierten Schutz verhindert. Das Rate-Limiting aktivierte sich nach 5 fehlgeschlagenen Login-Versuchen.
|
||||
|
||||
### 6.3 Systemstabilität und Monitoring
|
||||
|
||||
Das implementierte Monitoring nutzt strukturiertes Logging mit Rotation:
|
||||
|
||||
```python
|
||||
import logging
|
||||
from logging.handlers import RotatingFileHandler
|
||||
|
||||
logging.basicConfig(
|
||||
handlers=[RotatingFileHandler('app.log', maxBytes=10000000, backupCount=10)],
|
||||
level=logging.INFO,
|
||||
format='%(asctime)s %(levelname)s %(name)s %(message)s'
|
||||
)
|
||||
```
|
||||
|
||||
Erkannte und behobene Probleme umfassten Memory-Leaks bei lang laufenden Smart-Plug-Operationen, Race Conditions im Scheduler bei simultanen Zugriffen sowie SSL-Zertifikat-Probleme durch inkorrekte SAN-Konfiguration.
|
||||
|
||||
---
|
||||
|
||||
## 7. Projektabschluss
|
||||
|
||||
### 7.1 Soll-Ist-Vergleich
|
||||
|
||||
Vollständig erreichte Ziele umfassen die webbasierte Reservierungsplattform, automatische Hardware-Steuerung via IoT, zentrale Verwaltungsoberfläche, robuste Authentifizierung und Rechteverwaltung, WLAN-Integration der Raspberry Pi-Plattform, Datenbankaufbau für Reservierungsverwaltung sowie Test der Schnittstellen und Netzwerkverbindungen.
|
||||
|
||||
Zusätzlich realisierte Features beinhalten Energiemonitoring und Verbrauchsoptimierung, Nutzungsstatistiken und Dashboard, erweiterte Sicherheitsfeatures wie Rate-Limiting und CSRF-Schutz sowie einen Kiosk-Modus für Werkstatt-Terminals.
|
||||
|
||||
Abweichungen vom ursprünglichen Plan waren die Konsolidierung auf einen statt zwei Raspberry Pis aus Kostenoptimierungsgründen, das Hardware-Upgrade Pi 4 auf Pi 5 wegen Performance-Anforderungen, die Implementierung einer eigenen Frontend-Lösung als Notlösung statt Next.js-Integration sowie die Verschiebung der Intranet-Integration aufgrund von Zeitrestriktionen. Der akkumulierte Zeitverzug von 10 Stunden konnte durch effiziente Arbeitsweise in den finalen Sprints teilweise kompensiert werden.
|
||||
|
||||
### 7.2 Projektergebnisse und Erkenntnisse
|
||||
|
||||
Das MYP-System transformiert erfolgreich die analoge 3D-Drucker-Verwaltung in ein modernes cyberphysisches System. Die Lösung demonstriert, wie durch kreative IoT-Integration auch Legacy-Hardware in moderne Systemlandschaften integriert werden kann.
|
||||
|
||||
Die zentralen Erfolgsfaktoren waren die pragmatische Abstraktion komplexer Hardware-Probleme, eine robuste Softwarearchitektur mit umfassender Fehlerbehandlung sowie die konsequente Berücksichtigung von Sicherheitsanforderungen von Projektbeginn an. Für die Frontend-Entwicklung wurde aufgrund der Zeitrestriktionen und der Fokussierung auf meine Kernkompetenz der digitalen Vernetzung KI-Unterstützung in Anspruch genommen.
|
||||
|
||||
Als wichtige Erkenntnisse kristallisierten sich heraus, dass Hardware-Kompatibilitätsprüfungen vor Projektstart essentiell sind, Backup-Strategien für kritische Konfigurationen unerlässlich sind und agile Anpassungsfähigkeit bei unvorhergesehenen Problemen den Projekterfolg sichert.
|
||||
|
||||
### 7.3 Optimierungsmöglichkeiten
|
||||
|
||||
Das MYP-System bietet eine solide Basis für zukünftige Erweiterungen. Die modulare Architektur und umfassende API ermöglichen die Integration zusätzlicher Funktionalitäten ohne grundlegende Systemänderungen.
|
||||
|
||||
Kurzfristig ist die Anbindung an das unternehmenseigene Active Directory geplant, sobald die erforderlichen Genehmigungen vorliegen. Mittelfristig könnte bei Verfügbarkeit modernerer 3D-Drucker eine direkte Geräteintegration realisiert werden. Langfristig bietet sich die Erweiterung zu einer umfassenden Maker-Space-Management-Lösung an, die auch andere Gerätetypen wie Lasercutter oder CNC-Fräsen einbindet.
|
||||
|
||||
### 7.4 Formale Projektabnahme
|
||||
|
||||
Die Erstabnahme erfolgte am 3. Juni 2025 durch die Ausbildungsleitung der TBA. Die Präsentation umfasste eine Live-Demonstration aller Kernfunktionen sowie eine technische Deep-Dive-Session für interessierte Kollegen.
|
||||
|
||||
Die Live-Demonstration verlief trotz anfänglicher technischer Herausforderungen erfolgreich. Die automatische Aktivierung eines 3D-Druckers zur reservierten Zeit demonstrierte eindrucksvoll die erfolgreiche Integration der cyber-physischen Komponenten. Aktuell befindet sich das System in aktiver Beobachtung der realen Anwendung. Als letzter Schritt verbleibt die Schulung der Mitarbeiter, die in den kommenden Wochen stattfinden wird.
|
||||
|
||||
Die Bewertung der Ausbildungsleitung hob innovative Lösungsansätze für komplexe Integration, hohe technische Qualität der Implementation sowie die erkennbare Praxistauglichkeit des Systems hervor.
|
||||
|
||||
---
|
||||
|
||||
## Anlagen
|
||||
|
||||
**A1. Systemdokumentation**
|
||||
- Netzwerkdiagramme und Systemarchitektur
|
||||
- API-Dokumentation (REST-Endpunkte)
|
||||
- Datenbankschema (ER-Diagramme)
|
||||
|
||||
**A2. Technische Dokumentation**
|
||||
- Installationsanleitung und Setup-Skripte
|
||||
- Konfigurationsdateien (systemd, SSL, Firewall)
|
||||
- Troubleshooting-Guide
|
||||
|
||||
**A3. Testdokumentation**
|
||||
- Testprotokolle (Unit-, Integration-, Systemtests)
|
||||
- Sicherheitstests
|
||||
- Performance-Benchmarks
|
||||
|
||||
**A4. Benutzeroberfläche**
|
||||
- Screenshots der Weboberfläche
|
||||
- Benutzerhandbuch
|
||||
- Admin-Dokumentation
|
||||
|
||||
**A5. Projektmanagement**
|
||||
- Zeiterfassung nach Projektphasen
|
||||
- Kostenaufstellung
|
||||
- Übergabeprotokoll
|
||||
|
||||
---
|
||||
|
||||
## Glossar
|
||||
|
||||
| Begriff | Erläuterung |
|
||||
|---------|-------------|
|
||||
| **bcrypt** | Kryptographische Hash-Funktion für sichere Passwort-Speicherung mit konfigurierbarem Cost-Faktor |
|
||||
| **CSRF** | Cross-Site Request Forgery - Angriffsmethode, bei der authentifizierte Nutzer unbeabsichtigt Aktionen ausführen |
|
||||
| **Flask** | Python-basiertes Web-Framework für Backend-Entwicklung. Grundgerüst des MYP-Servers mit REST-API und Session-Management |
|
||||
| **Hardware in the Loop** | Testmethode, bei der reale Hardware-Komponenten in die Testumgebung eingebunden werden |
|
||||
| **Next.js** | React-basiertes Frontend-Framework, ursprünglich von Torben Haack für den Prototyp verwendet |
|
||||
| **Scheduler** | Zeitgesteuerte Komponente für automatisierte Smart-Plug-Operationen und Reservierungsverwaltung |
|
||||
| **Threads** | Parallele Ausführungsstränge innerhalb eines Prozesses für gleichzeitige Operationen |
|
||||
|
||||
---
|
||||
|
||||
**Projektstatistiken:**
|
||||
- **Codezeilen:** 9.000+ (Python/JavaScript)
|
||||
- **API-Endpunkte:** 100+
|
||||
- **Codeabdeckung:** 85%
|
||||
- **Gesamtkosten:** < 200 Euro
|
||||
- **Zeitverzug:** 10 Stunden vom ursprünglichen Zeitplan
|
||||
- **Systemlaufzeit:** In aktiver Beobachtung seit 3. Juni 2025
|
||||
Reference in New Issue
Block a user