Ces dernières semaines, il semble que l’avion de combat français soit de nouveau entré dans le cœur des médias français, après des années de bashing incessant. Nombreux sont les quotidiens et journaux de renoms à vanter les mérites de notre chasseur national, alors que la signature d’un contrat n’a certainement jamais été aussi proche.
S’il est vrai que le Rafale possède des atouts qui font de lui un avion capable et accompli, et qu’il s’affiche au-dessus du lot dans certains domaines, il en est un qui n’est jamais abordé, mais qui pourtant mérite qu’on s’y attarde : son évolutivité.
Le Rafale a été conçu comme un avion dont le système d’arme, doté d’une architecture ouverte, est améliorable à l’infini –ou presque. Et là réside sa véritable force que seul le temps sera capable de dévoiler aux nombreux observateurs et détracteurs de ce programme, s’ils ne se limitent pas aux apparences d’un avion qui a volé pour la première fois il y a de cela plus de 20 ans.
Sommaire
- Retour en arrière historique.
- Évolutivité des avions de combat moderne
- Dassault Aviation : Technique des petits pas
- Une architecture matérielle modulaire
- Virtualisation des systèmes.
- Du matériel « Plug & Play »
- Conclusion
quelques termes assez exotiques sont utilisés dans cet article. Pour un complément d’information, n’hésitez surtout pas à utiliser les commentaires!
Retour en arrière historique.
L’aviation de combat est née pendant la Première Guerre mondiale. À cette époque, et en partant de pratiquement zéro, chaque évolution technique avait pour conséquence une augmentation majeure des performances. C’est ainsi que les avions imaginés quelques mois plus tôt pouvaient devenir obsolètes en un instant, face à un ennemi mettant en ligne un avion nettement supérieur. Au début du vingtième siècle, la période de temps comprise entre l’idée d’un plan d’avion, la réalisation d’un prototype, puis de la production à plusieurs milliers d’exemplaires, et son retrait du service, pouvait s’écouler assez rapidement… De l’ordre de 3 à 4 ans.
Au fur et à mesure de l’avancée des techniques de l’aéronautique puis de l’arrivée des premiers systèmes d’arme, la durée (et donc le coût) de conception va s’allonger exponentiellement, ainsi que la durée de vie de ces appareils. Nous sommes progressivement arrivées jusqu’à une durée de conception d’un système d’arme complet entre 10 et 15 ans, voire beaucoup plus pour les programmes les plus complexes, comme le F-35 qui devrait dépasser les 20 ans. La durée de vie d’un avion dans une armée de l’air a également été allongée. Il n’est pas rare qu’un avion soit prévu pour durer 30 ans, et dans le cas des appareils de nouvelle génération, des chiffres comme 50 ans ne surprennent plus.
Évolutivité des avions de combat moderne
Un des meilleurs exemples que nous offre l’histoire en termes d’évolution d’un avion de combat est certainement le F-16. Du petit avion de combat de jour qu’il était à la fin des années 70, il est progressivement passé au statut d’avion à tout faire, la bête de somme de bien des armées occidentales, avec, grâce à ses derniers standards (Block60/61 émirati notamment) des capacités loin d’être égalées par nombre d’autres avions, même plus récents.
Mais si la cellule reste la même, à l’intérieur de l’avion, tout ou presque a changé. Tous les équipements électroniques composant le système d’arme (Radar, calculateurs, brouilleurs, récepteur d’alerte Radar, IFF, etc.) ont été remplacés. Si le constructeur de l’avion a fait l’économie de la conception d’une nouvelle cellule, motorisation, commandes de vol et tous les essais en soufflerie et en vol que cela nécessite, nous avons bien à faire à chaque fois à un système d’arme nouveau. Si l’avion a bel et bien évolué, il serait plus judicieux de parler de modernisation plutôt que d’évolution.
Les améliorations apportées au F16 sont tellement récentes que 40 ans après, des avions neufs sortent toujours de sa chaine de fabrication. En 1975, qui aurait pu imaginer cela ? Et même encore aujourd’hui, cela reste un exploit. Un fait qui n’est pas unique et entre désormais dans l’histoire. La durée de vie d’un avion de combat dans son ensemble a augmenté exponentiellement. Car ce n’est plus les performances permises par le couple cellule/motorisation qui est devenu un facteur clé des performances de l’avion au combat, mais bel et bien son système d’arme.
Dassault Aviation : Technique des petits pas
Partant de ce constat, il serait tentant d’imaginer que les concepteurs du Rafale ont porté la philosophie de Marcel Dassault, la technique « des petits pas » sur la conception du système d’arme devant équiper l’avion.
La technique des « petits pas » est très simple à comprendre. Le fondateur de l’entreprise voulait prendre le moins de risque possible lors de la conception d’un avion. Ainsi, lorsqu’un nouvel avion était conçu, on utilisait toujours une motorisation existante. Si des progrès avaient été réalisés au niveau de l’aérodynamique, on ne changerait que les ailes tout en gardant la même cellule. Et c’est là toute l’histoire de la série des mystères jusqu’aux Mirage. Même la conception du démonstrateur technologique du Rafale n’est pas partie de zéro, puisqu’elle est en grande partie basé sur les acquis du regretté programme Super Mirage 4000.
Apporter cette philosophie sur un système d’arme n’est pas si simple. Surtout qu’avec l’avènement de l’informatique, tous les systèmes s’imbriquent entre eux. Le moindre changement pouvant avoir des répercussions sur l’ensemble des systèmes, les processus de tests et de validation sont complexes, longs et extrêmement rigoureux.
L’informatique évoluant sans cesse, tant en terme d’architecture matérielle que de langages informatiques, permettre de rendre réalisable l’évolution de tout un système pour les 30 ou 40 années à venir est une gageure.
Les concepteurs des systèmes du Rafale vont donc se reposer sur deux concepts bien implantés dans le domaine de l’informatique, mais rarement exploités dans l’aviation, et certainement jamais à cette échelle : la modularité, et la virtualisation.
Une architecture matérielle modulaire
Le principe de base de la modularité, sa définition même, est de pouvoir déplacer ou d’ajouter des éléments en fonction des besoins. On souhaite donc concevoir un système qui permette d’évoluer dans le temps, en ajoutant des « modules » de puissance supplémentaires lorsque cela s’avèrera nécessaire. Le Rafale sera doté d’un calculateur central dénommé MDPU (Modular Data Processing Unit), ou EMTI en français (Équipement Modulaire de
Traitement de l’Information). Chaque MDPU est composé matériellement d’un fond de panier comprenant 18 slots pouvant accueillir autant de modules.
Dans le détail :
Chaque module étant composé d’une carte mère, d’un calculateur (processeur), et de mémoire vive.
Lors du passage à la quatrième tranche de production, les nouveaux Rafale furent livrés avec des modules plus puissant permettant de supporter le surcroit de charge de travail du système apporté par les différentes mises à jour matérielles, et faire face également aux plus grandes données générées dans le système de fusion de données par un Radar AESA capable de voir plus loin, et faire bien plus de choses en même temps.
En 2003, et pour la production du Rafale au standard F2, chaque module EMTI du Rafale était composé d’un processeur PowerPC 740 cadencé à 200Mhz, et accompagné de 64Mo de mémoire vive. En 2006, les modules embarquent désormais un Power PC 750 cadencé à 733Mhz, avec 256 Mo de mémoire.
En ce qui concerne le standard de production actuel, tout au plus savons-nous que les processeurs, toujours basés sur l’architecture Power, ont dépassé le Giga hertz et sont devenus multicoeur.
Les capacités de calcul dépendant de l’architecture matérielle embarquée dans le Rafale sont donc évolutives, et pratiquement sans limites. Si ce n’est le goulet que pourrait devenir la largeur du Bus du MDPU, problème qui n’est pas non plus sans solutions.
Et ce n’est pas fini. Car non seulement les modules de l’EMTI sont remplaçable par de plus puissants, mais Dassault Aviation a prévu large, car un second emplacement est disponible pour ajouter un second Rack EMTI…
Virtualisation des systèmes.
En revenant à l’exemple de la modernisation du F-16, chaque nouveau standard comprenait l’arrivée de nouveaux matériels, et de nouveaux logiciels devaient systématiquement être créés pour pouvoir les utiliser.
Pour simplifier à l’extrême, chaque logiciel est créé et dépend du matériel sur lequel il a été créé pour fonctionner. Comment s’assurer alors que le logiciel du Rafale puisse continuer à évoluer dans les décennies à venir, sans avoir besoin de tout réécrire si jamais le matériel change ? Réponse simple : la virtualisation !
La virtualisation permet une abstraction matérielle. Le logiciel fonctionne dans un environnement qui restera identique toute sa vie durant, et seule la partie logicielle (un hyperviseur) servant à faire le lien entre le matériel et cet environnement sera adaptée.
Lors de l’installation des premiers modules EMTI basés sur une nouvelle génération de processeur en 2006, les ingénieurs ont démarré le système, et… tout a fonctionné du premier coup ! Si des tests poussés sont effectués afin de s’assurer de la non-régression des systèmes de l’avion, aucune réécriture de code des logiciels dont dépend le système d’arme du Rafale n’a été nécessaire.
Rafale Update
Le développement des logiciels n’est jamais arrêté concernant un avion de combat. Avec l’ajout permanent de nouveaux armements, équipement, ou pour répondre à l’apparition de nouvelles menaces, le système de combat évolue sans aucune limite. Les améliorations logicielles sont livrées sous la forme de standard. Il y a les standards principaux F1/F2/F3, chacun subdivisé en sous-standards. Actuellement, le standard en service est le F3R(prime).
La mise à jour d’un Rafale est réalisée en quelques heures seulement via le branchement d’un ordinateur sur l’avion. S’ensuit une vérification des systèmes et l’avion est de nouveau opérationnel !
Lorsque le standard F3R devra être opérationnel en 2018, l’ensemble des avions de l’Armée de l’Air et de la Marine Nationale seront alors mis au dernier standard de la même façon, et tous seront capables de jouer avec la nouvelle nacelle de désignation laser de Thales, ou de tirer les nouveaux missiles très longue portée Meteor.
Du matériel « Plug & Play »
À la façon d’un ordinateur, un Rafale reconnait automatiquement le matériel qui lui est associé. Cela fait désormais partie du quotidien dans l’informatique. Vous ne vous posez pas la question, lorsque vous branchez un clé USB sur votre ordinateur, s’il faut l’installer ou pas… Et pourtant, il n’y a pas si longtemps que cela, l’ajout de n’importe quel matériel ou périphérique nécessitait une certaine dose de patience pour « apprendre » à l’ordinateur à utiliser le nouveau périphérique.
Le matériel du Rafale a également évolué. Comme nous l’avons vu plus haut, les modules de l’EMTI livrés récemment sont plus récents et plus puissants que ceux installés dans les avions les plus anciens. Ainsi, il est possible d’interchanger des modules entre les avions plus récents et d’autres plus anciens afin que la puissance de calcul moyenne soit équivalente dans tous les avions en parc. De cette façon, l’armée de l’air met à jour tous ces avions de manière plus ou moins homogène sans avoir besoin de racheter de nouveaux modules. Merci le Plug & Play ; mais cela va beaucoup plus loin que ça.
Les avions de la quatrième tranche de production sont livrés depuis la fin de l’année 2013. Ils embarquent de nouveaux « périphériques » augmentant très sensiblement les capacités de combat de l’avion, comme le DDM-NG ou le Radar RBE2 AESA équipé d’une antenne active. Ces équipements sont chers, et l’état des finances actuelles de l’armée de l’air ne permet certainement pas d’en acheter pour mettre tous les Rafale à jour. Mais pour maximiser le niveau opérationnel du parc, et lorsqu’un avion de la quatrième tranche est indisponible pour raison de maintenance par exemple, il est tout à fait possible de démonter le nouveau Radar, puis de le monter sur un des premiers avions livré en 2005. Étant donné que le logiciel de celui-ci est à jour, il n’aura aucun mal à reconnaitre et à exploiter le plein potentiel de son nouveau périphérique. Durée de l’opération, moins de trois heures !
Synthèse et conclusion :
Avec l’EMTI, la virtualisation et sa gestion des périphériques, le Rafale a été conçu comme une plateforme à très fort potentiel d’évolution. Bien que tous les avions puissent être modernisés profondément pour acquérir des capacités modernes, aucun pour le moment ne peut se targuer d’offrir un si haut niveau d’intégration, lui permettant d’évoluer aussi facilement, et donc à moindre coût. Pour s’en apercevoir, il suffit de regarder la concurrence.
Saab a lancé un programme de modernisation important de son Gripen. Hormis la modification de sa structure qui permettra d’emporter un moteur plus puissant et plus de carburant, la majorité des équipements électroniques sont différents. Outre le fait que les efforts de développement sont importants, et en ne parlant pas de modification structurelle, les anciens avions ne bénéficieront pas des améliorations, sauf à repasser par la case « usine ».
Plus proches du Rafale, nous avons l’Eurofighter, qui a été conçu selon une méthodologie plus traditionnelle. Ainsi, les avions des tranches de production 1, 2 et 3 possèdent chacun des standards logiciels et matériels qui leur sont propres (sans parler de la pléthore de sous-standards). La flotte n’est donc pas homogène, et cela conduit à une perte d’efficacité opérationnelle d’une part, une diminution de la durée de vie utile des premiers avions d’autre part, mais est également devenu un casse-tête logistique qui explique en partie le coût élevé du maintien en conditions opérationnel de ces avions. Voir l’article : Tempête sur le Typhoon.
Il y a également le cas du F-35 qui développe deux standards logiciels possédant les mêmes capacités, mais sur du matériel différent. Le Block 2F est en effet l’équivalent pour le F-35B du block 3I du F-35A, mais les deux avions ne disposent pas du même matériel…
Avec un couple cellule/motorisation offrant de bonnes performances, et un système d’arme à même de pouvoir évoluer sans aucune limite, le Rafale offre à ses utilisateurs un système d’arme tellement évolutif que la perspective du remplacement de l’avion est devenue secondaire… Le Rafale est appelé à se succéder à lui-même, pendant de nombreuses années encore.
23 Comments
Anonyme
Voilà un excellent article qui présente un aspect méconnu du Rafale.
Bravo.
Anonyme
Brillante intuition des equipes de Dassault, si l'on songe à l'époque ou ces choix ont été pris ! il reste à protéger le Rafale des virus !
Anonyme
L'avion n'est pas connecté sur internet et c'est les constructeurs qui fournissent aux militaires les codes informatiques. aucune chance de virus…
Nono
Affirmation péremptoire et on ne peut plus fausse !
Si c'était si simple et si sûr que vous le dites (pas d'internet + codes informatiques "de source sûre" = sécurité absolue), le virus Stuxnet n'aurait jamais pu infecter les automates Siemens qui gèrent les centrifugeuses d'enrichissement d'uranium en Iran ! 🙂
La faille comporte toujours une composante humaine, et le simple fait de propager des croyances en une sécurité absolue est déjà, en soi, une erreur qui peut mener à la catastrophe. Pensez-y.
Anonyme
Cependant il ne faut pas négliger que la centrifugeuses d'enrichissement d'uranium en Iran tournait sous Windows et que le ver Stuxnet est dédié à windows. Enfin c'est probablement (on en est pas sur à 100%) une femme de ménage qui l’a amené avec une clé USB. Donc sauf si les avions ont des prises USB ça risque d’être dur d’implanter ce genre de virus.
Après il ne faut pas oublier que les Chinois ont réussi à pirater les US et à leur piquer des données top secrètes concernant le f35 (ou le f22 je sais plus trop).
Anonyme
N'oubliez pas que l'operating system d'un calculateur d'avion est un OS temps réel embarqué. Il ne contient que du code binaire exécutable dans un espace mémoire limité. Il n'est conçu que pour réagir en temps réel à des évennements liés à l'aviation et à son système d'armes. C'est d'une conception très spécifique connue de peu de monde. Implanter un virus requiert une connaissance approfondie de l'OS et de ses failles potentielles. De plus on ne pourrait l'implémenter que dans une phase de mise au point d'un nouveau logiciel car au niveau de la maintenance avion, le compte maintenance est volontairement limité et ce ne sont que des menus qui doivent soit tester soit faire une mise à jour de µcode.
Ce qui est plus vraisemblable, ce sont les bugs dans un programme (cf le F22). Bien que ces programmes soient testés et re-testés(phase très longue), on n'est jamais à l'abri. Ne pas oublier qu'avant d'implanter un binaire exécutable, c'est tester sur simulateur.
Ce qui est très fort de la part des équipes Dassault ingénierie embarquée, c'est d'avoir conçu en 2006 un OS temps réel virtualisé permettant ainsi de s'affranchir de l'obsolescence matérielle/logicielle et de le faire tourner sur du matériel/logiciel dernier cri. Ne pas oublier que Dassault est le concepteur du logiciel Catia! Donc un grand bravo à l'équipe d'ingénieurs.
Si l'avion est techniquement réussi, ce n'est pas encore le cas commercialement. Espérons que 2015 nous annonce au moins 2 bonnes nouvelles, cela permettrait de remettre les pendules à l'heure au niveau de la concurrence. Il faut beaucoup de patience à l'avionneur car un marché militaire n'est pas un marché civil et l'inter-dépendance étatique est forte.
Anonyme
Pour rendre a cesar ce qui est a cesar,
l’OS temps reel de l’EMTI ainsi que l’EMTI lui meme n’est pas l’oeuvre de Dassault, c’est Thales qui en est l’auteur.
Et repose sur un dérivé d’OS très connu opensource.
Si il est difficile de concevoir un virus sans avoir accé a cet OS c’est un OS qui se comporte largement comme beaucoup de versions/dérivés de linux et il est tout a fait possible d’y introduire des virus.
bien sur c’est bien plus difficile que dans le cas de Stuxnet parce que dans ce cas le NSA a pu acheter/recuperer les automates allemand mis en œuvre dans les centrifugeuses.
Et si le point d’entrée du virus est bien un Windows la cible était des automate pas du tout sous Windows. Je vous laisse regardé quel system est utilisé sur les postes informatiques de notre armé …
James
Bravo pour l'article. Je pense que certains habitués seront vite décrochés.
Cet aspect système a été dès le début mis en avant par Dassault, voir pubs au Bourget des années 90 mais comme c'était moins "sexy" que les évolutions dans les airs ou les armes, de plus on (les médias) attendait que l'avion prouvait ses capacités "guerrières", ce qui a été fait depuis ses Opex.
JM
Excellent article didactique qui nous explique bien en quoi le Rafale est différent de ses concurrents !!
Merci pour ces explications, et pour le blog en général qui est passionnant !!
Anonyme
super article ! vraiment !
Anonyme
Merci Bruno et merci à Dassault Aviation !
Patrice Lecuyer
Michel47
Un grand BRAVO pour cet article qui associe simplicité de langage et haute technologie.
Un Fan du "portail-aviation"
;o)
David Privat
Excellent !
Une "synthèse" très didactique, merci.
FDB.
Le_Renard_Polaire
Une synthèse claire et digeste, bravo !
Haikai
Belle esprit de synthèse, qui nous explique clairement ce que jusqu'ici on ne pouvait que deviner sur les capacités d'évolution, ou plutôt de modernisation, du Rafale.
Nous pourrons donc, peut-être, voir un jour un Rafale évoluer vers la 6ème génération d'avion de combat, sans que cela ne pose de problème… Cela devrait ravir les contribuables. A condition, bien sûr, de pouvoir maintenir sa production assez longtemps.
Espérons ainsi que l’État français puisse commander ou vendre le plus de Rafale possible…
Haikai
Anonyme
Bravo le Portail!
Vous devriez aussi diffuser cet article en anglais, ça donnerait du grain à moudre à quelques uns…
Bien à vous,
Julien
thierry
Merci pour ces infos qui nous permettent de mieux comprendre la manière dont ce système a été conçu .
Gunmo
Bonjour,
Super article ! Merci à http://www.reddit.com/r/france de me l’avoir fait connaitre.
Cependant, il n’y a pas une petite coquille ici, je cite :
(…)La virtualisation permet une abstraction matérielle. Le logiciel fonctionne dans un environnement qui restera identique toute sa vie durant, et seule la partie logicielle (un hyperviseur) servant à faire le lien entre le matériel et cet environnement sera adaptée.(…)
Ce ne devrait pas plutôt être :
(..)La virtualisation permet une abstraction LOGICIELLE. Le MATÉRIEL fonctionne dans un environnement qui restera identique toute sa vie durant, et seule la partie logicielle (un hyperviseur) servant à faire le lien entre le matériel et cet environnement sera adaptée.(…)
?
Bruno ETCHENIC
Non non c’est bien cela. En réalité, comment en informatique, si j’aurais voulu être pointilleux j’aurais dû dire que la virtualisation c’est l’abstraction de la couche N-1.
Le matériel peut évoluer comme bon lui semble, l’hyperviseur fera en sorte de créer un environnement qui sera toujours identique pour le logiciel, qui lui “pensera” toujours fonctionner avec le même matériel.
Shelshel
En fait, je pense que l’utilisation “virtualisation” est peut être trompeuse si on s’imagine un fonctionnement tel que Virtualbox ou systèmes similaires.
Ici, on a plutôt affaire à l’utilisation d’un OS temps réel qui fourni une couche d’abstraction (API) afin d’utiliser le matériel qui est derrière. Un peu comme un logiciel Windows tournera sur tous les materiel PC vu que c’est Windows qui fournis le couche d’abstraction (API).
Sauf que là on parle bien d’un OS temps réel, donc avec une réelle ségrégation de temps CPU et de mémoire antre les différentes application (appelé généralement “conteneur”)
La même chose est utilisée sur les Airbus de dernière génération (A350, A380 et son dérivé militaire A400M) avec un materiel appelé CPIOM. C’est d’ailleurs mon métier de développer du soft embarqué temps réel sur ces CPIOM pour ces avions Airbus…
Anonyme
Quelques précisions :
Virtualisation :
il existe différents niveaux de virtualisation, ce que certains semblent ignorer mais sans doute pas notre rédacteur puisqu’il est informaticien de profession, mais en réponse à une réplique il aura oublié d’apporter cette précision.
La virtualisation de niveau 1 (celle dont il serait question ici) est une virtualisation de type matérielle.
Un exemple célèbre disponible sous Linux comme Windows est QEMU.
Qu’est ce que cela signfifie ? Ca signifie qu’en faisant tourner Qemu sur un ordinateur Windows à architecture x86 (Intel), QEMU est capable d’émuler par exemple un processeur de type ARM, PowerPC etc etc.
La virtualisation de niveau 2 est une virtualisation logicielle exclusivement. Et en effet, Virtualbox en est l’exemple le plus célèbre.
Une fois compilé pour Windows ou Linux, Virtualbox sera capable d’émuler au choix des systèmes d’exploitation Windows ou Linux MAIS pour architecture x86 Intel exclusivement, virtualbox ne sera pas capable de faire touner une version de Linux compilé sous ARM (utilisée par exemple sur les Raspberry py)
De quoi parle t-on ici ? On ne peut pas vraiment savoir et dans ce cas on ne peut que faire confiance au rédacteur.
Je suis la saga Rafale depuis très longtemps alors que j’étais encore gamin et que l’oiseau n’était qu’à l’état de projet… autant dire qu’au moment du lancement de ce projet la virtualisation n’existait pas… ou disons très peu du fait de la faible puissance des processeurs.
D’ailleurs à l’époque je crois que le terme n’existait pas, on parlait d’émulation.
Le seul cas “grand public” qui me vient à l’esprit c’est le fameux processeur DEC Alpha dédié aux serveurs mais qui apparurent très brièvement sur une très petite série de PC de bureau lancés par Digital Equipment.
D’ailleurs si vous en récupérez un, ce peut être un véritable objet de collection car très rare, c’était hyper novateur pour l’époque (fin des années 80), il ne doit pas y en avoir beaucoup en France, peut-être à peine plus que des Apple Lisa.
L’utlisateur avait le choix soit de lancer la bécane en mode station de travail native DEC Alpha, ou de la lancer en mode émulation IBM PC architecture Intel x86… donc là on parle d’un hyperviseur de niveau 1
C’était possible car le processeur DEC Alpha était une puce 64 Bit surpuissante en son temps capable d’émuler sans peine le fonctionnement d’un x86 32 bit de l’époque.
Virus :
Attention à ne pas raconter des conneries.
Comme cela a été déjà précisé l’immense majorité des virus ont été développés pour Windows, ils prolifèrent désormais sous Android, iOS et MacOS
BREF DES SYSTEMES A VOCATION GRAND PUBLIC PRINCIPALEMENT
Linux et BSD (hors Mac OS) restent relativement épargnés. Il y a quelques virus sous Linux … mais que tchi, ça doit se compter sur les doigts d’une seule main.
On remarquera qu’un virus développé pour Mac OS n’aura pas pour autant d’effet sur son cousin FreeBSD….
Car en réalité un virus est très fragile, il est conçu pour fonctionner dans un environnement très précis, dès que cet environnement n’est plus le même en général il ne marche plus.
Par exemple un virus développé pour un Windows de bureau ne marchera pas obligatoirement sur la version Windows Embbeded, qui comme son nom l’indique désigne la version de l’OS embarqué (comme sur les disctributeurs de billets).
Le noyau est éventuellement le même, mais pas l’environnement.
Si votre virus a été compilé pour Mac OS il ne tournera pas sous FreeBSD point final, quand bien même ces deux systèmes sont des systèmes BSD car d’une les “binaires” sont rigoureusement incompatibles, de deux les environnements sont sensiblement différents.
C’est la même raison qui rend les virus très compliqués à développer sous Linux du fait de la multitude de distributions Linux.
Les virus seront donc développés pour les distributions utlisant des paquets les plus standards possible genre .rpm (Red Hat, Mageia…), .deb (debian, Ubuntu…)
A ma connaissance… je ne connais pas de virus sous FreeBSD, il y en a quelques uns sous MacOS (disons un peu plus que sous Linux) mais pas des masses.
Ne parlons même pas de certains OS très obscurs genre VMS (héritage de DEC sur les fameux VAX stations qui furent très en vogue dans les entreprises de la finance par exemple).
Aujourd’hui VMS est utlisé en circuit fermé pour la gestion des lignes de métro totalement automatisées de la RATP à Paris, VMS est aussi très utilisé en circuit fermé dans des environnements industriels genre chaines de montage, autant vous dire que les virus n’existent pas, car la création d’un virus répond avant tout à une logique économique.
On développe un virus sur des plateformes à forte diffusion, et si Siemens s’est amusé à utliser Windows pour ses histores de centrales à je ne sais pas quoi, ce sont de purs imbéciles.
Les calculateurs du Rafale étant à base de PowerPC, ce n’est pas du Windows cà c’est certain… Ce peut être du VMS, UNIX, BSD…
Il est peu probable que ce soit du Linux car la licence Linux est liée à cette saloperie de GPL qui oblige tout contributeur à rendre les portions de code modifié disponible au public.
Imaginez bien qu’un concepteur d’armes n’ira jamais faire cela, et c’est là que l’on mesure tout le génie de Steve Jobs qui comprit bien avant tout le monde qu’il était préférable de s’appuyer sur des licence de type BSD, MIT… d’où le choix de BSD comme base au lieu de Linux, qui permettent à tout un chacun de faire ce que l’on veut du code de base sans aucune obligation de publication.
Un virus reste théoriquement possible… mais ce virus viendrait obligatoirement d’une action malveillante d’un membre du bureau d’étude.
Comme rappelé un virus est très fragile car il est prévu pour fonctionner dans un environnement donné, or l’environemment du Rafale est un environnement dédié ou “appliance” qui n’a rien à voir avec un Unix, Linux utlisé sur un serveur d’entreprise ou sur un PC de bureau.
Il faut avoir un accès privilégié pour pouvoir connaitre les caractéristiques de cet environnement, developper un virus, le tester et le diffuser.
Donc cette hypothèse de virus reste possible…. mais très théorique, en revanche les “bug”, ça c’est autre chose.
Un avion peut très bien s’écraser si par exmeple un logiciel de pilotage automatique est “buggé”, il ne faut pas aller crier au loup en pensant obligatoirement à un piratage ou un virus quelconque.
Et en fait un bug… c’est monnaie courante. Il faut louer la qualité des développeurs chez Thales/Dassault qui semblent en mesure de développer du code sans trop de bugs… car le débuggage ça prend un temps considérable.
Visiblement chez Lockheed… ils ont plus de soucis.
Ceci étant Thalès qui dispose d’une grosse branche “cyber sécurité” prend effectivement en compte ce risque potentiel sur les avions de ligne puisque en théorie les avions de lignes pourraient être vulnérables via les terminaux passager de divertissement qui sont en effet connectés à Internet
Après il est bien évident que des barrières sont établies entre ces systèmes de divertissements et les calculateurs de vol qui fonctionnent sans aucun doute sous des environnements totalement différents.
A quel niveau est ce risque ? Y t-il des passerelles (donc une possible vulnérabilé) entre les systèmes de controle de vol avec Internet ? Notamment en cas de détournement d’un avion avec des pilotes neutralisés, pourquoi pas imaginer qu’une porte dérobée ait été installée pour qu’un airbus puisse être repris en mains via un centre de contrôle au sol en neutralisant toute action des pirates ?
C’est théoriquement imaginable.
Le degré d’automatisation des Airbus est très très élevé, ce sont des avions quasi capables de s’autopiloter si ce n’est d’atterir tout seul
On ne le sait pas car communiquer ce serait donner des armes aux pirates informatiques, comme le dit Thales, donc personne ne dira jamais rien à ce sujet.
Ce n’est pas comme les failles de sécurité sur PC… au bout d’un certain délai elles sont publiquement communiquées, donc si l’éditeur n’a pas corrigé entre temps, ou si plus simplement l’utilisateur est négligent et ne fait pas ses mises à jour, tous les hackeurs de la planète peuvent utliser cette faille.
En aviation civile ou militaire… c’est secret défense
En tout cas pour revenir au Rafale qui à coup sûr fonctionne très certainement en vase clos, il ne faut surtout pas faire l’amalgame avec toutes les affaires alarmantes de virus qui touchent nos PC et nos smartphones.
On voit au passage que la virtualisation de niveau 1 permettrait à Dassault de basculer sur des calculateurs totalement différents en architecture Intel Itanium par exmeple… il faut juste au départ compiler un hyperviseur niveau 1 adapté pour assurer la rétro compatbilité avec les anciens codes.
Maurice
Le problème est que le Rafale transporte 2,5 tonnes d’électronique alors que le F-16 n’en transporte que 250 kilos, c’est à dire, 10 fois moins en poids et nettement plus performante !
Bruno
Tout à fait.
1) d’où sortent ces chiffres ?
2) les architectures sont différentes, comparer leur performances revient à comparer des choux et des carottes.
3) même la dernière version du F16 ne dispose pas de la fusion complète des capteurs, très gourmande en puissance de calcul. Encore une fois, aucun rapport.
4) un EMTI, c’est propre au rafale en rapport des autres avions de combat, mais pas dans le civil où c’est devenu un standard. Même sur le F35, le passage entre deux sous standard nécessitent le changement des calculateurs et de toute une partie de l’électronique.
5) et puis qu’est ce qu’on compte dans l’électronique ? Radar, contre mesure et tout le tin touin ? À ce compte le f-16 est largué, et de loin. Si comparaison il faut faire, c’est avec le F35, ou les versions à l’étude de l’advanced super hornet.
6)… Bon je vais arrêter là, je vois pas pourquoi je réponds à un commentaire aussi trollesque.