Le F-35

[bubzy]

il y a 34 minutes, Teenytoon a dit :

Celui du Rafale en a pas loin de 20 aussi et il est aujourd'hui supérieur à celui du F35...

La base oui, mais maintenant... beaucoup de choses ont été écrites entre temps et continues de l'être.

 

il y a 28 minutes, DEFA550 a dit :

Celle-là, je l'encadre !!! 

J'aurai plutôt cru que ce qui suit...

Il y a 4 heures, bubzy a dit :

Et une seconde fois, lors des tests de manoeuvres de combat réalisées contre un F-16 dans lequel le F-35A s'est retrouvé acculé dans pratiquement toutes les positions 
 

Enfin bref. Retenez de moi les plus spirituelles, ça me convient bien ! XD

[ARPA]

il y a 39 minutes, Rivelo a dit :

Tu imagines tous les avantages qu'ils auraient pu tirer d'une mutualisation avec le système d'arme du F22, toutes choses égales par ailleurs ?...

Ce n'était pas une contrainte du cahier des charges? Le F22 était considéré comme trop secret défense pour pouvoir servir au développement d'un avion "populaire". D'ailleurs sans les retard du F35, ça aurait pu être logique vu que les F22 et les F35 auraient été contemporains. 

[Rivelo]

il y a 41 minutes, seb24 a dit :

Je suis pas sur honnêtement. Le système du F-22 a plus de 20ans.

C'est bien ce que je dis, le pêché d'orgueil de l'IT 

Ce n'est pas amusant en tant que développeur de se plonger dans un programme écrit il y a 20 ans par une autre personne, dans un langage spécifique, utilisant des méthodologies datées, c'est un fait. Mais faire table rase (tentation au combien tentante) sous-estime complètement la somme de connaissance et de retour sur expérience que ces programmes intègrent. Cela sous-estime aussi le risque d'un projet "feuille blanche" avec de nouvelles technos par rapport à des évolutions incrémentales d'un soft existant. 

[Rivelo]

il y a 6 minutes, ARPA a dit :

Ce n'était pas une contrainte du cahier des charges? Le F22 était considéré comme trop secret défense pour pouvoir servir au développement d'un avion "populaire". D'ailleurs sans les retard du F35, ça aurait pu être logique vu que les F22 et les F35 auraient été contemporains. 

Je pense que c'est plus une contrainte du meccano industriel. BAe est en charge d'une grosse partie du système d'arme du F35. Tandis que pour le F22, c'était Boeing et LM qui étaient en charge de l'intégration de l'avionique.

[dark sidius]

Le Budget pour un budget de la taille d'un pays comme la France est a minima , le seuil correct serait 2% du Pib.

[g4lly]

 

 le seuil correct serait 2% du Pib.

Tu peux nous faire profiter du processus "scientifique" qui t'a amené a établir une telle valeur?

[judi]

il y a 9 minutes, g4lly a dit :

Tu peux nous faire profiter du processus "scientifique" qui t'a amené a établir une telle valeur?

Cela s'appelle l'OTAN et nos engagements en la matière. A savoir dépenser 2% du PIB dans la Défense (hors pensions il me semble bien). Evidement, cela ne s'applique qu'à la dernière partie de la phrase. Pas la première. J'aimerais moi aussi en profiter. Surtout qu'il n'y a pas de "loi" au sens scientifique ou même non-écrite en la matière. 

[Stratogogo]

Il y a 11 heures, Rivelo a dit :

Je pense que c'est plus une contrainte du meccano industriel. BAe est en charge d'une grosse partie du système d'arme du F35. Tandis que pour le F22, c'était Boeing et LM qui étaient en charge de l'intégration de l'avionique.

Ce qui est étonnant , c'est que si l'on suit les histoires de fusion/acquisition faites par Bae Systems Inc et Northrop Grumman , alors (théoriquement) l'avionique du F-35 tiendrait presque plus du YF-23 que du F-22.

 

Modifié le 14 octobre 2016 par Stratogogo

[Rivelo]

Il y a 10 heures, Stratogogo a dit :

Ce qui est étonnant , c'est que si l'on suit les histoires de fusion/acquisition faites par Bae Systems Inc et Northrop Grumman , alors (théoriquement) l'avionique du F-35 tiendrait presque plus du YF-23 que du F-22.

 

Le YF-23 était un avion expérimental et il n'avait que 200M$ de budget alloué par le Pentagone pour développer le Vehicle Management System. Forcément, ils ont été obligé d'être très pragmatiques. Si j'ai bien tout suivi, c'est un développement en ADA inspirés de ce qui volait déjà chez Boeing, basé sur l'OS VXWorks (assez reconnu dans le monde de logiciel temps-réel embarqué, un bon choix).

Pour le F35, le budget n'était pas un problème. "Ils" se sont lâchés et "ils" ont décidé de faire complètement table rase de tout l'historique (d'où nouvel OS, nouveau langage, mais aussi nouveaux bus de donnée, nouvelles interfaces hardware...).  Il n'y plus rien de compatible avec la génération précédente (ni les logiciels, ni les périphériques, ni l'équivalent des drivers)... 

[Stratogogo]

Il y a 2 heures, Rivelo a dit :

Le YF-23 était un avion expérimental et il n'avait que 200M$ de budget alloué par le Pentagone pour développer le Vehicle Management System. Forcément, ils ont été obligé d'être très pragmatiques. Si j'ai bien tout suivi, c'est un développement en ADA inspirés de ce qui volait déjà chez Boeing, basé sur l'OS VXWorks (assez reconnu dans le monde de logiciel temps-réel embarqué, un bon choix).

Pour le F35, le budget n'était pas un problème. "Ils" se sont lâchés et "ils" ont décidé de faire complètement table rase de tout l'historique (d'où nouvel OS, nouveau langage, mais aussi nouveaux bus de donnée, nouvelles interfaces hardware...).  Il n'y plus rien de compatible avec la génération précédente (ni les logiciels, ni les périphériques, ni l'équivalent des drivers)... 

Oui , et 100M$ en plus pour le radar si on parle de toute l'avionique. Mais ce n'est pas là où je voulais en venir.

J'ai juste un peu de mal à croire que le programme F-35 soit entièrement parti d'une feuille blanche et soit issu "d'une technologie différente" du F-22 comme le dit LM. Dans ce programme on retrouve beaucoup d'entreprises et de briques technologiques issues des ATF.

Alors OK , c'est vrai, certaines briques technologiques se sont améliorées ( meilleurs calculateurs, meilleures antennes AESA, meilleurs revêtements , meilleurs capteurs etc ) , et c'est vrai aussi semble t'il qu'ils utilisent un autre langage de codage (je ne me lance pas là dessus je n'y connais rien).

Par contre il y a vraiment un noyau dur d'entreprises issues du programme ATF (YF-22 et YF-23) qui se retrouvent dans le F-35. Que ce soit Tracor , Westinghouse , Sanders Associates , TRW , G.E. aviation ... on les retrouvent quasiment toutes aujourd'hui centralisées sous la houlette de Northrop Grumman et BAe Systems inc. Je ne pense pas qu'elles soient restées les bras croisés pendant 10 ans et que la réécriture du codage soit un obstacle pour elles.

C'est la fusion de données développée pour le F-35 ,qui elle par contre, est totalement nouvelle. Et c'est là , dans cette idée "d'intelligence artificielle" à laquelle on demande l'absolue perfection, que réside le vrai problème.

Très honnêtement je peux avoir complètement tort, mais on pourra bien continuer à parler de codage pendant cent sept ans dans le fil F-35, selon moi le vrai problème vient de l'architecture de la fusion de donnée et de ce qu'on lui demande. Les problèmes de codage ne sont qu'une conséquence directe.

[Rivelo]

il y a 2 minutes, Stratogogo a dit :

Très honnêtement je peux avoir complètement tort, mais on pourra bien continuer à parler de codage pendant cent sept ans dans le fil F-35, selon moi le vrai problème vient de l'architecture de la fusion de donnée et de ce qu'on lui demande. Les problèmes de codage ne sont qu'une conséquence directe.

Le codage n'est généralement pas un obstacle insurmontable en soi. Mais la remise en cause totale des architectures logicielles et hardwares a comme conséquence l'impossibilité de réutiliser quoi que ce soit de la bibliothèque de code et de composants déjà validés l'ensemble de tous les autres programmes récents de l'US Air Force (F22, mais aussi F16 et F18 de dernière génération, C130J, C17, C27J...) et même des programmes civils (jusqu'au 777, les Boeing civils utilisaient aussi le langage ADA et des architectures assez comparables). Tout doit être réinventé, y compris des choses que l'on pouvait penser acquises (ex : pilotage d'une GBU Paveway, utilisation d'une liaison L16, ...) ou les fondamentaux d'un bon FMS.  L'interopérabilité doit être revérifiée et la mise au point refaite.A cela se rajoute le boulot que l'on aurait eu de toute façon pour intégrer les nouveaux capteurs / les nouveaux périphériques.

Les difficultés que connait / a connu le F35 pour arriver juste au niveau du F16 sur des tâches aussi basiques que tirer une GBU ou tirer un missile air/air (sans parler à ce stade de fusion de données ou d'IA) découlent à mon avis directement de cette décision de faire table rase.

[Stratogogo]

Ok merci pour les précisions, je ne pensais pas que c'était aussi important comme problème.

Du coup que va t-il se passer si les Américains veulent intégrer un nouvel armement (bombe ou missile) à la fois sur le F-35 et à la fois sur un autre avion ?  Il faudra tout faire deux fois ?

Et autre question , est-ce que cela rend l'intégration de systèmes étrangers toujours possible ?

Modifié le 14 octobre 2016 par Stratogogo

[rogue0]

Le 13/10/2016 à 11:47, Rivelo a dit :

ADA a été choisi comme language standard à une époque par le Pentagone (années 80) mais en France, on utilise traditionnellement nos propres stacks logicielles (notament le Language Temps Réel pour les calculateurs de Rafale si j'ai bien suivi).

Par curiosité, comment se comparent le C++ et ADA (+OS dédié) sur les contraintes temps réel aéro ? 

Le 13/10/2016 à 09:56, bubzy a dit :

Pour autant, pour faire un avion de SUPERIORITE aérienne, il faut quelques éléments qu'aucun logiciel ne te donneront

En forçant (beaucoup) le trait, ca serait comme vendre le a10 ou le su25 comme des plateformes de supériorité aérienne. (Edit)Quels que soient les modules avioniques magiques rajoutés, Il faudrait vraiment être désespéré pour les utiliser dans ce rôle (ou alors l'opposition n'est que des hélicoptères, ou des P40). Meme contre les liners, ils sont marginaux ( sauf pour les lecteurs de RT/ sputnik <troll off>)

Modifié le 15 octobre 2016 par rogue0

[Rivelo]

Il y a 19 heures, Stratogogo a dit :

Ok merci pour les précisions, je ne pensais pas que c'était aussi important comme problème.

Du coup que va t-il se passer si les Américains veulent intégrer un nouvel armement (bombe ou missile) à la fois sur le F-35 et à la fois sur un autre avion ?  Il faudra tout faire deux fois ?

Et autre question , est-ce que cela rend l'intégration de systèmes étrangers toujours possible ?

Oui, c'est ça, pour un intégrer un nouvel armement sur le F35 et sur un autre avion US, il faudra faire le travail au moins deux fois.

Concernant l'intégration de matériel étranger, désolé, je n'ai pas d'infos précises là-dessus.

[Rivelo]

Il y a 2 heures, rogue0 a dit :

Par curiosité, comment se comparent le C++ et ADA (+OS dédié) sur les contraintes temps réel aéro ?

Les deux langages (C++, ADA95) sont compilables sur les OS temps-réel genre VxWorks et à ma connaissance les performances sont les mêmes.

Le problème est plutôt comment on peut s'assurer que le programme que l'on écrit fonctionne bien (C++ est de ce point de vue beaucoup plus délicat à manipuler que ADA ou Java, cf mon post précédent).

Pour ceux qui s'intéressent aux méthodes de développement pour l'aéronautique, il y a un doc un peu ancien mais toujours valable de Dassault sur le net (http://jl.domec.free.fr/siteDjl_fichiers/TP-cours1EL/EMTI-CalculateurRafale/DassaultInformatiqEmbarq_Ledinot.pdf) qui donne quelques bonnes infos. On y voit en particulier comment le travail de conception est draconien en amont de tout codage. Cocorico, on est assez bons en France sur ce genre de chose, cf le M2000, l'A320, le Rafale... 

[g4lly]

2 hours ago, rogue0 said:

Par curiosité, comment se comparent le C++ et ADA (+OS dédié) sur les contraintes temps réel aéro ?

ADA ou Java - du moins RT java - par exemple sont conçu pour gérer finement les processus concurrents les temps exécutions etc. C'est beaucoup moins le cas pour C++ ...

Sinon de la doc sur comment le programme JSF entend coder en C++ pour du logiciel critique.

http://www.stroustrup.com/JSF-AV-rules.pdf

[Deres]

il y a 36 minutes, g4lly a dit :

ADA ou Java - du moins RT java - par exemple sont conçu pour gérer finement les processus concurrents les temps exécutions etc. C'est beaucoup moins le cas pour C++ ...

Sinon de la doc sur comment le programme JSF entend coder en C++ pour du logiciel critique.

http://www.stroustrup.com/JSF-AV-rules.pdf

Quelque soit l'environnement et le langage choisi, le secret reste cependant de ne pas faire un plat de spaghetti de tâches temps réel.

La complexité doit être au service du besoin et pas pour se faire plaisir.

Souvent, les logiciels critiques à haut niveau utilisent des tâches cycliques de fréquence déterminés contenant de simples séquenceurs fonctionnels, charge au système de bien choisir la fréquence auquel une fonction a besoin de s'exécuter. L'utilisation d'interruption pour lancer une fonction doit correspondre à un besoin précis et ne pas être la norme.

[prof.566]

Merci ++ Deres. Je transmets de ce clic le document sur le F-35 au fiston qui va démarrer un cycle piscine) C++ à l'école 42.

[rendbo]

Il y a 22 heures, Stratogogo a dit :

Et autre question , est-ce que cela rend l'intégration de systèmes étrangers toujours possible ?

Oui, je pense, mais il devra normalement être fait par LM, car il n'est pas prévu que les clients aient accès au code. 

[zx]

En c++ l'un des points clés les plus important, c'est de bien comprendre les pointeurs, après ca va tout seul. contrairement aux langages java, ada, la mémoire n'est pas géré automatiquement par le programme, mais c'est au développeur de le faire, comme pour l'assembleur pour générer le code machine, on manipule directement des adresse mémoire sur une taille données, si on se trompe, boum! donc les pointeurs, il devra en manger matin, midi et soir. et en rêver la nuit. ensuite vient la notion de gestion des objets, instanciation, destruction.

Livre de chevet

https://www.amazon.fr/C-Programming-Language-Bjarne-Stroustrup/dp/0321563840/ref=sr_1_2?ie=UTF8&qid=1476553450&sr=8-2&keywords=c%2B%2B

Modifié le 15 octobre 2016 par zx

[FATac]

Pour l'expérience que j'en ai eu, quand bien même on maitrise les allocations/libérations de mémoire ainsi que les mécanismes de pointeurs, le plus gros piège du C++ dans un environnement temps-réel, c'est de maitriser l'instanciation, les constructeurs et les destructeurs.

Si les contructeurs/destructeurs font de l'allocation/libération de mémoire, alors la création ou l'instanciation temporaire de nouveaux objets va, nécessairement, prendre un temps susceptible de manquer sur les autres traitements.

J'ai vu des classes "numériques" multiplier les objets temporaires lors d'opérations basiques, avec passage par les constructeurs/destructeurs pour chacun des opérandes ET pour le résultat final, alors que les structures d'appel contenait déjà tout ce qu'il fallait pour accueillir tout ça ... mauvais design, certes, mais design classique, par un programmeur objet plutôt doué, mais ignorant des contraintes temps-réel et des modalité d'implémentation de son compilateur (ultra paramétrable et méga bourré d'options, sur IBM RS/6000).

Sinon, sans objet, pour éviter ce type de piège, le C++ redevient quasiment du C et on en perd le principal avantage.

[Deres]

Dans un logiciel de sécurité, on évite au maximum tout ce qui est pointeur et allocation dynamique.

Comme cela, pas besoin de maîtriser et de faire très attention puisqu'on s'interdit tous les "pièges à cons" classiques.

On n'utilisera les mécanismes de code complexe que quand on a des besoins fonctionnelles le justifiant (besoin de réactivité, d'économie CPU ou de mémoire).

Généralement, la partie complexe du code est faite au début du projet au niveau du design par des personnes très expérimentés et le reste du développement est du "code bateau" à base de if-then-else.

[zx]

Pour les parties crypto secu, elles sont généralement faites en C, on évite le C++,  il est interdit d'utiliser des allocation dynamique,  puis utilisation des obfucateurs, ensuite ca passe à la moulinette de l'audit, qui cherche la faille ou la moindre données accessible, ce sont des gens très expérimentés.

Modifié le 15 octobre 2016 par zx

[g4lly]

1 minute ago, zx said:

Pour les parties crypto secu, sont generalement fait en c, on évite le c++,  il interdit d'utiliser des allocaton dynamique,  puis utilisation obsfucateurs

Pour tout ce qui est de bas niveau et de petite taille le "c" est souvent une bonne solution, c'est "simple", très rapide - quasi autant que l'assembleur si le compilo est bon - et ca se debug bien tant que le programme n'est pas bien long. Au delà on "mélange" en appelant depuis Java, Ada, C++ des éléments codé en C. En général ca permet de profiter des avantages des divers langage pour chacune des fonctionnalité. L'exemple typique ce sont les pilote hardware ... souvent le C va tres bien, et produit du code léger, tres efficace et généralement portable.

[Shorr kan]

Messieurs, en tant que néophyte, c'est toujours un plaisir de vous lire quand la discutions porte sur la partie logiciel du programme et dans l’aéronautique en général . 

 

Il y a 3 heures, prof.566 a dit :

Merci ++ Deres. Je transmets de ce clic le document sur le F-35 au fiston qui va démarrer un cycle piscine) C++ à l'école 42.

Bonne chance pour lui !