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

Дипломная работа

«подсистемы оповещения для ИС ЭПОС»

 

Выполнил: Волков А.Д.

студент гр. 1192

 

Научный руководитель: Гавриленко Т.В.

доцент

 

Рецензент:

 

 

Сургут 2014

Реферат

стр. 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

Введение

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

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

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

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

· недостаточный контроль за своевременный ввод данных;

· отсутствие возможности создания запросов на коррекцию и дополнение данных;

· отсутствие оповещения о вводе данных по Событиям.

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

· оповещение пользователя о несвоевременном вводе данных;

· оповещение пользователя о Событиях;

· формирование запросов на коррекцию и дополнение данных;

· оповещение пользователя о некорректных и неполных данных.

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

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

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

· технические характеристики оборудования;

· параметры эксплуатации;

· результаты ремонта;

· наличие и движение оборудования.

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

· анализа эксплуатации и ремонта;

· отслеживания жизненного цикла оборудования;

· формирования отчетов в различных срезах;

· расследования причин отказов оборудования;

· подконтрольной эксплуатации;

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

· проведения анализа эксплуатации оборудования;

· формирования рейтингов;

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

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

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

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

· подсистема связи с СУБД;

· модуль кэширования;

· подсистема формирования отчетов;

· подсистема управления конфигурациями;

· подсистема ввода и редактирования данных;

· подсистема безопасности;

· пользовательский интерфейс.

 

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

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

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

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

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

 

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

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

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

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

Вывод

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

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

Таблица 1

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

	«Дело»	Програм Лайн	Выписка Он-лайн
Оповещение по Событиям	В области уведомлении Windows	Через Email	Через клиентское приложение, SMS, Email, Web-сайт
Оповещение о заявках	В области уведомлении Windows	Через Email	Нет
Оповещение о задержках	В области уведомлении Windows	Через Email	Нет

 

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

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

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

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

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

· отсутствие возможности отслеживать факты задержек ввода данных по операциям;

· отсутствие возможности создавать и отправлять запросы на дополнение и коррекцию данных;

· отсутствие оповещения пользователя по Событиям.

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

· изучить предметную область;

· изучить ИС «ЭПОС»;

· провести обзор существующих подсистем оповещений в различных ИС;

· разработать техническое задание на Подсистему;

· разработать контур Подсистемы;

· разработать инфологическую модель предметной области;

· разработать Подсистему;

· интегрировать Подсистему с ИС «ЭПОС».

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

· оповещение пользователя о новых Событиях;

· создание и отправка запроса на коррекцию и дополнение данных;

· оповещение пользователя о новых запросах на коррекцию и дополнение данных;

· оповещение пользователя о задержках ввода данных.

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

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

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

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

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

· оповещение пользователя о Событиях;

· оповещение пользователя о запросах на коррекцию и дополнение данных;

· возможность оформлять и отправлять запросы на коррекцию и дополнение данных;

· возможность оформлять подписки на оповещения;

· оповещение пользователя о задержках ввода данных.

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

 

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

· модуль формирования подписки – оформляет подписки на события по выбранному перечню оборудования;

· модуль формирования заявок пользователю СП – оформляет заявки на дополнение и коррекцию данных, необходимых для расследования отказов оборудования. Заявки отправляются на хранение в базу данных до востребования модулем опроса базы данных со стороны пользователя сервисного предприятия;

· модуль опроса базы данных – с определенным промежутком времени обращается к базе данных за данными для оповещений пользователя;

· модуль оперативного оповещения – активирует графические средства оповещения в пользовательском интерфейсе.

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

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

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

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

· пользовательский интерфейс – добавить формы для формирования подписок и заявок, графические элементы сигнализирования и графические окна просмотра оповещений;

· подсистему связи с СУБД – добавить дополнительные модули для связи подсистемы оповещения и СУБД;

· API СУБД – добавить дополнительные функции внесения данных по оповещения их извлечения и модификации;

· базу данных – дополнить таблицами для сущностей связанных с оповещением.

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

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

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

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

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

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

После нормализации инфологической модели предметной области была получена логическая инфологическая модель Подсистемы. Логическая инфологическая модель представлена на рис. 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

 

2. 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 (<Текущей даты)

 

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

Таблица 4

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

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

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

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

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

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

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

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

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

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

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

В данном подразделе описаны изменения, которые необходимо внести в подсистему связи с СУБД и 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.

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

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

· DataSet_DelayNotifications – оповещение по задержкам ввода данных;

· DataSet_EventNotifications – оповещение по событиям;

· DataSet_EventNotifications_Lists – список личных групп подконтрольных скважин;

· DataSet_EventNotifications_SharedLists – список общих групп скважин;

· DataSet_RequestResponce_List – оповещение о запросах на коррекцию и дополнение данных;

· DataSet_OPR_Stop – создание запроса на коррекцию и дополнение данных.

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

Таблица 8

API СУБД

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

· get_input_monitoring_prefs – вызов параметров для контроля за задержкой ввода данных;

· get_active_lists_wells – запрос данных для оповещения по Событиям;

· get_events – запрос данных по событию, выбранной скважины;

· get_data_request_attr – получение данных по запросу;

· del_lists_wells – удаление группы из подписки;

· del_lists_wells_set – удаление скважины из группы подписки;

· upd_lists_wells – обновление значений параметров подписки на События;

· get_data_request – формирование заявок на коррекцию и дополнение данных;

· add_data_request – добавление заявок на коррекцию и дополнение данных;

· add_lists_wells – добавление группы скважин;

· add_lists_wells_set – добавление скважины в группу подписок;

· update_data_requests_state – обновление статуса запроса;

· upd_lists_wells_set_note – обновление параметров скважин в подписке;

· upd_active_events_status – обновление статуса оповещения по Событиям;

· get_request_receivers – получение списка запросов;

· rem_data_request – удаление запроса;

· get_lists_wells – запрос данных по подписке;

· copy_lists_wells – копирование общую группу в список личных групп;

· set_input_monitoring_prefs – обновление параметров для настройки подписки на оповещение по задержкам ввода данных;

· get_data_requests_count – возвращает количество необработанных запросов;

· 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_