Titre de l’invention : GESTION DE PLANS DE VOL PAR REGISTRES DISTRIBUES [0001] L’invention concerne le domaine de la gestion du vol d’un aéronef en général, et de la gestion de plans de vols en particulier.

[0002] Etat de la Technique

[0003] Aujourd’hui, lorsqu’un aéronef veut effectuer un vol, dans des conditions où il a obligation de faire connaître son vol à une autorité de contrôle, il doit déposer un plan de vol.

[0004] Dans un futur proche, le nombre d’appareils en vol va croître de manière exponentielle, en raison de l’arrivée de drones qui vont non seulement augmenter la quantité de vols effectués mais aussi introduire une très grande disparité des plans de vol (missions très diverses e.g. surveillance longue durée, suivi d’un réseau, livraison de colis, loisirs, etc). La gestion du trafic actuel ne permet pas d’envisager de gérer ces nouveaux appareils. Il existe un besoin impératif quant à la gestion de tels vols, permettant de garantir la sécurité des vols telle qu’elle est connue et garantie aujourd’hui.

[0005] Le dépôt d’un plan de vol est à accomplir dès lors que les conditions du vol l’imposent. Le dépôt d’un plan de vol est obligatoire dans les cas suivants : vol en régime de vol aux instruments IFR ; vol de nuit hors vol local ; survols maritimes au- delà de la distance la plus faible des deux distances suivantes : a) distance permettant, en cas de panne d’un moteur, d’atteindre une terre se prêtant à un atterrissage d’urgence et b) distance égale à 15 fois l’altitude de l’aéronef ; vol devant évoluer dans des régions, sur des routes ou pendant des périodes désignées par arrêté du ministre chargé de l’aviation civile pour faciliter la fourniture du service d’alerte ou les opérations de recherche et de sauvetage (zones inhospitalières) ; vol devant évoluer dans des régions ou sur des routes désignées par arrêté du ministre chargé de l’aviation civile pour faciliter la coordination avec les organismes militaires ou les organismes de la circulation aérienne d’états voisins et éviter la nécessité éventuelle d’une interception aux fins d’identification, et vol devant franchir des frontières nationales.

[0006] Le but d'un plan de vol déposé est de fournir aux services du contrôle aérien des informations précises concernant un vol ou une portion de vol planifié par un appareil. L’autorité du contrôle aérien souhaite connaître ce qu’il est prévu de faire et ce qui peut attendre du pilote. En conséquence, un plan de vol déposé comportera toutes les informations pertinentes relatives au vol prévu.

[0007] Un plan de vol déposé comprend notamment :

• L'immatriculation de l'aéronef (e.g. l'indicatif d'appel)

• Les règles et le type de vol (e.g. IFR, VFR, aviation générale, transport, etc)

• Le nombre, le type d'aéronef et la catégorie de turbulence de sillage

• L'équipement embarqué (radiocommunication et radionavigation)

• L'aérodrome de départ

• L'heure estimée de départ du poste de stationnement

• La vitesse de croisière,

• Le niveau ou l'altitude de croisière,

• La route suivie

• L'aérodrome de destination et la durée totale estimée

• L'aérodrome de dégagement,

• L'autonomie

• Le nombre total des personnes présentes à bord

• L'équipement de survie

• des renseignements divers, dont l’identité du pilote.

[0008] Un nouveau type d’aéronef commence à émerger : les drones sont des aéronefs inhabités (au sens « sans pilote à bord » ; ils peuvent néanmoins transporter des passagers). Ces appareils soulèvent de nombreux problèmes techniques. Une très grande quantité d’appareils est anticipée : de l’ordre de 20000 appareils dans le ciel européen à l’horizon 2030. Ensuite, ces appareils ne vont pas décoller d’un aéroport pour aller à un autre aéroport comme le font tous les avions. Ceci en particulier les rend incompatibles avec les procédés de gestion des plans de vol actuels. La sécurisation du trafic aérien devient un véritable enjeu technique. La diversité des missions qui associées à cette quantité des drones conduit en théorie à trafic aérien ingérable avec les systèmes de contrôle aérien actuels. Enfin, un problème technique supplémentaire réside dans la diversité des donneurs d’ordre (ou clients) à l’origine de la mission, plus nombreux et moins identifiables que des compagnies aériennes ou des aéroclubs (e.g. personnes civiles, pseudo compagnies).

[0009] Utiliser les procédures actuelles faisant appel à des organismes officiels pour valider le plan de vol et le communiquer aux autorités de contrôle aérien ne pourra plus garantir la sécurité aérienne qui est attendue. La dimension de ce trafic aérien global avec l’arrivée des drones sera telle qu’elle va rendre difficile voire impossible la supervision humaine.

[0010] Il existe un besoin pour des systèmes et procédés avancés de gestion du trafic aérien comprenant notamment des drones.

[0011 ] Résumé de l’invention

[0012] Le document concerne des systèmes et des procédés pour la gestion du trafic aérien, comprenant notamment des drones télé pilotés ou autonomes. Au-delà d’une autorégulation de pair-à-pair utilisant une chaîne de blocs et des contrats intelligents, le document décrit différents modes de réalisation où l’intervention du régulateur est variable et s’exerce au travers de l’exécution de programmes et/ou de contrats intelligents, l’utilisation de systèmes de gestion de vol pour vérifier qu’un plan de vol est volable ainsi que différents mécanismes d’incitations pour la validation par consensus distribué de plans de vol et l’émission d’attestations, notamment des bons pour vol.

[0013] Le document décrit des systèmes et des procédés mis en oeuvre par ordinateur pour la régulation du trafic aérien comprenant des aéronefs habités et des drones, comprenant les étapes consistant à : écrire dans un registre distribué ou une chaîne de blocs le plan de vol d’un drone ou d’un aéronef habité, ledit plan de vol détaillant des paramètres comprenant au moins un quadruplet formé de l’opérateur du vol, de la trajectoire prévue, de l’identification du drone ou de l’aéronef et du pilote ou du télé pilote ; exécuter un ou plusieurs programmes d’ordinateur ou contrats intelligents pour vérifier séparément par étapes successives la conformité de l’opérateur, la conformité de la trajectoire, la conformité de l’identification de l’appareil, la conformité de l’identification du pilote ou télé pilote ; chaque conformité étant déterminée par comparaison du paramètre avec des bases de données préalablement constituées ; déterminer si la trajectoire prévue peut être volée dans le trafic aérien et si oui vérifier la conformité desdits paramètres du quadruplet considérés en combinaison, étant donné le trafic prévu.

[0014] Avantageusement, les modes de réalisation de l’invention permettent de réduire les erreurs humaines quant à la gestion des plans de vol.

[0015] Avantageusement, les modes de réalisation de l’invention permettent d’améliorer la sécurité et par suite la sûreté aéronautique. La capacité de l’aéronef à voler le plan de vol déclaré peut être contrôlée (ce qui n’est pas le cas aujourd’hui). L’aptitude du pilote à diriger l’aéronef peut également être contrôlée. Enfin, un contrôle global du plan de vol avec son avion et son pilote peuvent être vérifiés, notamment de manière automatique par rapport au trafic aérien global.

[0016] Avantageusement selon l’invention il devient possible de gérer un nombre très élevé d’aéronefs, comprenant notamment des drones, dans la circulation aérienne générale.

[0017] Avantageusement les modes de réalisation permettent dès à présent une sécurisation du trafic aérien existant, avant même l’arrivée des drones. En effet les modes de réalisation de l’invention permettent par exemple d’améliorer les contrôles de compatibilité entre plan de vol, avion et pilote.

[0018] Avantageusement, certains modes de réalisation peuvent être applicables pour les avions actuels et/ou les drones futurs.

[0019] Avantageusement, les modes de réalisation de l’invention sont également applicables aux véhicules autonomes terrestres, ou ferroviaires. Par exemple, des flottes de véhicules autonomes peuvent être gérées par l’entremise d’une ou de plusieurs chaînes de blocs (équivalent des plans de roulage). En effet, les mécanismes de l’invention sont transposables aux véhicules terrestres. Par exemples, le certificat « bon pour vol » du mobile aérien serait transposable en « certificat de conformité » du véhicule terrestre délivré par les autorités compétentes (carte grise par exemple); le certificat de pilotage serait transposable en « permis de conduire » valide ; et l’autorisation d’opérer serait transposable en reconnaissance d’un transporteur via les registres de commerce (immatriculation, droit d’opérer).

[0020] Avantageusement, l’utilisation d’une ou de plusieurs chaînes de blocs résout le problème technique du nombre élevé d’aéronefs à gérer, et de leur typicité de mission, non adaptés aux systèmes classiques de déclaration/validation de plan de vol par un tiers centralisé. Une chaîne de blocs présente l’avantage de générer une « confiance » dans le dépôt et l’exécution du vol par un mécanisme de validation par consensus distribué. Ce consensus distribué peut tout à fait être léger, rapide et pouvant être réalisé plus localement, notamment pour des porteurs qui effectuent de courtes missions dans des périmètres géographiques restreints (e.g. drones urbains ou agricoles par exemples).

[0021] Avantageusement, certains modes de réalisation de l’invention permettent d’établir une « confiance » dans le dépôt et l’exécution d’un vol d’un aéronef, en utilisant un mécanisme de validation par consensus distribué, léger, rapide et pouvant être réalisé « localement » (par exemple via des chaînes de blocs secondaires géographiques).

[0022] Avantageusement, certains modes de réalisation de l’invention permettent la mise en oeuvre d’un ou de plusieurs mécanismes de rétribution des «valideurs» ou «validateurs» peuvent inciter les différents acteurs de cet écosystème à participer à la validation des plans de vol de tiers.

[0023] Avantageusement, l’utilisation de chaînes de blocs permet un horodatage fiable permettent ainsi de remonter l’histoire lors de l’étude d’un cas anormal (panne, accident, incident ...).

[0024] Description des figures

[0025] D’autres caractéristiques et avantages de l’invention apparaîtront à l’aide de la description qui suit et des figures des dessins annexés dans lesquels:

[0026] [Fig. 1] illustre le fonctionnement d’une chaîne de blocs;

[0027] [FIG 2] illustre la gestion d’un plan de vol selon l’état de la technique ;

[0028] [Fig. 3] illustre un mode de réalisation de l’invention ;

[0029] [FIG. 4] illustre un aspect d’un mode de réalisation de l’invention ;

[0030] [FIG. 5] illustre un autre aspect d’un mode de réalisation de l’invention ;

[0031] [FIG. 6] illustre un mode de réalisation spécifique de l’invention.

[0032] Description détaillée de l’invention

[0033] Des définitions sont proposées ci-après. [0034] Un drone ou UAV (acronyme de « Unmanned Aerial Vehicle » en anglais) est un aéronef sans pilote humain à bord. Un drone peut être autonome et/ou piloté à distance. Les drones actuellement commercialisés varient considérablement en matière de performance, taille, autonomie, coûts de fonctionnement et prix d’acquisition. Certains drones sont des jouets à bas prix, d’autres sont des modèles professionnels à plusieurs milliers d’euros. Du point de vue technologique, les n- coptères comme les quadricoptères sont les modèles les plus répandus dans le commerce. Certains drones mesurent quelques centimètres (par exemple les drones d’inspiration biomimétique) tandis que d’autres atteignent plusieurs mètres d’envergure (e.g. drones de surveillance, Drones Taxi). Certaines gammes de drone permettent le transport de charges utiles. La plupart des drones commercialisés actuellement comportent des procédés et des dispositifs de stabilisation de vol.

Quant aux plans de vol des drones, s’ils peuvent être parfois intégralement prédéfinis, ils sont généralement au moins partiellement téléguidés par un opérateur humain. L’instrumentation embarquée des drones a significativement progressé ces dernières années. Par exemple, de meilleures batteries permettent désormais d’accroître significativement l’autonomie de vol, les processeurs embarqués sont plus performants, permettent des boucles de rétroaction plus rapides et les capteurs d’acquisition d’images gagnent en sensibilité améliorant les prises de vue et/ou la navigation. Par ailleurs, des capacités entièrement nouvelles sont devenues réalisables, notamment en vertu des progrès réalisés dans le domaine des MEMS, acronyme de « Micro Electro Mechanical Systems » en anglais, lesquels permettent l’amélioration des gyroscopes, accéléromètres et des autofocus laser. Les drones contemporains peuvent également utiliser les nouvelles caméras fournissant des informations de profondeur (" Depth-Field Caméras " ou « Time-Of-Flight ». De fait, les drones ont investi de très nombreux champs d’activité (surveillance, télécommunications, logistique, art, jeu, etc). Les drones peuvent comprendre des mécanismes de gestion du vol ou arcs-reflexes pour les évitements à très courte distance (e.g. oiseaux, etc), mais sans influence sur le plan de vol. Les drones considérés par l’invention peuvent comprendre des calculateurs embarqués et/ou accessibles à distance.

[0035] Selon la définition donnée par Wikipédia, une « chaîne de blocs » («blockchain» en anglais) ou un « registre distribué » (DLT pour « Distributed Ledger Technology » en anglais) 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, lesquels blocs forment une chaîne. Après avoir enregistré les transactions récentes, un nouveau bloc est généré et analysé. Si le bloc est valide (consensus distribué), le bloc peut être horodaté et ajouté à la chaîne de blocs. Chaque bloc est lié au précédent par une clé de hachage. Une fois ajouté à la chaîne de blocs, un bloc ne peut plus être ni modifié ni supprimé, ce qui garantit l'authenticité et la sécurité du réseau. Le chaînage utilise des fonctions de hachage et des arbres de Merkle. Un arbre de hachage est constitué par un ensemble de sommes de contrôle interdépendantes. Des sommes de contrôles sont concaténées selon une structure en arbre. Un arbre de hachage permet de pouvoir vérifier l'intégrité d'un ensemble de données sans disposer nécessairement de la totalité des données au moment de la vérification. Les enregistrements dans une chaîne de blocs sont protégés contre la falsification ou la modification par les nœuds de stockage : falsifier un bloc nécessite de falsifier l'ensemble de la chaîne, de sorte que le coût total devient prohibitif et garantit un niveau de confiance en la non-falsification de l'ensemble de la chaîne de blocs. Les transactions sont visibles dans l'ensemble du réseau (sauf élagage dit « pruning »).

[0036] Le temps est un facteur important pour les chaînes de blocs (notions de broadcasting, de propagation, de latence, etc.). Le consensus distribué de l'ensemble des nœuds du réseau peut prendre un temps très variable selon les technologies utilisées. Il peut être accéléré en utilisant diverses techniques, notamment des « sidechains », lesquelles augmentent aussi les capacités de stockage.

[0037] Dans le cadre du consensus distribué, une chaîne de blocs peut utiliser une validation par preuve de travail (« proof of work »). Du point de vue mathématique, une preuve de travail est « difficile à fournir mais facile à valider». Les systèmes de validation par preuve sont généralement asymétriques: le calcul qui est requis en contrepartie d'une demande de service est coûteux pour le demandeur mais demeure facilement vérifiable par un tiers. Différentes techniques peuvent être utilisées, notamment hashcash ou un "client-puzzle". [0038] Les nœuds « mineurs » ou de « minage » sont des entités dont le rôle est d’alimenter le réseau en puissance de calcul, pour permettre la mise à jour de la base de données décentralisée. Ces mineurs peuvent être rétribués par la distribution de jetons cryptographiques (« tokens »). D’autres modes de compensation (en complément ou par substitution) prévoient des commissions sur les transactions. Des « mineurs » ne sont pas toujours nécessaires : dans le cas des chaînes de blocs privées par exemple, les participants à la chaîne de blocs maintiennent eux-mêmes la base de données distribuée.

[0039] Une 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 (validation par preuve de travail). Une chaîne de blocs « publique » fonctionne sans tiers de confiance (modèle dit « trustless »), 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 nœuds participants au consensus qui sont définis à l'avance puis authentifiés. Ses règles de fonctionnement peuvent être éventuellement extrinsèques.

[0040] Les chaînes de blocs peuvent être ou devenir programmables par l’emploi de « contrats intelligents » (« smart contracts » en anglais). Les contrats intelligents sont des logiciels ou protocoles informatiques qui facilitent, vérifient et exécutent la négociation ou l'exécution d'un contrat. Ils visent à émuler ou approcher la logique des clauses contractuelles (droit des contrats). Les contrats intelligents ne sont pas strictement équivalents à des accords contractuels. Ils contribuent à rendre la violation d'un accord coûteux car ils contrôlent un bien par le biais de moyens numériques. Ils peuvent prévoir - ou pas - l’intervention de tiers au contrat pour suivre son exécution (par exemple des machines ou « oracles » ou services d’oracle. Un contrat intelligent est un code logiciel qui est stocké et est exécuté sur/par une chaîne de blocs et est déclenché par des données externes qui lui permet de modifier d'autres données, dans la chaîne de blocs ou ailleurs.

[0041] L’exécution d’un contrat intelligent est prédictible/prévisible; à tout le moins le code et donc la nature des calculs ou tests effectués par ce code sont connus. Le code d’un contrat intelligent est stocké sur ou dans la chaîne de blocs ; l’exécution du contrat intelligent est effectué lors de la validation des blocs (les ressources de calcul sont distribuées, ce qui signifie que 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 ; étant déterministe, les résultats des différentes exécutions doivent être identiques. Par suite, le code ainsi que l’exécution du code sont sûres.

[0042] Comme pour tout programme ou code informatique, différents langages de programmation sont disponibles, 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 »).

[0043] Il est divulgué un procédé mis en œuvre par ordinateur pour la régulation du trafic aérien comprenant des aéronefs habités et des drones, comprenant les étapes consistant à : - écrire dans un registre distribué ou une chaîne de blocs le plan de vol d’un drone ou d’un aéronef habité, ledit plan de vol détaillant des paramètres comprenant au moins l’opérateur du vol, la trajectoire prévue, l’identification du drone ou de l’aéronef et l’identification du pilote ou du télé pilote ; - exécuter un ou plusieurs programmes d’ordinateur pour : - vérifier séparément la conformité de l’opérateur du vol, de la trajectoire prévue, de l’identification du drone ou de l’aéronef, de l’identification du pilote ou du télé pilote ; ladite conformité étant déterminée par comparaison avec des bases de données préalablement constituées ; - déterminer si la trajectoire prévue peut être volée dans le trafic aérien et vérifier la conformité desdits paramètres considérés en combinaison.

Dans un développement, la chaîne de blocs est privée ou est publique.

[0044] Dans un mode de réalisation, la chaîne de blocs est privée (tous les appareils sont préalablement connus, et un nouvel appareil doit s’enregistrer par exemple auprès d’une autorité de régulation du trafic aérien). Dans un mode de réalisation, la chaîne de blocs est publique et de nouveaux appareils peuvent s’enregistrer modulo une épreuve d’admission.

[0045] Dans un développement, lesdits un ou plusieurs programmes d’ordinateur est sous le contrôle d’une autorité de régulation du trafic aérien.

[0046] Dans un développement, la régulation du trafic aérien s’effectue de manière entièrement distribuée, par échanges de pair-à-pair, un pair étant un aéronef inhabité ou un drone.

[0047] Dans un développement, lesdits un ou plusieurs programmes d’ordinateur comprennent un ou plusieurs contrats intelligents, un contrat intelligent comprenant des instructions de code stockées et exécutées sur/par ladite chaîne de blocs.

[0048] Dans un développement, l’étape consistant à déterminer la conformité du plan de vol comprend l’étape consistant à vérifier le plan de vol dans un système de gestion de vol FMS, ou calculateur aéronautique, d’un nombre N d’aéronefs, N étant configurable.

[0049] Dans un développement, l’accès et/ou la communication et/ou la validation des données de la chaîne de blocs est effectuée en fonction d’un score de rétribution VS prédéfini et/ou déterminé par lesdits un ou plusieurs contrats intelligents, ledit score de rétribution VS étant associé à un drone ou aéronef habité.

[0050] Dans un développement, un score VS d’un drone ou d’un aéronef dépend de plusieurs paramètres sélectionnés parmi une valeur associée aux informations produites VS_PROD et d’une valeur associée aux informations consommées, une valeur étant déterminée par consensus distribué.

[0051] Dans un développement, le score de rétribution évolue au cours du temps et étant inscrit dans la chaîne de blocs. [0052] Dans un développement, un contrat intelligent est multipartite à N parties, les parties comprenant un ou plusieurs parmi un opérateur, une compagnie aérienne et une autorité de la régulation aérienne.

[0053] Dans un développement, le procédé comprend en outre une étape consistant à délivrer une attestation ou bon pour vol en réponse à l’inscription d’un plan de vol d’un drone ou d’un aéronef habité dans la chaîne de blocs et la validation du bloc comprenant ladite inscription.

[0054] Dans un développement, les données de la chaîne de blocs sont au moins partiellement chiffrées et au moins un contrat intelligent détermine l’accès aux données, notamment par la gestion de clefs de chiffrement.

[0055] Dans un mode de réalisation, le code source du mécanisme de contrôle des échanges et/ou d’un ou de plusieurs des contrats intelligents est accessible aux parties participantes à la chaîne de blocs.

[0056] Dans un mode de réalisation, le mécanisme de contrôle des échanges comprend la détermination d’un score associé avec chacune des parties prédéfinies.

[0057] Dans un développement, le procédé comprend en outre une ou plusieurs étapes d’apprentissage automatique conduites sur les données accessibles par l’intermédiaire de la chaîne de blocs et/ou de un ou plusieurs contrats intelligents.

[0058] Dans un développement, l’apprentissage automatique est non-supervisé, ou est appliqué de manière réflexive sur des techniques différentes d’apprentissage automatique en coopération et/ou mises en concurrence.

[0059] Il est divulgué un produit programme d’ordinateur, ledit programme d’ordinateur comprenant des instructions de code permettant d’effectuer une ou plusieurs étapes du procédé, lorsque ledit programme est exécuté sur un ordinateur.

[0060] Il est décrit un système pour la gestion du trafic aérien comprenant : - des drones sans pilote humain à bord et des aéronefs habités au moins une chaîne de blocs, ladite chaîne de blocs étant configurée pour l’exécution d’un ou de plusieurs contrats intelligents; - lesdits un ou plusieurs contrats intelligents étant configurés pour exécuter un ou plusieurs mécanismes parmi un mécanisme de dépôt, de validation et/ou de vérification de conformité d’un plan de vol d’un drone sans pilote humain à bord et/ou d’un aéronef habité, un plan de vol détaillant des paramètres comprenant au moins l’opérateur du vol, la trajectoire prévue, l’identification du drone ou de l’aéronef et l’identification du pilote de l’aéronef ou du télé pilote du drone; - des calculateurs aéronautiques, par exemple un système de gestion de vol ou FMS, associés directement à la chaîne de blocs en lecture et/ou écriture, et/ ou indirectement à la chaîne de blocs par l’intermédiaire desdits un ou de plusieurs contrats intelligents.

[0061 ] La [FIG. 1 ] illustre le fonctionnement d’une chaîne de blocs.

[0062] La figure montre 4 blocs de données B1 à B4 (101, 102, 103, 104). L'arbre de hachage est constitué par un ensemble de valeurs de hash interdépendantes. Les feuilles de l'arbre sont les valeurs de hash de chacun des blocs de données initiales (111, 112, 113, 114). Dans un arbre de Merkle (binaire), ces valeurs de hachage sont alors concaténés deux à deux pour pouvoir calculer un nouveau hash parent (121 , 122). Ainsi de suite jusqu'au sommet de l'arbre ou on obtient un hash-sommet (131). Pour garantir l'intégrité d'un bloc par rapport à l'ensemble des données, il suffit de posséder les valeurs de hash des frères, les valeurs de hash des oncles et le hash-sommet. De plus, seul le hash-sommet (131) doit être récupéré de manière sure pour garantir l'intégrité de l'ensemble des données représentées par l'arbre. Par exemple, si on veut vérifier l'intégrité du block B2, il suffit d'avoir récupéré le hash 0-0 (son frère 111), le hashl (son oncle 122) et le hash-sommet (131).

[0063] Un bloc de données peut comprendre un ou plusieurs codes ou programmes ou contrats intelligents 140. Concrètement, un contrat intelligent 140 peut mettre un œuvre un ou plusieurs mécanismes : (a) d’accès aux données ou parties de données (portant notamment sur les plans de vol): -i) gestion des droits d’accès et partages des clefs de chiffrement (dans le cas d’un chiffrement asymétrique la clef privée est secrète et connue du seul utilisateur ou la clef publique peut être connue d’un registre) ; des mécanismes de chiffrement matériel peuvent être utilisés (TPM ou HSM, carte à puce, etc) ; ii) abonnement par unité de temps (journalier, hebdomadaire, mensuel, annuel, etc) et/ou par volume de données (e.g. au Mo octets de données téléchargées) ; des systèmes de crédits ou de points peuvent être utilisés ; b) de paiement ; les transactions peuvent être réglées en unité de compte (crypto-monnaie ou monnaie fiduciaire e.g. USD ou EUR) ; [0064] Les blocs de données (101, 102, 103, 104) sont produits puis consommés, i.e. accédés, en lecture et/ou écriture, par des parties ou entreprises (e.g. illustrées par 151, 152, 153).

[0065] Une partie ou entreprise ou consommateur peut être le constructeur de l’avion, un assembleur, un équipementier, un client ou une compagnie aérienne, une société fournisseur de données météorologiques, une autorité de régulation, etc.

[0066] Une partie peut être « producteur » de données et/ou « consommateur » de données. Un consommateur de données peut être dénommé « client » ou « demandeur » ou « receveur » par la suite. Un producteur peut être dénommé « émetteur » ou « serveur » ou « fournisseur » par la suite. L’expression « et/ou » souligne le fait que la production et la consommation peuvent être successives ou alternatives, ou même simultanées. Comme chaque partie peut acheter et/ou vendre, prendre licence et/ou concéder licence, céder ou donner ou partager des données qui lui sont propres, elle peut aussi accéder aux données partagées par les autres parties. La mise en partage des données permet de créer d’autres données, dont certaines peuvent avoir de la valeur technique ou autre.

[0067] Comme autre exemple de producteur/consommateur de données, les autorités de contrôle du trafic aérien 152 peuvent produire et consommer des données.

[0068] Les données peuvent notamment concerner des plans de vol et/ou leurs attestations associées, des notifications NOTAM, des alertes diverses, des statistiques de routage ou sur les plans de vol etc.

[0069] Enfin, une grande diversité de parties 153 peuvent consommer ou produire des données utiles : météorologiques, des services d’analyse (« analytics »), etc.

[0070] Dans certains modes de réalisation, différentes couches ou niveaux de régulation peuvent intervenir : une première couche de métadonnées ou chaîne de blocs 100 ; héritant des propriétés inhérentes à une chaîne de blocs (e.g. intégrité, in-falsifiabilité, etc) ; la chaîne de blocs 100 est essentielle, les autres niveaux sont optionnels. La chaîne de blocs est essentielle en ce qu’elle peut «tout» contenir (ici les données de plan de vol, les métadonnées, bases de données tierces etc) mais elle peut être allégée, notamment en déportant les données non-critiques ou volumineuses dans des bases de données secondaires, sous forme de chaîne de blocs également (« sidechains »), ou pas i.e. sans utilisation de chaîne de blocs ; une deuxième couche de données (non représentées) appelées ou référencées par la chaîne de blocs 100 (chiffrée en partie ou en totalité). Ces données, notamment de plans de vol, peuvent être stockées dans la base de données selon différents formats de (.txt, .doc, . rtf, .xml, .json, etc). Les données peuvent aussi comprendre des métriques de téléversement, de téléchargement, d’utilisations, etc lesquelles peuvent à leur tour déterminer des scores ou autres quantifications (au moyen de circuits de décision logiques e.g. des ordinateurs) ; une troisième couche de coordination ou de régulation entre acteurs (qui jouent tour à tour des rôles de producteur ou de consommateur, lisant et/ou écrivant sur la chaîne de blocs 100. Les accords entre participants à la chaîne de blocs peuvent être des contrats écrits (hors technique), ou bien partiellement - ou en totalité - transcrits via des contrats intelligents de type 140 ; une quatrième couche optionnelle peut enfin réguler les contrats intelligents eux-mêmes (contrats liés, contrats indépendants, contrat cadre modifiant d’autres contrats en aval, ou à l’inverse en amont, boucles de rétroaction multiples entre contrats, feedforward, etc). Optionnellement, l’entité 140 peut représenter ou être associé à un ou plusieurs validateurs (ou « oracles », lesquels peuvent correspondre à une validation indépendante humaine et/ou machine i.e. encodée algorithmiquement).

[0071] Dans un mode de réalisation, la chaîne de blocs 100 de données (de plans de vol) est publique. Il est notamment possible d’implémenter une validation par preuve de travail (« proof-of-work » ou PoW e.g. hashcash ou variante). Dans un mode de réalisation, la chaîne de blocs de données est privée : chaque participant est préalablement agréé (par contrat ou accord et dispose techniquement de clefs ou moyens d’authentification. Une validation par preuve d’enjeu (« proof-of-stake » ou PoS) est alors possible.

[0072] Additionnement ou en substitution, une ou plusieurs chaînes de blocs secondaires (non représentées) peuvent être utilisées. Par exemple, une chaîne de blocs principale peut contenir les métadonnées relatives aux données des plans de vols (i.e. y compris les valeurs de hachage des données), tandis qu’une chaîne secondaire peut contenir les données elles-mêmes. [0073] Dans un mode de réalisation, le procédé utilise un ou plusieurs « contrats intelligents ». Les données peuvent être partagées sur une chaîne de blocs afin d’en assurer l’horodatage et l’immuabilité.

[0074] Dans un mode de réalisation, l’utilisation que souhaite faire un consommateur des données de plans de vol d’un bloc est gouverné (directement ou indirectement via des règles) par un contrat intelligent.

[0075] Dans un mode de réalisation, toutes les données des blocs sont écrites en clair (e.g. les droits d’accès sont protégés). Dans un mode de réalisation, une partie des données sont écrites en clair (certaines informations sont lisibles par tout le monde, d’autres informations à plus haute valeur ajoutée sont protégées par exemple par chiffrement). Dans un mode de réalisation, les données des blocs sont chiffrées (e.g. symétrique, asymétrique, etc). Dans certains cas les données des blocs sont masquées en plus d’être chiffrées (l’existence des données est cachée, ce qui fournit une protection supplémentaire).

[0076] Dans un mode de réalisation, les données sont stockées dans une ou plusieurs bases de données partagées, chiffrées en tout ou partie, après vérification de leur intégrité et de l’authenticité du producteur.

[0077] Dans un mode de réalisation, la validation des données produites est effectuée par consensus distribué (e.g. utilisation validée avec un score de « pertinence » par plusieurs consommateurs, mesure et suivi du taux d’utilisation, etc) et/ou par validation d’un pair participant à la chaîne de blocs reconnu comme fiable dans la chaîne (qualification technique ou de nature administrative).

[0078] Dans un mode de réalisation, quelques informations (comme le format et/ou le résumé du contenu du bloc chiffré sont laissées en clair dans un espace de stockage (dans la chaîne ou en dehors de la chaîne), afin qu’un consommateur intéressé puisse savoir si le bloc l’intéresse ou non.

[0079] Dans certains modes de réalisation, les droits sur les données de blocs peuvent être conditionnels à des critères de contribution (notamment de ratio téléversement/téléchargement en anglais « upload/download » ou « seed/leech »).

[0080] Dans un mode de réalisation, l’accès aux données ou les droits sur ces données peuvent être régis de manière conditionnelle (par exemple si le solde d’un client ou demandeur ou Value Score est positif). [0081] Le cas échéant, si l’accès conditionnel est accordé (ou si les conditions prédéfinies sont satisfaites), le contrat intelligent exécuté peut émettre une transaction ou demande de récupération des données, laquelle transaction s’insérera (parmi plusieurs autres) dans un nouveau bloc. Si le consensus distribué confirme le bloc comprenant la transaction, une clef de chiffrement permettant la lecture des données souhaitée peut être envoyée au client ; qui pourra lire et exploiter les données désirées.

[0082] Dans un mode de réalisation, une pluralité d’acteurs partagent des données, e.g. de plans de vols, et stockent les valeurs de hash des données, ainsi que des informations relatives au format des données, dans une ou plusieurs chaînes de blocs. Après réalisation d’une transaction, un ou plusieurs contrats intelligents vérifient le « score » de valeur du demandeur, lui indiquent la position des données dans la base de données partagée, ainsi que les clefs de déchiffrement des données.

[0083] Dans un mode de réalisation, il n’y a pas de contrats intelligents (modèle direct). En effet, dans cette variante de réalisation, les producteurs et/ou consommateurs peuvent se passer de contrats intelligents, par lecture et/ou écriture (directe) dans la chaîne de blocs. Par exemple, un premier acteur peut recevoir une demande de vol ou d’attestation de vol de la part d’un consommateur et si la transaction aboutit (consensus distribué), il peut la communiquer directement audit acteur.

[0084] Dans un mode de réalisation, la chaîne de blocs ne contient pas les données de plans de vol en en elles-mêmes mais seulement la description qui est faite de ces données (les données sont stockées dans des chaînes secondaires ou une base de données centralisée off-chain). Ce mode de réalisation est avantageux en ce que les données répliquées dans la chaîne de blocs principale sont significativement moins volumineuses.

[0085] Dans un mode de réalisation, par abonnement ou « agrément de pair-à-pair », un aéronef ou drone peut, par exemple tour à tour, publier de l’information à destination des autres membres du réseau ou bien « s’abonner » (en anglais « subscribe ») au réseau, par exemple via un contrat intelligent, et recevoir les informations le concernant de manière automatique. Par exemple, un avion peut partager ses informations de plan de vol, de manière sûre et intègre, avec d’autres aéronefs (appartenant à d’autres compagnies aériennes, précisément). Les modes d’abonnement peuvent comprendre des modes push et/ou pull, de désinscription, etc. Dans certains modes de réalisation, chaque aéronef est en mesure de déterminer des intersections ou risques de collision : le trafic s’autorégule. Certains appareils ne disposant pas de moyens de calculs suffisants peuvent émettre des signaux avertissant de leur défaut ou absence de vérification temporaire ou permanente.

[0086] Dans un mode de réalisation, un contrat intelligent peut lire des données de blocs en clair et déclencher une ou plusieurs opérations, par exemple si le client ou demandeur ou consommateur est valablement abonné au type de données du bloc considéré ou si des conditions prédéfinies sont satisfaites.

[0087] Dans un mode de réalisation, un intermédiaire est ajouté (validation externe): un validateur de données (non représenté), typiquement un calculateur de l’autorité de la régulation du trafic aérien. Dans une première étape, de production, une source décide de publier des données dans la chaîne de blocs (directement ou indirectement via la base). Les données sont envoyés avec un identifiant (qui permet d’identifier la source d’envoi des données) et un résumé du contenu (e.g. paramètres, unités, quantité, format, etc) ainsi que la date des données (e.g. création, validité, etc) Cet ensemble forme un « bloc » à valider. Le sous-système de validation reçoit les données. La validation est effectuée soit consensus ou par un « validateur» externe et « de confiance » : d’autres fournisseurs ou utilisateurs vérifient l’intégrité des données (et en option l’authenticité de l’émetteur). Ceci peut donner lieu à rétribution (en VS) pour le ou les noeuds ayant participé à la validation. Ce peut être le consommateur qui vérifie l’intégrité du bloc (hash). Dans un mode de réalisation, le consommateur peut « noter » (unilatéralement) l’attractivité du bloc reçu (son intérêt estimé pour et par lui-même). Dans un mode de réalisation, la note est donnée par le consommateur. Dans un mode de réalisation, la note est calculée par comptage du nombre de téléchargements du jeu de données considéré et/ou par le nombre de consommateurs intéressés ou acheteurs/licenciés effectifs. Si les données sont déclarées comme étant invalides alors 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. Dans un mode de réalisation, si les données sont considérées comme valides/intègres alors un nouveau bloc est créé, qui contiendra le lien vers les données (e.g. adresses, clefs), et une augmentation de VS_PROD d’un certain montant pour le nœud ou la partie de validation.

[0088] Dans certains modes de réalisation, le tiers validateur est « internalisé » : les vérifications sont effectuées directement et automatiquement par un ou plusieurs contrats intelligents. A chaque nouvelle entrée dans la base (et tentative d’écriture de bloc), un ou plusieurs contrats intelligents peuvent exécuter diverses tâches, notamment a) vérifier si le producteur est déclaré (s’il s’agit d’une partie au consortium ou chaîne de blocs) ; b) modifier le score VS de la source c) noter ou évaluer les données entrées (directement ou indirectement) ; éventuellement d) effectuer directement des vérifications fonctionnelles sur les données (par exemple, des données issues d’un aéronef de modèle X peuvent être corrélées/croisées avec d’autres sources d’informations sur l’aéronef (e.g. 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 (e.g. heure de décollage, statut courant e.g. en vol, au sol, en croisière, position courante ...) ; en particulier, la séquence des vérifications du quadruplet opérateur/plan de vol/avion/pilote peut être mise en œuvre par un ou plusieurs contrats intelligents.

[0089] Dans la perspective de la consommation de données, un consommateur peut s’abonner ou se déclarer intéressé pour récupérer des données (e.g. ordre de transaction directement sur la chaîne de blocs ou via un ou un contrat intelligent). Le contrat intelligent concerné peut vérifier si le demandeur a le solde suffisant (VS) pour télécharger les données. Dans une variante de réalisation, le bloc acheté est mis à disposition d’un ou de plusieurs validateurs humains et/ou machines qui effectuent cette vérification. Si la transaction est valide, le jeu de données (par exemple chiffré) est transmis au demandeur, qui peut par exemple avoir la possibilité de vérifier son intégrité (valeur de hash récupérée dans la chaîne de blocs). Si le jeu de données est déterminé ou réputé valide, des clefs de déchiffrement (stockées dans la chaîne de blocs) sont récupérées par le contrat intelligent et transmises au demandeur. La transaction est ensuite inscrite dans la chaîne de blocs par le contrat intelligent. Dans un mode de réalisation, des mécanismes de compensation et/ou d’évaluation et/ou de rétribution et/ou de validation peut être mis en œuvre si les données sont déterminées comme étant valides (mécanisme de notation et/ou de réputation pour identifier ou rétribuer les émetteurs de données les plus « utiles » (notion relative à une ou plusieurs objectifs pouvant être objectivés et internalisés).

Le demandeur i.e. initiateur de la transaction peut par exemple importer les données obtenues et les croiser ou intégrer à des données existantes dans le but d’effectuer un traitement de type « Big Data » par des techniques d’intelligence artificielles (notamment d’apprentissage automatique).

[0090] La [FIG 2] illustre la gestion d’un plan de vol selon l’état de la technique.

[0091] Aujourd’hui, la notion de dépôt de « plan de vol » est standardisée à travers des formulaires et de nombreux outils facilitent le remplissage de ce document existant même en version électronique. Le dépôt est généralement automatique mais l’attestation de la validité de ce plan de vol passe par des opérations le plus souvent humaines.

[0092] En Europe par exemple, l’organisme centralisé qui délivre les plan de vol pour l’aviation commerciale ou de tourisme est la « CFMU » (« Central Flow Management Unit »), organisme de gestion et d'optimisation des flux de trafic aérien). Cet organisme de gestion ne sait gérer que quelques centaines de vols par jour, et est dédiée à la sécurité des passagers et membres d’équipage : elle n’est pas adaptée aux vols de drones. Elle gère des créneaux de décollage et atterrissage et transit dans les espaces aériens dans le but de garantir une densité correcte d’avion pour le contrôle aérien : elle est inadaptée à certains types de porteurs comme les drones urbains (e.g. altitudes de vol en dessous des plafonds gérés par cet organisme, non détectables par les radars de contrôle aérien, variabilité des vitesses et des altitudes trop importante pour ses algorithmes, lieux d’atterrissage et de décollage non figés ni répertoriés). Il faut généralement un préavis de 1 à 6 jours pour déposer un plan de vol. Ce délai est inadapté pour des modes d’utilisation de drones urbains (e.g. livraison de plateaux repas à la commande par exemple).

[0093] Quand la quantité et la variété de plans de vol déposés deviendra très grande, ce processus atteindra rapidement ses limites jusqu’à ne plus pouvoir répondre au service attendu (qui est la sécurité de la navigation, laquelle commence par la validation des plans de vol déposés).

[0094] Aujourd’hui, l’attestation « bon pour vol » d’un plan de vol spécifie des donneurs d’ordre et des mobiles aériens, en nombre identifiable, avec des plans de vol standards reliant des aéroports connus. [0095] La chaîne de validation des plans de vol actuels est illustrée à la [FIG. 2] L’autorité aérienne 250 délivre l’attestation ou la validation 260 « bon pour vol » si le plan de vol 240 est correctement défini et les conditions de vol du jour du vol sont compatibles avec le type de mobile aérien 220. Le plan de vol déposé 240 indique notamment l’avion utilisé 220 et indirectement désigne le propriétaire ou client 210 et un pilote certifié 230. L’autorité aérienne 200 a au préalable certifié « bon pour vol » le mobile aérien considéré, délivré des certificats de pilotage aux pilotes et autorisé les compagnies aériennes à opérer les mobiles aériens.

[0096] Le mécanisme est donc centralisé : il est limité dans sa capacité du fait de cette centralisation. Le « nœud » central ATC nécessite une très grande attention pour éviter les incidents, pannes, ou les malveillances. Cette architecture a aussi un impact fort sur les évolutions matérielles et logicielles, qui se révèlent délicates et longues.

[0097] La [FIG 3] illustre un mode de réalisation de l’invention.

[0098] La figure montre une chaîne de blocs 300, les entités précédentes décrites à la figure 2 et une entité « lambda » 330. La chaîne de blocs possède diverses propriétés énoncées ci-avant. En particulier, c’est une base de données distribuée (répliquée) et en écriture uniquement (« write-only »), que les flèches à sens unique représentent sur la figure. Le dépôt et/ou la validation peuvent être horodatés et/ou validés sur la chaîne de blocs. En particulier, la chaîne de blocs peut exécuter un ou plusieurs contrats intelligents (non représentés) qui mettent en œuvre le procédé selon l’invention et in fine peut délivrer une validation technique 360 (ou « attestation » dans son interprétation externe e.g. administrative).

[0099] Il est à noter que la chaîne de blocs 300 peut en réalité correspondre à une pluralité de chaînes de blocs (secondaires ou « sidechains », lesquelles peuvent accélérer les temps de réponse). Les mécanismes de mises en cache (ou d’architecture hybride centralisée/décentralisée) peuvent également accélérer les temps de traitement des plans de vols et la délivrance des « bons pour vol » en particulier.

[0100] Une ou plusieurs chaînes de blocs peuvent être utilisées. L’utilisation de chaînes de blocs secondaires est avantageuse en ce que la localité des plans de vol peut être optimisée. Certains aéronefs effectuent des missions courtes sur des périmètres géographiques restreints (drones urbains ou agricoles par exemples) : les aéronefs et drones concernés peuvent s’adresser ou s’associer à des chaînes de blocs spécifiques (e.g. secondaires ou caches centralisés).

[0101] Dans un mode de réalisation, la chaîne de blocs 300 est partitionnée en « espace » (du point de vue temporel, les événements sont inscrits en écriture seule, i.e. s’accumulent sans possibilité d’altération ou de falsification, ce qui permet notamment une traçabilité utile). Puisque les accès à la chaîne de blocs sont parallèles et concurrents, il peut être avantageux de définir des zones mémoires associées à des zones géographiques (x,y), voir même par niveaux d’altitude (z).

Les différents types d’aéronefs n’évoluent pas nécessairement dans les mêmes intervalles de FL (« Flight Levels »), certains drones étant amenés à évoluer à basse altitude, tandis que les avions commerciaux évoluent à haute altitude). La gestion verticale peut être un des critères de calcul en soi dans la gestion du trafic aérien, mais il peut dans certains cas être avantageux de procéder à cette gestion en tout ou partie dans les couches matérielles (partitionnement de la chaîne de blocs principale et/ou spécialisation des chaînes de blocs secondaires par zone d’espace 2D ou 3D).

[0102] Le symbole « quel que soit » dans l’entité 330 matérialise le fait que n’importe quel acteur 330 (e.g. 210, 220, 230, 240, 250, ou autre) de l’écosystème peut interagir et produire des données d’enregistrement ou de validation (chaîne de consortium, modèle « producteur/consommateurs »). Par acteur 330, on entend, dans un mode de réalisation, un acteur physique ou une personne morale: un opérateur (compagnie, opérateur de drones ...), un pilote, une autorité de certification de la qualité du pilote, une autorité de délivrance d’un certificat de vol pour un mobile, un constructeur, un organisme de maintenance (« contrôle technique »), un organisme territorial (ville état ...), une personne physique cliente de l’opération (exemple agriculteur ou coopérative pour un drone d’épandage), un expert dans la construction et la gestion de plans de vol, une autorité de contrôle aérien, ou une autorité de gestion du trafic aérien. Techniquement, l’ouverture à tout type d’acteur peut signifier que la chaîne de blocs 300 est de type public (requérant alors un mécanisme d’admission, par exemple par validation de preuve de travail, ou CPR « challenge-response » ou de tout autre type de mécanisme). Dans certains modes de réalisation, la chaîne de blocs est de type privée (participants connus ou agréés préalablement, authentification, etc). [0103] Dans un mode de réalisation, l’acteur 330 peut être un programme (classique, dont l’exécution n’est pas inéluctable, voire même un « contrat intelligent » (i.e. pas nécessairement hébergé par la chaîne de blocs 300, mais qui dépend d’une autre chaîne de blocs). Par exemple, l’exécution d’un contrat intelligent 330 peut se déclencher en fonction de la constatation d’un fait (par exemple la survenue d’un orage).

[0104] Les fonctions (le périmètre) d’un contrat intelligent peuvent être diverses.

Dans un mode de réalisation, la validation de l’identité et/ou la qualification du pilote peuvent être effectuées au moyen d’un ou de plusieurs contrats intelligents, déclenchés par un ou plusieurs Oracles 331 (ou services d’Oracle). Un Oracle peut être un agent ou service indépendant de vérification de l’enregistrement dudit pilote dans une base, et/ou de vérification de ses autorisations d’exercer dans une base d’enregistrement des pilotes.

[0105] Dans un mode de réalisation, un contrat intelligent est immuable et prédéterminé. Dans un mode de réalisation, un contrat intelligent comprend (i.e. peut implémenter en totalité ou en partie) un ou plusieurs mécanismes d’apprentissage automatique (les données d’apprentissage peuvent notamment comprendre un ou plusieurs historiques par exemple de plan de vol).

[0106] Dans un mode de réalisation de l’invention, un ou plusieurs mécanismes de rétribution des noeuds dits "valideurs" ou "validateurs" peuvent inciter les différents acteurs de l’écosystème à participer à la validation des plans de vol de tiers.

[0107] Dans un mode de réalisation de l’invention, le procédé comprend l’étape consistant à délivrer une attestation de vol pour une mission définie ou créée dans une base de données de plan de vols par un ou plusieurs opérateurs identifiés dans une base de données opérateurs, ayant établi un ou plusieurs contrats intelligents avec un ou plusieurs pilotes déclarés dans une base de données des pilotes certifiées, lesdits opérateurs initiaux possédant des mobiles aériens ou aéronefs ou drones faisant partie d’une base de données des mobiles aériens certifiés.

[0108] Dans un mode de réalisation de l’invention le donneur d’ordre initial peut confier au pilote la définition du plan de vol déposé conformément à la mission envisagé et utiliser le mobile aérien adéquat et pour lequel il a un certificat de vol. [0109] Dans un mode de réalisation, un calculateur de type « FMS » 310 (pour « Flight Management System ») peut être un des acteurs 330.

[0110] Par l’intermédiaire de l’exécution d’un ou de plusieurs contrats intelligents hébergés sur/par une ou plusieurs chaînes de blocs, le procédé comprend les étapes consistant à vérifier la définition correcte d’un ou de plusieurs plans de vol et la vérification ou la détermination que le mobile aérien sélectionné est apte à effectuer ou volé le plan de vol déposé ou soumis.

[0111] Plus généralement, on désigne par FMS un calculateur générique capable de générer un plan de vol ou de déplacement conforme aux standards internationaux (en matière aérienne, conformité aux normes AEEC ARINC 424 et 702). Dans certains modes de réalisation, le FMS peut être un calculateur de mission, conforme à d’autres règlements actuels ou futurs, par exemple un calculateur de roulage pour véhicule terrestre (voiture autonome).

[0112] La [FIG. 4] illustre un aspect d’un mode de réalisation de l’invention.

[0113] Les étapes d’ajout dans la base signifient un «horodatage» au sens de la chaîne de blocs, i.e. correspondent à l’enregistrement de l’information au sein d’un bloc.

[0114] Dans un mode de réalisation de l’invention, le procédé comprend deux phases successives, une première phase correspondant à déterminer si le plan de vol est valable 400 et une seconde phase consistant à déterminer une attestation du plan de vol 500 (voir figure 5).

[0115] La première phase établit une conformité «unitaire», i.e. fondée sur les caractéristiques propres de chaque acteur, prises et considérées isolément les unes des autres, par étapes successives: a) conformité de l’opérateur 410 ; un nouvel opérateur devra par exemple fournir des garanties en termes d’assurances versus les accidents de la circulation aérienne. b) conformité du plan de vol 420 ; un nouveau plan de vol devra être explicite autrement dit basé sur des points soit publics, soit privés mais dans tous les cas une définition en latitude et longitude doit exister, optionnellement avec une altitude. Un système FMS pourra, dans un mode de réalisation, valider que le plan de vol est correctement explicité. c) conformité du mobile 430 ; un nouveau mobile aérien devra par exemple disposer de certificats l’autorisant à voler en précisant son domaine de vol ses performances et ses équipements. Un système FM pourra valider l’adéquation entre le plan de vol déposé et les performances du mobile aérien choisi. Il pourra également être vérifié que l’équipement de l’avion est compatible de la mission ; par exemple un atterrissage, avec une approche choisie de type « ILS », nécessite un récepteur ILS à bord de l’avion. d) conformité du pilote 510 (voir figure 5).

[0116] Différentes bases de données peuvent être utilisées.

[0117] La base de données 431 concerne les différents types d’aéronefs existants et est mise à jour des différents types de drones.

[0118] La base de données de plan de vol déposés 421 comprend les plans de vol déposés par les appareils existants, et par extension les nouveaux plans de vol déposés par les drones (nouvelle structure de plan de vol avec par exemple l’absence d’aéroports publiés de départ et d’arrivée, remplacés par des points de décollage et d’atterrissage, par exemple).

[0119] La base de données des clients opérateurs 411 n’existe pas dans l’état de la technique. Cette base de données comprend et recense les opérateurs aériens classiques et de surcroît les opérateurs de drones (e.g. sociétés de commerce électronique, distribution de médicaments, drones agricoles, etc).

[0120] L’analyse des phases déclaratives attestant de la validité du plan de vol déposé (que ce soit avant le décollage, ou lors de modifications du plan de vol en vol) peut utiliser diverses bases de données (de pilotes ou compagnies aériennes, de mobiles aériens, de plans de vol, de clients). Ces bases de données peuvent être inscrites dans une ou plusieurs chaînes de blocs. Cette phase d’analyse et de traitement peut déboucher sur un calcul automatique de l’attestation du plan de vol déposé pour un client avec le mobile aérien utilisé et le pilote choisi.

[0121] La [FIG. 5] illustre un autre aspect d’un mode de réalisation de l’invention.

[0122] La deuxième phase ou niveau est effectué « en couplage », i.e. se fonde sur l’assemblage des étapes de vérification isolée, afin de vérifier in fine la conformité du quadruplet opérateur/plan de vol/mobile/pilote. [0123] Dans un mode de réalisation, l’organigramme illustré à la figure 5 montre différentes étapes de validation, de manière « croissante » (i.e. de manière cumulative).

[0124] Il est d’abord testé si le plan de vol « volable » est associé à un pilote connu. Il est ensuite déterminé si le pilote est associé à un aéronef enregistré et valide (étape 510). Pour rentrer dans la base de données pilote 511, un pilote devra préalablement renseigner les mobiles aériens pour lesquels il a obtenu un certificat. Dans certains modes de réalisation, il peut être vérifié que le pilote a bien renseigné ses certificats. Par la suite, le triplet plan de vol/pilote/avion est vérifié. Enfin, dans une dernière étape, étant donné le trafic prévu, il est déterminé si le quadruplet plan de vol/pilote/avion/trafic est autorisé ou validé.

[0125] La base de données de pilotes 511 existe actuellement pour les pilotes des avions de commerce, des avions d’affaire, des avions des aéroclubs. Par extension, la base 511 comprendra les télés-pilotes (en très grand nombre donc).

[0126] La [FIG. 6] illustre un mode de réalisation spécifique de l’invention.

[0127] L’utilisation d’une ou de plusieurs chaînes de blocs, ainsi que d’un ou plusieurs contrats intelligents optionnels, permet la coopération d’un grand nombre d’acteurs 610, dont les intérêts ne sont pas nécessairement congruents, de manière sécurisée et fiable.

[0128] Des mécanismes d’incitation au partage de données et/ou à la vérification de données peuvent être mis en oeuvre.

[0129] Dans un mode de réalisation, par exemple pour chaque étape illustrée aux figures 4 et 5, le procédé peut comprendre l’étape consistant à déterminer un score ou une note de validation, permettant de vérifier la conformité. Dans un mode de réalisation, la validation est binaire (réponse de conformité « OUI » ou réponse «

NON » de non-conformité). Dans un mode de réalisation, la réponse «OUI» ou «NON» se fait par comparaison du score à un seuil prédéfini, ou une plage de seuils prédéfinis.

[0130] Dans un mode de réalisation, la validation est quantifiée selon des états discrets (e.g. logique floue). [0131] Dans un mode de réalisation, le score est calculé sur la base de scores unitaires associés aux acteurs « valideurs» ou «validateurs» » tels qu’identifiés ci- avant.

[0132] Dans un mode de réalisation, pour un ou plusieurs acteurs, les scores peuvent être déterminés en fonction des étapes décrites précédemment. Par exemple, les scores peuvent être des points (entiers ou réels ou binaires). Un seuil peut correspondre à un nombre de points attendus selon la criticité de l’opération à valider. Dans un mode de réalisation, les scores peuvent dépendre des acteurs : en effet, un acteur peut être plus à même de valider le « mobile » par exemple, comparativement à d’autres acteurs.

[0133] Dans une variante de réalisation, les scores 610 (A ... E) dans l’exemple illustré à la [FIG. 6] peuvent dépendre du type d’entrée (par exemple ils peuvent dépendre du type de plan de vol déposé en fonction du risque pour l’environnement/population (e.g. survol d’un champ à risque inférieur au survol d’installation industrielle sans danger, lui-même associé à un risque inférieur à un survol d’un zone habitée peu dense, lui-même associé à un risque inférieur à un survol d’une zone habitée dense, lui-même associé à un risque inférieur à un survol d’une installation industrielle sensible).

[0134] Dans un mode de réalisation, un score dépend des acteurs considérés et/ou du type d’entrée.

[0135] Dans un mode de réalisation, un score peut évoluer au cours du temps.

[0136] Afin d’inciter les acteurs à participer aux étapes de validation, dans ce mécanisme décentralisé, une rétribution 620 peut être associée aux différentes étapes, sous forme d’un score de rétribution « VS1 ...VSN ») : Chaque membre du réseau se voit donc attribuer un score de valeur (VS = Value Score) pour lui permettre de participer aux échanges (en tant que producteur et/ou consommateur de données).

[0137] Ce score VS peut être fonction de a) la valeur des informations qu’il produit VS_PROD e.g. de ses contributions aux validations b) de la valeur des informations qu’il consomme VS_CONS e.g. quand il demande à faire valider son opération. La valeur VS peut s’exprimer sous forme d’un score, d’une crypto monnaie, d’une monnaie réelle. [0138] Avantageusement, la valeur ou score VS peut être modifiée par conversion en valeur monétisée, lorsque qu’un acteur achète un montant VS_TRANSACTION de droit de consommer pour pouvoir ultérieurement consommer des données de validation ou faire valider ses plans de vol, ce qui peut être utile s’il en consomme plus qu’il n’en produit. Un acteur peut transformer sa VS en monnaie réelle, en points, crédits ou autres jetons crypto, ce qui diminue sa VS de la valeur transformée VS_ TRANSACTION. Ce score VS est amené à évoluer en fonction de l’attractivité de la validation.

[0139] Les valeurs VS_PROD et VS_CONS peuvent être calculées de différentes manières. Par exemple, une valeur VS peut être déterminée en quantité (nombre d’étapes validées par un seul et même acteur) et/ou en qualité (définition fine du plan de vol, qualité des mobiles mis en oeuvre, etc). Une valeur VS peut aussi résulter d’un 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), l'historique d’utilisation, le cours du jour (fonction de paramètres), la fixation priori de bornes min/max, un consensus a priori sur les valeurs des différentes données entre acteurs, une valeur fixée par des autorités nationales ou des organismes internationaux en fonction de criticités dans l’opération, ou selon toute combinaison de ces modes de calcul.

[0140] Les valeurs ou modalités de calcul de ces valeurs peuvent être inscrites dans un ou plusieurs contrat intelligents, lesquels peuvent être bipartite (accord entre deux acteurs) ou multipartite (accord entre 1 à N fournisseurs et 1 à M consommateurs).

[0141] La chaîne de blocs peut contenir le score actualisé de VS pour chaque acteur du réseau : lorsque le score d’un acteur est mis à jour, la chaîne de blocs l’est aussi. 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ée. Par ailleurs cette valeur possède un historique certain (et peut donc avantageusement servir à quantifier la réputation d’un acteur).

[0142] Ainsi lorsqu’ un fournisseur publie des données de validation (dans la base de données ou dans un bloc de la chaîne de bloc selon les alternatives), ces données sont ajoutées (directement par l’émetteur ou via un contrat intelligent), ainsi que la valeur courante du VS, un timestamp (horodatage), une identification de la source (ID) et un moyen de valider l’intégrité du jeu de données ( hash du jeu de données).

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

[0144] Dans d’autres modes de réalisation, divers services d’analyse ou de méta- analyse peuvent être déterminés : historique et palmarès des contributeurs, calcul de risques d’injection de données fausses (i.e. simplement erronées) ou malicieuses (intentionnellement fausses pour affaiblir ou fausser les calculs réalisés par les tiers, etc). La chaîne de blocs étant transparente quant au moins à certaines données (métadonnées descriptives, historiques des transactions, etc), une partie éventuellement malicieuse sera rapidement déterminée comme telle et éjectée du noyau de confiance entre parties authentifiées. A contrario, la transparence du système dont la gouvernance est au moins en partie auditable encourage les parties prenantes à abandonner une certaine souveraineté sur les données, en contrepartie d’accès à des données tierces et/ou de compensation financière.

[0145] La présente 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. L’ordinateur peut être un rack ou une tablette ou un EFB (sac de vol électronique) ou une partie logicielle intégrée dans le FMS (système de gestion de vol), etc. Le support peut être électronique, magnétique, optique, ou électromagnétique.

[0146] Matériellement, les modes de réalisation de l’invention peuvent être réalisés par ordinateur. Par exemple, une architecture distribuée du type « informatique dans les nuages » (« cloud computing » en anglais). Des serveurs en pair-à-pair, entièrement ou partiellement distribués (existences de centres) peuvent interagir.

Une chaîne de blocs repose sur une architecture décentralisée, qui peut être plus ou moins distribuée. Une mise en œuvre par chaîne de blocs ne fait pas obstacle à l’existence d’une ou de plusieurs nœuds privilégiés, quand il s’agit de cloud privé ou de chaîne de blocs privée. Les accès peuvent être multiplateformes (e.g. depuis EFB, WebApp, accès sol, etc).

[0147] Dans un mode de réalisation, un aéronef ou drone est équipé d’un module de communication et de partage collaboratif de données issues des calculateurs embarqués dans l’aéronef. Ce module matériel peut être en relation avec divers utilisateurs (consommateurs) et/ou fournisseurs (producteurs) de données. Les équipements avioniques peuvent interagir (communication bilatérale) avec des équipements non-avioniques. Dans certains cas, les communications peuvent être unilatérales (depuis l’avionique vers le non-avionique, mais pas l’inverse, i.e. pour éviter l’injection de données erronées ou malicieuses du monde ouvert vers le monder avionique certifié). Des systèmes de gestion de vol FMS peuvent être mis en réseau entre eux, également avec des EFB.