SITA is the technology company jointly owned by the airline industry. The company announced the launch of their Aviation Blockchain Sandbox and invited industry players to join.
Barbara Dalibard, CEO, SITA, said: “Today we are inviting air transport organizations to work together so that we can collectively see how blockchain could work across our industry. Blockchain holds many promises but exploring these in individual organizations is not the most productive.”
“As the technology company owned by airlines, SITA is in a position to work neutrally with multiple stakeholders to explore and test multi-enterprise applications. Through this collaborative innovation, we will accelerate the learning for all.”
Like many other industries there are sometimes conflicts when the same data is stored by multiple companies, but in fact, it doesn’t match. Instead, SITA aims to encourage industry players to have shared applications with one version of the data.
The blockchain sandbox is led and managed by SITA’s research team, SITA Lab which is ten years old.
FlightChain
Last year the Lab ran a Proof of Concept (PoC) for flight information called FlightChain. The project included British Airways, Heathrow, Geneva Airport and Miami International Airport.
The test finished in November 2017, and the application will be available to all participants in the new Sandbox.
The ‘flight data problem’ is a well-known issue in the industry. Particularly the lack of a single source of information and data is not easily accessed by all parties. When flights get delayed, potentially different information appears in passenger apps, data obtained by airline agents, and at the airport.
The experiment used both Ethereum and Hyperledger Fabric to gain experience with the pros and cons of each. During the test, they processed more than two million flight changes with a smart contract arbitrating between conflicting data.
Standards or Smart Contracts?
Following the experiment, the SITA Lab suggested an alternative to creating industry blockchain standards because standards can be open to interpretation. Or they’re often misinterpreted. Instead, they concluded that a task force briefed to create standards should produce the smart contract. All parties can review the code, and once it’s signed off, they can deploy it.
However, in reality, standards tend to cover more than just the pure logic. That said, this is a useful suggestion for the process-oriented aspects of a standard. But less technical team members might want code ‘translations’.
