PEUT renifler

Le bus CAN lui-même est déjà beaucoup utilisé où, je suis intéressé par son utilisation dans la voiture, bien que cette zone ne puisse pas être limitée. Il y a quelques années, cette opportunité s'est présentée. J'ai regardé les spécifications générales - il ne semble y avoir rien de particulièrement compliqué. J'ai regardé les programmes que l'on trouve sur Internet - et je n'en aimais aucun, chacun manquait de quelque chose qui me semblait nécessaire à l'époque. Je vais réinventer mon vélo. Je fais renifler mon CAN plus loin sous la coupe.

Bus CAN

La description détaillée des détails techniques du bus CAN fait partie de la documentation. Dans cet article, il suffit de savoir qu'il:

• a une connexion physique à deux fils
• il existe différents débits de données
• des puces prêtes à l'emploi et même des cartes prêtes à l'emploi avec des pièces soudées sont déjà disponibles pour la connexion

Après avoir feuilleté les pages d'une célèbre boutique en ligne de l'Empire du Milieu, j'ai commandé plusieurs options différentes pour les boucliers et suis allé étudier les caractéristiques des signaux électriques dans une voiture. La voiture expérimentale était la LADA Kalina Cross avec le 127e moteur et une unité de commande électronique ITELMA M74.5 CAN.

Je me connecte au connecteur de diagnostic OBD (broches 6 et 14) et regarde l'oscilloscope qui s'y trouve. Après avoir tourné la clé de contact, des paquets d'une amplitude allant jusqu'à 2,5 V. commencent à courir. Je m'arrête sur l'oscilloscope et regarde le paquet.


Les bits de démarrage et d'arrêt sont perceptibles, certaines données du paquet. À cette époque, je savais déjà que le taux de transfert de données devait être de 500 kbit / s, comme étant le plus fréquent pour le bus CAN moteur. La durée du paquet est d'environ 230 μs et avant le paquet, il y a une pause assez importante dans la transmission des données. J'échelonne le temps et vois trois paquets et des pauses entre eux.


Si l'on ajoute la durée du transfert de données et la pause entre les paquets, il s'avère que le transfert d'une donnée prend environ 1 ms.

Pourquoi est-ce que je déduis tout ça? Et la question est purement pratique: la vitesse du port série est-elle suffisante pour transférer toutes les données? Et sur la base de ce que nous avons vu, nous pouvons conclure que la vitesse de 500 kbit / s se développe à l'intérieur du paquet, ce qui prend environ un quart du temps de transmission. Le taux de transfert moyen sera donc quatre fois inférieur. À cette époque, je n'avais toujours pas de test de vitesse d'interface série Arduino, et pour l'avenir, je peux dire que même avec le convertisseur série vers USB CH340 le plus courant, une vitesse de 2 Mbps fonctionne de manière stable.

Scanner CAN sur Arduino

Le premier bouclier arrivé pour l'Arduino UNO classique. Oui, il coûte beaucoup plus cher que ses homologues plus petits, mais il a à bord tout ce dont vous avez besoin et même deux boutons.


C'est avec lui que j'ai commencé toutes les expériences. Assemblé un circuit simple avec ce bouclier et un écran à deux lignes à cristaux liquides. L'objectif était d'afficher au moins certaines données à l'écran. J'ai trié différentes bibliothèques pour travailler avec le bus CAN sur Arduino (je dirai tout de suite que la bibliothèque correcte et fonctionnelle s'appelle CAN-BUS Shield par Seeed Studio avec le fichier d'en-tête mcp_can.h), j'ai changé le résonateur à quartz sur le bouclier 16 MHz (à l'origine, c'était 8 MHz) - il n'y avait pas de données.

Deux microcircuits sont installés sur le blindage: le contrôleur de bus CAN MCP2515 et le pilote de bus CAN TJA1050. Après avoir lu la documentation et les différents forums, j'ai décidé de changer le TJA1050 en un pilote plus canonique MCP2551 et les données sont apparues. Peut-être que le TJA1050 était initialement défectueux, car il était très difficile de se tromper en le connectant avec deux fils, en plus, j'ai utilisé des connecteurs OBD et DB9 pour la connexion.

En quelques heures, un simple scanner CAN a été écrit, qui affiche sur le LCD le numéro du paquet capturé, son ID et jusqu'à 8 octets de données pour ce paquet.


C'est là que les boutons sur le bouclier sont devenus utiles, que j'ai utilisé pour basculer entre le numéro du paquet affiché.


Le début étant posé, il faut passer à une mise en œuvre plus intéressante.

CAN sniffer sur Arduino

La tâche était assez simple:

• accepter le paquet du bus CAN
• nous mettons les données reçues dans notre structure
• envoyer la structure via le port série

Je n'ai vu aucun problème avec les deux premières tâches. La bibliothèque a fourni une interruption lors de la réception du prochain paquet de données et des fonctions pratiques pour la réception des données. Mais j'ai décidé d'envoyer des données à l'ordinateur via la bibliothèque CyberLib, ce qui élimine une partie de la surcharge de l'ensemble de la plate-forme Arduino, grâce à laquelle vous pouvez légèrement décharger le processeur pour traiter les données. Plus tard, cette bibliothèque a dû être abandonnée.

Afin de garantir que les données envoyées sont correctement traitées côté ordinateur, un préfixe de quatre octets 0xAA55AA55 est inséré dans le flux avant chaque prochaine donnée (pour une raison quelconque, ces octets étaient mémorisés pour les deux derniers octets du secteur de démarrage DOS, mais ils étaient dans un ordre différent). La logique est la suivante:

• l'ordinateur lit l'intégralité du flux depuis le port série et y trouve la séquence de préfixe souhaitée 0xAA55AA55
• immédiatement après le préfixe, il y aura 4 octets de l'identifiant du paquet
• plus la longueur des données de ce paquet, il contrôle la longueur de l'ensemble du paquet
• jusqu'à 8 octets de données

Sur ce point, la partie logicielle d'Arduino, à cette époque, était terminée. Plus tard, il a été considérablement refait, mais le concept général n'a pas changé.

J'ai également écrit un simple générateur de paquets de données pour le débogage à déboguer à la maison - il envoie simplement des paquets avec des données aléatoires au port série, ce qui vous permet de déboguer l'application sur votre ordinateur dans des conditions confortables.

Vers la même époque, les plus petits composants du blindage Arduino Nano et Mini CAN sont arrivés.


J'ai conçu un petit boîtier, je l'ai imprimé et j'ai placé tous les composants à l'intérieur.


À l'extérieur, il y a un connecteur OBD d'un côté et Mini USB de l'autre. À l'intérieur, il y a un interrupteur pour une résistance de terminaison.

CAN sniffer sur PC en utilisant wxWidgets

J'ai esquissé une ébauche simple d'un programme en C #, qui affiche les données reçues dans la grille. Et il est allé vérifier la voiture. Je n'allais tout simplement pas avec mon ordinateur portable, car sa batterie m'avait ordonné de vivre longtemps et était utilisée comme ordinateur fixe, mais j'ai pris un netbook avec un processeur très faible. Ce que j'ai vu ... je n'ai rien vu. Les deux cœurs sont chargés à 100%, l'interface d'application ne répond pas. Mais sur mon ordinateur, qui est encore beaucoup plus rapide qu'un netbook, avec le générateur de paquets aléatoires, l'application a bien fonctionné et affiché les données. De là, j'ai conclu que la plate-forme .NET sur des ordinateurs faibles ne fonctionnerait pas pour moi, car je ne pouvais déboguer sur le terrain à ce moment-là qu'avec ce netbook.

Plus tôt, j'ai utilisé la bibliothèque wxWidgets dans plusieurs projets et je n'ai qu'une expérience agréable à ce sujet. Il est léger, il n'est pas nécessaire de transporter diverses bibliothèques avec lui, et même multiplateforme, ce qui donne espoir que la partie interface du code peut être transférée sans altérations importantes vers d'autres plates-formes. À la fin de l'article, il y aura un lien vers le programme compilé, si vous ne souhaitez pas vous embêter avec tout cela.


Le premier prototype implémenté en C ++ et wxWidgets a montré que même un netbook gère l'affichage des données dans une table, et j'ai commencé à développer ce que j'avais prévu.

Sur le plan architectural, le programme se compose de deux flux: interface et flux de travail avec un port série. Aucun algorithme incroyablement intéressant n'a été appliqué. Le code est abondamment commenté et devrait être assez simple. Un lien vers la source sera à la fin de l'article.

La première chose qui a été faite a été la coloration des cellules de données dans le tableau en fonction de la limitation de l'obtention de ces données. Déjà dans le premier prototype, en regardant 17 lignes de données dont les valeurs changeaient continuellement, j'ai réalisé qu'il était nécessaire de distinguer d'une manière ou d'une autre les données fraîches et les données qui ne changent pas ou changent rarement. Il a fait une coloration en deux étapes:

• les premières données sont mises en évidence en arrière-plan de cellule verte
• les données arrivant à plusieurs reprises et plus loin sont surlignées avec un fond rouge, qui s'estompe progressivement en blanc si ces données ne changent plus

Immédiatement, il est devenu clair quelles cellules n'étaient pas du tout utilisées, lesquelles contenaient les contre-signaux. La recherche de valeurs variables d'intérêt est grandement simplifiée. Ci-après, toutes les images sont animées. Si l'animation ne fonctionne pas dans l'article (sur certains navigateurs mobiles) - cliquez sur l'image pour ouvrir la version complète de l'animation.



Ensuite, je voulais toujours vérifier si le port série est compatible avec le flux de données. Pour ce faire, côté Arduino, j'ai ajouté des compteurs pour le nombre de paquets reçus et un compteur d'octets dans le paquet. Ces compteurs sont envoyés à l'ordinateur dans un paquet avec l'identifiant 0x000. Lors de la réception de ces données, le programme ne les affiche pas dans un tableau, mais les affiche dans des champs d'informations séparés en haut. Les résultats ont même été assez agréables. En moyenne, jusqu'à 750 paquets / s sont reçus à une vitesse allant jusqu'à 9,5 kB / s, et c'est là que dans la région jusqu'à 80 kbit / s, ce qui est tout à fait possible pour un port série. Mais tout de même, l'échange de données est configuré par défaut à 500 kbps, que ce soit un meilleur stock.

L'ajout de la possibilité d'écrire des données dans le journal est apparu après avoir connecté l'adaptateur de diagnostic ELM327 en parallèle avec l'interface OBD et l'ai connecté au téléphone, j'ai essayé de lire diverses données. Les données étaient si rapides qu'il était impossible de les voir. Après avoir enregistré tout cela dans un journal, vous pouvez ensuite vous asseoir calmement et voir les données transmises. Pour ce faire, même les données de texte ASCII peuvent être écrites dans le journal. Vous pouvez également sélectionner le type de fichier, le caractère délimiteur et configurer le filtre de paquets en cliquant sur l'identifiant de paquet spécifié dans le tableau et en cliquant sur le bouton "Ajouter un ID au filtre" (par défaut, toutes les données sont écrites) si toutes les données sont écrites redondantes.

C’est alors que l’on a réalisé que toutes les applications téléphoniques qui effectuent toutes sortes de «diagnostics» via le bundle ELM327 et le téléphone ne communiquent pas directement avec le bus CAN du véhicule. Ils utilisent simplement la fonctionnalité de diagnostic OBD via le bus CAN en accédant à l'ID CAN 0x7E0. Habituellement, c'est l'adresse du contrôleur de moteur (ECU), la réponse en provient dans un paquet avec l'identifiant 0x7E8. Mais tous les autres paquets de données sont ceux dits spécifiques au vendeur et aucun fabricant ne les ouvrira simplement (bien qu'il y ait un exemple: Ford a publié un SDK pour ses voitures ).

En continuant à étudier ce qui est transmis dans ces packages, j'ai eu une autre idée: lorsque je clique sur une cellule du tableau, dans la fenêtre de programme à droite, affiche la valeur binaire et décimale de cet octet, ainsi que prend l'octet suivant et ajoute au mot. Ensuite, multipliez ce mot par un certain coefficient et obtenez un résultat décimal. Cela ne semble pas très clair, mais en rapport avec ce qui a été fait: la vitesse du moteur est fournie en paquet CAN ID 0x180, dans les deux premiers octets. Ces deux octets donnent un certain mot qui est proportionnel aux tours. Si la signification de ce mot est divisée par 8, alors l'élan actuel est obtenu. Par conséquent, un facteur de 0,125 est indiqué, comme l'inverse de 8. Ensuite, ce mot est visualisé dans un graphique avec ajustement dynamique en amplitude. En principe, le multiplicateur peut être recherché dans l'ordre inverse: j'ai trouvé des cellules qui sont très similaires à la vitesse du moteur ou autre chose selon le calendrier, après quoi le multiplicateur est ajusté pour obtenir des valeurs réelles.


Eh bien, la représentation binaire vous permet de rechercher divers indicateurs de bits. Par exemple, la recherche d'indicateurs de direction se réduit à les allumer et à observer quelle cellule commence à changer, dans l'exemple ci-dessous, c'est CAN ID 0x481 octet 2. Après cela, cliquer sur une cellule affiche sa valeur binaire dans le champ correspondant, où la commutation des deux inférieures est déjà visible bits (gauche, droite et si ensemble - une alarme).


Et enfin, je devais envoyer des données de contrôle au bus CAN et voir la réaction à ces commandes. Un code a été ajouté au programme Arduino qui reçoit les données de l'ordinateur et les transfère vers le bus CAN. C'est à ce stade que CyberLib a dû être abandonné, car il n'avait pas de support pour interrompre la réception des données dans le tampon du port série. Dans le programme sur l'ordinateur, j'ai ajouté plusieurs champs de texte dans lesquels vous pouvez entrer divers paramètres et un tableau pour voir la réponse de l'actionneur. L'exemple ci-dessous montre les commandes de contrôle activer / désactiver la première vitesse du ventilateur de refroidissement (0x0A) et activer / désactiver l'embrayage du climatiseur (0x0B).

Résumé

Pratiquement nulle part où trouver un décryptage complet des données des fabricants, en particulier les données officielles. Dans le meilleur des cas, ce sera la recherche de quelqu'un d'autre dans le cadre de la mise en œuvre d'une fonction supplémentaire. CAN sniffer peut vous aider à trouver ces données. J'ai pu trouver environ 40 paramètres différents de la voiture et pour des raisons d'expérience, sur la base des données, j'ai fait mon propre contrôle du ventilateur de refroidissement.

• Renifleur de bus CAN (côté Arduino)
• renifleur de bus wxCAN (côté PC)
• renifleur de bus wxCAN (exécutable Windows)

J'espère que tout cela me sera utile non seulement.