Привет.
Прошу не считать этот топик претензией. Я прекрасно понимаю, что эксплуатация опенсорсного софта подразумевает в изрядной степени риски пользователя, нежели полную ответственность авторов.
Также, если вопросы ниже будут ощущаться как попытка дискредитировать проект (чего я максимально тщательно постараюсь избежать), удалите этот топик: холиваров никому не надо.
И, наконец, примите мои извинения за занудство и многабукаф.
Я около полутора лет испытываю возможность промышленного (исключая реалтаймовые задачи, конечно) использования ВБ. Мне нравится гуманная цена линейки ваших продуктов. Мне нравится идеология софтовой начинки, которая с запасом вылетает за рамки стандартов МЭК прошлого тысячелетия: я за сутки могу построить на ВБ то, с чем бы иначе колупался долгими месяцами. В основном это простое и изящное сетевое взаимодействие. Мне нравится надежность железа: за все время скончались только три выноса WB-MGE, от атмосферной статики при грозе; более того, их материнки выглядят рабочими, выбило только китайские eth-to-serial субмодули. Вся остальная куча оборудования работает как часики. Это - прекрасно и достойно всяческих похвал.
Однако, помимо идеологии софта, нужна реализация. На данный момент, преодолев несколько десятков критических багов и подводных ежиков, я смог собрать относительно работоспособный тестовый узел. Чуть ниже объясню, почему относительно.
Любой ПЛК для промки представляет собой набор стейт-машин, состояние коих детерминированно в любой момент времени - в противном случае контроллер подлежит немедленной замене на исправный. Я встречал мнения, что в домашнем IoT (для чего, как я понимаю, ВБ разрабатывался изначально) достаточно модели IFTTT, которая предполагает не более чем реакцию на событие - нажал кнопку, свет включился. Однако, как старый САУшник и старый разработчик контроллеров, я никак не могу согласиться с этим. Если пользователь не способен точно знать состояния управляемого ПЛК прибора, он автоматически навлекает на себя риск пожара (отопитель, котел), потопа (водоснабжение) или, в лучшем случае, перерасхода энергии (тот же отопитель, кондей, освещение итд).
Состояние контроллера и присоединенной к нему периферии обязано быть жестко определено в любой момент времени. Если это невозможно (сбой железа или связи), оператор (владелец квартиры или диспетчер сети) обязан получить немедленное оповещение об аварии и вмешаться по возможности прежде, чем что-то бабахнет.
Таким образом, разница между “домашним” и промышленным применением контроллеров практически равна нулю. Да, для промки нужна более производительная техника (впрочем, мозгов ВБ с запасом хватает для львиной доли приложений) и реалтайм в особых случаях (но помилуйте, ВБ стОит на порядок дешевле того же Симатика, а Сименс десятилетиями вылизывал реалтайм).
Так вот. К сожалению, построить работоспособную стейт-машину на ВБ пока нельзя.
Из коробки набор софта упичкан всевозможными вочдогами, которые передергивают любой демон при подозрении на его “зависание” - я долго ругался тут с авторами и в итоге, плюнув, написал скрипт для первичной настройки контроллера, оставляющий только вочдог по зависанию железа (пока он, к чести разработчиков, не выстрелил на моем оборудовании ни разу). И начал ковырять причины, почему эти вочдоги были прикостылены вообще.
mosquitto. При падении связи с соседним брокером (у меня это серверы телеметрии, скада, подчиненные и головные контроллеры в распределенных системах) демон в какой-то момент начинает раздувать файл базы на диске и затыкается. Разумеется, рестарт не дает какого-либо положительного эффекта: в попытке прожевать этот файл демон снова виснет.
Костыльное решение: при превышении таймаута на старт mosquitto не просто передергивать демон, а грохать базу и затем передергивать демон. Костыльное решение 2: persistence = false. В обоих случаях вся информация о состоянии контролов идет лесом. Нормальное решение: отсутствует.
wb-rules. В какой-то неопределенный момент времени (у меня - от недели до трех аптайма) демон просто молча падает. Я нашел еще один, совсем уж потайной, вочдог, который передергивает wb-rules, если давно не получает от него свежее значение аптайма! No comment. Естественно, любое состояние скрипта в любой момент времени может быть сброшено (на чем я и обнаружил сию фатальную багу), а это категорически предотвращает написание работоспособной стейт-машины: даже если постоянно писать состояние в persistent storage, нет никакой гарантии, что wb-rules не осыпался в промежутке между записями, успев что-то в(ы)ключить.
Решение: отсутствует.
systemd/init. Последовательность старта демонов не определена, поэтому, строго говоря, переменные в скриптах, а также исполнительные устройства (!) могут получать на старте отфонарные значения, либо из сохраненных в базе mosquitto, либо по факту опроса входов, ну либо как повезет.
Костыльное решение: силовым методом на старте инитить переменные константами. Не спасет от кратковременных непредсказуемых состояний выходов. Нормальное решение: упорядочить запуск демонов, разрисовать и документировать систему их взаимодействия. Пока не сделано.
Получается, использовать ВБ как контроллер нельзя, кроме как для приложений IFTTT, которые могут теоретически не заметить рестарта управляющих скриптов. (А могут и заметить, я набредал на ветки о спорадических глюках.)
Что же делать? Как пользователи опенсорса, т.е. фактически энтузиасты, мы не имеем морального права форсить авторов на срочное решение изложенных выше проблем. Как покупатели оборудования, мы таки хотим, чтобы оно работало.
Я для себя вижу несколько путей. Прошу делиться соображениями тех, кому это также актуально.
- Уйти от ВБ, закупать классические ПЛК. (Не хочу, ибо идея ВБ таки очень хороша. Плюс, на закуп и установку ВБ потрачены уже вполне весомые суммы.)
- Влиться в разработку в качестве программиста. (Лично для меня малореально по дикой нехватке времени.)
- Писать скрипты на сях и компилировать в бинарник, отключив wb-rules. (Но что делать с москитой? И, главное, что скажут инженеры, которые будут эти шедевры эксплуатировать после нас?!)
- Натянуть на ВБ вместо родного софта нечто вроде openPLC. (И низвести хороший контроллер до статуса малинки под шапкой с релюшками, которой на алике трёшник красная цена…)
- Натянуть openPLC, оснастив его драйвером MQTT, на имеющуюся систему: можно грохнуть несколько зайцев кряду - совместимость с МЭК языками для староверов и одновременно с сетевой архитектурой, которая мне так нравится. (Но время, время же… И москита.)
Мнения, коллеги?
