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

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

УУ = РР + ИИ,

где УУ — успешный успех, РР — решительные решения, а ИИ — это искусственный интеллект. Все это, конечно, просто шутка на злобу дня — но, как известно, в любой шутке есть доля правды. В данном случае ремонт самолета, как и любое преодоление проблем, — это просто череда верных решений и правильных действий, поиск которых наверняка можно как-то облегчить. Раз так, то почему бы не придумать помощника в принятии решений? Собственно, так и появились DSS (Decision Support System, или СППР — системы поддержки принятия решений) — невероятно полезные системы, о которых практически ничего неизвестно. В этой статьей мы попробуем узнать, что это такое и как оно работает (и починим самолет заодно).

Проблема — это задача

Замечали ли вы, что в подавляющем большинстве маленькие дети действуют по принципу "вижу цель — не вижу преград"? В каком-то смысле DSS возвращает нас в детство, ведь эта система так же уверенно ведет нас к цели. Например, вам необходимо улететь из города A в город B: сейчас вам не придется создавать маршруты из всех доступных рейсов и ранжировать их по куче параметров самостоятельно, ведь есть метапоисковик, который сделает эту работу за вас. Все, что останется сделать вам, — это выбрать что-то из предложенного, то есть принять решение.

Помог ли вам метапоисковик? Да. Заметили ли вы колоссальную работу, которую он проделал? Нет.

Понять, что перед нами именно DSS, а не калькулятор, довольно просто:

1. DSS работают только в конкретных предметных областях — например, метапоисковик авиабилетов работает с маршрутами.

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

3. DSS работают только с альтернативными вариантами будущего, к которым могут приводить те или иные решения. Например, последствия выбора какого-то маршрута могут быть самыми разными — метапоисковик это понимает и ранжирует выдачу в соответствии некоторыми критериями, тем самым помогая обосновать принимаемое решение.

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

Что и как моделировать

В DSS данные и знания играют фундаментальную роль. Можно сказать, что DSS стали появляться, как только люди начали визуализировать данные и систематизировать знания.

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

Помимо данных, есть еще и знания. Если их правильно систематизировать и организовать, то на выходе тоже может получиться практически полноценная DSS. Рассмотрим медицинские знания: абстрактно можно сказать, что все они состоят из событий — это могут быть события, состоящие в постановке диагноза или назначении лечения. События можно хранить по старинке, записывая их от руки в медицинские карты, но лучше, чтобы они хранились в базе данных. Вот тут нам поможет то, что в такой предметной области как медицина есть ограниченное количество понятий, из которых можно составлять элементарные (атомарные) факты.

Допустим, некоторый факт может быть задан в виде пары понятий:

где — это множество конечных последовательностей некоторого алфавита (слова или строки).

Первый элемент в паре может выступать в качестве общего абстрактного понятия:

Второе понятие в данной паре может уточнять первое:

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

Исходя из такого определения события следует, что его легко можно представить в виде вектора. Тогда такое событие как постановка диагноза можно представить в виде логического условия, которое можно перекодировать в вектор, состоящий из булевых (бинарных) элементов 0 и 1. Тогда постановка диагноза может быть описана простым выражением:

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

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

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

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

Прецеденты, как и логические условия, тоже можно моделировать в виде векторов:

• — это параметры, описывающие ситуацию, условие или проблему;

• — количество параметров;

• — множества допустимых значений, соответствующих параметрам;

• — решение.

Теперь давайте подумаем, как можно найти идентичный или схожий прецедент. Поскольку перед нами вектор — точка из некоторого n-мерного пространства, то первое и самое простое что приходит на ум — это метод ближайшего соседа. Допустим, задан прецедент и некоторая проблемная ситуация . Тогда степень сходства (близости) можно определить с помощью самых разных метрик расстояния:

• Евклидова метрика (евклидово расстояние):

• Квадрат евклидового расстояния:

• Манхэттенская метрика:

• Расстояние Чебышева:

• Мера близости Журавлева:

где

• Мера сходства по Хэммингу:

где — число совпадающих признаков (параметров) у прецедента и проблемы .

От выбора меры сходства зависит очень многое — например, большинство значений векторов и являются дискретными, причем значения конкретного параметра носят категориальный характер и могут кодироваться самыми разными способами (Label Encoder, One-Hot Encoder, Binary Encoder, Contrast Encoding и т.д.). Таким образом использование самой привычной для нас евклидовой метрики может оказаться далеко не лучшим решением. А вот манхеттенская метрика и сходство по Хэммингу, как правило, показывают гораздо лучшие результаты.

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

Не всё ИИ, что с нейросетями

Пример с моделированием медицинских знаний дает хорошее представление о том, чего можно ожидать, заглянув "под капот" DSS. Лечебный процесс — это идеальная аналогия для процесса поиска и устранения неисправностей в пассажирском авиалайнере. Как сделать DSS, которая могла бы нам помочь в поиске и устранении неисправностей?

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

Если к системам самолета есть централизованный доступ, то БСТО объединит, обобщит и, если надо, скоррелирует всю информацию, до которой сможет добраться. Такие системы могут быть встроенными или поставляться отдельно в виде ноутбука, снабженного самыми разными алгоритмами контроля.

Приборная панель может сообщить не только о поломках, но об их причинах или возможном скором появлении, но далеко не всегда. БСТО как раз и необходима для тщательного анализа возможных причин любых отклонений от нормальной работы. Например, падение давления масла в двигателе может иметь разные причины:

• неполадки в работе масляного насоса;

• загрязнение фильтра;

• износ подшипников;

• повреждение уплотнений и трубопроводов;

• попадание посторонних предметов или жидкостей в масляную систему;

• неправильное подключение оборудования или трубопроводов.

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

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

На примере медицинских знаний мы убедились, что они могут быть как минимум структурированы. Например, мы можем взять РПУН и преобразовать его в веб-сайт, сделать на нем все необходимые разделы, посвященные каждой из систем самолета, а те разбить на подразделы и так далее. Опять же по такому сайту надо тыкать пальцами. А если поломка сложная, то все равно придется держать открытыми несколько вкладок, да еще и самому думать, в каком порядке по ним двигаться. Как же сделать, чтобы последовательность действий появлялась сама? Вспоминаем про XML — такой формат не совсем удобен для человека, но идеален для структурирования данных и для программ. Однако, чтобы структурировать знания, необходимо создать онтологию.

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

Чтобы создать свою онтологию, можно воспользоваться Protege — специализированной программой, облегчающей такой труд. Благодаря Protege, после анализа всех руководств по устранению неисправностей системы электроснабжения Сухой Суперджет получается онтология состоящая из 355 понятий и 1066 аксиом, описывающих основные системы, подсистемы и операции в соответствии с их различными классификациями. Основная цель этапа создания онтологии состоит в том, чтобы определить список основных операций (работ) и их взаимосвязей в контексте проявления определенных признаков неисправностей или отказов. Описания необходимых работ по устранению одной из неисправностей в такой онтологии могут выглядеть следующим образом:

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

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

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

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

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

Возникает вполне закономерный вопрос — где тут искусственный интеллект, и как он вообще может стоять рядом с табличными редакторами? Тут важно отметить еще раз: у нас есть знания — они имеют четкую структуру и они строго формализуются в виде векторов. В то же время каждый вектор представляет собой определенное состояние системы, а определенные действия переводят систему из одного состояния в другое, то есть преобразуют один вектор в другой. Фактически это означает, что мы можем соединять векторы (точки в n-мерном пространстве) стрелками, получая тем самым структуру, похожую на граф.

Процесс диагностирования и устранения неисправностей можно представить в виде ориентированного графа, который, как и обычный граф, может быть задан в виде матрицы смежности. Поскольку каждая дуга носит либо логический характер, либо характер действия, то и матрица смежности приобретает особую структурно-логическую форму. Зачем же нужен такой граф? Поломки бывают очень сложными, а чем больше элементов самолета мы учитываем, тем больше размерностей мы добавляем в пространство. Если элементов всего 500, то опытный специалист может самостоятельно прикинуть более-менее оптимальный план действий. Если их 50000, то лучше прибегнуть к помощи. Человеку очень сложно решать такие задачи, как:

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

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

• Поиск циклов — например, если нужно покрасить пол и потолок в разные цвета, то лучше начать с потолка, иначе придется чистить и красить пол дважды.

• Формирование параллельных маршрутов — важно для выполнения работ несколькими командами.

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

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

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

Создание DSS — это еще и ответственность, порой даже слишком большая ответственность.

Диагностическиое моделирование

Может ли самолет быть полностью работоспособным и неисправным одновременно? Такие состояния кажутся взаимоисключающими, но на самом деле такое более чем возможно. Есть системы: топливная, гидравлическая, электроснабжения, которые обязательно дублируются. Если дублирующая или основная система выходит из строя, то самолет останется полностью работоспособным, но неисправным, ведь поломок, согласно требованиям, не должно быть вообще. Помимо понятия "работоспособность", есть еще такое понятие как "надежность", которое напрямую влияет на степень безопасности.

Диагностирование можно выполнять с помощью логических функций, но при разработке DSS крайне важно понимать, откуда эти функции берутся. И тут тоже все довольно просто: чтобы понять, что с объектом что-то не так, а именно продиагностировать его, — достаточно просто описать все его возможные состояния. Описание может быть словесным, графическим, аналитическим, табличным или векторным. Например, степень износа каких-то деталей может измеряться в микрометрах — есть какая-то нормальная или допустимая область износа, но есть разные значения, которые могут вызывать различные негативные последствия.

В общем случае состояние объекта может определяться параметрами, а каждому параметру ставится в соответствие -степеней деградации. Слово "деградация" используется, чтобы подчеркнуть, что значения параметров ранжируются по шкале "лучше / хуже", а не "больше / меньше". Тогда определенной комбинации значений параметров будет соответствовать определенное состояние объекта. Допустим, у объекта всего два параметра — и , и каждый из них может принимать всего четыре значения: 0 — отсутствие деградации, 3 — максимальная деградация. Тогда диагностическая модель может выглядеть следующим образом:

Наш объект "живет" в двумерном пространстве и у него всего 16 состояний в которых он может находиться. Но согласитесь, таблица выглядит замысловатей, чем можно было бы ожидать. Все дело в категориях состояния, самые очевидные для нас это:

• Объект исправен — .

• Объект неисправен — .

Двух таких категорий хватит только для машины до и после краш-теста. На самом деле их больше, например:

• Неработоспособное состояние.

• Неисправное состояние — объект может быть как работоспособным, так и нет. Например, на автомобиле можно ехать и на трех колесах, да и сами колеса можно прикрутить не на четыре а на три болта — все зависит от требований к объекту, которые мы считаем приемлемыми.

• Состояние повреждения — приемлемая разновидность неисправного состояния, при которой объект все еще может работать, но не так хорошо, как хотелось бы.

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

Чтобы отнести объект к одной из категорий, он должен соответствовать определенным критериям. В нашем примере определенной категории соответствует конкретная степень деградации хотя бы одного из параметров: если хотя бы один из параметров равен 2, то он будет соответствовать категории , если 3 — то . При этом каждая категория может иметь подкатегории — в нашем примере они соответствуют конкретным значениям суммы значений деградации параметров.

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

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

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

Нужна DSS для поиска неисправностей? Сделайте ее сами в АвиаТехПом!

Итак, у нас есть сломанный пассажирский авиалайнер, и мы рассмотрели базовые принципы, на которых работают системы поддержки принятия решений. Можем ли мы опереться на эти принципы и создать собственную DSS? В теории да, но вот в чем дело — моделей авиалайнеров очень много, а ведь помимо них есть и другие типы самолетов и даже вертолетов. Неужели потребуется создавать DSS отдельно для каждого типа и модели?

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

• CAS (Crew Alerting System) — системы оповещения экипажей;

• БСТО — бортовые системы технического обслуживания;

• РПУН-ы — руководства по поиску и устранению неисправностей;

• КУНАТ-ы — карточки учета неисправностей авиационной техники;

• диагностические модели.

Гораздо проще и намного разумнее сделать программную оболочку для создания специализированных DSS, чем создавать десятки отдельных DSS. Именно так и появилась система АвиаТехПом — авиационный технический помощник.

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

Так выглядит экран с результатами поиска причин неисправности по внешним проявлениям и сигналам CAS.

Данный интерфейс удобен в том числе и для ввода и редактирования как знаний (РПУН-ы), так и прецедентов (КУНАТ-ы). Возможность ввода и редактирования обязательно нужна при создании баз знаний и прецедентов, но она также крайне важна и при их последующем дополнении. Это может показаться чем-то формальным и даже бюрократическим, но в качестве примера можно привести отличие между руководствами от разных компаний. Одни производители в своих руководствах предусмотрительно предупреждают техников о разных нюансах, например, о том что некоторый агрегат является довольно тяжелым и может привести к травмам или дополнительным поломкам при демонтаже, в то время как другие в своих руководствах просто пишут: "Демонтируйте данный агрегат".

Помимо десктопной версии, есть также и web-интерфейс:

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

Большинство DSS, поставляемых производителями воздушных судов, на самом деле вовсе не являются таковыми системами. По сути поставляемые ими решения — это просто поисковики, которые подсчитывают количество найденных слов в pdf-докуметах, составляющих документацию. Это, конечно, облегчает поиск необходимой информации, но над планом работ всё равно придется думать самостоятельно.

Все перечисленное крайне важно для создания DSS, но настоящим гарантом надежности и безопасности являются диагностические модели. Их также можно создавать в АвиаТехПом:

Выглядит сложновато, особенно если учесть, что АвиаТехПом позиционируется как оболочка для создания DSS непрограммирующими пользователями. Однако стоит  согласиться с тем, что диагностические модели — это слишком критичные для безопасности и надежности элементы DSS. Всё же с ними должны работать люди, обладающие специальными знаниями.

При описании принципов работы DSS неоднократно упоминалась важность многокритериальной оптимизации. Для многокритериальной диагностики в АвиаТехПом также есть отдельный модуль:

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

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

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

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

Когда речь заходит о конкретной DSS, то ее нужно сравнить с аналогами. Фраза "аналогов нет" в данном случае это действительно актуальна. Ближайшим аналогом АвиаТехПом-а является AirNav, разработанная в Airbus. Вот только в АвиаТехПом-е можно создать и AirNav, и DSS для Боинга, да хоть для Ми-171. Чтобы создать DSS в АвиаТехПом под нужды какого-то конкретного воздушного судна, он даже не обязан иметь БСТО.

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

Вместо заключения посчитаем профит

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

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

И правда, бухгалтер может счесть процесс диагностики очень быстрым. Если вдруг причину неисправности ищут неделю или даже месяц, то это просто какое-то ненормальное отклонение — выброс, который портит всю статистику. А что мы обычно делаем с выбросами? Мы их просто не учитываем в моделировании. В данном же случае это является "законной" частью выборки, которую ни в коем случае нельзя исключать. Есть же распределения с очень тяжелыми хвостами и даже с бесконечной дисперсией. Игнорирование редких событий и неиспользование распределений с тяжелыми хвостами — это просто большая склонность к неоправданному риску.

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

1. Нет возможности зарабатывать деньги по определенному маршруту.

2. Придется возвращать деньги за уже проданные билеты.

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

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

В зависимости от размеров авиакомпании положительный эффект может варьироваться от 0.01%-0.1%, если в авиакомпании больше 100 самолетов, и доходить до нескольких процентов, если количество самолетов в авиакомпании меньше 10. По большому счету дело даже не столько в финансовом эффекте. Гражданские авиаперевозки — это отрасль, в которой безопасность и благополучие пассажиров на первом месте. Если есть хоть малейший шанс их повысить, то его необходимо использовать. АвиаТехПом — это отличный инструмент моделирования состояний воздушных судов и их отдельных систем, способный выявить возможные неисправности. Для ученых, инженеров и конструкторов это — возможность найти изъян и исправить его еще до того, как он натворит бед.