Comments 23
UFO just landed and posted this here
Мы сделали платформу, которая может адекватно работать с любыми LoRaWAN-устройствами.
А как вы в этом убеждались? И про любые устройства, и про адекватно работать? Если я правильно помню, в предыдущей статье шла речь про пару сотен устройств. Большой сетью не назвать… На каком количестве базовых станций и устройств макс. пробовали все это?
Не верится просто в полноценный LoRaWAN сервер за такие сроки. Понятно, что с ресурсами СИБУРа можно нанять толковых людей. Но все равно вдевятером за месяц не родить…
UFO just landed and posted this here
Прототип можно и быстрее. Тут-то речь не про прототип.
UFO just landed and posted this here
Люди готовятся ее продавать на сторону, замахиваются на ЖКХ, и «адекватно работать с любыми LoRaWAN-устройствами». Что ж тогда боевая система, если не это?
Писать софт, не имея возможности проверить его на живых устройствах в сети хоть сколько-нибудь реалистичного размера, не выйдет. Т.е. написать-то можно, но в жизни потом может быть много дорогостоящей боли. И это не специфика LoRaWAN. C ZigBee и всякими там отечественными RF случается то же самое. Много лет получал деньги за устранение этой самой боли.
Конкретно про LoRaWAN на Хабре Interfer много писал. Про практику внедрения. Почитайте, я вряд ли кратко в одном комментарии все перескажу. Притом, при всем уважении, у них сеть относительно небольшая и не плотная. Когда последний раз интересовался, 9K устройств по двум областям размазано. У меня сейчас очередной пилот, 3.6K, на нескольких десятках гектаров при очень небольшом (единицы) количестве БС. Правда, страна совсем другая, с другой регуляторикой и большим числом каналов, так что все проще. Но, боюсь, сервер, проверенный с десятью устройствами на столе у разработчика, тут бы не подошел.
Писать софт, не имея возможности проверить его на живых устройствах в сети хоть сколько-нибудь реалистичного размера, не выйдет. Т.е. написать-то можно, но в жизни потом может быть много дорогостоящей боли. И это не специфика LoRaWAN. C ZigBee и всякими там отечественными RF случается то же самое. Много лет получал деньги за устранение этой самой боли.
Конкретно про LoRaWAN на Хабре Interfer много писал. Про практику внедрения. Почитайте, я вряд ли кратко в одном комментарии все перескажу. Притом, при всем уважении, у них сеть относительно небольшая и не плотная. Когда последний раз интересовался, 9K устройств по двум областям размазано. У меня сейчас очередной пилот, 3.6K, на нескольких десятках гектаров при очень небольшом (единицы) количестве БС. Правда, страна совсем другая, с другой регуляторикой и большим числом каналов, так что все проще. Но, боюсь, сервер, проверенный с десятью устройствами на столе у разработчика, тут бы не подошел.
UFO just landed and posted this here
Проблемы именно со связью. С масштабированием. Эфир — узкое место. Протокол тут посложнее, чем «просто радиомодем». Ну и представьте, что в случае с «просто радиомодемом» рядом такой же радиолюбитель на тех же частотах по тому же протоколу занимается тем же самым. Диапазон-то нелицензируемый.
Работу по опросу в LoRaWAN всерьез рассматривать не стоит. Тому масса причин, опять же, у Interfer про это вроде бы расписано в красках, не буду повторяться.
Работу по опросу в LoRaWAN всерьез рассматривать не стоит. Тому масса причин, опять же, у Interfer про это вроде бы расписано в красках, не буду повторяться.
UFO just landed and posted this here
Работа на нелицензируемых частотах это одна из главных фишек LoRaWAN. На лицензируемых она особо никому не нужна. Semtech пытался втюхать LoRa-модуляцию сотовикам вместо того, что потом стало NB-IoT. Не вышло, вложились в LoRaWAN.
Каналы у нас уже начинают забивать любители гонять DLMS всякий на электросчетчики по LoRaWAN, больше одной реализации знаю. К счастью, работает фигово, может, надоест людям.
Но в целом, наверное, становится понятно, что проблем на пути чуть больше, чем кажется на первый взгляд? И решать их в значительной степени приходится в софте, плюс по мере поступления, накопления практики, из общих соображений мелкие подлые грабли предугадать трудно. Вот поэтому сроки и вызвали у меня некоторые сомнения.
Каналы у нас уже начинают забивать любители гонять DLMS всякий на электросчетчики по LoRaWAN, больше одной реализации знаю. К счастью, работает фигово, может, надоест людям.
Но в целом, наверное, становится понятно, что проблем на пути чуть больше, чем кажется на первый взгляд? И решать их в значительной степени приходится в софте, плюс по мере поступления, накопления практики, из общих соображений мелкие подлые грабли предугадать трудно. Вот поэтому сроки и вызвали у меня некоторые сомнения.
hobogene, спасибо, что упомянули и привлекли мое внимание к статье)
Я бы с удовольствием почитал про ваш опыт. Не думали тоже выложить что-нибудь на хабре?
Я бы с удовольствием почитал про ваш опыт. Не думали тоже выложить что-нибудь на хабре?
Вам спасибо за то, что есть, что упоминать. Не такое частое явление пока в мире IoT вообще и LoRaWAN в частности.
Думал и думаю, но тут, с одной стороны, надо, чтобы никто из подопытных себя не узнал, не пострадал и не обиделся, опыт-то наживался с боями. А с другой, не хотелось бы написать что-то вроде газетной статьи эпохи шпиономании про майора М., командира Н-ской части. Будет, может, и полезно, но неубедительно.
Думал и думаю, но тут, с одной стороны, надо, чтобы никто из подопытных себя не узнал, не пострадал и не обиделся, опыт-то наживался с боями. А с другой, не хотелось бы написать что-то вроде газетной статьи эпохи шпиономании про майора М., командира Н-ской части. Будет, может, и полезно, но неубедительно.
А мы и не делали сетевой сервер сами. У нас Brocaar. К нему просто написана обвязка для интеграции в нашу платформу. А сама «IIoT-платформа» состоит не только из сетевого сервера. Там и бэк, и фронт, и хранилище.
Oops, промахнулся, комментарий перенесен по адресу.
А какие системы рассматривали до написания своей?
стеку технологий, принятых в SIBUR Digital.
А какой стек используется?
Датчик у нас добавляется в платформу в три клика.
На таком производстве датчики и их показания могут очень сильно влиять на работу различных систем и механизмов вплоть до печальных последствий.
Скажите пожалуйста, реализована ли как-то защита от:
1. Кривых рук при замене датчика
2. откровенного вредительства или диверсии с подменой датчика
3. Безопасная передача данных/управляющих сигналов (против того же вредительства)
Я правильно понимаю, что ваши датчики передают только один-два параметра? Преимущественно температуру? Я имею ввиду не всю систему, а именно конкретный датчик?
Это все здорово, красивые графики и удобный интерфейс, но плохо понятно применение для такой системы. Обычно на производстве все ключевое оборудование уже обвязано датчиками, которые собирают данные в систему управления процессами и сбора данных SCADA. Потом по этим данным операторы или модель процесса управляет контроллерами для оптимизации производства. Чтобы приносить прибыль для компании, ваша IoT система в первую очередь должна быть интегрирована в SCADA, а затем уже создавать дополнительный функционал для аналитики.
Основная идея в том что 90% аналитики на производстве основаны на физических симуляциях, и человеческий анализ, или даже машинное обучение не могут предоставить хорошую предсказательную способность, особенно для сложных процессов, где сотни датчиков. По-хорошему нужно создавать цифровые двойники и параметризировать их с датчиков. Это позволит рассчитывать ключевые характеристики процесса, которые невозможно измерить напрямую, например КПД компрессоров или степень загрязнения теплообменников. Далее, эта должна создаваться система для контроля процесса в реальном времени используя прогнозирующую модель.
Такие пакеты есть у Aspen и gProms.
Основная идея в том что 90% аналитики на производстве основаны на физических симуляциях, и человеческий анализ, или даже машинное обучение не могут предоставить хорошую предсказательную способность, особенно для сложных процессов, где сотни датчиков. По-хорошему нужно создавать цифровые двойники и параметризировать их с датчиков. Это позволит рассчитывать ключевые характеристики процесса, которые невозможно измерить напрямую, например КПД компрессоров или степень загрязнения теплообменников. Далее, эта должна создаваться система для контроля процесса в реальном времени используя прогнозирующую модель.
Такие пакеты есть у Aspen и gProms.
Sign up to leave a comment.
Когда написать свою IoT-платформу выгоднее, чем покупать готовую