CC BY
14ФУНДАМЕНТАЛЬНАЯ И ПРИКЛАДНАЯ МАТЕМАТИКА УДК 004.42
АРХИТЕКТУРА И АЛГОРИТМ РАБОТЫ СИСТЕМЫ РАСПРЕДЕЛЕННОЙ ДИСПЕТЧЕРИЗАЦИИ ЖИЛОГО КОМПЛЕКСА
А.А. Горелов, К.В. Дергачев
Брянский государственный технический университет
Целью создания подобных автоматизированных систем служит обеспечение безопасного и комфортного проживания людей в жилых комплексах, а также передача функций управления собственникам. Предлагается архитектура и алгоритм работы системы распределенной диспетчеризации жилого комплекса, позволяющей контролировать состояние дома и дворовой территории, а также управлять объектами с помощью компьютера или мобильного телефона. Система представляет собой масштабируемый сайт, адаптирующийся для работы с мобильными устройствами. Описан состав и назначение компонентов серверной и клиентских частей приложения. Предложен способ минимизации объема видеоинформации, передаваемой на клиентскую часть, с помощью преобразования RTSP потоков в формат MJPEG. Описан состав базы данных и обобщенные алгоритмы взаимодействия администратора и пользователя с системой диспетчеризации.
Ключевые слова: диспетчеризация, управление, жилой комплекс, безопасность, сайт, алгоритм, клиент, сервер, контроллер, PHP, Apache, MySQL.
Доступность и распространенность компьютерных, мобильных, сетевых и других современных информационных технологий позволяют эффективно решать задачи обеспечения комплексной безопасности объектов жилого фонда. Однако применение современных систем контроля доступа не приносит должного эффекта без участия в процессах контроля и управления самих жильцов. Поэтому для повышения эффективности системы безопасности актуальными являются разработка и внедрение системы диспетчеризации и автоматизации в виде веб-приложения, доступного для всех жильцов [2].
Техническая реализация контроля, управления и взаимодействия между жильцами сводится к установке камер наблюдения за ключевыми зонами с публичным вещанием, установка датчиков аварийных ситуаций (затопление, пожар, взлом и т.п.), а также исполнительных устройств (механизмы открытия ворот, шлагбаума, включения света, тревожных извещателей и т.п.) с возможностью управления этими устройствами самими жильцами [1, 5]. Такие полномочия и функции значительно расширяют возможности жителей дома, приобщают их к ответственности и мотивируют к благоустройству и содержанию территории, а также её дальнейшему развитию.
Таким образом, актуальной является задача организации взаимодействия между жильцами посредством разработки и внедрения веб-сайта для контроля за домом и двором, доступного всем жильцам, как с компьютера, так и с мобильных устройств. Чтобы сделать его эффективным, необходимо оснастить его функциями контроля и управления устройствами в доме и во дворе. Наличие такого сайта в значительной мере упростит проведение общих собраний и доведение информации до каждого жильца, а также существенно сэкономит время для принятия решений.
Сайт предполагает он-лайн обсуждение текущих вопросов и проблем, а также принятие общего решения путем голосования. Кроме того, в случае оснащения сайта информацией о событиях и датчиках, установленных в доме и во дворе, жители оперативно получают информацию о возможных неисправностях, которые могут стать причиной аварии. Оперативное извещение жильцов о таких авариях делает возможным немедленное их устранение или своевременное предупреждение аварийных служб и управляющей компании. Очевидно, что предотвращение аварийных ситуаций даст значительный экономический
эффект, ведь в большинстве случаев ликвидация последствий аварии значительно дороже ликвидации самой аварии.
Наличие органов управления исполнительными устройствами позволит жильцам открывать и закрывать ворота, шлагбаум, калитки во дворе, включать свет или звуковые системы непосредственно с мобильного устройства или компьютера. Это в значительной мере повысит безопасность, сэкономит время и главное - позволит вести эффективный контроль.
Программная система распределенного управления жилым комплексом должна: 1) представлять собой закрытый web-сайт, доступный только собственникам жилого комплекса; 2) сочетать в себе возможности управления всеми блоками системы автоматизации; 3) позволять жителям общаться между собой для организации совместных действий.
Программная система состоит из двух частей - серверной (сайт со службами) и клиентской (веб-страницы, открываемые пользователями на мобильных устройствах или персональных компьютерах).
В качестве операционной системы сервера была выбрана FreeBSD по причине стабильности, быстродействия, защищенности и корректности работы многих компонентов [3]. Помимо базового пакета компонентов ядра потребовались дополнительные, а именно:
- Apache, необходимый для поддержки сайта;
- MySql, используемый для управления базами данных [4];
- PHP, обрабатывающий скрипты [4];
- FFMpeg, выполняющий конвертацию потоков с видеокамер.
Физический контроллер, к которому подключены датчики и исполнительные устройства, поддерживает http-протокол, используемый для обмена данными между сервером и контроллером. По этому протоколу доступен xml-файл, содержащий значения состояний входов и выходов устройства, обновляемый в реальном времени самим контроллером. Таким образом, считывание состояний входов-выходов происходит методом анализа этого файла, а посылка команд контроллеру - GET-запросами. Для безопасности работы с контроллером, а также недопущения атак на него, он включен в другую (экранированную) подсеть, недоступную из внешней. Таким образом, контроллер видит только сервер, а сайт видят пользователи.
Видеопотоки для работы с камерами наблюдения можно получить либо непосредственно с камер, поддерживающих данную возможность, либо методом перекодировки. В данном случае использовался второй вариант, поскольку система адаптировалась под установленные камеры. Конвертер видеопотоков размещен непосредственно на сервере с сайтом.
Следует обратить внимание, что при данной конфигурации «все в одном», из всех служб основную нагрузку на процессор несет именно конвертер потоков видеокамер. Увеличение кодируемых потоков ведет к росту нагрузки на процессор. В типовой схеме с конвертацией до 16 видеопотоков использовался четырехъядерный процессор IntelCore i5 с четырьмя гигабайтами оперативной памяти. Поэтому при необходимости трансляции большего количества камер следует применять более производительные сервера, либо на этапе установки системы видеонаблюдения выбирать IP-камеры или регистраторы с возможностью самостоятельного вещания в mjpeg-поток.
Общую структуру системы можно представить в виде каталогов с файлами (табл.)
При старте системы запускаются необходимые службы, отвечающие за его корректную работу (apache, mysql, ffmpeg и др.), а также скрипты автозагрузки и планировщика задач. В их задачи входит отслеживание работоспособности конвертации потоков видеокамер, периодическая запись значений аналоговых датчиков (температур) в базу, анализа состояний пинов контроллеров и некоторые другие функции.
В одном из стартовых скриптов запускается бесконечный цикл, который раз в секунду анализирует XML файл контроллера и записывает значения используемых входов и выходов
в таблицу на сервере. Такая «перезапись» из контроллера в таблицу необходима для передачи состояний входов и выходов сайту, куда потом попадают авторизованные пользователи. Актуальные значения из этой таблицы (например, температура) отображаются на главной странице сайта.
Рассмотрим алгоритм работы сайта при входе в систему после авторизации.
Как только клиент заходит на сайт с компьютера или мобильного устройства, он попадает на страницу авторизации, где вводит логин и пароль. Данная страница подгружает класс users, который в свою очередь, посылает запрос в базу данных пользователей, и в зависимости от ответа базы (существует ли пользователь с таким логином и паролем) открывает доступ на главную страницу сайта, либо возвращает на страницу авторизации.
Таблица
Каталоги программной системы диспетчеризации_
Каталог Назначение
bin Скрипты для работы системы, например, отслеживание работы камер, посылка команд, чтение пинов контроллера.
cron Скрипты планировщика задач на автозагрузку
inc Файлы, обеспечивающие работу системы
classes Классы для работы с БД
configs Конфигурация
modules Папка с модулями системы (модуль чата, настроек, контроллеров, документов, групп доступа, логирования, пользователей и др.)
templates Папка с шаблонами системы
default Текущий шаблон (по умолчанию), содержит составные части, например, шаблон объявлений, чата, настроек, объектов, групп и др.
js Служебные скрипты шаблона для работы системы (интерфейс, отрисовка графиков, визуальных эффектов и т.д.)
fonts Шрифты, используемые в интерфейсах
plugins Плагины интерфейса
images Изображения интерфейса
templates c Папка компиляции шаблона интерфейса
uploads Папка загрузки файлов (фото, документы и прочие).
Главная страница index.php подгружает основные модули (чат, объявления и проч.), вызывающие классы, которые в свою очередь, обращаются к базе данных за сведениями, возвращаемыми модулю. Эти сведения (значения базы данных) передаются в шаблоны модуля, которые в свою очередь, отражаются в общем шаблоне, формирующем интерфейс пользователя.
Так, например, при загрузке index.php подгружается один из модулей modules/ads/view.php, отвечающий за показ объявлений, который вызывает класс ADS.class.php , обращающийся к одноименной таблице базы данных. Класс забирает из таблиц(ы) следующие значения: ID, название, текст, дата, которые передаются в одноименный модуль ads, где они обрабатываются и передаются в шаблон модуля ads. Шаблон модуля собирается вместе с остальными в основной шаблон main.tpl, который компилируется в директории templatesc и выводится клиенту. Для удобства модули, классы, шаблоны и таблицы, относящиеся к конкретному функционалу сайта, названы одинаково.
Компиляцией шаблонов занимается система шаблонизации - smarty.
В свою очередь, JavaScript на стороне клиента обновляет динамические элементы (окно чата, блоки состояний датчиков, окружения, состояния кнопок и др.), не обновляя страницу целиком.
Сайт предусматривает наличие объектов наблюдения (потоки с видеокамер с кнопками управления). Редактировать объекты могут только администраторы сайта.
Рассмотрим обращение с объектами на примере добавления нового объекта с последующим его вызовом.
При добавлении нового объекта администратором загружается index.php, который подгружает соответствующий модуль modules/objects/view.php, где администратор вносит название объекта и ссылку на mjpeg-поток видеокамеры. После чего JavaScript передает данные методу addobject из модуля, в этом методе происходит проверка введённых данных и через объект одноимённого класса, добавляет новую строку в базу. Эта строка содержит адрес потока, название объекта и ID. На основе двух последних параметров в последующем формируется ссылка для перехода на данный объект.
Добавление кнопок управления объектом происходит по схожему сценарию: при выборе объекта доступны поля для заполнения: название кнопки, IP контроллера, пин, посылаемое значение. По заполнении этих полей Javascript после нажатия кнопки «добавить» передает значения модулю, который, после проверки, используя соответствующий метод addbutton записывает с помощью класса в таблицу БД введенные ранее данные.
В результате при обновлении страницы в списке объектов появляются их названия в соответствии с расположением в базе данных.
При обращении к объекту происходит переход по ссылке, сгенерированной ранее при его создании. Ссылка состоит из имени домена, модуля, процедуры и ID объекта. При переходе по данной ссылке, из базы данных берется название объекта и ссылка на mjpeg-поток, эти данные помещаются в массив для передачи в шаблон.
Кроме того, согласно ID объекта, идет обращение к БД, таблице ObjectButtons, откуда выбираются все записи (кнопки) с ParentID выбранного объекта. Такая выборка позволяет из таблицы кнопок взять все необходимые (ранее созданные) кнопки с их характеристиками (название, IP контроллера, пин контроллера, посылаемое значение). Эти данные также складываются в массив для передачи в шаблон.
Далее подгружается шаблон модуля (objects), в него передается сформированный массив, а шаблонизатор smarty распределяет передаваемые части шаблона object в основной шаблон, после чего происходит компиляция и отображение интерфейса.
Формирование, отображение и выполнение остальных объектов происходит по тому же сценарию.
Если пользователь выполняет какое-то действие (например, открытие ворот с сайта), нажав соответствующую кнопку, то java-скрипт пользователя на несколько секунд блокирует повторное нажатие этой кнопки во избежание задвоения команд и как следствие - зависания управляемого объекта.
Результат нажатия кнопки для сервера - это появление новой необработанной строки с командой в таблице Commands (очередь команд), которая в последующем циклически обрабатывается одним из скриптов автозагрузки. Данный скрипт с бесконечным циклом и паузой в 1 секунду формирует запросы к таблице Commands на наличие таких строк. При обнаружении этой строки скрипт формирует и отправляет Get-запрос контроллеру в соответствии с указанным выходом, проверяя при этом ответ от контроллера (done или bad). Если по техническим причинам команду послать не удалось, то она помечается как непосланная и подлежит повторной отправке на контроллер. Если при успешной отправке команды, контроллер вернул значение done (выполнено), команда в строке таблицы БД помечается как выполненная, а если возвращенное значение bad, то команда помечается как невыполненная и не подлежит повторной обработке на следующем витке цикла скрипта, так как возможно она была сформирована некорректно.
Bad-значение может быть получено, если по техническим причинам контроллер отказался выполнить команду, либо на этапе формирования команды была допущена ошибка
(такое может произойти только если при заполнении информации о пинах контроллера была допущена ошибка в направлении работы или типе пина).
При восстановлении связи с контроллером скрипт группирует одинаковые команды в одну, после чего выполняет их последовательно поступлению. Данная группировка необходима для того, чтобы избежать многократных повторений команд, вызванных техническим сбоем или одновременным нажатием одной кнопки несколькими пользователями.
Помимо объектов, сайт предусматривает также другие разделы: пользователи, группы, объявления, фотогалерея и другие, назначение которых будет рассмотрено ниже. Соответствующие модули, классы и шаблоны имеют смысловые названия, а процедура обращения с ними схожа с вышеописанной.
В системе используются таблицы с данными, такие как:
- таблица пользователей, где указан перечень зарегистрированных участников сайта, причем автоматическая регистрация не предусмотрена (в целях безопасности), пользователи вносятся администратором вручную после ознакомления с правилами сайта;
- таблица групп и прав пользователей, в которой определены их полномочия и принадлежность;
- таблица состояний входов и выходов контроллера (или контроллеров в случае использования нескольких), обновляется в реальном времени после анализа XML файла контроллера;
- таблица погодных данных, которая раз в 10 минут обновляется с внешнего сайта погоды (при наличии подключения к сети Интернет);
- таблица показателей датчиков температуры, значения которой пополняются из XML файла раздела АЦП раз в 10 минут, используется для последующего построения графиков температур;
- таблицы термометров, используемых входных датчиков системы, кнопок исполнительных устройств, таблицы с самими контроллерами, MJPEG-ссылками потоков камер, которые заполняются при изменении конфигурации системы;
- таблицы сообщений чата, объявлений, голосований, которые обновляются при действиях пользователей на сайте;
- таблицы документов, списков, фотографий, черного списка, содержат ссылки на файлы, обновляются по мере внесения документов администратором;
- таблицы логов действий пользователей, срабатываний входов, очередей отправки командна контролер, динамически обновляющиеся в процессе работы системы.
На сервере развернута система управления базами данных (СУБД) на основе MySql для управления перечисленными таблицами.
В качестве планировщика задач и процессов используется CRON, являющийся частью системы. Планировщик в указанное время запускает заданные скрипты, которые проводят опросы погоды, работоспособности камер, а также записывают значения температур в базу данных.
Как было указано выше, на сервере развернута система перекодирования потоков видеокамер в доступный универсальный mjpeg-поток, не требующий использования клиентом дополнительных плагинов, представляющий собой серию картинок заданного разрешения, качества и частоты их смены.
Для отображения на сайте содержимого камер видеонаблюдения используются соответствующие RTSP потоки, однако зачастую такие потоки бывают слишком «тяжелыми» для обработки, особенно когда их много. Так, например, при использовании IP камеры высокого разрешения (1920х1080 пикселей) с частотой 25 кадров в секунду, в локальную сеть она будет выдавать до 10 МБит/с, соответственно всего десять таких камер вызовут перегрузку 100 мегабитной сети. Кроме того, просмотр таких потоков на мобильных устройствах с невысокой скоростью интернет связи будет практически невозможным и, в общем-то ненужным, т.к. размер экрана не позволит увидеть всю полноту кадров. Также по
RTSP-протоколу периодически происходит потеря пакетов, вследствие чего изображения с камер «подвисают». Связано это с нестабильностью работы самих камер (или видеорегистраторов), физическими факторами (перебои питания, скачки напряжения) или пиковыми нагрузками сети (особенно при использовании дешевого коммутационного оборудования).
Поэтому учитывая вышеизложенные факторы, было принято решение перекодировать RTSP потоки камер в серии картинок (MJPEG-поток) с более низким разрешением и частотой кадров. Такое решение позволило отображать материалы с видеокамер в реальном времени не перегружая сеть.
Процессом перекодировки занимается компонент FFMpeg (декодер), настройки которого содержат выходные параметры изображений (размер, частота кадров, качество). Для отслеживания работоспособности входящих RTSP потоков в CRON'е запущен бесконечный цикл, который раз в минуту проверяет наличие потока и в случае обнаружения его отсутствия перезапускает декодер.
Для упрощения ввода данных и оптимизации используются скрипты и маски. Так например, при входе на сайт с компьютера, пользователь вводит логин (номер телефона) с использованием уже заданного формата, а при заполнении своего профиля в некоторых полях использует только цифры в (например, номер дома или квартиры). Такой подход позволяет поддерживать порядок в базе данных.
При входе на сайт происходит авторизация пользователя, где ему необходимо указать свои учетные данные.
Главная страница сайта содержит следующие разделы:
- Профиль пользователя, где пользователь может самостоятельно изменять свои данные;
- Раздел состояний датчиков, окружения, температур и погоды. Данный раздел разделен на блоки по содержанию. В случае, если система обнаруживает срабатывание датчика (например пожара), соответствующий блок меняет текст и цвет на красный, сигнализируя об опасности;
- Раздел «Быстрый доступ» служит для оперативного управления наиболее часто используемых исполнительных устройств: шлагбаум, калитки и др.
- Раздел «Чат» позволяет пользователям в реальном времени обмениваться сообщениями между собой;
- Раздел «Голосование» предлагает варианты ответов на обсуждаемый вопрос, либо показывает статистику голосования в виде круговой диаграммы.
- В разделе «Объявления» перечислены и помечены цветами в зависимости от важности объявления пользователей.
Также сайт имеет дополнительное меню, которое находится слева, либо открывается путем нажатия соответствующей кнопки на мобильных устройствах. Это меню имеет следующие разделы:
- Объекты - кнопки доступа к камерам наблюдения, а также кнопки управления исполнительными устройствами в зоне видимости данных камер. Таким образом, пользователь нажимая на кнопку действия сразу видит результат;
- Доска позора и фотогалерея содержат фотоматериалы нарушителей порядка и разделенный по категориям фотоальбом.
- Документы и инструкции, содержит перечень телефонов экстренных служб и архив документов, касающихся деятельности управляющей компании, совета дома, протоколы, решения, ведомости и т.п.
- Опросы - список пройденных голосований с возможностью статистики.
Для администраторов предусмотрены в этом окне дополнительные разделы, а именно:
- Пользователи, группы. В этих разделах можно добавлять, изменять или удалять пользователей, групп и права доступа;
- Контроллеры. Данное меню позволяет администратору добавлять, изменять и удалять контроллеры, их пины, а также объединять несколько контроллеров, присваивать входным и выходным каналам назначение, просматривать текущее состояние всех пинов контроллеров системы;
- Настройка и события, содержит два подраздела: «Настройка системы» и «Управление и данные». Настройка системы необходима для конструирования кнопок и индикаторов главного окна. Именно в этом подразделе можно задать назначение кнопок, соответствие их пинам контроллера, вывести их на главное окно или оставить в администраторском разделе. Здесь же задаются термометры, данные из которых должны попадать в базу для последующего графического анализа температур. Подраздел «Управление и данные» служит для отображения состояния и управления всеми входами и выходами независимо от того, присутствуют ли они на главной странице. Также данный подраздел показывает значения термометров системы и позволяет вывести график изменения температур выбранного термометра. В этом же разделе отображается очередь команд (опционально) на контроллер и их состояние (выполнена или не выполнена), а также оповещения о срабатывании входных датчиков (опционально).
- Журнал системы, в котором отображены все действия пользователей с возможностью его выборочной очистки. Данный раздел служит для выявления нарушителей.
Рассмотрев основной функционал сайта, принципы его построения и алгоритм работы, следует отметить, что сайт представляет собой конструктор, легко адаптируемый под разные условия и обеспечивающий высокий уровень безопасности. Такой подход позволяет объединять несколько контроллеров воедино, обслуживая тем самым, объекты с большим количеством датчиков и устройств.
Возможность транскодировать RTSP потоки в MJPEG существенно ускоряет их отображение на мобильных устройствах в условиях недостаточной пропускной способности линий связи. А при использовании камер или регистраторов со встроенными mjpeg-потоками исчезает необходимость транскодирования на сервере, освобождая тем самым вычислительные ресурсы.
Список литературы
1. Антипенко, Е.В. Проблемы управления многоквартирными домами в процессе реформирования жилищно-коммунального хозяйства / Е.В.Антипенко, В.В.Евенко, В.В.Спасенников // Экономико-психологические и правовые проблемы инновационного развития жилищно-коммунального хозяйства: Материалы Всероссийской научно-практической конференции. 2015. С. 69-75.
2. Горелов, А.А. Система общественного контроля и самоуправления в сфере жилищно-коммунального хозяйства / А.А.Горелов, К.В.Дергачев // Экономика в условиях социально-техногенного развития мира: материалы Междунар. науч.конф. по (30 июня 2016 г., г.Брянск): в 2 т. Брянск:БГТУ, 2016. Т.2. С. 335-341.
3. Колисниченко, Д.Н. FreeBSD. От новичка к профессионалу / Д.Н. Колисниченко. СПб.:БХВ-Петербург, 2012. 608 с.
4. Никсон, Р. Создаем динамические веб-сайты с помощью PHP, MySQL, JavaScript и CSS. / Р. Никсон. СПб.:Питер, 2013. 560 с.
5. Самарин, О.Д. Автоматизация и диспетчеризация зданий как средство повышения их энергоэффективности / О.Д. Самарин, Е.А. Гришнева // Вестник МГСУ. 2011. № 6. С. 294297.
Сведения об авторах
Горелов A.A. - студент ФГБОУ ВО «Брянский государственный технический университет», e-mail: alexey415@rambler.ru;
Дергачев К.В. - кандидат технических наук, декан факультета информационных технологий, доцент ФГБОУ ВО «Брянский государственный технический университет», email: kv.dergachev@gmail.com.
ARCHITECTURE AND ALGORITHM OF THE SYSTEM OF DISTRIBUTED DISPATCHING OF A RESIDENTIAL COMPLEX
A.A. Gorelov, K.V. Dergachev
Bryansk State Technical University
The purpose of these automated systems is to ensure safe and comfortable stay of people in residential complexes, as well as the transfer of management functions to the owners. Proposed architecture and algorithm of the system of distributed dispatching of a residential complex, allow-ing you to control the condition of the house and yard area, and manipulate objects using a computer or mobile phone. The system is a scalable website, optimised for mobile devices. Describes the composition and purpose of components of server and client parts of the application. The proposed method minimize the amount of video information transmitted to the client, by converting the RTSP streams into MJPEG format. Describes the composition of the database and the generalized algorithms of interaction between the administrator and the user with the dispatching system.
Keywords: scheduling, management, residential complex, security, website, algorithm, client, server, controller, PHP, Apache, MySQL.
References
1. Antipenko, E.V. Problemy upravleniya mnogokvartirnymi domami v processe re-formirovaniya zhilishchno-kommunal'nogo hozyajstva / E.V.Antipenko, V.V.Evenko, V.V.Spasennikov // EHkonomiko-psihologicheskie i pravovye problemy innovacionnogo razvitiya zhilishchno-kommunal'nogo hozyajstva: Materialy Vserossijskoj nauchno-prakticheskoj konferencii. 2015. S. 69-75.
2. Gorelov, A.A. Sistema obshchestvennogo kontrolya i samoupravleniya v sfere zhilishchno-kommunal'nogo hozyajstva / A.A.Gorelov, K.V.Dergachev // EHkonomika v usloviyah social'no-tekhnogennogo razvitiya mira: materialy Mezhdunar. nauch.konf. po (30 iyunya 2016 g., g.Bryansk): v 2 t. Bryansk:BGTU, 2016. T.2. S. 335-341.
3. Kolisnichenko, D.N. FreeBSD. Ot novichka k professionalu / D.N. Kolisnichenko. SPb.: BHV-Peterburg, 2012. 608 s.
4. Nikson, R. Sozdaem dinamicheskie veb-sajty s pomoshch'yu PHP, MySQL, JavaScript i CSS. / R. Nikson. SPb.:Piter, 2013. 560 s.
5. Samarin, O.D. Avtomatizaciya i dispetcherizaciya zdanij kak sredstvo povysheniya ih ehnergoehffektivnosti / O.D.Samarin, E.A.Grishneva // Vestnik MGSU. 2011. № 6. S. 294-297.
About authors
Gorelov A.A. - student of Bryansk State Technical University, e-mail: alexey415@rambler.ru;
Dergachev K.V. - Candidate of Technical Sciences, Dean of the Faculty of Information Technology, Associate Professor of Bryansk State Technical University, e-mail: kv.dergachev@gmail.com.
