UAV-operaties
UAV-missies voor infrastructuurinspectie genereren beelden en sensorgegevens die halverwege de missie moeten worden geïnterpreteerd, zonder dat die interpretatie ooit gezag over de vluchtcontrole krijgt. Op deze pagina wordt uiteengezet hoe een dergelijke workflow zou worden gepland en uitgevoerd in TheEU Assist, geen verslag van een voltooide implementatie.
Hoe de workflow zou worden gestructureerd
Een missie zou worden ingediend door een geautoriseerde exploitant en opgesplitst in een gedefinieerde reeks fasen: onderzoek, analyse, nadere inspectie indien gerechtvaardigd, rapportage. Beeldmateriaal en sensorgegevens die tijdens de missie werden verzameld, zouden ter plaatse worden geïndexeerd, waardoor een kennispakket aan de eigen huurder van de exploitant zou worden geleverd. Een agent die voor de workflow is geconfigureerd, vergelijkt observaties met goedgekeurd referentiemateriaal en stelt een kandidaat-bevinding voor, ingevoerd met de status voorgesteld en gekoppeld aan de specifieke missie waar deze vandaan komt. Een verzoek om nadere inspectie zou hetzelfde voorgestelde-tot-goedgekeurde pad volgen voordat de UAV wordt geherpositioneerd.
De eigen vluchtcontroller, stabilisatie, navigatie, geofencing, terugkeer naar huis en noodprocedures van de UAV en het vermijden van botsingen, indien geïmplementeerd, zouden volledig buiten deze workflow blijven. Het platform zou nooit gezag over deze systemen hebben, vragen of uitoefenen, en geen enkele manoeuvre bereikt het vliegtuig totdat het een expliciete goedkeuring heeft gekregen.
Waar menselijke goedkeuring zit
Voor elk bevindings- of herpositioneringsverzoek is expliciete goedkeuring van een met name genoemde operator vereist voordat het als vastgesteld wordt beschouwd of er actie op wordt ondernomen. Dit is geen beleid dat bovenop de workflow wordt gelegd. Het is het mechanisme waarmee de workflow überhaupt verloopt: een niet-goedgekeurde fase voert eenvoudigweg de volgende stap niet uit.
Waar dit vandaag de dag op gebaseerd is, en waar niet
De workflow voor het ontleden van missies, de levenscyclus van voorgestelde tot goedgekeurde beoordelingen en de ondertekende auditketen achter elke actie zijn werkende onderdelen van het platform. Wat hier nog geen deel van uitmaakt: een missiespecifiek perceptiemodel dat is getraind op de eigen middelen en het terrein van een bepaalde operator, en dat is precies wat een eerste pilot zou bouwen. De deterministische vluchtcontroller van de UAV blijft door zijn ontwerp geheel buiten de reikwijdte van het platform. Het operationele oordeel bij een UAV-inzet zou de hele tijd bij het eigen team van de operator blijven, en elke missiespecifieke perceptievaardigheid zou samen met hen worden ontwikkeld, en niet als een kant-en-klaar model worden geleverd.
Een deel van de architectuur die ten grondslag ligt aan deze capaciteitenset is gedocumenteerd in documenten die nog in behandeling zijn. Deze pagina beschrijft waarvoor het platform is ontworpen, op een niveau dat geschikt is voor het plannen van een pilot, en niet voor een implementatiespecificatie.
Platformfuncties en interface zijn onderhevig aan voortdurende verbetering. Beschrijvingen in deze handleiding geven mogelijk niet de exacte lay-out of formulering van de laatst uitgebrachte versie weer.