OPC UA не подключается: диагностика клиента, сервера и сертификатов

На обложке и схемах: реальный контроллер Systeme Electric SM252MESC из каталога SMARTHOFF. Инженерные схемы подготовлены редакцией SMARTHOFF.

Материал подготовлен и проверен инженерной редакцией SMARTHOFF. Дата публикации: 3 августа 2026.

«OPC UA не подключается» — это не один диагноз, а общий симптом целой группы отказов. Поддержка OPC UA с обеих сторон не гарантирует соединение: за одинаковой надписью в двух спецификациях могут стоять разные роли Client и Server, разный объем поддержанных функций, несовместимые настройки безопасности и разные типы аутентификации пользователя.

Быстрее всего проблема локализуется, когда определен этап отказа: сеть → discovery и endpoint → SecureChannel → сертификаты приложений → user identity → Session → адресное пространство → подписки. Дальше проверяют параметры именно этого этапа — не отключая защиту и не меняя все настройки одновременно. Ниже — диагностическая цепочка из девяти шагов, таблица симптомов и StatusCode, матрица совместимости перед закупкой и список данных, которые ускорят проверку.

Что на самом деле означает «поддерживает OPC UA»

OPC UA — модульный стандарт, поэтому сравнивать нужно не надписи, а конкретные параметры двух устройств.

• Роль: Client или Server. Сервер публикует данные, клиент подключается и читает их. Два сервера друг с другом не соединятся: если контроллер — OPC UA Server, роль клиента должна взять на себя SCADA или одна из панелей оператора — поддержку роли Client у конкретной модели сверяют по ее документации.
• Profiles и Facets. Функциональность стандарта описана профилями. Приложение обязано реализовать обязательные Conformance Units заявленного профиля, а опциональные может не поддерживать — это прямо следует из OPC 10000-7, Profile conformance. Поэтому надпись «OPC UA compliant» не сообщает, есть ли, например, методы, события или история.
• Безопасность. Наборы MessageSecurityMode и SecurityPolicy у клиента и сервера должны пересекаться; универсального списка для всех версий нет.
• Аутентификация пользователя. Anonymous, имя и пароль, сертификат пользователя или issued token: сервер принимает только объявленные им типы, и не каждый продукт поддерживает все.
• Данные и сервисы. Read, Write, Browse, Subscription, методы, события, история, поддерживаемые типы данных — включая структуры, если они нужны.
• Лимиты и лицензии. Число сессий, подписок и отслеживаемых элементов, лицензионные опции OPC UA — продуктозависимы и проверяются по документации точной модели и версии firmware/runtime.

Как устроено подключение: этапы, которые проверяют по очереди

Подключение OPC UA-клиента к серверу — последовательность этапов, где каждый следующий зависит от предыдущего: сетевое соединение → GetEndpoints → выбор EndpointDescription → SecureChannel → CreateSession → ActivateSession → Browse и Read/Write → Subscription.

Успешный SecureChannel не доказывает, что пользователь пройдет ActivateSession. Активная Session не гарантирует, что нужный NodeId существует и доступен. Стабильное разовое чтение не означает, что подписки переживут обрыв сети. Диагностика сводится к вопросу: какой этап — последний успешный и какой — первый неуспешный.

Диагностическая цепочка: девять шагов

1. Сеть и фактический адрес сервера

• Симптом: клиент не видит сервер, таймауты до любых сообщений OPC UA.
• Что проверить: IP-связность и маршрут именно с машины клиента; фактический адрес и сетевой интерфейс, на котором работает сервер; DNS, NAT, VPN и межсетевые экраны по пути.
• Подтверждение: транспортное соединение устанавливается, сетевые таймауты из журнала клиента исчезают.
• Не менять наугад: настройки безопасности и учетные записи — на этом этапе они ни при чем.

2. DiscoveryEndpoint и GetEndpoints

• Симптом: сеть работает, но клиент не получает список endpoints сервера.
• Что проверить: адрес DiscoveryEndpoint и результат вызова GetEndpoints — по OPC 10000-4, Discovery именно он дает клиенту информацию, необходимую для открытия SecureChannel. Учтите: администратор может отключить discovery — тогда используют заранее подтвержденные сохраненные параметры.
• Подтверждение: клиент отображает список EndpointDescription сервера.
• Не менять наугад: сертификаты и политики безопасности — пока список endpoints не получен и не изучен.

3. Выбор EndpointDescription

• Симптом: соединение идет «не туда»: неожиданный режим безопасности, внезапный запрос логина, отказ без понятной причины.
• Что проверить: один URL сервера может публиковать несколько EndpointDescription с разными настройками. В описании endpoint — URL, сертификат сервера, MessageSecurityMode, SecurityPolicy, допустимые UserIdentityToken и транспорт (OPC 10000-4, EndpointDescription). Выберите endpoint, согласованный с проектом, а не первый в списке.
• Подтверждение: в журнале клиента виден именно выбранный endpoint.
• Не менять наугад: endpoints не взаимозаменяемы — перебор «наудачу» только запутает картину.

4. Transport, MessageSecurityMode и SecurityPolicy

• Симптом: SecureChannel не открывается; типичный результат — Bad_SecurityPolicyRejected.
• Что проверить: пересечение режимов и политик клиента и сервера; соответствие выбранного endpoint настройкам клиента.
• Подтверждение: OpenSecureChannel успешен в журналах обеих сторон.
• Не менять наугад: не «лечите» отказ переводом сервера на SecurityPolicy None насовсем — это допустимо только как временный контролируемый тест.

5. ApplicationInstanceCertificate и взаимные TrustLists

• Симптом: Bad_SecurityChecksFailed; сертификат попадает в отклоненные.
• Что проверить: при установлении SecureChannel приложения обмениваются сертификатами, и каждая сторона проверяет чужой сертификат по своему списку доверия — так определяет OPC 10000-2, Application Authentication. Доверие настраивается с обеих сторон: сервер должен доверять сертификату клиента, клиент — сертификату сервера. Проверьте также срок действия сертификатов и системное время устройств.
• Подтверждение: сертификаты обеих сторон находятся в доверенных, попыток повторного отклонения в журналах нет.
• Не менять наугад: не включайте автоматическое принятие любых сертификатов. Пути хранилищ и порядок действий зависят от продукта: как это устроено в конкретной платформе, показывает, например, процедура Siemens для S7-1500, но ее шаги нельзя переносить на другие платформы.

6. UserIdentityToken и права пользователя

• Симптом: Bad_IdentityTokenInvalid или Bad_IdentityTokenRejected при активации сессии.
• Что проверить: какие типы identity сервер объявил в endpoint (anonymous, имя и пароль, сертификат пользователя, issued token) и какие учетные данные передает клиент. OPC 10000-2, User Authentication отделяет этот этап от аутентификации приложений.
• Подтверждение: ActivateSession завершается успешно.
• Не менять наугад: сертификат приложения — ошибки identity к нему, как правило, не относятся.

7. CreateSession и ActivateSession

• Симптом: SecureChannel стабилен, но сессия не создается, не активируется или рвется; операции возвращают Bad_SessionNotActivated.
• Что проверить: журналы обеих сторон именно на этапах CreateSession и ActivateSession; тайм-ауты сессии; ограничение числа одновременных сессий по документации продукта.
• Подтверждение: Session активна и живет дольше рабочего цикла клиента.
• Не менять наугад: сетевые параметры и сертификаты, если SecureChannel открывается стабильно.

8. Browse, Read/Write, Namespace и NodeId

• Симптом: Session активна, но узлы не находятся, чтение дает ошибку, запись отклоняется — например, Bad_UserAccessDenied.
• Что проверить: фактическое адресное пространство сервера: таблицу namespaces, точные NodeId, типы данных, права на чтение и запись. Namespace index может измениться после обновления проекта — идентификаторы сверяют по серверу, а не угадывают по имени тега.
• Подтверждение: нужные узлы читаются и пишутся с теми же учетными данными, что и в целевой системе.
• Не менять наугад: настройки безопасности — нехватка прав пользователя не решается сменой SecurityPolicy.

9. Subscriptions, MonitoredItems и восстановление связи

• Симптом: разовое чтение работает, но подписки «замирают», после обрыва сети данные не возобновляются.
• Что проверить: интервалы публикации и выборки, число подписок и отслеживаемых элементов относительно лимитов конкретного продукта, поведение клиента при восстановлении соединения.
• Подтверждение: подписки переживают контролируемый обрыв и восстанавливаются так, как описано в документации.
• Не менять наугад: не сводите интервалы к нулю и не наращивайте подписки без сверки с лимитами — они продуктозависимы.

Сертификаты OPC UA: почему доверие должно быть взаимным

Самая частая путаница — между сертификатом приложения и учетной записью пользователя. Это разные механизмы на разных этапах.

• ApplicationInstanceCertificate удостоверяет само приложение — и клиент, и сервер. Сертификат нужен не «только серверу»: обе стороны предъявляют сертификаты при открытии SecureChannel.
• TrustList — собственный список доверия каждой стороны. Отклонить соединение может и сервер (не доверяет клиенту), и клиент (не доверяет серверу). Поэтому ситуация «сертификат принят в одном месте и отклонен в другом» закономерна: списков доверия два, и настраиваются они независимо.
• User identity — логин и пароль, сертификат пользователя или issued token — передается позже, при ActivateSession, и не заменяет доверие сертификатам приложений.

Отдельный источник отказов — несовпадение HostName или IP: адрес, по которому клиент обращается к endpoint, сверяется с сертификатом сервера, и при несовпадении один клиент ограничится предупреждением, а другой откажется соединяться. Отсюда типовой сценарий «сменили IP или имя сервера — все пропало»: сохраненный endpoint устарел, сертификат перестал соответствовать адресу. Лечение — повторное discovery и актуализация сертификата, а не отключение проверок.

SecurityPolicy: как тестировать, не отключая защиту

Перевод сервера на SecurityPolicy None — не исправление и не производственный режим. Допустим только временный контролируемый тест: по документации производителя, с согласия службы, отвечающей за безопасность объекта, и с обязательным возвратом безопасной конфигурации сразу после проверки. Универсально «лучшей» политики не существует: доступный набор зависит от продукта и версии, а выбор — от требований проекта.

Таблица симптомов и StatusCode

StatusCode — результат конкретной операции, а не готовый диагноз всей системы: у одного кода бывает несколько причин (OPC 10000-4, StatusCode).

Почему тестовый клиент — не доказательство совместимости

UAExpert и аналогичные инструменты незаменимы для локализации этапа отказа: ими удобно проверять GetEndpoints, доверие сертификатам и чтение узлов. Но успешное подключение тестового клиента не доказывает, что заработает целевая SCADA: она может использовать другой endpoint, другую SecurityPolicy, другой тип identity и другие функции — структуры, события, плотные подписки. Совпадать должны настройки и функциональный объем именно целевой пары «клиент — сервер», поэтому финальную проверку выполняют на целевых продуктах.

Матрица совместимости перед закупкой

До выбора артикула сверьте по документации обоих устройств:

• роли: кто Client, кто Server;
• необходимые проекту Profiles, Facets и сервисы;
• операции: Read, Write, Browse, Subscription; события, методы, история — только если они действительно нужны;
• типы данных, включая структуры;
• пересечение MessageSecurityMode и SecurityPolicy;
• поддерживаемые типы UserIdentityToken;
• лимиты sessions, subscriptions и monitored items — по документации точной модели;
• версия firmware/runtime и лицензионные опции;
• endpoint и сетевые условия: DNS, NAT, VPN, правила объекта;
• журналирование и поведение при восстановлении соединения.

Универсальных «правильных» значений здесь нет: матрица заполняется под конкретную пару устройств и конкретный проект.

Пример: контроллер с ролью OPC UA Server — SM252MESC

Как выглядит начало такой проверки, удобно показать на конкретной модели. Контроллер Systeme Electric SM252MESC в официальной карточке производителя заявлен как OPC UA Server; модель программируется в CODESYS, а руководство показывает пример сети, где контроллер доступен системе диспетчеризации как OPC UA Server. Роль OPC UA Client для этой модели производитель не заявляет — значит, подключаться к контроллеру должна SCADA или панель с ролью клиента.

Строка «OPC UA Server» в карточке — начало проверки, а не гарантия совместимости. Поддерживаемые профили, политики безопасности, типы identity и лимиты сессий по-прежнему сверяют с документацией конкретной версии — против требований конкретного клиента. Карточка Systeme Electric SM252MESC в каталоге SMARTHOFF — коммерческий маршрут к этой модели; технические параметры проверяются по документации производителя.

CTT и сертификация: что они проверяют

OPC Foundation развивает Compliance Test Tool — инструмент проверки клиентских и серверных продуктов на соответствие спецификации в объеме заявленных Profiles и Conformance Units; выпуск версии V1.05.06 показывает, что проверка соответствия — живая, развивающаяся практика. Доступ к инструменту и условия его использования определяет OPC Foundation.

Важно видеть границы. Локальный прогон CTT — это проверка соответствия заявленному объему, а не сертификация продукта. Сертификация OPC Foundation шире: помимо compliance она проверяет interoperability, robustness, usability и resource efficiency. Но и сертификат не обещает функцию, которой нет в заявленном объеме, — поэтому сверка профилей и сервисов остается задачей проекта.

Какие данные передать инженеру

Чтобы проверка совместимости была предметной, соберите:

1. точные модели и версии firmware/runtime клиента и сервера;
2. роли: кто Client, кто Server;
3. схему сети: адреса, DNS, NAT, VPN;
4. используемый endpoint;
5. выбранные MessageSecurityMode и SecurityPolicy;
6. тип user identity — без передачи паролей;
7. полный текст StatusCode и этап, на котором происходит отказ;
8. экспорт или скриншот результата GetEndpoints без секретов;
9. требуемые NodeId, namespace и типы данных;
10. нужные операции: Read, Write, Subscription, события, история;
11. ожидаемое число сессий, подписок и тегов;
12. журналы клиента и сервера с очищенными учетными данными;
13. лицензии и ограничения целевой SCADA и ПЛК.

С этим набором инженер SMARTHOFF может сверить пару «клиент — сервер» по документации и предложить подходящие контроллеры для систем автоматизации под требуемые роли и функции. Диагноз по одному скриншоту не обещаем: качество проверки определяется полнотой исходных данных.

FAQ: частые вопросы про подключение OPC UA

Если оба устройства поддерживают OPC UA, почему они не соединяются?

Потому что OPC UA — модульный стандарт. Роли Client и Server, профили, политики безопасности, типы identity и наборы сервисов у продуктов разные. Проверьте пересечение возможностей по документации и определите этап, на котором происходит отказ.

Чем сертификат приложения отличается от логина пользователя?

Сертификат приложения удостоверяет программу и проверяется при открытии SecureChannel. Логин и пароль (или сертификат пользователя) — это user identity, который передается при ActivateSession. Это разные этапы с разными ошибками, и одно не заменяет другое.

Почему UAExpert подключается, а SCADA — нет?

Вероятно, они используют разные endpoint, SecurityPolicy, тип identity или разные функции сервера. Сравните параметры подключения обоих клиентов и требуемый функциональный объем: тестовый клиент локализует этап отказа, но не доказывает совместимость целевой пары.

Нужно ли отключать SecurityPolicy для диагностики?

Как постоянное решение — нет. Допустим только временный контролируемый тест по документации производителя и политике безопасности объекта, с обязательным возвратом безопасной конфигурации после проверки.

Почему после смены IP или имени сервера связь пропала?

Сохраненный endpoint мог устареть, а сертификат сервера — перестать соответствовать новому адресу. Выполните повторное discovery, проверьте выбранный endpoint и актуализируйте сертификат вместо отключения проверок.

Что проверить при выборе контроллера с OPC UA?

Роль (Client или Server), нужные проекту профили и сервисы, политики безопасности, типы identity, лимиты сессий и подписок, версию firmware/runtime и лицензии — по документации точной модели, как в примере с SM252MESC.

Первичные источники

• OPC 10000-4: Discovery и GetEndpoints
• OPC 10000-4: EndpointDescription
• OPC 10000-4: StatusCode
• OPC 10000-2: Application Authentication
• OPC 10000-2: User Authentication
• OPC 10000-7: Profile conformance
• OPC Foundation: Compliance Test Tool (UACTT)
• OPC Foundation: How to Certify
• Systeme Electric: карточка SM252MESC и руководство ПЛК SM252MESC
• Siemens: Handling client and server certificates (S7-1500)