1

POLITECNICO DI MILANO

SCUOLA DI INGEGNERIA INDUSTRIALE E DELL’INFORMAZIONE

LAUREA MAGISTRALE IN INGEGNERIA INFORMATICA

MACS 1.1 – Rimodellazione della base di dati e aggiunta di nuovi strumenti di misurazione per un applicativo di automazione della taratura di sensori di temperatura

Tesi di:

Tommaso Calcina 817711

Relatore:

Prof. Alessandro Pesatori

Anno Accademico 2014/2015

2

Ringraziamenti

Sono grato a troppe persone per poterle citare tutte.

Eppure è difficile, mentre scrivo, riuscire ad essere sintetico.

Un percorso come quello universitario ti da così tanto, in termini puramente umani,

che credo non sia possibile confinare tutti i grazie in un “a tutti quelli che mi

sostengono, che mi vogliono bene”.

Con questo paragrafo voglio cercare di esprimere tutti i grazie detti, quelli non detti,

quelli abbozzati, meritati e immeritati, a tutti coloro i quali hanno incrociato il loro

bellissimo, ricco ma faticoso percorso con il mio.

Un grazie quindi a Diego, Leo, Ale, Luca, Alle, perché due anni sono volati anche

per la vostra simpatia e compagnia.

Grazie a Pala, al trio Canino-Ballestri-Ricetti, Otta, Robi, perché con le nostre cene,

feste e serate abbiamo creato qualcosa che va oltre ogni valore materiale.

Grazie a tutti i miei nuovi colleghi, perché mi avete fatto sentire subito parte di una

grande e bella famiglia.

Grazie a Capo, Monica e Alice, perché nonostante le distanze continueremo a

ripigliarci insieme.

Grazie a Matte e Lalli, perché avete davvero riempito la casa, in tutti i sensi.

Grazie ad Ari, con cui ho iniziato questi ultimi due anni universitari per pura

casualità, e tornando indietro rifarei tutto. Sei stata una bellissima scoperta.

Un grazie a Pippo, per la vicinanza nonostante le distanze, col quale mi attende

una nuova avventura. Non vedo l’ora.

Grazie ad Andre e Carlo, perché siete stati un grande supporto, anche se non ve

l’ho mai detto.

Grazie a Mezza e Garo, perché in cinque anni siete riusciti a farvi volere così bene

che mi sentirò per sempre in debito con voi.

3

Grazie a Lory, perché mi hai insegnato ci sono legami che vanno oltre ogni

ostacolo, oltre ogni difficoltà, spero che continueremo a sorreggerci a vicenda ogni

volta che ne avremo bisogno.

Grazie ad Alessia, perché sei una persona molto migliore di me.

Grazie ai miei parenti, perché mi dimostrano ad ogni occasione quali sono i veri

valori di una famiglia.

Grazie a Valentina, non potevo chiedere sorella migliore perché hai tutte le buone

qualità che mancano a me, e il tuo futuro sarà sicuramente splendido.

Grazie a mia madre e mio padre, perché senza di voi, senza il vostro sostegno

incondizionato, senza la vostra passione nel crescere un figlio ed alimentare i suoi

interessi, senza di voi sicuramente non ce l’avrei fatta.

Ringrazio inoltre il mio relatore, prof. Alessandro Pesatori, per la disponibilità

mostrata nonostante i mille impegni.

Menzione necessaria infine va fatta all’ingegner Francesco Braguti, realizzatore,

con il relatore prof. Alessandro Pesatori, della prima versione di MACS, il quale è

stato di fondamentale importanza nelle fasi critiche dell’ideazione e dello sviluppo,

e che anche grazie alla sua precisione e tempestività nei suggerimenti mi ha

portato a concludere in questo modo il mio percorso.

4

Sommario

L’argomento di questa tesi è lo studio e l’implementazione di diverse modifiche

all’applicativo MACS 1.0, utilizzato per l’automazione di campagne di taratura

all’interno di alcuni laboratori di taratura.

MACS permette all’operatore di automatizzare determinate operazioni durante

tutto il processo di taratura di un dato oggetto, nel nostro caso termocoppie e

termoresistenze (anche chiamate termometri a resistenza).

La prima parte del lavoro si è basata sullo studio delle funzionalità già presenti

all’interno dell’applicativo, nonché dell’analisi dell’immensa e poco uniforme base

di dati Access su cui si appoggiava. L’intento principale è stato infatti quello di

snellire tale base di dati il più possibile, riducendola a una versione minimale e

facilmente aumentabile, ogniqualvolta se ne presenti la necessità.

Una volta individuati i moduli LabVIEW su cui era necessario apportare delle

modifiche e implementata la base di dati studiata, è stato necessario integrare i

nuovi strumenti utilizzati, multimetro HP34401A e switching unit (chiamato anche

scanner) Agilent 34970A, nonché il nuovo RDBMS MySQL all’interno di un loop

consolidato e funzionante quale era quello dell’applicativo MACS alla versione 1.0.

Lo scopo principale è stato quello di arrivare ad una versione di MACS che

comunicasse il meno possibile con basi di dati diverse, e loggasse in esse soltanto

i dati strettamente necessari alla compilazione di un certificato di taratura,

seguendo il più possibile procedure semplici e lineari.

Coerentemente alla linea della semplicità è stato scelto di sviluppare

un’applicazione Desktop utilizzando il linguaggio Java nella piattaforma Standard

Edition, con il framework Swing, per la gestione della parte “statica” del database,

ovvero quelle tabelle in cui vengono memorizzati i dati relativi agli strumenti e ai

campioni appartenenti al laboratorio, e pure degli oggetti che di volta in volta sono

tarati utilizzando MACS.

5

Questa tesi è stata suddivisa in quattro capitoli, nel primo dei quali viene fatta

un’introduzione sul mondo della taratura in generale e sulla situazione di MACS

precedentemente alle modifiche in oggetto.

Nel secondo capitolo vengono descritti gli strumenti, sia hardware che software,

utilizzati nel corso dello sviluppo, e le metodologie a cui si è fatto riferimento.

Il terzo capitolo raccoglie tutte le fasi di implementazione, suddivise per area di

effort, spiegando nel dettaglio le scelte implementative, nonché le funzioni delle

novità all’interno del contesto dell’applicativo nel suo complesso.

Il quarto capitolo funge da ricapitolazione dei risultati e riepiloga pure i necessari

sviluppi futuri a cui l’applicativo deve essere sottoposto per raggiungere la totalità

degli obiettivi prefissati con la decisione dell’innovazione partita da una versione

1.0 stabile.

6

Indice

1. Introduzione ................................................................................................................. 9

1.1. La taratura ................................................................................................................ 9

1.2 Campagna di taratura .............................................................................................. 11

1.3. Stato dell’arte – MACS 1.0 ..................................................................................... 12

2. Strumenti e metodologie ............................................................................................ 13

2.1. LABView ................................................................................................................. 13

2.2. MySQL .................................................................................................................... 15

2.3. Java ........................................................................................................................ 16

2.4. Strumenti Hardware ................................................................................................ 17

3. Implementazione ....................................................................................................... 19

3.1. Base di dati ............................................................................................................. 19

3.2. Applicazione Desktop ............................................................................................. 22

3.3. MACS ..................................................................................................................... 27

3.3.1. Struttura ............................................................................................................... 27

3.3.2. Novità .................................................................................................................. 31

4. Conclusioni e sviluppi futuri ....................................................................................... 39

4.1. Conclusioni ............................................................................................................. 39

4.2. Sviluppi futuri .......................................................................................................... 40

5. Bibliografia ................................................................................................................. 42

7

Indice delle figure

Figura 1: Termometro a resistenza di platino (da Metrologia della Temperatura p.28) . 10

Figura 2: Schema generale di una termocoppia ............................................................ 10

Figura 3: Schema di registrazione dei dati di una taratura ............................................ 11

Figura 4: Screenshot della prima interfaccia implementata in MACS 1.0 ...................... 12

Figura 5: Screenshot di Front Panel e Block Diagram di un .vi, con le librerie di moduli disponibili ................................................................................................................... 13

Figura 6: Pagina principale della MySQL Workbench dopo la connessione al database .................................................................................................................... 16

Figura 7: Interfaccia dell'IDE NetBeans ......................................................................... 17

Figura 8: Multimetro HP 34401A utilizzato per i test ...................................................... 17

Figura 9: Agilent 34790A utilizzato ................................................................................ 18

Figura 10: Stato della vecchia base dati ........................................................................ 19

Figura 11: Diagramma E-R ottenuto dall'analisi dei dati necessari ................................ 20

Figura 12: mockup single-window studiato per l'applicazione di archivio ...................... 23

Figura 13: Class Diagram dell'applicazione desktop di archivio .................................... 24

Figura 14: Finestra singola su cui si svolge tutta l'esecuzione dell'applicazione ........... 25

Figura 15: Alert che chiede la conferma della cancellazione ......................................... 26

Figura 16: State machine riprodotta in LabVIEW (da www.ni.com) ............................... 27

Figura 17: Implementazione del ciclo producer/consumer in LabVIEW (da www.ni.com) .............................................................................................................. 28

Figura 18: La nuova pagina principale di MACS ............................................................ 30

Figura 19: Come appare oggi la finestra del tab SETUP ............................................... 30

Figura 20: Un .vit nel tree della project-window (destra) e la sua rappresentazione nel Block Diagram (sinistra) ............................................................................................. 31

Figura 21: Schematizzazione di un driver ...................................................................... 31

Figura 22: La cartella instr.lib, presente nel path di installazione di LabVIEW, contenente tutti i driver utilizzabili, sono riquadrati quelli inseriti per le recenti implementazioni ......................................................................................................... 32

Figura 23: Il modulo OpenTabCampagna.vi, utilizzato per recuperare le campagne dal database .............................................................................................................. 33

Figura 24: Finestra dell'ODBC admin in cui si notano i vecchi ODBC per Access e quello nuovo per MySQL ............................................................................................ 34

Figura 25: Come viene aperta la connessione al DB in MACS 1.1: si nota la connection reference in uscita che verrà passata per tutto il flow di esecuzione ....... 34

8

Figura 26: Esempio di gestione dell'inserimento. Il Context Help di LabVIEW attivo elenca gli input e gli output ......................................................................................... 35

Figura 27: Nuva gestione della funzione di Update ....................................................... 36

Figura 28: Nuova gestione della funzione di Delete ...................................................... 36

Figura 29: Il modulo getKeyFromAttribute.vi, implementato per il mantenimento dell'integrità referenziale ............................................................................................ 37

9

1. Introduzione

In questo capitolo viene fatta un’overview generale sul mondo della taratura (cosa

si intende per taratura, quali sono i riferimenti, quali considerazioni matematiche e

statistiche si fanno), per introdurre in seguito il concetto di applicativo per

l’automazione di una campagna di taratura e tutto ciò che riguarda lo stato dell’arte

prima che si mettesse in atto questo lavoro di tesi.

1.1. La taratura

Viene definito taratura il processo di confronto di uno strumento di misura con un

altro, di migliore qualità, il cui risultato determina un insieme di dati di correzione

per le letture dello strumento tarato. Così facendo, è possibile ottenere per lo

strumento oggetto di taratura una incertezza di misura residua minore di quella

precedentemente assegnatagli.

L’incertezza di misura va interpretata come la stima del grado di non conoscenza

della grandezza in oggetto.

Il risultato di una misura quindi non sarà mai semplicemente un numero riferito alla

misura singola, ma sarà quel numero misurato accompagnato dall’incertezza con

cui si può dire di conoscere tale misura.

Il confronto messo in atto durante una taratura avviene in ossequio ad una

fondamentale caratteristica metrologica in ambito commerciale e legale: la

riferibilità. Essa indica la proprietà di una misura di essere messa in relazione con

quella fornita da un campione riconosciuto. La realizzazione, il mantenimento,

nonché l’adeguamento alle nuove scoperte in ambito scientifico dei campioni

primari avviene sotto il controllo e la supervisione di organismi internazionali e

nazionali per la Metrologia.

Con il termine catena di riferibilità indichiamo il trasferimento delle realizzazioni

delle unità di misura, partendo dai campioni-prototipo, fino ad arrivare agli

strumenti in commercio che ne realizzano la misurazione.

Un termometro a resistenza, o RTD, o ancora termoresistore è un trasduttore

elettrico che sfrutta la proprietà dei metalli di variare la conducibilità elettrica con la

10

temperatura. Vengono fabbricati in genere con materiali sensibili come il platino,

proprio per le sue caratteristiche di lunga durata, stabilità e riproducibilità.

Figura 1: Termometro a resistenza di platino (da Metrologia della Temperatura p.28)

Le termocoppie sono invece trasduttori che utilizzano le proprietà termoelettriche

derivanti dall’accoppiamento di due conduttori di materiali diversi posti a

temperature differenti. Il loro funzionamento è basato sull’effetto Seebeck secondo

cui la tensione (tra i due fili) al giunto freddo è proporzionale alla differenza di

temperatura fra le due giunzioni.

Figura 2: Schema generale di una termocoppia

La scelta di termometri termodinamici è obbligatoria per principio ma scomoda

nella pratica. Essi infatti sono innanzitutto molto complessi e questo fa sì che pochi

laboratori ne possano disporre. In secondo luogo, la loro precisione e riproducibilità

è inferiore a quelle di alcuni termometri pratici.

11

Questi ragionamenti sono alla base della decisione presa nel 1927 di istituire la

Scala di Temperatura Internazionale (STI o ITS), la cui ultima versione risale al

1990 (ITS-1990).

1.2. Campagna di taratura

Il processo per la taratura di un sensore di temperatura è rigoroso e segue degli

step ben precisi, le procedure da seguire sono quindi determinate in base ai

riferimenti di cui un laboratorio dispone.

Lo strumento oggetto della taratura, durante tutta la campagna, viene utilizzato per

misurare dei cosiddetti set point, determinate condizioni termiche in cui poi si

effettueranno dei confronti statistici con le misure di uno strumento campione di

riferimento.

Si parte da una verifica a 0°, il punto del ghiaccio fondente, per poi inserire le varie

prove in oggetto (si effettuano infatti misurazioni di più strumenti

contemporaneamente a confronto con lo stesso campione) in un bagno

termostatato ad una specifica temperatura di riferimento.

Secondo passaggio è la misurazione durante la stabilizzazione della misura,

ovvero misurazioni durante il periodo nel quale gli strumenti arrivano alla

misurazione stabile, quindi si prelevano le misure nelle condizioni di stabilità.

Se disponibili, si utilizzano anche misurazioni di tarature precedenti per effettuare

i confronti.

Una volta terminato il ciclo, si deve nuovamente procedere alla verifica a 0°, quindi

si registrano tutte le misurazioni in una tabella di questo genere:

Figura 3: Schema di registrazione dei dati di una taratura

12

In generale la composizione in step del ciclo di taratura varia in base alle effettive

condizioni di operatività su cui gli oggetti devono essere tarati.

L’output di tutto il processo è quindi un registro in cui sono salvati tutti i dati raccolti

e da cui poi si passa allo studio statistico sulle incertezze descritto in precedenza

che porta alla compilazione del certificato di taratura.

1.3. Stato dell’arte – MACS 1.0

Al momento la versione 1.0 di MACS può essere definita come un’evoluzione nel

tempo di una precedente release, mai veramente utilizzata fino alla sua versione

funzionante in questione.

Viene utilizzato in alcuni laboratori di taratura (es. EMIT-LAS) per automatizzare le

operazioni che compongono una campagna di taratura di uno strumento.

MACS 1.0 contiene i moduli per la misurazione con alcuni strumenti specifici, per

cui era stata progettata la versione iniziale, la comunicazione con la base dati

Access e i moduli di scrittura dei file Excel.

L’interfaccia principale a tabs permette di scorrere le varie sezioni del programma,

non senza qualche difficoltà.

Figura 4: Screenshot della prima interfaccia implementata in MACS 1.0

13

2. Strumenti e metodologie

In questo capitolo vengono presentati nel dettaglio tutti gli strumenti utilizzati per la

realizzazione del progetto, sia software che hardware, in modo da dare una

panoramica generale sia sui singoli elementi che sulla comunicazione tra essi.

2.1. LabVIEW

LabVIEW è un linguaggio di programmazione grafica, proprietario (National

Instruments), il cui utilizzo è quindi soggetto al possesso di una determinata

licenza, ed ha come paradigma fondamentale quello del dataflow.

Un programmatore LabVIEW sviluppa un’applicazione utilizzando i vari .vi delle

librerie di cui dispone, collegando i vari moduli su quello che è definito il Block

Diagram, e gestendo le interfacce utente sul Front Panel.

Questi due pannelli infatti servono allo sviluppatore per dividere la parte di user

interaction (Front Panel) dalla parte strettamente logica (Block Diagram) che va a

comporre un programma, in questo modo, oltre ad avere un disegno logico chiaro,

il programmatore può anche testare, in parallelo, quanto l’effettiva risoluzione

visiva rispecchi le richieste.

Nell’immagine successiva si può vedere quali sono le scelte tra le varie librerie

cliccando col tasto destro sull’uno o sull’altro pannello:

Figura 5: Screenshot di Front Panel e Block Diagram di un .vi, con le librerie di moduli disponibili

14

Per l’esecuzione di un applicativo LabVIEW non è necessario avere installato la

suite completa, con la quale si può effettivamente anche creare o modificare un

applicativo, ma basta avere installato la giusta versione del cosiddetto Run-time

Engine, ovvero: se un applicativo è stato sviluppato con una determinata versione

di LabVIEW, va utilizzato il corrispondente Run-time Engine per poterlo vedere in

esecuzione.

In questo modo qualsiasi utilizzatore di un applicativo, non competente per la parte

di sviluppo, non appesantisce la macchina con un’installazione estremamente

pesante, quanto inutile, ma si limita ad avere soltanto l’abilitazione per

l’esecuzione.

Il concetto del dataflow si abbina bene alla caratteristica modulare e grafica di

LabVIEW. Per ogni modulo, rappresentato a livello fisico da un file di estensione

“.vi” e a livello grafico da blocchi con un’icona propria, sono specificati input e

output, dati che a loro volta sono specificati come obbligatori o opzionali.

Il Run-time Engine di LabVIEW è strutturato in modo tale da autorizzare

l’esecuzione di un modulo solo e soltanto quando tutti i dati di input obbligatori si

trovano all’ingresso di tale modulo, ovvero sono pronti per essere trattati.

In questo modo il developer, strutturando il proprio modulo principale in diversi

“subvi” (sotto-moduli), può cercare di avere un controllo il più possibile ottimale per

l’esecuzione, o quantomeno può riuscire a dare un comportamento deterministico

all’applicazione in questione.

L’utilizzo di LabVIEW è molto diffuso in ambienti in cui si deve necessariamente

passare da una fase di acquisizione dei dati, per poterli trasferire dal mondo reale,

nella stragrande maggioranza dei casi elettronico, al mondo del calcolo

approssimato dell’informazione digitale. Nel nostro caso è dunque MACS ad

essere sviluppato per intero con tale linguaggio di programmazione, data la sua

natura di applicativo per l’automatizzazione di un processo di acquisizione di dati

elettronici.

Data l’enorme diffusione di LabVIEW negli ambienti industriali è quasi normale che

ogni strumentazione hardware venga accompagnata, nella sua distribuzione, da

quelli che vengono definiti “drivers” LabVIEW, ovvero quei moduli software che

15

permettono una corretta interazione tra il software principale e l’hardware,

collegato attraverso specifiche interfacce.

La totalità della comunicazione con la base di dati è gestita, in LabVIEW, in diversi

modi. Per la sua semplicità, nel nostro caso, è stato scelto di utilizzare i moduli

forniti dalla libreria chiamata Database Connectivity Toolkit, rilasciata all’interno

della versione Professional di LabVIEW e ricca di esempi su cui basare la propria

esperienza di sviluppo.

Tutti gli altri moduli utilizzati per lo sviluppo del progetto sono stati scaricati o dal

tool corrispondente di National Instruments (VI Package Manager), dal portale

online di National Instruments o dai siti proprietari dello strumento hardware in

oggetto.

La versione di LabVIEW utilizzata è stata la 2014 32-bit.

2.2. MySQL

MySQL è senza dubbio uno dei RDBMS (Relational DataBase Management

System) più diffusi, almeno nella sua versione free, nello specifico la 5.3.

Nato come progetto OpenSource è stato poi acquistato dal gigante Oracle, il quale

ne ha voluto mantenere comunque le caratteristiche free anche per la sua già larga

diffusione.

E’ stato scelto per lo sviluppo principalmente per la mia esperienza pregressa con

esso, piuttosto che con altri equivalenti, che possono vantare, nelle versioni free,

prestazioni simili. Una versione free infatti è sembrata più che sufficiente in termini

di prestazioni per l’implementazione di cui necessitava il progetto.

Tutte le funzioni legate alla gestione della base di dati vengono fornite o tramite

riga di comando (MySQL shell command) o tramite un’utile ed intuitiva interfaccia

grafica, MySQL WorkBench, anch’essa in versione free, scaricabile dal sito di

MySQL.

16

Figura 6: Pagina principale della MySQL Workbench dopo la connessione al database

2.3. Java

Java è un linguaggio di programmazione orientato agli oggetti, specificamente

pensato per avere la caratteristica fondamentale di essere multi-piattaforma.

Esso infatti ha come principio fondamentale write once, run everywhere, ovvero il

codice compilato può essere eseguito su una qualsiasi piattaforma che ha al suo

interno la corrispondente JRE, o Java Runtime Environment.

Per lo sviluppo dell’applicazione Desktop si è utilizzato il framework Swing, uno dei

principali e sicuramente tra i più immediati per la realizzazione di interfacce

grafiche. L’intento infatti era quello di realizzare un’interfaccia minimale a pagina

singola.

Data la natura Desktop del progetto si è rimasti nell’ambito della cosiddetta Java

SE, Standard Edition, non occorrendo nessun tipo di architettura client-server o

altre funzionalità specifiche della Enterprise Edition.

La versione specifica utilizzata è stata la 1.8.0_45, e tutte le funzionalità sono state

testate per la retrocompatibilità fino alla versione 1.7.

L’IDE (o Integrated Development Environment) utilizzato per lo sviluppo è

NetBeans.

17

Figura 7: Interfaccia dell'IDE NetBeans

2.4. Strumenti Hardware

La strumentazione hardware utilizzata per l’implementazione è composta da un

multimetro e un’unità di switching.

Gli strumenti sono stati collegati tra loro mediante un cavo GPIB e con il PC tramite

un cavo-convertitore GPIB/USB.

2.4.1. Multimetro HP 34401A

Figura 8: Multimetro HP 34401A utilizzato per i test

Un multimetro è uno strumento elettronico che integra in un’unica unità diverse

funzioni di misurazione.

18

In particolare il multimetro utilizzato, modello HP 34401A, può misurare correnti,

tensioni, resistenze, con vari livelli di risoluzione (ad esempio per la misurazione di

resistenze si può scegliere tra 2 o 4 fili), frequenza, periodo, temperatura e

capacità.

Si è scelto di utilizzare questo multimetro per la presenza effettiva all’interno del

laboratorio del Dipartimento, ha una buona risoluzione (6 ½ cifre) e i driver

disponibili sono certificati LabVIEW.

2.4.2. Switching unit Agilent 34970A

Figura 9: Agilent 34790A utilizzato

L’unità Agilent 34790A viene definita come Data Acquisition / Data Logger

Switching Unit, più comunemente “scanner”.

Contiene al suo interno 3 slot e un DMM (Digital MultiMeter) le cui misure hanno

risoluzione di 6 ½ cifre.

Negli slot è possibile inserire moduli, tra i quali il più utilizzato è il 34901A che conta

20 canali, utilizzato per realizzare la switching unit effettiva e poterla utilizzare

anche come modulo di acquisizione di dati.

Il condizionamento del segnale integrato permette anche a questa unità di

effettuare le misurazioni più varie.

19

3. Implementazione

Nel capitolo 3 si segue tutto il processo di ideazione e sviluppo delle varie

modifiche da apportare a MACS e alla sua struttura sottostante per passare dalla

vecchia versione 1.0 alla nuova versione 1.1 con le caratteristiche già accennate

nel sommario di questo lavoro di tesi.

Si è partiti dall’analisi e la rimodellazione della base di dati, per poi sviluppare una

leggera applicazione Desktop di archiviazione dati “statici” per poi attuare tutte le

necessarie modifiche alla struttura di MACS per la gestione della nuova base di

dati.

3.1. Base di dati

La base di dati su cui si appoggiava MACS nella sua versione 1.0 si fondava su

Microsoft Access, ed era sostanzialmente il frutto di anni e anni di aggiunte anche

a blocchi di dimensioni importanti.

Figura 10: Stato della vecchia base dati

Risultato sospettabile di queste attività continuative nel tempo è stato l’ottenimento

di una base di dati formata da buona parte di attributi o non più utilizzati o con valori

NULL per ogni row presente.

La base di dati, inoltre, non presentava una uniformità neppure per le varie

nomenclature di: database utilizzati, tabelle e svariate colonne presenti.

Il primo step di analisi quindi si è focalizzato sullo studio dell’interazione tra MACS

e la base dati Access, per capire quale fosse lo stato attuale dello scambio di

informazioni, e con quale rate. Per fare questo è stato fondamentale il supporto

dell’ing. Francesco Braguti, in qualità di “manutentore” della suddetta versione 1.0,

20

e col quale si è provveduto a categorizzare le informazioni attualmente presenti in

necessarie ed obsolete.

Si è partiti migrando tutti i contenuti dei vari database Access in un unico, grande,

uniforme database MySQL, da cui poi si è iniziata l’analisi, cercando di fare la

distinzione tra dati la cui presenza era fondamentale per il processo e quelli invece

secondari, superflui, obsoleti o addirittura di troppo.

Lo studio delle relazioni tra le varie informazioni ha permesso quindi di arrivare alla

produzione del seguente diagramma Entità-Relazione.

(E’ necessario specificare che con il termine “prova” ci si riferirà agli oggetti

sottoposti alla procedura di taratura.)

Figura 11: Diagramma E-R ottenuto dall'analisi dei dati necessari

L’entità centrale del programma è senza dubbio campagna: essa contiene

l’identificativo univoco, il nome con cui ci si riferirà ad essa e la data di inserimento

21

all’interno del DB. L’informazione, di per sé estremamente generica, viene

arricchita dalle due entità definite come campagnasetpoint e campagnaprova.

Queste due entità rappresentano rispettivamente l’informazione relativa ad un set

point e ad un oggetto in prova all’interno di una campagna. All’interno di esse infatti

si ha il campo idcampagna, contenente la chiave primaria della campagna a cui la

singola prova o il singolo set point fanno riferimento. In questo modo all’interno di

MACS si andranno a recuperare tutte le informazioni di una campagna utilizzando

semplicemente la sua chiave primaria ed interrogare il DB tramite essa.

Queste due possono essere considerate tabelle operative in quanto popolate

dall’interfaccia di MACS ed utilizzate come riferimenti durante l’esecuzione della

campagna vera e propria.

Le tabelle considerate “statiche” o, più semplicemente, di archivio sono invece:

strumento, canale, forno, anagrafica, prova e campagna. Tutte queste sono

popolabili soltanto tramite l’utilizzo dell’applicazione Desktop descritta in seguito,

fatta eccezione per la tabella campagna che può essere popolata anche tramite

l’interfaccia di MACS.

La tabella strumento contiene le informazioni principali sullo strumento di

misurazione che viene utilizzato (nel nostro caso si utilizza sempre il multimetro

HP 34401A, ma la Case Structure dei moduli “operativi” di MACS garantisce la

gestione di strumenti anche diversi), ed è in relazione alla tabella canale,

contenente il set di canali disponibili sulla switching unit a cui lo strumento è

collegato.

La tabella forno è l’altra tabella che contiene informazioni riguardo agli strumenti

utilizzati per lo svolgimento della taratura. In questa tabella infatti si inseriscono le

informazioni relative ai forni al momento disponibili.

Le tabelle prova e anagrafica, invece, contengono le informazioni sui sensori: la

prima su quelli da tarare, la seconda sui campioni utilizzati dal laboratorio per i

confronti.

In prova infatti sono salvati tutti i campi specifici del sensore in taratura, oltre

ovviamente al committente e ai dati di un eventuale precedente certificato.

22

In anagrafica invece sono sufficienti le informazioni di descrizione del sensore

campione per il laboratorio, ad esempio la grandezza misurata e la gerarchia del

campione (prima o seconda linea).

Le chiavi di queste tabelle si trovano all’interno della tabella taratura, tabella

operativa con altre informazioni riguardanti la taratura dell’oggetto in questione, il

cui popolamento è demandato a MACS al termine di una campagna. Viene

utilizzato un attributo di tipo boolean (nel caso di MySQL tradotto come

TINYINT(1)) per distinguere se l’identificativo inserito è di un oggetto esterno al

laboratorio o su uno dei campioni stessi del laboratorio, ovvero su quale oggetto è

stata fatta la taratura.

E’ presente ancora nello schema la tabella dati, contenente una stringa di dati che

poi in versioni precedenti veniva utilizzata come guida per la compilazione

automatica dei file Excel, la cui eliminazione è già stata da tempo programmata e

sulla cui sostituzione ci sarà da concentrare i futuri sviluppi.

3.2. Applicazione Desktop

Lo sviluppo di un’interfaccia per il caricamento dati si rende necessario nel

momento in cui si vuole stabilire un utilizzo il più possibile safe della nuova base di

dati, per evitare l’inserimento di dati errati tra le informazioni necessarie al corretto

flow di tutta l’applicazione, essendo ora presenti nel database solo quelli necessari.

Le caratteristiche fondamentali di un’applicazione di questo tipo sono quindi la

semplicità e l’immediatezza dell’utilizzo da parte di un utente che nella maggior

parte dei casi non è qualificato all’inserimento dei dati direttamente nel database.

Una scelta naturale è stata dunque quella di sviluppare tale applicazione

utilizzando il framework Swing nel linguaggio di programmazione Java.

La prima scelta implementativa, per rispondere al requisito di semplicità, è stata

quella di creare un’interfaccia single window, il più possibile user-friendly, che

andasse incontro anche all’immediatezza nel ritrovare i pochi pulsanti che ne

guidassero l’utilizzo.

23

Figura 12: mockup single-window studiato per l'applicazione di archivio

Conoscendo le basi fondamentali delle librerie Swing è stato quindi necessario

“tradurre” in un diagramma la suddivisione delle classi che sarebbero andate a

comporre l’applicazione.

Come si nota dal diagramma è stato scelto di implementare un “livello”

dell’applicativo che racchiudesse in sé le informazioni raccolte dal database (ogni

tabella è rappresentata dalla classe chiamata col nome della stessa), in una sorta

di sviluppo ad Entities. Per ragioni di comodità e di possibilità di personalizzazione

nei minimi dettagli la scelta è stata inoltre di non utilizzare nessun tool di supporto

e creazione automatica di tali Entities, in modo da gestire “internamente” ogni

passaggio implementativo ed averne la piena consapevolezza.

Ogni classe corrispondente a una tabella ha così al suo interno le costanti

rappresentanti la struttura del database sottostante, come il nome della tabella e i

nomi delle sue colonne.

La classe Constants è stata implementata con l’intento di standardizzare per

quanto possibile la gestione delle “stringhe di sistema”: nomi di finestre,

24

intestazioni, alerts, mappature tra valori nel database e rappresentazione visiva

per una maggior comprensione dell’utente.

Figura 13: Class Diagram dell'applicazione desktop di archivio

Un elemento cardine dell’implementazione è la scelta di associare un pannello ad

ogni classe rappresentativa di una determinata tabella del database.

La rappresentazione all’interno della finestra principale è stata così agevole, ed

anche lo scambio dei vari pannelli al momento delle interazioni con l’utente.

25

Figura 14: Finestra singola su cui si svolge tutta l'esecuzione dell'applicazione

La versione rilasciata è stata sviluppata con l’intento di lasciarla il più generica

possibile, come si può notare da certi piccoli particolari come il titolo della finestra

o dalla semplicità di scelta delle combobox.

La parte centrale è stata occupata dalla tabella che rappresenta di volta in volta il

contenuto della tabella del DB selezionata all’interno della prima combobox da

sinistra.

La seconda combobox invece permette di visualizzare solo delle “sezioni” di

archivio; ad ogni voce di questa infatti è stata associata una query SQL di SELECT

con uno o più filtri WHERE già preimpostati.

La struttura della tabella viene rimodellata ogni volta che si cambia selezione

tramite una delle due combobox. L’applicazione infatti recupera i nomi delle

colonne della corrispondente tabella e li mostra all’utente con ogni dato che viene

recuperato dalla successiva SELECT.

Si è scelto di rendere l’attività di modifica interattiva con la selezione di una

determinata riga dalla tabella. Il sistema infatti recupera i dati dalla tabella,

26

corrispondenti alla riga selezionata, e li distribuisce nei campi di testo (o data, o

radio-button) in modo che l’utente possa modificarli a piacimento.

La linea guida di applicazione safe anche in questo caso ha portato alla decisione

di apportare la modifica effettiva sul DB solo dopo la conferma tramite l’apposito

button.

Così la cancellazione di un dato è preceduta da un alert che richiede la conferma

dell’utente, presentandogli anche una vista che il sistema sta cancellando la riga

selezionata.

Figura 15: Alert che chiede la conferma della cancellazione

Per quanto riguarda l’inserimento di un nuovo dato si è deciso di far comparire un

pannello, nella parte centrale della finestra, uguale in tutto e per tutto a quello di

modifica, con l’unica differenza che i campi si presentano vuoti, pronti ad essere

inseriti, anche in questo caso, successivamente alla conferma tramite apposito

button.

3.3. MACS

L’applicativo MACS, come già spiegato in precedenza, comunicava con le basi di

dati Access tramite i vari ODBC necessari e gestiva tutta la campagna di taratura

fino alla compilazione automatica dei log su fogli Excel.

27

3.3.1. Struttura

Il modulo principale di MACS viene chiamato MACS Linea 01, eredità di una

vecchia struttura di MACS in cui era suddiviso in due linee di taratura identiche, la

01 e la 02.

Per la nuova versione questo split non era più necessario, perciò le nuove

implementazioni sono state apportate soltanto sul .vi principale della linea 01.

L’interfaccia principale del programma è suddivisa in tabs, tra le quali poi si

seleziona quella desiderata in base al tipo di informazioni da inserire e in base alle

azioni da impostare.

La struttura precedente le modifiche era piuttosto macchinosa nella comprensione

e nel flow di utilizzo, inoltre era sviluppata su passate versioni di LabVIEW, con

controlli quindi anche visivamente obsoleti.

Il .vi principale si prende in carico la gestione delle macro-funzionalità del

programma, come le azioni di start-up (reset dell’hardware, apertura della

connessione col DB, apertura file di log) e di closing (corretto rilascio delle risorse

hardware, chiusura appropriata della connessione al DB, chiusura dei log e della

sessione del Run-time Engine a cui è appartenuto).

I modelli su cui si basa l’intera implementazione sono la macchina a stati e il ciclo

produttore/consumatore.

Una macchina a stati viene riprodotta, in LabVIEW, utilizzando propriamente While

Loops e Case Structures.

Figura 16: State machine riprodotta in LabVIEW (da www.ni.com)

28

Un ciclo While in LabVIEW è un ciclo di default non temporizzato che esegue fino

a quando la condizione in ingresso all’input boolean STOP non assume valore

TRUE. In un ciclo While si può inserire un cosiddetto Shift Register, ovvero una

“memoria” per un particolare dato attraverso i vari cicli.

Una Case Structure è un blocco che permette di cambiare il flow di esecuzione in

base a un valore in input al Case Selector della struttura.

Definendo dunque una serie di stati in cui una macchina si può trovare, ed

inserendo questi stati in un ciclo in grado di tenere traccia e, ove necessario,

modificare uno stato, si viene così a creare una macchina a stati, la cui complessità

è unicamente determinata dal numero degli stati che si vogliono implementare: la

struttura infatti è standard e indipendente dal numero degli stati.

Il ciclo produttore/consumatore è un altro tipico design pattern utilizzato in

LabVIEW per applicazioni di grandi dimensioni.

Questo tipo di implementazione permette di controllare facilmente più processi allo

stesso tempo, e ciò che rende questo metodo valido è la presenza della

comunicazione bufferizzata, garantita dall’utilizzo delle code (Queue).

Figura 17: Implementazione del ciclo producer/consumer in LabVIEW (da www.ni.com)

29

La coda infatti permette di avere i due cicli relativi ai due “attori” (producer e

consumer) che eseguono in parallelo e comunicano tra loro, così che il producer

sia in grado di produrre i token che poi il consumer consumerà.

Il limite della Queue è il fatto che sia vincolata ad un solo tipo di dato. Per gestire

diversi tipi di dato all’interno del nostro ciclo producer/consumer si dà in ingresso

alla Queue un tipo di dato composito, che contenga tutte le informazioni necessarie

alla corretta esecuzione del programma, specificato all’interno di speciali controlli

(.ctl) denominati Type Def., su cui si basa l’intero processo dell’applicazione.

I Type Def vengono definiti proprio per ovviare a questo problema di unicità del tipo

dato gestibile dalla coda, oltre ad essere utilizzati per raggruppare correttamente

le informazioni ricavate dalle ripetute interrogazioni del database.

Altro importante elemento nel pattern producer/consumer è l’Event Structure

all’interno del ciclo producer, la quale permette una sincronizzazione dei due cicli

e garantisce che l’ordine di esecuzione non porti mai in stati d’errore, se non

volutamente.

3.3.2. Novità

L’interfaccia principale è stata modificata con i controlli della nuova versione di

LabVIEW utilizzata (2014) e si presenta ora sotto una nuova veste.

La tab Anagrafica gestisce l’input dei nuovi dati di campagna.

La tab Lancio Campagne permette la gestione delle campagne mentre il Sinottico

e Campagne in Taratura (ancora in via di sviluppo) permettono la visualizzazione

degli stati delle varie campagne.

Certificazione Forni è una vecchia eredità che per il momento è stato deciso di

tenere, anche se inutilizzata.

SETUP infine fornisce un comodo tool di verifica strumenti e misura manuale.

30

Figura 18: La nuova pagina principale di MACS

Figura 19: Come appare oggi la finestra del tab SETUP

Sono state poi effettuate diverse modifiche al livello logico del sistema.

Una prima, evidente, scomodità che era richiesto eliminare era la presenza di 10

.vi identici per la gestione della parte operativa delle campagne.

Era necessario infatti adottare una nuova strategia d’implementazione che

permettesse di modificare una volta soltanto questa parte di applicativo per ogni

istanza.

Un primo improvement apportato è stato quindi quello di sostituire le istanze dei .vi

responsabili della parte attiva delle campagne con una singola istanza ripetuta di

un .vi template.

31

Un .vit, appunto .vi template, è un particolare tipo di .vi che concede allo

sviluppatore di poter avere attive più istanze contemporaneamente, e allo stesso

modo non dover ripetere la struttura uguale su più .vi nel momento in cui vuole che

il programma compia la stessa azione.

Figura 20: Un .vit nel tree della project-window (destra) e la sua rappresentazione nel Block Diagram (sinistra)

E’ stato quindi scelto di utilizzare un .vit per avere, come prima, un numero fisso di

campagne (10 nel nostro caso), ma avere un unico .vit da modificare invece che

dover moltiplicare una singola modifica sui 10 .vi che prima gestivano una

campagna ciascuno, singolarmente.

Altra modifica necessaria era l’aggiunta della comunicazione con i nuovi strumenti

di misurazione utilizzati.

In sostanza, come già accennato nel capitolo 2, gli strumenti hardware introdotti

nella catena sono accompagnati da parti di software, chiamate drivers, con cui si

deve guidare l’utilizzo automatico da parte del software MACS. Era necessario

perciò definire in che modo introdurre i nuovi moduli per la corretta comunicazione

delle misure rilevate.

Figura 21: Schematizzazione di un driver

I nuovi strumenti infatti sono stati utilizzati per la presenza in laboratorio, e a

differenza della comunicazione fisica tra strumento e PC, gestita interamente dai

connettori, la comunicazione logica del dato doveva invece essere controllata nella

maniera corretta attraverso i .vi di driver forniti, pena un completo disallineamento

tra MACS che si aspetta dei dati in input e lo strumento che li comunica sul

32

connettore ma il driver non lo riceve nella maniera corretta e/o non lo mette a

disposizione.

Figura 22: La cartella instr.lib, presente nel path di installazione di LabVIEW, contenente tutti i driver utilizzabili, sono riquadrati quelli inseriti per le recenti implementazioni

Una volta scritti correttamente i blocchi di comunicazione è stato necessario

inserirli all’interno di MACS nella maniera corretta. Si è deciso di aggiungerli ai vari

Case Structure che gestivano già i vecchi strumenti, piuttosto che sostituirli, per

aumentare le potenzialità del sistema, semplicemente controllando che il dataflow

andasse a selezionare sempre il caso giusto ogni volta che era necessario

utilizzare lo strumento collegato.

Sempre relativamente agli strumenti è stata cambiata la gestione dei canali della

switching unit che, nella precedente versione, non era compatibile con gli strumenti

utilizzati e quindi, come già spiegato per la base di dati, si è scelto di salvare i canali

nel DB e trattarli separatamente all’interno dell’applicazione. In sostanza secondo

la nuova logica i canali vengono recuperati in base allo strumento attualmente

utilizzato, così da avere anche la formattazione giusta da utilizzare nel momento

in cui si mandano i canali necessari in input alla switching unit (o meglio, al driver

che la controlla).

Parallelamente a questo anche la gestione generale degli strumenti è stata, per

quanto possibile, alleggerita e semplificata.

33

Sono stati eliminati alcuni blocchi che erano stati inseriti ma mai completati. Sono

stati raggruppati alcuni blocchi che svolgevano funzioni equivalenti in un unico

blocco la cui funzione cambiava con alcuni input aggiuntivi, ad esempio: le

comunicazioni con il DB prima erano svolte da un blocco diverso per volta, invece

ora sono state raggruppate per funzionalità. Inoltre, sono stati aggiunti alcuni

blocchi semplicemente per evitare di ripetere le stesse azioni e gli stessi

collegamenti in diverse zone del software.

Figura 23: Il modulo OpenTabCampagna.vi, utilizzato per recuperare le campagne dal database

Per quanto riguarda le singole tab, sono stati mantenuti solamente i campi

necessari ed inseriti nella base di dati, mentre sono stati tolti quelli inutilizzati, oltre

ad essere stata modificata la vista in generale dei tre tab relativi alle campagne.

Chiaramente la sostituzione della base di dati ha portato con sé notevoli

cambiamenti nella gestione della comunicazione MACS-DB.

La connessione al DB viene aperta all’esecuzione delle fasi preliminari di MACS,

e viene effettuata tramite un DSN.

Un DSN, acronimo di Data Source Name, è la risorsa (un nome simbolico)

utilizzata dalle applicazioni per rappresentare la connessione ODBC (Open

DataBase Connectivity), il driver che utilizza un API standard per connettere un

client a un DBMS.

34

Figura 24: Finestra dell'ODBC admin in cui si notano i vecchi ODBC per Access e quello nuovo per MySQL

E’ necessario utilizzare il connettore adatto per il database utilizzato, nel nostro

caso il connettore ODBC per MySQL, ed impostare la risorsa correttamente. Se

infatti si imposta la risorsa DSN nel modo corretto, sarà il modulo LabVIEW

“OpenConnection.vi” del Database Connectivity Toolkit ad amministrare la

connessione ricevendo in ingresso semplicemente una stringa col nome del DSN

e creando per l’output un riferimento. Questo riferimento sarà da passare per tutta

l’esecuzione del programma, fino alla chiusura della connessione, effettuata

tramite il modulo “CloseConnection.vi”.

Figura 25: Come viene aperta la connessione al DB in MACS 1.1: si nota la connection reference in uscita che verrà passata per tutto il flow di esecuzione

In questo modo è stata gestita la comunicazione col DB, grazie all’utilizzo dei soli

moduli appartenenti al Database Connectivity Toolkit, garantendo la compatibilità

degli ingressi e delle uscite per tutta l’esecuzione.

Dato il cambiamento della base di dati era necessario anche riqualificare tutti i Type

Def., array e cluster che gestivano la comunicazione dei dati all’interno di MACS

una volta recuperati dai DB.

35

In tutto il flow di esecuzione dunque si è andati a modificare i riferimenti ai singoli

dati in modo che le operazioni successive sul DB (insert, update e delete)

potessero comunque avvenire nella maniera corretta. Ogni cluster, ogni array e

non ultimo ogni Type Def. è stato riformulato per seguire il nuovo modello dei dati,

eliminando così ogni possibile incongruenza.

La modifica del trattamento dei dati all’interno di MACS ha portato alla sostituzione

completa di tutti i moduli responsabili della scrittura dei dati da MACS verso il DB.

I blocchi di insert sono stati uniformati e sono stati aggiunti al flow di esecuzione

utilizzando lo stesso modulo LabVIEW e portando all’ingresso del modulo “Insert

Data.vi” le stesse tipologie di dati, ovvero: il riferimento alla connessione al DB, il

cluster di dati tradotto in Variant, la tabella e le colonne a cui i dati avrebbero fatto

riferimento.

Figura 26: Esempio di gestione dell'inserimento. Il Context Help di LabVIEW attivo elenca gli input e gli output

Allo stesso modo si è cercato di uniformare anche l’utilizzo dei blocchi di update e

di delete, nelle rispettive Case Structure dei cicli consumer a cui si riferivano

(campagna, campagnaprova e campagnasetpoint).

36

Figura 27: Nuva gestione della funzione di Update

Figura 28: Nuova gestione della funzione di Delete

All’interno del processo si è creata la necessità di memorizzare nel DB la chiave di

una tabella referenziata, mentre a video, come naturale necessità, si voleva

visualizzare il valore di uno o più altri campi (ad esempio per popolare le combobox

di scelta nelle varie tab).

Sono stati implementati semplici moduli di comunicazione che effettuassero

l’accoppiamento chiave-nome e viceversa ogni volta che servisse.

Nell’immagine successiva si può notare come si è cercato di usare un blocco

standard per diversi utilizzi, cercando di mantenere input generali, in modo da

garantire il riutilizzo del codice il più possibile.

37

Figura 29: Il modulo getKeyFromAttribute.vi, implementato per il mantenimento dell'integrità referenziale

38

4. Conclusioni e sviluppi futuri

Senza ombra di dubbio è stato un lavoro stimolante, che permette anche di

immergersi in un ambito estremamente cross-disciplinare, che cerca di combinare

le diverse conoscenze per ottenere un risultato omogeneo e funzionante.

4.1. Conclusioni

La nuova base di dati, dato il metodo con cui è stata sviluppata, usando un

approccio totalmente diverso rispetto al passato, deve essere un punto di partenza

da cui intraprendere o, meglio, continuare l’aggiornamento dell’applicativo MACS.

La natura di MACS per cui si utilizza un unico strumento per effettuare le

misurazioni non è cambiata, così come la parte di reportistica collegata ai log sui

file Excel, poiché il principio alla base della generazione di un certificato di taratura

non è cambiato.

Ciò che è stato totalmente rivisto è stato il livello “intermedio” ossia la raccolta e la

memorizzazione dei dati in nuove strutture, così come il loro trattamento all’interno

dell’intero flow dell’applicativo.

LabVIEW, per un corretto funzionamento degli applicativi, necessita di una grande

coerenza dei dati che vanno a comporre il principio fondamentale alla base

dell’esecuzione, ossia il dataflow. Per questo sono stati necessari moltissimi test

delle singole unità, sia di quelle già implementate, con le nuove strutture dati in

ingresso, che di quelle di nuova introduzione, e ovviamente i test di corretta

integrazione tra le nuove parti introdotte e quelle che erano già presenti.

La composizione di MACS è al 100% in LabVIEW, perciò è chiaro che ogni

passaggio che è stato effettuato durante questo lavoro di tesi è stato

indissolubilmente legato alle conseguenze che esso avrebbe portato al

funzionamento del core in LabVIEW.

Un fondamento di questo lavoro è stato infatti cercare di apportare modifiche senza

dimenticare che la versione 1.0 aveva un suo funzionamento corretto, quindi ogni

dato generato per i test della base di dati è stato riportato migrando correttamente

le porzioni dei vecchi dati che erano già presenti nella struttura Access.

39

4.2. Sviluppi futuri

Data l’enormità della struttura di MACS è stato possibile completare gran parte

delle modifiche previste per il corretto funzionamento della campagna di taratura.

Tuttavia l’analisi degli aggiornamenti non si può né deve essere considerata

conclusa. Ogni strumento introdotto nella catena di azioni che vanno a comporre

la campagna ha bisogno infatti del corretto interfacciamento attraverso i vari moduli

di MACS che costituiscono la parte integrante di driver tra software e hardware.

Ogni introduzione all’interno della base di dati in base alle esigenze dei futuri

utilizzatori sarà personale e poco dispendiosa in termini di analisi, proprio perché

la natura della nuova base di dati è stata quella della presenza di tutti i dati

necessari e la quasi totale assenza di dati accessori.

E’ perciò evidente che un qualsiasi dato di cui si sentirà l’esigenza difficilmente

sarà una parte importante del processo, a meno che non cambi la natura del

processo stesso di campagna di taratura o cambino le regole alla base della

produzione del certificato di taratura.

La personalizzazione della base di dati sarà perciò molto più improntata

all’arricchimento dell’informazione stessa, e allo stato in cui si trovano la base di

dati e l’applicativo di gestione sarà semplice riuscire ad aggiungere le varie

necessità.

Importante questione rimasta in sospeso è la destrutturazione della tabella dati e

della nuova gestione della stringa da parsare contenente coefficienti e riferimenti

utilizzati per la compilazione del foglio Excel.

Tutto il lavoro è stato documentato attraverso lo scritto in questione, e si

raccomanda pertanto una lettura approfondita della parte di riferimento, nel caso

in cui si voglia mettere mano a codici o strutture.

I codici dell’applicazione Desktop nonché l’applicativo MACS sono stati

ampiamente commentati proprio per guidare i futuri gestori e manutentori nel

corretto approccio ai sistemi.

40

Le prossime implementazioni dovranno riguardare la gestione dei controller dei

forni, nonché i check sugli strumenti nel caso vengano cambiati, sostituiti o

modificati.

Future installazioni dei pacchetti allo stato attuale sono supportate dai manuali di

utilizzo dei vari tool, nonché dalle varie documentazioni fornite.

Per l’esecuzione di MACS 1.1 è sufficiente l’installazione sulla postazione del

LabVIEW Run-Time Engine.

La base di dati è basata sulla versione MySQL 5.6, ma anche versioni precedenti

sono compatibili. Viene fornito un dump con dati di prova fittizi per l’iniziale

popolamento della base dati.

L’esecuzione dell’applicazione desktop è possibile se si ha installato una versione

del Java Runtime Environment pari o superiore alla 1.7. La cartella di distribuzione

viene fornita con le librerie necessarie all’esecuzione e ad un README file che

sintetizza i passaggi necessari per il corretto utilizzo.

41

5. Bibliografia

VIM – Vocabolario Internazionale di Metrologia

T. Ricolfi, Metrologia della Temperatura, I.N.RI.M. (IMGC-CNR)

Guide to the expression of Uncertainty in Measurement, Geneva: ISO, 1993.

Nuova edizione corretta nel 1995. (Trad. it.: UNI CEI ENV 13005:2000. Guida

all'espressione dell'incertezza di misura. Milano: Ente Nazionale Italiano di

Unificazione, 2000)

[Online] http://www.keysight.com/en/

[Online] http://cp.literature.agilent.com/

[Online] http://dev.mysql.com/doc/refman/5.6/en/

[Online] https://www.oracle.com/java/index.html

[Online] http://www.labviewing.com/

[Online] http://www.ni.com/

[Online] http://www.javaworld.com/

[Online] http://www.vogella.com/

[Online] http://stackoverflow.com/