Dronedesk automatiserer britisk SORA-risikovurdering

Dronedesk, driftsplattformen fra britiske Grey Rock Innovations Ltd, har publisert en detaljert teknisk beskrivelse av hvordan den automatiserer britisk SORA-risikovurdering basert på JARUS SORA v2.5. Systemet beregner flygegeografi og maksimal befolkningstetthet direkte fra operatørens deklarerte parametere.

Ifølge Dronedesk sin egen dokumentasjon bygger plattformen på UK SORA-rammeverket slik det er definert i AMC1 Article 11 i Air Navigation Order. Beregningsmotoren for soner og grenser følger JARUS SORA v2.5 Annex A-metodikken presist, mens befolkningstetthet håndteres med en egen kjernemetode fra Annex F.

Automatisert flygegeografi og sonegeometri

Kjernen i systemet er en kalkulator som regner ut de laterale og vertikale grensene for kontingensvolum (CV), bakkerisikobuffer (GRB) og tilstøtende volum (AV). Beregningene tar utgangspunkt i operatørens oppgitte dronedata og valgt termineringsmetode, og bruker formlene i Annex A, seksjon A.5.

Poenget er sporbarhet: hver sonegrense kan spores direkte tilbake til regelverkskilden. For en assessor eller myndighet som skal godkjenne en operasjon, gir det et konsistent og etterprøvbart grunnlag i stedet for manuelle skjønnsvurderinger.

Kjernemetode for befolkningstetthet

Det mest interessante teknisk er hvordan Dronedesk håndterer maksimal befolkningstetthet. I stedet for å hente tallet fra én enkelt GHS-POP-rutecelle, bruker plattformen «sliding-window»-kjernemetoden fra Annex F, seksjon 3.9.1.

Metoden vurderer tettheten over det realistiske spredningsområdet til dronen i deklarert høyde. Nabocellenes befolkning summeres med proporsjonal overlappsvekting, og kjerneradiusen beregnes fra ligning (21): r = z / tan(30°), med minimum 100 meter. Befolkningsdata kommer fra GHS-POP R2023A (EU-kommisjonens JRC), luftromsklassifisering fra OpenAIP, og folkeansamlinger identifiseres via OpenStreetMap Overpass API.

Operatøren beholder ansvaret

Dronedesk er tydelig på hva plattformen ikke gjør. ARC strategiske tiltak for luftrisiko presenteres kun til orientering og påføres ikke automatisk i den residuale ARC-en – slik vurdering krever uavhengig assessor-skjønn. Bakkerisikotiltakene M1(A), M1(B), M1(C) og M2 kan velges av operatøren, men krever obligatorisk skriftlig begrunnelse.

Plattformen validerer ikke om begrunnelsene er tilstrekkelige. Ansvaret for at deklarerte tiltak er korrekte og relevante ligger hos operatøren selv – en viktig presisering i en tid der stadig flere lener seg på programvare i søknadsprosessen.

Hva betyr dette for norske dronepiloter?

Selv om dette er britisk SORA, er metodikken bygget på JARUS SORA v2.5 – nøyaktig samme internasjonale rammeverk som EASA og Luftfartstilsynet bygger på i spesifikk kategori. Norge har nettopp fått SORA oppdatert til versjon 2.5, og det gjør denne typen verktøy direkte relevant for norske operatører som sliter med tunge søknadsprosesser.

For offshore-inspeksjon, kraftlinjer og landbruk – der BVLOS ofte er hele poenget – kan automatisert beregning av flygegeografi og befolkningstetthet spare mye tid. Samtidig understreker Dronedesk et prinsipp som også gjelder i Norge: verktøyet gjør beregningen, men operatøren står ansvarlig for vurderingene. For deg som vil forstå hele løpet, har vi en egen guide til spesifikk kategori og STS i Norge. Merk at Dronedesk foreløpig er tilpasset britisk regelverk, så norske søknader krever fortsatt tilpasning til Luftfartstilsynets nasjonale rammer.