31 августа «Аэрофлот» ввёл в промышленную эксплуатацию информационную систему «Купол». Это программная платформа для поддержания лётной годности, техобслуживания и ремонта. Ею заменили AMOS – продукт швейцарской Swiss AviationSoftware, с 2023 года стопроцентной дочерней компании Lufthansa Technik. «Аэрофлот» выбрал AMOS в 2013 году, вывел в промышленную эксплуатацию летом 2017-го (внедрением занимался «Рамакс Интернейшнл») и связал её с SAP, с Sabre и напрямую с системами Boeing и Airbus.
Было бы неправильно называть «Купол» чем-то вроде «программы для механиков». По логике работы система очень близка к бухгалтерскому софту, только предметом учёта в ней служит остаток ресурса, а «закрытие отчётного периода» происходит перед каждым вылетом.
Лётная годность в авиации – это не столько техническое состояние (как, например, у автомобиля в те времена, когда техосмотр ещё не отменили), сколько юридическое, и подтверждать его приходится большим пакетом документов. По каждому агрегату на самолёте должна быть информация, откуда он взялся, сколько отработал, что с ним делали, кто расписался и на основании чего. Агрегат без бумаг – это бездок кусок железа, который нельзя ставить на самолёт, даже если он новый и в заводской упаковке.
Но давайте начнём с печенегов. Вернее, с программы техобслуживания. Производитель самолёта выпускает MPD (Maintenance Planning Document, «документ по планированию технического обслуживания»): документ, куда сведены все обязательные работы по планеру, системам и двигателям, от «осмотреть визуально» до «снять, разобрать, дефектовать». У каждой задачи свой интервал, и выражается он одновременно в лётных часах, циклах (то есть, взлётах-посадках) и календарном времени. Авиакомпания на базе MPD разрабатывает собственную программу техобслуживания, утверждает её у авиавластей и дальше обслуживает свой флот по ней. Для понимания масштабов: для обычного узкофюзеляжника типа A320 или B737 в этой программе несколько тысяч позиций.
После каждого рейса конкретного самолёта в систему загружаются данные о фактической наработке, они автоматически «раскидываются» по всем компонентам, тут логика простая: каждый компонент наследует налёт того борта, на котором установлен, поэтому любая перестановка агрегата между самолётами означает пересчёт остатков сразу для обоих. Одни детали имеют жёсткий назначенный ресурс: диск турбины отработал свои циклы – в утиль, даже если выглядит как с завода. Другие эксплуатируются по состоянию и снимаются по факту отказа или по результатам осмотра. Третьи ограничены календарём и сроком хранения – это расходники типа резины, аккумуляторов, кислородных баллонов, технических жидкостей.
Система обеспечивает также прослеживаемость истории: у каждого съёмного агрегата есть «биография» от выхода с конвейера завода-изготовителя до текущей позиции на борту – где стоял, сколько наработал, в каких ремонтах побывал, что там с ним делали и по какой документации. Это называется back-to-birth trace, и когда самолёт передаётся другому эксплуатанту или возвращается лизингодателю, именно эту историю по каждой позиции проверяют месяцами.
Также в системе хранятся директивы лётной годности и сервисные бюллетени. Регулятор или производитель выпускает документ: на самолётах такого-то типа с такими-то заводскими номерами в такой-то срок или при таком-то налёте сделать то-то. Система сопоставляет применимость директивы с собственным парком, ставит задачи в план и ведёт статус выполнения по каждому борту.
Конечно же, хранятся и все неисправности. Экипаж записывает замечание в бортжурнал, инженер либо устраняет его, либо откладывает по MEL (Minimum Equipment List, перечень минимального исправного оборудования), где расписано, с какими дефектами летать можно и как долго, а с какими нет. Неисправности разбиты на категогии: категория B даёт 3 дня на ремонт, C – 10, D – 120, у категории A срок прописывается индивидуально по каждой позиции.
Для каждого отложенного дефекта тикают собственные часики, и система должна вовремя сообщить, что завтра он превратится в AOG, то есть, запрет на вылет. Плюс повторяющиеся осмотры: нашли на обшивке вмятину в допустимых пределах – поставили на контроль и смотрите с заданной периодичностью.
Самое интересное в «Куполе» – планирование. Он берёт плановое расписание, анализирует его и показывает, когда какая задача подойдёт к сроку. Теперь нужно всё это оптимизировать: тысячи разрозненных операций собрать в пакеты так, чтобы борт нужно было загонять в ангар пореже, а каждый «чек» закрывал максимальное количество подходящих сроков. Слишком рано – сожжёшь часть ресурса впустую, потому что интервал следующего осмотра отсчитывается от выполнения предыдущего. Слишком поздно – самолёт будет стоять на земле.
Всё это ещё надо распределить по ангарам, стоянкам и сменам, потому что мест и людей конечное количество, и увязать с расписанием, чтобы борт оказался в базовом аэропорту именно тогда, когда его там ждут. Сутки внепланового простоя широкофюзеляжника стоят как небольшая квартира в Лобне, так что качество оптимизации вполне себе измеряется деньгами.
На основе плана оформляется резервирование запчастей под конкретный чек, заказы поставщикам с учётом сроков поставки, отправка снятых агрегатов в ремонт и контроль возврата, обменные фонды и т.п. Когда дело доходит до самих работ, формируются карты заданий; механики их выполняют, ответственные специалисты подписывают акты, на основении которых потом выдаётся СЛГ. Система хранит данные о том, кто, когда и что именно сделал, какую деталь поставил, каким инструментом пользовался и когда этот инструмент последний раз поверяли.
Система также накапливает статистику наработки по каждому типу агрегата, задержки и отмены с разбивкой по техническим причинам, повторяющиеся отказы, претензии поставщикам. Это даёт возможность обслуживания по состоянию: интервалы осмотров подгоняются под реальную картину отказов. В перспективе заработает и предиктивная аналитика, которая позволит заменить агрегат до того, как он с большой вероятностью выйдет из строя.
Конечно, миграция с одной такой системы на другую – процедура тяжёлая. Переносить приходится всю историю парка: остатки ресурсов по десяткам тысяч серийных номеров, статусы выполнения директив, открытые дефекты с их таймерами, программы ТО, складские остатки, справочники деталей и их взаимозаменяемости. Поэтому такие переходы требуют долгой опытной эксплуатации, когда обе системы работают, так что «промышленная эксплуатация» означает, что старую, наконец, выключили.
«Купол» – один из четырёх особо значимых проектов индустриального центра компетенций «Авиационный транспорт» наряду с системой бронирования «Леонардо» вместо Sabre и Amadeus, «Авиационной сервисной платформой» вместо сетей передачи данных SITA и ARINC и системой управления авиационной безопасностью.
Работает система на PostgreSQL и Astra Linux, системный интегратор — «РТ-Проектные технологии» из «Ростеха», разработчик — ИЦ ИАС, у которого до этого были похожие решения по МС-21, SJ-100 и двигателям ПД-14 и ПД-8.
Заявлено также, что «Купол» «…превзойдёт по ряду функций мирового лидера», что вполне вероятно: система написана с нуля, в то время ядро AMOS писали в девяностых, и возраст там чувствуется. Трёхмерные модели агрегатов и интерактивные руководства вместо перелистывания AMM – вещь приятная и местами реально полезная; наносить повреждения на трёхмерную модель фюзеляжа удобнее, чем на бумажную развёртку, и искать их потом проще.