Аварии, квитирование, тренды и OPC UA

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

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

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

OPC UA предоставляет модель данных и механизмы взаимодействия клиентов и серверов. При интеграции согласуют идентификаторы узлов, типы, единицы и правила доступа. Значение сопровождается сведениями о состоянии; не следует отбрасывать плохое качество только потому, что в поле осталось число.

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

Для перегрева задайте четыре отдельные отметки: возникновение, квитирование, возврат в норму и завершение события по принятой модели. Подготовьте тренд температуры, команды нагрева и состояния связи с общим временем. Смоделируйте пропуск данных и убедитесь, что он не выдаётся за ровный участок достоверного процесса. В карте OPC UA сохраните идентификатор, тип, качество и разрешённые операции.