Марина С. Шаповалова
Московский государственный технический университет им. Н.Э. Баумана, Москва, Россия, mshapovalova84@gmail.com
Александр А. Андреев
Московский государственный технический университет им. Н.Э. Баумана, Москва, Россия, andreev@indry.tech
Валерия В. Чувашова
Московский государственный технический университет им. Н.Э. Баумана, Москва, Россия, chuvashova@indry.tech
Аннотация. В статье анализируются технические требования, предъявляемые к электрозаправочным станциям с точки зрения определения возможности и особенностей проектирования информационной системы по их обслуживанию. Показаны основные особенности работы электрозаправочных станций, согласно стандартам, принятым в Европе, США и Китае. Рассмотрены их функциональные характеристики и специфика работы для удаленного управления с помощью информационной системы.
Сформулированы требования к информационной системе, которая может быть создана на основе микросервисной архитектуры. Показано, что для обеспечения взаимодействия между отдельными частями информационной системы должна быть обеспечена стабильность ее работы в режиме 24/7.
В ходе исследования определено, что:
взаимодействие клиента с сервером может быть реализовано посредством некоторого приложения или web-интерфейса и должно быть стабильным и устойчивым;
эта система будет включать в себя платежный модуль, электрическую балансировку, а обработка поступающих данных на сервер будет представлять собой распределенную систему обработки информации, имеющей в своей основе очередь с приоритетами;
сама информационная система должна быть спроектирована на основе архитектуры, реализующей клиент-серверный принцип работы;
специальная система мониторинга должна быть распределенной, что позволит своевременно обрабатывать поступающие запросы, видеть проблемы и своевременно решать их.
© Шаповалова М.С., Андреев А.А., Чувашова В.В., 2023
Ключевые слова: клиент, сервер, архитектура, электрозаправочные станции, микросервисы
За последние 15 лет количество электромобилей в мире выросло в 7 тыс. раз и, по прогнозам, еще через 10 лет составит 30% от всего автотранспорта. Растет и смежный, обслуживающий бизнес, в том числе станции по заправке таких автомобилей.
Десятки компаний, работающих с электрозаправочными станциями (ЭЗС – зарядная станция или электрозаправочная станция – элемент городской инфраструктуры, предоставляющий электроэнергию для зарядки аккумуляторного электротранспорта, такого как электромобили, электробусы, электроскутеры, электросамокаты, гироскутеры, сигвеи, электровелосипеды и т. п.), уже нашли своих клиентов, а в большинстве регионов они также являются объектами критической инфраструктуры и монополистами.
Поскольку заправка на ЭЗС, как правило, осуществляется в автономном режиме, очень важно определить принципы работы информационной системы, обслуживающей зарядные станции, управляющей проверкой и заправкой электромобилей. В этих условиях важно обеспечить требования информационной безопасности [Казарин, Шаряпов, Ященко 2018].
Данная статья направлена на описание технических требований с целью проектирования информационной системы, которая бы позволяла пользователям ЭЗС проводить заправку, а также особенностей ее будущей реализации.
Необходимо отметить, что такая система является объектом критически важной инфраструктуры, она является высоконагру- женной системой повышенной опасности и должна автономно работать 24/7.
На международном рынке представлены три основных стандарта ЭЗС [1], каждый из которых отличается особой геометрией зарядного штекера электромобиля и зарядной розетки. Представленные стандарты используются в Северной Америке, Европе и Китае. Кроме того, конструкция штекера для зарядки переменым током принципиально отличается от штекера для зарядки постоянным током.
Большой ассортимент оборудования для заправки автомобиля позволяет охватить все варианты применения (рис. 1). Стандарт по типу 1 для Северной Америки не предусматривает наличие инфра- структурного зарядного штекера.
В Европе в этом случае используется переходной кабель, который состоит из зарядного штекера электромобиля по типу 1 и инфраструктурного зарядного штекера по типу 2 [2].
В России распространены автомобили с зарядками всех трех типов. Поэтому необходимо, с одной стороны, унифицировать работу ЭЗС на аппаратном уровне, а с другой – обеспечить поддержку заряда для разного типа автомобилей. Однако полностью унифицировать виды зарядных устройств невозможно. Но при участии ведущих производителей автомобилей была разработана комбинированная система зарядки (CCS). Особенностью является зарядная розетка [3] (рис. 2) в электромобиле, которая подходит
для зарядных штекеров как переменного, так и постоянного тока. В этом случае электромобилю требуется только один интерфейс для зарядки как переменным, так и постоянным током.
Оборудованием всех типов будут оснащены ЭЗС, осуществляющие автономную заправку электромобилей. Подачу тока для зарядки, контроль состояния ЭЗС, оплату заправки будет осу- ществлять информационная система.
С одной стороны, такая система должна быть автономной и не предполагать персонал, который бы занимался контролем подачи тока ЭЗС при зарядке электромобиля. С другой стороны, необходимо отслеживать состояние каждой зарядной станции в системе, чтобы контролировать процесс зарядки, проверять состояние: станция рабочая/нерабочая; проводить оплату клиентами за зарядку электромобиля, учитывать возможности расширения парка географически удаленных друг от друга зарядных устройств, большего количества клиентов с разными типами электромобилей.
Для разработки информационной системы сети автомобильной ЭЗС необходимо учитывать следующие требования (рис. 3):
возможность обрабатывать большое количество запросов и постоянно отслеживать состояние каждой ЭЗС в системе;
большая удаленность ЭЗС друг от друга;
возможность работы с клиентами в разных регионах страны;
наличие большого парка ЭЗС с разным типом зарядки;
доступность системы 24/7;
возможность интеграции информационной системы по спек- тру протоколов со сторонними организациями;
возможный вариант реализации информационной системы как монолитной, с возможностью выделения отдельных сервисов для реализации клиент-серверной архитектуры и микросервисов для реализации отдельных функций.
Ключевым моментом программного отслеживания состояния ЭЗС является процесс зарядки электромобиля. При этом необходимо, чтобы:
происходила авторизация пользователя посредством радиочастотной идентификации;
отслеживалось состояние ЭЗС с помощью светодиодного индикатора;
производилось измерение дифференциального тока как показателя заправки электромобиля, так и корректной работы зарядной станции. Стабильный процесс зарядки автомобиля от ЭЗС обеспечивается множеством систем на обеих сторонах безопасности – контроля и мониторинга, подсчета и калькуляции, которые в реальном режиме взаимодействуют между собой. Для обработки состояний ЭЗС предполагается использовать распределенную систему обработки информации. В этом случае состояние ЭЗС удобно рассматривать как заявку, которая будет иметь статусы: «ожидает бронирования», «забронирована», «выдана» (рис. 4).
Рис. 4. Формирование заявки
Такой подход позволит рассматривать разрабатываемую информационную систему как автомат по обработке заявок. Состояние автомата удобно хранить в базе данных, а обрабатывать заявку (преобразовывать вход автомата в выход) следует в несколько потоков.
Число потоков разумно выбирать в зависимости от вычислительных мощностей, а не от числа активных заявок.
Реализовать такую систему удобно с помощью нескольких рабочих потоков, каждый из которых обрабатывает события следующим образом:
извлекает событие из очереди (например, внутреннее сообщение от подсистемы обмена);
определяет, к какому автомату относится событие;
считывает его состояние из постоянного хранилища (БД);
обрабатывает событие;
сохраняет в БД новое состояние автомата и удаляет событие из очереди событий.
В связи с особенностями существующих правил безопасности на большинстве ЭЗС нет возможности выполнить запрос серверу на выполнение того или иного действия, именно поэтому должна выполняться проверка состояния ЭЗС со стороны сервера по определенному протоколу и порту [4].
Информационная система обработки заявок построена на серверной части на Python3 и представляет собой классическую СМО ДБА (система массового обслуживания с отказами). Она имеет разработанную систему единой конфигурации проекта, что позволит осуществлять установку и настройку независимо от прораммной или аппаратной части сервера и клиентского устройства. Интерфейс системы разработан с помощью функционала библиотеки Tkinter, что позволяет создавать графические интерфейсы для приложений на Python. Система обработки заявок работает следующим образом:
Пользователь отправляет заявку через интерфейс системы.
Заявка попадает в очередь на обработку.
Система выбирает свободный обработчик и отправляет ему заявку на обработку.
Обработчик начинает обработку заявки.
Если обработчик не может обработать заявку, он отправляет ее на повторную обработку или отклоняет.
При успешной обработке заявки система отправляет уведомление пользователю. Таким образом, информационная система обработки заявок на Python3 является надежной и удобной в использовании. Она позволяет пользователям легко отправлять заявки и получать уведомления о статусе их обработки.
Большинство станций имеет возможность передавать все значения своих параметров одним пакетом. То есть при обращении к конкретной станции происходит создание файла в формате, аналогичном json. Он содержит несколько тысяч ключей, описывающих состояние данной ЭЗС, что сильно нагружает вычислительные мощности информационной системы.
В информационной системе будут рассматриваться два процесса генерации и обработки заявок с закрепленным для каждого клиента сервером и с динамическим выбором сервера. Оба процесса моделируют систему массового обслуживания с отказами, где заявки поступают в очередь на обработку и выбираются свободным обработчиком.
Однако в первом процессе каждый клиент закреплен за определенным сервером, а во втором процессе заявка распределяется на сервер с наименьшей загрузкой. В первом процессе клиенты генерируют заявки на обработку, которые поступают в очередь конкретного сервера, если у него есть свободное место. Если места нет, заявка отклоняется. Сервер выбирает заявку из очереди и начинает ее обработку. По завершении обработки заявка удаляется из очереди. Каждый клиент закреплен за определенным сервером, что может повлиять на загруженность определенных серверов и время ожидания заявок.
Во втором процессе заявки генерируются клиентами и распределяются на сервер с наименьшей загрузкой. Заявка поступает в очередь выбранного сервера и выбирается свободным обработчиком для обработки. По завершении обработки заявка удаляется из очереди. Этот процесс позволяет более равномерно распределить нагрузку на серверы и уменьшить время ожидания заявок. Оба процесса могут быть смоделированы для исследования различных параметров, таких как время ожидания заявок, загруженность серверов, количество отклоненных заявок и др. Это позволяет оптимизировать систему обработки заявок и улучшить ее эффективность.
Структура заявки может выглядеть следующим образом (рис. 5):
id (уникальный идентификатор заявки);
время_поступления (время, когда заявка поступила в систему);
тип_заявки (описание того, что нужно выполнить на сервере);
статус (текущий статус заявки, например «в очереди», «выполняется», «выполнена»);
id_сервера (идентификатор сервера, на который отправлена заявка);
время_обработки (время, которое затратил сервер на выполнение заявки);
Форма заявки не будет зависеть от того, на каком сервере она будет обрабатываться: закрепленным за клиентом или с динамическим выбором. Заявки будет удобно хранить в базе данных.
Структура базы данных может выглядеть следующим образом (рис. 6):
Таблица «Серверы»:
id (уникальный идентификатор сервера);
название (название сервера);
адрес (IP-адрес сервера);
время_обработки_заявки (время, необходимое серверу для обработки одной заявки);
текущая_загрузка (количество заявок, которые в данный момент обрабатывает сервер).
Таблица «Очереди»:
id (уникальный идентификатор очереди);
id_сервера (идентификатор сервера, к которому относится очередь);
время_ожидания (время, которое заявка проведет в очереди перед обработкой).
Таблицы, которые позволяют обработать заявку, – это данные по поступающим заявкам, обрабатываемым заявкам и статистике обработки заявок. Все эти таблицы имеют похожую структуру.
Таблица «Заявки на просмотр»:
id (уникальный идентификатор);
время_создания_заявки (будет использовано системное время);
время_задержки (будет использовано системное время между созданием заявки и попаданием ее на сервер);
время_ожидания (время, которое заявка проведет в очереди перед обработкой).
Таблица по обработке заявок, кроме представленных выше полей, будет содержать данные сервера, на который поступила обрабатываемая заявка, время поступления в очередь обработки и время обработки заявки.
Для получения статистики будет добавлено время завершения обработки заявки. При поступлении новой заявки необходимо выбрать сервер с минимальным временем обработки существующей очереди, который готов принимать новую заявку.
Для этого можно использовать следующий алгоритм:
Получить список всех серверов из таблицы «Серверы».
Для каждого сервера вычислить время, необходимое для обработки всех заявок в его очереди (текущая_загрузка * время_обработки_заявки).
Отфильтровать список серверов, оставив только те, у которых время обработки очереди меньше или равно времени ожидания новой заявки.
Отсортировать отфильтрованный список по возрастанию времени обработки очереди.
Выбрать первый сервер из отсортированного списка и отправить на него новую заявку. При обработке заявок необходимо также обновлять информацию о текущей загрузке серверов в таблице «Серверы». Реализация описанного выше алгоритма на языке Python представлена на рис. 7. Такая распределенная система будет позволять эффективно обрабатывать данные даже при высокой нагрузке на серверы, что необходимо для объекта критической инфраструктуры. Важно понимать, что ЭЗС является объектом критической инфраструктуры, поэтому ее работа должна быть обеспечена в режиме 24/7. Также необходимо организовать стабильное и устойчивое взаимодействие клиента с сервером посредством некоторого приложения или web-интерфейса. При этом разрабатываемая информационная система должна иметь платежный модуль (Celery) и электрическую балансировку (EnelX).
В соответствии с особенностями работы ЭЗС: увеличенной генерации трафика из-за постоянных проверок ее состояния, систему можно назвать высоконагруженной [5].
Более того, такую информационную систему следует сделать многомодульной. Это даст возможность перехода на более мощный сервер, позволит добавлять память и расширять интернет-каналы без потерь работоспособности системы.
Информационная система [6], построенная на основе макро- и микросервисов, представляет собой комплексное решение, которое позволяет обеспечить эффективное функционирование различных бизнес-процессов в организации. Макросервисы [7] – это крупные модули системы, которые выполняют функции, связанные с обработкой больших объемов данных, управлением процессами и взаимодействием с другими сервисами. Они обеспечивают высокую производительность и масштабируемость системы, а также позволяют управлять ее целостностью и безопасностью. Микро-сервисы – это небольшие модули системы, которые выполняют узкоспециализированные функции. Они могут быть разработаны независимо друг от друга и могут работать на разных платформах. Микросервисы позволяют быстро внедрять новые функции и изменения в систему, а также легко масштабировать ее при необходимости. Информационная система на базе макро- и микросервисов может включать в себя следующие функции:
управление бизнес-процессами – система может автоматизировать различные бизнес-процессы, такие как управление заказами, инвентаризация, управление производственными процессами и т. д.;
управление данными – система может обеспечивать хранение, обработку и анализ больших объемов данных, а также их интеграцию с другими системами;
управление взаимодействием с клиентами – система может обеспечивать управление отношениями с клиентами, автоматизировать процессы продаж и маркетинга, а также обеспечивать высокий уровень обслуживания клиентов;
управление ресурсами – система может обеспечивать управление ресурсами организации, такими как финансы, персонал, оборудование и т. д.;
управление безопасностью – система может обеспечивать высокий уровень безопасности данных и процессов в организации;
управление инфраструктурой – система может обеспечивать управление инфраструктурой организации, такой как сети, серверы, хранилища данных и т. д.
Таким образом, информационная система на базе макро- и микросервисов обеспечивает эффективное управление бизнес-процессами в организации, обеспечивая высокую производительность, масштабируемость, безопасность и гибкость системы.
Микросервисная архитектура позволяет это реализовать, однако она требует постоянного мониторинга изменений в конфигурационных метаданных программных систем, а также управления такими изменениями и инфраструктурой.
Микросервисная архитектура относится к распределенным системам. Согласно определению, распределенная система [8] – набор компьютерных программ, которые используют вычислительные ресурсы нескольких отдельных вычислительных узлов для достижения общей цели. Распределенные системы помогают повысить надежность и производительность и упрощают масштабирование системы. В случае большой нагрузки на систему можно добавить дополнительные узлы, которые могут организовать многопоточность обработки данных [9]. Управление конфигурацией помогает техническим командам создавать стабильные и надежные системы с помощью инструментов, которые автоматически управляют обновлениями конфигурационных данных и отслеживают их, что позволяет синхронизировать работу программного обеспечения в рамках микросервисной архитектуры, поскольку в центре конфигурации появляется достоверный источник информации. В готовую высоконагруженную систему мониторинг встроить нельзя, поэтому разработка системы должна иметь возможность встраивания датчиков мониторинга [10].
В процессе изучения особенностей отрасли ЭЗС стало ясно, что в большинстве структур имеются относительно большие приложения, которые нужно выносить на отдельные вычислительные мощности (рис. 8).
На рис. 7 показан пример разделения системы на отдельные макросервисы [11], такие как билинг, каждый из которых имеет свой набор микросервисов [12].
Микросервисное приложение для обслуживания и заправки электромобилей будет иметь следующие функции:
Синхронизация с мобильным приложением для клиентов: пользователи смогут использовать мобильное приложение для поиска ближайшей станции заправки, резервирования зарядного устройства и оплаты услуг.
Система оплаты: будет реализована платежная система, которая будет взаимодействовать с банком и обрабатывать платежи от клиентов.
Система мониторинга: будут установлены видеокамеры, которые будут следить за работой станции заправки и обеспечивать безопасность пользователей. Система мониторинга будет напрямую зависеть от видеокамер, поэтому ее можно изменять без влияния на работу клиент-серверной части.
Web-интерфейс: будет разработан web-интерфейс для управления станцией заправки, проверки работы устройств и их актуального состояния.
Система билинга: будет реализована система билинга, которая будет отвечать за проверку работы устройств и их актуального состояния.
Мобильное приложение под ios или Android: будет разработано мобильное приложение для клиентов с возможностью дальнейшей модификации.
Межсетевой экран: система макро- и микросервисов будет отделена от основной системы межсетевым экраном для предотвращения утечки пользовательских данных и изоляции работы основной части информационной системы.
Распределенная система обработки информации: для обеспечения стабильной работы системы клиент-серверной части при высокой нагрузке будет добавлена подсистема загрузки сервера и реализована как распределенная система обработки информации.
Система управления электрозаправкой будет следить за зарядными устройствами и автоматически управлять процессом зарядки электромобилей.
Система управления запасами будет следить за наличием необходимых материалов и запчастей для обслуживания станции заправки.
Система управления персоналом будет следить за работой сотрудников и обеспечивать эффективную работу станции заправки.
Система мониторинга качества необходима для отслеживания качества обслуживания клиентов и работы станции заправки в целом.
Система управления энергопотреблением будет оптимизировать потребление энергии и снижать затраты на электроэнергию.
Система управления техническим обслуживанием будет отслеживать состояние оборудования и проводить регулярное техническое обслуживание станции заправки.
Система управления аварийными ситуациями нужна для быстрого реагирования на возможные аварии и обеспечение безопасности пользователей.
Микросервисное приложение для обслуживания и заправки электромобилей будет синхронизировано с мобильным приложением для клиентов и системой оплаты. Они будут отделены от основной системы межсетевым экраном (fierwall) для предотвращения утечки пользовательских данных и изоляции работы основной части информационной системы, которая будет включать в себя систему мониторинга с камер, установленных рядом с ЭЗС.
В основной части также будут находиться web-интерфейс, система билинга, отвечающая за проверку работы устройств, а также их актуального состояния. К основной части также будет относиться платежная система, взаимодействующая с банком. Данные части информационной системы удобно реализовывать как микросервисы, поскольку они могут быть дополнены или изменены. Например, можно реализовать мобильное приложение под ios или Android с возможностью дальнейшей модификации, которая не будет существенно влиять на систему клиент-сервер, обрабатывающую запросы.
Система мониторинга может быть изменена, поскольку она будет напрямую зависеть от видеокамер. Устаревшая система наблюдения может быть заменена на новую, также без влияния на работу клиент-серверной части, содержащей базу данных. Клиент-серверную часть будет удобно разрабатывать как монолитную систему, которая должна стабильно работать даже при высокой нагрузке, поэтому необходимо добавить подсистему загрузки сервера и реализовать ее как распределенную систему обработки информации.
Таким образом, сформулированные технические требования показывают, что разрабатываемая информационная система по обеспечению работы ЭЗС будет учитывать особенности зарядных станций, их возможное удаленное расположение и доступность системы 24/7. Разрабатываемая система будет иметь гибридную архитектуру: Клиент-серверная часть будет реализована как монолитная структура, с возможностью подключения дополнительных серверов и распределения нагрузки на них. Остальные модули будут реализованы как микросервисы, что позволит расширить возможности системы в целом, подключая новые функции и модифицируя оборудование или приложения, не влияя на работу всей системы.
Литература
[1] Electrek. URL: https://electrek.co/2021/10/22/electric-vehicle-ev-charging-standards-and-how-they-differ (дата обращения 20 мая 2023).
[2] Dazetech. URL: https://www.dazetech.ology.com/charging-modes-for- ev/.Electric Vehicle Mode (дата обращения 20 мая 2023).
[3] Dalroad. URL: https://www.dalroad.com/resources/an-introduction- to-electric-vehicle-rapid-charging-standards (дата обращения 20 мая 2023).
[4] Leijon J., Boström C. Charging Electric Vehicles Today and in the Future // World Electr. Veh. J. 2022, 13 (8), 139. URL: https://www.mdpi.com/2032-6653/13/8/139/htm (дата обращения 20 мая 2023).
[5] Michaelson P., Holmberg D., Aasa B., Aasa U. High load lifting exercise and low load motor control exercises as interventions for patients with mechanical low back pain: A randomized controlled trial with 24-month followup // Journal of rehabilitation medicine: official journal of the UEMS European Board of Physical and Rehabilitation Medicine. 2016. Vol. 48 (5). URL: https:// www.researchgate.net/publication/301563842_High_load_lifting_exercise_ nd_low_load_motor_control_exercises_as_interventions_for_patients_with_ mechanical_low_back_pain_A_randomized_controlled_trial_with_24- month_followup (дата обращения 20 мая 2023).
[6] Rad B.B., Bhatti H.J., Ahmadi M. An Introduction to Docker and Analysis of its Performance // IJCSNS International Journal of Computer Science and Network Security. 2017. Vol. 17, no. 3. March. URL: https://www.researchgate.net/publication/318816158_An_Introduction_to_Docker_and_Analysis_of_its_Performance (дата обращения 20 мая 2023).
[7] Rad B.B., Bhatti H.J., Ahmadi M. An Introduction to Docker and Analysis of its Performance.
8 Rad B.B., Bhatti H.J., Ahmadi M. An Introduction to Docker and Analysis of its Performance.
9 Op. cit.
[10] Configuration Best Practices // The Kubernetes Authors. URL: https:// kubernetes.io/docs/concepts/configuration/overview/ (дата обращения 20 мая 2023).
[11] Fan Wei, Qian Zhang. Research on the Application of Microservice Architecture in Administrative Law Enforcement Supervision System // Journal of Physics: Conf. Series. 2019. Vol. 1237. P. 022055. URL: https://iopscience. iop.org/article/10.1088/17426596/1237/2/022055/pdf (дата обращения 20 мая 2023).
[12] Lewis J., Fowler M. Microservices a definition of this new architectural term. 2014. 25 March. URL: https://netman.aiops.org/~peidan/ANM2022/7. TraceAnomalyDetection/LectureCoverage/Microservices.pdf (дата обращения 20 мая 2023).
Информация об авторах
Марина С. Шаповалова, кандидат педагогических наук, доцент, Московский государственный технический университет им. Н.Э. Баумана, Москва, Россия; 105005, Россия, Москва, 2-я Бауманская ул., д. 5, стр. 1, mshapovalova84@gmail.com
Александр А. Андреев, магистр, Московский государственный технический университет им. Н.Э. Баумана, Москва, Россия; 105005, Россия, Москва, 2-я Бауманская ул., д. 5, стр. 1, andreev@indry.tech
Валерия В. Чувашова, магистр, Московский государственный технический университет им. Н.Э. Баумана, Москва, Россия; 105005, Россия, Москва, 2-я Бауманская ул., д. 5, стр. 1, chuvashova@indry.tech
