Tag: project management

(Italiano) ‘A colpo d’occhio’: Applicazione di un sistema di monitoraggio video in un impianto petrolchimico
AO N. 332 - Febbraio 2010 - A colpo d'occhio - Intellisystem Technologies

(Italiano) ‘A colpo d’occhio’: Applicazione di un sistema di monitoraggio video in un impianto petrolchimico

Sorry, this entry is only available in Italian. For the sake of viewer convenience, the content is shown below in the alternative language. You may click the link to switch the active language.

L’applicazione di un sistema di monitoraggio video in un impianto petrolchimico consente l’immediata individuazione di eventuali anomalie

Da diverso tempo le grandi multinazionali che lavorano nel campo della raffinazione del petrolio si occupano di tematiche di automazione di processo e sistemi per la tutela della sicurezza dei propri lavoratori. La sfida che continuamente si propone consiste nel garantire l’ottimizzazione delle risorse logistiche semplificando i cablaggi, l’uso e la manutenzione. Tutto senza trascurare l’aspetto più importante: limitare l’esposizione dei propri lavoratori al pericolo e preservarne la salute, garantendo loro l’incolumità. I sistemi messi a punto da Intellisystem Technologies offrono una valida soluzione a questi problemi, in quanto l’azienda progetta e realizza tecnologie che si integrano ad altre già esistenti a favore di una corretta ottimizzazione delle risorse disponibili. Inoltre, la continua evoluzione delle tecnologie di comunicazione digitale, che riguardano i sistemi per l’automazione di processo, ha fortemente modificato le tecniche e metodologie usate negli apparati di controllo, a favore di una sempre più spinta integrazione e coesistenza di più standard di comunicazione. In particolare, i processi distribuiti richiedono l’uso di soluzioni intelligenti, dispositivi di controllo e apparati di misura capaci di comunicare tra loro. L’esigenza di passare a una tecnologia di tipo Ethernet o di integrarla nasce dai vantaggi che se ne traggono in termini di semplificazione dei cablaggi, gestione dei sistemi e manutenzione, nonché di scalabilità.

 Segnalazioni da remoto

La soluzione di telecontrollo remoto e videosorveglianza over IP descritta di seguito è stata pensata per rispondere alle esigenze di una delle raffinerie ERG presenti nel polo petrolchimico di Siracusa. Il committente necessitava di un impianto di monitoraggio video intelligente, non solo da utilizzare come sistema per la sicurezza della produzione e dei lavoratori, ma anche capace di integrarsi con le tecnologie di controllo di processo già presenti nella sala quadri dell’impianto. In particolare, veniva richiesto l’interfacciamento di una postazione client di monitoraggio video con un sistema video-wall già presente in sala quadri, capace di fornire agli addetti una visione realistica delle variabili di controllo e produzione in essere, nonché una panoramica delle immagini provenienti dall’impianto. La soluzione offerta da Intellisystem insieme alla ditta DiPietro Automazione, che si è occupata dell’installazione dei sistemi, del loro cablaggio e dell’ingegneria di dettaglio, ha previsto l’utilizzo delle ‘networkcamere’ industriali Pan Tilt Zoom, di ultima generazione. Grazie alle loro caratteristiche di scalabilità e integrazione in una rete Ethernet in fibra ottica, esse si sono potute inserire senza interferire con gli apparati preesistenti in raffineria. La soluzione ‘Network Video Solution’ adottata rappresenta di fatto lo stato d’arte delle soluzioni per il monitoraggio remoto e offre benefici ben superiori a quelli offerti dagli equivalenti sistemi analogici. La flessibilità dei prodotti scelti ha semplificato l’integrazione della soluzione con altri sistemi di automazione industriale già presenti in loco. Valido strumento di controllo, il sistema offre in tempo reale uno streaming video di ciò che realmente accade nei punti più critici dell’impianto. Infatti, grazie alla tecnologia impiegata è possibile monitorare visivamente in realtime alcune parti dell’impianto, controllando ad esempio i bruciatori e le emissioni di fumi dal camino principale. In questo modo, oltre a osservare i parametri tipici di controllo di processo, si ha a disposizione un apparato di monitoraggio video gestibile da remoto, che permette in pochi istanti la verifica e la supervisione di alcune variabili oggettive ed euristiche, difficilmente quantizzabili dal normale sistema di controllo di processo. Nello specifico, una diversa colorazione dei fumi di scarico dei camini indica una condizione di anomalia nel funzionamento dell’impianto; questa rilevazione, unitamente alla misurazione di alcune variabili di processo, consente agli operatori presenti nella sala controllo di individuare e risolvere prontamente eventuali problematiche. Inoltre, non sempre il sistema di automazione effettua in maniera capillare tutte le misure; a volte alcune variabili secondarie vengono misurate localmente, mediante strumenti analogici quali manometri e termometri, che, nel caso in cui il sistema centrale segnali un’anomalia di funzionamento, rappresentano un valido strumento per individuare in modo preciso e tempestivo la causa di tale problema. Grazie al sistema installato, invece, è possibile rilevare visivamente, da remoto, anche le variazioni che in condizioni usuali verrebbero rilevate solo utilizzando degli strumenti analogici, direttamente in campo, ottimizzando di fatto i tempi d’intervento e d’individuazione certa della causa di guasto dalla sala controllo centrale. Non solo, nel caso in cui si presenti un’anomalia di funzionamento grave, che richieda l’esecuzione di operazioni manuali sul posto, il sistema permette la valutazione del rischio inerente l’invio di un operatore.

 Ampliamenti futuri

 Il sistema così realizzato verrà in futuro ampliato, sono infatti già previste alcune integrazioni, ad esempio l’estensione dei punti di ripresa dagli attuali dodici ai futuri 24 e l’utilizzo di termocamere in grado di ‘mappare’ il calore in immagini, permettendo una più accurata individuazione delle anomalie termiche, meccaniche, idrauliche ed elettroniche. In una seconda fase si intende integrare il sistema con l’apparato di automazione di processo DCS mediante algoritmi di ‘image processing’ atti a riconoscere eventi particolari, tipo un’anomala colorazione dei fumi di scarico in atmosfera.

A cura di Cristian Randieri. Articolo pubblicato sulla rivista Automazione Oggi N. 332 – Febbraio 2010.

Per scaricare l’articolo pubblicato sulla rivista, seguire il link riportato di seguito http://www.intellisystem.it/portfolio/ao-febbraio-2010/

FE Luglio-Agosto 2003 - RECS 101 - Intellisystem Technologies

(Italiano) RECS 101: UN WEB SERVER EMBEDDED PER APPLICAZIONI DI CONTROLLO REMOTO TRAMITE TCP/IP – 4° Parte

Sorry, this entry is only available in Italian. For the sake of viewer convenience, the content is shown below in the alternative language. You may click the link to switch the active language.

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:

  • 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 [1]. 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.
  • 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 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.
  • 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 scavalcare 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. In seguito, dopo aver controllato 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 files di password, nomi, login, dati riservati e ogni altra informazioni trasmessa in rete. In generale un hacker utilizza la previsione del numero di sequenza come preparativo per l’attacco vero e proprio al server oppure come base per l’attacco di un altro server della rete.
  • Hyperlink Spoofing: È un tipo d’attacco che gli hacker sferrano contro computer che comunicano utilizzando il protocollo HTTP [2]. 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 s’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 saranno memorizzate nel server fittizio. Un alto rischio di Hyperlink spoofing accade se l’utente preleva ed esegue dal server fittizio applet Java pericolosi, credendo che tali applet siano forniti da un server sicuro e che debbano pertanto essere considerati sicuri. L’attacco Hyperlink spoofing rende palese un difetto nel modo in cui, la maggior parte dei browser, impiega 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 riflettendo l’attività dell’azienda che possiede il sito Web cui si fa riferimento, non sempre questo accade. Quando è 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.
  • Web Spoofing: È un tipo d’attacco che prevede di creare una copia falsa ma convincente dell’intero sito Web [3]. 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 sia difficile per l’hacker sostituirsi all’intero Web, ma sfortunatamente non è così. L’hacker non deve memorizzare l’intero contenuto del Web, poiché il Web è, per definizione, disponibile on-line. Quando il server dell’hacker deve fornire una falsa pagina, gli basta prelevarla e modificarla dal Web stesso.

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:

  • Attacchi da password: Nelle reti, l’intercettazione delle transazioni, rappresenta uno dei rischi più gravi 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 quella a chiave pubblica (o a chiave asimmetrica). La crittografia a chiave semplice, utilizza un’unica chiave nota ai due capi della comunicazione che la usano per crittografare e decrittografare le informazioni. La crittografia a chiave pubblica, usa una chiave disponibile pubblicamente e una 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 criptata, utilizzando un attacco di questo tipo, è solo leggermente inferiore rispetto al pericolo che qualcuno possa rubare la chiave privata dal disco fisso.
  • 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 [4]). 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 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 ridirezionare 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.
  • 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 audittrail 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’auditingtrail, se utilizzato correttamente, è solo uno degli strumenti per 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.

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.

  • Web Spoofing: Questo genere d’attacchi è veramente pericoloso e in sostanza non è rilevabile. Le misure preventive che possono essere adottate si riassumono nei seguenti punti: • Disabilitare nel browser gli script in modo che l’hacker non possa nascondere l’evidenza dell’attacco; • Assicurarsi che la riga degli indirizzi del browser sia sempre visibile. • 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 disattivazione degli script si perderà qualche utile funzionalità, si potrà in ogni caso riattivarne l’uso, all’interno di 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.

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 

FE Giugno 2003 - RECS 101 - Intellisystem Technologies

(Italian) RECS 101: UN WEB SERVER EMBEDDED PER APPLICAZIONI DI CONTROLLO REMOTO TRAMITE TCP/IP – 3° Parte

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 

FE Marzo-Aprile 2003 – RECS 101 - Intellisystem Technologies

(Italian) RECS 101: UN WEB SERVER EMBEDDED PER APPLICAZIONI DI CONTROLLO REMOTO TRAMITE TCP/IP – 2° Parte

In questa seconda parte della presentazione del dispositivo RECS 101 sono affrontati i seguenti argomenti: le problematiche inerenti la configurazione dei parametri di rete per il corretto utilizzo del dispositivo all’interno di una rete Intranet/Internet; Come effettuare le operazioni di upload dell’interfaccia GUI personalizzata all’interno della memoria flash del dispositivo; In conclusione vengono presentati due possibili circuiti d’interfaccia che permettono allo sviluppatore di implementare in modo sicuro un proprio hardware per interfacciare RECS 101 a qualsiasi dispositivo/impianto da controllare via Internet.  

CONFIGURAZIONE DEI PARAMETRI DI RETE

Prima di poter utilizzare RECS 101 occorre configurare correttamente i suoi  parametri di rete utilizzando il programma shareware di utilità RECS Utility, scaricabile al seguente indirizzo http://www.intellisystem.it/recs/ download.htm. RECS Utility è stato progettato e realizzato per lavorare su piattaforma Microsoft Windows sui sistemi operativi delle versioni 95/98/ME/NT/2000 e XP Home/Professional. Una volta installato ed eseguito RECS Utility, verrà visualizzata la maschera iniziale del programma che permette di impostare l’indirizzo IP di RECS 101 (fig. 1) Prima di configurare l’indirizzo IP da assegnare al dispositivo è necessario avere informazioni sulla struttura degli indirizzi IP della rete in cui si andrà ad installare RECS 101. Pertanto occorrerà conoscere: • Un indirizzo IP non utilizzato all’interno della struttura; • La Subnet Mask della struttura. RECS 101 è preconfigurato in fase di testing con le seguenti impostazioni di fabbrica: Indirizzo IP: 172.16.10.103 Subnet Mask: 255.255.255.0 Per impostare o cambiare l’indirizzo IP di RECS 101 occorre prima reinizializzare l’indirizzo IP al valore di default 0.0.0.0 (operazione che verrà descritta di seguito). Inizializzare un nuovo indirizzo IP per RECS 101 implica la rimozione dell’associazione IP/MAC memorizzata all’interno del PC che s’intende adoperare. Tale informazione è memorizzata nella cache del protocollo ARP. Tramite il comando mostrato di seguito è possibile visualizzare tutte le associazioni IP/MAC presenti nel PC (ovviamente gli indirizzi IP riportati nell’esempio sono puramente fittizi): La rimozione di tale associazione va fatta utilizzando il comando ARP nel modo seguente; >> arp –d 192.168.1.15 Adesso si è pronti a reinizializzare l’indirizzo IP all’interno del dispositivo RECS 101. Selezionando la finestra “Configurazione indirizzo IP” e premendo il pulsante “Cancella indirizzo IP” sarà visualizzata la finestra riportata in fig. 2. Dopo aver correttamente impostato l’indirizzo IP che si vuole cancellare, automaticamente alla pressione del pulsante “OK” l’indirizzo IP di RECS 101 sarà impostato al suo valore di default 0.0.0.0. Nel caso in cui non si conosce a priori il vecchio indirizzo IP del dispositivo, si può adoperare la funzione di ricerca indirizzo IP tramite la pressione del pulsante “Ricerca indirizzo IP”. Sarà visualizzata la finestra riportata in fig. 3. Inserendo l’indirizzo MAC riportato nel pannello posteriore del dispositivo (fig.4) e pre- mendo il pulsante “Trova” dopo qualche istante il software restituirà l’indirizzo IP correntemente impostato nel dispositivo RECS 101. Occorre sottolineare che la ricerca non avrà esito positivo se la Subnet Mask del PC adoperato per la configurazione è diversa da quella impostata all’interno del dispositivo RECS 101 che per default è 255.255.255.0. Verificare anche l’indirizzo IP del PC da cui accedete a RECS 101 facendo in modo che l’indirizzo del PC ricada all’interno della stessa Subnet Mask di RECS 101.Ad esempio, supponendo che RECS 101 sia configurato nel modo seguente: Indirizzo IP: 172.16.10.103 Subnet Mask: 255.255.255.0 il PC con il quale si vuole accedere a RECS 101 dovrà avere la seguente configurazione: Indirizzo IP: 172.16.10.xxx Subnet Mask: 255.255.255.0 Dove “xxx” sta per qualsiasi numero compreso tra 0 e 255. Per modificare la configurazione dell’indirizzo IP e della Subnet Mask del PC occorre adoperare l’esatta funzionalità di Windows (fig. 5). Una volta rimosso con successo il vecchio indirizzo IP precedentemente assegnato a RECS 101 si è pronti per inserire in nuovo indirizzo IP selezionando la finestra “Configurazione indirizzo IP” (fig. 1). Se nella tabella “DataBase BootP” appare la vecchia configurazione del dispositivo, occorre premere il pulsante “Modifica configurazione” altrimenti premere il pulsante “Aggiungi nuovo dispositivo”: si aprirà la finestra riportata in fig. 6. Tale finestra presenterà i valori in precedenza impostati nel caso in cui il dispositivo sia già presente nel DataBase BootP. Viceversa conterrà i campi vuoti. La fig. 6 riporta l’esempio di quest’ultimo caso. Modificare il campo “Indirizzo IP” col nuovo indirizzo IP, il campo “Indirizzo MAC” (l’indirizzo MAC del vostro dispositivo è situato nel pannello posteriore, fig. 4), il campo “Gateway” (se esiste un Gateway nella vostra rete) ed in fine il campo “Subnet Mask” (fig. 6). Premendo il tasto “Aggiungi” le informazioni editate saranno memorizzate nel database degli indirizzi IP associato a RECS Utility. Per completare la configurazione dell’indirizzo IP memorizzato occorre lanciare le funzionalità del server BootP premendo il pulsante “Avvio BootP” della finestra “Configurazione indirizzo IP” (fig. 1). Attendere qualche istante sino a quando lo stato del dispositivo evidenzia la scritta “Invio della replica BootP all’indirizzo IP “ [ x x x . x x x . x x x . x x x ] ” ( d o v e “xxx.xxx.xxx.xxx” sarà il nuovo indirizzo IP impostato). Attendere sino a quando il led Tx non finisca di lampeggiare, quindi premere il pulsante “Arresto BootP” (fig. 1). A questo punto l’indirizzo IP di RECS 101 è stato cambiato. Se l’inizializzazione dell’indirizzo IP è avvenuta con successo, il Led TX del dispositivo lampeggerà in continuazione. Per verificarne il corretto funzionamento utilizzare il comando Ping da DOS. Ad esempio, supponendo che il nuovo indirizzo sia 172.16.10.105, se il comando Ping risponde come di seguito riportato, allora la modifica dell’indirizzo IP ha avuto successo. In caso contrario ripetere tutto il procedimento descritto. Potrebbe capitare il caso che il dispositivo RECS 101 sia settato con un indirizzo IP non compatibile con la rete nella quale RECS 101 è stato installato. Ciò si traduce nel fatto che RECS 101 non può essere indirizzato e di conseguenza non è possibile cambiare il suo indirizzo IP. In questo caso l’unica soluzione praticabile è quella di sconnettere RECS 101 dalla rete Lan nella quale era installato e connetterlo direttamente ad un PC dotato d’interfaccia Ethernet mediante un cavo di rete incrociato. Le operazioni da compiere sono riassunte nei seguenti punti: 1.Scollegare RECS 101 dalla rete Lan. 2.Collegare RECS 101 ad un PC tramite un cavo di rete incrociato. Le figure 7 e 8 mostrano la differenza di connessione tra un cavo di rete dritto ed uno incrociato. RECS 101 può essere collegato direttamente ad internet e quindi rendere le sue applicazioni visibili da tutte le parti del mondo se è configurato con un indirizzo IP statico. La fig. 9 ne rappresenta una possibile connessione. In sintesi ciò che occorre è: 1.Un indirizzo IP statico, ovvero un indirizzo IP che abbia visibilità su Internet. 2.Una connessione diretta ad internet ad esempio ADSL o una rete LAN perennemente connessa. 3.Condividere la connessione ad internet tramite un Router e/o un Hub/Switch. 4.Collegare RECS 101 alla rete dopo averlo configurato con il relativo indirizzo IP statico.

UPLOAD DELL’INTERFACCIA UTENTE PERSONALIZZATA

Per sfruttare al massimo le potenzialità di RECS 101, occorre personalizzare l’interfaccia grafica del dispositivo agendo e/o modificando i files forniti dal costruttore. Definita l’interfaccia utente per l’applicazione che s’intende progettare non resta che fare l’upload all’interno della memoria flash di RECS 101. Si ricorda che la memoria totale a disposizione dell’utente è di 500 KByte, con supporto fino a 256 differenti file. Poiché RECS 101 utilizza un file system proprietario, 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) Impostare 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. Di seguito è presentato un esempio illustrativo atto a descrivere l’operazione di upload dell’interfaccia personalizzata presente nel CD-Rom fornito in dotazione situata all’interno della cartella “CP” (il lettore può scaricare tale software direttamente da questo indirizzo: http://www.intellisystem.it/recs/ downloads/CP.zip). Poiché l’upload del file di progetto avviene mediante il protocollo UDP (protocollo che non prevede la conferma della ricezione dei pacchetti inviati) il lettore, in realtà, pur non avendo a disposizione RECS 101 può emulare tale funzionamento anche se il dispositivo non è fisicamente connesso alla rete. Le operazioni da compiere per procedere all’operazione di upload sono le seguenti: 1) Dopo aver lanciato RECS Utility selezionare l’opzione “Web Upload” come riportato in fig. 10. 2) Premere il pulsante “Seleziona Files di progetto” e selezionare la cartella contenente i files (Ad esempio la cartella Control Panel “CP” contenuta all’interno del CD-Rom fornito in dotazione), premere “ok” per proseguire (fig. 11). 3) Inserire quindi il nome da assegnare al file di progetto e premere il pulsante “Salva” (fig. 12). 4) Premere il pulsante “Upload” per trasferire il file immagine all’interno di RECS 101. Questa procedura attiverà una barra di progressione che indica lo stato d’avanzamento dell’operazione di upload in corso. Al termine di tale fase sarà visualizzato un messaggio che comunica la chiusura dell’operazione. Nel caso si volessero programmare più RECS 101 con la stessa interfaccia utente e quindi col medesimo indirizzo IP si possono saltare le fasi descritte nei punti 1-4 a patto di possedere il file di progetto *.REC. In questo caso premere il pulsante “Seleziona File di progetto” (fig. 10), selezionare il file di progetto da trasferire in RECS 101 (fig. 13), quindi procedere con l’operazione di upload premendo il pulsante “Upload” (fig. 10).

IMPLEMENTAZIONE DELLE INTERFACCE HARDWARE SULLE PORTE DI INPUT/OUTPUT

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 consentono il corretto rispetto delle caratteristiche elettroniche della logica TTL implementata nelle due porte. Di seguito distingueremo due tipi d’interfacce rispettivamente una per la porta di Input ed un’altra per la porta di Output. 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 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 tra i due dispositivi, ne assicurano il corretto funzionamento. La fig. 15 mostra una possibile realizzazione del circuito proposto.

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 tra i due dispositivi ne assicurano il corretto funzionamento. La fig. 16 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 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.

DEVELOPER’S BOARD

Su richiesta dell’utente, Intellisystem Technologies è in grado di fornire una developer’s board per il dispositivo RECS 101 (fig. 17). La developer’s board di RECS 101 è una scheda che integra al suo interno 16 switches per la simulazione dei 16 ingressi digitali di RECS 101 e 16 display a LED per le relative 16 uscite. Gli switch relativi ai 16 ingressi sono stati progettati per lavorare secondo logica TTL “Low Active”, e i 16 display relativi all’output sono stati progettati per lavorare secondo logica TTL “High Active” compatibilmente alle specifiche di RECS 101. Le tabelle 1 e 2 riportate di segui- to riassumono quanto detto in precedenza. La RECS developer’s board non necessita di alimentazione esterna poiché gli viene fornita direttamente da RECS 101 tramite i due connettori relativi all’IO. Mediante la RECS developer’s board è possibile progettare e sviluppare applicazioni senza aver a disposizione l’eventuale impianto da controllare. Dotata di due connettori ausiliari la RECS developer’s board permette allo sviluppatore di estendere le sue funzionalità ad altri dispositivi elettronici in modo da poter effettuare velocemente le comuni operazioni di debugging delle applicazioni. La fig. 18 riporta la piedinatura dei connettori ausiliari descritti in precedenza.

Nel prossimo numero si discuterà dei seguenti argomenti riguardanti RECS 101: 1) Protocollo di comunicazione implementato in RECS 101. 2) Monitor dello stato di I/O. 3) Controllo dei comandi di Output. 4) Comunicare con RECS 101: L’interfaccia Socket in C. 5) Comunicare con RECS 101: L’interfaccia Socket in Java.

_________

A cura di Cristian Randieri. Articolo pubblicato sulla rivista Fare Elettronica N. 213/214 – Marzo/Aprile 2003.

Per scaricare l’articolo pubblicato sulla rivista, seguire il link riportato di seguito http://www.intellisystem.it/portfolio/fe-mar-apr-2003-recs-101-2-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 – 3° Parte

RECS 101: UN WEB SERVER EMBEDDED PER APPLICAZIONI DI CONTROLLO REMOTO TRAMITE TCP/IP – 4° parte 

Intellisystem Technologies