SORA v2.5 spiegata semplice: come funziona Specific Operations Risk Assessment per autorizzazioni UAS Specific Category

Quando l'operazione non rientra in uno STS pubblicato dalla Commissione (vedi CB#003) né in una PDRA pre-approvata, l'operatore deve costruire un safety case e sottoporlo a ENAC come autorizzazione operativa ex art. 12 Reg. (UE) 2019/947. Lo strumento metodologico riconosciuto da EASA come AMC è SORA v2.5 — Specific Operations Risk Assessment — sviluppato dal Joint Authorities for Rulemaking on Unmanned Systems (JARUS). La guida spiega i 10 step, la tabella iGRC (Tabella 2), la matrice SAIL I-VI (Tabella 7), i 17 OSO (non 24 come nella v2.0), e fornisce 3 esempi tipici di operazione commerciale con SAIL stimato. Verbatim dal Main Body v2.5 ed. 13/05/2024.

Scarica PDF

SORA v2.5 spiegata semplice: come funziona Specific Operations Risk Assessment per autorizzazioni UAS Specific Category

«Volo BVLOS su 8 km di linea ferroviaria a 15 km da Bologna, drone 12 kg, sorvolo di tratti suburbani. Nessuno STS lo copre, nessuna PDRA italiana lo replica. ENAC mi chiede un SORA: cosa significa, in pratica?»

Quando l'operazione esce dal perimetro degli STS (Standard Scenarios pubblicati dalla Commissione — vedi CB#003 Patentino A2 e STS) e da quello delle PDRA (Predefined Risk Assessments pre-approvate da EASA, es. PDRA-S01/S02 spraying), l'operatore deve costruire da sé il safety case e sottoporlo all'autorità competente — ENAC in Italia — come autorizzazione operativa ex art. 12 del Reg. (UE) 2019/947. Lo strumento metodologico riconosciuto da EASA come Acceptable Means of Compliance (AMC) è il SORA — Specific Operations Risk Assessment, sviluppato dal Joint Authorities for Rulemaking on Unmanned Systems (JARUS).

SORA è un metodo a 10 step che converte la descrizione operativa in un punteggio di rischio (SAIL, sei livelli I-VI), il quale a sua volta determina quali safety objectives l'operatore deve dimostrare di rispettare. È deterministico, tabellare e — una volta capito — meno spaventoso di quanto sembri.

Questa guida si basa sulla versione 2.5 del Main Body, edizione del 13 maggio 2024 (doc identifier JAR-DEL-SRM-SORA-MB-2.5). Rispetto alla v2.0 del 2019, la v2.5 ha 17 OSO (non 24), una matrice iGRC semplificata, e un'integrazione esplicita del Cyber Extension.

Disclaimer: SORA è AMC riconosciuto da EASA, ma non sostituisce il giudizio dell'Autorità Competente (ENAC). Il § 1.2 (f) del Main Body chiarisce esplicitamente che l'autorità può richiedere mitigazioni aggiuntive o accettare interpretazioni alternative caso per caso. Questa guida è uno strumento di lavoro per orientarsi nel metodo — non sostituisce un safety engineer o un consulente UAS specializzato in fase di compilazione del safety case.


Quando serve il SORA (vs STS, vs PDRA)

Il Reg. (UE) 2019/947 disciplina tre categorie di operazioni UAS:

Dentro la Specific ci sono tre strade per ottenere l'autorizzazione, in ordine crescente di sforzo:

  1. STS (Standard Scenarios) — pubblicati direttamente dalla Commissione. Es. STS-01 (VLOS in area popolata con drone classe C5) e STS-02 (BVLOS in area scarsamente popolata con drone C6 e observer). Per usarli basta una dichiarazione all'autorità competente, niente safety case completo.
  2. PDRA (Predefined Risk Assessment) — risk assessment pre-approvati a livello EASA o nazionale per scenari specifici. Es. PDRA-S01 spraying agricolo BVLOS in area scarsamente popolata. Più rapide da implementare, ma vincolano alle prescrizioni del PDRA.
  3. SORA — quando l'operazione non rientra in STS né in PDRA. L'operatore costruisce il safety case da zero, applicando la metodologia JARUS, e lo sottopone a ENAC.

Decision tree pratico: STS pubblicato copre il vostro volo? Sì → dichiarazione. No → esiste una PDRA applicabile (S01/S02 spraying o altre)? Sì → autorizzazione semplificata. No → SORA completo.


Aggiornamento al 29 maggio 2026 — EASA ED Decision 2025/018/R

Con ED Decision 2025/018/R, EASA ha formalmente integrato SORA 2.5 nelle AMC e GM del Regolamento (UE) 2019/947 (Issue 1, Amendment 4). L'aggiornamento conferma:

  • Processo riorganizzato in due fasi (Risk Definition + CSP Development), 10 step.
  • 17 OSO (consolidamento dalle 24 della v2.0 per eliminazione delle ridondanze).
  • Containment assessment valutato prima degli OSO.
  • OSO riformulati per delineare meglio le responsabilità di operatore, design del UAS e terze parti.

Implementazione operativa 2026: in più Stati membri (es. Cipro), dal 1° marzo 2026 SORA 2.5 è il metodo obbligatorio per i Risk Assessment delle nuove autorizzazioni. Dal 31 marzo 2026 in alcuni Stati solo SORA 2.5 è ammesso per nuove autorizzazioni. ENAC sta allineando le proprie procedure; verificare lo stato della transizione sul portale ENAC droni prima di sottomettere una nuova domanda.

I 10 step del SORA — diagramma di flusso

1Pre-application evaluationGo / No-go2iGRC determination1–103Final GRC (mitig. M1/M2)≤ 74ARC inizialea / b / c / d5Strategic MitigationsResidual ARC6Tactical Mitigations (TMPR)Low / Med / High7SAIL (GRC × ARC)I–VI8Containment + ground bufferLow / Med / High9OSO compliance (17 OSO)matrice × robustness10Comprehensive Safety Portfoliopacchetto ENAC
Schema — i 10 step del processo SORA 2.5

Il Main Body v2.5 organizza la procedura in 10 step sequenziali (§ 2.4):

StepCosa faOutput
1Pre-application evaluation: l'operazione rientra nello scope di SORA?Go / No-go
2iGRC determination — calcolo del intrinsic Ground Risk ClassNumero 1-10
3Final GRC determination — applicazione delle mitigazioni M1A/M1B/M1C/M2Final GRC ≤ 7
4ARC determination — Air Risk Class inizialeARC-a / b / c / d
5Strategic Mitigations per air risk → Residual ARCResidual ARC ridotta
6Tactical Mitigations — TMPR (Tactical Mitigation Performance Requirement)Low / Medium / High
7SAIL determination — Final GRC × Residual ARCSAIL I-VI
8Containment — verifica che UA non esca dal volume + ground risk bufferLow / Medium / High
9OSO compliance — verifica dei 17 Operational Safety Objectives in base al SAILMatrice OSO × robustness
10Comprehensive Safety Portfolio (CSP) — preparazione documentazione finalePacchetto sottoposto a ENAC

I termini-chiave (in inglese, sono lo standard internazionale):


Citazioni dirette dal Main Body v2.5

Scopo del SORA (§ 1.1 Preface, p. 18):

"The SORA is a guide that allows an operator to identify the risk and, if needed, reduce it to an acceptable level by tailoring their mitigations to the operation. This involves meeting or exceeding the Target Level of Safety (TLOS) regardless of the complexity of the operation, UA size, or the area of operation."

TLOS quantificato (Executive Summary, p. 14):

"For ground risk – less than one fatality per million hours (1E-6 fatalities per hour). For air risk – less than one mid-air collision per 10 million flight hours (1E-7 mid-air collisions per flight hour) for operations that primarily occur under self-separation and see-and-avoid."

Cosa fare se Final GRC > 7 (§ 4.3.4, p. 40):

"If the final GRC is greater than 7, the operation is considered to have more risk than the SORA is designed to support. The applicant may discuss options available with the competent authority, such as using the certified category or a new application."


Step #2 — la tabella iGRC (Tabella 2 Main Body, p. 34)

L'iGRC è il punto di partenza. Si determina incrociando:

Tabella 2 estratta letteralmente dal Main Body:

Dimensione UA →1 m / 25 m/s3 m / 35 m/s8 m / 75 m/s20 m / 120 m/s40 m / 200 m/s
Controlled Ground Area11233
< 5 ppl/km²23456
< 5034567
< 50045678
< 5.00056789
< 50.000678910
> 50.00078Not part of SORA

Note importanti:


Step #4 — ARC e adjacent airspace (Figura 6 Main Body)

L'ARC è qualitativa. La determinazione (Figura 6, p. 41) parte da una decision tree:

  1. L'operazione è in atypical airspace (spazio segregato, NOTAM, area militare TRA, ecc.)? Sì → ARC-a
  2. È in spazio aereo non controllato (Classe G) a quote VLL < 500 ft AGL, in area lontana da aeroporti e rotte commerciali? Sì → ARC-b
  3. È in spazio aereo non controllato ma in prossimità di aeroporti o quote intermedie? Sì → ARC-c
  4. È in spazio aereo controllato (CTR, ATZ) o ad alta quota? Sì → ARC-d

Adjacent airspace (Step #4 + Step #8 Containment): l'operatore deve considerare anche lo spazio adiacente al volume operativo. Se il drone esce dal volume per qualsiasi motivo (perdita controllo, deriva vento), in quale spazio finisce?


Step #7 — SAIL determination (Tabella 7 Main Body, p. 47)

Il SAIL si determina incrociando il Final GRC (Step #3) con la Residual ARC (Step #5). Tabella 7 estratta letteralmente:

Final GRC ↓ \ Residual ARC →abcd
≤ 2IIIIVVI
3IIIIIVVI
4IIIIIIIVVI
5IVIVIVVI
6VVVVI
7VIVIVIVI
> 7Category C (Certified) — fuori SORA

Letta in pratica: più cresce il Final GRC e/o la Residual ARC, più alto il SAIL. Il SAIL determinato indica al Step #9 quale livello di robustness ("Low", "Medium", "High") l'operatore deve dimostrare per ciascuno dei 17 OSO.

Tabella TMPR (Tabella 6, p. 45) — Tactical Mitigation Performance Requirement:

Residual ARCTMPR
ARC-dHigh
ARC-cMedium
ARC-bLow
ARC-aNo requirement

Il TMPR esprime il livello di prestazione richiesto al sistema Detect-and-Avoid (DAA) dell'operazione.


Step #9 — OSO compliance (17 OSO, Tabella 14 Main Body)

Il Main Body v2.5 elenca 17 Operational Safety Objectives (Tabella 14, p. 54). Per ciascuno il Step #9 richiede di dimostrare un livello di robustness (Low / Medium / High) — il livello richiesto cresce con il SAIL.

Esempi di OSO significativi:

OSO #Descrizione (sintesi)Quando rileva
OSO #01UAS Operator is competent and/or provenTutti i SAIL
OSO #04UAS designed and produced to authority recognised design standardsSAIL III-VI
OSO #05UAS designed considering system safety and reliabilitySAIL III-VI
OSO #08Operational procedures are defined, validated and adhered toTutti
OSO #09Remote crew trained and current and able to control abnormal situationTutti
OSO #11Procedures are in-place to handle the deterioration of external systemsSAIL II-VI
OSO #18Automatic protection of the flight envelope from human errorsSAIL III-VI
OSO #24UAS designed and qualified for adverse environmental conditionsSAIL IV-VI

Per i SAIL bassi (I-II) molti OSO si soddisfano con procedure scritte e formazione documentata. Per i SAIL alti (IV-VI) servono design organizzativo e tecnico spesso ottenibili solo con consulenti specializzati o certificazioni industriali.


3 esempi di operazione commerciale con SAIL stimato

Tre esempi tipici, con stima di SAIL. Numeri indicativi — il valore esatto dipende dalle mitigazioni effettivamente documentate.

Caso A — Ispezione fotovoltaico in campagna, BVLOS limitato

Caso B — Ispezione ferrovia in area suburbana

Caso C — Consegna in centro urbano

Per Caso A è ragionevole il SORA "self-built" con safety engineer junior. Caso B è il border-line del realismo. Caso C richiede consulenza specializzata + LUC (Light UAS Operator Certificate) realistico.


Le 5 trappole comuni

Trappola 1 — ConOps sottodimensionato

Descrivere solo "cosa fa il drone" senza i 5 volumi semantici: flight geography + contingency volume + ground risk buffer + adjacent area + adjacent airspace. Il § 2.2 del Main Body richiede tutti e cinque. Un ConOps che dimentica adjacent area o ground risk buffer viene rinviato in revisione.

Trappola 2 — Densità popolazione stimata "a occhio"

Il § 4.2.4 e l'Annex F del Main Body richiedono dati autoritativi (mappe ISTAT, satellite imagery validata). Una stima qualitativa "qui è campagna, sono pochi" non passa la review ENAC.

Trappola 3 — Confondere mitigation con OSO

Le M1(A/B/C) e M2 al Step #3 riducono la GRC (sono mitigazioni di ground risk). Gli OSO al Step #9 sono obiettivi organizzativi/tecnici legati al SAIL. Sono workstream distinti. Un applicante alle prime armi tende a confonderli, perdendo il senso della sequenzialità degli step.

Trappola 4 — Adjacent area calcolata male

Step #8: outer limit della adjacent area = distanza percorsa in 3 minuti a velocità max dell'UA, con floor 5 km e cap 35 km (Figura 7, p. 52). Errore comune: usare la sola flight geography come adjacent area.

Trappola 5 — Containment trascurato

Molti operatori dimenticano Step #8. Se la adjacent area contiene assemblies > 40k persone entro 1 km dall'operational volume, le Tabelle 8-13 possono portare l'operazione out of scope del SORA (verso Certified). Verificare assemblies prima di tutto il resto.


Checklist pre-submission ENAC: 12 punti

Pensata come pre-review prima di sottoporre il Comprehensive Safety Portfolio (CSP).


Come Hovra rende sostenibile il safety case SORA

Hovra Own integra nel ciclo operativo i template e i workflow del SORA v2.5 — l'obiettivo è ridurre il safety case da "documento ostico costruito da zero per ogni operazione" a "set di volumi + parametri + procedure riutilizzabili tra operazioni simili":

Scopri il modulo Specific Operations su hovra.it → Articoli correlati: CB#003 Patentino A2/STS · CB#006 U-Space Italia 2026 · CB#009 Frasi SPe e buffer


Bibliografia

Fonti primarie

Articoli correlati nella serie


Questo documento ha finalità informative e divulgative. Non sostituisce in alcun caso il parere di un safety engineer o di un consulente UAS specializzato. Il SORA è un metodo riconosciuto come AMC ma non sostituisce il giudizio dell'autorità competente (ENAC).

Nimber S.r.l.