1

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

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

У нас назрела необходимость создать отчет который помог бы нам и клиентам выявлять объекты в которых ДУТ работает не коректно или другими словами показания от датчика ДУТ отсутствуют.
Мы решили похожую задачу по неисправности основного оборудования - трекера с помощью отчета по потерям связи. Но анализировать исправность ДУТ пока не можем. Можете ли вы подсказать каким образом можно решить эту задачу, при условии что на разных объектах сигнал от ДУТ приходит в разных параметрах типа frec1, frec2, adc1, adc2 и т.д. Я пытался решить эту задачу индивидуально для каждой машины в виде графика, Но это не очень удобно. Может быть есть какой то способ или рекомендации как сделать такой ГРУППОВОЙ отчет по всем машинам клиента?

То что мы подняли - больше не падает!
Надежный бизнес - это про нас.
www.informbyuro.com
2

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

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

Есть один из стандартных подходов, в виолоне вы его по сути всегда используете при создании датчика. Паттерн проектирование Адаптер  ( https://ru.wikipedia.org/wiki/Адаптер_( … тирования) , https://refactoring.guru/ru/design-patt … va/example ) На вики очень размыто, по второй ссылке ява, но по комментарием к примеру суть подхода раскроется для любого технаря. Можно не читать smile
По сути.
Для реализации вам нужны правила по которым система будит решать дут исправен или нет, как минимум я вижу 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: Спасибо за вопрос, надо клиентом, которые отслеживают неисправность оборудования настроить подобный отчет wink

FFA0-0BBB-8911-15BB

https://www.reg.ru
3

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

(08/10/2019 12:43:25 отредактировано zark)

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

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

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

InformByuro пишет:

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

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

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

Потому я предложу альтернативу:
1) Создайте произвольный датчик "КОД ОШИБКИ" на основе выражения "constN".
Здесь N -- любое значение, которое параметр от ДУТ не сможет принять. Пусть в нашем примере это будет "100500", тогда в строке "Параметр" укажите "const100500".
2) Создайте произвольный цифровой датчик "ДУТ НЕ ШЛЁТ ЗНАЧЕНИЙ" на основе параметра от ДУТ, со следующей таблицей расчёта:
    X = 0; a = 0; b = 0
    X = 100500; a = 0; b = 1
3) В качестве валидатора для датчика "ДУТ НЕ ШЛЁТ ЗНАЧЕНИЙ" выберите датчик "КОД ОШИБКИ". Тип валидации "Заменять датчик валидатором в случае ошибки".
4) Создайте шаблон отчёта по группе объектов с таблицей "Цифровые датчики" (с необходимыми столбцами, группировкой и т.д.), в настройках укажите фильтр по маске (имени) датчика "ДУТ НЕ ШЛЁТ ЗНАЧЕНИЙ", и тогда в таблице будут отображаться все интервалы, когда ДУТ не присылал значений.

К сожалению, у вас не достаточно прав для просмотра данного текста

@ Oleg Zharkovsky
Customer Service / Quality Control and Training
"Timely is the best. But still better late than never."
4

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

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

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

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

5

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

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

Всем огромное спасибо, за ваши советы.
Вчера меня осенила идея и решил все быстро стандартными средствами, результатом доволен
1. Сделал на всех топливных машинах датчик произвольный DUT с таблицей пересчета в которой все что ниже, нижнего предела включая ноль это 1 все что в зоне валидных значений 0
2. Дальше сделал отчет для группы объектов. таблица  по "ТРАССИРОВКА ДАТЧИКА" в настройках в маске указал DUT, с таймаутом экспериментировал 60-240 минут, группировка по объектам, детализация не нужна

То что мы подняли - больше не падает!
Надежный бизнес - это про нас.
www.informbyuro.com