Исследование и применение современных web-технологий для реализации программного комплекса «Умная парковка»

Научная новизна и теоретическая значимость исследования.
Работа открывает направление исследований в области развития 
современных 
информационных 
и 
WEB-технологий, 
применения 
информационных и WEB-технологий для улучшения качества жизни и 
комфорта как жителей России в целом, так и водителей в частности. 
Выявлены, обоснованы и описаны преимущества информационных 
технологий как инструмента развития парковочных систем. Показано, что с 
помощью 
этого 
инструмента 
становится 
возможным 
повысить 
эффективность и удобство как крытых, так и открытых парковок, не 
потратив на это большое количество ресурсов. 
Исследование показывает, что использование информационной 
системы «умной парковки» в традиционную систему парковок, включая 
охраняемые и неохраняемые парковки, не нарушает ее целостности, 
раскрывая при этом ее потенциал в решении проблем с очередями, 
переполненностью 
и 
безопасностью; 
а 
также 
в 
повышении 
удовлетворенности пользователей парковок – водителей. 
Практическая 
значимость 
исследования
. 
Проведен 
анализ 
традиционной системы парковок в городе Екатеринбург, а также нескольких 
похожих аналогов «умных парковок», создана схема предложенной 
парковки, создан рабочий макет парковки и прототип с рабочей программной 
и аппаратной частью. 

---

12 
1 Постановка задачи 
На основе исследований современных WEB-технологий, разработать 
программный комплекс «Умная парковка», состоящий из трех частей: 
1.
Клиентская 
часть 
WEB-приложения 
для 
резервирования 
парковочных мест. 
2.
Тестовый WEB-сервер для реализации работы WEB-приложения. 
3.
Тестовая база данных для реализации работы WEB-приложения. 
WEB-приложение должно представлять собой информационный 
сервис, позволяющий пользователю удаленно забронировать место на 
парковке, используя удобный пользовательский графический WEB-
интерфейс, наглядно показывающий текущий статус парковочных мест. 
Система должна обеспечивать:

Выбор метода бронирования (автоматический или ручной); 

Визуализацию текущего статуса парковочных мест; 

Автоматическое бронирование ближайшего парковочного места и 
запись соответствующей информации в базу данных; 

Бронирование парковочного места пользователем вручную, то есть 
посредством клика на желаемое место парковки, статус которого 
выделен как «свободный»; 

Блокирование дальнейшего бронирования пользователем парковочных 
мест. 
База данных должна содержать коллекцию парковочных мест с 
идентификаторами парковочных мест и их текущими статусами (занято или 
свободно). 

---

13 
2 Исследование современных WEB-технологий 
2.1 Описание стека технологий WEB-приложения 
Стек технологий, использованный при разработке WEB-приложения, 
включает в себя фреймворки и библиотеки, потребовавшиеся для 
эффективной, быстрой разработки и позволяющие с минимальным объемом 
данных и ограниченными системными требованиями интегрировать WEB-
приложение с остальными сервисами «Умной парковки» для отображения 
данных в WEB-интерфейсе в реальном времени. 
2.1.1 JavaScript-библиотеки 
Рассмотрим 
основные 
JavaScript-библиотеки 
и 
фреймворки, 
использующиеся в современном WEB-программировании. В работе [1] 
приведено сравнение их производительности (в соответствии с рисунком 1) в 
браузере Google Chrome 48. В данном случае тестируется создание 1000 
строк сразу после загрузки страницы (“create 1000 rows”), обновление 1000 
строк в таблице после 5 итераций «разогрева» JavaScript-движка (“update 
1000 rows (hot)”), частичное обновление строк в таблице после 5 итераций 
«разогрева» JavaScript-движка (добавление точки в конец каждой 10-ой 
строки, “partial update”), выбор строки после 5 итераций «разогрева» 
JavaScript-движка (визуальное выделение строки, “select row”), удаление 
строки после 5 итераций «разогрева» JavaScript-движка (“remove row”). Как 
видно из гистограммы на рис. 1, лучше всего показывает себя библиотека 
VueJS, кроме обновления строк в таблице. WEB-интерфейс «Умной 
парковки» предполагает визуальное обновление данных в реальном времени, 
а создание визуальной «подложки» для отображения парковочных мест 
создаётся только один раз, поэтому необходимо выбрать библиотеку, которая 
является производительной при обновлениях данных и хорошо сочетается с 
реализацией клиентского роутинга. Такой библиотекой является ReactJS. 

---

14 
Рисунок 1 
–
Гистограмма производительности JS-фреймворков (мс) 
React – разработанный компаниями Facebook и Instagram JavaScript-
фреймворк с открытым исходным кодом для создания пользовательских 
интерфейсов. Большинство пользователей React считают его Представлением 
в идеологии MVC. React был разработан, чтобы решить большую проблему: 
написание больших приложений с данными, которые меняются с течением 
времени. 
React – это библиотека на языке JavaScript для создания 
пользовательских интерфейсов. React позволяет описывать элементы, т.е. 
является декларативным. С помощью данной технологии можно 
безболезненно создавать интерактивные пользовательские интерфейсы. 
Разработчик может спроектировать простые представления для каждого 
состояния будушего WEB-приложения, и React сможет эффективно и 
производительно обновить и перерисовать только те компоненты, которые 
были затронуты изменением данных. Декларативные представления делают 
код более предсказуемым при выполнении и более удобным при отладке. 
Разработчик также может создавать инкапсулированные компоненты, 
которые управляют своим собственным состоянием, а затем соединять их для 
дальнейшего 
использования 
и 
создания 
сложных 
составных 
пользовательских интерфейсов. Так как логика компонентов написана на 
JavaScript, а не на языке-шаблонизаторе, программист может легко 

---

15 
передавать достаточно большой набор данных со сложной структурой по 
всему приложению, сохраняя состояние вне DOM [2]. 
Благодаря 
использованию 
данного 
фреймворка 
появляется 
возможность загрузить клиенту (например, в WEB-браузер) сразу все 
возможные «Представления». То есть для каждого действия пользователя в 
WEB-клиенте найдется подходящее графическое WEB-представление, а с 
сервера потребуется загрузить лишь то, что изменилось в данных (например, 
какие-нибудь числовые данные в мониторинге, или любая другая 
информация в удобном виде, например, JSON). Благодаря такому подходу, 
при начальной загрузке страницы на WEB-клиент загружается сравнительно 
большой файл (около 200-300 КБ для больших WEB-сервисов), однако при 
дальнейших запросах в текущей сессии пользователю загружается от 1 Б до ~ 
2-3 КБ (в зависимости от размера измененных данных), при этом на экране 
перерисовывается только измененная часть, что экономит время загрузки 
необходимого представления и Интернет-ресурсы пользователя. В результате 
наблюдается высокая скорость работы WEB-сервиса, улучшается 
отзывчивость интерфейса, ускоряется переход между страницами благодаря 
клиентскому роутингу, а шаблонизация интерфейса значительно упрощает 
доработку клиентской части WEB-приложения. 
React построен на концепции компонентов. Он отличается от таких 
фреймворков, как Angular или Ember, которые используют двухстороннюю 
привязку данных для обновления HTML страницы. На взгляд многих 
фронтенд-разработчиков [3], React проще для изучения, чем Angular или 
Ember – он намного меньше и хорошо работает с jQuery и другими 
фреймворками. Он, к тому же, чрезвычайно быстр, так как использует 
виртуальный DOM и обновляет только измененные части страницы 
(обращение к DOM до сих пор является самой медленной частью 
современных WEB-приложений, поэтому данная библиотека и получает 
преимущество в производительности, оптимизируя его). 

---

16 
Клиентский роутинг в этом случае можно реализовать с помощью 
библиотеки react-router [4]. Данная библиотека позволяет связывать 
клиентские роуты с React-компонентами, таким образом, все возможные 
состояния WEB-интерфейса будут содержаться в JavaScript-файле проекта, 
где объявлены роуты (в точке входа приложения, в соответствие с рисунком 
2). 
Рисунок 2 – Код JS-файла точки входа приложения, содержащего клиентский роутинг 
Для отрисовки схем или сложных рисунков в WEB-интерфейсе также 
может потребоваться библиотека D3. D3.js (или просто D3) – это JavaScript-
библиотека для обработки и визуализации данных. Она предоставляет 
удобные утилиты для обработки и загрузки массивов данных и создания 
DOM-элементов. Название d3 расшифровывается как data driven document. 
Это JavaScript библиотека, ориентированная на работу с данными и их 
визуальное представление для WEB-приложений, включая загрузку данных, 
визуализацию в режиме реального времени и множество других 
возможностей [5, 6]. 
Так как большинство браузеров, используемых сегодня, не 
поддерживают современные стандарты EcmaScript [7], в браузерах 
необходимо использовать старый стандарт EcmaScript 5, который 
поддерживается всеми современными браузерами, включая Internet 

---

17 
Explorer 11 [8], что позволяет значительно расширить возможность 
использования разрабатываемого WEB-интерфейса. Однако, отказываясь от 
новейших стандартов языка программирования, разработчик также 
отказывается от возможностей использовать новый синтаксический сахар и 
некоторые оптимизационные решения новых стандартов. Для этого 
необходимо транслировать JavaScript более свежего стандарта [7] в JavaScript 
стандарта EcmaScript 5, с этой задачей справляется Babel (JavaScript-
компилятор, на сайте [9] располагается его документация). 
В итоге получается достаточно много зависимостей, которые требуется 
импортировать в большинстве файлов, также, при разработке приложения, 
код разрастается и появляется множество файлов. Для сборки JavaScript-
файлов и файлов стилей в один JavaScript-файл и файл стилей 
соответственно, понадобится система сборки кода и пакетов в WEB-
фронтенде, webpack, документация которого расположена на сайте [10]. 
2.1.2 CSS-библиотеки 
CSS является примитивным и неполным языком программирования. В 
нём очень сложно создать функцию, переиспользовать определение или 
использовать наследование. Для больших проектов или сложных систем, 
поддержка кода на CSS становится большой проблемой. Однако, WEB-
технологии быстро развиваются, новые спецификации вводятся как в HTML, 
так и в CSS. WEB-браузеры применяют эти спецификации, но оставляют 
свои специальные вендор-префиксы. В некоторых случаях (в таких как, 
например, фоновый градиент), программирование с использованием 
специальных вендор-префиксов становится тяжелой ношей. Приходится 
добавлять всевозможные префиксы разных версий браузеров, чтобы достичь 
одинакового результата. 
Чтобы код на CSS получался лучше, программисты чаще всего 
используют различные подходы, например, разделение определений стилей в 

---

18 
небольшие файлы и их импортирование в один большой главный файл. 
Такой подход помогал разделять стили по компонентам, но не решал 
проблему с повторениями кода и не облегчал его поддержку. Другим 
подходом являлись попытки внедрения объектно-ориентированного 
программирования в CSS. В этом случае, к элементу применялись два или 
более определений классов. Каждый класс добавлял один тип стиля к этому 
элементу. Создание множества классов увеличивало возможность 
наследования кода, но уменьшало возможность эффективной поддержки 
кода. 
Препроцессоры, в свою очередь, помогают достичь написания 
масштабируемого и легко поддерживаемого кода в CSS. Используя 
препроцессор, программист может легким образом увеличить свою 
продуктивность и уменьшить объём кода в своём проекте. 
Таким образом, в первую очередь, для комфортного программирования 
стилей для WEB-клиента, разработчику необходим CSS-препроцессор. CSS-
препроцессоры расширяют использование CSS переменными, операторами, 
интерполяциями, функциями, «примесями» (mixins) и остальными 
полезными средствами. Наиболее известными CSS-препроцессорами 
являются SASS [11], LESS [12] и Stylus [13].
Как и любой язык программирования, препроцессоры имеют 
различные синтаксисы, однако, они довольно похожи друг на друга. Все 
препроцессоры поддерживают «классическое» программирование на CSS и 
их синтаксисы в целом схожи с CSS. 
Рассмотрим, чем отличаются синтаксисы CSS-препроцессоров на 
примере примесей (в соответствии с рисунком 3). Примеси – это набор 
условий, который компилируется в соответствии с некоторыми параметрами 
или статическими правилами. С помощью них можно создавать что-то 
наподобие функций и переиспользовать правила стилей в других местах в 
коде. Как видно из рисунка 3, наиболее привычным синтаксисом, похожим 

---

19 
на CSS, является синтаксис SASS и LESS, однако в SASS более конкретное, 
подробное описание использования примесей (@mixin, @include), чем в 
LESS (символ “.”, что дублирует селектор класса, который тоже начинается с 
символа “.”), поэтому при разработке будет использоваться CSS-
препроцессор SASS [14]. 
Рисунок 3 – Описание примесей в разных препроцессорах и аналог в CSS 
Далее, разработчику необходимо каким-то образом эффективнее 
писать кросс-браузерный CSS-код. Для этого нужна утилита, которая 
автоматически добавляет префиксы к правилам стилей. Например, компания 
Google рекомендует autoprefixer [15, 16] для postCSS-обработки. Данная 
библиотека позволяет писать стили без специальных вендор-префиксов (в 
соответствии с рисунком 4 и рисунком 5), таким образом, решается проблема 
с написанием кросс-браузерных стилей.

---

20 
Рисунок 4 – Описание CSS-правила без вендор-префиксов 
Рисунок 5 – Описание CSS-правил с вендор-префиксами, после работы autoprefixer 
2.2 Интеграция стека технологий 
Для того, чтобы эффективно интегрировать большое количество 
зависимостей в проект, необходим пакетный менеджер. Без пакетного 
менеджера зависимости необходимо скачивать с интернет-источников 
вручную, либо загружать зависимости в систему контроля версий кода, что в 
десятки раз увеличит размер разрабатываемого проекта и негативно повлияет 
как на скорость скачивания и установки проекта, так и на ресурсы сервера 
системы контроля версий. Самым известным пакетным менеджером для 
JavaScript-библиотек является npm, который в свою очередь также является 
самым большим в мире программным реестром [17]. С помощью npm нет 
необходимости добавлять файлы зависимостей в проект, а достаточно 
добавить в корень проекта файл с наименованием «package.json» 
(Приложение А), который содержит соответствие названий JavaScript-

---

21 
библиотек и их версий, при этом, версии можно «заморозить». Таким 
образом, в проекте всегда будут нужные версии пакетов, а загружать их 
можно перед запуском или сборкой проекта простой командой в консоли 
“npm install” (находясь при этом в корне проекта). 
Зависимости проекта, в свою очередь, могут также содержать свои 
зависимости, которые будут загружены при выполнении команды “npm 
install”. Следовательно, кодовая база проекта будет содержать значительное 
количество кода, большая часть из которого не сжата, а некоторые части кода 
могут не использоваться в проекте и занимать лишнее место, что ведет к 
загрузке лишних данных в браузере при загрузке страницы и помещении 
этих данных в оперативную память, что может замедлить работу WEB-
интерфейса. Чтобы избежать данных проблем, необходимо отсеивать 
неиспользуемый код и сжимать его при сборке, однако наиболее эффективно 
делать это автоматически. Автоматически это можно сделать, если 
подходящим образом сконфигурировать сборку в webpack [10], а именно, 
добавив в конфигурационный файл webpack UglifyJsPlugin [18], который 
производит минификацию и обфускацию JavaScript-кода. Также, необходимо 
добавить DedupePlugin [19], который ищет одинаковые файлы в проекте и 
исключает их из итоговой сборки. Неиспользуемые файлы и библиотеки 
webpack не включает в результат сборки по умолчанию. 
Для того, чтобы автоматически использовать такие технологии, как 
CSS-препроцессоры, 
postCSS-обработка 
(autoprefixer), 
современные 
стандарты EcmaScript [7], необходимо также добавить в конфигурационный 
файл системы сборки webpack так называемые «загрузчики» (loaders). [20] 
Например, описанные в файле “package.json” (Приложение А) зависимости 
babel-loader, sass-loader, postcss-loader и autoprefixer позволяют разработчику 
писать код на JavaScript современных стандартов, использовать синтаксис 
CSS-препроцессора SASS и не писать специальные вендор-префиксы, т.к. 

---

22 
трансляция языков и добавление префиксов произойдёт автоматически при 
сборке. 
2.3 Тестирование интеграции технологий 
Набор зависимостей, описанных в Приложении А, после загрузки в 
проект занимает 78,7 МБ на жёстком диске ПК (в соответствии с рисунком 
6). Размер всего остального кода в проекте составляет 804 КБ на жёстком 
диске ПК (в соответствии с рисунком 7). 
Рисунок 6 – Свойства папки “node_modules”, в которой содержатся все зависимости 
проекта 

---

23 
Рисунок 7 – Свойства всех файлов проекта, кроме папки “node_modules” 
Без применения описанных выше плагинов, собранный в webpack 
проект занимает 5,05 МБ на жёстком диске ПК (в соответствии с рисунком 
8), а с применением плагинов – 968 КБ (в соответствии с рисунком 9), 
следовательно, в этом случае размер собранного проекта уменьшился почти в 
5 раз, что говорит о несомненной пользе упомянутых выше плагинов для 
сборки production-версии разработанного проекта. 

---

24 
Рисунок 8 – Свойства папки “release”, в которой содержатся файлы проекта, собранного 
без плагинов для оптимизации 
Рисунок 9 – Свойства папки “release”, в которой содержатся файлы проекта, собранного с 
плагинами для оптимизации 

---

25 
2.4 Способы масштабирования WEB-приложения 
2.4.1 Описание проблем производительности WEB-клиента 
В настоящий момент в сфере разработки WEB-приложений существует 
множество проблем, связанных с недостаточной производительностью. 
Данные в больших WEB-приложениях на стороне сервера (или базы данных) 
могут занимать более 900 ГБ (например, данные об учащихся в 
международном масштабе) [21]. Поэтому, одной из проблем в разработке 
WEB-фронтенда больших WEB-приложений является низкая скорость 
обработки большого потока данных, присылаемого с сервера на WEB-клиент 
(чаще всего, WEB-браузер). Организацию обновления визуальных данных в 
WEB-клиенте можно выполнить разными способами: обновлять (и 
перерисовывать) данные исключительно после непосредственного запроса 
пользователя, использовать поллинг (WEB-клиент выполняет запросы на 
сервер с определенным интервалом) или использовать отличный от HTTP 
протокол для обмена сообщениями между браузером и WEB-сервером в 
режиме реального времени (например, WebSocket).
2.4.2 Сравнение способов обновления данных в WEB-приложении 
В первую очередь, как было сказано выше, организацию обновления 
визуальных данных в WEB-клиенте можно выполнить с помощью обычных 
HTTP-запросов по требованию пользователя. Например, в поисковом сервисе 
компании Google [22] используется именно такой метод: нажимая на кнопку 
поиска, пользователь отправляет HTTP-запрос на сервер, после чего получает 
ответ и обновляет информацию на странице. Пример простого HTTP-запроса 
на языке JavaScript приведен в Приложении Б. 
Во-вторых, организацию обновления визуальных данных в WEB-
клиенте можно выполнить с помощью HTTP-поллинга. В этом случае 
используется тот же простой HTTP-запрос данных, как и в первом случае, 

---

26 
однако он повторяется с некоторым интервалом времени, таким образом, 
WEB-клиент имеет возможность показывать информацию в реальном 
времени (пример на языке JavaScript приведен в Приложении В). Данный 
метод прост в реализации и может использоваться при разработке простого 
WEB-интерфейса сетевого устройства для мониторинга небольшого 
количества данных, например, мониторинг одной таблицы параметров 
сетевого устройства в реальном времени. 
Наконец, обновление визуальных данных можно реализовать с 
помощью WebSocket. В этом случае WEB-клиент открывает соединение с 
сервером [23] и подписывается на необходимые топики («темы») данных, 
после чего сервер отправляет данные по подписке в тот момент, когда 
посчитает нужным, например, когда данные изменились в базе данных 
(пример на языке JavaScript приведен в Приложении Г). Примером WEB-
приложения может стать любое WEB-приложение с обновлением данных в 
реальном времени, так как WebSocket является самым эффективным с точки 
зрения производительности и нагрузки на сервер транспортом [24]. 
Яндекс.Почта, доступная по адресу [25], использует WebSocket для загрузки 
сообщений с сервера в реальном времени (в соответствии с рисунком 10). 
Рисунок 10 – WebSocket-подключение на странице Яндекс.Почты 

---

27 
Таблица 1 – Сравнение способов организации обновления данных в WEB-
клиенте 
Из сравнения в таблице 1 видно, что для обработки больших данных 
выгоднее всего использовать WebSocket, т.к. размер потока сообщений 
Критерий сравнения 
Обновление 
только после 
запроса 
Поллинг 
WebSocket 
Возможность создания 
приложения с 
обновлением данных в 
реальном времени 
- 
+ 
+ 
Большое количество 
готовых реализаций 
(следовательно, простота 
разработки) 
+ 
+ 
- 
Малое количество 
запросов с WEB-клиента 
на сервер 
+/- (зависит от 
частоты прямых 
запросов 
пользователей) 
- 
(запросы 
посылаются 
с 
определенным 
интервалом, 
например, 2 раза в 
секунду) 
+ (запрос только 
один: 
для 
установки 
соединения 
с 
сервером) 
Необходимость 
реализации методов 
оптимизации большого 
потока данных на стороне 
WEB-клиента 
- (большой поток 
данных 
может 
возникнуть 
только 
из-за 
большого 
количества 
прямых запросов 
пользователей, 
его 
нужно 
обрабатывать на 
сервере, 
вследствие 
чего 
замедление 
работы 
интерфейса 
у 
других 
пользователей не 
возникнет) 
+ 
(Поллинг 
используется 
для 
реализации 
приложения 
с 
обновлением 
данных в реальном 
времени, поэтому 
данные 
нужно 
обновлять 
достаточно часто. 
Однако, если на 
сервере 
данных 
очень много (вся 
база может весить 
около 1 ТБ), то 
поллинг, даже с 
реализацией 
кластеризации 
данных [26] может 
стать совершенно 
неприменимым 
решением.) 
+ (Сервер сам 
посылает данные 
на WEB-клиент, 
поэтому, 
если 
сервер 
наблюдает в базе 
данных частые 
изменения – все 
изменения 
попадут в WEB-
клиент в виде 
большого потока 
сообщений.) [23] 

---

28 
между WEB-клиентом и сервером получается наименьшим и наиболее 
обоснованным (т.к. метод обновления только после запроса пользователя не 
подходит для создания приложения с данными, обновляющимися в реальном 
времени, а поллинг не подходит для постоянной загрузки данных, когда 
данных становится очень много; к тому же, при использовании поллинга 
WEB-клиент производит запросы на сервер всегда, даже тогда, когда данные 
в базе данных не изменились). Явным недостатком при использовании 
WebSocket становится множество различных так называемых «обёрток» над 
протоколом, без единой стандартизации. В таком случае необходимо выбрать 
такой протокол, который будет поддерживаться и на стороне WEB-клиента, 
и на стороне сервера. Несмотря на крайне ограниченное количество готовых 
решений для реализации передачи данных по данному протоколу, 
существует реализация протокола с открытым стандартом WAMP [27], с 
помощью которой можно относительно просто реализовать передачу и прием 
данных через WebSocket. Исходный код данной реализации расположен на 
сайте [28]. 
2.4.3 Решения проблемы очереди сообщений при большом потоке 
данных на WEB-клиент 
Чтобы решить проблему большого потока сообщений с сервера на 
WEB-клиент, например, в случае мониторинга большой сети, необходимо 
каким-то образом свести обработку каждого пришедшего сообщения к 
минимальному количеству операций, таким образом, уменьшив общее время 
обработки сообщений за определенный промежуток времени, что позволяет 
быстрее освобождать ресурсы для выполнения других задач (например, 
таких тяжелых, как построение DOM) в однопоточном WEB-клиенте. 
Буферизация данных позволяет эффективно решить данную проблему. Такая 
буферизация работает наподобие буферизации в процессоре (описанной в 
работе [29]), а именно при использовании буферизации WEB-клиент не 

---

29 
обрабатывает пришедшие с сервера сообщения сразу, а складывает их в 
буфер, причем не в массив, а сливает все данные в одно сообщение, чтобы 
его можно было удобно в дальнейшем применить к имеющимся данным, и 
всего один раз за заданный промежуток времени. 
Представим, что разрабатываемое WEB-приложение может содержать 
как малое количество данных в базе данных, так и очень большое количество 
данных. Например, приложение мониторинга сети в реальном времени. Если 
сетевых узлов мало (допустим, их количество может быть от 1 до 50), то 
буферизация сыграет небольшую роль, т.к. современные компьютеры имеют 
достаточные вычислительные ресурсы, чтобы успевать обработать 
телеметрию такого количества устройств (разумеется, если каждое 
сообщение не влечёт за собой, например, пересчет и перестроение графа 
топологической 
сети). 
Следовательно, 
нужно 
каким-то 
образом 
минимизировать влияние буферизации на визуальное отображение WEB-
интерфейса пользователя, когда сетевых узлов, а точнее, сообщений с 
сервера мало (приходят реже, чем заданный ранее интервал буферизации), и 
постепенно увеличивать влияние буферизации на скорость обновления 
данных в интерфейсе для того, чтобы вычислительные операции не забивали 
стек процесса и не вызывали визуальное затормаживание интерфейса, если 
сообщение начинают приходить чаще. Для этого предлагается обновлять 
таймер применения данных минимум до того момента, когда ни одно 
сообщение не придёт за заданный ранее интервал, а максимум до того 
момента, когда значение суммы временных интервалов (учитывая 
обновления таймеров) достигнет какой-нибудь критической отметки для 
форсированного обновления. Например, если задать минимальный интервал 
обновления равным 200 мс, то в том случае, если в течение 200 мс придёт 
только одно сообщение, то данные из этого сообщения применятся к данным 
в уже существующем WEB-хранилище сразу после данного интервала, 
иначе, таймер обновится и будет ожидать сообщение, если сообщение вновь 

---

30 
успеет прийти с сервера – таймер обновится и так далее. Так будет 
происходить до тех пор, пока сумма такого времени не достигнет 
критической отметки, равной, например, 1 секунде, и в этом случае данные, 
слепленные из всех пришедших за 1 секунду сообщений применятся к уже 
существующим данным в хранилище. Таким образом, при большом потоке 
данных обновление данных в WEB-интерфейсе будет происходить не чаще, 
чем 1 раз в секунду, а при малом потоке данных может происходить от 1 раза 
в 200 мс до 1 раза в 1 секунду. 
Рассмотрим реализацию данного алгоритма на языке JavaScript 
стандарта EcmaScript 2015 [30], представленную в Приложении Г. В данной 
реализации класс UpdateHandler отвечает за накопление и применение 
накопленных данных к хранилищу данных. В данной реализации класс 
обрабатывает сообщение о событиях, произошедших в большой сети, 
поэтому, потребовалась буферизация, чтобы свести задержки операций к 
минимуму. Внешние обработчики сообщений WebSocket используют метод 
bufferedUpdate, передавая в него сообщения с обновлениями данных о 
событиях, произошедших в сети. Учитывая, что константа, определенная в 
Приложении А как Constants.DEFAULT_UPDATE_TIMEOUT равна 200 мс, 
получаем реализацию буферизации, описанной выше. 
Современные 
технологии 
WEB-программирования 
позволяют 
реализовать 
WEB-приложения, 
удовлетворяющие 
как 
отсутствию 
чрезмерных вычислений и оптимизационных операций при малом потоке 
данных, так и отсутствию видимых задержек вычислений при большом 
потоке данных. Различные задачи разработок требуют использования разных 
технологий, методов и подходов к обработке информации и оптимизации 
данного процесса, однако в объёмных WEB-приложениях остаётся выгодным 
использование протокола WebSocket для организации обновления данных в 
WEB-клиенте и буферизации для оптимизации этого обновления. 

---

31 
3 Разработка программного комплекса «Умная парковка» 
3.1 Обзор аналогов 
Многие системы мониторинга парковочного пространства имеют 
сравнительно низкую интеллектуальную составляющую и точность 
показаний. Некоторые решения основаны на информации от паркоматах 
(парковочных автоматах), которые рассчитывают на достоверность 
информации о наличии свободного места при отсутствии оплаты [31]. 
Однако, такое решение не обеспечивает достоверность информации, так как 
располагает только косвенными данными. К тому же автопарковка около 
торгового центра обычно является бесплатной.
Другие решения предполагают установку большого количества 
датчиков, которые не защищены от условий окружающей среды и 
вандализма [32]. 
Крупные торговые центры прилагают усилия по обеспечению 
комфорта и безопасности парковок. Так, например, в Германии на парковке 
организовано наблюдение за всеми парковочными местами благодаря 
широкоугольным IP-камерам, которые ведут видеозапись целой группы 
парковочных мест по всей площади. Это позволяет увидеть кто, когда и 
какое парковочное место занимает либо покидает. При постоянной смене 
клиентов в течение дня рекомендуется вести непрерывную запись 
изображений с камер. Ночью или при небольшом движении на парковке 
предпочтительна эпизодическая запись по датчику движения, а также 
включение живого изображения на центральной станции [33]. Однако 
установленные системы видеонаблюдения используются только для целей 
безопасности, так как функционируют на платной парковке с заранее 
выделенными местами.
Интересное решение, представленное компанией StreetLine [34] 
ориентировано на использование видеоанализа, беспроводных технологий и 

---

32 
систем геопозиционирования. Как следует из названия компании, оно 
рассчитано на открытые парковки городских улиц.
Удачная система управления парковкой реализована компанией Park 
Assist [35], однако она не использует возможности сетевых технологий для 
мобильных устройств. Также эта система является закрытой для расширения 
возможностей и имеет сравнительно дорогую стоимость. Существует 
необходимость в создании системы управления парковой, которая может 
быть использована как на открытых, так и на закрытых парковках при 
минимальных затратах. 
3.2 Описание системы 
Предлагаемое решение является комплексной системой, которая 
включает в себя устройства сканирования парковочных мест, которые могут 
быть применены как для задач безопасности, так и для автоматизированной 
обработки информации. Интеллектуальная система обработки изображений 
позволяет анализировать данные о наличии свободных мест и выдавать 
информацию на различные устройства и информационные сервисы. Такими 
устройствами могут быть как телефоны и планшеты, так и электронные 
указатели, размещенные по территории парковки. Сервис, предназначенный 
для планшетов, может быть использован в составе информационного киоска. 
Для водителей, не обладающих мобильными устройствами, 
подключенными к «умной парковке», можно использовать средства 
отображения информации в виде светодиодного табло. Это позволяет 
расширить круг потребителей информации за счет доступности средств 
отображения информации. Такие технические средства являются 
наглядными и доступными по цене. На парковке должны быть установлены 
электронные табло и указатели в количестве, необходимом для ориентации в 
пространстве паркинга и однозначного понимания расположения свободных 
мест. 

---

33 
Умная парковка является компактной геоинформационной системой. 
При наличии возможности подключения мобильного устройства к сети 
передачи данных (GSM, Wi-Fi), пользователю может быть предоставлена 
расширенная информация о наличии парковочных мест. Такой сервис 
значительно упрощает процесс передвижения автомобиля, снижает время на 
ориентирование в пространстве и повышает качество предоставляемых 
услуг. 
Основным источником информации о свободном парковочном месте 
является информация с видеокамер. Камеры расположены на парковке таким 
образом, чтобы все парковочные места попали в поле обзора.
Существуют различные методы распознавания образов, которые 
позволяют с высокой долей вероятности идентифицировать наличие 
свободного пространства в заданном секторе. Каждое парковочное место 
отмечено специальным знаком-маркером (в соответствии с рисунком 11). 
Если автомобиль занимает парковочное место, то он полностью закрывает 
специальный знак и можно считать это место занятым. 
Рисунок 11 – Пример табло и парковочных мест в разрабатываемой системе 

---

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

---

35 
Для поиска своего автомобиля предусмотрен сервис для мобильных 
устройств и информационных киосков. Привязанный к мобильному 
устройству автомобиль позволит вызвать владельца в случае возникновения 
нештатных ситуаций. 
Некоторое количество парковочных мест оснащено функционалом 
«помощник парковки» для комфортной парковки водителей, которые 
затрудняются с определением габаритов. Это функция реализуется за счет 
стационарного расположения систем «парктроник». Она также является 
датчиком свободного места. 
3.2.1 Состав системы 
Система умной парковки состоит из двух подсистем: 
1.
Аппаратная и материальная часть 

1 IP-камера Cisco для распознавания номеров 

1 широкоугольная видеокамера для распознавания символов на 
парковочных местах 

Ультразвуковые датчики для идентификации занятых мест 

Уникальные графические символы для идентификации занятых 
мест видеокамерой 

Макет поверхности парковки 

3 машинки для презентации 

Контроллер для сбора и обработки данных 
2.
Программная часть 

WEB-сервер (WEB-API для веб-интерфейса пользователя), 

WEB-интерфейс для пользователей 

Общая база данных 

Программа видеоанализа свободных мест 

Программа видеоанализа и распознавания автомобильных номеров 

---

36 
В качестве системы контроля версий была выбрана система Git [36], 
которая является распространенной среди WEB-разработчиков, а также 
имеет удобный графический интерфейс и функциональную командную 
консоль. В качестве сервера для системы контроля версий выбран Bitbucket 
[37], так как данный сервер позволяет бесплатно хранить приватные 
репозитории кода, а также удобно объединять репозитории в проекты и 
создавать команды разработчиков в WEB-интерфейсе (в соответствии с 
рисунком 13). 
Рисунок 13 – Список репозиториев проекта "Умной парковки" 
3.2.2 Поток данных в системе 
Схема работы системы умной парковки представляет из себя 
абстрактное представление о потоке данных в системе (в соответствии с 
рисунком 14). Информация с видеокамер сохраняется на видеосервере и 
доступна для непосредственного наблюдения, а также последующей 
обработки. В зависимости от места установки камеры и наличии изменений 
в изображении система определяет присутствие автомобиля и при его 
наличии распознает номер. Камеры, наблюдающие за парковочными 
местами, фиксируют состояние занятости парковочных мест. Если место 
свободно, то информация поступает в базу данных. 
База данных хранит информацию о состоянии парковочных мест и 
номерах автомобилей в каждый момент времени. Полученная информация 
может быть использована для предоставления информации разным 

---

37 
пользователям в различных форматах, а также мониторинга и сбора 
статистики 
Рисунок 14 – Абстрактная схема работы умной парковки 
3.2.3 Пользовательские сценарии 
Разрабатываемая 
система 
предполагает 
три 
возможных 
пользовательских сценария: автоматическая парковка, ручная парковка с 
авто-назначенным парковочным местом и ручная парковка с местом, 
зарезервированным пользователем. Во-первых, пользователь решает, хочет 

---

38 
ли он заранее зарезервировать парковочное место. Если да, то пользователю 
необходимо зарегистрировать индивидуальный регистрационный номер 
своего транспортного средства в веб-приложении (например, в мобильном 
телефоне) и зарезервировать парковочное место в интерфейсе, либо 
позволить системе зарезервировать место автоматически. Веб-приложение 
показывает свободные и занятые места, выделенные зелеными или красными 
кругами соответственно (в соответствии с рисунком 15), и не позволяет 
пользователю зарезервировать уже занятое или забронированное место. 
Рисунок 15 – Визуализация занятых и не занятых мест в веб-приложении 
Когда машина подъезжает к въезду на парковку, камера распознает 
индивидуальный регистрационный номер, и система записывает фотографию 
и регистрационный номер в базу данных, ассоциируя номер с именем 
пользователя. Если такое соответствие нашлось, веб-приложение показывает 
пользователю схематичную навигацию к парковочному месту, выбранному в 

---

39 
приложении. Информация о занятости мест обновляется в реальном времени, 
поэтому не стоит волноваться даже о том, что место могут занять, пока 
водитель движется к нему – система произведет перерасчет пути к 
следующему ближайшему парковочному месту в случае, если место по 
какой-то причине займут. Приложение имеет Wi-Fi соединение с сервером, 
который отслеживает местоположение машины и рассчитывает путь до 
парковочного места с помощью анализа изображений, полученных с 
видеокамер. Видеокамеры, наблюдающие за парковочными местами, 
постоянно отслеживают их статус. Например, если камера не может 
распознать специальную метку на парковочном месте (допустим, в виде “X”), 
то считается, что место занято. В данном случае для дополнительной 
проверки могут использоваться ультразвуковые датчики, которые позволят 
проверить, действительно ли место занято, и на нем не припарковать ещё 
одно транспортное средство, или же метка просто покрыта снегом, грязью 
или пылью и перестала распознаваться. Данные с датчиков и камер также 
записываются в базу данных для того, чтобы веб-приложение смогло 
отобразить пользователю информацию о занятых местах, а также 
поддерживать актуальное состояние данных. 
Если соответствие регистрационного номера и имени пользователя не 
было найдено, система автоматически находит ближайшее свободное место и 
назначает его данному транспортному средству, выводя регистрационный 
номер вместе с указанием направления на табло. В данном случае веб-
приложение не используется.
Алгоритм 
работы 
системы 
изображен 
на 
UML-диаграмме 
последовательности (Приложение Е), абстрагированная от особенностей 
реализации архитектура работы веб-приложения для парковки изображена на 
UML-диаграмме активности (Приложение Ж). Схема компонентов и их 
взаимодействия изображена на UML-диаграмме компонентов (Приложение 
И). 

---

40 
3.4 Разработка программного обеспечения 
3.4.2 Разработка WEB-сервера 
Для разработки WEB-сервера была выбрана технология NodeJS [38], 
т.к. она позволяет ускорить процесс реализации вследствие того, что 
используется один и тот же язык программирования, что и в WEB-
интерфейсе (JavaScript). Структура WEB-сервера не является сложной (в 
соответствии с рисунком 16), так как сервер представляет из себя набор 
обработчиков HTTP-запросов и обращений в базу данных. Сервер 
предоставляет пользовательскому интерфейсу API (Приложение К) для 
безопасного изменения или сохранения данных в базе данных. 
Рисунок 16 – Структура исходного кода WEB-сервера в системе контроля версий

---

41 
Сервер предоставляет не только API, но и сами статические файлы 
собранного проекта WEB-интерфейса пользователя, расположенные в папке 
«release». 
3.4.3 Создание базы данных 
Для создания базы данных выбрана СУБД MongoDB [39], так как 
данная СУБД имеет драйвер для WEB-сервера, написанного с 
использованием технологии NodeJS, а также по причине того, что данные в 
MongoDB хранятся в формате JSON [40], что соответствует формату данных, 
использующимся в JavaScript. Проанализировав принципы работы 
разрабатываемой системы, были установлены следующие основные 
сущности для проектирования БД: 
1.
Пользователи. Данная коллекция документов хранит информацию о 
зарегистрированных в системе пользователях. Структура коллекции 
представлена в таблице 2. 
Таблица 2 – Коллекция «users» 
Название поля 
Тип данных 
_ID 
ObjectId 
name 
String 
password 
String 
licensePlate 
String 
2.
Парковочные 
места. 
Данная 
коллекция 
документов 
хранит 
информацию о парковочных местах, а именно, о состоянии мест 
(занято, свободно или забронировано), информацию о том, кто занял 
место, в какое время место было забронировано. Структура коллекции 
представлена в таблице 3. 

---

42 
Таблица 3 – Коллекция «parking» 
Название поля 
Тип данных 
_ID 
ObjectId 
id 
Number 
name 
String 
reserved 
Boolean 
occupiedByVideo 
Boolean 
occupiedBySensors 
Boolean 
userName 
String 
time 
Date 
3.4.4 Разработка WEB-интерфейса 
WEB-приложение использует клиент-серверную архитектуру. В 
частности, сервер выступает в качестве посредника между клиентом и базой 
данных, обеспечивая безопасную запись, чтение, редактирование и удаление 
документов в коллекциях базы данных mongoDB. 
Архитектура клиентской части WEB-приложения состоит из: 

Корня приложения, обеспечивающего клиентский роутинг (SPA – 
Single Page Application) и позволяющий менять визуальное 
представление браузера без полной перезагрузки страницы. (в 
соответствии с рисунком 2) 

Компонентов и стилей, реализующих визуализацию данных в 
клиентском браузере (в соответствии с рисунком 17, Приложение Л) 

---

43 
Рисунок 17 – Структура директорий React-компонентов 

Reflux-идеологии потока данных в клиентской части WEB-приложения 
[41]. Из действий (Actions) данные попадают в хранилище (Store) (в 
соответствии с рисунком 18, Приложение М), оттуда данные попадают 
в представление (View) посредством прослушивания событий 
изменения хранилища. Представлениями в данном случае являются 
React-компоненты. 

---

44 
Рисунок 18 – Структура директорий Reflux-сущностей