Linux viene spesso scelto per i computer di bordo dei veicoli quando il terminale fa parte di una macchina dedicata piuttosto che di una piattaforma generica per app mobili. Il team di sviluppo software potrebbe necessitare di una sequenza di avvio controllata, un'interfaccia QT personalizzata, accesso diretto a dispositivi CAN o seriali, servizi in background, registrazione locale dei log e un'immagine di sistema che può essere modificata solo tramite un processo di progettazione approvato.
Un computer di bordo Linux può ospitare interfacce uomo-macchina (HMI) integrate, sistemi di controllo e guida per macchinari, raccolta dati industriali e progetti OEM a lungo termine. Linux da solo non garantisce un comportamento in tempo reale preciso né la certificazione di sicurezza. Le tempistiche dipendono dal kernel, dai driver, dall'architettura dell'applicazione, dal carico di lavoro e dalla validazione. Gli acquirenti dovrebbero definire il tempo di risposta richiesto e testarlo sull'hardware finale.
Perché i team embedded scelgono Linux nei veicoli
Con Linux, il team embedded può mantenere il terminale concentrato su un'unica attività. Gli ingegneri possono disattivare i servizi non utilizzati, avviare l'HMI direttamente dopo l'avvio, posizionare i log in un punto accessibile ai tecnici e decidere come ripristinare lo storage dopo un'interruzione di corrente. Questo livello di controllo è prezioso, ma crea anche un carico di lavoro che deve avere un responsabile specifico.
QT viene comunemente utilizzato per un'interfaccia grafica dedicata. Un'applicazione QT può visualizzare lo stato della macchina, linee guida, allarmi, telecamere o comandi operatore senza mostrare un ambiente desktop. L'interfaccia può avviarsi automaticamente all'avvio e limitare l'accesso alle impostazioni di progettazione.
Un altro motivo è il controllo a lungo termine. Un progetto che si protrae per diversi anni potrebbe preferire un'immagine stabile, dipendenze documentate e rilasci di manutenzione programmati, piuttosto che frequenti modifiche alla piattaforma in stile consumer. Questo vantaggio si manifesta solo quando cliente e fornitore concordano sulla proprietà del codice sorgente, sugli strumenti di compilazione, sulle librerie, sulla politica di aggiornamento e sulla responsabilità dell'assistenza.
Linux non è automaticamente in tempo reale
Il termine "tempo reale" necessita di un valore numerico. Affermare che una schermata sembra veloce non equivale a dimostrare che un evento viene gestito entro 20 ms, 50 ms o un altro limite prestabilito. È necessario annotare l'evento, la sua scadenza, il carico presente durante il test e la risposta del sistema in caso di mancato rispetto della scadenza.
A seconda della risposta, il progetto potrebbe utilizzare un kernel in tempo reale, una pianificazione delle priorità, core del processore isolati, un microcontrollore o un controller di sicurezza separato. In molti veicoli il terminale Linux gestisce solo l'interfaccia uomo-macchina (HMI) e registra i dati, mentre una centralina elettronica (ECU) dedicata continua a gestire il ciclo di controllo. Si tratta di due progetti molto diversi.
Prima di chiamare un sistema in tempo reale, eseguire dei test di temporizzazione con le telecamere attive, il traffico CAN alla velocità target, la registrazione abilitata, la comunicazione di rete in esecuzione e l'interfaccia grafica sotto carico. Il test dovrebbe includere la temperatura, i ripetuti avvii, l'utilizzo della memoria e le periferiche previste.
Applicazioni tipiche di Linux per computer di bordo.
Interfaccia uomo-macchina dedicata
Una macchina edile, agricola o mineraria potrebbe necessitare di una schermata approvata per visualizzare modalità operative, allarmi, dati dei sensori, visualizzazioni della telecamera e informazioni di servizio. Linux e QT consentono al team di sviluppo software di creare un'interfaccia controllata senza esporre funzionalità non necessarie destinate all'utente finale.
Gateway dati CAN e seriale
In qualità di gateway, il terminale può ascoltare CAN, leggere uno strumento RS232 o RS485, ricevere dati GNSS, tenere un registro eventi e inviare record selezionati tramite Ethernet o 4G. Contare le porte non è sufficiente. La scheda tecnica dovrebbe anche riportare il bitrate, l'isolamento elettrico, la terminazione, la piedinatura, chi è il proprietario di ciascun messaggio e se la build di Linux espone il driver necessario.
Terminale di guida e posizionamento
Linux può supportare un'interfaccia di guida dedicata che combina il posizionamento GNSS o, in alternativa, RTK con i dati della macchina. La soluzione completa richiede comunque il posizionamento delle antenne, i dati di correzione, la gestione delle coordinate, lo stato del posizionamento, la comunicazione con il controllore e una risposta definita in caso di perdita delle correzioni.
Elaborazione locale dei bordi
Alcuni progetti elaborano localmente i dati provenienti da telecamere o sensori prima di inviare il risultato al cloud. Il processore, la memoria, lo spazio di archiviazione, la GPU e l'acceleratore necessari dipendono dall'algoritmo. È consigliabile eseguire il carico di lavoro effettivo sull'hardware di destinazione anziché stimare le prestazioni basandosi sul nome del processore.
Punti di partenza hardware per PDS Linux
Attualmente PDS offre opzioni Linux per i modelli T7 e T12. È quindi possibile scegliere un computer di bordo Linux, compatto o con schermo grande, in base alla configurazione dell'abitacolo e al carico di lavoro dell'applicazione.
| Punto di selezione | PDS T7 | PDS T12 |
|---|---|---|
| Display | 7 pollici, 1024 x 600, almeno 750 cd/m2 | 12,1 pollici, 1280 x 800, almeno 750 cd/m2 |
| opzione Linux | Linux 4.9 + QT5 | Kernel Linux 5.15 + QT5.15 |
| Processore pubblicato | Processore quad-core Cortex-A53 fino a 1,5 GHz | Processore Cortex-A55 a 8 core con frequenza fino a 1,8 GHz |
| Memoria/archiviazione pubblicata | 2 GB / 16 GB | 4 GB / 64 GB, con possibilità di aggiungere fino a 256 GB di memoria. |
| Layout dell'operatore | Schermo compatto con quattro tasti funzione frontali | Ampio schermo tattile per HMI multipannello |
| Interfacce veicolo pubblicate | Connettore di estensione, telecamera, opzioni antenna GNSS/LTE | Due porte CAN, due RS232, RS485, Ethernet, GPIO e quattro porte per telecamera. |
| Potenza e protezione | 9-36 V CC, IP66 | 9-36 V CC, IP66 |
Per un'interfaccia compatta, il PDS T7 è il primo modello da esaminare. Le sue dimensioni ridotte e i quattro tasti frontali si adattano perfettamente agli schermi di taxi, autocarri leggeri e macchine agricole di piccole dimensioni. Il PDS T12 si colloca all'altro estremo della lista: offre più spazio per un'interfaccia HMI di grandi dimensioni e fornisce le connessioni necessarie per telecamere e dati provenienti da macchinari pesanti.
Annota chi fornisce e gestisce ogni livello software.
Un prototipo Linux può funzionare perfettamente e comunque bloccarsi prima della produzione perché nessuno ha stabilito chi detiene la proprietà dell'immagine software. Il fornitore del dispositivo potrebbe aspettarsi che sia il cliente a compilarlo; il cliente potrebbe aspettarsi un kernel, dei driver e un'immagine di ripristino aggiornati. È fondamentale mettere per iscritto questi limiti prima di ordinare le prime unità pilota.
- Versioni esatte del kernel Linux e di QT.
- Pacchetto di supporto per la scheda, toolchain, SDK e istruzioni di compilazione.
- Accesso ai driver per CAN, seriale, fotocamera, GNSS, 4G, Wi-Fi, Bluetooth, Ethernet, USB e memoria.
- Dipendenze del bootloader, della schermata iniziale, dell'avvio automatico delle applicazioni e dei servizi.
- Accesso root, permessi utente, policy Secure Shell e credenziali di produzione.
- Registrazione della posizione, rotazione dei log, registri degli arresti anomali e diagnostica remota.
- Metodo di aggiornamento dell'immagine, ripristino, supporti di ripristino e procedura di assistenza sul campo.
- Proprietà del codice sorgente e periodo di supporto per la configurazione selezionata.
Piano per l'interruzione dell'alimentazione del veicolo
Un file system Linux può danneggiarsi se l'alimentazione viene interrotta durante un'operazione di scrittura. Il terminale e l'applicazione necessitano di una strategia di spegnimento e ripristino compatibile con il comportamento di accensione del veicolo. È importante verificare come viene rilevato l'ACC, se è possibile ritardare lo spegnimento, quali dati devono essere cancellati e come si comporta il dispositivo in caso di ripetuti avviamenti brevi.
Testa la configurazione di archiviazione di produzione con la frequenza di registrazione effettiva. Un sistema che scrive file provenienti da telecamere, database e log di diagnostica richiede una strategia diversa rispetto a una semplice interfaccia HMI. Considera partizioni di sola lettura, file system con journaling, log limitati, checkpoint delle applicazioni e una modalità di ripristino in base al rischio del progetto.
Convalidare driver e interfacce come un unico sistema
Durante la fase pilota, collegare tutte le periferiche previste. Se entrambe le reti CAN funzioneranno contemporaneamente, testarle insieme. Per ogni dispositivo seriale, annotare se utilizza RS232 o RS485, quindi verificare la velocità di trasmissione, la piedinatura, la lunghezza del cavo e la terminazione. Le telecamere devono essere scollegate e ricollegate durante il test in modo che il team possa verificare il corretto funzionamento dell'ordine di avvio, del ritardo di anteprima, della risoluzione e della registrazione.
Per 4G e GNSS, verificare il posizionamento dell'antenna, le bande di mercato di destinazione, il comportamento della SIM, la sincronizzazione dell'ora, l'output di posizionamento e il ripristino dopo la perdita del segnale. Un driver che funziona correttamente durante un breve test al banco potrebbe mostrare un comportamento diverso dopo ripetuti cicli di accensione o un funzionamento prolungato.
La sicurezza e gli aggiornamenti richiedono un proprietario pratico
Rimuovi le password predefinite, limita i servizi, proteggi le chiavi di produzione e documenta l'accesso remoto. Decidi chi si occupa del monitoraggio delle vulnerabilità del software e chi approva gli aggiornamenti. Un'immagine stabile non deve essere abbandonata.
Utilizzate un'implementazione graduale. Aggiornate un piccolo gruppo di veicoli, monitorate l'avvio, l'applicazione, le interfacce, i dati e il feedback degli operatori, quindi estendete l'aggiornamento. Conservate un'immagine di ripristino e una procedura chiara per rimettere in servizio un veicolo in caso di errore durante l'aggiornamento.
Linux o Android: quale dovrebbe essere utilizzato dal progetto?
Scegli Linux quando il terminale è un sistema embedded dedicato gestito da un team specializzato, soprattutto se il progetto richiede un'interfaccia HMI QT personalizzata, servizi controllati, integrazione hardware diretta e un'immagine di prodotto stabile. Scegli Android quando il progetto è incentrato sul touch, orientato alle app e gestito da un team di sviluppo mobile.
Entrambi i sistemi operativi supportano applicazioni per veicoli. La scelta più sicura è quella della piattaforma che meglio si adatta al software esistente, alle competenze degli sviluppatori, alle periferiche, al processo di aggiornamento e al periodo di supporto. Non scegliete un sistema operativo solo perché è diffuso in un altro settore.
Domande frequenti
Linux è più adatto per il controllo dei veicoli in tempo reale?
Non automaticamente. Il sistema necessita di requisiti di temporizzazione definiti e di un'architettura collaudata. Il controllo critico può rimanere in una centralina elettronica (ECU) o in un microcontrollore dedicati, mentre Linux gestisce l'interfaccia uomo-macchina (HMI), la registrazione dei dati e la comunicazione.
Il PDS T12 è compatibile con Android e Linux?
La pagina T12 attuale elenca Android 13 e una configurazione opzionale con kernel Linux 5.15 + QT5.15. Prima dello sviluppo, verificare l'immagine di produzione esatta, i driver, le interfacce e i materiali di supporto.
Quale modello è migliore per un'interfaccia HMI Linux compatta?
Il T7 è il modello base, più compatto, e include tasti funzione fisici. Il T12 è più adatto a un'interfaccia multi-pannello di grandi dimensioni, a diverse visualizzazioni della telecamera e a una connettività più ampia con il veicolo.
Completa lo schema del sistema prima di scegliere lo schermo
Prima di scegliere un computer di bordo Linux , disegnate uno schema del sistema su una pagina. Indicate cosa viene eseguito sul terminale, cosa rimane nella centralina, ogni interfaccia connessa, il percorso di accensione e spegnimento, il gestore del software e la procedura di ripristino. Una volta completato questo schema, le dimensioni dello schermo e la configurazione hardware necessarie saranno generalmente molto più facili da definire.
Contatta PDS Technology fornendoci il layout HMI, i requisiti per Linux e QT, le aspettative di avvio, l'elenco delle interfacce, il numero di telecamere, le esigenze di posizionamento, le condizioni di alimentazione del veicolo, il mercato di destinazione e la quantità di produzione. Il nostro team può aiutarti a identificare una configurazione T7 o T12 pratica per la valutazione ingegneristica.
Contattaci
📧Email: market@szpds.com
📞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.
