Technologie

L'application de bureau et la ligne de commande utilisent le même moteur de mesure, écrit en Rust. Cette page présente l'architecture, le flux de données d'une mesure, les performances et les principaux termes des réseaux embarqués.

Architecture Flux de données Performances Glossaire

Architecture

La mesure, le décodage, la simulation et l'enregistrement s'effectuent dans le moteur. L'interface reçoit les données par lots, à une fréquence maximale fixe, et ne peut donc pas ralentir la mesure.

Bordure continue : intégré à Arnodiqa. Bordure en tirets : via le pilote du fabricant.

Rust

Rust n'utilise pas de ramasse-miettes : aucune pause de collecte, même à des débits de trames élevés. Le moteur est multithread.

Tauri 2 + React

Une fenêtre native et une installation légère. L'ancrage des fenêtres (docking), les tableaux virtualisés et le rendu sur canvas prennent en charge de grands volumes de données.

YAML + JSON Schema

Les projets sont des fichiers texte que vous pouvez comparer et fusionner dans git. Le schéma fournit l'autocomplétion et la validation dans l'éditeur.

Journaux et support

Chaque binaire écrit un fichier journal à rotation ; un plantage génère un rapport local. Le paquet de support (zip) contient les journaux, la version et les informations système et matériel, avec les noms d'utilisateur, le nom d'hôte et les numéros de série anonymisés. Il ne contient jamais de clés, de données de bus ni de sources CAPL. Aucune donnée n'est envoyée.

Flux de données d'une mesure

Les trames proviennent d'une interface, du bus virtuel ou d'un fichier journal. Chaque événement reçoit un horodatage en nanosecondes depuis le début de la mesure.
Le thread d'E/S trie par ordre chronologique les événements de plusieurs canaux (fenêtre de réordonnancement) et les regroupe en lots.
Les lots passent par une file d'attente bornée. En temps réel, la mesure n'attend jamais : en cas de surcharge, des lots sont écartés, comptés et signalés. En mode « aussi vite que possible », le producteur attend et rien n'est perdu.
Le thread d'analyse met à jour les statistiques et exécute le graphe du Measurement Setup : filtres, déclencheurs avec temps de pré- et post-déclenchement, et branches vers l'enregistrement et les fenêtres.
Chaque bloc d'enregistrement écrit en parallèle dans son propre thread. L'interface reçoit au plus 30 à 60 lots par seconde ; en cas de retard, elle abandonne les événements les plus anciens et les comptabilise.

Performances

Live Trace	20 000 trames/s avec un affichage à 60 fps, y compris avec un filtre ou en mode position fixe
Lecture BLF	> 6 millions de trames/s ; mémoire utilisée indépendante de la taille du fichier
Écriture BLF	0,7 à 1 million de trames/s (zlib niveau 6)
Décodage DBC	< 1 µs par message de 20 signaux
Bus virtuel	1 Mbit/s en temps réel sans perte de trames

Valeurs typiques sur un poste de travail Windows récent ; les chiffres réels dépendent du matériel et de la configuration.

Glossaire

Un véhicule embarque des dizaines de calculateurs (ECU) qui échangent des messages sur des bus. Voici les termes les plus utilisés sur ce site.

ECU: Electronic Control Unit, ou calculateur : contrôle moteur, freinage ou gestion de batterie, par exemple. Une voiture en compte de 30 à plus de 100.
CAN: Controller Area Network : le bus embarqué le plus répandu, utilisé depuis les années 1980. Deux fils, des messages avec un identifiant de 11 ou 29 bits et jusqu'à 8 octets de données. Débit typique de 500 kbit/s.
CAN FD / CAN XL: Successeurs plus rapides. CAN FD transporte jusqu'à 64 octets avec une phase de données accélérée (2 Mbit/s par exemple) ; CAN XL transporte jusqu'à 2048 octets à environ 10 à 20 Mbit/s.
Arbitration: Lorsque deux calculateurs émettent en même temps, le message dont l'identifiant est le plus bas l'emporte, sans perte de données. L'identifiant fixe donc aussi la priorité.
Trame d'erreur, bus-off: Un calculateur qui détecte une erreur détruit la trame en émettant une trame d'erreur. Un nœud qui provoque trop d'erreurs passe à l'état « error passive », puis « bus-off » : il se déconnecte alors lui-même du bus.
Message et signal: Un message (trame) contient plusieurs signaux, par exemple EngineData avec EngineSpeed (tr/min) et CoolantTemp (°C), à des positions de bits fixes avec un facteur et un décalage.
DBC: Le format de fichier de référence de fait qui décrit les messages et signaux d'un réseau CAN. Sans DBC, vous ne voyez que des octets hexadécimaux ; avec une DBC, des valeurs lisibles.
LDF, ARXML, FIBEX: Fichiers de description pour, respectivement, LIN, les réseaux AUTOSAR (XML, tous bus confondus) et FlexRay/Ethernet.
LIN, FlexRay, Automotive Ethernet: Autres bus embarqués. LIN est économique et lent (lève-vitres, sièges), FlexRay est déterministe (châssis), Ethernet est rapide (caméras, calculateurs centraux) et utilise SOME/IP comme middleware.
J1939: Norme fondée sur CAN pour les poids lourds, les autocars, les machines agricoles et les engins de chantier, organisée en groupes de paramètres (PGN). Les nœuds revendiquent leur adresse avec un NAME de 64 bits ; les messages de plus de 8 octets passent par des protocoles de transport (BAM, CMDT) ; DM1 signale les codes défaut actifs.
Trace: La fenêtre principale : une liste en direct de chaque trame sur le bus, avec l'horodatage, le canal, l'identifiant, le nom, les données et les signaux décodés.
Measurement Setup: Un graphe de blocs qui détermine le traitement des données : filtrage, déclenchement (« enregistrer 50 ms avant et 200 ms après 800 tr/min »), enregistrement dans un fichier et affichage dans les fenêtres.
Simulation de bus résiduel: Vous testez un seul calculateur réel pendant que le logiciel simule le reste du bus (tous les autres calculateurs). Le calculateur se comporte alors comme s'il était monté dans un véhicule complet.
Interaction Layer (IL), NM: La couche d'interaction (IL) émet les messages selon les règles de la base de données (cyclique, sur changement, compteurs de vie, sommes de contrôle). La gestion de réseau (NM) coordonne la mise en veille et le réveil simultanés des calculateurs.
CAPL: Langage de script événementiel proche du C, créé par Vector Informatik (on message, on timer…) et très utilisé sur les bancs de test. La machine virtuelle de script d'Arnodiqa exécute les programmes CAPL existants.
UDS, ISO-TP, DoIP: Diagnostic. UDS (ISO 14229) est le protocole qui permet d'interroger un calculateur (codes défaut, sessions, flashage). ISO-TP segmente les messages longs pour CAN ; DoIP remplit la même fonction sur Ethernet.
BLF, ASC, MF4: Formats de fichiers journaux. BLF est binaire et compact (Vector), ASC est un texte lisible, MF4/MDF est la norme ASAM pour les données de mesure.
XCP: Protocole de mesure et de calibration des variables internes d'un calculateur pendant la conduite.
SIL / HIL: Software-in-the-loop (tout est virtuel, ce qui convient à l'intégration continue) et hardware-in-the-loop (un calculateur réel sur un banc HIL, dans un environnement simulé).
E2E, SecOC: Mécanismes AUTOSAR de protection des messages. E2E ajoute un compteur de vie et un CRC contre les messages altérés ou perdus ; SecOC ajoute une valeur de fraîcheur et un MAC contre la falsification et le rejeu. Dans une simulation de bus résiduel, les deux doivent être calculés correctement, faute de quoi le calculateur rejette les messages.
Flashage: Chargement d'un nouveau logiciel dans un calculateur, généralement via UDS : changement de session, security access, effacement de la mémoire, téléchargement des données, vérification et réinitialisation. Le micrologiciel est livré au format Intel HEX, S-record, binaire ou ODX-F.
Environnement isolé (air-gapped): Réseau physiquement séparé d'Internet, par exemple dans les laboratoires d'essais, de défense ou de sécurité. Le logiciel doit y fonctionner entièrement hors ligne, y compris l'installation, les licences, les mises à jour et l'IA. Voir Utilisation hors ligne.
CI: Intégration continue : à chaque modification du code, les tests s'exécutent automatiquement sur un serveur. Il faut pour cela un outil qui fonctionne sans interface graphique et sans connexion Internet.