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

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

Традиционное решение

Традиционно иерархическая структура переносится и на техническую реализацию. Каждая АСУ уровня ЛПУ имеет свою базу данных c информацией, доступной диспетчерам и технологам ЛПУ. В центральном пункте устанавливается АСУ уровня ГТП, содержащая базу данных всего предприятия. Между "верхним" и "нижним" уровнями осуществляется информационный обмен.

Иерархическая РАСУ ТП ГТП

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

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

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

Архитектура гео-кластера

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

Гео-кластер РАСУ ТП ГТП

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

Систему можно рассматривать как один виртуальный SCADA-сервер с одной базой данных и средствами визуализации, который обеспечивает работу всех диспетчерских пунктов ЛПУ и ГТП расположенных на значительном расстоянии друг от друга. На самом деле серверная часть системы достаточно сложна, но эта сложность полностью скрыта от пользователя. Процессы, выполняющиеся в такой среде можно разделить на две группы. Группу интерфейсных процессов "переднего края" - Front-end, отвечающих за общение системы с клиентами. И группу "рабочих" процессов управления - Back-end, выполняющих основные ресурсоемкие задачи.

Рассмотрим схему процессов гео-кластера на примере газотранспортного предприятия, состоящего из четырех ЛПУ и центрального пункта. Серверы SCADA в ГТП и двух ЛПУ образуют кластер. Они функционально идентичны и содержат единую базу данных. На схеме показано, что в ЛПУ 3 и 4 нет собственных SCADA-серверов, и их клиенты используют интерфейсы узлов ЛПУ 1 и ГТП.

Можно выделить три группы клиентов: пользователи (диспетчеры, технологи и специалисты, выполняющие мониторинг и управление); бездисковые терминалы, обеспечивающие работу пользователей; системы сбора данных, передающие в нашу среду информацию со стороны АСУ "нижнего" уровня, и внешние информационные системы, с которыми возможна интеграция. Каждой группе клиентов соответствуют Front-end-процессы. Это интерфейсы пользователей, серверы терминалов и службы обмена с внешними системами.

Взаимодействие клиентов с группой Front-end построено таким образом, что клиент всегда обслуживается процессом, работающим на "ближайшем" узле. Если по каким либо причинам ресурсы "ближайшего" узла не доступны, то на обслуживание клиента автоматически переключается следующий "ближайший" сервер. Front-end-процессы выполняются на каждом узле независимо и взаимодействуют с Back-end-процессами, работающими в пространстве кластера. Для осуществления задач кластера на всех узлах запущены службы синхронизации, репликации данных и балансировки нагрузки. В пространстве Back-end работают все функции чтения, записи, поиска и обработки информации баз данных.

Схема процессов гео-кластера

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

Новые свойства РАСУ ТП ГТП

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

Катастрофоустойчивость: За счет географической удаленности узлов (более 100 км), система устойчива к авариям и другим внешним воздействиям. Распределенность объектов более не усложняет задачу, а является дополнительным фактором повышения надежности.

Устойчивость к внутренним сбоям: Появление еще одного уровня надежности делает внутренние сбои отдельного узла менее критичными. Это позволяет в разумных пределах уменьшать требования надежности узлов и выбирать более экономичные серверные решения.

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

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

Оптимальное распределение ресурсов: Ситуация "недогруженности" SCADA-серверов малых ЛПУ и "перегруженности" крупных ЛПУ или ГТП исключена, т.к. теперь нагрузка распределяется на весь комплекс. Если весь комплекс в результате увеличения объемов передаваемых данных или подключения новых объектов не справляется с нагрузкой, то необходима установка дополнительных узлов кластера.

Оптимизация обменов между узлами: Так как данные всех ЛПУ и ГТП хранятся в единой базе, пропадает необходимость прямого обмена информацией между узлами. Обмены происходят косвенно через репликацию единой базы. Эти алгоритмы не требуют использования доступа к структуре базы, пересылают бинарную информацию в сжатом и зашифрованном виде, обеспечивая "зеркало" на системном уровне. Они реализованы производителем платформы, встроены в операционную систему, быстрее работают и лучше оптимизированы, чем алгоритмы синхронизации данных на уровне приложений. Тем самым решается одна из ключевых проблем системы с иерархической структурой – длительная синхронизация информации в удаленных базах данных в случае потери обменов между ГТП и ДП ЛПУ.

Дифференцированный доступ к данным: Разграничение зоны ответственности диспетчеров и степени детализации наблюдаемых ими объектов централизовано регулируется доступом пользователей. Эти настройки достаточно гибкие, и их можно выполнить как на этапе конфигурации системы, так и в процессе ее работы.

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

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

Стоимость владения: Решение с применением гео-кластера требует другого подхода к формированию спецификации оборудования. Сравнивая новую архитектуру с архитектурой проекта "ЯМАЛ2", в котором реализована иерархическая схема узлов, кластеры дублирования серверов SCADA и серверы архивирования в каждом пункте, мы можем сказать, что при реализации нового подхода есть тенденции уменьшения стоимости владения программно-аппаратной платформой за счет сокращения единиц оборудования, несмотря на то, что стоимость отдельных единиц техники может возрасти.

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

Количество SCADA узлов не обязательно должно совпадать с числом компрессорных станций, а может быть уменьшено. Это оптимизирует не только стоимость владения системой, но и накладные расходы на обслуживание. Что лучше? Выбрать высокопроизводительный сервер, обслуживающий два-три объекта или несколько менее мощных серверов для каждого ЛПУ? Это можно гибко варьировать в зависимости от конкретной ситуации.

Новый подход требует замену привычных дисковых массивов хранения устройствами, поддерживающими технологию SAN – Storage Area Network, которые несколько дороже обычных. Однако это перспективная технология, идущая на смену массивам с традиционным интерфейсом. Таким образом, мы предлагаем гибкий подход, позволяющий выбрать оптимальную стоимость программно-аппаратного комплекса проекта.

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

Гео-кластер многолик и неизбежен

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

С учетом опыта работы в проектах "ГОФО/ЯМАЛ" с традиционной иерархической структурой, предлагается комплексный подход к построению РАСУ ТП, использующий новые архитектурные решения. С одной стороны этот подход – самостоятельное решение, дающее новые свойства информационной системы, расширенную функциональность, развитие приложений и интерфейсов, современные методы внедрения и обслуживания. С другой стороны – это сохранение совместимости с ранее реализованными проектами, что дает преемственность концепций, наследование программно-аппаратной платформы и сохранение ранее сделанных инвестиций.

Павел Легеня

Литература

1. Николис Дж. Динамика иерархических систем. Эволюционное представление. М.: Мир, 1989.
2. Шильяк Д. Децентрализованное управление сложными системами. М.: Мир, 1994.
3. Касти Дж. Большие системы, связность, сложность и катастрофы. М.: Мир, 1982.
4. Рябинин И.А. Надежность и безопасность структурно-сложных систем. СПб.: Политехника, 2000.
5. Sun Microsystems, Inc. Sun Cluster Geographic Edition Overview. Part No: 817–7499–10 August 2005, Revision A.
6. Sun Microsystems, Inc. Sun Cluster Geographic Edition System Administration Guide. Part No: 817–7501–10 August 2005, Revision A.

Источник: http://corp.cnews.ru/reviews/articles/index.shtml?2007/05/30/252550