Селиванов Е.В. Математическое и программное обеспечение

ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ БЮДЖЕТНОЕ
ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ
ВЫСШЕГО ПРОФЕССИОНАЛЬНОГО ОБРАЗОВАНИЯ
«РЯЗАНСКИЙ ГОСУДАРСТВЕННЫЙ РАДИОТЕХНИЧЕСКИЙ
УНИВЕРСИТЕТ»
На правах рукописи
Селиванов Евгений Викторович
МАТЕМАТИЧЕСКОЕ И ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ
РАСПРЕДЕЛЁННЫХ ИНФОРМАЦИОННЫХ СЕРВИСОВ
ДЛЯ СИНТЕЗА КОМПОЗИТНЫХ СМЕСЕЙ
С ИСПОЛЬЗОВАНИЕМ ПРИКЛАДНЫХ БАЗ ЗНАНИЙ
Специальность
05.13.11 – «Математическое и программное обеспечение вычислительных машин,
комплексов и компьютерных сетей»
Диссертация
на соискание учёной степени
кандидата технических наук
Научный руководитель:
доктор технических наук, профессор
Каширин Игорь Юрьевич
Рязань 2015
2
ОГЛАВЛЕНИЕ
ОГЛАВЛЕНИЕ ............................................................................................................ 2
ВВЕДЕНИЕ.................................................................................................................. 5
ГЛАВА 1. СОВРЕМЕННЫЕ ПОДХОДЫ К АВТОМАТИЗИРОВАННОМУ
СОСТАВЛЕНИЮ КОМПОЗИТНЫХ СМЕСЕЙ ..................................................... 5
1.1 Задачи поиска оптимальных композитных смесей...................................... 15
1.1.1 Задачи поиска оптимальных величин ..................................................... 15
1.1.2 Постановка задачи поиска оптимальных композитных смесей........... 17
1.2 Математические методы, применяемые для решения задач составления
смесей...................................................................................................................... 18
1.2.1 Задача поиска оптимальной композиции компонентов гофрированного
картона, решаемая на производстве в ЗАО «Многоотраслевая
производственная компания «КРЗ».................................................................. 18
1.2.2 Программа «Рецептура асфальто-бетонной смеси 1.0» ........................ 23
1.2.3 Программа «Автоматизированная система расчета оптимальных
рецептов помольных смесей» (АСР «ОРПС») ................................................ 26
1.2.4 Комплекс программ «КОРАЛЛ» ............................................................. 33
1.3 Анализ математических решений, применяемых в существующих
программных системах автоматизации технологии изготовления смесей ..... 39
1.3.1 Сравнительный анализ оптимизационных методов .............................. 39
1.3.2 Общие недостатки систем составления оптимальных композитных
смесей, связанные с применяемыми математическими моделями и
методами решения.............................................................................................. 40
1.4 Возможности использования ИС для внедрения подходов к составлению
оптимальных композитных смесей...................................................................... 42
1.4.1 Текущее положение информационных технологий .............................. 42
1.4.2 Ключевые особенности SOA и перспективы использования ИС ГС и
SOA в задачах оптимизации композитных смесей......................................... 43
1.4.3 Взаимодействие в системе ИС ГС........................................................... 45
1.4.4 Реестры ИС ГС .......................................................................................... 47
1.4.5 Достоинства и недостатки ИС ГС ........................................................... 47
Основные результаты ............................................................................................... 49
ГЛАВА 2. МАТЕМАТИЧЕСКАЯ ФОРМАЛИЗАЦИЯ ТЕХНОЛОГИИ
ИЗГОТОВЛЕНИЯ КОМПОЗИТНЫХ СМЕСЕЙ................................................... 50
2.1 Обобщенное описание технологического процесса получения смесей с
заданными свойствами.......................................................................................... 50
2.2 Признаковые структуры для описания компонентных веществ смесей и их
свойств .................................................................................................................... 53
2.3 Алгебраическая формализация технологических процессов изготовления
смесей...................................................................................................................... 56
2.3.1 Классы эквивалентности технологических состояний. Кластеры
признаковых структур ....................................................................................... 56
3
2.3.2 Прикладные универсальные алгебраические модели ........................... 59
2.3.3 Свойства отношений прикладных универсальных алгебраических
моделей................................................................................................................ 62
2.3.4 Алгебры технологических цепочек приготовления смесей ................. 63
2.3.5 Свойства операций алгебры технологических цепочек приготовления
смесей .................................................................................................................. 65
2.4 Алгебраическая система технологических цепочек приготовления смесей.
Конструктивные оптимизирующие свойства алгебраической системы.......... 66
2.5 Унификация на множестве выражений алгебраической системы
технологических цепочек ..................................................................................... 68
2.6 Общее описание алгоритма унификации, оптимизирующего синтез
последовательностей технологических операций.............................................. 71
2.7 Схема алгоритма унификации........................................................................ 73
Основные результаты ............................................................................................... 77
ГЛАВА 3. АРХИТЕКТУРА И ПРОЕКТНЫЕ РЕШЕНИЯ
АВТОМАТИЗИРОВАННЫХ СИСТЕМ, ПРИМЕНЯЕМЫЕ В ТЕХНОЛОГИЯХ
ИЗГОТОВЛЕНИЯ КОМПОЗИТНЫХ СМЕСЕЙ................................................... 78
3.1 Основные архитектурные и технические решения, применяемые в
существующих программных системах автоматизации технологии
изготовления смесей.............................................................................................. 78
3.1.1 Программа «Рецептура асфальто-бетонной смеси 1.0» ........................ 78
3.1.2 Программа «Автоматизированная система расчета оптимальных
рецептов помольных смесей» (АСР «ОРПС») ................................................ 81
3.1.3 Программное обеспечение «SMART! Fertilizer Management Software»
.............................................................................................................................. 84
3.1.4 Общие недостатки архитектурных и технических решений,
применяемых в области задач составления смесей........................................ 87
3.2 Базовая архитектура и функциональные задачи интеллектуальной
автоматической системы, основанной на прикладной алгебре
технологических цепочек приготовления смесей .............................................. 88
3.2.1 Концептуальные особенности проектируемой интеллектуальной
системы................................................................................................................ 88
3.2.2 Диаграмма прецедентов............................................................................ 90
3.2.3 Диаграмма компонентов........................................................................... 92
3.2.4 Диаграмма взаимодействия...................................................................... 93
3.3 Алгоритм поиска оптимизированной рецептуры композитной смеси ...... 95
3.4 ТБЗ ИАС ПОС................................................................................................ 100
3.4.1 Структура ТБЗ ИАС ПОС ...................................................................... 101
3.4.2 Алгоритм адаптации ТБЗ ИАС ПОС..................................................... 108
3.4.3 Алгоритм пополнения и обучения ТБЗ ИАС ПОС с использованием
облачных технологий....................................................................................... 113
3.5 Оригинальные проектные решения, применяемые в программном
инструментарии ................................................................................................... 116
3.6 Анализ спроектированной ИАС................................................................... 118
4
Основные результаты ............................................................................................. 119
ГЛАВА 4. АВТОМАТИЗИРОВАННАЯ СИСТЕМА ПОИСКА
ОПТИМИЗИРОВАННЫХ КОМПОЗИТНЫХ СМЕСЕЙ ДЛЯ ПРОИЗВОДСТВА
КАРТОНА ................................................................................................................ 121
4.1 Цель и задачи проектирования автоматизированной системы «Composite-S
v.1.0»...................................................................................................................... 121
4.2 Архитектура автоматизированной системы «Composite-S v.1.0» ............ 122
4.2.1 UML-диаграмма компонентов ПС «Composite-S v.1.0» ..................... 122
4.2.2 Структура ТБЗ «Composite-S v.1.0» ...................................................... 123
4.2.3 Структура БД «Composite-S v.1.0» ........................................................ 126
4.2.4 Выбор средств для разработки............................................................... 128
4.3 Основные классы программного инструментария для реализации задачи
автоматизации в рамках объектно-ориентированного программирования .. 130
4.3.1 Классы моделей ПС «Composite-S v.1.0» ............................................. 131
4.3.2 Классы интерфейсов ИС ПС «Composite-S v.1.0» ............................... 133
4.4 Особенности функционирования автоматизированной системы
«Composite-S v.1.0».............................................................................................. 134
4.4.1 Требования к аппаратно-программному комплексу ПС «Composite-S
v.1.0» .................................................................................................................. 134
4.4.2 Работа с ПС «Composite-S v.1.0» ........................................................... 136
4.5 Оценка эффективности внедрения автоматизированной системы
«Composite-S v.1.0».............................................................................................. 140
4.5.1 Исходные данные и условия экспериментов ....................................... 140
4.5.2 Результаты экспериментов..................................................................... 141
4.5.3 Сравнение функциональных возможностей и характеристик
исследуемых ПС ............................................................................................... 146
Основные результаты ............................................................................................. 149
ЗАКЛЮЧЕНИЕ ....................................................................................................... 150
СПИСОК СОКРАЩЕНИЙ И УСЛОВНЫХ ОБОЗНАЧЕНИЙ.......................... 153
СПИСОК ЛИТЕРАТУРЫ....................................................................................... 154
ПРИЛОЖЕНИЕ 1. ОСНОВНЫЕ КЛАССЫ И СВОЙСТВА ОНТОЛОГИИ
«TechProcess»........................................................................................................... 166
ПРИЛОЖЕНИЕ 2. ИНТЕРФЕЙСЫ ИС ПС «Composite-S v.1.0» ...................... 175
ПРИЛОЖЕНИЕ 3. СВИДЕТЕЛЬСТВО О ГОСУДАРСТВЕННОЙ
РЕГИСТРАЦИИ ПРОГРАММЫ ДЛЯ ЭВМ........................................................ 185
ПРИЛОЖЕНИЕ 4. АКТЫ ВНЕДРЕНИЯ РЕЗУЛЬТАТОВ
ДИССЕРТАЦИОННОЙ РАБОТЫ ........................................................................ 187
5
ВВЕДЕНИЕ
Актуальность темы. Информационные сервисы (ИС) глобальных компьютерных сетей являются одним из важных программных системных элементов, используемых в облачных технологиях. Такие сервисы могут предоставлять пользователям инструментальные ресурсы, дающие возможность не только существенно упростить задачи специалиста в какой-либо предметной области, но и автоматизировать поиск и выборку знаний из других удаленных информационных ресурсов. Решение проблемы накопления и последующего использования специальных знаний в конкретной предметной области лежит в
основе новых подходов к формированию технологических баз знаний (ТБЗ),
являющихся основой математического и системного программного обеспечения (ПО) в комплексах с сервис-ориентированными архитектурами (SOA).
В качестве предметной области для ТБЗ в диссертации рассматривается
оптимизация композитных смесей, как целенаправленный процесс улучшения
технологических характеристик искомого композитного продукта при определённых условиях с учётом разнообразных факторов производства, влияющих
на результат. Архитектура и существующих программных систем оптимизации
смесей устаревает. Существующее ПО, ориентированное на численные математические методы, не может обеспечить требуемый уровень решения задачи о
смесях в условиях неизвестных с заданной точностью параметров. Такими параметрами могут являться: меняющиеся цены на комплектующие компоненты,
наличие принципиальной возможности поставки технологических компонентов, возможность применения технологии и/или ее элементов в условиях специфики конкретного предприятия. Таким образом, задача разработки нового,
основанного на ТБЗ, системного ПО и соответствующего математического
обеспечения, доступного специалистам посредством ИС, является актуальной.
В существующем ПО задача о смесях представляется в терминах математического программирования, включающих целевые функции и ограничения. В
рамках нового подхода целесообразно использовать формализм, позволяющий
6
учитывать особенности технологического процесса, объективно оценивать качество результирующего продукта, оперировать знаниями конкретной предметной области. Базы знаний – одно из самых актуальных направлений в проектировании ПО. Интеллектуальные алгоритмы, оперирующие знаниями, обладают достаточной гибкостью и позволяют решать сложные задачи.
С архитектурной точки зрения, современной и перспективной технологией, позволяющей частично решить основные проблемы задачи оптимизации
смесей, является архитектура SOA. Алгоритмы структурной композиции ИС
актуальны для реализации автоматического пополнения баз знаний, обучения
системы, параллельных вычислений. Последние, в частности, могут быть использованы для уменьшения времени решения задач, имеющих большую размерность.
Степень разработанности темы. Весомый вклад в развитие темы оптимизации многокомпонентных смесей внесли многие отечественные и зарубежные учёные: Е.А. Данильян, Б.Г. Печеный, Ф.Г. Ахмадиев, Р.М. Гильфанов,
А.В. Самойлов, А.В. Кочетков, С.М. Севериненко, Е. И. Конопленко, А.А. Романенко, П.В. Зозуля, О.Б. Рудаков, Г.Г Волокитин, Н.К Скрипникова, В.Л.
Винстон, Д. Парисай, Аллисон Макналти, Франсуа Рюффенак.
Значительных успехов в практической деятельности достигли А.Н. Мерцалов, В.О. Новицкий (кафедра «Автоматизированные системы и вычислительная техника» московского государственного университета пищевых производств), разработавшие программу «Автоматизированная система расчета
оптимальных рецептов помольных смесей». Особого внимания заслуживает
математическая модель, предложенная авторами. Она подробно описывает
задачу оптимизации помольных смесей в терминах целей и ограничений.
Обширная теоретическая и практическая проработка темы была
произведена в «МСХА им. К.А. Тимирязева» Б.В. Лукьяновым и П.Б. Лукьяновым. Ими был разработан комплекс программ «КОРАЛЛ», позволяющий производить расчёт рационов для сельскохозяйственных животных. Программы
7
«КОРАЛЛ» используют для расчёта метод совмещенных двойственных направлений, векторную оптимизацию, а так же метод «Монте-Карло».
Наиболее передовой зарубежной разработкой является система «SMART!
Fertilizer Management Software» (Гай Села, Юзи Кафкафи и др.). Система предназначена для поиска оптимального состава смеси сельскохозяйственных удобрений и использует наиболее современные технические решения (клиентсерверная архитектура, «тонкий клиент») по сравнению с другими программными продуктами.
В то же время, исследования в области автоматизации изготовления смесей направлены, чаще всего, на совершенствование существующих математических методов решения задач линейного программирования. Использование
математических формализмов для ТБЗ, с помощью которых удаётся наиболее
полно описать рассматриваемую задачу конкретной предметной области, в современных исследованиях является новым и до сих пор малоисследованным
направлением.
Объект исследования – программные системы и математическое обеспечение ИС с SOA архитектурой в приложении к оптимизации смесей.
Предмет исследования – архитектура и алгоритмы программных систем
оперирования знаниями в удаленных сервисах.
Целью диссертационной работы является разработка программного
обеспечения, ориентированного на знания и использование облачных технологий, в приложении к процессам изготовления смесей.
Исходя из поставленной цели, были определены следующие основные
задачи исследования.
1. Провести анализ существующих методов решения задач изготовления
смесей, использующихся в настоящее время, с целью выявления проблем при
их применении, определения общих недостатков существующих подходов.
2. Проанализировать текущее положение дел в сфере информационных
технологий и определить основные тенденции развития современных программных систем. Применить полученные данные в проектировании инстру-
8
ментального ПО для поиска в глобальных информационных ресурсах специальных знаний о рецептуре смесей.
3. Создать математическую формализацию для описания знаний о технологических процессах приготовления многокомпонентных смесей. Формализация должна описывать компонентные вещества, их свойства, основные операции составления композиции, технологические ситуации и процессы. Формализация должна обладать конструктивными оптимизирующими свойствами и позволять делать выводы на основе знаний о конкретной предметной области.
4. Проанализировать архитектурные, технические и функциональные решения, применяемые в существующих программных системах поиска оптимизированных смесей. Выявить преимущества и недостатки таких решений с целью определения основных особенностей, которыми должно обладать проектируемое в диссертационной работе инструментальное ПО.
5. Спроектировать структуру ТБЗ для хранения и возможности интеллектуального вывода информации о компонентах смеси, технологических ситуациях и процессах её изготовления.
6. Разработать оригинальные алгоритмы структурной композиции ИС в
контексте SOA для решения задач поиска оптимизированной рецептуры смесей, пополнения, обучения и адаптации ТБЗ.
7. Разработать программную реализацию SOA-системы поиска рецептуры смесей, использующую предложенные в диссертации алгоритмы структурной композиции ИС.
8. Провести экспериментальное сравнение разработанной системы с конкурентным ПО. Выявить достоинства и недостатки спроектированной системы.
Научная новизна.
1. Предложена формализация специальных знаний о технологии изготовления смесей, описывающая компонентные вещества, их свойства, основные
операции составления композиции, технологические ситуации и процессы.
Предложенная формализация позволяет математически строго анализировать
знания о компонентных веществах, их свойствах, технологические ситуации и
9
процессы, делать выводы на основе знаний ТБЗ о конкретной предметной области, а также даёт возможность применять интеллектуальные алгоритмы поиска рецептуры многокомпонентных смесей. Эти свойства являются основой
качественно нового математического подхода к решению задачи построения
ИС с SOA архитектурой.
2. Предложена оригинальная структура ТБЗ для хранения и возможности
интеллектуального вывода информации о компонентах смеси, технологических
ситуациях и процессах её изготовления, а также позволяющая автоматизировать процесс поиска рецептуры композитных смесей в удаленных ИС. Использование предлагаемой структуры ТБЗ является новым технологическим решением в области проектирования ПО.
3. Разработаны алгоритмы структурной композиции ИС для масштабируемой, распределённой системы, основанной на SOA, дающие возможность
повысить эффективность технологии поиска рецептуры композитных смесей.
Предложенные алгоритмы решают задачи поиска оптимизированной рецептуры смесей, пополнения, обучения и адаптации ТБЗ. Проведённые эксперименты показывают уменьшение темпов роста времени поиска рецептуры композитной смеси на 11 – 23 % в зависимости от количества исходных данных, по
сравнению с существующими на данный момент решениями.
Теоретическая значимость. Теоретическая часть диссертационной работы содержит математическую формализацию специальных знаний о технологии, описание структуры ТБЗ, а также ряд алгоритмов структурной композиции
ИС для решения задач изготовления оптимизированных смесей, пополнения,
обучения и адаптации ТБЗ.
Практическая значимость.
1. Предложенная структура ТБЗ универсальна и может быть использована
для широкого круга программных средств (ПС), работающих с понятиями
смежных предметных областей.
10
2. Показана возможность адаптации ТБЗ с помощью разработанного Data
Mining-алгоритма для автоматизированной корректировки расчёта прогнозных
характеристик смеси.
3. Показана возможность автоматического пополнения и обучения ТБЗ с
помощью разработанного алгоритма структурной композиции ИС.
4. Программная реализация ПС «Composite-S v.1.0» показывает эффективность использования разработанных алгоритмов структурной композиции
ИС с элементами облачных технологий для решения задачи поиска оптимизированной рецептуры композитных смесей. SOA, взятая за основу при проектировании ПС «Composite-S v.1.0» позволяет масштабировать систему, используя
механизмы распределения нагрузки, фактически реализуя концепцию облачных
вычислений. Практическая значимость такого технического решения выражается в возможности поиска оптимизированной рецептуры смеси в условиях
большого количества исходных компонентов, а также возможности балансировки соотношения производительности/стоимости системы.
Методы исследования. При решении поставленных в диссертационной
работе задач были использованы элементы теории множеств, теории графов,
теории универсальных алгебр, теории унификации, теории алгоритмов и объектно-ориентированного проектирования.
Основные положения, выносимые на защиту.
1. Формальный аппарат, позволяющий математически строго оперировать
знаниями о компонентных веществах, их свойствах, технологических ситуациях и процессах.
2. Структура ТБЗ для хранения и возможности интеллектуального вывода
новых знаний о компонентах смеси, технологических ситуациях и процессах её
изготовления, позволяющая автоматизировать процесс поиска рецептуры композитных смесей в удаленных ИС.
3. Оригинальные алгоритмы структурной композиции ИС, дающие возможность повысить эффективность технологии поиска знаний о рецептуре.
11
4. Реализация ПС «Composite-S v.1.0», предназначенного для автоматизированного поиска на примере оптимизированного компонентного состава картонов.
Обоснованность и достоверность результатов исследования. Корректность разработанной математической формализации технологии работы со знаниями об изготовлении смесей подтверждается аналитически при решении
прикладных задач оптимизации. Предложенная структура ТБЗ позволяет формировать ограничения задачи поиска оптимизированной рецептуры автоматически, автоматизировать процесс поиска рецептуры, учитывая множество разнообразных факторов специфики производства. Применение SOA гарантирует
расширяемость спроектированной системы и даёт возможность регулировать её
вычислительную мощность. Уменьшение темпов роста времени поиска оптимизированной рецептуры смеси на 11-23% в разработанной программной системе доказывает эффективность предложенных алгоритмов структурной композиции ИС, показывает преимущества применяемых проектных решений.
Достоверность результатов исследования подтверждается также их практической апробацией.
Реализация и внедрение результатов работы. Теоретические и практические результаты научной работы использованы в ЗАО «Многоотраслевая
производственная
компания
«КРЗ» для
составления
оптимизированной
композиции компонентного состава картона, а так же в учебном процессе
ФГБОУ ВПО «Рязанский государственный радиотехнический университет».
Практическая ценность результатов работы подтверждена соответствующими
актами о внедрении. В рамках научного исследования реализовано ПС для
поиска оптимизированной рецептуры смесей «Composite-S v.1.0», что подтверждается свидетельством о государственной регистрации программы для ЭВМ
№ 2015617615.
Апробация работы. Основные положения диссертационной работы отражены в докладах:
12
– Международной научно-практической конференции «Современные тенденции в образовании и науке» (Тамбов, 2012);
– XVII Всероссийской научно-технической конференции студентов, молодых ученых и специалистов «Новые информационные технологии в научных
исследованиях» (Рязань, 2012);
– Международной научно-практической конференции «Современные тенденции в образовании и науке» (Тамбов, 2013);
– Всероссийской научно-практической конференции «Современные проблемы экономики и управления в организации» (Рязань, 2014);
– IX Международной научно-практической конференции «Тенденции
развития современных информационных технологий, моделей экономических,
правовых и управленческих систем» (Рязань, 2014);
– XIX Всероссийской научно-технической конференции студентов, молодых ученых и специалистов «Новые информационные технологии в научных
исследованиях и в образовании» (Рязань, 2014).
Публикации. По теме диссертации опубликовано 16 печатных работ, 12
из них без соавторов. В том числе: 3 статьи в журналах, входящих в перечень
ВАК; 6 тезисов докладов на Международных и Всероссийских конференциях; 1
свидетельство о государственной регистрации программы для ЭВМ.
Личный вклад автора. Все представленные в диссертационной работе
научные результаты и выводы получены лично автором. Автором сформулированы основные идеи математической формализации технологии изготовления
смесей, структуры прикладной ТБЗ и алгоритмов структурной композиции ИС,
предложенных в диссертационной работе. Автором разработано ПС «Composite-S v.1.0», реализующее представленные в диссертационной работе технологии и алгоритмы. Вклад автора в публикации, выполненные в соавторстве, был
определяющим.
Научному руководителю д.т.н., профессору Каширину И.Ю. принадлежит
определение области научного исследования, постановка цели и задач диссертационной работы, руководство процессом проведения научной работы.
13
Соответствие паспорту специальности. Содержание диссертационной
работы соответствует паспорту специальности 05.13.11 – «Математическое и
программное обеспечение вычислительных машин, комплексов и компьютерных сетей»: п.3 «Модели, методы, алгоритмы, языки и программные инструменты для организации взаимодействия программ и программных систем»; п.4
«Системы управления базами данных и знаний»; п.9 «Модели, методы, алгоритмы и программная инфраструктура для организации глобально распределённой обработки данных».
Структура и объём диссертации. Диссертация состоит из введения (10
с.), четырёх глав (135 с., включая 30 рисунков и 16 таблиц), заключения (3 с.) и
четырёх приложений (23 с.). Библиографический список включает 132 наименования (12 с.).
Во введении определяются объект и предмет исследования, его цель и
задачи. Обосновывается актуальность темы, научная новизна, теоретическая и
практическая значимость исследования. Приводятся степень разработанности
темы и основные методы исследования; информация о реализации и внедрении
результатов работы, её апробации, личном вкладе автора, публикациях, сведения о структуре и объёме диссертации.
В первой главе приводится краткий обзор и анализ основных математических методов решения задач оптимизации смесей, используемых в прикладном программном обеспечении на настоящий момент времени. Также были
проанализированы возможности использования ИС для внедрения новых
подходов к составлению оптимальных композитных смесей.
Вторая глава посвящена разработке математической формализации технологии
изготовления
смесей,
описанию
универсальной
алгебры
технологических цепочек приготовления смесей. Приводится общая схема
алгоритма унификации.
В третьей главе приводится краткий обзор и анализ основных
архитектурных и технических решений, применяемых в существующих
программных системах автоматизации технологии изготовления смесей.
14
На основе проведённого анализа определяются функциональные задачи и
проектируется базовая архитектура интеллектуальной автоматической системы,
основанной на прикладной алгебре технологических цепочек приготовления
смесей. Разрабатывается алгоритм структурной композиции ИС для поиска
оптимизированной рецептуры композитной смеси, структура ТБЗ, алгоритмы
адаптации, пополнения и обучения ТБЗ. Выдвигаются оригинальные проектные
решения, применяемые в программном инструментарии.
Четвёртая глава посвящена разработке автоматизированной системы
поиска оптимизированных композитных смесей «Composite-S v.1.0», производится
оценка
эффективности
её
внедрения.
Серией
экспериментов
показывается уменьшение темпов роста времени расчёта оптимизированной
рецептуры смеси в зависимости от размера входных данных по сравнению с
конкурентными программными продуктами.
В заключении приводятся выводы и основные результаты проведённой
научной работы, а так же определяются возможные направления будущих исследований.
В приложении 1 приводятся основные классы и свойства онтологии
«TechProcess» на языке OWL, описывающие структуру разработанной в диссертационной работе ТБЗ.
В приложении 2 приводится описание WSDL-интерфейсов ИС ПС
«Composite-S v.1.0».
В приложении 3 представлено свидетельство о государственной регистрации программы для ЭВМ «Composite-S v.1.0».
В приложении 4 представлены акты внедрения результатов диссертационной работы.
15
ГЛАВА 1. СОВРЕМЕННЫЕ ПОДХОДЫ К
АВТОМАТИЗИРОВАННОМУ СОСТАВЛЕНИЮ
КОМПОЗИТНЫХ СМЕСЕЙ
1.1 Задачи поиска оптимальных композитных смесей
1.1.1 Задачи поиска оптимальных величин
Задачи поиска оптимального значения некоторой величины при соблюдении определённого набора ограничений или требований возникают в самых
различных областях человеческой деятельности: в производстве, сельском хозяйстве, химической, фармацевтической и пищевой промышленности, а так же
в экономических [1,2] и научных [3,4,5] исследованиях.
В общем виде аналитические задачи подобного рода могут быть представлены в виде системы:
ϕ 0 ( x1 , x2 ,..., xn ) → extr
(1.1)
ϕi ( x1 , x2 ,..., xn ) = 0; i = 1,2,..., n
(1.2)
( x1 , x2 ,..., xn ) ∈ G
(1.3)
Здесь ( x1 , x2 ,..., xn ) – вектор переменных; ϕi ( x1 , x2 ,..., xn ) – количественный показатель качества решения или целевая функция (ЦФ); G – множество,
элементы которого обладают определенными свойствами.
Системой ограничений (1.2) и множеством G (1.3) задаётся область допустимых решений. Задача оптимизации требует из всех допустимых решений,
удовлетворяющих ограничениям (1.2) и (1.3), найти такое, которое обеспечивает экстремальное значение ЦФ в зависимости от постановки задачи: минимальное или максимальное.
Задача, сформулированная в виде (1.1) – (1.3), является задачей математического программирования – раздела прикладной математики, исследующего методы поиска условного экстремума функции многих переменных [6].
Отличительной особенностью такой сформулированной в общем виде задачи
является отсутствие общего метода решения, за исключением метода грубой
16
силы или перебора абсолютно всех допустимых решений [7]. При этом, на настоящий момент времени даже для задач относительно небольшой размерности
полный перебор является практически нереализуемой процедурой для современных ЭВМ.
В зависимости от вида функций (1.2) и от вида множества G, задача оптимизации относится к конкретному классу задач математического программирования. Необходимо отметить, что для каждого класса в рамках соответствующего раздела математического программирования используются свои методы решения [6]. Рассмотрим общую классификацию задач математического
программирования.
Задача (1.1) – (1.3) является задачей линейного программирования (ЛП),
если ϕ 0 и ϕi (i = 1,2,..., m) линейные функции параметров управления:
n
n
j =1
j =1
ϕ 0 = ∑ c j x j , ϕi = ∑ aij x j − ai ,
а G – положительный ортант ( x j ≥ 0, j = 1,2,..., n ) или гиперпараллелепипед
( a −j ≤ x j ≤ a +j ; j = 1, n ) евклидова n-мерного пространства. Для линейных моде-
лей характерно свойство аддитивности и пропорциональности.
Задача (1.1) – (1.3) является задачей целочисленного программирования,
если G – некоторое подмножество точек евклидова n-мерного пространства, все
или отдельные координаты которых принимают целочисленное значение.
Задача (1.1) – (1.3) представляет особый подкласс задач целочисленного
программирования, если переменные в ней могут принимать только одно из
двух значений – 0 или 1. Это подкласс задач булевого программирования.
Также выделяют классы задач нелинейного, выпуклого, стохастического
и динамического программирования.
Перечисленные разделы содержат более узкие направления, а также на
практике часто встречаются задачи, обладающие свойствами разных классов,
например, задачи линейного целочисленного программирования с булевыми
переменными (ЛЦПБ) [6].
17
В современном мире большой популярностью пользуются линейные модели. Соответствующий математический аппарат достаточно развит, и широкий
класс реальных объектов управления довольно ясно описывается в терминах
ЛП [8].
Однако, необходимо отметить, что построение математической модели
реальной практической задачи является сложноформализуемым процессом. В
нём можно выделить следующие основные этапы:
- выделение переменных;
- постановка цели – запись ЦФ в терминах переменных;
- построение ограничений – запись соответствующих математических
выражений в терминах переменных;
- определение множества G – спецификация переменных.
1.1.2 Постановка задачи поиска оптимальных композитных смесей
Как частный случай задач оптимизации, постановка задачи о смесях в
общем виде выглядит следующим образом. Пусть имеется n компонентов, при
сочетании которых в разных пропорциях получаются смеси с различными характеристиками. Обозначим через aik и ak количество k-го вещества (k=1,2,…,q
– тип вещества), входящего в состав і-го компонента и в состав смеси соответственно.
Предполагается, что:
n
ak = ∑ aik xi , i = 1, 2,…, n , т.е. зависимость между aik и ak – линейная.
i =1
Через xi (i = 1, 2,…, n) обозначим процентное содержание i-го компонента
в смеси. Также имеется n величин Ci , которые могут характеризовать калорийность, массу, стоимость и др. (в зависимости от требования задачи) i-го компонента, и q величин dk , определяющих минимально необходимое содержание kго вещества в смеси.
Задача принимает вид:
18
n
∑ Ci xi → min
(1.4)
i =1
n
∑ aik xi ≥ d k , k = 1,2,..., q
(1.5)
i =1
n
∑ xi = 1
(1.6)
i =1
Задача (1.4) – (1.6) является примером классической задачи ЛП. В частных случаях задач о смесях, таких как, например, составление оптимальной
композитной смеси, вводят дополнительные ограничения на целочисленность,
а также булевы переменные [9].
Далее рассмотрим основные методы решения задач поиска оптимальных
смесей, применяемые на данный момент технологами производства, а так же
реализованные в специализированных программных системах.
1.2 Математические методы, применяемые для решения
задач составления смесей
1.2.1 Задача поиска оптимальной композиции компонентов гофрированного картона, решаемая на производстве в ЗАО «Многоотраслевая производственная компания «КРЗ»
При производстве гофрированного картона (ГК) перед технологами ЗАО
«Многоотраслевая производственная компания «КРЗ» встаёт задача составления оптимального компонентного состава конечного продукта.
Например, для производства трёхслойного ГК требуется подобрать четыре основных компонента:
−
картон для плоских слоёв (КПС) на внешний слой;
−
бумага для гофрирования (БГ) на промежуточный слой;
−
КПС на внутренний слой;
−
клей.
19
Технолог должен найти оптимальную композицию перечисленных компонентов. При этом он руководствуется техническим заданием, которое регламентирует характеристики конечного продукта. Исходные данные формируются на основе информации о характеристиках компонентов и их стоимости. Целевой функцией обычно выступает минимизация суммарной стоимости компонентов. Также технологу известны формульные зависимости характеристик ГК
от характеристик исходных компонентов [10].
Данная задача является упрощённой (не учитываются разнообразные технологические процессы, такие как нагрев клея и картона, контроль влажности
слоёв и т.д. [11]). Тем не менее, её решение вызывает затруднение при большом
количестве исходных данных.
Метод «ручного расчёта» экспертом
Очень большое количество предприятий, как и ЗАО «Многоотраслевая
производственная компания «КРЗ», до сиих пор используют ручной метод решения задачи составления оптимальной смеси как основной. Причин этому несколько.
Первая из них – сложность формализации задачи составления оптимальной смеси для её записи в пригодном для решения методами ЛП виде. Для решения необходимо определить единственный критерий (ЦФ), многокритериальность значительно усложняет вычисления. Однако, реальные задачи на производстве как правило всегда требуют оптимизации по нескольким критериям:
минимизация затрат, минимизация веса продукта и др. Поэтому возникает дилемма: использовать «грубую» модель, упростить решение и получить менее
точный результат или серьёзно усложнить модель, получив более точное решение.
Вторая причина предпочтения ручного расчёта: при решении задачи составления оптимальной смеси всю работу выполняет человек – специалисттехнолог, имеющий достаточный опыт в конкретной области, знакомый с производством и обладающий всеми необходимыми знаниями. Накопленные зна-
20
ния и опыт помогают эксперту при определённых обстоятельствах превзойти
системы автоматизированного расчёта.
Алгоритм работы технолога ЗАО «Многоотраслевая производственная
компания «КРЗ» выглядит следующим образом.
1) Технолог получает задание, содержащее требуемые характеристики
ГК.
2) Технолог получает информацию о предложениях поставщиков по каждому из интересующих его исходных компонентов.
3) Используя накопленную на предприятии статистику по ранее произведённым продуктам, технолог может выделить похожие по требуемым характеристикам продукты и узнать, из каких исходных компонентов они были произведены. Если поставщики предлагают достаточно схожие по характеристикам
исходные компоненты, и процесс производства не был с тех пор изменён, то,
как правило, технолог останавливается на одном из проверенных ранее вариантов.
4) Если технолога что-либо не устраивает в старых решениях, то он прибегает к ручному расчёту. Имея информацию о характеристиках и ценах на исходные компоненты, технолог, исходя из своего личного опыта и ситуации на
производстве (учитывая самые разнообразные условия вплоть до изменения
влажности в цехе), подбирает различные варианты композиции из самых подходящих, на его взгляд, компонентов.
5) Технолог выполняет расчёт прогнозных характеристик ГК для каждого
варианта композиции. Он использует формулы зависимостей характеристик
конечного продукта от характеристик исходных компонентов, опубликованные
в специализированной литературе [10] или выведенные на производстве из накопленной статистики. При этом технолог отдаёт предпочтение варианту, реализация которого будет наименее затратной.
Получив удовлетворительную композицию, технолог также может проверить свои вычисления с помощью какого-либо метода решения задач ЛП. Как
21
правило, такая проверка имеет малый вес по сравнению с мнением технолога,
так как при этом не учитываются многие факторы реального производства.
После изготовления партии ГК делаются контрольные измерения: характеристики конечного продукта и исходных компонентов пополняют статистику
предприятия, облегчая решение подобных задач в будущем.
К преимуществам данного метода можно отнести непосредственное участие в процессе опытного специалиста и, как следствие, учёт самых разнообразных трудно формализуемых факторов производства, использование накопленной ранее статистики и специализированных для конкретной предметной
области зависимостей.
К недостаткам относится необходимость привлечения высококвалифицированного специалиста в конкретной предметной области. Обычно число таких
людей крайне невелико. Также нужно отметить невысокую скорость решения
задачи и большую долю неопределённости в вопросе оптимальности полученного результата. Технолог стремится в первую очередь получить продукцию с
требуемыми характеристиками, тогда как минимизация затрат и прочие критерии отходят при этом на второй план. При этом человеку физически очень
трудно учесть все характеристики конечного продукта, приоритет отдаётся основным, а некоторая часть при расчётах просто опускается. Формирование вариантов композиции компонентов смеси также является очень трудоёмкой задачей, а при большой размерности задачи составить все варианты вручную вообще не представляется возможным.
Так, если в качестве исходных данных есть n видов КПС, m видов БГ и s
видов клея, то количество вариантов композиции G можно вычислить по формуле:
G=
(n + k − 1)! ⋅ m ⋅ s ,
k!⋅(n − 1)!
(1.7)
где k – набор сочетаний элементов n, k=2 (внешний и внутренний слой КПС).
Первая часть формулы 1.7, описывающая количество комбинаций двух
слоёв КПС, классифицируется в комбинаторике как «сочетание с повторением»
22
и представляет собой k-местные наборы, в которых каждый элемент n может
участвовать несколько раз [12]. Таблица 1.1 иллюстрирует справедливость
формулы 1.7 при n = 3; m = 4; s = 1 (клей для упрощения опустим).
Таблица 1.1 Набор сочетаний компонентов ГК
КПС1 + БГ1 + КПС1
КПС1 + БГ1 + КПС2
КПС1 + БГ1 + КПС3
КПС2 + БГ1 + КПС2
КПС2 + БГ1 + КПС3
КПС3 + БГ1 + КПС3
КПС1 + БГ2 + КПС1
КПС1 + БГ2 + КПС2
КПС1 + БГ2 + КПС3
КПС2 + БГ2 + КПС2
КПС2 + БГ2 + КПС3
КПС3 + БГ2 + КПС3
КПС1 + БГ3 + КПС1
КПС1 + БГ3 + КПС2
КПС1 + БГ3 + КПС3
КПС2 + БГ3 + КПС2
КПС2 + БГ3 + КПС3
КПС3 + БГ3 + КПС3
КПС1 + БГ4 + КПС1
КПС1 + БГ4 + КПС2
КПС1 + БГ4 + КПС3
КПС2 + БГ4 + КПС2
КПС2 + БГ4 + КПС3
КПС3 + БГ4 + КПС3
В ячейках таблицы перечислены все возможные комбинации компонентов для случая, когда последовательность слоёв КПС не имеет значения, т.е.
любой КПС может пойти как на внешний слой ГК, так и на внутренний.
Таблица 1.1 имеет размерность 4 x 6, количество комбинаций соответственно
равно 24. Подставив n = 3; m = 4; s = 1 в формулу 1.7 получим:
G=
(n + k − 1)! ⋅ m ⋅ s = (3 + 2 − 1)! ⋅ 4 ⋅ 1 = 4! ⋅ 4 = 24 ⋅ 4 = 24 .
k!⋅(n − 1)!
2!⋅(3 − 1)!
2!⋅2!
4
Если предположить, что последовательность слоёв КПС имеет значение,
то при тех же n = 3; m = 4; s = 1 набор комбинаций примет следующий вид.
Таблица 1.2 Набор размещений компонентов ГК
КПС1 + БГ1 + КПС1
КПС1 + БГ1 + КПС2
КПС1 + БГ1 + КПС3
КПС2 + БГ1 + КПС1
КПС2 + БГ1 + КПС2
КПС2 + БГ1 + КПС3
КПС3 + БГ1 + КПС1
КПС3 + БГ1 + КПС2
КПС3 + БГ1 + КПС3
КПС1 + БГ2 + КПС1
КПС1 + БГ2 + КПС2
КПС1 + БГ2 + КПС3
КПС2 + БГ2 + КПС1
КПС2 + БГ2 + КПС2
КПС2 + БГ2 + КПС3
КПС3 + БГ2 + КПС1
КПС3 + БГ2 + КПС2
КПС3 + БГ2 + КПС3
КПС1 + БГ3 + КПС1
КПС1 + БГ3 + КПС2
КПС1 + БГ3 + КПС3
КПС2 + БГ3 + КПС1
КПС2 + БГ3 + КПС2
КПС2 + БГ3 + КПС3
КПС3 + БГ3 + КПС1
КПС3 + БГ3 + КПС2
КПС3 + БГ3 + КПС3
КПС1 + БГ4 + КПС1
КПС1 + БГ4 + КПС2
КПС1 + БГ4 + КПС3
КПС2 + БГ4 + КПС1
КПС2 + БГ4 + КПС2
КПС2 + БГ4 + КПС3
КПС3 + БГ4 + КПС1
КПС3 + БГ4 + КПС2
КПС3 + БГ4 + КПС3
Таблица 1.2 имеет размерность 4 x 9, количество комбинаций соответственно равно 36. Такой набор классифицируется в комбинаторике как «размещение с повторением» [13] и вычисляется по правилу умножения [14], а формула расчёта для рассматриваемого примера принимает вид:
23
G = n k ⋅ m ⋅ s = 32 ⋅ 4 ⋅ 1 = 9 ⋅ 4 = 36
(1.8)
Таким образом, для реальной размерности задачи, когда, например, n =
80; m = 60; s = 15; количество комбинаций для расчёта будет очень большим –
5 760 000. В этом случае, если человек потратит на расчёт и оценку каждой
комбинации в среднем 30 секунд, то для полного перебора ему потребуется работать непрерывно 2000 суток или примерно пять с половиной лет. Именно поэтому для решения задач поиска оптимальных смесей часто применяются автоматизированные системы расчёта.
1.2.2 Программа «Рецептура асфальто-бетонной смеси 1.0»
Разработчик: Роман Ухов [15].
Программа предназначена для расчёта минеральной части асфальтобетонной смеси. Математическую модель, используемую в программе можно записать следующим образом:
n
∑ Ci xi → min
(1.9)
i =1
n
∑ f s ( xi ) ≥ d s , s = 1,2,..., q
(1.10)
i =1
n
∑ xi = 1 ,
(1.11)
i =1
где xi – материал (щебень, песок, минеральный порошок и др.), i приобретает
значения от 1 до n, n – количество материалов, Ci – стоимость тонны i-го материала, ds – значение свойства s результирующей асфальтобетонной смеси, q –
количество свойств смеси по заданному пользователем стандарту качества, fs(xi)
– функция линейной зависимости, выражающая влияние свойств материала xi
на свойство s асфальтобетонной смеси.
Целевая функция (1.9) направлена на минимизацию стоимости результирующей смеси [15]. Ограничения (1.10) отражают заданный пользователем
уровень качества асфальтобетонной смеси. Задача (1.9) - (1.11) является одной
24
из классических задач ЛП, для решения которых используются широко известные математические методы.
Симплекс-метод. Симплекс-метод является одним из наиболее известных во всём мире и был описан множество раз в различных отечественных
[3,4,6,7,16,17] и зарубежных [18,19] изданиях. В связи с этим, опустив подробности, рассмотрим обобщённую блок-схему алгоритма (рисунок 1.1) на примере программного обеспечения для нахождения оптимальной асфальтобетонной
смеси.
Рисунок 1.1 – Алгоритм симплекс-метода в задаче нахождения оптимальных
асфальтобетонных смесей
25
Практическое применение симплекс-метода для решения задач ЛП и в
частности задач поиска оптимальных смесей сопряжено с определёнными проблемами и способами их решения.
Например, если в системе ограничений задачи отсутствует полный набор
единичных векторов, вопрос нахождения исходного опорного решения и коэффициентов разложения векторов по базису этого решения несколько осложняется. В общем случае, когда задача имеет каноническую форму, и в системе
ограничений отсутствует полный набор единичных векторов, для нахождения исходного решения, которому соответствует единичный базис, используется специальный метод, получивший наименование «метод искусственного базиса». Он основывается на использовании вычислительной процедуры самого
симплекс-метода.
Также, ввиду того, что количество базисов, соответствующих опорным
решениям любой задачи ЛП, конечно, после некоторого числа переходов от
одного опорного решения к другому, возможно возникновение такой ситуации,
когда очередное опорное решение будет иметь базис, который фигурировал ранее. Эта ситуация называется зацикливанием. В настоящее время уже разработан ряд способов защиты от зацикливания, например, лексикографический метод.
Ещё одним недостатком симплекс-метода является потребность в большом объёме оперативной памяти для вычислений и крайне высокая чувствительность к размерности задачи [6]. Так, например, практика решения оптимизационных задач показывает, что количество исходных материалов (компонентов) может быть очень велико. Применительно к рассматриваемой программе
«Рецептура асфальто-бетонной смеси 1.0» это могут быть различные виды
щебня, песка, цементной пыли, минерального порошка и др. При этом похожие
компоненты от разных поставщиков могут иметь разную стоимость при незначительных различиях в характеристиках [20]. Современный рынок материалов
очень велик и это становится серьёзнейшей проблемой при решении рассматриваемых в работе задач.
26
1.2.3 Программа «Автоматизированная система расчета оптимальных рецептов помольных смесей» (АСР «ОРПС»)
Авторы: А.Н. Мерцалов, к.т.н. МГУПП, В.О. Новицкий, д.т.н. МГУПП
(кафедра «Автоматизированные системы и вычислительная техника» Московского государственного университета пищевых производств) [21].
Система предназначена для поддержки принятия решений по планированию зерновых ресурсов для мукомольного производства. Часть системы, отвечающая за поиск оптимальных помольных смесей, имеет следующую математическую модель:
∑∑ m jh (S h + Ch ) → m
j h
∑ αi ∑
i
j
∑ m jh Rhi
h
RiK ∑ m jh
min
jh ,m jh ∈N ⋅d
−1 →
, h = 1, H , j = 1, J ;
min
m jh ,m jh∈N ⋅d
(1.12)
, i = 1, I , j = 1, J ;
(1.13)
h
∑∑ m jh → m
j
h
max
jh , m jh ∈N ⋅d
, i = 1, I , j = 1, J ;
 = 0 ,если ∆t h > TM
m jh 
, h = 1, H , j = 1, J ;
>
0
,
если
∆
t
≤
TM

h
(1.14)
j −1
TM = ∑ τ j + ∆τ h ;
j =1
m jh − B ∑ m jh ≥ 0 , j = 1, J ;
(1.16)
h
∑ m jh − M t ≥ 0,
j = 1, J ;
(1.17)
h
∑ m jh (C L − Ch ) ≥ 0,
j = 1, J ;
(1.18)
h
1,если m jh > 0
ϕ jh = 
, j = 1, J ;
0 ,если m jh = 0
∑ ϕ jh ≤ Q ,
j = 1, J ;
(1.19)
h
∑ m jh (Rhi − RiL ) ≥ 0, i = 1, I ,
j = 1, J ;
∑ m jh (RiP − Rhi ) ≥ 0, i = 1, I ,
j = 1, J ;
h
h
V ( VidPom ,∑ m jh ,V K ) − V K ≥ 0 , j = 1, J ;
h
(1.15)
(1.20)
(1.21)
(1.22)
27
∑ m jh (A f
)
− U hf ≥ 0 , j = 1, J ,
h
(1.23)
где mjh – масса h-ой партии зерна, вводимой в j-ый рецепт смеси на заданном
периоде времени, j = 1, J , h = 1, H ; J – количество помольных смесей для определённого периода времени; H – количество доступных партий зерна; Ch–
стоимость h-ой партий зерна; Sh – транспортные издержки на доставку выбранного объема h-ой партии зерна. I – показатели качества зерна; α i – коэффициент значимости i -го показателя качества зерна; d – точность дозирования; Rhi –
значение i-ого показателя качества h-ой партии зерна, i = 1, I ; RiK – базисное
значение i показателя качества зерна, i = 1, I ; ∆t h – время с начала заданного
периода до начала поступления h -ой партии зерна на предприятие; τ j – время
работы на j-ой помольной смеси; ∆τ h – время подготовки h-ой партии для подачи в производство; B – минимальная доля ввода компонента в смесь; Mt – масса
зерна, необходимая для выработки в определённом периоде времени; CL – плановое значение стоимости 1 тонны зерна; ϕ jh – показатель использования h-ой
партии для j-го рецепта смеси на заданном периоде времени (1 – использовать,
0 – не использовать), ϕ jh = {0;1}; Q – число дозаторов; RiL – нижняя граница
значения показателя качества зерна i; RiP – верхняя граница значения показателя качества зерна i; VidPom – вид помола; VK – общий базисный выход продукции; V – функция расчета выходов продукции (рассчитывается по отношению к
базисному VK); Uhf – показатель принадлежности h-ой партии к f-признаку,
U hf = {0;1} ; Af – процент ввода пшеницы, обладающей f-признаком [22].
В рассмотренной модели можно выделить следующие критерии:
−
минимальная стоимость смеси (1.12);
−
минимальное отклонение показателей качества смеси (1.13);
−
максимальный размер партии (1.14).
Модель также содержит ряд ограничений:
28
−
время поступления партии зерна (1.15);
−
минимальный процент ввода компонента в смесь (1.16);
−
масса помольной смеси (1.17);
−
средневзвешенная стоимость смеси (1.18);
−
число компонентов в смеси (1.19);
−
средневзвешенные показатели качества (1.20, 1.21);
−
выход продукции (1.22);
−
ввод зерна различных классов или районов произрастания (1.23).
Задача (1.12) - (1.23) многокритериальна, а значит решить её с помощью
известных методов математического программирования в исходном виде не
представляется возможным. Авторы приводят задачу оптимизации помольной
смеси к однокритериальной путём записи ряда критериев в ограничения [22] и
предоставляя пользователю перед расчётом право выбора только одного из
трёх критериев оптимизации (1.12, 1.13, 1.14).
Математическая модель содержит требования целочисленности (1.19), а
также некоторые признаки нелинейности: дробно-рациональность (1.13), кусочно-линейность (1.13, 1.22) и неподчинение закону аддитивности в смеси для
некоторых показателей качества (1.20, 1.21). В связи с этим потребовалось преобразовать математическую модель с помощью линеаризации ограничений
(1.20, 1.21) по формуле Пертена, для ограничения «выход продукции» (1.22)
выявлены диапазоны значений при использовании функции, как линейного
критерия. Дробно-рациональный критерий (1.13) был линеаризован с помощью
преобразования в кусочно-линейную функцию разложением в ряд Маклорена и
последующей ее линеаризации с помощью вспомогательных ограниченийравенств. Проведенные преобразования позволили использовать для решения
задачи поиска оптимальной помольной смеси двойственный симплекс метод и
метод ветвей и границ [22].
29
Двойственный симплекс-метод
Двойственный симплекс-метод подобен обыкновенному симплекс-методу
и столь же хорошо описан в литературе как зарубежных [18,19] так и отечественных [3,4,6,7,16,17] авторов.
Реализуя поиск оптимальной помольной смеси с помощью метода ветвей
и границ, совмещённого с двойственным симплекс-методом, алгоритм АСР
«ОРПС» в начале своей работы находит решение задачи (1.12) - (1.23) без учёта
условий целочисленности переменных.
Находится псевдоплан задачи, которым является вектор ~
x = (~
x1 , ~
x2 ,..., ~
xn )
(
)
~
с базисом B = Ai1 , Ai 2 ,..., Ai m , такой, что удовлетворяет системе ограничений
(1.15) - (1.23) и ненулевым координатам которого соответствует базис матрицы,
построенной из коэффициентов левой части системы ограничений (1.15) (1.23), если оценки всех векторов неотрицательны.
Алгоритм последовательно переходит между псевдопланами в сторону
уменьшения значения одной из выбранных пользователем ЦФ (1.12, 1.13, 1.14)
задачи (1.12) - (1.23), выполняя следующие основные шаги.
1. Подобным симплекс-методу образом находятся коэффициенты разло~
жения всех векторов по базису B и все элементы xij i = 1,m; j = 0 ,n записыва-
(
ются
в первую симплекс-таблицу.
После
)
этого вычисляются оценки
∆ j ( j = 1,2 ,..., n ) и значение ЦФ Z0.
(
)
2. Если все xk 0 = ~
xi k ≥ 0 , k = 1,m , то считается, что получено оптимальное
решение текущей задачи. Если решение целочисленное, алгоритм АСР «ОРПС»
передаёт управление методу ветвей и границ для поиска лучшего целочисленного решения, или останавливает процесс поиска, если текущее решение удовлетворяет всем требованиям. Если решение не целочисленное, алгоритм АСР
«ОРПС» формирует новую подзадачу (ветвь), дополняя систему ограничений
текущей задачи, избавляясь таким образом от нецелочисленности одной из переменных, и передаёт управление методу ветвей и границ.
30
3. Поочередно просматриваются все элементы xkj, для которых xk0 < 0. Ес-
(
)
ли обнаруживается, что для некоторого xk0 < 0 все xkj ≥ 0 , j = 1,n , то текущая
задача не имеет допустимых решений. Алгоритм передаёт управление методу
ветвей и границ для перехода к другой ветви задач.
4. Выбирается один из коэффициентов xr 0 < 0 , (r ∈ {1,2 ,...,m}) , максималь-
ный по абсолютной величине, что, как правило, приводит к ускорению решения задачи. Для всех xrj < 0 , ( j ∈ {1,2 ,..., n}) вычисляются отношения ∆ j / x rj . Из
этих отношений выбирается минимальное по абсолютной величине. Допустим,
это будет ∆ s / xrs , что соответствует вектору As.
5. Алгоритм АСР «ОРПС» переходит к новому псевдоплану с новым ба-
зисом: базисный вектор Air заменяется свободным вектором As. С использованием основных формул пересчитываются коэффициенты разложения всех векторов, вычисляются новые оценки свободных векторов и новое значение ЦФ.
Далее выполняется шаг 2.
Этот процесс в программе АСР «ОРПС» продолжается до тех пор, пока координаты очередного псевдоплана станут неотрицательными или будет
установлен факт неограниченности снизу выбранной ЦФ (1.12, 1.13, 1.14) двойственной задачи. В последнем случае будет установлен факт отсутствия допустимых решений задачи текущей ветви, построенной методом ветвей и границ.
При использовании двойственного симплекс-метода основные вычислительные сложности системы АСР «ОРПС» связаны с определением исходного псевдоплана. Однако двойственный симплекс-метод в части основной вычислительной процедуры считается более экономным, чем обычный симплекс-метод [6].
Метод ветвей и границ
Алгоритм метода ветвей и границ широко известен и был описан множеством как зарубежных [18,19], так и отечественных [3,6,16,17] авторов. Этот
метод в системе АСР «ОРПС» реализует идею замены полного перебора на-
31
правленным, эвристическим поиском допустимых решений – комбинаций компонентов помольной смеси. Эффект достигается за счет массового отсеивания
«бесперспективных» вариантов. Для реализации поиска допустимых решений в
методе ветвей и границ может быть взят за основу какой-либо классический
метод решения, такой как симплекс-метод, модифицированный симплекс-метод
и др. В рассматриваемом примере поиска оптимальной помольной смеси системы АСР «ОРПС» это место занимает двойственный симплекс-метод, рассмотренный выше.
Алгоритм программы оперирует следующими основными понятиями, которые можно записать в общем виде:
F ( x ) → min
(1.24)
x ∈G .
(1.25)
Здесь (1.24) – одна из ЦФ (1.12, 1.13, 1.14), выбранная пользователем; G –
множество допустимых решений – комбинаций компонентов помольной смеси;
x – элемент множества G. Рекордом R= F(x') называется наименьшее из известных на конкретный момент времени значение, которое принимает ЦФ (1.24) на
некотором допустимом решении x′ ∈ G .
Алгоритм метода ветвей и границ системы АСР «ОРПС» состоит из следующих шагов.
1. Создаётся множество G, на первой итерации состоящее из одного найденного двойственным симплекс-методом решения.
2. В предварительно очищенный список задач S заносится множество G:
S={G}. В качестве рекорда R берётся достаточно большое положительное чис-
ло M.
3. Для каждого подмножества списка S вычисляются нижние границы
(оценки) ЦФ (1.24) на G. Нижняя граница – это такое число η (G) (или η (G')),
что для ∀x ∈ G имеет место F(x) ≥ η (G). При этом оценки вычисляются только
для тех подмножеств, для которых они не вычислялись ранее. Система АСР
«ОРПС» для вычислений использует двойственный симплекс-метод.
32
4. Сортируются в порядке возрастания оценок и последовательно анализируются подмножества списка S и вычисленные для этих подмножеств оценки.
Например, рассматривается очередное подмножество G* . Если G * = O/ ,
( )
это подмножество удаляется из списка S. Если η G* ≥ R , то G* также удаляется из S как «бесперспективное». Если G* – одноэлементное подмножество, или
( ) ( )
установлено, что на некотором решении x* ∈ G* имеет место η G* = F x* < R ,
( )
фиксируется новый рекорд: R = F x * .
Таким образом, алгоритм АСР «ОРПС» очищает список от всех «бесперспективных» подмножеств.
5. Если список пустой ( S = O/ ), то исходная задача (1.12) - (1.23) не имеет
решения.
6. Из списка выбирается подмножество с минимальной оценкой G min .
Если G min – одноэлементное подмножество, или установлено, что на не-
(
) (
)
котором решении X min ∈ G min имеет место η G min = F X min , то получено оптимальное решение. Алгоритм поиска оптимальной помольной смеси прекращает работу, возвращая найденный рецепт.
7. Алгоритм программы разбивает подмножество G min на ряд новых подмножеств, исключая нецелочисленные переменные с помощью ввода новых ограничений. Эти подмножества заносятся в список S, после чего выполняется
шаг 3.
В процессе работы по алгоритму метода ветвей и границ разбиению подлежат подмножества с минимальной оценкой. Важно то обстоятельство, что оставшиеся в списке подмножества не отбрасываются (если, конечно, они не признаются бесперспективными). Дело в том, что нижняя граница может оказаться
недостижимой: просто не существует такого решения, на котором значение ЦФ
совпадает с нижней границей, а вычисление достижимой границы весьма трудно реализовать [6].
33
1.2.4 Комплекс программ «КОРАЛЛ»
Комплекс программ разработан в «МСХА им. К.А. Тимирязева» Б.В.
Лукьяновым, П.Б. Лукьяновым [23].
В комплекс компьютерных программ оптимизации рационов для сельскохозяйственных животных входят программы:
−
«КОРАЛЛ – Кормление птицы»;
−
«КОРАЛЛ – Кормление молочного скота»;
−
«КОРАЛЛ – Кормление свиней»;
−
«КОРАЛЛ – Кормление овец»;
−
«КОРАЛЛ – Кормление выращиваемого скота».
Алгоритм поиска оптимальных кормовых смесей в перечисленных программах основывается на модификации классической задачи о рационе. В модель были внесены следующие основные изменения:
−
учет в модели дисбаланса рациона и, как следствие, экономических
потерь;
−
нелинейные функции потерь заменяют жёсткие ограничения на со-
держание компонентов питания в корме;
−
вводится мера экономической эффективности рациона;
−
несколько критериев оптимизации: минимизация стоимости рацио-
на, максимизация прибыли, максимизация продуктивности, максимизация показателей воспроизводства и сохранности животных;
−
вводится мера общей сбалансированности рациона;
−
линейный метод решения задачи заменяется на нелинейный [24].
Основным отличием от классической задачи о рационе в комплексе программ «КОРАЛЛ» является возможность многокритериальной оптимизации
кормовой смеси.
34
Векторная оптимизация
Реальные производственные задачи оптимизации редко бывают однокритериальными. Обычно технологи сталкиваются с проблемой выбора одного,
самого важного критерия из многих, руководствуясь политикой предприятия. В
рассматриваемом комплексе программ «КОРАЛЛ» также есть несколько целевых функций: минимизация стоимости рациона, максимизация прибыли, максимизация продуктивности, максимизация показателей воспроизводства и сохранности животных [23, 24].
Одним из способов разрешения проблемы многокритериальности рассматриваемых задач является векторная оптимизация, представляющая собой
процесс одновременной оптимизации нескольких конфликтующих целевых
функций на заданной области определения [25, 26]. В комплексе программ
«КОРАЛЛ» для оптимизации используется глобальный критерий, состоящий из
множества локальных [27], а задача записывается следующим образом:
W (a ) = f (ПР(а ), У об (а ), С рац (а ), СБ (а ))
(1.26)
W (a ) → max
(1.27)
a∈ A
(1.28)
«… где A – варианты рациона, рассматриваемые как альтернативы;
W(a) – значение глобального критерия, соответствующего рациону a;
ПР(a) – прибыль, получаемая от конверсии кормов рациона a в продукцию;
Уоб(a) – удой, обеспечиваемый рационом a;
Срац(a) – стоимость рациона a;
СБ(a) – сбалансированность рациона a;
f – некоторая функция от значений компонентов векторного критерия» [27].
Производится скаляризация векторного критерия. Локальные критерии
нормируются, так как имеют существенные различия в единицах измерения и
шкалах. Нормирование производится путём деления текущего значения на максимально возможное. Пользователь программного комплекса «КОРАЛЛ» может задать весовые коэффициенты для локальных критериев, в зависимости от
35
их важности для каждой конкретной задачи. В итоге, глобальный критерий записывается следующим образом:
W (a ) = λ1пр(а ) + λ 2 уоб (а ) − λ 3 с рац (а ) + λ 4 сб (а ) ,
(1.29)
«… где пр(α), уоб(α), срац(α), сб(α) – нормированные значения локальных критериев; λ1, λ2, λ3, λ4 – весовые коэффициенты соответствующих локальных критериев» [27].
Недостатком данного метода является наличие возможных ситуаций, при
которых решение, оптимизирующее глобальный критерий, неудовлетворительно для одного или нескольких локальных критериев: при достижении максимума целевой функции значения некоторых показателей компенсируются значениями остальных [25]. Также к недостаткам можно отнести большую долю
допущения в процессе расстановки весовых коэффициентов для локальных
критериев, правильность расстановки сильно зависит от технолога.
Метод совмещенных двойственных направлений
Для решения задачи оптимизации кормовой смеси в комплексе программ
«КОРАЛЛ» используется специализированный метод совмещённых двойственных направлений, являющийся нелинейным [24]. Этот метод представляет собой модификацию метода прямого поиска Хука-Дживса [28] и заключается в
поиске пары переменных, которая за счёт одновременного уменьшения и увеличения их значений позволяет получить большую скорость спуска функции
f ( x ) на каждом шаге алгоритма.
Для последовательного приближения к решению задачи оптимизации в
комплексе программ «КОРАЛЛ» используется формула:
xk +1 = xk + (a ki p i − akj p j ) ,
*
(1.30)
где aki , a kj – скалярные множители, соответствующие длине шага по осям i и j;
p1 , p 2 , ..., p n – базис E n -пространства; (aki p i − akj p j ) – пара, определяющая
*
уменьшение и увеличение значений переменных по осям i и j.
36
Для нахождения пары (aki p i − akj p j ) используется минимальное значение
*
функции f ( x ) , вычисляемой следующим образом:
*
f ( x ) = min({ f (xk + (a i p i − a j p j )) i ∈ [0 ,n ]; j ∈ [0 ,n]; i # j})
(1.31)
f ( x ) → (a i p i − a j p j )
(1.32)
*
*
*
Множители a i и a j определяются через следующие выражения:
i
∆ ⋅ xmax
a = i
 xmax − xki
i
j
∆ ⋅ xmax
a = j
 xmin − xkj
j
i
i
) ≤ xmax
при (xki + ∆ ⋅ xmax
i
i
) > xmax
при (xki + ∆ ⋅ xmax
j
) ≤ xminj
при (xkj + ∆ ⋅ xmax
при (x + ∆ ⋅ x
j
k
j
max
)> x
j
min
,
«… где ∆ – заданная относительная точность определения значений переменi
ных вектора x; xmax
– максимально допустимое значение i-той переменной;
j
xki – значение i-той переменной на k-том шаге оптимизации; xmin
– минимальj
но допустимое значение j-той переменной; xmax
– максимально допустимое
значение j-той переменной; xkj – значение j-той переменной на k-том шаге оптимизации; x 0 – фиктивная переменная, введена для обеспечения возможности движения функции f ( x ) только по одному из направлений: p i или p j ;
0
0
x 0 = xmin
= xmax
= 0 » [24].
Алгоритм решения задачи оптимизации кормовой смеси в комплексе программ «КОРАЛЛ» представлен далее. На блок-схеме (рисунок 1.2) дополнительно используются следующие обозначения: x* – вектор независимых переменных, соответствующий текущему минимальному значению функции; F –
текущее минимальное значение функции f ( x ) ; за базисную точку принимаi
i
) / 2, i = 1,2,...,n .
ется x i = (xmin
+ xmax
37
Рисунок 1.2 – Алгоритм решения задачи оптимизации кормовой смеси в комплексе программ «КОРАЛЛ»
По сравнению с прототипом – методом прямого поиска Хука-Дживса метод
совмещенных
двойственных направлений, иcпользуемый в комплексе
программ «КОРАЛЛ», за меньшее время решения обеспечивает большую на-
38
дежность в поиске глобального оптимума [24]. Так же метод-потомок в большей или меньшей степени перенимает некоторые положительные и отрицательные качества метода-прототипа, а именно:
− небольшой объём требуемой памяти по сравнению со стандартным
симплекс-методом;
− циклическое движение по координатам может стать причиной вырождения алгоритма в бесконечную последовательность исследующих поисков [29].
Сравнивая нелинейный метод оптимизации кормовой смеси, используемый в комплексе программ «КОРАЛЛ» с рассмотренными ранее более распространёнными линейными методами, можно сделать вывод о том, что для него
так же остро стоит проблема большой размерности задачи.
Метод Монте-Карло
Комплекс программ «КОРАЛЛ» позволяет произвести поиск оптимальной кормовой смеси методом Монте-Карло. При этом программа расчёта, используя генератор случайных чисел, многократно выбирает произвольные значения масс компонентов, в заданном диапазоне – от минимума до максимума.
Полученные случайные кормовые сочетания алгоритм анализирует на соответствие оптимальному рациону, проводится проверка на выполнение ограничений [30].
От пользователя требуется выбрать желаемые компоненты и указать число попыток генерации. При достаточно большом количестве попыток и удачном стечении обстоятельств, алгоритму программ «КОРАЛЛ» удаётся найти
сочетания компонентов, в большей или меньшей степени близких к оптимальным. Эти сочетания запоминаются и по окончании работы алгоритма выдаются
пользователю для анализа и оценки.
Метод Монте-Карло реализуется достаточно просто, однако не гарантирует получение результата даже при очень большом количестве попыток генерации. Вместе с тем, увеличение количества попыток серьёзно сказывается на
39
времени расчёта. Однако размерность исходной задачи имеет меньшее влияние
на время расчета по сравнению с другими математическими методами [31].
При умеренном количестве компонентов рациона и 7 000 000 000 попыток генераций среднее время расчёта в программах «КОРАЛЛ» может составлять 45-60 минут [30].
1.3 Анализ математических решений, применяемых в
существующих программных системах автоматизации
технологии изготовления смесей
1.3.1 Сравнительный анализ оптимизационных методов
На основании информации, предоставляемой во многих отечественных
[3,4,6,7,16,17,24,] и зарубежных [18,19,31] источниках составим наглядную таблицу (таблица 1.3) для сравнения рассмотренных выше математических методов.
Таблица 1.3 Характеристики математических методов
Характеристики
Время до получения приемлеТребования к Чувствительность
мого результата
объёму операк размерности
Метод
при большой
тивной памяти
задачи
размерности задачи
Прогнозируемое,
Полный переУниверсальный
Огромные
Огромная
неприемлемо
бор вариантов
большое
Метод МонтеСложноУниверсальный
Большие
Пониженная
Карло
прогнозируемое
СимплексЛинейный
Большие
Большая
Большое
метод
Двойственный
симплексЛинейный
Пониженные
Большая
Приемлемое
метод
Метод ветвей
Дискретный
Пониженные
Большая
Приемлемое
и границ
Метод
совмещенных
Нелинейный
Невысокие
Большая
Небольшое
двойственных
направлений
Тип (возможность решения
задач определённого типа)
40
В таблице приведены относительные оценки, выражающие преимущества
того или иного метода по отношению к остальным. Оценивая характеристики
рассмотренных математических методов с практической точки зрения, можно
сделать вывод о том, что основной проблемой является чувствительность к
размерности задачи. Относительно небольшое время решения на практике может оказаться неприемлемо большим. Бороться с этими негативными особенностями нужно с помощью качественно нового математического формализма и
достаточно эффективной программной архитектуры, позволяющей сократить
время решения задач подобного класса.
1.3.2 Общие недостатки систем составления оптимальных композитных смесей, связанные с применяемыми математическими моделями
и методами решения
Недостатки рассмотренных систем в большинстве случаев одинаковы или
весьма схожи. Часть минусов существующих ПС связана с используемой математической моделью и методами решения задач, которые, несмотря на всё своё
разнообразие, имеют одинаковые проблемы и ограничения.
В той или иной степени определённые недостатки нивелируются в зависимости от метода решения, но основные проблемы остаются. Избежать их
полностью с помощью существующих методов математического программирования не представляется возможным.
1. Влияние размерности задачи. Время расчёта увеличивается пропорционально увеличению размерности задачи. Размерность подразумевает под
собой большое количество исходных данных (например, компонентов смеси) и
ограничений. Особенно остро эта проблема проявляется в задачах комбинаторного типа: несмотря на конечность множества допустимых комбинаций G,
мощность этого множества для реальных задач столь высокая, что прямой перебор для поиска оптимальной комбинации становится нереализуемым. Например, в задаче о назначениях G = n!; в задаче о коммивояжере G = (n-1)! [6].
Даже при относительно небольшой размерности задачи нахождение оптималь-
41
ного решения может занять слишком продолжительное время, в том числе и
при использовании для расчёта мощной современной ЭВМ. Например, надстройка «Solver» в MS Excel может выполнять поиск решения максимум для
двухсот неизвестных [3, 32], при этом реальные задачи часто могут иметь
большую размерность, что может занимать большое время даже при использовании методов математического программирования, которые позволяют существенно сократить количество перебираемых вариантов.
2. Многокритериальность модели. Реальные задачи в большинстве своём
– многокритериальны [33]. Однако для решения их методами ЛП возникает необходимость привести такие задачи к однокритериальным (например, записав
часть критериев в ограничения или другим методом), либо прибегнуть к помощи ЛПР, предварительно проведя оптимизацию для всех критериев по отдельности. Практика показывает незаменимость человека в таких ситуациях, поскольку адекватность прочих средств для устранения этой проблемы остаётся
на довольно низком уровне [34].
3. Сама концепция существующей математической постановки оптимизационной задачи и рассмотренные методы её решения не предполагают учёта
особенностей технологического процесса, хотя именно технологический процесс стоит в основе производства смесей, а конечный продукт всецело зависит
от него. В настоящее время существует множество различных технологий приготовления смесей, различного оборудования, реализующего тот или иной технологический процесс, позволяющих из одних и тех же исходных компонентов
получить совершенно разные по качеству продукты. Как следствие этого, очевидна необходимость в качественно новом математическом формализме, хорошо подходящем для описания предметной области приготовления композитных
смесей.
42
1.4 Возможности использования ИС для внедрения подходов
к составлению оптимальных композитных смесей
1.4.1 Текущее положение информационных технологий
В настоящее время всё большую популярность набирают ИС глобальных
сетей (ГС) и построенные на SOA облачные технологии. Так, на сегодняшний
момент облачные технологии постепенно вытесняют с рынка обычные «настольные» приложения, и продолжают уверенно закреплять свои позиции. Часто человек даже не подозревает, что работает с облачным сервисом [35]. Рост
популярности ИС обусловлен целым рядом весомых преимуществ, получаемых
при использовании SOA.
Однако, в сфере производства и, в частности, в области производства
композитных продуктов, новые информационные технологии (ИТ) используются в очень малом объёме, либо используются технологии прошлых десятилетий [36]. По большей части предприятия используют для расчётов узкоспециализированные «настольные» приложения, либо более общие решения с использованием табличного процессора MS Excel. Также иногда для решения задачи
по составлению оптимальных композитных смесей вообще не используется никаких ПС, кроме обыкновенного калькулятора, а весь процесс расчёта от начала
и до конца выполняет человек – технолог производства.
Кроме того, все предшествующие расчёту и последующие за ним действия никак не автоматизированы – их также выполняет человек. Это такие трудоёмкие задачи, как сбор информации о продукции, предлагаемой поставщиками, её изучение и отбор, форматирование данных для расчёта, запись и хранение статистических данных по проведённому расчёту. Предприятия, даже в
рамках единой отрасли, осуществляют коммуникацию старыми, знакомыми
способами, такими, как звонки по телефону и почтовые пересылки, e-mail, а в
лучшем случае информация о продукции размещается на своей странице в Интернете или на сайте объявлений. При этом опубликованная информация обновляется крайне редко и быстро утрачивает свою актуальность. Также эта информация представлена в не слишком удобном виде, отсутствует унификация и
43
какой-либо единый формат, что в свою очередь сказывается на эффективности
такого способа взаимодействия [36].
Все обозначенные проблемы можно достаточно эффективно решить при
построении развёрнутой системы, реализующей весь потенциал SOA.
1.4.2 Ключевые особенности SOA и перспективы использования ИС
ГС и SOA в задачах оптимизации композитных смесей
SOA (англ. service-oriented architecture) – это особая парадигма проектирования сложных распределённых систем. SOA использует модульный подход
к разработке ПС, заключающийся в создании сети удалённых слабосвязанных
ИС со стандартизованными интерфейсами и протоколами взаимодействия [37].
ИС, входящие в систему на основе SOA, могут располагаться как в локальных сетях, так и в ГС. При этом каждый отдельный ИС, фактически, представляет собой «чёрный ящик» (рисунок 1.3), получающий для обработки некоторые данные и выдающий пользователю результат. Пользователь знает, что
делает сервис, но не знает, как именно он делает свою работу. Такое положение вещей оправданно при быстром росте технологий, когда уследить за всем
сразу невозможно. В целях экономии своего времени имеет смысл переложить
часть большой задачи на специализированный ИС. Это – естественное решение, возникшее в ходе эволюции разработки программного обеспечения, такое
же, как распределение труда в обществе [35]. За счёт этой особенности решается так же проблема повторного использования кода.
Для ПО, решающего задачи оптимизации смесей, описанное архитектурное решение является чрезвычайно выгодным, так как настройка и обновления
системы происходят совершенно незаметно для пользователя. Администратор
может «безболезненно» скорректировать алгоритм поиска решения, изменив
всего один модуль системы, которым является ИС, не затронув другие. В этом
заключается свойство заменимости ИС.
44
Рисунок 1.3 – Общая схема взаимодействия с ИС
Приведённая схема является общей. SOA подразумевает обширную разветвлённую сеть ИС, обладающую большим уровнем глобализации. Так, на
месте пользователя (рисунок 1.3) может находиться ещё один сервис, взаимодействующий с уже существующим ИС.
Высокий уровень глобализации сервис-ориентированных систем позволяет с лёгкостью осуществлять межорганизационное взаимодействие на любых
уровнях [38]. Такие особенности SOA, как автоматизация построения связей
между ИС и их композиции; оптимальное сочетание последовательного и параллельного типа композиции ИС позволяют решать сложные задачи, такие как
поиск оптимальных композитных смесей с исходными данными большой размерности.
Решения на основе SOA могут быть максимально тесно интегрированы с
ключевыми процессами и операциями любых задач оптимизации для получения гибкой, безопасной и экономически выгодной бизнес-системы [39].
45
1.4.3 Взаимодействие в системе ИС ГС
Для информационного обмена, описания веб-служб и типов данных в системах ИС взят за основу текстовый формат – XML: «Язык XML (Extensible
Markup Language) - фундамент, на котором строятся веб-сервисы» [40]. Язык
является расширяемым и не фиксирует разметку в документах: разработчик
может создать собственную разметку в соответствии с условиями, диктуемыми
конкретной областью работ. Компоненты смеси, их характеристики, композиции и многие другие вещи этой предметной области могут быть достаточно
полно описаны в XML.
Текстовый формат помог преодолеть проблемы совместимости ПС, не
только написанных на различных языках программирования (ЯП), но и разработанных для совершенно разных операционных систем (ОС), платформ и архитектур [41]. Ранее компонентные технологии, такие как COM (Component
Object Model) и CORBA (Object Request Broker Architecture), дававшие разработчикам функции для многократного применения двоичных объектов и их
взаимодействия между различными компьютерами, использовали для коммуникации протоколы, основанные на бинарном представлении передаваемых
данных [42]. Этот подход был причиной больших сложностей совместимости
даже тех программных компонентов, которые были написаны на одном ЯП.
Текстовый формат решил эту и многие другие проблемы межпрограммного
взаимодействия, во многом благодаря тому, что XML-документ довольно легко
воспринимается человеком.
На базе языка XML компаниями Microsoft и IBM был разработан язык
описания веб-сервисов (Web Services Description Language, WSDL) – формат
XML-схем, определяющий расширенную структуру описания интерфейсов ИС
[40]. С помощью WSDL могут быть описаны типы данных, передаваемых в сообщениях, как атомарные (числа, строки) так и сложные, составные (массив,
структура, объект класса). Также WSDL описывает функции ИС, предоставляемые пользователям и способ доступа к ним. Язык описания ИС – общепринятый стандарт, являющийся своеобразным компромиссом в области человеко-
46
машинного взаимодействия. XML-документ может быть понятен и человеку и
интерпретатору программного приложения.
Переход к текстовому описанию ИС способствовал развитию протокола
SOAP (Simple Object Access Protocol – простой протокол доступа к данным),
реализующего механизм подключения к сервисам. Его спецификация описывает структуру сообщений, используемых для обмена форматированными XMLданными в распределённой вычислительной среде, как локальной, так и глобальной [43]. SOAP обеспечивает транспорт базового уровня. На его основе могут возводиться более сложные протоколы и способы взаимодействия.
Часто встречаются системы, которые отходят от каноничного протокола
SOAP и стандарта WSDL, разрабатывая собственные, упрощённые интерфейсы
или API. «API — интерфейс прикладного программирования (или интерфейс
программирования приложений). Это - набор готовых классов, процедур,
функций, структур и констант, предоставляемых приложением (библиотекой,
сервисом) для использования во внешних программных продуктах. API определяет функциональность, которую предоставляет программа (модуль, библиотека). При этом API позволяет абстрагироваться от того, как именно эта функциональность реализована» [44]. Компании, использующие API, стремятся облегчить взаимодействие со своими ИС путём уменьшения передаваемой информации в сообщениях. Они переносят описание сервиса, его интерфейса и
методов взаимодействия на страницы ресурса, посвящённого этому ИС.
Ещё одним способом уменьшения количества передаваемой информации
при обмене сообщениями в среде ИС является замена более громоздкого XML
на формат JSON (англ. JavaScript Object Notation). Этот формат также является
текстовым, но в отличие от XML существенно легче воспринимается людьми.
Несмотря на происхождение от JavaScript, формат считается языконезависимым и может использоваться практически с любым ЯП. К тому же для многих
языков уже существует готовый код для создания и обработки данных в формате JSON. Применительно к веб-приложениям, JSON хорошо зарекомендовал
47
себя в задачах обмена данными как между браузером и сервером (AJAX), так и
между самими серверами через программные HTTP-интерфейсы [45].
Несмотря на некоторые проблемы, такие как, например, передача бинарных и медиа-файлов в системах ИС ГС, прочные позиции занимает информационный обмен, основанный на текстовых форматах передаваемых сообщений.
1.4.4 Реестры ИС ГС
ИС, составляющие основу SOA, могут быть сильно рассредоточены по
всей ГС, у них могут быть совершенно разные адреса и интерфейсы. При таком
положении вещей поиск нужного сервиса для решения какой-либо задачи может быть как очень долгим, так и безрезультатным. Это следует из того, что
даже современные поисковые системы, такие как Google, обладают не слишком
эффективным алгоритмом поиска веб-сервисов [46].
В качестве решения этих проблем в августе 2000 года был предложен
стандарт UDDI (англ. Universal Description Discovery & Integration) – средство
для расположения описаний ИС (WSDL) для последующего их поиска различными организациями и интеграции в свои ПС. Инициативу создания UDDI реестров поддержали большие компании, такие как IBM, Microsoft, SAP, HP и другие. UDDI содержат описание ИС, их адреса в сети, интерфейсы, wsdl-описания
и другую информацию для доступа к сервисам. В настоящее время реестры ИС
из общедоступных каталогов с множеством тематик превратились в узкоспециализированные закрытые сервисы, которые используются для нужд каждой
отдельно взятой системы, построенной на SOA [46].
1.4.5 Достоинства и недостатки ИС ГС
Основные проблемы SOA кроются в способе передаче информации между ИС ГС. ИС обмениваются сообщениями в текстовом формате, определённом
стандартом WSDL или API конкретной системы. Для любого подобного формата в большей или меньшей степени встаёт проблема избыточности. Однако в
48
настоящее время существуют способы, не выходящие за рамки стандартных
протоколов, позволяющие уменьшить объём передаваемой информации путём
её сжатия [47].
Ещё одна трудность состоит в том, что текстовый формат сообщений не
приспособлен для передачи бинарных данных – медиа файлов и пр. Эта проблема может быть решена путём использования для передачи двоичных данных
через другие протоколы, что не составляет труда на данный момент при текущем уровне развития информационных технологий ГС.
Одним из главных достоинств SOA является возможность практически
неограниченного масштабирования системы. Как следствие этого открываются
широкие перспективы использования параллельных вычислений для решения
задач большой размерности, дополнения системы новыми сервисами при необходимости. Распределённая система ИС ГС может обеспечивать большую надёжность хранения данных и стабильность работы за счёт дублирования информации и своих составных частей в ГС.
SOA в целом имеет большое значение для бизнеса и процессов, происходящих в нём [48]. Необходимо отметить, что поиск оптимальной композитной
смеси – это не только сам расчёт, а гораздо более объёмный процесс, включающий в себя поиск необходимых компонентов и их поставщиков, влекущий
за собой межорганизационное взаимодействие. Система ИС ГС, построенная по
принципам SOA, позволяет решить эти и другие проблемы. Такая система
представляет собой совершенно новый взгляд на ПО, разрабатываемое для решения задач оптимизации производства, и способное вывести процесс поиска
оптимальных композитных смесей на качественно новый уровень.
49
Основные результаты
В первой главе диссертационной работы были получены следующие результаты.
1.
Освещены основные особенности задач поиска оптимальных сме-
сей, выявлены основные проблемы этой предметной области.
2.
Рассмотрены основные математические методы решения задач со-
ставления оптимальных смесей, используемые существующими программными
системами.
3.
Проведён сравнительный анализ основных математических мето-
дов, используемых для поиска оптимальных композитных смесей.
4.
Выявлены недостатки существующих систем составления опти-
мальных композитных смесей, связанные с применяемыми для их решения математическими методами.
5.
Освещено современное состояние развития и возможности сервис-
ориентированных технических решений, основанных на взаимодействии посредством ГС.
6.
Выявлены возможности использования ИС для внедрения подходов
к составлению оптимальных композитных смесей.
50
ГЛАВА 2. МАТЕМАТИЧЕСКАЯ ФОРМАЛИЗАЦИЯ
ТЕХНОЛОГИИ ИЗГОТОВЛЕНИЯ КОМПОЗИТНЫХ
СМЕСЕЙ
2.1 Обобщенное описание технологического процесса
получения смесей с заданными свойствами
Для решения задачи поиска смеси с заданными характеристиками [49]
при известных исходных данных необходимо разработать соответствующий
математический формализм. Этот формализм должен быть основан на концепции анализа исходных данных и имеющихся технологий. Цель – синтез и оптимизация новых технологий, с помощью которых могут быть получены улучшенные характеристики результирующей смеси. Настоящая глава посвящена
созданию такого формализма на основе теории множеств [50], теории графов
[51] и теории универсальных алгебр [52].
Получение нового механизма изготовления смесей [49] основано на:
−
исследовании исходных материалов,
−
анализе характеристик результирующего материала (смеси),
−
анализе существующих технологических цепочек изготовления
смесей,
−
синтезе новой технологической цепочки, обеспечивающей требуе-
мое качество продукта.
Каждый этап технологического процесса характеризуется исходными для
этого этапа компонентными веществами, а так же результирующими веществами. Все они имеют множество характеристик, позволяющих идентифицировать
материал по качественным и количественным показателям [53]. Так, например,
для группы картонов результирующими характеристиками могут быть: удельный вес (граммаж), толщина, деформирование при увлажнении, деформирование при высушивании, абсолютное сопротивление продавливанию, сопротивление сжатию на коротком расстоянии [54] и т.п.
51
Таким образом, можно выделить два основных множества-универсума
[50,55], в пределах которых будут находиться все используемые в производстве
смесей материалы и характеристики этих материалов, а именно:
−
конечное множество компонентных веществ и их соединений:
Cs = {c1 ,ci ,...,cn },
−
{
}
конечное множество свойств веществ: Pr = p1 , p j ,..., pk .
Каждому компонентному веществу (материалу) ci из Cs, будет соответствовать некоторое подмножество Pri ⊆ Pr [53].
В рамках этих обозначений каждый этап (например, на шаге с номером
m) технологического процесса представляет собой получение из первоначального для этого этапа подмножества компонентных материалов Csm ⊆ Cs нового
подмножества Csm+1 ⊆ Cs. При этом характеристики, определяющие рабочие
свойства материалов также будут принадлежать соответствующим подмножествам Prm ⊆ Pr и Prm+1 ⊆ Pr.
Весь технологический процесс целиком, состоящий, например, из r шагов
будет содержать цепочку ϕ преобразований рассмотренных подмножеств:
ϕ : Cs1 , Pr1 → Cs2 , Pr2 → ... → Csr −1 , Prr −1 → Csr , Prr ,
где «→» – отношение строгого предшествования [50,56], а Csi , Pri
(2.1)
(i = 1,...,r ) –
пара определенных ранее подмножеств компонентных веществ и их характеристик соответственно [53].
Цепочка ϕ, фактически, является готовым решением задачи, которая может быть сформулирована следующим образом: получить последовательность
технологических шагов, приводящих от первоначальных условий
Cs1 , Pr1 к
заключительному решению Csr , Prr . Сложность задачи заключается в том,
что такая последовательность заранее неизвестна [53]. Также, часто неизвестными могут являются и некоторые промежуточные этапы. Некоторые из них
могут быть предварительно получены на ранних этапах производства и составить соответствующую ТБЗ [57]. В то же время, существует возможность полу-
52
чить недостающие в готовых решениях этапы из различных сторонних источников, которые содержат не только готовые решения, но и знания об особенностях взаимодействия более простых компонентных веществ и технологиях их
соединения.
В итоге, общую задачу синтеза технологического процесса получения
смесей с заданными свойствами можно сформулировать следующим образом.
«Для заданных исходных компонентных материалов (веществ) и их характеристик Cs1 , Pr1 и известных результирующих материалов и их характеристик, а также множества решений «→» получить технологическую цепочку
ϕ (2.1), позволяющую реализовать все составляющие ее процессы (шаги) в условиях конкретного производства [58]. При отсутствии готовых компонентных
решений в ТБЗ синтезировать эти решения из частных, ранее полученных на
других производствах».
< Cs11, Pr11 >
< Cs1n , Pr1n >
< Csr1, Prr1 >
< Csrn , Prrn >
Рисунок 2.1 – Множество технологических цепочек производства
Рисунок 2.1 содержит графическое представление множества всех известных в ТБЗ цепочек технологических процессов. Кружками здесь обозначены текущие состояния, достигаемые во время реализации технологического
процесса в результате выполнения действий, обозначенных стрелками. В самом
общем случае считается, что все состояния уникальны. Далее в настоящей главе будут рассмотрены частные разновидности графов технологических процессов.
53
2.2 Признаковые структуры для описания компонентных
веществ смесей и их свойств
В предыдущем параграфе было рассмотрено описание множеств компонентных веществ и свойств (характеристик) этих веществ, не учитывающее их
внутренней структуры. Внутренняя структура компонентов играет решающую
роль в определении зависимостей свойств результирующих продуктов при выполнении производственных операций над исходными материалами смесей
[10].
Для описания внутренней структуры характеристик веществ и их соединений целесообразно использовать структуры признаков [59]. Структуры признаков – это математический формализм, объединяющий основы реляционного
[60], фреймового [61] и логического [62] подходов в рамках механизма иерархически вложенных кортежей [63]. Структуры признаков являются более общими структурами, чем, например, исчисление предикатов. Основные отличия
заключаются в следующем:
−
структуры, размеченные символически, не включают явных пози-
ций аргументов;
−
для этих структур не требуется определять фиксированную мест-
ность (как это было в функциях и предикатах теорий первого порядка);
−
устраняются все различия между функциями и их аргументами;
−
переменные и ссылки обрабатываются отдельно.
Признаковую структуру сj ∈ Cs для описания компонентных веществ
можно представить с помощью кортежа неопределенной местности, имеющего
поименованные элементы [58]:
c j = ( N1 : Pr1 , N 2 : Pr2 ,..., N i : Pri ,..., N n : Prn ) ,
(2.2)
где Ni - имя из универсума имен элементов N, а Pri - значение из множества
возможных значений Pr .
54
В качестве примера можно привести описание одного из компонентов
производства картона с определенными свойствами. Пусть, например, множество имен N задано следующим описанием:
N = { “Class”, “Name”, “pH”, “Amount”,
“Unit of measure”, “Concentration” },
для каждого из имен задана своя область значений, например, для Class:
PrClass = {“Исходный материал”, “Компонентное вещество”,
”Результирующий материал” },
а для pH: PrpH = {0.0, …, 100.0}.
Тогда компонентное вещество ”Cульфитный щелок” можно описать следующей признаковой структурой c1 :
c1 ( Class: Компонентное вещество
Name: Cульфитный щелок
pH: 8,0
Amount: 1000,0
Unit of measure: граммы ) .
Структуру “Нейтрализатор формальдегида” можно описать таким образом:
c2 ( Class: Компонентное вещество
Name: Нейтрализатор формальдегида
Amount: 10,0 ).
Признаковые структуры могут быть вложенными друг в друга, например:
c12 (Class: Исходный материал
( Class: Компонентное вещество
Name: Cульфитный щелок
pH: 8,0
Amount: 1000,0
Unit of measure: граммы )
( Class: Компонентное вещество
55
Name: Нейтрализатор формальдегида
Amount: 10,0 ) ).
Если на множестве всех признаковых структур ввести операцию их композиции « o » [64], имеющую сложную семантику [65], описанную специальным
алгоритмом взаимодействия материалов и веществ, то можно считать, что приведенные в предыдущих примерах признаковые структуры могут быть элементами следующего равенства:
c12 = c1 o c2 .
(2.3)
Таким образом, рассмотренная операция последовательной композиции
позволяет формировать из элементов множества Cs технологические последовательности, рассмотренные ранее в п. 2.1:
ϕ : Cs1 → Cs2 → ... → Csr −1 → Csr .
(2.4)
Здесь множество Pr можно опустить, так как свойства веществ уже учтены в признаковых структурах Csi (i = 1,...,r ) . Отличием является лишь то, что в
технологической цепочке ϕ указываются только множества компонентных веществ Csi, для которых неизвестен алгоритм получения результата взаимодействия веществ и материалов.
Использование признаковых структур позволяет определять семантику
операций взаимодействия веществ и материалов, и, следовательно, автоматически получать результат операции в виде множества новых признаковых структур [58]. Например, можно определить компонентное вещество c3 «Ортофосфорная кислота»:
(Class: Компонентное вещество
Name: Ортофосфорная кислота
Concentration: 2,4% ) .
56
Если для операции композиции « o » определить правило взаимодействия
кислот и щелочей, то можно получить более сложное равенство, отражающее
преобразования свойства с именем «pH»:
c13 = c1 o c3 = ( Class: Компонентное вещество
Name: Cульфитный щелок pH: 6,4 Amount: 1000,0
Unit of measure: граммы ).
2.3 Алгебраическая формализация технологических
процессов изготовления смесей
2.3.1 Классы эквивалентности технологических состояний. Кластеры
признаковых структур
Как было определено в п. 2.1 и п. 2.2 настоящей главы, технологические
состояния при формальном описании технологий приготовления смесей могут
быть представлены множеством признаковых структур. Любое из этих множеств можно представить также одной единственной структурой, включающей
в себя все элементы множества как подструктуры (п. 2.2). Рисунок 2.1 графически представляет пространство возможных технологических цепочек преобразования исходных компонентных веществ и материалов в результирующие вещества и материалы. Эти процессы представлены в более или менее подробной
последовательности выполнения технологических операций.
Выбор последовательности операций, равно как и степени подробности
их описания сильно зависит от технолога, управляющего этими процессами, а
так же от имеющихся на производстве материалов и оборудования. При выборе
наиболее эффективной технологической цепочки технолог руководствуется
следующим базовым набором критериев:
– наличие компонентных веществ на складе или возможность их приобретения у поставщиков,
– наличие оборудования, позволяющего реализовать технологический
процесс на практике,
57
– допустимая граница себестоимости производственной операции, включая цену материалов, энергетические и трудовые затраты,
– допустимая граница времени производственного процесса,
– другие технологические условия.
Последний пункт указывает на то, что список критериев в общем случае
является открытым и может корректироваться как в сторону увеличения подробности, так и в сторону дополнения новыми критериями в зависимости от
процессов модернизации производства.
Важно также и то, что либо вся технологическая цепочка полностью, либо отдельные ее фрагменты могут быть реализованы на производстве различными способами. Следовательно, такие цепочки можно представить графически как более сложную сеть, чем сеть, приведенная в п. 2.1 (рисунок 2.1). В частности, такая сеть может содержать кроме последовательных еще и альтернативные ветви (рисунок 2.2).
Cs11
Cs12
Cs111
Cs112
Cs121
Cs113
Csr1
Csr2
Cs122
Cs11n
Cs12n
Cs1n
Csrn
Cs13n
Рисунок 2.2 – Графическое представление сети, имеющей параллельные дуги,
соответствующие альтернативным технологическим цепочкам
58
Из рисунка следует, что, например, ветвь
Cs11 → Cs111 → Cs112
→ Cs113
→
Csr1
может быть заменена эквивалентной ей ветвью
Cs11 → Cs111 → Cs121 → Cs122 → Cs113 → Csr1 ,
а конкретнее, эквивалентными являются лишь звенья
Cs112 и Cs121 → Cs122 .
Стоит отметить, что вряд ли в реальной практике найдутся такие эквивалентные цепочки, что даже при минимальном различии в технологическом
процессе они дадут при одинаковых начальных значениях один и тот же результат. Следовательно, говорить можно лишь о приблизительном равенстве
входных и выходных состояний альтернативных технологических цепочек. Однако, технолог, руководствуясь критериями эквивалентности, может отнести их
к равным. Таким образом, можно сделать вывод том, что некоторые из технологических состояний могут иметь равные им состояния с некоторой допустимой погрешностью. Эта погрешность может быть определена формально, т.е.,
например, с помощью предельных значений каких-либо характеристик, содержащихся в соответствующей признаковой структуре. Также она может быть задана технологом с помощью простого перечисления эквивалентных признаковых структур.
Определение 2.1 Множество состояний технологического процесса называется классом эквивалентности, если свойства, описанные элементами соответствующих признаковых структур, эквиваленты с погрешностью, заданной
заранее определенными предельными значениями.
Также, кроме тех состояний, которые уже ранее встречались технологу,
или уже содержатся в ТБЗ, со временем могут появиться новые состояния, попадающие в те же рамки значений свойств. Так как новые состояния еще не
идентифицированы на практике, они являются виртуальными и принадлежат
некоторой области n-мерного пространства с семантической метрикой [66], где
59
по осям обозначаются имена Ni количественных и качественных признаков, а
делениями шкалы являются значения этих признаков. Для качественных признаков при этом должна быть подобрана подходящая численная нумерация.
Общее число признаков для n-мерного пространства равно n (рисунок 2.3).
Определение 2.2 Виртуальная область n-мерного пространства с семантической метрикой называется кластером (cj) состояния технологического процесса, если она ограничена лишь предельными значениями заранее заданных
свойств, описанных элементами признаковой структуры.
N1
N2
cj+1
cj
Ni
Nn-1
Nn
Рисунок 2.3 – Кластеры виртуальных состояний технологических процессов в
n-мерном пространстве с семантической метрикой
2.3.2 Прикладные универсальные алгебраические модели
Алгебраической моделью в теории универсальных алгебр является некоторое множество-носитель, представляющее собой универсум элементов прикладной предметной области с заданным на этом множестве набором отношений [52].
В прикладной области приготовления смесей базовым множеством целесообразно принять множество подмножеств материалов и компонентных веществ, задействованных в технологических процессах. Ранее это множество
было обозначено как Cs. Элементами этого множества являются вещества и ма-
60
териалы ci ∈ Cs. Для исследования свойств компонентных веществ необходимо
иметь возможность сравнивать их, а так же проверять на наличие характеристик, которые могут быть обнаружены при взаимодействии с другими веществами. Математическая формализация сказанного может быть выражена с помощью записи соответствующих отношений. Далее идет перечисление основных из них.
1) Выделенное отношение эквивалентности « ≡ ».
Определение 2.3 Два подмножества веществ из универсума Cs считаются эквивалентными ( ci ≡ cj ) , если согласно определению 2.2, эти подмножества
принадлежат одному и тому же кластеру виртуальных состояний технологических процессов в n-мерном пространстве с семантической метрикой.
2) Отношение неравенства.
Определение 2.4 Два подмножества веществ ci и cj
из универсума Cs
считаются неравными, если отношение ( ci ≡ cj ) не выполняется, т.е. эти подмножества не принадлежат отношению эквивалентности. Этот факт записывается как ( ci ≠ cj ).
3) Отношение общности
Определение 2.5 Два подмножества веществ ci и cj
из универсума Cs
считаются находящимися в отношении общности ( ci ≈ cj ), если они имеют общие составляющие, т.е. ci ∩ cj ≠ ∅, где « ∩ » - операция пересечения множеств, а « ∅ » - пустое множество.
4) Отношение независимости
Определение 2.6 Два подмножества веществ ci и cj
из универсума Cs
считаются независимыми, если отношение ( ci ≈ cj ) не выполняется, т.е. эти
подмножества не принадлежат отношению общности. Этот факт записывается
как ( ci ⊥ cj ).
5) Отношение следования
Определение 2.7 Два подмножества веществ ci и cj
из универсума Cs
считаются находящимися в отношении следования ( ci → cj ), если из состояния
61
технологического процесса ci существует нетривиальная технологическая цепочка, ведущая в cj и являющаяся транзитивным замыканием отношения «→».
Для определения 2.7 следует добавить, что тривиальной считается технологическая цепочка, в которой результирующие вещества и материалы просто
вводятся в качестве готовых составляющих, не являющихся результатом взаимодействия первоначальных элементов.
6) Отношение антиследования
Определение 2.8 Два подмножества веществ ci и cj из универсума Cs
считаются находящимися в отношении антиследования, если отношение (ci →
cj ) не выполняется, т.е. эти подмножества не принадлежат отношению следования. Этот факт записывается как ( ci # cj ).
Таким образом, отношение антиследования означает, что на текущий момент времени ТБЗ не содержит знаний о возможности построения нетривиальной технологической цепочки, ведущей из ci в cj.
7) Отношения критериальной последовательности
Это – особый подвид отношений, позволяющий производить сравнение в
рамках одного определенного кластера, соответствующего некоторому критерию оценки качества смеси (п. 2.3.1). Таких отношений вводится ровно столько, сколько известно критериев оценки качества. Множество этих отношений
можно обозначить единым знаком «≥i », имея при этом в виду, что индекс i
пробегает значения от 1 до N, где N – число критериев оценки качественных и
других характеристик смеси. Например, это могут быть: цена, трудоемкость
производства, интегральная характеристика качества, определяющая потребительские свойства результирующего материала.
Для задания семантики таких отношений базовое множество Cs разбивается на подмножства-кластеры, являющиеся областью определения соответствующего отношения. Эти отношения являются отношениями нестрогого порядка [50]. Они упорядочивают технологические ситуации кластера, говоря о
том, какие из ситуаций более предпочтительны для производства с точки зрения данного критерия, а какие – менее предпочтительны. Фактически, задаётся
62
некоторая шкала, которая позволяет ранжировать технологические ситуации в
пределах примерно одинаковых технологических ситуаций.
Таким образом, система множеств Cs , R является прикладной алгебраической моделью смеси веществ и материалов, где R – множество бинарных отношений на области определения Cs, и
R = {≡ ,≠ ,≈ ,⊥ ,→ ,# ,≥ i }.
(2.5)
2.3.3 Свойства отношений прикладных универсальных алгебраических моделей
Базовыми свойствами бинарных отношений [50], которые могут быть необходимы при поиске технологических закономерностей и составляющих процессов технологических цепочек являются:
- рефлексивность ( x r x ),
- симметричность (x r y ⇒ y r x),
- антисимметричность ( отсутствие симметричности) ,
- транзитивность (x r y & y r z ⇒ x r z).
Здесь x, y, z ∈ Cs, r ∈ R, «&» - операция логического «И», а « ⇒ » - отношение следования (или операция логической импликации).
Основные свойства отношений, представленных в п. 2.3.2, сведены в таблицу (таблица 2.1).
К дополнительным свойствам отношений можно добавить очевидную
противоположность [50] следующих пар: {≡, ≠}, {≈, ⊥}, {→, #}, которая
должна учитываться при проектировании алгоритмов синтеза технологических
процессов изготовления смесей.
63
Таблица 2.1 – Свойства отношений прикладных универсальных алгебраических
моделей
Наличие или отсутствие свойства
Обозначение Рефлексивотношения
ность
Симметрич-
Антисимметрич-
ность
ность
Транзитивность
≡
+
+
_
+
≠
_
+
_
_
≈
+
+
_
_
⊥
_
+
_
_
→
+
_
_
+
#
_
+
_
_
≥i
+
_
_
+
Следует отметить, что, как множество пар элементов базового множества,
одно отношение может включать в себя другое. Например, отношение « ≥i »
предполагает, что элементы уже состоят в отношении « ≡ ».
2.3.4 Алгебры технологических цепочек приготовления смесей
Механизм образования нового компонентного вещества является сложным процессом и представляет собой семантику операции композиции исходных компонентных веществ.
Семантика учитывает следующие факторы:
– исходные вещества, временная последовательность их соединения (шаги, этапы),
– условия соединения (температура, пропорция, концентрация, длительность взаимодействия),
– результирующие вещества.
64
Схемы зависимостей характеристик качества результирующего продукта
от характеристик исходных компонентов представлены двумя следующими
подмножествами:
– точные формулы зависимостей;
– экспертные схемы зависимостей.
Схема зависимостей может быть представлена как граф состояний, связанных между собой дугами переходов из одного состояния в другое. Эти переходы образуют варианты последовательной и параллельной композиций. Каждое состояние описывается кортежем, который представляет собой конечное
множество признаковых структур. Каждая из таких структур содержит произвольное число неупорядоченных, но обязательно поименованных элементов. В
самом простом случае состояние может определяться одноэлементным множеством.
Под параллельной композицией дуг в описываемой ситуации понимается
возможность одновременного выполнения двух и более технологических операций. Под последовательной композицией понимается выполнение одной операции только после завершения другой. Таким образом, более точно схема зависимостей представляет собой сеть, или ориентированный и направленный
граф [51], ребра которого принято называть дугами.
Последовательная композиция дуг в предыдущих параграфах обозначена
символом операции « o ». Символ операции параллельной композиции обозначим с помощью символа «⊕».
Таким образом, система множеств Cs ,Ω является прикладной универсальной алгеброй смеси веществ и материалов, где Ω = {o ,⊕} – множество операций, замкнутых на области определения Cs и называемых сигнатурой алгебры [52]. Предложенную алгебру можно дополнить нулевой константой «∅»,
обозначающей полное отсутствие каких-либо материалов и компонентных веществ [58]. Нужно отметить, что в алгебре отсутствует единичная константа,
которая требует наличия для любой из операций возможность подбора обрат-
65
ного элемента, позволяющего вернуть технологический процесс в предыдущее
состояние.
Таким образом, тип алгебры [52] можно записать как {∅ (0 ), o (2), ⊕ (2 )} ,
где в круглых скобках указывается местность отношений. Так, например, константа «∅» имеет нулевую местность и не требует никаких аргументов. В множество операций она включается как постоянная операция без аргументов.
2.3.5 Свойства операций алгебры технологических цепочек приготовления смесей
Базовыми свойствами операций [50], которые могут понадобиться при
поиске технологических закономерностей и составляющих процессов технологических цепочек являются:
- идемпотентность (x ω х = x),
- коммутативность (x ω y = y ω х ),
- ассоциативность (x ω (y ω z)) = (( x ω y) ω z),
- дистрибутивность слева (x ω (y ω0 z)) = (x ω y) ω0 ( x ω z ),
- дистрибутивность справа ((y ω0 z) ω x) = (y ω x) ω0 ( z ω x ),
- свойство нулевой константы x ω ∅ = x,
где x ∈ Cs , y ∈ Cs, z ∈ Cs, ω ∈ Ω, ω0 ∈ Ω.
Таблица 2.2 содержит основные свойства операций, представленные ранее в п. 2.3.4.
Таблица 2.2 – Свойства операций прикладных универсальных алгебр
Наличие или отсутствие свойства
Обозначение Идемоперации
потентность
Коммута-
Ассоциа-
Дистрибу-
тивность
тивность
тивность
°
-
-
-
+
⊕
+
+
+
+
66
Кроме того, следует учитывать, что в алгебре технологических цепочек
приготовления смесей существует пустое количество компонентных веществ,
обозначенное символом «∅».
2.4 Алгебраическая система технологических цепочек
приготовления смесей. Конструктивные оптимизирующие
свойства алгебраической системы
Алгебраической системой [50] является алгебра, объединенная с множеством отношений. При этом отношения и операции из сигнатуры определены
на одном и том же множестве-носителе:
ACs = Cs ,Ω , R ,
(2.6)
R = {≡ ,≠ ,≈ ,⊥ ,→,# ,≥ i },
Ω = {∅ (0 ),o (2 ), ⊕ (2 )},
ACs = {c1 ,c2 ,...,cn },{∅(0 ), o (2 ), ⊕ (2 )}{
, ≡ ,≠ ,≈ ,⊥ ,→ ,# ,≥ i } .
Исследуем свойства операций алгебраической системы ACs, учитывая
возможность существования отношений на отдельных подмножествах множества Cs. Использование этих свойств даст возможность установить различия
эквивалентных технологических цепочек производства смесей и конструктивно
оценивать их предпочтительность для конкретного производства. Свойства, записываемые для рассмотренной алгебраической системы, следуют непосредственно из определений операций и отношений, рассмотренных ранее в п. 2.3.3,
2.3.4.
Приведем список основных свойств, который может при необходимости
быть дополнен производными соотношениями.
1) сi ⊥ cj ⇒ [ сi ° cj = сj ° ci ] ,
2) сi ≡ cj ⇒ [ сi ° cj = сj ° ci ] ,
3) сi ≡ cn & сi ≥ ci+1 ≥ ci+2 ≥ … ≥ cn ⇒ сi ≥ cn ,
67
4) ( ci → cn ) & ( ci ≡ cj ) & (cn ≡ ck) & сi → ci+1 → ci+2 → … → cn &
cj → cj+1 → cj+2 → … → ck & сi ≥ cj & ci+1 ≥ cj+2 & cn ≥ ck ⇒
сi ° ci+1 ° ci+2 ° … ° cn ≥ cj ° cj+1 ° cj+2 ° … ° ck ,
5) сi ° ( cj ⊕ ck ) ≡ сi ° cj ⊕ сi ° ck ,
6) сi ° cj ≡ сj ° ci & сi ° ck ≡ сk ° cj ⇒ ( cj ⊕ ck ) ° сi ≡ сi ° cj ⊕ сk ° cj,
7) ( ci → cn ) & ( ci ≡ cj ) & (cn ≡ ck) & сi → ci+1 → ci+2 → … → cn &
cj → cj+1 → cj+2 → … → ck & ∃ ci+1 , ∃ ci+2 , ci+1 ≥ cj+2 ⇒
сi ° ci+1 ° ci+2 ° … ° cn ≥ cj ° cj+1 ° cj+2 ° … ° ck ,
8) сi ≈ ci+1 ≈ ci+2 ≈ … ≈ cn ⇒ сi ° ci+1 ° ci+2 ° … ° cn ≠ ∅,
9) сi → ci+1 → ci+2 → … → cn & ∃ci+t , ci+t+1, ci+t #ci+t+1 & ( ci ≡ cj ) & (cn ≡ ck)
& cj → cj+1 → cj+2 → … → ck ⇒ cj ° cj+1 ° cj+2 ° … ° ck ≥
сi ° ci+1 ° ci+2 ° … ° cn .
Здесь задействован символ «∃» – квантор существования, в случае « ∃ ci »
определяемый как «в ТБЗ существует технологическая ситуация ci».
Кратко поясним приведенные свойства.
Свойства 1 и 2 выражают тот факт, что любые две эквивалентные или же
наоборот, полностью независимые, технологические ситуации можно поменять
местами во временной последовательности без нарушения общего результата
процесса.
Свойство 3 определяет транзитивность (транзитивное замыкание) для последовательности технологического процесса с лучшими свойствами.
Свойство 4 позволяет выбрать из двух процессов один, с более хорошими
технологическими характеристиками, если все соответствующие составляющие
этих процессов однонаправлено лучше по своим свойствам.
Свойства 5 и 6 вводят возможность оптимизации описания технологического процесса за счет вынесения общей части двух альтернативных процессов
«за скобку», т.е. описание этого процесса только один раз. Это, в свою очередь,
может свидетельствовать о возможности упрощения реальной технологии.
68
Свойство 7 позволяет установить критерий выявления из двух эквивалентных технологических цепочек одной, наиболее эффективной по какомулибо свойству, заданному заранее.
Свойство 8 позволяет обнаружить бессмысленность (противоречивость в
технологии) выполнения определенной технологической цепочки.
Свойство 9 дает возможность выделить в технологической последовательности производства смесей «лишнее» звено. Это говорит о том, что существует другая, более простая технологическая цепочка.
В заключении можно сделать вывод о том, что полученный алгебраический формализм достаточен для описания цепочек технологических процессов
и анализа свойств их оптимизации. Формализм дает возможность математически описать решение задачи синтеза технологических цепочек, сформулированной в п. 2.1.
Однако, для автоматизации поставленной задачи необходимо иметь эффективный алгоритм, который позволял бы производить поиск оптимизированных по различным критериям технологических последовательностей без вмешательства человека. Человек-эксперт или инженер по знаниям (ИЗ) [67, 68]
должен присутствовать лишь при формировании ТБЗ в части ее создания, пополнения и внесения изменений.
2.5 Унификация на множестве выражений алгебраической
системы технологических цепочек
Для автоматизации решения задачи, поставленной в п. 2.1, рассмотрим
исходные данные, которые должны быть заранее известны. Эти данные составляют основу ТБЗ, а именно:
– множество (универсум, перечень) компонентных веществ и материалов
Cs;
– множество элементарных звеньев (шагов) технологических цепочек по
составлению компонентных смесей как семантика операций последовательной
композиции (п. 2.3.4) « o »;
69
– множество критериев оценки качества текущего состояния технологического процесса как семантика отношений критериальной последовательности
“≥” (п. 2.3.2), число которых равно числу технологических критериев.
Все перечисленные множества при программной реализации должны
быть заранее в удобной для технолога форме введены ИЗ в ТБЗ [67, 68] и/или
для них должен быть определен другой источник информации. Современные
компьютерные технологии, включая облачные, позволяют, при соответствующем описании знаний в информационных ресурсах (например, в языках OWL-S
или WSDL [35,69]), выбирать необходимые данные из ИС ГС [70].
Нужно отметить, что все множества, перечисленные в качестве необходимых входных данных, могут изменяться и дополняться. В этом заключается
свойство обучаемости [71] или адаптивности автоматизированной системы, что
позволяет поддерживать технологию конкретного производства на должном
современном уровне.
Алгебраический формализм для исследования и составления оптимизированных технологических цепочек изготовления смесей содержит консервативную часть знаний, позволяющую оптимизировать технологии, исходя из
экспертных знаний ТБЗ.
Алгоритм синтеза технологических цепочек основывается на эвристических методах [72]. Они используют достаточно эффективные оценки, сокращающие поиск решения за счет экспертных критериев ТБЗ и свойств 1-9 из п.
2.4. В алгебраической записи алгоритм представляет собой процедуры унификации и генерализации [59] термов на множестве алгебраических выражений.
Определение 2.9 Два алгебраических терма s и t являются унифицируемыми, если существует подстановка, являющаяся унификатором для s и t [59].
Для алгебры поиска оптимальных компонентных смесей термами, задействованными в процессах унификации, будут алгебраические высказывания
формального языка L. Этот язык в форме Бэкуса-Наура [73], задается следующим образом.
70
<терм языка L> ::= <константа из раздела Cs ТБЗ>  <переменная>
(<терм языка L>)  <операционное выражение>,
<операционное выражение> ::= <терм языка L>° <терм языка L>
<терм языка L>⊕ <терм языка L>.
Здесь в угловые скобки заключены нетерминальные символы языка L,
символом «::=» обозначено высказывание «по определению есть», символ «»
означает высказывание «или». Остальные символы (скобки, знаки операций)
являются символами языковых цепочек.
Фактически, термы языка L уже рассматривались в предыдущих параграфах второй главы. Основным отличием является возможность введения переменных в последовательности описания технологического процесса. Так, например, выражение:
(
)
ci o ci +1 o x o c j ⊕ ck o cn o x
(2.7)
означает терм как последовательность выполнения перечисленных в нем технологических операций с возможной взаимной альтернативной заменой технологических операций cj и ck друг на друга. x – являются связными переменными, обозначающими одно и тоже подвыражение терма.
Таким образом, термы языка L представляют собой базу фактов (БФ) ТБЗ
[74]. В логическом запросе (2.7) x – неизвестный элемент технологии, который
необходимо найти. Для решения задачи, используя известную или пополняемую из внешних источников БФ, нужно построить последовательность, точно
совпадающую с термом примера, однако вместо x подставить правильное значение. Такая подстановка в итоге станет унификатором. В целом, речь можно
вести о решении задачи сопоставления из теории унификации [59].
Более сложной задача становится при использовании правил вывода ТБЗ,
которые соответствуют соотношениям 1-9 из п. 2.4. Эти правила дают возможность не только решать, но и оптимизировать полученные решения по длительности технологического процесса. Для этого в п. 2.6 предлагается соответствующий новый алгоритм унификации.
71
2.6 Общее описание алгоритма унификации,
оптимизирующего синтез последовательностей
технологических операций
Задачей нового алгоритма унификации является получение искомых технологических цепочек изготовления смесей, выраженных в алгебраических
термах произвольной длины, а так же отвечающих требованиям заранее установленных критериев. Таким образом, должна быть решена любая по сложности задача с известными начальными данными и результатом, либо установлен
факт её неразрешимости.
Например, самой сложной является задача следующего вида:
(
)
c0 x cn : ∀ci , ci +1 [c0 → ... → ci → ci +1 → ... → cn ] min ci ≥ j ci +1 ,
(2.8)
где «∀» - квантор всеобщности исчисления предикатов первого порядка [74],
читаемый здесь как «для любых ci , ci+1 ». Выражение min (ci ≥j ci+1) читается как
«отношение с минимальным значением соответствующего ему семантического
критерия». Таким образом, полная формулировка задачи звучит так: «на основе
знаний ТБЗ найти такой терм x, состоящий, возможно, из последовательности
подтермов, в которой любые два последовательных состояния технологического процесса отвечали бы критерию минимума (например, затрат) ».
Чаще может встречаться более простая задача, уже содержащая фрагменты решения, например:
(
)
c0 o c1 o x o cn −1 o cn : ∀ci , ci +1 [c1 → ... → cn −1 ] min c1 ≥ j cn −1 .
(2.9)
Здесь необходимо найти лишь один из шагов технологической цепочки,
которой, однако, может также оказаться сложным.
Таким образом, одним из отличий нового алгоритма унификации является учет критериев качества технологического процесса. Это означает, что из
всех имеющихся в ТБЗ фактов и правил в первую очередь должны рассматриваться именно те, которые отвечают заданным критериям качества (свойство 4
п. 2.4).
72
Следует также отметить, что в новом алгоритме при определении эквивалентности технологических состояний используются соответствующие кластеры (п. 2.3.1), а в качестве правил вывода среди прочих принимаются оптимизирующие преобразования (свойства 4 - 6) и отсечения тупиковых ветвей (свойство 8) алгебраической системы ACs (п. 2.4).
Общая схема алгоритма может быть описана следующим образом.
В предложенной задаче определяются начальные и результирующие условия. Затем одним их эвристических методов, например, методом ветвей и
границ [72] из БФ ТБЗ выбираются готовые цепочки технологического процесса. Каждое очередное звено цепочки идентифицируется с помощью кластеризации.
Из выбранного множества цепочек удаляются противоречивые последовательности.
Алгоритм продолжается выбором правил вывода, которые генерируют
новые возможные варианты технологических цепочек, оптимизированных с
помощью описанных ранее технологических свойств. При использовании множественной последовательности правил вывода из ТБЗ реализуется композиция
унификаторов [73], далее подстановки используются при формировании результата. Полученные решения фильтруются с помощью свойств противоречивости и упорядочиваются на основе оценки по заранее выбранным критериям.
Если при заданных критериях задача не имеет решения, технолог, задающий эти критерии, может изменить их и/или расширить границы кластеров для
классов эквивалентности технологических состояний. Алгоритм должен быть
запущен снова.
Алгоритм завершается при получении приемлемого решения с точки зрения технолога или при установлении факта невозможности определения искомой технологической последовательности.
В последнем случае алгоритм должен быть «дообучен», т.е. в ТБЗ должны быть включены новые факты, могут быть исправлены некоторые критерии
качества или скорректированы границы кластеров.
73
Еще одним положительным качеством нового алгоритма унификации являются его адаптационные свойства, т.к. при получении приемлемых решений,
он может не только запоминать их в БФ, но и упорядочивать применение использованных при решении правил.
2.7 Схема алгоритма унификации
Рисунок 2.4 содержит блок-схему алгоритма унификации, обобщенно
описанную в предыдущем параграфе.
Начало
FactsSelect(FF);
RulesSelect(RF)
Нет
FactsAndRulesSelect
Query
Complexity
Да
Terms matching
RF =
NULL
Да
Нет
FF =
NULL
Да
Нет
NewFacts = LightMatching(FF);
NewFacts = Clastering(FF)
UnifyRules(NewFacts, RF);
UnifyCompose(NewFacts)
GetNextElements(FF)
GetNextElements(RF)
1
2
Рисунок 2.4 – Блок-схема алгоритма унификации (начало)
74
1
2
Fact Base Matching
Result Testing
Нет
Contradiction?
Да
Modify Tech Sequence
DeleteContradiction
AppriciateCriterialResults
Return(ResultNewFacts)
Put Result
Конец
Рисунок 2.4 – Блок-схема алгоритма унификации (продолжение)
Таблица 2.3 описывает обозначения данных, функций и модулей, задействованных в блок-схеме алгоритма.
Таблица 2.3 – Обозначения алгоритмической схемы (начало)
№ Обозначение
Наименование
Семантика
п/п конструкции
1
2
3
конструкции
Предикат от
Проверка формулировки тех-
Query Complexity
конструкции
нологической задачи на слож-
( Query)
запроса
ность (применение правил)
Модуль выбора фак-
Блок извлечения и ТБЗ подхо-
FactAndRulesSelect
тов и правил
дящих фактов и правил вывода
FactsSelect(FF)
Функция выбора фак-
Выбор фактов, подходящих для
тов
задачи в системный стек
75
Таблица 2.3 – Обозначения алгоритмической схемы (продолжение)
№ Обозначение
Наименование
Семантика
п/п конструкции
конструкции
Область памяти для хранения
4
FF, RF
Системный стек
информации с возможностью
выборки и удаления
5
RulesSelect(RF)
Функция выбора пра-
Область памяти для хранения
вил
правил с возможностью их выборки и удаления
6
Terms Matching
Модуль сопоставле-
Блок унификации, выбираю-
ния термов
щий возможные подстановки
Функция выборки очередного
7
8
9
GetNextElements(Stack)
LightMatching (FF)
Функция подъема
элемента стека с последующим
стека
его удалением
Функция упрощенно-
Функция сопоставления термов
го сопоставления
без применения правил вывода
Функция кластериза-
Функция выделения классов
ции
эквивалентности на множестве
технологических состояний со-
Clastering(FF)
гласно критериям кластеризации
10
NewFacts
Стек новой области
Системный стек, постоянно по-
фактов
полняемый, содержащий новые
результаты отыскания технологических цепочек
11
UnifyRules(NewFacts,
Функция унификации
Функция, выбирающая очеред-
на основе правил
ное правило и производящая
унификацию с предыдущими
RF)
результатами
Функция композиции
12
UnifyCompose(NewFacts) подстановок
Стандартная функция композиции унификаторов для получения нового результата
76
Таблица 2.3 – Обозначения алгоритмической схемы (продолжение)
№ Обозначение
Наименование
Семантика
п/п конструкции
13
14
Fact Base Matching
Contradiction
конструкции
Модуль сопоставле-
Блок сопоставления (унифика-
ния фактов
ции) фактов из ТБЗ
Предикат обнаруже-
Булева функция, отыскиваю-
ния противоречий
щая тупиковые (противоречивые) технологические цепочки
Модуль модификации Блок модификации полученных
15
Modify Tech Sequence
технологических це-
в результате технологических
почек
цепочек путем удаления противоречивых и упорядочивания
результата
16
DeleteContradition
Функция удаления
Функция, удаляющая из ре-
противоречий
зультата противоречивые и неудачные варианты
AppriciateCriterialResults
17
Функция оценки и
Функция, оценивающая резуль-
упорядочивания ре-
таты по заранее установленным
зультатов
критериям и упорядочивающая
их
18
Result Testing
Put Result
19
Модуль проверки ре-
Блок проверки, очистки и упо-
зультатов
рядочивания результатов
Модуль вывода ре-
Блок формирования результа-
зультатов
тов в удобной для пользователя
форме
Return(ResultNewFacts)
20
Функция завершения
Функция формирования ре-
работы
зультатов и выдачи их пользователю
В таблице представлены основные данные, модули и функции. Реальная
программная реализация включает модули работы с ТБЗ, справочники компонентных веществ и материалов.
Стоит отметить, что при описании алгоритма не рассматривались возможности адаптации и обучения ТБЗ, которые реализуются вспомогательными
77
модулями автоматизированной системы. Особенности алгоритмов, реализующих эти возможности, рассматриваются в третьей главе диссертационной работы. В блок-схеме алгоритма не приведены также подробности реализации процедур сопоставления алгебраических термов и композиции подстановок, которые известны ранее в теории унификации [73].
Основные результаты
1.
На основе исследования проблемы автоматизации технологических
процессов для изготовления смесей сформулирована задача разработки математической формализации, позволяющей производить адекватный анализ таких
технологических процессов.
2.
Предложена алгебраическая модель, содержащая достаточное для
исследований количество бинарных отношений на множестве компонентных
веществ и материалов. Исследованы свойства предложенных отношений, показана их эффективность при описании свойств технологических ситуаций на
производстве.
3.
Описано использование кластеров пространства с семантической
метрикой, позволяющих применять в алгоритмах поиска технологических цепочек приготовления смесей обучение и адаптацию с целью повышения эффективности алгоритмов при накоплении знаний.
4.
Разработана алгебра и соответствующая алгебраическая система,
дающие возможности адекватного описания технологических процессов, автоматизации их проектирования и оптимизации их компонент.
5.
Спроектирован новый алгоритм унификации на множестве термов
алгебраической системы технологических цепочек, реализующий эффективный
поиск таких цепочек с упорядочиванием по критериям качества технологического процесса.
78
ГЛАВА 3. АРХИТЕКТУРА И ПРОЕКТНЫЕ РЕШЕНИЯ
АВТОМАТИЗИРОВАННЫХ СИСТЕМ, ПРИМЕНЯЕМЫЕ В
ТЕХНОЛОГИЯХ ИЗГОТОВЛЕНИЯ КОМПОЗИТНЫХ
СМЕСЕЙ
3.1 Основные архитектурные и технические решения,
применяемые в существующих программных системах
автоматизации технологии изготовления смесей
3.1.1 Программа «Рецептура асфальто-бетонной смеси 1.0»
Автор: Роман Ухов [15].
Программа предназначена для подбора состава минеральной части асфальто-бетонной смеси. Для организаций, имеющих отношение к строительству дорог, задача составления оптимальной смеси имеет большое значение. Математическая основа ПС «Рецептура асфальто-бетонной смеси 1.0», включающая математическую модель и основной алгоритм оптимизации, рассмотрена в
п. 1.2.2 диссертационной работы. Текущий раздел посвящён рассмотрению общих теоретических возможностей ПС, их анализу и выявлению ключевых достоинств и недостатков с технической стороны.
ПС «Рецептура асфальто-бетонной смеси 1.0» с технической точки зрения
представляет собой стандартное автономное приложение MS Windows с графическим интерфейсом. Внутренняя структура ПС состоит из нескольких модулей: модуль для работы с текстовыми файлами, модуль расчёта, модуль экспорта результатов в MS Excel и др. Модули ПС скомпилированы в единый исполняемый файл. Архитектура не позволяет обновлять или заменять их по отдельности. ПС не взаимодействует с какими-либо сервисами по сети.
Функционал программы позволяет вводить данные для требуемых по
ГОСТ характеристик смеси, вводить данные о материалах и рецептах. Ввод
осуществляется только через табличные формы в окне программы (рисунок
3.1). Проверка на правильность введённых данных отсутствует. Заполненные
пользователем вручную стандарты ГОСТ, материалы и рецепты сохраняются
79
на жёстком диске в файлах, имеющих специфический текстовый формат, исключающий возможность быстрого интегрирования с другими ПС.
Рисунок 3.1 – Окно программы «Рецептура асфальто-бетонной смеси 1.0»
Дополнительными функциями программы являются построение графика
процентного распределения зернового состав минеральной части смеси по величине зерна, а также вывод полученных данных в документ MS Excel в жёстко
определённой форме. Критерием поиска оптимального решения является минимальная стоимость асфальтобетона [15].
К достоинствам программы «Рецептура асфальто-бетонной смеси 1.0»
можно отнести простоту установки (распаковка архива), графический интерфейс, возможность хранения данных о материалах, рецептах и стандартах
ГОСТ.
80
К недостаткам относятся:
−
достаточно грубый алгоритм расчёта оптимальной смеси, не учиты-
вающий множество факторов, которые могут сыграть в конечном итоге ключевую роль. Например, при расчёте не учитываются технические факторы конкретного производства, технология;
−
оптимизация только по критерию минимальной стоимости;
−
отсутствие средств сбора и накопления статистических данных;
−
фиксированный алгоритм, не учитывающий статистику и, как след-
ствие, отсутствие обратной связи;
−
необходимость ручного ввода абсолютно всех исходных данных по
материалам;
−
необходимость ручного ввода нормативной документации ГОСТ;
−
продолжительное время вычислений при большой размерности за-
−
прямая зависимость ПС от физических характеристик оборудования
дачи;
пользователя;
−
не интуитивный интерфейс: множество полей ввода с неочевидным
назначением;
−
требование глубоких знаний в области производства асфальто-
бетонных смесей, а также подробной справки о программе;
−
отсутствие автоматического обновления и, как следствие, несвое-
временная фиксация ошибок и модификация алгоритма расчёта (если таковая
потребуется и будет выпущена автором);
−
сложность расширения функционала программы и невозможность
масштабирования (охват других отраслей и предметных областей);
−
Windows.
работоспособность программы исключительно на платформе MS
81
3.1.2 Программа «Автоматизированная система расчета оптимальных рецептов помольных смесей» (АСР «ОРПС»)
Авторы: А.Н. Мерцалов, к.т.н. МГУПП, В.О. Новицкий, д.т.н. МГУПП
(кафедра «Автоматизированные системы и вычислительная техника» Московского государственного университета пищевых производств) [21].
Программа предназначена для расчета оптимальных рецептов помольных
смесей. На сегодняшний день перед производителями мукомольной продукции
остро стоит задача оптимизации при производстве муки с требуемыми качествами, часто отличающимися от стандартных. Такую ситуацию на рынке формируют заводы полуфабрикатов, кондитерские и хлебобулочные предприятия,
которые предъявляют самые разнообразные требования к качеству муки. В соответствии со сложившейся ситуацией, производители мукомольной продукции
расширяют свой ассортимент, подстраиваясь под запросы покупателей.
Математическая основа ПС АСР «ОРПС», включающая математическую
модель и основные алгоритмы поиска оптимальной мукомольной смеси, рассмотрена в п. 1.2.3 диссертационной работы. Текущий пункт посвящён рассмотрению общих теоретических возможностей ПС, их анализу и выявлению
ключевых достоинств и недостатков с технической стороны.
ПС АСР «ОРПС» с технической точки зрения представляет собой приложение MS Windows с графическим интерфейсом. Архитектуру ПС составляют
несколько модулей: модуль импорта исходных данных, модуль поиска рецепта
оптимальной смеси, модуль анализа результатов расчёта, модуль ведения статистики, модуль экспорта рецепта и др. Модули образуют единое ПС, архитектура не позволяет обновлять или заменять их по отдельности. ПС может осуществлять взаимодействие с внешними системами, предоставляющими входную
информацию, а так же с ПС, отдающими команды оборудованию предприятия
для формирования помольных смесей.
Основываясь на заданных ограничениях по числу компонентов, качеству,
точности дозирования и массе зерновой смеси (рисунок 3.2) программа выпол-
82
няет расчет оптимальных рецептов помольных смесей для выбранного критерия.
Рисунок 3.2 – Окно программы АСР «ОРПС», вкладка «Ограничения»
Оптимальные рецепты помольных смесей рассчитываются на основании
текущих остатков сырья на комбинате, представленных в его силосной доске
(таблице, содержащей информацию о культуре, дате загрузки, количестве, качестве хранящейся партии и т.д. [75]), с учётом цен. В программе реализована
возможность загрузки данных силосной доски предприятия из файла, как альтернатива табличному вводу исходных данных.
Алгоритм расчёта основан на двойственном симплекс-методе и методе
ветвей и границ [22]. В зависимости от нужд предприятия расчёт (рисунок 3.3)
производится по одному из трёх критериев: минимальное отклонение качества
от эталона, максимальный размер помольной смеси, минимальная стоимость
помольной смеси.
83
Рисунок 3.3 – Окно программы АСР «ОРПС», вкладка «Расчёт»
Однако, АСР «ОРПС» не заменяет квалифицированного специалиста.
Выбор предпочтительного варианта остается за лицом, принимающим решения (ЛПР).
К достоинствам рассматриваемой программы можно отнести:
−
простоту установки;
−
графический интерфейс;
−
возможность настройки в соответствии с технологическими пара-
метрами предприятия;
−
возможность импорта информации о сырье;
−
выбор критерия оптимизации, большую свободу настроек;
−
небольшое время расчёта при малом количестве исходных данных;
−
возможность построения сравнительной таблицы различных вари-
антов расчёта;
−
экспорт результатов во внешние файлы;
−
ведение статистики рецептов и результатов;
84
−
обилие обучающей и справочной информации по работе с програм-
мой.
К недостаткам относится:
−
отсутствие возможности одновременного выбора двух и более кри-
териев оптимизации;
−
продолжительное время расчёта при большой размерности задачи;
−
прямая зависимость ПС от физических характеристик оборудования
пользователя;
−
отсутствие информации о нормативах и стандартах продукции;
−
отсутствие возможности автоматической загрузки данных о пред-
ложениях сырья сторонних организаций;
−
отсутствие автоматического обновления и, как следствие, несвое-
временная фиксация ошибок и модификация алгоритма расчёта;
−
сложность расширения функционала программы и невозможность
масштабирования;
−
программа работает только на платформе MS Windows.
3.1.3 Программное обеспечение «SMART! Fertilizer Management Software»
ПО «SMART! Fertilizer Management Software» разрабатывалось зарубежным научным коллективом (Гай Села, Юзи Кафкафи и др.) и предназначено для
поиска оптимального состава смеси сельскохозяйственных удобрений [76].
Рассматриваемое ПС представляет большой интерес с архитектурнотехнической точки зрения. «SMART! Fertilizer Management Software» реализует
клиент-серверную архитектуру [77], что позволяет уменьшить требования к
оборудованию пользователя. Эта архитектура также решает часть проблем обновления и актуализации ПС. Модули расчёта физически располагаются на
стороне сервера и могут быть заменены, улучшены и доработаны не затрагивая
конечного пользователя. Основные вычисления производятся на сервере. Таким
85
образом, клиент-серверная архитектура позволяет избавиться от прямой зависимости ПС от оборудования пользователя. Однако ПС, использующее такую
архитектуру, зависит уже от характеристик оборудования на стороне сервера.
Это решение выгодно отличает «SMART! Fertilizer Management Software» от
конкурентных систем, производящих поиск смеси на оборудовании клиента, но
не решает проблему больших и трудоёмких расчётов полностью.
На основании вводимых пользователем данных о площади и выращиваемых культурах алгоритм программы составляет смесь для удобрения земли.
Учитываются химические взаимодействия между компонентами смеси [78].
Для пользователей доступно два варианта клиентского ПО: для MS Windows и
веб-интерфейс. Критерием оптимизации смеси является минимальная стоимость [77].
ПО имеет дружественный интерфейс, однако часть исходных данных
пользователю необходимо указывать самостоятельно (рисунок 3.4). Например,
стоимость удобрений; производителя [79].
Рисунок 3.4 – Интерфейс ПО «SMART! Fertilizer Management Software»
86
К достоинствам рассматриваемой программы можно отнести:
−
удобный графический интерфейс;
−
возможность доступа с любого устройства, подключенного к Inter-
−
наличие справочной информации и поддержки;
−
стандарты и правила уже введены в программу;
−
возможность добавления/редактирования правил смешивания;
−
использование алгоритмов вычисления химического баланса, осно-
net;
ванные на результатах лабораторных тестов;
−
конвертирование метрических величин;
−
предупреждения о несовместимости компонентов и об опасности
полученной смеси (солёность, содистость и т.д.);
−
дополнительный сопутствующий функционал (расчёт времени вво-
да удобрений в почву);
−
хранение данных и статистики на стороне сервера;
−
экспорт результатов расчёта в MS Excel, MS Word, PDF.
К недостаткам относится:
−
длительное время работы алгоритма при большой размерности за-
−
возможность проведения сложных расчётов ограничивается техни-
дачи;
ческими характеристиками оборудования на стороне сервера;
−
отсутствие самокоррекции (самостоятельного формирования новых
правил) в алгоритме;
−
потребность самостоятельного ввода исходной информации (стои-
мости, производителя и т.д.);
−
характеристики исходных компонентов, существующих в базе дан-
ных, являются эталонными, что редко встречается на реальном рынке.
87
3.1.4 Общие недостатки архитектурных и технических решений,
применяемых в области задач составления смесей
К наиболее общим недостаткам архитектурных и технических решений
можно отнести следующие.
1. Поиск, определение и ввод исходных данных занимает много времени.
2. Подавляющее большинство программ не работает со статистикой, в алгоритм не заложен механизм самообучения. Лишь одна из рассмотренных программ «SMART! Fertilizer Management Software» позволяет корректировать
правила взаимодействия компонентов смеси. Однако, этот процесс требует непосредственного участия человека, а сами правила представляют собой описание взаимодействия химических элементов. Процесс их коррекции представляет сложность для обычного пользователя. Адаптивность и обучаемость систем
поиска оптимальных смесей на данный момент находится на низком уровне, а
чаще, просто отсутствует.
3. Отсутствие обучаемости и адаптивности говорит о том, что алгоритмы
ПС недостаточно гибки для требований, выдвигаемых современным производством и растущим рынком продукции. ПС «не имеют представления» о семантике проводимых операций и просто вычисляют результат в соответствии с выбранным математическим методом. Не учитываются разнообразные особенности и тонкости процесса формирования композитной смеси. Этот факт порождает как небольшие неточности, так и значительные погрешности при расчётах
на производстве.
4. ПС, в том числе имеющие хороший графический интерфейс, сложны
для конечного пользователя. Ему необходимо заполнить и проверить немалое
количество полей ввода (обычно представленных в виде ёмких таблиц), разобраться в многочисленных особенностях конкретного ПО и его настройках.
5. Архитектуры большинства ПС не обладают достаточной гибкостью и
расширяемостью. Лишь одна зарубежная ПС «SMART! Fertilizer Management
Software» имеет клиент-серверную архитектуру, но даже она не является самой
современной. Архитектура остальных рассмотренных ПС в лучшем случае ба-
88
зируется на взаимодействии программ в локальной сети. В худшем случае – ПС
представляет собой единственную программу. Вопросы масштабирования, обновления, скорости расчёта, совместимости и нелицензионного копирования
стоят остро из-за архитектуры существующих ПС оптимизации композитных
смесей.
6. ПО решения задачи поиска оптимальных смесей не универсально, каждая программа оптимизирована для своей, довольно узкой предметной области.
С одной стороны, это можно отнести к положительным свойствам, так как ПС
настроены для составления конкретного типа смеси, но, с другой стороны, в
основе всех рассмотренных систем лежит одна и та же задача в вариациях с небольшими различиями [9]. Этот факт позволяет сделать вывод о возможности
применения качественно нового подхода к решению задач поиска оптимальных
композитных смесей, позволяющего применить унифицированный алгоритм
для самых разнообразных смесевых производств.
3.2 Базовая архитектура и функциональные задачи
интеллектуальной автоматической системы, основанной на
прикладной алгебре технологических цепочек
приготовления смесей
3.2.1 Концептуальные особенности проектируемой интеллектуальной
системы
Основу проектируемой интеллектуальной системы составляют два главных компонента: прикладная алгебра технологических цепочек приготовления
смесей, рассмотренная во второй главе и SOA. На основе объединения этих
двух компонентов предлагается качественно новый подход к решению задач
поиска оптимизированных композитных смесей.
На основе выявленных достоинств и недостатков существующих ПС, в
этом пункте диссертационной работы определяются основные архитектурные и
функциональные особенности проектируемой интеллектуальной системы на
концептуальном уровне:
89
−
система имеет масштабируемую модульную структуру и состоит из
сети слабосвязанных ИС ГС, фактически базируясь на SOA [80];
−
система включает в свой состав ТБЗ, содержащую знания о мате-
риалах (компонентах), технологических ситуациях и процессах. ТБЗ должна
иметь возможность хранить и предоставлять информацию в соответствии с основными принципами прикладной алгебры, изложенными во второй главе;
−
вычислительные модули системы реализуют ресурсоёмкую часть
интеллектуального алгоритма унификации, оптимизирующего синтез последовательностей технологических операций (гл. 2, п. 2.6);
−
основными ролями взаимодействия с системой или актёрами [81]
являются: пользователь (предприятие), технолог, системный администратор,
инженер по знаниям (ИЗ) и сервис-инженер;
−
пользователь не обязан знать, как функционирует система, он мо-
жет осуществлять взаимодействие с ней по принципу «чёрного ящика»: пользователю известны лишь форматы входных и выходных данных;
−
технолог передаёт свои знания по предметной области системе че-
рез ИЗ;
−
ИЗ выполняет обучение системы, вводя в неё новые знания;
−
сервис-инженер масштабирует систему, добавляя или удаляя серви-
сы-источники данных, сервисы-обработчики и т.д.;
−
пользователь может получать услуги по оптимизации смесей;
−
пользователь может добавлять в систему информацию о продукции,
редактировать её;
−
системный администратор контролирует действия пользователей и
инженеров, разрешает возникающие при работе системы конфликты;
−
система должна облегчить процесс поиска и ввода исходных дан-
ных для задачи поиска оптимизированной композитной смеси;
−
система должна иметь возможность автоматического пополнения
информацией из внешних источников;
90
−
система не должна зависеть от оборудования пользователя;
−
процессы корректировки, расширения, обновления и развития сис-
темы не должны требовать активных действий пользователя.
3.2.2 Диаграмма прецедентов
Немаловажную роль в понимании архитектуры системы имеет графическое представление. На основе перечисленных в п.п. 3.2.1 особенностей составим оригинальную диаграмму прецедентов (рисунок 3.5) интеллектуальной автоматической системы поиска оптимизированных смесей (ИАС ПОС). Эта диаграмма известна так же как диаграмма вариантов использования (англ. «Use
Case Diagram») [82].
Рисунок 3.5 – Диаграмма вариантов использования ИАС ПОС
Представленная на рисунке диаграмма отражает отношения между актёрами и типичными способами взаимодействия с системой, а так же концептуальные зависимости между прецедентами внутри самой системы. Каждый актёр-человек обязательно имеет доступ к интерфейсу авторизации для иденти-
91
фикации его роли в системе, кроме актёра-технолога. Технолог – человек, который имеет много знаний в своей предметной области, но может не уметь обучать систему, так как этот процесс достаточно нетривиален. Поэтому технолог
взаимодействует с системой косвенно – через ИЗ, человека специализирующегося на работе со ТБЗ. Это решение оправдано так же и тем, что сообщать системе знания из разных предметных областей могут множество технологов, каждого из которых пришлось бы дополнительно обучать прямой работе с ТБЗ.
Это, в свою очередь, было бы стратегической ошибкой.
Пользователю доступны интерфейс работы со своей продукцией (добавление, редактирование, удаление) и интерфейс поиска оптимизированной компонентной смеси. Пользователь в отношении системы более ни в чём не заинтересован. Поиск оптимизированной компонентной смеси в свою очередь зависит от сервисов расчёта, которые черпают данные в ТБЗ.
ТБЗ имеет возможность пополнения двумя разными способами – с помощью человека (ИЗ) и с использованием информации сторонних ИС ГС, не входящих в состав разрабатываемой системы. Сторонняя информация перед поступлением в ТБЗ преобразуется к общему виду. Сервис-инженер контролирует
этот процесс и следит за актуальностью всех сервисов, входящих в состав системы.
Системный администратор контролирует общее состояние системы через
интерфейс панели управления, а так же посредством прямого контакта с актёрами «пользователь», «ИЗ» и «сервис-инженер».
Свойства расширяемости и глобальной распределённости, присущие разрабатываемой системе, отражены во взаимодействии внутренних сервисов с
внешними ресурсами ГС. Под «прочей информацией», получаемой из внешних
ресурсов понимается информация, позволяющая системе осуществлять расчёты
или дополняющая её возможности. Такой информацией могут считаться, например, текущие валютные курсы.
92
3.2.3 Диаграмма компонентов
ИАС ПОС, как и любая другая сложная система, на этапе проектирования
должна иметь чёткое деление на взаимосвязанные структурные компоненты.
Такое деление хорошо описывает архитектуру системы и позволяет эффективно скоординировать действия разработчиков. Этот пункт диссертационной работы посвящён разработке и анализу оригинальной UML-диаграммы компонентов ИАС ПОС (рисунок 3.6). Эта диаграмма является ключевой и, как правило, наименее подвержена изменениям на протяжении всего процесса разработки [83].
Рисунок 3.6 – Диаграмма компонентов ИАС ПОС
Компоненты системы, отражённые на диаграмме, представляют собой независимые сущности, скрывающие свою реализацию, в качестве которых могут
выступать модули, файлы, библиотеки, веб-сервисы и т.п. [84] Как было определено в п.п. 3.2.1, ИАС ПОС основывается на SOA. Таким образом, компоненты, представленные на диаграмме (рисунок 3.6), в рамках SOA являются ИС
ГС.
Ядро ИАС ПОС составляют такие компоненты как ТБЗ, Информационная
БД и сервисы расчёта. В качестве интерфейса взаимодействия человека с сис-
93
темой выступает компонент «Фронт-приложение», включающий в себя также
БД пользователей и сервисов. Содержащаяся в БД информация о входящих в
систему сервисах позволит реализовать функционал UDDI-сервиса для адресации и обмена данными внутри ИАС ПОС. Информационная БД хранит данные
о продукции, её ценах, качестве, общепринятых стандартах качества. ТБЗ состоит из БД фактов и компонента, отвечающего за логику вывода знаний и
взаимодействие с другими сервисами системы. Сервис расчёта схематично
представлен на диаграмме (рисунок 3.6) в единственном экземпляре, однако, на
практике этот компонент может являться целым массивом независимых сервисов расчёта. Легкость масштабирования ИС ГС – одна из основных особенностей SOA. Это в свою очередь позволяет использовать такие компоненты как
«сервис сбора информации» и пополнять систему новыми данными о продукции, её качестве, технологиях и фактах. Эти компоненты рассмотрены подробнее ниже (п.п. 4.3). Также на диаграмме (рисунок 3.6) схематично показаны
связи между компонентами, реализующие основные функции их взаимодействия.
3.2.4 Диаграмма взаимодействия
Для представления временных аспектов внутренних и внешних протоколов ИАС ПОС а так же организации иерархии взаимодействия служит диаграмма взаимодействия. Этот вид диаграмм необходим при проектировании
распределенных и параллельных приложений [85], таких как ИАС ПОС.
Этот пункт диссертационной работы посвящён проектированию диаграммы взаимодействия компонентов ИАС ПОС при выполнении поиска оптимизированной компонентной смеси.
Шкала времени на диаграмме (рисунок 3.7) направлена сверху вниз,
взаимодействие компонентов наглядно отображается при помощи горизонтальных стрелок. Схема даёт представление о времени жизни компонентов системы
при обработке запросов.
94
Рисунок 3.7 – Диаграмма взаимодействия компонентов ИАС ПОС при выполнении поиска оптимизированной рецептуры композитной смеси
Диаграмма отражает последовательность взаимодействия компонентов
ИАС ПОС при выполнении сценария поиска пользователем оптимизированной
рецептуры композитной смеси. Этот сценарий служит наиболее наглядным
примером в рамках рассматриваемой темы, так как затрагивает все аспекты
взаимодействия при оптимизации смеси.
95
3.3 Алгоритм поиска оптимизированной рецептуры
композитной смеси
Этот пункт диссертационной работы посвящён проектированию нового,
улучшенного алгоритма поиска оптимизированной рецептуры смеси (рисунок
3.8). Этот алгоритм является фундаментальным для разрабатываемой ИАС. Он
представляет собой расширенную интерпретацию алгоритма унификации, приведённого в п. 2.7 главы 2. Эта интерпретация раскрывает основные особенности решения задачи поиска рецептуры смеси с архитектурно-технической точки
зрения в проектируемой распределенной системе.
Начало
Front application
Authorization(Name,
Password)
Нет
Credentials
Accepted
Да
RequestProductList
(Type)
Query To Info DB
Show Available
Products (Type)
Choosing Product To
Find TechProcess
Input Additional
TechProcess Info
Get Knowledge Base
Service Address
Query TechProcess
(Product, Info)
Query To Tech. Know. Base
1
Рисунок 3.8 – Алгоритм поиска оптимизированной рецептуры композитной
смеси ИАС ПОС (начало)
96
1
Technological Knowledge Base
Identification
Inform. Area
Query To Front Application
Get System
Services Addresses
Query To Info DB
Get Information;
Info. Rectification
Нет
Query To Info Collect Service
Да
Query
Complexity
Full Facts And
Rules Select
Calculate Optimal
Data Partition
Fact Base Matching
Partial Facts And
Rules Select
Compose Task;
Send To Calc Service
Calc Service
Terms Matching;
Send Result Back
Нет
Last Task
Been Send
Да
Collect All Results
From Calc Services
Result Testing;
DeleteContradiction
Save Result;
Return Result
Конец
Рисунок 3.8 – Алгоритм поиска оптимизированной рецептуры композитной
смеси ИАС ПОС (продолжение)
97
Алгоритм содержит полный путь информации от входа пользователя в
систему до выдачи результата, проходящий через множество сервисов. Поэтому на блок-схеме (рисунок 3.8) пунктирными линиями выделены области алгоритмических конструкций, показывающие, к какому сервису относятся те или
иные функции. Таблица 3.1 содержит обозначения данных, функций и модулей,
задействованных в блок-схеме алгоритма, за исключением описанных ранее в
п. 2.7 главы 2.
Таблица 3.1 – Обозначения алгоритмической схемы (начало)
№ Обозначение
Наименование
Семантика
п/п конструкции
1
Authorization(Name,
конструкции
Авторизация пользо-
Ввод пользователем, зарегист-
вателя
рированным в ИАС своих персональных данных
Password)
2
3
Проверка персональ-
Проверка соответствия имени
Credentials Accepted
ных данных
пользователя и пароля
RequestProductList
Получение списка
Запрос и получение списка про-
(Type)
продуктов
дуктов по указанному типу
продукта
Построение запроса к БД ин-
4
Query To Info DB
Запрос к БД инфор-
формации и ожидание ответа
мации
Вывод полученного ранее спи-
5
6
7
Show Available
Вывод списка про-
ска продуктов, соответствую-
Products (Type)
дуктов
щих указанному типу
Выбор продукта
Выбор пользователем продукта
Choosing Product To
в качестве конечной точки тех-
Find TechProcess
нологического процесса
Input Additional
TechProcess Info
Ввод дополнительной
Ввод пользователем дополни-
информации
тельных условий протекания
технологического процесса
98
Таблица 3.1 – Обозначения алгоритмической схемы (продолжение)
№ Обозначение
Наименование
Семантика
п/п конструкции
8
Get Knowledge Base
конструкции
Функция получения
Функция получения списка ад-
адреса сервиса ТБЗ
ресов сервисов ТБЗ, зарегистрированных в системе и выбор
Service Address
одного из них
9
Query TechProcess
Запрос технологиче-
Запрос к сервису ТБЗ для полу-
ской цепочки
чения технологической цепочки на основании введённой ин-
(Product, Info)
формации; вывод результата
Запрос к сервису ТБЗ
10
Запрос к сервису ТБЗ и ожидание ответа
Query To Tech. Know.
Base
Фронт-приложение
11
Область алгоритмических конструкций, принадлежащая сер-
Front application
вису «фронт-приложение»
Сервис ТБЗ
12
13
14
Technological Knowledge
струкций, принадлежащая сер-
Base
вису ТБЗ
Идентификация ин-
Анализ переданных данных для
Identification
формационной облас-
эффективного поиска связан-
Inform. Area
ти
ной информации
Получение адресов
Получение списка адресов всех
сервисов системы
сервисов системы для после-
Get System
дующего взаимодействия
Services Addresses
15
Query To Front
Запрос к сервису
Запрос к сервису «фронт-
«фронт-приложение»
приложение» и ожидание ответа
Application
16
Область алгоритмических кон-
Get Information
Функция получения
Функция получения из БД ин-
основных данных
формации основных данных
для проведения расчёта
17
Query To Info Collect
Запрос к сервису сбо-
Запрос к сервису сбора инфор-
Service
ра информации
мации и ожидание ответа
99
Таблица 3.1 – Обозначения алгоритмической схемы (продолжение)
№ Обозначение
Наименование
Семантика
п/п конструкции
18
19
20
Info. Rectification
конструкции
Функция уточнения
Актуализация и уточнение ин-
информации
формации путём обращения к
сервису сбора информации
Full Facts And
Выбор всех фактов и
Выбор всех фактов, подходя-
Rules Select
правил
щих для задачи в стек
Вычисление опти-
Вычисление оптимального раз-
Calculate Optimal
мального разбиения
биения данных в зависимости
Data Partition
данных
от размерности задачи и количества свободных сервисов
расчёта
21
Partial Facts And
Выбор части фактов и
Выбор части фактов, подходя-
правил
щих для задачи в системный
стек для формирования задания
Rules Select
и отправки на сервис расчёта
22
Compose Task
Формирование зада-
Формирование задания для
ния
проведения расчёта на удалённом сервисе
23
Send To Calc Service
Отправка задания на
Отправка задания на сервис
сервис расчёта
расчёта и дальнейшее выполнение без ожидания результата
Сервис расчёта
24
Область алгоритмических конструкций, принадлежащая сер-
Calc Service
вису расчёта
25
26
Возвращение резуль-
Возвращение результата расчё-
тата
та по заданию сервису ТБЗ
Last Task
Отправлено послед-
Постусловие окончания цикла
Been Send
нее задание
по формированию и отправке
Send Result Back
заданий сервисам расчёта
100
Таблица 3.1 – Обозначения алгоритмической схемы (продолжение)
№ Обозначение
Наименование
Семантика
п/п конструкции
конструкции
Collect All Results
Сбор результатов вы-
Ожидание результатов выпол-
From Calc Services
полнения заданий
нения заданий от сервисов расчёта, если они ещё не были по-
27
лучены; формирование списка
технологических цепочек
Save Result
28
Сохранение результа-
Сохранение результатов поиска
тов поиска
технологических последовательностей для пополнения
статистики
Return Result
29
Возвращение резуль-
Возвращение результатов по-
татов поиска
иска технологических последовательностей сервису «фронтприложение»
Алгоритм поиска оптимизированной рецептуры композитной смеси ИАС
ПОС (рисунок 3.8) предложен впервые и полностью направлен на описание
процесса выполнения основной функции специализированного ПС. Алгоритмы, также являющиеся важной частью системы и описывающие функционал
адаптации, пополнения и обучения ТБЗ ИАС ПОС, будут приведены в тексте
работы далее.
3.4 ТБЗ ИАС ПОС
ТБЗ – основа ИАС ПОС, на которой строится инновационный подход к
решению проблемы поиска оптимизированной рецептуры композитной смеси.
База знаний (БЗ) хранит структурированную информацию, относящуюся к определённой области знаний для использования в ПС. БЗ отличается от БД
структурной организацией информации, представляющей собой набор классов
101
и свойств, описывающих объекты предметной области, их взаимосвязь. БЗ содержат правила вывода, позволяющие делать автоматические умозаключения о
новых фактах, узнаваемых системой и производить осмысленную обработку
поступающих данных [61].
Иерархический набор понятий и отношений, представляемый в БЗ именуется онтологией. Онтология позволяет формализовать определённую область
знаний с помощью схемы, описывающей релевантные классы объектов с вязи
между ними, правила и ограничения, налагаемые предметной областью [69].
Онтология должна представлять знания в виде, удобном для машинной обработки, являясь своеобразным связующим звеном между человеком и машиной.
Существует несколько формальных языков описания онтологии: OWL [86],
RDF [87], KIF [88] и др.
3.4.1 Структура ТБЗ ИАС ПОС
Создание ТБЗ преследует конкретную, практическую цель – поиск и оптимизация технологических цепочек приготовления смесей. Перед проектируемой онтологией не ставится задача создания всеобъемлющего описания всего.
Онтология ИАС ПОС должна содержать классы и отношения конкретной
предметной области. Ценность такой онтологии лежит скорее в области понятия применимости, чем понятия полноты.
При этом разрабатываемая в этом разделе оригинальная структура ТБЗ
ИАС ПОС должна отражать фундаментальные понятия алгебры технологических цепочек приготовления смесей, составленной ранее во второй главе. Основными понятиями здесь являются: компонент смеси и его характеристические особенности; кластеризованная область качества; технологическая ситуация; технологический процесс; отношения следования, антиследования, независимости, общности и др.
Для построения структуры ТБЗ ИАС ПОС используем формальный язык
описания онтологии OWL, представляющий знания предметной области в тер-
102
минах модели «объект-свойство». Классы и свойства объектов могут наследоваться в соответствии с иерархией понятий, выражая модель «от общего к частному». Например, класс «Композитный компонент» является наследником более общего класса «Компонент», который, в свою очередь является наследником суперкласса «Thing». Иерархия наследования классов и свойств ТБЗ ИАС
ПОС наглядно выражена на древовидной схеме (рисунок 3.9) ниже.
Рисунок 3.9 – Иерархия наследования классов и свойств ТБЗ ИАС ПОС
Как можно видеть, все классы являются потомками суперкласса «Thing»,
а свойства – потомками «topObjectProperty». Связь классов и свойств записывается в документе схемы с помощью специализированного синтаксиса. Рассмотрим пример записи структуры компонентов ТБЗ ИАС ПОС на языке OWL.
103
Листинг 3.1 – Фрагмент онтологии «TechProcess»
<Declaration>
<Class IRI="#TechSituation"/>
</Declaration>
<AnnotationAssertion>
<AnnotationProperty abbreviatedIRI="rdfs:label"/>
<IRI>#TechSituation</IRI>
<Literal xml:lang="ru" datatypeIRI="&rdf;PlainLiteral">
Технологическая ситуация</Literal>
</AnnotationAssertion>
<SubClassOf>
<Class IRI="#TechSituation"/>
<Class abbreviatedIRI="owl:Thing"/>
</SubClassOf>
<SubClassOf>
<Class IRI="#TechSituation"/>
<ObjectAllValuesFrom>
<ObjectProperty IRI="#includeComponent"/>
<Class IRI="#Component"/>
</ObjectAllValuesFrom>
</SubClassOf>
<DisjointClasses>
<Class IRI="#Cluster"/>
<Class IRI="#Component"/>
<Class IRI="#Manufacturer"/>
<Class IRI="#TechSituation"/>
<Class IRI="#componentCharacteristic"/>
<Class IRI="#equipment"/>
<Class IRI="#equipmentCharact"/>
<Class IRI="#region"/>
<Class IRI="#techProcess"/>
<Class IRI="#techProcessCharacter"/>
</DisjointClasses>
<Declaration>
<ObjectProperty IRI="#includeComponent"/>
</Declaration>
<AnnotationAssertion>
<AnnotationProperty abbreviatedIRI="rdfs:label"/>
<IRI>#includeComponent</IRI>
<Literal xml:lang="ru" datatypeIRI="&rdf;PlainLiteral">
Включает компонент</Literal>
</AnnotationAssertion>
<ObjectPropertyDomain>
<ObjectProperty IRI="#includeComponent"/>
<Class IRI="#TechSituation"/>
</ObjectPropertyDomain>
<ObjectPropertyRange>
<ObjectProperty IRI="#includeComponent"/>
<Class IRI="#Component"/>
</ObjectPropertyRange>
104
Секция <Declaration> здесь обозначает объявление класса или свойства.
В приведённом листинге объявляется класс TechSituation и свойство includeComponent. Каждой сущности присваивается локальный IRI для доступа внутри
документа и глобальный адрес URI для доступа через глобальную сеть. Секция
<AnnotationAssertion> определяет название объекта и язык, на котором записано это название. В данном случае язык определён конструкцией xml:lang="ru"
тега <Literal>. Секция <SubClassOf> определяет предка сущности. Класс TechSituation является потомком класса Thing. Синтаксис OWL позволяет определять свойства класса с помощью тега <SubClassOf>. Таким образом, код, с помощью подсекции <ObjectAllValuesFrom> декларирует, что класс TechSituation
может быть связан с классом Component через свойство includeComponent. Фактически эту конструкцию можно выразить фразой: «Технологическая ситуация
может включать в себя объекты класса «Компонент» (вещества и материалы)».
Тег <ObjectAllValuesFrom> также допускает ситуацию, когда технологическая
ситуация не содержит ни одного компонента, являясь по сути нулевой константой «∅» алгебры технологических цепочек приготовления смесей (п.п. 2.3.4 гл.
2).
Каждое свойство имеет свой домен <ObjectPropertyDomain> и область
определения <ObjectPropertyRange>. В данном случае свойство includeComponent имеет в качестве домена класс TechSituation, а в качестве области определения множество объектов, принадлежащих классу Component. Таким образом
устанавливается семантическая связь между понятиями.
Тег <DisjointClasses> однозначно устанавливает, что входящие в него
классы являются в реальном мире разными сущностями. Например, технологическая ситуация ни при каких обстоятельствах не может являться регионом (region) или производителем (Manufacturer) и т.д.
Язык OWL позволяет определять атрибуты для свойств, и это является
полезным инструментом при разработке онтологии, основанной на алгебре технологических цепочек приготовления смесей. Приведём наглядный пример.
105
Листинг 3.2 – Фрагмент онтологии «TechProcess»
<Declaration>
<ObjectProperty IRI="#isEqual"/>
</Declaration>
<AnnotationAssertion>
<AnnotationProperty abbreviatedIRI="rdfs:label"/>
<IRI>#isEqual</IRI>
<Literal xml:lang="ru" datatypeIRI="&rdf;PlainLiteral">
Эквивалентность</Literal>
</AnnotationAssertion>
<Declaration>
<ObjectProperty IRI="#isNotEqual"/>
</Declaration>
<AnnotationAssertion>
<AnnotationProperty abbreviatedIRI="rdfs:label"/>
<IRI>#isNotEqual</IRI>
<Literal xml:lang="ru" datatypeIRI="&rdf;PlainLiteral">
Неравнство</Literal>
</AnnotationAssertion>
<InverseObjectProperties>
<ObjectProperty IRI="#isEqual"/>
<ObjectProperty IRI="#isNotEqual"/>
</InverseObjectProperties>
<SymmetricObjectProperty>
<ObjectProperty IRI="#isEqual"/>
</SymmetricObjectProperty>
<SymmetricObjectProperty>
<ObjectProperty IRI="#isNotEqual"/>
</SymmetricObjectProperty>
<TransitiveObjectProperty>
<ObjectProperty IRI="#isEqual"/>
</TransitiveObjectProperty>
<ReflexiveObjectProperty>
<ObjectProperty IRI="#isEqual"/>
</ReflexiveObjectProperty>
В листинге определяются свойства, описывающие отношения между
классами: isEqual (Эквивалентность) и isNotEqual (Неравнство). Эти отношениия входят в прикладную алгебраическую модель смеси компонентов и описаны
ранее в п.п. 2.3.2 главы 2. Для них в п.п. 2.3.3 также были определены свойства
рефлексивности, симметричности, и транзитивности (таблица 2.1).
Из приведённой части описания ТБЗ на языке OWL можно понять, что
отношения isEqual и isNotEqual являются противоположными, о чём говорит
тег <InverseObjectProperties>. Тег <SymmetricObjectProperty> определяет, что
isEqual и isNotEqual обладают свойством симметричности. Отношение isEqual
106
так же обладает свойствами транзитивности и рефлексивности, что обозначено
тегами <TransitiveObjectProperty> и <ReflexiveObjectProperty> соответственно.
Другие классы и свойства определяются в онтологии технологических
процессов похожим образом. Таблица 3.2 содержит описание основных семантических связей между центральными классами разрабатываемой онтологии, за
исключением иерархии наследования, рассмотренной ранее.
Таблица 3.2 – Семантические связи онтологии «TechProcess»
Связываемый Семантическая
Класс-область
Ограни-
класс
связь (свойство)
определения
чение
Технологическая
Включает компонент
Компонент
Only
Затрагивает оборудование
Оборудование
Only
Имеет исходную технологи-
Технологическая ситуация
Exactly 1
ситуация
ческую ситуацию
Технологический
Может быть выполнен
Производитель
Some
процесс
Обладает характеристикой
Характеристика техноло-
Some
гического процесса
Приводит к технологической
Технологическая ситуация
Exactly 1
Состоит из
Технологический процесс
Only
Состоит в отношении
Компонент
Some
Расположен в
Регион
Some
Обладает характеристикой
Характеристика компонен-
Min 1
ситуации
Компонент
Производитель
та
Имеет качество
Кластер
Some
Имеет производителя
Производитель
Some
Имеет оборудование
Оборудование
Some
Может выполнить процесс
Технологический процесс
Some
Расположен в
Регион
Some
Производит
Компонент
Min 1
107
Таблица 3.2 – Семантические связи онтологии «TechProcess» (продолжение)
Связываемый Семантическая
Класс-область
Ограникласс
Регион
Оборудование
связь (свойство)
определения
чение
Прилегает к региону
Регион
Only
Расположен в
Регион
Only
Обладает характеристикой
Характеристика оборудования
Some
Необходимо пояснить значения столбца «ограничения». Ограничение
«Exactly 1» означает, что связываемый класс, например «Технологический процесс», может иметь лишь одну связь типа «Имеет исходную технологическую
ситуацию» с объектом класса-области определения «Технологическая ситуация». Ограничение «Min 1» отличается от предыдущего тем, что указывает минимальное количество связей, в данном случае равное единице. Ограничение
«Only» говорит о том, что связываемый класс может иметь множество связей с
классами указанного типа и при этом допускает отсутствие таких связей. Ограничение «Some» имеет такую же семантику, как и «Only», но в отличие от последнего не допускает полного отсутствия связей и является эквивалентом ограничения «Min 1».
Более полное OWL-описание онтологии технологических процессов, основанной на универсальной прикладной алгебре технологических цепочек приготовления смесей, приводится в приложении 1. Разработанная в диссертационной работе онтология «TechProcess» предложена впервые, является универсальной и может быть неоднократно использована различными ПС для поиска
оптимизированной рецептуры композитных смесей.
При всём богатстве языка OWL, онтология не может содержать в себе
весь функционал ТБЗ. Фактически онтология - набор понятий и отношений
конкретной предметной области. Для продуктивного использования ТБЗ в качестве активного компонента ИАС ПОС, её функционал (например, операции
композиции « o » и « ⊕ ») должен иметь также программную реализацию.
108
3.4.2 Алгоритм адаптации ТБЗ ИАС ПОС
Алгоритм адаптации ТБЗ ИАС ПОС, разрабатываемый в рамках этой
диссертационной работы, основан на механизме обратной связи и использовании распределённой обработки статистических данных. С помощью него система может производить автокоррекцию хранимых данных, уточнять характеристики смесей, получаемых в ходе определённых технологических процессов.
Адаптация в данном случае понимается как попытка системы опереться на
практические данные, полученные в ходе реальных технологических процессов
на производстве. Механизм обратной связи ИАС ПОС основывается на том, что
пользователь, получив рецептуру смеси, рассчитанную системой, может указать качественные характеристики продукта, произведённого по этой технологии на своём предприятии. Таким образом накапливается статистика соответствий вида «Технологический процесс – реальный продукт». Эти данные можно
использовать для автоматической корректировки расчётов качественных характеристик смеси. Блок-схема алгоритма (рисунок 3.10) демонстрирует основные
особенности процесса адаптации.
Начало
Statistics Accumulation
TechProcess
Calculation
System output
Show Calculation
Result
User Input
Input Real
Result
Next User Calculation
1
Рисунок 3.10 – Алгоритм адаптации ТБЗ ИАС ПОС (начало)
109
1
Statistic Accumulated
Technological Knowledge Base
Select Holistic Data;
Prepare Related Info
Query To Front Application
Get System
Services Addresses
Send Task To
Calculation Services
Calc Service
Clustering Data;
Indexing Data
Calc Average Values;
Return Results
Get Calc Results
Foreach Result
Representative?
Да
Data Correction
Нет
Конец
Рисунок 3.10 – Алгоритм адаптации ТБЗ ИАС ПОС (продолжение)
Алгоритм адаптации описывает процесс, имеющий название «Data
Mining» или интеллектуальный анализ данных [89], направленный на обнаружение неочевидных зависимостей в массиве статистической информации. В частности, характеристики конечного продукта могут иметь ярко выраженную зависимость от типа оборудования, использовавшегося в процессе производства.
110
Таблица 3.3 содержит обозначения функций и модулей, задействованных в
блок-схеме алгоритма, за исключением описанных ранее в п. 3.3.
Таблица 3.3 – Обозначения алгоритмической схемы (начало)
№ Обозначение
Наименование
Семантика
п/п конструкции
1
Statistics Accumulation
конструкции
Накопление статисти-
Область алгоритмических кон-
ки
струкций, отражающая процесс
накопления статистики
2
TechProcess Calculation
Поиск оптимизиро-
Пользователь производит рас-
ванной рецептуры
чёт оптимизированной рецеп-
смеси
туры требуемого типа смеси
(рисунок 3.8)
3
Show Calculation
Вывод рецептуры
Пользователь получает рецептуру смеси
Result
Input Real
Ввод характеристик
После того, как смесь была
Result
продукта
приготовлена, пользователь
вводит характеристики полу-
4
ченного по предложенной технологии продукта
Next User Calculation
Следующий расчёт
Повторение процедуры накопления статистики разными
5
пользователями для разных
продуктов
Statistic Accumulated
Статистика накоплена Произведено достаточное количество расчётов для стати-
6
стической обработки
Select Holistic Data
7
Выборка полноцен-
Полноценными данными счи-
ных данных
таются полные пары «Рецептура - результат»
8
Prepare Related Info
Подготовка связан-
Присоединение к выбранным
ных данных
данным информации о технологических процессах
111
Таблица 3.3 – Обозначения алгоритмической схемы (продолжение)
№ Обозначение
Наименование
Семантика
п/п конструкции
9
конструкции
Send Task To
Запуск задания на
Запуск задания на сервисах
Calculation Services
сервисах расчёта
расчёта и ожидание результата
Clustering Data
Кластеризация дан-
Кластеризация данных на осно-
ных
ве характеристик технологиче-
10
ского процесса
Indexing Data
Свёртка данных
Свёртка кластеризованных
данных в индексированный
11
массив
Вычисление средних значений
12
Calc Average Values
Вычисление средних
качественных характеристик
значений
реальных продуктов для каждого элемента свёртки
13
14
15
Return Results
Get Calc Results
Foreach Result
Возвращение резуль-
Возвращение результатов сер-
татов
вису ТБЗ
Получение результа-
Получение результатов расчё-
тов
тов сервисом ТБЗ
Циклическая обра-
Цикл по массиву результатов
ботка
Representative?
16
Проверка условия ре-
Определение репрезентативно-
презентативности
сти выборки данных в текущем
кластере
Data Correction
17
Корректировка дан-
Корректировка информации о
ных
технологических ситуациях, к
которым приводят технологические процессы рассматриваемого кластера
Как можно увидеть из блок-схемы адаптации (рисунок 3.10), основному
алгоритму предшествует этап накопления некоторого необходимого количества
статистических данных. Объём таких данных со временем быстро увеличивается и процесс их обработки становится ресурсоёмким. Однако, процесс обработ-
112
ки вписывается в модель распределённых вычислений. Примером может служить модель «MapReduce» компании Google – технология, позволяющая производить рачёты параллельно с использованием большого количества вычислительных машин. Объём обрабатываемых данных при этом может достигать нескольких петабайт [90].
Алгоритм интеллектуального анализа данных (рисунок 3.10) использует
кластеризацию технологических процессов на основе схожести их характеристик, например, по модели оборудования, на котором производится продукт.
Этот шаг именуется Map-шагом в модели MapReduce. Он представляет собой
подготовку данных к свёртке. Следующий шаг алгоритма в терминологии
MapReduce именуется Reduce-шагом. На этом этапе выполняется свёртка данных по ключам-кластерам в индексированный массив и вычисление средних
значений качественных характеристик реальных продуктов для каждого элемента свёртки. После этого результаты расчётов возвращаются для проведения
корректировок в ТБЗ.
Необходимо добавить, что «MapReduce» не единственная технология
распределённых вычислений, применимая в данной ситуации. Разработанный
алгоритм адаптации ТБЗ ИАС ПОС не ограничивает разработчика и даёт возможность самостоятельной реализации технологии распределённых вычислений в рамках парадигмы SOA. Модель «MapReduce» была рассмотрена как
наиболее известная на данный момент во всём мире.
Фактически, алгоритм адаптации ТБЗ ИАС ПОС предложен впервые и
может быть классифицирован как DataMining-алгоритм реализующий кластерный анализ совместно с концепцией Memory Based Reasoning или «вывод путем
сопоставления». Согласно этой концепции, алгоритм реализует поиск наиболее
близких ситуаций в прошлом для коррекции результатов в будущих вычислениях [91].
113
3.4.3 Алгоритм пополнения и обучения ТБЗ ИАС ПОС с использованием облачных технологий
Для пополнения ТБЗ ИАС ПОС новыми данными в системе предусматривается два пути. Первый способ заключается в ручной актуализации ТБЗ и
информационной БД человеком – ИЗ. Второй способ представляет собой автоматизированную актуализацию данных с помощью специализированных сервисов системы, носящих название «сервисы сбора информации».
Механизм второго способа получения данных системой основывается на
обширном, масштабируемом взаимодействии с внешними ИС ГС, не входящими в состав ИАС ПОС и, по своей сути, представляет собой вид облачной технологии [92]. Масштабируемость реализуется с помощью регулирования количества сервисов сбора информации. Каждый такой сервис осуществляет импорт
данных из внешних источников в систему, являясь своеобразным адаптером.
Эти процессы могут протекать на сервисах ИАС ПОС параллельно, уменьшая
время сбора новых данных и одновременно увеличивая охват информационного пространства глобальной сети.
Процесс пополнения ТБЗ происходит опосредованно – сервис сбора информации пополняет БД информации ИАС ПОС данными о производителях,
оборудовании, продуктах, их характеристиках, стоимости и т.д. Таким образом,
при последующих поисках оптимизированных технологических цепочек сервис
ТБЗ будет использовать, в том числе, новые данные из информационной БД.
Обучение ТБЗ происходит путём прямой передачи информации о новых технологических процессах сервису ТБЗ. Кроме того, алгоритм поиска оптимизированной рецептуры композитной смеси ИАС ПОС (рисунок 3.8) предусматривает функцию уточнения информации. Перед расчётами сервис ТБЗ может запрашивать и актуализировать различную информацию путём запроса данных
через сервис сбора информации. Это могут быть, например, текущие курсы валют, которые можно использовать для расчёта стоимости компонентов смеси,
производимых за рубежом.
114
Блок-схема (рисунок 3.11) описывает общий вид разработанного в рамках
этой диссертационной работы алгоритма автоматизированного пополнения и
обучения ТБЗ ИАС ПОС.
Начало
Info Collect Service
Get System
Services Addresses
Query To
Front Application
Select
GlobalServices
Foreach GlobalServices
Request Info From
Current GlobalService
Foreach Info Row
Adapt Info
Query To Info DB
Нет
Нет
Tech
Process?
New
Info?
Да
Send Info To
Knowledge Base
Да
Save Info To DB
Tech. Know. Base
New
Info?
Нет
Да
Save Info
Конец
Рисунок 3.11 – Алгоритм пополнения и обучения ТБЗ ИАС ПОС
115
Таблица 3.4 содержит обозначения функций и модулей, задействованных
в блок-схеме алгоритма, за исключением описанных ранее в п. 3.3.
Таблица 3.4 – Обозначения алгоритмической схемы
№ Обозначение
Наименование
Семантика
п/п конструкции
1
Info Collect Service
конструкции
Сервис сбора инфор-
Область алгоритмических кон-
мации
струкций, принадлежащая сервису сбора информации
2
3
Select
Foreach GlobalServices
Выборка ИС ГС для сбора информации
GlobalServices
Циклическая обра-
Цикл по выбранным ИС ГС
ботка
Request Info From
4
Выборка сервисов
Запрос к ИС ГС
Запрос к текущему ИС ГС из
выборки с целью получения
Current GlobalService
новой информации; ожидание и
получение ответа
5
Foreach Info Row
Adapt Info
6
Циклическая обра-
Цикл по полученным от ИС ГС
ботка
информационным сущностям
Функция форматиро-
Адаптация текущей информа-
вания информации
ционной сущности к внутрисистемному формату ИАС ПОС
7
8
9
10
Tech Process?
Условие
Определение типа информации
New Info?
Условие
Определение новизны и полезности информации для системы
Сохранение инфор-
Сохранение полученных дан-
мации в БД
ных в информационной БД
Send Info To
Отправка информа-
Передача информации сервису
Knowledge Base
ции
ТБЗ без ожидания ответа
Tech. Know. Base
Сервис ТБЗ
Область алгоритмических кон-
Save Info To DB
струкций, принадлежащая сер-
11
вису ТБЗ
12
Save Info
Сохранение инфор-
Сохранение полученных дан-
мации
ных в ТБЗ
116
Необходимо отметить, что алгоритм пополнения и обучения ТБЗ
(рисунок 3.11) выполняется циклически, через определённые для каждого сервиса промежутки времени. Предложенный в данной работе оригинальный алгоритм обладает новизной в рассматриваемой предметной области. Он является
одним из основных конкурентных преимуществ для ИАС ПОС.
3.5 Оригинальные проектные решения, применяемые в
программном инструментарии
В этом пункте собраны все оригинальные проектные решения, найденные
в ходе разработки предлагаемой архитектуры ИАС ПОС. Эти решения дают
системе дополнительные преимущества перед конкурентными продуктами.
Проблема поиска и форматирования исходных данных для расчёта решается за счёт подключения к системе сервисов автоматизированного поиска и
импорта информации о предлагаемых продуктах в унифицированном формате.
Специалисту не требуется тратить время на поиск подходящих предложений и
форматированию данных для загрузки в программу расчёта. Большим плюсом
является дополнение системы хранилищем нормативной документации, позволяющей оценивать соответствие продукции общепринятым и государственным
стандартам [93]. Полномочия по оценке соответствия стандартам передаются
сервису ТБЗ. Такое совмещение выглядит логичным: ТБЗ работает со знаниями
о продукции и кластеризует её, основываясь на качественных характеристиках
(гл. 2, п. 2.3.1).
Использование этих решений, в свою очередь, позволяет автоматизировать процесс формирования ограничений для задачи поиска оптимизированных
смесей, исходя лишь из заданного пользователем типа продукта [94]. Такой
подход ускоряет отбор и увеличивает количество пригодных для расчёта данных, при этом возрастает и размерность задачи оптимизации.
Проблема размерности и, соответственно, времени решения большой задачи оптимизации может быть решена частично за счёт использования сервисов параллельных вычислений [94]. Модульность SOA позволяет распределить
117
нагрузку на несколько ЭВМ абсолютно незаметно для пользователя [35]. При
этом количество сервисов расчёта может быть достаточно большим для решения задач оптимизации повышенной размерности.
Более того, архитектура ИАС ПОС предполагает формирование заданий
для расчётов, что в соответствии с парадигмой SOA, позволяет использовать не
только сервисы расчёта, разработанные специально для конкретного ПС. Современные сервисы облачных вычислений, предоставляемые такими большими
компаниями как Amazon [95], Google [96], IBM [97], Microsoft [98] и др., могут
быть использованы для проведения расчёта оптимизированной смеси в составе
ИАС ПОС. Перечисленные облачные решения имеют огромную мощность, что
может позволить решать объёмные вычислительные задачи поиска оптимизированных смесей за сравнительно короткое время.
Также нужно отметить, что размерность задачи в ИАС ПОС уменьшается
ещё на этапе формирования задания сервисом ТБЗ, который отбирает исходные
данные для расчёта на основании многих критериев. Примером может служить
отбор технологических ситуаций по типу установленного промышленного оборудования и возможности / невозможности выполнить тот или иной технологический процесс на конкретном предприятии.
Возможность накопления, хранения и использования статистики, её интеллектуальный анализ, является конкурентным преимуществом ИАС ПОС.
Так как технология SOA позволяет организовать многопользовательский доступ к приложению, объём собираемых данных о проводимых расчётах будет
большим, статистические выборки – репрезентативными, а использование механизма автокоррекции положительно скажется на точности вычислений [93].
Предлагаемая архитектура позволяет при необходимости дублировать все
свои компоненты, кроме фронт-приложения, выполняющего роль централизующего элемента системы. Дублирование повысит надёжность ИАС ПОС. Для
увеличения мощности узлов системы можно увеличить количество компонент,
выполняющих ту или иную функцию. Например, ввод в систему новых сервисов сбора информации, работающих с различными источниками, позволит уве-
118
личить количество собираемых данных в единицу времени. Использование распределённых БД при необходимости позволит увеличить объём хранимой информации [99]. На данный момент времени в этой области существуют такие
решения как MongoDB [100], Windows Azure Federations, VoltDB, Cassandra,
MySQL Cluster, Oracle Cluster Database [101] и др.
3.6 Анализ спроектированной ИАС
Анализируя особенности разработанной в этой главе ИАС ПОС можно
говорить о том, что она может быть классифицирована как решение из области
облачных технологий [35]. Разрабатываемая ПС в этом контексте реализует облачную бизнес-модель «программное обеспечение как услуга» или SaaS (англ.
«Software-as-a-Service»). Эта бизнес-модель достаточно широко распространена
на западе в отличии от РФ. Причиной тому служит недоверие российских компаний к аутсорсингу [102]. Однако, такое недоверие тормозит развитие не
только области SaaS-предложений, но и всех аутсорсинговых услуг в целом.
Внедрение облачных решений такого уровня имеет больше положительных
сторон, чем отрицательных.
В частности ПС, реализующее архитектуру ИАС ПОС, представленную в
этой главе, может иметь целый ряд преимуществ перед конкурентными программными продуктами. ТБЗ, основанная на алгебре технологических цепочек
приготовления смесей (гл. 2), предлагает качественно новый подход к решению
проблемы поиска и оптимизации рецептуры. SOA предлагает решение таких
проблем как: большая размерность задачи, поиск, импорт и хранение информации. Масштабируемость позволяет системе находить баланс между своей производительностью и стоимостью. Углублённые профильные знания не являются обязательным условием для пользователей системы.
Разработанный алгоритм структурной композиции ИС поиска оптимизированной рецептуры смеси (п. 3.3) способен обеспечить требуемую ПС вычислительную мощность, универсален и обладает достаточной гибкостью для ра-
119
боты с компонентами различного типа. Интеллектуальные алгоритмы адаптации (п. 3.4.2), пополнения и обучения (п. 3.4.3) ТБЗ с течением времени способствуют росту системы, как в физическом, так и в интеллектуальном смысле.
Спроектированная ИАС ПОС является универсальным решением в области
расчёта оптимизированных композитных смесей различного типа.
Основные результаты
1.
Рассмотрены основные архитектурные и технические решения, при-
меняемые в существующих программных системах автоматизации технологии
изготовления смесей, произведён их анализ и оценка, выявлены достоинства и
недостатки.
2.
На основе разработанного математического формализма технологи-
ческих процессов изготовления смесей и анализа существующих программных
решений в этой области сформулированы концептуальные особенности проектируемой интеллектуальной системы, позволяющие вывести процесс оптимизации на качественно новый уровень.
3.
Разработана базовая архитектура ИАС ПОС, создан необходимый
набор схем для проектирования ПО: диаграмма прецедентов, диаграмма компонентов, диаграмма взаимодействия.
4.
Разработан алгоритм структурной композиции ИС, расширяющий
алгоритм унификации, рассмотренный в пункте 2.7 главы 2. Представленная
общая схема алгоритма поиска оптимизированной рецептуры композитной смеси ИАС ПОС (рисунок 3.8) раскрывает основные особенности решения задачи с
архитектурно-технической точки зрения в спроектированной распределенной
системе. Алгоритм позволяет распределить вычислительную нагрузку на множество ИС ГС и решать задачи повышенной размерности.
5.
Предложена универсальная структура ТБЗ ИАС ПОС, позволяющая
хранить знания о композитных материалах разнообразной природы, их характеристиках и критериях качества, технологических ситуациях и возможности
120
перехода из одной такой ситуации в другую. Также предложенная структура
ТБЗ позволяет автоматизировать процесс поиска рецептуры композитных смесей.
6.
Разработана универсальная онтология «TechProcess» для производ-
ства компонентных смесей, которая может быть применена не только в данной
конкретной системе, но также и для широкого круга ПС, работающих с понятиями смежных предметных областей.
7.
Разработан оригинальный алгоритм структурной композиции ИС
для адаптации (автокоррекции) ТБЗ на основе статистики по практическому
производству композитных смесей. Интеллектуальный анализ данных опирается на методы кластеризации и концепцию «вывод путем сопоставления». Алгоритм позволяет уточнять прогнозные характеристики композитной смеси.
8.
Разработан оригинальный алгоритм структурной композиции ИС
для автоматического пополнения и обучения ТБЗ с использованием облачных
технологий. Алгоритм позволяет автоматизировать процесс поиска и форматирования исходных данных для задачи поиска оптимизированных смесей, а так
же процесс поиска и импорта новых технологий производства.
9.
Приведены и обоснованны проектные решения ИАС ПОС, выделе-
ны основные конкурентные преимущества системы, обеспечиваемые этими
проектными решениями.
10.
Проведён анализ спроектированной ИАС и её архитектуры. ПС,
разрабатываемые по приведённой в этой главе архитектуре могут быть классифицированы как решения из области облачных технологий, реализующие бизнес-модель «программное обеспечение как услуга» или SaaS.
121
ГЛАВА 4. АВТОМАТИЗИРОВАННАЯ СИСТЕМА ПОИСКА
ОПТИМИЗИРОВАННЫХ КОМПОЗИТНЫХ СМЕСЕЙ ДЛЯ
ПРОИЗВОДСТВА КАРТОНА
4.1 Цель и задачи проектирования автоматизированной
системы «Composite-S v.1.0»
Целью проектирования автоматизированной системы «Composite-S v.1.0»
является интеллектуальный поиск оптимизированных рецептур производства
ГК. Под рецептурой здесь понимаются рекомендации по компонентному составу продукта и описание технологической цепочки производства. Фактически,
спроектированная система должна решать реальную задачу поиска оптимизированной композиции компонентов ГК, поставленную на производстве в ЗАО
«Многоотраслевая производственная компания «КРЗ». Эта задача была рассмотрена в п. 1.2.1 первой главы диссертационной работы. При этом ПС «Composite-S v.1.0» должно продемонстрировать преимущества перед конкурентными ПС.
Таким образом, основными задачами проектирования автоматизированной системы «Composite-S v.1.0» являются:
– реализация масштабируемой программной системы, основанной на архитектуре ИАС ПОС, рассмотренной в главе 3;
– дополнение онтологии технологических процессов знаниями о предметной области целлюлозо-бумажного производства;
– устранение основных недостатков, выявленных при анализе конкурентных ПС;
– реализация достаточного количества преимуществ, предоставляемых
архитектурой ИАС ПОС, позволяющих системе «Composite-S v.1.0» быть конкурентоспособным продуктом.
122
4.2 Архитектура автоматизированной системы «Composite-S
v.1.0»
4.2.1 UML-диаграмма компонентов ПС «Composite-S v.1.0»
Диаграмма, проектируемая в этом разделе, базируется на основе диаграммы компонентов ИАС ПОС, рассмотренной в третьей главе. Схема
(рисунок 4.1) раскрывает основные особенности архитектуры ПС «Composite-S
v.1.0».
Рисунок 4.1 – Диаграмма компонентов ПС «Composite-S v.1.0»
Диаграмма компонентов наследует все особенности базовой архитектуры
ИАС ПОС, изложенные подробно в третьей главе. Однако, ПС «Composite-S
v.1.0» не имеет графического интерфейса обучения ТБЗ. Также, базовая архитектура ИАС ПОС (рисунок 3.6, гл. 3) предполагает наличие двух баз данных:
«БД пользователей и сервисов системы» и «Информационная БД». Однако, в
конкретной программной реализации «Composite-S v.1.0» эти БД объединены
без потери функциональности. Подробнее структура БД «Composite-S v.1.0»
рассматривается в п. 4.2.3 текущей главы. Необходимо отметить, что диаграм-
123
ма так же содержит «БД фактов и правил», однако этот компонент специфичен:
хранимые факты и правила входят в состав ТБЗ. Не смотря на то, что структура
ТБЗ отлична от привычной структуры реляционной БД, основные сущности,
такие как технологический процесс, технологическая ситуация и др. отражаются в информационной БД ПС «Composite-S v.1.0». Это решение позволяет облегчить доступ к хранимым данным ТБЗ, сделать процесс вывода рецептуры
смесей более лёгким.
Также для ПС «Composite-S v.1.0» конкретизируется количество сервисов
расчёта, которых должно быть не менее шести и количество сервисов сбора
информации, равное двум. Число сервисов расчёта было выбрано эмпирически
исходя из приемлемого соотношения суммарной мощности машин и потерь
времени на передачу данных по сети. Два сервиса сбора информации берут на
себя две разные функции: пополнение БД и обучение ТБЗ соответственно.
Таким образом, структура ПС «Composite-S v.1.0» основывается на базовой архитектуре ИАС ПОС, изложенной в третьей главе и конкретизирует её.
4.2.2 Структура ТБЗ «Composite-S v.1.0»
Структура ТБЗ разрабатываемого ПС «Composite-S v.1.0» основывается
на структуре ИАС ПОС (п. 3.4.1 гл. 3) и дополняет её знаниями о предметной
области целлюлозо-бумажного производства. На схеме (рисунок 4.2) представлены новые классы онтологии технологических процессов, описывающие свойства компонентов для производства ГК.
124
Рисунок 4.2 – Иерархия классов ТБЗ «Composite-S v.1.0»
Эти характеристики соответствуют ГОСТ [54,103,104,105,106] и могут
служить для объективной оценки качества продукта.
ТБЗ дополняется следующими объектами класса «Технологический процесс»: размол; внос добавок (антисептик, коагулянты); отлив; сушка; прессование; отбелка; мелование; проклейка; гофрирование; склейка и др. ИЗ вносит в
ТБЗ типовые технологические ситуации Cs и связывает их с технологическими
процессами.
Таким образом, ТБЗ «Composite-S v.1.0» позволит создавать рецептуру
производства картона в терминах разработанной алгебры поиска технологиче-
125
ских цепочек (гл. 2). Например, следующая схема (рисунок 4.3) иллюстрирует
построение компонентом ТБЗ «Composite-S v.1.0» альтернативных технологических цепочек.
Csn
Csn+1
Cs0
Cs4
Cs6
Cs3
Cs5
Csr1
Csr2
Cs1
Cs2
Рисунок 4.3 – Технологические цепочки в ПС «Composite-S v.1.0»
На схеме (рисунок 4.3) технологическая ситуация Cs0 представляет собой
исходную ситуацию на каком-либо конкретном производстве. Например, изначально производитель имеет в своём распоряжении лишь крахмальный клей и
макулатуру. Конечные технологические ситуации Csr1 и Csr2 представляют собой такие ситуации, к которым технолог хочет придти из исходной ситуации
Cs0 . Ситуации Csr1 и Csr2 могут содержать в качестве компонентных веществ,
например, ГК марки Т21 и Т22 по ГОСТ [104] соответственно. При этом существует несколько альтернативных технологических процессов, приводящих из
Cs0 в Csr1 и Csr2 , включающих в себя также промежуточные технологические
ситуации. Например, технологический процесс {Cs0 – Cs3} представляет собой
производство КПС из имеющейся макулатуры, {Cs3 – Cs5} производство БГ,
{Cs5 – Csr2} процесс склеивания слоёв ГК. В то же время, производитель может
выбрать альтернативную ветку решения технологической задачи: закупить
КПС и БГ у сторонних организаций (процессы {Cs0 – Cs1} и {Cs0 – Cs3}) и
склеить слои ГК на своём производстве (процессы {Cs1 – Csr2} и {Cs2 – Csr2}).
126
При этом технологические процессы могут состоять из нескольких подпроцессов. Например, если процесс {Cs0 – Cs4} представляет собой производство
КПС, и при этом Cs3 ≠ Cs4 , то он может включать в себя подпроцессы вноса в
продукт различных добавок: антисептиков (процесс {Cs0 – Csn}), коагулянтов
(процесс {Csn – Csn+1}) и т.д.
Разные технологические цепочки могут приводить к одинаковому результату, например, к ситуации Csr2. Однако, стоимость, трудоёмкость и пр. характеристики всего технологического процесса {Cs0 – Csr2} могут значительно отличаться. Механизм ТБЗ «Composite-S v.1.0», основанный на алгебре поиска
технологических цепочек (гл. 2) позволяет выбрать технологический процесс,
близкий к оптимальному.
Более полное OWL-описание онтологии технологических процессов, основанной на универсальной прикладной алгебре технологических цепочек приготовления смесей, приводится в приложении 1. Предложенная в этом пункте
дополненная онтология «TechProcess» может быть использована различными
ПС для реализации поиска наименее затратных технологий производства ГК и
его компонентного состава.
4.2.3 Структура БД «Composite-S v.1.0»
Процесс проектирования включает в себя составление ER-диаграммы, позволяющей описать концептуальную схему БД
[107,108]. БД «Composite-S
v.1.0» служит для хранения информации о пользователях и сервисах, входящих
в состав системы. Каждый пользователь «Composite-S v.1.0» представлен в БД
записью аккаунта. Каждый сервис системы представлен записью, содержащей
его сетевой адрес и тип, указывающий, какие функции выполняет этот сервис:
расчёт, ТБЗ и т.д.
Для лучшего понимания архитектуры БД, входящей в состав «CompositeS v.1.0», составлена оригинальная ER-диаграмма (рисунок 4.4).
127
Рисунок 4.4 – ER-диаграмма БД «Composite-S v.1.0»
128
Информация о технологических процессах и ситуациях, продукции, производителях, оборудовании и стандартах представлена соответствующими таблицами в БД.
4.2.4 Выбор средств для разработки
При построении сервис-ориентированной системы важную роль играет не
только задача разработки самих информационных сервисов, но также и задача
коммуникации между ними. Для разработчика в таких условиях первостепенную важность приобретает наличие удобных библиотек, классов на выбранном
им ЯП, позволяющих реализовывать веб-службы и взаимодействовать с ними
[109].
Технология взаимодействия сервисов, основывающаяся на WSDL, языконезависима. Однако, различные языки программирования предоставляют различный уровень удобства работы с этой технологией. Таблица 4.1 содержит результаты анализа поддержки работы с ИС в различных ЯП.
Таблица 4.1 – Поддержка работы с ИС в различных ЯП
Язык программирования
Поддержка
работы с ИС
С++
С#
PHP
Java
Стандартная
-
+/-
+
+/-
Сторонняя
+
+
+
+
Самостоятельная
+
+
+
+
Наличие и отсутствие средств работы с ИС по протоколу SOAP для каждого языка помечаются знаками «+» и «-» соответственно. Стандартная поддержка засчитывается, если в языке изначально присутствуют необходимые для
разработки средства, сторонняя – в том случае, если существуют библиотеки
или классы, разработанные третьими лицами. Самостоятельная поддержка оп-
129
ределяется принципиальной возможностью разработки своего средства взаимодействия с ИС [35].
Для создания веб-сервисов и взаимодействия с ними в PHP существуют
стандартные классы «SoapServer» и «SoapClient», реализующие полный необходимый функционал. В том числе, «SoapClient» предоставляет возможность
парсинга заранее неизвестного программе WSDL во время исполнения скрипта.
Соответственно, эта особенность открывает большие возможности для динамического связывания самых разных сервисов глобальной сети [109].
Исходя из проведённого анализа, для разработки был выбран ЯП PHP.
Учитывая тот факт, что «Composite-S v.1.0» является довольно масштабной
системой, разумно будет использовать современный PHP-framework для упрощения разработки. После сравнения возможностей и особенностей популярных
фреймворков [110,111] для разработки компонентов ПС «Composite-S v.1.0»
был выбран Yii-framework [112].
В качестве СУБД для ПС «Composite-S v.1.0» выбрана MySQL [113]. Эта
СУБД кросплатформенна, распространяется по свободной лицензии GNU GPL
и обладает всем необходимым функционалом [114]. Также СУБД MySQL полностью совместима как с PHP в целом [115] так и с Yii-framework в частности
[116].
Для
программирования
пользовательского
интерфейса
фронт-
приложения в ПС «Composite-S v.1.0» используются технологии HTML и CSS
[117,118]. Эти технологии являются наиболее распространёнными на данный
момент времени и хорошо зарекомендовали себя в области построения удобных, гибких и красивых пользовательских интерфейсов с богатыми возможностями.
130
4.3 Основные классы программного инструментария для
реализации задачи автоматизации в рамках объектноориентированного программирования
Классы компонента ТБЗ ПС «Composite-S v.1.0» достаточно подробно
раскрываются онтологией технологических процессов рассмотренной ранее.
Программная реализация этих классов дополняет логику онтологии такими
функциями, как:
- рекурсивный подсчёт стоимости технологического процесса;
- сравнение технологических ситуаций из одного кластера по какомулибо признаку;
- get и set методы для protected полей класса и др.
Более подробное описание структуры классов компонента ТБЗ ПС
«Composite-S v.1.0» приводится в приложении 1.
Однако, помимо классов ТБЗ, задача автоматизации в рамках объектноориентированного программирования требует наличия целого ряда классов,
обеспечивающих внутреннюю коммуникацию и функционирование распределённой SOA-системы. В частности, Yii-framework, выбранный для разработки
ПС «Composite-S v.1.0» реализует архитектурный шаблон проектирования
MVC (англ. Model View Controller) [112]. Архитектурный шаблон MVC организует структуру классов приложения таким образом, чтобы изменения одного из
компонентов оказывали минимальное воздействие на все остальные [119]. В
настоящее время шаблон MVC широко используется для построения архитектурных каркасов приложений и представляет собой эффективную технологию
разработки ПС [120]. Потоки данных между классами компонентов ПС
«Composite-S v.1.0», основанных на шаблоне MVC, схематично могут быть
представлены следующим образом (рисунок 4.5).
131
Модель
2. Создание экземпляров моделей
для обработки данных
3. Сформированный объект
Пользователь
1. HTTP-запрос
Контроллер
4. Передача объекта
для отображения
6. HTTP-ответ
5. Шаблон с данными объекта
Представление
Рисунок 4.5 – Потоки данных между классами в ПС «Composite-S v.1.0»
4.3.1 Классы моделей ПС «Composite-S v.1.0»
Модель в шаблоне MVC представляет собой класс, в котором сконцентрирована бизнес-логика приложения [121]. Часто модели используют также в
качестве компонент Active Record [122] для коммуникации с БД. В ПС «Composite-S v.1.0» эти два подхода объединены.
Концепция ПС предполагает многопользовательский доступ к приложению. Каждый пользователь представляется в системе уникальным объектом
класса-модели. В качестве примера рассмотрим наиболее интересную часть
кода класса-модели User.
Листинг 4.1 – Фрагмент модели «User»
class User extends CActiveRecord {
const ROLE_GUEST = 0; // Роль «гость»
const ROLE_USER = 1; // Роль «пользователь»
const ROLE_ADMIN = 2; // Роль «администратор»
/**
* @return string Имя связанной таблицы БД
*/
public function tableName() { return 'tb_user'; }
/**
* @return array Правила валидации
*/
public function rules() {
return array(
array ('email, passwd, first_name, last_name',
'required'),
array('role', 'numerical', 'integerOnly' => true),
132
array('role', 'in', 'range' => array
(self::ROLE_GUEST, self::ROLE_USER, self::ROLE_ADMIN)),
array ('email, first_name, last_name, patro_name',
'length', 'max' => 255),
array('passwd', 'length', 'max' => 70),
array('email', 'email'),
); }
/**
* @return array Связи с другими таблицами БД
*/
public function relations() {
return array(
'workers' => array(self::HAS_MANY, 'Worker',
'id_user'),
); }
/**
* @return string ФИО пользователя
*/
public function getFio() {
return trim($this->last_name . ' ' . $this->first_name
. ' ' . $this->patro_name); }
protected function beforeSave() {
if (parent::beforeSave()) {
if ($this->isNewRecord) {
$this->passwd = CPasswordHelper::hashPassword
($this->passwd);
} } … }
Класс User является наследником класса CActiveRecord, в котором реализуется функционал для работы с БД. CActiveRecord в свою очередь наследуется
от класса CModel – базового элемента шаблона MVC.
ПС «Composite-S v.1.0» использует механизм разделения доступа на основе ролей или RBAC (англ. Role Based Access Control) [123]. Поэтому одним
из элементов бизнес-логики класса User являются константы ROLE_GUEST,
ROLE_USER и ROLE_ADMIN, определяющие, как будет представлена роль
пользователя в системе.
Метод rules() определяет правила валидации (проверок), выполняемых
при каких-либо действиях с объектом модели User. Например, поле «role»
должно быть целым числом, принадлежащим множеству {ROLE_GUEST,
ROLE_USER, ROLE_ADMIN}. Если объект модели будет заполнен некорректными данными, ПС «Composite-S v.1.0» сгенерирует соответствующие сообщения об ошибках, основываясь на правилах валидации.
133
Метод relations() описывает связи между моделями ПС «Composite-S
v.1.0», которые являются отражением связей в БД. В данном случае User имеет
связь один-ко-многим с Worker по внешнему ключу (полю) «id_user».
В качестве примеров описания бизнес-логики в листинге приведены также метод формирования ФИО пользователя и метод, шифрующий введённый
пароль для хранения в БД. Идентично классу User созданы модели для всех
таблиц БД ПС «Composite-S v.1.0» (п.п. 4.2.3). Каждая модель реализует часть
бизнес-логики приложения.
4.3.2 Классы интерфейсов ИС ПС «Composite-S v.1.0»
Представление (View) ПС «Composite-S v.1.0» фактически является набором шаблонов на языках HTML и CSS, которые после заполнения данными передаются пользователю через контроллер (Controller). Набором классов коммуникационных интерфейсов ИС в данном случае является именно контроллер,
так как он принимает запрос и формирует ответ (рисунок 4.5).
Yii-framework предоставляет богатый функционал, позволяющий использовать классы-контроллеры для реализации интерфейсов веб-сервисов [124].
Посредством классов-контроллеров ПС «Composite-S v.1.0» реализует протокол
SOAP и формирует WSDL-описания для взаимодействия ИС внутри системы.
В качестве примера рассмотрим класс ServiceController, реализующий
интерфейс фронт-приложения ПС «Composite-S v.1.0».
Листинг 4.2 – Фрагмент контроллера «ServiceController»
class ServiceController extends Controller {
/**
* Вывод WSDL-описания сервиса
*/
public function actions() {
return array(
'wsdl' => array('class' => 'CWebServiceAction'),
); }
/**
* Получение адресов сервисов
* @param int Тип сервиса
134
* @return string JSON-список сервисов
* @soap
*/
public function getSrvAdress($srvType) {
return json_encode(Service::findService($srvType));
}
/**
* Проверка статуса сервиса
* @return string Статус сервиса
* @soap
*/
public function getStatus() { return 'OK'; }
}
ServiceController – наследник класса Controller – базового элемента шаблона MVC, который реализует функционал по обработке HTTP-запросов и выдаче HTTP-ответов. Каждый метод класса представляет собой функцию, которую можно вызвать, используя протокол SOAP. На основе комментариев
PHPDoc [125] описание интерфейса ИС дополняется тегами документации
WSDL [126]. Идентично классy ServiceController созданы классы интерфейсов
для каждого компонента ПС «Composite-S v.1.0»: ТБЗ, сервисы расчёта, сервисы сбора информации. Полученные в результате использования такого подхода
WSDL-описания интерфейсов приводятся в приложении 2.
4.4 Особенности функционирования автоматизированной
системы «Composite-S v.1.0»
4.4.1 Требования к аппаратно-программному комплексу ПС
«Composite-S v.1.0»
Минимальными требованиями к аппаратной части ПС «Composite-S
v.1.0» являются:
−
одна машина-сервер с процессором Intel Pentium 4 или аналогич-
ным AMD;
−
1 гб ОЗУ;
−
50 гб памяти на жёстком диске;
−
монитор с диагональю 17 дюймов, клавиатура, мышь;
135
−
соединение с глобальной сетью Интернет на скорости от 5 мбит/с.
Требования к программному окружению машины-сервера:
−
ОС Linux/Windows/MacOS;
−
настроенный веб-сервер Apache с модулем поддержки PHP;
−
СУБД MySQL.
При выполнении минимальных требований ПС «Composite-S v.1.0» работоспособно, однако преимущества, которые даёт SOA, в этом случае будут сведены к минимуму или полному их отсутствию. Например, увеличение скорости
расчёта путём распределённой обработки данных на одном сервере будет невозможно. Для полноценного функционирования ПС «Composite-S v.1.0» рекомендуемыми являются следующие требования.
Одна машина-сервер для компонент «фронт-приложение» и «Информационная БД», имеющая характеристики:
−
процессор Intel Pentium 4 или аналогичный AMD;
−
512 мб ОЗУ;
−
50 гб памяти на жёстком диске (или более, по мере увеличения ко-
личества информации в БД);
−
соединение с глобальной сетью Интернет на скорости от 5 мбит/с.
Одна машина-сервер для компонент «Сервис сбора информации», имеющая характеристики:
−
процессор Intel Pentium 4 или аналогичный AMD;
−
512 мб ОЗУ;
−
8 гб памяти на жёстком диске;
−
соединение с глобальной сетью Интернет на скорости от 10 мбит/с.
Одна машина-сервер для компоненты «Сервис ТБЗ», имеющая характеристики:
−
процессор Intel Core 2 Duo или аналогичный AMD;
−
2 гб ОЗУ;
−
20 гб памяти на жёстком диске;
136
−
соединение с глобальной сетью Интернет на скорости от 10 мбит/с.
Одна машина-сервер для каждого компонента «Сервис расчёта», имеющая характеристики:
−
процессор Intel Core 2 Duo или аналогичный AMD;
−
1 гб ОЗУ;
−
10 гб памяти на жёстком диске;
−
соединение с глобальной сетью Интернет на скорости от 10 мбит/с.
Требования к программному окружению перечисленных машин-серверов
идентичны рассмотренным ранее требованиям минимальной конфигурации
«Composite-S v.1.0», за исключением СУБД MySQL. ПО MySQL должно быть
установлено лишь на машину-сервер, предназначенную для компоненты «Информационная БД».
4.4.2 Работа с ПС «Composite-S v.1.0»
Для работы с ПС «Composite-S v.1.0» пользователю не нужно устанавливать никакого дополнительного программного обеспечения, достаточно с помощью браузера перейти на URL фронт-приложения. Доступ к ПС «CompositeS v.1.0» возможен с любых устройств, включая мобильные.
Интерфейс автоматизированной системы представлен динамическими
веб-страницами. Для начала работы пользователю необходимо пройти авторизацию (рисунок 4.6), чтобы идентифицировать себя в системе.
137
Рисунок 4.6 – Интерфейс авторизации «Composite-S v.1.0»
После авторизации пользователь может просматривать сведения о продукции, предлагаемой другими пользователями (предприятиями), а так же добавлять продукцию своего предприятия (рисунок 4.7).
Рисунок 4.7 – Форма добавления продукта «Composite-S v.1.0»
138
Добавляемая в систему продукция может быть использована при поиске
рецептур производства ГК другими пользователями. Это обстоятельство стимулирует производителей к поиску оптимального соотношения цена/качество
для поддержания конкурентоспособности своей продукции.
Для поиска оптимизированного компонентного состава гофрированного
картона пользователь должен заполнить форму «Новый рецепт» (рисунок 4.8),
указав информацию о желаемом целевом продукте, наличии исходных компонентов и пр.
Рисунок 4.8 – Постановка задачи оптимизации в «Composite-S v.1.0»
Алгоритм ПС «Composite-S v.1.0» в соответствии с заданными пользователем ограничениями по качеству ищет оптимизированную рецептуру, минимизируя суммарную стоимость технологического процесса и вес готового продукта. Результатом использования разработанного во второй и третьей главах
диссертации подхода к процессу оптимизации смесей становится возможность
139
вывода последовательных технологических шагов с подробными характеристиками каждого из них (рисунок 4.9).
Рисунок 4.9 – Просмотр рецепта в «Composite-S v.1.0»
Каждый процесс представлен в виде раскрывающейся панели, на которой
отображается информация о нём. Интерфейс ПС «Composite-S v.1.0» не требует
от пользователя углублённых знаний предметной области, является интуитивным и дружественным.
140
4.5 Оценка эффективности внедрения автоматизированной
системы «Composite-S v.1.0»
Для того, чтобы дать объективную оценку эффективности внедрения автоматизированной системы «Composite-S v.1.0» проведено сравнение этой системы с рассмотренными в диссертационной работе ранее ПС:
−
программа «Рецептура асфальто-бетонной смеси 1.0»;
−
программа «АСР «ОРПС»;
−
программа «КОРАЛЛ – Кормление птицы»;
−
система «SMART! Fertilizer Management Software».
ПС «Composite-S v.1.0» разработано с использованием качественно нового подхода к решению проблемы композиции смесей, как с математической,
так и с архитектурно-технической точки зрения. Конкурентные ПС используют
классический подход к решению проблемы смешивания. Таким образом, наиболее объективными способами сравнения этих программных продуктов являются:
−
сравнение темпа роста фактического времени расчёта (временной
сложности алгоритма [127]) разных ПС при увеличении размерности входных
данных;
−
сравнение функциональных возможностей ПС.
4.5.1 Исходные данные и условия экспериментов
Производимый анализ предполагает серию экспериментов и сравнение
темпа роста среднего времени работы (математического ожидания времени работы) алгоритмов рассматриваемых ПС. Фактически, искомой качественной
характеристикой ПС является чувствительность алгоритма к увеличению размерности задачи. Сложность алгоритма может быть определена как:
O( f (n )) ,
(4.1)
141
если при увеличении размерности входных данных n, время выполнения алгоритма возрастает с той же скоростью, что и функция f (n ) [128].
Пусть необходимо оптимизировать смесь, состоящую из четырёх видов
компонентов xj (j=1,…,4), соблюдая требования качества и минимизируя её
стоимость. Таким образом, тестовая задача для всех ПС приводится к максимально возможно похожей форме, что важно для экспериментального сравнения.
Было проведено шесть серий экспериментов Sn (n = 20, 32, 40, 52, 60, 72)
для разной размерности входных данных n, так как время работы рассматриваемых алгоритмов оптимизации меняется нелинейно в зависимости от значения n. Компоненты смесей, являющиеся входными данными, были сгенерированы на основе соответствующих ГОСТов [104,129,130,131,132] и информации,
доступной на ИС ГС. Такое решение было принято для удобства ввода исходных данных в ПС и сокращения временных затрат на этот процесс. Характеристики компонентов имеют равномерное распределение в рамках определённых
границ. Для каждой серии экспериментов было взято одинаковое количество
компонентов каждого типа. Например, для S20 взято по пять компонентов каждого вида xjm (j=1,…,4; m=1,…,5), для S32 взято по восемь компонентов каждого
вида xjm (j=1,…,4; m=1,…,8) и т.д.
Экспериментальный аппаратный комплекс для ПС «Composite-S v.1.0»
соответствовал рекомендуемым требованиям, перечисленным в п. 4.4.1 и имел
шесть сервисов расчёта. Для остальных ПС использовалась ЭВМ с техническими характеристиками, соответствующими машине-серверу для компоненты
«Сервис ТБЗ», описанными в п. 4.4.1.
4.5.2 Результаты экспериментов
В каждой серии Sn проведено по несколько экспериментов для каждого
ПС. Среднее время работы алгоритма каждого ПС для одной серии экспериментов найдено по формуле:
142
1 k
Tn = ∑ ti ,
k i =1
(4.2)
где n – размерность входных данных для данной серии экспериментов, k – колво экспериментов в серии (таблица 4.2), ti (i=1,…,k) – время работы алгоритма
на i-ом эксперименте.
Таблица 4.2 – Количество экспериментов в каждой серии
Размерность входных данных, n
Кол-во экспериментов, k
20
32
40
52
60
72
30
30
20
20
15
10
Количество экспериментов k в серии уменьшается с ростом n. Это обстоятельство связано с увеличением времени расчета. Некоторые эксперименты
длились более двух суток, поэтому их количество в последних сериях решено
было сократить.
Результаты, полученные в ходе экспериментов, приводятся на диаграммах (рисунок 4.10 - рисунок 4.12), где на оси «X» располагаются сравниваемые
ПС, а ось «Y» содержит значения среднего времени работы их алгоритмов Tn
(4.2) в секундах.
Рисунок 4.10 – Среднее время работы ПС для S20 и S32
143
Рисунок 4.11 – Среднее время работы ПС для S40 и S52
Рисунок 4.12 – Среднее время работы ПС для S60 и S92
Нужно отметить, что не все ПС справляются с поставленной задачей при
относительно больших n (рисунок 4.12). В случае, когда ПС завершало свою
работу с ошибкой, это ПС исключалось из сравнения в конкретной серии экспериментов. Экспериментальные данные сведены в общую таблицу (таблица
4.3) для представления в более наглядном виде.
144
Таблица 4.3 – Среднее время работы ПС
Среднее время работы в зависимости от
размерности входных данных n, секунд
Малая
Средняя
Большая
20
32
40
52
60
72
Программа
«Рецептура асфальто-бетонной
смеси 1.0»
«АСР «ОРПС»
«КОРАЛЛ – Кормление птицы»
«SMART! Fertilizer Management
Software»
«Composite-S v.1.0»
0,59
25,02
326,42
14403,24
-
-
0,20
4,37
40,64
981,01
11293,47
-
0,19
3,03
35,64
673,35
7396,59
-
3,12
6,87
36,17
791,74
8952,46
197580,34
4,02
8,25
31,98
602,32
6023,21
110890,00
ПС «Composite-S v.1.0» при малой размерности входных данных не имеет
преимуществ по среднему времени расчёта перед конкурирующими ПС. Это
обусловлено задержкой при передаче данных по сети между ИС ГС. Этот же
эффект можно наблюдать при расчёте смеси в системе «SMART! Fertilizer
Management Software», имеющую клиент-серверную архитектуру. Однако, с
ростом размерности задачи, задержки при передаче данных по сети становятся
пренебрежимо малыми. Среднее время расчёта возрастает быстро. В этих условиях большую роль играет темп роста времени работы ПС. Незначительное для
пользователя отставание на несколько секунд ПС «Composite-S v.1.0» в сериях
S20 и S32 окупается за счёт более пологой линии зависимости среднего времени
расчёта от размерности входных данных.
Для оценки темпов роста среднего времени расчёта сравниваемых ПС,
найдём величины, выражающие, во сколько раз увеличивалось значение Tn
(4.2) в каждой серии экспериментов по сравнению с предыдущей:
Pni → ni +1 =
Tni +1
Tni
,
(4.3)
где i=1,…,6 – порядковый номер серии экспериментов, ni – размерность входных данных для i-ой серии экспериментов, Tni – среднее время работы алгоритма (4.2).
145
Таблица 4.4 – Темпы роста среднего времени работы ПС
Увеличение Tn ,
P20→ 32
P32→ 40
P40→ 52
раз
Программа
«Рецептура асфальтобетонной смеси 1.0»
«АСР «ОРПС»
«КОРАЛЛ – Кормление
птицы»
«SMART! Fertilizer
Management Software»
«Composite-S v.1.0»
P52→ 60
P60→ 72
42,51
13,05
44,12
-
-
21,66
9,31
24,14
11,51
-
16,23
11,76
18,89
10,98
-
2,20
5,26
21,89
11,31
22,07
2,05
3,88
18,83
10,00
18,41
Оценивая темпы роста среднего времени расчёта P (таблица 4.4), можно
говорить, что в контексте условий эксперимента, чем меньше значение P, тем
более эффективно ПС с точки зрения временной сложности алгоритма. Таким
образом, можно рассчитать, насколько процентов разработанная система «Composite-S v.1.0» эффективнее конкурентных ПС:
Z q n →n
i
i +1

Pc n →n

= 1 − i i +1

Pq n →n

i
i +1

 ⋅ 100 % ,


(4.4)
где q=1,…,4 – порядковый номер конкурентного ПС, i=1,…,6 – порядковый
номер серии экспериментов, ni – размерность входных данных для i-ой серии
экспериментов, Pc – темп роста среднего времени расчёта ПС «Composite-S
v.1.0», Pq – темп роста среднего времени расчёта q-го конкурентного ПС.
Таблица 4.5 – Сравнительная оценка темпов роста среднего времени работы ПС
Эффективность,
%
Программа
«Рецептура асфальтобетонной смеси 1.0»
«АСР «ОРПС»
«КОРАЛЛ – Кормление
птицы»
«SMART! Fertilizer
Management Software»
Среднее значение
Z 20→ 32
Z 32→ 40
Z 40→ 52
Z 52→ 60
Z 60→ 72
95,17
70,29
57,32
-
-
90,52
58,36
21,97
13,13
-
87,36
67,03
0,30
8,96
-
6,80
26,37
13,96
11,56
16,58
69,96
55,51
23,39
11,22
16,58
146
Большие значения для Z 20→ 32 и Z 32→ 40 (таблица 4.5) объясняются сильным влиянием задержек при передаче данных по сети на величину Tn (4.2) ПС
«Composite-S v.1.0». Эти значения не могут рассматриваться как преимущество
разработанной системы, так как фактически среднее время T20 ПС «CompositeS v.1.0» в первой серии экспериментов значительно больше, чем у конкурентных ПС. В сериях S40 , S52 , S60 и S72 задержки при передаче данных по сети
становятся пренебрежимо малыми по сравнению с общим временем расчёта.
Таким образом, значения Z 40→ 52 , Z 52→ 60 и Z 60→ 72 дают наиболее объективное
представление об эффективности разработанной системы относительно конкурентных ПС. Подводя итог, можно говорить о том, что ПС «Composite-S v.1.0»
в среднем на 11 – 23 % эффективнее рассмотренных конкурентов с точки зрения временной сложности алгоритма.
4.5.3 Сравнение функциональных возможностей и характеристик исследуемых ПС
Функциональные возможности ПС наравне с показателями эффективности алгоритма являются для пользователя важным фактором. От технических
характеристик ПС во многом зависит, будет ли оно использоваться в принципе.
Результаты анализа функциональных возможностей и характеристик конкурентных ПС представлены в сравнительной таблице ниже (таблица 4.6).
Таблица 4.6 – Сравнение характеристик ПС (начало)
Характеристики,
Программы
«Рецептура асфальто-бетонной
смеси 1.0»
«АСР «ОРПС»
«КОРАЛЛ –
Кормление птицы»
«SMART! Fertilizer
Management Software»
«Composite-S v.1.0»
Многокритериальная
оптимизация
нет
да, с переводом
критериев в ограничения
да, векторная оптимизация
нет
да
Ввод исходных данных
ручной
ручной, импорт из
сторонних ПС
ручной, импорт из
внешних файлов
ручной, импорт из
внешних файлов
многопользовательский
ручной, автоматизированный сбор информации
Хранение статистики
нет
нет
нет
да
да
да, в MS Excel
да, в MS Office,
да, в MS Office,
да, в MS Office, PDF,
хранение на сервере
нет, хранение на сервере
нет
нет
нет
да
да
Автоматическое обновление
нет
нет
нет
да
да
Совместимость
только настольная
версия MS Windows
только настольная
версия MS Windows
только настольная
версия MS Windows
любая ОС, любое устройство
любая ОС, любое устройство
Самокоррекция, обучаемость
нет
нет
нет
нет
да
Экспорт результатов
Требуется соединение с Internet
147
функционал
Таблица 4.6 – Сравнение характеристик ПС (продолжение)
Программы
Характеристики,
функционал
«Рецептура асфальто-бетонной
смеси 1.0»
«АСР «ОРПС»
«КОРАЛЛ –
Кормление птицы»
«SMART! Fertilizer
Management
Software»
«Composite-S
v.1.0»
Предоставление
сведений о стандартах качества
нет
нет
да
да
да
подробное описание технологического процесса для
получения продукта
компоненты и их
пропорция
компоненты и их
пропорция
компоненты и
их пропорция
Тип архитектуры
настольное приложение
настольное приложение
настольное приложение
клиент-серверная
архитектура
SOA с элементами
облачных технологий
Требования к квалификации
пользователя
высокие
пониженные
пониженные
пониженные
пониженные
Требования к оборудованию пользователя
высокие
высокие
высокие
низкие (тонкий
клиент)
низкие (тонкий
клиент)
148
Представление результата
компоненты, их
пропорция, рекомендации по использованию
149
Основные результаты
1.
С учётом результатов второй и третьей глав диссертации, сформу-
лирована цель и определены задачи проектирования типовой автоматизированной системы поиска оптимизированных композитных смесей «Composite-S
v.1.0».
2.
Онтология «TechProcess», разработанная в третьей главе диссерта-
ции, дополнена новыми понятиями предметной области производства картона
для решения конкретных задач.
3.
Спроектирована БД ПС «Composite-S v.1.0», позволяющая хранить
и оперативно извлекать информацию о продукции, технологических процессах,
сервисах и пользователях системы. В БД представлены основные сущности, необходимые для решения задачи поиска рецептуры оптимизированных композитных смесей.
4.
Разработана оригинальная объектно-ориентированная реализация
классов автоматизированной системы «Composite-S v.1.0», основанная на архитектурном шаблоне MVC, чётко структурирующая программный код для облегчения поддержки программного продукта.
5.
Проведено экспериментальное сравнение автоматизированной сис-
темы «Composite-S v.1.0» с конкурентными ПС. Показана работоспособность и
эффективность внедрения разработанной автоматизированной системы «Composite-S v.1.0». ПС «Composite-S v.1.0» в среднем на 11 – 23 % эффективнее
рассмотренных конкурентов с точки зрения временной сложности алгоритма.
6.
Произведён анализ и сравнение функциональных характеристик
конкурентных ПС с разработанной автоматизированной системой «Composite-S
v.1.0». По результатам анализа составлена сводная таблица, показывающая, что
разработанная система «Composite-S v.1.0» обладает богатым, современным и
инновационным функционалом.
150
ЗАКЛЮЧЕНИЕ
Основные результаты диссертации заключаются в следующем.
1. Сделан обзор прикладных математических моделей и основных методов решения задач оптимизации смесей, используемых в существующих программных системах. Проведён сравнительный анализ математических методов,
выявлены недостатки существующих подходов к проблеме. Основными проблемами являются: сильное влияние размерности задачи на время расчёта, многокритериальность реальных задач, малое внимание к особенностям технологических процессов.
2. Проведено исследование текущих тенденций в сфере ИТ, современных
направлений в проектировании ПО и ИС ГС. Приведён обзор основных технологий, используемых системами на основе SOA. Обоснованы преимущества
SOA для решения задач поиска оптимальной рецептуры многокомпонентных
смесей.
3. Разработана математическая формализация технологии изготовления
композитных смесей, позволяющая математически строго анализировать компонентные вещества, их свойства, технологические ситуации и процессы. Предложена универсальная алгебра технологических цепочек производства, определены свойства её операций. Формализация также обладает конструктивными
оптимизирующими свойствами и позволяет делать выводы на основе знаний о
конкретной предметной области.
4. Проведено исследование архитектурных, технических и функциональных решений, применяемых в существующих программных системах поиска
оптимальных смесей. Основными недостатками прикладного ПО являются: высокие требованию к оборудованию пользователя и его квалификации; отсутствие механизмов автокоррекции, обучаемости; необходимость самостоятельной
подготовки входных данных пользователем и др.
5. Спроектирована структура ТБЗ для хранения и возможности интеллектуального вывода информации о компонентах смеси, технологических ситуа-
151
циях и процессах её изготовления. Использование ТБЗ позволяет автоматизировать процесс поиска рецептуры композитных смесей. Структура ТБЗ универсальна и может быть использована для широкого круга ПС, работающих с понятиями смежных предметных областей.
6. Разработаны алгоритмы структурной композиции ИС в контексте SOA
для решения задач оптимизации смесей, пополнения, обучения и адаптации
ТБЗ, дающие возможность повысить эффективность технологии поиска рецептуры композитных смесей. В предложенных алгоритмах реализованы концепции облачных технологий, такие как распределённые вычисления и масштабируемость. Эти свойства позволяют сократить время поиска оптимизированной
рецептуры смеси и находить баланс между производительностью и стоимостью
системы. Алгоритм адаптации ТБЗ реализует концепцию Data Mining, известную как Memory Based Reasoning или «вывод путем сопоставления». Согласно
этой концепции, алгоритм находит зависимости характеристик конечного продукта от характеристик составляющих его компонентов и технологии производства, выполняет соответствующую коррекцию данных в ТБЗ.
7. Разработана архитектура ИАС ПОС, описывающая общие подходы к
проектированию прикладных программных средств поиска рецептуры оптимизированных композитных смесей. Выдвинуты и обоснованы оригинальные проектные решения, выделены основные конкурентные преимущества системы,
обеспечиваемые этими проектными решениями.
8. Разработана программная реализация SOA-системы поиска рецептуры
смесей «Composite-S v.1.0», использующая описанные выше алгоритмы структурной композиции ИС. При разработке применён архитектурный шаблон объектно-ориентированного программирования MVC, позволяющий чётко структурировать программный код для облегчения поддержки программного продукта. Разработана оригинальная структура информационной БД ПС «Composite-S v.1.0».
9. Проведено экспериментальное сравнение разработанной системы с
конкурентным ПО. Проведен сравнительный анализ функциональных и техни-
152
ческих возможностей программных систем. Определено, что ПС «Composite-S
v.1.0» в среднем на 11-23 % эффективнее конкурентных систем исходя из оценок зависимости временной сложности алгоритма от размерности входных
данных.
Задачи исследования выполнены полностью, поставленная цель диссертационной работы – достигнута. При планировании будущих исследований
можно выделить следующие возможные направления.
1. Исследование возможностей расширения и модернизации разработанного математического формализма технологии изготовления композитных смесей. В частности, можно рассмотреть возможность пополнения списка конструктивных оптимизирующих свойств алгебраической системы.
2. Расширение структуры ТБЗ, внесение новых понятий и связей. Чем более подробно описана предметная область в ТБЗ, тем появляется больше возможностей для автоматического построения ограничений и отсеивания бесперспективных ветвей решения задачи поиска оптимизированной рецептуры смеси. Это в свою очередь способствует значительному увеличению скорости расчётов.
3. Разработка и добавление в ПС новых алгоритмов интеллектуального
анализа данных ТБЗ, реализующих другие концепции Data Mining, помимо уже
использующейся «Memory-based Reasoning». Наличие ТБЗ открывает большие
возможности для интеллектуального анализа данных и выявления неочевидных
зависимостей в процессах приготовления смесей. Применение подобных алгоритмов может способствовать увеличению точности расчёта прогнозных характеристик продукции и нахождению лучших технологических процессов производства.
4. Использование для написания высоконагруженных сервисов расчёта и
ТБЗ компилируемых языков, например C++. Это техническое решение позволит сократить время расчётов, в целом повысив производительность системы.
SOA позволит внедрить новые сервисы в систему, заменив старые абсолютно
незаметно и безболезненно для пользователей.
153
СПИСОК СОКРАЩЕНИЙ И УСЛОВНЫХ ОБОЗНАЧЕНИЙ
БГ
– бумага для гофрирования;
БД
– база данных;
БЗ
– база знаний;
БФ
– база фактов;
ГК
– гофрированный картон;
ГС
– глобальная сеть;
ИАС ПОС – интеллектуальная автоматическая система поиска оптимизированных смесей;
ИЗ
– инженер по знаниям;
ИС
– информационные сервисы;
ИТ
– информационные технологии;
КПС
– картон для плоских слоёв;
ЛП
– линейное программирование;
ЛПР
– лицо, принимающее решение;
ЛЦП
– линейное целочисленное программирование;
ЛЦПБ
– линейное целочисленное программирование с булевыми пе-
ременными;
ОС
– операционная система;
ПО
– программное обеспечение;
ПС
– программное средство;
ТБЗ
– технологическая база знаний;
ЦФ
– целевая функция;
ЯП
– язык программирования;
JSON
– JavaScript Object Notation;
SOA
– сервис-ориентированная архитектура;
SOAP
– простой протокол доступа к данным;
WSDL
– язык описания веб-сервисов.
154
СПИСОК ЛИТЕРАТУРЫ
1.
Корбут А.А., Финкельштейн Ю.Ю. Дискретное программирование.
– М.: Наука, 1969. – 368 с.
2.
Пантелеев А.В., Летова Т.А. Методы оптимизации в примерах и за-
дачах. – 2-е изд. – М: Высшая школа, 2005. – 544 с.
3.
Акулич И.Л. Математическое программирование в примерах и за-
дачах. – 3-е изд. – СПб.: Лань, 2011. – 319 с.
4.
Карманов В.Г. Математическое программирование. – М.: ФИЗ-
МАТЛИТ, 2004. – 264 с.
5.
Леонов А.А.
Методы решения линейных экстремальных задач.
Учебное пособие. – М.: МИФИ, 1984. – 57 с.
6.
Жолобов Д.А. Введение в математическое программирование:
Учебное пособие. – М.: МИФИ, 2008. – 376 с.
7.
Плотников А.Д. Математическое программирование: экспресс-курс.
– 2-е изд. – Минск: Новое знание, 2007. – 171 с.
8.
Салмин И.Д. Математические методы решения оптимизационных
задач. – М.: МИФИ, 2004. – 156 с.
9.
Селиванов Е.В. Общая постановка задачи оптимальной композиции
материалов как разновидности задачи о смесях // Современные проблемы науки
и образования. – 2014. – № 6; URL: www.science-education.ru/120-15599 (дата
обращения: 28.11.2014).
10.
Ефремов Н.Ф. Проектирование упаковочных производств. Часть 1:
Упаковки из гофрокартона: Учеб. пособие / Н.Ф. Ефремов, А.И. Васильев, Г.К.
Хмелевский. – М.: МГУП, 2004. – 394 с.
11.
Кононов Б.В., Ландау Г.Е., Погребов Е.М. Гофрированный картон.
Производство и переработка. – М.: «Лесная промышленность», 1971. – 191 с.
12.
Стенли Р. Перечислительная комбинаторика / Пер. с англ. – М.:
Мир, 1990. – 440 с.
155
13.
Корн Г., Корн Т. Справочник по математике для научных работни-
ков и инженеров. – М.: Наука, 1973. – 832 с.
14.
Виленкин Н.Я. Популярная комбинаторика. – М.: Наука, 1975. – 208
15.
Ухов Р. Г. Software for the computer control system of asphalt mixing.
с.
URL: http://rukhov.newmail.ru/ds168.html (дата обращения: 03.02.2009)
16.
Максимов Ю.Я. Алгоритмы линейного и дискретного програм-
мирования.– М.:МИФИ, 1982. – 72 с.
17.
Шевченко В.Н., Золотых Н.Ю. Линейное и целочисленное линейное
программирование. – Нижний Новгород: Изд-во Нижегородского госуниверситета им. Н.И. Лобачевского, 2004. – 154 c.
18.
Мину М. Математическое программирование. Теория и алгоритмы /
Пер. с фр. – М.: Наука, 1990. – 488 с.
19.
Таха Х. Введение в исследование операций / Пер. с англ. – 8 изд. –
М.: Вильямс, 2007. – 912 с.
20.
Селиванов Е.В. Основные функции программного обеспечения для
эффективного решения задачи поиска оптимальных смесей // Тенденции развития современных информационных технологий, моделей экономических, правовых и управленческих систем: сб. статей IX международной науч.-практич.
конф. / Под ред. С.В. Авилкиной – Рязань: Рязанский филиал МЭСИ, 2014. –
280 с.
21.
та
Мерцалов А.Н., Новицкий В.О. Автоматизированная система расче-
оптимальных
рецептов
помольных
смесей.
URL:
http://www.aiskhp.ru/articles/08_02_HP.htm (дата обращения: 30.10.2014).
22.
Мерцалов А.Н. Автоматизация процессов планирования зерновых
ресурсов мукомольного производства: автореф. дисс. канд. техн. наук: 05.13.06.
– М., 2009. – 25 с.
23.
Лукьянов Б.В., Лукьянов П.Б. Новый модуль программ «КОРАЛЛ»
для оптимизации кормления // Ценовик. – 2006. – № 9. – с. 14.
156
24.
Лукьянов П.Б. Система поддержки принятия решений для оптими-
зации оперативного управления экономикой производства животноводческой
продукции: автореф. дисс. док. экон. наук: 08.00.13. – М., 2011. – 44 с.
25.
Соболь И.М. Выбор оптимальных параметров в задачах со многими
критериями. – М.: Дрофа, 2006. – 175 с.
26.
Steuer R.E. Multiple Criteria Optimization: Theory, Computations, and
Application. – New York: John Wiley, 1986. – 546 p.
27.
Лукьянов Б.В., Лукьянов П.Б. Векторная оптимизация рационов в
программах «КОРАЛЛ» // Эффективное животноводство. – 2012. – № 8. – с. 12.
28.
Аттетков А.В., Галкин С.В., Зарубин В.С. Метод Хука - Дживса //
Методы оптимизации. — М.: Изд-во МГТУ им. Н.Э. Баумана, 2003. – 440 с.
29.
Методы
оптимизации.
Метод
поиска
Хука-Дживса.
URL:
http://www.theweman.info/topics/t4r5part2.html (дата обращения: 26.08.2014).
30.
Оптимизация
методом
Монте-Карло.
URL:
http://www.korall-
agro.ru/karlo.htm. (дата обращения: 21.05.2014).
31.
Fishman G.S. Monte Carlo: concepts, algorithms, and applications. –
New York: Springer, 2008. – 698 p.
32.
Microsoft support center. Постановка задачи и решение проблемы с
помощью надстройки "Поиск решения". URL: http://office.microsoft.com/ruru/excel-help/HP010342416.aspx (дата обращения: 11.04.2014).
33.
Токарев В.В. Методы оптимальных решений. Том 2. Многокрите-
риальность. Динамика. Неопределенность. – М.: ФИЗМАТЛИТ, 2012. – 420 с.
34.
Данилин В.И. Операционное и финансовое планирование в корпо-
рации. Методы и модели. – М.: Наука, 2006. – 334 с.
35.
Селиванов Е.В., Каширин И.Ю. Облачные технологии как новая
ступень эволюции информационных сервисов глобальных сетей // Вестник Рязанского государственного радиотехнического университета. – 2014. – № 1. – С.
97-103.
36.
Селиванов Е.В. Перспективы повышения экономической эффек-
тивности предприятий при использовании сети информационных сервисов //
157
Современные проблемы экономики и управления в организации: Сборник тезисов докладов Всероссийской заочной научно-практической конференции / Под
ред. М.В. Пронина, Ю.В. Рокотянской, Ю.М. Солдака, Е.Н. Евдокимовой, Н.В.
Казаковой, А.В. Янкевского – Рязань: РГРТУ, 2014. – 316 с.
37.
Papazoglou M.P. Web Services and SOA: Principles and Technology.
Pearson Education Limited, 2012. – 856 p.
38.
Селиванов Е.В., Каширин И.Ю. Тенденции развития сервис-
ориентированных информационных систем // Современные тенденции в образовании и науке: сб. науч. тр. по материалам Международной научнопрактической конференции 28 декабря 2012 г. – Тамбов: Изд-во ТРОО «БизнесНаука-Общество», 2013. – 163 с.
39.
Биберштейн Н., Боуз С., Фиаммант М., Джонс К., Ша Р. Компас в
мире сервис-ориентированной архитектуры (SOA). – Изд-во КУДИЦ-Пресс,
2007. – 256 с.
40.
Ньюкомер Э. Веб-сервисы: XML, WSDL, SOAP и UDDI – СПб.:
Питер, 2003. – 256 с.
41.
Бин Дж. XML для проектировщиков. Повторное использование и
интеграция. – Изд-во КУДИЦ-Образ, 2004. – 256 с.
42.
Эммерих В. Конструирование распределённых объектов. Методы и
средства программирования интероперабельных объектов в архитектурах
OMG/CORBA, Microsoft/COM и Java/RMI. – М.: Мир, 2002. – 512 с.
43.
Бекет Г. Java SOAP. – М.: Лори, 2012. – 456 с.
44.
Петин В. А. API Яндекс, Google и других популярных веб-сервисов.
Готовые решения для вашего сайта. – СПб.: БХВ-Петербург, 2012. – 480 с.
45.
Селиванов Е.В. Технологии обмена данными информационных сер-
висов глобальных сетей // Математическое и программное обеспечение вычислительных систем: межвуз. сб. науч. тр. / под ред. А.Н. Пылькина. – Рязань:
РГРТУ, 2012. – 240 с.
46.
Селиванов Е.В. Реестры информационных сервисов глобальной се-
ти Интернет // Новые информационные технологии в научных исследованиях:
158
материалы XVII Всероссийской научно-технической конференции студентов,
молодых ученых и специалистов. – Рязань: РГРТУ, 2012. – 276 с.
47.
ной
Юч Огбуджи. Рекомендация: Cжимайте файлы XML для эффектив-
передачи.
URL:
http://www.ibm.com/developerworks/ru/library/x-
tipcomp/index.html. (дата обращения: 15.09.2014).
48.
Brown P.C. Succeeding with SOA: Realizing Business Value Through
Total Architecture. Massachusetts: Addison-Wesley, 2007. – 244 p.
49.
Hiorns A.G. Mineral pigments if coatings paper and Boarif USA. – Pulp
and Paper, 2001. – 59 p. – pp. 56-57.
50.
Куратовский К., Мостовский А. Теория множеств. – М.: Мир, 1970.
– 416 с.
51.
Milind G., Polychronopoulos C.D. The hierarchical task graph as a uni-
versal intermediate representation. – Int. J. Parall. Programm., v.22, 1994. – N5. –
pp. 519-551.
52.
Каширин И.Ю., Маликова Л.В., Маркова В.В. Основы формальных
систем // Учебное пособие / под ред. Каширина И.Ю. М.: Минобразования России, НИЦПрИС, 1999. – 84 с.
53.
Селиванов Е.В. Обобщённое представление технологических про-
цессов в программном обеспечении // Новые информационные технологии в
научных исследованиях и в образовании: материалы XIX Всероссийской научно-технической конференции студентов, молодых ученых и специалистов. –
Рязань: РГРТУ, 2014. – 268 с.
54.
ГОСТ Р 53207-2008 Картон для плоских слоёв гофрированного кар-
тона. Технические условия.
55.
Лавров И.А. Математическая логика // Учеб. пособие для студ.
высш. учеб. заведений / под ред. Л. Л. Максимовой. – М.: Издательский центр
Академия, 2006. – 240 с.
56.
Ахо А., Ульман Дж. Теория синтаксического анализа, перевода и
компиляции. Том 2. Компиляция. – М.: Мир, 1978. – 487 с.
159
57.
Каширин И.Ю., Крошилин А. В., Крошилина. С. В. Автоматизиро-
ванный анализ деятельности предприятия с использованием семантических сетей. – М., Горячая линия – Телеком, 2013. – 139 с.
58.
Селиванов Е.В. Универсальная прикладная алгебра технологиче-
ских цепочек приготовления смесей // Современные проблемы науки и образования. – 2015. – № 1; URL: www.science-education.ru/121-17714 (дата обращения: 10.03.2015).
59.
Knight K. Unification: A Multidisciplinary Survey. – ACM Computing
Surveys, 1989. – V.21. – N 1. – pp. 93-124.
60.
Дейт К.Дж. Введение в системы баз данных. – М.: Вильямс, 2001. –
1096 с.
61.
Каширин Д.И., Каширин И.Ю. Модели представления знаний в сис-
темах искусственного интеллекта // Вестник Рязанского государственного радиотехнического университета. – 2010. – № 1. – С. 36-43.
62.
Братко И. Алгоритмы искусственного интеллекта на языке Prolog –
М.: Вильямс, 2004. – 640 с.
63.
Четыркин Е.М. Финансовая математика. – М.: «Дело», 2005. – 400 с.
64.
Салий В.Н. Универсальная алгебра и автоматы // Учебное пособие /
под ред. Салия В.Н. Саратовский государственный университет, 1988. – 73 стр.
65.
Каширин И.Ю., Коричнев Л.П. Формальное исследование интел-
лектуальных программных систем. – М.: Радио и связь, 1997. – 160 с.
66.
Kashirin I.Yu., Korichnev L.P. The Use of Program Semantic for Unifi-
able Object Representation in Object-Oriented Design. – Intern. Conf. of Math. &
Inf. Probl., GGU, Homel, 1994. – pp. 12-14.
67.
Частиков А.П., Гаврилова Т.А., Белов Д.Л. Разработка экспертных
систем. Среда CLIPS. – СПб.: БХВ-Петербург, 2003. – 608 с.
68.
Brownston L., at al. Programming Expert Systems in OPS5: An Intro-
duction to Rule-Based Programming. – Addison-Wesley Publ. Co, Inc., 1985. – 457
p.
160
69.
Каширин И.Ю., Минашкин С.А. Онтологии для представления зна-
ний в Интерактивных сервисах информационных сетей // Вестник РГРТУ № 1
Рязань, 2012. – С.72-76.
70.
Каширин И.Ю., Курдюков Н.С. Доказательство эффективности SIR
алгоритма авто-построения интерфейсов взаимодействия web-сервисов // Фундаментальные исследования. – № 6. – ч. 2. Научный журнал. Издательский дом
«Академия Естествознания», 2013. – С. 267-273.
71.
Никифоров В.О., Ушаков A.B. Управление в условиях неопреде-
ленности: чувствительность, адаптация, робастность. – СПб.: ПбГИТМО (ТУ),
2002. – 232с.
72.
Ахо А., Хопкрофт Дж., Ульман Дж. Структуры данных и алгорит-
мы. – М.: Вильямс, 2000. – 384 с.
73.
Backus J. Can programming be liberated from von Neu-man style? A
functional style and its algebra of programs. – Communication of the ACM, v.21,
1978. – N8. – pp. 613-641.
74.
Гаврилова Т.А., Хорошевский В.Ф. Базы знаний интеллектуальных
систем – СПб.: Питер, 2000. – 384 с.
75.
Зерновые культуры и элеваторы. Учёт работы элеватора. URL:
http://grainelevators.ru/uchet_raboti.php (дата обращения: 30.10.2014).
76.
SMART!
Fertilizer
Management.
URL:
http://www.smart-
fertilizer.com/About-Us (дата обращения: 30.10.2014).
77.
SMART!
Fertilizer
Features.
URL:
http://www.smart-
URL:
http://www.smart-
fertilizer.com/features (дата обращения: 11.09.2014).
78.
SMART!
Fertilizer
Calculator.
fertilizer.com/articles/fertilizer-calculator (дата обращения: 11.09.2014).
79.
SMART! Fertilizer Software Screenshots. URL: http://www.smart-
fertilizer.com/screenshots-web (дата обращения: 11.09.2014).
80.
Селиванов Е.В. Особенности проектирования приложений основан-
ных на информационных сервисах глобальных сетей // Межвуз. сб. статей. –
Липецк: ФГБОУ ВПО «ЛГПУ», 2012. – 189 с.
161
81.
Буч Г., Рамбо Д., Якобсон А. Язык UML. Руководство пользователя.
– 2-е изд. – М., СПб.: ДМК Пресс, Питер, 2004. – 432 с.
82.
Буч Г., Якобсон А., Рамбо Дж. UML. Классика CS. – 2-е изд. – СПб.:
Питер, 2006. – 736 с.
83.
Ларман К. Применение UML 2.0 и шаблонов проектирования. – 3-е
изд. – М.: Вильямс, 2006. – 736 с.
84.
Путилин А.Б., Юрагов Е.А. Компонентное моделирование и про-
граммирование на языке UML. Практическое руководство по проектированию
информационно-измерительных систем. – М.: НТ Пресс, 2005. – 664 с.
85.
Гома Х. UML. Проектирование систем реального времени, распре-
деленных и параллельных приложений. – М.: ДМК Пресс, 2014. – 700 с.
86.
OWL Web Ontology Language Semantics and Abstract Syntax. URL:
http://www.w3.org/TR/2004/REC-owl-semantics-20040210/
(дата
обращения:
05.02.2015).
87.
Resource
Description
Framework
(RDF).
URL:
(KIF).
URL:
http://www.w3.org/RDF/ (дата обращения: 05.02.2015).
88.
Knowledge
Interchange
Format
http://www.ksl.stanford.edu/knowledge-sharing/kif/ (дата обращения: 05.02.2015).
89.
Чубукова И.А. Data Mining. – М.: Бином, 2008. – 384 с.
90.
Уайт Т. Hadoop: Подробное руководство. – СПб.: Питер, 2013. – 672
91.
Chakrabarti S. and et al. Data Mining: Know it All. – Waltham: Morgan
с.
Kaufmann Publishers, 2010. – 480 p.
92.
Селиванов Е.В. Сервис-ориентированная архитектура в облачных
технологиях // Современные тенденции в образовании и науке: сб. науч. тр. по
материалам Международной научно-практической конференции 31 октября
2013 г. – Тамбов: Изд-во ТРОО «Бизнес-Наука-Общество», 2013. – 163 с.
93.
Селиванов Е.В. Решение основных проблем задачи поиска опти-
мальных смесей с помощью сервис-ориентированной архитектуры // Матема-
162
тическое и программное обеспечение вычислительных систем: межвуз. сб. науч. тр. / под ред. А.Н. Пылькина. – Рязань: РГРТУ, 2014. – 100 с.
94.
Селиванов Е.В., Селиванова Н.И. Возможности применения совре-
менных информационных технологий в задачах оптимизации производственной программы // Математическое и программное обеспечение вычислительных систем: межвуз. сб. науч. тр. / под ред. А.Н. Пылькина. – Рязань: РГРТУ,
2013. – 152 с.
95.
Amazon
Elastic
Compute
Cloud
(EC2)
URL:
http://aws.amazon.com/ru/ec2/ (дата обращения: 23.01.2015).
96.
Google Compute Engine. URL: https://cloud.google.com/compute/ (дата
обращения: 23.01.2015).
97.
IBM
Cloud
Computing.
URL:
http://www.ibm.com/cloud-
computing/ru/ru/ (дата обращения: 23.01.2015).
98.
Microsoft
Azure.
Платформа
облачных
вычислений.
URL:
http://azure.microsoft.com/ru-ru/ (дата обращения: 23.01.2015).
99.
Агальцов В.П. Базы данных. Распределенные и удаленные базы
данных. Книга 2. - М.: Форум: НИЦ ИНФРА-М, 2009. – 272 с.
100. Бэнкер К. MongoDB в действии. – М.: ДМК Пресс, 2014. – 394 с.
101. Гопалакришнан К. Oracle Database 10g. Настольная книга по кластерным технологиям. – М.: Лори, 2012. – 520 с.
102. Зенкин
Д.
Коммерсантъ.
Приложение
в
аренду.
URL:
http://www.kommersant.ru/doc/1138954 (дата обращения: 31.10.2014).
103. ГОСТ Р 50418-92 Силикат натрия растворимый. Технические условия.
104. ГОСТ Р 52901-2007 Картон гофрированный для упаковки продукции. Технические условия.
105. ГОСТ Р 53206-2008 Бумага для гофрирования. Технические условия.
106. ГОСТ Р 53876-2010 Крахмал картофельный. Технические условия.
163
107. Малыхина М.П. Базы данных. Основы, проектирование, использование. – СПб.: БХВ-Петербург, 2006. – 528 с.
108. Пирогов В.Ю. Информационные системы и базы данных. Организация и проектирование. – СПб.: БХВ-Петербург, 2009. – 528 с.
109. Селиванов Е.В. Поддержка работы с информационными сервисами
в языках программирования // Математическое и программное обеспечение вычислительных систем: межвуз. сб. науч. тр. / под ред. А.Н. Пылькина. – Рязань:
РГРТУ, 2013. – 152 с.
110. Макаров А.С. Сравнение популярных PHP-фреймворков. URL:
http://rmcreative.ru/playground/php-frameworks/ (дата обращения: 18.02.2015).
111. Skvorc
B.
Best
PHP
Frameworks
http://www.sitepoint.com/best-php-frameworks-2014/
for
(дата
2014.
URL:
обращения:
18.02.2015).
112. Макаров А.С. Yii. Сборник рецептов. – М.: ДМК Пресс, 2013. – 372
с.
113. Васвани В. MySQL. Использование и администрирование. – СПб.:
Питер, 2011. – 368 с.
114. MySQL
Community
Edition.
URL:
http://www.mysql.com/products/community/ (дата обращения: 25.02.2015).
115. Маклафлин Б. PHP и MySQL. Исчерпывающее руководство. – СПб.:
Питер, 2014. – 544 с.
116. The Definitive Guide to Yii. Объекты доступа к данным. URL:
http://www.yiiframework.com/doc/guide/1.1/ru/database.dao
(дата
обращения:
25.02.2015).
117. Дакетт Дж. HTML и CSS. Разработка и дизайн веб-сайтов – М.:
Эксмо, 2013. – 480 с.
118. Шафер С. HTML, XHTML и CSS. Библия пользователя – М.: Вильямс, 2011. – 656 с.
164
119. Гамма Э., Хелм Р., Джонсон Р., Влиссидес Дж. Приемы объектноориентированного проектирования. Паттерны проектирования. – СПб.: Питер,
2015. – 368 с.
120. Селиванов Е.В. Эффективное проектирование программного обеспечения вычислительных систем // Математическое и программное обеспечение вычислительных систем: межвуз. сб. науч. тр. / под ред. А.Н. Пылькина. –
Рязань: РГРТУ, 2011. – 120 с.
121. Фримен Э., Сиерра К., Бейтс Б. Паттерны проектирования. – СПб.:
Питер, 2015. – 656 с.
122. The
Definitive
Guide
to
Yii.
Active
http://www.yiiframework.com/doc/guide/1.1/ru/database.ar
Record.
(дата
URL:
обращения:
12.03.2015).
123. The Definitive Guide to Yii. Аутентификация и авторизация. Контроль
доступа
на
основе
ролей.
URL:
http://www.yiiframework.com/doc/guide/1.1/ru/topics.auth#sec-7 (дата обращения:
13.03.2015).
124. The
Definitive
Guide
to
Yii.
Веб-сервисы.
URL:
http://www.yiiframework.com/doc/guide/1.1/ru/topics.webservice (дата обращения:
13.03.2015).
125. Learn
about
phpDocumentor.
URL:
http://www.phpdoc.org/docs/latest/index.html (дата обращения: 21.04.2015).
126. Web Service Definition Language (WSDL). Documentation. URL:
http://www.w3.org/TR/wsdl#_documentation (дата обращения: 13.03.2015).
127. Крупский В.Н. Введение в сложность вычислений – М.: Факториал
Пресс, 2006. – 128 с.
128. Громкович Ю. Теоретическая информатика. Введение в теорию автоматов, теорию вычислимости, теорию сложности, теорию алгоритмов, рандомизацию, теорию связи и криптографию – СПб.: БХВ-Петербург, 2010. – 334
с.
165
129. ГОСТ 9128-2009 Cмеси асфальтобетонные дорожные, аэродромные
и асфальтобетон. Технические условия.
130. ГОСТ Р 52189-2003 Мука пшеничная. Общие технические условия.
131. ГОСТ Р 52812-2007 Смеси кормовые. Технические условия.
132. ГОСТ Р 51520-99 Удобрения минеральные. Общие технические условия.
166
ПРИЛОЖЕНИЕ 1. ОСНОВНЫЕ КЛАССЫ И СВОЙСТВА
ОНТОЛОГИИ «TechProcess»
<?xml version="1.0"?>
<!DOCTYPE Ontology [
<!ENTITY xsd "http://www.w3.org/2001/XMLSchema#" >
<!ENTITY xml "http://www.w3.org/XML/1998/namespace" >
<!ENTITY rdfs "http://www.w3.org/2000/01/rdf-schema#" >
<!ENTITY rdf "http://www.w3.org/1999/02/22-rdf-syntax-ns#"
>]>
<Ontology xmlns="http://www.w3.org/2002/07/owl#"
xml:base="http://www.tbz.composite-s.dev/TechProcess.owl"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:xml="http://www.w3.org/XML/1998/namespace"
xmlns:xsd="http://www.w3.org/2001/XMLSchema#"
xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#" ontologyIRI= "http://www.tbz.composite-s.dev/TechProcess.owl"
versionIRI="http://www.tbz.composites.dev/TechProcess.owl#1.0.0">
<Prefix name="" IRI="http://www.w3.org/2002/07/owl#"/>
<Prefix name="owl" IRI="http://www.w3.org/2002/07/owl#"/>
<Prefix name="rdf" IRI="http://www.w3.org/1999/02/22-rdfsyntax-ns#"/>
<Prefix name="xsd"
IRI="http://www.w3.org/2001/XMLSchema#"/>
<Prefix name="rdfs" IRI="http://www.w3.org/2000/01/rdfschema#"/>
<Annotation>
<AnnotationProperty abbreviatedIRI="rdfs:comment"/>
<Literal xml:lang="en"
datatypeIRI="&rdf;PlainLiteral">Common technological process
ontology</Literal>
</Annotation>
<Declaration>
<Class IRI="#Cluster"/>
</Declaration>
<Declaration>
<Class IRI="#Component"/>
</Declaration>
<Declaration>
<Class IRI="#Manufacturer"/>
</Declaration>
<Declaration>
<Class IRI="#TechSituation"/>
</Declaration>
<Declaration>
<Class IRI="#absorbabilityCharacter"/>
</Declaration>
<Declaration>
<Class IRI="#atomComponent"/>
</Declaration>
167
<Declaration>
<Class IRI="#boilingPoint"/>
</Declaration>
<Declaration>
<Class IRI="#breathabilityCharacter"/>
</Declaration>
<Declaration>
<Class IRI="#burstingStrength"/>
</Declaration>
<Declaration>
<Class IRI="#cartonCharacter"/>
</Declaration>
<Declaration>
<Class IRI="#cellulosicSheetCharacter"/>
</Declaration>
<Declaration>
<Class IRI="#componentCharacteristic"/>
</Declaration>
<Declaration>
<Class IRI="#componentCostCharact"/>
</Declaration>
<Declaration>
<Class IRI="#componentNameCaract"/>
</Declaration>
<Declaration>
<Class IRI="#compositeComponent"/>
</Declaration>
<Declaration>
<Class IRI="#crepePaperCharacter"/>
</Declaration>
<Declaration>
<Class IRI="#densityCharacter"/>
</Declaration>
<Declaration>
<Class IRI="#dryingTimeCharacter"/>
</Declaration>
<Declaration>
<Class IRI="#endCompressionResistance"/>
</Declaration>
<Declaration>
<Class IRI="#energyConsumption"/>
</Declaration>
<Declaration>
<Class IRI="#equipNameCaract"/>
</Declaration>
<Declaration>
<Class IRI="#equipment"/>
</Declaration>
<Declaration>
<Class IRI="#equipmentCharact"/>
</Declaration>
<Declaration>
<Class IRI="#fluidityCharacter"/>
168
</Declaration>
<Declaration>
<Class IRI="#glueCharacter"/>
</Declaration>
<Declaration>
<Class IRI="#gluePoint"/>
</Declaration>
<Declaration>
<Class IRI="#humidityCharacter"/>
</Declaration>
<Declaration>
<Class IRI="#maintenanceCost"/>
</Declaration>
<Declaration>
<Class IRI="#maintenanceInterval"/>
</Declaration>
<Declaration>
<Class IRI="#massCharacter"/>
</Declaration>
<Declaration>
<Class IRI="#meltingPoint"/>
</Declaration>
<Declaration>
<Class IRI="#planeCompressionResistance"/>
</Declaration>
<Declaration>
<Class IRI="#procNameCharact"/>
</Declaration>
<Declaration>
<Class IRI="#procProportionCharact"/>
</Declaration>
<Declaration>
<Class IRI="#procTempCharact"/>
</Declaration>
<Declaration>
<Class IRI="#procTimeCharacter"/>
</Declaration>
<Declaration>
<Class IRI="#qualityRange"/>
</Declaration>
<Declaration>
<Class IRI="#region"/>
</Declaration>
<Declaration>
<Class IRI="#ringCompression"/>
</Declaration>
<Declaration>
<Class IRI="#tearResistance"/>
</Declaration>
<Declaration>
<Class IRI="#techProcess"/>
</Declaration>
<Declaration>
169
<Class IRI="#techProcessCharacter"/>
</Declaration>
<Declaration>
<Class IRI="#thicknessCharacter"/>
</Declaration>
<Declaration>
<Class IRI="#toxicityCharacter"/>
</Declaration>
<Declaration>
<Class IRI="#viscosityCharacter"/>
</Declaration>
<Declaration>
<Class IRI="#waterProofCharacter"/>
</Declaration>
<Declaration>
<Class IRI="#wetness"/>
</Declaration>
<Declaration>
<Class IRI="#workhours"/>
</Declaration>
<Declaration>
<ObjectProperty IRI="#antiConsecution"/>
</Declaration>
<Declaration>
<ObjectProperty IRI="#belongsToManufacturer"/>
</Declaration>
<Declaration>
<ObjectProperty IRI="#canBeProcessedBy"/>
</Declaration>
<Declaration>
<ObjectProperty IRI="#canDoProcess"/>
</Declaration>
<Declaration>
<ObjectProperty IRI="#consecution"/>
</Declaration>
<Declaration>
<ObjectProperty IRI="#consistsOf"/>
</Declaration>
<Declaration>
<ObjectProperty IRI="#endsWithSituation"/>
</Declaration>
<Declaration>
<ObjectProperty IRI="#includeComponent"/>
</Declaration>
<Declaration>
<ObjectProperty IRI="#isCommonal"/>
</Declaration>
<Declaration>
<ObjectProperty IRI="#isEqual"/>
</Declaration>
<Declaration>
<ObjectProperty IRI="#isIndependent"/>
</Declaration>
170
<Declaration>
<ObjectProperty IRI="#isNotEqual"/>
</Declaration>
<Declaration>
<ObjectProperty IRI="#locatedIn"/>
</Declaration>
<Declaration>
<ObjectProperty IRI="#necessaryEquipment"/>
</Declaration>
<Declaration>
<ObjectProperty IRI="#produces"/>
</Declaration>
<Declaration>
<ObjectProperty IRI="#startsOnSituation"/>
</Declaration>
<SubClassOf>
<Class IRI="#Component"/>
<Class abbreviatedIRI="owl:Thing"/>
</SubClassOf>
<SubClassOf>
<Class IRI="#Component"/>
<ObjectSomeValuesFrom>
<ObjectProperty IRI="#hasComponentRelation"/>
<Class IRI="#Component"/>
</ObjectSomeValuesFrom>
</SubClassOf>
<SubClassOf>
<Class IRI="#Component"/>
<ObjectSomeValuesFrom>
<ObjectProperty IRI="#hasManufacturer"/>
<Class IRI="#Manufacturer"/>
</ObjectSomeValuesFrom>
</SubClassOf>
<SubClassOf>
<Class IRI="#Component"/>
<ObjectSomeValuesFrom>
<ObjectProperty IRI="#locatedIn"/>
<Class IRI="#region"/>
</ObjectSomeValuesFrom>
</SubClassOf>
<SubClassOf>
<Class IRI="#Component"/>
<ObjectMinCardinality cardinality="1">
<ObjectProperty
IRI="#hasComponentCharacteristic"/>
<Class IRI="#componentCharacteristic"/>
</ObjectMinCardinality>
</SubClassOf>
<SubClassOf>
<Class IRI="#Manufacturer"/>
<ObjectSomeValuesFrom>
<ObjectProperty IRI="#canDoProcess"/>
<Class IRI="#techProcess"/>
171
</ObjectSomeValuesFrom>
</SubClassOf>
<SubClassOf>
<Class IRI="#Manufacturer"/>
<ObjectSomeValuesFrom>
<ObjectProperty IRI="#hasEquipment"/>
<Class IRI="#equipment"/>
</ObjectSomeValuesFrom>
</SubClassOf>
<SubClassOf>
<Class IRI="#Manufacturer"/>
<ObjectSomeValuesFrom>
<ObjectProperty IRI="#locatedIn"/>
<Class IRI="#region"/>
</ObjectSomeValuesFrom>
</SubClassOf>
<SubClassOf>
<Class IRI="#Manufacturer"/>
<ObjectMinCardinality cardinality="1">
<ObjectProperty IRI="#produces"/>
<Class IRI="#Component"/>
</ObjectMinCardinality>
</SubClassOf>
<SubClassOf>
<Class IRI="#TechSituation"/>
<Class abbreviatedIRI="owl:Thing"/>
</SubClassOf>
<SubClassOf>
<Class IRI="#TechSituation"/>
<ObjectAllValuesFrom>
<ObjectProperty IRI="#includeComponent"/>
<Class IRI="#Component"/>
</ObjectAllValuesFrom>
</SubClassOf>
<SubClassOf>
<Class IRI="#atomComponent"/>
<Class IRI="#Component"/>
</SubClassOf>
<SubClassOf>
<Class IRI="#compositeComponent"/>
<ObjectSomeValuesFrom>
<ObjectProperty IRI="#consistsOf"/>
<Class IRI="#Component"/>
</ObjectSomeValuesFrom>
</SubClassOf>
<SubClassOf>
<Class IRI="#region"/>
<ObjectAllValuesFrom>
<ObjectProperty IRI="#locatedIn"/>
<Class IRI="#region"/>
</ObjectAllValuesFrom>
</SubClassOf>
<SubClassOf>
172
<Class IRI="#techProcess"/>
<ObjectSomeValuesFrom>
<ObjectProperty IRI="#canBeProcessedBy"/>
<Class IRI="#Manufacturer"/>
</ObjectSomeValuesFrom>
</SubClassOf>
<SubClassOf>
<Class IRI="#techProcess"/>
<ObjectSomeValuesFrom>
<ObjectProperty IRI="#hasTechProcessCharact"/>
<Class IRI="#techProcessCharacter"/>
</ObjectSomeValuesFrom>
</SubClassOf>
<SubClassOf>
<Class IRI="#techProcess"/>
<ObjectAllValuesFrom>
<ObjectProperty IRI="#consistsOf"/>
<Class IRI="#techProcess"/>
</ObjectAllValuesFrom>
</SubClassOf>
<SubClassOf>
<Class IRI="#techProcess"/>
<ObjectAllValuesFrom>
<ObjectProperty IRI="#necessaryEquipment"/>
<Class IRI="#equipment"/>
</ObjectAllValuesFrom>
</SubClassOf>
<SubClassOf>
<Class IRI="#techProcess"/>
<ObjectExactCardinality cardinality="1">
<ObjectProperty IRI="#endsWithSituation"/>
<Class IRI="#TechSituation"/>
</ObjectExactCardinality>
</SubClassOf>
<SubClassOf>
<Class IRI="#techProcess"/>
<ObjectExactCardinality cardinality="1">
<ObjectProperty IRI="#startsOnSituation"/>
<Class IRI="#TechSituation"/>
</ObjectExactCardinality>
</SubClassOf>
<DisjointClasses>
<Class IRI="#Cluster"/>
<Class IRI="#Component"/>
<Class IRI="#Manufacturer"/>
<Class IRI="#TechSituation"/>
<Class IRI="#componentCharacteristic"/>
<Class IRI="#equipment"/>
<Class IRI="#equipmentCharact"/>
<Class IRI="#region"/>
<Class IRI="#techProcess"/>
<Class IRI="#techProcessCharacter"/>
</DisjointClasses>
173
<SubObjectPropertyOf>
<ObjectProperty IRI="#isCommonal"/>
<ObjectProperty IRI="#hasComponentRelation"/>
</SubObjectPropertyOf>
<SubObjectPropertyOf>
<ObjectProperty IRI="#isEqual"/>
<ObjectProperty IRI="#hasComponentRelation"/>
</SubObjectPropertyOf>
<SubObjectPropertyOf>
<ObjectProperty IRI="#isIndependent"/>
<ObjectProperty IRI="#hasComponentRelation"/>
</SubObjectPropertyOf>
<SubObjectPropertyOf>
<ObjectProperty IRI="#isNotEqual"/>
<ObjectProperty IRI="#hasComponentRelation"/>
</SubObjectPropertyOf>
<InverseObjectProperties>
<ObjectProperty IRI="#antiConsecution"/>
<ObjectProperty IRI="#consecution"/>
</InverseObjectProperties>
<InverseObjectProperties>
<ObjectProperty IRI="#hasEquipment"/>
<ObjectProperty IRI="#belongsToManufacturer"/>
</InverseObjectProperties>
<InverseObjectProperties>
<ObjectProperty IRI="#canBeProcessedBy"/>
<ObjectProperty IRI="#canDoProcess"/>
</InverseObjectProperties>
<InverseObjectProperties>
<ObjectProperty IRI="#produces"/>
<ObjectProperty IRI="#hasManufacturer"/>
</InverseObjectProperties>
<InverseObjectProperties>
<ObjectProperty IRI="#isCommonal"/>
<ObjectProperty IRI="#isIndependent"/>
</InverseObjectProperties>
<InverseObjectProperties>
<ObjectProperty IRI="#isEqual"/>
<ObjectProperty IRI="#isNotEqual"/>
</InverseObjectProperties>
<SymmetricObjectProperty>
<ObjectProperty IRI="#adjacentToRegion"/>
</SymmetricObjectProperty>
<SymmetricObjectProperty>
<ObjectProperty IRI="#antiConsecution"/>
</SymmetricObjectProperty>
<SymmetricObjectProperty>
<ObjectProperty IRI="#isCommonal"/>
</SymmetricObjectProperty>
<SymmetricObjectProperty>
<ObjectProperty IRI="#isEqual"/>
</SymmetricObjectProperty>
<SymmetricObjectProperty>
174
<ObjectProperty IRI="#isIndependent"/>
</SymmetricObjectProperty>
<SymmetricObjectProperty>
<ObjectProperty IRI="#isNotEqual"/>
</SymmetricObjectProperty>
<TransitiveObjectProperty>
<ObjectProperty IRI="#consecution"/>
</TransitiveObjectProperty>
<TransitiveObjectProperty>
<ObjectProperty IRI="#consistsOf"/>
</TransitiveObjectProperty>
<TransitiveObjectProperty>
<ObjectProperty IRI="#critSeq"/>
</TransitiveObjectProperty>
<TransitiveObjectProperty>
<ObjectProperty IRI="#isEqual"/>
</TransitiveObjectProperty>
<TransitiveObjectProperty>
<ObjectProperty IRI="#locatedIn"/>
</TransitiveObjectProperty>
<ReflexiveObjectProperty>
<ObjectProperty IRI="#consecution"/>
</ReflexiveObjectProperty>
<ReflexiveObjectProperty>
<ObjectProperty IRI="#critSeq"/>
</ReflexiveObjectProperty>
<ReflexiveObjectProperty>
<ObjectProperty IRI="#isCommonal"/>
</ReflexiveObjectProperty>
<ReflexiveObjectProperty>
<ObjectProperty IRI="#isEqual"/>
</ReflexiveObjectProperty>
…
</Ontology>
175
ПРИЛОЖЕНИЕ 2. ИНТЕРФЕЙСЫ ИС ПС «Composite-S
v.1.0»
WSDL-описание нтерфейса сервиса «Фронт-приложение»
<?xml version="1.0" encoding="UTF-8"?>
<definitions xmlns="http://schemas.xmlsoap.org/wsdl/"
xmlns:tns="urn:ServiceControllerwsdl"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
name="ServiceController" targetNamespace="urn:ServiceControllerwsdl">
<wsdl:message name="getSrvAdressIn">
<wsdl:part name="srvType" type="xsd:int">
<wsdl:documentation>Тип сервиса</wsdl:documentation>
</wsdl:part>
</wsdl:message>
<wsdl:message name="getSrvAdressOut">
<wsdl:part name="return" type="xsd:string">
<wsdl:documentation>JSON-список сервисов</wsdl:documentation>
</wsdl:part>
</wsdl:message>
<wsdl:message name="getStatusIn"/>
<wsdl:message name="getStatusOut">
<wsdl:part name="return" type="xsd:string">
<wsdl:documentation>Статус сервиса</wsdl:documentation>
</wsdl:part>
</wsdl:message>
<wsdl:portType name="ServiceControllerPortType">
<wsdl:operation name="getSrvAdress">
<wsdl:documentation>Получение адресов сервисов</wsdl:documentation>
<wsdl:input message="tns:getSrvAdressIn"/>
<wsdl:output message="tns:getSrvAdressOut"/>
</wsdl:operation>
<wsdl:operation name="getStatus">
<wsdl:documentation>Проверка статуса сервиса</wsdl:documentation>
<wsdl:input message="tns:getStatusIn"/>
<wsdl:output message="tns:getStatusOut"/>
</wsdl:operation>
</wsdl:portType>
<wsdl:binding name="ServiceControllerBinding"
type="tns:ServiceControllerPortType">
<soap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http"/>
<wsdl:operation name="getSrvAdress">
176
<soap:operation soapAction="urn:ServiceControllerwsdl#getSrvAdress" style="rpc"/>
<wsdl:input>
<soap:body use="encoded" encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" namespace="urn:ServiceControllerwsdl"/>
</wsdl:input>
<wsdl:output>
<soap:body use="encoded" encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" namespace="urn:ServiceControllerwsdl"/>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="getStatus">
<soap:operation soapAction="urn:ServiceControllerwsdl#getStatus" style="rpc"/>
<wsdl:input>
<soap:body use="encoded" encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" namespace="urn:ServiceControllerwsdl"/>
</wsdl:input>
<wsdl:output>
<soap:body use="encoded" encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" namespace="urn:ServiceControllerwsdl"/>
</wsdl:output>
</wsdl:operation>
</wsdl:binding>
<wsdl:service name="ServiceControllerService">
<wsdl:port name="ServiceControllerPort" binding="tns:ServiceControllerBinding">
<soap:address location="http://composites.dev/index.php?r=service/wsdl&ws=1"/>
</wsdl:port>
</wsdl:service>
</definitions>
WSDL-описание нтерфейса сервиса «ТБЗ»
<?xml version="1.0" encoding="UTF-8"?>
<definitions xmlns="http://schemas.xmlsoap.org/wsdl/"
xmlns:tns="urn:ServiceControllerwsdl"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
name="ServiceController" targetNamespace="urn:ServiceControllerwsdl">
<wsdl:message name="getReceptIn">
<wsdl:part name="user" type="xsd:int">
<wsdl:documentation>Пользователь, который запрашивает
рецепт</wsdl:documentation>
</wsdl:part>
177
<wsdl:part name="product" type="xsd:int">
<wsdl:documentation>Продукт, который должен быть получен</wsdl:documentation>
</wsdl:part>
<wsdl:part name="info" type="xsd:anyType">
<wsdl:documentation>Дополнительная информация</wsdl:documentation>
</wsdl:part>
</wsdl:message>
<wsdl:message name="getReceptOut">
<wsdl:part name="return" type="xsd:string">
<wsdl:documentation>Технологический процесс в формате
JSON</wsdl:documentation>
</wsdl:part>
</wsdl:message>
<wsdl:message name="getOldReceptsIn">
<wsdl:part name="user" type="xsd:int">
<wsdl:documentation>Идентификатор пользователя</wsdl:documentation>
</wsdl:part>
</wsdl:message>
<wsdl:message name="getOldReceptsOut">
<wsdl:part name="return" type="xsd:string">
<wsdl:documentation>Рецепты в формате
JSON</wsdl:documentation>
</wsdl:part>
</wsdl:message>
<wsdl:message name="setReceptResultIn">
<wsdl:part name="recept" type="xsd:int">
<wsdl:documentation>Идентификатор рецепта</wsdl:documentation>
</wsdl:part>
<wsdl:part name="product" type="xsd:int">
<wsdl:documentation>Полученный продукт</wsdl:documentation>
</wsdl:part>
</wsdl:message>
<wsdl:message name="setReceptResultOut">
<wsdl:part name="return" type="xsd:string">
<wsdl:documentation>Результат запроса обновления данных</wsdl:documentation>
</wsdl:part>
</wsdl:message>
<wsdl:message name="newTechnologyIn">
<wsdl:part name="data" type="xsd:anyType">
<wsdl:documentation>Технологический процесс</wsdl:documentation>
</wsdl:part>
</wsdl:message>
<wsdl:message name="newTechnologyOut">
<wsdl:part name="return" type="xsd:string">
<wsdl:documentation>Результат запроса обновления данных</wsdl:documentation>
178
</wsdl:part>
</wsdl:message>
<wsdl:message name="getStatusIn"/>
<wsdl:message name="getStatusOut">
<wsdl:part name="return" type="xsd:string">
<wsdl:documentation>Статус сервиса</wsdl:documentation>
</wsdl:part>
</wsdl:message>
<wsdl:portType name="ServiceControllerPortType">
<wsdl:operation name="getRecept">
<wsdl:documentation>Запрос рецепта компонентной смеси</wsdl:documentation>
<wsdl:input message="tns:getReceptIn"/>
<wsdl:output message="tns:getReceptOut"/>
</wsdl:operation>
<wsdl:operation name="getOldRecepts">
<wsdl:documentation>Запрос ранее расчитаных рецептов</wsdl:documentation>
<wsdl:input message="tns:getOldReceptsIn"/>
<wsdl:output message="tns:getOldReceptsOut"/>
</wsdl:operation>
<wsdl:operation name="setReceptResult">
<wsdl:documentation>Сопоставление полученного на производстве продукта ранее расчитаному рецепту</wsdl:documentation>
<wsdl:input message="tns:setReceptResultIn"/>
<wsdl:output message="tns:setReceptResultOut"/>
</wsdl:operation>
<wsdl:operation name="newTechnology">
<wsdl:documentation>Обучение ТБЗ новой технологии смешивания</wsdl:documentation>
<wsdl:input message="tns:newTechnologyIn"/>
<wsdl:output message="tns:newTechnologyOut"/>
</wsdl:operation>
<wsdl:operation name="getStatus">
<wsdl:documentation>Проверка статуса сервиса</wsdl:documentation>
<wsdl:input message="tns:getStatusIn"/>
<wsdl:output message="tns:getStatusOut"/>
</wsdl:operation>
</wsdl:portType>
<wsdl:binding name="ServiceControllerBinding"
type="tns:ServiceControllerPortType">
<soap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http"/>
<wsdl:operation name="getRecept">
<soap:operation soapAction="urn:ServiceControllerwsdl#getRecept" style="rpc"/>
<wsdl:input>
<soap:body use="encoded" encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" namespace="urn:ServiceControllerwsdl"/>
</wsdl:input>
179
<wsdl:output>
<soap:body use="encoded" encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" namespace="urn:ServiceControllerwsdl"/>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="getOldRecepts">
<soap:operation soapAction="urn:ServiceControllerwsdl#getOldRecepts" style="rpc"/>
<wsdl:input>
<soap:body use="encoded" encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" namespace="urn:ServiceControllerwsdl"/>
</wsdl:input>
<wsdl:output>
<soap:body use="encoded" encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" namespace="urn:ServiceControllerwsdl"/>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="setReceptResult">
<soap:operation soapAction="urn:ServiceControllerwsdl#setReceptResult" style="rpc"/>
<wsdl:input>
<soap:body use="encoded" encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" namespace="urn:ServiceControllerwsdl"/>
</wsdl:input>
<wsdl:output>
<soap:body use="encoded" encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" namespace="urn:ServiceControllerwsdl"/>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="newTechnology">
<soap:operation soapAction="urn:ServiceControllerwsdl#newTechnology" style="rpc"/>
<wsdl:input>
<soap:body use="encoded" encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" namespace="urn:ServiceControllerwsdl"/>
</wsdl:input>
<wsdl:output>
<soap:body use="encoded" encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" namespace="urn:ServiceControllerwsdl"/>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="getStatus">
<soap:operation soapAction="urn:ServiceControllerwsdl#getStatus" style="rpc"/>
<wsdl:input>
180
<soap:body use="encoded" encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" namespace="urn:ServiceControllerwsdl"/>
</wsdl:input>
<wsdl:output>
<soap:body use="encoded" encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" namespace="urn:ServiceControllerwsdl"/>
</wsdl:output>
</wsdl:operation>
</wsdl:binding>
<wsdl:service name="ServiceControllerService">
<wsdl:port name="ServiceControllerPort" binding="tns:ServiceControllerBinding">
<soap:address location="http://tbz.composites.dev/index.php?r=service/wsdl&ws=1"/>
</wsdl:port>
</wsdl:service>
</definitions>
WSDL-описание нтерфейса сервиса расчёта
<?xml version="1.0" encoding="UTF-8"?>
<definitions xmlns="http://schemas.xmlsoap.org/wsdl/"
xmlns:tns="urn:ServiceControllerwsdl"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
name="ServiceController" targetNamespace="urn:ServiceControllerwsdl">
<wsdl:message name="blendTaskCalculationIn">
<wsdl:part name="blendTaskData" type="xsd:anyType">
<wsdl:documentation>Задание</wsdl:documentation>
</wsdl:part>
</wsdl:message>
<wsdl:message name="blendTaskCalculationOut">
<wsdl:part name="return" type="xsd:string">
<wsdl:documentation>Результат расчёта в формате
JSON</wsdl:documentation>
</wsdl:part>
</wsdl:message>
<wsdl:message name="adaptTaskCalculationIn">
<wsdl:part name="adaptTaskData" type="xsd:anyType">
<wsdl:documentation>Задание</wsdl:documentation>
</wsdl:part>
</wsdl:message>
<wsdl:message name="adaptTaskCalculationOut">
<wsdl:part name="return" type="xsd:string">
<wsdl:documentation>Результат расчёта в формате
JSON</wsdl:documentation>
</wsdl:part>
</wsdl:message>
181
<wsdl:message name="getStatusIn"/>
<wsdl:message name="getStatusOut">
<wsdl:part name="return" type="xsd:string">
<wsdl:documentation>Статус сервиса</wsdl:documentation>
</wsdl:part>
</wsdl:message>
<wsdl:portType name="ServiceControllerPortType">
<wsdl:operation name="blendTaskCalculation">
<wsdl:documentation>Расчёт части данных по заданию
сервиса ТБЗ для оптимизации рецептов
смесей</wsdl:documentation>
<wsdl:input message="tns:blendTaskCalculationIn"/>
<wsdl:output message="tns:blendTaskCalculationOut"/>
</wsdl:operation>
<wsdl:operation name="adaptTaskCalculation">
<wsdl:documentation>Расчёт части данных по заданию
сервиса ТБЗ для алгоритма адаптации</wsdl:documentation>
<wsdl:input message="tns:adaptTaskCalculationIn"/>
<wsdl:output message="tns:adaptTaskCalculationOut"/>
</wsdl:operation>
<wsdl:operation name="getStatus">
<wsdl:documentation>Проверка статуса
сервиса</wsdl:documentation>
<wsdl:input message="tns:getStatusIn"/>
<wsdl:output message="tns:getStatusOut"/>
</wsdl:operation>
</wsdl:portType>
<wsdl:binding name="ServiceControllerBinding"
type="tns:ServiceControllerPortType">
<soap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http"/>
<wsdl:operation name="blendTaskCalculation">
<soap:operation soapAction="urn:ServiceControllerwsdl#blendTaskCalculation"
style="rpc"/>
<wsdl:input>
<soap:body use="encoded" encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" namespace="urn:ServiceControllerwsdl"/>
</wsdl:input>
<wsdl:output>
<soap:body use="encoded" encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" namespace="urn:ServiceControllerwsdl"/>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="adaptTaskCalculation">
<soap:operation soapAction="urn:ServiceControllerwsdl#adaptTaskCalculation"
style="rpc"/>
<wsdl:input>
182
<soap:body use="encoded" encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" namespace="urn:ServiceControllerwsdl"/>
</wsdl:input>
<wsdl:output>
<soap:body use="encoded" encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" namespace="urn:ServiceControllerwsdl"/>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="getStatus">
<soap:operation soapAction="urn:ServiceControllerwsdl#getStatus" style="rpc"/>
<wsdl:input>
<soap:body use="encoded" encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" namespace="urn:ServiceControllerwsdl"/>
</wsdl:input>
<wsdl:output>
<soap:body use="encoded" encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" namespace="urn:ServiceControllerwsdl"/>
</wsdl:output>
</wsdl:operation>
</wsdl:binding>
<wsdl:service name="ServiceControllerService">
<wsdl:port name="ServiceControllerPort" binding="tns:ServiceControllerBinding">
<soap:address location="http://r1.composites.dev/index.php?r=service/wsdl&ws=1"/>
</wsdl:port>
</wsdl:service>
</definitions>
WSDL-описание нтерфейса сервиса сбора информации
<?xml version="1.0" encoding="UTF-8"?>
<definitions xmlns="http://schemas.xmlsoap.org/wsdl/"
xmlns:tns="urn:ServiceControllerwsdl"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
name="ServiceController" targetNamespace="urn:ServiceControllerwsdl">
<wsdl:message name="infoRectificationIn">
<wsdl:part name="infoType" type="xsd:int">
<wsdl:documentation>Тип информации</wsdl:documentation>
</wsdl:part>
<wsdl:part name="infoData" type="xsd:anyType">
<wsdl:documentation>Информация</wsdl:documentation>
</wsdl:part>
</wsdl:message>
183
<wsdl:message name="infoRectificationOut">
<wsdl:part name="return" type="xsd:string">
<wsdl:documentation>Уточнённая информация в формате
JSON</wsdl:documentation>
</wsdl:part>
</wsdl:message>
<wsdl:message name="getStatusIn"/>
<wsdl:message name="getStatusOut">
<wsdl:part name="return" type="xsd:string">
<wsdl:documentation>Статус сервиса</wsdl:documentation>
</wsdl:part>
</wsdl:message>
<wsdl:portType name="ServiceControllerPortType">
<wsdl:operation name="infoRectification">
<wsdl:documentation>Уточнение информации по запросу</wsdl:documentation>
<wsdl:input message="tns:infoRectificationIn"/>
<wsdl:output message="tns:infoRectificationOut"/>
</wsdl:operation>
<wsdl:operation name="getStatus">
<wsdl:documentation>Проверка статуса сервиса</wsdl:documentation>
<wsdl:input message="tns:getStatusIn"/>
<wsdl:output message="tns:getStatusOut"/>
</wsdl:operation>
</wsdl:portType>
<wsdl:binding name="ServiceControllerBinding"
type="tns:ServiceControllerPortType">
<soap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http"/>
<wsdl:operation name="infoRectification">
<soap:operation soapAction="urn:ServiceControllerwsdl#infoRectification"
style="rpc"/>
<wsdl:input>
<soap:body use="encoded" encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" namespace="urn:ServiceControllerwsdl"/>
</wsdl:input>
<wsdl:output>
<soap:body use="encoded" encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" namespace="urn:ServiceControllerwsdl"/>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="getStatus">
<soap:operation soapAction="urn:ServiceControllerwsdl#getStatus" style="rpc"/>
<wsdl:input>
<soap:body use="encoded" encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" namespace="urn:ServiceControllerwsdl"/>
</wsdl:input>
184
<wsdl:output>
<soap:body use="encoded" encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" namespace="urn:ServiceControllerwsdl"/>
</wsdl:output>
</wsdl:operation>
</wsdl:binding>
<wsdl:service name="ServiceControllerService">
<wsdl:port name="ServiceControllerPort" binding="tns:ServiceControllerBinding">
<soap:address location="http://i1.composites.dev/index.php?r=service/wsdl&ws=1"/>
</wsdl:port>
</wsdl:service>
</definitions>
185
ПРИЛОЖЕНИЕ 3. СВИДЕТЕЛЬСТВО О
ГОСУДАРСТВЕННОЙ РЕГИСТРАЦИИ ПРОГРАММЫ ДЛЯ
ЭВМ
187
ПРИЛОЖЕНИЕ 4. АКТЫ ВНЕДРЕНИЯ РЕЗУЛЬТАТОВ
ДИССЕРТАЦИОННОЙ РАБОТЫ