Сегодня я хотел бы продолжить публикацию своих рассказов об опыте управления проектами по созданию различного рода автоматизированных систем. Если в позапрошлый раз я писал о некотором лабораторном исследовании типа proof-of-concept из области комплексной автоматизации (см. статью «Стенд Комплексной Автоматизации: описание опыта разработки»), а в прошлый раз — об опыте построения АСУ реального времени на железнодорожном транспорте (см. статью «Опыт разработки АСУ реального времени для железной дороги»), то сегодня я расскажу о том, как мы разрабатывали Систему поддержки принятия решений при ликвидации последствий дорожно-транспортных происшествий при участии транспортных средств, перевозящих опасные грузы. Именно такой была тема работы, по результатам которой должен был возникнуть прототип системы.

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

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

1. Разработка моделей принятия решений в условиях ликвидации последствий ДТП
2. Разработка программного обеспечения системы, реализующего созданные модели
3. Подготовка аппаратно-технического обеспечения системы
4. Разработка организационно-распорядительной документации
5. Проведение организационно-технических мероприятий по апробации реализованного прототипа

Наиболее интересной частью являлась первое направление работ. Именно его я взял в свои личные руки как исполнитель (а не как руководитель проекта), примерив на себя ещё и роль методолога. Разработка модели заняла примерно полгода, при этом приходилось очень тесно взаимодействовать с коллегами из ДОУ МЧС России, с которыми мы прорабатывали вопросы долабораторного распознавания неизвестных отравляющих или опасных веществ.

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

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

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

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

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

1. Применение Т-нормы (нечёткое умножение) к фактическому значению параметра и значению из базы знаний.
2. Применение Т-конормы (нечёткое сложение) к полученным результатам Т-нормирования по всем выделенным фактически наблюдаемым параметрам.
3. Ранжирование полученных в результате Т-конормирования значений по убыванию.
4. Нормализация проранжированных значений в интервал [0, 1].
5. Отсечение нерелевантных предположений по порогу 0.6.
6. Валидация полученных результатов по информации о формальных параметрах.

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

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

1. Хлор, уверенность в гипотезе — 0.88.
2. Хлорпикрин, уверенность в гипотезе — 0.81.
3. …
4. Ацетилен, уверенность в гипотезе — 0.60.

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

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

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

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

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

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

Результатом выполненного проекта стал работающий прототип клиентского приложения системы. В перспективе планировалось разработать общую базу знаний по опасным веществам, а также базу знаний по принятым решениям, чтобы при тренировке групп ликвидации рассматривать уже пройденные события. Прототип был внедрён в ДОУ МЧС России в опытную эксплуатацию. К сожалению, мне неизвестна дальнейшая судьба этой разработки.

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

Описание моего опыта управления проектами по разработке и внедрению автоматизированных систем управления и информационных систем:

1. Стенд Комплексной Автоматизации: описание опыта разработки
2. Комментарии к героическому эпосу в трёх рунах о внедрении MIS
3. Опыт разработки АСУ реального времени для железной дороги

Автор: Darkus

Источник