Концепция Physical web. Bluetooth маячки. Сравнение стандартов iBeacon, AltBeacon и Eddystone

image

Последние несколько лет я занимаюсь R&D в области интернета вещей и распределенных систем, а так же являюсь Google developer expert IoT. В этой статье я хочу поделиться своим опытом и рассказать про новую концепцию Physical Web. Так же расскажу про разные маячки (англ. Beacon — маяк) и сравню основные стандарты iBeacon, Altbeacon и Eddystone.

В интернете вещей одним из мегатрендов сейчас являются умные дома, а точнее устройства для дома. Недавно была статья на Geektimes с обзором прогнозов в области интернета вещей от разных компаний. А в конце уходящего 2015 года свой прогонз представили Vision Mobile.

У нас уже есть умные термостаты, весы, камеры, телевизоры, холодильники, датчики, замки и тд. С каждыми днём на рынке появляется всё больше и больше умных устройств от самых разных производителей, притом некоторые из них действительно хороши и полезны. Но как сегодня выглядит наше взаимодействие с такими устройствами, например, первоначальная настройка и мониторинг? В подавляющем большинстве случаев, у каждого производителя есть приложение, с помощью которого мы и можем взаимодействовать с его продуктами. На первый взгляд выглядит нормально, так ведь?

Но ведь умные устройства могут нас окружать не только дома. У многих из нас есть приложения для общественного транспорта, оплаты парковок, аренды автомобилей или велосипедов. Но если вы оказываетесь в другой стране по работе или в отпуске, вам скорей всего нужно будет установить еще несколько приложений.

Если мы верим в закон Мура, то маленькие, недорогие, подключенные устройства скоро ворвутся в нашу жизнь, наполняя наши дома, рабочие и общественные места. В настоящее время большинство умных устройств для интернета вещей требует установки специального приложения. Такое узкое решение просто не масштабируется до взаимодействия со всем множеством умных устройств. Я не имею ничего против приложений, приложения это здорово! Но их много и то взаимодействие, которое они нам предлагают не всегда удобно.

Концепция Physical Web


Physical Web — это попытка построить мост между цифровым и физическим миром, который позволяет нам расширить суперсилу web — URL — для повседневного использования. В своей основе, Physical Web является службой обнаружения: умный объект передает соответствующий URL-адрес, который могут принимать любые устройства поблизости, например ваш смартфон или планшет. Эта простая возможность транслировать обычный URL открывает новые, захватывающие способы взаимодействия.

Видео o Physical web от Scott Jenson. Рекомендую посмотреть.



Представьте, что вы можете легко взаимодействовать со всеми умными устройствами в вашем доме, без труда их настроить или получить диагностические данные. Подойдя к остановке вы можете узнать когда прибудет ближайший автобус, сев в него, вы узнаете информацию по маршруту, время до следующей остановки. В торговом центре вы узнаете об акциях и скидках. Подойдя к торговому автомату, вы сможете купить и получать товар, не уговаривая его принять ваши деньги и даже не прикасаясь к нему. Вы можете купить билет в музей или кино, а подойдя к постеру или предмету экспозиции получить о нем дополнительную информацию. Можно арендовать машину или велосипед, оплатить парковку, совершив меньше ненужных действий. Или занять очередь. Занять очередь, Карл! Мы же в России так любим очереди. Даже если вы окажетесь в другом городе, для вас ничего не изменится.

Всё это возможно без установки кучи ненужных приложений, вам понадобиться одно единственное приложение, для Android это — Physical Web Browser, а на iOS — данный функционал встроен в Google Chrome. Google Chrome с поддержкой Physical web для Android сейчас находится в стадии beta. Так же поддержку Physical Web в скором времени получит Opera c переходом на кодовую базу Chrome 49.

Physical Web является естественным решением, предлагающим взаимодействие по требованию без дополнительных усилий и накладных расходов в виде установки приложений. Это совершенно новый User eXperience, предлагающий взаимодействие по требованию, только тогда когда это действительно нужно пользователю. Вы просто нажимаете на ссылку и получаете то, что вам нужно. Никаких Push уведомлений, вибраций или чего то подобного.
Physical Web экономит силы, средства и время на разработку приложений, т.к. не нужно писать приложение под каждую платформу, достаточно сделать одно, адаптивное Web приложение.

Пример того как это выглядит:


Physical Web еще не готов до конца и не является продуктом Google. Это экспериментальный проект, находящийся на ранней стадии и разрабатываемый Google в открытом виде, как и все вещи, связанные с интернетом.

Устройство маячков


Как вы уже могли легко догадаться, источником так нужного нам URL являются маячки (англ. Beacon — маяк). Маячки представляют собой простейшее устройство, которое с заданной частотой транслирует какие-то данные, так называемый advertisement packet, с помощью технологии Bluetooth v4 или Bluetooth Low Eenergy(BLE).

Для тех, кто переживает за приватность: маячки принципиально не могут вас отслеживать, они умеет только транслировать сообщения и ничего о вас не знают. Им всё равно, один человек получает от них пакеты или 30.

Ниже, как пример, представлен маячок от компании Estimote в разобранном виде:


Производителей устройств сейчас достаточно, поэтому на рынке представлены самые различные реализации как по размеру, форм-фактору, так и по назначению. Есть, например, и промышленные реализации, способные работать на улице и питаться от постоянного источника энергии. Цены на готовые устройства также варьируются.

Далеко не полный пример разнообразия устройств:


Маячки, которые у меня есть в данный момент:


В чем же концептуальная разница между маячками, если не брать в расчет цену и исполнение? Разница заключается в формате транслируемых сообщений.

Сейчас есть три основных стандарта:

  • iBeacon
  • AltBeacon
  • Eddystone

На самом деле есть еще стандарты, например PayPal beacon или какие-то свои реализации от вендоров, например gimbal и estimote, но именно перечисленные выше являются на данный момент основными, доминирующими стандартами.

Большинство устройств сейчас умеют транслировать сообщения в любом из этих трех форматов, а некоторые даже одновременно в нескольких. Давайте рассмотрим их чуть подробнее чтобы понять, в чем между ними разница.

iBeacon


Первым стандартом был iBeacon, он был представлен компанией Apple inc. в 2013 году. Основным его назначением было применение в области розничной торговли и мобильного маркетинга, а также для локального позиционирования внутри помещений.

Стандарт iBeacon предполагает трансляцию только 1 типа advertisment packet, который состоит из следующих частей:

  • UUID — 16-байтный уникальный идентификатор группы маяков;
  • Major — 2-байтное беззнаковое значение;
  • Minor — 2-байтное беззнаковое значение;
  • Measured Power — значение уровня сигнала в 1 м от передатчика. 8-битное знаковое целое — значение показателя уровня принимаемого сигнала (RSSI — Received Signal Strength Indicator), которое используется для определения близости (proximity) маяка к приёмнику (мобильному устройству). Измеряется в dBm.

iBeacon frame:
image


Устройство или iOS сами по себе эти пакеты ничего не значат, их должно обрабатывать приложение. В каждом отдельном случае, для каждого сценария использования пользователю придется ставить отдельное приложение. Количество UUID с которым может работать приложение ограничено. Среди недостатков стандарта стоит отметить его проприетарность, отсутствие нативной поддержки на платформе Android и то, что он умеет транслировать только один тип advertisment packet.

AltBeacon


Консорциумом RadiusNetwork's был представлен альтернативный и открытый стандарт AltBeacon. Он изначально разрабатывался как интероперабельный и обратно совместимый со стандартом iBeacon. AltBeacon обладает почти таким же функционалом что и iBeacon, хотя и позволяет передать чуть больше полезной информации.

AltBeacon frame:
image


Из 28 байт Advertisment packet, нам доступны 25 байт которые состоят из:

  • MFG ID — 2 байта. Идентификатор производителя устройства
  • BEACON CODE — 2 байта. Код Advertisment packet
  • BEACON ID — 20 байт. Уникальный идентификатор устройства
  • MFG RSVD — 1 байт. Специальное зарезервированное поле (в основном используется для Bluetooth assigned numbers)

В свою очередь BEACON ID может быть представлен как у iBeacon, т.е. 16-byte id1 + 2-byte id2 + 2-byte id3. Подробнее со спецификаций протокола можно ознакомиться здесь. Так как это по сути открытый аналог iBeacon, то и недостатки у него такие же.

Eddystone



В 2015 году компанией Google был представлен новый и полностью открытый стандарт Eddystone, который эволюционировал из проекта URIbeacon. Как и 2 других стандарта, Eddystone — это спецификация протокола, которая определяет формат сообщений BLE. Eddystone включает весь опыт других стандартов и призван быть более гибким и устранить недостатки присущие ibeacon и AltBeacon

В отличие от них, он умеет рассылать уже 3 типа пакетов:

  • Eddystone-UID — 16-байтовый идентификатор устройства, который состоит из 10-байт namespaceId и 6-байт instanceId.
  • Eddystone-URL — транслирует URL используя сжатый формат кодирования. Любой длинный URL можно сократить с помощью Google URL Shortener (https://goo.gl/), что бы поместится в ограниченный 18 байтами Advertisment packet. После декодирования, URL может быть использован любым клиентом с доступом к интернету. Например, если маячок транслирует URL: https://goo.gl/Aq18zF, то любой клиент, который получил этот пакет может посетить этот URL (https://goo.gl/Aq18zF).
  • Eddystone-TLM — телеметрия, доступны такие данные как напряжение аккумуляторной батареи, температура устройства, количество отправленных пакетов с момента включения и время с момента включения.

Eddystone frame:
image


Eddystone-URL является основой Physical Web и позволяет легко обнаруживать и взаимодействовать с окружающим нас веб-содержимым. Так как он транслирует обычный URL нам не нужно ничего кроме браузера. Никаких специальных приложений, библиотек или SDK!
Для случаев когда нужно сделать не публичное, обычное приложение для внутреннего или специального использования, Eddystone-URL не подходит, мы должны использовать Eddystone-UID.

Как я уже писал выше, есть маячки, которые позволяют одновременно транслировать несколько видов пакетов, например iBeacon и Eddystone-URL или Eddystone-UID и Eddystone-URL. Как и для чего это можно использовать я расскажу дальше.

Как это выглядит на примере маячков RadBeacon USB, RadBeacon Dot и iBKS 105:


Работа с маячками и реализация Physical Web


В самом простом случае, для реализации Physical Web, достаточно ble-маячка с поддержкой Eddystone. Разные модели маячков инициализириуется и конфигурируютсятся по разному. Можно легко развернуть 5, 10, или, скажем 100 маячков. Вы просто назначаете им URL, потом, если это необходимо, меняете только сам контент. Но если вам нужно развернуть большое количество разных устройств, от разных производителей на достаточно большой площади (торговый центр, аэропорт, район города или даже целый город), при том что часть маячков могут быть в постоянном движении, например в транспорте. В таком случае у вас возникают некоторые проблемы, но решения есть. Некоторые производители предоставляют свои облачные решения и CMS для управления маячками, например Estimote, Kontakt.io, Blesh, Phy.net и LightCurb. Estimote и Kontakt.io так же предоставляют на github свои SDK.

На мой взгляд, наиболее универсальным и простым инструментом для решения подобных задач является (Google's beacon platform)[https://developers.google.com/beacons/]. Google's beacon platform позволяет легко мониторить и управлять сразу всеми устройствами. Платформа позволяет работать с разными маячками от разных производителей, предоставляй разработчикам единый, простой и гибкий инструмент, о котором я подробно расскажу в отдельной статье.
Мы можем добавить в уже имеющееся, популярное у пользователей приложение возможность работы с маячками, например для навигации или получения каких то дополнительных данных. Понятно что в этом случае Eddystone-URL не подходит, нам нужно использовать Eddystone-UID. Но благодаря тому что некоторые маячки умеют рассылать сразу два типа пакетов одновременно, например Eddystone-URL или Eddystone-UID, мы можем обеспечить пользователей с приложением дополнительными данными, а пользователей без приложения, самим приложением.
В случае когда необходимо сделать не публичное приложение для специального или внутреннего использования, мы просто используем Eddystone-UID.

Маячки могут использоваться для навигации, при том не только внутри помещений(indoor). На первый взгляд эта задача выглядит на такой уж сложной, ведь мы можем определять расстояние до маячка с помощью RSSI. Но даже в идеальных условиях значение сигнала скачет. Связанно это с особенностями антенны, распространения волн, зашумленностью и преградами. В целом, приблизительно, вы можете определить расстояние и кому то этого достаточно. Но если вам нужны более точные показания, то придётся применять триангуляцию сигнала, фильтр Калмана и т.д. В целом, на хабре было написано достаточно про особенности indoor навигации, вот неплохие статьи:


Эмуляторы


Что делать если хочется попробовать поработать с концепцией Physical web, маячком, но не хочется тратить денег? Или нужно что то быстро спрототипировать, а маячка под рукой не оказалось? Мы можем воспользоваться эмуляторами.
Например, кроссплатформенный проект (https://github.com/don/node-eddystone-beacon). Он умеет рассылать все 3 вида Advertisment Packet, работает поверх NodeJS, в зависимостях у него только проект bleno, который является модулем nodejs для работы с BLE периферией. Большинство ноутбук выпущенных начиная с 2011 года обладают Bluetooth v4, он же BLE. Так что вы без проблем можете эмулировать работу Eddystone маячка прямо у себя на ноутбуке. ""
В роли источников сообщений Eddystone могут выступать и телефоны с Android и iOS. Для это вы можете легко найти приложения в Play Market и AppStore соответственно.
Всё это позволяет вам попробовать и начать разрабатывать прямо сейчас.



P.S. Отвечу на ваши вопросы.
UPD: Обновил статью, добавил скриншоты и текст. Материал про Google's beacon platform вынес в отдельную статью из двух частей:

  1. Google's beacon platform. Часть 1. Proximity API
  2. Google's beacon platform. Часть 2. Nearby messages API
  • +12
  • 22,2k
  • 6
Поделиться публикацией

Комментарии 6

    0
    Круто! Расскажи, плиз, про Nearby и про реальные примеры самых успешных внедрений
      0
      Ок, учту, добавлю примеры успешных внедрений
      0
      Отличная статья!) Еще бы хотел знать, какие устройства могут работать с данной технологией (на каких версиях iOS и Android это все поддерживается)
        +1
        Об этом я подробно расскажу в следующей части. Но если кротко, то для iOS минимальной версией является iOS 7.0.
        Для Android, желательно 4.3 и выше, например, приложение Physical web требует версию 4.4 и выше.
        0
        А есть ли какие-нибудь маячки размером порядка элемента питания CR2450, что используется для питания?
        Например, чтобы можно было повесить на ошейник коту

      Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

      Самое читаемое