Corba è una tecnologia utilizzata per gestire ambienti distribuiti con vincoli prestazionali che non si sposano bene con le esigenze tipicamente embedded, in modo particolare dove sono richiesti precisi requisiti di tipo real-time. Per cercare di rispondere anche a questo particolare segmento è stata realizzata una versione real-time, ovvero RT-Corba: in quest’articolo mostreremo alcune caratteristiche di questa variante.
In un contesto distribuito, spesso, si utilizza il termine middleware come un particolare strato software che consente di dividere funzionalmente, e in modo trasparente rispetto all’applicazione, le caratteristiche di un modulo o di una board: l’invio di un dato si traduce semplicemente in un’istruzione al proprio middleware. Più precisamente, con questo termine solitamente ci si riferisce a un insieme di strati software che si comportano da intermediari tra diverse macchine e applicazioni indipendentemente dai protocolli di rete usati per la connessione: a questo riguardo si veda la Figura 1 dove si è preso in considerazione un middleware DDS.
Figura 1: I nuovi micro MPC5676R di Freescale
L’esigenza di una simile soluzione nasce allo scopo di risolvere i problemi di compatibilità che inevitabilmente possono sorgere tra gli attori coinvolti, hardware e software, nel momento in cui essi concorrono per la fornitura di un servizio che per sua natura non deve essere legato a una particolare configurazione. Non solo, con questa tecnologia è possibile dividere il carico funzionale di un sistema tra diversi soggetti al fine di non sacrificarne il funzionamento complessivo qualora uno degli attori coinvolti non sia più in grado di partecipare al sistema. Secondo alcuni, la caratteristica fondamentale di ogni middleware è la trasparenza e la disomogeneità. Infatti, trattandosi di reti con nodi distribuiti, i client che dovessero richiedere un servizio potrebbero utilizzare macchine e applicazioni diverse di volta in volta, mentre le richieste medesime potrebbero essere suddivise in diversi sottocompiti da smistare su più macchine server, anche potenzialmente differenti tra loro. In un approccio tipicamente middleware, ad esempio in un paradigma publish/subscribe, l’idea fondamentale è quella di evitare di realizzare un modello basato su un meccanismo di tipo client-server su reti con nodi distribuiti, perché ciò potrebbe avere impatti sulle prestazioni del sistema. Al fine di garantire al nostro sistema il rispetto dei requisiti di real-time è necessario utilizzare un middleware orientato alle QoS o Quality of Services. A questo proposito, l’OMG ha da tempo standardizzato le estensioni real-time di CORBA, RT-CORBA, che a oggi sono incluse nella versione 3.0 dello standard.
UN TIPICO SISTEMA DISTRIBUITO EMBEDDED
Una tecnologia di questo tipo può essere inserita nel campo della robotica. In effetti, è possibile, ad esempio, realizzare un sistema di localizzazione simultanea e costruzione delle mappe rilevando l’ambiente circostante e affidando il controllo e il rilievo a diversi robot tra loro coordinati. A questo proposito, in un contesto di questo tipo, o multi-robot, la comunicazione è uno degli aspetti più critici e allo stesso tempo importanti: condividere e scambiare informazioni sull’ambiente in cui lavorano gli agenti o sulla loro posizione può, infatti, migliorare sensibilmente le performance del sistema complessivo. Utilizzare più agenti cooperanti - robot - per la soluzione del problema richiede un’attenzione particolare sugli aspetti di comunicazione per consentire una corretta condivisione delle informazioni. Questo particolare compito può essere gestito con un sistema distribuito basato su un’architettura CORBA (Common Object Broker Request Architecture) il che consentirebbe anche di rendere più modulare e scalabile l’apparato software del sistema stesso: i robot sono rappresentati come server in grado di fornire servizi a un client centralizzato che si occupa dell’elaborazione e della gestione della mappa globale. La corretta temporizzazione può essere ottenuta grazie alla gestione di una scala dei tempi che consente di collocare le varie azioni in un contesto temporale comune. Non solo, con l’uso della variante RTCorba è possibile anche gestire particolari vincoli temporali.
CORBA
CORBA identifica l’acronimo Common Object Request Broker Architecture ed è, dal 1989, uno standard OMG, Object Management Group. CORBA consente lo sviluppo di applicazioni in grado di lavorare insieme attraverso le reti usando un protocollo di comunicazione standard denominato IIOP - Internet Inter - ORB Protocol. La Figura 2 mostra l’architettura di Corba.
Figura 2: Architettura dei micro MPC5676R
Ogni programma basato su CORBA è potenzialmente in grado di comunicare con qualsiasi altro programma che usi oggetti supportati da CORBA, indipendentemente dal sistema operativo, dal linguaggio di programmazione e dal tipo di rete su cui i programmi si trovano. Le applicazioni CORBA sono composte da oggetti, ovvero moduli software che hanno in sé funzionalità e dati con la possibilità di creare varie istanze di un medesimo oggetto. In una visione tipicamente client/server, gli oggetti, che forniscono servizi costituiscono la parte server, mentre il client è un’applicazione in grado di invocare, tramite CORBA, le funzionalità del server stesso, le cui istanze possono anche essere presenti su un calcolatore remoto. In realtà, per applicazioni che richiedono delle responsabilità piuttosto critiche nelle operazioni di delivery è necessario considerare dei vincoli temporali legati ai diversi servizi; infatti, a volte può essere necessario associare a un dato/servizio una validità temporale all’interno di uno spazio condiviso perché consegnare l’informazione in tempi certi e confrontabili può essere determinante per la gestione della funzionalità complessiva. L’uso di un middleware che non dia garanzie di performance o di predicibilità al processo di trasferimento verso differenti domini può incidere negativamente sui tempi e sul successo dell’interazione. È necessario, per rispettare questo vincolo, ricorrere a soluzioni che permettano di applicare al comportamento dei servizi il concetto di QoS (Quality of Service). Per rispondere a questo criterio diventa necessario utilizzare una nuova infrastruttura che preveda, insieme alla gestione delle politiche QoS, la possibilità di assegnare all’ORB una forma di priorità delle sue richieste o inserendo delle strategie di demultiplexing e dispatching. In un contesto embedded di tipo real time diventa così necessario utilizzare una nuova infrastruttura di comunicazione che permetta di scegliere la tipologia di connessione, il meccanismo di scheduling, la scelta e la gestione di un particolare QoS: dalla priorità dei singoli thread alle dimensioni del buffer fino ad arrivare a definire le connessioni a livello di trasporto. Nella specifica CORBA il cuore dell’intera architettura risiede nell’ORB, ovvero il mezzo utilizzato per trasportare le invocazioni remote da e verso gli oggetti CORBA. Due ORBs che appartengono allo stesso dominio possono comunicare direttamente fra loro senza intermediari, anche se poi nella realtà gli ORBs, di solito, appartengono a domini differenti perché, magari, offrono funzionalità proprietarie. Nei casi in cui una invocazione remota debba lasciare il suo dominio per raggiungere un dominio differente, l’invocazione dovrà attraversare un bridge. Il ruolo di un bridge è di assicurare che il contenuto e la semantica delle invocazioni siano tradotti dalla forma decisa dall’ORB mittente verso la forma comprensibile all’ORB destinatario. In tal modo, le applicazioni utente su di un certo ORB vedranno per le invocazioni soltanto il contenuto e la semantica a loro più appropriate. I bridges, infine, possono essere realizzati come estensioni dell’ORB Core oppure come oggetti di servizio del middleware. Il GIOP specifica un protocollo di trasferimento standard e un insieme di formati di messaggi per la comunicazione fra gli ORBs. Il protocollo GIOP è pensato per l’interazione fra gli ORBs ed è progettato per utilizzare i servizi forniti da qualsiasi livello di trasporto orientato alla connessione che soddisfi un insieme minimo di assunzioni. In RT-CORBA, la Figura 3 mostra la variante RT in ambito Corba, l’aspetto più interessante è stata la scelta di standardizzare le policy di QoS e le interfacce, in questo modo diventa possibile controllare le risorse e i meccanismi di comunicazione tra le diverse scelte utilizzate. Infatti, attraverso lo Scheduling Service, definito dalle specifiche, si facilita l’applicazione delle politiche di scheduling delle risorse astraendo i meccanismi di basso livello messi a disposizione dall’ORB. Come si vede, agli elementi già esistenti nel modello di riferimento classico si affiancano un real time ORB per la nuova interfaccia orientata alla QoS dell’ORB, un modulo di mapping sui meccanismi di priorità sottostanti e i moduli per la gestione della QoS offerta alle applicazioni.
Figura 3: La scheda di sviluppo MPC567XEVB
