Как создавать IoT-устройства: методика и примеры
На первый взгляд разработка «железных» продуктов мало чем отличается от IoT-устройств.
Имея опыт работы в менеджменте производства мобильных терминалов, а потом и устройств интернета вещей, Алексей Пышкин, R&D-директор notAnotherOne, рассуждает о методологии разработки IoT-продуктов. Речь пойдет об удобной и простой системе, которая считает деньги, оценивает технологии и при этом понятна клиенту.
Проработав более 10 лет в различных компаниях, занимающихся производством мобильных телефонов и смартфонов, к IoT у меня сложилось своеобразное отношение. Интернет вещей казался легким и простым. Это отношение жило со мной до моего первого IoT-продукта.
По плану разработка должна была занять 6 месяцев, но в итоге затянулась до 11. Задержка и приведшие к ней вызовы натолкнули меня на определенную рефлексию и поиск ответов: чем же отличается IoT от другого хардвера, и есть ли наработанные подходы и методологии разработки. Перебирая различные методики, я утвердился во мнении, что IoT – система систем, и методология нужна соответствующая.
Система систем — это объединение систем в сеть на определенный период времени для достижения определенной более высокой цели рамках общей системы; при этом, каждая из систем является независимой и работоспособной.
Djamshidi, 2009
Основные критерии IoT как системы систем
У IoT-продукта есть свои особенности:
- Отсутствие единого product owner-a или ответственного за всю систему.
- Повышенные требования к полезности / ценности устройства – устройство должно обязательно добавлять ценность. Никто не собирается платить за устройство или подписку на услугу, если:
— Устройство или сервис не работает должным образом;
— Не привносит ценности в жизнь или работу пользователя;
— Заставляет пользователя постоянно думать и заботиться об устройстве;
— Не выглядит органично в каждодневной жизни пользователя.
- В разы увеличены сложность, цена ошибки и зависимости от всех смежных систем, по сравнению с другой электроникой. К примеру, если встроенный датчик гироскопа в девките не работает должным образом, то на выходе мы получаем неправильную информацию о положении продукта в пространстве.
- Повышенные требования к безопасности + многочисленные отраслевые требования и стандарты. Российский рынок не сильно зарегулирован, в то время как на Западе существуют тонны всяческих стандартов - это особенно применимо к IIoT (Industrial IoT).
- Мультидисциплинарность.
В разработку вовлечены представители разных направлений от компьютерных инженеров до UX-инженеров, необходимо дружить разным командам.
Типичные фейлы в разработке IoT-устройств
- Члены команды не общаются друг с другом. Инженеры не общаются с дизайнерами и наоборот. К примеру, в устройстве с мониторингом качества воздуха поменяли краску корпуса на более стойкую → сенсоры летучих органических веществ реагируют на так называемый outgassing и показывают завышенные данные.
- Команда переоценивает свои возможности и не пытается аутсорсить экспертизу, не отдавая себе отчет в оценке финансовых и человеческих ресурсов.
- В погоне за определенными целями команда забывает о UX и о потребностях конечных пользователей.
- Продукт делается для никого или «connected, потому что так модно». Например, «умные» солонки и грохотки для яиц скорее создают больше проблем, чем решают их.
- Устройство не future-proof, то есть не проработаны механизмы OTA (обновление по воздуху, on-the-air), недостаточно ресурсов для крупных обновлений. В этом контексте меня всегда забавляют обещания cloud- или IoT- компаний, сулящих пожизненный сервис. Непонятно, чей жизненный цикл они подразумевают: жизнь конечного пользователя, бизнес-активность своей компании, или работу API?
- Устройство не работает или работает неправильно без подключения к сети.
- Устройство не работает без облака.
- Устройство перестает работать, если появляется проблема у партнеров (библиотека/модуль, API, облачный сервис).
Есть жизненный рассказ на данную тему. Речь идет о подключенном доме, который полностью вышел из строя из-за действий грабителей. В целях самозащиты хозяйка схватилась за пистолет, но он отказался стрелять. Причина до смешного банальна: на каждый выстрел требовалась авторизация, а ее невозможно было пройти, так как отсутствовало подключение к сети.
Как избежать типичных фейлов
Мы уже выяснили, что имеем дело с системой систем, поэтому возникает новая сущность — та, которая контролирует все системы и взаимодействия между ними. Если опираться на литературу, то это это некий system engineer (инженер систем). Кроме этого появляются product owners для отдельных систем (облако, железо, приложения и т.д.)
Еще один подход — выбор конкретной методологии, в соответствии с которой происходит обмен информацией, оценка рисков и принятие решений. Важно, чтобы методология применялась и в коммуникациях с клиентом, чтобы разговаривать с ним на одном языке. При этом важно не уходить в технические детали и доносить информацию как можно проще, так как клиенты попадаются разные.
Выбор методологии
Industrial Internet Architecture framework
Этот фреймворк достаточно всеобъемлюще описывает взаимодействие различных команд. Основная проблема — он не покрывает некоторые предметные области, не раскрывает тему дизайна + сложная терминология для клиента.
MBSE, Model-Based System Engineering
Тоже достаточно всеобъемлющая и развитая методология, но представляющая техническую сложность для не ИТ-специалистов. Она предполагает рекомендованные связки в виде UML2/SysML + DoDAF/TOGAF/ OpenUP UMD + TODEF и другие узкоспециализированные приложения, которые трудно использовать, если речь идет о внешнем клиенте.
IoT Management Framework
Это более-менее простой и удобоваримый фреймворк, так как он не требует от стейкхолдеров специальных знаний, например, UML и использования специального софта. Первым его описывал Дэниэл Элизальде, один из авторов по теме IoT, в том числе промышленного интернета вещей.
Основная цель – декомпозировать основные составляющие и разобрать влияние тех или иных предметных областей на основные компоненты. Причем драфт фреймворка можно адаптировать под свои потребности.
Например, у автора не вынесены этапы ID/MD, то есть разработка промышленного дизайна и разработка механической структуры как составляющие разработки, поэтому мы вынесли эти этапы в отдельный пункт.
ID/MD — больная тема для нас как дизайн-хауса. Когда речь заходит про промышленные устройства интернета вещей, то чаще всего всплывает такая аббревиатура как IoUH, по-другому, Internet of Ugly Housings, или интернет страшных корпусов. Со своей стороны, отметим, что «промышленное» не значит «некрасивое».
Например, уличная станция измерения качества воздуха. Слева типовой дизайн. Справа один из прототипов для стационарной установки для контроля качества воздуха Atmotube.
Модель Build vs Buy vs Partner
Ниже представлен полный цикл разработки продукта. Все начинается с идеи. На следующем этапе — исследование, проверка концепции, патентование, разработка промышленного дизайна и инженерной документации, прототипирование.
Через несколько инженерных итераций получаем MVP, потом переходим в выбору и настройке производства, прогоняем продукт через несколько циклов тестирования, и в конце запускаем массовое производство.
Если представить этот цикл в более высокоуровневом варианте, то у нас возникает такая картина:
Первым этапом идет исследование, то есть продуктовый анализ, анализ конкурентов, анализ и проработка фич. На данном этапе разработчикам важно провести оценку, как они будут производить это устройство. Будет ли это сборка с нуля, либо переиспользование железа и каких-то модулей, либо партнерство. Условно назовем это противостояние Build vs Buy vs Partner.
Матрица принятия решений для Build vs Buy vs Partner
Чтобы выбрать правильный подход, надо ответить на следующие вопросы:
- В каких именно составляющих ваша компания может привнести ценность?
- Целевая бизнес-модель: как планируете зарабатывать с помощью этого устройства;
- Имеющиеся ресурсы: человеческие, опыт, финансы и т.д.;
- Time to market: как быстро вы хотите выпустить устройство;
- Наличие на рынке готовых решений;
- Intellectual property — требования.
Если вы хотите выпустить продукт в кратчайшие сроки, скажем, в течение нескольких месяцев, то надо смотреть в сторону готового решения. Если же вы затеваете полноценную разработку, то мы говорим о 6-10 месяцах плотной работы.
Также важно наличие готовых решений на рынке с искомым функционалом. Если у вашего устройства нет конкурентов, то это серьезный повод напрячься. Это значит, исследование и конкурентный анализ проводились небрежно, либо ниша не столь привлекательна, и стоит задуматься о целесообразности затеи.
Если вы хотите владеть продуктом и всей интеллектуальной собственностью, связанной с ним, например, source-коды прошивки, тулинг, source-коды софта, то лучше создавать продукт с нуля.
Структура расходов
Есть фиксированные издержки, которые не зависят от количества устройств. Конечно, есть исключения, например как лицензии на софт или определенные модули. Фиксированные издержки состоят они из R&D-расходов, так называемых NRE (non-recurring engineering), расходов на продажи, маркетинговые активности и операционные косты. Плюс есть переменные издержки: стоимость каждого произведенного устройства.
Buy vs Build vs Partner на примере
Давайте рассмотрим, как обновленный фреймворк по IoT Management работает в процессе принятия решений для “Buy vs Build vs Partner” на примере датчика полива растений. Это простое устройство с большим количеством потребительских моделей.
ID/MD: Вероятно дизайн устройства будет главным новшеством.
Hardware: Плата достаточно простая, и все принципы действия уже хорошо изучены, и нового ничего не будет.
Firmware: Прошивка уже стабилизирована бесконечными релизами, апдейтами, и все шишки уже набиты.
Communications: В плане передачи данных скорее всего устройство работает с хабом, чтобы иметь возможность непрерывно рапортовать об уровне влажности почвы. Тут ничего нового.
Cloud: Здесь есть к чему стремиться, и не хотелось бы пользоваться китайскими проприетарными облачными сервисами. Можно улучшить пользовательский опыт, переведя работу с данными на один из крупных облачных провайдеров или использовать open cloud.
Apps: Чаще всего проприетарные приложения для датчика не обладают расширенной функциональностью и приятным интерфейсом, поэтому это еще одна область для улучшения UX.
Проделав довольно поверхностный анализ, делаем вывод, что для широко распространенных категорий устройств с простым функционалом не стоит изобретать велосипед. Стоит всерьез задуматься о полном или частичном переиспользовании готовой «начинки» и привнести ценность, улучшив пользовательский опыт, будь то простая первоначальная настройка устройства, интуитивно понятный интерфейс, интересный дизайн, выгодно отличающийся от конкурентов и т.п.
Если же вы, детально изучив конкурентов, уверены на 100%, что сможете сделать продукт с нуля лучше и/или дешевле, чем все доступные на рынке, и у вас есть для этого необходимые ресурсы – дерзайте. При этом не забудьте взвесить все возможные затраты - см. раздел «Бизнес».
Матрица принятия решений
К циклу разработки добавляется матрица принятия решений. В идеальном мире основные решения должны происходить параллельно с разработкой продуктовой стратегии, так как существует очень много пересечений.
Так выглядит матрица:
Каждую их составляющих мы разбираем по областям принятия решений. А именно UX, данные, бизнес, технологии и безопасность.
UX в матрице решений
UX — ради улучшения пользовательского опыта мы и планируем запускать это устройство.
Чтобы понять потребность пользователя, мы должны сформировать персонифицированную модель или user persona. Это понятие пришло в хардвер из дизайна.
Этот собирательный образ вашего пользователя помогает минимизировать пристрастность всех причастных к разработке и помогает донести потребности вашего пользователя до разных команд. Описание пользователя содержит четкое описание целей, которые он планирует достичь с помощью вашего устройства.
Отталкиваясь от personas, можно наполнять так называемый «день в жизни» (a day in the life) — описание типичного дня пользователя, со всеми рутинными действиями, а уже потом переходить к более детальному анализу user job stories/user scenarios, где будут рассмотрены все боли пользователя, которые вы планируете решить и все сценарии использования вашего будущего устройства.
Разберем UX влияет на принятие решений по каждой составляющей разработки на примере браслета с измерением пульса.
ID/MD дизайн:
- Корпус и ремешок должны быть из гипоаллергенной резины;
- Вариативность цветов;
- Пыле- и влагозащита.
Hardware:
- Определение частоты пульса и оксидации крови;
- Легкий вес для удобного ношения на руке;
- Отображение результатов измерений на экране;
- Энергоемкость батареи, чтобы держать заряд как минимум неделю.
Firmware:
- Обработка данных в реальном времени;
- Простота настройки.
Список требований к прошивке можно продолжить исходя из основных целей и условий использования.
Communications:
- Постоянное подключение к сети, чтобы не потерять момент изменения пульса или снижения кислородного насыщения крови - для этого, устройство должно быть постоянно подключено к сети, без полагания на смартфоны. О Bluetooth мы не говорим, а говорим о каком-то другом протоколе, который позволит устройству обмениваться данными без смартфона – примером может быть Wi-Fi (но в этом случае устройство становится зависимым от WiFi-покрытия), встроенный LTE-модем (повлияет на автономность устройства и потребует дополнительных настроек и предоплаченной SIM), либо что-то из LPWAN (LoRA, NB-IoT, etc.).
Cloud:
- Интеграция со сторонними платформами, например, API медицинских сервисов;
- Приватность данных;
- Хранение истории, например, глубиной в месяц.
Apps:
- Приложения для основных операционных систем Android/iOS;
- Базовый функционал по построению графиков, список контактов для отправки истории.
Бизнес в матрице принятия решений
Говоря о бизнесе, прежде чем приступить к разработке продукта, нужно сформировать четкое представление:
- На чем будем зарабатывать, то есть монетизация;
- На что будем тратить. Тут стоит обратить внимание модель Buy VS Build VS Partner.
Рассмотрим детальнее возможные издержки.
ID/MD/Hardware:
Мы объединили траты на ID/MD и hardware. Все пункты обязательны, если вы решили создавать продукт самостоятельно. Единственный опциональный пункт — дизайн-патент. Многие предпочитают не тратить несколько тысяч долларов. Мы ратуем за патентование, так как заимствования встречаются сплошь и рядом.
Firmware:
Если рассчитывать стоимость разработки прошивки, то они могут покрывать сервис как сторонней команды, либо работу вашей.
Кроме этого необходимо приобрести лицензию на программные компоненты, если говорить не об open source. Отчисления могут занимать большой процент в расходах.
И опять же стоит упомянуть сертификации к прошивкам. Как пример подойдет сертификация Android-устройств. Если в устройстве планируется использовать GMS (Google Mobile Services), тогда необходимо провести сертификацию с упором на софт у одного из официальных партнеров Google.
Communications:
Считаем стоимость передачи данных, если речь идет о сетях wide area networks, таких как GSM, LTE, либо стоимость построения Wi-Fi/LPWAN инфраструктуры.
Cloud:
Абонентская плата, стоимость за поддержку, стоимость процессорного времени, лицензия на аналитику, сторонние компоненты и модули.
Apps:
Разработка, использование сторонних компонентов, модулей и лицензии.
Ниже схема, как заработать на своем IoT-устройстве.
Данные в матрице принятия решений
Технологии в матрице принятия решений
В заключение кратко подытожим написанное:
- Ранняя и всесторонняя проработка проекта позволяет многократно снизить риски на более поздних этапах;
- IoT – история про партнерства. Не стоит изобретать велосипед, если есть сомнения, удастся ли превзойти существующие решения по функционалу и/или стоимости. Это касается аппаратных и программных модулей;
- Постарайтесь предусмотреть сценарий работы с минимальной зависимостью работоспособности устройства от сети, сторонних сервисов, облака;
- Исходите из самого худшего сценария. Произойти может все, что угодно: полное прекращение поддержки сервиса партнером или невозможность обеспечить работу облачной инфраструктуры вами. В этом случае устройство должно выполнять основной функционал в режиме оффлайн. К сожалению, это применимо не ко всем категориям устройств, но если такая возможность есть, то к ней надо стремиться;
- Постарайтесь вырастить в команде как owner-ов по каждому из направлений (HW, SW, ID/MD), так и owner-а системы. Последний сможет оценить влияние изменений внутри одной системы на другие.
*Подготовил этот материал в рамках участия в конференции, посвященной IoT-разработке – IoT Focus Tech Conference (Минск, Беларусь).
За абзац про типичные фейлы отдельное спасибо
Достали уже эти московские метросексуалы и их бизнес-модели как бы купить что-то в Китае подешевле и продать здесь подороже. Пока сами делать не научитесь от начала до конца, не поймёте, в чём смысл.
Иначе заработать сможете только на распиле бабла или на конферециях. Так как ваши потенциальные клиенты и сами в Китае купят.
Достали уже эти провинциальные комментаторы про то какие они умные и при этом бедные.. Пока сами не научитесь делать продукты с нуля, и успешно продавать, не поймете в чем смысл. Иначе никогда в жизни не заработаете нормальных денег, и так и будет строчить ваши никчемные токсичные комментарии.
"Если у вашего устройства нет конкурентов, то это серьезный повод напрячься" - Как изобретатель скажу вам, что вы написали бред, мягко говоря. А патентование я считаю атавизмом 19-го века. Собираюсь создать клуб-фонд бесплатных лицензий на изобретения, и вообще авторские права, но только для членов клуба, чтобы продающие лицензии на авторские права не смогли паразитировать на бесплатных лицензиях этого клуба-фонда
Если у вашего устройства нет конкурентов то ваши шансы 0.00000000001 на успех.
Вы как изобретатель конечно же можете поделиться примером успеха, какое устройство не имеющее конкурентов вы вывели на рынок?
Это все ограничено по времени действия.
Деньги кто на поддержку(патентов итп ) будет тратить ?
Представился Генри Форд, как он вместо того что бы собирать свою первую коляску без лошади, ходит по соседям (фермерам и ковбоям) и на полном серьезе предлагает опросник, что лучше? - лошади, на которых они с детства ездят или куча непонятных слов - шасси, цилиндры, колен-вал.