Le F-35

[jojo (lo savoyârd)]

 

[herciv]

Il y a 22 heures, Boule75 a dit :

Oui. Ça concerne d'ailleurs aussi les propres capteurs de l'avion.

Parmi les difficultés dont j'imagine que la fusion doit tolérer l'absence ou la dégradation :

- le réseau, dont le débit est susceptible de fluctuer, voire de s'interrompre, avec des routines de rattrapage d'erreurs, etc...

- des capteurs aveuglés, saturés, souffrant de rémanence ou de défaillance partielle,

- la perte définitive d'un coéquipier (destruction, retraite, hors-portée, désastre informatique...)

- les nuages, le relief ou une manoeuvre brutale, peuvent altérer radicalement les données reçues d'un pair,

- prise en compte des différentes versions des logiciels et capteurs, possiblement de la sensibilité variable d'un capteur à l'autre.

 

Sur tous ces aspects, fusionner les pistes est plus simple que fusionner les sources.

Ca veut aussi dire que d'un calcul a l'autre tes proba peuvent changer radicalement et avec des pistes vlo tes probas sont deja mauvaises alors quand un incidents arrive sur tes partenaires il doit plus rester grand chose.

[prof.566]

En fait, il fusionne des données filtrées quand même. Vous imaginez échanger toutes les données collectées par un radar????

[Boule75]

il y a 12 minutes, prof.566 a dit :

En fait, il fusionne des données filtrées quand même. Vous imaginez échanger toutes les données collectées par un radar????

Non, pas bien : je ne sais rien ni de la "résolution", ni du "nombre d'images pas secondes", ni du "nombre de couleurs par pixel", si on peut ainsi faire le parallèle avec une caméra, toutes données qui dimensionnent la taille d'un flux vidéo brut. En outre je me doute qu'on pourrait peut être échanger des données à un stade intermédiaire de traitement, après filtrage du fond d'image par exemple, voire les différences d'une "image" à l'autre 19 fois sur 20 plutôt que chaque "image" à chaque fois, tactique basique de compression des flux vidéo encore une fois.

[prof.566]

Rajoute la 3D pour le radar...

[Boule75]

il y a 8 minutes, prof.566 a dit :

Rajoute la 3D pour le radar...

J'avais mis la couleur : y en aurait-t-il aussi ?

[jojo (lo savoyârd)]

il y a 13 minutes, Boule75 a dit :

J'avais mis la couleur : y en aurait-t-il aussi ?

Avec ceci, vous prendrez bien de l'audio LTE ? 

[ARPA]

Il y a 4 heures, Boule75 a dit :

Non, pas bien : je ne sais rien ni de la "résolution", ni du "nombre d'images pas secondes", ni du "nombre de couleurs par pixel", si on peut ainsi faire le parallèle avec une caméra, toutes données qui dimensionnent la taille d'un flux vidéo brut. En outre je me doute qu'on pourrait peut être échanger des données à un stade intermédiaire de traitement, après filtrage du fond d'image par exemple, voire les différences d'une "image" à l'autre 19 fois sur 20 plutôt que chaque "image" à chaque fois, tactique basique de compression des flux vidéo encore une fois.

La tu commences à traiter les informations. Donc tu perds l'intérêt de la fusion de données avant traitement. 

La L16 qui peine pour transmettre toutes pistes dispose d'une bande passante en kbit/s. (Une piste est un écho détecté depuis presque une minute)

Maintenant si on veut transmettre toutes les informations (non traités) de chacuns des 1000+ modules des 3 autres F35 de la patrouille, on risque d'approcher le gigabits. 

Sans aller si loin, pour le contrôle aérien français, on utilise la fusion de données des plots (donc avant traitement en pistes, mais il s'agit quand même d'un écho détecté une dizaine de fois en quelques dizieme de seconde) ce qui implique pour les radars terrestres une liaison au minimum en dizaines de kbit (dépendant du nombre de plots détectés, donc de la portée du radar) 

[hadriel]

Il y a 8 heures, Boule75 a dit :

Non, pas bien : je ne sais rien ni de la "résolution", ni du "nombre d'images pas secondes", ni du "nombre de couleurs par pixel", si on peut ainsi faire le parallèle avec une caméra, toutes données qui dimensionnent la taille d'un flux vidéo brut. En outre je me doute qu'on pourrait peut être échanger des données à un stade intermédiaire de traitement, après filtrage du fond d'image par exemple, voire les différences d'une "image" à l'autre 19 fois sur 20 plutôt que chaque "image" à chaque fois, tactique basique de compression des flux vidéo encore une fois.

A vue de pif le débit de données brut instantané d'un radar c'est

2* bande passante instantanée du radar * nombre de modules AESA* le nombre de bits du signal numérisé

Avec 1000 modules AESA on tombe vite dans le 100 milliards d'échantillon/seconde qui rentrent dans le module de traitement, ça se trimbale pas comme ça sur une liaison de donnée. On ne doit donc pouvoir échanger que des données un minimum pré-traitées (au moins focalisées dans le cas d'un AESA), et éventuellement compressées avec juste la forme d'onde des échos détectés.

[Boule75]

il y a 16 minutes, hadriel a dit :

A vue de pif le débit de données brut instantané d'un radar c'est

2* bande passante instantanée du radar * nombre de modules AESA* le nombre de bits du signal numérisé

Avec 1000 modules AESA on tombe vite dans le 100 milliards d'échantillon/seconde qui rentrent dans le module de traitement, ça se trimbale pas comme ça sur une liaison de donnée. On ne doit donc pouvoir échanger que des données un minimum pré-traitées (au moins focalisées dans le cas d'un AESA), et éventuellement compressées avec juste la forme d'onde des échos détectés.

Ah quand même ! Ça pique, et effectivement, ça m'étonnerait lourdement que ces données brutes passent en direct sur de l'hertzien directionnel. Déjà, sur de la fibre, il faudrait s'en occuper sérieusement, alors sur la radio...

J'imagine que derrière, ce signal est traité par des processeurs massivement parallèles (genre GPU) optimisés pour les calculs matriciels, c'est ça ? On fait ça en France ? Je découvre... (mais ça n'est pas le bon fil)

[hadriel]

Il y a 9 heures, Boule75 a dit :

J'imagine que derrière, ce signal est traité par des processeurs massivement parallèles (genre GPU) optimisés pour les calculs matriciels, c'est ça ? On fait ça en France ? Je découvre... (mais ça n'est pas le bon fil)

Je suis pas du domaine mais j'imagine que c'est fait sur FPGA (ou sur ASIC).

[g4lly]

9 hours ago, hadriel said:

Avec 1000 modules AESA on tombe vite dans le 100 milliards d'échantillon/seconde qui rentrent dans le module de traitement, ça se trimbale pas comme ça sur une liaison de donnée. On ne doit donc pouvoir échanger que des données un minimum pré-traitées (au moins focalisées dans le cas d'un AESA), et éventuellement compressées avec juste la forme d'onde des échos détectés.

En mode veille ... le balayage doit chuter largement ... pourquoi s'emmerder à revisiter un secteur 100 fois par seconde alors que la seconde précédente on y a rien trouvé...

1000 modules * 2 pulse secondes * échantillonnage basique du retour ... c'est pas si ingérable que ça en veille.

Quand on passe en mode formation de piste la forcément la revisite et plus fréquente et l'analyse du signal retour est plus poussée... mais pourquoi s'emmerder a revisité 100 fois par seconde ... 1 fois ça suffit bien.

Une fois la piste établie on peut a nouveau ralentir le balayage.

Les pistes intéressantes peuvent passer en mode poursuite renforcée avec une revisite plus fréquente, échantillonner plus finement l'écho retour en mode analyse NTCR etc. mais ça concerne moins de 20 pistes normalement.

En gros pourquoi utiliser une vulgaire méthode de balayage brute force quand c'est pas nécessaire...

[FATac]

Peut-être parce que dans certains cas, même en veille, afin d'augmenter la portée de détection, plusieurs (dizaines de) modules vont pointer le même secteur. Le nombre de secteurs visités chute alors drastiquement, nécessitant d'augmenter le nombre de scan par seconde pour récupérer un balayage correct.

Je me trompe ?

[DEFA550]

il y a 43 minutes, g4lly a dit :

En mode veille ... le balayage doit chuter largement ... pourquoi s'emmerder à revisiter un secteur 100 fois par seconde alors que la seconde précédente on y a rien trouvé...

1000 modules * 2 pulse secondes * échantillonnage basique du retour ... c'est pas si ingérable que ça en veille.

Quand on passe en mode formation de piste la forcément la revisite et plus fréquente et l'analyse du signal retour est plus poussée... mais pourquoi s'emmerder a revisité 100 fois par seconde ... 1 fois ça suffit bien.

Une fois la piste établie on peut a nouveau ralentir le balayage.

Les pistes intéressantes peuvent passer en mode poursuite renforcée avec une revisite plus fréquente, échantillonner plus finement l'écho retour en mode analyse NTCR etc. mais ça concerne moins de 20 pistes normalement.

En gros pourquoi utiliser une vulgaire méthode de balayage brute force quand c'est pas nécessaire...

Hmmm... Je pense que tu peux balayer tout ça d'un revers de main.

Le calculateur ne reçoit pas 1000 signaux individuels, mais la somme des signaux reçus par chaque module c'est à dire un signal unique sur une porteuse à 10 GHz (bande X). Ca passe à la moulinette d'une transformée de Fourier pour en extraire les amplitudes et phases de chaque bande de fréquence (spectre du signal). L'analyse porte là-dessus (filtrage, intégration, etc), et c'est de là que sont extraites les pistes éventuelles.

Echantillonner le signal brut à 10 GHz impose une fréquence d'échantillonnage d'au moins 20 GHz (Nyquist). Vous voulez transmettre ça sur un réseau ?

Partager le spectre du signal ne doit pas être beaucoup plus pratique, d'ailleurs, vu la masse de données que ça représente.

A partir de là, un partage ne peut concerner que les points d'intérêt (anomalies du signal, qu'elles soient ou non interprétées comme des pistes potentielles).

[prof.566]

Quote

Quand on passe en mode formation de piste la forcément la revisite et plus fréquente et l'analyse du signal retour est plus poussée... mais pourquoi s'emmerder a revisité 100 fois par seconde ... 1 fois ça suffit bien.

Une fois la piste établie on peut a nouveau ralentir le balayage.

Les pistes intéressantes peuvent passer en mode poursuite renforcée avec une revisite plus fréquente, échantillonner plus finement l'écho retour en mode analyse NTCR etc. mais ça concerne moins de 20 pistes normalement.

En gros pourquoi utiliser une vulgaire méthode de balayage brute force quand c'est pas nécessaire.

..”

 

Quelques points ;

1/ Il n’y a pas une voie de réception par module mais une voie de réception par secteur d’antenne (surtout les 4 cadrans élévation et circulaire permettant une écartométrie d’amplitude instantanée)
2/ Les centaines de modules regardent tous la même direction, direction qui est d’ailleurs le résultat voie par voie de la compilation en phase des signaux de tous les modules.
3/ La vitesse du balayage du mode veille est unique pour un mode donné (fréquence de répétition : MFR, BFR, ...) ; la fréquence de revisite est fonction de la dimension de la zone de veille adaptée au secteur d’intérêt (duquel la menace peut intervenir de partout). Il faut trouver le compromis entre fréquence de revisite et dimension de la zone selon les caractéristiques des menaces.
4/ effectivement, en cas de seuil de détection franchi (on parle de première détection), le balayage électronique permet de s’acharner dans la direction pour confirmer ou non, jusqu’à constituer un plot.
5/ le rafraichissement des infos du plot peut être ralenti, juste assez pour obtenir au plus vite les infos piste, donc la bonne qualité du vecteur vitesse permettant un tir (on dit souvent qu’un balayage électronique permet, par rapport à un balayage mécanique, de gagner une dizaine de milles entre la première détection en rapprochement et la capacité de tir).
6/ La notion de pistes renforcées revient effectivement à donner le temps de balayage qui va bien à celles-ci, éventuellement au détriment des autres.

[hadriel]

Il y a 9 heures, prof.566 a dit :

..”

 

Quelques points ;

1/ Il n’y a pas une voie de réception par module mais une voie de réception par secteur d’antenne (surtout les 4 cadrans élévation et circulaire permettant une écartométrie d’amplitude instantanée)

Les déphasages en réception sont obtenus de manière analogique sur les AESA?

[herciv]

@prof.566

Les S-400 achetés par les turques posent des problème d'interopérabilité pour le f-35

Apparemment c'est une vrai merde à résoudre car la Turquie n'est pas seulement cliente. Elle intervient aussi sur le plan industriel et sur la maintenance.

L'interopérabilité des pays non OTAN avec le f-35 est un vrai problème et donc pas uniquement pour les EAU signalé par @prof.566

“We’re going to have to start looking at, if they are going to go through with this, how we can be interoperable in the future. But right now, I can tell you our policies do not allow us to be interoperable with that system.”

..

Further complicating the issue is the planned delivery of Turkey’s first F-35s in 2018. Analysts worry that Turkey operating both the S-400 and F-35 together could compromise the jet’s security, as any data collected by the air defense system and obtained by Russia could help expose the joint strike fighter’s vulnerabilities. For a platform like the F-35, whose major strengths are its stealth and data fusion capabilities, that would be a disaster.

https://www.defensenews.com/digital-show-dailies/dubai-air-show/2017/11/16/us-official-if-turkey-buys-russian-systems-they-cant-plug-into-nato-tech/

“It’s a significant concern, not only to the United States, because we need to protect this high end technology, fifth-generation technology” but for “all of our partners and allies that have already purchased the F-35,” she said.

 

Le message est clair : si vous voulez profiter des megadonnées US faut entrer dans la coalition et ne plus rien acheter en dehors de celle-ci. Quelque part ce prositionnement était prévisible mais ça va radicaliser les positions diplomatiques en fonction du matériel acheté. Ils vont pas aimer les indiens.

 

 

Modifié le 17 novembre 2017 par herciv

[clem200]

Après l'iPhone, l'iPad, le iF35 ...

[Patrick]

Il y a 2 heures, herciv a dit :

Les S-400 achetés par les turques posent des problème d'interopérabilité pour le f-35

Tout ça présage d'une affaire type F-14 iraniens bis.

[prof.566]

Quote

Les déphasages en réception sont obtenus de manière analogique sur les AESA?

Hmmm.... Le déphasage est effectué à un niveau où le signal et sa phase sont analogiques, à XGHz, mais les filtres déphaseurs agissent d’une manière “discrète”, l’un assurant un déphasage de Pi/2, l’autre Pi/4 etc.

Pour donner un exemple : si la phase du signal initial est de 31°, une fois déphasé de Pi/2 et Pi/4, ça donnera 180+90+31=301°

 

Modifié le 17 novembre 2017 par prof.566

[Ponto Combo]

Un billet sur les méthodes de lobbying de LM

Le F-35, une influence des plus opaques

http://www.guerres-influences.com/le-f-35-une-influence-des-plus-opaques/

Citation

Chaque année, Lockheed Martin dépense environ 15 millions de dollars dans des campagnes d’influence diverses. Une somme qui n’inclut pas les « dons » réalisés en faveur de différents candidats aux élections locales et nationales.

Ça ne parait pas si élevé que ça pour une boite comme LM, par contre les méthodes...

[Teenytoon]

Oui, 15 millions de dollar de budget "publicité", pour une boîte comme LM, je ne vois pas bien l’extravagance. C’est 10% d’un F35 au tarif estimé actuel. 

[Picdelamirand-oil]

Lockheed Martin delays F-35 Block 3F software final certification to February

http://www.janes.com/article/75800/lockheed-martin-delays-f-35-block-3f-software-final-certification-to-february

If Turkey buys the Russian S-400 missile system, it can't be allowed to buy the F-35 fighter jet

http://www.washingtonexaminer.com/if-turkey-buys-the-russian-s-400-missile-system-it-cant-be-allowed-to-buy-the-f-35-fighter-jet/article/2641027

 

[prof.566]

L'année n'est pas préciseé...

Le bloc 3F décalé à Février

http://www.janes.com/article/75800/lockheed-martin-delays-f-35-block-3f-software-final-certification-to-february

[Gibbs le Cajun]