Intellisystem Technologies studia i sistemi per la conservazione delle opere
Da diverso tempo enti di ricerca nazionali ed esteri si occupano della conservazione delle opere d’ arte. La sfida è garantirne una perfetta conservazione mantenendo un elevato livello di qualità percettiva delle stesse. I sistemi proposti da Intellisystem Technologies sono dotati di accorgimenti tecnici che garantiscono la conservazione, come vetrine climatizzate o sistemi per la conservazione sottovuoto, e sottopongono i prodotti finiti a minuziosi controlli e monitoraggi. In particolare, la società ha messo a punto un sistema sperimentale per la generazione e il mantenimento del vuoto controllato mediante tecnologia fieldbus per la conservazione delle opere d’arte.
Fare il vuoto per conservare meglio
Il sistema si compone di una camera da 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 predefiniti nell’intervallo da 1*10·3 a 1*103 mbar e da 1*10-9 a 1*10-3 mbar, e quattro elettrovalvole, due per il ritorno dell ‘aria e due per l’estrazione dell’aria dalla camera (pre-vacuum e vacuum). Il sistema è stato progettato per effettuare il controllo remoto del vuoto e garantire sia funzioni di monitoraggio e regolazione automatica della pressione nella camera in base a un valore assegnato, sia la possibilità d’intervento remoto su ognuno dei dispositivi attivati. Per fare ciò è stata studiata e realizzata una rete fieldbus in cui sono previsti un sistema di supervisione dell’impianto, rappresentato da una workstation con un’interfaccia Profibus master; un ‘unità slave per l’acquisizione delle misure di pressione; un’unità PLC con interfaccia FMS per il controllo locale del vuoto. Obiettivo dell’applicazione è permettere il controllo remoto della pressione interna della camera di test, preposta a contenere opere d’arte che necessitano una conservazione sottovuoto. Per questo il controllore locale (PLC) riceve informazioni dalla stazione di supervisione sul tipo di controllo da effettuare (manuale o automatico) e, in caso di controllo automatico, sul valore target di pressione da imporre. Sulla base di queste ultime informazioni il PLC esegue 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. L’architettura adottata per realizzare il controllo in remoto del sistema di vuoto comprende una scheda di acquisizione che converte le misure analogiche di pressione in dati binari che passa alla slave unit 2; la stazione di supervisione (master unit 1) che fornisce al PLC la misura attuale di pressione scandendo ciclicamente la slave unit 2 (periodo di scansione = 100 ms). Essa trasforma inoltre le misure dal formato binario a quello 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. Il terminale remoto presenta l’interfaccia utente per il controllo della camera a vuoto. La parte centrale del- 1 a finestra di comando è occupata dal quadro sinottico che riproduce in modo schematico l’impianto, assieme agli indicatori di funzionamento: la colorazione verde indica il funzionamento attivo del dispositivo associato (pompa accesa o elettrovalvola aperta), il rosso indica gli altri stati. Ai due sensori di pressione sono associati due indicatori la cui accensione segnala quale dei due dispositivi è stato selezionato per l’acquisizione corrente delle misure di pressione. Un altro pannello contiene due visualizzatori, il primo a scorrimento in scala semilogaritmica, che fornisce l’andamento temporale della pressione interna alla camera. Il secondo display, invece, visualizza il valore corrente di pressione in mbar. Sebbene ancora in fase sperimentale, l’applicazione ha dimostrato elevata efficienza.
__________
A cura di Cristian Randieri. Articolo pubblicato sulla rivista Fieldbus & Networks – Febbraio 2004.
Per scaricare l’articolo pubblicato sulla rivista, seguire il link riportato di seguito http://www.intellisystem.it/portfolio/fn-feb-04-1/
Le schede d’interfaccia relè a 1, 8 o 16 canali di Intellisystem Technologies (www.intellisystem.it) sono state progettate e realizzate secondo rigorosi criteri di sicurezza che permettono a questi dispositivi un totale isolamento del carico dal sistema di controllo, grazie ai diversi livelli d’isolamento in essi implementati: ottico, galvanico, protezione delle uscite relè tramite varistori. Utilizzandole unitamente ai prodotti Intellisystem Technologies, si ottengono sistemi di telecontrollo basati su tecnologia Tcp/IP capaci di comandare l’azionamento di carichi e sistemi di potenza. I sistemi proposti sono stati progettati per poter essere impiegati non solo in abbinamento con i prodotti di telecontrollo e videocontrollo di Intellisystem Technologies, ma anche con qualsiasi sistema di controllo che abbia delle uscite in segnale. Grazie a pad supplementari presenti a bordo di tutte le schede è possibile differenziare il livello logico di ciascun ingresso semplicemente aggiungendo dei resistori.
A cura di Cristian Randieri. Articolo pubblicato sulla rivista Il Giornale dell’Installatore Elettrico N. 1 – 30 Gennaio 2004.
Per scaricare l’articolo pubblicato sulla rivista, seguire il link riportato di seguito http://www.intellisystem.it/portfolio/gie-30-gen-04-relay/
RECS 101 è un Web server embedded, prodotto da Intellisystem Technologies, nato per gestire applicazioni professionali di controllo remoto in ambiente TCP / IP in maniera veloce, facile e sicura. Una volta collegato a una rete Ethernet, RECS 101 mette a disposizione dell’utente 32 canali digitali di cui 16 di Input e 16 di Output. Supportato dai comuni browser Internet, permette di gestire totalmente da remoto qualsiasi dispositivo o apparecchiatura elettronica in pochi e semplici passaggi. La caratteristica che rende unico RECS 101 consiste nella capacità di poter eseguire del codice Java per la gestione dell’interfaccia relativa al controllo delle porte di I/O. Tale caratteristica permette di gestire l’interfaccia utente tramite un’Applet Java parametrica, sviluppando così l’applicazione di controllo in modo rapido e sicuro. RECS 101 viene utilizzato nelle applicazioni di videosorveglianza, telecontrollo remoto e domotica, rappresentando un valido strumento per integrare tutte le funzionalità di un sistema di controllo industriale nei comuni sistemi di monitoraggio video. L’offerta di Intellisystem Technologies è completata da una sistema Linux embedded con supporto hardware e software per applicazioni Web-based. Si tratta di Axis Developer Board LX, che monta a bordo le più comuni porte d’interfaccia e il potente processore Axis ETRAX 100LX, progettato per venire incontro alla domanda di sviluppare nuove applicazioni che siano low cost, facili da implementare, con caratteristiche di supporto al networking. Grazie alla nuova tecnologia MMU (Memory Manage Unit) il sistema è in grado di supportare il kernel Linux 2.4, senza far uso di patches, garantendo la massima portabilità delle più comuni librerie Linux normalmente adottate sui comuni Pc.
A cura di Cristian Randieri. Articolo pubblicato sulla rivista Elettronica Oggi Embedded N. 5 – Gennaio 2004.
Per scaricare l’articolo pubblicato sulla rivista, seguire il link riportato di seguito http://www.intellisystem.it/portfolio/eo-emb-gen-04/
Le schede d’interfaccia relè a 1, 8 o 16 canali di Intellisystem Technologies (www.intellisystem.it) sono state progettate e realizzate secondo rigorosi criteri di sicurezza che permettono a questi dispositivi un totale isolamento del carico dal sistema di controllo, grazie ai diversi livelli d’isolamento in essi implementati: ottico, galvanico, protezione delle uscite relè tramite varistori. Utilizzandole unitamente ai prodotti Intellisystem Technologies, si ottengono sistemi di telecontrollo basati su tecnologia Tcp/IP capaci di comandare l’azionamento di carichi e sistemi di potenza. I sistemi proposti sono stati progettati per poter essere impiegati non solo in abbinamento con i prodotti di telecontrollo e videocontrollo di Intellisystem Technologies, ma anche con qualsiasi sistema di controllo che abbia delle uscite in segnale. Grazie a pad supplementari presenti a bordo di tutte le schede è possibile differenziare il livello logico di ciascun ingresso semplicemente aggiungendo dei resistori.
A cura di Cristian Randieri. Articolo pubblicato sulla rivista Commercio Elettrico N. 1 – Gennaio 2004.
Per scaricare l’articolo pubblicato sulla rivista, seguire il link riportato di seguito http://www.intellisystem.it/portfolio/ce-gen-04-relay/
I fieldbus rappresentano una valida soluzione per il controllo remoto e la misura nei sistemi d’acquisizione usati nel campo della ricerca sperimentale
La continua evoluzione delle tecnologie basate su sistemi digitali ha fortemente modificato le tecniche e metodologie usate nei sistemi di controllo, specie negli esperimenti di fisica nucleare. In particolare, oggi la richiesta di processi distribuiti richiede sistemi intelligenti, dispositivi di controllo e sistemi di misura capaci di comunicare attraverso la rete. Tali sistemi vengono richiesti per ridurre le connessioni, il che si traduce in una semplificazione della gestione dei sistemi poiché diminuiscono le problematiche inerenti alla manutenzione. I sistemi fieldbus rappresentano una valida soluzione per il controllo remoto e per la misura nei sistemi d’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, ecc.); al tempo stesso bisogna soddisfare i fondamentali requisiti di sicurezza, portatilità e semplicità richiesti. 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 alle sale sperimentali. Sfortunatamente, l’ambiente tipico 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 quando l’esperimento è in esecuzione.
Misurare gli ioni pesanti
Il sistema sperimentale a cui ci si riferisce viene utilizzato per studiare le reazioni e interazioni degli ioni pesanti. La struttura è alloggiata in una sala sperimentale dei Laboratori Nazionali del Sud di Catania che prende il nome di ‘Neutron Hall’. Tale esperimento è gestito dal gruppo di ricerca Chic (Collaboration for Heavy Ion Collision). La struttura sperimentale si compone di una serie di camere a vuoto, con finestre d’osservazione, nelle quali vengono effettuate gli esperimenti di interferometria nucleare. Un fascio di ioni ad energia intermedia (10-50 MeV/A) viene deflesso nel vuoto e quindi convogliato ali’ interno della camera di reazione attraverso opportuni magneti. Il fascio urta il bersaglio nucleare; durante la collisione genera delle particelle subatomiche le cui caratteristiche vengono rilevate da vari rivelatori; i dati generati vengono acquisiti e successivamente analizzati dagli operatori. Una prima applicazione del sistema Profibus si può trovare nel controllo remoto di un multidetector (costituito da un array bidimensionale di scintilla tori allo Ioduro di Cesio) usato per rilevare particelle nucleari come protoni e/o ioni leggeri. L’apparato meccanico deve poter essere movimentato lungo i tre assi x, y e z in realtime, senza che il fascio prodotto dagli acceleratori di particelle venga interrotto. Un’altra esigenza stringente è costituita dalla precisione della meccanica e quindi dell’elettronica di controllo. Tramite l’utilizzo dei sistemi Profibus è stato implementato il controllo remoto dell ‘apparato meccanico integrato con un sistema di monitoraggio online della posizione di ogni singolo rivelatore. Tale applicazione ha messo in evidenza i vantaggi derivanti dall’introduzione dei sistemi Profibus in termini di portabilità e semplicità, grazie all’uso di un sistema a singolo bus di comunicazione. Inoltre, si sono registrate buone performance in termini di velocità della rete durante la sofisticata interazione dinamica tra la console di comando e il dispositivo di controllo remoto. Una seconda applicazione presenta l’implementazione di un apparato fieldbus su un sistema di controllo del vuoto utilizzato per 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 e 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. In questo caso è stato dimostrato come sia possibile combinare le caratteristiche dell’intelligenza decentrata, in accordo con la filosofia dei sistemi fieldbus, con stazioni di supervisione, sistemi di controllo (regolatori, PLC, ecc.), attuatori e trasduttori che condividono il bus e interagiscono in modi differenti.
__________
A cura di Cristian Randieri. Articolo pubblicato sulla rivista Fieldbus & Networks – Settembre 2003
Per scaricare l’articolo pubblicato sulla rivista, seguire il link riportato di seguito http://www.intellisystem.it/portfolio/fns-set-2003-profibus/
Intellisystem Technologies in collaborazione con Elsacom ha realizzato un sistema satellitare per il telecontrollo e la trasmissione di immagini mediante micro embedded Web server avvalendosi della tecnologia Globalstar. La soluzione proposta, basandosi sulla tecnologia packet PPP di Elsacom/ Globalstar, oltre ad acquisire e trasmettere immagini in formato Jpeg, permette la gestione software di attuatori per il telecontrollo dell’apparato in uso. Grazie alle potenzialità del micro Web server integrato nel sistema l’utente interagisce con il dispositivo remoto da controllare semplicemente attraverso interfacce Web personalizzabili. Le caratteristiche del sistema permettono di trasferire immagini in video-live supportando tutte le funzionalità della suite di protocolli TCP/lP, quali http, email ed ftp, e al contempo rappresenta un apparato di accesso al sistema che permette all’utente di interagire con esso in remoto agendo su opportuni attuatori telecontrollati via Web. La facilità di programmazione della soluzione permette la gestione dell’invio dei fotogrammi, risolvendo molte delle problematiche inerenti il videocontrollo e il telecontrollo ‘over IP’ di macchinari o siti remoti. Il sistema trova ampie applicazioni nel telesoccorso, il monitoraggio ambientale, la protezione civile e militare.
A cura di Cristian Randieri. Articolo pubblicato sulla rivista Fieldbus & Networks – Settembre 2003.
Per scaricare l’articolo pubblicato sulla rivista, seguire il link riportato di seguito http://www.intellisystem.it/portfolio/fns-june-2003-diamond-experiment/
Con questa quarta parte, si conclude la trattazione del dispositivo RECS 101 con un argomento di rilevante importanza: “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 lato 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 ad essa. Il web ha il potere di aumentare la produttività di chiunque, tuttavia come per ogni tecnologia o attività di 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 s’intende esaminare. In generale si possono individuare quattro categorie:
• 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:
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:
Hyperlink Spoofing: Se s’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 è quella 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 desidera 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: • 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. • Il sito deve contenere link che conducono solo ad altri siti sicuri.
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 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 [5÷13]:
• Leakage (unauthorized attempts to obtain information belonging to or intended for someone else).
• Tampering (unauthorized changing/ including deleting/of information).
• Resource stealing (unauthorized use of resources or facilities such as memory or disk space).
• 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 del applet restringendolo a determinate aree del client. La tabella 1 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ò ad esempio accedere al disco fisso dell’utente, aprire nuovi canali di trasmissione o restituire informazioni approfondite, relative al client che esegue l’applet stessa. Gli applet e la libreria standard java, 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 un’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.
ARCHITETTURA DI SICUREZZA JAVA
In accordo a quanto riportato in letteratura [8], l’applet Verifier [9], è 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: • Il programma non provochi l’overflow o l’underflow dello stack. • Il programma esegua accessi validi alla memoria e ai registri. • I parametri di tutte le istruzioni bytecode siano corretti. • 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 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 sono 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 [5÷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ù chiaro, i problemi per cui il dispositivo potrebbe essere vulnerabile, sono principalmente dovuti a:
• 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 sopra 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 database delle password ed user ID è effettuata 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ò 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.
___________
A cura di Cristian Randieri. Articolo pubblicato sulla rivista Fare Elettronica N. 217/218 – Luglio/Agosto 2003.
Per scaricare l’articolo pubblicato sulla rivista, seguire il link riportato di seguito http://www.intellisystem.it/portfolio/fe-lug-ago-2003-recs-101-part-4/
___________
Link consigliati per la lettura completa di tutti gli articoli
RECS 101: UN WEB SERVER EMBEDDED PER APPLICAZIONI DI CONTROLLO REMOTO TRAMITE TCP/IP – 1° Parte
RECS 101: UN WEB SERVER EMBEDDED PER APPLICAZIONI DI CONTROLLO REMOTO TRAMITE TCP/IP – 2° Parte
RECS 101: UN WEB SERVER EMBEDDED PER APPLICAZIONI DI CONTROLLO REMOTO TRAMITE TCP/IP – 3° parte
Con il telecontrollo si possono ridurre i rischi di contaminazione da radiazione durante gli esperimenti di fisica nucleare
_______
A cura di Cristian Randieri. Articolo pubblicato sulla rivista Fieldbus & Networks – Giugno 2003.
Per scaricare l’articolo pubblicato sulla rivista, seguire il link riportato di seguito http://www.intellisystem.it/portfolio/fn-giu-03-diamond-experiment/
_______
Situati a Catania, i Laboratori nazionali del sud dell’Istituto nazionale di fisica nucleare rappresentano da anni un centro mondiale di ricerca per la fisica nucleare sperimentale. Recentemente qui è stato condotto l’esperimento di fisica nucleare denominato ‘Esperimento Diamante’, che prevedeva il test di un rivelatore sperimentale al diamante (composto da un film di diamante depositato mediante la tecnica ‘Microwave plasma enhanced chemical vapor deposition’ su un substrato al silicio) per lo studio sistematico di un fascio di protoni ottenuto mediante un acceleratore di tipo tandem da 15 MV. 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 caratterizzare la regione interna di un fascio di particelle emesse da un acceleratore.
Misure di questo tipo rivestono particolare importanza per le applicazioni derivabili in ambito medico che utilizzino fasci di radiazioni. Solitamente tali misure vengono effettuate mediante dei rivelatori denominati ‘tazze di Faraday’, il cui limite sta nel fatto che il segnale da essi emesso è troppo basso perché se ne possa ottenere una risoluzione spaziale, il che limita la misura del profilo del fascio in esame.
Scopo dell’esperimento era porre a confronto le misure ottenute ottenute con tre diversi tipi di rivelatori, ossia al silicio, al diamante e basati sulle tazze di Faraday.
Spesso durante gli esperimenti di fisica nucleare si pone maggiore attenzione ai sistemi di acquisizione dei dati che non agli apparati di gestione dell’esperimento, trascurando a volte tutta una serie di complicazioni puramente operazionali che possono limitare la corretta esecuzione dell’esperimento stesso.
L’insorgere di questo tipo di problematiche, infatti, può ridurre drasticamente l’effettivo tempo di acquisizione dei dati sperimentali, poiché ogni qualvolta occorre accedere alla sala sperimentale, è necessario sospendere il fascio ed eseguire un nuovo set-up.
Facciamo qualche osservazione
Attualmente la maggior parte dei sistemi di supporto agli esperimenti di fisica nucleare sono attivati manualmente all’interno delle sale sperimentali. Durante ogni esperimento la presenza di radiazioni, pericolose sia per gli essere umani, sia per la strumentazione, richiede di porre le sale sperimentali in un cosiddetto stato di ‘Safety contro!’; perciò occorre sospendere il fascio ogni qualvolta un operatore deve intervenire all’interno delle sale.
Tra le sale sperimentali e quelle di acquisizione vengono approntate connessioni dedicate di tipo punto-punto; ciò significa che un gran numero di conduttori collegano le due zone, rappresentando di fatto un potenziale punto di diffusione delle radiazioni. I sistemi di telecontrollo e teleassistenza di ultima generazione proposti da Intellisystem Technologies, utilizzando la suite di protocolli TCP/IP permettono di ottimizzare le risorse logistiche, riducendo il numero delle connessioni necessarie, e riducono i costi di gestione. Consentono inoltre agli addetti di concentrarsi con maggiore libertà sul lavoro primario di acquisizione di dati e misure sperimentali.
A prova di radiazione
Prendendo parte all’esperimento Diamante, Intellisystem Technologies ha testato un valido strumento per il monitoraggio delle sale sperimentali utilizzando le moderne tecnologie di telecontrollo e teleassistenza. Il micro embedded Web server Recs 1O1 prodotto dall’azienda, in grado di controllare 16 ingessi e 16 uscite, è stato impiegato in combinazione con una videocamera Axis 2120, a sua volta collegata a un modulo audio Axis 2191. E’ stato possibile disporre di una postazione di telecontrollo capace non solo di gestire immagini, ma anche di controllare lo stato di dispositivi esterni quali i sensori, e di manovrarne altri, quali gli attuatori. In particolare, il dispositivo Recs 101 è stato testato per la prima volta 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 il test. I risultati hanno mostrato l’ottima immunità della soluzione ai disturbi dovuti a radiazioni di tipo nucleare, nella fatti specie neutroni. L’integrazione del sistema Recs 101 con i dispositivi Axis e il sistema di movimentazione hanno dimostrato come sia possibile controllare da remoto tramite Internet un impianto sperimentale per la ricerca nel campo della fisica nucleare, ottimizzando costi e tempi d’esecuzione. Sono stati anche ridotti i tempi d’intervento degli operatori durante le varie fasi dell’esperimento, con conseguente diminuzione dei rischi da esposizione a radiazioni nucleari per gli addetti. Inoltre, per la prima volta più ricercatori da ogni parte del mondo hanno potuto connettersi alla sala sperimentale via Internet, tramite un canale video e uno audio bidirezionale, e controllare la movimentazione del bersaglio.
In questa terza parte della presentazione del dispositivo RECS 101 vengono affrontati i seguenti argomenti: il protocollo di comunicazione implementato in RECS 101 ed esempi di metodologie per la progettazione di applicazioni personalizzate mediante l’implementazione di socket Internet in C e in Java.
PROTOCOLLO DI COMUNICAZIONE IMPLEMENTATO IN RECS 101
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 (figura 1). 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. I comandi di controllo si suddividono in due categorie che identificano due operazioni diverse: Monitor Stato I/O Tramite quest’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 quest’operazione sono essenzialmente due:
• I/O Get Command: È il comando mediante il quale l’interfaccia socket interroga RECS 101 sullo stato delle proprie porte.
• I/O Get Command Responce: È il comando di risposta mediante il quale RECS 101 comunica all’interfaccia socket lo stato delle sue porte di I/O. 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. La tabella 1 riassume i comandi relativi alla comu nicazione e i tipi di messaggi che vengono scambiati tra l’interfaccia socket ed il dispositivo RECS 101. 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 tabella 2. 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 di Output siano nello stato logico alto e i bit 1,3 e 5 della porta di Input siano anch’essi nello stato logico alto, RECS 101 alla ricezione del comando “0x75” risponderà come descritto nella tabella 3. A questo punto l’interfaccia socket tra RECS 101 ed il PC utente si occuperà dell’interpretazione di questo valore visualizzandolo sul PC utente. Anche se i dati relativi allo stato delle porte di I/O sono contenuti in 4 byte, RECS 101 invierà all’interfaccia socket Figura 3: Comandi di controllo di RECS 101 Figura 4: Comando di controllo della porta di Output di RECS 101 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) [1], 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 usarne16, di conseguenza, l’utente dovrà interpretare solamente i primi 4 bytes del pacchetto ricevuto (tabella 4). Controllo dei comandi di Output 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 tabella 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. 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 corrispon dente valore in esadecimale è 0x000F, occorrerà inviare a RECS 101 il valore esadecimale 76:00:0F come mostrato nella tabella 6.
COMUNICARE CON RECS 101: L’INTERFACCIA SOCKET IN C
Si riporta, di seguito, un esempio di codice sorgente scritto nel linguaggio C, il quale rappresenta l’implementazione di un’interfaccia socket basata sulle API dei socket di Berkely. I frammenti di codice riportati di seguito, si occupano 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:
• 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 s’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 d’errore, al verificarsi di quest’evento sarà 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 sono 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 (vedi listato 1) 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 le 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 è quindi memorizzato nella variabile outbit. Richiamiamo la procedura IOMonitor() per leggere lo stato della porta di I/O 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 procedura 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 siano 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 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.(vedi listato 2) Per maggiore chiarezza la figura 5 riporta un esempio pratico di quanto descritto precedentemente, pertanto si supporrà quanto segue: • Lo stato della porta di Output di RECS 101 è uguale a 00000000|10001001. • Si vuole portare a livello logico “alto” il quinto bit della porta di Output a partire dalla destra.
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, gestita mediante un interfaccia browser. Come ben noto, le Applet sono dei programmi autonomi, scritti in Java, eseguibili mediante un comune browser. La potenzialità di un software scritto in Java, consente 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 d’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à. (listato 3)
_________
A cura di Cristian Randieri. Articolo pubblicato sulla rivista Fare Elettronica N. 216 – Giugno 2003.
Per scaricare l’articolo pubblicato sulla rivista, seguire il link riportato di seguito http://www.intellisystem.it/portfolio/fe-giugno-2003-recs-101-3-parte/
_____________
Link consigliati per la lettura completa di tutti gli articoli
RECS 101: UN WEB SERVER EMBEDDED PER APPLICAZIONI DI CONTROLLO REMOTO TRAMITE TCP/IP – 1° Parte
RECS 101: UN WEB SERVER EMBEDDED PER APPLICAZIONI DI CONTROLLO REMOTO TRAMITE TCP/IP – 2° Parte
RECS 101: UN WEB SERVER EMBEDDED PER APPLICAZIONI DI CONTROLLO REMOTO TRAMITE TCP/IP – 4° parte