# Umsetzungsroadmap Die Zeitangaben sind erste Planungskorridore. Sie werden nach Festlegung von Fahrzeug, Hardware und Produktumfang neu geschaetzt. ## Phase 0: Projektbasis und Sicherheitsgrenze Ziel: Ein reproduzierbares Integrationsprojekt statt unversionierter Softwarekopien. - GitHub-Repository und Branch-Schutz anlegen - ArduPilot- und QGC-Fork sowie exakte Baseline-Commits festlegen - Ziel-Fahrzeug, Flight Controller und Desktop/Mobile-Plattformen festlegen - Funktionsregister, Definition of Done und Evidenzformat abnehmen - Lizenz-, Marken- und Update-Strategie klaeren Ist am 17. Juli 2026: Repository, Matrix, Roadmap-Lieferung und der exakte QGC/MK15-Quellpin sind vorhanden. Offen bleiben ArduPilot, Fahrzeug/Board, Lizenzentscheidung, Asset-Rechte und die freigegebene Android-Toolchain. Exit Gate: Beide Quellstaende sind gepinnt, lokal unveraendert baubar und die Produktgrenzen sind dokumentiert. ## Phase 1: Vollstaendiger Source Audit Ziel: Codebasierter Ist-Stand fuer genau die gelieferten Versionen. - ArduPilot-Funktionsinventar je Fahrzeug und Build erzeugen - Flugmodi, Parameter, Commands, Missionsitems und MAVLink-Fluesse erfassen - QGC-ArduPilot-Plugins und vorhandene Setup-/Plan-/Fly-Funktionen abbilden - Gaps als konkrete Anforderungen mit Prioritaet und Risiko klassifizieren - Jede Matrixzeile mit Codepfad und Quellbeleg versehen Exit Gate: Alle P0/P1-Funktionen haben Owner, Ist, Soll, Akzeptanzkriterium und geplanten Test. ## Phase 2: Reproduzierbare SITL-Basis Ziel: Eine gefahrlose, automatisierbare Ende-zu-Ende-Verbindung. - ArduPilot SITL fuer den Ziel-Fahrzeugtyp starten - QGC ueber MAVLink/UDP verbinden und Parameter-/Mission-Roundtrip testen - Basisszenario Arm, Takeoff, Mission, RTL und Land ausfuehren - Telemetrie- und DataFlash-Logs als CI-Artefakte sichern - Linkverlust, Batterie- und Geofence-Szenarien als negative Tests anlegen Exit Gate: Ein gepinnter CI-Lauf reproduziert den Basisszenario-Test und veroeffentlicht auswertbare Evidenz. ## Phase 3: QGC-MVP fuer DroneShine Ziel: Sicheres Setup, Monitoring und Basiskontrolle fuer einen Fahrzeugtyp. - Custom-Build-Grundlage und Branding einrichten - ArduPilot-Verbindung, Parameter-Metadaten und Setup-Assistent verifizieren - Preflight-Status, Arm-Hemmnisse und kritische Warnungen klar darstellen - Flugmodi und gefuehrte Aktionen mit Bestaetigung und Feedback umsetzen - Karte, Instrumente, Batterie, GNSS, Linkstatus und Video integrieren Exit Gate: P0-Workflows bestehen SITL-Tests; keine kritische Aktion bleibt ohne ACK, Timeout und sichtbaren Endzustand. ## Phase 4: Mission und Sicherheit Ziel: Missionsworkflow und Failsafe-Konfiguration vollstaendig nachweisen. - Missionen erstellen, validieren, speichern, laden und uebertragen - Geofence, Rally Points, Terrain und unterstuetzte Kameraaktionen abdecken - Pause, Resume, Guided, RTL und Land je Fahrzeugverhalten testen - Failsafe-Konfiguration mit plausiblen Defaults und Warnungen versehen - Abbruch-, Wiederverbindungs- und Teiluebertragungsfaelle testen Exit Gate: P0/P1-Missions- und Sicherheitsfaelle sind in SITL verifiziert. ## Phase 5: DroneShine-Domainfunktionen Ziel: Nur die Funktionen ergaenzen, die QGC-Upstream nicht ausreichend bietet. - Reinigungsnutzlast und Gimbal-/Kameraworkflows spezifizieren - Checklisten, Einsatzvorlagen und Missionsmuster integrieren - Betriebsdatenexport und freigegebene Cloud-Schnittstellen definieren - Rollen, Audit Trail und Datenschutz bewerten - Offline-Verhalten und Karten-/Metadatenstrategie festlegen Exit Gate: Jede proprietaere Erweiterung hat Protokollvertrag, Simulationstest und dokumentiertes Degradationsverhalten. ## Phase 6: HIL, Bench und Feldvalidierung Ziel: Stufenweise Freigabe auf realer Hardware. - Flight Controller am Tisch ohne Propeller testen - Sensor-, RC-, Telemetrie-, Batterie- und Aktuatorpfade pruefen - Hardware-in-the-Loop und Stoerfallszenarien ausfuehren - Geschuetzte Boden- und Fesselflugtests durchfuehren - Erst danach kontrollierte Flugerprobung nach freigegebenem Testplan Exit Gate: Sicherheitsreview, Testprotokoll, bekannte Einschraenkungen und Rollback sind freigegeben. ## Phase 7: Release und Betrieb Ziel: Reproduzierbare, signierte und beobachtbare Releases. - Plattform-Builds und Tests in GitHub Actions ausfuehren - Artefakte, SBOM, Signaturen und Release Notes erzeugen - Update-/Rollback-Kanal definieren - Roadmap und Testreports unter der Dev-Domain bereitstellen - Upstream-Updates regelmaessig als eigene Regression bewerten ## Empfohlener erster Sprint 1. Ziel ist zunaechst genau ein Fahrzeugtyp und ein Flight-Controller-Board. 2. Der gelieferte ArduPilot-Fork wird mit Commit, Board-Build und Features gepinnt. 3. Lizenzweg, Branding-Rechte und Android-Signing-Verantwortung werden entschieden. 4. Die Android-Builder-Toolchain wird in GitHub Actions vollstaendig gepinnt. 5. Danach folgen QGC MockLink/Emulator und ein physischer MK15-Basistest. 6. ArduPilot SITL prueft Connect, Parameter, Mission, Start, Pause, RTL und Logs. 7. Erst aus den gemessenen Gaps entstehen weitere QGC-Codeaufgaben.