Dérive d'horloge du Patriot et responsabilité sur le champ

Résumé

Le 25 février 1991, une batterie Patriot à Dhahran n'a pas réussi à suivre et intercepter un Scud irakien entrant. Le Bureau général de la comptabilité des États-Unis a conclu qu'un problème logiciel dans l'ordinateur de contrôle des armes produisait un calcul de suivi inexact qui s'aggravait avec le temps de fonctionnement continu. Le Scud a frappé une caserne de l'armée et le GAO a rapporté que 28 Américains ont été tués.
Le mécanisme technique était une conversion de temps à précision finie. Le système conservait le temps en dixièmes de secondes et convertissait une valeur d'horloge entière de plus en plus grande pour les calculs de fenêtre de portée. Ses registres 24 bits limitaient la précision de cette conversion. Après que la batterie de Dhahran a fonctionné pendant plus de 100 heures consécutives, l'erreur de temps accumulée était d'environ 0,3433 seconde et la fenêtre de portée prédite était déplacée d'environ 687 mètres.
L'erreur devenait déjà visible institutionnellement. Les données israéliennes reçues le 11 février montraient un décalage significatif de la fenêtre de portée après huit heures. Une modification logicielle compensatoire a été publiée le 16 février, et un message du 21 février avertissait les utilisateurs que des temps d'exécution très longs pouvaient décaler la fenêtre de portée. Pourtant, l'avertissement ne définissait pas « très long », les responsables supposaient que les batteries ne resteraient pas allumées assez longtemps pour échouer, et le logiciel modifié est arrivé à Dhahran le 26 février, un jour après l'attaque.
La responsabilité s'étend donc au-delà de l'arithmétique. Elle découle du contrôle de la représentation numérique, des hypothèses d'endurance, de l'analyse des anomalies, des limites opérationnelles, du contenu de l'avertissement, de l'autorité de redémarrage, de la distribution du logiciel, de la configuration de l'unité et de la preuve que l'action corrective est parvenue à la batterie avant qu'elle ne soit nécessaire. Une petite erreur de calcul est devenue catastrophique parce que le système de contrôle technique et opérationnel ne l'a pas limitée dans les conditions de déploiement.

Dhahran a transformé la disponibilité en un état critique pour la sécurité

La disponibilité logicielle est souvent traitée comme une preuve de fiabilité. Un système qui est resté disponible pendant des jours peut sembler plus digne de confiance que celui qui a récemment redémarré. La défaillance du Patriot à Dhahran révèle la possibilité inverse: le temps écoulé lui-même peut être un danger croissant. Si un calcul interne perd de la précision à mesure que la valeur de l'horloge augmente, le fonctionnement continu n'est pas neutre. Il modifie l'état du système même si aucun composant ne plante visiblement et qu'aucun opérateur ne voit d'alarme.

Le rapport de février 1992 du GAO a établi l'événement central. Le 25 février 1991, un système de défense antimissile Patriot opérant à Dhahran, en Arabie saoudite, n'a pas réussi à suivre et intercepter un Scud entrant. Le missile a frappé une caserne de l'armée américaine. Le GAO a rapporté que 28 Américains ont été tués. Son examen a été demandé pour déterminer si un problème logiciel était impliqué, quel était le problème et ce qui avait été fait pour le corriger.

La réponse du rapport était directe. Un problème logiciel dans l'ordinateur de contrôle des armes a conduit à un calcul de suivi inexact qui s'est aggravé plus le système fonctionnait longtemps. Au moment de l'incident, la batterie fonctionnait en continu depuis plus de 100 heures. L'inexactitude accumulée a amené le système à chercher au mauvais endroit la cible entrante.

Cette description est importante car elle distingue le cas d'une perte de puissance totale, d'un écran figé ou d'un crash conventionnel. La batterie Patriot est restée un système en fonctionnement. La dégradation dangereuse existait à l'intérieur d'un calcul utilisé pour décider où le traitement radar devait regarder ensuite. Un système peut donc être opérationnel au sens administratif—alimenté, doté en personnel et disponible—tout en devenant inapte opérationnellement pour une fonction de sécurité spécifique.

La question de la responsabilité n'est pas simplement de savoir pourquoi un ordinateur a représenté une fraction imparfaitement. Les machines binaires estiment régulièrement des quantités qui ne peuvent pas être exprimées exactement dans un nombre fixe de bits. La question plus difficile est de savoir pourquoi l'approximation a été autorisée à s'accumuler au-delà d'une limite sûre dans une mission de défense en conditions réelles, et pourquoi les organisations contrôlant le logiciel, les opérations et le support sur le terrain n'ont pas converti la limite connue en protection pour l'unité déployée.

Ce que le dossier officiel établit

Le rapport du GAO devrait rester l'autorité principale pour la conclusion sur le logiciel de Dhahran. Il ne s'agissait pas d'une anecdote de salle de classe rétrospective constituée de folklore. Le GAO a interviewé des responsables de la maintenance du logiciel Patriot, examiné les analyses de l'armée, étudié l'architecture et le langage assembleur, analysé les instructions machine associées à l'inexactitude, vérifié le calcul correctif et participé à une simulation au Patriot Software Test Facility. Le rapport indique que les responsables étaient généralement d'accord avec les faits présentés.

Cela ne signifie pas que le rapport règle toutes les controverses sur les performances du Patriot pendant la guerre du Golfe. Le bilan d'interception plus large du système est devenu l'objet de contestations politiques, techniques et factuelles. Les affirmations sur le fait que d'autres engagements ont détruit des ogives entrantes impliquent des preuves, des définitions et des questions causales différentes. Ces débats ne devraient pas être importés dans l'affaire du logiciel de Dhahran comme s'ils étaient interchangeables.

Pour cet incident, le GAO a décrit une chaîne plus étroite et bien étayée. L'ordinateur de contrôle des armes utilisait les informations de la cible provenant du radar. Un algorithme de fenêtre de portée calculait une zone où le système devrait ensuite chercher un Scud suspecté. Les données en dehors de cette zone calculée étaient filtrées, tandis que les informations à l'intérieur soutenaient le suivi, le ciblage et l'interception. La prédiction dépendait de la vitesse de la cible et de l'heure de la dernière détection radar.

L'horloge du système conservait le temps en dixièmes de secondes comme un entier. Les calculs de suivi nécessitaient que le temps et la vitesse soient exprimés comme des nombres réels. Parce que les registres de l'ordinateur étaient longs de 24 bits, la conversion de la valeur temporelle introduisait une perte de précision. L'effet augmentait à la fois avec la durée de fonctionnement et la vitesse de la cible. Le fonctionnement prolongé décalait la fenêtre de portée calculée par rapport à la position réelle de la cible.

Le GAO a ensuite relié le calcul au résultat sur le terrain. La batterie Alpha avait fonctionné en continu pendant plus de 100 heures. La fenêtre de portée s'est décalée si loin que la batterie n'a pas suivi le Scud entrant et ne l'a donc pas engagé. C'est la frontière causale officielle pour la défaillance logicielle. L'analyse peut en tirer des leçons de gouvernance, mais elle ne doit pas inventer des ordres de bataille supplémentaires, des motivations individuelles ou des décisions non documentées.

L'erreur numérique était petite par calcul et grande en contexte

L'arithmétique est souvent résumée par l'expression « erreur d'arrondi ». Cette expression est approximativement vraie mais incomplète sur le plan institutionnel. Elle suggère une divergence décimale inoffensive ou une erreur isolée d'un programmeur. Le risque réel venait de l'interaction entre la représentation, l'accumulation, la vitesse de la cible et l'utilisation continue.

Le système comptait le temps en unités d'un dixième de seconde. Un dixième n'a pas de représentation exacte finie en binaire, tout comme un tiers n'a pas de représentation exacte finie en décimal. Un ordinateur doit stocker une approximation. L'architecture de l'ordinateur Patriot limitait la précision disponible pour la conversion utilisée dans le calcul de suivi. Chaque conversion était proche de la valeur souhaitée, mais pas identique.

Le temps écoulé était représenté par un entier qui augmentait à mesure que le système restait allumé. Lorsque ce compteur d'horloge plus grand était converti à l'aide de l'approximation à précision limitée, la différence absolue entre le temps calculé et le temps réel augmentait également. Le logiciel n'avait pas besoin de devenir moins prudent d'un moment à l'autre. La même méthode de représentation générait une erreur opérationnelle plus grande car elle était appliquée à une valeur de temps écoulé plus grande.

L'annexe du GAO a quantifié la progression. Après une heure, le temps calculé était d'environ 0,0034 seconde de retard, correspondant à un décalage de la fenêtre de portée d'environ sept mètres. Après huit heures, le rapport indiquait une inexactitude temporelle d'environ 0,0275 seconde et un décalage d'environ 55 mètres. Après 20 heures, l'inexactitude était d'environ 0,0687 seconde et le décalage d'environ 137 mètres. À 100 heures, le calcul était d'environ 0,3433 seconde de retard et le décalage approximatif était de 687 mètres.

Ces chiffres montrent pourquoi « seulement une fraction de seconde » est le mauvais cadre de risque. Une fraction de seconde doit être évaluée par rapport à la vitesse de la cible et à la logique qui consomme la valeur temporelle. Le GAO a décrit les Scuds comme se déplaçant à environ Mach 5 dans ce contexte opérationnel. Une cible se déplaçant rapidement couvre une distance conséquente pendant un court intervalle de temps. Le travail de la fenêtre de portée était de restreindre l'endroit où le traitement radar devait regarder ensuite.

Une fois que l'erreur de prédiction a déplacé cette fenêtre suffisamment loin, la véritable cible pouvait tomber en dehors de la zone considérée comme pertinente.

Le résultat n'était pas simplement une estimation moins élégante. Cela a modifié ce que le système pouvait reconnaître comme la cible. Le calcul aidait à déterminer si un objet était identifié, suivi et considéré comme à portée de tir. Une approximation numérique se trouvait donc à l'intérieur d'une frontière décisionnelle avec des conséquences directes pour l'engagement.

C'est un principe de sécurité récurrent. L'ampleur de l'erreur ne peut être évaluée isolément de la fonction de transfert entre le calcul et l'action. Une petite erreur de temps peut être sans importance dans un traitement de paie et catastrophique dans l'évitement de collision, le dosage médical, le contrôle industriel ou le suivi de missiles. L'assurance technique doit traduire l'erreur numérique en effet de domaine dans l'état opérationnel le plus grave crédible.

Une hypothèse de conception est devenue une limite opérationnelle non déclarée

Le GAO a rapporté que le Patriot avait été conçu à l'origine comme un système de défense aérienne mobile. Son concept opérationnel antérieur anticipait le mouvement et seulement quelques heures de fonctionnement à un seul endroit. Pendant la guerre du Golfe, les batteries ont été placées dans des positions relativement permanentes pour protéger les actifs, le personnel et les civils des attaques de Scuds. Le système était également utilisé contre une classe de cibles et un profil de vol qui n'avaient pas défini sa mission originale.

Ce n'est pas la preuve que l'adaptation était intrinsèquement irresponsable. Les systèmes déployés sont souvent appelés à faire face à des menaces modifiées. C'est la preuve que l'assurance basée sur l'enveloppe opérationnelle originale ne peut pas suivre silencieusement le système dans une enveloppe différente. Un système mobile censé redémarrer ou se relocaliser toutes les quelques heures peut contenir des variables d'état dont le comportement à long terme n'a jamais été traité comme critique pour la sécurité. Une batterie maintenue disponible en continu pendant des jours crée une exigence d'endurance différente.

La dérive de l'horloge était donc aussi une défaillance d'interface entre les hypothèses de conception et la doctrine sur le terrain. Le logiciel intégrait une hypothèse sur la taille que le temps écoulé deviendrait. La pratique en temps de guerre a créé une valeur beaucoup plus grande. Aucun côté seul ne définit la sécurité. Le système est sûr seulement si le modèle opérationnel déployé reste dans l'enveloppe validée ou si le logiciel et les procédures sont modifiés avant que l'enveloppe ne s'étende.

Une limite de durée de fonctionnement qui n'existe qu'implicitement dans l'arithmétique n'est pas une limite efficace. Les opérateurs ne peuvent pas se conformer à un seuil qui ne leur a jamais été donné. Les commandants ne peuvent pas planifier la relève, les fenêtres de redémarrage ou la couverture chevauchante autour d'un nombre qui n'a pas été traduit en doctrine. Les équipes logistiques ne peuvent pas prioriser une modification logicielle si on ne leur dit pas quelles unités s'approchent d'un état dangereux.

L'affaire de Dhahran demande donc qui possédait l'enveloppe opérationnelle. Les mainteneurs de logiciels contrôlaient la connaissance du calcul. Le bureau de projet pouvait analyser les données d'anomalie et modifier le code. Les commandements opérationnels savaient comment les batteries étaient réellement utilisées. Les unités déployées contrôlaient la configuration immédiate et les actions de redémarrage dans le cadre de l'autorité et des conditions de menace qui leur avaient été données. La haute direction de l'armée contrôlait le système de diffusion des avertissements et des mises à jour.

La sécurité dépendait de la réconciliation de ces vues.

L'exigence pertinente n'était pas simplement « suivre les Scuds ». Elle était plus proche de « maintenir la précision de suivi requise pour la plus longue période de fonctionnement continu que le déploiement en temps de guerre peut exiger ». Si cette condition d'endurance avait été explicite, l'analyse d'erreur numérique, les tests de longue durée, les instructions sur le terrain et les rapports de configuration auraient pu être évalués par rapport à la même limite mesurable.

Les données israéliennes ont rendu le risque visible avant l'attaque

Le défaut n'est devenu connaissable seulement après Dhahran. Le GAO a décrit des preuves de terrain reçues avant l'incident. Le 11 février 1991, le bureau du projet Patriot a reçu des données israéliennes identifiant un décalage de 20 % de la fenêtre de portée radar après huit heures consécutives de fonctionnement. Les systèmes contrôlés par les Israéliens avaient utilisé des enregistreurs de données externes, fournissant des informations utiles à l'analyse de l'armée.

Les responsables du bureau de projet ont déclaré que le système ne suivrait pas un Scud lorsque le décalage de la fenêtre de portée atteignait 50 % ou plus. Parce que le décalage était proportionnel au temps de fonctionnement, le résultat de huit heures pouvait être extrapolé. Le GAO a rapporté qu'après environ 20 heures d'utilisation continue, le calcul de temps inexact devenait suffisamment grand pour que le radar regarde au mauvais endroit.

Cette séquence est un test classique d'escalade d'anomalie. Des preuves existaient, mais les preuves ne protègent un système que lorsqu'elles sont converties en une décision contrôlée. Le décalage initial de 20 % pouvait être décrit comme une marge dégradée plutôt qu'une défaillance immédiate. Pourtant, sa signification dépendait de la trajectoire de l'erreur. Une erreur croissante avec un seuil de défaillance connu nécessite une projection, pas seulement une observation.

Le GAO a rapporté que les responsables de l'armée croyaient initialement que l'expérience israélienne était atypique. Ils supposaient que les autres utilisateurs ne faisaient pas fonctionner les systèmes pendant huit heures ou plus à la fois. Cette croyance était une hypothèse opérationnelle, et elle était erronée pour la batterie Alpha à Dhahran. L'unité est finalement restée en fonctionnement continu pendant plus de 100 heures.

L'échec de gouvernance n'était pas que les responsables ignoraient toutes les preuves. Ils ont analysé les données, confirmé une perte de précision et apporté une modification logicielle. Le fossé était que l'anomalie n'a pas produit une réponse de sécurité complète et applicable sur le terrain avant que le correctif n'atteigne chaque unité exposée. Le GAO a déclaré que les responsables n'ont pas utilisé les données israéliennes pour déterminer combien de temps le Patriot pouvait fonctionner avant que le calcul inexact ne rende le système inefficace.

Cette distinction est importante. Le développement correctif et le contrôle des risques intérimaires sont des obligations séparées. Une fois qu'un correctif est en préparation, les organisations peuvent agir comme si le problème était sur la voie de la résolution. Une unité déployée reste exposée jusqu'à ce que la configuration corrigée soit installée ou qu'une atténuation efficace soit en place. Le temps entre la confirmation du défaut et l'installation à l'échelle de la flotte est lui-même un intervalle de risque géré.

L'avertissement n'a pas indiqué le seuil dont les opérateurs avaient besoin

Le 21 février, le bureau du projet Patriot a envoyé un message aux utilisateurs indiquant que des temps d'exécution très longs pouvaient décaler la fenêtre de portée et décaler la cible. Le message disait également qu'une modification logicielle était en cours d'envoi pour améliorer le ciblage. Le GAO a identifié une faiblesse décisive: le message ne précisait pas ce qui était considéré comme « très long ».

Un langage qualitatif peut communiquer une préoccupation sans permettre l'action. « Très long » peut signifier huit heures pour un analyste de logiciels, un jour pour un commandant ou plusieurs jours pour un équipage opérant sous une menace constante. Un avertissement opérationnel doit relier le danger à un état mesurable et à une réponse requise. Il doit dire quand le risque devient inacceptable, ce que l'unité doit faire, qui peut autoriser l'action et comment la conformité est enregistrée.

Les responsables de l'armée ont dit au GAO qu'ils présumaient que les utilisateurs ne feraient pas fonctionner les batteries en continu pendant des périodes assez longues pour échouer, donc ils ne croyaient pas qu'une guidance plus détaillée était nécessaire. Cette présomption illustre pourquoi la conception des avertissements ne peut pas reposer sur la même hypothèse impliquée dans le danger. Si la pratique sur le terrain est incertaine, le processus d'avertissement doit la vérifier.

L'accusé de réception devrait inclure la disponibilité actuelle de l'unité, la version du logiciel et l'atténuation prévue, pas seulement la confirmation qu'un message a été reçu.

L'état réel de la batterie de Dhahran—plus de 100 heures de fonctionnement continu—n'était pas une bordure subtile autour du point de perte de suivi projeté de 20 heures. Il était bien au-delà. Un système de contrôle capable de faire correspondre les avertissements à l'état des unités aurait dû identifier la batterie Alpha comme urgente.

C'est là que la responsabilité devient factuelle. Il ne suffit pas de montrer que le quartier général a transmis un message général. La preuve pertinente est de savoir si l'unité exposée a reçu une limite intelligible dans le temps, compris sa conséquence, avait l'autorité et l'opportunité d'agir, et a signalé son achèvement. Les journaux de transmission prouvent seulement le début de cette chaîne.

Les avertissements pour les logiciels critiques pour la sécurité devraient être des directives opérationnelles versionnées. Ils ont besoin d'un identifiant de défaut, des configurations affectées, d'un déclencheur observable, d'un état sûr maximal, d'une atténuation, d'un rôle responsable, d'une date limite, d'une confirmation de réception et d'une preuve de clôture. Lorsque le seuil dépend du temps, l'avertissement devrait également exiger le signalement de la disponibilité actuelle. Sinon, la variable de risque centrale reste invisible pour l'organisation qui essaie de la contrôler.

Le redémarrage était une mesure d'atténuation, mais pas un système de contrôle complet

Le GAO a rapporté que le redémarrage du système Patriot toutes les quelques heures pouvait éliminer les décalages significatifs de la fenêtre de portée en réinitialisant l'horloge de l'ordinateur à zéro. Il a décrit le redémarrage comme prenant environ 60 à 90 secondes. En termes purement techniques, c'était une atténuation simple pour l'erreur de temps écoulé accumulée.

Sur le plan opérationnel, « il suffit de redémarrer » ne s'exécute pas tout seul. Une batterie de défense aérienne existe pour fournir une protection continue. Même une courte interruption peut devoir être coordonnée en fonction des alertes en cours, de la couverture d'autres batteries, de l'autorité de commandement et de la charge de travail de l'équipage. Le même rapport notait que l'installation de modifications logicielles nécessitait l'arrêt des systèmes pendant au moins une à deux heures, une interruption beaucoup plus longue avec des implications évidentes pour la planification.

Cela n'établit pas qu'un redémarrage à un moment particulier était impossible ou que les opérateurs ont refusé un ordre disponible. Les preuves publiques dans l'ensemble de sources ne soutiennent pas cette affirmation. Cela montre pourquoi une atténuation doit être traduite en doctrine avant de pouvoir être créditée comme un contrôle.

Un contrôle de redémarrage crédible identifierait une disponibilité maximale en dessous du seuil dangereux, avertirait à mesure que cette limite s'approche, spécifierait qui ordonne le redémarrage, coordonnerait la couverture temporaire, vérifierait que l'horloge s'est réinitialisée et enregistrerait la nouvelle heure de début. Si la protection continue rend le redémarrage inacceptable, l'organisation doit fournir une capacité de chevauchement ou accélérer l'installation du logiciel corrigé. Le danger ne peut pas être géré en espérant que les équipes de terrain déduisent une procédure d'un avertissement imprécis.

L'existence d'une atténuation techniquement facile peut parfois affaiblir la réponse institutionnelle. Les décideurs peuvent supposer que quelqu'un près du système peut résoudre le problème de manière informelle. Cette hypothèse transfère la responsabilité sans transférer les instructions, l'autorité ou les preuves. Dans un dossier de sécurité, une atténuation compte seulement lorsqu'elle est réalisable dans les conditions opérationnelles et démontrablement mise en œuvre.

Le correctif logiciel existait avant l'attaque mais est arrivé après

Après avoir analysé les données israéliennes, le bureau du projet Patriot a développé une modification logicielle pour compenser le calcul de temps inexact et permettre des temps d'exécution prolongés. Le GAO a rapporté que la version modifiée a été publiée le 16 février 1991. Elle est arrivée à Dhahran le 26 février—le lendemain de l'attaque fatale.

Les responsables de l'armée ont attribué le retard de distribution au temps nécessaire pour organiser le transport aérien et terrestre vers tous les emplacements Patriot dans un environnement de guerre. Ce contexte est pertinent. Livrer des supports logiciels physiques, un support technique ou des changements de configuration contrôlés à travers un théâtre d'opérations n'est pas équivalent à distribuer une mise à jour grand public de routine. Mais la difficulté opérationnelle n'efface pas l'exposition. Elle définit l'exigence logistique que le processus de sécurité doit gérer.

L'intervalle de neuf jours entre la publication et l'incident de Dhahran devrait être traité comme une fenêtre de risque de configuration. Pendant cette fenêtre, certaines unités restaient sur un logiciel connu pour avoir un problème de suivi sensible à la durée. Un processus mature maintiendrait un inventaire en direct des batteries affectées, de leurs versions logicielles, de la disponibilité actuelle, de la criticité de la mission, du statut d'expédition de la mise à jour et de l'atténuation intérimaire.

La priorité devrait suivre le risque, pas seulement une séquence de distribution standard. Une unité déjà au-delà de la durée de fonctionnement sûre projetée justifierait une attention immédiate. Si une version corrigée ne pouvait pas arriver rapidement, le système de commandement devrait appliquer un calendrier de redémarrage ou une autre mesure approuvée. Chaque unité devrait passer par des états explicites: affecté, averti, atténué, mise à jour expédiée, mise à jour reçue, installée, vérifiée fonctionnellement et clôturée.

L'affaire de Dhahran précède les opérations logicielles livrées par réseau telles qu'elles sont maintenant couramment comprises, mais le problème de responsabilité reste actuel. Un fournisseur ou un bureau de projet peut publier un correctif alors que la base installée reste vulnérable. « Correctif disponible » n'est pas la même chose que « risque éliminé ». Les organisations responsables des systèmes à haute conséquence ont besoin de preuves au dernier kilomètre.

La même logique s'applique aux hôpitaux, aux usines industrielles, aux réseaux de sécurité publique et aux infrastructures critiques. Un code correctif assis au quartier général ne protège pas un système distant. La sécurité dépend du temps de distribution, de l'autorité locale, de l'opportunité d'installation, des tests de compatibilité et de la preuve de la configuration résultante.

L'enregistrement limité des performances a affaibli l'apprentissage

Le GAO a également décrit une contrainte de preuve. Le Patriot n'avait pas d'enregistreur de données internes intégré qui conservait des informations détaillées sur les performances. Des enregistreurs externes portables étaient disponibles, mais les commandants américains ont décidé de ne pas les utiliser par crainte que les enregistreurs ne provoquent un arrêt imprévu du système. Les commandants israéliens ont utilisé des enregistreurs et fourni des données qui ont aidé à révéler l'anomalie de la fenêtre de portée.

La décision présente un véritable compromis de sécurité. Ajouter une instrumentation à un système d'armes en conditions réelles peut créer son propre risque. Un enregistreur qui pourrait perturber le fonctionnement ne peut pas être traité comme inoffensif. Pourtant, refuser de collecter des données a aussi un coût: la dégradation peut rester invisible, l'analyse des anomalies devient plus lente et la reconstruction après l'événement devient moins certaine.

L'ingénierie responsable exige que ce compromis soit fait explicitement. Si l'enregistreur préféré est trop risqué pour une utilisation de routine, une voie de preuve alternative est nécessaire. Cela pourrait inclure une instrumentation passive validée indépendamment, une collecte de diagnostic programmée, une relecture en laboratoire utilisant des états de longue durée représentatifs, un enregistrement redondant sur des batteries sélectionnées ou un plan formel pour capturer les données d'anomalie sans interférer avec l'engagement.

Le point important n'est pas que les commandants devraient toujours choisir plus de télémétrie. C'est qu'un système à haute conséquence s'adaptant à une nouvelle cible et à un nouveau modèle opérationnel a besoin d'un système d'apprentissage défini. Pendant la tempête du désert, le logiciel a été modifié à plusieurs reprises à mesure que l'expérience opérationnelle s'accumulait. Le GAO a rapporté six modifications logicielles entre août 1990 et février 1991. L'adaptation rapide augmente l'importance de preuves de performance fiables et de traçabilité de la configuration.

Sans bons enregistrements, les organisations dépendent davantage des rapports des utilisateurs, des hypothèses et des observations isolées. Cela rend plus facile de rejeter une anomalie comme atypique et plus difficile de déterminer si un changement a fonctionné sur l'ensemble de la flotte. La collecte de preuves fait donc partie du système de protection, pas seulement une ressource pour les historiens après une défaillance.

La responsabilité découle du contrôle pratique

Aucun rôle unique ne contrôlait chaque maillon de la chaîne de Dhahran. C'est précisément pourquoi un modèle de responsabilité systémique est nécessaire. La responsabilité distribuée ne devrait pas devenir une responsabilité diluée.

L'ingénierie logicielle et matérielle contrôlait les choix de représentation, la connaissance des limitations 24 bits, l'algorithme correctif et la vérification du calcul modifié. Leur obligation n'était pas de garantir la perfection mathématique. Elle était d'identifier la limite d'erreur sur la plage de fonctionnement crédible et de montrer que le suivi restait dans la tolérance requise.

Le bureau du projet Patriot contrôlait l'analyse des anomalies, la maintenance du logiciel et des parties importantes de l'avertissement et de la distribution. Une fois que les données israéliennes ont montré une dégradation, le bureau était en position de convertir l'observation en une limite opérationnelle, une version corrective et une action prioritaire sur le terrain. Le récit du GAO montre qu'il a développé un correctif et communiqué un avertissement. L'analyse de la responsabilité demande pourquoi ces actions n'ont pas constitué une protection en temps opportun à Dhahran.

Le leadership opérationnel contrôlait la doctrine et la connaissance de la manière dont les batteries étaient réellement utilisées. Si les systèmes restaient actifs en continu pendant des jours, ce fait devait atteindre les personnes évaluant les hypothèses d'endurance. Les commandements contrôlaient également si les redémarrages, les temps d'arrêt pour mise à jour et la protection par chevauchement pouvaient être planifiés.

La chaîne de distribution du logiciel et de soutien au théâtre contrôlait le mouvement de la version modifiée vers les emplacements déployés. Dans un environnement de guerre, les retards de transport peuvent être compréhensibles, mais ils restent une partie du risque du système. La performance logistique devrait être mesurée par rapport à l'urgence du danger.

Le leadership de l'unité et les opérateurs contrôlaient les actions locales dans le cadre des ordres, des informations et de l'autorité dont ils disposaient. Ils ne devraient pas être tenus pour seuls responsables de n'avoir pas déduit un seuil non spécifié. Inversement, un processus de sécurité doit définir les preuves requises au niveau de l'unité: journaux de disponibilité, accusé de réception de l'avertissement, enregistrement du redémarrage, version installée et vérification fonctionnelle.

L'armée et le leadership de la défense contrôlaient le système de gouvernance plus large: critères de préparation, canaux de rapport, autorité de déploiement, examen indépendant et l'équilibre entre disponibilité et temps d'arrêt correctif. La responsabilité institutionnelle se situe à ce niveau car les équipes locales ne peuvent pas créer une visibilité de configuration à l'échelle de la flotte ou réécrire la politique d'avertissement par elles-mêmes.

Le rôle du fabricant devrait également être délimité par des preuves. Le dossier source soutient la discussion sur la maintenance du logiciel et la correction technique, mais il ne justifie pas de traiter un programmeur ou une entreprise comme la cause complète. La défaillance opérationnelle est issue d'un défaut technique interagissant avec l'architecture du système, les conditions de mission modifiées, les hypothèses sur la disponibilité, le contenu d'avertissement incomplet et le déploiement retardé de la correction.

Cette répartition en couches est plus exigeante que de désigner un coupable. Elle exige que chaque propriétaire produise des preuves pour le contrôle qu'il détenait. L'ingénierie produit une analyse d'erreur et des résultats de test. Le bureau de projet produit des décisions de danger et des enregistrements de publication. Le commandement produit une doctrine opérationnelle et une visibilité sur l'état des unités. La logistique produit des preuves de livraison. Les unités produisent une confirmation de configuration et d'atténuation. La surveillance vérifie que la chaîne se ferme avant que l'exposition ne se poursuive.

L'affaire n'est pas un verdict sur chaque engagement du Patriot

L'efficacité plus large du Patriot pendant la guerre du Golfe a été contestée. Le témoignage du GAO, l'analyse technique des politiques et les rapports publics ultérieurs ont remis en question les affirmations officielles de succès et examiné la difficulté d'établir la destruction des ogives. D'autres parties ont défendu les performances du système. Ces débats sont un contexte pertinent pour la qualité des preuves, mais ils ne sont pas nécessaires pour gonfler la conclusion sur la dérive d'horloge de Dhahran.

L'affaire spécifique a son propre dossier officiel: une batterie n'a pas réussi à suivre et engager un Scud entrant parce qu'un calcul de temps inexact avait augmenté pendant le fonctionnement prolongé. Garder la limite étroite améliore la responsabilité. Elle empêche une défaillance logicielle documentée de devenir un proxy rhétorique pour chaque affirmation concernant le système d'armes.

La même discipline s'applique au rapport sur les victimes. Le rapport de Dhahran du GAO indique que le Scud a frappé une caserne de l'armée et tué 28 Américains. Ce chiffre peut être attribué au GAO. L'article ne devrait pas ajouter un nombre précis de blessés, une séquence détaillée à l'intérieur de la caserne ou des affirmations sur les actions de réponse individuelles à moins que des preuves tout aussi fiables ne les soutiennent.

Le dossier n'établit pas non plus de faute intentionnelle. Les preuves soutiennent les conclusions sur les hypothèses, les limites de calcul, la spécificité de l'avertissement et le calendrier des mises à jour. Elles ne soutiennent pas les allégations de sabotage, de conduite criminelle ou de décision délibérée d'exposer l'unité à un résultat mortel connu.

Il est également important de ne pas décrire chaque calcul à précision finie comme un défaut. L'approximation est inhérente à l'informatique. Le défaut réside dans l'utilisation d'une approximation dont l'erreur accumulée dépasse la tolérance du système dans des conditions opérationnelles crédibles sans détection ni contrôle efficaces.

Enfin, l'affaire ne devrait pas être réduite à une erreur de l'opérateur. Le GAO a rapporté que les responsables présumaient que les utilisateurs ne feraient pas fonctionner les batteries pendant de très longues périodes, alors que la réalité sur le terrain à Dhahran était de plus de 100 heures de fonctionnement continu. Ce décalage est un problème d'interface institutionnelle. Les opérateurs font partie du système, mais ils ne peuvent pas imposer une limite que l'ingénierie et le commandement n'ont pas rendue explicite et actionable.

Ce qu'un système de contrôle plus fort exigerait

Les leçons les plus utiles de Dhahran sont concrètes. « Utiliser plus de précision » est une réparation, mais ce n'est pas un programme de gouvernance complet.

Définir la tolérance numérique en termes opérationnels

Les exigences devraient indiquer l'erreur de prédiction maximale autorisée à la durée de disponibilité la plus longue crédible et à la vitesse de cible la plus élevée pertinente. Elles devraient identifier le point auquel la fenêtre de portée ne fournit plus la probabilité de suivi requise. Une décision sur la largeur de bit devient révisable seulement lorsqu'elle est traduite en effet physique.

Les ingénieurs devraient calculer l'erreur accumulée dans le pire cas, pas seulement l'erreur par conversion. Les tests devraient exercer les horloges près et au-delà des limites d'endurance. Si le logiciel utilise le temps écoulé dans plusieurs fonctions, chaque chemin a besoin d'un budget d'erreur.

Rendre l'enveloppe opérationnelle explicite

L'enveloppe validée devrait inclure la durée de fonctionnement continu, les caractéristiques de la cible, les hypothèses de redémarrage, la version du logiciel et les conditions environnementales. Lorsque le déploiement passe d'une utilisation mobile de courte durée à une préparation fixe et continue, le changement devrait déclencher une réévaluation formelle.

Une limite de disponibilité appartient aux ordres techniques, aux affichages des opérateurs, aux tableaux de bord de préparation et à la planification des commandements. Elle ne devrait pas rester découvrable seulement grâce à une analyse ultérieure des instructions en assembleur.

Instrumenter la disponibilité et la marge

Le système devrait exposer l'état pertinent pour la sécurité. Les opérateurs et les commandements de soutien ont besoin d'une mesure précise du temps d'exécution continu et d'une indication claire de la marge de suivi restante. Les avertissements devraient s'intensifier avant la limite, pas après que le calcul devient inefficace.

L'instrumentation doit elle-même être testée pour la non-interférence. Si l'enregistrement crée un risque inacceptable, le programme a besoin d'un autre mécanisme de preuve validé. Choisir de ne pas enregistrer ne peut pas signifier choisir de ne pas apprendre.

Séparer le développement correctif de l'atténuation intérimaire

Lorsqu'un changement logiciel permanent est en cours, un contrôle de danger intérimaire a encore besoin d'un propriétaire. L'atténuation peut être un redémarrage programmé, une disponibilité maximale réduite, une couverture par chevauchement, un mode de mission restreint ou une autre mesure technique. Elle a besoin d'une faisabilité documentée et d'une preuve d'achèvement.

Le risque reste ouvert jusqu'à ce que chaque unité affectée soit protégée, pas seulement jusqu'à ce que le code soit publié.

Utiliser des avertissements quantifiés

Les messages de sécurité devraient remplacer des expressions telles que « très long » par des seuils. Ils devraient identifier les versions affectées, énoncer la conséquence, exiger une action spécifique et nommer l'autorité responsable de cette action. Si le seuil dépend de l'état actuel, les unités devraient signaler cet état avec leur accusé de réception.

Un message n'est pas clos lorsqu'il quitte le quartier général. La clôture nécessite un accusé de réception, une compréhension, une action et une vérification.

Maintenir une visibilité sur la configuration de la flotte

Les responsables du programme et des opérations devraient savoir quelle version logicielle chaque batterie exécute, quand elle a redémarré pour la dernière fois, quels avertissements elle a accusés et si le changement correctif a passé un contrôle fonctionnel local. Cet inventaire devrait être assez actuel pour prioriser le risque pendant les opérations rapides.

Les enregistrements de configuration empêchent également un mode de défaillance courant dans lequel les organisations supposent qu'un correctif publié a supprimé l'exposition partout.

Planifier des fenêtres de maintenance sûres

Redémarrer ou installer un logiciel peut interrompre la protection. Cela crée un problème opérationnel légitime, pas une excuse pour laisser le danger non géré. Les commandements devraient planifier une couverture par chevauchement, une maintenance échelonnée ou une autre mesure de continuité. L'autorité d'accepter le bref risque de maintenance par rapport au risque croissant du calcul devrait être explicite.

Tester la mission réellement effectuée

Les tests d'endurance devraient refléter le fonctionnement continu en temps de guerre, pas seulement les sessions plus courtes imaginées dans le concept original. Les modèles de cible devraient refléter la vitesse et le comportement des menaces que le système est chargé d'engager. Les tests doivent couvrir l'interaction du temps d'exécution, de la représentation numérique et de la logique de la fenêtre de portée.

Le GAO a rapporté qu'un test d'endurance a été mené plus tard pour s'assurer que les temps d'exécution prolongés ne créaient pas d'autres difficultés système. Le contrôle durable est de rendre cette classe de test routinière avant que les conditions de déploiement n'exposent la limite.

Préserver la vérification indépendante

Les corrections critiques pour la sécurité devraient être vérifiées indépendamment par rapport à la limite d'erreur énoncée et au scénario opérationnel. Le GAO lui-même a recalculé la correction dans le cadre de son examen. Les programmes ne devraient pas avoir besoin d'un audit post-défaillance pour découvrir si l'arithmétique de longue durée a été évaluée.

L'examen indépendant devrait également évaluer l'adéquation de l'avertissement, la distribution sur le terrain et la clôture de la configuration. La vérification du logiciel seule ne peut pas montrer que la version corrigée a atteint le système exposé.

Les contrefactuels clarifient les contrôles mais ne réécrivent pas l'histoire

Plusieurs contrefactuels aident à identifier les contrôles manquants. Si la conversion de temps avait maintenu une précision adéquate à 100 heures, le déplacement spécifique de la fenêtre de portée décrit par le GAO ne se serait pas développé de la même manière. Si la batterie avait été redémarrée dans un intervalle de sécurité imposé, l'horloge interne serait revenue à zéro et l'erreur accumulée aurait été réduite. Si le logiciel modifié était arrivé et avait été installé avant le 25 février, le calcul compensatoire aurait peut-être résolu le problème connu.

Ce sont des propositions axées sur le contrôle, pas des affirmations qu'un seul changement aurait certainement empêché toutes les conséquences de l'attaque. L'interception est un processus physique et opérationnel complexe. Les preuves publiques établissent pourquoi la batterie Alpha n'a pas suivi et engagé ce Scud; elles ne garantissent pas le résultat d'un engagement hypothétique.

Un autre contrefactuel concerne le contenu de l'avertissement. Une directive quantifiée émise le 21 février, adaptée à la disponibilité actuelle de chaque unité affectée et soutenue par une autorité de redémarrage, aurait rendu le risque plus actionable. Savoir si elle aurait été exécutée à Dhahran dépend de faits qui ne sont pas entièrement établis ici. La leçon est que l'avertissement qualitatif réel n'a pas fourni le seuil dont les opérateurs avaient besoin.

Le but de l'analyse contrefactuelle est de relier chaque point de défaillance à un contrôle testable. Elle ne devrait pas être utilisée pour créer une certitude après coup ou pour effacer les contraintes des opérations en temps de guerre.

Les systèmes modernes accumulent encore des risques temporels invisibles

L'architecture dans le rapport du GAO reflète son époque, mais le modèle de risque est contemporain. Les systèmes à longue durée d'exécution accumulent de l'état: les compteurs augmentent, les horloges tournent, les baux expirent, les certificats vieillissent, les décalages dérivent, les files d'attente s'approfondissent et les approximations numériques se composent. Un service peut passer des tests courts et encore échouer après des jours ou des mois de disponibilité.

Le matériel moderne offre des registres plus larges et une plus grande précision, mais la largeur seule ne garantit pas la sécurité. Le logiciel convertit encore entre les unités de temps, les domaines d'horloge et les types numériques. Les systèmes distribués combinent des horloges murales, des horloges monotones et des horodatages distants. Les dispositifs embarqués peuvent économiser de la mémoire ou de la puissance de traitement. La sécurité dépend de l'analyse de la représentation réelle et de la durée de la mission.

Les hypothèses opérationnelles continuent également de changer plus rapidement que les systèmes. Une plateforme conçue pour une utilisation intermittente peut devenir une infrastructure disponible en continu. Un outil de sauvegarde peut devenir un service principal. Un déploiement régional peut devenir mondial. Un système construit pour une charge de travail peut être exposé à un environnement plus rapide ou plus variable. Chaque changement peut invalider une limite implicite.

Le problème de la chaîne d'avertissement est tout aussi actuel. Les équipes de sécurité et de sûreté publient régulièrement des avis alors que les opérateurs distants restent sur des versions vulnérables. Les tableaux de bord peuvent montrer qu'un correctif existe sans prouver l'installation. Les messages peuvent décrire le risque qualitativement sans énoncer de date limite ou d'état affecté. Dhahran démontre pourquoi la preuve au dernier kilomètre est importante.

La leçon la plus profonde est que le temps doit être gouverné comme une donnée. Son unité, sa précision, son époque, sa valeur maximale, son comportement de réinitialisation et son chemin de conversion sont des exigences d'interface. La disponibilité est une entrée dans le dossier de sécurité. Si l'erreur augmente avec le temps, chaque heure de fonctionnement consomme de la marge.

Questions pour la surveillance et la direction

Les dirigeants responsables des logiciels à haute conséquence devraient être capables de répondre à un ensemble compact de questions.

Quelle est la durée d'exécution continue la plus longue crédible, et le système a-t-il été testé au-delà? Quels calculs accumulent de l'erreur avec le temps écoulé? Quel effet physique ou de service découle de l'erreur dans le pire cas? Où est documentée la durée maximale sûre?

Qui reçoit les données d'anomalie du terrain, et qui décide si elles modifient l'enveloppe opérationnelle? Lorsqu'un danger est confirmé, qui possède l'atténuation intérimaire pendant qu'un correctif permanent est développé? Cette personne peut-elle ordonner un redémarrage ou une interruption de service?

Un avertissement contient-il un seuil mesurable, les versions affectées et une action requise? L'accusé de réception indique-t-il l'état réel de l'unité? Existe-t-il des preuves que l'action a eu lieu?

Le leadership peut-il identifier chaque configuration déployée, la disponibilité actuelle et le statut de mise à jour? Combien de temps faut-il au logiciel correctif pour atteindre le site le plus éloigné? La priorité de distribution est-elle liée à l'exposition?

Quelles preuves sont collectées pendant le fonctionnement? L'instrumentation a-t-elle été testée pour la non-interférence? Si l'enregistrement direct est dangereux, quelle alternative soutient la détection des anomalies et la reconstruction indépendante?

Qui vérifie indépendamment non seulement le changement de code mais aussi la clôture sur le terrain? Quel changement de condition fait passer le statut de « correctif publié » à « risque éliminé »?

Ces questions transforment une célèbre histoire de logiciel en un modèle opérationnel responsable. Elles demandent des artefacts, des propriétaires et des seuils plutôt que des déclarations de confiance.

Conclusion

La défaillance du Patriot à Dhahran a été causée par un problème de temporisation logicielle, mais « erreur d'arrondi » est une description trop petite de la défaillance institutionnelle. Une précision limitée a créé une erreur qui augmentait avec la disponibilité. Les conditions de déploiement modifiées ont poussé le système bien au-delà de la durée de fonctionnement supposée par les responsables. Les données de terrain ont exposé la dégradation. Une correction logicielle a été publiée et un avertissement a été envoyé, mais l'avertissement manquait d'un seuil de temps utilisable et la version corrigée est arrivée à Dhahran après l'attaque.

Le dossier du GAO soutient une allocation disciplinée des responsabilités. L'ingénierie possédait le comportement numérique et sa vérification. Le bureau de projet possédait la conversion des anomalies, l'avertissement et la correction. Le leadership opérationnel possédait la doctrine et la visibilité sur l'utilisation continue. La logistique possédait la livraison de la configuration modifiée. Les unités déployées avaient besoin d'une autorité et d'instructions explicites pour l'atténuation. La haute direction possédait le système de preuves reliant ces contrôles.

La leçon durable n'est pas que les ordinateurs doivent éviter l'approximation. Elle est que les organisations doivent limiter l'approximation dans les conditions qui comptent. Le temps écoulé, la version logicielle, l'accusé de réception de l'avertissement et l'action corrective doivent devenir des objets de contrôle visibles. Dans un système protégeant la vie humaine, une limite de sécurité ne peut pas rester cachée dans le développement binaire d'une fraction.

Patriot a fait de la dérive d'horloge un test de responsabilité pour les logiciels de champ de bataille