Le JSF menacé au Canada !!!!

[bubzy]

90 Md$, c'est le coût TOTAL, incluant le petit déjeuner des pilotes et les pleins de carburant sur toute la durée de vie de l'avion.

 

En France, les 40 et quelques milliards comprennent le développement, l'industrialisation et l'acquisition des avions. Si on y inclue tout le reste, ça nous ferait peur...

 

Je me suis fais grillé de trois jours par ZX, mais je vous propose néanmoins ceci.

 

Et comme d'habitude, je suis ouvert à toute critique:

 

Canada : Lockheed Martin s'oppose à un compétition

 

http://portail-aviation.blogspot.fr/2014/05/canada-lockheed-martin-soppose-une.html

 

Le plus dur dans cet article c'est de réussir à calmer ses doigts pendant que le culcul il fait des bons sur la chaise...

[syntaxerror9]

Je trouve que c'est très bien.

 

Au niveau présentation, peut être que de mieux souligner les deux points clé en gras serait judicieux.

 

Le coté opérationnel.

....

Le coté compensations économiques.

.....

(Sous une forme ou une autre)

 

+ une petite photo du Rafale avec METEOR en illustration, et c'est parfait. :)

Modifié le 26 mai 2014 par syntaxerror9

[bubzy]

Tu remarquera que j'ai fait super soft pour pas faire trop "pro Rafale". En même temps, les connerie de Popaul se suffisaient d'elles même.

J'ai pas développé pour ce qui concerne la partie industrie et économique parcequ'on a un dossier prévu dessus. ça va viendre.

[syntaxerror9]

i know about "the dossier"! ;)

 

C'est bien d'être soft en effet.

Mais comme t'as mis des photos de deux des trois concurrents les plus sérieux, une du Rafale ne serait pas incongrue.

 

Mais je reviens sur la présentation générale.

Je trouve qu'on ne vois pas assez la structure du texte qui est très aéré entre les paragraphes.

 

C'est pourquoi je te proposai des introductions en gras ou autre méthode, pour mieux structurer le texte en quatre parties:

 

-Introduction de la problématique et de P. Manson.

-Le coté opérationnel.

-le coté compensations économiques.

-la conclusion et la problématique des concurrents dont les chaines vont bientôt fermer.

 

L’intérêt de bien marqué les paragraphes, c'est que ça reste bien dans la tête des gens tel un slogan publicitaire. A la fin, le lecteur vois le texte dans son ensemble et le fond lui apparaît comme une évidence.

Modifié le 26 mai 2014 par syntaxerror9

[bubzy]

voilà, c'est modifié ! J'ajouterai une photo du Rafale.. peut être ! ;)

[syntaxerror9]

Voilà, là, c'est bien.
T'as musclé ton jeu.
"Si non, t'allais en l'encontre de grandes déconvenues."
:)

Modifié le 26 mai 2014 par syntaxerror9

[CarlJF]

Un autre point important que Manson "oublie" de mentionner. Les fameuses retombées de 9 milliards du F-35 dont il fait mention ne sont pas garanties. Pour se réaliser, il faudrait que les ventes du F-35 atteignent les niveaux initialement envisagé (ce que l'on sait déjà faux) et que les entreprises canadiennes emportent tous les contrats sur lesquels elles soumissionnent, ce qui serait quand même surprenant. Bref, Manson passe sous silence que ces retombées ne seront présentes que dans le cas d'un scénario idéal dont on peut déjà affirmer qu'il ne se réalisera pas.

[Rémy]

Comment peut-on accorder le moindre crédit, au Canada, à ce général à la retraite passant dans le giron de l'entreprise incriminée (à la tête de la filiale en plus)... c'est délirant. Rédiger un billet posé dessus demande une grande autodiscipline... chapeau.

Modifié le 27 mai 2014 par Rémy

[Picdelamirand-oil]

J'ai écrit un billet publié sur 45 Nord au Canada sur le logiciel du F-35 :

 

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

[Marcus]

J'ai écrit un billet publié sur 45 Nord au Canada sur le logiciel du F-35 :

 

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

 

Intéressant démonstration.

Les logiciels du F-35 sont un sujet sur Lockheed enfume beaucoup.

 

[Technocrate]

http://www.45enord.c...giciel-du-f-35/

 

Article très instructif, je ne connaissais pas le paradoxe de François Horn.

J'en ai parlé à ma femme qui bosse aussi en informatique et qui m' a sortie un autre exemple : 9 femmes ne font pas un bébé en 1 mois; certaines choses ne peuvent pas être segmentées

 

En revanche, tu parts du postulat qu'ils partent d'une feuille blanche alors que plus probablement ils réutilisent du code du F22 ou F16.

Ca doit faire gagner un paquet d'années.

Modifié le 28 mai 2014 par Technocrate

[rendbo]

J'ai écrit un billet publié sur 45 Nord au Canada sur le logiciel du F-35 :

 

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

 

J'aime assez le seul actuel commentaire de l'article !

:)

[BPCs]

J'ai écrit un billet publié sur 45 Nord au Canada sur le logiciel du F-35 :

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

Pendant longtemps la psychologie expérimentale raisonnait sur les faits extérieurs car n'ayant pas accès au fonctionnement de la boîte noire (=le cerveau).

Avec les moyens d'imagerie moderne, le fonctionnement en direct à ou etrre investigué.

Tout ce détour pour dire que ce "billet" apporte un "insight" aux phénomènes extérieurs que l'on ne peut que constater :

Tous ces travaux pour prolonger la cellule des Legacy Fighter couplés à des investissement de retrofit Aesa des F-15 et F-16

Mais surtout ce paradoxe qui veut que les plus ardents supporters du F-35B , les Marines, envisagent de prolonger leur AV-8B jusqu'en 2030 !

Certes, ils doivent d'abord remplacer leur F-18 A ... Mais pour un appareil qui devrait avoir une chaîne de prod à grosse capacité, il y'a une gène ...

Effectivement la question du logiciel donne un sens à tout cela !

Mais comparativement un Rafale ou un F-22 font combien de lignes de code ?

Et quelle réutilisation du code du F-22 ?

Modifié le 28 mai 2014 par BPCs

[Picdelamirand-oil]

http://www.45enord.c...giciel-du-f-35/

 

Article très instructif, je ne connaissais pas le paradoxe de François Horn.

J'en ai parlé à ma femme qui bosse aussi en informatique et qui m' a sortie un autre exemple : 9 femmes ne font pas un bébé en 1 mois; certaines choses ne peuvent pas être segmentées

 

En revanche, tu parts du postulat qu'ils partent d'une feuille blanche alors que plus probablement ils réutilisent du code du F22 ou F16.

Ca doit faire gagner un paquet d'années.

La réutilisation du code est une bonne idée des chefs mais tous ceux qui réalisent savent que c'est une mauvaise idée: sous prétexte de réutilisation, les chefs ne mettent pas les ressources nécessaires à disposition, ce qui fait perdre du temps! Elle est de toute façon assez difficile: on peut à la rigueur récupérer son propre code, mais celui d'un autre... Je n'ai jamais vu de récupération réussie au niveau du calculateur central (le chef d'orchestre) peut être cela se fait -il au niveau des équipements (je verrais bien cela pour les algorithmes d'un Radar).

 

Maintenant il est bien évident que si on a fait une bibliothèque de fonctions mathématiques on a tout fait pour que ce soit récupérable facilement, mais l'effort correspondant, à la création, est 20 fois plus important qu'une création sans volonté de récupérer. Ce que veulent les chefs c'est que l'on récupère sans avoir fait l'effort à la création, qui permet ensuite la récupération.

Mais comparativement un Rafale ou un F-22 font combien de lignes de code ?

Et quelle réutilisation du code du F-22 ?

Je crois qu'un F 22 c'est de l'ordre de 3 millions de lignes de code.

 

Pour un Rafale je ne sais pas (attention il est omnirole) mais c'est déjà 400 000 lignes pour le Radar.

[Picdelamirand-oil]

J'aime assez le seul actuel commentaire de l'article !

:)

 

Il est classé meilleur commentateur

[prof.566]

La réutilisation du code est une bonne idée des chefs mais tous ceux qui réalisent savent que c'est une mauvaise idée: sous prétexte de réutilisation, les chefs ne mettent pas les ressources nécessaires à disposition, ce qui fait perdre du temps! Elle est de toute façon assez difficile: on peut à la rigueur récupérer son propre code, mais celui d'un autre... Je n'ai jamais vu de récupération réussie au niveau du calculateur central (le chef d'orchestre) peut être cela se fait -il au niveau des équipements (je verrais bien cela pour les algorithmes d'un Radar).

 

Maintenant il est bien évident que si on a fait une bibliothèque de fonctions mathématiques on a tout fait pour que ce soit récupérable facilement, mais l'effort correspondant, à la création, est 20 fois plus important qu'une création sans volonté de récupérer. Ce que veulent les chefs c'est que l'on récupère sans avoir fait l'effort à la création, qui permet ensuite la récupération.

Je crois qu'un F 22 c'est de l'ordre de 3 millions de lignes de code.

 

Pour un Rafale je ne sais pas (attention il est omnirole) mais c'est déjà 400 000 lignes pour le Radar.

C'était de l'ordre de 800 000 pour le Rafale F1 (de mémoire), très primitif...

Modifié le 28 mai 2014 par prof.566

[jérôme]

Je crois qu'un F 22 c'est de l'ordre de 3 millions de lignes de code.

 

et se que les 3 millions de lignes de code sont utilisé a 100%  ?

[FATac]

Non, mais ce n'est pas un problème.

 

Lors de la conception de ce type de code, il faut prouver qu'il couvre toutes les situations prévues. Cela ne signifie pas pour autant que toutes ces situations vont arriver.

[Picdelamirand-oil]

C'était de l'ordre de 800 000 pour le Rafale F1 (de mémoire), très primitif...

 

800 000 lignes de code pour un programme classique c'est déjà impressionnant mais pour du logiciel embarqué encore plus: il ne faut pas dire que c'était très primitif, c'est la taille du logiciel du F 35 qui est anormale. La taille du logiciel, ce n'est pas une qualité, c'est un défault, c'est comme le devis de masse d'un avion il faut lutter tout au long du programme pour qu'elle n'augmente pas trop, parce que si on se vautre, on a les delais du F-35.

[jérôme]

si j'ai bien compris  un  rafale avec 3 millions de code ne fera pas forcement  mieux qu'un autre rafale avec 800 000 code ?

[zx]

Ca dépend comment en raisonne, si c'est du tout intégrer(f22?) ou avec un système d'exploitation utilisant des librairies et des composants avec des plugin modulaire ayant leur propre logiciel communiquant via interface avec l'OS. (damocles, spectra, radar, etc..),

ensuite vient la capacité de l'intelligence des plugin a s'intégrer automatiquement dans le système et être disponible

dans l'interface homme machine du rafale.

 

il suffit de voir window ou autre ce qu'il doit apprendre à gérer au niveau des périphériques quand on connecte quelque chose, non seulement il faut qui le détecte mais qu'il utilise ou charge le bon pilote pour le gérer en tant que ressources système pour les besoins applicatifs ou des services.

Modifié le 29 mai 2014 par zx

[Picdelamirand-oil]

Ca dépend comment en raisonne, si c'est du tout intégrer(f22?) ou avec un système d'exploitation utilisant des librairies et des composants avec des plugin modulaire ayant leur propre logiciel communiquant via interface avec l'OS. (damocles, spectra, radar, etc..),

ensuite vient la capacité de l'intelligence des plugin a s'intégrer automatiquement dans le système et être disponible

dans l'interface homme machine du rafale.

 

il suffit de voir window ou autre ce qu'il doit apprendre à gérer au niveau des périphériques quand on connecte quelque chose, non seulement il faut qui le détecte mais qu'il utilise ou charge le bon pilote pour le gérer en tant que ressources système pour les besoins applicatifs ou des services.

L'OS n'est pas du genre windows, il est du genre temps reel.

si j'ai bien compris  un  rafale avec 3 millions de code ne fera pas forcement  mieux qu'un autre rafale avec 800 000 code ?

Non, à un niveau de complexité donné il faut limiter la taille du logiciel, mais un Rafale omnirole a un logiciel plus complexe qu'un Rafale F1. Pour la complexité du F-35 il faudrait que la taille de son logiciel soit comprise entre 3 et 4 millions de ligne au lieu de 8 à 10. (ça devait être 8 au début et 10 maintenant).

[zx]

je n'ai pas dit que le rafale avait un window, c'était un exemple en terme de détection de ressources et ce que cela implique, ca peut etre très bien un linux ou un os spécialisé temps réel mou ou dur ou autre chose. 

 

par contre l'outil de planification des missions semble utiliser un window en client, on en avait parlé à une époque.

http://secretdefense.blogs.liberation.fr/defense/2009/02/les-armes-attaq.html

 

Déjà window est  une faille de sécurité à lui tout seul. à proscrire pour les trucs sensibles.

Modifié le 29 mai 2014 par zx

[Claudio Lopez]

J'ai écrit un billet publié sur 45 Nord au Canada sur le logiciel du F-35 :

 

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

 

Mais bon dieu ! Qu'est ce que c'est compliqué de concevoir le système informatique embarqué d'un avion de chasse.... :-[

Charles E. avait prévu que Lockeed n'était que au début des emmerdes avec le F35.

 

Ce n'est pas demain la veille que j'arriverai à concevoir un avion de chasse dans mon garage .

Modifié le 29 mai 2014 par Claudio Lopez

[FATac]

si j'ai bien compris  un  rafale avec 3 millions de code ne fera pas forcement  mieux qu'un autre rafale avec 800 000 code ?

 

Tout est une histoire de choix et de compromis.

 

J'ai un petit passé de développeur, j'ai participé à des projets du même type.

 

Le nombre de ligne de code n'est qu'un indicateur ultra-grossier de la complexité. J'ai parfois pu diviser ce nombre par 2 sur des projets que j'ai repris, tout en conservant la couverture fonctionnelle et en gagnant en clarté, en concision et en maintenabilité.

 

Dans certains cas, tu peux diviser drastiquement le nombre de lignes de codes en décrétant qu'un cas prévu ne se rencontrera pas ou bien en en simplifiant sa gestion pour retrouver rapidement une configuration plus simple. Inversement, ajouter les fonctions permettant de gérer un événement rare ou "pointu" peut complexifier à l'extrême et multiplier l'impact sur le code.

 

Un des facteurs de complexité du code que l'on peut rencontrer parfois est la volonté de profiter de l'augmentation de la puissance de calcul pour prendre en compte plus finement les phénomènes physiques. Or, la volonté de "réalité" bute sur la complexité alors que l'approximation avec un empilement de modèles simples adaptés à des plages de paramètres permet souvent une simplification bénéfique avec un réalisme suffisant pour un traitement correct.

 

Le vrai but - que les ingénieurs ont tendance à oublier - c'est de rester dans des paramètres et des situations connues, de converger, plutôt que d'être juste ou exact en toutes circonstances avec un risque de divergence ou d'excursion de paramètres qu'il faudra traiter (ce qui, en temps réel, est une vraie gageure).

 

Au final, entre un hypothétique "Rafale à 800000 lignes" et un autre hypothétique "Rafale à 3000000 lignes", la différence peut se trouver dans pleins de facteurs de variation, certains positifs et d'autres négatifs sur les capacités de l'appareil :

  - mauvaise programmation (ça arrive plus souvent qu'on ne le pense, mais tant que ça marche et dans les délais, on ne vérifie pas toujours si c'est optimisé en performances ou en organisation/maintanabilité, hélas)

  - effets de mode (certains décideurs techniques sont parfois "spinnés" vers des technos émergentes et les imposent dans des projets de ce type, parfois en mieux, parfois en pire ... et il faut aussi voire avec la disponibilité des personnes formées aux technos utilisées ... les langages des années 70/80 ne sont plus forcément appris de nos jours, et on ne fait pas du temps réel à coup d'objets en C++ ou en Java !)

  - prise en compte d'une complexité accrue des modèles physiques (ce qui n'a d'intérêt que si l'on arrive à de meilleurs "outputs" par rapport aux données reçues - et ici encore, ce n'est pas toujours le cas, mais on améliore quand même, au cas où)

  - augmentation de capacités (nouvelles possibilités, nouveaux matériels, nouveaux traitements, filtres supplémentaires, etc.)

 

En gros, il est impossible de conclure sur une telle (et simple) comparaison de nombre de lignes de codes.