Data is lately at the heart of the disruptions occurring across the economy, with aviation stakeholders aggressively investing in harnessing their data as critical corporate assets to drive strategic insights, improve operations, support faster turnaround times and personalize passenger experiences. Although there has been indeed a paradigm shift, with aviation companies starting to open up their data and with some industry data-sharing concepts having proven to be very effective and valuable to participating stakeholders, the overall aviation industry generally remains reluctant in sharing data due to privacy, legal and organisational policies and even infrastructure limitations.

Towards a European Data Sharing Space

In its latest white paper on “Data Science Hype or Ripe for Aviation”, IATA promotes Common Industry Data Sharing Platforms as a core, high-level area of Data Science application in Aviation, that require strong governance and a neutral custodian to ensure data provided by participants is protected, e.g. through anonymization, aggregation, and averaging of data fields according to the governing framework of the platform. The need for data sharing and exchange platforms, i.e. Data Marketplaces, where data is commercialized using open data, monetized data and trusted data sharing mechanisms, is also highlighted in the recent BDVA position paper, entitled “Towards A European Data Sharing Space”.

Aviation Data Sharing as part of ICARUS

To this direction, ICARUS has put data sharing very high in its agenda as evidenced from its MVP prioritization activities. Upon meticulously studying and understanding the underlying state-of-play regarding data sharing in general, and in aviation in particular, from a research / academic and market perspective, ICARUS proposed:

• A Data Sharing Model that formalises all data attributes and qualities that affect, or are in any way relevant to, the ways in which data assets can be shared / traded. The model comprises three core entities, namely the Asset, the Policy and the Contract and two supporting entities, namely Attributes and Terms, with the latter being specified as one of Prohibition, Permission and Obligation or an attribute guarantee.
• A Blockchain-enabled Data Policy and Assets Brokerage Framework that captures the complex provider-consumer interactions to demonstrate how ICARUS envisions to enable the creation of structured, machine-processable data contracts for the aviation industry, whilst maintaining the data owner in control of the provided data.

ICARUS Data Assets

An Asset in ICARUS is defined as one of the following:

1. A specific dataset from a data provider or an open data source
2. An application that can be used as-is to perform a specific analytics and/or visualisation task inside ICARUS. Such an application may take the form of instructions that need to be expressed in the language used by the ICARUS analytics and visualisation tools and they may or may not be linked to specific data input sources.
3. The result of applying specific data analytics and/or visualisations on specific data, which can be perceived as a report.

The ICARUS Asset Brokerage Workflow

In particular, the core asset brokerage workflow that captures the basic provider-consumer interactions comprises three phases:

Phase I-a: Data Assets Exploration and Phase I-b: Non-data Assets Exploration initiated by an ICARUS user performing a query to search for data or applications (algorithms, visualizations). Both alternatives of Phase I end with the query results being returned to the user. In all cases, the results that are presented to the user adhere to the limitations imposed by the defined terms and policies. Browsing and reviewing the presented result list, the user may choose to issue a request to obtain a specific asset.

Phase II: Smart Contract Drafting initiated when the data owner is notified of the request. In case the request is not considered interesting, the provider may refuse to proceed and the process ends without any contract being drafted. If the provider chooses to follow through, the next step is the definition of the contact terms (as foreseen by the ICARUS sharing model). It should be noted that many of the terms will be pre-calculated as they stem from the asset attributes and policies, as well as from the request that initiated the process. The provider is then guided on providing the remaining required terms and on updating the pre-calculated ones if needed. Apart from the structured terms, the provider in this phase should also provide the natural language part of the agreement (unless not desired). Once this process is completed, a smart contract is created and uploaded to the blockchain. The contract is now in draft stage, as denoted by the field “Stage” which is used as a flag for the contract’s status and is in this case set to “Draft”.

Being notified for the draft contract, the prospective consumer proceeds to review the terms and may act in the following three ways:

• Reject the contract and end the process. In this case the smart contract’s “Stage” field is set to “Rejected”.
• Accept the contract as-is. The smart contract’s “Stage” field is set to “Accepted”. This concludes Phase II.
• Edit the contract terms. Editing is possible both for the smart contract part and for the natural language document. Once editing is completed, the smart contract is updated accordingly and its “Stage” field is set to “Negotiating”. In this case, the asset provider is notified for the updates in the contract and should proceed to review them. There are three possible actions:
  1. Reject the contract and end the process. In this case the smart contract’s “Stage” field is set to “Rejected”.
  2. Accept the updated contract as-is. The smart contract’s “Stage” field is set to “Accepted”. This concludes Phase II.
  3. Edit the contract terms. Editing is possible both for the smart contract part and for the natural language document. Once editing is completed, the smart contract is updated accordingly and its “Stage” field is set to “Draft”. It should be noted that editing the contract results in a different state depending on who performed the edit, the provider or the consumer.

The negotiation over the contract terms corresponds to a loop between the previous steps that ends once the contract stage is set to either “Rejected” or “Accepted”. In the first case, the workflow is terminated in Phase II, otherwise it moves to Phase III.

Phase III: Smart Contract Validation requiring that the smart contract has been accepted by both parties (and its “Stage” field is set to “Accepted”). When this is done, the data consumer should proceed with the payment. Once the data provider validates that the payment was successfully made, the smart contract stage changes to “Paid”, which is the stage that denotes that the smart contract is considered valid and the ICARUS platform will allow the consumer to obtain the asset. Access to the asset will be automatically ensured for the time interval defined by the duration field of the smart contract.

It should be clarified that contracts in ICARUS are hybrid, in the sense that although a smart contract mechanism is in place, a decision has been made to maintain a textual part of the underlying agreement. To avoid confusion, smart contracts are defined as “self-executing contracts with the terms of the agreement between buyer and seller being directly written into lines of code. The code and the agreements contained therein exist across a distributed, decentralized blockchain network.” The need to be self-executable precludes any text written in natural language. However, based on the requirements elicited from the aviation stakeholders (both participating in ICARUS and external) and on the landscape analysis on smart contracts in aviation and automated data sharing contracts in the scope of intellectual property, this was not considered a viable option in ICARUS due to the limited familiarity of stakeholders in the aviation industry with this technology and the gravity of data sharing agreements in aviation both in terms of monetary value and legal implications.

More details on the state-of-the art analysis, the Data Sharing Framework are available in the ICARUS Deliverables D2.2 and D2.3, as well as in a conference paper.

Blog post prepared by SILO and Suite5.