FR3107777A1 - AVIONICS SOFTWARE AND DATABASE UPDATES - Google Patents

Abstract

The document describes systems and methods for updating software and/or avionics databases of an aircraft, comprising the steps of: - maintaining one or more private blockchains between several distinct airlines, a company administering one or more aircraft; - a chain of blocks comprising one or more smart contracts; a smart contract governing the management of one or more software and/or database updates, known as updates; an update being associated with validity conditions in time and/or in space; - uploading and/or downloading then installing an update in an on-board maintenance system in a flight management system of said one or more aircraft according to rules contained in one or more of said smart contracts. Developments are described. Figure for the abstract: Fig. 3

Description

AVIONICS SOFTWARE AND DATABASE UPDATES

Field of invention

The document describes methods and devices for avionics in general, and for avionics suite configuration management in particular.

State of the art

The deployment and installation of software updates and/or databases is an essential operation to maintain an aircraft in operational condition. To operate an aircraft, an airline has an obligation to keep the avionics suite software and databases (DB) up to date (all on-board software and databases). In particular, it must also be able to demonstrate that its database update operations have indeed been carried out.

Loadable software refers to a computer asset to be deployed in the avionics suite (set of software installed in an aircraft). This IT asset to be deployed may be or include one or more databases (“ database ”, DB) and/or software (“software”, SW). These assets, called “DB and/or SW” thereafter, have a standardized format called “ Field Loadable Software ”, acronym FLS. More generally, the expression "update" concerns both databases and software. The applicable aeronautical standards are the A615, A665, A666 and A667 standards. The so-called data loading operation designates the operation consisting in deploying a loadable software in the avionics suite (eg downloading, verification, installation).

The update procedures and in particular the stages of routing software on board are still complex and very little automated. Currently, the update methods are not very sophisticated (e.g. retrieving updates on CD-ROM or via an Internet portal, transferring the loadable software assets to a computer that can connect to the avionics network, then finally loading them into the avionics suite ). These update operations require the physical presence of an operator in the aircraft to be able to “connect” to the avionics. All these manipulations induce complex logistics and therefore costs for the airlines which must repeat this operation very regularly (at least every 28 days for the navigation databases). This complexity and the lack of automation are the consequence of the requirement for a very high level of security and complete traceability.

Indeed, it is imperative for aeronautical security and flight safety to ensure that the installed software assets (“ assets ” in English, including in particular software and databases) are not corrupted or pirated. Verifications now almost always go through a manual verification by a maintenance operator. The security measures essentially consist of hash value checks, all along the chain, then various checks on the screens (eg MCDU) of the flight management system.

The complexity of current update procedures leads to two major problems. First, they imply significant costs for the airlines that own aircraft fleets. Second, these procedures introduce a great deal of "rigidity" into the configuration of the aircraft. In fact, updates are only made when strictly necessary. To date, it is not possible to finely manage the aircraft configuration (for example by activating an option for certain flights only, loading a navigation database just adapted to the needs of a flight, etc.).

The state of the art describes research or certain commercial products which aim to install connected boxes inside the cockpit, with a view to downloading and then installing software products in the avionics, but its research or products present limitations ( especially in terms of computer security).

There is a need for advanced devices or methods for distributing software and or database updates in an aircraft.

The document describes systems and methods for updating aircraft avionics software and/or databases, comprising the steps of:
- maintain one or more private blockchains between several separate airlines, one company administering one or more aircraft; - a chain of blocks comprising one or more smart contracts; a smart contract governing the management of one or more software and/or database updates, called updates; an update being associated with validity conditions in time and/or space;
- uploading and/or downloading then installing an update in an on-board maintenance system in a flight management system of said one or more aircraft according to rules contained in one or more of said smart contracts. Developments are described.

Advantageously, the invention allows a very high level of computer security.

Advantageously, the invention allows a secure transfer of software and/or database updates from the company's servers to the maintenance system in the aircraft.

Advantageously, the invention allows secure transfer of the aircraft configuration from the maintenance system on board the aircraft to the company's servers.

Advantageously, the invention allows secure communications between different actors (airlines, information systems, maintenance systems, etc.)

Advantageously, the invention allows an airline to check the configuration status of one or more aircraft in its fleet of aircraft at any time.

Advantageously, the invention allows the pilot to check at any time the update status of the avionics suite of the aircraft on which he is flying.

Advantageously, the embodiments of the invention make it possible to automate the deployment of software and/or database updates, which can make this operation extremely simple and rapid.

Subsequently, new business approaches become possible, such as selling features and/or data. Until now, an airline's planes are configured in such a way that they can carry out all possible missions. So often companies prefer to load a global navigation database even if the aircraft only flies on one continent. This allows the company good flexibility if it needs to reallocate this aircraft quickly on a new route. However, this approach induces additional costs because a global navigation database is significantly more expensive than a European navigation database. The speed of deployment of the system would allow in such cases to load only the continent concerned and, if necessary, to quickly load a larger map remotely.

Advantageously, the invention allows tamper-proof logging of the aircraft configuration that can be used as proof of proper maintenance with the control authorities.

Advantageously, the traceability of transactions carried out on a chain of blocks allows billing by use.

Description of figures

Other characteristics and advantages of the invention will appear with the aid of the following description and the figures of the appended drawings in which:

illustrates how a blockchain works;

illustrates examples of steps of the process according to the invention.

Detailed description of the invention

According to the embodiments of the invention, a “mobile” or “aircraft” can be a drone, or a commercial plane, or a freight plane, or even a helicopter, whether or not carrying passengers. The mobile can be a piloted, remotely piloted or autonomous mobile; such as an aircraft (aeroplane, helicopter, or any other device subject to aeronautical laws). In other embodiments, the mobile can be terrestrial, surface (e.g. boat), submersible (submarine), orbital (satellite), etc. More generally, the term "aircraft" in the description below may be replaced by the terms vehicle, car, truck, bus, train, motorcycle, boat, robot, submarine, toy, etc. or any element capable of being remotely controlled (by radio link, satellite, or other), at least partially (intermittently, or periodically, or even opportunistically over time).

A computer-implemented method for updating aircraft avionics software and/or databases is described, comprising the steps of:- maintaining one or more private blockchains between several separate airlines , a company administering one or more aircraft;- a blockchain comprising one or more smart contracts; a smart contract governing the management of one or more software and/or database updates, known as updates; an update being associated with conditions of validity in time and/or space;- uploading and/or downloading then installing an update in an on-board maintenance system in a flight management system of said one or more aircraft in based on rules contained in one or more of said smart contracts.

The blockchain used is private (but a public blockchain embodiment remains possible). In one embodiment, the blockchain is private (all devices are known beforehand, and a new device must register with, for example, an air traffic regulation authority). In one embodiment, the blockchain is public and new devices can register modulo an admission test.

An airline runs one or more nodes, or parts of nodes. The limitations in time and space allow an adjusted granularity, ie allow to manipulate what is strictly necessary. This avoids or minimizes the injection of malicious or accidentally systemic code.

Airlines or data providers may be in charge of publishing update packages (or packages) on the blockchain, to which validity conditions will be associated.

In a development, the step consisting in installing an update is triggered after human validation, for example on the order of the pilot, said validation being determined after one or more biometric, challenge-response and/or physiological tests.

The distinction between human and machine is changing and the level of difficulty must increase faster than the increase in the computing power of the machines, so as to guarantee that the human remains in the loop (“human in the loop”). The driver but also other participants can trigger the update. The tests can therefore be multiplied (biometric signature, etc.). A challenge-response test includes a Captcha test, but also all its variants to discriminate between humans and machines, including in its machine learning developments. In particular, the tests can be chosen randomly (unique palette each time).

In a development, the step consisting in installing an update is carried out beforehand in a virtual machine isolated from the on-board maintenance system concerned, a minimum quarantine time being implemented before the actual installation.

The changes made can be at least temporarily isolated, in order to avoid or minimize the installation of malicious code.

In a development, one or more smart contracts implement logical tests relating to the integrity of the updates and/or the consistency of the implementation of the data updates, in particular verifications of the validity of the aircraft configurations, an aircraft configuration comprising previously authorized combinations of software and/or databases.

Compatibility tests are prepared before installation (“secured boot”, etc.), but can be done during installation and continued after updating. This avoids or minimizes the injection of malicious or accidentally systemic code. By systemic risk, it is meant that a complex system (an assembly of software codes) can see its overall behavior greatly modified by small modifications made to the code.

The advantage of a smart contract lies in the fact that the code is auditable, and above all that the execution of this code is inevitable (executions carried out in parallel on the nodes of the blockchain, and final result validated by distributed consensus ).

A smart contract will be able to provide services for automatic verification of the validity of configurations. Optionally, a chain of blocks can also be used as a means of secure transfer of DBs and/or SWs between suppliers and companies and can provide automatic verification services for the validity of configurations.

In a development, updates to software and/or avionics databases are stored and/or transmitted in encrypted form, the encryption being of the post-quantum type.

In one embodiment, a private blockchain is used (e.g. with no admission test other than strong authentication, accessible to airlines and aircraft maintenance systems. Updates can potentially reveal patches, i.e. vulnerabilities Post-quantum encryption prevents the disclosure of vulnerabilities, even historical ones, to an attacker.

At rest or communicated data may be encrypted. Optionally, a blockchain can also serve as a means of secure transfer of data between suppliers and companies.

In a development, the entire avionics code is stored and made accessible via said one or more blockchains.

This embodiment reverses the perspective: instead of "patching" (applying an update) an existing and monolithic embedded code, it is a matter of downloading and executing from scratch only the sub-parts (necessary and sufficient) of a monolithic code stored and implemented in a blockchain.

More generally still, the use of several chains of blocks allows sophisticated embodiments. For example, a so-called main blockchain can store and manipulate the main avionics code (FMS, FWS, etc.), while secondary blockchains will address specific functional areas.

In a development, upload and/or download requests are made via publications of the status of aircraft configurations and/or by automatic subscriptions, by aircraft or airlines, to predefined types of updates .

On-board maintenance systems will then be able to automatically retrieve updates from the blockchain to make them available for deployment in the avionics suite.

To meet traceability needs, the method can include a regular mechanism for publishing the aircraft configuration in the blockchain by the on-board maintenance system.

In development, a smart contract includes plain-readable code and a portion of code in encrypted form.

This is about combining the best of both worlds: a smart contract can contain both open code (“open source”, auditable) and closed code (“binary code”). The closed code (encrypted) can be hardened (hardened code, obfuscated) in order to protect the most sensitive information.

In a development, updates of software and/or avionics databases are stored in a centralized database.

In a development, updates of software and/or avionics databases are exchanged peer to peer between aircraft, possibly from different airlines.

This embodiment is particularly resilient, connectivity permitting. The aircraft in flight can cooperate to carry out their updates (propagation step by step). In development, a download and/or update upload is associated with a transaction with a counterparty.

The counterparty can be a cryptographic token, an amount of cryptocurrency, or an amount expressed in fiat currency. In addition, by relying on the traceability of the BC, such a system makes it possible to bill “per use” for functionalities or avionics DB.

Such a process will greatly simplify the deployment of software updates or DB in the aircraft which will be a very source of savings for airlines.

In one development, the encryption is asymmetric, a public key being associated with the identifier of an aircraft and a private key being associated with the on-board maintenance system of said aircraft.

In one development, a smart contract is multiparty with N parties, the parties including one or more parties among a data provider, an airline and an airline regulatory authority.

A computer program product is described, said computer program comprising code instructions making it possible to perform one or more of the steps of the method, when said program is executed on a computer

A system is described for the management of air traffic comprising means for the implementation of one or more steps of the method, in particular: - one or more aircraft, each aircraft comprising a maintenance system; - at least one chain of blocks, said chain of blocks being configured for the execution of one or more smart contracts; - said one or more smart contracts being configured for - aeronautical computers, for example a flight management system or FMS, directly associated to the read and/or write blockchain, and/or indirectly to the blockchain through said one or more smart contracts.

There 1 illustrates how a blockchain works.

According to the definition given by Wikipedia, a “blockchain” (“blockchain” in English) or a “distributed ledger” (DLT for “Distributed Ledger Technology” in English) is a distributed database secured by cryptographic techniques. The exchanged transactions are grouped into “blocks” at regular time intervals, in a cryptographically secure manner, which blocks form a chain. After recording recent transactions, a new block is generated and analyzed. If the block is valid (distributed consensus), the block can be timestamped and added to the blockchain. Each block is linked to the previous one by a hash key. Once added to the blockchain, a block can no longer be modified or deleted, ensuring network authenticity and security. Chaining uses hash functions and Merkle trees. A hash tree is made up of a set of interdependent checksums. Checksums are concatenated in a tree structure. A hash tree makes it possible to verify the integrity of a set of data without necessarily having all of the data at the time of the verification. Records in a blockchain are protected against tampering or modification by storage nodes: tampering with one block requires tampering with the entire chain, so the total cost becomes prohibitive and guarantees a level of trust 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 network nodes can take a very variable time depending on the technologies used. It can be accelerated by using various techniques, in particular “sidechains”, which also increase storage capacities.

As part of distributed consensus, a blockchain can use proof of work validation. From a mathematical point of view, a proof of work is “hard to provide but easy to validate”. Validation by proof systems are generally asymmetrical: the calculation that is required in return for a service request is costly for the requester but remains easily verifiable by a third party. Different techniques can be used, including hashcash or a "client-puzzle".

The "minor" or "mining" nodes are entities whose role is to supply the network with computing power, to allow the update of the decentralized database. These minors can be rewarded by the distribution of cryptographic tokens (“tokens”). Other methods of compensation (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 themselves maintain the distributed database.

A blockchain can be public or private, or according to intermediate governances, which can use different barriers to entry (validation by proof of work). A “private” blockchain consists of consensus participating nodes that are defined in advance and then authenticated. Its operating rules may possibly be extrinsic.

There shows 4 blocks of data 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). In a (binary) Merkle tree, these hash values are then concatenated two by two to be able to calculate a new parent hash (121, 122). And so on until the top of the tree where we obtain a hash-vertex (131). To guarantee the integrity of a block with respect to all the data, it is enough to have the hash values of the brothers, the hash values of the uncles and the hash-vertex. Moreover, only the hash-vertex (131) must be recovered in a safe manner to guarantee the integrity of all the data represented by the tree. For example, if you want to check the integrity of block B2, you just need to have retrieved hash 0-0 (his brother 111), hash1 (his uncle 122) and the hash-vertex (131).

A block of data can include one or more codes or programs or smart contracts 140. Concretely, a smart contract 140 can implement one or more mechanisms: (a) for access to data or parts of data (relating in particular to plans theft): -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 may be known to a registry) ; 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 per volume of data (e.g. per MB of data downloaded); credit or point systems can be used; b) payment; transactions can be settled in units of account (crypto-currency or fiduciary currency e.g. USD or EUR);

The data blocks (101, 102, 103, 104) are produced then consumed, i.e. accessed, in reading and/or writing, by parties or companies (e.g. illustrated by 151, 152, 153).

A party or business or consumer may be the aircraft manufacturer, an assembler, an OEM, an aircraft or airline, a weather data provider company, a regulatory authority, etc.

A party can be a “producer” of data and/or a “consumer” of data. A data consumer may be referred to as "customer" or "requester" or "receiver" hereafter. A producer may be referred to as “issuer” or “server” or “provider” thereafter. The expression “and/or” emphasizes the fact that production and consumption can be successive or alternative, or even simultaneous. As each party can buy and/or sell, license and/or grant licence, assign or give or share its own data, it can also access data shared by the other parties. Sharing data creates other data, some of which may have technical or other value. As another example of a data producer/consumer, air traffic control authorities 152 can produce and consume data.

The data may in particular concern flight plans and/or their associated certificates, NOTAM notifications, various alerts, routing or flight plan statistics, etc.

Finally, a wide variety of parties 153 can consume or produce useful data: weather, analysis services (“analytics”), etc.

In some embodiments, different layers or levels of regulation may be involved: a first layer of metadata or blockchain 100; inheriting properties inherent to a blockchain (e.g. integrity, tamper-proof, 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 voluminous data in secondary databases, also in the form of a chain of blocks (“sidechains”), or not i.e. without the use of a chain of blocks; a second layer of data (not shown) called or referenced by the blockchain 100 (encrypted in part or in full). This data, in particular flight plans, can be stored in the database in different formats (.txt, .doc, .rtf, .xml, .json, etc.). Data may also include metrics of uploads, downloads, usage, etc. which in turn may determine scores or other quantifications (by means of logical decision circuits e.g. computers); a third layer of coordination or regulation between actors (who alternately play the roles of producer or consumer, reading and/or writing on the blockchain 100. Agreements between participants in the blockchain can be written contracts (excluding technical), or partially - or entirely - 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. Optionally, the entity 140 can represent or be associated with one or more validators (or “oracles”, which can correspond to a validation independent human and/or machine i.e. algorithmically encoded).

Smart contracts

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 make breaking an agreement costly because they control an asset through digital means. They may or may not provide for the intervention of third parties to the contract to monitor its execution (e.g. machines or “oracles” or oracle services). A smart contract is software code that is stored and executed on/by a blockchain and is triggered by external data that 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 for a smart contract is stored on or in the blockchain; the execution of the smart contract is performed during block validation (computing 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. As a result, the code as well as the execution of the code are safe.

As with any computer program or code, different programming languages are available, with different security and regulation models (framework contract governing other contracts, cascading contracts, etc.). The forms taken by smart contracts can be diverse (e.g services, agents, snippets, scripts, SOA, APIs, add-ons, plug-ins, extensions, DLC, etc). Mathematical logic (decision-making operating on data) can be that of classical, fuzzy, combinatorial, intuitionistic, modal, propositional, partial, para-consistent logic, etc. or a combination of these logics. The software can be coded in part or in whole on hardware form (e.g. FPGA). A smart contract may be wholly or partly open source and/or closed source. In the case of open source, the code is auditable or verifiable by the parties or third parties. 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 a 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.

In one embodiment, the chain of blocks 100 of data (of flight plans) is public. In particular, it is possible to implement validation by proof of work (“proof-of-work” or PoW e.g. hashcash or variant). In one embodiment, 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.

In addition or in substitution, one or more secondary blockchains (not shown) can be used. For example, a primary blockchain may contain metadata related to flight plan data (i.e. including the hash values of the data), while a secondary blockchain may contain the data itself.

In one embodiment, the method uses one or more "smart contracts". Data can be shared on a blockchain to ensure timestamping and immutability.

In one embodiment, a consumer's intended use of a block's flight plan data is governed (directly or indirectly via rules) by a smart contract.

In one embodiment, all block data is written in clear (e.g. 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 block data is encrypted (e.g. symmetric, asymmetric, etc). In some cases the block data is obfuscated in addition to being encrypted (the existence of the data is obfuscated, which provides additional protection).

In one embodiment, the data is stored in one or more shared databases, encrypted in whole or in part, after verification of their integrity and the authenticity of the producer.

In one embodiment, the validation of the data produced is carried out by distributed consensus (e.g. use validated with a "relevance" score by several consumers, measurement and monitoring of the rate of use, etc.) and/or by validation of a peer participating in the blockchain recognized as reliable in the chain (technical or administrative qualification).

In one embodiment, some information (such as the format and/or summary of the encrypted block's contents is left unencrypted in a storage space (on-chain or off-chain), so that an interested consumer can know if the block interests him or not.

In certain embodiments, the rights to the block data may be conditional on contribution criteria (in particular the upload/download ratio in English “upload/download” or “seed/leech”).

In one embodiment, access to or rights to data may be conditionally governed (e.g., if a customer or applicant's balance or Value Score is positive).

Optionally, if conditional access is granted (or if pre-defined conditions are met), the executed smart contract can issue a data retrieval transaction or request, which transaction will insert itself (among several others) into a new block . If the distributed consensus confirms the block comprising the transaction, an encryption key allowing the reading of the desired data can be sent to the client; who will be able to read and exploit the desired data.

In one embodiment, a plurality of actors share data, e.g. flight plans, and store the hash values of the data, as well as information about the format of the data, in one or more blockchains. After completing a transaction, one or more smart contracts verify the requester's value "score", indicate to him the position of the data in the shared database, as well as the data decryption keys.

In one embodiment, there are no smart contracts (direct model). Indeed, in this alternative embodiment, producers and/or consumers can do without smart contracts, by reading and/or writing (directly) in the blockchain. For example, a first actor can receive a request for theft or a theft certificate from a consumer and if the transaction is successful (distributed consensus), he can communicate it directly to said actor.

In one embodiment, the chain of blocks does not contain the flight plan data in itself but only the description that is made of this data (the data is stored in secondary chains or a centralized database off -chain ). This embodiment is advantageous in that the data replicated in the main blockchain is significantly less bulky.

In one embodiment, by subscription or "peer-to-peer approval", an aircraft or drone can, for example, alternately, publish information intended for other members of the network or even "subscribe" (in English “subscribe”) to the network, for example via a smart contract, and receive information about it automatically. For example, an aircraft can share its flight plan information, securely and with integrity, with other aircraft (belonging to other airlines, precisely). Subscription modes may include push and/or pull modes, unsubscribe, etc. In certain embodiments, each aircraft is able to determine intersections or risks of collision: the traffic regulates itself. Some devices that do not have sufficient means of calculation can emit signals warning of their defect or lack of temporary or permanent verification.

In one embodiment, a smart contract can read block data in the clear and trigger one or more operations, for example if the client or requestor or consumer is validly subscribed to the data type of the block in question or if predefined conditions are met. .

In one embodiment, an intermediary is added (external validation): a data validator (not shown), typically a computer from the air traffic regulation authority. In a first stage, production, a source decides to publish data in the chain of blocks (directly or indirectly via the base). The data is sent with an identifier (which identifies the source of sending the data) and a summary of the content (e.g. parameters, units, quantity, format, etc.) as well as the date of the data (e.g. creation, validity, etc) This set forms a “block” to be validated. The validation subsystem receives the data. Validation is carried out 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). This may give rise to compensation (in VS) for the node(s) that participated in the validation. It can be the consumer who verifies the integrity of the block (hash). In one embodiment, the consumer can “rate” (unilaterally) the attractiveness of the block received (its estimated interest for and by itself). In one embodiment, the score is given by the consumer. In one embodiment, the score is calculated by counting the number of downloads of the data set considered and/or by the number of interested consumers or effective purchasers/licensees. If the data is declared invalid then the blockchain is updated with a decrease in VS_PROD by a certain amount for the producer, and an increase in VS_PROD for the one who detected the anomaly. In one embodiment, if the data is considered valid/integrated then a new block is created, which will contain the link to the data (e.g. addresses, keys), and an increase in VS_PROD of a certain amount for the node or the validation part.

In some embodiments, the third-party validator is "internalized": verifications are performed directly and automatically by one or more smart contracts. With each new entry into the database (and attempt to write a block), one or more smart contracts can perform various tasks, including a) checking if the producer is declared (if it is a party to the consortium or blockchain); b) modify the VS score of the source c) score or evaluate the data entered (directly or indirectly); possibly d) perform functional checks directly on the data (for example, data from a model X aircraft can be correlated/cross-referenced with other sources of information on the aircraft (e.g. public or private sources of the company, air traffic control) issued in real time and corresponding to the state of the aircraft (e.g. take-off time, current status e.g. in flight, on the ground, in cruise, current position, etc.); in particular, the sequence of checks of the operator/flight plan/aircraft/pilot quadruple can be implemented by one or more smart contracts.

From the perspective of data consumption, a consumer can subscribe or declare an interest in retrieving data (e.g. transaction order directly on the blockchain or via a smart contract). The relevant smart contract can check whether the requestor has the sufficient balance (Sv) to download the data. In a variant embodiment, the purchased block is made available to one or more human and/or machine validators who carry out this verification. If the transaction is valid, the data set (for example encrypted) is transmitted to the requester, 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 transmitted to the requestor. The transaction is then written into the blockchain by the smart contract. In one embodiment, compensation and/or evaluation and/or retribution and/or validation mechanisms can be implemented if the data is determined to be valid (rating and/or reputation mechanism to identify or reward the most "useful" data issuers (concept relating to one or more objectives that can be objectified and internalized). The applicant, i.e. initiator of the transaction, can for example import the data obtained and cross-check or integrate them with existing data in the purpose of carrying out “Big Data” type processing using artificial intelligence techniques (in particular automatic learning).

There illustrates examples of steps of an embodiment according to the invention.

In one embodiment, the blockchain parties include one or more airlines and one or more aircraft.

Airlines can be in charge of i) defining for each aircraft one or more avionic configurations stored in the blockchain and/or ii) adding validity conditions (in time and/or space) to each aircraft configuration

Aircraft include an on-board maintenance system which can be responsible for i) periodically publishing, and therefore timestamping, the status of its aircraft configuration on the blockchain; ii) to retrieve from the blockchain, the configuration expected by the airline (in accordance with the conditions of validity) and iii) to carry out the updates automatically if necessary (including the publication of the new aircraft configuration on blockchain)

In one embodiment, these aircraft configurations may materialize through one or more smart contracts.

In particular, in order to ensure the confidentiality of the DB and/or SW packets, the latter may be published on the blockchain in an encrypted manner, for example with the public key of the aircraft for which they are intended. Thus, following the download of the DB and/or SW packet from the blockchain, the on-board maintenance system will be able to decrypt it using the private key of the aircraft at its disposal.

The onboard maintenance system can be hosted in an open world computer connected to the avionics, or directly be hosted in the avionics world. The maintenance system has direct or indirect (via a secure gateway) access to the blockchain network.

As in any blockchain, the identity of a party is verified through the fact that it has a private key, which must therefore be implemented and stored securely in the aircraft maintenance system.

In one embodiment, a blockchain is a private blockchain, i.e. for which the consensus mechanism is managed by a limited number of known nodes. These known nodes can be administered by a group or consortium in charge of managing this blockchain.

In one embodiment, the consensus mechanisms implemented by these nodes will be light and classic mechanisms of the Paxos, RAFT or BFT algorithm type. Proof of work validations are indeed not relevant for a private blockchain whose nodes are known and safe.

In a specific embodiment (expanded management of air traffic, in particular or drone), the chain of blocks used can be of the public type and admission tests by validation of proof of work can be put in place. Some adaptations can be implemented (e.g. limitations on the number of transactions, limitation on the volume of data exchanged, etc.

In one embodiment, a pair of keys is generated for each airline (comprising a public key and a private key). The private key is kept by the airline and is used to sign the packages (see step 220). The public key is the identifier of the company on the blockchain (through its hash value).

In one embodiment, a key pair is generated for each plane or aircraft. The private key is kept by the on-board maintenance system (in a trusted computer module, e.g. a TPM, for example). The public key is the identifier of the plane or aircraft on the blockchain (through its hash value).

In one embodiment, a distributed register will be kept up to date, in order to associate each aircraft with the airline that administers it (in other words, there is an association table between the aircraft identifier and the airline identifier)

This register allows the aircraft system to know which address in the chain of blocks has the right to load software and/or databases. in one embodiment, the administration of this register is done via one or more smart contracts.

In one embodiment, a smart contract notably allows a company to add a new aircraft identifier (which will be associated with its company identifier) and a contract involving two companies (signed by both companies) allowing the transfer of the aircraft management.

In an alternative embodiment, the distributed register can be replaced by the opposite imposed on the companies to store the identifier of the airline in the on-board maintenance system.

In one embodiment, an aircraft knows the signature of its company, in order to only accept orders (or commands or instructions) for downloading, uploading or installing (of one or more software and/or data base).

In one embodiment, the method for updating an aircraft includes the steps of:

At step 210, one of several airlines retrieves from its data provider a set of new DBs and/or SWs to be deployed (downloaded and installed). Optionally, the airline also retrieves a predefined validity period for the DBs and/or compatibility instructions for the DBs and/or SWs.

At step 220, for a given aircraft, the airline determines a DB and/or SW packet to be deployed on said aircraft. This package is encoded with the public key of the aircraft and signed by the company.

At step 230, the airline ensures the consistency of the aircraft configuration once the DBs and/or SWs have been installed (compatibility with the DBs and SWs already in place).

At step 240, the airline publishes the DB and/or SW packet on the blockchain along with the metadata, including one or more of the following data: conditions of use and/or installation (e.g. time interval and/or or in space concerning the validity of the aircraft configuration for example), identifier of the destination aircraft, etc. Indeed, it may sometimes be desirable to deploy (download, install) the configuration in the aircraft considered only under predefined conditions, for example in a given geographical area and or at a given period.

Publishing data on the blockchain can be done in a variety of ways. In one embodiment, the data is published in the clear in the blockchain. In one embodiment, data is encrypted and then posted to the blockchain. In one embodiment, the data is associated with one or more smart contracts hosted in and implemented by the blockchain. All or part of the data can indeed be executable. In one embodiment, certain data can only be executed by the maintenance system of the aircraft considered (and exclusively this maintenance system). in other words, once triggered, the smart contract allows the aircraft maintenance system to access the DBs and/or SWs.

In one embodiment, a notification system may be implemented. For example, by performing a predefined transaction (of cryptographic tokens) between the airline and the aircraft maintenance system, it can be determined that an action is expected from the aircraft on-board maintenance system ( in this case the downloading and installation of a DB and/or SW package).

In an alternative embodiment, the airline only publishes in the blockchain the metadata and a hash value of the DB and/or SW packet. Said DB and/or SW package can be made accessible to the aircraft maintenance system by other means (e.g. centralized server, transfer via physical media, etc.)

In one embodiment, the onboard maintenance system periodically performs one or more checks. A verification step may in particular comprise a step consisting in verifying the existence of a new DB and/or SW packet. These verifications can be periodic (the verification period can be of the order of a minute). If necessary, if a new DB and/or SW package is available, the on-board maintenance system downloads it and stores it on board the aircraft.

If the aircraft is offline, the download can be done opportunistically (avionics cloud, stopover, if the aircraft is offline it will have to wait to retrieve the package, it is the company's responsibility to place publish the packages early enough in the BC so that the embedded system can download it in time.

Based on the metadata associated with the package, the on-board maintenance system can switch to “update available ” mode, for example as soon as the conditions defined in the package metadata are met (criteria temporal and/or spatial). If the conditions are no longer met, the system leaves the “ update available ” mode and step 260 is prohibited.

In one embodiment, if the onboard maintenance system is in "update available" mode and if the aircraft is in a phase of its mission compatible with the download and/or installation (for example aircraft on the ground, compatible flight phase, sufficient connectivity, etc.), then a manual operation or confirmation performed from the aircraft can trigger the deployment of the DB and/or SW packet in the avionics suite.

In one embodiment, manual i.e. human triggering may be required for aviation security reasons. Advantageously, the human initiative of triggering the update can prevent any risk of an untimely and annoying update, even dangerous for operations. In other embodiments, medium term, this triggering can be entirely automatic.

In a manual embodiment, it is sometimes required to use storage on removable media (e.g. SD card, compact flash, etc.) the handling of the media is then done by an operator (or a pilot) in the cockpit.

In one embodiment, a blockchain can also be used as a means of transferring DB and/or SW packets, especially between data providers and airlines. Data providers, if any, can publish new versions of the packages they produce on the blockchain. Through the use of one or more smart contracts, airlines can retrieve these packages and deploy them to their aircraft. The benefits of this embodiment in which the blockchain is also used for storing packets include increased security, as encryption can be done end-to-end. Removing intermediaries can improve security because any intermediary can be considered a point of vulnerability.

In one embodiment, the blockchain may support the transactional portion of package purchases. A transaction may include the communication of an object with a financial counterparty.

In one embodiment, the consistency of the software versions in an avionics suite is an important technical problem to be managed for the maintenance departments of the companies. Some databases are only compatible with certain software versions, certain software versions are incompatible with each other, etc.

In one embodiment, avionics manufacturers or integrators can publish smart contracts on the blockchain for verification of aircraft configurations.

Software and/or hardware implementation

The present invention can be implemented from hardware and/or software elements. It may be available as a computer program product on a computer-readable medium. The computer can be a rack or a tablet or an EFB (electronic flight bag) or a software part integrated in the FMS (flight management system), etc. The medium can be electronic, magnetic, optical, or electromagnetic.

Physically, the embodiments of the invention can be realized by computer. For example, a distributed architecture of the "cloud computing" type. Peer-to-peer servers, fully or partially distributed (existences of centers) 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, when it comes to private cloud or private blockchain. Access can be cross-platform (eg from EFB, WebApp, ground access, etc).
In one embodiment, an aircraft or drone is equipped with a module for communication and collaborative sharing of data from computers on board the aircraft. This material module can be in relation with various users (consumers) and/or suppliers (producers) of data. Avionics equipment can interact (bilateral communication) with non-avionics equipment. In some cases, the communications can be unilateral (from the avionics to the non-avionics, but not the reverse, ie 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 with each other, also with EFBs.

Claims (15)

A computer-implemented method for updating software and/or avionics databases of an aircraft, comprising the steps of:
- maintain one or more private blockchains between several separate airlines, one company administering one or more aircraft;
- a blockchain comprising one or more smart contracts; a smart contract governing the management of one or more software and/or database updates, called updates; an update being associated with validity conditions in time and/or in space;
- uploading and/or downloading then installing an update in an on-board maintenance system in a flight management system of said one or more aircraft according to rules contained in one or more of said smart contracts. Method according to claim 1, the step consisting in installing an update being triggered after human validation, for example on the order of the pilot, said validation being determined after one or more biometric, challenge-response and/or physiological tests. Method according to claim 2, the step consisting in installing an update being carried out beforehand in a virtual machine isolated from the on-board maintenance system concerned, a minimum quarantine time being implemented before the actual installation. Method according to claim 1, one or more smart contracts implementing logical tests relating to the integrity of the updates and/or the consistency of the implementation of the data updates, in particular verifications of the validity of the configurations- aircraft, an aircraft configuration comprising previously authorized combinations of software and/or databases. Method according to claim 1, the updates of software and/or avionics databases being stored and/or transmitted in an encrypted manner, the encryption being of the post-quantum type. Method according to any one of the preceding claims, the entire avionics code being stored and made accessible via said one or more chains of blocks. Method according to any one of the preceding claims, upload and/or download requests being made via publications of the state of the aircraft configurations and/or by automatic subscriptions, by the aircraft or the airlines, to predefined update types. A method according to any preceding claim, a smart contract comprising plain-readable code and a code portion in encrypted form. Method according to any one of the preceding claims, the updates of software and/or avionics databases being stored in a centralized database. Method according to any one of the preceding claims, the updates of software and/or avionics databases being exchanged peer-to-peer between aircraft, possibly from different airlines. A method according to any preceding claim, wherein an update download and/or upload is associated with a transaction with a cryptographic token type counterpart. Method according to any one of the preceding claims, the encryption being asymmetric, a public key being associated with the identifier of an aircraft and a private key being associated with the on-board maintenance system of said aircraft. A method according to any preceding claim, a smart contract being N-party multi-party, the parties comprising one or more of a data provider, an airline and an airline regulatory authority. A computer program product, said computer program comprising code instructions for carrying out the steps of the method according to any one of claims 1 to 13, when said program is executed on a computer. System for the management of air traffic comprising means for implementing the steps of the method according to any one of Claims 1 to 13