DISTRIBUTION STATEMENT
NATURA DOCUMENTO
DOCUMENT NUMBER:
REV.:
CIRA-CF-12-0600
1
PROJECT
PROGETTO
JOB
COMMESSA
WP
PROGRESSIVO DI ARCHIVIO
NO. OF PAGES
DELIVERABLE
RISTRETTO
ARCHIVIO
/CIRA/TECV
0036
3+109
TITLE
TECVOL-II: System Requirements
PREPARED
PREPARATO
REVISED
VERIFICATO
APPROVED
APPROVATO
AUTHORIZED
AUTORIZZATO
De Lellis Ettore
(PMIS)
De Lellis Ettore
(PMIS)
De Lellis Ettore
(PMIS)
De Lellis Ettore
(PMIS)
DATE/DATA
DATE/DATA
01/08/2012
01/08/2012
DATE/DATA
01/08/2012
DATE/DATA
03/08/2012
BY THE TERMS OF THE LAW IN FORCE ON COPYRIGHT, THE REPRODUCTION, DISTRIBUTION OR USE OF
THIS DOCUMENT WITHOUT SPECIFIC WRITTEN AUTHORIZATION IS STRICTLY FORBIDDEN
A NORMA DELLE VIGENTI LEGGI SUI DIRITTI DI AUTORE QUESTO DOCUMENTO E' DI PROPRIETA' CIRA E NON POTRA'
ESSERE UTILIZZATO, RIPRODOTTO O COMUNICATO A TERZI SENZA AUTORIZZAZIONE
I
DOCUMENT NUMBER:
REV.:
CIRA-CF-12-0600
1
TITLE:
TECVOL-II: System Requirements
ABSTRACT:
Nell’ambito del programma PRO.R.A. (art.4 c.1 DM 305/98) il CIRA ha portato avanti a partire dal
2004 il progetto TECVOL riguardante lo sviluppo di tecnologie per il volo autonomo di UAV con
dimostrazioni in volo tramite piattaforma volante manned ultraleggera. Il progetto TECVOL si è
concluso nel 2012 con l’Acceptance Review.
La revisione del programma PRO.R.A. prevede l’estensione di tale progetto, che d’ora in poi sarà
denominato TECVOL-II, ha un duplice obiettivo: lo sviluppo delle tecnologie per raggiungere elevati
livelli di autonomia per gli UAV con lo specifico obiettivo di migliorare l’affidabilità e la sicurezza del
volo e la flessibilità delle operazioni, riducendo al contempo tempi e costi di sviluppo dei nuovi
prodotti; lo sviluppo di sistemi automatici di ausilio al pilotaggio in velivoli del segmento Personal Air
Transport. L’insieme delle tecnologie UAV e dei sottosistemi per velivoli manned sviluppati all’interno
del progetto rappresenta il sistema oggetto di questo documento che ha come scopo la definizione dei
relativi System Requirements.
L’attuale revisione del documento (REV.1) è avvenuta in seguito alla System Requirements Review di
progetto che si è conclusa con successo in data 30/07/2012.
AUTHORS:
De Lellis Ettore;Di Benedetto Carlo;Pascarella Domenico;Nebula Francesco;Morani Gianfranco;De
Mizio Marco;Genito Nicola;Montaquila Roberto V.;Luongo Salvatore;Castrillo Vittorio Ugo;
Baraniello Vincenzo;Di Vito Vittorio;Mercogliano Paola
APPROVAL REVIEWERS:
De Lellis Ettore
APPROVER
De Lellis Ettore
AUTHORIZATION REVIEWERS:
De Lellis Ettore;Ciniglio Umberto;Corraro Federico;Fusco Francesco;Cuciniello Giovanni;Vitale
Antonio;Filippone Edoardo;Leoncini Paolo;Inverno Michele;Schiano Pasquale;Mercogliano Paola
AUTHORIZER
De Lellis Ettore
II
DOCUMENT NUMBER:
REV.:
CIRA-CF-12-0600
1
DISTRIBUTION RECORD:
DEPT
NAME
*
DEPT
NAME
*
* PT = PARTIAL
A = ALL
III
TECVOL-II
TECVOL-II - System Requirements
CIRA-CF-12-0600
REVISION LIST
LISTA DELLE REVISIONI
REV
DESCRIPTION
DATE
EDITOR
0
Prima emissione
06/06/2012
E. De Lellis
1
Revisione a seguito della SRR Review di cui il
documento è oggetto.
11/07/2012
E. De Lellis
1
TECVOL-II
TECVOL-II - System Requirements
CIRA-CF-12-0600
INDICE DEI CONTENUTI
1
INTRODUZIONE ................................................................................................................................................... 4
1.1
1.2
1.3
1.4
1.5
1.6
1.1
2
CONTESTO GENERALE ................................................................................................................................... 11
2.1
2.2
2.3
2.4
2.5
2.6
3
SCOPO DEL DOCUMENTO ....................................................................................................................................... 4
ORGANIZZAZIONE DEL DOCUMENTO ..................................................................................................................... 5
CONTRIBUTI AL DOCUMENTO ................................................................................................................................ 5
APPLICABILITÀ...................................................................................................................................................... 6
DOCUMENTI APPLICABILI ...................................................................................................................................... 6
DOCUMENTI DI RIFERIMENTO ................................................................................................................................ 6
ACRONIMI ............................................................................................................................................................. 9
TECNOLOGIE PER UAS: COERENZA CON LO SCENARIO INTERNAZIONALE ........................................................... 12
SISTEMI AVIONICI DI AUSILIO AL PILOTAGGIO DI VELIVOLI PATS: MOTIVAZIONI ............................................... 18
SINERGIA CON IL PROGETTO MISE L808/95 ....................................................................................................... 20
TOOLS/FACILITIES DI VERIFICA E VALIDAZIONE .................................................................................................. 20
RELAZIONE TRA TECVOLII ED ATM AIRPOT LAB ............................................................................................ 23
ANALISI DELLA ACCEPTANCE REVIEW DEL PROGETTO TECVOL-I .................................................................... 24
REQUISITI FUNZIONALI ................................................................................................................................. 25
3.1
3.2
INTRODUZIONE ALLA LETTURA DEI REQUISITI ..................................................................................................... 25
TECNOLOGIE DI VOLO AUTONOMO PER UAV (DA TECVOL-I) ........................................................................... 27
3.2.1.1
3.2.1.2
3.2.1.3
3.2.1.4
3.2.1.5
Autonomous Collision Avoidance Multisensor based (ACAM) ............................................................................27
Automatic Take Off (ATOF) .................................................................................................................................28
Autolanding EGNOS&Visual-based (ALEV) .......................................................................................................28
Automatic 4D plan execution (4DPE) ...................................................................................................................31
RPV .......................................................................................................................................................................35
3.3 TECNOLOGIE DI VOLO AUTONOMO PER UAV ...................................................................................................... 36
3.3.1
Autonomous Mission Management and Execution ................................................................................... 36
3.3.1.1
3.3.1.2
3.3.1.3
3.3.1.4
3.3.1.5
3.3.2
HMI and Payload management ................................................................................................................ 61
3.3.2.1
3.3.2.2
3.3.2.3
3.3.3
Autonomous Mission Manager (High Autonomy Planner/Replanner - HAPR) ....................................................37
Tecnologie di Adaptive Flight Control Law (AFCL) .............................................................................................53
Tecnologie per l’Integrated Health Management (IHMG) .....................................................................................55
Automatic Taxi Replanner (ATRP) .......................................................................................................................58
Tecnologie per l’Automatic Taxi Management (ATMA) ......................................................................................60
Preflight Support Mission Planner (PSMP) ...........................................................................................................61
Preflight Automatic Mission Planner (PAMP).......................................................................................................65
Automatic Target Detection and Recognition System (ATDR) .............................................................................66
Datalink .................................................................................................................................................... 70
3.3.3.1
3.3.3.2
Tecnologie relative ai Reconfigurable Datalink (DTLK) .......................................................................................71
Tecnologie relative ai Datalink satellitari ..............................................................................................................73
3.4 SISTEMI AVANZATI DI AUSILIO AL PILOTAGGIO PER VELIVOLI MANNED PATS.................................................... 74
3.4.1
Situational Awareness Systems ................................................................................................................. 74
3.4.1.1
3.4.1.2
3.4.1.3
3.4.2
Systems for Automatic Flight .................................................................................................................... 82
3.4.2.1
3.4.2.2
3.4.2.3
3.4.2.4
3.4.2.1
4
Weather Situational Awareness System (WSAS) ..................................................................................................74
Traffic Awareness and Alerting System (TRAW) .................................................................................................76
Terrain Situational Awareness System (TAWS) ....................................................................................................80
Advanced Cockpit (ADCO) ...................................................................................................................................82
4D Contract Management System (4DMS) ...........................................................................................................89
Traffic & Obstacle Avoidance System (TOAS) .....................................................................................................92
Multi-Functional Display & Decision System (MFDD) ........................................................................................96
Smart Autopilot (SMAP) .......................................................................................................................................99
ROAD MAP TECNOLOGICA DEL PROGETTO ......................................................................................... 101
4.1
4.2
ROAD MAP E MILESTONES DI PROGETTO ............................................................................................................ 101
ORGANIZZAZIONE DEI DELIVERABLE DI PROGETTO ........................................................................................... 106
LISTA DELLE FIGURE
2
CIRA-CF-12-0600 Rev. 1 P. 2/109
TECVOL-II
TECVOL-II - System Requirements
CIRA-CF-12-0600
Figura 2-1 - Unmanned Systems Integrated Roadmap FY2011-2036 by DoD USA (Autonomy)
[R2] .................................................................................................................................................... 14
Figura 2-2 - UAS Airspace Integration – USA DoD Operational View [R2] ................................... 17
Figura 2-3 - Unmanned Systems Integrated Roadmap FY2011-2036 by DoD USA (Airspace
Integration) [R2] ................................................................................................................................ 17
Figura 2-4 - Unmanned Systems Integrated Roadmap FY2011-2036 by DoD USA
(Communications) [R2] ..................................................................................................................... 18
Figura 2-5 - Progetto EPSON Indice di mobilità in Europa. Dati al 2004 ........................................ 18
Figura 2-6 - Indice della domanda di traffico aereo personale in Europa.......................................... 19
Figura 2-7 - Tools/Facilities di verifica e validazione ....................................................................... 23
Figura 3-1 - Architettura funzionale di bordo di TEVOL-II .............................................................. 37
Figura 4-1 – Road Map tecnologica congiunta dei progetti TECVOL-II - MISE ........................... 103
Figura 4-2 – Diagramma di flusso alla base dell’albero della documentazione di ogni sistema ..... 109
LISTA DELLE TABELLE
Tabella 2-1 – Linee tecnologiche individuate nel documento di ConOps ......................................... 11
Tabella 2-2 - Livelli di autonomia [R7] ............................................................................................. 13
Tabella 2-3 - Spazi aerei e missioni per UAV [R5] ........................................................................... 15
Tabella 2-4 - Esempi di requisiti per alcune missioni [R6] ............................................................... 16
Tabella 3-1 – Metodi di verifica applicabili alle tecnologie/sistemi sviluppati nel progetto ............. 26
Tabella 3-2 – Analisi dei Conops [A1] per l’Autonomous Mission Manager ................................... 42
Tabella 3-3 – Analisi dei Conops [A1] per l’Adaptive Flight Control Law ...................................... 53
Tabella 3-4 – Analisi dei Conops [A1] per le tecnologie di Integrated Health Management............ 56
Tabella 3-5 – Analisi dei Conops [A1] per l’Automatic Taxi Replanner .......................................... 59
Tabella 3-6 – Analisi dei Conops [A1] per il Preflight Support Mission Planner ............................. 62
Tabella 3-7 – Analisi dei Conops [A1] per l’Automatic Target Detection and Recognition System 67
Tabella 3-8 – Analisi dei Conops [A1] per le tecnologie di Reconfigurable Datalink ...................... 72
Tabella 3-9 – Analisi dei Conops [A1] per il Weather Situational Awareness System..................... 75
Tabella 3-10 – Analisi dei Conops [A1] per il Traffic Awareness and Alerting System .................. 77
Tabella 3-11 – Analisi dei Conops [A1] per il Terrain Situational Awareness System .................... 81
Tabella 4-1 – Matrice di tracciabilità project requirements / tecnologie individuate nei Conops ... 102
Tabella 4-2 – Milestones di programma afferenti al progetto TECVOL-II a piano triennale vigente
[R1] .................................................................................................................................................. 104
Tabella 4-3 - Milestones di programma afferenti al progetto TECVOL-II proposta aggiornata ..... 105
Tabella 4-4 – Matrice di tracciabilità tecnologie individuate nei Conops / project requirements ... 106
3
CIRA-CF-12-0600 Rev. 1 P. 3/109
TECVOL-II
1
TECVOL-II - System Requirements
CIRA-CF-12-0600
Introduzione
Nell’ambito del programma PRO.R.A. (art.4 c.1 DM 305/98) il CIRA ha portato avanti a partire dal
2004 il progetto TECVOL-I riguardante lo sviluppo di tecnologie per il volo autonomo di UAV
con dimostrazioni in volo tramite piattaforma volante manned ultraleggera. L’acceptance review del
progetto TECVOL-I è stata ultimata come sancito in [R51].
La revisione del programma PRO.R.A. come definito in [R1] prevede l’estensione di tale progetto,
che d’ora in poi sarà denominato TECVOL-II, con lo scopo di sviluppare:
• tecnologie per raggiungere elevati livelli di autonomia per gli UAV con lo specifico
obiettivo di migliorare l’affidabilità e la sicurezza del volo e la flessibilità delle operazioni,
riducendo al contempo tempi e costi di sviluppo dei nuovi prodotti;
• sistemi automatici di ausilio al pilotaggio in velivoli del segmento Personal Air Transport.
L’insieme delle tecnologie UAV e dei sottosistemi per velivoli manned sviluppati all’interno del
progetto rappresenta il sistema oggetto di questo documento.
1.1 Scopo del documento
Lo scopo del documento è quello di definire i requisiti di alto livello del sistema sopra definito.
I requisiti sono definiti sulla base dei concept of operations (ConOps) del progetto già definiti con il
deliverable [A1]. Preliminarmente alla definizione dei ConOps, una prima proposta sugli obiettivi
tecnologici ad altissimo livello, inquadrabile come vision del progetto stesso, era stata sottoposta
agli stakeholders di progetto recependo sia dei commenti sulle prime idee proposte sia eventuali
ulteriori argomenti di interesse comune da inserire nel progetto stesso. Quest’interazione è stata
documentata in [R3] e sintetizzata nel §5.5 di [A1]. Inoltre, tali feedback sono stati utilizzati per
definire le priorità sullo sviluppo delle diverse linee tecnologiche, in quanto i ConOps si riferiscono
volutamente ad un ampio spettro di linee tecnologiche e di ricerca, il cui pieno sviluppo non sarebbe
possibile da espletare con il solo progetto TECVOL-II.
La definizione dei ConOps del progetto è seguita oltre che dal suddetto processo di coinvolgimento
degli stakeholders anche un’approfondita analisi di quanto sviluppato nell’ambito del progetto
TECVOL-I che naturalmente costituisce la base di partenza che deve però essere opportunamente
ampliata per rispondere alle nuove esigenze. In particolare, le tecnologie individuate nei ConOps
sono in parte quelle funzionalità di GNC che, rispetto a quanto già implementato nel progetto
TECVOL-I, possano ulteriormente innalzare l’autonomia di bordo, ed in parte quelle tecnologie sia
HW che SW necessarie alla futura realizzazione di un sistema avionico prototipale di un UAV.
Inoltre, il progetto si prefissa di sviluppare tutti quei sistemi automatici di ausilio al pilotaggio, in
parte basati sugli algoritmi autonomi già sviluppati per gli UAV ed in parte sviluppati ex novo.
Il presente documento si propone di selezionare le linee tecnologiche individuate come
maggiormente prioritarie e schematizzarle attraverso dei requisiti di alto livello inquadrabili come
project requirements da soddisfare nell’arco del suo orizzonte temporale (2012-2016).
Di conseguenza nel presente documento saranno solo definiti dei requisiti funzionali su possibili
tecnologie e sistemi da sviluppare nell’ambito del progetto. Non saranno definiti dei requisiti
operativi, di interfaccia, di product assurance, ambientali e di vincolo. La definizione di tale tipo di
4
CIRA-CF-12-0600 Rev. 1 P. 4/109
TECVOL-II
TECVOL-II - System Requirements
CIRA-CF-12-0600
requisiti sarà demandata a dei successivi system requirements definiti per ogni singolo sistema e/o
tecnologia individuati per poi proseguire con lo sviluppo previsto dalle linee guida sopra
individuate.
Infine, le tecnologie o sistemi individuati saranno caratterizzate da un particolare TRL al quale il
relativo processo di sviluppo tenderà. Sulla base del TRL sarà anche associato ad ogni tecnologia o
sistema un opportuno albero della documentazione definito con l’obiettivo di essere coerenti con le
linee guida RTCA DO-178-C livello D per quanto riguarda le eventuali componenti SW.
1.2
Organizzazione del documento
Il documento sarà strutturato su quattro capitoli. Il primo capitolo rappresenta un’introduzione agli
scopi del presente documento ed al progetto. Nel secondo capitolo è descritto il contesto generale
nel quale il progetto si esplica. In particolare in esso si approfondisce in primis il contesto interno al
CIRA, individuando le correlazioni sia tra i due output principali (documento [A1] e presente
documento) prodotti dal processo finora seguito nell’individuazione dei project requirements
(processo descritto nel precedente paragrafo), sia tra i due progetti principali dell’unità sistemi
TECVOL-II e MISE sottolineando le relative sinergie. Nel secondo capitolo è, inoltre, descritto il
contesto internazionale di riferimento nell’ambito delle tecnologie per il volo autonomo
evidenziando come le tematiche di ricerca affrontate dai progetti TECVOL-II e MISE sono ritenute
strategiche anche in altri importanti programmi internazionali. Nel terzo capitolo sono definiti tutti i
project requirements e, infine, nel quarto capitolo sono presentati alcuni cenni sulla gestione del
progetto ed in particolare sono presentate e descritte le milestone di programma previste
nell’orizzonte temporale del progetto (2012-2016) e la roadmap tecnologica individuata in modo
sinergico nei due progetti TECVOL-II e MISE.
1.3 Contributi al documento
Il documento ha avuto diversi contributi direttamente e/o attraverso deliverables/note tecniche
emesse nell’ambito del progetto. In particolare,
U. Ciniglio ha contribuito ai capitoli §2 e §4;
D. Pascarella e S. Parrilli hanno contribuito al §2 ed ai paragrafi §3.3.1.1 e §3.3.1.3,
V. Di Vito ha contribuito ai paragrafi §3.2.1.1, §3.2.1.4, §3.4.1.2, §3.4.2.1, §3.4.2.2 e §3.4.2.3;
G. Morani ha contribuito ai paragrafi §3.3.1.2, §3.3.1.4 e §3.3.1.5;
N. Genito ed A. Vitale hanno contribuito al paragrafo §3.3.1.3;
C. Di Benedetto ha contribuito al §3.3.2.1,
M. De Mizio ha contribuito al paragrafo §3.3.2.3;
V. Castrillo e R. Montaquila hanno contribuito ai paragrafi §3.3.3.1 e §3.3.3.2;
P. Mercogliano ha contribuito al paragrafo §3.4.1.1;
V. Baraniello ha contribuito ai paragrafi §3.4.1.3 e §3.4.2.4;
F. Corraro ha contribuito al §4.
5
CIRA-CF-12-0600 Rev. 1 P. 5/109
TECVOL-II
TECVOL-II - System Requirements
CIRA-CF-12-0600
L’editor E. De Lellis ha integrato ed armonizzato tutti questi contributi ed ha scritto i paragrafi non
citati. Tutti i responsabili dell’unità Sistemi, inoltre, hanno dato un fattivo contributo nel rivedere i
contenuti e fornire suggerimenti.
1.4 Applicabilità
Il presente documento rappresenta il documento di System Requirements del progetto TECVOL-II,
ed in particolare rappresenta il deliverable con codice SGP 23603 della commessa 6020088100.
1.5 Documenti applicabili
[A1] CIRA-CF-11-1355 “TECVOL-II: Concept of Operations”
1.6 Documenti di riferimento
Tutti i documenti di seguito riportati vanno considerati nell’ultima revisione disponibile.
[R1]
PRO.R.A. - PROgramma nazionale di Ricerche Aerospaziali Piano Triennale 2012-2014,
CIRA-CF-11-1370, Approvato nell'Assemblea dei Soci del 16/12/2011
[R2]
Unmanned Systems Integrated Roadmap, FY2011-2036, Department of Defense USA
[R3]
TECVOL-II: Interazione con gli stakeholders sulla vision del progetto, CIRA-CF-11-1356
[R4]
ICAO Cir 328, AN\190 Unmanned Aircraft Systems (UAS), 2011
[R5]
EUROCAE WG 73, UAS insertion into commercial airspace: Europe and US standards
perspective, Digital Avionics Systems Conference (DASC) 2011 IEEE/AIAA 30th, pagg.
5C5-1-5C5-12
[R6]
Concept for civil UAS applications, D1.2 INOUI, 2008
[R7]
NATO - NIAG (SG/75) “Pre-feasibility Study on UAV Autonomous Operations”, 2004
[R8]
NIST Special Publication Autonomy Levels For
Framework”;
[R9]
TECVOL-I: Requisiti SW di Alto Livello per il Modulo Autonomous GNC, CIRA-CF-120625,
[R10]
Meeting di Ri-pianificazione progetti MISE & TECVOLII, CIRA-VER-12-0083, Febbraio
2012
[R11]
Studio di Fattibilità per il Laboratorio Sensori di Navigazione: Definizione dei requisiti di
sperimentazione, CIRA-CF-11-1364
[R12]
“Estimating the demand for Personal Air Transport - The EPATS project”, Ad de Graaff ,
presentazione Febbraio 2009.
[R13]
Progetto SENECA: “Sistemi GNSS per la Navigazione Elicotteristica (Versione Finale)”,
E. Filippone, Novembre 2010, CIRA-CF-10-1219, Rev1.
[R14]
Indagine di mercato sui Sistemi Avionici di Guida, Navigazione e Controllo per aerei
manned, MISE, Novembre 2011
Unmanned Systems (ALFUS)
6
CIRA-CF-12-0600 Rev. 1 P. 6/109
TECVOL-II
TECVOL-II - System Requirements
CIRA-CF-12-0600
[R15]
FAA Order 8130.34 “Airworthiness Certification of Unmanned Aircraft Systems and
Optionally Piloted Aircraft, Ottobre 2010
[R16]
Standard per l’interoperabilità dei Sistemi di Simulazione del CIRA, CIRA-CF-12-0422,
Maggio 2012
[R17]
XMALE – Concept of Operations Part I. CIRA-CF-11-1376, Aprile 2012
[R18]
XMALE – Concept of Operations Part II. CIRA-CF-11-1377, Aprile 2012
[R19]
Survey on on-board sensors to be possibly used for “weather awareness”. CIRA-CF-120520.
[R20]
Indagine sui prodotti satellitari meteo di potenziale uso per la “Weather Awareness”,
CIRA-CF-12-0519.
[R21]
State of the art of Visualization for Weather Awareness, CIRA-CF-12-0336
[R22]
Pericoli per piattaforme General Aviation e UAV derivanti da fenomeni meteorologici.
CIRA-TR-12-0011.
[R23]
Contribution to the initial validation plan supporting the integration activities. CIRA-TR11-0036
[R24]
TECVOL-II - Kick Off tecnico, CIRA-VER-11-0262
[R25]
TECVOL-I: Requisiti SW di Alto Livello per il Modulo Autonomous GNC, CIRA-CF-120625, In fase di emissione.
[R26]
TECVOL-I: Sviluppo e Testing Real Time del Modulo SW Autonomous Collision
Avoidance con Singolo Ostacolo, CIRA-CF-08-0659, Aprile 2009
[R27]
TECVOL-I: Sviluppo e Testing Real Time del Modulo SW 4D Way-Points Autonomous
Mid Air Flight, CIRA-CF-09-1566, Gennaio 2010
[R28]
TECVOL-I: Definizione dei requisiti della Ground Control Station, CIRA-CF-07-1459
[R29]
TECVOL-I: Progettazione della sezione RPV della Ground Control Station, CIRA-CF-080390
[R30]
TECVOL-I: Report chiusura attività - Sperimentazione del sistema di visione immersiva
stereoscopica per UAV, CIRA-CF-11-0348 Rev. 1
[R31]
TECVOL-I: Definizione dei requisiti per FMS con funzionalità di 4D Trajectory
Management, CIRA-CF-08-1467
[R32]
TECVOL-I: Sviluppo e Testing Real-Time del Modulo di Autonumous Take-Off e Post
Touch-Down, CIRA-CF-09-1378
[R33]
TECVOL-I: Validazione in volo su FLARE del Modulo SW Free Path DGPS/AHRS
Autolanding, CIRA-CF-07-1206, Rev. 1
[R34]
Flight Test and On-Gound Analisys unità EGNOS, CIRA-CF-12-0786
7
CIRA-CF-12-0600 Rev. 1 P. 7/109
TECVOL-II
TECVOL-II - System Requirements
CIRA-CF-12-0600
[R35]
Indagine sugli aspetti comunicativi relativi alle funzionalità di Handover e Multicrew,
CIRA-CF-12-0271
[R36]
Indagine sugli aspetti comunicativi relativi alla funzionalità di controllo di sistemi
multiship, CIRA-CF-12-0626
[R37]
D. Rudinskasa, Z. Gorajb, and J. Stankūnasc: “Security analysis of UAV radio
communication system”, Aviation, Volume 13, Issue 4, pagine 116-121, 2009
[R38]
H. Saarnisaari, “Universal Frequency Domain Baseband Receiver Structure for Future
Military Software Defined Radios”, NATO Research and Technology Organization, RTOMP-IST-092-5
[R39]
J. Leduc, M. Adrat, M. Antweiler, and H. Elders-boll: “Legacy Waveforms on Software
Defined Radios: Benefits of Advanced Digital Signal Processing”, NATO Research and
Technology Organization, RTO-MP-IST-092-9
[R40]
W. Felber: “Wireless Communication Systems Design for Tactical Software-Defined
Radios – From Scenario-Based Analysis to Channel and Waveform Parameter”, NATO
Research and Technology Organization, RTO-MP-IST-092-11
[R41]
M. Rice, A. Davis, and C. Bettweiser: “Wideband Channel Model for Aeronautical
Telemetry”, IEEE Transactions on Aerospace and Electronics Systems, Vol. 40, No. 1,
pagine 57-69, 2004
[R42]
M. Rice: “PCM/FM Aeronautical Telemetry in Frequency Selective Multipath
Interference”, IEEE Transactions on Aerospace and Electronics Systems, Vol. 36, No. 4,
pagine 1090-1098, 2000
[R43]
Scope Of Work della collaborazione paritaria CIRA-ALENIA su tecnologie e funzionalità
autonome e di ausilio alla missione di velivoli UAS, CIRA-CF-11-0791
[R44]
CIRA-ALN progress meeting a Torino del 2012-03-21, CIRA-VER-12-0145
[R45]
Item 2 – Pianificatore di Missione, E-mail di V. Fiorino (Alenia) del 14/06/2011, CIRAMAI-11-0055
[R46]
Phone conference CIRA-Alenia del 2011-11-17, CIRA-VER-11-77-04
[R47]
Requisiti alto livello per il modulo di Autotaxi, E-mail di P. Galati (Alenia) del
17/11/2011, CIRA-MAI-12-0030
[R48]
TECVOL-II: Autonomous Target Detection and Recognition – Project Requirements,
CIRA-CF-12-0690
[R49]
MISE: Documento di System Requirements –Settembre 2011, CIRA-CF-11-0455
[R50]
Incontro con ENAC del 27-10-2011, Verbale riunione CIRA-VER-11-0471
[R51]
TECVOL Report AR Dimostratore HW/SW delle tecnologie del volo autonomo, CIRACF-11-1361
8
CIRA-CF-12-0600 Rev. 1 P. 8/109
TECVOL-II
TECVOL-II - System Requirements
CIRA-CF-12-0600
1.1 Acronimi
ACAS
ADS
ADS-B
AGL
AHRS
AMF
AR
ASAS
ATC
ATD-R
ATM
ATOL
CAM
CAN
CIRA
COTS
CPA
CR
CS-LSA
DEM
D-GPS
EGNOS
ENAC
EO
EPMS
FAA
FCC
FDI
FLARE
FMECA
FTB
GA
GBAS
GCS
GIS
GNAV
GNC
GNSS
GPS
GPU
HD
HIL
HLR
HMD
HMI
HUD
ICAO
IF
Autonomous Collision Avoidance System
Air Data System
Automatic Dependent Surveillance - Broadcast
Above Ground Level
Attitude and Heading Reference System
Autonomous Mid-air Flight
Acceptance Review
Autonomous Separation Avoidance System
Air Traffic Control
Automatic Target Detection and Recognition
Air traffic Management
Autonomous Take Off and Landing
Cockpit Avionico Manned
Controller Area Network
Centro Italiano Ricerche Aerospaziali
Commercial Off The Shelf
Closest Point of Approach
Concept Review
Certfication Specification - Light Sport Aeroplanes
Digital Elevation Model
Differential GPS
European geostationary navigation overlay system
Ente Nazionale Aviazione Civile
Elettro-Ottico
Electric Power Management System
Federal Aviation Administration
Flight Control Computer
Fault Detection and Identification
Flying Laboratory for Aeronautical REsearch
Failure Mode Effects and Criticality Analysis
Flying Test Bed
General Aviation
Ground Based Augmentation System
Ground Control Station
Geographic Information System
Global NAVigation
Guida, Navigazione e Controllo
Global Navigation Satellite System
Global Positioning System
Graphics Processing Unit
Hardware
Hardware In The Loop
High Level Requirements
Helmet Mounted Display
Human Machine Interface
Head Up Display
International Civil Aviation Organization
Infrared
9
CIRA-CF-12-0600 Rev. 1 P. 9/109
TECVOL-II
IFR
IMA
IMC
IMU
IR
ISTAR
LALT
LATM
LGNC
LRVT
LTSW
MAG
MALE
MOSI
MTOW
MWIR
NBDL
OP
OPA
OTS
PATS
PIC
PMIS
P-RNAV
PRO.R.A.
QR
ROI
RPV
SADA
SBAS
SCAS
SIL
SRR
SUMA
SW
TBD
TCAS
TECVOL
TMA
TRL
UAS
UAV
ULM
VD
VFR
VHF
VLA
VMC
WBDL
TECVOL-II - System Requirements
CIRA-CF-12-0600
Instrument Flight Rules
Integrated Modular Avionic
Instrumental Meteorological Conditions
Inertial Measurement Unit
InfraRed
Intelligence Surveillance Target Acquisition and Reconnaissance
Laser Altimeter
Laboratorio ATM
Laboratorio di Guida, Navigazione e Controllo
Laboratorio Payload, Sensors e HMI
Laboratorio di Softcomputing
Magnetometer
Medium Altitude Long Endurance
Laboratorio di MOdellistica e SImulazione
Maximum Take-Off Weight
Mid-Wavelength InfraRed
Narrow Band Data Link
OPerations
Optionally Piloted Aircraft
Off The Shelf
Personal Air Transportation System
Pilot In Command
Project Management & System Engineering
PRecision area NAVigation
Programma Nazionale di Ricerca Aerospaziale
Qualification Review
Region Of Interest
Remote Piloted Vehicle
Laboratorio Sistemi Embedded e Comunicazione
Satellite-Based Augmentation System
Stability and Control Augmentation System
Software In The Loop
System Requirements Review
Laboratorio Sistemi Meteo e Strumentazione
Software
To Be Defined
Traffic Collision Avoidance System
TECnologie per il VOLo autonomo
Terminal Control Area
Technological Readiness Level
Unmanned Aerial System
Unmanned Aerial Vehicle
Ultra Leggero a Motore
ValiDation
Visual Flight Rules
Very High Frequency
Very Light Aircraft
Visual Meteorological Conditions
Wide Band Data Link
10
CIRA-CF-12-0600 Rev. 1 P. 10/109
TECVOL-II
TECVOL-II - System Requirements
CIRA-CF-12-0600
2 Contesto Generale
La descrizione completa degli obiettivi generali del progetto TECVOL-II e del contesto nell’ambito
del quale essi verranno perseguiti è contenuta nei paragrafi 5.1 e 5.3 di [A1], dove la risposta agli
obiettivi strategici del progetto precedentemente posti è stata sintetizzata nello sviluppo di 4 pillars
tecnologici riguardanti rispettivamente:
1. architetture, algoritmi e dispositivi riguardanti i sistemi autonomi e adattivi per missioni di
velivoli UAV in ambienti non strutturati (e.g. non noti a priori);
2. sistemi per migliorare l’interoperabilità degli UAV in spazi aerei regolati dall’ATM e
sistemi per garantire l’interoperabilità tra stazioni di controllo e velivoli autonomi nella
gestione di operazioni su flotte di UAV;
3. prototipizzazione di sistemi avionici di ausilio al pilota, al fine di incrementare la situational
awareness dello stesso, relativamente al segmento del Personal Air Transportation;
4. metodi, processi e tools per la verifica e la validazione con focus sulla certificazione di
nuovi prototipi avionici sia per velivoli manned che unmanned.
Inoltre (vedi Tabella 2-1), sulla base dei pillars tecnologici sopra definiti, dell’analisi dei sistemi
sviluppati in TECVOL-I e dei feedback degli stakeholders [R3], in [A1] sono state definite le linee
tecnologiche da sviluppare ed il relativo livello di priorità associato.
ID
L1-T1
L1-T2
L1-T3
L1-T4
L1-T5
L1-T6
L1-T7
L1-T8
L2-T1
L2-T2
L2-T3
L2-T4
L2-T5
L3-T1
L3-T2
L3-T3
L4-T1
L4-T2
L4-T4
Tecnologia Proposta
Autonomous Mission Management
Autonomous Taxing
Autonomous Take-off & Post Touchdown
Autonomous 4D Mid-Air Flight
Autonomous Approach & Landing with Adaptive Capabilities
Autonomous Obstacle Collision Avoidance
Autonomous Self-Separation
Autonomous Target Tracking
Adaptive Flight Control Law
Failure & Health Monitoring
On Line Identification
Sensor Management and Navigation
Vision-aided Navigation
Metodi di verifica e qualification kit
Traffic awareness
Atmospheric Situational Awareness
Terrain Situational Awareness
Automatic Target Recognition and detection
SAR-based surveillance
Mission Planner
Augmented Vision
GCS/HMI
Reconfigurable Datalink
Fattibilità datalink per flotta UAV
Power Line Communication
Priorità
Essential
Essential
Essential
Essential
Essential
Essential
Essential
Essential
Desirable
Desirable
Desirable
Essential
Essential
Desirable
Essential
Essential
Essential
Essential
Desirable
Essential
Optional
Essential
Essential
Optional
Optional
Tabella 2-1 – Linee tecnologiche individuate nel documento di ConOps
11
CIRA-CF-12-0600 Rev. 1 P. 11/109
TECVOL-II
TECVOL-II - System Requirements
CIRA-CF-12-0600
In aggiunta a quanto contenuto nel documento [A1], precedentemente richiamato, in questa sede si
forniscono alcuni elementi aggiuntivi riguardanti rispettivamente :
•
la coerenza tra la road map (pillars/linee tecnologiche) delineata in [A1] per il progetto
TECVOL-II e quella seguita in altri programmi di ricerca internazionali con specifico
riferimento alle tecnologie per UAV (§2.1);
•
un’analisi di maggior dettaglio delle motivazioni alla base del terzo pillar riguardante la
prototipizzazione di sistemi avionici di ausilio al pilota per velivoli PATS (§2.2);
•
una descrizione sintetica delle sinergie tra il progetto TECVOL-II ed il progetto MISE
L808/95 [R10] il cui obiettivo è lo sviluppo e validazione in volo su architettura IMA di
applicativi SW per la gestione di velivoli UAV della classe MALE nell’esecuzione di
missioni di sorveglianza (§2.3);
•
una descrizione dello scenario di validazione e verifica di tecnologie e sistemi che, a partire
da quanto già parzialmente descritto nel capitolo 6 di [A1], sarà arricchita con il piano di
utilizzo di tools/facilities in fase di sviluppo nell’ambito di altri progetti gestiti dall’unità
Sistemi, su tutti il progetto MISE finanziato nell’ambito della L808/95 (§2.4);
•
le relazioni esistenti tra i progetti TECVOL-II ed ATM Airpot Lab;
•
un’analisi della Acceptance Review del progetto TECVOL-I con il conseguente impatto
nella attività di sviluppo di TECVOL-II.
2.1 Tecnologie per UAS: coerenza con lo scenario internazionale
Il primo pillar tecnologico identificato nel progetto ha come specifico obiettivo l’innalzamento del
livello di autonomia di bordo degli UAV rispetto alle funzionalità autonome già sviluppate
nell’ambito del progetto TECVOL-I.
L’obiettivo a cui tende il progetto TECVOL-II è quello di raggiungere un’autonomia di livello 3
nella scala definita dalla NATO [R7] (vedi Tabella 2-2), anche se si può prevedere che il velivolo, a
seconda della necessità, possa operare anche con livelli di autonomia inferiore. Oltre a quella
NATO, in letteratura si trovano numerose altre classificazioni del grado di autonomia di un velivolo
unmanned. Di particolare interesse quella fornita dal NIST [R8] che individua i vari fattori che
determinano l’autonomia di un velivolo e ne calcola il peso. Tali fattori sono la complessità della
missione, l’indipendenza dall’operatore umano e la complessità dell’ambiente circostante. In [R8]
una componente della misura dell’indipendenza dall’operatore umano è il cosiddetto livello di
interazione, definito come “the level of authority at which the operator interacts with the UAS” e
che ammette una scala che va (in ordine di autonomia decrescente) dall’assegnare missione,
strategic goals, tactical goals, mission tasks, fino ad assegnare una route, oppure interagire con
l’autopilota o, ancora, pilotare remotamente.
12
CIRA-CF-12-0600 Rev. 1 P. 12/109
TECVOL-II
TECVOL-II - System Requirements
Level
Level Type
1
Remote Controlled System
2
Automated System
3
Autonomous Non-Learning System
4
Autonomous Learning System
CIRA-CF-12-0600
Functionality
System reactions and behaviour(s) depend
on pilot input.
Reactions and behaviour depend on fixed
built-in functionality (pre-programmed).
The system
- can follow well defined procedures
without human support
- is not aware of the objectives
- is not able to tackle unforeseen
situations for which no procedure has
been (or can be) defined.
Behaviour depends upon fixed built-in
functionality or upon a fixed set of rules that
dictate system behaviour (goal-directed
reaction and behaviour).
The system
− is able to define and apply new
procedures, applying general principles
and rules
− is able to define and pursue lower level
objectives, consistent with the higher
level ones.
Has the ability to modify rules and behaviour.
Behaviour depends upon a set of rules that
can be modified for continuously improving
goal directed reactions and behaviours within
an
overarching
set
of
inviolate
rules/behaviours.
Tabella 2-2 - Livelli di autonomia [R7]
Nel considerare le funzioni svolte a bordo che vanno nella direzione di aumentarne l’autonomia
all’interno del progetto si è deciso di interessarsi anche alle funzioni applicative legate al payload
sensoristico il cui utilizzo costituisce, nella maggioranza dei casi, lo scopo primario di una missione
UAV. Aumentare il livello di automazione delle funzionalità del payload consente l’accrescimento
dell’autonomia e della capacità decisionale dell’intero sistema velivolo, soprattutto se la guida può
risultare in alcune fasi asservita alle indicazioni delle funzioni applicative di missione. La messa a
punto di tecnologie applicative di missione nel progetto, soprattutto legate a funzioni di visione
artificiale collegata al payload sensoristico di imaging, consente di completare il quadro dell’offerta
del CIRA sull’aumento di autonomia di missione di velivoli unmanned anche in quadro prospettico
di utilizzo di flotte di velivoli cooperanti per un comune, complesso obiettivo di missione.
A conferma di quanto sopra descritto a proposito dell’incremento del livello di autonomia, si cita il
recente documento del DoD degli Stati Uniti [R2] nel quale si presenta una roadmap per lo
sviluppo dei sistemi unmanned fino al 2036. In esso l’incremento del livello di autonomia è
appunto uno dei 7 obiettivi strategici individuati e viene essenzialmente motivato nei termini di
to reduce the manpower burden and reliance on full-time high-speed communications links while
also reducing decision loop cycle time.
Una delle criticità per il raggiungimento degli obiettivi in termini di incremento del livello di
autonomia abbondantemente descritto in [R2] riguarda proprio
13
CIRA-CF-12-0600 Rev. 1 P. 13/109
TECVOL-II
TECVOL-II - System Requirements
CIRA-CF-12-0600
The ability to Understand and Adapt to the Environment, …. to operate in complex and uncertain
environments, the autonomous system must be able to sense and understand the environment. This
capability implies that the autonomous system must be able to create a model of its surrounding
world by conducting multisensor data fusion (MDF) and converting these data into meaningful
information that supports a variety of decision-making processes.
Con specifico riferimento all’analisi e trattamento dei dati dei sensori nel documento citato è
chiaramente evidenziato che uno degli approcci fondamentalì da perseguire è appunto quello di
minimizzare la richiesta di banda ai sistemi di data-link attraverso una sempre maggiore
concentrazione a bordo di capacità di sensor fusion.
Un ulteriore elemento di congruenza del progetto TECVOL-II con la roadmap di cui al documento
[R2], riguarda il fatto che in entrambi i casi uno dei challenge fondamentali per il raggiungimento
dell’obiettivo posto in termini di incremento del livello di autonomia, consiste in
The Development of new Verification and Validation (V&V) and Testing & Evaluation techniques
to enable verifiable “trust” in autonomy.
In linea con gli obiettivi di cui al quarto pillar tecnologico del progetto, in [R2] si evidenzia tra
l’altro che:
To ensure the safety and reliability of autonomous systems and to fully realize the benefits of these
systems, new approaches to V&V are required. Today’s V&V processes will be severely stressed
due to the growth in the amount and complexity of software to be evaluated. They utilize existing
industry standards for software certification that are in place for manned systems (e.g., DO-178B).
Without new V&V processes, such as the use of trust audit trails for autonomy, the result will be
either extreme cost growth or limitations on fielded capabilities.
In conclusione, in Figura 2-1 sono opportunamente evidenziati i principali punti di contatto tra la
roadmap identificata in [R2] e gli obiettivi del progetto TECVOL-II.
Figura 2-1 - Unmanned Systems Integrated Roadmap FY2011-2036 by DoD USA (Autonomy) [R2]
In riferimento al secondo pillar tecnologico identificato nel progetto, aspetto fondamentale sarà
quello riguardante l’effettivo inserimento degli UAV nel traffico ATM. Un punto fermo su tale
problematica per il prossimo futuro, come sancisce la circolare ICAO 328 [R4] sui sistemi
unmanned, contempla tale evenienza solo per gli RPV (Remotely Piloted Vehicle), per i quali a
14
CIRA-CF-12-0600 Rev. 1 P. 14/109
TECVOL-II
TECVOL-II - System Requirements
CIRA-CF-12-0600
garantire il controllo del velivolo sarà sempre il pilota remoto. Ciò comporta che l’interazione tra
UAV ed ATM resta un task del pilota remoto ed il set di messaggi scambiati con l’ATM può restare
pressoché identico a quello attuale, sebbene particolarità tipiche dei sistemi UAV possano andare ad
incidere sulla modalità di scambio messaggi (possibile ritardo nelle comunicazioni), sui possibili
report che il pilota può fornire (il pilota non è in grado di fornire, se non tramite l’ausilio di sensori,
informazioni circa le condizioni meteo presenti sul velivolo o eventuale traffico in vista),
sull’efficacia delle istruzioni di separazione date dall’ATM in caso di caduta del data link.
A tale proposito si evidenzia in [R2] come una possibile soluzione a tail problemi possa risiedere
nel generale incremento del livello di autonomia a bordo di cui al primo pillar. Infatti è possibile
immaginare condizioni operative che prevedono che i messaggi provenienti dall’ATM arrivino sia
al pilota nella GCS che alla piattaforma UAV, e che questa possa decidere la strategia di reazione
autonomamente lasciando al pilota remoto solo il compito di approvare la strategia decisa. Questo
tipo di soluzione potrebbe in qualche modo ovviare ai vincoli regolamentari imposti dall’ICAO
diminuendo entro i limiti consentiti la latenza tra istruzione proveniente dall’ATM ed esecuzione
della stessa, almeno nelle condizioni di rotta.
La velocità di reazione del velivolo unmanned ad eventuali istruzioni ATM è molto critica
soprattutto nelle fasi terminali del volo. Ecco perché, nelle previsioni a medio termine del gruppo
EUROCAE WG 73, per l’inserzione degli UAV in spazi aerei non segregati, si immagina che,
almeno inizialmente, gli aeroporti utilizzati continuino ad essere esclusivamente dedicati a questo
tipo di traffico [R5]. A questo proposito la Tabella 2-3, riportata in [R5], può essere anche utile a
definire le possibili missioni in ambito civile di un UAV.
Tabella 2-3 - Spazi aerei e missioni per UAV [R5]
15
CIRA-CF-12-0600 Rev. 1 P. 15/109
TECVOL-II
TECVOL-II - System Requirements
CIRA-CF-12-0600
Anche nel progetto INOUI, nel D1.2 [R6], vengono elencati i tipi di missione, ad esempio missioni
cargo e di station keeping, ma le missioni più numerose sono quelle di sorveglianza e osservazione.
Le missioni di sorveglianza sono da annoverare tra quelle più comunemente svolte da UAV per
finalità di monitoraggio ambientale, di sicurezza sociale e sorveglianza militare, a scopo soprattutto
preventivo, e vi si riferisce comunemente con l’acronimo ISTAR (Intelligence, Surveillance, Target
Acquisition and Reconnaissance).
Nella selezione delle missioni di riferimento per il progetto si terrà conto di precisi requisiti sul
velivolo, come, ad esempio, peso, durata e altitudini (come mostrato in Tabella 2-4) ed in
particolare, si farà riferimento ad un velivolo di tipo MALE (Medium-Altitude Long-Endurance).
Le caratteristiche di questo tipo di velivolo sono un’altitudine compresa tra i 10,000 e i 30,000 piedi
e missioni della durata tipicamente di 24-48 ore.
Tabella 2-4 - Esempi di requisiti per alcune missioni [R6]
Per ultimo si evidenzia che, le questioni sia tecnologiche che normative relative all’integrazione
degli UAV all’interno del sistema di gestione del traffico aereo sono riconosciute come centrali
anche nell’ambito della già citata roadmap del DoD USA [R2]. In tale sede, uno degli obiettivi
strategici perseguiti, è appunto quello dell’UAS Airspace Integration, nell’ambito del quale si
afferma che:
is vital for the Department of Defense and the Federal Aviation Administration to collaborate
closely to achieve progress in gaining access for unmanned aerial systems to the National Airspace
System to support military and civil requirements.
In particolare,
DoD’s vision is to ensure UAS have routine access to the appropriate airspace required to meet
mission needs. For military operations, UAS will operate with manned aircraft using CONOPS that
make manned or unmanned aircraft distinctions transparent to air traffic services (ATS) authorities
and airspace regulators.
16
CIRA-CF-12-0600 Rev. 1 P. 16/109
TECVOL-II
TECVOL-II - System Requirements
CIRA-CF-12-0600
Come esempio, nella Figura 2-2 sono mostrati i sei possibili scenari di integrazione degli UAS nello
spazio aereo commerciale di cui alla visione presentata in [R2].
Figura 2-2 - UAS Airspace Integration – USA DoD Operational View [R2]
Nello specifico i punti di contatto tra la road-map presentata in [R2] con riferimento alla
problematica di UAS Airpsace Integration, ed il progetto TECVOL-II sono sintetizzati in Figura
2-3. Da essa si evince che l’impegno previsto nell’ambito del progetto TECVOL-II è
essenzialmente orientato allo sviluppo di sistemi di airborne sense & avoid e self-separation.
Figura 2-3 - Unmanned Systems Integrated Roadmap FY2011-2036 by DoD USA (Airspace Integration) [R2]
Infine in Figura 2-4 sono indicati i punti in comune tra [R2] e TECVOL-II nell’ambito della ricerca
e sviluppo di datalink innovativi.
17
CIRA-CF-12-0600 Rev. 1 P. 17/109
TECVOL-II
TECVOL-II - System Requirements
CIRA-CF-12-0600
Figura 2-4 - Unmanned Systems Integrated Roadmap FY2011-2036 by DoD USA (Communications) [R2]
2.2 Sistemi avionici di ausilio al pilotaggio di velivoli PATS:
Motivazioni
La motivazione alla base della scelta di dedicare risorse significative nell’ambito del progetto in
questione alla prototipizzazione di sistemi avionici avanzati per velivoli di piccole dimensioni per il
trasporto personale (PATS - Personal Air Transportation System) si basa in prima istanza sulle
risultanze di diverse attività di indagine a livello Nazionale ed Europeo condotte nel recente
passato, che in maniera concorde evidenziano le potenzialità di sviluppo del settore dei velivoli per
il trasporto personale (VLA, GA, Elicotteri) previsto per il prossimo decennio. In particolare (vedi
Figura 2-5 - progetto EPSON) i documenti [R12] [R13] hanno evidenziato che i paesi dell’area
mediterranea presentano un indice di mobilità medio-basso. Per l’Italia, in particolare, questo è
accentuato nelle aree meridionali.
Figura 2-5 - Progetto EPSON Indice di mobilità in Europa. Dati al 2004
Osservando quanto fatto in altri paesi Europei, l’opportunità di avere una moderna infrastruttura
aerea, agevolerebbe lo sviluppo di nuove tipologie di traffico (non solo privato), in grado di
18
CIRA-CF-12-0600 Rev. 1 P. 18/109
TECVOL-II
TECVOL-II - System Requirements
CIRA-CF-12-0600
proporre una valida alternativa alla mobilità su ruote e su acqua. A costi contenuti e nel rispetto dei
vincoli di sicurezza, potrebbe essere sviluppato un collegamento alternativo, basato sul trasporto
aereo personale, che permetta il superamento di barriere naturali, quali le dorsali montane, o
l’attraversamento di tratti di mare, etc., in tempi ridotti e che contribuisca alla continuità
continentale con le isole. In Europa ed in Italia sussistono, quindi, condizioni particolarmente
benevole per lo sviluppo del trasporto aereo personale, come si evince in Figura 2-6, dove è
riportata una stima della futura domanda di traffico aereo personale [R12]: le tratte in colore rosso
sono quelle ad elevata richiesta di mobilità e quindi le più favorevoli per il futuro sviluppo di
traffico aereo personale. Dal grafico emerge chiaramente che le regioni del sud Europa, Italia in
particolare, sono quelle in cui si stima una domanda maggiore e quindi un mercato potenzialmente
interessante.
Figura 2-6 - Indice della domanda di traffico aereo personale in Europa
Le previsioni descritte sono applicabili anche laddove la definizione di PATS venga allargata fino
ad includere velivoli a decollo verticale in quanto l’elicottero, per le sue peculiari caratteristiche
operative, trova applicabilità tipicamente nel trasporto cosiddetto point-to-point, un tipo di trasporto
cioè, privato o commerciale, schedulato o non-schedulato, che consenta decollo ed atterraggio nelle
immediate prossimità di effettiva partenza e di destinazione conclusiva del viaggio stesso.
Al fine di trovare ulteriori riscontri, oltre quelli di cui sopra, nel corso del 2011, con il supporto di
una ditta esterna è stata condotta una indagine volta a stimare il mercato potenziale dei sistemi
avionici di guida, navigazione e controllo per velivoli della classe PATS. Le conclusioni di tale
indagine [R14] hanno evidenziato, in sintesi:
• un mercato per il trasporto aereo personale, che a livello Europeo, raddoppierà i propri
volumi entro il 2020, di fatto confermando i risultati degli studi precedentemente citati;
19
CIRA-CF-12-0600 Rev. 1 P. 19/109
TECVOL-II
TECVOL-II - System Requirements
CIRA-CF-12-0600
• la richiesta da parte degli operatori (piloti, società di gestione) di velivoli dotati di sistemi
avionici avanzati a basso costo capaci di ridurre il workload del pilota ed aumentare il
livello di safety complessiva nella gestione della missione di volo;
• la notevole vitalità del comparto industriale Nazionale, nell’ambito del quale sono stati
censiti 59 aziende che producono e/o manutengono velivoli della classe PATS, e 24 aziende
che producono sistemi e/o componenti avionici per tale classi di velivoli.
2.3 Sinergia con il progetto MISE L808/95
In accordo con quanto previsto dal Piano Triennale vigente [R1], il progetto TECVOL-II, oggetto
del presente documento, verrà condotto in maniera da garantire la massima sinergia con il progetto
MISE, finanziato nell’ambito della legge 808/95 e finalizzato alla realizzazione di applicativi SW di
bordo per la gestione di UAS della classe MALE nell’esecuzione di missioni di sorveglianza.
Cosi come definito in dettaglio in [R10], i due progetti, che insieme rappresentano oltre il 60% dei
ricavi complessivi dell’unità Sistemi del CIRA per il prossimo triennio, sono organizzati in modo
tale da evitare duplicazioni di attività e mettendo a fattore comune i risultati conseguiti.
Nello specifico il progetto MISE ha come obiettivo fondamentale la sistematizzazione delle
tecnologie di volo autonomo per velivoli UAS già dimostrate durante il precedente progetto
TECVOL-I, con l’obiettivo di favorirne il trasferimento verso l’azienda nazionale di riferimento,
nel caso specifico Alenia Aermacchi anch’essa coinvolta con analogo progetto nell’ambito dei
finanziamenti L808/95. Per tale motivo, in ambito MISE, particolare cura verrà dedicata alla
sistematizzazione del processo di progetto degli applicativi SW in accordo con le linee guida della
DO178B/C, ed allo sviluppo di tools/facilities per la verifica e validazione degli applicativi SW
oggetto del progetto.
Viceversa il progetto TECVOL-II si concentrerà, da una parte, sulla messa a punto di tecnologie e
sistemi avionici per UAS altamente innovativi e funzionali al raggiungimento di un livello di
autonomia superiore rispetto a quello raggiunto nell’ambito del progetto TECVOL-I (vedi par. 2.1),
dall’altra alla prototipizzazione di sistemi avionici avanzati per velivoli manned della classe PATS
in accordo con quanto descritto nel paragrafo 2.2.
Per quanto riguarda inoltre la messa a fattor comune dei risultati conseguiti nell’ambito dei due
progetti, ciò verrà nella sostanza implementato attraverso l’utilizzo in ambito TECVOL-II, previa
opportuna customizzazione ed adattamento, dei tools e facilities di verifica e validazione di SW
safety critical sviluppati e messi a punto nell’ambito del progetto MISE.
Come descritto in maggior dettaglio nel §4, in fase di pianificazione dei due progetti [R10], è stata
individuata una road-map di sviluppo di tecnologie del volo autonomo di velivoli UAV e sistemi
avionici avanzati di ausilio al pilotaggio dei velivoli manned di piccole dimensione, comune tra i
due progetti per il periodo 2012-2016.
2.4 Tools/Facilities di verifica e validazione
Di seguito si intendono descrivere in maniera sintetica i tools e le facilities che verranno utilizzate
per supportare il processo di verifica e validazione delle tecnologie e dei sistemi di cui al presente
progetto, durante l’intero ciclo di sviluppo. A tale proposito rimandando al documento di Conops
per i dettagli [A1], in questa sede si ricorda che l’approccio scelto prevede che le fasi iniziali del
20
CIRA-CF-12-0600 Rev. 1 P. 20/109
TECVOL-II
TECVOL-II - System Requirements
CIRA-CF-12-0600
progetto seguono l’approccio a “V” fino alla definizione dei requisiti di sistema allocati ai diversi
sottosistemi (linee tecnologiche di progetto individuate). Le successive fasi di sviluppo (analisi,
design, implementazione, testing, generazione prototipo e relativa review di accettazione) sono
iterative e sono svolte per ogni ciclo di spirale, o iterazione, dove in ciascuna di esse si persegue
l’obiettivo di costruire, in modo progressivo, nuove porzioni (prototipo o build) del sistema, via via
integrate con le precedenti, di verificarle e validarle, riducendo fin dall’inizio i rischi tecnici di
progetto. A premessa si evidenzia che tutte i tools/facilities di seguito descritte, saranno sviluppate
adattando opportunamente ed integrando quanto previsto nell’ambito del progetto MISE L808/95 in
accordo con l’obiettivo strategico di evitare duplicazioni e massimizzare la sinergia tra i due
progetti (vedi par. 2.3).
Nello specifico i tools/facilities di verifica e validazione che verranno utilizzati sono di seguito
descritti evidenziandone per ciascuno di essi la fase di applicabilità:
• Desktop Simulators: si tratta di ambienti di simulazione off-line che verranno utilizzati
rispettivamente nella fase di analisi, per la verifica degli HLR (Functional Simulator) e
nella fase di design per la verifica dei Low Level Specifications (Engineering Simulator) sia
per le applicazioni UAV che per quelle dedicate ai velivoli manned di piccole dimensioni.
• SIL IMA: si tratta di un ambiente di simulazione real-time, basato su tecnologia IMAARINC653 che verrà utilizzato a supporto della fase di implementazione dei soli moduli
SW per applicazioni UAV, con l’obiettivo di verificare la correttezza del processo di rapidprototyping utilizzato per la generazione del codice SW real-time a partire dai LLS e relativa
implementazione sul sistema real-time target di tipo IMA.
• HIL IMA: si tratta di una facility per la simulazione real-time HW in the loop che verrà
utilizzata nella fase di testing a terra degli applicativi SW per UAV. A differenza del SIL,
in questo caso, oltre alle opportune verifiche funzionali verranno completate anche i test di
integrazione fisica con gli altri sottosistemi che si interfacciano con il prototipo sviluppato.
• Cockpit Avionico Manned: si tratta di una facility per la simulazione real-time HW e pilot
in the loop utilizzata nella fase di testing a terra dei prototipi di sistemi avionici a supporto
del pilotaggio dei velivoli per il trasporto personale. In particolare esso verrà utilizzato per
verificare/dimostrare in ambiente rappresentativo applicazioni proprietarie CIRA per la
classe di velivoli considerati ivi incluse HMI innovative orientate ad incrementare la
“situational awareness”. La facility includerà anche una piattaforma HW real-time specifica
per la prototipizzazione degli applicativi SW real-time che utilizzerà una tecnologia standard
non IMA.
• FLAREII: costituito da un velivolo della classe CS-LSA (MTOW 600 Kg) equipaggiato
opportunamente e gestito in modo da essere compliant con la configurazione operativa
definita in [R15] con il nome di “Optionally Piloted Aircraft” (OPA)1. La peculiarità della
piattaforma FLARE II, rispetto alla piattaforma FLARE già disponibile in quanto realizzata
nell’ambito del progetto TECVOL-I e che comunque verrà utilizzata almeno fino a tutto il
2013, riguarda il fatto che essa verrà equipaggiata con un sistema EFIS riconfigurabile
1
OPA Operating Limitations ; The aircraft will be operated with a pilot onboard at all times having the ability to
immediately override any installed system that can be operated remotely or by automation.
21
CIRA-CF-12-0600 Rev. 1 P. 21/109
TECVOL-II
TECVOL-II - System Requirements
CIRA-CF-12-0600
consentendo in tal modo la validazione in volo di sistemi di ausilio al pilotaggio di velivoli
manned per il trasporto personale. Ovviamente, grazie alla flessibilità operativa garantita dal
concetto operativo OPA potrà essere pienamente utilizzata, cosi come la piattaforma
FLARE già esistente, anche per la validazione in volo delle tecnologie del volo autonomo
per UAV.
Per ultimo, si evidenzia che le facilities/tools di cui sopra sono complementati da una serie di
moduli SW (Complex Systems Real-Time Simulator) per la simulazione real-time del contesto
operativo/funzionale nell’ambito del quale operano gli applicativi/sistemi per il volo autonomo
degli UAV e per il supporto al pilotaggio dei velivoli manned di piccole dimensioni da verificare e
validare. Tali moduli di simulazione, che si integreranno secondo le necessità con i tools/facilities di
terra sopra descritti (SIL IMA, HIL IMA Cockpit Avionico Manned) per soddisfare a pieno i
requisiti di verifica e validazione del progetto, esibiranno le seguenti caratteristiche peculiari:
• disponibilità in diverse versioni ciascuna opportunamente configurata per garantirne la
corretta integrazione nell’ambito di ciascuno dei tools/facilities di terra sopra descritti. In
particolare saranno disponibili versioni con livelli di dettaglio diversi in termini di ipotesi di
modellistica, opportunamente tarati con gli obiettivi dello specifico test di verifica e
validazione
• architettura funzionale caratterizzata da elevata modularità e interoperabilità [R16], sia tra i
diversi moduli sia con simulatori disponibili c/o enti esterni (Università, PMI, Grandi
Aziende) che collaborano con il CIRA sul progetto in questione. L’obiettivo ultimo è quello
di consentire la simulazione di sistemi e scenari dai più semplici ai più complessi
caratterizzati ad esempio dall’interazione di simulatori di uno o più velivoli manned/manned
con piloti nel loop inseriti in uno scenario di traffico il più realistico possibile.
• nello specifico saranno presenti moduli per la simulazione di
o Piattaforme Aeree (simulatori di aerial e space vehicles, manned ed unmanned),
o Piattaforme di Terra (es. ATM/ATC emulators, stazioni di servizio a supporto della
navigazione, ecc.),
o Piattaforme Satellitari (es. satelliti della rete GPS, della rete EGNOS,
metereologici),
o Scenari (es. traffico aereo, Aree Segregate, Aree Interdette al Volo, posizioni dei
Navigation Aids, meteo hazards, veicoli/target a terra).
Nella seguente figura si sintetizzano schematicamente quali sono i tools/facilities di verifica e
validazione sopra descritti e che verranno utilizzati nelle diversi fasi del ciclo di progetto adottato.
22
CIRA-CF-12-0600 Rev. 1 P. 22/109
TECVOL-II
TECVOL-II - System Requirements
CIRA-CF-12-0600
Figura 2-7 - Tools/Facilities di verifica e validazione
Per ultimo si intende evidenziare che, l’approccio alla verifica e validazione delle tecnologie del
volo autonomo per UAV sopra descritto, potrebbe essere ulteriormente arricchito, laddove
compatibile con tempi e costi disponibili, con una ulteriore attività di dimostrazione in volo
utilizzando la piattaforma unmanned X-MALE oggetto di un analogo progetto PRORA condotto
dall’unità Velivoli del CIRA [R17][R18]. A tale proposito si osserva in maniera esplicita che tali
attività di dimostrazione in volo sono da considerarsi ad ogni modo addizionali rispetto a quelle
previste in ambito TECVOL-II utilizzando la piattaforma FLARE-II. Quanto detto è motivato sia
perché FLARE-II è l’unica che consente di validare in volo i sistemi avionici di ausilio al pilotaggio
dei velivoli manned di piccole dimensioni, sia perché un’attività preliminare di prova in volo con un
velivolo Optionally Piloted come FLARE-II delle tecnologie di volo autonomo per UAS è
comunque necessaria per ridurre i rischi legati alla sperimentazione direttamente su una piattaforma
unmanned come X-MALE. Ad ogni modo, nella sua versione attuale, il budget allocato per il
progetto TECVOL-II non prevede nessuna risorsa dedicata alle attività di porting e dimostrazione in
volo su X-MALE delle tecnologie per il volo autonomo sviluppate in ambito TECVOL-II.
2.5 Relazione tra TECVOLII ed ATM Airpot Lab
Il Progetto TECVOL-II è stato definito assumendo che le attività di sperimentazione in volo
necessitino esclusivamente delle infrastrutture sperimentali di cui alle piattaforme volanti FLARE
(già disponibile) e FLARE II (pianificata). Viceversa TECVOL-II è stato definito supponendo non
ancora disponibile la facility ATM Airport Lab, ad oggi oggetto solo di uno studio di fattibilità di
fase 0 la cui realizzazione però non è stata ancora deliberata. Si evidenzia in particolare che le
attività volative sia di FLARE che di FLARE II, a partire dal 2013 verranno comunque svolte
dall'Aeroporto Oreste Salomone di Capua indipendentemente dalla realizzazione ed integrazione in
esso delle infrastrutture sperimentali previste per l'ATM airport Lab. Ad ogni modo il progetto
23
CIRA-CF-12-0600 Rev. 1 P. 23/109
TECVOL-II
TECVOL-II - System Requirements
CIRA-CF-12-0600
TECVOL-II beneficierà dell'eventuale realizzazione del ATM Airport Lab essenzialmente
consentendo una migliore efficienza nella gestione delle prove di validazione in volo previste.
2.6 Analisi della Acceptance Review del progetto TECVOL-I
Nell’Acceptance Review del progetto TECVOL-I le decisioni dell'autorità decisionale hanno in
alcuni casi demandato al progetto TECVOL-II la piena risposta alla RIDs. In particolare in risposta
alle RID 12 e 32 di si è suggerito di verificare in ambito del progetto TECVOL-II le prestazioni al
touch down della funzionalità di Autolanding relative alla dinamica del pitch e le prestazioni del
modulo di envelope protection durante le fasi di mid air. Tale verifiche saranno portate in conto dal
piano di validazione del sistema di autolanding specificato nel §3.2.1.3.
Nelle RID 54, 56 e 77 di [R51] invece si è suggerito di portare in conto nel progetto le normative
EASA CS-23 e STANAG4671 (USAR.1329) in particolar modo per armonizzare le definizione dei
livelli di autonomia raggiunti. I livelli di autonomia previsti all’interno del progetto TECVOL-II
sono stati chiariti nel §2.1 utilizzando [R7] come specifico riferimento nella definizione dei suddetti
livelli. Al contesto normativo nel quale inquadrare il progetto è stato invece dedicato il capitolo 9 di
[A1].
Infine nelle rispote alle RIDs 55, 63, 73 e 84 di [R51] si è suggerito un upgrade della funzionalità di
Autonomous Collision Avoidance sviluppate in TECVOL-I portando in conto le regole dell'aria e
possibili forme ellissoidali della safety bubble e si suggerito di garantire la consistenza tra le due
sorgenti di dati utilizzate FDR (Flight Data Recorder) e GDR (Ground Data Recorder). Il primo
suggerimento è stato interamente recepito attraverso la definizione dei requisiti relativi al Traffic &
Obstacle Avoidance System (TOAS) specificato nel §3.4.2.3 mentre il secondo suggerimento sarà
portato in conto nelle future attività di validazione svolte con il dimostratore FLARE e
successviamente con FLARE-II.
24
CIRA-CF-12-0600 Rev. 1 P. 24/109
TECVOL-II
TECVOL-II - System Requirements
CIRA-CF-12-0600
3 Requisiti funzionali
I requisiti saranno prima divisi in tre grandi categorie: Tecnologie di volo autonomo TECVOL-I (§3.2), Tecnologie di volo autonomo per UAV
(§3.3) e Sistemi avanzati di ausilio al pilotaggio per velivoli manned (§3.4). In ognuna di queste categorie sono state individuate diverse classi di
tecnologie e/o sistemi (identificate nel documento dai paragrafi di terzo livello del presente capitolo, a partire dal §3.3.1) ed, infine, per ogni classe è
stata individuata la specifica tecnologia e/o sistema da specificare attraverso i requisiti di progetto (identificati dai paragrafi di quarto livello del
presente capitolo, a partire dal §3.2.1.1).
3.1 Introduzione alla lettura dei requisiti
Il ciclo di sviluppo dei sistemi SW/HW legati al progetto TECVOL-II saraà definito utilizzando uno schema di classificazione ispirato agli standard
di produzione di sistemi avionici utilizzati in ambito aeronautico: RTCA/DO-178B per quanto riguarda i requisiti software ed IEEE Std 1233 1998
Ed. per lo sviluppo dei requisiti di un sistema.
Il presente documento si prefigge di definire i requisiti di progetto che nel classico ciclo di sviluppo preso a riferimento sono assimilabili ai requisiti
utente per uno specifico sistema. I requisiti di progetto identificheranno delle particolari tecnologie e dei particolari sistemi da sviluppare. Per ogni
tecnologia e/o sistemi dovranno essere di seguito nel corso del progetto definiti dei requisiti di sistema. Per alcune delle tecnologie e/o sistemi
individuati sono già disponibili dei requisiti di sistema che saranno opportunamente referenziati.
In ogni paragrafo relativo ad un dato sistema saranno presenti i seguenti sottoparagrafi: descrizione sintetica del sistema, giustificazione della scelta
di sviluppare il dato sistema, metodo di verifica finale sulla base di quando definito nella seguente tabella ed infine i requisiti di progetto veri e
propri.
Sigla
VM_Demonstration (HIL)
VM_Demonstration (CAM)
VM_Flight_Validation (FLARE)
Descrizione
Dimostrazione di quanto specificato nella
facility real time per simulazioni HW-In-theLoop (cfr. HIL-IMA definiti nel §2.4)
Dimostrazione di quanto specificato nella
facility replicante un Cockpit Avionico Manned
(cfr. CAM definito nel §2.4)
Validazione in volo di quanto specificato sulla
25
CIRA-CF-12-0600 Rev. 1 P. 25/109
TECVOL-II
TECVOL-II - System Requirements
VM_Flight_Validation (FLARE II)
CIRA-CF-12-0600
piattaforma volante FLARE
Validazione in volo di quanto specificato sulla
piattaforma volante FLARE II (cfr. FLARE-II
definiti nel §2.4)
Tabella 3-1 – Metodi di verifica applicabili alle tecnologie/sistemi sviluppati nel progetto
I metodi di verifica associati ad ogni sistema andranno anche a definire implicitamente il livello di maturità tecnologica che è previsto raggiungere
nel corso dell’attuale progetto per quello specifico sistema.
Di seguito il codice con il quale saranno definiti gli identificativi rappresentativi di ogni requisito.
Tutti i requisiti di progetto utilizzeranno un codice univoco composto nel seguente modo:
• il prefisso TECV2-SUBS-;
• un codice alfanumerico di 4 caratteri identificante il nome del sottosistema e/o tecnologia individuato/a (ad es. “NAME”);
• un numero di 5 cifre indicante il progressivo unico del requisito (con incrementi nominali di 10);
• un suffisso di 4 caratteri alfanumerici che identifica la versione del requisito (ad esempio “_0.0”):
Un identificativo tipico di un requisito di progetto potrebbe essere: TECV2-SUBS-NAME-00010_0.0
I campi previsti nella definizione dei requisiti saranno: identificativo, titolo, descrizione, rational (applicabile solo se non già implicitamente
contenuto nel sottoparagrafo di giustificazione relativo all’intero sistema).
26
CIRA-CF-12-0600 Rev. 1 P. 26/109
TECVOL-II
TECVOL-II - System Requirements
CIRA-CF-12-0600
3.2 Tecnologie di volo autonomo per UAV (da TECVOL-I)
In questa categoria sono raggruppati i requisiti relativi alla validazione in volo sulla piattaforma volante FLARE di tecnologie già parzialmente
sviluppate nel progetto TECVOL-I. Una sistematizzazione dei requisiti relativi alle suddette tecnologie è in corso d’opera nel documento [R25] la
cui emissione è prevista per Giugno 2012. I deliverable TECVOL-I da cui sono tratti i sopra citati requisiti sono [R26], [R27], [R28], [R31] e [R32].
3.2.1.1
Autonomous Collision Avoidance Multisensor based (ACAM)
3.2.1.1.1 Descrizione sintetica del sistema
Il sistema per l’Autonomous Collision Avoidance (ACA) Multisensor based (di seguito sinteticamente indicata con l’acronimo ACAM) ha come
obiettivo l’avoidance di ostacoli mobili non cooperativi la cui posizione è stimata attraverso una stima ottima dei dati provenienti da più sensori di
detection. A tale sistema è associato l’identificativo S01.
3.2.1.1.2 Giustificazione
Una sintetica descrizione dei risultati ottenuti in TECVOL-I con riferimento alla funzionalità ACA è riportata nel documento ConOps TECVOL-II
[A1], nella sezione 3.3.3, mentre una descrizione completa è riportata nel documento di riferimento [R26]. Il sistema ACAM costituisce un followup rispetto a quanto già implementato in TECVOL-I, laddove è stato portato a livello di sviluppo tecnologico TRL 6 un sistema ACA basato
essenzialmente sull’impiego del radar come sensore principale di obstacle detection (come indicato in [A1] e nella sezione 3.4.1.2 del presente
documento).
L’obiettivo principale da raggiungere in TECVOL-II per quanto riguarda il sistema ACAM, in qualità di follow-up delle attività TECVOL-I, è
quello di sviluppare ulteriormente la tecnologia ereditata da TECVOL-I andando ad effettuare la manovra ACA basandosi non più sul solo radar
come sensore di detection ma anche sui sensori elettro-ottici (EO), operanti in particolare nel visibile (VIS) e nell’infrarosso (IR). Anche per il
sistema ACAM si prevede in TECVOL-II uno sviluppo fino a TRL 6. In questo senso rispetto ai requisiti già definiti in [R26] viene aggiunto nel
presente documento un solo requisito che esprima l’obiettivo suddetto.
Come evidente, il sistema ACAM implementa miglioramenti rispetto a TECVOL-I solo in termini di sensoristica impiegata per la detection, mentre
tutti gli upgrade in termini di algoritmi di avoidance saranno integrati in TECVOL-II nell’ambito del Traffic and Obstacle Avoidance System (cfr.
sezione 3.4.2.3). La linea tecnologia di riferimento individuata in [A1] è la L1-T2 relativa all’esecuzione autonoma della missione ed, in particolare,
all’ Automatic Collision Avoidance.
27
CIRA-CF-12-0600 Rev. 1 P. 27/109
TECVOL-II
TECVOL-II - System Requirements
CIRA-CF-12-0600
3.2.1.1.3 Metodo di verifica
VM_Flight_Validation (FLARE)
3.2.1.1.4 Requisiti di progetto
ID
Titolo
TECV2SUBS ACAM 00010_0.0
Funzionalità
dell'ACAM
module
3.2.1.2
Descrizione
Rationale
La funzionalità di Autonomous Collision Avoidance
Il modulo ACAM dovrà essere in grado di eseguire manovre di
rimane la medesima sviluppata in TECVOL-I,
autonomous collision avoidance basandosi sui dati provenienti da
mentre ciò che viene migliorato rispetto a TECVOL-I
una suite di sensori comprendente sensori radar ed elettro-ottici (VIS
è la suite di sensori e la relativa data fusion, a
e IR).
supporto dell'obstacle detection and tracking.
Automatic Take Off (ATOF)
La tecnologia di Automatic Take Off si propone di rendere automatica anche la fase di take off di una tipica missione UAV. Tale tecnologia è stata
già sviluppata nel progetto TECVOL-I e per la descrizione del relativo sviluppo e testing in laboratorio con simulazioni real time HW-In-The-Loop
si faccia riferimento a [R32] nel quale sono definiti anche i relativi requisiti di sistema. La validazione in volo degli algoritmi sviluppati sarà portata
a termine nell’ambito del progetto TECVOL-II attraverso la piattaforma volante FLARE entro il mese di Settembre 2012. La linea tecnologia di
riferimento individuata in [A1] è la L1-T2 relativa all’esecuzione autonoma della missione ed, in particolare, all’ Automatic Take Off. A tale
sistema è associato l’identificativo S02.
3.2.1.3
Autolanding EGNOS&Visual-based (ALEV)
3.2.1.3.1 Descrizione sintetica del sistema
Nella presente sezione sono descritti, sotto forma di appositi requisiti, gli obiettivi che si intende raggiungere attraverso lo sviluppo, in ambito
TECVOL-II, di un sistema che assolva alla funzione di autolanding con l’ausilio di algoritmi di navigazione basati su una fusion delle informazioni
fornite principalmente da un sistema satellitare SBAS (quale quello EGNOS) ed un set di sensori elettroottici / infrarossi. Il sistema di Autolanding
EGNOS&Visual based sarà di seguito identificato dalla sigla ALEV. A tale sistema è associato l’identificativo S03.
28
CIRA-CF-12-0600 Rev. 1 P. 28/109
TECVOL-II
TECVOL-II - System Requirements
CIRA-CF-12-0600
3.2.1.3.2 Giustificazione
I requisiti di tecnologie relative all’Autolanding EGNOS&Visual-based sono stati definiti mediante un’analisi delle change AL-C6 , AL-C12
definite nel §4 di [A1] ed in generale delle tecnologie L1-T2, L1-T6 ed L1-T7 (vedi Tabella 2-1 per il riepilogo delle linee tecnologiche individuate
nel §5 di [A1]) riguardanti lo sviluppo delle tecnologie di autolanding e di visual based navigation.
Rif. in [A1]]
Descrizione
L1-T2, L1T6 (change
AL-C6, ALC12)
Autonomous
Approach & Landing
with Adaptive
Capabilities
&
Sensor Management
and Navigation
Vision-aided
Navigation
L1-T7
Analisi
Obiettivo principale da perseguire nello sviluppo della tecnologia suddetta è quello di aggiornare gli
algoritmi di navigazione sviluppati in TECVOL-I in modo da poter usufruire dei vantaggi offerti da
EGNOS, rispetto a quelli tipici del GPS (stand alone).
La funzionalità di autolanding è stata già sviluppata e validata in volo [R33] in TECVOL-I per mezzo di
una suite di sensori che prevedeva un GPS differenziale (e quindi una pista appositamente strumentata), una
AHRS (comprendente una IMU ed un MAG), un set di sensori aria tradizionali ed un Laser Altimetro
(LALT).
In TECVOL-II ci si prefigge invece di sviluppare una tecnologia di autolanding su una pista completamente
non strumentata utilizzando algoritmi di navigazione EGNOS based. Un’analisi preliminare ([R34]) ha
infatti già dimostrato che le accuratezze orizzontali offerte dal solo sistema EGNOS non sono sufficienti
per effettuare un atterraggio (sia basandosi sulle normative ICAO (CAT III) che sulle pregresse esperienze
CIRA). È quindi necessario un aiding nel piano orizzontale che potrà essere fornito da sensori elettro ottici
(EO) / infrrarosso (IR); in una prima fase, tali sensori potranno essere simulati, in volo, utilizzando la
misura fornita dal GPS differenziale, attualmente già disponibile a bordo.
Il sistema di navigazione per l’autolanding EGNOS&Visual based (denominato ALEV) dovrà integrare un
set di differenti sensori primari (EGNOS, IMU, MAG, EO/IF, LALT, ADS) e, nel contempo, dovrà
soddisfare i requisiti di performance (in termini di accuratezza, integrità, affidabilità e safety) richiesti per
un atterraggio manuale.
3.2.1.3.3 Metodo di verifica
VM_Flight_Validation (FLARE)
29
CIRA-CF-12-0600 Rev. 1 P. 29/109
TECVOL-II
TECVOL-II - System Requirements
CIRA-CF-12-0600
3.2.1.3.4 Requisiti di progetto
ID
Titolo
Descrizione
Autolanding
EGNOS&Visual
based
Il sistema ALEV dovrà eseguire in automatico le manovre di
allineamento, approccio alla pista, atterraggio fino al touch-down e
gestione della fase di post-touchdown. La manovra di atterraggio
automatico avverrà secondo traiettorie di approccio non fissate a
priori, bensì generate in linea sulla base dello stato iniziale del
velivolo.
TECV2-SUBS-
ALEV 00010_0.0
TECV2-SUBS-
ALEV 00020_0.0
TECV2-SUBS-
Il sistema ALEV, in una sua versione preliminare individuata dalla sigla
ALEV-V0, sarà in grado di svolgere la manovra di autolanding per
Set di sensori di
mezzo di un sistema di navigazione basato sul seguente set di sensori
ALEV 00030_0.0
navigazione
primari: EGNOS, IMU, MAG, GPS differenziale (D-GPS), LALT, ADS. In
intermedio
particolare, il D-GPS dovrà essere utilizzato per simulare le misure
tipiche di un aid orizzontale ottenibile da sensori EO/IR.
TECV2-SUBS-
Il sistema ALEV definitivo, identificato dalla sigla ALEV-V1, dovrà
Set di sensori di
essere in grado di atterrare anche su piste non strumentate per
navigazione
ALEV 00040_0.0
mezzo di un sistema di navigazione basato sul seguente set di sensori
definitivo
primari: EGNOS, IMU, MAG, EO/IF, LALT, ADS.
Rationale
Performance del Il sistema ALEV dovrà soddisfare gli stessi requisiti di integrità ed
sistema
affidabilità richiesti per un atterraggio manuale.
30
CIRA-CF-12-0600 Rev. 1 P. 30/109
TECVOL-II
TECVOL-II - System Requirements
3.2.1.4
CIRA-CF-12-0600
Automatic 4D plan execution (4DPE)
3.2.1.4.1 Descrizione sintetica del sistema
Nella presente sezione sono descritti, sotto forma di appositi requisiti, gli obiettivi che si intende raggiungere attraverso lo sviluppo, in ambito
TECVOL-II, della tecnologia Automatic 4D Plan Execution (di seguito sinteticamente indicata con l’acronimo 4DPE). A tale sistema è associato
l’identificativo S04.
3.2.1.4.2 Giustificazione
Stante la natura di follow-up di tale funzione rispetto a quanto già implementato in TECVOL-I, nella redazione di tali requisiti si è tenuto
debitamente in conto di quanto già sviluppato nel citato precedente progetto. L’elemento fondamentale del quale si è tenuto conto nella redazione
dei requisiti che seguono è che gli algoritmi di 4DAMF sviluppati in TECVOL-I sono stati testati fino alla simulazione fast time, raggiungendo TRL
5 [R27]. Ne segue che l’obiettivo principale da raggiungere in TECVOL-II per quanto riguarda il 4DPE, in qualità di follow-up delle attività
TECVOL-I, è quello di sviluppare la tecnologia ereditata da TECVOL-I fino al TRL 6, senza integrazione di nuove funzioni. Tutti gli upgrade,
invece, saranno integrati in TECVOL-II nell’ambito del 4D Contract Management System (cfr. sezione 3.4.2.2).
Una sintetica descrizione dei risultati ottenuti in TECVOL-I con riferimento alla funzionalità di 4D Autonomous Mid-air Flight (4DAMF) è
riportata nel documento ConOps TECVOL-II [A1], nella sezione 3.3.1, mentre una descrizione completa è riportata nel documento di riferimento
[R27]. I requisiti descritti di seguito, quindi, sono coerenti con quelli indicati nel documento di riferimento [R27] e ne costituiscono una
generalizzazione dal punto di vista dell’utente. La linea tecnologica di riferimento individuata in [A1] è la L1-T2 relativa all’esecuzione autonoma
della missione ed, in particolare, all’ navigazione automatica 4D.
3.2.1.4.3 Metodo di verifica
VM_Flight_Validation (FLARE)
31
CIRA-CF-12-0600 Rev. 1 P. 31/109
TECVOL-II
TECVOL-II - System Requirements
CIRA-CF-12-0600
3.2.1.4.4 Requisiti di progetto
ID
TECV2-SUBS- 4DPE- 00010_0.0
TECV2-SUBS-
Titolo
Descrizione
Rationale
Il modulo 4DPE dovrà essere progettato per l'applicazione generale al
Applicabilità del
Come follow-up del 4DAMF di TECVOL-I, ne
segmento di volo di cruise, andando ad escludere esplicitamente
4DPE Module
viene mantenuta la medesima applicabilità
l'applicazione alle fasi di take off e landing.
Il modulo 4DPE, quando attivato, dovrà generare una traiettoria di
riferimento ed una correzione, ove necessaria, al riferimento di TAS
Funzionalità del da inviare all’autothrottle tali da raggiungere il WP di target
4DPE 00020_0.0
4DPE Module desiderato nel rispetto del vincolo temporale (velocità inerziale media
desiderata nel raggiungimento del WP) per esso specificato nella lista
di WPs considerata e del criterio spaziale di cattura desiderato
Vincoli sui
riferimenti per
SCAS/AP
generati da
4DPE module
Come follow-up del 4DAMF di TECVOL-I, ne
viene mantenuta la medesima impostazione. Ne
segue che il Required Time of Arrival (cfr
requisito apposito) sul WP di target non è
espresso come tale ma come velocità inerziale
media desiderata nel raggiungere tale WP a
partire dalla posizione inziale del velivolo.
Il modulo 4DPE dovrà generare riferimenti per lo SCAS/Autopilot nel Si desidera ridurre il workload del sistema
rispetto dei vincoli dinamici previsti per la piattaforma volante SCAS/AP, generando per esso comandi che
desiderata.
siano fisicamente realizzabili.
TECV2-SUBS-
4DPE 00030_0.0
TECV2-SUBS-
Il 4DPE module dovrà implementare la generazione e l’inseguimento
di traiettoria per il raggiungimento di WPs 4D, specificati in termini di
Generazione ed liste di WPs (piani di volo). Tale funzionalità dovrà essere espletata
inseguimento considerando uno per volta, in maniera sequenziale, come WP di
della traiettoria target corrente tutti i WPs contenuti nella lista. Nel momento in cui
4DPE 00040_0.0
4D
un WP 4D viene attivato come WP di target corrente, il 4DPE module
“contrattuale” dovrà generare una traiettoria 3D (traiettoria “contrattuale”) ed un
da parte del
profilo di velocità che consentano il raggiungimento di tale WP in
4DPE module conformità con i criteri di capture spaziale e temporale per esso
stabiliti. Tale traiettoria e tale profilo di velocità dovranno essere
compatibili con le prestazioni dinamiche cui il velivolo è sottoposto.
Si desidera che la traiettoria generata sia
fisicamente volabile da parte del velivolo, quindi
si richiede che già a livello di guidance vengano
tenute in conto le prestazioni dinamiche (ad
esempio il raggio di curvatura minimo) ed i limiti
di inviluppo (ad esempio in termini di TAS) del
velivolo medesimo
32
CIRA-CF-12-0600 Rev. 1 P. 32/109
TECVOL-II
TECV2-SUBS-
TECV2-SUBS-
TECV2-SUBS-
TECVOL-II - System Requirements
Il vincolo Required Time of Arrival (RTA) rappresenterà il tempo in
corrispondenza del quale, a partire dall’istante in cui inizia
l’inseguimento del WP di target corrente ed in condizioni nominali, si
richiede che tale WP venga raggiunto, in conformità con il criterio di
capture
spaziale
per
esso
stabilito.
Tale vincolo discenderà dal requisito sulla velocità inerziale media di
raggiungimento del WP di target corrente, specificata nella lista di
WPs per ciascun WP 4D, e dalla lunghezza della traiettoria
“contrattuale” generata dal 4DPE module.
CIRA-CF-12-0600
La ragione per cui viene imposta una velocità
inerziale media e non direttamente un RTA è
duplice
(cfr
4DAMF
TECVOL-I):
1. l'inviluppo di volo di FLARE è talmente ridotto
in termini di TAS che è più conveniente ottenere
il desiderato RTA calcolandolo, piuttosto che
imponendolo, a partire dall'effettiva lunghezza
della traiettoria nominale generata on line dal
modulo stesso e dalla desiderata velocità
inerziale (imposta come requisito in modo che
sia ragionevolmente compatibile con l'inviluppo
di
TAS
previsto
per
FLARE);
2. la lista di WPs implementata nel SW 4DAMF
ha ereditato quella progettata per il SW di
3DAMF, quindi non contiene un campo RTA ma
un campo di velocità inerziale desiderata (che
comunque in 3DAMF non era usato).
4DPE 00050_0.0
Required Time
of Arrival (RTA)
4DPE 00060_0.0
Margine
temporale su
RTA
Il WP 4D dovrà essere raggiunto in conformità al prescritto RTA entro
un prefissato margine temporale. Tale margine rappresenterà la In presenza di disturbi esterni, come inevitabile
finestra temporale, rispetto al vincolo RTA, nell’ambito della quale si nel volo reale, deve essere previsto un adeguato
accetta che, in condizioni reali, il velivolo effettui la capture del WP, in margine temporale rispetto al RTA imposto
conformità con il criterio di capture spaziale per esso stabilito.
4DPE 00070_0.0
Monitoraggio
continuo delle
condizioni di
inseguimento
del vincolo
temporale
Il 4DPE module dovrà calcolare con una prefissata frequenza di
aggiornamento l'Estimated Time of Arrival (ETA) e dovrà confrontarlo
con il RTA prefissato, allo scopo di valutare se la differenza tra ETA e
RTA è o meno tale da rispettare il margine temporale prestabilito sul
WP inseguito.
L'efficacia del 4DPE module nel soddisfacimento
del vincolo temporale su WP di target risulta
aumentata se l'azione di verifica dell'errore
temporale stimato e conseguente attuazione di
una strategia correttiva viene effettuata con
frequenza opportunamente elevata.
33
CIRA-CF-12-0600 Rev. 1 P. 33/109
TECVOL-II
TECVOL-II - System Requirements
CIRA-CF-12-0600
Attorno alla traiettoria “contrattuale” generata dal 4DPE module per
il raggiungimento del target WP corrente dovrà essere presente un
volume di controllo (Contract Tube, CT) finalizzato a stabilire uno
spazio 3D di “free flight” per il velivolo, cioè uno spazio di manovra
Volume di
controllo
nel quale esso potrà liberamente gestire il proprio volo per il
(Contract Tube) raggiungimento
del
current
WP.
attorno alla
Le dimensioni di tale volume di controllo dovranno essere
traiettoria
sufficientemente ampie da consentire al velivolo eventuali modifiche
“contrattuale” locali e/o globali della traiettoria verso il WP attualmente inseguito
(rigenerazione di traiettoria), modifiche motivate da disturbi
ambientali (vento) che ostacolino l’inseguimento della traiettoria
“contrattuale” nel rispetto del vincolo temporale sul WP.
In presenza di disturbi esterni, come inevitabile
nel volo reale, deve essere previsto un adeguato
margine spaziale rispetto alla traiettoria
"contrattuale" imposta
Nel caso in cui la condizione del velivolo nei confronti del vincolo
temporale sia tale da richiedere un intervento da parte del 4DPE
module, esso dovrà implementare le seguenti capacità operative:
a) modifica del solo riferimento di velocità del velivolo;
b)
modifica
della
sola
traiettoria
3D
del
velivolo;
c) modifica simultanea del riferimento di velocità e della traiettoria 3D
del velivolo.
Si richiede che il 4DPE module sia in grado di
espletare azioni correttive non solo sul profilo di
velocità, come usuale negli FMS correnti, ma
anche sul profilo geometrico di traiettoria o su
entrambi. Ciò è finalizzato all'introduzione di
capacità innovative rispetto a quelle
usualmente implementate negli FMS
Anche in fase di rigenerazione del riferimento di
TAS, si richiede che il 4DPE module sia in grado
di tenere conto dell'inviluppo operativo del
velivolo
TECV2-SUBS-
4DPE 00080_0.0
TECV2-SUBS-
Azioni di
controllo per il
4DPE 00090_0.0 soddisfacimento
del vincolo
temporale
TECV2-SUBS-
Nell’esercitare l’azione di controllo sul riferimento di velocità del
Limiti all’azione
velivolo, il 4DPE module dovrà tenere conto dei vincoli di prestazione
di controllo sulla
del medesimo ed evitare pertanto che la velocità aerodinamica (TAS)
4DPE 00100_0.0
velocità del
comandata fuoriesca dall’inviluppo operativo del velivolo nella
velivolo
configurazione corrente.
34
CIRA-CF-12-0600 Rev. 1 P. 34/109
TECVOL-II
TECV2-SUBS-
TECVOL-II - System Requirements
Nel modificare la traiettoria 3D del velivolo, il 4DPE module dovrà
rigenerare on line una traiettoria che sia coerente con i vincoli
dinamici cui esso è sottoposto, cioè che sia effettivamente attuabile
Rigenerazione
da parte del velivolo medesimo. Inoltre, la nuova traiettoria 3D dovrà
della traiettoria
essere tale da ricadere entro il volume di controllo assegnato attorno
per il
alla traiettoria “contrattuale”. Nel caso in cui il sistema 4DPE non
soddisfacimento
riesca a generare una nuova traiettoria 3D che, unitamente ad
4DPE 00110_0.0
del vincolo
un’eventuale opportuna modifica del riferimento di velocità, consenta
temporale e
di rispettare il prescritto margine temporale sul WP di destinazione
relativi limiti
e/o non riesca a generare una nuova traiettoria 3D completamente
operativi
contenuta entro il volume di controllo attorno alla traiettoria
“contrattuale”, esso dovrà fornire alla logica di automazione di
missione di alto livello un’opportuna indicazione in merito.
3.2.1.5
CIRA-CF-12-0600
Anche in fase di rigenerazione di traiettoria, si
desidera che vengano tenute in conto le
prestazioni dinamiche (ad esempio il raggio di
curvatura minimo) del velivolo, oltre che i
requisiti 4D imposti sulla traiettoria e sul WP di
target
RPV
Sebbene il progetto TECVOL-II abbia come specifico obiettivo una maggiore autonomia di bordo degli UAV fino a raggiungere il livello 3 nella
scala definita dalla NATO [R7] (vedi Tabella 2-2), l’importanza delle tecnologie per il pilotaggio da remoto degli stessI resta cruciale. Infatti tale
concetto viene ribadito dalla circolare ICAO sugli UAS [R4] che individua il possibile inserimento degli UAS nello spazio aereo regolato dall’ATM
solo come velivoli pilotati, o almeno completamente controllati, da remoto. Anche l’autorità certificativa nazionale ENAC, in un recente incontro
utile alla definizione dei Conops del progetto [R50], ha ribadito l’importanza del pieno sviluppo delle tecnologie RPV.
Lo sviluppo della funzione di pilotaggio da remoto di un velivolo unmanned era già stata prevista nel progetto TECVOL-I. L’obiettivo primario del
lavoro svolto è stato quello di progettare e realizzare un sistema innovativo per la funzionalità di visione durante il pilotaggio remoto di velivoli
unmnned al fine di fornire una maggiore consapevolezza della situazione al pilota. Questo obiettivo ha posto il problema di dotare il sistema di
nuove funzionalità, che fornissero al pilota di un UAV stimoli visivi analoghi a quelle che egli riceve pilotando un velivolo tradizionale e
permettendogli così di sfruttare appieno la propria capacità di visione: a tale scopo è stato progettato, sviluppato e validato in volo un sistema per la
visione stereoscopica immersiva a distanza con l’obiettivo di migliorare la situation awareness del pilota durante le fasi di pilotaggio remoto di
velivoli unmanned [R30].
35
CIRA-CF-12-0600 Rev. 1 P. 35/109
TECVOL-II
TECVOL-II - System Requirements
CIRA-CF-12-0600
Nel progetto TECVOL-I non è però stato completato lo sviluppo della funzione di controllo da remoto del velivolo sebbene i requisiti tale
tecnologia sono stati pienamente specificati nei documenti [R28][R29]. In particolare la specifica dei suddetti requisiti è propedeutica alla
progettazione e realizzazione della stazione di terra medesima, il cui scopo è quello di consentire:
• il pilotaggio manuale da remoto della piattaforma volante FLARE;
• il management della modalità di volo autonomo;
• il monitoraggio e controllo di esperimenti in volo condotti sul velivolo FLARE ed inerenti il testing delle numerose funzionalità
implementate nel modulo di Autonomous GNC quali atterraggio automatico, navigazione autonoma per WPs e autonomous collision
avoidance.
Nel progetto TECVOL-II ci si propone quindi di ultimare lo sviluppo delle funzionalità suddette e validare in volo la tecnologia RPV sulla
piattaforma FLARE. La linea tecnologica di riferimento individuata in [A1] è la L3-T3 relativa allo sviluppo delle interfacce uomo macchina, e
relativi algoritmi di bordo ad esse afferenti, utili al supporto alla guida manuale e/o automatica. A tale sistema è associato l’identificativo S05.
3.3 Tecnologie di volo autonomo per UAV
In questa categoria sono raggruppati i requisiti relativi alle tecnologie specificamente sviluppate per gli UAV. In particolare saranno considerati sia
il segmento di bordo di un UAV che quello di terra come previsto nel §5.3 di [A1], inoltre saranno sviluppate anche tecnologie per datalink
innovativi che saranno affiancate a quelle relative al datalink di sistema dei vari dimostratori volanti utilizzati per la validazione in volo. Secondo
quanto detto la categoria oggetto del presente paragrafo sarà suddivisa in tre classi: l’Autonomous Mission Management and Execution che sarà
inquadrata nel segmento di bordo dell’UAV, la classe di HMI and Payload management inquadrata in parte nel segmento di bordo (payload) ed in
parte in quello di terra (HMI) ed, infine, la classe di tecnologie relativi ai Datalink.
3.3.1
Autonomous Mission Management and Execution
In questa classe sono comprese tutte le tecnologie afferenti agli algoritmi di Guida, Navigazione e Controllo (GNC) previsti per il segmento di
bordo di un UAV allo scopo di perseguire il secondo pillars tecnologico del progetto ([A1] e §2 del presente documento). In particolare
l’architettura funzionale di riferimento del sistema GNC che sarà sviluppato in ambito del progetto TECVOL-II è stata già ampiamente affrontata e
descritta nel §5 di [A1] e viene di seguito riportata per comodità del lettore in Figura 3-1. Ad essa faranno riferimento i diversi moduli che saranno
sviluppati nel progetto i cui requisiti sono definiti nei prossimi sotto-paragrafi.
36
CIRA-CF-12-0600 Rev. 1 P. 36/109
TECVOL-II
TECVOL-II - System Requirements
Vehicle Constraints
Data
Link
Mission
Feasibility
Mission
Management
Trajectory
References
Trajectory
Generation
Targets
Feasibility
Features
& Classifications
Trajectory
Feasibility
Attitude
Commands
Trajectory
Tracking
Attitude
Feasibility
Flight Control
Laws
Vehicle
Parameters
Situational
Awareness
Vehicle
Measurements
On-Line
Identification
Vehicle & Position
Measurements
Terrain Features
Figura 3-1 -
3.3.1.1
Failure & Health
Monitoring
Mission
Objectives
Targets
& Modes
Mission
Mode
CIRA-CF-12-0600
Sensor
Management &
Navigation
Architettura funzionale di bordo di TEVOL-II
Autonomous Mission Manager (High Autonomy Planner/Replanner - HAPR)
3.3.1.1.1 Descrizione sintetica del sistema
L’Autonomous Mission Manager, di seguito identificato dalla sigla HAPR, dovrà gestire tutti gli aspetti relativi alla pianificazione autonoma di
missione, cioè alla generazione di piani che guidino nel raggiungimento degli obiettivi. Le funzioni di alto livello allocate a questo modulo sono,
dunque, quelle di:
• interpretazione delle istruzioni di missione: dovranno essere formalizzati (secondo un linguaggio opportunamente definito) i target di
missione e i vincoli;
37
CIRA-CF-12-0600 Rev. 1 P. 37/109
TECVOL-II
TECVOL-II - System Requirements
CIRA-CF-12-0600
• ricostruzione in linea dello scenario operativo: dovrà essere effettuato un assessment delle informazioni ambientali provenienti dal
Situational Awareness, dal database di bordo di supporto per la navigazione e da terra (modulo Data Link) per la ricostruzione dello scenario
operativo da considerare per la pianificazione e l’esecuzione della missione;
• mission planning autonomo: dovrà essere elaborato e aggiornato in linea il piano di volo sulla base delle informazioni fornite dai sottomoduli
per l’interpretazione delle istruzioni di missione e per la stima delle caratteristiche dello scenario.
L’Autonomous Mission Manager dovrà, infine, prevedere la gestione di livelli variabili di autonomia. A tale sistema è associato l’identificativo S06.
3.3.1.1.2 Giustificazione
I requisiti di progetto riguardanti l’Autonomous Mission Manager sono stati definiti mediante un’analisi delle change AL-C16, AL-C17 e AL-C18
definite nel §4 di [A1] ed in generale della tecnologica L1-T1 (vedi Tabella 2-1 per il riepilogo delle linee tecnologiche individuate nel §5 di [A1]).
La tabella che segue sintetizza l’analisi condotta sulle singole change.
Rif. in [A1]
L1-T1
(change ALC16)
Descrizione
Riduzione della
frequenza di
interazione tra gli
operatori di terra e il
velivolo
Analisi
Il sistema dovrà consentire agli operatori di terra di poter inviare le sole istruzioni di missione (locazioni
target, locazioni finali, funzioni da eseguire nelle zone target, criteri di esecuzione). È necessario, tuttavia,
prevedere un livello di autonomia variabile a seconda dello scenario operativo attuale e delle richieste della
GCS. In quest’ottica, i gradi di autonomia che il modulo di Autonomous Mission Management dovrà
supportare sono quelli relativi (requisito TECV2-SUBS-HAPR-00010):
• all’esecuzione di un piano missione (livello di autonomia più alto): livello A;
• all’esecuzione di un piano di volo: livello B;
• all’esecuzione di una sequenza di istruzioni autopilota: livello C.
L’esecuzione di comandi in modalità RPV (livello di autonomia più basso), invece, non impatta
l’Autonomous Mission Manager.
I primi due livelli di autonomia implicano una interazione “intelligente” da parte del sistema, in cui
quest’ultimo dovrà elaborare rispettivamente il piano di missione o il piano di volo richiesto per valutarne
la fattibilità ed eventualmente dovrà proporre delle proprie varianti. A questo scopo, il modulo di
Autonomous Mission Management dovrà offrire le due seguenti funzioni:
• contrattazione del piano di missione (requisito TECV2-SUBS-HAPR-00100): per il livello A dovrà
essere negoziato il piano di missione da eseguire mediante un protocollo specifico che implementi:
la notifica di fattibilità della missione e l’invio del piano di volo elaborato a bordo (si veda la
38
CIRA-CF-12-0600 Rev. 1 P. 38/109
TECVOL-II
TECVOL-II - System Requirements
CIRA-CF-12-0600
descrizione dell’analisi della change AL-C18 per maggiori dettagli sulla fattibilità di un piano di
missione);
i meccanismi di autorizzazione a procedere;
• contrattazione del piano di volo (requisito TECV2-SUBS-HAPR-00140): per il livello B dovrà essere
negoziato il piano di volo da eseguire mediante un protocollo specifico che implementi:
la notifica di fattibilità del piano di volo e l’invio di eventuali piani di volo sostitutivi elaborati a
bordo in caso di fattibilità parziale (si veda la descrizione dell’analisi della change AL-C18 per
maggiori dettagli sui concetti di fattibilità del piano di volo e di piani di volo alternativi);
i meccanismi di autorizzazione a procedere.
I risultati dei protocolli di contrattazione sono:
• i piani di missione e i piani di volo concordati per il livello A: sono i piani di missione e di volo che
verranno eseguiti dal velivolo;
• il piano di volo concordato per il livello B: è il piano di volo che verrà eseguito dal velivolo.
Entrambi i protocolli dovranno essere attivati, oltre che su richiesta della GCS (cioè quando viene
sottoposto un nuovo piano di missione o di volo), anche in maniera “spontanea” per esigenze di
ripianificazione (causate da eventi asincroni legati al traffico, al meteo, a variazioni nelle no-fly zone o a
comunicazioni di non fattibilità del piano di volo provenienti dal sottosistema preposto alla sue esecuzione).
Per una descrizione più dettagliata della ripianificazione si veda l’analisi della change AL-C18.
La gestione di ognuno dei tre livelli di autonomia sopra riportati richiede, inoltre, un’interpretazione di tutte
le possibili istruzioni di missione, che dovrà avvenire mediante funzioni basate su un linguaggio formale
opportunamente definito. Devono essere, dunque, formalizzati:
• il piano di missione richiesto (requisito TECV2-SUBS-HAPR-00030), che dovrà specificare gli
obiettivi di missione (mission constraints indicati in [A1]), i criteri (funzionali di costo) e i vincoli di
percorso diretti (cioè il sottoinsieme dei path constraints indicati in [A1] che viene esplicitamente
indicato dall’operatore per la missione e che contiene, ad esempio, vincoli legati all’attraversamento di
un waypoint predeterninato oppure limitazioni sull’altitudine e la velocità);
• il piano di volo richiesto (requisito TECV2-SUBS-HAPR-00110), che dovrà specificare la sequenza di
waypoint o di leg da eseguire, corredata di eventuali informazioni temporali (per il flight plan 4D) e di
criteri ARINC 424-19;
• il piano di volo generato, che dovrà specificare il flight plan elaborato a bordo nel caso di esecuzione di
una missione di livello A o di una missione di livello B con piano di volo parzialmente fattibile; il flight
plan elaborato dovrà essere inviato alla GCS per l’autorizzazione esplicita da parte dell’operatore di
terra nell’ambito dei protocolli di contrattazione del piano di missione (requisito TECV2-SUBS-HAPR39
CIRA-CF-12-0600 Rev. 1 P. 39/109
TECVOL-II
TECVOL-II - System Requirements
L1-T1
(change ALC17)
Stima delle
caratteristiche dello
scenario operativo di
missione
L1-T1
(change ALC18)
Autonomous Mission
Planning
CIRA-CF-12-0600
00100) e del piano di volo (requisito TECV2-SUBS-HAPR-00140);
• le istruzioni per l’autopilota (requisito TECV2-SUBS-HAPR-00160), che dovranno specificare la
sequenza dei comandi per l’autopilota per una missione di livello C;
• i messaggi informativi (requisito TECV2-SUBS-HAPR-00040), per la segnalazione di eventi asincroni
legati al meteo, al traffico, alle no-fly zone o alle condizioni delle piste di atterraggio.
Il modulo di Autonomous Mission Management, infine, dovrà inoltrare la sequenza di comandi autopilota
al sottosistema preposto per l’esecuzione nel caso di una missione di livello C (requisito TECV2-SUBSHAPR-00170).
Il modulo di Autonomous Mission Management dovrà formalizzare in una forma adatta alla risoluzione del
problema di ottimizzazione per il planning tutti i vincoli legati allo scenario operativo di missione non
strutturato (requisito TECV2-SUBS-HAPR-00050). Questi ultimi, nel dettaglio, possono essere considerati
dei vincoli di percorso indiretti, in quanto non sono selezionati esplicitamente dall’operatore di terra, ma
sono dettati dalle no-fly zone o da eventi asincroni legati al traffico, al meteo o a variazioni nelle no-fly
zone. Le informazioni relative a tali vincoli provengono dal database di bordo, dalla Situational Awareness
e dal Data Link (requisito TECV2-SUBS-HAPR-00040).
Il modulo di Autonomous Mission Management dovrà elaborare ed aggiornare il piano di volo. In base al
concetto di differenziazione dei livelli di autonomia (requisito TECV2-SUBS-HAPR-00010), il processo di
planning dovrà variare a seconda che sia richiesta l’esecuzione un piano di missione (livello A nell’analisi
della change AL-C16) o di un piano di volo (livello B nell’analisi della change AL-C16).
Nel primo caso il flight plan, come descritto in [A1], deve essere inteso come la soluzione di un problema
di ottimizzazione vincolato, definito formalmente specificando un funzionale di costo da minimizzare e un
insieme di vincoli suddivisibili in mission constraints, path constraints e vehicle constraints.
In realtà, in base a quanto previsto nell’architettura funzionale di bordo di TECVOL-II proposta in [A1]
(fig. 13), le informazioni relative ai vehicle constraints non verranno usate direttamente in input alla
funzione di mission planning, ma indirettamente mediante comunicazioni di non fattibilità del piano di volo
provenienti dal modulo di Trajectory Generation. Ne segue che la pianificazione di missione (requisito
TECV2-SUBS-HAPR-00060) dovrà operare secondo le indicazioni fornite dal piano di missione richiesto e
dallo scenario operativo. Il primo, infatti, contiene il funzionale di costo, i mission constraints e i path
constraints diretti (si veda la descrizione dell’analisi per la change AL-C16 per maggiori dettagli); il
secondo, invece, definisce i vincoli di percorso indiretti (si veda la descrizione dell’analisi per la change
AL-C17 per maggiori dettagli).
Nel caso in cui il modulo non riesca ad elaborare un piano di volo che soddisfi il piano di missione richiesto
e lo scenario operativo, esso dovrà determinare un piano di missione alternativo e fattibile e il relativo
40
CIRA-CF-12-0600 Rev. 1 P. 40/109
TECVOL-II
TECVOL-II - System Requirements
CIRA-CF-12-0600
piano di volo (requisito TECV2-SUBS-HAPR-00090). La ricerca di un flight plan alternativo potrà
avvenire rilassando i vincoli di percorso indiretti e/o introducendo delle varianti nel piano di missione, ossia
rilassando uno o più vincoli tra quelli presenti nel mission plan richiesto. Nelle fasi successive di progetto
dovranno essere approfonditi i meccanismi con cui potranno essere selezionati e modificati i vincoli in un
piano di missione alternativo.
Qualora neanche la pianificazione di missione alternativa presenti una soluzione, il mission plan richiesto
dovrà essere classificato come non fattibile (requisito TECV2-SUBS-HAPR-00090).
Oltre alla funzione di pianificazione di missione (attivata dalla sottomissione di un nuovo mission plan
dall’operatore di terra), l’Autonomous Mission Manager dovrà mettere a disposizione anche una funzione
di ripianificazione della missione (requisito TECV2-SUBS-HAPR-00080). Quest’ultima dovrà aggiornare
il piano di volo a seguito di cambiamenti nello scenario operativo o di comunicazioni di non fattibilità del
piano di volo concordato (cioè autorizzato dal processo di contrattazione; si veda l’analisi della change ALC16 per maggiori dettagli): i primi sono causati da eventi asincroni legati al traffico, al meteo, a variazioni
nelle no-fly zone e si traducono in cambiamenti nei vincoli di percorso indiretti; i secondi forniscono
indicazioni sui vehicle constraints descritti in [A1] relativamente alla configurazione e/o allo stato di salute
del velivolo. Si osservi che la ripianificazione di missione potrebbe anche non introdurre cambiamenti nel
piano di volo nel caso in cui le modifiche allo scenario operativo non impattino il piano di volo generato. È
evidente che anche per la ripianificazione si riproporrà la possibilità di generazioni di piani alternativi a
quelli concordati (requisito TECV2-SUBS-HAPR-00090), che richiederanno nuovamente la contrattazione
e l’autorizzazione esplicita dell’operatore di terra.
Per quanto riguarda il livello di autonomia B, invece, la funzione di planning dovrà valutare la fattibilità del
piano di volo richiesto dall’operatore di terra nell’ambito dello scenario operativo corrente (requisito
TECV2-SUBS-HAPR-00120). La compatibilità tra il flight plan richiesto e lo scenario operativo potrà
essere totale, nulla o parziale. In quest’ultimo caso l’Autonomous Mission Manager dovrà elaborare un
piano di volo alternativo e fattibile e che abbia uno scostamento minimo dal piano di volo richiesto. Nelle
fasi successive di progetto dovranno essere stabiliti i criteri di classificazione di un flight plan (in termini di
fattibilità, fattibilità parziale e non fattibilità) e un indice di scostamento (da minimizzare) tra un piano di
volo parzialmente fattibile e il corrispondente piano di volo alternativo. Tale indice dovrà tener conto sia di
misure spaziali (ad esempio, distanze geografiche tra i waypoint dei due plan) che di misure temporali (ad
esempio, differenze temporali nel raggiungimento di waypoint 4D).
Analogamente al livello A, anche in una missione di livello di autonomia B dovrà essere disponibile una
funzione di ripianificazione di volo (requisito TECV2-SUBS-HAPR-00130), per la quale valgono le stesse
considerazioni della funzione di ripianificazione di missione visto che entrambe agiscono sul piano di volo
41
CIRA-CF-12-0600 Rev. 1 P. 41/109
TECVOL-II
TECVOL-II - System Requirements
CIRA-CF-12-0600
concordato.
Il modulo di Autonomous Mission Management, infine, dovrà:
• inoltrare il piano di volo concordato al sottosistema preposto per l’esecuzione nel caso di una missione
di livello A o di livello B; (requisito TECV2-SUBS-HAPR-00150);
• acquisire le eventuali comunicazioni relative alla mancata copertura del piano di volo concordato a
causa di vincoli legati alla configurazione del velivolo e/o failure di sottosistemi (requisito TECV2SUBS-HAPR-00070).
Si ipotizza che le tipologie di missione autonome applicabili per il velivolo siano (requisito TECV2-SUBSHAPR-00020):
• missione di spostamento: atterraggio in un sito diverso da quello di decollo;
• missione di monitoraggio: copertura di un insieme di aree geografiche di interesse in cui eventualmente
devono essere eseguite specifiche azioni di sorveglianza;
• missione di tracking: la copertura di un insieme di aree geografiche d'interesse in cui cercare e seguire
un target specifico.
La definizione delle tipologie di missioni autonome applicabili è essenziale per il disegno di dettaglio del
formato del piano di missione nelle fasi successive di progetto.
Al fine, inoltre, di implementare nel lungo periodo un’integrazione del sistema all’interno di una flotta di
UAS come richiesto in [A1], sarà necessario sviluppare l’Autonomous Mission Manager conformemente a
standard internazionali per lo scambio messaggi e per la descrizione delle informazioni in ambito
aeronautico (requisito TECV2-SUBS-HAPR-00180).
L1-T1 all
Tabella 3-2 – Analisi dei Conops [A1] per l’Autonomous Mission Manager
3.3.1.1.3 Metodo di verifica
VM_Flight_Validation (FLARE II)
42
CIRA-CF-12-0600 Rev. 1 P. 42/109
TECVOL-II
TECVOL-II - System Requirements
CIRA-CF-12-0600
3.3.1.1.4 Requisiti di progetto
ID
Titolo
TECV2-SUBS- HAPR-00010
_0.0 Livelli di
autonomia/interazione
TECV2-SUBS- HAPR-00020
_0.0 Tipologie di missione
autonoma
Descrizione
L'Autonomous Mission Manager dovrà prevedere i seguenti tipi
d'interazione con la GCS, legati ai vari gradi di autonomia che il
velivolo dovrà supportare:
- esecuzione autonoma di una missione;
- esecuzione di un piano di volo;
- esecuzione di istruzioni autopilota.
Nella modalità di esecuzione autonoma di una missione, il modulo di
Autonomous Mission Management dovrà supportare le seguenti
tipologie di missione:
- missione di spostamento;
- missione di monitoraggio;
- missione di tracking.
Rational
L'esecuzione di istruzioni in
modalità RPV non dovrà
essere gestita
dall'Autonomous Mission
Manager.
Per missione di spostamento
si intende il semplice
atterraggio in un sito diverso
da quello di decollo.
Per missione di monitoraggio
si intende la copertura di un
insieme di aree geografiche
di interesse in cui
eventualmente devono
essere eseguite specifiche
azioni di sorveglianza.
Per missione di tracking si
intende la copertura di un
insieme di aree geografiche
d'interesse in cui cercare e
seguire un target specifico.
43
CIRA-CF-12-0600 Rev. 1 P. 43/109
TECVOL-II
TECV2-SUBS- HAPR-00030
TECVOL-II - System Requirements
_0.0 Ricezione del piano di
missione richiesto
CIRA-CF-12-0600
Nella modalità di esecuzione autonoma di una missione, il modulo di
Autonomous Mission Management dovrà essere in grado di ricevere
una rappresentazione formale del piano di missione richiesto
dall'operatore di terra. Tale rappresentazione dovrà contenere gli
obiettivi di missione, i criteri di missione e gli eventuali vincoli di
percorso diretti.
Per obiettivi di missione si
intendono i target geografici
che il velivolo deve
raggiungere ed eventuali
azioni da compiere sugli
stessi (mission constraints in
[A1]).
Per criteri di missione si
intendono i funzionali di
costo che devono essere
minimizzati/massimizzati
nell'esecuzione della
missione.
Per vincoli di percorso diretti
si intendono gli eventuali
path constraints
esplicitamente indicati nella
definizione della missione,
come il passaggio per un
determinato waypoint o
vincoli su altitudine e
velocità. Si definiscono invece
vincoli di percorso indiretti
quelli che sono legati a no-flyzone, meteo, traffico.
Si noti che l'insieme dei
vincoli di percorso diretti ed
indiretti costituisce i path
constraints di [A1].
Nelle fasi successive di
progetto dovranno essere
definiti i possibili valori e i
formati dei campi del piano di
missione.
44
CIRA-CF-12-0600 Rev. 1 P. 44/109
TECVOL-II
TECVOL-II - System Requirements
CIRA-CF-12-0600
TECV2-SUBS- HAPR-00040
_0.0 Ricezione di messaggi
informativi
L'Autonomous Mission Manager dovrà essere in grado di ricevere le
informazioni riguardanti eventi asincroni legati al meteo, al traffico, a
modifiche (anche temporanee) alle informazioni contenute nei
database di bordo (no-fly zone, condizioni delle piste).
TECV2-SUBS- HAPR-00050
_0.0 Gestione dello scenario
operativo
L'Autonomous Mission Manager dovrà gestire lo scenario operativo
di missione, identificando i vincoli di percorso indiretti.
TECV2-SUBS- HAPR-00060
_0.0 Pianificazione di missione
I vincoli di percorso indiretti
sono quelli non indicati
esplicitamente da un
operatore di terra. Si tratta
dei vincoli legati alle no-fly
zone o eventi asincroni
dipendenti dal traffico, dal
meteo o da variazioni nelle
no-fly zone. Le informazioni
relative a tali vincoli
provengono dal database di
bordo, dal Situational
Awareness e dalla GCS
(mediante i messaggi
informativi) e dovranno
essere formalizzate in una
forma adatta al planning.
Nella modalità di esecuzione autonoma di una missione,
Il piano di volo elaborato è
l'Autonomous Mission Manager dovrà elaborare un piano di volo che inteso come soluzione del
problema di ottimizzazione
risolva il piano di missione richiesto dall'operatore di terra
nell'ambito dello scenario operativo corrente.
univocamente definito a
La funzione di pianificazione di missione dovrà essere attivata ogni
partire dal piano di missione
volta che viene sottoposto un nuovo piano di missione dall'operatore richiesto e dallo scenario
di terra.
operativo. Il piano di
missione definisce i criteri, gli
obiettivi e i vincoli di
percorso diretti (requisito
TECV2-SUBS-HAPR-00030). Lo
scenario operativo definisce i
vincoli di percorso indiretti
(requisito TECV2-SUBS-HAPR00050).
45
CIRA-CF-12-0600 Rev. 1 P. 45/109
TECVOL-II
TECV2-SUBS- HAPR-00070
TECVOL-II - System Requirements
_0.0 Ricezione della non fattibilità
del piano di volo concordato
CIRA-CF-12-0600
L'Autonomous Mission Manager dovrà essere in grado di ricevere le
comunicazioni relative alla non fattibilità del piano di volo
concordato da parte del sottosistema preposto alla sua esecuzione.
Per piano di volo concordato
si intende quello autorizzato
a valle dei processi di
contrattazione del piano di
missione (requisito TECV2SUBS-HAPR-00100) o di
contrattazione del piano di
volo (requisito TECV2-SUBSHAPR-00140).
La non fattibilità del piano di
volo concordato è legata ai
vehicle constraints descritti in
[A1], per cui può essere
causata dai vincoli associati
alla configurazione e/o allo
stato di salute del velivolo.
46
CIRA-CF-12-0600 Rev. 1 P. 46/109
TECVOL-II
TECV2-SUBS- HAPR-00080
TECVOL-II - System Requirements
_0.0 Ripianificazione di missione
CIRA-CF-12-0600
Nella modalità di esecuzione autonoma di una missione,
l'Autonomous Mission Manager dovrà aggiornare il piano di volo
concordato tenendo conto dei cambiamenti nello scenario operativo
o delle comunicazioni di non fattibilità del piano di volo concordato
stesso.
Per piano di volo concordato
si intende quello autorizzato
a valle del processo di
contrattazione del piano di
missione (requisito TECV2SUBS-HAPR-00100).
I cambiamenti allo scenario
operativo sono provocati da
eventi asincroni legati al
traffico, al meteo, a variazioni
nelle no-fly zone e si
traducono in cambiamenti
dei vincoli di percorso
indiretti.
Le comunicazioni di non
fattibilità del piano di volo
concordato forniscono
un'indicazione sui vehicle
constraints descritti in [A1]
relativamente alla
configurazione e/o stato di
salute del velivolo.
La ripianificazione della
missione potrebbe anche non
introdurre modifiche nel caso
in cui vi siano cambiamenti
nello scenario operativo che
non impattano il piano di
volo concordato stesso.
47
CIRA-CF-12-0600 Rev. 1 P. 47/109
TECVOL-II
TECV2-SUBS- HAPR-00090
TECVOL-II - System Requirements
CIRA-CF-12-0600
_0.0 Pianificazione/ripianificazione Nella modalità di esecuzione autonoma di una missione, se il
di missione alternativa
problema di pianificazione/ripianificazione di missione non presenta
soluzioni, l'Autonomous Mission Manager dovrà elaborare un piano
di volo che risolva un piano di missione alternativo e fattibile
ottenuto rilassando uno o più vincoli nel piano di missione richiesto
e/o uno o più vincoli di percorso indiretti. Se anche la pianificazione
della missione alternativa non presenta soluzioni, l'Autonomous
Mission Manager dovrà giudicare il piano di missione (richiesto o
concordato) come non fattibile.
Per il concetto di piano di
missione concordato si veda
il requisito TECV2-SUBSHAPR-00100.
Qualora la
pianificazione/ripianificazione
della missione non presenti
soluzioni, visto che lo
scenario operativo non
costituisce una variabile di
controllo, l'Autonomous
Mission Manager dovrà
suggerire all'operatore di
terra delle varianti fattibili al
piano di missione richiesto (in
caso di pianificazione) o
concordato (in caso di
ripianificazione) e/o uno o più
vincoli di percorso indiretti.
Nelle fasi successive di
progetto dovranno essere
stabiliti nel dettaglio i
meccanismi con cui
identificare i possibili piani di
missione alternativi (cioè
quali vincoli possono essere
rilassati e in che modo
possono essere modificati).
48
CIRA-CF-12-0600 Rev. 1 P. 48/109
TECVOL-II
TECVOL-II - System Requirements
TECV2-SUBS- HAPR-00100
_0.0 Contrattazione del piano di
missione
TECV2-SUBS- HAPR-00110
_0.0 Ricezione del piano di volo
richiesto
CIRA-CF-12-0600
Nella modalità di esecuzione autonoma di una missione,
l'Autonomous Mission Manager dovrà gestire una contrattazione del
piano di missione che comprenda i seguenti processi:
- notifica della fattibilità, della non fattibilità o della fattibilità con
vincoli rilassati del piano di missione richiesto;
- invio del piano di missione alternativo in caso di fattibilità con
vincoli rilassati;
- invio del piano di volo elaborato a bordo per l'esecuzione della
missione (richiesta o alternativa);
- gestione delle autorizzazioni/divieti espliciti da parte dell'operatore
di terra per l'eventuale piano di missione alternativo e per il piano di
volo elaborato (anche nel caso di piano di missione richiesto
fattibile).
Il protocollo di contrattazione dovrà essere attivato nei due seguenti
casi:
- pianificazione della missione;
- ripianificazione della missione, se viene generato un nuovo piano di
volo.
Nella modalità di esecuzione di un piano di volo, il modulo di
Autonomous Mission Management dovrà essere in grado di ricevere
una rappresentazione formale del piano di volo richiesto
dall'operatore di terra. Tale rappresentazione dovrà contenere la
sequenza di waypoints o di legs da eseguire, corredata di eventuali
informazioni temporali e criteri ARINC 424-19 .
I piani di missione e di volo
autorizzati a valle del
processo di contrattazione
costituiscono rispettivamente
il piano di missione
concordato e il piano di volo
concordato, cioè i piani di
missione e di volo che il
velivolo dovrà effettivamente
eseguire.
Le informazioni temporali
specificano vincoli temporali
di esecuzione del piano di
volo (flight plan 4D).
49
CIRA-CF-12-0600 Rev. 1 P. 49/109
TECVOL-II
TECV2-SUBS- HAPR-00120
TECVOL-II - System Requirements
_0.0 Pianificazione di volo
CIRA-CF-12-0600
Nella modalità di esecuzione di un piano di volo, l'Autonomous
Mission Manager dovrà valutare la fattibilità (intesa come
compatibilità con lo scenario operativo corrente) del piano di volo
richiesto, il quale dovrà essere classificato in fattibile, parzialmente
fattibile o non fattibile.
Nel caso in cui il piano di volo richiesto sia parzialmente fattibile, il
modulo dovrà elaborare un piano di volo alternativo e fattibile che
abbia lo scostamento minimo da quello richiesto.
La funzione di pianificazione di volo dovrà essere attivata ogni volta
che viene sottoposto un nuovo piano di volo dall'operatore di terra.
Nelle fasi successive di
progetto dovranno essere
stabiliti nel dettaglio i criteri
secondo cui un piano di volo
viene giudicato fattibile,
parzialmente fattibile o non
fattibile. Dovrà, inoltre,
essere definito un indice di
scostamento (da
minimizzare) tra il piano di
volo richiesto parzialmente
fattibile e un piano di volo
alternativo e fattibile. Tale
indice dovrà tener conto sia
di misure spaziali (ad
esempio, distanze
geografiche tra i waypoint dei
due piani) che di misure
temporali (ad esempio,
differenze temporali nel
raggiungimento di waypoint
4D).
50
CIRA-CF-12-0600 Rev. 1 P. 50/109
TECVOL-II
TECV2-SUBS- HAPR-00130
TECVOL-II - System Requirements
_0.0 Ripianificazione di volo
CIRA-CF-12-0600
Nella modalità di esecuzione di un piano di volo, l'Autonomous
Mission Manager dovrà aggiornare il piano di volo concordato
tenendo conto dei cambiamenti nello scenario operativo o delle
comunicazioni di non fattibilità del piano di volo concordato stesso.
Per piano di volo concordato
si intende quello autorizzato
a valle del processo di
contrattazione del piano di
volo (requisito TECV2-SUBSHAPR-00140).
I cambiamenti allo scenario
operativo sono provocati da
eventi asincroni legati al
traffico, al meteo, a variazioni
nelle no-fly zone e si
traducono in cambiamenti
dei vincoli di percorso
indiretti.
Le comunicazioni di non
fattibilità del piano di volo
concordato forniscono
un'indicazione sui vehicle
constraints descritti in [A1]
relativamente alla
configurazione e/o stato di
salute del velivolo.
La ripianificazione di volo
potrebbe anche non
introdurre modifiche nel caso
in cui vi siano cambiamenti
nello scenario operativo che
non impattano il piano di
volo concordato.
51
CIRA-CF-12-0600 Rev. 1 P. 51/109
TECVOL-II
TECVOL-II - System Requirements
TECV2-SUBS- HAPR-00140
_0.0 Contrattazione del piano di
volo
TECV2-SUBS- HAPR-00150
_0.0 Inoltro del piano di volo
TECV2-SUBS- HAPR-00160
_0.0 Ricezione delle istruzioni
autopilota
TECV2-SUBS- HAPR-00170
_0.0 Inoltro delle istruzioni
autopilota
TECV2-SUBS- HAPR-00180
_0.0 Utilizzo di standard
TECV2-SUBS- HAPR-00190
_0.0 Efficienza computazionale
CIRA-CF-12-0600
Nella modalità di esecuzione di un piano di volo, l'Autonomous
Mission Manager dovrà gestire una contrattazione del piano di volo
che comprenda i seguenti processi:
- notifica della fattibilità, della non fattibilità o della fattibilità
parziale, con le relative modifiche, del piano di volo;
- gestione delle autorizzazioni/divieti espliciti da parte dell'operatore
di terra in caso di piano di volo parzialmente fattibile.
Il protocollo di contrattazione dovrà essere attivato nei due seguenti
casi:
- pianificazione del volo;
- ripianificazione del volo, se viene generato un nuovo piano di volo.
Nella modalità di esecuzione autonoma di una missione o nella
modalità di esecuzione di un piano di volo, il modulo di Autonomous
Mission Management dovrà inoltrare il piano di volo concordato al
sottosistema preposto per la sua esecuzione.
Il piano di volo autorizzato a
valle del processo di
contrattazione costituisce il
piano di volo concordato,
cioè il piano di volo che il
velivolo dovrà effettivamente
eseguire.
Il piano di volo concordato è
quello autorizzato a valle del
processo di contrattazione
del piano di missione (nel
caso di esecuzione autonoma
di una missione; requisito
TECV2-SUBS-HAPR-00100) o
del processo di
contrattazione del piano di
volo (nel caso di esecuzione
di un piano di volo; requisito
TECV2-SUBS-HAPR-00140).
Nella modalità di esecuzione di istruzioni autopilota, l'Autonomous
Mission Manager dovrà essere in grado di ricevere istruzioni di
comando per l'autopilota.
Nella modalità di esecuzione di istruzioni autopilota, l'Autonomous
Mission Manager dovrà inoltrare le istruzioni di comando per
l'autopilota al sottosistema preposto per la loro esecuzione.
La progettazione dell'Autonomous Mission Management dovrà
essere sviluppata, laddove possibile, conformemente a standard
internazionali per lo scambio di messaggi e per la descrizione delle
informazioni in ambito aeronautico.
La progettazione dell'Autonomous Mission Management dovrà
essere sviluppata, laddove possibile, ottimizzando l'efficienza
computazionale degli algoritmi di bordo per la gestione dei dati e per
i processi di generazione del piano di volo.
52
CIRA-CF-12-0600 Rev. 1 P. 52/109
TECVOL-II
TECVOL-II - System Requirements
3.3.1.2
CIRA-CF-12-0600
Tecnologie di Adaptive Flight Control Law (AFCL)
3.3.1.2.1 Descrizione sintetica del sistema
La tecnologia relativa alle Adaptive Flight Control Law (AFCL) riguarda la capacità di effettuare il controllo d’assetto del veicolo con
caratteristiche di elevata adattavità e robustezza in termini di:
• Robustezza alle incertezze ed errori di modello
• Robustezza alle failures di sistema
• Adattività alle differenti condizioni di volo
Tale tecnologia è concepita nell’ottica del miglioramento delle capacità di esecuzione autonoma della missione e soprattutto dell’affidabilità e della
sicurezza del sistema di Guida, Navigazione e Controllo. Infatti, le capacità elencati ai punti precedenti consentono di gestire automaticamente gli
scenari off-nominal e, più in generale, la discrepanza tra le condizioni di volo previste off-line e quelle effettivamente riscontrate durante la
missione. A tale tecnologia è associato l’identificativo S07.
3.3.1.2.2 Giustificazione
I requisiti della tecnologia GNC di Adaptive Flight Control Law sono stati definiti mediante un’analisi della change AL-C9 definita nel §4 di [A1]
ed in generale della tecnologia L1-T3 (vedi Tabella 2-1 per il riepilogo delle linee tecnologiche individuate nel §5 di [A1]. La tabella che segue
sintetizza l’analisi condotta sulla suddetta tecnologia.
Rif. in [A1]]
Descrizione
L1-T3
(change ALC9)
Adaptive Flight
Control Law
Analisi
I requisiti sono stati identificati considerando lo sforzo tecnologico che deve essere prodotto per
raggiungere il livello di automazione previsto per la piattaforma di TECVOL-II. Pertanto, essi devono
essere considerati come requisiti tecnologici, ovvero come requisiti che identificano gli aspetti chiave delle
tecnologie da sviluppare per garantire l’esecuzione autonoma della missione, con specifico riferimento alla
parte di Guida, Navigazione e Controllo, ed in particolare alle leggi di controllo di basso livello.
I requisiti sono stati definiti anche sfruttando i requisiti tecnologici identificati in altri progetti CIRA,
relativi allo sviluppo di tecnologie GNC per dimostratori unmanned con elevata autonomia.
Tabella 3-3 – Analisi dei Conops [A1] per l’Adaptive Flight Control Law
3.3.1.2.3 Metodo di verifica
53
CIRA-CF-12-0600 Rev. 1 P. 53/109
TECVOL-II
TECVOL-II - System Requirements
CIRA-CF-12-0600
VM_Flight_Validation (FLARE II)
3.3.1.2.4 Requisiti di progetto
ID
TECV2-SUBS-
TECV2-SUBS-
TECV2-SUBS-
TECV2-SUBS-
AFCL-0001
AFCL-0002
AFCL-0003
AFCL-0004
Titolo
0_0.0
0_0.0
0_0.0
0_0.0
TECV2-SUBS-
AFCL-0005
0_0.0
TECV2-SUBS-
AFCL-0006
0_0.0
Descrizione
Il modulo dovrà assicurare il controllo di assetto del velivolo garantendo
Robustezza alle
prestazioni e stabilità robuste in presenza di incertezze di modello (i.e. parametri
incertezze di modello
aerodinamici, ambiente esterno, ecc.)
Il sistema dovrà garantire l'adattatività alle differenti condizioni di volo. Pertanto
le leggi di controllo dovranno adattarsi automaticamente in funzione delle
Adattività a differenti effettive condizioni di volo incontrate.
condizioni di volo
Gestione dei limiti
prestazionali
Tolleranza alle
failures e
Riconfigurabilità
Il sistema dovrà tener conto esplicitamente delle limitazioni prestazionali del
velivolo, in modo da consentire un'elevata adattività a scenari off-nominal in cui
tali caratteristiche dinamiche del velivolo possono cambiare durante il volo.
Rationale
Una tale capacità di
adattività evita l'utilizzo di
leggi di controllo preschedulate in funzione della
speciica condizione di volo.
In caso di failures, il
comportamento dinamico
del velivolo potrebbe
cambiare e i vincoli sui
limiti di performance
varierebbero di
conseguenza.
Il sistema AFCL dovrà essere robusto a failures e guasti di sistema, in particolare a
failures del sistema di attuazione e ai sensori.
Pertanto esso dovrà essere riconfigurabile, ossia cambiare i propri parametri in
presenza di condizioni off-nominal che modifichino il comportamento dinamico
del velivolo o riducano l'accuratezza delle grandezze retroazionate al sistema di
controllo.
Il sistema dovrà garantire la tolleranza almeno ad una failure singola del sistema
Tolleranza alle failure
di attuazione, ridistribuendo in maniera ottimale i comandi alle superfici
di attuatori
aerodinamiche non interessati dal guasto.
Il sistema dovrà garantire la tolleranza almeno ad una failure singola ai sensori di
Tolleranza alle failure navigazione, riconfigurandosi opportunamente, ossia cambiando alcuni
di sensori
parametri in modo da tener conto della riduzione dell' accuratezza delle
grandezze misurate.
54
CIRA-CF-12-0600 Rev. 1 P. 54/109
TECVOL-II
TECVOL-II - System Requirements
3.3.1.3
CIRA-CF-12-0600
Tecnologie per l’Integrated Health Management (IHMG)
3.3.1.3.1 Descrizione sintetica del sistema
Le tecnologie per l’Integrated Health Management (IHMG) si propongono l’obiettivo di aumentare la robustezza del sistema rispetto ai
malfunzionamenti, mediante:
• l’utilizzo di tecniche di Fault Detection and Isolation (FDI) per attuatori e sensori,
• la stima in linea dei nuovi vehicle constraints, conseguenti alla presenza della fault.
L’Integrated Health Management utilizza inoltre tecniche di identificazione in linea per aggiornare in tempo reale i parametri aerodinamici e
propulsivi del velivolo ed i disturbi ambientali sperimentati durante il volo. Quest’ultima stima in linea si riferisce dunque a parametri fisici del
velivolo e dell’ambiente in cui esso opera, mentre la stima dei vehicle constraints è relativa ad alcuni parametri critici correlati a limiti sulle
proprietà del velivolo e che consentono di definire l’inviluppo di volo nel quale il velivolo può operare in sicurezza anche in presenza di una fault
(Safe Flight Region). A tale tecnologia è associato l’identificativo S08.
3.3.1.3.2 Giustificazione
I requisiti delle tecnologie per l’Integrated Health Management sono stati definiti mediante un’analisi delle change AL-C8, AL-C10 e AL-C11
definite nel §4 di [A1] ed in generale delle tecnologie L1-T4 ed L1-T5 (vedi Tabella 2-1 per il riepilogo delle linee tecnologiche individuate nel §5
di [A1]) riguardanti lo sviluppo delle funzionalità di On Line Parameter Identification e di Failure & Health Monitoring. La tabella che segue
sintetizza l’analisi condotta sulle singole tecnologie.
Rif. in [A1]]
Descrizione
L1-T5
(change ALC8)
On-line Identification
Analisi
I moduli preposti alla generazione ed inseguimento di traiettoria richiedono in ingresso informazioni circa
le prestazioni correnti del velivolo, per evitare di definire traiettorie non realizzabili. Le prestazioni possono
essere sintetizzate in alcuni parametri caratteristici, i cui valori nominali sono noti prima del volo ma
possono variare durante la missione per varie cause (consumo carburante, avarie, rilascio di un carico). Allo
scopo di ottenere informazioni aggiornate sulle prestazioni, il modulo On-line Identification dovrà fornire
una stima in tempo reale dei parametri fisici del velivolo, principalmente parametri aerodinamici e
propulsivi (requisito TECV2-SUBS-HAPR-00070), e relativa precisione, caratterizzata in termini di bande
di incertezza rispetto al valore medio stimato (requisito TECV2-SUBS-HAPR-00090). Infine, il modulo
On-line Identification fornirà anche una stima dei disturbi ambientali locali sperimentati durante il volo
(requisito TECV2-SUBS-HAPR-00080).
55
CIRA-CF-12-0600 Rev. 1 P. 55/109
TECVOL-II
TECVOL-II - System Requirements
L1-T4
(change ALC10)
Model-based Fault
Detection and
Isolation per sensori
ed attuatori
L1-T4
(change ALC11)
Identificazione in
linea dei
malfunzionamenti
CIRA-CF-12-0600
Lo sviluppo di questa tecnologia consentirà alla piattaforma volante il conseguimento di un elevata
robustezza in ambienti non strutturati.
Il modulo di Fault Detection and Isolation ha lo scopo di monitorare lo stato dei sistemi di bordo, in
particolare di sensori ed attuatori, e di individuare ed isolare eventuali avarie (requisiti TECV2-SUBSHAPR-00010, TECV2-SUBS-HAPR-00040). I vincoli di peso, ingombro e costi del velivolo spingono
verso tecniche model-based, che riducono al minimo la ridondanza hardware (requisito TECV2-SUBSHAPR-00020).
La modellistica della fault dovrà includere anche la dinamica che caratterizza il transitorio da
funzionamento nominale a non-nominale, per consentire di testare funzionalità di prognostica (requisito
TECV2-SUBS-HAPR-00030).
Dati sperimentali saranno necessari per tarare e validare i modelli di simulazione della fault.
La caratterizzazione della fault (requisito TECV2-SUBS-HAPR-00050) sarà realizzata in linea, utilizzando
tecniche di Data Mining ed un apposito dataset di training. A partire da questo dataset si potranno applicare
off-line opportuni algoritmi di Machine Learning e Data Analysis per l’elaborazione di uno o più modelli di
classificazione dei malfunzionamenti, che saranno successivamente utilizzati on-line. Il training set dovrà,
inoltre, soddisfare le seguenti caratteristiche:
• dovrà contenere dei segnali di fault detection & isolation “etichettati” con la tipologia di failure a cui si
riferiscono;
• dovrà contenere ogni tipologia di failure;
• dovrà contenere un’elevata quantità di dati per ogni tipologia di failure.
È preferibile che i dati di training siano sperimentali e che presentino un alto numero di attributi di input. Il
dataset sarà inoltre integrato con dati generati in simulazione utilizzando i modelli citati nella change ALC10.
Oltre all’identificazione della fault, il modulo dovrà anche stimare in linea le prestazioni degradate e le
limitazioni dell’inviluppo di volo del velivolo, conseguenti ad una fault (requisito TECV2-SUBS-HAPR00060). Questi vehicle constraints saranno comunicati ai moduli preposti alla generazione ed inseguimento
della traiettoria di riferimento e al sistema di controllo, per consentire la generazione di traiettorie e di
comandi realizzabili in sicurezza dal velivolo. I vehicle constraints non saranno stimati direttamente, ma
saranno ricavati dalla misura di altri parametri ad essi relazionati e selezionati in analisi eseguite off-line.
Tabella 3-4 – Analisi dei Conops [A1] per le tecnologie di Integrated Health Management
3.3.1.3.3 Metodo di verifica
56
CIRA-CF-12-0600 Rev. 1 P. 56/109
TECVOL-II
TECVOL-II - System Requirements
CIRA-CF-12-0600
VM_Flight_Validation (FLARE II)
3.3.1.3.4 Requisiti di progetto
ID
TECV2-SUBS- IHMG-00010
_0.0
TECV2-SUBS- IHMG -00020
_0.0
TECV2-SUBS- IHMG -00030
_0.0
TECV2-SUBS- IHMG -00040
_0.0
TECV2-SUBS- IHMG -00050
_0.0
TECV2-SUBS- IHMG -00060
_0.0
TECV2-SUBS- IHMG -00070
_0.0
Titolo
Funzione di Health
Monitoring
Identificazione delle
failure
Descrizione
Rationale
Il software di bordo dovrà prevedere un modulo che si occupi della identificazione
(individuazione, isolamento e caratterizzazione) di eventuali failure.
Il modulo di Health Monitoring sarà in grado di identificare le failure di uno o più
L'utilizzo di
dispositivi di bordo (sensori e attuatori) in assenza di ridondanze HW, attraverso
metodologie modell'utilizzo di metodologie model based.
based consente di
ridurre peso, ingombro
e costi della
strumentazione di
bordo
Funzione di
Il modulo di Health Monitoring disporrà di algoritmi che dall'analisi dei dati
prognostica
provenienti dai sensori di bordo saranno in grado di prevedere l'insorgenza di una
failure.
Isolamento delle
Il modulo di Health Monitoring sarà in grado di identificare in caso di failure quale
failure
è il dispositivo malfunzionante.
Caratterizzazione delle Il modulo di Health Monitoring disporrà di algoritmi che dall'analisi dei dati
Failure
provenienti dai sensori di bordo saranno in grado di identificare la tipologia di
failure.
Vehicle Constraints
In caso di failure il modulo di Health Monitoring sarà in grado di fornire i nuovi
I range delle
range di prestazioni del velivolo.
prestazioni saranno dei
vincoli utilizzati dagli
algoritmi per la
generazione e
l'inseguimento della
traiettoria
Identificazione in linea Il modulo di Health Monitoring dovrà essere in grado di stimare in linea le
I parametri stimati in
dei parametri del
caratteristiche aerodinamiche e propulsive del velivolo al fine di valutare gli effetti linea saranno utilizzati
velivolo
di cambi di configurazione o di failure.
per aggiornare i
parametri del velivolo
utilizzati dagli algoritmi
di generazione e
l'inseguimento della
57
CIRA-CF-12-0600 Rev. 1 P. 57/109
TECVOL-II
TECVOL-II - System Requirements
CIRA-CF-12-0600
traiettoria
TECV2-SUBS- IHMG -00080
_0.0
TECV2-SUBS- IHMG -00090
_0.0
3.3.1.4
Stima in linea del
vento
Caratterizzazione delle
stime
Il modulo di Health Monitoring dovrà essere in grado di stimare in linea la
direzione e la velocità del vento in prossimità del velivolo.
Il modulo di Health Monitoring dovrà fornire oltre ai valori nominali dei parametri
stimati in linea anche una caratterizzazione delle stime, in termini di incertezza
Automatic Taxi Replanner (ATRP)
3.3.1.4.1 Descrizione sintetica del sistema
Il modulo relativo alla tecnologia GNC di Automatic Taxi Replanner (ATRP) si inquadra nell’ambito delle tecnologie per la gestione ed esecuzione
della missione, ed in particolare, riguarda la pianificazione in linea di una rotta relativa alla fase di taxiing del velivolo a partire dalla posizione di
parcheggio fino alla testata pista e viceversa. Il piano generato deve garantire il soddisfacimento dei vincoli legati sia alle limitazioni di performance
del veicolo sia alla compatibilità col sistema ATM/ATC, pertanto il sistema è concepito per aumentare le capacità di gestione autonoma della
missione e ridurre così al minimo l’intervento dell’uomo. A tale sistema è associato l’identificativo S09.
3.3.1.4.2 Giustificazione
I requisiti della tecnologia GNC di Automatic Taxi Replanner sono stati definiti mediante un’analisi della change AL-C18 definita nel §4 di [A1] ed
in generale della tecnologia L1-T2 (vedi Tabella 2-1 per il riepilogo delle linee tecnologiche individuate nel §5 di [A1]) riguardante lo sviluppo di
tecnologie per la pianificazione strategica ed esecuzione autonoma di una missione UAV. La tabella che segue sintetizza l’analisi condotta sulla
suddetta tecnologia.
Rif. in [A1]]
L1-T2
(change GSC2)
Descrizione
Automatic Taxi
Replanner
Analisi
Lo sviluppo del modulo di Automatic Taxi Replanner è utile ad innalzare le capacità di autonomia degli
UAV rispetto a quanto già sviluppato nel progetto TECVOL-I, in tal senso tale tecnologia è stata
individuata come strategica all’interno di [A1]. Inoltre, interesse per la suddetta tecnologia è stato
ampiamente espresso anche da Alenia-Aermacchi nell’ambito della collaborazione paritaria in corso tra
58
CIRA-CF-12-0600 Rev. 1 P. 58/109
TECVOL-II
TECVOL-II - System Requirements
CIRA-CF-12-0600
Alenia e Cira sull’autonomia di bordo [R43].
I requisiti di progetto per il modulo ATRP sono stati identificati prevalentemente a partire dal concetto
operativo di Autotaxi fornito da Alenia nella conference call del 17 Novembre 2011 [R46] e nella
contestuale email [R47]. I requisiti sono stati concepiti con riferimento ad una piattaforma con capacità di
volo autonomo, ma possono essere anche estese a piattaforme di tipo manned come tecnologie di ausilio al
pilota.
Tabella 3-5 – Analisi dei Conops [A1] per l’Automatic Taxi Replanner
3.3.1.4.3 Metodo di verifica
VM_Demonstration (HIL)
3.3.1.4.4 Requisiti di progetto
ID
Titolo
Descrizione
TECV2-SUBS-
ATRP-0001
0_0.0
Pianificazione di
traiettoria
Il modulo Automatic Taxi Re-Planner (ATRP), quando attivato, dovrà generare
rotta per la fase di taxiing del velivolo a partire dalla posizione corrente fino al
punto di inizio pista o all'Hangar di destinazione a seconda che la pianificazione
venga effettuata prima del decollo o dopo l'atterraggio.
TECV2-SUBS-
ATRP-0002
0_0.0
Output del modulo
ATRP
Il modulo ATRP dovrà fornire come output una rotta pianificata in termini di
Waypoint (Taxipoint) contenenti almeno la posizione, la velocità nonché, laddove
siano presenti vincoli temporali, il tempo di raggiungimento (TBC).
Rationale
TECV2-SUBS-
ATRP-0003
0_0.0
Gestione delle
limitazioni
prestazionali del
velivolo
TECV2-SUBS-
ATRP-0004
0_0.0
Gestione dei vincoli
derivanti dal sistema
ATC/ATM
Il modulo dovrà generare una rotta compatibile con i vincoli imposti dal sistema
ATC, con particolare riferimento ad aree interdette al passaggio del velivolo.
Ottimizzazione della
rotta
In caso di piattaforma
La rotta generata dal modulo ATRP dovrà essere ottimizzata rispetto ad uno o più
manned, il pilota potrebbe
criteri predefiniti ed eventualmente selezionabili dal pilota (es. minimo tempo,
optare per diverse strategie
minimo consumo, ecc.).
di ottimizzazione
TECV2-SUBS-
ATRP-0005
0_0.0
Il modulo dovrà generare una rotta compatibile con i vincoli derivanti dalle Traiettoria
percorribile
limitazioni di performance del velivolo, in particolare con la massima velocità e senza correre il rischio di un
massimo angolo di steering.
rollover
59
CIRA-CF-12-0600 Rev. 1 P. 59/109
TECVOL-II
TECV2-SUBS-
TECV2-SUBS-
TECVOL-II - System Requirements
ATRP-0006
ATRP-0007
3.3.1.5
0_0.0
0_0.0
CIRA-CF-12-0600
Il sistema dovrà tener conto
anche
dei
vincoli
provenienti da: regolamenti
Gestione delle
Il modulo dovrà tener conto delle informazioni contenute in un database
aeroportuali, regole di
informazioni
(disponibile a bordo) e riguardanti i vincoli legati dall'aeroporto in cui il taxi viene
concernenti gli
utilizzo
della
pista,
effettuato. Tali informazioni dovranno essere codificate in opportuni vincoli per il
taxiways,
aree
di
aeroporti di partenza
modulo ATRP.
parcheggio
e
docking
ed arrivo
nonché la presenza di
ostacoli fissi
Input del modulo
ATRP
Il modulo ATRP dovrà ricevere lo stato corrente del velivolo, in termini di
posizione e velocità, i parametri del velivolo (limitazioni prestazionali), vincoli
derivanti dall'aeroporto e dalle piste utilizzabili per il taxiing (vedi requisito
precedente) e la destinazione finale (testata pista o hangar a seconda che la
pianificazione venga effettuata prima del decollo o dopo l'atterraggio).
Tecnologie per l’Automatic Taxi Management (ATMA)
3.3.1.5.1 Descrizione sintetica del sistema
La tecnologia di Automatic Taxi Management (ATMA) dovrà permettere al velivolo su pista di gestire in modo automatico tutta la fase di taxiing
precedente al decollo e successiva all’atterraggio. A tale tecnologia è associato l’identificativo S10.
3.3.1.5.2 Giustificazione
I requisiti della tecnologia GNC di Automatic Taxi Management sono stati definiti mediante un’analisi della change AL-C5 definita nel §4 di [A1]
ed in generale della tecnologia L1-T2 (vedi Tabella 2-1 per il riepilogo delle linee tecnologiche individuate nel §5 di [A1]) riguardante lo sviluppo
di tecnologie per la pianificazione strategica ed esecuzione autonoma di una missione UAV. La tecnologia di Automatic Taxi Management sarà
sviluppata appunto allo scopo di ampliare la capacità di gestione ed esecuzione autonoma della missione di un UAV anche nelle fasi di taxing. Tale
tecnologia sarà naturalmente accoppiata a quella di Automatic Taxi Replanner (ATRP). Il modulo basato sulla tecnologia ATRP infatti fornirà gli
opportuni ingressi (lista di way point da seguire sui percorsi aeroportuali) al modulo basato sulla tecnologia ATMA.
3.3.1.5.3 Metodo di verifica
60
CIRA-CF-12-0600 Rev. 1 P. 60/109
TECVOL-II
TECVOL-II - System Requirements
CIRA-CF-12-0600
VM_Flight_Validation (FLARE II)
3.3.1.5.4 Requisiti di progetto
ID
TECV2-SUBS-
ATMA-0001
3.3.2
Titolo
0_0.0
Descrizione
Rationale
Il modulo basato sulla tecnologia ATMA dovrà processare in input un set di
waypoint (taxipoint) caratterizzanti la rotta da compiere a partire dall’hangar
fino alla testata pista e viceversa. Il modulo dovrà quindi generare in linea una
traiettoria che consenta al velivolo di effettuare il taxiing previsto dal set di
Gestione ed
waypoint caratterizzante la rotta desiderata in maniera automatica e nel
esecuzione automtica
rispetto dei vincoli legati sia alle limitazioni di performance del velivolo su pista
della fase di Taxing
sia alla compatibilità col sistema ATM/ATC. Inoltre, il sistema dovrà anche
provvedere all’esecuzione automatica della fase di taxing attraverso la
generazione di riferimenti di posizione e velocità per i moduli di guida e
controllo di basso livello in modo da inseguire la traiettoria generata.
HMI and Payload management
Questa classe racchiude sia le tecnologie relative alla gestione del payload nell’ambito del segmento di bordo di un UAV, ed in particolare la
tecnologia di Automatic Target Detection and Recognition, sia lo sviluppo di tecnologie innovative per il segmento di terra orientate al supporto
all’operatore di terra per la pianificazione strategica di una missione, in modo parzialmente o completamente automatizzato.
3.3.2.1
Preflight Support Mission Planner (PSMP)
3.3.2.1.1 Descrizione sintetica del sistema
Il sistema di pianificazione di missione di UAV si presenta orientato alla pianificazione in base ai vincoli e ai requisiti della missione, coinvolgendo
nella determinazione del percorso da far effettuare al velivolo tutta una serie di parametri e di verifiche incrociate, e iterative, legati a elementi
eterogenei (gli obiettivi della missione, i sensori, in particolare di imaging, con le loro capacità di acquisizione, il velivolo in termini di prestazioni e
consumo, i datalink e la relativa copertura rispetto all’inviluppo di volo) uniti alle regole delle procedure operative ordinarie e di emergenza.
61
CIRA-CF-12-0600 Rev. 1 P. 61/109
TECVOL-II
TECVOL-II - System Requirements
CIRA-CF-12-0600
Il sistema dovrà offrire un’inedita possibilità di input e selezione da database di configurazioni di sensori, mappe di copertura di datalink, e si servirà
di un motore di analisi della traiettoria che incrocerà le informazioni disponibili (dati sensori, prestazioni velivolo, ecc.) con i vincoli delle risorse
(datalink, carburante, ecc.) ed i vincoli esterni (es. no-fly zone) per validare o fornire indicazioni di riprogettazione del piano di volo per incontrare i
requisiti della missione. A tale sistema è associato l’identificativo S11.
3.3.2.1.2 Giustificazione
I requisiti di tecnologie relative ai Preflight Support Mission Planner sono stati definiti mediante un’analisi della change GS-C2 definita nel §4 di
[A1] ed in generale delle tecnologie L3-T1 ed L3-T3 (vedi Tabella 2-1 per il riepilogo delle linee tecnologiche individuate nel §5 di [A1])
riguardanti lo sviluppo di tecnologie per HMI ed in particolare dello sviluppo di un Mission Planner. La tabella che segue sintetizza l’analisi
condotta sulle singole tecnologie.
Rif. in [A1]]
L3-T1
(change GSC2)
Descrizione
Mission Planner
Analisi
L’esigenza di realizzare un nuovo Pianificatore di Missione più orientato ai sensori, al contesto operativo
ed agli obiettivi di missione rispetto a quanto già sviluppato nel progetto TECVOL-I è già stata descritta in
forma esaustiva nel paragrafo 5.3.3.1 [A1].
In aggiunta ai contenuti del documento sopra menzionato è da evidenziare l’interesse espresso da AleniaAermacchi, nei diversi incontri avuti anche su questo argomento, che hanno portato ad una collaborazione
paritaria tra CIRA ed Alenia Aermacchi [R43].
Come preliminary user requirements Alenia-Aermacchi ha fornito alcuni dettagli sulle funzioni richieste al
software di pianificazione della missione insieme a elementi architetturali di dettaglio [R45].
Tabella 3-6 – Analisi dei Conops [A1] per il Preflight Support Mission Planner
3.3.2.1.3 Metodo di verifica
VM_Demonstration (HIL)
3.3.2.1.4 Requisiti di progetto
62
CIRA-CF-12-0600 Rev. 1 P. 62/109
TECVOL-II
TECVOL-II - System Requirements
ID
TECV2-SUBS-
PSMP-0001
Titolo
0_0.0
CIRA-CF-12-0600
Descrizione
Pianificatore di
Missione
Il PSMP (Preflight Support Mission Planner) deve assistere l'operatore in tutte le
fasi di creazione/modifica di una missione di volo per un UAV, con la regola che,
per gli attributi per cui è possibile restringere i possibili valori, deve essere fornita
la possibilità di scegliere i dati da una lista preconfigurata invece di doverli inserire
ogni volta.
TECV2-SUBS-
PSMP-0002
0_0.0
Gestione Mappe
Il PSMP deve fornire la possibilità di gestire diverse tipologie di mappe e per
ognuna di esse deve fornire la possibilità di utilizzare le funzioni di Zoom e di Scroll
dinamico, oltre alla possibilità di centrare la vista su una determinata coordinata
geografica.
TECV2-SUBS-
PSMP-0003
0_0.0
Gestione Spazi Aerei
su Mappe ICAO
Il PSMP deve fornire la possibilità di utilizzare le mappe della ICAO per
l'individuazione degli spazi aerei, delle aerovie e di tutte le stazioni e riferimenti
comuni alle mappe aeronautiche standard.
Gestione Anagrafiche
Il PSMP deve fornire la possibilità di gestire le seguenti anagrafiche di riferimento
con l'obiettivo di facilitare l'operatore durante la generazione di un piano di
missione:
1. target (validità temporale);
2. no-fly zone (validità temporale);
3. safe area (validità temporale);
4. velivoli;
5. mappe/immagini;
6. rotte standard;
7. user waypoint;
8. payload;
9. stazioni data link;
10. tipologie pattern (sequenze prestabilite di waypoint);
11. emergency route;
12. termination route.
Per gestione di un'anagrafica si intende la possibilità per l'operatore di inserire un
nuovo valore (record) nell'anagrafica, modificare un record presente
nell'anagrafica, eliminare permanentemente un record presente nell'anagrafica.
Questa funzione deve prevedere un pannellino attraverso il quale sia possibile
scegliere l'elemento che si desidera configurare per poi passare alla form per
l'inserimento dei dati.
TECV2-SUBS-
PSMP-0004
0_0.0
Rationale
63
CIRA-CF-12-0600 Rev. 1 P. 63/109
TECVOL-II
TECV2-SUBS-
TECVOL-II - System Requirements
PSMP-0005
0_0.0
TECV2-SUBS-
PSMP-0006
0_0.0
TECV2-SUBS-
PSMP-0007
0_0.0
TECV2-SUBS-
PSMP-0008
0_0.0
Configurazione
Missione
CIRA-CF-12-0600
Il PSMP deve fornire la possibilità di definire la configurazione di base della
missione, attraverso un'apposita form contente tutti gli attributi necessari alla
definizione della configurazione di una missione. I principali attributi sono
rappresentati da:
- velivolo;
- payload sensoristico (ovvero sensori da imbarcare sul velivolo);
- carburante da impiegare durante la missione;
- data e orario della missione;
- tipologia missione (in zona segregata con relativa selezione dell'area interessata,
oppure in zona non segregata);
- stazione data link da impiegare durante la missione;
- inserimento dei target di interesse durante la missione.
La costruzione della rotta che il velivolo UAV deve seguire durante la missione
deve avvenire attraverso l'inserimento di waypoint successivi, durante
Definizione della rotta
l'inserimento è sempre possibile aggiunger un waypoint tra due waypoint
esistenti.
All'inserimento di un waypoint il PSMP deve compiere diverse verifiche di
validazione e di accettazione del waypoint:
- raggiungibilità in funzione delle prestazioni del velivolo;
- copertura datalink;
Verifica waypoint
- attraversamento no-fly zone;
- consumo carburante;
- visibilità dei target.
Inserimento
Emergency Route
L'inserimento di una Emergency Route durante la pianificazione di una missione è
opzionale e consiste nello sceglierne una tra quelle disponibili e già configurate,
che inizia dall'ultimo waypoint inserito e finisce in un loiter dove si presume sia
possibile ristabilire la connessione del velivolo con la stazione di terra. L'obiettivo
di una Emergency Route è proprio il recupero della connettività del velivolo con la
stazione di controllo a terra.
TECV2-SUBS-
PSMP-0009
0_0.0
Inserimento
Termination Route
L'inserimento di una Termination Route durante la pianificazione di una missione
è opzionale e consiste nello sceglierne una tra quelle disponibili e già configurate,
che inizia dal loiter di una Emergency Route e termina con l'atterraggio di
emergenza del velivolo (safe crash) in un'area prestabilita.
TECV2-SUBS-
PSMP-0010
0_0.0
Footprint Sensore
Il PSMP deve essere in grado di evidenziare sulla mappa il footprint del sensore
prescelto con un'indicazione della qualità dell'immagine prevista.
64
CIRA-CF-12-0600 Rev. 1 P. 64/109
TECVOL-II
TECV2-SUBS-
TECV2-SUBS-
TECV2-SUBS-
TECVOL-II - System Requirements
PSMP-0011
PSMP-0012
PSMP-0013
3.3.2.2
CIRA-CF-12-0600
Apertura, Modifica,
Eliminazione Missioni
Deve essere possibile aprire o anche eliminare una missione preesistente
selezionandola da un elenco delle missioni già inserite, ordinate dalla più recente
alla meno recente. Il sistema, prima dell'eliminazione definitiva della missione,
deve chiedere conferma all'operatore.
Il PSMP deve fornire la possibilità di modificare i waypoint che compongono la
rotta appartenente alla missione in uso, consentendo all'operatore di modificare
gli attributi di un waypoint e/o modificare l'ordine di un waypoint lungo la rotta
e/o eliminare un waypoint dalla rotta. A seguito di una modifica di un waypoint, il
sistema deve attivare tutte le verifiche necessarie alla validazione dello stesso
waypoint.
0_0.0
Esportazione Dati
Missione
Il PSMP deve fornire la possibilità all'operatore di esportare i dati di missione,
quelli di configurazione e quelli della rotta (lista di waypoint e di leg) in formato
elettronico standard (come previsto dalla modulistica ICAO per le autorizzazione
dei piani di volo) di una missione di volo selezionata da un elenco delle missioni
già inserite, ordinate dalla più recente alla meno recente.
0_0.0
Esportazione Dati
Missione per TCS
Il PSMP deve fornire la possibilità all'operatore di esportare i dati di missione
richiesti dalla TCS relativi ad una missione di volo selezionata da un elenco delle
missioni già inserite, ordinate dalla più recente alla meno recente.
0_0.0
Preflight Automatic Mission Planner (PAMP)
Per soddisfare i requisiti definiti nel paragrafo precedente relativi al Pre-flight Support Mission Planner sarà individuato uno specifico tool SW
commerciale adatto a sviluppare le funzionalità previste dai requisiti sopra definiti. Il tool individuato dovrà dare enfasi alla parte di
sensoristica/datalink tipici di una missione UAV, includendo funzioni di pianificazione ma senza possibilità di includere mappe cartografiche
(rappresentazione grafica attive) dei dati rilevabili aeronautici (espressi potenzialmente in uno specifico standard come ad es. l’ARINC424).
L’obiettivo principale della tecnologia di Preflight Automatic Mission Planner è quello di riuscire ad avere a disposizione un tool commerciale
aperto ed integrabile con servizi proprietari del CIRA che permetta di progettare un dispositivo grafico (Preflight Automatic Mission Planner) che
sia di ausilio al pilota nel definire il piano di volo e relativa traiettoria secondo logiche di ottimizzazione, dove però gli engine di ottimizzazione
siano definiti e progettati internamente in modo coerente con quanto già avviene nel SW di ripianificazione di bordo attualmente sviluppato
nell’ambito del progetto MISE. A tale sistema è associato l’identificativo S12.
65
CIRA-CF-12-0600 Rev. 1 P. 65/109
TECVOL-II
TECVOL-II - System Requirements
ID
TECV2-SUBS-
Titolo
PAMP-0001 0_0.0
3.3.2.3
Automatic Mission
Planner
CIRA-CF-12-0600
Descrizione
Rationale
Il PAMP (Preflight Automatic Mission Planner) deve assistere l'operatore in tutte
le fasi di creazione/modifica di una missione di volo per un UAV, sulla base di
mapper cartografiche della area di operazioni e secondo logiche di ottimizzazione
definibili dall’utente.
Automatic Target Detection and Recognition System (ATDR)
3.3.2.3.1 Descrizione sintetica del sistema
Con lo scopo di estendere la capacità di autonomia del velivolo durante lo svolgimento della missione, sarà sviluppato il sistema di Automatic
Target Detection and Recognition (ATDR), che implementerà la funzione di rilevamento e riconoscimento automatico di target on ground, dotando
il velivolo di un opportuno payload di sensori (telecamere nel visibile e infrarosso termico). Il sistema di ATDR dovrà individuare i possibili
obiettivi di interesse per la missione, classificarli secondo categorie predefinite, a cui eventualmente associare anche una diversa priorità di
osservazione, e quindi tracciarli in modo autonomo oppure evidenziarli ad un operatore remoto, che deciderà se e quali obbiettivi debbano essere
inseguiti dal velivolo. A tale sistema è associato l’identificativo S13.
3.3.2.3.2 Giustificazione
I requisiti di progetto relativi all’Automatic Target Detection and Recognition System sono stati definiti mediante un’analisi della change AL-C14
definita nel §4 di [A1] ed in generale della tecnologia L2-T4 (vedi Tabella 2-1 per il riepilogo delle linee tecnologiche individuate nel §5 di [A1]).
La tabella che segue sintetizza l’analisi condotta sulle singole tecnologie.
Rif. in [A1]]
Descrizione
L2-T4,
(change ALC14)
Automatic Target
Detection and
Recognition
Analisi
Nell’ambito del progetto TECVOL-II, nel considerare le funzioni svolte a bordo di un UAV (che vanno nella
direzione di aumentarne l’autonomia) è maturata l’idea di interessarsi anche alle funzioni applicative legate al
payload sensoristico il cui utilizzo costituisce, nella maggioranza dei casi, lo scopo primario di una missione
UAV. Aumentare il livello di automazione delle funzionalità del payload consente infatti l’accrescimento
dell’autonomia e della capacità decisionale dell’intero sistema velivolo, soprattutto perché la guida risulta in
alcune fasi asservita alle indicazioni delle funzioni applicative di missione.
66
CIRA-CF-12-0600 Rev. 1 P. 66/109
TECVOL-II
L2-T5
TECVOL-II - System Requirements
SAR-based
surveillance
CIRA-CF-12-0600
Le missioni di sorveglianza sono da annoverare tra quelle più comunemente svolte da UAV per finalità di
monitoraggio ambientale, di sicurezza sociale e sorveglianza militare, a scopo soprattutto preventivo. In
questo ambito la funzione di inseguimento (tracking) di un target a terra, soprattutto se in movimento,
rappresenta quella che meglio esemplifica la variabilità della destinazione di un velivolo in funzione di
indicazioni acquisite durante la missione stessa.
Nel caso di un velivolo unmanned, tra gli scenari operativi usuali, si può considerare quello in cui un
operatore nella GCS, analizzando visivamente le immagini e i dati acquisiti dai sensori di missione di bordo,
indica al sistema a bordo il target da inseguire, identificando ad esempio una region of interest che contiene il
target. Ciò richiede la disponibilità di sistemi di trasmissione dati bordo-terra a sufficiente throughput e
contenuta latenza, non sempre ipotizzabile nelle lunghe distanze (datalink BLOS) o in circostanze operative
difficili e/o avverse. Si è deciso così di investigare su uno scenario operativo che richiedesse un superiore
livello di autonomia e prevedesse una operatività maggiormente indipendente da una continua interazione per
la validazione con gli operatori a terra richiedendo, di contro, una maggiore capacità di analisi dei dati e di
capacità decisionali del sistema. Queste sono le premesse da cui è nata l’idea di focalizzarsi sullo studio e lo
sviluppo di un sistema Automatic Target Recognition, che fosse in grado di migliorare l’autonomia nelle
missione più usuali per un velivolo UAV (individuazioni di target sensibili) e che fosse in grado, a partire da
immagini di riferimento per i target cercati, di svolgere in autonomia il compito della detection e del
riconoscimento di tali target attraverso l’utilizzo dei payload sensoristici tipici per un velivolo unamnned
(sensori EO/IR).
Per verificare la bontà di tale scelta, è stato ritenuto opportuno confrontarsi anche con l’industria nazionale,
richiedendo ad Alenia-Aermacchi, con la quale è in corso una proficua collaborazione sui sistemi autonomi
[R43], di esprimere il proprio interesse per tale tecnologia. Nel corso del meeting dello scorso 21 Marzo
[R44], l’Alenia ha espresso al CIRA il proprio interesse nello sviluppo di una serie di funzioni che, sfruttando
le caratteristiche di un’immagine (fusa da più sensori), forniscano una serie di dati, tra cui il riconoscimento
del target di interesse (classe di oggetto).
A valle di tali richieste, il CIRA ha avviato uno studio preliminare [R48] in cui sono stati definiti i project
requirements di seguito riportati che verranno a breve sottoposti ad Alenia per un ulteriore confronto sullo
sviluppo di questa tecnologia.
Per quanto riguarda il possibile utilizzo dei sensori SAR in sostituzione e/o in aggiunta ai sensori EO/IR sarà
svolto uno studio di fattibilità sulla possibilità di integrare il sistema di Automatic Target Detection and
Recognition con il SAR.
Tabella 3-7 – Analisi dei Conops [A1] per l’Automatic Target Detection and Recognition System
67
CIRA-CF-12-0600 Rev. 1 P. 67/109
TECVOL-II
TECVOL-II - System Requirements
CIRA-CF-12-0600
3.3.2.3.3 Metodo di verifica
VM_Flight_Validation (FLARE II)
3.3.2.3.4 Requisiti di progetto
ID
Titolo
Descrizione
TECV2-SUBS-
ATDR-0001
0_0.0
Automatic Target
Detect & Recognition
Il sistema di Automatic Target Detection & Recognition dovrà svolgere le
funzionalità di Automatic Target Detection e Automatic Target Recognition.
TECV2-SUBS-
ATDR-0002
0_0.0
Funzionalità di
Automatic Target
Detection
La funzionalità di Target Detection individua, all'interno di un'immagine acquisita
dai sensore, le ROI (region of interest) all'interno delle quali è localizzato un
target.
La funzionalità di Target Recognition stabilisce a quale classe di riferimento
appartengono i target individuati.
TECV2-SUBS-
ATDR-0003
0_0.0
Funzionalità di
Automatic Target
Recognition
TECV2-SUBS-
ATDR-0004
0_0.0
Robustezza
Il sistema ATDR dovrà riconoscere automaticamente i target presenti in
un'immagine, in maniera indipendente dalle loro caratteristiche di dimensioni ed
orientamento nel piano immagine, colore, punto di osservazione.
Dotazione HW
Il sistema ATDR si baserà sulla seguente dotazione HW:
1) L'unità di elaborazione su cui è installato l'applicativo software di ATR ed i dati
necessari al suo funzionamento
2) L'interfaccia di acquisizione dei sensori di imaging
3) I sensori di imaging
Installabilità
Il sistema ATDR dovrà essere progettato per poter essere installato su un sistema
UAS (velivoli di tipo UAV/UCAV e relativa GCS/TCS). Il sistema, per quanto
progettato per aumentare l'autonomia dei velivoli unmanned, dovrà comunque
potere essere installato anche su velivoli manned.
TECV2-SUBS-
TECV2-SUBS-
ATDR-0005
ATDR-0006
0_0.0
0_0.0
Rationale
68
CIRA-CF-12-0600 Rev. 1 P. 68/109
TECVOL-II
TECVOL-II - System Requirements
TECV2-SUBS-
ATDR-0007
0_0.0
Sensori di visione del
sistema ATR
TECV2-SUBS-
ATDR-0008
0_0.0
Posizione sensori
TECV2-SUBS-
ATDR-0009
0_0.0
Classi di target
CIRA-CF-12-0600
La scelta dell'utilizzo di
sensori di tipo EO/IR, è
dovuta
alla
loro
universale presenza in
tutti
i
payload
sensoristici
di
tipo
aeronautico. Per quanto
Il sistema ATDR si baserà su l'utilizzo di sensori EO/IR (electro-optical infrared riguarda il possibile
sensor) composto da una telecamera nel visibile (Daylight camera) ed una utilizzo dei sensori SAR
in sostituzione e/o in
telecamera nell’infrarosso termico.
aggiunta ai sensori EO/IR
sarà svolto uno studio di
fattibilità sulla possibilità
di integrare il sistema di
Automatic
Target
Detection
and
Recognition con il SAR.
SI presuppone che i sensori EO/IR siano installati all'interno di una torretta
brandeggiata e stabilizzata, montata sul velivolo in modo da potere effettuare
riprese nadirali
Dalla letteratura, si
evince che i veicoli a
Il sistema ATDR dovrà permettere la detection ed il riconoscimento di mezzi in
terra rappresentano i
movimento sulla superficie terrestre ed in mare dotati di motore termico (auto,
target
di
maggiore
moto, mezzi militari, autobus, navi, barche).
interesse per le missioni
UCAV/UAV.
69
CIRA-CF-12-0600 Rev. 1 P. 69/109
TECVOL-II
TECV2-SUBS-
TECVOL-II - System Requirements
ATDR-0010
0_0.0
Database signature
termiche
CIRA-CF-12-0600
Il
database
delle
signature rappresenta la
conoscenza a priori da
parte del sistema dei
target da individuare e
riconoscere. Il ricorso a
sensor
Il sistema ATDR si baserà (tra l'altro) sull'utilizzo di un database delle signature sistemi
nella banda termica e nel visibile dei target che si vogliono riconoscere. Tale simulation, rappresenta
alternativa
database dovrà essere acquisito, ove disponibile, o creato attraverso sistemi di l'unica
"sensor simulation".
possibile per sopperire
alla difficoltà di ottenere
da enti esterni, per
motivi di riservatezza,
database significativi di
signature termiche di
veicoli.
Il sistema ATDR dovrà fornire, attraverso il datalink di servizio della piattaforma
UAS, i risultati all'operatore nella GCS che potrà valutare ed eventualmente
modificare/annullare i target rilevati dal sistema o aggiungere eventuali target
non rilevati.
TECV2-SUBS-
ATDR-0011
0_0.0
MMI
TECV2-SUBS-
ATDR-0012
0_0.0
Interoperabilità ISM
Il sistema verrà progettato per potersi integrare con il sistema ISM (progetto (in
particolare
del
MISE) , al fine di estenderne le funzionalità e sfruttarne (se disponibili) le sistema di tracking dell’
peculiarità.
ISM [R49])
Il sistema ATDR dovrà funzionare sia con che senza l'interazione con l'operatore in
TCS.
Le prestazioni del sistema ATDR, in mancanza di interazione con la TCS,
risulteranno degradate, in quanto l'operatore non sarà in grado nè di eliminare
eventuali falsi allarmi né di integrate eventuali mancate rilevazioni del sistema.
TECV2-SUBS-
ATDR-0013
0_0.0
Funzionamento in
modalità
supervisionata e non
supervisionata
TECV2-SUBS-
ATDR-0014
0_0.0
Prestazioni in
modalità non
supervisionata
3.3.3
Datalink
In questa classe sono comprese tutte le tecnologie per la ricerca e sviluppo di datalink innovativi sia per comunicazioni LOS che BLOS.
70
CIRA-CF-12-0600 Rev. 1 P. 70/109
TECVOL-II
TECVOL-II - System Requirements
3.3.3.1
CIRA-CF-12-0600
Tecnologie relative ai Reconfigurable Datalink (DTLK)
3.3.3.1.1 Descrizione sintetica del sistema
Le sfide attuali e future nel settore delle comunicazioni aeronautiche per velivoli UAV riguardano:
•
l’ottimizzazione delle tecniche di trasmissione e delle risorse disponibili, in termini di banda impiegata e potenza irradiata, in funzione delle
quantità di informazioni da trasmettere e delle condizioni, più o meno avverse, presentate dal canale trasmissivo;
•
la possibilità di poter comunicare impiegando modalità di comunicazione diverse in modo da garantire l’operabilità con differenti infrastrutture
di terra e/o satellitari;
•
la robustezza nei confronti di segnali interferenti casuali, in modo da contrastare la crescente congestione nell’utilizzo di risorse frequenziali, o
appositamente generati (jamming).
Una risposta a tali sfide può essere data, seppur con efficacia diversa a seconda dell’obiettivo dell’elenco precedente da perseguire, mediante lo
sviluppo di tecnologie innovative per l’implementazione di un Reconfigurable Datalink (RDL), ovvero un datalink in cui sia possibile, cambiando il
software associato al processing dei segnali in banda base e senza apportare modifiche all’hardware, variare le funzioni per le comunicazioni messe
a disposizione dell’utente.
Inoltre, per predire e/o testare le performance di un sistema di comunicazione è necessario avere, in fase di progettazione, dei modelli capaci di
simulare il segmento trasmittente, il canale di propagazione e il segmento ricevente. In particolare, il Simulatore di Canale Radio (SCR), è uno
strumento in grado di riprodurre, una volta specificato il contesto ambientale in esame, il deterioramento che il segnale subisce durante la
propagazione. I fenomeni da modellare sono: l’attenuazione da spazio libero, il multipath fading, la presenza di rumore e di segnali interferenti.
Considerato che il principale ambito d’impiego sarà quello delle comunicazioni aeronautiche, il simulatore di canale dovrà tener conto del fatto che
il segmento trasmittente e quello ricevente non hanno una posizione fissa e costante nel tempo. A tale sistema è associato l’identificativo S14.
3.3.3.1.2 Giustificazione
I requisiti relativi ai Reconfigurable Datalink sono stati definiti mediante un’analisi della change AV-C1 definita nel §4 di [A1] ed in generale della
tecnologia L4-T1 (vedi Tabella 2-1 per il riepilogo delle linee tecnologiche individuate nel §5 di [A1]). La tabella che segue sintetizza l’analisi
condotta su tale tecnologia.
Rif. in [A1]]
Descrizione
Analisi
71
CIRA-CF-12-0600 Rev. 1 P. 71/109
TECVOL-II
L4-T1
(change AVC1)
TECVOL-II - System Requirements
Reconfigurable
Datalink
CIRA-CF-12-0600
I Concept of Operations di TECVOL II e le successive indagini sugli aspetti comunicativi relativi alle
funzionalità di Handover e Multicrew e di controllo di sistemi Multiship, effettuate nei documenti [R35] e
[R36], hanno messo in evidenza i requisiti funzionali che i dispositivi base di un datalink devono possedere
onde implementare le suddette funzionalità, riassumibili sinteticamente in: riconfigurabilità, affidabilità,
integrità del segnale e sicurezza, interoperabilità con standard diversi, capacità di gestire comunicazioni di
tipo BLOS. La spinta ad investire sull’integrità del segnale e sulla sicurezza nelle comunicazioni radio per
UAV è evidenziata con forza anche in [R37]. Inoltre, la road-map delle comunicazioni dei sistemi
unmanned illustrata in [R2] richiede, in aggiunta alle caratteristiche precedenti, la capacità di adattamento
alla quantità di informazioni da trasmettere ed alle condizioni offerte dal contesto radio. I riferimenti
[R38],[R39] e [R40] mostrano, poi, come, per diversi scenari applicativi, la possibilità di variare le funzioni
per le comunicazioni messe a disposizione dell’utente, cambiando il software associato al processing dei
segnali in banda base e senza apportare modifiche all’hardware, sia la strada vincente da perseguire, strada
capace di rispondere in maniera flessibile alle esigenze delle caratteristiche funzionali citate.
Infine, gli studi effettuati nei riferimenti [R41] e [R42] dimostrano che nell’ambito delle comunicazioni
aereonautiche è possibile schematizzare il fenomeno del multipath fading con un raggio diretto (antennavelivolo) e uno o al più due raggi riflessi. Di conseguenza, si è deciso di affrontare il problema della
modellizzazione geometrica della zona di volo e, per questa via, si è giunti alla definizione dei requisiti che
un simulatore di canale radio dovrebbe soddisfare.
Tabella 3-8 – Analisi dei Conops [A1] per le tecnologie di Reconfigurable Datalink
3.3.3.1.3 Metodo di verifica
VM_Demonstration (HIL)
3.3.3.1.4 Requisiti di progetto
ID
TECV2-SUBS- DTLK-0001
0_0.0
Titolo
Riconfigurabilità del
datalink
Descrizione
Il Datalink dovrà essere riconfigurabile, ovvero dovrà essere possibile cambiare le
tecniche di modulazione/demodulazione, codifica/decodifica di canale e
crittografia impiegate per la trasmissione delle informazioni, adattandole alle
caratteristiche del canale radio.
Rationale
72
CIRA-CF-12-0600 Rev. 1 P. 72/109
TECVOL-II
TECVOL-II - System Requirements
CIRA-CF-12-0600
TECV2-SUBS- DTLK-0002
0_0.0
Sicurezza ed integrità
del segnale
Il Datalink dovrà utilizzare tecniche tali da garantire la sicurezza e l'integrità del
segnale nei confronti di disturbi casuali e/o generati ad hoc e la robustezza nei
confronti del multipath fading.
TECV2-SUBS- DTLK-0003
0_0.0
Comunicazione BLOS
Il Datalink dovrà consentire lo scambio di informazioni tra la Ground Control
Station ed il velivolo anche nel caso in cui quest'ultimo si trovi in condizioni di
BLOS rispetto alla stazione di terra.
TECV2-SUBS- DTLK-0004
0_0.0
Approccio modelbased
L'approccio alla progettazione del Datalink dovrà essere di tipo model-based,
ovvero il Datalink dovrà essere fornito di un opportuno modello che consenta la
simulazione del segmento trasmittente e del segmento ricevente ai fini di
valutarne e/o predirne le perfomance.
TECV2-SUBS- DTLK-0005
0_0.0
Simulazione del
canale radio di
propagazione
Il modello del Datalink dovrà includere il canale radio di propagazione;
quest'ultimo dovrà essere quanto più fedele possibile alla realtà permettendo di
simulare i tipici deterioramenti introdotti dalla propagazione del segnale:
attenuazione da spazio libero, multipath fading, presenza di rumore e segnali
interferenti.
TECV2-SUBS- DTLK-0006
0_0.0
Dinamica del canale
radio
Poiché il principale ambito d’impiego sarà quello delle comunicazioni
aeronautiche, nelle simulazioni associate al Datalink, in particolare al canale radio
di propagazione, si dovrà tener conto del fatto che il segmento trasmittente e
quello ricevente non hanno una posizione fissa e costante nel tempo ma possono
essere in movimento, anche simultaneamente.
TECV2-SUBS- DTLK-0007
0_0.0
Ambiente software di
simulazione
Il modello del Datalink, inclusivo del canale radio di propagazione, dovrà essere
impiegato e simulato in ambiente Matlab – Simulink.
3.3.3.2
Tecnologie relative ai Datalink satellitari
Nell’ambito dei Datalink satellitari sarà svolto uno studio di fattibilità volto:
1. alla valutazione delle possibili costellazioni di satelliti adoperabili nell’ambito delle comunicazioni per UAV, focalizzando l’attenzione sui
throughput, sulle bande disponibili e sui tempi di latenza;
2. alla definizione di una possibile architettura funzionale per l’implementazione di un datalink in grado di gestire comunicazioni di tipo LOS e di
tipo BLOS adoperanti sistemi satellitari.
73
CIRA-CF-12-0600 Rev. 1 P. 73/109
TECVOL-II
TECVOL-II - System Requirements
CIRA-CF-12-0600
3.4 Sistemi avanzati di ausilio al pilotaggio per velivoli manned PATS
Nonostante le linee tecnologiche definite nei Conops si riferiscono principalmente agli UAS, nella categoria oggetto di questo paragrafo sono stati
individuati quei sistemi avanzati di ausilio al pilotaggio per velivoli manned che potevano essere sviluppati sfruttando gli stessi concetti algoritmici
già definiti in [A1]. L’opportunità progettuale di questa scelta è stata già affrontata nel §2.2 e tutti i paragrafi di giustificazione dei successivi sistemi
individuati sono da intendersi, laddove necessario, solo come integrazione del suddetto paragrafo. Le classi facenti parte di questa categoria sono
quelle relative all’accrescimento della consapevolezza del pilota sull’ambiente circostante (Situational Awareness Systems) e quelle relative alle
funzioni di volo automatico avanzate a supporto del pilota (Systems for Automatic Flight).
3.4.1
Situational Awareness Systems
3.4.1.1
Weather Situational Awareness System (WSAS)
3.4.1.1.1 Descrizione sintetica del sistema
Lo sviluppo di un sistema di weather awareness nell’ambito del progetto ha lo scopo di introdurre, per gli UAV e per i velivoli general aviation di
piccole dimensioni, un sottosistema che sia in grado, attraverso diverse funzionalità, di supportare il pilota (sia esso realmente presente sul velivolo
o no) e il sistema di pianificazione e controllo del volo qualora ci si trovi in prossimità di situazioni meteorologiche avverse. Tale sottosistema deve
prevalentemente consentire il monitoraggio e, laddove sia possibile, la previsione su diversi range temporali e nelle diverse fasi di volo, degli hazard
atmosferici. Questi ultimi rappresentano quei fenomeni meteorologici che hanno un qualche impatto sia sulla sicurezza del volo che sulla sua
efficienza. Tali fenomeni sono molteplici e la loro pericolosità varia con le caratteristiche del velivolo e con le varie fasi di volo (es. crociera,
atterraggio, taxing ect.).
Passo preliminare alla definizione di dettaglio di un sistema deputato al monitoraggio ed alle previsioni a breve termine di supporto alle decisioni
del pilota, è quello dell’identificazione dello stato dell’arte sulle informazioni meteo disponibili attraverso servizi basati su osservazioni satellitari,
su osservazioni a terra e osservazioni a bordo, nonché nell’identificazione di una modalità previsionale a breve termine (nowcasting) basata sui dati
osservati.
Lo studio dello stato dell’arte è in corso ed ha messo in evidenza come, sia per il monitoraggio che per la previsione di tali fenomeni, sia necessario
integrare diverse tipologie di sensori di misura esistenti, ovvero strumenti derivanti principalmente dalle piattaforme di misura satellitari, reti di
sensori distribuite a terra (on site) e, possibilmente, di misure disponibili on board. Per la previsione degli hazard meteorologici tali conoscenze
devono essere integrate con lo sviluppo di modelli fisico/numerici. Una volta valutata l’affidabilità dei singoli prodotti sviluppati per il
74
CIRA-CF-12-0600 Rev. 1 P. 74/109
TECVOL-II
TECVOL-II - System Requirements
CIRA-CF-12-0600
monitoraggio e la previsione, la fornitura di tali informazioni, mediante rappresentazioni grafica o dati alfa numerici, dovrà essere funzionale alle
esigenze del pilota e del sistema di pianificazione e controllo del volo garantendo sinteticità e un reale supporto alle decisioni in presenza di
fenomeni meteorologici avversi. A tale sistema è associato l’identificativo S15.
3.4.1.1.2 Giustificazione
I requisiti di tecnologie relative ai Weather Awareness System sono stati definiti mediante un’analisi delle change SA-C4 e GS-C1 definite nel §4 di
[A1] ed in generale della tecnologia L2-T2 (vedi Tabella 2-1 per il riepilogo delle linee tecnologiche individuate nel §5 di [A1]) riguardante lo
sviluppo della tecnologia per il Weather Awareness. La tabella che segue sintetizza l’analisi condotta su tale tecnologia.
Rif. in [A1]]
L2-T2
(change SAC4. GS-C1)
Descrizione
Realizzazione di
architettura, algoritmi
e tools, basati su
dispositivi innovativi,
per la definizione di
un sistema innovativo
di weather awareness
ad ausilio del
pilotaggio
Analisi
In risposta a tale change è stato eseguito uno studio sullo state dell’arte delle tecnologie per il weather
awareness ([R19],[R20],[R21]). Tale studio ha riguardato sia l’identificazione dei fenomeni meteorologici
che, per la loro pericolosità, maggiormente hanno bisogno di essere monitorati e previsti [R22] sia lo studio
dei sensori attualmente disponibili su diverse piattaforme che, in ambito UAV e general aviation, possono
essere utilizzate per la weather awareness riguardante tali hazard meteorologici. Le caratteristiche del
sistema individuato seguono anche le generali indicazioni per la definizione e sviluppo dei sistemi di
weather awareness emersi nell’ambito delle partecipazioni a importanti progetti europei quali SESAR e
ALICIA [R23].
Tabella 3-9 – Analisi dei Conops [A1] per il Weather Situational Awareness System
3.4.1.1.3 Metodo di verifica
VM_Demonstration (CAM), attraverso confronto con dataset di osservazioni meteorologici osservati per un certo numero di test case (inferiore a 5)
e definizione di indici statistici per la valutazione oggettiva delle performances.
75
CIRA-CF-12-0600 Rev. 1 P. 75/109
TECVOL-II
TECVOL-II - System Requirements
CIRA-CF-12-0600
3.4.1.1.4 Requisiti di progetto
TECV2-SUBS-
ID
WSAS-0001
0_0.0
TECV2-SUBS-
WSAS-0002
0_0.0
TECV2-SUBS-
WSAS-0003
0_0.0
3.4.1.2
Titolo
"Situational
awareness" sul
monitoraggio delle
condizioni meteo
"Situational
awareness" sul
nowcasting degli
hazard meteo
“Weather awareness
“ a supporto di
sistemi automatici di
generazione del piano
di volo
Descrizione
Il sistema WSAS dovrà fornire supporto al pilota attraverso lo sviluppo di sistemi
per il monitoraggio delle condizioni atmosferiche e sulla eventuale presenza di
hazard meteorologici durante tutte le fasi di volo
Rational
Il sistema WSAS dovrà fornire supporto al pilota attraverso lo sviluppo di
tecniche per il nowcasting degli hazard meteorologici durante diverse fasi di
volo
Il sistema WSAS dovrà fornire supporto ai sistemi automatici di ottimizzazione
del piano di volo affinchè tengano in conto le condizioni meteorologiche
presenti e previste.
Traffic Awareness and Alerting System (TRAW)
3.4.1.2.1 Descrizione sintetica del sistema
Nella presente sezione sono descritti, sotto forma di appositi requisiti, gli obiettivi che si intende raggiungere attraverso lo sviluppo, in ambito
TECVOL-II, della funzione Traffic Awareness and Alerting System (di seguito sinteticamente indicata con l’acronimo TRAW). A tale sistema è
associato l’identificativo S16.
3.4.1.2.2 Giustificazione
I requisiti relativi al Traffic Awareness and Alerting System sono stati definiti mediante un’analisi delle change SA-C1, SA-C2 e SA-C3 definite nel
§4 di [A1] ed in generale della tecnologia L2-T1 (vedi Tabella 2-1 per il riepilogo delle linee tecnologiche individuate nel §5 di [A1]) riguardante lo
sviluppo di della tecnologia per il Traffic Awareness. La tabella che segue sintetizza l’analisi condotta su tale tecnologia.
76
CIRA-CF-12-0600 Rev. 1 P. 76/109
TECVOL-II
TECVOL-II - System Requirements
Rif. in [A1]]
L2-T1
(change SAC1, SA-C2,
SA-C3)
Descrizione
Traffic Awareness
and Alerting System
CIRA-CF-12-0600
Analisi
Tale funzione è finalizzata a costituire un significativo incremento rispetto a quanto già implementato, e
portato a livello di sviluppo tecnologico TRL 6 in TECVOL-I, in ambito obstacle detection and tracking. Il
sistema sviluppato in TECVOL-I, come sinteticamente descritto nel §3 di [A1], era basato su una gerarchia
sensoristica in cui il radar era il sensore principale e costituiva non tanto un tool a sé stante quanto
esclusivamente un sistema di supporto alla collision avoidance.
Rispetto a quanto fatto in TECVOL-I, in TECVOL-II si intende seguire un approccio che dedica maggiore
attenzione alle specificità di tale funzione, finalizzandola a costituire già di per sé un tool di supporto al
pilota di un velivolo manned, oltre che uno strumento di calcolo dei dati necessari al funzionamento di
algoritmi di self separation e collision avoidance (cfr. sezione3.4.2.3), le caratteristiche innovative di tali
funzioni sono state sinteticamente illustrate nel documento ConOps TECVOL-II [A1] e vengono qui
pertanto completate ed espresse sotto forma di appropriati requisiti funzionali di alto livello.
Tabella 3-10 – Analisi dei Conops [A1] per il Traffic Awareness and Alerting System
3.4.1.2.3 Metodo di verifica
VM_Flight_Validation (FLARE II)
3.4.1.2.4 Requisiti di progetto
ID
Titolo
Descrizione
Il TRAW module dovrà essere utilizzabile su velivoli sia di tipo manned
che unmanned e dovrà poter essere impiegato sia come tool di
Applicabilità del
TECV2-SUBS- TRAW- 00010_0.0
supporto al pilota che come modulo di calcolo dei dati di input
TRAW Module
necessari al funzionamento di algoritmi di self separation e collision
avoidance.
Rationale
Si richiede lo sviluppo di un modulo che assolva
contemporaneamente alle funzioni di supporto
al pilota e di calcolo dei dati di input per
algoritmi automatici, in modo da poter essere
utilizzato sia in modalità di volo pilotato che in
modalità di volo automatico.
77
CIRA-CF-12-0600 Rev. 1 P. 77/109
TECVOL-II
TECVOL-II - System Requirements
Il TRAW module dovrà essere in grado di monitorare il traffico
circostante il velivolo, nell'ambito di un assegnato volume di
Funzionalità del
TECV2-SUBS- TRAW- 00020_0.0
controllo, e dovrà calcolare, per ognuna delle tracce individuate, tutti
TRAW Module
i dati necessari a descriverne le condizioni di volo nonchè possibili
situazioni di conflitto (perdita di separazione e/o collisioni).
TECV2-SUBS- TRAW- 00030_0.0
Requisiti di
detection
CIRA-CF-12-0600
Al modulo viene richiesto di fornire non solo le
informazioni di traffic awareness in senso
stretto ma anche di elaborare tali informazioni
al fine di individuare possibili conflitti e/o
collisioni (traffic alerting).
Il modulo dovrà essere utilizzabile in condizioni
Il TRAW module dovrà essere in grado di individuare, all'interno del del tutto generali, quindi dovrà essere in grado
volume di controllo assegnato, sia velivoli di tipo cooperativo che di svolgere la sua funzione sia nei confronti di
velivoli di tipo cooperativo che nei confronti di
velivoli di tipo non cooperativo.
velivoli di tipo non cooperativo.
Questo requisito costituisce un significativo
Il TRAW module dovrà essere in grado di individuare e tracciare
Gestione di
miglioramento di quanto fatto in TECVOL-I,
TECV2-SUBS- TRAW- 00040_0.0
simultaneamente molteplici intruder (fino ad un numero massimo da
intruder multipli
laddove la validazione fino a TRL 6 è avvenuta
stabilire nel corso del progetto).
considerando un singolo intruder.
TECV2-SUBS- TRAW- 00050_0.0
Capacità di
sensor fusion
Tramite l'impiego della sensor fusion, si punta a
In funzione dei sensori installati on-board, il TRAW module dovrà
sfruttare al meglio le varie possibili
implementare adeguati algoritmi di fusion di tutti i dati disponibili al
combinazioni di sensori disponibili, in funzione
fine di ottenere la migliore stima dei parametri caratterizzanti il
dello stato di salute della sensor suite di bordo
traffico circostante il velivolo.
e dello scenario operativo.
TECV2-SUBS- TRAW- 00060_0.0
Suite di sensori
Il TRAW module dovrà essere in grado di svolgere la propria funzione, Si richiede al TRAW module ampia flessibilità, in
sebbene eventualmente con prestazioni diverse, utilizzando differenti termini di impiego di diverse possibili suite di
suite di sensori: full sensors suite, low cost sensor suite.
sensori da montare on-board.
Nella sua versione full, la suite di sensori utilizzata dal TRAW module
dovrà comprendere almeno sensori elettro-ottici (VIS e IR), radar e Questa configurazione di sensori arricchisce
TECV2-SUBS- TRAW- 00070_0.0 Full sensor suite ADS-B. Per la detection short range, dovrà essere sufficiente anche quella presente in TECVOL-I tramite l'aggiunta
l'impiego del solo radar o del solo ADS-B. Per la detection long range, del sistema ADS-B.
dovrà essere sufficiente anche l'impiego del solo ADS-B.
78
CIRA-CF-12-0600 Rev. 1 P. 78/109
TECVOL-II
TECVOL-II - System Requirements
Nella sua versione low cost, la suite di sensori utilizzata dal TRAW
module dovrà comprendere almeno sensori elettro-ottici (VIS e IR),
Low-cost sensor radio ranger ed ADS-B. Per la detection short range, dovrà essere
TECV2-SUBS- TRAW- 00080_0.0
suite
sufficiente anche l'impiego del solo ADS-B o degli elettro-ottici (VIS e
IR) in abbinamento con il radio ranger. Per la detection long range,
dovrà essere sufficiente anche l'impiego del solo ADS-B.
TECV2-SUBS- TRAW- 00090_0.0
Descrizione
generale del
traffico
CIRA-CF-12-0600
Questa configurazione di sensori è finalizzata a
supportare sistemi di traffic awareness e
alerting (nonché di traffic avoidance) di tipo low
cost, grazie alla rinuncia all'impiego del radar.
Il TRAW module dovrà fornire in uscita, per tutti i velivoli tracciati
Requisito minimo di traffic awareness, senza
nell'ambito del volume di controllo assegnato, almeno i dati di
funzione di alerting.
posizione e volocità (vettoriale).
Si richiede un'extended traffic awareness, grazie
Identificazione
Il TRAW module dovrà essere in grado di identificare la classe degli alla possibilità di identificazione automatica
TECV2-SUBS- TRAW- 00100_0.0 della classe degli
intruder.
della classe degli intruder da parte del TRAW
intruder
module.
Il TRAW module dovrà monitorare il traffico all'interno del volume di Si richiede un'extended traffic awareness, grazie
Attribuzione del
TECV2-SUBS- TRAW- 00110_0.0
controllo considerato e stabilire, in base alle regole dell'aria, per alla possibilità di determinazione automatica
Right of Way
ciascun intruder individuato la sussistenza o meno del Right of Way.
del RoW da parte del TRAW module.
TECV2-SUBS- TRAW- 00120_0.0
Distinzione tra
conflitti e
collisioni
Sulla base della considerazione di opportuni volumi di sicurezza
(separation bubble e collision bubble), il TRAW module dovrà essere
in grado di distinguere possibili conflitti (velivoli per i quali si prevede
la violazione della separation bubble ma non della collision bubble) e
possibili collisioni (velivoli per i quali si prevede la violazione della
collision bubble).
Si richiede che il TRAW module sia in grado di
discriminare tra i diversi possibili tipi di alert,
allo scopo non solo di fornire adeguati input agli
algoritmi automatici di self separation e
collision avoidance ma anche di migliorare la
consapevolezza da parte del pilota in termini di
priorità degli alert.
79
CIRA-CF-12-0600 Rev. 1 P. 79/109
TECVOL-II
TECVOL-II - System Requirements
TECV2-SUBS- TRAW- 00130_0.0
TECV2-SUBS- TRAW- 00140_0.0
3.4.1.3
Parametri
descrittivi delle
condizioni di
conflitto
Sulla base di un'opportuna propagazione di traiettoria del proprio
velivolo e di ciascun intruder considerato, il TRAW module dovrà
calcolare come minimo (ove applicabili): la condizione di
conflitto/non conflitto, il tempo rimanente alla violazione della
separation bubble, la distanza tra velivolo ed intruder al closest point
of approach, il tempo rimanente al raggiungimento del closest point
of approach.
Parametri
descrittivi delle
condizioni di
collisione
Sulla base di un'opportuna propagazione di traiettoria del proprio
velivolo e di ciascun intruder considerato, il TRAW module dovrà
calcolare come minimo (ove applicabili): la condizione di
collisione/non collisione, il tempo rimanente alla violazione della
collision bubble, la distanza tra velivolo ed intruder al closest point of
approach, il tempo rimanente al raggiungimento del closest point of
approach.
CIRA-CF-12-0600
I dati descrittivi delle condizioni di alert
dovranno essere adeguati non solo per la
presentazione di un'extended traffic awareness
ed alerting al pilota ma anche sufficienti a
supportare il funzionamento di algoritmi
automatici
di
traffic
avoidance.
La modalità migliore di propagazione di
traiettoria del proprio velivolo e degli intruder
dovrà essere investigata nel corso del progetto
ed in ogni caso sarà dipendente dalle
informazioni di traffic awareness disponibili e
della modalità di volo del velivolo.
Terrain Situational Awareness System (TAWS)
3.4.1.3.1 Descrizione sintetica del sistema
Il sistema di Terrain Situational Awareness dovrà fornire in maniera automatica all’equipaggio dei warning relativi a potenziali rischi di collisione
con il terreno. I messaggi di warning dovranno essere forniti con un preavviso sufficiente affinché una manovra di risoluzione sia decisa ed attuata.
Tale tipologia di sistemi sono generalmente conosciuti con il nome di TAWS e sono basati sull’utilizzo di sistemi tipo radar altimetri e di mappe
dell’orografia. Nel sistema che si intende sviluppare si cercherà di evitare l’utilizzo di sistemi radio (ad esempio radar altimetri) a vantaggio di
sistemi più compatti come ad esempio delle video-camere.
Relativamente alla classificazione ICAO dei sistemi TAWS, si opterà per l’implementazione di funzionalità miste fra la classe A (Part 121 e Part
135 con un numero di posti maggiore o uguale a 10) e la classe B (destinata ai velivoli che ricadono nella Part 91 con 6 posti o più oppure nella Part
135 da 6 a 9 posti). Infatti il sistema di TAWS sarà dotato di una visualizzazione dati (MFD&D) non richiesta per la Classe B ma soltanto per la
Classe A, ma non implementerà la funzionalità di Terrain Following richiesta invece anche per la Classe B. A tale sistema è associato
l’identificativo S17.
80
CIRA-CF-12-0600 Rev. 1 P. 80/109
TECVOL-II
TECVOL-II - System Requirements
CIRA-CF-12-0600
3.4.1.3.2 Giustificazione
I requisiti relativi al Trerrain Awareness and Alerting System sono stati definiti mediante una breve analisi sullo stato dell’arte relativo alle
tecnologia L2-T3 (vedi Tabella 2-1 per il riepilogo delle linee tecnologiche individuate nel §5 di [A1]) riguardante lo sviluppo di sistemi per il
Terrain Awareness nell’ambito di velivoli pilotati della classe General Aviation. La tabella che segue sintetizza l’analisi condotta su tale tecnologia.
Rif. in [A1]]
L2-T3
Descrizione
Terrain Situational
Awareness System
Analisi
La definizione dei requisiti di progetto del modulo di TAWS è basata sull’analisi delle indicazioni
contenute nel documento Conops, nonché da un’analisi di sistemi commerciali. Relativamente ai sistemi
commerciali, una sintesi dei principali sistemi esistenti sul mercato è fornita da “Pilot’s guide to avionics –
Terrain Awareness and Alerting Systems- Buyer’s Guide”. Il sistema che si svilupperà presenta degli
aspetti di miglioramento rispetto ai sistemi attuali relativamente ai sensori utilizzati e conseguentemente
agli algoritmi di sensor fusion.
Tabella 3-11 – Analisi dei Conops [A1] per il Terrain Situational Awareness System
3.4.1.3.3 Metodo di verifica
VM_Demonstration (CAM)
3.4.1.3.4 Requisiti di progetto
TECV2-SUBS-
ID
TSAS-0001
0_0.0
TECV2-SUBS-
TSAS-0002
0_0.0
Titolo
Funzionalità Terrain
Awareness
Descrizione
Il modulo di Terrain Awareness & Alerting dovrà essere dotato di una funzionalità di Terrain
Alerting che determini il verificarsi di una o più fra le seguenti condizioni:
- Premature descent;
- Excessive Rates of descent;
- Negative climb rate or altitude loss after takeoff;
- "Under Five Hundreds".
Premature descent
warning
Il modulo dovrà generare un flag di "Premature Descent" se l'attuale quota è i) al di sotto di
quella programmata dal pianificatore di missione o ii), nel caso specifico dell' atterraggio, è
al di sotto del path di approccio per la pista su cui avverrà l'atterraggio.
Rationale
81
CIRA-CF-12-0600 Rev. 1 P. 81/109
TECVOL-II
TECVOL-II - System Requirements
TECV2-SUBS-
TSAS-0003
0_0.0
TECV2-SUBS-
TSAS-0004
0_0.0
TECV2-SUBS-
TSAS-0005
0_0.0
3.4.2
CIRA-CF-12-0600
Excessive Rate of
descent warning
Under Five Hundreds
Warning
Il modulo dovrà generare un flag di "Excessive Rate of Descent" se l'attuale velocità di
discesa è al di sotto di quella definita dal pianificatore di missione.
Il modulo dovrà generare un flag di "Under Five Hundreds" se, la quota al di sopra del
terreno (AGL) o al di sopra della pista di atterraggio più vicina è inferiore a 500 ft.
Sensori per Terrain
Awareness
Il modulo di Terrain Awareness & Alerting per svolgere le sue funzionalità dovrà utilizzare le
misure fornite da cartografia digitale DTEC almeno di livello 1, un Laser altimetro, misure
GPS e, se disponibile, un sistema video.
Systems for Automatic Flight
3.4.2.1
Advanced Cockpit (ADCO)
3.4.2.1.1 Descrizione sintetica del sistema
Nella presente sezione sono descritti, sotto forma di appositi requisiti, gli obiettivi che si intende raggiungere attraverso lo sviluppo, in ambito
TECVOL-II, del sistema Advanced Cockpit (di seguito sinteticamente indicata con l’acronimo ADCO).
Tale funzione rappresenta un elemento di assoluta innovazione rispetto alle attività di ricerca sviluppate in TECVOL-I, laddove non sono stati
condotti studi specifici riguardo a tale argomento, eccezion fatta per lo studio dei requisiti della Ground Control Station [R28], alcuni dei quali
possono essere utilmente rivisitati nel presente ambito. Anche in sede di ConOps di TECVOL-II [A1], inoltre, tale argomento non è stato trattato,
pertanto nella presente sezione vengono espresse, sotto forma di appropriati requisiti utente, le caratteristiche principali che ci si aspetta vengano
implementate nel sistema ADCO. A tale sistema è associato l’identificativo S18.
3.4.2.1.2 Giustificazione
Lo sviluppo di un cockpit avionico di tipo avanzato nell’ambito del progetto TECVOL-II è motivato dalla necessità di tenere conto fin d’ora di
quelle che potrebbero essere le prospettive di sviluppo tecnologico in un’ottica temporale più ampia di quella coperta dal progetto TECVOL-II
medesimo, andando perciò a spingersi a considerare un orizzonte temporale che arriva fino al 2020.
In ambito del progetto MISE, infatti, sono state già previste delle attività di sviluppo di un cockpit avionico manned di tipo standard come già
descritto nel §2.4.
82
CIRA-CF-12-0600 Rev. 1 P. 82/109
TECVOL-II
TECVOL-II - System Requirements
CIRA-CF-12-0600
La filosofia di sviluppo del concetto del cockpit avionico avanzato, invece, è quella di sfruttare le maggiori potenzialità tecnologiche HW/SW, che
si suppongono disponibili in un orizzonte temporale più lungo, al fine di superare lo standard attuale e puntare alla riconfigurabilità completa sia del
contenuto informativo offerto (che si prevede più ampio rispetto agli standard consueti) sia delle modalità nella presentazione delle informazioni al
pilota (per conseguire migliore efficienza ed efficacia nel layout), il tutto al fine di garantire una situational awareness migliore di quella conseguita
con gli attuali standard avionici.
L’ottica di sviluppo dei requisiti di seguito riportati è quella di un sistema che sia applicabile nel contesto di riferimento del progetto TECVOL-II,
quindi che abbia caratteristiche che ne consentano l’impiego nell’ambito sia degli Unmanned Aerial Systems (UAS) che dei velivoli Very Light
Aircraft (VLA) o General Aviation (GA).
La filosofia di definizione dei requisiti che seguono è quella di consentire lo sviluppo di un sistema che sia in grado di:
• ridurre il workload del pilota;
• aumentare le performance nell’esecuzione della missione di volo;
• aumentare la situational awareness;
• aumentare l’efficienza dell’interazione tra pilota e cockpit (e, quindi, tra pilota e velivolo);
• aumentare la safety del volo;
• consentire l’integrazione delle funzionalità più avanzate di automazione della missione;
• aumentare la flessibilità del sistema cockpit al fine di consentire l’upgrade delle sue funzionalità.
Il cockpit avanzato specificato nei seguenti paragrafi, sebbene sia riferito a velivoli manned, sarà sviluppato sulla base delle linee tecnologiche
previste in [A1] L2-T1, L2-T2, L2-T3 riguardanti la situational awareness del pilota (remoto o a bordo che sia) sul traffico circostante, sulla quota
del terreno sottostante e sulle condizioni metereologiche lungo la rotta da seguire. Inoltre è applicabile anche la tecnologia L3-T3 di [A1] relativa
allo sviluppo delle interfacce uomo macchina utili al supporto alla guida manuale e/o automatica.
3.4.2.1.3 Metodo di verifica
VM_Demonstration (CAM)
3.4.2.1.4 Requisiti di progetto
83
CIRA-CF-12-0600 Rev. 1 P. 83/109
TECVOL-II
TECVOL-II - System Requirements
ID
Titolo
Descrizione
CIRA-CF-12-0600
Rationale
Si richiede l'applicabilità duale del sistema in
Applicabilità del Il sistema ADCO dovrà essere applicabile nell'ambito degli UAS modo da consentire la riutilizzabilità dello
TECV2-SUBS- ADCO- 00010_0.0
sistema ADCO nonché su velivoli di tipo VLA e GA.
stesso sia in ambito manned che unmanned, sia
a bordo che in postazioni di controllo remoto.
Il sistema ADCO dovrà fornire al pilota adeguata rappresentazione
visuale dei dati descrittivi dello stato del velivolo e delle informazioni
sulla missione in esecuzione, nonché dovrà consentirgli adeguata
interazione con il velivolo medesimo al fine di portare a compimento
la missione di volo. A tal fine, esso dovrà implementare le funzionalità
di seguito elencate (come descritte negli specifici requisiti):
Funzionalità del
TECV2-SUBS- ADCO- 00020_0.0
-) Situation Awareness
sistema ADCO
-) Mission Management
-) Failure and Health Monitoring
-) Communications and Datalink Management
-) Comando del velivolo
-) Interactive Envelope Protection
-) Alerting ottico ed acustico
Si richiede che il sistema ADCO sia avanzato, nel
senso che deve essere in grado di integrare,
oltre ai pannelli informativi tradizionali ormai
acquisiti anche in ambito VLA e GA, anche
ulteriori
tipi
di
interfacce
finalizzate
all'automazione della missione, all'envelope
protection ed alla gestione dello stato di salute
del velivolo.
Funzionalità di
Situational
Awareness
Il sistema ADCO dovrà fornire al pilota tutte le informazioni
necessarie a descrivere, in maniera sufficientemente esaustiva e con
aggiornamento in tempo reale, lo stato del velivolo nonché
l'ambiente operativo in cui esso opera. Tali informazioni dovranno
includere almeno i primary flight data, i dati di navigazione, quelli di
propulsione, il traffico circostante, gli ostacoli fissi, i dati meteo di
interesse.
In realtà, come evidente dai requisiti che
seguono, tale set di requisiti corrisponde alla
funzionalità minima di situational awareness
che il sistema dovrà integrare.
Funzionalità di
Mission
Management
Il sistema ADCO dovrà consentire al pilota la gestione della missione
di volo, attraverso la possibilità di monitorare lo stato di eventuali
sistemi di automazione di missione presenti a bordo (ad esempio il 4D
Contract Management System), e di impostare le modalità desiderate
di impiego di tali sistemi.
Il sistema ADCO dovrà essere in grado di
supportare le più avanzate tecnologie di
automazione
della
missione
disponibili
nell'orizzonte temporale di interesse, a
cominciare da quelle sviluppate nel progetto
TECVOL-II.
TECV2-SUBS- ADCO- 00030_0.0
TECV2-SUBS- ADCO- 00040_0.0
84
CIRA-CF-12-0600 Rev. 1 P. 84/109
TECVOL-II
TECVOL-II - System Requirements
CIRA-CF-12-0600
Il sistema ADCO dovrà consentire al pilota di conoscere lo stato di
salute del velivolo, con riferimento a tutti i sistemi (o, come minimo, a
quelli safety critical) presenti a bordo.
Nel caso in cui a bordo sia implementato anche un sistema
automatico di health management in grado di riconfigurare alcuni
sistemi in seguito a failure, il sistema ADCO dovrà essere in grado di
informare il pilota circa l'avvenuta riconfigurazione e le relative
modalità.
Tale funzionalità rappresenta un avanzamento
di grande rilievo nel campo dei velivoli VLA e
GA, avanzamento ancor più rilevante se tale
funzionalità viene supportata dalla disponibilità
di un sistema di health management automatico
o di ausilio al pilota.
Il sistema ADCO dovrà consentire al pilota la gestione dei canali di
comunicazione e dei relativi sistemi di datalink, che dovranno poter
Funzionalità di
essere eventualmente riconfigurati al fine di usare, in caso di avaria,
Communications
percorsi di scambio dati diversi dai nominali (ad es., in caso di perdita
TECV2-SUBS- ADCO- 00060_0.0
and Datalink
del link con il segmento di terra, il pilota dovrà poter attivare,
management
attraverso il sistema ADCO, un apposito link di comunicazione di
emergenza satellitare o con altri velivoli).
In un contesto operativo nel quale si suppone
disponibile una molteplicità di canali di
comunicazione, ivi inclusa la possibilità ad
esempio di comunicare con il segmento di terra
tramite i velivoli circostanti (in caso di perdita
del proprio link verso terra), risulta importante
la presenza nel sistema ADCO di un'apposita
funzionalità di gestione delle comunicazioni
(anche in situazioni di emergenza).
Il sistema ADCO dovrà essere in grado di monitorare la congruità dei
comandi di volo e di impostazione della navigazione impartiti dal
pilota e dovrà comunicare eventuali incompatibilità dei medesimi con
i limiti di prestazione del velivolo e/o con i vincoli di missione
impostati (ad esempio, il sistema ADCO dovrà essere in grado di
segnalare se la rotta impostata attraversa una no-fly zone).
Tale requisito mira ad aumentare l'efficacia
dell'interazione tra pilota e velivolo, richiedendo
al sistema ADCO di fornire al pilota una sorta di
feedback in merito alla coerenza dei comandi
impartiti.
Il sistema ADCO dovrà consentire al pilota di attingere a tutte le
informazioni di interesse attraverso un'apposita interfaccia uomomacchina, che dovrà anche consentire la selezione delle informazioni
da mostrare.
Tale interfaccia dovrà implementare le funzionalità di situation
awareness, mission management, failure and health monitoring e
Human Machine
communications and datalink management.
TECV2-SUBS- ADCO- 00080_0.0
Interface (HMI)
A tal fine, essa dovrà includere vari sottosistemi (come dettagliati
negli specifici requisiti):
-) Advanced HUD;
-) Advanced MFD;
-) Advanced EICAS;
-) FHMS.
Si richiede che la HMI riunisca ed organizzi in
una modalità di presentazione efficace tutte le
informazioni di tipo strumentale disponibili a
bordo, nonché le informazioni relative al profilo
di missione ed allo stato di salute del velivolo e
dei sistemi di bordo.
TECV2-SUBS- ADCO- 00050_0.0
TECV2-SUBS- ADCO- 00070_0.0
Funzionalità di
Failure and
Health
monitoring
Funzionalità di
Interactive
Envelope
Protection
85
CIRA-CF-12-0600 Rev. 1 P. 85/109
TECVOL-II
TECV2-SUBS- ADCO- 00090_0.0
TECV2-SUBS- ADCO- 00100_0.0
TECVOL-II - System Requirements
CIRA-CF-12-0600
EFIS (Electronic
Flight
Instrument
System)
La HMI implementata nel sistema ADCO dovrà essere di tipo EFIS
(Electronic Flight Instrument System), cioè dovrà fare uso di una
rappresentazione delle informazioni provenienti dai vari strumenti e
dai vari sistemi interessati di tipo sintetico, modificabile sia in termini
di contenuti visualizzati che in termini di modalità di visualizzazione, e
riconfigurabile via software.
Grazie
all'implementazione
dell'intero
contenuto informativo tramite EFIS, si desidera
conferire al sistema ADCO la massima
flessibilità, andando nel contempo a rendere
possibile la rappresentazione di un maggior
numero di informazioni a parità di spazio
disponibile.
Single Display
Cockpit (SDC)
La HMI nel sistema ADCO dovrà essere implementata tramite un
unico display, di grandi dimensioni, senza discontinuità ed
eventualmente curvo in funzione della conformazione della cabina di
pilotaggio. Il SDC dovrà essere di tipo touch screen ed il layout delle
informazioni e delle interfacce di input tattile dovrà essere
modificabile via software.
L'uso di un singolo display consente la
massimizzazione dell'impiego dello spazio
disponibile nella cabina di pilotaggio, nonché la
riconfigurabilità totale della modalità di
presentazione di tutte le informazioni
disponibili.
TECV2-SUBS- ADCO- 00110_0.0
Dark cockpit
TECV2-SUBS- ADCO- 00120_0.0
Intelligent
Display
Management
Al fine di ridurre il work load per il pilota, tutti i sottosistemi
componenti la HMI del sistema ADCO dovranno visualizzare le
informazioni secondo una filosofia dark cockpit (ove applicabile), cioè
dovranno presentare al pilota solo le informazioni strettamente
necessarie alla fase di volo in corso, mentre i dati non rilevanti per
tale fase di volo dovranno essere evidenziati sugli schermi o con avvisi
Tali funzionalità consentono sia di ridurre il
acustici unicamente in caso di avarie o anomalie.
work load del pilota, dandogli la possibilità di
Il sistema ADCO dovrà essere in grado di supportare la riduzione del focalizzare l'attenzione sulle sole informazioni di
workload per il pilota in particolari fasi di volo andando interesse, sia di massimizzare le informazioni
automaticamente ad indentificare le informazioni di interesse per tale potenzialmente visualizzabili a parità di spazio
fase di volo ed a mostrare solo queste (o ad evidenziare solo queste) disponibile, in funzione della fase di volo in
nella HMI, nascondendo le altre e richiamandole automaticamente corso.
solo in caso di avaria/anomalia delle medesime. Il sistema ADCO,
inoltre, dovrà essere in grado di discriminare il grado di pericolosità
dell’anomalia, evitando di distrarre l'attenzione del pilota nelle fasi
più critiche (decollo ed atterraggio) con anomalie di lieve entità che
possono essere prese in considerazione in una fase successiva del
volo a minore criticità.
86
CIRA-CF-12-0600 Rev. 1 P. 86/109
TECVOL-II
TECV2-SUBS- ADCO- 00130_0.0
TECVOL-II - System Requirements
De-cluttering
CIRA-CF-12-0600
Il sistema ADCO dovrà consentire al pilota di decidere il livello di
dettaglio delle informazioni da visualizzare, consentendogli di
impartire adeguati comandi di de-cluttering. Il pilota, pertanto, dovrà
poter scegliere di eliminare dal display informazioni che non sono
richieste nella fase di volo in questione e di ripristinarle in seguito o
dovrà poter scegliere di dare maggiore enfasi a determinate tipologie
di informazioni (ad esempio, in rotta il pilota dovrà poter eliminare
dalla mappa virtuale informazioni geografiche troppo di dettaglio, che
invece ripristinerà in approccio.)
Il sistema ADCO dovrà presentare le informazioni relative ai primary
flight data su un apposito Head-Up display, cosentendo così il
pilotaggio senza distogliere lo sguardo dall'ambiente circostante. Tale
HUD dovrà essere di tipo avanzato, andando ad includere anche
Advanced Head informazioni di improved situation awareness. Esse dovranno essere
TECV2-SUBS- ADCO- 00140_0.0
Up Display
costituite, ad esempio, da informazioni di visione sintetica quali una
(HUD)
riproduzione 3D dell'ambiente esterno (in caso di scarsa visibilità a
occhio nudo) basata su sensori infrarossi (Forward Looking Infra Red,
FLIR) o radar, ove disponibili, ed informazioni avanzate di assistenza
alla navigazione (ad esempio rappresentazione della traiettoria
prevista del tipo "tunnel in sky").
L'impiego di un HUD in velivoli di tipo ULV e GA
rappresenta un'innovazione, ritenuta adeguata
alla luce dell'orizzonte temporale considerato
per l'applicazione del sistema ADCO qui
delineato.
Non si è ritenuto adeguato, invece, l'impiego di
Helmet Mounted Display (HMD), in quanto
assolutamente non necessario in funzione della
tipologia di missione di volo tipica dei velivoli
ULV e GA.
Il sistema ADCO dovrà includere un Multi Functional Display in grado
di rappresentare informazioni di situational awareness, mission
management e communications management. Tale MFD dovrà
consentire l'input di comandi di configurazione tramite touch screen.
Il MFD implementato nel sistema ADCO dovrà essere di tipo avanzato,
in quanto dovrà consentire in maniera flessibile la gestione della
Advanced Multi missione di volo (attraverso adeguato interfacciamento verso i sistemi
TECV2-SUBS- ADCO- 00150_0.0
Functional
di 4D Contract Management System, Traffic and Obstacle Avoidance
Display (MFD) System, ecc.), la gestione delle comunicazioni, sia in condizioni
nominali che in emergenza, la visualizzazione dei dati meteo in
sovrapposizione alla mappa geografica (2D o 3D), la visualizzazione
orografica selettiva del terreno circostante in funzione della quota del
velivolo (ad esempio, il terreno a quota adeguatamente inferiore a
quella del velivolo viene oscurato sulla mappa mentre il terreno a
quota superiore viene enfatizzato).
Il sistema ADCO dovrà recepire le caratteristiche
implementate nel Multi Functional Display
sviluppato in ambito TECVOL-II e dovrà
migliorarle, estendendo le funzionalità di tale
display attraverso l'integrazione pure di
rappresentazioni complessive 3D dell'ambiente
circostante che integrino tutte le info di
situational awareness disponibili.
87
CIRA-CF-12-0600 Rev. 1 P. 87/109
TECVOL-II
TECV2-SUBS- ADCO- 00160_0.0
TECV2-SUBS- ADCO- 00170_0.0
TECV2-SUBS- ADCO- 00180_0.0
TECV2-SUBS- ADCO- 00190_0.0
TECVOL-II - System Requirements
CIRA-CF-12-0600
Advanced
EngineIndicating and
Crew-Alerting
System (EICAS)
Il sistema ADCO dovrà implementare un sistema di visualizzazione
delle informazioni relative all'impianto di propulsione e di
segnalazione di anomalie ed avarie. Tale sistema dovrà essere di tipo
avanzato, in quanto, in presenza di eventuali sistemi di bordo in grado
di riconfigurare il sistema di propulsione in seguito a failures, dovrà
essere in grado di segnalare la riconfigurazione e di indicare le
informazioni rilevanti che la descrivono.
Le funzionalità avanzate del sistema EICAS
consistono essenzialmente nell'integrazione di
informazioni provenienti da eventuali sistemi di
bordo di health management (nello specifico di
riconfigurazione del sistema di propulsione in
seguito a failures).
Failiure and
Health
Management
System
Il sistema ADCO dovrà implementare un sistema di visualizzazione e
gestione dello stato di salute del velivolo, andando a consentire al
pilota l'implementazione di strategie di riconfigurazione in seguito a
failures di tipo prestabilito. Tale sistema dovrà essere in grado di
visualizzare informazioni a diverso livello di dettaglio in funzione dello
stato di salute dei diversi sistemi interessati (dando ovviamente
maggiore enfasi ai sistemi in condizione anomala rispetto a quelli in
condizione normale).
Tale sistema riveste una caratteristica di
innovatività di grande rilievo per il sistema
ADCO qui delineato, in quanto non comune
nell'ambito del velivoli GA e ULV.
End Effectors
Il sistema ADCO dovrà implementare adeguati end effectors per
l'ìnput dei comandi (direct-link o aumentati) alle supefrici
aerodinamiche di controllo ed al sistema di propulsione da parte del
pilota. Tali end effectors dovranno includere stick e pedaliera dotati di
force feedback e con possibilità di regolazione dell'intensità delle
sollecitazioni e della resistanza offerti al pilota.
L'impiego di end effectors dotati di force
feedback si rietiene possa considerarsi di tipo
standard nell'orizzonte temporale considerato,
almeno nei velivoli GA.
Command and
data entry
Il sistema ADCO dovrà offrire al pilota la possibilità di controllare le
informazioni da mostrare e di inserire dati di input nei sistemi di
automazione della missione attraverso dispositivi di input di tipo sia
tattile (touch screen) sia, eventualmente ed ove ritenuto applicabile,
di tipo vocale (direct voice input, DVI).
L'introduzione di sistemi di input dei comandi di
tipo vocale si ritiene suscettibile di studio
nell'ambito del sistema ADCO, mentre non si
ritengono applicabili sistemi più evoluti, del tipo
eye trackers, perché non richiesti in funzione
delle missioni di volo tipiche di velivoli GA e
ULV.
88
CIRA-CF-12-0600 Rev. 1 P. 88/109
TECVOL-II
TECVOL-II - System Requirements
3.4.2.2
CIRA-CF-12-0600
4D Contract Management System (4DMS)
3.4.2.2.1 Descrizione sintetica del sistema
Nella presente sezione sono descritti, sotto forma di appositi requisiti, gli obiettivi che si intende raggiungere attraverso lo sviluppo, in ambito
TECVOL-II, di un sistema che assolva alla funzione di 4D Contract Management (di seguito sinteticamente indicata con l’acronimo 4DMS). A tale
sistema è associato l’identificativo S19.
3.4.2.2.2 Giustificazione
Il sistema 4DMS sarà finalizzato a costituire un significativo incremento tecnologico rispetto a quanto già implementato in TECVOL I (e che si
intende portare a maturazione tecnologica fino a TRL 6 in TECVOL II, cfr. Automatic 4D Plan Execution §3.2.1.4). Le caratteristiche innovative di
tale sistema sono state sinteticamente illustrate nel documento ConOps [A1] e vengono qui pertanto completate ed espresse sotto forma di
appropriati requisiti di progetto.
E’ da rilevare, inoltre, che già in TECVOL I è stato svolto uno studio mirante ad identificare le funzionalità richieste ad un Flight Management
System (FMS) avanzato, capace di gestire un volo autonomo 4D [R31]. Pertanto, nella redazione dei requisiti di cui alla presente sezione, si è fatto
uso anche dei risultati di tale studio, opportunamente rivisitati alla luce delle specificità del progetto TECVOL II, e delle competenze acquisite nei
progetti in corso PPlane (The Personal Plane Project, finanziato nell’ambito del VII FP EU) e 4DCo-GC (4D Contracts – Guidance and Control,
anch’esso finanziato nell’ambito del VII FP EU).
Il sistema 4DMS specificato nei seguenti paragrafi, sebbene sia riferito a velivoli manned, sarà sviluppato sulla base della linea tecnologica prevista
in [A1] L1-T2 riguardante lo sviluppo di funzionalità per l’esecuzione automatica di particolare fasi del volo ed in particolare l’evoluzione delle
tecnologie di navigazione 4D.
3.4.2.2.3 Metodo di verifica
VM_Demonstration (CAM)
3.4.2.2.4 Requisiti di progetto
ID
Titolo
Descrizione
Rationale
89
CIRA-CF-12-0600 Rev. 1 P. 89/109
TECVOL-II
TECV2-SUBS- 4DMS- 00010_0.0
TECV2-SUBS- 4DMS- 00020_0.0
TECV2-SUBS- 4DMS- 00030_0.0
TECV2-SUBS- 4DMS- 00040_0.0
TECVOL-II - System Requirements
Il modulo 4DMS dovrà essere progettato per l'applicazione generale
Applicabilità del
al segmento di volo di cruise, andando ad escludere esplicitamente
4DMS Module
l'applicazione alle fasi di take off e landing.
CIRA-CF-12-0600
L'estensione della funzionalità di volo
autonomo attraverso contratti 4D che
includono anche le fasi di take-off e landing si
ritiene opportuno trattarla in TECVOL II solo in
termini
di
studio
di
fattibilità.
Ciò in quanto si prevede che l'implementazione
effettiva di tale estensione protrebbe richiedere
eccessive risorse rispetto a quelle disponibili ed
inoltre in letteratura e nei progetti in corso (in
particolare PPlane e 4DCo-GC) il concetto di
take-off e landing 4D non è stato delineato in
dettaglio ma solo genericamente enunciato.
4D take-off e
landing
In TECVOL II si dovrà investigare, in termini di studio di fattibilità, la
possibilità di estendere la navigazione autonoma 4D anche alle fasi di
take off e landing.
Contratto 4D
Il contratto 4D sarà costituito da una sequenza di WPs 4D, individuati
da volumi di controllo 3D e da una finestra temporale, e da segmenti
di traiettoria (bone trajectory) che li congiungono, corredati da un
adeguato margine spaziale. Il contratto 4D si intenderà generato dal
segmento di terra ed assegnato al velivolo.
Il concetto di contratto 4D da considerare in
TECVOL II in sede di funzionalità di 4DMS viene
definito in maniera coerente con quanto
considerato nei progetti PPlane e 4DCo-GC
Ciascuno dei WPs 4D facenti parte del contratto sarà caratterizzato da
numerose proprietà, volte ad individuarne la posizione 3D, il vettore
velocità eventualmente desiderato all’attraversamento del WP, la
modalità di capture temporale con il relativo margine, la modalità di
capture spaziale con il relativo margine (volume di controllo), la
modalità di holding (se prevista), e così via.
Anche se nel concetto di contratto 4D
considerato
solitamente
nel
contesto
internazionale non viene richiesta la cattura di
un WP nel rispetto di un prefissato
orientamento del vettore velocità inerziale del
velivolo, si ritiene opportuno mantenere in
TECVOL II questa caratteristica funzionale
addizionale, che è stata sviluppata in sede di
progettazione dell'algoritmo di 4DAMF di
TECVOL I e mantenuta in TECVOL II nel 4DPE
module.
WPs 4D
90
CIRA-CF-12-0600 Rev. 1 P. 90/109
TECVOL-II
TECV2-SUBS- 4DMS- 00050_0.0
TECVOL-II - System Requirements
Aggiornabilità
on line del
contratto 4D
CIRA-CF-12-0600
Questo requisito traduce un aspetto
fondamentale del concetto di contratto 4D, che
risiede nella possibilità di aggiornamento del
Tutte le proprietà dei WPs, nonché i margini spaziali consentiti contratto medesimo in sede tattica (cioè
nell’inseguimento della bone trajectory, dovranno poter essere durante il volo) rispetto a quanto assegnato in
eventualmente aggiornate on line da parte del segmento di terra.
sede strategica (cioè prima del volo), per tenere
conto di eventuali cambiamenti (disturbi
ambientali, failures sul velivolo, intervenute no
fly zones) nello scenario operativo.
Il 4DMS module dovrà essere in grado di generare automaticamente i
riferimenti necessari per l'inseguimento del contratto 4D assegnato,
nel rispetto dei margini spaziali e temporali facenti parte del contratto
medesimo.
Funzionalità del Qualora necessario, a causa ad esempio della presenza di disturbi
TECV2-SUBS- 4DMS- 00060_0.0
4DMS Module ambientali e/o di failures che modifichino le performances del
velivolo, il 4DMS module dovrà essere in grado di rigenerare
automaticamente una traiettoria e/o un profilo di velocità,
compatibili con le prestazioni del velivolo, che siano in grado di
mantenere il velivolo entro il contratto assegnato (ove possibile).
Il 4DMS module, benchè concepito per
l'impiego in velivoli manned, deve essere in
grado di gestire il volo in maniera
completamente
automatica.
Ove il pilota decidesse di mantenere la guida del
velivolo, il 4DMS module continuerebbe ad
elaborare i medesimi outputs, da intendersi in
tal caso come suggerimenti al pilota invece che
come comandi di guidance automatica del
velivolo.
Azioni di
controllo per il
TECV2-SUBS- 4DMS- 00070_0.0 soddisfacimento
del vincolo
temporale
Al fine di costituire un significativo
avanzamento rispetto allo stato dell'arte degli
FMS con capacità di inseguimento di WPs 4D, il
4DMS module dovrà essere in grado di
espletare la funzione di inseguimento
automatico del contratto 4D assegnato tramite
azioni su tutti i canali di controllo, anche
simultaneamente, invece che sul solo canale di
velocità.
Il 4DMS module, al fine di rispettare il vincolo temporale su ciascun
WP, dovrà essere in grado di agire sia sul riferimento di velocità che
su quello di traiettoria che su entrambi, sempre nel rispetto dei
vincoli dinamici e di performance del velivolo nonché dei vincoli
imposti dal contratto 4D assegnato.
Al fine di garantire il pieno successo
nell'implementazione automatica del contratto
Monitoraggio
Il 4DMS module dovrà costantemente monitorare l’andamento della 4D assegnato, il 4DMS module dovrà
continuo
TECV2-SUBS- 4DMS- 00080_0.0
missione e prevedere eventuali scostamenti futuri del velivolo dal implementare un'adeguata frequenza di
dell'applicazione
aggiornamento dei parametri caratterizzanti il
contratto assegnato.
del contratto
comportamento del velivolo rispetto al
contratto assegnato.
91
CIRA-CF-12-0600 Rev. 1 P. 91/109
TECVOL-II
TECVOL-II - System Requirements
TECV2-SUBS- 4DMS- 00090_0.0
TECV2-SUBS- 4DMS- 00100_0.0
TECV2-SUBS- 4DMS- 00110_0.0
3.4.2.3
CIRA-CF-12-0600
Rinegoziazione
on-line del
contratto
assegnato
Nel caso in cui la nuova traiettoria e/o il nuovo riferimento di velocità
rigenerati non dovessero rispettare i margini spaziali e/o temporali
richiesti dal contratto assegnato, il 4DMS module dovrà comunicare
tale circostanza al segmento di terra, trasmettendogli altresì l'ultima
traiettoria e profilo di velocità generati al fine di chiedere
l'approvazione delle variazioni al contratto che essi implicano.
Gestione delle
no-fly zones
La flessibilità che si richiede ai contratti 4D nel
Il 4DMS module dovrà essere in grado di rigenerare in linea la
futuro scenario ATM implica che il 4DMS
traiettoria e/o il profilo di velocità del velivolo al fine di evitare no fly
module dovrà essere in grado di gestire anche
zones fisse, nel rispetto (ove possibile) del contratto originale
le no fly zones, almeno limitatamente a quelle
assegnato al velivolo.
fisse.
Gestione
simultanea di
più WPs 4D
Il 4DMS module dovrà essere in grado di
Il 4DMS module dovrà essere in grado di rigenerare la traiettoria e/o il ottimizzare il volo tenendo conto dell’insieme
profilo di velocità del velivolo, al fine di rispettare il contratto 4D dei WPs da raggiungere e non di un solo WP alla
assegnato, tenendo conto non solo del WP 4D attulamente volta (come invece implementato nel 4DAMF di
considerato come target ma anche dei WPs successivi.
TECVOL I e, conseguentemente, nel 4DPE di
TECVOL II)
La flessibilità che si richiede ai contratti 4D nel
futuro scenario ATM implica che il 4DMS
module dovrà essere in grado di gestire, almeno
in maniera basica, la rinegoziazione tattica del
contratto medesimo.
Traffic & Obstacle Avoidance System (TOAS)
3.4.2.3.1 Descrizione sintetica del sistema
Nella presente sezione sono descritti, sotto forma di appositi requisiti, gli obiettivi che si intende raggiungere attraverso lo sviluppo, in ambito
TECVOL II, della funzione Traffic and Obstacle Avoidance System (di seguito sinteticamente indicata con l’acronimo TOAS). A tale sistema è
associato l’identificativo S20.
3.4.2.3.2 Giustificazione
Tale funzione è finalizzata a costituire un significativo incremento rispetto a quanto già implementato in TECVOL I e portato a maturazione
tecnologica fino a TRL 6 (cfr. documento di riferimento [R26][R26] e sezione 3.2.1.1 del presente documento). Le caratteristiche innovative di tale
92
CIRA-CF-12-0600 Rev. 1 P. 92/109
TECVOL-II
TECVOL-II - System Requirements
CIRA-CF-12-0600
funzione sono state sinteticamente illustrate nel documento ConOps TECVOL II [A1] e vengono qui pertanto completate ed espresse sotto forma di
appropriati requisiti utente.
Nella redazione dei requisiti riportati in questa sezione, pertanto, si è tenuto conto del ConOps di TECVOL II [A1], nonché delle competenze
acquisite in materia di automatic collision avoidance ed automatic self-separation nell’ambito del progetto in corso MIDCAS (Mid-Air Collision
Avoidance System, finanziato da EDA).
Il sistema TOAS specificato nei seguenti paragrafi, sebbene sia riferito a velivoli manned, sarà sviluppato sulla base della linea tecnologica prevista
in [A1] L1-T2 riguardante lo sviluppo di funzionalità per l’esecuzione automatica di particolare fasi del volo ed in particolare l’evoluzione delle
tecnologie per il Sense&Avoid del traffico circostante.
3.4.2.3.3 Metodo di verifica
VM_Demonstration (CAM)
3.4.2.3.4 Requisiti di progetto
ID
Titolo
Descrizione
TECV2-SUBS- TOAS- 00010_0.0
Il modulo TOAS dovrà essere progettato per l'applicazione generale al
Applicabilità del
segmento di volo di cruise, andando ad escludere esplicitamente
TOAS Module
l'applicazione alle fasi di take off e landing.
TECV2-SUBS- TOAS- 00020_0.0
Traffic and
obstacle
In TECVOL II si dovrà investigare, in termini di studio di fattibilità, la
avoidance nelle possibilità di estendere le funzionalità di traffic e obstacle avoidance
fasi di take-off e anche alle fasi di take off e landing.
landing
Rationale
Si ritiene opportuno limitare lo sviluppo del
sistema TOAS alla fase di cruise, andando ad
esaminare l'applicabilità di tale sistema alle fasi
di take-off e landing solo in termini di studio di
fattibilità.
Ciò in quanto si prevede che l'implementazione
effettiva dell'estensione del sistema TOAS a
coprire le fasi di take-off e landing protrebbe
richiedere eccessive risorse rispetto a quelle
disponibili ed inoltre le modalità di gestione
della collision avoidance e della self separation
nelle fasi di take-off e di landing non sono
ancora ben chiare. In tali fasi, infatti, è tuttora
nettamente maggiore l'importanza del ruolo
svolto dal sistema ATC piuttosto che da
algoritmi automatici di bordo.
93
CIRA-CF-12-0600 Rev. 1 P. 93/109
TECVOL-II
TECVOL-II - System Requirements
CIRA-CF-12-0600
Il TOAS module, benchè concepito per l'impiego
in velivoli manned, deve essere in grado di
gestire la separazione del velivolo in maniera
completamente automatica.
Ove il pilota decidesse di mantenere la guida del
velivolo, il TOAS module continuerebbe ad
elaborare i medesimi outputs, da intendersi in
tal caso come suggerimenti al pilota invece che
come comandi di guidance automatica del
velivolo.
Si richiede lo sviluppo di un unico modulo in
grado di gestire in maniera automatica sia la
collision avoidance che la self separation, cioè in
grado di agire sia a livello tattico che a livello di
emergenza.La presenza della funzionalità di
automatic self-separation costituisce una novita
assoluta rispetto a quanto fatto in TECVOL I.
TECV2-SUBS- TOAS- 00030_0.0
Funzionalità del
TOAS Module
Il TOAS module dovrà essere in grado di generare automaticamente i
riferimenti necessari (manovra di avoidance) per assicurare al velivolo
il mantenimento di un'adeguata distanza di separazione rispetto ai
velivoli circostanti ed agli ostacoli. Il TOAS module dovrà essere in
grado a tal fine di gestire sia potenziali conflitti a livello tattico
(perdita della prescritta separazione minima) che a livello di
emergenza (collisioni).
TECV2-SUBS- TOAS- 00040_0.0
Considerazione
dei vincoli
cinematici e
dinamici del
velivolo
La considerazione dei vincoli caratterizzanti il
Il TOAS module dovrà considerare, già nell'algoritmo di ottimizzazione
velivolo già in sede di posizione del problema di
vincolata finalizzato all'elaborazione della manovra di avoidance, i
ottimizzazione vincolata mira a garantire che la
vincoli cinematici e dinamici (fattore di carico massimo e raggio di
manovra di avoidance elaborata sia compatibile
curvatura minimo) caratterizzanti il velivolo.
con le prestazioni del velivolo.
In TECVOL II si intende mantenere
l'impostazione generale di manovra 3D che è
Il TOAS module dovrà elaborare una manovra di avoidance (sia a
Tridimensionalità
stata messa a punto in TECVOL I, andando però
livello tattico che a livello strategico) che si sviluppi, se necessario, in
TECV2-SUBS- TOAS- 00050_0.0 della manovra di
a tenere in conto nell'effettiva elaborazione
uno spazio 3D (cioè agendo simultaneamente su tutte e tre le
avoidance
della manovra anche le regole dell'aria e la
componenti del vettore velocità).
compatibilità con il TCAS, come da requisiti
specifici.
TECV2-SUBS- TOAS- 00060_0.0
Considerazione
di velivoli non
cooperativi
Il modulo dovrà essere utilizzabile in condizioni
Il TOAS module dovrà essere in grado di assicurare il mantenimento di del tutto generali, quindi dovrà esssere in grado
un'adeguata separazione del velivolo rispetto a velivoli sia di tipo di svolgere la sua funzione sia nei confronti di
velivoli di tipo cooperativo che nei confronti di
cooperativo che di tipo non cooperativo.
velivoli di tipo non cooperativo.
94
CIRA-CF-12-0600 Rev. 1 P. 94/109
TECVOL-II
TECVOL-II - System Requirements
TECV2-SUBS- TOAS- 00070_0.0
Considerazione
delle regole
dell'aria
TECV2-SUBS- TOAS- 00080_0.0
Considerazione
della
compatibilità
TCAS II
CIRA-CF-12-0600
Il TOAS module dovrà generare una manovra di avoidance che tenga La compatibilità della manovra generata (sia per
conto delle regole dell'aria.
esigenze di collision avoidance che per esigenze
di mantenimento della separazione) con le
regole dell'aria e con il sistema TCAS II è
finalizzata a consentire l'applicabilità del
Il TOAS module dovrà generare una manovra di avoidance che sia sistema TOAS in spazi aerei non segregati.
compatibile con la logica di detection e di evasione del sistema TCAS
II..
Questo requisito costituisce un miglioramento
Il TOAS module dovrà essere in grado di garantire simultaneamente la
fondamentale di quanto fatto (peraltro solo a
Gestione di
separazione del velivolo (sia a livello tattico che in emergenza)
livello di manovra in emergenza, cioè di collision
TECV2-SUBS- TOAS- 00090_0.0
intruder multipli rispetto a molteplici intruder (fino ad un numero massimo da stabilire
avoidance) in TECVOL I, laddove si considerava
nel corso del progetto).
un solo intruder.
TECV2-SUBS- TOAS- 00100_0.0
Capacità di
nuisance-free
deconfliction
Il requisito è motivato dalla circostanza che, in
uno spazio aereo congestionato (nel quale
presumibilmente molteplici velivoli sono
presenti nel volume operativo del sistema di
Il TOAS module dovrà essere in grado di elaborare una manovra di
Traffic Awareness and Alerting e, quindi , del
avoidance che risolva tutti i conflitti individuati (conflitti primari)
sistema TOAS), sono non trascurabili le
senza crearne di nuovi (conflitti secondari).
probabilità che la deconfliction rispetto ai
velivoli attualmente in conflitto generi nuovi
conflitti rispetto a velivoli che inizialmente
erano conflict-free.
TECV2-SUBS- TOAS- 00110_0.0
Minimizzazione
dello
scostamento
rispetto alla
traiettoria
nominale
Il requisito mira a garantire che il sistema TOAS
Nell'elaborazione della manovra di avoidance (sia a livello tattico che
non generi manovre impattanti più del
in emergenza), il TOAS module dovrà essere in grado di minimizzare
necessario sullo svolgimento della missione
lo scostamento dalla traiettoria nominale del velivolo.
complessiva del velivolo.
95
CIRA-CF-12-0600 Rev. 1 P. 95/109
TECVOL-II
TECVOL-II - System Requirements
In TECVOL II si dovrà investigare, in termini di studio di fattibilità, la
possibilità di sviluppare un sistema TOAS in grado di generare
Massimizzazione
manovre di avoidance (sia in senso tattico che in emergenza) che
TECV2-SUBS- TOAS- 00120_0.0 della persistenza
tengano anche conto dell'esigenza di mantenere il velivolo (o i
della detection
velivoli) in conflitto all'interno del campo di vista del sistema di Traffic
Awareness and Alerting.
3.4.2.4
CIRA-CF-12-0600
Il fine dello studio di fattibilità proposto è
l'investigazione della possibilità di minimizzare
le situazioni in cui l'esecuzione della manovra di
avoidance da parte del velivolo comporti la
fuoriuscita di uno o più velivolo in conflitto dal
campo di vista del sistema di Traffic Awareness
(tale circostanza risulta più probabile in caso di
manovre di emergenza, in quanto di solito
effettuate a massimo comando o quasi).
Multi-Functional Display & Decision System (MFDD)
3.4.2.4.1 Descrizione sintetica del sistema
Il sistema MFD&D dovrà sintetizzare in maniera grafiche tutte le informazioni che permettono al pilota di ottimizzare la conoscenza dell’ambiente
in cui il velivolo si trova ad operare. Tali informazioni potranno riguardare i dati meteo, i dati di traffico (sia in volo che su pista), i dati
dell’orografia del terreno, nonché tutte le informazioni relative alla traiettoria del velivolo.
A tale scopo il sistema dovrà interfaccerà con i moduli di Weather Situational Awareness, Terrain Situational Awareness, Traffic Awareness and
Alerting, Traffic & Obstcale Avoidance. Inoltre potrà essere utilizzato anche per tutti gli altri tool per l’awareness che saranno sviluppati
nell’ambito del progetto TECVOL-II (§3.4.1).
Tale sistema non dovrà limitarsi alla sola rappresentazioni grafica di informazioni provenienti da altri sistemi/ sensori o canali di comunicazione, ma
dovrà essere dotato di tools di supporto alle decisioni del pilota. In tale ambito ricadano i tool di generazione della traiettoria che dovranno
permettere al pilota, in maniera semplice, di pianificare la missione e/o gestire eventuali emergenze o situazioni estemporanee non note o predicibili
durante la pianificazione strategica della missione. A tale sistema è associato l’identificativo S21.
3.4.2.4.2 Giustificazione
La definizione dei requisiti di progetto relativi al sistema Multi Functional Display and Decision è basata sull’analisi di sistemi analoghi rivolti a
velivoli della classe VLA e General Aviation (rif Honeywell Bendix/King KMD 550 e KMD 850; rif Avidyne’s EX 500; rif Garmin GX 200). Gli
enhancements proposti rispetto a tali dispositivi derivano dall’analisi del documento di CONOPS TECVOL-II, tenuto conto dei sistemi che si
interfacceranno con il MFDD. Tali miglioramenti possono essere inquadrati essenzialmente in due aree: i) Situation Awareness e ii) Supporto alle
96
CIRA-CF-12-0600 Rev. 1 P. 96/109
TECVOL-II
TECVOL-II - System Requirements
CIRA-CF-12-0600
operazioni di guida del pilota. Per quanto riguarda la Situation Awareness i miglioramenti riguardano una migliore rappresentazione dei dati
provenienti dai sistemi con cui l’MFDD si interfaccia (ad esempio dati meteo, dati di traffico e di orografia del terreno) ed una sinterizzazione dei
dati stessi in un’unica interfaccia fornendo al pilota una visione complessiva dell’ambiente circostante senza dover cambiare finestra di
visualizzazione.
Per quanto riguarda il supporto al pilota, gli ambiti di sviluppo riguardano sia tutte le operazioni di supporto alla definizione del piano di volo che la
risoluzione di situazioni che impattano sul piano di volo corrente e non erano predicibili in fase di pianificazione strategica della missione. Un
ulteriore aspetto di miglioramento rispetto ai prodotti attuali è sicuramente la riduzione del peso e del costo.
Il sistema MFD&D specificato nei seguenti paragrafi, sebbene sia riferito a velivoli manned, sarà sviluppato sulla base delle linee tecnologiche
previste in [A1] L1-T1, L1,T2, L2-T2, L2-T3 riguardanti l’ausilio alla ripianificazione automatica di un piano di volo ed alla sua esecuzione
automatica nel rispetto delle informazioni di situational awareness riguardanti il terreno sottostante il velivolo e le condizioni meteo lungo le
possibili rotte compatibili con la posizione attuale e la destinazione desiderata. Inoltre è applicabile anche la tecnologia L3-T3 di [A1] relativa allo
sviluppo delle interfacce uomo macchina utili al supporto alla guida manuale e/o automatica.
3.4.2.4.3 Metodo di verifica
VM_Demonstration (CAM)
3.4.2.4.4 Requisiti di progetto
TECV2-SUBS-
ID
MFDD-0001
0_0.0
TECV2-SUBS-
MFDD-0002
0_0.0
TECV2-SUBS-
MFDD-0003
0_0.0
Titolo
Registrazione dati di
Volo
Interfaccia di
comunicazione con
SATCOM
Visualizzazione dei
dati di volo
Descrizione
Il Multi-Functional Display dovrà effettuare la registrazione dei dati di volo
connessi alla guida, navigazione e controllo del velivolo.
Il Multi-Functional Display dovrà possedere un'interfaccia di trasmissione dati
da/verso un ricevitore di comunicazione satellitare.
Rationale
Il Multi-Functional Display dovrà possedere un'interfaccia grafica per la
visualizzazione sia dei dati provenienti dai sensori di bordo che trasmessi a bordo
mediante i link di comunicazione con cui il sistema si interfaccia.
97
CIRA-CF-12-0600 Rev. 1 P. 97/109
TECVOL-II
TECVOL-II - System Requirements
CIRA-CF-12-0600
TECV2-SUBS-
MFDD-0004
0_0.0
Pianificazione
Il Multi-Functional Display dovrà possedere una funzionalità di pianificazione
Strategica del piano di strategica della traiettoria basata su:
volo
1) un criterio selezionabile dal pilota fra un set limitato (minimo consumo,
minima distanza, minimo tempo, tempo di arrivo predefinito [TBC]);
2) il punto attuale ed il punto di destinazione;
3) vincoli noti a priori;
TECV2-SUBS-
MFDD-0005
0_0.0
Ripianificazione
tattica della
traiettoria
Il Multi-Functional Display dovrà possedere una funzionalità di ripianificazione
tattica della traiettoria che risolva minacce impellenti (ad esempio modificate
condizioni di meteo e/o traffico e/o NOTAM in genere) ma non modifichi il piano
di missione a lungo termine. L'attivazione della nuova traiettoria è sempre
sottoposta all'approvazione del pilota.
Tale funzionalità gestirà
eventuali minacce
presenti fra due
Waypoints.
TECV2-SUBS-
MFDD-0006
0_0.0
Visualizzazione
virtuale dello spazio
aereo
Il Multi Functional Display dovrà riassumere i dati relativi alle condizioni meteo,
di traffico (in volo e a terra), altimetria del terreno e, se disponibili, le mappe
aeroportuali, nonché eventuali informazioni e/o allarmi provenienti dai sistemi di
Terrain Awareness and Alerting, Weather Awareness e Traffic and Obstacle
Avoidance in una visione virtuale dello spazio aereo circostante il velivolo.
Tale funzionalità può
essere di ausilio al
pilotaggio in condizioni
di scarsa visibilità.
TECV2-SUBS-
MFDD-0007
0_0.0
Ripianificazione
d'emergenza del
piano di volo
Il Multi Functional Display dovrà possedere una funzionalità di generazione della
traiettoria che, attivata dal pilota, elabori una traiettoria di emergenza che tenga
conto dei mutati limiti di inviluppo del velivolo, eventuali failures dei sensori o
altre condizioni critiche per la guida, navigazione e controllo del velivolo.
TECV2-SUBS-
MFDD-0008
0_0.0
Warning per
impossibilità di
completamento del
piano di volo
Il Multi Functional Display dovrà generare e visualizzare un segnale d'allarme se il Nel caso in cui si
piano di volo corrente intercetta una no-fly zone (ad esempio modificate
presentino, a valle della
condizioni di meteo e/o traffico e/o NOTAM in genere).
pianificazione strategica,
delle mutate condizioni
che rendono non
attuabili il piano di volo
corrente il sistema dovrà
generare un segnale di
allarme. Spetterà, però,
al pilota decidere le
azioni da intraprendere.
98
CIRA-CF-12-0600 Rev. 1 P. 98/109
TECVOL-II
TECVOL-II - System Requirements
3.4.2.1
CIRA-CF-12-0600
Smart Autopilot (SMAP)
3.4.2.1.1 Descrizione sintetica del sistema
Il progetto TECVOL-II si sistematizzare le tecnologie già sviluppate nell’ambito del progetto TECVOL-I relativamente alle linee di controllo del
velivolo assimilabili a modi di Autopilota e/o di Flight Director ed allo sviluppo di Smart Actuator già previsti in ambito del progetto MISE [R49].
Il sistema di Smart Autopilot (da qui in poi identificato con la sigla SMAP) sarà però completato con delle funzionalità di carattere innovativa
rispetto a quanto presente allo stato dell’arte nel mercato degli Autopiloti per la classe di velivoli General Aviation. In particolare lo SMAP dovrà
essere in grado di gestire in modo automatico condizioni di emergenza come la failure di sistemi non critici, la fuori uscita dell’inviluppo di volo
operativo del particolare velivolo ed il degrado delle performance dei modi di autopilota già ingaggiati. In seguito alle sopracitate condizioni non
nominali lo SMAP dovrà individuare ed ingaggiare la configurazioni di modi automatici sui diversi assi più opportuna per fronteggiare la
sopraggiunta emergenza. Contestualmente sarà avvisato il pilota del cambio di configurazione, il quale potrà in ogni momento riprendere il
controllo del velivolo disingaggiando lo SMAP. A tale sistema è associato l’identificativo S22.
3.4.2.1.2 Giustificazione
Lo SMAP specificato nei seguenti requisiti, sebbene sia riferito a velivoli manned, sarà sviluppato sulla base della linea tecnologica prevista in [A1]
L1-T2 riguardante lo sviluppo di funzionalità per l’esecuzione automatica della fase di crociera di un volo. Inoltre è applicabile anche la tecnologia
L3-T3 di [A1] relativa allo sviluppo delle interfacce uomo macchina utili al supporto alla guida manuale e/o automatica.
3.4.2.1.3 Metodo di verifica
VM_Demonstration (CAM)
3.4.2.1.4 Requisiti di progetto
TECV2-SUBS-
ID
SMAP-0001
0_0.0
Titolo
Smart Autopilot
Descrizione
Rationale
Il sistema SMAP dovrà implementare, per il velivolo di riferimento selezionato, le
tipiche funzionalità di Autopilota e/o di Flight Director comprendendo la
seguente lista di modi standard di Autopilota:
1. Pitch Attitude Hold PAH
2. Heading Hold HH
99
CIRA-CF-12-0600 Rev. 1 P. 99/109
TECVOL-II
TECVOL-II - System Requirements
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
TECV2-SUBS-
SMAP-0002
0_0.0
Condizioni offnominal
TECV2-SUBS-
SMAP-0003
0_0.0
HMI
TECV2-SUBS-
SMAP-0004
0_0.0
Validazione della
configurazione
TECV2-SUBS-
SMAP-0005
0_0.0
Pilot Control
CIRA-CF-12-0600
Altitude Hold AH
Heading Select HS
Altitude Select / VNAV AS
Wing Leveler WL
IAS Hold IMH
Roll Attitude Hold RAH
Glide Slope APPR_GS NAV /LNAV NAV
Vertical Speed Hold VSH
Track Select TRK
Localizer APPR_LOC
Back Course BC
Lo SMAP dovrà essere in grado di gestire in modo automatico condizioni di
emergenza come la failure di sistemi non critici, la fuori uscita dell’inviluppo di
volo operativo del particolare velivolo ed il degrado delle performance dei modi
di autopilota già ingaggiati. In seguito alle sopracitate condizioni non nominali lo
SMAP dovrà individuare ed ingaggiare la configurazioni di modi automatici sui
diversi assi più opportuna per fronteggiare la sopraggiunta emergenza.
Il pilota avrà la possibilità, attraverso un’opportuna HMI, di configurare lo SMAP
ed ingaggiare la configurazione di modi automatici desiderata in modalità
Aupilota o in modalità Flight Director.
Ad ogni variazione della configurazione dei modi eseguita dal pilota, lo SMAP
opererà una validazione della configurazione e renderà operativa l’impostazione
del pilota solo in caso di esito positivo. In caso contrario, lo SMAP utilizzerà
l’ultima configurazione di volo valida.
Contestualmente ad eventuali cambi di configurazione dei modi ingaggiati per
fronteggiare condizioni off-nominal il pilota sarà prontamente avvisato i In ogni
momento il pilota potrà riprendere il controllo del velivolo disingaggiando lo
SMAP.
100
CIRA-CF-12-0600 Rev. 1 P. 100/109
TECVOL-II
TECVOL-II - System Requirements
CIRA-CF-12-0600
4 Road map tecnologica del progetto
4.1 Road map e milestones di progetto
Le linee guida seguite per la pianificazione preliminare del progetto sono state descritte nel §8 di [A1]. L’approccio scelto è stato quello un “ciclo a
V con spirale” che si differisce dal classico ciclo a V in quanto, a partire dalle fasi di sviluppo successive all’individuazione dei project requirements
dei diversi sistemi selezionati come strategici, individua un processo a spirale con sviluppi incrementali per poi chiudersi di nuovo con la parte
finale del ciclo a V attraverso l’acceptance review finale.
Tale approccio è stato scelto per la peculiarità del progetto che non si riferisce allo sviluppo di un singolo sistema (sebbene complesso) ma bensì ad
una classe di sistemi/tecnologie anche se tutti orientati all’incremento del livello di autonomia nella gestione della missione di volo per velivoli
unmanned che manned di piccole dimensioni. In Tabella 4-1 è riportata una matrice di tracciabilità tra i prodotti previsti e specificati nel precedente
capitolo (per i quali è riportata anche la sigla identificativa associata ai relativi requisiti) e le linee tecnologiche individuate nel documento di
Conops già riportate in Tabella 2-1.
Va comunque evidenziato che alcuni dei sistemi/tecnologie specificati sono tra loro strettamente correlati, si potrebbe quasi definire una sorta di
propedeuticità andando ad individuare dei sistemi/tecnologie più complessi (che saranno ultimati negli ultimi due anni del progetto) che in qualche
modo inglobano alcuni dei sistemi precedentemente sviluppati. Come conseguenza di ciò, gli step incrementali previsti dall’approccio sostenuto
sono applicabili sia a livello di progetto sia a livello dei vari sistemi/tecnologie il cui sviluppo è previsto nel progetto stesso.
L’approccio “a V con spirale” dunque permetterà di produrre dei risultati più tangibili fin dai primi anni del progetto in modo da semplificare anche
il compito di eventuali revisori nel giudicare gli avanzamenti intermedi del progetto stesso.
Inoltre, con lo stesso obiettivo sopra espresso e come ampiamente discusso nel §2.3, il progetto TECVOL-II verrà condotto in maniera da garantire
la massima sinergia con il progetto MISE, finanziato nell’ambito della legge 808/95 e finalizzato alla realizzazione di applicativi SW di bordo per la
gestione di UAS della classe MALE nell’esecuzione di missioni di sorveglianza. Per quanto riguarda la messa a fattor comune dei risultati
conseguiti nell’ambito dei due progetti, ciò verrà nella sostanza implementato attraverso l’utilizzo in ambito TECVOL-II, previa opportuna
customizzazione laddove necessaria, dei tools e facilities di verifica e validazione di SW safety critical sviluppati e messi a punto nell’ambito del
progetto MISE e sinteticamente descritti nel §2.4. In definitiva nel progetto MISE saranno sviluppati dei dimostratori tecnologici di sistemi avionici
per velivoli UAV, chei saranno sfruttati anche per i processi di verifica e validazione dei sistemi/tecnologie sviluppati in TECVOL-II.
101
CIRA-CF-12-0600 Rev. 1 P. 101/109
TECVOL-II
TECVOL-II - System Requirements
CIRA-CF-12-0600
L’implementazione di tale sinergia ha portato alla definizione di una road-map tecnologica comune afferente ad entrambi i progetti mostrata in
Figura 4-1.
ID
Sigla (§3)
S01
S02
S03
S04
S05
ACAM
ATOF
ALEV
4DPE
RPVE
S06
S07
S08
S09
S10
S11
S12
S13
S14
HAPR
AFCL
IHMG
ATRP
ATMA
PSMP
PAMP
ATDR
DTLK
S15
S16
S17
S18
S19
S20
S21
S22
WSAS
TRAW
TAWS
ADCO
4DMS
TOAS
MFDD
SMAP
Sistema specificato (§3)
§
Tecnonlogie [A1]
Tecnologie di volo autonomo per UAV (da TECVOL-I)
Autonomous Collision Avoidance Multisensor based 3.2.1.1 L1-T2
Automatic Take Off
3.2.1.2 L1-T2
Autolanding EGNOS &Visual-based
3.2.1.3 L1-T2, L1-T6, L1-T7
Automatic 4D plan execution
3.2.1.4 L1-T2
Remote Piloting Vehicle
3.2.1.5 L3-T3
Tecnologie di volo autonomo per UAV
Autonomous Mission Manager
3.3.1.1 L1-T1
Adaptive Flight Control Law
3.3.1.2 L1-T3
Tecnologie per l’Integrated Health Management
3.3.1.3 L1-T4, L1-T5
AutomaticTaxi Replanner
3.3.1.4 L1-T2
Automatic Taxi Management
3.3.1.5 L1-T2
Preflight Support Mission Planner
3.3.2.1 L3-T1
Preflight Automatic Mission Planner
3.3.2.2 L3-T1
Automatic Target Detection and Recognition System 3.3.2.3 L2-T4, L2-T5
Reconfigurable Datalink
3.3.3.1 L4-T1
Sistemi avanzati di ausilio al pilotaggio per velivoli manned PATS
Weather Situational Awareness System
3.4.1.1 L2-T2
Traffic Awareness and Alerting System
3.4.1.2 L2-T1
Terrain Situational Awareness System
3.4.1.3 L2-T3
Advanced Cockpit
3.4.2.1 L2-T1, L2-T2, L2-T3, L3-T3
4D Contract Management System
3.4.2.2 L1-T2
Traffic & Obstacle Avoidance System
3.4.2.3 L1-T2, L2-T1
Multi-Functional Display & Decision System
3.4.2.4 L1-T1, L1,T2, L2-T2, L2-T3, L3-T3
Smart Autopilot
3.4.2.1 L1-T2, L3-T3
Tabella 4-1 – Matrice di tracciabilità project requirements / tecnologie individuate nei Conops
102
CIRA-CF-12-0600 Rev. 1 P. 102/109
TECVOL-II
TECVOL-II - System Requirements
12/2012
06/2012
12/2013
06/2013
AL EGNOS (Vers. Intermedia) ALEV
Preflight Mission Planner PSMP
Auto Take-off ATOF
ACAM
CIRA-CF-12-0600
12/2015
12/2014
12/2016
4D Auto Plan Exec. 4DPE
RPVE
HIL
FLARE
FLARE
Auto Mission RePlanner (ALN)
Aereal Video Compression
Payload Sensors Simulation
ATM SIM-0
SIL
IMA
FT Navigation Unit
Auto Taxi Replanner ATRP
Reconfigurable Datalink DTLK
HIL
IMA
SMART AP
AL EGNOS & Visual ALEV
Image Senor Management
Autonomous Target Detection ATDR
Traffic Avoidance TOAS
Legenda:
FLARE II
Auton. Target Tracking
TECVOL-II
Auton. Mission Manager HAPR
Auton. Taxi Manager ATMA
FLARE II First Flight
MISE
Autonomy Managementr (ALN)
COCKPIT
AVIONICO
MANNED
CAM standard
Traffic Awareness TRAW
Weather Awareness WSAS
Advanced Cockpit ADCO
MFD & Decision System MFDD
Terrain Awareness TSAS
4D Contract Mng 4DMS
Traffic Avoidance TOAS
Figura 4-1 – Road Map tecnologica congiunta dei progetti TECVOL-II - MISE
103
CIRA-CF-12-0600 Rev. 1 P. 103/109
TECVOL-II
TECVOL-II - System Requirements
CIRA-CF-12-0600
Per una descrizione delle tecnologie da sviluppare nel progetto MISE mostrate nella road map si faccia riferimento al documento [R49]. Come si
può dedurre dalla figura sopra mostrata è previsto nell’ambito dei due progetti uno sviluppo graduale sia dei vari dimostratori tecnologici quali il
SIL-IMA, l’HIL-IMA, il dimostratore volante FLARE-II ed il Cockpit Avionico Manned, (si rimanda al §2.4 per una loro descrizione) che si
affiancano al dimostratore volante FLARE-I ed al suo HIL ereditati dal progetto TECVOL-I, sia delle diverse tecnologie che saranno verificate e
validate per mezzo di essi.
Le interazioni tra i due progetti riguardano quindi essenzialmente lo sviluppo dei suddetti dimostratori in MISE in modo che siano pronti secondo il
piano temporale mostrato nella Road Map e siano compatibili con i sistemi da validare in ambito TECVOL-II. Tale compatabilità sarà garantita dal
fatto che le sinergie messe in campo tra i due progetti riguardano anche la modalità di gestione attuata, infatti a partire da Gennaio 2012 è operativa
una modalità di gestione congiunta delle attività dei due progetti che nello specifico prevede una pianificazione singergica delle attività, meeting
avanzamento congiunti e lista delle actions congiunte.
Infine si evidenzia che laddove il finanziamento MISE dovesse venire meno l’azione di mitigazione prevista sarà quella di finanziare con i soldi
PRORA nell'ambito TECVOL-II le facilities di sperimentazione necessarie eventualmente ridimensionando il numero di sistemi che il progetto
prevede di sviluppare secondo quelle che sono le priorità già espresse sulle tecnologie individuate in [A1] e quindi sui relativi sistemi specificati nel
presente documento.
Le milestones di programma previste per il progetto TECVOL-II nell’ambito del piano triennale 2012-2014 vigente [R1] sono quelle mostrate in
Tabella 4-2.
Nr.
SBA04
SBA18
SBA15
Milestone
SRR-Requisiti del Sistema di Gestione della Missione
DDR – Detailed Design Review del Sistema di gestione della
missione validato on-ground
Rilascio algoritmi per un sistema di gestione di missione
autonoma di UAV
Data prevista
Maggio 2012
Giugno 2014
Dicembre 2015
Tabella 4-2 – Milestones di programma afferenti al progetto TECVOL-II a piano triennale vigente [R1]
La milestone SBA04 sarà raggiunta attraverso la review di [A1] e del presente documento. Sulla base di quanto proposto nell’ambito del presente
documento, tenendo conto anche della complessità del progetto come si è venuta a determinare in fase di definizione dei project requirements.
104
CIRA-CF-12-0600 Rev. 1 P. 104/109
TECVOL-II
TECVOL-II - System Requirements
CIRA-CF-12-0600
nonché della sinergia con il progetto MISE, in questa sede si intende sottoporre a revisione e quindi ad approvazione una nuova configurazione delle
milestones di progetto di cui alla Tabella 4-3.
In particolare è stata aggiunta un’ulteriore milestone di programma legata alla validazione in volo delle tecnologie sviluppate nel progetto
TECVOL-I solo fino ad un TRL 5 (cfr. §3.2) denominata AR-F1.
Nr.
SBA04
AR-F1
SBA18
SBA15
Milestone
SRR-Requisiti del Sistema di Gestione della Missione
Validazione in volo delle tecnologie sviluppate in TECVOL-I
DDR – Detailed Design Review del Sistema di gestione della
missione validato on-ground
Rilascio algoritmi per un sistema di gestione di missione
autonoma di UAV
Data prevista
Giugno 2012
Dicembre 2013
Giugno 2015
Dicembre 2016
Tabella 4-3 - Milestones di programma afferenti al progetto TECVOL-II proposta aggiornata
La milestone SBA18 sarà posticipata di un anno e sarà legata alla validazione dei diversi sistemi e tecnologie sviluppate sui dimostratori tecnologici
di laboratorio quali l’HIL-IMA ed il CAM. Infine la milestone SBA15 sarà anch’essa posticipata di un anno e sarà legata alla validazione dei diversi
sistemi e tecnologie sviluppate sul dimostratore volante FLARE-II. Si evidenzia che l’allungamento di un anno sulla durata complessiva del
progetto è peraltro compensata dal fatto che grazie all’approccio di sviluppo scelto, per ciascuno dei prossimi anni da oggi fino al completamento
del progetto si prevedono dimostrazioni di specifici sistemi/tecnologie intermedi. Le tre milestones PRORA suddette sono anche evidenziate nella
road map di Figura 4-1 con dei pallini rossi.
Per completare la tracciabilità tra le linee tecnologie individuate nei Conops ed la serie di sistemi/tecnologiespecificati nel presente documento, in
Tabella 4-4 si riporta anche la matrice di tracciabilità inversa.
ID Tecnologia [A1]
L1-T1
L1-T2
L1-T3
L1-T4
L1-T5
Nome Tecnologia Proposta in [A1]
Autonomous Mission Management
Autonomous Mission Execution
Adaptive Flight Control Law
Failure & Health Monitoring
On Line Identification
ID Sistema specificato (§3)
S01
S01, S02, S03, S09, S10, S19, L1-T2, L1-T2
S07
S08
S08
105
CIRA-CF-12-0600 Rev. 1 P. 105/109
TECVOL-II
TECVOL-II - System Requirements
L1-T6
L1-T7
L1-T8
L2-T1
L2-T2
L2-T3
L2-T4
L2-T5
L3-T1
L3-T2
L3-T3
L4-T1
L4-T2
L4-T4
Sensor Management and Navigation
Vision-aided Navigation
Metodi di verifica e qualification kit
Traffic awareness
Atmospheric Situational Awareness
Terrain Situational Awareness
Automatic Target Recognition and detection
SAR-based surveillance
Mission Planner
Augmented Vision
GCS/HMI
Datalink riconfigurabile
Fattibilità datalink per flotta UAV
Power Line Communication
CIRA-CF-12-0600
S03
S03
Vedi §2.4, §3.1 e §4.2
S16, S18, S20
S15, S18, S21
S17, S21
S13
S13
S11, S12
S05, S18, S21, S22
S14
Tabella 4-4 – Matrice di tracciabilità tecnologie individuate nei Conops / project requirements
In particoalre, come si può dedurre dalla Tabella 4-4 tutte le linee tecnologiche giudicate “essential” in Tabella 2-1 (che riporta la Tabella 5 definita
in [A1]) sono state mappate in specifici sistemi/tecnologie da sviluppare nel progetto, inoltre anche le linee tecnologiche L1-T3 (Adaptive Flight
Control Law), L1-T4 (Failure & Health Monitoring), L1-T5 (On Line Identification) e L2-T5 (SAR-based surveillance) giudicate “desirable” sono
comunque state considerate nella specifica dei vari sistemi. Fuori dalla pianificazione nell’orizzonte temporale 2011-2016 del progetto restano solo
le altre linee tecnologie giudicate “desirable” o “optional” (L3-T2, L4-T2 e L4-T4) per le quali al momento non esistono risorse disponibili.
4.2 Organizzazione dei deliverable di progetto
Lo sviluppo di ogni sistema/tecnologia ed il relativo albero della documentazione associato avrà l’obiettivo di essere coerente con le linee guida
RTCA DO-178-C livello D per quanto riguarda le eventuali componenti SW e compatibile a linea guida similare per quanto riguarda le eventuali
componenti HW. Ogni sistema/tecnologia specificato nel presente documento sarà basato su un ciclo di sviluppo con le seguenti caratteristiche
principali:
• Model Based. Il ciclo di sviluppo del sistema/tecnologia è affiancato da un ciclo di sviluppo dei modelli di simulazione che sono utilizzati sia
per le analisi progettuali sia per le verifiche numeriche in simulazione o in tempo reale.
106
CIRA-CF-12-0600 Rev. 1 P. 106/109
TECVOL-II
TECVOL-II - System Requirements
CIRA-CF-12-0600
• Rapid Prototyping. La codifica prototipale degli algoritmi alla base del sistema/tecnologia (o di suoi sotto-moduli) è operata in maniera
automatica (per circa il 70-80% del codice) a valle della produzione delle specifiche di basso livello. Questo consente di eseguire iterazioni
rapide tra le fasi di specifica SW di basso livello, test di singoli moduli SW e test integrati in tempo reale di moduli SW (Rapid Prototyping
Iterations).
L’albero della documentazione previsto per ogni sistema/tecnologia sarà in accordo con il diagramma di flusso mostrato in Figura 4-2. Di seguito è
riportata una breve descrizione di alcune delle fasi di sviluppo in esso citate.
Sulla base dei project requirements, definiti nel presente documento, ci saranno tre ulteriori livelli di specificazione: sub-system requirements,
HW/SW high level requirements, low level specifications. Durante le fasi relative alla definizione dei system requirements e HW/SW high level
requirements saranno svolte anche ulteriori attività di analisi di letteratura, di fattibilità, di meccanica del volo, di trade-off architetturale e di
progettazione preliminare algoritmica. Modelli di simulazione semplificati (meccanica del volo lineare, a tre gradi di libertà, ecc.) saranno utilizzati
a supporto delle attività di analisi e definizione dei requisiti.
Nella fase di Detailed Design saranno invece eseguite le analisi progettuali di dettaglio degli algoritmi e dei sottosistemi HW per definire le
specifiche di basso livello degli algoritmi (ad es. attraverso schemi Matlab/Simulink documentati) e dei sottosistemi HW. Saranno inoltre eseguiti i
test numerici di verifica dei requisiti di alto livello. Modelli di simulazione dettagliati del velivolo di riferimento e dei sotto-sistemi di interesse (con
eventuale modelli di altri sistemi SW/HW che debbano interagire con il primo) saranno utilizzati sia per le analisi progettuali che per le relative
verifiche formali dell’algoritmo.
In TECVOL-II per la codifica del SW si utilizzerà prevalentemente il SW Modules Automatic Coding dove, per ogni sotto modulo algoritmico,
saranno prodotti tramite un ambiente di generazione automatica del codice (ad es. Real Time Workshop di Mathworks), i sorgenti (in linguaggio C)
atti a essere compilati e linkati su un elaboratore hard real time. Tali moduli saranno sottoposti a delle verifiche formali di qualità del codice
prodotto derivate dalle linee guida della DO178B (assenza di divisioni per 0, cicli infiniti, ecc.) e a test funzionali di unità ed integrati. Per le
verifiche formali sarà utilizzato un ambiente di verifica formale automatica (ad es. Simulink Verification & Validation e, in futuro, Polyspace). Per
le verifiche funzionali, i singoli sotto-moduli saranno compilati, linkati e integrati in un ambiente Fast Real Time dedicato sviluppato a partire dal
modello di simulazione di dettaglio della fase precedente (SW-in-the-Loop Tests) o nel dimostratore comune SIL-IMA. I risultati di tali test
funzionali saranno confrontati con quelli concernenti le verifiche numeriche della fase precedente per stabilire la correttezza della codifica. Nella
fase di Integration Tests, il prototipo complessivo del sistema ottenuto attraverso il download del SW generato automaticamente nel target HW, sarà
testato in un ambiente in tempo reale attraverso simulazioni HW-in-the-loop, che a seconda dei casi saranno eseguite nei dimostratori HIL-FLARE,
HIL-IMA o CAM. Quando previste le fasi di Vehicle AIV & AIT e di Flight Test serviranno ad integrare il nuovo sistema nel dimostratore volante
107
CIRA-CF-12-0600 Rev. 1 P. 107/109
TECVOL-II
TECVOL-II - System Requirements
CIRA-CF-12-0600
opportuno (FLARE o FLARE-II) e ad eseguire i relativi flight test con recupero dei dai di volo. Infine nella fase di Post Flight Analysis saranno
analizzati i dati di volo, operata l’identificazione dei parametri dei modelli di simulazione e/o valutate le prestazioni in volo dell’algoritmo rispetto a
quelle attese e infine saranno proposte le modifiche ai modelli o agli algoritmi per aumentare le prestazione, risolvere problemi, ecc. L’output finale
di tale fase sarà il Post Flight Analysis Report. Il set tipico di documenti previsto per ogni sistema sarà quindi quello di seguito elencato:
• Project Requirements (questo documento)
• Systems Requirements
• Validation Plan (piano di validazione dei requisiti di sistema da svolgersi a seconda dei casi su uno tra i dimostratori HIL-IMA, CAM,
FLARE o FLARE-II)
• Requisiti SW HLR
• Requisiti HW HLR (se applicabili)
• Verification Plan (piano di verifica dei requisiti di alto livello HW/SW)
• Requisiti SW LLR (documentazione comprensiva di descrizione arichitetturale)
• Specifiche HW (se applicabili) (documentazione comprensiva di descrizione arichitetturale)
• Verification Test Report
• Validation Test Report
108
CIRA-CF-12-0600 Rev. 1 P. 108/109
TECVOL-II
TECVOL-II - System Requirements
CIRA-CF-12-0600
Project
Requirements
Feasibility &
Architecture
Design Report
Sub-System
Requirements
Algorithm HLR
/ HW HLR
Verification &
Validation
Test Plan
Preliminary Design
Report
Detailed Design
Report
Algorithm LLS
/ HW LLS
Simplified Model
Description Reports
Detailed Model
Description Reports
Simulink
Drawings
Unit, Integration
& Real Time
Test Dossier
Test Rig
Description Reports
Post Flight
Analysis Report
Model
Identification &
Validation
Figura 4-2 – Diagramma di flusso alla base dell’albero della documentazione di ogni sistema
109
CIRA-CF-12-0600 Rev. 1 P. 109/109