На мнемосхеме насосной давление держится на отметке 5,2 бар. Это может означать устойчивый режим, отсутствие изменения в передаваемых данных или то, что экран давно не получает обновлений. Если все три ситуации выглядят одинаково, оператору приходится угадывать.

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

Разберём способ согласовать состояния и проверки на условном примере. Это требования к проекту мониторинга, а не описание готовых настроек определённой SCADA.

Разделите значение, изменение и доступность

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

В OPC UA DataValue предусмотрены значение, код состояния и временные отметки источника и сервера. Отметка источника может быть связана с последним изменением значения или статуса. Поэтому её возраст нельзя без понимания семантики использовать как универсальный таймер потери связи.

Для конкретного сигнала запишите четыре факта: когда значение изменилось, когда источник подтвердил его доступность, когда его получил компонент сбора и когда обновился экран. Не все устройства предоставляют все четыре отметки. Отсутствующие сведения отмечайте как неизвестные, а не заменяйте вымышленным временем измерения.

Посмотрите на всю цепь доставки

Путь данных может включать датчик, контроллер, шлюз, сервер сбора и браузер оператора. Успешная связь на одном участке не подтверждает исправность остальных. Браузер может получать ответы сервера, который сам потерял соединение с контроллером.

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

Например, OPC UA описывает keep-alive подписки: при отсутствии уведомлений сервер может подтвердить, что подписка активна. Такое сообщение не доказывает работоспособность физического датчика. Поддержку и доступность подобного механизма в конкретной цепи проверяют отдельно.

Если диагностика ограничена, честное обозначение — «доступность источника не подтверждена». Программа не должна выдавать отсутствие сведений за подтверждённую норму.

Согласуйте понятные состояния качества

Вместо одной лампы «связь есть» создайте описание состояний для оператора. Названия ниже — пример проектной легенды, которую нужно согласовать со специалистами предприятия.

Подтверждено. Доступность источника и качество значения удовлетворяют заданным правилам. На экране видны число и единица; подробности позволяют проверить источник и время.

Сомнительно. Значение получено, но источник сообщает ограничение качества либо часть обязательных проверок не выполнена. Число сопровождается текстовым предупреждением, объясняющим ограничение.

Устарело. Ранее подтверждённое значение сохранено, но текущая доступность больше не подтверждается по установленному правилу. На экране написано «последнее известное», отдельно показано время подтверждения.

Недоступно. Пригодного значения нет: например, система только запустилась либо источник вернул ошибку без достоверной истории. Вместо числа отображается понятный знак отсутствия и описание состояния.

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

Заполненный пример временной последовательности

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

Последовательность выглядит так:

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

Покажите ограничение рядом с числом

Текстовое обозначение должно находиться возле значения, а не только в общем журнале. Когда человек рассматривает один агрегат, он может не заметить предупреждение в другом углу экрана.

Полезный образец подписи: «5,2 бар · последнее известное · подтверждено в 09:00:05». При сомнительном качестве — «5,2 бар · качество ограничено: диагностика источника». Если значения ещё не было — «данные не получены». Цвет может усиливать сообщение, но не быть единственным различием.

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

Не подменяйте пропуск нулём. Ноль бар выглядит как физическое событие и может вызвать ошибочную интерпретацию. Не скрывайте устаревание округлением времени: «обновлено сегодня» недостаточно для оперативного решения.

Сохраните смысл в архиве и расчётах

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

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

При восстановлении связи уточните, существует ли история на источнике. Если её нет, пропущенный интервал остаётся пропуском. Новое текущее значение не позволяет восстановить все изменения между последним успешным чтением и возвращением связи.

Проверьте сценарии, которые обычно забывают

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

  1. Значение не меняется, подтверждения приходят: ложного устаревания нет.
  2. Источник недоступен, сервер работает: предупреждение относится к нужным сигналам.
  3. Один тег неисправен, соседние исправны: проблема не скрыта общим зелёным статусом.
  4. Сервер недоступен браузеру: весь экран заметно теряет подтверждение актуальности.
  5. Соединение восстановлено без нового значения: нормальное качество преждевременно не показывается.
  6. Пришло запоздалое сообщение: оно не заменяет более новое состояние без предусмотренного правила.
  7. После запуска нет первого значения: экран не показывает искусственный ноль.

Чек-лист требования к отображению

Для каждого класса сигналов зафиксируйте: смысл временных отметок; признак доступности; основание выбора срока; состояния качества; текст возле числа; поведение архива; правило восстановления; ответственного за диагностику. Укажите, какие сведения невозможно получить от текущего оборудования.

Мониторинг помогает увидеть ограничение данных, но не становится системой защиты. Действия при неопределённом состоянии определяются эксплуатационными процедурами и архитектурой объекта. Настройки интерфейса не заменяют локальные защитные функции.

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

Источники и материалы по теме

- OPC Foundation: DataValue и временные отметки.
- OPC Foundation: подписки и keep-alive.
- Карта тегов SCADA.
- Как сделать мониторинг оборудования полезным.

Все материалы →