ISOBUS Transport Protocol

Le funzioni principali del Transport Protocol sono due:

1. Pacchettizzazione e riassemblaggio dei messaggi 2. Gestione delle connessioni

Per quanto riguarda il punto uno bisogna dire che messaggi con dimensione maggiore di otto bytes non sono allocabili in un singolo Data Frame CAN normalmente utilizzato per le comunicazioni ISOBUS. Dunque messaggi lunghi devono essere spezzati in pacchetti più piccoli, ed ogni pacchetto deve essere spedito in Frame diversi. In fase di ricezione poi ogni

singolo Frame deve essere ricevuto e processato in modo da riassemblare il pacchetto originario. Tale comportamento è tipico delle reti a pacchetti, ed è ad esempio simile a quanto accade per il protocollo TCP normalmente utilizzato per connessioni via Internet.

Il Data Frame CAN include un campo dati lungo otto bytes. Siccome ogni pacchetto in cui viene suddiviso un messaggio di grandi dimensioni deve essere individualmente identificato, in modo da poter correttamente riassemblare il messaggio stesso, il primo byte del campo dati viene utilizzato come numero di sequenza (sequence number) del pacchetto. Per tale motivo ad ogni pacchetto viene assegnato un numero di sequenza che può variare tra 0 e 255. Dunque la massima dimensione di un messaggio diventa (255 pacchetti x 7 bytes/pacchetto) = 1785 bytes.

Per quanto riguarda il riassemblamento dei pacchetti essi verranno ricevuti in sequenza date le caratteristiche di una rete ISOBUS. Quindi ogni pacchetto facente parte di un singolo messaggio dovrà essere assemblato in ordine di sequence number, in una singola sequenza di bytes. Al termine del procedimento questa sequenza di bytes sarà passata alla applicazione che ha richiesto il messaggio di grandi dimensioni. E’ importante notare che contrariamente a quanto accade per altri tipi di dati in questo caso non c’è nessuna garanzia sulle tempistiche di consegna, come vedremo infatti la gestione delle connessioni prevede anche il rifiuto o l’interruzione di una comunicazione. Ciò va tenuto in conto ma non vanifica l’utilizzo del transport protocol per i nostri scopi, dai quali sono escluse informazioni real-time, ma si pensa di trasmettere dati per diagnosi e fleet management che non hanno tipicamente vincoli stringenti in fatto di tempistiche di consegna, anche considerando che fuori dalla rete ISOBUS gli stessi dati dovranno passare attraverso Internet con ritardi ordini di grandezza superiori a quelli tipici di ISOBUS. In ogni caso nel seguito sono presenti alcuni cenni sul punto due, ovvero la gestione delle connessioni, al fine di meglio comprendere l’indeterminatezza associata ai tempi di trasmissione.

Nel seguito si farà riferimento con il termine ‘sender’ al controller ISOBUS che trasmette un messaggio di ‘Request to Send’ (nel seguito RTS) ovvero richiesta di invio, mentre ‘receiver’ sarà il controller che in risposta invierà un messaggio ‘Clear to Send’ (nel seguito CTS) ovvero invio accettato.

La gestione delle connessioni (Connection Management) riguarda l’aprire, utilizzare e chiudere delle connessioni ‘virtuali’ per trasferimenti tra specifici controller. Una connessione virtuale in ambiente ISO 11783 si può considerare come una associazione temporanea tra due controller allo scopo di trasferire un singolo messaggio di grandi dimensioni. Nel caso invece

la connessione sia da uno a molti (broadcast) non è previsto controllo di flusso né è prevista una chiusura esplicita della connessione virtuale stessa.

Una connessione si considera iniziata nel momento in cui un controller trasmette un messaggio RTS ad un indirizzo di destinazione. Il messaggio RTS contiene la dimensione dell’intero messaggio in bytes, il numero di pacchetti complessivo tramite i quali il messaggio verrà trasferito, il massimo numero di pacchetti che possono essere spediti in risposta ad un singolo CTS, ed un’altro parametro ISOBUS, ovvero il Parameter Group Number del messaggio trasportato. Al momento della ricezione di un messaggio RTS, un controller può decidere di accettare la connessione o rifiutarla. Per accettare la connessione il receiver trasmetterà un messaggio CTS. Il CTS inviato contiene il numero di pacchetti del messaggio che il receiver può accettare, ed il sequence number del primo pacchetto atteso. Il receiver deve assicurarsi di aver disponibili sufficienti risorse per gestire il numero di pacchettti dei quali sta accettando la consegna. Il sequence number del pacchetto nel caso di una connessione appena aperta, sarà uno.

E’ da notare che il CTS potrebbe non contenere l’accettazione di tutti i pacchetti che compongono il messaggio completo.

Per rifiutare la connessione un controller deve rispondere con un messaggio di Connection Abort (termine connessione). La connessione può essere rifiutata per una ragione qualsiasi, anche se tipicamente mancanza di risorse, ad esempio memoria ne è la causa.

La connessione si considera stabilita per il sender quando questi riceve un CTS corrispondente al suo RTS dal receiver. La connessione si considera stabilita per il receiver nel momento in cui questi ha trasmesso con successo il suo CTS in risposta al RTS ricevuto.

Queste definizioni sono utili a determinare quando un Connection Abort deve essere inviato per chiudere una connessione. Un receiver deve mandare un Connection Abort se ha letto il messaggio RTS e decide di non stabilire la connessione. Ciò permette di evitare che il sender debba attendere un timeout prima di cercare di attivare una nuova connessione.

Vediamo ora qualcosa sul trasferimento dati, che inizia dopo che il sender ha ricevuto il messaggio CTS. Una eccezione è nel caso in cui il trasferimento dati avviene in seguito ad un messaggio del tipo ‘Broadcast Announce’ (annuncio di trasmissione broadcast), in questo caso il messaggio CTS non è usato. Nel caso invece di messaggi tra due soli controller, il receiver è responsabile della gestione del flusso tra i due controller coinvolti nella trasmissione. Se il receiver vuol fermare temporaneamente il flusso dati, mantenendo la connessione aperta, deve utilizzare un CTS settando il numero di pacchetti che è disponibile a ricevere eguale a zero.

Nel caso il flusso debba essere fermato per alcuni secondi il receiver deve ripetere la trasmissione del CTS ogni mezzo secondo per avvisare il sender che la connessione non si è interrotta.

Vediamo ora qualcosa sulla chiusura delle connessioni. Esistono due casi di chiusura in assenza di errori. Il primo occorre nel caso di trasmissione broadcast, il secondo nel caso di connessione punto a punto. Nel primo caso non viene effettuata nessuna chiusura esplicita della connessione, che viene considerata chiusa in seguito alla semplice ricezione dei dati previsti. Nel caso di connessione punto a punto invece ed al momento della ricezione dell’ultimo pacchetto previsto, il receiver trasmette un ‘end of message ack’ (avviso di fine messaggio per ricevuta) al sender. Ciò per segnalargli che la connessione viene considerata chiusa dal receiver. Il ‘end of message ack’ serve a far sì che la connessione venga liberata per successivi utilizzi da parte di altri controller.

Nel caso di trasmissione broadcast i receiver non devono inviare un messaggio di Connection Abort. Invece nel caso di connessione punto a punto sia il sender che il receiver possono, in qualsiasi momento, utilizzare un Connection Abort per terminare la connessione.

Ad esempio se il receiver dovesse accorgersi che non sono rimaste risorse sufficienti per processare il messaggio stesso, può semplicemente terminare la connessione emettendo un messaggio di Connection Abort. Al ricevimento del Connection Abort, tutti i pacchetti costituenti il messaggio di grandi dimensioni verranno scartati.

Altra causa di chiusura di una connessione per timeout può essere il guasto di uno dei controller coinvolti nel caso di trasmissione punto a punto. Quando il sender o il receiver decidono di chiudere una connessione per qualsiasi ragione incluso il timeout, devono spedire un messaggio di Connection Abort. A titolo di esempio nella seguente Tabella 5.4 sono elencati alcuni motivi per cui viene effettuato un Connection Abort con i codici associati secondo lo Standard ISOBUS:

Tabella 5.4: ISOBUS - Motivi e codici di Connection Abort

V a lu e D e sc rip tion

1 A lr ead y in on e or m or e co nn ec tio n m a na ged s e ss ion s a nd c an not s up po rt ano th er .

2 S ys tem r es ou rc e s w ere nee de d fo r an othe r tas k s o this c onn ec tio n m an age d s es s io n wa s ter m in ated.

3 A tim eo ut o c cu rr ed a nd this is the c on ne ction a bo rt to c los e the s es s ion .

4–2 50 R es e rv ed for as s ig nm ent in a futur e Inter nation al S ta nd ard . 2 51– 25 5 P e r IS O 1 17 83 P ar ts 7 & 8 de fin itio ns .

Lo Standard ISOBUS definisce in ogni dettaglio come devono avvenire le transazioni associate al Transport Protocol, in questo paragrafo si è semplicemente voluto evidenziare alcune caratteristiche fondamentali, ovvero che è un protocollo pensato per il trasporto di dati punto a punto o anche broadcast, che la dimensione massima di un singolo messaggio trasportabile è di 1785 bytes, e che per quanto lo Standard cerchi di minimizzare tempi di attesa nella consegna dei dati, le tempistiche non sono assolutamente garantite, anzi in qualche modo il TP è da considerare a più bassa priorità rispetto al normale traffico ISOBUS, visto che può essere interrotto per qualsiasi ragione in qualsiasi momento. Nel seguente paragrafo verranno introdotti alcuni cenni ad una estensione del TP, detta Extended Transport Protocol, visto che può essere utile alla soluzione dei problemi analizzati nel Task 1.