Capitolo 1
Descrizione generale del modulo PACO
Nel presente capitolo sono descritti i tratti distintivi del modulo software per il Progetto della sezione maestra di fusoliera, siglato con l'acronimo PACO (Parametric Cross section Optimization).
L'obiettivo è quello di fornire al lettore una "visione d'insieme", focalizzando l'attenzione sulle principali problematiche affrontate fin dalle fasi iniziali del lavoro.
Per questo motivo, si è cercato di seguire, per quanto possibile, un filo "cronologico" che, partendo dalla fase di concezione del codice, consentisse di presentare una panoramica organica del lavoro, con un graduale approfondimento del livello di dettaglio, pur tuttavia senza eccedere i limiti imposti dalla connotazione introduttiva del capitolo.
Una certa quantità di figure, schemi e diagrammi di flusso sono stati approntati a beneficio della chiarezza nonché della sintesi d'esposizione.
I paragrafi seguenti sono, dunque, dedicati alla definizione della struttura generale del software, ovvero al "chi deve fare cosa"; un livello di dettaglio maggiore, che coinvolga ad esempio le descrizioni delle diverse procedure di stima con i relativi algoritmi di calcolo, esula dagli scopi di questo capitolo1.
1
L'approfondimento del livello di dettaglio è, in parte, rimandato ai capitoli successivi (cfr. PARTE I – Cap. 2); si è comunque deciso di non relazionare circa gli algoritmi di calcolo utilizzati nelle stime in quanto trattasi di relazioni geometriche che non richiedono particolare “attenzione” ma che, dato il numero cospicuo, renderebbero eccessivamente pesante la lettura.
Ad ogni modo, per chi volesse acquisire un livello cognitivo “di dettaglio” del codice, vale il rimando ai file Matlab PACO.m, PACO_ANALISYS.m e collegati, che, proprio a scopo esplicativo, sono sufficientemente commentati.
Fig. 1- 1: Schema generale funzionale del software
1.1 Concezione generale della struttura funzionale del software
Il primo passo per la strutturazione del software, è stata la definizione della sua ossatura funzionale, ovvero, l'individuazione dell'interfaccia con l'Utente, la separazione ed attribuzione delle diverse funzioni nonché la definizione della gerarchia tra queste.
La struttura funzionale adottata è quella classica (fig. 1-1), secondo la quale il software PACO, concepito come una "black-box", realizza la funzione di elaborazione dei dati d'ingresso (input) per produrre, in uscita, il layout di sezione (output).
Punto nevralgico è l'istruzione del "File input"2, compilato 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.
Il File input, è interfaccia tra l'Utente ed il software e, come tale, realizza la funzione di raccolta e trasferimento delle informazioni dal primo al secondo.
L'output, costituito dal layout di sezione, è interfaccia tra il software e l'Utente e realizza la funzione di raccolta e presentazione dei risultati dell'elaborazione.
2
Più avanti (cfr. § 1.6), nel corso di questo capitolo, viene descritta la struttura generale del file input, le cui diverse sezioni vengono esaminate, con maggiore dettaglio, nel capitolo successivo.
start
PACO
(PArametric Cross section Optimization)
B a nc he d a ti Specifica Scelte progettuali Requisiti
UTENTE file input
Layout di sezione
Fig. 1- 2: Esempio di Layout grafico di sezione maestra
1.2 Definizione dell'approccio di Progetto
Identificata l'architettura funzionale, il passo successivo verso la definizione della struttura operativa del software, è stato quello di chiarire l'approccio di progetto, con particolare riferimento agli obiettivi.
Fin dall'inizio, è apparso chiaro che, la caratterizzazione del contenuto della
black-box in termini di strumenti funzionali al design di sezione e dell'organizzazione di
questi secondo una struttura logico-gerarchica, doveva necessariamente passare attraverso l'analisi delle caratteristiche dell'output prodotto.
Ciò avrebbe fornito, tra l'altro, utili chiarimenti circa l'istruzione del File input.
1.2.1 Layout di sezione
In linea con i propositi esposti sopra, l'analisi ha trovato il suo "naturale" punto di partenza nella definizione del layout di sezione.
Adottando la comune accezione del termine, si è voluto indicare con esso il complesso dei risultati delle elaborazioni del software necessari alla definizione completa della sezione maestra (fig. 1-2), tanto per ciò che concerne la forma e le dimensioni, quanto, anche, in relazione alla configurazione di cabina (poltrone e cappelliere) ed alla configurazione cargo (container e pallet).
Subito, sono risultati evidenti i due "cardini" su cui imperniare l'approccio di design, corrispondenti ad altrettante azioni "portanti" nella struttura operativa del software:
Configurazione cargo (container/pallet) Vano di stiva ventrale
Ponte cargo blocco poltroncine cappelliera (overhead bin) Ponte di cabina Lobo ventrale Lobo di cabina parete cabina struttura
Fig. 1- 3: (a) clearance di cortesia per il passeggero adiacente alla parete (b) clearance per accomodamento della configurazione cargo
1. CONFIGURAZIONE 2. DIMENSIONAMENTO
Queste sono state, rispettivamente, riferite all'organizzazione degli spazi interni, con la collocazione dei componenti secondo le disposizioni d'input fornite dall'Utente, ed alla stima degli ingombri relativi agli spazi interni, dei ponti e della struttura.
Altrettanto evidente è risultata la relazione di dipendenza e consequenzialità tra le suddette azioni, per la quale, la configurazione degli spazi, influenza gli ingombri interni, mentre, il rispetto di questi ultimi determina le dimensioni esterne della sezione maestra.
Da qui, i due requisiti "naturali" per il dimensionamento dell'ordinata (fig. 1- 3):
a) Rispetto della "clearance" di cortesia per il passeggero adiacente alla parete. b) Rispetto della "clearance" necessaria ad ospitare la configurazione cargo prescelta
Fig. 1- 4: Sistemi di riferimento assoluto e ausiliario di sezione
Nel primo caso, l'ingombro da rispettare è direttamente riconducibile alla configurazione ed al dimensionamento degli arredi di cabina (disposizione e dimensioni di poltroncine e corridoi), mentre, nel secondo, risulta dalla configurazione di trasporto di merci e bagagli (disposizione e dimensioni di container o pallet).
1.2.2 Convenzioni
Per configurare e dimensionare gli spazi interni nonché il contorno esterno della sezione maestra, è stato necessario introdurre e far uso di opportune convenzioni.
In primo luogo, per rimanere nell'ambito generale3, è stato necessario introdurre un sistema di riferimento assoluto, in base al quale, definire un opportuno sistema di riferimento ausiliario per la sezione maestra (fig. 1-4).
Il riferimento assoluto è stato scelto in modo intuitivo, con origine nel vertice del cono di radome ed asse x disposto, da prora a poppa, in direzione dell'asse longitudinale del velivolo.
3
Qui, in linea con gli scopi del capitolo, sono state discusse brevemente le convenzioni di carattere generale adottate. In ciascuna delle Appendici, altrettanti paragrafi sono stati espressamente dedicati alle convenzioni riguardanti gli aspetti specifici di progetto trattati.
Fig. 1- 5: Schema dell'approccio di progetto della sezione maestra di fusoliera
Il riferimento ausiliario più opportuno4 per il layout di sezione maestra, è stato definito facendo coincidere la quota z = 0, ovvero la traccia del FRP (Fuselage Refence Plane), con la superficie del ponte di cabina.
Quest'anomalia, rispetto alle consuetudini tecniche5, è stata giustificata da motivazioni di carattere pratico, in quanto, ad esempio, è risultata più rapida ed intuitiva l'istruzione del File input in relazione alla configurazione degli spazi interni.
4
La convenienza è stata valutata in relazione tanto alla configurazione degli spazi interni di cabina, cioè di quello che deve essere disposto al di sopra del livello del pavimento, quanto degli eventuali spazi adibiti a stivaggio di merci e bagagli, solitamente disposti al di sotto del ponte di cabina.
5
L'esame dei disegni costruttivi di molti velivoli, dimostra infatti che, generalmente, che il FRP, definito dalla giacitura xy del riferimento assoluto, non coincide mai con il piano solido del ponte di cabina.
SPECIFICA REQUISITI spessore strutture e rivestimenti dimensionamento "cappelliere" dimensionamento sezione stiva spessore ponte di cabina LAYOUT SEZIONE Geometria di sezione Dati di accomodamento Payload N°posti affiancati Poltroncine Configurazione Cargo (containers/pallets) SCELTE DI PROGETTO
Fig. 1- 6: Flusso logico del modulo software PACO
start
stima ingombro max interno di cabina stima spessore del guscio strutturale
Banche dati
Specifica Scelte progettuali
Requisiti
UTENTE file input
stima spessore del ponte di cabina
z
oc(o)Accomodamento Cargo ? In cabina
In stiva ventrale
stima ingombri di configurazione cargo stima ingombri del vano di stiva ventrale
Geometria di Sezione ? Monolobata Bilobata Priorità ? Cabina Cargo
nuova stima della quota
z
ocdel centro di cabinadimensiona lobo ventrale
Layout completo di sezione maestra
Verifica clearance passeggero ? Verifica clearance cargo ? No end
1.2.3 Modelli di analisi per le stime
Come anticipato nella precedente sezione introduttiva6, è stato seguito l'approccio tradizionale di progetto (fig. 1-5).
Per quanto possibile, quindi, sono state utilizzate procedure di stima basate sui dati storici di velivoli simili per categoria e dimensioni.
Queste sono state applicate al dimensionamento preliminare dello spessore del guscio strutturale e del ponte di cabina, mentre, in altri casi, si è preferito l'uso di procedure concepite "ad hoc".
Ad esempio, geometria e dimensioni della sezione maestra sono state determinate nel rispetto dei requisiti di sicurezza e della specifica di accomodamento del carico pagante, ma anche in base alla libertà, concessa all'Utente, di organizzare lo spazio interno di cabina e quello di stiva secondo le proprie esigenze.
Questa libertà è stata tradotta nella possibilità di scegliere opportunamente, ad esempio, le poltroncine con relativa disposizione, il tipo di contenitori (container, pallet) per il trasporto di bagagli e merci, la geometria della sezione ed altro ancora.
In definitiva il criterio adottato è stato quello di dimensionare la sezione maestra di fusoliera "dall'interno verso l'esterno", allo scopo di conferire al codice un'elevata flessibilità applicativa.
Sulla base di stime di dimensionamento di carattere statistico, ciò sarebbe stato impossibile, a causa delle forti limitazioni alla libertà di scelta dell'Utente.
1.3 Struttura operativa generale del modulo software
La struttura generale di PACO (fig. 1-6) è fortemente condizionata dall'adozione dell'approccio alla progettazione di sezione maestra di fusoliera definito precedentemente (§ 1.2.3).
Nel diagramma a blocchi sono posti in evidenza tanto la già discussa struttura funzionale (§ 1.1) quanto, anche, il flusso logico operativo del software, ovvero il contenuto di ciò che, allo stadio di sviluppo iniziale, era stato visualizzato soltanto come una black-box.
Nella fase istruttoria dell'input, l'Utente può usufruire di banche dati7, opportunamente predisposte allo scopo di facilitare quelle scelte che implicano l'assegnazione di dimensioni, come, ad esempio nel caso degli arredi interni di cabina (poltroncine) oppure dei contenitori per il trasporto di merci e bagagli (container e pallet). 6 Cfr. Introduzione, § 4. 7 Cfr. Introduzione, § 6.
Fig. 1- 7: Principali quote dimensionanti la sezione maestra di fusoliera
Acquisite le informazioni contenute nel File Input, il codice avvia il ciclo iterativo di dimensionamento della sezione maestra, procedendo "dall'interno verso l'esterno", a partire dalla stima della massima larghezza interna di cabina Wi (fig. 1-7, (a)).
Questa è direttamente correlata all'ingombro dimensionante Wc, ottenuto incrementando l'ingombro Ws della fila trasversale di poltroncine (fig. 1-7, (b)), da entrambi i lati, della distanza seat_gap stabilita tra la parete di cabina ed il bracciolo della poltroncina ad essa adiacente.
Inoltre, in base alle convenzioni adottate8, è possibile porre una relazione tra l'ingombro dimensionante Wi e la quota di posizione, Zoc, del centro del lobo di cabina.
8
In primo luogo, la convenzione relativa alla posizione del FRP (§ 1.2.3), nonché, le convenzioni relative alla posizione degli ingombri dimensionanti Wc e Wi e, per finire, la convenzione circa la geometria che descrive il contorno di sezione.
In base a queste, infatti, l'ingombro Wc, è stato disposto alla quota h1, ovvero all'altezza della sommità del bracciolo della poltroncina rispetto al pavimento, mentre, l'ingombro Wi è stato collocato alla quota Zoc, ovvero in corrispondenza dell'altezza del centro del lobo di cabina. Infine, si è ipotizzato che il contorno di sezione, sia esterno che interno, sia definito, almeno in prima approssimazione, mediante archi di conica (cerchio o ellisse), ciascuno dei quali descritto mediante una precisa equazione canonica.
Proprio quest'ultima evidenza ha suggerito l'opportunità di scegliere la quota Zoc
come variabile di controllo del ciclo di dimensionamento.
Il passo successivo, nello sviluppo del flusso logico operativo di PACO, è il dimensionamento dello spessore tw (thickness of wall) di sezione.
Questo, risultante dai contributi distinti portati dalla struttura e dal rivestimento interno di cabina, è posto in relazione con l'ingombro Wi9 e stimato mediante
l'interpolazione di dati storici, rappresentativi delle diverse categorie di velivoli.
A questo punto, il codice, in base all'input dell'Utente, attiva la procedura di dimensionamento più idonea in relazione alla dislocazione dello spazio destinato allo stivaggio del cargo, ovvero, a seconda che quest'ultimo debba essere accomodato sullo stesso piano di carico dei passeggeri o, in alternativa, su un ponte di carico inferiore.
Nella prima delle eventualità suddette, trattandosi, per lo più, di fusoliere recanti un singolo ponte di carico10, il criterio applicato al dimensionamento del contorno della parete interna di cabina coincide con il rispetto della clearance di cortesia per il passeggero adiacente a questa (cfr. § 1.2.1 e fig. 1-3 (a)).
Nel secondo caso, trattandosi, di fusoliere recanti, almeno, un doppio piano di carico, la sezione maestra può essere, indifferentemente, monolobata o bilobata.
Per entrambe le tipologie di forma, il codice procede, prima di tutto, alla stima dello spessore tMD (thickness of Main Deck) della struttura del ponte di cabina.
Quest'ultimo, posto in relazione con la larghezza massima WMD del ponte, a sua volta dipendente dalla larghezza WFRP e dalle altre dimensioni caratteristiche del lobo interno di cabina, è stato valutato in base al best fit dei dati storici11.
Seguono, nell'ordine, la stima degli ingombri della "configurazione cargo"12, della posizione ZLD e dimensione WLD del ponte cargo, nonché degli altri ingombri del vano di stiva ventrale.
Nel caso di sezione bilobata, il software procede al dimensionamento13 del contorno interno del lobo di cabina e di quello ventrale; i criteri applicati sono, rispettivamente, il rispetto della clearance di cortesia del passeggero adiacente alla parete ed il rispetto
9
Cfr. Appendice C.
10
Generalmente, quando è presente un solo piano di carico, la geometria di sezione è monolobata o, al più,essa presenta la tipica forma bilobata caratterizzata dall'eccentricità "positiva" dei lobi, ovvero dalla posizione più elevata del centro del lobo ventrale e dalla sua maggiore dimensione rispetto al lobo di cabina (tipo ATR 42).
Infatti, la geometria bilobata classica (tipo B 727, DC 9 o A320), caratterizzata dall'eccentricità "negativa" dei lobi e concepita per l'accoglienza di un vano stiva all'interno del lobo ventrale, è tipica delle fusoliere recanti, almeno, due piani di carico.
11
Cfr. Appendice C.
12
Il termine è, qui, indicativo di tipologia, numero e disposizione dei contenitori (container, pallet) scelti per il trasporto di merci e bagagli.
13
Fig. 1-8: (a) possibile layout di sezione ottenuto con priorità cabina
(b) medesimo layout di sezione dopo modifica della configurazione cargo.
della clearance necessaria all'accomodamento della configurazione cargo assegnata dall'Utente (fig. 1-3, (b)).
Nel caso di sezione monolobata, non essendo possibile il simultaneo rispetto delle relazioni che traducono in termini analitici i due criteri di dimensionamento14, il codice attiva, la procedura più idonea a seconda che l'utente abbia assegnato la priorità al primo dei suddetti criteri piuttosto che al secondo.
Nella prima eventualità, il risultato prodotto dal codice potrebbe non verificare la clearance minima necessaria per accomodare la configurazione cargo (fig. 1-8, (a)).
In tal caso, l'Utente dovrà modificare opportunamente15 il File input e far girare nuovamente il codice fino ad ottenere un layout di sezione soddisfacente (fig. 1-8,
(b)).
14
Nel caso di sezione monolobata, infatti, il contorno di sezione è continuo e, tanto il tratto di conica relativo alla cabina, quanto il tratto ventrale, devono avere in comune il centro.
Non possono essere rispettate, simultaneamente, la clearance del passeggero di parete e quella di accomodamento della configurazione cargo perchè il problema matematico risulta insolubile a causa del difetto del numero di variabili (il centro di sezione) rispetto al numero di equazioni linearmente indipendenti (le due condizioni di clearance.
15
L'intervento di modifica potrà riguardare uno o più parametri di configurazione degli spazi interni, piuttosto che una scelta differente degli arredi di cabina.
LD-3/w layout esplorativo
LD-3(35)/w layout modificato
Fig. 1- 9: (a) possibile layout di sezione ottenuto con priorità cargo
(b) medesimo layout di sezione dopo modifica della configurazione di cabina (intervento di aumento del parametro seat_gap).
Nella fattispecie del caso riportato in fig. 1-8, è stato sufficiente modificare la configurazione cargo passando dal container STtanDard LD3/w ad un container "USer Defined", modificato in altezza in base allo spazio disponibile in stiva.
Nell'eventualità che l'Utente abbia indicato, invece, la priorità cargo, è possibile che il risultato prodotto dal codice non soddisfi la clearance minima di cortesia per il passeggero adiacente alla parete di cabina (fig. 1-9, (a)).
In tale evenienza, ancora una volta, l'Utente dovrà intervenire sul File input fino ad ottenere un layout di sezione soddisfacente (fig. 1-9, (b)).
Nella fattispecie del caso riportato in fig. 1-9, è stato sufficiente l'aumento della distanza seat_gap tra il blocco di poltroncine adiacente alla parete e quest'ultima.
Infine, il codice salva i risultati in un opportuno file di testo, organizzandoli in forma di tabelle di dati16.
A chiusura della sessione di lavoro vi è la presentazione del layout grafico della sezione maestra.
16
MATLAB© è in grado, infatti, di gestire files di testo (aventi estensione .txt). Con il comando diary (sintassi: diary 'nomefile.txt') è possibile creare, scrivere e salvare un file testo che, in un qualunque momento successivo, l'Utente può editare (sintassi di comando: edit 'nomefile.txt') oppure richiamare nella command window di Matlab (sintassi: type 'nomefile.txt'). LD-3 LD-3 layout esplorativo LD-3 LD-3 layout modificato (a) (b)
Fig. 1- 10: Escursione applicativa del software PACO
1.4 Flessibilità operativa
Il target applicativo del software è stato centrato17 sulle fusoliere dei velivoli da trasporto passeggeri, caratterizzate da sezione maestra monolobata o bilobata, recante fino ad un massimo di due ponti di carico e dieci poltroncine allineate (fig. 1-10).
Le categorie di velivoli corrispondenti sono (per ognuna, alcuni esempi sono indicati in parentesi):
3. Business/Executive (Dassault Falcon 50, Lockheed jetstar II, Cessna Citation II) 4. Regionali Turboprop e Turbogetto (ATR 72, Dornier 328, Embraer ERJ 140) 5. Turbofan, a corto/medio raggio (B 727, A 320, DC 9)
6. Turbofan a lungo raggio (B 767, B 777, A 310, A 340, Lockheed Tristar)
La flessibilità operativa del codice, in relazione alle applicazioni limitate ai velivoli a fusoliera convenzionale, risulta abbastanza elevata (fig. 1-11).
Inoltre si evidenziano alcune potenzialità d'indagine esplorativa piuttosto interessanti.
Ad esempio, nel rispetto dei limiti imposti dai requisiti applicativi, è possibile caratterizzare la geometria della sezione (fig. 1-12, (a) e (b)), oppure (fig. 1-12, (b)) è possibile esplorare configurazioni abbastanza prossime a quelle delle fusoliere con doppio ponte di carico passeggeri (tipo A 380).
17
Le motivazioni sono quelle discusse nella sezione introduttiva di questo lavoro (cfr. Introduzione, § 1.3.1).
Fig. 1- 11: Esempi applicativi del software PACO
Quest'ultima evidenza suggerisce la possibilità di superare il limite applicativo relativo al numero di ponti di carico, mediante l'integrazione futura del codice con una sezione espressamente predisposta per il raddoppio del ponte di carico passeggeri.
1.5 Limiti applicativi
Fermo restando il campo operativo limitato ai velivoli da trasporto civile, l’unico vero limite di PACO è l’analisi delle fusoliere di velivoli ad architettura non convenzionale.
Falcon 50
Embraer ERJ 140
ATR 42
Fokker 28
DC 9
LD-3/w
A 320
LD-3 LD-3
B 777
LD-3 LD-3
A 340
LD-1 LD-1
Lockheed Tristar
Fig. 1- 12: Esempi di potenzialità applicative di PACO
Infatti, come già posto in evidenza18, l’esclusione dal campo applicativo delle fusoliere configurate per il trasporto misto (Combi) e/o di quelle configurate per il trasporto esclusivo delle merci (Freighter), non rappresenta una limitazione effettiva delle potenzialità del codice.
Limitare a dieci il massimo numero di poltrone affiancate, equivale ad imporre il limite massimo di due corridoi19.
Anche questo non rappresenta una limitazione effettiva poiché la quasi totalità della produzione aerospaziale per impieghi civili soddisfa la suddetta prescrizione.
Infine, per quanto riguarda il numero di ponti di carico, bisogna effettivamente riconoscere l’attuale limite sofferto dal codice.
Tuttavia, vale quanto detto al paragrafo precedente, circa la possibilità attuale di “simulare” la forma e le dimensioni esterne della sezione di fusoliera dei velivoli a triplo ponte di carico (fig. 1-12).
18 Cfr. Introduzione, § 2.1. 19 Cfr. /11/, § 25.817. Fun narrow LD-3 LD-3 Fun wide
1.6 Strutturazione del File Input
La struttura operativa del codice, ovvero "chi deve fare cosa", definisce anche, con maggiore dettaglio, obiettivi, strumenti e, soprattutto, risorse necessarie in termini di dati ed informazioni.
Pur rimanendo nell'ambito della connotazione tipica di uno strumento concepito per l'analisi preliminare, causa la difficoltà di coniugare l'obiettivo di flessibilità operativa con la vastità del campo applicativo, sussiste il problema dell'efficiente gestione di una gran quantità d'informazioni, parte delle quali provenienti dai requisiti e dalle specifiche e parte, invece, dalle scelte dell'Utente.
Il File Input Standard, ovvero un "canovaccio" opportunamente commentato, modificabile, "in toto" oppure solo in parte, in base alle esigenze dell'Utente, rappresenta una soluzione vantaggiosa20 in termini di tempo necessario all'istruzione dell'Input, nonché efficace nella gestione degli items pluridimensionali (poltroncina e container/pallet) mediante l'utilizzo dei data banks a questi espressamente dedicati.
Al fine di rendere più efficiente lo "smistamento" dei dati tra le diverse sezioni del codice dedicate al design di sezione, ovvero alla configurazione ed al dimensionamento di questa, il File Input è stato strutturato (vd. fig. 1-13), suddividendo i parametri associati ai diversi dati informativi, in base alla natura di questi, in cinque categorie di pertinenza (Architettura, Geometria, Configurazione di Cabina, Configurazione Cargo, Stiva).
A queste, è stata aggiunta una sesta categoria cui appartengono i parametri "switch", adibiti alla gestione dei defaults del codice, ovvero dei dati (ergonomici, di distanziamento e movimentazione del cargo all'interno della stiva ed altro ancora) che, generalmente, vengono modificati con minore frequenza.
Il codice, in base al valore (1 oppure 0) assegnato dall'Utente a ciascuno dei suddetti parametri switch, secondo la logica on/off, attiva o disabilita una determinata sezione interattiva, finalizzata alla modifica dei defaults gestiti dal parametro.
Sono due i modi per effettuare la modifica, globale o parziale, di un File Input già residente in memoria:
1. Editare direttamente (dalla command window di Matlab©) il file da modificare. 2. Utilizzare la function MODIFY_INPUT predisposta per lo scopo.
20
Altri tipi di soluzioni, ad esempio basate sulla modalità "interattiva" (si veda il comando "input", sintassi : "variable_name = input('comment')" ), ad ogni modifica, anche solo parziale, necessitano il passaggio in rassegna di tutti i dati d'Input, con conseguente dilatazione del tempo necessario all'istruzione di questo.
Fig. 1- 13: Struttura del File Input
Del nuovo File Input, il codice crea una versione "file dati" ed anche una versione "file testo", entrambe con lo stesso nome (scelto dall'Utente) addizionato del suffisso "_PACO_INPUT", ma con estensione ".mat" e ".txt", rispettivamente.
Il vantaggio risultante è, per l'Utente, la possibilità di avere a disposizione una banca dati cui attingere per rendere ancora più veloce l'istruzione di un nuovo File
Input.
Infatti, scegliendo di modificare un File Input memorizzato, riferito ad una configurazione di fusoliera simile a quella da analizzare, è possibile minimizzare il numero di modifiche da effettuare.
ARCHITETTURA tipo di velivolo n° ponti di carico GEOMETRIA tipo di sezione forma del lobo
di cabina orientamento asse maggiore di sezione CABINA scelta poltroncina composizione blocchi di poltroncine distanza tra il blocco di poltrone e la parete CARGO scelta containers classe riferimento standard dei containers Altezza containers (User Defined) STIVA larghezza max altezza max larghezza ponte FILE INPUT DEFAULTS Geometria Interni cabina Ergonomia Cargo UTENTE
Fig. 1- 14: Mappa del codice
1.7 Mappa del codice
Il codice PACO, nella sua forma definitiva, è risultato essere l'insieme di functions e
script, ovvero di M-files, ma anche di files dati e files testo, rispettivamente
classificabili come Mat-files e Txt-files.
PFD_CODE PACO_files MODIFY_INPUT CODE_files INPUT_files OUTPUT_files Mat_files M_files Txt_files Mat_files M_files
PACO PALOMA PFD_CODE
PALOMA_files DATA_banks
futuri interventi di modifica o d'integrazione,nonché a beneficio dell'Utente per una maggiore consapevolezza d'uso, l'intero corpo del software è stato ordinato secondo una precisa struttura logica (fig. 1-14), riassumibile in quattro livelli successivi.
Al primo livello sono collocati i programmi esecutivi dei moduli software; a questi si aggiunge un modulo di editazione e modifica del File Input.
Al secondo, sono raggruppati i Files (di ogni genere) distinti a seconda dell’appartenenza ad un modulo software piuttosto che ad un altro.
Qui sono collocati anche i Data Banks in quanto essi possono essere considerati files "trasversali", cioè di accesso comune ad entrambi i moduli software21 che costituiscono il corpo di PFD_CODE.
Al terzo livello si è operata una distinzione tra i files che sono riconducibili, rispettivamente, al corpo esecutivo del modulo software, all'Input e all'Output.
Al quarto, infine, per ognuna delle categorie considerate, sono state distinte tre diverse sotto-categorie che raggruppano M-files, Mat-files e Txt-files, ovvero, riferite rispettivamente a script e functions, files dati e files testo.
21
PACO e PALOMA, infatti, condividono gli items di configurazione degli interni di cabina e di stiva (poltroncine e containers/pallets).
