Журнал «Автоматизация и IT в энергетике»




НОВЫЙ НОМЕР ЖУРНАЛА №3,2017

Новый отраслевой журнал «Автоматизация и IT в НГК»
Оформить подписку на журнал «Автоматизация и IT в НГК» прямо сейчас!

Краткие новости

Конференция

В отеле InterContinental заказчики и поставщики встретились с производителями нефтегазоперерабатывающего оборудования.

Подробнее...
 

XXII Международная специализированная выставка «Сургут. Нефть и Газ – 2017»

С 27 по 29 сентября 2017 года в г. Сургуте состоится XXII Международная специализированная выставка «Сургут. Нефть и Газ – 2017».
Подробнее...
 

17-я международная выставка «НЕФТЕГАЗ-2017» и Национальный нефтегазовый форум-2017

17 – 20 апреля 2017 года в Москве состоятся главные отраслевые события –17-я международная выставка «НЕФТЕГАЗ-2017» и Национальный нефтегазовый форум-2017.
Подробнее...
 

Archived

Главная

Интеграции и организация информационных потоков в системах диспетчерского управления НГК

19.12.2010 г.

В статье Н.К. Богданова  и Н.И. Сушковой (ЗАО «АтлантикТрансгазСистема»), опубликованной в журнале  АИТНГО № 2-2010, рассматривается автоматизация функциональных обязанностей диспетчера на современном НГК, которая обеспечивается не только АСУТП (SCADA-системой), но и множеством других программ - от электронных таблиц Excel до систем моделирования. В статье рассмотрены типовые информационные потоки между всем множеством программных инструментов  диспетчерского управления. Приведены методы реализации информационного взаимодействия.

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

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

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

Какая архитектура информационного взаимодействия: индивидуально настраиваемого между каждой парой компонентов, которым необходим доступ к информации друг друга, или с подключением компонентов и передачей информации через интеграционный модуль - наиболее эффективна? Оба подхода применяются и однозначного ответа, какой из них лучше, практика не дает [Применительно к задаче создания единой системы уровней предприятия и филиалов показано возможное, наиболее рациональное решение: все информационные стыки, так или иначе связанные с подсистемой реального времени, остаются непосредственными, т.е. организованными между источником и конечным получателем информации и, таким образом, речь идет об интеграции данных. Однако для производственных задач, выполняемых по регламенту, целесообразно обеспечить интеграцию приложений с использованием специального коммуникационного программного обеспечения.

В качестве примера рассмотрены предпосылки создания и механизмы реализации следующих информационных потоков между: передача данных между SCADA-системой и долгосрочным архивом; взаимодействие SCADA-системы с ПО гидравлического моделирования; архивирование расчетов (включая прогнозы) моделирования в долгосрочном архиве; взаимодействие комплекса производственных задач (диспетчерское управление вне реального времени) с  долгосрочном архивом; передача данных из комплекса производственных задач в SCADA-систему; взаимодействие подсистем реального времени уровней диспетчерских предприятия и филиала; специальная задача обмена оперативными сообщениями между уровнями предприятия и филиала; взаимодействие долгосрочных архивов уровней предприятия и филиала; обеспечение доступа специального коммуникационного ПО к долгосрочным архивам, данным производственного управления; передача данных в системы анализа и финансово-хозяйственного управления.

SCADA-система ↔ Долгосрочный архив

Любая SCADA-система имеет встроенную возможность архивирования поступающих значений для последующего построения графиков. Однако эти оперативные архивы ограничены по времени или объему данных. При необходимости работы с данными большого временного интервала работать с архивом сырых данных нецелесообразно. Применение системы долгосрочного архивирования снимает как ограничения по объемам/срокам хранения, так и обеспечивает функции автоматического расчета средних значений за временные интервалы (час, сутки, месяц, год). Важно, что в отличие от SCADA-системы, где каждый из параметров, по которым настроены сбор и архивирование данных, используется индивидуально, то для данных, сохраненных в долгосрочном архиве, частыми являются выборки временного ряда не одного конкретного параметра, а группы, в которую по некоторому признаку объединены несколько объектов. Для этого необходимо хранить нормативно-справочную информацию о типизации объектов SCADA-системы. Ввод и поддержание актуальности этой НСИ может осуществляться или человеком с помощью специализированного интерфейса, или НСИ может выгружаться из SCADA-системы автоматически, наряду с оперативными данными. Хранение НСИ реализуется в специальной модели данных (структуре таблиц), не связанной непосредственно с моделью оперативных данных. В случае реализации долгосрочного архива средствами реляционной СУБД, наиболее распространенный механизм - SQL-запросы вставки данных, однако система архивирования может быть реализована и как активный элемент, собирающий значения при их изменениях, и использующий для связи со SCADA-системой, например, связку OPC-клиент - OPC-сервер. Доступ к сохраненным в архиве значениям обычно необходим для формирования отчетов и осуществляется из специализированных программ. Но и обратная передача значений в SCADA-систему может быть задействована, если в долгосрочный архив поступают данные еще и от других систем и требуется обеспечить их визуализацию на АРМ диспетчера наряду с данными реального времени. Примером могут служить результаты прогнозного моделирования.

SCADA-система ↔ Система моделирования

Для эффективного и безопасного управления такими сложными объектами как сеть трубопроводов, нефтяной или газовый промысел, важно знать информацию о состоянии объекта не только на текущий момент, но и на ближайшее или даже предсказуемо далекое будущее. Это достигается использованием систем моделирования, которые, в общем случае, обладают функциональностью: 1) оперативного моделирования. По ряду измеренных параметров рассчитывают профили основных технологических параметров и значения, которые невозможно измерить, такие как запас газа в трубе или потери при транспортировке. Сравнение результатов расчетов с текущими измерениями позволяет в определенной степени контролировать состояние оборудования КИПиА. 2) Прогнозного моделирования, позволяя заранее предсказать изменение параметров технологического процесса при текущих условиях и оценить  желательность такого развития событий. 3) Вариантного моделирования, когда оценка будущего состояния производится с учетом подачи в определенные моменты управляющих воздействий (открытие/закрытие кранов, пуск/останов агрегатов).

Исходя из вышесказанного, передача информации из SCADA-системы в систему моделирования необходима для постоянного поддержания последней в актуальном состоянии; возврат результатов оперативных и прогнозных расчетов в  SCADA-систему является механизмом гарантирования информированности и готовности к принятию решений диспетчером. Поскольку наилучшие результаты достигаются при моделировании крупного участка сети, то желательно моделировать целиком всю сеть на уровне предприятия, возвращать результаты в SCADA-систему ЦДП и затем из нее раздавать рассчитанные и прогнозные значения в SCADA-системы отдельных филиалов.

Примером внедрения двунаправленного стыка системы моделирования и SCADA-системы может служить система поддержки принятия решений в центральной диспетчерской межпромыслового коллектора Уренгойского НГКМ, система моделирования потоков газа «АСТРА», по переданным в нее текущим параметрам, определяет направления и объемы перетоков газа в коллекторе. Данная информация возвращается в SCADA-систему для отображения на мнемосхемах АРМ диспетчера. Другой пример - тренажерные комплексы подготовки диспетчеров, представляющие собой связку системы реального времени СПУРТ и системы моделирования «Веста». Обычно передача данных реализована через обменные файлы, что требует дополнительной настройки экспорта/импорта. Повысить быстродействие взаимодействия (что необходимо, если на систему моделирования также возложена функция обнаружения утечек) может применение стыка с использованием протоколов передачи данных, например OPC. Однако реальную интеграцию демонстрируют системы, разработанные одним производителем, в которых система моделирования является частью системы SCADA и использует ее базу данных для хранения измеренных и рассчитанных значений, сведений о структуре трубопроводной сети, условно-постоянных параметрах. Примером такого симбиоза могут служить продукты PSIControl и PSIGanesi - разработки компании PSI AG.

Система моделирования → Долгосрочный архив

Проблемой большинства SCADA-систем является отсутствие логической взаимосвязи между отдельными сигналами, которая вводится, например, в реляционных СУБД. Даже если база данных SCADA-системы реализована в виде дерева объектов, или отношения вложенности задаются правилами именования тегов, но такая система, во-первых, не описывает все возможные варианты отношений между объектами, и во-вторых, требует ручной настройки в каждом конкретном случае, а следовательно, не надежна. Поэтому, при наличии технической возможности, прогнозное значение желательно сохранять не в отдельном объекте БД SCADA-системы, а в том объекте, для которого сделан прогноз. Одним из технических решений может быть сохранение прогнозного значения в архиве «в будущем» от текущего момента времени. Это позволит оперировать данным значением теми же методами, что и с «настоящими» архивами, сохраненными за прошедшее от текущего момента время - в частности, строить график без дополнительных ухищрений по комбинации архива одной величины и мгновенного значения другой. По мере хода времени прогнозное значение в архиве будет заменено на реально прошедшее, но, когда нас не интересует архив прогнозов.

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

По сигналу таймера система моделирования ГТС запрашивает из SCADA-системы текущие значения используемых моделью параметров и рассчитывает, какими они будут через 2 часа. Эти значения записываются в долгосрочный архив. Для визуального контроля на графике в SCADA-системе, прогнозное значение интерполируется и формируется массив значений, заполняющих краткосрочный архив.

Комплекс диспетчерских задач ↔ Долгосрочный архив

Вне реального времени для контроля и управления технологическим процессом на газотранспортных предприятиях России используются документы:

- журнал диспетчера - документ с постоянной структурой, отдельные части которого заполняются диспетчерами на ЛПУ и затем объединяются в сводный отчет в ЦДП. В журнале диспетчера есть 2-х часовой и суточный разделы, информация в которых фиксирует параметры технологического процесса и обновляется каждые два часа или раз в сутки при наступлении «контрактного часа». Кроме числовых значений, в журнал диспетчера заносятся сведения о ремонтах оборудования;

- диспетчерское задание - указание вышестоящего уровня управления по требуемым целевым значениям отдельных параметров технологического процесса. Центральные диспетчерские ОАО «Газпром», ООО «Межрегионгаз» рассылают диспетчерские задания факсом или телеграммой; между уровнями ЦДП и ЛПУ в подавляющем большинстве случаев используется устная передача по телефону.

При наличии технической возможности целесообразно отказаться от существующего отдельного хранения архива сформированных журналов диспетчера и архивных данных SCADA-системы. При наличии для каждого из параметров, фигурирующих в журнале, долговременного архива часовой (2-х часовой, суточной) периодичности, можно представить журнал как массив ссылок на архивные значения, с использованием кодировки НСИ (имен объектов), принятой в SCADA-системе. Диспетчер, заполняющий журнал, должен иметь возможность как принять автоматически сформированное архивное значение, так и вручную его откорректировать - тогда именно оно сохранится в архиве на данный час. Приводится схема подобного объединения архивных данных. Данный подход можно рассматривать как промежуточный шаг увеличению роли измеренных данных реального времени при формировании отчетности. На предприятиях транспорта и распределения газа в Западной Европе ведут архивы исполнения контрактных обязательств, а не сформированных к определенному часу с применением ручного труда «снимков состояния ГТС», чем являются российские журналы диспетчера. В базу данных SCADA-системы и долгосрочного архива целесообразно добавить параметры, которые фигурируют в журнале диспетчера, но по которым отсутствует поступление измеряемых значений. Передача информации между базами данных долгосрочного архива и диспетчерских задач реализуется, в отличие от остальных рассматриваемых информационных стыков, не в автоматическом режиме по регламенту, а через прикладную программу с графическим интерфейсом, с которой работает специалист диспетчерской службы.

Комплекс диспетчерских задач → SCADA-система

Однонаправленная связь. Поскольку диспетчерское задание носит ситуативный характер, т.е. определяет целевые значения отдельных параметров ТП, перечень которых может меняться, наиболее эргономичным представляется отображение диспетчерского задания на АРМ SCADA-системы, используемых диспетчером в работе. Для логического объединения контролируемого параметра и его целевого значения нужно не вводить в SCADA-систему отдельный объект, а использовать атрибуты существующего. Таким атрибутом, реализуемым практически любой системой, являются уставки, в большинстве SCADA-систем есть возможность задать, как правило, не менее четырех уставок для одного аналогового сигнала: верхние и нижние предупредительные и аварийные. Для наиболее распространенного случая, целесообразно зарезервировать использование предупредительных уставок для хранения диспетчерского задания, а аварийные настраивать в соответствии с физическими ограничениями на параметры технологического процесса.

Технически изменение уставок или запись значений сигналов реализуется при доступе через интерфейс прикладного программирования (API) или OPC-сервер, возможно - через изменение промежуточного, специально введенного сигнала, если прямой доступ к уставкам не предусмотрен, но есть возможность задать один сигнал в качестве уставки для другого. Диспетчерское приложение взаимодействует с локальной по отношению к нему SCADA-системой в ЦДП; распространение уставок на ЛПУ - функция, которая должна обеспечиваться механизмом взаимодействия SCADA-систем уровней ЛПУ и ГТП.

Передача данных между SCADA-системами уровней ЛПУ и ГТП

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

Для высокочастотного уведомления верхнего уровня об изменениях на нижнем уровне, характеризующемся изменением отдельных значений, протоколы взаимодействия, ориентированные на передачу отдельных сигналов, предпочтительнее. Наиболее универсальный из них, реализованный в большинстве SCADA-пакетов - это OPC. Известные ограничения этого протокола по работе в распределенных сетях передачи данных масштаба региона снимаются применением ПО промежуточного слоя - средствами «тунеллирования» OPC-запросов. Однако и OPC, и большинство других протоколов передачи данных, первоначально разработанных для взаимодействия SCADA-систем с контроллерами, а не друг с другом, имеют ряд принципиальных ограничений, связанных с непредоставлением никакой нормативно-справочной информации о контролируемом объекте. Связать каждый из присутствующих в адресном пространстве сигналов с характеристикой оборудования или параметром ТП, который он описывает, можно только по результатам «ручного» анализа его символьного имени, и то в случае, если разработчик придерживался определенной системы наименования и документировал ее.

В отличие от применения стандартизированных протоколов передачи данных, обмен информацией с помощью файлов - всегда частное решение, применяемое в случаях, когда требование скорости доставки информации уступает необходимости передавать данные единым набором, содержащим массив значений и связанный массив НСИ. Формат файла определяет система-клиент, располагаемая на вышестоящем уровне управления; примером может служить программный комплекс АССПООТИ, пользователь которого - ЦПДД ОАО «Газпром» - имеет возможность обязать региональные ГТП формировать обменные файлы требуемого формата. Передача файлов, выполняемая с помощью специализированного транспортного ПО, обладает преимуществом более четкого контроля доставки информации до адресата.

Техническим решением, объединяющим достоинства обоих методов, является использование протокола ICCP (Inter-Control Center Communication Protocol, также известен как IEC 60870-6/TASE.2), специально разработанного для взаимодействия диспетчерских пунктов между собой. Он предусматривает возможность передачи блоков технологической информации различных типов, содержащих требуемый объем НСИ. В литературе описана сеть обмена технологической информацией предприятий электроэнергетики США, построенная регулятором - NERC (Североамериканский совет по надежности электроэнергетики); в качестве протокола передачи данных применяется ICCP/TASE.2. Аналогичная построена структура, обеспечивающая информационные обмены между газотранспортными предприятиями в Западной Европе.

Обмен оперативными сообщениями

Оперативные сообщения - это своеобразная система  документооборота производственно-диспетчерской службы, фиксирующая  связанные с технологическим управлением события. В систему оперативных сообщений включают как факсы и управляющие документы от руководства, так и записи о проводящихся ремонтах или огневых работах, поломках оборудования,  вызовах дежурной машины, выездах работников на трассу. В качестве подобного журнала могут использоваться внедренные на предприятии системы документооборота или в упрощенном варианте система электронной почты, но, как правило, оперативные сообщения интересны не только сами по себе, а в привязке к конкретному  технологическому объекту, диспетчера интересуют не только последние поступившие распоряжения и события по всей газотранспортной сети, но и, в случае работ на конкретном объекте и оборудовании, что происходило и какие распоряжения выдавались относительно интересующего объекта. Подобные журналы сообщений тем ценнее и технически более сложны, чем выше уровень управления и чем больше отделов с разными интересами и правами доступа задействованы в работе. Введенные в такую систему документы, как и в обычной системе документооборота, нуждаются в согласовании и утверждении, установке уровня важности, разграничения прав доступа и срока действия. Для уровней ЛПУ и ГТП особенно ценна привязка сообщений к технологической модели SCADA, поэтому может быть целесообразнее встраивать систему обмена сообщениями в SCADA-пакет, а не использовать универсальную систему электронного документооборота.

Обмен данными между долгосрочными архивами

Как правило, долгосрочный архив ведется на основании существующих «локальных» оперативных данных. Передача массивов архивной информации, характеризующих состояние технологического процесса за прошедший промежуток времени, между системами долгосрочного архивирования разных уровней управления обычно не осуществляется. Но если долгосрочный архив используется для хранения отчетной информации (в прошлом), представляемой нижним уровнем управления вышестоящему, и для хранения прогнозной информации (в будущем), сообщаемой «сверху вниз», то необходима реализация двунаправленного обмена информацией.

Большинство СУБД содержит встроенные механизмы репликации данных, но использовать такие механизмы нецелесообразно, так как правила репликации различны в зависимости от типа информации. В большинстве случаев, исправленное вручную значение не может быть заменено автоматически измеренным, или, введенная вручную корректировка на верхнем уровне не может быть заменена данными снизу. Таких правил бывает слишком много и для успешной репликации средствами СУБД обычно реализуют собственные механизмы на базе экспорта/импорта данных в файлы или удаленного вызова SQL-запросов. Перспективным решением будет использование тиражируемого интеграционного ПО.

Передача данных диспетчерской отчетности системам автоматизации производства

Интерпретация поступающих данных реального времени и результатов моделирования, принятие решений и формирование отчетности является основной, круглосуточной работой оперативного диспетчерского персонала ГТП. Анализ производственных и финансовых показателей работы предприятия, и тем более принятие руководящих решений по его результатам, не подчинено жестким регламентам, и в системах производственно-финансовой автоматизации использование диалогового, интерактивного режима должно быть сведено к минимуму: выделенного персонала для выполнения рутинных операций нет; рутинных задач отслеживания и расчета различных показателей деятельности предприятия - множество. Поэтому, когда не требуется передача данных в реальном времени, т.е. выполняется обмен не технологической, а производственной и отчетной информацией, необходимо рассмотреть целесообразность применения ПО класса ETL (Extract-Transform-Load) или ESB (Enterprise Service Bus). Общее у этих групп ПО - применение «ядра», в котором заложены сценарии информационных обменов и функционирующего на выделенном сервере, и набора «адаптеров» - программ-агентов, настраиваемых для подключения к каждому конкретному источнику или получателю данных. Сценарии описывают условия выборки данных, их преобразования, включая перекодировку НСИ при необходимости, и сохранения в базе данных системы-получателя. Каждая из обменивающихся данными информационных систем может выступать как «сервис», обслуживающий запросы на выборку/загрузку данных. С этой точки зрения, взаимодействия с различными ИС, ничем не отличаются. В отдельных случаях, источником/приемником данных может являться не база данных, а файл - для обмена производственной информацией между газовыми компаниями в Европе все большее распространение получает файловый формат Edig@s. Производят интеграционное ПО крупные фирмы-разработчики; выбор можно делать между Microsoft BizTalk Server, SAP xMII и SAP XI, ICONICS BizViz, Oracle Data Integrator, IBM WebSphere.

Вариант реализации

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

Таким примером работающей в газовой промышленности АСУТП со сложной структурой взаимосвязей между компонентами является система оперативного диспетчерского управления DAISY компании E.ON Ruhrgas. Схема взаимодействующих функциональных блоков аналогична приведенной модели; с некоторыми уточнениями:

  • большой объем данных поступает в SCADA-систему центральной диспетчерской непосредственно от систем автоматики и телемеханики, а не от промежуточных SCADA-систем уровня филиала;
  • комплекс диспетчерских задач ориентирован на оперативный мониторинг и управление ГТС для обеспечения исполнения контрактных обязательств. При этом ГТП имеет большое количество договоров на поставку относительно небольших объемов газа;
  • если в РФ реализуется обмен данными между выше- и нижестоящими уровнями управления, но практически нет информационных стыков между «равноправными» диспетчерскими, то в Европейском Союзе газовые компании взаимодействуют между собой на паритетных началах;
  • с некоторыми из партнеров осуществляется обмен технологической информацией; с некоторыми - производственной информацией.

Внедрение и развитие любой сложной информационной системы, и АСУТП транспорта газа в том числе, будет тем более эффективным и надежным, чем прозрачнее будут информационные связи между отдельными компонентами. Использование стандартных протоколов передачи данных и методов доступа; передача не только значений, но и справочной информации; обеспечение целостности данных за счет передачи не отдельных значений параметров, а цельных массивов данных; использование единой кодировки НСИ - залог успешности каждого из этапов жизненного цикла системы автоматизации.

Богданов Николай Константинович, к.т.н., зав. сектором реализации комплексных проектов ЗАО «АтлантикТрансгазСистема», Этот e-mail защищен от спам-ботов. Для его просмотра в вашем браузере должна быть включена поддержка Java-script , (495) 660-08-02

Сушкова Наталия Ивановна, зав. сектором систем диспетчерского управления

 

Новости

Подпишитесь прямо сейчас:
Ваш e-mail: *
Ваше имя: *




22-24 november 16
Журнал - Автоматизация и IT в НГК. Звоните по телефону (495) 221-09-38, info@avite.ru