tesi dottorato di ricerca in informatica e telecomunicazioni dott. ing. cristian randieri: sistemi...
TRANSCRIPT
UNIVERSITÀ DEGLI STUDI DI CATANIA
FACOLTA’ DI INGEGNERIA
DOTTORATO DI RICERCA IN INFORMATICA E TELECOMUNICAZIONI
- XVI CICLO -
Dott. Ing. CRISTIAN RANDIERI
SISTEMI DI TELECONTROLLO
REMOTO PER IL SUPPORTO AGLI
ESPERIMENTI DI FISICA NUCLEARE
TESI DI DOTTORATO DI RICERCA
Coordinatore:
Ch.mo Prof. O. MIRABELLA
Tutor:
Ch.mo Prof. O. MIRABELLA
DICEMBRE 2003
Desidero ringraziare l’intero staff dell’ISTITUTO
NAZIONALE DI FISICA NUCLEARE - LABORATORI NAZIONALI
DEL SUD di Catania ed, in particolare:
- il Prof. Vincenzo Bellini responsabile
INFN dell’Esperimento di interferometria
nucleare denominato CHIC,
- il Prof. Renato Potenza responsabile
INFN dell’Esperimento Diamante
per avermi concesso l’utilizzo delle risorse necessarie allo
svolgimento delle mie ricerche.
Un ringraziamento va al Prof. Orazio Mirabella per
avermi costantemente seguito durante tutte le fasi di
svolgimento della presente tesi.
Un ricordo va al Prof. Victor Rizza, che purtroppo non è
più tra noi, per avermi trasmesso la sua immensa voglia di
sapere, ricercare e mettere concretamente in pratica idee,
ricerche, studi.
In fine un ringraziamento sincero a tutti coloro che mi
hanno costantemente incoraggiato e supportato nel mio
lavoro di ricerca.
i
SOMMARIO
INTRODUZIONE
CAPITOLO I
PROBLEMATICHE INERENTI I SISTEMI DI SUPPORTO PER LA
RICERDA NEL CAMPO DELLA FISICA NUCLEARE
1.1 INTRODUZIONE ....................................................................................................................... 1
1.2 CONTROLLO REMOTO NEGLI ESPERIMENTI DI FISICA NUCLEARE ................... 2
1.3 TECNICHE DI CONTROLLO REMOTO NEGLI ESPERIMENTI DI FISICA
NUCLEARE............................................................................................................................... 5
CAPITOLO II
I FIELDBUS E L’ARCHITETTURA PROFIBUS
2.1 INTRODUZIONE ....................................................................................................................... 7
2.2 INTRODUZIONE AI FIELD BUS ........................................................................................... 7
2.2.1 ARCHITETTURA DI RETE ............................................................................................................. 8
2.2.2 CARATTERISTICHE DEL TRAFFICO DI DATI E METODI DI ARBITRAGGIO ...................................... 9
2.2.3 VANTAGGI DEL FIELD BUS ....................................................................................................... 10
2.2.4 TIPI DI FIELD BUS ...................................................................................................................... 10
2.3 INTRODUZIONE AL PROFIBUS ......................................................................................... 13
2.3.1 ARCHITETTURA DI RETE .......................................................................................................... 14
2.3.2 LA FAMIGLIA PROFIBUS ........................................................................................................... 16
2.3.3 PHYSICAL LAYER ..................................................................................................................... 17
2.3.4 DATA LINK LAYER ................................................................................................................... 20
ii
2.3.4.1 Generalità .............................................................................................. 21
2.3.4.2 Token reception ..................................................................................... 22
2.3.4.3 Token trasmission .................................................................................. 22
2.3.4.4 Inserimento e rimozione di stazioni sul bus .......................................... 23
2.3.4.5 Inizializzazione del ring logico.............................................................. 24
2.3.4.6 Token rotation time e priorità ................................................................ 25
2.3.4.7 Modalità send/request ciclica e aciclica ................................................ 25
2.3.4.8 Registrazione di stazioni ....................................................................... 26
CAPITOLO III
PROFIBUS PER LE ATTIVITA’ DI RICERCA DEL GRUPPO CHIC
DELL’INFN/LNS
3.1 INTRODUZIONE .................................................................................................................... 27
3.2 L'IMPIANTO PER GLI STUDI SULL'INTERFEROMETRIA NUCLEARE ................. 27
3.3 SISTEMA REMOTO DI MOVIMENTAZIONE .................................................................. 29
3.4 SISTEMA REMOTO PER LA GENERAZIONE DEL VUOTO ........................................ 31
3.5 RETE PROFIBUS .................................................................................................................... 33
3.5.1 APPLICOM COMMUNICATION SERVER ................................................................................ 34
3.5.1.1 Tool di configurazione pcconf .............................................................. 35
3.5.1.2 Applicom User Interface ....................................................................... 36
3.5.2 PROFIBUS DP SLAVES .......................................................................................................... 37
3.5.3 PROFIBUS FMS PLC .............................................................................................................. 38
CAPITOLO IV
CONTROLLO REMOTO DI POSIZIONE MEDIANTE PROFIBUS
4.1 INTRODUZIONE ................................................................................................................... 40
4.2 SISTEMA ELETTROMECCANICO DI POSIZIONAMENTO ....................................... 42
4.3 SISTEMA DI CONTROLLO LOCALE ............................................................................... 43
iii
4.3.1 STRUTTURA INTERNA ......................................................................................................... 43
4.3.2 INTERFACCIA DI CONVERSIONE DEI SEGNALI ..................................................................... 44
4.4 PROGRAMMAZIONE DEI CONTROLLERS HCTL 1100 ............................................... 49
4.4.1 ACCESSO ALLO SLAVE ........................................................................................................ 49
4.4.2 ACCESSO AI REGISTRI DEI CONTROLLERS HCTL 1100 ........................................................ 51
4.4.3 INIZIALIZZAZIONE DEGLI HCTL 1100 .................................................................................. 53
3.4.3.1 Reset ...................................................................................................... 53
3.4.3.2 Caricamento dei registri ........................................................................ 54
4.5 PROCEDURE DI SUPPORTO AL CONTROLLO ............................................................. 55
4.5.1 LETTURA DELLO STATO DEI FINECORSA ............................................................................. 55
4.5.2 CONTROLLO DI POSIZIONE E VELOCITÀ .............................................................................. 56
4.5.2.1 Controllo a profilo trapezoidale ............................................................ 56
4.5.2.2 Procedura di posizionamento ................................................................ 57
4.5.2.3 Procedura di lettura della posizione corrente ........................................ 59
4.6 CALIBRAZIONE DEL SISTEMA DI POSIZIONAMENTO ............................................ 60
4.7 INTERFACCIA UTENTE DEL TERMINALE DI CONTROLLO REMOTO ................ 62
4.7.1 FINESTRA PER IL CONTROLLO DI POSIZIONE ....................................................................... 64
CAPITOLO V
CONTROLLO REMOTO DEL VUOTO
5.1 INTRODUZIONE .................................................................................................................... 66
5.2 ARCHITETTURA DI CONTROLLO DISTRIBUITA ...................................................... 69
5.3 ACQUISIZIONE DELLE MISURE DI PRESSIONE ......................................................... 70
5.3.1 MISURE ANALOGICHE DI PRESSIONE .................................................................................. 70
5.3.2 CONVERSIONE DEI SEGNALI .............................................................................................. 72
5.3.3 ACQUISIZIONE DEI DATI ..................................................................................................... 75
5.4 SISTEMA DI CONTROLLO LOCALE ................................................................................ 79
5.4.1 CONFIGURAZIONE DEL PLC SULLA RETE PROFIBUS ........................................................... 79
5.4.2 ALGORITMO DI CONTROLLO LOCALE.................................................................................. 83
5.5 INTERFACCIA REMOTA DI COMANDO ......................................................................... 93
5.5.1 PROCEDURE PER LA COMUNICAZIONE FMS ....................................................................... 95
iv
CAPITOLO VI
RECS 101 UN SISTEMA DI CONTROLLO REMOTO BASATO SU
TECNOLOGIA MICRO WEB SERVER EMBEDDED
6.1 INTRODUZIONE .................................................................................................................... 97
6.2 I SISTEMI WEB SERVER EMBEDDED ED INTERNET ................................................ 98
6.3 APPROCCIO MEDIANTE L'UTILIZZO DELLA TECNOLOGIA JAVA ..................... 99
6.3.1 I VANTAGGI DELL'UTILIZZO DI JAVA ................................................................................. 101
6.3.2 L'UTILIZZO DI JAVA ALL'INTERNO DI SISTEMI WEB SERVER EMBEDDED ........................... 102
6.3.3 LA JAVA VIRTUAL MACHINE ............................................................................................. 104
6.3.4 IMPLEMENTAZIONE DELLA JVM ALL'INTERNO DI UN WEB SERVER EMBEDDED ................ 105
6.4 UN CASO REALE:RECS 101 .............................................................................................. 108
6.4.1 PERSONALIZZAZIONE DELL'INTERFACCIA UTENTE ........................................................... 112
6.5 CONFIGURAZIONE DEI PARAMETRI DI RETE ........................................................ 119
6.6 UPLOAD DELL'INTERFACCIA UTENTE PERSONALIZZATA ................................. 119
6.7 IMPLEMENTAZIONE DELLE INTERFACCE HW PER LE PORTE DI I/O ............ 120
6.7.1 UNITÀ DI INPUT ................................................................................................................. 121
6.3.2 UNITÀ DI OUTPUT ............................................................................................................... 122
6.8 PROTOCOLLO DI COMUNICAZIONE IMPLEMENTATO IN RECS 101 ................ 123
6.8.1 MONITOR DELLO STATO DI I/O .......................................................................................... 126
6.8.2 CONTROLLO DEI COMANDI DI OUTPUT .............................................................................. 128
6.9 COMUNICARE CON RECS 101: L'INTERFACCIA SOCKET IN C ........................... 130
6.10 COMUNICARE CON RECS 101: L'INTERFACCIA SOCKET IN JAVA ................. 138
6.11 IL PROBLEMA DELLA SICUREZZA PER I WEB SERVER EMBEDDED ............. 140
6.11.1 POSSIBILI CONTROMISURE .............................................................................................. 144
6.12 I PRINCIPALI PROBLEMI DI SICUREZZA DEGLI APLLET JAVA ...................... 148
6.11.2 ARCHITETTURE DI SICUREZZA IN JAVA .......................................................................... 150
6.13 RECS 101 SECURITY ........................................................................................................ 151
v
CAPITOLO VII
ESPERIMENTO DIAMANTE UN CASO REALE D’UTILIZZO DI
RECS 101
7.1 INTRODUZIONE .................................................................................................................. 153
7.2 ESPERIMENTO DIAMANTE .............................................................................................. 154
7.3 CONTROLLO REMOTO MEDIANTE RECS 101 ............................................................ 157
7.4 ARCHITETTURA DEL SISTEMA DI CONTROLLO...................................................... 160
7.5 INTERFACCIA DI POTENZA ............................................................................................. 162
CAPITOLO VIII
UN GATEWAY X10-TCP/IP PER IL CONTROLLO REMOTO DI UNA
CAMERA A VUOTO
8.1 INTRODUZIONE .................................................................................................................. 164
8.2 INTRODUZIONE AL PROTOCOLLO X10 ....................................................................... 165
8.2.1 CENNI SULLA TEORIA DELLA TRASMISSIONE X10 .............................................................. 166
8.3 PROTOCOLLO X10 MODIFICATO .................................................................................. 170
8.3.1 FORMATO DEI MESSAGGI ................................................................................................... 171
8.3.2 PROTOCOLLO DI ACCESSO ALLA LINEA (MAC) ................................................................. 183
8.3.3 PROCEDURE ....................................................................................................................... 184
8.4 CARATTERISTICHA DEL GATEWAY X10 .................................................................... 186
8.5 SISTEMA REMOTO PER IL CONTROLLO DEL VUOTO ........................................... 187
8.6 INTERFACCIA DI COMANDO .......................................................................................... 190
CONCLUSIONI ...................................................................................................................... 192
BIBLIOGRAFIA ........................................................................................................................ 195
INTRODUZIONE
INTRODUZIONE
Lo studio dei sistemi dinamici possiede oggi un carattere fortemente interdisciplinare, con
applicazioni riguardanti la fisica, la chimica e la biologia. In campo fisico le stesse tecniche,
nate per risolvere problemi di meccanica celeste (come ad esempio lo studio della stabilità
solare) vengono applicati alla dinamica stellare di una galassia [1], a fenomeni di ottica in un
mezzo non omogeneo [2], e alla fisica degli acceleratori di particelle [3]. In quest’ultimo caso,
in particolare, l’introduzione dei magneti superconduttori nella costruzione dei grandi
acceleratori adronici [4], pur avendo permesso di raggiungere campi magnetici elevati (e
quindi elevate energie) a costi contenuti negli ultimi anni ha dato un forte impulso alla ricerca
svolta nel campo della fisica nucleare.
Tali studi molte volte teorici, necessitano di opportune verifiche sperimentali che vengono
effettuate sfruttando sistemi complessi quali ad esempio gli acceleratori di particelle
unitamente ad altri il più delle volte autocostruiti specificatamente per l’esperimento oggetto
della ricerca. Tali sistemi per la loro caratteristica complessità necessitano di svariati
sottosistemi di controllo e monitoraggio remoto poiché i vari esperimenti nella maggior parte
dei casi sono molto rischiosi per l’essere umano che quindi demanda alle macchine la
supervisione ed il controllo di molti parametri sensibili.
Nasce quindi l’esigenza di mettere a punto ed utilizzare sistemi di controllo remoto di tipo
distribuito sufficientemente robusti da ben tollerare le avverse condizioni operative presenti
(campi elettromagnetici intensi, sorgenti radioattive, fluidi criogenici a bassissime
temperature ecc.) ed in grado di soddisfare i necessari requisiti di sicurezza, affidabilità e
semplicità: si pensi agli apparati per la generazione del vuoto, ai sistemi per l’acquisizione
delle misure sperimentali, a quelli per il controllo dei fasci di particelle, ai sistemi per il
raffreddamento a temperature prossime allo zero assoluto, a tutti i possibili attuatori e
trasduttori (pompe, elettrovalvole, organi meccanici) di supporto alla ricerca sperimentale nel
campo della fisica nucleare.
INTRODUZIONE
D’altro canto l’avvento e la diffusione delle nuove tecnologie delle telecomunicazioni
unitamente all’incessante sviluppo dell’elettronica digitale e delle reti di calcolatori ha
radicalmente modificato le tecniche e le metodologie per il controllo di processo di sistemi
molto complessi: in particolare oggi cresce sempre di più l’esigenza di un controllo
distribuito, dove sistemi intelligenti e dispositivi di controllo e/o di misura devono essere in
grado di comunicare tra loro. Unitamente a ciò è aumentata la necessità di ridurre al minimo
il cablaggio dei sistemi che si traduce nella riduzione della posa in opera e manutenzione dei
cavi. Queste nuove esigenze trovano nelle nuove tecnologie di networking svariate soluzioni
sufficientemente consolidate ed in via di progressiva diffusione. Fra queste i Field Bus o Bus
di Campo, le reti Ethernet con i micro embedded web server e lo standard X10, possono
fornire valide metodologie e soluzioni utilizzabili per il controllo remoto di impianti per la
ricerca sperimentale e la produzione industriale.
Della famiglia dei sistemi Field Bus o Bus di Campo ci riferiremo in particolare allo standard
ProFiBus (Process Field Bus) [5], che è una architettura di rete che prevede la presenza di un
unico mezzo di comunicazione o bus, costituito da un doppino schermato o da una fibra
ottica, al quale sono connessi tutti i sistemi di controllo e trasduzione, basata sul modello ISO
OSI ma del quale supporta solo tre dei sette livelli di comunicazione per ragioni di efficienza.
Tale tecnologia è particolarmente indicata in tutte quelle applicazioni tempo-critiche dove la
velocità di intervento costituisce uno dei fattori più importanti.
Per quanto riguarda le reti Ethernet verrà considerata un’architettura di controllo distribuito
che prevede l’utilizzo di micro embedded web server [6], che basati su sistemi a
microprocessore con interfaccia di rete e supporto Ethernet rappresentano entità autonome
capaci di operare all’interno di infrastrutture di reti dati esistenti.
In fine verrà preso in considerazione lo standard X10 [7] tipicamente adoperato per la Home
Building Automation che opportunamente integrato con i sistemi basati su micro embedded
web server permette una maggiore flessibilità di controllo per il controllo di piccoli sistemi
che non necessitano requisiti real time spinti.
INTRODUZIONE
In questo lavoro di tesi vengono presentati i risultati di una collaborazione tra l’ISTITUTO DI
INFORMATICA E TELECOMUNICAZIONI della FACOLTÀ DI INGEGNERIA dell’ UNIVERSITÀ DEGLI
STUDI DI CATANIA ed i LABORATORI NAZIONALI DEL SUD dell’ISTITUTO NAZIONALE DI FISICA
NUCLEARE per la realizzazione e l’utilizzo esteso di soluzioni ed applicazioni dedicate al
controllo remoto di apparecchiature sperimentali di supporto alla ricerca nel campo della
fisica nucleare.
La prima applicazione descritta prevede l’utilizzo di una rete ProFiBus relativamente al
controllo remoto in tempo reale di un sistema robotizzato di movimentazione a tre gradi di
libertà per il posizionamento millimetrico di un complesso di rivelatori di ioni pesanti: in essa
sarà possibile apprezzare i potenziali vantaggi di affidabilità e semplicità dell’uso di un unico
bus di comunicazione unitamente alle buone prestazioni di velocità della rete che consentono
un’interazione dinamica sofisticata tra terminale di comando e postazione remota.
Una seconda applicazione propone un’architettura distribuita per il controllo del vuoto di una
camera per lo sviluppo ed il test dei rivelatori di particelle, con la quale verranno sottolineate
le caratteristiche di decentralizzazione dell’intelligenza che stanno alla base della filosofia dei
bus di campo e per la quale stazioni di supervisione, dispositivi di controllo (regolatori, PLC
ecc.), attuatori e trasduttori condividono lo stesso bus di comunicazione, potendo così
interagire nei più svariati modi.
Una terza applicazione prevede l’utilizzo di micro embedded web server con il supporto alla
Java Virtual Machine [8], per il controllo remoto di attuatori che si è rivelata particolarmente
utile per il controllo di alcuni strumenti di misura ed ha messo in evidenza le sue peculiarità di
portabilità all’interno di infrastrutture Ethernet già esistenti.
In fine viene presentata un’applicazione che mette assieme le caratteristiche delle precedenti
assieme allo standard X10 al fine di semplificare al massimo il cablaggio del sistema. In
questo modo è stato dimostrato come sia stato possibile eliminare quasi totalmente tutti i
INTRODUZIONE
cablaggi, fino adesso necessari, per l’interconnessione ed il controllo remoto di attuatori di
tipologia On/Off quali ad esempio valvole per il vuoto.
CAPITOLO I- PROBLEMATICHE INERENTI I SISTEMI DI SUPPORTO PER LA RICERCA NEL CAMPO DELLA FISICA NUCLEARE
1
CAPITOLO I
PROBLEMATICHE INERENTI I SISTEMI DI SUPPORTO
PER LA RICERCA NEL CAMPO DELLA FISICA
NUCLEARE
1.1 INTRODUZIONE
La continua evoluzione delle tecnologie basate sui sistemi digitali hanno fortemente
modificato le tecniche e metodologie usate nei sistemi di controllo. In particolare oggi la
richiesta di processi distribuiti richiede sistemi intelligenti, dispositivi di controllo e sistemi di
misura capaci di comunicare attraverso la rete. Un importante requisito di questi sistemi è
l’esigenza di ridurre le connessioni, il ché si traduce nel semplificare la gestione dei sistemi
diminuendone le problematiche inerenti alla manutenzione. I sistemi che verranno di seguito
proposti possono rappresentare una valida soluzione per il controllo remoto e per la misura
nei sistemi di acquisizione, normalmente applicati nella ricerca sperimentale oggetto della
fisica nucleare. Questo campo di ricerca richiede apparati di controllo distribuiti capaci di
lavorare in condizioni particolarmente difficili (campi elettromagnetici elevati, presenza di
particelle radioattive, bassa temperatura etc..) ed al tempo stesso bisogna soddisfare i
fondamentali requisiti di sicurezza, portabilità e semplicità. La presenza di un gran numero di
dispositivi complica ulteriormente la progettazione e realizzazione di tali sistemi di controllo.
Molti dispositivi devono essere controllati localmente, ciò richiede frequenti accessi nelle sale
sperimentali. Di norma l’accesso ad una di queste sale è rigorosamente regolamentato da un
accesso ristretto solamente al personale coinvolto nell’esperimento e richiede particolari
procedure dette “di ronda” che assicurano l’effettiva evacuazione del personale dalla sala
prima che venga riattivato l’esperimento in questione [9]. Sfortunatamente, l’ambiente tipico
CAPITOLO I- PROBLEMATICHE INERENTI I SISTEMI DI SUPPORTO PER LA RICERCA NEL CAMPO DELLA FISICA NUCLEARE
2
degli esperimenti nucleari non è sicuro; di conseguenza è molto difficile e pericoloso per un
operatore umano recarsi all’interno di tali sale sperimentali per modificare i parametri dei
sistemi durante quando l’esperimento è in esecuzione. Per questo motivo, l’utilizzo di
moderne tecnologie di controllo remoto rappresentano valide soluzione poiché possono
fornire tools per implementare sistemi di controllo remoto; i sistemi di seguito descritti sono
dei sistemi di comunicazione largamente diffusi nel mondo industriale progettati per
soddisfare queste esigenze.
Il lavoro presentato contiene i risultati dell’implementazione di diversi sistemi di controllo
remoto utilizzati per il controllo di apparati sperimentali per la fisica nucleare. Il controllo
remoto di alcuni apparati rende la gestione dell’esperimento molto più flessibile, eliminando
ogni problema derivane dall’esigenza di accedere direttamente nelle sale sperimentali poco
sicure e pericolose per ogni essere vivente a causa dei forti livelli di radiazione che possono
essere presenti. Da non trascurare anche il fatto che gli esperimenti di fisica nucleare spesso
richiedono l’assemblaggio di sistemi le cui dimensioni sono considerevoli [4], [10]…[19], di
conseguenza effettuare accessi frequenti a questi dispositivi può essere oneroso e a volte
impossibile.
1.2 CONTROLLO REMOTO NEGLI ESPERIMENTI DI FISICA
NUCLEARE
Poiché gli apparati utilizzati negli esperimenti di fisica nucleare sono spesso molto
complessi e coinvolgono un gran numero di dispositivi di misura quali sensori ed attuatori, la
possibilità di gestire questi dispositivi attraverso un controllo remoto presenta due vantaggi:
CAPITOLO I- PROBLEMATICHE INERENTI I SISTEMI DI SUPPORTO PER LA RICERCA NEL CAMPO DELLA FISICA NUCLEARE
3
1) permette agli operatori di modificare alcuni parametri dell’esperimento senza che questi
debbano direttamente accedere alle sale sperimentali;
2) permette di monitorare un gran numero di variabili fondamentali per il buon esito
dell’esperimento.
Il tipo d’informazione presente nel sistema può essere suddiviso in due categorie:
La supervisione dell’impianto ed il controllo dei dati, necessari per il
corretto funzionamento del sistema.
Questa informazione viene utilizzata per settare le condizioni operative che
meglio si prestano per il corretto eseguimento dell’esperimento. La relativa
dinamica è modesta, perciò può essere gestita tramite controllo remoto utilizzando
un sistema distribuito.
L’acquisizione dei dati sperimentali.
I segnali solo solitamente ottenuti a frequenze aleatorie e sono caratterizzati da
una durata molto piccola (generalmente pochi nanosecondi o meno); di
conseguenza essi devono essere memorizzati in loco il ché implica l’utilizzo di
sistemi di acquisizione dedicati che rendono l’eventuale trasferimento attraverso
un sistema a bus non adeguato.
I sistemi sperimentali a cui ci si riferisce vengono normalmente utilizzati per studiare le
particelle subatomiche dell’atomo. Normalmente sono necessarie adeguate strutture protette e
sicure alloggiate all’interno dei laboratori di ricerca per la fisica nucleare il cui accesso è
rigorosamente regolato da sistemi di protezione molto sofisticati e sicuri. Dopo un’attenta
analisi dei vari modi di funzionamento di svariati sistemi sperimentali è stata focalizzata la
nostra attenzione nel problema di monitorare i sistemi di controllo tipici di un esperimento di
fisica nucleare. In effetti abbiamo osservato che questa parte dell’esperimento viene
generalmente gestita in modo tradizionale adoperando soluzioni molto semplicistiche spesso
CAPITOLO I- PROBLEMATICHE INERENTI I SISTEMI DI SUPPORTO PER LA RICERCA NEL CAMPO DELLA FISICA NUCLEARE
4
dettate da regole euristiche. Spesse volte negli esperimenti di fisica nucleare ci si concentra
molto di più nei sistemi di acquisizione dei dati sperimentali che nei sistemi di gestione
dell’esperimento stesso trascurando a volte tutta una serie di complicazioni puramente
operazionali che potrebbero limitarne la corretta esecuzione. L’insorgere di problemi di
questo tipo può limitare l’effettivo tempo di acquisizione dati poiché a volte è necessario
sospendere il fascio e quindi rifare un nuovo setup dell’esperimento stesso.
Più specificatamente sono state fatte le seguenti osservazioni:
· Attualmente la maggior parte dei sistemi di supporto sono attivati manualmente all’interno
delle sale sperimentali;
· Durante ogni esperimento la presenza delle radiazioni (pericolosa sia per gli essere umani
che per la strumentazione) richiede di mettere le sale sperimentali nello stato cosiddetto di
“Safety Control”; il che si traduce nel problema di dover sospendere il fascio ogni qualvolta
un operatore deve intervenire all’interno di tali sale[9];
· Tutte le connessioni tra le sale sperimentali e le sale di acquisizione hanno connessioni
dedicate di tipo punto-punto; Ciò significa che un gran numero di conduttori collegano le due
sale rappresentando di fatto un potenziale punto di diffusione delle radiazioni.
Sulla base di queste considerazioni, abbiamo identificato due punti chiave che influiscono
negativamente sui tempi di setup degli apparati sperimentali:
· I sistema di supporto per gli apparati multirivelatore. In particolare nell’esperimento
CHIC, tale sistema, comprendente 13 rivelatori CSi , deve poter essere movimentato durante
le varie fasi dell’esperimento in modo da potersi posizionare in punti diversi per ottenere
diverse calibrazioni durante le varie fasi di presa dati [20];
· Le camere da vuoto. Tale sistema rappresenta un componente essenziale per la ricerca da
quando i fasci prodotti dagli acceleratori vengono fatti fluire attraverso il vuoto poiché gli ioni
pesanti hanno la proprietà di degradare l’energia da essi posseduti quando sono a contatto con
l’aria. Quindi dal punto di vista sperimentale le camere a vuoto rappresentano un importante
CAPITOLO I- PROBLEMATICHE INERENTI I SISTEMI DI SUPPORTO PER LA RICERCA NEL CAMPO DELLA FISICA NUCLEARE
5
sistema di supporto per la ricerca utilizzato per lo sviluppo e la messa a punto dei rivelatori di
particelle [21].
1.3 TECNICHE DI CONTROLLO REMOTO NEGLI ESPERIMENTI DI
FISICA NUCLEARE
I sistemi di controllo remoto rappresentano una tecnologia ben consolidata nei sistemi di
controllo industriale. Largamente utilizzati negli impianti industriali sino ad oggi hanno una
limitata estensione nelle applicazioni sperimentali. Concettualmente un sistema basato su
tecnologia ad infrastruttura di rete permette di sostituire un fascio di cavi con un cavo singolo.
Questo semplice concetto è una grande innovazione nei processi di controllo dei sistemi di
comunicazione, arrecante un cospicua serie di vantaggi (qualcuno direttamente, altri
indirettamente) i quali si riflettono nelle metodologie e nelle tecniche usate per la
autoprogettazione degli impianti.
I principali vantaggi possono essere descritti come segue:
· Riduzione dei costi dei cavi e quindi della loro installazione, di conseguenza ciò riduce il
numero delle scatole di giunzione, delle barriere di insolazione di sicurezza e da non
trascurare il problema di eventuali cortocircuiti dovuti ad una cattiva posa in opera;
· Facile addizione o rimozione di dispositivi del sistema senza la necessità di nuovi cavi.
Questo è un punto chiave nell’arrangiamento degli esperimenti i quali, diversamente dagli
impianti industriali, sono strutture dinamiche continuamente in evoluzione dove l’addizione o
la rilocazione di sensori è una frequente occorrenza;
· Riduzione in numero di connessioni per i dispositivi montati su parti mobili. Questo è un
innegabile vantaggio in apparati (per es. nelle braccia dei robots o nei supporti mobili dei
CAPITOLO I- PROBLEMATICHE INERENTI I SISTEMI DI SUPPORTO PER LA RICERCA NEL CAMPO DELLA FISICA NUCLEARE
6
sistemi di misura) i quali usano un largo numero di dispositivi collegati e per i quali matasse
di cavi di interconnessione potrebbero rendere più pesanti e più rigide articolazioni;
· Effettuare meno aperture nei muri per passare i cavi. Quando un laboratorio è adattato per
evitare perdite di particelle inquinanti questo potrebbe essere un punto importante;
· Risparmio nel peso dei cavi;
· Riduzione degli errori di installazione. Nei sistemi complessi il problema degli errori umani
nei dispositivi cablati non dovrebbe essere sottovalutato. Quando sono usate centinaia di
connessioni può capitare che una connessione risulti errata (causata, per esempio dalla
confusione tra due differenti conduttori) , non sempre è possibile rivelare l’errore anche
quando il sistema è stato testato. Se è usato un sistema a bus, d’altro canto, i vari dispositivi
sono connessi in parallelo, sullo stesso bus o in differenti buses, e solo la configurazione del
sistema e l’applicazione software sono responsabili per la corretta esecuzione del flusso di
informazioni. E’ possibile implementare moduli software che controlleranno il corretto setup
del sistema;
· Riduzione dei costi di documentazione. Benché questo non sia una voce importante nella
totalità dei costi di un progetto, la fase di produzione della documentazione è una delle più
delicate (in vista di possibili aggiornamenti del progetto). Quando l’aggiornamento (come già
menzionato un esperimento di fisica nucleare è altamente dinamico) coinvolge variazioni
nella disposizione di un certo numero di dispositivi, gli schemi precedenti ed i disegni
richiedono considerevoli modificazioni.
CAPITOLO II – I FIELDBUS E L’ARCHITETTURA PROFIBUS
7
CAPITOLO II
I FIELDBUS E L’ARCHITETTURA PROFIBUS
2.1 INTRODUZIONE
Il ProFiBus é uno standard di bus di campo dalla architettura consolidata e ben definita dai
suoi promotori industriali (Siemens ed altri) e dal punto di vista commerciale è largamente
adottato come modello di riferimento da parte di molte case costruttrici di componenti per il
controllo industriale. In quanto bus di campo esso, grazie alla filosofia dell’unico bus di
comunicazione, rappresenta una valida alternativa a quei sistemi centralizzati dove la
presenza dei collegamenti punto-punto dalla stazione di controllo (workstation o PLC) verso i
vari dispositivi di supporto al controllo (attuatori, trasduttori ecc.) comporta fasi di
installazione ed ingegnerizzazione di notevole complessità anche per schemi di automazione
piuttosto modesti.
In questo capitolo vengono introdotti alcuni cenni sui bus di campo o Field Bus,
successivamente verranno analizzare più nel dettaglio alcune delle caratteristiche salienti del
sistema ProFiBus.
2.2 INTRODUZIONE AI FIELD BUS
Il controllo di processo a livello di singola cella o macchina di
produzione vede ancora oggi l’uso diffuso di connessioni
punto-punto tra un controllore (tipicamente una workstation o
un PLC) ed i vari sensori e attuatori: tali collegamenti fanno
4 20 mA
Fig. 2.1
CAPITOLO II – I FIELDBUS E L’ARCHITETTURA PROFIBUS
8
uso di doppini intrecciati e della codifica “4-20 mA current loop” (Fig 2.1), codifica robusta
poiché basata sulla trasformazione dell’informazione binaria in termini di corrente iniettata
sul doppino da un generatore di corrente costante e quindi relativamente poco sensibile ai
disturbi di natura elettromagnetica. Questo sistema è abbastanza affidabile ma ciononostante
tende oggi ad essere considerato superato per i seguenti motivi:
elevato numero di collegamenti e quindi grande impiego di fili;
lavori di stesura e protezione dei fili piuttosto onerosi.
Da qui nasce l’idea di connettere tutti i dispositivi di campo tramite un unico bus detto
appunto “bus di campo” (Field Bus).
I Field Bus o bus di campo sono reti specializzate per la comunicazione tra dispositivi
finalizzati al controllo di processo , quali controllori, attuatori, sensori, la cui filosofia si basa
essenzialmente sulla presenza di un unico mezzo fisico di comunicazione di tipo seriale (bus)
per l’interconnessione tra i vari dispositivi.
2.2.1 Architettura di rete
Fig. 2.2 Architetture di rete: ISO OSI e Field Bus
Applicazione
Presentazione
Sessione
Trasporto
Rete
Collegamento
Fisico
Collegamento
Fisico
Applicazione
CAPITOLO II – I FIELDBUS E L’ARCHITETTURA PROFIBUS
9
Con il sistema a bus unico, svariati dispositivi confluiscono sul medesimo canale di
comunicazione per cui le informazioni scambiate subiscono un processo di serializzazione: i
dati scambiati fra i dispositivi di controllo, gli attuatori ed i sensori hanno generalmente
dimensioni piccole (anche pochi bits) ma, una volta prodotti, devono raggiungere il proprio
destinatario in tempi estremamente piccoli, legati alla dinamica del processo controllato; al
fine di gestire i processi tempo critici altrettanto rapidamente che con il sistema dei
collegamenti dedicati punto-punto (comunicazione parallela), l’architettura dei Field Bus
risulta mancante dei quattro livelli intermedi presenti nel modello OSI; tale scelta
implementativa comporta uno snellimento nelle fasi di elaborazione dei pacchetti di dati
scambiati tra due unità qualsiasi, riducendo così i servizi offerti a quelli essenziali di livello
fisico, collegamento dati ed applicazione.
2.2.2 Caratteristiche del traffico di dati e metodi di arbitraggio
Il traffico di dati che caratterizza un bus di campo può essere suddiviso in tre categorie:
traffico ciclico, caratterizzato da dati che con periodo costante vengono prodotti, immessi
sul bus e da esso prelevati; tipicamente tale traffico è costituito da istanze di variabili di
processo che periodicamente vengono monitorate; le operazioni con cui tali
comunicazioni vengono realizzate devono impiegare una quantità di tempo frazione del
tempo di ciclo;
traffico aciclico, costituito essenzialmente da informazioni che possono essere generate
in qualunque istante e che sono generalmente associate al verificarsi di particolari eventi
(es. messaggi d’allarme, condizioni particolari di processo ecc.)
traffico ciclico con periodo variabile.
Il problema della gestione del traffico è strettamente connesso con quello della distribuzione
della banda del canale tra le varie stazioni e quindi dell’accesso al bus stesso;
CAPITOLO II – I FIELDBUS E L’ARCHITETTURA PROFIBUS
10
relativamente a quest’ultimo problema si presentano due grosse classi di soluzioni:
un approccio distribuito che lascia alle stazioni connesse al bus il compito di stabilire di
volta in volta chi ha il diritto ad accedervi (es. token bus) riservando ad ogni stazione un
intervallo di tempo ben definito per effettuare le proprie comunicazioni;
un approccio centralizzato che demanda ad una stazione prescelta il compito di arbitro
per l’assegnazione del bus alle stazioni richiedenti; sulla base delle informazioni in
possesso, tale stazione computa una tabella di schedulazione che regola l’ordine di
accesso al bus.
2.2.3 Vantaggi del Field Bus
L’ utilizzo del Field Bus comporta l’eliminazione dei cablaggi separati per ognuno dei
dispositivi di campo, con i seguenti vantaggi:
- semplificazione del sistema;
- riduzione dei costi di cablaggio e passaggio cavi;
- riduzione degli errori di installazione;
- espandibilità del sistema, grazie alla possibilità di connettere “a caldo” nuove stazioni al
bus, ossia senza dover interrompere la rete e quindi il suo funzionamento;
- pronto riconoscimento dei dispositivi guasti e di interruzioni nel cavo;
- possibilità di informazione broadcasting, per cui un dato prodotto da un nodo (es. un
sensore) è disponibile per tutti gli altri dispositivi connessi al bus;
- migliore distribuzione dei compiti che snellisce il carico di lavoro dei dispositivi di
controllo grazie all’adozione di attuatori e sensori sempre più intelligenti che, oltre a
disporre dell’hardware necessario per la comunicazione, posseggono la logica di
regolazione necessaria per la realizzazione locale del controllo ad anello chiuso.
2.2.4 Tipi di Field Bus
Esistono già diverse versioni di Field Bus, tra cui le più diffuse sono:
CAPITOLO II – I FIELDBUS E L’ARCHITETTURA PROFIBUS
11
FIP, uno standard sviluppato in Francia, distribuito solo a livello sperimentale e quindi
non ancora commercializzato. Dal FIP sono generati i seguenti tipi di traffico:
- traffico periodico per aggiornamento di variabili
- traffico aperiodico per aggiornamento di variabili
- traffico aperiodico per scambio di messaggi
La differenza tra messaggi e variabili sta nel fatto che un messaggio è una frame di
lunghezza maggiore di una variabile che è generalmente una informazione molto
piccola. Il traffico è rigorosamente schedulato per cui una stazione per trasmettere deve
avere il permesso dal Bus Arbitrator. Inoltre se essa ha informazioni acicliche da
spedire, può richiederne la schedulazione al Bus Arbitrator, agganciando tale richiesta
ad una trasmissione ciclica. Solo quando ci sarà un pò di banda libera il Bus Arbitrator
manderà l’autorizzazione a trasmetterle. Ovviamente tale meccanismo ottimizza la
trasmissione del traffico ciclico ma è poco efficiente nella gestione di quello aciclico.
IEC, che dovrebbe costituire lo standard internazionale. Esso utilizza un approccio
centralizzato per la gestione del mezzo fisico, infatti l’architettura del Field Bus IEC
prevede un bus con un certo numero di stazioni chiamate Link Master, una delle quali
prende il nome di Link Active Scheduler (LAS) e ogni stazione Link Master ha bisogno
dell’autorizzazione del LAS per poter trasmettere. La tabella di schedulazione prevede
che ci siano una sequenza di trasmissioni di tipo ciclico e degli spazi vuoti disponibili
per il traffico aciclico, che viene gestito con un meccanismo a prenotazione. Questo
approccio permette una gestione più efficiente del traffico aciclico anche perché per
esso sono previsti tre tipi di messaggi con tre diverse priorità: Urgent, Normal e Time
Available.
CAN, un sistema multimaster in cui l’accesso al bus avviene seguendo le regole di un
CSMA/CD modificato. Ogni nodo che necessita di trasmettere dei dati ascolta il bus e
se questo è libero inizia a trasmettere. Se due o più nodi iniziano contemporaneamente a
trasmettere avverrà una collisione e in questo caso il messaggio a priorità più alta
ottiene l’accesso. L’approccio usato è quindi distribuito, e basato su un meccanismo a
collisione più che a token. La priorità è associata ai messaggi, i quali hanno nomi
CAPITOLO II – I FIELDBUS E L’ARCHITETTURA PROFIBUS
12
individuali che specificano il significato del dato. Il numero di nodi è pertanto illimitato
(a meno delle limitazioni di ordine fisico) e quindi si possono aggiungere nuovi nodi
senza cambiare l’hardware o il software del sistema.
Esistono inoltre altre versioni di Field Bus appositamente sviluppate per applicazioni
particolari, come ad esempio quello specializzato per l’automazione dei treni e il Field Bus
MIL 1552, utilizzato nel campo del trasporto aereo.
CAPITOLO II – I FIELDBUS E L’ARCHITETTURA PROFIBUS
13
Fig. 2.3 ProFiBus: esempio di rete
2.3 INTRODUZIONE AL PROFIBUS
Il Process Field Bus (ProFiBus)[5] è un sistema di comunicazione nato per connettere
dispositivi di campo digitali diversi come trasmettitori, attuatori, controllori, PLC e dispositivi
di supervisione e programmazione.
Un bus di campo è di solito costituito da una o più unità centrali di supervisione con funzioni
di controllo e da un certo numero di dispositivi automatici (Fig. 2.3). La funzione più
importante del PROFIBUS è quella di permettere uno scambio ciclico di messaggi tra i
dispositivi di campo e l’unità centrale di controllo. Il sistema ProFiBus include stazioni attive
(Masters), in grado di iniziare comunicazioni indipendenti sul bus, e passive (Slaves) ossia
disponibili alla comunicazione solo su apposita richiesta esterna. In totale possono essere
indirizzate 127 stazioni, delle quali solo 32 attive. L’accesso al bus è realizzato con un
metodo ibrido, ossia di tipo Master - Slave per la comunicazione tra stazioni attive e stazioni
passive, e di tipo distribuito basato su Token Bus per la comunicazione tra stazioni attive. In
questo caso il token è passato da una stazione attiva alla successiva in un ring 1ogico, nel
quale ogni nodo non solo conosce il suo predecessore e successore ma possiede una lista
“Live List” di tutti i nodi vivi sul bus. Questo rende il sistema particolarmente robusto, infatti
se la stazione successiva non risponde si prova con quelle che la seguono nella Live List, fino
Master Unit1
PLC
Slave Unit 1
Control
Workstation
Master Unit2
Digital I/O Module
Digital I/O Module
Slave Unit 2
CAPITOLO II – I FIELDBUS E L’ARCHITETTURA PROFIBUS
14
a quando qualcuna non risponde e, a meno che la rete non sia andata in crash, si riesce sempre
a far sopravvivere il ring che si riconfigura continuamente. Se il ring logico contiene una sola
stazione attiva e diverse stazioni passive si è nel caso di un sistema puramente Master-Slave.
L’accesso al bus viene controllato esclusivamente dalle stazioni attive: la comunicazione é
iniziata sempre da una stazione attiva che ha ricevuto il permesso (token) per l’accesso al bus.
Le stazioni passive invece rimangono neutrali, trasmettendo dati solo quando ne ricevono una
esplicita richiesta; normalmente restano in ascolto sul bus e sondano tutte le richieste,
rispondendo però solo a quelle che effettivamente le indirizzano; inoltre, la risposta da parte
di una stazione passiva deve avvenire entro un certo slot di tempo, oltre il quale la richiesta
deve essere ripetuta.
Il ProFiBus può essere usato in moltissimi campi, dal manufactoring alla produzione
energetica, dalla costruzione automatizzata all’industria di base, ed in generale dovunque
siano richiesti sistemi basati su bus e a basso costo.
Le prestazioni tecniche del bus possono essere adattate alla specifica applicazione: sono
infatti possibili differenti data rates che vanno da 9.6 Kbits/s a 12 Mbits/s, pur mantenendo
invariati i protocolli d’accesso e di comunicazione.
Nei prossimi paragrafi vedremo una breve descrizione dell’architettura di rete, seguita da una
panoramica sulla famiglia ProFiBus e sui suoi componenti; verranno poi di seguito descritte
con maggior dettaglio le caratteristiche comuni a tutte le varianti del ProFiBus.
2.3.1 Architettura di rete
Come nel caso dei FieldBus, il ProFiBus è stato anch’esso sviluppato sulla base del
modello OSI, anche se l’architettura utilizzata è quella classica di tutti i sistemi in tempo reale
per il controllo di processo (sistemi che presentano vincoli temporali piuttosto stringenti),
ossia con tre soli livelli:
1. Physical Layer
2. Data Link Layer
3. Application Layer
CAPITOLO II – I FIELDBUS E L’ARCHITETTURA PROFIBUS
15
i livelli intermedi sono assenti per ovvie ragioni di velocità.
Si riportano di seguito i compiti svolti dai tre livelli:
il livello 1 (Physical Layer) definisce le caratteristiche di trasmissione a livello fisico;
il PROFIBUS può essere utilizzato in una grande varietà di ambienti ed industrie dove
possono essere richieste comunicazioni digitali a basso costo sia tra i dispositivi di campo
che tra questi ultimi ed i controllori dei livelli più alti nella gerarchia di controllo; per
supportare questa varietà di applicazioni le varianti della famiglia PROFIBUS fanno uso
dei seguenti standard di comunicazione fisica: RS 485 e IEC 1158-2; inoltre
recentemente si è cominciata ad utilizzare anche la fibra ottica per permettere distanze di
trasmissione maggiori ed offrire un più alto margine di immunità ai disturbi;
il livello 2 (Data Link Layer) definisce il protocollo d’accesso al bus; il DLL del
PROFIBUS segue lo standard IEEE 802 nel separare i servizi di comunicazione dei dati
(Link Control) dai servizi di controllo dell’accesso al mezzo fisico (Access Control); ciò
permette un più efficiente controllo dell’accesso al bus senza degradare o complicare i
servizi forniti all’Application Layer;
il livello 3 (Application Layer) definisce i servizi applicativi; ogni versione del
PROFIBUS implementa un proprio Application Layer in modo da soddisfare le diverse
esigenze nell’ambito delle applicazioni industriali.
CAPITOLO II – I FIELDBUS E L’ARCHITETTURA PROFIBUS
16
2.3.2 La famiglia ProFiBus
Al fine di soddisfare le diverse esigenze in ambito industriale, sono state fornite tre diverse
ma compatibili versioni di PROFIBUS:
il PROFIBUS - FMS costituisce la soluzione general-purpose per la comunicazione a
livello di cella; i potenti servizi FMS permettono un ampio raggio di applicazioni ed una
grande flessibilità, anche in processi di comunicazione piuttosto complessi e onerosi; in
esso sono definiti tutti e tre i livelli visti in precedenza; l’Application Layer consiste di
un FMS (Fieldbus Message Specification) e una LLI (Lower Laver Interface); l’FMS
contiene il protocollo delle applicazioni e fornisce all’utente una vasta scelta di potenti
servizi di comunicazione, mentre l’LLI implementa le varie relazioni di comunicazione
e permette all’FMS un accesso indipendente dal dispositivo al livello 2 (FDL, Fieldbus
Data Link) che, invece, implementa il controllo dell’accesso al bus ed opportuni
meccanismi di sicurezza. Le tecniche di trasmissione utilizzate sono l’RS 485 o la fibra
ottica;
il PROFIBUS - DP [5] è stato progettato soprattutto per la comunicazione tra sistemi di
controllo d’automazione e dispositivi di I/O e viene particolarmente utilizzato in tutte le
applicazioni che richiedono basso costo ed alta velocità; nell’architettura del
PROFIBUS - DP sono definiti solo i livelli i e 2 e l’interfaccia utente mentre mancano
invece i livelli dal terzo al settimo, assicurando così una trasmissione dei dati veloce ed
efficiente; le funzioni applicative fornite all’utente ed al sistema stesso sono definite
nell’interfaccia utente; per la trasmissione sono disponibili la tecnica RS 485 e la fibra
ottica;
il PROFIBUS - PA é stato progettato in particolar modo per l’automazione di processo;
esso permette lo scambio di dati e l’alimentazione sul bus usando una tecnologia a due
cavi e seguendo lo standard internazionale IEC 1158-2; l’uso combinato di questa
tecnica di comunicazione e di un protocollo per la trasmissione dei dati, estensione di
CAPITOLO II – I FIELDBUS E L’ARCHITETTURA PROFIBUS
17
quello usato dal PROFIBUS - DP, garantisce intrinseca sicurezza e permette ai
dispositivi di campo di essere alimentati sul bus.
PROFIBUS - DP e PROFIBUS - FMS usano la stessa tecnica di trasmissione e lo stesso
protocollo d’accesso al bus, per cui dispositivi diversi, appartenenti a queste due varianti di
fieldbus, possono essere connessi al medesimo bus; dispositivi basati sul PROFIBUS - PA
possono essere facilmente integrati in reti di PROFIBUS - DP/FMS utilizzando un
accoppiatore di segmenti.
2.3.3 Physical Layer
Come preannunciato nel paragrafo precedente, le tre varianti PROFIBUS fanno uso di
tecniche di trasmissione che si differenziano per lunghezza e topologia del mezzo, interfaccia
di linea, numero di stazioni e velocità di trasmissione; tuttavia esse usano lo stesso protocollo
di accesso al mezzo e lo stesso protocollo di trasmissione ed hanno un’interfaccia comune
all’Applicatìon Layer.
Si riportano di seguito alcune brevi descrizioni.
RS 485 per DP/FMS:
è la tecnica più frequentemente utilizzata dal PROFIBUS; le sue aree di applicazione
sono tutte quelle in cui sono richieste alte velocità di trasmissione e installazioni semplici
e poco costose; il mezzo fisico utilizzato è il doppino intrecciato e schermato e le velocità
di trasmissione vanno da 9.6 kbit/s a 12 Mbit/s.
L’RS 485 é molto facile da gestire. La struttura del bus permette l’aggiunta e la
rimozione di stazioni o la realizzazione passo dopo passo del sistema senza influenzare le
altre stazioni. Successive espansioni del sistema non hanno effetti sulle stazioni già attive.
In ogni segmento di bus è possibile connettere fino a 32 stazioni. I1 bus è terminato
all’inizio e alla fine di ogni segmento da un apposito circuito a componenti passivi detto
Bus Terminator, che deve essere alimentato per garantire l’eliminazione degli errori di
CAPITOLO II – I FIELDBUS E L’ARCHITETTURA PROFIBUS
18
riflessione. Quando sono utilizzate più di 32 stazioni. è necessario far uso di ripetitori per
connettere i diversi segmenti.
La tab. 2.1 riassume le principali caratteristiche dell’RS 485.
Topologia della rete Bus lineare, terminato ad entrambe le estremità da
circuiti terminatori
Mezzo fisico Doppino intrecciata schermato
Numero di stazioni 32 stazioni in ogni segmento senza ripetitori; fino
ad un massimo di 127 stazioni con ripetitori
Tipo di connettori Connettori D a 9 pin
Tab. 2.1 Caratteristiche dell’interfaccia RS 485
IEC 1158-2 per PA:
è la tecnica che permette intrinseca sicurezza, soddisfacendo così le esigenze di svariate
industrie tra cui quella chimica e quella petrolchimica, oltre a consentire l’alimentazione
diretta sul bus per i dispositivi ad esso connessi; vediamone di seguito i punti essenziali:
- ogni segmento di bus possiede una sola sorgente di alimentazione detta Power
Supply Unit;
- l’alimentazione non viene fornita sul bus quando una stazione sta trasmettendo;
- ogni dispositivo di campo assorbe una corrente costante;
- la linea di bus è terminata ad entrambe le estremità da un bus terminator;
- è possibile realizzare reti con struttura lineare, ad albero ed a stella;
- è consentito l’uso di segmenti ridondanti per aumentare l’affidabilità.
La tab. 2.2 riportata di seguito mostra le principali caratteristiche della tecnica IEC 1158-
2.
CAPITOLO II – I FIELDBUS E L’ARCHITETTURA PROFIBUS
19
Trasmissione dei dati Digitale, bit-synchronous, codifica Manchester
Velocità di trasmissione 31.25 Kbit/s
Supporto fisico Doppino intrecciato schermato
Alimentazione Sul bus, attraverso le linee di dati
Numero di stazioni 32 stazioni in ogni segmento senza ripetitori; fino
ad un massimo di 126 stazioni con ripetitori
Numero di ripetitori Sino ad un massimo di 4
Tab. 2.2 Principali caratteristiche della tecnica IEC 1158-2
CAPITOLO II – I FIELDBUS E L’ARCHITETTURA PROFIBUS
20
2.3.4 Data Link Layer
2.3.4.1 Generalità
Il ProFiBus utilizza un metodo di accesso al mezzo fisico che è sostanzialmente un ibrido
tra due diverse tecniche: una di tipo distribuito basata sul modello del “Token Passing” ed una
di tipo centralizzato basata sul modello “Master-Slave”.
In particolare, come già anticipato precedentemente, l’accesso al mezzo fisico è controllato
esclusivamente dalle stazioni Master, le uniche stazioni attive collegate al bus, mentre le
stazioni Slave, passive, non possono mai accedere al bus di propria iniziativa ma solo su
richiesta delle stazioni attive. La comunicazione attraverso il bus è iniziata, sempre e solo,
dalla stazione Master che ha acquisito il token e che quindi ha il permesso di accedere al bus.
Il token viene trasmesso da una stazione attiva all’altra attraverso un “ring logico” ottenuto
grazie al fatto che ogni stazione Master collegata al bus conosce oltre al suo indirizzo TS
(This Station), sia quello della stazione Master che la precede (PS = Previous Station), sia
quello della stazione Master che la segue (NS = Next Station)(Fig. 2.4).
Fig. 2.4 Esempio di gestione dei token
token
Master Stations ring logico
PS TS NS
Slave Stations
CAPITOLO II – I FIELDBUS E L’ARCHITETTURA PROFIBUS
21
Il ProFiBus è un bus di campo robusto, capace di gestire diversi stati, condizioni di errore o
eccezioni che possono presentarsi durante il normale funzionamento, tra le quali vi sono:
- presenza di token multipli nel bus;
- perdita del token;
- duplicazione degli indirizzi;
- presenza di stazioni malfunzionanti;
- aggiunta o eliminazione di stazioni dal bus;
Per quanto detto in precedenza, una stazione Master che riceve il token può accedere al bus
per scambiare messaggi con altre stazioni: tale scambio ciclico di messaggi è costituito da
frame di richiesta della stazione Master che possiede il token e da ack o frame di risposta da
parte di altre stazioni, Master o Slave; il ciclo viene interrotto solo quando la stazione Master
che possiede il token deve cederlo allo scadere del tempo a sua disposizione.
Le stazioni Slave e le Master che non posseggono il token stanno in ascolto sul bus e
rispondono alla stazione mittente solo quando sono esplicitamente indirizzate da una frame: la
risposta da parte della stazione indirizzata deve pervenire alla stazione mittente entro un certo
periodo di tempo detto “Slot Time”, superato il quale la stazione mittente ripeterà la richiesta
ovvero rispedirà una frame.
Da notare, comunque, che una qualunque richiesta, sia essa nuova o una ripetizione a causa di
un precedente fallimento, non può essere inoltrata rispetto alla precedente prima dello scadere
di un altro periodo di tempo detto “Idle Time”. Se dopo un certo numero prefissato di tentativi
la stazione destinataria non risponde alla richiesta, essa é marcata come “Non-Operational”:
i successivi tentativi di accedere ad essa verranno effettuati solo una volta senza ripetizioni
fino a quando non si avrà una risposta dalla stazione: a quel punto tutto riprenderà
normalmente.
Nel ProFiBus esistono sostanzialmente quattro modi trasmissivi:
Token handling;
Acyclic request or send/request operation;
Cyclic send/request operation;
Registration of station;
CAPITOLO II – I FIELDBUS E L’ARCHITETTURA PROFIBUS
22
Fig. 2.5 ProFiBus: esempio di rete
essi verranno ampiamente descritti nei paragrafi seguenti.
2.3.4.2 Token reception
Una stazione Master (TS) può trasmettere sul bus solo dopo aver ricevuto il token dalla
stazione Master registrata come PS (Previous Station) nella sua LAS (List of Active Station:
la lista di tutte le stazioni attive collegate al bus, creata all’atto dell’accensione della
stazione); se invece il token arriva da una stazione Master che non coincide con la PS, la
stazione ricevente (TS) presuppone che si sia verificato un errore di trasmissione e rifiuta il
token; qualora però, dopo il primo rifiuto, la stazione TS dovesse ricevere di nuovo il token
dalla stessa stazione, accetterebbe il token presupponendo che la topologia del ring logico sia
cambiata (pe. la stazione PS è guasta); in tal caso inoltre, la stazione TS dovrà anche
modificare la sua LAS per aggiornarla alla nuova condizione del ring (Fig. 2.5).
2.3.4.3 Token transmission
Quando una stazione Master (TS) che possiede il token termina la sua attività di accesso al
bus perché è scaduto il tempo a sua disposizione (THT = Token Holding Time) oppure perché
non ha altri messaggi da inviare, deve cedere il token alla stazione Master NS (Next Station) e
mettersi in ascolto sul bus per verificare che la trasmissione del token avvenga correttamente.
token
Master Stations
PS TS NS
CAPITOLO II – I FIELDBUS E L’ARCHITETTURA PROFIBUS
23
Infatti, per informare la stazione che la trasmissione ha avuto successo, la stazione Master
che riceve il token deve spedirle una frame. Può anche accadere che la frame ricevuta non sia
stata spedita dalla stazione NS: ciò vuol dire che un’altra stazione, e non la NS, si è
impossessata del token; in ogni caso, non appena ricevuta la frame, la stazione smette di stare
in ascolto sul bus. Un caso particolare si verifica, invece, quando la stazione TS dopo aver
spedito il token non riscontra nessuna attività sul bus per un periodo di tempo maggiore di un
intervallo prefissato detto Slot Time: in questo caso la stazione TS ripete la trasmissione del
token e attende, in ascolto sul bus, per un altro Slot Time; se in questo secondo Slot Time
viene riscontrata attività sul bus, la stazione TS finisce di stare in ascolto, altrimenti prova a
trasmettere il token alla stazione Master successiva alla NS; a questo punto si ripete il
procedimento precedente ossia, se la stazione TS riceve una frame smette di stare in ascolto
sul bus, altrimenti, trascorso lo Slot Time, riprova la trasmissione e così sia; se, infine, la
stazione TS è l’unica stazione Master presente sul bus, essa spedisce il token a se stessa fino a
quando non riesce a registrare un’altra stazione Master sul bus alla quale spedire il token.
2.3.4.4 Inserimento e rimozione di stazioni sul bus
Le stazioni Master e Slave possono essere rimosse o aggiunte al bus in qualunque
momento, fino ad un massimo complessivo di 127 stazioni. Gli indirizzi PS, NS e TS
contenuti nella LAS non sono consecutivi ma tra essi vi è un “GAP”, un intervallo di
indirizzi utili per l’inserimento di nuove stazioni: questi intervalli sono memorizzati in una
“GAP List” che però non contiene gli indirizzi compresi tra quello più grande e 127.
Ogni stazione Master possiede una GAP List e la gestione di quest’ultima avviene al
termine della trasmissione di tutti i messaggi ciclici, sempre che sia ancora possibile
mantenere il token, ovvero nell’ipotesi che la stazione Master sia riuscita a trasmettere tutti i
messaggi prima che il suo tempo di possesso del token sia scaduto.
CAPITOLO II – I FIELDBUS E L’ARCHITETTURA PROFIBUS
24
Se una stazione non riesce a gestire la sua GAP List durante l’intervallo di tempo in cui
possiede il token, provvederà a farlo al successivo arrivo del token subito dopo la trasmissione
di tutti i messaggi ad alta priorità.
L’aggiornamento della propria Gap List da parte di una stazione Master che ha ottenuto il
token consiste nell’interrogare tutte le stazioni connesse al bus, richiedendo a ciascuna di esse
una frame di ack opportuna contenente lo stato della stazione interrogata (p.e. “not ready”,
“Slave station” ecc.).
2.3.4.5 Inizializzazione del ring logico
L’inizializzazione del bus è necessaria ogni volta che una stazione Master, pronta ad
entrare nel ring, non riscontra nessuna attività sul bus per un intervallo di tempo prefissato: in
questa condizione la stazione Master genera il token, se ne appropria, ed avvia una fase di
polling delle stazioni collegate al bus spedendo a tutte una “Request FDL Status” (Richiesta
dello stato a livello Fieldbus Data Link) che permette di conoscere lo stato attuale delle
stazioni interrogate: se queste ultime rispondono alla richiesta precedente con una “Master
Station not ready” oppure con una “Slave station”, vengono inserite nella GAP List; la prima
stazione Master che risponde con una “ready to enter logical token ring” è registrata come NS
nella LAS e ad essa viene passato il token. Con questo procedimento la singola stazione
Master riesce a ricostruire un primo ring logico costituito da due stazioni che può
successivamente essere esteso con l’aggiunta di altre stazioni.
Nel caso in cui si perda il token nel bus e la LAS e la GAP List esistano ancora, piuttosto
che inizializzare il bus è necessario reinizializzarlo: in quest’ultimo caso la stazione con
l’indirizzo più basso genera il token, se ne appropria e comincia la sua normale trasmissione
ciclica dei messaggi fino a quando non scade il tempo a sua disposizione; finita la sua attività
di comunicazione, la stazione Master passa il token alla stazione successiva e tutto riprende
normalmente.
CAPITOLO II – I FIELDBUS E L’ARCHITETTURA PROFIBUS
25
2.3.4.6 Token Rotation Time e priorità dei messaggi
Quando una stazione Master riceve il token, essa comincia a misurare il “TRR” (Real
Rotation Time) rappresentante il tempo che intercorre tra l’istante in cui la stazione riceve il
token e quello in cui il token vìene ricevuto nuovamente dopo un intero giro del ring logico.
Un primo dimensionamento del sistema ProFiBus viene effettuato fissando il parametro
“TTR” (Target Rotation Time) che rappresenta il massimo valore del TRR che deve essere
misurato sul sistema e che dipende, in genere, dal numero di stazioni Master collegate al bus e
dalla durata della trasmissione dei messaggi ad alta priorità.
La differenza tra TTR e TRR prende il nome di “THT” (Token Holding Time) e rappresenta
appunto l’intervallo di tempo in cui una stazione Master possiede il token e può quindi
trasmettere i suoi messaggi: si noti comunque che, indipendentemente dal valore del TRR ,
ogni stazione Master deve avere sempre la possibilità, all’atto della ricezione del token, di
trasmettere un messaggio ad alta priorità e la relativa ripetizione in caso di errore; questo
meccanismo é implementato proprio per dare la possibilità a tutte le stazioni di segnalare
errori, guasti o allarmi che rappresentano appunto i messaggi a più alta priorità.
Per poter trasmettere più di un messaggio ad alta priorità ed eventualmente per trasmettere
anche messaggi a bassa priorità, una stazione Master deve registrare, all’istante in cui riceve il
token, un TRR minore del TTR, cioè deve avere a disposizione più tempo di quello minimo
stabilito in fase di progetto.
Ogni stazione Master che possiede il token comincia a trasmettere i messaggi ad alta priorità
e, solo se dopo la trasmissione di questi messaggi il THT è ancora positivo, passa alla
trasmissione di messaggi a bassa priorità o alla gestione della GAP List.
2.3.4.7 Modalità Send/Request ciclica ed aciclica
La modalità di trasmissione “Acyclic Send/Request” viene utilizzata ogni volta che
l’utente deve trasmettere o richiedere un dato (messaggio) in maniera asincrona: per far ciò
CAPITOLO II – I FIELDBUS E L’ARCHITETTURA PROFIBUS
26
l’utente inoltra una specifica richiesta al controller FDL che trasmetterà in modo aciclico i
dati che gli sono forniti.
Nel caso di “Cyclic Send/Request”, invece, la stazione Master che possiede il token
interroga ciclicamente le altre stazioni collegate al bus seguendo un ordine stabilito in una
lista detta “Poll List”. La gestione della Poll List (Poll Cycle) comincia dopo che sono stati
trasmessi tutti i messaggi ad alta priorità: quelli a bassa priorità possono essere trasmessi solo
se alla fine del Poll Cycle il THT è ancora positivo, cioè se la stazione può tenere ancora il
token.
Se il THT non è sufficiente per completare tutto il Poll Cycle, la Poll List viene divisa in
segmenti e ciascuno dei segmenti viene gestito in arrivi successivi del token: in ogni caso i
messaggi a bassa priorità potranno essere trasmessi solo alla fine del Poll Cycle, quindi è
necessario bilanciare opportunamente il sistema in modo da evitare che i messaggi a bassa
priorità non vengano mai trasmessi.
2.3.4.8 Registrazione di Stazioni
Questa modalità di trasmissione viene attivata tutte le volte in cui l’utente inoltra al
controller FDL la richiesta della Live List, cioè della lista di tutte le stazioni collegate al bus:
per ottenere la Live List il controller FDL indirizza con una “Request FDL Status” tutte le
stazioni agganciate al bus, con l’eccezione di quelle contenute nella LAS.
Alla fine, gli indirizzi di tutte le stazioni che hanno risposto correttamente e di tutte quelle
contenute nella LAS verranno memorizzati nella Live List.
27
CAPITOLO III
PROFIBUS PER LE ATTIVITA’ DI RICERCA DEL
GRUPPO C.H.I.C. DELL’INFN/LNS
3.1 INTRODUZIONE
I sistemi basati su tecnologia ProFiBus presentano caratteristiche di elevata flessibilità e
affidabilità che ben rispondono ai requisiti necessari per la realizzazione di una rete di
comunicazione dedicata all’integrazione di controlli remoti di supporto alle attività di ricerca
nel campo della fisica nucleare.
In questo capitolo vengono introdotte le applicazioni del ProFiBus messe a punto in seno alle
attività del gruppo di ricerca C.H.I.C. dei LABORATORI NAZIONALI DEL SUD di Catania
(I.N.F.N.) [20]: in particolare vengono presentate le caratteristiche del sito all’interno del
quale hanno luogo le attività di ricerca; di seguito verranno introdotte le due applicazioni di
controllo remoto affrontate mediante l’uso del ProFiBus; infine verranno descritte la topologia
della rete ProFiBus ivi realizzata e le caratteristiche tecniche dei componenti hardware e
software adottati per la realizzazione della rete.
CAPITOLO III- PROFIBUS PER LE ATTIVITA’ DI RICERCA DEL GRUPPO C.H.I.C. DELL’INFN/LNS
27
3.2 L’IMPIANTO PER GLI STUDI SULL’INTERFEROMETRIA
NUCLEARE
Fig. 3.1 Fotografia della Neutron Chamber all’interno della sala del fascio
La figura 3.1 mostra la struttura della “Neutron Chamber”, preposta allo studio di
particelle pesanti: questa struttura, in dotazione al gruppo di ricerca C.H.I.C., si trova
all’interno dei Laboratori Nazionali del Sud dell’ I.N.F.N. ed è costituita da una serie di
camere stagne, provviste di apposite feritoie di osservazione, all’interno delle quali
vengono svolti esperimenti di interferometria nucleare: sotto opportune condizioni di vuoto
spinto, un fascio di particelle ad alta energia viene deflesso e convogliato verso la camera a
neutroni mediante una struttura a guida elettromagnetica (si notino i grossi elettromagneti
a sinistra nella foto) provocando il bombardamento di apposite targhette dette “bersaglio”;
gli effetti delle collisioni vengono rilevati da appositi rivelatori (i cilindri neri nella foto) e
le misure vengono acquisite ed analizzate in una sala di acquisizione separata.
CAPITOLO III- PROFIBUS PER LE ATTIVITA’ DI RICERCA DEL GRUPPO C.H.I.C. DELL’INFN/LNS
28
I motivi per cui ci si è mossi verso la realizzazione di una rete a bus di campo ProFiBus
sono i seguenti:
- attualmente tutti gli azionamenti delle apparecchiature di supporto sono di tipo manuale
e localizzati vicino alla struttura;
- durante ogni esperimento la presenza di radiazioni nocive per l’uomo e l’ambiente
richiede la chiusura ermetica del plesso; qualunque intervento non previsto, causa
guasti o altro, richiede l’interruzione del fascio ed un periodo di attesa (qualche ora)
prima di consentire l’ingresso dei tecnici in condizioni di sicurezza;
- tutti i collegamenti dall’impianto verso la sala di acquisizione sono di tipo dedicato
punto-punto;
sotto queste condizioni l’impiego del ProFiBus porta ai vantaggi già enunciati nel
precedente capitolo e qui brevemente riassunti:
- possibilità di controllare in remoto qualunque dispositivo senza alcun intervento in
loco;
- riduzione dei cablaggi a seguito del convogliamento delle informazioni e dei comandi
di controllo e azionamento su di un unico bus che, estendendosi per tutto il perimetro
del sito, sostituisce tutti i collegamenti punto-punto;
- sicurezza intrinseca nel trasporto dei dati garantita dal supporto a doppino intrecciato
schermato e dalla codifica differenziale RS485 dei dati che insieme riducono gli effetti
dei disturbi di natura elettromagnetica;
- espandibilità della rete grazie alla possibilità di inserire moduli slave o altri dispositivi
compatibili in qualunque punto del bus;
Nei prossimi paragrafi vengono introdotte due applicazioni di controllo remoto che nel
corso di svolgimento di questo lavoro di tesi sono state affrontate mediante l’utilizzo del
ProFiBus.
CAPITOLO III- PROFIBUS PER LE ATTIVITA’ DI RICERCA DEL GRUPPO C.H.I.C. DELL’INFN/LNS
29
3.3 SISTEMA REMOTO DI MOVIMENTAZIONE
La prima applicazione di cui ci siamo occupati riguarda il controllo remoto di un
sistema di movimentazione a tre gradi di libertà per il posizionamento micrometrico di un
apparato (E.M.R.I.C.) costituito da 13 rivelatori di ioni pesanti allo ioduro di cesio: la Fig.
3.2.a mostra il sistema di movimentazione alloggiato all’interno della struttura sferica a
barre di Fig. 3.1, con sopra montato il sistema E.M.R.I.C. che si affaccia ad una finestra
della Neutron Chamber.
Fig. 3.2 Sistema di posizionamento
La Fig. 3.2.b mostra il modello 3D del sistema di posizionamento: esso è costituito da tre
guide lineari, ciascuna dotata di vite a ricircolo di sfere, disposte nelle tre direzioni
cartesiane; di esse, due sono del tipo a barra e sono disposte rispettivamente secondo le
direzioni orizzontali x e y, mentre il movimento nella direzione verticale z è realizzato
mediante una pedana sostenuta da quattro guide, anch’esse a vite.
a) b)
a
)
CAPITOLO III- PROFIBUS PER LE ATTIVITA’ DI RICERCA DEL GRUPPO C.H.I.C. DELL’INFN/LNS
30
Ogni guida è azionata da un motore elettrico di tipo brushless, dotato di encoder ad
impulsi in quadratura e di riduttore di giri; infine alle estremità di ogni guida sono presenti
degli opportuni finecorsa per il rilevamento della corsa massima.
Le tabelle 3.1 e 3.2 riassumono le caratteristiche dei componenti utilizzati:
L’apparato di movimentazione è corredato da un sistema di controllo dedicato: esso è
costituito da un backplane sul quale sono montate 3 schede di controllo, ciascuna utilizzante
un chip specializzato (HP HCTL-1100) per il controllo di motori elettrici in continua di tipo
brushless o passo passo.
La logica d’interfaccia del backplane fornisce 3 porte ad 8 bit il cui tipo ed uso è descritto
in tab. 3: di esse, la porta A , bidirezionale, è quella dedicata allo scambio dei dati da e
verso i registri dei chip di controllo, la porta B , di input, viene utilizzata per la lettura dei
finecorsa ed infine la porta C , di output, serve all’indirizzamento dei chip e per la
generazione dei segnali di sincronismo; i dettagli relativi al funzionamento ed alla
programmazione degli HCTL1100 controllers verranno ampiamente illustrati di seguito.
Motore N° impulsi x giro
Rapporto di riduzione
Alimentazione (V)
X 400 43 1 12
Y 400 43 1 24
Z 400 14 1 24
tab. 3.1
Guida Risoluzione (mm/giro vite)
X 5 Y 5 Z 0.25
tab. 3.2
Porta Tipo Uso
A I/O Dati, Registri B I Dati C O Sincronismo
tab. 3.3
Fig. 3.3 Struttura interna del sistema di controllo
CAPITOLO III- PROFIBUS PER LE ATTIVITA’ DI RICERCA DEL GRUPPO C.H.I.C. DELL’INFN/LNS
31
3.4 SISTEMA PER LA GENERAZIONE DEL VUOTO
Fig. 3.4 Camera a vuoto per lo sviluppo ed il test di rivelatori
La seconda applicazione di controllo remoto realizzata con l’ausilio dei sistemi ProFiBus
riguarda un sistema di supporto alla ricerca, per lo sviluppo e la calibrazione dei rivelatori
di particelle; nella Fig. 3.4 è rappresentato lo schema completo dell’impianto che si
compone di: una camera stagna, una pompa rotativa di pre-vuoto, una pompa turbo per la
creazione del vuoto spinto, uno strumento per la misura della pressione, due trasduttori di
pressione rispettivamente per valori compresi tra 110-3 1103 mbar (Pirani) e 110-9
CAPITOLO III- PROFIBUS PER LE ATTIVITA’ DI RICERCA DEL GRUPPO C.H.I.C. DELL’INFN/LNS
32
110-3 mbar (Penning), quattro elettrovalvole delle quali due per il rientro d’aria e due per
l’estrazione dell’aria dalla camera (pre-vuoto e alto vuoto).
Fig. 3.5 Schema della camera a vuoto per lo sviluppo ed il test di rivelatori
Si riportano di seguito gli obiettivi che si è inteso perseguire per le attività di controllo
remoto:
- monitoraggio e regolazione automatica della pressione interna alla camera sulla base di
un valore di target prefissato;
- possibilità di intervento a distanza su uno qualunque degli azionamenti ;
Valvola
alto vuoto
Valvola rientro
Turbo
Valvola di
rientro
Penning
Pirani
Lettore di
pressione
Turbo
Rotativa
Valvola
pre-vuoto
8888
CAPITOLO III- PROFIBUS PER LE ATTIVITA’ DI RICERCA DEL GRUPPO C.H.I.C. DELL’INFN/LNS
33
3.5 RETE PROFIBUS
Fig. 3.6 Rete ProFiBus
Il primo passo verso la realizzazione e l’integrazione dei controlli relativi alle applicazioni
introdotte è consistito nello sviluppo ed assemblaggio della rete ProFiBus secondo la
topologia di Fig. 3.6:dallo schema in figura si comprende come l’idea di principio preveda
l’uso di PLC ed unità slaves digitali per il controllo in locale, e di unità master di
supervisione per il controllo parametrico e l’acquisizione dati.
La struttura intrinsecamente modulare dell’architettura adottata consente l’espansione
progressiva del sistema con l’inserimento di nuovi moduli di comunicazione e controllo
senza dover modificare le componenti preesistenti.
CAPITOLO III- PROFIBUS PER LE ATTIVITA’ DI RICERCA DEL GRUPPO C.H.I.C. DELL’INFN/LNS
34
3.5.1 Applicom Communication Server
Il nodo nevralgico del controllo remoto sulla rete ProFiBus realizzata è costituito dalla
stazione master di supervisione e controllo parametrico: per realizzarla si è fatto uso di una
scheda Applicom PC1500PFB (Fig. 3.7) per PC IBM compatibile:
la scheda in figura costituisce una stazione di tipo Master su ProFiBus DP/FMS; il transfer
rate consentito va da un minimo di 9600 bps fino ad un massimo di 500 kbps ; il mezzo
utilizzato è un doppino schermato, specifico per questo tipo di applicazione.
Il software a corredo con la scheda mette a disposizione diversi tools per la configurazione
della rete, insieme alla libreria a collegamento dinamico applicom.dll contenente
l’interfaccia applicativa verso i processi utente.
Fig. 3.7 Applicom Communication Server
CAPITOLO III- PROFIBUS PER LE ATTIVITA’ DI RICERCA DEL GRUPPO C.H.I.C. DELL’INFN/LNS
35
3.5.1.1 Tool di configurazione PCCONF
Il sistema adoperato utilizza “PCCONF”, un adeguato tool per il setting dei parametri di
configurazione hardware, quali interrupts e indirizzo base di memoria, per l’immissione
dei parametri della rete e per la configurazione dei dispositivi , masters o slaves, presenti
sul bus.
Fig. 3.8 ProFiBus: parametri di rete
La Fig. 3.8 mostra la finestra per l’immissione dei parametri di rete: tra quelli che di più
influenzano le prestazioni della rete scorgiamo il Target Rotation Time già definito al
CAPITOLO III- PROFIBUS PER LE ATTIVITA’ DI RICERCA DEL GRUPPO C.H.I.C. DELL’INFN/LNS
36
Capitolo II, ed il Gap Update Factor consistente nel numero di rotazioni complete del
token che la stazione Master Applicom deve attendere prima di aggiornare la sua GAP
List.
Per maggiori dettagli sugli altri parametri di rete e sulla configurazione dei dispositivi di
campo rimandiamo a [22].
3.5.1.2 Applicom User Interface
L’interfaccia tra l’architettura di rete della stazione Applicom ed i processi utente viene
fornita per mezzo di una libreria a collegamento dinamico (Applicom.dll): essa mette a
disposizione tutta una serie di primitive per l’apertura delle sessioni di comunicazione e
per l’interscambio di dati ciclico e acliclico tra la stazione Master Applicom e gli altri
dispositivi connessi al bus; in Fig. 3.9 possiamo vedere l’elenco delle funzioni di lettura e
scrittura verso dispositivi DP presenti sul bus; in Fig. 3.10 possiamo vedere le analoghe
funzioni per il ProFiBus FMS.
Fig. 3.9 Funzioni di comunicazione ProFiBus DP
CAPITOLO III- PROFIBUS PER LE ATTIVITA’ DI RICERCA DEL GRUPPO C.H.I.C. DELL’INFN/LNS
37
Tra le funzioni speciali per la gestione delle comunicazioni ricordiamo la InitBus() e la
ExitBus() rispettivamente per l’apertura e la chiusura delle comunicazioni del task corrente.
Fig. 3.10 Funzioni di comunicazione ProFiBus FMS
3.5.2 ProFiBus DP Slaves
Fig. 3.11 16 bit I/O ProFiBus DP Module
CAPITOLO III- PROFIBUS PER LE ATTIVITA’ DI RICERCA DEL GRUPPO C.H.I.C. DELL’INFN/LNS
38
Per la soluzione ai problemi di controllo remoto introdotti ai paragrafi 3.3 e 3.4 si è
optato verso l’utilizzo di due moduli slave ProFiBus DP WeidMuller 16 bit Input / 16 bit
Output (Fig. 3.11) aventi le seguenti caratteristiche:
- 16 bit Input (Q1..Q16), 16 bit Output (I17..I32), singolarmente indirizzabili;
- logica di livello I/O industriale 0 24 V;
- protezione in uscita contro i corto-circuiti accidentali;
- alimentazione 24Vcc;
- intervallo di indirizzi da 0 99 settabili manualmente (finestre circolari in figura);
Moduli di questo tipo sono stati utilizzati per lo scambio di dati da e verso dispositivi di
trasduzione e/o controllo.
3.5.3 ProFiBus FMS PLC
Fig. 3.12 Fotografia del PLC SAIA PCD2
Per risolvere il problema del controllo remoto del sistema di test dei rivelatori di
particelle si è fatto uso di un PLC SAIA PCD 2 (Fig. 3.12) corredato di modulo di
comunicazione ProFiBus FMS PCD7.F700 e di due moduli da 8 bit PCD2.E110 e
CAPITOLO III- PROFIBUS PER LE ATTIVITA’ DI RICERCA DEL GRUPPO C.H.I.C. DELL’INFN/LNS
39
PCD2.A400 rispettivamente di input e di output ; riassumiamo di seguito le caratteristiche
principali del dispositivo:
- numero di ingressi/uscite: 8 moduli di ingresso/uscita in grado di gestire 64 ingressi/uscite
digitali oppure 8 moduli di ingresso/uscita analogici per un totale di 64 ingressi/uscite
analogiche;
- processore: 1 unità centrale (CPU) equipaggiata con microcontroller 68340;
- memoria utente: 32 KB di RAM base estendibile a 535 KB;
- flag: 8192 x 1 bit;
- registri dati: 4096 x 32 bit (non volatili);
- registri indice: 16 x 31 bit;
- temporizzatori/contatori: 1600;
- campo di conteggio/temporizzazione: 31 bit senza segno;
- base dei tempi: programmabile da 10ms a 10 s;
- formato dei dati: interi da –2-31 a +231-1; virgola mobile da –5.42101 x 10-20 a +9.22337 x 1018;
- interfacce di comunicazione: PGU/RS 232, RS422/485;
- collegamenti in rete: S-Bus, reti LAC, LAN1, MODBUS, PROFIBUS;
I dettagli relativi all’impiego ed alla programmazione del PLC verranno esposti di seguito.
CAPITOLO IV- CONTROLLO REMOTO DI POSIZIONE MEDIANTE PROFIBUS
40
CAPITOLO IV
CONTROLLO REMOTO DI POSIZIONE MEDIANTE
PROFIBUS
4.1 INTRODUZIONE
Fig. 4.1 Rete ProFiBus per il controllo remoto del sistema di posizionamento
Come già anticipato al paragrafo 3.3 del capitolo precedente, la prima applicazione della
rete ProFiBus riguarda il controllo remoto di un sistema elettromeccanico di posizionamento:
in Fig. 4.1 possiamo osservare una sezione della rete ProFibus relativa a questa applicazione,
si noti la stazione di supervisione contenente l’Applicom Master Board ed lo slave ProFiBus
dedicato alla scambio di dati tra la rete ed il sistema di controllo locale dei motori
dell’apparato di posizionamento; nel corso di questo capitolo verranno illustrate nel dettaglio
CAPITOLO IV- CONTROLLO REMOTO DI POSIZIONE MEDIANTE PROFIBUS
41
le varie fasi di sviluppo del controllo in questione con particolare attenzione verso l’utilizzo
della tecnologia ProFiBus.
Verranno analizzate le caratteristiche tecniche del sistema di movimentazione e del suo
apparato di controllo locale; si procederà verso la descrizione del progetto dell’interfaccia
elettronica d’accoppiamento tra un modulo slave ProFiBus di comunicazione ed il suddetto
sistema; di seguito saranno descritte le operazioni di accesso ai DSP controllers ed i relativi
cicli di lettura e scrittura; per concludere verrà analizzato il software di terminale remoto con
particolare riferimento alle procedure di programmazione dei controllers HCTL1100, gli
algoritmi di monitoraggio e supervisione, l’interfaccia grafica.
CAPITOLO IV- CONTROLLO REMOTO DI POSIZIONE MEDIANTE PROFIBUS
42
4.2 SISTEMA ELETTROMECCANICO DI POSIZIONAMENTO
Fig. 4.2 Fotografia del sistema di posizionamento
Considerando il sistema di posizionamento di Fig. 4.1 già descritto al paragrafo 3.3:
facciamo alcune considerazioni sui dati tecnici relativi agli accoppiamenti meccanici tra le
guide ed i relativi motori: dai dati delle tabelle 3.2 e 3.3 (Capitolo III) si deduce che per le
guide x ed y sono necessari 2 giri di vite per ottenere uno spostamento di 1 cm ossia, tenuto
conto del rapporto di riduzione di 43:1, 86 giri di alberino motore, equivalenti a 400x86 =
34400 impulsi motore per il medesimo spostamento; per il sistema di guida sull’asse z
abbiamo un passo di 0.25 mm/giro e quindi, tenendo conto del rapporto di riduzione di 14:1 e
dei 400 impulsi per giro motore, sono necessari 560 giri motore per 1 cm lineare, equivalenti
a 224000 impulsi motore.
CAPITOLO IV- CONTROLLO REMOTO DI POSIZIONE MEDIANTE PROFIBUS
43
4.3 SISTEMA DI CONTROLLO LOCALE
4.3.1 Struttura interna
La Fig. 4.2 mostra lo schema del sistema di controllo dei motori costituito da un backplane
sul quale sono inseriti tre DSP integrati HCTL1100 specializzati nel controllo di posizione e
velocità di motori in continua passo-passo e/o brushless; la logica di comunicazione del
backplane mette a disposizione 3 porte di comunicazione ad 8 bit per la selezione e la
programmazione dei controllers oltreché per la lettura degli stati dei finecorsa.
Il primo problema affrontato per il controllo in remoto dell’apparato è consistito nel ricavare
dalle uscite e dagli ingressi di uno slave le porte necessarie per la comunicazione col sistema
di controllo dei motori.
Porta Tipo Uso
A I/O Dati, Registri B I Dati C O Sincronismo
tab. 4.1
Fig. 4.3 Struttura interna del sistema di controllo
CAPITOLO IV- CONTROLLO REMOTO DI POSIZIONE MEDIANTE PROFIBUS
44
4.3.2 Interfaccia di conversione dei segnali
Gli slave Weidmuller adottati dispongono di 16 ingressi e 16 uscite digitali a 24 Vcc
indirizzabili singolarmente o a gruppi di 8 o 16 bit; è stato dunque necessario realizzare
un’opportuna scheda elettronica d’interfaccia per la conversione dei livelli dei segnali, da
24Vcc industriale a 5Vcc TTL e viceversa, e per l’opportuna combinazione di 8 bit d’ingresso
ed 8 bit d’uscita dello slave al fine di ottenere una porta bidirezionale.
Nelle figure 4.4.a e 4.4.b sono rappresentati gli schemi di principio per la conversione dei
livelli di segnale: nella prima, un opportuno partitore riduce di livello il segnale d’ingresso
mentre il buffer cmos 4050 provvede a disaccoppiare l’uscita dall’ingresso; nella seconda si fa
uso di un bus driver open-collector per elevare la tensione di ingresso ai valori d’uscita
necessari.
b) a)
Fig. 4.4
CAPITOLO IV- CONTROLLO REMOTO DI POSIZIONE MEDIANTE PROFIBUS
45
In Fig. 4.4 si può vedere il metodo con il quale si è ottenuta una porta bidirezionale ad 8 bit
accoppiando 8 ingressi e 8 uscite dello slave:
le uscite dello slave da Q1 a Q8 sono controllate da un buffer three state 74HC244; le uscite
three state sono elettricamente connesse sia agli ingressi I1..I8 dello slave che alle 8 linee
della porta A del controllore dei motori. Quando occorre effettuare una operazione di lettura,
le uscite del buffer vengono poste in stato di alta impedenza mentre, viceversa, quando si
vuole compiere una operazione di scrittura, le uscite del buffer vengono abilitate. Per ciò che
riguarda il segnale di controllo della direzione dei dati vedremo nei paragrafi seguenti come
esso venga ricavato da un bit della porta C.
Le tabelle 4.2 e 4.3 riportano rispettivamente le corrispondenze controllore slave e la
piedinatura del connettore d’interfaccia.
Fig. 4.4
Porta Controllore I/O Slave
A I17..I24 || Q1..Q8
B I25..I32 C Q9..Q16
tab. 4.2
Pin Descrizione Pin Descrizione
1 PortC6 15 PortB4 2 PortC4 16 PortB5 3 PortA0 17 PortB6 4 PortA1 18 PortB7 5 PortA2 19 PortC3 6 PortA3 20 PortC7 7 PortA4 21 PortC2 8 PortA5 22 PortC1 9 PortA6 23 PortC5
10 PortA7 24 PortC0 11 PortB0 25-30 NC 12 PortB1 31-32 GND 13 PortB2 33 +5Vcc 14 PortB3 34 +12Vcc
tab. 4.3
CAPITOLO IV- CONTROLLO REMOTO DI POSIZIONE MEDIANTE PROFIBUS
46
In Fig. 4.5 è rappresentato lo schematico della scheda d’interfaccia: a sinistra si notino le
porte dello slave e a destra il connettore per flat-cable del sistema di controllo dei motori.
La Fig. 4.6 mostra il contenuto del blocco PORTA.SCH: esso realizza la trasformazione degli
ingressi I17 - I24 (nella figura sono indicati con I0..I7) e delle uscite Q1 – Q8 (Q0..Q7 nella
figura) nella porta bidirezionale A0 – A7; si noti in essa la presenza del buffer three state per
l’accoppiamento uscite – ingressi e i sistemi di partitori resistivi per la conversione dei livelli
dei segnali.
CAPITOLO IV- CONTROLLO REMOTO DI POSIZIONE MEDIANTE PROFIBUS
47
Fig. 4.5 Schematico della scheda d’interfaccia
CAPITOLO IV- CONTROLLO REMOTO DI POSIZIONE MEDIANTE PROFIBUS
48
Fig. 4.7 Schematico conversione livelli Q8..Q15 ->C0..C7
Fig. 4.6 Schematico conversione Q0..Q7 e I0..I7 in A0..A7
CAPITOLO IV- CONTROLLO REMOTO DI POSIZIONE MEDIANTE PROFIBUS
49
Le figure 4.7 e 4.8 mostrano gli schematici per la trasformazione di Q9..Q16 (nella figura 4.7
sono indicati con Q8..Q15) in C0..C7 e di B0..B7 in I25..I32 (I8..I15 nella figura 4.8).
Fig. 3.8 Schematico conversione livelli I8..I15 ->B0..B7
Fig. 4.8 Schematico conversione livelli I8…I15 ->B0..B7
CAPITOLO IV- CONTROLLO REMOTO DI POSIZIONE MEDIANTE PROFIBUS
50
4.4 PROGRAMMAZIONE DEI CONTROLLERS HCTL 1100
L’accesso ai chip di controllo dei motori e ai loro registri viene effettuato attraverso uno
slave ProFiBus opportunamente configurato all’indirizzo di rete 2: ogni operazione verso i
controllori dei motori avviene quindi nella forma di una lettura o scrittura verso lo slave.
Nei prossimi paragrafi verranno analizzate le funzioni di comunicazione ProFiBus DP per il
trasferimento di dati tra la stazione di supervisione Applicom e lo slave sopra citato. Per
concludere saranno analizzate le sequenze di chiamate a queste funzioni che realizzano i cicli
di accesso ai registri dei controllers; per proseguire vedremo le procedure di posizionamento e
di inizializzazione del sistema.
4.4.1 Accesso allo slave
L’interfaccia processi utente del ProFiBus DP comprende diversi modi di funzionamento:
tra questi vi è il wait-mode consistente nel fatto che le funzioni di comunicazione che lo
implementano non restituiscono il controllo al processo chiamante fintantoché lo scambio di
dati e di acks non si è concluso.
Per la comunicazione tra la stazione di supervisione e lo slave di controllo sono state utilizzate
due funzioni wait-mode: writepackqbyte e readpackibyte ; in Fig. 4.12 si riassumono le due
funzioni assieme ai loro parametri.
CAPITOLO IV- CONTROLLO REMOTO DI POSIZIONE MEDIANTE PROFIBUS
51
void POut(char port, char val) { short int status, nchan = 0, nequip = 1, nbyte = 1; long int byte; switch (port) { case PORT_A: { byte = 0; break; } case PORT_C: { byte = 1; break; } default : return; } writepackqbyte(&nchan,&nequip,&nbyte,&byte,&val,&status); ProfiTst(status);
}
short status; /*** valore restituito dopo la chiamata: se 0 -> ok ***/ short nchan = 0; /*** canale applicom ***/ short nequip = 1; /*** riferimento allo slave ***/ short nbyte = 1; /*** numero di bytes scambiati ***/ long byte; /*** riferimento del byte; 0 = basso, 1 = alto ***/ writepackqbyte(&nchan,&nequip,&nbyte,&byte,&val,&status);
readpackqbyte(&nchan,&nequip,&nbyte,&byte,&val,&status);
Fig. 4.12
Fig. 4.13 Procedura di scrittura per le porte A e C
char PIn(char port) { short int status, nchan = 0, nequip = 1, nbyte = 1; long int byte; char val; switch (port) { case PORT_A: { byte = 0; break; } case PORT_B: { byte = 1; break; } default : return 0; } readpackibyte(&nchan,&nequip,&nbyte,&byte,&val,&status); ProfiTst(status);
}
Fig. 4.14 Procedura di lettura per le porte A e C
CAPITOLO IV- CONTROLLO REMOTO DI POSIZIONE MEDIANTE PROFIBUS
52
Le figure 4.14 e 4.15 mostrano le procedure base per l’accesso, in scrittura e lettura, alle
porte del sistema di controllo dei motori: si noti che l’operazione di scrittura riguarda solo le
porte A e C, in quanto B è di sola lettura, mentre l’operazione di lettura riguarda A e B; si
osservi inoltre che la selezione tra le porte avviene variando il valore del parametro byte,
quest’ultimo condizionato dal parametro di procedura port.
Le due procedure mostrate costituiscono i mattoni base per la realizzazione dei cicli di
accesso ai registri dei controllers HCTL 1100.
4.4.2 Accesso ai registri dei controllers HCTL 1100
L’accesso ai registri dei controllers HCTL1100 avviene con la generazione di una
sequenza opportuna di segnali di controllo e dati sulle tre porte A, B e C.
A tal proposito, la tabella 4.4 descrive i
segnali di controllo associati ai bits della
porta C; essa servirà per la comprensione
delle procedure che seguiranno e che
realizzano i cicli di accesso ai registri
degli HCTL controllers.
Bit porta C Segnale Attivo Descrizione
0 M0 Alto Motore 0 1 M1 Alto Motore 1 2 M2 Alto Motore 2 3 CS Alto Chip Select 4 RST Alto Reset 5 OE Basso Output Enable 6 ALE Basso Address Latch Enable 7 WR Basso Write Enable
tab. 4.4
void scrivi(char reg, char mot, char val) {
POut (PORT_C, mot + 0xe0); POut (PORT_A, reg); POut (PORT_C, mot + 0xa0); POut (PORT_C, mot + 0xe0); POut (PORT_A, val); POut (PORT_C, mot + 0xe8); POut (PORT_C, mot + 0x68); POut (PORT_C, mot + 0x60); POut (PORT_C, mot + 0xe0);
}
char leggi(char reg, char mot) {
char val; POut (PORT_C, mot + 0xe0); POut (PORT_A, reg); POut (PORT_C, mot + 0xa0); POut (PORT_C, mot + 0xe0); POut (PORT_C, mot + 0xe8); POut (PORT_C, mot + 0xe0); POut (PORT_C, mot + 0xc8); val = PIn (PORT_A); POut (PORT_C, mot + 0xe0); return val;
}
Fig. 4.15 Procedure di scrittura / lettura registri HCTL1100
CAPITOLO IV- CONTROLLO REMOTO DI POSIZIONE MEDIANTE PROFIBUS
53
La Fig. 4.15 mostra le procedure scrivi e leggi : esse hanno come parametri il numero del
motore (mot = 1,2 o 3) e l’indirizzo del registro al quale si vuole accedere; la procedura scrivi
richiede inoltre il dato da copiare sul registro desiderato.
Procederemo ora alla descrizione dei passi che compongono queste due ultime procedure; si
faccia riferimento alla tabella 4.4 per la comprensione del tipo di segnali di controllo generati
sulla porta C.
La procedura scrivi si compone dei seguenti passi:
selezione dell’HCTL: viene effettuata in ogni chiamata a POut ponendo in mot il valore
corrispondente al controller desiderato (1, 2 o 3); il valore aggiunto
0xE0 esadecimale nella prima e nell’ultima chiamata rende inattivi
gli altri segnali di controllo della porta C; si osservi che mot sta per
motore in quanto ad ogni motore è assegnato un controller HCTL;
selezione del registro: il registro desiderato viene selezionato ponendone l’indirizzo sulla
porta A (seconda chiamata a POut) e generando un impulso attivo
basso sul segnale di controllo ALE (bit 6 di C) mediante due
successive chiamate a POut (terza e quarta chiamata);
scrittura del dato: viene effettuata ponendo il dato sulla porta A e, di seguito,
attivando e disattivando i segnali CS e WR (ultime quattro
chiamate a POut).
CAPITOLO IV- CONTROLLO REMOTO DI POSIZIONE MEDIANTE PROFIBUS
54
Vediamo di seguito i passi essenziali della procedura leggi:
selezione dell’HCTL: anche qui, la selezione del chip di controllo avviene specificandone
l’indirizzo (1, 2 o 3) nel parametro mot in ogni chiamata a POut;
selezione del registro: già descritta nella procedura scrivi;
lettura del dato: viene fatta generando un impulso attivo basso di CS e OE,
mantenendo alto WR, e prelevando il dato dalla porta A (ultime tre
righe della procedura leggi).
4.4.3 INIZIALIZZAZIONE DEGLI HCTL 1100
L’inizializzazione di ogni controller HCTL1100 avviene in due passi: reset del controller e
caricamento dei registri con i valori di controllo (velocità max, poli, zeri ecc.); nei prossimi
due paragrafi saranno analizzate nel dettaglio queste due operazioni.
4.4.3.1 Reset
Si osservi la Fig. 4.16: il reset di ogni HCTL 1100 avviene generando un impulso attivo
alto del segnale di controllo RST (RST: bit 4 della porta C) dopo aver opportunamente
selezionato il controller desiderato mediante i tre bit meno significativi di C (parametro mot
= mot1,mot2,mot3); ciò viene effettuato con le tre chiamate in figura alla procedura Pout
Fig. 4.16 Procedura di Reset
void RstHctl(char mot) { POut (PORT_C, mot); POut (PORT_C, mot + 16); POut (PORT_C, mot);
}
CAPITOLO IV- CONTROLLO REMOTO DI POSIZIONE MEDIANTE PROFIBUS
55
4.4.3.1 Caricamento dei registri
La procedura di caricamento consiste in una serie di chiamate alla procedura scrivi per il
settaggio dei registri che regolano il comportamento di ogni chip di controllo; tralasciando il
commento al codice corrispondente, poniamo attenzione sui registri coinvolti e sulla loro
funzione:
dinamica del controllo: è regolata dai primi tre registri in tab. 4.5, i quali fissano
rispettivamente lo zero, il polo ed il guadagno della rete di
compensazione che ogni controller inserisce nel proprio loop
di retroazione; i valori prescelti per tali registri sono stati
ottenuti empiricamente, sulla base di stime e prove di
laboratorio reiterate;
settaggi di posizione: riguardano i registri da &H29 a &H2A; essi contengono la
posizione alla quale il motore controllato si porterebbe se si
desse all’HCTL il comando di start; essi vengono
inizializzati a zero;
accelerazione e velocità: sono gli ultimi tre registri in tabella; i primi due determinano
l’accelerazione allo start e la decelerazione in fase di
raggiungimento della posizione finale; l’ultimo fissa invece la
velocità massima intermedia; le discrepanze tra i valori di
questi registri per i tre chip di controllo sono giustificate dalla
necessità di dover compensare le differenti caratteristiche dei
tre motori, dei loro riduttori, e dei passi delle loro guide.
Registro Descrizione HCTL1 HCTL2 HCTL3
&H20 Filter zero 120 120 120 &H21 Filter pole 40 40 40 &H22 Gain 195 195 195 &H29 Final Position (LSB) 0 0 0 &H2A Final Position 0 0 0 &H2B Final Position (MSB) 0 0 0 &H26 Acceleration (LSB) 0 0 0 &H27 Acceleration (MSB) 5 5 10 &H28 Maximum Velocity 25 30 30
tab. 4.5
CAPITOLO IV- CONTROLLO REMOTO DI POSIZIONE MEDIANTE PROFIBUS
56
4.5 PROCEDURE DI SUPPORTO AL CONTROLLO
Inizializzati i chip di controllo dei motori, si deve procedere alla calibrazione del sistema di
posizionamento; prima di illustrare quest’ultima fase descriviamo di seguito tre procedure
essenziali: una riguarda l’attivazione del controllo di posizione e velocità per uno dei tre chip
di controllo, un’altra riguarda la lettura della posizione corrente e la terza invece riguarda la
lettura dello stato dei finecorsa.
4.5.1 Lettura dello stato dei finecorsa
La lettura dello stato dei finecorsa relativi ad una direzione di spostamento ha il fine di
verificare il raggiungimento o meno di uno dei due limiti di estensione della guida: tale lettura
si effettua ponendo l’indirizzo del motore sulla porta C ed eseguendo un ciclo di attivazione
del segnale CS , durante il quale si legge l’informazione desiderata dalla porta B.
I bits 0 e 1 del dato letto dalla porta B riportano rispettivamente gli stati dei finecorsa
appartenenti alla guida selezionata con mot : 0 equivale a finecorsa raggiunto, 1 il contrario.
BYTE FinecorsaTst(char mot) { BYTE finec; POut(PORT_C, mot + 0xe8); finec = PIn(PORT_B) & 3; POut (PORT_C, mot + 0xe0); return finec;
}
Fig. 4.17 Test Finecorsa
CAPITOLO IV- CONTROLLO REMOTO DI POSIZIONE MEDIANTE PROFIBUS
57
4.5.2 Controllo di posizione e velocità
L’HCTL1100 prevede diversi modi di funzionamento:
1. Position Control;
2. Proportional Velocity Control;
3. Integral Velocity Control;
4. Trapezoidal Profile Control.
Tralasciando i dettagli relativi ai primi tre modi di controllo, verrà analizzato il Controllo a
Profilo Trapezoidale, utilizzato nell’applicazione.
4.5.2.1 Controllo a Profilo Trapezoidale
E’ uno dei modi di controllo di posizione e di velocità implementati dall’HCTL 1100, con
la caratteristica di imporre alla velocità un profilo di variazione triangolare o trapezoidale;
una volta impostata la posizione finale, la velocità massima e l’accelerazione nei rispettivi
registri, basta attivare questo modo di controllo perché l’HCTL 1100 calcoli automaticamente
la progressione della velocità ed il relativo profilo; se la velocità massima viene raggiunta
prima di metà della distanza da percorrere, il profilo sarà trapezoidale, altrimenti sarà
triangolare.
Max. Velocity
Accel Accel
Velocity
Trapezoidal
Max. Velocity
Accel Accel
Velocity
Triangular
Fig. 4.18 Controllo mediante profilo trapezoidale
a) b)
CAPITOLO IV- CONTROLLO REMOTO DI POSIZIONE MEDIANTE PROFIBUS
58
Bit Funzione
0 AD0 1 AD1 2 AD2 3 set/clear 4 - 5 - 6 - 7 -
tab. 4.6
4.5.2.2 Procedura di posizionamento
Il modo di funzionamento dell’HCTL 1100 è condizionato particolarmente dal contenuto
di due suoi registri: il Program Counter (&H05) ed il Flag Register (&H00).
Il Program Counter comanda l’attivazione di una delle seguenti quattro funzioni
preprogrammate:
Software Reset (valore d’attivazione 00H);
Initialization/Idle mode (valore d’attivazione 01H);
Align mode (valore d’attivazione 02H);
Control modes (valore d’attivazione 03H);
l’ultima funzione porta l’HCTL 1100 nello stato di controllo; il modo di controllo viene
fissato dal contenuto del Flag Register ; la tabella 4.6 mostra i bit di quest’ultimo assieme alla
loro funzione: i tre bit meno significativi formano l’indirizzo del flag referenziato mentre il bit
seguente specifica l’operazione da compiere sul flag (1 = set, 0 = clear); dei flag indirizzabili,
quello che riguarda il modo di controllo a profilo trapezoidale è il flag F0; l’attivazione di
questo flag, previo caricamento del Program Counter col valore corrispondente a Control
Modes (03H) provoca l’avvio del ciclo di controllo.
CAPITOLO IV- CONTROLLO REMOTO DI POSIZIONE MEDIANTE PROFIBUS
59
Siamo ora in grado di analizzare la procedura di posizionamento (Fig. 4.19):
il parametro val contiene un intero con segno a 24 bit rappresentante la posizione finale del
motore (specificato da mot) in termini di impulsi (400 impulsi = 1 giro motore); tale valore
deve essere ripartito ed inserito nei tre registri &H29, &H2A, &H2b; inoltre si deve portare
l’HCTL nello stato di controllo ponendo il valore 03H nel Program Counter (&H05); infine
per avviare il controllo è sufficiente attivare il flag 0 scrivendo il valore 08H nel Flag
Register (AD0 = AD1 = AD2 = 0; set/clear = 1).
Fig. 4.19 Procedura di Posizionamento
void Posiz(char mot, int val) { BYTE vh,vm,vl; if(val<0) val += 16777215; vl = val & 0xff; vm = (val & 0xff00)>>8; vh = (val & 0xff0000)>>16; scrivi(0x2B, mot, vh); scrivi(0x2A, mot, vm); scrivi(0x29, mot, vl); scrivi(0x5, mot, 3); scrivi(0x0, mot, 8); }
CAPITOLO IV- CONTROLLO REMOTO DI POSIZIONE MEDIANTE PROFIBUS
60
4.5.2.3 Procedura di lettura della posizione corrente
La procedura per la lettura della posizione corrente (Fig. 4.20) preleva il contenuto di tre
registri appositi dell’HCTL 1100 (&H12-&H14) e ricompone un intero con segno a 24 bit
rappresentante la posizione del motore mot espressa in numero di impulsi motore ( 1 giro =
400 impulsi).
int LeggiPosiz(char mot) { int pos = 0; BYTE vl = leggi(0x14,mot); BYTE vm = leggi(0x13,mot); BYTE vh = leggi(0x12,mot); pos = vl + (vm<<8) + (vh<<16); if (vh>0x80) pos - =16777216; return pos; }
Fig. 4.20 Procedura di lettura della posizione corrente
CAPITOLO IV- CONTROLLO REMOTO DI POSIZIONE MEDIANTE PROFIBUS
61
4.6 CALIBRAZIONE DEL SISTEMA DI POSIZIONAMENTO
Terminata la fase di Reset e di Inizializzazione dei registri di ogni chip di controllo, il
sistema di posizionamento è ancora in uno stato improprio poiché non sono note le posizioni
assolute delle guide lineari: è necessaria una fase di calibrazione del sistema meccanico per la
ricerca delle posizioni di massima estensione e di quelle d’equilibrio.
La Fig. 4.20 mostra il diagramma di flusso relativo all’operazione di calibrazione relativa
ad un solo motore (l’operazione va eseguita per tutti e tre i motori contemporaneamente):
essa comincia con una chiamata alla procedura RstHctl() (par. 4.4.3.1) per il reset hardware
del controller; segue poi il caricamento dei registri con i valori di controllo opportuni (filtro di
compensazione, posizione iniziale e finale, velocità massima, accelerazione ecc.); segue poi
Fig. 4.21 Flow Chart della Calibrazione
CAPITOLO IV- CONTROLLO REMOTO DI POSIZIONE MEDIANTE PROFIBUS
62
una chiamata alla procedura Posiz() (par. 4.5.2.2) passandole un valore di posizione finale
sufficientemente alto da spingere il cursore mobile oltre l’estensione stessa della guida;
quando il cursore della guida lineare raggiunge uno dei due finecorsa, il controllore arresta
automaticamente il motore; il primo test in figura cicla sulla procedura FinecorsaTst() e,
quando rileva l’attivazione del finecorsa opportuno, forza l’esecuzione di una nuova
inizializzazione dell’HCTL 1100 (RstHctl() e LoadDefVal()); ogni reset comporta
l’azzeramento dei registri contenenti la posizione corrente, dunque in questa fase la posizione
corrente è pari a zero; a questo punto si esegue una nuova chiamata a Posiz() al fine di
spostare il cursore nella direzione opposta, esattamente a metà della estensione della guida
(posizione d’equilibrio; la tabella 4.7 riporta i valori di tali spostamenti per ognuna delle tre
guide); quando lo spostamento è ultimato si esegue nuovamente il reset ed il settaggio dei
registri; a questo punto il cursore mobile è esattamente a centro guida e la posizione corrente è
pari a zero; qualunque spostamento assoluto d’ora in poi sarà relativo a questo punto d’origine
o equilibrio.
Spostamento Impulsi Centimetri
X 498800 14.5 Y 498800 14.5 Z 2811200 12.55
tab. 4.7
CAPITOLO IV- CONTROLLO REMOTO DI POSIZIONE MEDIANTE PROFIBUS
63
4.7 INTERFACCIA UTENTE DEL TERMINALE DI CONTROLLO REMOTO
Dopo aver visto la porzione di software che si occupa specificatamente della gestione del
sistema di controllo locale dell’apparato di movimentazione, occupiamoci adesso
dell’interfaccia utente del terminale remoto: essa è stata sviluppata col supporto del
compilatore Microsoft Visual C++ 5.0 secondo l’architettura Documento-Vista di MFC 4.2;
analizziamo di seguito gli elementi essenziali dell’interfaccia facendo riferimento alla Fig.
4.22.
Fig. 4.22 Interfaccia Utente
CAPITOLO IV- CONTROLLO REMOTO DI POSIZIONE MEDIANTE PROFIBUS
64
- Sistema di output grafico tridimensionale: al centro della finestra è presente il modello
tridimensionale del sistema di posizionamento, il quale ha la funzione di restituire in
tempo reale lo stato del sistema durante le fasi di inizializzazione e posizionamento;
assieme ad esso sono presenti una terna di assi cartesiani ortogonali per il riferimento
delle direzioni di spostamento, ed una finestra quadrata contrassegnata da una freccia
uscente stante ad indicare la direzione del fascio di particelle. Il sistema viene aggiornato
in tempo reale durante ogni cambiamento di posizione; inoltre le caselle sulla barra di
stato in basso a destra forniscono, anch’esse in tempo reale, i valori delle coordinate x, y
e z della posizione corrente.
- Barra degli strumenti: contiene gli strumenti per la personalizzazione dell’output
grafico;
- comandi per la rotazione l’angolo di vista attorno al sistema di guide;
- comando di visualizzazione degli assi di riferimento;
- comandi per lo scrolling verticale;
- comandi per la funzione di zoom;
- controllo a tendina per la scelta del parametro da regolare col cursore
adiacente;
- cursore per la regolazione del parametro selezionato col controllo a
tendina;
CAPITOLO IV- CONTROLLO REMOTO DI POSIZIONE MEDIANTE PROFIBUS
65
- Barra di comando: contiene i seguenti pulsanti di comando
Nel prossimo paragrafo verrà introdotta la finestra di dialogo per l’immissione dei comandi
di controllo del sistema di posizionamento.
4.7.1 Finestra per il controllo di posizione
La Fig. 4.23 mostra la finestra di comando della posizione così come appare durante
un’operazione di posizionamento; esaminiamo di seguito gli elementi essenziali che la
caratterizzano.
- attiva la finestra di comando posizione;
- attiva la finestra per il controllo remoto del sistema di generazione
del vuoto (Capitolo V);
- attiva la finestra delle informazioni.
Fig. 4.23 Finestra di Comando Posizione
CAPITOLO IV- CONTROLLO REMOTO DI POSIZIONE MEDIANTE PROFIBUS
66
Pulsante Init: avvia la fase di calibrazione già vista al paragrafo 4.6;
Pulsante Set: chiama la procedura Posiz() per ogni motore passando i valori
specificati nelle caselle delle coordinate target;
Caselle x-y-z: consentono l’immissione delle coordinate target;
Pulsante Stop: funzione d’emergenza; effettua tre chiamate a RstHctl() per i tre
motori, dopodiché il sistema dovrà essere reinizializzato;
Pulsante Save: salva la posizione target col nome specificato nel menu a tendina
List; la posizione salvata potrà essere recuperata dal medesimo
menù;
Pulsante Del: cancella il target selezionato sul menu List dal file interno;
Menu List: consente l’immissione di nomi simbolici per il salvataggio del
target corrente grazie all’uso combinato del pulsante Save;
permette inoltre la selezione di targets precedentemente salvati;
Video: indicano il tipo di attività in corso; gli ingranaggi in moto
indicano che almeno uno dei motori è in funzione; l’apparire del
computer che trasmette bit indica una attività corrente di
trasmissione di dati verso i controllers;
Progressione: tre barre di progressione indicano, per ciascuna guida, il grado di
avanzamento verso la posizione target richiesta.
66
CAPITOLO V
CONTROLLO REMOTO DEL VUOTO MEDIANTE
PROFIBUS
5.1 INTRODUZIONE
La Fig. 5.1 mostra la porzione di rete ProFiBus dedicata al controllo del sistema del vuoto
presentato al par.3.4 del Capitolo III ; in essa possiamo notare la stazione di supervisione
Fig. 5.1 Rete Profibus per il controllo del sistema del vuoto
CAPITOLO V- CONTROLLO REMOTO DEL VUOTO MEDIANTE PROFIBUS
67
Applicom per il controllo remoto parametrico, il PLC Saia-Burgess [23] per il controllo locale
del sistema di vuoto ed un secondo slave che, come vedremo nei prossimi paragrafi, viene
utilizzato per l’acquisizione delle misure di pressione.
Obiettivo di questa applicazione del ProFiBus è il controllo remoto della pressione interna
della camera di test in Fig. 5.2 (riproponiamo per comodità la figura già vista al paragrafo
3.4).
Per far ciò, il controllore locale (PLC) deve ricevere informazioni dalla stazione di
supervisione sul tipo di controllo da effettuare (manuale o automatico) e, nel caso di controllo
automatico, sul valore target di pressione da imporre; sulla base di queste ultime informazioni,
PLC dovrà eseguire le corrette sequenze temporali di attivazione delle pompe e delle
elettrovalvole al fine di imporre all’interno della camera, il valore di pressione target richiesto.
Valvola
alto vuoto
Valvola rientro
Turbo
Valvola di
rientro
Penning
Pirani
Lettore di
pressione
Turbo
Rotativa
Valvola
pre-vuoto
8888
Fig. 5.2 Sistema per la generazione del vuoto
CAPITOLO V- CONTROLLO REMOTO DEL VUOTO MEDIANTE PROFIBUS
68
Nei prossimi paragrafi introdurremo dapprima l’architettura distribuita utilizzata per questo
tipo di controllo; seguirà poi una descrizione relativa ai trasduttori di pressione utilizzati ed al
tipo di segnale da essi restituito; proseguiremo ancora con una descrizione relativa al progetto
della scheda per l’acquisizione delle misure di pressione, ed al suo interfacciamento con la
rete ProFiBus; verranno poi forniti i dettagli relativi alla configurazione del PLC sulla rete
ProFiBus, al suo utilizzo mediante programmazione in linguaggio Ladder ed alle primitive di
comunicazione ProFiBus FMS per l’interscambio di dati tra la stazione Applicom ed il PLC;
per concludere si darà visione del software d’interfaccia utente del terminale remoto,
descrivendone il funzionamento e la struttura interna.
CAPITOLO V- CONTROLLO REMOTO DEL VUOTO MEDIANTE PROFIBUS
69
5.2 ARCHITETTURA DI CONTROLLO DISTRIBUITA
La Fig. 5.3 mostra l’architettura adottata per la realizzazione del controllo in remoto del
sistema di vuoto: una scheda di acquisizione converte le misure analogiche di pressione in
dati binari che passa allo slave unit 2; la stazione di supervisione Applicom (Master Unit 1)
assolve la funzione di fornire al PLC la misura attuale di pressione e per far ciò scandisce
ciclicamente lo slave unit 2 (periodo di scansione = 100 ms), trasforma le misure dal formato
binario a valori corrispondenti di pressione nel formato a virgola mobile, esegue un algoritmo
di filtraggio per eliminare il rumore di misura, e trasmette il valore ottenuto al PLC; quando
viene attivata la modalità automatica di controllo, il PLC utilizza l’informazione di pressione
corrente ottenuta dalla Master Unit 1, assieme al valore target desiderato, per applicare il suo
algoritmo di controllo sugli attuatori e regolare di conseguenza la pressione interna alla
camera.
INT Data-Pressure
FP Data-Pressure
Master Unit1
PLC
Slave Unit 2
Control Workstation
Master Unit2
Digital I/O Module
Fig. 5.3 Architettura distribuita per il controllo del vuoto
CAPITOLO V- CONTROLLO REMOTO DEL VUOTO MEDIANTE PROFIBUS
70
Nome Sigla Casa costruttrice
Range di funzionamento (mbar)
Pirani TPR 010 Balzers 10-4103
Penning IKR020 Balzers 10-910-3
tab. 5.1
5.3 ACQUISIZIONE DELLE MISURE DI PRESSIONE
5.3.1 Misure analogiche di pressione
La misura della pressione all’interno della camera è affidata a due trasduttori appositi,
differenziati per gli intervalli di utilizzo; la tab. 5.1 riporta i dati ad essi relativi, mentre le
figure 5.4.a e 5.4.b mostrano le rispettive caratteristiche Pressione – Tensione.
Un ulteriore strumento, il Balzers TPG 300, alimenta opportunamente i due trasduttori, offre
un meccanismo di protezione da contaminazioni per il Penning, e visualizza la pressione
corrente su di un display (lettura locale); inoltre mette a disposizione le uscite analogiche dei
due trasduttori (Fig.5.5); é compito dell’unità che effettua il polling di queste uscite convertire
i valori di tensione in misure di pressione, sulla base delle caratteristiche note, oltreché
b)
a)
Fig. 5.4 Caratteristiche Pressione-Tensione
CAPITOLO V- CONTROLLO REMOTO DEL VUOTO MEDIANTE PROFIBUS
71
stabilire quale dei due trasduttori stia misurando correttamente e quale sia invece in stato di
underrange o di overrange.
Fig. 5.5 TPG300 Analog Output
CAPITOLO V- CONTROLLO REMOTO DEL VUOTO MEDIANTE PROFIBUS
72
5.3.2 Conversione dei segnali
La figura 5.6.a mostra il cassetto contenente la scheda di conversione analogico/digitale
realizzata per l’acquisizione delle misure di pressione: è una scheda ad 8 bit lineare, a due
canali, provvista di ingresso di selezione ed uscite di livello logico industriale 0-24 Vcc. La
figura 5.6.b mostra in dettaglio la maschera frontale del cassetto: in essa sono presenti un
display a 10 barre led per la visualizzazione della conversione binaria corrente (1), due led
per la visualizzazione del trasduttore selezionato (2 , led verde = Pirani, led giallo =
Penning), un connettore a 9 poli per le uscite digitali (3), due connettori Lemo a tre e a due
poli rispettivamente per gli ingressi analogici (4) e per la selezione del canale d’ingresso (5).
Fig. 5.6 Scheda per la conversione A/D
b) a)
1
2
3
4
5
CAPITOLO V- CONTROLLO REMOTO DEL VUOTO MEDIANTE PROFIBUS
73
Vediamo di seguito lo schematico del circuito di conversione.
Fig. 5.7 Schematico del circuito di conversione A/D
CAPITOLO V- CONTROLLO REMOTO DEL VUOTO MEDIANTE PROFIBUS
74
La Fig. 5.7 mostra lo schematico del circuito di conversione: il componente centrale di tutta la
scheda è il convertitore ADC0804 (per maggiori dettagli consultare i National DataBooks) ad
8 bit, convertitore (U2 sullo schematico) ad approssimazioni successive con un tempo di
conversione pari a 100 s, configurato per funzionare in free-running mode, ossia in
conversione continua (CS a massa e uscita INTR collegata all’ingresso WR); la risoluzione
offerta è sufficiente a coprire le caratteristiche di Fig. 5.4; in esse infatti notiamo in tutto
cinque grossi intervalli di tensione-pressione più altri due più piccoli agli estremi delle
caratteristiche; in ogni intervallo, supponendoli di pari ampiezza, ricadono circa 256/7 36
livelli discreti di quantizzazione; poiché ad ogni intervallo corrisponde un ordine di grandezza
di pressione, all’interno di ciascuno di essi abbiamo una precisione di circa 10/36 = 0.27 , più
che sufficiente per il tipo di precisione richiesta da questa applicazione; effettivamente tale
precisione, se è maggiore al centro delle caratteristiche, diminuisce agli estremi a causa della
contrazione degli intervalli, ma ciò non costituisce un problema poiché la parte inferiore della
caratteristica a) (associata al Pirani) compresa tra 10-4 e 10-3 mbar è sovrapposta alla
caratteristica b) del Penning, che presenta un intervallo corrispondente di tensione più ampio,
ed è quest’ultima caratteristica che si usa a questi valori di pressione; inoltre l’intervallo tra
102 e 103 mbar, che nella caratteristica a) risulta essere abbastanza stretto, non ha di fatto
utilità sperimentale per il tipo di attività di test svolte all’interno della camera; infine, la
pompa a turbina non è in grado di raggiungere i 10-910-8 mbar, intervallo in corrispondenza
del quale la caratteristica b) si contrae.
La tensione di riferimento del convertitore è pari a +5Vcc e poiché i segnali forniti dai
trasduttori hanno una escursione massima di 10 V, é necessario dimezzare il segnale in
ingresso al convertitore per mezzo del circuito costituito dagli amplificatori operazionali
U1A e U1B.
La selezione dell’ingresso avviene per mezzo dello scambiatore analogico di precisione
MAX319CPA (U5) controllato dall’ingresso di selezione CHSEL, mentre l’uscita in formato
CAPITOLO V- CONTROLLO REMOTO DEL VUOTO MEDIANTE PROFIBUS
75
binario ad 8 bit è controllata da U8 e U9 (74LS07), i quali trasformano i livelli del dato
binario, in uscita dal convertitore, dalla logica TTL (+5Vcc) a quella industriale a (+24Vcc).
Infine l’integrato U6 (74LS244) provvede a pilotare il display a barre D1 per la
visualizzazione del dato binario di conversione.
5.3.3 Acquisizione dei dati
Come abbiamo già visto al par. 5.2, il modulo di conversione è interfacciato con la rete
ProFiBus per mezzo di un modulo slave WeidMuller locato all’indirizzo fisico 3: l’uscita Q1
comanda l’ingresso di selezione del modulo di campionamento, mentre gli ingressi I17-I24
prelevano il dato binario in uscita dal medesimo modulo.
La figura 5.8 mostra il codice della procedura GetMediaSample(): essa preleva in
successione samp_w campioni di pressione dallo slave di indirizzo 3, e ne restituisce il valore
medio; il valore intero ottenuto viene convertito in un valore corrispondente di pressione
attraverso due tabelle (Fig. 5.9) di 256 costanti in virgola mobile, una per ogni trasduttore di
pressione; i valori in esse immagazzinati sono stati ottenuti per interpolazione delle
caratteristiche pressione-tensione dei due trasduttori, e verificati per mezzo di misure
sperimentali.
CAPITOLO V- CONTROLLO REMOTO DEL VUOTO MEDIANTE PROFIBUS
76
Le procedure appena viste costituiscono il supporto base per l’acquisizione delle misure di
pressione; vediamo ora di seguito la procedura OnTimer() che si occupa del campionamento
periodico degli ingressi del modulo slave di indirizzo 3.
unsigned char GetMediaSample(const int samp_w) { int i; short int status, nchan = 0, nequip = 3, nbyte = 1; long int byte = 0; char val ; unsigned long int sum; sum = 0; for (i = 0; i<samp_w; i++) {
readpackibyte(&nchan,&nequip,&nbyte,&byte,&val,&status);
sum += (unsigned char) val; } return (sum / samp_w); } Fig. 5.8 Procedura per il filtraggio delle misure di pressione
float m_pir_tab[256]; // tabella valori press. pirani float m_pen_tab[256]; // tabella valori press. penning void LoadPressVal(float *tab,BYTE valtype) // 0 = pir, 1 = penn { FILE * myfile; if (valtype) myfile = fopen("Pen.map","rt"); else myfile = fopen("Pir.map","rt"); float tempval; for(int i = 0; i<256; i++) { fscanf(myfile,"%e",&tempval); tab[i] = tempval; } fclose(myfile); }
Fig. 5.9 Procedura per l’inizializzazione delle tabelle di pressione
CAPITOLO V- CONTROLLO REMOTO DEL VUOTO MEDIANTE PROFIBUS
77
void OnTimer (UINT nTimerID) { if (nTimerID == PRESSTIMER) { const int samp_w = 20; short int status, nchan = 0, nequip = 3, nbyte = 1, bit; long int byte = 0; unsigned char val ; float fval; if (m_flag_head < 0) { bit = 0; writepackqbit(&nchan,&nequip,&nbyte,&byte,&bit,&status); m_flag_head = 0; } /*** get media samples ***/ val = GetMediaSample(samp_w); if (!m_flag_head) fval = m_pir_tab[val]; else fval = m_pen_tab[val]; /*** test per passaggio pirani-penning ***/ if((val == 0)&&(m_flag_head == 0)) { bit = 1; writepackqbit(&nchan,&nequip,&nbyte,&byte,&bit,&status); val = GetMediaSample(samp_w); if (val<255) { m_flag_head = 1; } else { bit = 0; writepackqbit(&nchan,&nequip,&nbyte,&byte,&bit,&status); } return; } /*** test per passaggio penning-pirani ***/ if((val == 255)&&(m_flag_head == 1)) { bit = 0; writepackqbit(&nchan,&nequip,&nbyte,&byte,&bit,&status); val = GetMediaSample(samp_w); if (val>0) { m_flag_head = 0; } else
{ bit = 1; writepackqbit(&nchan,&nequip,&nbyte,&byte,&bit,&status); } } } }
Fig. 5.10 Procedura per l’acquisizione delle misure di pressione
CAPITOLO V- CONTROLLO REMOTO DEL VUOTO MEDIANTE PROFIBUS
78
La Fig. 5.10 mostra parte del sorgente relativo alla procedura OnTimer(): essa viene
richiamata dal FrameWork del sistema operativo ogni 100ms, a seguito dell’attivazione di un
opportuno timer; la variabile m_flag_head tiene traccia del sensore di pressione attualmente
selezionato (0 = Pirani, 1 = Penning, <0 valore iniziale); la chiamata a GetMediaSample()
pone in val il valore corrente di pressione, filtrato, in formato intero; il seguente test su
m_flag_head richiama la tabella opportuna per la conversione da intero a virgola mobile e
pone il risultato in fval (in seguito vedremo come questo valore viene trasmesso al PLC e
come viene utilizzato dal software del terminale remoto per l’aggiornamento degli strumenti
virtuali di monitoraggio).
I due test in fondo alla procedura implementano un criterio per la selezione del trasduttore da
cui attingere le misure di pressione: il primo test verifica se il trasduttore selezionato è il
Pirani e se il valore intero restituito è pari a zero; se le due condizioni sono vere, seleziona il
Penning e se la sua misura intera è inferiore a 255 allora pone m_flag_head a 1, altrimenti
riseleziona il Penning e lascia m_flag_head pari a 0; il test per il passaggio da Penning a
Pirani è il duale di quello appena visto e ne lasciamo l’analisi al lettore.
CAPITOLO V- CONTROLLO REMOTO DEL VUOTO MEDIANTE PROFIBUS
79
5.4 SISTEMA DI CONTROLLO LOCALE
Nei precedenti paragrafi abbiamo anticipato come la funzione di controllo locale sia svolta
da un apposito PLC (vedi descrizione al par. 3.5.3, Capitolo III); esso riceve i comandi e le
informazioni necessarie al controllo dalla stazione di supervisione Applicom e, sulla base di
queste, esegue determinate azioni corrispondenti secondo un algoritmo di controllo che il PLC
implementa al suo interno.
Nei prossimi paragrafi illustreremo le procedure di configurazione del PLC inerenti alla
comunicazione attraverso la rete ProFiBus ; successivamente introdurremo alcune nozioni
base sul linguaggio Ladder per poi procedere alla descrizione dell’algoritmo di controllo del
PLC formulato col suddetto linguaggio; proseguiremo poi con una descrizione degli
azionamenti elettrici e delle trasformazioni operate sulle uscite del PLC per adattarle agli
inneschi degli attuatori.
5.4.1 Configurazione del PLC sulla rete ProFiBus
La Fig. 5.11 mostra la finestra di dialogo dell’utility PCConf per la configurazione del PLC
sulla rete ProFiBus: tale finestra serve per l’immissione dei dati caratteristici del dispositivo
connesso al bus, informazioni necessarie all’Applicom Communication Server per
l’interscambio di dati; la prima specifica riguarda il tipo di ‘dialetto’ ProFiBus utilizzato
(FMS in questo caso); segue poi l’indirizzo fisico, il SAP locale (dell’Applicom) e quello del
PLC (remoto); segue poi la specifica relativa al tipo di comunicazione (MMAC = Master to
Master ACyclic), la password (0 = nessuna), ed altre informazioni relative alla lunghezza
massima delle Protocol Data Unit ad alta e bassa priorità, ed al periodo di attesa in stato di
idle prima dello scambio di un telegramma di monitoraggio tra la stazione Applicom ed il
PLC; i medesimi parametri vanno impostati nella finestra di configurazione della rete
all’interno del software di sviluppo del PLC.
CAPITOLO V- CONTROLLO REMOTO DEL VUOTO MEDIANTE PROFIBUS
80
Fig. 5.11 Finestra del tool PCConf per la configurazione del PLC
La configurazione del PLC, attraverso il proprio software di sviluppo per la realizzazione
della comunicazione FMS, comporta la creazione di due stazioni logiche (Fig. 5.12), una per
la stazione Applicom ed una associata al PLC .
CAPITOLO V- CONTROLLO REMOTO DEL VUOTO MEDIANTE PROFIBUS
81
La Fig. 5.13 mostra i dettagli relativi alla stazione associata al PLC : una casella contiene la
lista degli oggetti scambiati con la stazione di supervisione (ogni dato da scambiare deve
essere definito e dichiarato in questa lista come un oggetto con determinate caratteristiche di
formato); un’altra elenca i canali di comunicazione che la stazione condivide con altre
stazioni; in questo caso è presente un solo canale (10) che collega la stazione 2 (PLC) alla
stazione 0 (stazione Applicom).
Fig. 5.12 Finestra per l’editing delle stazioni di comunicazione FMS
CAPITOLO V- CONTROLLO REMOTO DEL VUOTO MEDIANTE PROFIBUS
82
Fig. 5.13 Finestra per l’editing della stazione associata al PLC
Fig. 5.14 Finestra per il link dei canali di comunicazione
CAPITOLO V- CONTROLLO REMOTO DEL VUOTO MEDIANTE PROFIBUS
83
La Fig. 5.14 mostra la definizione del collegamento tra i canali delle due stazioni, operazione
essenziale per la realizzazione della comunicazione FMS tra le due stazioni.
Le operazioni di definizione viste per la stazione associata al PLC vanno ripetute per quella
associata al Master Applicom (per un approfondimento consultare [23]).
5.4.2 Algoritmo di controllo locale
L’algoritmo di controllo locale è stato sviluppato nel linguaggio Ladder; di seguito
analizzeremo l’implementazione dell’algoritmo nel suddetto linguaggio e daremo visione dei
dati (oggetti) scambiati tra la stazione di supervisione e quella di controllo locale.
CAPITOLO V- CONTROLLO REMOTO DEL VUOTO MEDIANTE PROFIBUS
84
Nome Tipo Indirizzo Indice Descrizione ERROR Input 5 - Segnale esterno d’errore
FC_Rot Input 0 - Finecorsa valvola rotativa: 1 -> valvola chiusa FC_Turbo Input 1 - Finecorsa valvola turbo: 1 -> valvola chiusa FC_Vent Input 2 - Finecorsa valvola rotativa: 1 -> valvola chiusa Turbo_80 Input 4 - Segnale esterno: 1 -> turbo all’80% di regime P_rot_on Output 20 - Uscita di comando pompa rotativa: 1 -> ON
P_turbo_on Output 21 - Uscita di comando pompa turbo: 1 -> ON V_rot_on Output 16 - Uscita di comando valvola rotativa: 1 -> OPEN
V_turbo_on Output 17 - Uscita di comando valvola turbo: 1 -> OPEN V_vent_on Output 18 - Uscita di comando valvola rientro camera: 1 -> OPEN
V_rturbo_on Output 19 - Uscita di comando valvola rientro turbo: 1 -> OPEN Status_err Flag 104 100 Stato d’errore Status_p_r Flag 105 100 Stato pompa rotativa Status_p_t Flag 106 100 Stato pompa turbo Status_t_80 Flag 107 100 Stato regime 80% Status_v_r Flag 100 100 Stato valvola rotativa Status_v_rt Flag 103 100 Stato valvola rientro turbo Status_v_t Flag 101 100 Stato valvola turbo Status_v_v Flag 102 100 Stato valvola rientro camera
Manual_p_rot Flag 204 103 Comando manuale remoto per pompa rotativa Manual_p_tur Flag 205 103 Comando manuale remoto per pompa turbo Manual_v_rot Flag 200 103 Comando manuale remoto per valvola rotativa Manual_v_tur Flag 201 103 Comando manuale remoto per valvola turbo Manual_v_ven Flag 202 103 Comando manuale remoto per valvola rientro camera Manual_v_rtb Flag 203 103 Comando manuale remoto per valvola rientro turbo Start_empty Flag 300 104 Comando remoto di avvio controllo automatico
Start_manual Flag 304 104 Comando remoto di avvio controllo manuale Start_reset Flag 302 104 Comando remoto di avvio reset automatico Start_vent Flag 301 104 Comando remoto di avvio rientro aria automatico Press_curr Flag 150 101 Valore corrente di pressione Press_targ Flag 151 102 Valore target di pressione
Press_targ_H Flag 153 106 Soglia alta di pressione Press_targ_L Flag 152 105 Soglia bassa di pressione
tab. 5.2
La tab. 5.2 mostra la lista delle variabili utilizzate per l’implementazione dell’algoritmo di
controllo locale: di esse le prime cinque sono ingressi locali al PLC, le sei successive sono
uscite locali; le altre che seguono sono variabili contenute in oggetti scambiati tra la stazione
di supervisione Applicom ed il PLC ; gli indici ad esse relativi sono dei riferimenti utilizzati
per referenziare tali variabili nelle chiamate alle procedure di servizio per le comunicazioni
ProFiBus FMS.
CAPITOLO V- CONTROLLO REMOTO DEL VUOTO MEDIANTE PROFIBUS
85
La macchina a stati implementata è riportata in Fig. 5.15
Start_empty
Start_vent
Start_reset
Start_manual
Start_vent
Start_reset
Timer 3
Timer 2
Timer 1
Start_manual Start_vent Start_empty
Idle
Stato 0
Vuoto Automatico
Stato 1
Rientro aria Automatico
Stato 2
Comando Manuale
Stato 5
Fase rientro1
Stato 3
Fase rientro2
Stato 4
Reset
Stato 6
Fig. 5.15 Macchina a stati dell’algoritmo di controllo locale
CAPITOLO V- CONTROLLO REMOTO DEL VUOTO MEDIANTE PROFIBUS
86
La macchina a stati dell’algoritmo di controllo locale si compone di sei stati: lo stato 0 o di
idle è lo stato di partenza; lo stato 1 è quello in cui il PLC esegue il controllo automatico
dello svotamento della camera, e viene raggiunto attraverso il comando remoto start_empty;
lo stato 2 si raggiunge dallo stato 0 a seguito di un comando start_vent ed è lo stato in cui il
PLC esegue il rientro d’aria automatico della camera; gli stati 3 e 4 costituiscono delle fasi
intermedie del rientro automatico dell’aria nella camera e sono attivati allo scattare di appositi
timer per l’apertura e chiusura temporizzata delle valvole di rientro (vedremo il tutto più
avanti con maggiore dettaglio); lo stato 5 riguarda il controllo manuale in remoto
dell’apparato del vuoto e viene attivato a partire dallo stato 0 a seguito di un comando
start_manual; lo stato 6 è uno stato intermedio che viene attraversato tutte le volte che si esce
da uno degli altri stati, a seguito di un comando di start_reset, start_manual, start_vent o
start_empty, ed al suo interno il PLC esegue il reset di tutte le uscite di comando degli
attuatori e di altre variabili intermedie essenziali.
CAPITOLO V- CONTROLLO REMOTO DEL VUOTO MEDIANTE PROFIBUS
87
In Fig. 5.16 possiamo vedere la porzione di Ladder relativa alla transizione dallo stato 0 ad
uno dei possibili stati successori: la linea verticale sinistra costituisce la linea a stato logico 1,
mentre quella di destra costituisce la linea di massa,ossia a stato logico 0; inizialmente il PLC
si trova nello stato 0; la transizione verso uno qualunque degli altri stati può avvenire solo se
start_reset è pari a zero (si osservi il contatto normalmente chiuso avente start_reset
associato); l’attivazione su comando remoto di una delle tre variabili start_empty, start_vent
o start_manual, porta il PLC in uno dei tre stati successivi (1, 2 o 5); si osservi che i relé a
destra della figura sono di tipo Set e dunque le variabili booleane associate, se attivate,
permarranno nel loro stato logico alto fino ad un successivo reset per mezzo di un relé di tipo
Reset.
Fig. 5.16
Fig. 5.17
CAPITOLO V- CONTROLLO REMOTO DEL VUOTO MEDIANTE PROFIBUS
88
La Fig. 5.17 raffigura il Ladder relativo al controllo manuale all’interno dello stato 5: si
può osservare che l’apertura della valvola che mette in comunicazione la turbo con la camera
è condizionata dal raggiungimento dell’80 % della velocità di regime della turbina; altre
condizioni di sicurezza sono implementate all’interno del software d’interfaccia del terminale
remoto che visioneremo più avanti.
In Fig. 5.18 possiamo vedere la porzione di ladder relativa alla fase di vent (stati2,3 e 4): a
partire dallo stato 2 l’uscita v_vent_on viene posta ad 1, a condizione che le valvole di
accesso alla camera delle due pompe siano chiuse (FC_Rot = FC_Turbo = 1); il primo timer
in figura ha la funzione di consentire la transizione dallo stato 2 allo stato 3 dopo 4 minuti
(2440 x 100ms), in corrispondenza del quale viene attivata la valvola di rientro della turbo (i
quattro minuti d’attesa lasciano il tempo alla turbina di ridurre la propria velocità); si
Fig. 5.18
CAPITOLO V- CONTROLLO REMOTO DEL VUOTO MEDIANTE PROFIBUS
89
osservi che la transizione verso lo stato 3 non disattiva l’uscita di comando della valvola di
rientro della camera; dopo altri 10 minuti (2° timer con TV = 6000 x 100ms) si passa allo
stato 4 in corrispondenza del quale la valvola di rientro d’aria della turbo viene chiusa (nella
transizione 3-4, lo stato 3 viene disattivato -> v_rturbo_on = 0); dopo circa 12 minuti
dall’attivazione dello stato 4 si attiva fase_vent_2 e con l’ultima riga del ladder si resetta
start_vent e si passa allo stato 6.
Si osservi che negli schemi Ladder sinora mostrati si è omessa, per brevità, l’illustrazione dei
circuiti che nella transizione da uno stato al successivo provvedono all’azzeramento della
variabile booleana associata allo stato precedente: tale operazione è fondamentale per la
coerenza della macchina a stati per la quale un solo stato alla volta può essere attivo.
La Fig. 5.19 mostra la porzione dell’algoritmo Ladder relativo allo stato 1, nel quale il PLC
esegue il controllo automatico della pressione interna alla camera sulla base del valore di
target: in particolare la stazione di supervisione remota, oltre al valore di target press_targ,
fornisce al PLC due valori di target (press_targ_H e press_targ_L) per la realizzazione di un
controllo ad isteresi.
Analizziamo sulla figura l’algoritmo di attivazione della pompa turbo: se lo stato 1 è attivo,
se la pressione corrente è minore della pressione target e se quest’ultima è minore di 510-2
allora viene settata la variabile hold_p_tur ; infine se Stato_1 è alto insieme a hold_p_tur
l’uscita di comando della turbo (p_turbo_on) viene posta a 1.
CAPITOLO V- CONTROLLO REMOTO DEL VUOTO MEDIANTE PROFIBUS
90
Fig. 5.19
CAPITOLO V- CONTROLLO REMOTO DEL VUOTO MEDIANTE PROFIBUS
91
La ragione del confronto tra la pressione target ed il valore 510-2 risiede nel fatto che per
pressioni superiori a quest’ultimo valore non si ha necessità di attivare la turbo.
Consideriamo adesso la sequenza di attivazione della valvola di aspirazione della rotativa: se
Stato_1 è attivo, se la valvola di rientro d’aria della camera è chiusa (FC_Vent = 1), se
press_curr é maggiore di press_targ_H e se press_curr è maggiore di 510-2 allora viene
settata la variabile hold_v_rot; infine, a partire dallo stato 1, se hold_v_rot e FC_Vent sono
attive, dopo un tempo pari a delay_rot (valore impostato dal terminale remoto) v_rot_on
assume il valore 1.
La sequenza di chiusura della valvola di rotativa si basa sul confronto tra la pressione corrente
e la soglia bassa di target: se la prima è inferiore alla seconda e se tale condizione si mantiene
per più di mezzo secondo (il ritardo elimina l’influenza degli spikes negativi frequenti)
hold_v_rot si resetta e di conseguenza v_rot_on va a zero.
Si osservi che delay_rot ritarda l’apertura della valvola di aspirazione della rotativa rispetto
all’attivazione della rotativa stessa: la rotativa infatti viene attivata , a partire dallo stato 1, se
una delle due variabili hold_v_rot e hold_p_tur è pari a 1; inoltre, quest’ultima condizione
forza la rotativa a restare accesa anche quando la sua valvola d’accesso alla camera si chiude
e ciò perché la rotativa, oltre alla funzione di prevuoto, assolve la funzione di aspirazione dei
flussi molecolari che la turbo estrae dalla camera.
Infine prendiamo in esame la rete ladder che regola il comportamento dell’elettrovalvola di
aspirazione della turbo: se Stato_1, Turbo_80, FC_Vent e FC_Rot sono a 1, se press_curr é
maggiore di press_targ_H e se press_curr si mantiene minore o uguale a 510-2 per più di 0.5
secondi (quest’ultima condizione riduce l’influenza degli spikes negativi presenti nella misura
di pressione corrente) hold_v_rot viene resettata (viene forzata la chiusura della valvola di
aspirazione della rotativa) e hold_v_tur viene posta a 1 attraverso due rami differenti;
quando invece press_curr si mantiene minore o uguale a press_targ_L per un tempo
maggiore di 0.5 secondi, sia hold_v_tur che valve_switch (l’utilizzodi quest’ultima verrà
spiegato di seguito) vengono resettate.
Vediamo adesso di comprendere la necessità dei due cammini differenti per l’attivazione di
hold_v_tur: si osservi che uno di essi passa per un timer che applica un ritardo pari a
CAPITOLO V- CONTROLLO REMOTO DEL VUOTO MEDIANTE PROFIBUS
92
delay_tur (impostato dal terminale remoto) prima dell’attivazione della suddetta variabile;
tale ritardo ha lo scopo di modificare la dinamica d’intervento del PLC al fine di disinnescare
eventuali oscillazioni di apertura e chiusura della valvola di aspirazione della turbo,
oscillazioni che possono verificarsi a causa della imperfetta tenuta stagna della camera a
pressioni inferiori a 10-3 (fenomeno di degassazione dei materiali di isolamento); il secondo
cammino attiva hold_v_tur senza il ritardo suddetto, purché valve_switch sia attiva; ciò è
necessario perché al raggiungimento del valore di 510-2 mbar, in corrispondenza del quale la
valvola di aspirazione della pompa di prevuoto viene chiusa, se la valvola di aspirazione della
turbo non interviene subito, la pressione potrebbe risalire sopra il valore suddetto a causa delle
inevitabili perdite della camera, provocando così la riapertura della valvola di prevuoto ed una
conseguente anomalia di funzionamento nell’algoritmo di controllo (l’oscillazione potrebbe
così protrarsi a lungo); si osservi che valve_switch viene settata a 1 alla prima apertura della
valvola di prevuoto; a seguito della chiusura di quella della turbo, valve_switch viene resettata
e le successive riaperture della valvola della turbo (hold_v_tur = 1) subiranno il ritardo
delay_tur impostato.
CAPITOLO V- CONTROLLO REMOTO DEL VUOTO MEDIANTE PROFIBUS
93
5.5 INTERFACCIA REMOTA DI COMANDO
La Fig. 5.20 mostra l’interfaccia utente del terminale remoto per il controllo della camera a
vuoto: descriviamo di seguito gli elementi che la contraddistinguono, alla luce dell’algoritmo
di controllo locale implementato dal PLC e già descritto nel corso dei paragrafi precedenti.
La parte centrale della finestra di comando è occupata dal quadro sinottico riproducente
l’impianto da un punto di vista schematico, assieme agli indicatori di funzionamento: la
colorazione verde di uno qualunque di essi di essi indica il funzionamento attivo del
dispositivo associato, ossia pompa accesa o elettrovalvola aperta; il rosso indica gli stati
Fig. 5.20 Interfaccia utente per il controllo del vuoto
CAPITOLO V- CONTROLLO REMOTO DEL VUOTO MEDIANTE PROFIBUS
94
rimanenti. Ai due sensori di pressione sono associati due indicatori la cui accensione sta ad
indicare quale dei due dispositivi sia attualmente selezionato per l’acquisizione corrente delle
misure di pressione. In alto a destra è presente un pannello contenente due visualizzatori:
il primo è un visualizzatore a scorrimento in scala semilogaritmica che fornisce l’andamento
temporale della pressione interna alla camera; il secondo è un display che visualizza il valore
corrente di pressione in mbar.
Il Main Panel contiene diversi pulsanti, uno per ogni stato di controllo dell’algoritmo locale:
Il pannello Diagnostic fornisce due indicatori: System Error che indica la presenza di un
malfunzionamento dello strumento che alimenta i trasduttori di pressione, e Turbo 80% che
informa del raggiungimento dell’80 % della velocita massima della turbina.
Man - attiva la funzione di comando manuale (Stato_5 = 1); ogni singolo
attuatore può essere usato per comandare;
Reset - attiva la procedura automatica di reset (Stato_6 = 1); tutte le pompe
vengono spente e tutte le elettrovalvole vengono chiuse;
Vent - attiva la procedura automatica di rientro d’aria (Stato_2 = 1);
Auto Vacuum - attiva la procedura di controllo automatico della pressione;
il target ed altri parametri vengono immessi mediante i
controlli che seguono; (Stato_1 = 1);
Target - consente l’immissione del valore target di pressione utilizzato dal PLC
durante il controllo automatico di pressione;
Tolerance - definisce l’ampiezza dell’isteresi durante il controllo automatico;
press_targ_L,H = press_targ ( 1Tolerance);
Delays - consentono l’immissione del ritardo d’apertura rispettivamente per la
valvola d’aspirazione della rotativa e della turbo;
CAPITOLO V- CONTROLLO REMOTO DEL VUOTO MEDIANTE PROFIBUS
95
5.5.1 Procedure per la comunicazione FMS
La Fig. 5.21 mostra la procedura chiave per la trasmissione di dati in formato binario tra la
stazione di supervisione Applicom ed il PLC: essa fa uso della funzione writepackbit che
trasmette il dato value all’equipment di indirizzo 2; le norme di comunicazione FMS server
impongono una trasformazione del valore di indice di un oggetto FMS in un indirizzo
secondo la formula address = index 256 ; ciò sta a significare che se si vuole ad es. passare
al modo di funzionamento manuale bisogna eseguire la chiamata PLC_Write(256*104, 16)
(si faccia riferimento alla tabella 5.2) dove 104 è l’indice dell’oggetto flag ad 8 bit che
contiene Start_manual e 16 = 2^4 è la maschera di bit che attiva Start_manual (bit 4).
La Fig. 5.22 mostra la procedura per il monitoraggio delle variabili di controllo e
l’aggiornamento degli indicatori del quadro sinottico: essa viene richiamata ogni 100 ms
all’interno della funzione membro OnTimer(); legge l’oggetto status index 100), lo confronta
col valore precedentemente letto e se vi sono differenze aggiorna lo stato dei leds mediante
opportune chiamate alla procedura SetLed(); la stessa cosa compie per l’oggetto Start (index
104) contenente i flag di attivazione degli stati di controllo (Start_. . .).
Un’altra procedura, la PLC_Press() di cui omettiamo la descrizione, viene anch’essa
richiamata periodicamente all’interno di OnTimer per la trasmissione al PLC della misura
corrente in formato floating point.
short PLC_Write(long adr, short value) { short nchan = 0; /* Channel number */ short neq = 2; /* Equipment number */ short nb = 8; /* Number of variables */ short status; /* Status */ writepackbit(&nchan, &neq, &nb, &adr, &value, &status); return status;
}
Fig. 5.21 Procedura per il filtraggio delle misure di pressione
CAPITOLO V- CONTROLLO REMOTO DEL VUOTO MEDIANTE PROFIBUS
96
short PumpControlDialog::PLC_Status_Leds(short & h_stat, short & h_start) { short nchan = 0; /* Channel number */ short neq = 2; /* Equipment number */ short nb = 8; /* Number of variables */ short status; /* Status */ short value; long adr = STATUS*256; readpackbit(&nchan, &neq, &nb, &adr, &value, &status); if (h_stat != value) { SetLed(value & STATUS_V_R, MIN_LED_RED, (CStatic *) GetDlgItem(LED_VALV2)); SetLed(value & STATUS_V_T, MIN_LED_RED, (CStatic *) GetDlgItem(LED_VALV3)); SetLed(value & STATUS_V_V, MIN_LED_RED, (CStatic *) GetDlgItem(LED_VALV1)); SetLed(value & STATUS_R_T, MIN_LED_RED, (CStatic *) GetDlgItem(LED_VALV4)); SetLed(value & STATUS_P_R, MIN_LED_RED, (CStatic *) GetDlgItem(LED_OIL)); SetLed(value & STATUS_P_T, MIN_LED_RED, (CStatic *) GetDlgItem(LED_TURBO)); SetLed(value & STATUS_P_T, MIN_LED_RED, (CStatic *) GetDlgItem(LED_TURBO)); SetLed(value & STATUS_ERR, DIA_LED_RED, (CStatic *) GetDlgItem(IDC_LED_ERR)); SetLed(value & STATUS_T_80, DIA_LED_GREEN, (CStatic *) GetDlgItem(IDC_LED_80)); h_stat = value; } adr = START_COMMANDS*256; readpackbit(&nchan, &neq, &nb, &adr, &value, &status); if (h_start != value) { SetLed(value & START_MANUAL, LED_GREEN, (CStatic *) GetDlgItem(LED_MAN)); SetManPanel(value & START_MANUAL); SetLed(value & START_EMPTY, LED_YELLOW, (CStatic *) GetDlgItem(LED_EMP)); SetLed(value & START_VENT, LED_ORANGE, (CStatic *) GetDlgItem(LED_FIL)); SetLed(value & START_RESET, LED_RED, (CStatic *) GetDlgItem(LED_RES)); h_start = value; } return status;
}
Fig. 5.22 Procedura peril monitoraggio delle variabili di controllo
CAPITOLO VI- RECS 101
97
CAPITOLO VI
RECS 101 UN SISTEMA DI CONTROLLO REMOTO
BASATO SU TECNOLOGIA MICRO WEB SERVER
EMBEDDED
6.1 INTRODUZIONE
Un web server embedded è un web server integrato all’interno di un sistema embedded
caratterizzato da risorse di calcolo limitate capace di gestire documenti ed applicazioni web.
L’applicazione della tecnologia Web ad un sistema embedded permette la creazione di
interfacce utente mediante il linguaggio HTML. I vantaggi che derivano dall’adozione di tale
strategia permettono di ottenere un’interfaccia user friendly, a basso costo, cross platform, e
network ready. Aggiungendo a tale dispositivo la tecnologia del linguaggio di
programmazione Java si ottiene un sistema capace di gestire vere e proprie applicazioni che
possono essere facilmente programmate sfruttando le potenzialità tipiche di un linguaggio ad
alto livello. Scopo di questo capitolo è quello di presentare una soluzione web server
embedded capace di gestire la Java Virtual Machine per applicazioni di supporto agli
esperimenti di fisica nucleare. Viene presentato un sistema la cui architettura fornisce
un’interfaccia API (Application Program Interface) semplice e, al tempo stesso, potente. In
particolare si discute la progettazione e l’implementazione di RECS 101 (acronimo di Remote
Ethernet Control System), un sistema web server embedded, sviluppato al fine di poter
gestire applicazioni di controllo remoto mediante l’utilizzo di reti Ethernet. In conclusione,
vengono presentate alcune applicazioni pratiche del dispositivo, quali: realizzazione di circuiti
elettronici d’interfaccia, uno studio riguardante dei test di performance di RECS 101 ed
un’analisi delle problematiche di protezione da attacchi alla sicurezza da parte di hacker.
CAPITOLO VI- RECS 101
98
6.2 I SISTEMI WEB SERVER EMBEDDED ED INTERNET
Poiché il World Wide Web (o Web) è in continua evoluzione, appare chiaro ed evidente
che tale tecnologia assume delle nuove funzionalità che vanno molto oltre la semplice
visualizzazione delle pagine Web. Per molte applicazioni commerciali e scientifiche il
browser web è diventato uno standard per lo sviluppo di interfacce utente di numerose
applicazioni. Questo perché i browsers web sono capaci di fornire interfacce GUI a varie
applicazioni client/server senza il bisogno di andare ad implementare del software per il lato
client. Negli ultimi anni è sempre più cresciuto il numero di tecnologie web che possono
essere applicate ad elementi gestibili dalla rete questa esigenza ha dato molto impulso per la
sperimentazione di questi sistemi anche per scopi scientifici e di ricerca applicata quale ad
esempio quella tipica dei laboratori di fisica nucleare. Come ben noto la maggioranza delle
reti di computer viene gestita mediante il protocollo TCP/IP. La gestione di apparati
elettronici tramite web fornisce all’utente l’abilità di configurare e monitorare variegati
dispositivi tramite Internet mediante l’uso di un comune browser. La soluzione migliore a
questo tipo di esigenze è sicuramente data dall’utilizzo di server web embedded connesso ad
un infrastruttura di rete al fine di fornire un interfaccia utente basata su web costruita
mediante l’utilizzo dell’ormai noto linguaggio HTML [24] unitamente a grafici e ad altre
caratteristiche comuni ai web browsers [25]. Se si pensa di aggiungere alle funzionalità ormai
consolidate di un web server embedded la capacità di poter gestire applicazioni Java ecco che
questi sistemi aprono le frontiere a capacità inesplorate, che rendono essi capaci di eseguire i
più variegati compiti quali, ad esempio, quelli di controllo remoto, supervisione e gestione di
sistemi elettronici (Fig. 6.1). Nelle applicazioni di controllo remoto si fa sempre più presente
l’esigenza di interconnettere apparecchiature e strumentazioni tramite web server embedded
al fine di avere una gestione quanto più decentralizzata possibile delle loro funzionalità [25].
Ognuno di questi controller programmato opportunamente diviene capace di eseguire
differenti algoritmi di controllo.
CAPITOLO VI- RECS 101
99
Fig. 6.1 Architettura di un web server embedded
6.3 APPROCCIO MEDIANTE L’UTILIZZO DELLA TECNOLOGIA
JAVA
Il concetto della Virtual Machine di Java è particolarmente indicato per questo approccio
permettendo l’uso di una strategia di controllo indipendente dalla piattaforma hardware del
sistema in cui viene gestita. Questa metodologia è stata da tempo adoperata nelle applicazioni
Internet dove non sono richiesti stringenti vincoli di real-time. L’uso del linguaggio di
programmazione Java per le applicazioni di controllo remoto fornisce il vantaggio di integrare
sistemi general purpose con internet permettendo la supervisione ed il controllo di sistemi.
Oggigiorno i sistemi che si basano su web server embedded richiedono sempre applicazioni
più complesse, facili da programmare, al fine di eseguire i compiti di supervisione e gestione.
Web
Server
Embedded
JAVA
Browser
Embedde
d
Inter
net
CAPITOLO VI- RECS 101
100
Per realizzare il concetto di network computing viene presentata la tecnologia Java al fine di
ottenere la combinazione sinergica di sistemi di controllo realtime distribuiti che siano
gestibili tramite la rete Internet. Con l’incessante sviluppo della microelettronica i sistemi
embedded sono stati applicati a molteplici prodotti industriali ed elettronici, poiché
presentano le caratteristiche di essere economici, affidabili con buone performance se
comparati con il software utilizzato nei Personal Computers [25]. Il vantaggio delle tecnologie
Internet permette di interconnettere tra loro dispositivi e sistemi all’interno della rete internet.
Tutto questo facilita l’accesso ai dispositivi permettendo di effettuare operazioni di
monitoraggio, di controllo, di reporting, start up, shutdown di qualsiasi dispositivo
semplicemente premendo dei tasti all’interno di un interfaccia GUI gestita da un comune
browser [26]. Il nuovo concetto che intendiamo introdurre si basa sull’esecuzione di Applet
Java per eseguire operazioni di controllo o di monitoraggio di dispositivi remoti . In questo
tipo di sistemi il controllo distribuito si ottiene mediante il trasferimento di pagine HTML e
l’esecuzione di applet Java (Fig. 6.2).
Fig. 6.2 Esecuzione di Applet Java per eseguire operazioni di controllo o di monitoraggio
di dispositivi remoti
Questo nuovo concetto permette di espandere le comuni capacità dei sistemi di controllo
fornendo un sistema remoto distribuito per il controllo di sistemi elettronici. La progettazione
di sistemi embedded richiede l’integrazione e lo sviluppo di componenti hardware e software:
spesse volte queste sono particolarmente difficili da realizzare poiché ogni controller possiede
la sua piattaforma hardware e software. Anziché adoperare linguaggi differenti e non standard
per l’implementazione del software nella maggior parte dei casi è preferibile adoperare un
Embed
ded
System
Pagine richieste
Testo/Applet
Browser
TCP/IP
CAPITOLO VI- RECS 101
101
linguaggio comune [25]. Il Java rappresenta una scelta ottimale per differenti motivi: è un
linguaggio standard completo di librerie, è un linguaggio molto semplice che riduce le
problematiche inerenti l’analisi dei programmi, la loro ottimizzazione e trasformazione
[26],[27].
6.3.1 I vantaggi dell’utilizzo di Java
Il linguaggio di programmazione Java si sta diffondendo sempre più all’interno
dell’industria dell’information technology particolarmente per le applicazioni che prevedono
l’utilizzo di database. Il Java è un linguaggio di programmazione che permette di installare
un’applicazione all’interno di un server ed essere quindi eseguita su diverse piattaforme
hardware. Questi vantaggi possono essere brevemente riassunti nei seguenti punti:
- Indipendenza dalla piattaforma: diversamente dai comuni compilatori che
producono codice per CPU specifiche, il Java produce del codice per una CPU
virtuale. Al fine di rimanere indipendente da specifiche piattaforme hardware il
sistema runtime di Java fornisce un’interfaccia universale per qualsiasi applicazione
che si desidera sviluppare. Tale interfaccia denominata JVM (Java Virtual Machine) è
una sorta di processore virtuale che si interpone tra il processore fisico del PC e
l’applicazione scritta in Java. Tuttavia, l’indipendenza dalla piattaforma non è
sufficiente per assicurare il successo di un linguaggio di programmazione. La JVM è
da diverso tempo inclusa all’interno dei browser più popolari quali, ad esempio,
Microsoft Explorer e Netscape. Alcuni sistemi operativi real-time includono al loro
interno la tecnologie Java e tutto ciò permette di giungere alla seguente conclusione
“la JVM è una risorsa universale” [26,28];
CAPITOLO VI- RECS 101
102
- Potenza: Il Java racchiude in se nuove caratteristiche che includono la gestione dei
database, l’invocazione dei metodi remoti ed altre caratteristiche inerenti la gestione
della sicurezza.
- Networking: Il Java nasce come linguaggio di programmazione distribuito, il che si
traduce nel fatto che la sua progettazione includeva sin dall’inizio la gestione di
particolari funzioni inerenti il networking. Il Java ha una libreria vastissima di routine
per la gestione dei protocolli quali, ad esempio, il TCP/IP, l’HTTP, l’FTP. Le
applicazioni Java possono avere accesso ad oggetti attraverso la rete Internet per
mezzo di URL (Universal Resource Locator, più comunemente noto come indirizzo
del sito web) in un modo molto simile all’accesso ad un comune file system locale.
Unendo la tecnologia Java alle potenzialità dei sistemi basati su web server embedded
si possono ottenere dei sistemi molto potenti per la gestione di applicazioni di
controllo.
- Efficienza: Le moderne JVM superano la forte limitazione delle passate dove veniva
evidenziata la problematiche dell’estrema lentezza di esecuzione dei programmi.
Attualmente grazie all’utilizzo della tecnologia Just in Time (JIT) compiler le
performance d’esecuzione delle applet sono state fortemente migliorate [27].
6.3.2 L’utilizzo di Java all’interno di sistemi web server embedded
L’uso di linguaggi object-oriented assieme alle loro tecniche di progettazione permettono
di ottenere un codice che risulta essere facilmente riutilizzabile e mantenibile. Normalmente,
un’applicazione che va trasferita ad un controller si compone di un file binario eseguibile che
viene direttamente eseguito dalla CPU. Il vantaggio principale di un approccio di questo tipo
si traduce in una maggiore velocità d’esecuzione. Il Java permette di ottenere la funzionalità
“compila una sola volta e utilizza più volte”. E’ virtualmente possibile utilizzare lo stesso
codice compilato in piattaforme differenti e, quindi, eseguire il codice su differenti Sistemi
Operativi per fare i test ed il debugging del software per poi trasferire il tutto all’interno di un
CAPITOLO VI- RECS 101
103
dispositivo di controllo [26]. Il Java si presenta come un linguaggio di programmazione
fortemente adottato per la programmazione applicazioni che fanno di internet un punto di
forza. I vantaggi principali inerenti l’utilizzo delle applet Java all’interno di un web server
embedded possono essere riassunte nei seguenti punti:
- Non occorre sviluppare una Graphical User Interface (GUI) poiché i browser web di
per se suppliscono a tale funzionalità;
- Le dimensioni del codice Java sono minori rispetto alle istruzioni di codice macchina
rendendo particolarmente attrattivo l’utilizzo di tale tecnologia all’interno di web
server embedded dove, sicuramente, la dimensioni della RAM messa a disposizione
per le applicazioni è limitata;
- Essendo l’esecuzione delle applet in locale, e quindi non all’interno del sistema
embedded, l’efficienza e la complessità d’esecuzione degli algoritmi da eseguire sono
a carico del client e non del sistema embedded che, sicuramente, avrà risorse di
calcolo molto più limitate rispetto a quelle di un comune PC;
- Molti costruttori di microprocessori per sistemi embedded hanno investito
nell’implementazione della JVM all’interno dei loro dispositivi: di conseguenza gran
parte del software è già disponibile;
- E’ intuitivo prevedere che in un immediato futuro la maggior parte dei kernel dei
microcontrollori includerà la JVM.
CAPITOLO VI- RECS 101
104
6.3.3 La Java Virtual Machine
Attualmente esistono diversi modi di implementare la JVM. La fig. 6.3 mostra due
possibili implementazioni.
Codice Java Codice C/C++
JVM Librerie Native
Piattaforma Hardware
Codice Java
Sistema Operativo Java
JVM Librerie Native
Piattaforma Hardware
Fig. 6.3 Possibili implementazioni della JVM
Nella prima la JVM viene integrata all’interno di un ambiente di sviluppo software. L’altra
incorpora un Sistema Operativo Java che viene particolarmente indicata per quelle
applicazioni che prevedono l’utilizzo di un unico ambiente di sviluppo sia per i
programmatori che per gli utilizzatori [26]. Una volta disponibile l’interfaccia JVM è
possibile includerla all’interno di un sistema di sviluppo embedded integrandola con le
librerie del codice nativo. Ciò può essere ottenuto utilizzando qualsiasi linguaggio di
programmazione quale, ad esempio, il Java bitcode interpreter e, quindi, compilare il tutto in
accordo ai vincoli hardware del sistema in cui la si vuole integrare. L’utilizzo della JVM
all’interno di un web server embedded presenta il vantaggio che coloro che svilupperanno il
codice per la programmazione dell’applicazione all’interno del sistema embedded
utilizzeranno istruzioni Java e non dovranno tener contro delle relazioni che intercorrono tra
la JVM e la microprogrammazione del sistema embedded. In più si può fornire all’utente
finale un’interfaccia tipo applet parametrica che richiede semplicemente il setup di alcuni
CAPITOLO VI- RECS 101
105
parametri. In quest’ultimo caso l’utente finale non necessita di avere alcuna conoscenza
riguardo il linguaggio di programmazione Java.
6.3.4 Implementazione della JVM all’interno di un web server embedded
L’applicazione che viene presentata in questo articolo, pur essendo stata implementata
all’interno di un architettura basata su processore UBICOM, può essere virtualmente
implementata all’interno di qualsiasi microprocessore o microcontrollore che dir si voglia. La
Fig. 6.4 mostra lo schema architetturale semplificato di un possibile scenario d’applicazione
in cui sono richiesti dei sistemi per il controllo di 16 ingressi digitali e 16 uscite digitali.
Fig. 6.4 Scenario d’applicazione del dispositivo RECS 101.
L’architettura presentata permette la simulazione e lo studio di procedure tipiche dei sistemi
di controllo quali, ad esempio: acquisizione di segnali, azioni di controllo per mezzo di
attuatori, l’elaborazione e la presentazione delle informazioni acquisite o manipolate. Il
sistema embedded presentato si basa su un software di sviluppo scritto in C. Tale programma
può far eseguire dei task preprogrammati all’interno della ROM o far eseguire delle
CAPITOLO VI- RECS 101
106
applicazioni Java. La capacità di far eseguire applicazioni Java viene fornita dai seguenti
componenti software che devono essere prevaricati nella ROM del dispositivo mediante il su
citato software di sviluppo [29]:
- Il file loader .class, che permette di fare il downloads del codice Java da eseguire nella
RAM del dispositivo;
- L’implementazione della JVM stessa;
- Implementazioni di classi per la gestione dell’hardware locale;
- Classi Java riferite al sistema embedded.
La JVM è stata implementate in accordo alle specifiche dettate dallo standard [7], Fig. 6.5.
Fig. 6.5 Architettura della JVM implementata.
CAPITOLO VI- RECS 101
107
Il programma monitor che risiede all’interno del sistema embedded scarica il file .class che
deve essere eseguito all’interno della memoria RAM; dopodiché l’informazione viene
processata e si provvede alla costruzione della Constant Pool Table. La Constant Pool è
quindi risolta ed il programma passa alla ricerca del metodo d’inizializzazione del programma
main che dovrà essere eseguito. Dopo aver trovato questi metodi, la JVM ricerca il Byte Code
che deve essere eseguito e, di conseguenza, invoca l’interprete di bytecode. Quando i metodi
delle classi Java sono stati invocati la JVM richiama delle subroutine del firmware del
microprocessore che provvederanno all’implementazione del metodo specifico.
La JVM di per se stessa non comunica direttamente con l’hardware del sistema ma usa delle
classi per fare ciò. Un fattore molto limitante di questi sistemi è dovuto alla scarsità della
memoria che si ha a disposizione. Di conseguenza ciò porta a fare delle scelte su quali metodi
e classi devono essere implementati all’interno del sistema.
CAPITOLO VI- RECS 101
108
6.4 UN CASO DI STUDIO REALE: RECS 101
RECS 101 rappresenta una realizzazione pratica di quanto appena esposto, la tab. 6.1
riporta le principali caratteristiche e specifiche del sistema proposto.
Specifica RECS 101
CPU Ubicom SX52BD (8 bit microprocessor, 50 MIPS)
Memoria 512 Kb flash memory (Utilizzata per contenere le
pagine web dell’utente)
Connessione di Rete Interfaccia Ethernet 10 Base-T (IEEE802-3)
Connessione Utente 16 Ingressi digitali / 16 Uscite digitali
Protocolli Internet Supportati HTTP / BOOTP / TCP / UDP / IP
ICMP / ARP
Ethernet 802.3
Software di Utilità RECS Utility (Piattaforma Windows)
Web page uploader e cambio indirizzo IP
Tab 6.1 Specifiche del dispositivo RECS 101.
RECS 101 integra al suo interno un network processor dotato di interfaccia di rete Ethernet
per connettersi direttamente a qualsiasi rete locale sia essa Internet che Intranet. Ciò ha
permette di connettere i loro dispositivi direttamente ad Internet attraverso una rete Lan e, di
conseguenza, di gestire da remoto il controllo totale dei dispositivi attraverso interfacce
grafiche utente personalizzabili, direttamente accessibili mediante i comuni browser quali, ad
esempio, Microsoft Internet Explorer e Netscape Navigator. RECS 101 si basa sullo schema
hardware presentato in Fig. 6.6.
CAPITOLO VI- RECS 101
109
Fig. 6.6 Schema funzionale di RECS 101
RECS 101 è stato programmato in modo tale da contenere una pagina web precaricata
all’interno della memoria flash del dispositivo che può essere modificata a piacimento in
modo da personalizzarne le applicazioni.
Microprocessore
Ethernet
Controller
Filtro
10 Base T
Memoria Flash
512 KB
16 Ingressi Digitali
TTL
16 Uscite Digitali
TTL
CAPITOLO VI- RECS 101
110
Fig. 6.7 Home page personalizzabile del dispositivo RECS 101.
RECS 101 contiene un web server integrato capace di gestire fino a 512k di documenti ed
applicazioni web: tali risorse sono state precaricate all’interno della memoria flash del
dispositivo. La Fig. 6.7 è un esempio di una pagina web gestita da RECS 101 che può essere
utilizzata per fornire informazioni statiche sul dispositivo quali, ad esempio, immagini, testi,
files etc. La pagina visualizzata può essere personalizzata a piacimento mediante l’uso dei più
comuni editor di pagine HTML. Le pagine web possono contenere al loro interno file di
immagini del tipo JPG, GIF, BMP, file video tipo SWF di Flash e qualsiasi altro file si ritenga
opportuno che l’HTTP server di RECS 101 debba gestire. Selezionando il link “RECS 101
Control Panel” si accederà alla pagina web dedicata al controllo dell’applicazione. La
caratteristica che rende unico tale sistema consiste nell’utilizzare un web server all’interno di
un’applicazione embedded con la possibilità di eseguire del codice Java per la gestione
dell’interfaccia relativa al controllo delle 16 porte di input e delle 16 porte di output (Fig. 6.8).
Tale caratteristica permette di poter gestire l’interfaccia utente tramite un’Applet Java
CAPITOLO VI- RECS 101
111
parametrica: in questo modo l’utente finale può sviluppare la propria applicazione di controllo
in modo molto veloce e sicuro senza dover essere in grado di programmare in Java.
Fig. 6.8 Esempio di una possibile interfaccia GUI implementata in RECS 101.
All’interno del pannello di controllo (Fig. 6.8) si può notare un LED aggiuntivo specificato
“Network”. La sua funzionalità è quella di fornire all’utente lo stato della rete: una
connessione senza problemi provoca il suo continuo lampeggiare. Nel caso di perdita
momentanea del collegamento il LED non lampeggerà e, se la connessione non si ristabilisce
entro qualche minuto il sistema chiuderà la connessione con RECS 101. Problematiche di
questo tipo normalmente non sorgono in reti Intranet ma possono capitare se si collega RECS
101 alla rete Internet .
CAPITOLO VI- RECS 101
112
6.4.1 Personalizzazione dell’interfaccia utente
RECS 101 è un sistema progettato in modo tale da essere totalmente personalizzabile. Al
suo interno è possibile modificare ed aggiornare il firmware di sistema in modo tale da poter
sviluppare rapidissimamente delle applicazioni in maniera facile e sicura. In particolare è stato
sperimentato un software contenente alcuni files ed un’APPLET (RECS.jar) di controllo che
possono essere personalizzati mediante i parametri riportati di seguito:
PDFOOK : Stringa d’inizializzazione Applet. Non è possibile effettuare nessuna
modifica
host : Indirizzo IP associato a RECS 101(Es. host value="172.16.10.103" vuol dire
che l’indirizzo IP di RECS è 172.16.10.103
port : Porta TCP adoperata dall’ applicazione per comunicare con RECS 101. Il
valore di tale porta è fisso e pertanto non modificabile (Es. port value=6001)
polling :Intervallo di Polling. Ha una risoluzione di 10 ms e può essere settato in
funzione dell’applicazione. Per es. “polling value=1” significa che il check dello stato
d’ I/O del dispositivo verrà controllato ogni 10 ms
NumLed : Numero ingressi da monitorare mediante LED bicolore (Es. NumLed
value=16, verranno visualizzati 16 LED indicatori di stato)
NumB : Numero di pulsanti di comando per la modifica dello stato delle uscite (Es.
NumB value=16, verranno visualizzati 16 pulsanti)
Per comodità del lettore la Tab. 6.2 riassume tutti i parametri gestiti dall’applet in questione.
CAPITOLO VI- RECS 101
113
Tab. 6.2 Parametri di configurazione dell’Applet
Di seguito si riporta il frammento del codice HTML del file index.html relativo alla
personalizzazione dell’Applet in cui si evidenzia il setup dei parametri di inizializzazione.
L’esempio in questione prevede l’utilizzo di tutte le 16 uscite e di tutti i 16 ingressi messi a
disposizione dall’hardware di RECS 101.
<APPLET CODE=Applicazione.class ARCHIVE=RECS.jar WIDTH=850
HEIGHT=500>
<param name=PDFOOK value="Intellisystem Technologies Device">
<param name=host value="172.16.10.103">
<param name=port value=6001>
<param name=polling value=1>
<param name=NumLed value=16>
<param name=NumBot value=16>
</APPLET>
La Fig. 6.8 rappresenta l’interfaccia utente che si ottiene applicando il codice appena esposto.
Le limitazioni di quest’Applet consistono nel fatto che non è possibile modificare i testi ed i
colori dei vari componenti che formano l’interfaccia utente.
Per superare questa limitazione è stata messa a punto un’ Applet più elaborata che permette di
personalizzare ulteriormente l’interfaccia grafica utente mediante altri parametri che
permettono di definirne colori e testi (Fig. 6.9).
CAPITOLO VI- RECS 101
114
Fig. 6.9 Interfaccia GUI avanzata implementata in RECS 101.
Di seguito si riassumono i parametri che permettono la personalizzazione dell’Applet in
questione (RECS.jar versione avanzata):
PDFOOK : Stringa d’inizializzazione Applet. Non è possibile effettuare nessuna
modifica;
host : Indirizzo IP associato a RECS 101(Es. host value="172.16.10.103". Vuol dire
che l’indirizzo IP di RECS è 172.16.10.103;
port : Porta TCP adoperata dall’ applicazione per comunicare con RECS 101. Il
valore di tale porta è fisso e pertanto non modificabile (Es. port value=6001) ;
polling :Intervallo di Polling. Ha una risoluzione di 10 ms e può essere settato in
funzione dell’applicazione. Per es. “polling value=1” significa che il controllo dello
stato d’ I/O del dispositivo verrà controllato ogni 10 ms;
Title : Stringa intestazione applicazione. (Es. Title value="RECS I/O DEMO ") ;
CAPITOLO VI- RECS 101
115
ColTit : Colore da associare alla stringa impostata nel parametro “Titolo”. (Es. ColTit
value="green" , il testo verrà stampato in verde) ;
CAPL : Colore di sfondo Applet. (ES. CAPL value="yellow", lo sfondo sarà giallo) ;
NumLed : Numero ingressi da monitorare mediante LED bicolore (Es. NumLed
value=16, verranno visualizzati 16 LED indicatori di stato) ;
NumB : Numero di pulsanti di comando per la modifica dello stato delle uscite (Es.
NumB value=16, verranno visualizzati 16 pulsanti) ;
TBT* : Testo da associare al pulsante * relativo all’uscita * (Es. TBT1
value="Comando 10" è il testo da associare al pulsante 10 per modificare lo stato dell’
uscita 10) ;
CTBT* : Colore del testo associato al titolo del pulsante *. (Es. CTBT10 value="red",
il colore associato al testo relativo al pulsante 10 è rosso) ;
CLBF* : Colore associato al LED di stato dell’ uscita * quando quest’ultima è nello
stato “OFF” (Es. CLBF10 value="gray", il colore del LED associato allo stato “OFF”
dell’ uscita 10 sarà grigio) ;
CLBT* : Colore associato al LED di stato dell’ uscita * quando quest’ultima è nello
stato “ON” (Es. CLBT10 value="blue", il colore del LED associato allo stato “ON”
dell’ uscita n.10 sarà blu) ;
TLD*: Testo da associare al LED * relativo all’ ingresso *. (Es. TLD1 value="Luce
Camera" è il testo da associare al LED 1 per effettuare la lettura dello stato dell’
ingresso 1) ;
CTLD* : Colore del testo associato al titolo del LED * relativo all’ingresso *. (Es.
CTLD1 value="black", il colore associato al testo relativo al LED 1 sarà nero) ;
CAPITOLO VI- RECS 101
116
CLIF* : Colore associato al LED di stato dell’ ingresso * quando quest’ultimo è nello
stato “OFF” (Es. CLIF10 value="green", il colore del LED associato allo stato “OFF”
dell’ ingresso 10 sarà verde) ;
CLIT* : Colore associato al LED di stato dell’ ingresso * quando quest’ultimo è nello
stato “ON” (Es. CLIT10 value="red", il colore del LED associato allo stato “ON” dell’
ingresso 10 sarà rosso) ;
Per comodità del lettore la tab. 6.3 riassume in forma tabulare i parametri
personalizzabili dell’Applet per la gestione avanzata di RECS 101.
Tab. 6.3 Parametri di configurazione dell’Applet per la gestione avanzata di RECS 101
Di seguito si riporta il frammento del codice HTML del file index.html relativo alla
personalizzazione dell’Applet in cui si evidenzia il setup dei parametri di inizializzazione.
CAPITOLO VI- RECS 101
117
<APPLET CODE=Applicazione.class ARCHIVE=RECS.jar WIDTH=850
HEIGHT=500>
<param name=PDFOOK value="Intellisystem Technologies Device">
<param name=host value="172.16.10.103">
<param name=port value=6001>
<param name=polling value=1>
<param name=Title value="RECS 101 I/O Demo">
<param name=ColTit value="black">
<param name=CAPL value="white">
<param name=NumLed value=16>
<param name=NumBot value=16>
Un esempio di personalizzazione dei pulsanti e degli indicatori LED è rappresentato dal
seguente codice contenuto all’interno del file index.html:
<param name=TBT1 value="Comando 1">
<param name=CTBT1 value="red">
<param name=CLBF1 value="gray">
<param name=CLBT1 value="blue">
<param name=TLD1 value="Ingresso 1">
<param name=CTLD1 value="black">
<param name=CLIF1 value="green">
<param name=CLIT1 value="red">
La Fig. 6.10 riassume quanto detto in precedenza, ovvero:
1. La pagina 101.html rappresenta la home page del sito web contenuto in RECS
101. Al suo interno è presente un collegamento alla pagina Index.html;
2. La pagina Index.html contiene al suo interno i parametri di setup dell’Applet
per la gestione degli ingressi e delle uscite di RECS 101;
CAPITOLO VI- RECS 101
118
3. Tramite l’applet RECS.jar si interviene sulle porte d’input e di output per la
gestione dell’hardware che si intende controllare.
Fig. 6.10 Files necessari per la personalizzazione dell'interfaccia utente di RECS 101
Inter
net
Appl
et
Hardware da
controllare
101
.html
Index.
htmlml
CAPITOLO VI- RECS 101
119
6. 5 CONFIGURAZIONE DEI PARAMETRI DI RETE
RECS 101 è un sistema progettato per essere usato dinamicamente in qualsiasi contesto di
rete Ethernet pertanto si è provveduto a progettare e realizzare un software d’utilità detto
RECS Utility. Tale software è stato progettato e realizzato per lavorare su piattaforma
Microsoft Windows sui sistemi operativi delle versioni 95/98/ME/NT/2000 e XP Home
Ediction/Professional. Nella fig. 1 si riporta la maschera iniziale del programma che permette
di impostare l’indirizzo IP di RECS 101 (Fig. 6.12)
Fig. 6.12 - Schermata iniziale di RECS Utitlity.
6.6 UPLOAD DELL’INTERFAZZIA UTENTE PERSONALIZZATA
Per sfruttare al massimo le potenzialità di RECS 101 occorre personalizzale l’interfaccia
grafica del dispositivo agendo e/o modificando degli opportuni files di configurazione.
Definita l’interfaccia utente per l’applicazione che si intende progettare non resta che fare
CAPITOLO VI- RECS 101
120
l’upload all’interno della memoria flash di RECS 101 (la memoria totale a disposizione
dell’utente è di 500 KByte con supporto fino a 256 differenti file).
Poiché RECS 101 utilizza un file system non standard i file relativi all’interfaccia web sono
gestiti mediante una tabella interna di tipo “file index”. Per trasferire i files all’interno di
RECS 101 è necessario procedere prima alla creazione di un file di progetto che rappresenta
l’immagine dei files che dovranno essere memorizzati all’interno della memoria flash. Il file
di progetto, che presenta un estensione *.REC, può essere unicamente gestito dal web server
integrato in RECS 101. RECS Utility contiene al suo interno delle funzionalità dedicate alla
costruzione e all’upload di questo tipo di file. Per procedere all’upload dell’interfaccia utente
personalizzata occorre seguire i seguenti passi:
1) Creare e/o modificare le pagine web personalizzate con qualsiasi software di web-
publishing
2) Settare i parametri dell’applet in funzione delle esigenze di progetto
3) Utilizzare il software RECS Utility per creare il file di progetto *.REC
4) Fare l’upload del file di progetto all’interno di RECS 101
6.7 IMPLEMENTAZIONE DELLE INTERFACCE HW PER LE
PORTE DI I/O
RECS 101 si interfaccia con l’impianto o dispositivo da controllare mediante due porte a
16 bit digitali, rispettivamente, una di Input ed un’altra di Output poste sul frontalino
posteriore. La fig. 14 riporta la piedinatura dei connettori Cannon a 25 poli che ospitano tali
porte. Il progettista che intende interfacciare RECS 101 deve predisporre delle interfacce che
permettano il corretto rispetto delle caratteristiche elettroniche della logica TTL
implementata nelle due porte. Di seguito distingueremo due tipi di interfacce rispettivamente
una per la porta di Input ed un’altra per la porta di Output.
CAPITOLO VI- RECS 101
121
Digital Input
Digital Output
LED Pin Note Tasto
Pin Note
1 2 1 2 2 15 2 15 3 3 3 3 4 16 4 16 5 4 5 4 6 17 6 17 7 5 7 5 8 18 8 18 9 6 9 6
10 19 10 19 11 7 11 7 12 20 12 20 13 8 13 8 14 21 14 21 15 9 15 9 16 22 16 22 1 Vcc +5v 1 Vcc +5v 14 Vcc +5v 14 Vcc +5v 10 GND 10 GND 23 GND 23 GND 12, 13, 24, 25 Non usati 12, 13, 24,
25 Non usati
Fig. 6.13 Piedinatura dei connettori di I/O di RECS 101
6.7.1 Unità d’Input
Poiché l’interfaccia di I/O di RECS 101 lavora con livelli logici TTL il dispositivo da
interfacciare alla porta d’ingresso deve presentare anch’esso un interfaccia di tipo TTL. I 16
CAPITOLO VI- RECS 101
122
bit d’ingresso per l’applicazione fornita sono stati progettati per funzionare in logica TTL
“Low Active”. Non sempre però i dispositivi hanno delle porte TTL e perciò, in questo caso,
è opportuno adoperare un circuito che interponendosi tra RECS 101 e il dispositivo da
interfacciare possa connettere i due dispositivi senza che essi corrano il rischio di
danneggiarsi. Il circuito suggerito utilizza dei fotoaccopiatori che, garantendo un totale
isolamento galvanico tra i due dispositivi, ne assicurano il corretto funzionamento. La Fig.
6.14 mostra una possibile realizzazione del circuito proposto.
Fig. 6.14 Interfaccia per la connessione di un dispositivo alla porta d’ingresso di RECS
101
6.7.2 Unità d’Output
RECS 101 è dotato 16 uscite che lavorano con livelli logici TTL progettati per funzionare
in logica “High Active”. Affinché RECS 101 possa essere correttamente interfacciato con un
altro dispositivo che lavora con tensioni diverse si consiglia l’uso di fotaccopiatori che
garantendo un totale isolamento galvanico tra i due dispositivi ne assicurano il corretto
funzionamento. La Fig. 6.15 mostra lo schema elettrico di un circuito d’esempio per la
realizzazione di un’interfaccia d’uscita da collegare a RECS 101. Tale circuito si presta
CAPITOLO VI- RECS 101
123
benissimo per tutte quelle applicazioni nelle quali è necessario effettuare un controllo di tipo
ON/OFF di carichi di qualunque tipo. Poiché il circuito contiene dei relay assieme agli
optoisolatori si ottiene un circuito doppiamente isolato sia galvanicamente (per mezzo dei
realy) che otticamente (mediante l’uso di fotoaccoppiatori). Questa proprietà è da non
sottovalutare per prevenire possibili rischi di danneggiamento di RECS 101 o peggio ancora
di tutti i sistemi presenti nella rete a cui è connesso RECS 101: in questo modo si è sicuri che
per qualsiasi operazione errata compiuta a valle dell’interfaccia il danno è comunque
confinato al danneggiamento dell’interfaccia stessa.
Fig. 6.15 Interfaccia per la connessione di un dispositivo mediante relay alla porta
d’uscita di RECS 101
6.8 PROTOCOLLO DI COMUNICAZIONE IMPLEMENTATO IN RECS
101
CAPITOLO VI- RECS 101
124
RECS 101 effettua il controllo delle sue porte digitali mediante un interfaccia basata sui
socket di Internet. Per ottenere il controllo remoto delle porte di I/O attraverso Internet, è
necessario che l’interfaccia che gestisce i socket venga implementata nel PC dell’utente che
intende collegarsi a RECS 101 attraverso il protocollo TCP/IP. La potenzialità di RECS 101
consiste nel fatto che tale interfaccia può essere implementata indifferentemente mediante un’
Applet Java (che viene eseguita all’interno del Web Browser che si collega al dispositivo
RECS 101) o un’applicazione C/Java che utilizzi i socket di Internet (Fig. 6.16).
Fig. 6.16 Possibili scenari d’implementazione dell’interfaccia di comunicazione socket di
RECS 101
Ovviamente per fare ciò occorre progettarle adeguatamente aderendo allo standard fissato
dalle regole della suite di protocolli TCP/IP. Tali interfacce si occuperanno quindi di inviare e
ricevere i comandi per il controllo delle porte di I/O attraverso l’indirizzo IP impostato su
RECS 101 e la relativa porta fissata alla 6001.RECS 101 si occuperà dell’interpretazione dei
comandi di controllo ricevuti o trasmessi dal dispositivo elettronico da controllare ad esso
connesso.
Interfaccia
Socket
Applet
Java
Applicazione
C/C++
Applicazione
Java
Interfacc
ia
Socket
Dispositivo
da controllare
CAPITOLO VI- RECS 101
125
Fig. 6.17 Schema funzionale per la gestione di un dispositivo elettronico tramite RECS
101
I comandi di controllo si suddividono in due categorie che identificano due operazioni
diverse:
- Monitor Stato I/O: Tramite questa operazione è possibile avere informazioni inerenti lo
stato di tutte le linee di I/O contenute nelle due porte a 16 bit di RECS 101. I comandi relativi
a questa operazione sono essenzialmente due:
1. I/O Get Command: E’ il comando mediante il quale l’interfaccia socket interroga
RECS 101 sullo stato delle proprie porte;
2. I/O Get Command Responce: E’ il comando di risposta mediante il quale RECS
101 comunica all’interfaccia socket lo stato delle sue porte di I/O.
Fig. 6.18 Comandi di controllo di RECS 101
- Controllo dell’Output: Questo tipo di operazione, gestita unicamente dal comando
Output Set Command è utilizzata dall’interfaccia socket per settare i valori della porta
d’Output di RECS 101.
Monitor
Stato I/O
I/O Get
Command
I/O Get
Command
Responce
CAPITOLO VI- RECS 101
126
Fig. 6.19 Comando di controllo della porta di Output di RECS 101.
La tab. 1 riassume i comandi relativi alla comunicazione e i tipi di messaggi che vengono
scambiati tra l’interfaccia socket ed il dispositivo RECS 101.
Tipo di operazione Comando Direzione
PC Utente RECS 101
Monitor Stato I/O I/O Get Command
I/O Get Command Responce
Controllo dell’Output Output Set Command
Tab. 6.4 Comandi relativi alla comunicazione e i tipi di messaggi che vengono scambiati tra
l’interfaccia socket ed il dispositivo RECS 101.
6.8.1 Monitor dello stato di I/O
Lo stato della porta di I/O di RECS 101 è controllato mediante comandi gestiti tramite
l’interfaccia socket che provvede a far dialogare il PC utente con RECS 101. Più esattamente
il comando che il PC utente deve inviare per ricevere da parte di RECS 101 lo stato delle
porte di I/O è lo “0x75”, che si compone di un byte. Quando RECS 101 riceverà tale comando
provvederà a comunicare lo stato delle porte di I/O utilizzando 4 byte come riportato in tab.
6.5.
Tipo Numero di Byte
Controllo
dell’Output
Output Set
Command
CAPITOLO VI- RECS 101
127
1 2 3 4
Comando per monitorare lo stato delle
porte di I/O
0x75
Risposta contenete lo stato delle porte di
I/O
Stato della porta di Input Stato della porta di Output
Byte 1 Byte 2 Byte 3 Byte 4
MSB LSB MSB LSB
Stato della porta di Input Stato della porta d’Output
Tab. 6.5 Controllo dello stato delle porte di I/O di RECS 101.
Appare evidente che lo stato delle porte di I/O dipenderà dalla logica implementata
dall’utilizzatore di RECS 101. Per esempio, supponendo che il circuito da interfacciare a
RECS 101 sia stato progettato per lavorare secondo la tecnica “Active LOW” ciò equivale a
dire che un ipotetico diodo Led collegato ad un’uscita della porta di Output sia acceso quando
a quest’ultima viene inviato uno zero logico. Se adesso consideriamo il caso in cui i bit 0,2,4 e
10 della porta d’Output siano nello stato logico alto e i bit 1,3 e 5 della porta d’Input siano
anch’essi nello stato logico alto, RECS 101 alla ricezione del comando “0x75” risponderà
come descritto nella tab. 6.6. A questo punto l’interfaccia socket tra RECS 101 ed il PC utente
si occuperà dell’interpretazione di questo valore visualizzando il corrispondente valore su PC
utente.
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 0 1 1 1 1 1 0 1 0 1 0 0 0 0 0 0 0 0 0 0 0 1 0 1 0 1 0
1111| 1011 | 1110 | 1010 = 0xFBEA 0000 | 0000 | 0010 | 1010 = 0x002A
CAPITOLO VI- RECS 101
128
Stato della porta d’Input Stato della porta d’Output
Tab. 6.6 Esempio di codifica dello stato della porta di I/O.
Anche se i dati relativi allo stato delle porte di I/O sono contenuti in 4 byte, RECS 101
invierà all’interfaccia socket una parola di 16 bytes. Di conseguenza l’utente dovrà
interpretare solamente i primi 4 bytes del pacchetto ricevuto. Ciò è dovuto al fatto che, come
detto in precedenza, la trasmissione di queste informazioni avviene mediante i socket che
operano tramite il protocollo TCP/IP che a sua volta opera sullo standard Ethernet. Poiché lo
standard Ethernet impone una lunghezza minima del pacchetto di 64 bytes (inclusi i gli
headers IP e TCP) , e considerando il fatto che nel caso in cui venga generato un pacchetto la
cui lunghezza minima è inferiore ai 64 bytes questi viene scartato, bisogna arrivare alla
conclusione che anche se RECS ne avrebbe di bisogno solamente 4 si è costretti ad usarne 16,
di conseguenza, l’utente dovrà interpretare solamente i primi 4 bytes del pacchetto ricevuto
(Tab. 6.7).
2 bytes 2 bytes 60 bytes
Stato della porta di Input Stato della porta d’Output Dati non utilizzati
Tab. 6.7 Formato del pacchetto ricevuto dall’interfaccia socket
6.8.2 Controllo dei comandi di Output
CAPITOLO VI- RECS 101
129
Questo tipo di comando viene utilizzato in tutti quei casi in cui si vuole modificare il
valore di un bit della porta di Output di RECS 101 senza che venga generato un messaggio di
conferma. La tab. 5 riporta il formato del relativo comando “0x76” che si compone di 4 bytes
di cui il primo contiene il comando vero e proprio e gli altri due rappresentano il nuovo stato
che la porta d’Output dovrà assumere.
Tipo Numero di Bytes
1 2 3
Comando di controllo della porta
d’Output 0x76 Stato della porta di Output
Tab. 6.8 Formato del commando di controllo della porta di Output
Per esempio, supponiamo il caso in cui si voglia modificare lo stato della porta d’Output di
RECS 101 settando allo stato logico “alto” i bit 0,1,2 e 3 lasciando tutti gli altri nello stato
logico “basso”. Allora poiché il corrispondente valore in esadecimale è 0x000F, occorrerà
inviare a RECS 101 il valore esadecimale 76:00:0F come mostrato nella tab. 6.9.
CAPITOLO VI- RECS 101
130
Tab. 6.9 Esempio di modifica dello stato della porta d’uscita di RECS 101.
6.9 COMUNICARE CON RECS 101: L’INTERFACCIA SOCKET IN C
Si riporta di seguito un esempio di codice sorgente scritto nel linguaggio di
programmazione C che rappresenta l’implementazione di un’interfaccia socket basata sulle
API dei socket di Berkely. I frammenti di codice riportati di seguito implementano le
funzionalità di gestire rispettivamente il “Monitor Stato I/O “ e il “Controllo dell’Output”
descritti precedentemente. Prendendo spunto da questi esempi l’utente oltre a capire i
meccanismi di funzionamento descritti potrà essere capace di costruire una propria interfaccia
personalizzata che funzionerà come applicazione, ovvero permetterà di gestire RECS 101
attraverso il protocollo TCP/IP ma senza il supporto di un Web Browser. Un’applicazione di
questo tipo poterebbe essere utili per tutte quelle esigenze di protezione e di riservatezza che
escludano l’utilizzo di una tale interfaccia. Come primo esempio si riporta la procedura
IOMonitor che si occupa di monitorare lo stato delle porte di Input e di Output di RECS 101.
Per poter gestire tale operazione occorre per prima cosa definire due buffer rispettivamente
commandBuf che conterrà il codice relativo al comando da inviare a RECS 101 e
ResponseBuf che conterrà il valore letto nella porta di I/O.
Occorrerà inoltre definire delle variabili di ausilio quali:
CAPITOLO VI- RECS 101
131
- commandLen: è un intero che contiene la lunghezza del comando relativo a
commandBuf;
- lenReceived: intero che conterrà la lunghezza del buffer di ricezione ResponseBuf.
- i: variabile intera da utilizzare per i cicli iterativi
Definite le variabili occorre inizializzare il Socket TCP mediante la chiamata alla procedura
TCPSocketInit() che per brevità non viene riportata. Si passa quindi ad inizializzare il buffer
che conterà il comando utilizzando la costante IOGet, che definita altrove, è uguale a 0x75
che rappresenta il codice esadecimale del comando Monitor Stato I/O. A questo punto
utilizzando l’istruzione sendto si invia l’istruzione Monitor Stato I/O a RECS 101, inviando
come parametri il valore del buffer e altre informazioni riguardanti l’indirizzo IP di RECS
101. Poiché la funzione sendto restituisce un valore che è uguale a -1 in caso di errore, al
verificarsi di questo evento verrà visualizzato un opportuno messaggio d’errore indicante un
problema riscontrato durante la comunicazione con il dispositivo. Inviato il comando Monitor
Stato I/O bisogna predisporre l’interfaccia socket a ricevere le informazioni che scaturiscono
dall’interrogazione fatta. Per prima cosa bisogna allocare i buffer di ricezione ResponseBuf,
dopodiché mediante l’istruzione recvfrom (che è la corrispondente dell’istruzione sendto nel
caso della ricezione) si riceveranno le informazioni relative allo stato della porta di I/O di
RECS 101. Poiché l’istruzione recvform restituisce un valore uguale a -1 in caso d’errore è
possibile implementare delle istruzioni che avvertano nel caso in cui ci siano stati degli errori
di comunicazione. Supponendo che non ci siano stati errori durante la comunicazione si può
passare alla visualizzazione dello stato delle porte di I/O mediante la lettura del buffer di
ricezione Response Buf.
La procedura può terminare chiudendo il Socket TCP e rilasciando le locazioni di memoria
allocate per la gestione dei buffer.
//-------------------------------------------
CAPITOLO VI- RECS 101
132
// RECS 101: Esempio di programmazione di
// un interfaccia socket in C
// Procedura IOMonitor
//
// By Intellisystem Technologies
// http://www.intellisystem.it
//-------------------------------------------
void IOMonitor()
{
char commandBuf, *ResponseBuf ;
int commandLen, lenReceived ;
int i ;
// Inizializzazione del Socket TCP
TCPSocketInit() ;
// Esegui I comandi TCP
commandBuf = IOGet ;
commandLen = 1 ;
// Invia I comandi a RECS 101
err = sendto (sock,&commandBuf,commandLen,0,
(struct sockaddr*)&clientAddr,sizeof(clientAddr));
if (err == -1)
{
perror("\n Errore nell’invio dei dati !! \n");
exit (1);
}
// Allocazione di un buffer per I pacchetti
// in ingresso, 1 pacchetto = 16 bytes
ResponseBuf = calloc(0x10, sizeof(char)) ;
// Ricezione dei pacchetti entranti
lenReceived = recvfrom (sock,ResponseBuf,0x10,0,
(struct sockaddr*)&clientAddr,&clientLen);
if (lenReceived < 0)
{
perror("\n Errore nella ricezione dei dati??? \n") ;
exit(0) ;
}
// Visualizza la dimensione dei pacchetti entranti
printf("\n%d N. di bytes ricevuti -> \n", lenReceived) ;
CAPITOLO VI- RECS 101
133
// Memorizza lo stato delle porte di I/O
// per usi futuri nell’array IOStatus
for (i=0; i<4; i++)
IOStatus[i] = ResponseBuf[i];
// Visualizza lo stato delle porte di I/O
printf("\n\n* Stato delle porte di I/O di RECS 101 *\n") ;
printf("Porta di Input : %x:%x\t\t Porta di Output : %x:%x",
IOStatus[0], IOStatus[1], IOStatus[2], IOStatus[3]) ;
printf("***** Intellisystem Technologies *****\n") ;
// Rilascia le allocazioni di memoria allocate per il buffer
free(ResponseBuf) ;
// Chiude il Socket TCP
TCPSocketClose() ;
}
Il secondo esempio che si riporta serve a variare lo stato della porta di Otuput di RECS 101.
In particolare si riporta come esempio la procedura per modificare un solo bit della porta di
Output che una volta selezionato verrà portato a livello logico alto. Per tale scopo
adopereremo la procedura SetOutput().
Come nel caso precedente iniziamo con la dichiarazioni delle variabili locali:
- commandBuf: è un array di caratteri che conterrà i tre byte che compongono il
comando Output Set Command;
- commandLen: è un intero che contiene la lunghezza in byte dell’istruzione Output
Set Command;
- outbit:è un intero inizializzato al valore zero che conterrà la posizione del bit della
porta di Output che si vuole modificare;
- outdata: è un intero inizializzato al valore 0x0001 che viene utilizzato come maschera
per la modifica del singolo bit che compone la parola relativa alla porta di Output.
La prima operazione da svolgere è quella di richiedere quale bit all’interno della parole che
compone la porta di Output si vuole modificare. Tale valore viene quindi memorizzato nella
variabile outbit. Richiamiamo la procedura IOMonitor() per leggere lo stato della porta di I/O
CAPITOLO VI- RECS 101
134
che verrà memorizzato all’interno dell’array IOStatus. Da notare che IOStatus [2] conterrà la
parte MSB della porta di Output e IOStatus [3] conterrà la parte LSB. A questo punto occorre
ristabilire una connessione con RECS 101 pertanto reinizializziamo il Socket tramite la
procedure TCPSocketInit(). Poiché in C quando si definisce una variabile di tipo int questa
viene allocata all’interno di una cella di memoria di 16 bit sia IOStatus [2] che IOStatus[3]
saranno contenuti in due celle da 16 bit. Occorre quindi fare in modo che queste vengano
compattate come unico valore a 16 bit, tale operazione viene svolta eseguendo l’operazione
logica sui bit di IOStatus[2] e IOStauts [3]:
outdata = ( Shift di 8 posizioni verso sinistra di IOStatus[2] ) OR (IOStatus [3])
quanto appena detto viene espletato da un unica istruzione riportata nel listato:
outdata |= ((IOStatus[2]<<8) | IOStatus[3]);
Essendo il nostro obiettivo portare a livello logico alto solamente il bit selezionato tramite la
variabile outbit, l’operazione necessaria da fare è quella di utilizzare la variabile outdata
precedentemente inizializzata ad 1 e farla shiftare (a livello di bit) di tante posizioni verso la
sinistra rispetto al valore di outdata, in questo modo il bit posto inizialmente uguale ad i in
outdata si posizionerà alla relativa posizione lasciando tutti gli altri bit uguali a zero. Quanto
detto si riassume nella seguente pseudo istruzione:
outdata= outdata OR (1 Shift di outbit posizioni verso sinistra)
che si traduce nella seguente istruzione C:
outdata |= (int) (1 << outbit);
A questo punto la variabile outdata conterrà il nuovo valore dello stato della porta di Out con
il bit selezionato portato a livello logico alto. Occorre adesso prepararsi per eseguire il
CAPITOLO VI- RECS 101
135
commando Output Set Command. Per fare ciò dobbiamo riempire il buffer commandBuf di
tre byte rispettivamente, uno per il codice istruzione 0x76 e i rimanenti che conterranno la
parte MSB e LSB del nuovo stato della porta di Output.
Adoperando le seguenti istruzioni:
IOStatus[2] = (outdata & 0xff00)>> 8 ;
IOStatus[3] = (outdata & 0x00ff) ;
facciamo in modo che IOStatus [2] contenga la parte MSB del nuovo stato della porta di
Output, il ché si ottiene eseguendo la seguente operazione logica sui bit di outdata:
IOStatus[2]= Shift di 8 posizioni verso destra (outdata AND 11111111|00000000)
Per il secondo caso sarà sufficiente eseguire solamente la seguente operazione logica sui bit di
outdata:
IOStatus[3]= outdata AND 11111111|00000000
Riempito il buffer che conterrà il comando da inviare a RECS 101 non ci rimane che
adoperare l’istruzione sendto per rendere tale comando operativo. Si ricorda che tale
istruzione restituisce un valore che nel caso sia -1 indica che l’informazione non è stata
trasmessa correttamente. Per concludere, l’ultima operazione da fare è quella di chiudere il
Socket mediante la chiamata alla procedura TCPSocketClose.
//-------------------------------------------
// RECS 101: Esempio di programmazione di
// un interfaccia socket in C
// Procedura SetOutput
//
// By Intellisystem Technologies
// http://www.intellisystem.it
//-------------------------------------------
void SetOutput ()
CAPITOLO VI- RECS 101
136
{
char commandBuf[3] ;
int commandLen ;
int outbit=0, outdata=0x0000 ;
int err ;
// Richiede quale bit si vuole portare a livello logico
// alto della porta di Output
printf(" Prego selezionare il bit della porta d’Output
di cui si vuole invertire lo stato logico “alto”(0-15) :");
scanf("%d", &outbit) ;
// Legge lo stato corrente delle porte di I/O
IOMonitor() ;
// Re-Initializza il Socket TCP
TCPSocketInit() ;
// Determina il nuovo valore della porta d’Output a partire
// dallo stato attuale delle uscite
outdata = ((IOStatus[2]<<8) | IOStatus[3]) ;
outdata |= (int) (1 << outbit); // Or operation with currentle selected Bit
// Memorizza il nuovo stato della porta di Output
IOStatus[2] = (outdata & 0xff00)>> 8 ;
IOStatus[3] = (outdata & 0x00ff) ;
// Costruisci il buffer che conterrà Il comando Output Set Command
// 1) Command ID IOSet=0x76
commandBuf[0] = IOSet ;
// 2) Output status set
commandBuf[1] = (BYTE) ((outdata & 0xff00) >> 8) ;
commandBuf[2] = (BYTE) (outdata & 0x00ff) ;
commandLen = 3 ;
// Invia I comandi a RECS 101
err = sendto (sock,&commandBuf,commandLen,0,
(struct sockaddr*)&clientAddr,sizeof(clientAddr)) ;
if (err == -1 )
{
perror("\n Errore nell’invio dei dati !! \n");
exit (1);
CAPITOLO VI- RECS 101
137
}
// Chiude il Socket TCP
TCPSocketClose() ;
}
Per maggiore chiarezza la Fig. 6.20 riporta un esempio pratico di quanto descritto
precedentemente, pertanto si supporrà quanto segue:
1) Lo stato della porta di Output di RECS 101 è uguale a
00000000|10001001;
2) Si vuole portare a livello logico “alto” il quinto bit della porta di Output a
partire dalla destra.
Stato della porta di
Output
00000100|10001001
Bit della da portare allo
stato logico “alto”
5° IOStatus[2]
00000000|000001
00 Shift 8 pos. Sx
00000100|000000
00
IOStatus[3]
00000000|100010
01
Outdata=IOStatus [2] OR IOStatus
[3]
00000100|10001001
Outbit= Shift di 5 pos. Sx
di 1
00000000|00100000
Outdata=Outdata OR
outbit
00000100|10101001 Outdata AND
0xff00
00000100|00000000 IOStatus[2]= Shift 8 pos.
Dx
00000000|00000100
IOStatus[3]= Outdata AND
0x00ff 00000000|10101001
CAPITOLO VI- RECS 101
138
Fig. 6.20 Esempio che illustra l’algoritmo per settare a livello logico “alto” il 5° bit della
porta di Output di RECS 101
6.10 COMUNICARE CON RECS 101: L’INTERFACCIA SOCKET IN
JAVA
Come detto in precedenza per superare tutte le limitazioni dovute alla gestione di RECS
101 mediante un software applicativo la soluzione proposta da Intellisystem Technologies
utilizza la tecnologia Java che prevede la creazione di un’Applet di controllo viene gestita
mediante un interfaccia browser. Come ben noto le Applet sono dei programmi autonomi,
scritti in Java, eseguibili mediante un comune browser del World Wide Web. La potenzialità
di un software scritto il Java permette di essere totalmente indipendenti dalla piattaforma HW
su cui si esegue l’applicazione. Senza entrare troppo nei dettagli della programmazione in
Java riportiamo di seguito un frammento di codice Java riguardante un esempio di
implementazione dell’interfaccia Socket basata su Applet che permette la ricezione e
trasmissione di degnali di I/O, attraverso il protocollo TCP. Il lettore più attento può
paragonare i codici seguenti con quelli scritti in C ed evidenziare quindi le analogie in termini
di funzionalità.
//------------------------------------------
// RECS 101: Esempio di programmazione di
// un interfaccia socket in Java
// Procedura readIOport
//
// By Intellisystem Technologies
// http://www.intellisystem.it
CAPITOLO VI- RECS 101
139
//------------------------------------------
public int readIOport()
{
Socket socketTCP = null;
int tmp = 0;
int inputData = 0;
byte rxData[] = new byte[16];
byte data[] = {COMMAND_GET};
try {
socketTCP = new Socket(InetAddress.getByName(m_host), m_port);
socketTCP.setTcpNoDelay(true);
socketTCP.getOutputStream().write(data, 0, data.length);
instream = new DataInputStream(socketTCP.getInputStream());
tmp = instream.read(rxData, 0, rxData.length);
if (tmp != -1)
{
inputData = (int) (rxData[2] << 8 | (rxData[3] & 0x00ff));
inputData &= 0xffff;
}
socketTCP.close();
instream.close();
}
catch (Exception e)
{
System.out.println("Err : " + e);
}
return inputData;
}
//-------------------------------------------
// RECS 101: Esempio di programmazione di
// un interfaccia socket in Java
// Procedura writeOutputPort
//
// By Intellisystem Technologies
// http://www.intellisystem.it
//-------------------------------------------
public void writeOutputPort(int outdata)
CAPITOLO VI- RECS 101
140
{
Socket socketTCP = null;
byte[] data = new byte[4];
data[0] = COMMAND_SET;
data[1] = (byte) ((outdata >> 8) & 0x000000ff);
data[2] = (byte) (outdata & 0x000000ff);
// Initialize socket
try {
socketTCP = new Socket(InetAddress.getByName(m_host), m_port);
socketTCP.setTcpNoDelay(trujhe);
socketTCP.getOutputStream().write(data, 0, data.length);
socketTCP.close();
}
catch (Exception e)
{
System.out.println("Err: " + e);
}
}
6.11 IL PROBLEMA DELLA SICUREZZA PER I WEB SERVER
EMBEDDED
La sicurezza è un aspetto molto importante e da non trascurare nei sistemi di controllo
specie se sono gestiti tramite la rete Internet. Se da un alto la rete Internet offre grandi
flessibilità a livello di condivisione di risorse e di gestione da remoto dall’altro è sicuramente
un ambiente non sicuro poiché chiunque può connettersi alla rete. Il web ha il potere di
aumentare la produttività di chiunque, tuttavia come per ogni tecnologia o attività do gruppo
oltre alle straordinarie attività occorre considerarne i rischi. Generalmente gli attacchi ad un
sistema di controllo remoto si possono classificare mediante l’individuazione dei punti deboli
del sistema che si intende esaminare.
In generale si possono individuare quattro categorie:
CAPITOLO VI- RECS 101
141
Vulnerabilità dei dati
Vulnerabilità del software
Vulnerabilità del sistema fisico
Vulnerabilità delle trasmissioni
Per difendersi da questi attacchi, ci si deve attendere che ogni potenziale intruso possa
sfruttare queste vulnerabilità per accedere ai dati e quindi potenzialmente danneggiare il
sistema. Ad esempio, la connessione di un sistema di controllo su internet può aprire delle
falle nei sistemi di sicurezza e tali falle possono essere utilizzate da utenti non autorizzati per
accedere o manipolarne le funzionalità. Gli intrusi potrebbero anche invalidare il server
Internet del sistema di controllo, modificandone i file in esso memorizzati (ad esempio i file
che contengono le informazioni sulle User-ID e Password degli utenti del sistema). I
potenziali Hacker potrebbero inserire nel sistema dei virus e altri programmi distruttivi auto-
replicanti in grado di danneggiare o disabilitare completamente il sistema. Possiamo
classificare gli attacchi provenienti da internet nelle seguenti categorie:
1. Attacchi da password: Gli intrusi cercano di entrare nel sistema immettendo un
codice di Login ed una password, provando varie volte sino a trovarne una
funzionante [29]. Normalmente vengono adoperati dei software in grado di utilizzare
variegati dizionari che provano di continuo diverse combinazioni sino a quando non
trovano quella vincente che permette di far accedere al sistema. Ad esempio i sistemi
Unix sono particolarmente vulnerabili ad attacchi di questo tipo poiché UNIX non
blocca l’accesso degli utenti dopo un determinato numero di tentativi falliti, cosa che
normalmente avviene nella maggior parte degli altri sistemi operativi;
2. Attacchi alla sicurezza della rete e dei pacchetti: Poiché ogni pacchetto trasmesso in
Internet può attraversare un gran numero di nodi prima di giungere a destinazione, gli
CAPITOLO VI- RECS 101
142
hacker possono utilizzare appositi strumenti denominati “racket sniffer” per
intercettare i pacchetti inoltrati nella rete (inclusi i pacchetti di login e trasmissione dei
dati). I più comuni attacchi ai pacchetti sono precursori degli attacchi al protocollo IP.
Per iniziare un attacco sniffing, un hacker per prima cosa va alla ricerca di una User
ID e di una password di un utente legittimo utilizzandola per accedere alla rete
distribuita. Dopo essersi intruso nella rete l’hacker osserva e copia le trasmissioni dei
pacchetti e tenta di raccogliere quante più informazioni possibili sulla rete.
3. Attacchi al protocollo IP: Si concentra sull’indirizzamento dei pacchetti che il
protocollo IP utilizza per le trasmissioni. Un attacco di questo tipo prevede due fasi.
Nella prima si cerca di determinare l’indirizzo IP del server, generalmente mettendosi
in ascolto dei pacchetti Internet, provando a specificare in ordine vari numeri di host
oppure connettendosi al sito mediante un browser web e osservando l’indirizzo IP
nella barra di stato. Poiché l’hacker sa che gli altri computer della rete condividono
una parte del dell’indirizzo IP del server, cercherà di simulare un indirizzo IP che gli
consenta di by-passare il router e di accedere al sistema come se fosse un utente
interno. Dopo che l’hacker avrà iniziato a trovare gli indirizzi della rete, inizierà anche
a controllare i numeri di sequenza dei pacchetti che si trasmettono tali computer. Dopo
aver monitorizzato le trasmissioni della rete, l’hacker cercherà di prevedere il
prossimo numero di sequenza che verrà generato dal server e quindi fornirà un proprio
pacchetto con tale numero di sequenza inserendosi fra il server e l’utente. Poiché
l’hacker ha già l’indirizzo IP del server, può in realtà generare pacchetti con i numeri
di sequenza corretti e indirizzi IP che gli consentono di intercettare le trasmissioni con
l’utente. Dopo che l’hacker ha avuto accesso al sistema tramite la previsione di un
numero di sequenza, può accedere alle informazioni che il sistema di comunicazione
trasmette al server, inclusi i file di password, nomi, login, dati riservati e ogni altra
informazioni trasmessa in rete. In generale un hacker utilizza la previsione del numero
CAPITOLO VI- RECS 101
143
di sequenza come preparativo per l’attacco vero e proprio al server oppure come base
per l’attacco di un altro server della rete.
4. Hyperlink Spoofing: E’ un tipo di attacco che gli hacker sferrano contro computer
che comunicano utilizzando il protocollo HTTP [30]. Gli hacker possono dunque
sferrare attacchi anche al protocollo di autenticazione di server SSL (Secure Socket
Layer) utilizzato per la creazione di browser e server Web sicuri, come i prodotti
Microsoft e Netscape. Un attacco di questo tipo prevede che un hacker fungendo da
intermediario convinca il browser a connettersi a un server fittizio presentando al
browser l’aspetto di una sessione sicura. Un hacker intermediario è un hacker che si
inserisce nel flusso dei pacchetti che scorrono fra un client ed un server. In questo
modo l’hacker convince l’utente a rilevare determinate informazioni quali ad esempio
User ID e Password o altre informazioni riservate che verranno memorizzate nel
server fittizio. Un alto rischio di Hyperlink spoofing si verifica se l’utente preleva ed
esegue dal server fittizio applet Java pericolosi, credendo che tali applet vengano
forniti dal server sicuro e che debbano pertanto essere considerati sicuri. L’attacco
Hyperlink spoofing rende palese un difetto nel modo in cui la maggior parte di
browser impiegano i certificati digitali per rendere sicure le sessioni. L’attacco
spoofing tramite collegamenti ipertestuali non attacca la crittografia a basso livello o il
funzionamento del protocollo SSL. Di conseguenza l’attacco può essere sferrato anche
ad altre applicazioni garantite da un certificato, a seconda del modo in cui tali
applicazioni impieghino i propri certificati. Il problema principale è che gli attacchi
Hyperlink spoofing si basano sul fatto che il certificato SSL fornito contiene
informazioni errate (ad esempio il nome del DNS). Quindi nonostante gli indirizzi
URL sembrino corretti e sembrino riflettere le attività dell’azienda che possiede il sito
Web cui si fa riferimento, non sempre questo accade. Quando viene registrato un
dominio le autorità Internet assicurano che il DNS non sia già stato registrato da altri
ma non assicurano che non violi le leggi di copyright.
CAPITOLO VI- RECS 101
144
5. Web Spoofing: E’ un tipo d’attacco che prevede di creare una copia falsa ma
convincente dell’intero sito Web [31]. Il sito Web ha tutto l’aspetto del sito vero e
proprio, ovvero contiene le stesse pagine e gli stessi link del vero sito WEB, ma è
completamente sotto il controllo dell’hacker. In un attacco di questo tipo, l’hacker può
osservare o modificare tutti i dati che vanno dalla vittima al server del sito Web.
Inoltre, l’hacker può controllare tutto il traffico di ritorno dal server Web alla sua
vittima. In seguito l’hacker può impiegare vari tipi di attacco tra cui ad esempio lo
sniffing e lo spoofing. Con lo sniffing l’hacker osserva passivamente il traffico della
rete. Lo spoofing invece prevede un’attività di manipolazione in quanto l’hacker
convince un host di essere un altro computer fidato e pertanto si prepara a ricevere
varie informazioni. Ad esempio l’hacker può registrare i contenuti e le risposte che il
server invia al client (User ID, password ecc.). L’hacker può eseguire un’attività di
sorveglianza anche se la vittima ritiene di trovarsi in una connessione sicura.
Indipendentemente dal fatto che la connessione impieghi i metodi SSL o S-http,
l’hacker sarà comunque in grado di ingannare l’utente. Si potrebbe pensare che è
difficile per l’hacker sostituirsi all’intero World Wide Web ma, sfortunatamente non è
così. L’hacker non deve memorizzare l’intero contenuto del Web. Poiché il Web e, per
definizione, disponibile on-line, quando il server dell’hacker deve fornire una falsa
pagina, gli basta prelevarla e modificarla dal Web stesso.
6.11.1 Possibili contromisure
Sebbene il mondo dell’informatica sia in continua evoluzione trovare dei rimedi che
eliminino definitivamente tali problemi è molto difficile, tuttavia nel seguente paragrafo
vogliamo presentare alcune soluzioni che adottate potrebbero essere un modo per fronteggiare
queste problematiche. Rispecchiando lo schema precedente riportiamo di seguito le soluzioni
possibili:
CAPITOLO VI- RECS 101
145
1. Attacchi da password: Nelle reti l’intercettazione delle transazioni rappresenta uno
dei più gravi rischi che attualmente affligge i singoli utenti e le organizzazioni. Per
proteggersi dall’intercettazione dei pacchetti è opportuno crittografare tutte le
trasmissioni. I due tipi principali di crittografia sono la crittografia a chiave semplice
(o a chiave simmetrica) e la crittografia a chiave pubblica (o a chiave asimmetrica). La
crittografia a chiave semplice utilizza un'unica chiave nota ai due capi della
comunicazione i quali la usano per crittografare e decrittografare le informazioni. La
crittografia a chiave pubblica usa una chiave disponibile pubblicamente e una chiave
segreta conosciuta dall’utente. La maggior parte dei programmi normalmente
utilizzati per eseguire la crittografia dei messaggi, seguono lo standard PEM (Privacy
Enanched Mail) definito in dettaglio nelle RFC 1421, 1422,1423 e 1424. Gli algoritmi
di crittografia più utilizzati sono l’algoritmo RSA (Rivest-Shamir-Adleman) e
l’algoritmo Diffide-Hellman. Tali algoritmi possono quindi essere utilizzati per
marcare in modo digitale le trasmissioni. Questa tecnica consente ai destinatari dei
messaggi di verificare l’identità del mittente. Studi recenti hanno dimostrato che
misurando accuratamente il tempo necessario per eseguire le operazioni sulla chiave
privata, un hacker può dedurre gli esponenti fissi di Diffide-
Hellman, i fattori delle chiavi RSA e dunque violare questi sistemi di crittografia. In
termini realistici, il pericolo che qualcuno possa decodificare una trasmissione criptato
utilizzando un attacco di questo tipo è solo leggermente inferiore rispetto al pericolo
che qualcuno possa rubare la chiave privata dal disco fisso.
2. Attacchi alla sicurezza della rete e dei pacchetti: Gli attacchi sniffer su reti
distribuite possono essere evitati utilizzando degli schemi di identificazione come il
sistema delle password monouso o il sistema di autenticazione a ticket (come
Kerberos [32]). Alcuni sistemi monouso forniscono agli utenti la prossima password
nel momento in cui l’utente si connette dal sistema. Anche se sia le password
monouso che gli schemi Kerberos possono rendere molto più difficile lo sniffing delle
CAPITOLO VI- RECS 101
146
password su una rete non sicura, entrambi i metodi espongono al rischio di attacchi
attivi se il canale dati non è criptato o codificato. Un attacco attivo al protocollo
TCP/IP consente all’hacker di redirigere il canale TCP verso la propria macchina.
Dopodiché l’hacker può by-passare la protezione che offre un sistema di password
monouso o di autenticazione a ticket. La connessione TCP diviene vulnerabile a
chiunque sia in possesso di uno sniffer di pacchetti TCP e di un generatore di pacchetti
TCP posizionati sul percorso della connessione.
3. Attacchi al protocollo IP: Il modo più semplice per prevenire il sistema contro
questo tipo di attacchi a previsione di numero di sequenza consiste nell’assicurarsi che
il router, il firewall e ogni server del sistema abbiano attivato la protezione audit-trail.
Un audit-trail è una registrazione cronologica delle attività di sistema, sufficiente per
consentire la ricostruzione, la revisione e l’esame della sequenza di situazioni e di
attività che hanno riguardato o che hanno condotto a un’operazione, una procedura o
un evento in una transazione dal suo inizio ai suoi risultati finali. Utilizzando gli audit-
trail si può osservare quando un hacker tenta di attraversare il router e il firewall e
quando tenta di accedere al server. Utilizzando uno dei programmi di servizio
disponibili nel sistema operativo, si può richiedere che a seguito di un determinato
numero di richieste di accesso negate venga prodotto un avvertimento. Si deve
riconoscere che l’auditing e la manutenzione e l’osservazione degli audit-trail non
offrono una protezione “ a prova d’errore” contro gli attacchi al sistema. Se qualcuno
esegue lo “spoofing” del sistema, ad esempio, l’operazione non potrà essere
individuata dall’auditing. Se qualcuno ascolterà il sistema con uno sniffer, l’auditing
probabilmente non si accorgerà di nulla poiché l’hacker non accede ai dati del server
ma semplicemente osserva i dati in passaggio. Come tutti gli altri strumenti di
prevenzione degli attacchi, l’auditing-trail, se utilizzato correttamente, è solo uno degli
strumenti di un piano organico di sicurezza. L’auditing non può sostituire un firewall o
uno screening router o una politica di sicurezza. Analogamente gli altri sistemi
difensivi non possono sostituire l’auditing.
CAPITOLO VI- RECS 101
147
4. Hyperlink Spoofing: Se si impiegano già applicazioni Web che fanno affidamento
sull’autenticazione del server (ad esempio per il prelevamento di applet Java), l’unica
soluzione praticabile consiste nel far partire il browser da una pagina sicura in modo
che gli utenti possano fidarsi dei link iniziali e che un hacker non possa mai inviarli in
luoghi sospetti. Una pagina sicura è una pagina di cui si può verificare l’integrità e
questo, in genere, significa che tale pagina deve essere un file HTML locale o una
pagina su un server SSL. Se si vuole che il browser di un utente parta aprendo una
pagina SSL, si deve inviare l’indirizzo URL di tale pagina tramite mezzi difficili o
impossibili da intercettare (ad esempio un floppy o una lettera), altrimenti la pagina
potrebbe diventare il punto di partenza per l’attacco che s’intende prevenire. Tutti i
link contenuti in questa pagina dovrebbero inviare gli utenti su siti di provata
affidabilità e preferibilmente tutti i link dovrebbero essere di tipo SSL. L’affidabilità
può basarsi sui seguenti criteri:
a. Il sito deve essere condotto con criteri di sicurezza. Ovvero l’intero sito deve
essere reso sicuro contro gli attacchi e l’intercettazione delle pagine.
b. Il sito deve contenere link che conducono solo ad altri siti sicuri.
5. Web Spoofing: Questo genere di attacchi è estremamente pericoloso e praticamente
non è rilevabile. Le misure preventive che possono essere adottate si possono
riassumere nei seguenti punti:
a. Disabilitare nel browser gli script in modo che l’hacker non possa nascondere
l’evidenza dell’attacco;
b. Assicurarsi che la riga degli indirizzi del browser sia sempre visibile;
c. Fare attenzione all’indirizzo URL visualizzato dal browser, assicurandosi che
punti sempre al server a cui si pensa di essere connessi.
Questa strategia riduce fortemente i rischi di attacco anche se un hacker può
comunque colpire un utente dalla rete, specialmente coloro che non si preoccupano di
osservare strani comportamenti sulla riga degli indirizzi o della barra di stato. Con la
CAPITOLO VI- RECS 101
148
disattivazione degli script si perderà qualche utile funzionalità ma si potrà comunque
riattivare il uso all’interno dei siti fidati per disattivarli nuovamente quando si lascia il
sito fidato.La creazione di una soluzione a lungo termine è molto più difficile, poiché
occorrerebbe modificare il codice del browser in modo tale che programma visualizzi
sempre la riga dell’indirizzo offrendo una maggiore sicurezza così come la possibilità
di rendere sicuro il browser contro modifiche esterne, ovvero fare in modo che i
programmi Web non possano creare false barre di menù, false barre di stato ecc. Per le
pagine che il browser preleva utilizzando una connessione sicura, una migliore
indicazione di attivazione della connessione sicura potrebbe aiutare a garantire
un’effettiva sicurezza dell’utente. Invece di indicare semplicemente l’attivazione di
una connessione sicura, i browser potrebbero visualizzare con chiarezza il nome del
server che ha completato tale connessione.Fondamentalmente ogni approccio al
problema del Web-spoofing sembra essere affidato alla vigilanza dell’utente. Il fatto
che un amministratore di sistema possa realisticamente attendersi questo tipo di
vigilanza da tutti gli utenti della rete pone seri dubbi.
6.12 I PRINCIPALI PROBLEMI DI SICUREZZA DEGLI APPLET JAVA
Anche se Java rappresenta un ambiente di programmazione relativamente sicuro, occorre
considerare vari argomenti che aiutino a difendersi contro i problemi di sicurezza derivanti
dall’impiego di Java. Poiché la JVM interpreta gli applet Java localmente, in genere gli applet
consumano grandi quantità di risorse di sistema. Gli applet ostili o mal programmati possono
consumare troppe risorse di sistema utilizzando la maggior parte della CPU o della memoria
de computer. Quando un applet consuma troppe risorse, il computer può rallentare sino quasi
a bloccarsi. Questo stato di blocco è il risultato di un attacco. Nelle prime implementazioni di
Java (JDK 1.1.2) esisteva un bug nel verificatore di applet che consentiva a un applet
prelevato su un client che si trova all’interno di un firewall di collegarsi a un determinato host
CAPITOLO VI- RECS 101
149
al di là del firewall. Dopo la connessione, l’applet poteva trasmettere informazioni relative
alla macchina client invece che informazioni relative al server proxy così come dovrebbe fare
l’applet, aprendo la rete a un attacco spoofing.
In generale possiamo dire che il Java può soffrire di quattro tipi possibili di attacchi [33..38]:
1. Leakage (unauthorized attempts to obtain information belonging to or intended for
someone else),
2. Tampering (unauthorized changing/including deleting/of information),
3. Resource stealing (unauthorized use of resources or facilities such as memory or disk
space)
4. Antagonism (interactions not resulting in a gain for the intruder but annoying for the
attacked party).
Gli Applet Java utilizzano un sistema di sicurezza noto con il nome di Sandbox che
protegge il computer contro l’intrusione di applet ostili. Il modello Sandbox limita l’accesso
al sistema da parte dell’applet restringendolo a determinate aree del client.
Installazione Cache
SAND BOX Accesso Completo Trusted
Applet java Standard *
Applet java Trusted *
Installazione
permanente
Libreria Java standard * Libreria Java Trusted *
* Utilizzo dell’autenticazione
Tab. 6.10 Sisitema di sicurezza Sandbox di Java
La Tab. 6.10 si riferisce ad un’applet Java di tipo standard chiamato applet sandbox.
L’applet sandbox ha un accesso limitato alle risorse del sistema. Un applet sandbox non può
CAPITOLO VI- RECS 101
150
ad esempio accedere al disco fisso dell’utente, aprire nuovo canali di trasmissione o restituire
informazioni approfondite relative al client che esegue l’applet. Gli applet standard java e la
libreria standard sono applet sandbox. Il tipo trusted è una nuova variante del modello java, un
applet trusted ha accesso a tutte le risorse di sistema e opera all’esterno della sandbox. In
genere gli applet java trusted sono applet creati da un’organizzazione o all’interno di una
intranet aziendale oppure applet che l’autore firma prima della trasmissione via internet. In
generale non è possibile garantire la sicurezza degli applet trusted in quanto l’applet ha un
accesso completo alle risorse del sistema.
6.12.1 Architettura di sicurezza java
In accordo a quanto riportato in letteratura [36], l’applet Verifier [37] è una parte del
sistema run-time di java che assicura che l’applet segua determinate regole di sicurezza. Per
iniziare, l’applet verifier conferma che il file della classe segua le specifiche del linguaggio
java. L’applet verifier non presume che il file della classe sia stato prodotto da un compilatore
sicuro. Al contrario controlla nel file della classe l’esistenza di violazioni alle regole del
linguaggio e altre restrizioni riguardanti lo spazio dei nomi e chiudere altre via di fuga
impiegabili per uscire dal file della classe. In particolare l’applet verifier assicura che:
1. il programma non provochi l’overflow o l’underflow dello stack;
2. il programma esegua accessi validi alla memoria e ai registri;
3. i parametri di tutte le istruzioni bytecode siano corretti;
4. il programma non converta illegalmente i dati.
L’applet verifier svolge queste funzioni critiche analizzando le istruzioni contenute nel file
dell’applet. Un browser Web utilizza un solo class loader che il browser attiva all’avvio, dopo
questa fase il browser non può estendere, modificare o sostituire il caricatore di class. Gli
applet non possono creare o far riferimento a un proprio class loader. L’applet verifier è
indipendente dall’implementazione di riferimento Sun del compilatore java e dalle specifiche
CAPITOLO VI- RECS 101
151
di alto livello del linguaggio Java. L’applet verifier esamina il bytecode generato dal
compilatore java . La JVM si fida (e pertanto esegue) del byte code importato da internet solo
dopo che tale bytecode ha passato l’analisi del verifier. Per passare al verifier il bytecode deve
rispondere alla sintassi, alle firme degli oggetti, al formato del file della classe ed altre
prevedibilità dello stack run-time definiti dall’implementazione.
Gli applet vengono eseguiti in condizioni di sicurezza relativamente stringenti. L’applet
security manager è il meccanismo java che si occupa delle restrizioni sugli applet. Un browser
ha un solo manager della sicurezza. L’applet security manager si inizializza all’avvio del
browser e in seguito non può essere sostituito, modificato o esteso. Gli applet non possono
creare o far riferimento a un proprio gestore della sicurezza. Per una descrizione più
dettagliata dell’architettura di sicurezza Java si rimanda alle note bibliografiche [6..14].
6.13 RECS 101 SECURITY
Come evidenziato in precedenza RECS101 rappresenta un implementazione realistica di
un web server integrato capace di gestire al suo interno la JVM. Il problema della sicurezza
nel nostro caso presenta diversi vincoli non indifferenti che riguardano le scarse capacità di
calcolo del dispositivo realizzato. Sicuramente è quasi impensabile poter implementare tutti i
sistemi anti-intrusione presentati nei paragrafi precedenti. Nonostante ciò gioca a nostro
favore il fatto che essendo un dispositivo non standard che non ha al suo interno un sistema
operativo standard ciò permette di sfruttare le proprietà hardware del dispositivo. Per essere
più chiari i problemi per cui il dispositivo potrebbe essere vulnerabile sono principalmente
dovuti ad:
CAPITOLO VI- RECS 101
152
- possibile attacco alla password d’accesso al sistema;
- Attacchi al protocollo IP e alla sicurezza dei pacchetti;
- Hyperlink Spoofing;
- Web Spoofing.
Poiché la nostra applicazione si basa sulla JVM abbiamo un livello di protezione base che
comunque ci viene fornito dalla gestione delle Applet (come esposto precedentemente). Le
contromisure che abbiamo adottato per far fronte alle problematiche su esposte sono le
seguenti:
- Possibile attacco alla password d’accesso al sistema: RECS 101 non integra al suo
interno alcun sistema di gestione delle chiavi sia esse pubbliche che private,
trattandosi di un sistema embedded dedicato al controllo remoto di apparecchiature
elettronico il suo utilizzo sarà sicuramente riservato ad una cerchia molto ristretta di
utenti di conseguenza si può ipotizzare che gli utenti del sistema possano essere
definiti a priori. Ciò implica che il firmware del sistema deve essere programmato in
modo tale da inserire tutti i possibili utenti del sistema. La gestione del Dbase delle
password ed user ID viene effettuato mediante l’applet Java Stessa che andrà a leggere
un file crittografato posto all’interno del file system di RECS 101.
- Attacchi al protocollo IP e alla sicurezza dei pacchetti: Un attacco di questo tipo
viene in qualche moto ridotto mediante la crittografia del pacchetto contente lo stato
delle porte di I/O. Poiché come si è visto precedentemente le porte di I/O di RECS 101
sono codificate in un dato a 32 bit è possibile inserire un algoritmo di crittografia che
possa proteggere il contenuto dei dati. Nel caso in cui RECS 101 venga utilizzato con
una propria logica di controllo con operazioni di sniffing è pressoché impossibile
risalire all’algoritmo di controllo del sistema poiché questo è contenuto all’interno
dell’applet.
- Hyperlink Spoofing & Web Spoofing: L’implementazione di un supporto SSL
all’interno di RECS 101, per la sua complessità è pressoché impensabile. Di
conseguenza un attacco Hyperlink Spoofing sarebbe possibile. Per evitare ciò si può
CAPITOLO VI- RECS 101
153
pensare di adoperare due RECS 101 che lavorando in parallelo uno controlli gli stati
dell’altro, in questo modo la probabilità che entrambi i sistemi vengano attaccati
simultaneamente decresce di molto. Per quanto riguarda il Web Spoofing, si può
pensare di disattivare il supporto Java in RECS 101 però il prezzo da pagare è la
portabilità del dispositivo, nel senso che il dispositivo perderebbe tutte le proprietà
inerenti l’accesso alle porte di I/O tramite interfaccia Web. Poiché RECS 101 supporta
anche i Socket C è possibile scrivere delle applicazioni Client/Server in C che eseguite
localmente in un PC possono attivare una connessione con quest’ultimo. In questo
modo si risolvono tutti i possibili problemi di Hyperlink Spoofing e Web Spoofing.
CAPITOLO VII- ESPERIMENTO DIAMANTE UN CASO REALE D’UTILIZZO DI RECS 101
153
CAPITOLO VII
ESPERIMENTO DIAMANTE UN CASO REALE
D’UTILIZZO DI RECS 101
7.1 INTRODUZIONE
L’obiettivo di questo capitolo è quello di illustrare un caso pratico d’applicazione che ha
permesso di sperimentare in campo le potenzialità del sistema RECS 101. In particolare si
farà riferimento all’esperimento “Diamante” di fisica nucleare svoltosi presso i Laboratori
Nazionali del Sud di Catania che ha avuto come scopo quello di studiare il comportamento di
nuovi rivelatori al diamante [16] [17] . Il sistema, messo a punto per l’occasione, ha permesso
di monitorare da remoto il funzionamento di alcuni sistemi e strumenti alloggiati all’interno
della sala sperimentale in cui è avvenuto l’esperimento. I risultati di tale test hanno mostrato
l'ottima immunità ai disturbi dovuti a radiazioni di tipo nucleare attestandone quindi
l'eventuale utilizzo all'interno di ambienti radioattivi.
CAPITOLO VII- ESPERIMENTO DIAMANTE UN CASO REALE D’UTILIZZO DI RECS 101
154
7.2 ESPERIMENTO DIAMANTE
Nelle applicazioni in cui è previsto un elevato livello di radiazioni, l'utilizzo di un rivelatore
al diamante ha dimostrato, meglio di ogni altro materiale, la capacità di poter caratterizzare la
regione interna di un fascio di particelle emesse da un acceleratore. Le misure di intensità di
fascio all'interno di un esperimento di fisica nucleare sono di particolare importanza per le
applicazioni derivabili in ambito medico che utilizzino fasci di radiazioni. Per applicazioni di
questo tipo gli usuali rivelatori al silicio presentano delle forti limitazioni a causa proprio
delle elevate radiazioni a cui sarebbero esposti che si traducono in una irreversibile distruzioni
delle giunzioni in essi presenti. Usualmente le misure di intensità di fascio vengono effettuate
mediante delle tazze di Faraday posizionate dove il fascio viene stoppato. La limitazione di
tale tecnica sta nel fatto che il segnale emesso da questi rivelatori è talmente basso che non si
riesce ad avere una risoluzione spaziale del segnale limitandone la misura del profilo del
fascio in esame. L'esperimento Diamante condotto a Catania presso i Laboratori Nazionali del
Sud si propone uno studio sistematico di un fascio di protoni ottenuto mediante un
acceleratore di tipo tandem da 15 MV.
Fig. 7.1 Acceleratore Tandem dei Laboratori Nazionali del Sud
CAPITOLO VII- ESPERIMENTO DIAMANTE UN CASO REALE D’UTILIZZO DI RECS 101
155
I rivelatori al diamante sono stati progettati e realizzati a Roma nei laboratori di Tor Vergata.
Un rivelatore al diamante consiste di un film di diamante depositato tramite la tecnica
conosciuta come "Microwave Plasma Enhanced Chemical Vapor Deposition" su di un
substrato al silicio. Scopo dell'esperimento è stato quello di porre a confronto le misure
ottenute con tre diversi tipi di rivelatori ossia quelli al silicio, quelli al diamante e quelli
denominati tazza di Faraday. La foto seguente rappresenta uno schema della disposizione dei
rivelatori rispetto al fascio all'interno di una camera a vuoto.
Fig. 7.2 Schema funzionale dell’apparato sperimentale
Si notino i rivelatori al diamante fissati nel piatto rotante e la struttura metallica in acciao inox
della camera a vuoto (fig. 7.3).
Fig. 7.3 Particolari della fase di setup dell’esperimento.
CAPITOLO VII- ESPERIMENTO DIAMANTE UN CASO REALE D’UTILIZZO DI RECS 101
156
Le misure ottenute hanno testimoniato la stabilità del sistema e la sua riproducibilità
evidenziando proprietà non conosciute sino ad oggi ovvero l 'elevato guadagno del rivelatore
e l'ottimo tempo di risposta.
7.3 CONTROLLO REMOTO MEDIANTE RECS 101
Il sistema RECS 101 progettato per applicazioni di Telecontrollo e Teleassistenza di
ultima generazione, utilizzando la suite di protocolli TCP/IP è un sistema che permette di
ottimizzare le risorse logistiche (riducendone il numero delle connessioni) e soprattutto riduce
i costi di gestione lasciando maggiore libertà di concentrazione sul lavoro primario, che in
applicazioni di ricerca nel campo della fisica nucleare si traducono in operazioni per
l’acquisizione di dati provenienti da misure sperimentali. Il sistema RECS 101 ha avuto
l’occasione di poter prendere parte all’esperimento Diamante rappresentando un valido
strumento per il monitoraggio della sala sperimentale mediante le moderne tecnologie
Telecontrollo e Teleassistenza offrendo una soluzione sicura e professionale nettamente
superiore alle soluzioni analogiche utilizzate da diversi anni nella ricerca scientifica [Art.
CERN]. Sfruttando la combinazione vincente del micro embedded web server RECS 101 che
permette il controllo di 16 ingessi e di 16 uscite, in combinazione con una network camera
AXIS 2120 collegata ad un modulo audio AXIS 2191 (fig. 7.4), è stato possibile avere a
disposizione una postazione di Telecontrollo capace di gestire non solo immagini ma anche
capace di controllare lo stato di dispositivi esterni, quali sensori e di manovrarne altri quali ad
esempio attuatori.
CAPITOLO VII- ESPERIMENTO DIAMANTE UN CASO REALE D’UTILIZZO DI RECS 101
157
Fig. 7.4 Schema del sistema di videocontrollo e telecontrollo adoperato nell’Esperimento
Diamante.
In particolare per la prima volta è stato testato il dispositivo RECS 101 come sistema di
supervisione e controllo per il posizionamento di un bersaglio mobile oggetto del test
dell’esperimento, posto all’interno della camera a vuoto sperimentale ove ha avuto luogo
l'esperimento di Fisica Nucleare (fig 7.5). I risultati di tali test hanno mostrato l'ottima
immunità ai disturbi dovuti a radiazioni di tipo nucleare (nella fattispecie neutroni),
attestandone quindi l'eventuale impiego all'interno di ambienti radioattivi.
Fig. 7.5 Apparati per il Telecontrollo dell’esperimento Diamante confronto tra una foto (a)
ed un’immagine trasmessa dal sistema (b).
CAPITOLO VII- ESPERIMENTO DIAMANTE UN CASO REALE D’UTILIZZO DI RECS 101
158
L'integrazione del sistema RECS 101 con i dispositivi AXIS ed il sistema di movimentazione
hanno ampiamente dimostrato come sia possibile controllare da remoto tramite Internet un
impianto sperimentale per la ricerca nel campo della Fisica Nucleare ottimizzandone i costi ed
i tempi d'esecuzione. Ciò ha permesso di ridurre drasticamente i tempi d'intervento degli
operatori durante le varie fasi dell'esperimento che si sono tradotti in una riduzione dei rischi
da esposizione a radiazioni nucleari a cui normalmente queste persone sono soggette. Inoltre,
per la prima volta, più ricercatori da ogni parte del mondo hanno potuto connettersi alla sala
sperimentale via Internet e controllare la movimentazione del bersaglio. Utilizzando il modulo
audio è stato possibile interagire con gli operatori addetti al setup dell’esperimento
direttamente da internet disponendo di un canale video e di un canale audio bidirezionale che
ha permesso di rendere partecipi Professori e ricercatori nella risoluzione delle comuni
problematiche presenti in questa delicata fase.
CAPITOLO VII- ESPERIMENTO DIAMANTE UN CASO REALE D’UTILIZZO DI RECS 101
159
7.4 ARCHITETTURA DEL SISTEMA DI CONTROLLO
Fig. 7.6 Architettura del sistema di controllo remoto
La Fig. 7.6 mostra l’architettura adoperata per la realizzazione del test sperimentale per il
controllo remoto di strumenti posti all’interno della sala sperimentale in cui si è svolto
l’esperimento Diamante; RECS 101 si occupa di gestire l’accensione e lo spegnimento di
strumenti di misura posti all’interno della sala campionando i suoi ingressi che verificano lo
stato degli strumenti ogni 200 ms; una scheda d’interfaccia per la gestione di carichi di
potenza progettata e realizza appositamente per controllare gli strumenti di misura; una
network camera AXIS 2120 unitamente ad un modulo audio AXIS 2191 provvedono ad
inviare immagini e suoni (bidirezionali).
Il sistema sperimentale ha permesso di poter controllare da remoto l’accensione e lo
spegnimento di strumenti quali: un analizzatore di spettro ed un oscilloscopio utilizzati per
monitorare alcuni parametri sensibili dell’esperimento. Le problematiche inerenti questa
soluzione sono state dettate dall’esigenza di poter visualizzare e gestire da remoto le
immagini di questi strumenti che per la loro sensibilità dovevano stare proprio all’interno
CAPITOLO VII- ESPERIMENTO DIAMANTE UN CASO REALE D’UTILIZZO DI RECS 101
160
della sala sperimentale poiché un eventuale connessione alle sonde troppo lunga avrebbe
pregiudicato le misure.
In questo modo adoperando un semplice browser internet quale ad esempio Internet Explorer
o Netscape è stato possibile gestire l’intero sistema tramite Internet (fig. 7.7). Ciò ha
permesso di far interagire col sistema più persone in modo simultaneo da più parti del mondo.
Fig. 7.7 Consolle di controllo degli apparati nella sala acquisizione dati.
7.5 INTERFACCIA DI POTENZA
Poiché il sistema RECS 101 dispone di 16 ingressi e 16 uscite digitali di tipo TTL
indirizzabili singolarmente, è stato necessario progettare e realizzare una scheda elettronica
d’interfaccia che fosse capace di gestire dei carichi di potenza e che al tempo stesso fosse
totalmente disaccoppiata da RECS 101.
La scheda d'interfaccia di seguito chiamata RECS Relay rispecchia rigorosi criteri di
sicurezza che permettono a questi dispositivi un totale isolamento del carico dal sistema di
CAPITOLO VII- ESPERIMENTO DIAMANTE UN CASO REALE D’UTILIZZO DI RECS 101
161
controllo grazie ai diversi livelli d'isolamento in essi implementati: isolamento ottico,
galvanico, protezione delle uscite relay tramite variatori (fig. 7.8).
Fig. 7.8 Interfaccia RECS Relay
Utilizzandole unitamente a RECS 101 si ottiene un sistema di controllo basato su tecnologia
TCP/IP che può comandare l'azionamento di carichi e sistemi di potenza. Nel caso
dell’esperimento Diamante questa scheda ha permesso di comandare da remoto degli
strumenti di misura ed il posizionamento del bersaglio (fig 7.9 e 7.10).
Fig. 7.9 Particolare della sala sperimentale in cui si evince la scheda RECS Relay
CAPITOLO VII- ESPERIMENTO DIAMANTE UN CASO REALE D’UTILIZZO DI RECS 101
162
Fig. 7.10 Sistema di controllo TCP/IP per il comando di carichi di potenza
Le caratteristiche tecniche del sistema si possono riassumente nei seguenti punti:
• 16 ingressi;
• Comando di carichi con assorbimento Max di 10A e una tensione max di 250 V AC o 30V
DC;
• Pilotaggio delle interfacce in continua con ingressi positivi TTL (la tensione di pilotaggio
può essere variata inserendo dei resistori negli opportuni pad della scheda);
• Corrente di pilotaggio ~20mA;
• Relay ad estrazione rapida con zoccolo;
• Grado di protezione IP00;
• Fissaggio a scatto rapido su profilato DIN 35.
CAPITOLO VII- ESPERIMENTO DIAMANTE UN CASO REALE D’UTILIZZO DI RECS 101
163
Fig. 7.11 Schema elettrico
Fig. 7.12 Connettore d’ingresso
Nelle figure 7.11 e 7.12 si riporta rispettivamente lo schema elettrico e la piedinatura del
connettore d’ingresso della scheda RECS Relay
CAPITOLO VIII- UN GATEWAY X10-TCP/IP PER IL CONTROLLO REMOTO DI UNA CAMERA A VUOTO
164
CAPITOLO VIII
UN GATEWAY X10-TCP/IP PER IL CONTROLLO
REMOTO DI UNA CAMERA A VUOTO
8.1 INTRODUZIONE
L’obiettivo di questo capitolo è quello di illustrare un caso di studio che dimostri come la
convergenza di più tecnologie di controllo remoto possa portare un forte contributo per
l’ulteriore ottimizzazione del supporto agli esperimenti di fisica nucleare. La soluzione di
seguito descritta e presentata permette di ridurre ulteriormente la necessità d’introdurre nuovi
cablaggi dovuti dall’esigenza d’interconnessione di nuovi apparati e sistemi durante gli
esperimenti per la fisica nucleare. Per questo motivo viene proposta una nuova soluzione che
prevede l’integrazione di un sistema X10 con un sistema TCP/IP basato su micro web server
embedded per aggiungere funzionalità e supporto al sistema di controllo remoto per la
produzione del vuoto progettato per lavorare con tecnologia Profibus descritto nei capitoli
precedenti. Normalmente lo standard X10 si basa su di un protocollo utilizzato nel campo
della Home automation non è utilizzabile per applicazioni scientifiche poiché essendo molto
semplice implementa nativamente pochi comandi. Per questo motivo verrà descritto ed
implementato un nuovo protocollo X10 che rappresenta di fatto un’estensione del protocollo
classico con comandi più potenti capaci di supportare la comunicazione bidirezionale (grazie
ad una programmazione ad hoc del firmware del sistema hardware), permette di gestire
maggiori informazioni riguardanti l’applicazione da controllare. La tecnologia che verrà
presentata permette una drastica riduzione delle informazioni che transitano nella linea
CAPITOLO VIII- UN GATEWAY X10-TCP/IP PER IL CONTROLLO REMOTO DI UNA CAMERA A VUOTO
165
elettrica e sarà teoricamente possibile connettere e controllare fino a 65000 dispositivi. Il
sistema proposto si basa su di un’unità sperimentale le cui funzioni hanno tutte le
caratteristiche di un gateway tra il protocollo X10 e la suite di protocolli TCP/IP. Il sistema
dotato di un’interfaccia Java di tipo “Applet” può essere gestito utilizzando un comune
browser Internet tipo Internet Explorer o Netscape. La caratteristica principale dell’utilizzo di
un’Applet Java aggiunge al sistema la massima portabilità su diversi sistemi operativi e la
capacità da parte dell’utente finale di personalizzare e modificare l’interfaccia grafica GUI
(aggiungere/rimuovere dispositivi, sensori ecc.) senza aver di bisogno di alcuna esperienza di
programmazione in JAVA. In particolare viene presentata l’implementazione di un sistema di
controllo del vuoto di una camera a vuoto speciale usata per sviluppare e testare sistemi di
rivelazione di particelle operanti in condizioni di vuoto spinto. Il sistema nel suo complesso
include due pompe da vuoto, due sensori per il vuoto ed un PLC. Le due pompe lavorano in
sequenza poiché ognuna di esse opera in un determinato range di pressione. Il PLC viene
impiegato per monitorare la pressione nella camera e contiene una logica capace di far
commutare il funzionamento di ogni pompa [20]. In questa applicazione si dimostra come sia
possibile combinare le caratteristiche dell’intelligenza decentrata con una stazione di
supervisione capace di intervenire manualmente sul sistema da remoto sfruttando la
combinazione vincente di un sistema X10 con un micro embedded web server con
funzionalità Java intergrate che di fatto nel suo complesso rappresenta un mini gateway X10.
8.2 INTRODUZIONE AL PROTOCOLLO X10
Il protocollo X10 rappresenta oggi uno standard “De Facto” nei sistemi per la Home
automation che si basano sulla trasmissione Power Line Carrier (P.L.C) [42]. Largamente
utilizzato per applicazioni domestiche [44]..[48], sino ad oggi ha avuto una limitata estensione
nelle applicazioni sperimentali come quelle qui descritte. Concettualmente un sistema X10
permette di veicolare delle informazioni e quindi dati all’interno di una linea elettrica. Questo
CAPITOLO VIII- UN GATEWAY X10-TCP/IP PER IL CONTROLLO REMOTO DI UNA CAMERA A VUOTO
166
semplice concetto è una grande innovazione nei processi di controllo dei sistemi di
comunicazione, arrecante un cospicua serie di vantaggi (qualcuno direttamente, altri
indirettamente) i quali si riflettono nelle metodologie e nelle tecniche usate per
l’autoprogettazione degli impianti [44]. Un sistema X10 tipico consiste di più moduli X10
interconnessi alla linea elettrica che viene utilizzata come mezzo trasmissivo. Normalmente
un’interfaccia PC dotata di connessione seriale viene utilizzata per generare i comandi x10 ai
vari dispositivi periferici. Quest’ultimi si occupano di ricevere ed attuare i comandi ad essi
impartiti. Una generica rete X10 può essere rappresentata come in fig. 8.1
Fig. 8.1 Tipica rete X10
8.2.1 Cenni sulla teoria della trasmissione X10
Il sistema di trasmissione X10 [42] si basa sulla sincronizzazione e l’invio delle
informazioni sfruttando lo zero crossing rate della sinusoide che compone il segnale di una
linea elettrica. Le specifiche indicano una trasmissione il più possibile prossima al punto
d’attraversamento dello zero entro 200 microsecondi da quest’ultimo. L’unità master del
sistema fornisce un’onda quadra a 60 Hz caratterizzata da un ritardo massimo di 100 μs
dall’attraversamento dello zero della sinusoide della linea elettrica (zero crossing). Le
informazioni sono rappresentate in binario e più specificatamente:
- l’1 è rappresentato da un burst di 120 KHz nello zero;
POWER LINE
Master
Unit
Appliance
Appliance
CAPITOLO VIII- UN GATEWAY X10-TCP/IP PER IL CONTROLLO REMOTO DI UNA CAMERA A VUOTO
167
- lo 0 è rappresentato dall’assenza di un burst di 120 KHz nello zero.
L’unità master modula i suoi ingressi con impulsi della durata di 1 ms su di una portante a
120 KHz. Tali impulsi vengono trasmessi tre volte in modo tale da farli coincidere con il
punto d’attraversamento dello zero di tutte le tre fasi di un sistema a distribuzione a tre fasi
(fig. 8.2).
Fig. 8.2 Relazioni temporali relative all’attraversamento dello zero
Per maggiore chiarezza, i segnali rappresentati in fig. 2 sono mostrati come se fossero stati
filtrati da un filtro passa alto, mentre la sinusoide a 60 Hz è mostrata solo per fornire un
riferimento. In realtà i segnali sono sovrapposti alla sinusoide di 60Hz il cui andamento è
mostrato in fig. 8.3.
Fig. 8.3 – Segnali sovrapposti alla sinusoide di 60 Hz
CAPITOLO VIII- UN GATEWAY X10-TCP/IP PER IL CONTROLLO REMOTO DI UNA CAMERA A VUOTO
168
Una trasmissione completa del codice include undici cicli della sinusoide, più
specificatamente:
- i primi due cicli rappresentano lo Start Code;
- 4 cicli rappresentano l’House Code;
- gli ultimi 5 cicli rappresentano rispettivamente un Number Code (da 1 a 16) o un
Function Code (On, Off ecc).
Questo blocco completo (Start Code, House Code, Key Code) deve essere trasmesso in gruppi
di 2 su 3 cicli tra ogni gruppo di 2 codici. Fanno eccezione le funzioni Bright e Dim che
devono essere trasmesse di continuo senza gap tra i codici. All’interno di ogni blocco dei dati,
ogni 4 o 5 bitcode deve essere trasmesso in forma completa mezzo ciclo della sinusoide
componente la linea elettrica. La tab 8.1 mostra la codifica in binario degli House Cose e dei
Key Code. Il codice di partenza è unico ed è sempre 1110 ed è l’uno a fare eccezione
nell’introduzione della trasmissione completa del mezzo ciclo.
Tab. 8.1 House Code e Key Code
CAPITOLO VIII- UN GATEWAY X10-TCP/IP PER IL CONTROLLO REMOTO DI UNA CAMERA A VUOTO
169
Consideriamo alcuni di questi codici:
1. Una particolare richiesta d’identificazione detta “Hail Request” viene trasmessa per
vedere se sono presenti all’interno della linea altri trasmettitori. Questo permette di
assegnare differenti House Code nel caso in cui questa richiesta venga accolta “Hail
Acknowledge”;
2. Nell’istruzione “Pre-Set-Dim” il bit D8 rappresenta il bit più significativo del livello
Dim da impostare ed I bit H1,H2,H4 e H8 rappresentano I bit meno significativi;
3. Il codice dati esteso è seguito da 8 byte che possono rappresentare il dato analogico
(una volta convertito in digitale). Non ci devono essere gap tra il codice esteso dei dati
e i dati attuali, e nessun gap tra i byte dei dati. I primi 8 byte possono essere adoperati
per comunicare quanti byte dei dati li seguiranno. Se sono lasciati dei gap tra i byte
dati questi potrebbero essere ricevuti erroneamente da moduli X10 e quindi potrebbero
introdurre degli errori.
Il codice esteso è simile ai dati estesi: gli 8 byte che seguono il codice esteso (senza gap)
possono rappresentare codici addizionali. Questo permette allo sviluppatore di espandere i
256 codici base implementati nello standard. I moduli ricevitori X10 richiedono un
“silenzio” dopo almeno 3 cicli tra ogni coppia di 11 bit di codice trasmesso. L’unica
eccezione a questa regola riguarda i codici Bricht e Dim. Questi ultimi sono trasmessi di
continuo senza gap tra gli 11 bit del codice dim e gli 11 bit del codice Bright. Un ciclo di
3 gap è necessario tra codici diversi, per esempio tra Bright e Dim, o 1 e Dim, o On e
Bright ecc.
CAPITOLO VIII- UN GATEWAY X10-TCP/IP PER IL CONTROLLO REMOTO DI UNA CAMERA A VUOTO
170
8.3 PROTOCOLLO X10 MODIFICATO
Considerando che il protocollo X10 di sua natura è molto semplice e come descritto
precedentemente implementa nativamente pochi comandi per cui sarebbe stato impensabile
adoperare un tale sistema in ambito della ricerca sperimentale specie nel campo della Fisica
Nucleare. Di conseguenza sfruttando la predisposizione di tale protocollo ad essere
modificato e quindi integrato con altri comandi ci ha permesso di mettere a punto un sistema
master basato su microprocessore che oltre ad integrare i normali comandi X10 ne integrasse
altri con funzionalità più avanzate [20].
Le caratteristiche del sistema master sono le seguenti:
- Comunicazione bidirezionale su protocollo X10;
- Interfaccia seriale RS-232;
- Buffer FIFO da 80 bytes;
- Gestione delle collisioni e ritrasmissione automatica delle informazioni;
- Compatibilità con lo standard X10 ed il suo codice esteso e funzioni estese;
- Supporto del protocollo standard per messaggi sino a 127 bit di lunghezza;
- Riconoscimento in automatico della frequenza di lavoro della linea elettrica;
L’unità in questione di seguito denominate PLI (Power Line Interface) è stata sviluppata per
poter permettere l’interfacciamento dei moduli X10 detti anche “Appliance” con PC o altri
sistemi embedded capaci di dialogare con essa mediante l’interfaccia RS232. I sistema è
capace di ricevere ed inviare tutti i codici X10 siano essi standard che estesi, le funzioni estese
e messaggi personalizzati che possono raggiungere una lunghezza massima di 127 bit.
L’utilizzo di un ampio buffer permette di eliminare i cicli di attesa durante le trasmissioni
X10. Il sistema di Collision Avoidance e detec, la ritrasmissione automatica delle
informazioni permette di ottenere un’elevata affidabilità della trasmissione. Il protocollo
seriale implementato per la sua estrema semplicità permette di controllare tutte le funzionalità
CAPITOLO VIII- UN GATEWAY X10-TCP/IP PER IL CONTROLLO REMOTO DI UNA CAMERA A VUOTO
171
interne del PLI tipo: abilitare o disabilitare la trasmissione a tre fasi, abilitare o disabilitare la
trasmissione doppia, settare il sistema per operare su frequenze a 50 o 60 Hz ecc.
Per potenziare ulteriormente le funzionalità del PLI abbiamo pensato di interfacciarlo con un
unità basata su micro embedded web server che mediante un’interfaccia seriale-TCP/IP fosse
capace di far gestire il PLI tramite internet e con il pieno supporto delle Java Applet [43].
Il sistema che si ottiene è di fatto un gateway X10-TCP/IP con elevate caratteristiche di
portabilità (fig. 8.4 ).
Fig. 8.4 Gateway X10- TCP/IP
8.3.1 Formato dei messaggi
Il messaggio si compone di una sequenza di byte. Il primo nibble indica il tipo del
messaggio. Il PLI è in grado di gestire due tipi di messaggi (vedasi la tab. 8.2)
Valore Binario Descrizione
0010 Dati PLI
0001 Dati Linea elettrica
Tab. 8.2 Messaggi gestiti dal PLI
X10 Master Unit RS232-TCP/IP
converter
X10 TCP/IP Gateway
CAPITOLO VIII- UN GATEWAY X10-TCP/IP PER IL CONTROLLO REMOTO DI UNA CAMERA A VUOTO
172
Consideriamo il primo caso ovvero quello riguardante lo scambio di dati con il PLI. La tab.
8.3 rappresenta la frame con cui vengono codificati tali messaggi.
Tipo Lunghezza Dato CheckSum
1° nibble 2° nibble N Bytes (max 14 byte) 1 byte
Tipo del messaggio Numero di bytes nel campo dati -1 Dati Somma dei byte
precedenti
Tab. 8.3 Codifica del frame per lo scambio dei dati con il PLI
Il secondo nibble contiene il numero di byte meno uno contenuti nel campo dati; il campo dati
può contenere da 1 a 14 byte; in fine il campo Checksum rappresenta la somma di tutti i byte
precedenti ed è usato per il controllo degli errori di trasmissione. La tab 8.4 riportata di
seguito riassume tutti i possibili comandi e funzioni che possono essere gestiti dal PLI.
Valore del
1° Byte
Funzione Valore del
prossimo
byte (hex)
Tipo di dato Descrizione
04 SendUnitType 06
00
UnitTypeValue Tipo di unità PLI
06
01
UnitTypeValue Tipo di unità PLI-P
0E Request 03 SWRelease Richiesta versione firmware
04 UnitType Richiesta tipo unità
10 PowerLineFrequency Richiesta frequenza linea elettrica
20 TxAck Richiesta se l’Ack è attivo o
disattivo
CAPITOLO VIII- UN GATEWAY X10-TCP/IP PER IL CONTROLLO REMOTO DI UNA CAMERA A VUOTO
173
21 3PhaseTransmission Richiesta se la trasmissione a tre
fasi è attiva o disattiva
22 TwiceTransmission Richiesta se la trasmissione doppia
è attiva o disattiva
23 ReTXAttempts Richiesta del numero max di
tentativi per la ritrasmissione
30
TT
Statistics TT=Tipo
40 CurrentTime
42 CurrentDate
Valore del
1° Byte
Funzione Valore del
prossimo
byte (hex)
Tipo di dato Descrizione
OF Values 03
W
SWRelease Versione del Firmware.
10
PP
PowerLineFrequency Frequenza della linea elettrica. PP
riporta I valori 50 o 60 (decimanli)
20
X
TxAck Riporta se gli Ack sono abilitati o
disabilitati
21
X
3PhaseTransmission Riporta se la trasmissione a tre fasi
è abilitata o disabilitata
22
X
TwiceTransmission Riporta se la trasmissione a due
fasi è abilitata o disabilitata
23
X
ReTXAttempts Riporta il numero di ritrasmissioni
nel caso di fallimento. I valori
possibili variano da 1 a 15.
Default = 8
40 | 41 CurrentTime
CAPITOLO VIII- UN GATEWAY X10-TCP/IP PER IL CONTROLLO REMOTO DI UNA CAMERA A VUOTO
174
42 CurrentDate
Valore del
1° Byte
Funzione Valore del
prossimo
byte (hex)
Tipo di dato Descrizione
20 SettingSystem 20
X
TxAck Abilita o Disabilita la conferma di
una corretta trasmissione.
X=0 disabilitata X=1 abilitata.
Default= abilitata
21
X
3PhaseTransmission Abilita o Disabilita la trasmissione
a tre fasi.
X=0 disabilitata X=1 abilitata.
Default= abilitata
22
X
TwiceTransmission Abilita o Disabilita la trasmissione
a due fasi.
X=0 disabilitata X=1 abilitata.
Default= abilitata
23
X
ReTXAttempts Setta il numero massimo di max di
prove di ritrasmissione in caso di
collisione prima di cancellare la
trasmissione
Valori di X da 0 a 15
Default = 8
Valore del
1° Byte
Funzione Valore del
prossimo
byte (hex)
Tipo di dato Descrizione
30 Statistics 00
SS SS
RR RR
CC CC
AllStatistics Pacchetti inviati
Pacchetti ricevuti
Pacchetti cancellati
Collisioni
CAPITOLO VIII- UN GATEWAY X10-TCP/IP PER IL CONTROLLO REMOTO DI UNA CAMERA A VUOTO
175
OO OO
40 | 41 SetCurrentTime SS SS Setta l’orologio del sistema in
secondi, 40 e 41 indicano
rispettivamente, AM e PM.
I valori validi sono compresi tra 0
e 43199 (11:59:59)
42 SetCurrentDate GG GG Setta la data del sistema da
01/01/2003 al 06/06/2182
F0 HardwareFailure 10 PowerLine Riporta un errore di trasmissione
Txo Rx sulla rete elettrica
11 ZeroCrossing
FF SystemInformation 10 BufferOverflow Indica che il buffer in ingresso del
PLI è pieno
22
TX
XX
CollisionDetect Sono state trovate delle collisioni
mentre si tentava di trasmettere il
bit XX sulla fase T
23 TxCancelled E’ stato raggiunto il numero max
di ritrsmissioni
30 ChecksumError Errore nella Checksum
Tab. 8.4 Comandi e funzioni gestibili dal PLI
Per maggiore chiarezza riportiamo di seguito alcuni esempi che chiarificano la codifica
appena esposta (i valori espressi in con codifica esadecimale):
Esempio 1. Richiesta della versione del firmware:
Il computer invia al PLI: 23 0E 03 34
Il PLI risponde supponendo che la versione del firmware sia 2.01: 24 0F 03 21 57
CAPITOLO VIII- UN GATEWAY X10-TCP/IP PER IL CONTROLLO REMOTO DI UNA CAMERA A VUOTO
176
Esempio 2. Richiesta del tipo di unità:
Il computer invia al PLI: 23 0E 02 33
Il PLI risponde: 24 04 06 00 2E
Esempio 3. Buffer seriale pieno.
Quando il buffer della porta seriale è pieno il PLI invia un messaggio d’errore al computer: 23
FF 10 32. Il computer deve quindi attendere sino a quando il buffer non viene svuotato. Si
noti che l’ultimo messaggio inviato può andare perso se la trasmissione non è stata
completata.
Consideriamo adesso il caso della codifica della frame che deve essere trasmessa tra il PLI e i
vari appliance presenti nella rete X10. La tab. 8.5 mostra la codifica adoperata per la
trasmissione e ricezione dei dati sulla linea elettrica.
Tipo Lunghezza Dato CheckSum
4 bit 11 bit N bit 1 bytes
0 0 0 1 L L L L L L L L L L L D D . . . D C C C C C C C C
1° byte 2° byte Bytes intermedi Ultimo byte
Tipo di
messaggio
Numero di bit del campo dati Dati Somma di tutti i byte precedenti
Tab 8.5 Frame relativa ai dati trasmessi o ricevuti lungo la linea elettrica
CAPITOLO VIII- UN GATEWAY X10-TCP/IP PER IL CONTROLLO REMOTO DI UNA CAMERA A VUOTO
177
Il PLI invia sulla linea elettrica tutti I bit indicati nel campo lunghezza partendo dall’ultimo
bit del secondo byte del messaggio.
Esempi
Per inviare un indirizzo X10 “A-1” il computer invia: 10 12 CC EE (i bit in
eccesso non sono presi in considerazione);
Per inviare il commando “A ON” il computer invia: 10 12 C5 E7
Per inviare un codice X10 esteso ad “A-1” il computer invia: 10 3A CF 60 00
10 89
Per inviare una funzione estesa (ad esempio il cambio d’indirizzo da A-1 a B-
4) il computers invia: 10 3A CC 20 0E A0 E4
In conclusione riportiamo la codifica della frame riferita agli Extended Message (tab. 8.5) e
quella riferita alle funzioni estese tab. 8.6.
Byte
2 6 11 15 23 31
1101 HouseCode Extended Code Key Code Data Command
4 bits 5 bits 4 bits 8 bits 8 bits
Tab 8.5 Extended Message
CAPITOLO VIII- UN GATEWAY X10-TCP/IP PER IL CONTROLLO REMOTO DI UNA CAMERA A VUOTO
178
1110 House Code Key Code Lunghezza Dati 0000
Start Code End Code
4 bit 5 bit 4 bit N*8 bit
Tab. 8.6 Codifica della frame delle funzioni estese
La codifica degli House Code e Key code è riportata nella tab 8.1. La tabella 8.7 riportata di
seguito riassume le funzioni estese implementate nel protocollo di comunicazione modificato.
Val (hex)
Dati Nome Funzione Descrizione
00 HHHHUUUU AAAAAAAA
AssignAddress Impostazione di House Code ed UnitCode. Il secondo byte del campo Dati è opzionale, verrà utilizzato solo per l’indirizzamento esteso.
01 HHHHUUUU AAAAAAAA
OldAddress Invia il vecchio HC e UC. Viene inviata quando c’è un cambio manuale di indirizzo e per confermare la ricezione di un cambio di indirizzo. La ricezione di questa funzione deve essere sempre confermata con un ACK. Viene inviata un massimo di 3 volte ad intervalli di 5 sec (a 100 bps). Il secondo byte del campo Dati è opzionale, verrà utilizzato solo per l’indirizzamento esteso.
02 XXXXXXXX XXXXXXXX
LTCValue Indicazione del numero di ore di funzionamento globale. Il 1º byte è LSB, l’altro MSB. Se il valore da riportare è inferiore a 256 ore il 2nd byte non viene utilizzato. Questa indicazione a 16 bit consente di contare sino a 7 anni e mezzo circa (2730 giorni 15 ore).
03 XXXXXXXX XXXXXXXX
ATCValue Indicazione del numero di minuti di funzionamento. Il 1º byte è LSB, l’altro MSB. Se il valore da riportare è inferiore a 256 ore il 2nd byte non viene utilizzato. Questa indicazione a 16 bit consente di contare sino a 45 giorni 12 ore 15 minuti.
CAPITOLO VIII- UN GATEWAY X10-TCP/IP PER IL CONTROLLO REMOTO DI UNA CAMERA A VUOTO
179
04 TTTTTTTT PPPPPPPP
UnitType Indica il tipo di unità. Il primo byte indica la categoria, il secondo il modello, quest’ultimo è opzionale. Consultare la tabella 8.8 per identificare i vari tipi di unità.
07 AbsentLoad Informazione di assenza di carico. Viene fornita quando viene disinserito il carico (oppure per rottura di esso, ad esempio lampada fulminata),oppure quando viene indirizzata l’unità che non presenta alcun carico collegato.
08 NewGuest Informazione di connessione di una unità in rete.
0E XXXXXXXX Request Richiede quello che è specificato nel secondo byte Guardare tabella 8.9
0F TTTTTTTT VVVVVVVV
ValueIs Risponde con i valori richiesti dalla funzione Request quando sono ad 8 bit. T indica il tipo di informazione. V il valore. Guardare tabella 8.10
10 AAAAAAAA ExtendedAddress Imposta il valore di indirizzo esteso da utilizzare
11 0000000X ExtendedAddressing Abilita o disabilita l’indirizzamento esteso. Funzione di tipo broadcast.
30 31
SSSSSSSS SSSSSSSS
TimeIs Specifica l’ora corrente in secondi. Viene utizzato anche il bit meno significativo che indica la funzione per rappresentare 17 bit. Tale bit superiore indica AM o PM, rispettivamente per valore 0 o 1. I valori validi sono da 0 a 43199 (11:59:59). It’s a broadcast function.
32 GGGGGGGG GGGGGGGG
DateIs Specifica la data corrente in giorni a partire dal 01/01/2000. Il 1º gennaio 2000 è rappresentato da 1. Valori validi dal 1/01/2000 al 6/06/2179. It’s a broadcast function
F0 XXXXXXX0 XXXXXXX1
SetSystemVariable Guardare tabella 8.11
F1 XXXXXXX0 RequestSystem Guardare tabella 8.11
F2 XXXXXXX0 SystemValue Guardare tabella 8.11
CAPITOLO VIII- UN GATEWAY X10-TCP/IP PER IL CONTROLLO REMOTO DI UNA CAMERA A VUOTO
180
XXXXXXX1
F3 XXXXXXXX LightFX Imposta l’effetto luce desiderato 0 = Normale 1 = Emergenza 10 = Christmas 1 11 = Christmas 2
FF XXXXXXXX … XXXXXXXX
Acknowledge Conferma la ricezione di un comando. I byte che seguono assumono significato diverso a seconda del contesto.
Tab. 8.7 Funzioni estese
Le tabelle 8.8…8.11 riassumono delle codifiche adoperate dalle funzioni estese descritte nella
tabella 8.7.
Categoria (hex)
Descrizione
Sigla(hex) Descrizone sigla
01 Lamp 00 DR01
02 Appliance
00 SH01
02 CE04
03 CE06
03 Controllo 00 MA03
04 Vari 00 IRC1
05 Universali 00 DE01
Tab 8.8 Unit Type (04H)- Specifica il tipo di unità
CAPITOLO VIII- UN GATEWAY X10-TCP/IP PER IL CONTROLLO REMOTO DI UNA CAMERA A VUOTO
181
Valore 2º byte (hex)
Nome funzione
Descrizione
00 Address Richiesta del nuovo indirizzo. L’unità invia questa richiesta e riceve risposta con la funzione AssignedAddess
01 OldAddress Richiesta del vecchio indirizzo
02 UnitType Richiede che tipo di unità sia
03 SWRelease Richiede la versione del firmware presente sull’unità
10 PSP Richiede la percentuale di potenza fornita
20 LTC Richiesta del valore LifeTimeCounter
21 ATC Richiesta del valore ActiveTimeCounter
30 31
Time Richiesta orario
32
Date Richiesta data
40 TimerStatus
80 Temperature Temperatura
81 Humidity Umidità relativa
82 Brightness Luminosità
Tab 8.9 Request (0Eh) -Richiede il valore specificato dal secondo byte indicato nella
seguente tabella. Tutte le funzioni Request vengono inviate per 3 volte al max ad intervalli di
5 sec (a 100 bps) sempre che non si sia ricevuta prima una risposta.
CAPITOLO VIII- UN GATEWAY X10-TCP/IP PER IL CONTROLLO REMOTO DI UNA CAMERA A VUOTO
182
Valore 2º byte(hex
)
Grandezza riportata
Descrizione
03 SWRelease
Versione del firmware. I primi 4 bit rappresentano la versione principale, i secondi le modifiche.
10 PSP Percentuale di energia fornita
80 Temperature
Riporta il valore di temperatura istantanea in °C
81 Humidity Umidità
82 Brightness Luminosità
Tab 8.10 ValueIs (0Fh) - Riporta il valore ad 8 bit indicato nella tabella.
Valore 2º byte (hex)
Grandezza riportata
Descrizione
0 TriphaseTXMode Trasmissione trifase
10 ExtendedAddressing Indirizzamento a 16 bit
Tab. 8.11 - SetSystemVariable (F0h) e RequestSystemVariable (F1h) e SystemValue (F2h)
Riporta il valore ad 8 bit indicato nella tabella
CAPITOLO VIII- UN GATEWAY X10-TCP/IP PER IL CONTROLLO REMOTO DI UNA CAMERA A VUOTO
183
8.3.2 Protocollo di accesso alla linea (MAC)
Considereremo tre casi distinti il caso in cui viene eseguito del codice X10 standard, il caso
in cui viene eseguito quello esteso ed infine quando vengono eseguite le funzioni estese:
Codice standard (X-10)
Il protocollo X10 usa la tecnica che si basa sulla seguente asserzione “Assicurarsi che il
sistema non stia ricevendo”. Per fare questo verificare che ci siano 4, 5 o 6 zero crossing,
scelti casualmente, privi di segnale, corrispondente al bit “0”. Se durante la trasmissione viene
rilevato un errore, ossia si stava trasmettendo 0 e viene letto 1 oppure la potenza del segnale
ricevuto e maggiore di quella del segnale trasmesso, bisogna annullare immediatamente la
trasmissione e riprenderla dopo un tempo scelto a caso fra 4,5 o 6 zero crossing con l’assenza
di “1”. Fra un messaggio e l’altro deve esserci un gap di almeno 4 cicli. I codici Dim e Bright
possono essere inviati anche senza gap. Il protocollo X10 standard non fornisce indicazioni se
annullare del tutto la trasmissione se si verificano errori per n volte consecutive. Se si
verificano errori per 8 volte consecutive è consigliabile annullare l’operazione di
trasmissione.
Extended Code (X-10)
Con il sistema degli Extended Code, il numero ed il tipo di messaggi che vengono usati
richiede che il trasmettitore sia in grado di prevenire le collisioni quando sia possibile, e nel
caso ci sia una collisione, deve essere rilevata e deve essere risolto il conflitto. Per fare questo
è stato utilizzato il seguente protocollo di acceso. Innanzitutto tutti i messaggi hanno la stessa
priorità. Il trasmettitore deve attendere, per accedere alla linea di trasmissione, 8, 9 o 10 z.c.
durante il quale non devono esserci trasmissione di “1”. Se viene rilevato un “1”, il conteggio
ricomincia. Se durante la trasmissione viene rilevato un conflitto, si rileva una collisione, si
annulla la trasmissione e riprende il ciclo, ossia si aspetta per 8, 9 o 10 z.c. privi di “1” e poi si
ricomincia a trasmettere. X-10 non fornisce indicazioni se annullare del tutto la trasmissione
CAPITOLO VIII- UN GATEWAY X10-TCP/IP PER IL CONTROLLO REMOTO DI UNA CAMERA A VUOTO
184
se si verificano errori per n volte consecutive. Se si verificano errori per 8 volte consecutive,
annullare l’operazione di trasmissione.
Funzioni estese
Esistono due livelli di priorità: Normale ed Assoluta. I messaggi con priorità normale
seguono le norme del paragrafo precedente. Le specifiche dei messaggi con priorità Assoluta
sono da definire.
8.3.3 Procedure
Per completezza analizziamo diverse procedure che il sistema può eseguire in funzione di
diversi stimoli provenienti dalla rete elettrica:
Indirizzo
Una nuova unità ha come indirizzo predefinito base P16 e indirizzo esteso 0.
All’inserimento in rete seguirà la procedura Automatic address setting with master. Ad ogni
successivo inserimento in rete l’unità comunicherà il suo arrivo con la funzione NewGuest.
Indirizzamento automatico con l’unità master
All’avvio l’unità NewDevice invia la richiesta Request(Address) per 3 volte ad intervalli di
5 secondi (su un collegamento a 100 bps). La risposta a questa richiesta viene data con la
funzione AssignAddress. Se riceve risposta, si manda al master la conferma, ossia si invia la
funzione SendOldAddress, il master confermerà la ricezione di SendOldAddress con l’invio
di un Ack.
Qui vengono schematizzate le funzioni (N=Nuova unità, M=Master)
N: Request(Address) per 3 volte al massimo con intervallo di 5 sec sino alla ricezione di
AssignedAddress
CAPITOLO VIII- UN GATEWAY X10-TCP/IP PER IL CONTROLLO REMOTO DI UNA CAMERA A VUOTO
185
M: AssignAddress
N: SendOldAddress per 3 volte al massimo con intervallo di 5 sec sino alla ricezione di ACK
M: ACK
Se non riceve risposta eseguirà la procedura ogni volta che verrà avviata l’unità sino a quando
perderà la proprietà NewDevice. La proprietà NewDevice = False dopo l’arrivo di
AssignedAddress.
È possibile recuperare da parte del master una sessione di impostazione dell’indirizzo con la
funzione Request (OldAddress).
CAPITOLO VIII- UN GATEWAY X10-TCP/IP PER IL CONTROLLO REMOTO DI UNA CAMERA A VUOTO
186
8.4 CARATTERISTICHE DEL GATEWAY X10
Il sistema proposto nel suo complesso si compone di due unità un modulo per la gestione
dei segnali X10 (unità master) ed un altro che è un web server embedded identico a quello
descritto nel capitolo VI con l’unica differenza che anziché avere delle porte di I/O è stato
dotato di una porta seriale RS-232 (fig. 8.5).
Fig. 8.5 – X10 TCP/IP Gateway, funzionalità
I due sistemi master unit (PLI) ed embedded web server si interfacciano mediante una
connessione seriale basata su protocollo RS232. Una volta collegato ad una rete Ethernet,
l’intero sistema offre una piattaforma hardware e software che ne permette la
programmazione mediante un linguaggio ad alto livello quale il Java. Tale caratteristica
permette di poter gestire l’interfaccia utente tramite un’Applet Java parametrica (si veda il
capitolo VI): in questo modo l’utente finale può sviluppare la propria applicazione di
controllo in modo molto veloce e sicuro senza dover essere in grado di programmare in Java.
Master Unit
X10 (PLI)
Embedded
Web Server
X10
Appliance
X10
Appliance
CAPITOLO VIII- UN GATEWAY X10-TCP/IP PER IL CONTROLLO REMOTO DI UNA CAMERA A VUOTO
187
Supportato da qualsiasi browser internet quale Internet Explorer o Netscape, il sistema
permette di gestire totalmente da remoto qualsiasi dispositivo o apparecchiatura elettronica in
pochi e semplici passaggi.
8.5 SISTEMA REMOTO PER IL CONTROLLO DEL VUOTO
L’applicazione presentata in questo articolo rappresenta un test svolto su di un sistema di
supporto per lo sviluppo e la messa a punto di un rivelatore di particelle. Uno schema
completo dell’impianto è riportato in fig. 8.6; esso comprende una camera di vuoto, una
pompa rotativa di pre vuoto, una turbo pompa per creare il vuoto, un indicatore visivo di
pressione, due trasduttori di pressione per valori settati tra 1*10-3 ÷ 1*103 mbar e 1*10-9 ÷
1*10-3 mbar, quattro elettrovalvole, due per il ritorno dell’aria e due per l’estrazione dell’aria
dalla camera (pre vacuum e vacuum).
fig. 8.6 Schema del sistema per la generazione del vuoto
CAPITOLO VIII- UN GATEWAY X10-TCP/IP PER IL CONTROLLO REMOTO DI UNA CAMERA A VUOTO
188
Il controllo remoto del vuoto deve eseguire i seguenti compiti:
- Monitoraggio e regolazione automatica della pressione nella camera in base ad un valore
assegnato;
- Possibilità di intervento remoto su ognuno dei dispositivi attivati.
La fig. 8.7 mostra lo schema a blocchi relativo al sistema di controllo ideato per il vuoto. Al
suo interno si evince un PLC dedicato al controllo automatico del vuoto che acquisendo delle
informazioni sul sistema quali pressioni regola in automatico il vuoto presente nella camera. Il
PLC è dotato di opportuna interfaccia TCP/IP che si integra con quella proposta nel nostro
sistema X10.
fig. 8.7 Schema a blocchi del sistema di controllo per il vuoto
Compito del nostro sistema X10 è quello di permettere di agire manualmente sull’impianto
direttamente sulle pompe e sulle valvole che regolano il deflusso dell’aria che viene aspirata
dalle pompe (fig.8.8). Per questo obiettivo abbiamo utilizzato dei moduli dimmer e dei moduli
On/Off di cui i primi opportunamente interfacciati con le valvole ne permettono la
chiusura/apertura parziale ed i secondi permettono l’azionamento delle pompe per la
produzione del vuoto.
X10 TCP/IP
Gateway
PLC
Camera a vuoto
CAPITOLO VIII- UN GATEWAY X10-TCP/IP PER IL CONTROLLO REMOTO DI UNA CAMERA A VUOTO
189
Fig. 8.8 Schema del sistema di controllo remoto per il vuoto
Le operazioni rappresentate dal sistema di controllo possono essere descritte come segue:
· un circuito di acquisizione presente nel PLC converte le misurazioni analogiche della
pressione in dati binari gestiti dal PLC stesso;
· il PLC converte le misurazioni in binario ed esegue un algoritmo di correzione per
eliminare il rumore delle misure;
· quando è attivato il controllo automatico, il PLC utilizza l’informazione della pressione,
assieme al valore settato dall’operatore, applica il suo algoritmo di controllo agli attuatori e
conseguentemente regola la pressione nella camera.
- nella modalità manuale le funzioni di controllo del PLC sono disabilitate per cui
quest’ultimo si limiterà solo ed esclusivamente a fornire i valori letti dai trasduttori delle
pressioni. Sarà compito dell’operatore agire manualmente tramite il gateway X10 su valvole e
pompe.
Modulo
X10
Modulo
X10
Modulo
X10
Modulo
X10
Modulo
X10
Modulo
X10
Pompa1 Pumpa2 Valvola1 Valvola2 Valvola3 Valvola4
X10 TCP/IP
Gateway
CAPITOLO VIII- UN GATEWAY X10-TCP/IP PER IL CONTROLLO REMOTO DI UNA CAMERA A VUOTO
190
8.6 INTERFACCIA DI COMANDO
La fig. 8.9 mostra l’interfaccia di controllo che permette all’operatore di gestire
remotamente l’intero sistema per il controllo del vuoto nella camera. La parte centrale del
pannello di controllo riproduce uno schema dell’impianto insieme con gli indicatori delle
operazioni: ogni indicazione colorata in verde indica che il dispositivo associato è attivo, per
esempio una pompa o una elettrovalvola è aperta; rosso indica i rimanenti stati.
Fig. 8.9 Interfaccia GUI realizzata in Java per il controllo del vuoto
I due sensori di pressione hanno due indicatori a led; l’accensione di uno indica quale dei due
dispositivi è stato correntemente selezionato per acquisire le misurazioni della pressione.
Sulla parte alte destra sono situati due display: il primo è un grafico scorrevole in scala semi-
logaritmica mostrante l’andamento della pressione nella camera; il secondo visualizza la
pressione corrente in mbar. Il pannello principale contiene un numero di pulsanti, uno per
ogni stato di controllo dell’algoritmo locale. Il pannello di diagnosi ha due indicatori: Errore
di sistema, il quale indica la presenza di malfunzionamento dello strumento che fornisce la
pressione trasdotta, e Turbo 80%, il quale informa l’utilizzatore che l’80% della massima
CAPITOLO VIII- UN GATEWAY X10-TCP/IP PER IL CONTROLLO REMOTO DI UNA CAMERA A VUOTO
191
velocità della turbina è stato raggiunto. In basso a sinistra è situato un pulsante che permette la
commutazione del funzionamento del sistema da automatico a manuale.
CONCLUSIONI
192
CONCLUSIONI
Nel presente lavoro di tesi sono stati presentati i risultati relativi all’impiego delle nuove
tecnologie in ambienti per la ricerca nel campo della fisica nucleare.
In particolare sono state studiate ed introdotte delle particolari architetture per
l’integrazione di controlli distribuiti su bus di campo ProFiBus: una prima applicazione ha
riguardato il controllo remoto di un sistema elettromeccanico per il posizionamento di un
gruppo di rivelatori di ioni pesanti; l’impiego sinergico delle più recenti tecnologie software-
hardware nel campo della grafica vettoriale e della comunicazione su bus di campo hanno
permesso la realizzazione di un controllo remoto efficiente (impiegato con successo
all’interno dell’Esperimento C.H.I.C. del L.N.S. - I.N.F.N.), dotato di una interfaccia virtuale
in grado di restituire in tempo reale lo stato del sistema controllato.
La seconda applicazione ha riguardato il controllo in remoto di una camera a vuoto per lo
sviluppo ed il test di rivelatori di particelle: l’architettura di controllo distribuita, introdotta in
quest’ambito, ha evidenziato le peculiarità di decentralizzazione dell’intelligenza che stanno
alla base della filosofia Field Bus e per le quali due o più unità intelligenti di controllo
condividono le misure delle grandezze controllate grazie all’impiego di sensori intelligenti
interfacciati direttamente sul bus di comunicazione, potendo così interagire nei più svariati
modi.
La terza applicazione che ha visto come protagonista la realizzazione di RECS 101 un
dispositivo tecnologicamente avanzato che ha permesso di gestire tramite Internet apparati
elettronici posti all’interno di una sala sperimentale dell’I.N.F.N. durante l’esperimento
Diamante, ha mostrato grandi performance in termini di robustezza, versatilità ed immunità ai
CONCLUSIONI
193
disturbi. Particolarmente flessibile per gli “ultimi adattamenti” immancabili durante gli
esperimenti di fisica nucleare che non sono mai standard e che avvengono sempre in tempi
ben schedulati e rigidi.
In fine la soluzione che prevede l’utilizzo del gateway X10, pur necessitando di ulteriori
perfezionamenti, ha dimostrato di ridurre drasticamente le interconnessioni di attuatori con
particolare riferimento alle valvole. Il sistema grazie all’interfacciamento TCP/IP unitamente
al supporto Java, ha permesso di rendere molto elastica l’interfaccia grafica che grazie alla sua
parametrizzazione, diminuisce drasticamente i tempi di sviluppo di quest’ultima permettendo
di fatto una rapida messa in esercizio del sistema anche in presenza di modifiche sostanziali
dell’impianto da controllare.
Gli incoraggianti risultati ottenuti, aprono la strada a concreti sviluppi futuri. La facilità
con cui i vari sistemi possono essere espansi ed integrati, senza influenzare quelle preesistenti,
spingono ad una ottimistica previsione di espansione e perfezionamento di tali soluzioni
all’interno della ricerca applicata che si svolge presso i Laboratori Nazionali del Sud di
Catania: le intrinseche garanzie di integrità dei dati offerte, in un ambiente altamente nocivo
per l’uomo e caratterizzato da intense sorgenti elettromagnetiche e radioattive, ed i vantaggi
di semplificazione dei cablaggi, laddove tradizionalmente il controllo remoto vede l’impiego
di complessi collegamenti dedicati punto-punto, consentiranno il confluimento
contemporaneo di misure sperimentali e di messaggi di controllo su di un unico mezzo
trasmissivo o bus di campo.
CONCLUSIONI
194
Si può pertanto concludere affermando che tale lavoro rappresenta un primo e significativo
passo verso l’impiego delle più recenti tecnologie di reti di calcolatori nelle applicazioni di
supporto alla ricerca nel campo della fisica nucleare.
BIBLIOGRAFIA
195
BIBLIOGRAFIA
[1] E. D. Courant, H. S. Snyder, Theory of the alternating-gradient syncroton, Ann. Phys.
(N.Y.) 3 (1958).
[2] G. Turchetti, Normal forms for Hamiltonian maps and application to beam dynamics,
International conference “Non linear dynamics and optics” (1994).
[3] A. Bazzani, G. Servizi, E. Todesco e G. Truchetti, A normal form approach to the
theory of nonlinear betatronic motion, CERN Yellow Report (1994).
[4] W. R. Leo, Techniques for Nuclear and Particle Physics Experiments, Sprinter-
Verlang.
[5] Profibus standard DIN 19245.
[6] Wilson, A.,”The Challenge of embedded Internet”, Electronic Product Design, January
1998, pp. 31-2,34.
[7] X10 communication protocol. http://www.x10.org.
[8] D. Mulchandani, “Java for Embedded Systems”, in IEEE Computer Magazine, pp. 30-
39, May June 1998.
[9] G. Benincasa et all, Final report on the uniform equipment access at CERN, CERN / PS
93-16.
BIBLIOGRAFIA
196
[10] O. Bartalini, V. Bellini, J.P. Bocquet, M. Capogni, M. Castoldi, A. D’Angelo, J.P.
Didelez, R. Di Salvo, D. Garozzo, G. Gervino, F. Ghio, B. Girolami, M. Guidal, E.
Hourany, I. Kilvington, V. Kouznetsov, F. Kunne, A. Lapik, P. Levi Sandri, A. Lleres,
D. Moricciani, V. Nedorezov, L. Nicoletti, D. Rebreyend, F. Renard, C. Randieri, M.
Sanzone, C. Schaerf, M.L. Sperduto, M. C. Sutera, A.Turinge and A. Zucchiatti. New
results for π and ω photoproduction at the Graal facility from threshold to 1.5 GeV.
Communication to the Conference Hadron Structure 2000 Stara Lesna, High Tatra
Mountains, 2-8 Ottobre 2000
[11] V. Bellini, F. Palazzolo, A. Scirè, M.L. Sperduto, S. Albergo, G. Poli, R. Potenza, C.
Randieri, V. Russo, M.C. Sutera, M. Capogni, C. Schaerf, A. D'Angelo, D. Moricciani,
A.V Kuznetsov, B. Girolami, F. Ghio, Position sensitive disc for charged particle
detection, 2000 Frontier Detectors for Frontier Physics 8th Pisa Meeting on
Advanced Detectors, 21-27 May 2000, Pisa, Italy.
[12] O. Bartalini, V. Bellini , J.P. Bocquet , M. Capogni , M. Castoldi , A. D'Angelo ,A.
D'Angelo,J.P. Didelez , R. Di Salvo , A. Fantini , G. Gervino , F. Ghio , B. Girolami ,
A. Giusa, M. Guidal , E. Hourany , V. Kouznetsov , A. Lapik , P. Levi Sandri , A.
Lleres , D. Moricciani , V. Nedorezov , L. Nicoletti , C. Randieri, D. Rebreyend , F.
Renard , N. V. Rudnev, C. Schaerf , M.L. Sperduto , C. Sutera , A.Turinge, A.
Zabrodin, A. Zucchiatti, MESON PHOTOPRODUCTION AT GRAAL AND
BARYON RESONANCES, HADRON STRUCTURE 2000, 2-8- October 2000, Stara
Lesna, High Tatra Mountains, Slovak Republic.
[13] V. Bellini, F. Palazzolo, A. Sciré, M. L. Sperduto, S. Albergo, G. Poli, R. Potenza, C.
Randieri,V. Russo, M. C. Sutera, M. Capogni, C. Schaerf, A. D'Angelo, D. Moricciani,
A. V Kuznetsov, B. Girolami, F. Ghio, Position Sensitive Disc for Charged Particle
BIBLIOGRAFIA
197
Detection, Nuclear Instruments and Methods in Physics Research 2001, pp 174-177.
[14] D. Moricciani, O. Bartalini, V. Bellini, J. Bocquet, M. Capogni, M. Castoldi, A.
D'Angelo, J.P. Didelez, R. Di Salvo, A. Fantini, G. Gervino, F. Ghio, B. Girolami, A.
Giusa, M. Guidal, E. Hourany, V. Kuznetsov, A. Lapik, P. Levi Sandri, A. Lleres, V.
Nedorezov, L. Nicoletti, C. Randieri, D. Rebreyend, F. Renard, N.V. Rudnev, C.
Schaerf, M.L. Sperduto, C.M. Sutera, A. Turinge, A. Zabrodin, A. Zucchiatti. Compton
Scattering AT GRAAL. 8th Meeting on Mesons and Light Nuclei, Prague, Czech
Republic, 2-6 Jul 2001. Published in AIP Conf.Proc.603:527-529,2001 Also in *Prague
2001, Mesons and light nuclei* 527-529.
[15] O. Bartalini, V. Bellini , J.P. Bocquet , M. Capogni , M. Castoldi , A. D'Angelo ,A.
D'Angelo,J.P. Didelez , R. Di Salvo , A. Fantini , G. Gervino , F. Ghio , B. Girolami ,
A. Giusa, M. Guidal , E. Hourany , V. Kouznetsov , A. Lapik , P. Levi Sandri , A.
Lleres , D. Moricciani , V. Nedorezov , L. Nicoletti , C. Randieri, D. Rebreyend , F.
Renard , N. V. Rudnev, C. Schaerf , M.L. Sperduto , C. Sutera , A.Turinge, A.
Zabrodin, A. Zucchiatti, MESON PHOTOPRODUCTION AT GRAAL AND
BARYON RESONANCES, Nuclear Physics, Elsevier 2002, pp 218-225.
[16] C. Tuvè, V. Bellini, R. Potenza, C. Randieri, C. Sutera, G. Pucella, M. Marinelli , E.
Milani, A. Paoletti, , A. Tucciarone , G. Verona-Rinati. Carrier Dynamics in CVD
Diamond: Electron and Hole Contributions. Diamond and Related Materials accepted
for publication (2003).
[17] Cristina Tuvè, V. Bellini, R. Potenza, C. Randieri, C. Sutera, G. Pucella, M. Marinelli,
E. Milani, A. Paoletti, A. Tucciarone, G. Verona-Rinati, NUCLEAR PARTICLE
DETECTION AS PROBE FOR DIAMOND DEFECT CHARACTERITATION, XLI
BIBLIOGRAFIA
198
INTERNATIONAL WINTER MEETING ON NUCLEAR PHYSICS Bormio (Italy)
January 26 - February 2, 2003.
[18] Y. Assafiri , O. Bartalini , V. Bellini , J.P. Bocquet , S. Bouchigny , M. Capogni , M.
Castoldi , A. D'Angelo , J.P. Didelez , R. Di Salvo , A. Fantini , L. Fichen , G. Gervino ,
F. Ghio , B. Girolami , A. Giusa , M. Guidal , E. Hourany , V. Kouznetsov , R. Kunne , J-
M. Laget , A. Lapik , P. Levi Sandri , A. Lleres , D. Moricciani , V. Nedorezov , D.
Rebreyend, C. Randieri , F. Renard , N. Rudnev , C. Schaerf , M. Sperduto , M.C. Sutera
, A. Turinge , Q. Zhao , A. Zucchiatti. The Double π0 AND ω Meson Photoproduction
at GRAAL NSTAR2002: accepted for publication 6 Feb 2003.
[19] Y. Assafiri , O. Bartalini , V. Bellini , J.P. Bocquet , S. Bouchigny , M. Capogni , M.
Castoldi , A. D'Angelo , J.P. Didelez , R. Di Salvo , A. Fantini , L. Fichen , G. Gervino ,
F. Ghio , B. Girolami , A. Giusa , M. Guidal , E. Hourany , V. Kouznetsov , R. Kunne , J-
M. Laget , A. Lapik , P. Levi Sandri , A. Lleres , D. Moricciani , V. Nedorezov , D.
Rebreyend, C. Randieri , F. Renard , N. Rudnev , C. Schaerf , M. Sperduto , M.C. Sutera
, A. Turinge , A. Zucchiatti. Double π0 photoproduction on the proton at GRAAL .
Preprint submitted to Phys. Rev. Lett.
[20] O. Mirabella, V. Bellini, C. Randieri, C. Spitale, A Profibus-based Control System for
Nuclear Physics Applications, The 6th World Multi-Confernce on Systemics,
Cybernetics and Informatics SCI 2002, July 2002, Orlando, Florida.
[21] P. Strubin et all, Operational protocol for vacuum system, CERN / AT-VA 91-6.
[22] Applicom® Communication Server Reference Manual v.2.9 .
BIBLIOGRAFIA
199
[23] SAIA BURGESS Reference Manual: Profibus Configurator
[24] McCombie, B.,”Embedded Web server now and in the future,” Real-Time Magazine,
no.1 March 1998, pp. 82-83.
[25] Aptronix, “Bring Embedded System to the Internet”, http://www.aptronix.com.
[26] J. Gosling, B. Joy, G. Steele,”The Java Laguage Specification”, http://java.sun.com
[27] J.S. Young et All., “Design and specification of embedded system in java using
Successive, formal Refinement”, Proceedings of DAC’98, 1998 Design Automation
Conference. San Francisco, C.A.,june 15-19.
[28] T. Lindholm, F. Yellin “The Java Virtual Machine Specification”, 1996.
http://java.sun.com
[29] Netid Managed Services, Information technology, Northwestern Technology,
http://gradeswww.acns.nwu.edu/ist/snap/doc/sniffing.html
[30] Internet spoofing reference page, http://www.brd.ie/paper/sslpaper/hyperlin.html
[31] Web Spoofing: An Internet Con Game,
http://www.cs.pronceton.edu/sip/pub/spoofing.html
[32] B. C. Neuman and T. Ts’o. Kerberos: An Authentication Service for Computer
Networks. In IEEE Communications, volume 39, pages 33–38.
[33] S. Fritzinger and M. Mueller. Java security, 1996. Sun Microsystems, Incorporated.
White Paper. http://java.sun.com/security/whitepaper.txt.
BIBLIOGRAFIA
200
[34] L. Gong. Secure Java Classloading. IEEE Internet Computing, 2(6):56{61,
November/December 1998.
[35] C. Kerer. A exible and extensible security framework for Java code. Master's thesis,
Distributed Systems Group, Technical University of Vienna, Austria, October 1999.
[36] G. McGraw and E. Felten. Java security and type safety. Byte, January 1997.
[37] G. McGraw and E. W. Felten. Java security: hostile applets, holes, and antidotes. John
Wiley, New York, 1997.
[38] G. McGraw and E. W. Felten. Securing Java: getting down to business with mobile code.
John Wiley, New York, 1999.
[39] A. Rubin and D. E. Geer. Mobile Code Security. IEEE Internet Computing, 2(6):30{34,
November/December 1998.
[40] Sun Microsystems, Incorporated. Secure computing with Java: now and the future,
September 1998. White Paper. http: //java.sun.com/marketing/collateral/security.html.
[41] F. Yellin. Low level security in Java. In Proceedings of the Fourth International World
Wide Web Conference, Boston, Massachusetts, USA, December 11{14, 1995, volume 1
of World Wide Web Journal. O'Reilly & Associates, Incorporated, November 1995.
http://www.w3.org/pub/Conferences/WWW4/Papers/197/40.html.
BIBLIOGRAFIA
201
[42] X10 communication protocol. http://www.x10.org
[43] V. Bellini, O. Mirabella, C. Randieri, An X10 based intelligent gateway for Process
Control Applications. Accepted for the The 7th World Multi-Confernce on Systemics,
Cybernetics and Informatics SCI 2003, July 27-30 2003, Orlando, Florida.
[44] Kennet Wacks, “Home System Standards: Achievements and Challenges” , Ph. D.,
Convener of Home Electronic System Standards Committee, IEEE Communication
Magazine, April 2002.
[45] A.M. Cole and B.Q. Tran, “Home Automation To Promote Independent Living In
Elderly Populations”.
[46] John R. Durrett, “A Hybrid Analysis And Architectural Design Method For
Development of Smart Home Components”, Texas Tech University,
December 2002.
[47] J.L.Ryan, “Home Automation”, Electronic And Communication Engineering
Journal, July/August 1989.
[48] Dimitar Valtchev and Ivailo Frankov, “Service Gateway Architecture For A
Smart Home”, IEEE 2002.