# Zielarchitektur

Stand: 17. Juli 2026

## Verantwortlichkeiten

| Ebene | Verantwortung | Beispiele |
|---|---|---|
| QGroundControl | Bedienung, Konfiguration, Planung, Anzeige | Setup, Missionseditor, Karte, Video, Telemetrie, Log-Download |
| MAVLink | versionierte Kommunikationsgrenze | Heartbeat, Parameter, Mission Protocol, Commands, Status, FTP |
| ArduPilot | echtzeitkritische Fahrzeuglogik | Regelkreise, EKF, Navigation, Failsafes, Geofence, Aktuatoren |
| Companion Computer, optional | rechenintensive Zusatzlogik | Bildverarbeitung, KI, ROS 2, Cloud-Synchronisierung |
| Flughardware | Sensoren, Aktuatoren und physische Sicherheit | IMU, GNSS, Barometer, ESC, Motor, Safety Switch |

QGroundControl darf nie die einzige Instanz fuer eine sicherheitskritische
Reaktion sein. Funkverlust, niedrige Batteriespannung, EKF-Probleme und
Geofence-Verletzungen muessen auch ohne laufende Bodenstation im Autopiloten
beherrscht werden.

## Laufzeitfluss

```text
Pilot / Operator
       |
       v
DroneShine QGroundControl (Desktop oder Mobile)
       |
       | MAVLink 2 ueber USB, Telemetrieradio, UDP/TCP oder IP-Link
       v
ArduPilot auf dem Flight Controller
       |
       +--> Sensorik / Zustandschaetzung / Navigation
       +--> Failsafes / Geofence / Missionsausfuehrung
       +--> Motoren / Servos / Nutzlast
```

Die oeffentliche Webanwendung zeigt Roadmap und spaeter freigegebene
Testartefakte. Sie liegt nicht im Steuerpfad der Drohne.

## Entwicklungsstruktur

```text
droneshine-qgroundcontrol/
  data/                 Funktionsregister und spaeter Testevidenz
  docs/                 Architektur, Roadmap, Verfahren und ADRs
  roadmap/              statische Statusansicht
  deploy/               gehaertete statische Web-Laufzeit
  .github/workflows/    CI, Smoke-Test und Image-Publishing
  sources/ardupilot/    spaeter: gepinnter ArduPilot-Fork
  sources/qgroundcontrol/ spaeter: gepinnter QGC-Fork
  tests/                 spaeter: Contract-, SITL- und UI-Tests
  tools/                 spaeter: Inventar- und Reportgeneratoren
```

## Erweiterungspunkte in QGroundControl

Die Auswahl erfolgt erst nach dem Source Audit. Bevorzugt werden vorhandene
QGC-Abstraktionen:

1. `FirmwarePlugin` und `AutoPilotPlugin` fuer ArduPilot-spezifisches Verhalten.
2. MAVLink-Kommandos und Standard-Microservices statt proprietaerer Protokolle.
3. QML-Komponenten fuer neue Bedien- und Anzeigeelemente.
4. Custom Build/Branding fuer DroneShine-spezifische Oberflaeche und Defaults.
5. Eigene MAVLink-Dialect-Erweiterungen nur, wenn Standardnachrichten die
   Anforderung nachweislich nicht abdecken.

## Versionierung

Eine Aussage wie "ArduPilot kann Funktion X" ist ohne Fahrzeug und Version zu
ungenau. Die Baseline wird mindestens durch folgende Werte festgelegt:

- ArduPilot-Repository, Release und Commit
- Fahrzeug-Firmware, zum Beispiel Copter, Plane oder Rover
- Flight-Controller-Board und aktivierte Build-Features
- QGroundControl-Repository, Release und Commit
- MAVLink-Dialect und Protokollversion
- Betriebssysteme und Hardware der Bodenstation

Jede Funktion im Register erhaelt spaeter Codepfad, Parameter/Message-IDs,
Testfall und Evidenz. Erst dann darf sie als verifiziert gelten.

## Dokploy und DNS

Dokploy ist sinnvoll fuer die statische Roadmap und spaeter fuer freigegebene
Testreports, zum Beispiel unter:

```text
https://dev-qgroundcontrol.office-dashboard.com/roadmap/
```

Nicht sinnvoll ist Dokploy als primaere Umgebung fuer die native QGC-App, fuer
GUI-Entwicklung oder fuer reale Fernsteuerung. CPU-intensive Builds,
Abhaengigkeitsinstallationen und breite Simulationssuiten gehoeren in GitHub
Actions/GHCR. Der VPS bleibt Deployment- und leichte Laufzeitumgebung.

Die statische Laufzeit wird als nicht-root Container in GitHub Actions gebaut,
getestet und mit Provenance sowie SBOM nach GHCR veroeffentlicht. Dokploy zieht
nur einen unveraenderlichen Image-Digest. Details und Freigabegates stehen in
`docs/deployment.md`.