(attenzione: il file é unico, di 900 K, pari a circa 400 pagine - da leggersi solo in  progressione)
_____________________________________________________________________________
REALIZZAZIONE DI UN TRADUTTORE
SCPI nnnn
PER LA COMUNICAZIONE DI STRUMENTI IN RETE
TESI  OTTOBRE 1998
UNIVERSITA’ DEGLI STUDI DI PADOVA - FACOLTA’ DI INGEGNERIA - DIPARTIMENTO DI ELETTRONICA E INFORMATICA

Capitolo 1
IL PROGETTO VIRLAB
(VIrtual Remote LABoratory)

1.1 COS’ E’ IL PROGETTO "VIRLAB"

Capitolo 2
INFORMAZIONI SCAMBIATE
2.1 REQUISITI DELLE INFORMAZIONI SCAMBIATE
2.2 VIRTUALIZZAZIONE DEL BANCO
2.3 STRUTTURA LOGICA DELLE INFORMAZIONI
2.4 IMPLEMENTAZIONE NEL CASO DI COMUNICAZIONE DIRETTA
2.5 IMPLEMENTAZIONE NEL CASO DI COMUNICAZIONE VIA HTTP
2.6 REALIZZAZIONE DELLA CLASSE VirlabCmd
2.7 LISTA DEI COMANDI IMPLEMENTATI E CODICI CORRISPONDENTI

Capitolo 3
IL LINGUAGGIO SCPI
3.1 INTRODUZIONE
3.2 ORGANIZZAZIONE DEL LINGUAGGIO SCPI
3.3 DESCRIZIONE DI ALCUNI SOTTALBERI
3.4 SINTASSI E STILE DEI COMANDI SCPI
3.5 NOTAZIONI DELLO STANDARD SCPI
3.6 I PARAMETRI

Capitolo 4
PROGETTO "TRADUTTORE"
4.1 INTRODUZIONE
4.2 OBBIETTIVI DEL PROGETTO "TRADUTTORE"
4.3 TABELLE DI TRADUZIONE DEGLI STRUMENTI
4.4 OPERAZIONI ESEGUITE DAL CODICE "TRADUTTORE"
4.5 STRUTTURA DEL "TRADUTTORE"
4.6 SIMULATORE DI TRADUZIONE
4.7 IL PROGETTO ProTrans17

Capitolo 5
MANUALI SCPI DEGLI STRUMENTI
5.1 INTRODUZIONE
5.2 STRUMENTO: OSCILLOSCOPIO HP54615B.
5.3 STRUMENTO: MULTIMETRO HP3478A
5.4 STRUMENTO: ANALIZZATORE DI SPETTRO HP35660A
CONCLUSIONI
BIBIOGRAFIA

SISTEMA DI MISURAZIONE AUTOMATICO.

Un sistema automatico di misura può essere schematizzato in

Ogni strumento deve essere dotato di una struttura aggiuntiva per trasmettere i valori misurati e per ricevere dall' elaboratore centrale comandi per una predisposizione iniziale o per un adeguamento della sua configurazione a causa di variazioni delle grandezze da misurare. A tal fine ogni strumento avrà una adeguata struttura elettronica composta sia da una parte hardware che da una parte software. Le istruzioni ricevute in tale sistema saranno riconosciute tra il set di istruzioni implementate e decodificate in modo da agire su un particolare blocco funzionale del dispositivo. Gli strumenti da inserire in un sistema di misura automatico possono non presentare il pannello frontale dei comandi in quanto tutte le funzioni ottenibili dallo strumento vengono messe a disposizione con modalità completamente diverse. Ogni strumento può essere considerato una interfaccia intelligente che acquisisce e condiziona dei segnali di ingresso, estrae da essi delle informazioni, li elabora e li trasmette ad un host computer dove confluiscono i dati forniti dagli altri strumenti presenti nel sistema di misura.

L' elaboratore centrale effettuerà una elaborazione globale dei dati ricevuti e considerando alcuni parametri sarà in grado di intervenire sui dispositivi.

Per la scelta delle caratteristiche del canale di comunicazione possono essere adottati vari criteri. Si può ottimizzare qualche parametro come la velocità di trasmissione, la semplicità costruttiva o di impiego del canale trasmissivo. Un simile modo di procedere porta sicuramente ad una notevole efficienza del collegamento in un ben definito contesto operativo, ma presenta anche vari inconvenienti. Richiede difatti una notevole impegno sia nella progettazione e nella messa a punto dei vari trasmettitori e ricevitori necessari per la comunicazione, sia per la predisposizione del software di gestione dell' intera attività di trasferimento delle informazioni. In un diverso contesto operativo dove viene richiesto l' ottimizzazione di qualche altro parametro un sistema così realizzato è difficilmente riutilizzabile. Una alternativa a questo modo di procedere è di accettare invece una ottimizzazione più globale, adottando ad esempio, dei tipi di canali di trasmissione già utilizzati per il collegamento con altre periferiche. Sono stati realizzati sistemi costituiti da strumenti in grado di comunicare adottando una trasmissione seriale asincrona secondo il protocollo RS-232. La trasmissione seriale asincrona è una modalità di trasmissione molto utilizzata nel collegamento fra unità centrale e periferiche. Essa richiede una struttura del trasmettitore e del ricevitore molto semplice, mentre il canale di trasmissione si può ridurre a soli tre conduttori: due per la trasmissione dei segnali e uno per il riferimento dei potenziali. Questo canale di trasmissione è adatto per le normali periferiche ma non considera le specifiche esigenze degli strumenti di misura, i quali prevedono la trasmissione di particolari tipi di informazioni. Di conseguenza alcune prestazioni sono accettabili, mentre altre, anche se usuali per uno strumento sono insoddisfacenti e comportano, ad esempio, una riduzione della velocità effettiva di trasmissione delle informazioni.

Per superare queste difficoltà sono stati proposti vari tipi di canali di trasmissione per la gestione degli strumenti di misura. Parecchie sono le caratteristiche che deve presentare uno standard di comunicazione. Fra queste, quelle di maggior interesse sono: la distanza dei collegamenti, il numero di dispositivi collegabili e la velocità di trasferimento delle informazioni. La Hewlett-Packard ha messo a punto un protocollo chiamato HP-Interface Bus, HP-IB, che è stato adottato dall' organizzazione internazionale IEEE con la sigla IEEE-488. Esso si caratterizza per i seguenti parametri generali: la struttura generale del sistema di misura è a bus, in tal modo è possibile la trasmissione in parallelo di più bit contemporaneamente ed è semplice apportare variazioni del numero di componenti collegabili al sistema. Il bus viene realizzato tramite linee raggruppate fra loro in un cavo (party-line bus). La velocità di trasmissione massima teorica è pari a 1Mbytes/s. Il numero massimo di elementi collegabili è 15 e la lunghezza del bus dipende dal numero di elementi collegati ed è inferiore ai 20 m.

Per lo standar 488 si può utilizzare nel sistema una configurazione lineare.(fig. 2 )

Dei cavi della lunghezza tipica di un paio di metri con opportuni connettori alle due estremità consentono di collegare fra loro in sequenza i vari strumenti. Con un ulteriore cavo si collegano questi con l' elaboratore. I connettori originali 488 presentano 24 terminazioni o pin.

Da un punto di vista logico il bus 488 può essere suddiviso in data bus e control bus.

Il data bus è costituito da otto linee che consentono la trasmissione in parallelo di dati codificati su otto bit. La trasmissione è asincrona, ogni dato richiede una procedura di partenza per la sua trasmissione, ultimata la quale si ha una procedura di fine trasmissione. Vi sono poi altre otto linee per il controllo, una linea per il potenziale di riferimento dei vari segnali, una linea di sicurezza per il collegamento a terra degli involucri degli strumenti, le restanti sei linee svolgono una parziale funzione di schermo per ridurre l' influenza dei rumori. Lo standard 488 ha stabilito delle regole che devono essere seguite per trasferire una informazione tramite il bus, definendo la struttura meccanica del bus e le caratteristiche elettriche statiche e dinamiche dei segnali che partecipano al trasferimento.

Le informazioni che vengono trasmesse ad esempio fra due componenti del sistema possono essere suddivise in quattro livelli (fig. 3). Al livello inferiore (layer A ) sono definite le varie caratteristiche meccaniche ed elettriche. Il successivo ampliamento apportato allo standard, denominato IEEE 488.2 riguarda i due livelli sovrastanti che impongono le regole da seguire per lo scambio di messaggi, ad esempio, le varie unita’ di misura, il formato da utilizzare per rappresentare un valore numerico, se in virgola fissa oppure in virgola mobile. Al livello superiore (layer C) lo standard IEEE 488.2 definisce come devono essere formulati i vari comandi o richieste di tipo generale, vale a dire normalmente presenti nei vari strumenti. Ad esempio, viene stabilito come ogni dispositivo deve organizzare il suo byte di stato in modo che l' host computer possa utilizzare una unica routine per la sua decodifica, avendo imposto il significato di ciascun bit del registro di stato. Ad un livello ancora superiore (layer D) si possono definire le regole per la formulazione dei vari messaggi da scambiarsi fra i componenti del sistema. Questi messaggi sono molto influenzati dalle caratteristiche specifiche degli strumenti collegati.

Le regole di comunicazione stabilite in tale livello non sono definite dal protocollo IEEE 488.2 ma nè costituiscono una estensione, le cui convenzioni attualmente sono rispettate solamente da alcuni costruttori di strumenti. Si prevede, nel futuro immediato, una maggiore diffusione di queste convenzioni per la comunicazione tra strumenti. L' insieme di messaggi scambiabili prende il nome di linguaggio SCPI (Standard Comand for Programmable Instrument). e sarà l' argomento dei prossimi capitoli.

Capitolo 1

IL PROGETTO VIRLAB

1.1 COS’ E’ IL PROGETTO "VIRLAB"

Il progetto "ViRLab" (VIrtual Remote LABoratory) è nato dall’esigenza di trasformare alcuni laboratori, tra cui quelli di misure elettroniche del Dipartimento di Elettronica e Informatica dell’Università di Padova e il corrispondente del Politecnico di Torino, in laboratori utilizzabili anche attraverso elaboratori elettronici situati in sedi distaccate dai Dipartimenti stessi.

E’ interessante osservare che un numero crescente di aziende sta scoprendo i vantaggi offerti dalle soluzioni associate all’uso di strumentazione virtuale le quali permettono, a differenza degli strumenti tradizionali, una maggiore flessibilità e riutilizzabilità. In questo modo lo sviluppo di strumentazione virtuale consente ad un’azienda oltre che un aumento della propria professionalità una diminuzione di costi sia dell’acquisto degli strumenti, sia di sviluppo e di manutenzione.

L’obbiettivo finale del progetto "ViRLab" è quello di realizzare un software che permetta l’utilizzo di strumenti quali oscilloscopi, multimetri, analizzatori di spettro ecc., mediante un elaboratore posto fisicamente a distanza dalla localizzazione stessa degli strumenti attraverso una rete basata, come Internet, sul protocollo TCP/IP. L’utente finale utilizzerà degli strumenti "virtuali" realizzati attraverso apposite interfacce grafiche in modo del tutto simile agli strumenti reali con il vantaggio di poter rielaborare i risultati ottenuti con lo stesso elaboratore con cui effettua le misure. La possibilità di scegliere la modalità di rielaborazione dei dati è uno degli aspetti fondamentali nella distinzione tra strumento reale e virtuale: uno strumento reale ha caratteristiche e prestazioni ben definite dal costruttore e l’utente non può modificarle, invece attraverso la flessibilità del software quest’ultimo può decidere le funzionalità del sistema di misura e la modalità di rappresentazione dei dati per migliorare l’analisi.

La remotizzazione, inoltre, permette di migliorare l’utilizzo delle risorse se si dà la possibilità a più utenti di usare contemporaneamente uno stesso strumento o meglio se si realizza una struttura capace, assegnando alternativamente l’uso di uno strumento a più utenti, di effettuare una condivisione.

Un altro aspetto importante su cui si basa l’intero progetto è quello della separazione "utente-strumento". Se un utente ha bisogno, ad esempio, di utilizzare un oscilloscopio non deve preoccuparsi di come accedere ad esso ma deve supporre che il proprio PC sia lo strumento. Egli non deve conoscere l’indirizzo della macchina che ha fisicamente collegato un oscilloscopio ma semplicemente che vuole usare un oscilloscopio; di più, se un utente ha bisogno di utilizzare un banco di misura con determinati strumenti sarà compito del software trovare il primo banco libero con gli strumenti richiesti in un insieme pre-assegnato.

Architettura del laboratorio remoto

Nel progetto "ViRLab", si può far riferimento ad un sistema composto da uno o più computer sui quali sono in esecuzione degli applicativi software, che rappresentano gli strumenti "virtuali", da una struttura di rete basata sul protocollo TCP/IP, attraverso cui le informazioni devono essere trasmesse, e da un insieme di computer a cui gli strumenti di misura sono fisicamente collegati con diverse modalità, ad esempio mediante un bus 488 o un collegamento seriale.

Architettura client/server

La situazione più semplice è quella in cui la remotizzazione di un banco di misura avviene mediante due computer direttamente collegati in rete: il primo viene utilizzato dall’utente attraverso un programma applicativo e il secondo, invece, gestisce gli strumenti ad esso collegati. Con questa configurazione il paradigma di comunicazione tra i due computer può essere il classico client/server in cui nell’elaboratore dell’utente è presente un processo client che effettua una richiesta di misura direttamente al processo server in esecuzione sul computer gestore degli strumenti; successivamente il processo server, dopo aver eseguito la misura sullo strumento, spedirà al client i risultati.

In realtà esistono varie situazioni di rete attraverso cui la remotizzazione deve avvenire, in particolare non si ha in genere un collegamento diretto tra i due computer ma esistono diversi intermediari tra loro. Infatti, l’utente che necessità di utilizzare gli strumenti in modo remoto non si trova nello stesso luogo dove fisicamente gli strumenti sono situati ma, ad esempio, in un altro laboratorio o nella propria abitazione. Il laboratorio stesso, inoltre, deve essere pensato come un insieme di elaboratori collegati tra loro, per poter collaborare nella soddisfazione di una richiesta, ed ulteriormente collegati ad Internet attraverso strutture quali firewall e proxy-server (Figura 1.1).

Infine, anche l’insieme dei computer client può essere pensato come una rete locale collegata ad Internet mediante proxy-server e firewall. Infatti, attualmente questa architettura rispecchia gran parte delle reti aziendali collegate ad Internet e alla struttura di un ISP (Internet Service Provider).

L’utente utilizza gli applicativi forniti come se essi fossero degli strumenti reali. La modalità di impiego deve essere la stessa sia se gli strumenti sono fisicamente collegati alla macchina dell’utente, sia se si trovano collegati ad un altro computer remoto, sia si tratti di moduli di simulazione. In altri termini, l’utente non deve preoccuparsi di come sono distribuiti fisicamente gli strumenti, ma deve piuttosto pensare che gli strumenti siano gli applicativi.

Il processo client deve quindi limitarsi a fornire una adeguata ed intuitiva interfaccia grafica con la possibilità di:

rielaborazione dei dati provenienti dagli strumenti;
eventuale ritrasmissione in "run-time" di comandi da inviare agli strumenti;
visualizzazione degli stessi con diverse modalità;
memorizzazione dei dati su memoria di massa per un successivo riutilizzo.

Il processo server, invece, non è necessario fornisca un’interfaccia grafica mentre le informazioni sul suo stato devono poter essere ottenute nello stesso modo in cui si inviano i comandi da eseguire su uno strumento. In pratica l’unico modo per poter comunicare con il processo server è attraverso un canale TCP/IP. Tra le caratteristiche principali che il programma server deve possedere si ricordano le seguenti:

* gestione contemporanea in "time-sharing" di più client;
* accesso alla strumentazione, con possibilità di definire delle "macro" o offrire funzioni di simulazione;
* gestione di uno o più insiemi di dispositivi fisici (banchi), tra loro variamente connessi, e/o di moduli di simulazione
* collaborazione con altri server nell’esecuzione dei comandi sulla strumentazione per migliorare lo sfruttamento delle risorse disponibili.

L’interazione tra il processo client e quello server può essere pensata come un ciclo comprendente i seguenti passi:

* il client invia al server un comando, la modalità di trasmissione deve supportare l’attuale evoluzione delle strutture di rete;
* il server riceve il comando, lo interpreta ed esegue la relativa richiesta;
* il server spedisce al client i risultati relativi al comando eseguito;
* il client riceve i dati, li elabora e eventualmente li visualizza in modo adeguato.

L’unicità nella gestione degli strumenti e dei moduli di simulazione, sia in locale che in remoto, implica la presenza di un programma server su ogni macchina dell’intero sistema cioè su ogni macchina degli utenti e su ogni macchina che gestisce fisicamente gli strumenti. I CA, in genere, scambiano informazioni solo con il server locale e la trasmissione via rete avviene tra server.

Questa impostazione comporta l’introduzione di una nomenclatura che distingua il comportamento principale del programma server: esso verrà chiamato "client server" se il suo unico compito è quello di ricevere le richieste localmente dagli applicativi client senza eseguire misure sugli strumenti, verrà invece chiamato "bench server" se il suo unico compito è quello di eseguire le misure impiegando la strumentazione. E’ chiaro che il programma server deve poter funzionare contemporaneamente sia come "client server", sia come "bench server", qualora tali modi vengono contemporaneamente assolti si impiegherà il nome "virlab server". Inoltre nel seguito si indicherà con il nome "client application" (CA) un generico applicativo client che dialoga sia con l’utente per mezzo di opportuna interfaccia grafica, sia con "virlab server".

Gli aspetti fondamentali che riguardano, invece, la trasmissione dei dati sono la specificazione di un "comando remoto" e la modalità di trasmissione di tali comandi via rete. Per la definizione della struttura di tali comandi si deve effettuare uno studio sulle possibili informazioni che essi devono contenere, invece, per la loro rappresentazione si devono tenere presenti i vincoli imposti dalle modalità di trasmissione adottate.

Un comando rappresenta la richiesta che un client effettua al server e quindi al suo interno devono essere presenti tutte le informazioni per la specificazione del banco di misura, dello strumento e dell’operazione da eseguire sullo strumento. All’interno del progetto, però, un comando assume un concetto più ampio: esso rappresenta l’unità base per lo scambio delle informazioni sia tra i server che tra server e client.

Con questo si intende che un comando al suo interno non contiene soltanto un indicazione della operazione che deve essere eseguita sulla strumentazione ma anche altre richieste di servizio o informazioni tra cui i risultati stessi della misura, informazioni sullo stato del server e situazioni di errore.

Attraverso questa unicità modalità di gestione delle informazioni si riesce ad ottenere una struttura software molto semplice e flessibile come verrà evidenziato nel paragrafo relativo all’architettura dei moduli software.

Le informazioni contenute in un comando, quindi, sono molteplici ed è necessario creare una classificazione e suddivisione dei possibili valori che i vari campi possono assumere. In particolare questa classificazione deve basarsi su una struttura ben definita che possa identificare in modo univoco un così detto "comando di alto livello" cioè un comando che il server deve interpretare.

In definitiva la struttura interna di un comando rappresenta il linguaggio con cui si può dialogare con un server cioè il linguaggio attraverso il quale può essere fatta una richiesta e il linguaggio con cui le risposte ci vengono spedite.

Il capitolo relativo alla "Rappresentazione delle informazioni" delinea in modo dettagliato la struttura di un comando e specifica i vari formati con cui può essere rappresentato.

Architettura dei moduli software

L’insieme dei moduli software realizzati all’interno del progetto "ViRLab" può essere suddiviso in:

* Uno o più applicativi client che rappresentano gli strumenti virtuali a disposizione
dell’utente;
* Un programma server che gestisce le richieste dei client ed esegue fisicamente le misure sulla strumentazione.

Un applicativo client (CA=Client Application) ha le seguenti caratteristiche:

* È in esecuzione sulla macchina disponibile all’utente, viene attivato come programma "stand-alone" o come procedura di un ambiente integrato (e.g. un VI di LabVIEW);
* Più di un programma CA può essere in esecuzione in un dato istante temporale;
* Può fornire una interfaccia utente;
* Non può inviare direttamente comandi alla strumentazione ma si deve limitare all’invio di richieste al programma server attraverso un canale TCP/IP.

Il programma "virlab server" ha le seguenti caratteristiche principali:

È in esecuzione sulla macchina dell’utente e su ogni macchina del laboratorio, non presenta interfaccia grafica e viene attivato coma programma "daemon" al momento del boot o all’atto della prima richiesta di servizio da parte di un programma CA;

Un solo programma "virlab server" può essere in esecuzione in un dato istante sulla stessa macchina;

Comanda la strumentazione disponibile sulla macchina su cui è in esecuzione oppure dialoga con altri programmi "virlab server" tramite rete per l’esecuzione remota dei comandi;

fornisce ai CA un immagine dei banchi disponibili specificando le caratteristiche degli strumenti e i relativi indirizzi;

può svolgere funzioni di simulazione con comandi identici a quelli corrispondenti a richieste di esecuzione di servizi a dispositivi fisici;

permette l’allocazione delle risorse attraverso richieste specifiche di "lock" e "unlock";

fornisce delle informazioni di "audit" (eventualmente mantenute su file) per tenere traccia della sua evoluzione temporale.

L’interazione tra CA e programma "virlab server" è messa in evidenza nella Figura 1.2 nella quale si può immediatamente notare che, grazie alla presenza di un programma server sia sul PC1 che sul PC2, uno stesso applicativo client (CA) vede gli strumenti A e B allo stesso modo.

Infatti un CA effettua una richiesta sempre al server locale il quale, per come è strutturato internamente, "nasconde" la destinazione reale della richiesta (strumento A o strumento B). In questo modo lo strumento diventa: per l’utente l’applicativo client, per il CA il server locale e per il server locale uno qualsiasi degli strumenti collegati ad un server con cui può dialogare.

Con questa struttura è facile immaginare che il laboratorio "virtuale" (ViRLab) sia costituito dall’insieme dei server che sono in grado di scambiarsi le informazioni. Inoltre, la possibilità di trasferire le richieste di un CA attraverso Internet permette, anche, la realizzazione di un laboratorio distribuito cioè composto da un insieme qualsiasi di nodi della rete globale.

Dalla Figura 1.2 si può notare anche che il flusso delle informazioni tra CA, server e dispositivi fisici, in realtà, può avvenire in due modi:

* attraverso il server locale (percorso 1-2-3);

* con un collegamento diretto TCP/IP al server remoto (percorso 5-3).

Al programmatore di CA è lasciata libera scelta tra le precedenti alternative tuttavia, anche se la seconda modalità appare più efficiente, non sempre è possibile instaurare una comunicazione TCP/IP diretta tra CA e server remoto. La comunicazione con il software locale, quindi, permette di svincolare il programmatore dalle problematiche relative alla trasmissione attraverso proxy-server, firewall ecc., evitandogli di prevedere il supporto per tali sistemi. Inoltre la seconda possibilità esclude la macchina locale dal laboratorio e quindi non permette di utilizzare assieme strumenti locali con strumenti remoti. Per ulteriori commenti a tal proposito si veda il capitolo "Protocollo di rete" con particolare attenzione al paragrafo "Scelta del protocollo di comunicazione".

Gli strumenti virtuali del progetto ViRLab sono costituiti da un insieme di programmi, ad esempio realizzati in ambiente LabVIEW, che attraverso un canale TCP/IP comunicano con il programma "virlab server" da cui successivamente ricevono i risultati oggetto di eventuale post-elaborazione e rappresentazione grafica.

1.1.1 Client sviluppati in ambiente LabVIEW

LabVIEW è un ambiente di programmazione di tipo grafico realizzato dalla "National Instruments" ed orientato principalmente allo sviluppo di applicazioni software per la gestione di strumenti di misura. La sua flessibilità è tale da permettere ai programmatori lo sviluppo di software di impiego più generale e non necessariamente limitato alla strumentazione numerica; di fatto LabVIEW si propone come valida alternativa ai compilatori tradizionali.

Per realizzare un generico programma client si utilizzano alcune funzioni di libreria che costituiscono i "mattoncini" fondamentali degli strumenti virtuali: questa organizzazione del software permette di costruire un VI (Virtual Instrument) avente solo le funzionalità desiderate tralasciando quelle non necessarie in una determinata situazione.

Un generico programma client LabVIEW è costituito da un pannello frontale, che rappresenta l’interfaccia visibile all’utente. Esso si può considerare suddiviso in due sezioni una per l’ingresso, costituita dall’insieme dei controllori che servono per impostare gli strumenti, e una per l’uscita costituita dall’insieme degli indicatori che permettono la rappresentazione dei dati.

Sono disponibili 3 categorie di librerie, cioè insiemi di applicativi, LabVIEW:

* Libreria locale: i VI accedono direttamente agli strumenti tramite scheda GPIB;
* Libreria remota: i VI accedono agli strumenti utilizzando il modulo SUB-VI che attua la comunicazione con il programma server;
* Libreria SCPI: simile alla libreria remota tranne per il fatto che i comandi inviati agli strumenti sono in formato SCPI.

La scelta dell’ambiente LabVIEW per la realizzazione dei programmi client può essere giustificata per i seguenti motivi:

* Possibilità di realizzare velocemente programmi che gestiscono una sezione di misura;
* Ampia disponibilità di librerie predisposte per l’uso si strumentazione;
* Possibilità di ottenere una struttura modulare dei programmi;
* Possibilità di realizzare un’interfaccia grafica particolarmente accurata per la rappresentazione dei dati.

1.1.2 Client sviluppati con altri ambienti

Un programma client può essere realizzato attraverso diversi ambienti di sviluppo tra cui i tradizionali linguaggi di programmazione. I requisiti richiesti riguardano la modalità con cui deve avvenire la comunicazione con il server e la struttura delle informazioni scambiate. In particolare, un generico client deve instaurare un comunicazione TCP/IP con il server, spedire un comando nel formato specificato nel paragrafo 3 del Capitolo "Rappresentazione delle informazioni", e rimanere in attesa, senza chiudere la connessione, della risposta, che avrà una struttura analoga a quella della richiesta.

All’interno del progetto "ViRLab" sono stati realizzati alcuni client in grado di comunicare con il "virlab server". L’ambiente di sviluppo utilizzato, Visual Basic 5, permette di gestire una comunicazione TCP/IP mediante il controllo standard Winsock. Affinché la comunicazione sia possibile si devono compiere le seguenti operazioni:

* Impostare i parametri della comunicazione (indirizzo, porta);
* Effettuare richiesta di connessione;
* Nel caso in cui la richiesta sia accettata, spedire i dati nel formato opportuno;
* Rimanere in attesa della risposta, senza chiudere la comunicazione;
* Ripetere le operazioni precedenti per altre eventuali richieste;
* Chiudere la comunicazione al termine delle operazioni.

Il programma "virlab server" rappresenta la parte centrale dell’intero progetto ed è su di esso che si basa l’intero funzionamento del laboratorio remoto.

La progettazione software (design) del programma server, basata sulla specificazione dei requisiti, si è orientata su una struttura modulare che può essere schematizza nella Figura 4. La suddivisione in moduli è basata sulle funzioni fondamentali che il server deve svolgere:

* Interpretazione dei comandi (BM);
* Esecuzione dei comandi sulla strumentazione (LIM);
* Trasmissione dei comandi via rete (ECM);
* Comunicazione con gli applicativi client (LCM).

La separazione dell’intero software in 4 moduli fornisce quella semplicità di funzionamento che sta alla base di qualsiasi sistema robusto ed affidabile. Inoltre la modularità fornisce molteplici vantaggi tra cui quelli di seguito elencati:

* Miglior utilizzo delle risorse umane durante la fase di sviluppo con possibilità di assegnazione dei vari moduli a soggetti diversi all’interno del gruppo di lavoro;
* Riduzione dei costi e dei tempi di manutenzione del software nel caso di modifica di uno o più moduli; solo il modulo interessato viene modificato;
*Semplificazione nella ricerca degli errori poiché si evita il fenomeno di "ripple", un errore influenza solo il modulo in cui si verifica;
* Riutilizzabilità dei moduli.

Tutte queste proprietà derivano dalla capacità di un modulo di nascondere le informazioni al suo interno ("Hide Information") se esso si identifica completamente con la sua interfaccia verso l’esterno. Un modulo deve fornire un insieme di funzioni e procedure che forniscono ben definite funzionalità; chi usa queste procedure deve essere garantito che la funzionalità richiesta venga eseguita in modo corretto e non deve preoccuparsi di come essa viene svolta.

Inoltre la modularità è un processo ricorsivo nel senso che i moduli possono a loro volta essere suddivisi in sotto moduli e così via. Infatti anche i moduli del server seguono questa linea e sono in genere suddivisi i più sotto moduli sia in senso orizzontale, come nel caso del modulo ECM che è diviso in due moduli distinti (ECMSender e ECMReceiver), sia in modo verticale con stratificazione del software, come nel caso del modulo LIM in cui i vari strati eseguono diversi livelli di traduzione dei comandi. La modularità, però, richiede anche un costo e cioè la precisa e dettagliata specifica delle interfacce tra i moduli poiché queste devono rimanere stabili nel tempo. Una modifica di un’interfaccia comporta la modifica del modulo a cui essa si riferisce, la modifica del modulo, invece, non deve modificare la sua interfaccia.

Lo scambio di informazioni sia tra moduli, sia verso l’esterno, riguarda il contenuto di un comando poiché, come si è precedentemente sottolineato, sia le richieste che le risposte sono trattate allo stesso modo, cioè come comandi. Come si può intuire dunque una modifica della struttura del comando influisce su ogni interfaccia tra moduli e verso l’esterno, quindi se è necessario rendere indipendente le interfacce dalla struttura del comando altrimenti l’intera struttura modulare del sistema non avrebbe più significato. Questo importante aspetto è stato implementato rappresentando uno stesso comando come modulo cioè con interfacce ben definite non modificabili attraverso le quali è possibile ottenere le informazioni in modo indipendente da come internamente sono rappresentate.

In base a queste considerazioni si è pensato di legare tutte le interfacce tra i moduli ad una unica struttura dati con le caratteristiche precedentemente specificate: la classe VirlabCmd. Questa classe possiede tutte le informazioni che specificano un comando che il server deve interpretare ma anche delle procedure per ottenere le informazioni in modo indipendente da come sono organizzate internamente alla stessa classe. Questo è un concetto importante dell’intero progetto poiché, grazie ad esso, sarà possibile modificare in futuro la struttura di un comando senza modificare alcuna riga di codice dei vari moduli.

In particolare, facendo riferimento alla figura 1.4, l’interfaccia 1 è rappresentata dalla stessa classe VirlabCmd, l’interfaccia 2 non è legata alla classe del comando poiché è rappresentata dai "driver" per la comunicazione con la strumentazione, le interfacce 3 e 4 sono ottenute mediante delle funzioni della classe VirlabCmd. Per una dettagliata descrizione delle interfacce, della struttura interna del comando e della classe VirlabCmd si faccia riferimento al capitolo relativo alla "Rappresentazione delle informazioni.

1.1.3 BM: Bench Manager

Il Bench Manager (BM) è il modulo principale dell’intero programma "virlab server" e si occupa della interpretazione e gestione dei comandi. BM è essenzialmente il programma principale ed è esso che coordina gli altri 3 moduli durante la gestione dei comandi. Le richieste possono provenire indistintamente da uno qualsiasi dei moduli sottostanti anche se il modulo di provenienza dà un significato diverso alla richiesta ricevuta:

Se proviene da LCM essa è una richiesta effettuata da un CA, normalmente in esecuzione sullo stesso calcolatore nel quale è in esecuzione BM, poiché LCM si occupa delle connessioni con i programmi applicativi;

Se proviene da ECM essa è una richiesta remota cioè proveniente, normalmente, da un altro "virlab server", poiché ECM si occupa della trasmissione via rete attraverso il protocollo HTTP;

Se proviene da LIM essa è una richiesta contenente i risultati di una misura poiché LIM si occupa della gestione degli strumenti fisicamente connessi al computer su cui è in esecuzione il server.

La gestione delle richieste consiste nel trattamento locale del comando o nel suo smistamento a server remoti. In locale possono essere risolte richieste di informazione o di settaggio di parametri del server e, ovviamente, richieste di esecuzioni di comandi sulla strumentazione. In questo ultimo caso vengono utilizzate apposite code, una per ogni banco di misura, in cui le richieste vengono accodate prima del loro invio al LIM. Le strutture a coda sono necessarie poiché BM permette l’allocazione di interi banchi di misura, con procedure di lock e unlock, con cui una applicazione client può riservarsi l’uso esclusivo di un banco. In pratica BM esegue una allocazione globale delle risorse con timeout che impedisce il blocco critico del sistema nel caso in cui una applicazione non sia più in grado di deallocare la risorsa riservatasi.

Oltre a questo BM si occupa della gestione di un database nel quale vengono inserite le informazioni circa il numero di transazioni tra esso e i vari moduli nonché informazioni sui lock, richieste di informazioni ed errori che sono stati gestiti.

1.1.4 ECM: External Communication manager

L’External Communication Manager si occupa della spedizione e ricezione dei comandi via rete attraverso il protocollo HTTP. Esso è diviso in due moduli:

ECMSender che svolge le funzioni di client HTTP, cioè spedisce i comandi;

ECMReceiver che svolge le funzioni di server HTTP, cioè riceve i comandi.

Entrambi i moduli permettono la spedizione e la ricezione di più comandi contemporaneamente. Nella spedizione vengono segnalati a BM eventuali condizioni di errore con opportuni comandi inseriti in una coda FIFO, in ricezione, invece, vengono inseriti i comandi ricevuti in una coda FIFO dalla quale BM può prelevarli quando ritiene più opportuno.

Tra le caratteristiche fondamentali di ECM si ricorda il supporto, grazie al protocollo HTTP, di strutture quali proxy-server e firewall ormai indispensabili nella realizzazione di LAN collegate ad Internet, e la sua indipendenza dalla struttura interna di un comando grazie all’introduzione delle funzioni PutPacket e GetPacket all’interno della classe VirlabCmd con le quali i due moduli inseriscono ed estraggono i comandi da un messaggio HTTP.

Oltre a questo i due moduli forniscono anche funzioni di autenticazione automatica dei messaggi HTTP e di codifica dei dati trasmessi.

1.1.5 LCM: Local Communication Manager

Il modulo Local Communication Manager si occupa della trasmissione dei dati tra le applicazioni client (CA) e BM, cioè del collegamento locale tra server e CA. La trasmissione avviene tramite il protocollo TCP/IP quindi, come già illustrato precedentemente, LCM può essere utilizzato anche per trasmissioni via rete con i pregi della prestazione ma con gli svantaggi legati al mancato supporto per proxy-server.

LCM accetta le connessioni di più applicazioni client contemporaneamente e le identifica tramite un codice numerico che verrà inserito nel comando passato a BM. Il codice è necessario per poter identificare le risposte con i risultati e mandarle al relativo mittente.

Anche in questo caso è importante mettere in evidenza l’indipendenza del modulo dalla struttura interna del comando grazie alla presenza delle funzioni InsertString e GetString con cui LCM trasforma un comando in formato di stringa adatto alla trasmissione via TCP/IP.

1.1.6 LIM: Local Instrument manager

Il modulo Local Instrument Manager ha il compito di eseguire fisicamente un comando su uno strumento. I comandi che esso riceve possono essere considerati di "alto livello" nel senso che necessitano di una traduzione per la loro esecuzione. Il modulo infatti è suddiviso in tre strati ciascuno dei quali effettua una traduzione fino ad arrivare alla particolare stringa da spedire attraverso i vari tipi di collegamenti alla strumentazione:

Bench Command Translator (BCT): esegue la virtualizzazione del banco, cioè riconosce a quale strumento del banco deve essere inviato il comando estraendo tale informazione dal comando stesso. Il compito principale di tale modulo è risolvere l’associazione tra indirizzi virtuali, specificati dalla coppia bench-unit, e indirizzi fisici, individuati da interfaccia e indirizzo di interfaccia.

Instrument Command Translator (ICT): esegue la traduzione di un comando da un opportuno formato "generale", ad esempio SCPI, nel comando corrispondente per uno strumento specifico precedentemente identificato dal BCT;

Hardware Interfaces (HI): realizzano i comandi tradotti per l’interfaccia specifica e per lo strumento fisico collegato all’interfaccia selezionata Si noti che esiste un modulo per ogni interfaccia.

Quando viene richiamata la funzione che LIM fornisce per l’esecuzione di un comando da parte di BM un comando attraversa tutti gli strati di traduzione fino ad arrivare al dispositivo fisico. Successivamente le risposte da parte degli strumenti vengono inserite in appositi comandi e inseriti in una coda da cui BM può prelevarli quando ritiene opportuno.

Un aspetto importante del modulo LIM è che esso si basa su appositi database per le varie traduzioni effettuate sui comandi. Questi sono costituiti da svariate tabelle che devono essere configurate in modo adeguato in base alla strumentazione fisicamente collegata al PC.

INFORMAZIONI SCAMBIATE

In questo capitolo verrà descritta la rappresentazione delle informazioni gestite dal progetto ViRLab. La loro specifica è di fondamentale importanza per chi vuole realizzare un programma in grado di comunicare con il server del progetto: l’insieme delle specifiche che saranno introdotte può essere considerato il protocollo di comunicazione con il programma server.

Per comprendere come sono strutturate le informazioni scambiate si devono preventivamente specificare i requisiti che deve soddisfare un generico comando interpretato dal server. A tal proposito si deve ricordare che un comando non può contenere solo richieste di misure da eseguire mediante strumentazione, ma anche richieste di informazioni sullo stato del server e i risultati delle stesse misurazioni. In pratica un comando rappresenta l’unità elementare di informazione scambiata nella comunicazione tra i moduli del programma server o con l’esterno.

Le principali proprietà che un comando deve possedere possono essere riassunte nel modo seguente:

un comando deve permette l’identificazione dell’unità su cui la misurazione deve essere eseguita, sia per quanto riguarda la topologia del banco di misura, sia per quanto riguarda l’ubicazione della macchina che ne permette l’utilizzazione;

un comando deve essere applicabile al numero maggiore possibile di strumenti esistenti, deve cioè adottare (o definire) uno standard per la comunicazione con gli strumenti (ad esempio SCPI);

un comando deve fornire una modalità di accesso alla strumentazione indipendente da indirizzi fisici o tipo di interfaccia impiegati (virtualizzazione del banco di misura);

un comando deve possedere una sintassi in vista della sua interpretazione da parte del programma server;

la struttura di un comando deve poter essere modificata idealmente senza comportare cambiamenti ai moduli del programma server, o almeno i cambiamenti richiesti devono essere limitati.

Queste proprietà si traducono nella suddivisione del comando stesso in campi e sotto campi con significati ben precisi. Le informazioni contenute in questi campi e le relazioni tra esse permettono di soddisfare le proprietà precedentemente specificate e quindi una loro modifica comporta la riprogettazione del modulo "Bench Manager" che ha il compito di interpretarli.

Oltre a tutte proprietà si devono introdurre delle codifiche appropriate del comando per renderlo adatto alla trasmissione attraverso i vari canali di comunicazione utilizzati. La codifica è strettamente legata al canale di comunicazione il quale richiede delle caratteristiche ben specifiche a cui è necessario uniformarsi.

I due canali esterni al programma server utilizzati riguardano le interfacce tra :

il modulo LCM e le applicazioni client (CA), realizzata attraverso una comunicazione TCP/IP;

i moduli ECM nelle trasmissione via rete, realizzata attraverso il protocollo HTTP.

Prima di delineare come sono stati strutturati i pacchetti TCP/IP e HTTP nei due casi è necessario analizzare come internamente è suddiviso un comando, suddivisione che si basa su alcuni ulteriori requisiti fondamentali del progetto "ViRLab" che verranno subito descritti.

Quando si svolge un’operazione che coinvolga un generico strumento connesso localmente a un calcolatore risulta necessario specificare alcuni parametri (ad esempio indirizzi 488). L’operazione stessa può inoltre essere specificata sintatticamente secondo una modalità che dipende dallo strumento specifico che si intende controllare. Un tipico esempio è costituito dai comandi che si inviano normalmente agli strumenti nel formato di stringhe ASCII. Tali comandi assumono costrutto sintattico diverso a seconda della famiglia di strumenti coinvolti (oscilloscopio, multimetro, …), o ancora variano al variare del modello prescelto all’interno di una stessa famiglia (HP54600, Tek TDS340, …). Al fine di superare le precedenti difficoltà si è introdotto il concetto di virtualizzazione di un banco di misura. Per definizione, si pensa che un banco di misura sia fisicamente costituito da un insieme di strumenti che possono essere controllati localmente da un computer, e dai dispositivi sotto test ad essi connessi, ovvero da tutti i moduli eseguibili in grado di fornire dati simulati in risposta a comandi. Con virtualizzazione di un banco di misura si intende mostrare ad un client un banco di test sempre allo stesso modo, come se cioè si trattasse composto di unità le quali reagiscono a comandi software la cui sintassi non cambia al variare degli strumenti fisici effettivamente associate a tali unità o al variare della modalità di collegamento degli strumenti tra loro e con il dispositivo sotto test.

Si osserva che al variare del tempo, ovvero tra un test e un altro, l’organizzazione di un banco può variare. In particolare possono variare

* gli strumenti disponibili,
* le connessioni tra strumenti,
* i dispositivi sotto test, connessi alla strumentazione.

Per quanto riguarda i dispositivi sotto test, si può certamente supporre che una loro variazione sia ininfluente ai fini della organizzazione della procedure di test fintantoché non viene variata anche la topologia delle connessioni alla strumentazione. Si noti che, banalmente, uno degli obiettivi di una procedura di test controllata da calcolatore è proprio quella di poter ripetere lo stesso test su di uno stesso dispositivo o su dispositivi distinti.

Per quanto riguarda le variazioni sia degli strumenti fisicamente disponibili, sia delle connessioni tra strumenti, si osserva che esse comportano in genere anche una parziale ridefinizione della procedura di test, nel senso che i comandi inviati agli strumenti devono essere variati.

Per minimizzare tali modifiche si mette a disposizione una serie di funzioni che consentono di identificare un tipologia delle connessioni e degli strumenti disponibili. Un banco di misura viene quindi identificato mediante una forma del tipo:

nome banco, strumenti fisici connessi, classe di dispositivi sotto test.

e opportune funzioni svolte dal server permettono ai client di verificare se il banco di misura attualmente disponibile, è compatibile con la procedure che sta per essere eseguita.

La definizione di banco di misura comporta la possibilità di poter specificare in "run-time"

* quali strumenti sono disponibili;

* le interconnessioni tra gli strumenti e i DUT (Device Under Test).

Tali informazioni sono organizzate in opportuni file che il programma server legge (periodicamente) in modo da poter rendere disponibili le informazioni corrispondenti ai client o in modo da poter correttamente attivare le procedure di traduzione dei comandi definite nel seguito.

Dal punto di vista di un client l’unica informazione interessante è pertanto il nome di un banco di test il quale si suppone individui univocamente un insieme di strumenti fisici e DUT opportunamente connessi. Inoltre un client si può riferire ad uno strumento o ad un sottoinsieme di strumenti di un banco come una "unità", anch’essa individuata da un nome logico.

Un virlab server può gestire contemporaneamente più banchi di misura composti ognuno da più unità. Le unità, inoltre, possono esser condivise da più banchi che per riservarsene l’uso adottano politiche di allocazione di risorse mediante primitive di "lock" e "unlock".

Un comando viene pensato logicamente composto dei campi e sotto campi descritti nella Tabella 2.1

Tabella 2.1 Struttura logica di un comando

Questa suddivisione è conseguenza di diversi aspetti che devono essere tenuti in considerazione per una gestione corretta delle informazioni.

In particolare, come conseguenza del fatto che un comando può contenere al suo interno diversi tipi di dati (comandi per gli strumenti, risultati di misurazioni, ecc.), è necessario introdurre una modalità per capire cosa esso contiene. Questo viene realizzato attraverso il campo "Command_Class" con cui si specifica la classe del comando cioè se esso è una richiesta, una risposta, un errore e così via.

Un altro aspetto è quello dell’identificazione del destinatario e del mittente di un comando. Deve essere specificato a chi il comando deve essere inviato sia per quanto riguarda la strumentazione, sia per quanto riguarda l’applicazione client. Si può intuire che i due valori sono simmetrici poiché chi effettua una richiesta, quindi il mittente, durante la ricezione della risposta diventa il destinatario. I campi preposti a questo scopo sono "destination" e "sender" che sono suddivisi a loro volta in sotto campi per l’identificazione all’interno della gerarchia: macchina-banco-unità, se il destinatario è uno strumento, o macchina-applID-commandID, se si tratta di una applicazione client.

Inoltre è necessario introdurre in un comando delle informazioni che facilitino la sua gestione, questo può essere fatto attuando una suddivisione dei comandi stessi in classi e sotto classi che indicano un comportamento ben preciso che il BM deve seguire. Il campo preposto per questo è chiamato "service" poiché identifica un servizio che il BM è il grado di fornire, mentre il campo "type" identifica un tipo di comando nella classe specificata (ad esempio: info-numeroclient o accesso-send).

Infine non può mancare l’indicazione del comando vero e proprio cioè della stringa da inoltrare allo strumento o della stringa che contiene i risultati e così via. Esso può essere considerato il parametro dell’intero comando e viene rappresentato dal campo "Cmd".

La struttura interna di un comando può variare nel tempo e quindi deve essere prevista una implementazione che non comporti uno stravolgimento dell’intero progetto software se essa viene modificata. Un esempio di tale implementazione è la classe VirlabCmd che sarà descritta nel seguito.

La struttura logica di un comando presentata nel paragrafo precedente può essere implementata in modi diversi a seconda del modulo di comunicazione coinvolto. Nel caso di una comunicazione tra gli applicati client (CA) e il modulo LCM la codifica avviene come segue.

Un comando viene compattato in un unico pacchettoTCP/IP nel quale tutti i campi di un comando sono scritti in un’unica stringa secondo la procedura seguente:.

* Si trasformano i valori dei vari campi in stringhe;

* Si riuniscono le varie stringhe ottenute in un'unica stringa più grande utilizzando dei separatori di campo univoci, impiegati per permettere la successiva estrazione dei campi dalla stringa stessa;

* Si definisce una modalità per determinare la fine della stringa;

* Infine i caratteri impiegati nella codifica del campo "Cmd" appartengono alla tabella ASCII intera a 8 bit, ovvero assumono un qualunque valore compreso tra 0₁₀ e 255₁₀.

In particolare i separatori utilizzati sono:

* Separatore di campo: carattere di "linefeed" (ASCII code = 10);

* Separatore di sottocampo: carattere di "horizontal tab" (ASCII code=9);

e la modalità per determinare la fine della stringa si basa sull’aggiunta della sua lunghezza in testa all stringa stessa.

La costruzione della stringa avviene mediante i seguenti passi (si ricordi che il campo "BM_status" non viene trasferito ai CA):

* Deve essere inserito un separatore di campo ogni volta che inizia un campo del comando;

* Deve essere inserito un separatore di sottocampo prima di ogni sottocampo;

* In testa alla stringa devono essere inseriti due numeri in formato stringa: il primo, che occupa sempre e solo il primo carattere, indica il numero di cifre del secondo numero, il secondo indica il numero di caratteri dell’intera stringa, compresi i numeri in testa.

Si consideri il seguente esempio in cui per identificare il separatore di campo si utilizza la coppia di caratteri "\n" e per separatore di sottocampo la coppia "\t".

Se il comando da codificare è il seguente:

La stringa che lo rappresenta è:

Infatti dal primo "\n" , compreso, alla fine vi sono 78 caratteri a cui si devono aggiungere i 3 per i numeri all’inizio ottenendo i numeri 2 e 81 all’inizio della stringa. Si noti la mancanza del campo "BM_status" che non deve essere inserito.

E’ interessante notare che l’introduzione di indicazioni sulla dimensione del pacchetto in testa allo stesso consente di inviare nel campo "Cmd" anche codici di controllo della tabella ASCII, ovvero di poter impiegare un formato binario per la trasmissione di informazioni.

La seguente codifica è adottata nella trasmissione tra i moduli ECM per il trasferimento dei dati via rete, chi quindi necessità di dialogare in modo remoto con il programma server attraverso il modulo ECM deve adottare la struttura delle informazioni illustrata nel seguito.

Anche in questo caso si tratta di trasformare un intero comando in una stringa poiché HTTP si basa sul protocollo TCP/IP. HTTP però ha delle maggiori restrizioni di TCP/IP poiché i suoi messaggi devono rispettare la struttura delineata dalla grammatica che descrive il protocollo stesso. In particolare, alcuni caratteri di controllo all’interno di un messaggio HTTP assumono un ben determinato significato. Questi caratteri se presenti all’interno di un comando non vengono eliminati con la trasformazione in stringa adottata nel caso di collegamento diretta e un server HTTP interpreterà i messaggi ricevuti in modo errato. Per evitare tale situazione si codifica la stringa del caso diretto in modo da eliminare la presenza dei caratteri di controllo.

La codifica della stringa adottata può essere considerata una "pseudo" conversione "binhex" in cui ad ogni carattere della stringa vengono associati due caratteri che rappresentano in esadecimale il numero del carattere stesso nella codifica ASCII.

Nelle seguenti tabelle vi sono le funzioni realizzate in Visual Basic per ottenere tali codifiche.

Per chiarire come la codifica avviene consideriamo il seguente comando:

Al quale verrà associata la seguente stringa del caso di comunicazione con il modulo LCM:

Successivamente mediante la codifica "binhex" si otterrà la seguente stringa:

Infatti il codice ASCII di "2" è 32, di "8" è 38 e così via. In particolare si osservi che i separartori di campo e sottocampo sono codificati con "0A" e "09", cioè 10 e 9 in esadecimale. Anche in questo caso non è presente il campo "BM_status" che non deve essere trasferito.

Questa stringa per poter essere trasferita con il protocollo HTTP viene inserita nel "body" di un messaggio HTTP di tipo POST, per maggiori chiarimenti sulla costruzione dei messaggi HTTP si faccia riferimento al paragrafo "Utilizzo del protocollo HTTP nel progetto" del Capitolo "Protocollo di rete".

La classe VirlabCmd è un struttura complessa, come si può vedere dalle Tabella 2.4 e Tabella 2.5, in cui, oltre alle informazioni che riguardano i vari campi in cui è stato suddiviso un comando, vi sono anche alcune funzioni e procedure che, dai dati presenti nella struttura, producono delle stringhe adatte alla trasmissione via rete, in pratica realizzano le stringhe per la comunicazione diretta e per la trasmissione via HTTP.

Le funzioni presenti nella classe VirlabCmd hanno il pregio di permettere l’indipendenza tra la struttura interna del comando e i moduli del progetto. Infatti, ad esempio, LCM per trasmettere un comando via TCP/IP non ha la necessità di conoscere come è strutturato un comando per poi trasformarlo in formato stringa, ma gli è sufficiente richiamare la funzione "GetString" della classe per ottenere lo stesso risultato. In modo analogo a ECM per produrre la stringa codificata è sufficiente richiamare la funzione "GetPacket" senza preoccuparsi nemmeno della codifica che quindi può essere cambiata anch’essa in futuro senza modificare il modulo.

Ai vari moduli (LCM, ECM, LIM) non interessa cosa deve essere trasmesso ma soltanto che esistano le funzioni per ottenere le stringhe da trasmettere. Infatti, i moduli LCM e ECM possono essere utilizzati per trasmettere qualsiasi tipo di informazione, attraverso i rispettivi canali di comunicazione.

La lista dei comandi implementati rappresenta l’insieme dei comandi a cui il server, ed in particolare BM, è in grado di rispondere. Se si utilizzano dei valori per i vari campi differenti da quelli previsti BM risponde con un messaggio d’errore. Più semplicemente la lista dei comandi implementati rappresenta il "linguaggio" con cui si può dialogare con il server.

Di seguito vengono riassunti i vari valori in apposite tabelle.

Il campo "command class" serve ad identificare il tipo di comando inviato.

Questi 2 campi servono ad identificare il tipo di richiesta ricevuta.

Nel caso di classi di comando del tipo CC_REQUEST:

Per classi di comando del tipo CC_ERROR:

Questo è l’insieme dei comandi con cui il server risponde alle varie richieste ricevute.

IL LINGUAGGIO SCPI

Per porre rimedio ad una situazione di confusione che si era venuta a creare nei primi anni '60 quando esistevano una larga varietà di interfacce e protocolli di comunicazione non standarizzate per il controllo tramite computer degli strumenti di misura, nel 1975 l' Istitute of Electrical and Electronic Engineers ( IEEE ) approvò la normativa IEEE 488.

IEEE 488 definisce un protocollo standard per la trasmissione di dati fra strumenti e computer. Più precisamente tale normativa definisce un protocollo per lo scambio di informazioni tra strumenti e computer senza specificare il significato dei dati scambiati. Come conseguenza le industrie inventarono estensioni al protocollo dipendenti dallo specifico strumento, così nei primi anni '80 si iniziò a sentire l' esigenza di uno standard che permettesse di specificare anche la semantica dei dati scambiati via IEEE 488.

Nel 1987 la IEEE propose "IEEE 488.2-1987, Codes, Formats, Protocols and Common Commands for Use with IEEE 488.1-1987". Questo standard definisce le regole che devono soddisfare gli strumenti e i controllori di un sistema di misura, unitamente all' organizzazione della comunicazione e pure il formato e le specifiche di alcuni comandi frequentemente usati. Ogni industria di strumentazione era lasciata libera di definire invece il nome e gli effetti di altri comandi, e così è tuttoggi possibile che due strumenti simili e conformi allo standard IEEE 488.2, possano presentare comandi sintatticamente diversi. Per ovviare a tale incoveniente i principali costruttori hanno fondato un consorzio, il quale ha definito un' estensione del protocollo IEEE 488.2, lo standard SCPI (Standard Commands for Programmable Instruments). L' idea base dello standard consiste nel definire istruzioni associabili a blocchi funzionali nei quali si può pensare sia suddivisibile un qualsiasi strumento. Tale approccio presenta parecchi vantaggi. Innanzi tutto è possibile descrivere in modo uniforme una grande varietà di funzioni e strumenti. Vale a dire che lo SCPI rende compatibili, dal punto di vista della programmazione, strumenti di una stessa classe o strumenti aventi le stesse funzionalità. Ad esempio per una misura di tensione in continua su Oscilloscopi di case costruttrici diverse o anche impiegando un multimetro si utilizza sempre la stessa istruzione cioè : SENSe:FUNCtion "VOLTage:DC", in modo analogo per la misura di frequenza mediante un Counter o un Oscilloscopio si userà il comando: SENSe:FUNCtion "FREquency". Si parla talvolta di coerenza di programmazione "verticale" per indicare l' utilizzo dello stesso comando per controllare dispositivi appartenenti alla stessa classe (nell' esempio precedente la classe degli strumenti Oscilloscopi). Viceversa la coerenza "orizzontale" di programmazione consiste nell' uso dello stesso comando per controllare una funzionalità simile in strumenti di classi diverse.

Per quanto riguarda le risposte che gli strumenti inviano all' host computer si osserva che il formato della risposta di uno strumento compatibile SCPI ad una particolare richiesta è ben definita, riducendo così lo sforzo di interpretazione dei dati o dello stato del dispositivo in quanto il formato dei dati e le informazioni sullo stato sono forniti in un formato indipendente dal particolare dispositivo dialogante.

Un ulteriore vantaggio associato allo standard SCPI è quello di ridurre il tempo di sviluppo dei programmi di implementazione dei comandi degli strumenti sui dispositivi compatibili SCPI, fornendo un linguaggio di programmazione facile da interpretare e ben strutturato. In particolare per un impiego remoto dello strumento, semplici comandi SCPI comportano per l' utilizzatore, un controllo della strumentazione SCPI facile e veloce, mentre un controllo della strumentazione tradizionale spesso fornisce parecchi comandi dettagliati, ma complicati.

Il linguaggio è progettato per essere espanso in futuro con nuovi comandi mantenendo la compatibilità con i comandi già definiti; infatti non appena un costruttore propone un nuovo strumento, il linguaggio di programmazione viene aggiornato in modo da rimanere compatibile con gli strumenti SCPI esistenti. Il Consorzio SCPI analizza annualmente le proposte di estensione dei comandi dello standard, proposte che possono essere inoltrate sia dai membri del Consorzio sia da altri enti interessati. Le revisioni dello standard, pubblicate annualmente, hanno validità immediata e diventano parti permanenti del linguaggio, per cui ogni copia di SCPI è caratterizzato dall' anno di emmissione di quella versione. La proposta di un nuovo comando può essere accettata se rispetta le regole di "Syntax and Style" e se non esiste un comando che controlla la stessa funzionalità.

Lo SCPI risulta essere estremamente versatile e adatto alle più diverse applicazioni e può essere utilizzato su interfacce IEEE 488.1, IEEE 488.2, VXI Bus, RS 232C e altre.

Ovviamente, dal punto di vista della programmazione l ' uso dello standard SCPI riduce notevolmente lo sforzo di sostituzione di uno strumento SCPI con un altro SCPI rispetto a strumenti non compatibili con tale standard, ma non risolve le problematiche associate all' accuratezza, alla risoluzione e alle funzionalità diverse degli strumenti.

Il linguaggio SCPI è definito da una grammatica rappresentata mediante un albero, vale a dire da una struttura gerarchica; ogni stringa comando è formata dalla successione di parole che si incontrano percorrendo l' albero dalla radice ad una foglia terminale.

Il carattere ":" indica il passaggio nell' albero ad una foglia sottostante e separa le parole nel comando. Ad esempio, il comando: SENSe:CURRent:DC:RANGe:AUTO ON è rappresentato, nell' albero SCPI, dal percorso evidenziato nel grafico sottostante:

LIV. 0 SCPI Sottalbero TRIGger
LIV. 1 INPut DISPlay SENSe TRIGger
LIV. 2 COUPling MENU RESistance CURRent DELay
LIV. 3 NAME AC DC
LIV. 4 RANGe
LIV. 5 AUTO

Le parti del comando associate a ciascuna foglia nell' albero sono dette anche "parole chiavi". Ognuna di queste occupa un diverso livello nell' albero. Comandi corti sono formate da parole chiavi di alto livello e forniscono maggiore generalità all' istruzione. Viceversa un comando formato da molte parole chiavi sostituisce nello standard una istruzione di funzionalità più complessa e maggiormente legata alle caratteristiche dello strumento considerato. Inoltre, ad ogni parola chiave si può associare un sottoalbero, il quale si può interpretare come un set di comandi dello strumento caratterizzati da una funzionalità comune. Ad esempio, il sottoalbero TRIGger raccoglie tutte le istruzioni che riguardano il blocco funzionale di sincronizzazione degli eventi. In particolare una foglia terminale può considerarsi un sottoalbero degenere che individua un solo comando.

In questa ottica conviene considerare ogni strumento modellizzato come un insieme di blocchi funzionali che si scambiano dati o messaggi di controllo; ogni blocco rappresenta una particolare funzione dello strumento e lo standard SCPI definisce quindi un albero per la generazione di comandi in corrispondenza di ogni funzione indicata nei blocchi.

Il modello generale di uno strumento programmabile è rappresentato in figura 3.2

* Signal
* Data bus Signal Routing Measurement Function Format
* Trigger Memory
* Signal
* Data bus Signal Routing Signal Generation Format

flusso dei controlli
flusso dei dati

Con riferimento alla figura 3.2 ogni blocco rappresenta una sub-unità funzionale di uno strumento. Tali blocchi sono descritti nel seguito.

E' il blocco di condizionamento del segnale. I comandi associati a questa funzionalità hanno in comune la parola chiave ROUTe del linguaggio SCPI. Tali comandi adattano il segnale alle caratteristiche richieste nella porta di ingresso o nella porta di uscita dello strumento.

Measurement Function

Il blocco Measurement Function puo’ essere scomposto nei sottoblocchi: INPut, SENSe, CALCulate come indicato in figura 3.3

* INPut SENSe CALCulate
* Measurement Function

Tale blocco di misura esegue inizialmente un condizionamento del segnale d’ingresso (blocco INPut) tramite le funzioni di filtraggio del segnale ( FILTer), di offset (OFFSet), di amplificazione (GAIN ) e di attenuazione (ATTenuation ).

Successivamente il blocco SENSe converte i segnali fisici in dati numerici da inviare all' host computer; le funzioni tipiche implementate da "SENSe" sono quelle di definizione del tipo, dell’ampiezza, della risoluzione del segnale da misurare. Tale blocco è presente in tutti gli strumenti programmabili che misurano grandezze ed è caratterizzato da un ampio numero di sottosistemi.

Il flusso di dati viene in seguito elaborato (blocco CALCulate) per fornire grandezze derivabili da quelle principali, in genere più semplici da utilizzare o di immediata interpretazione e per convertire unità di misura.

I blocchi INPut, SENSe, CALCulate sono associati agli omonimi sottoalberi dei comandi.

Strumenti che utilizzano sorgenti interne di segnale sono costituiti da blocchi funzionali di generazione del segnale (Signal Generation), i quali possono essere a loro volta scomposti in tre sottoblocchi: CALCulate, SOURce e OUTPut come indicato in fig.3.4

* CALCulate SOURce OUTPut
* Signal Generation

Il blocco di OUTPut esegue il condizionamento del segnale generato ed è costituito dalle funzioni di filtraggio, di offset, di attenuazione e di guadagno. Esso è presente in tutti gli strumenti del tipo "sorgente di segnale".

Il blocco di SOURce genera un segnale analogico a partire da parametri opportuni o da dati numerici. Tale blocco è presente in tutti i generatori di segnale e contiene un gran numero di funzioni secondarie a seconda del tipo di segnale da generare.

Infine il blocco CALCulate permette la conversione dei dati numerici cambiando l' unità di misura.

I blocchi OUTPut, SOURce, CALCulate sono associati agli omonimi sottalberi dei comandi.

Il blocco trigger permette di sincronizzare le operazioni dello strumento. Si distinguono nello SCPI associati a tale blocco funzionale quattro sottoalberi di comando: TRIGger, ARM, INITiate e ABORt .

Il blocco Memory è associato ad un set di comandi di gestione della memoria del dispositivo. Esso definisce le operazioni di salvataggio dei dati all' interno dello strumento. La memoria dello strumento può essere inaccessibile all' operatore, oppure può essere solo letta o ancora può essere accessibile sia in lettura sia in scrittura.

Il blocco Format consente la conversione dei dati da un formato interno allo strumento a uno adatto alla comunicazione con i dispositivi esterni.

I dati possono essere rappresentati in formato binario, ottale, esadecimale o ASCI.

Uno strumento può implementare solo alcune delle funzionalità del modello di figura 3.2, restringendo al minimo i comandi accettabili. Ad esempio un voltmetro con un solo ingresso può implementare istruzioni SCPI relative ai blocchi di Measurement Function, Trigger, Format senza necessariamente interessare il blocco Memory o Signal Routing.

Pertanto un voltmetro può essere descritto dal sottoinsieme di figura 3.2 rappresentato in fig. 3.5

Signal Measurement Function Format

Trigger

Analogamente, un alimentatore programmabile ad una sola uscita può essere rappresentato dal blocco generatore di segnale e dal blocco formato dei dati:

Signal Signal Generation Format Data Bus

DISPlay Sottosistema.

Il sottosistema DISPlay controlla la presentazione testuale, la parte grafica ed le informazioni della traccia. Le informazioni della traccia includono dati di misurazione e dati provenienti dall' interazione dell' utente con il pannello dello strumento.

Le foglie principali del sottoalbero DISPlay sono: MENU, WINDow, GRAPhics, STATe, TEXT, TRACe.

FORMat Sottosistema.

Il sottosistema FORMat raccoglie un vasto insieme di differenti rappresentazioni di dati per il trasferimento numerico e ordinato di informazioni. Le foglie principali del sottoalbero sono: DATA, SREGister.

Il comando associato alla foglia DATA fornisce l' impostazione di configurazione dati. Viene specificato il tipo e la lunghezza dei dati. I tipi di dati validi sono: ASCii, INTeger, UINTeger, REAL, HEXadecimal, OCTal, BINAry, e PACKed. Il parametro <length> da specificare con questo comando è opzionale per tutti i tipi; il suo significato è dipendente dal tipo selezionato. Un esempio di implementazione del comando FORMat:DATA sarà illustrato nel Manuale SCPI dell' oscilloscopio HP54615B.

L' input sottosistema controlla le caratteristiche del segnale all' ingresso dello strumento.

In particolare i sottoalberi principali associati a tale sottosistema sono: ATTenuation, COUPling, FILTer, GAIN, IMPedance, OFFSet, POSition.

MEASure Sottosistema.

Lo scopo del gruppo di istruzioni MEASure è l' acquisizione di dati usando un insieme di istruzioni di alto livello. Il gruppo di istruzioni MEASure ha una dualità; si distinguono comandi e richieste caratteristiche. Diversamente, con il sottosistema CONFigure, posizionato allo stesso livello di MEASure, si hanno delle forme distinte di richieste e di comandi. Le istruzioni del sottosistema MEASure si riferiscono alle caratteristiche del segnale quando viene misurato, esse sono strutturate per permettere all' utente di controbilanciare l’ intercambialità del controllo nel processo di misurazione.

MEASURE fornisce una completa capacita’ operativa dove lo strumento e’ configurato; l' effettuazione di una misura fornisce, mediante operazioni sul segnale misurato, i valori di determinati parametri associati. Spesso e’ richiesto un piu’ preciso controllo della misurazione. Percio’ MEASURE e’ integrata provvedendola di due comandi: CONFigure e READ. CONFigure svolge la parte della configurazione della misura e READ svolge l’ acquisizione dei dati post elaborati e parte dell’ elaborazione della misura.

Si può operare una configurazione generica della misurazione utilizzando CONFIGURE e quindi modificare la misurazione cambiando le funzioni dello specifico strumento. Il READ poi, completa il processo di misura. Il sottosistema READ e’ suddiviso in due ulteriori comandi: INITiate[:IMMediate] e FETch?.INITiate[:IMMediate]. Il sottosistema FETCH opera la funzione post elaborazione dati. Su un singolo set di dati acquisiti si possono implementare molte istruzioni FETCH. Per fare un esempio, in un oscilloscopio si possono acquisire molti segnali di misura che contengono parecchie informazioni, come la frequenza del segnale, il voltaggio AC e DC. Un segnale transitorio puo’ essere catturato usando MEASURE, READ o INITIATE. FETCH permette di ottenere ciascuna caratteristica dei differenti segnali senza riacquisire una nuova misura.

MEASURE fornisce la compatibilita’ migliore tra gli strumenti perche’ non e’ richiesta la conoscenza dello strumento per compiere l’ operazione. CONFIGURE/READ e’ meno compatibile se la riconfigurazione dello strumento e’ compiuto tra le operazioni CONFIGURE E READ. Questo perche’ la riconfigurazione dipende dallo strumento specifico. FETCH è ancora meno compatibile perche’ la conoscenza dello strumento e’ necessaria per determinare se l ‘ informazione e’ stata aquisita dallo stesso.

Per fare un altro esempio un oscilloscopio puo’ catturare sia il tempo di salita sia l’ ampiezza dell’ impulso in una singola acquisizione. Se l’ ampiezza dell’ impulso fosse acquisita attraverso un comando MEASURE, sarebbe possibile misurare il tempo di salita.

Se l’ ampiezza dell’ impulso fosse misurata con un cronometro, le informazioni sul tempo di salita non potrebbero essere disponibili senza operare un’ altra acquisizione dei dati. Percio’ FETCH non potrebbe essere usato.

Cambiando alcune parti dell’ acquisizione di uno strumento, i dati di misura esistenti potrebbero essere invalidati. Per esempio la sequenza: INITiate;CONFigure:VOLTage;FETCH:VOLTage? potrebbe generare un errore perche’ il dato e’ stato invalidato dal comando CONFIGURE.

Riconfigurando il display o i blocchi del tracciato non si avra’ questo effetto.

SENSe Sottosistema.

I comandi SENSe sono organizzati in molte sezioni. Ciascuna sezione o sottosistema tratta controlli che riguardano direttamente lo strumento specifico, posizionati nel dispositivo e non riferiti invece alle caratteristiche del segnale diretto. Questi comandi sono relazionati attraverso il nodo SENSe. Il nodo SENSe può essere opzionale in particolari strumenti. Il motivo per il quale SENSe viene reso opzionale è di permettere a dispositivi che dispongono di sensori primari di accettare comandi brevi/corti.

Il nodo SENSE non puo’ essere un optional se SOURce o ROUTe sono optional anch’ essi, poiche’ solo un nodo a un dato livello puo’ essere un optional. Per esempio, un tipico calcolatore puo’ scegliere di fare il nodo SENSE optional, dal momento che i comandi piu’ frequentemente usati sarebbero sotto il sottosistema SENSE. Se il calcolatore contiene anche sia la funzione SOURce sia la funzione ROUTing, queste dovrebbero essere controllate attraverso i loro rispettivi nodi. Un nodo optional come SENSE implica che il dispositivo accettera’ i comandi con o senza il nodo optional e si avra’ lo stesso risultato. Il dispositivo e’ implementato per accettare il nodo optional, se inviato senza errori. In alcuni casi , un sensore puo’ contenere sorgenti dipendenti o funzioni sensorie. L’ aggiuntiva funzionalita’ dipendente sara’ posta come sottonodi SENSE o SOURCE. Inoltre i nodi optionali (SENSE, SOURCE e ROUTE) non sono ammessi se questa funzionalita’ dipendente esiste in un dispositivo. Altrimenti potrebbe verificarsi conflitti nell’ interpretazione dei comandi, per esempio tra SENSE e SOURCE se SOURCE diventa un optional.

Il sottonodo FREQuency di SENSe contiene parecchi comandi che hanno complessi accoppiamenti. Fra gli altri include i comandi START, STOP, CENTER e SPAN.

SOURce

I comandi SOURce sono divisi in molte sezioni. Ciascuna sezione o sottosistema tratta con i controlli che direttamente interessano diversi blocchi del dispositivo, e non sono invece relazionati con le caratteristiche del segnale diretto. Questi comandi sono referenziati attraverso il nodo SOURce . Il nodo SOURce può essere un optional in un dispositivo particolare. La ragione per cui SOURce è optionale è per permettere a dispositivi che sono sorgenti primarie di accettare comandi più corti.

Il nodo SOURce non può essere optionale se lo sono anche il SENSe e il ROUte, perchè solo un nodo ad un dato livello può essere optionale. Per esempio un tipico alimentatore di potenza puo’ scegliere di rendere il nodo SOURce optionale, dal momento che i comandi piu’ frequentemente usati saranno sotto il sottosistema SOURce. Un nodo optional, come SOURce, implica che il dispositivo accettera’ e sviluppera’ i comandi con o senza tale nodo avendo lo stesso risultato. Il dispositivo e’ implementato per accettare il nodo optional, se inviato senza errore. In alcuni casi, un SOURce puo’ contenere sorgenti dipendenti o funzioni sensorie. Allora l’ aggiuntiva funzionalita’ dipendente sara’ collocata come sottonodi SENSE o SOURCE . Inoltre , non sono ammessi i nodi optional (SENSe, SOURce o ROUTe) se questa funzionalita’dipendente esiste in un dispositivo.

Altrimenti potrebbero verificarsi conflitti nell’ interpretazione dei comandi per esempio tra SOURce e SENSe se a SENSe fosse permesso di essere un optional.

I sottonodi principali di SOURce sono CURRent, POWer, VOLTage, FREQuency e RESistance. Questi sottonodi contengono molti set di comando che hanno complessi accoppiamenti.

Criterio di tacito consenso.

Tutti gli strumenti SCPI devono rispettare le specifiche fisiche di IEEE 488.2, eccetto la sezione 4.1 di IEEE 488.1 "Requisiti", che potrà essere omessa quando lo strumento non implementa l' interfaccia IEEE 488.1.

In questa sezione sono indicate i comandi obbligatori e opzionali del formato SCPI

Comandi obbligatori per IEEE 488.2.

Alcuni comandi già definiti nello standard 488.2 devono essere obbligatoriamente gestiti da uno strumento compatibile SCPI. Tali comandi sono riassunti nella tabella 3.7

*CLS CLEAR STATUS COMMAND
*ESE STANDARD EVENT STATUS ENABLE COMMAND
*ESE? STANDARD EVENT STATUS ENABLE QUERY
*ESR? STANDARD EVENT STATUS REGISTER QUERY
*IDN? IDENTIFICATION QUERY
*OPC OPERATION COMPLETE COMMAND
*OPC? OPERATION COMPLETE QUERY
*RST RESET COMMAND
*SRE SERVICE REQUEST ENABLE COMMAND
*SRE? SERVICE REQUEST ENABLE QUERY
*STB? READ STATUS BYTE QUERY
*TST? SELF-TEST QUERY
*WAI WAIT-TO-CONTINUE COMMAND

Questi particolari comandi prendono il nome di Common Commands e sono inviati dal controller ai vari dispositivi. Essi devono obbligatoriamente iniziare con il carattere ASCII

"*" e sono formati da tre caratteri maiuscoli, eventualmente seguiti da un punto di domanda quando il comando e’ una richiesta di informazioni al dispositivo.

Spesso tali comandi interessano i bit dei registri del dispositivo, quindi conviene prima di descriverli parlare dei registri di stato nello standard 488.2 i quali definiscono lo stato dello strumento. Le informazioni sullo stato di un dispositivo possono essere fornite tramite due modalita’ distinte. La prima e’ basata sull’ uso di registri nei quali viene indicato se rispetto ad una situazione di riferimento si e’ verificato una variazione.

E’ possibile anche avere la successione degli stati di un dispositivo utilizzando una struttura di accodamento ( output queue) nella quale vengono sequenzialmente memorizzate tutte le variazioni di stato che si verificano. In tal modo si ha come informazione aggiuntiva l’ evoluzione dello stato del dispositivo.

Ad ogni strumento e’ imposta una struttura interna minima per indicare il suo stato, che prende il nome di struttura standard , nella quale alcuni parametri sono obbligatori, mentre altri sono lasciati alla liberta’del progettista in modo da permettere la rappresentazione anche di situazioni dipendenti specificatamente dal tipo di strumento utilizzato.

Stato dei dispositivi continuamente monitorati.

Condition Register

Transition Filter