Содержание


Лучшие методики разработки решений для Интернета вещей

Применение опыта разработки мобильных решений в IoT-проектах

Comments

Итак, вы решили разработать решение для Интернета вещей. Для начала полезно изучить методики, выработанные при создании мобильных решений. В частности, обратите внимание на следующие методики:

  • Отделение API-интерфейсов от сервисов
  • Итеративная разработка прототипа решения
  • Ожидание проблем с сетевым доступом.

Аватары, сервисы и отделенные API-интерфейсы

Если вам приходилось разрабатывать web-приложение, то вы уже знакомы с понятием сервиса. Сервис — это функциональная возможность, предоставляемая приложением и определяющая наше традиционное восприятие системы (например, метеорологический сервис).

Потребителями сервиса являются аватары — подключенные к Интернету объекты (которые могут быть программными продуктами или физическими интеллектуальными устройствами). Аватары взаимодействуют с элементами сервиса или со всем сервисом. Каждый аватар взаимодействует с сервисом независимо, однако вместе они обеспечивают высокую эффективность сервиса.

Рассмотрим для примера метеорологический сервис. Аватарами могут быть web-сайт или мобильное приложение, которые показывают актуальные данные о погоде. Кроме того, аватаром может быть подключенная к сети метеостанция, которая каждую минуту отправляет данные в метеорологический сервис, сообщая текущие значения температуры, влажности и скорости ветра.

Современные мощные мобильные сервисы (например, сервисы Google, и в особенности Google Now, Facebook и Twitter) доступны для множества аватаров, включая настольные приложения, мобильные web-сайты, специализированные приложения, приложения других поставщиков и даже дополнения к браузерам. Каждый из этих аватаров может использовать столько возможностей сервиса, сколько требует контекстная ниша, в которой он функционирует. На любую web-страницу (аватар) можно поставить кнопку «твитнуть эту ссылку» (один сервис), или можно на главном экране устройства под управлением Android (аватар) видеть список результатов поиска (еще один сервис).

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

Отличным современным примером применения такого подхода в секторе физических устройств является FitBit. Компания FitBit предлагает ассортимент устройств, позволяющих оценивать здоровье и физическую форму пользователя. Между устройствами есть различия (например, подсчет шагов или ступенек), однако основной сервис один и тот же. Эти устройства агрегируют показатели датчиков активности и предоставляют пользователю сводную информацию для принятия обоснованных решений, связанных со здоровьем.

FitBit предоставляет следующие сервисы:

  • Отслеживание данных об активности (тип, продолжительность, израсходованные калории, время активности, пульс)
  • Отслеживание данных о сне (продолжительность сна и бодрствования)
  • Отслеживание потребленных калорий и выпитой воды
  • Отслеживание данных о весе
  • Формирование отчетов в системе.

Разные аватары взаимодействуют с устройствами FitBit по-разному:

  • Средства отслеживания физической формы фиксируют информацию и возвращают ее сервису
  • Мобильное приложение обеспечивает просмотр агрегированных данных
  • Web-приложение предоставляет более детальные данные и общие тенденции
  • Сторонние системы могут передавать в платформу данные (например, сведения о продуктах питания)
  • Сторонние системы могут считывать агрегированные данные (например, количество шагов) для добавления в свои собственные сервисы.

Таким образом, отделение сервисов и наличие хорошего API обеспечивают FitBit следующие преимущества:

  • Сервис доступен для различных аватаров и может использоваться по-разному (на запястье, в кармане, на столе).
  • Сторонние системы могут повышать ценность изделий FitBit, добавляя собственные сервисы.
  • В условиях фрагментированности рынка мобильных устройств (поскольку все больше компаний конкурируют с Apple) FitBit может реагировать быстро и легко, выпуская новое приложение для любого устройства, которому нужен аватар (даже для телефонов под управлением Windows).

Такой подход на основе отделения API-интерфейсов становится все более распространенным, поскольку приложения должны поддерживать как мобильные, так и настольные web-среды. Если вы организуете свой IoT-сервис подобным образом, то сможете развивать его в новых направлениях при появлении рыночных возможностей.

Для IoT-решения необходимы прототипы программного и аппаратного обеспечения

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

Задача еще более усложняется наличием множества вариантов контекста, в котором IoT-решение может использоваться. Даже если это всего лишь датчик — как будут обеспечиваться взаимодействия с ним? С использованием мобильного или web-приложения? Отличается ли конфигурирование от отчетности? Насколько удобны в использовании интерфейсы? Список вопросов может выглядеть бесконечным.

В отрасли мобильных продуктов накоплен большой опыт решения таких проблем, поскольку мобильные среды могут приводить к изменению контекста, оказывая влияние на применимость сервиса. В результате создание мобильных решений обычно начинается с простых прототипов, которые совершенствуются по мере доработки. Обычно этот процесс включает следующие этапы:

  1. Создание простого интерактивного web-приложения с использованием среды разработки для быстрого определения основных аспектов взаимодействий. Все вызовы сервиса заменяются заглушками с использованием замещающего контента, достаточно реалистичного для моделирования того, как информация должна воспроизводиться и как ее необходимо использовать.
  2. Интеграция простых аспектов сервиса, позволяющая определить, насколько ответы корректны и релевантны контексту.
  3. Переход к проектированию интерфейсов за пределами функциональных прототипов с учетом методов взаимодействий и потребностей в обучении и обратной связи.
  4. Продолжение разработки и интеграции возможностей вплоть до выпуска продукта.

Итеративный подход к разработке прототипов IoT-решения позволяет гарантировать пригодность сервиса к использованию и реализацию требуемых аспектов. Обратите внимание, что не для каждого контекста требуются все аспекты вашего сервиса. Посмотрите на современное мобильное банковское приложение — и вы увидите, что обычно оно не предоставляет полнофункциональную банковскую платформу, ограничиваясь информированием о состоянии счета и возможностью выполнять некоторые виды платежей/переводов. В контексте мобильного банковского обслуживания пользователи, как правило, только проверяют, достаточно ли у них средств, чтобы сходить за продуктами или оплатить счет.

Итеративный подход можно применять не только к созданию прототипов IoT-сервиса и аватаров, но и к разработке прототипов используемого в решении аппаратного обеспечения:

  1. Начните с простой готовой аппаратной платформы. Хотя Arduino считается любительской платформой, это недорогой, качественный и достаточно надежный вариант для быстрого получения работающего прототипа. Потратив всего несколько долларов, можно определить, есть ли в вашей идее какая-либо ценность, — без инвестиций в проектирование специальной системной платы.
  2. Дорабатывайте прототип, используя максимально возможное количество готовых компонентов. Сохраняйте состояние, при котором прототип можно быстро разобрать и перестроить. Для этого лучше всего подходят системные платы для прототипирования, компоненты для штыревого монтажа и подключаемые модули. Используйте хорошо известные компоненты, чтобы уделять внимание созданию прототипа, не разбираясь в деталях реализации.
  3. Отделите важнейшие компоненты от системных плат, к которым они подключаются. Применение компонентов, использующих стандартные протоколы, такие как I2C и SPI, позволит при необходимости быстро заменить Arduino на BeagleBone или Raspberry Pi.
  4. Используйте готовое оборудование как можно дольше, перед тем как решите перейти на другое оборудование, а потом подумайте еще раз.

В качестве основы вашего IoT-решения вы можете использовать Raspberry Pi, Arduino, ESP8266 или другие подобные компоненты. Конечно, бывают веские причины для использования конкретных процессоров или системных плат. Однако если вы создаете подключенный к Интернету садовый датчик, то возможностей ATMEGA328 (контроллер Arduino) или ESP8266 хватит для ваших потребностей с запасом. Используя готовые компоненты, вы получаете преимущества от масштаба уже существующей инфраструктуры, а также от наличия готовых решений типичных проблем.

В настоящее время аппаратные средства легко поддаются инженерному анализу. В IoT-решении ценным является сервис, а не конкретные аватары. Поэтому дорогие специализированные аппаратные компоненты будут повышать стоимость ваших аватаров без существенного повышения ценности вашего сервиса (ухудшая при этом ценовую конкурентоспособность вашего продукта). Придерживайтесь модульного подхода к разработке компонентов и платы контроллера. Тогда, если вам потребуется перейти на более мощную или менее дорогую системную плату, вам не придется перестраивать все с нуля.

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

Проектирование по принципу Offline First как способ решения проблем с доступом к сети

Многие разработчики, живущие в больших городах, в особенности на Западе, воспринимают повсеместную доступность мобильных и wifi-сетей как нечто само собой разумеющееся. Это ошибочное допущение может сделать ваше решение полностью непригодным для использования. Методика разработки Offline First обеспечивает создание мобильных и web-приложений, которые будут работать без поддерживающей их сети. Возможно, доступны будут не все функции, но потеря и восстановление сетевого подключения должны проходить гладко, не затрагивая конечного потребителя.

Разработка мобильных решений по принципу Offline First основывается на следующих общих принципах:

  • Исходите их того, что доступ к сети может быть потерян в любой момент — даже (и особенно) в процессе передачи данных.
  • Используйте короткие и более частые сообщения вместо объемных запросов и ответов.
  • Используйте локальное хранилище для буферизации сообщений, которые необходимо передавать по сети. Сообщения, хранимые локально, можно ставить в очередь в автономном режиме или отправлять повторно в случае сбоя.
  • Убедитесь в том, что приложение определяет наличие сетевого подключения, и не ожидайте, что пользователь будет знать об этом.
  • Реализуйте механизмы фоновой синхронизации данных, например, сначала обновления состояния системы, а затем синхронизация версий данных (чтобы пользователь мог вернуться к своей задаче).

Многое из этого применимо и к IoT-разработке, хотя многие устройства на базе датчиков предусматривают постоянное wifi-подключение. Безусловно, в перегруженном пространстве (например, в жилом здании в центре большого города, такого как Гонконг) может быть 50–100 wifi-сетей, конфликтующих за одно пространство сигналов (и мешающих друг другу). Каждый, кто принимал участие в конференциях разработчиков, знает, насколько плохим может быть wifi-соединение, когда хотя бы 200 разработчиков с ноутбуками, планшетами и мобильными телефонами создают собственные точки доступа в ограниченном пространстве. Мне приходилось наблюдать на конференциях, как неплохие беспроводные модули не могли установить связь из-за шума и конфликтов в сети.

Итак, как применить описанные методики к IoT-проектам? При разработке IoT-решений воспользуйтесь следующими рекомендациями:

  • Допускайте возможность отключения от сети в любой момент.
  • Сначала записывайте данные локально, и только потом отправляйте.
  • На стороне сервиса используйте систему управления очередями сообщений, такую как RabbitMQ.
  • Используйте для обмена сообщениями легкие и устойчивые протоколы, такие как CoAP и MQTT, вместо более тяжеловесного протокола HTTP.

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

В условиях роста количества подключенных к сети устройств надежность сети нельзя гарантировать даже в средах домашних сетей. Обеспечение функционирования в автономном режиме и устойчивости к сетевым проблемам должно стать важнейшим аспектом в разработке вашего IoT-решения.

Заключение

В этой статье описано, как отделение API-интерфейсов от сервисов позволяет создавать мощные IoT-приложения. Кроме того, рассказано о том, как можно упростить разработку IoT-решения, используя простое модульное оборудование, такое как платы Arduino. Также описано, как применение концепции разработки мобильных решений Offline First позволяет улучшить сетевые взаимодействия IoT-устройств. Вы узнали, как можно использовать лучшие методики мобильной разработки при создании решений для Интернета вещей, чтобы повысить вероятность успеха IoT-проектов.


Ресурсы для скачивания


Похожие темы


Комментарии

Войдите или зарегистрируйтесь для того чтобы оставлять комментарии или подписаться на них.

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=Мобильные приложения
ArticleID=1023158
ArticleTitle=Лучшие методики разработки решений для Интернета вещей
publish-date=12032015