• Non ci sono risultati.

PRIMA PARTE

N/A
N/A
Protected

Academic year: 2021

Condividi "PRIMA PARTE"

Copied!
27
0
0

Testo completo

(1)
(2)

1. Interfaccia col pilota umano

1.1 Obiettivi

I sistemi di comandi di volo dei moderni velivoli FBW comportano numerosi vantaggi tra i quali: la possibilità di incrementare le prestazioni attraverso la realizzazione di configurazioni instabili; la protezione automatica dell’inviluppo di volo per evitare lo stallo ed il superamento dei limiti strutturali, la riduzione del carico di lavoro sul pilota e il miglioramento della risposta ai disturbi atmosferici. Questi vantaggi vengono conseguiti ottimizzando il comportamento dinamico del velivolo attraverso una gestione automatica della spinta e dei movimenti delle superfici di controllo da parte dei computer di bordo (Flight Control Computers-FCC). Trattandosi di sistemi estremamente complessi è necessario che studi relativi alle loro modalità di funzionamento, alle problematiche di progetto ed alla verifica delle loro prestazioni debbano ricorrere a metodi di simulazione numerica in tempo reale del tipo “Hardware-In-The-Loop/Man-In-The-Loop”, non potendo prescindere dalle problematiche di integrazione tra i diversi componenti ed in particolare dall’interazione tra il software che gestisce il FCS, di componenti hardware ed il pilota umano. In questo contesto è in corso presso il DIA un’attività di ricerca che prevede lo sviluppo di un sistema di simulazione in tempo reale per moderni velivoli FBW [1, 2]. L’obiettivo principale della ricerca è quello di realizzare simulazioni “Real-Time/HITL/MITL” di un moderno FCS/FBW. Per far ciò il modello di simulazione deve essere eseguibile in tempo reale utilizzando il toolbox di Matlab-Simulink xPC Target.

Questo toolbox è essenzialmente costituito da tre elementi: un compilatore una libreria di blocchi, alcuni dei quali utilizzati per lo scambio di dati con altre

(3)

unità di calcolo, e un sistema operativo che può essere installato su un PC (Target) diverso dal PC dove è presente Simulink (Server). Il toolbox permette di generare automaticamente codice C partendo da un modello Simulink, compilarlo, caricarlo e mandarlo in esecuzione sul Target via rete Ethernet. Sul Target deve essere stato installato il sistema operativo xPC Target, che sfrutta al minimo le risorse di calcolo lasciandole quasi completamente disponibili per l’esecuzione in tempo reale del modello.

A causa della complessità del modello di simulazione del FCS le capacità di calcolo di un singolo PC Target non sono sufficienti. Da qui la necessità di sfruttare le risorse di un’architettura distribuita basata su una rete ad alta velocità costituita da PC Targets operanti in parallelo, su ciascuno dei quali gira in tempo reale una porzione dell’intero modello. Questa architettura inoltre deve essere in grado di integrare nel loop componenti hardware, quali gli FCC e gli attuatori idraulici delle superfici aerodinamiche.

In sintesi, come visibile in Fig 1.1, si tratta di una rete di sette PC (Target) che provvedono alla simulazione della dinamica dei diversi sottosistemi, ai quali si aggiunge un PC (Server), che provvede alla compilazione dei codici di simulazione ed alla loro distribuzione sulla rete ed un PC che funge da stazione di controllo della simulazione e da una unità per la memorizzazione dei dati. Queste unità di calcolo sono collegate tra loro mediante una rete ad alta velocità che sfrutta una memoria condivisa (Broadcast Memory). Ulteriori unità di calcolo, collegate via Ethernet, provvedono alla gestione della postazione pilota e all’interfaccia con i componenti hardware, costituiti da uno degli attuatori primari e da quattro FCC.

(4)

Unità di Calcolo PC Target 6 Input / Output Dati Analogico-Digitali PC Target 7

Modello FCC (leggi di controllo

velivolo,loop di controllo attuatori, elaborazione Dati-Aria) Stazione di Controllo della Simulazione Display Stato PC Targets PC Target 1 HUB Memoria Condivisa

Switch Monitor (da tastiera)

Rete ETHERNET (Protocollo UDP) PC Server • Preparazione Modelli Simulink • Compilazione e Download sui PC Targets

• Avvio della Simulazione

• Registrazione Dati

• Simulazione Avarie

Unità di Input/Output ed Espansione Unità di calcolo PC Target 2 PC Target 3 PC Target 4 PC Target 5 Hardware Alimentazione Elettrica SOV Hardware Condizionamento LVDT Pistone ed LVDT DDV Schede Input/Output Hardware Alimentazione Elettrica DDV Unità di Controllo Banco Dowty (Simulazione Carichi Aerodinamici) -Unità di Controllo Centrale Idraulica (Variazione Parametri Idraulici) (Strumentazione di bordo) PC Off-Line 1 (Comandi pilota) Joystick Engineering Test System (ETS)

(Visualizzazione scenario) PC Off- Line 2 Postazione pilota Banco Idraulico VELIVOLO ATTUATORE (“Hardware-in-the loop”)

Figura 1.1 Architettura del banco prova allestito presso il DIA

In questo capitolo viene sviluppata la parte di interfaccia con il pilota umano costituita oltre che dallo stick di comando (Joystick), da una rappresentazione dinamica dello scenario di volo (Visual), e da un Cockpit contenente i principali strumenti di volo e l’impostazione dell’autopilota. Lo scambio di dati tra il

(5)

modello di simulazione e le varie interfacce, collocate su due PC esterni al loop di simulazione (PC off-line), avviene tramite un collegamento Ethernet, utilizzando come protocollo di trasmissione l’UDP.

1.2 Descrizione del modello preesistente FBW2

1.2.1 Descrizione del software FBW2

Allo stato attuale il sistema di simulazione è completamente software ed è costituito da un modello, sviluppato in ambiente Matlab-Simulink, che contiene i diversi componenti del FCS (FCC, Attuatori, Impianto idraulico, Sensori, ecc..) ed un modello della dinamica del velivolo.

La zona evidenziata in Fig 1.2 rappresenta la configurazione del banco software dal quale prende il via questa tesi. Come si può vedere dalla figura esso è formato da quattro Target, tre dei quali impiegati per la simulazione dei diversi componenti del FCS ed uno per la dinamica del velivolo.

(6)

Unità di Calcolo Display Stato PC Targets PC Server

• Preparazione Modelli Simulink

• Compilazione e Download sui PC Targets

• Avvio della Simulazione

• Registrazione Dati • Simulazione Avarie TARGET 1Aircraft Dynamics TARGET 2Hydraulic Plant TARGET 3 Actuation System TARGET 4FCC HUB Memoria Condivisa Switch Monitor/Tastiera Rete ETHERNET Stazione di Controllo della Simulazione • Sensors Comandi Pilota Visualizzazione scenario Strumenti di volo

(7)

1.2.2 Descrizione del modello

Il modello di simulazione della dinamica del velivolo di riferimento per il lavoro è denominato FBW2.mdl e comprende essenzialmente cinque blocchi:

− Un modello semplificato del computer di bordo (Flight Control Computer, FCC) contenente in particolare le leggi di controllo del velivolo (sia di tipo SAS che Autopilota) nei piani longitudinale e latero-direzionale.

− Un modello dell’impianto idraulico comprendente due pompe a cilindrata variabile, i vari accumulatori, le tubazioni.

− Un modello del sistema di attuazione del velivolo contenente due attuatori primari (elevatori) modellizzati con elevato livello di complessità. Gli altri attuatori (due alettoni, rudder, leading edge flaps, trailing edge flaps, airbrake) sono schematizzati in modo semplificato (funzioni di trasferimento del prim’ordine).

− Un modello della dinamica del volo, comprendente tre sottoblocchi:

• Uno per il calcolo delle derivate aerodinamiche del velivolo e dei momenti di cerniera agenti sulle superfici mobili

• Uno per l’integrazione delle equazioni di moto del velivolo considerato come corpo rigido

• Uno per il calcolo di forze/momenti propulsivi e del consumo di carburante.

− Un blocco denominato MP-init che serve ad abilitare le varie porzioni del modello all’interno dei vari Targets.

(8)

In Fig 1.3 si riporta lo schema raffigurante il livello principale (Top-level) dello schema Simulink del modello FBW2.mdl.

Figura 1.3 Livello principale del modello FBW2.mdl

Questo modello viene compilato sul PC-sever mediante una procedura alternativa allo standard fornito dal toolbox xPC Target.

Il programma LOADER (realizzato in collaborazione con la ditta EMTEK) consente l’allocazione dei file eseguibili sui vari targets individuati all’interno della rete Ethernet tramite un indirizzo IP; su ognuno di questi verrà simulata soltanto la porzione di modello abilitata grazie all’attivazione del blocco Enable pilotata dal blocco MP-init.

Ad ogni step di simulazione il valore aggiornato di tutti i dati viene messo a disposizione degli altri targets per mezzo dei blocchi MP-write ed MP-read (Fig. 1.4) capaci di scrivere e di leggere in memoria condivisa.

(9)

Bloccco M_FCS

Blocco per la scrittura in memoria condivisa Blocco per la lettura dalla

memoria condivisa

Figura 1.4 Blocchi di lettura e scrittura in memoria condivisa

Questa procedura di funzionamento è stata sviluppata in [1, 3], ai quali si rimanda per eventuali approfondimenti.

(10)

1.3 Sviluppo delle interfacce

1.3.1 Descrizione del collegamento tramite rete

Per il collegamento dei PC off-line sui quali sono realizzate le interfacce pilota si è scelto di utilizzare la rete Ethernet già impiegata per la trasmissione dati fra il PC Server ed i PC utilizzati come Targets.

Gli strumenti base per la comunicazione tramite rete sono l’Internet Protocol (IP), l’User Datagram Protocol (UDP) ed il Transmission Control Protocol (TCP). L’IP è un protocollo di “basso livello” che spedisce dati di dimensione limitata attraverso la rete sotto forma di “Datagramma”, che contiene nell’intestazione gli indirizzi internet del mittente e del ricevente. Ogni Host su un IP network ha un unico indirizzo internet, formato da 32 bit, che permette di identificare il mittente/ricevente di dati. Questo indirizzo è scritto con quattro interi divisi da un punto, ogni intero è rappresentato attraverso un numero binario utilizzando al massimo 8 bit. Ad esempio

Indirizzo internet = 132.13.2.30 Rappresentazione binaria = 10000100 00001101 00000010 00011110.

L’IP può spezzettare i Datagrammi, ove necessario, in segmenti più piccoli per ricomporli nella forma originale nel momento in cui arrivano a destinazione.

I limiti di questo protocollo risiedono nell’impossibilità di assicurare la completa ricezione dei dati. Inoltre, poiché questi vengono spediti separatamente, non ne è garantito l’arrivo nella corretta sequenza. Infatti l’IP può far arrivare un singolo pacchetto più di una volta se viene duplicato durante la trasmissione.

(11)

L’UDP rappresenta un sistema semplice per le comunicazioni di basso livello fra applicazioni su PC. Le applicazioni comunicano spedendo Datagrammi ad una macchina o porta di destinazione. Mentre l’IP gestisce il trasferimento dal PC di partenza a quello di arrivo, l’UDP lo invia alla porta di destinazione.

Il limiti di questo protocollo sono i medesimi riscontrati nell’IP.

Il TCP è un protocollo di livello superiore che sfrutta l’IP per inviare i dati. In pratica scompone i dati da inviare in modo da renderne possibile la gestione da parte di quest’ultimo, provvede inoltre alla rilevazione di eventuali errori di trasmissione assicurando che i dati arrivino nell’ordine giusto senza duplicazione. Questo viene fatto grazie all’aggiunta di informazioni addizionali da parte del TCP che verranno inserite nel datagramma dall’IP.

Tale processo viene ripetuto in modo inverso al momento della ricezione garantendo il controllo di eventuali errori e notificando la corretta trasmissione. La mancata notifica dell’arrivo di un segmento di dati, fa si che questi vengano ritrasmessi dal computer di partenza.

La differenza fra UDP e TCP è sostanziale, infatti mentre il primo non assicura niente sulla qualità dei dati consegnati il secondo ne garantisce una consegna senza errori, perdite o duplicazioni, ottenuta attaccando delle informazioni aggiuntive al datagram, risultando per questo più lento.

Nel nostro caso si è scelto di usare il protocollo di trasmissione UDP per ottenere una elevata velocità di trasferimento dei dati. L’eventuale perdita di segmenti d’informazione non pregiudica il corretto funzionamento del sistema grazie alla elevata frequenza di trasmissione inoltre, i PC off-line non partecipano ai calcoli per le simulazioni in tempo reale, quindi non sono critici.

(12)

1.3.2 Scambio di dati via UDP/IP in ambiente Simulink

In Fig 1.5 è rappresentato il modello utilizzato per l’invio di dati da una porta di comunicazione ad un’altra, che può essere sulla medesima macchina oppure su un altro computer.

Figura 1.5 Blocco di invio

Il blocco PACK ha il compito di convertire il formato del segnale, scalare o vettoriale, da formato double a formato stringa e di creare i pacchetti di dati e trasmetterli al blocco Send. Questo provvede ad inviarli all’indirizzo IP e alla porta specificati dall’utente.

Il blocco Zero order hold è necessario solo nel caso in cui si vogliano inviare dati ad una frequenza diversa da quella di esecuzione del modello da cui essi provengono.

Il modello di ricezione, Fig 1.6, utilizza il blocco Receive per la ricezione dei dati in formato stringa; in esso devono essere specificati l’indirizzo IP del mittente, la porta di comunicazione e la dimensione del segnale (intesa come numero di bytes).

La prima uscita trasmette i dati al blocco Unpack, adibito alla conversione dal formato stringa a quello originario (double) e al riassemblaggio dei pacchetti.

La seconda uscita è utile solo per verificare se è avvenuta o meno la ricezione di informazione.

(13)

Figura 1.6 Blocco di ricezione

I due blocchi possono essere utilizzati sia per la comunicazione fra due modelli Simulink operanti su diversi PC, sia per la comunicazione fra un modello Simulink e il modello del pannello strumenti o il visual.

1.4 Interfaccia Joystick

Per la visualizzazione della strumentazione e dello scenario si è reso necessario l’uso di due PC off-line, per l’interfaccia col pilota si sfrutta invece lo stesso PC Server.

Nel modello di simulazione FBW2 gli input di comando delle superfici di controllo vengo impostati tramite dei blocchi (Fig. 1.7) contenuti all’interno del blocco Cockpit Pilot. In Fig. 1.8 si può vedere dove è allocato quest’ultimo all’interno di M_FCS.

In questo modo è possibile, utilizzando funzioni disponibili all’interno della libreria di Simulink, impostare comandi predefiniti di tipo a gradino, a rampa e ad impulso ed inoltre se ne può definire una storia temporale per mezzo di un

(14)
(15)

M_FCS

(16)

Questa impostazione piuttosto semplice risulta indispensabile quando si vogliono fare dei confronti fra modelli, in quanto permette di riprodurre il medesimo comando in modo univoco durante le diverse simulazioni.

Per permettere l’invio dei comandi mediante Joystick è stato aggiunto un blocco all’interno di Cockpit Pilot denominato Input Joystick (Fig. 1.9) il quale è in grado di ricevere, utilizzando il protocollo di trasmissione UDP, i segnali. provenienti dal modello Joystick.mdl riportato in Fig. 1.10. Nell’altro blocco, Input Simulink, posto all’interno di Cockpit Pilot, sono stati inseriti i blocchi di comando rappresentati in Fig. 1.7.

Blocco cockpit pilot

(17)

Figura 1.10 Modello Joystick

All’interno del modello sono presenti tre blocchi:

− Comandi Joystick che contiene, come si vede dalla Fig 1.11, il blocco Joystick Input presente nella libreria di simulink, in grado di convertire la posizione dello stick di comando (Microsoft “Sidewinder force feedback”) in segnali numerici;

− Pack che impacchetta i segnali da inviare;

(18)

Figura 1.11 Blocco comandi joystick del modello Joystick

Nell’ingrandimento sono visibili le tre uscite del blocco Joystick Input che sono

Axes vettore con quattro componenti relative ai quattro movimenti che possono essere effettuati con lo stick di comando;

Buttons vettore di otto componenti corrispondenti alla pressione degli otto pulsanti presenti sul joystick;

Point of View segnale che varia fra 0 e 360 al variare della posizione di una rotella presente sul joystick, non utilizzato in questo lavoro;

(19)

Dell’uscita Buttons si sfruttano solo due componenti: la prima, per permettere al pilota il passaggio, durante la simulazione, da controllo tramite file a controllo tramite joystick, la seconda permette il passaggio inverso.

1.5 Interfaccia Visual

Per la visualizzazione dello scenario viene sfruttato il software di simulazione di Microsoft Flight Simulator 2002 che tramite l’applicativo FS-Link, sviluppato all’interno del DIA, permette di acquisire dati dall’esterno utilizzando il protocollo di trasmissione UDP.

I dati inviati al PC off-line, necessari per la ricostruzione della posizione del baricentro e dell’angolo di vista del pilota, sono:

− Latitudine

− Longitudine

− Quota

− Velocità

− Angoli di Eulero

Questi vengono inviati dal blocco Visual UDP contenuto all’interno di M_FCS posto sul top level di FBW3.mdl.

Nella Fig 1.12 si vede il blocco Send to visual che impacchetta i dati e li invia, utilizzando la rete Ethernet, al PC off-line.

(20)

Figura 1.12 Modello simulink del blocco Visual UDP

1.6 Interfaccia Cockpit-Autopilota

L’interfaccia Cockpit è costituita da un pannello, visibile in Fig 1.13, contenente gli strumenti che consentono di visualizzare i principali parametri di volo quali:

(21)

− Numeri giri del motore

− IAS (scala in Knots)

− Angoli di assetto del velivolo

− Vertical speed

− Quota di volo

− Longitudine latitudine

− Angolo di prua

− Angoli di deflessione delle superfici primarie di comando

− Angolo di deflessione dei flaps

− Valore della manetta

− Fattore di carico

ed i comandi relativi all’autopilota per mezzo dei quali è possibile impostare una delle seguenti funzionalità:

− Rapid climb (RC)

− Steep climb (SC)

− Pitch

− Glide slope (GS)

− Instrumental Landing System (ILS)

− Controllo in velocità (IAS/MACH)

− Controllo della quota di volo

− Controllo in imbardata − Controllo in rollio

(22)

Figura 1.13 Cockpit (front panel)

L’interfaccia, che durante la simulazione è visibile dal pilota su uno dei due PC off-line, è stata sviluppata impiegando il software LabVIEW National Instruments che consente di creare pannelli di visualizzazione e controllo tramite l’utilizzo di strumenti virtuali presenti all’interno della propria libreria.

In generale un programma Labview (definito Virtual Instrument, VI) è costituito da due parti : un pannello di interfaccia interattiva con l’utente chiamata front panel, che può contenere leve, pulsanti, indicatori, ed un block diagram nel quale è possibile programmare l’algoritmo mediante un linguaggio di programmazione grafica a blocchi.

La Fig 1.13 rappresenta il front panel di pannello.vi mentre nelle figure 1.14 e 1.15 è rappresentato il relativo block diagram composto da due cicli while, il primo (Fig. 1.16) destinato alla ricezione dei parametri di volo mentre il secondo (Fig.1.17) adibito all’invio dei segnali di comando dell’autopilota.

(23)

ANEMOMETRO DIREZIONALE ALTIMETRO VARIOMETRO VIROSBANDOMETRO ORIZZONTE ARTIFICIALE

(24)
(25)

Come si vede dalle figure, i blocchi utilizzati per la scrittura e la lettura hanno sigle e colori diversi in funzione del tipo di dato trattato, come indicato di seguito:

Formato double, contrassegnato dalla lettera DBL e di colore arancione;

Formato stringa contrassegnato dalla sigla abc e di colore rosa

Formato integer contrassegnato dalla sigla I16 e di colore blu;

Formato boolean contrassegnato dalla sigla TF e di colore verde;

Inoltre la linea di contorno dei blocchi utilizzati per la scrittura ha uno spessore maggiore rispetto a quella dei blocchi di lettura è vuoto.

1.6.1 Blocco di ricezione dei dati

(26)

Come si può notare dalla Fig 1.16 la porta di comunicazione è specificata in un apposito blocco esterno al ciclo (blocco porta locale) così come è esterno il blocco UDP open che comanda l’apertura del canale di comunicazione UDP.

La lettura dei dati, ricevuti in formato stringa, viene effettuata dal blocco UDP read ed in seguito convertiti nel loro formato originario, cioè double, ricostruendo così il vettore proveniente dal blocco Flight Control System (FCS) del modello FBW3.mdl. L’ultimo blocco del modello consente di decomporre il vettore (Array) in 17 scalari corrispondenti alle 17 variabili i cui valori sono destinati ai vari strumenti.

Gli strumenti di volo utilizzati e visibili in Fig 1.13 sono oggetti ActiveX disponibili nella libreria di strumentazione aeronautica della Global Magic Software.

Figura 1.17 Utilizzo dell'oggetto ActiveX "Anemometro"

Per illustrare il funzionamento degli oggetti ActiveX e la loro gestione da parte dei relativi sub-VI si prende ad esempio l’anemometro. Come si vede dalla Fig. 1.17 l’icona corrispondente alla sub-VI che gestisce lo strumento riceve, attraverso il collegamento arancione, il valore della Indicated Air Speed (IAS) proveniente dall’Array. Il blocco AIRLib.Air esterno al ciclo While rappresenta lo strumento ActiveX mentre quello denominato ERROR IN tratta dati in formato stringa utili per la gestione degli errori.

(27)

1.6.2 Blocco di invio dati

La Fig 1.18 mostra la porzione del blocco While che consente la conversione dei dati in formato stringa e il loro invio, sotto forma di pacchetti, al modello FBW3.

Figura 1.18 Ciclo while per l'invio dei dati

I dati da inviare sono 16 scalari di cui 13 in formato double e 3 in formato I32 contraddistinti rispettivamente da collegamenti in arancione ed in blu. Essi vengono convertiti in formato stringa prima del loro invio tramite il blocco UDP write che richiede l’immissione dell’indirizzo IP e il numero della porta utilizzata. Il blocco UDP open, esterno al ciclo While, rende possibile la connessione con un’altra macchina.

Figura

Figura 1.1 Architettura del banco prova allestito presso il DIA
Figura 1.2 Banco software comprensivo di interfacce (Modello Simulink FBW3)
Figura 1.3 Livello principale del modello FBW2.mdl
Figura 1.4 Blocchi di lettura e scrittura in memoria condivisa
+7

Riferimenti

Documenti correlati

L’edizione 2021 del Festival ospiterà un convegno, organizzato in collaborazione con Università degli Studi di Torino, e rivolto al mondo della scuola, agli studenti e

L’Importo di Liquidazione Finale, ossia l’ammontare in Euro da riconoscere al Portatore in seguito all’esercizio automatico dei Certificati alla Data di Scadenza, è

Se il Valore Finale dell’Attività Sottostante è inferiore o uguale al Livello di Protezione, che per il Certificato di cui al presente esempio coincide con il Livello di Soglia

Alla data della Relazione periodica il Fondo non aveva ricevuto garanzie reali nell’ambito delle operazioni di finanziamento tramite titoli o in total return swap. II.2

Tale utilizzo, sebbene possa comportare una temporanea amplificazione dei guadagni o delle perdite rispetto ai mercati di riferimento, non è comunque finalizzato

nella ricerca di controparti commerciali estere tramite piattaforma dedicata: una vetrina virtuale che offre opportunità di business one-to-one nei

Good and prolonged response to pembrolizumab in a patient with a heavily pretreated anaplastic oligodendroglioma with MSH6-. Duration of response:

Sul mare, sul lago o alle pendici di una montagna: se il tuo Camping Village si trova in una zona adatta alle vacanze attive e gli ospiti della tua struttura hanno la possibilità