Gestione input

Sezione II: Aspetti specifici 4.3 Analisi prove coast-down

Analisi concettuale

4.1 Gestione input

Il primo aspetto che doveva essere affrontato per la realizzazione del progetto richiesto è il caricamento dei dati da elaborare, in modo da definire una procedura standard da utilizzarsi poi in tutto il programma. Prima di presentare la metodologia individuata, si espone la procedura in uso evidenziandone le criticità, in modo che siano più chiari i motivi che hanno condotto alla soluzione adottata.

Tipicamente, la sequenza di operazioni necessaria era la seguente:

• si caricano i dati acquisiti e salvati dal programma di acquisizione, aventi estensione *.dat (e d’ora in poi chiamati dat-files), in un apposito visualizzatore (VSLZR);

• nel VSLZR, il calibratore cerca manualmente le porzioni del file di interesse, attiva i canali desiderati e quindi procede all’esportazione in formato testuale;

• VSLZR, durante l’esportazione, provvede a correggere il disallineamento delle basi temporali definendo un nuovo riferimento con tempo di campionamento a scelta dell’utente;

• i file esportati vengono caricati in un foglio di calcolo per l’elaborazione. I file in formato testuale hanno come pregi la facilità di scambio tra programmi e di consultazione per l’utente, che può aprili e leggerne direttamente il contenuto. Come contro hanno però dimensioni elevate e, per l’utilizzo nel tool sviluppato, richiedono una programmazione più sofisticata per poterne importare il contenuto in Matlab.

I problemi principali riscontrati sono:

• il contenuto di un file testo viene letto riga per riga, mentre i dati sono organizzati per colonne, quindi è necessario leggere tutto il file, impiegando un tempo relativamente elevato;

• deve essere indicato con precisione il formato dei dati che si stanno caricando, compresi spazi e segni di tabulazione, altrimenti il programma non è in grado di interpretare correttamente le informazioni lette;

• se nel file non è presente una riga di intestazione, non è possibile sapere a cosa si riferiscono i valori se non conoscendo dell’ordine con cui sono elencate le variabili; purtroppo questo dipende dalla sequenza con cui l’utente seleziona i canali in VSLZR e non vi è modo per tenerne traccia; • se è presente la riga di intestazione, si può implementare una procedura che

associ un nome ad ogni colonna del testo e ricostruisca i dati cercando l’etichetta corrispondente; se però questa varia, la procedura fallisce a meno

di inserire manualmente ogni volta i nuovi nomi canali.

Come è evidente, oltre alla lentezza, il punto debole più importante è che se il file risulta anche solo leggermente differente da quanto atteso, l’importazione fallisce. Questo problema, affrontabile al costo di una notevole complicazione del codice incaricato della lettura, ma soprattutto la necessità di esportare uno ad uno ogni singolo file acquisito con notevole spreco di tempo e rischio di errore, ha spinto a cercare una soluzione alternativa.

Una ricerca effettuata, vedere a tal proposito (9), ha permesso di concludere che i dat-file sono di tipo binario (non leggibili direttamente dall’utente), ma sono di fatto dei database di dati, contenenti tutti i segnali che si è deciso di salvare in fase di configurazione dell’acquisizione, ciascuno associato al relativo riferimento temporale e abbinato ad una serie di informazioni aggiuntive come nome, descrizione canale (in gergo, “metadati”).

Inoltre si è scoperto che, tra le aziende specializzate nel settore acquisizione dati, esiste un particolare standard di riferimento per la struttura dei file prodotti, chiamato Measure Data

File (MDF). Sviluppato come formato proprietario negli anni ‘90 da Bosch e Vector Informatik,

negli anni molti produttori si sono allineati ad esso e così si è diffuso al punto che nel 2003 è stato ufficialmente adottato dalla Association for Standardisation of Automation and Measuring

Systems: da quel momento le sue specifiche sono di pubblico dominio e consultabili da tutti. In

genere ogni produttore poi aggiunge elementi non previsti nello standard, ma questo non pregiudica le possibilità di scambio.

Anche il programma di acquisizione in uso in azienda salva i suoi dat-files rispettando questo formato e così è stato possibile reperire un tool specifico (d’ora in poi MDFTOOL), in grado di leggere file scritti secondo questo standard e importarli nel workspace.

Il tool è dotato di interfaccia grafica ma, più utile per il presente progetto, è utilizzabile anche tramite riga di comando: basta una sola riga di codice per caricare un intero dat-file. Una volta importato, tutti i canali contenuti divengono normali vettori ed è possibile perciò manipolarli utilizzando tutti gli strumenti di Matlab.

Come anticipato in §3.5, i dat-file presentano il problema dei riferimenti temporali. MDFTOOL importa i dati grezzi e non corregge questa situazione: si limita a creare diversi vettori time (uno per 100ms, uno per 10ms, etc.), chiaramente tutti di lunghezza diversa, e per ogni canale indica a quale time si riferisce.

Naturalmente questa situazione rende difficoltosa la manipolazione dei dati perché Matlab lavora su vettori e risulta estremamente scomodo trattare vettori di lunghezza diversa, un motivo fra tutti l’impossibilità di confrontare direttamente due segnali ricorrendo agli indici e dover invece riferirsi ogni volta al tempo.

Analisi concettuale da MDFTOOL:

• si fissa un nuovo riferimento temporale, unico per tutti i segnali, caratterizzato da un tempo di campionamento arbitrario (a scelta dell’utente);

• i canali non utili sono scartati;

• a partire dal nuovo riferimento temporale, vengono ricostruiti i segnali di interesse tramite interpolazione;

Il tempo di campionamento in questa fase non è legato in alcun modo al tempo di acquisizione, ma ovviamente se si sceglie un tempo molto più breve, l’estesa interpolazione necessaria porta a sfumare il senso fisico dei valori ricavati; se invece è molto più alto, allora in fase di acquisizione è stato scelto un tempo inutilmente breve con spreco di risorse.

Chiaramente l’operazione ricorda molto da vicino quella eseguita manualmente al momento dell’esportazione da VSLZR, tuttavia in questo modo è possibile automatizzare il processo, velocizzare le operazioni e scongiurare il rischio di errore andando a definire una volta per tutte le azioni da svolgere.

Quando però il primo prototipo del tool è stato sperimentato, è emerso un problema: il processo di importazione dei canali richiedeva un tempo di esecuzione decisamente elevato, nell’ordine delle decine di secondi per ogni file.

Dato che il committente desiderava poter analizzare in moto automatizzato molti file alla volta, impiegare decine di secondi ciascuno, solo per la fase di importazione, è stato ritenuto inaccettabile. Indagando sulle cause di questa lentezza, sono stati individuati due punti critici:

1. MDFTOOL, in assenza di ulteriori istruzioni, opera importando tutti i canali dal dat-file. Questo è un problema nel momento in cui l’acquisizione contiene molti più canali del necessario (cioè quasi sempre): si può tranquillamente arrivare a qualche centinaio.

2. MDFTOOL lavora utilizzando file temporanei, quindi tutta l’operazione richiede numerosi accessi al disco rigido: il file sorgente deve essere letto, file temporanei vengono scritti e letti durante le operazioni, viene scritto un file contente i dati acquisiti di tutti i canali, da questo vengono infine letti i canali e caricati nel workspace.

Si è proceduto allora all’ottimizzazione di questi punti critici:

1. da un’analisi del codice è emersa la possibilità di fornire, tramite un parametro al momento della chiamata, una lista dei canali d’interesse in modo che dal file sorgente vengano letti solamente questi;

file temporanei, conservando tutte le informazioni in memoria.

Il risultato di questi interventi è, per un file di riferimento, un tempo di importazione ridotto dai circa trenta secondi originari a meno di un secondo.

C’è però un’osservazione da fare: per non utilizzare file temporanei su disco è necessario tenere in memoria tutti i dati e questo è possibile solo con dat-file di dimensioni limitate, compatibilmente con la memoria volatile (RAM) disponibile sul pc in uso. Ora, trattandosi in questo caso di prove di durata comunque limitata a poche decine di minuti, questo non costituisce un problema.

Concludendo, la soluzione trovata presenta i seguenti vantaggi rispetto alla procedura di primo tentativo:

• possono essere letti direttamente i file acquisiti senza necessità di pre- elaborazione (risparmio di tempo, rischio di errore umano eliminato); • nel file sono presenti tutti i canali, così è possibile scegliere di volta in volta

con facilità quelli di interesse (maggiore flessibilità);

• la programmazione è molto più semplice e il tool si occupa di recuperare tutti i canali necessari (procedura più robusta);

• il caricamento dati vero e proprio richiede meno tempo (risparmio di tempo)