[10242] Добавить диагностику подстановки констант в часовых данных

Как то быстро Вы тему закрыли, хотя бы дней 5 дали на обсуждение, люди не каждый день заходят.
Вот начало Добавить в диагностику зависание расходомера
Закончили на


“Да, на закладке Датчики нужно указать какие датчики используются, иначе эта диагностика не выполняется.” - а какая связь между данными датчиков и срабатыванием нештатной ситуации на не меняющиеся данные от датчиков? Я к тому, что эти данные не все заполняют, за ненадобностью.

Далее. “Думаю, что часовые данные не показатель, так как расход может быть там маленький, на пределе погрешности.” - маленький или нет, не играет роли. Важно то, что расходомер не исправен и его нужно чинить. Я же на примере показал, что расход в час 0,33 м3 горячей воды - 330 литров в час (длилось 6 часов), а по факту расход нулевой. Но абонент должен заплатить за 1980 литров горячей воды.


Так, что я не считаю, что часовые не показатель.

Тоже не понимаю для чего необходимо заполнение датчиков в точке учета для диагностики подстановки констант

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

Ну можно разделить НС на Подстановку констант в суточном архиве и подстановку констант в часовом архиве.

Согласан с автором

В пояснении не увидел причину связи описания датчика и срабатыванием НС

В моих примерах - не константы. В моих примерах - это просто случайное значение расхода (V) на котором завис расходомер, ни как не связанное с уставками, константами, верхними и нижними пределами, базой данных и т.д.
Именно это я и пытался донести в первоначальном предложение (Добавить в диагностику зависание расходомера), в отслеживании повторяющегося (не меняющегося) часового значения.
Тогда получается не подходит подстановка констант для моего предложения, т.к. из описания следует “система проверяет, что прибор возвращает уставку вместо реального значения.” То есть, если вычислитель начал подставлять уставки ( указанные в закладке Датчики), в течении 3 дней, то тогда система выдает нештатку. Так?

Судя по времени суток - это больше похоже на то, что у расходомера сбился нуль, если Вы уверены, что дело именно в отказе расходомере. Для контроля такого поведения оборудования есть НС “утечки или ночной расход”. Хотя, Вы показали, только 1 пример, но в этом примере - это выглядит как обычный “уход нуля”.

То, что я написал, не отменяет потребности в диагностике констант часовых, но для часового потребления в теплоснабжении нельзя запустить полный аналог НС суточного контроля констант. На отоплении константы по массе и количестве теплоты в 2-3-4-5 часов не редкость.

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

Я всё-таки прошу сформулировать конкретные предложения, как описано здесь.

Пока эти темы похожи на сессию вопрос-ответ. Вы у меня спрашиваете “Почему вот так сделано”, я отвечаю.

Я понял за уставки. Спасибо. Теперь предложение.
Предлагаю в диагностику “Подстановка констант”:

  1. Добавить диагностику часовых констант, а так же возможность выбирать число часов повторяющихся значений (от 2 и далее).
  2. Отвязать эту функцию, от того задан датчик или нет. Ибо смысла в этом нет. А заполнять сотни не нужных (для кого-то) датчиков, ради функционирования этой диагностики, так скажем не рационально.

По пункту 2 поддерживаю. Но если это сделать “в лоб” - то по крайней мере у нас сразу по всем узлам возникнет НС, т.к. отсутствуют датчики давления и везде используются договорные значения. Если отвязывать диагностику от заполнения датчиков - нужно как-то решить этот вопрос. Можно как раз переделать логику на следующую: если в точке учета заполнены датчики давления - диагностика подстановки констант производится в т.ч. по давлению. Иначе только температура и расход.
Это естественно касается только систем теплоснабжения/ГВС.

Тогда можно добавить еще выбор датчиков (т1, т2, р1, р2, V1, V2)

Странно. Как я и описывал выше, в вашем случае диагностика подстановки констант нужна только там, где стоят датчики, но отвязку вы поддерживаете.

Честно говоря, по результатам обсуждения я склоняюсь к тому, что привязка к датчикам должна остаться. Я не согласен с тем, что это “ненужная” информация. Для полноценной работы система должна знать физическую картину вашего объекта. А чтобы это сделать, помимо устройства для сбора данных нужно знать и какие первичные датчики установлены.

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

Новый пример. Это холодная вода. Прибор прописал. Но НС нет (видимо нет 3 суток подряд). Прикрепляю суточные и часовые.


[quote=“Антон Чичков, post:11, topic:14842, username:achi”]
Честно говоря, по результатам обсуждения я склоняюсь к тому, что привязка к датчикам должна остаться. Я не согласен с тем, что это “ненужная” информация. Для полноценной работы система должна знать физическую картину вашего объекта. А чтобы это сделать, помимо устройства для сбора данных нужно знать и какие первичные датчики установлены.
[/quote] Чтобы знать физическую картину, при добавлении точки прописываются: вид системы и количество трубопроводов, то есть понятно, что на любой системе будет расходомер, на отплении и ГВС термометры. Вопрос только с датчиками давления.


Ну допустим без заведения датчиков никак. Тогда хотя бы упростить нужно это дело. А именно, заведение датчика не может быть завершено без: указания серийного номера и варианта исполнения. Хотелось бы ограничиться заведением модели датчика, чтобы система “видела” физическую картину. Я так думаю, что серийный номер и вариант исполнения не влияют на подстановку констант.

Слишком усложнит настройку.

Но чтобы избежать этого:

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

И обязательно добавить настройку в групповые операции

так это уже предлагал:

Но пишут, что без датчиков никак

Проблема с вкладкой “датчики” в том, что там обязательно необходимо указать модель, серийный номер, вариант исполнения. У нас есть множество узлов, где датчики давления реально есть, но нет информации об их серийных номерах. Заполнять с фиктивными серийниками тоже не хочется чтобы потом путаницы не возникло.
Поэтому тоже считаю необходимым добавить настройку с тремя галочками “производить диагностику подстановки констант по:” Температуре/Расходу/Давлению

@saner22, про диагностику подстановки в часовом архиве я уже писал, что согласен с тем, что она должна появиться. Мы запланировали эту функцию в версии 3.47, и она в неё уже включена.

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

По поводу настройки датчиков пока простого решения нет. Добавлять параметры в диагностику сейчас не слишком простая задача из-за особенностей внутренней реализации.

Возможно, такую настройку стоит сделать глобальной для всего сервера, а не для каждой точки отдельно? Будет ли этого достаточно?

Имеется ввиду что мы в системных параметрах укажем для всех точек учета нужна ли нам диагностика допустим по давлению, верно?
Если да - то нас такое решение устроило бы, хотя я и не считаю такой подход правильным.

Не хорошее решение. В системе всегда есть узлы, где нужно контролировать константы, и где это не нужно. Т.е. есть узлы:

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

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

Сейчас именно так и сделано, только на закладке с датчиками.

Мне нужна пауза в этом вопросе. Я пока не вижу хорошего решения, которое обеспечит обратную совместимость и упростит настройку системы.