Jump to content
AIR-DEFENSE.NET

ywaDceBw4zY3tq

Members
  • Posts

    180
  • Joined

  • Last visited

Reputation

178 Excellent

Profile Information

  • Pays
    Galicia

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. ywaDceBw4zY3tq

    [Rafale]

    https://articles.adsabs.harvard.edu/cgi-bin/nph-iarticle_query?1996ESASP.375..111N&defaultprint=YES&filetype=.pdf Un article sur l'architecture informatique du Rafale à ses débuts (publié une conférence sur le software en temps réel en 96).
  2. De ce que je comprend, Thales a reçu un contrat pour mettre a jour (ils en étaient déjà responsable en 2012) le programme NATO Common Operational Picture (en tout cas c'est ce sur quoi portent les communiqués de presse de fin janvier 2021). En gros, de la mise en commun et de la visualisation pour la décision tactique, d'après ce petit passage: https://euro-sd.com/2021/04/articles/exclusive/22547/common-operational-picture/ Pour ce qui est du cloud de combat du SCAF, j'ai l'impression que l'objectif est de construire un MADL européen, que ce soit (entre autres) les liaisons de données tactique haut débit très directionnelle et résistantes au brouillage, les questions de fusion de données multicapteur / gestion des redondances (comme dans le papier AIAA que j'ai posté dans le fil F35), le tout dans une architecture ouverte qui communique avec le plus de choses possibles (https://www.marinecorpstimes.com/news/your-marine-corps/2018/10/05/marines-connect-f-35-jet-to-himars-rocket-shot-for-first-time/, en france on pourrait imaginer les interactions avec Scorpion par exemple). Sur les questions de liaisons / fusion de données, comme ça a été précisé plus Thales est compétent, mais effectivement je ne suis pas sûr de voir ce que ça à voir avec le cloud de l'OTAN, ni avec le cloud au sens civil du terme.
  3. Les japonais se sont particulièrement bien défendus lors du projet FS-X (qui a donné le F2). Au départ, les USA voulaient leur faire construire des F16 sous licence, avec un transfert de techno réciproques, pour éviter un développement complètement national. Les japonais ont largement trainé les pieds pour transférer leur techno et ont tout fait pour minimiser la part de R&D réalisée au USA. Au final l'avion n'a rien a voir avec le F16, l'avionique et les commandes de vol sont intégralement japonaise (premier AESA équipant un chasseur au monde, en 2002 !), l'aile est complètement redessinée et conçue par MHI (avec une grande expertise développée en composites) ... Ils ont très bien réussis à construire et défendre leur R&D locale, même face au USA. Un rapport de la RAND intéressant sur cette histoire: https://www.rand.org/pubs/monograph_reports/MR612z2.html En terme de développement il ne manque que les moteurs, et ils font beaucoup d'efforts: https://en.wikipedia.org/wiki/IHI_Corporation_XF9
  4. Extrêmement intéressant, il est possible d'en savoir plus (même si j'en doute) ? C'est intéressant parce que l'Arabel c'est de la bande X, donc on aurait envie de penser que vu la taille des antennes de spectra on aurait une bonne directivité en réception (j'imagine que c'est une bande qui a reçue une attention particulière pendant la conception).
  5. L'idée d'impliquer l'industrie australienne c'est celle d'Attack, on peut pas vraiment dire qu'ils ont étés convaincus ... On commence a discuter chantiers US parce que c'est la solution la plus certaine. Les délais sont au final une question de volonté politique du côté US, et une concession a négocier pour les Australiens: si ils le voulaient, les chantiers navals US pourraient commencer à livrer dès cette année. Toute construction en Australie impliquera des enjeux de gestion de programme par nature beaucoup plus incertains.
  6. NG est occupé a faire les SNLE 3G après les SNA. Construire 6 / 8 SNA en même temps que les SNLE c'est doubler les capacités de production, ça voudrait dire qu'on décide d'une expansion capacitaire en terme de SNA sans précédent (à ma connaissance, mais a part Bohai en Chine ces dernières années je vois pas trop), avec un préavis très court, et avec quelle utilisation de ces capacités après un hypothétique contrat australien ? Même au USA ça commence a grogner en disant que ça va être très compliqué, qu'il faudrait ouvrir un nouveau chantier et que ça va coûter très cher. Le combustible je pense qu'ils s'en foutent / qu'ils voient surtout les avantages (pas besoin de construire les capacités de rechargement de coeur).
  7. J'avoue ne sincèrement pas comprendre les déclarations de certains australiens sur le "retour vers la France". Les problèmes de BITD sont exactement les mêmes, voire encore pire: au fond, il serait envisageable pour les USA de dévier des Virginias de leur production actuelle vers la RAN, parce que les objectifs dans le Pacifique semblent plutôt alignés, mais c'est complètement impossible pour nous. La capacité excédentaire de construction de SNA n'existe pas dans le monde occidental, ni au USA, ni au RU, ni en France, c'est le fond de leur problème. Mais j'ai cru comprendre que le chantier naval de Bohai avait reçu des extensions très significatives récemment par contre.
  8. Ce site est intéressant mais des fois j'aimerais bien voir leur sources / méthodologie, comme quand on apprend que Spectra est conçu et fabriqué par Thales North America (https://www.airframer.com/aircraft_detail.html?model=Dassault_Rafale section Weapons System), que Moog Control UK fait les "primary flight controls" du Rafale ou que Thales UK fait l'OSF. C'est rigolo parce que le site référence clairement les entités corporate françaises de Thales, mais affiche souvent des entités british pour des composants du Rafale ...
  9. ywaDceBw4zY3tq

    [Rafale]

    J'avoue que je ne suis pas sûr de tout suivre. De ce que je comprend, le notch doppler c'est le fait que sur un radar doppler moderne, tu filtre les contacts du clutter sur la base de leur vitesse radiale, en se basant sur l'idée que le clutter a en moyenne (sur la durée de l'intervalle de traitement cohérent) une vitesse radiale nulle, donc une fréquence doppler nulle. Avec une antenne plus grande le gain est meilleur, donc le SNR aussi, mais tu ne peut pas vraiment arrêter de filtrer le morceau du spectre du signal reçu qui correspond au vitesse radiales nulles, sinon c'est la foire au faux contacts non ? De ce que j'ai lu, il est possible d'implémenter des stratégies pour poursuivre le contact "a travers" le notch. Difficile de connaître exactement le niveau de fidélité de cette simulation (il y a quand même un feedback conséquent de l'AdlAE), mais sur le 2000C de DCS, le RDI dispose d'un mode d'illumination dans lequel le radar est pointé vers la position "en sortie de notch" du contact, sur la base de l'estimation précédente de sa direction / vélocité, en se basant sur l'idée qu'il est difficile de maintenir une vitesse radiale nulle pendant longtemps pour le contact (parce que l'estimation de la position du radar qui t'illumine est imprécise).
  10. Un petit post sur les expérimentations faites par l'US Navy en matière de mat optroniques. En 2020, L3 Harris a reçu un contrat de ~17 millions de dollars pour construire des mats "low profile" avec une signature radar plus faible. On a déjà vu ces mats sur certain Virginia: Ce qui est intéressant c'est que l'US Navy a aussi expérimenté avec des mats fabriqués par ... Hensoldt, ce modèle-ci en particulier: https://www.hensoldt.net/products/optronics/oms-150-optronic-mast-system-for-submarines/ Je serais assez curieux de connaître les avantages et inconvénients par rapport au mat BVS-1 (https://www.marinetechnologynews.com/blogs/umm-photonics-mast-for-virginia-class-attack-submarines-700510) "classique".
  11. Très intéressant, c'est possible d'en savoir plus ? Le système de fusion de données pointe le radar pour affiner automatiquement les pistes sur la base du SNR des contacts ? Ou c'était plutôt pour la détection passive ?
  12. Un résumé d'un article sur la fusion de données du F35, écrit par les gens qui s'en occupent chez LM. l'article est disponible ici: https://arc.aiaa.org/doi/abs/10.2514/6.2018-3520 (un tour sur libgen avec le doi permettra d'obtenir le pdf). Remarque préalable: je ne suis évidemment pas spécialiste dela fusion de données, et encore moins spécialiste de l'implémentation de ces méthodes sur le F35. Ce résumé contient donc nécessairement des erreurs de vocabulaire, de traduction ou de compréhension. En espérant que ça soit quand même un peu utile, le voila. Introduction: Les auteurs distinguent différents niveaux de fusion de données: - Niveau 1: "object assessment": chaque capteur propose indépendemment une piste par objet - Niveau 2: capacité d'agrégation des objets du niveau 1: déduplication / matching entre les objets détectés par les différents capteurs - Niveau 3: capacité d'évaluation de l'impact des actions prévues sur l'estimation actuelle de la situation (est-ce qu'une action me rend plus vulnérable / plus efficace) - Niveau 4: capacité de raffinement de la situation estimée: quels sont les meilleurs choix d'utilisation des capteurs pour améliorer la connaissance de la situation ? Après cette représentation idéalisée, les auteurs font un historique très rapide des implémentations de la fusion de données: -Années 70-80: corrélation des pistes: si deux capteurs détectent un objet identique, on ne représente que la piste la plus précise. La précision de la fusion est équivalente a celle du meilleur capteur, il n'y a pas d'amélioration qualitative venant d'une détection simultanée sur plusieurs capteurs. -Années 90: Combinaison des pistes ("track blending"). Il n'y a pas d'explication particulière sur le fonctionnement de cette stratégie. On comprend qu'a partir des années 90 (l'avion "exemple montré est un Super Hornet), on commence à avoir des méthodes de fusion qui permettent de tirer parti des avantages respectifs des capteurs: un IRST a une très bonne résolution en azimuth / élévation, mais l'estimation de la distance est difficile. A l'inverse, le radar peut estimer la distance, mais est limité en résolution azimuth / élévation par la taille du faisceau. Avec ces nouvelles méthodes, il devient possible d'arriver a la précision azimuth / élévation de l'IRST et la résolution en en distance (ou variation de la distance) du radar. -Années 2000+: sur le F22 et le F35, la fusion est réalisée au plus bas niveau possible, i.e a l'échelle des mesures des capteurs et pas des pistes produites par ces derniers. Plutôt que d'agréger les détections des différents capteurs, on agrège les mesures pour produire une détection unique. Sur ces avions, la fusion est qualifiée de "closed loop": la gestion des capteurs est gérée automatiquement en fonction des besoins de l'algorithme de fusion des données (identification, construction d'une piste suffisamment précise pour l'engagement). Capteurs et liaison de données sur le F35: L'architecture de fusion des données est identique pour les trois variantes. Du côté matériel, il y a: -l'APG-81 (radar) -l'ASQ-239 (RWR / CME) -l'EOTS (optronique "avant") -le DAS (optronique "couverture large") -le MADL (liaison de données intra-patrouille) Le F35 est équipé de la L16, mais justifient l'utilisation du MADL par le fait que l'information sur la qualité de la piste est limitée. La liaison de données intra-patrouille permet de partager: - l'estimation locale (pour l'avion émetteur) de la piste - la covariance de la piste (filtre de Kalman) - historique d'identification du mobile - historique RWR de la piste Approche adoptée pour la fusion de données sur le F35: Lors des débuts de la conception du F35, la fusion de données était déconnectée de la gestion des capteurs. La date n'est pas mentionnée, mais il a été décidé d'intégrer le gestionnaire de capteurs a la fusion de données (correspond au niveau 4 mentionné dans l'introduction). L'architecture est définie en terme de sources et destinations d'information. Les sources peuvent être les capteurs ou les liaisons de données, pendant que les destinations sont les écrans du cockpit, ou l'armement. Le "fusion engine" construit une représentation unifiée des données, et pilote les capteurs pour améliorer l'estimation de la situation. Les données entrantes ou sortantes sont normalisées par des "virtual interface models", chargés de traduire l'information dans une forme standard pour les algorithmes de fusion de données. Le VIM chargé des données sortantes formate les données en fonction des besoins des "utilisateurs". Cette approche permet en théorie de déconnecter les capteurs et les utilisateurs des algorithmes de fusion de données, et donc de faciliter l'intégration de nouveaux capteurs / utilisateurs de données. Niveaux d'information: Le pilote reçoit toujours une information dite "Tier 3", qui inclut la meilleure estimation de la situation compte tenu des informations des capteurs a bord, ainsi que des informations reçues par les liaisons de données. A l'inverse, l'information partagée par le MADL est "Tier 1", elle est directement le résultat des mesures effectuées par le capteur et ne passe pas par le "fusion engine". Chaque avion agrège donc les mesures des capteurs des membres de la patrouille, et non pas les résultats de la fusion de données. L'idée est de garantir l'indépendance statistique entre les données fournies par les membres de la patrouille. Pour incorporer des informations qui ne proviennent pas du MADL (par exemple de la liaison 16), le F35 utilise des algorithmes spécifiques pour gérer les redondances dans l'information fournie, et éviter de diminuer artificiellement l'erreur d'estimation d'une piste. Les informations fournies par les liaisons de données classiques sont fournies avec un "facteur de qualité". Cette caractérisation de l'incertitude n'est pas très précise, et en général le facteur de qualité le plus faible est retenu lors de l'intégration de ces données (par prudence), ce qui conduit a dépondérer l'information provenant de la L16. A l'inverse, le MADL communique une matrice de covariance complète de l'estimation actuelle, ce qui permet de pondérer précisément les pistes "off board". Identification des mobiles: Le F35 adopte une modélisation probabiliste de l'identité des mobiles. Cette approche permet de gérer plus facilement les ambiguité et incertitudes dans l'identification des mobiles. L'approche bayésienne a été écartée car il était difficile de spécifier correctement les distributions a-priori. Au final la théorie de Dempster-Shafer a été retenue (https://en.wikipedia.org/wiki/Dempster%E2%80%93Shafer_theory). La bibliothèque de plateformes identifiables inclut toutes les plateformes "pertinentes" présentes dans le théatre d'opération. Cette bibliothèque est construite de manière hiérarchique. La confiance dans l'identification est toujours supérieure a un niveau "élevé" de la taxonomie (avion, bateau, hélicoptère) qu'a un niveau bas (MH60, Su35 ...). Les probabilités sont converties en décision en fonction d'un seuil choisi par le pilote: la bibliothèque de plateforme est parcourue du bas vers le haut jusqu'a ce que l'on trouve une catégorie qui dépasse le seuil de confiance défini. Gestion autonome des capteurs: Le nombre important de capteurs sur les plateformes modernes impose une gestion automatique de ces derniers. Le gestionnaire de capteurs sert a: -minimiser la charge de travail du pilote -optimiser l'utilisation des capteurs pour un objectif en particulier, potentiellement défini par le pilote: recherche de contacts, poursuite, minimisation d'incertitude sur une piste en particulier. Le gestionnaire de capteurs équilibre aussi ces différents objectifs ("maintenance" des pistes / découverte de nouveau contacts). -reconfigurer les capteurs en cas d'avarie ou d'indisponibilité temporaire. Le pilote peut interagir de différentes façons avec le gestionnaire de capteurs. Par exemple, le pilote peut désigner une direction qui devrait faire l'objet d'un intérêt particulier, ou encore désigner une piste comme prioritaire. Le gestionnaire rafraichira alors cette piste plus fréquemment pour minimiser l'incertitude de position. Le gestionnaire des capteurs essaye aussi d'éviter un excès de précision, une fois qu'un niveau d'information "suffisant" (qui n'améliore plus l'appréciation de la situation par le pilote) est atteint. Détection coopérative: Pour les émetteurs au sol, le F35 implémente une méthode de localisation coopérative. Les temps et fréquences d'écoute ("ESM dwells") sont synchronisés entre les avions de la patrouille depuis un avion "leader". En regroupant les impulsions de l'émetteur et en calculant les délais d'arrivée sur les différents avions de la patrouille (transmis par MADL), il est possible de localiser précisément les émetteurs au sol.
  13. https://gcaptain.com/us-shipyards-record-revenue-but-firesale-valuations/ Un article intéressant sur le fait que les chantiers navals américains ont des carnets de commande remplis, mais sont valorisés a des niveaux extrêmement bas, a l'inverse des entreprises américaines de l'aérospatiale. VT Halter Marine a gagné un contrat de ~750 millions pour construire un brises-glace, mais a été vendu pour 15 millions de dollars. HII a un carnet de commandes de ~60 milliards, mais est évalué a seulement ~10 miliards. Hypothèses de l'auteur: - les marges sont beaucoup plus importantes dans l'aérospatial: même si HII a des revenus très élevés parce qu'ils construisent des bateaux très couteux, les profits sont faibles. Il suffit que les dépassements de coût soient faibles sur les contrats "fixed costs" pour que les chantiers navals perdent de l'argent, ce qui peut être fatal pour les plus petits. -moins de tension en terme de salariés qualifiés / besoin de moins de personnes en général dans l'aérospatial. -pas d'exportation du naval de défense: situation de monopsone ou la Navy est l'unique client, et pas toujours un client facile (changement de specs).
  14. https://www.codeonemagazine.com/article.html?item_id=72 Un article intéressant sur l'estimation de la déformation induite par la la verrière du F35.
  15. Merci, je ne connaissais pas Cosmos Skymed. Tu crois qu'avec la démocratisation des SDR, du GaN et compagnie on aura des composants hyperfréquences suffisamment peu coûteux pour faire des constellations de cubesat qui font du SAR, ou ça n'aura jamais de sens de mettre ces capteurs sur des plateformes "jetables" ?
×
×
  • Create New...