UAV-Operationen
UAV-Missionen zur Infrastrukturinspektion erzeugen Bilder und Sensordaten, die während der Mission interpretiert werden müssen, ohne dass diese Interpretation jemals Autorität über die Flugsteuerung erlangt. Auf dieser Seite wird dargelegt, wie ein solcher Arbeitsablauf auf inTheEU Assist geplant und ausgeführt werden würde, und es handelt sich nicht um eine Aufzeichnung einer abgeschlossenen Bereitstellung.
Wie der Arbeitsablauf strukturiert sein würde
Eine Mission würde von einem autorisierten Betreiber eingereicht und in eine definierte Abfolge von Phasen unterteilt: Besichtigung, Analyse, genauere Inspektion, sofern erforderlich, Berichterstattung. Während der Mission gesammelte Bild- und Sensordaten würden vor Ort indiziert und in ein Wissenspaket eingespeist, das auf den eigenen Mieter des Betreibers zugeschnitten ist. Ein für den Workflow konfigurierter Agent vergleicht Beobachtungen mit genehmigtem Referenzmaterial und schlägt einen Kandidatenbefund vor, der mit dem Status „Vorgeschlagen“ eingegeben und an die spezifische Mission gebunden ist, aus der er stammt. Eine Anfrage nach einer genaueren Inspektion würde dem gleichen vorgeschlagenen bis genehmigten Weg folgen, bevor das UAV neu positioniert wird.
Der eigene Flugcontroller des UAV, Stabilisierung, Navigation, Geofencing, Return-to-Home- und Notfallverfahren sowie Kollisionsvermeidung, sofern implementiert, würden völlig außerhalb dieses Arbeitsablaufs bleiben. Die Plattform würde niemals die Autorität über diese Systeme innehaben, anfordern oder ausführen, und kein Manöver erreicht das Flugzeug, bis es eine ausdrückliche Genehmigung durchlaufen hat.
Wo menschliche Zustimmung sitzt
Jede Feststellungs- oder Neupositionierungsanfrage bedarf der ausdrücklichen Genehmigung eines benannten Betreibers, bevor sie als festgestellt behandelt oder bearbeitet wird. Dabei handelt es sich nicht um eine Richtlinie, die über dem Workflow liegt. Es ist der Mechanismus, durch den der Workflow überhaupt abläuft: Eine nicht genehmigte Phase führt den nächsten Schritt einfach nicht aus.
Worauf sich das heute stützt und worauf nicht
Der Mission-Decomposition-Workflow, der Lebenszyklus der vorgeschlagenen bis zur genehmigten Überprüfung und die unterzeichnete Prüfkette hinter jeder Aktion sind funktionierende Teile der Plattform. Was noch nicht Teil davon ist: ein missionsspezifisches Wahrnehmungsmodell, das auf die eigenen Ressourcen und das Gelände eines bestimmten Betreibers trainiert wird, was genau das ist, was ein erster Pilot erstellen würde. Der deterministische Flugcontroller des UAV bleibt konstruktionsbedingt vollständig außerhalb des Anwendungsbereichs der Plattform. Die operative Beurteilung eines UAV-Einsatzes würde während der gesamten Zeit beim eigenen Team des Betreibers verbleiben, und alle missionsspezifischen Wahrnehmungsfähigkeiten würden gemeinsam mit ihnen entwickelt und nicht als Standardmodell geliefert.
Ein Teil der diesem Funktionsumfang zugrunde liegenden Architektur ist in noch laufenden Einreichungen dokumentiert. Auf dieser Seite wird beschrieben, wofür die Plattform konzipiert ist, und zwar auf einer Ebene, die für die Planung eines Pilotprojekts geeignet ist, und nicht als Implementierungsspezifikation.
Plattformfunktionen und Benutzeroberfläche unterliegen einer kontinuierlichen Verbesserung. Die Beschreibungen in diesem Handbuch spiegeln möglicherweise nicht das genaue Layout oder den Wortlaut der neuesten veröffentlichten Version wider.