Программные продукты и системы

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

Такой комплексный подход находит свою реализацию при разработке интерактивной системы поддержки принятия решений по предупреждению и ликвидации ЧС.

При этом возможны два принципиальных пути реализации интерактивной системы: внедрение единой комплексной системы и внедрение локально-кусочных систем [1].

В свою очередь, интерактивная система – это только часть автоматизированной информационно-управляющей системы для предупреждения и действий в ЧС (АИУС РСЧС) [2], которая в широком смысле является совокуп- ностью автоматизированных систем и технических средств, объединенных в единый комплекс [3]. Ключевую роль в ее функционировании играет ПО. Этому способствуют и такие факторы, как тенденция к росту степени универсальности ПО и независимости от применяемых аппаратных технологий, а также создание систем на основе микросервисов, когда крупная клиент-серверная информационная система представляет собой множество простейших модулей, взаимодействующих между собой для обработки запросов пользователя [3].

Постановка задачи

Под интерактивной системой понимается сочетание компонентов аппаратного и программного обеспечения, которое получает ин- формацию, вводимую пользователем, и сообщает ему свой ответ, помогая в работе или выполнении задачи (ГОСТ Р 55241.1–2012/ISO/ TR 9241-100:2010).

Разрабатываемая интерактивная система архитектурно представляет собой ряд однотипных модулей (рис. 1), каждый из которых осуществляет моделирование для конкретной ЧС.

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

-     учитывать возможности разветвления точек преломления;

-     хранить все линии и связи как единое целое (один объект – трубопровод);

-     хранить большое количество точек преломления линейных объектов;

-     хранить параметры сегментов линейных объектов (ширина трубы, материал, давление и прочее);

-     программно реализовать прерывание построения ветвей (конечные точки ветвей).

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

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

Клиентская часть представляет собой сайт: для этого пользовательские машины должны поддерживать браузеры с поддержкой HTML5 (например, Google Chrome и Yandex Browser). Клиентская часть отвечает за отрисовку карты, объектов (точек на карте и линейных объектов), зон поражения моделируемых ЧС, облаков диалога, интерфейса взаимодействия с модулями (сценариями) системы, а также за хранение временных данных (таких, как параметры сценариев, которые пользователь должен предоставить сам, заполнив поля в диалоговых окнах).

Решение

Для определения поражающих факторов аварий, связанных с разрушением магистрального газопровода, предлагается использование нормативов (ГОСТ Р 55241.1–2012/ISO/TR 9241-100:2010) и научно обоснованных подходов [4], а также методических указаний Газпрома. Исходные данные для расчетов:

-     состав транспортируемого газа;

-     давление на выходе из компрессорной станции, расположенной до точки разрыва;

-     давление на входе в компрессорную станцию, расположенную после точки разрыва;

-     наружный диаметр трубы;

-     толщина стенки;

-     проектная производительность газопровода;

-     температура на выходе из компрессорной станции;

-     температура окружающей среды;

-     коэффициент теплообмена между газом и окружающей средой;

-     плотность транспортируемого газа при стандартных условиях транспорта.

Алгоритмы, изложенные в [4] и СТО Газпром 2-2.3-351-2009, представляются в виде кода на языке PHP и впоследствии подключаются как дополнительный модуль к системе в виде отдельного сценария.

Все исходные данные для расчетов подаются в систему двумя способами: через диалоговые окна в клиентской части системы (например, точка аварии выбирается пользова- телем) и из БД. Сегмент БД показан на рисунке (см. http://www.swsys.ru/uploaded/image/2019-3/2019-3-dop/31.jpg). В таблицу «Объект» запи- сываются все объекты на карте (для трубопровода – отдельные сегменты), тогда как таблица «Связанные объекты» описывает связи между объектами (например, между сегментами трубопровода). При такой структуре БД можно хранить только некоторые исходные данные, а остальные рассчитывать с помощью уже имеющихся на отдельной стадии работы системы параметров.

Основная задача клиентской части систе- мы – передача пользователю системы данных, рассчитанных на серверной части. Для этого необходимо совершить ряд действий в клиентской части системы. Рассмотрим необходимость расчета пользователем последствий разрыва магистрального газопровода.

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

После расчета сервером параметров поражения и передачи их клиентской части пользователь сможет отобразить зоны поражения.

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

1. Вызывается функция получения данных в результате прорыва газопровода.

2. Отображенные на карте газопроводы делятся на сегменты (участок между преломлениями линейного объекта).

3. Из коллекции газопровода вызывается нужный сегмент по id сегмента, который считывается из html-кода после обработки события клика на газопровод функцией create­EventsOnPipes(). Метод createEventsOnPipes() создает объект события при клике на газопровод.

4. При клике на газопровод генерируется временная точка на карте, которая будет открывать облако диалога на том месте, где кликнул пользователь – место, где произошел разрыв газопровода (см. http://www.swsys.ru/uploaded/image/2019-3/2019-3-dop/32.jpg).

5. После клика с помощью координаты точки, по которой кликнул пользователь, опре- деляется объект сегмента, по которому будут производиться дальнейшие расчеты.

6. По данному объекту на карте определяется id сегмента газопровода. Добавляется точка на карту с уникальным id, и с помощью методов получения html кода заполняется облако диалога созданной временной кнопки.

Далее приведен фрагмент кода обработки создания объекта на трубопроводе:

function createEventsOnPipes()

{   

var tempPlacemark;

collectionPipes.events.add('click', function (e) {

if (tempPlacemark !== undefined)

{

            myMap.geoObjects.remove(tempPlacemark);

}

var objPipe = e.get('target');

coordPoint =  e.get("coords");

var segmentId = objPipe.options.get('id');

tempPlacemark = new ymaps.Placemark(coordPoint);

myMap.geoObjects.add(tempPlacemark, 99999);

tempPlacemark.properties.set('balloonContentBody',getHtmlHeatZones(segmentId, coordPoint));

            tempPlacemark.properties.set('balloonContentHeader',getHtmlHeader('heat_zones'));

tempPlacemark.balloon.open();

    });

}

После этого функция расчета работает следующим образом:

-     производится получение временной точ­ки на карте, созданной ранее;

-     производятся эмуляция расчета данных и добавление в footer точки текста о загрузке данных;

-     производится получение координат всех точек сегмента (начала и конца);

-     выполняется получение точки разрыва газопровода;

-     происходит отправка данных на сервер через Ajax-запрос.

Полученные данные записываются в глобальную переменную для использования в других функциях после расчета. Переменная хранит расход газа на всех промежутках времени. Так как функция построения зон поражения вызывается из события, добавленного на кнопку при получении html-контента, приходится использовать данную глобальную переменную, которая будет видна в функции создания зон поражения на карте. Далее передается html-контент для footer-точки и добавляется в него. Если известна длина факела, то на карте сразу строятся зоны поражения (см. http:// www.swsys.ru/uploaded/image/2019-3/2019-3-dop/33.jpg).

В методе создания зон действия поражающих факторов определяются цвета для их отрисовки. Считывается время, выбранное для показа на карте (15 мин., 30 мин., 60 мин.) (см. http://www.swsys.ru/uploaded/image/2019-3/ 2019-3-dop/34.jpg). Считывается точка эпицентра ЧС, создаются объекты зон поражения и добавляются в коллекцию.

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

function createCircle(){

      var colors = [

            "#0df52b",

            "#cff50d",

            "#fff901",

            "#fdd506",

            "#fd9c06",

            "#e01212"

      ];

      if (G.data.lengthFire != undefined)

      {

            createSector(G.data, $("#coordPoint").val(). split(','));

            return true;

      }

      var j = $("#timeBurning").val();

      var circle;

      var point = $("#coordPoint").val().split(',');

      for (var i = 0 ; i < G.data.HeatZone[j].length; i++)

      {

            circle = new ymaps.Circle([[point[0], point[1]], G.data.HeatZone[j][i]],{}, {fillColor:colors[i], fillOpacity:0.3, name: "Circle" + i});

            collectionPictures.add(circle, i);

      }

      myMap.geoObjects.add(collectionPictures);

}

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

Подробно пример расчета последствий аварии на магистральном газопроводе рассмотрен в работе [5].

Для нахождения радиусов зон безопасного удаления тех или иных объектов до точки разрыва (Ri) в информационной системе реализован следующий алгоритм. Начальные значения расстояний (X) при расчетах принимаются как d + 1. По указанному алгоритму производится расчет величины теплового излучения qi. Если получившиеся значения qi превышают установленные в [6] ограничения, расчет идет по расстоянию Xi = Xi–1 + ΔX до тех пор, пока полученные значения qi не совпадут либо не будут меньше пороговых значений, характеризующих зоны поражения. В информационной системе величина шага расчета теплового излучения задана в 1 метр. При необходимости количество зон и их параметры могут быть уточнены и отличаться от указанных в [6].

При рассмотрении сценария взрыва газовоздушной смеси (если воспламенение произойдет при некоторой задержке и образуется взры- воопасная по составу смесь) для расчета пара- метров зон действия поражающих факторов взрыва возможна реализация алгоритма в соответствии с ГОСТ Р 12.3.047-2012 и требованиями Приказа Федеральной службы по экологическому, технологическому и атомному надзо­ру от 2018 года.

Реализация системы расчета

Система для расчета реализована в виде клиент-серверного web-приложения, в котором клиент имеет возможность моделировать различные ЧС с визуализацией зон поражения, наложенных на карту. Архитектура приложения была выбрана в соответствии с необходимостью разделения потребления ресурсов, а также для возможности одновременного доступа нескольких пользователей. Основные принципы современного клиент-серверного приложения и особенности разработки данного типа систем описаны в [7]. В качестве подложки используются карты Яндекс. В отличие от Google-карт Яндекс имеет поддержку административно-территориального разделения России в самом API, что позволяет напрямую по запросам в данный API использовать данные для отрисовки границ регионов, муниципальных образований и других административных объектов (одна из функций приложения).

При разработке приложения авторы опирались на работы [8, 9]. Модели развития последствий ЧС, используемые в системе, разработаны отечественными исследователями, при этом был проведен обзор зарубежных аналитических выкладок последствий ЧС, в результате выявлено, что во многом между результатами исследований данных источников есть корреляция [10].

В качестве сервера используется платформа Open Server Panel версии 5.2.9 – набор утилит, программ и сервисов для создания локального сервера. Из всего набора стоит отметить программу PHPMyAdmin версии 4.8.3, необходимую для администрирования БД MySQL версии 5.6 с использованием графического интерфейса, без необходимости написания запросов вручную. Также существует возможность взаимодействия с базой с использованием SQL-запросов. С помощью данного инструмента была сконструирована БД MySQL, хранящаяся на сервере. Сама БД унифицирована и приведена к нормальной форме Бойса–Кодда. БД необходима для хранения информации об объектах, отображаемых на карте. Это могут быть жилые здания, промышленные объекты, маги- стральные продуктопроводы, спасательные формирования (спасательные центры, пожарные части). Данная информация используется программой при моделировании, а передача данных из базы на сервер происходит с помощью паттерна программирования «Фасад».

Клиентская часть проекта написана на языке JavaScript. Он удобен для проекта тем, что при расширении функционала и невозможности реализации стандартными способами есть возможность подключить к проекту библиотеки для реализации необходимого функционала. Так, например, была подключена библиотека JQuery версии 3.3.1, имеющая возможность точно описывать и производить Ajax-запросы, с помощью которых осуществляется считывание полей HTML-документа (то есть самой страницы сайта) без необходимости перезагрузки страницы (без методов по использованию GET/POST функционала). Также для формирования клиентской части программы используется фреймворк Bootstrap версии 3.3.7. Он позволяет использовать созданные заранее шаблоны для кнопок, полей и других элементов страницы с определенной стилизацией, что придает клиентской стороне проекта лаконичность и простоту при использовании.

Серверная часть проекта написана на языке PHP версии 7.2. Для расчета различных параметров ЧС использование ресурсов клиентской стороны было бы нецелесообразно, поэтому JavaScript, производящий обработку на сто- роне клиента, для данной задачи не подходит. Это легко устранимо заменой языка на PHP, ко- торый производит обработку действий на сервере. Язык PHP также удобен тем, что является объектно-ориентированным, это, в свою очередь, необходимо для структуры разрабатываемого продукта. В качестве фреймворка используется Laravel 5.x. Он позволяет соединять все элементы проекта для упорядоченной работы модулей.

Есть возможность разработки проекта несколькими разработчиками, для этого используется инструмент контроля версий git с помощью сервиса Bitbucket и программы Source­Tree, предлагающей интерфейс для загрузки проекта на сервис без использования консоли.

Заключение

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

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

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

Литература

1.    Агеев С.В., Измалков В.А., Романов А.С. Современные тенденции создания комплексной системы безопасности жизнедеятельности как элемента автоматизированной информационно-управляющей системы РСЧС // ВНИИ ГОЧС: комплексные решения проблем безопасности. 2016. С. 38–41.

2.    Качанов С.А., Нехорошев С.Н., Попов А.П. Информатизационные технологии поддержки принятия решений в чрезвычайных ситуациях. М.: Деловой экспресс, 2011. 400 с.

3.    Измалков В.А. Современные тенденции развития программного и других видов обеспечения АИУС РСЧС // Технологии гражданской безопасности. 2018. Т. 15. № 4. С. 48–51.

4.    Валуйский В.Е. Оценка обстановки при возникновении чрезвычайных ситуаций // Современные технологии обеспечения гражданской обороны и ликвидации последствий чрезвычайных ситуаций. 2016. № 1. С. 95–99.

5.    Сарданашвили С.А. Расчетные методы и алгоритмы (трубопроводный транспорт газа). М.: Нефть и газ, 2005. 577 с.

6.    Гуськов М.А. Обеспечение безопасности объектов магистрального транспорта газа в чрезвычайных ситуациях на основе повышения готовности оперативного персонала к действиям по локализации аварий: дис. ... канд. технич. наук. М.: РГУ нефти и газа им. Губкина, 2015. 155 с.

7.    Мартин Р. Чистая архитектура. Искусство разработки программного обеспечения. СПб: Питер, 2019. 352 с.

8.    Turban E., Aronson J.E. Decision support systems and intelligent systems. Prentice Hal, 2004, 955 p.

9.    Pantazis N. A., Stefanos N.A., Kandris D. & Vergados D. An automated system for integrated service management in emergency situations. Proc. Conf. PCI, 2011, pp. 154–157. DOI: 10.1109/PCI.2011.37.

10. Totani G., Totani F., Celli D., Pasquali D., Di Risio M. Post-event site investigation, monitoring, stability analysis, and modeling of a gas pipeline explosion. JFAP, 2016, vol. 17, no. 1, pp. 86–92. DOI: 10.1007/s11668-016-0212-0.

References

1. Ageev S.V., Izmalkov V.A., Romanov A.S. Current trends in the creation of an integrated life safety system as an element of the automated information and control system of the RUERS. All-Russia Scientific Research Institute on Problems of Civil Defense and Emergency Situations: Comprehensive Solutions to Security Problems. 2016, pp. 38–41 (in Russ.).
2. Kachanov S.A., Nekhoroshev S.N., Popov A.P. Information Technology Support for Decision-Making in Emergency Situations. Moscow, Delovoy Express Publ., 2011, 400 p. (in Russ.).
3. Izmalkov V.A. Current trends in the development of software and other types of support for AIMS RUERS. Civil Security Technologies. 2018, vol. 15, no. 4, pp. 48–51 (in Russ.).
4. Valuysky V.E. Assessment of the situation in the case of emergency. Modern Technologies for Civil Defense and Emergency Response. 2016, no. 1, pp. 95–99 (in Russ.).
5. Sardanashvili S.A. Calculation Methods and Algorithms (Pipeline Gas Transportation). Moscow, Neft i Gas Publ., 2005, 577 p. (in Russ.).
6. Guskov M.A. Ensuring the Safety of the main Gas Transportation Facilities in Emergency Situations Based on Increasing the Preparedness of Operating Personnel for Accident Localization Actions. PhD Thesis. Moscow, Gubkin Univ. Publ., 2015, 155 p. (in Russ.).
7. Martin R. Clean Architecture: A Craftsman’s Guide to Software. St. Petersburg, Piter Publ., 2019,
   352 p.
8. Turban E., Aronson J.E. Decision Support Systems and Intelligent Systems. 7th ed., Prentice Hall Publ., 2004, 955 p.
9. Pantazis N.A., Stefanos N.A., Kandris D., Vergados D. An automated system for integrated service management in emergency situations. Proc. Conf. PCI. 2011, pp. 154–157. DOI: 10.1109/PCI.2011.37.
10. Totani G., Totani F., Celli D., Pasquali D., Di Risio M. Post-event site investigation, monitoring, stability analysis, and modeling of a gas pipeline explosion. JFAP. 2016, vol. 17, no. 1, pp. 86–92. DOI: 10.1007/s11668-016-0212-0, 2016.