Alljoyn: взгляд embedded разработчика. Часть 1: знакомство

Не сочтите за расовые предрассудки, но в сегодняшней статье понятие «embedded разработка» будет означать разработку и программирование устройств на микроконтроллерах с использованием языка Си, безо всяких процессоров, Linux'ов, Windows'ов, Pyton'ов и прочего «не хардкора». Я намеренно сделал эту оговорку в самом начале, чтобы не пришлось постоянно акцентировать внимание на этом в дальнейшем.

Alljoyn — это протокол взаимодействия между устройствами разрабатываемый альянсом Allseen. В отличии от распространенных ныне протоколов промавтоматики (ModBus, KNX, BacNET и пр.) Alljoyn изначально рассчитан на применение в бытовых устройствах, т.е. тот самый пресловутый Интернет вещей. Причем Alljoyn претендует на статус глобального мирового стандарта и если взглянуть на список комнаний-участников альянса, вполне можно допустить, что его амбиции не безосновательны.
Сегодня мы попытаемся заглянуть за ширму маркетинговых заявлений об «универсальности, кросплатформенности и простоте использования» и понять что же за зверя пытается изобрести группа самых известных IT компаний со всего мира.

Итак, Alljoyn — это фреймворк с открытыми исходными кодами и документацией. Его идея изначально зародилась в компании Qualcomm и со временем переросла в крупный альянс. Физическим транспортом, в теории может служить любая среда передачи данных, при условии, что в качестве транспорта используется стек TCP/IPv4 или TCP/IPv6. Но в реальности, на данный момент используются только локальные сети (ethernet и Wi-Fi). Заявлена поддержка всех основных платформ: Linux, Windows, IOS, Android, а так же возможность портирования на микроконтроллеры.

Разработчиков железа такой подход привлекает тем, что в теории им не нужно заниматься написанием приложений под телефоны и компьютеры для управления исполнительными устройствами — железячник делает устройство и пишет для него прошивку, а различные красивые приложения для айфончика рисуют специально обученные люди. Многие скажут, что подобные попытки создать стандартизированный протокол уже принимались неоднократно, мне лично тут же вспоминается непростая судьба ZigBee. Тут можно только ждать и надеяться, что на этот раз всё удастся.

Топология

Эту картинку можно часто увидеть, когда речь заходит об Alljoyn, и она действительно важна для понимания принципа взаимодействия между устройствами. Как видно есть два базовых блока:

• APP — блок, реализующий бизнес-логику. Это может быть физическое устройство (такое как лампочка, кондиционер или телевизор), предоставляющее свои интерфейсы управления в Alljoyn шину. Так же это может быть приложение на смартфоне или компьютерная программа, которая преобразовывает Alljoyn-интерфейсы в визуальные интерфейсы пользователя (проще говоря, это приложение на телефоне, с помощью которого мы управляем Alljoyn-устройствами). Причем, APP никогда не взаимодействуют друг с другом напрямую, это взаимодействие всегда происходит через Router.
• Router — блок, реализующий взаимодействие между APPs и шиной Alljoyn. Может находиться как одном физическом устройстве с APP, так и на различных.

Теперь постепенно подбираемся к Embedded части. Есть 2 варианта исполнения фреймворка:

• Standard Core — вариант предназначенный для использования в устройствах с операционными системами (смартфоны, компьютеры, телевизоры и пр.)
• Thin Core — версия фреймворка на «чистом» Си для применения во встраиваемых приложениях (а именно в микроконтроллерах).

В рамках данного цикла нас в основном будет интересовать облегченная версия Thin. Так вот в состав Thin-устройства никогда не входит Router. Самым простым примером такого Thin-устройства является «умная лампочка» с Wi-Fi. и реализованным в ней протоколом AllJoyn.
Таким образом, для того чтобы управлять нашей «лампочкой» в сети должен быть хотя бы один роутер, а так как в «лампочке», в соответствии с идеологией AllJoyn, он находиться не может, выходит, что должно существовать отдельное физическое устройство, в котором реализован блок Router. Внимательный читатель, возразит: пусть Router (раз уж это просто отдельный процесс в операционке) будет находиться в телефоне, с которого мы запускаем приложение для управления «лампочкой». Да, в частном случае такой вариант будет работать. Но только в частном.
Во-первых, в телефоне может оказаться «неправильный» Router, который делает «неправильный мёд» и предоставляет услуги роутинга только для APP, находящихся внутри телефона.

На рисунке слева «правильный» Router получает презентационные данные от всех APP вокруг, включая 2 «лампочки» и начинает их презентовать в окружающую сеть и внутрь себя. В результате получаем возможность управлять «лампочками».
На рисунке справа, Router отказывается презентовать «лампочки», он, по задумке разработчика, служит лишь для вывода «наружу» своих блоков APP. Подчеркну, что термин «неправильный» не подразумевает неверное функционирование (разработчик намеренно не наделяет Router подобными функциями), а лишь показывает невозможность непосредственной работы с «лампочками».

Про Windows 10 и AllJoyn

Microsoft является одним из главных членов Альянса и судя по всему делает определенную ставку на AllJoyn. Так, тут на хабре уже была статья по этому поводу. Цитата из указанной статьи:

в Windows 10 включена полная поддержка данного протокола, а именно:
Во-первых, вам не нужно заботиться об AllJoyn-роутере, описанном выше, так как Windows 10 включает специальный сервис AllJoyn Router Service, который может использоваться как вашими приложениями, так и другими устройствами в сети.

К сожалению, в Windows как раз тот самый «неправильный» Router. Он решает главную поставленную перед ним задачу — убрать необходимость написания блока Router в своих приложениях, но не выполняет маршрутизацию сторонних Thin устройств.

Теперь мы можем представить структуру сети, при которой мы получим работающую систему в любом случае, следующим образом:

Т.е. в сети должно находиться некое, всегда включенное устройство, с запущенным на нем блоком Router. И с этим в текущей реализации фреймворка придется жить. В принципе, на практике это не должно быть какой-то серьезной проблемой — Router, как отдельный сервис, можно запускать на физическом роутере или на какой-нибудь RPi.

Общие принципы взаимодействия в сети

Каждое AllJoyn устройство обладает некоторым набором интерфейсов. Это может быть один из базовых наборов, несколько базовых наборов, это может быть фиксированный набор одного из профилей или собственные интерфейсы, которые необходимы именно этому устройству.
Каждое устройство умеет объявлять о своих интерфейсах в сети (это происходит автоматически). Если другое устройство «заинтересовалось» одним из объявленных интерфейсов, то оно «спрашивает подробности».
Кроме интерфейсов каждое устройство может генерировать события и выполнять действия, инициированные другими устройствами по сети.
Технически самое первое объявление о себе в сеть выполняется одним из трех способов:

• Broadcast сообщения в порт 9956 (устаревший способ, использовавшийся в ранних версиях)
• Multicast сообщения AllJoyn (адрес 224.0.0.113, порт 9956)
• Multicast сообщения mDNS (адрес 224.0.0.251, порт 5353)

Допускается использовать как одного из способов, так и сразу несколько.
Внутри этих посылок запаковывается информация о TCP-соединении (IP-адрес и порт) по которому необходимо будет подключиться для последующего взаимодействия. Таким образом, UDP используется только для знакомства и обмена первичной информацией, а в последствии работа идет через TCP-сокет. Объявление «своих» интерфейсов происходит уже по TCP. Официально за AllJoyn зарегистрирован порт 9955 для TCP соединения, но данное правило не является обязательным, так как информация о реальном порте передается при «знакомстве». Однако, я рекомендую использовать именно 9955, так как в WireShark именно этот порт зарезервирован для AllJoyn, и WireShark парсит пакет и разбивает его на отдельные поля в очень удобной форме, что существенно упрощает жизнь на этапе отладки.

События и действия

События и действия – это базовый механизм, который облегчает взаимодействие между приложениями и устройствами alljoyn. Этот механизм позволяет приложениям и устройствам посылать события в сеть, которые будут видеть все остальные устройства сети. Похожим образом приложения и устройства могут «рассказывать» о действиях, которые они могут осуществлять по команде других устройств. Например, датчик движения может посылать событие, если кто-то проходит мимо, а лампочка выполнять по команде извне действие включения. Возможность обнаружения этих событий и действий, позволяет создавать приложение, которое включает свет при срабатывании датчика. Этот простой механизм обнаружения действий и событий позволяет приложениям создавать динамические реакции на события.
Самый простой пример этого механизма — обратная связь: у нас есть 1 лампочка и 2 телефона, которые ей управляют. С первого телефона выключаем лампочку, и на экране второго тут же видим что лампочка выключена.

Проект «Освещение»

Allseen альянс поддерживает и развивает свой протокол. Одним из способов развития являются «рабочие группы», в которых реализуются различные проекты, например, по профилям устройств.
Проект Освещение разрабатывает библиотеку сервисов освещения Lighting Service Framework (LSF), которая реализует открытый и общедоступный способ взаимодействия с устройствами освещения на базе AllJoyn вне зависимости от производителя. Этот проект позволяет производителям устройств освещения создавать устройства, которые могут взаимодействовать друг с другом и с другими устройствами сети AllJoyn, а разработчикам приложений предоставляется API для общения с устройствами освещения от любого производителя.

Особенности LSF включают в себя реализацию в виде открытого кода следующих возможностей:

• Управление состоянием отдельной лампы: включение/выключение, оттенком, насыщенностью, яркостью и температурой цвета
• Управление группами ламп, включая создание, присвоение имен, удаление групп и управление группой как будто это одна лампа
• Сохранение настроек освещения, называемое пресет, позволяя конкретному состоянию лампы быть сохраненным для будущего использования
• Применение эффектов, например, пульсации или перехода из одного состояния в другое в течение некоторого времени
• Создание сцен освещения, включающих в себя отдельные лампы или группы ламп, и необходимые пресеты и эффекты, которые могут быть установлены для создания настроения и атмосферы

Именно на этот профиль мы обратим свой взор в следующей части цикла, когда займемся практической реализацией «умной» лампочки на связке микроконтроллера SAMD21 (Cortex M0) и Wi-Fi модуля WINC1500.

Что есть на данный момент

На сайте альянса есть страница Product Showcase, на которой публикуется список существующего оборудования. Насколько этот список полон и актуален можно только догадываться. Для глобального мирового стандарта, список весьма скромен, но все-таки альянс находится лишь в начале своего пути. Присутствуют тут и различные «умные» лампочки, розетки и т.п. Но если присмотреться к ним на сайтах производителей, то увидим, что AllJoyn реализован как альтернативный протокол в дополнение к своему проприетарному. Одна из причин этого — практически полное отсутствие реальных мобильных приложений для AllJoyn.

DashBoard 14.12. На момент написания данной статьи, по неведомым мне причинам, это приложение было удалено Play Маркета для Android. Приложение представляет собой панель управления для различных AllJoyn устройств.

LSF Sample App. Приложение для Android, реализующее панель управления для лампочек, поддерживающих профиль LSF. На данный момент его можно скачать только в виде apk-файла или исходных кодов с сайта альянса.

Luminaire. Приложение, имитирующее на экране телефона AllJoyn «умную» лампочку. Использует Thin вариант библиотеки. Отличная вещь для отладки, эта лампочка определяется предыдущим приложение (LSF) как реальная лампочка. К тому же в состав Luminaire включен «Правильный» Router, чьими услугами мы воспользуемся в последствии, когда будем делать «умную лампочку в железе».