Rivelo

La mission a permis de valider beaucoup de choses (ex : tenue bouclier thermique, déploiement parachute) et, comme tu le dis, de collecter pleins d'infos sur le comportement dynamique de la capsule. Ce serait tentant d'analyser à fond ce qui a pu se passer sur la fin du vol pour trouver la cause racine et refaire un essai. Mais effectivement cela va être dur de convaincre tous les partenaires européens d'ici à la prochaine réunion ministérielle de novembre... Le risque, ce serait plutôt que certains prennent peur et refuse d'allonger l'argent pour finir le rover

C'était le moment que je préférais en mission sur mon aviso : quand, au poste de combat, le cuistot se déguisait en ninja et s'installait derrière sa 12,7mm. Je n'aurais pas aimé être le gars en face, c'était une très bonne gachette Blague à part, en asymétrique, le mode "corsaire" avec les commandos et la BP en action, ça le fait. C'est juste usant si on doit tenir le dispositif longtemps (d'où l'intérêt des Narwhal télé-opérés depuis l'intérieur) mais en cas de coup de chaud, c'est dissuasif.

D'autant plus bizarre que la zone d’atterrissage (amarissage ?) prévue est très bien cartographiée (c'est la zone dans laquelle Opportunity évolue depuis 10 ans). Après, cela demandera du temps pour faire faire à MRO des observations systématiques de la zone, de chercher l'aiguille dans la botte de foin (taille de Schiaparelli : environ 1 ou 2 pixels...).

C'est ce type de trajectoire a insertion directe qui est utilisée pour tous les rovers (dont Opportunity, Spirit, Curiosity et potentiellement Exomars 2020). La vitesse d'entrée est plus élevée, il ne faut pas se planter sur la trajectoire, mais cela permet de poser au sol une masse plus importante (on économise le carburant qui aurait été nécessaire pour freiner et satelliser la sonde).

Les brouilleurs sont prévus ("fitted for") et présents sur la maquette de la FTI sur le stand DCNS (modèle export full option). Il y en a un sur tribord avant de la passerelle (sur l'emplacement qui est occupé à bâbord par le Narwhal) et l'autre sur bâbord arrière, "en diagonal". Pas prévu pour l'instant sur la FTI française, mais j'imagine que cela doit possible de les poser en retrofit. Coté guerre elec, il y avait un détecteur radar dans la mature et un intercepteur de com si ma mémoire est bonne.

Oui, je confirme, il y a une nouvelle maquette du BRAVE sur le stand STX.

Sur le modèle full option DCNS, je les ai vu et ils étaient cités. Par contre, sur la FTI montrée sur le stand du ministère de la Défense, il n'y avait que les lance-leurre ASM et la personne qui était là m'a confirmé que les lance leurre anti-missile n'étaient pas prévu pour la version de 2023. Pas de doute que Lacroix sait faire. Je ne serai pas étonné que cela soit uniquement uniquement une histoire de budget. (PS : c'était amusant de jouer au jeu des 7 différences entre les deux stands ;-) )

Autres infos : L'innovation sur la défense à vue, c'est un local derrière la passerelle dans lequel serait projeté une vue en réalité augmentée à 360 degré autour du bâtiment (avec fusion des données des autres capteurs en surimpression et vue "tout temps" pour voir dans le noir). On voit les caméras sur la mature de la maquette de FTI française Pour l'hélico, ce serait un NH90 OU un Panther et un drone. Cela dépend bien sur du drone qui n'existe pas encore mais c'est l'hypothèse de travail. Mix de 16 Aster 15 ou 30. Les deux modèles de missile étaient exposés sur le stand MBDA et on voyait bien que l'Aster 30 est une version rallongée de 50 cm avec un booster plus long. Les deux engins sont très similaires. On voyait aussi un Mica VL qui en fait est à peine moins encombrant qu'un Aster 15 pas beaucoup d'infos sur le système d'arme mais Thalès met en avant ses nouvelles consoles et cela parle beaucoup de fusion de donnée poussée (façon F35... cela promet) Possibilité d'avoir un bâtiment rallongé façon break familial pour les clients exports. La "flexzone" supplémentaire (tronçon rallongé) est prévu sous les Exocets et permettrait de stocker du matériel pour les forces spéciales, des conteneurs etc... Ou de faire des customisations ? Evidemment, la maquette du stand DCNS montre un bâtiment full option (avec lance-leurre ASM ET anti-missile, brouilleurs "en diagonale", disposés symétriquement par rapport aux Narwhals, 32 VLS). L'installation de quelques Mdcn en silos verticaux est techniquement possible si c'est prévu dès l'origine d'après la personne de DCNS avec qui j'ai parlé.

Ben... Il n'y a déjà plus de TAG. Ce sera du CODAD (Diesel + Diesel), comme les FLF. 32MW (4 * 8 MW) pour la FTI française (donnée pour 26 noeuds), et jusqu'à 40 MW (4 * 10MW) pour les modèles exportation (pour atteindre 29-30 noeuds). Ce sera quand même très pêchu comme motorisation. Concernant les SAM, la personne de la DGA avec laquelle j'ai parlé cet après-midi sur le salon laissait entendre que le passage à 32 missiles était une "modularité de conception". C'est à dire que il faut que cela soit prévu dès l'origine, sinon l'espace libre sera utilisé à d'autres fins. Sinon, on peut remarquer que si la protection anti-missile pose un peu question (pas de brouilleur prévu sur la FTI française pour l'instant, pas de lance-leurre anti-missile non plus, protection anti-aérienne courte portée absente), la partie ASM est très complète : sonar de coque, sonar trempé "Captas 4 Compact", torpilles, NH90, et même lance-leurre anti-torpilles. En fait, ils ont lu le forum AD et fait la super FLF ASM dont on parlait cet été sur le fil :-)

Allez, pour se changer les idées et faire le vide, retour aux fondamentaux du fil...

Il y a cette semaine un article intéressant dans Air & Cosmos sur l'utilisation de l'Alouette III dans la formation initiale des pilotes de l'aéronavale. On y retrouve pas mal d'info déjà cités dans le forum (ex : RSA des Alouettes SA316N en 2019, renforts de H120 d'Helidax pour palier les indispos des Alouettes) avec quelques anecdotes amusantes (ex : ajustement créatif du programme de formation car le H120 doit rester au dessus de la terre ferme !) En creux, le rappel du besoin de son doter d'un hélicoptère léger (pour l'écolage), biturbine (pour préparer les pilotes aux Panthers/NH90), capable d'aller se promener près des cotes (kit de flottaison) et d'apponter (ils ne parlent pas des roulettes dans l'article). Et à la fin la promesse de refondre la formation autour de cet appareil lorsqu'il sera dispo. Tiens, cela fait penser à la définition du HIL

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...

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.

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.

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)...

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.

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.

LM s'est pris les pieds dans le tapis en communicant ce chiffre. D'abord, c'était un moyen marketing d'illustrer la supériorité supposée de leur système d'arme. Puis, c'est devenu une excuse pour expliquer les difficultés de mise au point de leur système. Et maintenant, par effet boomerang, cela devient une "preuve" de la complexité du projet... Je suis moi aussi assez curieux de savoir un peu mieux comment ils ont architecturé leur bazar. En tout cas, ils ont manifestement succombé au premier péché capital de l'IT : le péché d'orgueil de penser que cela vaut mieux de partir d'une feuille blanche. 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 ?...

Le nombre de lignes de code n'est pas un indicateur très fiable pour jauger un logiciel. Je m'explique. Dans les années 80, chaque ligne de code (en ADA, en C, en Pascal ou tout autre language utilisé) était écrite à la main, avec un processus de conception assez cadré (on écrivait beaucoup de texte de spécification avant de programmer quoi que ce soit). C'était déjà un gros progrès par rapport à l'écriture bas niveau en langage machine (le compilateur traduit le language fait beaucoup de vérifications et génère l'exécutable en évitant beaucoup d'erreurs humaines de retranscription). A cette époque, les micro-processeurs et la mémoire étaient environ 10 000x moins importante qu'aujourd'hui, donc on optimisait beaucoup la taille des programmes. Et par ailleurs, comme c'était écrit à la main, les ingénieurs trouvaient des astuces pour écrire le moins de lignes possibles. Aujourd'hui, les ressources CPU et mémoire sont tellement sur-abondantes que les méthodes de developpement logiciel ont évolué. On continue l'approche traditionnelle quand on fait des logiciels très petits qui sont embarqués, mais de gros projets on utilise différentes librairies sur étagère (pas forcément optimisés pour ce que l'on veut faire mais c'est dispo donc on réutilise) et aussi des outils qui écrivent des lignes de code automatiquement (là aussi, c'est pas très optimisé mais cela tourne). Pour certains type de développement (ex : développement d'IHM), cela permet d'aller beaucoup plus vite mais si le développement n'est pas bien surveillé, cela peut avoir comme conséquence de faire des logiciels très peu performants, avec des bugs mal maitrisés (qui peuvent se loger dans des parties de code que l'on récupérer ou générés), très difficilement maintenables. La taille du programme témoigne plus de l'approche utilisés (quick and dirty ou conçu avec soin et fignolé à la main) que d'autre chose. Pour moi, 8 million de ligne, cela veut juste dire que cela a été fait avec une approche objet / code généré / reuse massif. Ce qui explique le cauchemar actuel pour fiabiliser le logiciel, l'optimiser et rajouter les fonctionnalités manquantes.

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). C'est un enjeu important de maitriser l'ensemble des couches (y compris l'OS et le compilateur) pour le développement de systèmes IT temps-réels. Cela avait fait débat au moment du lancement du programme Rafale (sur le thème "encore une vision nombriliste des français, yaka faire du ADA comme les US") mais je pense que le résultat parle de lui même maintenant... Le choix récent de C++ par LM vient du fait que ADA est vu au pays de la Silicon Valley comme quelque-chose de "old school" pour lequel il est difficile de trouver facilement des programeurs et des librairies de code toute faite. Tous les étudiants étudient le C++ à l'école et on peut bidouiller beaucoup de choses avec des bouts de logiciels récupérés à droite ou à gauche ou des générateurs de code. C'est donc plus facile de staffer un gros projet comme celui du F35, avec des ressources moins chères et disponibles "sur étagère" (pas besoin de les former à ADA, qui n'est utilisé que sur des projets militaires). Et au début, cela va plus vite (dans une logique quick and dirty). Le problème que cette approache pose est à deux niveaux : - C++ est plus sujet à des erreurs de programmation que ADA (ou que Java, utilisé habituellement dans les développements de serveur web). C'est justement pour palier aux risques inhérent au C que ADA avait été conçu (c'est un peu technique, mais ADA permet au compilateur de vérifier plus drastiquement le respect des spécifications d'interface et dispose notament, comme Java, de protections pour éviter les erreurs de pointeur). Le débuggage peut devenir très, très complexe sur un programme de 8 million de lignes. - Autre conséquence facheuse : il n'a pas été possible de récupérer pour le calculateur du F35 (réalisé en C++) le code du F22 (développé en ADA)... D'où le gap entre les deux plate-formes... Et l'absence de "reuse" entre les deux calculateurs qui suivent des roadmap parallèles. Le choix du language de programmation est un des nombreux éléments techniques mal maitrisés dans ce programme F35...

Oui, et cela explique certains des points de flou : - pourquoi le faible nombre de victimes - comment le navire a été identifié dans le trafic par les rebelles - pourquoi certains officiels émiriens prétendent que c'est un missile anti-char portable et pas un missile anti-navire - comment la vidéo de l'incendie s'est retrouvé sur le net ;-)

Oui, sur AD dans le fil "Modernisations des La Fayette et Floréal" C'est bien l'hypothèse de la récupération des SADRAL des FASM qui est évoquée.

On a déjà eu l'occasion d'échanger à ce sujet : je ne pense pas que mélanger le 2ème et 3ème niveau soit une bonne idée. J'assume complètement le fait que des brillants amiraux aient pu proposer le contraire en imaginant "BATSIMAR" dans une période de disette budgétaire extrême pour sauver les meubles. Mais cela n'en reste pas moins à mon avis une fausse piste.

Mistral par grappe de 6 (lanceurs SADRAL de récupération selon les infos sur le forum) + canon de 100mm Difficile de dire que FLF sont de rang 1 après... Par contre, c'est cohérent avec ce que les FS et les avisos ont.

Ce serait quand même hallucinant de se débarrasser des FLF et de garder en ligne des avisos à bout de souffle... A mon avis, on s'orient tout doucement au contraire vers la structuration d'un "niveau 2" dans nos frégates, constitué des FS et des FLF "rénové à minima". Des bâtiments d'environ 3000T, endurants, fiables, dotés d'une plate-forme avia, de capacités anti-navire dissuasives et d'une capacité à embarquer des commandos. Peu ou pas de capacités anti-aériennes, quelques nuances importantes (furtivité) qui joueront sur les zones de déploiement affectées à chacune de ces flottes. Mais des vecteurs très bien adaptés à des missions solos anti-piraterie, Narcops, à l'escorte de navires genre BPC dans des zones où on ne craint pas une agression missile, à l'affirmation de notre souveraineté, à la reconnaissance. Une fois ce "niveau 2" structuré avec des bâtiments adaptés, on pourrait dire au revoir aux avisos et les remplacer sans regrets par des navires moins armés comme les B2M ou d'autres projets d'OPC faiblement armés...