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

С чего начинать диагностику

Запишите время, компонент, действие и полный текст сообщения. Затем установите, на каком участке возникла ошибка: браузер → Studio/HMI, Studio → узел, Runtime → I/O либо Runtime → Historian.

В Studio используйте журнал соответствующего узла и фильтр источника. Для проблем запуска нужны журналы ОС:

systemctl status samutag-studio samutag-runtime samutag-hmi samutag-historian --no-pager
journalctl -u samutag-studio -n 150 --no-pager
journalctl -u samutag-runtime -n 150 --no-pager
journalctl -u samutag-hmi -n 150 --no-pager
journalctl -u samutag-historian -n 150 --no-pager

Для наблюдения в реальном времени добавьте -f. Если терминал показывает байтовые последовательности вместо кириллицы, проверьте UTF-8-локаль и вывод без программы постраничного просмотра: journalctl -u samutag-historian -o cat --no-pager. Для обращения в техническую поддержку сохраните сообщения за время возникновения ошибки.

Журналы узлов в Studio

1. Откройте проект и перейдите на вкладку «Узлы». Откройте нужный Runtime, Historian или АРМ и перейдите к просмотру его состояния.
2. Разверните блок «Журнал узла». Кнопка «Обновить» получает сообщения от выбранного узла. Если служба недоступна, проверьте её журнал средствами ОС, как показано выше.
3. Начните с источника и уровня «Все», чтобы увидеть последовательность событий: запуск, отказ, повторные попытки и восстановление.
4. Найдите время сбоя, затем ограничьте выборку источником, уровнем, текстом и периодом.

Пример: найти ошибку конкретного I/O-сервера

Выберите нужный сервер в поле «Источник», установите уровень ERROR и нажмите «Обновить». На снимке осталась одна запись о закрытии соединения Modbus TCP до получения ответа.

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

Уровни сообщений и хранение журнала

В редакторе узла на вкладке «Параметры компьютера» задаются «Минимальный уровень журнала», «Объём журнала, МБ» и «Хранить журнал, дней».

Минимальный уровень определяет, какие сообщения записываются: при INFO сохраняются INFO, WARNING, ERROR и CRITICAL, а DEBUG пропускается. Фильтр в просмотре журнала только отбирает уже записанные сообщения и не включает подробное журналирование.

1. Для диагностики установите DEBUG и сохраните узел.
2. Передайте обновлённые настройки компоненту: загрузите актуальный проект на Runtime или АРМ, для Historian примените конфигурацию.
3. Воспроизведите проблему и сохраните сообщения за нужный период.
4. Верните обычный уровень, например INFO, и снова примените настройки.

Для сохранения журнала Linux в файл используйте, например, journalctl -u samutag-runtime --since "1 hour ago" -o short-iso --no-pager > runtime-log.txt. При необходимости выполните команду с sudo. Для другой службы замените её имя.

Нет соединения с узлом

Проверьте слушающие порты на машине службы:

ss -ltnp

Адрес loopback (127.0.0.1 или ::1) принимает подключения только с того же компьютера. Если используется 0.0.0.0, подключаться всё равно нужно к реальному IP или DNS-имени.

Графика не меняется или привязка не найдена

1. Найдите полный путь проблемного символа, включая цепочку вложенных символов и ID элемента.
2. Откройте источник графики и проверьте выбранный вид анимации, выражение и тип.
3. Определите, относится ли привязка к локальному параметру символа или к тэгу Runtime. Локальная переменная не обязана иметь серверный источник.
4. Проверьте владельца this и MyModel, особенно после переноса экземпляров между моделями или изменения композиции.
5. Сохраните символ и убедитесь, что на HMI загружена актуальная версия проекта. До загрузки обновлённого проекта АРМ продолжает использовать прежнюю графику.
6. Сравните значение и качество тэга в просмотре Runtime с ожидаемым условием.

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

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

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

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

История не поступает

1. Проверьте, включена ли история у тэга и применён ли актуальный состав параметров.
2. Проверьте Runtime: есть ли успешные сканы и подключение к выбранному Historian.
3. Проверьте Historian: доступна ли база, завершена ли подготовка схемы, хватает ли места.
4. Оцените очередь доставки и счётчики потерь. После восстановления связи дождитесь догрузки.
5. Проверьте часы и период запроса, затем наличие восстановленных архивных суток.

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

Ошибки ввода-вывода и качества тэгов

В просмотре Runtime добавьте проблемный тэг в область «Значения» и сравните его значение, качество и текст ошибки с журналом соответствующего I/O-сервера. Ниже приведены характерные сообщения и порядок проверки.

Ошибки Runtime и скриптов

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

Ошибки лицензии и доступа к файлам

Порядок получения запроса и установки файла со снимками Studio приведён в разделе «Лицензирование». Если причина не определена, передайте в поддержку версию компонента, полный текст ошибки, время и журнал соответствующего узла.

Резервное копирование

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

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

Пример логического резервирования PostgreSQL с запросом пароля, для пользователя с необходимыми правами:

pg_dump -h 127.0.0.1 -U samutag_studio -W -Fc -f studio-backup.dump samutag_studio
pg_dump -h 127.0.0.1 -U samutag_historian -W -Fc -f historian-backup.dump samutag_historian

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

Обновление и очистка старых релизов

1. Сделайте резервные копии и запишите текущие версии.
2. Выберите совместимые дистрибутивы и предусмотрите окно обслуживания.
3. Запустите install.sh соответствующего компонента. Сохраните существующие конфигурации и ключи.
4. Проверьте состояние служб, подключение, права и лицензию.
5. При необходимости повторно загрузите проект на Runtime и HMI и примените конфигурацию Historian.
6. После проверки удалите ненужные релизы по предложению установщика. Оставьте предыдущий релиз и резервную копию для восстановления.

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

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

Проверка перед вводом в работу

В тестовой среде проверьте нормальный режим, отказ канала, остановку I/O, переподключение, перезапуск узла и заполнение диска.

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

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