Un computer di bordo CAN Bus non si limita a esporre una coppia di terminali CAN. Deve ricevere i messaggi corretti al momento giusto, trasmettere i dati selezionati a un'applicazione, coesistere con dispositivi seriali e collegamenti wireless e rimanere affidabile in tutte le condizioni elettriche e ambientali del veicolo.
Per i produttori di apparecchiature originali (OEM), la parte più difficile inizia dopo la scelta delle dimensioni del display. I team di integrazione devono concordare sull'architettura del bus, le definizioni dei messaggi, l'interfaccia con il sistema operativo, il comportamento dei servizi e i test di accettazione. Questa guida fornisce una checklist pratica per trasformare un terminale CAN Bus in un sottosistema di produzione ripetibile.
Illustrazione dell'integrazione del PDS. Cablaggio, protocolli e comportamento del software devono essere convalidati sul veicolo di destinazione.
Definire l'architettura del computer di bordo del bus CAN prima di scegliere l'hardware.
Una rete CAN è un bus differenziale condiviso. Diverse centraline elettroniche si scambiano frame e ogni nodo ricevente decide se un frame è rilevante. Il livello fisico, la velocità di trasmissione, la terminazione, la politica dei connettori e il protocollo dei messaggi devono corrispondere alla progettazione del veicolo. CSS Electronics fornisce un'utile introduzione al bus CAN per i team che necessitano di un vocabolario condiviso.
La prima decisione che il produttore di apparecchiature originali (OEM) deve prendere riguarda le funzioni consentite al computer di bordo del veicolo che utilizza il bus CAN. Può limitarsi a monitorare i dati, richiedere un insieme limitato di azioni, fungere da gateway o partecipare a una rete privata. Tale ruolo deve essere specificato nel documento di controllo dell'interfaccia. Un terminale di monitoraggio e un controller con capacità di comando richiedono test e misure di sicurezza informatica differenti.
Identificare inoltre ogni bus collegato al terminale. Nei veicoli commerciali, le reti CAN dedicate a propulsione, carrozzeria, attrezzature, diagnostica e reti private sono spesso separate. La loro combinazione senza un'adeguata strategia di isolamento o gateway può generare traffico indesiderato, comportamenti anomali o propagazione di guasti.
| Livello di integrazione | Decisione di progettazione | È richiesta la prova |
|---|---|---|
| Fisico | Velocità di trasmissione, topologia, terminazione, cavo, connettore e isolamento | Schema del cablaggio, acquisizione con oscilloscopio o analizzatore e piano EMC |
| Protocollo | CAN grezzo, J1939, CANopen, ISO-TP, UDS o formato proprietario | Database dei messaggi, identificatori, diagrammi di temporizzazione e di stato |
| Sistema operativo | Driver, API, autorizzazioni, priorità del processo e ripristino | Documentazione SDK, codice di esempio e risultati dell'iniezione di errori |
| Applicazione | Decodifica, filtraggio, registrazione, visualizzazione e logica aziendale | Casi di test end-to-end con dati del veicolo registrati |
| Ciclo vitale | Controllo delle versioni, aggiornamenti, diagnostica e assistenza sul campo. | Configurazione di base, processo di rilascio e procedura di ripristino |
Completare la checklist del computer di bordo del veicolo CAN Bus RS232 RS485
I progetti OEM spesso combinano CAN con apparecchiature seriali preesistenti. Una checklist per computer di bordo CAN Bus RS232 RS485 dovrebbe documentare ciascuna interfaccia separatamente e quindi testare l'intero percorso dati.
Autobus CAN
Confermare il numero di canali indipendenti, il supporto CAN FD, le velocità di trasmissione, il metodo di terminazione, l'isolamento, il comportamento di riattivazione e la piedinatura del connettore. Verificare se il terminale deve ricevere solo frame specifici o anche trasmettere messaggi. Acquisire il carico del bus e la latenza nel caso peggiore con il cablaggio completo del veicolo.
RS232 e RS485
Per un computer di bordo con RS232, specificare i livelli di tensione, la velocità di trasmissione (baud rate), il controllo di flusso, il connettore, la lunghezza del cavo e il protocollo. L'RS232 è generalmente punto-punto. L'RS485 può utilizzare la modalità half-duplex o full-duplex con più nodi, pertanto è necessario definire i requisiti di terminazione e polarizzazione. Non dare per scontato che impostazioni di baud rate identiche garantiscano la compatibilità del protocollo.
Richiedi un test di loopback o a livello di dispositivo prima dell'installazione sul veicolo. Quindi testa il traffico simultaneo su CAN, entrambi i canali seriali, USB e la connessione wireless. Il carico condiviso del processore e la gestione degli interrupt possono rivelare problemi che non emergono nelle dimostrazioni a singola interfaccia.
Illustrazione dell'integrazione OEM di PDS. Il comportamento dell'interfaccia deve essere verificato con la configurazione del prodotto indicata nel preventivo.
Controllo del database dei messaggi e del modello dati
L'applicazione non deve decodificare frame esadecimali grezzi in tutto il codice sorgente. Definire un database dei messaggi (DBC), mappare valori fisici e unità e generare un livello di decodifica testato. Includere frequenze di aggiornamento, comportamento in caso di timeout, gestione dei valori non validi, ordine dei byte, scalatura e intervalli dei segnali.
Gestisci le versioni del database insieme al software del veicolo, non solo con l'applicazione del terminale. Se una centralina aggiunge un messaggio o modifica un segnale, il team di integrazione deve sapere quali terminali, modelli cloud e casi di test sono interessati. Archivia i log CAN rappresentativi in modo che le modifiche di decodifica possano essere riprodotte anche senza un veicolo.
Se il progetto utilizza lo standard SAE J1939 , documentare gli indirizzi sorgente, i gruppi di parametri, il comportamento delle richieste e la gestione diagnostica. Per CANopen o un protocollo proprietario, fornire le macchine a stati equivalenti e le definizioni degli errori.
Selezionare il sistema operativo e l'API CAN
Un computer di bordo CAN Bus con sistema operativo Linux può esporre le proprie interfacce tramite il sottosistema SocketCAN del kernel. Il team di sviluppo software può utilizzare operazioni socket standard, filtri e strumenti di rete. È importante verificare la versione del kernel, il driver CAN, la configurazione del buffer di ricezione e le autorizzazioni nell'immagine di sistema distribuita, anziché solo su una scheda di sviluppo.
Su Android, il fornitore può offrire un'API Java, Kotlin, nativa o JNI. È importante chiedere come le applicazioni ricevono i frame, come viene controllato l'accesso in trasmissione e cosa succede quando il servizio viene riavviato. Il piano di integrazione dovrebbe includere un watchdog o un controllo di integrità in grado di ripristinare il funzionamento in caso di arresto di un processo, di disconnessione dell'interfaccia o di stato del bus inattivo.
I progetti OpenHarmony dovrebbero ricevere una definizione di interfaccia altrettanto specifica. Evitate di accettare un'affermazione generica sul supporto di CAN. L'OEM necessita dell'effettiva superficie API, di un progetto di esempio, delle autorizzazioni, del comportamento durante il ciclo di vita e della possibilità di eseguire il debug.
Aggiungere GNSS e 4G LTE senza indebolire l'interfaccia del veicolo.
Un terminale GNSS per veicoli con bus CAN può combinare dati di posizione, movimento e stato del veicolo. Definisci la precisione richiesta, la frequenza di aggiornamento, il formato delle coordinate, la sorgente oraria e il servizio di correzione. Verifica il posizionamento dell'antenna con il tetto, la cabina, il vano di carico e le apparecchiature radio nelle vicinanze. Mantieni la perdita del segnale GNSS e il timeout CAN come stati indipendenti, in modo che una sorgente non disponibile non invalidi l'altra.
Un computer di bordo 4G LTE estende questi flussi di dati a una piattaforma di flotta, ma il collegamento in uplink non deve essere considerato sempre disponibile. Specificare le bande supportate, i profili degli operatori, il comportamento in roaming, l'isolamento dell'antenna, i limiti di dati e il tempo di riconnessione. Utilizzare il buffering locale per i record importanti e definire quali campi vengono inviati immediatamente, periodicamente o solo dopo un evento.
Definire la proprietà e l'accesso ai dati. I proprietari dei veicoli potrebbero richiedere il controllo su dati relativi a posizione, diagnostica, conducente e funzionamento. Il terminale e la piattaforma cloud necessitano di politiche chiare in materia di autenticazione, autorizzazione, conservazione dei dati e comandi remoti.
Proteggere l'alimentazione, i segnali e il confine del software
L'alimentazione del veicolo comprende l'avviamento a freddo, la gestione del carico, l'avviamento di emergenza e la commutazione degli accessori. Il computer di bordo del veicolo con bus CAN deve essere specificato con un intervallo di ingresso, uno standard transitorio, un fusibile, una messa a terra e un comportamento di accensione per la classe di veicolo effettiva. Le porte CAN e seriali possono anche richiedere isolamento galvanico o protezione quando si collegano ad apparecchiature esterne.
Trattare CAN come interfaccia attendibile solo dopo che l'OEM ne ha definito l'attendibilità. Limitare gli identificatori di trasmissione, convalidare lunghezze e intervalli ricevuti, limitare la velocità dei comandi e impedire a un'applicazione di accedere a canali bus non correlati. Registrare le modifiche di configurazione rilevanti per la sicurezza e supportare aggiornamenti software firmati o verificati.
Il cablaggio deve essere di facile manutenzione. Etichettare i connettori, documentare la piedinatura, proteggere le porte non utilizzate e specificare la coppia di serraggio ove necessario. Un terminale che supera il test di laboratorio può comunque guastarsi se un cablaggio pesante tira un connettore o crea un moncone che disturba il bus.
Utilizzare una matrice di accettazione per il rilascio in produzione
| Area di prova | Esempio di criterio di accettazione |
|---|---|
| Salute degli autobus | Nessun frame di errore involontario durante le sequenze di funzionamento normale, avvio, riattivazione e spegnimento. |
| Analisi dei dati | I segnali decodificati corrispondono alle misurazioni di riferimento nell'intero intervallo operativo. |
| Latenza | I dati critici raggiungono l'applicazione entro i tempi previsti dal progetto. |
| Recupero | I servizi CAN, seriali, GNSS e cellulari si ripristinano dopo guasti ai cavi, all'alimentazione e alla rete. |
| Cicli di potenza | I dati di configurazione e quelli memorizzati nella cache sopravvivono agli scenari di accensione e batteria richiesti. |
| Aggiornamento e ripristino | Un aggiornamento non riuscito può riportare l'unità a una versione funzionante nota. |
Prima della produzione, un computer di bordo CAN Bus deve superare una matrice approvata di test relativi al bus, alla latenza, al ripristino e all'aggiornamento. PDS fornisce supporto per l'integrazione OEM/ODM di terminali per veicoli robusti e può allineare le interfacce al piano software del progetto. L'OEM deve comunque detenere la specifica dell'interfaccia a livello di veicolo e approvare il piano di validazione finale.
Illustrazione della convalida PDS. I criteri di accettazione e le apparecchiature di prova devono essere concordati prima del rilascio in produzione.
FAQ
Di cosa ha bisogno un computer di bordo di un veicolo con sistema CAN Bus per ricevere i dati del veicolo?
Necessita di un'interfaccia CAN fisica compatibile, della corretta velocità di trasmissione e terminazione, dell'accesso al bus pertinente, di un database dei messaggi e di un software in grado di decodificare i segnali richiesti. Il terminale deve inoltre gestire i timeout, i valori non validi e i guasti del bus.
È possibile che un computer di bordo utilizzi contemporaneamente i protocolli CAN, RS232 e RS485?
Molti computer di bordo per veicoli robusti possono supportare queste interfacce contemporaneamente, ma il numero esatto di canali e il loro isolamento dipendono dal modello. Testate tutto il traffico richiesto contemporaneamente e verificate che il sistema operativo esponga ciascuna interfaccia in modo affidabile.
Il protocollo J1939 è equivalente al CAN Bus?
J1939 è un protocollo di livello superiore utilizzato nelle reti CAN, principalmente nei veicoli pesanti. Un terminale può supportare fisicamente il CAN senza necessariamente supportare i messaggi J1939 specifici o il comportamento diagnostico richiesto dal progetto.
I dati CAN devono essere elaborati sul terminale o nel cloud?
Utilizza il terminale per il filtraggio, la visualizzazione, gli avvisi e il buffering sensibili al tempo. Invia i record riepilogativi o basati su eventi al cloud quando la disponibilità della rete e le policy sui dati lo consentono. La suddivisione deve rispettare i requisiti di latenza, privacy, costi e funzionamento offline.
Contattaci
📧Email:[email protected]
📞Tel:+86 13421822024
🌐Sito web: www.szpds.com
Disclaimer
Le informazioni contenute in questo articolo sono fornite a solo scopo di riferimento. PDS Technology Co., Ltd. declina ogni responsabilità per eventuali errori, omissioni o per l'inadeguatezza del contenuto ad applicazioni specifiche. Le specifiche del prodotto sono soggette a modifiche senza preavviso. Gli acquirenti sono tenuti a verificare tutti i dettagli tecnici con il nostro team prima dell'utilizzo.
Informazioni su PDS Technology
PDS Technology è un'azienda leader nella produzione OEM/ODM di terminali GNSS RTK ad alta precisione e computer di bordo, al servizio dei settori agricolo, edile, minerario, dei taxi e della logistica dal 2011.
Con oltre 15 anni di esperienza in ricerca e sviluppo nel settore automobilistico, offriamo dispositivi robusti e multi-OS (Android/Linux/OpenHarmony) dotati di posizionamento RTK con precisione centimetrica, protezione IP66 e funzionalità predisposte per l'intelligenza artificiale. I nostri stabilimenti certificati IATF16949 hanno prodotto oltre 100.000 unità distribuite a livello globale, detenendo oltre il 30% del mercato cinese dei terminali di guida automatica per macchine agricole. Esportiamo in Giappone, Stati Uniti, Regno Unito, Turchia, Russia e altri paesi.
