I registratori CAN memorizzano i messaggi con timestamp. Questa guida illustra il CAN classico e il CAN FD, la decodifica del segnale e il percorso dati per la diagnostica remota, con particolare attenzione ai registratori CANedge adatti per schede SD, WLAN e LTE.
In sintesi
- Un registro CAN contiene messaggi e timestamp; i valori misurati comprensibili si ottengono solo tramite un'opportuna decodifica.
- CAN FD offre fino a 64 byte di dati utente e, opzionalmente, una fase dati più veloce.
- I modelli CANedge supportano CAN classico e CAN FD; il percorso dati varia a seconda del protocollo: scheda SD, WLAN o LTE.
Cosa registra effettivamente un registratore CAN
Un registratore CAN memorizza i messaggi provenienti dal bus di un veicolo o di una macchina: nello specifico, l'identificativo (CAN ID), i dati utente e i timestamp. Ciò consente di tracciare quali dati erano presenti sul bus connesso in un dato momento. Tuttavia, il file non fornisce automaticamente testo in chiaro come la velocità del motore, la temperatura o lo stato della batteria. Per questo, è necessario conoscere il significato e la codifica dei segnali.
Una misurazione inizia quindi con una domanda specifica: l'obiettivo è isolare un errore sporadico, confrontare uno stato operativo o documentare un test sul campo di lunga durata? L'accesso al bus, la durata della registrazione e la selezione dei messaggi rilevanti sono determinati da questa domanda. Per le analisi successive, i dati grezzi, la configurazione della misurazione e la descrizione del segnale utilizzata devono rimanere tutti tracciabili.
CAN classico e CAN FD: differenze e compatibilità
Il livello di collegamento dati CAN, incluso CAN FD, è standardizzato nella norma ISO 11898-1. CAN FD aumenta la quantità di payload per frame da un massimo di 8 a 64 byte. BRS sta per "Bit Rate Switch": quando la commutazione è abilitata, la fase dati può utilizzare una velocità di trasmissione dati superiore rispetto alla fase di arbitraggio, in cui viene negoziato l'accesso al bus.
La velocità di trasmissione dati raggiungibile dipende da fattori quali i ricetrasmettitori, la topologia della linea e le condizioni operative. Pertanto, un limite superiore generale di 8 Mbit/s non rappresenta un limite CAN FD universalmente valido.
I controller CAN FD possono elaborare anche i frame CAN classici. I controller classici, d'altro canto, non comprendono i frame FD e possono reagire ad essi con frame di errore. Una rete mista richiede pertanto una strategia di comunicazione specifica e appropriata.
| caratteristica | CAN classico | CAN FD |
|---|---|---|
| Dati di utilizzo per fotogramma | Fino a 8 byte | Fino a 64 byte |
| Bitrate | Una velocità di trasmissione nominale, fino a 1 Mbit/s | Bitrate nominale; con bitrate dati separato BRS |
| Identificatore CAN | 11 o 29 bit | 11 o 29 bit |
| Controllore | Comprende i frame CAN classici | Supporta i frame CAN e FD classici. |
I dati grezzi si trasformano in segnali: DBC e altre descrizioni.
Un file DBC è un database CAN standard in formato testo. Descrive, ad esempio, quali bit di un messaggio appartengono a un segnale, l'ordine dei byte e come devono essere applicati scalatura, offset e unità di misura. Solo con queste informazioni un valore grezzo diventa una misurazione interpretabile.
Il DBC è un formato di scambio pratico per questo scopo, ma non un requisito obbligatorio: le stesse regole possono anche derivare da un'altra specifica di segnale documentata ed essere implementate in un software appropriato. Il punto cruciale è che la descrizione corrisponda al veicolo specifico, alla centralina e alla versione del software. Senza queste informazioni, nessun flusso di dati CAN può essere decodificato in modo affidabile basandosi esclusivamente sui suoi identificatori.
Registrazione locale con CANedge1
Il CANedge1 di CSS Electronics supporta sia il CAN classico che il CAN FD. Memorizza i dati su una scheda SD in formato MDF4 (.MF4). Ciò lo rende adatto per misurazioni in cui i dati vengono successivamente estratti in loco, sia sul banco prova che durante i test sui veicoli.
Il processo di selezione non riguarda quindi tanto la natura "fissa o mobile" del dispositivo, quanto piuttosto la necessità di un trasferimento remoto automatico. Prima di un utilizzo prolungato, si consiglia di effettuare una breve registrazione di prova: i parametri del bus e i timestamp sono corretti? Sono inclusi i messaggi richiesti? Il software di analisi previsto è in grado di elaborare il file?
Diagnostica remota: dal veicolo tramite WLAN alla valutazione
L'analisi remota richiede non solo l'accesso CAN, ma anche un percorso dati verso il luogo di analisi. CAN FD non fornisce né una connessione Internet né un proprio servizio di diagnostica. Anche UDS è un livello di protocollo separato: la registrazione passiva dei messaggi esistenti è diversa dall'interrogare attivamente una centralina con servizi di diagnostica.
Il CANedge2 integra la registrazione locale con la connettività Wi-Fi. Può trasferire automaticamente i file di log completati a un server compatibile con S3 configurato, ad esempio, non appena il veicolo si connette a una rete Wi-Fi disponibile. Si tratta di un trasferimento dati basato su file e non di un flusso automatico continuo in tempo reale. L'accesso Wi-Fi, l'accesso al server e la successiva elaborazione devono essere configurati e testati con un file di prova reale.
Raccolta dati mobile con LTE e CANedge3
Se è necessario trasferire dati al di fuori di una rete Wi-Fi disponibile, CANedge3 offre una connessione dati mobile. La versione qui indicata combina LTE con GNSS e IMU. Ciò consente di analizzare i dati registrati dal bus insieme alle informazioni su posizione e movimento. Per il funzionamento in modalità mobile sono necessarie una scheda SIM compatibile e una copertura di rete adeguata.
La soluzione più adatta dipende dalla procedura di misurazione: scheda SD per l'estrazione successiva dei dati, Wi-Fi per la trasmissione tramite punti di accesso noti o LTE per la trasmissione dati mobile. Tuttavia, l'accesso remoto ai file di registro non sostituisce una diagnosi professionale. Risultati significativi richiedono segnali appropriati, una decodifica corretta e un periodo di osservazione adeguato alla specifica questione da affrontare.
Domande frequenti
Un controller CAN classico può ricevere messaggi CAN FD?
No. I controller CAN FD supportano anche il CAN classico; viceversa, i controller classici non comprendono i frame FD e possono generare frame di errore. La condivisione di un bus deve essere pianificata di conseguenza.
Ho assolutamente bisogno di un file DBC per l'analisi CAN?
No. Sono necessarie regole di decodifica del segnale corrette. Il formato DBC è comune a questo scopo; anche un'altra specifica di segnale documentata può servire da base.
CAN FD è già una soluzione per la diagnostica remota?
No. Sono necessari anche l'acquisizione dei dati, un percorso di trasmissione e la valutazione. I servizi di diagnostica attiva come l'UDS sono separati da questi e richiedono il supporto appropriato da parte della centralina e dello strumento di diagnostica.
Fonti e ulteriori informazioni
- CiA: CAN FD – l'idea di base
- CiA: Generazioni del livello di collegamento dati CAN
- CSS Electronics: CAN FD spiegato – velocità di trasmissione e compatibilità
- CSS Electronics: file DBC e decodifica del segnale
- CSS Electronics: Confronto hardware CAN
- CSS Electronics: CANedge1 – Registratore di dati CAN con scheda SD
- CSS Electronics: CANedge2 – Registratore di dati CAN con WLAN
- CSS Electronics: CANedge3 – LTE e GPS/IMU
- CSS Electronics: CANedge2 – Trasmissione dati
- CSS Electronics: servizi di diagnostica UDS
