Un calculateur embarqué CAN Bus ne se contente pas de mettre à disposition deux bornes CAN. Il doit recevoir les messages appropriés au moment opportun, transmettre les données sélectionnées à une application, coexister avec les périphériques série et les liaisons sans fil, et garantir un fonctionnement fiable quelles que soient les conditions électriques et environnementales du véhicule.
Pour les équipementiers, la difficulté commence après le choix de la taille de l'écran. Les équipes d'intégration doivent s'accorder sur l'architecture du bus, les définitions des messages, l'interface avec le système d'exploitation, le comportement du service et les tests d'acceptation. Ce guide propose une liste de contrôle pratique pour transformer un terminal CAN Bus en un sous-système de production reproductible.
Illustration de l'intégration PDS. Le câblage, les protocoles et le comportement du logiciel doivent être validés sur le véhicule cible.
Définissez l'architecture informatique embarquée du bus CAN avant de choisir le matériel.
Un réseau CAN est un bus différentiel partagé. Plusieurs calculateurs électroniques échangent des trames, et chaque nœud récepteur détermine la pertinence d'une trame. La couche physique, le débit binaire, la terminaison, la politique de connexion et le protocole de messagerie doivent correspondre à la conception du véhicule. CSS Electronics propose une introduction utile au bus CAN pour les équipes ayant besoin d'un vocabulaire commun.
La première décision du constructeur concerne les fonctionnalités autorisées pour l'ordinateur de bord utilisant le bus CAN. Il peut se limiter à la surveillance des données, exécuter un nombre restreint d'actions, servir de passerelle ou participer à un réseau privé. Ce rôle doit être consigné dans le document de contrôle de l'interface. Un terminal de surveillance et un contrôleur capable de recevoir des commandes nécessitent des tests et une attention particulière en matière de cybersécurité.
Identifiez également tous les bus connectés au terminal. Les véhicules commerciaux séparent souvent les réseaux CAN du groupe motopropulseur, de la carrosserie, des outils, des diagnostics et les réseaux CAN privés. Leur mélange sans stratégie d'isolation ou de passerelle peut générer du trafic indésirable, des réveils intempestifs ou la propagation de défauts.
| Couche d'intégration | décision de conception | Preuves requises |
|---|---|---|
| Physique | Débit binaire, topologie, terminaison, câble, connecteur et isolation | Schéma de câblage, capture d'image à l'oscilloscope ou à l'analyseur et plan CEM |
| Protocole | Format brut CAN, J1939, CANopen, ISO-TP, UDS ou format propriétaire | Base de données de messages, identifiants, diagrammes de chronologie et d'état |
| Système opérateur | Pilote, API, autorisations, priorité du processus et récupération | Documentation du SDK, exemples de code et résultats d'injection de fautes |
| Application | Décodage, filtrage, journalisation, affichage et logique métier | Cas de test de bout en bout avec données de véhicule enregistrées |
| Cycle de vie | Gestion des versions, mises à jour, diagnostics et service après-vente | configuration de référence, processus de déploiement et procédure de récupération |
Liste de contrôle complète pour un ordinateur de véhicule CAN Bus RS232 RS485
Les projets des constructeurs automobiles combinent souvent le bus CAN avec des équipements série existants. Une liste de contrôle pour un calculateur de véhicule CAN Bus RS232 RS485 doit documenter chaque interface séparément, puis tester l'intégralité du chemin de données.
Bus CAN
Vérifiez le nombre de canaux indépendants, la compatibilité CAN FD, les débits binaires, la méthode de terminaison, l'isolation, le comportement de réveil et le brochage du connecteur. Assurez-vous que le terminal ne doit recevoir que des trames spécifiques ou également transmettre des messages. Mesurez la charge du bus et la latence maximale avec le faisceau complet du véhicule.
RS232 et RS485
Pour un calculateur embarqué avec interface RS232, spécifiez les niveaux de tension, le débit en bauds, le contrôle de flux, le connecteur, la longueur du câble et le protocole. Le RS232 est généralement une liaison point à point. Le RS485 peut fonctionner en semi-duplex ou en duplex intégral avec plusieurs nœuds ; les exigences de terminaison et de polarisation doivent donc être définies. Ne présumez pas que des paramètres de débit en bauds identiques garantissent la compatibilité du protocole.
Avant l'installation sur véhicule, demandez un test de boucle ou un test au niveau du périphérique. Testez ensuite le trafic simultané sur le réseau CAN, les deux canaux série, l'USB et la connexion sans fil. La charge partagée du processeur et la gestion des interruptions peuvent révéler des problèmes invisibles lors des démonstrations sur une seule interface.
Illustration de l'intégration OEM de PDS. Le comportement de l'interface doit être confirmé avec la configuration du produit indiquée.
Contrôler la base de données de messages et le modèle de données
L'application ne doit pas décoder de trames hexadécimales brutes dans l'ensemble du code. Définissez une base de données de messages (DBC), associez les valeurs physiques et les unités, et générez une couche de décodage testée. Incluez les taux de mise à jour, le comportement en cas de délai d'attente, la gestion des valeurs invalides, l'ordre des octets, la mise à l'échelle et les plages de signaux.
Mettez à jour la base de données avec le logiciel du véhicule, et pas seulement avec l'application terminale. Si un calculateur ajoute un message ou modifie un signal, l'équipe d'intégration doit savoir quels terminaux, modèles cloud et cas de test sont concernés. Stockez des journaux CAN représentatifs afin de pouvoir reproduire les modifications de décodage sans véhicule.
Si le projet utilise la norme SAE J1939 , documentez les adresses sources, les groupes de paramètres, le comportement des requêtes et la gestion des diagnostics. Pour CANopen ou un protocole propriétaire, fournissez les automates d'état et les définitions d'erreurs équivalents.
Sélectionnez le système d'exploitation et l'API CAN
Un ordinateur de bord CAN fonctionnant sous Linux peut exposer ses interfaces via le sous-système SocketCAN du noyau. L'équipe logicielle peut utiliser les opérations de socket standard, les filtres et les outils réseau. Il est important de vérifier la version du noyau, le pilote CAN, la configuration du tampon de réception et les permissions dans l'image système finale, et non uniquement sur une carte de développement.
Sur Android, le fournisseur peut proposer une API Java, Kotlin, native ou JNI. Renseignez-vous sur la manière dont les applications reçoivent les trames, dont l'accès à la transmission est contrôlé et ce qui se passe lors du redémarrage du service. Le plan d'intégration doit inclure un mécanisme de surveillance ou de contrôle d'intégrité capable de reprendre le service après l'arrêt d'un processus, la déconnexion d'une interface ou une erreur en mode passif sur le bus.
Les projets OpenHarmony doivent recevoir une définition d'interface tout aussi précise. Il est inacceptable d'accepter une déclaration générique indiquant la prise en charge du protocole CAN. Le fabricant d'équipement d'origine (OEM) a besoin de l'API concrète, d'un exemple de projet, des permissions, du comportement du cycle de vie et des fonctionnalités de débogage.
Ajoutez le GNSS et la 4G LTE sans dégrader l'interface du véhicule.
Un terminal GNSS embarqué avec bus CAN permet de combiner les données de position, de mouvement et d'état du véhicule. Définissez la précision requise, la fréquence de mise à jour, le format des coordonnées, la source de temps et le service de correction. Testez le positionnement de l'antenne en conditions réelles (toit, cabine, chargement et équipements radio à proximité). Gérez la perte GNSS et le délai d'expiration CAN indépendamment les uns des autres afin qu'une source indisponible n'affecte pas l'autre.
Un ordinateur embarqué 4G LTE étend ces flux de données à une plateforme de flotte, mais la liaison montante ne doit pas être considérée comme toujours disponible. Spécifiez les bandes de fréquences prises en charge, les profils d'opérateur, le comportement en itinérance, l'isolation des antennes, les limites de données et le délai de reconnexion. Utilisez la mise en mémoire tampon locale pour les enregistrements importants et définissez les champs à envoyer immédiatement, périodiquement ou uniquement après un événement.
Délimiter la propriété et l'accès aux données. Les propriétaires de véhicules peuvent exiger le contrôle des données de localisation, de diagnostic, de conducteur et d'exploitation. Le terminal et la plateforme cloud doivent disposer de politiques claires en matière d'authentification, d'autorisation, de conservation des données et de contrôle à distance.
Protéger l'alimentation, les signaux et le périmètre logiciel
L'alimentation du véhicule comprend les seuils de démarrage, la décharge de charge, les démarrages d'urgence et la commutation des accessoires. Le calculateur embarqué du bus CAN doit être spécifié en fonction de la catégorie de véhicule : plage d'entrée, norme de transitoires, fusible, mise à la terre et comportement d'allumage. Les ports CAN et série peuvent également nécessiter une isolation galvanique ou une protection lors de leur connexion à des équipements externes.
Considérez le bus CAN comme une interface de confiance uniquement après que le constructeur l'ait validée. Limitez les identifiants de transmission, validez les longueurs et les plages de réception, réduisez le débit des commandes et empêchez une application d'accéder à des canaux de bus non autorisés. Consignez les modifications de configuration critiques pour la sécurité et prenez en charge les mises à jour logicielles signées ou vérifiées.
Le faisceau de câbles doit faciliter la maintenance. Étiquetez les connecteurs, documentez le brochage, protégez les ports inutilisés et spécifiez le couple de serrage lorsque nécessaire. Un terminal validé en laboratoire peut néanmoins présenter une défaillance si un faisceau de câbles trop épais tire sur un connecteur ou crée un court-circuit perturbant le bus.
Utilisez une matrice d'acceptation pour la mise en production.
| Zone de test | Exemple de critère d'acceptation |
|---|---|
| Santé des bus | Aucune image d'erreur inattendue lors des séquences normales, de démarrage, de sortie de veille et d'arrêt. |
| Exactitude des données | Les signaux décodés correspondent aux mesures de référence sur toute la plage de fonctionnement. |
| Latence | Les données critiques parviennent à l'application dans les délais et le budget prévus par le projet. |
| Récupération | Les services CAN, série, GNSS et cellulaires sont rétablis après des pannes de câble, d'alimentation et de réseau. |
| cycles de puissance | Les données de configuration et les données mises en mémoire tampon sont conservées dans les scénarios d'allumage et de batterie requis. |
| Mise à jour et restauration | Une mise à jour ayant échoué peut ramener l'appareil à une version fonctionnelle connue. |
Avant la production, un calculateur embarqué CAN Bus doit réussir une série de tests validés portant sur le bus, la latence, la récupération et les mises à jour. PDS propose une assistance à l'intégration OEM/ODM pour les terminaux embarqués durcis et assure l'alignement des interfaces avec le plan logiciel du projet. L'OEM reste responsable des spécifications d'interface au niveau du véhicule et doit approuver le plan de validation final.
Illustration de la validation PDS. Les critères d'acceptation et l'équipement de test doivent être convenus avant la mise en production.
FAQ
De quoi un ordinateur de bord utilisant le bus CAN a-t-il besoin pour recevoir les données du véhicule ?
Il lui faut une interface CAN physique compatible, le débit binaire et la terminaison appropriés, un accès au bus concerné, une base de données de messages et un logiciel capable de décoder les signaux requis. Le terminal doit également gérer les délais d'attente, les valeurs invalides et les défauts de bus.
Un ordinateur de bord peut-il utiliser simultanément les protocoles CAN, RS232 et RS485 ?
De nombreux ordinateurs de bord durcis peuvent prendre en charge ces interfaces simultanément, mais le nombre exact de canaux et leur isolation dépendent du modèle. Testez tout le trafic requis en même temps et vérifiez que le système d'exploitation expose correctement chaque interface.
Le protocole J1939 est-il identique au bus CAN ?
J1939 est un protocole de couche supérieure utilisé sur les réseaux CAN, principalement dans les véhicules lourds. Un terminal peut prendre en charge physiquement le CAN sans pour autant prendre en charge les messages J1939 spécifiques ni le comportement de diagnostic requis par le projet.
Les données CAN doivent-elles être traitées sur le terminal ou dans le cloud ?
Utilisez le terminal pour le filtrage temporel, l'affichage, les alertes et la mise en mémoire tampon. Envoyez les enregistrements synthétisés ou événementiels vers le cloud lorsque la disponibilité du réseau et la politique de données le permettent. La répartition des données doit tenir compte de la latence, de la confidentialité, du coût et des exigences de fonctionnement hors ligne.
Contactez-nous
📧 Courriel : [email protected]
📞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.
