di Andrea Gatti
Pubblicato su MokaByte Numero 33 – Settembre 99
In molte applicazioni, il controllo e il monitoraggio remoto non sono prestazioni nuove; da tempo sono utilizzate connessioni seriali con PC, terminali e reti per scopi diagnostici, in altri casi sono utilizzate connessioni telefoniche per un accesso su richiesta. Queste interfacce sono state spesso progettate ad hoc, dedicate al dispositivo specifico. In altri casi, per ottenere un codice il più compatto possibile per l’interfaccia dal lato “embedded”, sono state create delle interfacce utente semplificate con codici di comando al limite della criptatura.
Introduzione
L’uso delle tecnologie di Internet permette le stesse funzioni delle interfacce dedicate, le possibilità di configurazione sono decisamente più ampie e ad un costo di sviluppo decisamente più basso.
Lo sviluppo dell’interfaccia diventa la progettazione di pagine HTML e del software applicativo in grado di rispondere alle query del browser e la prima attività esterna in cui Internet può fare la differenza è durante l’installazione presso il cliente.
Una connessione Internet permette al vostro utente di interagire col vostro prodotto attraverso un browser Web piuttosto che con un’interfaccia utilizzante hardware dedicato (interruttori, display, ecc.) eliminandone il costo relativo.
Il progetto dell’interfaccia utente diventa un’applicazione software che potete standardizzare per tutti i prodotti. Un’interfaccia browser migliora anche la curva di apprendimento di un nuovo prodotto perché molti utenti hanno già familiarità con l’Explorer di Microsoft o il Navigator di Netscape.
Facendo leva sulla potenza e robustezza dei browser, un Web server di tipo embedded può dare al sistema un’eccezionale flessibilità. L’interfaccia utente diventa parte del sistema piuttosto che essere un componente software separato da installare e manutenere presso il cliente. Qualsiasi utente che utilizza un browser Web può interagire con il sistema senza bisogno di implementazioni aggiuntive da parte dello sviluppatore.
Inoltre adattare le interfacce utente diventa una cosa relativamente semplice in quanto le pagine HTML contengono tutte le differenze riguardo visualizzazione, lingua e grafica mentre il software di sistema è sempre lo stesso.
Un altro grande vantaggio è dato dalla possibilità di rendere disponibile in rete la documentazione del prodotto, abbattendo il costo di stampa, spedizione e aggiornamento della documentazione stessa migliorandone nello stesso tempo la qualità.
Aggiornando la documentazione del prodotto, potete aggiornare contemporaneamente anche il software operativo. Il costo dell’aggiornamento on-line è solo una frazione del costo per fare un retrofit sul firmware richiamando gli utilizzatori o con un programma di cambio dell’hardware.
Netscape Communications (Mountain View, CA), ad esempio, usa questa tecnica nel suo browser. Infatti, il file di help, dalla versione 3.0, “punta” a locazioni del sito di Netscape. Questa tecnica permette a Netscape di aggiornare e modificare la documentazione dei prodotti senza distribuire gli errati corrige a tutti i clienti migliorando nello stesso tempo la qualità della documentazione stessa.
Un prodotto in rete può anche distribuire parte del carico di elaborazione ad altri computer connessi sulla rete.Vista attraverso il browser, la potenza di calcolo di un sistema embedded può apparentemente aumentare. L’interfaccia utente può dare un’analisi statica dei dati del sistema puntando il browser verso un partner più potente sulla rete fornendogli i dati grezzi. Il partner effettua i calcoli ed invia i dati al browser: dal punto di vista dell’utente l’informazione appare come proveniente dal sistema embedded. Questa tecnica permette di utilizzare un processore di costo inferiore evidenziando capacità di una macchina più potente.
Molto dipende comunque dalle caratteristiche e dalle prestazioni del sistema. Quando aggiungere anche solo un kbyte di memoria rischia portare il sistema fuori mercato, il sovraccarico di un server embedded e dei protocolli di Internet (IP) può non essere accettabile.
Il protocollo TCP/IP ha dei meccanismi per la gestione degli errori di trasmissione tali da ridurre in maniera considerevole la velocità di trasmissione e di conseguenza compromettere i tempi di risposta dell’interfaccia; questi meccanismi rendono non deterministica la connessione tramite il TCP/IP
L’altra faccia della medaglia
Dopo averne visto i vantaggi, è opportuno anche mettere a fuoco i punti critici. Internet è lenta, a volte inaffidabile e soggetta ad attacchi da parte di hacker che possono anche violare la privacy dei vostri clienti. Un’accurata scelta dei componenti hardware e software permette di convivere con questo tipo di problemi utilizzando tutte le potenzialità della rete.
Una regola primaria è di rendere il funzionamento del sistema indipendente dalla rete, progettandolo in modo da sfruttare la rete senza dipendere da essa.
Internet non è deterministica e sarebbe folle utilizzarla in una forma qualsiasi di controllo ad anello chiuso. Se l’applicazione richiede prestazioni temporalmente critiche la soluzione deve essere necessariamente diversa. Ad esempio, i componenti critici possono essere collegati con una rete hard real-time per utilizzare poi lo stack TCP/IP come “porta” per il monitoraggio non invasivo del sistema stesso (vedi figura 1) ed è questa una delle più interessanti caratteristiche della connessione in rete: la capacità di collezionare dati operativi riguardo il vostro prodotto, sia in real-time sia periodicamente.
Internet è utilizzabile per migliorare le prestazioni del prodotto, ma nello stesso tempo è necessario proteggere il sistema da utenti non autorizzati con metodi che vanno dalla gestione di password alla criptatura dei dati. Un’altra tecnica fra le più recenti e popolari è quella di mettere in piedi una rete privata virtuale (VPN Virtual Private Network). Una VPN permette comunicazioni sicure su internet utilizzando un Point-to-point Tunnelling Protocoll con criptatura dei messaggi con algoritmi a chiave pubblica.
Internet si presta bene anche alla raccolta di informazioni; questo è però un argomento che tocca il “nervo scoperto” della privacy. Bisogna chiedersi se i propri clienti vogliono che voi conosciate tutto sulle loro abitudini. Se pensate di raccogliere informazioni tramite la rete è preferibile discuterne preventivamente con ogni cliente e prevedere meccanismi per disabilitare in tutto o in parte questa possibilità.
La scelta dell’architettura
Per connettere un sistema ad Internet possiamo seguire diverse strade: LAN, modem, collegamenti radio o gateway, come schematizzato in figura 2.
Il tipo di connessione ha necessariamente delle ricadute sulla progettazione del sistema e può richiedere anche hardware esterno aggiuntivo; è necessario anche verificare che il processore abbia la potenza necessaria per gestire sia il carico dell’applicazione sia quello della comunicazione. Le necessità Hardware del sistema possono essere sorprendentemente modeste: in base al tipo di connessione, servono interfacce di rete o una normale seriale RS232, un processore di prestazioni almeno equivalenti ad un 80386, lo spazio di memoria sufficiente ad ospitare il codice del server, dello stack TCP/IP e le pagine HTML. Parte integrante dell’architettura del sistema è il software di rete e la scelta richiede un’attenta valutazione dei costi e della efficacia della soluzione ed è sicuramente il software di rete la parte meno nota (vedi Fig.3). Fortunatamente il software di rete è disponibile come “componente” presso i realizzatori di componenti e di sistemi operativi real-time (RTOS). A titolo di esempio, uno stack TCP/IP completo richiede almeno 50kbyte di ROM e 2kbyte di RAM e il vostro sistema deve avere non solo lo spazio di memoria sufficiente per il software di rete ma ripartire le risorse fra l’applicazione e il software di comunicazione.
Inviare le pagine Web su Internet va a carico di un Web server: il Web server è un programma che resta in attesa di una connessione con un client (es. un browser Web), una volta stabilita la connessione, il server invia i dati predefiniti come ad esempio una pagina HTML con i dati dell’applicazione
I componenti software sono rappresentati in figura 3, l’uso di tutti o solo di alcuni dipende ovviamente dall’applicazione. Un set minimo include un sistema operativo real-time (RTOS) e il software applicativo, il server http, lo stack TCP/IP e i driver per l’hardware di rete (es. Ethernet); se il sistema utilizza per la connessione una linea RS232 o un modem è necessario anche il point-to -point protocol (PPP) oppure il serial-line Internet protocol (SLIP). I componenti software sono indicati in figura 3, i componenti minimi sono indicati dalla nota (a).
I driver di comunicazione, lo stack TCP/IP, il point-to-point protocol (PPP) e il serial-line Internet protocol (SLIP) da anni fanno parte della maggior parte dei RTOS come componenti di comunicazione standard. Quello che deve essere aggiunto è l’http server che possa essere utilizzato da un normale browser Web per comunicare con il sistema embedded.
Applicazioni per Java
Nello scenario presentato, Java è sicuramente una delle soluzioni più interessanti. E’ un ambiente pensato per applicazioni distribuite e l’automazione industriale è un campo interessante.
Java può girare su mainframe o su workstation per controlli di alto livello, controllori di processo o di macchina. I componenti distribuiti si possono scambiare controlli, dati e codice. Strumenti come database connectivity, remote method invocation, applet, servlet sono pensati per questo tipo di applicazioni.
L’indipendenza dalla piattaforma gioca un ruolo marginale in questo caso, Il programma è progettato per lavorare su una piattaforma specializzata che prevede, in buona parte dei casi, dispositivi di I/O collegati ad hardware esterno altrettanto specializzato. I componenti real-time sono progettati per lavorare correttamente con determinate risorse. Java può avere un ruolo dove è richiesto che i dispositivi siano aggiornabili. Modificando il sistema, anche aggiungendo dispositivi ed aumentando le prestazioni il sotware di base può essere agevolmente adattato: facendo buon uso del dinamic binding il software che gira su dispositivi di basso livello può essere scalato su dispositivi di alto livello aggiungendo l’hardware e il software corrispondente senza modificare il codice di base originale facilitando la manutenzione del codice stesso.
Java può beneficiare dello stesso tipo di situazione di mercato che ha aiutato le architetture tipo IBM 460, Sun, DEC VAX e Wintel. Se Java diventa un’architettura di riferimento, cosa molto probabile vista la tendenza, può valere la pena di usarlo solo per avere accesso alle applicazioni che altri hanno sviluppato per essa. Un telefono può includere Java per accedere facilmente ad un’applicazione tipo calendario, ad un’applicazione di posta elettronica e un diario elettronico per ragazzi può includere Java per accedere ad una collezione di giochi.
Applicazioni embedded di grosse dimensioni comprendono normalmente molti programmi, applicazioni grafiche molto “pesanti”, applicazioni con capacità di gestione degli errori molto approfondite, sistemi esperti ecc. Tutti questi sistemi possono avere dei vantaggi dalla efficienza di gestione della memoria di Java
Da notare che le informazioni visualizzate nella pagina sono di tipo statico e che va distinto fra un’animazione e la visualizzazione di dati aggiornati dinamicamente. Una pagina HTML è tipicamente predefinita e il server può modificare solo alcune caratteristiche del testo. Sulla gestione e visualizzazione dinamica di dati dinamici Java e le tecnologie ad esso associate possono giocare un ruolo determinante. Utilizzando degli applet Java nella definizione della pagina è possibile bypassare questa limitazione e rendere dinamica l’interfaccia.
Per il server, gli applet sono solo un altro file da trasferire: la JVM fa parte del browser o in altri casi del RTOS.
Un’applicazione reale
I concetti espressi nelle parti precedenti sono stati utilizzati per la realizzazione dell’applicazione illustrata in figura 1. Il sistema si compone essenzialmente di una parte a bordo treno, il Train RoGate Gateway, e da una parte di terra. Il sistema è stato realizzato nell’ambito del progetto UE TR1045 – ROSIN (Railway Open System Interconnection Network – http://www.labs.it/rosin/) finanziato in parte dalla UE e in parte da aziende del settore (DG XIII – Telematics Application Programme – Transport Sector).
Il RoGate fa parte insieme agli altri dispositivi di bordo di sistema hard real-time ed è collegato ad essi con una rete tipo MVB (Multifunction Vehicle Bus) conforme alla standard IEC61375 – TCN Train Communication Network. Il Rogate si comporta come un proxy server per permettere l’accesso dall’esterno, in questo caso con una connessione GSM, al sistema treno. In figura 4 è riportata l’architettura tipica di un veicolo ferroviario.
Al momento dell’inaugurazione della rete, il RoGate rileva tutti i dispositivi presenti sulla rete e, utilizzando i servizi specifici della rete (TNM TCN Network Management), la mappatura degli impianti e/o funzioni supportati dai vari dispositivi. I componenti software di questa applicazione sono illustrati in figura 5.
L’uso delle API permette di sviluppare le applicazioni lato client come, ad esempio, la presentazione delle informazioni per gli interventi di manutenzione o per l’analisi del life-cycle cost (costo del ciclo di vita). L’uso di Java permette la portabilità dell’applicazione o del’applet in quanto lingua franca di Internet e un buon livello di robustezza e sicurezza al tutto in quanto pensata espressamente per sistemi distribuiti (Java RMI object oriented RPC). L’uso di XML permette l’accesso ai dati localizzati sul server.
Il RoGate permette, oltre a rendere disponibili i dati di targa dei vari impianti, anche il monitoraggio non intrusivo del traffico di rete; la figura 6 illustra l’architettura funzionale del RoGate stesso e la figura 7 ne illustra lo schema interno.
