Сервер истории Historian

Что сохраняет Historian

Historian хранит числовые и дискретные значения, качество, переходы аварий и события. Источником записей служит Runtime; клиенты HMI запрашивают сохранённые данные для трендов и журналов.

После применения конфигурации Historian работает независимо от Studio: принимает записи от Runtime и отвечает на запросы HMI. База Historian отделена от базы Studio. Для переноса накопленной истории скопируйте базу Historian, каталог архивов и конфигурацию службы.

Настройка узла и базы

1. Подготовьте отдельную базу и роль PostgreSQL по инструкции установки. Проверьте возможность входа с компьютера Historian.
2. В Studio откройте вкладку «Узлы», выберите созданный сервер истории или нажмите «＋». В «Назначение» установите «Historian — сервер истории». Задайте название, например History1, и адрес компьютера службы.
3. Укажите «Порт службы Historian», обычно 8095. Это порт компонента SAMUTAG, а не порт PostgreSQL.
4. Заполните «База PostgreSQL Historian», «Адрес PostgreSQL (со стороны Historian)» и «Порт PostgreSQL», обычно 5432. Адрес 127.0.0.1 означает, что PostgreSQL находится на том же компьютере, что и Historian.
5. Введите «Пользователь PostgreSQL» и «Пароль PostgreSQL». Используйте реквизиты подготовленной роли. При редактировании оставьте поле пароля пустым, чтобы сохранить прежний пароль.
6. Задайте «Хранить живые данные, дней», «Хранить восстановленный кеш, часов» и «Час архивирования, UTC». Например, 90 дней, 72 часа и 2 соответственно. Подробный пример приведён в настройке архивирования.
7. Проверьте параметры журнала, описание и «Включён». Нажмите «Сохранить» вверху справа.
8. В контекстном меню узла скачайте конфигурацию для нужной ОС. Установите Historian, разместите конфигурацию в каталоге службы и настройте каталог архивов по инструкции установки. Запустите службу.
9. У нужных тэгов включите историю. В настройках Runtime и АРМ выберите этот узел в поле «Сервер истории»; сохраните настройки. Модели должны быть назначены Runtime.
10. Откройте «Просмотр сервера» для Historian и нажмите «Применить конфигурацию». Дождитесь завершения и проверьте состояние базы и количество параметров. Затем загрузите проект на Runtime и АРМ.
11. В просмотре Historian выберите «База параметров (трендов)», укажите контрольный тэг кнопкой «…» и недавний период «С — По». Выполните запрос и убедитесь, что поступают актуальные значения. Аналогично проверьте записи аварий и событий, если они настроены.

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

Выгрузка и параметры historian.json

Нажмите правой кнопкой на узле Historian и скачайте конфигурацию нужной платформы. Меню скачивания и порядок установки показаны в общей инструкции. Файл содержит параметры подключения к отдельной PostgreSQL-базе истории; установите его как historian.json в каталог службы Historian.

Общие поля format, version, node_id, project_name, description, host, token и logging описаны в таблице конфигурации узлов. После установки файла перезапустите службу и проверьте готовность базы; затем примените конфигурацию Historian из Studio.

Какие значения попадают в историю

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

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

После изменения состава примените конфигурацию Historian и загрузите проект на Runtime. Проверьте свежие записи по одному известному параметру до включения массового архивирования.

Доставка: оперативная память и дисковая очередь

При исправной связи Runtime передаёт значения в Historian из оперативной памяти. При потере связи или отставании записи временно сохраняются в дисковой очереди.

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

Не зафиксированные на диске данные RAM-буфера могут быть потеряны при аварийном завершении. Объём буфера оперативной памяти и дисковой очереди (spool) ограничен; при переполнении возможен отказ от новых записей со счётчиком потерь. Заполнение буферов и счётчик потерь доступны в просмотре состояния узла.

Архивирование разделов таблиц для экономии места

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

Исторические таблицы разделены на партиции — отдельные разделы за каждые сутки. Границы суток определяются по UTC. По окончании заданного срока оперативного хранения Historian переносит целый суточный раздел в архив.

1. Выбор периода. Во время планового обслуживания Historian выбирает завершённые сутки, которые уже не входят в период оперативного хранения.
2. Создание архива. Данные раздела выгружаются в сжатый файл в настроенном каталоге архивов. Значения, качество и время записей сохраняются без сокращения точности и без замены измерений усреднёнными значениями.
3. Проверка. Historian выполняет контрольное восстановление и проверяет целостность и полноту сохранённых данных. При ошибке проверки исходный раздел остаётся в базе.
4. Освобождение места. Только после успешной проверки раздел вместе с его индексами удаляется из PostgreSQL. История за эти сутки остаётся в архиве и доступна для последующего восстановления.

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

Срок оперативного хранения не является сроком удаления истории. Например, при значении 90 дней более старые завершённые сутки переходят в архив, а не исчезают из истории.

Просмотр архивных периодов

Оператор выбирает нужный период в тренде или журнале обычным способом. Если запрошенные данные уже перенесены в архив, Historian восстанавливает необходимые суточные разделы в PostgreSQL. Вручную искать и распаковывать файлы не требуется.

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

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

Запоздавшие данные, например после восстановления связи с Runtime, сохраняются и для уже архивированных суток. При просмотре Historian объединяет их с ранее сохранённой историей.

Если восстановление завершилось ошибкой, проверьте доступность каталога архивов, свободное место и журнал Historian.

Настройки архивирования и восстановления

В настройках узла Historian задаются сроки оперативного хранения и хранения временно восстановленных данных, а также время ежедневного архивирования.

В конфигурации службы также задаются каталог архивов, минимальный запас свободного места и предельный объём восстановленных данных. Каталог должен быть доступен службе Historian. При достижении лимита восстановления дождитесь очистки временных копий либо увеличьте лимит с учётом доступного места.

UTC — всемирное координированное время. Час обслуживания задаётся по UTC. При планировании ночных операций переведите его в местное время площадки и учитывайте нагрузку резервного копирования.

Время и отставание

Внутренние временные метки используют UTC, интерфейс может показывать местное время. Разница ровно в несколько часов часто указывает на неверную интерпретацию часового пояса; растущая задержка чаще связана с очередью, недоступностью базы или перегрузкой.

1. Сравните часы Runtime, Historian, Studio и рабочей станции.
2. Проверьте время последней записи и последнее успешное подтверждение доставки.
3. Посмотрите объём буфера оперативной памяти и дисковой очереди и счётчики отклонённых записей.
4. Убедитесь, что выбран правильный источник и период тренда.

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

Обслуживание и резервная копия истории

Резервная копия Historian включает согласованный набор: базу PostgreSQL, каталог архивов и конфигурацию. База содержит служебные сведения об архивах, файлы — данные архивированных суток.

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

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