Linux est souvent choisi pour l'ordinateur de bord lorsque le terminal fait partie d'une machine dédiée plutôt que d'une plateforme d'application mobile généraliste. L'équipe logicielle peut avoir besoin d'une séquence de démarrage contrôlée, d'une interface QT personnalisée, d'un accès direct aux périphériques CAN ou série, de services en arrière-plan, d'une journalisation locale et d'une image système qui ne peut être modifiée que selon un processus d'ingénierie approuvé.
Un ordinateur embarqué Linux peut s'intégrer aux interfaces homme-machine (IHM) embarquées, à la commande de machines, au guidage, à la collecte de données industrielles et aux projets OEM de longue durée. Linux seul ne garantit ni un fonctionnement en temps réel strict ni la certification de sécurité. Le temps de réponse dépend du noyau, des pilotes, de l'architecture applicative, de la charge de travail et de la validation. Il est recommandé aux acheteurs de définir le temps de réponse requis et de le tester sur le matériel final.
Pourquoi les équipes embarquées choisissent Linux dans les véhicules
Avec Linux, l'équipe en charge des systèmes embarqués peut concentrer le terminal sur une seule tâche. Les ingénieurs peuvent désactiver les services inutilisés, lancer l'interface homme-machine directement après le démarrage, placer les journaux à un endroit facilement accessible aux techniciens et définir la procédure de récupération du stockage après une coupure de courant. Ce niveau de contrôle est précieux, mais il engendre également des tâches qui doivent être attribuées à un responsable désigné.
QT est couramment utilisé pour les interfaces graphiques dédiées. Une application QT peut afficher l'état de la machine, des lignes de guidage, des alarmes, des images de caméras ou des commandes opérateur sans nécessiter d'environnement de bureau. L'interface peut démarrer automatiquement après le démarrage du système et restreindre l'accès aux paramètres techniques.
Le contrôle à long terme est une autre raison. Un projet s'étalant sur plusieurs années peut privilégier une image stable, des dépendances documentées et des mises à jour de maintenance planifiées plutôt que des changements de plateforme fréquents, comme c'est le cas pour les solutions grand public. Cet avantage n'apparaît que si le client et le fournisseur s'accordent sur la propriété du code source, les outils de compilation, les bibliothèques, la politique de mise à jour et les responsabilités en matière de support.
Linux n'est pas automatiquement en temps réel.
Le terme « temps réel » doit être quantifié. Affirmer qu'un écran est rapide ne signifie pas prouver qu'un événement est traité en 20 ms, 50 ms ou tout autre délai fixe. Notez l'événement, son échéance, la charge système pendant le test et la réponse du système en cas de dépassement de cette échéance.
Selon la réponse, la conception peut utiliser un noyau temps réel, une planification par priorité, des cœurs de processeur isolés, un microcontrôleur ou un contrôleur de sécurité séparé. Dans de nombreux véhicules, le terminal Linux gère uniquement l'interface homme-machine et enregistre les données, tandis qu'un calculateur dédié continue d'exécuter la boucle de contrôle. Ce sont deux conceptions très différentes.
Avant de soumettre un système à une utilisation en temps réel, effectuez des tests de synchronisation avec les caméras actives, le trafic CAN au débit cible, l'enregistrement des données activé, la communication réseau en cours et l'interface graphique soumise à une charge importante. Le test doit inclure la température, des redémarrages répétés, l'utilisation du stockage et les périphériques attendus.
Applications Linux typiques pour ordinateurs de bord de véhicules
Interface homme-machine dédiée
Une machine de construction, agricole ou minière peut nécessiter un écran unique et homologué affichant les modes de fonctionnement, les alarmes, les données des capteurs, les images des caméras et les informations de maintenance. Linux et Qt permettent à l'équipe logicielle de créer une interface contrôlée sans exposer de fonctionnalités grand public non pertinentes.
Passerelle de données CAN et série
En tant que passerelle, le terminal peut écouter le protocole CAN, lire un instrument RS232 ou RS485, recevoir des données GNSS, conserver un journal d'événements et envoyer des enregistrements sélectionnés via Ethernet ou 4G. Le simple comptage des ports ne suffit pas. La fiche technique doit également indiquer le débit binaire, l'isolation électrique, la terminaison, le brochage, le destinataire de chaque message et préciser si la distribution Linux inclut le pilote requis.
Terminal de guidage et de positionnement
Linux peut prendre en charge une interface de guidage dédiée qui combine le positionnement GNSS ou RTK (en option) avec les données machine. La solution complète nécessite néanmoins le positionnement de l'antenne, les données de correction, la gestion des coordonnées, l'état du positionnement, la communication avec le contrôleur et une réponse définie en cas de perte de corrections.
Traitement local en périphérie
Certains projets traitent localement les données de la caméra ou du capteur avant d'envoyer le résultat vers le cloud. Le processeur, la mémoire, le stockage, le GPU et l'accélérateur requis dépendent de l'algorithme. Il est préférable d'exécuter la charge de travail réelle sur le matériel cible plutôt que d'estimer les performances à partir du nom du processeur.
Points de départ matériels Linux PDS
PDS propose actuellement des options Linux pour les T7 et T12. Un ordinateur embarqué Linux compact ou à grand écran peut donc être sélectionné en fonction de l'aménagement de la cabine et de la charge de travail des applications.
| Point de sélection | PDS T7 | PDS T12 |
|---|---|---|
| Afficher | 7 pouces, 1024 x 600, au moins 750 cd/m² | 12,1 pouces, 1280 x 800, au moins 750 cd/m² |
| option Linux | Linux 4.9 + QT5 | Noyau Linux 5.15 + QT 5.15 |
| Processeur publié | Processeur quadricœur Cortex-A53 jusqu'à 1,5 GHz | Processeur à 8 cœurs Cortex-A55 jusqu'à 1,8 GHz |
| Mémoire/stockage publié | 2 Go / 16 Go | 4 Go / 64 Go, avec possibilité d'extension jusqu'à 256 Go. |
| Agencement de l'opérateur | Écran compact avec quatre touches de fonction frontales | Grand écran tactile pour interface homme-machine multi-panneaux |
| Interfaces de véhicules publiées | Connecteur d'extension, caméra, options d'antenne GNSS/LTE | Deux ports CAN, deux ports RS232, un port RS485, un port Ethernet, un port GPIO et quatre ports caméra. |
| Puissance et protection | 9-36 V CC, IP66 | 9-36 V CC, IP66 |
Pour une interface compacte, le PDS T7 est le premier modèle présenté. Son format réduit et ses quatre touches frontales s'intègrent parfaitement aux écrans discrets des taxis, des camionnettes et des petites machines agricoles. Le PDS T12, quant à lui, se situe en bout de liste : il offre plus d'espace aux grandes interfaces homme-machine et fournit les connexions nécessaires aux caméras et aux données des engins lourds.
Notez qui fournit et assure la maintenance de chaque couche logicielle.
Un prototype Linux peut fonctionner parfaitement et pourtant être bloqué avant la production, faute de consensus sur la propriété de l'image logicielle. Le fournisseur peut exiger du client qu'il la compile ; le client, quant à lui, peut exiger un noyau, des pilotes et une image de récupération maintenus. Il est essentiel de définir clairement ces limites par écrit avant de commander les premiers prototypes.
- Versions exactes du noyau Linux et de QT.
- Package de support de la carte, chaîne d'outils, SDK et instructions de compilation.
- Accès aux pilotes pour CAN, série, caméra, GNSS, 4G, Wi-Fi, Bluetooth, Ethernet, USB et stockage.
- Chargeur de démarrage, écran de démarrage, démarrage automatique des applications et dépendances de service.
- Accès root, permissions utilisateur, politique de sécurité shell et identifiants de production.
- Enregistrement de l'emplacement, rotation des journaux, rapports d'incidents et diagnostics à distance.
- Méthode de mise à jour d'image, restauration, supports de récupération et procédure de service sur site.
- Propriété du code source et période de support pour la configuration sélectionnée.
Plan en cas de coupure de courant du véhicule
Un système de fichiers Linux peut être endommagé en cas de coupure de courant pendant une écriture. Le terminal et l'application nécessitent une stratégie d'arrêt et de redémarrage adaptée au comportement du contacteur d'allumage du véhicule. Il convient de se renseigner sur la détection de l'ACC, la possibilité de différer l'arrêt, les données à effacer et le comportement du périphérique lors de démarrages courts et répétés.
Testez la configuration de stockage de production avec le débit d'enregistrement réel. Un système gérant l'écriture des fichiers de caméra, des bases de données et des journaux de diagnostic nécessite une stratégie différente de celle d'une simple interface homme-machine (IHM). Envisagez des partitions en lecture seule, des systèmes de fichiers journalisés, des journaux limités, des points de contrôle d'application et un mode de récupération adapté aux risques du projet.
Valider les pilotes et les interfaces comme un seul système
Connectez tous les périphériques prévus lors du test pilote. Si les deux réseaux CAN fonctionnent simultanément, testez-les ensemble. Pour chaque périphérique série, notez s'il utilise RS235 ou RS485, puis vérifiez le débit en bauds, le brochage, la longueur du câble et sa terminaison. Les caméras doivent être débranchées et rebranchées pendant le test afin que l'équipe puisse observer le rétablissement de l'ordre de démarrage, du délai de prévisualisation, de la résolution et de l'enregistrement.
Pour la 4G et le GNSS, vérifiez l'emplacement de l'antenne, les bandes de fréquences du marché cible, le comportement de la carte SIM, la synchronisation horaire, la précision du positionnement et la récupération après une perte de signal. Un pilote fonctionnant correctement lors d'un test rapide peut présenter un comportement différent après plusieurs cycles d'allumage ou une utilisation prolongée.
La sécurité et les mises à jour nécessitent un propriétaire pragmatique
Supprimez les mots de passe par défaut, limitez les services, protégez les clés de production et documentez les accès distants. Désignez les personnes chargées de surveiller les vulnérabilités logicielles et d'approuver les mises à jour. Une image stable ne doit pas devenir une image abandonnée.
Utilisez un déploiement progressif. Mettez à jour un petit groupe de véhicules, surveillez le démarrage, l'application, les interfaces, les données et les retours des opérateurs, puis étendez le déploiement. Conservez une image de récupération et une procédure claire pour remettre un véhicule en service en cas d'échec de la mise à jour.
Linux ou Android : lequel le projet doit-il utiliser ?
Optez pour Linux lorsque le terminal est un système embarqué dédié, maintenu par une équipe spécialisée, notamment si le projet nécessite une interface homme-machine QT personnalisée, des services contrôlés, une intégration matérielle directe et une image produit stable. Choisissez Android lorsque le projet est axé sur le tactile, orienté applications et maintenu par une équipe de développement mobile.
Les deux plateformes sont compatibles avec les applications embarquées. Il est plus sûr d'opter pour celle qui correspond aux logiciels existants, aux compétences des développeurs, aux périphériques, au processus de mise à jour et à la période de support. Évitez de choisir un système d'exploitation uniquement parce qu'il est courant dans un autre secteur.
Foire aux questions
Linux est-il meilleur pour le contrôle des véhicules en temps réel ?
Pas automatiquement. Le système nécessite des contraintes de synchronisation définies et une architecture éprouvée. Les fonctions critiques peuvent rester dans un calculateur ou un microcontrôleur dédié, tandis que Linux gère l'interface homme-machine, l'enregistrement des données et la communication.
Le PDS T12 est-il compatible avec Android et Linux ?
La page T12 actuelle mentionne Android 13 et une configuration optionnelle avec noyau Linux 5.15 + QT 5.15. Veuillez vérifier la configuration exacte (image système, pilotes, interfaces et outils de support) avant de commencer le développement.
Quel modèle est le plus adapté à une interface homme-machine (IHM) Linux compacte ?
Le T7 est le modèle d'entrée de gamme, plus compact, et intègre des touches de fonction physiques. Le T12 est mieux adapté à une interface multi-écrans étendue, à la gestion de plusieurs vues caméra et à une connectivité véhicule plus large.
Terminez le schéma système avant de choisir l'écran.
Avant de choisir un ordinateur embarqué Linux , établissez un schéma système d'une page. Indiquez ce qui s'exécute sur le terminal, ce qui reste dans le calculateur, toutes les interfaces connectées, le processus d'allumage et d'arrêt, le responsable de la maintenance du logiciel et la méthode de récupération. Une fois ce schéma terminé, la taille d'écran et la configuration matérielle requises sont généralement beaucoup moins sujettes à débat.
Contactez PDS Technology en précisant la configuration de votre interface homme-machine (IHM), vos exigences Linux et QT, vos attentes en matière de démarrage, la liste des interfaces, le nombre de caméras, vos besoins en positionnement, les conditions d'alimentation du véhicule, le marché cible et le volume de production. Notre équipe vous aidera à identifier une configuration T7 ou T12 adaptée à vos besoins d'évaluation technique.
Contactez-nous
📧 Courriel : market@szpds.com
📞Tél. : +86 13421822024
🌐Site web : www.szpds.com
Clause de non-responsabilité
Les informations contenues dans cet article sont fournies à titre indicatif uniquement. PDS Technology Co., Ltd. décline toute responsabilité en cas d'erreurs, d'omissions ou d'inadéquation du contenu à des applications spécifiques. Les spécifications des produits peuvent être modifiées sans préavis. Il est conseillé aux acheteurs de vérifier tous les détails techniques auprès de notre équipe avant utilisation.
À propos de PDS Technology
PDS Technology est un fabricant OEM/ODM de premier plan de terminaux GNSS RTK de haute précision et d'ordinateurs de bord, au service des secteurs de l'agriculture, de la construction, des mines, des taxis et de la logistique depuis 2011.
Forts de plus de 15 ans d'expérience en R&D pour l'automobile, nous proposons des appareils robustes et multi-OS (Android/Linux/OpenHarmony) dotés d'un positionnement RTK centimétrique, d'une protection IP66 et compatibles avec l'intelligence artificielle. Nos usines certifiées IATF 16949 ont produit plus de 100 000 unités déployées dans le monde entier, représentant plus de 30 % du marché chinois des terminaux de pilotage automatique pour l'agriculture. Nous exportons notamment au Japon, aux États-Unis, au Royaume-Uni, en Turquie et en Russie.
