Подключение к opc серверу из 1с
1С-MS InduLink позволяет интегрировать MasterSCADA с любыми конфигурациями 1С (версии 8.3 и выше). Но самым эффективным будет использование MasterSCADA с конфигурацией 1С:ERP Управление предприятием 2.0, предназначенной именно для автоматизации учета на производственных предприятиях.
С помощью модулей 1С-MS InduLink реализуется в автоматическом режиме двухсторонний обмен всей необходимой информацией баз данных MasterSCADA и 1С. При этом 1С никак не вмешивается в работу систем под управлением MasterSCADA, надежность работы которой остается на том же высоком уровне.
Модули 1С-MS InduLink обеспечивают обмен между MasterSCADA и 1С именно теми данными, которые нужны в конкретной системе.Использование предлагаемого продукта наиболее востребовано при реализации учета ресурсов, систем оперативного управления предприятиями, в производствах, выпускающих продукцию под заказ по специфическим рецептурам или комплектациям.
Так, для учета расхода ресурсов производственных предприятий (как энергетических, топливных, так и материальных потоков) из MasterSCADA в 1С могут передаваться интегральные или средние значения расходов за заданные периоды, информация о превышении лимитов и т.п.
В производственных системах из 1С в MasterSCADA могут передаваться рецептуры продукции, задания на объем производства, перечень выполняемых операций и т.п., а обратно поступать информация о расходах материалов или комплектующих, объемах выпуска.
В системах оперативного управления производством из 1С в MasterSCADA может передаваться информация по планируемой загрузке оборудования, плановым операциям технического обслуживания оборудования, а обратно – сведения о реальном пробеге оборудования (моточасы), коэффициенте его загрузки и др.
Получаемая MasterSCADA из 1С информация может использоваться в качестве непосредственных заданий для управляемого оборудования. А данные из MasterSCADA могут анализироваться учетной системой и использоваться для построения отчетов и других управленческих операций.
Существенную гибкость в построении автоматизированных систем обеспечивает и широкий набор универсальных интерфейсов MasterSCADA, которая помимо перечисленной функциональности во взаимодействии с 1С, может также выступить в качестве программного моста между 1С и любыми иными производственными системами.
Модуль 1С-MS InduLink разработан совместно с NIRAX. Компания NIRAX оказывает услуги по настройке и адаптации модуля под конкретные системы.
На днях пришлось крепко повозиться с настройкой вызова удалённого сервера по протоколу OPC DA 2.05a, и эта информация бы очень пригодилась, знай я её заранее.
1. Что такое OPC DA и в частности OPC DA 2.05a
В общем случае OPC — это набор открытых протоколов, регламентирующих взаимодействие между собой различных объектов автоматизации, таких как SCADA-системы, к примеру. OPC DA (Data Access) — это один из таких протоколов, он обеспечивает обмен данными с устройствами или программными компонентами. В моем случае по этому протоколу нужно было периодически забирать данные со SCADA-системы. И самое важное — OPC DA работает на базе технологии COM, так что взаимодействие с OPC сервером по сути сводится к взаимодействию с COM сервером.
2. Какие есть библиотеки
Бинарники от Opc Foundation
Компоненты от Advasol
Платные компоненты (причем весьма дорогие). Скачал я Evaluation версию — инсталлятор, который потребовал пароль (!), ну а пароль пришел по почте. Самое полезное в этом наборе компонент — тестовые клиенты для OPC — winforms приложения, позволяющие попробовать приконнектиться и посмотреть, что есть внутри OPC сервера. Сами библиотеки я не смотрел, они обфусцированы и в них заложено ограничение по времени — полчаса, потом программу надо перезапускать. Но с тестовым клиентом возился долго, так как система у меня была 64битная, а сборка тестового клиента, как оказалось, собрана под Target Platform = AnyCPU, и в 32битной винде запускалась как 32битное приложение (и все работало как надо), а в 64битной — как 64битное. Что приводило к ошибке в коде COM-интеропа вида «CLSID is not registered». А я думал, что у меня что-то неправильно настроено и 2 дня убил на копания в secpol.msc, dcomcnfg и compmgmt.msc. По счастливой случайности догадался запустить клиент с другой тачки и все стало ясно. С помощью ILDASM и Hex-редактора определил смещение флага TargetPlatform (от начала CLR Header), добавил туда второй бит 32BITREQUIRED и все заработало. Вывод — если у вас не работает COM Interop, первым делом проверьте соответствие платформы. К слову, клиент тоже был обфусцирован (с помощью SmartAssembly), и его CLR Header был расположен в конце.
Библиотека OPCDOTNET
3. Можно ли написать код без использования библиотек
В принципе, ничего сложного в этом нет, если вы имели опыт взаимодействия с COM/DCOM приложениями. А тем, кто как и я, не особо разбирается в этих технологиях, могу порекомендовать писать код, поглядывая на декомпилированные исходники библиотеки от OPC Foundation. По сути, для взаимодействия с OPC сервером достаточно всего лишь сделать интеропы на необходимые интерфейсы, получить их и дергать методы.
4. Проблемы
— Тестовый клиент не подключается с ошибкой RPC сервер недоступен — проверьте доступность портов, порта номер 135 как минимум (основной порт DCOM).
— Access Denied — придется повозиться с настройкой как сервера, так и клиента. См. ссылки внизу
— CLSID is not registered — проверьте, установлен ли у вас Core Components, возможно их не хватает. Либо проверьте Target Platform сборки, осуществляющей интероп. Может быть, там AnyCPU а должно быть x86.
— CoCreateInstanceEx возвращает валидный COM объект, но при касте его к COM интерфейсам вываливается Access Denied (0x80070001). С этой проблемой я возился полдня. Эта штука происходит, когда для доступа к серверу необходимо указать юзера и пароль. Вы вызываете CoCreateInstanceEx, заполнив перед этим SERVER_INFO, и вам приходит ссылка на объект. Однако следующие вызовы QueryInterface не сохраняют параметров доступа, которые вы указали при получении объекта, и это приводит к Access Denied. Решение — вызвать магическую функцию CoInitializeSecurity, которая установит дефолтные параметры безопасности для COM-вызовов. Код:
При вызове этой функции может случиться ошибка RPC_E_TOO_LATE. Эта ошибка возникает обычно из-за хост-процесса Visual Studio, который неявно вызывает CoInitializeSecurity при старте. Для решения проблемы достаточно отключить использование хост-процесса в настройках проекта.
5. Ссылки по теме
OPC Training Institute — сайт с множеством отлично оформленных статей, которые помогают в случае проблем. Например, как настроить DCOM, какие возможные причины ошибки RPC server is not available итд. Требует регистрации, регистрация бесплатна.
Туториалы по настройке DCOM — еще 1 хорошо оформленный туториал для настройки.
При написании данной заметки использовались следующие материалы:
3. On-line справка Step 7 Professional V15.1
4. SIMATIC S7-1500, ET 200MP, ET 200SP, ET 200AL, ET 200pro Communication. Function Manual (10/2018 A5E03735815-AG)
5. Здравый смысл
Радикально ситуация меняется в ноябре-декабря 2018 года с выходом прошивки 2.6 и Step 7 версии 15.1. Появляется возможность настроить CPU в качестве OPC UA клиента. А это, в свою очередь дает нам возможность организовать защищенный канал обмена информацией машина-машина (контроллер-контроллер). И это важно (про существование Secure OUC мне так же известно, однако OUC являет собой обмен данными в свободном формате, чего хватает для маленьких объемов, но отсутствие строгого формата данных накладывает свой отпечаток…). Большинство протоколов полевого уровня для промышленности разрабатывалось в прошлом веке и рассчитаны они, в первую очередь, на честных людей. Только время идет, честных людей становится меньше, злодеев - больше, поэтому обмен данными надо как можно лучше спрятать, зашифровать, запаролить, обложить сертификатами, а всем посторонним в ответ показывать обидные жесты и говорить неприличные слова.
Итак, настройка контроллера (S7-1512 FW2.6) в качестве OPC UA сервера.
По умолчанию OPC UA отключен в настройках, поэтому заходим в свойства CPU, ищем ветку OPC UA → Server → General и активируем OPC UA Server.
2. Использование OPC UA в контроллерах Simatic требует приобретение лицензии, поэтому покупаем лицензию, заходим в свойства Runtime licenses → OPC UA и ставим тип приобретенной лицензии. Лицензии для 1500ой серии бывают трех типов: маленькая, средняя и большая, в зависимости от типа CPU. S7-1510 и S7-1512 требуют «small».
3. По желанию можно задать Application name для OPC UA сервера, порт и временные интервалы. Интервалы сбора (sampling) и публикации (publishing) я выставил минимальными. Стоит помнить, что уменьшение интервалов повышает нагрузку на CPU. Имя приложения и номер порта оставил по умолчанию.
4. Базовая настройка закончена. Компилируем и грузим PLC.
5. Пора бы и проверить, работает ли вообще. Запускаем программу OPC UA Client (ее можно скачать с SIOS по первым двум ссылкам в начале заметки). Ставлю ip адрес моего контроллера — 192.168.43.10 и нажимаю кнопку Get Endpoints. Получаю возможные «точки входа»
Захожу по самому первому варианту, без сертификатов, без шифрования, без пароля, нажимаю «Connect to selected Endpoints» и перехожу на вкладку «Browse nodes». В контроллере загружена программа управления котельной, нахожу одну переменную (Node или узел — так называется «тэг» или «переменная» в протоколе)
В правой верхней части есть строчка Node id (идентификатор узла или «адрес переменной»), выделяю его мышкой и жму Ctrl-C
Перехожу на вкладку Read/Write, вставляю скопированный node id и нажимаю кнопку Read
Получаю прочитанное значение переменной равное 3. Действительно, все совпадает, насосы отопительного контура должны чередоваться в третий день недели, и именно эта цифра вбита в переменную DayOfWeek блока данных OKPumpsAuto.
Закрываю программу. Базовый функционал есть, и он работает. Но этого мало. Сейчас OPC UA сервер настроен на режим «заходи, кто хошь, бери, че хошь». Необходимо добавить немного безопасности.
6. Включаем «глобальные настройки безопасности» в свойствах CPU, Protection&Security → Certificate Manager, ставим галочку Use global settings…
7. В навигации всего проекта находим Security Settings → Settings. Смело нажимаем кнопку Protect this project. Действие необратимое. Снять защиту с проекта уже не получится. Дело в том, что оффлайновый проект будет содержать сертификаты серверной и клиентской машины, они должны быть защищены во избежании покражи. После нажатия кнопки Protect система предложит создать администратора проекта:
Теперь любое открытие проекта TIA Portal будет требовать ввода логина и пароля. Кроме администратора проекта, разумеется, можно и нужно создать пользователей с меньшими правами.
8. После того, как мы активировали глобальные настройки безопасности, необходимо заново вручную сгенерировать сертификат контроллера. В дальнейшем лучше, конечно же, сразу защищать проект, создавать администратора проекта и ставить контроллерам «глобальные настройки безопасности», но данная заметка частично носит общеобразовательный характер. Возвращаемся в настройки CPU, ищем OPC UA → Server →Security
Нажимаем кнопку «…» рядом с надписью «Server certificate»,а в появившемся окне — кнопку «Add new».
Создаем новый сертификат устройства, все значения остаются по умолчанию. Сертификат, как видно, подписан серьезной организацией! В итоге все становится вот так:
Сейчас предлагаю скомпилировать проект, загрузить его в ПЛК и проверить программой, как работает связь. На самом деле, в результате последних изменений в настройках уровень секьюрности не поднялся ни на йоту. Все это было лишь подготовительным процессом. Потихоньку приходит время приступать к настройкам контроллера, который будет играть роль OPC UA клиента, проверить обмен данными, ну а потом уже закрыть все бреши в безопасности. Но вначале необходимо выгрузить xml файл с описанием всех тэгов (узлов, nodes) контроллера-сервера. Этот файл формируется достаточно просто — система выбирает только те переменные, которые помечены флагом Accessible from HMI/OPC UA и разрешает их запись, если стоит флаг Writable from HMI/OPC UA . При этом блок данных тоже должен быть доступен по OPC UA (по умолчанию доступен). Например:
Для экспорта снова заходим в настройки CPU и ищем там OPC UA → Server → Export, нажимаем кнопку «Export OPC UA XML file»
Переходим к настройкам OPC UA клиента, то есть той стороны обмена, которая будет инициировать связь, запрашивать и записать переменные. В качестве клиентской части у меня выступает S7-1510 с прошивкой FW2.6.
9. Добавляю контроллер в проект и сразу активирую глобальные настройки безопасности.
10. Активирую OPC UA клиента
11. Активирую лицензию OPC UA
12. Генерирую сертификат этого второго, клиентского контроллера. В дальнейшем контроллер-сервер и контроллер-клиент обменяются (не без моей помощи) своими сертификатами, а подключение незнакомых устройств будет запрещено. В свойствах CPU идем на Protection & Security, жмем Add new.. в таблице Device certificates, жмем на кнопку «…» в появившейся пустой строке, жмем «Add new» в появившемся окне, наблюдаем уже знакомое окно создания нового подписанного сертификата:
В поле usage я дополнительно указал, что сертификат используется для OPC UA Client'а, по умолчанию у меня был выставлен Tls.
13. Наступает одно из самых интересных: настройка клиентского интерфейса,а точнее — настройка соединения к серверу и создания наборов данных для чтения и/или записи. В структуре проекта у второго (клиентского) контроллера:
PLC_2 → OPC UA communication → Client Interfaces →Add new client interface
Жмем кнопку «Import interface» и подгружаем ранее экспортированный XML файл
Теперь открыты все Nodes серверного контроллера. Поскольку стоит задача учебного характера, требуется немного — просто считать 4 переменных блока OKPumpsAuto.
Для этого я создаю Readlist и перетаскиваю интересные мне переменные из правой части экрана в левую. Разумеется, в боевых задачах список чтения может быть больше. Разумеется, в боевых задачах будет не только чтение, но и запись переменных. В этой заметке ограничился одним чтением. В итоге у нас получается следующее:
Итого у нас создан один интерфейс, состоящий из одного списка чтения. Набор данных для чтения подготовлен. Но чего-то не хватает, необходимо еще настроить само соединение интерфейса. Для этого открываем вкладку Properties в нижней части экрана
Необходимо прописать ip-адрес сервера, в моей случае 192.168.43.10.
На странице Security выбираем ранее созданный клиентский сертификат и пока ничего более не меняем.
Создание и заполнение клиентского интерфейса привело к автоматическому созданию двух блоков данных: Client interface_1_Data и Client interface_1_Configuration.
Смотрим блок данных Data, там уже указаны те переменные, которые планируем читать. Чертовски удобно.
14. Теперь необходимо написать программу, которая будет устанавливать связь с OPC UA сервером, готовить канал связи, читать информацию и закрывать соединение. Программа носит строго демонстрационный характер, в боевых задачах она должна быть написана по-другому. В онлайн справке на вызываемые блоки находится все необходимая информация. Там же приводится пример на языке SCL, лучше подходящий к промышленному применению, но не такой наглядный, как в моем случае.
В проект добавляются следующие меркерные переменные
Ищем функцию OPC_UA_Connect и перетаскиваем ее в нетворк OB1
Имя экземплярного блока я оставил по умолчанию. Что радует — этот вызов имеет графический конфигуратор, как, например, вызовы S7-связи в TIA Portal'е или вызов PID-регулятора. Этот конфигуратор экономит просто уйму времени, а это не может не радовать.
Остается выбрать только созданный клиентский интерфейс (он один) и обвязать блок вспомогательными переменными.
Для лучшего понимания привожу скриншот из онлайн справки Step 7. Именно в таком порядке необходимо выполнять вызовы (как минимум три) перед тем, как приступить к чтению/записи данных. Любой вызов выполняется по переднему фронту входа Req. Успешное или неуспешное выполнения вызова я фиксирую (не сбрасывая, сброс только ручной) в переменных с именами done или err.
Теперь привожу скриншоты всех нетворков программы уже после того, как я последовательно сделал запрос на выполнение функциональных блоков. Как вы видите бит запроса req у меня выставлен в истину (блок отрабатывается только по переднему фронту), биты успешного исполнения (done) выставлены в истину. Если у вас ни done, ни error не выставляется в истину,а connectionid первого вызова остается равным нулю, значит, что-то сделано не так. Например, используется не тот Server Endpoint или неправильно установлен сертификат. Эти вызовы должны вызваться последовательно один за другим. Я взводил биты руками и смотрел на результат вызова, а только потом переходил к следующему. Очевидно, что полноценная программа должна осуществлять вызов автоматически и переходить на следующий шаг в зависимости от результата текущего.
Нетворк 4 — самый важный, это цепочка чтения данных с сервера. Ради него все и делалось. Остальные нетворки вызывают функциональные блоки закрытия соединения и освобождения ресурсов. Их я пока не вызывал.
В результате вызова нетворка 4 в блоке данных DB2 появились прочитанные данные:
15. В настоящий момент два контроллера общаются по протоколу OPC UA, цель почти достигнута. Но не полностью. Настройки безопасности до сих пор находятся на уровне «бери, чо хошь». Я спокойно могу подключиться программой OPC UA Client и читать/записывать все возможные данные. Давайте ограничим круг общения этих ПЛК, пусть они «дружат» только друг с другом. Переходим на серверный контроллер, свойства CPU, OPC UA → Server → Security → Secure channel, убираем из Endpoint'ов политику «No Security»
Проматываем ниже до Trusted Clients. Добавляем сертификат контроллера-клиента (PLC_2). Снимаем галочку Automatically accept client certificates during runtime. Сервер теперь не будет общаться ни с кем, кроме как с клиентским PLC.
Переходим на User authentication, запрещаем гостевой доступ, создаем логин/пароль для пользовательского доступа: user1 / password1.
Прогружаем серверный PLC. Возвращаемся к клиентскому PLC, открываем Client interface, закладка Configuration, выбираем Security, в поле General выставляем режим и политику безопасности:
Проматываем ниже, выбираем тип аутентификации — пользователь и пароль, указываем имя пользователя user1, пароль password1
Снимаем галочку Automatically accept server certificate during runtime
Жмем на зеленую стрелочку, сразу переходим на другую закладку настроек ищем там поле «сертификаты партнерских устройств» и добавляем в него сертификат сервера
Компилируем и прогружаем клиентский ПЛК (PLC_2), открываем мониторинг OB1 и последовательно вручную исполняем блоки в нетворках 1..4 Если все сделано правильно, то все блоки отработают успешно, а данные будут успешно прочитаны в DB2.
16. Осталось лишь проверить, пустит ли кого-нибудь еще серверный контроллер. Запускаем OPC UA Client и пробуем подключиться. Список Endpoint'ов возвращается. Подключаемся по Basic256 SignAndEncrypt, указав имя пользователя user1 и пароль password1.
Предлагается проверка сертификата сервера, принимаем его
Но соединение не устанавливается, сервер не принимает сертификат «левого» клиента.
Итого, поставленная цель достигнута. Настроен безопасный обмен данными на уровне ПЛК, то есть - "горизонтальное" взаимодействие.
В предыдущих нескольких статьях, мною были описаны возможности применения протокола modbus для создания собственной Scada системы на базе python. В этот раз хочется поделиться опытом построения системы опроса подчиненных устройств с использованием ОРС технологии.
Недостатки OPC серверов в том, что их можно использовать только в операционных системах семейства Microsoft Windows (как правило они платные), а об устройствах использующих ОС Linux можно было забыть.
Но со временем была создана спецификация OPC Unified Architecture (англ. Унифицированная архитектура OPC), что дало возможность использовать данную технологию передачи данных на иных операционных системах отличных от Windows. Это касается и встраиваемых систем, где может быть запущен полноценный Linux.
Подробнее можно прочитать здесь.
Например, на одноплатном компьютере Raspberry Pi можно запустить одновременно несколько различных OPC UA серверов для опроса терминальных устройств, счетчиков, датчиков и т.д., при этом система будет работать вполне стабильно.
Установка библиотек
Для работы с OPC UA и modbus серверами используются Xubuntu 17.04 Desktop и Windows 8.1. В Xubuntu 17.04 уже установлены Python 2.7 и Python 3.5 по умолчанию. Выбираем Python 3.5.
Если после установки операционной системы на компьютер не были добавлены необходимые пакеты, то нужно выполнить:
Решаем проблему зависимостей:
После поставим еще необходимые библиотеки:
Для windows можно установить через pip3.exe, библиотека и примеры находятся здесь
Для запуска сервера, библиотеку нужно импортировать:
Теперь создаем OPC UA сервер.
Вот и весь код на python для запуска OPC UA. Как оказалось ничего сложного, и если теперь подключиться к запущенному серверу с помощью UA Expert, то можно увидеть иерархический список наших объектов и переменных со значениями.
Для модификации значений переменных используется функция set_value типа:
Конечно это очень примитивный пример, но в библиотеке OPC UA заложено намного больше возможностей, о которых можно прочитать здесь.
Единственное в чем не удалось разобраться, так это, как установить логин и пароль на сервер, вроде как-то посредством politics, думаю позже решу эту проблему.
Конфигуратор серверов
В продолжение к вышесказанному, возникла задача по оперативному конфигурированию каждого вновь создаваемого сервера.
Для данной цели был написан «Конфигуратор серверов» на библиотеке PyQt5.
Принцип работы:
— создается база данных на sqlite3
— формируются таблицы для slave и master частей сервера.
— таблицы заполняются необходимыми параметрами.
— формируется скрипт запуска.
Структура каталогов:
srvconf.py – программа «Конфигуратор сервера»
db – находится файл базы данных srvDb.db.
img – файлы .jpg для кнопок
source – файлы шаблонов серверов
Для Windows будет создан файл типа start_XX.bat, для Linux файл типа start_XX.sh, где ХХ порядковый номер сервера в таблице servers.
Содержимое файла start_XX.bat:
Содержимое файла start_XX.sh для Linux:
В параметрах запуска для Linux используется xfce4-terminal, т.к. работаю в Xubuntu 17.04,
но можно указать и другой тип запуска, вроде gnome-terminal.
В примерах довольно понятно описаны параметры заполнения таблиц.
Управление на данный момент реализовано частично и только в master_dcon, поэтому используется только телесигнализация и телеизмерения. В дальнейшем думаю добавить и телеуправление.
Это наиболее простой и небезопасный вариант подключения, который не рекомендуется использовать при подключении к OPC UA серверам. Отдать предпочтение следует другим вариантам подключения, которые задействуют политику безопасности. Доступны три варианта политики безопасности, которые различаются используемым алгоритмом безопасности и длиной ключа:
• Basic128Rsa15 - устарела и больше не считается безопасной.
• Basic256Sha256 - самый безопасный вариант.
Внимание! Первая попытка подключения к OPC UA серверу с включенной политикой безопасности будет безуспешной! Для создания безопасного канала связи, Simple-Scada и OPC UA сервер сначала обменяются сертификатами, при этом, OPC-сервер автоматически поместит сертификат Simple-Scada в список недоверенных сертификатов и Simple-Scada не сможет подключиться к OPC-серверу до тех пор, пока администратор OPC-сервера не переместит сертификат в список доверенных вручную.
Последний шаг - выбор способа аутентификации. Доступны следующие варианты:
• Анонимный - информация о пользователе недоступна.
• Имя пользователя и пароль - для авторизации на OPC-сервере используется имя пользователя и пароль.
• Сертификат безопасности - для авторизации используется путь к файлу X509v3-сертификата (в формате ".pfx") и пароль к нему.
Внимание! Simple-Scada передаст указанный сертификат OPC-серверу после первой попытки подключения и OPC-сервер поместит его в список недоверенных сертификатов пользователей. Администратор OPC-сервера должен вручную переместить сертификат в список доверенных сертификатов пользователей!
Для примера рассмотрим вариант безопасного подключения к тестовому OPC UA серверу Prosys OPC:
После нажатия кнопки "Создать", Simple-Scada и OPC UA сервер обменяются сертификатами, при этом, OPC-сервер автоматически поместит сертификат Simple-Scada в список недоверенных сертификатов. Отобразится окно о неудачной попытке подключения:
Далее, необходимо вручную переместить сертификат в список доверенных. Нажмем "ОК", перейдем в интерфейс OPC-сервера и добавим сертификат в список доверенных:
После этого, повторно нажмем кнопку "Создать" - теперь OPC UA сервер будет успешно добавлен.
Параметры OPC-UA сервера
Если выделить добавленный OPC-сервер, то можно просмотреть информацию о нем и изменить параметры:
• Максимум тегов на подписку - эта опция позволяет задать максимальное количество тегов в одной подписке. Скада будет автоматически создавать доп. подписки, если превышено это значение. 0 - добавлять все теги в одну подписку (рекомендуется).
• Максимум тегов на запись - скада при необходимости отправляет UA-серверу запросы на запись тегов. Один запрос может содержать множество тегов, в которые нужно записать значение. Данная опция позволяет ограничить количество тегов в одном запросе. Если установить значение равное 1, то в одном запросе на запись будет только один тег. 0 - без ограничений (рекомендуется).
• Чтение после записи - если опция активна, то сразу после записи будет выполняться чтение, чтобы максимально быстро получить новое значение переменной. Эту опцию лучше всего использовать когда частота опроса переменных достаточно редкая, но после записи не хочется ждать пока значение переменной обновится.
• Метка времени - определяет из какого источника нужно брать метку времени для тегов OPC-сервера. Доступны варианты:
▪ OPC-сервер - получать метку времени от OPC-сервера.
▪ Источник - взять метку времени из переменной.
▪ Компьютер - использовать время компьютера.
• Расширенные настройки - дополнительные настройки OPC сервера. Рекомендуется изменять их только при проблемах в работе с OPC-сервером.
▪ Тайм-аут сессии - время, в течение которого сеанс должен оставаться открытым без активности.
▪ Тайм-аут подключения - время ожидания при попытке установления подключения, по истечении которого будет выдана ошибка подключения.
▪ Тайм-аут запросов - время ожидания ответа от UA-сервера на запросы скада-системы, по истечении которого скада прекратит ждать ответ и выдаст ошибку.
▪ Проверка статуса - частота, с которой будет проверяться статус OPC-сервера. Чем меньше это значение, тем быстрее будет обнаружена проблема связи.
▪ Реакция на BadNodeIdUnknown - после подключения к UA-серверу скада пытается подписаться на переменные, чтобы отслеживать их изменения. Если в конфигурации UA-сервера не существует таких переменных, то он возвращает ошибку BadNodeIdUnknown. Данная опция определяет реакцию на ошибку BadNodeIdUnknown:
▪ прекратить попытки подписаться - скада не будет предпринимать попыток подписаться на переменные, которые отсутствуют в конфигурации UA-сервера.
▪ попытаться подписаться позже - скада будет периодически пытаться подписаться на такие переменные. Данная опция подходит для UA-серверов, которые меняют конфигурацию во время работы. Например, сначала часть переменных отсутствует в конфигурации и скада не может на них подписаться, затем они добавляются в конфигурацию, скада предпринимает новую попытку и успешно подписывается.
• Имя в скриптах - используя это имя, к UA-серверу можно обратиться через скрипты (например, для вызова методов).
Читайте также: