Aller au contenu
AIR-DEFENSE.NET

Le F-35


georgio
 Share

Messages recommandés

Rob1, False Positive , tu l'as écrit  c'est une information erroné .. tu peux dire que ce n'est pas fes erreurs si tu veux .. mais tu tombes dans le panneau du vocabulaire politiquement correct. 

 

Je n'ai pas dit que ce n'était pas des erreurs. Seulement que ce n'est pas de la langue de bois pour "positiver" des erreurs, mais du langage normal de logique (pas Shadok).

 

Lien vers le commentaire
Partager sur d’autres sites

Ah ca, je dis pas le contraire, 80% d'erreur le truc est à chier. Mais ma rigueur intellectuelle m'empêche qu'on critique le F-35 sur la base d'une mauvaise compréhension du "fasle positive".

 

 

J'ai toujours trouvé que cette vidéo résumait très bien mon année de maths sup :)

 

:D Avec  80% d'erreur, il reste en effet un peu de chance que le système ne se trompe pas de temps en temps.

Lien vers le commentaire
Partager sur d’autres sites

Rob1, False Positive , tu l'as écrit  c'est une information erronée .. tu peux dire que ce n'est pas fes erreurs si tu veux .. mais tu tombes dans le panneau du vocabulaire politiquement correct. 

Dans ta rigeur intellectuelle, il n'y a pas une demie erreur ou une erreur pleine. 

 

Si la rigueur intellectuelle veut que toutes les erreurs soient des erreurs, quelle que soit leur nature, l'honnêteté impose quand même de mesurer que les conséquences ne sont pas les mêmes.

 

Un faux positif, c'est un signalement à tort. Cela signifie que, par précaution, on prendra des mesures conservatoires pour éviter de détériorer la situation (changement de pièces, mode alternatif de fonctionnement, bascule sur un circuit de secours, immobilisation des éléments rapportés en défaut). Ces mesures sont prises à tort, ce qui va conduire à une dérive des coûts - avec ces opérations non justifiées - et à une chute de confiance des opérateurs dans le système.

 

Un faux négatif serait bien plus grave. C'est toujours une erreur, mais c'est l'absence de signalement d'un problème. Cela signifie que le système fonctionne en mode dégradé (ou ne fonctionne plus) alors que l'opérateur a toujours l'illusion d'un fonctionnement nominal. A titre d'exemple, c'est le panneau du train qui affiche "trois vertes" alors que le train n'est pas sorti ou pas verrouillé. L'écart entre la situation réelle et la situation perçue par l'opérateur ne permettra généralement pas de rattraper la situation lorsqu'elle va se compromettre. Les conséquences sont généralement et plus brutalement néfastes et conduisent à des pertes (d'appareils ou de systèmes).

 

Si 80% de faux positifs, c'est bien trop élevé pour permettre la confiance, cela reste aussi accompagné de 20% de diagnostics fiables.

 

Par contre, si ce taux de faux positif est si élevé, c'est peut être pour garantir la sensibilité du système et rejeter les faux négatifs. Baisser la sensibilité risquerait alors de laisser passer des défauts rédhibitoires compromettant la sécurité. Quelque part, cette précaution a un coût ... cet avion est décidément un appareil de riches.

  • Upvote (+1) 1
Lien vers le commentaire
Partager sur d’autres sites

Il me semble qu'on ne peut pas parler de faux négatif mais de défaut de détection dans ce cas car si le système ne prévoit pas de détecter, il ne peut pas être mis en défaut et s'il le prévoyait, c'est une panne ou un défaut. Pas très clair mon propos mais je souhaitais donner mon avis même si c'est du chipotage.
L'essentiel est la confiance dans le système. Si l'on ne sait pas vraiment si les détections sont fiables, que ce soit par défaut ou par excès, on peut finir par ne plus en tenir compte et faire des inspections en parallèle.

Modifié par Gallium nitride
Lien vers le commentaire
Partager sur d’autres sites

Il me semble qu'on ne peut pas parler de faux négatif mais de défaut de détection dans ce cas car si le système ne prévoit pas de détecter, il ne peut pas être mis en défaut et s'il le prévoyait, c'est une panne ou un défaut. Pas très clair mon propos mais je souhaitais donner mon avis même si c'est du chipotage.

L'essentiel est la confiance dans le système. Si l'on ne sait pas vraiment si les détections sont fiables, que ce soit par défaut ou par excès, on peut finir par ne plus en tenir compte et faire des inspections en parallèle.

Et s'il le prévoyait mais qu'il a mal fait son travail parceque la programmation est merdique c'est un faux négatif. (et la programmation est merdique)

Lien vers le commentaire
Partager sur d’autres sites

J'ai gémi de douleur en voyant les prix. Mais je ne vais pas poster ça sur le topic, parce que, bon..., il s 'appelle "the F-35 anti-bash thread". Oui, depuis quelques années, c’est le F-35 qui s'en prend plein la face sur ce forum outre-Atlantique.
  • Upvote (+1) 1
Lien vers le commentaire
Partager sur d’autres sites

Quelques extraits significatifs traduits du rapport cité par PIC:

 

En ce qui concerne les moteurs:

Après l'incident de Juin 2014, les inspections qui ont suivi, menées par l'entreprise Pratt & Whitney ont permis d'identifier 22 moteurs avec des signes de surchauffe. En date du 31 Janvier 2015, 18 de ces 22 moteurs avaient reçu un correctif court-terme et ont été autorisés à revenir au cours normal des opérations de vol. Pratt & Whitney a identifié plusieurs correctifs potentiels à long terme, mais aucune décision définitive n'a encore été prise.

Les données fournies par Pratt & Whitney indiquent que le nombre d'heures moyen entre deux pannes pour le moteur du F-35A est à environ 21% de la cible prévue à cette date. Le moteur du F-35B en est lui à environ 52%. Pratt & Whitney a identifié un certain nombre de modifications de conception qui permettront d'améliorer la fiabilité des moteurs et certains de ces changements sont déjà en cours d'intégration dans la conception et la production. Cependant d'autres modifications de conception que Pratt & Whitney pense nécessaires ne sont actuellement pas financées.

Les logiciels:

Le personnel et les installations qui avaient été consacrés au développement et tests des logiciels Block 3i et Block 3F ont été réaffectés au Block 2B pour soutenir l'IOC prévu en 2015 pour Marine Corp, ce qui retardera d'au moins 6 mois la mise à dispostion du Block 3F. Les reports auront également comme conséquence de réduire le nombre de F-35 mis en service au cours des prochaines années, ce qui pourrait forcer les services des Armées à investir dans l'extension de la durée de vie de leurs flottes actuelles, y compris les A-10 Thunderbolt II et le  F/A-18 Hornet.

Le coût:

les données du bureau du Programme JSF indiquent qu'après comptabilisation des diminutions de quantités de production, le programme n'atteindra probablement pas les objectifs de coûts unitaires fixés par le Secretary of Defense for Acquisition, Technology, and Logistics, en 2012.

Le contrôle:

La meilleure façon de procéder est d'avoir 100% des process de fabrication critiques contrôlés au cours de la production initiale à cadence réduite. Actuellement, 40% de ces process sont contrôlés de manière statistique et selon les responsables de Lockheed Martin, seulement 54% des process critiques peuvent fournir suffisamment de données pour permettre un contrôle statistique. En conséquence, ils ne s'attendent pas à atteindre 100%.

  • Upvote (+1) 3
Lien vers le commentaire
Partager sur d’autres sites

De rien, j'avais un peu de temps devant moi et je n'ai traduit que ce qui me semblait nouveau par rapport aux anciens rapports du GAO.

Pour ce qui concerne les contrôles, je trouve ça limite flippant mais je vois ça de ma porte et je relativise.

Oui parce que c'est 100% des process critiques qu'ils ne peuvent pas faire.

Lien vers le commentaire
Partager sur d’autres sites

Oui parce que c'est 100% des process critiques qu'ils ne peuvent pas faire.

Qu'ils ne peuvent pas contrôler plutôt, mais c'est déjà énorme. Autrement dit il faut s'attendre à des surprises sur les appareils déjà produits et même sur les productions futures. Au delà des rétrofits nécessaires suite aux divers correctifs  et améliorations prévus, il y aura probablement des retours  pour défaut de fabrication. Souhaitons que cela ne mette pas en jeu la vie des pilotes.

Modifié par Gallium nitride
Lien vers le commentaire
Partager sur d’autres sites

Quelques extraits significatifs traduits du rapport cité par PIC:

Les logiciels:

Le personnel et les installations qui avaient été consacrés au développement et tests des logiciels Block 3i et Block 3F ont été réaffectés au Block 2B pour soutenir l'IOC prévu en 2015 pour Marine Corp, ce qui retardera d'au moins 6 mois la mise à dispostion du Block 3F. Les reports auront également comme conséquence de réduire le nombre de F-35 mis en service au cours des prochaines années, ce qui pourrait forcer les services des Armées à investir dans l'extension de la durée de vie de leurs flottes actuelles, y compris les A-10 Thunderbolt II et le  F/A-18 Hornet.

Je rapelle que de mon point de vue lorsqu'on est en retard dans les développements logiciel, si le logiciel est complexe et si l'équipe est importante déjà, ce n'est pas en rajoutant du monde qu'on réduit les retards.

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

Lien vers le commentaire
Partager sur d’autres sites

Je rapelle que de mon point de vue lorsqu'on est en retard dans les développements logiciel, si le logiciel est complexe et si l'équipe est importante déjà, ce n'est pas en rajoutant du monde qu'on réduit les retards.

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

Oui, je me souviens bien  et la démonstration était éloquente. Dans le cas qui nous concerne, c'était peut-être aussi une réaffectation de compétences en même temps que d'effectifs.

Lien vers le commentaire
Partager sur d’autres sites

J'ai lu l'article. 250 Lignes par an, c'est pas un peu faible sans vouloir (trop) polémiquer? 

 

Citation:

 

 

 

Comme on est dans un projet complexe la productivité est réduite à 250 lignes de code par an et par personne

 

 

En Crash prog je fais aisément 3000 lignes par mois. Et je ne suis pas un programmeur. 

Lien vers le commentaire
Partager sur d’autres sites

250 lignes de code du logiciel réellement embarqué.

Et des dizaines de milliers de lignes de code de tests, de simulations…

Sans compter les contraintes sur le code : utilisation de languages tres rigoureux, donc largement plus difficile d'utilisation. Analyse statique et dynamique du code. Traitement de tous les cas d'exception…

Çà n'a rien à voir avec la programmation traditionnelle. Sans compter les contraites d'efficacité !

  • Upvote (+1) 1
Lien vers le commentaire
Partager sur d’autres sites

Réponse concise. Je m'incline*.

 

Mais n'oublions pas que le logiciel n'est pas que du CDV. Il y a beaucoup** d'analyses logique, de recherche de library, de comparaison etc.. Bref on est loin d'un moteur de calcul scientifique embeddé dans une appli ;)

.

Il y a une source vers un standard ou un minimum requierement?  

 

 

*sauf sur le "Traditionnelle" et "efficacité" qui sont un peu hors de propos dans le contexte. 

**Essentiellement même peut-on penser

Modifié par TomcatViP
Lien vers le commentaire
Partager sur d’autres sites

Réponse concise. Je m'incline*.

 

Mais n'oublions pas que le logiciel n'est pas que du CDV. Il y a beaucoup** d'analyses logique, de recherche de library, de comparaison etc.. Bref on est loin d'un moteur de calcul scientifique embeddé dans une appli ;)

.

Il y a une source vers un standard ou un minimum requierement?  

 

 

*sauf sur le "Traditionnelle" et "efficacité" qui sont un peu hors de propos dans le contexte. 

**Essentiellement même peut-on penser

Dans l'article j'avais mis ce lien

http://clerse.univ-lille1.fr/IMG/pdf/pardoxe_productivite_logiciel.pdf

où il y a beaucoup d'explication sur les différents niveaux de productivité, productivité apparente etc...

J'en extrait le passage suivant

 

ainsi Jones estime que la productivité apparente varie de 25 000 lignes de code source par homme-année pour "le codage seul, mesuré pendant une journée et converti en taux annuel", à 250 pour "les moyens totaux consacrés en un an au logiciel par l'entreprise, y compris projets abandonnés, tous les développements et améliorations et toute la maintenance" (1989, p. 38).

 

Qui montre déjà un rapport 100.

Il est clair que la mesure à partir des lignes de codes n'est pas très pertinentes, mais c'est la seule métrique que l'on ait, vu de l'exterieur, pour mesurer le logiciel du F-35. Il est clair aussi que sur un programme aéronautique, il y a autour du programmeur tout un environnement technique qui travaille à la production du logiciel: Simulateurs, Stimulateurs, gestion de configuration (Trois variantes d'un avion multirole),logiciel de test, de mesure de performance, d'analyse...mais surtout cela se termine par des essais en vol. Et là la productivité est très faible ce qui nous met systématiquement dans le bas des fourchettes.

Lien vers le commentaire
Partager sur d’autres sites

Rejoindre la conversation

Vous pouvez publier maintenant et vous inscrire plus tard. Si vous avez un compte, connectez-vous maintenant pour publier avec votre compte.

Invité
Répondre à ce sujet…

×   Collé en tant que texte enrichi.   Restaurer la mise en forme

  Seulement 75 émoticônes maximum sont autorisées.

×   Votre lien a été automatiquement intégré.   Afficher plutôt comme un lien

×   Votre contenu précédent a été rétabli.   Vider l’éditeur

×   Vous ne pouvez pas directement coller des images. Envoyez-les depuis votre ordinateur ou insérez-les depuis une URL.

 Share

  • Statistiques des membres

    5 967
    Total des membres
    1 749
    Maximum en ligne
    Stevendes
    Membre le plus récent
    Stevendes
    Inscription
  • Statistiques des forums

    21,5k
    Total des sujets
    1,7m
    Total des messages
  • Statistiques des blogs

    4
    Total des blogs
    3
    Total des billets
×
×
  • Créer...