CC BY
152
УДК 519.816
ПОДХОД К РАЗРАБОТКЕ СИСТЕМЫ ПОДДЕРЖКИ ПРИНЯТИЯ РЕШЕНИЙ НА ПРИМЕРЕ НЕФТЕГАЗОДОБЫВАЮЩЕГО ПРЕДПРИЯТИЯ
Ю.А. Загорулько, И.А. Ануреев, Г.Б. Загорулько
Институт систем информатики им. А.П. Ершова СО РАН, г. Новосибирск Новосибирский государственный университет E-mail: [email protected]
Рассматривается подход к разработке системы, обеспечивающей поддержку принятия решений задач повседневной управленческой деятельности для лиц, принимающих решения, с целью снижения энергозатрат процесса добычи углеводородов на нефтегазодобывающем предприятии и повышения экологической безопасности этого процесса. Обсуждается архитектура и принципы построения такой системы.
Ключевые слова:
Система поддержки принятия решений, онтология задач, онтология предметной области, продукционные правила, семантические сети, целочисленное программирование. Key words:
Decision support system, task ontology, subject domain ontology, production rules, semantic networks, integer programming.
Введение
Для повышения энергоэффективности и экологической безопасности добывающих предприятий нефтегазового комплекса широко используются информационные технологии [1]. В настоящее время на таких предприятиях используется достаточно большое количество АСУ ТП. Но, как правило, эти АСУ ТП установлены на локальных объектах и обслуживают только основной производственный процесс, а именно - добычу углеводородного сырья, не затрагивая при этом транспортное обслуживание и проведение плановых и экстренных ремонтов. В связи с этим такие системы не могут обеспечить ЛПР (лицо, принимающее решение) необходимой информацией обо всех процессах, влияющих на эффективность и экологическую безопасность работы предприятия. К тому же эти системы, действуя локально, обеспечивают управление и мониторинг только отдельно взятого объекта или процесса, в то время как для принятия эффективных решений требуется иметь интегральную информацию обо всех объектах и процессах технологической инфраструктуры добывающего предприятия.
Для снижения энергетических затрат добывающих предприятий нефтегазового комплекса и повышения экологической безопасности их работы создается система оперативного мониторинга их технологической инфраструктуры (СОМТИ). Важным компонентом этой системы является аналитическая подсистема обработки информации (АП СОМТИ), которая должна обеспечивать поддержку принятия решений задач повседневной управленческой деятельности для ЛПР с целью снижения энергозатрат процесса добычи углеводородов на предприятии и повышения экологической безопасности этого процесса.
Рассмотрению архитектуры и принципов построения этой подсистемы и посвящена данная статья.
Назначение АП СОМТИ
Аналитическая подсистема СОМТИ должна решать следующие задачи:
• Анализ состояния объектов технологической инфраструктуры добывающего предприятия нефтегазового комплекса (далее - просто объектов) с целью предотвращения аварийных ситуаций.
• Анализ состояния объектов с целью улучшения показателей их работы.
• Анализ статической и динамической информации об объектах с целью принятия решений о плановом техническом обслуживании и ремонте объектов, а также списании объектов и замене их новыми.
• Выработку рекомендаций для ЛПР об оптимизации потоков технологического транспорта и процессов технического обслуживания и ремонтов объектов.
Эти задачи можно сгруппировать следующим образом:
1. Информационная поддержка ЛПР, включая оценку текущей ситуации (мониторинг), интерпретацию данных мониторинга и диагностику предаварийных ситуаций.
2. Прогнозирование (с оценкой рисков).
3. Выработка рекомендаций для ЛПР (включая архивирование выданных ЛПР рекомендаций с их упорядочиванием по датам и событиям).
Архитектура и представление знаний в АП СОМТИ
Так как технологическая инфраструктура предприятия может быть подвержена как структурным, так и качественным изменениям, вся система в целом и АП СОМТИ, в частности, должна быть настраиваема на предметную область (ПО) и типы задач. В связи с этим в состав АП СОМТИ в явном
виде входит модель ПО, представленная онтологией, а ее архитектура допускает подключение дополнительных модулей, обеспечивающих поддержку принятия решений новых задач.
АП СОМТИ (рисунок) включает следующие компоненты: обработчик заданий, планировщик, интерпретатор конфигураций (супервизор), управляемый онтологией адаптер, конфигуратор системы, онтологию, репозитарий модулей принятия решений. Кроме того, в АП СОМТИ используются следующие внешние модули: интерпретатор продукционных правил, решатель задач целочисленного линейного программирования (ЦЛП), редактор онтологий, а также редактор правил и моделей.
В своей работе АП СОМТИ использует базу данных подсистемы хранения информации СОМ-ТИ (БД ПХИ), в которой представлены данные о структуре и состоянии технологической инфраструктуры предприятия.
Онтология системы [2] состоит из двух взаимосвязанных онтологий - онтологии ПО и онтологии задач [3], для описания которых используется язык представления знаний интегрированной системы 8ешр-ТЛО [4, 5].
Онтология ПО описывает модель предметной области в виде понятий и отношений между ними. Базовыми понятиями (классами) онтологии ПО являются: Объект анализа, Нормативно справочный объект, Состояние, График ремонтов, Маршрут, Результат.
В классе Объект анализа выделяются подклассы Оборудование (насосные установки, трансформаторы, трубопроводы, линии электропередач и т. п.) и Подвижные объекты (автоцистерны, грузовики, автобусы и другие виды автотранспорта). Эти объекты могут находиться в том или ином состоянии, для описания которого вводится класс Состояние. В свою очередь класс Состояние имеет следующие подклассы: Неисправность, Поломка, Штатное состояние, Предаварийное состояние.
Для контроля соответствия параметров объектов анализа нормативным значениям вводится понятие Нормативно справочный объект. Экземпляры этого понятия создаются для каждого типа объектов (например, для насосов одной марки) и связываются с соответствующими объектами отношением «Описывается».
Каждый объект ПО имеет свой график ремонтов, в котором собрана информация о плановых, текущих и срочных ремонтах данного объекта.
Результатами работы АП СОМТИ являются сообщения о состоянии оборудования и подвижных объектов, рекомендации для ЛПР, решения транспортных задач, скорректированные графики ремонтов и т. п.
Заметим, что онтология ПО не только служит для описания модели ПО, но и определяет формат представления информации, извлекаемой из БД
ПХИ, в виде объектов (экземпляров понятий) предметной области. Именно с таким представлением будут работать все модули поддержки принятия решений, включенные в АП СОМТИ.
Онтология задач включает описания решаемых системой задач и модулей принятия решений, реализующих решения этих задач, а также понятия, определяющие настройки и стратегии решения задачи. В онтологии вводятся отношения между задачами и связи задач с модулями принятия решений.
Для описания задачи вводится понятие (класс) Задача, имеющий атрибуты «Имя задачи» и «Параметры задачи».
Первый атрибут задает имя задачи. Атрибут «Параметры задачи» представляет собой множество пар вида <СТ, Ьт>, где Ст - класс онтологии ПО или онтологии задач, Ьт - список имен объектов класса СТ, для которых должна быть решена данная задача (предполагается, что имя объекта является ключевым атрибутом объекта). Если Ьт - не задано (пусто), то считается, что задача решается для всех объектов класса Ст.
Для представления модуля принятия решений в онтологии задач вводится класс Модуль, имеющий атрибут «Имя модуля».
На задачах определены отношения «Подзадача» и «Порождает». Первое отношение связывает некоторую задачу с другими задачами (ее подзадачами), решение которых требуется для решения данной задачи. Отношение «Порождает» определяет потенциальную возможность порождения одной задачи другой. Вводится также отношение «Реализует», связывающее модуль принятий решений с задачей, решение которой он обеспечивает. Модуль может связываться только с терминальной задачей.
Все модули принятия решений хранятся в репо-зитарии и снабжены следующими атрибутами: «Имя модуля», «Входные данные», «Выходные данные», «Решатель».
Атрибут «Имя модуля» задает имя модуля принятия решений.
Атрибут «Входные данные» определяет множество типов (классов) объектов, необходимых для функционирования модуля. Значение атрибута имеет вид <Сп, В.ы, Д„>, где Сы - множество классов онтологии ПО и онтологии задач, В.ы - множество отношений онтологии ПО, заданных на классах С Ап - множество ограничений на значения атрибутов объектов классов из С Ограничение Ап служит для фильтрации объектов, необходимых для решения задачи (принятия решений). Если для какого-то класса не задано ограничение, то будут выбираться все объекты данного класса. Если модуль реализует задачу, у которой есть параметры, то параметры задачи добавляются к множеству ограничений А п.
Рисунок. Архитектура АП СОМТИ
Атрибут «Выходные данные» определяет множество классов, объекты которых могут быть порождены в ходе работы модуля. Его содержимое имеет вид <СШ, ЯоШ>, где Сш1 - множество классов онтологии ПО, Яш - множество отношений онтологии, заданных на классах Сш.
Атрибут «Решатель» задает имя программной системы, которая будет исполнять (интерпретировать) данный модуль принятия решений. На данный момент в АП используется два решателя: интерпретатор продукционных правил технологической среды 8ешр-ТЛО и решатель задач целочисленного линейного программирования (ЦЛП) [6]. Для каждого решателя разработан адаптер для обмена данными между ним и локальным хранилищем данных АП СОМТИ (ЛХД).
Набор модулей может быть расширен с помощью конфигуратора системы, который позволяет регистрировать новые модули и включать их в ре-позитарий модулей и онтологию задач.
Принципы работы АП СОМТИ
Основной цикл работы АП СОМТИ состоит в последовательном выполнении заданий, поступающих от подсистемы управления СОМТИ.
Задание содержит некоторую последовательность известных АП СОМТИ задач, записанную в определенном формате. Задача считается известной АП СОМТИ, если ее описание представлено в онтологии задач.
Обработчик заданий анализирует задание, извлекает из него очередную задачу, представляет ее в формате, заданном онтологией задач, и передает планировщику.
Планировщик для каждой поступившей на его вход задачи порождает исполняемую конфигурацию модулей, реализующих ее. При этом он использует онтологию задач и репозитарий модулей. Если задача в задании была снабжена параметрами, то они учитываются при сопоставлении данной
задачи с задачами, представленными в онтологии задач, и при успешном сопоставлении передаются в модуль, реализующий решение этой задачи.
Цикл работы интерпретатора конфигураций состоит в выборе из конфигурации модулей описания очередного модуля принятий решений, загрузке необходимых для его работы данных из БД ПХИ (через управляемый онтологией адаптер) в ЛХД, вызове соответствующего решателя и исполнении им выбранного модуля, загрузке результатов работы модуля в ЛХД.
После отработки очередного модуля принятия решений супервизор осуществляет мониторинг ЛХД и при обнаружении в нем объектов типа «Задача» формирует задание из этих задач и вызывает планировщик. После окончания работы планировщика, который может дополнить конфигурацию новыми описаниями модулей, супервизор продолжает работу уже над модифицированной конфигурацией модулей.
Поддержка принятия решений в АП СОМТИ
Как было сказано выше на данный момент АП СОМТИ включает два типа модулей поддержки принятия решений:
1. Продукционные модули, для исполнения которых в состав АП включен интерпретатор продукционных правил интегрированной технологической среды 8ешр-ТЛО.
2. Вычислительные модули, для исполнения которых служит решатель задач ЦЛП.
Для решения задач диагностики, мониторинга, выработки управляющих воздействий и рекомендаций используются модули поддержки принятия решений, реализованные в парадигме продукционной модели. Они включают структурированное множество продукционных правил, описанных в терминах онтологии системы. Для описания продукционных правил используется язык системы 8ешр-ТЛО.
Рассмотрим более подробно работу продукционных модулей, осуществляющих мониторинг некоторого куста скважин и диагностику содержащегося в нем оборудования: автоматизированной групповой замерной установки, трансформаторной подстанции, кустовой насосной станции, насосных установок и транспортных труб. Описания данных объектов представляются в семантической сети. С помощью продукционных правил, работающих над сетью, проводится анализ таких параметров, как дебит скважины, давление на участках трубопровода, энергопотребление и др.
Результатом работы модуля, осуществляющего мониторинг куста, может быть сообщение о наличии утечки на определенном участке трубопровода, либо заключение о предполагаемой неисправности того или иного оборудования. Детальную диагностику оборудования, выделенного первым модулем, и определение его неисправности осуществля-
ет продукционный модуль, предназначенный для диагностики данного типа оборудования.
Рассмотрим понятие Неисправность, играющее важную роль в диагностике оборудования. Для каждого вида оборудования (например, Насосная установка), вводится класс (Неисправность насосной установки) с теми же атрибутами (параметрами), что и у данного вида оборудования. Значением атрибута «Название» экземпляра этого понятия будет название неисправности (например, «Разрушение рабочего колеса»). Значениями же атрибутов, определяющих технические характеристики конкретного вида оборудования, будут симптомы рассматриваемой неисправности.
В данном контексте, симптомы - это либо предельные значения параметров оборудования, либо лингвистические переменные, описывающие поведение параметров (падение, возрастание, стабильность и т. д.). Для связи оборудования с неисправностями служит понятие Гипотеза. Для каждой конкретной пары оборудования и его неисправности в семантической сети порождается объект класса Гипотеза, первым атрибутом которого является диагностируемый объект, вторым -возможная неисправность, третьим - вероятность того, что данный объект имеет данную неисправность. В процессе проверки гипотезы обнаружение у диагностируемого объекта симптомов неисправности увеличивает значение ее вероятности. Если окажется, что вероятность гипотезы больше некоторого порогового значения, установленного экспертом, то результатом работы продукционного модуля будет сообщение о наличии у диагностируемого объекта данной неисправности.
Поддержка решения задач оптимизации ремонтов оборудования и транспортных потоков осуществляется вычислительными модулями. Используемый в АП решатель ЦЛП GLPK представляет модель решения задачи и входные данные для нее на специальном языке GMPL (GNU MathProg Language). Результат работы решателя также представляется на языке GMPL. Позволяя описывать задачу в естественной математической нотации, включающей параметрические уравнения и неравенства, индексированные выражения и т. п., этот язык упрощает составление вычислительных моделей экспертами, однако требует специального адаптера, который осуществляет обмен данными между вычислительной моделями и онтологической моделью ЛХД.
Рассмотрим в качестве примера задачу оптимизации маршрутов движения транспорта, осуществляющего перевозку нефти от отдаленных скважин к центральному пункту сбора. Модель предметной области на верхнем уровне включает классы Автопарк, Транспорт, Скважина, Дорожная сеть, Центральный пункт сбора нефти. Онтология задач включает класс Настройки решения транспортной задачи, который описывает параметры решения транспортной задачи.
Задание, поступающее от подсистемы управления СОМТИ, заключается в организации маршрутов движения транспорта, позволяющей минимизировать расход горючего при фиксированном уровне добыче нефти. Параметры соответствующей ему задачи включают имена автопарков, предоставляющих транспорт, имена скважин, с которых планируется забирать нефть, имя дорожной сети, имя центрального пункта сбора, а также имя настройки решения транспортной задачи.
Вычислительная модель решения этой задачи включает следующие параметры, разбитые в соответствии с онтологической классификацией для:
• автотранспорта - число ходок, грузоподъемность, средняя скорость, расход топлива; число единиц автотранспорта для каждого автопарка;
• скважин - дебит, соседние посещенные скважины для каждого автомобиля и каждой ходки; автомобили, которые посетили скважины для каждой ходки; объемы нефти, взятые каждым из автомобилей в каждой из ходок; число скважин, с которых собирается нефть и отвозится на пункт учета;
• дорожной сети - минимальные расстояния между любыми двумя объектами инфраструктуры (автопарками, скважинами, центральным пунктом сбора) и их обеспечивающие схемы проезда;
• настройки решения транспортной задачи -точность решения, время прогона, максимальное число ходок автомобилей, горизонт планирования (период времени, на которое составляется расписание движения транспорта), стратегия решения (задает применяемую стратегию решения задачи).
Адаптер ЦЛП загружает данные из онтологической модели, определяемой параметром задачи, в вычислительную модель и интерпретирует результаты решателя ЦЛП в терминах онтологии предметной области. Параметры вычислительной задачи, как правило, соответствуют атрибутам объектов классов онтологии ПО и онтологии задач, а ре-
СПИСОК ЛИТЕРАТУРЫ
1. Байков И.Р., Самородов Е.А., Ахмадуллин K.P. Методы анализа надежности и эффективности систем добычи и транспорта углеводородного сырья. - М.: ООО «Недра-Бизнесцентр», 2003. - 275 с.
2. Guarino N. Formal Ontology in Information Systems // Proc. of FOIS'98, Trento, Italy, 6-8 June 1998. - Amsterdam: IOS Press, 1998. - P. 3-15.
3. Добров Б.В., Иванов В.В., Лукашевич Н.В., Соловьев В.Д. Онтология и тезаурусы. - Казань: Казанский гос. ун-т, 2006. - 198 с.
4. Загорулько Ю.А., Попов И.Г., Щипунов В.В. Интегрированная технологическая среда для создания систем обработки знаний
зультаты работы решателя ЦЛП - объектам этих классов. Так результат решения указанной задачи является экземпляром класса Решение транспортной задачи с двумя атрибутами - «Маршруты движения транспорта» и «Суммарный объем собранной нефти».
Заключение
Предложен подход к разработке системы поддержки принятия решений задач повседневной управленческой деятельности для лиц, принимающих решения на нефтегазодобывающем предприятии. Ввиду того, что технологическая инфраструктура предприятия может быть подвержена как структурным, так и качественным изменениям, данный подход обеспечивает настройку системы на предметную область и типы задач. Для этого в состав в системы в явном виде включена модель предметной области, представленная онтологией, а ее архитектура допускает подключение дополнительных модулей, обеспечивающих поддержку принятия решений при решении новых задач.
В настоящее время реализована пилотная версия системы АП СОМТИ, обеспечивающая поддержку принятия решений таких задач управленческой деятельности лиц, принимающих решения, как мониторинг состояния объектов технологической инфраструктуры предприятия с целью своевременного вывода неисправного оборудования из эксплуатации или постановке его на ремонт, оптимизация ремонтных работ и транспортных потоков.
Работа выполняется в рамках Государственного контракта № 02.514.11.4126 от 30.09.2009 г. с Федеральным агентством по науке и инновациям в рамках федеральной целевой программы «Исследования и разработки по приоритетным направлениям развития научно-технологического комплекса России на 2007-2012 годы» научно-исследовательские работы по теме: «Разработка интеллектуальной системы пространственно-технологического мониторинга на базе глобального спутникового позиционирования с целью повышения энергоэффективности и экологической безопасности существующих методов добычи углеводородов» (шифр заявки «2009-04-1.4-15-13-011»).
// Известия РАН. Теория и системы управления. - 1995. - № 5. - С. 210-213.
5. Загорулько Ю.А., Попов И.Г Представление знаний в интегрированной технологической среде Semp-TAO // Проблемы представления и обработки не полностью определенных знаний / под ред. И.Е. Швецова. - М.-Новосибирск, 1996. -С. 59-74.
6. GLPK (GNU Linear Programming Kit). Дата обновления: 2008.10.16. URL: http://www.gnu.org/software/glpk/glpk.html (дата обращения: 16.03.2010).
Поступила 16.03.2010 г.
