Что мы имеем на данный период времени в мире ГА? Известный факт: каждая из крупных IT-компаний имеет свой инструмент для работы с умными домами. И каждый вендор предоставляет свой API для заинтересованных в интеграции. А на начальном этапе даже доплачивает разработчикам за новые навыки (actions, skills и т. д. — в соответствии с терминологией вендора).

Самый удобный и практичный на сегодняшний день сервис, по оценкам наших специалистов, это Amazon Alexa. У неё больше возможностей для детального формирования навыка, нежели у Google Assistant, Yandex «Алиса», Mail.Ru «Маруся», Тинькоф «Олег» и других. Для Alexa прибор – это параметрическая виртуальная сущность, вследствие чего навыки могут настраиваться под каждый прибор индивидуально. Например, помимо температуры воды, можно задать расходники, которые ассистент будет предлагать купить на Амазоне. Но, к большому сожалению, в настоящее время Alexa не поддерживает русский язык и не работает на территории РФ, поэтому для российского пользователя этот ГА бесполезен. У Google и «Яндекса» ассистент более «естественный» – получает и отвечает на команды «человеческим» языком, может вести диалог с пользователем, что делает этот ГА более приятным для использования. Единственным серьёзным минусом Google было то, что его Actions не поддерживали русский язык. Однако с 24.07.2019 Google Actions работают в «телефонах» на русском языке, так что этот недостаток коллегами устранен.

Это всё ладно. А если мы захотим интегрировать один прибор с несколькими ГА?

Это можно. С помощью девайса.

Девайс – это сущность со своим поведением в системе. Это общий принцип для всех вендоров. И вот тут стоит остановиться, здесь начинается всё самое интересное. Различия — в подходах. Например, Google и Яндекс стараются стандартизировать управление техникой. То есть теперь придётся писать код не для каждого отдельного прибора, а хватит одной программы для всей серии. И даже если изменится прошивка, придется изменить код один раз, что весьма удобно. Наша компания уже имеет интеграцию с Google, Yandex, Amazon. Техника слушается Алису, Алексу и ассистента Google. Ранее мы показывали, что внутри голосовых ассистентов.

Откуда взялись голосовые помощники?

Одна из самых продвинутых систем распознавания речи в мире принадлежит Google, ее история началась ещё в 2002 году. Компания выпустила Voice Search, на основе которого и был разработан Google Assistant. В 2016 был он представлен на презентации Google I/O. Google Home это одна из 'surface' для Google Assistant. Сейчас точность распознавания речи их ГА оценивается в 95% и почти не уступает людям.

Голосовой помощник Alexa был представлен компанией Amazon в 2014. Там же была представлена и и умная колонка Amazon Echo, которая умеет управлять большим количеством устройств в рамках «умного дома».

Yandex SpeechKit – система распознавания речи у Яндекса. Она используется в 400+ приложениях. Также компания внедряет свой ГА – Алису – в браузеры и электронные устройства. Свой ГА российская компания представила в 2017, а уже осенью 2018 года Яндекс выпустил в продажу свою умную колонку «Яндекс.Станция».

Наши специалисты говорят, что к сто пятьдесят шестому году...

Шутки шутим, поэтому пока лишь к 2020 году. Немного о статистике:

1. В 2017 году зарегистрировано около 33 миллионов устройств с голосовым управлением по всему миру;
2. Западные эксперты назвали голосовой поиск одним из топ-3 трендов SEO в 2017 году;
3. На 2018 год «Google Ассистент» работает на 400 миллионах устройств по всему миру. И эта цифра только растёт;
4. По данным Global Web Index, 25% людей в возрасте от 16 до 24 лет используют голосовой поиск с мобильных устройств;
5. По прогнозам компании Comscore, к 2020 году 50% запросов будет производиться голосом;
6. Согласно исследованиям WalkerSands за 2018 год, каждый пятый пользователь умной колонки от Amazon покупал с ее помощью, а треть планировала сделать это в следующем году;
7. Согласно исследованию PWC, 71% пользователей при поиске в сети предпочли бы набирать текст голосам, а не вручную.

Как можно понять, тенденция использования ГА увеличивается, что говорит о том, что самое время брать вендор и запускать собственного помощника. Для нас ключевое в нём – это навык управления умными устройствами, что будет отличать SkyFriend от других ассистентов.

А давайте интегрироваться!

НО также наша задача – работать с имеющимся подходом вендора и далее адаптировать его под наш специфичный протокол управления техникой. Мы идём по пути стандартизации, практического применения, воспринимая устройство как набор навыков: каждый чайник умеет кипятить воду (навык), также он умеет нагревать её до нужной температуры (навык), поддерживать эту температуру на протяжении заданного времени и т. п. Например, команда «On/Off» – стандартная для любого прибора. Задача – перевести эту команду от сервиса под наш протокол. В чём особенность нашего протокола? Он связывает разных голосовых ассистентов (сейчас три, в перспективе — всех крупных) и позволяет им всем работать с приборами, в том числе одновременно. Связь – один ко многим. Вопрос состоит лишь в том, как именно мы будем адаптировать наш протокол ко всем подходам?

Посмотрим. Отдельные проекты под каждый ГА – это:

• Увеличенный штат сотрудников;
• Много кода и legacy в будущем;
• Невозможность масштабирования.

При появлении на рынке новых ассистентов придется пропорционально увеличивать штат и объёмы работ. Логично, что от такого варианта мы отказались. Однако, несмотря на различные подходы для каждого голосового ассистента, у них можно найти общее – то, с чем они в принципе работают – skill, trait, навык. Названия разные, но суть одна и та же. Значит, задача разработать свой «навык», который будет восприниматься ассистентами. В дальнейшем нужно будет только добавлять новых вендоров, что решает вопрос масштабирования. Также будем держать в уме, что значительное количество нашей техники использует BLE транспорт, что диктует архитектурные особенности.

Мы разработали два микросервиса, работающих в паре.



Первый – командный слой. Его задача: провести конвертацию (маппинг) между API вендора и нашим протоколом. Он работает так: специфический запрос ассистента – маппинг под наш навык – маппинг под протокол устройства. При таком подходе легко добавлять новые навыки: производится маппинг под конечный протокол R4S – код передается во второй сервис. Последний пункт может быть исключен при передаче команды по Wi-Fi.

Второй сервис или транспортный слой служит для:

1. Установления сессии с клиентским гейтвеем;
2. Поднятия и поддержания Bluetooth-соединения;
3. Приёма/передачи команд от первого сервиса.

Этот сервис – часть более высокоуровневой сущности: BT-девайс плюс gateway-посредник, работающие по принципу: приём команд через интернет – передача по BT. Беспроводные соединения могут быть ненадёжными. Почему? Радиоканал может быть ограничен параметрами среды — толстыми бетонными стенами и др… Как итог, приборы элементарно могут «отвалиться», поэтому поддержание стабильного соединения становится важной задачей для транспортного слоя.



Политика соединения может быть разной:

1. Постоянная поддержка связи.

Плюсы: минимальная задержка выполнения команд ГА.
Минусы: дорого по трафику и энергопотреблению; существует ограничение по количеству одновременно подключённых устройств (в данном поколении Bluetooth 4.0/4.2 – шесть, в Bluetooth 5.0 до двадцати). Также это потребует дополнительных серверных ресурсов.

2. Подключение по требованию.

Плюсы: подключение почти не требует трафика и заряда.
Минусы: высокая задержка выполнения команд плюс само выполнение не гарантировано (соединение может «отвалиться» или быть неуспешным). При таком подходе мы не укладываемся во время ожидания ГА на ответ. Сессия закончилась и the end.

Так же остается вопрос – команда получена и отработана, НО что делать с соединением дальше: отключаться или держать дальше. Обратим внимание на то, что ровно таким же способом работает Apple HomeKit при работе с BLE оконечными приборами (через Apple TV или iPad в качестве гейтвея). Выглядит это так – при первой попытке отправить команду процесс занимает довольно продолжительное время (или лучше сказать – заметное для пользователя), однако последующие команды выполняются почти мгновенно. После окончания работы пользователя с прибором операционная система «кладёт» сессию через некоторое разумное время и далее процесс повторяется как новый.

Однако, это ещё не всё.

Сложность 1. Маршрутизация Gateway.



Если в помещении несколько гейтвеев, то встаёт вопрос – к какому из них подключаться, и какой гейтвей к какому прибору подключается. Сейчас всё работает по принципу – кто успел, тот и подключился. Не всегда удачная имплементация, поскольку ближайший (а значит способный более надёжно подключиться) гейтвей может быть занят в используемом таймслоте. Тогда подключается тот, кто свободен и способен. Это происходит без оглядки на качество связи. Поэтому важно выстроить иерархию и схему работы, чтобы пользователю было максимально удобно.

Сложность 2. Множество пользователей.

Это ситуация, когда одним гейтвеем или устройством могут пользоваться одновременно несколько пользователей. Разумеется с обеспечением высокого уровня безопасности. Например, с разных ГА или с ГА и телефонов пользователя. Рой вопросов: какой прибор включить первым, если команды ГА противоречат друг другу, какая команда в приоритете и должна быть выполнена раньше и т. п. Частично нашу проблему решает сервис Redis – база данных, в которой хранятся сессии пользователей, состояния девайсов и осуществляется приемопередача команд и выступающая шиной передачи данных между первым и вторым сервисами. Но на этом пока решение проблемы останавливается.

Что сделали мы? Мы сделали SkyFriend. Это наша собственная разработка, голосовой помощник по управлению техникой, который также будет поддерживать русский язык. Ключевая особенность нашего ГА заключается в том, что он заточен на непосредственное взаимодействие с умной техникой Ready for Sky без дополнительных приборов. Прибор два в одном — ассистент совмещен с гейтвеем, который будет получать информацию либо через команды, которые пользователь передаёт со своего смартфона, либо непосредственно голосом. Плюс SkyFriend имеет дополнительные функции, которые позволят ему конкурировать с теми, которые уже существуют. Он умеет по запросу включать напоминания, может определять геолокацию пользователя, искать информацию в Wikipedia, рекомендовать фильмы, произносить тосты, читать новости, отвечать на вопросы, сообщать время и погоду в любом городе мира, играть с пользователем в «Загадки» и «Города», шутить шутки. Покупка билетов и заказ такси пока находятся на стадии альфа-теста. И это ещё только часть функционала.

Совсем недавно Google анонсировали работу своей колонки на похожей архитектуре — исполнительный скрипт загружается непосредственно в колонку Google Home. Выигрыш на стороне пользователя состоит в снижении времени на исполнение команд. Не нужно отправлять её на сервер производителя техники, она с сервера Google по тому же каналу связи летит прямо на колонку и там исполняется.

Однако, Google всё ещё не поддерживает другие транспорты — Bluetooth, ZigBe, Z-Wave, RF и т.д. непосредственно на колонке, а SkyFriend поддерживает Bluetooth 5.0.

Что нам ещё осталось? Работа с ресурсами системы — добавить памяти, мощности процессора и т.д. И мы готовы предложить пользователям новое качество ГА.

Что можем сказать в заключении?

ГА – это тренд, это удобно, это практично. Тема новая, комплексная, в ней есть множество вопросов, которые пока сложно решить. Тем более в одиночку. Поэтому приглашаем к дискуссии.

Что будет дальше? А дальше будет наша новая статья об архитектуре SkyFriend. Всё расскажем и покажем. Но потом.

P. S. Предложения и отзывы можно оставить в комментариях.