Система поддержки принятия решений по диагностированию состояния технологического процесса по производству газобетона

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

Выпускная квалификационная работа

Система поддержки принятия решений по диагностированию состояния технологического процесса по производству газобетона

Аннотация

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

Содержание

• Список сокращений
• Введение
• 1. Исследование технологического процесса по производству газобетона
• 1.1 Описание технологического процесса по производству газобетона и существующей системы управления
• 1.2 Обоснование выбора CASE-средств
• 1.3 Разработка функциональных моделей системы. Модель объекта «как есть»
• 1.4 Цель и задачи ВКР
• 2. Проектирование СППР по диагностированию технологического процесса производства газобетона
• 2.1 Модель «как будет» процесса диагностирования состояния технологического процесса производства газобетона с учетом СППР
• 2.2 Идентификация требований к СППР
• 2.3 Разработка архитектуры СППР
• 3. Прототипирование СППР по диагностированию технологического процесса производства газобетона
• 3.1 Прототипирование БП СППР
• 3.2 Прототипирование механизма логического вывода
• 3.3 Прототипирование интерфейса СППР
• 4. Организационная часть и экономическая часть
• 4.1 Организационная часть
• 4.2 Экономическая часть
• 5. безопасность и экологичность проекта
• 5.1 Идентификация и анализ опасных и вредных факторов, воздействующих на работников завода
• 5.2 Разработка мероприятий по обеспечению безопасности и экологичности условий труда
• Заключение
• Список литературы
• Приложение А
• Приложение Б

Список сокращений

АИС - автоматизированная информационная система.

АСУ -автоматизированная система управления.

БД - база данных.

ВКР - выпускная квалификационная работа.

ВНД - внутренняя норма доходности

ИД - индекс доходности

ООО - общество с ограниченной ответственностью

ПАЗ - противоаварийная защита

ПК - персональный компьютер

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

ПП - программный продукт

РЕ - расходная емкость

РД - рабочая документация

СППР - система поддержки принятия решений

СТП - спецификация требований пользователя

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

ТП - технологический процесс

УГАТУ - уфимский государственный авиационный технический университет

УСО - устройство связи с объектами

ЧДД - чистый дисконтированный доход

CAD - Сomputer Aided Design

CAE - Computer Aided Engineering

CMMI - Capability Maturity Model Integration

ERP - Enterprise Resource Planning

HMI - Human Machine Interface

IT -Information Technology

MES - Manufacturing Execution System

SADT - Structured Analysis and Design Technique

SCADA - Supervisory Control And Data Acquisition

Введение

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

При управлении сложными техническими объектами, большая ответственность ложится на плечи оператора/диспетчера, который отвечает за весь процесс производства. В 60-х годах ошибка человека была первоначальной причиной аварий лишь в 20% случаев, тогда как к концу 80-х доля "человеческого фактора" стала приближаться к 80 %. Таким образом, требование повышения качества систем диспетчерского управления является одной из предпосылок появления нового подхода при разработке таких систем: ориентация на оператора/диспетчера и его задачи. Разработка системы информационной поддержки оперативного управления процессом производства газобетона позволит повысить эффективность противоаварийной защиты, сократить аварийные ситуации и отказы оборудования и, соответственно, уменьшить финансовые затраты на производство.

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

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

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

1. Исследование технологического процесса по производству газобетона

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

решение диагностирование производство газобетон

Общество с ограниченной ответственностью (ООО) «ДЖУТ - СТ» учреждено в соответствии с действующим законодательством Российской Федерации и приобрело права юридического лица с момента его регистрации в администрации города Агидель. ООО «ДЖУТ - СТ» строит свою деятельность на основании устава и законодательства. Участниками общества являются граждане Российской Федерации.

Основной продукцией предприятия ООО «ДЖУТ - СТ» является кирпич и газобетон. Основной целью технологического процесса по их производству является:

1) получение продукта с заданными характеристиками;

2) обеспечение непрерывного, безаварийного производства.

В состав производства входят следующие отделения[29]:

Узел №10 - отделение приемки цемента, извести-пушонки и гипса, а также помола и транспорта вяжущего. Состоит из пневморазгрузчика ТА-51, трех емкостей хранения цемента по 120м3 каждый и одного пневмонасоса ТА-14Б, транспортирующего цемент в расходные емкости, а также трех шаровых мельниц типа СМ-1456 и двух пневмовинтовых насосов типа ТА-14Б, транспортирующих, полученное после мельниц вяжущее, на газобетонное и силикатное производство.

Узел №20 - отделение приема и помола песка для газобетонного производства. Состоит из приемного бункера емкостью 32 м3, двух емкостей хранения по 120 м3 каждая и шаровой мельницы мокрого помола СМ6001А.

Узел №21 - отделение приготовления шлама, для чего предусмотрены 2 шлам-бассейна по 50м3 каждый и 2 бассейна обратного шлама по 25м3, а также 2 бронированных шламовых насоса, производительностью по 25м3 каждый для транспортировки шлама в отделение дозирования и смешения.

Узел №22 - отделение подготовки воды, для чего предусмотрены две емкости по 10м3 каждая.

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

Узел №24 - отделение вызревания и сборки-разборки форм. Состоит из станка сборки-разборки и 35 камер вызревания, оборудованных системой вентиляции и отопления.

Узел №25 - линия реза, состоящая из станка продольной резки, станка поперечной резки, станка снятия верхней горбушки и двух кантователей.

Узел №26 - автоклавное отделение. Состоит из 8 тупиковых автоклавов, 8 линий накопления готовых к пропарке массивов, 1 запасной и 1 разгрузочной линии. Погрузка-разгрузка автоклавов осуществляется с помощью электро- передаточного моста.

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

Узел №29 - приготовление алюминиевой суспензии. Состоит из двух емкостей, оборудованных мешалками и бронированного насоса.

Взаимодействие узлов представлено на рис. 1.1.

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

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

Рисунок 1.1 - Узлы завода по производству газобетона

Рисунок 1.2 - Организационная схема завода по производству газобетона

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

Реализованная АСУТП комплекса по производству автоклавного газобетона выполняет следующие функции:

? сбор информации о состоянии технологических объектов управления;

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

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

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

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

? противоаварийная защита (ПАЗ) процесса и производства при возникновении аварийных ситуаций;

? архивирование событий;

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

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

Рассматриваемая в данной работе система поддержки принятия решений взаимодействует с разработанной АСУТП на уровне Logistic - модуля, предназначенного для формирования аварийных сигналов. Logistic собирает данные с о ходе технологического процесса производства газобетона и обрабатывает их в соответствие с определенными алгоритмами для формирования аварийных сигналов. Аварийные сигналы формируются в текстовой форме и заводятся в систему поддержки принятия решений (СППР) по прерыванию. СППР обрабатывает полученные аварийные сигналы в соответствии с базой правил и выдает оператору готовый набор действий, необходимый для устранения аварии.

Таким образом СППР решает задачи:

­ архивации аварийных сигналов;

­ выдачи сценария ликвидации аварийной ситуации;

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

­ контроля за действиями по ликвидации аварийной ситуации.

1.2 Обоснование выбора CASE-средств

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

­ выбрать одну из стандартных архитектур СППР;

­ определить форматы входных данных СППР;

­ определить форматы выходных данных СППР;

­ определить внутренние интерфейсы СППР;

­ определить внешние интерфейсы СППР;

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

Для выбора CASE-средств из представленного списка доступных использован метод анализа иерархий (МАИ). В ходе сравнения доступных продуктов на первом этапе был сформулирован список критериев сравнения этих продуктов (таблица 1.1).

Таблица 1.1 - Критерии, применяемые для выбора инструментов организационного проектирования ИС

Критерий	Определение
1. Поддерживаемый стандарт	Возможность использовать весь комплекс стандартов по организационному проектированию при разработке технического задания и моделей.
2. Система хранения данных модели	Возможность хранения в БД всей необходимой информации, обеспечение возможности получения данных по всем необходимым запросам, сокращение избыточности и дублирования данных, и обеспечение целостности базы данных.
3. Экспорт отчетов	Возможность хранения в БД всей необходимой информации, обеспечение возможности получения данных по всем необходимым запросам, сокращение избыточности и дублирования данных, и обеспечение целостности базы данных.
4. Генерация отчетов	Автоматическая генерация отчетов по программным файлам, которые включает в себя: сбор и размещение в файле спецификаций элементов структурной схемы, генерацию текстов по шаблонам для библиотечных модулей, реализацию описанных процессов обработки информации, выполненных в предыдущих фазах разработки для отдельных структурных элементов и не представленных на диаграммах своей декомпозицией, в виде фрагментов программного кода.
5. Возможность групповой работы	Обеспечение многопользовательского доступ к моделям, которые могут храниться на центральном сервере и могут быть доступны для всех участников группы проектирования, при этом обеспечиваются в полном объеме возможности коллективного труда по созданию сложных и объемных моделей.
6. Описание доступа к данным
7. Возможность анализа стоимости процессов	Технологии распределения затрат между операциями бизнес-процесса с последующим распределением стоимости операций по объектам учета.

Иерархия сравнения продуктов ARIS, BPWin и Rational Rose представлена на рис. 1.3. В рамках этой иерархии принятия решения по выбору из трех возможных вариантов выделяют 3 уровня: на первом уровне устанавливается глобальная цель принятия решения: выбор полнофункционального средства, отвечающего применению к конкретной задаче.

Рисунок 1.3 - Трёхуровневая иерархия

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

Таблица 1.2 - Характеристики инструментов организационного проектирования ИС

	ARIS Toolset 5.0	ERwin/BPwin	Rational Rose
1	2	3	4
1.Поддерживаемый стандарт	IDEF3 (в форме еЕРС), частично DFD, ERM, UML	IDEFO, IDEF3, DFD	МТ, UML, нотация Буча
2. Система хранения данных модели	Объектная база данных	Модели хранятся в файлах. Возможно создание репозитория на основе реляционной СУБД с помощью Model Mart	Модели хранятся в файлах
3. Экспорт отчетов	Реализован экспорт отчетов в MS Office, текстовый файл, RTF, HTML	Реализован экспорт отчетов в MS Office, текстовый файл, RTF, HTML	-
4. Генерация отчетов	Создание отчетов на основе стандартных и настраиваемых пользователем макросов Visual Basic	RPT Win, возможность визуальной настройки отчетов, включая расчет по формулам с использованием UDP	-
5. Возможность групповой работы	Используется ARIS Server.	Используется Model Mart	Rational Suite, Visual Source Save
6. Описание доступа к данным	Нет	Для каждой работы могут быть описаны права на использование данных. Объект модели данных может быть создан непосредственно в среде BPwin	Для каждой работы могут быть описаны права на использование данных.
7. Возможность анализа стоимости процессов	Возможность использовать ARIS ABC	Упрощенный АВС-анализ стоимости по частоте использования в процессе. Возможность экспорта в Easy ABC	Нет встроенных возможностей анализа.

Таблица 1.3 - Шкала предпочтений объектов по методу анализа иерархий

Степень превосходства	Определение
0	Объекты несравнимы
1	Объекты одинаково важны
3	Умеренное превосходство одного над другим
5	Существенное превосходство одного над другим
7	Значительное превосходство одного над другим
9	Абсолютное превосходство одного над другим
2,4,6,8	Промежуточные значения степени превосходства

Для получения экспертных оценок значимости критериев была построена матрица с перечнем объектов сравнения. Попарно сравнивались критерии по отношению к поставленной цели, и была заполнена матрица парных сравнений (табл. 1.4).

Таблица 1.4 - Матрица парных сравнений критериев

	Кр 1	Кр 2	Кр 3	Кр 4	Кр 5	Кр 6	Кр 7
Кр 1	1,0	3,0	5,0	1,0	0,0	2,0	3,0
Кр 2	0,3	1,0	7,0	8,0	6,0	6,0	5,0
Кр 3	0,2	0,1	1,0	5,0	5,0	9,0	1,0
Кр 4	0,0	0,1	0,2	1,0	9,0	0,2	0,0
Кр 5	0,0	0,2	0,2	6,0	1,0	5,0	8,0
Кр 6	0,5	0,2	0,1	3,0	6,0	1,0	7,0
Кр 7	0,3	0,2	0,0	5,0	0,0	1,0	1,0

Для каждой такой матрицы был найден вектор значений критериев y1, ..., yn по формуле:

.

Затем нормализовали этот вектор:



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

Индекс согласованности (ИС) дает информацию о степени нарушения согласованности.

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

,

.

Величина ИС сравнивается с той, которая получилась бы при случайном выборе количественных суждений из шкалы, и образовании обратно симметричной матрицы. Значения случайной согласованности (СС) для идеальных матриц разного размера приведены в таблице 1.5

Таблица 1.5 - Значения случайной согласованности для матриц разного размера.

Размер матрицы	1	2	3	4	5	6	7	8	9	10
СС	0	0	0,58	0,9	1,12	1,24	1,32	1,41	1,45	1,49

Отношение согласованности (ОС) дает представление о верности сделанных суждений:

При этом, если

ОС ? 0,1 матрица, безусловно, согласованна;

0,1<ОС ? 0,2 согласованность матрицы приемлема;

ОС > 0,2 согласованность матрицы не приемлема.

ОС = 0,1, следовательно, матрица, безусловно, согласованна.

Было проведено аналогичное попарное сравнение альтернатив по каждому критерию в отдельности. Для этого для каждого критерия была заполнена матрица альтернатив (табл. 1.6):

Таблица 1.6 - Матрица парных сравнений альтернатив по 1-му критерию

	ERwin/BPwin	ARIS Toolset 5.0	Rational Rose
ERwin/BPwin	1	2	5
ARIS Toolset 5.0	1/2	1	6
Rational Rose	1/5	1/6	1

Таблица 1.7 - Матрица парных сравнений альтернатив по 2-му критерию

	ERwin/BPwin	ARIS Toolset 5.0	Rational Rose
ERwin/BPwin	1	3	4
ARIS Toolset 5.0	1/3	1	9
Rational Rose	1/4	1/9	1

Таблица 1. 8 - Матрица парных сравнений альтернатив по 3-му критерию

	ERwin/BPwin	ARIS Toolset 5.0	Rational Rose
ERwin/BPwin	1	1	8
ARIS Toolset 5.0	0	1	7
Rational Rose	1/8	1/7	1

Таблица 1.9 - Матрица парных сравнений альтернатив по 4-му критерию

	ERwin/BPwin	ARIS Toolset 5.0	Rational Rose
ERwin/BPwin	1	4	2
ARIS Toolset 5.0	1/4	1	7
Rational Rose	1/ 2	1/7	1

Таблица 1.10 - Матрица парных сравнений альтернатив по 5-му критерию

	ERwin/BPwin	ARIS Toolset 5.0	Rational Rose
ERwin/BPwin	1	7	6
ARIS Toolset 5.0	1/7	1	5
Rational Rose	1/6	1/5	1

Таблица 1.11 - Матрица парных сравнений альтернатив по 6-му критерию

	ERwin/BPwin	ARIS Toolset 5.0	Rational Rose
ERwin/BPwin	1	1	4
ARIS Toolset 5.0	0	1	7
Rational Rose	1/4	1/7	1

Таблица 1.12 - Матрица парных сравнений альтернатив по 7-му критерию

	ERwin/BPwin	ARIS Toolset 5.0	Rational Rose
ERwin/BPwin	1	1	0
ARIS Toolset 5.0	0	1	2
Rational Rose	0	1/2	1

Заключительным этапом выбора оптимального CASE-средства является определение глобального приоритета альтернатив с учетом весов всех критериев (таблица 1.13).

Таблица 1.13 - Определение глобальных приоритетов альтернатив

	Кр 1	Кр 2	Кр 3	Кр 4	Кр 5	Кр 6	Кр 7	Глобальный приоритет
Нормализ. вектор приоритетов	0	1,22	0,54	0	0	0,29	0
ERwin/BPwin	0,55	0,57	0,88	0,55	0,74	0,83	0	1,82
ARIS Toolset 5.0	0,37	0,36	0	0,33	0,19	0	0	0,67
Rational Rose	0,08	0,08	0,11	0,11	0,07	0,17	0	0,26

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

1.3 Разработка функциональных моделей системы. Модель объекта
«как есть»

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

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

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

Наименование стрелки	Описание	Тип
1	2	3
Сообщение	Сообщение об ошибке	Input
Регламент узла	Регламент узла	Control
БД сотрудников	БД сотрудников	Control
Спецификация на оборудование	Спецификация на оборудование	Control
Должностные инструкции	Должностные инструкции	Control
Формы отчетности	Формы для отчетов	Control
Отчет о проделанной работе	Отчет о проделанной работе	Output
Оператор	Оператор	Mechanism
Инженер-технолог	Инженер-технолог	Mechanism
Старший инженер	Старший инженер	Mechanism

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

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

Таблица 1.15 - Описание функциональных блоков диаграммы
декомпозиции контекстной модели

Функциональный блок	Описание
Зарегистрировать сообщение	Регистрация сообщения об ошибке
Выявить отклонение	Выявление отклонения в работе
Устранить неполадку	Устранение неполадок
Проверить выполненную работу	Проверка выполненных работ
Сформировать отчет	По итогам проделанных работ, формирование отчета

Диаграмма декомпозиции представлена на рис. 1.5.

Рисунок 1.5 - Диаграмма декомпозиции главной функции

Методология DFD (Data Flow Diagrams) - диаграммы потоков данных - позволяет определить:

- функции обработки информации (работы, activities);

- документы (стрелки, arrows), объекты, сотрудников или отделы, которые участвуют в обработке информации;

- внешние ссылки (external references), которые обеспечивают интерфейс с внешними объектами, находящимися за границами моделируемой системы;

- таблицы для хранения документов (хранилище данных, data store).

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

В таблице 1.15 приведено описание диаграммы потоков данных.

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

Компоненты	Наименование	Описание
Наименование подсистемы	Диагностирование состояния технологического процесса производства газобетона	Диагностирование состояния технологического процесса производства газобетона
Внешняя сущность	Logistic	Из программы Logistic поступают сообщения об ошибках
Внешняя сущность	Служба обслуживания газобетонных установок (СОГУ)	СОГУ принимает сообщение об ошибках, предлагает решение и исправляет неполадки в системе
Внешняя сущность	Отдел по контролю за производством	По итогам проделанных работ формируется отчет и направляется в отдел по контролю за производством

Рисунок 1.6 - Диаграмма потоков данных (AS-IS) в нотации DFD

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

Таблица 1.16 - Описание декомпозиции диаграммы потоков данных

Компоненты	Наименование	Описание
1	2	3
Процесс	Выявление отклонения	После поступления сообщения об аварии наступает процесс выявления отклонения
Процесс	Устранение неполадки	Согласно плану работ производиться устранение неполадки
Процесс	Проверка выполненной работы	По запросу на проверку выполненных работ производится проверка выполненных работ
Процесс	Формирование отчета	По итогам проделанных работ формируется отчет
Внешняя сущность	Служба обслуживания газобетонных установок (СОГУ)	После поступления сообщения об аварии СОГУ формирует план работ, устраняет проблему и руководствуясь спецификацией проверки газобетонных установок осуществляет проверку выполненных работ
Хранилище данных	Архив	Сформированный отчет хранится в архиве

Рисунок 1.7 - Декомпозиция диаграммы потоков данных (AS-IS) в нотации DFD

Диаграмма декомпозиции в форме диаграммы потоков данных представлена на рис. 1.7.

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

1.4 Цель и задачи ВКР

Целью ВКР является: увеличение времени безотказной работы технологического комплекса по производству газобетона за счет внедрения системы поддержки принятия решений по диагностированию состояния этого комплекса.

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

где N0 -- исходное число работоспособных объектов,

n(t) -- число отказавших объектов за время t.

Межгосударственный стандарт ГОСТ 27.002-89. Настоящий стандарт устанавливает основные понятия, термины и определения понятий в области надежности и распространяется на технические объекты. Настоящий стандарт должен применяться совместно с ГОСТ 18322. Настоящий стандарт устанавливает применяемые в науке, технике и производстве термины и определения основных понятий в области видов, методов и показателей технического обслуживания и ремонта изделий.

Задачи ВКР:

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

2.Разработать структуру СППР и основные компоненты: алгоритм принятия решений и информационную модель базы данных (ИМ БД).

В состав системы поддержки принятия решений войдут три главных компонента: база данных, база моделей и программная подсистема, которая состоит из трех подсистем: системы управления базой данных (СУБД), системы управления базой моделей (СУБМ) и системы управления интерфейсом между пользователем и компьютером.

3. Разработать прототип СППР и составить план внедрения

Прототип СППР для оперативно-диспетчерского управления (ООО) «ДЖУТ - СТ» позволит персоналу технологического процесса (ЛПР - лицу, принимающему решения):

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

- по необходимости переключать внимание ЛПР на одну из подсистем технологического процесса производства газобетона;

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

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

- отслеживать процесс управления системы;

- прогнозировать состояние параметров управления;

- вмешиваться в процесс управления;

- проводить тестирование.

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

2. Проектирование сппр по диагностированию технологического процесса производства газобетона

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

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

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

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

? "модульность", обеспечивающая декомпозицию задач при создании и расширении системы;

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

2.1 Модель «как будет» процесса диагностирования состояния технологического процесса производства газобетона с учетом СППР

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

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

Таблица 2.1 - Описание модели IDEF0

Наименование стрелки	Описание	Тип
Сообщение	Сообщение об ошибке	Input
Регламент узла	Регламент узла	Control
Спецификация на оборудование	Спецификация на оборудование	Control
Должностные инструкции	Должностные инструкции	Control
Формы отчетности	Формы для отчетов	Control
Отчет о проделанной работе	Отчет о проделанной работе	Output
Оператор	Оператор	Mechanism
Инженер-технолог	Инженер-технолог	Mechanism
Старший инженер	Старший инженер	Mechanism
СППР	Система поддержки принятия решений	Mechanism

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

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

Таблица 2.2 - Описание работ, входящих в процесс диагностирования
состояния с учетом СППР

Функциональный блок	Описание
Зарегистрировать сообщение	Регистрация сообщения об ошибке
Сформировать решение	Формирование решения по устранению ошибки
Принять решение о необходимом действии	Принятие решения о необходимом действии
Направить решение на исполнение	Принятое СППР решение направляется на исполнение
Исполнить	Инженер-технолог исправляет ошибку
Проверить исполнение	СППР тестирует, а старший инженер проверяет работу системы
Отметить исполнение работы	Отметка об исполнении работ
Сформировать отчет	По итогам проделанных работ формируется отчет

Рисунок 2.3 - Диаграмма декомпозиции главной функции

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

В соответствии с диаграммой на рис. 2.3 входными данными для СППР является список сообщений, а выходными отчет о проделанной работе.

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

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

Компоненты	Наименование	Описание
Наименование подсистемы	Диагностирование состояния технологического процесса производства газобетона	Диагностирование состояния технологического процесса производства газобетона
Внешняя сущность	Logistic	Из программы Logistic поступают сообщения об ошибках
Внешняя сущность	Служба обслуживания газобетонных установок (СОГУ)	СОГУ принимает сообщение об ошибках, предлагает решение и исправляет неполадки в системе
Внешняя сущность	Отдел по контролю за производством	По итогам проделанных работ формируется отчет и направляется в отдел по контролю за производством

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



Рисунок 2.4 - Диаграмма потоков данных (AS-IS) в нотации DFD

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

Таблица 2.4 - Описание декомпозиции DFD процесса диагностирования состояния технологического процесса по производству
газобетона

Компоненты	Наименование	Описание
1	2	3
Процесс	Регистрация сообщения	Поступающие в систему сообщения регистрируются и направляются в БД СППР и СОГУ
Процесс	Формирование решения	По поступившим сообщениям формирует решение БП СППР и СОГУ
Процесс	Выбор из списка решений	По списку решений формируется наиболее оптимальное решение
Процесс	Исполнение решения	После выбора действия в СОГУ направляется запрос на исполнение
Процесс	Исполнение работы	СОГУ назначает ответственное лицо для устранения неполадки
Процесс	Проверка исполнения работы	БП СППР тестирует систему, а СОГУ проверяет систему руководствуясь спецификацией проверки газобетонных установок
Процесс	Отметка исполнения работы	После успешной проверки и тестирования БД СППР записывает отметку о проделанной работе

Рисунок 2.5 - Декомпозиция диаграммы потоков данных (AS-IS)
в нотации DFD

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

2.2 Идентификация требований к СППР

Требования к СППР сформулированы в соответствие с ГОСТ 34.602-89 Техническое задание на создание автоматизированной системы.

Необходимо отметить, что проект «Система поддержки принятия решений по диагностированию технологического процесса производства газобетона» является зависимым. На предыдущем этапе были разработаны ситуационная модель в соответствие с IEEE Std 830-1998 представлены ситуационные модели узлов, основанные на разделение работы системы на режимы. В результате были получены алгоритмы формирования аварийных сообщений из показаний датчиков и исполнительных механизмов нижнего уровня.

Цель создания системы, которая позволит персоналу технологического процесса (ЛПР - лицу, принимающему решения):

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

- по необходимости переключать внимание ЛПР на одну из подсистем технологического процесса производства газобетона;

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

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

- отслеживать процесс управления системы;

- вмешиваться в процесс управления.

Область применения - завод по производству газобетона в г. Агидели.

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

СППР реализуется средствами С# и встраивается в SCADA-систему в виде модуля, вызываемого при нажатии на аварийное сообщение. Она позволяет:

- выявлять аварийные и нештатные ситуации;

- отображать информацию на экране монитора в удобной и понятной для оператора форме;

- выдавать советы по ликвидации нештатных ситуаций, руководствуясь и ссылаясь на стандарты по осуществления технологического процесса;

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

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

- контролировать и регистрировать факт выполнения или невыполнения назначенных работ.

Пользователем системы является оператор.

В результате анализа разработанных во второй главе моделей были сформулированы функциональные требования к СППР. Функциональные требования представлены в виде таблицы режимов (таблица 2.5).

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

Требование	Функции, соответствующие требованию	Ограничения на выполнение
1	2	3
Помощь диспетчеру в принятии решений по состоянию системы. Своевременное включение нужного режима работы системы	Загрузка сообщений об ошибках из Logistic в СППР; Загрузка ранга сообщений об ошибках; Выбор правила по выбору решения; Формирование решений в БП СППР	Время на загрузку возможных решений не должно превышать 1 мин
Своевременное обнаружение аварийной ситуации. Своевременное оповещение оператора. Оповещение оператора о возможных решениях аварийных ситуаций. Помощь в принятии решений в критических ситуациях.	Загрузка сообщений об ошибках из Logistic в СППР; Загрузка ранга сообщений об ошибках; Выбор правила по выбору решения; Формирование решений в БП СППР	Время между возникновением сигнала и сообщения не должно превышать 10 с
Своевременное оповещение о наступлении гарантийных сроков. Своевременное наступление сроков профилактического обслуживания. Контроль технического обслуживания объектов производства.	Исполнение назначенных работ; Исполнение контроля назначенных работ; Учет проверок выполненных работ; Отчет о тестировании;	Реакция оператора на сообщение о необходимости регламентного события не должно превышать 1 часа, выполнение регламентных работ должно завершаться за 24 часа после постановки работы на контроль. Отчет должен быть сформирован не позже, чем через 3 мин после запроса оператора

В результате список функций, который реализует СППР:

- загрузка сообщений об ошибках из Logistic в СППР;

- загрузка ранга сообщений об ошибках;

- формирование решений в СОГУ;

- формирование решений в БП СППР;

- выбор правила по выбору решения;

- выбор решения;

- исполнение назначенных работ;

- исполнение контроля назначенных работ;

- учет тестов систем;

- учет проверок выполненных работ;

- отчет о тестировании;

- отчет о проверке;

- отчет о проделанной работе;

- обнаружение поломки на этапе загрузки сообщений из Logistic;

- обнаружение поломки на этапе формирования решений;

- обнаружение поломки на этапе выбора решений;

- обнаружение поломки на этапе исполнения;

- обнаружение поломки на этапе учета;

- обнаружение поломки на этапе формирования отчета.

2.3 Разработка архитектуры СППР

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

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

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

Компонентами СППР являются:

- база данных;

- база правил;

- алгоритм логического вывода;

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

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

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

- приложение удобно в использовании благодаря готовым шаблонам и эффективным средства;

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

- наличие мастеров для создания тех или иных операций с программой.

База правил - это область памяти, которая содержит совокупность правил в форме правил вида ЕСЛИ - ТО. БП СППР реализована в виде таблицы инструкций в БД, такой подход возможен если есть четкий набор входных данных и к каждому из них предусмотрен конкретный набор инструкций.

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

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

Рисунок 2.6 - Архитектура СППР

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

Одна из основных задач при конструировании СППР - выбор подходящего формального аппарата для описания процесса принятия решений и построение на его базе адекватной (корректной) модели принятия решений (МПР). В качестве такого аппарата обычно используются продукционные системы. В общем виде под продукцией понимают выражение вида: ЕСЛИ А, ТО B.

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

Сильные и слабые стороны систем продукций

Сильные стороны систем продукций:

? модульность;

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

? естественность (вывод заключения в продукционной системе во многом аналогичен процессу рассуждения эксперта);

? гибкость родовидовой иерархии понятий, которая поддерживается только как связь между правилами (изменение правила ведет за собой изменение в иерархии);

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

? простота пополнения и модификации;

? простота механизма логического вывода.

Слабые стороны систем продукций:

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

- сложно представить родовидовую иерархию понятий;

- неясность взаимных отношений правил;

- сложность оценки целостного образа знаний;

- отличие от человеческой структуры знаний;

- отсутствие гибкости в логическом выводе.

БП СППР по диагностированию состояния технологического процесса производства газобетона содержит продукционные правила вида:

ЕСЛИ Сообщение = Узел №10 (отделении приема и склада), дробилка молотковая двухроторная СМД-115 - выходной показатель производительности по материалу снизился на 30%, ТО:

Работа №1 = Остановить работу дробилки молотковой двухроторной СМД-115;

Ответственный = Начальник отдела обслуживания газобетонных установок

ЕСЛИ Сообщение = Работа дробилка молотковой двухроторной СМД-115 остановлена, ТО:

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

Ответственный = мастер отдела обслуживания газобетонных установок - Петров П.П.

ЕСЛИ Сообщение = Заменена специальная решетка предназначенная для просеивания раздробленного материала и дальнейшей переработки нераздробленных кусков материала, ТО:

Работа №3 = Запустить в работу дробилку молотковую двухроторную СМД-115.

Ответственный = мастер отдела обслуживания газобетонных установок - Петров П.П.

ЕСЛИ Сообщение = Запущена дробилка молотковая двухроторная СМД-115 после технических работ, ТО:

Работа №4 = Провести тестирование установки

Ответственный = инженер отдела обслуживания газобетонных установок - Сидоров В.П.

3. Прототипирование СППР по диагностированию технологического процесса производства газобетона

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

3.1 Прототипирование БД СППР

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

- ограничения атрибутов сущностей (таблица 3.1);

- ограничения кортежей (таблица 3.2);

- прочие ограничения (таблица 3.4);

-операционные правила (таблица 3.5);

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



Рисунок 3.1 - Схема данных

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

Имя атрибута или агрегата	Тип	Размер	Границы или допустимые значения	Структура	Условие	Значение по умолчанию
1. ИД сообщения	числовой	-	0..9	1)	-	-
2. Текст сообщения	строковый	-	Аа..Яя	3)	-	-
3. Дата время получения	дата		тек.дата	2)	-	-
4. Номер узла	числовой	-	0..9	1)	-	-
5.Наименование узла	строковый	-	Аа..Яя	3)	-	-
6. ИД инструкции 7. Текст инструкции 8.Трудоемкость инструкции	числовой строковый строковый	-	0..9 Аа..Яя Аа..Яя	1) 3) 3)	-	-
9. ИД вида сообщения 10. Наименование вида сообщения 13. Степень критичности	числовой строковый строковый	-	0..9	1) 3) 3)	-	-
14. ИД оборудования 15.Наименование оборудования 16.Марка оборудования 17.Срок проверки	числовой строковый строковый дата	-	0..9 Аа..Яя Аа..Яя тек.дата	1) 3) 3) 2)	-	-
18. Дата время начала выполнения 19.Факт выполнения	дата строковый		тек.дата Аа..Яя	2) 3) 1)	-	-
20.ИД работы 21. Наименование работы 22.Ответственный за выполнение работы 23.Трудоемкость работы	числовой строковый дата строковый строковый		0..9 Аа..Яя Аа..Яя Аа..Яя	1) 3) 3) 3)	-	-

В таблице 3.1 использованы следующие условные обозначения:

1) поле не должно содержать более 5 цифр. Маска ввода: 00000

2) поле дата должно содержать цифры от 0 до 9, символы {.}. Маска ввода: 00.00.0000

3) ответ (первая буква прописная остальные строчные).

Таблица 3.2 - Ограничения кортежей

Группа атрибутов	Ограничение
1 Номер узла	Ряд натуральных чисел, в котором не долно быть пропусков

Таблица 3.3 - Ограничения уникальности

Группа атрибутов	Среди каких экземпляров имеет место уникальность
1.1 Сообщения. ИД сообщения 1.2 Узел.Номер узла 1.3 Оборудование. ИД оборудования 1.4 Инструкции. ИД инструкции 1.5 Вид сообщения., ИД вида сообщения 1.6 Работа. ИД работы	среди всех сообщений среди всех узлов среди всего имеющегося среди всех имеющихся инструкций среди всех видов сообщений среди всех пработ

Таблица 3.4 - Операционные правила

Событие	Группа атрибутов	Ограничение
1 Удаление или обновление атрибутов, относящихся к персоне	Атрибуты, относящиеся к персоне: Табельный номер, Фамилия, Имя, Отчество, … и т.д.	При удалении записи о какой-либо персоне все сведения о ней переносятся в архивную базу с указанием даты-времени, причины удаления и имени пользователя, выполнившего удаление. Эти сведения хранятся в архивной базе не менее 1 года, а затем могут быть автоматически удалены

На рисунке 3.2 приведен пример таблицы «Сообщения» с тестовыми данными.

Рисунок 3.2 - Тестовые данные таблицы «Сообщения»

На рисунке 3.3 приведен пример таблицы «Вид сообщения» с тестовыми данными:

Рисунок 3.3 - Тестовые данные таблицы «Вид сообщения»

На рисунке 3.4 приведен пример таблицы «Оборудование-узел» с тестовыми данными: