АСУ ТП для нефтедобывающего предприятия

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

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

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

Системообразующие элементы АСУ ТП:

• датчики и интеллектуальные преобразователи,
• средства телеметрии,
• вторичные преобразующие и показывающие приборы,
• программируемые логические контроллеры и их программное обеспечение (ПО),
• персональные компьютеры и их ПО (АРМ’ специалистов),
• серверы для ведения баз данных реального времени и для выполнения серверных компонент ПО АСУ ТП.

Диапазон средств реализации задач АСУ ТП нефтедобычи, обычно используемых в проектах с участием специалистов ИБС, довольно широк:

• от интеллектуальных приборов Fisher Rosemount, радарных уровнемеров Saab, Seltec, до отечественных разработок «Гамма 7», «Гамма 8»;
• от известных зарубежных контроллеров «Modicon» или «Scada Pack» до «ТК1616», «СТМ-Z», «Сакмар-Скат», производимых на отечественных предприятиях;
• от зарубежных SCADA-систем InTouch, iFix, Factory Link, GENESIS32 до их отечественных аналогов «Телескоп+», «Trace Mode» или «КРУГ 2000».

Применяемые технические средства, разумеется, зависят от конкретной ситуации в каждом проекте АСУ ТП.

Критерии эффективности и решаемые задачи

Вот некоторые параметры, по значению которых можно судить об успешности функционирования АСУ ТП:

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

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

• Сбор информации от кустов и ДНС, УПСВ, БКНС, электрических распределительных станций.
• Промежуточное хранение данных. Данные из подсистем АСУ ТП поступают, как правило, не одновременно, требуют взаимной проверки и увязки. С этой целью организуется промежуточное кратковременное хранение данных перед их согласованием и агрегированием.
• Унификация данных. Все данные приводятся к единой системе классификаторов, кодов, структур и справочников. Унификация происходит на уровне корпоративных, международных стандартов и т. п.  Кроме того, данные преобразуются к принятым единицам измерения.
• Интеллектуальное агрегирование данных (с очисткой, выбраковкой случайных, флуктуационных данных). Некорректные и противоречивые данные уточняются и согласуются.
• Эргономичная многоэкранная визуализация (с возможностью детализации по желанию оператора). и предоставление данных потребителям. В соответствие с запросами пользователей и лиц, ответственных за принятие управленческих решений, осуществляется выбор необходимых данных.
• Сведение агрегированных данных на супервизорный уровень (диспетчерский пункт промысла) или в «ситуационную комнату уровня» (обычно это ЦДУ).
• Хранение данных (трендов параметров). Целью хранения данных служит накопление исторических данных, которые необходимы для проведения ретроспективного анализа, выявления тенденций и прогноза.
• Подготовка данных для проведения специфических расчетов вне АСУ ТП или проведение таких расчетов (для тех случае, когда необходимые вычислительные алгоритмы реализованы в «теле» АСУ ТП (например, регулирование).
• Процедуры анализа трендов по апертурному принципу или с привлечением оператора-технолога.
• Процедуры поддержки принятия оперативных технологических решений с предварительной оценкой их экономических последствий (перезапуск некондиционной нефти на второй цикл подготовки или слив в дренаж – типичные ситуации, требующие такой оценки).
• Генерация заявок в систему верхнего уровня на проведение бизнес-процессов на основе собранной информации о состоянии и наработке технологического оборудования.
• Отчетность перед системой верхнего уровня в согласованных терминах.

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

Чтобы удовлетворять современным функциональным требованиям и тенденциям, наиболее передовые АСУ ТП сегодня реализуются на основе объектно-ориентированного подхода (ООП). Это предполагает использование библиотек предметных объектов, начиная от объекта «датчик» и завершая такими объектами как «ДНС» или «техпроцесс».

АСУ ТП – возврат к управлению процессами

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

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

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

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

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

Однако на это подобие либо не обращается внимания и оно теряется в должностных инструкциях и неформальных действиях персонала при их исполнении, либо скрывается в алгоритмах функционально - группового управления (ФГУ) за именами конкретных агрегатов.

Если использовать объектно-ориентированное представление, то вот некоторые методы, с помощью которых можно заставить процесс последовательно проходить его состояния:

• Формируется потребность выполнить совокупностью компонент (агрегатов) определенную функцию уровня процесса. То есть осознается необходимость выполнения метода «Процесс_Х. затребовать на выполнение»
• Формируется покомпонентная (поагрегатная) структура процесса. На каждую необходимую трансформацию (операцию) должен найтись хотя бы один свободный и исправный «претендент». Происходит «сборка» процесса  «Процесс_Х.собрать».
• Снимается набор показателей с компонент (агрегатов). Это означает запуск для объекта-агрегата метода «дать свои текущие параметры».
• Определяется готовность множества компонент (агрегатов) выполнить своим коллективным поведением некоторую функцию, ассоциируемую с процессом в целом.
• Определяется индивидуально для каждого компонента (агрегата) команда, необходимая ему, чтобы нужный процесс в целом смог стартовать. Выдаются для каждого компонента (агрегата) нужный для него прикладной метод.
• Происходит загрузка в память описания эталонного процесса, относительно которого в дальнейшем будут оцениваться отклонения.
• Подаются команды на старт процесса, характерные для него (извлекаются из описания процесса, хранящегося в памяти).
• Процесс начинает выполняться (именно здесь выполняется метод «Процесс_Х.оценить отклонение») и продолжает выполняться до возникновения необходимости в другом процессе или до своего нормального завершения. Отслеживается актуальность данного процесса, после исчезновения которой происходит гашение процесса по специальному алгоритму и управление передается другому процессу.
• После окончания выполнения данного процесса для всех участвующих в нем компонент (агрегатов) происходит выполнение своего учетного метода - выполняется для каждого свой (!) учетный метод типа «отослать зарегистрированные данные о выполнении прикладного метода куда-то». Здесь надо учесть все, что надо учесть для данного агрегата (например, понесенные энергозатраты на выполнение операции или количество моточасов, израсходованных на выполнение операции).
• Запуск следующего цикла.

Таким образом, будучи реализованной в новой АСУ ТП, рассмотренная процессная парадигма (разработанная и реализованная совместными усилиями компании ИБС и ИПУ РАН) открывает следующие возможности:

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