Главная Пресс-центр Статьи и публикации Взаимодействие с OPC-серверами через Интернет

Взаимодействие с OPC-серверами через Интернет

А.Б. Григорьев, ЗАО «РТСофт»

Статья рассматривает проблемы, возникающие при использовании технологии DCOM в глобальных сетях. Предлагается вариант решения проблемы для OPC-серверов с помощью технологии ISAPI.

 
  Стандарт OPC (OLE for Process Control OLE для управления технологическими процессами), разработанный консорциумом OPC Foundation, становится всё более популярным в АСУ ТП, так как с его помощью можно легко организовать обмен данными между различными программами и устройствами ([1,2]). То, что в основе OPC лежит технология DCOM (Distributed Component Object Model распределённая модель компонентных объектов), определяет как многие сильные стороны стандарта, так и его недостатки (наверное, можно даже сказать, что OPC не имеет никаких серьёзных недостатков за исключением тех, которые имеет DCOM). Один из главных недостатков DCOM неприспособленность для работы в глобальных сетях, в частности, Интернет, являющейся одной из основ интеграции различных подсистем современного предприятия в единое информационное пространство. Передача данных на большие расстояния очень интересует и пользователей АСУ ТП, так как с её помощью можно осуществлять удалённый мониторинг хода технологического процесса, работы оборудования и.п.

 
  Что же мешает связываться через Интернет при использовании DCOM? Первая причина это применение межсетевых экранов, или брандмауэров (firewall), которые призваны защищать компьютер от несанкционированного доступа извне. Защита обеспечивается тем, что весь сетевой обмен идёт через специальный компьютер, на котором установлен брандмауэр, и если пакеты, идущие через сеть, кажутся ему подозрительными, их прохождение блокируется. Технология DCOM может использовать различные транспортные протоколы для передачи данных, в том числе и те, которые пригодны для глобальных сетей (например, TCP/IP). Однако брандмауэры обычно настраиваются таким образом, чтобы существенно ограничить диапазон портов, через которые можно выйти в глобальную сеть. Порты, используемые DCOM, обычно попадают в список запрещённых, а удаление их из этого списка существенно снижает защиту сети против внешних атак. Для решения этой проблемы компания Microsoft предлагает использовать протокол Tunneling TCP, осуществляющий передачу данных через порт 80. Этот порт является стандартным портом для протокола HTTP (HyperText Transfer Protocol протокол передачи гипертекста) и поэтому он обычно открыт.

 
  Использование протокола Tunneling TCP является прозрачным как для DCOM-клиента, так и для DCOM-сервера, но накладывает дополнительные ограничения на систему. Во-первых, при использовании этого протокола 80-ый порт используется не только для HTTP, поэтому брандмауэр должен быть настроен таким образом, чтобы пропускать «неродной» для этого порта протокол. Во-вторых, в систему требуется установить COM Internet Services (CIS специальное ПО, входящее в Windows, которое позволяет использовать Tunneling TCP для DCOM). И в третьих, протокол Tunneling TCP для своей работы требует Internet Information Server (IIS web-сервер, встроенный в ОС Windows) версии не ниже 4.0, установленного на стороне DCOM-сервера. Это накладывает дополнительные ограничения и на операционную систему, потому что IIS устанавливается только на серверные версии Windows (Windows NT 4.0 Server, Windows 2000 Server и т. д.). Более того, если используются интерфейсы обратного вызова (часть технологии DCOM, позволяющая не только клиенту вызывать функции сервера, но и серверу вызывать функции клиента, т. е. организовывать двусторонний обмен), а в OPC они используются, то и на клиентской стороне тоже необходимы CIS и IIS, что влечёт за собой необходимость наличия серверной версии. Более подробно использование протокола Tunneling TCP описано в [3].

 
  Кроме проблем, связанных с передачей данных, существуют проблемы с аутентификацией клиента. Программные технологии Microsoft гарантируют успешный доступ через DCOM в двух случаях: либо когда компьютеры находятся в одном домене, либо когда они находятся в одной рабочей группе, причём в последнем случае на оба компьютера надо зайти с одинаковым именем пользователя. Если указанные условия не выполнены, то, как показывает практика, доступ может быть как разрешён, так и запрещён, причём последнее случается гораздо чаще. Соответственно, использование протокола Tunneling TCP может дать надёжный результат только в пределах одного домена, компьютеры которого разделены брандмауэрами.

 
  Тем не менее, более узкую задачу получение данных от OPC-сервера можно решить и в общем случае (здесь и далее под OPC подразумевается наиболее распространённый стандарт из этой группы OPC Data Access). Один из возможных вариантов решения, разработанный автором этой статьи, описан ниже. Он основан на использовании ISAPI (Internet Server Application Programming Interface). Технология ISAPI очень напоминает по своей сути CGI, в которой web-сервер для генерации части страницы вызывает специальные приложения. (Обычно web-сервер хранит свои страницы в виде HTML-файлов, которые пересылаются клиенту при получении запроса. Однако так можно хранить только статическую информацию. Если же информация должна динамически меняться, используются сценарии. Вместо того, чтобы отправить клиенту готовый файл, web-сервер вызывает сценарий, который, руководствуясь заложенной в него программистом логикой, формирует HTML-файл или его часть, который web-сервер затем пересылает клиенту. Интерфейс CGI (Common Gate Interface) разновидность таких сценариев. Сценарий CGI это обычный исполняемый файл, выводящий на стандартное устройство вывода сгенерированный им HTML-код. Интерфейс CGI поддерживается практически всеми web-серверами на любых платформах. Интерфейс ISAPI, в отличие от CGI, поддерживается только IIS, а также некоторыми другими web-серверами для Windows в качестве расширений.)

 
  В ISAPI вместо приложений используется DLL (динамически компонуемая библиотека). Это позволяет существенно экономить ресурсы сервера и уменьшать время обработки запроса. В нашем случае ISAPI имеет ещё одно важное преимущество перед CGI: сценарий CGI, сформировав необходимую часть страницы, выгружается из памяти, освобождая все ресурсы. Библиотека ISAPI, загруженная один раз, остаётся в памяти до тех пор, пока сервер не начнёт испытывать нехватку памяти, то есть, возможно, никогда, если библиотека интенсивно используется (такое поведение позволяет существенно ускорить все последующие обращения web-сервера к библиотеке). В нашей разработке с помощью ISAPI формируется HTML-страница, отображающая значения переменных OPC-сервера. Просмотр данной страницы возможен с помощью браузера Internet Explorer версии 4.0 и выше. Если бы для формирования страницы использовались сценарии CGI, то каждый раз при вызове сценария требовалось бы установить связь с OPC-сервером, создать в нём группу, получить значения нужных переменных и разорвать связь. Библиотека ISAPI позволяет использовать одно и то же подключение к OPC-серверу много раз.

 
  Библиотека ISAPI может содержать несколько функций. Для вызова конкретной функции необходимо указать её имя в адресе, отделив от имени библиотеки символом»?» (пример можно увидеть на рис. 1, где показан вызов функции Connect). Параметры передаются функции методом GET или POST (основные методы передачи информации серверу от клиента, используемые в HTTP), так же, как и при использовании CGI. Благодаря тому, что библиотека не выгружается из памяти после вызова функции, мы имеем возможность использовать результаты работы одной функции в другой, сохранив их в глобальных переменных библиотеки.

 
 
 
  Взаимодействие с системой начинается со страницы, показанной на рис. 2 качестве примера OPC-сервера используется CCOPC-сервер, описанный в [2]). Эта страница создана с помощью чистого HTML, без использования ISAPI, скриптов и прочих подобных технологий. В верхнее поле пользователь должен ввести имя любого OPC-сервера, установленного на web-сервере. В нижнее поле нужно ввести частоту обновления. Так как web-сервер не может обновлять страницу по собственной инициативе, для отслеживания изменений значений переменных клиент должен время от времени запрашивать у сервера обновление. При нажатии на кнопку «Далее» вызывается функция Connect из библиотеки InetOPCClient.dll. В качестве параметров ей передаются имя OPC-сервера и частота обновления.

 
 
 
  Функция Connect формирует страницу, состоящую из четырёх фреймов, показанную на рис. 1. В левом фрейме отображается список переменных OPC-сервера, к которому произведено подключение. Пользователь может выбрать интересующие его переменные, и тогда их значения будут отображаться в правом фрейме. Эти значения обновляются с частотой, указанной пользователем при подключении. Остальные два фрейма имеют нулевой размер и потому невидимы. Они используются для загрузки скриптов (вставки в HTML-документ программ на языках JavaScript или VBScript; браузер, получив такой документ от web-сервера, выполняет эти программы в режиме интерпретатора), обновляющих содержимое правого фрейма.

 
  Библиотека InetOPCClient.dll может обеспечивать передачу данных одновременно нескольким клиентам, причём разные клиенты могут подключаться к разным OPC-серверам. Для обслуживания каждого из клиентов создаётся отдельная нить. Каждая такая нить получает уникальный числовой идентификатор. Нить создаётся внутри функции Connect. Все остальные функции библиотеки в качестве одного из своих параметров требуют этот идентификатор. Функция Connect, создавая страницу, генерирует на этой странице скрипты, вызывающие другие функции. В этих скриптах прописывается идентификатор, который функция Connect присвоила созданной нити. Это гарантирует, что все функции, вызванные с данной страницы, будут обращаться к той нити, которая была создана функцией Connect, сгенерировавшей данную страницу. Нить при создании подключается к выбранному OPC-серверу и создаёт в нём группу.

 
  Когда пользователь отмечает переменные в списке в левом фрейме, вызывается функция AddItem или DeleteItem библиотеки InetOPCClient.dll. Вызов функции из ISAPI-библиотеки в терминах браузера означает загрузку страницы, которую формирует эта функция. Указанные функции нужны только для того, чтобы добавить переменные в группу, созданную соответствующей нитью (или удалить переменные из группы). Поэтому они генерируют пустые страницы. Эти пустые страницы загружаются в один из невидимых фреймов.

 
  Во второй из невидимых фреймов загружается страница, созданная функцией Refresh. Эта функция используется для обновления содержимого правого фрейма. Страница, которую она формирует, содержит скрипты, обновляющие соответствующие поля в правом фрейме. Скрипт формируется таким образом, чтобы он обновлял только те поля, которые действительно нуждаются в обновлении, т. е. изменились с момента последнего вызова Refresh. Это позволяет существенно сократить трафик, так как чем меньше полей изменяет скрипт, тем меньше его размер. В конце своей работы скрипт выдерживает паузу, заданную пользователем при подключении, и вновь загружает в тот же фрейм функцию Refresh.

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

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

 
  1. Создание с помощью технологии ISAPI web-страницы, отображающей текущие значения переменных любого OPC-сервера, работающего на компьютере, являющимся web-сервером. Небольшая доработка системы может обеспечить связь с любым OPC-сервером, работающим на любом компьютере в локальной сети, в которую входит Web-сервер.

 
  2. Обеспечение независимого подключения произвольного числа клиентов через Интернет к одному и тому же OPC-серверу или к разным серверам.

 
  3. Минимизация трафика за счёт того, что передаются значения только реально изменившихся переменных.

 
  К нерешённым задачам следует отнести прежде всего то, что связь не восстанавливается автоматически. Если на каком-то этапе при очередной загрузке функции Refresh произошёл сбой, всю процедуру подключения придётся проводить заново. По всей видимости, эта задача не может быть решена при использовании стандартных браузеров. Но не только браузеры могут быть HTTP-клиентами. И формат HTML не единственный формат, который можно передавать с помощью этого протокола. Любой текстовый файл может быть передан через HTTP. В связи с этим наиболее целесообразным представляется вариант, при котором разрабатывается специальный текстовый формат, ориентированный на данные, получаемые от OPC-сервера. Разрабатывается также и специальный клиент, который способен получать эти файлы через интернет. Библиотека ISAPI модифицируется таким образом, чтобы на выходе формировать не HTML-файлы, а файлы указанного формата. Клиент должен иметь возможность отдавать полученные им данные другим приложениям. Оптимальный вариант если он при этом будет OPC-сервером, т.е. то, что получил через HTTP, будет отдавать через OPC. В этом случае можно будет не просто отображать данные, полученные от OPC-серверов через Интернет, но и передавать их обычным OPC-клиентам, таким как SCADA-системы (возможная схема подобной системы показана на рис.3).

 
 
 
  Использование такого подхода позволит помимо всего прочего ещё больше уменьшить трафик в глобальной сети. Действительно, при использовании стандартного браузера ISAPI-библиотека вынуждена формировать файлы, которые содержат не только непосредственно данные, но и скрипты, позволяющие браузеру, во-первых, отобразить полученные данные, а во-вторых, сделать очередной запрос по прошествии указанного интервала. Эти скрипты занимают немало места, в разы увеличивая объём передаваемой информации. С другой стороны, оригинальный HTTP-клиент будет содержать весь код, необходимый для выполнения описанных действий, он не будет нуждаться в инструкциях со стороны web-сервера. Поэтому объём служебной информации может быть сведён к минимуму, необходимому для проверки целостности данных. Кроме того, в таком формате можно было бы предусмотреть авторизацию, препятствующую несанкционированному получению данных от удалённого OPC-сервера.

 
  Описанная выше система могла бы стать оптимальным решением во многих ситуациях, где нужно получать данные от удалённого OPC-сервера. Тем не менее, разработка такой системы с коммерческой точки зрения на данный момент не очень целесообразна. Дело в том, что консорциум OPC Foundation готовит к выпуску новый стандарт OPC-XML. Этот стандарт позволит упаковывать данные, полученные от OPC-серверов, в формат XML (eXtensible Markup Language расширяемый язык разметки) открытый текстовый формат, предназначенный для хранения разнородной информации и поддерживаемый браузером Internet Explorer 5.0 и выше, который затем также можно будет передавать по HTTP. Пока нет полной ясности с возможностями стандарта OPC-XML и с отношением к нему производителей SCADA-систем, определить перспективность подобной разработки затруднительно. Коммерчески оправданной подобная разработка может быть только в случае создания конкретного проекта, нуждающегося в подобной системе, при разработке которого нет времени ждать, когда появится стандарт OPC-XML и его поддержка в SCADA-системах.

 
  Список литературы

 
  1. Куцевич И. В., Григорьев А. Б. «Стандарт OPC путь к интеграции разнородных систем», PCWeek, 32-33, 2001

 
  2. Григорьев А. Б. «OPC средство общения разнородных систем», Промышленные АСУ и контроллеры, 4, 2002

 
  3. Levy M., «COM Internet Services», msdn.microsoft.com/library/default.asp?url=/library/en-us/dndcom/html/cis.asp

 
  Тел:742-68-28,

 
  Email:rtsoft@rtsoft.ru

22.04.2014