От теории к практике: как применяется блокчейн в авиации01.11.2019 15:20

Гражданская авиация — глобальная индустрия, в которой непрерывно происходит синхронизация и обработка огромных массивов данных. В середине 20 века глобальные системы бронирования авиабилетов были одними из первых примеров применения компьютерных комплексов и сетей передачи данных. Давайте посмотрим, как сегодня технологии блокчейн могут помочь быстрее и эффективнее решить простую, на первый взгляд, задачу: перевести пассажира из точки «А» в точку «В»?

Дано

Большое число организаций — участниц процесса

Как минимум одна авиакомпания;
Точка продаж, через которую был куплен билет (это может быть сайт авиакомпании или офис туристического агентства);
Провайдер инвенторной системы (система обслуживания пассажиров);
Как минимум два аэропорта;
Служба воздушного контроля;
Службы пограничного и таможенного контроля (для международного перелета);
Поставщик и заправщик топлива;
Организация, занимающаяся техническим обслуживанием воздушных судов;
Поставщики питания и других услуг;
Оператор программы лояльности, если пассажир являются участником подобной программы;
Страховая компания, если пассажир приобрел дополнительную страховку.

Усложним задачу

Всем участникам процесса необходимо иметь актуальные данные, связанные с их частью организации перевозки. А именно:

Данные о времени прибытия борта, назначенное место стоянки воздушного судна;
Информацию о проданном билете;
Реестр зарегистрированных на рейс пассажиров;
Данные о наличии необходимых виз и прохождении паспортного и таможенного контроля;
Данные об оказанных услугах в аэропорту, включая питание и топливное обслуживание — объемы услуг и точное время оказания услуг;
Информацию о проведении технических контрольных и ремонтных мероприятиях;
Информацию о прохождении предполетного контроля экипажа и многое другое.

При этом на некоторые информационные потоки могут налагаться дополнительные требования. Например, обмен данными с несколькими независимыми источниками / потребителями с аутентификаций источников информации или поддержание неизменности истории изменения данных с возможностью аудита.

Обмен данными

Печатные документы vs Excel vs API vs…?

Все организации имеет информационные системы, связанные с управлением операционной деятельностью, учетом доходов и расходов, при этом степень автоматизации информационного взаимодействия с контрагентами варьируется от передачи печатных документов, с последующим переносом в цифровые хранилища данных, до использования различных механизмов интеграции:

Экспорт / импорт файлов

различных форматов (CSV, XML, Excel…)

Платформы

В сфере гражданской авиации работают глобальные платформы для взаимодействия организаций в процессе авиаперевозок:

BSP (Billing and Settlement Plan);
GDS (Global Distribution System);
PSS (Passenger Service System).

О них мы писали в нашей предыдущей статье. Платформы работают как сервис и поддерживаются такими ассоциациями и компаниями как IATA, SITA, Amadeus и др. Все текущие платформы централизованы: есть организация, предоставляющая сервис, все программное обеспечение, серверные мощности находятся под ее управлением. С точки зрения разработки и поддержки систем, обеспечение уровня сервиса — это удобно, однако есть и свои минусы:

Дополнительные расходы участников процесса, связанные с оплатой услуг платформ;
Передача информации внешней организации. Данные, имеющие бизнес-ценность, могут быть скомпрометированы или доступны третьим лицам;
Провайдер услуги может влиять на правила информационного взаимодействия.

API

Использование API позволяет организовать непосредственное взаимодействие между контрагентами. Одним из стандартов API является NDC (New Distribution Capabilities), предназначенный для прямой продажи билетов и дополнительных услуг. В то же время при взаимодействии с контрагентами при наземном обслуживании подобных
стандартов еще нет, фрагментарная реализация сервисов интеграции данных не основывается на общепринятых стандартах.

API это инструмент коллаборации между контрагентами, позволяющий превратить бизнес или организацию в платформу. Однако потенциальное создание API для всех вариантов взаимодействия контрагентов может с одной стороны привести к централизации сервисов, через которые идет взаимодействие, с другой стороны — к росту количества и типов интеграций и усложнению информационного ландшафта организаций.

Блокчейн ?

Мы имеем:

Множество источников данных, которые должны собираться в одно информационное поле;
Критичную важность корректности данных, источников происхождения и времени появления;
Прямой обмен данными предпочтительнее использования посредников при передаче данных.

Применение технологии блокчейн / распределенного реестра — выглядит логичной часть решения сложной задачи, которую мы обозначили в самом начале: перевести пассажира из точки «А» в точку «В». Благодаря этой технологии, все участники процесса получают одну версию данных, и они не тратят время и другие ресурсы на согласование и обсуждение.

Единая версия данных для множества участников

Используя возможности распределенного реестра организации могут по своим правилам, оперативно, с контролем времени и источника сообщения, а также факта доставки, обмениваться информацией с минимально необходимой или нулевой степенью раскрытия в схеме взаимодействия, когда несколько организаций получают и отправляют данные, связанные с определенным контекстом — пассажир, авиарейс, ULD (Unit load device, авиа-контейнер) и т.д.

Основная ценность технологии распределенного реестра основывается на двух ключевых элементах.

проверенное происхождение данных (хотя блокчейн НЕ гарантирует достоверность данных, но действительно дает понять, кто какие данные поместил в книгу и когда);
контролируемые процессы — все участники могут видеть и понимать, как данные проходят через заранее согласованный, запрограммированный процесс.

Смарт-контракты

Правила обмена данными можно описать в виде смарт-контрактов, которые определяют модель данных по определенному процессу. Смарт-контракт выполняется в нейтральной среде распределенного реестра, защищенной от доступа или влияния третьих лиц, гарантирующей фиксацию хронологической последовательности внесения информации сторонами, формируя тем самым аудиторский след.

В коде смарт-контракта определяются уровни доступа к данным, кто и при каких условиях может вносить данные. Помимо организаций, участников процесса, важным источником данных являются «оракулы» — информационные системы, переносящие данные из внешней среды в блокчейн. «Оракулами» могут являться, например:

сертифицированные массомеры в топливозаправочных автомобилях;
биржи, предоставляющие текущие курсы валют;
системы распознавания образов.

Доступ к данным из внешней среды дает возможность автоматизировать выполнение условий сделки, алгоритмов расчета стоимости услуг.

Выглядит неплохо, как это реализовать ?

v1.0: Ethereum

В 2017 году S7 Airlines, в партнерстве с Альфа-Банком, одной из первых авиакомпаний запустила в промышленную эксплуатацию проект на базе технологии блокчейн, который сейчас активно используются в процессе взаимодействия S7 Airlines с агентской сетью, и позволяет связать данные о продаже авиабилетов с платежными операциями.

Процесс информационного и платежного взаимодействия с агентами рассматривался как частный случай создания бизнес-сетей, целью которых является ускорение бизнес- и производственных процессов, сокращение операционных издержек за счет прямого и защищенного информационного и платежного взаимодействия организаций.

Блокчейн-платформа, разрабатываемая S7 Техлаб, сразу предусматривала построение сетей для процессов, в котором организации обмениваются бизнес-информацией и при достижении некоторых условий смарт-контракт инициирует банковский платеж. Чтобы транзакции, размещенные в блокчейн, имели юридические последствия, был разработан юридический фреймворк, в том числе позволяющий банку проводить платежи на основе данных из блокчейн транзакции.

Первая версия блокчейн-платформы была реализована на базе протокола Ethereum, с использованием консенсуса Proof-Of-Authority, в котором на уровне системных смарт-контрактов определялся круг организаций — валидаторов, а также модель доступа. Для этого использовались возможности клиента Parity.

Архитектура предусматривала развертывание под определенный процесс отдельной сети. Основные роли участников:

Организация-участник определенного процесса (например, при продаже билетов, это агент или авиакомпания)
Банк, обеспечивающий платежи, инициируемые транзакцией, размещенной в блокчейн.

On-chain компоненты первой версии платформы (смарт-контракты) были реализованы на Solidity с применением техник обновления смарт контрактов, что в смарт-контрактах на базе EVM (Ethereum Virtual Machine) создает ряд затруднений в разработке и поддержке. Off-chain компоненты были реализованы главным образом на JavaScript / Node.JS, так как наиболее стабильные библиотеки (web3.js, truffle и другие) реализованы именно на этом стеке.

Блокчейн-платформа на базе протокола Ethereum стала хорошим стартом, так как в 2017 году это была наиболее стабильная технология, поддерживающая смарт-контракты, с массой доступных библиотек, однако при дальнейшем расширении требований и развитии функциональности, мы столкнулись с рядом ограничений, присущих протоколу Ethereum:

Транзакции не являются финальными, принимаются простым большинством голосов узлов — валидаторов;
Единый реестр операций, доступный всем участникам. Решения на базе Quorum и других расширенных реализаций клиентов Ethereum с поддержкой приватных транзакций в 2017 году были еще нестабильны;
Solidity, как язык разработки, имел значительные ограничения на реализуемую логику. Реализовать сложную логику было проблематично: например, при достижении определенного количества используемых переменных в смарт-контракте компилятор выдавал ошибку stack too deep и дальнейшее расширении логики смарт контракта приходилось проводить со значительными технологическими ухищрениями.

v2.0: Hyperledger Fabric

Во второй половине 2017 года вышла стабильная версия фреймворка Hyperledger Fabric 1.0 с такими возможностями как:

Двухфазный коммит;
Изоляция данных на основе каналов;
Идентификация на базе PKI;
Гибкая модель конфигурирования участников сети (Membership Service Provider);
Продвинутая система настройки разрешений на операции (policies);
Единая кодовая база на Go.

Это убедило вести дальнейшее развитие блокчейн-платформы на базе этого фреймворка. Время показало, что выбор был правильным: сейчас значительная часть создаваемых корпоративных проектов промышленного уровня на базе распределенного реестра использует технологию Hyperledger Fabric. Создание распределенных между организациями систем предполагает знакомство всех участников с применяемыми технологиями, поэтому документированность, известные практики использования и уровень принятия рынком Hyperledger Fabric упрощает взаимодействие с партнерами.

Блокчейн-технологии в 2017 году (да и на текущий момент тоже) находятся на этапе бурного развития и нам пришлось пройти путь разработки значительного количества собственных компонент, столкнувшись с такими проблемами как:

Отсутствие best practices при разработке и тестировании блокчейн приложений;
Отсутствие простого и стабильного SDK на Go;
Отсутствие практик поддержания уровня сервиса сети (конфигурация сети, мониторинг узлов, решение нештатных ситуаций и пр.)
Сложное изменение конфигурации участников сети.

За два года развития блокчейн-платформы S7 мы прошли путь от ручного развертывания сетей и написания простых смарт-контрактов до формирования инструментария, с помощью которого мы можем быстро создавать блокчейн-сети с внешними партнерами. С учетом опыта развертывания отдельных проектов мы разработали:

Средства развертывания компонент сети в K8S, либо на любых виртуальных серверах / облачных сервисах;
Децентрализованное управление сетью и доступом к сети;
Средства мониторинга и поддержания уровня обслуживания;
Компоненты разработки смарт-контрактов и off-chain приложений, включая шифрование данных;
Шлюзы к банкам для проведения платежных операций.

Open source

Часть наших разработок мы выложили в open source:

cckit

библиотека, позволяющая структурированно разрабатывать смарт-контракты. Последняя версия также содержит средства кодогенерации на базе мета-описаний gRPC-сервисов и protobuf — сообщений, позволяющие специфицировать интерфейсы смарт-контрактов (чейн-кодов) Hyperledger Fabric, а также автоматизировать создание SDK для взаимодействия со смарт-контрактами.

Помимо этого, реализованы следующие возможности:

Маршрутизация (routing) обращений к функциям;
Функции промежуточной обработки (middleware);
Object-state mapping;
Расширенная реализация MockStub.

hlf-sdk-go

собственный упрощённый SDK:

Простые и понятные компоненты;
Подключаемые discovery provider и crypto suite;
Встроенные GRPC-метрики;
Балансировка вызовов GRPC на базе go-grpc;
Отдельный пакет для работы с Fabric CA;
Трейсинг операций на основе OpenTracing (Jaeger).

Текущие проекты

С использованием данного инструментария разработано уже несколько проектов:

Система взаимодействия между авиакомпаниями и поставщиками топлива

На основании цифрового смарт-контракта в системе AFSC (Aviation fuel smart contracts) S7 Airlines и поставщик топлива согласовывают предварительный объем топлива и его цену. Эти данные используются для назначения технического задания водителю топливозаправщика в аэропорту. После того как командир воздушного судна запросит у оператора точный объем топлива, необходимый для выполнения рейса, в банк авиакомпании направляется онлайн-заявка для резервирования соответствующей суммы на счете. Моментальное подтверждение из банка дает старт заправке.

Новая версия платформы взаимодействия с прямыми агентами S7

которая находится в промышленной эксплуатации (обороты уже превысили 300 млн руб. в месяц). Аналогичная система внедряется также для сторонней крупной транспортной компании.

Ряд проектов находится в разработке, в том числе и связанные с взаимодействием с аэропортами и компаниями, обеспечивающими наземное обслуживание самолетов.

Трансформация индустрии

В каких проектах технология блокчейн может вывести авиацию, как отрасль, на еще более высокий уровень? Пожалуй, самое важное — безопасность полетов. Блокчейн может выступать в качестве виртуального журнала, где будет записываться вся информация об обслуживании отдельных частей самолета: откуда они прибыли, кто с ними работал, куда они направляются далее и пр. Благодаря такой прозрачности, блокчейн может подтолкнуть авиационную безопасность на совершенно новый уровень.

А еще программы лояльности. Вот лишь один пример: токенизация баллов лояльности позволит им быть более ликвидным и удобным для клиента инструментом. Они могут обеспечивать сквозное взаимодействие в индустрии путешествий между авиакомпаниями, отелями, судоходными компаниями и компаниями по аренде автомобилей.

И это далеко не все. Несмотря на то, что текущие примеры– это пока первые шаги, применение блокчейн с высокой степенью вероятности окажет огромное влияние на трансформацию индустрии гражданской авиации в области информационного и платежного взаимодействия, что, безусловно, поможет сделать процесс взаимодействия «пассажир — авиаперевозчик» еще более удобным и надежным.

Ценность для бизнеса

По оценке Building Value with Blockchain Technology: How to Evaluate Blockchain«s
Benefits от Международного экономического форума, индустрия гражданской авиации и сферы путешествий в целом в наибольшей степени могут получить преимущества в части автоматизации взаимодействия с использованием смарт-контрактов, единой версии данных для всех участников процесса и возможностей создавать новые типы продуктов и сервисов. В первую очередь, за счет модернизации технологий, обслуживающих информационные потоки между партнерами.

На базе блокчейн могут быть реализованы процессы, требующие платежного взаимодействия (оплата услуг аэропортов/поставщиков топлива и так далее или взаимные платежи по договорам интерлайна), так и процессы с платежами не связанные, например, факты выполнения рейсов.

Смарт-контракты могут содержать заранее согласованные между партнерами правила для автоматизированной проверки условий и выполнения действий, в том числе платежных, что позволит значительно снизить ручную работу, создающую задержки и потенциальные ошибки.

Временные метки, которыми сопровождаются все блокчейн-транзакции, также могут
позволить контролировать соглашения об уровне обслуживания (SLA), например в при
выполнении технологического графика обслуживания воздушного судна в аэропорту.
Максимальной эффективности подобные решения достигнут в сочетании с технологиями интернета вещей (IoT) и машинного распознавания образов — факты, хранимые и учитываемые в смарт-контрактах смогут поступать в блокчейн максимально автоматизировано, без участия человека.

Подводные камни

Для бизнес-сетей актуальна схема консорциума, в которой узлы сети поддерживают отдельные организации — участники сети. Доступ к узлам сети могут иметь как участники консорциума, так и внешние организации, в зависимости от требований по интероперабельности. Рассмотрим основные препятствия при создании бизнес-сетей.

С точки зрения бизнеса:

Идентификация процесса взаимодействия контрагентов, при которой действительно требуется децентрализованность. Проработка структуры информационного взаимодействия, условия доступности данных;
Корректная оценка влияния изменения парадигмы взаимодействия с контрагентами и стоимости внедрения;
Организация работы в консорциуме контрагентов, в том числе прямых конкурентов.

С точки зрения технологий:

Отсутствие в настоящее время «идеальных» алгоритмов работы распределенной сети, сочетающих в себе безопасность, масштабируемость и децентрализацию (выберите 2 из 3);
Отсутствие стандартизированных подходов к разработке смарт-контрактов и юридических практик;
Отсутствие лучших практик при создании подобных систем.

Главное, что минусы — это не препятствия, а зоны роста. Тем интереснее будущее, нам есть над чем работать.