Come nel caso del Data Link Layer, anche sull'Interaction Layer sono sta- ti eseguiti numerosi test minori per veri care le singole funzionalità. Alla ne dell'implementazione, per validare tutto quanto realizzato, è stato con- dotto un test più signi cativo che attraverso l'uso dell'Interaction Layer ha permesso di veri care l'intero Protocol Stack.
L'idea di base del test è quella di sfruttare un demo realizzato da Davide Cantini durante il proprio lavoro di tesi [Can 02], aggiungendo l'uso del siste- ma di comunicazione. Il demo, realizzato per E.R.I.K.A., utilizzava l'RCX per pilotare un piccolo mezzo su un percorso tracciato, sfruttando i rileva- menti fatti attraverso dei sensori ottici: in base alle rilevazioni, l'algoritmo di controllo era in grado di capire la posizione del mezzo rispetto al percorso e pilotare due motori (con modalità PWM, Pulse Width Modulation) in modo da correggere la direzione del mezzo stesso. Attraverso la versione originale del driver infrarosso per E.R.I.K.A., e sfruttando la Tower ed un sempli-
ce programma per sistema Linux, era inoltre possibile inviare dei comandi all'RCX, ottenendo cambiamenti nella velocità e piccoli controlli simili.
Il test realizzato a partire da tale demo prevede di monitorare il com- portamento del mezzo su un PC con S.Ha.R.K., sfruttando il sistema di comunicazione per lo scambio di dati. In particolare l'applicazione sull'RCX ha il compito di pilotare il mezzo sul percorso, ed inviare sul canale i dati di volta in volta richiesti dall'applicazione sul PC; quest'ultima invece può richiedere vari servizi, dall'invio di grandezze presenti sull'RCX alla modi ca delle grandezze stesse. Quando richiede una serie di dati periodici, l'appli- cazione mostra i dati ricevuti in un diagramma temporale, permettendo così di veri care la frequenza di arrivo dei dati.
Il test è più signi cativo rispetto ai precedenti per varie ragioni: • si sfrutta non solo il Data Link Layer ma anche l'Interaction Layer; • una delle unità è in movimento, quindi più soggetta ai disturbi;
• dato il movimento di una delle unità, è logico che le due interfacce infra- rosse siano più lontane di quanto non lo siano state nei test precedenti; inoltre per lo stesso motivo si perde anche l'allineamento, introducendo altre di coltà di comunicazione;
• su entrambe le unità, ma specialmente sull'unità mobile con E.R.I.K.A., il sistema è decisamente più carico, avendo altri compiti essenziali da svolgere.
Il test ha messo in evidenza numerosi aspetti del sistema, dai tempi necessari per la comunicazione all'occupazione di memoria.
Si nota in particolare che il sistema progettato è, nonstante la semplicità, abbastanza e ciente, dato che i lunghi tempi necessari per le trasmissioni sono dovuti alla ridotta velocità del Physical Layer. Il tempo misurato tra la richiesta relativa ad una variabile e l'arrivo del suo valore è molto alto, arrivando a circa 250 ms. I due fattori che in buona parte determinano
questo risultato sono legati entrambi al Physical Layer, ossia il baud rate estremamente basso e la necessità di inviare i complementi dei singoli byte. Come già detto in precedenza la necessità dei complementi limita al di sotto del 50% le rese del sistema, il che signi ca anche un aumento di un fattore 2 dei tempi necessari per la trasmissione. Riuscire ad eliminare tale limitazione porterebbe a tempi quasi dimezzati. Stesso dicasi per quanto riguarda il baud rate, in particolare i tempi necessari sono quasi inversamente proporzionali al baud rate dell'interfaccia seriale. Si nota inoltre che i tempi sono dovuti quasi interamente alla vera e propria trasmissione: nel caso preso in considerazione infatti era richiesto complessivamente lo scambio di 52 byte tra le due unità, e considerando la trama prevista ed il baud rate i tempi minimi di trasmissione erano di circa 238 ms; le attività aggiuntive legate alla ricetrasmissione, come la preparazione del pacchetto, pesano dunque per circa 12 ms, meno del 5%. Questo signi ca tra l'altro che l'attività di trasmissione non incide più di tanto sulle altre attività del sistema, ed è quindi facilmente integrabile nelle normali operazioni che questi eettua. È chiaro comunque che quest'ultimo punto è fortemente dipendente dal tipo di tra co generalmente richiesto, come ad esempio dalla frequenza di campionamento delle variabili condivise. Altro aspetto messo in evidenza è la scarsa occupazione di memoria delle due implementazioni. Infatti la versione scritta per S.Ha.R.K. non supera i 20 kB, mentre per quanto riguarda E.R.I.K.A. le dimensioni scendono a meno di 10 kB1.
Va detto però che complessivamente la versione attuale non è soddisfa- cente. I tempi sono lunghi, per le tipiche applicazioni di controllo per le quali il sistema è pensato, inoltre la necessità di una linea di vista tra gli elementi si rivela una limitazione piuttosto forte. Durante il monitoraggio si è infatti
1Nel caso di E.R.I.K.A. è di cile dare una stima precisa dell'occupazione di memoria
delle sole librerie di comunicazione, dato che il processo di compilazione fornisce un unico eseguibile che comprende sistema, librerie ed applicazione. Di fatto l'introduzione delle librerie porta ad un aumento delle dimensioni dell'eseguibile che va dai 5 ai 10 kB, a seconda delle funzionalità richieste, del numero di variabili condivise ed altri aspetti simili.
constatata la totale perdita di comunicazione in certi istanti, dovuta in parte all'aumento della distanza tra gli elementi, ma legata soprattutto al disalli- neamento tra i due dispositivi infrarossi causato dal fatto che l'RCX era in movimento su un percorso chiuso, e quindi nel compiere un giro completo ruotava su se stesso di 360 gradi.