Фильтр по тематике

Создание распределённых систем сбора данных на основе стандарта OPC

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

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

Следуя общей логике и тенденциям развития бизнес-процессов, вслед за контролем над финансовыми и товарными потоками, автоматизацией основных организационных функций предприятия переходят к решению задач оперативного контроля над производственными процессами и к обеспечению «сквозной прозрачности» бизнеса на основе полной и достоверной информации.

На российском рынке систем автоматизации технологических процессов с некоторой задержкой относительно общих тенденций развития информационных систем начинает формироваться совершенно новый класс задач – интеграционные, связанные с объединением потоков информации от разнородных локальных систем сбора данных и управления технологическими объектами. Решению подобных задач препятствуют многочисленные трудности, во-первых, связанные с несовместимостью локальных систем (по форматам данных, по поддерживаемым интерфейсам и протоколам обмена), во-вторых, в большинстве случаев речь идёт об объединении территориально распределённых систем, и здесь на первый план выходят вопросы организации передачи данных, редко встречающиеся при внедрении локальных АСУ ТП. В такой ситуации решение, лежащее на поверхности, – построение специализированной масштабной системы с полной или частичной заменой существующих АСУ ТП и решением коммуникационных задач — зачастую возможно лишь при неограниченном бюджете проекта, что безусловно является исключением.

Те же вопросы, связанные с организацией передачи данных, возникают и при необходимости проектирования любой территориально (географически) распределённой АСУ ТП.

Кроме того, при построении масштабных систем сбора данных и управления достаточно часто встречаются задачи, для которых не находится оптимального решения в рамках предлагаемых одним поставщиком программно-аппаратных средств, и вновь возникают проблемы совместимости разнородного оборудования и программного обеспечения.

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

Промышленно развитые страны столкнулись с этими вопросами значительно раньше, что и вызвало к жизни появление первого единого стандарта для организации сбора и передачи данных в системах промышленной автоматизации – ОРС, позволяющего, с одной стороны, полностью решить проблему несовместимости интерфейсов и протоколов обмена данными при объединении разнородных АСУ ТП и, с другой стороны, дающего заказчику возможность свободного выбора оборудования и программного обеспечения АСУ ТП без жёстких привязок к частнофирменным решениям. Процесс обмена информацией с технологическими устройствами происходит внутри OPC-серверов – программ, поставляемых как производителями оборудования, так и независимыми разработчиками. (На разработке OPC-серверов специализируются многие компании, например Automated Solutions, Kepware, Matrikon, Cybtec и другие.)

Но наряду с очевидными достоинствами технологии ОРС присущ и ряд существенных недостатков, до последнего времени серьёзно ограничивающих использование стандарта ОРС в качестве основы построения масштабных территориально распределённых АСУ ТП. Прежде всего, протокол OPC создавался на базе COM/DCOM для обмена данными между OPC-приложениями в рамках одного компьютера/локальной сети и нестабильно работает в случае межсегментной передачи данных. При этом возникает множество проблем по настройке DCOM в географически и административно разделённых сетях.

Сложности, появляющиеся при создании территориально (географически) распределённых проектов, существенно отличаются от проблем, решаемых в ходе создания локальных систем «нижнего» уровня — АСУ ТП и систем уровня управления предприятием (ERP). Прежде всего возникают вопросы, связанные с организацией каналов передачи данных как от поставщиков данных (контроллеров, УСПД, УСО), так и между иерархическими уровнями системы, зачастую разделенными сотнями километров. В большинстве случаев существующие каналы связи не отличаются качеством и надёжностью, а построение специализированных линий передачи данных невозможно по экономическим причинам. Это значит, что программное обеспечение, отвечающее за обмен информацией между объектами системы, должно уметь устойчиво передавать достаточно большие объёмы информации по низкоскоростным линиям, автоматически реагировать на часто возникающие коллизии и разрывы связи, самостоятельно осуществлять выбор наиболее коротких маршрутов передачи данных в случаях, когда имеющиеся каналы передачи перестают работать и появляются новые.

Следующий вопрос возникает при выборе стандарта передачи данных. Стандарт для передачи данных желательно иметь открытый, широко распространённый, поддерживаемый большинством независимых разработчиков и оборудования, и программного обеспечения (в частности, SCADA-систем). И если по транспортному уровню на эту роль оптимально подходит протокол TCP/IP, то с протоколом верхнего уровня ситуация остаётся неясной. Идеальным ответом было бы использование одного и того же протокола на всех уровнях создаваемой системы. Стандарт ОРС как раз годится на роль универсального, но при условии решения проблем, связанных с функционированием COM/DCOM.

Решение нашлось с появлением нового класса программных продуктов, названных «коммуникационными» OPC-серверами. Их основная задача – качественная передача данных. В табл. 1 представлены некоторые из них.


В таблице оценивались только основные функциональные возможности, наиболее важные с точки зрения передачи данных.

В данной статье более подробно рассматривается коммуникационный ОРС-сервер SplitOPC, впервые появившийся в январе 2001 г. и с тех пор занимающий лидирующие позиции в соответствующем сегменте рынка. На сегодняшний день он не имеет аналогов среди отечественных и зарубежных программных продуктов. С момента появления первой версии SplitOPC постоянно совершенствовался, в реальных условиях оттачивались алгоритмы работы, добавлялись новые функциональные возможности. На текущий момент на сайте проекта www.splitopc.ru доступна для загрузки уже четвертая версия. Временная лицензия позволяет запустить и полностью использовать все возможности SplitOPC в течение 30 дней.

Одним из основных отличительных достоинств SplitOPC (на которые он изначально и был ориентирован) является высокая производительность и устойчивость в условиях работы с большими объёмами данных по каналам связи низкого качества.

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

  • «Сквозная» передача данных, независимо от нахождения узлов в различных сегментах локальной/глобальной сети, учитывая установленные брандмауэры (firewall).
  • Определение и создание нового маршрута доступа к данным в случае разрыва старого (динамическая перемаршрутизация). Автоматически находится новый (резервный) путь передачи данных в случае потери связи по работающему маршруту. При восстановлении более короткой цепочки передачи информации маршрут вновь автоматически перестраивается с целью уменьшения накладных расходов.
  • «Горячее» резервирование с автоматическим «подхватом» роли в случае выхода из строя основного сервера (требуется дублирование серверов).
  • Поддержка криптозащиты любых сегментов межсетевого трафика с произвольной длиной ключа. На рис. 1 приведён пример построения распределённой системы передачи данных с использованием перечисленных возможностей.
  • Поддержка таблиц глобальных псевдонимов тегов OPC. Позволяет создавать псевдонимы для уже имеющихся в системе сигналов, что очень удобно при подключении к информационной сети уже имеющихся АСУ и технологического оборудования, максимально сокращает трудозатраты на подключение.
  • Система именования сигналов, позволяющая дать уникальное имя каждому сигналу, строится по аналогии с доменной структурой имён (DNS), позволяя точно определять, какому уровню принадлежат те или иные данные. Например, на рис. 2 показано, как с помощью таблиц глобальных псевдонимов и системы именования сигналов возможно «упорядочение» структуры имён сигналов и автоматическое построение иерархической системы, в которой пользователь, находящийся, к примеру, в Казани, по имени тега MSK.TUM.NBR.NAD.Pout получает доступ к значению сигнала с именем 142_Pвых, сформированному контроллером в ранее установленной АСУ ТП в районе Надыма.
  • Высокая скорость передачи большого количества тегов (до 200 000) в режиме реального времени, использование уникальных алгоритмов сжатия, позволяющих передавать требуемые объемы данных по низкоскоростным каналам связи (табл. 2). При оценке пропускной способности коммутируемого соединения использовались модемы 3COM, Zyxel и GSM Siemens TC35i. В последнем столбце приведены значения, рассчитанные исходя из процентного соотношения часто/редко меняющихся сигналов, встречающегося в реальных условиях на объектах промышленной автоматизации.
  • Гарантированное время для прохождения команд управления достигается работой встроенной системы приоритетов, при этом команды управления имеют наивысший приоритет.
  • Указание прав доступа (чтение, запись) к определенным группам сигналов предотвращает возможность несанкционированной отдачи команды или изменения значений.

Указанное на рис. 3 время задержки в 100 мс учитывает задержку передачи команды непосредственно на промежуточном узле, то есть время обработки команды и перехода IP→OPC→IP. В случае достаточной пропускной способности канала, например, в локальной сети, и гарантированно малого времени прохождения пакета по канальной/сетевой инфраструктуре это значение может использоваться в качестве коэффициента для предварительного расчёта времени прохождения команды управления. При выполнении этого условия в реальных проектах для расчёта задержки данный коэффициент (100 мс) требуется умножить на количество промежуточных узлов.


Если же время прохождения пакета не гарантировано, как в случае передачи через Интернет по имеющимся каналам связи, требуется учитывать потери времени на передачу пакета и возможные задержки в коммуникационном оборудовании и производить расчёт поправки для каждого конкретного случая.

На рис. 3 показан канал Москва-Тюмень (2 Мбит/с) для которого величина поправки составляет ~800 мс, что в результате даёт примерно секундную задержку при прохождении команды управления.

Столь богатая функциональность и высокая надёжность работы SplitOPC обусловили широкую распространённость продукта – в частности, на начало 2005 года в России и в сопредельных государствах на базе SplitOPC реализованы десятки распределённых систем сбора данных и управления (системы диспетчерского контроля и управления – СДКУ, узлы учёта нефти, АСУ ТП распределённых объектов и др.), в которых установлено более 300 копий продукта. В числе наших крупных заказчиков такие уважаемые компании, как АК «Транснефть», ОАО «Лукойл», ОАО «Роснефть», ОАО «Сибнефть», ОАО «Татнефть» и другие.

В конце 2004 года компания ПРОСОФТ-Системс была принята в ряды некоммерческой организации OPC Foundation, что позволило разработчикам SplitOPC получить полный доступ к наработкам международного сообщества в области технологии ОРС и, в частности, успешно провести полный тест на соответствие SplitOPC всем спецификациям OPC DA 2.0 (тесты OPC Compliance).

Построение на базе SplitOPC масштабных распределённых систем сбора данных и управления представляется одним из оптимальных решений на рынке, как с точки зрения технических характеристик, так и по экономическим критериям, учитывая непрерывный рост популярности стандарта ОРС, связанный с появлением все большего числа ОРС-серверов, охвативших практически все типы используемого в системах промышленной автоматизации оборудования (не только контроллеры, но и интеллектуальные датчики, расходомеры и т.п.).

Большой опыт внедрения многоуровневых систем в различных отраслях и широкий спектр разработанных компанией ПРОСОФТ-Системс программных продуктов (OPC-серверы, компоненты для создания верхнего уровня) позволяют применять OPC-решения на стыке с другими стандартами (МЭК-86…-101, ModBus и т.п.), использующимися в промышленной автоматизации.

В настоящее время коммуникационный сервер SplitOPC является единственным решением из всех существующих на рынке, позволяющим без больших интеллектуальных и финансовых затрат построить иерархическую распределённую систему сбора данных, связав разнородные источники информации и полностью опираясь на общепринятые стандарты. ● 

Авторы — сотрудники ООО «ПРОСОФТ-Системс», г. Екатеринбург
Телефон: (343) 376-2820,
факс: (343) 376-2830

Комментарии
Рекомендуем

ООО «ПРОСОФТ» 7724020910 2SDnjdbfYK3
ООО «ПРОСОФТ» 7724020910 2SDnjdbfYK3