ISOBUS, luci e ombre

La tecnologia ISOBUS, che prevede il collegamento e il dialogo tra sistemi provenienti dai più disparati costruttori, rappresenta forse la massima espressione di collaborazione a livello multi aziendale; e se è vero quello che recitava Henry Ford “mettersi insieme è un inizio, rimanere insieme è un progresso, lavorare insieme un successo” allora ci chiediamo “com’è possibile che, dopo tutti questi anni, tale tecnologia non abbia già soppiantato i vecchi sistemi dedicati”?

Il background

Fino all’inizio degli anni ’90 in ambito agricolo la comunicazione tra trattrice e ogni singolo attrezzo (o implement) a essa collegato, avveniva tramite collegamenti dedicati e conseguenti allestimenti.

Fig. 1 – Interno di una cabina dotata di collegamenti dedicati a singola interfaccia.

Come mostrato in figura 1, in cabina l’operatore poteva ritrovarsi una vera e propria accozzaglia di interfacce, connettori e cavi; tutti quanti accuratamente disposti secondo il “senso estetico” dell’installatore.  

Tale configurazione, oltre che risultare economicamente svantaggiosa (a causa della presenza di un’interfaccia per ogni singolo implement), potrebbe essere definita anche pericolosa. Un elevato affollamento di dispositivi e un posizionamento inadeguato possono infatti ridurre il campo visivo dell’operatore con eventuali problemi di sicurezza (mancato rispetto della norma ISO 5721 [1]).

Da considerare anche il fatto che disporre ogni volta di un’interfaccia uomo-macchina diversa, a seconda dell’applicazione, rende difficoltosa la gestione dell’intero sistema. Il fatto di avere comandi non standardizzati, differenti sia per forma che per collocazione delle informazioni risulta anti-intuitiva e certamente può comportare un rallentamento sia nella fase di attuazione comandi che di feedback all’operatore.

L’implementazione di cablaggi non standard e/o non previsti dal costruttore, implica infine la necessità di forare la cabina; ciò può comportare, seppur limitatamente, una riduzione della sicurezza strutturale (ISO 5700 [2]) e sicuramente una diminuzione prestazionale della cabina stessa (ISO 14269 [3] in tutte le sue sottoparti per il riscaldamento, la ventilazione, l’aria condizionata, il filtraggio dell’aria e la pressurizzazione della cabina).

La filosofia di  ISOBUS

Per ovviare al problema derivante dell’utilizzo di singoli collegamenti customizzati, gli stessi costruttori di trattrici e di implement, si sono impegnati nella definizione di un protocollo di comunicazione standardizzato, che ha portato alla stesura della norma ISO 11783 “Serial control and communications data network”, in tutte le sue sottoparti [4].

Tale protocollo noto a tutti gli addetti al settore col nome di ISOBUS, si basa su un semplice principio: una trattrice conforme alle specifiche dispone di un terminale grafico (Virtual Terminal – VT), il quale attraverso un unico bus di comunicazione (basato sul protocollo CAN) può dialogare con qualsiasi implement compatibile, riconfigurandosi all’avvio, per mostrare le informazioni provenienti dagli attrezzi collegati alla rete (fig. 2).

Fig. 2 – Esempio di rete ISOBUS con trattrice e due implement.

Così facendo a ogni dispositivo sarà assegnata una pagina grafica di interfaccia operatore, per la visualizzazione e in controllo, utilizzando per tutti il medesimo terminale.

La norma definisce non solo il tipo di dati e la struttura dei messaggi, ma anche la tipologia dei connettori, in modo da garantire collegamenti di tipo plug&play tra tutte le sottoparti del sistema (fig. 3).

Fig. 3 – Connettori per il collegamento plug&play e sezione del bus di comunicazione.

Nel momento stesso in cui un implement viene collegato, si attiva automaticamente una fase di identificazione e configurazione tra le centraline della rete che permette il riconoscimento del nuovo dispositivo,  la cui interfaccia di controllo sarà disponibile sul VT una volta terminata tale fase.

In quest’ottica, a seconda della tipologia di lavorazione necessaria sul campo, i vari attrezzi vengono collegati alla trattrice, formando un’unica rete di comunicazione e un sistema i cui “componenti” sono completamente intercambiabili, e il loro “assemblaggio” non comporta costi aggiuntivi di modifica del sistema.

Tale rete rimane però volutamente separata dal sottosistema Power Train della macchina, al fine di evitare interferenze o sovraccarichi, in una rete così critica e importante.

Per quanto detto sin ora si può affermare che ISOBUS rappresenti una notevole innovazione in ambito agricolo; nelle cabine troviamo veri e propri computer di bordo, che attraverso interfacce grafiche intuitive, permettono all’operatore di interagire in modo semplice e standardizzato con tutti i dispositivi della rete.

Da questo punto di vista la tecnologia semplifica le operazioni svolte dall’operatore agricolo e allo stesso tempo rende la complessità intrinseca del sistema trasparente all’utente.

Dalla guida manuale all’automazione

Fig. 4 – Esempio di configurazione veicolo con reti multiple, sia standard che proprietarie.

La comunicazione nelle varie sottoreti del sistema può essere proprietaria e non necessariamente deve essere conforme allo standard ISOBUS, come mostrato in figura 4.

L’elemento che funge da gateway tra la rete proprietaria della trattrice e la rete composta dagli attrezzi collegati è chiamato Tractor ECU (TECU, secondo quanto definito nella norma ISO 11783-9).

Queste centraline per l’interconnessione vengono classificate in base alle potenzialità, definite dallo standard ISOBUS, che esse stesse supportano:

·         CLASSE 1: trasmissione delle informazioni di base tra il trattore e le ECU connesse al bus attrezzo (gestione potenza, informazioni di velocità, meccanismi di sollevamento, presa di forza, controllo luci e informazioni sulla lingua utilizzata);

·         CLASSE 2: in aggiunta alla CLASSE 1 è in grado di trasmettere informazioni più dettagliate sullo stato sia della trattrice che dei sottosistemi connessi (formato tempo e data, forza di trazione nel meccanismo di sollevamento posteriore, controllo sistema luci dell’attrezzo);

·         CLASSE 3: in aggiunta alla CLASSE 2 è in grado si ricevere ed eseguire alcuni comandi che le ECU degli implement o il Task Controller (1) inviano sulla rete (posizionamento del meccanismo di sollevamento posteriore, velocità di rotazione della presa di forza, set point di velocità e sistema di accoppiamento con l’attrezzo e controllo valvole).

Per tutte quante le classi vi è la possibilità opzionale di ricevere informazioni dal sistema di navigazione GPS. L’esperienza comune porta a pensare all’attrezzo come qualcosa di subordinato alla trattrice; le funzionalità di classe 3 introducono una vera rivoluzione concettuale nella catena di comando (fig. 5).

Fig. 5 – Concetto di flusso di comando invertito.

A fronte dell’innovazione introdotta sono però presenti forti implicazioni per quanto riguarda la  sicurezza funzionale. Premesso che i comandi inviati dall’operatore hanno la massima priorità e devono sempre poter “sovrascrivere” (override) una qualsiasi richiesta proveniente dagli implement, si possono tuttavia verificare condizioni di “conflitto” legate alla modularità del sistema. Visto che possono essere collegati contemporaneamente più attrezzi alla stessa trattrice, il numero massimo e la loro tipologia dipendono dalla lavorazione del terreno che si desidera compiere e dalla potenza massima erogabile dalla trattrice stessa (per i latifondi americani si può ragionevolmente pensare al collegamento contemporaneo di 5 o 6 attrezzi), è possibile ritrovarsi in configurazioni in cui due o più implement inviano richieste discordanti alla TECU.

Da notare che le richieste si suddividono in:

·         Set point – richiesta di un valore puntuale di funzionamento

·         Limiti – definizione del range di funzionamento ammesso

Indipendentemente dalla tipologia delle richieste attive, per motivi di sicurezza la TECU attribuirà a un solo implement per volta il controllo (set point) della funzione desiderata (sempre subordinato ai comandi operatore).

Esaminiamo il caso esemplificativo in cui alla trattrice siano collegati soltanto due attrezzi (ATT1 e ATT2) e ipotizziamo che per una lavorazione ottimale del terreno ATT1  richieda alla macchina di procedere a una velocità compresa tra 2-10 km/h, mentre ATT2 richieda per motivi strutturali di operare entro il range 0-5 km/h.

Fig. 6 – Esempio di intersezione non nulla delle richieste.

Come evidenziato in figura 6, in questo caso l’intersezione delle richieste non è nulla e il corretto range di funzionamento risultante è compreso tra 2 e 5 km/h, pertanto l’implement a cui è affidato il controllo della funzione deve comandare il set point all’interno di tale range.

Sarà comunque compito della TECU garantire che l’effettiva velocità del mezzo rientri nei limiti ottenuti dall’intersezione.

Fig. 7 – Esempio di intersezione nulla delle richieste.

Sempre a titolo di esempio consideriamo ora il caso mostrato in figura 7, dove cioè ATT1 richieda di procedere a velocità compresa tra 0-2 km/h, mentre ATT2 richieda di operare a velocità compresa tra 3-5 km/h.  In quest’ultimo caso l’intersezione delle richieste è nulla, ed è compito della TECU segnalare i dettagli della situazione di conflitto, i quali  devono essere illustrati in modo chiaro all’operatore, cosicché egli possa scegliere consapevolmente quale richiesta soddisfare.

Allo stato attuale la configurazione multi-implement e la possibilità di gestire un’elevata automazione del controllo del trattore (Task Controller e Sequence Controller (2)) mettono in luce alcune criticità dello standard, che sono attualmente oggetto di discussione all’interno dei comitati di normazione internazionali e delle associazioni che riuniscono i maggiori costruttori a livello mondiale. Un esempio di tali associazioni è AEF (Agricultural Industry Electronics Faundation), i cui gruppi di lavoro, composti principalmente da personale tecnico, hanno il compito di fornire le linee guida per la corretta applicazione degli standard internazionali, creare le relative strutture di supporto e proporre eventuali modifiche e integrazioni allo standard ISOBUS.

Alcune ombre

Essendo ISOBUS, per definizione, uno standard aperto dedicato a sistemi modulari, presenta tutti i lati positivi ma anche i pericoli e le complessità legati a tali architetture.

La possibilità di riconfigurare di volta in volta la macchina, collegando in un unico sistema “n” generici attrezzi (ognuno dei quali richiede particolari condizioni al contorno per il corretto funzionamento) rende difficoltosa e complessa la politica di gestione.

Inoltre, per macchine dotate di TECU CLASSE 3, è stato recentemente sollevato il problema della sicurezza dal punto di vista legale.

Infatti, poiché in un sistema aperto “chiunque” può interfacciarsi e instaurare un dialogo con i restanti sottosistemi connessi alla rete, può accadere che anche dispositivi non conformi avviino una comunicazione.

Considerando il caso estremo in cui tale comunicazione porti a un uso improprio e/o pericoloso della macchina, viene spontaneo chiedersi: “se il  conflitto tra le richieste inoltrate alla TECU dalle centraline dovesse essere fonte di incidenti, chi può o deve essere ritenuto responsabile?”.

La colpa è del “mandante” (implement non conforme che ha generato una richiesta inappropriata) o dell’ “esecutore materiale” (la trattrice che ha attuato la corrispondente manovra)?

Il buon senso indurrebbe a indicare come responsabile il costruttore dell’attrezzo non conforme, ma è risaputo che in caso di incidenti, dipanare la matassa delle responsabilità giuridiche non è cosa così scontata.

Questo è principalmente il motivo che spinge, ancora oggi, alcune case costruttrici a introdurre gradualmente lo standard; fino a quando cioè non vi sarà un’adeguata legislazione che stabilisca chiaramente la suddivisione di responsabilità tra il produttore della trattrice, il produttore di implement, il cliente finale e l’operatore.

Infine dal punto di vista normativo per i sistemi modulari, anche avvalendosi di dispositivi “realmente conformi”,  non è possibile effettuare un’analisi dei rischi esaustiva della macchina.

L’approccio delle linee guida finora elaborate si limita generalmente a un risk assessment per lo scenario “trattore più singolo implement”, data l’ovvia impossibilità di considerare a priori tutte le possibili configurazioni tipiche di un sistema aperto.

Di conseguenza, anche disponendo di sottosistemi conformi, non è comunque garantito che la loro connessione realizzi automaticamente un sistema completo conforme; essendo, a rigore, lo scenario di rischio diverso a seconda delle possibili configurazioni multi-implement, potrebbe sempre verificarsi una configurazione che non sia stata precedentemente considerata e che necessiti un riesame per il sistema completo (come ad esempio avviene in ambito aeronautico).

Questi punti di analisi giustificano la lentezza con cui si sta diffondendo il protocollo ISOBUS; ciononostante i produttori stanno continuando a lavorare su due binari paralleli ma palesemente antitetici: da un lato lo sviluppo del protocollo unificato standard (architettura aperta plug&play), dall’altro la definizione di architetture proprietarie (chiuse) le quali implementano meccanismi di security tali da  permettere solo a implement pre-certificati, riconosciuti dalla trattrice, l’attivazione di  funzioni di qualsiasi genere. Se le soluzioni chiuse saranno solo uno step intermedio in attesa della completa implementazione di ISOBUS, oppure si affermeranno come soluzioni permanenti sul mercato dipenderà dalla possibilità di superare in modo esaustivo, e in tempi ragionevoli, gli ostacoli tecnici e legali precedentemente descritti.


(1) Task Controller: ECU dedicata in grado di impartire comandi sia alla trattrice che agli implement, modificando il loro comportamento sulla base di una programmazione temporale e georeferenziata, ricevuta dal sistema di controllo dell’azienda agricola (Farm Management System).

(2) Sequence Controller: ECU dedicata, similare al Task Controller, che permette la registrazione e la successiva riproduzione di operazioni, al fine di agevolare il lavoro dell’operatore, evitando la ripetizione manuale di sequenze di comandi che possono risultare a volte complesse.

Bibliografia

[1] ISO 5721: 1989 – Tractors for agriculture – Operator’s field of Vision.

[2] ISO 5700: 2006 – Tractors for agriculture and forestry – Roll-over protective structures (ROPS) -Static test method and acceptance conditions.

[3] ISO 14269: 1997 – Tractors and self-propelled machines for agriculture and forestry – Operator enclosure environment, Parts 1 – 5.

Richiedi maggiori informazioni










Nome*

Cognome*

Azienda

E-mail*

Telefono

Oggetto

Messaggio

Inserire questo codice*: captcha 

Ho letto e accetto l'informativa sulla privacy*

Lascia un commento

Inserisci il tuo commento
Inserisci il tuo nome