CC BY
58
УДК 004.415.2
С. С. Щербаков1, А. А. Кузнецова1, А. А. Беспалько1, А. С. Галицкий2.
А. В. Хельвас1'2
1 Московский физико-технический институт (государственный университет) 2 ООО «Лаборатория моделирования систем»
Программная платформа и информационная модель
ситуационного центра
В статье рассматриваются стандарты сообщений для передачи информации о чрезвычайных ситуациях и программная платформа для обмена сообщениями между всеми государственными структурами и организациями, связанными с чрезвычайными ситуациями.
Ключевые слова: стандарт сообщений, чрезвычайные ситуации, программная платформа, ситуационный центр. ЕБХЬ.
S.S. Shcherbakov1, A. A. Kuznetsova1, A. A. Bespalko1, A. S. Galitskiy2,
A. V. Khelvas1'2
1 Moscow Institute of Physics and Technology (State University) 2 Systems Simulation Laboratory LLC
Software platform and the information model of a
situational center
The paper considers with message standards for transmitting emergencies information and a software platform for sharing messages with government agencies and the full range of organizations related to emergencies.
Key words: message standard, emergencies, software platform, situation center. EDXL.
1. Введение
В России активно развивается такой инструмент управления, как ситуационные центры, в том числе для организации управления в чрезвычайных ситуациях. Организация управления в чрезвычайных ситуациях имеет высокую важность. Так, но данным МЧС России, только в 2017 году на территории Российской Федерации было зарегистрировано 257 чрезвычайных ситуаций (далее ЧС), в результате которых пострадало 36 402 человека и погибло 556 человек [1|. В приказе МЧС России [2| упоминаются следующие типы ЧС:
• техногенные чрезвычайные ситуации;
• природные чрезвычайные ситуации;
• биолого-социальные чрезвычайные ситуации;
• крупные террористические акты.
© Щербаков С. С., Кузнецова А. А.. Беспалько А. А.. Галицкий А. С., Хельвас А. В. 2018 © Федеральное государственное автономное образовательное учреждение высшего образования «Московский физико-технический институт (государственный университет)». 2018
Урегулирование каждого типа ЧС подчиняется конкретному, заранее определенному сценарию, который задействует экстренные службы в заданном порядке. При этом сценарии реагирования на разные типы ЧС имеют между собой много общего: вызов служб, запрос ресурсов, госпитализацию пострадавших и т.п. Соответственно возникает необходимость разработки информационной модели взаимодействия экстренных служб для каждого из сценариев, использующей структурированный язык обмена информацией.
Принятие стандартов для обмена информацией является общемировой практикой. Ряд из них принят в качестве международных стандартов, либо рекомендован для применения национальными правительствами. Так, в 2003 году Emergency Management Tecimieal Committcc (Технический Комитет по Чрезвычайным Ситуациям), входящий в консорциум OASIS, разработал структурированный язык Emergency Data Exchange Language (язык обмена данными по чрезвычайным ситуациям, далее EDXL). Данный язык представляет собой набор стандартов обмена сообщениями на основе XML, которые облегчают обмен информацией по ЧС между государственными структурами и полным спектром организаций, связанных с ЧС. В настоящее время EDXL содержит в себе следующие стандарты:
• Distribution Elcmcnt (EDXL-DE) отвечает за маршрутизацию EDXL сообщений (например, предупреждений или сообщений о ресурсах) путем включения информации о координатах, инциденте и идентификаторе отправителя или получателя.
• Resource Message (EDXL-RM) описывает набор стандартных сообщений для обмена данными между информационными системами, которые координируют запросы на аварийное оборудование и предметы снабжения.
• Hospital Availabilitv Exchange (EDXL-HAVE) служит для предоставления информации о госпиталях, такой как количество свободных коек и доступные ресурсы.
• Common Alerting Protocol (EDXL-CAP) используется для информирования о ЧС.
• Situation Rcporting (EDXL-SitRep) предназначен для получения и передачи своевременных отчетов о ситуации, призван ускорить принятие обоснованных управленческих решений по инцидентам, необходимых для эффективного реагирования и адаптации к ЧС, облегчая общение между различными организациями.
• Tracking of Emergency Patients (EDXL-TEP) отвечает за информацию о пострадавших в ЧС: их местоположение, транспортировка, состояние.
Комбинируя в различном сочетании перечисленные стандарты EDXL, можно описать в формализованном виде сценарий управления любой возможной чрезвычайной ситуацией от дорожно-транспортного происшествия до аварии на атомной электростанции.
Цель данной работы: исследовать возможность построения информационной модели работы ситуационного центра на основе вышеперечисленных стандартов.
В данной статье рассматриваются:
• жизненный цикл управления чрезвычайной ситуацией;
• структуры стандартов EDXL-RM, EDXL-CAP, EDXL-SitRep;
• модели реальных ситуаций, в которых применяется EDXL;
• программная платформа и ее реализация.
2. Жизненный цикл управления чрезвычайной ситуацией
Жизненный цикл управления большинством чрезвычайных ситуаций (ЧС) включает в себя 5 этапов [3]:
1) Предотвращение. Основное внимание уделяется предотвращению человеческих жертв, главным образом, от возможных стихийных бедствий или террористических (как физических, так и биологических) атак. Меры по предотвращению призваны обеспечить постоянную защиту от стихийных бедствий, так как не все бедствия могут быть предотвращены. Например, эффективные системы оповещения и продуманные планы эвакуации могут существенно снизить риски получения травмы или смерти.
2) Подготовка. В данный этап входят моделирование возможных ситуаций, обучение и оснащение сотрудников экстренных служб. Подготовка фокусируется на готовности реагировать на инциденты и все виды чрезвычайных ситуаций.
3) Реагирование и ликвидация. На данном этапе при помощи ситуационного центра происходит координация служб реагирования и управление ресурсами (оборудование и материалы). Основная цель - устранить угрозу жизни и здоровью людей. Данный этап начинается сразу после возникновения катастрофы или чрезвычайной ситуации.
4) Ликвидация последствий. Этап ликвидации состоит из мероприятий, направленных стабилизацию ситуации и восстановление функционирования важнейших общественных ресурсов. Этап ликвидации последствий начинается сразу же после того, как угроза жизни и здоровью людей уменьшилась. Цель данного этапа - вернуть пострадавшую область к нормальному функционированию.
5) Подготовка к повторному возникновению ЧС. На последнем этапе жизненного цикла ЧС проводятся мероприятия, направленные на снижение риска порчи имущества и возникновения человеческих жертв. Например, после наводнения поднимают здания и строят дамбы.
Этапы жизненного цикла управления чрезвычайной ситуацией связаны между собой (рис. 1):
Рис. 1. Жизненный цикл управления чрезвычайной ситуацией
Этап реагирования и ликвидации, в свою очередь, также можно условно разделить на несколько фаз. Процесс реагирования на ЧС является одним наиболее сложных с точки зрения управления и по разному описан в большом количестве работ, но по нашему мнению, во всех случаях можно выделить следующие ключевые фазы:
1) оценка ситуации, начиная с получения первого сообщения о ЧС до составления полного (насколько возможно) описания ситуации, включая оповещение всех, кого может затрагивать ЧС;
2) оценка необходимых действий и требуемых ресурсов (сил и средств — СиС) и принятие решения;
3) мобилизация необходимых СиС;
4) контроль исполнения в процессе осуществления мероприятий но .ликвидации последствий;
5) принятие решения о завершении мероприятий но реагированию на основании получения донесений об исполнении;
6) завершающие действия:
- демобилизация (освобождение) СиС;
- оповещение заинтересованных сторон;
- составление отчетов.
При помощи стандартов EDXL можно полностью описать процесс реагирования на ЧС от ее возникновения до окончательно!^ урегулирования.
3. Описание стандартов EDXL
В рамках данной статьи к рассмотрению предложены три стандарта EDXL: EDXL-CAP, EDXL-RM, EDXL-SitRep. С их помощью можно охватить жизненный цикл управления большинством ЧС: информирование о ЧС, запрос ресурсов, доклады о ситуации.
3.1. EDXL-САР
Common Alerting Protocol представляет собой основанный на XML формат данных для обмена информацией о событиях и угрозах, связанных с безопасностью и комфортностью жизнедеятельности. САР является средством обмена критической информацией в гетерогенной информационной среде, поддерживается множеством ведомственных и публичных информационных систем во всем мире.
В Российской Федерации стандарт САР, определенный в Рекомендации Международно!^ Союза Электросвязи МСЭ-Т Х.1303 и принятый Организацией но развитию стандартов структурированной информации, является рекомендованным протоколом взаимодействия КСЭОН (комплексная система экетренших) оповещения населения об угрозе возникновения или о возникновении чрезвычайных ситуаций) с сетями связи [4|.
САР обеспечивает открытый цифровой формат сообщений для всех типов оповещений и уведомлений. САР поддерживает следующие функции:
• географическое позиционирование с использованием широты и дол!хугы, а также других !'еонространственных представлений в трехмерном пространстве;
• поддержку многоязычности;
• усовершенствованные возможности обновления сообщений и их отмены;
• поддержку стандартов цифрово!'о шифрования и подписи;
• работу с мультимедиа файлами (изображения, звук, видео).
События являются автономными сообщениями данных, которые moí'vt быть отправлены или получены всеми компонентами. События moí'vt быть опубликованы в очереди сообщений и прочитаны всеми системами, участвующими в информационном обмене. САР помогает стандартизировать содержимое событий так, чтобы несколько доменов могли отправлять и получать события в одном формате с использованием общих преобразований. Стандарт задает обязательные и необязательные ноля в записи события и приемлемые значения для этих нолей. Управление обработкой событий может выполнять роль нроме-жуто4HOÍX) звена между форматами наследования и стандартизированным форматом. САР можно расширить, чтобы обрабатывать ежедневные операции в дополнение к чрезвычайным ситуациям.
На рис. 2 представлена структура XML, содержащих) САР сообщение. Подробное описание каждох'о из элементов XML можно найти в документации OASIS [5]. Для успешной отправки САР сообщения события, как минимум, должны содержать:
• уникальные идентификаторы: события (Incident ID), сообщения (Message ID), отправителя (Sender ID), предыдущих сообщений (Reference ID);
• дату и время события (Sent Date/Time);
• тип сообщения;
• статус сообщения;
• информацию о событии: категорию события (Event Category), тип события (Event Туре), срочность (Urgency), уровень угрозы жизни (Saverity), вероятность (Certainty);
• информацию о прикрепленных файлах (если они есть);
• информацию о месте происшествия.
Language (language) Contact Info (contact)
Description (resourceDesc)
Parameter (parameter)
MiME Type (mimeType)
i—> > V Message ID (identifier) Event Category (category) *
File Size (size)
Sender ID (sender) Resource (resource)
URI (uri)
Sent Date/Time (sent) Event Type (event)
Dereferenced URI (derefUri)
Message Status (status) Response Type (responseType)
Digest (digest)
Message Type (msgType) Urgency (urgency)
Sou rce( source) Severity (severity)
Alert (alert)
Info (info) Certainty (certainly)
Restriction (restriction) Audience (audience)
Addresses (addresses) EventCode (eventCode)
Handlling Code (code) Effective Date/Time (effective)
> 1—> Note(note) ► > Onset Date/Time (onset)
—> —> -> Area Description (areaDesc)
Reference IDs (references) Expiration Date/Time (effective)
Area polygin (poligon) *
Incident IDS (incidents) Headline (headline)
Area Circle (circle) *
Scope(acope) Area (area)
-> Area Geocode (geocode)
Event Description (description)
Altitude (altitude)
information URL (web)
Ceiling (ceiling)
fnstuctions (instruction) Sender Name (senderName)
Рис. 2. Структура XML, содержащего САР сообщение. В скобках указано название соответствующего элемента в XML. Полужирным выделены поля, которые заполнить нужно обязательно. Курсивом выделены поля, имеющие значение по умолчанию, которое будет использовано, если поля окажутся незаполненными. Знак * означает, что может быть несколько элементов этого поля.
3.2. EDXL-RM
Главная цель стандарта Resource Messaging заключается в предоставлении набора стандартных форматов XML-сообщений для реагирования на ЧС. Процесс урегулирования чрезвычайной ситуации можно разделить на три стадии:
• обнаружение;
• планирование;
• развертывание.
Как видно на рис. 3, 16 различных видов ЕОХЬ-КМ сообщений, описанных в таблице 1.1, полностью охватывают процесс урегулирования ЧС, что позволяет эффективно обмениваться информацией о необходимых ресурсах между задействоваными компаниями и службами.
б)
Рис. 3. Взаимодействие между получателем и поставщиком ресурсов на протяжении трех фаз урегулирования последствий ЧС: а) обнаружение, б) планирование, в) развертывание
Структура EDXL-RM полностью описывается с помощью диаграмм и таблиц. Общая структура представлена в виде эталонной модели Element Reference Model (ERM), которая изображена на рис. 4. Общая модель является основой для различных видов RM сообщений. ERM совместно с таблицей 1.1 описывают общую структуру RM, включая структуру отдельных элементов. Как меняется ERM в зависимости от типа EDXL-RM сообщения, можно посмотреть в документации OASIS [6].
Стандарт Resource Messaging позволяет не только существенно ускорить все мероприятия, связанные с запросом и распределением ресурсов, необходимых для реагирования на чрезвычайные ситуации, но и свести возможность возникновения ошибок к минимуму, что очень важно для быстрого и четкого реагирования на ЧС. Это достигается путем автоматизации связанных с управлением ресурсами процессов и установления строгих требований к используемым сообщениям.
Таблица 1.1. Типы сообщений Resource Messaging
Тип сообщения Описание Отправитель
RequestResource Используется для запроса необходимых ресурсов Потребитель
Таблица 1.1. Типы сообщений Resource Messaging.
Response1To Request Resource Тип сообщения, используемого для ответа на сообщения типа «RequestResource». Позволяет перечислить ресурсы (ресурсы), которые, по мнению предоставляющей ресурсы организации, соответствуют запросам Поставщик
RcquisitionRcsourcc Сообщение, используемое для «заказа» определенного ресурса или для подтверждения того, что определенный ресурс «заказан» Потребитель
Commit Resource Используется для согласования передачи определенного ресурса в ответ на « Request Resoure » Поставщик
Rcqucstlnformation Сообщение для уточнения информации о ресурсах. Потребитель, поставщик
Response1To Rcqucstlnformation Используется для ответа на сообщения типа « Request Information » Потребитель, поставщик
Offer UnsolicitedResource Данный тип сообщения используется, чтобы предложить ресурсы, которые не были запрошены, но могут понадобиться в ходе урегулирования ЧС Поставщик
ReleaseResource Сообщение, используемое для отправки обратно к поставщику Потребитель
Request Ret urn Сообщение для запроса на отправку ресурсов обратно к поставщику Поставщик
Response1To Request Ret urn Сообщение, используемое для ответа на сообщение типа «Request Ret urn» и содержащее в себе информацию о том, возможно ли вернуть ресурс Потребитель
RcqucstQuotc Используется для запроса у поставщика цены ресурса Потребитель
Response1To Request Quote Используется для ответа на «RcqucstQuotc» и содержит в себе информацию о цене ресурсов Поставщик
RcqucstRcsourccDcploymcnt Status Используется для запроса текущих) статуса ресурса Потребитель, поставщик
RcqucstExtcndcdDcploymcnt Duration Сообщение, используемое для продления срока использования ресурса Потребитель
Response1To Request Ext ended Deployment Duration Сообщение, используемое для ответа на сообщение типа « Request Ext cndcdDcploymcnt Duration » Потребитель
3.3. EDXL-SitRep
Стандарт Situation Reporting предоставляет собой набор стандартных форматов XML-сообщений о '1С. специально предназначенного для передачи своевременных отчетов о ситуации, чтобы ускорить принятие обоснованных управленческих решений но инцидентам, необходимых для эффективного реагирования на аварийные ситуации, облегчая обмен информацией между различными организациями и службами.
Чрезвычайные происшествия требуют незамедлительной реакции на любые виды изменений в ситуации. Чтобы ситуационный центр и команда реагирования принимали пра-
вильные и своевременные решения, необходимо получать актуальную информацию об инциденте. Стандарт EDXL-SitRep обладает следующими свойствами:
• беспрепятственный обмен информацией;
• актуальность предоставляемой информации;
• поддержка всех типов опасности и ЧС любого масштаба;
• поддержка полного жизненного цикла ЧС;
• минимизация ручного и дублирующего ввода информации;
• эффективное взаимодействие со всеми стандартами EDXL;
• позволяет просматривать информацию о маршрутизации сообщений.
Эти свойства стандарта EDXL-SitRep полезны для экономии времени и оптимизации использования ресурсов, необходимых для реагирования на чрезвычайные ситуации.
Аналогично, как и Resource Message, SitRcp полностью описывается таблицами и Element Reference Model. На рис. 5 представлена верхнеуровневая модель ERM, которая описывает стандарт SitRcp и структуру XML в целом. Более подробно ERM для всех 5 типов SitRcp, описанных в таблице 1.2, представлены в документации стандарта [7].
Таблица 1.2. Типы сообщений Situation Reporting
Тип сообщения
Описание
Отправитель
FieldObservationType
Основной отчет, описывающий наблюдения
Ситуационный и командный центры
Situationinformation Туре
Тип сообщений, используемый для предоставления ответов на запросы ресурсов и информации о потребностях в ресурсах
Ситуационный и командный центры
Response Resources Tot als Туре
Тип сообщений, используемый для предоставления ответов на запросы ресурсов, информации о потребностях в ресурсах и их распределении
Командный центр и отдел логистики
Casualty Andlllness Summary Type
Тип сообщений, используемый для обобщения информации, относящейся к числу и статусу жертв
Командный центр, отдел логистики, медицинские службы
ManagementReporting Summary Туре
Данный тип сообщений используется для обобщения информации и данных, относящихся к текущему урегулированию последствий ЧС
Командный центр, отдел логистики, отдел по связям с общественностью
4. Примеры использования ЕБХЬ
Рассмотренные стандарты структурного языка ЕБХЬ позволяют наладить быстрый и эффективный обмен сообщениями в случае возникновения чрезвычайной ситуации. В таблице 1.3 представлен возможный сценарий обмена ХМЬ-сообщсниями с использованием стандартов ЕОХЬ на примере реагирования на вымышленное дорожно-транспортное происшествие с участием автоцистерны и легкового автомобиля.
Рис. 4. Структура ХМЪ, содержащего ЯМ сообщение
Таблица 1.3. Сценарий обмена сообщениями
Дата и время Описание события Тип сообщения
08.08.17 9:35 Столкновение автоцистерны с легковым автомобилем, с опрокидыванием, без возгорания, есть пострадавшие, есть опасность разлива топлива, трасса А-107, в районе посёлка «Берёзки-1», координаты: 55.3323, 37.5483, Московская обл.
08.08.17 9:37 Поступил сигнал на 112 от водителей, свидетелей ДТП телефонный звонок
Таблица 1.3. Сценарий обмена сообщениями
08.08.17 9:38 Проинформированы: ДДС МЧС, Скорая помощь, ГК «Автодор», ЦБДД, ГУДХ, ФКУ «Центравтомагиетраль», ГИБДД. ЕБХЬ-САР
08.08.17 9:40 МЧС направляет к месту происшествия пожарный расчет К1)Х1.-Янгср
08.08.17 9:40 ГИБДД направляет к месту происшествия наряд ДПС К1)Х1.-Янгср
08.08.17 9:40 Скорая помощь направляет к месту происшествия брнга-ду К1)Х1.-Янгср
08.08.17 9:55 Прибывший на место ДТП наряд ДПС вводит частичное перекрытие движения, а также обнаруживает необходимость вызова снецтехники для подъема автоцистерны, эвакуатора для транспортировки легкового автомобиля и тягача для транспортировки автоцистерны ЕПХТ.-ТШ
08.08.17 9:57 Проведено информирование владельцев смежных дорог федерального и регионального значения К1)Х1.-Янгср
08.08.17 9:57 Проведено информирование РЖД о возможности образования затора на Ж/Д-переезде у поселка Львовский К1)Х1.-Янгср
08.08.17 10:00 ЦБДД вводит временные ограничения, назначает пути объезда К1)Х1.-Янгср
08.08.17 10:02 Направлены информационные сообщения на табло оповещения на смежных дорогах К1)Х1.-Янгср
08.08.17 10:05 Прибывшая на место ДТП бригада скорой помощи диагностирует у одного из пострадавших черепно-мозговую травму (ЧМТ), требуется срочная госпитализация в клинику с наличием томографа и возможностью проведения операции на головном мозге ЕПХТ,-НАУЕ
08.08.17 10:07 Получено подтверждение о наличии автокрана нужной грузоподъёмности от АТП-21, ул. Станционная, 3, Домодедово, Московская обл. ЕПХТ.-ТШ
08.08.17 10:10 Получено подтверждение только из НИИ скорой помощи им. Склифоеовекого ЕПХТ.-НАУЕ
08.08.17 10:15 Запрос вертолёта для транспортировки пострадавших) ЕПХТ.-ТШ
08.08.17 10:20 Двое пострадавших в состоянии средней тяжести отправлены с бригадой скорой помощи в клинику г. Подольска ЕБХЬ-ТЕР
08.08.17 10:50 Пострадавший с ЧМТ отправлен вертолётом в НИИ скорой помощи им. Склифоеовекого
08.08.17 11:05 Прибыл автокран для подъёма автоцистерны ЕПХТ.-ТШ
08.08.17 11:25 Прибыл эвакуатор ЕПХТ.-ТШ
08.08.17 11:55 Прибыл тягач ЕПХТ.-ТШ
08.08.17 12:05 Последствия ДТП устранены ЕПХТ.-ТШ
08.08.17 12:05 Проведено информирование владельцев смежных дорог федерального и регионального значения К1)Х1.-Янгср
08.08.17 12:06 Отменены все временные ограничения, проведено информирование РЖД К1)Х1.-Янгср
08.08.17 12:07 Сняты информационные сообщения на табло оповещения на смежных дорогах К1)Х1.-Янгср
5. Программная платформа и ее реализация
Все рассмотренные выше стандарты ЕТХХГ задают способ информационного обмена сообщениями с ситуационными центрами, но не описывают способы создания этих сообщений
и не гарантируют правильность заполнения полей. Именно поэтому в ситуационном центре помимо стандартов должна присутствовать программная платформа.
SitRep
SitRepType
+ ActionPlan + AuthorizedBy + ForTimePeriod + IncidentID
+ IncidentLifecyde Phase + Message ID + NextContact + OriginatlngMessagelD + PrecedingMessagelD + Report
+ ReportConfidence + ReportingLocation + ReportNumber + ReportPurpose + ReportTitle + ReportVersion + Severity + Urgency
F ie Id O bse rvationTy p e
+ ImmediateNeeds +lmmediateNeedsCategory + Observation Location + ObservationText
Рис. 5. Структура XML, содержащего SitRep сообщение
Ситуационные центры и их программные платформы уже на протяжении многих лет успешно применяются при управлении чрезвычайными ситуациями в различных городах и странах. Например, развернутый в 2010 году ситуационный центр в Рио-де-Жанейро позволил в полной мере использовать все городские технологические устройства: 560 камер наружного наблюдения, 100 датчиков осадков, 8800 GPS-датчиков в автобусах. Централизованное управление чрезвычайными ситуациями позволило снизить время их ликвидирования на 30 процентов [8].
Компанией ЗАО «ЦОСиВТ» была разработана программная платформа ситуационного центра «COSOC», использующая стандарт EDXL-CAP, в которой на данный момент реализованы:
• отправка и хранение САР-сообщений;
• отображение САР-сообщений на карте и в виде списка;
• фильтр САР-сообщений по дате, времени и типу ЧС;
• поиск САР-сообщений по ключевым фразам;
расчет метрик и визуализация аналитики;
• шлюзы для интеграции с другими сервисами.
Для создания программной платформы использовалась модульная среда Apache Karaf, внутри которой развернута база данных Apache Cassandra и приложения Java для взаимодействия с ней (сохранение САР и пересчет метрик). Из базы данных информация для отображения на сайте передается с помощью .JSON (JavaScript Object Notation). На рис. 6 приведена схема взаимодействия использованных технологий.
САР
N САР
Н\ САР
Apache Karaf
XML
маршрутизатор сообщений
сохранение САР
Java пересчет метрик Apache Cassandra
JSON
отображение САР
визуализация аналитики
Рис. 6. Использованные в создании ситуационного центра технологии и схема их взаимодействия
В ходе работы над проектом программной платформы ситуационного центра был разработан и интегрирован в платформу сервис для получения метеосводки, который получает метеорологические данные из открытого API(application programming interface) сайта openweathermap.org.
Метеосводка содержит в себе данные о температуре, осадках, скорости ветра и давлении. В случае превышения значения одного или нескольких параметров над пороговым формируется САР-сообщение типа « alert» о соответствующей погодной аномалии. Примеры использования сервиса показаны на рис. 7.
рд -
fie ola
Seeundária sao Pedro
¿ i
X2 Aar И18 15.03.51 GMT »{¡J 00 Г!
t
|i}l»l4íH>
I Itou I
Пойся ПО jaronoBHy
К Бремя Заголовок У Д С Б 3D
22 Авг 2018 21:04:17 ОМТ+ОЗОО Превышено максимальное Вин *
количество осадим i в
г.Вила-Реал. Осадков 1
за последние три
часа - 2,0 мм
Авг 2018 21:04:17 GMT+03D0 Превышено максимальное О ни *
количество осад»™ i в
гКаштелу-Бранку.
Осадков за
последние три ча& i •
0.24 ММ
Анг 2018 21:04:17 GUT*0300 Превышена II] mi *
максимальная
температура в
г Клштелу-Бранку.
Т-Э1.1ЭС
Авг 2018 21:04:17 GMT+0300 Превышена максимальная S mi •
температура в
г.Эвора. T=35.Q С -
Рис. 7. Пример использования сервиса предупреждения о погодных аномалиях
Данный функционал полностью охватывает этап оповещения о ЧС, который является наиболее важным, так как именно своевременное и информативное оповещение позволяет избежать жертв, принять правильные решения и существенно сэкономить время и ресурсы (рис. 8).
Очевидно, что для охвата всего жизненного цикла ЧС в данной программной платформе необходимо аналогично реализовать компоненты для ЕБХЬ-81111ер и ЕВХЬ-11М, которые будут иметь практически такой же как у существующей компоненты для ЕОХЬ-САР функционал. Также в перспективе можно добавить ЕБХЬ-НАУЕ и ЕБХЬ-ТЕР для эффективного взаимодействия с медицинскими службами и организациями. На рис. 9 показана возможная схема взаимодействия между компонентами ситуационного центра.
Информация о ЧС
Землетрясение}-—-^^
Шторм
Цунами
Пожар
ДТП
<alert>
Информация о ЧС структурируется согласно стандарту САР
ХМ1.
Информация о ЧС представлена в формате САР
Сирена
Радио
Телевидение
Звонки/CMC
б)
Рис. 8. Реагирование служб оповещения: без использования стандарта ЕБХЬ-САР (а) и с использованием стандарта ЕБХЬ-САР (б)
Оповещение о ЧС (EDXL-CAP) Запрос и распределение ресурсов (ЕОХ|_-1Ш) -> Информирование о текущей ситуации (ЕОХЬЗИНер) -* ЧС ликвидирована? Прекращение действий по ликвидации
i i нет
Рис. 9. Охват жизненного цикла ЧС с помощью программной реализации стандартов ЕБХЬ (в скобках указаны используемые стандарты сообщений)
6. Рассуждения о построении информационной модели ситуационного центра
Вернёмся к главной цели данного исследования: достаточно ли рассмотренных выше стандартов для формирования полноценной информационной модели ситуационного центра? Предположим, что недостающие стандарты реализованы, и ситуационный центр может отправлять и получать сообщения в форматах, соответствующих ситуации и предназначению (как в приведенном выше примере в разделе 4). Но при этом остаётся открытым вопрос: каким образом эти сообщения порождаются?
Главная цель создания ситуационного центра - это повышение эффективности принятия решений соответствующими органами управления, т.е. ситуационный центр можно рассматривать как разновидность системы поддержки принятия решений. Но в классической системе поддержки принятия решений помимо источников информации должна присутствовать, как минимум, ещё модель данных. Все описанные выше протоколы задают стандарт информационного обмена ситуационного центра с внешними системами, но не отвечают на вопрос: каким образом эти сообщения порождаются? Кто (или что) отвечает за корректное заполнение полей этих информационных сообщений? В какой момент они должны отправляться? Иными словами, приведенные стандарты описывают процессы обмена информацией ситуационного центра с внешними информационными системами, но никак не описывают то, что происходит внутри самого ситуационного центра.
Для того, чтобы принять правильное решение, нужно иметь некую модель, описывающую все существенные аспекты того вида деятельности, к которому инцидент относится, и в процессе анализа ситуации понять: а) достаточно ли имеющейся информации? б) к каким последствиям может привести тот или иной фактор? К примеру, в приведенном выше сценарии существенным фактором является то, что опрокинувшийся автомобиль является бензовозом, и, следовательно, необходимо учитывать возможность разлива топлива и возгорания. Если бы речь шла, например, о паводке, или вспышке инфекционного заболевания, в расчёт следовало бы принимать совсем другие факторы.
На первый взгляд может показаться, что стандарт ЕБХЬ-Зйтер смотрится наиболее подходящим кандидатом на роль «универсальной информационной модели чрезвычайной ситуации». Но это верно лишь отчасти. Сообщение в формате ЕБХЬ-Зйтер даёт лишь «моментальный снимок» ситуации в определённый момент времени, но не содержит в себе никаких правил, позволяющих понять (т.е. рассчитать) - как эта ситуация будет разви-
ватьея дальше, и каковы должны быть управляющие воздействия, чтобы заставить ситуацию развиваться в нужном направлении. Например, чем нужно тушить трансформаторную подстанцию, какое количество огпетушащего вещества и сколько единиц техники для этого нужно? Для формализованного и структурированного описания подобных знаний и правил, очевидно, нужны специальные модели данных, которых нет в вышеописанных стандартах. Данные знания, безусловно, существуют и зафиксированы во многочисленных наставлениях экстренных служб и выучиваются их операторами до того, как они смогут приступить к работе. Но если ставить задачу задействовать автоматизированные средства обработки поступающей информации, вплоть до алгоритмов формальной логики, эти знания необходимо преобразовать в структурированный формализованный вид, пригодный для машинной обработки. На наш взгляд это и есть наиболее актуальная задача в дальнейшей разработке ПО ситуационных центров.
7. Выводы
В работе рассмотрены стандарты семейства EDXL, разработанные консорциумом OASIS для оповещения о чрезвычайных ситуациях (ЧС) и информационного взаимодействия служб и ведомств но реагированию на ЧС и ликвидации их последствий. Цель исследования заключалась в оценке их применимости в качестве возможной основы для создания информационной модели работы ситуационного центра. Исследован вариант применения одного из стандартов (EDXL-CAP) в программной реализации ситуационного центра (программный комплекс «COSOC» компании АО «ЦОСиВТ») и описана использованная программная платформа. Показано, что использование всего набора имеющихся стандартов EDXL позволяет решить задачу эффективного взаимодействия информационных систем различных служб и ведомств в течение всего жизненного цикла ЧС. В то же время отмечено, что исследованных в работе стандартов недостаточно для построения полноценной информационной модели работы собственно самого ситуационного центра, и, следовательно, необходима дальнейшая работа но исследованию и обобщению соответствующего опыта и имеющихся наработок в этом направлении.
Работа выполнена в рамках пилотного проекта по созданию интеграционного модуля АС «Безопасный город» Новгородской области.
Литература
1. Государственный доклад «О состоянии защиты населения и территорий Российской Федерации от чрезвычайных ситуаций природного и техногенного характера в 2017 году». М.: МЧС России. ФГБУ ВНИИ ГОЧС (ФЦ), 2018. 376 с.
2. Приказ МЧС России от 08.07.2004 X 329 (ред. от 24.02.2009) «Об утверждении критериев информации о чрезвычайных ситуациях». URL: http://\v\v\v.consultant.ru/cons/cgi/onlinc.cgi?rcq doe&base EXP&n 575989&rnd 8F03039EAAC786F773D3979453F82C42Mrom 466216-009075305547919781
3. Herrmann J. Disaster Response Planning and Preparedness: phases of disaster. New York Disaster Intcrfaith Services, 2007.
4. Методические рекомендации но созданию комплексной системы экстренного оповещения населения об угрозе возникновения или о возникновении чрезвычайных ситуаций. МЧС России, 2013. URL: http://\v\v\v.mchs.gov.ru/upload/sitcl/documcnt-ffle/lzBh5iT6xB.pdf
5. Jones Е., West-fall J. \et. al.}. Common Alerting Protocol Version 1.2. OASIS, 2010. URL: http://docs.OcU4is-opcn.org/cmcrgcncy/cap/vl.2/CAP-vl.2.html.
6. Jones E., Dr. Aymond P. \ei. al.}. Emergency Data Exchange Language Resource Messaging (EDXL-RM) 1.0. OASIS, 2009. URL: http://docs.oasis-open.org/emergency/edxl-rm / v 1.0 / E DXL- RM- S P E C-V1.0 .ht ml.
7. Jones E., Brooks R. \et. al.}. Emergency Data Exchange Language Situation Reporting (EDXL-SitRcp) Version 1.0. OASIS, 2016. URL: http://docs.oasis-opcn.org/cmcrgcncy/cdxl-sitrcp/vl.O/cdxl-sitrcp-vl.O.html.
8. 4 Inspirations for Sustainable Transport from Rio de .Janeiro. Benoit Colin, 2015. URL: https://\v\v\VAvri.org/blog/2015/03/4-inspirations-sustainabl(vtransport-rio-dc-jaiiciro
References
1. State report «On the state of protection of the population and territories Of the Russian Federation from natural and man-made emergencies characters in 2017». Russian Emergency Situations Ministry, 2018.
2. Order of Russian Emergency Situations Ministry from 08.07.2004 N 329 (ed. from 24.02.2009) «On approval of information criteria about emergency situations».
3. Jack Herrmann. Disaster Response Planning and Preparedness: phases of disaster. New York Disaster Interfait h Services, 2007.
4. Guidelines for creating a comprehensive system of emergency notification of the population about the threat of or the occurrence of emergency situations. Russian Emergency Situations Ministry, 2013.
5. Jones E., West-fall J., et. al., Common Alerting Protocol Version 1.2. OASIS, 2010. URL: http://d0cs.0asis-0pcn.0rg/cmcrgcncy/cap/vl.2/CAP-vl.2.html.
6. Jones E., Dr. Aymond P., e.t. al., Emergency Data Exchange Language Resource Messaging (EDXL-RM) 1.0. OASIS, 2009. URL: http://docs.oasis-opcn.org/emcrgency/cdxl-r m / v 1.0 / E DXL- RM- S P E C-V1.0. ht ml.
7. Jones E., Brooks /?.. e.t. al., Emergency Data Exchange Language Situation Reporting (EDXL-SitRcp) Version 1.0. OASIS, 2016. URL: http://docs.oasis-opcn.org/cmcrgcncy/cdxl-sitrcp/vl.O/cdxl-sitrcp-vl.O.html.
8. 4 Inspirations for Sustainable Transport from Rio de .Janeiro. Benoit Colin, 2015. URL: https://www.wri.org/blog/2015/03/4-inspirations-sustainablc-traiisport-rio-dc-janciro
Поступила в редакцию 23.11.2018
