Программная платформа и информационная модель ситуационного центра

В России активно развивается такой инструмент управления, как ситуационные центры, в том числе для организации управления в чрезвычайных ситуациях. Организация управления в чрезвычайных ситуациях имеет высокую важноств. Так, по данным МЧС России, толвко в 2017 году на территории Российской Федерации было зарегистрировано 257 чрезвычайных ситуаций (далее - ЧС), в резулвтате которых пострадало 36 402 человека, и погибло 556 человек [1]. В приказе МЧС России [2] упоминаются следующие типы ЧС:

• •    техногенные чрезвычайные ситуации;

• •    природные чрезвычайные ситуации;

• •    биолого-социальные чрезвычайные ситуации;

• •    крупные террористические акты.

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

Принятие стандартов для обмена информацией является общемировой практикой. Ряд из них принят в качестве международных стандартов, либо рекомендован для применения национальными правительствами. Так, в 2003 году Emergency Management Technical Committee (Технический Комитет по Чрезвычайным Ситуациям), входящий в консорциум OASIS, разработал структурированный язык Emergency Data Exchange Language (язык обмена данными по чрезвычайным ситуациям, далее EDXL). Данный язык представляет собой набор стандартов обмена сообщениями на основе XML, которые облегчают обмен информацией по ЧС между государственными структурами и полным спектром организаций, связанных с ЧС. В настоящее время EDXL содержит в себе следующие стандарты:

• •    Distribution Element (EDXL-DE) - отвечает за маршрутизацию EDXL сообщений (например, предупреждений или сообщений о ресурсах) путем включения информации о координатах, инциденте и идентификаторе отправителя или получателя.

• •    Resource Message (EDXL-RM) - описывает набор стандартных сообщений для обмена данными между информационными системами, которые координируют запросы на аварийное оборудование и предметы снабжения.

• •    Hospital Availability Exchange (EDXL-HAVE) - служит для предоставления информации о госпиталях, такой как количество свободных коек и доступные ресурсы.

• •    Common Alerting Protocol (EDXL-САР) - используется для информирования о ЧС.

• •    Situation Reporting (EDXL-SitRep) - предназначен для получения и передачи своевременных отчетов о ситуации, призван ускорить принятие обоснованных управленческих решений по инцидентам, необходимых для эффективного реагирования и адаптации к ЧС, облегчая общение между различными организациями.

• •    Tracking of Emergency Patients (EDXL-TEP) - отвечает за информацию о пострадавших в ЧС: их местоположение, транспортировка, состояние.

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

Цель данной работы: исследовать возможность построения информационной модели работы ситуационного центра на основе вышеперечисленных стандартов.

В данной статье рассматриваются:

• •    жизненный цикл управления чрезвычайной ситуацией;

• е    структуры стандартов EDXL-RM, EDXL-САР, EDXL-SitRep;

• •    модели реальных ситуаций, в которых применяется EDXL;

• •    программная платформа и ее реализация.

2.    Жизненный цикл управления чрезвычайной ситуацией

Жизненный цикл управления большинством чрезвычайных ситуаций (ЧС) включает в себя 5 этапов [3]:

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

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

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

• 4)    Ликвидация последствий. Этап ликвидации состоит из мероприятий, направленных стабилизацию ситуации и восстановление функционирования важнейших общественных ресурсов. Этап ликвидации последствий начинается сразу же после того, как угроза жизни и здоровью людей уменьшилась. Цель данного этапа - вернуть пострадавшую область к нормальному функционированию.

• 5)    Подготовка к повторному возникновению ЧС. На последнем этапе жизненного цикла ЧС проводятся мероприятия, направленные на снижение риска порчи имущества и возникновения человеческих жертв. Например, после наводнения поднимают здания и строят дамбы.

Этапы жизненного цикла управления чрезвычайной ситуацией связаны между собой (рис. 1):

Рис. 1. Жизненный цикл управления чрезвычайной ситуацией

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

• 1)    оценка ситуации, начиная с получения первого сообщения о ЧС до составления полного (насколько возможно) описания ситуации, включая оповещение всех, кого может затрагивать ЧС;

• 2)    оценка необходимых действий и требуемых ресурсов (сил и средств — СиС) и принятие решения;

• 3)    мобилизация необходимых СиС;

• 4)    контроль исполнения в процессе осуществления мероприятий по ликвидации последствий;

• 5)    принятие решения о завершении мероприятий по реагированию на основании получения донесений об исполнении;

• 6)    завершающие действия:

• -    демобилизация (освобождение) СиС;

• -    оповещение заинтересованных сторон;

• -    составление отчётов.

3.    Описание стандартов EDXL 3.1.    EDXL-CAP

При помощи стандартов EDXL можно полностью описать процесс реагирования на ЧС от ее возникновения до окончательного урегулирования.

В рамках данной статьи к рассмотрению предложены три стандарта EDXL: EDXL-CAP, EDXL-RM, EDXL-SitRep. С их помощью можно охватить жизненный цикл управления большинством ЧС: информирование о ЧС, запрос ресурсов, доклады о ситуации.

Common Alerting Protocol представляет собой основанный на XML формат данных для обмена информацией о событиях и угрозах, связанных с безопасностью и комфортностью жизнедеятельности. САР является средством обмена критической информацией в гетерогенной информационной среде, поддерживается множеством ведомственных и публичных информационных систем во всем мире.

В Российской Федерации стандарт САР, определенный в Рекомендации Международного Союза Электросвязи МСЭ-Т Х.1303 и принятый Организацией по развитию стандартов структурированной информации, является рекомендованным протоколом взаимодействия КСЭОН (комплексная система экстренного оповещения населения об угрозе возникновения или о возникновении чрезвычайных ситуаций) с сетями связи [4].

САР обеспечивает открытый цифровой формат сообщений для всех типов оповещений и уведомлений. САР поддерживает следующие функции:

• •    географическое позиционирование с использованием широты и долготы, а также других геопространственных представлений в трехмерном пространстве;

• •    поддержку многоязычности;

• •    усовершенствованные возможности обновления сообщений и их отмены;

• •    поддержку стандартов цифрового шифрования и подписи;

• •    работу с мультимедиа файлами (изображения, звук, видео).

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

На рис. 2 представлена структура XML, содержащего САР сообщение. Подробное описание каждого из элементов XML можно найти в документации OASIS [5]. Для успешной отправки САР сообщения события, как минимум, должны содержать:

• •    уникальные идентификаторы: события (Incident ID), сообщения (Message ID), отправителя (Sender ID), предыдущих сообщений (Reference ID);

• •    дату и время события (Sent Date/Time);

• •    тип сообщения;

• •    статус сообщения;

• •    информацию о событии: категорию события (Event Category), тип события (Event Туре), срочность (Urgency), уровень угрозы жизни (Saverity), вероятность (Certainty);

• •    информацию о прикрепленных файлах (если они есть);

• •    информацию о месте происшествия.

3.2.    EDXL-RM

Рис. 2. Структура XML, содержащего САР сообщение. В скобках указано название соответствующего элемента в XML. Полужирным выделены поля, которые заполнить нужно обязательно. Курсивом выделены поля, имеющие значение по умолчанию, которое будет использовано, если поля окажутся незаполненными. Знак * означает, что может быть несколько элементов этого поля.

Главная цель стандарта Resource Messaging заключается в предоставлении набора стандартных форматов XML-сообщений для реагирования на ЧС. Процесс урегулирования чрезвычайной ситуации можно разделить на три стадии:

• •    обнаружение;

• •    планирование;

• •    развертывание.

Как видно на рис. 3, 16 различных видов EDXL-RM сообщений, описанных в таблице 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.

ResponseToRequestResource	Тип сообщения, используемого для ответа на сообщения типа «RequestResource». Позволяет перечислить ресурсы (ресурсы), которые, по мнению предоставляющей ресурсы организации, соответствуют запросам	Поставщик
RequisitionResource	Сообщение, используемое для «заказа» определенного ресурса или для подтверждения того, что определенный ресурс «заказан»	Потребитель
CommitResource	Используется для согласования передачи определенного ресурса в ответ на «RequestResoure»	Поставщик
Requestinformation	Сообщение для уточнения информации о ресурсах.	Потребитель, поставщик
ResponseToRequestlnformation	Используется для ответа на сообщения типа «Requestinformation»	Потребитель, поставщик
OfferUnsolicitedResource	Данный тип сообщения используется, чтобы предложить ресурсы, которые не были запрошены, но могут понадобиться в ходе урегулирования ЧС	Поставщик
ReleaseResource	Сообщение, используемое для отправки обратно к поставщику	Потребитель
RequestReturn	Сообщение для запроса на отправку ресурсов обратно к поставщику	Поставщик
ResponseToRequestReturn	Сообщение, используемое для ответа на сообщение типа «RequestReturn» и содержащее в себе информацию о том, возможно ли вернуть ресурс	Потребитель
RequestQuote	Используется для запроса у поставщика цены ресурса	Потребитель
ResponseToRequestQuote	Используется для ответа на «RequestQuote» и содержит в себе информацию о цене ресурсов	Поставщик
RequestResourceDeployment Status	Используется для запроса текущего статуса ресурса	Потребитель, поставщик
RequestExtendedDeployment Duration	Сообщение, используемое для продления срока использования ресурса	Потребитель
ResponseToRequestExtended DeploymentDuration	Сообщение, используемое для ответа на сообщение типа «RequestExtendedDeploymentDuration»	Потребитель

3.3.    EDXL-SitRep

Стандарт Situation Reporting предоставляет собой набор стандартных форматов XML-сообщений о ЧС, специально предназначенного для передачи своевременных отчетов о ситуации, чтобы ускорить принятие обоснованных управленческих решений по инцидентам, необходимых для эффективного реагирования на аварийные ситуации, облегчая обмен информацией между различными организациями и службами.

Чрезвычайные происшествия требуют незамедлительной реакции на любые виды изменений в ситуации. Чтобы ситуационный центр и команда реагирования принимали пра- вильные и своевременные решения, необходимо получать актуальную информацию об инциденте. Стандарт EDXL-SitRep обладает следующими свойствами:

• •    беспрепятственный обмен информацией;

• •    актуальность предоставляемой информации;

• •    поддержка всех типов опасности и ЧС любого масштаба;

• •    поддержка полного жизненного цикла ЧС;

• •    минимизация ручного и дублирующего ввода информации;

• •    эффективное взаимодействие со всеми стандартами EDXL;

• •    позволяет просматривать информацию о маршрутизации сообщений.

4.    Примеры использования EDXL

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

Аналогично, как и Resource Message, SitRep полностью описывается таблицами и Element Reference Model. На рис. 5 представлена верхнеуровневая модель ERM, которая описывает стандарт SitRep и структуру XML в целом. Более подробно ERM для всех 5 типов SitRep, описанных в таблице 1.2, представлены в документации стандарта [7].

Таблица. 1.2. Типы сообщений Situation Reporting

Тип сообщения	Описание	Отправитель
FieldObservationType	Основной отчет, описывающий наблюдения	Ситуационный и командный центры
SituationlnformationType	Тип сообщений, используемый для предоставления ответов на. запросы ресурсов и информации о потребностях в ресурсах	Ситуационный и командный центры
ResponseResourcesTotalsType	Тип сообщений, используемый для предоставления ответов на. запросы ресурсов, информации о потребностях в ресурсах и их распределении	Командный центр и отдел логистики
CasualtyAndlllness SummaryType	Тип сообщений, используемый для обобщения информации, относящейся к числу и статусу жертв	Командный центр, отдел логистики, медицинские службы
ManagementReporting SummaryType	Данный тип сообщений используется для обобщения информации и данных, относящихся к текущему урегулированию последствий ЧС	Командный центр, отдел логистики, отдел по связям с общественностью

Рассмотренные стандарты структурного языка. EDXL позволяют наладить быстрый и эффективный обмен сообщениями в случае возникновения чрезвычайной ситуации. В таблице 1.3 представлен возможный сценарий обмена. XML-сообщениями с использованием стандартов EDXL на примере реагирования на вымышленное дорожно-транспортное происшествие с участием автоцистерны и легкового автомобиля.

Assignmentinformation

+ Quantity

+ Restrictions

+ AnticipatedFunction

+ PriceQuote

+ Order

Assignmentinstructions

+ ModeOfTransportation

+ Navigation Instruction

+ Reportinginstructions

RequestedArrival

EstimatedArrival

ActualArrival

Req uested Departu re EstimatedDeparture ActualDeparture

Req uested Retu rnArrival EstimatedReturnArrival

Actual Retu rnArrival

Req uested Retu rn Depa rtu re EstimatedReturnDeparture ActualReturnDeparture

Committed

BeginAvailable EndAvailable

Current

ReportTo

Route

Рис. 4. Структура XML, содержащего RM сообщение

Таблица 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	Проинформированы: ДДС МЧС, Скорая помощь, ГК «Автодор», ЦБДД, ГУДХ, ФКУ «Центравтомагистраль», ГИБДД.	EDXL-CAP
08.08.17 9:40	МЧС направляет к месту происшествия пожарный расчет	EDXL-Sitrep
08.08.17 9:40	ГИБДД направляет к месту происшествия наряд ДПС	EDXL-Sitrep
08.08.17 9:40	Скорая помощь направляет к месту происшествия брига ДУ	EDXL-Sitrep
08.08.17 9:55	Прибывший на место ДТП наряд ДПС вводит частичное перекрытие движения, а также обнаруживает необходимость вызова спецтехники для подъёма автоцистерны, эвакуатора для транспортировки легкового автомобиля и тягача для транспортировки автоцистерны	EDXL-RM
08.08.17 9:57	Проведено информирование владельцев смежных дорог федерального и регионального значения	EDXL-Sitrep
08.08.17 9:57	Проведено информирование РЖД о возможности образования затора на Ж/Д-переезде у посёлка Львовский	EDXL-Sitrep
08.08.17 10:00	ЦБДД вводит временные ограничения, назначает пути объезда	EDXL-Sitrep
08.08.17 10:02	Направлены информационные сообщения на табло оповещения на смежных дорогах	EDXL-Sitrep
08.08.17 10:05	Прибывшая на место ДТП бригада скорой помощи диагностирует у одного из пострадавших черепно-мозговую травму (ЧМТ), требуется срочная госпитализация в клинику с наличием томографа и возможностью проведения операции на головном мозге	EDXL-HAVE
08.08.17 10:07	Получено подтверждение о наличии автокрана нужной грузоподъёмности от АТП-21, ул. Станционная, 3, Домодедово, Московская обл.	EDXL-RM
08.08.17 10:10	Получено подтверждение только из НИИ скорой помощи им. Склифосовского	EDXL-HAVE
08.08.17 10:15	Запрос вертолёта для транспортировки пострадавшего	EDXL-RM
08.08.17 10:20	Двое пострадавших в состоянии средней тяжести отправлены с бригадой скорой помощи в клинику г. Подольска	EDXL-TEP
08.08.17 10:50	Пострадавший с ЧМТ отправлен вертолётом в НИИ скорой помощи им. Склифосовского
08.08.17 11:05	Прибыл автокран для подъёма автоцистерны	EDXL-RM
08.08.17 11:25	Прибыл эвакуатор	EDXL-RM
08.08.17 11:55	Прибыл тягач	EDXL-RM
08.08.17 12:05	Последствия ДТП устранены	EDXL-RM
08.08.17 12:05	Проведено информирование владельцев смежных дорог федерального и регионального значения	EDXL-Sitrep
08.08.17 12:06	Отменены все временные ограничения, проведено информирование РЖД	EDXL-Sitrep
08.08.17 12:07	Сняты информационные сообщения на табло оповещения на смежных дорогах	EDXL-Sitrep

5.    Программная платформа и ее реализация

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

SitRep

SitRepType

+ ActionPlan

+ AuthorizedBy

+ ForTimePeriod

+ IncidentID

+ IncidentLifecyclePhase

+ MessagelD

+ NextContact

+ OriginatingMessagelD

+ PrecedingMessagelD

+ Report

+ Reportconfidence

+ ReportingLocation

+ ReportNumber

+ ReportPurpose

+ ReportTitle

+ Reportversion

+ Severity

+ Urgency

Рис. 5. Структура XML, содержащего SitRep сообщение

Ситуационные центры и их программные платформы уже на протяжении многих лет успешно применяются при управлении чрезвычайными ситуациями в различных городах и странах. Например, развернутый в 2010 году ситуационный центр в Рио-де-Жанейро позволил в полной мере использовать все городские технологические устройства: 560 камер наружного наблюдения, 100 датчиков осадков, 8800 GPS-датчиков в автобусах. Централизованное управление чрезвычайными ситуациями позволило снизить время их ликвидирования на 30 процентов [8].

Компанией ЗАО «ЦОСиВТ» была разработана программная платформа ситуационного центра «COSOC», использующая стандарт EDXL-CAP, в которой на данный момент реализованы:

• •    отправка и хранение САР-сообщений;

• •    отображение САР-сообщений на карте и в виде списка;

• •    фильтр САР-сообщений по дате, времени и типу ЧС;

• •    поиск САР-сообщений по ключевым фразам;

• •    расчет метрик и визуализация аналитики;

• •    шлюзы для интеграции с другими сервисами.

Для создания программной платформы использовалась модульная среда Apache Karaf, внутри которой развернута база данных Apache Cassandra и приложения Java для взаимодействия с ней (сохранение САР и пересчет метрик). Из базы данных информация для отображения на сайте передается с помощью JSON (JavaScript Object Notation). На рис. 6 приведена схема взаимодействия использованных технологий.

Рис. 6. Использованные в создании ситуационного центра технологии и схема их взаимодействия

Метеосводка содержит в себе данные о температуре, осадках, скорости ветра и давлении. В случае превышения значения одного или нескольких параметров над пороговым формируется САР-сообщение типа «alert» о соответствующей погодной аномалии. Примеры использования сервиса показаны на рис. 7.

Рис. 7. Пример использования сервиса предупреждения о погодных аномалиях

Данный функционал полностью охватывает этап оповещения о ЧС, который является наиболее важным, так как именно своевременное и информативное оповещение позволяет избежать жертв, принять правильные решения и существенно сэкономить время и ресурсы (рис. 8).

Очевидно, что для охвата всего жизненного цикла ЧС в данной программной платформе необходимо аналогично реализовать компоненты для EDXL-SitRep и EDXL-RM, которые будут иметь практически такой же как у существующей компоненты для EDXL-CAP функционал. Также в перспективе можно добавить EDXL-HAVE и EDXL-TEP для эффективного взаимодействия с медицинскими службами и организациями. На рис. 9 показана возможная схема взаимодействия между компонентами ситуационного центра.

а)

б)

Рис. 8. Реагирование служб оповещения: без использования стандарта EDXL-CAP (а) и с использованием стандарта EDXL-CAP (б)

Рис. 9. Охват жизненного цикла ЧС с помощью программной реализации стандартов EDXL (в скобках указаны используемые стандарты сообщений)

6.    Рассуждения о построении информационной модели ситуационного центра

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

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

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

На первый взгляд может показаться, что стандарт EDXL-Sitrep смотрится наиболее подходящим кандидатом на роль «универсальной информационной модели чрезвычайной ситуации». Но это верно лишь отчасти. Сообщение в формате EDXL-Sitrep даёт лишь «моментальный снимок» ситуации в определённый момент времени, но не содержит в себе никаких правил, позволяющих понять (т.е. рассчитать) - как эта ситуация будет разви- ваться дальше, и каковы должны быть управляющие воздействия, чтобы заставить ситуацию развиваться в нужном направлении. Например, чем нужно тушить трансформаторную подстанцию, какое количество огнетушащего вещества и сколько единиц техники для этого нужно? Для формализованного и структурированного описания подобных знаний и правил, очевидно, нужны специальные модели данных, которых нет в вышеописанных стандартах. Данные знания, безусловно, существуют и зафиксированы во многочисленных наставлениях экстренных служб и выучиваются их операторами до того, как они смогут приступить к работе. Но если ставить задачу задействовать автоматизированные средства обработки поступающей информации, вплоть до алгоритмов формальной логики, эти знания необходимо преобразовать в структурированный формализованный вид, пригодный для машинной обработки. На наш взгляд - это и есть наиболее актуальная задача в дальнейшей разработке ПО ситуационных центров.

7.    Выводы

В работе рассмотрены стандарты семейства EDXL, разработанные консорциумом OASIS для оповещения о чрезвычайных ситуациях (ЧС) и информационного взаимодействия служб и ведомств по реагированию на ЧС и ликвидации их последствий. Цель исследования заключалась в оценке их применимости в качестве возможной основы для создания информационной модели работы ситуационного центра. Исследован вариант применения одного из стандартов (EDXL-САР) в программной реализации ситуационного центра (программный комплекс «COSOC» компании АО «ЦОСиВТ») и описана использованная программная платформа. Показано, что использование всего набора имеющихся стандартов EDXL позволяет решить задачу эффективного взаимодействия информационных систем различных служб и ведомств в течение всего жизненного цикла ЧС. В то же время отмечено, что исследованных в работе стандартов недостаточно для построения полноценной информационной модели работы собственно самого ситуационного центра, и, следовательно, необходима дальнейшая работа по исследованию и обобщению соответствующего опыта и имеющихся наработок в этом направлении.

Работа выполнена в рамках пилотного проекта по созданию интеграционного модуля АС «Безопасный город» Новгородской области.