Поиск УТП в экосистеме Интернета вещей:часть 2

Арпит Хосла из IoT Australia Consulting

В этой серии статей наша цель - не только наметить цепочку создания стоимости IoT, но также рыночные / экономические структуры и меняющуюся динамику вокруг них. Эта статья предназначена для лиц, принимающих бизнес-решения, которые пытаются выяснить стратегию решения и УТП в каждом компоненте цепочки создания стоимости. В нашей последней статье мы сосредоточились на датчиках, устройствах, шлюзах и коммуникациях IoT в цепочке создания стоимости. В этой статье мы, Арпит Хосла и Пранит Такур из IoT Australia Consulting Services погрузимся в платформы Интернета вещей.

Учитывая множество способов толкования термина «платформа Интернета вещей», мы пользуемся этой возможностью, чтобы сначала высказать свое мнение о том, что все включает в себя платформа Интернета вещей. На высоком уровне он включает в себя горизонтальные и вертикальные возможности. Некоторые из возможностей, которые можно пометить как горизонтальные, - это управление подключением, управление устройствами, прием и хранение данных, платформа поддержки приложений и платформы поддержки аналитики. Иногда платформы биллинга, обеспечивающие сквозное выставление счетов, также являются частью семейства горизонтальных платформ. Сами приложения являются более вертикальными или специфичными для сценария и, следовательно, могут быть отнесены к категории вертикальных возможностей. Давайте посмотрим на каждую из этих возможностей через призму стратегии и USP.

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

Точно так же с точки зрения стратегии решения для управления устройствами разработчик технического обмана должен учитывать требования управления жизненным циклом устройства, управления и контроля, мониторинга, аудита и обновлений прошивки на. В этом контексте лицо, принимающее решение, должно учитывать не только стандартные протоколы, такие как LWM2M и OMADM, но и контекстно-зависимые протоколы, которые могут быть OPC-UA, Profinet, Modbus и Hart и т. Д. Однако с точки зрения USP новатор мало что может использовать функции управления подключением или устройством.

Платформы приема и хранения данных не привыкли сталкиваться с проблемами неоднородности, меняющимися стандартами и требованиями обеспечения масштабируемости с правильным уровнем безопасности. С точки зрения стратегии решения, выбор правильного протокола из https, MQTT, CoAP, AMQP и т. Д. Является одним из ключевых решений. Обычно большинство платформ предлагают поддержку вышеперечисленных протоколов, но решение здесь принимают реклама и простота интеграции. Например, некоторые платформы предоставляют набор библиотек для обеспечения связи, что требует затрат времени и усилий на разработку, с другой стороны, другие предлагают настройку на основе конфигурации с низким кодом / малым касанием.

С точки зрения доступности решения мы видим три подхода. Во-первых, брокеры приема данных и платформы хранения являются частью пакета, предлагаемого поставщиками сквозных горизонтальных облачных платформ, такими как AWS . &Лазурь. Это попытка упростить сложность настройки и управления инфраструктурой, масштабируемости, высокой доступности и т. Д. Альтернативным решением является покупка полностью продуктовых платформ, таких как C3IoT, Software AG, PTC . Под продуктом мы понимаем стандартные производственные требования, касающиеся администрирования, эксплуатации, аудита, интеграции и пользовательского интерфейса.

Типичный третий вариант - это создание с использованием решений с открытым исходным кодом, таких как Rabbitmq, Eclipse Mosquito и т. Д. В целом, большинство игроков PaaS и SaaS имеют аналогичные предложения в этой области, и типичные соображения при выборе - масштабирование, коммерческое, эксплуатационное и текущее обслуживание и поддержка. Мы не рассматриваем эту часть решения в качестве сильного кандидата для создания какого-либо ключевого дифференциатора или УТП, кроме того, с множеством доступных решений мы ожидаем, что эта часть цепочки создания стоимости останется конкурентоспособной и, следовательно, имеет небольшую вероятность того, что PaaS или SaaS злоупотребят рыночной властью. . В конце концов, мы можем отметить это как конкурентное и коммерческое пространство, где предпочтительным способом разработки является PaaS или SaaS.

Платформы поддержки приложений и аналитические платформы также могут быть отнесены к категории горизонтальных платформ. Эти платформы позволяют вашему решению обрабатывать входящие данные в режиме реального времени или пакетно / по расписанию. Это отличается от платформы приема данных, поскольку здесь не все платформы имеют одинаковые возможности. Как лицо, принимающее технические решения, обычно оценивают возможности выполнения аналитики и машинного обучения, разработки приложений визуализации и возможностей хостинга. Расширяемость за счет интеграции и вызовов API - еще один аспект рассмотрения. Эта интеграция может осуществляться со средами, которые являются монолитными или основанными на микросервисах, облачными или локальными.

Некоторые из этих решений также проникают в пространство Edge, особенно для пограничной аналитики. Как только лицо, принимающее решение, узнает требования с точки зрения вышеуказанных измерений, он снова может взглянуть на одно из трех вариантов PaaS-предложений из Azure и AWS или сборки на основе открытого исходного кода. Учитывая, что потребность в периферийных или туманных вычислениях быстро растет и считается наиболее растущей областью, разработчику решения также почти обязательно иметь четкую стратегию Edge. В Edge space можно было бы взглянуть на решения вроде Intel Чипсеты и периферийные устройства на базе Movidius от Dell с точки зрения оборудования и Azure IoT Edge, AWS IoT Greengrass, периферийное устройство Software AG с точки зрения программного обеспечения. В области аналитики и приложений, следуя третьему подходу к построению, необходимо объединить такие технологии, как Kaa, HDFS, Kafka, Nifi, Mongo DB, Nginx и т. Д., Чтобы создать надежное решение IoT.

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

Следующими на очереди идут специальные приложения Vertical. Разработчики решений обычно вызывают различные функции из приведенного выше каталога платформ IoT, чтобы построить конец приложения. Например, приложение может быть разработано в среде, предоставляемой платформой поддержки приложений, путем сбора данных с платформы приема данных и последующей разработки визуализации на основе тенденций и аналитических данных, полученных с помощью платформ аналитики. Это когда понимание, полученное в результате этого сквозного сшивания экосистемы на основе контекста, решает проблему, тогда становится известно, что ценность была создана, и тем самым вооружает решение сильным УТП.

Это область, которая требует изучения с помощью относительно более крупной бизнес-линзы. Лица, принимающие решения, должны оценить, является ли приложение ценным, редким, несовершенно имитируемым и незаменимым. С точки зрения рыночной структуры, это область, где можно определить свой собственный рынок и получить монополию, поэтому создание с нуля, возможно, с использованием среды с открытым исходным кодом, является предпочтительным подходом. Кроме того, с точки зрения бизнеса, мы ожидаем, что клиенты будут оставаться в этом пространстве, поэтому время здесь имеет большое значение, и чем раньше можно будет выйти на рынок с выбранным решением, тем выше шансы использовать УТП для масштабирования.

В целом, с точки зрения разработки USP, наиболее подходящим кандидатом кажутся вертикальные приложения с настраиваемой аналитикой. С точки зрения стратегии решения платформы IoT, хотя мы дали рекомендации по PaaS или SaaS для приема данных, PaaS для приложений и аналитики и сборки на основе открытого исходного кода для конкретных вертикальных приложений, но мы ценим огромную важность контекста, который определяет все решения. Если контекст требует быстрого вывода продукта на рынок при поддержке специализированных исследований и разработок:Saas может стать оптимальным решением. Следовательно, все вышеперечисленные факторы можно использовать в качестве общих рекомендаций, но для каждого варианта использования потребуется свое собственное жюри и свое собственное решение.

Авторами этого блога являются Арпит Хосла, основатель IoT Australia Consulting Services, и Пранит Такур, советник IoT Australia Consulting Services