После длительных выходных стабильно срабатывает НС “Порывы” на объектах типа школ, садиков и т.п., где потребление в выходные и праздники минимально. Коэффициент подобран для типичного потребления и когда проходят 3-4 дневные выходные, высока вероятность срабатывания НС.
Предложение. Сделать возможность исключать из расчета среднего потребление выводные и праздничные дни. Т.е. пользователю дать возможность убрать из расчета: субботу, воскресенье и праздничные дни отдельно. Правда придется решить, как в ЛЭРС добавить производственный календарь.
Спасибо за предложение, действительно, в выходные дни имеет смысл делать отдельную диагностику утечек и порывов.
Мы попробуем добавить такую настройку для утечек и порывов в версии 3.55. Производственный календарь будет загружаться автоматически из общедоступного ресурса.
Пока флажок будет только для утечек и порывов, но предусмотрим возможность сделать её для любого типа диагностики.
Я бы предложил пойти чуть дальше. И задавать дни активного потребления из списка: дни недели, праздничные и перенесенные дни. По умолчанию выбрано все.
Настройка должны быть доступна через групповую операцию
С первым предложением я полностью согласен. Это простой и эффективный механизм, который позволит решить проблемы с 90% объектов с потреблением только в рабочие дни.
Но что это за список я сходу понять не могу. Что за дни недели? Выходные? Почему выходные отличаются от праздничных? Что это за перенесённые дни? Рабочие субботы, или дни, когда выходной перенесён с одного дня на другой? И почему важно отключать диагностику в такой день?
В открытых источниках нет такой информации, есть только список дат, которые в году являются выходными. Всё остальное придётся как-то рассчитывать, и не факт, что совпадут наши представления с вашими.
Фактически, вы хотите задавать собственный производственный календарь, но сколько объектов будут выбиваться из утверждённого календаря?
Нам надо соблюсти баланс между простотой настройки и реализации системы и её эффективностью. Поэтому, возможность отключить диагностику в праздничные дни по ПК я поставлю в план, но список делать пока не планирую.
К тому же, это реально в разы больше работы, и не особо понятно насколько это будет востребовано среди наших пользователей.
В дальнейшем можно будет добавить календари по объектам, но вводить его придётся вручную, и далеко не факт, что это кто-то будет делать.
Такая настройка позволит, например, настроить и те объекты, которые работают по субботам, либо заведения у которых понедельник нерабочий, и т.п. отраслевые неожиданности.
Потому, что выходные это не праздничные
Есть организации, которые игнорируют праздничные дни, и как следствие у них потребление зависит в основном от дня недели. В качестве примера, это некоторые высшие учебные заведения и некоторые детские садики, подстраивающие под пром.предприятия.
Это они и есть.
Вопрос не корректный. Я не обсуждаю конкретный объект.
Я предложил сделать гибкую настройку диагностики, которую можно будет подстроить и под экзотику отраслевых, промышленных и бюджетных организаций по стране. Подстройка связана, с тем, чтобы расчет среднего потребления считался только в дни реального потребления на объекте.
На прочие вопросы вроде как нет необходимости отвечать. Они вытекают из неверно понятого моего предложения.
Для таких “Отраслевых неожиданностей” нужно задавать собственный производственный календарь. Я по-прежнему против такой сложной настройки в общем случае. Повторюсь, нужен баланс между сложностью и функциональностью. Введение общего ПК решит проблему с большинством объектов. Для особых объектов потребуется задавать собственный ПК, но это нужно отложить до тех пор, пока такая функция вообще не будет добавлена.
В разных регионах нашей страны производственные календари отличаются. К примеру можете посмотреть ПК Республики Башкортостан - там будет еще несколько дополнительных праздничных дней в году.
Согласен с @Kvashnin - нужен достаточно гибкий инструмент.
А как предложение @kvashnin поможет в вашей ситуации? Что вы выберите из этого списка?
В вашем случае как раз стоит иметь возможность определить собственный ПК, и это можно продумать, но только после того, как ПК вообще появится в системе.
Антон. Это Вы написали про “собственный производственный календарь”. Придумали термин и дальше ведете беседу через это понятие. Но в моем предложении нет его. Я не просил возможности добавлять праздники и расширять производственный календарь, чтобы имело смысл говорить о “собственном производственном календаре”.
Более того, “собственный производственный календарь” – слишком громкий и неопределенный термин, не стоит его использовать в ПО, которое решает задачи уровня ЛЭРС Учета.
Ваше утверждение не верно. Все что я написал выше, касается расчета среднего потребления для определения НС “Порывы”. Выбирая дни, когда объект имеет типичное потребление, мы значительно уменьшим ложные срабатывания этой НС. Для нежилых объектов график потребления по дням недели может отличаться от схемы- типичное потребление только по рабочим дням. Чтобы обеспечить гибкость настройки я предложил позволить пользователю указывать дни типичного потребления для точек учета. Причем взять за основу производственный календарь, чтобы подтянуть праздничные и перенесенные дни к выделению.
Добавлю. Предлагаемые изменения остаются в рамках единого для страны ПК. В нем всегда явно выделены праздничные дни и дни, которые перенесены. Вот например для 2023 года.
Я “придумал” этот термин исходя из того какие задачи вы описали. Прочитайте сообщение от @7in, в котором он указывает, что для Башкирии ПК отличается от общероссийского. Кроме того, свои ПК используют Татарстан и, похоже, Крым. Уже как минимум видно, что должна быть возможность использовать несколько ПК. Как в этом случае вы видите эксплуатацию ЛЭРС в этих регионах с помощью вашего списка типичных дней потребления?
Далее. В ПК указывается какие дни являются праздничными, а какие выходными. Думаю, что это согласуется с вашим понятием “типичного потребления”. И если термин “собственный производственный календарь” для отдельного объекта мне понятен, то ваш список я до сих пор не могу осмыслить и представить себе как он должен выглядеть и как его реализовать. Возможно, в голове у вас это стройная и понятная система, но другим пользователям это может быть крайне неудобно.
К тому же, если ввести понятие собственного календаря, можно будет определить как он заполняется алгоритмически, то есть, указать, что тут рабочие дни с понедельника по субботу, и так далее. В общем, пока я не могу стопроценто сказать, что ваше предложение я понял и могу его поставить в план.
У меня нет сейчас задачи эксплуатировать ЛЭРС в этих регионах. И мне региональные праздники не создавали до сих пор проблему. Если нужно считаете нужным - обсуждайте их. Но к моему дополнению они не имеют прямого отношения. Праздники бывают 1 раз год и их действительно можно учесть “собственным производственным календарем”. А мое предложение, про потребление, привязанное к дням недели. И соответственно, я никак не вижу “эксплуатацию ЛЭРС в этих регионах” в рамках своего предложения
Ну зависимость есть, но не полная.
Попробую ещё раз на примерах.
3 объекта.
**1 объект - Ком.предприятие. ** В объекте есть сотрудники, когда работает компания. Компания не работает в субботу/воскресенье и не работает в праздничные/перенесенные дни. Когда компания не работает, сотрудников мало: охрана и дежурный персонал, потребление снижается сильно. И желательно сб. и вс. исключить из расчета среднего расхода, праздничные/перенесенные дни также стоит исключить из расчета.
Дни типичного потребления: пн, вт ср, чт, пт. Если праздничные/перенесенные дни, полученные из ПК, выпадают на период с пн по пт, то этот конкретный день тоже исключаем из расчета среднего расхода.
**2 объект - Средняя школа. ** В том же городе, на той же улице. Она не работает по воскресеньям и праздничным/перенесенным дням, а по субботам работает.
Для этого объекта дни типичного потребления: пн, вт ср, чт, пт, сб. С праздничными/перенесенным дням поступаем так же как и для 1 объекта.
3 объект - Рынок. В том же городе, на той же улице. Тот, с которого я списываю распорядок, не работает только по пн. и прочие дни работает. Праздничные/перенесенные дни игнорирует. Даже 1 января начинает работать в 13-14 часов.
Для этого объекта дни типичного потребления: вт ср, чт, пт, сб, вс. Праздничные/перенесенные дни игнорируем.
И все 3 объекта находятся в одной системе. Нужно при расчете среднего значения для целей диагностики учитывать, что для:
1 объекта средний расход считаем с пн по пт с учетом праздничных/перенесенных дней;
2 объекта средний расход считаем с пн по сб с учетом праздничных/перенесенных дней;
3 объекта средний расход считаем с вт по вс, праздничные/перенесенные дни игнорируем.
Как видите ПК нужен только чтобы учесть праздничные/перенесенные дни при определении нерабочих дней. И будет ПК федеральный, или “собственный производственный календарем” не важно.
Дмитрий, да всё понятно, но вам придётся вести вебинары, чтобы объяснить другим пользователям нашей системы как эти ваши флажки правильно настроить и скомбинировать Иначе ими никто пользоваться не будет.
Мы делаем систему общего назначения, а не заточенной под конкретно ваши задачи. И нам нужно, как я уже множество раз говорил, сделать баланс между сложностью и функциональностью.
Например, у меня всё ещё есть вопрос, если в примере со школой праздничный день выпадает на субботу, и переносится на понедельник, школа в эту субботу работает, или нет? Возможно, у директора на этот счёт есть своё мнение, и он поменяет режим работы, нам в таком случае придётся для этой школы делать ещё один флаг.
Я предлагал дать возможность определить собственный ПК, который необязательно заполнять вручную дата за датой. Можно определить правила его заполнения, похожие на то, что вы описывали. Но дать возможность его просмотреть и отредактировать если есть какие-то нюансы в работе.
В любом случае, всё сразу мы сделать не сможем, и для начала добавим хотя бы возможность исключить диагностику в праздничные и выходные по общероссийскому ПК. Дальнейшие шаги будем планировать исходя из подготовительных шагов.
У вас есть все чтобы сделать это просто и наглядно
Хм… “конкретно мои задачи”
Объекты типичные. Ситуация, если настраивать диагностику, тоже знакомая многим.
Я параллельно настраиваю сейчас диагностику в 3-ех системах разного назначения. Вижу сложности и шероховатости в этой части ПО. Ничего уникального или лично моего. Да я и примеры взял обычные.
Более того, очень много систем, где отключают НС Порывы или после праздников / выходных просто удаляют эти НС из-за ложных срабатываний. Последнее часто вижу, когда НС просто удаляют, “а то что они все красные”. А чтобы хранилась история НС – это вообще редкость, т.к. диагностика сейчас без регулярной подстройки и чистки – генерит ложные НС.
Так что блок диагностики у вас еще не нашел “баланс между сложностью и функциональностью” и недостаточно описан в документации.
Между описанием ситуации и выводом для меня нет прямой связи. Для настройки диагностики не важно, что решит в конкретном случае директор. Речь ведь идет об одном дне в году. И никто не будет ситуационно менять настройку диагностики. При этом 1 день не сильно именит картину.
Мое же предложение касается периодического недельного цикла. И его цель уменьшить ложное определение НС. Ну и далее, при необходимости, можно увеличить чувствительность этой НС, сменив значение 3, на меньшее.
Что касается примера.
Тут или у директора будет некая схема переноса, выраженная в приказе, тогда, при желании, уже может потребоваться что-то похожее на “собственный производственный календарь”. Но пока думаю можно и без нее. Причины выше.
Вот таблица, где я прикинул описанную вами ситуацию.
Вывод. 1 праздник, да еще перенесенный не меняет ситуацию, так чтобы было ложное НС, хотя уже видно, старый алгоритм в типичной для объекта ситуации насчитал превышение в 0,4 раза.
Вот из-за 4 ноября, в этом году было 4 выходных, было масса ложных срабатываний. В новый год и в мае уверен вообще беда с этой НС.
Антон. Вам стоит объяснить что значит “собственный ПК”. Возможно вопрос терминов, и не о чем дискутировать. Для меня ПК это год, где все дни размечены как рабочие/выходные/праздничные/перенесенные.
Задавать такое, на мой взгляд, трудоемко, не нужно и пользователи не будут задавать. Если “собственный ПК” - это размеченный недельный цикл, то я не возражаю. Но название, на мой взгляд, не подходящее.
Почему не сможете. Задача, вроде, не сложная. Бюджетные организации садики/школы/больницы и т.п. - это организации, которые чаще объединены в систему, чем иные объекты. У этих организаций есть план потребления по воде и наличие ответственных за это потребление. Они в первую очередь и являются потребителем диагностики про воду.
Появилась возможность исключить из диагностики выходные и праздничные дни по производственному календарю. Календарь пока один, общероссийский, дальнейшие шаги мы будем продумывать сейчас, при подготовке к версии 3.56. Коснулось только порывов.