Сергей Пупкевич, руководитель департамента Java-решений Qulix Systems, делится кейсом по разработке программного обеспечения для умных домов и честно рассказывает, в чем были основные сложности и как их удалось решить.
Все начинается с протокола
Не так давно наша компания завершила очередной этап проекта по разработке программной части системы «умный дом» для компании Nero Electronics. В работе над умным домом Nero нам пришлось работать сразу с двумя протоколами. Один – это общедоступный z-wave, а второй – собственная разработка Nero.
И второй момент очень интересен. Разработка «самописного» протокола связана с несколькими серьезными вызовами.
- Во-первых, его нужно постоянно поддерживать, то есть его доработка и улучшение не заканчиваются, что ведет к дополнительным затратам на команду и инфраструктуру.
- Во-вторых, нужна очень сильная инженерная команда. Например, для организации канала связи, на котором будут работать устройства, требуются очень сильные математики. Они должны помочь обеспечить защиту от помех. Ведь радиоэлектронный мир сейчас перенасыщен сигналами.
Есть ли альтернативы самописным протоколам?
Да. Это публичные протоколы Z-wave, ZigBee и Bluetooth LE. Они уже «из коробки» обеспечивают помехоустойчивость, приличный радиус действия, хорошо справляются с препятствиями типа стен. Их множество, но для умных домов подходят только протоколы с низким энергопотреблением.
При этом у Z-wave есть одна существенная проблема – это дорогие устройства (датчики, управляющие элементы и прочее), которые с ним совместимы. Их цена может быть в два-три раза выше, чем у устройств, работающих с другими протоколами. Как следствие, выбор Z-wave отсекает огромный пласт клиентов, которые не готовы платить за устройства большие деньги.
У ZigBee небольшими минусами является низкая скорость передачи данных (что допустимо для систем умного дома). Еще один недостаток заключается в том, что устройства ZigBee, выпущенные разными производителям, нередко оказываются несовместимы друг с другом.
В этом плане Bluetooth LE может показаться оптимальным решением, так как он обеспечивает хорошую дальность работы и низкое энергопотребление.
Но его существенным минусом является топология работы. Если устройства Z-wave и ZigBee могут сами ретранслировать сигнал от роутера, позволяя расширять сеть, то каждое Bluetooth-устройство должно взаимодействовать напрямую с роутером. И если в квартире еще можно построить сеть с прямой видимостью роутера, то в загородном доме дальности действия Bluetooth может не хватить.
Почему мы работали с самописным решением?
Когда мы только начинали работу, указанных протоколов или еще не было, или же они были «сырыми». Приходилось «отсекать» большой кусок потенциальных покупателей, выбирая Z-wave с его дорогими устройствами.
На данный момент разработка собственного протокола мне видится нецелесообразной. Уже есть из чего выбирать.
Две сложности в разработке умного дома
Для разработчика сложной частью является организация простой настройки умного дома. Наша задача – сделать так, чтобы систему мог установить обычный пользователь, не прибегая к помощи специалиста.
Обычно у пользователей возникают проблемы именно на этом этапе. Например, в решениях типа того, что предлагает Xiaomi, нужно «руками» объединять устройства в сеть – вручную находить и прописывать номера, настраивать все в интерфейсе и так далее.
Наш замысел состоял в том, чтобы система все делала автоматически. Причем сразу после того, как включается в розетку. В итоге процесс выглядит так: при первом включении управляющее устройство всего дома подключается к Wi-Fi, затем сканирует пространство вокруг себя, находит устройства умного дома (датчики, исполняющие устройства), включает их в сеть и настраивает. Мы даже предусмотрели систему идентификации по QR-кодам на тот случай, если кто-то вдруг боится, что сеть «прихватит» соседские устройства. Чтобы этого не произошло, достаточно лишь сфотографировать этот QR-код – и система распознает устройство.
Второй сложный момент – организация доступа к умным домам с мобильных устройств из других сетей. Например, из офиса или через мобильный интернет. Дело в том, что когда пользователь дома, обычно он находится в одной Wi-Fi сети с умным домом – тогда проблем нет. Но что делать, если доступ нужно получить удаленно?
Проблема могла бы решиться «белым» IP-адресом (то есть IP, под которым устройство всегда находится в сети), к которому всегда можно подключиться. Проблема в том, что таких адресов очень мало. Провайдеры не предоставляют их своим клиентам, выдавая постоянно меняющиеся. И здесь встает задача: как «связать» пользователя именно с его домом?
Решить такую проблему помогает технология WebRTC. Если вкратце описать суть ее работы, то она помогает пользователю и умному дому «находить» друг друга посредством «облачного посредника». Используя облачную инфраструктуру, мы смогли построить решение, которое знает обо всех подключенных умных домах.
Рабочий процесс выглядит так: когда к платформе подключается пользователь, то с его устройства поступает запрос: «А дай-ка мне такой-то дом». «Посредник» (это могут быть сервера Amazon или Google, например) ищет IP-адрес, который прямо сейчас присвоен умному дому, после чего соединяет обе стороны, давая доступ пользователю к его управлению.
О проблемах с видеонаблюдением
Видеонаблюдение – одна из важных функций в умном доме. Ее наличие само собой разумеется, но при разработке мы столкнулись с серьезной проблемой. И с этой проблемой, скорее всего, столкнется каждый, кто будет работать в этой индустрии.
Когда речь идет об управлении устройствами, входящими в умный дом, то для этого требуется очень небольшой объем трафика – килобайты (всего-то нужно пересылать команды). Проблемы начинаются тогда, когда мы работаем с видеонаблюдением и передачей видео.
Передача видео с одной Full HD-камеры способна потреблять примерно мегабит трафика в секунду. А теперь представим, что вы захотели посмотреть трансляцию из дома, сидя на работе. Как уже было сказано выше, напрямую подключиться к умному дому нельзя из-за динамического IP, так что в дело снова вступает «облачный посредник». И вот здесь возникает большая статья расходов – передача видеотрафика.
Представим, что в сети тысяча домов – это гигабит в секунду. Многие провайдеры не способны предоставить скорость выше 100 мегабит в секунду. Следовательно, мы упираемся в инфраструктурные ограничения. И это без учета тех затрат на трафик, которые понесет владелец дома.
В общем, задача с передачей видео до сих пор не решена в полной мере.
Служба поддержки и ведения логов
Важная часть работы над «умным домом» – это организация пользовательской поддержки. И здесь есть свои сложности: как понять, что делал клиент (или что произошло), перед тем как что-то пошло не так?
Перед нами встала задача организовать систему поддержки. Для этого мы разработали специальную систему логов, которая записывает все происходящее в системе, а затем отправляет информацию в «облако», откуда она перенаправляются на специальный сервер обработки. Там все данные структурируются.
В итоге мы построили систему таким образом, что специалист службы поддержки имеет доступ ко всем логам и данным в них за любую дату. Это нужно, чтобы можно было быстро выяснить, что происходило с системой до выхода из строя, какие ошибки в ней появились. Например, специалист увидит, что пропало интернет-соединение или не работает GSM-модуль. Имея эту информацию, он уже сможет посоветовать клиенту что-то конкретное вместо того, чтобы «вслепую» выдвигать гипотезы или просто гадать.
Разработка системы логирования оказалась довольно сложной. Ведь нам нужно было организовать все так, чтобы она умела обрабатывать записи с тысяч умных домов. Данные собираются из разных систем, поэтому их нужно структурировать, а это терабайты информации, которые сложно обрабатывать в онлайне.
Например, в одном доме есть GSM-модуль, устройства с LCD-дисплеями, система управления устройствами, связь мобильного клиента и сервера – это все разные системы. Например, если сломался GSM-модуль, то система потеряла возможность отправлять SMS-сообщения. В этом случае мы имеем дело уже с двумя записями в логах – поломка GSM-модуля и невозможность отправки сообщения. Службе поддержки же нужно собрать их все вместе, чтобы получить цельную картину состояния дел в доме и выявить причину проблемы.
В общем, задача оказалась сложной, но решить мы ее смогли с помощью стека Elasticsearch плюс Kibana. Логи хранятся в базе Elasticsearch, а просматриваются с помощью приложения Kibana, которое и выдает всю картину по дому.
О безопасности
Конечно, когда разрабатывается умный дом, то безопасности придается большое значение. Все-таки он управляет большим количеством критически важных вещей: видеонаблюдение, двери, свет… В чем опасность? Получив доступ к системе, злоумышленник, например, может открывать двери или ворота.
Важно не дать ему эту возможность. Но как это сделать, если все работает через интернет, а трафик вполне может быть перехвачен?
Мы моделировали много ситуаций и искали решения для них. Например, злоумышленник покупает идентичный клиентскому управляющий центр умного дома. По идее он может попытаться получить доступ к вашей системе, так как устройства идентичны и работают на одном протоколе. Эту задачу мы решили при помощи нанесения на устройства QR-кодов, которые нужно отсканировать смартфоном.
Проще говоря, даже купив такое же устройство, преступник не сможет подключиться к системе, не получив физического доступа к каждому из устройств умного дома. Следовательно, и управлять он ими не сможет.
Что касается возможности перехвата трафика, то здесь мы внедрили шифрование. Причем данные шифруются на всех этапах передачи: от устройства до умного дома, от умного дома до «облака» – все это защищенное соединение.
Кстати, один из наших аналитиков предположил, что если удастся каким-то образом украсть бэкап умного дома и «залить» его на новое управляющее устройство, то можно будет получить доступ к нему. В итоге и эту возможность мы закрыли: для восстановления из бэкапа нужно будет вводить логин и пароль суперадминистратора, а также знать секретное слово.
Если суперадминистратор забудет пароль, то сможет восстановить его по кодовому слову. Даже если нарушитель его узнает, то это ему ничем не поможет. Дело в том, что новый пароль приходит через SMS на телефон, который был указан при регистрации умного дома или на email суперадминистратора. Взломщик, даже зная кодовое слово, не сможет установить себе приложение и сменить пароль потому, что нужен еще доступ к номеру телефона или почте суперадминистратора. Следовательно, он ничем не сможет управлять.
В погоне за безопасностью не стоит забывать и об удобстве использования. Чтобы избавить пользователя от необходимости бесконечно вводить логины и пароли, мы создали привязку умного дома к ID телефона.
Разработанное нами приложение нельзя установить на смартфоне, который не защищен отпечатком пальца или пин-кодом. Следовательно, даже если злоумышленник украдет нужный смартфон, то ему придется узнать код от телефона, логин-пароль от системы. Маловероятно, что у него будет такой набор информации. Если же он у него есть, то владельцу стоит пересмотреть свое отношение к безопасности и хранению данных.
«Облака» и безопасность
Так как многие сервисы завязаны на «облаке», то отдельный блок вопросов безопасности возникает именно из-за опасений за его безопасность.
Учитывая этот факт, мы решили разместить в нем сугубо технические данные, которые ничем не будут полезны взломщикам. При этом никакой критически важной информации туда не передается. Что же у нас там хранится?
Прошивки. Прошивки локального сервера и устройств управления. Каждое устройство может «забрать» оттуда новую версию ПО и обновиться. Это системная информация, которая не несет пользы нарушителю.
Идентификаторы. Имея идентификатор и установив приложение, злоумышленник сможет разве что найти в сети умный дом, но подключиться к нему – нет, так как для этого потребуется знать пароль суперадминистратора.
Логи. Даже если взломщику каким-то образом удастся получить доступ к логам, то ему эта информация ничем не поможет. Во-первых, логины-пароли туда не передаются. Во-вторых, там содержатся сугубо технические данные. Например, когда в последний раз включался свет на кухне, какие устройства подключены к системе или как часто открывалась дверь. Учитывая тот факт, что информация в логах никак не персонализирована, то она будет бесполезной.
Инфраструктура
Самая большая сложность в разработке системы умного дома – поддерживать стабильность ее работы. Так или иначе, но все умные дома поддерживают связь с «облаком», которое помогает мобильным устройствам их находить. И если выйдет из строя мобильный «облачный» сервер, то они сразу одновременно потеряют доступ к ним (а клиенты – к домам).
Эту задачу мы решали путем разворачивания облачных серверов в кластере, оставив себе возможности для резервирования. Например, если из строя выходит один сервер, то система автоматически переключается на другой. Важно предусмотреть балансировку нагрузки на сервера. Ведь по мере роста количества домов она будет расти.
Например, один сервер не сможет обслужить более 40 тысяч умных домов: ему не хватает портов, чтобы подключить все. Это ограничения операционной системы, которая предусматривает всего около 60 тысяч портов, 20 тысяч из которых – служебные. Эти тонкости нужно учитывать.
Все это упирается в огромные затраты на инфраструктуру. Многие компании полагают, что можно сфокусироваться лишь на разработке умного дома, а для решения инфраструктурных вопросов достаточно будет «отделаться» облачным сервером Amazon, но это не так. Например, через Amazon нельзя пустить видео. Во-первых, сам провайдер ограничивает канал 10 мегабитами. Во-вторых, сервера далеко, а это значит, что видео может сильно замедлить скорость работы, что скажется на стабильности работы всей системы. Возможно, это неплохой вариант для тестирования, но точно не для полноценной эксплуатации.
В итоге мы все равно приходим к тому, что нужно разворачивать всю инфраструктуру в существующих дата-центрах, а то и создавать собственные, чтобы оптимизировать затраты. А в случае масштабирования на несколько стран желательно иметь свой дата-центр в каждой из них, а затем соединять их в единые региональные узлы. Так что масштабирование становится непростой задачей.
Материалы по теме:
Почему программирование должны учить не только программисты
22 полезных инструмента для начинающих кодеров
Нашли опечатку? Выделите текст и нажмите Ctrl + Enter
Материалы по теме
- 1 Программирование 2.0: как ИИ-ассистенты упрощают разработку
- 2 Как геймдев-стартапам сократить расходы и сроки за счет опенсорса
- 3 7 советов, которые помогут вендору грамотно организовать поддержку партнеров
- 4 Популярные технологии, документация и единый стиль кода. Что учесть при разработке MVP ИТ-проекта
- 5 Корпоративные коммуникации в 2024 году
ВОЗМОЖНОСТИ
23 апреля 2024
23 апреля 2024