Закрыть
Регистрация
Закрыть
Логин:
Пароль:
Забыли свой пароль?
Регистрация
Каталог товаров

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


Одноклассники Facebook LJ Twitter В Контакте
Одна из наиболее сложных задач в области автоматизации технологических процессов и автоматизированного сбора данных – построение территориально распределенных автоматизированных систем и интеграция разнородных систем, связанная с объединением потоков информации от локальных систем сбора данных и управления технологическими объектами. 
Решению подобных задач препятствуют многочисленные трудности:
  • несовместимость локальных систем (по форматам данных, по поддерживаемым интерфейсам и протоколам обмена);
  • в большинстве случаев речь идет об объединении территориально распределенных систем, и здесь на первый план выходят вопросы организации передачи данных, редко встречающиеся при внедрении локальных АСУ ТП. 
Полностью решить проблему несовместимости интерфейсов и протоколов обмена данными при объединении разнородных АСУ ТП, и предоставить заказчику возможность свободного выбора оборудования и программного обеспечения АСУ ТП без жестких привязок к частно фирменным решениям позволяет стандарт ОРС (www.opcfoundation.org).
Для решения задачи качественного сбора и передачи данных существует класс программных продуктов, называемых «коммуникационными» OPC-серверами. 
Наиболее известный – SplitOPC (www.splitopc.ru), впервые появившийся на рынке в январе 2001 г.
и на сегодняшний день не имеющий аналогов среди отечественных и зарубежных продуктов.Только SplitOPC обладает рядом уникальных возможностей, позволяющим создавать географически, иерархически и административно распределенные системы сбора данных и управления в реальном масштабе времени, работающие на низкоскоростных каналах связи (рис. 1).
Рисунок 1. Структурная схема передачи данных

ФУНКЦИОНАЛЬНЫЕ ВОЗМОЖНОСТИ

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

Скорость передачи канала
связи (Кбит/сек)
Количество передаваемых, ежесекундно меняющихся сигналов (шифрации нет)
Количество передаваемых, ежесекундно меняющихся сигналов (шифрация есть)
Расчетное (для реальных объектов автоматизации) количество передаваемых сигналов (шифрации нет)
Коммутируемые линии связи
1200
12
6
52
4800
32
15
140
9600
85
38
340
19200
204
91
860
33600
530
252
2100
Выделенные линии связи
~ 2 Mbit
~ 8 000
~ 3 500
~ 30 000
~ 10 Mbit
~ 60 000
~ 28 000
~ 120 000
~ 100 Mbit
~ 85 000
~ 40 000
~ 200 000
При оценке пропускной способности коммутируемого соединения использовались модемы Zyxel и GSM Siemens TC35i. В последнем столбце приведены значения, рассчитанные исходя из процентного соотношения часто/редко-меняющихся сигналов, встречающегося в реальных условиях на объектах промышленной автоматизации. 
Реализация шлюзов в системы реального времени (например, QNX – «КП телемеханики» на базе контроллеров Moscad) позволяет организовать передачу команд телеуправления и сбор данных в формате OPC без существенных временных и финансовых затрат. При этом значения, получаемые из таких систем, становятся общедоступны в виде OPC тегов, в которые также могут записываться данные для передачи команд телеуправления.
Рисунок 3. Канал Тюмень-Москва

С помощью двунаправленного шлюза-конвертора
OPC <-> IEC 60870-5-104 появилась возможность интегрировать данные и команды телемеханики, поступающие в этих  форматах,  а также производить преобразование из одного формата в другой в режиме реального времени. Использование решений  позволяет  осуществлять «прозрачную» интеграцию разнородных фрагментов в общую систему. 
Указанное на рисунке 3 время задержки в 100 mS учитывает задержку передачи команды непосредственно на промежуточном узле, т.е. время обработки команды и перехода
IP -> OPC -> IP. В случае достаточной пропускной способности канала и гарантированно малого времени прохождения пакета по канальной/сетевой инфраструктуре, это значение может использоваться в качестве коэффициента для предварительного расчета времени прохождения команды телемеханики.
При выполнении этого условия в реальных проектах, для расчета задержки данный коэффициент (100 ms) требуется умножить на количество промежуточных узлов.
Если же время прохождения пакета не гарантированно, как в случае передачи через Интернет, требуется учитывать потери времени на передачу пакета и возможные задержки в коммуникационном оборудовании и производить расчет поправки для каждого конкретного случая. На рисунке 3 показан канал Тюмень-Москва (2 Мбита), для которого величина поправки составляет  ~800 ms, что в результате дает примерно секундную задержку при прохождении команды телемеханики. 
Функциональные возможности и высокая надежность SplitOPC обусловили широкую распространенность продукта – на начало 2005 года в России на базе SplitOPC реализованы десятки распределенных систем сбора данных и управления (телемеханика, системы диспетчерского контроля и управления – СДКУ, узлы учета нефти, АСУ ТП распределенных объектов, и др.), в которых установлено более 300 копий продукта. В числе наших крупных заказчиков такие уважаемые 
компании, как АК «Транснефть», ОАО «Лукойл», ОАО «Роснефть», ОАО «Сибнефть», ОАО «Татнефть», ОАО «ТНК-BP» и другие.
В настоящее время коммуникационный сервер SplitOPC (рис. 4) является единственным решением из всех существующих на рынке, позволяющим без больших интеллектуальных и финансовых затрат построить иерархическую распределенную систему сбора данных, связав разнородные источники информации и полностью опираясь на общепринятые стандарты.
Рисунок 4. Общий вид SplitOPC
 

Компания: Прософт-Системы, ООО
Количество просмотров: 1355
Назад в раздел

Заполните необходимые поля в приведенной ниже форме и нажмите кнопку "Отправить". Мы свяжемся с вами удобным для вас способом, в удобное для вас время.

Ваше имя*
Компания
Должность
E-mail*
Телефон
Ваши вопросы*

Введите текст на картинке *