Le logiciel du F-35

[Boule75]

Quelques vagues nouvelles des soucis d'alimentation en oxygène (il ne me semble pas avoir vu ça ici), sur Luke AFB, pour le F-35A :

• l'enquête n'a pas permis d'identifier ce qui clochait avec l'OBOGS,
• ils préconisent une modification des lois logicielles de contrôle du débit en oxygène pour en fournir plus dans certains cas (et donc une nième mise à jour générale de tous les avions déjà produits, au niveau du firmware de l'OBOGS...)
• les vols ont repris avec de nouvelles restrictions du domaine (altitude max plus basse),
• un cas de sensation d'hypoxie a été relevé depuis, provoqué par une valve défectueuse : pour le coup, ils ont trouvé.

Modifié le 19 juillet 2017 par Boule75

[DEFA550]

Rien ne dit que quelque chose cloche avec l'OBOGS. L'incriminer de la sorte procède d'un raisonnement fondamentalement biaisé.

[Boule75]

il y a 2 minutes, DEFA550 a dit :

Rien ne dit que quelque chose cloche avec l'OBOGS. L'incriminer de la sorte procède d'un raisonnement fondamentalement biaisé.

C'est bien un peu ce que sous-tend l'article : ils vont augmenter le débit d'oxygène fourni par l'OBOGS lors de certaines séquences de vol pour atténuer le ressenti de manque des pilotes, en dépit du fait qu'aucun défaut n'ait été identifié sur l'OBOGS lui-même. Solution palliative, donc, voir mobilisation de l'effet placebo.

[DEFA550]

C'est une solution palliative visant à augmenter la marge à l'hypoxie à certaines altitudes faute d'avoir trouvé l'origine réelle du problème. Ca vient compléter le briefing sur la détection des symptômes, la réduction des vols aux altitudes concernées, et l'augmentation de la réserve minimal d'oxygène gazeux (secours).

Si la modification touche l'OBOGS c'est parce que l'architecture du système est ainsi faite. L'enrichissement de l'air en oxygène est gérée à son niveau, là où d'autres architectures délivrent une concentration constante diluée en aval selon besoins par un régulateur (en principe monté sur le siège). 

Quoiqu'il en soit, le fait qu'une mesure palliative soit prise à son niveau le désigne comme solution potentielle, pas comme coupable d'un problème.

[FATac]

C'est un raisonnement courant, bien que fondamentalement erroné, de supposer que l'origine d'un problème est nécessairement confondue avec l'endroit où l'on applique les solutions.

[Deres]

il y a 41 minutes, FATac a dit :

C'est un raisonnement courant, bien que fondamentalement erroné, de supposer que l'origine d'un problème est nécessairement confondue avec l'endroit où l'on applique les solutions.

Oui, les responsables logiciels pourront t'en parler en long, en large et en travers ...

[rendbo]

Le 19/07/2017 à 10:50, Boule75 a dit :

les vols ont repris avec de nouvelles restrictions du domaine (altitude max plus basse),

Si ça continue, l'avion n'aura le droit que de rouler sur la route, et encore, pas en montagne parce que ça monte trop haut. L'avantage c'est que les trappes seront ouvertes, et l'électronique n'aura plus jamais trop chaud. Ca résoudra aussi les problèmes de refuel par BOM, y aura qu'à s'arrêter à la station service...

et dire qu'on n'est pas encore vendredi !

[Picdelamirand-oil]

Moi je ne suis pas d'accord pour faire du bashing à propos du F-35 sur des problèmes qui sont de l'ordre de la mise au point.....même le Vendredi!

Par contre sur les problèmes sérieux ....oui!

Et pour moi les problèmes sérieux sont:

• Un problème de masse: de ce fait le F-35 ne satisfait pas les performances minimum d'autonomie de l'ORD. De plus il a subit une cure d'amaigrissement conduite en dépit du bon sens ce qui fait que la version B a des problèmes structuraux graves qui à ma connaissance ne sont pas réglés. Cette cure d'amaigrissement a aussi conduit à supprimer des dispositifs de sécurité ce qui entraîne les blagues sur l'incapacité du F-35 de voler par temps orageux.
• Un problème de chaleur: pour évacuer les calories afin de réduire la signature infrarouge de l'oiseau les US ont mis en place un système de refroidissement qui utilise le carburant. Ils ont sans doute trop misé dessus et ils n'arrivent pas dans les cas extrèmes à bien évacuer toutes les calories. Cela entraîne les blagues sur la peinture blanche des camions d'avitaillement et sur l'ouverture des soutes toutes les 10 minutes dans certaines conditions de vol.
• Un problème de vibration: Le F-35 est sujet à du Buffeting de manière permanente! Les conditions sont tellement mauvaises dans les soutes que cela réduit la vie opérationnelle des armes transportées.
• Un problème de casque: le programme F-35 a fait l'impasse sur le HUD car selon eux cela faisait double emploi avec le casque. Ils en sont à la troisième génération de casque , mais celui ci est encore trop lourd, trop gros (il cogne sur la verriere quand le pilote veut se retourner) et il fonctionne mal de nuit bien qu'il y ait eu des progrès sur ce point. Comme il n'y a pas de HUD ces points sont critiques.
• Un problème d'ALIS: c'est une usine à neutron mais on ne peut pas s'en passer. Alis permet de plus aux Américains de controler l'usage que les alliés font du F-35, il permet au Chinois de tout savoir du F-35, et au Russes de pouvoir bloquer toutes la flotte de F-35 en coupant des cables bien choisis dans l'atlantique.
• Un problème de logiciel critique: Le logiciel critique du F-35 n'a pas été développé en suivant les normes nécessaires à ce type de logiciel.
• Un problème de coût: L.M. ne peut résoudre ce problème que par la diffusion de fausses informations.
• Un problème de délai: Le F-35 n'aura rien de rare quand il sera enfin opérationnel, il sera juste temps de traiter les obsolescences.
• Un problème de "concurrency": Ce type de développement consiste à mettre la charrue avant les boeufs, cela se traduit par des centaines d'avions qu'il faudra rétroffiter avant de pouvoir les utiliser dans de vraies opérations, c' est principalement cette approche qui est responsable des problèmes de coût et de délai déjà cités.

[Henri K.]

Le 20/7/2017 à 14:22, Picdelamirand-oil a dit :

• Un problème de logiciel critique: Le logiciel critique du F-35 n'a pas été développé en suivant les normes nécessaires à ce type de logiciel.

Quelles normes précisément ?

Henri K.

[FATac]

Je ne crois pas qu'ils soient concernés par les niveaux de SPICE.

[Picdelamirand-oil]

Il y a 5 heures, Henri K. a dit :

Quelles normes précisément ?

Henri K.

De mon temps c'était DO 178 B level A. Aujourd'hui je ne sais pas.

[zx]

Biggest Challenge Facing USAF’s Top Weapons Buyer? Software

http://aviationweek.com/defense/biggest-challenge-facing-usaf-s-top-weapons-buyer-software

si pb d'accès.

 

Biggest Challenge Facing USAF’s Top Weapons Buyer? Software

The U.S. Air Force’s new acquisition chief wants to revolutionize the way the service develops and buys cutting-edge technology—and his first step will be fixing the Pentagon’s software problem.

The Air Force’s biggest-ticket weapons systems—Lockheed Martin’s F-35Joint Strike Fighter, Northrop Grumman’s B-21 bomber and Boeing’s KC-46 tanker—are flying computers as well as warfighting machines, reliant on advanced computing and millions of lines of code. But it is these software-intensive programs that most often rack up cost overruns and schedule delays, said Will Roper, the Air Force’s assistant secretary for acquisition, technology and logistics. 

It may be time for the Air Force—and perhaps the Department of Defense as a whole—to rethink whether an acquisition system developed to buy things like submarines and ground vehicles applies to software that changes every day, Roper told reporters during a recent Pentagon roundtable.

“In my view, it simply doesn’t,” Roper said. “So one of the things that I have to make the shift on in this job is getting the Air Force where we can do agile software development.”

“Agile” software development, as opposed to the traditional “waterfall” model of building and releasing software in large chunks over months or even years, involves smaller, more frequent software drops, much like the way a user gets iPhone updates.

Of course, an F-35 is not an iPhone, Roper acknowledges. But from a software development perspective, the two are not so different, he said.

“In many ways in today’s world there’s not as big of a difference from a software development mindset between developing a lot of parallel software stacks for a commercial device as there is for a military system,” Roper said. “It shouldn’t matter—if you can do it one or two times then you can go the rest of the way, and that actually is what gives me a lot of hope in thinking about how to steer the Joint Strike Fighter program.”

But moving to an agile software model, for the F-35 or any software-intensive program, will require a major culture shift, Roper said. Acquisition professionals, who were trained “in a different era,” are not accustomed to testing and certifying weapons systems quickly, Roper said.

“Heck, you could imagine in a future war we could be changing software every day of the war as a necessary factor for winning,” Roper said. “So how do we do that?”

For the F-35 in particular, the ability to get agile software right will be crucial, both to Block 4 follow-on development and to effective sustainment. Roper believes the program could benefit from some agile software development “pathfinders” prior to Block 4 as a test run. The maintenance and sustainment side of the house, which is where most of the cost of the program will be as it wraps up development, “would be good places to begin,” Roper said.

“Things like [the Autonomic and Logistics Information System (ALIS)] or the [Mission Data Files] are things we can work on to prove to ourselves that we really can do this drop of software every couple of weeks or every couple of months and sustain that over time,” Roper said. “We don’t have all the i’s dotted, the t’s crossed but ... I see some reasons to be cautiously optimistic.”

Roper believes many of the F-35’s sustainment challenges would be solved with better software development. ALIS for instance, a predictive maintenance system designed to automatically track the health of each component of each F-35 worldwide, runs on software, but it is built on a 1990s architecture that badly needs an update.

“It’s kind of like if you could solve this one thing, the dominos would fall over,” Roper said.

Roper is also working to ensure the Air Force can recruit and retain talented software developers to help transition to an agile model—both from inside and outside the service.

He pointed to Raytheon’s new “DevOps” application of commercial best practices such as cloud technologies and automation to another long-delayed, software-intensive program, the next-generation GPS ground control system (OCX), as a sign of progress.

“We’re not asking for something that’s crazy. We’re asking for something that’s common practice in one industry to be applied here,” Roper said.

 

Modifié le 1 mai 2018 par zx

[Picdelamirand-oil]

Le 1/5/2018 à 20:29, zx a dit :

Biggest Challenge Facing USAF’s Top Weapons Buyer? Software

http://aviationweek.com/defense/biggest-challenge-facing-usaf-s-top-weapons-buyer-software

si pb d'accès.

  Révéler le texte masqué

Biggest Challenge Facing USAF’s Top Weapons Buyer? Software

The U.S. Air Force’s new acquisition chief wants to revolutionize the way the service develops and buys cutting-edge technology—and his first step will be fixing the Pentagon’s software problem.

The Air Force’s biggest-ticket weapons systems—Lockheed Martin’s F-35Joint Strike Fighter, Northrop Grumman’s B-21 bomber and Boeing’s KC-46 tanker—are flying computers as well as warfighting machines, reliant on advanced computing and millions of lines of code. But it is these software-intensive programs that most often rack up cost overruns and schedule delays, said Will Roper, the Air Force’s assistant secretary for acquisition, technology and logistics. 

It may be time for the Air Force—and perhaps the Department of Defense as a whole—to rethink whether an acquisition system developed to buy things like submarines and ground vehicles applies to software that changes every day, Roper told reporters during a recent Pentagon roundtable.

“In my view, it simply doesn’t,” Roper said. “So one of the things that I have to make the shift on in this job is getting the Air Force where we can do agile software development.”

“Agile” software development, as opposed to the traditional “waterfall” model of building and releasing software in large chunks over months or even years, involves smaller, more frequent software drops, much like the way a user gets iPhone updates.

Of course, an F-35 is not an iPhone, Roper acknowledges. But from a software development perspective, the two are not so different, he said.

“In many ways in today’s world there’s not as big of a difference from a software development mindset between developing a lot of parallel software stacks for a commercial device as there is for a military system,” Roper said. “It shouldn’t matter—if you can do it one or two times then you can go the rest of the way, and that actually is what gives me a lot of hope in thinking about how to steer the Joint Strike Fighter program.”

But moving to an agile software model, for the F-35 or any software-intensive program, will require a major culture shift, Roper said. Acquisition professionals, who were trained “in a different era,” are not accustomed to testing and certifying weapons systems quickly, Roper said.

“Heck, you could imagine in a future war we could be changing software every day of the war as a necessary factor for winning,” Roper said. “So how do we do that?”

For the F-35 in particular, the ability to get agile software right will be crucial, both to Block 4 follow-on development and to effective sustainment. Roper believes the program could benefit from some agile software development “pathfinders” prior to Block 4 as a test run. The maintenance and sustainment side of the house, which is where most of the cost of the program will be as it wraps up development, “would be good places to begin,” Roper said.

“Things like [the Autonomic and Logistics Information System (ALIS)] or the [Mission Data Files] are things we can work on to prove to ourselves that we really can do this drop of software every couple of weeks or every couple of months and sustain that over time,” Roper said. “We don’t have all the i’s dotted, the t’s crossed but ... I see some reasons to be cautiously optimistic.”

Roper believes many of the F-35’s sustainment challenges would be solved with better software development. ALIS for instance, a predictive maintenance system designed to automatically track the health of each component of each F-35 worldwide, runs on software, but it is built on a 1990s architecture that badly needs an update.

“It’s kind of like if you could solve this one thing, the dominos would fall over,” Roper said.

Roper is also working to ensure the Air Force can recruit and retain talented software developers to help transition to an agile model—both from inside and outside the service.

He pointed to Raytheon’s new “DevOps” application of commercial best practices such as cloud technologies and automation to another long-delayed, software-intensive program, the next-generation GPS ground control system (OCX), as a sign of progress.

“We’re not asking for something that’s crazy. We’re asking for something that’s common practice in one industry to be applied here,” Roper said.

 

Traduction

Le plus grand défi auquel est confronté le meilleur acheteur d'armes de l'USAF ? Logiciels

Le nouveau chef des acquisitions de l'U.S. Air Force veut révolutionner la façon dont le service se développe et achète une technologie de pointe - et sa première étape sera de régler le problème de logiciel du Pentagone.

Les plus gros systèmes d'armes de la Force aérienne - le F-35Joint Strike Fighter de Lockheed Martin, le bombardier B-21 de Northrop Grumman et le tanker KC-46 de Boeing - sont des ordinateurs volants ainsi que des machines de combat, qui dépendent de l'informatique avancée et de millions de lignes de code. Mais ce sont ces programmes à forte intensité logicielle qui entraînent le plus souvent des dépassements de coûts et des retards, a déclaré Will Roper, secrétaire adjoint à l'acquisition, à la technologie et à la logistique de la Force aérienne. 

Il est peut-être temps que la Force aérienne - et peut-être le ministère de la Défense dans son ensemble - repense à la question de savoir si un système d'acquisition mis au point pour acheter des choses comme des sous-marins et des véhicules terrestres s'applique aux logiciels qui changent tous les jours, a dit M. Roper aux journalistes lors d'une récente table ronde du Pentagone.

"À mon avis, ce n'est tout simplement pas le cas, a dit M. Roper. "Donc, l'une des choses que je dois faire dans ce travail, c'est d'obtenir la Force aérienne où nous pouvons faire du développement logiciel agile."

"Le développement de logiciels "agiles", par opposition au modèle traditionnel de "chute d'eau" qui consiste à construire et à publier des logiciels en gros morceaux sur des mois ou même des années, implique des chutes de logiciels plus petites et plus fréquentes, un peu comme la façon dont un utilisateur obtient les mises à jour de son iPhone.

Bien sûr, un F-35 n'est pas un iPhone, reconnaît Roper. Mais du point de vue du développement de logiciels, les deux ne sont pas si différents, a-t-il dit.

"À bien des égards, dans le monde d'aujourd'hui, il n'y a pas autant de différence entre le développement d'un grand nombre de piles de logiciels parallèles pour un appareil commercial que pour un système militaire ", a dit M. Roper. "Cela ne devrait pas avoir d'importance - si vous pouvez le faire une ou deux fois, alors vous pouvez faire le reste du chemin, et c'est en fait ce qui me donne beaucoup d'espoir en pensant à la façon de diriger le programme Joint Strike Fighter.

Mais le passage à un modèle logiciel agile, pour le F-35 ou tout autre programme à forte intensité logicielle, exigera un changement de culture majeur, a dit M. Roper. Les professionnels de l'acquisition, qui ont été formés "à une époque différente", n'ont pas l'habitude de tester et de certifier rapidement les systèmes d'armes, a dit M. Roper.

"Heck, vous pourriez imaginer que dans une guerre future, nous pourrions changer de logiciel tous les jours de la guerre comme un facteur nécessaire pour gagner ", a dit M. Roper. "Alors, comment on fait ça ?"

Pour le F-35 en particulier, la capacité à obtenir un logiciel agile sera cruciale, à la fois pour le développement de suivi de Block 4 et pour un soutien efficace. Roper pense que le programme pourrait bénéficier d'un certain nombre de "pathfinders" de développement logiciel agile avant le bloc 4 à titre de test. L'entretien et le soutien de la maison, qui est l'endroit où se situera la plus grande partie du coût du programme au fur et à mesure que le développement s'achèvera, " serait un bon point de départ ", a dit M. Roper.

"Des choses comme[le Système d'Information Autonomique et Logistique (ALIS)] ou les[Fichiers de Données de Mission] sont des choses sur lesquelles nous pouvons travailler pour nous prouver que nous pouvons vraiment faire cette goutte de logiciel toutes les deux semaines ou tous les deux mois et maintenir cela dans le temps", a dit M. Roper. "Nous n'avons pas tous les i pointillés, les t sont croisés mais .... Je vois des raisons d'être prudemment optimiste."

Roper croit que bon nombre des problèmes de maintien en puissance du F-35 seraient résolus grâce à un meilleur développement logiciel. ALIS par exemple, un système de maintenance prédictive conçu pour suivre automatiquement l'état de santé de chaque composant de chaque F-35 dans le monde entier, fonctionne avec un logiciel, mais il est construit sur une architecture des années 1990 qui a grand besoin d'une mise à jour.

"C'est un peu comme si vous pouviez résoudre cette seule chose, les dominos tomberaient ", a dit M. Roper.

Roper s'efforce également de s'assurer que la Force aérienne peut recruter et conserver des développeurs de logiciels talentueux pour faciliter la transition vers un modèle agile, tant à l'intérieur qu'à l'extérieur du service.

Il a souligné que la nouvelle application par Raytheon des meilleures pratiques commerciales telles que les technologies et l'automatisation des nuages à un autre programme à long terme et à forte intensité logicielle, le système de contrôle au sol (OCX) de la prochaine génération de GPS, est un signe de progrès.

"Nous ne demandons pas quelque chose de fou. Nous demandons qu'une pratique courante dans une industrie soit appliquée ici ", a dit M. Roper.

Modifié le 27 juin 2018 par Picdelamirand-oil

[prof.566]

DO178B mais...

 

https://news.ycombinator.com/item?id=13810148

un peu de biblio

 

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

 

 

https://www.militaryaerospace.com/articles/2013/10/software-code-f-35.html

 

Si un pro le sent...

 

Celle ci est savoureuse... https://www.unsw.adfa.edu.au/capability-systems-centre/sites/csc/files/uploads/3. Morris - Pitman UNSW Briefing.pdf

Modifié le 27 juin 2018 par prof.566

[Picdelamirand-oil]

il y a une heure, prof.566 a dit :

DO178B mais...

https://news.ycombinator.com/item?id=13810148

un peu de biblio

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

https://www.militaryaerospace.com/articles/2013/10/software-code-f-35.html

Si un pro le sent...

Celle ci est savoureuse... https://www.unsw.adfa.edu.au/capability-systems-centre/sites/csc/files/uploads/3. Morris - Pitman UNSW Briefing.pdf

J'avais commencé une discussion sur ce sujet après avoir appris que les FCS avaient été développées sans appliquer la DO 178 B

http://www.air-defense.net/forum/topic/29-le-f-35/?do=findComment&comment=905745

 

[herciv]

il y a 11 minutes, Picdelamirand-oil a dit :

J'avais commencé une discussion sur ce sujet après avoir appris que les FCS avaient été développées sans appliquer la DO 178 B

http://www.air-defense.net/forum/topic/29-le-f-35/?do=findComment&comment=905745

 

Moi pas comprendre : il compte faire du logiciel agile en partant d'une base malsaine ?

[Picdelamirand-oil]

il y a 1 minute, herciv a dit :

Moi pas comprendre : il compte faire du logiciel agile en partant d'une base malsaine ?

C'est une idée de chef.

[zx]

JSF,  no segfault, je demande à voir,  :P :P

[herciv]

il y a 53 minutes, Picdelamirand-oil a dit :

C'est une idée de chef.

BOn bah avec le f4 on se mettait à la hauteur des specs du f-35, ben avec une telle idée je pense que le F5/MLU va le dépasser.

 

Modifié le 27 juin 2018 par herciv

[herciv]

@Picdelamirand-oil

dans la méthode que tu nous décrite il y plusieurs pages, tu estimais ou pas une linéarité des méthodes et du management ?

Peut-être que ma question n'a pas de sens ?

[Picdelamirand-oil]

Il y a 3 heures, herciv a dit :

@Picdelamirand-oil

dans la méthode que tu nous décrite il y plusieurs pages, tu estimais ou pas une linéarité des méthodes et du management ?

Peut-être que ma question n'a pas de sens ?

Je ne sais pas si elle a du sens, mais j'ai du mal à la comprendre.

[herciv]

il y a 2 minutes, Picdelamirand-oil a dit :

Je ne sais pas si elle a du sens, mais j'ai du mal à la comprendre.

Par exemple passer d'un développement en V à un developpement agile, ou inclure la concurrency qui joue à la fois sur le dev et la prod ou rogner les efforts de certifications ?

[Rivelo]

il y a une heure, herciv a dit :

Par exemple passer d'un développement en V à un developpement agile, ou inclure la concurrency qui joue à la fois sur le dev et la prod ou rogner les efforts de certifications ?

L'introduction d'une méthode agile pour remplacer le cycle en V traditionnel sur un logiciel existant se fait assez facilement quand on est en phase de maintenance évolutive (on fractionne les changements à apporter pour qu'ils deviennent sécable en petites évolutions incrémentales, puis on applique un cycle de développement agile à chacune de ces modifications incrémentales du logiciel). Ce n'est pas incompatible avec un release management figeant de manière régulière une version stable à déployer largement ou à utiliser par défaut (c'est de toute façon une bonne pratique sur tous les systèmes critiques de ne pas livrer en permanence et de bien tester à fond avant chaque upgrade majeur). 

Ceci étant dit, je ne pense pas que l'on en soit là sur le F35. Ils sont toujours en train de courir après le cahier des charges initial...

[DEFA550]

Il y a 3 heures, Rivelo a dit :

Ceci étant dit, je ne pense pas que l'on en soit là sur le F35. Ils sont toujours en train de courir après le cahier des charges initial...

Autrement dit, ils sont en VFR, de nuit, en plein brouillard.

[Boule75]

il y a 17 minutes, DEFA550 a dit :

Autrement dit, ils sont en VFR, de nuit, en plein brouillard.

Mais ils klaxonnent !