Одна из наиболее сложных задач в области автоматизации технологических процессов и автоматизированного сбора данных – построение территориально распределенных автоматизированных систем и интеграция разнородных систем, связанная с объединением потоков информации от локальных систем сбора данных и управления технологическими объектами.
Решению подобных задач препятствуют многочисленные трудности:
- несовместимость локальных систем (по форматам данных, по поддерживаемым интерфейсам и протоколам обмена);
- в большинстве случаев речь идет об объединении территориально распределенных систем, и здесь на первый план выходят вопросы организации передачи данных, редко встречающиеся при внедрении локальных АСУ ТП.
Полностью решить проблему несовместимости интерфейсов и протоколов обмена данными при объединении разнородных АСУ ТП, и предоставить заказчику возможность свободного выбора оборудования и программного обеспечения АСУ ТП без жестких привязок к частно фирменным решениям позволяет стандарт ОРС (
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
