Acquisition & enregistrement
Intégrité des données : détecter pertes, dérives et enregistrements tronqués
Le fichier existe, il s'ouvre, et les courbes paraissent plausibles. Rien de tout cela ne constitue une preuve. Voici la liste de ce qui peut clocher dans un enregistrement, et lesquels vous pouvez réellement détecter.
Le fichier existe. Et alors ?
La fin d'une sortie produit un fichier de la taille attendue, qui s'ouvre sans se plaindre et trace des courbes qui ressemblent à l'appareil. Chacun de ces faits est compatible avec un enregistrement qui a perdu un tiers d'une voie, dérivé d'une demi-seconde par rapport à une autre unité, ou capté une fréquence repliée qui n'a jamais existé.
La bonne nouvelle, c'est qu'un conteneur bien conçu porte les preuves nécessaires : un motif de synchronisation sur chaque bloc, un compteur de séquence par voie, des longueurs, des sommes de contrôle et un horodatage. Les anomalies sont détectables. Ce qui manque, en général, c'est quelqu'un pour regarder.
La taxonomie — et ce que chacune vous coûte
faire défiler
| Anomalie | Cause probable | Ce que vous perdez | Détectable ? |
|---|---|---|---|
| Perte de synchro trame | liaison dégradée, débit modifié, motif trop court | tout de la perte au reverrouillage | oui — compteur de synchro |
| Rupture de séquence | paquet perdu, tampon saturé, écriture en retard | des échantillons, sans trou visible | oui — numéro de bloc |
| Somme de contrôle en défaut | corruption sur le support ou la liaison | une donnée fausse qui paraît valide | oui — si le conteneur en porte |
| Bloc vide inattendu | voie absente, capteur débranché, module en défaut | la voie entière | oui — face au bloc de réglage |
| Fichier tronqué | coupure, support saturé | l'index, parfois la fin | oui — à l'ouverture |
| Écrêtage | étendue d'entrée trop juste | l'amplitude réelle des crêtes | oui — compteur de saturation |
| Décalage entre unités | pas de référence commune | toute analyse comparative | seulement si on le cherche |
| Repliement | filtre non adapté à la cadence | rien — la donnée paraît propre | non, jamais après coup |
Lisez la dernière colonne d'abord. Six de ces huit anomalies se signalent à qui contrôle. Les deux dernières, non — et ce sont celles qui invalident des conclusions plutôt que de perdre des données, d'où le fait qu'elles relèvent de la discipline d'avant vol et non du rapport d'après vol.
Les pertes de synchro, et ce qu'elles veulent dire
Sur un flux télémesuré, une perte de synchronisation est un événement de liaison : le récepteur a perdu le verrouillage de trame et tout ce qui précède le reverrouillage est perdu. C'est normal, cela arrive à chaque campagne, et l'information utile est le motif — à quelle fréquence, pendant combien de temps, et à quel moment du vol. Une grappe de pertes à chaque virage incliné est un problème d'antenne, pas un problème de données.
À l'intérieur d'un fichier enregistré, une perte de synchronisation veut dire autre chose et de plus grave : l'écriture a produit quelque chose que la lecture ne sait pas suivre. Cela désigne l'équipement ou le support plutôt que le trajet radio, et cela mérite une investigation plutôt qu'une note dans le journal.
Ruptures de séquence et blocs manquants
C'est l'anomalie qui se cache le mieux. Chaque voie porte son propre compteur de blocs, incrémenté à chaque bloc y compris les vides. Si le compteur saute, des blocs manquent — et comme chaque bloc restant porte son propre temps, le fichier se lit parfaitement : la courbe enjambe simplement le trou, et si le trou est court personne ne le voit.
Les causes sont généralement prosaïques et méritent d'être connues : un tampon débordé parce que le support a marqué une pause, une écriture arrivée en retard, un paquet réseau perdu entre une unité esclave et le maître. Toutes sont des problèmes de capacité ou de synchronisme, toutes s'aggravent quand le support se remplit, et toutes sont invisibles si l'on ne regarde pas le compteur.
faire défiler
Sommes de contrôle et corruption silencieuse
Une somme de contrôle est le seul mécanisme qui attrape une donnée présente, bien formée et fausse. Sans elle, un bit retourné sur le support ou en transit devient une valeur — plausible, au bon endroit, au bon instant.
D'où l'importance de savoir si votre conteneur en porte réellement une et la vérifie, et si votre lecteur la contrôle ou la saute pour aller plus vite. Un lecteur qui ignore silencieusement une somme de contrôle en défaut est pire qu'un lecteur qui n'en a pas, parce qu'il produit de la confiance.
La dérive temporelle, et pourquoi c'est la plus chère
Une anomalie de temps n'abîme pas une voie : elle abîme la relation entre les voies, c'est-à-dire là où réside l'ingénierie. Deux unités qui n'ont jamais été asservies à une référence commune produisent deux jeux de données cohérents chacun avec lui-même, séparés par un décalage qui n'apparaît dans aucun des deux fichiers.
La dérive est le même problème au ralenti : une unité en holdover après une perte de GPS s'écarte à la vitesse de son oscillateur, quelques millisecondes par heure sur un composant ordinaire. Sur une sortie de trois heures, c'est assez pour ruiner une mesure de phase et trop peu pour que quiconque le remarque.
La détection est possible, mais seulement si vous l'avez préparée : enregistrer la source de temps et son état avec les données, et injecter un événement commun sur toutes les unités avant le vol pour disposer d'une référence mesurée. Sans l'un de ces deux moyens, un décalage temporel est indétectable et définitif.
Deux contrôles, avant et après
L'intégrité n'est pas une activité d'analyse, c'est une activité d'exploitation, et sa place est dans deux procédures courtes plutôt que dans les bonnes intentions de quelqu'un.
Avant le vol : le bloc de réglage correspond à la liste de paramètres visée ; chaque voie configurée produit des données lors d'un essai sur établi ; les filtres anti-repliement correspondent aux cadences réellement attribuées ; un événement commun est injecté sur toutes les unités et les écarts sont mesurés ; le support a la place pour la sortie plus la marge.
Après le vol, avant que l'appareil ne revole : le fichier s'ouvre et se ferme proprement ; aucune voie ne manque face au bloc de réglage ; les pertes de synchronisation et les ruptures de séquence sont comptées et localisées ; les sommes de contrôle passent ; les compteurs de saturation sont lus ; et l'enregistrement est déchargé plutôt que laissé à l'écrasement.
La seconde procédure compte plus qu'il n'y paraît, car son objet n'est pas de valider les données. C'est d'attraper un défaut d'installation alors que l'appareil est encore au sol, pour que la sortie suivante ne le répète pas.
Ce que doit contenir un rapport d'intégrité
- Une ligne par voie, et non un verdict par fichier. Un enregistrement est rarement uniformément bon ou mauvais.
- Des anomalies classées par type, parce que le type indique où chercher — une liaison, un tampon, un support, une configuration.
- La position et la durée de chacune, pour qu'un analyste décide si elle touche le segment qui l'intéresse.
- Une comparaison au bloc de réglage, pour qu'une voie absente soit signalée et non supposée.
- Et un format stable, pour que deux rapports de deux campagnes se comparent et qu'une tendance se voie avant de devenir une panne.
La raison d'automatiser cela n'est pas la rigueur, c'est l'honnêteté. Un contrôle qu'un humain fait quand il a le temps est un contrôle qu'on saute précisément quand la campagne est chargée — c'est-à-dire précisément quand les anomalies arrivent.