Сервер приложений Runtime

Что делает Runtime

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

Основной цикл Runtime и сетевой опрос выполняются с независимыми периодами. Драйверы I/O обновляют значения измерений, а основной цикл Runtime, называемый сканом, использует полученные данные для вычислений. Интервал скрипта задаёт требуемую периодичность запуска. Если вычисления занимают больше заданного интервала, следующий запуск задерживается.

Начало настройки узлов в Studio

Узел описывает компьютер и службу, на которой будет работать часть проекта. Создайте узел кнопкой «＋» в заголовке дерева «Узлы» или ссылкой «Добавить узел» внизу дерева.

1. Откройте проект и перейдите на вкладку «Узлы». Выберите нужный узел в дереве слева. Его поля появятся в рабочей области справа.
2. На вкладке «Параметры компьютера» заполните «Название», «Назначение» и «Имя компьютера / IP». Название отличает узел внутри проекта; адрес указывает компьютер, на котором установлена служба.
3. Заполните поля выбранного назначения по инструкции ниже. Проверьте описание и переключатель «Включён». Нажмите «Сохранить» в правом верхнем углу.
4. Для первоначальной установки нажмите правой кнопкой мыши на узел в дереве и выберите «Скачать конфигурацию Linux» либо «Скачать конфигурацию Windows». Установите соответствующий компонент и разместите его конфигурацию по инструкции установки.
5. После запуска службы откройте «Просмотр сервера» или «Просмотр АРМ». Убедитесь, что Studio получает состояние компонента. Затем примените конфигурацию Historian или загрузите проект на Runtime и АРМ.

«Сохранить» записывает настройки в проект Studio. Чтобы применить изменения на работающем узле, загрузите на него проект. Для загрузки нужны права пользователя Studio на развёртывание и права редактирования проекта.

Адреса 192.0.2.x на иллюстрациях приведены для учебного примера. Вместо них укажите адреса своих компьютеров. Если несколько служб работают на одном компьютере, их порты и рабочие каталоги должны различаться.

Выгрузка конфигурации узла

Конфигурация JSON задаёт, как запускается служба на компьютере: идентификатор узла, порты, каталоги, токен и параметры подключения. Исполняемый проект Runtime и видеокадры АРМ загружаются отдельно после запуска службы.

1. Сохраните настройки проекта, включая токен, затем сохраните параметры выбранного узла.
2. На вкладке «Узлы» нажмите правой кнопкой на нужном узле.
3. Выберите «Скачать конфигурацию Linux» или «Скачать конфигурацию Windows» в соответствии с компьютером службы.
4. Сохраните файл. По имени проверьте компонент, имя узла и платформу.
5. На компьютере службы сохраните резервную копию прежнего файла и установите скачанный файл под штатным именем: runtime.json, hmi.json или historian.json в каталог компонента.
6. Проверьте адреса прослушивания, порты, пути и доступ служебного пользователя к файлам. Перезапустите соответствующую службу и откройте просмотр узла в Studio.

Команды скачивания доступны при праве редактирования проекта и разрешении пользователя Studio на загрузку проектов на узлы. Если их нет, проверьте оба уровня доступа.

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

«Имя компьютера / IP» в Studio — адрес, по которому Studio обращается к узлу. Поле host внутри JSON — локальный адрес, на котором служба принимает подключения. 0.0.0.0 означает все локальные IPv4-интерфейсы; его нельзя использовать как адрес удалённого компьютера.

Общие поля файлов конфигурации

Следующие поля формируются при скачивании конфигурации. Для обычной настройки меняйте параметры узла в Studio и скачивайте файл повторно. При ручном изменении JSON соблюдайте типы значений и сохраняйте назначение файла конкретному узлу.

Поля logging.* находятся внутри объекта logging. Далее приведены отдельные поля Runtime, HMI и Historian.

Параметры runtime.json

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

Блок historian

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

Сервер приложений: настройка по шагам

1. Выберите или создайте узел, например Runtime1. В поле «Назначение» установите «Сервер приложений», в «Имя компьютера / IP» — адрес компьютера Runtime.
2. В поле «Сервер истории» выберите настроенный Historian. Вариант автоматического выбора подходит, когда в проекте один сервер истории.
3. Проверьте «Порт управления и загрузки» (обычно 8765), «Порт диагностики» (8766) и «Порт резервирования» (8767). Значения должны совпадать с конфигурацией установленной службы.
4. Задайте «Количество процессов Runtime». Для начальной проверки небольшого проекта можно оставить один процесс; для рабочего проекта выполните оценку ёмкости. В поле «Допустимое время scan, мс» укажите допустимую длительность цикла, а в «Запас производительности, %» — требуемый резерв.
5. При использовании истории проверьте поля «Historian: RAM-буфер узла, МиБ», «Historian: дисковая очередь, МиБ» и папку очереди. Это ресурсы компьютера Runtime для доставки данных, а не размер базы Historian. Начальные значения можно оставить до оценки нагрузки.
6. Выберите «Минимальный уровень журнала», задайте объём и срок хранения журнала. Для обычной работы используйте INFO; DEBUG включайте на время подробной диагностики.
7. Перейдите на вкладки «Модели» и «I/O серверы», назначьте состав узла, затем нажмите «Сохранить».
8. После установки и запуска службы откройте «Просмотр сервера», проверьте состояние и выполните загрузку проекта.

Размещение моделей и процессов

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

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

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

1. На вкладке «Модели» найдите корневую модель в области «Не привязанные объекты».
2. Перетащите её в область «Привязанные модели». Раскройте ветвь стрелкой слева от имени и проверьте дочерние модели. Кнопки «+» и «−» раскрывают и сворачивают всё дерево соответствующей области.
3. Для отмены назначения нажмите крестик справа от корневой модели. Учитывайте, что вместе с ней исключается вся вложенная ветвь.
4. Сохраните узел. При следующей загрузке Runtime получит собственные объекты назначенных моделей и экземпляры всей ветви.

Назначение серверов ввода-вывода

1. Сначала создайте соединения и карты по разделу «Серверы ввода-вывода».
2. В настройках Runtime откройте вкладку «I/O серверы».
3. Перетащите необходимые соединения в область «Назначенные I/O-серверы». Для Modbus Gate назначьте шлюз: его дочерние устройства входят в состав вместе с ним.
4. Проверьте, что назначены именно те серверы, на переменные которых ссылаются тэги размещённых моделей и экземпляров.
5. Нажмите «Сохранить» и загрузите обновлённый проект на Runtime. После запуска проверьте значения и качество нескольких тэгов.

Загрузка проекта и проверка результата

1. Сохраните проект и устраните ошибки ссылок и типов.
2. Проверьте адрес узла, токен, конфигурацию службы, лицензию и назначенные модели.
3. В просмотре сервера откройте «Показать различия» и оцените, какие изменения будут применены на узле.
4. Нажмите правой кнопкой на узел в дереве и выберите «Залить и запустить проект». Studio проверит проект, передаст его на узел и запустит новую версию.
5. Дождитесь готовности всех рабочих процессов.
6. В области «Значения» нажмите кнопку «…», найдите и добавьте контрольные тэги. Проверьте значение, качество и отсутствие ошибок. Затем проверьте журнал, вычисляемый тэг, аварию и передачу данных в Historian.

Большой проект обрабатывается фоновым заданием. Следите за этапами выполнения и сообщениями журнала. Если менялись клиентские привязки или графика, отдельно обновите HMI.

Оценка ёмкости узла

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

Цвет индикатора показывает достаточность ресурсов: зелёный — ресурсов достаточно, жёлтый — запас невелик, красный — ёмкости недостаточно. Проверьте результат на рабочем проекте: время цикла зависит от сложности скриптов и обмена с оборудованием.

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

Просмотр значений и диагностика

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

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

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

Резервные пары

Количество резервных пар в проекте не ограничивается одной. Можно создать несколько независимых пар «основной сервер приложений — резервный сервер», распределив между ними модели и серверы ввода-вывода. У каждой пары свой основной узел, свой резервный узел и отдельные настройки резервирования.

Например, один проект может включать пару для котельной, вторую — для насосной станции и третью — для вентиляции:

• BoilerRuntime и BoilerReserve — модели и оборудование котельной.
• PumpRuntime и PumpReserve — модели и оборудование насосной станции.
• VentRuntime и VentReserve — модели и оборудование вентиляции.

Для каждой пары выполните последовательность ниже. При создании резервного узла выберите его основной сервер в поле «Основной сервер». Модели и I/O-серверы назначаются основному узлу соответствующей пары; резерв получает тот же состав. Загрузите проект и проверьте переключение отдельно для каждой пары.

1. Сначала настройте основной узел с назначением «Сервер приложений», его модели и I/O-серверы.
2. В дереве узлов нажмите «＋» и создайте второй узел, например Runtime2. Выберите назначение «Резервный сервер приложений» и укажите адрес второго компьютера.
3. В поле «Основной сервер» выберите Runtime1. Проверьте «Порт резервирования» и доступность связи между компьютерами.
4. Определите политику «Возвращать на основной»: нужно ли возвращать активную роль основному узлу после восстановления его работы.
5. Проверьте порты управления и диагностики резервного узла, описание и настройки журнала. Нажмите «Сохранить».
6. Скачайте конфигурацию именно резервного узла и установите Runtime на второй компьютер. Модели и I/O-серверы резерв получает от основного; отдельно назначать их резерву не требуется.
7. Загрузите проект на оба узла. В просмотре состояния проверьте роли пары и связь. Проведите испытание переключения и возврата до ввода системы в работу.

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

Один АРМ может отображать данные нескольких пар, если его видеокадры используют объекты соответствующих Runtime-узлов. Выбор активного сервера выполняется отдельно для каждой пары. Для такого АРМ обеспечьте сетевой доступ к обоим участникам каждой используемой пары.

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

Modbus- и OPC UA-серверы Runtime

На узле сервера приложений можно включить сервер Modbus или OPC UA для внешних клиентов. В этом случае SAMUTAG предоставляет внешним клиентам значения своих тэгов. I/O-клиент выполняет обратную задачу: получает данные от внешнего устройства.

Откройте вкладку «Узлы» и редактор основного сервера приложений. Настройки находятся на вкладках «Сервер Modbus» и «Сервер OPC UA». Резервный сервер использует настройки основного. На снимках показана учебная конфигурация с экземпляром Pump1.

Настройка сервера Modbus TCP

1. На вкладке «Сервер Modbus» включите слайдер «Включить сервер Modbus».
2. Укажите «Порт»: по умолчанию 502. Выберите порядок байтов и слов, соответствующий настройкам внешнего клиента. На примере байты идут старшим первым, а слова — младшим первым.
3. В поле «Разрешённые хосты» перечислите адреса клиентов через запятую. Можно указывать IP-адреса, подсети CIDR и DNS-имена. В примере разрешён один учебный адрес 192.0.2.50; замените его адресом своего клиента.
4. Слайдер «Разрешить запись» оставьте выключенным, если внешние клиенты должны только читать значения. Нажмите «Сохранить настройки Modbus».

Ниже находится карта публикуемых тэгов. Нажмите «Добавить тэг …», выберите экземпляр и тэг, затем задайте область данных, тип, адрес и разрешение записи. Кнопка «Автозаполнение» формирует карту автоматически; после этого проверьте адреса и состав строк.

Значение REAL занимает два регистра: в примере давление с адресом 0 использует регистры 0 и 1. Значок карандаша открывает редактирование строки, крестик удаляет её из карты. «Экспорт карты» сохраняет описание адресов для настройки внешнего клиента.

Настройка сервера OPC UA

1. На вкладке «Сервер OPC UA» включите слайдер «Включить сервер OPC UA».
2. Задайте «Порт» (по умолчанию 4840) и интервал «Обновление значений, мс». Интервал определяет обновление значений, предоставляемых OPC UA-клиенту.
3. Выберите «Защита канала». Для режима Basic256Sha256 SignAndEncrypt укажите пути в полях «Файл сертификата на узле» и «Файл закрытого ключа на узле». Эти файлы должны находиться на компьютере Runtime и быть доступны его службе.
4. Укажите «Разрешённые хосты», при необходимости включите «Разрешить запись» и нажмите «Сохранить настройки OPC UA».

Добавьте тэги кнопкой «Добавить тэг …» или воспользуйтесь «Автозаполнением». Автоматический NodeId формируется по полному пути экземпляра и имени тэга; адресное пространство сервера группируется по моделям. Например, тэг Pump1.Pressure доступен как ns=2;s=Pump1.Pressure.

Кнопка «Пересоздать автоматические NodeId» обновляет автоматически сформированные идентификаторы по текущим путям тэгов. После её использования проверьте привязки внешнего клиента и передайте ему новый экспорт карты.

Применение настроек и подключение клиента

Обозначение R в обеих картах означает чтение, R/W* — разрешение записи для строки. Запись извне работает только при включённом общем слайдере «Разрешить запись» и разрешении записи в нужной строке.

После подготовки настроек и карты загрузите обновлённый проект на Runtime. Для Modbus-клиента укажите адрес компьютера Runtime и выбранный порт. Для OPC UA-клиента используйте адрес opc.tcp://адрес-узла:порт/samutag/, например opc.tcp://192.0.2.10:4840/samutag/. Проверьте чтение опубликованных тэгов.

Остановка и повторный запуск

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

systemctl stop samutag-runtime
systemctl start samutag-runtime
journalctl -u samutag-runtime -n 100 --no-pager

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