В настоящий момент в журнале НС “Данные от устройства не получены” указывается дата и время получения последних данных при первичном обнаружении этой НС. Следующая запись в журнале НС содержит информацию либо о её закрытии, либо о повторном возникновении, если НС перестала быть активной и далее снова выполнилось условие её возникновения. Ниже представлены оба варианта НС:
Однако, в журнале не фиксируются события, подтверждающие наличие этой НС. При этом, для других НС подобные события регистрируются.
Кроме того, из журнала неясно, когда оператор или иной персонал получил уведомление об этой НС. В конкретной системе для разных объектов применяется разный период допустимого времени отсутствия связи.
Предложение: в журнале НС “Данные от устройства не получены” фиксировать все события, подтверждающие эту НС, а также дополнительно в каждой записи указывать дату и время фиксации НС программным обеспечением “ЛЭРС Учет”
Так сделано из-за того каким образом проводится эта диагностика. Почти для всех остальных типов диагностики можно выделить какой-то факт, когда она была зафиксирована. Например, для какого-нибудь рабочего режима это факт опроса. При опросе может быть получено несколько архивных записей, в которых фиксируется нештатная ситуация. Каждый этот факт мы фиксируем в журнале, так как он может быть полезен для того, чтобы разобраться с проблемой.
Диагностика отсутствия связи работает не так. Она запускается по таймеру каждый час и диагностирует факт отсутствия данных. Если сделать так, как вы предлагаете, то в журнал зафиксированной НС каждый час будет добавляться новая запись, которая вряд ли несёт какую-то полезную нагрузку.
Думаю, стоит рассмотреть фиксацию конкретного времени, когда НС была обнаружена, т.к. сейчас оно обновляется после каждой диагностики. Но вот нужно ли заносить в журнал каждый факт запуска этой проверки?
Это действительно важно. Текущий алгоритм является проблемным, так как невозможно определить, когда именно персонал был уведомлён о нештатной ситуации. Это одна из основных причин, почему я разбираюсь с этой НС.
Польза в том, что можно отследить развитие ситуации. Если считаете, что это избыточно для большинства систем, меня устроит возможность настройки, которая позволит видеть результат диагностики по данной нештатной ситуации.
Также важно не ввести пользователей в заблуждение. В конкретной системе опрос проводится раз в 15 минут, и если фиксировать НС, то это будет раз в час. Т.е. фиксация не будет привязана к реальному времени возникновения события. Об этом стоит указать в доументации и не визуально постараться не допустить этого заблуждения
Сейчас начал детально разбираться с механизмом этой диагностики и вот какие выводы могу сделать.
В колонке “Возникла” всегда отображается дата последних данных, когда нештатная ситуация была выявлена в первый раз. Она может обновится только в том случае, когда НС была закрыта и выявлена повторно. Любые повторные обновления НС не влияют на эту дату.
В колонке “Выявлена” всегда отображается дата по часам сервера, когда НС была зафиксирована, или обновлена, что позволяет понять когда она последний раз фиксировалась.
В детализации НС самая первая запись сохранена на ту дату, когда НС была впервые зафиксирована по часам сервера. Соответственно, она совпадает с датой, когда было отправлено уведомление.
Фиксировать каждый факт диагностики мне всё ещё кажется неверным. Сейчас фиксируется каждый факт отсутствия связи в активном периоде. То есть, если период отсутствия данных у вас стоит равным 6 часов, НС будет обновлена и дописаны сообщения в детализацию один раз в 6 часов, не смотря на то, что физически диагностика выполнилась шесть раз.
А как при таком порядке убедиться, что контроль действительно был? Для других НС наличие контроля можно увидеть.
Отсутствие контроля может быть вызвано зависанием модема на сервере, проблемами с каналом связи, зависанием службы опроса и т.п. Такие ситуации случаются и это не редкость. В данном случае компания полагается на ЛЭРС в части контроля параметров и контроля того, что персонал видел эту информацию. Однако последнее никак не следует из данных по НС.
Не совсем понял, вы хотите убедиться, что ЛЭРС действительно проверил, что есть активная НС? Если так, то при чём тут каналы связи? Проверка независимо от потоков опрос. Как вам поможет тот факт, что сервер убедился, что связи нет, но не стал обновлять НС, так как уже есть активная
НС “Данные от устройства не получены” ведь отличается от прочих НС тем, что она не фиксирует каждую фиксацию НС. Это смущает пользователей. Поэтому они хотят видеть подтверждение того, что контроль был осуществлен. То есть пользователи ожидают, что в НС будут фиксироваться неудачные запросы или, как минимум, ежечасные проверки наличия данных.
Но с учетом этого:
и этого
Давайте внесем изменения и попробуем поработать с таким алгоритмом.
Ведь после внесения изменения в НС появится дата и время последних данных и дата последней проверки. То есть будет однозначно понятен период, в течение которого не поступают данные от прибора учета.
Но вопрос: если пользователь закроет НС, а при ближайшей проверке не будет новых данных, будет ли снова открыта закрытая НС с прежней датой и временем обнаружения или сформируется новая НС с текущей датой и временем обнаружения?
