Normes & formats
IRIG 106 Chapter 10, expliqué
Pourquoi les données d'essai finissent dans un fichier .c10, ce que le standard spécifie réellement, et ce qu'il laisse volontairement au constructeur — un guide pratique pour les ingénieurs qui enregistrent, déchargent et analysent des données embarquées.
Pourquoi les essais en vol avaient besoin d'un format commun
Une installation d'essais en vol n'est presque jamais mono-fournisseur. Les capteurs viennent d'un industriel, les unités d'acquisition d'un autre, l'enregistreur d'un troisième, la station sol et le logiciel d'analyse de deux autres encore. Tous doivent s'accorder sur ce à quoi ressemble une seconde de vol enregistrée.
Avant l'existence d'un format numérique commun, chaque enregistreur écrivait le sien. Cela signifiait un lecteur spécifique par appareil, des données prisonnières d'une chaîne d'outils, et un problème d'archivage qui ne fait que grossir : un programme qui vole trente ans doit pouvoir réouvrir un fichier enregistré sur un matériel qui n'existe plus.
IRIG 106 est le standard de télémesure publié par le Telemetry Group du Range Commanders Council, et il fait référence dans les centres d'essais. Chapter 10 en est le chapitre consacré à l'enregistrement numérique : un conteneur unique que tout outil conforme sait ouvrir. La conséquence pratique est celle qui compte — votre enregistreur et votre logiciel d'analyse n'ont plus à venir du même fournisseur.
Ce que Chapter 10 spécifie — et ce qu'il ne spécifie pas
Il spécifie
- Un conteneur par paquets : comment des données hétérogènes (trames PCM, bus avioniques, vidéo, analogique, tout-ou-rien, liaisons série) sont encapsulées, identifiées et horodatées dans un seul flux.
- L'identification des voies, le séquencement des paquets et les contrôles d'intégrité.
- L'enregistrement de configuration (TMATS) qui décrit le contenu.
- La représentation du temps et son rattachement à une référence externe telle qu'IRIG-B ou GPS.
- Les interfaces utilisées pour décharger ou diffuser les données.
Il ne spécifie pas
- La conversion de vos paramètres en grandeurs physiques — l'étalonnage vit dans votre base d'instrumentation, au mieux partiellement reflété dans TMATS.
- Les schémas de compression ou de chiffrement, qui restent du domaine du constructeur.
- À quoi ressemble un fichier bien organisé. Les index d'enregistrement et les événements sont utiles mais optionnels.
À l'intérieur d'un paquet Chapter 10
Tout, dans le fichier, est un paquet, et chaque paquet commence par un en-tête de taille fixe. Il démarre par un motif de synchronisation (0xEB25) qui permet à un lecteur de s'accrocher au flux même en cours de fichier, puis porte l'identifiant de voie, les longueurs de paquet et de données, un numéro de séquence, des drapeaux, le type de donnée, et un compteur de temps relatif (RTC) de 48 bits cadencé à 10 MHz. Une somme de contrôle d'en-tête le referme.
Un en-tête secondaire optionnel porte le temps absolu. Vient ensuite un mot spécifique à la voie, qui contient les paramètres n'ayant de sens que pour ce type de donnée, puis la charge utile. Pour les types orientés message — un bus 1553, ARINC 429, une liaison série — chaque message de la charge utile est précédé de son propre en-tête intra-paquet portant son horodatage et son état. Du remplissage et une somme de contrôle optionnelle ferment le paquet.
faire défiler
Cet horodatage à deux niveaux est le cœur du standard. Un message 1553 et une image vidéo enregistrés dans des paquets différents peuvent être rejoués dans leur ordre réel, parce que chacun porte son propre instant au lieu de dépendre de sa position dans le fichier.
Les types de données que vous rencontrerez
faire défiler
| Famille | Contenu typique | Intérêt |
|---|---|---|
| Généré par calculateur | TMATS, événements d'enregistrement, index | Rend le fichier auto-descriptif et navigable |
| PCM | Trames de télémesure, souvent le flux émis en RF | Décommuté en paramètres au sol |
| Temps | Temps absolu IRIG-B, GPS ou PTP | Rattache le compteur de l'enregistreur à l'UTC |
| Bus avioniques | MIL-STD-1553, ARINC 429, CAN | Horodatage au message, trafic bus en contexte |
| Analogique | Voies capteurs conditionnées | Vibrations, jauges, pression, température |
| Tout-ou-rien | États logiques et lignes discrètes | Événements, positions d'interrupteurs, commandes |
| Série / réseau | Liaisons UART, captures Ethernet | Avionique moderne et trafic charge utile |
| Vidéo et image | MPEG-2, H.264, images fixes | Cockpit, caméras extérieures, emports |
L'ensemble exact des types et sous-types évolue d'une édition du standard à l'autre. Un lecteur doit respecter la version d'en-tête qu'il rencontre plutôt que présumer d'une édition — et un fichier peut légitimement mêler un type propre à un constructeur et des types normalisés.
TMATS : l'enregistrement qui se décrit lui-même
TMATS est un ensemble de paires attribut/valeur en texte simple, organisé en groupes couvrant l'enregistrement en général, l'enregistreur lui-même, les structures de trames PCM, les bus, et les extensions propres au constructeur. Il est écrit comme premier paquet de l'enregistrement, ce qui rend un fichier Chapter 10 auto-descriptif : quelles voies existent, comment la trame PCM est construite, quelles sont les cadences et les pleines échelles.
En pratique, TMATS ne vaut que ce que vaut la configuration qui l'a produit. Le défaut classique est l'incohérence : une voie renommée après l'export de la configuration, une cadence modifiée sur la piste, une liste de paramètres qui ne correspond plus à la trame. Un bon outil d'analyse vous montre le TMATS et signale les écarts au lieu de lui faire silencieusement confiance.
Le temps : ce que tout le monde sous-estime
Le RTC de 48 bits à 10 MHz offre une résolution inférieure à la microseconde sur environ dix mois de comptage continu. C'est l'horloge propre de l'enregistreur et, seule, elle ne dit rien de l'UTC. Ce sont les paquets de temps absolu et les en-têtes secondaires qui la rattachent à une référence externe — IRIG-B, GPS ou PTP.
Deux enregistreurs à bord du même aéronef ne s'accordent que s'ils sont tous deux asservis à la même référence. Sinon, vous héritez d'un décalage fixe, invisible dans chaque fichier pris isolément et flagrant dès qu'on les superpose — et le trouver coûte généralement une campagne.
La même logique vaut à la relecture. Tout doit être reconstruit à partir du temps enregistré, jamais de l'ordre dans lequel les paquets sont lus ou reçus. Un outil qui trace chaque voie jusqu'à son propre dernier échantillon fera apparaître des décalages fantômes entre des courbes acquises au même instant.
De l'enregistrement embarqué à la station sol
- À bord, les unités d'acquisition numérisent capteurs et bus, et l'enregistreur écrit les paquets Chapter 10 sur un SSD interne ou une cartouche amovible.
- Pendant le vol, un sous-ensemble est généralement transmis en télémesure RF pour que le sol suive l'essai en direct.
- Ces mêmes paquets peuvent aussi être diffusés sur Ethernet, ce qui permet à une station sol de jouer le rôle de récepteur temps réel sur un banc ou en hall d'intégration.
- Après le vol, le fichier est déchargé par Ethernet ou par échange de cartouche, puis décommuté, visualisé, exporté et rapporté.
- Parce que le conteneur est normalisé, ce fichier reste lisible longtemps après le retrait de l'enregistreur — c'est la vraie raison pour laquelle les programmes l'imposent.
Les pièges classiques
- Prendre « conforme Chapter 10 » pour « interchangeable ». Vérifiez l'édition, et vérifiez quels types de données sont réellement utilisés.
- Négliger TMATS, puis reconstruire la description des paramètres à la main des mois plus tard.
- Mélanger les références de temps entre enregistreurs, ou entre enregistreur et station sol.
- S'appuyer sur des types de données propriétaires sans vérifier que votre chaîne d'analyse les lit.
- De très gros enregistrements sans index : chaque repositionnement devient un balayage complet du fichier.