Программный продукт SplitOPC

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

Решению подобных задач препятствуют многочисленные трудности:

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

Полностью решить проблему несовместимости интерфейсов и протоколов обмена данными при объединении разнородных АСУ ТП, и предоставить заказчику возможность свободного выбора оборудования и программного обеспечения АСУ ТП без жестких привязок к частно-фирменным решениям позволяет стандарт ОРС (www.opcfoundation.org).

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

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

Рисунок 1. Структурная схема передачи данных

Функциональные возможности

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

Рисунок 2. Структурная схема наименования сигналов

При оценке пропускной способности коммутируемого соединения использовались модемы Zyxel и GSM Siemens TC35i. В последнем столбце приведены значения, рассчитанные исходя из процентного соотношения часто/редко-меняющихся сигналов, встречающегося в реальных условиях на объектах промышленной автоматизации. 

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

С помощью двунаправленного шлюза-конвертора OPC <-> IEC 60870-5-104 появилась возможность интегрировать данные и команды телемеханики, поступающие в этих  форматах,  а также производить преобразование из одного формата в другой в режиме реального времени. Использование решений  позволяет  осуществлять «прозрачную» интеграцию разнородных фрагментов в общую систему. 

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

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

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

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

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

Рисунок 3. Окно настройки SplitOPC

Рисунок 4. Общий вид SplitOPC