Lire un bus avionique : MIL-STD-1553 et ARINC 429

Deux bus, deux philosophies

MIL-STD-1553 date des années 1970, ARINC 429 de 1977. Les deux sont encore spécifiés sur des appareils qui entrent en service aujourd'hui, et cela mérite qu'on s'y arrête : dans un domaine où rien ne dure, ces deux-là ont survécu à toutes les modes. La raison est simple : chacun fait exactement une chose, et la fait de façon prévisible.

Ils y sont arrivés par des routes opposées. Le 1553 partage un support unique sous contrôle central : un bus controller décide qui parle et quand, si bien que le trafic est un ordonnancement répété et que la latence est bornée par construction. L'ARINC 429 donne à chaque signal sa propre paire et un émetteur unique : il n'y a rien à arbitrer, donc pas de contention du tout.

L'un échange du câblage contre de la complexité de protocole, l'autre fait l'inverse. Un gros avion civil finit avec des centaines de bus 429 ; un appareil bâti autour du 1553 fait passer l'essentiel sur quelques bus. Les deux choix se défendent, et tous deux laissent une signature nette sur la façon de les instrumenter.

MIL-STD-1553 : un bus avec un chef

La couche physique est une paire torsadée blindée, couplée par transformateur, terminée aux deux extrémités, portant des données codées Manchester à 1 Mbit/s. Les installations sont généralement redondantes — bus A et bus B — le contrôleur décidant lequel est utilisé, et ce choix fait lui-même partie de ce qu'il faut enregistrer.

Tout, sur le bus, est un mot de vingt temps-bit : trois de synchronisation, seize de charge utile, un de parité. Il en existe trois sortes — commande, donnée et état — et le motif de synchronisation distingue les mots de commande et d'état des mots de donnée, ce qui permet à un moniteur d'analyser un trafic qu'il n'a pas initié.

Le bus controller émet chaque transaction. Les terminaux distants, adressés de 0 à 30, le 31 étant réservé à la diffusion, ne parlent que lorsqu'ils sont interrogés et doivent répondre dans un délai borné. Un mot de commande nomme le terminal, le sens, une sous-adresse qui désigne le tampon visé, et un nombre de mots de un à trente-deux. Cette dernière limite façonne toutes les interfaces 1553 jamais écrites : un message porte au plus trente-deux mots, donc un gros jeu de paramètres devient beaucoup de petits messages sur un ordonnancement fixe.

Comme le contrôleur ordonnance tout, le trafic est périodique — couramment une trame mineure à 50 ou 100 Hz. Cela rend le 1553 particulièrement agréable à analyser : vous savez ce qui devrait être présent, donc un message qui n'apparaît pas est un constat et non une énigme.

ARINC 429 : un seul qui parle, aucune question

Un bus 429, c'est un émetteur et jusqu'à vingt récepteurs, sur paire torsadée blindée, à 12,5 kbit/s ou 100 kbit/s. Le codage est bipolaire à retour à zéro — trois états de tension, donc le zéro est un véritable état et pas seulement une absence. La réception est totalement passive : vous raccordez un récepteur et rien sur le bus ne s'en aperçoit.

Chaque mot fait trente-deux bits. Huit forment le label, écrit en octal par convention et transmis bit de poids faible en premier — un détail qui piège tout le monde exactement une fois. Deux bits identifient la source ou la destination, dix-neuf portent la donnée, deux portent la matrice signe/état, et le dernier est une parité impaire.

Le label dit de quel paramètre il s'agit ; il ne dit pas ce que la valeur signifie. Le codage — binaire avec une étendue et une résolution déclarées, décimal codé binaire, ou un champ de bits discrets — vient de la spécification de ce label sur cet équipement. Et la matrice signe/état dit si vous avez le droit de croire le nombre : donnée valide, donnée non calculée, test fonctionnel, ou alarme de panne. C'est le champ le plus souvent ignoré, et celui qui transforme une analyse embrouillée en une analyse évidente.

Il n'y a ni acquittement ni retransmission. Un mot corrompu est simplement faux, et la mise à jour suivante arrive à la cadence de répétition spécifiée pour ce label — ce qui est aussi la façon dont un récepteur détecte un paramètre devenu périmé.

Ce que veut dire enregistrer un bus

Vous êtes un moniteur. Vous n'émettez jamais, vous n'acquittez jamais, et vous ne chargez pas le bus : la prise est à haute impédance ou couplée par transformateur, et l'installation est conçue pour que retirer votre instrumentation ne change rien. Si l'appareil se comporte différemment avec votre équipement installé, vos données décrivent un autre appareil.

Chaque message est horodaté à la réception, et la résolution utile est la microseconde, pas la milliseconde. Un mot 1553 occupe vingt microsecondes ; la question qui a motivé l'essai est très souvent une latence — combien de temps entre la commande et la réponse, entre la mise à jour du capteur et la commande qui s'en sert — et un horodatage à la milliseconde n'y répond pas.

Ce qu'il faut enregistrer va au-delà de la charge utile : lequel des bus redondants a porté le message, l'état d'erreur, le temps de réponse, et le fait qu'un message attendu ne soit pas apparu du tout. Un enregistrement de bus qui ne contient que les messages réussis a discrètement jeté la partie la plus intéressante du vol.

La bonne nouvelle, c'est que le trafic de bus coûte peu à stocker. Un bus 1553 pleinement chargé représente 1 Mbit/s de trafic brut ; un bus 429 haut débit, 100 kbit/s. Vingt bus réunis coûtent encore moins qu'une seule voie vidéo : filtrer à la source — l'origine classique du « on n'avait pas enregistré ça » — ne se justifie donc presque jamais.

Dans un enregistrement Chapter 10, le trafic de bus part dans des paquets orientés messages où chaque message porte son propre temps intra-paquet. Le format D.T.MUX associe à chaque message un mot d'offset temporel dont la résolution est sélectionnable. Même idée, deux orthographes : la datation appartient au message, pas au bloc qui le transporte.

Du trafic aux paramètres : l'ICD est le vrai travail

Un message 1553 brut, c'est une adresse de terminal, un sens, une sous-adresse, un nombre de mots et jusqu'à trente-deux mots de charge utile. Rien là-dedans ne dit « vitesse air ». Un mot 429 brut, c'est un label et dix-neuf bits. Rien ne dit « un mètre par seconde par point, complément à deux, négatif vers le bas ».

Ce qui rend le trafic signifiant, c'est le document d'interface : quels mots de quel message portent quel paramètre, dans quel codage, avec quelle mise à l'échelle, quelle convention de signe et quelle unité. L'enregistrement est un problème matériel résolu depuis des décennies. L'interprétation est un problème de gestion de configuration qui n'est jamais tout à fait résolu.

Et l'ICD est vivant. Il appartient à une configuration d'aéronef et à un standard logiciel, et il change entre les deux. Un décodage construit sur le document de l'an dernier appliqué au trafic de cette année produit des nombres faux d'une manière que personne ne remarque — le même mode de défaillance qu'un format PCM erroné, et tout aussi coûteux.

La discipline qui paie : garder la description d'interface avec l'enregistrement plutôt que dans le répertoire de quelqu'un, et utiliser un outil qui vérifie ce qui est vérifiable — labels attendus présents, cadences de répétition plausibles, champs d'état valides — au lieu de décoder en silence.

Là où cela déraille

• Une prise qui charge le bus, ou un coupleur installé sans respecter les règles de longueur de dérivation — une instrumentation qui modifie ce qu'elle mesure.
• Ignorer le mot d'état et la matrice signe/état, puis passer une semaine à expliquer un paramètre que l'appareil avait déjà déclaré invalide.
• Une résolution temporelle choisie par commodité et non pour la question posée : la milliseconde ne mesure pas une latence de bus.
• Supposer qu'un message existe parce que l'ICD le dit. L'ordonnancement est ce que fait le logiciel, pas ce que le document prétend.
• Le label transmis poids faible en premier, et les paramètres binaires lus avec la mauvaise convention de signe. Les deux produisent des données presque justes.
• Ne pas enregistrer quel bus redondant était actif, puis tenter d'expliquer un trou qui n'était qu'une bascule sur l'autre bus.

CAN et AFDX : le paysage actuel

Le CAN est arrivé du monde automobile et se trouve aujourd'hui partout sur les appareils légers, les hélicoptères, les drones et les liaisons entre équipements. Il arbitre par priorité d'identifiant et non par ordonnancement, ce qui le rend événementiel : la charge du bus varie avec ce que fait l'appareil, et les moments intéressants sont précisément les moments chargés. Cela rend l'enregistrement plus utile, pas moins.

ARINC 664, mieux connu sous le nom d'AFDX, reconstruit du déterminisme au-dessus d'un Ethernet commuté : des liens virtuels avec une allocation de bande garantie, si bien qu'un réseau sans contrôleur central conserve une latence bornée. L'enregistrer devient un problème de capture Ethernet — des ordres de grandeur de données en plus qu'un bus 1553, et la question du filtrage redevient réelle.

La tendance est claire : moins de bus dédiés, plus de réseau. Le problème d'instrumentation passe du décodage d'un bus à la capture et au filtrage d'un réseau. Le problème de configuration, lui, ne bouge pas d'un pouce : il faut toujours le document qui dit ce que le trafic signifie.

De retour au sol

La valeur d'un enregistrement de bus n'est presque jamais le bus lui-même. C'est la corrélation : la valeur commandée sur le bus à côté de la valeur mesurée sur une voie analogique, l'action de l'équipage sur la vidéo de poste, le même paramètre tel qu'il apparaissait dans le flux télémesuré. C'est là qu'un essai répond à une question au lieu de produire un fichier.

Ce qui ramène à la condition qui traverse tous ces sujets : une référence de temps unique pour toute l'installation, et un outil qui reconstruit la chronologie à partir du temps enregistré et non de l'ordre d'arrivée. Tout le reste n'est que décodage.