Проверка обмена KNX / OPC UA
на стенде

Состав первого стенда

Первый запуск 30 октября 2026 года выполнен с клиентом asyncua. Разделы о качестве, командах и перезапуске ниже относятся к этому запуску; дополнительная проверка FUXA описана отдельно.

Эмулятор, Linux-шлюз и клиент запускались в отдельных контейнерах изолированной Docker-сети. Данные передавались по KNXnet/IP UDP и OPC UA TCP. Конфигурацию шлюза создавал автоматизированный сценарий через HTTPS API с отдельным применением изменений.

• ZVENO 0.1.0, исходная версия репозитория da984ba.
• Python 3.12.15, OPC UA-клиент asyncua 2.1.0, KNX-библиотека xknx 3.15.0.
• Linux arm64 в OrbStack, Docker Engine 29.8.2; хост — Apple M1 Pro, 8 логических CPU.
• Температура DPT 9.001 на адресе 2/0/0, командные и обратные точки DPT 1.001 и 9.001.

Это функциональная проверка обмена, а не измерение производительности или совместимости с оборудованием конкретного производителя.

Значения, качество и время

После запуска у температурного тега ещё не было живого значения: клиент получил BadWaitingForInitialData. Затем эмулятор передал 23,5; внешний OPC UA-клиент получил это значение с качеством Good.

Встроенный просмотр ZVENO показал то же значение и качество. Время источника и сервера сравнили с чтением внешнего OPC UA-клиента — значения временных меток совпали.

Команды из OPC UA в KNX

Клиент записал уставку 22,5 в разрешённый командный тег. Шлюз дождался согласованной обратной связи. Запись 30 при заданном диапазоне 18–26 была отклонена. Запись в тег обратной связи, которому команда не разрешена, также была отклонена.

Отдельно проверили таймаут обратной связи и потерю KNX ACK. Эхо собственной команды не считалось новым подтверждением от устройства.

Потеря связи и перезапуск

При принудительном обрыве KNX-подключения тег обратной связи получил качество UncertainLastUsableValue. После восстановления подключения ранее отправленные команды не воспроизводились автоматически.

После перезапуска шлюз восстановил температуру 23,5 из локального состояния с качеством UncertainInitialValue: сохранённое значение не выдавалось за новое измерение.

Эмулятор зарегистрировал 6 команд в ходе сценария. После восстановления связи и перезапуска шлюза счётчик остался равным 6.

Результаты и границы первого запуска

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

Значения 23,5 и Good подтверждаются успешным выполнением приведённых проверок сценария; сводный отчёт не является журналом всех телеграмм. Внешний клиент asyncua проверяет протокол, но не заменяет испытание конкретной SCADA.

В этом запуске не измерялись нагрузка 10 000+ тегов, WAN-задержка, KNX IP Secure или работа реального объекта. OPC UA использовал SecurityPolicy None и SecurityMode None внутри изолированной сети.

Дополнительная проверка: SCADA FUXA

FUXA 1.3.5-2968 прочитала изменяющиеся значения через ZVENO. Управление через API этой сборки завершалось ошибкой; полная двусторонняя совместимость не подтверждена.

В отдельном запуске 30 октября 2026 года использовали шлюз из версии репозитория 3b308cc, официальный образ FUXA 1.3.5 и установленный драйвер node-opcua 2.149.0. В обозревателе OPC UA выбрали температуру и две точки освещения. Подключение работало внутри тестовой сети с SecurityPolicy None и SecurityMode None.

При изменении температуры в KNX-эмуляторе с 23,5 до 24,0 значение обновилось в FUXA. Чтение дополнительно проверили через API самой SCADA.

Для управления отправили команды true и false через API FUXA. Обе команды достигли KNX-эмулятора. После команды false шлюз зарегистрировал confirmed, а FUXA прочитала false на теге обратной связи. При этом API FUXA возвращал HTTP 400: драйвер этой версии отклонял статус GoodCompletesAsynchronously при проверке isGood().

По спецификации OPC UA Write этот статус означает запись в промежуточную систему без подтверждения обновления конечного источника. Он не равнозначен завершённой физической операции. В проверенной связке ошибка API не означала, что команда не отправлена: перед повтором нужно проверить обратную связь.

Демонстрационные теги в FUXA: температура 24 и обратная связь false. Снимок подтверждает отображение данных; успешное управление через API не подтверждено.

Отчёт проверки FUXA с ограничением совместимости содержит наблюдения SCADA, записи KNX-эмулятора, версии и ID образов. Этот запуск не проверял обработку качества и восстановление связи в FUXA. Для полноценного управления нужна отдельная проверка с целевой SCADA заказчика.

Как проверить обмен на объекте

Для внедрения нужно повторить проверку на ваших устройствах и из OPC UA-клиента вашей SCADA: сверить значения, качество, время и разрешённые команды. Сначала согласуют сетевой доступ и исходные точки, затем применяют настройки и проверяют результат.

Удалённое администрирование Linux-хоста через SSH возможно при подготовленном доступе; этот стендовый запуск не проверял SSH-сеанс или удалённый объект. Состав и условия внедрения KNX / OPC UA.