Когда написать свою IoT-платформу выгоднее, чем покупать готовую

Привет!

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

Платформа нужна для того, чтобы обеспечить управление устройствами IoT-сети всех уровней и съем данных с датчиков, хранение этой информации и её дальнейшую обработку. Да, на рынке сейчас достаточно подобных платформ, но они не готовы решать задачу «из коробки». Это или какие-то отдельные куски бэкенда, которые полезные и нам бы пригодились в работе, или такие же полезные куски фронтенда, но такого, чтобы все сразу и прямо из коробки — нету. Даже самая близкая к нашим потребностям платформа требовала довольно серьезного допиливания и найма в штат новых разработчиков исключительно под эти задачи.



Мы сели, посчитали total cost of ownership и другие плюсы и минусы использования ведущих платных платформ, сравнили это с возможностью пойти и написать свою платформу. И получилось, что сделать свою для нас — примерно в два раза дешевле, при этом платформа будет полностью соответствовать стеку технологий, принятых в SIBUR Digital.



Платформа и компоненты


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

Вторая немаловажная часть — backend. Именно он проводит все операции с данными, которые поступают с датчиков сети или от наших других систем.

И третья составляющая это хранилище данных. Мы используем разработанный в SIBUR Digital ресурс – Узел Корпоративных Данных. Наш Backend отправляет исторические данные с устройств IoT-сетей в корпоративное Big Data хранилище.



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

Frontend представляет собой удобный пользовательский интерфейс на single page application (веб-интерфейс), который доступен с любого корпоративного ПК.

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

Получается, что платформа состоит из сетевого сервера, бэкенда, хранилища данных и фронтенда. А теперь о её задачах.

Что будет делать такая платформа


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

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

Третья задача — администрирование. Это уже такая сервисная страница для обслуживающего персонала, которое поможет заниматься эксплуатацией сети оконечных устройств. Датчики, кроме собираемых данных об окружении или объектах, передают в том числе и собственную телеметрию, по которой можно отслеживать их состояние и работоспособность. Помогает обслуживающему персоналу вовремя заметить, что какой-то датчик отвалился, или батарейка скоро сядет, или ещё что.

И вот, вроде бы, описаны довольно очевидные вещи, ничего сверхъественного, верно? Но практика показывает, что всего этого в готовых решениях нет. Или одно, или другое.

Прокачал систему — прокачай человека


Мы хотим дать аппаратчику полноценный цифровой инструмент, по сути превратив его в “цифрового аппаратчика”. Такой рабочий довольно быстро прокачивает нужную экспертизу, получает level up и становится цифровым сотрудником. Что это значит для нас в разрезе разговора о платформе? А то, что мы в таком случае должны это предусмотреть, учесть, что такой аппаратчик, у которого на старте нет каких-то навыков программирования, все равно мог сам для себя создавать нужные интерфейсы, выводя необходимые именно для его работы данные.

Поэтому мы сделали редактор мнемосхем. Датчик у нас добавляется в платформу в три клика. Первый: подключил датчик к сети отсканировав QR-код. Вручную аппаратчику не приходится вбивать номера датчика, параметры сети или еще какие-то данные.

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

И, наконец, остается лишь взять этот датчик и разместить его на схеме, выбрав необходимые границы срабатывания (например, температуру (минимальную и максимальную).

И всё, выходит, в эти три шага человек создал себе интерфейс, с помощью которого будет дальше эксплуатировать систему.

Вот нагляднее на картинках.



Одна из главных функций платформы — вывод для персонала уведомлений и статусов. То есть сотрудник видит это всё примерно как список новых писем в почтовом клиенте, само собой, с разным приоритетом по цвету, в зависимости от критичности и необходимости среагировать как можно быстрее (красные события, желтые события). Пока не среагируешь на событие, оно будет напоминать о себе звуком и визуально. Снова и снова.



Такой простоты для конечного пользователя без навыков программирования в существующих платформах вообще нет. Оно, в принципе, понятно, ведь цель таких платформ — зарабатывание средств по модели time&material оплаты за доработки + фикс за использование самой платформы. Чем больше доработок требуется клиенту, тем лучше. Потому что любая хотелка такого клиента в плане “А добавьте нам вот это, а можно еще тут вывести что-то” это дополнительный источник заработка для интегратора. Увы, но пока это работает так.

Поэтому мы и сделали свою. Ушло на всё, кстати, погода, стартовали мы осенью 2018, а к весне 2019 основная функциональность была готова. Рассказываю я об этом только сейчас, а не год назад, ибо в 2019 была длинная история с оформлением прав интеллектуальной собственности на нашу платформу.

Будущее платформы


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

Во-вторых, мы можем предоставлять это как Platform as a Service. Мы уже прорабатываем продажи наших датчиков и софта для других компаний, которым это тоже интересно и которые пришли примерно к такому же выводу насчет существующих платных решений. Понятное дело, что большинство таких клиентов тоже из нефтегазовой отрасли, тут задачи и процессы не сильно отличаются, поэтому допиливать что-то придется совсем чуть-чуть. Если вообще придется.

В-третьих, не нефтегазом единым. Мы сделали платформу, которая может адекватно работать с любыми датчиками в LoRaWan-сети. То есть если у вас есть устройство, которое поддерживает открытые стандарты LoRa-альянса, то они смогут работать на нашей платформе. Поэтому здесь открываются возможности и для ЖКХ, и для сельского хозяйства, и для иных отраслей, где надо собирать данные с IoT-датчиков. Здесь уже, конечно, потребуются конкретные доработки под конкретный тип датчиков, да.

О дальнейшем развитии платформы буду писать. Если есть какие-то дополнительные вопросы, буду рад ответить.

Василий Ежов
владелец продукта IoT в СИБУРе
Источник: habr.ru