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

Размещено на http://www.allbest.ru/

Аннотация

Тема дипломной работы: «Разработка информационной системы поддержки принятия решений оператором при управлении транспортировкой газа»

Выполнил студент: Артюшин Дмитрий Юрьевич

Год защиты: 2015

Руководитель доцент: Стычук А.А

В данной дипломной работе представлена реализация информационной системы поддержки принятия решения оператором при управлении транспортировкой газа предприятием ОАО «Газпромрегионгаз» Данная информационная система направлена на повышение эффективности и оперативности принимаемых решений в процессе управления.

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

Введение

транспортировка газопровод магистраль

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

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

Одной из тех сфер, предприятия которых особенно нуждаются в автоматизации процессов их работы, является промышленность. Это объясняется, во-первых, слабым уровнем развития промышленности в целом по России, и, во-вторых, высоким уровнем конкуренции со стороны западных производителей в этой сфере.

Одной из таких организаций является ОАО «Газпромрегионгаз», которая осуществляет транспортировку газа среднего давления по городу Орлу и Орловской области.

Целью данной дипломной работы является повышение эффективности и оперативности принимаемых решений оператором в процессе управления транспортировкой газового потока на предприятии ОАО «Газпромрегионгаз».

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

- рассмотрены особенности функционирования предприятия по способу управления транспортировкой газа;

- провести моделирование ППО;

- разработана структура базы данных для хранения информации;

- осуществлено проектирование приложения;

- проведена оценка экономической эффективности информационной системы;

- проведены мероприятия по обеспечению БЖД.

1. Анализ принципов функционирования предприятия ОАО «Газпромрегионгаз»

1.1 Общая характеристика предприятия ОАО «Газпромрегионгаз»

Очередной филиал в городе ОРЛЕ был открыт компанией ОАО «Газпромрегионгаз» в сентябре 2005 года. Предприятие было создано для обслуживания газопроводов по Орлу и транспортировки газа через Орловскую область. Численность предприятия ОАО «Газпромрегионгаз» с филиалами районных служб Орловской области составляет 450 человек.

Предприятие расположено в г. Орел, ул. Монтажная, дом № 14 А.

Площадь предприятия составляет 500 м² на территории предприятия находится 3 здания, головное здание в два этажа площадью 150 м² .

Общая численность работников предприятия составляет 120 человек, в том числе:

- ИТР и служащие - 90 чел;

- рабочие - 20 чел;

По специальностям:

- прочие специальности - 10 (электрики, грузчики, водители, охрана).

Сети филиалов объединяются с сетью офиса ОАО «Газпромрегионгаз» через VPN - туннели, таким образом, что ресурсы сетей филиалов доступны напрямую. VPN - туннели находятся между маршрутизаторами головного офиса, ОАО «Газпромрегионгаз» и филиалами.

Данное предприятие занимается обслуживанием газопровода по Орловской области. В ведомстве ОАО «Газпромрегионгаз» находятся 8 перекачивающих станций, десятки пропускных станций, сотни километров газопровода, за всем этим следят ЭВМ, которыми управляет персонал ОАО «Газпромрегионгаз». Одной из важнейшей задачи этого предприятия, является обеспечение безопасности транспортировки газа высокого и малого давления. На газовых магистралях находится большое число датчиков, которые собирают информацию и передают в диспетчерскую где они обрабатываются, анализируются и принимается решение, какое действие нужно предпринять, что бы избежать той или иной проблемной, конфликтной ситуации. За этой работой следит диспетчер, который занимается анализом поступающих сигналов, и от его умения, знания, опыта, зависит принятие правильного решения.

1.2 Описание организации деятельности ОАО «Газпромрегионгаз»

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

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

Главной статьей дохода ОАО «Газпромрегионгаз» является транспортировка газа внутри России, данное предприятие обслуживает город Орел и Орловскую область. Основная задача предприятия это:

- эксплуатация газовых сетей;

- оказание Информационно-консультативных услуг;

- строительство объектов газоснабжения в населенных пунктах;

- доставка газа конечному потребителю.

1.3 Постановка задачи информационной системы поддержки принятия решения оператором

Процесс принятия решения на предприятии ОАО «Газпромрегионгаз» является довольно сложным. Поэтому очень важно быстро, а главное, правильно принимать различные управленческие решения. Разрабатываемая информационная система позволит значительно повысить эффективность и оперативность принятия решений в процессе управления транспортировки газа.

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

1.3.1 Функциональные требования к информационной системе

К основным функциональным требованиям можно отнести:

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

– контроль за выполнением технологических операций;

– управление структурой производства и операциями на оборудовании;

– формирование отчетов по процессу управления в виде графиков и диаграмм.

1.3.2 Нефункциональные требования к информационной системе поддержки принятия решения

К нефункциональным требованиям можно отнести:

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

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

– информационная система должна обеспечивать целостность собираемой, анализируемой, а также дополнительной (служебной) информации;

– информационная система должна работать под управлением различных операционных систем как семейства Unix, так и Windows;

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

1.4 Анализ существующих разработок поддержки принятия решения

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

Однако при использовании «традиционной» системы телемеханики и диспетчерского управления (SCADA-системы задачу анализа ситуации и принятия решений выполняет человек-диспетчер. В условиях необходимости принятия ответственных решений в ограниченные сроки (особенно при локализации аварий) и на основе анализа многокритериальных данных нагрузка на диспетчера существенно возрастает. Задача принятия решений усложняется при необходимости анализа технологического объекта сложной структур, например, закольцованной трубопроводной системы перемычками и различными вариантами потоков газа.

SCADA (аббр. от англ. Supervisory Control And Data Acquisition, Диспетчерское управление и сбор данных) -- данное понятие обычно применяется к системе управления в промышленности: система контроля и управления процессом с применением ЭВМ. Процесс может быть технологическим, инфраструктурным или обслуживающим:

1) Технологические процессы включают -- производство, выработку энергии, конструирование, переработка. Может протекать в непрерывном, пакетном, периодическом или дискретном режимах.

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

3) Процессы в сфере обслуживания имеют как частную так и общественную стороны -- здания, аэропорты, корабли и космические станции. Они контролируют и управляют HVAC, доступом и потреблением энергии.

Основными компонентами системы SCADA являются следующие подсистемы:

1) Человеко-машинный интерфейс (HMI, англ. Human Machine Interface) -- инструмент, который представляет данные о ходе процесса человеку оператору, что позволяет оператору контролировать процесс и управлять им.

2) Диспетчерская система -- собирает данные о процессе и отправляет команды процессу (управление).

3) Абонентский оконечный блок, либо УСО (RTU, англ. Remote Terminal Unit), подсоединяемый к датчикам процесса. Преобразует сигнал с датчика в цифровой код и отправляет данные в диспетчерскую систему.

4) Коммуникационная инфраструктура для реализации промышленной сети.

SCADA-системы решают ряд задач:

1) Обмен данными с УСО (устройства связи с объектом, то есть с промышленными контроллерами и платами ввода/вывода) в реальном времени через драйверы.

2) Обработка информации в реальном времени.

3) Отображение информации на экране монитора в удобной и понятной для человека форме.

4) Ведение базы данных реального времени с технологической информацией.

5) Аварийная сигнализация и управление тревожными сообщениями.

6) Подготовка и генерирование отчетов о ходе технологического процесса.

7) Осуществление сетевого взаимодействия между SCADA ПК.

8) Обеспечение связи с внешними приложениями (СУБД, электронные таблицы, текстовые процессоры и т. д.).

SCADA-системы позволяют разрабатывать АСУ ТП в клиент-серверной или в распределенной архитектуре.

Иногда SCADA-системы комплектуются дополнительным ПО для программирования промышленных контроллеров. Такие SCADA-системы называются интегрированными и к ним добавляют термин SoftLogіс.

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

Исходя из вышесказанного, особую роль приобретает автоматизация информационной поддержки принятия решений в области управления газопроводами, газовыми промыслами и другими распределенными объектами. Системы, решающие подобные задачи, не должны быть навсегда, - они должны динамично развиваться, адаптироваться запрограммированы жестко, раз и к новым, изменяющимся условиям, гибко и оперативно перестраивать алгоритмы функционирования. Фактически речь идёт о реализации элементов искусственного интеллекта в диспетчерском управлении. Для обозначения подобного расширения телемеханики и диспетчерской системы можно использовать термин СППР - система поддержки принятия решений. СППР представляет собой компьютерную программу (точнее, сложный программный комплекс), которая работает параллельно SCADA-системе пункта управления промыслом или газопроводом.

Задачами СППР являются:

- помощь диспетчеру в анализе текущего режима работы объекта;

- автоматизации идентификации аварийных ситуаций и выдача диспетчеру рекомендаций по их локализации и устранению при максимальном сохранении работоспособности газотранспортной системы или другого технологического объекта в целом.

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

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

- давление на входе в ГРП;

- контроль выходного давления;

- перепад на фильтре;

- t- газа на входе в ГПР;

- давление в трубе;

- температура в помещении;

- датчик проникновения «Свой - Чужой»;

- датчик утечки газа.

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

В составе СППР являются входит ряд модулей.

База данных Подсистемы глубокого архива (ПГА), реализованная средствами СУБД InterBase. Подсистема глубокого архива предназначена для обеспечения информационных обменов между разнородными источниками и потребителями информации СППР, и представления входных и выходных данных СППР в удобном для обработки и визуализации виде;

Рисунок 1 - Общая структура системы телеметрии.

База знаний СППР (СУБД InterBase). В базе знаний хранятся заранее разработанные рекомендации по действиям диспетчера в различных аварийных ситуациях;

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

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

Для выполнения своих функций, СППР взаимодействует с различными информационными системами.

Входными данными для СППР являются:

- данные реального времени от Системы телемеханики Межпромыслового коллектора: давления газа в точках замера, положение телемеханизированных кранов, информация о месте и времени обнаружения волн давления (13 контролируемых пунктов телемеханики);

- данные ручного ввода от Диспетчерского пункта СТМ МПК - положение нетелемеханизированных кранов. Как отмечалось выше, в настоящий момент объем телемеханизации составляет около 30%. Однако в базе данных реального времени присутствуют все краны коллектора. Состояние нетелемеханизированных кранов вводится диспетчером ЛПУ вручную по результатам мониторинга коллектора службой ЛЭС;

- данные реального времени от информационно-справочной системы диспетчерского управления (ИС ДУ) установками комплексной подготовки газа (УКПГ);

- режим работы газоперекачивающих агрегатов (ГПА), положение запорной арматуры Узлов замера газа(УЗГ), давление, температура, расход газа, данные ручного ввода по сторонним поставщикам газа в коллектор. Данные вводятся диспетчером с 2-часовой или суточной периодичностью;

- нормативно-справочная информация (НСИ) о топологии МПК, геометрии участков коллектора, типах и параметрах ГПА на УКПГ. НСИ используется для построения математической модели коллектора;

- «база знаний» - заранее подготовленный набор инструкций по действиям диспетчера в различных нештатных ситуациях, в зависимости от текущего режима работы МПК. В инструкциях учитываются знания о всех возможных режимах работы МПК на данный момент, и предыдущий опыт действий персонала в аналогичных ситуациях.

Схема входных информационных потоков СППР приведена на Рисунке 2.

Рисунок 2 - Схема информационных потоков СППР

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

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

1.5 Организационная структура предприятия ОАО «Газпромрегионгаз»

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

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

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

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

каковы основные функции, выполняемые ИТ-службой?

кто или что является объектом выполняемых работ?



Размещено на http://www.allbest.ru/

Рисунок 3 - Организационная структура предприятия

откуда собираются данные о проделанной работе?

кто ответственный за сбор и предоставление отчетов?

каким образом производиться сбор данных для статистических отчетов по работе с базой данных?

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

На процессы, протекающие в ИТ-службе, выделим следующие точки зрения:

главный инженер;

диспетчер;

сотрудник ИТ - отдела.

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

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

Для рассматриваемой предметной области было принято решение построить модель - модель «to-be» («как будет»).

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

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

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

Построим контекстную диаграмму (рисунок 4).

Контекстная диаграмма представляет основную функцию ИТ-службы ОАО «Газпромрегионгаз» - организация проведения операций по поддержки принятия решений.

Информация о присутствующих на контекстной диаграмме стрелках сведена в таблицу 1.

Для более детального рассмотрения процессов предметной области необходимо провести декомпозицию контекстной диаграммы. Полученная таким образом диаграмма представлена на рисунке 5. В результате декомпозиции было выделено 2 активности:

«Этап настройки системы»;

«Этап выбора решений».

В первую очередь, на основании данных для настройки системы (активность «Этап настройки системы»). Именно на основе данных для настройки будут осуществляться все дальнейшие этапы процесса производства.



Таблица 1 - Описание стрелок контекстной диаграммы

Название	Описание	Тип
Информация о ситуации	Информация о ситуации в конкретный момент времени	Входная
Данные для настройки системы		Входная
Нормативы организации	Различные приказы, предписания, постановления	Управляющая
Методы теории систем	Различные приказы, распоряжения, постановления и правила, касающиеся деятельности подразделения	Управляющая
Набор предлагаемых решений	Сабор предлагемых решений для принятия правильного решения оператором	Выходная
Операторы	Сотрудники подразделения ОАО «Газпромрегионгаз»	Механизм
ЭВМ	Электронно-вычислительная машина	Механизм

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



Теперь перейдем к декомпозиции активности «Этап настройки системы» (рисунок 6), которая нас и будет интересовать для автоматизации. Так как данная активность разбивается на три активности:

«Анализ проблемы»;

«Формулирование целей и задач»;

«Определение критериев».

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

На последнем этапе осуществляется определение критериев. Это делается для получения фактов и правил для правильного принятия решения.

Декомпозиция блока «Определение критериев» представлена на рисунке 7.

На ней имеются следующие активности:

«Ввод пользователем данных для форматирования правила»;

«Проверка данных введенных пользователем»;

«Сохранение правил в базе знаний».

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



Декомпозиция блока «Этап выбора решений» представлена на рисунке 8. Этап выбора решений включат в себя 3 наиболее важных стадии:

«Формирование множества альтернатив»;

«Анализ альтернатив»;

«Формирование управляющих воздействий».

На первом шаге происходит формирование множества вариантов решения данной проблемы, активность «Формирование множества альтернатив», на следующем этапе активности мы производим анализ сформированных альтернатив, выбираем наиболее подходящий вариант принятия решения, активность «Анализ альтернатив». Далее на основе выбранного варианта производим формирование управляющего воздействия оказываемого на систему, которое отражено активностью «Формирование управляющих воздействий».

Произведем, декомпозицию блока «Формулирование множества альтернатив» которая представлена на рисунке 9.

На ней имеются следующие активности:

- «Определить тип ситуации»;

- «Определить возможные альтернативы».

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

Декомпозиция блока «Анализ альтернатив» представлена на рисунке 10

На ней имеются следующие активности:

- «Определить критерии для данных параметров»;

- «Извлечь из базы данных электронные значения параметров»;

- «Сформировать список альтернатив удовлетворяющих критериям»



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

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

2. Разработка информационной системы поддержки принятия решений оператором при управлении транспортировкой газа

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

2.1 Концептуализация предметной области

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

- «Пользователь» - информация о пользователе входящим в систему;

- «Режим» - выбор режима, в котором пользователь входит в систему;

- «История» - история произошедших событий в системе;

- «Правило» - правило, используемое в системе;

- «Мероприятие» - реакция на возникшую ситуацию;

- «Условие» - часть правила входящее в условие;

- «Параметр» - набор критериев используемых в системе;

- «Знак» - математическое значение (>,<,=>,<=,=).



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

Таблица 2 - Атрибуты сущностей и их взаимосвязь с моделью ППО

Сущность	Атрибут	Описание	Тип
1	2	3	4
Пользователь	логин	вводимый логин	Текстовый
	пароль	вводимый пароль	Текстовый
	режим администратора	вход в систему в режие администратор	Целое
	режим аналитика	вход в систему в режима аналитик	Целое
	режим диспетчера	вход в систему в режиме диспетчер	Целое
Режим	номер режима	суррогатный ключ, задающий режим	Целое
	имя режима	название режима	Текстовый
История	дата и время	момент времени в который происходит событие	Дата и время
	номер правила	правило которое сработало	Целое
	номер меры	номер меры принятой в отвер на событие	Целое
	номер режима	в каком режиме находился пользователь в момент возникновения события	Целое
	логин	имя пользователя	Текстовый
	описание события	комментарий к событию	Текстовый
Правило	номер правила	идентификационный номер правила	Целое
	имя правила	имя применяемого правила	Текстовый
Мероприятие	номер меры	суррогатный ключ, задающий мероприятие	Целое
	описание меры	текстовое описание мероприятия	Текстовый
Условие	номер условия	идентификационный номер условия	Целое
	номер порогового значения	суррогатный ключ, задающий номер порогового значения	Целое
	номер знака	идентификационный номер знака	Целое
	номер параметра	идентификацинный номер параметра	Целое
Пороговое значение	номер порогового значения	суррогатный ключ, задающий номер порогового значения	Целое
	пороговое значение	максимально допустимое значение	Целое
Знак	номер знака	идентификационный номер знака	Целое
	значение	имя значения	Текстовый
Параметр	номер параметра	идентификациооный номер параметра	Целое
	название параметра	имя параметра	Текстовый

2.2 Определение ограничений целостности

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

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

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

Таблица 3 - Ограничения на значения атрибутов

Сущность	Атрибут	Допустимые значения	Примечания
Знак	Номер знака	[0..4]	Всего может быть только пять состояний
Режим	Номер режима	[0..2]	Всего может быть только три режима

На атрибуты «Название параметра» и «Номер параметра» сущности «Параметр» также накладываются ограничения, но значения этого атрибута не заносятся пользователем, а присутствуют в БД с момента ее генерации.

Атрибут «Название параметра» может принимать следующие значения:

- «Давление на входе»;

- «Давление среднее»;

- «Давление на фильтре 1»;

- «Давление низкое»;

- «Перепад на фильтре 2»;

- «Газ, %».

Перейдем к обоснованию выбора стратегий ограничения целостности БД для идентифицирующих и неидентифицирующих связей.

Стратегии ограничения целостности приведем в таблице 4.

Таблица 4 - Основные стратегии ограничения целостности БД для связей и категорий

Действие	Идентифицирующая связь	Неидентифицирующая связь
Вставка родителя	---	---
Вставка потомка	Запрещающая	Запрещающая
Изменение родителя	Запрещающая	Каскадная
Изменение потомка	Запрещающая	Запрещающая
Удаление родителя	Каскадная	Запрещающая
Удаление потомка	---	---

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

Так, например, для связей «Документ-Подразделение», «Документ-Компьютерная_техника» на изменение родителя установлена запрещающая стратегия.

Таблица 5 - Неосновные стратегии ограничения целостности БД для идентифицирующих и неидентифицирующих связей

Действие	Идентифицирующая связь	Неидентифицирующая связь
Изменение родителя	Каскадная	Запрещающая
Удаление родителя	Запрещающая	Каскадная

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

Для связей «Условие-Правило», «Правило-Мероприятие» установлена запрещающая стратегия на удаление. В первом случае такую стратегию можно объяснить следующим образом: невозможно удалить условие, если оно содержится в любом правиле, не удалив предварительно это правило. В другом случае - невозможно удалить мероприятие, не отменив его для соответствующего правила.

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

Часть проверок на корректность перенесена на уровень пользовательского приложения. При концептуальном проектировании схемы БД, на значения ряда атрибутов были наложены дополнительные ограничения целостности. Ограничения на значения других атрибутов реализуем при помощи предложения CHECK и включим в состав описания полей таблиц БД при проектировании ее структуры. Так в таблице «Условие» на поле «Номер параметра» наложено следующиее ограничение:

CHECK (Номер параметра >=0 AND Номер параметра <=6).

Стратегии ограничения целостности БД для идентифицирующих и неидентифицирующих связей реализованы при помощи триггеров. СУБД InterBase по умолчанию поддерживает запрещающую стратегию ограничения целостности на удаление и изменение родителя, а также вставку ребенка. Поэтому такие стратегии не нуждаются в построении дополнительных триггеров. Однако все остальные стратегии нуждаются в построении соответствующих триггеров. CASE-средство ERWin генерирует стандартные тексты триггеров для реализации каскадных изменений, которыми мы и воспользуемся. С помощью триггеров мы реализуем дополнительные ограничения на значения полей проектируемой БД. Это применимо в следующих случаях:

- при генерации первичного ключа;

- при вставке текущего пользователя системы в БД;

- при добавлении текущей даты;

- при каскадной вставке записей.

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

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

CREATE TRIGGER сур_ключ FOR таблица

BEFORE INSERT

AS

Begin

New.идентификатор = gen_id(генератор, 1)

End

Для работы такой конструкции сначала требуется создать генератор с именем «генератор»:

CREATE GENERATOR генератор

Затем нужно присвоить ему первоначальное значение:

SET GENERATOR генератор TO 1.

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

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

2.3 Выбор целевой СУБД

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

- поддержка реляционной модели баз данных;

- поддержка стандарта SQL (Structured Query Language);

- достаточное быстродействие;

- достаточная надежность.

Вышеперечисленным требованиям в полной мере отвечает система InterBase 6.5: Client and Server. Кроме того, данная система обладает рядом других достоинств:

поддержка архитектуры «Клиент/Сервер»;

наличие средств оптимизации производительности сервера (настройки, статистика);

автоматическая оптимизация запросов;

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

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

Выбор СУБД InterBase 6.5: Client and Server в качестве средства реализации базы данных повлек за собой необходимость адаптации к ней концептуальной схемы. Кроме того, в соответствие с типами, определенными для атрибутов в процессе логического проектирования, из всех типов, поддерживаемых СУБД InterBase 6.5: Client and Server, для целочисленных атрибутов были выбраны типы «integer», а для атрибутов символьных типов - тип «varchar» с указанием максимального числа символов в строке.

В результате проведенных работ была построена физическая модель данных, ориентированная на работу под управлением СУБД Interbase 6.5 (приложение А).

2.4 Алгоритмы работы системы

Опишем основные алгоритмы, реализованные в системе. На рисунке 12 изображена схема алгоритма действий диспетчера. В ходе выполнения осуществляется взаимодействие с базой данных. «Запрос 1» представляет собой SQL запрос SELECT с определёнными условиями для сущностей «Условие-Правило», «Условие», «Правило», «Пороговое значение».

На рисунке 13 изображена схема алгоритма добавления нового пользователя. В ходе выполнения осуществляется взаимодействие с базой данных. «Запрос 1» представляет собой SQL запрос UPDATE с определенными условиями для сущности «Пользователь».

Рисунок 13 - Схема алгоритма добавления нового пользователя



Рисунок 12 -Схема алгоритма действий диспетчера

На рисунке 14 изображена схема алгоритма изменения данных пользователя. В ходе выполнения осуществляется взаимодействие с базой данных. «Запрос 1» представляет собой SQL запрос UPDATE с определенными условиями для сущности «Пользователь».

Рисунок 14 - Схема алгоритма изменения данных пользователя

На рисунке 15 изображена схема удаления существующего пользователя, В ходе выполнения осуществляется взаимодействие с базой данных. «Запрос 1» представляет собой SQL запрос DELETE с определенными условиями для сущности «Пользователь».



Рисунок 15 - Схема удаления существующего пользователя

На рисунке 16 изображена схема работы алгоритма добавление нового условия. В ходе выполнения осуществляется взаимодействие с базой данных. «Запрос 1» представляет собой SQL запрос INSER с определенными данными для сущности «Условие».

Рисунок 16 - Схема добавления нового условия

На рисунке 17 изображена схема удаления выбранного правила. В ходе выполнения осуществляется взаимодействие с базой данных. «Запрос 1» представляет собой SQL запрос DELETE с определенными данными для сущности «Правило».

Рисунок 17 - Схема удаления выбранного правила

2.5 Проектирование пользовательского интерфейса

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

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

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

Рисунок 18 - Транзитивная сеть, описывающая логику диалога системы с пользователем

Если произошел ввод идентификатора диспетчер, то система переходит в режим подсети диспетчер, Логика диалога диспетчера с программой отражена на рисунке 19.

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



Рисунок 19 - Транзитивная сеть, описывающая логику диалога системы с диспетчером

Если был осуществлен вход под идентификатором администратор, то логика диалога будет следующая (рисунок 20)

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



Рисунок 20 - Транзитивная сеть, описывающая логику диалога системы с администратором

Если произошел вход в систему под идентификатором аналитик, то транзитивная сеть, описывающая логику диалога, будет представлена на следующем рисунке 21

Здесь описаны переходы на окно ввода имени нового правила, удаление существующего правила и на окно конструктора нового правила, выход из подсети и переход на форму регистрации.



Рисунок 21 - Транзитивная сеть, описывающая логику диалога системы с аналитиком.

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

Таблица 6 - Описание состояний транзитивной сети

Состояние	Описание
1	2
S0	Стартовое состояние, пользователь вводит логин и пароль. Режим работы
F0	Конец. Финальное состояние. Завершаем работу программы
SD	Открыта основная форма - Диспетчер
SD1	Отображена вкладка - История событий
SD2	Открыто окно Word, в котором отображена история событий
FD	Выход из системы, закрытие сеанса - Диспетчер
Sadm	Открыта основная форма - Администратор
Sadm1	Отображена форма редактирования учетных записей
Sadm2	Отображено модальное окно ввода нового пароля
Sadm3	Отображено модальное окно подтверждения удаления пользователя
Sadm4	Отображено модальное окно добавления нового пользователя
SA	Открыта основная форма - Аналитик
SA1	Окно ввода имени для объединенного правила
FA	Выход из системы, закрытие сеанса - Аналитик
Fadm	Выход из подсети - Администратор
SA2	Отображение окна подтверждения удаления правила
SA3	Окно - Конструктор нового правила

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

Таблица 7 - Описание переходов транзитивной сети

№ дуги	Входной сигнал	Реакция на входной сигнал
1	2	3
1	Нажата кнопка "Вход"	Отказ от входа в систему, предложение ввести логин и пароль и режим работы
2	Введены логин и пароль для режима "Диспетчер"	Переход системы в режим "Диспетчер", отображение главного окна диспетчера
3	Введены логин и пароль для режима "Администратор"	Переход системы в режим "Администратор", отображение главного окна администратора
4	Введены логин и пароль для режима ""Аналитик"	Переход системы в режим "Аналитик ", отображение главного окна аналитика
5,6,7,8	Нажата кнопка закрытие приложения	Выход из приложения
9	Нажата кнопка выбор из меню "Изменение частоты опроса"	В основной форме диспетчер изменяет частоту опроса
10	Нажата кнопка "Опросить сейчас"	В основной форме диспетчера обновляются параметры
11,12,13,14,15,16,17	Нажатие на элемент списка ГРП	Обновление таблиц в основном окне
18	Выбор вкладки история события	Отражена история события в виде таблицы
19,20,21,22,23,24,25	Установлена отметка на соответствующей ГРП	Отобразить события в таблице отмеченных ГРП
26,27,28,29,30,31,32	Снята отметка с определения ГРП	Скрыть не отмеченное событие связанное с ГРП
33	Выбор вкладки "Главная форма"	Переход на главную форму "Диспетчер"
34,35	Нажатие кнопки "Экспорт"	Открыт текстовый процесс Word
36,37,38	Нажатие кнопки "Сменить пользователя"	Возврат на форму выбора Логина и пароля и режим работы
39,4	Зактрытие текстового окна Word	Переход на ранее активную вкладку
41,42	Выход из подсети "Диспетчер"	Переход на форму выбора логина ,пароля и режима работы
43	Ввод данных о СУБД	Обновление данных на форме
44	Ввод имени БД	Обновление имени БД на форме
45	Ввод вида источника данных	Обновление вида источников на форме
46	Нажата кнопка "Работа с учетными записями"	Открытие формы "редактор учетных записей"
47	Нажата кнопка "Изменить пароль"	Откритие окна изменения пароля
48	Нажата кнопка "Удалить"	Открытие окна удаления пользователя
49	Нажатак кнопка "Добавить"	Открытие окна добавления нового пользователя
50	Выделение строки в таблице учетных записей	Подсвечивание выбранной учетной записи
51	Введен новый пароль в поле ввода	Отобразить спецсимволом символ пароля
52	Нажата кнопка "OK"	Пароль изменен
53	Нажата кнопка "Отмена"	Пароль остается без изменений
54	Нажата кнопка "ОК"	Учетная запись удалена
55	Нажата кнопка "Отмена"	Не удалена учетная запись
56	Установлена метка	Установлена метка администратор
57	Установлена метка	Установлена метка аналитик
58	Установлена метка	Установлена метка диспетчер
59	Сната метка	Снята метка администратор
60	Сната метка	Снята метка аналитик
61	Сната метка	Снята метка диспетчер
62	Введен логин	Отображен логин новой учетной записи
63	Нажата кнопка "ОК"	Пользователь добавлен
64	Нажата кнопка "Отмена"	Пользователь не добавлен
65	Выбрать первую строку из таблицы	Подсвечивание выделения в таблице
66	Снять выделение с строки таблицы	Снять выделение с таблицы
67	Нажата кнопка объединить в основной форме аналитика	Отображено окно ввода для добавления правила
68,73	Нажата кнопка "ОК"	Обновить список правил в таблице
69,74	Нажата кнопка "Отмена"	Отобразить таблицу правил без изменений
71, 70	Выход из подсети "Администратор"	Переход на ввод логина, пароля и режима входа
72	Нажата кнопка удалить	Отображение окна подтверждения
75	Выход из подсети "Аналитик"
76	Нажата кнопка ввести новое правило	Открыто окно конструктора нового правила
77	Нажата кнопка "Готово"	Добавлено новое правило
78	Нажата кнопка "Отмена"	Отображение прежнего списка правил
79	Отображено новое название	Отображение названия
80	Ввод нового названия	Введено новое название правила
81	Выделить строку в таблице	Подсветить выбранную строку
82	Выбрать параметр	Отобразить выбранный параметр
83	Выбрать значение	Отобразить выбранное значение
84	Выбрать знак	Отобразить выбранный знак
85	Добавить условие	Внесение нового условия в таблицу условий
86	Нажатие кнопки изменить	Отобразить данные в полях параметров ,знак, значение соответсвующее выделенному условию

На рисунке 22 изображена экранная форма программного приложения с помощью, которого происходит вход в систему, требуется ввести логин, пароль, режим входа.



Рисунок 22 - Экранная форма входа в систему

На рисунке 23 изображена экранная форма подсети диспетчер. На форме отображена главная страница приложения, справа присутствует список ГРП, при выделении конкретной ГРП появляется список, в котором отображено время опроса и данные.

Рисунок 23 - Экранная форма подсети диспетчер

Также на форме присутствует время опроса которое диспетчер может изменить, или опросить в данный момент времени. Также на форме есть кнопка «экспорт», при нажатии которой происходит формирование отчета.

На рисунке 24 изображена экранная форма программного приложения диспетчер, вкладка история событий, которая отражает запрошенные данные в соседнем поле на конкретной выбранной ГРП.

Рисунок 24 - Экранная форма вкладки история событий

Рисунок 25 -Экранная форма вкладки тревожного сообщения

Когда появляется внештатная ситуация, то появляется форма на которой отображена причина появления такой ситуации и возможные методы ее устранения. Диспетчеру остается выбрать одно из решений и выполнить его (рисунок 25).

На рисунке 26 отображена главное окно вкладки администратор, на нем администратору предлагается ввести имя сервера БД, имя БД и вид источника данных, также есть кнопка работа с учетными записями рисунок 27, при нажатии которой администратор может производить ряд действий:

- добавление новой учетной записи;

- удаление существующей учетной записи;

- изменение пароля у существующей учетной записи;

При добавлении учетной записи администратору предлагается ввести логин нового работника и отметить галочкой его права (рисунок 28).

Рисунок 26 - Главная экранная форма вкладки администратор



Рисунок 27 - Главная экранная форма вкладки администратор

Рисунок 28 -Экранная форма вкладки добавления нового пользователя

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

Рисунок 29 - Экранная форма изменения пароля

На экранной форме 30 отражено окно, с помощью которого аналитик добавляет, удаляет, изменяет, правила. На форме отображен список правил и критерии.

Рисунок 30 - Экранная форма вкладки аналитик

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

На рисунке 32 присутствует форма позволяющая редактировать правила, здесь аналитик может добавить новое условие, изменить существующее, а также выбрать параметр и присвоить ему значение, подтвердить это нажатием на кнопку готово. Также можно изменить существующее правило, для этого выбираем правило подвергшееся изменению. Выполняем необходимые изменения, и нажимаем кнопку готово.

Рисунок 31 - Экранная форма объединения правила



Рисунок 32 - Экранная форма редактирования правил

3. Обоснование экономической эффективности разработки информационной системы для ОАО «Газпромрегионгаз»