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

МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ

ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ БЮДЖЕТНОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ ВЫСШЕГО ПРОФЕССИОНАЛЬНОГО ОБРАЗОВАНИЯ «ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ - УЧЕБНО-НАУЧНО-ПРОИЗВОДСТВЕННЫЙ КОМПЛЕКС»

ДИПЛОМНАЯ РАБОТА

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

Специальность 230201 «Информационные системы и технологии»

Студент Пасечникова О.Е

Руководитель Фролова В.А

Нормоконтроль Волков В.Н

Консультант по организационной

и экономической части Терентьев С.В

Консультант по безопасности жизнедеятельности

Шушпанов А.Г

Орел 2014

Введение

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

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

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

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

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

Целью дипломной работы является создание подсистемы поддержки принятия решений в системе оперативно-диспетчерского контроля и управления нефтестанции на предприятии ОАО «Юго-Западтранснефтепродукт» ЛПДС «Стальной Конь».

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

- рассмотреть особенности функционирования предприятия;

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

- разработать структуру базы данных;

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

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

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

1. Аналитическая часть

интерфейс алгоритм база данные

1.1 Анализ работы нефтестанции

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

Основными задачами нефтестанции являются:

- обеспечение бесперебойного снабжения потребителей нефтепродуктами в необходимом количестве и ассортименте;

- сохранность качества нефтепродуктов и сокращение до минимума потерь при их приеме, хранении и отпуске [2].

Всего на нефтестанции работают 147 человек. Обслуживают предприятие следующие внутренние подразделения и службы: транспортная бригада, аварийная бригада, бригада электриков, пожарная бригада, отдел контрольно-измерительных приборов, служба операторов, расчетно-финансовый отдел, служба охраны [2]. Организационная структура предприятия представлена на рисунке 1.

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

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

Рисунок 1 - Организационная структура управления

Архитектура АСУТП на ЛПДС «Стальной Конь» представлена тремя уровнями на рисунке 2.



Рисунок 2 - Уровни автоматизированной системы

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

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

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

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

- управление технологическим оборудованием магистрального трубопровода из операторной, местного диспетчерского пункта, районного диспетчерского пункта;

- автоматическую защиту и блокировку;

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

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

- регулирование давления, расхода, температуры;

- регулирование расхода нефтепродуктов;

- регистрацию, архивирование и отображение информации о работе технологического оборудования магистрального трубопровода;

- связь с другими системами автоматизации и информационными системами [3].

К основным функциям автоматизированной системы управления технологическими процессами на нефтестанции относятся:

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

- проверку соответствия измеренных значений технологических параметров допускаемым (нормативным) значениям;

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

- передачу информации в другие системы, в объёме, требуемом для функционирования этих систем;

- отображение состояния и режимов работы оборудования магистрального трубопровода на видеомониторах с помощью мнемосхем, использующих стандартные мнемосимволы [3];

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

Время, необходимое для отображения вновь открываемых экранных форм на автоматизированном рабочем месте, не превышает 1 секунды. Период обновления информации на экранных формах рабочего места не превышает 0,5 секунды [3].

От локальных систем управления котельных, дизельных электростанций в системы автоматизации нефтеперекачивающей станции передаются дискретные сигналы: обобщенный сигнал состояния (включена/отключена («в работе»)) [3].

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

- обобщенный сигнал аварии;

- обобщенный сигнал состояния (включена/отключена («в работе»));

- сигнал срабатывания главного быстродействующего запорного клапана топливоснабжения котельной;

- сигнал несанкционированного проникновения;

- сигнал превышения предельного и аварийного значения содержания окиси углерода в воздухе [3].

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

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

- канальный уровень: Ethernet;

- сетевой уровень: IP;

- транспортный уровень: TCP (допускается использование EFDP);

- прикладной уровень: HTTP или HTTPS [3].

Допускается использовать внутрифирменные протоколы связи баз данных, таких как MS SQL Server, Oracle, OSI PI System и т.п.

Кроме системы оперативно-диспетчерского контроля на предприятии также функционируют следующие системы:

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

2. ЕИАС - единая информационно-аналитическая система управления по тарифам.

В соответствии с письмом Федеральной службы по тарифам от 9 марта 2006 года № ДС-1137/11 «О полнофункциональном применении Единой Информационно-аналитической системы «ФСТ - РЭК - субъекты регулирования» с 1 ноября 2009 года введена в постоянную эксплуатацию Единая Информационно-аналитическая система «ФСТ - РЭК - субъекты регулирования» на территории всей Российской Федерации [6].

Наиболее актуальными проблемами на любой линейной производственно-диспетчерской станции, в частности на нефтестанции «Стальной конь», являются проблемы безопасности эксплуатации и улучшение управления процессами контроля слива/налива и транспортировки нефтепродукта без потерь.

Для решения данных задач разрабатываются и внедряются системы телемеханики. Системы телемеханики обеспечивают удаленный контроль за территориально-распределенными объектами, информационную поддержку работы диспетчера, обеспечивают ретрансляцию на исполнительные устройства команд, поданных диспетчером телеуправления или телерегулирования. В штатном режиме работы объектов данные, полученные телемеханикой, являются основой для анализа режима работы технологических объектов и принятия решений по его оптимизации. В аварийных ситуациях данные, контролируемые телемеханикой, позволяют диагностировать разрывы трубопроводов и другие аварийные ситуации, определять место аварии осуществлять локализацию (отключение) аварийного участка [3].

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

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

Основная задача разрабатываемой подсистемы поддержки принятия решений - это предоставление аналитикам инструмент для выполнения анализа данных.

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

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

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

Функциональные требования:

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

- контроль показания датчиков давления, загазованности, температуры, уровня масла;

- обработка и выдача решения об изменении показаний датчиков, включению/отключению насосов, наборе указаний аварийной бригаде;

- хранение и отображение необходимой информацию о принятых решениях;

- возможность наполнения базы знаний экспертом;

- ведение журнала сбоев;

- ведение журнала отправки аварийной бригады.

Нефункциональны требования:

- разделение прав доступа между оператором, администратором, экспертом;

- работа под операционной системой Windows 7;

- понятный оператору интерфейс.

1.3 Описание модели процессов принятия решений

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

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

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

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

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

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

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

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

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

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

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

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

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

Контекстная диаграмма представлена на рисунке 3.



Рисунок 3 - Контекстная диаграмма

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

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

Рисунок 4 - Сформировать и выбрать мероприятия, заполнить журналы

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

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

Блок произвести работу по формированию мероприятий декомпозируется на 4 блока: загрузить значения загрузить значения из существующей БД, сопоставить значения с фактами, сформировать мероприятия и выбрать мероприятие (рисунок 5).

Рисунок 5 - Произвести работу по формированию мероприятий

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

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

Блок сформировать мероприятия декомпозируется на 3 блока: вывести решение об неудовлетворительных показаниях, вывести решение о критических показаниях, вызвать ремонтную бригаду (рисунок 6).

Рисунок 6 - Вывести мероприятие

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

1.4 Компоненты разрабатываемой подсистемы поддержки принятия решений

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

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

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

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

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

Рисунок 7 - Структура разрабатываемой подсистемы

1.5 Формирование фактов в разрабатываемой подсистеме поддержки принятия решений

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

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

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

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

Ниже приведен пример формирования фактов.

Пример:

Файл, полученный из БД системы:

Датчик1 30

База данных:

30 низкое

База знаний:

если датчик1 низкое то низкое давление в трубе1

если низкое давление в трубе1 и насос 1 работает в полную мощность то пробой в трубе1

если низкое давление в трубе1 то включить насос1 на полную мощность

Рабочая память:

датчик1 низкое

низкое давление в трубе1

включить насос1 на полную мощность

1 если датчик1 низкое то низкое давление в трубе1

2 если низкое давление в трубе 1 то включить насос 1 на полную мощность

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

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

2.1 Проектирование базы данных

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

Рисунок 8 - Логический уровень БД

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

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

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

Продукция состоит из антецедента (условие) и консеквента (следствие). Информация о продукциях содержится в трех сущностях «факт антецедента», «факт консеквента», «продукция».

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

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

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

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

2.2 Физическая модель БД

Физическая модель базы данных представлена на рисунке 9.

Рисунок 9 - Физическая модель базы данных

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

Сущность «Sensor» соотносится с сущностью «Датчик», содержит те же поля, что и на логическом уровне.

Сущность «Readout_Fact» соотносится с сущностью «Показание датчика - факт».

Сущности «Факт», «Информация» и «Мероприятие» на логическом уровне представлены сущностью «Fact» на физическом.

Сущность «AntecedentFact» содержит те же поля, что и сущность «Факт Антецедента» на логическом уровне.

Сущность «Production» соотносится с сущностью «Продукция» и содержит те же поля.

Сущность «ConcequentFact» соотносится с сущностью «Факт консеквента».

Сущность «User» соотносится с сущностью «Пользователь» и содержит те же поля, что и на логическом уровне.

Сущность «PerfomedAction» соотносится с сущностью «Проведение мероприятия» и содержит те же поля, что и на логическом уровне.

2.3 Определение ограничений целостности для связей между сущностями

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

Сущность «Sensor» связана с сущностью «Readout_Fact» с помощью идентифицирующей связи «один ко многим», так как у одного и того же датчика могут быть разные показания. Ключ «SesorID» является мигрирующим первичным ключом для сущности «Readout_Fact» для того, чтобы по номеру датчика определять для какого типа датчика использовать соответствующие диапазоны.

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

Сущности «AntecedentFact» и «ConcequentFact» являются вспомогательными, реализующими связь «многие ко многим» для сущностей «Production» и «Fact». Для каждой продукции может быть множество фактов в части консеквета и множество фактов в части антецедента.

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

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

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

2.4 Выбор стратегий ограничения целостности

Обеспечение целостности базы данных также осуществляется при помощи стандартных триггеров, встроенных в СУБД. Целостность поддерживается во-первых на уровне контроля уникальности первичных ключей и автоматической генерации значений суррогатных ключей «Номер факта» сущности «Факт» и «Номер правила» сущности «Правило». Во-вторых, обеспечивается целостность базы данных с точки зрения корректности внешних ключей. Это подразумевает с одной стороны контроль того, чтобы значения внешних ключей в дочерней сущности всегда соответствовали некоторым записям в родительской сущности, либо имели значение NULL, если связь разрешает его использование. С другой стороны обеспечивается поддержание целостности при помощи стратегий RESTRICT, CASCADE, SET NULL и NO ACTIONЮ которые определяют набор действий, совершаемых при добавлении, удалении или изменении записей в двух сущностях, связанных через внешний ключ. При использовании стратегии RESTRICT для родительской сущности, удаление или изменение записи, имеющей связанные с ней записи в дочерней сущности, будут заблокированы, т.е. запрос завершится с сообщением об ошибке. Стратегия CASCADE при удалении записей в родительской сущности удаляет также все связанные записи в дочерней сущности, а при обновлении, соответственно, обновляет значения полей. Использование стратегии SET NULL, при удалении записи в родительской сущности обнуляет (устанавливает значение NULL) соответствующее поле в дочерней сущности. Задание NO ACTION отключает использование каких-либо проверок для данной связи. Рассмотрим использование данных стратегий для каждой из связей рассматриваемой базы данных.

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

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

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

Связи сущности «Пользователь» с сущностями «Правило», «ПроведенноеМероприятие» и «ЗафиксированныйСбой» на обновление имеют стратегию CASCADE, поскольку возможна ситуация, когда пользователь захочет изменить свой логин в системе. На удаление данные связи используют стратегию RESTRICT, поскольку в сущности «Правило» содержится информация введенная пользователем, и ее удаление должно быть только явным, а в сущностях «ПроведенноеМероприятие» и «ЗафиксированныйСбой» содержится история функционирования станции, которая также не должна быть удалена случайно.

2.5 Алгоритм работы приложения

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

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

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

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

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

Здесь доступны переходы на:

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

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



Рисунок 11 -

3. Обоснование экономической эффективности разработки подсистемы поддержки принятия решений системы оперативно-диспетчерского контроля

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

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

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

3.1 Виды и источники получаемых эффектов

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

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

Экономический эффект вызван:

- повышением качества принимаемых решений вследствие внедрения подсистемы;

- экономией затрат труда диспетчера.

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

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

Оценим затраты на разработку системы.

3.2 Оценка стоимости разрабатываемой подсистемы поддержки принятия решений

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

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

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

Рассчитаем оплату труда работников в различных этапах проектирования.

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

Сот = ? ? p ij * T ij * (1+k)

где - затраты на оплату труда исполнителей, руб.;

- часовая тарифная ставка сотрудника j-й категории, выполняющего i-й этап работ, руб;

- трудоемкость i-го этапа проектных работ для сотрудника j-ой категории, ч;

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

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

Стадии разработки системы и их оплата приведены в таблице 3.1.

Таблица - 3.1 Стадии разработки системы

Этап проектирования	Исполнители	Часовая тарифная ставка, руб.	Трудоемкость, ч.	Итого
1. Изучение предметной области	Руководитель дипломной работы	243	10	2431,7
	Разработчик	78	17	2254,2
2. Постановка задач	Руководитель дипломной работы	243	14	5783,4
	Разработчик	78	70	9282
	Специалист	420	5	3570
3. Анализ аналогов системы	Разработчик	78	20	2652
4. Оценка экономической эффективности разработки и внедрения системы	Разработчик	78	12	1591,2
	Консультант по экономической части	243	4	826,2
5. Анализ условий труда	Разработчик	78	12	1591,2
	Консультант по безопасности жизнедеятельности	243	4	826,2
6. Разработка архитектуры ПО	Руководитель дипломной работы	243	2	826,2
	Разработчик	78	150	19890
7. Реализация (кодирование)	Разработчик	78	250	33150
8. Тестирование	Разработчик	78	10	1326
9. Внедрение	Разработчик	78	25	3315
Итого	____	___	___	89315,3

Таким образом, затраты на оплату труда исполнителей составят:

= 89315,3 р.

Далее производится анализ затрат на необходимые для разработки системы аппаратные средства.

Затраты на эксплуатацию ЭВМ вычисляются по формуле:

, (3.1)

где - затраты на эксплуатацию ЭВМ, руб.;

- общие стоимостные затраты, руб.;

- стоимость амортизации машин, руб.

Общие стоимостные затраты определяются согласно формуле:

С0 = Цмч*Тэвм (3.2)

где - стоимость машинного часа ЭВМ, руб.;

- время эксплуатации ПЭВМ, н/часов.

Стоимость машинного часа ЭВМ вычислим, исходя из следующих данных: мощность используемой ЭВМ - 0,5 кВт, стоимость электроэнергии - 2,96 руб/кВт. Цмч = 0,5*2,96 = 1,48 руб.

Также произведем анализ затрат машинного времени по этапам проектирования. Результаты представлены в таблице 3.2.

Таблица 3.2 - Расчет времени эксплуатации ЭВМ

Этап проектирования	Количество н- часов
Сбор, формулирование и анализ требований к разрабатываемой подсистеме	48
Концептуальное и логическое проектирование	24
Проектирование базы данных, базы знаний	80
Разработка компонентов подсистемы	92
Настройка взаимодействия	40
Тестирование, настройка	80
Технико-экономическое обоснование эффективности ИС и анализ условий труда оператора	28
Руководство этапами дипломного проектирования	24
Итого	416

Таким образом, н - часов. Подставив полученные данные в формулу (3.2), получим: Со = 1,48*416 = 615,68 руб.

Стоимость амортизации машины определяется по формуле:

СА =ач* Тэвм (3.3)

где - часовая сумма амортизации машин, руб.

Расчет часовой суммы амортизации ЭВМ произведем, исходя из следующих данных: стоимость компьютера - 20000,00 руб., количество рабочих дней в году - 313 дней, количество рабочих часов в дне - 8 часов, срок эксплуатации ЭВМ - 5 лет.

ач = 20000/ (313*8*5) = 1,60 руб.

В связи с этим стоимость амортизации ЭВМ будет равна:

CA = 1,60 * 416 = 665,8 руб.

Подставив рассчитанные значения и в формулу (3.1), определим величину затрат на эксплуатацию ЭВМ в процессе проведения проектных работ: Сэвм = 615,68 + 665,8 = 1281,48 руб.

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

, (3.4)

где - общие затраты на разработку, руб.

Собщ = 89315,3 + 1281,48 = 90596,78 руб.

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

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

СВ = СУ + СОБ (3.5)

где СВ - стоимостные затраты на внедрение ИС, руб.;

СУ - величина затрат на установку ИС, руб.;

СОБ - стоимость обучения персонала эксплуатации ИС, руб.

Величина затрат на установку АС на предприятие определяется согласно формуле:

СУ = k * ТУ * pА * (1 + K) (3.6)

где k - количество ПЭВМ, на которых планируется установка АС;

ТУ - трудоемкость установки АС, ч;

pА - часовая тарифная ставка администратора, руб.;

К - коэффициент заработной платы из формулы (3.1).

Трудоемкость установки проектируемого программного средства на одном компьютере составляет в среднем 0,15 ч., а один час работы администратора стоит 200 рублей. Программный продукт будет установлен на 1 ПЭВМ. Рассчитаем величину СУ:

CУ = 6 · 0,15 * 200,00 * (1,0 + 0,7) = 306 руб.

Стоимость обучения работников предприятия и эксплуатации ИС СОБ, руб., определяется, как:

СОБ = gr *ТОБ * pОБ * (1 + K)+ p * ТОБ * (1 + K) (3.7)

где gr - количество обучающихся групп;

ТОБ - трудоемкость обучения персонала АС, ч;

pОБ - тарифная ставка работника, проводящего обучение, руб.;

К - коэффициент заработной платы из формулы (3.2);

р - тарифная ставка работника, проходящего обучение.

Учитывая, что один час работы диспетчера оплачивается в размере 250 рублей, а системного администратора - в размере 200 рублей, получим значение величины CОБ:

CОБ = 1 * 4 * 200 · (1,0 + 0,7) + 250 * 4 · (1,0 + 0,7) = 3060 руб.

Таким образом, величина затрат на установку подсистемы и обучение сотрудников составляет 3060 руб.

Общая сумма по разработке и внедрению программного продукта будет равна 90596,78 руб. + 3060 руб. = 93656,78 руб.

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

3.3 Оценка величины экономического эффекта от внедрения системы

Экономический эффект от внедрения подсистемы поддержки принятия решений, как уже было сказано, вызван повышением качества принимаемых решений и экономией затрат труда оператора.

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

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

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

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

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

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

(3.8)

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

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

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

С1 = p * T0 * (1+k), (3.9)

где - затраты на оплату труда исполнителей, руб.;

- средняя часовая тарифная ставка исполнителя, руб. (в расчетах 250 руб. );

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

Стоимость амортизации ЭВМ определяется по формуле:

CA = a * T0 (3.10)

Где a - часовая сумма амортизации, вычисляемая по формуле (3.6) (в расчетах a = 2,12 руб.).

Стоимость обработки данных с помощью ЭВМ определяется по формуле:

Cэвм = Ц * T0 (3.11)

где - стоимость машинного часа ЭВМ (в расчетах = 1,48 руб/ч, так как используемая ЭВМ имеет мощность 0,5 кВт, а стоимость электроэнергии принимается равной 2,96 руб/кВт).

Общие стоимостные затраты при ручном варианте рассчитывается по следующей формуле:

(3.12)

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

Результаты оценки трудовых затрат при ручном слежении приведены в таблице 3.

Таблица 3 - Оценка трудовых затрат ручном слежении

Наименование операции	Трудоемкость на на одну операцию (н-час)	Количество операций в год (шт.)	Трудоемкость на все операции (н-час)
Ведение истории сбоев	2	12	24
Ведение журнала отправки аварийных бригад	2	33	66
Итого:	-	-	90

Из таблицы 10 получаем, что общая трудоемкость ручного варианта составляет = 90 н-час. Подставив это значение в формулы (3.9), (3.10) и (3.11), получим следующие значения:

С1 =250*90*(1+0,7) = 38250 (3.9)

С а = 2,12* 90 = 190,8 (3.10)

С ЭВМ = 1,48* 90 = 133,2 (3.11)

С помощью формулы (3.12) рассчитываем общие стоимостные затраты при полуавтоматизированном слежении за параметрами:

С0 = 38250 +190,8 + 133,2 = 38574 руб. (3.12)

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

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

Таблица 4 - Объем работ при машинной обработке информации

Наименование операции	Трудоемкость на на одну операцию (н-час)	Количество операций в год (шт.)	Трудоемкость на все операции (н-час)
Ведение истории сбоев	1	11	11
Ведение журнала отправки аварийных бригад	0.3	30	9
Итого:	-	-	20

Итак, трудоемкость автоматизированного варианта обработки информации 20 н-час.

...