Tesi Dottorato di Ricerca in Informatica e Telecomunicazioni Dott. Ing. Cristian Randieri: SISTEMI...

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


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:


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


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


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


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


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


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;


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:


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


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.


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


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


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.


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


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


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.


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


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


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;


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


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.


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.


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ò


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.


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.


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

)


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


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


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


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.


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


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


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


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


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


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


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.


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.


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


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


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


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.


47

Fig. 4.5 Schematico della scheda d’interfaccia


48

Fig. 4.7 Schematico conversione livelli Q8..Q15 ->C0..C7

Fig. 4.6 Schematico conversione Q0..Q7 e I0..I7 in A0..A7


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


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.


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


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


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).


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);

}


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


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


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)


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.


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); }


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


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


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


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


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;


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


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


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.


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


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


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


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


73

Vediamo di seguito lo schematico del circuito di conversione.

Fig. 5.7 Schematico del circuito di conversione A/D


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


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.


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


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


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.


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.


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 .


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


82

Fig. 5.13 Finestra per l’editing della stazione associata al PLC

Fig. 5.14 Finestra per il link dei canali di comunicazione


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.


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.


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


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.


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


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


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.


90

Fig. 5.19


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


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.


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


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;


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


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.


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.


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


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


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];


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


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.


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


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


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.


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.


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.


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


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


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 .


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.


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).


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 ") ;


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) ;


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.


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;


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


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


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.


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


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


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


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


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


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


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


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


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.


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:


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.

//-------------------------------------------


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) ;


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


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


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.

//-------------------------------------------


// un interfaccia socket in C

// Procedura SetOutput

//



//-------------------------------------------

void SetOutput ()


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);


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


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à.

//------------------------------------------


// un interfaccia socket in Java

// Procedura readIOport

//




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;

}

//-------------------------------------------


// un interfaccia socket in Java

// Procedura writeOutputPort

//



//-------------------------------------------

public void writeOutputPort(int outdata)


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:


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


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


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.


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:


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


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.


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


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


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ò


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


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:


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ò


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.


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


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.


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.


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).


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.


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


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


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


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.


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


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


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


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


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


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.


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à


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


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


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)


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


174

42 CurrentDate

Valore del

1° Byte

Funzione Valore del

prossimo

byte (hex)


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.


Default= abilitata

22

X

TwiceTransmission Abilita o Disabilita la trasmissione

a due fasi.


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)


30 Statistics 00

SS SS

RR RR

CC CC

AllStatistics Pacchetti inviati

Pacchetti ricevuti

Pacchetti cancellati

Collisioni


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


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


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


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.


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


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à


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.


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


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


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


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).


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


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


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


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


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


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.

http://www.x10.org/

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 .

http://www.intellisystem.it/sci2002/introscii2002.htm

http://www.intellisystem.it/sci2002/introscii2002.htm

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.

http://java.sun.com/

http://java.sun.com/

http://gradeswww.acns.nwu.edu/ist/snap/doc/sniffing.html

http://www.brd.ie/paper/sslpaper/hyperlin.html

http://www.cs.pronceton.edu/sip/pub/spoofing.html

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.

http://www.w3.org/pub/Conferences/WWW4/

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.

http://www.x10.org/

Tesi Dottorato di Ricerca in Informatica e Telecomunicazioni Dott. Ing. Cristian Randieri: SISTEMI...

Technology

Transcript of Tesi Dottorato di Ricerca in Informatica e Telecomunicazioni Dott. Ing. Cristian Randieri: SISTEMI...