"Платформа АТОЛЛ": точная информация в нужное время

1 марта 2008 Connect
Connect
# 3, 2008 г.
Иван Мугалев,
директор центра решений ТЭК компании Открытые Технологии

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

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

В предлагаемой статье мы рассмотрим подход к обеспечению непротиворечивости данных и их хранению в компаниях нефтегазового сектора, предлагаемый компанией Открытые Технологии.

В результате анализа спектра задач, решаемых на нефтегазовых предприятиях, компанией «Открытые Технологии» была разработана собственная структура хранения данных - "Платформа АТОЛЛ".

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

Все функции, которые должна была обеспечить "Платформа АТОЛЛ", были сгруппированы в соответствии с основными направлениями деятельности нефтегазодобывающего предприятия:

  • поиск и разведка месторождений;
  • разработка месторождений;
  • эксплуатация месторождений;
  • проектирование и моделирование;
  • контроль сервисов и ресурсов;
  • управление сервисами;
  • управление ресурсами;
  • управление производственной деятельностью.

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

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

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

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

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

Платформа использовалась также и для решения задач корпоративного уровня. Как пример можно выделить организацию доступа к геолого-геофизическим и гидродинамическим моделям (ГГМ, ГДМ) из любой точки вертикально интегрированного холдинга. Платформа была развернута в корпоративном центре в Москве и в шести регионах России. Описание и сами ГГМ и ГДМ, а также паспорта на разработку месторождений вводились сотрудниками НИПИ или добывающих структур в регионах, при этом осуществлялась привязка моделей к организационным единицам, скважинам, месторождениям, пластам и т. д. из единого корпоративного справочника. Описание моделей моментально становилось доступным во всех семи узлах корпоративной сети. Это обеспечивалось специальными механизмами репликации информации, базирующимися на технологиях Oracle. Пользователь мог просмотреть любую модель, передача которой по сети с одного узла в другой выполнялась с помощью пакетной доставки с использованием возможностей той же СУБД Oracle. Результатом данного проекта стало единое хранилище всего фонда моделей и проектов для вертикально интегрированной компании с разделенным уровнем доступа и механизмами контекстного поиска.

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

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

В качестве наиболее интересных преимуществ использования платформы как схемы хранения информации для внедряемых функциональных решений можно выделить следующие:

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

Именно эти возможности позволят в итоге получить руководителю целостную картину прежде всего о той информации, которой он оперирует.




Предыдущая новость:
Защита информации от утечки из информационных систем
Следующая новость:
Контроль пользовательского доступа