Le logiciel du F-35

2

Je voudrais faire partager quelques réflexions et calculs de coin de table pour illustrer la difficulté de produire et de tester un logiciel complexe et temps réel de grande dimension. La taille du logiciel embarqué du F-35 est évaluée entre 8 et 10 millions de ligne de code selon les sources. C’est une taille gigantesque.

De tels logiciels existent au sol pour réaliser de la gestion classique, mais un logiciel embarqué est, normalement, beaucoup plus léger, en taille, et beaucoup plus complexe à mettre au point.

De plus il faut faire une ségrégation entre le logiciel «critique» et le logiciel normal car si, par exemple, le module «navigation» a une erreur fatale, il n’est pas envisageable que les commandes de vol ne répondent plus. Et il est bien évident que le logiciel critique demande plus de travail et de tests que le logiciel normal.

Une première difficulté vient de l’impossibilité d’augmenter indéfiniment la taille des équipes logicielles.

Ce point est illustré dans Les paradoxes de la productivité dans la production des logiciels de François Horn: «les mois et les hommes ne sont interchangeables que lorsqu’une tâche peut être divisée entre plusieurs travailleurs sans réclamer de communication entre eux» et «si n taches doivent être séparément coordonnées avec chaque autre tâche, l’effort augmente en n(n-1)/2. Dans des situations extrêmes ces activités supplémentaires font plus que compenser l’apport de travailleurs supplémentaires».

Pour contourner cette difficulté le même document donne une solution qui consiste à effectuer un important travail préalable au niveau de l’architecture du système pour le décomposer en modules plus petits qui doivent avoir une indépendance maximale.

Nous allons donc faire des hypothèses sur la modularité du logiciel du F-35 pour tenter d’en estimer la difficulté de réalisation et surtout de test.

Pour ce faire on peut estimer le nombre de calculateurs du système d’arme (c’est un premier niveau de modularité), la taille probable des équipes et la complexité probable du calculateur tactique (ou calculateur de mission c’est-à-dire celui qui coordonne tous les équipements).

Pour les estimations on doit utiliser des ratios en lignes de code, bien que ce soit critiquable, car c’est la seule donnée d’entrée dont on dispose.

Je pense qu’un tel système d’arme comporte entre 100 et 200 calculateurs. Pour ce qui est de la taille des équipes, chargées de réaliser un «module» on peut tabler sur 10 à 20 personnes travaillant pendant 10 ans. Il s’agit donc de gros «module» représentant une fonction déjà complexe.

Comme on est dans un projet complexe la productivité est réduite à 250 lignes de code par an et par personne en considérant les moyens totaux consacrés en un an au logiciel par le projet:

Ce taux de 250 lignes par an peut sembler un peu faible, mais c’est un taux qui ne compte que le logiciel embarqué, non compris le logiciel abandonné, tous les développements, les tests sur les bancs de tests, les améliorations et toute la maintenance.

Or pour le mettre au point il faut développer d’autres logiciels: on commence par faire un logiciel qui teste les interfaces, pour cela le calculateur tactique envoie les messages élémentaires relatifs à un équipement et vérifie que les réponses correspondent à ce qui est attendu. Ce programme doit être aussi simple que possible pour que sa mise au point soit facile, il est statique et ne teste que les échanges (en général sur un bus).

Il faut ensuite faire une simulation numérique de chaque équipement (on peut utiliser le programme de test des interfaces pour un premier niveau de mise au point de cette simulation) ces simulations serviront à l’évaluation validation du logiciel tactique. Il faut ensuite faire des programmes de stimulation des équipements : par exemple si on a une centrale à inertie il faut remplacer les accéléromètres et les gyromètres par des stimulations calculées par le calculateur de simulation, les injecter dans une centrale réelle branchée sur le bus afin de pouvoir tester l’intégration de celle ci au banc.

Il faut enfin faire une simulation générale qui produit des thèmes d’exercice et qui coordonne l’environnement général avec la simulation (ou la stimulation) de tous les équipements du système d’arme.

Sur ce banc les tests d’intégration vont beaucoup plus vite qu’en vol: on peut par exemple pour tester un module faire varier les configurations par software alors qu’en vol chaque configuration représente un vol différent. En plus sur le banc on peut tester les réactions du système d’arme aux différentes pannes des équipements ou de l’avion.

Une équipe produit en moyenne un «module» de 40 000 lignes de code. Pour un logiciel d’une taille de 10 millions de lignes cela fait 250 «modules» soit en moyenne 1 à 2 module par calculateurs.

Mais le calculateur tactique doit faire entre un million et un million et demi de lignes de code, c’est-à-dire entre 20 et 30, voir 35 «modules». Ces modules sont sans doute de grandes fonctions comme missiles air-air, missiles air-sol, suivi de terrain, radar, contre mesures, navigation, liaison tactique etc.

L’intégration de ce type de fonction à un niveau élémentaire peut se faire au banc mais l’intégration finale se fait obligatoirement en vol et là c’est très long car tous les autres modules doivent être présents et à un niveau de mise au point acceptable et qu’il faut tester un grand nombre de configurations différentes (c’est un avion multi rôles) et même le faire sur trois avions différents (versions A, B et C).

Lorsque nous avons 250 modules à réaliser avec chacun un planning de 10 ans et que parmi ces 250 modules 30 dépendent de tous les autres pour leur mise au point, il ne faut pas espérer tenir le planning. Même en supposant que des tests peuvent commencer sans que tout soit disponible, il me semble raisonnable de compter 15 ans pour la disponibilité complète des 250 modules, 5 ans pour les tests au banc et 10 ans pour les essais en vol ce qui fait 30 ans si tout le monde a bien fait son travail. Comme le programme a commencé en 2001, la date estimée pour un F-35 opérationnel nous amène à 2031.

Pour l’instant les essais en vol qui ont eu lieu concernent surtout l’avion lui-même mais très peu le logiciel de mission.

Du point de vue des essais en vol, en 2012, Lockheed Martin a dépassé ses objectifs de développement. Lockheed dit avoir réalisé 1167 vols et 9319 points de mesure en 2012 alors que le plan était de 988 vols et 8458 points. Sur les vols effectués, 926 étaient des vols ayant pour but d’élargir les domaines de vol des trois variantes de F-35, tandis que 241 étaient réalisés par les avions de mission/systèmes pour tester l’avionique et les capteurs.

Mais un rapport du directeur du DOT&E révèle que cela s’est fait en réalisant des tests prévus pour les années suivantes. Des anomalies matérielles et des retards de mise au point de logiciels ont empêchés le programme d’atteindre certains objectifs de test fixés pour 2012. Ces objectifs étaient pourtant nécessaires pour permettre le démarrage de la formation des pilotes de F-35. Ainsi, le programme avait terminé seulement 78 % des points de mesure prévues pour l’année.

L’ajout de points de mesure supplémentaires pour traiter de nouveaux problèmes, pour réaliser les tests de non-régression liées aux corrections apportées, et pour les tests réalisés en avance de phase, a augmenté le nombre des points de test à traiter de plus de 35 %. Le rapport du directeur du DOT&E pour l’année 2013, sans surprise, confirme la difficulté de la mise au point de ce logiciel.

Retraité, Richard Rutily a travaillé toute sa carrière dans des sociétés privées pour des contrats militaires ou de haute technologie et nécessitant une habilitation au Secret défense. Il a ainsi travaillé chez Dassault, Matra, EADS, Aérospatiale et Astrium.

Répondre