ERP for droner: dronepilotens beredskapsplan

ERP - Emergency Response Plan, beredskapsplan - er dokumentet som sier hva man skal gjøre når kontrollen over en droneoperasjon er tapt: hvem som skal varsles, i hvilken rekkefølge, og hvordan man begrenser følgene av et styrt, en kollisjon eller en drone som flyr sin vei.

⚠️ Utenfor luftfarten betyr ERP som regel enterprise resource planning, altså forretningssystemer. I droneregelverket betyr ERP alltid beredskapsplanen: det er begrepet EASA, JARUS og de nasjonale myndighetene bruker.

Hva den ikke er: en nødprosedyre

Dette er den vanligste misforståelsen, og SORA-metoden avklarer den tydelig. Den skiller mellom tre nivåer av respons:

• avviksprosedyrer (contingency) bringer en unormal situasjon tilbake under kontroll, for eksempel et batteri som svekkes eller et midlertidig linkbrudd;
• nødprosedyrer håndterer selve luftfartøyet når det er ute av kontroll: flyterminering, fallskjerm, nødlanding;
• ERP begynner der luftfartøyet ikke lenger betyr noe. Den håndterer følgevirkningene av et kontrolltap - en skadet person, en brann, et luftfartøy som er truffet - og koordinerer innsatsen med nødetatene.

Enkelt sagt utspiller en nødprosedyre seg på fjernkontrollen. ERP utspiller seg på telefonen. Hoveddokumentet i SORA 2.5 sier det rett ut: ERP handler ikke om kontrollen over luftfartøyet.

Hva den må inneholde

SORA 2.5 plasserer den under det operative sikkerhetsmålet OSO #08 (operative prosedyrer er definert, validert og etterlevd). Vedlegg E fastsetter et minimumsinnhold:

1. listen over forventede nødsituasjoner som kan få følgevirkninger;
2. en prosedyre for hver av dem, inkludert kriteriene for å gjenkjenne situasjonen;
3. listen over relevante kontakter: flygekontroll, politi, brannvesen, førsteinnsats.

Vedlegget legger til fire forventede egenskaper. ERP må være egnet for situasjonen, effektivt dempe de forventede følgevirkningene, tydelig fordele oppgavene i besetningen, og være praktisk gjennomførbar og innøvd, slik at den kan gjennomføres under stress.

Det siste punktet er det folk glemmer. En ERP som ingen noen gang har gått gjennom, er en plan bare i navnet.

Tilpasset risikoen, ikke papirmengden

Vedlegg E presiserer at ERP bør stå i forhold til de mulige følgevirkningene av et bakkenedslag, som en brann eller et utslipp av giftig gass. En drone på 900 gram over et jorde og en multirotor på 25 kilo over et industriområde krever ikke samme plan.

Bevisnivået følger samme logikk. På lave sikkerhetsnivåer erklærer operatøren at ERP er tilstrekkelig. På høyt sikkerhetsnivå forventes en skrivebordsøvelse, og en kompetent tredjepart bekrefter at den er representativ. Øvelsen kan involvere tredjeparter som er nevnt i planen, som brannvesenet eller den som har ansvaret for stedet.

Hva som endret seg med SORA 2.5

I tidligere versjoner av metoden telte ERP som et tiltak mot bakkerisiko: å ha en kunne senke risikoklassen. SORA 2.5 fjernet den fra tiltakene og knyttet den i stedet til de operative prosedyrene.

Den praktiske følgen: en ERP senker ikke lenger kravnivået ditt. Den er en del av det du må dokumentere, uansett hvilket nivå det er.

En generell plan, og et ark per sted

En nyttig ERP har to lag.

Det første er generelt. Det ligger i MANEX, driftshåndboken: forventede situasjoner, prosedyrer, roller, varslingskjeden. Det endrer seg lite.

Det andre er spesifikt for hvert oppdrag. Det er dette som brukes i felt:

• stedets nøyaktige koordinater, til å lese opp for nødetatene;
• nærmeste sykehus og brannstasjon, med adkomstveier;
• lokale kontakter: kunde, ansvarlig for stedet, flygekontrollenhet;
• møteplassen og adkomst for utrykningskjøretøy;
• risikoer knyttet til stedet: lagrede produkter, kraftledninger, publikum til stede.

En generisk ERP, kopiert fra ett oppdrag til det neste, svikter nettopp her. Den dagen den trengs, har ingen tid til å slå opp adressen til sykehuset.

Når den kreves

I den åpne kategorien kreves ingen formell ERP. Å ha de nyttige numrene og stedets adresse klare er fortsatt god praksis.

I den spesifikke kategorien er den en del av søknaden: den forventes under OSO #08 i en SORA-vurdering, og driftshåndboken inneholder den. Den er et av dokumentene myndigheten ser på, fordi den viser om operatøren har tenkt på det som kommer etterpå.

Det viktigste

1. ERP er ikke en flyprosedyre. Den begynner når luftfartøyet ikke lenger betyr noe.
2. Den inneholder minst de forventede situasjonene, en prosedyre for hver og kontaktene som skal nås.
3. Den står i forhold til de mulige følgevirkningene, ikke til størrelsen på søknaden.
4. Den øves inn. En plan som aldri er øvd, holder ikke under stress.
5. Den brytes ned per sted. Det er feltarket som sparer tid.

Les mer

• SORA for droner - risikovurderingsmetoden som krever ERP i den spesifikke kategorien.
• MANEX - driftshåndboken som inneholder den generelle ERP.
• JARUS - gruppen av myndigheter som publiserer SORA.