Gateway CAN Bus per trattori autonomi: architettura di integrazione e cause dei guasti nei sistemi da campo

Perché l'integrazione del CAN bus nei trattori autonomi fallisce sul campo

Il posizionamento RTK sui trattori autonomi garantisce ormai abitualmente una precisione inferiore ai 5 cm. Gli algoritmi di pianificazione del percorso sono stati convalidati in diverse implementazioni commerciali. Tuttavia, i tecnici sul campo che lavorano all’adeguamento dei trattori autonomi continuano a riscontrare lo stesso tipo di guasto: il sistema funziona in condizioni controllate, ma smette di funzionare a metà stagione durante le effettive operazioni sul campo.

Nella maggior parte dei progetti di retrofit, il malfunzionamento è riconducibile sempre allo stesso punto: non all’antenna GNSS, né all’algoritmo di tracciamento, ma al livello di integrazione del bus CAN sul veicolo stesso. Manca una conversione affidabile del protocollo. Manca un circuito di controllo locale. I comandi di sterzata passano attraverso un’infrastruttura che non è mai stata progettata per il controllo in tempo reale del veicolo.

Questo articolo tratta tre argomenti: quali sono le cause dei malfunzionamenti nell’integrazione del bus CAN nelle implementazioni di trattori autonomi, perché le scelte architetturali più comuni aggravano tali problemi e quale sia il funzionamento effettivo, a livello di sistema, di un gateway per bus CAN appositamente progettato per i trattori autonomi.

Gateway CAN Bus per trattori autonomi

1. Protocolli bus eterogenei privi di un livello di traduzione unificato

Esiste un gateway CAN bus per trattori autonomi che risolve un problema che si presenta sin dalle prime fasi di ogni progetto di retrofit: il veicolo utilizza contemporaneamente più bus incompatibili tra loro e non esiste alcun dispositivo in grado di collegarli. 

In un tipico intervento di retrofit su un trattore autonomo vengono utilizzati contemporaneamente almeno quattro bus di comunicazione incompatibili tra loro:

  • Centralina dello sterzo e centralina motore su bus CAN — protocollo J1939, in genere a 250 Kbps o 500 Kbps
  • Ricevitore RTK-GNSS che trasmette stringhe NMEA tramite RS232
  • Sensori IMU e del suolo su RS485 con protocollo Modbus RTU
  • Implementare il feedback di posizione sugli ingressi digitali (DI)

Queste bus sono fisicamente e logicamente incompatibili. I frame J1939 non corrispondono ai registri Modbus. Le frasi NMEA non vengono analizzate come segnali CAN. Senza un dispositivo che li colleghi tutti a livello locale, i dati dei sensori non possono raggiungere l’algoritmo di controllo e i comandi di sterzata non possono raggiungere l’attuatore.

Nei progetti di retrofit, la soluzione più comune consiste nell'utilizzare convertitori di protocollo separati collegati in serie tramite un'interfaccia IPC. Ciò risolve il problema della compatibilità, ma comporta una maggiore complessità del cablaggio, un numero maggiore di punti di guasto e nessun miglioramento nella latenza di controllo.

2. Accumulo di latenza nei circuiti di regolazione con instradamento su cloud

È proprio qui che l’architettura del gateway CAN bus per i trattori autonomi si discosta in modo più netto dai progetti incentrati sul cloud — ed è qui che i guasti sul campo sono più difficili da diagnosticare. 

Nelle implementazioni sul campo, la velocità della rete raramente rappresenta il fattore limitante. È invece la variabilità a costituire il fattore limitante.

Alcune architetture di trattori autonomi fanno passare il ciclo di correzione dello sterzo attraverso un server remoto: i dati dei sensori vengono caricati, la deviazione viene calcolata in remoto e il comando di correzione viene rinviato. Quando la rete funziona bene, la latenza di andata e ritorno è gestibile. Nei campi agricoli con copertura 4G irregolare, spesso non è così. A una velocità operativa in campo di 6–8 km/h, un picco di 150–200 ms nella trasmissione dei comandi produce un errore trasversale misurabile che si accumula nel corso di una passata.

L'inserimento di un circuito di controllo sensibile al tempo su un collegamento a latenza variabile costituisce un disallineamento architetturale. Il controllo della sterzata tramite bus CAN richiede una risposta locale deterministica, non una risposta dipendente dal cloud.

3. Affidabilità ambientale per l'intera stagione di crescita

I requisiti di affidabilità per un gateway CAN bus sui trattori autonomi sono diversi da quelli delle implementazioni industriali standard — e la maggior parte dell’hardware generico non regge il confronto. 

Durante le operazioni estive sul campo, la temperatura all’interno della cabina raggiunge regolarmente i 50–65 °C. A ciò si aggiungono le vibrazioni costanti sui terreni accidentati, la polvere generata dalle operazioni di lavorazione del terreno e di raccolta, nonché i lavaggi periodici con idropulitrice. Nei progetti di retrofit, i componenti che superano i test al banco spesso si guastano nel giro di una sola stagione di coltivazione. Gli alloggiamenti raffreddati a ventola accumulano polvere. I connettori si allentano a causa delle vibrazioni. I componenti progettati per una temperatura massima di 70 °C non dispongono di margine termico sufficiente in una cabina che raggiunge regolarmente temperature più elevate.

Gateway CAN bus, IPC e PLC: confronto tra le architetture di controllo dei trattori autonomi 

Per gli ingegneri incaricati di valutare l'architettura di controllo nell'ambito di un progetto relativo a un trattore autonomo, la scelta tra gateway CAN bus, IPC e PLC determina la complessità dell'integrazione, i costi di manutenzione e l'affidabilità a lungo termine in condizioni operative reali. 

Ogni approccio ha un caso d'uso legittimo: la domanda è quale di essi soddisfi effettivamente i requisiti di un sistema CAN bus per trattori autonomi.

PLC

I PLC garantiscono un controllo locale deterministico con decenni di comprovata affidabilità nell’automazione industriale. Il limite nelle applicazioni relative ai trattori autonomi è rappresentato dall’ampiezza del protocollo. I PLC standard non gestiscono in modo nativo la decodifica dei frame J1939, l’analisi sintattica delle frasi NMEA e il calcolo della deviazione dal percorso in esecuzione parallela. L’aggiunta di tali funzionalità tramite moduli aumenta i costi hardware e la complessità di integrazione. I PLC sono particolarmente adatti nei casi in cui le sequenze di controllo sono fisse e i requisiti di protocollo sono limitati — ad esempio, per implementare una logica di sollevamento legata ai segnali dei confini del campo.

IPC industriale

Un IPC con sistema operativo Linux gestisce l’intera gamma di protocolli grazie a schede di interfaccia adeguate e dispone della potenza di calcolo necessaria per attività impegnative: stack di navigazione completi, visione artificiale per il rilevamento degli ostacoli, fusione complessa dei dati dei sensori. Il problema pratico nell’installazione in cabina agricola è di natura ambientale. Il raffreddamento a ventola comporta il rischio di accumulo di polvere nelle condizioni tipiche della lavorazione del terreno e della raccolta. Il fattore di forma è più grande di quanto la maggior parte delle cabine possa ospitare comodamente. L’assorbimento di potenza dagli impianti elettrici del veicolo a 12 V/24 V richiede una gestione aggiuntiva dell’alimentazione. Per le applicazioni su trattori autonomi ad alta potenza di calcolo, un IPC è spesso ancora la soluzione più indicata. Per la guida RTK-GNSS con sterzo tramite bus CAN e controllo degli attrezzi tramite ISOBUS, è necessario un hardware più complesso di quanto richiesto dall’attività stessa.

Gateway CAN bus per veicoli agricoli

Un gateway industriale senza ventola, dotato di interfacce native CAN, RS232, RS485 e I/O digitali, risolve direttamente il problema del bridging dei protocolli senza gli svantaggi ambientali di un PC industriale raffreddato a ventola. Il circuito di controllo locale opera direttamente sul gateway, senza alcuna dipendenza dalla rete nel percorso di controllo. Il fattore di forma compatto lo rende adatto alle installazioni in cabina. L’ingresso CC ad ampio intervallo di tensione si collega direttamente agli impianti elettrici del veicolo senza necessità di ulteriori conversioni di potenza.

Il compromesso è rappresentato dal limite di potenza di calcolo. Le attività basate sulla visione artificiale e gli stack di navigazione completi superano la capacità di elaborazione degli attuali gateway agricoli edge.

Per l’impiego di trattori autonomi che utilizzano il posizionamento RTK-GNSS con controllo dello sterzo tramite bus CAN e gestione degli attrezzi tramite ISOBUS, un gateway dedicato per il bus CAN rappresenta la scelta architettonicamente più appropriata — non perché sia più semplice, ma perché si adatta al carico di lavoro effettivo e ai vincoli ambientali.

Compatibilità J1939 e ISOBUS: cosa comporta effettivamente l’integrazione del bus CAN

Garantire la corretta compatibilità tra J1939 e ISOBUS è una delle sfide meno documentate nell'implementazione dei gateway CAN bus per trattori autonomi — e una delle cause più comuni di ritardi nell'integrazione nei progetti reali. 

Le macchine agricole di John Deere, Trimble, Topcon, AGCO e della maggior parte dei principali OEM comunicano tramite CAN utilizzando J1939 come livello di protocollo di base. ISOBUS (ISO 11783) estende lo standard J1939 con messaggi standardizzati per il collegamento degli attrezzi e il controllo multimarca: ecco perché un display Trimble può comandare un attrezzo di un altro produttore tramite lo stesso bus CAN.

In pratica, gli standard J1939 e ISOBUS definiscono la struttura dei frame. L'integrazione di dispositivi specifici richiede la decodifica dei gruppi di parametri specifici del produttore (PGN) e dei numeri di parametri sospetti (SPN). Nei progetti di retrofit, è comune imbattersi in centraline di sterzo che utilizzano la struttura standard dei frame J1939 con assegnazioni PGN proprietarie, oppure in implementazioni ISOBUS che includono estensioni del fornitore oltre al set di messaggi standard.

Un gateway CAN bus con analisi dei frame configurabile gestisce tutto ciò senza dover riscrivere il codice dell’applicazione per ogni singolo dispositivo. L’integratore configura gli offset di campo, i tipi di dati e il ridimensionamento per ogni PGN a livello di gateway. I frame in entrata vengono decodificati automaticamente. I comandi in uscita vengono assemblati a partire dai parametri configurati. Quando il dispositivo successivo utilizza una struttura di frame diversa, cambia la configurazione del gateway, ma non quella dell’applicazione di controllo.

Ciò assume rilevanza pratica quando un progetto di retrofit prevede l'utilizzo combinato di controllori dello sterzo, centraline motore e componenti di diversi produttori. Senza un'analisi configurabile dei frame a livello di gateway, ogni nuova combinazione di dispositivi richiede un intervento di integrazione personalizzato a livello di applicazione.

Come funziona il circuito di controllo locale del gateway CAN sul veicolo

Il valore fondamentale di un gateway CAN bus per i trattori autonomi sta nel fatto che il circuito di controllo dello sterzo non esce mai dal veicolo — e per capire perché questo sia importante è necessario tracciare con precisione il funzionamento del circuito stesso. 

Il gateway si collega direttamente al bus CAN del veicolo, al ricevitore RTK-GNSS tramite RS232 e ai sensori tramite RS485. La conversione dei protocolli avviene localmente — decodifica dei frame J1939, analisi delle frasi NMEA, lettura dei registri Modbus — e i dati normalizzati vengono inviati all’applicazione di controllo locale.

Quando il veicolo si discosta dal percorso previsto, la logica di controllo del gateway calcola la correzione e invia il comando di sterzata tramite CAN direttamente al controller dello sterzo. L’intero ciclo — dall’input del sensore al comando all’attuatore — rimane all’interno del veicolo. Nessuna rete esterna è coinvolta nel ciclo.

La connettività di rete gestisce la registrazione dei dati sulla piattaforma cloud e il monitoraggio remoto della flotta. Non svolge alcun ruolo nel controllo dello sterzo in tempo reale. Nelle implementazioni sul campo in cui la connessione 4G si interrompe durante il funzionamento, il ciclo di controllo dello sterzo prosegue senza interruzioni. I dati vengono memorizzati temporaneamente in locale e sincronizzati quando la connettività viene ripristinata.

Specifiche dell'EG8200 per l'implementazione di un gateway CAN bus su trattori autonomiGateway industriale per l'edge EG8200

I IOTRouter EG8200 è progettato come gateway CAN per applicazioni su trattori autonomi e veicoli agricoli — l'unico modello della serie EG con supporto nativo dell'interfaccia CAN. 

Parametro Specifiche
Porte CAN 2× frame ID indipendenti, standard + estesi
Velocità di trasmissione CAN da 125 Kbps a 1 Mbps, configurabile in modo indipendente per ciascuna porta
Supporto dei protocolli J1939, ISOBUS (ISO 11783), analisi dei frame configurabile a livello di PGN
RS232 1× — Ricevitore RTK-GNSS
RS485 2× — IMU, sensori del suolo, dispositivi Modbus
I/O digitale 2× DI, 2× DO
Processore Cortex-A7 dual-core, 1,2 GHz
Memoria 512 MB di RAM, 4 GB di spazio di archiviazione
GNSS integrato Modalità doppia BeiDou/GPS, WGS84
Cellulare 4G LTE, supporto tri-carrier
WiFi Wi-Fi 6 dual-band, 2,4 GHz + 5 GHz simultanei
Potenza assorbita Ampio intervallo di tensione: 9–36 V CC, 280 mA a 12 V
Temperatura di esercizio da -40 °C a +85 °C
Involucro Acciaio zincato, raffreddamento passivo senza ventola
EMC Livello 3 di protezione ESD contro le scariche d'aria, livello 2 contro le sovratensioni, livello 2 contro i picchi di tensione

 

Due porte CAN indipendenti consente la connessione simultanea a reti bus distinte — la rete J1939 del gruppo motopropulsore a 500 Kbps e la rete ISOBUS a 250 Kbps — su un unico dispositivo, senza bisogno di un convertitore separato.

Raffreddamento passivo senza ventola elimina l'accumulo di polvere negli ambienti di lavoro agricoli. Con un intervallo di funzionamento compreso tra -40 °C e +85 °C, il dispositivo copre le condizioni termiche tipiche della cabina, con un margine di sicurezza al di sopra del limite massimo di 65 °C rilevato nelle misurazioni sul campo.

BeiDou/GPS integrato fornisce al gateway una posizione indipendente, distinta da quella del ricevitore RTK — utile per il monitoraggio della flotta e per correlare i dati operativi con la posizione sul campo quando il flusso di dati RTK non è disponibile.

Installazione: ciò che conta di più, secondo l’esperienza sul campo

L'installazione di un gateway CAN bus su un trattore autonomo comporta una serie limitata di scelte relative all'installazione che hanno un impatto enorme sull'affidabilità a lungo termine — la maggior parte delle quali non è riportata nella documentazione del prodotto. 

Terminazione del bus CAN — verificare prima del collegamento

Le reti CAN dei veicoli sono progettate con resistenze di terminazione da 120 Ω a ciascuna estremità fisica del bus. Il collegamento del gateway in un punto intermedio del bus senza tenere conto della terminazione esistente crea un’impedenza del bus errata e riflessioni del segnale. Nelle installazioni sul campo, ciò si manifesta con errori intermittenti di comunicazione CAN correlati alla temperatura e alle vibrazioni — facilmente scambiabili per un guasto hardware. Prima del collegamento, verificare che il bus disponga della corretta terminazione su entrambe le estremità. Non aggiungere un terzo punto di terminazione.

Posto di montaggio — la temperatura della superficie non corrisponde a quella ambiente

L'EG8200 è progettato per funzionare fino a +85 °C. Le temperature all'interno della cabina durante le operazioni estive sul campo si aggirano in genere tra i 50 e i 65 °C. Un dispositivo montato in un punto in cui la luce solare diretta colpisce l’involucro può raggiungere temperature superiori di 15–20 °C rispetto a quelle ambientali — sufficienti a far superare il limite. Montarlo in una posizione ombreggiata all’interno della cabina o in un involucro sigillato al riparo dall’esposizione solare.

Node-RED per la messa in servizio sul campo

Il gateway utilizza Node-RED per la logica applicativa di controllo locale. Il filtraggio degli ID CAN, la configurazione della velocità di trasmissione, i parametri RS232, la logica di elaborazione dei sensori e le condizioni di uscita DO vengono configurati tramite l'interfaccia visiva senza ricorrere a codice a livello di dispositivo. Nei progetti di retrofit in cui è necessario regolare i parametri durante la messa in servizio, le modifiche vengono apportate tramite l'interfaccia senza dover accedere fisicamente al dispositivo ogni volta.

Implementazione di una flotta composta da più veicoli

Un EG8200 per veicolo come nodo periferico indipendente. Gli aggiornamenti remoti del firmware tramite 4G consentono di effettuare la manutenzione ordinaria senza necessità di interventi in loco. La modalità AP supporta fino a 20 connessioni simultanee di client Wi-Fi per scenari di rete locale sul campo.

Domande frequenti sull'integrazione del gateway CAN bus nei progetti relativi ai trattori autonomi

Queste domande ricorrono spesso nelle implementazioni di gateway CAN bus per trattori autonomi, in particolare nei progetti di retrofit multimarca in cui dispositivi J1939 e ISOBUS di diversi produttori devono coesistere sulla stessa rete del veicolo. 

Le due porte CAN possono funzionare contemporaneamente a velocità di trasmissione diverse?

Sì. Ogni porta è configurabile in modo indipendente con velocità comprese tra 125 Kbps e 1 Mbps. Nelle implementazioni in cui il protocollo J1939 del gruppo motopropulsore funziona a 500 Kbps e le applicazioni ISOBUS a 250 Kbps, entrambe si collegano a un unico EG8200 senza bisogno di un convertitore separato.

In che modo il gateway gestisce i frame CAN proprietari di determinati produttori?

Il nodo CAN avanzato opera a livello di frame ed è indipendente dal protocollo. Gli offset di campo, i tipi di dati e i fattori di scala vengono configurati per ciascun ID CAN. I PGN standard J1939 e le estensioni proprietarie utilizzano lo stesso meccanismo. Quando un nuovo dispositivo presenta una struttura di frame diversa, cambia la configurazione del gateway, ma non quella dell’applicazione di controllo.

La perdita del segnale 4G influisce sul circuito di controllo dello sterzo?

No. Il ciclo di controllo dello sterzo viene eseguito localmente sul gateway. La rete 4G trasmette i dati operativi alla piattaforma cloud; non fa parte del percorso di controllo in tempo reale. Nelle installazioni sul campo in cui il segnale viene interrotto durante il funzionamento, il controllo locale prosegue normalmente e i dati memorizzati nel buffer vengono sincronizzati al ripristino della connettività.

In quali casi è più opportuno utilizzare un IPC piuttosto che un gateway CAN per i trattori autonomi?

Quando l’applicazione richiede visione artificiale, uno stack di navigazione ROS completo o carichi di lavoro di fusione dei sensori che superano la capacità di un processore dual-core da 1,2 GHz, un IPC è la scelta hardware più indicata. Per la guida autonoma basata su RTK-GNSS con sterzo tramite bus CAN e controllo degli attrezzi tramite ISOBUS, la potenza di elaborazione dell’EG8200 è in grado di gestire il carico di lavoro, mentre il design senza ventola, l’alimentazione a tensione estesa e le porte CAN native riducono il lavoro di integrazione rispetto a un IPC con adattatori aggiuntivi.

Per quali applicazioni dei trattori autonomi questo gateway non è adatto?

Il rilevamento degli ostacoli basato sulla visione, l’elaborazione delle nuvole di punti LiDAR e le applicazioni che eseguono stack di navigazione completamente autonomi superano il limite di potenza di calcolo dell’EG8200. Per tali carichi di lavoro, l’hardware più adatto è un IPC o una piattaforma di calcolo appositamente progettata per i veicoli autonomi. L’EG8200 gestisce il gateway del bus CAN e il livello di controllo locale, ma non il livello di percezione.

Chi sono
db6893fd1d3e314ac461fa240068dc06?s=150&d=mp&r=g
Specialista in soluzioni IoT ~ Web ~  Altri articoli

Agnes Wang è una specialista in soluzioni IoT presso IOTRouter, dove si occupa principalmente di gateway IoT industriali, edge computing e soluzioni di automazione industriale.

È specializzata in tecnologie di comunicazione industriale, tra cui Modbus, IEC 60870-5-104, MQTT, OPC UA, integrazione di PLC e applicazioni di monitoraggio remoto. Collabora alla stesura di articoli tecnici e guide applicative riguardanti soluzioni IoT industriali, conversione di protocolli ed edge computing.

↑