Rivelo

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

Pour revenir sur la question des missions des FTI, une petite piqûre de rappel en provenance du Yemen (cf le fil AD qui va bien) : les missiles anti-navire d'origine chinoise/iranienne sont en train de proliférer au Moyen Orient (y compris au Yemen) et certaines factions auraient trouvé le moyen de les tirer depuis la terre sur des cibles à distance des côtes. Pour l'instant, les cibles sont des navires logistiques des flottes saoudiennes ou émiraties mais ce n'est que le début. La question des capacité AAW (cf discussion précédente dans le fil) n'est donc pas théorique du tout. Et il ne s'agit pas simplement d'assurer l'auto-protection de la frégate elle-même (façon FLF) mais d'être capable de sécuriser un convoi de bâtiments "pas furtifs" ou une zone. Je commence à mieux "visualiser" à quoi va servir le SF500 et ses Asters...

Make In India C'est les lots ultérieurs qui pourraient être fabriqués sur place.

Cela parle ce matin de FTI dans un article du site ttu.fr (http://www.ttu.fr/5897-2/) On resterait dans un domaine très classique en termes d'artillerie, avec comme pour la Fremm la porte ouverte à du plus lourd pour les clients export...

Pour adresser certains des points, des parallèles peuvent être fait avec les grandes entreprises ou les autres administrations publiques. La bureaucratisation, le carriérisme, l'étouffement des "gens du terrain" par des cadres "plus politiques" dans la hiérarchie, le cloisonnement par métier par exemple sont des problèmes assez fréquents dans les grandes structures. Pour la remise en cause de West Point, on peut faire le parallèle avec la remise en cause du rôle des énarques ou des grands corps d'ingénieurs par exemple... La bonne nouvelle, c'est que, au moins sur certains points, il y a des recettes éprouvées dans le civil dont on peut s'inspirer. La généralisation des équipes projet permet de casser les silos de manière efficace et offre une vraie souplesse d'adaptation (dans le monde militaire, c'est ce que l'on fait avec les GTIA en OPEX par exemple). La responsabilisation à un niveau assez bas de la structure sur les résultats permet d'éviter la paralysie bureaucratique (dans le domaine militaire, on peut penser au niveau de d'autonomie réel donné au commandement niveau groupe/section sur le terrain ou à ce que l'officier marinier est autorisé à faire de son propre chef devant sa console). La généralisation d'une culture "du résultat" dans la rémunération et la progression de carrière (ces deux points étant liés dans la fonction publique) permet de valoriser les bosseurs qui mouillent la chemise sur le terrain et d'éviter les phénomènes de cour. Aucun de ses concepts ne sont vraiment nouveau pour les armées. En cherchant bien, on trouve toujours des cas d'unités qui performent bien et que l'on peut prendre en exemple (et à chaque fois on retrouve les même "ingrédients" de performance quand on sait quoi chercher). Dans mon boulot actuel, cela m'arrive d'ailleurs de les utiliser pour expliquer à des civils comment cela pourrait mieux marcher dans leur équipe. L'exemplarité par exemple est une valeur militaire. Le rôle donnés aux sous-officiers dans les unités d'élite est aussi très instructif. L'amélioration permanente est à la base de toutes les théories managériales récentes (ex : Lean), on peut l'illustrer avec l'utilisation des RETEX. De manière générale, le pragmatisme des militaires quand ils font la guerre est souvent remarquable. C'est quand les militaires ne font plus la guerre que cela se gâte... La motivation flanche, les structures se fossilisent, il devient difficile de distinguer les bons des mauvais, le recrutement se biaise (cela devient un job de fonctionnaire comme un autre), on arrive plus à attirer les meilleurs candidats, on perd la boussole pour choisir les bons investissements à faire. Cela m'arrive aussi d'utiliser ce contre-exemple... Vu de loin, j'ai l'impression que c'est le mal qui ronge l'US Army en ce moment...

La New Glenn fait un peu la taille d'une Saturn V mais elle n'en pas la puissance. Le méthane liquide n'est pas très dense en comparaison de l'hydrogène ou du kérosène. D'où un premier étage très volumineux en comparaison d'autres modèles. C'est pour cela qu'une "New Amstrong" est évoquée pour plus tard. C'est pas mauvais, c'est juste très, très américain John Glenn est encore aujourd'hui très connu là-bas car, outre son titre de gloire d'être le premier astronaute US à avoir un fait un vrai vol orbital, il a ensuite été une figure publique (il a été élu au sénat pendant 25 ans) avant de revoler sur navette spatiale à la fin des années 80.

Repost dans le bon fil ! L’Europe valide le programme Ariane-6 http://www.lemonde.fr/economie/article/2016/09/14/l-europe-valide-le-programme-ariane-6_4997503_3234.html Le projet est lancé, le design figé, la structure industrielle restructurée... et maintenant le budget est débloqué. Yapluka !

Est-ce que il y a un topic spécifique sur Ariane 6 ? L’Europe valide le programme Ariane-6 http://www.lemonde.fr/economie/article/2016/09/14/l-europe-valide-le-programme-ariane-6_4997503_3234.html Le projet est lancé, le design figé, la structure industrielle restructurée... et maintenant le budget est débloqué. Yapluka !

C'est un peu simpliste en effet. Parfois c'est aussi une simplicité de langage pour parler des missions généralement confiées à ces bases. Brest devient synonyme de FOST et Toulon de GAN. Ainsi, une "Nouvelle FLF Brestoise" sera implicitement une FLF retrofitée pour avoir des capacités ASM renforcées (sonar remorqué, TLT) pour chasser sérieusement le sous-marin en zone côtière tandis que une "Nouvelle FLF toulonaise" serait une FLF à laquelle on aurait juste greffé un sonar de coque pour éviter de se prendre une mine dérivante. Tout est dans l'implicite et je suis d'accord que exprimé tel quel, c'est énervant. Si le débat, c'est d'éviter de couper la petite flotte en deux (avec des FLF "ASM renforcée" à Brest et des FLF "ASM minimum" à Toulon) comme on peut le lire entre les lignes du post du blog, je pense que la discussion fait de nouveau sens. Ce serait plus logique de prévoir les TLT et le sonar remorqué sur les FTI (plus gros flotteur, plus facile de prévoir le TLT et le sonar de coque si c'est d'origine) et limiter l'impact du retrofit sur les FLF (ex : sonar de coque que l'on sait faire sans tout modifier + MAJ électronique). Le regroupement des bâtiments par type dans les ports d'attache est pour moi un autre sujet, plutôt d'optimisation MCO / gestion RH.

Aux US, les relations homme/femme sont assez, voir très compliquées. Ce qui en France est perçu comme un geste de galanterie normal ou une petite mise en boite sympa que l'on peut se permettre entre collègues peut être compris là-bas comme du harcèlement sexuel (pas que dans l'armée, dans le civil aussi). J'imagine que le commandement des Marines a prévu un chaperon pour les deux cobayes féminines afin d'être sur que cette première expérience à forte visibilité se passe sans accroc (logique ceinture/bretelle).

J'ai côtoyé le commandant Caroline Aigle. Je ne sais pas si elle résistait mieux au G que d'autres mais son mental, sa combativité, son esprit, son intelligence et sa volonté de vaincre était incroyable. J'ai énormément de respect pour elle et ce qu'elle représente encore aujourd'hui après sa disparition prématurée. Alors oui, des femmes combattants cela existe. J'en ai rencontré une. A chaque fois que je lis des articles sur les différences anatomiques entre hommes et femmes dans le métier militaire qui "expliquent" le fait que certains postes soient réservés au hommes, je repense à elle. Une fois, je suis arrivé juste devant elle pendant un cross (... on galérait tous les deux en milieu de peloton). Est-ce que j'étais pour autant un meilleur combattant qu'elle ? Non, évidement non.