RICERCA ITALIANA     

Programma di ricerca

COMMUTA: Componenti hardware/software mutanti per sistemi distribuiti dinamicamente riconfigurabili

Università di riferimento

Politecnico di TORINO - AUTOMATICA E INFORMATICA - TORINO(TO)

Responsabile dell'Unità di ricerca

Paolo PRINETTO

Descrizione

L'obbiettivo prioritario del progetto è la definizione, la realizzazione e la sperimentazione di un'architettura distribuita riconfigurabile basata sulla possibilità di modificare dinamicamente le compenti sia hardware che software di un sistema mediante l'impiego di agenti mobili e di dispostivi hardware programmabili.

Il modello architetturale proposto si basa su nodi di diverse tipologie, che interagiscono mediante una rete di comunicazione di tipo wired o wireless. Le due principali categorie di nodi sono:

- Nodi agenzia: si tratta di nodi di elaborazione dedicati alla gestione ed al coordinamento degli agenti operanti nel sistema. I nodi agenzia operano secondo il paradigma dei web-services, gestendo la pubblicazione dei servizi implementati dagli agenti mediante un server UDDI e offrendo meccanismi di ricerca evoluti

- Nodi mutanti: tali nodi sono composti, dal punto di vista fisico, da un'architettura di elaborazione di tipo classico (processore, memoria, I/O, etc.) e da unità FPGA programmabili dinamicamente. I nodi mutanti saranno i responsabili dell'elaborazione vera e propria richiesta dall'applicativo in esecuzione. La loro architettura e quindi le loro funzionalità hardware e software saranno configurabili a run-time attraverso l'utilizzo degli agenti mobile presenti nel sistema.

L'idea base del progetto dell'Unità di Ricerca del Politecnico di Torino è la definizione dell'architettura e delle funzionalità dei nodi muatnti, ossia dei nodi di elaborazione e riconfigurazione dinamica. Rispetto ai normali sistemi riconfigurabili, i nodi mutanti proposti in questo progetto dovranno essere in grado di:

- soddisfare esigenze di calcolo di tipo applicativo, realizzando, con un circuito hardware dedicato (implementato all'interno dell'FPGA), alcune delle funzionalità software previste dall'agente;

- garantire il corretto funzionamento del sistema a seguito di guasti individuati da operazioni di test, determinando nuove condizioni operative che richiedono la sostituzioni di componenti hardware.

Entrambe le funzionalità dovranno quindi essere realizzate utilizzando al meglio la riconfigurabilità sia hardware che software del nodo mutante. In particolare:

- per soddisfare le esigenze di calcolo e di prestazioni, la riconfigurabilità permetterà di non legare l'implementazione del nodo ad una specifica applicazione. Ad esempio, se si ha necessità di sicurezza, si potrà configurare il sistema con un processore crittografico, mentre lo stesso hardware, in diversa configurazione, potrà essere utilizzato con funzioni di compressione dati per applicazione di trasmissioni di immagini. In questo caso il processore potrà avere anche potenza più limitata, semplificando la realizzazione del nodo di elaborazione e limitando la dissipazione di potenza nei casi in cui non è necessario utilizzare l'hardware aggiuntivo;

- per garantire il corretto funzionamento del sistema ed aumentare il grado tolleranza ai guasti i nodi mutanti saranno progettati in modo da permettere di riparare/sostituire un componente guasto attraverso una riconfigurazione dinamica della logica programmabile.

Un aspetto estremamente innovativo dell'architettura proposta è la gestione della riconfigurazione tramite agenti mobili. In questo modo non è necessario memorizzare sul singolo nodo le sequenze di bit di configurazione che non servono. Al momento opportuno saranno "trasportate" sul nodo da un agente. E' dunque evidente che il progetto introduce una generalizzazione del concetto di mobilita' in quanto lo spostamento dell'agente puo' comportare l'attivazione di un nuovo modulo software oppure l'attivazione di un nuovo componete hardware specificamente configurato per l'applicazione. Di fatto l'hardware riconfigurato puo' essere considerato una sorta di processore specializzato per l'applicazione e si viene così a creare un modello di "hardware mobile", concetto innovativo ed introdotto in questo progetto per la prima volta.

Facendo riferimento al piano descritto nel modello A, il lavoro dell'unità Politecnico di Torino nel progetto COMMUTA si articolerà nelle seguenti attività:
WP1 Definzione delle soluzioni
- T1.C0: Definizione delle soluzioni integrate
- T1.P1: definizione e progettazione di soluzioni architetturali sia hardware sia software del nodo mutante dedicate alla gestione e al coordinamento della mobilità degli agenti da e per il nodo stesso;
- T1.P2 - definizione e progettazione di soluzioni architetturali sia hardware sia software del nodo mutante in grado di consentire un efficiente partizionamento e riconfigurabilità delle risorse hardware del sistema;
- T1.P3 - definizione e progettazione di soluzioni architetturali sia hardware sia software del nodo mutante in grado di rilevare, durante il normale funzionamento, eventuali guasti permanenti nelle componenti del nodo stesso e proporre efficienti ed efficaci soluzioni di riconfigurazione per la risoluzione del problema
- T1.C1 Integrazione delle soluzioni

WP2 Realizzazione del prototipo
- T2.C0: Definizione della piattaforma di integrazione
- T2.P1: implementazione delle soluzioni definitie nel WP1

WP3 Valutazione sperimentale
- T3.C0: Definizione del dimostratore e pianificazione degli esperimenti
- T3.P1: valutazione delle prestazioni e della copertura dei guasti nel prototipo

Per la realizzazione dei task obbiettivi sopra citati, lo schema concettuale dell'architettura del nodo mutante (schematizzata in figura) sarà composta dai seguenti moduli:

- un Layer di gestione agenti (deliverable del task T1.P1). Questa prima interfaccia si occuperà di gestire le comunicazioni con i nodi agenzia, di ricevere ed autenticare agenti in arrivo sul nodo mutante, e di inviare tramite agenti richieste di riconfigurazione provenienti dal nodo stesso;

- Configuration Processor (deliverable del task T1.P2) con il compito di gestire la riconfigurazione dell'hardware programmabile del nodo. Le richieste di riconfigurazione potranno arrivare sia dall'interno del nodo stesso, per esempio da un'applicazione, oppure dall'esterno, per esempio da un nodo agenzia.

- un Diagnostic Test Processor (deliverable del task T1.P3) incaricato di testare periodicamente le risorse hardware (e software) del sistema, di localizzare eventuali malfunzionamenti ed in base alla loro tipologia richiedere al Configuration Processor di attivare una riconfigurazione dell'hardware che ripari l'errore o di richiedere all'esterno una riconfigurazione del nodo completo, in modo da non rischiare di propagare l'errore all'esterno del sistema stesso.





L'architettura proposta sarà dunque in grado di soddisfare le due specifiche principali del nodo mutante, ossia la riconfigurabilità per esigenze di calcolo di tipo applicativo e la riconfigurabilità per esigenze di riparazione del nodo o del sistema. Richieste per entrambi i tipi di riconfigurazione potranno arrivare sia dall'interno che dall'esterno del nodo:

- Richieste interne:
o Per esigenze prestazionali e di calcolo: da applicazioni che richiedono risorse diverse o più efficienti di quelle al momento disponibili nel sistema.
o Per esigenze di riparazione: dal Diagnostic Test Processor, dopo il rilevamento di un guasto all'interno del nodo.

- Richieste esterne:
o Per esigenze prestazionali e di calcolo: dai nodi agenzia, che possono decidere di riconfigurare il nodo in modo da modificare/ottimizzare le prestazioni e/o funzionalità a livello di sistema.
o Per esigenze di riparazione a livello di sistema: dai nodi agenzia in seguito alla necessità di riparare o riconfigurare il sistema in seguito a un guasto.

Particolare attenzione sarà riservata alle strategie di riparazione. In particolare verrà implementata un strategia gerarchica di riparazione. Una volta che il Diagnostic Test Processor ha rilevato, diagnosticato e localizzato il guasto, si dovrà scegliere, in base alla tipologia e criticità del guasto stesso, quale delle seguenti quattro strategie di riparazione attivare:

- Riparazione di una parte di un componente: la parte hardware guasta del componente viene programmata all'interno dell'FPGA. Questa strategia è possibile solo nel caso di componenti la cui architettura è altamente modulare.

- Riparazione di un componente completo: il componente viene messo off-line e sostituito con una sua "replica", programmata all'interno dell'FPGA.

- Riparazione della funzionalità di un nodo: una certa funzionalità del nodo viene implmentata all'interno dell'FPGA.

- Riparazione del nodo: il nodo intero viene messo off-line, e sostituito a livello di sistema da un'altro nodo mutante.

Le funzionalità dell'architettura saranno sperimentate in una reale applicazione di controllo di sensori distribuiti, applicazione particolarmente significativa per la quale è richiesto il controllo di numerosi dispositivi distribuiti in ampie aree geografiche. In questo caso si suppone che il sistema operi in due diverse fasi. In una prima fase il sistema utilizza l'hardware riconfigurabile a disposizione per incrementare le prestazioni di algoritmi di filtraggio. In una seconda fase, a seguito di un guasto di un'unità di memoria per la gestione dei segnali di campo, utilizza lo stesso hardware per sostituire il modulo di memoria, implementando quindi anche l'algoritmo di filtraggio interamente in software.