WO2021170305A1 - Manipulations de bases de donnees par registres distribues - Google Patents

Manipulations de bases de donnees par registres distribues Download PDF

Info

Publication number
WO2021170305A1
WO2021170305A1 PCT/EP2021/050552 EP2021050552W WO2021170305A1 WO 2021170305 A1 WO2021170305 A1 WO 2021170305A1 EP 2021050552 W EP2021050552 W EP 2021050552W WO 2021170305 A1 WO2021170305 A1 WO 2021170305A1
Authority
WO
WIPO (PCT)
Prior art keywords
data
database
blockchain
databases
aircraft
Prior art date
Application number
PCT/EP2021/050552
Other languages
English (en)
Inventor
François Coulmeau
Dorian Martinez
Original Assignee
Thales
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Thales filed Critical Thales
Publication of WO2021170305A1 publication Critical patent/WO2021170305A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/10—Office automation; Time management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/04—Forecasting or optimisation specially adapted for administrative or management purposes, e.g. linear programming or "cutting stock problem"
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/06—Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/10—Office automation; Time management
    • G06Q10/101—Collaborative creation, e.g. joint development of products or services
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/20—Administration of product repair or maintenance
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q50/00—Information and communication technology [ICT] specially adapted for implementation of business processes of specific business sectors, e.g. utilities or tourism
    • G06Q50/40—Business processes related to the transportation industry

Definitions

  • the state of the art is generally based on centralized databases, controlled by one or more players. These databases are updated by a privileged actor, then validated by each actor who G uses, without sharing or quality measurement.
  • the actors creators / validators or producers / consumers
  • a non-exhaustive list of these players includes, in particular, computer suppliers, aircraft manufacturers, designers of aerodynamics databases, engine manufacturers, state organizations (designers of navigation procedures), researchers, geologists, designers of magnetic declination models of the globe, airlines, or meteorologists.
  • the document relates to systems and methods for the management of aeronautical databases, comprising the steps of: maintaining a blockchain; said blockchain comprising one or more smart contracts; a smart contract governing the management of one or more databases validate all or part of a database, or an update of said database, by consensus distributed among the parties associated with the data chain blocks, said parts being associated with one or more aeronautical computers, in particular FMS flight management systems.
  • Developments describe in particular G the use of patches, smart contracts, scores (especially reliability), obsolescence of data or avionics databases. Aspects of software are described.
  • the embodiments of the invention make it possible to substantially improve the aeronautical databases.
  • the embodiments of the invention allow the emergence of value-added services for air operations (eg estimation of delays, overconsumption, optimization of trajectories, anticipation of flows, meteorology, management of “dispatch” fleets etc).
  • the embodiments of the invention make it possible to improve aeronautical safety, as well as flight safety, by analysis of flows and early detection of anomalies that are difficult to predict a priori.
  • the embodiments of the invention make it possible to improve the mission management of an aircraft when many devices are engaged in space (e.g. airplanes, drones, etc.).
  • the embodiments of the invention make it possible to manipulate data originating from several computers, from various suppliers.
  • the invention makes it possible in particular to go beyond the conventional “bipartite” contractual and technical framework.
  • the invention makes it possible to manage the variability, the rapid evolution of actors and / or data
  • the embodiments of the invention allow global processing, almost in real time, of the data between the actors.
  • the methods and systems for validating database information according to the invention make it possible to ensure fluid transmission of data (up-to-date and correct) from the computers to the users.
  • the sharing can be quantified (the exchanges are traceable).
  • the embodiments according to the invention improve the sharing of raw information originating from aeronautical computers in a community of computer suppliers or users of these computers, in order to derive therefrom enriched confirmations having a value, while ensuring the integrity of the information that is transmitted and equal treatment between the actors (fair remuneration of the one who makes the data available).
  • G use of time-stamped exchange mechanisms verified by consensus make it possible to ensure the same level of integrity as traditional processes, and the sharing of these databases in real time.
  • FIG. 1 [0021] [fig-2] illustrates examples of steps of an embodiment according to the invention.
  • a “mobile” or “aircraft” may be a drone, or a commercial aircraft, or a freight aircraft, or even a helicopter, whether or not carrying passengers.
  • the mobile can be piloted, remotely piloted or autonomous; such as an aircraft (airplane, helicopter, or any other device subject to the laws of aeronautics).
  • the mobile can be terrestrial, surface (e.g. boat), submersible (submarine), orbital (satellite), etc.
  • the term “aircraft” in the description below can be replaced by the terms vehicle, car, truck, bus, train, motorcycle, boat, robot, submarine, toy, etc. or any element that can be remotely controlled (by radio link, satellite, or other), at least partially (intermittently, or periodically, or even op portunist over time).
  • NAVDB databases are used by on-board computers (FMS for “Flight Management System”), in order to build the flight plans of the aircraft.
  • FMS flight Management System
  • these databases contain and determine in particular the structuring of air routes and take-off and landing procedures for all types of aircraft, in particular airports and associated runways in 2D, 3D; waypoints in 2D or 3D, standard take-off ("SID") and landing procedures "STAR", “VIA”, “APP”, air routes “Airways”, radio navigation beacons in 2D / 3D with their frequency and type: “VOR”, “DME”, “T AC AN”, etc.
  • MAGVAR Magnetic Declination corrections. It is provided, for example, by the American administration ("National Oceanic and Atmospheric Administration”, acronym NOAA). It models the terrestrial globe, and in particular the difference between the true heading ("True Heading”) and the magnetic heading (“Magnetic Heading”). It is used by FMS flight management systems but also by inertial location systems ("Inertial Reference Systems", acronym 1RS) to calculate magnetic and true headings at any point on the aircraft's trajectory.
  • NOAA National Oceanic and Atmospheric Administration
  • PROFDB This so-called "PERFDB” database is generally provided by the manufacturer of the aircraft and contains the modeling of the behavior of the aircraft (modeling of its aerodynamics eg drag, lift, etc.), of its engines ( consumption, push). It is used by FMS or PA (Autopilot) systems or by surveillance systems (TAWS for field surveillance, TCAS for surveillance between devices) to calculate the 3D trajectory of the aircraft, its lateral capacities, in vertical, in speed, flight envelope, fuel consumption, etc.
  • FMS or PA Autopilot
  • TAWS surveillance systems
  • TCAS surveillance between devices
  • This so-called “AOF-DB” database is in accordance with the international standard AEEC ARINC 816. It contains and determines the structuring of airport surfaces (or helipad) and is used by taxiing computers (AOF for Airport Operation Function) or FMS. It contains the positions of runways, taxiways, hangars, parking points, etc.
  • TAWS-DB This so-called "TAWS-DB” database is in accordance with the AEEC international standard.
  • ARINC 762 contains a model of the terrestrial terrain (elevation in relation to a chosen geodesy). It is a mesh of the terrestrial globe, more or less fine according to the sources of information, including in particular the rise above the mean sea level, by mesh.
  • WXR-DB contains a model of meteorological forecasts (e.g winds, temperatures, convections, volcanic activities) over a given time horizon.
  • GNSS-DB contains, among other things, the ephemeris of the GNSS constellations (eg GPS, GALILEO, GAGAN, GLONASS, etc.) and is used by GNSS receivers to calculate the aircraft position, or by the FMS systems to calculate the predicted availability of satellite receptions throughout the flight plan.
  • GNSS-DB ephemeris of the GNSS constellations (eg GPS, GALILEO, GAGAN, GLONASS, etc.) and is used by GNSS receivers to calculate the aircraft position, or by the FMS systems to calculate the predicted availability of satellite receptions throughout the flight plan.
  • ATC-DB contains 3D polygons which correspond to air sectors, and associated frequencies, but also opening / closing times of said sectors, different flight authorizations depending on the circumstances. categories of aircraft passing through them, etc.
  • the long and complex updates of databases are subject to numerous constraints of testability, proof of determinism and integrity ("qualification” or "certification” procedures).
  • the RTCA DO200 document therefore specifies the long and costly processes which make it possible to guarantee the non-corruption of the raw data during the transformation stages which lead to the generation of the databases to be embarked.
  • the update time cycles can be very different.
  • the so-called WXR DB meteorological database is updated before each flight. Data is updated globally every six hours for some airlines, hourly for others. For a flight lasting a few hours, this cycle may be insufficient, as the weather can change very quickly.
  • NAVDB database is updated every 28 days (AIRAC cycle for "Aeronautical Information Regulation and Control") an update for example updates the opening of new runways, the publication of points passage, modification of radio navigation beacons, etc.
  • AOF-DB database The same update cycle is observed for the so-called AOF-DB database.
  • changes between two separate cycles are managed manually (use of paper bulletins), which leads to misunderstandings and risks to aviation security. nautical.
  • the DB database (terrain / Obstacles) is updated every one to five years depending on the suppliers.
  • the obstacle section can be updated with shorter cycles.
  • these updates do not take into account the topographical modifications of the globe, and large-scale constructions (e.g. high voltage pylons, buildings ).
  • Warning systems can therefore be less precise, integrated, or generate false alarms.
  • the MAGVAR database is updated every five years for aircraft. It includes a prediction model to calculate, on a given date, the real declination. In practice, the real variations over time do not always correspond to the model, and moreover the magnetic declination evolves more erratically and more rapidly than expected, because of cosmic or climatic events. The on-board systems that use it are therefore biased (loss of precision) or even distorted.
  • an experienced pilot will fly the modified procedure, by hand, while observing the way in which the computers concerned would wish to fly this same procedure, in order to validate it, and to authorize the other planes to use G afterwards.
  • PERFDB database is updated via wind tunnel tests and modeling, once at the start of the aircraft program and then changes very little (except for major fixes).
  • constant or linear error correction is provided thanks to various factors (correction of engine flow rate, engine performance, drag related to the aging of the aircraft or to maintenance, etc.).
  • these fixes do not take into account the aging of the aircraft, and inaccuracies in modeling can lead to systematic biases for the computers that use them.
  • a computer-implemented method for managing aeronautical databases comprising the steps of: maintaining a chain of blocks; - said chain of blocks comprising one or more smart contracts; a smart contract governing the management of one or more databases. - validating all or part of a database, or of an update of said database, by consensus distributed among the parties associated with the blockchain, said parties being associated with one or more aeronautical computers, in particular FMS flight management systems.
  • the advantage of using a smart contract lies in the fact that the code is auditable, and especially that the execution of this code is inevitable (executions carried out in parallel on the nodes of the blockchain, and final result validated by consensus distributed).
  • the use of a blockchain allows the implementation of distributed consensus mechanisms. The use of the data concerned can be confirmed as valid by M other users among N.
  • said aeronautical computers perform logical validation tests and / or provide proof of determinism and integrity of the calculations of the validation tests.
  • one or more smart contracts can serve as intermediaries to implement logical tests relating to the integrity of the updates and / or the consistency of the implementation of these data updates. . Wind tunnel tests and / or modeling can also be invoked.
  • the method further comprises a step consisting in modifying one or more data updates, by making constant, linear or non-linear corrections.
  • the validation of all or part of a database, or of a data update is also determined by a predefined trusted third party, in particular an air navigation control authority .
  • a smart contract governs the rights to access, read and / or write to the databases and / or the blockchain, in particular by the management of encryption keys.
  • a smart contract that is to say of programs executed in parallel whose execution is auditable and secure, makes it possible to organize the exchanges of data, in a qualitative and / or quantitative manner, in the time and / or space.
  • a smart contract will thus be able to provide automatic verification services of the validity of configurations (by class of aircraft for example, but also according to a granularity up to the aircraft configuration specific to each device).
  • a smart contract can indeed control updates, directly (manage) or indirectly (govern, e.g. through rules). Smart contracts can apply or trigger the application of one or more tests on the data concerned (eg integrity, absence of malicious code, systemic consistency or consistency, i.e. compatibility of additions or withdrawals, etc.) .
  • a smart contract can encrypt, decrypt and / or re-encrypt data (e.g. prevent collusion or parasitism, etc.).
  • the encryption is asymmetric, a public key being associated with the identifier of an aircraft and a private key being associated with the aircraft.
  • a smart contract governs the communications of database updates between database providers and the airlines or aircraft consuming said updates.
  • a chain of blocks can also serve as a means of secure transfer of DBs and / or SWs between suppliers and companies and may provide automatic verification services for the validity of configurations.
  • one or more smart contracts determine a reliability score associated with the parties to the blockchain.
  • the reliability score is determined as a function of intrinsic parameters associated with the data communicated, including in particular the lifespan of the data, the rarity of the existence of the data, a high frequency of use of the data, the criticality of a procedure associated with the data, a performance associated with the data, in particular in terms of reducing fuel consumption, reducing noise or reducing the risk of collision between aircraft.
  • the reliability score is determined as a function of extrinsic parameters associated with the sources of the data communicated, comprising in particular a variable or predefined reputation, a ratio between uploading and / or downloading of data, or a transaction with a consideration for increasing said reliability score.
  • a database and / or an update of a database are stored in a centralized database and / or directly in the decentralized or distributed blockchain.
  • a database is selected from the group comprising a NAVDB Navigation database, a MAGVAR magnetic declination database, a PERFDB performance database, an AOF airport database, a TAWS terrain and / or obstacle database, a WXR meteorological database, a GNSS satellite constellation database, or an ATC air sector database.
  • database data is non-avionic data, originating from open sources, comprising in particular data from the AISD perimeter, data originating from electronic flight bags or EFB, data originating from cabin systems or IFE, and / or data from ground systems.
  • a blockchain is public, with admission and / or participation criteria such as validation by proof of work.
  • the blockchain is private (all devices are known beforehand, and a new device must register for example with an air traffic regulatory authority). In one embodiment, the blockchain is public and new devices can register on an admission test.
  • a computer program product comprising code instructions making it possible to perform one or more steps of the method, when said program is executed on a computer.
  • a system is described for the management of updates of aeronautical databases: at least one chain of blocks, said chain of blocks being configured to execute or several smart contracts; - said one or more intelligent contracts being configured to validate all or part of a database, or of an update of said database, by consensus distributed among the parties associated with the blockchain, said parties being associated with one or more aeronautical computers, in particular FMS flight management systems.
  • an aircraft or drone is equipped with a module for communication and collaborative sharing of data originating from the computers on board the aircraft.
  • This hardware module can relate to various users (consumers) and / or suppliers (producers) of data.
  • Avionics equipment can interact (two-way communication) with non-avionics equipment.
  • communications can be one-sided (from avionics to non-avionics equipment, but not the other way around, i.e. to avoid the injection of erroneous or malicious data from the open world to the certified avionics world).
  • FMS flight management systems can be networked together, also with EFBs.
  • system further comprises a centralized database and / or a so-called secondary block chain comprising aeronautical data, said data being referenced or indexed in the so-called main private block chain.
  • FIG.1 illustrates the operation of a chain of blocks.
  • a "blockchain” or a “distributed ledger” is a database distributed and secured by crypto graphics techniques.
  • the transactions exchanged are grouped into “blocks” at regular time intervals, in a cryptographically secure manner, which blocks form a chain.
  • a new block is generated and analyzed. If the block is valid (distributed consensus), the block can be time stamped and added to the blockchain.
  • Each block is linked to the previous one by a hash key. Once added to the blockchain, a block cannot be edited or deleted again, ensuring the authenticity and security of the network.
  • Chaining uses hash functions and Merkle trees.
  • a hash tree is made up of a set of interrelated checksums. Checksums are concatenated according to a tree structure. A hash tree makes it possible to verify the integrity of a set of data without necessarily having all the data available at the time of the verification. Records in a blockchain are protected from tampering or modification by storage nodes: tamper block requires tampering with the entire chain, so the total cost becomes prohibitive and ensures a level of confidence in the non-tampering of the entire blockchain. Transactions are visible throughout the network (except “pruning”).
  • Time is an important factor for blockchains (notions of broadcasting, propagation, latency, etc.).
  • the distributed consensus of all the nodes of the network can take a very variable time depending on the technologies used. It can be accelerated using various techniques, including "sidechains", which also increase storage capacities.
  • proof of work In the context of distributed consensus, a blockchain can use validation by proof of work ("proof of work”). From a mathematical point of view, proof of work is "difficult to provide but easy to validate”. Proof validation systems are generally asymmetric: the calculation that is required in return for a service request is costly for the requester but remains easily verified by a third party. Different techniques can be used, including hashcash or a "client-puzzle”.
  • Minor nodes are entities whose role is to supply the network with computing power, to allow updating of the decentralized database. These minors can be remunerated by the distribution of crypto graphic tokens ("tokens"). Other compensation methods (in addition or by substitution) provide for commissions on transactions. “Miners” are not always necessary: in the case of private blockchains, for example, the participants in the blockchain maintain the distributed database themselves.
  • a blockchain can be public or private, or according to intermediary governance, which can use different barriers to entry (validation by proof of work).
  • a “public” blockchain works without a trusted third party (so-called “trustless” model), generally with complex proof-of-work validation (e.g. hashcash).
  • a public blockchain does not generally define any rule other than that of the code constituted by the protocol and software technology that composes it.
  • a “private” blockchain consists of consensus participating nodes that are defined in advance and then authenticated. Its operating rules may possibly be extrinsic.
  • Blockchains can be or become programmable through the use of “smart contracts”.
  • Smart contracts are computer software or protocols that facilitate, verify and execute the negotiation or execution of a contract. They aim to emulate or approach the logic of contractual clauses (contract law). Smart contracts are not strictly equivalent to contractual agreements. They help to make the violation an expensive deal because they control a good through digital means. They may or may not provide for the intervention of third parties to the contract to monitor its execution (for example machines or "oracles" or oracle services.
  • a smart contract is software code that is stored and is executed on / by a blockchain and is triggered by external data which allows it to modify other data, in the blockchain or elsewhere.
  • the execution of a smart contract is predictable / predictable; at the very least the code and therefore the nature of the calculations or tests carried out by this code are known.
  • the code of a smart contract is stored on or in the blockchain; the execution of the intelligent contract is carried out during the validation of the blocks (the computational resources are distributed, which means that the execution of a smart contract is safe in itself: the code of the smart contract is replicated in several nodes of the architecture implementing the blockchain, being deterministic, the results of the different executions must be identical, therefore the code as well as the execution of the code are safe.
  • smart contracts can be diverse (e.g services, agents, snippets, scripts, SOA, API, add-ons, plug-ins, extensions, DLC, etc.).
  • Mathematical logic (decision-making operating on data) can be that of classical logic, fuzzy, combinatorial, intuitionist, modal, propositional, partial, para-consistent, etc. or a combination of these logics.
  • the software can be coded in part or in whole in hardware form (e.g. FPGA).
  • a smart contract can be in whole or in part open source (“open source”) and / or closed source (“closed source”).
  • a smart contract can combine open source parts (e.g. auditable, verifiable, improvable, etc.) with closed parts (proprietary, secret, sensitive, etc.).
  • a closed source can be binary, possibly obfuscated or hardened.
  • Cryptographic techniques can be diverse: symmetric, asymmetric, “post-quantum”, “quantum-safe”, with use of “Quantum-Key-Distribution”, etc.).
  • a smart contract can be human and / or machine readable.
  • the [fig.l] shows 4 data blocks B1 to B4 (101, 102, 103, 104).
  • the hash tree is made up of a set of interrelated hash values.
  • the leaves of the tree are the hash values of each of the initial data blocks (111, 112, 113, 114).
  • these hash values are then concatenated two by two in order to be able to calculate a new parent hash (121, 122). So on until the top of the tree where we get a hash-top (131).
  • hash-top (131) only the hash-top (131) must be safely retrieved to guarantee the integrity of all the data represented by the tree. For example, if we want to verify the integrity of block B2, we just need to have retrieved the 0-0 hash (his brother 111), the hashl (his uncle 122) and the hash-top (131).
  • a data block can include one or more codes or programs or smart contracts 140.
  • a smart contract 140 can implement one or more mechanisms: (a) access to data or parts of data (including on flight plans): -i) management of access rights and sharing of encryption keys (in the case of asymmetric encryption the private key is secret and known only to the user or the public key can be known to a register) ; hardware encryption mechanisms can be used (TPM or HSM, smart card, etc.); ii) subscription per unit of time (daily, weekly, monthly, annual, etc.) and / or by data volume (e.g. per MB bytes of data downloaded); credit or point systems can be used; b) payment; transactions can be settled in unit of account (cryptocurrency or fiat currency e.g. USD or EUR);
  • the data blocks (101, 102, 103, 104) are produced and then consumed, i.e. accessed, in reading and / or writing, by parties or companies (e.g. illustrated by 151, 152, 153).
  • a party or company or consumer can be the manufacturer of the aircraft, a supplier, an equipment manufacturer, a customer or an airline, a company providing meteorological data, a regulatory authority, etc.
  • a party may be a "producer” of data and / or a "consumer” of data.
  • a data consumer can be referred to as a “customer” or “requester” or “recipient” hereafter.
  • a producer can be referred to as “sender” or “server” or “supplier” hereafter.
  • the expression “and / or” emphasizes the fact that production and consumption can be successive or alternative, or even simultaneous.
  • each party can buy and / or sell, license and / or grant a license, assign or give or share data of its own, it can also access data shared by the other parties. Sharing data allows you to create other data, some of which may be of technical or other value.
  • air traffic control authorities 152 can produce and consume data.
  • the data can in particular relate to flight plans and / or their associated certificates, NOTAM notifications, various alerts, routing statistics. or on flight plans etc.
  • a first layer of metadata or chain of blocks 100 inheriting the properties inherent in a blockchain (e.g. integrity, tamper-proofing, etc.); blockchain 100 is essential, other levels are optional.
  • the blockchain is essential in that it can contain “everything” (here flight plan data, metadata, third-party databases, etc.) but it can be lightened, in particular by deporting non-critical or large data.
  • secondary databases also in the form of a chain of blocks (“sidechains”), or not ie without the use of a chain of blocks; a second layer of data (not shown) called or referenced by the blockchain 100 (partially or fully encrypted).
  • flight plans can be stored in the database in different formats (.txt, .doc, .rtf, .xml, .json, etc.).
  • the data can also include upload, download, usage metrics, etc. which in turn can determine scores or other quantifications (using logical decision circuits e.g. computers); a third layer of coordination or regulation between actors (who in turn play the roles of producer or consumer, reading and / or writing on blockchain 100.
  • Agreements between participants in the blockchain can be written contracts (outside technical), or even partially - or in full - transcribed via smart contracts of type 140; a fourth optional layer can finally regulate the smart contracts themselves (linked contracts, independent contracts, framework contract modifying other contracts in downstream, or conversely upstream, multiple feedback loops between contracts, feedforward, etc.)
  • the entity 140 can represent or be associated with one or more validators (or “oracles”, which can correspond to a human and / or machine independent validation (ie algorithmically encoded).
  • the chain of blocks 100 of data is public.
  • it is possible to implement validation by proof of work (“proof-of-work” or PoW e.g. hashcash or variant).
  • the chain of data blocks is private: each participant is previously approved (by contract or agreement and technically has keys or means of authentication. Validation by proof of stake »Or PoS) is then possible.
  • a main blockchain may contain metadata relating to flight plan data (i.e. including the hash values of the data), while a secondary string can contain the data itself.
  • the method uses one or more "smart contracts”. Data can be shared over a blockchain to ensure timestamp and immutability.
  • a consumer's intended use of a block's flight plan data is governed (directly or indirectly through rules) by a smart contract.
  • all the data of the blocks are written in clear (e.g. the access rights are protected). In one embodiment, part of the data is written in clear (some information is readable by everyone, other information with higher added value is protected, for example by encryption). In one embodiment, the data of the blocks is encrypted (e.g. symmetric, asymmetric, etc.). In some cases the data in the blocks is masked in addition to being encrypted (the existence of the data is hidden, which provides additional protection).
  • the data is stored in one or more shared databases, encrypted in whole or in part, after verification of their integrity and of the authenticity of the producer.
  • the validation of the data produced is carried out by distributed consensus (eg use validated with a score of "relevance" by several consumers, measurement and monitoring of the rate of use, etc.) and / or by va lidation of a peer participating in the blockchain recognized as reliable in the chain (technical or administrative qualification).
  • distributed consensus eg use validated with a score of "relevance” by several consumers, measurement and monitoring of the rate of use, etc.
  • va lidation of a peer participating in the blockchain recognized as reliable in the chain (technical or administrative qualification).
  • some information (such as the format and / or the summary of the content of the encrypted block is left unencrypted in a storage space (in the chain or outside the chain), so that a interested consumer can know if the block interests him or not.
  • the rights to the block data can be conditional on contribution criteria (in particular the upload / download ratio in English “upload / download” or “seed / leech”).
  • access to the data or the rights to this data can be governed conditionally (for example if the balance of a customer or requestor or Value Score is positive).
  • the executed smart contract can issue a transaction or data recovery request, which transaction will be inserted (among several others) in a new block. If the distributed consensus confirms the block comprising the transaction, an encryption key allowing the desired reading of the data can be sent to the client; who can read and use the desired data.
  • a plurality of actors share data, eg flight plans, and store the hash values of the data, as well as information relating to the format of the data, in one or more blockchains.
  • one or more smart contracts verify the requester's value "score", indicate the position of the data in the shared database, and the data decryption keys.
  • the block chain does not contain the flight plan data per se but only the description which is made of this data (the data is stored in secondary chains or a database. centralized ojf-chain data).
  • This embodiment is advantageous in that the data replicated in the main blockchain is significantly smaller.
  • an aircraft or drone can, for example in turn, publish information intended for other members of the network or else "s 'subscribe' to the network, for example via a smart contract, and receive information about it automatically.
  • an aircraft can share its flight plan information securely and with integrity with other aircraft (owned by other airlines, specifically).
  • the subscription methods can include push and / or pull modes, unsubscribe, etc.
  • each aircraft is able to determine intersections or collision risks: the traffic regulates itself. Certain devices which do not have sufficient calculation means can emit signals warning of their defect or absence of temporary or permanent verification.
  • an intelligent contract can read block data in clear and trigger one or more operations, for example if the client or requester or consumer is validly subscribed to the data type of the block considered or if conditions predefined are satisfied.
  • an intermediary is added (external validation): a data validator (not shown), typically a computer for the air traffic regulation authority.
  • a source decides to publish data in the blockchain (directly or indirectly via the database).
  • the data is sent with an identifier (which identifies the source of sending data) and a summary of the content (eg parameters, units, quantity, format, etc.) as well as the date of the data (eg creation, validity, etc)
  • This set forms a "block" to validate.
  • the validation subsystem receives the data. Validation is performed either by consensus or by an external and “trusted” “validator”: other providers or users verify the integrity of the data (and optionally the authenticity of the issuer).
  • the third party validator is “internalized”: the verifications are carried out directly and automatically by one or more smart contracts.
  • one or more smart contracts can perform various tasks, in particular a) check if the producer is declared (if it is a party to the consortium or blockchain); b) modify the SV score of the source c) rate or evaluate the data entered (directly or indirectly); possibly d) directly perform functional verifications on the data (for example, data from a model X aircraft can be correlated / crossed with other sources of information on the aircraft (eg public or private sources of company, air traffic control) emitted in real time and corresponding to the state of the aircraft (eg take-off time, current status eg in flight, on the ground, in cruise, current position, etc.); in particular, the Operator / flight plan / aircraft / pilot quadruplet check sequence can be implemented by one or more smart contracts.
  • a consumer can subscribe or express an interest in retrieving data (eg transaction order directly on the blockchain or via a smart contract or contract).
  • the contract telligent concerned can check if the requestor has sufficient balance (VS) to download the data.
  • the purchased block is made available to one or more human validators and / or machines which perform this verification. If the transaction is valid, the data set (for example encrypted) is transmitted to the requestor, who may for example have the possibility of verifying its integrity (hash value retrieved from the blockchain). If the dataset is determined or deemed valid, decryption keys (stored in the blockchain) are retrieved by the smart contract and passed to the requestor. The transaction is then written into the blockchain by the smart contract.
  • compensation and / or evaluation and / or reward and / or validation mechanisms can be implemented if the data is determined to be valid (rating and / or reputation mechanism to identify or pay the most "useful" data issuers (concept relating to one or more objectives that can be objectified and internalized).
  • the requester ie the initiator of the transaction can for example import the data obtained and combine them or integrate them with existing data in the aim of carrying out a “Big Data” type processing by artificial intelligence techniques (in particular machine learning).
  • FIG.2 illustrates examples of steps of one embodiment of the invention.
  • the figure shows examples of database exchanges between a producer
  • the method for updating one or more databases of an aircraft comprises different steps.
  • a database producer or supplier 210 communicates one or more databases, to be updated or deployed (download and install).
  • the centralized database 240 and / or the chain of blocks 100 is enriched with all or part of the new updated data.
  • the producer publishes on the blockchain the provision of the new data in a new block.
  • a validation node verifies the integrity of the proposed block and makes it available in the blockchain 230.
  • a consumer aircraft 220 makes a request for data from the blockchain (e.g. an intelligent contract). The updates are retrieved directly from the centralized database 240 and / or via the blockchain 100.
  • the sharing and / or validation mechanism can be encoded in one or more smart contracts.
  • the sharing module can control communications between various users and / or data providers (social graph control). This module can be encoded by smart contract.
  • the system according to the invention comprises a module for validating and / or sharing (collaborative / cooperative) data, in particular originating from the computers on board the aircraft, which module is configured to measure, qualify, quantify, evaluate, simulate, calculate or otherwise manipulate these databases.
  • One or more smart contracts 240 can control the updates.
  • the tests described above can be internalized by these intelligent contracts (eg management of confirmations or manual information from the pilot, tests on the PERFDB via communications with wind tunnel tests on the ground, tests via modeling, corrections by constants or according to linear functions.).
  • Smart contracts can perform various actions, including validating 230 one or more blocks. Validation can be performed by distributed consensus, for example by applying one or more tests to the data concerned (eg integrity, absence of malicious code, systemic consistency or consistency, i.e. compatibility of additions or withdrawals, etc.) .
  • Smart contracts can manage access, read and / or write rights to databases.
  • flight procedure data for example, the "quality" of aircraft and / or crew members may be taken into account.
  • Performance databases can be (for example exclusively) managed by OEMs, or aircraft manufacturers or aerodynamicists.
  • Field databases or MAGVAR can be handled by geologists or institutions (e.g. National Institute for Geographic and Forest Information). In one embodiment, these entities can be finely integrated into the validation process and validate in real time, or in quasi real time / just in time, the modifications made to the databases.
  • air navigation control authorities can control the flow of data (e.g. prioritize, censor, authorize, confirm, invalidate, corroborate, modify, alter, enrich, cross-reference, etc.).
  • a smart contract can ensure equal treatment between contributors.
  • Running a smart contract can be triggered automatically (eg Oracle). It can read data external or internal to the blockchain, and trigger the performance of predefined actions if the previously coded conditions are met (for example if its balance (Value Score) is positive if applicable, the smart contract can issue a data recovery request, which request can lead to the creation of a new block in the chain of blocks, it is also possible to cause the communication of a decryption key for the requested block.
  • a smart contract can be triggered automatically (eg Oracle). It can read data external or internal to the blockchain, and trigger the performance of predefined actions if the previously coded conditions are met (for example if its balance (Value Score) is positive if applicable, the smart contract can issue a data recovery request, which request can lead to the creation of a new block in the chain of blocks, it is also possible to cause the communication of a decryption key for the requested block.
  • the data can be stored directly on the blockchain 100 and / or on the centralized database 240. In other words, in one embodiment, all of the data can be stored directly. on the blockchain. In one embodiment, all of the data can be stored directly on the centralized database 240. In other embodiments, the data is stored partly in the blockchain 100 and partly in the database. centralized data 240.
  • the data can be stored in a centralized and shared database 140.
  • This database can be encrypted, for example after verifying the integrity and / or the authenticity of the producer.
  • a block of the block chain 100 can contain data added or modified or deleted or replaced from the block chain 100 and / or from the centralized database 240.
  • the method according to the invention comprises a step consisting in validating all or part of a database used by the aeronautical computers (or by a multitude of actors interested in their updates) .
  • state organizations can help validate updates to the MAGVAR database.
  • Data providers can help validate datasets, whether or not they are associated with service offers (e.g. analyzes, alerts, crossovers, enrichments, etc.).
  • the validation of the data produced can be done by consensus (use validated with a score of "relevance" by several consumers, rate of use) or by validation of one or more actors recognized as reliable in the blockchain.
  • Some information like the format and the summary of the contents of the block (ie encrypted data) can be left in clear in a storage space (in the chain or outside the chain), so that an interested consumer or aircraft can know whether he is interested in the block or not.
  • the traceability of the exchanges can be determined.
  • Data exchanges can be time-stamped and / or verified by distributed consensus, for example via va- lidation dependent on the "quality" of the actors. This quality can be quantified in various ways, static (or even predefined) or dynamic (reputation score, reliability index, etc.).
  • all the data can be stored in clear.
  • the data can be encrypted (for example according to post quantum encryption).
  • the data produced can also be masked or hidden (steganography, masking, concealment, etc.).
  • an aircraft can "subscribe" to one or more data channels (RSS, NOTAM, or others), acting as Oracle.
  • This aircraft can for example receive information concerning it automatically (e.g. meteorology, air traffic, diversion, etc.).
  • the value of an update is a function (eg sum, analytical function, parametric, calculable by algorithm) of the extrinsic value of the data (that of the database producer) and of the intrinsic value of the data ( objectified via logical tests, simulations, references to these compatibility lists, etc.).
  • a function eg sum, analytical function, parametric, calculable by algorithm
  • reliability scores are manipulated as a function of data download and / or upload histories, from a quantitative (active suppliers) and / or qualitative (eg data quality) point of view, reliability, accuracy, or on the contrary erroneous or even malicious data). Through the management of these clues, malicious actors can be excluded, others re-compensated, etc.
  • a member of the network can be assigned a value score (Value Score, acronym VS) to enable him to participate in the exchanges (as a producer and / or consumer of data).
  • This VS score can be a function of the value of the information it produces VS_PROD and the value of the information it consumes VS_CONS.
  • the VS value can be expressed as a score, a cryptocurrency, a real currency.
  • the SV can be modified by cash payments, so that a requestor obtains the right to consume, which can for example be useful if he consumes more data than he needs. product.
  • a node or actor can in turn transform its VS into fiat currency or cryptocurrency.
  • the VS score is caused to change as a function of the attractiveness of the data produced (number of subscribers for example, or number of downloads, or quantities of downloads), of the value of the data. he consumes, and purchases / sales in the monetized alternative.
  • the VS_PRED and VS_CONS values can be calculated in several ways, for example in quantity (eg in Megabyte), in quality (eg as a function of the criticality of the calculator or of the on-board function concerned), by consensus on a price ( proposal by a consumer, validation by the producer or proposal by a producer vs. acceptance / rejection by a consumer, or negotiation), depending on the history of use, the daily price, the a priori setting of min limits / max, a priori consensus on the values of the different data between actors, etc.
  • quantity eg in Megabyte
  • quality eg as a function of the criticality of the calculator or of the on-board function concerned
  • consensus on a price proposal by a consumer, validation by the producer or proposal by a producer vs. acceptance / rejection by a consumer, or negotiation
  • the daily price the a priori setting of min limits / max
  • a priori consensus on the values of the different data between actors etc.
  • the value of the update of a database can be determined as a function of the difficulty of producing the datum of the database.
  • the publication and validation of a procedure can have a different value depending on whether the procedure will be frequently used subsequently by the other actors. But the value can also depend on the criticality of the procedure; for example an approach requiring a high navigation performance (“Low RNP” for Low Required Navigation Procedure) may have a higher value than a traditional procedure having less precision needs.
  • the content that is updated is the structure of the procedure in standardized and shared format for example (Arinc 424, Arinc 816).
  • the value can be linked to the rarity of the published point (lightly crossed air routes).
  • the updated content is the magnetic declination at the geographical point considered (latitude / longitude), by use of on-board sensors (eg GPS, inertial units, magnetometers, etc.).
  • on-board sensors eg GPS, inertial units, magnetometers, etc.
  • the value can be linked to the criticality of the modification in relation to the risk of collision: presence of cranes near an approach axis of an airport for example, change of seat 'obstacles, etc.
  • the value can also be linked to the presence of artefacts in the terrain database (eg errors in the base, real altitude different from the encoded altitude, fineness of the mesh of the updated base, etc.).
  • the value may be greater around take-off and landing areas compared to overflight areas.
  • the updated content is a terrain / obstacle elevation for a given point (latitude / longitude).
  • latitude / longitude For an obstacle, its type can also be updated, as well as geometric data (radius, thickness, etc.).
  • the content can be the measurement of winds and temperatures at a given point in space (latitude / longitude / altitude); it can be the presence of convections (cloudy polygon in 3D), etc.
  • the value may depend on the performance that the weather phenomenon can generate (eg fuel savings for strong tailwinds for example, risks of comfort for areas of turbulence, etc.). Since the data is more scalable, the value can be linked to the freshness of the latter (eg hour publication of the data).
  • the value of an update can also be converted into real currency, or into tax relief or some other benefit.
  • the validation of a flight procedure linked to an airport can result in a reduction in landing fees for the company which is at the origin of the validation, on this basis. airport. It can also translate into advantages in take-off / landing slots, priority over flights over busy air routes. Any combination of these calculation methods is possible.
  • the methods for calculating these values are written into a smart contract.
  • the contract can be bipartite (agreement between 2 actors) or multipartite (agreement between 1..N suppliers and 1..M consumers).
  • a "provisioning" smart contract detects new data stores metadata in a blockchain (identification, date, sender, score, hash of data content); during retrieval, a smart contract for the “consumption” of data is triggered, verifies the value score of the potential buyer, verifies (option) the reality, value or integrity of the data “ provision ”, downloads it and sends it to the requesting aircraft.
  • the smart contract can also send the information of the corresponding block of the blockchain, and the hash of the data content (which allows the requesting aircraft to verify the integrity of the data).
  • the database-producing suppliers fill a shared database and store the “hashes” (hash function, e.g. CRC) of the data, as well as the time-stamped data in a chain of blocks; during a request or request, a smart contract is triggered to check the value score of the consumer and / or producer, and indicates the position of the data in the shared database (or in the blockchain, with the keys decryption). To avoid key sharing between aircraft or collusion, a smart contract can re-encrypt the data. Different DRM mechanisms can be implemented (e.g. number of uses capped, validity period, etc.).
  • the blockchain contains in real time the VS score for each actor in the network: when the score of an actor is updated, the blockchain is also updated, G use of the blockchain allows to have this training distributed on several nodes and therefore to make it immutable and secure (as well as to have a certain history). So when a supplier publishes a dataset (in the database or in a block of the blockchain depending on the alternatives), its VS, a timestamp are added (directly by the sender or via a smart contract). (timestamp), and a means of identifying the source (ID) and a means of validating the integrity of the dataset (hash of the dataset).
  • three actors separate the roles: the producers of database updates (for example a meteorological data supplier or an airport data supplier (CCI, CFMU, Eurocontrol, etc.) ), update consumers (eg aircraft, airlines) and data validation entities (eg control authorities, ATC, airlines) An exemplary embodiment is described below.
  • database updates for example a meteorological data supplier or an airport data supplier (CCI, CFMU, Eurocontrol, etc.
  • update consumers eg aircraft, airlines
  • data validation entities eg control authorities, ATC, airlines
  • a provider decides to publish its update of a database in the blockchain.
  • the data is sent with an identifier that identifies the source of sending the data, and a summary of the content (parameters, units, quantity, format) and date.
  • This set forms a "block" to be validated.
  • For a procedure update of a navigation database several tests are generally necessary, depending on the categories of device (heavy, medium, light), the performances must therefore be validated by device class.
  • the data is received and tests are carried out: the validation is performed either by consensus or by a trusted “validator”: other suppliers or users of the nodes verify the integrity of the. data (and optionally the authenticity of the transmitter).
  • the blockchain can be updated with a drop in VS_PROD by a certain amount for the producer, and an increase in VS_PROD for the one who detected the anomaly. If the data is considered healthy, then a new block is created, which contains the link to the data, and an increase in VS_PROD by some amount for the valid node ur.
  • integrity checks are performed directly and automatically by a smart contract: at each new entry into the database (and attempt to write a block), a contract can check: a) whether the producer is declared (if it is a consortium chain); b) include his VS score in the assessment of his integrity; c) to include his “mark” in this same evaluation; d) perform functional checks on the data (eg data from a given aircraft can be correlated / crossed with other sources of information on the aircraft (eg public or private sources from the company, from air traffic control). ..) emitted in real time and corresponding to the state of the aircraft (take-off time, status (in flight, on the ground, in cruise, etc.), current position.
  • a smart contract can check: a) whether the producer is declared (if it is a consortium chain); b) include his VS score in the assessment of his integrity; c) to include his “mark” in this same evaluation; d) perform functional checks on the data (eg data from a given aircraft can be correlated / crossed with
  • a consumer can subscribe or express an interest in retrieving data (request or request on the blockchain, or intelligent contract).
  • a smart contract checks whether the buyer has the means (VS) to download the data; alternatively, the purchase block is made available to validators who perform this verification. If the transaction is valid, the (encrypted) dataset is transmitted to the requestor who has the possibility to verify its integrity (hash retrieved from the blockchain). If the dataset is deemed valid, decryption keys (stored in the blockchain) are retrieved by the contract and passed to the requester. The transaction is written to the blockchain by the smart contract.
  • the method according to the invention includes a payment and validation mechanism when the information is considered valid.
  • the method according to the invention includes a rating mechanism to reward the most useful data transmitters.
  • a number of actors can integrate the new data with existing data with the aim of performing "Big Data” processing by artificial intelligence techniques.
  • the analyzes which are then performed on the consolidated data are shared (or not).
  • the time stamping is performed by writing to a chain of blocks, which writes the block when it is produced by the transmitter, the block comprising at least the date of provision, the authentication of the sender, and the identification of the data as well as its location.
  • a score is assigned to the issuer of a database update depending on the update date and the quality of the validation of the issuer.
  • the present invention can be implemented from hardware and / or software elements. It may be available as a computer program product on computer readable media.
  • the computer can be a rack or a tablet or an EFB (electronic flight bag) or a software part integrated into the FMS (flight management system), etc.
  • the medium can be electronic, magnetic, optical, or electromagnetic.
  • the embodiments of the invention can be implemented by computer.
  • Peer-to-peer, fully or partially distributed (center existences) servers can interact.
  • a blockchain is based on a decentralized architecture, which can be more or less distributed.
  • a blockchain implementation does not preclude the existence of one or more privileged nodes, whether it is private cloud or private blockchain.
  • Access can be cross-platform (e.g. from EFB, WebApp, ground access, etc.).

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Human Resources & Organizations (AREA)
  • Strategic Management (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Economics (AREA)
  • Tourism & Hospitality (AREA)
  • Theoretical Computer Science (AREA)
  • Marketing (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Operations Research (AREA)
  • Quality & Reliability (AREA)
  • Development Economics (AREA)
  • Data Mining & Analysis (AREA)
  • Game Theory and Decision Science (AREA)
  • Educational Administration (AREA)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Primary Health Care (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Storage Device Security (AREA)

Abstract

Le document concerne des systèmes et des procédés pour la gestion de bases de données aéronautiques, comprenant les étapes consistant à : maintenir une chaîne de blocs; ladite chaine de blocs comprenant un ou plusieurs contrats intelligents; un contrat intelligent gouvernant la gestion d'une ou de plusieurs bases de données. valider tout ou partie d'une base de données, ou d'une mise à jour de ladite base de données, par consensus distribué parmi les parties associées à la chaine de blocs, lesdites parties étant associées à un ou plusieurs calculateurs aéronautiques, notamment des systèmes de gestion de vol FMS. Des développements décrivent notamment l'utilisation de correctifs, de contrats intelligents, de scores (notamment de fiabilité), l'obsolescence des données ou de bases de données avioniques. Des aspects de logiciel sont décrits.

Description

Description
Titre de l'invention : MANIPULATIONS DE BASES DE DONNEES PAR REGISTRES DISTRIBUES Domaine de l’invention
[0001] Le document décrit des procédés et des dispositifs dans le domaine technique de l’avionique, et en particulier des bases de données distribuées.
Etat de la Technique
[0002] L’État de la technique repose généralement sur des bases de données centralisées, contrôlée par un ou plusieurs acteurs. Ces bases de données sont mises à jour par un acteur privilégié, validées ensuite par chaque acteur qui G utilise, sans partage, ni mesure de qualité.
[0003] Dans le domaine avionique, le partage de données n’est pas la règle. La concentration des données générées par un seul acteur (intermédiaire) est parfois nécessaire mais le manque de réciprocité est souvent néfaste en ce qu’il ne permet pas un traitement égalitaire entre les fournisseurs et utilisateurs, les rôles des uns et des autres pouvant d’ailleurs être échangé.
[0004] Dans des environnements de travail de plus en plus complexe, il existe un intérêt majeur à une mise en commun des données : les analyses de données tirent profit d’une consolidation de ces données, à laquelle poussent notamment les approches Big Data contemporaines et la connectivité accrue entre systèmes embarqués et au sol.
[0005] Plus généralement, il existe un intérêt pour le partage d’informations brutes issues de calculateurs aéronautiques dans une communauté de fournisseurs de calculateurs, de créateurs de données, ou d’utilisateurs (ou consommateurs) de données de ces cal culateurs, afin d’améliorer les mises à jours de données aéronautiques, tant en matière de « fraîcheur » que d’intégrité des informations qui sont transmises.
[0006] Dans le secteur aéronautique, les acteurs (créateurs/valideurs ou producteurs/ consommateurs) de données peuvent être variés. Une liste non exhaustive de ces acteurs comprend notamment des fournisseurs de calculateurs, des avionneurs, des concepteurs de bases de données d’aérodynamique, des motoristes, des organisations étatiques (concepteurs de procédures de navigation), des chercheurs, des géologues, des concepteurs des modèles de déclinaison magnétique du globe, des compagnies aériennes, ou des météorologistes.
[0007] Parvenir à faire coopérer ces acteurs est tâche complexe. Les problèmes techniques qui se posent sont nombreux et peuvent notamment se formuler comme suit. Comment inciter les acteurs précédemment mentionnés à participer à une mise à jour coopérative des bases de données aéronautiques ? Comment structurer techniquement les échanges ? Comment assurer une rétribution juste et certaine de ces acteurs pour leur contribution ?
[0008] La littérature brevet adresse peu ou mal ces préoccupations. Le document de brevet EP3367137 intitulé “ Systems and methods of gathering and distributing critical weather event information “ décrit par exemple un système de partage d’informations de météorologie critique entre plusieurs avions. Un serveur au sol agissant en tant qu’intermédiaire est chargé de gérer les demandes entre les différents avions (à la fois fournisseurs et consommateurs de données). Cette approche présente des limitations (e.g. centralisation, connectivité, intégrité et pertinents et données, etc).
Résumé de l'invention
[0009] Le document concerne des systèmes et des procédés pour la gestion de bases de données aéronautiques, comprenant les étapes consistant à : maintenir une chaîne de blocs; ladite chaîne de blocs comprenant un ou plusieurs contrats intelligents ; un contrat intelligent gouvernant la gestion d’une ou de plusieurs bases de données valider tout ou partie d’une base de données, ou d’une mise à jour de ladite base de données, par consensus distribué parmi les parties associées à la chaîne de blocs, lesdites parties étant associées à un ou plusieurs calculateurs aéronautiques, notamment des systèmes de gestion de vol FMS. Des développements décrivent notamment G utilisation de correctifs, de contrats intelligents, de scores (notamment de fiabilité), l’obsolescence des données ou de bases de données avioniques. Des aspects de logiciel sont décrits.
[0010] Avantageusement, les modes de réalisation de l’invention permettent d’améliorer sur le fond les bases de données aéronautiques.
[0011] Avantageusement, les modes de réalisation de l’invention permettent de faire émerger des services à valeur ajoutée pour les opérations aériennes (e.g. estimation des retards, des surconsommations, optimisation des trajectoires, anticipation des flux, de la météorologie, la gestion des flottes « dispatch » etc).
[0012] Avantageusement, les modes de réalisation de l’invention permettent d’améliorer la sûreté aéronautique, ainsi que la sécurité des vols, par analyse des flux et détection anticipée d’anomalies difficilement prédictibles a priori.
[0013] Avantageusement, les modes de réalisation de l’invention permettent d’améliorer la gestion de mission d’un aéronef lorsque de nombreux appareils sont engagés dans l’espace (e.g. avions, drones, etc).
[0014] Avantageusement, les modes de réalisation de l’invention permettent de manipuler des données issues de plusieurs calculateurs, de divers fournisseurs. L’invention permet notamment de dépasser le cadre contractuel et technique classique « bipartite ». L’invention permet de gérer la variabilité, l’évolution rapide des acteurs et/ou des données
[0015] Avantageusement, les modes de réalisation de l’invention permettent un traitement global, quasiment en temps réel, des données entre les acteurs.
[0016] Avantageusement, les procédés et les systèmes de validation d’informations de bases de données selon l’invention permettent d’assurer une transmission fluide des données (actualisées et intègres) des calculateurs vers les utilisateurs. Par construction, le partage peut être quantifié (les échanges sont traçables).
[0017] Avantageusement, les modes de réalisation selon l’invention améliorent le partage d’informations brutes issues de calculateurs aéronautiques dans une communauté de fournisseurs de calculateurs ou d’utilisateurs de ces calculateurs, afin d’en tirer des in firmations enrichies ayant une valeur, tout en assurant l’intégrité des informations qui sont transmises et l’égalité de traitement entre les acteurs (juste rétribution de celui qui met à disposition la donnée).
[0018] Avantageusement, G utilisation de mécanismes d’échanges horodatés et vérifiés par consensus (via des règles de validation dépendant de la qualité des aéronefs et membres d’équipage pour valider des modifications en temps réel de bases de données) permettent d’assurer le même niveau d’intégrité que les processus classiques, et au partage de ces bases en temps réel.
Description des figures
[0019] D’autres caractéristiques et avantages de l’invention apparaîtront à l’aide de la des cription qui suit et des figures des dessins annexés dans lesquels:
[0020] [fig.l] illustre le fonctionnement d’une chaîne de blocs;
[0021] [fig-2] illustre des exemples d’étapes d’un mode de réalisation selon l’invention.
Description détaillée de P invention
[0022] Selon les modes de réalisation de l’invention, un « mobile » ou « aéronef » peut être un drone, ou un avion commercial, ou un avion de fret, ou bien encore un hélicoptère, embarquant ou non des passagers. Le mobile peut piloté, télé-piloté ou autonome ; tel qu’un aéronef (avion, hélicoptère, ou tout autre appareil soumis aux lois de l’aéronautique). Dans d’autres modes de réalisation, le mobile peut être terrestre, de surface (e.g. bateau), submersible (sous-marin), orbitale (satellite), etc. Plus géné ralement, le terme « aéronef » dans la description ci-après peut être remplacé par les termes de véhicule, voiture, camion, bus, train, moto, bateau, robot, sous-marin, jouet, etc. ou tout élément étant susceptible d’être télé-piloté (par liaison radio, satellite, ou autre), au moins partiellement (de manière intermittente, ou périodique, ou même op portuniste au cours du temps).
[0023] Les calculateurs embarqués dans un aéronef utilisent massivement un grand nombre de bases de données pour effectuer leurs tâches. Plusieurs de ces bases de données sont décrites ci-après (liste non exhaustive).
[0024] Bases de données de Navigation
[0025] Ces bases de données dites « NAVDB » sont utilisés par les calculateurs embarqués (FMS pour « Flight Management System »), afin de construire les plans de vol des aéronefs. Au standard international AEEC ARINC 424, ces bases contiennent et dé terminent notamment la structuration des routes aériennes et des procédures de décollage et atterrissage pour tous les types d’aéronef, notamment les aéroports et pistes associées en 2D, 3D ; les points de passage en 2D ou 3D, les procédures stan dardisées de décollage (« SID ») et d’atterrissage « STAR », « VIA », « APP », les routes aériennes « Airways », les balises de radionavigation en 2D/3D avec leur fréquence et leur type : « VOR », « DME », « T AC AN », etc.
[0026] Bases de données de déclinaison magnétique
[0027] Cette base de données mondiale dite « MAGVAR » contient les corrections de dé clinaison magnétique. Elle est fournie par exemple par l’administration américaine (« National Oceanic and Atmosphéric Administration », acronyme NOAA). Elle modélise le globe terrestre, et en particulier l’écart entre le cap vrai (« True Heading ») et le cap magnétique (« Magnetic Heading »). Elle est utilisée par les systèmes de gestion de vol FMS mais aussi par les systèmes de localisation inertiels ( « Inertial Reference Systems », acronyme 1RS) pour calculer en tout point de la trajectoire de l’aéronef les caps magnétiques et vrais.
[0028] Base de données de performances
[0029] Cette base de données dite « PERFDB » est généralement fournie par le constructeur de l’aéronef et contient la modélisation du comportement de l’aéronef (modélisation de son aérodynamique e.g. traînée, portance, ...), de ses moteurs (consommation, poussée). Elle est utilisée par les systèmes FMS ou PA (Pilotes Automatique) ou par les systèmes de surveillance (TAWS pour la surveillance terrain, TCAS pour la sur veillance entre appareils) pour calculer la trajectoire 3D de l’aéronef, ses capacités en latéral, en vertical, en vitesse, son enveloppe de vol, sa consommation de carburant, etc.
[0030] Base de données aéroportuaire
[0031] Cette base de données dite « AOF-DB » est au standard international AEEC ARINC 816. Elle et contient et détermine la structuration des surfaces aéroportuaires (ou hélipad) et est utilisée par les calculateurs de roulage (AOF pour Airport Operation Function) ou FMS. Elle contient les positions des pistes, des taxiways, des hangars, des points de parking, etc.
[0032] Base de données terrain et/ou obstacles
[0033] Cette base de données dite « TAWS-DB » est au standard international AEEC
ARINC 762, et contient une modélisation du terrain terrestre (élévation par rapport à une géodésie choisie). C’est un maillage du globe terrestre, plus ou moins fin selon les sources d’informations, comprenant notamment l’élévation au-dessus du niveau moyen des mers, par maille.
[0034] Base de données météorologique
[0035] Cette base de données dite « WXR-DB » contient une modélisation des prévisions météorologiques (e.g vents, températures, convections, activités volcaniques) sur un horizon de temps donné.
[0036] Bases de données de constellations satellitaires
[0037] Cette base de données dite « GNSS-DB » contient entre autre les éphémérides des constellations GNSS (e.g. GPS, GALILEO, GAGAN, GLONASS ...) et est utilisée par les récepteurs GNSS pour calculer la position avion, ou par les systèmes FMS pour calculer la disponibilité prédite des réceptions satellitaires tout au long du plan de vol.
[0038] Base de données de secteurs aériens
[0039] Cette base de données dite « ATC-DB » contient des polygones 3D qui cor respondent à des secteurs aériens, et des fréquences associées, mais aussi des heures d’ouverture/fermeture desdits secteurs, des autorisations de vol différentes selon les ca tégories d’aéronefs qui les traversent, etc.
[0040] Mises à jour des bases de données
[0041] Les mises à jours, longues et complexes, des bases de données sont soumises à de nombreuses contraintes de testabilité, de preuve de déterminisme et d’intégrité (procédures de « qualification » ou « certification »). Ainsi le document du RTCA DO200 précise-t-il les processus longs et coûteux qui permettent de garantir la non- corruption des données brutes lors des étapes de transformation qui conduisent à la gé nération des bases de données à embarquer.
[0042] i. Cycles
[0043] Selon les sources, les cycles temporels de mise à jour peuvent être très différents.
[0044] La base de données météorologique dite WXR DB est mise à jour avant chaque vol. Les données sont mises à jour dans le monde toutes les six heures pour certaines compagnies aériennes, toutes les heures pour d’autres. Pour un vol d’une durée de quelques heures, ce cycle peut être insuffisant, la météorologie pouvant évoluer très vite.
[0045] Par exemple, la base de donnée dite NAVDB est mise à jour tous les 28 jours (cycle AIRAC pour « Aeronautical Information Régulation and Control ») une mise à jour actualise par exemple l’ouverture de nouvelles pistes, la publication de points de passage, la modification de balises de radionavigation, etc. Un même cycle d’actualisation est observé pour la base de donnée dite AOF-DB. A ce jour, les modi fications entre deux cycles distincts sont gérées manuellement (utilisation de bulletins papiers), ce qui entraîne des incompréhensions et des risques pour la sûreté aéro- nautique.
[0046] La base de données DB (terrain / Obstacles) est mise à jour tous les un à cinq ans selon les fournisseurs. La partie relative aux obstacles peut être mise à jour avec des cycles plus courts. Cependant, ces mises à jour ne prennent pas en compte les modi fications topographiques du globe, et les constructions d’envergure (e.g. pylônes haute tension, immeubles ...). Les systèmes d’alerte (TAWS par exemples) peuvent donc être moins précis, intègres, ou générer de fausses alarmes.
[0047] La base de donnée MAGVAR est mise à jour tous les cinq ans pour les aéronefs. Elle comporte un modèle de prédiction pour calculer, à une date donnée, la déclinaison réelle. En pratique, les variations réelles dans le temps ne correspondent pas toujours au modèle, et de plus la déclinaison magnétique évolue plus erratiquement et plus ra pidement que prévu, à cause d’évènements cosmiques ou climatiques. Les systèmes embarqués qui l’utilisent sont donc biaisés (perte de précision) voir faussés.
[0048] ii. Tests.
[0049] Chaque modification doit être testée avant d’être déployée.
[0050] Dans certains cas, un pilote expérimenté va voler la procédure modifiée, à la main, tout en observant la manière dont les calculateurs concernés souhaiteraient voler cette même procédure, afin de la valider, et d’autoriser les autres avions à G utiliser par la suite.
[0051] La base de données dite PERFDB est mise à jour via des essais en soufflerie et des modélisations, une fois au démarrage du programme avion et évolue ensuite très peu (sauf correctifs majeurs). Sur certains appareils, il est prévu une correction d’erreur constante ou linéaire grâce à différents facteurs (correction de débit moteur, de per formance moteur, de traînée liée au vieillissement de l’avion ou à la maintenance, etc). Malgré tout, ces correctifs ne prennent pas en compte le vieillissement de l’avion, et des imprécisions de modélisations peuvent entraîner des biais systématiques pour les calculateurs qui les utilisent.
[0052] Il est décrit un procédé mis en œuvre par ordinateur pour la gestion de bases de données aéronautiques, comprenant les étapes consistant à :- maintenir une chaîne de blocs; - ladite chaîne de blocs comprenant un ou plusieurs contrats intelligents ; un contrat intelligent gouvernant la gestion d’une ou de plusieurs bases de données. - valider tout ou partie d’une base de données, ou d’une mise à jour de ladite base de données, par consensus distribué parmi les parties associées à la chaîne de blocs, lesdites parties étant associées à un ou plusieurs calculateurs aéronautiques, notamment des systèmes de gestion de vol FMS.
[0053] L’avantage d’utiliser un contrat intelligent réside dans le fait que le code est auditable, et surtout que l’exécution de ce code est inéluctable (exécutions effectuées en parallèle sur les nœuds de la chaîne de blocs, et résultat final validé par consensus distribué). L’usage d’une chaîne de blocs permet la mise en œuvre de mécanismes de consensus distribué. L’utilisation des données concernées peut être confirmée comme étant valide par M autres utilisateurs parmi N.
[0054] Dans un développement, lesdits calculateurs aéronautiques effectuent des tests logiques de validation et/ou apportent des preuves de déterminisme et d’intégrité des calculs des tests de validation.
[0055] Dans un mode de réalisation, un ou plusieurs contrats intelligents peuvent servir d’intermédiaires pour implémenter des tests logiques portant sur l’intégrité des mises à jour et/ou la cohérence de la mise en œuvre de ces mises à jour de données. Des essais en soufflerie et/ou des modélisations peuvent aussi être invoqués.
[0056] Dans un développement, le procédé comprend en outre une étape consistant à modifier une ou plusieurs mises à jour de données, par apport de correctifs constants, linéaires ou non-linéaires.
[0057] Dans un développement, la validation de tout ou partie d’une base de données, ou d’une mise à jour de données, est en outre déterminée par un tiers de confiance prédéfini, notamment une autorité de contrôle de la navigation aérienne.
[0058] Dans un développement, un contrat intelligent gouverne les droits d’accès, de lecture et/ou d’écriture dans les bases de données et/ou la chaîne de blocs, notamment par la gestion de clefs de chiffrement.
[0059] L’utilisation de contrats intelligents, c’est-à-dire de programmes exécutés en parallèle dont l’exécution est auditable et sûre, permet d’organiser les échanges de données, de manière qualitative et/ou quantitative, dans le temps et/ou dans l’espace. Un contrat intelligent pourra ainsi fournir des services de vérification automatique de la validité des configurations (par classe d’avion par exemple, mais aussi selon une granularité allant jusqu’à la configuration-avion propre à chaque appareil). Un contrat intelligent peut en effet contrôler les mises à jour, directement (gérer) ou indirectement (gouverner, e.g. par l’intermédiaire de règles). Les contrats intelligents peuvent appliquer ou déclencher l’application d’un ou de plusieurs tests sur les données concernées (e.g. intégrité, absence de code malveillant, cohérence ou consistant systémique c’est-à-dire compatibilité des ajouts ou retraits, etc.). Un contrat intelligent peut chiffrer, déchiffrer et/ou chiffrer à nouveau les données (e.g. empêcher les collusions ou parasitismes, etc).
[0060] Dans un mode de réalisation, le chiffrement est asymétrique, une clef publique étant associée à l’identifiant d’un aéronef et une clef privée étant associe à l’aéronef.
[0061] Dans un développement, un contrat intelligent gouverne les communications des mises à jour des bases de données entre fournisseurs de bases de données et les compagnies aériennes ou aéronefs consommant lesdites mises à jour.
[0062] De façon optionnelle, une chaîne de blocs pourra aussi servir comme moyen de transfert sécurisé des DB et/ou SW entre les fournisseurs et les compagnies et pourra fournir des services de vérification automatique de la validité des configurations.
[0063] Dans un développement, un ou plusieurs contrats intelligents déterminent un score de fiabilité associés aux parties à la chaîne de blocs.
[0064] Dans un développement, le score de fiabilité est déterminé en fonction de paramètres intrinsèques associés aux données communiquées, comprenant notamment la durée de vie des données, la rareté d’existence des données, une haute fréquence d’usage des données, la criticité d’une procédure associée aux données, une performance associée aux données, notamment en matière de réduction de la consommation de carburant, de la réduction du bruit ou de réduction du risque de collision entre aéronefs.
[0065] Dans un développement, le score de fiabilité est déterminé en fonction de paramètres extrinsèques associés aux sources des données communiquées, comprenant notamment une réputation variable ou prédéfinie, un ratio entre téléversement et/ou télé chargement de données, ou une transaction avec une contrepartie pour augmenter ledit score de fiabilité.
[0066] Dans un développement, une base de données et/ou une mise à jour d’une base de données sont stockées dans une base de données centralisée et/ou directement dans la chaîne de blocs décentralisée ou distribuée.
[0067] Dans un développement, une base de données est sélectionnée dans le groupe comprenant une base de données de Navigation NAVDB, une base de données de dé clinaison magnétique MAGVAR, une base de données de performances PERFDB, une base de données aéroportuaire AOF, une base de données terrain et/ou obstacles TAWS, une base de données météorologique WXR, une base de données de constellations satellitaires GNSS, ou une base de données de secteurs aériens ATC.
[0068] Dans un développement, des données des bases de données sont des données non avioniques, provenant de sources ouvertes, comprenant notamment des données du périmètre AISD, des données issues de sacs de vol électroniques ou EFB, des données issues de systèmes cabine ou IFE, et/ou des données issues de systèmes au sol.
[0069] Dans un développement, une chaîne de blocs est publique, avec des critères d’admission et/ou de participation du type validation par preuve de travail.
[0070] 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.
[0071] Il est décrit 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. [0072] Il est décrit un système pour la gestion de mises à jour de bases de données aéro nautiques: - au moins une chaîne de blocs, ladite chaîne de blocs étant configurée pour exécuter ou de plusieurs contrats intelligents; - lesdits un ou plusieurs contrats in telligents étant configurés pour valider tout ou partie d’une base de données, ou d’une mise à jour de ladite base de données, par consensus distribué parmi les parties associées à la chaîne de blocs, lesdites parties étant associées à un ou plusieurs cal culateurs aéronautiques, notamment des systèmes de gestion de vol FMS.
[0073] Dans un mode de réalisation, un aéronef ou drone est équipé d’un module de com munication 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 les équipements 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.
[0074] Dans un mode de réalisation, le système comprend en outre une base de données cen tralisée et/ou une chaîne de blocs dite secondaire comprenant les données aéro nautiques, lesdites données étant référencées ou indexées dans la chaîne de bloc privée dite principale.
[0075] La [fig.1] illustre le fonctionnement d’une chaîne de blocs.
[0076] 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 crypto graphiques. 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 »).
[0077] 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.
[0078] 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".
[0079] 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 crypto graphiques (« tokens »). D’autres modes de compensation (en complément ou par sub stitution) 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 par ticipants à la chaîne de blocs maintiennent eux-mêmes la base de données distribuée.
[0080] Une chaîne de blocs peut être publique ou privée, ou selon des gouvernances inter mé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 éven tuellement extrinsèques.
[0081] 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.
[0082] 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 in telligent est effectué lors de la validation des blocs (les ressources de calcul sont dis tribué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.
[0083] Comme pour tout programme ou code informatique, différents langages de pro grammation 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, éven tuellement obfusqué ou durci (« hardened »). Les techniques cryptographiques peuvent être diverses : symétrique, asymétrique, « post-quantum », « quantum-safe », avec uti lisation de « Quantum-Key-Distribution », etc). Un contrat intelligent peut être lisible par l’homme et/ou la machine (“human and/or machine readable »).
[0084] La [fig.l] 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).
[0085] 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) ;
[0086] 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).
[0087] Une partie ou entreprise ou consommateur peut être le constructeur de l’avion, un as sembleur, 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.
[0088] 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.
[0089] 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.
[0090] 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.
[0091] Enfin, une grande diversité de parties 153 peuvent consommer ou produire des données utiles : météorologiques, des services d’analyse (« analytics »), etc.
[0092] 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 re pré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 quanti fications (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 re pré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 algo rithmiquement).
[0093] 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.
[0094] 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.
[0095] 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é.
[0096] 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.
[0097] 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 in formations à 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).
[0098] 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.
[0099] 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 va lidation d’un pair participant à la chaîne de blocs reconnu comme fiable dans la chaîne (qualification technique ou de nature administrative).
[0100] 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.
[0101] 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 »).
[0102] 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).
[0103] 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.
[0104] 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éa lisation 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.
[0105] 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.
[0106] 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 cen tralisée ojf-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.
[0107] 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 in formations 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.
[0108] 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.
[0109] Dans un mode de réalisation, un intermédiaire est ajouté (validation externe): un va- lidateur 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 nœuds 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 va lidation.
[0110] Dans certains modes de réalisation, le tiers validateur est « internalisé » : les véri fications 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éri fications 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.
[0111] 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 in- telligent 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 à dis position 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).
[0112] La [fig.2] illustre des exemples d’étapes d’un mode de réalisation de l’invention.
[0113] La figure montre des exemples d’échanges de bases de données entre un producteur
210 et un consommateur 220, par l’entremise d’une ou de plusieurs chaînes de blocs 100, hébergeant et exécutant un ou plusieurs contrats intelligents 140. Les rôles de producteur et de consommateur peuvent être endossés successivement ou simul tanément pour un acteur aéronautique.
[0114] Dans un mode de réalisation, le procédé de mise à jour d’une ou de plusieurs bases de données d’un aéronef comprend différentes étapes. Un producteur ou fournisseur de base de données 210 communique une ou de plusieurs bases de données, à mettre à jour ou à déployer (télécharger et installer). La base de données centralisée 240 et/ou la chaine de blocs 100 est enrichie de tout ou partie des nouvelles données mises à jour.
Le producteur publie sur la chaine de blocs de la mise à disposition des nouvelles données dans un nouveau bloc. Un nœud de validation vérifie l’intégrité du bloc proposé et le met à disposition dans la chaine de blocs 230. Un aéronef consommateur 220 effectue une demande de données auprès de la chaines de blocs (e.g. un contrat in telligent). Les mises à jours sont récupérées directement depuis la base de données cen tralisée 240 et/ou via la chaine de blocs 100.
[0115] Contrats intelligents (optionnels)
[0116] L’utilisation de contrats intelligents reste entièrement optionnelle (e.g programmes informatiques dont l’exécution n’est pas parallélisée, existence de nœuds adminis trateurs ou privilégiés, etc). [0117] De manière optionnelle, le mécanisme de partage et/ou de validation peut être encodé dans un ou plusieurs contrats intelligents. Le module de partage peut contrôler des communications entre divers utilisateurs et/ou fournisseurs de données (contrôle du graphe social). Ce module peut être encodé par contrat intelligent.
[0118] Dans un mode de réalisation, le système selon l’invention comprend un module de validation et/ou de partage (collaboratif /coopératif) de données, notamment issues des calculateurs embarqués dans l’aéronef, lequel module est configuré pour mesurer, qualifier, quantifier, évaluer, simuler, calculer ou autrement manipuler ces bases de données.
[0119] Un ou plusieurs contrats intelligents 240 peuvent contrôler les mises à jour. En par ticulier les tests précédemment décrits peuvent être internalisés par ces contrats in telligents (e.g. gestion des confirmations ou informations manuelles du pilote, tests sur la PERFDB via des communications avec des essais en soufflerie au sol, tests via des modélisations, corrections par constantes ou selon des fonctions linéaires.). Les contrats intelligents peuvent réaliser différentes actions, notamment la validation 230 d’un ou de plusieurs blocs. La validation peut être effectuée par consensus distribué, par exemple en appliquant un ou plusieurs tests sur les données concernées (e.g. intégrité, absence de code malveillant, cohérence ou consistant systémique c’est-à-dire compatibilité des ajouts ou retraits, etc.). L’utilisation de contrats intelligents, c’est-à-dire de programmes exécutés en parallèle dont l’exécution est auditable et sûre, permet d’organiser les échanges de données, de manière qualitative et/ou quantitative, dans le temps et/ou dans l’espace. Ces programmes exécutables permettent option- nellement de manipuler les indices de fiabilité des différents contributeurs.
[0120] Les contrats intelligents peuvent gérer les droits d’accès, de lecture et/ou d’écriture dans les bases de données. Concernant les données de procédure de vol, par exemple, la « qualité » des aéronefs et/ou des membres d’équipage peut être prise en compte.
Les bases de données de performance peuvent être (par exemple exclusivement) ma nipulées par des équipementiers, ou des avionneurs ou des aérodynamiciens. Les bases de données terrain ou MAGVAR peuvent être manipulé par des géologues ou des ins titutions (e.g. Institut National de l'information Géographique et forestière). Dans un mode de réalisation, ces entités peuvent être intégrées finement dans le processus de validation et valider en temps réel, ou en quasi temps réel/flux tendus, les modi fications apportées aux bases de données. En particulier, les autorités de contrôle de la navigation aérienne peuvent contrôler le flux de données (e.g. prioriser, censurer, autoriser, confirmer, infirmer, corroborer, modifier, altérer, enrichir, croiser, etc).
[0121] Dans un mode de réalisation, un contrat intelligent peut permettre d’assurer une égalité de traitement entre les contributeurs.
[0122] Un exemple d’utilisation d’un contrat intelligent est décrit ci-après. L’exécution d’un contrat intelligent peut être déclenchée automatiquement (e.g. Oracle). Il peut lire des données externes ou internes à la chaîne de blocs, et déclencher la réalisation d’actions prédéfinies si les conditions préalablement codées sont satisfaites (par exemple si son solde (Value Score) est positif le cas échéant, le contrat intelligent peut émettre une requête de récupération des données, laquelle requête peut conduire à la création d’un nouveau bloc dans la chaîne de blocs il est également possible de causer la commu nication d’une clef de déchiffrement pour le bloc requis.
[0123] Stockage centralisé ou distribué
[0124] De manière générale, les données peuvent être stockées directement sur la chaîne de blocs 100 et/ou sur la base de données centralisée 240. En d’autres termes, dans un mode de réalisation, la totalité des données peut être stockée directement sur la chaîne de blocs. Dans un mode de réalisation, la totalité des données peut être stockée di rectement sur la base de données centralisées 240. Dans d’autres modes de réalisation, les données sont stockées pour partie dans la chaîne de blocs 100 et pour partie dans la base de données centralisée 240.
[0125] Dans un mode de réalisation, les données peuvent être stockées dans une base de données centralisée et partagée 140. Cette base de données peut être chiffrée, par exemple après vérification de l’intégrité et/ou de l’authenticité du producteur.
[0126] Un bloc de la chaîne de blocs 100 peut contenir des données ajoutées ou modifiées ou supprimées ou remplacées de la chaîne de blocs 100 et/ou de la base de données centralisée 240.
[0127] Validation
[0128] Dans un mode de réalisation, le procédé selon l’invention comprend une étape consistant à valider tout ou partie d’une base de données utilisées par les calculateurs aéronautiques (ou par une multitude d’acteurs intéressés par leurs mises à jours). Par exemple, les organisations étatiques peuvent contribuer à valide les actualisations de la base MAGVAR. Des fournisseurs de données peuvent contribuer à valider des jeux de données, associés ou non avec des offres de services (e.g. analyses, alertes, croisements, enrichissements, etc.).
[0129] La validation des données produites peut être faite par consensus (utilisation validée avec un score de « pertinence » par plusieurs consommateurs, taux d’utilisation) ou par validation d’un ou plusieurs acteurs reconnus comme fiable dans la chaîne de blocs. Quelques informations comme le format et le résumé du contenu du bloc (i.e. des données cryptées) peuvent être laissées en clair dans un espace de stockage (dans la chaîne ou en dehors de la chaîne), afin qu’un consommateur ou aéronef intéressé puisse savoir si le bloc l’intéresse ou non.
[0130] La traçabilité des échanges peut être déterminée. Les échanges de données peuvent être horodatés et/ou vérifiés par consensus distribué, par exemple via des règles de va- lidation dépendant de la « qualité » des acteurs. Cette qualité peut être quantifiée de diverses manières, statiques (voire prédéfinies) ou dynamiques (score de réputation, indice de fiabilité, etc.).
[0131] Chiffrement
[0132] Dans un mode de réalisation, toutes les données peuvent être stockées en clair
(c’est-à-dire sans chiffrement). Dans un mode de réalisation, les données peuvent être chiffrées (par exemple selon un chiffrement post quantum). Les données produites peuvent également être masquées ou cachées (stéganographie, masquage, dissi mulation, etc.).
[0133] Dans un mode de réalisation, un aéronef peut s’ « abonner » à un ou plusieurs canaux de données (RSS, NOTAM, ou autres), agissant en tant qu’Oracles. Cet aéronef peut par exemple recevoir les informations le concernant de manière automatique (e.g. mé téorologie, trafic aérien, déroutement, etc).
[0134] Valeur d’une mise à jour
[0135] La valeur d’une mise à jour est fonction (e.g. somme, fonction analytique, para métrique, calculable par algorithme) de la valeur extrinsèque des données (celle du producteur de bases de données) et de la valeur intrinsèque des données (objectivée via des tests logiques, des simulations, des références à ces listes de compatibilités, etc).
[0136] i. Scores de fiabilité (valeur extrinsèque)
[0137] Dans un mode de réalisation, des scores de fiabilité sont manipulés en fonction des historiques de téléchargement et/ou de téléversement de données, d’un point de vue quantitatif (fournisseurs actifs) et/ou qualitatif (e.g. qualité des données, fiabilité, exactitude, ou au contraire données erronées, voire malicieuses). Par le biais de la gestion de ces indices, des acteurs malveillants peuvent être exclus, d’autres ré compensés, etc.
[0138] Dans un mode de réalisation, un membre du réseau peut se voir attribuer un score de valeur (Value Score, acronyme VS) pour lui permettre de participer aux échanges (en tant que producteur et/ou consommateur de données). Ce score VS peut être fonction de la valeur des informations qu’il produit VS_PROD et de la valeur des informations qu’il consomme VS_CONS. La valeur VS peut s’exprimer sous forme d’un score, d’une crypto monnaie, d’une monnaie réelle. Dans un mode de réalisation, la VS peut être modifiée par des versements de monnaie, pour qu’un demandeur se procure le droit de consommer, ce qui peut par exemple être utile s’il en consomme plus de données qu’il n’en produit. Dans un mode de réalisation, un nœud ou acteur peut in versement transformer sa VS en monnaie fiduciaire ou en crypto-monnaie.
[0139] Dans un mode de réalisation, le score VS est amené à évoluer en fonction de l’attractivité des données produites (nombre d’abonnés par exemple, ou nombre de té léchargements, ou quantités de téléchargement), de la valeur des données qu’il consomme, et des achats/ventes dans l’alternative monétisée.
[0140] Les valeurs VS_PRED et VS_CONS peuvent être calculées de plusieurs manière, par exemple en quantité (e.g. au Mégabyte), en qualité (e.g. fonction de la criticité du cal culateur ou de la fonction embarquée concernée), par 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), en fonction de l’historique d’utilisation, du cours du jour, de la fixation a priori de bornes min/max, du consensus a priori sur les valeurs des différentes données entre acteurs, etc.
[0141] ii. Valeur d’une mise à jour (intrinsèque)
[0142] En particulier, la valeur de la mise à jour d’une base de données peut être déterminée en fonction de la difficulté à produire la donnée de la base. Pour une base de données de navigation, la publication et validation d’une procédure peut avoir une valeur différente selon que la procédure sera fréquemment utilisée par la suite par les autres acteurs. Mais la valeur peut également dépendre de la criticité de la procédure ; par exemple une approche nécessitant une performance de navigation élevée {« Low RNP » pour Low Required Navigation Procédure ) peut avoir une valeur plus élevée qu’une procédure traditionnelle ayant de moindres besoins de précision. Le contenu qui est mis à jour est la structure de la procédure au format standardisé et partagé par exemple (Arinc 424, Arinc 816). Pour une base de données de type MAGVAR, la valeur peut être liée à la rareté du point publié (routes aériennes faiblement traversées). Le contenu mis à jour est la déclinaison magnétique au point géographique considéré (latitude/longitude), par utilisation de capteurs à bord (e.g. GPS, centrales inertielles, magnétomètres ...). Pour une base de données terrain ou obstacles, la valeur peut être liée à la criticité de la modification par rapport aux risques de collision: présence de grues à proximité d’un axe d’approche d’un aéroport par exemple, changement de place d’obstacles, etc. La valeur peut être liée également à la présence d’artefacts dans la base de données terrain (e.g. erreurs dans la base, altitude réelle différente de l’altitude codée, finesse du maillage de la base mise à jour, etc). La valeur peut etre être supérieure aux alentours de zones de décollage et atterrissage par rapport à des zones de survol. Le contenu mis à jour est une élévation du terrain / obstacle pour un point donné (latitude/longitude). Pour un obstacle, son type peut également être mise à jour, ainsi que des données géométriques (rayon, épaisseur ...). Pour une base de données météo, le contenu peut être la mesure de vents et températures en un point donné de l’espace (latitude/longitude/altitude) ; cela peut être la présence de convections (polygone nuageux en 3D), etc. La valeur peut dépendre des performances que le phénomène météo peut engendrer (e.g. gain de carburant pour des vents forts arrière par exemple, risques de confort pour des zones de turbulence, etc). La donnée étant plus évolutive, la valeur peut être liée à la fraîcheur de cette dernière (e.g. heure de publication de la donnée).
[0143] La valeur d’une mise à jour peut également être convertie en monnaie réelle, ou en allègement de taxes ou un quelconque autre avantage. Dans le cas d’une base de données de navigation, la validation d’une procédure de vol liée à un aéroport peut se traduire par une réduction des taxes d’atterrissage pour la compagnie qui est à l’origine de la validation, sur cet aéroport. Elle peut aussi se traduire par des avantages sur les créneaux de décollage/atterrissage, des priorités sur des survols de routes aériennes fré quentées. Toute combinaison de ces modes de calcul est envisageable.
[0144] Dans un mode de réalisation, les modalités de calcul de ces valeurs sont inscrites dans un contrat intelligent. Le contrat peut-être bipartite (accord entre 2 acteurs) ou multipartite (accord entre 1..N fournisseurs et 1..M consommateurs).
[0145] Exemples de mode de réalisation - Architectures
[0146] Différentes architectures informatiques sont possibles. Un exemple d’architecture in formatique est décrit ci-après. Des fournisseurs de données remplissent tout d’abord leurs bases de données avec de nouvelles données. Un contrat intelligent de « mise à disposition » détecte les nouvelles données stocke des métadonnées dans une chaîne de blocs (identification, date, émetteur, score, hash du contenu des données) ; lors de la récupération (« retrieval »), un contrat intelligent de « consommation » de données se déclenche, vérifie le score de valeur de l’acheteur potentiel, vérifie (option) la réalité, la valeur ou l’intégrité de la donnée « mise à disposition » , la télécharge et l’envoie à l’aéronef demandeur. Le contrat intelligent peut également envoyer les informations du bloc correspondant de la chaîne de bloc, et le hash du contenu des données (ce qui permet à l’aéronef demandeur de vérifier l’intégrité des données).
[0147] Dans un mode de réalisation, les fournisseurs producteurs de bases de données rem plissent une base partagée et stockent les « hash » (fonction de hachage, e.g. CRC) des données, ainsi que les données horodatées dans une chaîne de blocs; lors d’un demande ou requête, un contrat intelligent se déclenche pour vérifier le score de valeur du consommateur et/ou producteur, et lui indique la position des données dans la base de données partagée (ou dans la chaîne de blocs, avec les clefs de déchiffrement). Pour éviter des partages de clefs entre aéronefs ou les collusions, un contrat intelligent peut chiffrer à nouveau les données. Différents mécanismes DRM peuvent être implémentés (e.g. nombre d’usages capé, durée de validité, etc).
[0148] De nombreuses variantes d’échanges sont possibles (stockage direct dans un contrat intelligent, une base de données tierce et/ou temporaire non représentée, clefs de chiffrement éphémères, etc).
[0149] Dans un mode de réalisation, 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 l’est également, G utilisation de la chaîne de blocs permet d’avoir cette in- formation distribuée sur plusieurs nœuds et donc de la rendre immuable et sécurisée (ainsi que de posséder un historique certain). Ainsi lorsqu’ un fournisseur publie un jeu de données (dans la base de données ou dans un bloc de la chaîne de bloc selon les al ternatives), sont ajoutés (directement par l’émetteur ou via un contrat intelligent) son VS, un timestamp (horodatage), et un moyen d’identification de la source (ID) et un moyen de valider l’intégrité du jeu de données (hash du jeu de données). 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é), cela met à jour le VS du fournisseur (ajout de la 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). Cette transaction peut être dans la chaîne de blocs.
[0150] Dans un mode de réalisation, trois acteurs se départagent les rôles : les producteurs de mises à jour de bases de données (par exemple un fournisseur de données météoro logiques ou un fournisseur de données aéroportuaires (CCI, CFMU, Eurocontrol ...), les consommateurs de mises à jour (e.g. les aéronefs, les compagnies aériennes) et les entités de validation des données (e.g. les autorités de contrôle, ATC, compagnies aériennes). Un exemple de mode de réalisation est décrit ci-après.
[0151] Un fournisseur décide de publier sa mise à jour d’une base de données dans la chaîne de blocs. Les données sont envoyées avec un identifiant qui permet d’identifier la source d’envoi des données, et un résumé du contenu (paramètres, unités, quantité, format) et la date. Cet ensemble forme un « bloc » à valider. Pour une mise à jour de procédure d’une base de données de navigation, il faut en général plusieurs tests, selon les catégories d’appareil (lourd, moyen, léger), les performances doivent donc être validées par classe d’appareil. Dans le système et le procédé selon l’invention, les données sont reçues et des tests sont conduits : la validation est effectuée soit par consensus ou par un « valideur » de confiance : d’autres fournisseurs ou utilisateurs des nœuds 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 nœuds ayant participé à la validation. Ce peut être le consommateur qui vérifie l’intégrité du bloc (hash). Dans une variante, le consommateur peut « noter » l’attractivité du bloc reçu (son intérêt pour lui-même). Dans une variante, cette note est donnée par le consommateur. Dans une autre option, la note est calculée par comptage du nombre de téléchargements du jeu de données et/ou par le nombre de consommateurs intéressés. Dans une variante, la note est fixée par des besoins réglementaires, par exemple, la validation d’une procédure de navigation nouvelle sur un grand aéroport fréquenté peut avoir une note élevée. Dans un mode de réalisation, la note est fixée par des besoins internationaux de couverture mondiale (cas des MAGVAR par exemple). Si les données sont déclarés comme invalides, alors la chaîne de blocs peut être 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 données sont considérées comme intègres, alors un nouveau bloc est créé, qui contient le lien vers les données, et une augmentation de VS_PROD d’un certain montant pour le nœud valide ur. Dans un mode de réalisation, des vérifications d’intégrité sont effectuées directement et auto matiquement par un contrat intelligent : à chaque nouvelle entrée dans la base (et tentative d’écriture de bloc), un contrat peut vérifier : a) si le producteur est déclaré (si il s’agit d’une chaîne de consortium) ; b) faire rentrer son score VS dans l’évaluation de son intégrité ; c) faire rentrer sa « note » dans cette même évaluation ; d) effectuer des vérifications fonctionnelles sur les données (e.g. des données issues d’un aéronef donné peuvent être corrélées/croisées avec d’autres sources d’information 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 (heure de décollage, statut (en vol, au sol, en croisière ...), position courante.
[0152] Du côté du consommateur, un consommateur peut s’abonner ou se déclarer intéressé pour récupérer une donnée (requête ou demande sur la chaîne de blocs, ou contrat in telligent). Un contrat intelligent vérifie si l’acheteur a les moyens (VS) pour té lécharger les données ; dans une alternative, le bloc d’achat est mis à disposition de valideurs qui effectuent cette vérification. Si la transaction est valide, le jeu de données (chiffré) est transmis au demandeur qui a la possibilité de vérifier son intégrité (hash récupéré dans la chaîne de blocs). Si le jeu de données est réputé valide, des clefs de déchiffrement (stockées dans la chaîne de blocs) sont récupérées par le contrat et transmises au demandeur. La transaction est écrite dans la chaîne de blocs par le contrat intelligent. Dans des variantes de réalisation, le procédé selon l’invention comprend un mécanisme de rétribution et de validation lorsque les informations sont considérées comme valides. Dans des variantes de réalisation, le procédé selon l’invention comprend un mécanisme de notation pour rétribuer les émetteurs de données les plus utiles.
[0153] Dans un mode de réalisation, un plusieurs acteurs (consommateur, producteur, va- lidateur) peut intégrer les nouvelles données à des données existantes dans le but d’effectuer un traitement « Big Data » par des techniques d’intelligence artificielles. Les analyses qui sont alors effectuées sur les données consolidées sont partagées (ou pas).
[0154] Dans un mode de réalisation, le procédé et/ou le système selon l’invention comprend une ou plusieurs étapes de validation et/ou de mise à jour de bases de données par des équipages et/ou calculateurs embarqués dans un aéronef utilisant une chaîne de blocs , le système comprenant au moins un aéronef « émetteur » de la modification de la base de données ; au moins un acteur « consommateur de données » (ndlr : acteur = compagnie, aéronef, AOC, ATC, entreprise ....) ; des ressources de mémoire et/ou de calcul, accédées localement et/ou à distance, pour manipuler et stocker des données de G « émetteur », lesdites données comprenant au moins une identification des données (format, nommage, datation et/ou qualité) et leur emplacement (cloud, adresse, di rectement dans la chaîne de blocs, le hachage des données, des clefs de chiffrement et/ ou de compression, et ; des ressources de mémoire et/ou de calcul pour horodater de manière certaine des données comprenant au moins la date de mise à disposition des données et l’authentification de l’émetteur (soir en clair, soit via un « login ») ; un score de valeur étant lié au jeu de données mises à jour dans la base de données ; un mécanisme de « consommation » de la base de données mise à jour ; des ressources de calcul pour vérifier l’intégrité du jeu de données de l’émetteur (hash par ex) ; un mécanisme de rétribution de l’émetteur positif pour le score de valeur si le jeu de données est reconnu au moins intègre et négatif ou nul sinon ; un mécanisme de paiement du « consommateur », négatif ou nul pour le score de paiement si le jeu de données est reconnu au moins intègre, et négatif sinon.
[0155] Dans un mode de réalisation, l’horodatage est effectué par inscription dans une chaîne de blocs, qui met en écriture le bloc lorsqu’il est produit par l’émetteur, le bloc comprenant au moins la date de mise à disposition, l’authentification de l’émetteur, et l’identification des données ainsi que leur emplacement. Optionnellement, un score est attribué à l’émetteur d’une mise à jour de la base de données fonction de la date de mise à jour et de la qualité de la validation de l’émetteur.
[0156] Mise en œuvre logicielle et/ou matérielle
[0157] 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 électro magnétique.
[0158] Matériellement, les modes de réalisation de l’invention peuvent être réalisés par or dinateur. 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).

Claims

Revendications
[Revendication 1] Procédé mis en œuvre par ordinateur pour la gestion de bases de données aéronautiques, comprenant les étapes consistant à :
- maintenir une chaîne de blocs;
- ladite chaîne de blocs comprenant un ou plusieurs contrats intelligents
; un contrat intelligent gouvernant la gestion d’une ou de plusieurs bases de données.
- valider tout ou partie d’une base de données, ou d’une mise à jour de ladite base de données, par consensus distribué parmi les parties associées à la chaîne de blocs, lesdites parties étant associées à un ou plusieurs calculateurs aéronautiques, notamment des systèmes de gestion de vol FMS.
[Revendication 2] Procédé selon la revendication 1, lesdits calculateurs aéronautiques ef fectuant des tests logiques de validation et/ou apportant des preuves de déterminisme et d’intégrité des calculs des tests de validation.
[Revendication 3] Procédé selon l’une quelconque des revendications précédentes, comprenant en outre une étape consistant à modifier une ou plusieurs mises à jour de données, par apport de correctifs constants, linéaires ou non-linéaires.
[Revendication 4] Procédé selon l’une quelconque des revendications précédentes, la va lidation de tout ou partie d’une base de données, ou d’une mise à jour de données, étant en outre déterminée par un tiers de confiance prédéfini, notamment une autorité de contrôle de la navigation aérienne.
[Revendication 5] Procédé selon l’une quelconque des revendications précédentes, un contrat intelligent gouvernant les droits d’accès, de lecture et/ou d’écriture dans les bases de données et/ou la chaîne de blocs, notamment par la gestion de clefs de chiffrement.
[Revendication 6] Procédé selon l’une quelconque des revendications précédentes, un contrat intelligent gouvernant les communications des mises à jour des bases de données entre fournisseurs de bases de données et les compagnies aériennes ou aéronefs consommant lesdites mises à jour.
[Revendication 7] Procédé selon l’une quelconque des revendications précédentes, un ou plusieurs contrats intelligents déterminant un score de fiabilité associés aux parties à la chaîne de blocs.
[Revendication 8] Procédé selon la revendication 7, le score de fiabilité étant déterminé en fonction de paramètres intrinsèques associés aux données com muniquées, comprenant notamment la durée de vie des données, la rareté d’existence des données, une haute fréquence d’usage des données, la criticité d’une procédure associée aux données, une per formance associée aux données, notamment en matière de réduction de la consommation de carburant, de la réduction du bruit ou de réduction du risque de collision entre aéronefs.
[Revendication 9] Procédé selon la revendication 8 ou 7, le score de fiabilité étant déterminé en fonction de paramètres extrinsèques associés aux sources des données communiquées, comprenant notamment une réputation variable ou prédéfinie, un ratio entre téléversement et/ou téléchargement de données, ou une transaction avec une contrepartie pour augmenter ledit score de fiabilité.
[Revendication 10] Procédé selon l’une quelconque des revendications précédentes, une base de données et/ou une mise à jour d’une base de données étant stockées dans une base de données centralisée et/ou directement dans la chaîne de blocs décentralisée ou distribuée.
[Revendication 11] Procédé selon l’une quelconque des revendications précédentes, une base de données étant sélectionnée dans le groupe comprenant une base de données de Navigation NAVDB, une base de données de déclinaison magnétique MAGVAR, une base de données de performances PERFDB, une base de données aéroportuaire AOF, une base de données terrain et/ou obstacles TAWS, une base de données météorologique WXR, une base de données de constellations satellitaires GNSS, ou une base de données de secteurs aériens ATC.
[Revendication 12] Procédé selon l’une quelconque des revendications précédentes, des données des bases de données étant des données non avioniques, provenant de sources ouvertes, comprenant notamment des données du périmètre AISD, des données issues de sacs de vol électroniques ou EFB, des données issues de systèmes cabine ou IFE, et/ou des données issues de systèmes au sol.
[Revendication 13] Procédé selon l’une quelconque des revendications précédentes, une chaîne de blocs étant publique, avec des critères d’admission et/ou de participation du type validation par preuve de travail.
[Revendication 14] Un produit programme d’ordinateur, ledit programme d’ordinateur comprenant des instructions de code permettant d’effectuer les étapes du procédé selon l'une quelconque des revendications 1 à 13, lorsque ledit programme est exécuté sur un ordinateur.
[Revendication 15] Système pour la gestion de mises à jour de bases de données aéro nautiques: - au moins une chaîne de blocs, ladite chaîne de blocs étant configurée pour exécuter ou de plusieurs contrats intelligents;
- lesdits un ou plusieurs contrats intelligents étant configurés pour valider tout ou partie d’une base de données, ou d’une mise à jour de ladite base de données, par consensus distribué parmi les parties associées à la chaîne de blocs, lesdites parties étant associées à un ou plusieurs calculateurs aéronautiques, notamment des systèmes de gestion de vol FMS.
PCT/EP2021/050552 2020-02-27 2021-01-13 Manipulations de bases de donnees par registres distribues WO2021170305A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR2001863A FR3107775B1 (fr) 2020-02-27 2020-02-27 Manipulations de bases de donnees par registres distribues
FRFR2001863 2020-02-27

Publications (1)

Publication Number Publication Date
WO2021170305A1 true WO2021170305A1 (fr) 2021-09-02

Family

ID=71661958

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2021/050552 WO2021170305A1 (fr) 2020-02-27 2021-01-13 Manipulations de bases de donnees par registres distribues

Country Status (2)

Country Link
FR (1) FR3107775B1 (fr)
WO (1) WO2021170305A1 (fr)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3367137A2 (fr) 2017-02-27 2018-08-29 Honeywell International Inc. Systèmes et procédés de collecte et de distribution d'informations d'événements météorologiques critiques
FR3063406A1 (fr) * 2017-02-28 2018-08-31 Airbus Helicopters Procede et dispositif pour echanger des donnees integres

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR3090964B1 (fr) * 2018-12-21 2021-06-18 Thales Sa Registres distribues pour le partage de donnees en aeronautique

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3367137A2 (fr) 2017-02-27 2018-08-29 Honeywell International Inc. Systèmes et procédés de collecte et de distribution d'informations d'événements météorologiques critiques
FR3063406A1 (fr) * 2017-02-28 2018-08-31 Airbus Helicopters Procede et dispositif pour echanger des donnees integres

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
JEROME KEHRLI ET AL: "Blockchain 2.0 Blockchain 2.0 -From Bitcoin Transactions to Smart Contract applications", 22 November 2016 (2016-11-22), XP055389969, Retrieved from the Internet <URL:https://www.niceideas.ch/blockchain_2.0.pdf> [retrieved on 20200914] *

Also Published As

Publication number Publication date
FR3107775B1 (fr) 2022-01-28
FR3107775A1 (fr) 2021-09-03

Similar Documents

Publication Publication Date Title
EP3671598A1 (fr) Registres distribues pour le partage de donnees en aeronautique
US10611474B2 (en) Unmanned aerial vehicle data management
EP3712798A1 (fr) Registres distribues pour la gestion du cycle de vie de donnees en aeronautique
ES2874055T3 (es) Sistema y procedimiento para la distribución de datos electrónicos
CN110326018B (zh) 航空航天商务交易
US10380812B2 (en) Vehicle transaction validation
FR3067802A1 (fr) Gestion de routes alternatives pour un aeronef
WO2021052853A1 (fr) Gestion de plans de vol par registres distribues
FR3055958A1 (fr) Aide a la decision pour la revision d&#39;un plan de vol
EP3877867A1 (fr) Systèmes et procédés de gestion de données de véhicule
FR3095277A1 (fr) Registres distribues pour la gestion de donnees meteorologiques en aeronautique
FR3067803A1 (fr) Synchronisation d&#39;un systeme dual avionique et non-avionique
FR3046273A1 (fr) Architecture ouverte pour systeme de gestion de vol
CN105474166A (zh) 用于有目的计算的方法和系统
Maiti et al. Estimating service quality in industrial internet-of-things monitoring applications with blockchain
FR3030805A1 (fr) Qualite de service d&#39;un systeme de gestion de vol
Duong et al. Decentralizing air traffic flow management with blockchain-based reinforcement learning
WO2022046469A1 (fr) Systèmes et procédés de gestion de données de véhicule
FR3107777A1 (fr) Mises a jour de logiciels et de bases de donnees en avionique
FR3038751A1 (fr) Procede d&#39;integration d&#39;une application d&#39;optimisation de route (s) sous contraintes dans un systeme embarque avionique a architecture ouverte de type client serveur
WO2021170305A1 (fr) Manipulations de bases de donnees par registres distribues
WO2021089221A1 (fr) Procede et dispositif de gestion securisee d&#39;une banque d&#39;images pour l&#39;aide a l&#39;atterrissage d&#39;aeronef
Rateb Blockchain for the internet of vehicles: A decentralized IoT solution for vehicles communication and payment using ethereum
EP4058959A1 (fr) Espace collaboratif de gestion de contexte de plan de vol
US12002309B2 (en) Systems and methods for managing vehicle data

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 21700215

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 21700215

Country of ref document: EP

Kind code of ref document: A1