Групповой отчет по неисправностям ДУТ

Есть один из стандартных подходов, в виолоне вы его по сути всегда используете при создании датчика. Паттерн проектирование Адаптер  ( https://ru.wikipedia.org/wiki/Адаптер_( … тирования) , https://refactoring.guru/ru/design-patt … va/example ) На вики очень размыто, по второй ссылке ява, но по комментарием к примеру суть подхода раскроется для любого технаря. Можно не читать
По сути.
Для реализации вам нужны правила по которым система будит решать дут исправен или нет, как минимум я вижу 2 датчика (форма описания датчика <имя датчика>:<параметр>:[<тарированная таблица, где {Х:A:B}>]):
1. ДУТ_N_0:rs485_fls02:[{0:0:1}{1:0:0}] - единица, если на параметре 0, суда же можно добавить верхнюю границу и отфильтровать по напряжению (фильтровать лучше не по 0, а по суммированию цифрового датчика в состоянии включено если напряжение ниже рабочего напряжения ДУТ), если хотите.
2. ДУТ_ЗАВИС:rs485_fls02-#rs485_fls02:[{-1:0:0}{0:0:1}{1:0:0}] - валидируем через перемножение(или неравенства 0, тут нужен тест) по датчику стоянки(СТОЯНКА:speed:[{0,0,1}{1,0,0}]) - получаем датчик который будит активироваться, если объект движется, а топливо не меняет свой уровень, необходимость тесто опишу ниже.
В целом суть адаптера тут проявляется следующим образом, все диагностические датчики названы одинаковы, но внутри датчика происходит адаптирование(ну или магия) данных к необходимому виду. В итоге мы получаем 20 объектов, по котором уже сейчас можно настроить шаблон отчета по группе объектов таблица цифровой датчик с маской датчика ДУТ_N_0 и ДУТ_ЗАВИС. Но не кто вам не мешает сделать цифровой датчик СТАТУС_ДУТ:[ДУТ_N_0]+[ДУТ_ЗАВИС]:[] тогда вы получите один датчик который будит сигнализировать о неисправности дут, а в него уже добавить сколь угодно диагностических датчиков.
п.с. Если неисправность это 1 (вы же именно неисправность ищите?) то диагностические датчики необходимо суммировать, любое значение выше 0 будит считается его включением. А если неисправность это 0, то датчики необходимо между собой перемножать, тогда если хотя бы один из датчиков 0 то и результат равен 0.
Сноска: Необходимость теста типа валидации по датчику, диагностирующий зависание, необходимо, потому что при суммировании ДУТ_N_0 и ДУТ_ЗАВИС результат будит получен, если оба датчика валидны, но с другой стороны логично указать тип валидации "проверка на 0", и в первом, и во втором случаи. Только имейете ввиду что ваш диагностический датчик статуса ДУТ будит передавать, что значение неизвестно.
П.С. 2: Вы можете вывести СТАТУС_ДУТ в панели мониторинга в качестве состояния датчика предварительно указать его раскраску и текстовую расшифровку значения.
П.С. 3: Спасибо за вопрос, надо клиентом, которые отслеживают неисправность оборудования настроить подобный отчет

Если вы хотите просто понимать, что данные от ДУТ перестали поступать или зависли - это одно. Данные вещи легко реализовать, выше написано как.
При условии, что сам ДУТ присылает коды ошибок, все также элементарно.

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