跃钢 周, Dongfeng Motor Corporation
Fusion du protocole J1939 dans la conception de la plate-forme de communication par bus CAN.
Utiliser le logiciel de conception de systèmes NI LabVIEW et un module de communication CAN NI PXI pour concevoir une méthode de filtrage des ID de protocole J1939 afin de recevoir et d’envoyer plusieurs trames selon le format de protocole et de construire une plate-forme de communication CAN. Nous avons également mis en œuvre une simulation complète de l’environnement électrique HIL (hardware-in-the-loop) du véhicule et construit une plate-forme de test sur banc moteur qui inclut l’envoi et la réception de messages par bus CAN, le stockage et l’affichage en temps réel.
Tous les véhicules utilitaires conformes aux normes d’émissions chinoises National III à National IV utilisent le bus CAN pour communiquer entre les unités de contrôle électronique (ECU), y compris l’ECU du véhicule (VECU), l’ECU du moteur (EECU), l’ECU de la boîte de transmission automatique, l’ECU des instruments et l’ECU du système de freinage antiblocage. Le réseau de contrôle de véhicule a mis en œuvre le bus CAN pour véhicules utilitaires basé sur le protocole J1939, combiné avec l’unité de commande multipoint (MCU), le contrôleur CAN et la structure d’émetteur-récepteur CAN du nœud MCU. Les solutions existantes pour les tests sur route et sur banc moteur, ainsi que les tests de simulation HIL de l’environnement électrique des véhicules, qui incluent un PC, un module de communication CAN et un logiciel, sont extrêmement coûteuses.
En raison de l’absence de définitions communes des identificateurs de messages et des trames de données du bus industriel dans les spécifications CAN 2.0 B, les paramètres sont arbitraires. Les spécifications de communication par bus CAN des véhicules utilitaires suivent le protocole SAE J1939, basé sur CAN 2.0 B. Il n’existe actuellement aucune méthode de communication par bus CAN basée sur LabVIEW et le protocole J1939 dans une application de périphérique de contrôle PXI pour l’industrie automobile nationale. Nous avons donc décidé de combiner le logiciel LabVIEW avec le protocole complexe J1939 pour filtrer, recevoir, synthétiser, recombiner et envoyer des messages.
Compte tenu des caractéristiques du réseau de bus CAN des véhicules utilitaires, nous avons construit une plate-forme de bus CAN basée sur LabVIEW et le protocole J1939, et l’avons intégrée dans un périphérique d’interface modulaire NI PXI pour les tests HIL sur le banc moteur et l’environnement électrique des véhicules.
Le protocole J1939 est basé sur les spécifications CAN 2.0 B. L’ID 29 bits de la trame étendue CAN 2.0 B est défini pour former un système de codage J1939, y compris la priorité (P), le bit réservé (R), la page de données (DP), l’unité de données de protocole (PF), l’unité étendue (PS), l’adresse source (SA) et le champ de données, comme le montre la figure 1. La couche d’application du modèle de référence d’interconnexion de systèmes ouverts (OSI) contient sept parties encapsulées dans une ou plusieurs trames de données CAN via une unité de données de protocole (PDU) et transmises à d’autres nœuds de périphériques dans le réseau de bus via la couche physique.
Diverses fonctions de périphériques CAN 2.0 B envoient des informations de message différentes en utilisant le même ID. Les périphériques CAN sélectionnés selon un protocole spécifique du fabricant peuvent ainsi générer des ID non reconnus ou incohérents lors de l’intégration du système. Chaque trame de message du protocole J1939 possède un identificateur et un PGN uniques. Une adresse source unique est ainsi attribuée à chaque nœud et celle-ci est associée à l’identificateur CAN pour éviter que plusieurs nœuds n’utilisent le même identificateur. Par exemple, ID : 0CF00400 représente un message de vitesse et de couple du moteur.
Les spécifications CAN 2.0 B définissent la couche de liaison de données en sept couches du modèle de référence OSI. Il s’agit donc d’une norme de bas niveau, comme le montre la figure 2. Les produits du bus CAN présentent généralement une mauvaise compatibilité, interchangeabilité et intégration. À l’inverse, J1939 est un protocole de haut niveau selon la couche d’application du modèle de référence OSI, qui définit les signaux (paramètres) et les messages (groupe de paramètres) de l’application du véhicule. Le signal est décrit par des paramètres, et chaque paramètre se voit attribuer un numéro de paramètre suspect (SPN). Ces paramètres définissent la signification physique des octets de données dans le champ de données PDU ; par exemple, SPN190 représente la vitesse du moteur.
Les spécifications CAN 2.0 B ne peuvent transmettre que des messages à trame unique, alors que le protocole J1939 peut transmettre des messages à trame unique et multiple, y compris le dialogue et la diffusion. J1939 peut regrouper, envoyer, recevoir, synthétiser et réorganiser des messages selon le protocole de transmission de données à trames multiples.
L’interface du module se compose d’un émetteur-récepteur CAN NI PXI à deux ports, d’un contrôleur CAN SJA1000T, d’un émetteur-récepteur CAN haute vitesse TJA1041T et d’un émetteur-récepteur CAN basse vitesse TJA1054AT. La couche de liaison de données du protocole J1939 regroupe les messages selon le format PDU et effectue la synchronisation des trames de données CAN, le contrôle séquentiel, le contrôle d’erreur et le contrôle de flux.
Selon le protocole de la couche physique J1939, chaque segment de réseau peut comprendre :
De plus, l’émetteur-récepteur du bus CAN convertit le niveau de tension entre le bus CAN et le MCU.
Comme le montre la figure 3, le message de bus CAN basé sur le flux de traitement multitâche du protocole J1939 utilise une structure de boucle productrice et consommatrice. La boucle productrice utilise la fonction de mise en file d’attente des éléments pour ajouter des données à la file d’attente du cluster de messages. Par ailleurs, la boucle consommatrice utilise la fonction de mise en file d’attente des éléments pour déplacer les données hors de la file d’attente du cluster de messages. La file d’attente communique entre les boucles pour éviter les conflits entre plusieurs tâches. Lorsque la production de données est plus rapide que leur consommation, les buffers de file d’attente évitent la perte de données de messages.
Comme le montre la figure 4, nous avons implémenté la plate-forme de communication par bus CAN basée sur LabVIEW et le protocole J1939 dans une simulation d’environnement électrique de véhicule HIL pour un test de réception de messages. Nous l’avons comparé simultanément au module Vector CANoe. La figure 7 montre le message EECU reçu d’un moteur tournant en continu. En une seconde, le système peut recevoir un message de 526 trames de l’EECU sans perdre de message.
Le message de consommation de carburant révèle l’efficacité énergétique du moteur en temps réel. Le VECU reçoit le message dans le réseau de bus CAN selon le protocole J1939 applicable aux véhicules utilitaires pour contrôler le changement de vitesse de la boîte de vitesses automatique. L’ECU d’instruments combinés reçoit et affiche ce message en temps réel pour rappeler au conducteur les bonnes habitudes de conduite et manœuvrer le véhicule pour obtenir le meilleur rendement énergétique. Pour optimiser les performances du moteur, son rendement et les normes d’émissions, nous étalonnons l’EECU pour obtenir les meilleurs paramètres d’étalonnage de largeur d’impulsion d’injection. Après l’étalonnage, nous effectuons un test comparatif pour vérifier les effets de l’étalonnage EECU.
Un test de moteur en régime permanent peut révéler les performances du véhicule à une vitesse constante. Un test de moteur en régime transitoire dans des conditions de fonctionnement variables simule l’état du moteur dans des conditions routières réelles. En comparant le message de consommation de carburant en temps réel et la mesure de consommation de carburant instantanée réelle, nous déterminons les performances du contrôle EECU.
La figure 8 compare la mesure de la courbe de consommation de carburant du moteur en régime transitoire sur banc de test dans 10 conditions de fonctionnement. Les données du message de consommation de carburant EECU reçues et analysées par le bus CAN selon le protocole J1939 sont nettement différentes lorsque le moteur tourne à faible charge par rapport au compteur de consommation de carburant du test et du banc. Ainsi, l’injection réelle de carburant est faible lorsque le moteur tourne à faible charge. La quantité de carburant injectée cible et réelle varie considérablement en raison de la fluctuation de la pression de la rampe commune lorsque le moteur tourne à faible charge, ce qui entraîne une fluctuation de la quantité de carburant. Les deux courbes sont généralement cohérentes : Les valeurs cibles d’injection de carburant du moteur reçues via le bus CAN sont très similaires aux valeurs mesurées réelles, et la tendance et le cadencement sont synchronisés. Autrement dit, l’étalonnage EECU a permis d’obtenir la meilleure valeur cible de largeur d’impulsion d’injection.
La plate-forme de communication par bus CAN basée sur le protocole J1939 et la plate-forme NI PXI a permis de jeter les bases de l’implémentation d’un module NI CAN dans une application de communication par bus CAN pour véhicules utilitaires. La plate-forme est prometteuse pour les applications futures telles que les tests sur banc moteur, les tests HIL de simulation de l’environnement électrique des véhicules, la réalisation du filtrage, la reconnaissance, la synthèse, la réception, le regroupement, la transmission, le stockage, l’analyse, le calcul et l’affichage des messages du bus CAN en temps réel.
Grâce aux puissantes fonctions d’analyse mathématique et de traitement des files d’attente de LabVIEW, aux périphériques NI PXI et à un module d’interface CAN adapté à un environnement de test de véhicule difficile, ce système fournit les fonctionnalités d’analyse des informations sur les messages du bus CAN requises pour de multiples conditions de test. Il démontre la synchronisation de l’échantillonnage des données de message acquises par les périphériques NI PXI. L’analyse comparative démontre les performances en temps réel et l’authenticité des données de test.
跃钢 周
Dongfeng Motor Corporation
Chine
zhouyg@dfl.com.cn