PROCEDE ET DISPOSITIF DE GESTION SECURISEE D’UNE BANQUE D’IMAGES POUR L’AIDE A L’ATTERRISSAGE D’AERONEF

[0001] L’invention concerne un procédé et un dispositif de gestion sécurisée d’une banque d’images utilisées par les systèmes d’aide à l’atterrissage des aéronefs. Le domaine d’exploitation principal de l’invention est celui des systèmes d’aide à l’atterrissage dits EVS (« Enhanced Vision System » en anglais) basés sur des caméras ou capteurs d’imagerie électro-optique, infra-rouge ou radar pour filmer l’environnement aéroportuaire lors de l’atterrissage d’un aéronef.

[0002] L’invention adresse le problème général de l’aide à l’atterrissage d’aéronefs sur une piste d’atterrissage, par conditions de visibilité réduite, en particulier à cause de conditions météorologiques difficiles, par exemple en cas de brouillard. Les normes imposent des règles d’obtention de visibilité pendant la phase d’atterrissage. Ces règles se traduisent par des seuils de décision qui se réfèrent à l’altitude de l’avion lors de sa phase de descente. A chacun de ces seuils, des repères visuels identifiés doivent être obtenus pour poursuivre la manoeuvre d’atterrissage, sans quoi elle doit être abandonnée. Les manoeuvres d’atterrissage abandonnées représentent un réel problème pour la gestion du trafic aérien et pour la planification des vols. Il faut estimer avant le décollage la capacité à pouvoir atterrir à destination sur la base de prévisions météorologiques, plus ou moins fiables, et le cas échéant prévoir des solutions de repli.

[0003] Le problème de l’atterrissage des aéronefs par conditions de visibilité réduite a fait l’objet du développement de plusieurs techniques qui sont actuellement utilisées.

[0004] L’une de ces techniques est le système d’atterrissage aux instruments ILS (« Instrument Landing System » en anglais). Le système ILS repose sur plusieurs équipements de radiofréquence installés au sol, au niveau de la piste d’atterrissage, et un instrument compatible placé à bord de l’aéronef. L’utilisation d’un tel système de guidage requiert des équipements onéreux et une qualification spécifique des pilotes. Il ne peut par ailleurs pas être installé sur tous les aéroports. Ce système n’est pas généralisé et il sera dans l’avenir probablement décommissionné. [0005] Une autre alternative est l’aide à l’atterrissage par GPS (« Global Positioning System » en anglais). Bien qu’ayant une précision suffisante, la fiabilité de cette solution est trop faible puisqu’elle peut facilement - intentionnellement ou non - être sujette au brouillage. Aussi, son intégrité n’est pas garantie.

[0006] Une technique de vision augmentée EVS est également employée. Le principe est d’utiliser des senseurs plus performants que l’œil du pilote par conditions météorologiques dégradées, et d’incruster les informations collectées par les senseurs dans le champ de vision du pilote, par le biais d’un affichage tête haute ou sur la visière d’un casque porté par le pilote. Cette technique repose essentiellement sur l’emploi de capteurs pour détecter le rayonnement des lampes disposées le long de la piste et sur la rampe d’approche. Les lampes à incandescence produisent de la lumière visible mais elles émettent aussi dans le domaine infrarouge. Des capteurs dans le domaine infrarouge permettent de détecter ces rayonnements et la portée de détection est meilleure que celle de l’être humain dans le domaine visible, lors de conditions météorologiques dégradées. Une amélioration de la visibilité permet donc dans une certaine mesure d’améliorer les phases d’approche et de limiter les approches abandonnées. Toutefois, cette technique repose sur le rayonnement infrarouge parasite des lampes présentes au voisinage de la piste. Pour des soucis de durabilité des lampes, la tendance actuelle est au remplacement des lampes à incandescence par les lampes à LED. Ces dernières ont un spectre moins étendu dans le domaine infrarouge. Un effet collatéral est donc de provoquer une obsolescence technique des systèmes EVS à base de capteurs infrarouge.

[0007] Une alternative aux senseurs infrarouges est l’obtention d’images par un senseur radar, en bande centimétrique ou millimétrique. Certaines bandes de fréquence choisies en dehors des pics d’absorption de la vapeur d’eau présentent une sensibilité très faible aux conditions météorologiques difficiles. De tels senseurs permettent donc de produire une image au travers de brouillard par exemple. Cependant, même si ces capteurs ont une résolution en distance fine, ils présentent une résolution angulaire bien plus grossière que les solutions optiques. La résolution est directement liée à la taille des antennes utilisées, et elle est souvent trop grossière pour obtenir un positionnement précis de la piste d’atterrissage à une distance suffisante pour effectuer les manœuvres de recalage. [0008] Quelle que soit la méthode (EVS, Radar) utilisée dans un système d’aide à l’atterrissage, il y a toujours un traitement d’images pour permettre le déroulement des procédures de vols qui utilisent ces capteurs pour aider l’équipage à se positionner par rapport à la piste d’atterrissage ou au terrain de posé.

[0009] Les traitements d’images actuels sont liés à une typologie d’image particulière à chaque senseur, et sont effectués a priori, par calibration et expérience. Or, les traitements d’images sont calibrés sur la base de quelques aéroports uniquement.

[0010] Dans certains cas, des vols sont effectués par temps clair en journée pour calibrer les capteurs en question. Cependant compte-tenu du coût des vols pour générer des images, le nombre de vols reste très limité et par conséquent la banque d’images qui regroupe l’ensemble des images collectées reste de taille réduite.

[0011] Par ailleurs, la banque d’images reste incomplète car elle ne prend pas en compte la diversité des situations météorologiques, la variabilité de l’environnement (comme la présence d’obstacles temporaires par exemple), et elle n’est de surcroît pas exhaustive sur terre.

[0012] Il en résulte alors une fiabilité réduite des calculateurs de pilotage ou d’affichage qui utilisent de l’imagerie pour les opérations aériennes.

[0013] Il existe donc un besoin d’améliorer les traitements d’images pour les opérations aériennes, en augmentant le volume de données de la banque d’images afin d’atteindre un seuil de fiabilité requis tant en termes de précision qu’en termes de couverture géographique.

[0014] Plus généralement, un but de l’invention est l’obtention d’une masse critique d’images issues de capteurs embarqués sur des aéronefs participant à une communauté de fournisseurs d’images, qu’il s’agisse d’images dans le visible, dans l’infra-rouge ou d’images radar. La masse critique d’images doit être suffisante pour que des traitements d’image puissent fonctionner avec une fiabilité qui permette d’améliorer la sécurité des opérations aéronautiques basées sur l’utilisation de tels senseurs.

[0015] Un autre but de l’invention vise à répondre au besoin d’encourager la participation à l’enrichissement d’une telle banque d’images. Ce but est atteint par la mise en place de mécanismes de rétribution juste et certaine des contributeurs qui fournissent les images ou qui fournissent les processus permettant les traitements des images. En effet, un autre frein à l’amélioration du contenu de la banque d’images est le faible taux de contributeurs et il existe le besoin d’inciter tout acteur à participer à cette mise à jour des données d’images qu’ils produisent ou qu’ils utilisent, de manière collaborative et sans intermédiaire. Les acteurs créateurs et/ou gestionnaires de données d’images peuvent être assez variés incluant de manière non limitative, des fournisseurs de capteurs d’image, des avionneurs, des spécialistes du traitement d’images, des états (concepteurs de procédures de navigation), des chercheurs, des compagnies aériennes.

[0016] Au-delà de la question d’une rétribution inexistante pour un fournisseur d’images, une des raisons de la faible participation actuelle est liée à la question du risque de l’utilisation d’images dont la provenance n’est pas certaine et/ou dont la fiabilité n’est pas validée. Aussi, il existe le besoin de mécanismes de validation sûrs des données en provenance d’un fournisseur d’images, la validation certaine devant porter au moins sur la date d’obtention et de mise à disposition des images, et sur l’authentification de l’émetteur.

[0017] Ainsi, un objet de l’invention est de pallier les inconvénients des techniques connues.

[0018] A cet effet, l’invention a pour objet de répondre aux besoins précités en proposant une solution de gestion sécurisée d’une banque d’images pour des opérations aériennes, notamment pour l’aide à l’atterrissage des aéronefs.

[0019] Pour obtenir les résultats recherchés, il est proposé un procédé mis en oeuvre par ordinateur pour la gestion sécurisée d’une banque d’images pour l’aide à l’atterrissage d’aéronef, le procédé comportant au moins des étapes de : recevoir des données capteurs, les données étant relatives à au moins une image collectée par au moins un capteur équipant un aéronef, ledit aéronef faisant partie d’une communauté de fournisseurs d’images comprenant une pluralité d’aéronefs, chaque image capteur collectée étant étiquetée avec au moins des informations d’horodatage et d’identification du fournisseur d’images, et un moyen de valider l’intégrité des données ;

- valider l’intégrité des données reçues selon un processus de validation par consensus distribué ; - créer un bloc de données validé, si l’intégrité des données est validée, ledit bloc validé comprenant au moins un lien vers lesdites données capteurs ; et

- mettre à disposition le bloc de données validé dans un réseau de registres distribués.

[0020] Selon des modes de réalisation alternatifs ou combinés :

- l’étape de validation par consensus distribué consiste à mettre en oeuvre un algorithme de consensus pour faire valider l’intégrité des données par au moins deux fournisseurs d’images parmi la communauté des fournisseurs d’images.

- l’étape de validation par consensus distribué comprend une étape de vérification de la qualité des images capteurs via des règles de validation dépendant des fournisseurs d’images.

- les données comprennent de plus un résumé de contenu et des données additionnelles relatives à, notamment la météo, l’état de systèmes de navigation au moment des prises de vue, la position 3D de l’aéronef au moment du toucher sur la piste, la position 3D et l’orientation 3D de l’aéronef par rapport à la terre et/ou du capteur ayant pris la/les images.

- le procédé comprend après l’étape de réception des données, une étape de stocker les données capteurs dans une base de données d’images capteurs, et où l’étape de validation se fait sur les données stockées.

- le réseau de registres distribués est une chaîne de blocs comprenant une pluralité de noeuds.

- l’étape de validation par consensus distribué est interne à la chaîne de blocs et consiste en une preuve de travail, et l’étape de mise à disposition dudit bloc validé consiste à ajouter ledit bloc validé à la chaîne de blocs.

- l’étape de validation par consensus distribué comprend de plus une étape de rétribution du ou des noeuds de la chaîne de blocs contributeur(s) à la validation.

- l’étape de rétribution consiste à accorder un score synthétique VS à un nœud de la chaîne de bloc qui est contributeur à la validation. - l’étape de validation par consensus distribué est effectuée par un code logiciel appelé contrat intelligent stocké sur et exécuté par la chaîne de blocs.

- le procédé comprend de plus une étape consistant à utiliser les données capteurs validées pour entraîner des algorithmes d’apprentissage automatique et générer des modèles algorithmes de traitement d’images entraînés.

- l’apprentissage automatique se fait sur des réseaux de neurones profonds, notamment des réseaux de type réseau neuronal convolutif CNN ou de type réseau antagoniste génératif GNN.

- le procédé comprend de plus une étape de stocker les modèles d’algorithmes de traitement d’images entraînés dans une base de données d’algorithmes de traitement d’images entraînés et/ou une étape d’écrire les modèles dans une chaîne de blocs.

- l’étape d’écrire consiste à écrire un hash dans la chaîne de blocs.

- le procédé comprend de plus une étape d’envoi d’un ou plusieurs modèles d’algorithmes de traitement d’images entraînés vers une entité consommateur ayant émis une requête d’utilisation de modèle.

- la requête d’utilisation est un ordre d’achat passé sur la chaîne de blocs où sont écrits les modèles, ou est faite par un contrat intelligent auquel l’entité consommateur est abonnée.

- l’étape d’envoi consiste à envoyer une clef de décryptage pour un modèle d’algorithme requis.

- le procédé comprend de plus une étape de vérification de la capacité de l’entité consommateur à recevoir le ou les modèles requis.

- le procédé comprend de plus une étape de rétribution de type VS pour une entité consommateur qui participe à la validation de données capteurs.

[0021] Avantageusement, l’invention met en oeuvre des mécanismes d’horodatage sûrs pour la mise à disposition dans une base de données d’images capteurs géo- référencées, de nouvelles images capteurs prises pendant des vols par une pluralité d’aéronefs dits « fournisseurs d’images », chaque image étant associée à des paramètres du vol correspondant, et notamment les paramètres de position 3D et d’orientation 3D de l’appareil au moment de la prise de vue. [0022] Avantageusement, la validation des images à ajouter à la banque d’images est une validation par consensus. Notamment, la validation des images comprend la vérification de la qualité des images capteurs qui doivent être mises à disposition dans la base, et qui est faite via des règles de validation dépendant des fournisseurs d’images. En particulier, les règles de validation dépendent de la qualité de chaque fournisseur d’images, la qualité couvrant la qualité des aéronefs et des membres d’équipage par exemple pour des procédures. Avantageusement, les règles de validation peuvent aussi prendre en compte la qualité d’acteurs spécialistes du traitement d’image qui peuvent valider également la qualité des prises de vue et leur utilité pour entraîner des algorithmes de traitement d’image.

[0023] Avantageusement, les images mises à disposition dans la base de données d’images capteurs peuvent être utilisées pour entraîner différents algorithmes d’intelligence artificielle pour classifier les images, notamment par des réseaux de neurones profonds ou « Deep Learning » en anglais.

[0024] Avantageusement, la base de données d’images capteurs telle que constituée selon les principes de l’invention peut être utilisée pour développer des algorithmes de traitement d’images entraînés robustes et produire une base de données d’algorithmes entraînés, l’entrainement desdits algorithmes étant variable selon les fournisseurs des images capteurs.

[0025] La base de données d’images capteurs peut être utilisée pour valider la robustesse ou la faiblesse de différents algorithmes vis-à-vis de scénarios (« use cases » en anglais) considérés comme problématiques, en permettant de faire tourner en parallèle les différents algorithmes sur le jeu de données déjà présent dans la base d’images et de détecter sur les résultats fournis des écarts trop importants entre les différents algorithmes.

[0026] La présente invention trouvera de nombreux domaines d’application et notamment des applications pour la détection :

- de piste, de contour de piste, de rampe lumineuse, de lampes d’approche ;

- d’obstacles aux abords du sol, de bâtiments au roulage, de véhicules ou de personnes ;

- d’oiseaux, de tout type de drones ; - de lignes électriques.

[0027] L’invention couvre aussi un produit programme d’ordinateur comprenant des instructions de code permettant d’effectuer les étapes du procédé revendiqué, lorsque le programme est exécuté sur un ordinateur.

[0028] L’invention couvre de plus un dispositif de gestion sécurisée d’une banque d’images pour l’aide à l’atterrissage d’aéronef, le dispositif comprenant des moyens pour mettre en oeuvre les étapes du procédé revendiqué.

[0029] D’autres caractéristiques, détails et avantages de l’invention ressortiront à la lecture de la description faite en référence aux dessins annexés donnés à titre d’exemple et qui représentent, respectivement :

[0030] [Fig.1] une architecture « producteur/valideur » d’un système de gestion sécurisée d’une banque d’images selon un mode de réalisation de l’invention ;

[0031] [Fig.2] les étapes d’un procédé de mise à disposition d’un bloc de données validé selon un mode de réalisation de l’invention ;

[0032] [Fig.3] une architecture pour le traitement d’images capteurs d’un système de gestion sécurisée d’une banque d’images selon un mode de réalisation de l’invention ;

[0033] [Fig.4] les étapes d’un procédé de mise à disposition d’algorithmes de traitement d’images entraînés selon un mode de réalisation de l’invention ;

[0034] [Fig.5] une architecture « consommateur » d’un système de gestion sécurisée d’une banque d’images selon un mode de réalisation de l’invention ;

[0035] [Fig.6] les étapes d’un procédé pour utiliser des algorithmes de traitement d’images entraînés selon un mode de réalisation de l’invention ;

[0036] [Fig.7] une architecture d’un système de gestion sécurisée d’une banque d’images selon un mode de réalisation de l’invention.

[0037] La figure 1 illustre une architecture 100 dite « producteur/valideur » d’un système de gestion sécurisée d’une banque d’images selon les principes de l’invention. Le système « producteur/valideur » 100 selon un mode de réalisation de l’invention comprend une communauté de fournisseurs d’images 102. Une communauté de fournisseurs d’images au sens de la présente invention s’entend comme un ensemble de dispositifs 102 où chaque dispositif est apte à capturer et fournir une/des images prises par un/des capteurs. Dans un mode de réalisation concernant l’aide à l’atterrissage d’aéronefs, les images d’un fournisseur d’images sont des images prises au cours d’un vol d’un aéronef équipé de capteurs. La communauté de fournisseurs d’images est alors une flotte d’aéronefs, un aéronef au sens de la présente invention prenant une définition générique couvrant tout engin volant, que ce soit un avion, un drone, un ballon, qu’il soit piloté ou non.

[0038] Le système 100 comprend un réseau de type registre distribué 104 ou DLT (« Distributed Ledger Technology » en anglais) qui est composé d’une pluralité d’entités de calcul (processeurs, ordinateurs) où un registre est simultanément enregistré et synchronisé sur les entités du réseau. Le réseau peut évoluer par l'addition de nouvelles informations préalablement validées par l'entièreté du réseau, et la mise à jour d'un registre distribué se répercute sur l'ensemble du réseau. Chaque dispositif ou entité du réseau possède en permanence la dernière version du registre.

[0039] Dans un mode de réalisation particulier, le réseau 104 est une chaîne de blocs (« blockchain » en anglais) où chaque bloc est lié au précédent par une clé de hachage. Une chaîne de blocs est une base de données distribuée et sécurisée par des techniques cryptographiques. Les transactions échangées sont groupées en « blocs » à intervalles de temps réguliers, de manière sécurisée par cryptographie, et forment une chaîne.

[0040] Dans une variante de réalisation, le système 100 comprend une base de données d’images 106 qui permet de stocker les images collectées et envoyées par les fournisseurs d’images.

[0041] Le système 100 comprend de plus un module 108 de validation de l’intégrité des données, couplé au réseau 104. Dans un mode de réalisation, le module de validation est aussi couplé à la base de données d’images 106.

[0042] Le module de validation 108 est configuré pour permettre une validation collaborative des données. De manière avantageuse, le module de validation met en oeuvre un algorithme de validation par consensus distribué. Les données validées sont mises à disposition dans le réseau DLT 104 ou selon une variante de réalisation dans la chaîne de blocs. [0043] Dans un mode de réalisation de l’invention avec chaîne de blocs, la validation par consensus distribué est interne à la chaîne de blocs et peut consister en une preuve de travail (« proof of work » en anglais). La chaîne de blocs peut être publique ou privée, ou selon des gouvernances intermédiaires, qui peuvent utiliser différentes barrières à l’entrée dont une validation par preuve de travail. Une chaîne de blocs « publique » fonctionne sans tiers de confiance (modèle dit « trustless » en anglais), généralement avec une validation par preuve de travail complexe (e.g. hashcash). Une chaîne de blocs publique ne définit généralement pas d'autre règle que celle du code constitué par la technologie protocolaire et logicielle qui la compose. Une chaîne de blocs « privée » comprend des noeuds participants au consensus qui sont définis à l'avance puis authentifiés. Ses règles de fonctionnement peuvent être éventuellement extrinsèques.

[0044] La figure 2 déroule les étapes d’un procédé 200 de mise à disposition de données validées dans un réseau DLT 104 selon un mode de réalisation de l’invention. Le procédé 200 correspond à une configuration dite « Producteur/Valideur » tel que celle illustrée sur la figure 1 , où un fournisseur d’images publie dans le réseau DLT des données relatives à des images capteurs qu’il a collectées. Dans un mode de réalisation, des données relatives aux images capteurs sont stockées dans la base de données d’images 106, et un lien est inscrit dans une chaîne de blocs contenant par exemple un SHA (« Secure Hash Algorithm » en anglais) de l’image.

[0045] Chaque image collectée est étiquetée, et les données sont envoyées 202 avec au moins des informations d’horodatage (e.g. date de création, validité) et d’identification du fournisseur d’images, et au moins un moyen de valider l’intégrité des données (e.g. l’association d’un nombre de hachage aux données). Les données peuvent aussi comprendre un résumé du contenu (e.g. paramètres, unités, quantité, format de l’image) ainsi que des données complémentaires, comme la météo perçue, l’état de systèmes de navigation au moment des prises de vue, la position 3D au moment du toucher sur la piste, etc. Avantageusement, le fournisseur peut inscrire la position 3D et l’orientation 3D par rapport à la terre de l’aéronef et/ou du capteur ayant pris la/les images. Cet ensemble forme un « bloc » à valider.

[0046] Dans un mode de réalisation, les images capteurs sont une séquence d’images produites à intervalle temporel fixe. Dans une alternative, les images capteurs sont une séquence d’images produites à une distance fixe par rapport à un élément de référence (e.g. un seuil de piste). Avantageusement, des algorithmes de compression d’images peuvent être appliqués, les données produites peuvent être masquées (par cryptage par exemple).

[0047] Dans un mode de réalisation, les données sont envoyées en temps réel par le fournisseur d’images par liaison de données numérique. Dans une alternative, les données sont envoyées une fois l’aéronef posé (e.g. via une liaison « Gatelink » quand l’aéronef est en liaison Wifi à sa porte). Dans une autre alternative, les données sont stockées à bord de l’aéronef et récupérées par téléchargement par un opérateur.

[0048] Le procédé 200 permet dans une étape suivante 204 de valider les données selon un processus collaboratif qui permet au réseau DLT de parvenir à un consensus. Dans un mode de réalisation, l’étape de validation consiste à mettre en oeuvre un algorithme de consensus qui implique au moins deux fournisseurs d’images de la communauté des fournisseurs d’images capteurs.

[0049] Dans un mode de réalisation, les données stockées dans la base de données d’images peuvent être encryptées après l’étape de vérification de leur intégrité et de l’authenticité du producteur.

[0050] Dans un mode de réalisation pour améliorer la robustesse du système à la triche, l’étape de validation permet de croiser les données de la base de données d’images (i.e. l’identification du fournisseur d’images) avec des données externes (par exemple avec l’information si le vol est bien prévu à cet horaire sur cet aéroport pour cet identifiant).

[0051] Dans un mode de réalisation de chaîne de blocs, l’étape de validation collaborative des images capteurs comprend une étape de rétribution du/des contributeur(s) à la validation (i.e. le/les nœud(s) de la chaîne de blocs). L’étape de rétribution peut consister à accorder un score synthétique VS (« Value Score » en anglais) à un nœud participant à la validation, le score permettant de gouverner les accès aux échanges (en tant que producteur/fournisseur d’images et/ou valideur et/ou consommateur).

[0052] Dans un mode de réalisation, ce score VS peut être fonction de i) la « valeur » des informations qu’il produit VS_PROD et ii) de la « valeur » des informations qu’il consomme VS_CONS. La valeur VS peut s’exprimer sous forme d’un score (chiffré), d’un symbole, de valeur dans une crypto-monnaie, d’une monnaie réelle (fiduciaire), etc. Si les images sont déclarées comme invalides, la chaîne de blocs est mise à jour avec une baisse du VS_PROD d’un certain montant pour le producteur, et une augmentation du VS_PROD pour celui qui a détecté l’anomalie. Si les images sont déclarées comme valides, la chaîne de blocs est mise à jour avec une augmentation du VS_PROD d’un certain montant pour le nœud valideur.

[0053] Revenant à l’étape 204 de validation, si les images sont considérées comme intègres et donc validées, le procédé permet de créer 206 un registre ou bloc de données validé, puis d’envoyer 208 le bloc validé dans le réseau DLT 104. Dans un mode de réalisation de chaîne de blocs, le bloc validé qui est créé contient un lien vers les données.

[0054] Dans un mode de réalisation de chaîne de blocs, l’étape de validation collaborative des images capteurs peut s’effectuer directement et automatiquement par un code logiciel appelé contrat intelligent (« Smart Contract » en anglais) stocké sur et exécuté par la chaîne de blocs. A chaque nouvelle entrée dans la base (et tentative d’écriture de bloc), un contrat peut vérifier :

- si le producteur est déclaré (s’il s’agit d’une chaîne de consortium) ;

- de faire rentrer le score VS du producteur dans l’évaluation de son intégrité ;

- de faire rentrer une « note » dans cette même évaluation ;

- effectuer des vérifications fonctionnelles sur les données : des données issues de l’aéronef concerné peuvent être corrélées/croisées avec d’autres sources d’information sur l’aéronef (sources publiques ou privées de la compagnie, du contrôle aérien ...) émises en temps réel et correspondant à l’état de l’aéronef (heure de décollage, statut (en vol, au sol, en croisière ...), position courante ...).

[0055] Tel que connu des technologies chaîne de blocs, un contrat intelligent est un code logiciel qui est stocké et exécuté sur/par une chaîne de blocs et est déclenché par des données externes, ce qui permet de modifier d'autres données, dans la chaîne de blocs ou ailleurs. Un contrat intelligent permet d’assurer l’égalité de traitement (en valeur) entre les parties prenantes au contrat. Les ressources de calcul étant distribuées, les données partagées sur la chaîne de bloc, l’exécution d’un contrat intelligent est sûre en elle-même : le code du contrat intelligent est répliqué en plusieurs nœuds de l’architecture mettant en œuvre la chaîne de blocs, et en étant déterministe, les résultats des différentes exécutions sont identiques. Le code ainsi que l’exécution du code sont alors sûres.

[0056] Comme pour tout programme ou code informatique, différents langages de programmation sont disponibles pour un contrat intelligent, avec différents modèles de sécurité et de régulation (contrat-cadre régissant d’autres contrats, contrats en cascade, etc). Les formes prises par les contrats intelligents peuvent être diverses (e.g services, agents, snippets, scripts, SOA, API, add-ons, plug-ins, extensions, DLC, etc). La logique mathématique (les prises de décisions opérant sur les données) peut être celle de la logique classique, floue, combinatoire, intuitionniste, modale, propositionnelle, partielle, para-consistante, etc ou une combinaison de ces logiques. Le logiciel peut être codé en partie ou en totalité sur forme matérielle (e.g. FPGA). Un contrat intelligent peut être en totalité ou en partie en source ouverte (« open source ») et/ou en source fermée (« closed source »). Dans le cas de source ouverte, le code est auditable ou vérifiable par les parties ou les tiers. Un contrat intelligent peut combiner des parties en source ouverte (e.g. auditables, vérifiables, améliorables, etc) avec des parties fermées (propriétaires, secrètes, sensibles, etc). Une source fermée peut être un binaire, éventuellement obfusqué ou durci (« hardened »). Les techniques cryptographiques peuvent être diverses : symétrique, asymétrique, « post-quantum », « quantum-safe », avec utilisation de « Quantum- Key-Distribution », etc). Un contrat intelligent peut être lisible par l’homme et/ou la machine (« human and/or machine readable »).

[0057] La figure 3 illustre une architecture 300 permettant le traitement d’images capteurs et la figure 4 montre les étapes d’un procédé 400 de mise à disposition d’algorithmes de traitement d’images entraînés dans un système de gestion sécurisée d’une banque d’images selon un mode de réalisation de l’invention. Le système 300 comprend un réseau de type registre distribué 104 auquel peuvent se connecter une pluralité d’entités 302 dites spécialistes du traitement d’images, configurées pour entraîner des réseaux de neurones, et produire des algorithmes de traitement d’images entraînés qui peuvent être stockés dans une base de données 304 d’algorithmes de traitement d’images entraînés. Avantageusement, le réseau DLT 104 contient selon le principe du procédé 200 décrit précédemment, des blocs de données validés. Le procédé 400 débute quand N (N>=1) entités 302 décident de requérir ou reçoivent directement 402 un ou plusieurs blocs de données validés.

[0058] A l’étape suivante 404, les N entités spécialistes du traitement d’images mettent en oeuvre des algorithmes d’apprentissage automatique sur les données correspondantes.

[0059] Différents types d'apprentissage automatique (ou machine) sont possibles. L'apprentissage automatique est un domaine de l'informatique qui utilise des techniques statistiques pour donner aux systèmes informatiques la possibilité "d'apprendre" avec des données (par exemple, pour améliorer progressivement les performances d'une tâche spécifique), et ce sans être explicitement programmé à cette fin.

[0060] Des réseaux de neurones (réalisation matérielle de l’apprentissage automatique, ou émulation logicielle) peuvent être utilisés pour traiter de nouvelles données. L’apprentissage automatique peut être effectué sur des données particulièrement volumineuses, c’est-à-dire en utilisant autant de données que possible (e.g. stabilité, convergence, signaux faibles, etc). De nouvelles données peuvent être ajoutées en permanence et l’apprentissage peut être affiné.

[0061] Différents algorithmes d’apprentissage peuvent être utilisés, en combinaison avec les caractéristiques selon l’invention. Le procédé peut comprendre un ou plusieurs algorithmes parmi les algorithmes comprenant: les "machines à vecteur de support" ou "séparateurs à vaste marge" (en anglais « Support Vector Machine », acronyme SVM) ; le « boosting » (classifieurs); les réseaux de neurones (en apprentissage non-supervisé) ; les arbres de décision ("Random Forest"), les méthodes statistiques comme le modèle de mixture gaussienne ; la régression logistique ; l'analyse discriminante linéaire ; et les algorithmes génétiques.

[0062] Matériellement, selon des modes de réalisation, le procédé selon l’invention peut être mis en oeuvre sur ou par un ou plusieurs réseaux de neurones. Un réseau de neurones selon l’invention peut être un ou plusieurs réseaux de neurones choisis parmi les réseaux de neurones comprenant : a) un réseau de neurones artificiels (en anglais « feedforward neural network »; b) un réseau de neurones artificiels acyclique, e.g. un perceptron multicouche, se distinguant ainsi des réseaux de neurones récurrents ; c) un réseau de neurones à propagation avant ; d) un réseau de neurones de Hopfield (un modèle de réseau de neurones récurrents à temps discret dont la matrice des connexions est symétrique et nulle sur la diagonale et où la dynamique est asynchrone, un seul neurone étant mis à jour à chaque unité de temps) ; e) un réseau de neurones récurrents (constitué d'unités interconnectées interagissant non-linéairement et pour lequel il existe au moins un cycle dans la structure) ; f) un réseau neuronal convolutif (en anglais « CNN » ou « ConvNet » pour « Convolutional Neural Networks », un type de réseau de neurones artificiels acycliques feedforward, par empilage multicouche de perceptrons) ou g) un réseau antagoniste génératif (en anglais « Generative Adversarial Networks » acronyme GAN, qui est une classe d'algorithme d'apprentissage non-supervisé).

[0063] Dans un mode de réalisation, un réseau GAN peut être utilisé pour entraîner et robustifier les algorithmes pour faire face à différents situations : panne ou attaque cyber sur les senseurs, sur le système avionique/calculateurs, etc. En effet, actuellement il est impossible de récupérer des données qui correspondraient à de telles situations. Les GAN permettent de facilement générer de large quantité de données, les GANs peuvent donc se révéler très utiles pour l’entrainement d’algorithmes d’apprentissage automatique.

[0064] Un GAN a pour but de générer des données qui sont très similaires à celles d’un jeu d’entrainement. Pour ce faire le générateur va générer des « fausses » images qui trompent le discriminateur en lui faisant croire qu’elles sont réelles. Le discriminateur doit quant à lui déterminer du mieux qu’il peut quelles images sont « réelles » et lesquelles sont « fausses ». Au fur et à mesure de l’entrainement les deux modules s’améliorent (le discriminateur et le générateur) jusqu’à ce que le discriminateur ne soit plus en mesure de distinguer les fausses images des vraies, et il produit alors des prédictions avec 50% de précision (équivalent à deviner de manière aléatoire la nature de l’image). La qualité des images produites par le générateur est alors très similaire à celles du jeu utilisé pour l’entrainement.

[0065] Quelques exemples d’amélioration de la robustesse des algorithmes en utilisant un GAN peuvent être :

- de créer des « fausses données de pistes » en utilisant un GAN avec un générateur ; - d’enrichir les données (« Data Enhancement »), les GANs permettant par exemple de facilement modifier la météo dans une image, on peut envisager que pour chaque image (ou autre type de donnée) ajoutée à la base de données d’images, un GAN soit mis en oeuvre pour générer automatiquement la même image avec une météo différente ;

- d’entrainer les algorithmes à détecter des situations impossibles en simulant ces situations et en générant les données correspondantes ;

- de créer des « Adversarials Inputs » pour étudier la réaction des algorithmes et minimiser l’impact d’une potentielle attaque/panne d’un senseur ou d’un composant de la chaîne fonctionnelle.

[0066] Revenant au procédé 400 de la figure 4, quand l’étape 404 d’entrainement des algorithmes de traitement d’images est terminée, le procédé permet 406 de générer des modèles d’algorithmes entraînés et de les stocker dans une base de données 304 d’algorithmes de traitement d’images entraînés pour utilisation par des uti I i sate u rs/co n so m m ate u rs .

[0067] Dans un mode de réalisation, les résultats sont des modèles d’intelligence artificielle de type « réseaux de neurones profonds » avec leurs paramètres (poids), leur fiabilité (précision, rappel).

[0068] Dans une alternative, le traitement d’image peut être standard et porter sur la détection de contour, de droite, de contraste.

[0069] Dans une autre alternative, l’algorithme de traitement d’images peut détecter un niveau d’intérêt sur de nouvelles images par rapport à un stock d’images existant, et effectuer des opérations de notation d’images en associant un tag à une image considérée comme inintéressante ou de faible valeur.

[0070] Le procédé 400 se termine par la mise à disposition 408 de modèles d’algorithmes de traitement d’images entraînés. Dans un mode de réalisation, les modèles des algorithmes entraînés sont mis à disposition dans un réseau de type registre distribué, qui avantageusement peut être le même réseau 104 que celui des fournisseurs d’images.

[0071] Dans un mode de réalisation, les modèles des algorithmes entraînés sont écrits dans une chaîne de blocs. Dans une alternative, les modèles sont écrits dans une base de données d’algorithmes de traitement d’images entraînés et un hash est écrit dans une chaîne de blocs.

[0072] La figure 5 illustre une architecture dite « consommateur » 500 permettant l’utilisation d’algorithmes de traitement d’images entraînés et la figure 6 montre les étapes d’un procédé 600 pour utiliser des modèles d’algorithmes de traitement d’images entraînés dans un système de gestion sécurisée d’une banque d’images selon un mode de réalisation de l’invention.

[0073] Le système 500 comprend une base de données 304 stockant des modèles d’algorithmes de traitement d’images entraînés couplée à un réseau de type registre distribué 504. Le procédé 600 d’utilisation d’algorithmes de traitement d’images entraînés débute quand une entité ‘consommateur’ 502 émet une requête d’utilisation 602 vers le réseau DLT 504. Afin de savoir si un bloc de données peut l’intéresser et donc faire une requête d’utilisation d’un modèle d’algorithme entraîné, des informations comme le format et le résumé du contenu d’un bloc du réseau (i.e. des données cryptées) peuvent être laissées en clair dans un espace de stockage.

[0074] Dans un mode de réalisation de chaîne de blocs, un consommateur peut s’abonner ou se déclarer intéressé pour récupérer un modèle d’algorithme entraîné de traitement d’images ou des paramètres optimisés en passant un ordre d’achat sur la chaîne de bloc 504 ou par un contrat intelligent. Le contrat vient lire les données en clair et se déclenche si le consommateur est abonné à cette donnée et si son solde (Value Score) est positif. Si c’est le cas, le contrat peut émettre une demande de récupération des données qui donne lieu en créant un nouveau bloc à l’envoi d’une clef de décryptage pour le bloc requis.

[0075] Si le jeu de données correspondant à la demande de l’acheteur est réputé valide, des clefs de décryptage stockées dans la chaîne de bloc sont récupérées par le contrat et transmises à l’acheteur. La transaction est écrite dans la chaîne de blocs par le contrat.

[0076] Avantageusement, un consommateur peut adresser une requête pour plusieurs modèles d’algorithmes de traitement d’images entraînés, afin d’améliorer la précision, l’intégrité et la disponibilité ou pour des questions de redondance (par mise en oeuvre d’une technique de dissimilarité par exemple). [0077] Après réception de la requête d’un consommateur, le procédé permet de vérifier 604 si ce dernier a la capacité requise pour télécharger le modèle entraîné ou les paramètres optimisés.

[0078] Dans un mode de réalisation avec chaîne de blocs où un consommateur participe à la validation de blocs pour les images capteur et obtient une rétribution de type VS, la vérification porte sur la valeur du VS du consommateur qui doit l’autoriser à récupérer le ou les modèles entraînés.

[0079] Dans une alternative, un ordre d’achat passé sur la chaîne de bloc peut être mis à disposition d’entités de validation qui effectuent la vérification du VS. Des mécanismes de rétribution et de validation peuvent être activés lorsque les vérifications sont considérées comme valides.

[0080] Si la requête ou la transaction est valide, l’algorithme requis ou le jeu de données optimisé pour un algorithme que l’utilisateur a déjà, est transmis 606 au consommateur. Avantageusement, ce dernier peut avoir la possibilité de vérifier son intégrité (par le hash récupéré dans la chaîne de blocs).

[0081] Dans une variante de réalisation, le consommateur peut noter l’attractivité du bloc reçu (vis-à-vis de son propre intérêt). Des mécanismes de notation peuvent aussi être activés pour rétribuer les émetteurs de données les plus utiles.

[0082] Dans une autre variante, une note peut être calculée pour un bloc, par comptage du nombre de téléchargements des images et/ou par le nombre de consommateurs intéressés.

[0083] Dans une autre variante, une note peut être fixée pour répondre à des besoins réglementaires, comme par exemple, la validation d’une procédure de navigation nouvelle sur un grand aéroport fréquenté peut avoir une note élevée pour les images fournies.

[0084] Dans une autre variante, une note peut être fixée pour répondre à des besoins internationaux de couverture mondiale, ce qui peut être le cas pour des aéroports peu desservis.

[0085] La figure 7 illustre l’architecture d’un système 700 de gestion sécurisée d’une banque d’images pour l’aide à l’atterrissage d’aéronefs selon un mode préférentiel de réalisation de l’invention avec des chaînes de blocs. [0086] L’architecture générale du système est une architecture de type Fournisseur/Consommateur qui met en œuvre les procédés décrits aux figures 2, 4 et 6.

[0087] Une communauté de fournisseurs d’images capteurs 702 fournit de nouvelles données construites sur des images capteurs prises par des senseurs pendant des vols, en particulier pendant des phases d’atterrissage, et stockées dans une base de données 706. Les données sont validées par un mécanisme de validation par consensus 708.

[0088] Un contrat intelligent de mise à disposition détecte les nouvelles données validées et stocke des méta-données dans une chaîne de blocs 704 (i.e. une identification, une date, un émetteur, un score, un hash du contenu des données).

[0089] Les données sont utilisées par une communauté 710 de spécialistes du traitement d’images pour entraîner des algorithmes de traitement d’images capteurs et générer des algorithmes entraînés, stockés dans une base de données 712 d’algorithmes de traitement d’images capteur entraînés.

[0090] Lors de l’achat de données, un ordre d’achat est passé par un consommateur 714 sur une chaîne de blocs 716, et un contrat intelligent de consommation de données se déclenche. Le contrat vérifie le score de valeur de l’acheteur/consommateur potentiel, vérifie en option la réalité de la donnée mise à disposition, la télécharge et l’envoie à l’acheteur. Le contrat de consommation envoie également les informations du bloc correspondant de la chaîne de bloc, et le hash du contenu des données (ce qui permet à l’acheteur de vérifier l’intégrité des données).

[0091] Dans un mode de réalisation, le contrat de consommation indique à l’acheteur la position des données dans la base de données partagée et les clefs de décryptage de la donnée. Dans un mode alternatif, le contrat réencrypte la donnée dans la base de données pour que chaque consommateur paie et pour éviter les partages de clefs.

[0092] Dans un mode de réalisation sans contrat intelligent, un fournisseur peut recevoir un ordre d’achat et émettre la donnée requise directement vers l’acheteur. Il écrit la transaction (avec la date et le hash) dans la chaîne de blocs. A réception, l’acheteur vérifie le bloc (avec le hash) et valide le bloc ou le rejette. Chaque membre du réseau se voit attribuer un score de valeur (VS) pour lui permettre de participer aux échanges (en tant que producteur et/ou consommateur de données). Les scores sont mis à jour en fonction du résultat. Un score VS est fonction :

- de la valeur des informations qu’il produit VS_PROD ; et

- de la valeur des informations qu’il consomme VS_CONS.

[0092] La valeur VS peut s’exprimer sous forme d’un score, d’une cryptomonnaie, d’une monnaie réelle. Avantageusement la valeur VS peut être modifiée par conversion en valeur monétisée, lorsque que :

- un acteur achète un montant VS_MONEY de droit de consommer pour pouvoir ultérieurement consommer des données (ce qui peut être utile s’il en consomme plus qu’il n’en produit) ;

- un acteur transforme sa VS en monnaie réelle ou cryptomonnaie pour d’autres usages, ce qui diminue sa VS de la valeur transformée VS_MONEY.

[0093] Le score VS est amené à évoluer en fonction de l’attractivité des données qu’il produit (nombre d’abonnés par exemple ou nombre de téléchargements ou quantité de téléchargements), de la valeur des données qu’il consomme, et des achats/ventes dans l’alternative VS_MONEY.

[0094] Les valeurs VS_PROD et VS_CONS peuvent être calculées par l’une ou combinaison des méthodes suivantes :

- valeur en quantité (au Megabyte par ex) ;

- valeur en qualité (fonction de la qualité de l’image, de la rareté, de l’angle de vue) ;

- consensus sur un prix (proposition par un consommateur, validation par le producteur ou proposition par un producteur vs. acceptation/refus par un consommateur, ou négociation) ;

- historique d’utilisation ;

- cours du jour fonction de différents paramètres ;

- fixation a priori de bornes min/max ;

- consensus a priori sur les valeurs des différentes données entre acteurs ;

- valeur liée à la qualité de l’algorithme de traitement d’images ; - valeur liée à l’importance de l’image pour paramétrer l’algorithme de traitement d’images.

[0095] Ces valeurs ou modalités de calcul de ces valeurs sont inscrites dans un contrat intelligent. Le contrat peut-être bi-partite (accord entre deux acteurs) ou multi- partite (accord entre 1 à N fournisseurs et 1à M consommateurs).

[0096] La chaîne de blocs contient en temps réel le score de VS pour chaque acteur du réseau : lorsque le score d’un acteur est mis à jour, la chaîne de blocs est mise à jour aussi. Avantageusement, l’utilisation de la chaîne de blocs permet d’avoir cette information distribuée sur plusieurs noeuds et donc de la rendre immuable et sécurisé ainsi que de posséder un historique certain.

[0097] Lorsqu’un consommateur récupère un jeu de données dans la chaîne de blocs, après vérification de l’intégrité (hash recalculé), la VS du fournisseur est mise à jour (ajout d’une somme si le bloc est validé, retrait d’une somme si le jeu de données était corrompu) et sa propre VS (d’une valeur inverse à celle de l’émetteur) est mise à jour. Cette transaction est écrite dans la chaîne de blocs.

[0098] Chaque fournisseur peut tour à tour publier de l’information à destination des autres membres du réseau ou bien « s’abonner au réseau » via un contrat intelligent par exemple, et recevoir les informations le concernant de manière automatique.

[0099] Le système peut être hébergé dans un « cloud » ou sur des serveurs (noeuds de la chaîne de blocs) et est accessible sur multiplateformes (EFB, WebbApp On the ground, etc).

[0100] La présente description illustre une implémentation préférentielle de l’invention, mais qui n’est pas limitative. Des exemples sont choisis pour permettre une bonne compréhension des principes de l’invention et une application concrète, mais ne sont en rien exhaustifs et doivent permettre à l’homme du métier d’apporter des modifications et des variantes d’implémentation en conservant les mêmes principes.

[0101] L’invention peut s’implémenter à partir d’éléments matériels et/ou logiciels. Elle peut être disponible en tant que produit programme d’ordinateur sur un support lisible par ordinateur et comprend des instructions de code pour exécuter les étapes des procédés dans leurs différents modes de réalisation.