Перед вами четвёртый материал (вот первый, второй и третий) из серии статей, посвящённых информационным технологиям в авиаперевозках. Наша сегодняшняя тема — DCS (Departure Control System, система контроля отправки пассажиров).

Что произошло в 05:30, когда я вошёл в аэропорт Нагпура и GDS выбыла из игры?

На календаре — 8 февраля 2026 года. Время — 5:30. Место действия — Международный аэропорт имени Бхимрао Рамджи Амбедкара, Нагпур.

Стойка регистрации Air India открыта. Перед ней — короткая очередь. Я кладу паспорт. Сотрудница авиакомпании что-то вводит в свой компьютер, бросает взгляд на экран и тут же наклеивает бирку на мой багаж.

То, на что она смотрит — это не GDS.

GDS — Amadeus — система, которая ещё в декабре создала мою PNR-запись с кодом DDTCIV, завершила работу несколько месяцев тому назад. Она подтвердила наличие места, выпустила электронный билет, сохранила информацию о бронировании. С тех пор она уже не принимала особого участия в организации моего путешествия. Сотрудница авиакомпании сверяла мои данные с DCS Amadeus Altéa. Это — самостоятельное приложение, построенное на базе отдельного слоя данных, оптимизированное для задач, совершенно не совпадающих с теми, что решает GDS.

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

Передача управления между системами

GDS хранит коммерческую информацию о бронировании. А PSS, в случае с Air India это — Amadeus Altéa — хранит операционные записи, обслуживающие процесс перевозки. Получается, что GDS и PSS хранят различные, хотя и связанные между собой данные.

Когда в системе планирования авиакомпании создаётся рейс — это запускает целый каскад событий:

DCS активируется примерно за 24 часа до вылета рейса (точный размер временного окна варьируется; он зависит от правил и особенностей авиакомпании; 24 часа — это удобное для восприятия значение, а не универсальный параметр, применяемый повсюду). В этот момент DCS загружает из PSS список пассажиров со сведениями о них. А именно — все записи бронирования с PNR, данные о распределении мест, SSR-запросы, APIS-сведения о пассажирах. После этого DCS превращается в систему регистрации данных для рейса. А GDS становится историческим справочником, доступным только для чтения.

Когда сотрудница авиакомпании проверила моё бронирование в аэропорту NAG — она обращалась именно к DCS. В ответ на её запрос был просмотрен список пассажиров рейса AI416 на 8 февраля. Там было найдено моё имя, произошла сверка состояния моего электронного билета с ETD.

Чем занимается сотрудник авиакомпании, стоящий за стойкой регистрации пассажиров?

Вот что происходит за стойкой регистрации:

Сквозная регистрация багажа, когда один багажный талон используется для всего маршрута NAG→DEL→LHR — это сложная задача, в решении которой участвует несколько авиационных систем. Система маршрутизации багажа должна знать о том, что рейс AI416 стыкуется с рейсом AI2015 по одному и тому же PNR. Ей должно быть известно о том, что оба полётных сегмента оформлены в одном классе обслуживания, и что пересадка в Дели укладывается во временное окно для трансфера багажа. Если любое из этих условий не выполняется — сотрудник оформит две разные багажные бирки на два отдельных полётных сегмента.

О штрихкоде BCBP. Что именно считывает сканер посадочных талонов у выхода на посадку?

Каждый посадочный талон — напечатанный на бумаге, открытый на мобильном устройстве, электронный — содержит штрихкод, оформленный в соответствии со стандартом IATA «Resolution 792 Bar Coded Boarding Pass». В коде зашифрована структурированная строка данных, на считывание которой у сканера посадочных талонов уходит несколько миллисекунд.

Эта строка моего посадочного талона на рейс NAG→DEL выглядит так:

M1SAHASRABUDDHE/AJITEM DDTCIV NAGDEL AI 0416 039Y001A0000

Разберём её:

M1
  Код формата M (BCBP), 1 полётный сегмент (этот посадочный талон покрывает один полётный сегмент)
 
SAHASRABUDDHE/AJITEM
  Имя пассажира: фамилия/имя, дополняется пробелами до 20 символов
 
DDTCIV
  PNR-код: шесть символов из системы бронирования рейсов
 
NAG
  IATA-код аэропорта вылета
 
DEL
  IATA-код аэропорта назначения
 
AI
  IATA-код авиакомпании
 
0416
  Номер рейса, дополняется нулями до 4 цифр
 
039
 Юлианская форма представления даты: день 039 2026 года = 8 февраля
 
Y
  Код класса обслуживания (класс каюты для операционных целей)
  Обратите внимание: здесь Y — класс каюты, а не класс тарифа, обозначаемый как Z
  Салон бизнес-класса в AI на внутренних рейсах в операционных целях
  обозначается как Y
  Такая маркировка используется на узкофюзеляжных самолётах, где
  места бизнес-класса расположены на первых рядах одной кабины самолёта
 
001A
  Номер места: ряд 1, кресло A
 
0000
  Порядковый номер регистрации пассажира на рейс

Сканер посадочных талонов считывает штрихкод, сверяет PNR-код с данными списка пассажиров из DCS, подтверждает статус OPEN (не использован) электронного билета в ETD, меняет его на USED и открывает выход на посадку. В DCS обновляются сведения о количестве пассажиров, прошедших на посадку. Система управления загрузкой и балансировкой самолёта получает сведения о том, что место 01A занято. Если время окончания посадки на рейс истекает и при этом некоторые забронированные места оказываются незанятыми — сотрудник, осуществляющий посадку пассажиров, обращается к DCS для выяснения того, какие именно пассажиры не явились на посадку. После этого начинается процедура снятия пассажиров с рейса.

APIS: невидимый пограничный контроль

До того, как я оказался на борту самолёта, следующего рейсом AI2015 из Дели в Лондон, компания Air India передала мои паспортные данные в МВД Соединённого Королевства через APIS (Advance Passenger Information System, система предварительной информации о пассажире). Это, с 2003 года, обязательная процедура для всех рейсов, следующих в Соединённое Королевство.

Вот что происходит с данными:

Если система МВД сообщит о проблеме, причиной которой может быть визовое несоответствие, нахождение пассажира в списке наблюдения, отсутствие каких-то данных о пассажире, Air India получит уведомление о запрете посадки (No Boarding) до вылета воздушного судна. Пассажиру отказывают в посадке ещё в аэропорту вылета, а не на границе Соединённого Королевства. Именно такая последовательность действий не случайна. Дело в том, что заблаговременное выявление пассажиров, которым запрещён въезд в страну, оказывается гораздо дешевле и проще, чем работа с ними после того, как самолёт попадёт в воздушное пространство Соединённого Королевства.

При передаче данных APIS используется структурированный формат сообщений, передаваемых по сетям SITA. Речь идёт об инфраструктуре для передачи сообщений SITA Type B, упомянутой в 1 части этой серии материалов. Формат сообщений, появившийся в 1949 году, до сих пор используется для передачи паспортных данных.

Почему миграция Air India на систему Altéa — это большое и важное дело?

До 2023 года компания Air India пользовалась устаревшей DCS SITA. Миграция на Amadeus Altéa, осуществляемая поэтапно в 2022-2023 годах, была одной из крупнейших миграций PSS в истории авиации Азии.

Вот что включала в себя эта миграция:

• Перенос рабочей базы данных PNR и многолетней истории бронирования рейсов на платформу Altéa с использованием соответствующей модели данных.

• Реинтеграция в систему программы лояльности Flying Returns.

• Переучивание тысяч сотрудников аэропортов по всей Индии и в заграничных представительствах компании.

• Модернизация интерфейса между системой управления доходами Air India и инвенторным модулем Altéa.

• Перенос в новую систему сведений о соглашениях между авиакомпаниями по совместному обслуживанию перевозок и о совместном использованию кодов рейсов.

• Переработка слоя передачи данных системы APIS.

В первые месяцы после миграции сообщалось о замедлениях системы регистрации в периоды пиковой нагрузки, об ошибках при организации совместного обслуживания пассажиров в рамках соответствующих соглашений, о проблемах, связанных с баллами лояльности. Всё это — вполне ожидаемые последствия перевода работающей системы с одной базы на другую. И сложность этого перехода — это не некая характеристика самой Altéa. Это — особенность миграции. Каждая деталь, которой не уделили должного внимания на этапе планирования, приводила к инцидентам после начала практического использования системы.

Что же досталось компании Air India после миграции? Это — современная PSS, адаптированная под облачные технологии, обладающая улучшенными возможностями NDC (New Distribution Capability, новая дистрибутивная модель). Это — улучшенные инструменты самообслуживания и инфраструктура, которой пользуются дюжины других авиакомпаний, где применяется та же платформа. В результате налицо долгосрочное положительное воздействие перехода Air India на Altéa. Здесь мы сталкиваемся с так называемым «сетевым эффектом», когда ценность системы возрастает по мере роста количества её участников. Улучшения, вносимые в платформу, становятся доступны всем, кто ей пользуется, в том числе — Air India.

Особый путь IndiGo: применение Navitaire в аэропорту NAG

Авиакомпания IndiGo использует систему Navitaire NewSkies. Это — PSS, построенная с нуля для компаний-лоукостеров, для которых характерна высокая частота перелётов и прямые рейсы.

Altéa — это монолитная платформа, обеспечивающая бронирование рейсов, контроль отправки пассажиров, учёт выручки. А Navitaire отличается более высоким уровнем модульности. Входящая в её состав DCS — AirportConnect Open — спроектирована в расчёте на организацию быстрых процедур регистрации на рейс, выполняемых с минимальным уровнем дополнительных сложностей. Она оптимизирована с учётом нужд авиакомпаний, которые способны подготовить только что прилетевший самолёт к следующему вылету за 25, а не за 75 минут.

Особенности и ограничения Navitaire хорошо видны при рассмотрении работы этой системы в аэропорту и при её сравнении с Altéa.

Регистрация на рейс компании IndiGo (Navitaire):

• Быстрая, минималистичная модель данных.

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

• Учёт очков лояльности с использовании отдельной системы.

• Система быстрее и проще, чем Altéa, она создана под решение конкретных задач.

Регистрация на рейс компании Air India (Altéa):

• Доступна полная история PNR.

• Поддержка сложных SSR.

• Поддержка соглашений между авиакомпаниями по совместному обслуживанию перевозок.

• Интеграция программы лояльности.

• Медленнее Navitaire, но даёт доступ к более широкому спектру данных и возможностей.

Система Navitaire хорошо подходит компании IndiGo по той же причине, по которой операционная система TPF до сих пор используется в авиации для учёта ресурсов авиакомпаний. Это — жёсткая специализация и нацеленность на конкретный тип рабочих нагрузок. При этом те издержки, которые сопровождают взаимодействие такой системы с другими системами, принимаются осознанно, а не по случайности. В бизнес-модели IndiGo нет нужды учитывать все те сложности, с которыми сопряжено моё путешествие по маршруту NAG→DEL→LHR. Речь идёт о сквозной регистрации, об особых запросах на питание, о передаче APIS-данных. А так как в системе всё это не обрабатывается — её пользователи за это не платят.

Чем управляется табло отправления авиарейсов?

Данные на табло отправления авиарейсов в аэропорту NAG поступают из DCS Altéa и Navitaire. Эти системы получают новости из системы управления полётами авиакомпании.

Если вылет рейса AI416 задерживается — происходит следующее:

GDS получает пассивное обновление — это уведомление об изменении расписания. Система записывает полученные сведения в PNR, не уведомляя об этом продавцов билетов. Именно так изменилось время вылета рейса AI112 — с 13:00 на 14:15. Произошло это незаметно, где-то между декабрём и февралём. Авиакомпания поменяла своё операционное расписание, Altéa передала данные в GDS, а GDS внесла изменения в PNR, не запуская механизм активного оповещения пассажиров.

Такое поведение заложено в систему. 75-минутный сдвиг расписания находится в пределах обычных операционных колебаний. Система инициирует отправку активных уведомлений только при сдвигах, превышающих настраиваемый порог. Дело в том, что если оповещать каждого пассажира о любом изменении расписания, не превышающем 90 минут — это подорвёт доверие к уведомлениям от авиакомпаний. Сообщения об изменениях в расписании будут содержать больше «шума», чем «полезного сигнала». Пороговое значение, о котором идёт речь, продиктовано не техническими ограничениями, а сознательным решением владельцев системы.

Итоги

Разделение коммерческих процессов и процессов, обеспечивающих операционную деятельность авиакомпаний, позволяет уйти от взаимозависимости систем, когда нагрузка на одну из них влияет на другую. Системы GDS и DCS ориентированы на решение разных задач. Это — соответственно — коммерческие и операционные задачи. Если бы они были тесно взаимосвязаны — это могло бы привести, например, к ситуации, когда скорость регистрации пассажиров на рейсы зависела бы от нагрузки системы бронирования билетов. Подобные ситуации предотвращаются благодаря тому, что в определённый момент (примерно за 24 часа до отправления рейса) одна система передаёт управление другой. После этого GDS превращается в источник справочной информации, а DCS становится системой, отражающей актуальные сведения о рейсе и пассажирах. Подобный паттерн применим во всех случаях, когда две системы имеют разные профили нагрузки и разные требования к консистентности данных. Для его реализации нужно задать момент передачи управления, разграничить зоны ответственности и запретить изменение данных в системе, которая раньше была главной.

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

Пороговые временные значения, позволяющие управлять отправкой уведомлений при изменениях в расписании, задаются владельцами системы и не являются чем-то стандартным. GDS тихо, без рассылки уведомлений, приняла обновления, изменившие время отправления рейса AI112. Это — пример корректной работы системы при сдвиге расписания на 75 минут. Порог рассылки активных уведомлений должен быть установлен на такой уровень, достижение которого предусматривает необходимость какой-то реакции от пассажиров. А вот для всего, что ниже этого порога, хорошо подойдут обновления, выполняемые без уведомлений. Установкой таких значений должны, через настройки, заниматься владельцы системы, а не программисты.