science-review.ru
В области домашней автоматизации уже ведется большая работа – от энергоэффективных до полностью автоматизированных решений. Однако внедрение машинного обучения во взаимодействие пользователя с системой находится на начальном этапе, поэтому необходимо провести огромную работу по внедрению машинного обучения в автоматизированную систему.
Поэтому предлагаемая система состоит из последовательности модулей:
− мобильный модуль;
− домашний модуль;
− конечный пользователь;
− интеллектуальные устройства.
На рисунке 1 представлена архитектура высокоуровневой системы, в которой можно идентифицировать представление пользователя, мобильный модуль, модуль платформы автоматизации и интеллектуальные устройства, подключенные внутри дома.
Цель исследования: рассмотреть архитектуру и особенности системы управления «умным домом».
Мобильный модуль. Этот модуль служит точкой подключения пользователя ко всему рабочему процессу. Все взаимодействия будут происходить в приложении, установленном на мобильном устройстве, и действия, предпринятые внутри него, вызовут серию событий во всей системе.
Как показано на рисунке 2, мобильный компонент состоит из мобильного приложения и переобученной модели, интегрированной в приложение. Эта интеграция происходит в режиме реального времени, обеспечивая мгновенную обратную связь с пользователем, и поэтому, согласно сценарию, конкретные команды и действия будут отправляться по каналу связи, существующему между этим модулем и модулем домашней автоматизации. Оба компонента играют важную роль в быстродействии и полезности системы и описаны в следующих подразделах.
Мобильное приложение. Мобильное приложение будет установлено на пользовательском устройстве, и его основная роль заключается в сборе пользовательских взаимодействий, интерпретации собранных данных и установлении связи с платформой автоматизации.
С учетом простоты использования и доступности наиболее разумным выбором в данном контексте является приложение для Android. Разработка собственного приложения для iOS потребует специального оборудования и охватит меньшее сообщество пользователей, чем Android. Таким образом, при выборе операционной системы Android для разработок можно гарантировать, что большое количество устройств будет совместимо, можно будет охватить огромное количество пользователей, а процесс общения не будет ограничен возможностями программного обеспечения.
Кроме того, это приложение должно обеспечивать возможность установления связи между мобильным устройством и платформой домашней автоматизации. Для этого ему необходимо будет играть роль клиента в протоколе связи между ними, отправляя информацию на платформу. Поскольку Android поддерживает широкий спектр интеграций с коммуникационными плагинами и программным обеспечением, этот выбор гарантировал, что можно найти решение, близкое к оптимальному.
Рис. 1. Архитектура высокоуровневой системы
Рис. 2. Архитектура мобильного модуля
Датчики мобильного устройства. Основной целью предлагаемой интеграции является возможность использования датчиков мобильных устройств для интуитивного взаимодействия с интеллектуальными устройствами. Одним из основных и крупнейших сборщиков информации, который можно найти в каждом мобильном устройстве, является камера. Таким образом, чтобы воспользоваться всеми возможностями, необходимо найти способ интерпретации данных, собранных датчиком камеры.
Решением стало использование библиотеки машинного обучения, совместимой с предложенной архитектурой, способной загружать и обрабатывать данные, создавать, обучать и повторно использовать модели с простым развертыванием. Таким образом, решение, используемое в компоненте интерпретации, опирается на структуру тензорного потока [1] .
В дополнение к предоставлению возможности переобучения нейронной сети без использования сложного и мощного оборудования самым большим общим преимуществом этого инструмента является возможность запускать модели машинного обучения на мобильных устройствах в рамках сжатого и мобильного решения Tensor Flow Lite [2].
Использование машинного обучения на устройстве позволяет упростить архитектуру системы без необходимости выполнения последовательных вызовов сервера для оценки информации.
На рисунке 3 представлена архитектура решения – стек компонентов, участвующих в процессе. Кроме того, программные интерфейсы приложений Java и C++ отвечают за загрузку и вызов интерпретатора, который, в свою очередь, выполняет модель с использованием набора ядер. В версиях Android, превосходящих 8.1, поддерживается API нейронных сетей Android (NN API) [3], который позволяет эффективно распределять вычисления между процессорами устройств и использовать преимущества аппаратного ускорения с помощью аппаратного уровня абстракции нейронных сетей Android (NN HAL). Если ни один из них не доступен, будет задействован центральный процессор.
Домашний модуль. В нем находятся два основных компонента: брокер, отвечающий за связь модулей, и экземпляр домашней автоматизации, отвечающий за интеграцию интеллектуальных устройств и датчиков. Оба они размещены внутри одной и той же установочной платформы.
Одной из основных проблем, которые возникали, является установка брокера и платформы автоматизации на одно и то же оборудование, чтобы можно было избежать необходимости в дополнительном оборудовании. Следовательно, выбор всех трех компонентов был сделан с учетом необходимости того, чтобы каждый из них был совместим между собой.
Подходящим решением для интеграции обоих элементов является установка их внутри Raspberry Pi. Таким способом обеспечиваются снижение стоимости, простота установки и обслуживания, так как весь этот модуль основан на Raspberry Pi 3B + [4], где работают брокер MQTT и платформа автоматизации.
Рис. 3. Архитектура стека модели вывода
Брокер. Выбор MQTT [5] в качестве протокола связи привел к необходимости наличия брокера для управления всеми вызовами публикации и подписки и, следовательно, поддержания связи между задействованными элементами. Решением MQTT Broker можно управлять тремя различными способами: первый предполагает наличие публичного брокера, предоставляющего услуги, второй – частного брокера, а третий подразумевает использование встроенного брокера. Поскольку в публичном брокере любое устройство или организация могут публиковать и подписываться на любую тему на нем и у большинства платформ домашней автоматизации по умолчанию отсутствует брокер, самый безопасный и простой способ интегрировать этот узел в архитектуру – полагаться на частного брокера, где только устройства с предоставленным разрешением могут публиковать и подписываться на темы, управляемые этим брокером.
Для выполнения этой интеграции выбранным брокером MQTT был Mosquitto [6]. Как легкое решение с открытым исходным кодом, широко используемое для обмена сообщениями Интернета вещей и, кроме того, легко устанавливаемое на Raspberry Pi, Mosquitto предоставляет инструменты, необходимые для работы в качестве посредника связи.
На рисунке 4 представлено размещение брокера в архитектуре системы, принимающего запросы на подписку от платформы автоматизации и, соответственно, доставляющего туда сообщения при получении публикации данных с мобильного устройства, следовательно, устанавливающего соединение для передачи данных между ними.
Платформа автоматизации. Принимая во внимание предполагаемую интеграцию и учитывая выводы, сделанные ранее, можно заключить, что Home Assistant [7] является хорошим выбором для реализации, поскольку он проверяет все флажки: имеет открытый исходный код, разработан на хорошо известном легком в освоении языке, имеет сильное базовое сообщество пользователей и может быть установлен на устройстве с низкой вычислительной мощностью, таком как Raspberry Pi.
Установка состоит в экземпляре Home Assistant, размещенном в Raspberry Pi, изначально работающем в виртуальной среде Python поверх ОС Raspian. Как показано на рисунке 5, платформа также будет иметь подключенные к себе устройства «умного дома», способные отправлять команды, выполнять операции и изменять состояние в соответствии с информацией, отправленной пользователем с мобильного устройства и переданной через брокера. Таким образом, при определении желаемого решения и учитывая, что уже существовало, а также ограничения и возможности предлагаемой интеграции, процесс проектирования и разработки можно разделить на ряд этапов:
− разработка компонента машинного обучения и преобразование его в нужный формат;
− создание мобильного приложения, отвечающего за интеграцию модели в режиме реального времени;
− установка и настройка платформы автоматизации;
− внедрение коммуникационных процессов.
Эти четыре основных этапа разработки и внедрения системы являются ключом к успешной работе предлагаемого решения.
Связь модулей. MQTT представляется наиболее подходящим выбором в этом сценарии, предоставляя решение для обеспечения связи между двумя модулями, которое широко используется в средах Интернета вещей с низкой пропускной способностью, низкой задержкой и хорошей производительностью (рис. 6).
В контексте архитектуры системы и с учетом принципов MQTT один компонент будет выступать в качестве издателя, один – в качестве брокера, а третий – в качестве подписчика [8].
Рис. 4. Роль посредника в коммуникации в архитектуре системы
Рис. 5. Интеллектуальные устройства, подключенные к платформе домашней автоматизации
Рис. 6. Архитектура процесса коммуникации
Наиболее логичным способом реализации архитектуры протокола в этом сценарии является использование мобильного устройства абонентом, ответственным за публикацию данных в определенной теме, на которую подписана платформа автоматизации. Таким образом, мобильное устройство может постоянно публиковать обновления об изменениях состояния и взаимодействиях с пользователями, зная, что они будут получены на платформе автоматизации, прослушивающей данные в определенных подписанных темах.
В данной статье описана разработанная система. Она состоит из следующих модулей:
− мобильный модуль;
− домашний модуль;
− конечный пользователь;
− интеллектуальные устройства.
В разработанной системе пользователь может управлять устройствами, существующими в его доме, с помощью пользовательского интерфейса камеры, имеющего визуальное представление действий и обеспечивающего интуитивное взаимодействие.
Библиографическая ссылка
Засыпкин Д.С., Белов Ю.С. АРХИТЕКТУРА СИСТЕМЫ «УПРАВЛЕНИЯ УМНЫМ ДОМОМ» // Научное обозрение. Технические науки. 2022. № 2. С. 10-15;URL: https://science-engineering.ru/ru/article/view?id=1388 (дата обращения: 04.04.2025).
DOI: https://doi.org/10.17513/srts.1388