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

    Привет!

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

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



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



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


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

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

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



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

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

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

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

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


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

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

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

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

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


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

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

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

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

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

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



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



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

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

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


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

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

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

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

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

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

      +3

      А что, кроме температуры "воздуха" планируется измерять?
      Вопрос к тому, что бигдата, IoT и прочий блокчейн легко меркнут по сложности перед необходимостью просверлить трубу с хотя бы водой, не говоря уже о каком-нибудь триэтилалюминии, чтобы поставить датчик давления, температуры среды или, упаси боже, расходомер.
      И цифровой аппраратчик, подключив n-нный не очень важный (важные поставили при строительстве и включили в АСУ) термометр, заскучает.

        0
        Вибрацию, загазованность, давление, расход, съем показаний со счетчиков и другие параметры.
        0
        Мы сделали платформу, которая может адекватно работать с любыми LoRaWAN-устройствами.


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

        Не верится просто в полноценный LoRaWAN сервер за такие сроки. Понятно, что с ресурсами СИБУРа можно нанять толковых людей. Но все равно вдевятером за месяц не родить…
          0

          А что такого сложного в этой сети, что нельзя за месяц запилить прототип работающий?

            0
            Прототип можно и быстрее. Тут-то речь не про прототип.
              0

              Я может не совсем корректно выразился. Это уже не прототип но ещё и не совсем боевая система. Ну т. е. За неделю выкатили прототип, за три создали готовое решение. Внедрили в опытную эксплуатацию. Чем именно эти протоколы и сервера отличаются от других. Что может так повлиять на скорость разработки? Вроде бы промышленный стандарт, а там обычно "палка-верёвка". Они же ПО пилят, а не готовые устройства? А ПО таки за месяц с хорошим штатом можно разработать.

                0
                Люди готовятся ее продавать на сторону, замахиваются на ЖКХ, и «адекватно работать с любыми LoRaWAN-устройствами». Что ж тогда боевая система, если не это?

                Писать софт, не имея возможности проверить его на живых устройствах в сети хоть сколько-нибудь реалистичного размера, не выйдет. Т.е. написать-то можно, но в жизни потом может быть много дорогостоящей боли. И это не специфика LoRaWAN. C ZigBee и всякими там отечественными RF случается то же самое. Много лет получал деньги за устранение этой самой боли.

                Конкретно про LoRaWAN на Хабре Interfer много писал. Про практику внедрения. Почитайте, я вряд ли кратко в одном комментарии все перескажу. Притом, при всем уважении, у них сеть относительно небольшая и не плотная. Когда последний раз интересовался, 9K устройств по двум областям размазано. У меня сейчас очередной пилот, 3.6K, на нескольких десятках гектаров при очень небольшом (единицы) количестве БС. Правда, страна совсем другая, с другой регуляторикой и большим числом каналов, так что все проще. Но, боюсь, сервер, проверенный с десятью устройствами на столе у разработчика, тут бы не подошел.
                  0

                  За наводку спасибо. Ну вы сами описали. ЖКХ и открытые поля, это диаметрально разные задачи. А в чем трудность работать с разными устройствами? Я не могу понять на какой стадии можно ожидать проблем. Это приём данных от устройств или агрегация этих данных? Вроде бы этот протокол должен быть простым радио модемом. Даже то что вы привели в пример 9к устройств, они же не разом передают. Как раз есть оркестратор, который спрашивает каждое устройство. И ещё момент, с какой периодичностью это все Передаётся? Одно дело опросить 9к за час, другое дело за секунду.

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

                    Работу по опросу в LoRaWAN всерьез рассматривать не стоит. Тому масса причин, опять же, у Interfer про это вроде бы расписано в красках, не буду повторяться.
                      0

                      Про протокол немного читал. Да вижу узкие места. Но вот если вы говорите про нелицензируемый канал, получается ещё печальнее. Хорошо если разраб придерживается неких правил и/или протоколов. Но у него то могут быть свои протоколы, и забивать канал полностью. На сколько я помню, классического опроса там и нет. Есть попытка устройства связаться и получить следующее окно для передачи. А как такое решается? Синхронизация времени.

                        0
                        Работа на нелицензируемых частотах это одна из главных фишек LoRaWAN. На лицензируемых она особо никому не нужна. Semtech пытался втюхать LoRa-модуляцию сотовикам вместо того, что потом стало NB-IoT. Не вышло, вложились в LoRaWAN.

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

                        Но в целом, наверное, становится понятно, что проблем на пути чуть больше, чем кажется на первый взгляд? И решать их в значительной степени приходится в софте, плюс по мере поступления, накопления практики, из общих соображений мелкие подлые грабли предугадать трудно. Вот поэтому сроки и вызвали у меня некоторые сомнения.
                    0
                    hobogene, спасибо, что упомянули и привлекли мое внимание к статье)

                    Я бы с удовольствием почитал про ваш опыт. Не думали тоже выложить что-нибудь на хабре?
                      0
                      Вам спасибо за то, что есть, что упоминать. Не такое частое явление пока в мире IoT вообще и LoRaWAN в частности.

                      Думал и думаю, но тут, с одной стороны, надо, чтобы никто из подопытных себя не узнал, не пострадал и не обиделся, опыт-то наживался с боями. А с другой, не хотелось бы написать что-то вроде газетной статьи эпохи шпиономании про майора М., командира Н-ской части. Будет, может, и полезно, но неубедительно.
              0
              А мы и не делали сетевой сервер сами. У нас Brocaar. К нему просто написана обвязка для интеграции в нашу платформу. А сама «IIoT-платформа» состоит не только из сетевого сервера. Там и бэк, и фронт, и хранилище.
                0
                В смысле, Chirpstack. Из статьи-то выглядит, что сами все писали. Тогда понятно. Ну, допиливать там для реальной жизни много.

                Про состав платформы я понял, я вполне внимательно прочитал пост.
                  0
                  Оформление прав на интеллектуальную собственность, наверное, выглядело забавно.
                0
                Oops, промахнулся, комментарий перенесен по адресу.
                  0
                  А какие системы рассматривали до написания своей?
                    0
                    стеку технологий, принятых в SIBUR Digital.

                    А какой стек используется?
                      0
                      Бэк на Python, фронт JS React.
                      0
                      Датчик у нас добавляется в платформу в три клика.

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

                      Скажите пожалуйста, реализована ли как-то защита от:
                      1. Кривых рук при замене датчика
                      2. откровенного вредительства или диверсии с подменой датчика
                      3. Безопасная передача данных/управляющих сигналов (против того же вредительства)
                        0
                        Я правильно понимаю, что ваши датчики передают только один-два параметра? Преимущественно температуру? Я имею ввиду не всю систему, а именно конкретный датчик?

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

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