Le logiciel du F-35

[Picdelamirand-oil]

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

D'un autre coté ils peuvent aider. Lez "mission data loads" US ne seront jamais prêts dans les temps pour l'évaluation test. Qui risque du coup de se dérouler avec des données destinées à des pays clients.... Enfin ca c'est le cas optimiste ou le pod de restitution serait mis au point/commandé d'ici le mois d'aout et ou les avions appareillés pour les tests auront subis 155 modifications indispensables pour représenter un avion de production...

Oui 155... en fait on s'y perd un peu dans les modifications indispensables, parce que il y a de la triche. Par exemple pour assurer l'IOC du F-35B ils avaient repoussés la  correction de 800 anomalies à plus tard, dont certaines après le block 3F. Donc elles sont arbitrairement "pas indispensables" et puis ils ont réduit la fréquence des plantages dues à la désynchronisation entre le Radar et le reste du système mais normalement il faudrait trouver une vraie solution à ce problème, mais ils semblent se contenter de la situation actuelle. Et puis ils découvrent 20 nouvelles anomalies par mois et pour que les tests convergent ils décident de ne pas en corriger 61% parce qu'ils savent qu'ils ne pourraient pas tout corriger pour la date prévue de l'IOC de la Navy. Donc combien d'anomalies seront à corriger sur les avions déjà construits?...MYSTERE.

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

[prof.566]

Bon, ne nous inquiétons pas. Déjà qu'il faut 55h pour changer un moteur de F35C... (pas grave, il n'y a pas de moteur spare de prévu...)

[rendbo]

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

Donc combien d'anomalies seront à corriger sur les avions déjà construits?...MYSTERE.

Mais ces anomalies, à moins qu'elles ne soient structurelles ou matérielle ne se règlent elles pas juste en uploadant la nouvelle version du logiciel ?

[Boule75]

il y a 18 minutes, rendbo a dit :

Mais ces anomalies, à moins qu'elles ne soient structurelles ou matérielle ne se règlent elles pas juste en uploadant la nouvelle version du logiciel ?

Eh non : si la nouvelle version ne les corrige pas...

[rendbo]

 

il y a 2 minutes, Boule75 a dit :

Eh non : si la nouvelle version ne les corrige pas..

oui ça je m'en doute merci, c'est le fait qu'il y ait des anomalies et des avions construits qui m'interroge : si ce n'est que logiciel... 

Modifié le 15 février 2017 par rendbo

[Picdelamirand-oil]

il y a 20 minutes, rendbo a dit :

Mais ces anomalies, à moins qu'elles ne soient structurelles ou matérielle ne se règlent elles pas juste en uploadant la nouvelle version du logiciel ?

C'est vrai que les Block 2B; 3F désignent des versions logicielles principalement, mais pas que, parce que c'est devenu des jalons pour les autres modifications aussi dont des modifications matérielles et structurelles. Donc il faudra plus de 155 modifications matérielles et structurelles pour mettre à niveau les F-35 déjà construits,....sinon on parlerait de milliers d'anomalies....

[prof.566]

155 pour mettre à jour les avions équipés pour test (un peu moins par avion, ce n'est pas uniforme). Le problème n'est pas vraiment là. Le problème c'est que le JPO veut à tout prix faire démarrer l'évaluation/test finale du pentagone vers la fin de l'été. Exemple : pour le block 3F release 5, 276 problèmes critiques, dont plus de 20 "must fix". la version pour les tests est la FR6 et ne tente de corriger que la moitié de ces points critiques. Pour le reste, ils "patcheront" au coup par coup, sans test de régression, en considérant que les tests sur d'anciens blocks sonht toujours valables, en testant plusieurs paramètres à la fois etc.

[bubzy]

Toi, ca sent que t'es en train de te documenter a fond pour nous sortir un arricle du meme accabit qu'avec le typhoon... ;)

[Picdelamirand-oil]

J'ai traduit la partie "test des systèmes de mission" du rapport annuel du DTOE page 47 et 48 car cela concerne essentiellement le logiciel embarqué du programme F-35 et permet d'évaluer où on en est du développement.

Test des systèmes de mission

Le programme poursuit un plan axé sur les coûts et le planning pour supprimer des points planifiés de test du système de mission en utilisant d'autres données d'essai pour atteindre les objectifs de ces points d'essai afin d'accélérer la fin de la phase de développement. Ce plan, s'il n'est pas correctement exécuté avec les données pertinentes, une rigueur analytique et une confiance statistique suffisante, reporterait des risques importants sur les tests opérationnels, les modernisations ultérieures, et les pilotes au combat

Cette approche risquée permet également de rejeter les essais planifiés soigneusement  contenus dans le plan directeur d'essai et d'évaluation (TEMP) et le plan d'essai conjoint du bloc 3F (JTP), contenu que la direction de programme a jugé nécessaire lorsque ces documents ont été signés.

Le programme envisage de "mettre en quarantaine" les points du JTP, dont les vols sont prévus par les centres de test, et plutôt de sauter à des points de test complexes, de réduction de risque pour l'efficacité des missions, récemment mis au point, pour échantillonner rapidement la performance complète du bloc 3F. Ensuite, si l'une des fonctionnalités du bloc 3F semble fonctionner correctement au cours des points de test complexes, le programme pourra supprimer les points du JTP sous-jacents à ces capacités et les désigner comme "non nécessaires".

Toutefois, le programme doit veiller à ce que les données de substitution soient applicables et à ce qu'elles fournissent une validation statistique suffisante pour que les objectifs du point de test aient été atteints avant de supprimer les points de test sous-jacents. Bien que cette approche puisse fournir une évaluation rapide de l'échantillonnage des capacités du bloc 3F,  il existe des risques importants.

Les versions récentes du logiciel pour le test en vol sont nombreuses et cela peut empêcher le programme d'utiliser des données provenant de ces versions pour valider les suppressions de point de test, car elles peuvent ne plus être représentatives du bloc 3F. La disponibilité limitée et le coût élevé des campagnes de tests au Western Test Range (WTR), combiné à des taux élevés de répétition de vol pour les tests effectués au WTR, rendent difficile pour le programme de conduire efficacement ces tests.

Enfin, les capacités les plus complexes du bloc 3F ont seulement récemment atteint un niveau de maturité qui permet de les tester, et ce sont aussi des points de test parmi les plus difficiles à exécuter (c'est-à-dire l'ensemble des capacités du bloc 3F et le domaine de vol).

Jusqu'à une date récente, le Bureau du Programme estimait que les essais en vol des systèmes de mission se termineraient en octobre 2017. Il reconnaît maintenant le risque que ces essais s'étendent au début de la CY18.

L'estimation d'octobre 2017 était basée sur un taux de réalisation des tests gonflé et sur des taux de correction et de répétition des tests optimistes. L'estimation a également supposé que le bloc 3FR6, livré aux essais en vol en décembre 2016, aurait la maturité nécessaire pour compléter les tests restants et satisfaire aux exigences des spécifications sans exiger des versions supplémentaires de logiciels pour combler des lacunes

Cependant, cela est hautement improbable, car plusieurs capacités essentielles - y compris les tirs au canon et l'infrastructure air-air du WTR - n'avaient pas encore fait l'objet d'essais en vol ou ne fonctionnaient pas correctement lorsque le bloc 3FR6 a été fournis.

Les Services ont classé 276 anomalies relatives aux performances au combat comme étant "critiques" et devant être corrigées dans le bloc 3F, mais moins de la moitié de ces anomalies ont benéficié de tentatives de correction dans 3FR6.

[Picdelamirand-oil]

Pour ce qui est d'ALIS qui est le principal système au sol ayant du développement logiciel le paragraphe est page 51 et la traduction est celle ci:

Système d'information logistique autonome

Le programme n'a pas réussi à livrer de nouvelles fonctionnalités ALIS en 2016, mais a mis à jour par deux fois le  logiciel ALIS 2.0.1, actuellement en place, pour combler les anomalies et les lacunes en matière d'utilisation. Le programme prévoyait de tester et de mettre en production ALIS 2.0.2, y compris l'intégration de la gestion des données de propulsion, au cours de l'été 2016, dans le cadre de la déclaration de la capacité opérationnelle initiale de la Force aérienne; Cependant, les retards dans le développement et l'intégration ont repoussé les tests et le déploiement en 2017.

En raison des retards d' ALIS 2.0.2, Lockheed Martin a réaffecté du personnel pour soutenir le développement de ce produit.

Cela a causé des retards dans le calendrier de développement d'ALIS 3.0, la dernière version majeure du logiciel SDD. Le programme a reconnu en août 2016 qu'il ne pouvait pas suivre le calendrier ALIS 3.0 et a élaboré des plans pour restructurer cette version d'ALIS et les capacités restantes d'ALIS 3.0 dans plusieurs versions, dont certaines qui seront  produites après l'achèvement du SDD.

La restructuration du programme ALIS a répartis les capacités prévues et les mises à jour de sécurité pour ALIS dans quatre versions: une version pour SDD (ALIS 3.0), avec ce que le bureau de programme considérait comme nécessaire pour l'IOT&E et trois versions de logiciel supplémentaires destinées à être mises en service à intervalles de 6 mois après la fin de SDD, avec le reste du contenu initialement prévu pour ALIS 3.0.

Le programme prévoit de livrer des mises à jour de maintenance de ces logiciels entre chacune de ces quatre versions de logiciel pour corriger les anomalies et les problèmes d'utilisation, mais ces versions ne comprendront pas de nouvelles fonctionnalités.

L'Armée de l'Air a terminé son premier déploiement d'avions F-35A en utilisant la version modulaire du matériel de l'escadron ALIS, appelée Standard Operating Unit Version 2 (SOU v2) et la version 2.0.1 à Mountain Home AFB, Idaho en février 2016. Les difficultés pendant l'intégration de la SOU v2 dans le réseau de la base ont créé des interférences avec la connectivité entre les stations de travail de Mountain Home et la SOU v2, mais n'ont pas affecté la connectivité de la SOU v2 avec l'unité logistique autonome principale (ALOU) de Fort Worth au Texas.

[Picdelamirand-oil]

Mon estimation finale de la taille de l'équipe chargée du développement du logiciel du F-35 était de 3190 :

Les seuls éléments permettant ce calcul était la taille du logicielle donnée pour 24 millions de lignes. Mais on a un élément nouveau: le prix! le prix serait de £ 12 milliards!

http://www.presstv.ir/Detail/2017/07/17/528746/UK-F35-Fallon-US-pentagon-RAF

Citation

The fifth-generation stealth jet is also unable to transmit data to British ships or older planes without giving away its own position to the enemy.
More importantly, the aircraft’s £12 billion software system is prone to cyber attacks and Britain won’t be able to alter the code on its own, the report added.

La productivité en PIB étant aux US de 100 000 $ par an et par personne (à ne pas confondre avec un salaire si le salarié récupérait 100% de la valeur qu'il produit ça se saurait) cela donne 156281 années homme! si on fait l'hypothèse d'un développement sur 20 ans cela donne une équipe moyenne de 7814 personnes.

Et moi qui pensait que le modèle COCOMO exagérait la taille des équipes des logiciels très complexes, on trouve là un rapport 2 défavorable....

[Benoitleg]

Il y a 9 heures, Picdelamirand-oil a dit :

Mon estimation finale de la taille de l'équipe chargée du développement du logiciel du F-35 était de 3190 :

Les seuls éléments permettant ce calcul était la taille du logicielle donnée pour 24 millions de lignes. Mais on a un élément nouveau: le prix! le prix serait de £ 12 milliards!

http://www.presstv.ir/Detail/2017/07/17/528746/UK-F35-Fallon-US-pentagon-RAF

La productivité en PIB étant aux US de 100 000 $ par an et par personne (à ne pas confondre avec un salaire si le salarié récupérait 100% de la valeur qu'il produit ça se saurait) cela donne 156281 années homme! si on fait l'hypothèse d'un développement sur 20 ans cela donne une équipe moyenne de 7814 personnes.

Et moi qui pensait que le modèle COCOMO exagérait la taille des équipes des logiciels très complexes, on trouve là un rapport 2 défavorable....

Ces 12 milliards couvrent uniquement les coûts des équipes ou intègrent les investissements en matériels ? Ce qui diminuerait d'autant le coût  jour-homme.

Modifié le 18 juillet 2017 par Benoitleg

[Picdelamirand-oil]

il y a 19 minutes, Benoitleg a dit :

Ces 12 milliards couvrent uniquement les coûts des équipes ou intègrent les investissements en matériels ? Ce qui diminuerait d'autant le coût  jour-homme.

Certainement que ça couvre les deux, mais les chiffres sont tellement énormes que j'ai considéré qu'en première approximation le coût du matériel était négligeable. Et pour compenser je parle d'une erreur dans un rapport 2 alors que les chiffres que je donne montrent un rapport bien plus grand que 2. Je cherche juste des ordres de grandeur.

Modifié le 18 juillet 2017 par Picdelamirand-oil

[Benoitleg]

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

Certainement que ça couvre les deux, mais les chiffres sont tellement énormes que j'ai considéré qu'en première approximation le coût du matériel était négligeable. Et pour compenser je parle d'une erreur dans un rapport 2 alors que les chiffres que je donne montrent un rapport bien plus grand que 2. Je cherche juste des ordres de grandeur.

Je pensais aussi aux charges de bâtiments pour accueillir 5000/6000/7000/etc. personnes, aux simulateurs divers, aux matériels informatiques de support de travail, etc..

Pour exemple, dans une structure avec un effectif variant entre 70 et 90 employés, les couts de bâtiment oscillaient entre 1 et 1,5  m€ annuels.

Modifié le 18 juillet 2017 par Benoitleg

[Picdelamirand-oil]

il y a 10 minutes, Benoitleg a dit :

Je pensais aussi aux charges de bâtiments pour accueillir 5000/6000/7000/etc. personnes, aux simulateurs divers, aux matériels informatiques de support de travail, etc..

Ça coûte combien par personne? une personne pendant 20 ans ça coûte 2 000 000 $ dans mon calcul. Ce que tu rapporte coûte peut être 50 000 $ par personne ce qui fait 350000000 $ c'est une somme mais c'est négligeable.

Modifié le 18 juillet 2017 par Picdelamirand-oil

[Benoitleg]

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

Ça coûte combien par personne? une personne pendant 20 ans ça coûte 2 000 000 $ dans mon calcul. Ce que tu rapporte coûte peut être 50 000 $ par personne ce qui fait 350000000 $ c'est une somme mais c'est négligeable.

70 personnes sur 20 ans à 1m€/an pour les frais de bâtiments, ca donne environ 20 m€ (en négligeant l'inflation), soit 2 Mds € pour 7000 personnes (x100).

Après, l'exemple que je cite nécessitait de grands espaces de stockage, (1/2 des surfaces), mais je présume que les bâtiments pour accueillir le développement du F35 nécessite une sécurisation poussée au coût conséquent, ce qui doit égaliser les choses.

Modifié le 18 juillet 2017 par Benoitleg

[Picdelamirand-oil]

il y a 4 minutes, Benoitleg a dit :

70 personnes sur 20 ans à 1m€/an, ca donne environ 20 m€, soit 2 Mds € pour 7000 personnes (x100).

Après, l'exemple que je cite nécessitait de grands espaces de stockage, (1/2 des surfaces), mais je présume que les bâtiments pour accueillir le développement du F35 nécessite une sécurisation poussée au coût conséquent, ce qui doit égaliser les choses.

Non mais Lockheed n'emploie pas des Smigards 

[Benoitleg]

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

Non mais Lockheed n'emploie pas des Smigards 

Là non plus, mais travailler chez Lockheed est sans aucun doute plus rémunérateur .

[Boule75]

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

Ça coûte combien par personne? une personne pendant 20 ans ça coûte 2 000 000 $ dans mon calcul. Ce que tu rapporte coûte peut être 50 000 $ par personne ce qui fait 350000000 $ c'est une somme mais c'est négligeable.

Un coût global de 100.000$/an/programmeur ça me paraît très sous-évalué. D'une part parce que ça ne fait pas de super-salaires pour les USA. D'autre part parce que si on parle de coût global, il faut tout compter autour : les locaux (sécurisés), les services afférents aux locaux, les services afférents aux programmeurs (RH, juridique, compta...), les équipes de support (hordes de cadres et consultants de direction dirigeant les braves programmeurs, spécialistes de l'audit fonctionnel et de la qualité, juristes et spécialistes de la contractualisation...), tout un tas de fonction qui doivent fleurir de manière plus ou moins linéaire avec le nombre de programmeurs.

Un autre aspect : le même document signale que le code est farci de codes "commerciaux", pré-existants, donc. Si ce code est comptabilisé dans les 24M de lignes de code, mais déjà écrit (des libs), ça fait ça de moins à écrire et ça brouille nos calculs.

[Picdelamirand-oil]

il y a 2 minutes, Boule75 a dit :

Un coût global de 100.000$/an/programmeur ça me paraît très sous-évalué. D'une part parce que ça ne fait pas de super-salaires pour les USA. D'autre part parce que si on parle de coût global, il faut tout compter autour : les locaux (sécurisés), les services afférents aux locaux, les services afférents aux programmeurs (RH, juridique, compta...), les équipes de support (hordes de cadres et consultants de direction dirigeant les braves programmeurs, spécialistes de l'audit fonctionnel et de la qualité, juristes et spécialistes de la contractualisation...), tout un tas de fonction qui doivent fleurir de manière plus ou moins linéaire avec le nombre de programmeurs.

Un autre aspect : le même document signale que le code est farci de codes "commerciaux", pré-existants, donc. Si ce code est comptabilisé dans les 24M de lignes de code, mais déjà écrit (des libs), ça fait ça de moins à écrire et ça brouille nos calculs.

c'est vrai que sur l'ATL2 on avait pas de code commercial, même le système d'exploitation était propriétaire et dédié à l'avion. Utiliser du code commercial pour réaliser le système d'un avion militaire nous aurait paru incongru. Mais ça doit représenter du travail quand même de bien utiliser du code commercial et d'assurer qu'on embarque rien de dangereux par la même occasion.

[prof.566]

L'usage des librairies préexistantesest documenté, limité et réglementé (lo document est public). En clair, il y a une "liste" de librairies autorisées. Je ne vous raconte pas la tête du fiston qui reprogramme Printf en ce moment quand je lui ai dit ca...

Modifié le 19 juillet 2017 par prof.566

[herciv]

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

L'usage des librairies préexistantesest documenté, limité et réglementé (lo document est public). En clair, il y a une "liste" de librairies autorisées. Je ne vous raconte pas la tête du fiston qui reprogramme Printf en ce moment quand je lui ai dit ca...

C'est du C++ je crois. L'existence de code commercial n'est absolument pas anormal dès lors qu'on a choisi le C++. C'est même l'une des raisons probables qui ont poussées à ce choix. Donc ils font de l'héritage, fonction essentielle qui permet de ne pas réécrire des librairies existantes surtout quand elles sont basiques.

Mais ça ne donne pas le poids de ces librairies dans le projet globale.

Modifié le 19 juillet 2017 par herciv

[kotai]

Ce ne serais pas plus simple de programmer en objet?

[herciv]

il y a 3 minutes, kotai a dit :

Ce ne serais pas plus simple de programmer en objet?

Le C++ est un langage objet.

[FATac]

il y a 31 minutes, kotai a dit :

Ce ne serais pas plus simple de programmer en objet?

Comme le dit herciv, le C++ est orienté objet.

Après, il y a deux concepts objet qui s'opposent :

• la programmation orientée objet (POO, ce que font les langages objets classiques)
• la programmation par objet (PPO, qui peut être faite avec des langages classiques et qui joue sur les structures de données pour associer données et code lié).

Dans le premier cas, tu peux avoir une complexité d'exécution de ton code liée aux mécanismes d'instanciation, d'héritage et de généralisation, puis de libération des objets. Pour faire i = i + 1, certains langages vont créer une copie de l'objet entier i, créer un objet entier avec la valeur de la constante 1, créer un objet entier temporaire pour recevoir le résultat de l'opération, et enfin copier celui ci dans l'objet destination. Les instanciations/libérations inutiles peuvent faire perdre un temps précieux à l'exécution pour des opérations simples sur des objets complexes.

Dans le second cas, tu augmentes la complexité des couches basses de ton code pour retrouver une abstraction raisonnable aux niveaux élevés, mais tu maîtrises dès la compilation le comportement à l'exécution. Tu ne prends pas le risque d'opérations inutiles. C'est un peu comme recoder soi-même scanf (plutôt que printf) pour lui éliminer les formats inutiles et lui ajouter de la sécurité vis à vis des "inputs" imprévus ...