Picdelamirand-oil

On Base: Testing and Maintaining the F-35 at the PAX ITF NAS Patuxent River, Maryland // March 27, 2015 A 5th Generation fighter jet like the F-35 cannot begin to help secure our skies without first being pushed to its limits in rigorous testing. This means putting the Lightning II through scorching heat, frigid cold, hard-impact landings on the decks of aircraft carriers and careful touchdowns on wet runways. Throughout the vast array of tests, engineers at Naval Air Station Patuxent River (PAX) Integrated Test Force (ITF) in Maryland constantly monitor each part of the jet to ensure that all of the systems work together as they should. Brittany, an early career engineer, is one of the many engineers supporting flight test activities at PAX. Brittany’s role in flight test heavily focuses on monitoring and improving how the F-35 engine and lift fan interface with the rest of the aircraft. The Pratt & Whitney engine—capable of generating up to 40,000 pounds of thrust—creates heat as a by-product of its power. As it is carefully nestled in the back of the jet and immediately surrounded by critical hardware, Brittany must constantly monitor the area during testing and ensure all thermal readings are within normal limits. On the B variant, she also helps verify that the drive shaft—which spins the lift fan—is functioning properly. Brittany’s daily work on these integral elements of the jet allow her to have a unique hand in the success of every F-35 Lightning II that she and the PAX team test. Each time they encounter an unexpected result or challenge, Brittany and the flight test team must innovate and adjust their approach to problem-solve in real time. “I know for every test point we complete, we are constantly expanding the envelope of what the fleet can do with this aircraft,” she offers. From Land to Sea With plans for the F-35 to fly in the diverse environmental homes of our international partners around world, testing of the aircraft is robust and covers every possible flight scenario. During her time at PAX, Brittany has had the opportunity to support three separate flight test detachments: the F-35B Developmental Test-2 (DT-2) aboard the USS Wasp, F-35B wet runway and crosswind testing at Edwards Air Force Base (AFB) and most recently, F-35B climatic testing at Eglin AFB. “Supporting these detachments is one of my favorite parts of the job,” she offers with a smile. “It helps me shake it up a bit and gain new, valuable experiences.” Brittany’s three-week detachment to the USS Wasp for the second F-35B sea trials was by far her most unforgettable experience as a flight test engineer. “Working aboard a carrier for three weeks was a once in-a-lifetime opportunity,” she reflects. ”Looking back on it now it almost feels unreal—we were standing on deck not far from the aircraft, watching short takeoffs (STOs) and vertical landings (VLs). I feel incredibly lucky to have had that experience.” Brittany has also had her fair share of supporting various program firsts from the control room. She helped monitor test points during the first weapons separation, first vertical takeoff (VTO) and the first VL at night, both on land and at sea. Never a Dull Moment Brittany never imagined that this was the sort of hands-on work she would be doing just a few years out of school. “This is not at all what I imagined I would be involved in,” she reveals. “I thought I would be at a desk all day, working on some type of analysis or design for some tiny part. That is certainly a far cry from the dynamic work I do on the aircraft every day now.” “Dynamic” it certainly is. On a daily basis, Brittany works on everything from supporting flight test in the control room, which includes participating in mission briefs and debriefs, monitoring safety of test parameters and completing post-test activities. She can even find herself troubleshooting a problem on the aircraft, coordinating maintenance and regression activities, updating information on the screens used to monitor the aircraft in the control room, assisting in test planning or supporting an event at the Manned Flight Simulator. “I actually enjoy not always knowing what the day will bring,” she says. Brittany and her team constantly rise to the challenge of the unknown. After all, the goal of testing is to see how the aircraft behaves under different conditions and parameters. Any time an unexpected jet behavior occurs, it is the team on-site who must implement a solution in real time—and this is why the work of Brittany, her fellow flight test engineers and truly the whole team is instrumental in the success of the F-35. For Brittany, it is not only the work that she does, but also the team that she is a part of that makes her experience in flight test so rewarding. “The team at PAX is an extraordinary team. We are fully capable of pulling together and overcoming the challenging obstacles we face in order to meet program milestones to the best of our abilities—it’s excellent.”

C'est un sens que l'on accepte plus facilement, mais c'est pas le même sens que l'autre assertion. Je ne me prononçais pas sur la "vérité" de l'assertion elle même mais seulement sur son équivalence avec sa contraposée.

L'affirmation de la première proposition est contenue dans la deuxième sinon ce ne serait pas équivalent. http://fr.wikipedia.org/wiki/Proposition_contrapos%C3%A9e

Non, Non, Saab a une équipe importante sur place qui attendait la conclusion du MMRCA pour proposer le Gripen à la place du Tejas, ... et vendre du nombre avec "Make in India" et tout et tout.

Cette vidéo de 1h 39 permet de confirmer pas mal d'informations mais ce qui m'a intéressé le plus c'est l'explication du général Bogdan donnée à 1h 27' https://www.youtube.com/watch?v=8G6knYbFoAk&feature=player_detailpage Il explique la raison pour laquelle il n'y a pas encore de solution définitive à l'anomalie qui a entraîné l'incendie du 23 Juin dernier. En fait la modélisation utilisée pour concevoir le moteur est défaillante et ils ont besoin de la corriger pour pouvoir faire la nouvelle conception!

Pourtant "ce qui vole mal est laid" est la contraposée de "ce qui est beau vole bien" et donc c'est équivalent.

Bon vous croyez vraiment que tous les problèmes logiciels du F-35 vont être réglés d'ici le mois de Juin?

Il faut aussi écrire les simulations....et les tester!

Oui ça dépend, tu prendrait quelle hypothèse si tu devais faire un choix? Groundburst pour être sûr.

Vous prenez une carte d'Europe, vous placez dessus vos 60 points à peu près répartis, avec un peu plus de charges à l'ouest qu'a l'est. Vous imaginez que ce sont des explosions nucléaires et que les vents dominants vont d'Ouest en est. Et vous vous demandez où il faudrait aller pour avoir une chance de survivre.

Avec la moitié, il y a plus d'Europe.

Ils ne font pas que ça, il y a tout le reste à développer, c'est pour ça qu'on ne produit que 250 lignes. Au final ils développent une quantité relativement normale de logiciel. Le brouillage large zone c'est antinomique avec l'idée de furtivité, ils peuvent laisser ça à d'autres avions.

Est-ce que tu peux imaginer ce que ça fait de tirer 120 ASMP?

Franchement je ne sais pas comparer le niveau atteind par le F-35 avec celui du Rafale. Celui du Rafale a l'air de donner satisfaction. Celui du F-35... pour être gentil on va attendre qu'il marche pour juger. Pour moi il n'y a pas de "niveau" dans une fusion: on y arrive ou on y arrive pas. Par contre les capteurs qui participent à la fusion induisent des niveaux de complexité différents. Peut-être que la fusion du F-35 est plus difficile de ce fait. J'ai signalé que pour moi la fusion avec des données venant d'une liaison tactique posait des problèmes fondamentaux. Mais je suis sur qu'on saura le programmer, ce qui est difficile dans ce cas c'est de savoir le spécifier. Lorsqu'on rajoutera une liaison du type MADL au Rafale (et j'espère que ce sera un des résultats de Tragedac) sa fusion de données sera comparable à celle du F-35 sauf qu'elle marchera.

Pour chaque projet de ce genre, le chef de projet se sent capable d'augmenter la productivité au dela de ce chiffre ridicule de 250 lignes par an. Comme il ne veut quand même pas se mettre la barre trop haut, parce que ce sera à lui de faire des efforts, et qu'il pense comme toi que 2500 lignes sont possibles, il acceptera en général un chiffre du genre 1000 (ça fait quand même une grosse marge). Et il prendra des mesures pour agmenter la productivité: en général c'est quelqu'un d'expérience qui a déjà dirigé des projets et qui se rapelle qu'il y a dans tel projet une bibliothèque de routines déjà testées et qui pourraient être utile et d'autre actions du genre. Cela fait augmenter la productivité un peu: du genre 280-300 et on se retrouve avec le fameux rapport pi entre l'estimation du temps estimé pour le développement et du temps qu'il a été nécessaire d'y consacrer. Le drame du logiciel du F-35 c'est qu'il est deux fois trop gros pour la complexité des fonctions qu'il est censé réaliser. Si on me donnait la direction de ce projet, j'essayerais d'abord de le faire maigrir. Il doit y avoir dedans plein de duplication de la même fonction qu'il faut donc mettre au point plusieurs fois. En gros l'architecture du logiciel est certainement à revoir avec un objectif de réduction de la taille. C'est comme le devis de masse: en aviation personne ne dira jamais "les moteurs sont devenus tellement puissant qu'on a plus besoin de s'occuper du devis de masse". La taille du logiciel c'est l'équivalent du devis de masse et ça montre tout de suite si il est bien ou mal foutu.

Merci pour l'éclairage.

Dans l'article j'avais mis ce lien http://clerse.univ-lille1.fr/IMG/pdf/pardoxe_productivite_logiciel.pdf où il y a beaucoup d'explication sur les différents niveaux de productivité, productivité apparente etc... J'en extrait le passage suivant 　 Qui montre déjà un rapport 100. Il est clair que la mesure à partir des lignes de codes n'est pas très pertinentes, mais c'est la seule métrique que l'on ait, vu de l'exterieur, pour mesurer le logiciel du F-35. Il est clair aussi que sur un programme aéronautique, il y a autour du programmeur tout un environnement technique qui travaille à la production du logiciel: Simulateurs, Stimulateurs, gestion de configuration (Trois variantes d'un avion multirole),logiciel de test, de mesure de performance, d'analyse...mais surtout cela se termine par des essais en vol. Et là la productivité est très faible ce qui nous met systématiquement dans le bas des fourchettes.

Le Pakistan pourrait les avoir...

ça va se passer d'autant plus mal :D

De toute façon tu ne gagne pas en portée en fusionnant (par rapport au meilleur capteur) tu transforme plus facilement des détections en pistes et tu prend la donnée la plus précise pour chaque paramètre mesuré.

Je rapelle que de mon point de vue lorsqu'on est en retard dans les développements logiciel, si le logiciel est complexe et si l'équipe est importante déjà, ce n'est pas en rajoutant du monde qu'on réduit les retards. http://www.45enord.ca/2014/05/le-logiciel-du-f-35/

Oui parce que c'est 100% des process critiques qu'ils ne peuvent pas faire.

Whoa! Merci Gallium Nitride. C'est plus confortable que de le lire en Anglais, mais je suis malade et j'avais la flemme pour faire des traductions d'extraits.

Une transcription de l'interview de Parrikar: http://www.hindustantimes.com/india-news/more-rafales-required-but-need-to-factor-in-cost-defence-minister-manohar-parrikar/article1-1337631.aspx

Si tu veux illustrer http://2.bp.blogspot.com/-ZyMaLwF5V8g/Uui787MA6VI/AAAAAAAAES4/B7DGdmZOwIY/s400/f-35-price-fixing-figure-4-575px.jpg