OPC Туннелирование – Знайте ваши возможности

В этой статье рассматривается, как туннелирование решает трудности, связанные с DCOM, и дает представление о том, на что обращать внимание при выборе продукта OPC туннелирования.

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

В то же время каждый, кто пытался включить OPC в сеть, знает, что это в лучшем случае проблематично. Сетевой протокол для OPC – это DCOM, который не предназначен для передачи данных в режиме реального времени. DCOM трудно настраивается, плохо реагирует на перебои в работе сети и имеет серьезные бреши в системе безопасности. Использование DCOM между разными ЛВС, например, при подключении заводской локальной сети к корпоративной, иногда невозможно настроить. Использование OPC через DCOM также требует больше сетевого трафика, чем некоторые сети могут поддерживать либо в силу ограничений пропускной способности, либо в силу уже имеющейся высокой нагрузки на систему. Для преодоления этих ограничений на рынке существует множество «туннелирующих» решений. В этой статье рассматривается, как туннелирование решает трудности, связанные с DCOM, и дает представление о том, на что обращать внимание при выборе продукта туннелирования OPC.

Исключение DCOM

Цель туннелирования OPC – исключить DCOM, что обычно достигается путем замены сетевого протокола DCOM на TCP. Вместо подключения клиента OPC к подключенному к сети серверу OPC клиентская программа подключается к локальному приложению туннелирования OPC, которая работает как локальный сервер OPC. Приложение туннелирования принимает запросы от клиента OPC и конвертирует их в сообщения TCP, которые затем пересылаются по сети парному приложению туннелирования на компьютере-сервере OPC. Там запрос конвертируется обратно и отправляется серверному приложению OPC для обработки. Любой ответ сервера пересылается по туннелю обратно клиентскому приложению OPC тем же образом.

Так в общем и целом работает большинство туннеллеров OPC. При ближайшем рассмотрении мы увидим, что, хотя все они исключают DCOM, существует несколько принципиально разных подходов к архитектуре туннелирования OPC, что на практике ведет к абсолютно разным результатам. При рассмотрении решений для туннелирования есть четыре аспекта, на которые необходимо обращать внимание:

1. Распространяет ли продукт туннелирования транзакции OPC в сеть или осуществляет их локально?
2. Что происходит с клиентом и сервером OPC во время обрыва сети?
3. Как туннель поддерживает множественные клиент-серверные соединения?
4. Обеспечивает ли продукт туннелирования безопасность, включая шифрование данных, аутентификацию и авторизацию пользователя?

1. Транзакции OPC по сети или локально?

Сегодня на рынке два базовых типа продуктов туннелирования OPC, каждый имеет свой подход к проблеме. Первый передает транзакции OPC в сеть, в то время как второй осуществляет все OPC транзакции на локальном передающем или принимающем компьютере.

Передача транзакций OPC в сеть подразумевает, что типичный запрос клиента OPC передается по сети серверу OPC, а ответ сервера затем проходит весь путь обратно до клиента. К сожалению, данный подход сохраняет синхронную природу подключения по сети с помощью DCOM со всеми ее недостатками. Это оставляет незащищенной каждую клиент-серверную транзакцию OPC при таких сетевых неполадках, как таймауты, задержки, блокирующее поведение. Мониторинг соединения может сократить их влияние, но не исключить его, как мы увидим ниже.

С другой стороны, локальный подход к транзакциям OPC ограничивает клиент-серверные транзакции до их локальных машин соответственно. Например, когда программа туннелирования OPC получает запрос от клиента OPC, она оперативно предоставляет ответ клиенту OPC из данных локальной копии, сохраненной в кэше. На другом конце происходит то же самое. Задача программы туннелирования в таком случае поддерживать две копии данных (на стороне сервера и на стороне клиента) в постоянной синхронизации. Это может быть выполнено очень успешно без перебоев в функционировании клиента и сервера. Как результат, данные проходят по сети как можно меньше, а клиент и сервер OPC защищены от всех сетевых неполадок.

2. Сетевые неполадки — подход к решению

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

Для защиты от сетевых неполадок и обрывов любое хорошее приложение туннелирования предложит какой-либо способ мониторинга соединения. Обычно это делается с помощью «heartbeat» -сообщения: две программы туннелирования шлют друг другу сообщения с определенным интервалом, например, каждые несколько секунд. Если ответ не вернулся в течение заданного пользователем времени, приложение туннелирования полагает, что сеть не работает. После клиент и сервер OPC могут быть информированы, что сеть нарушена.

По сути все довольно просто. Проблема возникает, когда необходимо определить таймаут, используемый для идентификации обрыва сети. Если установить слишком длинный таймаут, клиент может надолго блокироваться в ожидании ответа только для того, чтобы узнать, что сеть не работает. С другой стороны, слишком короткий таймаут даст вам ложный сигнал об отсутствии сетевого соединения, если по какой-то причине период ожидания больше, чем вы рассчитывали. Чем медленнее сеть, тем больше должен быть таймаут.

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

Как именно продукт туннелирования информирует клиента OPC об обрыве сети, также варьируется в зависимости от ее конфигурации. Продукты, выпускающие транзакции OPC в сеть, как правило делают одно из двух:

1. Приводят к остановке сервера OPC. Клиент OPC получает сообщение об остановке, которое якобы исходит от сервера. Не зная об обрыве сети, клиент работает, исходя из предположения, что сам сервер OPC перестал функционировать.
2. Ничего не сообщают клиенту и генерируют обрыв COM, когда клиент в очередной раз инициирует транзакцию. Здесь есть два недостатка. Во-первых, клиент должен уметь обходиться с обрывами COM - событиями, наиболее вероятно приводящими к выходу клиента из строя. Хуже того, поскольку клиенты часто находятся в ждущем режиме, в котором они не инициируют транзакции, клиент может думать, что последние значения данных достоверны и актуальны, не осознавая наличия проблемы.

   Продукты, обеспечивающие локальные транзакции OPC, предлагают третий вариант:

3. Поддерживают соединение COM на протяжении всего обрыва сети и изменяют атрибут элементов данных на «Нет соединения» или аналогичный. Данный подход оставляет OPC-соединение открытым простым и надежным способом, а клиенту не приходится обрабатывать обрывы COM.

3. Поддержка множественных соединений

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

Если вы рассматриваете множественные туннельные соединения, непременно проверьте наличие перекрестного взаимодействия между клиентами. Блокирует ли требующий много времени запрос от медленного клиента другие запросы, находящиеся в обработке? Некоторые туннельные приложения сериализуют доступ к серверу OPC, когда подключено множество клиентов, обрабатывая запросы последовательно. Это может упростить программирование разработчику туннеля, но чревато неприемлемым поведением приложения. Если один клиент делает времяёмкий запрос через туннель, другие клиенты должны встать в очередь и ждать завершения обработки данного запроса, прежде чем дело дойдет до их запросов. Все клиенты блокируются на время обработки самого длительного запроса, что снижает производительность системы и значительно увеличивает время ожидания.

С другой стороны, если туннель обрабатывает запросы OPC локально, данная ситуация просто не произойдет. Транзакции OPC не передаются по сети, а значит, не подвергаются ни сетевым эффектам, ни сериализации.

4. А что с безопасностью?

Когда бы вы ни занимались передачей по сети производственных данных, безопасность — это ключевой вопрос. На самом деле, безопасность — основная причина, чтобы предпочесть туннелирование, а не DCOM. DCOM никогда не предназначался для использования в глобальных сетях, поэтому его модель безопасности спроектирована преимущественно для того, чтобы было легко настроить для использования в централизованно администрируемых ЛВС. Даже попытки настроить безопасность DCOM при взаимодействии между двумя разными сегментами одной локальной сети могут быть крайне трудными. Один из подходов к безопасности DCOM – отгородить файерволом всю систему, так чтобы ничего не проникало ни внутрь, ни наружу, затем выставить менее строгие настройки безопасности на компьютерах внутри файервола. Возможно, это лучшее решение для надежной сети, но это не всегда выход. Иногда вам необходимо передавать данные за файервол, чтобы отправить их через глобальную сеть или даже Интернет. Для таких случаев вам потребуется безопасное соединение. Слабые настройки безопасности DCOM просто неприемлемы.

Большинство экспертов согласны в том, что есть три аспекта сетевой безопасности:

• Шифрование данных необходимо, чтобы обезопасить себя от тех, кто выискивает в сети ваши исходные данные.
• Аутентификация пользователей — это проверка каждого подключившегося пользователя на основе имени пользователя и пароля или другого совместно используемого секретного ключа, такого как пара открытыйличный ключ.
• Авторизация устанавливает права доступа для каждого пользователя, прошедшего аутентификацию, и дает доступ к соответствующей функциональности.

Существует несколько опций, доступных разработчикам туннелирования, для обеспечения этих трех типов безопасности. Некоторые предпочитают разрабатывать собственное решение с нуля. Другие используют стандартные продукты и протоколы, с которыми знакомы многие пользователи. Среди них:

SSL (Secure Socket Layer) — Обеспечивает только шифрование данных, но очень удобен для пользователя. Как правило, вы просто ставите галочку при запуске продукта, чтобы активировать шифрование данных SSL. Продукт туннелирования должен обеспечивать аутентификацию пользователей и авторизацию отдельно.

VPN (Virtual Private Network) — Обеспечивает и шифрование и аутентификацию. VPN не является частью продукта, сам по себе, вместо этого он выполняется операционной системой. Продукт туннелирования затем запускается через VPN, но все еще требуется поддержка авторизации.

SSH (Secure Shell) Tunneling — Обеспечивает шифрование и аутентификацию TCP-соединений. Этот протокол чаще используется в Unix и Linux-приложениях, но может быть эффективен и в MS-Windows. SSH Tunneling может рассматриваться как вид двухточечной VPN.

Поскольку ни один из этих протоколов не охватывает все три области, вам следует убедиться, что продукт туннелирования, который вы выбираете, заполнил недостающие пробелы. Например, не упускает авторизацию. Последнее, что вам нужно, так это чтобы какой-то предприимчивый юный новичок или стажер ненароком не подключился к вашей реальной промышленной системе и не начал изменять элементы данных.

Как узнать? Протестировать!

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

Как вы можете узнать, что вы получаете? Соберите как можно больше информации у разработчика, а затем протестируйте систему. Загрузите и установите несколько подходящих продуктов. (Большинство предлагают временную демо-версию). Максимально точно воспроизведите вашу целевую промышленную систему. Дайте на нее большую нагрузку. Отсоедините сетевой кабель и посмотрите, что будет. Подключите множественных клиентов, если это то, что вы планируете делать. Настройте безопасность. Также рассмотрите другие факторы, такие как простота использования, соответствие стандартам OPC, как программное обеспечение работает с другими, сопутствующими задачами, которые вам придется решать.

Если DCOM вам надоел, туннелирование OPC обеспечивает очень хорошую альтернативу. Это удобный вариант, о котором должен знать каждый инженер или системный интегратор. По меньшей мере, вы определенно сочтете это улучшением по сравнению с настройкой DCOM. А с соответствующими инструментами и подходом вы также сможете сделать его надежным и безопасным, насколько позволит ваша сеть.

Об авторах

Боб МакИлврайд — менеджер по коммуникациям Cogent Real-Time Systems. Имеет диплом магистра профессионального литературного дела, 12 лет опыта написания и публикации технической документации и маркетинговых коммуникаций в отраслях: природный газ и управление технологическими процессами.

Эндрю Томас — президент и сооснователь Cogent Real-Time Systems. Имеет диплом магистра: проектирование систем и искусственный интеллект. Более 15 лет работает в отрасли управления технологическими процессами, преимущественно занимается передачей данных, операционной совместимостью и приложениями искусственного интеллекта в управлении технологическими процессами.

Источник: http://cogentdatahub.com/Download/PDF_Release/OPC_Tunnelling_Options.pdf