Le logiciel du F-35

[Picdelamirand-oil]

Le logiciel du F-35

C'est un sujet que j'ai déjà abordé et je voudrais en faire une synthèse dans une série de posts.

Je commencerais avec l'introduction de l'article que j'ai publié dans 45enord.ca/

http://www.45enord.ca/2014/05/le-logiciel-du-f-35/

Un logiciel embarqué est, normalement, beaucoup plus léger, en taille, et beaucoup plus complexe à mettre au point qu'un logiciel de gestion classique. 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 de façon à limiter les activités supplémentaires de coordination entraîné par la décomposition.

Cette introduction est là pour faire sentir que lorsqu'on a affaire à de gros logiciel complexes, on n'est pas libre du point de vue du planning, et on ne peut pas forcément diminuer le temps de développement en augmentant les ressources.

A propos du logiciel du F-35 on n'a qu'une information : sa taille, pour évaluer le temps de développement il existe des modèles assez sophistiqués, mais qu'on ne pourra pas utiliser par manque d'information. Avec seulement la taille on ne pourra utiliser que le modèle COCOMO. Mais vous verrez que c'est mieux que rien!

Modifié le 8 février 2017 par Picdelamirand-oil

[zx]

c'est du LM, ca risque d'être dur d'avoir d'autre sources, peut être le DOD

https://www.f35.com/about/life-cycle/software

Citation

 

F-35 software enables:

Flight controls

Radar functionality

Communications, navigation and identification

Electronic attack

Sensor fusion

Weapons deployment

A Block Development Approach

From the program’s outset, the software team has focused on developing six key software releases known as Blocks:

Block 1A/1B – Block 1 comprises 78 percent of the more than 8.3 million source lines of code required for the F-35’s full warfighting capability. Block 1A was the ready for training configuration while Block 1B provided initial multi-level security.

Block 2A – Block 2A is currently released to the F-35 fleet. It provides enhanced training including functionality for off-board fusion, initial data links, electronic attack and mission debrief. With Block 2A, nearly 86 percent of the required code for full warfighting capability is flying.

Block 2B – Block 2B provides initial warfighting capabilities, including but not limited to expanded data links, multi-ship fusion and initial live weapons. The U.S. Marines declared IOC in July 2015 with Block 2B. With Block 2B, more than 87 percent of the required code for full warfighting capability is flying.

Block 3i – Block 3i provides the same tactical capabilities as Block 2B. The principal difference between 2B and 3i is the implementation of new hardware, specifically the updated Integrated Core Processor. The Air Force declared IOC with Block 3i in August 2016. With Block 3i, 89 percent of code required for full warfighting capability is flying.

Block 3F – Block 3F provides 100 percent of the software required for full warfighting capability, including but not limited to data link imagery, full weapons and embedded training. Mission Systems Block 3F software development is 98 percent complete.

Current Software Development Status

As of October 2016, 100 percent of the required F-35 airborne software is written and being tested in 3F Flight Test. Additional ground based software, such as ALIS and Training Systems, is 95 percent complete.

 

 

 ALIS, don't keep us waiting: F-35 jet's software 'delayed'

And local sysadmins left to reset ground crews' 'dealer module' Toughbooks

https://www.theregister.co.uk/2017/01/12/f35_alis_software_delayed/

 

Modifié le 8 février 2017 par zx

[zx]

Une news pas trop vieille Mai 2016

F-35s failed 'scramble test' because of buggy software

https://www.theregister.co.uk/2016/05/02/f35s_failed_scramble_test_because_of_buggy_software/

Modifié le 8 février 2017 par zx

[prof.566]

Je suis en train d'écrire la dessus. C'est dramatique. En 3 lignes: le logiciel block 2B était instable. Qu'à cela ne tienne, on l'implémente quand même sur un nouveau hardware (processeur), des fois que ca marcherait mieux... Encore plus instable, bien sur. Tant pis, on y rajoute de nouvelles fonctions pour faire le 3F. MTBF de 0.4h, trop instable pour être utilisé pour des tests.. retour à la case 3I etc.

[zx]

Pentagon Tester: F-35 Still Has Serious Problems (Aout 2016)

http://www.popularmechanics.com/military/weapons/a22530/pentagon-tester-f-35-combat-testing-delays/

Citation

The Pentagon's director of operational testing, Michael Gilmore, stated in a memo obtained by Bloomberg that the F-35 is "actually not on a path toward success but instead on a path toward failing to deliver" the plane's full combat capabilities on time. Gilmore also said the plane is "running out of time and money" to address deficiencies

 

Citation

 

The problem seems to be due to delays in getting the Block 3F software package, which controls much of the F-35's most important features, ready for the entire F-35 fleet. Block 3F is known as the "full warfighting package" and having it operational is one of the key requirements of ending F-35 development. Testing now appears likely to be pushed back to later in 2017 or even 2018.

At least 15 capabilities in the 3F software package—including the ability to process enemy radar signals, track moving targets on the ground, share imagery between aircraft, use the GPS-guided GBU-39 Small Diameter Bomb, and operate the plane's 25-millimeter gun—are all still under development and at risk of not being ready for combat testing.

 

 

Modifié le 8 février 2017 par zx

[prof.566]

Il a sorti un rapport de 126 pages en janvier. Celui que je suis en train d'éplucher...

[herciv]

Juste une petite question. Pourquoi ce fil se retrouve dans un fil armée de terre ;)

C'est à ce moment que je déclenche mon rire sardonique façon diabolo et satanas.

[zx]

Effectivement,  bonne remarque.

[prof.566]

Pour tromper les modos?

[herciv]

Ils doivent être endormis. Les chats dorment, les souris dansent.

[Picdelamirand-oil]

Présentation du modèle COCOMO

C'est un modèle qui permet d'estimer l'effort et la durée d'un projet en fonction de la taille du logiciel. La formule qui permet le calcul de l'effort a la forme suivante:

 Effort =  A x TailleB x M

où A est une constante qui dépend du type de logiciel et de l'organisation, Taille est la taille du logiciel qui peut être estimée en ligne de code ou par d'autres métriques pour les versions récentes de COCOMO, B est compris entre 1 et 1.5  et il reflète l’augmentation non linéaire des coûts en fonction de la taille  du projet,  M est un multiplicateur.

Toute la difficulté est de trouver les bonnes valeurs pour les coefficients.

COCOMO donne des valeurs typiques et il existe différents niveaux de COCOMO qui permettent de calculer des valeurs plus précises si on a plus d'informations sur le projet. Initialement il y avait 3 niveaux: de base, intermédiaire et détaillé. Puis il y a eu COCOMO II qui lui-même avait plusieurs niveau. Mais on n'a pas assez d'informations pour utiliser des modèles trop sophistiqués.

Dans le modèle intermédiaire, en fonction de la nature du projet l'estimation de l’effort est le suivant:

Simple : PM = 3.2*M*(KLOC) ^1.05

Modéré : PM = 3.0*M*(KLOC) ^1.12

Complexe : PM = 2.8*M*(KLOC) ^1.20

Il n'y a pas de formule pour les projets très complexes, car pour ces projets il faudrait calculer les coefficients avec le modèle détaillé. Mais l'examen de l'ensemble des modèles COCOMO disponibles montre que la valeur maximale de B est autour de 1.26 donc on peut prendre une approximation pour ces projets et je propose :

Très Complexe : PM = 2.6*M*(KLOC) ^1.26

[Picdelamirand-oil]

Présentation du modèle COCOMO (suite)

Dans la formule PM = 2.6*M*(KLOC) 1.26 il ne reste que M à déterminer. PM c'est des People Months ou des Mois*Hommes et le facteur 2.6 est redondant avec M mais c'est parce que dans les modèles simplifiés M vaut 1.

Le modèle intermédiaire lui permet de calculer M en tenant compte des caractéristiques du projet. Le modèle intermédiaire introduit 13 facteurs de productivité. Les 13 facteurs sont multipliés entre eux pour donner un facteur d'ajustement qui vient modifier l'estimation donnée par la formule de base.

Facteurs de productivité

• Logiciel
  • RELY: Fiabilité requise
  • DATA: Volume des données manipulées
  • CPLX: Complexité du produit
• Matériel
  • TIME: Contraintes de temps d'exécution
  • STOR: Contraintes de taille mémoire
  • VIRT: Instabilité de la mémoire
• Personnel
  • ECAP: Aptitude de l'équipe
  • AEXP: Expérience du domaine
  • VEXP: Expérience de la machine virtuelle
  • LEXP: Maîtrise du langage
• Projet
  • MODP: Pratique de développement évoluées
  • TOOL: Utilisation d'outils logiciels
  • SCED: Contraintes de délais

Il existe dans la littérature des tableaux donnant les valeurs de ces paramètres, dans ce post je vais donner seulement les valeurs qui me semblent pertinentes, pour des raisons pratiques! (je ne sais pas comment faire un tableau). Je n'ai pas pris les valeurs extrêmes soit  "extrêmement élevé" et "très basse" parce que sur un projet grandiose comme le F-35 il est statistiquement impossible que l'on atteigne ces valeurs. Ensuite j'ai pris les valeurs qui rendent maximum M pour être en accord avec les dérives constatées des coûts et des délais.

On a donc

• RELY:           1.4
• DATA:           1.16
• CPLX:            1.3
• TIME:             1.3
• STOR:           1.21
• VIRT:             1.3
• ECAP:            1.18
• AEXP:            1.13
• VEXP:            1.1
• LEXP:            1.07
• MODP:           1.1
• TOOL:            1.1
• SCED:            1.08

La multiplication de tous ces coefficients donne 8.854 qui multiplié par 2.6 donne 23.

COCOMO permet d'évaluer aussi la durée du projet et la répartition de l'effort par phase. 

Dans le modèle intermédiaire, en fonction de la nature du projet l'estimation de l’effort est le suivant:

• Simple : TDEV = 2.5(HM)^0.38
• Modéré : TDEV = 2.5(HM)^0.35  
• Complexe : TDEV = 2.5(HM)^0.32

Pour un projet très complexe on prendra TDEV = 2.5(HM)^0.31 où HM est le résultat du calcul précédent en Homme mois.

On peut ensuite calculer la distribution de l'effort par phases (en %)

• RPD (Requirements and Preliminary Design): Conception globale et Plan d'intégration
• DD (Detail Design) : Conception détaillée
• CUT (Code and Unit Test) : Programmation et Tests unitaires
• IT (Integration and Test) : Intégration

On a les valeurs suivantes que j'ai extrapolées compte tenue de mon expèrience et parce que je n'ai pas trouvé dans la littérature des valeurs pour des projets aussi gros que le F-35.

• RPD : 19%
• DD : 25%
• CUT: 19%
• IT : 37%

Enfin on peut répartir la durée entre les phases:

• RPD : 38%
• DD et CUT: 30%
• IT : 32%

Modifié le 10 février 2017 par Picdelamirand-oil

[Picdelamirand-oil]

Application du modèle COCOMO intermédiaire (étendu) au projet F-35

Je n'ai pas présenté ce modèle juste pour le plaisir, je propose donc de l'appliquer au projet F-35, brutalement bien que pour moi il ne soit pas satisfaisant du fait des contraintes que posent les essais en vol et qu'on ne trouve pas sur les systèmes informatiques plus classiques. Mais j'aborderais ces problèmes plus tard.

Calcul de l'effort et de la durée

On a vu que pour l'effort c'était PM =23*(KLOC) 1.26 = 7 599 657 en prenant KLOC = 24000

Pour la durée c'est donc TDEV = 2.5(7 599 657)^0.31 = 340 mois soit 28 ans et 4 mois

Le projet F-35 a été signé en Octobre 2001 ce qui implique une fin du développement au début de 2030 pas très différente de mes autres estimations qui pointent sur 2031.

Modifié le 10 février 2017 par Picdelamirand-oil
Précision sur la date de début

[herciv]

Merci pour cette belle présentation.

Par contre dans ta formule je ne vois pas ou tu décris KLOCK et pourquoi tu choisis KLOC = 24000

[Picdelamirand-oil]

il y a 4 minutes, herciv a dit :

Merci pour cette belle présentation.

Par contre dans ta formule je ne vois pas ou tu décris KLOCK et pourquoi tu choisis KLOC = 24000

KLOC c'est kilo ligne of code,  et comme on a 24000000 de lignes de code pour le F-35 ça fait 24000 kilo.

Bon bien sur j'ai triché pour trouver le résultat qui m'arrangeait, je vous laisse trouver où j'ai triché et lorsque je donnerais la solution cela permettra de mieux discuter de COCOMO, de sa Validité, du programme F-35 et de l'importance de la taille du logiciel pour satisfaire un besoin donné!

[herciv]

Bon je commence. Pour moi tu connais le nombre de ligne de code avant de planifier. Ca ressemble à une approche au doigt mouillé.

[zx]

ca dépend quoi, si ce sont des générateurs qui produisent les sources en fonction de critéres, les lignes de code  augmentent très très vite, plus il y a de code et

plus il est difficile de le maintenir et de le faire évoluer.

[Picdelamirand-oil]

Sur les lignes de code je peux pas tricher, on n'a qu'une seule information je suis bien obligé de l'utiliser.

Modifié le 10 février 2017 par Picdelamirand-oil

[herciv]

il y a 14 minutes, Picdelamirand-oil a dit :

Sur les lignes de code je peux pas tricher, on n'a qu'une seule information je suis bien obligé de l'utiliser.

C'est pas ce que je veux dire.

Ta formule permet d'anticiper un effort de développement en temps et en homme. Mais elle suppose que tu connaisses le nombre de ligne qu'il y aura au final.

[Picdelamirand-oil]

il y a 2 minutes, herciv a dit :

C'est pas ce que je veux dire.

Ta formule permet d'anticiper un effort de développement en temps et en homme. Mais elle suppose que tu connaisses le nombre de ligne qu'il y aura au final.

Oui là d'accord c'est valide mais c'est pouillème, L.M. dit que 100% du code est écrit et en test...Et puis si je rajoute des lignes je vais me rapprocher de 2031, ce sera encore mieux!

Modifié le 10 février 2017 par Picdelamirand-oil

[herciv]

En outre ayant fait du développement, je sais que le nombre final de ligne est moins important en fin de projet.

Attend. Tu parles déjà du f-35 moi je suis encore dans la compréhension de ton outil.

On tapera après.

En plus concernant le f-35 tu ne prend pas en compte que tous les avions sont construit avant que le logiciel "final" soit intégré dans de grande quantité.

[Patrick]

Le 08/02/2017 à 21:47, prof.566 a dit :

MTBF de 0.4h

PARDON ????  J'attends ton article avec impatience pour plus de détails. Là je suis tellement abasourdi que j'en suis circonspect.

[prof.566]

Oh ben je t'en remets une couche alors : 20 new deficiencies/month

[Picdelamirand-oil]

il y a 58 minutes, prof.566 a dit :

Oh ben je t'en remets une couche alors : 20 new deficiencies/month

Tout le monde s'étonne mais pour moi c'est normal. Il faut bien comprendre que le Block 3I qui a les mêmes fonctionnalités que le Block 2B ne fait pratiquement rien. L'avion vole mais une bonne architecture implique qu'il peut voler sans calculateur tactique parce que si un logiciel ayant un MTBF de 0.4 h pouvait impacter la sécurité du vol....au secours. Donc ce logiciel peut créer des pistes avec les données du radar, mais on sait que le radar se désynchronise du calculateur et que ça fait planter le système et donc il y a des progrès à faire, il peut désigner un objectif Air à un AMRAAM ou designer un objectif sol à une GBU (je crois) et c'est tout. 

Donc ce truc qui marchotte c'est juste le framework dans lequel viendront s'inscrire toutes les fonctions complexes qui sont tant vantées par L.M.

L.M. dit que le logiciel est écrit et qu'il est en test. Je les crois! c'est la version 3F la seule qui fait des choses sophistiquées, mais on en est au début de l'intégration et si vous regardez le modèle COCOMO que je vous ai présenté vous voyez que l'intégration c'est le tiers du temps total du projet. Il faut donc rajouter la moitié du temps déjà passé soit 8 ans! Cela nous mène à 2025 et croyez vous que ce sera prêt? Non j'expliquerais pourquoi mais le principe c'est que les essais en vol sont par nature bien plus long que les essais classiques sur une plate forme informatique. Donc je maintien 2031.

[prof.566]

En fait, les premiers 3F plantaient tellement qu'ils en sont revenus à une 3i pour la stabiliser (et au passage corriger des bugs du 2B). Puis ils sont repartis sur le 3F. Ils en sont aux tests du 3FR06, qui est normalement le release qui sera testé par leOT&E.... Enfin quand les avions instrumentés test auront subi 155 modifications.... Et que le pod de restitution existera (il n'est pas encore commandé... Ca va être ric rac pour le mois d'Aout). De toutes facons pour les tests, dans les dataloads ca va être dur. Et comme pour aller plus vite ils skippent des tests en assurant que ceux effectués précedemment sur d'autres bloks restent valables etc.................