Picdelamirand-oil

L'eau, ça ne se justifie que si ils craignaient des fuites et un incendie, parce que sinon ce n'est pas représentatif, ça n'a pas la même densité que le Kérosene.

Pas d'accord: quand on dit " All Rafales have a built-in CFT capability" c'est que la plomberie est déjà en place.

http://www.dassault-aviation.com/wp-content/blogs.dir/1/files/2012/08/Fox_Three_nr_2.pdf

Il y a aussi Trappier qui a dit que la configuration Rafale pour le Qatar était un peu particulière ce qui impliquait une livraison retardée le temps de faire le développement. Par contre leur rafale sont déjà en production, c'est juste la finition qui doit se faire après le développement.

"4,5+ gen" c'est la génération!

Il existe dans la sphère médiatique, la seule qui compte à notre niveau.

The Rafale will outlclass le saint J-20 Source: http://defence.pk/threads/india-to-order-2nd-batch-of-36-rafales-in-2020.472254/page-4#ixzz4VradCenN

Pour la France je pense que c'est le plus léger qui a toutes ses chances.

Dans le lien que j'ai donné ils parlent d'un JAS 39 C qui est mono place et du "Sqn Ldr Dilokrit Pattavee" comme pilote décédé. Si tu as d'autres infos...

Crash d'un Gripen thailandais. http://www.bangkokpost.com/news/general/1180041/gripen-jet-crashes-during-air-show-pilot-killed RIP pour le pilote

Non ça indique qu'ils veulent que leur poste soit confirmé par le sénat suite à leur audition.

Pourquoi la Belgique organiserait une compétition ou seul un candidat peut se présenter?

Bodgan a déjà dit qu'il y en aura 493 à rétrofiter

L'article semble raisonnable.

moi je crois qu'ils font semblant d'avoir peur, parce qu'ils sont très polis.

Gilmore c'est juste pas son rôle de proposer l'abandon du programme, il est là pour faire des tests opérationnels quand l'avion sera au point, et il a été chargé d'un mission de surveillance du déroulement du programme au bénéfice du SENAT au moment de la remise à plat du programme. Il remplit ces deux missions, il dit ce qui va pas, il propose des solutions et il s'inquiète de l'état dans lequel on lui donnera l'avion quand il devra faire les tests opérationnels et quand. Il remarque aussi que sans un certain nombre d'outil il ne pourra pas les faire en particulier il réclame à corps et à cri les fameuses data qui décrivent les menaces dans le système du F-35.

http://piketty.blog.lemonde.fr/2017/01/05/de-la-productivite-en-france-en-allemagne-et-ailleurs/

pas dans le bon fil

Le dernier rapport sur le F-35: il y a beaucoup de choses, dont beaucoup sont connues mais pour l'instant je n'ai fait que le survoler. http://www.dote.osd.mil/pub/reports/FY2016/pdf/dod/2016f35jsf.pdf

Indian defense Tu n'as qu'a dire que tu va proposer un nouveau LSA encore mieux que celui de vstol jockey.

Le logiciel du F-35 Je voudrais faire partager quelques réflexions et calculs de coin de table pour illustrer la difficulté de produire et de tester un logiciel complexe et temps réel de grande dimension. La taille du logiciel embarqué du F 35 est évaluée entre 8 et 10 millions de ligne de code selon les sources. C'est une taille gigantesque. De tels logiciels existent au sol pour réaliser de la gestion classique, mais un logiciel embarqué est, normalement, beaucoup plus léger, en taille, et beaucoup plus complexe à mettre au point. De plus il faut faire une ségrégation entre le logiciel "critique" et le logiciel normal car si, par exemple, le module "navigation" a une erreur fatale, il n'est pas envisageable que les commandes de vol ne répondent plus. Et il est bien évident que le logiciel critique demande plus de travail et de tests que le logiciel normal. Une première difficulté vient de l'impossibilité d'augmenter indéfiniment la taille des équipes logicielles. Ce point est illustré dans "Les paradoxes de la productivité dans la production des logiciels" de François Horn : "les mois et les hommes ne sont interchangeables que lorsqu'une tâche peut être divisée entre plusieurs travailleurs sans réclamer de communication entre eux" et "si n taches doivent être séparément coordonnées avec chaque autre tâche, l'effort augmente en n(n-1)/2 (idem, p. 15). Dans des situations extrêmes ces activités supplémentaires font plus que compenser l'apport de travailleurs supplémentaires" http://clerse.univ-lille1.fr/IMG/pdf/pardoxe_productivite_logiciel.pdf Pour contourner cette difficulté le même document donne une solution qui consiste à effectuer un important travail préalable au niveau de l'architecture du système pour le décomposer en modules plus petits qui doivent avoir une indépendance maximale. Nous allons donc faire des hypothèses sur la modularité du logiciel du F-35 pour tenter d'en estimer la difficulté de réalisation et surtout de test. Pour ce faire on peut estimer le nombre de calculateurs du système d'arme (c'est un premier niveau de modularité), la taille probable des équipes et la complexité probable du calculateur tactique (ou calculateur de mission c'est-à-dire celui qui coordonne tous les équipements). Pour les estimations on doit utiliser des ratios en lignes de code, bien que ce soit critiquable, car c'est la seule donnée d'entrée dont on dispose. Je pense qu'un tel système d'arme comporte entre 100 et 200 calculateurs. Pour ce qui est de la taille des équipes, chargées de réaliser un "module" on peut tabler sur 10 à 20 personnes travaillant pendant 10 ans. Il s'agit donc de gros "module" représentant une fonction déjà complexe. Comme on est dans un projet complexe la productivité est réduite à 250 lignes de code par an et par personne en considérant les moyens totaux consacrés en un an au logiciel par le projet : Ce taux de 250 lignes par an peut sembler un peu faible, mais c'est un taux qui ne compte que le logiciel embarqué, non compris le logiciel abandonné, tous les développements, les tests sur les bancs de tests, les améliorations et toute la maintenance. Or pour le mettre au point il faut développer d'autres logiciels : on commence par faire un logiciel qui teste les interfaces, pour cela le calculateur tactique envoie les messages élémentaires relatifs à un équipement et vérifie que les réponses correspondent à ce qui est attendu. Ce programme doit être aussi simple que possible pour que sa mise au point soit facile, il est statique et ne teste que les échanges (en général sur un bus). Il faut ensuite faire une simulation numérique de chaque équipement (on peut utiliser le programme de test des interfaces pour un premier niveau de mise au point de cette simulation) ces simulations serviront à l'évaluation - validation du logiciel tactique. Il faut ensuite faire des programmes de stimulation des équipements : par exemple si on a une centrale à inertie il faut remplacer les accéléromètres et les gyromètres par des stimulations calculées par le calculateur de simulation, les injecter dans une centrale réelle branchée sur le bus afin de pouvoir tester l'intégration de celle ci au banc. Il faut enfin faire une simulation générale qui produit des thèmes d'exercice et qui coordonne l'environnement général avec la simulation (ou la stimulation) de tous les équipements du système d'arme. Sur ce banc les tests d'intégration vont beaucoup plus vite qu'en vol: on peut par exemple pour tester un module faire varier les configurations par software alors qu'en vol chaque configuration représente un vol différent. En plus sur le banc on peut tester les réactions du système d'arme aux différentes pannes des équipements ou de l'avion. Une équipe produit en moyenne un "module" de 40 000 lignes de code. Pour un logiciel d'une taille de 10 millions de lignes cela fait 250 "Modules" soit en moyenne 1 à 2 module par calculateurs. Mais le calculateur tactique doit faire entre un million et un million et demi de lignes de code, c'est-à-dire entre 20 et 30, voir 35 "modules". Ces modules sont sans doute de grandes fonctions comme missiles air-air, missiles air-sol, suivi de terrain, radar, contre mesures, navigation, liaison tactique etc. L'intégration des ce type de fonction à un niveau élémentaire peut se faire au banc, mais l'intégration finale se fait obligatoirement en vol, et là c'est très long car tous les autres modules doivent être présents et à un niveau de mise au point acceptable et qu'il faut tester un grand nombre de configurations différentes (c'est un avion multi rôles) et même le faire sur trois avions différents (versions A, B et C). Lorsque nous avons 250 modules à réaliser avec chacun un planning de 10 ans et que parmi ces 250 modules 30 dépendent de tous les autres pour leur mise au point, il ne faut pas espérer tenir le planning. Même en supposant que des tests peuvent commencer sans que tout soit disponible, il me semble raisonnable de compter 15 ans pour la disponibilité complète des 250 modules, 5 ans pour les tests au banc et 10 ans pour les essais en vol ce qui fait 30 ans si tout le monde a bien fait son travail. Comme le programme a commencé en 2001, la date estimée pour un F 35 opérationnel nous amène à 2031. Pour l'instant les essais en vol qui ont eu lieu concernent surtout l'avion lui-même mais très peu le logiciel de mission. http://aviationweek.com/awin/f-35-jsf-testers-report-progress-problems Du point de vue des essais en vol, en 2012, Lockheed Martin a dépassé ses objectifs de développement. Lockheed dit avoir réalisé 1167 vols et 9319 points de mesure en 2012 alors que le plan était de 988 vols et 8458 points. Sur les vols effectués, 926 étaient des vols ayant pour but d'élargir les domaines de vol des trois variantes de F-35, tandis que 241 étaient réalisés par les avions de mission/systèmes pour tester l'avionique et les capteurs. Mais un rapport du directeur du DOT&E révèle que cela s'est fait en réalisant des tests prévus pour les années suivantes. Des anomalies matérielles et des retards de mise au point de logiciels ont empêchés le programme d'atteindre certains objectifs de test fixés pour 2012. Ces objectifs étaient pourtant nécessaires pour permettre le démarrage de la formation des pilotes de F-35. Ainsi, leprogramme avait terminé seulement 78 % des points de mesure prévues pour l'année. L'ajout de points de mesure supplémentaires pour traiter de nouveaux problèmes, pour réaliser les tests de non-régression liées aux corrections apportées, et pour les tests réalisés en avance de phase, a augmenté le nombre des points de test à traiter de plus de 35 %. Le rapport du directeur du DOT&E pour l'année 2013, sans surprise, confirme la difficulté de la mise au point de ce logiciel. "Challenges in development and testing of mission systems software continued through 2013, due largely to delays in software delivery, limited capability in the software when delivered, and the need to fix problems and retest multiple software versions." http://spectrum.ieee.org/riskfactor/aerospace/aviation/software-testing-problems-continue-to-plague-f35-joint-strike-fighter-program

http://www.45enord.ca/2014/05/le-logiciel-du-f-35/ Mais le site semble avoir des problèmes en ce moment

La rumeur vient de CNL-PN-AA qui prétend qu'il est un colonel de l'armée de l'air et qu'il a des amis haut placés chez SAFRAN. Le M88 8,3 t serait prévu pour le Qatar.