58250

Исследование процесса работы пользователей с информационной системы учета электропогружного оборудования скважин (ИС «ЭПОС»)

Дипломная

Информатика, кибернетика и программирование

В результате данной работы было спроектирована, разработана и внедрена подсистема оповещения в ИС «ЭПОС», устраняющая недостатки в работе ИС «ЭПОС». Разработаны и реализованы спецификации требований на внесение изменений в ИС «ЭПОС».

Русский

2014-05-30

3.02 MB

15 чел.

11

Реферат

стр. 82, рис. 28, табл. 9, прил. 2

Подсистема оповещения для информационной системы учета ЭЛЕКТРОПОГРУЖНОГО оборудования скважин нефтяной компании «Роснефть» (Компании).

В данной дипломной работе проведено исследование процесса работы пользователей с информационной системы учета электропогружного оборудования скважин (ИС «ЭПОС»). Целью работы является повышение эффективности работы пользователей ИС «ЭПОС».

В результате данной работы было спроектирована, разработана и внедрена подсистема оповещения в ИС «ЭПОС», устраняющая недостатки в работе ИС «ЭПОС». Разработаны и реализованы спецификации требований на внесение изменений в ИС «ЭПОС».

Подсистема оповещения разработана в среде программирования Microsoft Visual Studio и внедрена с применением системы управления версиями SourceGear Vaul.

Подсистема оповещения разработана, внедрена и находится на стадии тестирования жизненного цикла ИС «ЭПОС».

Содержание

Реферат 2

Содержание 3

Перечень понятий и сокращений 5

Введение 6

1. Описание предметной области 9

1.1. Модель бизнес-процессов 10

1.2. Обзор ИС «ЭПОС» 14

2. Обзор аналогов 19

2.1. Подсистема оповещений и уведомлений системы «Дело» 19

2.2. Програм Лайн: Уведомления о событиях 22

2.3. Подсистема «Выписка Онлайн» в ДБО BS-Client x64 25

2.4. Вывод 28

3. Постановка задачи 30

4. Контур Подсистемы 32

5. Инфологическая модель предметной области 37

6. Виды обеспечения 39

6.1. Информационное обеспечение 39

6.2. Математическое обеспечение 47

6.3. Программное обеспечение 50

6.3.1. Подсистема связи с СУБД 51

6.3.2. API СУБД 52

6.3.3. Модуль опроса базы данных 58

6.3.4. Модуль оперативного оповещения 58

6.3.5. Модуль формирования заявок 60

6.3.6. Модуль формирования подписок 61

6.4. Техническое обеспечение 61

7. Описание интерфейса 62

7.1. Оповещение по событиям 62

7.2. Оповещение о запросах 66

7.3. Контроль ввода данных 69

8. Технико-эксплутационные характеристики 71

Заключение 73

Список использованных источников 75

Приложение 1 77

Приложение 2 79

Перечень понятий и сокращений

БД – база данных

ДК – мероприятие расследования причин внутрисменной остановки комплекта погружного оборудования на подконтрольной скважине, либо ее отказа

ДО – дочернее добывающее общество

ИС – информационная система

НЭО – наземное электрооборудование скважины

ОК – отдел качества

ПО – погружное оборудование

РФ – Российская Федерация

СП – сервисное предприятие

СУБД – система управления базами данных

ЭПОС – система учета электропогружного оборудования скважины

Событие – регистрация факта внутрисменной остановки комплекта погружного оборудования на подконтрольной скважине, либо ее отказ

Компания – ОАО «НК «Роснефть»

Подсистема – подсистема оповещения, разработанная для внедрения в «ЭПОС»

Введение

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

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

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

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

  1. недостаточный контроль за своевременный ввод данных;
  2. отсутствие возможности создания запросов на коррекцию и дополнение данных;
  3. отсутствие оповещения о вводе данных по Событиям.

Для разработки Подсистемы была использована среда разработки Microsoft Visual Studio. Разработанная подсистема способна расширить «ЭПОС» функциями:

  1. оповещение пользователя о несвоевременном вводе данных;
  2. оповещение пользователя о Событиях;
  3. формирование запросов на коррекцию и дополнение данных;
  4. оповещение пользователя о некорректных и неполных данных.

Благодаря спиральной модели жизненного цикла ЭПОСа, автор воспользовался возможностью внедрить Подсистему в «ЭПОС» и устранил тем самым выявленные недостатки в работе ИС «ЭПОС». Для качественного внедрения были использована система управления версиями SourceGear Vault.

В процессе внедрения были внесены изменений в компоненты ЭПОСа для обеспечения взаимодействия Подсистемы с ИС «ЭПОС».

  1.  Описание предметной области

Нефтяная промышленность РФ – основной сектор топливно-энергетического комплекса нашей страны. От ее успешного функционирования зависят эффективное удовлетворение внутреннего и внешнего спроса на нефть и продукты ее переработки, обеспечение валютных и налоговых поступлений в федеральный бюджет. Не менее важна эта отрасль и для энергетической безопасности страны и ее политических интересов в мире [1].

Большое место в нефтяной промышленности РФ занимает ОАО «НК «Роснефть». Компания добывает большую часть нефти по всей территории РФ. Большие объемы добычи достигаются благодаря интенсивной разработке месторождений и большому количеству используемых скважин (миллионы). Для технического обслуживания такого большого числа скважин в Компании работают множество сервисных предприятий.

Эффективность использования нефтепромыслового подземного оборудования во многом зависит от повышения качества его изготовления, подбора оборудования, соблюдения технологии монтажа и эксплуатации[2]. Повышение качества серийно изготавливаемого оборудования необходимо добиваться за счет повышения качества рекламационной работы к заводам–изготовителям, т.е. полно и качественно проводить учет и анализ работы узлов оборудования. Данная работа требует накопления большой статистики по причинам отказа узлов оборудования, о наработке их за срок службы, о характеристиках рабочей среды, и условий эксплуатации, где используется данное оборудование.

Анализ причин остановки и повторных ремонтов дает возможность разработать конкретные мероприятия по значительному сокращению их количества.

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

Для решения таких задач Компания применяет «ЭПОС», с помощью которой проводится сбор данных из СП для анализа.

  1.  Модель бизнес-процессов

Объектом исследования является процесс работы сотрудников СП и отдел качества с ИС «ЭПОС». На вход процесса поступает информация из различных источников в бумажном и электронном виде. Сотрудники СП и отдел качества руководствуются соответствующими положениями и инструкциями пользователя «ЭПОС». В результате работы оформляются сводные отчеты, а пользователи отдел качества с помощью ИС «ЭПОС» формируют протокол расследования.

Модель бизнес-процессов описана согласно нотации IDEF0. IDFE0 используется для создания функциональной модели, отображающей структуру и функции системы, а также потоки информации и материальных объектов, связывающие эти функции[3]. Концептуальная схема предметной области представлена на рис. 1.

Рис.1. Концептуальная схема предметной области

При декомпозиции процесса работы пользователя с «ЭПОС» можно выделить 4 основных процесса:

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

Модель бизнес-процессов предметной области представлена на рис.2.

Рис. 2. Модель бизнес-процессов

При такой модели время от начала расследования до оформления протокола по ДК складывается из следующих составляющих:

– время поиска событий для расследования [1 – 8 час];

– время запроса коррекции и дополнения данных [1 час];

– время поиска ответственных за ввод данных [2 – 4 часа];

– время дополнения и коррекции данных [8 – 16 часов];

– возобновления расследования после выполнения запроса [8– 16 часа];

– время расследования событий с корректными и полными данными [2 – 6 часов].

Рис. 3. Временные затраты бизнес-процессов

Таким образом, время от начала расследования до оформления протокола, по оценке автора, может доходить до   рабочих часов, что в переводе на дни может составлять 6-7 рабочих дней, как это видно на рис. 3.

  1.  Обзор ИС «ЭПОС»

Информационная система «ЭПОС» предназначена для ведения оперативного учёта, контроля и анализа параметров эксплуатации и ремонта электропогружного оборудования, их узлов, НЭО и кабеля и формирования первичной, оперативной и аналитической отчетности ОАО «НК «Роснефть», а также сторонних предприятий, задействованных в процессе учёта. В системе реализован широкий спектр функций по учету операций над оборудованием, позволяющие отслеживать состояние оборудования и его параметров на всем его жизненном цикле.

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

  1. технические характеристики оборудования;
  2. параметры эксплуатации;
  3. результаты ремонта;
  4. наличие и движение оборудования.

Подобная информация необходима пользователям добывающих организаций для:

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

В результате работ добывающих организаций ОАО «НК «Роснефть» получает необходимое количество информации для:

  1. проведения анализа эксплуатации оборудования;
  2. формирования рейтингов;
  3. ведения статистики по результатам добывающих обществ.

Жизненный цикл ИС «ЭПОС» построен на основе спиральной модели, которая предполагает постоянное развитие информационной системы. Благодаря этому и тому, что ИС «ЭПОС» является собственной разработкой Компании, есть возможность интегрировать в ИС «ЭПОС» дополнительные подсистемы, модули и расширять тем самым функционал системы, адаптируя ее под новые нужды пользователя.

Архитектура информационной системы «ЭПОС» представлена на рис. 4. Архитектура ИС «ЭПОС» построена по принципу «клиент-сервер». Клиентское приложение тиражируется на множество рабочих мест различных подразделений и предприятий.

Клиентская часть системы учёта оборудования «ЭПОС» содержит 7 элементов:

  1. подсистема связи с СУБД;
  2. модуль кэширования;
  3. подсистема формирования отчетов;
  4. подсистема управления конфигурациями;
  5. подсистема ввода и редактирования данных;
  6. подсистема безопасности;
  7. пользовательский интерфейс.

Рис. 4. Архитектура ИС «ЭПОС»

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

Пример графического интерфейса ЭПОСа представлен на рис. 5.

Рис. 5. Графический интерфейс ЭПОСа

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

  1.  Обзор аналогов

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

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

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

  1.  Подсистема оповещений и уведомлений системы «Дело»

«Подсистема оповещений и уведомлений» предназначена для автоматической рассылки уведомлений и оповещений в электронную почту пользователей о различных событиях системы электронного документооборота (СЭД) «ДЕЛО»[9].

Рассылка оповещений производится всем пользователям системы «ДЕЛО», в соответствии с их правами и должностями. «Подсистема оповещений и уведомлений» обеспечивает рассылку оповещений при следующих событиях:

  1. пересылка регистрационной карточки;
  2. отправка документа внутреннему адресату;
  3. ввод поручения;
  4. редактирование поручения;
  5. ввод отчета об исполнении поручения;
  6. направление регистрационной карточки проекта документа на визирование;
  7. направление регистрационной карточки проекта документа на подпись.

«Подсистема оповещений и уведомлений» обеспечивает уведомление пользователей системы «ДЕЛО» о приближении сроков исполнения ими действий по следующим событиям:

  1. исполнение поручения;
  2. контроль поручения;
  3. визирования документа;
  4. подписание документа.

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

Периодичность отправки уведомлений определяется в настройках параметров подсистемы.

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

Периодичность рассылки уведомлений по каждому из событий может быть задана отдельно. Обеспечена возможность задавать периодичность рассылки с указанием, в какие именно дни следует направлять первое, второе и так далее уведомления.

Место подсистемы оповещения в СЭД «Дело» изображено значком на рис. 6.

Рис. 6. Подсистема оповещения в СЭД «Дело»

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

Пример оповещения изображен на рис. 7.

Рис. 7. Пример оповещения в СЭД «Дело»

Так как подсистема «Оповещения и уведомления» интегрирована с «ДЕЛО-Web» (в рассылаемых подсистемой сообщениях размещаются ссылки на регистрационные карточки для открытия через «ДЕЛО-Web»), то необходимо при покупке данной подсистемы приобретать и серверную часть «ДЕЛО-Web».

  1.  Програм Лайн: Уведомления о событиях

Подсистема «Програм Лайн: Уведомления о событиях» была опробована на пилотном проекте в группе компаний «КАМИ» — крупнейшем в стране поставщике промышленного оборудования. Подсистема была встроена в эксплуатируемую там 1С:УПП. На текущий момент настроено порядка 20 различных уведомлений, сообщения регулярно получают более 100 человек[10].

Подсистема «Програм Лайн: Уведомления о событиях» предназначена для рассылки оповещений пользователям и партнерам о важных событиях в информационной базе, например:

  1. менеджеру - о поступлении оплаты заказа, срыве сроков поставки, приходе нового товара;
  2. клиенту - о готовности его заказа к отгрузке, просроченной задолженности или наступлении срока очередного платежа и так далее.

Принцип работы «Програм Лайн: Уведомления о событиях» изображен на рис. 8.

Рис. 8. Принцип работы «Програм Лайн: Уведомления о событиях»

Обрабатываются два вида событий информационной базы:

  1. при изменении данных в базе — поступление оплаты от клиента, изменение состояния заказа, согласование заявки на оплату и так далее;
  2. при периодическом анализе данных — для напоминания о сроке очередного платежа или просроченном платеже, поздравлении с днем рождения и так далее.

Подсистема встраивается в любую конфигурацию, включая УПП, УТ 10.3, УП 2.0 (ERP), УТ 11, Бухгалтерию и так далее. Встраивание не затрагивает типовые объекты и модули и не оказывает влияния на последующие обновления. Работает с конфигурациями на платформах 1С 8.2 и 8.3. Код полностью открыт для изменений. Пример оповещения представлен на рис. 9.

Рис. 9. Пример оповещения в «Програм Лайн: Уведомления о событиях»

Интерфейс подсистемы проработан для интуитивного освоения, настраивать простые уведомления сможет пользователь, а более сложные — специалисты поддержки базы 1С.

  1.  Подсистема «Выписка Онлайн» в ДБО BS-Client x64

Подсистема «Выписка Он-Лайн» комплексного решения для дистанционного банковского обслуживания юридических лиц «ДБО BS-Client x64» предназначена для информационного обслуживания клиентов кредитных организаций в сегментах малого и среднего бизнеса[11].

Подсистема «Выписка Он-Лайн» позволяет клиентам банка получать информацию об остатках и выписки по счетам через сеть Интернет в круглосуточном режиме. Данное решение может использоваться банком совместно с другими подсистемами комплексного решения «ДБО BS-Client x64», обеспечивая единое пространство дистанционного обслуживания клиентов по всем сервисам системы «ДБО BS-Client x64».

Место подсистемы «Выписка Он-лайн» в структуре системы «ДБО BS-Client x64» отражено на рис. 10.

Рис. 10. Выписка Онлайн в системе ДБО BS-Client x64

Подсистема «Выписка Он-лайн» функционирует в паре с сервером Нотификации, который обеспечивает хранение данных для оповещений.

«Сервер Нотификации» v. 2 — это автономный технологический сервис, обеспечивающий автоматическое информирование клиентов банка – юридических и физических лиц - по различным каналам связи[12].

Схема взаимодействия «Сервера Нотификации» изображен на рис. 11.

Рис. 11. Схема взаимодействия «Сервера Нотификации» v. 2

«Сервер Нотификации» v. 2 позволяет банку автоматически информировать клиентов посредством SMS, E-mail, файлового обмена. Система на основе XML-запросов от информационных систем банка (CRM, АБС, ДБО, процессинга и прочее) автоматически генерирует сообщения о поступлении/списании средств, осуществленных операциях в торговой сети, снятии средств в банкомате, изменениях лимита, сроках действия пластиковой карты, других заданных событиях: сроках платежей по кредитам, изменении цен, котировок и прочее.

  1.  Вывод

Рассмотренные подсистемы оповещения функционируют в рамках конкретных систем, однако «Програм Лайн: Уведомления о событиях» допускает возможность интеграции благодаря открытости платформы 1С: «Предприятие». В условиях эксплуатации ИС «ЭПОС» возможность интеграции рассмотренных решений отсутствует из-за требований к безопасности ИС «ЭПОС»[3]. Предлагается разработать частную подсистему оповещения для использования ее в ИС «ЭПОС» учитывая опыт разработчиков рассмотренных аналогов.

Сравнить аналоги можно с помощью таблицы 1.

Таблица 1

Сравнительная таблица аналогов

«Дело»

Програм Лайн

Выписка Он-лайн

Оповещение по Событиям

В области уведомлении Windows

Через Email

Через клиентское приложение, SMS, Email, Web-сайт

Оповещение о заявках

В области уведомлении Windows

Через Email

Нет

Оповещение о задержках

В области уведомлении Windows

Через Email

Нет

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

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

Использование SMS приемлемо для экстренных видов оповещения таких как аварии на скважине, порывы трубопровода и подобные. В рамках работы ИС «ЭПОС» такие оповещения не востребованы. Однако возможно в будущем в рамках развития ИС «ЭПОС» потребность в экстренных оповещениях появиться.

  1.  Постановка задачи

Целью данной работы является – проектирование, разработка и внедрение подсистемы оповещения. Разработанная Подсистема должна устранить ряд недостатков информационной системы «ЭПОС»:

  1. отсутствие возможности отслеживать факты задержек ввода данных по операциям;
  2. отсутствие возможности создавать и отправлять запросы на дополнение и коррекцию данных;
  3. отсутствие оповещения пользователя по Событиям.

Для достижения данной цели необходимо:

  1. изучить предметную область;
  2. изучить ИС «ЭПОС»;
  3. провести обзор существующих подсистем оповещений в различных ИС;
  4. разработать техническое задание на Подсистему;
  5. разработать контур Подсистемы;
  6. разработать инфологическую модель предметной области;
  7. разработать Подсистему;
  8. интегрировать Подсистему с ИС «ЭПОС».

Разработанная Подсистема должна обладать следующими функциями:

  1. оповещение пользователя о новых Событиях;
  2. создание и отправка запроса на коррекцию и дополнение данных;
  3. оповещение пользователя о новых запросах на коррекцию и дополнение данных;
  4. оповещение пользователя о задержках ввода данных.

При внедрении Подсистемы необходимо учесть особенности архитектуры ИС «ЭПОС» и внести изменения в ИС «ЭПОС» для успешной интеграции Подсистемы и ИС «ЭПОС».

  1.  Контур Подсистемы

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

Предполагается, что каждое оповещение на одном рабочее место за один сеанс работы пользователя с ИС «ЭПОС» будет возникать однократно, поэтому кэшировать данные для работы Подсистемы не требуется. Таким образом, Подсистема должна встроиться в структуру ИС «ЭПОС» так, как это показано на рис. 12.

На этапе проектирования заказчик потребовал следующие функции:

  1. оповещение пользователя о Событиях;
  2. оповещение пользователя о запросах на коррекцию и дополнение данных;
  3. возможность оформлять и отправлять запросы на коррекцию и дополнение данных;
  4. возможность оформлять подписки на оповещения;
  5. оповещение пользователя о задержках ввода данных.

Рис. 12. Подсистема оповещения в ИС «ЭПОС»

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

  1. модуль формирования подписки – оформляет подписки на события по выбранному перечню оборудования;
  2. модуль формирования заявок пользователю СП – оформляет заявки на дополнение и коррекцию данных, необходимых для расследования отказов оборудования. Заявки отправляются на хранение в базу данных до востребования модулем опроса базы данных со стороны пользователя сервисного предприятия;
  3. модуль опроса базы данных – с определенным промежутком времени обращается к базе данных за данными для оповещений пользователя;
  4. модуль оперативного оповещения – активирует графические средства оповещения в пользовательском интерфейсе.

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

Контур Подсистемы представлен на рис. 13.

Рис. 13. Контур подсистемы оповещения

Подсистема взаимодействует с подсистемой связи с СУБД и с пользовательским интерфейсом ИС «ЭПОС». Для внедрения необходимо внести изменения в:

  1. пользовательский интерфейс – добавить формы для формирования подписок и заявок, графические элементы сигнализирования и графические окна просмотра оповещений;
  2. подсистему связи с СУБД – добавить дополнительные модули для связи подсистемы оповещения и СУБД;
  3. API СУБД – добавить дополнительные функции внесения данных по оповещения их извлечения и модификации;
  4. базу данных – дополнить таблицами для сущностей связанных с оповещением.

Изменения в БД, подсистему связи с СУБД и API СУБД подробно описаны в настоящей работе в пункте 6.1, 6.3.1 и 6.3.2 соответственно. Изменения в графическом интерфейсе подробнее описаны в разделе 7.

Данные изменения необходимы для успешной интеграции Подсистемы с ИС «ЭПОС».

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

  1.  Инфологическая модель предметной области

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

Скважины могут объединяться в группы для подписок по Событиям. Одна скважина может входить в несколько групп. Пользователь может подписываться на несколько групп скважин. Так как одно оповещение по Событиям может адресоваться нескольким пользователям, то статус оповещения устанавливается относительно каждого адресата.

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

  1. скважина;
  2. пользователь;
  3. сервисное предприятие;
  4. события;
  5. группа скважин;
  6. протокол ДК;
  7. запросы.

Инфологическая модель предметной области представлена на рис. 14.

Рис. 14. Инфологическая модель предметной области

Представленная модель оформлена с помощью языка ER-диаграмм (от англ. Entity-Relationship, т.е. сущность-связь). Где стержневые сущности изображены прямоугольниками, ассоциативные – шестиугольниками, характеристические – трапециями, а атрибуты – овалами[4].

  1.  Виды обеспечения

В данном подразделе представлены изменения в ИС «ЭПОС» необходимые для функционирования Подсистемы и разработанные модули Подсистемы.

  1.  Информационное обеспечение

После нормализации инфологической модели предметной области была получена логическая инфологическая модель Подсистемы. Логическая инфологическая модель представлена на рис. 15.

Рис. 15. Логическая инфологическая модель базы данных 

Логическая модель разработана с помощью CASE-средства AllFusion ERwin Data Modeler 7 в нотации IDEF1X.

IDEF1X является методом для разработки реляционных баз данных и использует условный синтаксис, специально разработанный для построения концептуальной схемы структуры данных предприятия, независимой от конечной реализации базы данных и аппаратной платформы[5].

С помощью CASE-средство AllFusion ERwin переход от логической модели к физической происходит достаточно легко[6]. Благодаря данной возможности задача модификации существующей базы данных ИС «ЭПОС» не вызвала затруднений. Физическая инфологическая модель Подсистемы представлена на рис. 16. В качестве СУБД было использовано MS SQL Server 2008 R2, которое обеспечивает управление данными ИС «ЭПОС» на сервисных предприятиях ООО «Юганскнефтегаз». Так как в базе данных ИС «ЭПОС» информация о пользователях уже имеется, то таблицу USERS создавать нет необходимости.

Для рассылки по электронной почте используется компонент СУБД – Database Mail.

Компонент Database Mail — это решение уровня предприятия для отправки сообщений электронной почты от компонента SQL Server Database Engine. Используя компонент Database Mail, приложения базы данных могут отправлять почтовые сообщения пользователям. Сообщения могут содержать результаты запроса, а также могут включать файлы из любого сетевого ресурса. Компонент Database Mail спроектирован для надежности, масштабируемости, безопасности и простой поддержки[14].

Рис. 16. Инфологическая модель Подсистемы

Физическая инфологическая модель Подсистемы содержит в себе таблицы:

  1. NOTIFY_LIST_WELLS – таблица групп со скважинами для подписок. Она необходима для хранения информации о группах скважин для подписки. Список атрибутов таблицы NOTIFY_LIST_WELLS описан в табл. 2. Менять значения параметров подписки может только автор. Группы с указанным параметром «Общая группа», доступны для подписки всем пользователей, иначе оповещение будет приходить только автору группы.

Таблица 2

Описание атрибутов таблицы NOTIFY_LIST_WELLS

Атрибут

Тип данных

Описание

FK

PK

Ограничение целостности

LIST_ID

счетчик

Идентификатор перечня

Нет

Да

NOT NULL (уникальное значение)

LIST_NAME

текстовый

Наименование перечня скважин

Нет

Нет

NOT NULL (<255 символов)

OWNER

текстовый

Автор перечня

Да

Нет

NOT NULL (<255 символов)

CDS_STOP

логический

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

Нет

Нет

NOT NULL

EPOS_DEMOUNT

логический

Демонтаж

Нет

Нет

NOT NULL

EPOS_DISASM

логический

Разбор

Нет

Нет

NOT NULL

SUBS_DATE

дата

Дата подписки

Нет

Нет

NOT NULL (<Текущей даты)

SHARED

логический

Общая группа

Нет

Нет

NULL

  1. QUALITY_DAY_REC – таблица протоколов дня качества, она необходима для хранения данных о протоколах дня качества. Список атрибутов таблицы QUALITY_DAY_REC описан в табл. 3. Таблица связана с таблицами NOTIFY_EVENTS и NOTIFY_REQUEST_DATA

Таблица 3

Описание атрибутов таблицы QUALITY_DAY_REC

Атрибут

Тип данных

Описание

FK

PK

Ограничение целостности

QUALITY_DAY_REC_ID

Счетчик

Идентификатор протокола

Нет

Да

NOT NULL (уникальное значение)

QUALITY_DAY_REC_DATE

дата

Дата создания протокола

Нет

Нет

NOT NULL (<Текущей дату)

EVENT_ID

числовой

Идентификатор События

Да

Нет

NOT NULL

STOP_YMD

дата

Дата отказа скважины

Нет

Нет

NOT NULL (<Текущей даты)

  1.  WELL – таблица сущности «скважина», она необходима для хранения данных о скважинах. В таблице хранятся данные о местонахождении скважины. Список атрибутов таблицы WELL описан в табл. 4.

Таблица 4

Описание атрибутов таблицы WELL

Атрибут

Тип данных

Описание

FK

PK

Ограничение целостности

WELL_ID

числовой

Идентификатор скважины

Нет

Да

NOT NULL (уникальное значение)

OILWELL

текстовый

Имя скважины

Нет

Нет

NOT NULL (<30 символов)

REGION

текстовый

Регион

Нет

Нет

NOT NULL (<30 символов)

OIL_FIELD

текстовый

Месторождение

Нет

Нет

NOT NULL (<30 символов)

WELL_CLUSTER

текстовый

Куст

Нет

Нет

NOT NULL (<30 символов)

SHOP

текстовый

Цех

Нет

Нет

NOT NULL (<30 символов)

NOTE

текстовый

Примечание

Нет

Нет

NULL (<255 символов)

KIT_PO_NUMBER

текстовый

Номер комплекта ПО

Нет

Нет

NULL (<30 символов)

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

  1. NOTIFY_EVENTS – таблица событий, связанных со скважинами. Список атрибутов таблицы NOTIFY_EVENTS описан в табл. 5. Информация данной таблицы используется при оповещении по Событиям.

Таблица 5

Описание атрибутов таблицы NOTIFY_EVENTS

Атрибут

Тип данных

Описание

FK

PK

Ограничение целостности

EVENT_ID

числовой

Идентификатор события

Нет

Да

NOT NULL (уникальное значение)

WELL_ID

числовой

Идентификатор скважины

Да

Нет

NOT NULL

EVENT_DATE

дата

Дата события

Нет

Нет

NOT NULL (<текущей даты)

STOP_REASON_TYPE

текстовый

Причина остановки

Нет

Нет

NULL (<150 символов)

OPERATION_ID

числовой

Операция в ЭПОС

Нет

Нет

NULL

MPR

числовой

Межремонтный период

Нет

Нет

NULL (>0)

MODUFY_DATE

дата

Дата модификации записи в ЭПОС

Нет

Нет

NULL (<текущей даты и >EVENT_DATE)

EVENT_TYPE_ID

числовой

Идентификатор типа события

Да

Нет

NULL

  1. NOTIFY_ACTIVE_EVENTS – таблица, хранящая информацию об оповещении пользователя о событии. Список атрибутов таблицы NOTIFY_ACTIVE_EVENTS описан в табл. 6. Оповещение о Событие может приходить нескольким пользователям и в разное время. После получения оповещения пользователь может сменить статус События относительно себя. В зависимости от статуса оповещения могут приходить повторно или приходить только при изменении информации о Событии. Хранить время изменения статуса События нет необходимости.

Таблица 6

Описание атрибутов таблицы NOTIFY_ACTIVE_EVENTS

Атрибут

Тип данных

Описание

FK

PK

Ограничение целостности

EVENT_ID

числовой

Идентификатор события

Да

Да

NOT NULL (>0)

STATUS_ID

числовой

Идентификатор статуса

Да

Нет

NOT NULL (>0)

USER_NAME

текстовый

Имя пользователя

Нет

Да

NOT NULL (<30 символов)

  1. NOTIFY_REQUEST_DATA – таблица запросов на дополнение или коррекцию данных. Запись имеет ссылку на протокол Дня качества, откуда можно получить информацию о Событии и скважине, по которым необходимо дополнить или скорректировать данные. Сотрудники отдела качества должны иметь возможности отслеживать изменения статуса запроса, для этого необходимо хранить информацию об авторе запроса и дату выполнения запроса. Список атрибутов таблицы NOTIFY_REQUEST_DATA описан в табл. 7.

Таблица 7

Описание атрибутов таблицы NOTIFY_REQUEST_DATA

Атрибут

Тип данных

Описание

FK

PK

Ограничение целостности

REQUEST_ID

числовой

Идентификатор запроса

Нет

Да

NOT NULL (уникальный)

QUALITY_DAY_REC_ID

числовой

Идентификатор протокола Дня Качества

Да

Нет

NOT NULL

REQUEST_STATE_ID

числовой

Статус запроса

Да

Нет

NOT NULL

NOTIFY_REQUEST_TYPE_ID

числовой

Тип запроса

Да

Нет

NOT NULL

REQUEST_DATE

дата

Дата запроса

Нет

Нет

NOT NULL (<текущей даты)

REQUEST_AUTHOT

текстовый

Автор запроса

Да

Нет

NOT NULL (<30 символов)

SERVICE_ENTERPRISE_ID

числовой

Сервисное предприятие

Да

Нет

NOT NULL

REQUEST_COMMENT

текстовый

Комментарий

Нет

Нет

NULL (<4000 символов)

REQUEST_COMPLETE_DATE

дата

Дата выполнения запроса

Нет

Нет

NULL (<текущей даты)

А так же используется ряд справочников:

  1.  DIC_SERVICE_ENTERPRISE – таблица сервисных предприятий;
  2. NOTIFY_INPUT_OPR_PREFS – таблица, хранящая информацию о том, что нужно ли оповещать пользователя о несвоевременном вводе данных;
  3.  NOTIFY_LIST_WELL_SET – таблица отношения скважин к группе;
  4.  DIC_NOTIFY_STATUS – справочник статусов оповещения;
  5.  DIC_NOTIFY_EVENT_TYPE – справочник типов события;
  6.  DIC_NOTIFY_REQUEST_TYPE – справочник типов запроса;
  7.  DIC_NOTIFY_REQUEST_STATE – справочник статусов запроса;
  8. NOTYFY_INPUT_OPR_TYPES – таблица максимально допустимых задержек ввода данных;
  9.  DIC_OPERATION_TYPE – справочник типов операций;
  10. NOTIFY_REQUEST_DATA_FILTERS – таблица, хранящая информацию о фильтрации запросов.

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

Данные для заявки на дополнение и коррекцию данных хранятся в таблице NOTIFY_REQUEST_DATA. По этим данным пользователь со стороны сервисного предприятия получает оповещение, в котором указан номер скважины, ее местоположение (месторождение, куст, цех), дата расследуемого события, автор запроса, тип заявки (на коррекцию или дополнение данных) и дату создания заявки. После отработки заявки пользователь самостоятельно меняет статус заявки, чтобы пользователь со стороны отдела качества мог об этом узнать и проверить исполнение заявки.

  1.  Математическое обеспечение

В Подсистеме используется формула для расчета времени задержки ввода данных:

Оповещение о несвоевременности ввода данных формируется по правилу:

где Z – допустимая задержка ввода данных, определяемая каждым пользователем индивидуально.

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

Блок-схема алгоритма работы подсистемы оповещения изображена на рис. 17.

Рис. 17. Алгоритм работы Подсистемы

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

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

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

  1.  Программное обеспечение

В данном подразделе описаны изменения, которые необходимо внести в подсистему связи с СУБД и API СУБД, а также описаны модули Подсистемы.

Изменения и модули Подсистемы разработаны с помощью среды разработки Microsoft Visual Studio 2008. Внесения изменений и интеграция Подсистемы с ИС «ЭПОС» были проведены на одном из этапов развития целевой системы.

Программа работает на Framework 3.5, поддерживающий операционную систему Windows XP[13]. При внесении изменений в графический интерфейс были использованы пакеты графических компонентов DevExpress. Легкая интеграция Подсистемы с ИС «ЭПОС» была достигнута благодаря системе управления версиями SourceGear Vualt версии 5.1.2. Для тиражирования Подсистемы на рабочие места использовалась ClickOne. СУБД было использовано Microsoft SQL Server 2008 R2. Изменения в базу данных ИС «ЭПОС» были внесены с помощью среды SQL Server Management Studio.

  1.  Подсистема связи с СУБД

Для взаимодействия Подсистемы с СУБД были разработаны и внесены модули:

  1.  DataSet_DelayNotifications – оповещение по задержкам ввода данных;
  2. DataSet_EventNotifications – оповещение по событиям;
  3. DataSet_EventNotifications_Lists – список личных групп  подконтрольных скважин;
  4.  DataSet_EventNotifications_SharedLists – список общих групп скважин;
  5.  DataSet_RequestResponce_List – оповещение о запросах на коррекцию и дополнение данных;
  6.  DataSet_OPR_Stop – создание запроса на коррекцию и дополнение данных.

Каждый модуль подсистемы связи с СУБД взаимодействует с несколькими процедурами из API СУБД согласно таблице 8

Таблица 8

Описание модулей подсистемы связи с СУБД

Имя модуля

Связанные процедуры в API СУБД

DataSet_DelayNotifications

get_input_monitoring_prefs, set_input_monitoring_prefs

DataSet_OPR_Stop

add_data_request,  get_request_receivers, get_data_request_attr

DataSet_RequestResponce_List

add_data_request, update_data_requests_state, rem_data_request, get_request_receivers

DataSet_EventNotifications_SharedLists

get_lists_wells, get_lists_wells_set

DataSet_EventNotifications

get_active_lists_wells, get_events, upd_active_events_status

DataSet_EventNotifications_Lists

get_lists_wells, del_lists_wells, add_lists_wells, upd_lists_wells, upd_lists_wells_set_note, add_lists_wells_set, del_lists_wells_set, get_lists_wells_set

Разработанные модули обеспечивают обмен данными между Подсистемой и API СУБД. Помимо взаимодействия с API СУБД модули обеспечивают контроль данных для снижения количества ошибок пользователя.

  1.  API СУБД

Для доступа к данным были разработаны и внесены в ИС «ЭПОС» хранимые процедуры:

  1.  get_input_monitoring_prefs – вызов параметров для контроля за задержкой ввода данных;
  2.  get_active_lists_wells – запрос данных для оповещения по Событиям;
  3. get_events – запрос данных по событию, выбранной скважины;
  4.  get_data_request_attr – получение данных по запросу;
  5.  del_lists_wells – удаление группы из подписки;
  6. del_lists_wells_set – удаление скважины из группы подписки;
  7. upd_lists_wells – обновление значений параметров подписки на События;
  8.  get_data_request – формирование заявок на коррекцию и дополнение данных;
  9. add_data_request – добавление заявок на коррекцию и дополнение данных;
  10. add_lists_wells – добавление группы скважин;
  11. add_lists_wells_set – добавление скважины в группу подписок;
  12. update_data_requests_state – обновление статуса запроса;
  13.  upd_lists_wells_set_note – обновление параметров скважин в подписке;
  14. upd_active_events_status – обновление статуса оповещения по Событиям;
  15. get_request_receivers – получение списка запросов;
  16. rem_data_request – удаление запроса;
  17. get_lists_wells – запрос данных по подписке;
  18. copy_lists_wells – копирование общую группу в список личных групп;
  19. set_input_monitoring_prefs – обновление параметров для настройки подписки на оповещение по задержкам ввода данных;
  20. get_data_requests_count – возвращает количество необработанных запросов;
  21. get_lists_wells_set – управление общими группами подписок.

Разработанные хранимые процедуры обеспечивают операции над данными, хранящимися на сервере СУБД. Подробно хранимые процедуры описаны в таблице 9.

Таблица 9

Описание хранимых процедур

Имя процедуры

Параметр

Описание

set_input_monitoring_prefs

IS_MONITORING_ENABLE (входной параметр)

Включение оповещения о задержках ввода данных

CRITICAL_DELAY_PERIOD (входной параметр)

Допустимая задержка ввода данных

MONITOR_OPERATION_TYPE_IDS (входной параметр)

Электронная почта пользователя

get_data_requests_count

CNT (выходной параметр)

Количество необработанных запросов

get_new_events_count

CNT (выходной параметр)

Количество новых Событий

Продолжение табл. 9

Имя процедуры

Параметр

Описание

get_input_monitoring_prefs

IS_MONYTORING_ENABLE (выходной параметр)

Включение оповещения о задержках ввода данных

CRITICAL_DELAY_PERIOD (выходной параметр)

Допустимая задержка ввода данных

EMAIL (выходной параметр)

Электронная почта пользователя

OPERATION_TYPES (выходной параметр)

Список типов операций для подписки

upd_active_events_status

EVENT_ID (входной параметр)

Идентификатор События

STATUS_ID (входной параметр)

Идентификатор нового статуса

get_active_lists_wells

ACTIVE_LISTS (выходной параметр)

Список подписанных групп

del_lists_wells_set

LISTS_ID (входной параметр)

Идентификатор группы

WELL_ID (входной параметр)

Идентификатор удаляемой из группы скважины

add_lists_wells_set

LISTS_ID (входной параметр)

Идентификатор группы

WELL_ID (входной параметр)

Идентификатор новой в группе скважине

NOTE (входной параметр)

Комментарий

get_events

FROM_DATE (входной параметр)

Дата «после»

TO_DATE (входной параметр)

Дата «до»

LISTS_IDS (входной параметр)

Идентификатор подписанной группы

IS_HISTORY (входной параметр)

Признак архивных данных

EVENTS (выходной параметр)

Список Событий

Продолжение табл. 9

Имя процедуры

Параметр

Описание

upd_lists_wells_set_note

LISTS_ID (входной параметр)

Идентификатор группы

WELL_ID (входной параметр)

Идентификатор изменяемой скважины

NOTE (входной параметр)

Новое значение комментариев

IS_ACTIVE (входной параметр)

Новое значение «подписана»

del_lists_wells

LISTS_ID (входной параметр)

Идентификатор удаляемой группы

add_lists_wells

LISTS_ID (выходной параметр)

Идентификатор новой группы

LISTS_NAME (входной параметр)

Название новой группы

upd_lists_wells

LISTS_ID (входной параметр)

Идентификатор обновляемой группы

LISTS_NAME (входной параметр)

Новое имя группы

CDS_STOP (входной параметр)

Новое значение подписки на события остановки скважины

EPOS_DEMOUNT (входной параметр)

Новое значение подписки демонтаж скважины

EPOS_DISASM (входной параметр)

Новое значение подписки разбора скважины

SHARED (входной параметр)

Новое значение «общая группа»

copy_lists_wells

SRC_LISTS_ID (входной параметр)

Идентификатор группы из источника

DST_LISTS_NAME (входной параметр)

Имя группы

DST_LISTS_ID (входной\выходной параметр)

Новый идентификатор группы

NAME_EXISTS (выходной параметр)

Сигнал о совпадении идентификаторов группы

Окончание табл. 9

Имя процедуры

Параметр

Описание

get_data_requests

quality_day_rec_id (входной параметр)

Идентификатор дня качества

data_requests (выходной параметр)

Список запросов

get_lists_wells

IS_OWNER (входной параметр)

Является ли пользователь автором подписки

ALL_SHARED (входной параметр)

Только общие группы

LIST_WELLS (выходной параметр)

Список групп скважин

get_lists_wells_set

LISTS_ID (входной параметр)

Идентификатор группы

LISTS_WELL (выходной параметр)

Список скважин из группы

add_data_request

DATA_REQUEST_ID (выходной параметр)

Идентификатор созданного запроса

QUALITY_DAY_REC_ID (входной параметр)

Идентификатор протокола «Дня качества»

SERVICE_ENTERPRISE_ID (входной параметр)

Идентификатор сервисного предприятия

REQUEST_TYPE_ID (входной параметр)

Идентификатор типа запроса

REQUEST_COMMENT

(входной параметр)

Комментарий к запросу

update_data_requests_state

DATA_REQUEST_IDS (входной параметр)

Идентификатор изменяемого запроса

REQUEST_STATE_ID (входной параметр)

Идентификатор нового статуса запроса

rem_data_request

DATA_REQUEST_ID (входной параметр)

Идентификатор удаляемого запроса

get_request_receivers

RESULT (выходной параметр)

Список запросов

SERVICE_ENTERPRISE_ID (входной параметр)

Идентификатор сервисного предприятия

Использование хранимых процедур позволяет снизить нагрузку на компьютерную сеть и упрощает разработку клиентских приложений[8].

  1.  Модуль опроса базы данных

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

  1.  Модуль оперативного оповещения

Для оперативного оповещения пользователя о Событиях в модуле используется класс EventNotifications. Класс описывает правила, в соответствии с которым требуется активировать графический элемент пользовательского интерфейса, а именно:

  1. если количество событий находится от 1 до 8 включительно, то вывести в правом нижнем углу экрана значок в форме красного круга с цифрой в центре, соответствующей количеству событий;
  2. если количество событий больше 9, то вывести в правом нижнем углу экрана значок в форме красного круга с символом «>9» в центре;
  3. если курсор мыши наведен на графический элемент, то отразить рядом с курсором сообщение «ЭПОС: Оповещение о событиях».

Инициализация класса происходит только по сигналу из модуля опроса базы данных. Листинг класса EventNotifications представлен в приложении 1.

Для оперативного оповещения пользователя о запросах от отдела качества в модуле используется класс RequestNotifications. Класс описывает правила, в соответствии с которым требуется активировать графический элемент пользовательского интерфейса, а именно:

  1. если количество запросов находится от 1 до 8 включительно, то вывести в правом нижнем углу экрана значок в форме красного квадрата с цифрой в центре, соответствующей количеству запросов;
  2. если количество запросов больше 9, то вывести в правом нижнем углу экрана значок в форме красного квадрата с символом «>9» в центре;
  3. если курсор мыши наведен на графический элемент, то отразить рядом с курсором сообщение «ЭПОС: Оповещение о запросах».

Инициализация класса происходит только по сигналу из модуля опроса базы данных. Листинг класса RequestNotifications представлен в приложении 2.

  1.  Модуль формирования заявок

Для обеспечения возможности создания заявок на коррекцию и дополнение данных был разработан соответствующий модуль. Модуль содержит класс DKRequest_Edit. Класс позволяет создавать заявки на дополнение и коррекцию данных. На вход модуля со стороны пользователя поступает:

  1. информация по отказу:
  2. местоположение скважины (регион+месторождение+куст);
  3. номер комплекта погружного оборудования;
  4. дата отказа;
  5. сервисное предприятие, осуществившее демонтаж;
  6. параметры рассылки:
  7. сервисное предприятие;
  8. пользователь сервисного предприятия;
  9. тип запроса (коррекция/дополнение);
  10. статус (при создании запроса по умолчанию «новый»);
  11. комментарий.

В результате работы модуля формируется запрос, который отправляется через модуль DataSet_OPR_Stop в подсистеме связи с СУБД в базу данных до востребования.

  1.  Модуль формирования подписок

Для обеспечения возможности управления подписками на оповещение по событиям был разработан модуль формирования подписок. Модуль предоставляет возможность просматривать группы скважин через модуль DataSet_EventNotifications_SharedLists. Редактирование и создание новых личных групп, и их состав происходит с использованием модуля DataSet_EventNotifications_Lists. Для просмотра оповещений по событиям и изменения их статус используется модуль DataSet_EventNotifications подсистемы связи с СУБД.

  1.  Техническое обеспечение

Так как Подсистема работает в составе ИС «ЭПОС» техническое обеспечение используется целевой системы, а именно:

  1. сервер СУБД
  2. процессор Intel Xeon 3 ГГц или его аналог;
  3. оперативная память не менее 2 Гб
  4. не менее 20 Гб свободного пространства на жестких дисках.
  5. Рабочая станция
  6. процессор Pentium III или его аналог;
  7. оперативная память не менее 512 Мб;
  8. сетевая карта 10/100 Мбит/с Ethernet adapter;
  9. устройства ввода;
  10. дисплей с разрешением не менее 800х600.

Аппаратура передачи данных обеспечивает пропускную способность канала передачи данных от сервера СУБД к компьютерам пользователей не менее 2 Мб/c.

  1.  Описание интерфейса

В данном разделе описаны изменения пользовательского интерфейса ИС «ЭПОС», которые необходимо было внести для внедрения Подсистемы.

Оперативное оповещение о Событиях и запросах происходит с помощью отображения специальных значков в панели задач операционной системы Windows, как показано на рис. 18. Оповещение о Событиях отображается в форме красного круга со значением количества новых оповещений о Событиях (элемент 1 на рис. 18). Оповещение о запросах отображается в форме красного квадрата (элемент 2 на рис. 18) со значением количества новых оповещений о вводе данных.

Рис. 18. Оперативное оповещение

В пользовательском интерфейсе использованы элементы пакетов DevExpress, которые отвечают большим эргономическим требованиям и обладают большими функциональными возможностями, чем элементы стандартных пакетов Visual Studio.

  1.  Оповещение по событиям

Чтобы посмотреть оповещение о Событиях необходимо зайти в меню «Сервис» и выбрать в разделе «Оповещение» пункт «Контроль событий». Вкладка содержит две вложенных в нее вкладки – «Журнал событий» и «Архив событий».

Журнал событий содержит новые оповещения о Событиях. Как видно из рис. 19. в Журнале Событий реализовано контекстное меню (элемент 1 рис. 19) для записей Событий. Благодаря данному меню пользователь получает возможность менять статус записи оповещения, обращаться к подсистеме формирования отчетов за информацией о полной истории выбранной скважины или о разборе оборудования связанного с выбранной скважины.

Вкладка «Архив событий» (элемент 2 рис. 19) отображает информацию обо всех Событиях, которые связаны с какой-либо скважиной из числа подписок пользователя.

Рис. 19. Вкладка «Контроль событий»

В правой части вкладки находится область «Группы» (элемент 3 рис. 19), где отображены группы скважин, на которые подписан пользователь. Для управления подписками следует нажать кнопку «Управление группами …» (элемент 4 рис. 19). После нажатия кнопки произойдет вызов окна «Управление группами». Внешний вид окна «Управление группами» изображено на рис. 20. Данное окно позволяет пользователю оформлять подписки. Создание и удаление групп и скважин из состава подписки в окне имеются специальные кнопки с символами «+» и «х» (элементы 1а и 1б на рис. 20).

Группа, которая определена как «Общая группа» (элемент 2 на рис. 20) доступна для копирования в состав подписки другим пользователем, при этом права на изменения параметров группы остаются за автором группы. Для того, чтобы скопировать Общую группу в состав своей подписки, пользователю следует нажать на кнопку «Показать общие группы» (элемент 3 на рис. 20).

Рис. 20. Окно «Управление группами»

После нажатия на кнопку «Показать общие группы» вызовется окно «Копирование общих групп», в котором пользователь может включить общую группу (элемент 2 рис. 21) в список личных групп (элемент 3 рис. 21) или удалить при помощи кнопок с символами «<» и «>» (элементы 1а и 1б на рис. 21) соответственно. Внешний вид окна «Копирование общих групп» изображено на рис. 21.

Рис. 21. Окно «Копирование общих групп»

Перед копированием или удалением можно ознакомиться с составом выбранной группы (элементы 4 и 5 на рис. 21).

В случае если выбранная при копировании группа совпадает именем с какой-нибудь группой из личных групп, то вызывается окно «Выбор действия». Внешний вид окна изображен на рис. 22.

Рис. 22. Окно «Выбор действий»

Окно предлагает сохранить общую группу в списке личных групп с новым именем (элемент 1 на рис. 22) или дополнить состав существующей личной группы новыми скважинами (элемент 2 на рис. 22).

  1.  Оповещение о запросах

Чтобы просмотреть оповещения о запросах, необходимо зайти в меню «Сервис» и в разделе «Оповещение» выбрать пункт «Запросы от ОК». В этом случае вызовется вкладка «Запросы от ОК», в которой пользователю отобразиться список необработанных запросов на дополнение или коррекцию данных, за которые он ответственен. Как видно из рис. 23. для записей запросов пользователей имеет возможность назначить статус «В работе» или «Выполнен» (элемент 1 на рис. 23).

Рис. 23. Вкладка «Запросы от пользователей ОК»

Чтобы просмотреть все запросы на дополнение и коррекцию данных по какой-нибудь скважине за какой-нибудь период времени можно обратиться к архиву запросов (элемент 2 на рис. 23). Для просмотра состояния запросов пользователь отдела качества может открыть подобную вкладку через пункт «Запросы по ДК» того же раздела меню. Внешний вид окна «Запросы по ДК» изображен на рис. 24.

Во вкладке «Архив запросов» есть возможность отфильтровать список запросов за определенный период (элемент 4 на рис. 24) и\или по скважине (элемент 3 на рис. 24).

Рис. 24. Окно «Запросы по ДК»

Пользователь отдела качества при работе с протоколом ДК, при необходимости может вызвать список запросов на коррекцию и дополнение данных, созданных кем-либо из пользователей ИС «ЭПОС» или запросы созданных только им (элемент 2 на рис. 24). С помощью контекстного меню пользователь отдела качества имеет возможность отправить повторный запрос с такими же параметрами, что у выделенного запроса, определить для запроса статус «Закрыто» и удалить, если статус запроса имеет значение «Закрыто» (элемент 1 на рис. 24).

Для создания нового запроса на коррекцию или дополнение данных по Событию, с протоколом расследования, которого работает пользователь, в окне со списком запросов предусмотрена кнопка «Создать новый запрос». После нажатия этой кнопки происходит вызов окна «Отправить запрос». Окно имеет две области:

  1. информация по отказы (элемент 3 на рис. 25) – содержит поля с данными, необходимые ответственному за ввод данных лицу для обработки запроса;
  2. параметры рассылки (элемент 4 на рис. 25) – содержит поля с данными, необходимыми для отправки запроса.

Для отправки запроса пользователь должен обязательно указать СП и тип запроса (элементы 1 и 2 на рис. 25 соответственно). Внешний вид окна «Отправить запрос» изображен на рис. 25.

Рис. 25. Окно «Отправить запрос»

После нажатия на кнопки «Отправить» запрос отправляется с указанными параметрами на сервер.

  1.  Контроль ввода данных

Для настройки оповещения о несвоевременном вводе данных необходимо в меню «Сервис» выбрать в разделе «Оповещение» пункт «Контроль ввода данных», после чего появится вкладка «Контроль ввода данных». Внешний вид вкладки «Контроль ввода данных» изображен на рис. 26.

Рис. 26. Вкладка «Контроль ввода данных»

В данной вкладке настраивается допустимая задержка (элемент 1 на рис. 26), перечень типов операций (элемент 2 на рис. 26), за задержкой которых необходимо отслеживать и адрес электронной почты (элемент 3 на рис. 26), на который должны приходить оповещения. При необходимости можно отключить оповещение или включить его (элемент 4 на рис. 26). После нажатия кнопки «Сохранить» (элемент 5 на рис. 26) изменения сохраняются в базе данных.

Для формирования отчета о задержках ввода данных пользователю следует в меню «Отчеты» выбрать пункт «Контроль ввода данных», после чего появится вкладка «Отчет – контроль ввода данных». Внешний вид вкладки изображен на рис. 27.

Рис. 27. Вкладка «Отчет – контроль ввода данных»

Чтоб отчет сформировался необходимо указать набор сервисных предприятий (элемент 1 на рис. 27), в котором должны были внести данные, период (элемент 2 на рис. 27), за который задержки были зафиксированы, количество дней допустимых для задержки ввода данных (элемент 3 на рис. 27). После указания всех параметров отчет можно сформировать, нажав на кнопку «Сформировать».

  1.  Технико-эксплутационные характеристики

После проектирование, разработки и интеграции Подсистемы в ИС «ЭПОС», с целью тестирования Подсистема была запущена в эксплуатацию на предприятиях ООО «Юганскнефтегаз» без прекращения функционирования предыдущих способов работы сотрудников ОК. По предварительным результатам тестирования наблюдаются следующие эффекты в работе сотрудников объединения:

  1. время поиска событий для расследования сократилось до 1 минуты благодаря автоматическому оповещению пользователя о Событиях;
  2. время запроса коррекции и дополнения данных сократилось до 1 минуты благодаря возможности создавать и оправлять запросы в Подсистеме;
  3. время дополнения и коррекции данных сократилось до 4 часов благодаря наличию достаточных сведений в заявке;
  4. время до возобновления расследования после выполнения запроса сократилось до 1-4 минут благодаря автоматическому оповещению пользователя о Событиях.

Как видно из рис. 28 снижение затрат времени даже при пессимистичной оценке значительное. Время на поиск ответственных за ввод данных больше не требуется, так как запросы автоматически направляются лицам ответственным за ввод данных. Таким образом, суммарное время, затраченное от момента обнаружения некорректных или неполных данных по событиям до конца расследования, составляет 3-11 часов (1,53-5,61% от предыдущего значения).

Рис. 28. Снижение затрат времени

То есть задержку в работе сотрудников отдела качества удалось снизить на 94,39-98,47 % от предыдущего значения.

Заключение

В ходе данной дипломной работе:

  1. изучена предметная область;
  2. изучена ИС «ЭПОС»;
  3. проведен обзор существующих подсистем оповещений в различных ИС;
  4. разработано техническое задание на Подсистему;
  5. разработан контур Подсистемы;
  6. разработана инфологическая модель предметной области;
  7. разработана Подсистема;
  8. интегрирована Подсистема с ИС «ЭПОС».

В результате данной работы была спроектирована, разработана и внедрена подсистема оповещения в ИС «ЭПОС», тем самым цель работы достигнута. Подсистема обладает всеми требуемыми функциями для устранения недостатков в ИС «ЭПОС».

Подсистема в настоящее время работает в тестовом режиме на предприятиях ООО «Юганскнефтегаз». По предварительным данным наблюдается значительное сокращение задержек в работе отдела качества. По сравнению с предыдущими временными затратами, использование подсистемы оповещения дает значительную экономию времени.

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

Список использованных источников

  1. Байков Н. Перспективы российской нефтегазовой промышленности и альтернативных источников энергии // Мировая экономика и международные отношения. – 2008. - №6. – С.49-56.
  2. Научно-исследовательский Центр CALS – «Прикладная логистика» «МЕТОДОЛОГИЯ ФУНКЦИОНАЛЬНОГО МОДЕЛИРОВАНИЯ IDEF0». ГОССТАНДАРТ РОССИИ Москва РД IDEF 0 - 2000
  3. Нугаев Р. Я. «Безопасная эксплуатация нефтепромысловых объектов» - 1990 год
  4. Техническое задание на ИС «ЭПОС».
  5. Карпычев В. Ю. Методология IDEF1Х и программный продукт ERWin: Учебно-методическое пособие 2007 год
  6. Диго С. М. «Базы данных. Проектирование и создание» учебно-методический комплекс М.:ЕАОИ, 2008. – 171с.
  7. Кириллов В. В. ОСНОВЫ ПРОЕКТИРОВАНИЯ РЕЛЯЦИОННЫХ БАЗ ДАННЫХ – учебное пособие Санкт-Петербургский Государственный институт точной механики и оптики (технический университет) Кафедра вычислительной техники
  8. Роберт Д. Шнайдер Microsoft SQL Server Проектирование высокопроизводительных баз данных. Издательство «ЛОРИ», 1998
  9.  http://www.eos.ru/eos_products/eos_delo/opovesch.php - описание подсистемы оповещения и уведомления системы «Дело»
  10.  http://program-line.ru/produkt - описание конфигурации «Програм Лайн: Уведомления о событиях»
  11.  http://www.bssys.com/solutions/financial-institutions/dbo-bs-client-x64/online-statement/ - описание подсистемы «Выписка Он-лайн» в системе «ДБО BS-Client»
  12.  http://www.bssys.com/solutions/financial-institutions/spetsializirovannye-resheniya/server-notifikatsii/ - описание Сервера Нотификации
  13.  http://www.microsoft.com/ru-ru/download/details.aspx?id=21 – описание framework 3.5
  14.  http://technet.microsoft.com/ru-ru/library/ms175887(v=sql.105).aspx – описание компонента SQL Server – Database Mail

Приложение 1

Листинг класса EventNotifications

class EventNotifications

 {

  private static TimeSpan minRefreshPeriod = new TimeSpan(0, 1, 0);

  private UI.Main.FormMain formMain_;

  private string connectionString_;

  private string schema_;

  private int notificationsRefreshPeriod_;

  private DateTime nextRefreshTime_;

  private TimeSpan refreshPeriod_;

  private System.Windows.Forms.NotifyIcon notifyIcon_;

  System.Drawing.Icon[] icons_ = null;

  public IdleHandler_EventNotifications(

   UI.Main.FormMain formMain,

   string server,

   string sid,

   string schema,

   string user,

   string password)

  {

   formMain_ = formMain;

   {

    int indexOfColon = server.IndexOf(':');

    string optionalPort = ((indexOfColon >= 0) ? string.Format(@"Port={0};", server.Substring(indexOfColon + 1)) : "");

    connectionString_ = string.Format(

     "Server={0};Sid={1};User Id={2};Password={3};Pooling=False;Direct=True;{4}",

     ((indexOfColon >= 0) ? server.Substring(0, indexOfColon) : server),

     sid, user, password, optionalPort);

   }

   schema_ = schema;

   notificationsRefreshPeriod_ = 0;

   nextRefreshTime_ = DateTime.Now;

   notifyIcon_ = null;

   icons_ = null;

   if (formMain_ != null) formMain_.setRefreshEventNotifyIconDelegate(refreshNotifyIcon);

  }

  public bool onIdle()

  {

   if (formMain_ != null)

   {

    if (DateTime.Now >= nextRefreshTime_)

    {

     int notificationsRefreshPeriod = formMain_.eventNotificationsRefreshPeriod();

     if (notificationsRefreshPeriod_ != notificationsRefreshPeriod)

     {

      notificationsRefreshPeriod_ = notificationsRefreshPeriod;

      refreshPeriod_ = new TimeSpan(

       notificationsRefreshPeriod / 60,

       notificationsRefreshPeriod % 60,

       0);

      if (notifyIcon_ == null)

      {

       notifyIcon_ = new System.Windows.Forms.NotifyIcon();

       notifyIcon_.Text = @"ЭПОС: Оповещения о событиях";

      }

      if (icons_ == null)

      {

       icons_ = new System.Drawing.Icon[]

       {

        new System.Drawing.Icon("Resources/notify_round_00.ico"),

        new System.Drawing.Icon("Resources/notify_round_01.ico"),

        new System.Drawing.Icon("Resources/notify_round_02.ico"),

        new System.Drawing.Icon("Resources/notify_round_03.ico"),

        new System.Drawing.Icon("Resources/notify_round_04.ico"),

        new System.Drawing.Icon("Resources/notify_round_05.ico"),

        new System.Drawing.Icon("Resources/notify_round_06.ico"),

        new System.Drawing.Icon("Resources/notify_round_07.ico"),

        new System.Drawing.Icon("Resources/notify_round_08.ico"),

        new System.Drawing.Icon("Resources/notify_round_09.ico"),

        new System.Drawing.Icon("Resources/notify_round_10.ico"),

       };

      }

     }

     refreshNotifyIcon();

    }

    return true;

   }

   return false;

  }

Приложение 2

Листинг класса RequestNotifications

class RequestNotifications

 {

  

  private UI.Main.FormMain formMain_;

  private string connectionString_;

  private string schema_;

  private int notificationsRefreshPeriod_;

  private DateTime nextRefreshTime_;

  private TimeSpan refreshPeriod_;

  private System.Windows.Forms.NotifyIcon notifyIcon_;

  System.Drawing.Icon[] icons_ = null;

  public IdleHandler_RequestNotifications(

   UI.Main.FormMain formMain,

   string server,

   string sid,

   string schema,

   string user,

   string password)

  {

   formMain_ = formMain;

   {

    int indexOfColon = server.IndexOf(':');

    string optionalPort = ((indexOfColon >= 0) ? string.Format(@"Port={0};", server.Substring(indexOfColon + 1)) : "");

    connectionString_ = string.Format(

     "Server={0};Sid={1};User Id={2};Password={3};Pooling=False;Direct=True;{4}",

     ((indexOfColon >= 0) ? server.Substring(0, indexOfColon) : server),

     sid, user, password, optionalPort);

   }

   schema_ = schema;

   notificationsRefreshPeriod_ = 0;

   nextRefreshTime_ = DateTime.Now;

   notifyIcon_ = null;

   icons_ = null;

   if (formMain_ != null) formMain_.setRefreshRequestNotifyIconDelegate(refreshNotifyIcon);

  }

  public bool onIdle()

  {

   if (formMain_ != null)

   {

    if (DateTime.Now >= nextRefreshTime_)

    {

     int notificationsRefreshPeriod = formMain_.requestNotificationsRefreshPeriod();

     if (notificationsRefreshPeriod_ != notificationsRefreshPeriod)

     {

      notificationsRefreshPeriod_ = notificationsRefreshPeriod;

      

      if (notifyIcon_ == null)

      {

       notifyIcon_ = new System.Windows.Forms.NotifyIcon();

       notifyIcon_.Text = @"ЭПОС: Оповещения о запросах";

      }

      if (icons_ == null)

      {

       icons_ = new System.Drawing.Icon[]

       {

        new System.Drawing.Icon("Resources/notify_square_00.ico"),

        new System.Drawing.Icon("Resources/notify_square_01.ico"),

        new System.Drawing.Icon("Resources/notify_square_02.ico"),

        new System.Drawing.Icon("Resources/notify_square_03.ico"),

        new System.Drawing.Icon("Resources/notify_square_04.ico"),

        new System.Drawing.Icon("Resources/notify_square_05.ico"),

        new System.Drawing.Icon("Resources/notify_square_06.ico"),

        new System.Drawing.Icon("Resources/notify_square_07.ico"),

        new System.Drawing.Icon("Resources/notify_square_08.ico"),

        new System.Drawing.Icon("Resources/notify_square_09.ico"),

        new System.Drawing.Icon("Resources/notify_square_10.ico"),

       };

      }

      refreshNotifyIcon();

     }

    }

    return true;

   }

   return false;

  }

  private bool refreshData(ref int requestsCount)

  {

   bool isDataRefreshed = false;

   using (Devart.Data.Oracle.OracleConnection connection = new Devart.Data.Oracle.OracleConnection(connectionString_))

   {

    connection.Open();

    isDataRefreshed = refreshData(connection, ref requestsCount);

    connection.Close();

   }

   return isDataRefreshed;

  }

  private bool refreshData(Devart.Data.Oracle.OracleConnection connection, ref int requestsCount)

  {

   bool isDataRefreshed = false;

   using (Devart.Data.Oracle.OracleCommand oracleCommand = new Devart.Data.Oracle.OracleCommand(schema_ + ".notification.get_data_requests_count", connection))

   {

    oracleCommand.CommandType = System.Data.CommandType.StoredProcedure;

    try

    {

     oracleCommand.Parameters.Add(new Devart.Data.Oracle.OracleParameter("CNT", Devart.Data.Oracle.OracleDbType.Number, System.Data.ParameterDirection.Output));

     oracleCommand.ExecuteNonQuery();

     object objRequestsCount = oracleCommand.Parameters[0].Value;

     if ((objRequestsCount != null) && !(objRequestsCount is DBNull))

      requestsCount = Convert.ToInt32(objRequestsCount);

     isDataRefreshed = true;

    }

    catch (Devart.Data.Oracle.OracleException ex)

    {

     if (ex.Code != 4068)

     {

      System.Windows.Forms.MessageBox.Show(Sys.Utils.textOracleUserExc(ex), "Ошибка",

       System.Windows.Forms.MessageBoxButtons.OK,

       System.Windows.Forms.MessageBoxIcon.Exclamation);

      if (ex.Code == 6550)       {

       requestsCount = 0;        isDataRefreshed = true;

      }

     }

    }

   }

   return isDataRefreshed;

  }

  public void refreshNotifyIcon()

  {

   int requestsCount = 0;

   Devart.Data.Oracle.OracleConnection connection = Sys.DB.DBManager.getConnection();

   bool isDataRefreshed = ((connection != null) && refreshData(connection, ref requestsCount));

   if (!isDataRefreshed) isDataRefreshed = refreshData(ref requestsCount);

   if (isDataRefreshed)

   {

    if ((refreshPeriod_ == null) || (refreshPeriod_ < minRefreshPeriod))

     

    if (notifyIcon_ != null)

    {

     bool showNotifyIcon = ((notificationsRefreshPeriod_ > 0) && (refreshPeriod_ != null));

     if (notifyIcon_.Visible != showNotifyIcon) notifyIcon_.Visible = showNotifyIcon;

     if (showNotifyIcon)

     {

      if ((icons_ != null) && (icons_.Length > 0))

      {

       System.Drawing.Icon icon = icons_[Math.Min(requestsCount, icons_.Length - 1)];

       if ((icon != null) && (icon != notifyIcon_.Icon)) notifyIcon_.Icon = icon;

      }

     }

    }

   }

  }

  public void hide()

  {

   if ((notifyIcon_ != null) && notifyIcon_.Visible) notifyIcon_.Visible = false;

  }

 }