Milano Luglio 2005

1. Soluzione middleware di interfacciamento della tecnologia RFID basata su architettura distribuita e canale multi BUS Milano Luglio 2005

2. Problematiche inerenti la tecnologia RFiD • Complessità tecniche • Gestione dei dati: • Grossi volumi: Devono essere gestiti grossi volumi di dati in quanto ogni lettore può acquisire più volte al secondo tutti i tag nel raggio di rilevazione. Nascono problemi di scalabilità e modularità della soluzione. • Filtraggio: Non tutti i dati ricevuti devono essere elaborati ma alcuni vanno filtrati secondo criteri configurabili. • Preelaborazione: il flusso dati acquisito dai lettori non è di norma direttamente utilizzabile dai sistemi gestionali e spesso necessita di preelaborazione. (Implementazione di una Business Logic a livello Middleware) • Integrazione nel contesto aziendale: • Integrazione: l’interfacciamento ai sistemi gestionali dell’azienda è una problematica complessa che necessita lo sviluppo di opportune interfacce dedicate • Affidabilità: l’utilizzo di metodi di interfacciamento diretti non consente un approccio di certificazione del dato creando una situazione non adeguata a sistemi critici • HW failure detection: integrare la tecnologia RFiD significa integrare HW eterogeneo a sistemi aziendali. Risulta difficile per i sistemi a valle identificare problemi derivanti da eventuali anomalie Hardware • Mancanza di standard: • HW eterogeneo: di fatto non vi sono standard di interfacciamento con i sistemi HW. L’integrazione diretta dei sistemi di lettura risulta onerosa e poco flessibile • Gestione, Monitoring e Alerting: Non esiste un protocollo standard di amministrazione dei lettori. Per questo motivo il monitoring e l’amministrazione di una rete di lettori risulta onerosa.

3. Lettore RFiD Lettore RFiD Lettore RFiD Come un Middleware risolve le problematiche? Sono necessari standard anche in un contesto dove questi non esistono. Servono sistemi che ‘assorbono’ le complessità intrinseche della tecnologia garantendo soluzioni scalabili ed affidabili E’ dunque necessario un layer di integrazione pensato ad hoc per queste tecnologie che sia in grado di trasformare il problema RFID in un ‘classico’ problema di integrazione E’ necessario un middleware dedicato RFID per ricondurre la problematica RFID ad una problematica ‘classica’ di integrazione Un middleware e’ un termine piuttosto generico che serve ad indicare una “struttura” informatica (hw/sw) destinata ad unire ed interfacciare sistemi “logicamente” distinti. Navision Biztalk Middleware RFiD ........ Nella realtà RFiD, il middleware e’ uno strato software che si fa carico di rendere disponibili ai sistemi utilizzatori i dati che vengono rilevati dai lettori, in modo efficiente e sicuro. In sintesi il suo compito è assorbire tutte le problematiche generate dalle soluzioni RFiD.

4. Middleware: Architettura della soluzione La soluzione Middleware Progettato per rispondere alle esigenze generali di applicazioni eterogenee è basato su architettura distribuita ed è costituito dalle seguenti componenti: RHM: modulo applicativo avente il compito di interfacciarsi direttamente con l’hardware di lettura e acquisire i dati CHM: modulo applicativo cui convergono i flussi dati e successivamente elaborati e distribuiti ai sistemi a valle FEA: applicativo di front end, un usufruitore dei dati a supporto del processo.Potrebbe essere associato ad ulteriori sistemi, ad esempio reportistica, monitoring, sistemi di supply chain, magazzino e tracciabilità • Peculiarità generali • Architettura distribuita • Struttura modulare • Sistema Scalabile • Comunicazione certificata • Sicurezza della trasmissione/ ricezione dati • Struttura programmabile real time • SDK di supporto • Comunicazione Multi BUS • Indipendenza dall’HW • Output multicanale • Ogni canale è programmabile separatamente • Interfacciamento avanzato HW RHM Remote Hardware Manager BS BS BS Protocolli eterogenei BS CHM Central Hardware Manager FEA Front End Application BS Applicativo Front end

5. RHM: caratteritische • RHM:Remote Hardware Manager • RHM è il modulo di acquisizione dati dall’hardware di rilevazione RF-iD. • Non è un semplice collettore ma un sistema avanzato di interfacciamento, • preelaborazione, comunicazione certificata e connessione multiBUS. • Ogni RHM è collegato tramite un BUS dati ad almeno un CHM. • RHM è strutturato in 4 blocchi fondamentali: • Acquisizione dati dalle sorgenti hardware • Manipolazione degli stessi secondo criteri programmabili • Trasmissione dei dati lungo un Bus di comunicazione • Fault tolerance • Caratteristiche peculiari: • Elaborazione dati • Elaborazione dati a “stadi” – ogni step del processo (acquisizione dati dall’hardware, formattazione, preelaborazione, pubblicazione ,certificazione......) è trattato in modo scorrelato dal precedente stadio di elaborazione • Stadio di preelaborazione dati - Possibilità di preelaborazione configurabile dei dati acquisiti mediante un modulo di business rules • Sicurezza dei dati • Comunicazione certificata - la comunicazione è certificata ovvero il componente per ogni dato spedito attende in risposta un segnale di acquisizione effettuata. Se ciò non accade il dato viene registrato in un database e la spedizione viene ripetuta ad intervalli ciclici. (Il dato viene comunque messo nel database.) • Gestione dello storico - Il database di supporto al componente mantiene uno storico configurabile dei dati transitati • Fault tolerance – Il sistema è ridondato a livello logico e in caso di malfunzionamento automaticamente viene spento il componente e attivato il suo speculare in modo da garantire la continuità del servizio • HW failure detection – Pericolose anomalie agli apparati HW vengono rilevate dal sistema e notificate

6. CR CR FD FD BS BS DBS DBS RHM: caratteritische • Interfacciamento dati verso HW RFID • Interfacciamento indipendente dall’ HW – L’architettura del sistema in nessun modo dipende dal tipo di HW utilizzato. Interfacciamento tramite Plug-in • Update real time - Inserimento di nuovi plug-in di interfacciamento senza la necessità di spegnere il sistema. • Interfacciamento dati verso i sistemi • Interfacciamento in output modulare – canali in uscita interfacciati attraverso moduli di comunicazione sostituibili e del tutto scorrelati dalle restanti componenti del sistema.Ne deriva una grande elasticità di utilizzo e modifica. • Update real time - Inserimento di nuovi plug-in di interfacciamento senza la necessità di spegnere il sistema. • Architettura di comunicazione Multi BUS - Il collegamento con il CHM e gli altri sistemi è multibus in modo indipendente dalla natura del dato trattato.Possono essere utilizzati BUS differenti contemporaneamente. • Scalabilità della soluzione e diagnostica • Scalabilità – L’architettura è distribuita, il numero degli RHM può essere aumentato senza impatti significativi. • Configurazione tramite XML – Sistema in tutte le sue componenticonfigurabile tramite XML • Diagnostica – Diagnostica avanzata del sistema • Testing AOK – Ogni modulo componente il sistema può funzionare in modalità AOK ovvero attivare un comportamento standard predefinito garantendo una rapida identificazione dei problemi Struttura indicativa del modulo RHM con Fault Tolerance e logica ridondata

7. CHM: caratteritische • CHM:Central Hardware Manager • CHM è il modulo centrale di gestione di tutti i flussi dati generati dagli RHM. • Ogni flusso dati viene acquisito, processato, postelaborato e messo a disposizione • in differenti canali di uscita programmabili destinati ad alimentare sistemi • erterogenei (gestionale aziendale,reportistica,monitoring,alerting....). • Il CHM è multi ingresso e multi uscita con comunicazione a BUS generico. • CHM è strutturato in 5 blocchi fondamentali: • Acquisizione dati dai BUS di comunicazione • Manipolazione degli stessi secondo criteri programmabili • Distribuzione dei dati mediante la creazione di diversi canali logici di output • Trasmissione dei dati lungo un BUS di comunicazione • Fault tolerance • Caratteristiche peculiari: • Elaborazione dati • Canali multipli di ingresso – il CHM acquisisce i dati in tempo reale ed in contemporanea da tutti gli RHM istanziati • Canali multipli di uscita – il CHM presenta più canali logici di uscita programmabili singolarmente. • Elaborazione dei dati a “stadi” – ogni step del processo (acquisizione dati dall’hardware, formattazione, preelaborazione, pubblicazione ,certificazione......) è trattato in modo scorrelato dal precedente stadio di elaborazione • Stadio di preelaborazione dati – Possibilità di preelaborare i dati in ingresso al CHM • Stadio di postelaborazione dati – Il flusso dati può essere postelaborato in modo da incontrare le esigenze dei sistemi destinatari. • Sicurezza dei dati • Comunicazione certificata – Il CHM è il garante della comunicazione ovvero ogni dato spedito dagli RHM viene acquisito e restituita una conferma di ricezione. • Gestione dello storico - Il database di supporto al componente mantiene uno storico configurabile dei dati transitati • Fault tolerance – Il sistema è ridondato a livello logico e in caso di malfunzionamento viene spento il componente e attivato il suo speculare

8. Dispatcher BS Esempio di struttura del modulo di dispatcher dei canali logici App Interface FEA CHM: caratteritische • Interfacciamento verso i sistemi • Interfacciamento ai sistemi modulare - Interfacciamento tramite plug-in ovvero a componente modulare, in nessun modo predefinito nell’architettura • Dispatching programmabile – ogni canale di output del flusso dati può essere instradato separatamente e postelaborato. • Architettura di comunicazione Multi BUS - Il collegamento con il CHM e gli altri sistemi è multibus in modo indipendente dalla natura del dato trattato.Possono essere utilizzati BUS differenti contemporaneamente. • Scalabilità della soluzione e diagnostica • Scalabilità – L’architettura è distribuita, il numero dei CHM può essere aumentato senza impatti significativi. • Configurazione tramite XML – Il sistema è in tutte le sue componenticonfigurabile tramite XML • Diagnostica – Diagnostica avanzata del sistema • AOK – Ogni modulo componente il sistema può funzionare in modalità AOK ovvero attivare un comportamento standard predefinito garantendo una rapida identificazione dei problemi

9. FEA: caratteritische • FEA:Front End Application • Il FEA a differenza dei precedenti moduli non è un componente ma • una famiglia di applicazioni . • Un FEA è un qualsiasi applicativo a supporto del processo che usufruisce dei dati elaborati dal CHM • FEA può essere: • Sistema di gestione delle operazioni di picking a supporto dell’operatore • Sistema di gestione e controllo inventario magazzino • Sistema di gestione di un qualsiasi HW complesso o insieme di apparati • Sistemi di fornitori o terze parti a supporto del processo • Interfacciamento dati verso CHM • Interfacciamento dati modulare – Ogni FEA comunica attraverso un interfaccia modulare dedicata • Connessione multiBUS – Ogni FEA può essere connesso ad un diverso BUS dati • Comunicazione Sincrona – Il FEA è collegato in modalità sincrona ovvero il dato è disponibile in tempo reale. Vi è la possibilità di utilizzare una comunicazione asincrona ovvero in modalità batch tramite XML • preelaborazione dati • preelaborazione – i dati vengono elaborati a più stadi, se necessario, nel RHM e CHM prima di essere disponibili per il FEA. L’impatto sui sistemi aziendali è ridotto nella complessità • Multi canale – Ogni FEA si collega ad un canale logico il cui flusso dati può liberamente essere trattato senza implicazioni sui restanti canali

10. Esempio applicativo – Supply Chain Cliente Fornitore Magazzino Magazzino FEA FEA RFiD RFiD BarCode BarCode RHM RHM CHM CHM Interfaccia operatore Interfaccia operatore FEA FEA Biztalk Biztalk I/O I/O RHM RHM Gate RFiD entrata merce Gate RFiD uscita merce ERP (Nav.) SCM SCM ERP (Nav.) ERP Sistema integrato basato su tecnologia RFiD ‘ibrida’ in architettura distribuita

11. Contatti Soluzione middleware di interfacciamento della tecnologia RFID basata su architettura distribuita e canale multi BUS ActValue consulting & solutions www.actvalue.com Via De Gasperi, 126 20017 Rho (MI) Contatti: Andrea Barchiesi Tel. 02 934642.25 cell. 335-6328484 Andrea.Barchiesi@ActValue.com Stefano Bergonzi Tel. 02 934642.21 cell. 335-8252558 Stefano.Bergonzi@ActValue.com