Introduzione

La presente Tesi di Laurea, sviluppata presso il Dipartimento d'Ingegneria Aerospaziale (DIA) dell'Università di Pisa, è finalizzata alla concezione e sviluppo di un codice software per la modellazione parametrica delle fusoliere dei velivoli da trasporto passeggeri nella fase di Progetto Concettuale.

Nel corso del presente capitolo, verranno fornite le indicazioni riguardanti la struttura e l'organizzazione della Tesi, nonché le metodologie e gli strumenti utilizzati per lo svolgimento del lavoro.

1. Considerazioni generali

Nella progettazione della fusoliera di un velivolo da trasporto per impieghi civili, l’obiettivo fondamentale consiste nel soddisfacimento della funzione primaria di trasporto del carico pagante in modo ottimale rispetto ai costi di gestione della macchina.

Due importanti voci di costo, sono costituite dal consumo di carburante e dal tempo di stazionamento a terra necessario per la movimentazione di passeggeri e merci.

I consumi sono direttamente imputabili alla resistenza aerodinamica del velivolo e la fusoliera partecipa a questa con contributi di diversa natura, tra i quali si distingue una quota di resistenza a portanza nulla, statisticamente compresa tra il 20% e il 40% di quella relativa all’intero velivolo.

Il tempo di stazionamento a terra è riferibile principalmente all’organizzazione e alla gestione degli spazi interni per l'accomodamento del carico pagante, nonché alla razionale predisposizione degli accessi di servizio, delle uscite di sicurezza e dei portelloni di carico per lo stivaggio dei bagagli e delle merci.

Fig. 1 : Relazione statistica tra la lunghezza interna di cabina e l'indice di carico.

del carico pagante nonché al comfort del passeggero e ciò permette d’individuare soltanto soluzioni di compromesso.

Fermi restando i vincoli stabiliti dai requisiti di certificazione9_{, cui il progettista}

deve assoggettarsi, ciò che caratterizza fortemente l'approccio tradizionale di progetto, in fase concettuale, è il gran numero di valutazioni condotte sfruttando le informazioni disponibili per velivoli "simili".

Questa caratterizzazione è particolarmente evidente nel progetto concettuale delle fusoliere dei velivoli da trasporto commerciale, in quanto, essendo queste realizzate per rispondere a requisiti economici e funzionali dello stesso tipo, risultano sufficientemente standardizzate in relazione a geometria e dimensioni.

Un esempio è dato dalla valutazione dell'ingombro longitudinale della cabina passeggeri, che, in fase concettuale può essere stimato (fig.10_{. fig. 1) sulla base di}

relazioni statistiche estrapolate dalle raccolte dei dati storici.

Contestualmente, si notano i best fit statistici (rappresentati dalle rette) ottenuti interpolando, separatamente, i dati relativi ai velivoli appartenenti a due categorie di riferimento, distinte in base alla tipica dislocazione delle merci in fusoliera.

9

cfr. /11/ 10

Fig. 2: Struttura della sezione maestra di fusoliera

Per ciascuna categoria il best fit dei dati storici stabilisce un legame statistico tra la dimensione LC della cabina e l'indice di carico ottenuto come combinazione di

parametri quali il passo tra le file di poltroncine, il numero totale di passeggeri in classe unica ed il numero di poltroncine affiancate in sezione maestra.

Un altro punto "critico" che, in fase di Progetto Concettuale, viene affrontato con il ricorso a stime basate sui dati storici è la valutazione dello spessore del guscio strutturale (ordinata e pannello) nonché della trave del ponte di cabina (fig. 2).

Questo tipo di stime, tipiche dell'approccio tradizionale di progetto, possono risultare inattendibili tutte le volte che, ad esempio, si voglia far ricorso a soluzioni non convenzionali, anche soltanto in relazione all'uso di tecnologie costruttive avanzate o all'impiego di materiali innovativi.

Infatti, a parità di geometria e dimensioni, possono aversi caratteristiche macroscopiche, ad esempio in termini di rigidezza, pesi e costi, molto diverse al variare dei materiali e delle tecnologie impiegate.

Un ultimo esempio, degno di nota, è la stima dell'angolo d'inclinazione (rispetto all'orizzontale) del tronco di coda di fusoliera, comunemente noto come "upsweep" di coda.

La sua valutazione corretta in fase di Progetto Concettuale è praticamente impossibile in quanto essa deve essere il risultato di compromesso delle ottimizzazioni di più discipline (Aerodinamica, Meccanica del volo, Strutture) che esprimono tendenze contrastanti e che, di solito, nell'approccio tradizionale al Progetto, intervengono in tempi differenti.

fig. 3: Incremento della resistenza in funzione dell'upsweep di coda

Ad esempio (fig.11 _{3) si vede che, dal punto di vista Aerodinamico e Strutturale, un} valore eccessivo dell'upsweep di coda è da evitare in quanto, se da un lato diminuiscono i fenomeni di interferenza tra la scia d'ala e gli impennaggi, dall'altro si ha un eccessivo incremento della resistenza ed anche problemi strutturali causati dalle oscillazioni laterali di coda generate dal distacco di vortici di scia di maggiore intensità dal tronco caudale12_.

Al contrario, un valore troppo basso dell'upsweep è da evitare sia dal punto di vista della Meccanica del volo che da quello Strutturale in quanto penalizza le prestazioni in decollo ed atterraggio a causa dei troppo piccoli valori risultanti dell'angolo di "seduta".

Per limitare gli effetti negativi sulle prestazioni del velivolo in regime di bassa velocità, si richiederebbero sistemi d'ipersostentazione più grandi e complessi e/o carrelli di maggiore lunghezza, con inevitabili incrementi di peso.

11

Il diagramma riportato in figura è tratto da /12/, pag. 40. 12

Cfr. /12/, chapter III, pag. 39.

Il problema, noto come “Buffeting” di coda, può costituire, infatti, un fenomeno di fatica importante per la struttura.

Da quanto detto si capisce come il ricorso a stime basate su criteri di similitudine tra i velivoli possa limitare le potenzialità esplorative di analisi di soluzioni non convenzionali ed, al tempo stesso, introdurre ritardi, economicamente pericolosi, nella segnalazione di errori o di "punti deboli" del progetto.

Un altro aspetto fondamentale, messo in luce attraverso gli esempi prodotti, è l'importanza di un approccio di tipo MDO con la disponibilità di un modello tridimensionale "parametrico" di fusoliera fin dalle fasi iniziali di Progetto, il quale verrebbe ottimizzato ed aggiornato contemporaneamente secondo il punto di vista di tutte le discipline concorrenti.

2. Obiettivi e requisiti principali

Come naturale conseguenza delle argomentazioni esposte precedentemente, è stata concepita l'idea di sviluppare un codice per la definizione e la generazione grafica del modello parametrico 3D della fusoliera ad architettura convenzionale dei velivoli da trasporto commerciale.

L'impostazione è il risultato del condizionamento esercitato da una serie di "requisiti" che, fin dall'inizio, sono apparsi connotazioni imprescindibili di un software concepito per la progettazione preliminare.

Fra tutte, sono state perseguite le caratteristiche di flessibilità, velocità di generazione e semplicità di gestione del modello, apprezzabili soprattutto nell'ambito del Progetto Concettuale, nel quale contano maggiormente la rapidità e la semplicità dell'analisi rispetto al livello di dettaglio di questa.

2.1 Flessibilità applicativa

Con questo termine s’intende, l'applicabilità al Progetto delle fusoliere di una vasta gamma di categorie di velivoli da trasporto commerciale per impieghi civili, aventi fusoliera a singolo ponte di cabina e con un massimo di 10 poltroncine in sezione maestra.

Duplice la motivazione alla base della scelta: in primo luogo, considerata la vastità del panorama commerciale nella sua interezza, la predisposizione di uno strumento software con connotazione applicativa "universale", avrebbe richiesto uno sforzo eccessivo, in relazione alle risorse applicabili ad un lavoro di Tesi, ma, soprattutto non avrebbe portato aggiunte significative alla definizione del modello di fusoliera.

Generalmente, infatti, i velivoli civili ad uso commerciale sono concepiti per poter essere convertiti, qualsiasi lo stadio della loro vita operativa e mediante interventi mirati (anche a livello strutturale), ad una configurazione di trasporto differente da quella iniziale .

Fig. 4: B 727: esempio di versatilità di trasporto commerciale

Un esempio di versatilità, in tal senso, è il B 727 (fig. 4, (a)) che è stato configurato per diverse tipologie di carico (fig. 4, (b), (c) e (d)).

Le principali configurazioni, distinte in base alle diverse esigenze di trasporto, sono:

1. PASSENGERS

2. COMBI (passengers/cargo) 3. ALL CARGO

Alla prima tipologia appartengono i velivoli configurati per il trasporto esclusivo di passeggeri (fig. 4, (b) ed (e)); la caratteristica è rappresentata dal fatto che, nel caso siano presenti due o più piani di carico (fig. 5, (a) e (b)), passeggeri e cargo sono sistemati su ponti distinti, rispettivamente su ponti superiori i primi, e su ponte inferiore il secondo .

(a) (b)

(c)

(d) (e)

Fig. 5: (a) sezione A 320: doppio piano di carico (b) sezione B 747: triplo piano di carico

La seconda tipologia prevede la sistemazione di passeggeri e cargo sullo stesso piano di carico (fig. 4, (c) ed (e)) e con una ripartizione variabile in funzione delle esigenze di mercato.

Per finire, i velivoli configurati per il trasporto all cargo, comunemente indicati anche con il termine "freighters" (fig. 4, (d) ed (e)), sono caratterizzati dalla destinazione di tutti i piani di carico al trasporto esclusivo di merci.

E' raro che un velivolo venga progettato, esclusivamente, per il trasporto cargo, e, d'altro canto, la maggior parte degli interventi di conversione della configurazione di trasporto passeggeri, non altera la forma e le dimensioni d'ingombro esterne della fusoliera.

Ne consegue che, la scelta di centrare il campo applicativo del software sulla categoria di velivoli da trasporto passeggeri, non introduce penalità significative in termini di flessibilità operativa ma, piuttosto, ha permesso di snellire e semplificare la struttura del codice .

I velivoli da trasporto passeggeri dotati di triplo ponte di carico, rappresentano una sfida progettuale che, attualmente, soltanto i due più grandi costruttori mondiali13

13

L'americana BOEING ha già realizzato, a partire dagli anni '60 del secolo appena concluso, il progetto B 747 che, ancora oggi unico nel suo genere, è impiegato dalle compagnie di tutto il mondo sulle rotte intercontinentali, mentre si attende entro la prima decade del secolo appena iniziato il nuovo B 7xx.

La concorrenza europea, rappresentata dal consorzio AIRBUS, è attualmente impegnata nella fase avanzata del progetto A 380, con tempi di realizzazione previsti entro il 2010.

Fig. 6: Esempio di evoluzione dal concetto wide body a quello wing body

sono in grado di raccogliere.

In ogni caso, questa tipologia architettonica rappresenta soltanto una delle possibili risposte dei costruttori alle future esigenze del mercato relative all'incremento del carico pagante .

Altra tendenza architettonica per il futuro è l'evoluzione dell'attuale concetto di fusoliera wide body (fig. 6, (a)), grazie all'incremento del numero di poltroncine affiancate sullo stesso ponte di carico .

Il rispetto dei requisiti di sicurezza, richiederebbe l'inserimento di molteplici corridoi, fino ad ottenere la geometria della sezione di fusoliera, caratteristica della concezione wing body (fig. 6, (b)) ed integrata nella struttura dell'ala .

Dopo un'attenta valutazione dei vantaggi in contrapposizione ai rischi del prendere in considerazione architetture non convenzionali come quelle appena descritte, dagli standard costruttivi, al momento, non ben definibili ma solo ipotizzabili, si è deciso di limitare la flessibilità applicativa del codice all'architettura convenzionale, caratterizzata da un massimo di due piani di carico, con un massimo di dieci poltroncine affiancate su un unico ponte di cabina .

In pratica, rientrano nei limiti del requisito applicativo del software, le fusoliere dei velivoli appartenenti alle seguenti categorie: business/executive, regionali turboelica e/o turbogetto, turbofan a corto/medio raggio (narrow body) e turbofan a lungo raggio (wide body), con geometria monolobata e/o bilobata della sezione maestra.

Il requisito stesso esclude l'adozione della sezione trilobata, essendo questa una caratteristica dei velivoli a doppio ponte passeggeri (tipo B 747) .

2.2 Modularità

Si ritiene che il software debba presentare caratteristiche di modularità, ovvero sia predisposto all’integrazione all'interno di procedure automatizzate di progettazione più ampie.

Ciò è stato tradotto nella possibilità di operare, indifferentemente, in modo "indipendente" oppure in modo "integrato"; nel primo caso i dati d'ingresso devono essere generati, esternamente, dall'Utente, mentre nel secondo, gli stessi dati sono le uscite di altri moduli (ad esempio ATO14, PRELDES15 e altri, disponibili presso il DIA).

Per finire, ma non meno importante, il requisito d'interfaccia con sistemi CAD16

tridimensionali per la generazione grafica e la gestione parametrica del modello 3D di fusoliera.

3. Approccio al Design di fusoliera

Nell'approccio tradizionale di progetto, la geometria della fusoliera e le sue dimensioni sono definite, nella fase concettuale, quasi esclusivamente in base alla specifica di carico pagante ed in base a valutazioni di massima inerenti l'aerodinamica. Il layout di fusoliera è ottenuto (fig. 7) attraverso due fasi successive, aventi come obiettivo, rispettivamente, il layout di sezione ed il layout longitudinale.

Geometria e dimensioni della sezione maestra sono determinati in base ai requisiti di sicurezza ed alla specifica di accomodamento del carico pagante, insieme ad opportune scelte inerenti, ad esempio, le poltroncine con relativa disposizione su fila, il tipo di contenitori (container, pallet) per il trasporto di bagagli e merci, ed altro.

La fase successiva è finalizzata al completamento del layout di fusoliera in modo che questa soddisfi la specifica di accomodamento del carico pagante, unitamente ad opportune funzionalità inerenti la rapidità di movimentazione di questo durante le operazioni d'imbarco ed evacuazione, nonché possieda determinate caratteristiche aerodinamiche e strutturali.

In quest'ambito è previsto il dimensionamento della cabina per l'accomodamento dei passeggeri, degli spazi adibiti ai servizi e di quelli destinati allo stivaggio di merci e bagagli, nonché la disposizione ed il dimensionamento degli accessi di servizio e delle uscite di sicurezza.

Un approccio di questo tipo risulta particolarmente adatto ad essere automatizzato,

14 cfr. /9/. 15 cfr. /10/. 16

fig. 7: Schema di approccio al Design di fusoliera

per operare in forma parametrica, all'interno di cicli d’ottimizzazione iterativi "multidisciplinari", mediante l'integrazione di moduli di analisi, tipici delle diverse discipline concorrenti nel progetto, aventi complessità crescente con lo stadio di avanzamento di questo. SPECIFICA REQUISITI spessore strutture e rivestimenti dimensionamento "cappelliere" dimensionamento sezione stiva spessore ponte di cabina LAYOUT SEZIONE LAYOUT LONGITUDINALE Geometria di sezione Dati di accomodamento Payload N°posti affiancati Poltroncine Configurazione Cargo (containers/pallets) uscite, porte e finestrini Aree servizi SCELTE DI PROGETTO lunghezza cabina equipaggio Flyghtdeck Dimensionamento stive

Fig. 8: Best fit dei dati storici per la stima dell'ingombro di sezione maestra

Nella presente Tesi è stato seguito l'approccio tradizionale al progetto di fusoliera; poiché l'obiettivo dichiarato è quello di ottenere uno strumento rivolto alle fasi preliminari di progetto, si è optato per l'uso di moduli di analisi che privilegiano la rapidità delle stime rispetto al livello d’accuratezza di queste.

In particolare, per quanto possibile, si è cercato d’usare procedure di stima basate sul best fit dei dati storici dei velivoli simili per categoria e dimensioni.

Nella maggior parte dei casi, ciò non è in contraddizione con le argomentazioni mosse a critica dell'approccio tradizionale di Progetto, infatti, l'obiettivo di questo lavoro è la generazione del modello "concettuale" parametrico di fusoliera, ossia l'individuazione dei parametri primari utili alla definizione di una "piattaforma" unica per le ottimizzazioni successive dei moduli di analisi delle varie discipline.

In alcuni casi, tuttavia, sono state privilegiate strategie alternative; ad esempio nel caso della stima della lunghezza di cabina oppure della larghezza della sezione trasversale di questa, si è preferito valutare in base all'ingombro interno effettivo.

In tal modo le dimensioni della cabina, e, di conseguenza, quelle della fusoliera sono, caso per caso, quelle necessarie a racchiudere lo spazio interno così come esso è stato concepito dall'Utente.

Ciò permette di tener conto della larghezza effettiva dei corridoi, del numero delle uscite, delle aree servizi (galley, lavatory) e di quant’altro può influire sulle dimensioni della cabina.

Utilizzando stime di carattere statistico (rispettivamente cfr. figg. 1 e 817_{), ciò} sarebbe stato impossibile.

17

fig. 9: Struttura generale del codice PFD_CODE start PACO PALOMA Layout di sezione Layout longitudinale B a nc he d a ti Specifica Scelte progettuali Requisiti

UTENTE file input

Layout grafico di sezione Layout grafico longitudinale file input file input end end Modello 3D di fusoliera end

4. Struttura generale del codice

Al codice completo per la definizione e la generazione grafica del modello parametrico di fusoliera, sviluppato nell'ambito della presente Tesi di Laurea, è stata assegnata la sigla identificativa PFD_CODE (Parametric Fuselage Design_CODE).

La sua struttura generale (fig. 9) è fortemente condizionata dall'adozione dello schema operativo (fig. 7) dell'approccio tradizionale al progetto di fusoliera.

In particolare sono riconoscibili le due "colonne portanti" del codice: 1. PACO (PArametric Cross section Optimization)

2. PALOMA (PArametric Longitudinal Optimization and Modeling Analysis)

ciascuna afferente ad un modulo (o sezione) indipendente del software .

Il primo modulo, ha come obiettivo il layout di sezione maestra della fusoliera a partire dal "file input" di dati, compilato18 _{manualmente dall'Utente, in base alla}

specifica di accomodamento del carico pagante ed alle varie scelte progettuali ma tenendo conto anche dei requisiti di certificazione.

I risultati prodotti dal modulo di dimensionamento della sezione maestra di fusoliera, completano le istruzioni d'input necessarie al modulo successivo, dedicato al layout longitudinale di fusoliera, comprensivo del layout di cabina e, qualora fossero presenti le stive ventrali, anche del layout del ponte cargo.

Per una maggiore flessibilità d'uso del software, ciascuno dei moduli suddetti è stato concepito per operare anche in modalità indipendente; in tal caso l'Utente si farà carico di compilare il "File Input" richiesto dalla sezione del codice che intende utilizzare.

Quest'opportunità è molto utile quando, ad esempio, s’intenda operare uno studio di pre-ottimizzazione, alla ricerca della configurazione di maggiore soddisfazione per l'Utente .

La fase terminale del codice, nella sua configurazione completa, è relativa alla generazione del modello tridimensionale di fusoliera.

E' auspicabile che, questa fase ultima, avvenga direttamente all'interno di un ambiente CAD tridimensionale, a partire dal modello di fusoliera generato dal codice.

18

L'istruzione del "file input" è un punto nevralgico che richiede un approfondimento non concepibile in questa sede; per una trattazione specifica dell'argomento si rimanda il lettore alle sezioni successive di questo lavoro di Tesi (vd. PARTE I- Cap. 2 e PARTE II- Cap. 2), nonché agli esempi applicativi riportati nella sezione Allegati .

Si sfrutterebbe, in tal modo, la capacità di gestire le variabili dimensionali del modello come parametri, propria dei CAD 3D di uso comune nell'industria, con la possibilità d'intervenire "a posteriori", direttamente sul modello di fusoliera e senza la necessità di far "girare" nuovamente il codice .

Lo sviluppo dell'interfaccia tra il codice ed il CAD 3D (ad esempio CATIA® V.5 in dotazione presso DIA avrebbe le credenziali in regola), non è stato affrontato in questo lavoro di Tesi .

5. Banche dati

Fin dalle battute iniziali, ci si è resi conto che la flessibilità, intesa come capacità di analizzare una gamma quanto più ampia possibile della variegata produzione aeronautica, avrebbe fornito al software un apprezzabile valore aggiunto.

In particolare è apparso chiaro che si sarebbe potuto ottenere un buon grado di acquisizione di questo obiettivo, concedendo all'Utente una più ampia libertà di azione all'atto d'istruire il File Input per il codice.

Ciò si sarebbe dovuto tradurre, direttamente, in una maggiore possibilità di scelta in relazione alle caratteristiche esterne di fusoliera, tipo l'architettura generale del velivolo e la geometria della sezione maestra, ma anche in una maggiore libertà di caratterizzazione degli spazi interni di cabina, ad esempio attraverso una scelta più ampia della dislocazione e delle dimensioni di poltroncine, uscite ed aree servizi .

Non ultima una maggiore possibilità di caratterizzazione della configurazione di stivaggio di merci e bagagli, ad esempio, mediante una scelta sufficientemente ampia delle tipologie e dimensioni dei contenitori (container e pallet) adibiti allo scopo. All'atto pratico, il perseguimento della flessibilità operativa, nell'intento di coprire quanto più possibile dell'ampia casistica, ha richiesto un lungo lavoro d’istruzione del codice ma anche una continua "messa a punto" di un metodo efficace per la compilazione del File Input.

Quest'ultimo aspetto ha evidenziato almeno due livelli distinti di difficoltà sui quali intervenire .

Il primo era rappresentato dal notevole impegno richiesto all'Utente in relazione al reperimento, spesso non semplice, di una grande quantità di dati dalle provenienze più varie, nonché in relazione alla congruenza ed al "realismo" delle scelte da operare.

Infatti, fatta salva la libertà decisionale dell'Utente, era comunque necessario fornire a quest'ultimo gli strumenti opportuni per ottenere una certa conformità dei risultati con la realtà del vasto panorama commerciale.

La soluzione più idonea a questa problematica è stata individuata nella disponibilità di "banche dati", ovvero raccolte di dati dimensionali, "realistici", perché relativi ad un

scelte che questi deve compiere all'atto della compilazione del File Input .

La predisposizione delle banche dati, ha richiesto preventivamente un'ampia ricerca mirata all'acquisizione di dati riguardanti i velivoli da trasporto commerciale, prodotti negli ultimi anni ed attualmente in servizio .

Come precedentemente detto, sono state analizzate le categorie di velivoli turbogetto business/executive, quelle relative ai turbofan a corto/medio/lungo raggio, nonché la categoria dei turboelica "commuter" e "feeder", adatti ai collegamenti tra i piccoli e i grandi aeroporti (sistemi di comunicazione hub-and-spoke).

Sono stati raccolti ed analizzati un gran numero di disegni costruttivi e specifiche dei diversi velivoli (recanti, tra l'altro, il numero, la disposizione e le dimensioni degli accessi per i passeggeri, degli accessi di servizio e delle uscite di sicurezza), nonché di disegni relativi agli arredi di cabina (poltroncine, galley, lavatory) ed ai contenitori per il trasporto di merci e bagagli (container e pallet).

Ulteriore vantaggio offerto da questo tipo d'impostazione, risiede nella possibilità di "aggiornamento" delle raccolte di dati con il duplice scopo di assicurare al codice, da un lato, un grado di flessibilità crescente e, dall'altro, il mantenimento del "passo" con la produzione industriale di elementi per gli allestimenti interni dei velivoli.

Il secondo livello di difficoltà era rappresentato dalla necessità di organizzare in maniera "efficiente" tutti i dati provenienti dalle scelte dell'Utente, ovvero, riuscire ad esprimere concetti complessi, come, ad esempio, la desiderata disposizione degli interni di cabina, in maniera quanto più possibile "intuitiva" e con un numero di istruzioni limitato.

Di ciò, si discuterà nel seguito con il necessario grado di approfondimento.

6. Cenni descrittivi dell'ambiente software

Il codice è stato sviluppato su piattaforma MATLAB® 6.519_.

Le motivazioni alla base della scelta, risiedono in una serie di considerazioni sulle caratteristiche peculiari di questo ambiente software, ritenute adatte allo svolgimento di questo lavoro, secondo gli obiettivi ed i requisiti precedentemente esposti.

Di seguito si forniscono alcuni cenni descrittivi20 _{delle caratteristiche del software,}

focalizzando l'attenzione sugli aspetti che hanno influenzato la scelta.

19

MATLAB® è un prodotto "The Math Works" Inc., 24 Prime Park Way, Natick, Massachusets 01760 – E-mail: info@mathworks.com, http://www.mathworks.com.

20

Ovviamente, una descrizione completa ed esaustiva esula dagli obiettivi della presente Tesi e, perciò, si rimanda il lettore che voglia approfondire l'argomento alle pubblicazioni specifiche (manuali) a cura della Prentice Hall, Inc., tra le quali il riferimento /13/ di bibliografia.

In primo luogo MATLAB®, con la sua vasta toolbox di strumenti specifici dedicati alle applicazioni delle più diverse discipline (dall'Ingegneria alla Teoria dei Segnali), non soltanto è una potente piattaforma di calcolo, completa di tools per l'analisi e rappresentazione grafica dei dati, ma soprattutto è un vero e proprio linguaggio di programmazione, efficiente e più “snello” rispetto ai codici tradizionali come

FORTRAN, PASCAL o C.

Questa caratteristica, insieme alla capacità di rappresentazione grafica in 2D e 3D, hanno consentito di sviluppare interamente PFD_CODE, completo dei layouts grafici in 2D e della generazione del modello (di controllo) 3D di fusoliera, rimanendo sempre all'interno del medesimo ambiente software.

Non secondaria è la caratteristica di poter "importare" ed "esportare" dati in file di vario formato (ad esempio i formati testo, ascii, excel ecc.), cosa questa che consente al codice di interfacciarsi con strumenti di calcolo sviluppati in ambienti software differenti da MATLAB® oppure con sistemi CAD per la gestione parametrica del modello di fusoliera.

I mattoni utilizzati per la programmazione di qualsivoglia nuovo tool in ambiente MATLAB® sono:

a) function b) script file

Entrambi sono strutturati secondo una sequenza di istruzioni ma, a differenza dello

script file, la function (che può includere altre function al suo interno) è una "black

box" che produce una serie di uscite (output) in funzione di un certo numero di variabili d'ingresso (input).

Come ogni linguaggio di programmazione che si rispetti, anche MATLAB® utilizza operatori logici (and, or e not), nonché opportune strutture per il controllo del flusso dei comandi da eseguire21_.

Queste ultime (quattro in tutto), possono essere suddivise nelle due categorie seguenti:

a) Strutture cicliche b) Strutture condizionali

Le prime consentono la ripetizione di un gruppo di istruzioni per un numero di volte che può essere preventivamente fissato (cicli for) oppure soggetto al verificarsi di una certa condizione (cicli while) .

21

Si omette la spiegazione dettagliata della sintassi delle diverse strutture di controllo decisionale. Per chi intenda approfondire l'argomento vale quanto segnalato nella nota precedente.

Alla seconda categoria appartengono, invece, le strutture decisionali che avviano o bloccano l'esecuzione di una sequenza di istruzioni in base al verificarsi o meno di una o più relazioni tra espressioni numeriche (struttura if – else –end) oppure equivalenze tra variabili di tipo "stringa di testo" (struttura switch-case) .

Per finire, si intende sottolineare il fatto che, già da alcuni anni, MATLAB® è di uso comune presso il DIA ed ha un'ampia diffusione presso le Facoltà d'Ingegneria delle Università di tutto il mondo, cosa che ha costituito ulteriore punto di merito nel giudizio di preferenza .