Переключение между межотопительным и отопительным режимами обычно требует времени, внимания и значительного ручного контроля, либо выполняется приблизительно, что в этот период затрудняет диагностику нештатных ситуаций.
Эта процедура явно требует автоматизации и упрощения. На мой взгляд, у ваших коллег этот вопрос уже практически решён.
Стоит добавить только дополнительный контроль наружной температуры, если такая возможность есть.
Алгоритм достаточно прост: программа либо автоматически, либо полуавтоматически переключает режимы. В полуавтоматическом режиме ПО уведомляет пользователя о потенциальной смене режима на объекте, и уже пользователь принимает окончательное решение. В любом случае ПО фиксирует причины перехода или предложения о переключении режима, что позволяет отслеживать логику работы системы.
Хотелось бы понять почему это требует столько времени и внимания? Обычно теплосети выдают дату, когда отопление будет остановлено, и достаточно сменить режим всех объектов групповой операцией. Или у вас какая-то другая процедура?
Так же я не совсем понимаю что именно настраивается на скриншоте. К сожалению, по нему я не могу понять что это за ПО, чтобы глянуть хотя бы документацию. Если я всё правильно понимаю, то это настройка одного конкретного объекта? То есть, эти критерии задаются для каждого объекта отдельно?
Мой ответ не касается одного региона, так как я наблюдаю, как это происходит в разных частях России. Часто это не одна конкретная дата, а период. Разные районы и объекты переходят на другой режим в разные дни. Более того, часть объектов может отключиться от отопления раньше, а часть — подключиться позже.
В таких условиях при переходах часто возникает хаос в диагностике. Либо персонал вообще не контролирует работу узлов в этот период, либо диагностика требует значительно больше времени и усилий. При этом люди, занимающиеся учётом, не всегда связаны напрямую с режимами теплоснабжения и видят изменения только постфактум.
В результате переход на зимний или летний режим, по моим наблюдениям, часто происходит примерно через неделю после фактического перехода. После пеерхода закрывают все НС, чтобы убрать накопившийся “мусор” в НС
Текущий способ перехода часто создает неопределённость в эксплуатации узлов учёта в период перхода и снижает доверие к системе диагностики в ЛЭРС Учёте.
Кроме того, сейчас мы начинаем привязывать отчёты о потреблении к режимам, чтобы разделять условия дорасчётов. Поэтому важно переключать режим для каждого объекта точно в день перехода.
Скриншоту более 5 лет, он из Взлёт ИИС.
Я вижу это как настройку в каждом объекте для диагностики с возможностью изменения групповой операцией. Уникальность настроек здесь не приветствуется, но допускается, что она может понадобиться.
Похоже, проблема в этом. Если они занимаются учётом, как они могут не знать о режимах?
Не согласен с этим утверждением. Если система эксплуатируется неверно, она и выдаст неверные результаты.
Напомню, что сейчас должен работать перевод в летний режим “задним числом”. То есть, можно заранее групповой операцией перевести объекты в нужный режим и не беспокоиться о диагностике.
Кроме того, на скриншоте видно, что перевод выполняется если критерии выполняются в течение 3х дней. А значит на протяжении трёх дней тоже будет снижаться доверие к системе диагностики?
И какой вывод я должен сделать из вашего ответа? Обучать клиентов их работе? Требовать, чтобы их техпроцессы соответствовали требованиям ПО “ЛЭРС Учет”?
Учет и режимы – это часто зона ответственности разные должностей, и люди, занимающиеся учетом, не всегда погружены в точные даты смены режимов по объектам. Я наблюдаю картину, когда переключение может растянуться на 2 недели, а с учетом того, что кто-то может отключиться самостоятельно, переход с отопительного периода может и не укладываться в эти 2 недели.
Это же ветка предложений. Почему присутствует сочетание “эксплуатируется неверно”?
Все так. Но я писал о схеме, когда во время перехода в системах, эксплуатируемых УК и сервисными компаниями, переключение режима происходит позже, а вы пишете, что можно заранее перевести.
“Заранее” – это схема для другой вселенной. Чтобы переводить заранее, нужно быть уверенным во всех участниках этого процесса и в том, что переключение режима – это стабильный и нормальный процесс. А по факту это не так. Поэтому и нужны полуавтоматы, упрощающие жизнь персоналу.
Уведомит через три дня, когда уже сформированы ложные НС, которые вы хотите убрать, реализовав такой алгоритм. Я тут вижу, что мы ходим по замкнутому кругу. Я никак не могу себе собрать цельную картину как это улучшит систему.
Тогда зачем тут автоматизация? Как я вижу, мы можем в НС добавить признак режима, в котором она сформирована. И если после переключения видно, что НС сформирована для другого режима, она может автоматчиески быть помечена как ложная. И да, можно продумать повторную диагностику в этом случае. Эта идея мне нравится больше, чем автоматизация, так как мы можем лучше разобраться с исходной проблемой - ложными НС.
На мой взгляд, описанное вами и есть автоматизация.
ЛЭРС Учет самостоятельно определит объекты и выберет для них даты начала отопительного периода. Пользователь сможет парой кликов сменить режим сразу у всех объектов с выбранными границами режимов, а при необходимости, увидеть подробную информацию. После смены режима будет проведена повторная диагностика на наличие нештатных ситуаций (НС). Я бы не стал отмечать старые НС как ложные, а просто удалял их без следа. Мы же изменили режим, и результаты диагностики за дни, когда был установлен неверный режим, не имеют значения. Отметка НС как ложных создаёт дополнительную работу. По моему мнению, НС стоит просто удалять, так как пользователь сам санкционировал изменение режима. Если это важно, можно добавить предупреждение об удалении НС в окне подтверждения решения пользователя.
Если описанное выше соответствует вашему предложению – отлично!
Я бы хотел понять что вы имеете в виду здесь. Моё предложение я уже, как мне кажется, описал понятно, но попробую ещё раз показать сценарий,
Объект работает, например, в зимнем режиме. После того как отопление отключается, в зимнем режиме начинают формироваться ложные нештатные ситуации. ЛЭРС для каждой нештатной ситуации хранит в каком режиме работы объекта (лето или зима) она была зафиксирована.
Оператор видит, что количество нештатных ситуаций увеличилось, понимает, что, скорее всего, это связано со сменой режима.
После этого или индивидуально для объекта, или групповой операцией, которая уже существует, оператор изменять текущий режим работы задним числом. Система предлагает ему удалить сформированные с неверным режимом нештатные ситуации и провести диагностику повторно.
Если такой вариант устраивает, проведём анализ и посмотрим на какую версию сможем назначить реализацию.
