| Author |
Message |
|
Written on: 07. 11. 2013 [16:32]
|
|
rxs5
Дмитрий Лыков
In tech support
registered since: 06.11.2013
Posts: 205
|
Здравствуйте.
Продолжу тему про UAExpert и OPC UA.
Использую UAExpert Version:1.2.2 175 и OpenSCADA 0.8.1 и OPC_UA 0.6.2
Настроил входной транспорт и транспортный протокол (скриншоты).
При использовании UAExpert происходит успешный коннект и отображается в дереве только папка Root (скриншот).
В логах UAExpert имеются ошибки (выделил цветом).
Сравнивая с Вашим скриншотом UAExpert, заметил следующее:
1. У Вас в Root отображается перечень DAQ, хотя по логу из UAExpert подключаемся к определенному источнику DAQ.OPC_UA
Строка
14:20:42.783 | Server Node | ........ | ApplicationUri: 'localhost/OpenSCADA/DAQ.OPC_UA'
2. Интересно посмотреть скриншот Ваших настроек транспортного протокола OPC UA при рабочем варианте подключения UAExpert.
3. Также интересно посмотреть лог подключения Вашего UAExpert к OPC UA из OpenSCADA.
Attachment
|
|
Written on: 07. 11. 2013 [20:37]
|
|
roman
Roman Savochenko
Moderator Contributor Developer
registered since: 12.12.2007
Posts: 3750
|
"rxs5" wrote:
Продолжу тему про UAExpert и OPC UA.
Использую UAExpert Version:1.2.2 175 и OpenSCADA 0.8.1 и OPC_UA 0.6.2
Настроил входной транспорт и транспортный протокол (скриншоты).
Сборка 0.8.1 старая если там даже запрос на подпись не обрабатывается.
Сертификат на сервере, как и на клиенте нужны в обязательно порядке.
"rxs5" wrote:
2. Интересно посмотреть скриншот Ваших настроек транспортного протокола OPC UA при рабочем варианте подключения UAExpert.
Зачем, скрин, просто возьмите и запустите ДемоБД(АГЛКС), там рабочая и замкнутая на себя конфигурация, но работает и с UAExpert.
"rxs5" wrote:
3. Также интересно посмотреть лог подключения Вашего UAExpert к OPC UA из OpenSCADA.
Вложил.
В целом, на данный момент, оптимизирована клиентская часть, а серверная ещё имеет проблемы, основная из которых это неполноценная реализация Publish сервиса, который UAExpert требует в обязательном порядке. Это приводит к тому, что минут через 10 соединение теряется. Проблема в том, что сервис Publish асинхронный, т.е. ответ идет секунд через 5 после запроса, что входной транспорт+протокол в OpenSCADA не поддерживал, вот только утряс изменения в API OpenSCADA на этот предмет и в ближайшее время реализую нормально. Кроме того хотел серверную часть оптимизировать как и клиентскую: автоматически создавать транспорт для протокола, с нужными настройками, и разделить объект EndPoint на типы: Discovery, Server, Gate.
Learn, learn and learn better than work, work and work.
Attachment
OpenSCADA_UA.png (File type: image/png, Size: 146.83 kilobytes) — 1169 downloads
|
|
Written on: 08. 11. 2013 [15:09]
|
|
rxs5
Дмитрий Лыков
In tech support
registered since: 06.11.2013
Posts: 205
|
"roman" wrote:
В целом, на данный момент, оптимизирована клиентская часть, а серверная ещё имеет проблемы, основная из которых это неполноценная реализация Publish сервиса, который UAExpert требует в обязательном порядке. Это приводит к тому, что минут через 10 соединение теряется. Проблема в том, что сервис Publish асинхронный, т.е. ответ идет секунд через 5 после запроса, что входной транспорт+протокол в OpenSCADA не поддерживал, вот только утряс изменения в API OpenSCADA на этот предмет и в ближайшее время реализую нормально. Кроме того хотел серверную часть оптимизировать как и клиентскую: автоматически создавать транспорт для протокола, с нужными настройками, и разделить объект EndPoint на типы: Discovery, Server, Gate.
Спасибо за пояснения. Роман, у вас есть какие-то ориентиры по срокам работ по OPC UA ?
Возможно серверная часть будет использоваться в нашем проекте, и необходимо понять по срокам когда и чего следует ожидать.
|
|
Written on: 09. 11. 2013 [17:51]
|
|
roman
Roman Savochenko
Moderator Contributor Developer
registered since: 12.12.2007
Posts: 3750
|
"rxs5" wrote:
Спасибо за пояснения. Роман, у вас есть какие-то ориентиры по срокам работ по OPC UA ?
Я с ним работу возобновил пару месяцев назад, а сейчас она несколько замедлилась.
Но объекты уведомлений думаю на этих выходных, или в крайнем случае со следующей недели, сделаю. Как минимум эта работа профинансирована и есть контрагент, хотя и пустышка в сервисе Publish.
"rxs5" wrote:
Возможно серверная часть будет использоваться в нашем проекте, и необходимо понять по срокам когда и чего следует ожидать.
Если так то Вам нужно понять какие сервисы Вы вообще будете использовать, поскольку Publish клиентом может и не использоваться вовсе, как и в ранних версиях UAExpert, что и сейчас работает. С другой стороны на вашем киенте могут использоваться иные сервисы, которых у меня живьём нет, а без реального контрагента их как правило не реализуешь, во всяком случае в рабочем виде.
Learn, learn and learn better than work, work and work.
|
|
Written on: 20. 12. 2013 [15:34]
|
|
rxs5
Дмитрий Лыков
In tech support
registered since: 06.11.2013
Posts: 205
|
Можно как-то ограничивать видимость объектов на стороне сервера OPC UA, чтобы клиенту OPC UA после подключения был доступен только список явно указанных модулей ?
В более простом варианте: чтобы клиент видел только 1 из модулей DAQ, а все остальные модули закрыть от обзора.
|
|
Written on: 20. 12. 2013 [18:20]
|
|
roman
Roman Savochenko
Moderator Contributor Developer
registered since: 12.12.2007
Posts: 3750
|
"rxs5" wrote:
Можно как-то ограничивать видимость объектов на стороне сервера OPC UA, чтобы клиенту OPC UA после подключения был доступен только список явно указанных модулей ?
В более простом варианте: чтобы клиент видел только 1 из модулей DAQ, а все остальные модули закрыть от обзора.
Нельзя, а после полной реализации проверки прав доступа будет или всё видно или видно и доступно для модификации.
Для описанного выше в дополнение нужно добавлять ACL с отдельным перечнем узлов и правами доступа.
Learn, learn and learn better than work, work and work.
|
|
Written on: 23. 12. 2013 [16:46]
|
|
rxs5
Дмитрий Лыков
In tech support
registered since: 06.11.2013
Posts: 205
|
Анализировал дампы подключений OPC UA серверов ignition и openscada. Клиент - IWS.
Заметил различия:
1. Подтверждение от клиента после CreateSessionResponse
В ignition
12 0.018704000 192.168.195.97 192.168.195.192 OpcUa 951 UA Secure Conversation Message: CreateSessionResponse
идет подтверждение создания сессии со стороны клиента
13 0.018760000 192.168.195.192 192.168.195.97 TCP 54 54614 > bre [ACK] Seq=501 Ack=3981 Win=65536 Len=0
В openscada нет такого подтверждения.
А вот после активации сессии идет подтверждение от клиентов и для сервера OpenSCADA и для сервера Ignition
2. Отличия внутри CreateSessionResponse
OpcUa Binary Protocol
OpcUa Service : Encodeable Object
CreateSessionResponse
SessionId: NodeId
NodeId Namespace Id: 1337 - в ignition есть поле
AuthenticationToken: NodeId
NodeId Namespace Id: 1337 - в ignition есть поле
Array of ServerEndpoints
[0] : EndpointDescription
Array of UserIdentityTokens
TransportProfileUri: [OpcUa Null String] - в ignition не пустое значение
SecurityLevel: 0 - в ignition не 0-е значение
ServerSignature : SignatureData
Signature: <MISSING>[OpcUa Null ByteString] - в ignition не пустое значение
|
|
Written on: 23. 12. 2013 [17:28]
|
|
roman
Roman Savochenko
Moderator Contributor Developer
registered since: 12.12.2007
Posts: 3750
|
"rxs5" wrote:
1. Подтверждение от клиента после CreateSessionResponse
В ignition
12 0.018704000 192.168.195.97 192.168.195.192 OpcUa 951 UA Secure Conversation Message: CreateSessionResponse
идет подтверждение создания сессии со стороны клиента
13 0.018760000 192.168.195.192 192.168.195.97 TCP 54 54614 > bre [ACK] Seq=501 Ack=3981 Win=65536 Len=0
В openscada нет такого подтверждения.
Я уже говорил, что OpenSCADA не шлёт такого и не может поскольку это внутреннее дело TCP стека, кроме того спецификация OPC_UA TCP этого не регламентирует!
"rxs5" wrote:
2. Отличия внутри CreateSessionResponse
SessionId: NodeId
NodeId Namespace Id: 1337 - в ignition есть поле
Наличие NameSpace и вид NodeId вообще сервер определяет из своих внутренний соображений.
"rxs5" wrote:
AuthenticationToken: NodeId
NodeId Namespace Id: 1337 - в ignition есть поле
Наличие NameSpace и вид NodeId вообще сервер определяет из своих внутренний соображений.
"rxs5" wrote:
Array of ServerEndpoints
[0] : EndpointDescription
Array of UserIdentityTokens
TransportProfileUri: [OpcUa Null String] - в ignition не пустое значение
SecurityLevel: 0 - в ignition не 0-е значение
У тестовых примеров от UnifiedAutomation "TransportProfileUri" пустое и в целом для меня не понятное. SecurityLevel больше вопрос рекомендации использования.
"rxs5" wrote:
ServerSignature : SignatureData
Signature: <MISSING>[OpcUa Null ByteString] - в ignition не пустое значение
Это поле не нужно для нешифрованного канала, т.е. политики безопасности "None" и в тех-же тестовых примерах от UnifiedAutomation отсутствовало.
Learn, learn and learn better than work, work and work.
|
|
Written on: 24. 12. 2013 [18:59]
|
|
rxs5
Дмитрий Лыков
In tech support
registered since: 06.11.2013
Posts: 205
|
Вопрос по записи значений через OPC UA.
При чтении клиентом UAExpert заметил, что у всех параметров атрибут WriteMask равен 0.
Соответственно записывать значения в данные параметры мы не можем.
Дальше, посмотрел в исходниках, там такая ситуация
http://oscada.org/svn/tags/openscada_0.8.0/src/moduls/daq/OPC_UA/libOPC_UA/libOPC_UA.cpp
case AId_WriteMask: case AId_UserWriteMask: req.setAttr("type", int2str(OpcUa_UInt32))->setText("0"); return 0;
и
http://oscada.org/svn/tags/openscada_0.8.0/src/moduls/daq/OPC_UA/mod_prt.cpp
case AId_WriteMask: case AId_UserWriteMask: req.setAttr("type", i2s(OpcUa_UInt32))->setText("0"); return 0;
Т.е. в WriteMask всегда записывается 0. Значит это значения только для чтения. Но если нам необходимо делать запись через OPC UA, то для некоторых параметров необходимо указать WriteMask=1.
Возможно сделать доступ для параметра в OpenSCADA для установки значения поля, которое бы потом считывалось в WriteMask протокола OPC UA ?
|
|
Written on: 24. 12. 2013 [19:53]
|
|
roman
Roman Savochenko
Moderator Contributor Developer
registered since: 12.12.2007
Posts: 3750
|
"rxs5" wrote:
Вопрос по записи значений через OPC UA.
При чтении клиентом UAExpert заметил, что у всех параметров атрибут WriteMask равен 0.
Соответственно записывать значения в данные параметры мы не можем.
С чего Вы это взяли?
Возможность записи определяется:
case AId_AccessLevel: case AId_UserAccessLevel:
req.setAttr("type", i2s(OpcUa_Byte))->setText(i2s(ACS_Read | (nVal->fld().flg()&TFld::NoWrite ? 0 : ACS_Write)));
Во всяком случае в клиенте проверяется именно AccessLevel и OpenSCADA клиент на сервер пишет.
Learn, learn and learn better than work, work and work.
|
