28 мая 2016г.
Функциональная модель
Развитие систем ситуационного управления требует решения задач автоматизации процесса управления силами и средствами подразделений по обеспечения общественной безопасности. Ключевыми потребителями автоматизированной системы подразделения и службы МВД России: подразделения патрульно службы (ПС); подразделения обеспечения безопасности на дорогах (ПОБД); подразделения охраны (ПОх); подразделения обеспечения общественной безопасности на транспорте (ПООБТ). Непосредственными пользователями будут центры мониторинга (ЦМ) и их Диспетчерские службы (ДС).
Функционирование диспетчерской службы организуется по территориальному и ведомственному принципу. Данные ДС руководят деятельностью ПС, ПОБД и т.д. При проведении мероприятий, в которых участвуют ДС разных субъектов РФ, эти ДС берут на себя руководство всеми силами и средствами служб обеспечения общественной безопасности на подведомственной территории и являются курирующими (основными) ДС в рамках территориального органа. По признаку объекта управления выделяются и другие службы: ДС патрульной службы; ДС территориального подразделения охраны; ДС линейного подразделения по обеспечения общественного порядка на транспорте.
С целью обеспечения координации в рамках плана единой дислокации, при проведении мероприятий должна быть обеспечена возможность обмена информацией между различными службами, то есть сведения о местоположении и состоянии подвижных объектов, относящихся к одной из служб, должны быть доступны в ДС и других служб. Для выполнения этой задачи требуется организация информационного обмена между ЦМ различной территориальной и муниципальной принадлежности.: автоматическая регистрация и работа переданных сил и средств, прибывших из другого региона, в региональной системе местонахождения; сопровождение подвижных объектов (в том числе, особо ценных и опасных грузов), перемещающихся между различными регионами, с выводом мониторинговой информации непосредственно подразделениям, в зоне ответственности, которых в данный момент находится подвижный объект. Реализация этих задач обеспечивается на базе взаимодействия с внешней информационной навигационно-мониторинговой системой – региональных спутниковых навигационно-мониторинговых систем (СНМС).
СНМС должны обеспечивать возможность построения распределённой иерархической системы, в которой вышестоящие центры мониторинга смогут собирают выборочную информацию от нижестоящих центров по каналам связи, с использованием интегрированной мультисервисной телекоммуникационной сети в защищенном виде, и при необходимости сохранять ее в своей собственной базе данных [2].
В Системе управления силами и средствами подразделений по обеспечения общественной безопасности реализуются следующие функциональные возможности: информационное взаимодействие между уровнями иерархии системы; обеспечение доступа к справочной и служебной информации; предоставление справочной и служебной информации различным уровням иерархии системы; осуществление автоматизированной поддержки актуальности справочной информации на всех уровнях иерархии. Изменения должны вступать в силу во всех ЦМ на всех уровнях иерархии; использование навигационных сигналов системы ГЛОНАСС либо совместно сигналов систем ГЛОНАСС/GPS.
Анализ технологических решений
Для обеспечения требуемого функционала необходимо, чтобы решение было масштабируемым и гибким. Масштабируемость необходима для расширения системы при увеличении количества сил и средств, которые нуждаются в управлении, в том числе и при развертывании системы. Гибкость необходима системе для добавления функционала АРМ и серверных приложений, который требуется пользователям для обеспечения их работы [3].
Для системы, которая строится на федеральном уровне, количество обслуживаемых единиц достаточно велико, что приводит к требованию масштабирования.
Вертикальное масштабирование — увеличение производительности каждого компонента системы с целью повышения общей производительности. Масштабируемость в этом контексте означает возможность заменять в существующей вычислительной системе компоненты более мощными и быстрыми по мере роста требований и развития технологий. Это самый простой способ масштабирования, так как не требует никаких изменений в прикладных программах, работающих на таких системах.
Горизонтальное масштабирование — разбиение системы на более мелкие структурные компоненты и разнесение их по отдельным физическим серверам (виртуальным серверам), и увеличение количества серверов, параллельно выполняющих одну и ту же функцию. Масштабируемость в этом контексте означает возможность добавлять к системе новые узлы, серверы, процессоры для увеличения общей производительности. Этот способ масштабирования накладывает дополнительные требования к программам, чтобы программы могли в полной мере пользоваться возросшим количеством ресурсов и выполнять процессные действия параллельно.
В целях построения более гибкой системы, целесообразно ориентироваться на создание приложений под горизонтальное масштабирование. Хоть это и более трудоемко, с точки зрения программирования, но дает больше свободы в случае необходимости наращивания мощности системы в случае увеличения количества пользователей или контролируемых объектов, а также это проще при размещении в готовой вычислительной инфраструктуре. Кроме того, при горизонтальном масштабировании, автоматически получается большая отказоустойчивость, поскольку в случае отказа оборудования, нагрузку возьмёт на себя другой сервер, хотя, и в аварийном режиме (с перегрузкой), что даст время для восстановления выбывшего из строя оборудования, или замены и развертывания нового вычислительного узла.
Горизонтальное масштабирование накладывает особые требования на разработку программных компонент. Это требование – параллельное программирование. Параллельное программирование сейчас представлено несколькими возможными технологиями, которые по сути представляют собой одно и то же. Основным краеугольным камнем параллельных вычисления является синхронизация процессов. Синхронизация может выполняться на уровне операционной системы, на уровне среды выполнения, или быть реализовано в явном виде в программе.
Также существует отдельная концепция разработки, аналогичная объектной модели программирования. Данная модель программирования называется модель акторов. Модель акторов исходит из того, что все вычислительные процессы являются акторами, которые представляют собой универсальный примитив параллельного численного расчёта: в ответ на сообщения, которые он получает, актор может принимать локальные решения, создавать новые акторы, посылать свои сообщения, а также устанавливать, как следует реагировать на последующие сообщения.
На текущий момент существует много реализаций модели акторов как в целых, отдельных языках программирования, так и в библиотеках для уже существующих языков программирования: Язык программирования Erlang; Akka, инструментарий для Java приложений по модели акторов; Java — объектно- ориентированный язык программирования; Google Web Toolkit (GWT) — свободный Java-фреймворк, который позволяет веб-разработчикам создавать Ajax-приложения; JavaScript — прототипно-ориентированный сценарный язык программирования; PHP (Hypertext Preprocessor - препроцессор гипертекста) – скриптовый язык программирования общего назначения, интенсивно применяемый для разработки веб-приложений; C# (си шарп)
– объектно-ориентированный язык программирования; ASP.NET (Active Server Pages) – технология создания веб- приложений и веб-сервисов; С/С++ – компилируемый статически типизированный язык программирования общего назначения; готовые средства для обеспечения параллельных вычислений – аппаратные и программные балансировщики нагрузки [1].
На основании выше изложенного, в качестве языка программирования вычислительных модулей с большим объемом вычислений обосновано использование языка С/С++ под операционную систему виртуальных серверов (Linux) с использованием модели акторов (вычислительные объекты и пулы потоков вычислений). Под данный язык программирования достаточно просто найти специалиста разработчика. С/С++ исходный код компилируется в быстрый машинный код, который практически не имеет накладных расходов, связанных со средой выполнения, напрямую взаимодействует с ядром операционной системы, требует минимальных объемов оперативной памяти. Использование как альтернативы языка Erlang, несмотря на хорошую масштабируемость, не оправдано с точки зрения гибкости, поскольку данный язык является не сильно распространенным, для него сложно найти специалиста разработчика необходимого уровня для поддержки решения.
В качестве языка программирования сервиса приложений обосновано использование языка Java с использованием библиотек клиент-серверного взаимодействия и поддержкой взаимосвязи с браузерами всех типов, поддержка работы со всеми распространенными СУБД с помощью готовых библиотек. Под данный язык программирования (базовый) достаточно просто найти специалиста разработчика. Приложение Java может быть развернуто под любую операционную систему, в том числе и на компьютере диспетчера при необходимости более широкой схемы распределенного построения системы. По сравнению с скриптовыми аналогами (PHP, JavaScript – node.js) Java обладает большей производительностью, а по сравнению с C# – ASP.NET обладает большей кроссплатформенностью, что делает процесс внедрения более простым и гибким. Использование Akka нецелесообразна, из-за сложности в развертывании и поддержке вычислительной среды (необходимость в настройке вычислительного кластера), и в поиске специалиста разработчика необходимого уровня для поддержки решения под данную архитектуру.
В качестве языка программирования АРМ обосновано использование JavaScript, HTML5 и CSS (Cascading Style Sheets — каскадные таблицы стилей, формальный язык описания внешнего вида документа, написанного с использованием языка разметки), с использованием существующих открытых библиотек по работе с картографической информацией и ГИС, открытых библиотек для связи с сервисом приложений на Java с поддержкой большинства современных браузеров, открытых графических библиотек удобной работы со списками, справочниками, с возможностью смены тем и цветов под требования конкретного пользователя (это облегчает работу пользователя диспетчера путем обеспечения комфортной для его глаз цветовой схеме). Количество «открытых» библиотек – библиотек с открытым исходным кодом сейчас достаточно велико. Их использование обосновано возможностью их проверки на предмет неявных и явных уязвимостей, а также возможностью их адаптации под требования пользователей и тюнинг производительности. По этой причине, например, нежелательно использование удобного инструментария GWT, поскольку при каждой компиляции генерируется новый JavaScript, который сложно отладить и доработать отдельно от основного сервиса приложений. Использование «закрытых» компонент обосновано только в случае использования целостных отдельных внешних систем, например, каких-то конкретных ГИС или конкретных BI (Business intelligence – Бизнес-аналитика), в которых нет открытых инструментов для АРМ и внешнего взаимодействия.
Предлагается использование следующих библиотек JavaScript: JQuery – для взаимодействия JavaScript и HTML, помогает легко получать доступ к любому элементу документа HTML, обращаться к атрибутам и содержимому элементов документа, манипулировать ими. Также библиотека jQuery предоставляет удобный API для работы с AJAX; OpenLayers - предназначенная для создания карт на основе программного интерфейса (API), подобного GoogleMap API или Bing Maps API, имеет много функций и возможностей; Cocos2d-JS – игровой 2D движок.
Дополнительные библиотеки будут выбираться в процессе разработки.
Использование балансировщиков, причем разного типа, такие как кэширующий прокси с функцией балансирования, а также драйверов системы виртуализации, оправдано и обязательно. В качестве балансировщика взаимодействия АРМ и сервиса приложений, а также АРМ и ГИС сервера, будет использоваться кэширующий прокси – приложение nginx, которое позволяет: распределять запросы между сервисами приложений с отслеживанием сессии пользователя; кэшировать картинки и часто повторяемые запросы с контролем срока давности.
Список литературы
1. Б. Маклафлин, Г. Поллайс, Д. Уэст Объектно-ориентированный анализ и проектирование: Пер. с англ. – СПб.: Питер, 2013.
2. Цехановский В.В., Чертовской В.Д. Управление данными. – Издательство "Лань". 2015
3. Щелоков С. А. Проектирование распределенных информационных систем. – Оренбург: ОГУ. 2012.
